Различные полномочия на файл журнала при использовании rsyslog

Хорошее резюме, несколько дополнительных моментов:

• slapcat делает дамп из любого ( local), это не обязательно Berkeley (hdb или bdb), он также работает с OLC ( cn = config ). Выполняется дамп в формат LDIF . (Под прямым я подразумеваю непосредственно управляемый OpenLDAP, а не, например, серверную часть SQL, даже если он хранится локально.)
• ldapadd требует, чтобы slapd был запущен, slapadd требует, чтобы он не работал
• ldapsearch требует, чтобы slapd был запущен, slapcat не заботится о том, работает ли он с Бэкэнд BDB, как вы заметили

Короче:

• slapcat - это способ получить хорошую резервную копию, которую можно быстро восстановить, хотя и с простоями на главном сервере (вы можете обойти это с помощью различных типов настройки репликации). Это то, что вы должны использовать для общего резервного копирования и резервных копий перед обновлением.
• ldapsearch (без + ) предоставит вам портативную резервную копию , которую вы, вероятно, сможете загрузить с небольшими трудностями в любой другой сервер каталогов, но это будет жизнеспособное восстановление только при простой настройке OpenLDAP (без репликации, без специальных наложений, без перезаписи), и если вы не заботитесь о сохранении UUID / создании / изменении метаданных -данные. Вам также понадобятся любые дополнительные файлы схемы, которые идут вместе с вашими данными.
• ldapadd (с использованием другого идентификатора ldapmodify ) можно использовать для простого применения изменений LDAP (изменение объекта, удалить и переименовать), что невозможно или невозможно с помощью slapadd / slapcat только

Для большинства администраторов основные соображения возникают из-за немного различающегося содержимого LDIF в каждом случае, и требование для slapd , чтобы он работал (или не работал). Более важные отличия заключаются в следующем:

1. slapcat быстрее, потому что он просто выгружает базу данных, пропуская служебные данные протокола LDAP, аутентификацию, контроль доступа, объектные и временные ограничения, наложения; и он не выполняет поиск в соответствии с иерархией LDAP.
2. slapadd работает быстрее (опять же, без накладных расходов протокола LDAP), и в случае, если вы восстанавливаете заведомо исправную резервную копию, вы можете запустить ее в быстром режиме ( -q ), чтобы ускорить крупный импорт. Вы также можете отключить проверку схемы ( -s ), хотя заметьте, что небольшие изменения в схеме или проверке данных между версиями OpenLDAP не являются чем-то необычным.
3. slapcat ограничен локальными базами данных, он не будет переходить на другие каталоги (например, с back-ldap ], back-meta ) как будет ldapsearch . То же самое относится к slapadd / ldapadd .
4. ldapsearch будет возвращать динамические атрибуты, которые не хранятся в серверной части, например hasSubordinates или поддерживаемые с помощью оверлеев (например, slapo-memberof ). У вас возникнут проблемы с их загрузкой с помощью ldapadd (например, операционные атрибуты без модификации пользователем). Перезапись (slapo-rwm) также может исказить представление ldapsearch содержимого каталога.
5. slapcat включает внутренние (рабочие) атрибуты, если вы используете репликацию, эти атрибуты критичны. При репликации вы несколько меньше зависите от резервного копирования, но если вы используете ldapadd для перезагрузки своего мастера, каждый объект будет воссоздан путем репликации (изменен entryUUID entryCSN ) Хотя вы можете включить операционные атрибуты с помощью специального атрибута «+» с ldapsearch (или allop overlay), это не то же самое, что slapcat ], почему это так, см. предыдущий пункт. Эти атрибуты также включают создание / изменение DN и отметки времени, которые могут быть важны для некоторых приложений.
6. поскольку slapcat не соблюдает иерархию LDAP (подразумеваемый порядок), нет гарантии, что его порядок данных будет чтобы быть жизнеспособным с ldapadd - т.е. даже если вы удалите операционные атрибуты, ldapadd может пожаловаться, потому что подчиненные могут появиться перед их вышестоящими (родителями). Спецификации LDAP требуют наличия родителя, но также оставляют неопределенный порядок результатов поиска в этом отношении. См. Комментарий Ховарда ниже: OpenLDAP slapadd молча поддерживает неупорядоченные данные для некоторых бэкэндов. В крайнем случае, вы можете повторно использовать slapadd с опцией «Продолжить при ошибке» ( -c ), пока все " он определяет режим создания для всех строк селектора, следующих до следующей директивы $ FileCreateMode. Порядок строк жизненно важен.