[Freeipa-users] attribute "dnaremotebindmethod" not allowed

Rich Megginson rmeggins at redhat.com
Fri Jul 25 17:00:05 UTC 2014


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

>
>
>> 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?
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140725/89246d54/attachment.htm>


More information about the Freeipa-users mailing list