<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 07/25/2014 01:46 AM, Anthony Messina
      wrote:<br>
    </div>
    <blockquote cite="mid:9995266.x8tqsJ07Iq@linux-ws1.messinet.com"
      type="cite">
      <pre wrap="">On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 07/23/2014 06:38 PM, Anthony Messina wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Looks like the schema file was changed, but not added to the list of 
files to be replaced at upgrade, I will open a 389 ticket and have it in

 the next release.


Could you try t copy file manually for now ?
</pre>
          </blockquote>
          <pre wrap="">


Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to 
/etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA 
masters and restarting seems to have eliminated the error.



Is there anything else that needs to be done?


</pre>
        </blockquote>
        <pre wrap="">
That should be all. BTW, the schema upgrade error is now fixed in
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20">https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20</a>
</pre>
      </blockquote>
      <pre wrap="">

With that update, my dirsrv error logs on both of my masters are flooded with 
the following errors.  Issuing 'ipactl restart' several times seems to reduce 
the incidence:

 - Connection is NULL and hence cannot access SLAPI_CONN_ID</pre>
    </blockquote>
    <br>
    Sorry about that - this will be fixed in 1.3.2.21.<br>
    <br>
    <blockquote cite="mid:9995266.x8tqsJ07Iq@linux-ws1.messinet.com"
      type="cite">
      <pre wrap="">

Also, I'm not sure if it's related to the above error, but the following are 
what I find related to the originally reported dnaremotebindmethod issue after 
upgrading both of my masters.

Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something other 
than (null) as a value?  Should they be the same on each master?

~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix-
ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com
SASL/GSSAPI authentication started
SASL username: <a class="moz-txt-link-abbreviated" href="mailto:admin@EXAMPLE.COM">admin@EXAMPLE.COM</a>
SASL SSF: 56
SASL data security layer installed.
dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com
objectClass: nsContainer
objectClass: top
cn: posix-ids

dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn
 =etc,dc=example,dc=com
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: ipa1.example.com
dnaPortNum: 389
dnaSecurePortNum: 636
dnaRemainingValues: 199972
dnaRemoteBindMethod: (null)
dnaRemoteConnProtocol: (null)</pre>
    </blockquote>
    <br>
    This looks wrong.  Please file a ticket.<br>
    <br>
    <blockquote cite="mid:9995266.x8tqsJ07Iq@linux-ws1.messinet.com"
      type="cite">
      <pre wrap="">

dn: dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn
 =etc,dc=example,dc=com
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: ipa2.example.com
dnaPortNum: 389
dnaSecurePortNum: 636
dnaRemainingValues: 0

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>