PAM/LDAP et problème de disponibilité

Le
patpro ~ Patrick Proniewski
Bonjour,

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

Et mon etc/nsswitch.conf contient ceci :

group: files ldap
group_compat: nis
hosts: files dns
networks: files
passwd: files ldap
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files


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
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Masson
Le #22894351
patpro ~ Patrick Proniewski
'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:
patpro ~ Patrick Proniewski
Le #22894391
In article Eric Masson
patpro ~ Patrick Proniewski
'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
Eric Masson
Le #22894551
patpro ~ Patrick Proniewski
'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é -+-
talon
Le #22894541
patpro ~ Patrick Proniewski

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.

group: files ldap
group_compat: nis
hosts: files dns
networks: files
passwd: files ldap
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files


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
Le #22894641
In article Eric Masson
patpro ~ Patrick Proniewski
'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
talon
Le #22894631
Eric Masson
patpro ~ Patrick Proniewski
'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
patpro ~ Patrick Proniewski
Le #22894621
In article (Michel Talon) wrote:

patpro ~ Patrick Proniewski >
> 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
Le #22894911
patpro ~ Patrick Proniewski
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
Le #22895351
In article (Xavier) wrote:

patpro ~ Patrick Proniewski
> 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 :

group: cache files ldap
group_compat: nis
hosts: cache files dns
networks: files
passwd: cache files ldap
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

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 #22896781
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)
Publicité
Poster une réponse
Anonyme