Re: Problème NIS

Le 20/12/2021 à 18:24, BERTRAND Joël a écrit :
Bonsoir

Sur Bullseye, un reboot (???!!!???) des clients (en Bullseye eux aussi) a réglé le problème. Par contre, je n'ai pas (encore) réussi à identifier la cause. C'est aussi la première fois, il me semble, mais les souvvenirs, on sait ce que cela vaut, qu'un reboot règle un problème sous debian.

Je ne sais pas quelle était la cause, mais le remède a fonctionné. Phénomène reproductible sur tous les clients et sur chaque cohorte d'étudiants concernés (3 à ce jour sur cette distribution debian 11). Pour le coup, NIS est un service qui peut même tomber en marche.

Bien évidemment, l'identification de la cause m'intéresse très fortement (rien trouvé dans les logs...).

Bonne soirée

Jean-Claude

    Bonjour à tous,

    J'ai une station de travail qui est en Debian/Bookworm et qui fonctionnait correctement jusqu'à une mise à jour récente (apportée par unattented upgrade) et je n'arrive pas à trouver ce qui coince.

    Configuration :
- serveur NIS/NFS tournant sous NetBSD 9.2 (rien de changé de ce côté-là). Les tables NIS sont exportées correctement et sur la machine fautive, un ypcat passwd par exemple renvoie quelque chose.
- poste FreeBSD
- postes Linux (un debian stable et plusieurs debian/testing).

    Lors de la mise en place de la configuration, j'ai galéré parce que tout ce beau monde ne cause pas la même langue ni le même format. J'ai donc côté NetBSD un Makefile spécifique pour générer les fichiers à la bonne syntaxe pour Linux, NetBSD et FreeBSD. J'ai aussi forcé le chiffrement des mots de passe à old pour les entrées yp.

    Lorsque je fais un ypcat passwd sur le poste fautif (et les autres d'ailleurs), j'obtiens:

bertrand:iuzeyizruyeri:1002:1002:...

    Bref, cela semble bien chiffré avec crypt.

    Sur le poste FreeBSD, ça fonctionne sans problème. Sur le poste Debian 11 aussi. Mais pas sur testing où un su par exemple me retourne :

su: user bertrand does not exist or the entry does not contain all the required fields

    Naturellement, j'ai testé avec plusieurs identifiants. Le résultat est toujours le même.

    J'ai vu que les fichiers /etc/pam.d/auth* avaient été mis à jour récemment, mais je ne comprends pas le rapport (et surtout, je ne vois pas trop quelle est la différence entre ceux de la machine sous debian 11 et celle sous testing). Dernière chose, toutes ces machines sont diskless, mais apparmor ne semble pas se plaindre.

    Je prends toute idée parce que je ne vois vraiment pas d'où vient le problème...

    Bien cordialement,

    JKB