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

[James Roman]

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

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.

One other consideration, are both server time in sync (at least within 5 
minutes) but in general, you want them to be pretty close.