В статье будут описаны нюансы в работе, возможно некоторые очевидны, но все это понимают.
OS
По сути один и тот же openldap, но в разных ОС с одними и теми же ключами может работать или не работать. Вот пример:
ldapsearch -x -LLLL -D 'cn=admin,ou=services,dc=domain,dc=com' '(!(objectClass=gosaDepartment))' -s sub -H 'ldaps://ldap.domain.com' -b 'uid=user,ou=people,dc=domain,dc=com' -w '<pass>'
Так вот, в Linux’e это отработает нормально, а в Solaris будет ругань:
ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed
В чём же дело? Внимательный читатель заметит, что фильтр идёт не в конце, после всех параметров, в средине. Видимо, в Linux не так строго, как в Solaris.
Index
В OpenLDAP’e так же, как и в mysql/postgresql/… есть индексы. Полная аналогия как по преимуществам, так и по недостаткам. Как правило, самыми распространёнными есть eq (чёткое соответствие) и sub (аналог like в базах данных). Их так же нужно использовать с осторожностью: слишком много индексов будут больше потреблять ресурсов. Поэтому, используйте их только тогда, когда в логах часто видите сообщения:
<= mdb_substring_candidates: (description) not indexed
что означает, что индекс по атрибуту description не используется. Можно задавать так:
index roleOccupant eq,sub
а можно одним махом сразу несколько определить и для них всех будет использоваться матчинг eq+sub:
index default sub,eq index cn,sn,uid,mail,givenName,description
Теперь самое важное! Если вы делаете include схем с описанием атрибутов, то использовать индекс вы можете только после включения файла, где он описан. В противном случае вы получите ошибку:
/etc/openldap/slapd.conf: line 85: index attribute "gosaGroupObjects" undefined
Дальше. Индексы создаются исключительно в момент заливки ldif’a в пустую базу. Если же захотелось индексы на непустой базе, нужно её принудительно переиндексировать, предварительно остановив службу LDAP’e:
slapindex -v -f /etc/openldap/slapd.conf
Limit
С ними сталкиваешься на относительно не больших объёмах баз, к примеру, 500 записей пользователей (неважно, активные или нет) + 20 групп уже могут выходить на пределы лимита. В логах можно увидеть такую запись:
mdb_id2entry_put: mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
Для решения этого нужно увеличить объём самой базы хранения. По умолчанию она 10Мб. Заодно, можно увеличить и прочие лимиты, например, на передачу данных на slave – сервера:
overlay memberof ... maxsize 104857600 sizelimit unlimited sizelimit size=unlimited
... overlay syncprov ... sizelimit unlimited sizelimit size=unlimited
Важно делать эти изменения в каждом блоке overlay.
Возможно, стоит еще увеличить и такой лимит sockbuf_max_incoming_auth (sockbuf_max_incoming). Вот выдержка из справки:
sockbuf_max_incoming
Controls the packet size that is accepted for add/modify/delete/search operations. This option lets you control the max packet size in bytes. This option can be used to prevent denial of service attacks.
Default: 262,144
Example: sockbuf_max_incoming 123456
sockbuf_max_incoming_auth
Controls the packet size that is accepted for authentication (bind) operations. This option lets you control the max packet size in bytes. This option can be used to prevent denial of service attacks.
Default: 1,677,216
Example: sockbuf_max_incoming_auth 123456
master – slave
Как узнать, актуален ли ваш slave? Узнать это можно, запросив аттрибут contextCSN у master’a и slave’a и сравнив их. По сути это немного изменённый timestamp.
Config
Существует 2 метода хранения параметров: классический и новый OLC (когда параметры LDAP’a хранятся в самом LDAP’e). Как отличать их? Всё просто: если вы встречаете параметры, которые начинаются с olc, например, olcAccess, то это новый метод. У OLC метода есть свои преимущества и недостатки:
преимущества – не нужно делать restart сервера, если нужно внести изменения в настройки сервера
недостатки – любые изменения в конфиге нужно делать через ldapadd/ldapmodify, что усложняет настройку.
LoadBalancer
Для повышения отказоустойчивости, можно применять lload (LDAP Load Balancer Daemon ) , если у вас версия 2.5 и выше или другой tcp proxy (например, haproxy), если версия 2.4 или ниже.
Dynamic groups (dynlist overlay)
Это чем-то похоже на временные таблицы в mysql. Предположим, у вас есть группа в 20000 человек, но вам нужны не все пользователи из этой группы, а только некоторые, которых вы можете отобрать через search filter (допустим, он очень большой или ПО не позволяет использовать или ещё какие-то причины). Можно создать соответствующую группу и поместить их туда. Но если это нужно делать часто, то проще поменять search filter, чем каждый раз добавлять/удалять пользователей из групп. Именно это и позволяет dynlist: вы создаете динамическую группу на основе некоторого search filter (memberURL) и далее работаете с ней, как с обычной группой.
ManageDsaIT
Adding, modifying, and deleting referral objects is generally done using ldapmodify(1) or similar tools which support the ManageDsaIT control. The ManageDsaIT control informs the server that you intend to manage the referral object as a regular entry. This keeps the server from sending a referral result for requests which interrogate or update referral objects.
The ManageDsaIT control should not be specified when managing regular entries.
