Impossible d'atteindre le serveur LDAP

Bonjour à tous !

Voilà plusieurs semaines que je me suis lancé dans une installation yuhohost. C’est super, joli, pratique et concis mais assez compliqué pour moi. Je cherche, fouine, chine et arrive souvent à trouver la solution à mes problèmes, mais là, je sèche. Si une âme charitable pouvez me donner un coup de main, il recevrait de ma part ma reconnaissance éternelle :blush:
DONC

Impossible d’atteindre le serveur LDAP, message d’erreur lorsque j’essaie de me connecter en tant qu’admin. Sur le portail utilisateur, aucun de mes identifiants ne fonctionne : “Nom d’utilisateur ou mot de passe incorrect”. Je n’ai pourtant rien changé et le reboot ne donne rien. Il n’y a que mon blog wordpress qui m’est accessible.

En passant par la console, yunohost user list donne

root@raspberrypi:~# yunohost user list
Erreur : Impossible d'atteindre le serveur LDAP
Exception AttributeError: "'Authenticator' object has no attribute 'con'" in bound method Authenticator.__del__ of moulinette.authenticators.ldap.Authenticator object at 0x1ba5d90>> ignored

Je suis allé voir du côté de ldap.py et consors, mais je ne comprends absolument pas. Si vous aviez une idée…

Merci de votre aide

Hello,

Çela peut être pas mal de choses :slight_smile:

Je pars de l’hypothese que ton installation de yunohost s’est bien déroulée.

Avant de pouvoir t’aider il faudrait que tu nous en dise plus :

  • Quel est on os et sa version (je fais l’hypothése que tu es sous debian jessie) ?
  • Le daemon slapd est-il bien en cours d’execution ? : ps -ef | grep slap et/ou pidof slapd et/ou /etc/init.d/slapd status
  • S’il est bien en cours d’execution, ecoute-t-il bien sur le port 389 : netstat -an | grep 389
  • Si les vérifs précédentes sont ok, ton firewall bloque-t-il l’acces au port 389 ? : iptables -vnL
  • Enfin, tu peux jeter un oeil au fichier de log /var/log/syslog. Dans une install yuno par défaut le daemon slapd log dans ce fichier (tu peux faire un grep sur la chaine ‘slapd’). Au besoin, ouvre 2 terminaux, dans un tu passes la commande tail -f /var/log/syslog et dans l’autre du arrêtes puis démarre slap. Cela te permettra de voir en live les eventuelles erreurs.

Je pense que c’est un bon début pour trouver ce qui ne fonctionne pas.

Dis nous.

A+

Merci pour ta réponse rapide bidroik!

  • j’ai une version wheezy

  • Effectivement, un rapide

    /etc/init.d/slapd start

m’a aidé a relancé le service. Et même après un reboot, le service se relance seul. Je ne sais pas ce qui s’est passé, mais cela me bloquait tout. Les solutions les plus simples sont parfois les meilleures.
Merci beaucoup. A+

C’est parfait :smile:

A+

Je déterre un peu la discussion car mon problème se radine en prenant une forme légèrement différente (le fourbe !). Le slapd is running ok, mais impossible d’atteindre le serveur LDAP.
Impossible de se connecter au portail yunohost. Il n’y a que mon blog qui soit disponible. De même pour l’interface admin qui me mets inlassablement

L'API ne répond pas (erreur : 502 Bad Gateway)

ainsi que

Erreur : Impossible d'atteindre le serveur LDAPException AttributeError: "'Authenticator' object has no attribute 'con'" in <bound method Authenticator.__del__ of <moulinette.authenticators.ldap.Authenticator object at 0x1525d50>> ignored

Du coup, impossible de faire d’update, d’upgrade ou quoi que ce soit d’autre.

Je précise que j’ai changé de box entretemps, mais j’ai normalement tout bien reconfiguré puisque j’ai l’accès distant, local, à mon blog+admin et jirafeau.

Merci de votre aide.

Vraiment personne, une idée ?

Hello,

C’est difficile à dire comme ça, il va falloir que tu trouves des pistes dans les logs de ton systeme.

L’erreur que tu mentionnes est inscrite sur la page web quand tu tentes de te connecter sur le portail ?
Si oui, serait-ce juste un probleme avec l’api web ? As-tu essayé les commandes yunohost*.

Connecte toi sur ton serveur en ssh (en root) puis essayes une commande du style : yunohost user list

Que te renvoie cette commande ? la liste des user yuno ou une erreur ?

Jette un oeil au fichier /varlog/syslog et également aux fichiers de log présents dans /var/log/yunohost.

C’est un travail d’enquête et les indices se trouvent dans ton systeme :smile:

A+

D’accord, merci pour les infos.
Le problème est que j’ai déjà effectué certaines tâches que tu me conseilles de faire, sans en connaître réellement les significations, et donc sans savoir si les résultats sont pertinents ou non (comme ps -ef | grep)

Mon [OK] Slapd is running

La 1ère erreur (L’API ne répond pas) est effectivement affichée sur la page web admin yunohost.
La 2ème apparaît dans mon terminal quand je fais certaines manip du genre update, upgrade et notamment yunohost user list

Je vais étudier les fichiers log que je ne connais pas du tout et voir si je peux en déduire quelque chose.
Merci encore.

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

Super, merci pour les tuyaux.

Je m’y emploie de suite et poste mes résultats/avancés(/échecs?).

Bon, j’ai enfin réussi à trouver du temps pour m’y (re)mettre. Et t’inquiètes pas pour les accents et fautes d’orthographes, on les voit pas !
J’ai donc repris ton post point par point, et voilà ce qu’il en résulte :

  • Le service LDAP est bien en cours d’exécution :

    ~# ps -ef | grep slapd
    openldap 2798 1 0 nov.18 ? 00:00:03 /usr/sbin/slapd -h ldap://127.0.0.1/ ldapi://127.0.0.1/ -g openldap -u openldap -f /etc/ldap/slapd.conf
    root 30603 30586 0 13:33 pts/0 00:00:00 grep slapd

Au passage, à quoi correspond le numéro, j’ai pas le même ça doit être normal ?

  • Le service LDAP écoute bien sur un port :

(LISTEN). Mais c’est tout. Pas de (ESTABLISHED) ou autre. Voici :

~# lsof -i4 | grep ldap
slapd      2798            openldap    8u  IPv4     8017      0t0  TCP 127.0.0.1:ldap (LISTEN)
  • Je vérifie alors mon firwall

     ~# iptables -vL
    

    Chain INPUT (policy DROP 281K packets, 33M bytes)
    pkts bytes target prot opt in out source destination
    14072 2191K fail2ban-yunohost tcp – any any anywhere anywhere multiport dports http,https
    14072 2191K fail2ban-nginx tcp – any any anywhere anywhere multiport dports http,https
    65143 3423K fail2ban-dovecot tcp – any any anywhere anywhere multiport dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
    65143 3423K fail2ban-sasl tcp – any any anywhere anywhere multiport dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
    54235 2352K fail2ban-postfix tcp – any any anywhere anywhere multiport dports smtp,ssmtp
    393 19924 fail2ban-ssh tcp – any any anywhere anywhere multiport dports ssh
    19M 1090M ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
    15447 742K ACCEPT tcp – any any anywhere anywhere tcp dpt:smtp
    15 716 ACCEPT tcp – any any anywhere anywhere tcp dpt:domain
    449 22944 ACCEPT tcp – any any anywhere anywhere tcp dpt:http
    688 40028 ACCEPT tcp – any any anywhere anywhere tcp dpt:https
    9 476 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssmtp
    85 4988 ACCEPT tcp – any any anywhere anywhere tcp dpt:imaps
    2 104 ACCEPT tcp – any any anywhere anywhere tcp dpt:xmpp-client
    0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:xmpp-server
    0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:5290
    908 48724 ACCEPT tcp – any any anywhere anywhere tcp dpt:51413
    4 240 ACCEPT tcp – any any anywhere anywhere tcp dpt:9876
    3825K 220M ACCEPT udp – any any anywhere anywhere udp dpt:domain
    0 0 ACCEPT udp – any any anywhere anywhere udp dpt:openvpn
    1178 70680 ACCEPT all – lo any anywhere anywhere
    0 0 ACCEPT icmp – any any anywhere anywhere

    Chain FORWARD (policy ACCEPT 1072 packets, 275K bytes)
    pkts bytes target prot opt in out source destination

    Chain OUTPUT (policy ACCEPT 22M packets, 1319M bytes)
    pkts bytes target prot opt in out source destination

    Chain fail2ban-dovecot (1 references)
    pkts bytes target prot opt in out source destination
    65143 3423K RETURN all – any any anywhere anywhere

    Chain fail2ban-nginx (1 references)
    pkts bytes target prot opt in out source destination
    14072 2191K RETURN all – any any anywhere anywhere

    Chain fail2ban-postfix (1 references)
    pkts bytes target prot opt in out source destination
    54235 2352K RETURN all – any any anywhere anywhere

    Chain fail2ban-sasl (1 references)
    pkts bytes target prot opt in out source destination
    65143 3423K RETURN all – any any anywhere anywhere

    Chain fail2ban-ssh (1 references)
    pkts bytes target prot opt in out source destination
    393 19924 RETURN all – any any anywhere anywhere

    Chain fail2ban-yunohost (1 references)
    pkts bytes target prot opt in out source destination
    14072 2191K RETURN all – any any anywhere anywhere

Comprends pas…

  • Puis-je communiquer avec mon serveur LDAP ? Aucune idée

    ~# ldapsearch -LLL -D cn=admin,dc=yunohost,dc=org -W -b dc=yunohost,dc=org uid=
    Enter LDAP Password:
    ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

Impossible donc de rentrer mon mot de passe.

  • Et pour finir, impossible d’afficher mon /var/log/syslog :

    ~# nano /var/log/syslog
    Procéssus arrêté

Incompréhensible. Les autres fichiers log sont affichables.

Si je comprends bien et pour résumer, je n’ai pas de communication avec le service ldap qui est pourtant bien en cours d’exécution.

Merci de vos réponses

Hello,

Bien, bel effort pour les infos :smile: on va pouvoir t’aider un peu plus.

Je suppose que tu parles du “2798” ? Si oui il s’agit de l’id du processus qui référence ton serveur ldap, on dit “pid”. Et oui c’est normal qu’il ne s’agisse pas du même numéro que moi. Cela dit le hasard aurait pu faire que nous ayons le même, c’est le noyau qui “choisit” le pid.

Cool il est là et écoute sur le bon port.

Concernant tes régles de firewall, as-tu vraiment taper l’option “v” ? Le soucis c’est que sans cette option on ne voit pas les interfaces. Ce qui nous interresse ici serait de voir les régles pour l’interface “lo” (127.0.0.1). Pourrais-tu repasser cette commande en t’assurant de bien mettre l’option “v” (avant le L, sinon ça foire).
La politique par défaut de la chaine input est DROP (c’est bien !) mais on voit que le compteur est élevé (33Mo dropé) ce compteur ne représente pas forcement les paquets vers ton serveur ldap mais il se pourrait qu’on soit sur une piste sérieuse.

Ça c’est cool aussi, ton serveur est éxécuté et une requête avec les outils de base ldap indique que la communication avec le serveur est en échec. Nous sommes maintenant quasi certain que la couche logiciel yunohost n’y est pour rien.

Normal, tant mieux, dans le cas contraire tu aurais pu avoir un soucis de mot de passe ou de compte et l’erreur aurait été différente.

Pour l’ouverture du fichier syslog, là c’est déjà beaucoup plus étonnant. Perso je n’utilise jamais nano et rarement un programme qui ouvre un fichier de log en édition. Il se peut que ton fichier de log contiennent des caracteres que nano ne gere pas ou que ton fichier de log est corrompu (ce serait étonnant et à ce moment tu vas avoir d’autres ennuis avec ta machine :))

Pour ce fichier de log donne nous la sortie de la commande file /var/log/syslog. Cette commande renvoi le type de fichier.

Donne nous également la sortie de la commande ls -lh /var/log/syslog, ceci juste pour voir la taille de ce fichier.

Accessoirement, vérifie que ton espace disque est ok : df -h (selon ton partionnement, /var peut être une partition séparée ou être localisé sur la racine directemenent (/))

Essaies ensuite de l’ouvrir avec un autre programme, je te conseille la commande less et dis nous si c’est ok.

Si tu ne réussis toujours pas à ouvrir ce fichier de log, tu peux tenter de relancer le service de logging. Je ne pense pas t’avoir demandé quel est ton systeme d’exploitation (debian ?) et quelle version (7 ou 8, wheezy ou jessie).
Je suis sous jessie et il s’agit de rsyslogd. Si tu es également sous jessie tu peux tenter un systemctl restart rsyslog.service.

Dis nous déjà ce que tu as en passant toutes ces commandes et on avisera.

Bon courage.

A+

Toutes mes excuses, je t’ai dis une connerie, on voit bien la régle pour l’interface “lo” :

C’est juste que l’affichage n’est pas terrible et j’ai loupé cette ligne. Du coup, c’est ok, pas de restriction du coté du firewall. Continues de creuser les fichier de log et je réfléchi de mon coté à ce qu’on pourrait tester.

A+

Tu plaisantes ? Merci à TOI pour tes efforts !! T’es un rapide !

Alors pour :

Ca donne :

~# file /var/log/syslog 
/var/log/syslog: ASCII text, with very long lines

Et pour :

Ca donne :

~# ls -lh /var/log/syslog 
-rw-r----- 1 root adm 2,4G déc.   2 11:48 /var/log/syslog

Et enfin :

df -h
Sys. fich.     Taille Util. Dispo Uti% Monté sur
/dev/root         29G   13G   16G  46% /
devtmpfs         119M     0  119M   0% /dev
tmpfs             25M  300K   25M   2% /run
tmpfs            5,0M     0  5,0M   0% /run/lock
tmpfs             49M     0   49M   0% /run/shm
/dev/mmcblk0p1    48M   20M   29M  41% /boot
/dev/sda1        917G  272M  870G   1% /storage/
tmpfs             49M     0   49M   0% /tmp

Pour ça, j’ai compris que j’étais large en terme de place.

Quant aux logs, je ne savais pas qu’il fallait utiliser less. Du coup, ça marche mieux avec… :confused:
J’en profite pour confirmer ma version : 7.8 Wheezy.

Voici donc la dernière page de mon log :

Dec  2 11:52:50 raspberrypi postfix/cleanup[9548]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:50 raspberrypi postfix/cleanup[9548]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:50 raspberrypi postfix/cleanup[9548]: warning: B271917CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:51 raspberrypi postfix/pickup[3049]: warning: BAC3717CED: message has been queued for 27 days
Dec  2 11:52:51 raspberrypi postfix/pickup[3049]: BAC3717CED: uid=0 from=<root>
Dec  2 11:52:51 raspberrypi postfix/cleanup[9549]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:51 raspberrypi postfix/cleanup[9549]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:51 raspberrypi postfix/cleanup[9549]: warning: BAC3717CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:52 raspberrypi postfix/pickup[3049]: warning: BFEC517CED: message has been queued for 29 days
Dec  2 11:52:52 raspberrypi postfix/pickup[3049]: BFEC517CED: uid=0 from=<root>
Dec  2 11:52:52 raspberrypi postfix/cleanup[9548]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:52 raspberrypi postfix/cleanup[9548]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:52 raspberrypi postfix/cleanup[9548]: warning: BFEC517CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:53 raspberrypi postfix/pickup[3049]: warning: C4F5D17CED: message has been queued for 28 days
Dec  2 11:52:53 raspberrypi postfix/pickup[3049]: C4F5D17CED: uid=0 from=<root>
Dec  2 11:52:53 raspberrypi postfix/cleanup[9549]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:53 raspberrypi postfix/cleanup[9549]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:53 raspberrypi postfix/cleanup[9549]: warning: C4F5D17CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:54 raspberrypi postfix/pickup[3049]: warning: CA07817CED: message has been queued for 25 days
Dec  2 11:52:54 raspberrypi postfix/pickup[3049]: CA07817CED: uid=0 from=<root>
Dec  2 11:52:54 raspberrypi postfix/cleanup[9548]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:54 raspberrypi postfix/cleanup[9548]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:54 raspberrypi postfix/cleanup[9548]: warning: CA07817CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:55 raspberrypi postfix/pickup[3049]: warning: CF94F17CED: message has been queued for 23 days
Dec  2 11:52:55 raspberrypi postfix/pickup[3049]: CF94F17CED: uid=0 from=<root>
Dec  2 11:52:55 raspberrypi postfix/cleanup[9549]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)
Dec  2 11:52:55 raspberrypi postfix/cleanup[9549]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "root@jessijo.nohost.me"
Dec  2 11:52:55 raspberrypi postfix/cleanup[9549]: warning: CF94F17CED: virtual_alias_maps map lookup problem for root@jessijo.nohost.me -- deferring delivery
Dec  2 11:52:56 raspberrypi postfix/pickup[3049]: warning: D57E417CED: message has been queued for 29 days

Je vois bien les messages d’erreurs mais là je sèche ? Je vais demander à L’apôtre google.

Pas de quoi, d’autant que tu y mets également de la bonne volonté, du coup c’est agréable de te filer un coup de main. Apres faut esperer que ça aboutisse à la compréhension du présent probleme :slight_smile:

Donc, c’est bien un fichier texte. En revanche ton fichier est énorme. Je pense que c’est la raison pour laquelle nano a planté. Soit ton systeme log beaucoup soit la rotation de tes logs ne fonctionne comme attendu.

L’utilisation de less est une affaire de gout et d’habitude essentiellement. J’ai des collegues qui lisent les logs avec vi. Maintenant, j’aime ce programme pour 2 raisons : 1/ je n’aime parcourir un fichier de log en l’ouvrant en lecture/ecriture, 2/ je suis certain que less ne bouffera pas toute la ram de ma machine si le fichier est trés gros (comme dans ton cas :))

J’ai vu également que tu n’as pas de soucis d’espace disque, bonne nouvelle.

Dans l’extrait de log que tu fournis, on ne voit pas de ligne correspondant au service ldap. Il faudrait que tu filtre les lignes de ce fichier de log. Essaies la commande suivante grep slapd /var/log/syslog.
Attention la sortie peut être longue, si c’est le cas tu “pipe” ta commande sur less : grep slapd /var/log/syslog | less

Si tu souhaites conserver la sortie de la commande, renvoie la dans un fichier, par exemple : grep slapd /var/log/syslog > /tmp/slapd_log_from_syslog.txt.

Je ne pense pas que tu trouves ton bonheur car dans ce qu’on voit des tes logs, c’est le service de messagerie postfix qui rencontre les mêmes problemes que toi, à savoir, joindre le ldap.
C’est d’ailleurs peut être postfix qui “pourri” ton fichier de log. C’est une piste à explorer, postfix sature-t-il ton systeme au point que le ldap ne réponde pas ? ou bien postfix perd les pédales parce que ldap ne répond plus ?

Un truc à essayer est d’arrêter postfix pour refaire des tests de connexion au ldap. Tu dois avoir un script d’init nommé “postfix” dans /etc/init.d. Tu peux l’arrêter avec la commande /etc/init.d/postfix stop. Une fois arrêté, essaie de voir si ton ldap est joignable. Pour relancer postfix : /etc/init.d/postfix start.

Je crois comprendre que tu es sur un raspberrypi. Je suppose que la distrib installée est une raspbian. Il s’agit donc d’une debian mais je ne connais pas raspbian et il est possible que je loupe quelque chose du à une particularité qui m’échapperai.

Si jamais tu souhaites poster une grande quantité d’information qui ne tiendrai pas dans cette conversation, n’hésites pas à utiliser le service de debian : http://paste.debian.net/

Tiens nous au jus.

A+

Effectivement, 2.4G je me doutais que ça faisait un peu beaucoup.

En faisant

cela me retourne effectivement un gros fichier. Mais impossible d’atteindre la fin du fichier. il me mets “processus arrêté”

Ca me retourne une erreur :

~# grep slapd /var/log/syslog > /tmp/slapd_log_from_syslog.txt
grep: erreur en écriture

Quant à google, effectivement rien de concluant. En plus en anglais…

J’ai ensuite arrêté postfix, mais mon ldap reste injoignable.
Je suis bien sur raspberry debian Wheezy avec install yunohost. Cela marchait bien jusqu’à présent et depuis mon retour de vacances, plus rien. Impossible de se connecter. C’est grave docteur ?

Mouais, ton systeme me semble bien dans les chous, probleme mémoire ? Je suppose qu’un rasp ne possede pas beaucoup de mémoire. Tu peux toujours zieuter ta ram avec un free -m cela va t’afficher la mémoire en Mo, chez moi ça donne ça :

 # free -m
             total       used       free     shared    buffers     cached
Mem:          1941       1729        211         61        167       1000
-/+ buffers/cache:        561       1380
Swap:         3956          0       3956

Si ta “swap used” elevé + “Mem free” bas + “Mem cached” bas = pas bon

Les erreurs que tu rencontres avec tes grep me laisse penser que c’est ça. Si c’est autre chose ça va être tendu de deviner ce que c’est.

On peut tenter qqchose :

  1. Arrêter le plus de service possible. Je ne sais pas s’il existe une commande qui arrête tous les services de yunohost
  2. Forcer une rotation de ton syslog
  3. Redémarrer ta machine
  4. Essayer à nouveau de choper les logs de slapd dans ton syslog archivé

La commande yunohost service status liste tous les services yuno démarré. Repere ceux qui sont en état “running” et pour chacun d’eux tu passes la commande yunohost service stop <service>

Pour forcer la rotation de ton syslog tu dois avoir la configuration dans /etc/logrotate.d/rsyslog. Pour forcer la rotation tu passes la commande logrotate -v -f /etc/logrotate.d/rsyslog. Le “-v” ne sert qu’à afficher plus d’infos pendant l’execution de la commande. Honnetement j’ai un peu peur que ça plante comme tes grep mais ça se tente. Penses bien a arrêter les services yuno auparavant (pour gagner de la ram et éviter les écritures dans syslog).

Redémarre ta machine. Dans le cas ou la rotation a plantée, redemarre et essaie à nouveau.

Si la rotation a fonctionné, essaies de voir direct si ldap répond. Que ça fonctionne ou pas il faudrait piger ce qu’il se passe. Apres rotation, dans /var/log, tu vas avoir des archives de tes fichiers syslog. A priori celui en cours d’utilisation ne donnera pas d’infos, il faut chercher dans les archives.

Voila comment tu trouveras tes archives. Passe la commande ls -ltrh /var/log/syslog*. Chez moi ça donne :

 # ls -ltrh /var/log/syslog*
-rw-r----- 1 root adm  16K Nov 26 06:27 /var/log/syslog.7.gz
-rw-r----- 1 root adm  29K Nov 27 06:34 /var/log/syslog.6.gz
-rw-r----- 1 root adm  30K Nov 28 06:41 /var/log/syslog.5.gz
-rw-r----- 1 root adm  41K Nov 29 06:47 /var/log/syslog.4.gz
-rw-r----- 1 root adm  36K Nov 30 06:50 /var/log/syslog.3.gz
-rw-r----- 1 root adm  18K Dec  1 06:26 /var/log/syslog.2.gz
-rw-r----- 1 root adm 315K Dec  2 06:39 /var/log/syslog.1
-rw-r----- 1 root adm 274K Dec  2 23:19 /var/log/syslog

Chez toi, c’est le fichier “syslog.1” qui nous interresse (il devrait peser les 2,4Go). Essaies de nouveau les grep. Si tu as les mêmes erreurs … bah c’est chaud :slight_smile: … on trouvera une astuce.

Bon je sais pas trop mais voici mon free -m

~# free -m
total       used       free     shared    buffers     cached
Mem:           244        225         19          0          6        102
-/+ buffers/cache:        115        129
Swap:            0          0          0

Ok pour les services je ne laisse donc que slapd d’actif ?
Les voici :

    root@raspberrypi:~# yunohost service status
glances: 
  status: running
  loaded: enabled
metronome: 
  status: running
  loaded: enabled
tahoe-lafs: 
  status: inactive
  loaded: disabled
postfix: 
  status: inactive
  loaded: enabled
transmission-daemon: 
  status: running
  loaded: enabled
openvpn: 
  status: inactive
  loaded: enabled
postgrey: 
  status: inactive
  loaded: enabled
nginx: 
  status: running
  loaded: enabled
shellinabox: 
  status: running
  loaded: enabled
ssh: 
  status: running
  loaded: enabled
yunohost-api: 
  status: running
  loaded: enabled
mysql: 
  status: running
  loaded: enabled
dovecot: 
  status: running
  loaded: enabled
bind9: 
  status: inactive
  loaded: enabled
php5-fpm: 
  status: running
  loaded: enabled
xbmc: 
  status: inactive
  loaded: enabled
slapd: 
  status: running
  loaded: enabled

En revanche, qu’est-ce que c’est une rotation ? Je vais tester tout ça.

Bon, la rotation a apparemment bien marché.

Je sais pas si c’est interessant mais voici mon syslog (pas le 2.4G, le dernier à 1.1M) :

Dec  3 21:00:30 raspberrypi slapd[17843]: daemon: shutdown requested and initiated.
Dec  3 21:00:30 raspberrypi slapd[17843]: slapd shutdown: waiting for 0 operations/tasks to finish
Dec  3 21:00:30 raspberrypi slapd[17843]: slapd stopped.
Dec  3 21:03:57 raspberrypi slapd[2807]: @(#) $OpenLDAP: slapd  (Apr  2 2015 01:44:57 $#012#011root@plugwash.raspbian.lan:/openldap-2.4.31/debian/build/servers/slapd
Dec  3 21:04:11 raspberrypi slapd[2809]: slapd starting
Dec  3 21:05:17 raspberrypi slapd[2809]: conn=1000 fd=12 ACCEPT from IP=127.0.0.1:52385 (IP=127.0.0.1:389)
Dec  3 21:05:17 raspberrypi slapd[2809]: conn=1000 op=0 SRCH base="dc=yunohost,dc=org" scope=2 deref=2 filter="(&(objectClass=inetOrgPerson)(|(mail=joe@jessijo.nohost.me)(mail=@jessijo.nohost.me)(mail=@.jessijo.nohost.me)(mail=@.nohost.me)(mail=@.me)(mail=@.)))"
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:17 raspberrypi slapd[2809]: conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
Dec  3 21:05:19 raspberrypi slapd[2809]: conn=1001 fd=17 ACCEPT from IP=127.0.0.1:52387 (IP=127.0.0.1:389)
Dec  3 21:05:19 raspberrypi slapd[2809]: conn=1001 op=0 SRCH base="dc=yunohost,dc=org" scope=2 deref=2 filter="(&(objectClass=inetOrgPerson)(|(mail=joe@jessijo.nohost.me)(mail=@jessijo.nohost.me)(mail=@.jessijo.nohost.me)(mail=@.nohost.me)(mail=@.me)(mail=@.)))"
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:19 raspberrypi slapd[2809]: conn=1001 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
Dec  3 21:05:49 raspberrypi slapd[2809]: conn=1000 op=1 SRCH base="dc=yunohost,dc=org" scope=2 deref=2 filter="(&(objectClass=inetOrgPerson)(|(mail=joe@jessijo.nohost.me)(mail=@jessijo.nohost.me)(mail=@.jessijo.nohost.me)(mail=@.nohost.me)(mail=@.me)(mail=@.)))"
Dec  3 21:05:49 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed
Dec  3 21:05:49 raspberrypi slapd[2809]: <= bdb_equality_candidates: (mail) not indexed

Ensuite

~# ls -ltrh /var/log/syslog*
-rw-r----- 1 root adm 2,5G déc.   3 20:59 /var/log/syslog.1
-rw-r----- 1 root adm 1,1M déc.   3 21:22 /var/log/syslog

Par contre pour la suite, je ne comprends pas. Je fais grep slapd /var/log/syslog.1 | lessmais ensuite ? Au moins maintenant, j’atteins la fin du fichier.
Quand je tente un yunohost tools upgrade, j’ai toujours mon message d’erreur :

Erreur : Impossible d'atteindre le serveur LDAP

J’ai refait free -m, mais toujours pareil. Les services sont relancés, c’est normal ? Je ne sais absolument pas quoi faire, désolé.

Hello,

Bon c’est pas mal tout ça, les manips fonctionnent, la rotation du syslog a fonctionné. Sur ce point, et d’apres le “ls” il semble que ton systeme ne fait aucune rotation des logs. Une rotation c’est ce qui permet d’archiver des fichiers de log et d’éviter d’avoir des fichiers de logs énormes. En régle général tu n’as pas besoin de conserver un historique de log trop important. Ce qu’il s’est produit sur ta machine il y plusieurs semaines/mois n’a pas d’intêret. Mais ce n’est pas le sujet.

Je n’ai pas compris un truc, as-tu redémarré ton raspberry ? je pense que oui mais je voulais être sur.

Pour la mémoire, rien à signaler ne t’occupe pas de ça, je voulais juste avoir un oeil sur cet élément et c’est ok.

Bah pas trop :smile: On cherche des informations sur le comportement du ldap. C’est dans l’historique qu’on peut espérer trouver quelque chose.

Le service ldap va écrire dans syslog avec le préfixe “slapd”. Les erreurs comme les informations lambda. L’idée est d’extraire ces messages préfixés par “slapd” et d’en trouver un qui semble être une erreur. les message du type “…bdb_equality_candidates: (mail) not indexed…” ne sont pas interressant (à ce stade en tous cas). Tu peux donc réduire les éléments en utilisant la commande suivante : grep slapd /var/log/syslog.1 | grep -v 'not indexed' > /tmp/slapd_msg_from_syslog.txt

Quoi faire de ces messages ? utilise le site que je t’ai donné en lien sur un post précédent pour copier le contenu de “slapd_msg_from_syslog.txt”. S’il y a trop de chose dans ce fichier, fais un tri pour ne donner que ce qu’il te semble être une erreur.

Sinon, dans l’extrait que tu as donné, tout semble normal. Le ldap semble fonctionner normalement … désolé … Faut maintenant voir si tu trouves autre chose dans le “syslog.1”.

Si tu as redémarré ta machine, oui, c’était l’objectif, un redémarrage propre de tous les services.

Je ne te cache que je suis un peu sec. Il y a surement un truc tout con qui parasite ton systeme, la difficulté est de mettre le doigt dessus.

On peut encore essayer un truc mais je n’y crois pas. Admettons que ta config firewall empêche la connexion. On va modifier momentanement les connexions entrantes. C’est déconseillé mais au point ou on en est.

Donc :

  1. On laisse tout rentrer : iptables -P INPUT ACCEPT
  2. Tu testes le ldap en executant la requête ldap d’un des premiers post : dapsearch -LLL -D cn=admin,dc=yunohost,dc=org -W -b dc=yunohost,dc=org uid=<moncompte>
  3. Que ça fonctionne ou pas tu refermes le firewall : iptables -P INPUT DROP

Essaies de nous envoyer les logs et tente la petite procédure du dessus.

On verra pour la suite …

A+