Réplication Openldap ne se fait pas(syncrepl) [Résolu]

[darkukai]

Bonjour à tous(tes)

Je test une solution de réplication entre deux serveur OpenLdap sous debian,
J'ai commencer a utilisé le démon de réplication slurpd sur le serveur maitre avec toute la config adéquate au niveau du slapd.conf du serveur maitre et du serveur esclave et malheureusement rien de marchait, aucune sortie dans mes logs, pas de réplication, nada

Je me suis donc tourné vers la deuxième solution qui consiste a utilisé syncrepl, donc rebelote mais beaucoup plus rapide cette fois si car apparement la config ne se fait qu'au niveau du slapd.conf du serveur esclave dans lequel on rajoute :

Code x :

1
2
3
4
5
6
7
8
9
10
11
12
syncrepl  rid=007
  provider=@ip du serveur maitre
  type=refreshOnly
  interval=00:00:03:00
  searchbase="dc=domain,dc=com"
  filter="(objectClass==*)"
  scope=sub
  schemachecking=off
  updatedn="cn=replica,dc=domain,dc=com"
  bindmethod=simple
  binddn="cn=replica,dc=domain,dc=com"
  credentials=pass en clair

Et tout ce que j'obtiens dans me logs c'est un vague :
tail -f /var/log/ldaplog

Mar 22 (..) localhost slapd[1446]: do_syncrep1: ldap_initialize failed (@ip serveur maitre)

et aucun trace de connexion sur mes logs du serveur maitre
de plus un ldapsearch -x -h @ipserveur_maitre -b "dc=domain,dc=com" fonctionne super bien

Je pédale dans la semoule avec cette réplication qui ne se fait pas si quelqu'un a une petite idée qui pourrait me venir en aide je lui en serait reconnaissant


D'avance Merci
Thomas

[darkukai]

Rebonjour tout le monde

Alors j'apporte un peu d'eau a mon moulin ( mon moulin avait soif ---->[] )

J'ai oublié un truc apparement super important sur le serveur maitre (provider) c'est la directive sessionlog dans mon slapd.conf, c'est tout moi çà

m'enfin je rajoute donc

Code :

1
2
 
sessionlog 123 500

ou 123 est mon <sid> et 500 ma limite

je rajoute aussi coter slave dans mon slapd.conf

Code :

1
2
3
4
 
syncrepl ...
provider=ldap://10.203.195.1:389
...

pour etre sur qu'il ne lui manque rien pour papoter avec son copain.

Je fais aussi un truc stupide ( j'ai lu sur un howto qui avait l'air sérieux qu'il vallait mieux partir avec des bases strictement identiques)
donc je copie innocement tout le dossier /var/lib/ldap de mon provider sur le /var/lib/ldap/ de mon slave

je fais un /etc/init.d/slapd restart sur le slave pour voir ce qui se passe et là : çà papote
j'ai même la trace de ma connec sur mon maitre génialllllll .... mais normal en fait

le truc c'est que je pense qu'il a pas apprécié la copie de dossier puisque dans les logs de mon slave j'ai un truc comme çà :

Code :

1
2
3
4
5
6
 
sldap starting
<= bdb_equality_candidates: (entryUUID) index_param failed (18)
last message repeated 5 times
null_callback: error code 0x32
bdb_db_inbit: Initializing BDB database

n'aurait t'il pas apprécié ma sauvage copie de dossier ????

une solution simple de réplication ne saurait t'elle pas alors de faire un script qui copie tout le dossier /var/lib a intervalle régulier


M'enfin encore des questions soulevées qui attendront qu'une ame charitable ou mon compagnon google m'aide a trouver les réponses.

[darkukai]

Bonjour,
Finalement je me prend d'affection pour mon problème je pense que l'on va vivre une longue histoire

Après quelques recherche j'ai entrapreçu le faites qu'il fallait index l'entrée EntryUUID pour que çà marche et ce sur les deux serveurs donc ni une ni d'hirondelle je fait la manip sur mes deux serveurs :

vi /etc/slapd.conf

...
Index EntryUUID eq
....

et effectivement çà semble apporté sont petit plus puisque je n'ai plus lors de la tentative de réplication de message sur le slave :
Code:

<= bdb_equality_candidates: (entryUUID) index_param failed (18)


cependant j'ai du coup :

Code:

syncrepl_entry : be_modify failed (50)
null callback
be_add failed (50)


Il me semble que l'erreur 50 dans ldap signifie un problème de droit d'accès mais je peux me tromper,
je vérifie mes ACL mais elles semblent bonne Sad dans le doute je remplace l'utilisateur replica que j'utilise pour le bind et la MAJ par l'admin de la base mais sans plus de succès.

Je suis désormais la piste de la version trop vieille, j'ai lu en effet qu'une bonne 15aine de bugs était réferencé concernant syncrepl entre la version 2.2 distribué sur sarge et la toute dernière version, je vais donc tenter ce matin de mettre a jours mes deux openldap ( fait $%#&! quand même.. ouuuh pardon )

EDIT / Bon bein je viens d'essayer de mettre a jour mon slapd en 2.3.30-5 en modifiant mon sources.list pour récupérer la version de la testing mais un gros message d'alerte ( en gros : ' Pour satisfaire toute les dépendances nous allons devoir viré votre kernell image version 2.4 .... ce qui est somme toute déplaisant pour la bonne marche du système, je repète çà craint vraiment de le faire si tu le fait c'est que t'est vraiment un #*$$@ !)
Bon du coup je me suis calmé je crois que j'ai une galette de la testing dans un coin je vais me refaire mes install sur mes serveurs test en testing mais çà me fais bien §<*$# = ! car le serveur en prod est sur sarge

Donc si quelqu'un a trouvé une astuce pour passer sur sarge de slapd 2.2 a la 2.3 qu'il me fasse un petit coucou

[darkukai]

Bon alors mise en place de deux serveurs sous Etch pour avoir openldap 2.3

Config serveur maitre :
vi /etc/ldap/slapd.conf

Code :

1
2
3
4
5
6
7
8
9
10
11
 
...
moduleload syncprov
...
index entryUUID,entryCSN eq
...
rootdn    "cn=admin,dc=mondomain,dc=net
...
overlay syncprov
           syncprov-checkpoint 50 5
           syncprov-sessionlog 50

Config serveur esclave

vi /etc/ldap/slapd.conf

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
rootdn      "cn=admin,dc=mondomain,dc=net"
...
index   entryUUID,entryCSN eq
...
syncrepl rid=123
             provider=ldap://@ipduserveurmaitre:389
             type=refreshOnly
             interval=00:00:05:00
             searchbase="dc=mondomain,dc=net"
             filter="(objectClasse=*)"
             scope=sub
             schemachecking=off
             bindmethod=simple
             binddn="cn=admin,dc=mondomain,dc=net"
             credentials=motdepasseenclair

Et çà marche !!!!! normal meuh direz vous c'est quand même fait pour çà

Bon j'ai sur les deux serveurs des erreurs : rootdn have already superprivilege on database mais sinon çà marche.

La seul ombre au tableau c'est que je veut implémenter cette solution entre mon serveur de mail déjà en production qui serait le serveur maitre et un backupMX qui serait en slave mais mon serveur mail est sous sarge et est hypra stable donc je pensais pas le migrer sous etch avant un bon moment

[elbronziero]

Salut,

tu devrais pouvoir compiler toi meme une version plus récente de ton openldap pour qu'elle marche avec ton noyau....
Enfin, je dis ca, c'est pour t'éviter de passer en 2.6....
Fais un essai sur une install a blanc d'abord, mais ca a des chances de bien fonctionner