Y a-t-il une mauvaise chose si je change /etc/ldap/slapd.d/cn=config.ldif manuellement?

Depuis 2,3, OpenLDAP utilise un moteur de configuration appelé slapd-config. Ils ont dit que l'utiliser pour que toute la configuration LDAP puisse être changée en vol.

C'est l'en-tête de /etc/ldap/slapd.d/cn=config.ldif:

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. 

J'ai changé de données et certains autres fichiers qui ont cet en-tête, après avoir redémarré le slapd, mes modifications ont eu des effets.

Y a-t-il quelque chose d'autre si je change ces fichiers manuellement? Si je n'ai pas besoin de 'change on fly', dois-je modifier ces fichiers manuellement au lieu d'utiliser ldapmodify? Quelle application a généré ces fichiers, et quand?

REMARQUE: j'utilise openldap-2.4.28 sur Ubuntu 12.04

Si vous modifiez manuellement les fichiers LDIF dans cn = config, leur contenu et les sommes de contrôle ne correspondent pas, ce qui n'est pas fatal, mais est ennuyant lors de l'utilisation d'outils tels que Slapcat .

La modification de cn = config de manière appropriée avec ldapmodify est très pénible, et vous finirez par accumuler des tonnes de fichiers LDIF à la fois artisanaux, à usage unique, à usage unique. Par rapport à l'édition de slapd.conf, c'est un cauchemar. Quoi qu'il en soit, si vous devez effectuer des modifications de configuration d'exécution, ldapmodify est votre seule option. Cependant, si vous pouvez vous procurer un certain temps d'arrêt, vous avez deux autres poisons parmi lesquels choisir.

Tout d'abord, il existe une méthode hautement non prise en charge mais rapide et sale qui fonctionne bien pour la configuration initiale d'OpenLDAP si vous savez ce que vous faites:

 $ service slapd stop $ cp -a /etc/ldap/slapd.d /etc/ldap/slapd.d.old <edit the LDIF files in /etC/ldap/slapd.d> $ service slapd start 

Si Slapd démarre, il devrait fonctionner correctement, mais c'est toujours une bonne idée de la queue / var / log / syslog lors du démarrage du service:

 $ tail -n 0 -f /var/log/syslog|grep slapd 

Vous pouvez corriger les erreurs de somme de contrôle en utilisant slapcat et slapadd comme décrit ci-dessous.

Deuxièmement, il existe une méthode moins souple qui implique l'utilisation de slapcat et slapadd (modifié à partir de ces instructions ):

 $ slapcat -n0 -F /etc/ldap/slapd.d > config.ldif <edit config.ldif> $ mkdir /etc/ldap/slapd.d.new $ slapadd -n0 -F /etc/ldap/slapd.d.new -l config.ldif 

Si slapadd réussit sans erreurs, vous pouvez migrer vers le répertoire slapd.d modifié. Selon ce fil, Slapadd n'ajoute que des données, afin d'écraser le contenu du répertoire slapd.d d'origine n'est pas possible. Par conséquent, nous devons déplacer les répertoires autour d'un peu:

 $ service slapd stop $ mv /etc/ldap/slapd.d /etc/ldap/slapd.d.old $ mv /etc/ldap/slapd.d.new /etc/ldap/slapd.d $ chown -R openldap:openldap /etc/ldap/slapd.d $ service slapd start 

Ces deux méthodes plus ou moins non supportées permettent de vivre avec cn = config un peu plus supportable.

Lorsque vous voyez un fichier qui indique

 # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. 

Vous feriez bien de suivre les instructions pour modifier correctement le contenu de ce fichier .

Dans ce cas, cela signifie mettre à jour la configuration OpenLDAP en utilisant la commande ldapmodify conformément au manuel OpenLDAP.
Cela vous permet d'appliquer des modifications à la configuration OpenLDAP à la volée et de régénérer le slapd.conf (utilisé lors du démarrage du serveur LDAP en tant que configuration bootstrap)


En général, l'échec de suivre les instructions (comme "NE PAS MODIFIER CE FICHIER, PUIS-T-IL AUTOMATIQUE!") Entraînera des douleurs et des souffrances.

Dans ce cas particulier, vous pouvez constater que vos modifications apportées au fichier ont été effacées la prochaine fois que quelqu'un effectuera les choses de la bonne manière, et vous devrez reconstruire votre configuration (probablement sans enregistrement, car le fichier que vous avez édité sera Remplacé).
La prochaine fois que vous ne pourrez pas écouter un avertissement comme celui-ci, vous pourriez rendre un système non démarrable ou pire.