J'ai deux machines sous FreeBSD 7.x, que j'ai configurées pour utiliser
le LDAP uniquement pour les connexions SSH et sudo.
En tout cas, c'est ce que je croyais jusqu'à ce que le LDAP tombe et que
plus rien ne fonctionne sur la machine :
(extrait de /var/log/messages)
cron[86046]: nss_ldap: could not search LDAP server - Server is
unavailable
pax: nss_ldap: could not search LDAP server - Server is unavailable
pax: nss_ldap: could not search LDAP server - Server is unavailable
pax: nss_ldap: could not search LDAP server - Server is unavailable
top: nss_ldap: could not search LDAP server - Server is unavailable
xinetd[86537]: nss_ldap: could not search LDAP server - Server is
unavailable
cron[86540]: nss_ldap: could not search LDAP server - Server is
unavailable
cron[86553]: nss_ldap: could not search LDAP server - Server is
unavailable
cron[86552]: nss_ldap: could not search LDAP server - Server is
unavailable
pax: nss_ldap: could not search LDAP server - Server is unavailable
pax: nss_ldap: could not search LDAP server - Server is unavailable
sudo: nss_ldap: could not search LDAP server - Server is unavailable
Dans le même ordre d'idée, Postfix s'est pris les pieds dans le LDAP,
alors que rien dans sa config ne pointe vers le LDAP :
smtp/bounce[92176]: nss_ldap: failed to bind to LDAP server
ldap://MONLDAP: Can't contact LDAP server
smtp/bounce[92176]: nss_ldap: reconnecting to LDAP server (sleeping 8
seconds)...
postfix-mailgw/cleanup[92148]: nss_ldap: reconnected to LDAP server
ldap://MONLDAP after 4 attempts
smtp/bounce[92176]: nss_ldap: reconnected to LDAP server ldap://MONLDAP
after 3 attempts
postfix-mailgw/bounce[92154]: nss_ldap: reconnected to LDAP server
ldap://ldappublic.univ-lyon2.fr after 4 attempts
postfix-smtp-listes/scache[92161]: nss_ldap: reconnected to LDAP server
ldap://MONLDAP after 4 attempts
postfix-smtp-listes/smtp[92160]: nss_ldap: reconnected to LDAP server
ldap://MONLDAP after 4 attempts
Comment puis-je me prémunir de ce genre de problème ? (à part en
consolidant le LDAP, il ne dépend pas de moi).
Ma config s'appuie sur un /etc/pam.d/sshd modifié pour utiliser le LDAP
et un /usr/local/etc/pam.d/sudo qui pointe non plus vers system, mais
vers sshd.
/usr/local/etc/nss_ldap.conf est un lien vers /usr/local/etc/ldap.conf
Y-a-t'il un moyen de découpler le login ssh+sudo du reste ? Je veux
juste que certaines personnes présentes dans le LDAP puisse se connecter
à la machine et faire un sudo. Je ne veux pas que cron, xinetd, smtpd et
autres process ne fonctionnent plus, ou très mal, quand le LDAP tombe.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Comment puis-je me prémunir de ce genre de problème ? (à part en consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
-- J'ai essayé de creer un news un alt.west.virginia ou sur d'autres alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait? l'emetteur d'un new recoit il un avertissement si celui ci est censuré? -+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
Comment puis-je me prémunir de ce genre de problème ? (à part en
consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page
suivante :
http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
--
J'ai essayé de creer un news un alt.west.virginia ou sur d'autres
alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait?
l'emetteur d'un new recoit il un avertissement si celui ci est censuré?
-+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
Comment puis-je me prémunir de ce genre de problème ? (à part en consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
-- J'ai essayé de creer un news un alt.west.virginia ou sur d'autres alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait? l'emetteur d'un new recoit il un avertissement si celui ci est censuré? -+- LM in: <http://www.le-gnu.net> - Bien sansurer ses news sur C-I -+-
patpro ~ Patrick Proniewski
In article , Eric Masson wrote:
patpro ~ Patrick Proniewski writes:
'Lut,
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,0 0.html
Merci pour les pistes. Malheureusement je ne vois pas d'amélioration autre que de lancer nscd pour utiliser le cache :/ Ou alors j'ai raté un truc.
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se connectent que très rarement à la machine, n'ont pas de crontab...
Je ne comprends pas que le moindre truc parte en requête LDAP.
Puis là, j'ai lancé nscd, ajouté cache dans quelques entrées de mon nsswitch.conf, relancé nsswitch et j'ai une avalanche de plantages :
Dec 7 16:13:11 kernel: pid 161 (showq), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99619 (cleanup), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99618 (trivial-rewrite), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99621 (bounce), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99620 (scache), uid 0: exited on signal 11 Dec 7 16:13:18 kernel: pid 159 (trivial-rewrite), uid 0: exited on signal 11 Dec 7 16:13:22 kernel: pid 171 (error), uid 0: exited on signal 11 Dec 7 16:13:23 kernel: pid 170 (smtp), uid 0: exited on signal 11 Dec 7 16:13:32 kernel: pid 99624 (bounce), uid 0: exited on signal 11
Je vais voir si ça revient à la normale, mais quand même, ça craint mon affaire.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <rmt1t7-gur1.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
> Comment puis-je me prémunir de ce genre de problème ? (à part en
> consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page
suivante :
http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,0
0.html
Merci pour les pistes. Malheureusement je ne vois pas d'amélioration
autre que de lancer nscd pour utiliser le cache :/
Ou alors j'ai raté un truc.
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il
devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se
connectent que très rarement à la machine, n'ont pas de crontab...
Je ne comprends pas que le moindre truc parte en requête LDAP.
Puis là, j'ai lancé nscd, ajouté cache dans quelques entrées de mon
nsswitch.conf, relancé nsswitch et j'ai une avalanche de plantages :
Dec 7 16:13:11 kernel: pid 161 (showq), uid 0: exited on signal 11
Dec 7 16:13:11 kernel: pid 99619 (cleanup), uid 0: exited on signal 11
Dec 7 16:13:11 kernel: pid 99618 (trivial-rewrite), uid 0: exited on
signal 11
Dec 7 16:13:11 kernel: pid 99621 (bounce), uid 0: exited on signal 11
Dec 7 16:13:11 kernel: pid 99620 (scache), uid 0: exited on signal 11
Dec 7 16:13:18 kernel: pid 159 (trivial-rewrite), uid 0: exited on
signal 11
Dec 7 16:13:22 kernel: pid 171 (error), uid 0: exited on signal 11
Dec 7 16:13:23 kernel: pid 170 (smtp), uid 0: exited on signal 11
Dec 7 16:13:32 kernel: pid 99624 (bounce), uid 0: exited on signal 11
Je vais voir si ça revient à la normale, mais quand même, ça craint mon
affaire.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,0 0.html
Merci pour les pistes. Malheureusement je ne vois pas d'amélioration autre que de lancer nscd pour utiliser le cache :/ Ou alors j'ai raté un truc.
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se connectent que très rarement à la machine, n'ont pas de crontab...
Je ne comprends pas que le moindre truc parte en requête LDAP.
Puis là, j'ai lancé nscd, ajouté cache dans quelques entrées de mon nsswitch.conf, relancé nsswitch et j'ai une avalanche de plantages :
Dec 7 16:13:11 kernel: pid 161 (showq), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99619 (cleanup), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99618 (trivial-rewrite), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99621 (bounce), uid 0: exited on signal 11 Dec 7 16:13:11 kernel: pid 99620 (scache), uid 0: exited on signal 11 Dec 7 16:13:18 kernel: pid 159 (trivial-rewrite), uid 0: exited on signal 11 Dec 7 16:13:22 kernel: pid 171 (error), uid 0: exited on signal 11 Dec 7 16:13:23 kernel: pid 170 (smtp), uid 0: exited on signal 11 Dec 7 16:13:32 kernel: pid 99624 (bounce), uid 0: exited on signal 11
Je vais voir si ça revient à la normale, mais quand même, ça craint mon affaire.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Eric Masson
patpro ~ Patrick Proniewski writes:
'Lut,
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
Je vais voir si ça revient à la normale, mais quand même, ça craint mon affaire.
Tu utilises nss_ldap ou nss_ldapd ?
--
c'est ce con appelle une remarque idiote
-+- AM in Guide du Neuneu Usenet : Le méta-neuneu est arrivé -+-
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il
devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se
connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
Je vais voir si ça revient à la normale, mais quand même, ça craint mon
affaire.
Tu utilises nss_ldap ou nss_ldapd ?
--
c'est ce con appelle une remarque idiote
-+- AM in Guide du Neuneu Usenet : Le méta-neuneu est arrivé -+-
99,999% de mes requêtes doivent s'arrêter avec succès sur file, il devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
Je vais voir si ça revient à la normale, mais quand même, ça craint mon affaire.
Tu utilises nss_ldap ou nss_ldapd ?
--
c'est ce con appelle une remarque idiote
-+- AM in Guide du Neuneu Usenet : Le méta-neuneu est arrivé -+-
talon
patpro ~ Patrick Proniewski wrote:
Et mon etc/nsswitch.conf contient ceci :
Je pense que c'est ici que tout se met à dépendre de ldap! Es-tu bien sûr que tu as besoin de modifier nsswitch.conf pour que le login ssh fonctionne? Il est clair que tous les programmes locaux font sans arrêt des appels getpwuid() etc. qui attaquent nsswitch et donc ldap dans ta configuration.
Y-a-t'il un moyen de d?coupler le login ssh+sudo du reste ? Je veux juste que certaines personnes pr?sentes dans le LDAP puisse se connecter ? la machine et faire un sudo. Je ne veux pas que cron, xinetd, smtpd et autres process ne fonctionnent plus, ou tr?s mal, quand le LDAP tombe.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou sa version réseau), et mon expérience est que ceci couvre la quasi totalité des programmes, ils seront tétanisés dès que le ldap tombe, ou les pages jaunes .... J'ai vécu avec ce problème dans mon labo, et la seule solution efficace que j'ai trouvée est d'avoir un compte local sur *ma* machine qui continue à tourner quelle que soit la situation du serveur (ldap, yp, etc.). Une autre solution est de te constituer un cache local, par exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est que tu ne peux pas compter sur le bon fonctionnement du serveur distant, l'expérience prouve que plus un service est centralisé et abondamment pourvu d'"admin sys", plus il a de chance d'être foireux.
patpro
--
Michel TALON
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Et mon etc/nsswitch.conf contient ceci :
Je pense que c'est ici que tout se met à dépendre de ldap!
Es-tu bien sûr que tu as besoin de modifier nsswitch.conf
pour que le login ssh fonctionne? Il est clair que tous les programmes
locaux font sans arrêt des appels getpwuid() etc. qui attaquent
nsswitch et donc ldap dans ta configuration.
Y-a-t'il un moyen de d?coupler le login ssh+sudo du reste ? Je veux
juste que certaines personnes pr?sentes dans le LDAP puisse se connecter
? la machine et faire un sudo. Je ne veux pas que cron, xinetd, smtpd et
autres process ne fonctionnent plus, ou tr?s mal, quand le LDAP tombe.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des
programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou
sa version réseau), et mon expérience est que ceci couvre la quasi
totalité des programmes, ils seront tétanisés dès que le ldap tombe,
ou les pages jaunes ....
J'ai vécu avec ce problème dans mon labo, et la seule solution efficace
que j'ai trouvée est d'avoir un compte local sur *ma* machine qui
continue à tourner quelle que soit la situation du serveur (ldap, yp,
etc.). Une autre solution est de te constituer un cache local, par
exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est
que tu ne peux pas compter sur le bon fonctionnement du serveur distant,
l'expérience prouve que plus un service est centralisé et abondamment
pourvu d'"admin sys", plus il a de chance d'être foireux.
Je pense que c'est ici que tout se met à dépendre de ldap! Es-tu bien sûr que tu as besoin de modifier nsswitch.conf pour que le login ssh fonctionne? Il est clair que tous les programmes locaux font sans arrêt des appels getpwuid() etc. qui attaquent nsswitch et donc ldap dans ta configuration.
Y-a-t'il un moyen de d?coupler le login ssh+sudo du reste ? Je veux juste que certaines personnes pr?sentes dans le LDAP puisse se connecter ? la machine et faire un sudo. Je ne veux pas que cron, xinetd, smtpd et autres process ne fonctionnent plus, ou tr?s mal, quand le LDAP tombe.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou sa version réseau), et mon expérience est que ceci couvre la quasi totalité des programmes, ils seront tétanisés dès que le ldap tombe, ou les pages jaunes .... J'ai vécu avec ce problème dans mon labo, et la seule solution efficace que j'ai trouvée est d'avoir un compte local sur *ma* machine qui continue à tourner quelle que soit la situation du serveur (ldap, yp, etc.). Une autre solution est de te constituer un cache local, par exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est que tu ne peux pas compter sur le bon fonctionnement du serveur distant, l'expérience prouve que plus un service est centralisé et abondamment pourvu d'"admin sys", plus il a de chance d'être foireux.
patpro
--
Michel TALON
patpro ~ Patrick Proniewski
In article , Eric Masson wrote:
patpro ~ Patrick Proniewski writes:
'Lut,
> 99,999% de mes requêtes doivent s'arrêter avec succès sur file, il > devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se > connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
C'est "success" non ? [success=return] est la politique implicite. Je veux bien le rajouter en dur, au cas où, mais à quoi se fier si le soft ne marche pas comme la doc le dit ? :)
> Je vais voir si ça revient à la normale, mais quand même, ça craint mon > affaire.
Tu utilises nss_ldap ou nss_ldapd ?
nss_ldap
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <cr02t7-gur1.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
> 99,999% de mes requêtes doivent s'arrêter avec succès sur file, il
> devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se
> connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
C'est "success" non ? [success=return] est la politique implicite. Je
veux bien le rajouter en dur, au cas où, mais à quoi se fier si le soft
ne marche pas comme la doc le dit ? :)
> Je vais voir si ça revient à la normale, mais quand même, ça craint mon
> affaire.
Tu utilises nss_ldap ou nss_ldapd ?
nss_ldap
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
> 99,999% de mes requêtes doivent s'arrêter avec succès sur file, il > devrait chercher dans le LDAP uniquement pour 2 uid, qui ne se > connectent que très rarement à la machine, n'ont pas de crontab...
Et en ajoutant [found=return] après files ?
C'est "success" non ? [success=return] est la politique implicite. Je veux bien le rajouter en dur, au cas où, mais à quoi se fier si le soft ne marche pas comme la doc le dit ? :)
> Je vais voir si ça revient à la normale, mais quand même, ça craint mon > affaire.
Tu utilises nss_ldap ou nss_ldapd ?
nss_ldap
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
talon
Eric Masson wrote:
patpro ~ Patrick Proniewski writes:
'Lut,
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
Ca ne peut pas résoudre son problème s'il ne dispose pas localement d'un fichier avec la totalité des utilisateurs susceptibles de se connecter par ssh, c'est à dire essentiellement une copie locale de la base ldap. Il n'est pas évident que l'admin de la base ldap laisse répliquer celle ci, en particulier les passwd pour des raisons de sécurité, si bien qu'au total "bienvenue au club".
--
Michel TALON
Eric Masson <emss@free.fr> wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
> Comment puis-je me prémunir de ce genre de problème ? (à part en
> consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page
suivante :
http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
Ca ne peut pas résoudre son problème s'il ne dispose pas localement d'un
fichier avec la totalité des utilisateurs susceptibles de se connecter
par ssh, c'est à dire essentiellement une copie locale de la base ldap.
Il n'est pas évident que l'admin de la base ldap laisse répliquer celle
ci, en particulier les passwd pour des raisons de sécurité, si bien
qu'au total "bienvenue au club".
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Tu as regardé du coté de la page de man nsswitch.conf ?
La section EXAMPLES devrait amha te donner des idées ainsi que la page suivante : http://searchsystemschannel.techtarget.com/generic/0,295582,sid99_gci1523744,00.html
Ca ne peut pas résoudre son problème s'il ne dispose pas localement d'un fichier avec la totalité des utilisateurs susceptibles de se connecter par ssh, c'est à dire essentiellement une copie locale de la base ldap. Il n'est pas évident que l'admin de la base ldap laisse répliquer celle ci, en particulier les passwd pour des raisons de sécurité, si bien qu'au total "bienvenue au club".
--
Michel TALON
patpro ~ Patrick Proniewski
In article <idlklj$2iti$, (Michel Talon) wrote:
patpro ~ Patrick Proniewski wrote: > > Et mon etc/nsswitch.conf contient ceci : >
Je pense que c'est ici que tout se met à dépendre de ldap! Es-tu bien sûr que tu as besoin de modifier nsswitch.conf pour que le login ssh fonctionne? Il est clair que tous les programmes locaux font sans arrêt des appels getpwuid() etc. qui attaquent nsswitch et donc ldap dans ta configuration.
le LDAP devrait recevoir une requête seulement quand l'UID ou le GUI rencontré n'est pas trouvé dans "files". Ce qui n'est jamais le cas, sauf exception si une des deux personnes autorisées se connecte. Et là, tu me fais penser à quelque chose :
J'ai dans ma conf sshd un allowusers avec des logins provenant du LDAP. Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
Pour revenir à ta question, je ne sais pas si c'est obligatoire de modifier nsswitch.conf, j'ai suivi le handbook FreeBSD, car les histoires de PAM ne me sont pas du tout familières, et j'avais besoin d'être guidé.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou sa version réseau), et mon expérience est que ceci couvre la quasi totalité des programmes, ils seront tétanisés dès que le ldap tombe, ou les pages jaunes .... J'ai vécu avec ce problème dans mon labo, et la seule solution efficace que j'ai trouvée est d'avoir un compte local sur *ma* machine qui continue à tourner quelle que soit la situation du serveur (ldap, yp, etc.). Une autre solution est de te constituer un cache local, par exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est que tu ne peux pas compter sur le bon fonctionnement du serveur distant, l'expérience prouve que plus un service est centralisé et abondamment pourvu d'"admin sys", plus il a de chance d'être foireux.
Je suis d'accord. De toute manière les deux personnes du LDAP autorisées à se connecter sur la machine sont justement les admin du LDAP. Donc elles peuvent réparer le LDAP pour se connecter. Par contre ce qui m'embête c'est l'effondrement des services comme le SMTP quand le LDAP ne marche plus, juste à cause du fait que j'ai voulu faire en sorte que des UID du LDAP soient autorisés à se connecter en SSH sur la machine. Déjà je suis pas fan de LDAP, mais là, ça me file carrément de l'urticaire.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <idlklj$2iti$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
>
> Et mon etc/nsswitch.conf contient ceci :
>
Je pense que c'est ici que tout se met à dépendre de ldap!
Es-tu bien sûr que tu as besoin de modifier nsswitch.conf
pour que le login ssh fonctionne? Il est clair que tous les programmes
locaux font sans arrêt des appels getpwuid() etc. qui attaquent
nsswitch et donc ldap dans ta configuration.
le LDAP devrait recevoir une requête seulement quand l'UID ou le GUI
rencontré n'est pas trouvé dans "files". Ce qui n'est jamais le cas,
sauf exception si une des deux personnes autorisées se connecte.
Et là, tu me fais penser à quelque chose :
J'ai dans ma conf sshd un allowusers avec des logins provenant du LDAP.
Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement
des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
Pour revenir à ta question, je ne sais pas si c'est obligatoire de
modifier nsswitch.conf, j'ai suivi le handbook FreeBSD, car les
histoires de PAM ne me sont pas du tout familières, et j'avais besoin
d'être guidé.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des
programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou
sa version réseau), et mon expérience est que ceci couvre la quasi
totalité des programmes, ils seront tétanisés dès que le ldap tombe,
ou les pages jaunes ....
J'ai vécu avec ce problème dans mon labo, et la seule solution efficace
que j'ai trouvée est d'avoir un compte local sur *ma* machine qui
continue à tourner quelle que soit la situation du serveur (ldap, yp,
etc.). Une autre solution est de te constituer un cache local, par
exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est
que tu ne peux pas compter sur le bon fonctionnement du serveur distant,
l'expérience prouve que plus un service est centralisé et abondamment
pourvu d'"admin sys", plus il a de chance d'être foireux.
Je suis d'accord. De toute manière les deux personnes du LDAP autorisées
à se connecter sur la machine sont justement les admin du LDAP. Donc
elles peuvent réparer le LDAP pour se connecter.
Par contre ce qui m'embête c'est l'effondrement des services comme le
SMTP quand le LDAP ne marche plus, juste à cause du fait que j'ai voulu
faire en sorte que des UID du LDAP soient autorisés à se connecter en
SSH sur la machine.
Déjà je suis pas fan de LDAP, mais là, ça me file carrément de
l'urticaire.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
patpro ~ Patrick Proniewski wrote: > > Et mon etc/nsswitch.conf contient ceci : >
Je pense que c'est ici que tout se met à dépendre de ldap! Es-tu bien sûr que tu as besoin de modifier nsswitch.conf pour que le login ssh fonctionne? Il est clair que tous les programmes locaux font sans arrêt des appels getpwuid() etc. qui attaquent nsswitch et donc ldap dans ta configuration.
le LDAP devrait recevoir une requête seulement quand l'UID ou le GUI rencontré n'est pas trouvé dans "files". Ce qui n'est jamais le cas, sauf exception si une des deux personnes autorisées se connecte. Et là, tu me fais penser à quelque chose :
J'ai dans ma conf sshd un allowusers avec des logins provenant du LDAP. Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
Pour revenir à ta question, je ne sais pas si c'est obligatoire de modifier nsswitch.conf, j'ai suivi le handbook FreeBSD, car les histoires de PAM ne me sont pas du tout familières, et j'avais besoin d'être guidé.
Oui mais si tes utilisateurs distants ont besoin d'exécuter des programmes qui ont besoin de près ou de loin de "lire /etc/passwd" (ou sa version réseau), et mon expérience est que ceci couvre la quasi totalité des programmes, ils seront tétanisés dès que le ldap tombe, ou les pages jaunes .... J'ai vécu avec ce problème dans mon labo, et la seule solution efficace que j'ai trouvée est d'avoir un compte local sur *ma* machine qui continue à tourner quelle que soit la situation du serveur (ldap, yp, etc.). Une autre solution est de te constituer un cache local, par exemple un serveur ldap local miroir de l'autre. Ce qui est sûr c'est que tu ne peux pas compter sur le bon fonctionnement du serveur distant, l'expérience prouve que plus un service est centralisé et abondamment pourvu d'"admin sys", plus il a de chance d'être foireux.
Je suis d'accord. De toute manière les deux personnes du LDAP autorisées à se connecter sur la machine sont justement les admin du LDAP. Donc elles peuvent réparer le LDAP pour se connecter. Par contre ce qui m'embête c'est l'effondrement des services comme le SMTP quand le LDAP ne marche plus, juste à cause du fait que j'ai voulu faire en sorte que des UID du LDAP soient autorisés à se connecter en SSH sur la machine. Déjà je suis pas fan de LDAP, mais là, ça me file carrément de l'urticaire.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
xavier
patpro ~ Patrick Proniewski wrote:
Comment puis-je me prémunir de ce genre de problème ? (à part en consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom l'indique, toutes les requêtes pour des services réseaux (y compris sockets ? là je ne sais pas) passent par là.
C'est là que tu vois toute la peine des admins Windows, où *tout* est objet LDAP... que tu ne contrôles même pas, à l'inverse de MacOSX, ou tu *peux* recréer un objet à l'identique, avec les mêmes SID/GID/UUID. Enfin, si, tu peux en théorie avec ADSiEdit, mais la probabilité de tout casser est proche de 100%
-- XAv - moi, j'avais fait des études pour devenir ingé infomatique, pas admin Windows... In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Comment puis-je me prémunir de ce genre de problème ? (à part en
consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom
l'indique, toutes les requêtes pour des services réseaux (y compris
sockets ? là je ne sais pas) passent par là.
C'est là que tu vois toute la peine des admins Windows, où *tout* est
objet LDAP... que tu ne contrôles même pas, à l'inverse de MacOSX, ou tu
*peux* recréer un objet à l'identique, avec les mêmes SID/GID/UUID.
Enfin, si, tu peux en théorie avec ADSiEdit, mais la probabilité de tout
casser est proche de 100%
--
XAv - moi, j'avais fait des études pour devenir ingé infomatique, pas
admin Windows...
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Comment puis-je me prémunir de ce genre de problème ? (à part en consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom l'indique, toutes les requêtes pour des services réseaux (y compris sockets ? là je ne sais pas) passent par là.
C'est là que tu vois toute la peine des admins Windows, où *tout* est objet LDAP... que tu ne contrôles même pas, à l'inverse de MacOSX, ou tu *peux* recréer un objet à l'identique, avec les mêmes SID/GID/UUID. Enfin, si, tu peux en théorie avec ADSiEdit, mais la probabilité de tout casser est proche de 100%
-- XAv - moi, j'avais fait des études pour devenir ingé infomatique, pas admin Windows... In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
patpro ~ patrick proniewski
In article <1jt4yw1.beejqz19hckjqN%, (Xavier) wrote:
patpro ~ Patrick Proniewski wrote:
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom l'indique, toutes les requêtes pour des services réseaux (y compris sockets ? là je ne sais pas) passent par là.
il est dans mon post original, mais je vais te donner le nouveau qui utilise le cache de nscd :
l'ancien n'avait pas les "cache", c'est la seule différence entre maintenant et mon post original.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1jt4yw1.beejqz19hckjqN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
> Comment puis-je me prémunir de ce genre de problème ? (à part en
> consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom
l'indique, toutes les requêtes pour des services réseaux (y compris
sockets ? là je ne sais pas) passent par là.
il est dans mon post original, mais je vais te donner le nouveau qui
utilise le cache de nscd :
In article <1jt4yw1.beejqz19hckjqN%, (Xavier) wrote:
patpro ~ Patrick Proniewski wrote:
> Comment puis-je me prémunir de ce genre de problème ? (à part en > consolidant le LDAP, il ne dépend pas de moi).
Qu'il y a-t-il dans ton nsswitch.conf ? Parce que, comme son nom l'indique, toutes les requêtes pour des services réseaux (y compris sockets ? là je ne sais pas) passent par là.
il est dans mon post original, mais je vais te donner le nouveau qui utilise le cache de nscd :
l'ancien n'avait pas les "cache", c'est la seule différence entre maintenant et mon post original.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
F. Senault
Le 7 décembre 2010 à 16:59, patpro ~ Patrick Proniewski a écrit :
/.../
Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
C'est bien de là que vient ton problème - c'est le fichier groups qui contient des utilisateurs et non l'inverse ; ergo, tu es obligé d'énumérer tous les groupes (locaux & ldap) pour connaître la liste des groupes auxquels appartient un utilisateur, quel qu'il soit...
Ma solution a généralement été de laisser en fichiers la gestion des groupes.
Fred -- People are not programmed - one cannot simply ram a metaphorical serial cable up someone's arse and rewrite whatever bit of their source code is making them function incorrectly. (Alistair J. R. Young)
Le 7 décembre 2010 à 16:59, patpro ~ Patrick Proniewski a écrit :
/.../
Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement
des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
C'est bien de là que vient ton problème - c'est le fichier groups qui
contient des utilisateurs et non l'inverse ; ergo, tu es obligé
d'énumérer tous les groupes (locaux & ldap) pour connaître la liste des
groupes auxquels appartient un utilisateur, quel qu'il soit...
Ma solution a généralement été de laisser en fichiers la gestion des
groupes.
Fred
--
People are not programmed - one cannot simply ram a metaphorical serial
cable up someone's arse and rewrite whatever bit of their source code is
making them function incorrectly.
(Alistair J. R. Young)
Le 7 décembre 2010 à 16:59, patpro ~ Patrick Proniewski a écrit :
/.../
Et surtout j'ai dans /etc/groups un groupe avec des logins du LDAP.
Ça voudrait dire qu'à chaque requête sur group j'aurai obligatoirement des requêtes sur le LDAP ? Si c'est ça, le cache va bien aider...
C'est bien de là que vient ton problème - c'est le fichier groups qui contient des utilisateurs et non l'inverse ; ergo, tu es obligé d'énumérer tous les groupes (locaux & ldap) pour connaître la liste des groupes auxquels appartient un utilisateur, quel qu'il soit...
Ma solution a généralement été de laisser en fichiers la gestion des groupes.
Fred -- People are not programmed - one cannot simply ram a metaphorical serial cable up someone's arse and rewrite whatever bit of their source code is making them function incorrectly. (Alistair J. R. Young)
