[Freeipa-users] Replica not syncing 'memberOf' attributes

Dan Scott danieljamesscott at gmail.com
Thu Oct 7 14:43:15 UTC 2010


On Thu, Oct 7, 2010 at 10:20, Rich Megginson <rmeggins at redhat.com> wrote:
> Dan Scott wrote:
>>
>> On Wed, Oct 6, 2010 at 22:02, Rich Megginson <rmeggins at redhat.com> wrote:
>>
>>>
>>> Dan Scott wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> On Wed, Oct 6, 2010 at 18:30, Rich Megginson <rmeggins at redhat.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Dan Scott wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> I'm not sure which group this is referring to. Admins only contains 3
>>>>>> users, no nested groups.
>>>>>>
>>>>>> The problem appears to be related to the users, rather than the
>>>>>> groups. None of the users on ohm have a 'memberOf'. Curie has the
>>>>>> correct memberOf attributes.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> The error message specifically mentions the admin group:
>>>>>
>>>>> - Entry "cn=admins,cn=groups,cn=accounts,dc=example,dc=com" --
>>>>> attribute "memberOf" not allowed
>>>>>
>>>>> As if it is attempting to add the memberOf attribute to the group entry
>>>>> cn=admins,cn=groups,cn=accounts,dc=example,dc=com - I don't know why it
>>>>> would do this unless it is attempting some sort of group nesting.
>>>>>
>>>>>
>>>
>>> This is still a mystery - we need to figure out why it is attempting to
>>> add
>>> memberOf to this entry.
>>>
>>>>>>
>>>>>> The groups themselves appear to be correct on both servers. Both ohm
>>>>>> and curie have groups which contain the correct 'member' attributes.
>>>>>> So the problem appears to be that ohm contains groups with correct
>>>>>> 'members', but none of the users have any 'memberOf's.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Do all of the users have the inetUser objectclass?
>>>>>
>>>>>
>>>>
>>>> Yep. Looks like it. I have 162 users:
>>>>
>>>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b
>>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc
>>>>   162     324    3564
>>>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b
>>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass:
>>>> inetUser'|wc
>>>>   162     324    3564
>>>> [djscott at ohm ~]$
>>>>
>>>>
>>>
>>> If you run the lib/dirsrv/slapd-ds/fixup-memberof.pl script, does it add
>>> the
>>> memberOf attributes?
>>>
>>
>> When I try to run that, I get the following:
>>
>> [root at ohm ~]# /usr/lib64/dirsrv/slapd-EXAMPLE.COM/fixup-memberof.pl -b
>> cn=groups,cn=accounts,dc=example,dc=com -D uid=admin -w -
>> Bind Password: *************
>>
>> ldap_simple_bind: No such object
>>
>
> uid=admin is not the full DN - should be something like
> uid=admin,cn=accounts,dc=example,dc=com or something like that?

Sorry about that, I now get:

adding new entry cn=memberOf_fixup_2010_10_7_10_41_11, cn=memberOf
task, cn=tasks, cn=config
ldap_add: Insufficient access

I have an admin Kerberos ticket and I know the password is correct
because otherwise I get 'ldap_simple_bind: Invalid credentials'.

Thanks,

Dan

>>
>> Thanks,
>>
>> Dan
>>
>>
>>>>>>
>>>>>> On Wed, Oct 6, 2010 at 16:17, Rich Megginson <rmeggins at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Dan Scott wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
>>>>>>>> $hostname' to the command to ensure that I queried both servers. The
>>>>>>>> results look identical to me, apart from the ordering.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>> On Wed, Oct 6, 2010 at 15:34, Rob Crittenden <rcritten at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dan Scott wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 6, 2010 at 11:32, Simo Sorce<ssorce at redhat.com>
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 6 Oct 2010 10:26:48 -0400
>>>>>>>>>>> Dan Scott<danieljamesscott at gmail.com>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I have master and slave FreeIPA servers. I recently upgraded the
>>>>>>>>>>>> slave
>>>>>>>>>>>> by wiping, re-installing Fedora 13 and re-creating the
>>>>>>>>>>>> replication
>>>>>>>>>>>> using ipa-replica-prepare and ipa-replica-install.
>>>>>>>>>>>>
>>>>>>>>>>>> For some reason, the slave is having difficulty replicating the
>>>>>>>>>>>> memberOf attribute. I can attach an LDAP viewer to the replica,
>>>>>>>>>>>> and
>>>>>>>>>>>> view the schema, but the memberOf attributes are missing. Also,
>>>>>>>>>>>> the
>>>>>>>>>>>> master server contains the lines:
>>>>>>>>>>>>
>>>>>>>>>>>> - Entry "cn=admins,cn=groups,cn=accounts,dc=example,dc=com" --
>>>>>>>>>>>> attribute "memberOf" not allowed
>>>>>>>>>>>> NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
>>>>>>>>>>>> referrals for replica dc=example,dc=com: 20
>>>>>>>>>>>> NSMMReplicationPlugin - replica_reload_ruv: Warning: new data
>>>>>>>>>>>> for
>>>>>>>>>>>> replica dc=example,dc=com does not match the data in the
>>>>>>>>>>>> changelog.
>>>>>>>>>>>>  Recreating the changelog file. This could affect replication
>>>>>>>>>>>> with
>>>>>>>>>>>> replica's  consumers in which case the consumers should be
>>>>>>>>>>>> reinitialized.
>>>>>>>>>>>> [06/Oct/2010:09:58:33 -0400] - skipping cos definition
>>>>>>>>>>>> cn=account
>>>>>>>>>>>> inactivation,cn=accounts,dc=example,dc=com--no templates found
>>>>>>>>>>>>
>>>>>>>>>>>> The rest of the replication appears to be working correctly (as
>>>>>>>>>>>> far
>>>>>>>>>>>> as
>>>>>>>>>>>> I can tell).
>>>>>>>>>>>>
>>>>>>>>>>>> I have tried using ipa-replica-manage init and synch to try to
>>>>>>>>>>>> fix
>>>>>>>>>>>> the
>>>>>>>>>>>> replication, but I suspect this has something to do with the
>>>>>>>>>>>> schema
>>>>>>>>>>>> definition.
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have any pointers/ideas for how I can fix this?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dan, the memberof attribute is explicitly not replicated, and
>>>>>>>>>>> should
>>>>>>>>>>> be
>>>>>>>>>>> simply re-generated on the receiving replica when "member"
>>>>>>>>>>> attributes
>>>>>>>>>>> are replicated.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So does this imply that there is some corruption in the schema on
>>>>>>>>>> the
>>>>>>>>>> replica server?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Are the IPA versions on the master and the replica the same ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> They are both the same version: ipa-server-1.2.2-4.fc13.x86_64
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Dan Scott
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is complaining that memberOf isn't allowed in the admins group
>>>>>>>>> which
>>>>>>>>> is
>>>>>>>>> pretty strange.
>>>>>>>>>
>>>>>>>>> Can you show us the admins group out of the replica and master?
>>>>>>>>>
>>>>>>>>> ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com'
>>>>>>>>> cn=admins
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> Neither one has the inetUser objectclass which allows the use of
>>>>>>> memberOf.
>>>>>>>  But why is it attempting to add memberOf to this entry which is
>>>>>>> itself
>>>>>>> a
>>>>>>> group entry?  Is this some sort of nested group?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>>
>>>>>>>>> rob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Freeipa-users mailing list
>>>>>>>>> Freeipa-users at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>




More information about the Freeipa-users mailing list