Principe

Les données d'authentification (à savoir UID, login, mot de passe, répertoire personnel, date d'expiration, GID et groupes) sont stockées sur un serveur MySQL.

Lorsqu'un utilisateur veut se connecter sur un poste client, celui-ci ira vérifier l'authenticité de la personne, en vérifiera l'activation (non-expiration) et si tout va bien connectera la personne avec les bons UID, GID, homedir, etc.

• (parler de guia et Projet/GUIA/Greffons/NssMySQL)

Mise en place

Sur le serveur

1. Mettre en place un serveur MySQL accessible par IP depuis tous les postes clients devant utiliser l'authentification centralisée.

2. Créer une base qui contiendra les données d'authentification (par exemple authnss). Nous conseillons fortement l'utilisation du schéma prévu par le projet GUIA, disponible ici : http://trac.sn.auf.org/guia/browser/trunk/guia/noyau/greffons/NSSMySQL/bases/auth.sql

3. Mettre en place les données dans la base. Pour ce faire, tout dépend de votre organisation actuelle :
   • Si vous utilisez déjà un MySQL, le mieux est d'étudier l'adaptation du schéma de votre base actuelle ;
   • Si vous utilisez déjà un autre SGBD, regardez si vous ne pouvez pas en changer et passer à MySQL avec le schéma proposé ;

   • Si vous êtes déjà en NIS ou LDAP ou autre, étudier l'écriture d'un script de synchronisation que vous pourrez lancer soit de façon générale de temps en temps (via cron), soit plus finement lors de l'ajout, de la modification ou de la suppression d'un utilisateur.

Sur les clients

voir http://trac.sn.auf.org/auf-desktop/browser/trunk/auf-desktop/debian/postinst et le contenu de racine-gutsy/etc/

• installer libnss-mysql-bg¹ pour que la bibliothèque de résolution de nom (nss = name service switch) sache interroger MySQL.

• installer nscd pour éviter que le système sache cacher les données de connexion, afin d'éviter de faire des requêtes MySQL sans arrêt, et fasse tout planter...

Que faire lorsque "ça ne marche pas"

Attention !! Il ne faut pas confondre la phase d'authentification (libnss) avec l'accés aux fichiers (nfs). Si l'erreur se produit aprés l'authentification, et se présente sous quelquechose de la forme d'une petite fenêtre "Votre dossier personnel est censé être "/home/xxxx" mais il semble ne pas exister", c'est plutôt sur l'infrastructure nfs qu'il faudra se pencher.

Points à vérifier

Est-ce que le problème se pose pour tous les comptes ou pour quelques comptes seulement ?

• pour tous les comptes : vérifier l'infrastructure d'authentification en général (voir plus bas)
• pour tous les comptes, mais pas systématiquement : sans-doute une saturation du nombre de processus mysql
• certains comptes seulement : vérifier la configuration de ces comptes en particulier, dans la base mysql

Sur le serveur, vérifier les points suivants :

• mysql fonctionne-t-il ?

• La base/table d'authentification contient-elle un nombre d'entrées réaliste par rapport aux valeurs habituelles ?

nfs-dakar:~# mysql authnss -Be "select count(*) from users"
count(*)
1508

• Combien de processus actuellement utilisés sur le serveur, et est-ce cohérent avec la variable max_connections dans le /etc/mysql/my.cnf ?

nfs-dakar:~# mysql -B -e "show processlist" | wc -l
35
nfs-dakar:~# mysql -B -e "show processlist" | grep authnss|wc -l
33
nfs-dakar:~# mysql -B -e "show variables" |grep max_connections
max_connections 300

Sur le client, vérifier les points suivants :

• Les commandes getent donnent-elles des informations réalistes ? gentent passwd | wc -l devrait donner une valeur du même ordre de grandeur que celle données par le select count(*) sur le serveur. Bien faire la vérification pour passwd, shadow et group

• nscd fonctionne-t-il ?

• Les fichiers de configurations sont-ils bien présents ? /etc/libnss-mysql.cfg et /etc/libnss-mysql-root.cfg ?

• Est-il effectivement possible de se connecter au serveur mysql depuis le client, en ligne de commande, avec les paramétres donnés dans les fichiers de configuration. Essayer en faisant des copier/coller des hostname/login/password au besoin, pour se méfier de fautes de frappes un peu traîtres

• /etc/nsswitch.conf est-il comme il devrait être ?

• Est-ce que le /etc/init.d/nscd restart n'as pas été un peu oublié avant de faire les premiers tests ?

• Pas de messages alarmant lors d'une analyse des logs ? Que donne un grep libnss-mysql /var/log/daemon.log ?