Выборы закончились, можно жечь.
Выборы закончились, можно жечь.
Выборы закончились, можно жечь.
Например, у пользователей чистятся папки с карантином. Раньше работало вот так:
purgespam cmd=»ipurge -f -d 5 user.*.quarantine» at=0100
Но теперь программа стала «выборочно» очищать папки, некоторые просто игнорирует.
Есть подозрение, что изменили таймаут, по которому прекращается выполнение ipurge.
Пока не разобрался в причине, пришлось выкручиваться вот таким смешным образом:
и так далее, по всему алфавиту 🙂
Исходные данные:
корень зла: dc=test,dc=com
организация раз: o=org1,dc=test,dc=com
организация два: o=org2,dc=test,dc=com
Необходимо пользователю uid=admin1,o=org1,dc=test,dc=com дать возможность управлять (добавлять, удалять, редактировать) записи в org1. Пользователю uid=admin2,o=org2,dc=test,dc=com, аналогичные права на org1 и org2.
Мы не будем жестко прописывать в acl пользователей. Каждый раз менять sldap.conf или динамический cn=config при изменении администратора контейнера не очень удобно. Для разгарничения доступа будем использовать objectclass: groupOfNames. По сути своей — это группа, которую, в отличии от posixGroup, openldap умеет использовать в acl.
Создадим две группы: cn=admins1,dc=test,dc=com и cn=admins2,dc=test,dc=com. В первую будем добавлять пользователей, которые будут рулить org1, во вторую, пользователей управляющих org2. Обратите внимание на то, что эти группы в иерархии находятся на одном уровне с org1 и org2, это сделано для того, чтобы добавлять/удалять пользователей в эти группы мог только суперадмин.
dn: cn=admins2,dc=test,dc=com
cn: admins2
member: uid=admin2,o=org2,dc=test,dc=com
objectclass: groupOfNames
objectclass: top
Теперь займемся sldap.conf. За основу был взят файл из пакета в OpenSuSE. От оригинала остались только первые два правила.
access to attrs=userPassword,userPKCS12
by self write
by * auth
access to attrs=shadowLastChange
by self write
by * read
#=====================================
access to dn.subtree=»o=org1,dc=test,dc=com»
by self write
by group.exact=»cn=admins1,dc=test,dc=com» write
by anonymous auth
by * read
#======================================
access to dn.subtree=»o=org2,dc=test,dc=com»
by self write
by group.exact=»cn=admins2,dc=test,dc=com» write
by anonymous auth
by * read
#=======================================
access to dn.base=»dc=test,dc=com»
by * read
access to dn.one=»dc=test,dc=com»
by * read
access to dn.base=»»
by * read
access to dn.base=»cn=Subschema»
by * read
access to *
by * none
Рассмотрим подробнее этот файл. Как я уже говорил, первые два правила отсались от оригинала.
Правило доступа к контейнеру o=org1,dc=test,dc=com
Аналогично описан доступ ко второму контейнеру.
access to dn.base=»dc=test,dc=com»
by * read
access to dn.one=»dc=test,dc=com»
by * read
access to dn.base=»»
by * read
Эти правила добавил для того, чтобы программы типа phpLDAPadmin могли отображать информацию о корневых контейнерах.
access to dn.base=»cn=Subschema»
by * read
Это запись для удобства. В phpLDAPadmin можно смотреть схемы, описания атрибутов, при условии, что ldap сервер такую информацию отдаёт.
access to *
by * none
Вот пожалуй и все. В результате, если поменялся администратор контейнера не надо рестартовать сервер (в случае статической конфигурации) или возится с ldif файлами (в случае динамической конфигурации). В любом клиенте ldap заходим суперадмином и меняем членов групп admins1 и admins2.
Лечится это просто, в sldap.conf необходимо заменить схему rfc2307bis.schema на nis.schema. Перезапустить ldap сервер. В интерфейсе phpLDAPadmin-на очистить кеш (там есть соответствующая ссылочка). После этого шаблон создания группы будет доступен.
Очень длинная передача, но рекомендую дослушать до конца.