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

[Nathan Kinder]

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.

-NGK
>    
>> One other consideration, are both server time in sync (at least within 5
>> minutes) but in general, you want them to be pretty close.
>>      
> Yes, they are both in sync ('Exactly' in sync,<  1s apart as far as I can tell).
>
> Thanks for your help.
>
> Dan
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>