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? Also, should the ticket be filed against 389, or against FreeIPA? > 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? -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
signature.asc
Description: This is a digitally signed message part.
-- 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