Note : Le problème arrive dans un cas bien particulier, uniquement si on veut faire du multi-instances avec OpenLDAP sur une machine, qui tourne avec un O.S. Ubuntu (testé à partir de 16.04).
Les mêmes actions sur un serveur sous Debian se passent correctement.
Contexte
La configuration et les données sont dans une arborescence :
/opt/openldap conf/data.d : configuration de l'instance data conf/repli.d : configuration de l'instance repli (replica de la première instance) db/data : données de l'instance data db/repli : données de l'instance repli
La création de l'instance est faite via un fichier LDIF et la commande slapadd. Tout semble se passer correctement jusque là.
Symptôme du problème
Lorsque l'on veut démarrer l'instance avec la commande
/usr/sbin/slapd -h 'ldap://:389/ ' -g openldap -u openldap -F /opt/openldap/conf/data.d -n slapddata -d -1
On a un message d'erreur :
5a4e15c3 slapddata init: initiated server. 5a4e15c3 slap_sasl_init: initialized! 5a4e15c3 backend_startup_one: starting "cn=config" 5a4e15c3 ldif_read_file: Permission denied for "/opt/openldap/conf/data.d/cn=config.ldif" 5a4e15c3 send_ldap_result: conn=-1 op=0 p=0 5a4e15c3 send_ldap_result: err=80 matched="" text="internal error (cannot read some entry file)" 5a4e15c3 slapddata destroy: freeing system resources. 5a4e15c3 slapd stopped. 5a4e15c3 connections_destroy: nothing to destroy.
Analyse
Le message d'erreur semble provenir d'un problème de droits sur les fichiers. On peut vérifier que ce n'est pas le cas :
ls -l /opt/openldap/conf/data.d total 8 drwxr-x--- 3 openldap openldap 4096 Jan 3 21:08 cn=config -rw------- 1 openldap openldap 653 Jan 3 21:08 cn=config.ldif
Si on compare avec le paramétrage de l'instance par défaut (qui fonctionne), on constate que l'on a les mêmes droits :
ls -l /etc/ldap/slapd.d/ total 8 drwxr-x--- 3 openldap openldap 4096 Jan 3 21:07 cn=config -rw------- 1 openldap openldap 478 Jan 3 21:07 cn=config.ldif
La principale différence entre Debian et Ubuntu Server est l'utilisation de apparmor sur ce dernier O.S.
Et en listant le contenu du répertoire de configuration, il y a en effet un fichier de paramétrage pour slapd (le binaire utilisé par OpenLDAP).
ls /etc/apparmor.d/ abstractions disable local lxc-containers tunables usr.lib.snapd.snap-confine.real usr.sbin.slapd cache force-complain lxc sbin.dhclient usr.bin.lxc-start usr.sbin.rsyslogd usr.sbin.tcpdump
En regardant le contenu de ce fichier, on voit qu'il y a des restrictions sur les répertoires :
# ldap files /etc/ldap/** kr, /etc/ldap/slapd.d/** rw, .../... # the databases and logs /var/lib/ldap/ r, /var/lib/ldap/** rwk,
Résolution du problème
Pour résoudre le problème on a finalement 2 options :
- désactiver apparmor
- modifier le paramétrage apparmor pour autoriser notre fonctionnement.
Désactivation de apparmor pour slapd
On peut désactiver apparmor en utilisant aa-disable, qui est dans le package apparmor-utils :
sudo apt install apparmor-utils aa-disable slapd
Une fois ceci effectué, on peut alors démarrer l'instance, et vérifier qu'elle tourne :
ps -ef |grep slap openldap 840 1 0 12:28 ? 00:00:01 /usr/sbin/slapd -h ldap://:389/ -g openldap -u openldap -F /opt/openldap/conf/data.d -n slapddata
Modification du paramétrage apparmor
On peut aussi vouloir garder apparmor mais adapter la configuration. Pour ceci, 2 actions sont nécessaires :
- modification du fichier de paramétrage local
- recharger ou redémarrer la configuration de apparmor
Modifer le fichier /etc/apparmor.d/local/usr.sbin.slapd pour ajouter le paramétrage propre à notre configuration :
# Site-specific additions and overrides for usr.sbin.slapd. # For more details, please see /etc/apparmor.d/local/README. # # Custom configuration # ldap configuration files /opt/openldap/** kr, /opt/openldap/conf/** rw, # the databases and logs /opt/openldap/db/ r, /opt/openldap/db/** rwk,
Note : ne pas oublier la virgule sur la dernière ligne. Sans cela apparmor ne validera pas la configuration.
Puis on recharge :
systemctl reload apparmor
On peut alors relancer notre instance, et vérifier qu'elle fonctionne :
/usr/sbin/slapd -h 'ldap://:389/ ' -g openldap -u openldap -F /opt/openldap/conf/data.d -n slapddata ps -ef |grep slapd openldap 1360 1 0 12:45 ? 00:00:00 /usr/sbin/slapd -h ldap://:389/ -g openldap -u openldap -F /opt/openldap/conf/data.d -n slapddata
Conclusion
Les messages d'erreurs sont parfois succincts. Dans le cas où il est difficile d'expliquer un souci de droits d'accès, il est intéressant de vérifier si les mécanismes de sécurité des O.S. (apparmor ou selinux) n'imposent pas des contraintes sur les emplacements des fichiers.
Le même genre de souci peut arriver avec une base mysql / mariadb. Par défaut, les nouvelles versions de MariaDB désactivent apparmor.
cat /etc/apparmor.d/usr.sbin.mysqld usr.sbin.mysqld # This file is intensionally empty to disable apparmor by default for newer # versions of MariaDB, while providing seamless upgrade from older versions # and from mysql, where apparmor is used. # # By default, we do not want to have any apparmor profile for the MariaDB # server. It does not provide much useful functionality/security, and causes # several problems for users who often are not even aware that apparmor # exists and runs on their system. ...