On Fri, Oct 8, 2010 at 16:28, Nathan Kinder <nkin...@redhat.com> wrote: > On 10/08/2010 12:08 PM, Dan Scott wrote: >> >> On Fri, Oct 8, 2010 at 14:52, James Roman<james.ro...@ssaihq.com> wrote: >> >>> >>> On 10/08/2010 01:49 PM, Dan Scott wrote: >>> >>>> >>>> On Fri, Oct 8, 2010 at 13:18, Rich Megginson<rmegg...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> Dan Scott wrote: >>>>> >>>>>> >>>>>> On Fri, Oct 8, 2010 at 11:39, James Roman<james.ro...@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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users