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.

...