I am using freeipa-server-3.3.5-1.fc20.x86_64 in a basic, two-server MMR setup between ipa1 and ipa2. I am reporting this issue per Rich's request here: https://www.redhat.com/archives/freeipa-users/2014-July/msg00263.html and as I hope to keep my systems properly updated in preparation for a future yum upgrade to Fedora 21 and FreeIPA 4.
After upgrading 389-ds-base from 1.3.2.16-1.fc20.x86_64 to 1.3.2.19-1.fc20.x86_64, I received the following errors in the dirsrv error log:
[17/Jul/2014:07:51:50 -0500] - Entry "dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com" -- attribute "dnaremotebindmethod" not allowed [17/Jul/2014:07:51:50 -0500] 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 reported the issue here: https://www.redhat.com/archives/freeipa-users/2014-July/msg00139.html
I then manually upgraed the schema files as suggested by Ludwig here: https://www.redhat.com/archives/freeipa-users/2014-July/msg00178.html
Then Martin reported here: https://www.redhat.com/archives/freeipa-users/2014-July/msg00225.html that the schema error was fixed and I then upgraded to 1.3.2.20-1.fc20.x86_64
Below are the differences between dnaRemoteBindMethod and dnaRemoteConnProtocol before and after the last upgrade:
Before upgrade to https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20
~]# 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: admin@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 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
After upgrade to https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20
~]# 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: admin@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) 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
Closing as a duplicate of #47861. Will be included in the next release 1.3.2.21.
While #47861 seems to fix the original problem of not updating schema files, it doesn't do much for {{{ dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) }}} which is why Rich wanted me to file this ticket in the first place. What ''should'' those values be in a FreeIPA setup?
Replying to [comment:2 amessina]:
The value should be the same value as in the replication agreement. Or, the attribute should not be present. Not sure which is the intention. "(null)" is not an acceptable value.
Replying to [comment:3 rmeggins]:
Replying to [comment:2 amessina]: While #47861 seems to fix the original problem of not updating schema files, it doesn't do much for {{{ dnaRemoteBindMethod: (null) dnaRemoteConnProtocol: (null) }}} which is why Rich wanted me to file this ticket in the first place. What ''should'' those values be in a FreeIPA setup? The value should be the same value as in the replication agreement. Or, the attribute should not be present. Not sure which is the intention. "(null)" is not an acceptable value.
After talking with Rich on IRC (Thank you, Rich!), I copied the values from the FreeIPA replication agreement {{{ nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaTransportInfo: LDAP }}}
and modified as follows: {{{ dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com changetype: modify replace: dnaRemoteBindMethod dnaRemoteBindMethod: SASL/GSSAPI - replace: dnaRemoteConnProtocol dnaRemoteConnProtocol: LDAP }}}
At least this will remove the invalid '''(null)''' values.
Sorry, amessina. I've talked with Rich and learned this is a new bug which should be fixed for 1.3.2.
Reopening it.
attachment 0001-add-attributes-only-if-they-have-a-value.patch
The attached patch should fix the issue although I did not yet reproduce.
NOTE: If instances had been upgrded to 1.3.2.20 or .21 before, the illegal values could be in the database and have to be removed explicitely by ldapmodify
attachment 0001-Ticket-47866-Errors-after-upgrading-related-to-attri.patch
committed to master: New commits: commit 3dcf4a9
committed to 1.3.2: New commits: commit f237812
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.2.23
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1197
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.