Comportement NIS étrange

Version imprimable

Bonjour,

Je viens d'installer un nouveau pc avec SLES 11.2 à l'aide d'un live-cd générer sur susestudio.com (Outils très très pratique).
J'utilise une authentification basée sur un serveur NIS. Cela fonctionne presque correctement, mais ce petit presque est problématique pour certains scripts.
Voici le problème:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 node9:~ # node9:~ # id -a Tux uid=400(Tux) gid=100(users) groups=100(users),3000(cadds),120(simul),253(cte),222(acou),153(admins),151(simulfs),200(wwwadmins),150(dvlp),710(calcul),250(cdi),4000(catia) node9:~ # node9:~ # su - Tux [I have no name!@node9:~]$ [I have no name!@node9:~]$ [I have no name!@node9:~]$ id -a uid=400 gid=100(users) groups=100(users),120(simul),150(dvlp),151(simulfs),153(admins),200(wwwadmins),222(acou),250(cdi),253(cte),710(calcul),3000(cadds),4000(catia) [I have no name!@node9:~]$ [I have no name!@node9:~]$ id -a Tux id: Tux: No such user [I have no name!@node9:~]$ logout node9:~ # ll /etc/nsswitch.conf -rw-r--r-- 1 root root 1244 May 22 13:34 /etc/nsswitch.conf
Les "users" sont bien reconnus par le root, ils peuvent se connecter correctement au poste, mais une requête en tant qu'utilisateur ne semble pas autorisée. De ce fait, même le prompt bash est perdu et me renvoi un "I have no name!".
J'en déduis qu'il doit y avoir un problème de droit d'accès à certains fichiers, puisque seul le root à un retour correct de la part du NIS.

Si quelqu'un à une piste...
D'avance merci pour votre aide.

PS: je peux vous mettre les fichiers de conf (/etc/nsswitch.conf et /etc/yp.conf) sur demande, mais ce sont les mêmes que ceux utilisés sur mes autres postes (SLES 11.2 également) et qui fonctionnent.

26/05/2013, 10h12
thierry.chich
Dans un cas pareil, je ferai la commande suivante:
Code:

1 2 strace -f id -a Tux
Ça listera les appels systèmes de la commande, et on verra ce qui échoue. En cas de difficultés à analyser, on peut aussi faire la même en tant que root, et même faire un diff si vraiment c'est obscur.
27/05/2013, 10h30
Leduc08

1 pièce(s) jointe(s)

Bonjour,

Merci pour la réponse.
J'ai suivi vos instructions, mais lorsque les logs diffèrent(L113), je ne vois pas d'explications ou de fichiers qui pourrait être mis en cause.

J'ai joint 3 fichiers de logs correspondant au strace:
Tux@node~: id -a
Tux@node~: id -a Tux
Root@node# id -a Tux

Si vous voyez une piste, je suis à l'écoute?
29/05/2013, 21h55
thierry.chich
IL y a beaucoup de différences que j'ai du mal à saisir, mais il u a une chose qui me frappe dans la trace en tant que SGE1:
Code:

1 2 298 bind(4, {sa_family=AF_INET, sin_port=htons(925), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied)
Pour une raison que je ne comprends pas très bien id semble ouvrir une socket en mode serveur sur le port 925, ce qu'il n'a pas le droit de faire, puisqu'il n'est pas root (c'est logique).

Reste la question, pourquoi ça marche sur les autres ? Ben, je n'en sais rien. Peut-être un setuid root posé sur id et pas dans cette version ?
30/05/2013, 09h35
Leduc08

Merci Thierry pour ce retour,

A ce niveau je n'ai plus vraiment pieds...
J'ai mis le support Novell dans la boucle.
Sachant que les installations basiques à partir d'un DVD de SLES 11.2 fonctionnent, je pense que le problème viendrait d'un package manquant, car sur Suse Studio, l'image de base est très light (C'est le but).
Mais comme c'est pour un noeud de cluster, le but est d'avoir une image d'installation strictement identique pour tous les noeuds. (Installation de nouveaux et mise à jour des anciens).

Est-ce qu'il y aurait d'autres choses à tester qui pourraient t'aider?

Encore merci pour ton aide.
30/05/2013, 10h57
Leduc08
Je viens de remarquer un point de différence dans le fichier /etc/passwd entre une version de SLES 11.2 qui fonctionne et celle qui ne fonctionne pas:
Code:

1 2 3 4 5 6 SLES OK uuidd:x:102:104:User for uuidd:/var/run/uuidd:/bin/false SLES NON OK uuidd:x:103:103:User for uuidd:/var/run/uuidd:/bin/false
Historiquement, nous avons un group avec l'id 103 dans le NIS.
--> Est-ce que cela peut poser problème?
Comment s'explique le fait que sur 2 versions de SLES il n'y ai pas les mêmes id pour des users système?

PS: modifier l'id et le gid en 102:104 sur le serveur qui pose problème ne change rien.
30/05/2013, 22h42
thierry.chich

Ah ouais, mais même distrib, même version ? J'avais pas bien lu.
En ce cas, il faut aussi faire un

Code:

strace -f id -a Tux

sur une qui marche.
Et cela dit, dans un dispositif comme celui-là, je suis sûr que le support va proposer une réinstall. Dans un cas pareil, soit l'install s'est mal produite, soit il y a une différence au niveau du serveur nis (autorisation manquante pour cette ip, par exemple).
31/05/2013, 08h29
Leduc08

1 pièce(s) jointe(s)

Il n'y a qu'a demandé...

Oui, même distrib, même version: SLES 11.2.
--> C'est pour cela également que je suis étonné de ne pas avoir les mêmes id sur les users systèmes comme uuid.

Pour la réinstallation, comme il y a une iso qui vient de susestudio, je pense qu'ils se devraient de trouver une solution.
En attendant, je n'ai aucune réponse de leur part.

Encore merci pour ton aide.

Bonjour Thierry,

Le problème est résolu, même si j'ai pas compris exactement la provenance.

En fait, la commande id -a $Nom_User, fait appel au serveur via un port réservé à l'administration (<1024), uniquement accessible par le root en mode classique.

J'ai donc modifié mon fichier ypserv.conf sur le server:
Code:

1 2 3 4 5 6 7 8 # Host : Domain : Map : Security # #10.128.238. : * : passwd.byname: ports 10.128.238. : * : passwd.byname : none #10.128.238. : * : passwd.byuid : ports 10.128.238. : * : passwd.byuid : none
La question qui reste en suspend pour moi est:
Pourquoi d'une version de SLES 11.2 à l'autre, le client YP n'interroge pas les même ports...

Encore merci pour ton aide.
Au plaisir de te lire.