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

[Dan Scott]

On Fri, Oct 8, 2010 at 16:28, Nathan Kinder <nkinder at redhat.com> wrote:
> On 10/08/2010 12:08 PM, Dan Scott wrote:
>>
>> On Fri, Oct 8, 2010 at 14:52, James Roman<james.roman at ssaihq.com>  wrote:
>>
>>>
>>>  On 10/08/2010 01:49 PM, Dan Scott wrote:
>>>
>>>>
>>>> On Fri, Oct 8, 2010 at 13:18, Rich Megginson<rmeggins at redhat.com>
>>>>  wrote:
>>>>
>>>>>
>>>>> Dan Scott wrote:
>>>>>
>>>>>>
>>>>>> On Fri, Oct 8, 2010 at 11:39, James Roman<james.roman at ssaihq.com>
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> So does anyone have any more suggestions? Or should I just configure
>>>>>>>> a
>>>>>>>> new replica with new hostname and IP?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I've seen the initial problem where the memberof elements stop
>>>>>>> updating
>>>>>>> on
>>>>>>> my own FreeIPA v1 replica as well. Normally it happens after I
>>>>>>> perform
>>>>>>> a
>>>>>>> full init of the replica. The subsequent errors you are experiencing
>>>>>>> have
>>>>>>> not occurred on my system. You have not indicated a synchronization
>>>>>>> error
>>>>>>> anywhere, but they tend to get buried in the error logs. I assume you
>>>>>>> are
>>>>>>> not short on disk space on the replica. I also assume that the /var
>>>>>>> has
>>>>>>> not
>>>>>>> been mounted as read-only. (I've had a few oddities where
>>>>>>> disk/storage
>>>>>>> problems have caused a file-system to be remounted read-only
>>>>>>> recently)
>>>>>>>
>>>>>>> Out of curiosity, if you modify a user on the replica, do the changes
>>>>>>> get
>>>>>>> saved to the record? If you add a user to a new group on the replica
>>>>>>> does
>>>>>>> the memberof attribute get added to the user's record?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hmm, very strange. Adding my user to another group appears to have
>>>>>> fixed the memberOf attributes for my user on the replica....
>>>>>>
>>>>>> Presumably, the fixup-memberof.pl script is supposed to do this -
>>>>>> strange that it does not appear to work.
>>>>>>
>>>>>> I can create a temporary group, add all users to it and then remove
>>>>>> them again - possibly that would fix the problem?
>>>>>>
>>>>>> I'm still a little concerned by log entries such as (on the replica):
>>>>>>
>>>>>> NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
>>>>>> for replica dc=example,dc=com was reloaded and it no longer matches
>>>>>> the data in the changelog (replica data>    changelog). Recreating the
>>>>>> changelog file. This could affect replication with replica's consumers
>>>>>> in which case the consumers should be reinitialized.
>>>>>>
>>>>>>
>>>>>
>>>>> You should only see this once.  This is ok for an initial
>>>>> initialization
>>>>> or
>>>>> a reinitialization.
>>>>>
>>>>
>>>> OK, thanks. I also get the following (on both master and replica) on
>>>> each alteration of LDAP:
>>>>
>>>> NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
>>>> referrals for replica dc=example,dc=com: 20
>>>>
>>>> Is this expected/normal?
>>>>
>>>> Thanks,
>>>>
>>>> Dan
>>>>
>>>
>>> Dan
>>>
>>> I was going to suggest reinitializing the sync agreement and running the
>>> fixmemberof script again. Did I miss that you have actually done that
>>> already?
>>>
>>
>> Yes, once I realised that there were difference between the master and
>> replica I ran:
>>
>> ipa-replica-manage init ohm.example.com
>>
>> from curie. To try and get the syncing working.
>>
>>
>>>
>>> If not than that error seems pretty out of place. Before you do run
>>> the following script on both servers (replacing dc=example and hostname)
>>> and
>>> remove the admin group from any that you find on both servers before
>>> doing
>>> your re-init.
>>> ldapsearch -Y GSSAPI -h hostname -b
>>> "cn=groups,cn=accounts,dc=example,dc=com"
>>> '(member=cn=admins,cn=groups,cn=accounts,dc=example,dc=com)'
>>>
>>
>> I did have a group which contained the admins group as a member. I
>> removed this yesterday and so there are now no groups containing the
>> member 'admins'.
>>
>>
>>>
>>> The test of adding the user to the group was only to test that the
>>> ipa-memberof plug-in is functioning properly on the replica. It is
>>> triggered
>>> by a group change on the server. The fixmemberof script is really a much
>>> more efficient way of updating all accounts.
>>>
>>
>> Yes, but the fixmember script doesn't appear to work. It appeared to
>> successfully add the entry:
>>
>> cn=memberOf_fixup_2010_10_8_15_6_11
>>
>> but the memberOf attributes weren't corrected.
>>
>
> The way that the memberOf fixup task works is that a search is performed
> using the specified search base and optional filter that are supplied when
> the task is created.  Each matching entry has it's memberOf attribute values
> removed and the memberOf values are re-computed.
>
> The reason that the task did not work for you is that you set the base for
> the fixup task to "cn=groups,cn=accounts,dc=example,dc=com".  This search
> base does not contain any of your user entries, so noe of them had their
> memberOf attribute re-computed.  The search base needs to contain your user
> entries that you want fixed up.

Excellent, thanks.

I've run an 'init' of ohm and all of the memberOf attributes were
removed. I then ran fixup and they were re-added correctly, so that
script seems to be working fine. I'm not sure why the memberOf
attributes aren't being replicated during the initialisation though.

I see this error in the logs:

- skipping cos definition cn=account
inactivation,cn=accounts,dc=example,dc=com--no templates found

Could this be causing the replication to stop? I can't find this
template (/etc/dirsrv/schema/*) on either curie or ohm, so I'm not
sure where it's coming from. I can find 'nsAccountLock' though....

I haven't seen the admins memberOf log message since I removed admins
as a nested group (as expected).

Thanks,

Dan