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 :
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.
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Paul Gaborit écrivait dans fr.comp.os.bsd :
À (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+).
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que /etc/pam.d est mal configureé).
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.
Le 20-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Paul Gaborit écrivait dans fr.comp.os.bsd :
À (at) Tue, 19 Feb 2008 22:35:16 +0000 (UTC),
talon@lpthe.jussieu.fr (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+).
Certes. Mais sur mon réseau, c'est NIS tout court (en raison
d'interactiions avec d'autres OS). Le serveur principal est en
shadow passord pour certaines raisons que je ne développerai pas
ici. Je ne vois cependant toujours pas pourquoi le client refuse la
connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
/etc/pam.d est mal configureé).
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.
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Paul Gaborit écrivait dans fr.comp.os.bsd :
À (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+).
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que /etc/pam.d est mal configureé).
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
Paul Gaborit wrote:
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait des requêtes aux pages jaunes à tout propos. Pas seulement quand on se loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre information sur toi. Recopier ces fichiers sur chaque machine par rsync via ssh, ça impliquerait: 1) ne transmettre que des deltas, une propriété de rsync. 2) ne le faire que rarement, uniquement quand on update le map central. Pour des centaines de machines ce serait une réduction par des ordres de grandeur du traffic sur le réseau.
Je ne parle pas de la sécurité garantie par ssh, et du fait que *toutes* les machines du réseau freezent immédiatement dès que le serveur de pages jaunes a le moindre problème, tandis que rien de tel ne se passe avec des des fichiers locaux. Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
--
Michel TALON
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des
abominations. Pas étonnant que Microsoft ait choisi cette solution
couplée à l'autre abomination qu'est Kerberos.
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait
des requêtes aux pages jaunes à tout propos. Pas seulement quand on se
loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre
information sur toi. Recopier ces fichiers sur chaque machine par rsync
via ssh, ça impliquerait:
1) ne transmettre que des deltas, une propriété de rsync.
2) ne le faire que rarement, uniquement quand on update le map central.
Pour des centaines de machines ce serait une réduction par des ordres de
grandeur du traffic sur le réseau.
Je ne parle pas de la sécurité garantie par ssh, et du fait que *toutes*
les machines du réseau freezent immédiatement dès que le serveur de
pages jaunes a le moindre problème, tandis que rien de tel ne se passe
avec des des fichiers locaux. Pierre David avait viré les pages jaunes
chez nous quand il s'occcupait de nos machines, et c'est lui qui avait
cent fois raison. Il avait mis en place un petit programme
client-serveur s'occupant de la recopie des fichiers à chaque
modification du maître qui marchait très bien. Maintenant il y a des
solutions plus standard et plus sûres, comme rsync.
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait des requêtes aux pages jaunes à tout propos. Pas seulement quand on se loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre information sur toi. Recopier ces fichiers sur chaque machine par rsync via ssh, ça impliquerait: 1) ne transmettre que des deltas, une propriété de rsync. 2) ne le faire que rarement, uniquement quand on update le map central. Pour des centaines de machines ce serait une réduction par des ordres de grandeur du traffic sur le réseau.
Je ne parle pas de la sécurité garantie par ssh, et du fait que *toutes* les machines du réseau freezent immédiatement dès que le serveur de pages jaunes a le moindre problème, tandis que rien de tel ne se passe avec des des fichiers locaux. Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
--
Michel TALON
Paul Gaborit
À (at) Wed, 20 Feb 2008 11:11:09 +0000 (UTC), (Michel Talon) écrivait (wrote):
Paul Gaborit wrote:
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
Idée préconçue 1 : Microsoft l'a choisi = c'est nul !
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait des requêtes aux pages jaunes à tout propos. Pas seulement quand on se loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre information sur toi. Recopier ces fichiers sur chaque machine par rsync via ssh, ça impliquerait: 1) ne transmettre que des deltas, une propriété de rsync. 2) ne le faire que rarement, uniquement quand on update le map central. Pour des centaines de machines ce serait une réduction par des ordres de grandeur du traffic sur le réseau.
Idée préconçue 2 : l'important est de réduire le traffic réseau dû à LDAP, NIS+ ou NIS.
Ici, par rapport au reste, le traffic généré par LDAP/NIS+ (actuellement) ou par NIS (avant) est infime (même s'il y a de grandes chances qu'il soit supérieur à ce que nécessiterait une solution purement 'rsync'). Par contre, beaucoup d'applications peuvent modifier (une partie de) la base LDAP. Pour moi, l'intérêt premier c'est la propagation instantanée de ces modifications. L'autre intérêt est l'intégration dans un réseau très hétérogène (ça marche avec Windows, avec MacOS X, avec...).
Je ne parle pas de la sécurité garantie par ssh, et du fait que *toutes* les machines du réseau freezent immédiatement dès que le serveur de pages jaunes a le moindre problème, tandis que rien de tel ne se passe avec des des fichiers locaux.
Les serveurs LDAP, NIS+ ou NIS sont replicables (c'est d'ailleurs conseillé sur un gros réseau). Si tous sont plantés simultanément, c'est qu'il y a d'autres problèmes sur le réseau. Donc peu importe qu'on ne puisse plus vérifier le mot de passe des utilisateurs non locaux : de toutes manières, ils auraient d'autres problèmes (par exemple leur HOME ne serait pas disponible).
Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné ? Au moins, une tâche supplémenatire de maintenance d'un ensemble d'utilitaires maison. Mais j'imagine qu'il y avait d'autres avantages.;-) Mais ce n'est pas nécessairement généralisable.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 20 Feb 2008 11:11:09 +0000 (UTC),
talon@lpthe.jussieu.fr (Michel Talon) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des
abominations. Pas étonnant que Microsoft ait choisi cette solution
couplée à l'autre abomination qu'est Kerberos.
Idée préconçue 1 : Microsoft l'a choisi = c'est nul !
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien
dans l'éventuelle complexité (si ce n'est que Windows demande parfois
à utiliser LDAP d'une manière pas très compatible avec le reste du
monde et que ce n'est pas modifiabke).
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait
des requêtes aux pages jaunes à tout propos. Pas seulement quand on se
loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre
information sur toi. Recopier ces fichiers sur chaque machine par rsync
via ssh, ça impliquerait:
1) ne transmettre que des deltas, une propriété de rsync.
2) ne le faire que rarement, uniquement quand on update le map central.
Pour des centaines de machines ce serait une réduction par des ordres de
grandeur du traffic sur le réseau.
Idée préconçue 2 : l'important est de réduire le traffic réseau dû à
LDAP, NIS+ ou NIS.
Ici, par rapport au reste, le traffic généré par LDAP/NIS+
(actuellement) ou par NIS (avant) est infime (même s'il y a de grandes
chances qu'il soit supérieur à ce que nécessiterait une solution
purement 'rsync'). Par contre, beaucoup d'applications peuvent
modifier (une partie de) la base LDAP. Pour moi, l'intérêt premier
c'est la propagation instantanée de ces modifications. L'autre intérêt
est l'intégration dans un réseau très hétérogène (ça marche avec
Windows, avec MacOS X, avec...).
Je ne parle pas de la sécurité garantie par ssh, et du fait que
*toutes* les machines du réseau freezent immédiatement dès que le
serveur de pages jaunes a le moindre problème, tandis que rien de
tel ne se passe avec des des fichiers locaux.
Les serveurs LDAP, NIS+ ou NIS sont replicables (c'est d'ailleurs
conseillé sur un gros réseau). Si tous sont plantés simultanément,
c'est qu'il y a d'autres problèmes sur le réseau. Donc peu importe
qu'on ne puisse plus vérifier le mot de passe des utilisateurs non
locaux : de toutes manières, ils auraient d'autres problèmes (par
exemple leur HOME ne serait pas disponible).
Pierre David avait viré les pages jaunes chez nous quand il
s'occcupait de nos machines, et c'est lui qui avait cent fois
raison. Il avait mis en place un petit programme client-serveur
s'occupant de la recopie des fichiers à chaque modification du
maître qui marchait très bien. Maintenant il y a des solutions plus
standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné
? Au moins, une tâche supplémenatire de maintenance d'un ensemble
d'utilitaires maison. Mais j'imagine qu'il y avait d'autres
avantages.;-) Mais ce n'est pas nécessairement généralisable.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 20 Feb 2008 11:11:09 +0000 (UTC), (Michel Talon) écrivait (wrote):
Paul Gaborit wrote:
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.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
Idée préconçue 1 : Microsoft l'a choisi = c'est nul !
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
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+).
N'importe quoi! A tout instant, chacune des centaines de machines fait des requêtes aux pages jaunes à tout propos. Pas seulement quand on se loggue, mais chaque fois qu'un programme quelconque a besoin de la moindre information sur toi. Recopier ces fichiers sur chaque machine par rsync via ssh, ça impliquerait: 1) ne transmettre que des deltas, une propriété de rsync. 2) ne le faire que rarement, uniquement quand on update le map central. Pour des centaines de machines ce serait une réduction par des ordres de grandeur du traffic sur le réseau.
Idée préconçue 2 : l'important est de réduire le traffic réseau dû à LDAP, NIS+ ou NIS.
Ici, par rapport au reste, le traffic généré par LDAP/NIS+ (actuellement) ou par NIS (avant) est infime (même s'il y a de grandes chances qu'il soit supérieur à ce que nécessiterait une solution purement 'rsync'). Par contre, beaucoup d'applications peuvent modifier (une partie de) la base LDAP. Pour moi, l'intérêt premier c'est la propagation instantanée de ces modifications. L'autre intérêt est l'intégration dans un réseau très hétérogène (ça marche avec Windows, avec MacOS X, avec...).
Je ne parle pas de la sécurité garantie par ssh, et du fait que *toutes* les machines du réseau freezent immédiatement dès que le serveur de pages jaunes a le moindre problème, tandis que rien de tel ne se passe avec des des fichiers locaux.
Les serveurs LDAP, NIS+ ou NIS sont replicables (c'est d'ailleurs conseillé sur un gros réseau). Si tous sont plantés simultanément, c'est qu'il y a d'autres problèmes sur le réseau. Donc peu importe qu'on ne puisse plus vérifier le mot de passe des utilisateurs non locaux : de toutes manières, ils auraient d'autres problèmes (par exemple leur HOME ne serait pas disponible).
Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné ? Au moins, une tâche supplémenatire de maintenance d'un ensemble d'utilitaires maison. Mais j'imagine qu'il y avait d'autres avantages.;-) Mais ce n'est pas nécessairement généralisable.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Belhomme
Paul Gaborit wrote in news::
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est comme pour tout, il y a : 1/ ceux qui savent 2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc - pour les seconds, c'est imbittable.
De fait, LDAP est pas forcément le protocole le plus simple à appréhender, mais il rend de réels services, et franchement, quand on a pris la peine de se former dessus, ca n'est pas pire qu'une MIB SNMP ou une zone DNS de Bind... Quant à Active Directory, c'est modifiable, mais il est vrai que ca ne se fait pas simplement, et que Microsoft le déconseille pour une simple question de support.
-- Rico
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote in
news:wt93arneruo.fsf@marceau.enstimac.fr:
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des
abominations. Pas étonnant que Microsoft ait choisi cette solution
couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien
dans l'éventuelle complexité (si ce n'est que Windows demande parfois
à utiliser LDAP d'une manière pas très compatible avec le reste du
monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est
comme pour tout, il y a :
1/ ceux qui savent
2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc
- pour les seconds, c'est imbittable.
De fait, LDAP est pas forcément le protocole le plus simple à appréhender,
mais il rend de réels services, et franchement, quand on a pris la peine de
se former dessus, ca n'est pas pire qu'une MIB SNMP ou une zone DNS de
Bind...
Quant à Active Directory, c'est modifiable, mais il est vrai que ca ne se
fait pas simplement, et que Microsoft le déconseille pour une simple
question de support.
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est comme pour tout, il y a : 1/ ceux qui savent 2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc - pour les seconds, c'est imbittable.
De fait, LDAP est pas forcément le protocole le plus simple à appréhender, mais il rend de réels services, et franchement, quand on a pris la peine de se former dessus, ca n'est pas pire qu'une MIB SNMP ou une zone DNS de Bind... Quant à Active Directory, c'est modifiable, mais il est vrai que ca ne se fait pas simplement, et que Microsoft le déconseille pour une simple question de support.
-- Rico
JKB
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Eric Belhomme écrivait dans fr.comp.os.bsd :
Paul Gaborit wrote in news::
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est comme pour tout, il y a : 1/ ceux qui savent 2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc - pour les seconds, c'est imbittable.
Tiens... Moi, je sais, mais je trouve toujours ça imbittable (pourtant, je cause sendmail.cf dans le texte, zones bind, snmp, mais LDAP, non...).
Bon, j'ai un quick and dirty patch pour utiliser le ypbind de NetBSD sur ypserv de Linux :
rayleigh:[~] > cat /var/yp/NetBSD make grpunconv pwunconv make grpconv pwconv rayleigh:[~] >
Autre chose, pour la personne qui recherchait comment faire fonctionner ce @~#[[^[{|{|" d'amd, j'ai une solution fonctionnelle :
riemann# cat ./amd.conf [ global ] normalize_hostnames = no print_pid = no restart_mounts = yes auto_dir = /amd log_file = /var/log/amd log_options = all plock = no map_type = file browsable_dirs = yes unmount_on_exit = yes dismount_interval = 600 local_domain = mydomain.fr
[ /import ] map_name = /etc/amd.import
riemann# cat amd.import /defaults type:=nfs;opts:=rw,soft home rhost:=weierstrass;rfs:=/export/home; riemann#
avec riemann, le client NetBSD, et weierstrass, le serveur NFS linux. Les répertoires des utilisateurs (weierstrass:/export/home) sont montés dans /import/home au travers d'un lien symbolique /amd/weierstrass/export/home. Pas simple et vraiment pas bien documenté !...
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.
Le 20-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Eric Belhomme écrivait dans fr.comp.os.bsd :
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote in
news:wt93arneruo.fsf@marceau.enstimac.fr:
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des
abominations. Pas étonnant que Microsoft ait choisi cette solution
couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien
dans l'éventuelle complexité (si ce n'est que Windows demande parfois
à utiliser LDAP d'une manière pas très compatible avec le reste du
monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est
comme pour tout, il y a :
1/ ceux qui savent
2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc
- pour les seconds, c'est imbittable.
Tiens... Moi, je sais, mais je trouve toujours ça imbittable
(pourtant, je cause sendmail.cf dans le texte, zones bind, snmp,
mais LDAP, non...).
Bon, j'ai un quick and dirty patch pour utiliser le ypbind de NetBSD
sur ypserv de Linux :
rayleigh:[~] > cat /var/yp/NetBSD
make
grpunconv
pwunconv
make
grpconv
pwconv
rayleigh:[~] >
Autre chose, pour la personne qui recherchait comment faire
fonctionner ce @~#[[^[{|{|" d'amd, j'ai une solution fonctionnelle :
riemann# cat ./amd.conf
[ global ]
normalize_hostnames = no
print_pid = no
restart_mounts = yes
auto_dir = /amd
log_file = /var/log/amd
log_options = all
plock = no
map_type = file
browsable_dirs = yes
unmount_on_exit = yes
dismount_interval = 600
local_domain = mydomain.fr
[ /import ]
map_name = /etc/amd.import
riemann# cat amd.import
/defaults type:=nfs;opts:=rw,soft
home rhost:=weierstrass;rfs:=/export/home;
riemann#
avec riemann, le client NetBSD, et weierstrass, le serveur NFS
linux. Les répertoires des utilisateurs (weierstrass:/export/home)
sont montés dans /import/home au travers d'un lien symbolique
/amd/weierstrass/export/home. Pas simple et vraiment pas bien
documenté !...
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.
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Eric Belhomme écrivait dans fr.comp.os.bsd :
Paul Gaborit wrote in news::
LDAP c'est un monstre de complexité. Pour moi c'est l'abomination des abominations. Pas étonnant que Microsoft ait choisi cette solution couplée à l'autre abomination qu'est Kerberos.
LDAP n'a pas été conçu par ou pour Microsoft. Ils n'y sont pour rien dans l'éventuelle complexité (si ce n'est que Windows demande parfois à utiliser LDAP d'une manière pas très compatible avec le reste du monde et que ce n'est pas modifiabke).
désolé, mais je peux pas m'empêcher de tomber dans le troll : LDAP, c'est comme pour tout, il y a : 1/ ceux qui savent 2/ les autres
- Pour les premiers, LDAP, c'est simple, utile, pratique, puissant, etc - pour les seconds, c'est imbittable.
Tiens... Moi, je sais, mais je trouve toujours ça imbittable (pourtant, je cause sendmail.cf dans le texte, zones bind, snmp, mais LDAP, non...).
Bon, j'ai un quick and dirty patch pour utiliser le ypbind de NetBSD sur ypserv de Linux :
rayleigh:[~] > cat /var/yp/NetBSD make grpunconv pwunconv make grpconv pwconv rayleigh:[~] >
Autre chose, pour la personne qui recherchait comment faire fonctionner ce @~#[[^[{|{|" d'amd, j'ai une solution fonctionnelle :
riemann# cat ./amd.conf [ global ] normalize_hostnames = no print_pid = no restart_mounts = yes auto_dir = /amd log_file = /var/log/amd log_options = all plock = no map_type = file browsable_dirs = yes unmount_on_exit = yes dismount_interval = 600 local_domain = mydomain.fr
[ /import ] map_name = /etc/amd.import
riemann# cat amd.import /defaults type:=nfs;opts:=rw,soft home rhost:=weierstrass;rfs:=/export/home; riemann#
avec riemann, le client NetBSD, et weierstrass, le serveur NFS linux. Les répertoires des utilisateurs (weierstrass:/export/home) sont montés dans /import/home au travers d'un lien symbolique /amd/weierstrass/export/home. Pas simple et vraiment pas bien documenté !...
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
Paul Gaborit wrote:
Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné ?
Qu'y avions nous gagné? (car c'est au passé). La tranquillité, ça marchait comme une horloge.
Au moins, une tâche supplémenatire de maintenance d'un ensemble d'utilitaires maison.
Effectivement pour cette raison (ne pas entretenir les utilitaires) le responsable info chez nous est revenu aux pages jaunes, avec son cortège d'emmerdements.
Voilà le genre de choses qu'on trouve dans les logs Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****] for domain "maia24" not responding Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****] for domain "maia24" OK
Et quand ça se produit, les machines freezent. Et il y a bien deux serveurs de pages jaunes répliqués.
Mais j'imagine qu'il y avait d'autres avantages.;-) Mais ce n'est pas nécessairement généralisable.
--
Michel TALON
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Pierre David avait viré les pages jaunes chez nous quand il
s'occcupait de nos machines, et c'est lui qui avait cent fois
raison. Il avait mis en place un petit programme client-serveur
s'occupant de la recopie des fichiers à chaque modification du
maître qui marchait très bien. Maintenant il y a des solutions plus
standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné
?
Qu'y avions nous gagné? (car c'est au passé). La tranquillité, ça
marchait comme une horloge.
Au moins, une tâche supplémenatire de maintenance d'un ensemble
d'utilitaires maison.
Effectivement pour cette raison (ne pas entretenir les utilitaires) le
responsable info chez nous est revenu aux pages jaunes, avec son cortège
d'emmerdements.
Voilà le genre de choses qu'on trouve dans les logs
Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****]
for domain "maia24" not responding
Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****]
for domain "maia24" OK
Et quand ça se produit, les machines freezent. Et il y a bien deux
serveurs de pages jaunes répliqués.
Mais j'imagine qu'il y avait d'autres
avantages.;-) Mais ce n'est pas nécessairement généralisable.
Pierre David avait viré les pages jaunes chez nous quand il s'occcupait de nos machines, et c'est lui qui avait cent fois raison. Il avait mis en place un petit programme client-serveur s'occupant de la recopie des fichiers à chaque modification du maître qui marchait très bien. Maintenant il y a des solutions plus standard et plus sûres, comme rsync.
C'est très bien que ça marche chez vous comme ça. Qu'y avez-vous gagné ?
Qu'y avions nous gagné? (car c'est au passé). La tranquillité, ça marchait comme une horloge.
Au moins, une tâche supplémenatire de maintenance d'un ensemble d'utilitaires maison.
Effectivement pour cette raison (ne pas entretenir les utilitaires) le responsable info chez nous est revenu aux pages jaunes, avec son cortège d'emmerdements.
Voilà le genre de choses qu'on trouve dans les logs Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****] for domain "maia24" not responding Feb 20 06:46:38 niobe /usr/sbin/ypbind[690]: NIS server [****] for domain "maia24" OK
Et quand ça se produit, les machines freezent. Et il y a bien deux serveurs de pages jaunes répliqués.
Mais j'imagine qu'il y avait d'autres avantages.;-) Mais ce n'est pas nécessairement généralisable.
--
Michel TALON
Manuel Bouyer
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB <knatschke@koenigsberg.fr> wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison
d'interactiions avec d'autres OS). Le serveur principal est en
shadow passord pour certaines raisons que je ne développerai pas
ici. Je ne vois cependant toujours pas pourquoi le client refuse la
connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche
un master.passwd.byname, pas shadow.byname. S'il ne trouve pas,
il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec
tout le monde ...)
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien). J'ai la flemme de regarder ce que fait exactement ypbind donc cela restera comme ça un certain temps...
Cordialament,
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.
Le 20-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB <knatschke@koenigsberg.fr> wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison
d'interactiions avec d'autres OS). Le serveur principal est en
shadow passord pour certaines raisons que je ne développerai pas
ici. Je ne vois cependant toujours pas pourquoi le client refuse la
connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche
un master.passwd.byname, pas shadow.byname. S'il ne trouve pas,
il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec
tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne
donne rien). J'ai la flemme de regarder ce que fait exactement
ypbind donc cela restera comme ça un certain temps...
Cordialament,
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.
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien). J'ai la flemme de regarder ce que fait exactement ypbind donc cela restera comme ça un certain temps...
Cordialament,
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
JKB wrote:
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format (c'est a dire avec les champs supplementaires class, change et expire).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB <knatschke@koenigsberg.fr> wrote:
Le 20-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB <knatschke@koenigsberg.fr> wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison
d'interactiions avec d'autres OS). Le serveur principal est en
shadow passord pour certaines raisons que je ne développerai pas
ici. Je ne vois cependant toujours pas pourquoi le client refuse la
connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche
un master.passwd.byname, pas shadow.byname. S'il ne trouve pas,
il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec
tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne
donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format
(c'est a dire avec les champs supplementaires class, change et expire).
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format (c'est a dire avec les champs supplementaires class, change et expire).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le 21-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format (c'est a dire avec les champs supplementaires class, change et expire).
Cela n'a pas l'air de fonctionner. Me manque-t-il quelque chose ?
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.
Le 21-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB <knatschke@koenigsberg.fr> wrote:
Le 20-02-2008, à propos de
Re: [NetBSD 4.0] Binding a linux NIS server...,
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB <knatschke@koenigsberg.fr> wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison
d'interactiions avec d'autres OS). Le serveur principal est en
shadow passord pour certaines raisons que je ne développerai pas
ici. Je ne vois cependant toujours pas pourquoi le client refuse la
connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche
un master.passwd.byname, pas shadow.byname. S'il ne trouve pas,
il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec
tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne
donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format
(c'est a dire avec les champs supplementaires class, change et expire).
Cela n'a pas l'air de fonctionner. Me manque-t-il quelque chose ?
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.
Le 21-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Le 20-02-2008, à propos de Re: [NetBSD 4.0] Binding a linux NIS server..., Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB wrote:
Certes. Mais sur mon réseau, c'est NIS tout court (en raison d'interactiions avec d'autres OS). Le serveur principal est en shadow passord pour certaines raisons que je ne développerai pas ici. Je ne vois cependant toujours pas pourquoi le client refuse la connexion (comme s'il ne savait pas utiliser le shadow.byname ou que
C'est exactement ca. NetBSD (et les autres BSD aussi je pense) cherche un master.passwd.byname, pas shadow.byname. S'il ne trouve pas, il cherche le mot de passe dans passwd.byname (ce qui doit marcher avec tout le monde ...)
Il ne cherche pas de master.passwd.byname (j'ai essayé et cela ne donne rien).
Il faut master.passwd.byname et master.passwd.byuid, avec le bon format (c'est a dire avec les champs supplementaires class, change et expire).
Cela n'a pas l'air de fonctionner. Me manque-t-il quelque chose ?
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.
