#47866 Errors after upgrading related to attribute "dnaremotebindmethod" not allowed
Closed: wontfix None Opened 9 years ago by amessina.

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]:

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.

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.

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

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata