Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: > Dan Scott wrote: >> >> Hi, >> >> On Wed, Oct 6, 2010 at 18:30, Rich Megginson 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 Thanks, Dan On Wed, Oct 6, 2010 at 16:17, Rich Megginson 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 >> wrote: >> >> >> >>> >>> Dan Scott wrote: >>> >>> >>> Hi, On Wed, Oct 6, 2010 at 11:32, Simo Sorce wrote: > > On Wed, 6 Oct 2010 10:26:48 -0400 > Dan Scott 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
Dan Scott wrote: On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 18:30, Rich Megginson 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 3243564 [djsc...@ohm ~]$ ldapsearch -h ohm.example.com -x -b 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: inetUser'|wc 162 3243564 [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? Thanks, Dan On Wed, Oct 6, 2010 at 16:17, Rich Megginson 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 wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 11:32, Simo Sorce wrote: On Wed, 6 Oct 2010 10:26:48 -0400 Dan Scott 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?
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Thu, Oct 7, 2010 at 10:20, Rich Megginson wrote: > Dan Scott wrote: >> >> On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: >> >>> >>> Dan Scott wrote: >>> Hi, On Wed, Oct 6, 2010 at 18:30, Rich Megginson 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 >> 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 wrote: > > Dan Scott wrote: > > > > >> >> Hi, >> >> On Wed, Oct 6, 2010 at 11:32, Simo Sorce >> wrote: >> >> >> >> >>> >>> On Wed, 6 Oct 2010 10:26:48 -0400 >>> Dan Scott 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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 In FreeIPA v1 I'm almost positive you must run this script as cn=directory manager. This is scheduling an administrative task on the LDAP server, not actually running the task itself. Your admin account only has rights to entities within the "cn=domain,cn=com" branch. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
Dan Scott wrote: On Thu, Oct 7, 2010 at 10:20, Rich Megginson wrote: Dan Scott wrote: On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 18:30, Rich Megginson 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 3243564 [djsc...@ohm ~]$ ldapsearch -h ohm.example.com -x -b 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: inetUser'|wc 162 3243564 [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'. The IPA admin user can't write to cn=config. You need to do this as cn=Directory Manager rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Thu, 7 Oct 2010 10:43:15 -0400 Dan Scott wrote: > 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 Sorry Dan, these kind of task need to be run with "cn=Directory Manager" credentials I am afraid. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Thu, Oct 7, 2010 at 10:58, Rob Crittenden wrote: > Dan Scott wrote: >> >> On Thu, Oct 7, 2010 at 10:20, Rich Megginson wrote: >>> >>> Dan Scott wrote: On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: > > Dan Scott wrote: > >> >> Hi, >> >> On Wed, Oct 6, 2010 at 18:30, Rich Megginson >> 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'. > > The IPA admin user can't write to cn=config. You need to do this as > cn=Directory Manager Thanks for all the help guys. Sorry I don't know too much about this. Looks like it finally ran: adding new entry cn=memberOf_fixup_2010_10_7_11_10_0, cn=memberOf task, cn=tasks, cn=config The log file on ohm now contains an entry: [07/Oct/2010:11:10:01 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=example,dc=com: 20 Curie contains the same log entry. But, none of the users contain the memberOf attributes on ohm. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
Dan Scott wrote: On Thu, Oct 7, 2010 at 10:58, Rob Crittenden wrote: Dan Scott wrote: On Thu, Oct 7, 2010 at 10:20, Rich Megginson wrote: Dan Scott wrote: On Wed, Oct 6, 2010 at 22:02, Rich Megginson wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 18:30, Rich Megginson 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 3243564 [djsc...@ohm ~]$ ldapsearch -h ohm.example.com -x -b 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: inetUser'|wc 162 3243564 [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'. The IPA admin user can't write to cn=config. You need to do this as cn=Directory Manager Thanks for all the help guys. Sorry I don't know too much about this. Looks like it finally ran: adding new entry cn=memberOf_fixup_2010_10_7_11_10_0, cn=memberOf task, cn=tasks, cn=config The log file on ohm now contains an entry: [07/Oct/2010:11:10:01 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=example,dc=com: 20 20 is "type or value exists" - I think this means that it is attempting to set a referral for the master, but there already is one. Curie contains the same log entry. But, none of the users contain the memberOf attributes on ohm. Does IPA have its own memberOf plugin, or is it using the one from 389? Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/07/2010 11:20 AM, Rich Megginson wrote: 20 is "type or value exists" - I think this means that it is attempting to set a referral for the master, but there already is one. Curie contains the same log entry. But, none of the users contain the memberOf attributes on ohm. Does IPA have its own memberOf plugin, or is it using the one from 389? The answer is that it can, depending on the version of 389 that was initally installed. Try running the following to see how many memberof plugins you have and whether they are enabled. [#} ldapsearch -x -D "cn=directory manager" -W -LLL -b "cn=plugins,cn=config" -s one 'cn=*member*' cn nsslapd-pluginEnabled Enter LDAP Password: dn: cn=ipa-memberof,cn=plugins,cn=config cn: ipa-memberof nsslapd-pluginEnabled: on dn: cn=MemberOf Plugin,cn=plugins,cn=config cn: MemberOf Plugin nsslapd-pluginEnabled: off ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Thu, 07 Oct 2010 09:20:29 -0600 Rich Megginson wrote: > > > Does IPA have its own memberOf plugin, or is it using the one from > 389? In v1, it had its own memberof plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Thu, Oct 7, 2010 at 11:32, James Roman wrote: > On 10/07/2010 11:20 AM, Rich Megginson wrote: >> >> 20 is "type or value exists" - I think this means that it is attempting to >> set a referral for the master, but there already is one. >>> >>> Curie contains the same log entry. >>> >>> But, none of the users contain the memberOf attributes on ohm. >> >> Does IPA have its own memberOf plugin, or is it using the one from 389? > > The answer is that it can, depending on the version of 389 that was initally > installed. > > Try running the following to see how many memberof plugins you have and > whether they are enabled. > > [#} ldapsearch -x -D "cn=directory manager" -W -LLL -b > "cn=plugins,cn=config" -s one 'cn=*member*' cn nsslapd-pluginEnabled > Enter LDAP Password: > dn: cn=ipa-memberof,cn=plugins,cn=config > cn: ipa-memberof > nsslapd-pluginEnabled: on > > dn: cn=MemberOf Plugin,cn=plugins,cn=config > cn: MemberOf Plugin > nsslapd-pluginEnabled: off Looks like I'm using the ipa-memberof plugin: [r...@ohm ~]# ldapsearch -x -D "cn=directory manager" -W -LLL -b "cn=plugins,cn=config" -s one 'cn=*member*' cn nsslapd-pluginEnabled Enter LDAP Password: dn: cn=ipa-memberof,cn=plugins,cn=config cn: ipa-memberof nsslapd-pluginEnabled: on dn: cn=MemberOf Plugin,cn=plugins,cn=config cn: MemberOf Plugin nsslapd-pluginEnabled: off This result is the same for both servers. I ran with the '-h' option using each host name. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/06/2010 07:03 PM, Rich Megginson wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 19:29, Nathan Kinder wrote: On 10/06/2010 03:08 PM, Dan Scott wrote: I'm not sure which group this is referring to. Admins only contains 3 users, no nested groups. Do any other groups have a "member" attribute that points to your "cn=admins" group's DN? The error message indicates that some other group has your admins group as a member. Yes, I do have another group of which admins is a member. I have removed it temporarily. Would this be a problem normally? I'm not sure how the memberOf plugin is supposed to handle situations like this. The memberOf plug-in leaves it up to the administrator to ensure that the proper objectClasses are present on objects that it wants to add memberOf to. When the plug-in encounters an issue where the memberOf attribute it not allowed on an entry, it simply continues on to the next entry. This one grouping error should not cause any other issues with memberOf working for other groups. From an FreeIPA perspective, should it be allowed to list the "cn=admins" group as a member of another group? If so, the proper objectClass needs to be added to "cn=admins" to allow the memberOf attribute. Thanks, Dan -NGK 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 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. Thanks, Dan On Wed, Oct 6, 2010 at 16:17, Rich Megginson 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 wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 11:32, Simo Sorce wrote: On Wed, 6 Oct 2010 10:26:48 -0400 Dan Scottwrote: 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-
[Freeipa-users] When does freeipa make it to the Red Hat tree? some years off? RHEL7?
regards Steven Jones Technical Specialist Linux/Vmware Tele 64 4 463 6272 Victoria University Kelburn New Zealand ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
