On Thu, Oct 7, 2010 at 10:20, Rich Megginson <rmegg...@redhat.com> wrote: > Dan Scott wrote: >> >> On Wed, Oct 6, 2010 at 22:02, Rich Megginson <rmegg...@redhat.com> wrote: >> >>> >>> Dan Scott wrote: >>> >>>> >>>> Hi, >>>> >>>> On Wed, Oct 6, 2010 at 18:30, Rich Megginson <rmegg...@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: >>>> >>>> [djsc...@ohm ~]$ ldapsearch -h curie.example.com -x -b >>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>>> 162 324 3564 >>>> [djsc...@ohm ~]$ ldapsearch -h ohm.example.com -x -b >>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>>> inetUser'|wc >>>> 162 324 3564 >>>> [djsc...@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: >> >> [r...@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 <rmegg...@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 <rcrit...@redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Dan Scott wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, Oct 6, 2010 at 11:32, Simo Sorce<sso...@redhat.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, 6 Oct 2010 10:26:48 -0400 >>>>>>>>>>> Dan Scott<danieljamessc...@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@redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users