On 07/25/2014 10:43 AM, Anthony Messina wrote:
On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote:
On 07/25/2014 01:46 AM, Anthony Messina wrote:
On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote:
On 07/23/2014 06:38 PM, Anthony Messina wrote:
On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote:
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 ?

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?


That should be all. BTW, the schema upgrade error is now fixed in
https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20
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

Sorry about that - this will be fixed in 1.3.2.21.

Thank you, Rich.


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: ad...@example.com
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)

This looks wrong.  Please file a ticket.
I'm having trouble understanding the problem in order to file a ticket...

I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received the
schema errors as well as

dna-plugin - dna_update_shared_config: Unable to update shared config entry:
dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-
ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65]

I then upgraded to 389-ds-base-1.3.2.20-1.fc20.  Unfortunately, I cannot be
sure what *should* be present for each of dnaRemoteBindMethod and
dnaRemoteConnProtocol *or* if any original values were deleted when I first
installed 389-ds-base-1.3.2.19-1.fc20.x86_64.  If so, how would I know what
the values were?

I'm not sure. What I think is that these should not be present at all - I think they are just copied from the replication agreement configuration.


Also, should the ticket be filed against 389, or against FreeIPA?

389



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
Shouldn't the "second" master also have values for dnaRemoteBindMethod and
dnaRemoteConnProtocol?




-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to