Tuto Openldap, partie VI : Réplication

Vous aimerez aussi...

12 réponses

  1. LAINE dit :

    Merci beaucoup mec 🙂

    • Nicolas dit :

      De rien 😉
      J’ai refais quelques modification à l’instant pour info.

      Aujourd’hui, je traiterais de la mise en place de Keepalived pour avoir une IP unique.

  2. Vincent dit :

    Super merci ! Continue comme ça, ton blog est génial et surtout claire et DANS DES VERSIONS D’ACTUALITÉS ! Met en place une plateforme de don je n’hésiterai pas a te soutenir 🙂

    • Nicolas dit :

      Merci !
      Ce genre de commentaires fait toujours plaisir.
      En effet, je tente toujours d’être un maximum didactique dans mes explications en mettant l’accent sur les points qui m’auraient posés soucis, en expliquant comment j’ai solutionné, etc…
      Bref, pas de panique, je continue. Sur le LDAP, il doit me rester trois articles.
      Ensuite, ce sera un tuto sur la messagerie et un autre sur se monter un NAS à domicile (avec système de gestion de films, séries, etc…)
      Pour la partie don, ce n’est pas idiot, je vais regarder à cela.

  3. Vincent dit :

    Merci à toi 🙂 Si tu veux pousser sur le LDAP je pense que l’authentification avec Kerberos peutt-être super intéressant du fait que les docs sont assez pauvre sur le sujet 🙂
    La messagerie est intéressant, j’attends ça avec impatience 🙂

  4. Freakss dit :

    Merci pour ce tuto.
    Je rencontre un souci après avoir tout passé.
    J’ai cette erreur dans les logs:
    do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (32) No such object
    do_syncrep2: rid=002 (32) No such object
    do_syncrepl: rid=002 rc -2 retrying (4 retries left)

    Sauriez-vous me dire pourquoi svp?
    do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object
    do_syncrep2: rid=001 (32) No such object
    do_syncrepl: rid=001 rc -2 retrying (4 retries left)

    • Nicolas dit :

      Hum…
      Les acls pour la réplication sont bonnes ?
      Les comptes réplication également ?

      Je vais tacher de le refaire en test, voir si je n’aurais pas zappé un truc.

      Par contre, je vais être honnête, je pense refaire ce tuto, mais avec juste une réplication Master-Slave.
      Au final, le Slave qui reste Slave en cas de Down du Master n’est pas embêtant dans le cas du service LDAP.
      N’ayant aucune application en écriture dessus (ça ne sert au final que pour la lecture des comptes), il assure toujours le service pour mes autres serveurs et je peux remonter le master quand je veux, n’en ayant besoin que pour faire mes écritures…
      Au passage (oui, je travaille deja sur l’article, mais il n’est pas le prochain, désolé 😉 ) j’ajoute un système qui fait que Xen change la Ram activement en fonction de qui est en charge du service.
      Ainsi au final, si LDAP1 tombe, LDAP2 prend la relève pour les lectures, et voit sa Ram augmentée dynamiquement…
      Arrivant à une trentaine de Domu, je commence à bidouiller un peu…

  5. Jean-Luc Ch. dit :

    encore une fois merci pour ce tuto qui rend l’entrée dans LDAP simple et claire.
    Après avoir mis en place la réplication, je vois qu’après quelques semaines d’arrêt de l’un des serveurs, la réplication est devenue unidirectionnelle.
    Lorsque je regarde contextCSN, j’ai bien les deux valeurs sur chaque serveur, correspondant à chaque RID, pour la base cn=config.
    Par contre, pour les données, le serveur qui ne réplique pas les modifs de son homologue n’affiche qu’une ligne contextCSN (correspondant à son propre RID).
    Aurais tu une idée de la source du problème?

    • Nicolas dit :

      Encore une fois, de rien 😉

      Pour ton soucis, je pense que le pourquoi est dans la question : un des serveurs arreté trop longtemps.
      C’est toujours le problème avec les configs master-master.
      C’est lequel qui ne réplique pas ? Celui que tu as relancé ?

      Les logs disent quoi ?
      Au pire, je supprimerais la synchro et la remettrais en place.
      J’ai un article la dessus, mais c’est loin d’être terminé.

  6. Jean-Luc Ch. dit :

    Celui que j’ai relancé ne récupère pas en effet les modifs de celui resté allumé.
    J’ai un doute sur les logs. Je ne vois rien dans slapd.log. Je vais chercher faire mieux/

  7. Jean-Luc Ch. dit :

    Voici le log, en complément:
    Jan 11 01:00:17 lan-olp-001 slapd[13018]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (4) Size limit exceeded
    Jan 11 01:00:17 lan-olp-001 slapd[13018]: do_syncrep2: rid=001 (4) Size limit exceeded
    Jan 11 01:00:17 lan-olp-001 slapd[13018]: do_syncrepl: rid=001 rc -2 quitting

    Cela semble se produire lorsqu’un serveur est éteint trop longtemps, en effet. La résolution consisterait à permettre au compte de réplication d’outrepasser via des droits supplémentaires (time.soft=unlimited time.hard=unlimited). Tu proposes déjà de lever cette limitation dans ton tuto. Je ne parviens pas à voir de manière détaillée si le log porte sur la configuration ou sur les données. Je sens que je vais supprimer puis refaire la sync

  8. Dazounet dit :

    Salut, et merci pour ce tuto !
    Je suis dans un cas particulier où je souhaite ne répliquer qu’une OU de mon master sur mon slave. J’ai eu l’idée de n’injecter qu’un dump de cette OU et de ne donner le droit en lecture/écriture de mon utilisateur de réplication qu’à cette OU.
    Mais je galère encore avec les ACLs. Est-ce que c’est la bonne méthode ? Si oui, comment bien mettre en place cela et quels sont les points de vigilance à surveiller ? Parce que là je tourne en rond :/

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *