Re,
Si tu n’es pas encore à l’aise avec les tâches d’administration systeme n’hésites pas à demander.
La commande ps -ef | grep slapd permet de lister tous les processus (avec la commande complete) de ton systeme et de filtrer les résultats (| grep slapd) qui correspondent à la chaine slapd.
Comme je vois les choses, ton enquête doit prendre en compte les éléments ci-dessous (non exhaustif probablement):
- L’erreur que ton rencontres dit
Impossible d'atteindre le serveur LDAPException AttributeError. Il semble que la moulinette yunohost cherche à joindre le serveur ldap sans y parvenir.
- Le serveur ldap est un service qui “écoute” les requêtes en “réseau” :
- Il faut contrôler que le service slapd est en cours d’execution (a priori ça c’est ok)
- Il faut contrôler qu’il écoute sur le port standrard (389)
- Il faut contrôler que ton firewall ne bloque pas la communication avec le service ldap
Si les points ci-dessus sont ok, on peut penser que ton systeme ne parasite pas le fonctionnement du service ldap. Il faut maintenant s’assurer qu’il n’y ait pas un probleme avec le service ldap lui même et la ce sont les logs qui vont pouvoir te donner les indices. Les éléments que tu trouveras dans ces logs ne sont pas forcement simple à interpréter, il va falloir user de logique et faire des hypothese en fonction de ce que tu y liras.
Ci-dessous, les commandes que je passerai sur mon systeme en cas d’erreur :
- Le serice ldap est en cours d’execution ? :
$ ps -ef | grep slapd
openldap 689 1 0 Nov11 ? 00:00:03 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
Oui, il est en cours d’execution
- Le service ldap ecoute sur le port 389 ? :
$ lsof -i4 | grep ldap
slapd 689 openldap 9u IPv4 12271 0t0 TCP *:ldap (LISTEN)
slapd 689 openldap 24u IPv4 515809 0t0 TCP localhost:ldap->localhost:34471 (ESTABLISHED)
auth 7869 dovecot 19u IPv4 515808 0t0 TCP localhost:34471->localhost:ldap (ESTABLISHED)
Oui il écoute sur le port ldap (LISTEN) (389) sur toutes les adresse ipv4 demon systeme (*) → premiere ligne.
Le serveur dovecot a établit une communication avec le service ldap en passant par l’adresse de loopback, port ldap, de mon systeme (localhost : 127.0.0.1) → deuxieme et troisieme ligne
- Mon firewall bloque les communication vers 127.0.0.1:389 ? :
Là, c’est plus complexe. La commande iptables vL va lister toutes tes régles de firewall. Si la commande précédente te montre des communications “ESTABLISHED” il n’est probablement pas necessaire de passer par cette étape. Néanmoins, passe la commande iptables puis essayes de voir si tous est ok pour l’interface lo et si tu as mis des régles spécifiques pour le port ldap dans les chaines INPUT et OUTPUT. Dans mon cas ça donne ceci : (pas de régle pour le port ldap)
- INPUT : 17945 5053K ACCEPT all – lo any anywhere anywhere
- OUTPUT : 17945 5053K ACCEPT all – any lo anywhere anywhere
Dans mon cas le traffic sur la loopback est autorisé dans tous les sens (je rappelle que je n’ai pas de régles spécifiques pour le port ldap/389).
- Puis-je communiquer avec mon serveur ldap ? :
L’idée ici est de passer une commande d’interrogation du ldap sans passer par la moulinette et de voir si tu obtiens une réponse. Je te propose de tenter de récupérer les informations de ton compte yunohost. Pour cela tu devras récupérer le mot de passe du compte admin (mot de passe d’administration initialisé lors de l’installation). Il te faut également le nom de ton compte yunohost.
La commande que je passe ici en exemple est : ldapsearch -LLL -D cn=admin,dc=yunohost,dc=org -W -b dc=yunohost,dc=org uid=<mon compte>
Cela donne ceci (j’ai volontairement masqué le nom reel de mon compte et de mon domaine) :
$ ldapsearch -LLL -D cn=admin,dc=yunohost,dc=org -W -b dc=yunohost,dc=org uid=toto
Enter LDAP Password: ← Tape ici ton password d’administration
dn: uid=toto,ou=users,dc=yunohost,dc=org
uid: toto
objectClass: mailAccount
objectClass: inetOrgPerson
objectClass: posixAccount
loginShell: /bin/false
uidNumber: 58273
displayName: toto yunoname
userPassword:: e0NSWVBUfSQxJFIwQ1dTVEg5JDd0L0xhc3dKNHlqUC5kN3BQelRySjE=
gidNumber: 58273
homeDirectory: /home/toto
sn: yunonamen
givenName: toto
maildrop: toto
cn: toto yunoname
mail: toto@yuno.dom
mail: root@yuno.dom
mail: admin@yuno.dom
mail: webmaster@yuno.dom
mail: postmaster@yuno.dom
mailuserquota: 500M
Dans le fichier de log /var/log/syslog on trouve ces quelques lignes lors de ma requête :
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 fd=30 ACCEPT from IP=[::1]:36618 (IP=[::]:389)
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=0 BIND dn="cn=admin,dc=yunohost,dc=org" method=128
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=0 BIND dn="cn=admin,dc=yunohost,dc=org" mech=SIMPLE ssf=0
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=0 RESULT tag=97 err=0 text=
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=1 SRCH base="dc=yunohost,dc=org" scope=2 deref=0 filter="(uid=toto)"
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 op=2 UNBIND
Nov 22 11:52:12 yunoserv slapd[689]: conn=1674 fd=30 close
S’il y avait eu une erreur, j’aurais probablement des informations sur cette erreur dans ce fichier de log.
Si, comme moi, tout est ok sur ces points de contrôle il ne te reste plus qu’a fouiller dans tes fichiers logs et penser à des tests qui pourraient êtres pertinents dans ton cas.
N’hésites pas à poster les résultats de ces test pour qu’on puisse t’aiguiller.
Bon courage.
A+
PS : si mon post vous pique les yeux c’est normal. Il manque des tas d’accents et il y a probablement pas de mal de fôtes d’autografes … désolé … la flemme de me relire
on va pouvoir t’aider un peu plus.
