En révisant le support de travaux pratiques sur
l'introduction aux annuaires LDAP avec OpenLDAP, j'ai perdu
un certain tempsavant de pouvoir traiter la partie sur
l'analyse de la configuration du service LDAP. Relativement à l'édition précédente, les versions du paquet source
openldapont évolué et un petit détail sur la résolution des noms m'avait échappé. Bien sûr, me direz-vous, dans la vraie vie tout le monde installe son service LDAP en ayant préalablement validé que le serveur est connu du service DNS. Eh bien, pas moi ! Dans un contexte de travaux pratiques, on cherche à isoler les services les uns des autres de façon à ne traiter qu'un seul problème bien identifié à la fois. Voyons donc comment on peut se fourvoyer facilement et quelle démarche aurait pu être suivie d'entrée de jeu.
Au début, il était question d'authentification ...
Pour valider les questions et les réponses du TP, on configure de façon très classique deux instances de machines virtuelles avec le système de base et le service SSH en
Debian/testing: un serveur et un client. On effectue les mises à jour et on renomme les machines. On obtient avec la topologie suivante :
|eth0
_|____
(_______) noyau
|Routeur| <-- système hôte
(_______)
|br0 @IP: 198.51.100.1
___|______
| | <-- openvswitch
`-.------.-'
|tap0 |tap1
| --'.
| |' |hostname : vm-ldap-client
| |. |@IP : 198.51.100.3
--'. `--'
|' |hostname :
vm-ldap-server
|. |@IP : 198.51.100.2
`--'
Après installation des deux paquets
slapdet
ldap-utilssur le serveur, on teste l'accès à la configuration.
Traitement des actions différées (« triggers ») pour « man-db »...
Paramétrage de libltdl7:amd64 (2.4.2-1.1) ...
Paramétrage de libodbc1:amd64 (2.2.14p2-5) ...
Paramétrage de libperl5.14 (5.14.2-13) ...
Paramétrage de libslp1 (1.2.1-9) ...
Paramétrage de slapd (2.4.31-1) ...
Creating new user openldap... done.
Creating initial configuration... done.
Creating LDAP directory... done.
[ ok ] Starting OpenLDAP: slapd.
Paramétrage de ldap-utils (2.4.31-1) ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
Total disk space freed by localepurge: 0 KiB
# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" dn
ldap_sasl_interactive_bind_s: Local error (-2)
Eh paf ! C'est à partir de là que les choses ont mal tourné. Je me suis focalisé sur l'authentification SASL et non sur la partie
interactive_bind_sdu message. Pourtant, cette instruction est bien celle préconisée dans le fichier de documentation du paquet
slapd:
/usr/share/doc/slapd/README.Debian.gz
Je me suis lancé dans la configuration de l'authentification SASL avec le paquet
sasl2-binet le mécanisme PAM pour authentifier les utilisateurs locaux dont le super-utilisateur qui doit avoir accès sans restriction à la configuration du ou des annuaires LDAP configurés sur le serveur. Bien que cette authentification soit fonctionnelle, j'obtenais toujours le même message d'erreur. La situation était bloquée. Pas moyen de modifier le DIT.
À la fin, il n'était plus question que de résolution des noms
Au lieu de m'enfermer dans cette voie sans issue, j'aurais dû commencer par faire appel à
strace.
# strace ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" dn
<snipped>
recvfrom(4, "h4\201\203\0\1\0\0\0\1\0\0\16vm-ldap-server\0\0\34\0\1"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("198.51.100.1")}, [16]) = 107
gettimeofday({1348409171, 770189}, NULL) = 0
poll([{fd=4, events=POLLIN}], 1, 4998) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [107]) = 0
recvfrom(4, "6\361\201\203\0\1\0\0\0\1\0\0\16vm-ldap-server\0\0\1\0\1"..., 1941, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("198.51.100.1")}, [16]) = 107
close(4) = 0
write(2, "ldap_sasl_interactive_bind_s: Lo"..., 47
ldap_sasl_interactive_bind_s: Local error (-2)
) = 47
write(3, "0\5\2\1\1B\0", 7) = 7
close(3)
Voici à nouveau le message d'erreur consécutivement à une transaction réseau avec des sockets. Mais que diable vient faire cette requête réseau dans une manipulation locale au système ? On passe donc à l'analyse réseau sur le système hôte ; celui avec l'adresse IP 198.51.100.1.
# tshark -i br0 ! port 22
tshark: Lua: Error during loading:
[string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled
Running as user "root" and group "root". This could be dangerous.
Capturing on br0
0.000000 198.51.100.2 -> 198.51.100.1 DNS 74 Standard query 0x6213 A vm-ldap-server
0.000266 198.51.100.1 -> 198.51.100.2 DNS 149 Standard query response 0x6213 No such name
0.016816 198.51.100.2 -> 198.51.100.1 DNS 74 Standard query 0x2cd4 A vm-ldap-server
0.016885 198.51.100.2 -> 198.51.100.1 DNS 74 Standard query 0x28a4 AAAA vm-ldap-server
0.017050 198.51.100.1 -> 198.51.100.2 DNS 149 Standard query response 0x28a4 No such name
0.017110 198.51.100.1 -> 198.51.100.2 DNS 149 Standard query response 0x2cd4 No such name
Bingo ! la requête locale sur le DIT de l'annuaire à besoin de connaître la correspondance entre nom et adresse IP. On se jette sur l'édition du fichier
/etc/hostsdans lequel on donne l'information manquante.
# head -4 /etc/hosts
127.0.0.1 localhost
127.0.1.1 vm-ldap-server
198.51.100.2 vm-ldap-server
Ouf ! Une nouvelle exécution de la commande
ldapsearchne produit plus d'erreur et on peut enfin modifier le DIT de l'annuaire.
# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" dn
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: dn
#
<snipped>
# search result
search: 2
result: 0 Success
# numResponses: 12
# numEntries: 11
En guise de conclusion
C'est une nouvelle petite leçon d'humilité. On s'imagine être expérimenté et on se fait attraper comme un débutant sur un détail insignifiant en apparence.
Maintenant, pour rebondir sur le billet intitulé
7 astuces pour rapporter les bogues Debian efficacement et voir vos problèmes résolus, est-ce que le problème que je viens de rencontrer mérite un rapport de bug ? Il m'est déjà arrivé dans le passé d'émettre des rapports qui ont fait flop. Ils étaient soit hors sujet (#616487), soit sans aucun intérêt.
