Savez vous comment on peux configurer une authentification utilisant ldap avec la contrainte suivante : J'ai trois serveurs ldap (deux réplicas) et je souhaite pouvoir configurer les trois serveurs ldap sur le poste client afin qu'il y en ai toujours un qui marche !
Dans le fichier /etc/libnss-ldap.conf, on ne peux mettre qu'un seul serveur ldap ! Je n'ai vu nulle part comment en mettre un second. Idem pour la configuration du module libpam-ldap.
Par contre, aucun problème avec le fichier /etc/ldap/ldap.conf mais celui-là ne sers "que pour ldapsearch", ce qui ne réponds pas du tout à mon problème.
L'un de vous a t'il une solution à ce dilemme sachant que tous les sites parle de réplication de l'annuaire ldap mais qu'après, ils n'utilisent QUE l'annuaire maître dans les fichiers de configurations (sauf samba qui a prévu le coup).
Remarque annexe. On voir partout qu'il faut configurer et installer le module libpam-ldap alors que la configuration de nss suffit. Question annexe, dans les documentations , les auteurs configurent les deux. Peux t'on configurer libpam-ldap sans configurer la libnss-ldap ? Si non (comme je le crois), quel est l'apport réel de la libpam-ldap ?
Forum Linux.général libnss-ldap avec plusieurs serveurs ldap
20
jan.
2006
# slapd + slurpd + heartbeat + lvs
Posté par Mouns (site web personnel) . Évalué à 2.
maintenant, le detail de comment faire ... c une autre paire de manche.
la piste primordiale est : mettre le heartbeat/lvs uniquement sur des slaves en ReadOnly .
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par symoon . Évalué à 2.
"libnss-ldap failover"
http://www.metaconsultancy.com/whitepapers/ldap-linux.htm
uri ldap://ldap.example.com/ ldap://ldap-backup.example.com/
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par Mouns (site web personnel) . Évalué à 1.
oups, alors :)
sinon SLAPD est connu pour sa lenteur ... et il y a le projet tiny-ldap ( http://www.fefe.de/tinyldap/ ) du meme auteur que la dietlibc qui me semble assez sympathique.
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> cela sous entendait que l'on avait lu le manuel :(
J'avais lu pas mal de doc mais j'étais passé à coté de celle-là. Ca arrive... Si tu fouille un peu sur le net, tu verrais 50000 doc pour t'expliquer qu'il faut mettre un slapd esclave via slurpd mais très peu parlent d'une solution simple utilisant ces esclaves (à part samba).
La solution avec heartbeat + lvs fonctionne mais c'est vrai que je souhaitais un truc plus simple ou les clients intérrogent la première base qui répond. Ca ne me pose aucun problème de configuration même sur un gros parc machine car les postes s'autoconfigurent avec cfengine ;-)
Et puis heartbeat, si mes souvenirs sont bons (pas essayé les dernières versions), ca ne marche qu'entre deux machines. Comme tu fait si tu as un maître et trois esclaves ?
Autre question dans la même veine, est'il possible de configurer courier (imap) pour qu'il puisse intérroger plusieurs annuaires ?
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par Mouns (site web personnel) . Évalué à 2.
pour ce qui est du heartbeat, si heartbeat permet de prendre 2 machines pour n'en presenté qu'une ... , tu peux prendre 4 machines qui vont faire 2 qui vont faire une ( configuration tres moisi par contre ). reste comme alternative, puisque LDAP est un protocole qui peut etre synchrone ou non, mettre un "dispatcher" en heartbeat qui interroge autant de LDAP que tu veux ... l'overhead par requete etant faible tu pourras tenir une forte charge sans trop de difficulté.
pour ce qui est d'un environnement totalement LDAP , tu peux tout mettre sous LDAP. un probleme restera, l'interface d'administration. as tu une interface d'admin autre que de tout faire à la mano ? au moins des scripts de base pour les opérations les plus frequentes ?
Pour avoir regardé un peu partout, les schemas GOSA sont pas trop mal mais il faut quand meme les completer.
Ce qui revient a dire que tu dois penser FROM SCRATCH tes structures de données car quand tu auras tout mis en prod, tu ne pourras pas faire "oups, j'ai oublié un truc faut tout refaire".
à contrario, OpenLDAP etant un escargot niveau performance, j'ai du me resoudre d'abord avec du tiny-ldap puis quand je me suis rendu compte que je restaurais trop souvent les bases openldap alors que le probleme n'était ni un probleme hardware ni systeme ... je suis passé à contre coeur à une solution à base de SGBD-SQL :'(
pam et nss ont des implementation qui permettent d'interoger des SGBD-SQL.
des que je trouve le redhat-directory-server en {debian,Ubuntu} stable, je ferai un test car à l'époque ou c'était un produit Netscape, c'était la meilleur implementation LDAP du marché.
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Question charge, je suis autour de 150 utilisateurs... J'ai pas mal entendus de problème sur la tenue en charge d'openldap. Pour le moment, ca a l'air de tenir.
Question schema, je pense me faire mes propres outils en perl (ou bash) à partir d'une base existante. Le système tourne en production avec un seul annuaire ldap pour le moment ! Je suis en train de placer des secondaires ici ou là, a des endroits stratégiques. La base utilisateur est aussi à refaire, tous les utilisateurs ne sont pas des mêmes classes ! Mais ca marche...
Bref, j'aurais préféré commencer mieux mon entrée en matière concernant ldap. C'est en forgeant qu'on devient forgeron.
Les solutions que tu me proposes m'intéresse grandement dès que j'aurais stabilisé et fiabilisé mon système actuel avec les moyens actuels...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.