[Freeipa-users] attribute "dnaremotebindmethod" not allowed

[Anthony Messina]

On Friday, July 25, 2014 01:43:04 PM Anthony Messina wrote:
> On Friday, July 25, 2014 11:00:05 AM Rich Megginson wrote:
> > 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: admin at 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
> 
> Ticket filed: https://fedorahosted.org/389/ticket/47866
> 
> > 
> >
> > 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?

For others who may be looking into this issue, I copied the values from the 
FreeIPA replication agreement:

nsDS5ReplicaBindMethod: SASL/GSSAPI
nsDS5ReplicaTransportInfo: LDAP

and ldapmodify-d 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

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140804/f37876a0/attachment.sig>