[NetBSD 4.0] Binding a linux NIS server...

Le
JKB
Bonjour à tous,

Je relance mon thread de la semaine dernière (mais entre temps, mon
FAI a réinitialisé [enfin] son serveur de news, donc je ne peux
répondre à mon post précédent).

Considérons un serveur NIS tournant sous Linux/Sparc64 appelé
rayleigh et un client tournant sous NetBSD 4.0/sparc32 se prénomant
riemann.

fermat:[~] > ssh -l root riemann
Password:
Last login: Tue Feb 12 16:18:25 2008
NetBSD 4.0 (GENERIC.MP) #0: Sun Dec 16 02:23:20 PST 2007

Welcome to NetBSD!

Terminal type is xterm.
We recommend creating a non-root account and using su(1) for root access.
riemann# ps -aux | grep yp
root 692 2.8 0.6 420 3348 ? Ss 4:24PM 0:05.63 sshd: root@ttyp0
root 622 0.0 0.2 156 912 ? Ss 4:20PM 0:00.09 /usr/sbin/ypbind
root 635 0.0 0.1 176 728 ttyp0 R+ 4:25PM 0:00.01 grep yp
root 700 0.1 0.2 280 1208 ttyp0 Ss 4:24PM 0:-1.84 -sh
root 720 0.0 0.1 88 732 ttyp0 R+ 4:25PM 0:00.00 ps -aux
riemann#

Pas de problème, sshd tourne et le nis fonctionne a priori.
Regardons de plus près le NIS.

riemann# ypcat passwd.byname

Sortie verbeuse qui me renvoie tous les comptes exportés par le
serveur NIS. Donc on va considérer que le NIS fonctionne.

riemann#

J'ai monté à la main les $HOMEs des utilisateurs au bon endroit. La
preuve :

riemann# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/sd0a 2071664 26462 1941620 1% /
/dev/sd0d 5264240 878 5000150 0% /var
/dev/sd0g 11914202 771702 10546790 6% /usr
/dev/sd0e 49646140 2 47163832 0% /home
kernfs 1 1 0 100% /kern
procfs 4 4 0 100% /proc
rayleigh:/export/home 353376836 111971956 223454288 33%
/import/home
riemann#

Je m'occuperai de amd plus tard Mais je n'arrive pas à me
connecter sur cette machine :

riemann# su - bertrand
su: unknown login bertrand
riemann# ypcat passwd.byname | grep bertrand
bertrand:x:1000:1000:BERTRAND Jo,,,:/import/home/bertrand:/bin/bash
riemann# which bash
/bin/bash
riemann#

Je n'ai aucune trace bizarre dans les logs. Si je tente un ssh
depuis une autre machine, j'obtiens :

Feb 12 16:33:40 riemann sshd[376]: Invalid user bertrand from 192.168.0.83
Feb 12 16:33:41 riemann sshd[376]: Failed none for invalid user bertrand
from 192.168.0.83 port 60054 ssh2

avant même que le client ssh me demande mon mot de passe. J'avoue
mon ignorance crasse de NetBSD (mais j'ai une solide pratique
d'Unices de tous poils). Je ne vois vraiment pas ce que j'ai pu
oublier Une idée ?

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #1026584
Le 19-02-2008, à propos de
[NetBSD 4.0] Binding a linux NIS server...,
JKB écrivait dans fr.comp.os.bsd :
Je n'ai aucune trace bizarre dans les logs. Si je tente un ssh
depuis une autre machine, j'obtiens :

Feb 12 16:33:40 riemann sshd[376]: Invalid user bertrand from 192.168.0.83
Feb 12 16:33:41 riemann sshd[376]: Failed none for invalid user bertrand
from 192.168.0.83 port 60054 ssh2

avant même que le client ssh me demande mon mot de passe. J'avoue
mon ignorance crasse de NetBSD (mais j'ai une solide pratique
d'Unices de tous poils). Je ne vois vraiment pas ce que j'ai pu
oublier... Une idée ?


Bon, on progresse. J'ai remplacé compat dans /etc/nsswitch.conf par
nis files. Je ne vois pas pourquoi compat ne fonctionne pas
(j'utilisais pourtant la syntaxe '+'). Problème suivant : une
connexion ssh sur un compte NIS ne donne rien avec dans les logs :

Feb 19 17:55:50 riemann sshd[2892]: Failed keyboard-interactive/pam for
bertrand from 192.168.0.83 port 40358 ssh2
Feb 19 17:55:55 riemann sshd[2892]: Failed password for bertrand from
192.168.0.83 port 40358 ssh2

J'ai un chiffrement md5 des deux côtés, pourtant... Une idée ?

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

talon
Le #1028005
Thierry Herbelot
JKB wrote:

[COUIC]

il y a bien la ligne +::::::::: à la fin de /etc/passwd et /etc/group ?

TfH

PS : si tu arrives à configurer AMD sur ton BSD pour monter les HOMEs des
utilisateurs, je suis intéressé



Je ne sais pas quel est exactement ton contexte mais chez moi ça le fait
sans problème avec un serveur Linux et la config suivante:
niobe% cat amd.conf
[global]
auto_dir = /.amd
log_file = /var/log/amd.log
log_options = error,fatal,user
map_type = file
search_path = /etc

[/Cd]
map_name = amd.cdrom

# For nfs mounts

[/Net]
map_name = amd.net

niobe% cat amd.net
/defaults type:=host;fs:=${autodir}/${rhost};rhost:=${key}
* opts:=rw,grpid,resvport,nosuid,nodev,soft


niobe% cat amd.cdrom
cdrom type:Ífs;opts:=ro,nosuid;dev:=/dev/acd0c;fs:=${autodir}/cdrom


--

Michel TALON

JKB
Le #1028004
Le 19-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Thierry Herbelot écrivait dans fr.comp.os.bsd :
JKB wrote:

[COUIC]

il y a bien la ligne +::::::::: à la fin de /etc/passwd et /etc/group ?


Non, parce qu'à la lecture du man, j'ai compris (peut-être de
travers) que cela n'était utile que dans le cas "compat".

TfH

PS : si tu arrives à configurer AMD sur ton BSD pour monter les HOMEs des
utilisateurs, je suis intéressé


Je vais devoir y passer... J'ai des Sparc32 à faire revivre...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB
Le #1028003
Le 19-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Thierry Herbelot écrivait dans fr.comp.os.bsd :
JKB wrote:

[COUIC]

il y a bien la ligne +::::::::: à la fin de /etc/passwd et /etc/group ?


Je viens d'essayer, cela ne change rien.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Manuel Bouyer
Le #1028002
JKB
Bon, on progresse. J'ai remplacé compat dans /etc/nsswitch.conf par
nis files. Je ne vois pas pourquoi compat ne fonctionne pas
(j'utilisais pourtant la syntaxe '+'). Problème suivant : une
connexion ssh sur un compte NIS ne donne rien avec dans les logs :

Feb 19 17:55:50 riemann sshd[2892]: Failed keyboard-interactive/pam for
bertrand from 192.168.0.83 port 40358 ssh2
Feb 19 17:55:55 riemann sshd[2892]: Failed password for bertrand from
192.168.0.83 port 40358 ssh2

J'ai un chiffrement md5 des deux côtés, pourtant... Une idée ?


Dans ton post precedent:
riemann# ypcat passwd.byname | grep bertrand
bertrand:x:1000:1000:BERTRAND Jo,,,:/import/home/bertrand:/bin/bash


y'a pas le mot de passe ...
Je pense que le probleme viens du fait que linux et NetBSD utilisent
une facons differente de cacher les mots de passe (je ne serais pas
surpris que NetBSD cherche une map master.passwd.byname ou un truc
comme ca, avec les mots de passe dedans). Je ne sais pas comment
fait linux de son cote. Faire marcher un client linux avec un serveur NetBSD
je sais, mais dans l'autre sens ... (deja, pourquoi un serveur est-il sous
linux ? :)

--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--

talon
Le #1033666
Manuel Bouyer
Je pense que le probleme viens du fait que linux et NetBSD utilisent
une facons differente de cacher les mots de passe (je ne serais pas
surpris que NetBSD cherche une map master.passwd.byname ou un truc
comme ca, avec les mots de passe dedans). Je ne sais pas comment
fait linux de son cote. Faire marcher un client linux avec un serveur NetBSD
je sais, mais dans l'autre sens ... (deja, pourquoi un serveur est-il sous
linux ? :)



Il y a moyen de demander à Linux qu'il envoie le map avec les passwds
dedans. C'est comme ça chez nous, ce qui permet d'être compatible avec
d'autres OS. Au début l'admin n'aime pas, il faut lui expliquer que de
toute façon son /etc/shadow va passer sur le réseau, que ce soit
séparément ou mélangé avec /etc/passwd.
A vrai dire c'est le système des pages jaunes qui est débile. Il serait
bien plus sûr et efficace d'utiliser rsync pour répliquer passwd
et shadow sur toutes les machines régulièrement, ou chaque fois qu'on
change le maître.


--

Michel TALON

JKB
Le #1035141
Le 19-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB
Bon, on progresse. J'ai remplacé compat dans /etc/nsswitch.conf par
nis files. Je ne vois pas pourquoi compat ne fonctionne pas
(j'utilisais pourtant la syntaxe '+'). Problème suivant : une
connexion ssh sur un compte NIS ne donne rien avec dans les logs :

Feb 19 17:55:50 riemann sshd[2892]: Failed keyboard-interactive/pam for
bertrand from 192.168.0.83 port 40358 ssh2
Feb 19 17:55:55 riemann sshd[2892]: Failed password for bertrand from
192.168.0.83 port 40358 ssh2

J'ai un chiffrement md5 des deux côtés, pourtant... Une idée ?


Dans ton post precedent:
riemann# ypcat passwd.byname | grep bertrand
bertrand:x:1000:1000:BERTRAND Jo,,,:/import/home/bertrand:/bin/bash


y'a pas le mot de passe ...
Je pense que le probleme viens du fait que linux et NetBSD utilisent
une facons differente de cacher les mots de passe (je ne serais pas
surpris que NetBSD cherche une map master.passwd.byname ou un truc
comme ca, avec les mots de passe dedans). Je ne sais pas comment
fait linux de son cote. Faire marcher un client linux avec un serveur NetBSD
je sais, mais dans l'autre sens ... (deja, pourquoi un serveur est-il sous
linux ? :)


La vraie question est : pourquoi cette machine est-elle sous NetBSD
? Mais je m'égarre... ;-) Disons que j'en suis au hack sauvage pour
faire tourner un noyau Linux sur sparc32/SMP (et encore, pas avec
des HyperSparc...) et que je recompile tous les paquets debian pour
processeur sparcV8 strict.

Effectivement, j'ai une table shadow.byname. C'est grave, docteur ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


F. Senault
Le #1036136

si je lis bien ta conf AMD, elle permet d'accèder aux ordis distants
par /Net/machine, ce qui n'est pas exactement ce que je veux.


| 9:39 :~> pwd
| /.amd_mnt/magnum/host/data/users/home/fred
| 9:39 :~> ls -ld /home
| lrwxr-xr-x 1 root wheel 28 Mar 13 2006 /home -> /host/magnum/data/users/home

Non ?

Fred
--
On l'a vu dans la poussière Avec les chats des cimetières
Glissant entre les fissures Frôlant les tombes et leurs murs
Dans la chaleur de l'été Les os des hommes pourrissaient
Joey ce soir ne dérange Que les démons et les anges (Noir Désir, Joey)

talon
Le #1037506
Thierry Herbelot

je n'étais pas assez précis : je recherche la configuration d'AMD sur un BSD
pour monter les HOMEs linux exportés par autofs/NIS (les répertoires
arrivent sous /home/users/<user> sur ma machine Linux)

si je lis bien ta conf AMD, elle permet d'accèder aux ordis distants
par /Net/machine, ce qui n'est pas exactement ce que je veux.

TfH



A vrai dire je ne sais pas trop ce qui se passe coté linux serveur NFS,
mais apparemment amd s'enquiert de ce qui est montable sur le serveur et
monte tout. Pour ce qui concerne le /home/user/machin, c'est exactement
comme ça chez moi, et simplement grace à un lien symbolique. Par exemple
j'ai dans /:
lrwxr-xr-x 1 root wheel 8 9 mai 2006 ada@ -> /Net/ada
lrwxr-xr-x 1 root wheel 13 10 mai 2006 ada1@ ->
/Net/ada/ada1
lrwxr-xr-x 1 root wheel 13 10 mai 2006 ada2@ ->
/Net/ada/ada2
et mon home est censé être dans /ada1/lpthe/talon
Au login la machine BSD détecte la volonté d'aller sous /ada1 donc de
monter /Net/ada. Le nom de machine "ada" est identifié et tout ce qui
est montable sur le serveur Linux "ada" est monté par NFS.



--

Michel TALON

Paul Gaborit
Le #1037501
À (at) Tue, 19 Feb 2008 22:35:16 +0000 (UTC),
(Michel Talon) écrivait (wrote):
Il y a moyen de demander à Linux qu'il envoie le map avec les passwds
dedans. C'est comme ça chez nous, ce qui permet d'être compatible avec
d'autres OS. Au début l'admin n'aime pas, il faut lui expliquer que de
toute façon son /etc/shadow va passer sur le réseau, que ce soit
séparément ou mélangé avec /etc/passwd.


LDAP et NIS+ permettent d'éviter la circulation "en clair" de ces
fichiers. Si on se limite à NIS, il y a eu des tentatives de
"sécurisation" mais généralement, c'est lourd.

A vrai dire c'est le système des pages jaunes qui est débile. Il serait
bien plus sûr et efficace d'utiliser rsync pour répliquer passwd
et shadow sur toutes les machines régulièrement, ou chaque fois qu'on
change le maître.


Lorsqu'on a plusieurs centaines de machines et d'utilisateurs, la
solution 'rsync' me semble bien plus "débile" que NIS (ou LDAP ou
NIS+).

--
Paul Gaborit -
Publicité
Poster une réponse
Anonyme