<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/05/2015 07:33 PM, thierry bordaz
      wrote:<br>
    </div>
    <blockquote cite="mid:5571DD63.8000300@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Hi,<br>
        <br>
        So far I am still unable to reproduce the problem.<br>
        Comparing the errors logs of failing replica vs successful
        replica they are very similar. Except this failure<br>
        <br>
        <br>
        Failing one<br>
        <blockquote><tt>...</tt><tt><br>
          </tt><tt>[03/Jun/2015:03:45:33 -0400]
            slapd_ldap_sasl_interactive_bind - Error: could not perform
            interactive bind for id [] mech [GSSAPI]: <b>LDAP error -1
              (Can't contact LDAP server)</b> ((null)) errno 115
            (Operation now in progress)</tt><tt><br>
          </tt><tt>[03/Jun/2015:03:45:33 -0400] slapi_ldap_bind - Error:
            could not perform interactive bind for id [] authentication
            mechanism [GSSAPI]: error -1 (Can't contact LDAP server)</tt><tt><br>
          </tt><tt>[03/Jun/2015:03:45:33 -0400] NSMMReplicationPlugin -
            agmt="cn=meTotestmaster.zaeba.li" (testmaster:389):
            Replication bind with GSSAPI auth failed: LDAP error -1
            (Can't contact LDAP server) ()</tt><tt><br>
          </tt><tt>[03/Jun/2015:03:45:38 -0400]
            slapd_ldap_sasl_interactive_bind - Error: could not perform
            interactive bind for id [] mech [GSSAPI]: LDAP error -1
            (Can't contact LDAP server) ((null)) errno 2 (No such file
            or directory)</tt><tt><br>
            <many errors><br>
            ...<br>
          </tt></blockquote>
        <br>
        Successful one:<br>
        <blockquote><tt>...</tt><tt><br>
          </tt><tt>[05/Jun/2015:17:51:20 +0200] NSMMReplicationPlugin -
            agmt="cn=meTovm-229.idm.lab.eng.brq.redhat.com"
            (vm-229:389): Replication bind with GSSAPI auth failed: <b>LDAP
              error -2 (Local error)</b> (SASL(-1): generic failure:
            GSSAPI Error: Unspecified GSS failure.  Minor code may
            provide more information (No Kerberos credentials
            available))</tt><tt><br>
          </tt><tt>[05/Jun/2015:17:51:23 +0200] NSMMReplicationPlugin -
            agmt="cn=meTovm-229.idm.lab.eng.brq.redhat.com"
            (vm-229:389): Replication bind with GSSAPI auth resumed</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:26 +0200] - slapd shutting down -
            signaling operation threads - op stack size 7 max work q
            size 2 max work q stack size 2</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:26 +0200] - slapd shutting down -
            waiting for 1 thread to terminate</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:26 +0200] - slapd shutting down -
            closing down internal subsystems and plugins</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:26 +0200] - Waiting for 4 database
            threads to stop</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:27 +0200] - All database threads
            now stopped</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:27 +0200] - slapd shutting down -
            freed 2 work q stack objects - freed 8 op stack objects</tt><tt><br>
          </tt><tt>[05/Jun/2015:18:47:27 +0200] - slapd stopped.</tt><tt><br>
            ...<br>
          </tt></blockquote>
        This is looking like in the failing case, the replica is not
        able to connect to the master. <br>
        In the successful tests I did not install DNS while it was
        installed in the failing tests.<br>
        We need to retry with DNS configuration, because it could be
        part of the failure to access the master host.<br>
      </div>
    </blockquote>
    <br>
    And I still fail to reproduce with DNS<br>
    <br>
    Master:<br>
    <blockquote><tt>#server install</tt><br>
      <tt>FREEIPACI_DNS_FORWARDER=x.y.z.t</tt><br>
      <tt>FREEIPACI_DNS_REVERSE_ZONE=e.f.g.h.......ip6.arpa.</tt><br>
      <tt>FREEIPACI_PASSWORD='Secret123'</tt><br>
      <tt>FREEIPACI_REALM=<REAL></tt><br>
      <tt>FREEIPACI_DOMAIN=<domain></tt><br>
      <br>
      <tt> </tt><br>
      <tt>ipa-server-install \</tt><br>
      <tt>    --setup-dns --forwarder=$FREEIPACI_DNS_FORWARDER \</tt><br>
      <tt>    -p $FREEIPACI_PASSWORD -a $FREEIPACI_PASSWORD \</tt><br>
      <tt>    -r $FREEIPACI_REALM -n $FREEIPACI_DOMAIN \</tt><br>
      <tt>    -U</tt><br>
    </blockquote>
    replica 1<br>
    <blockquote><tt>ipa-replica-install --setup-ca --setup-dns
        --forwarder x.y.z.t
        /var/lib/ipa/replica-info-<VM1_fqdn>.gpg</tt><br>
    </blockquote>
    replica 2<br>
    <blockquote><tt>ipa-replica-install --setup-ca --setup-dns
        --forwarder x.y.z.t /var/lib/ipa/replica-info-<VM2_fqdn>.gpg</tt><br>
      <br>
    </blockquote>
    The error log is not enough to find the root cause why replication
    was broken but we the most probable cause was<br>
    that the replicas did not find the master address.<br>
    <br>
    <br>
    <blockquote cite="mid:5571DD63.8000300@redhat.com" type="cite">
      <div class="moz-cite-prefix"> <br>
        thanks<br>
        theirry<br>
        <br>
        On 06/04/2015 07:27 PM, thierry bordaz wrote:<br>
      </div>
      <blockquote cite="mid:55708A82.8050402@redhat.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">Hello Oleg,<br>
          <br>
          So far I have been unable to reproduce the problem.<br>
          I tried various scenarios depending if the first update was on
          master/slave, or with 2 slaves, 1 slave, 1slave added later.<br>
          <br>
          Do you have any detail how you did your test ?<br>
          <br>
          If you can restart the remaining VM, I would be interested in
          the logs (access/errors).<br>
          <br>
          thanks<br>
          thierry<br>
          On 06/03/2015 11:11 AM, Oleg Fayans wrote:<br>
        </div>
        <blockquote cite="mid:556EC4BE.4080802@redhat.com" type="cite">Hi

          Martin, <br>
          <br>
          On 06/03/2015 10:46 AM, Martin Babinsky wrote: <br>
          <blockquote type="cite">On 06/03/2015 10:33 AM, Oleg Fayans
            wrote: <br>
            <blockquote type="cite">Hi, <br>
              <br>
              With the latest freeipa code containing Topology plugin
              patches, I am <br>
              unable to make any changes in replicas. <br>
              <br>
              I have the following topology: <br>
              replica1 <=> master <=> replica3 <br>
              Here is the output of the ipa topologysegment-find
              command: <br>
              <br>
              Suffix name: realm <br>
              ------------------ <br>
              2 segments matched <br>
              ------------------ <br>
                 Segment name: replica1.zaeba.li-to-testmaster.zaeba.li
              <br>
                 Left node: replica1.zaeba.li <br>
                 Right node: testmaster.zaeba.li <br>
                 Connectivity: both <br>
              <br>
                 Segment name: replica3.zaeba.li-to-testmaster.zaeba.li
              <br>
                 Left node: replica3.zaeba.li <br>
                 Right node: testmaster.zaeba.li <br>
                 Connectivity: both <br>
              ---------------------------- <br>
              Number of entries returned 2 <br>
              ---------------------------- <br>
              <br>
              <br>
              Any changes on master get replicated to replicas
              successfully. However, <br>
              any attempts to change anything on replicas, for example,
              create a user, <br>
              result in the error message about DatabaseError
              (attached). <br>
              <br>
              The corresponding part of the dirsrv log looks like this:
              <br>
              <br>
              03/Jun/2015:04:11:55 -0400] slapi_ldap_bind - Error: could
              not perform <br>
              interactive bind for id [] authentication mechanism
              [GSSAPI]: error -1 <br>
              (Can't contact LDAP server) <br>
              [03/Jun/2015:04:15:02 -0400] slapi_ldap_bind - Error:
              could not send <br>
              startTLS request: error -1 (Can't contact LDAP server)
              errno 0 (Success) <br>
              [03/Jun/2015:04:16:55 -0400]
              slapd_ldap_sasl_interactive_bind - Error: <br>
              could not perform interactive bind for id [] mech
              [GSSAPI]: LDAP error <br>
              -1 (Can't contact LDAP server) ((null)) errno 2 (No such
              file or directory) <br>
              [03/Jun/2015:04:16:55 -0400] slapi_ldap_bind - Error:
              could not perform <br>
              interactive bind for id [] authentication mechanism
              [GSSAPI]: error -1 <br>
              (Can't contact LDAP server) <br>
              <br>
              The full log is attached <br>
              <br>
              <br>
              <br>
            </blockquote>
            Hi Oleg, <br>
            <br>
            could you also post the output of 'journalctl -xe' related
            to dirsrv (on master and also on replicas)? I have seen a
            couple of segfaults there during reviewing Petr Vobornik's
            topology* commands. <br>
            <br>
          </blockquote>
          Attached <br>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>