Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Fri, Oct 8, 2010 at 16:28, Nathan Kinder wrote: > On 10/08/2010 12:08 PM, Dan Scott wrote: >> >> On Fri, Oct 8, 2010 at 14:52, James Roman wrote: >> >>> >>> On 10/08/2010 01:49 PM, Dan Scott wrote: >>> On Fri, Oct 8, 2010 at 13:18, Rich Megginson wrote: > > Dan Scott wrote: > >> >> On Fri, Oct 8, 2010 at 11:39, James Roman >> 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 y
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/08/2010 12:08 PM, Dan Scott wrote:
On Fri, Oct 8, 2010 at 14:52, James Roman wrote:
On 10/08/2010 01:49 PM, Dan Scott wrote:
On Fri, Oct 8, 2010 at 13:18, Rich Megginsonwrote:
Dan Scott wrote:
On Fri, Oct 8, 2010 at 11:39, James Roman
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@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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
Dan Scott wrote: On Fri, Oct 8, 2010 at 13:18, Rich Megginson wrote: Dan Scott wrote: On Fri, Oct 8, 2010 at 11:39, James Roman 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? It is a bug, but I think it is benign. It just means it is attempting to set a value, but the value is already set. 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 Fri, Oct 8, 2010 at 14:52, James Roman wrote:
> On 10/08/2010 01:49 PM, Dan Scott wrote:
>>
>> On Fri, Oct 8, 2010 at 13:18, Rich Megginson wrote:
>>>
>>> Dan Scott wrote:
On Fri, Oct 8, 2010 at 11:39, James Roman
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.
> 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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/08/2010 01:49 PM, Dan Scott wrote: On Fri, Oct 8, 2010 at 13:18, Rich Megginson wrote: Dan Scott wrote: On Fri, Oct 8, 2010 at 11:39, James Roman 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. ___ 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 Fri, Oct 8, 2010 at 13:18, Rich Megginson wrote: > Dan Scott wrote: >> >> On Fri, Oct 8, 2010 at 11:39, James Roman 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 ___ 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 Fri, Oct 8, 2010 at 11:39, James Roman 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. Thanks, Dan ___ 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On Fri, Oct 8, 2010 at 11:39, James Roman 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. 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 Thu, Oct 7, 2010 at 11:47, Dan Scott wrote: > 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. So does anyone have any more suggestions? Or should I just configure a new replica with new hostname and IP? 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-
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 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 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
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 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
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
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
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
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
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 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: 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. 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 Sorcewrote: 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-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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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? 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? 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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? 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 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? >>> > > 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 > Fre
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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. -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 Sorcewrote: 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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. >> >> 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 ~]$ 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? >>> > > thanks > > rob > > > > > > ___
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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. 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? 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? 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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 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 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? >>> >>> 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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? 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
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 > > thanks > > rob > # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=admins # requesting: ALL # # admins, groups, accounts, example.com dn: cn=admins,cn=groups,cn=accounts,dc=example,dc=com member: uid=admin,cn=users,cn=accounts,dc=example,dc=com member: uid=djscott,cn=users,cn=accounts,dc=example,dc=com member: uid=mauro,cn=users,cn=accounts,dc=example,dc=com gidNumber: 1001 description: Account administrators group cn: admins objectClass: top objectClass: groupofnames objectClass: posixGroup # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=admins # requesting: ALL # # admins, groups, accounts, example.com dn: cn=admins,cn=groups,cn=accounts,dc=example,dc=com objectClass: top objectClass: groupofnames objectClass: posixGroup cn: admins description: Account administrators group gidNumber: 1001 member: uid=admin,cn=users,cn=accounts,dc=example,dc=com member: uid=djscott,cn=users,cn=accounts,dc=example,dc=com member: uid=mauro,cn=users,cn=accounts,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ___ 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: 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 thanks 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
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 ___ 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 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. Are the IPA versions on the master and the replica the same ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Replica not syncing 'memberOf' attributes
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? Thanks, Dan Scott ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
