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

2010-10-08 Thread Dan Scott
On Thu, Oct 7, 2010 at 11:47, Dan Scott danieljamessc...@gmail.com wrote:
 On Thu, Oct 7, 2010 at 11:32, James Roman james.ro...@ssaihq.com 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

2010-10-08 Thread Dan Scott
On Fri, Oct 8, 2010 at 11:39, James Roman james.ro...@ssaihq.com wrote:

 So does anyone have any more suggestions? Or should I just configure a
 new replica with new hostname and IP?

 Thanks,

 Dan

 I've seen the initial problem where the memberof elements stop updating on
 my own FreeIPA v1 replica as well. Normally it happens after I perform a
 full init of the replica. The subsequent errors you are experiencing have
 not occurred on my system. You have not indicated a synchronization error
 anywhere, but they tend to get buried in the error logs. I assume you are
 not short on disk space on the replica. I also assume that the /var has not
 been mounted as read-only. (I've had a few oddities where disk/storage
 problems have caused a file-system to be remounted read-only recently)

 Out of curiosity, if you modify a user on the replica, do the changes get
 saved to the record? If you add a user to a new group on the replica does
 the memberof attribute get added to the user's record?

Hmm, very strange. Adding my user to another group appears to have
fixed the memberOf attributes for my user on the replica

Presumably, the fixup-memberof.pl script is supposed to do this -
strange that it does not appear to work.

I can create a temporary group, add all users to it and then remove
them again - possibly that would fix the problem?

I'm still a little concerned by log entries such as (on the replica):

NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
for replica dc=example,dc=com was reloaded and it no longer matches
the data in the changelog (replica data  changelog). Recreating the
changelog file. This could affect replication with replica's consumers
in which case the consumers should be reinitialized.

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

2010-10-08 Thread James Roman

 On 10/08/2010 01:49 PM, Dan Scott wrote:

On Fri, Oct 8, 2010 at 13:18, Rich Megginsonrmegg...@redhat.com  wrote:

Dan Scott wrote:

On Fri, Oct 8, 2010 at 11:39, James Romanjames.ro...@ssaihq.com  wrote:


So does anyone have any more suggestions? Or should I just configure a
new replica with new hostname and IP?

Thanks,

Dan


I've seen the initial problem where the memberof elements stop updating
on
my own FreeIPA v1 replica as well. Normally it happens after I perform a
full init of the replica. The subsequent errors you are experiencing have
not occurred on my system. You have not indicated a synchronization error
anywhere, but they tend to get buried in the error logs. I assume you are
not short on disk space on the replica. I also assume that the /var has
not
been mounted as read-only. (I've had a few oddities where disk/storage
problems have caused a file-system to be remounted read-only recently)

Out of curiosity, if you modify a user on the replica, do the changes get
saved to the record? If you add a user to a new group on the replica does
the memberof attribute get added to the user's record?


Hmm, very strange. Adding my user to another group appears to have
fixed the memberOf attributes for my user on the replica

Presumably, the fixup-memberof.pl script is supposed to do this -
strange that it does not appear to work.

I can create a temporary group, add all users to it and then remove
them again - possibly that would fix the problem?

I'm still a little concerned by log entries such as (on the replica):

NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
for replica dc=example,dc=com was reloaded and it no longer matches
the data in the changelog (replica data  changelog). Recreating the
changelog file. This could affect replication with replica's consumers
in which case the consumers should be reinitialized.


You should only see this once.  This is ok for an initial initialization or
a reinitialization.

OK, thanks. I also get the following (on both master and replica) on
each alteration of LDAP:

NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20

Is this expected/normal?

Thanks,

Dan

Dan

I was going to suggest reinitializing the sync agreement and running the 
fixmemberof script again. Did I miss that you have actually done that 
already? 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

2010-10-08 Thread Rich Megginson

Dan Scott wrote:

On Fri, Oct 8, 2010 at 13:18, Rich Megginson rmegg...@redhat.com wrote:
  

Dan Scott wrote:


On Fri, Oct 8, 2010 at 11:39, James Roman james.ro...@ssaihq.com wrote:

  

So does anyone have any more suggestions? Or should I just configure a
new replica with new hostname and IP?

Thanks,

Dan

  

I've seen the initial problem where the memberof elements stop updating
on
my own FreeIPA v1 replica as well. Normally it happens after I perform a
full init of the replica. The subsequent errors you are experiencing have
not occurred on my system. You have not indicated a synchronization error
anywhere, but they tend to get buried in the error logs. I assume you are
not short on disk space on the replica. I also assume that the /var has
not
been mounted as read-only. (I've had a few oddities where disk/storage
problems have caused a file-system to be remounted read-only recently)

Out of curiosity, if you modify a user on the replica, do the changes get
saved to the record? If you add a user to a new group on the replica does
the memberof attribute get added to the user's record?



Hmm, very strange. Adding my user to another group appears to have
fixed the memberOf attributes for my user on the replica

Presumably, the fixup-memberof.pl script is supposed to do this -
strange that it does not appear to work.

I can create a temporary group, add all users to it and then remove
them again - possibly that would fix the problem?

I'm still a little concerned by log entries such as (on the replica):

NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
for replica dc=example,dc=com was reloaded and it no longer matches
the data in the changelog (replica data  changelog). Recreating the
changelog file. This could affect replication with replica's consumers
in which case the consumers should be reinitialized.

  

You should only see this once.  This is ok for an initial initialization or
a reinitialization.



OK, thanks. I also get the following (on both master and replica) on
each alteration of LDAP:

NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20

Is this expected/normal?
  
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

2010-10-08 Thread Nathan Kinder

On 10/08/2010 12:08 PM, Dan Scott wrote:

On Fri, Oct 8, 2010 at 14:52, James Romanjames.ro...@ssaihq.com  wrote:
   

  On 10/08/2010 01:49 PM, Dan Scott wrote:
 

On Fri, Oct 8, 2010 at 13:18, Rich Megginsonrmegg...@redhat.comwrote:
   

Dan Scott wrote:
 

On Fri, Oct 8, 2010 at 11:39, James Romanjames.ro...@ssaihq.com
  wrote:

   

So does anyone have any more suggestions? Or should I just configure a
new replica with new hostname and IP?

Thanks,

Dan

   

I've seen the initial problem where the memberof elements stop updating
on
my own FreeIPA v1 replica as well. Normally it happens after I perform
a
full init of the replica. The subsequent errors you are experiencing
have
not occurred on my system. You have not indicated a synchronization
error
anywhere, but they tend to get buried in the error logs. I assume you
are
not short on disk space on the replica. I also assume that the /var has
not
been mounted as read-only. (I've had a few oddities where disk/storage
problems have caused a file-system to be remounted read-only recently)

Out of curiosity, if you modify a user on the replica, do the changes
get
saved to the record? If you add a user to a new group on the replica
does
the memberof attribute get added to the user's record?

 

Hmm, very strange. Adding my user to another group appears to have
fixed the memberOf attributes for my user on the replica

Presumably, the fixup-memberof.pl script is supposed to do this -
strange that it does not appear to work.

I can create a temporary group, add all users to it and then remove
them again - possibly that would fix the problem?

I'm still a little concerned by log entries such as (on the replica):

NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
for replica dc=example,dc=com was reloaded and it no longer matches
the data in the changelog (replica datachangelog). 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

2010-10-08 Thread Dan Scott
On Fri, Oct 8, 2010 at 16:28, Nathan Kinder nkin...@redhat.com wrote:
 On 10/08/2010 12:08 PM, Dan Scott wrote:

 On Fri, Oct 8, 2010 at 14:52, James Romanjames.ro...@ssaihq.com  wrote:


  On 10/08/2010 01:49 PM, Dan Scott wrote:


 On Fri, Oct 8, 2010 at 13:18, Rich Megginsonrmegg...@redhat.com
  wrote:


 Dan Scott wrote:


 On Fri, Oct 8, 2010 at 11:39, James Romanjames.ro...@ssaihq.com
  wrote:



 So does anyone have any more suggestions? Or should I just configure
 a
 new replica with new hostname and IP?

 Thanks,

 Dan



 I've seen the initial problem where the memberof elements stop
 updating
 on
 my own FreeIPA v1 replica as well. Normally it happens after I
 perform
 a
 full init of the replica. The subsequent errors you are experiencing
 have
 not occurred on my system. You have not indicated a synchronization
 error
 anywhere, but they tend to get buried in the error logs. I assume you
 are
 not short on disk space on the replica. I also assume that the /var
 has
 not
 been mounted as read-only. (I've had a few oddities where
 disk/storage
 problems have caused a file-system to be remounted read-only
 recently)

 Out of curiosity, if you modify a user on the replica, do the changes
 get
 saved to the record? If you add a user to a new group on the replica
 does
 the memberof attribute get added to the user's record?



 Hmm, very strange. Adding my user to another group appears to have
 fixed the memberOf attributes for my user on the replica

 Presumably, the fixup-memberof.pl script is supposed to do this -
 strange that it does not appear to work.

 I can create a temporary group, add all users to it and then remove
 them again - possibly that would fix the problem?

 I'm still a little concerned by log entries such as (on the replica):

 NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
 for replica dc=example,dc=com was reloaded and it no longer matches
 the data in the changelog (replica data    changelog). Recreating the
 changelog file. This could affect replication with replica's consumers
 in which case the consumers should be reinitialized.



 You should only see this once.  This is ok for an initial
 initialization
 or
 a reinitialization.


 OK, thanks. I also get the following (on both master and replica) on
 each alteration of LDAP:

 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20

 Is this expected/normal?

 Thanks,

 Dan


 Dan

 I was going to suggest reinitializing the sync agreement and running the
 fixmemberof script again. Did I miss that you have actually done that
 already?


 Yes, once I realised that there were difference between the master and
 replica I ran:

 ipa-replica-manage init ohm.example.com

 from curie. To try and get the syncing working.



 If not than that error seems pretty out of place. Before you do run
 the following script on both servers (replacing dc=example and hostname)
 and
 remove the admin group from any that you find on both servers before
 doing
 your re-init.
 ldapsearch -Y GSSAPI -h hostname -b
 cn=groups,cn=accounts,dc=example,dc=com
 '(member=cn=admins,cn=groups,cn=accounts,dc=example,dc=com)'


 I did have a group which contained the admins group as a member. I
 removed this yesterday and so there are now no groups containing the
 member 'admins'.



 The test of adding the user to the group was only to test that the
 ipa-memberof plug-in is functioning properly on the replica. It is
 triggered
 by a group change on the server. The fixmemberof script is really a much
 more efficient way of updating all accounts.


 Yes, but the fixmember script doesn't appear to work. It appeared to
 successfully add the entry:

 cn=memberOf_fixup_2010_10_8_15_6_11

 but the memberOf attributes weren't corrected.


 The way that the memberOf fixup task works is that a search is performed
 using the specified search base and optional filter that are supplied when
 the task is created.  Each matching entry has it's memberOf attribute values
 removed and the memberOf values are re-computed.

 The reason that the task did not work for you is that you set the base for
 the fixup task to cn=groups,cn=accounts,dc=example,dc=com.  This search
 base does not contain any of your user entries, so noe of them had their
 memberOf attribute re-computed.  The search base needs to contain your user
 entries that you want fixed up.

Excellent, thanks.

I've run an 'init' of ohm and all of the memberOf attributes were
removed. I then ran fixup and they were re-added correctly, so that
script seems to be working fine. I'm not sure why the memberOf
attributes aren't being replicated during the initialisation though.

I see this error in the logs:

- skipping cos definition cn=account
inactivation,cn=accounts,dc=example,dc=com--no templates found

Could this be causing the replication to stop? I can't find this
template (/etc/dirsrv/schema/*) on either curie or ohm, so I'm not
sure 

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

2010-10-07 Thread Dan Scott
On Wed, Oct 6, 2010 at 22:02, Rich Megginson rmegg...@redhat.com wrote:
 Dan Scott wrote:

 Hi,

 On Wed, Oct 6, 2010 at 18:30, Rich Megginson rmegg...@redhat.com wrote:


 Dan Scott wrote:


 I'm not sure which group this is referring to. Admins only contains 3
 users, no nested groups.

 The problem appears to be related to the users, rather than the
 groups. None of the users on ohm have a 'memberOf'. Curie has the
 correct memberOf attributes.



 The error message specifically mentions the admin group:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed

 As if it is attempting to add the memberOf attribute to the group entry
 cn=admins,cn=groups,cn=accounts,dc=example,dc=com - I don't know why it
 would do this unless it is attempting some sort of group nesting.


 This is still a mystery - we need to figure out why it is attempting to add
 memberOf to this entry.

 The groups themselves appear to be correct on both servers. Both ohm
 and curie have groups which contain the correct 'member' attributes.
 So the problem appears to be that ohm contains groups with correct
 'members', but none of the users have any 'memberOf's.




 Do all of the users have the inetUser objectclass?


 Yep. Looks like it. I have 162 users:

 [djsc...@ohm ~]$ ldapsearch -h curie.example.com -x -b
 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc
    162     324    3564
 [djsc...@ohm ~]$ ldapsearch -h ohm.example.com -x -b
 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass:
 inetUser'|wc
    162     324    3564
 [djsc...@ohm ~]$


 If you run the lib/dirsrv/slapd-ds/fixup-memberof.pl script, does it add the
 memberOf attributes?

When I try to run that, I get the following:

[r...@ohm ~]# /usr/lib64/dirsrv/slapd-EXAMPLE.COM/fixup-memberof.pl -b
cn=groups,cn=accounts,dc=example,dc=com -D uid=admin -w -
Bind Password: *

ldap_simple_bind: No such object

Thanks,

Dan


 On Wed, Oct 6, 2010 at 16:17, Rich Megginson rmegg...@redhat.com
 wrote:



 Dan Scott wrote:



 Hi,

 ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
 $hostname' to the command to ensure that I queried both servers. The
 results look identical to me, apart from the ordering.

 Thanks,

 Dan

 On Wed, Oct 6, 2010 at 15:34, Rob Crittenden rcrit...@redhat.com
 wrote:




 Dan Scott wrote:




 Hi,

 On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:




 On Wed, 6 Oct 2010 10:26:48 -0400
 Dan Scottdanieljamessc...@gmail.com  wrote:





 Hi,

 I have master and slave FreeIPA servers. I recently upgraded the
 slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.

 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica,
 and
 view the schema, but the memberOf attributes are missing. Also,
 the
 master server contains the lines:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the
 changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found

 The rest of the replication appears to be working correctly (as
 far
 as
 I can tell).

 I have tried using ipa-replica-manage init and synch to try to fix
 the
 replication, but I suspect this has something to do with the
 schema
 definition.

 Does anyone have any pointers/ideas for how I can fix this?




 Dan, the memberof attribute is explicitly not replicated, and
 should
 be
 simply re-generated on the receiving replica when member
 attributes
 are replicated.




 So does this imply that there is some corruption in the schema on
 the
 replica server?





 Are the IPA versions on the master and the replica the same ?




 They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

 Thanks,

 Dan Scott




 It is complaining that memberOf isn't allowed in the admins group
 which
 is
 pretty strange.

 Can you show us the admins group out of the replica and master?

 ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins




 Neither one has the inetUser objectclass which allows the use of
 memberOf.
  But why is it attempting to add memberOf to this entry which is itself
 a
 group entry?  Is this some sort of nested group?



 thanks

 rob




  

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 

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

2010-10-07 Thread James Roman



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

2010-10-07 Thread Dan Scott
On Thu, Oct 7, 2010 at 11:32, James Roman james.ro...@ssaihq.com 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

2010-10-07 Thread Nathan Kinder

On 10/06/2010 07:03 PM, Rich Megginson wrote:

Dan Scott wrote:

Hi,

On Wed, Oct 6, 2010 at 19:29, Nathan Kinder nkin...@redhat.com 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 Megginsonrmegg...@redhat.com  
wrote:



Dan Scott wrote:


Hi,

ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
$hostname' to the command to ensure that I queried both servers. The
results look identical to me, apart from the ordering.

Thanks,

Dan

On Wed, Oct 6, 2010 at 15:34, Rob Crittendenrcrit...@redhat.com
 wrote:



Dan Scott wrote:



Hi,

On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com
wrote:




On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scottdanieljamessc...@gmail.comwrote:




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

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

2010-10-06 Thread Simo Sorce
On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scott danieljamessc...@gmail.com wrote:

 Hi,
 
 I have master and slave FreeIPA servers. I recently upgraded the slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.
 
 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica, and
 view the schema, but the memberOf attributes are missing. Also, the
 master server contains the lines:
 
 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found
 
 The rest of the replication appears to be working correctly (as far as
 I can tell).
 
 I have tried using ipa-replica-manage init and synch to try to fix the
 replication, but I suspect this has something to do with the schema
 definition.
 
 Does anyone have any pointers/ideas for how I can fix this?

Dan, the memberof attribute is explicitly not replicated, and should be
simply re-generated on the receiving replica when member attributes
are replicated.

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


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

2010-10-06 Thread Dan Scott
Hi,

On Wed, Oct 6, 2010 at 11:32, Simo Sorce sso...@redhat.com wrote:
 On Wed, 6 Oct 2010 10:26:48 -0400
 Dan Scott danieljamessc...@gmail.com wrote:

 Hi,

 I have master and slave FreeIPA servers. I recently upgraded the slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.

 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica, and
 view the schema, but the memberOf attributes are missing. Also, the
 master server contains the lines:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found

 The rest of the replication appears to be working correctly (as far as
 I can tell).

 I have tried using ipa-replica-manage init and synch to try to fix the
 replication, but I suspect this has something to do with the schema
 definition.

 Does anyone have any pointers/ideas for how I can fix this?

 Dan, the memberof attribute is explicitly not replicated, and should be
 simply re-generated on the receiving replica when member attributes
 are replicated.

So does this imply that there is some corruption in the schema on the
replica server?

 Are the IPA versions on the master and the replica the same ?

They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

Thanks,

Dan Scott

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


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

2010-10-06 Thread Rob Crittenden

Dan Scott wrote:

Hi,

On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:

On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scottdanieljamessc...@gmail.com  wrote:


Hi,

I have master and slave FreeIPA servers. I recently upgraded the slave
by wiping, re-installing Fedora 13 and re-creating the replication
using ipa-replica-prepare and ipa-replica-install.

For some reason, the slave is having difficulty replicating the
memberOf attribute. I can attach an LDAP viewer to the replica, and
view the schema, but the memberOf attributes are missing. Also, the
master server contains the lines:

- Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
attribute memberOf not allowed
NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20
NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
replica's  consumers in which case the consumers should be
reinitialized.
[06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
inactivation,cn=accounts,dc=example,dc=com--no templates found

The rest of the replication appears to be working correctly (as far as
I can tell).

I have tried using ipa-replica-manage init and synch to try to fix the
replication, but I suspect this has something to do with the schema
definition.

Does anyone have any pointers/ideas for how I can fix this?


Dan, the memberof attribute is explicitly not replicated, and should be
simply re-generated on the receiving replica when member attributes
are replicated.


So does this imply that there is some corruption in the schema on the
replica server?


Are the IPA versions on the master and the replica the same ?


They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

Thanks,

Dan Scott


It is complaining that memberOf isn't allowed in the admins group which 
is pretty strange.


Can you show us the admins group out of the replica and master?

ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins

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

2010-10-06 Thread Dan Scott
Hi,

ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
$hostname' to the command to ensure that I queried both servers. The
results look identical to me, apart from the ordering.

Thanks,

Dan

On Wed, Oct 6, 2010 at 15:34, Rob Crittenden rcrit...@redhat.com wrote:
 Dan Scott wrote:

 Hi,

 On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:

 On Wed, 6 Oct 2010 10:26:48 -0400
 Dan Scottdanieljamessc...@gmail.com  wrote:

 Hi,

 I have master and slave FreeIPA servers. I recently upgraded the slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.

 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica, and
 view the schema, but the memberOf attributes are missing. Also, the
 master server contains the lines:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found

 The rest of the replication appears to be working correctly (as far as
 I can tell).

 I have tried using ipa-replica-manage init and synch to try to fix the
 replication, but I suspect this has something to do with the schema
 definition.

 Does anyone have any pointers/ideas for how I can fix this?

 Dan, the memberof attribute is explicitly not replicated, and should be
 simply re-generated on the receiving replica when member attributes
 are replicated.

 So does this imply that there is some corruption in the schema on the
 replica server?

 Are the IPA versions on the master and the replica the same ?

 They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

 Thanks,

 Dan Scott

 It is complaining that memberOf isn't allowed in the admins group which is
 pretty strange.

 Can you show us the admins group out of the replica and master?

 ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins

 thanks

 rob

# extended LDIF
#
# LDAPv3
# base cn=groups,cn=accounts,dc=example,dc=com 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 cn=groups,cn=accounts,dc=example,dc=com 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

2010-10-06 Thread Dan Scott
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 rmegg...@redhat.com wrote:
 Dan Scott wrote:

 Hi,

 ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
 $hostname' to the command to ensure that I queried both servers. The
 results look identical to me, apart from the ordering.

 Thanks,

 Dan

 On Wed, Oct 6, 2010 at 15:34, Rob Crittenden rcrit...@redhat.com wrote:


 Dan Scott wrote:


 Hi,

 On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:


 On Wed, 6 Oct 2010 10:26:48 -0400
 Dan Scottdanieljamessc...@gmail.com  wrote:



 Hi,

 I have master and slave FreeIPA servers. I recently upgraded the slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.

 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica, and
 view the schema, but the memberOf attributes are missing. Also, the
 master server contains the lines:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found

 The rest of the replication appears to be working correctly (as far as
 I can tell).

 I have tried using ipa-replica-manage init and synch to try to fix the
 replication, but I suspect this has something to do with the schema
 definition.

 Does anyone have any pointers/ideas for how I can fix this?


 Dan, the memberof attribute is explicitly not replicated, and should be
 simply re-generated on the receiving replica when member attributes
 are replicated.


 So does this imply that there is some corruption in the schema on the
 replica server?



 Are the IPA versions on the master and the replica the same ?


 They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

 Thanks,

 Dan Scott


 It is complaining that memberOf isn't allowed in the admins group which
 is
 pretty strange.

 Can you show us the admins group out of the replica and master?

 ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins


 Neither one has the inetUser objectclass which allows the use of memberOf.
  But why is it attempting to add memberOf to this entry which is itself a
 group entry?  Is this some sort of nested group?

 thanks

 rob


  

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


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

2010-10-06 Thread Dan Scott
Hi,

On Wed, Oct 6, 2010 at 18:30, Rich Megginson rmegg...@redhat.com wrote:
 Dan Scott wrote:

 I'm not sure which group this is referring to. Admins only contains 3
 users, no nested groups.

 The problem appears to be related to the users, rather than the
 groups. None of the users on ohm have a 'memberOf'. Curie has the
 correct memberOf attributes.


 The error message specifically mentions the admin group:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed

 As if it is attempting to add the memberOf attribute to the group entry
 cn=admins,cn=groups,cn=accounts,dc=example,dc=com - I don't know why it
 would do this unless it is attempting some sort of group nesting.

 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 rmegg...@redhat.com wrote:


 Dan Scott wrote:


 Hi,

 ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
 $hostname' to the command to ensure that I queried both servers. The
 results look identical to me, apart from the ordering.

 Thanks,

 Dan

 On Wed, Oct 6, 2010 at 15:34, Rob Crittenden rcrit...@redhat.com
 wrote:



 Dan Scott wrote:



 Hi,

 On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:



 On Wed, 6 Oct 2010 10:26:48 -0400
 Dan Scottdanieljamessc...@gmail.com  wrote:




 Hi,

 I have master and slave FreeIPA servers. I recently upgraded the
 slave
 by wiping, re-installing Fedora 13 and re-creating the replication
 using ipa-replica-prepare and ipa-replica-install.

 For some reason, the slave is having difficulty replicating the
 memberOf attribute. I can attach an LDAP viewer to the replica, and
 view the schema, but the memberOf attributes are missing. Also, the
 master server contains the lines:

 - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
 attribute memberOf not allowed
 NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
 referrals for replica dc=example,dc=com: 20
 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
 replica dc=example,dc=com does not match the data in the changelog.
  Recreating the changelog file. This could affect replication with
 replica's  consumers in which case the consumers should be
 reinitialized.
 [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
 inactivation,cn=accounts,dc=example,dc=com--no templates found

 The rest of the replication appears to be working correctly (as far
 as
 I can tell).

 I have tried using ipa-replica-manage init and synch to try to fix
 the
 replication, but I suspect this has something to do with the schema
 definition.

 Does anyone have any pointers/ideas for how I can fix this?



 Dan, the memberof attribute is explicitly not replicated, and should
 be
 simply re-generated on the receiving replica when member attributes
 are replicated.



 So does this imply that there is some corruption in the schema on the
 replica server?




 Are the IPA versions on the master and the replica the same ?



 They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

 Thanks,

 Dan Scott



 It is complaining that memberOf isn't allowed in the admins group which
 is
 pretty strange.

 Can you show us the admins group out of the replica and master?

 ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins



 Neither one has the inetUser objectclass which allows the use of
 memberOf.
  But why is it attempting to add memberOf to this entry which is itself a
 group entry?  Is this some sort of nested group?


 thanks

 rob



  

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


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

2010-10-06 Thread Nathan Kinder

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 Megginsonrmegg...@redhat.com  wrote:
   

Dan Scott wrote:
 

Hi,

ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
$hostname' to the command to ensure that I queried both servers. The
results look identical to me, apart from the ordering.

Thanks,

Dan

On Wed, Oct 6, 2010 at 15:34, Rob Crittendenrcrit...@redhat.com  wrote:

   

Dan Scott wrote:

 

Hi,

On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.comwrote:

   

On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scottdanieljamessc...@gmail.comwrote:


 

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

2010-10-06 Thread Rich Megginson

Dan Scott wrote:

Hi,

On Wed, Oct 6, 2010 at 18:30, Rich Megginson rmegg...@redhat.com wrote:
  

Dan Scott wrote:


I'm not sure which group this is referring to. Admins only contains 3
users, no nested groups.

The problem appears to be related to the users, rather than the
groups. None of the users on ohm have a 'memberOf'. Curie has the
correct memberOf attributes.

  

The error message specifically mentions the admin group:

- Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
attribute memberOf not allowed

As if it is attempting to add the memberOf attribute to the group entry
cn=admins,cn=groups,cn=accounts,dc=example,dc=com - I don't know why it
would do this unless it is attempting some sort of group nesting.

This is still a mystery - we need to figure out why it is attempting to 
add memberOf to this entry.

The groups themselves appear to be correct on both servers. Both ohm
and curie have groups which contain the correct 'member' attributes.
So the problem appears to be that ohm contains groups with correct
'members', but none of the users have any 'memberOf's.


  

Do all of the users have the inetUser objectclass?



Yep. Looks like it. I have 162 users:

[djsc...@ohm ~]$ ldapsearch -h curie.example.com -x -b
'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc
162 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 rmegg...@redhat.com wrote:

  

Dan Scott wrote:



Hi,

ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
$hostname' to the command to ensure that I queried both servers. The
results look identical to me, apart from the ordering.

Thanks,

Dan

On Wed, Oct 6, 2010 at 15:34, Rob Crittenden rcrit...@redhat.com
wrote:


  

Dan Scott wrote:




Hi,

On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com  wrote:


  

On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scottdanieljamessc...@gmail.com  wrote:





Hi,

I have master and slave FreeIPA servers. I recently upgraded the
slave
by wiping, re-installing Fedora 13 and re-creating the replication
using ipa-replica-prepare and ipa-replica-install.

For some reason, the slave is having difficulty replicating the
memberOf attribute. I can attach an LDAP viewer to the replica, and
view the schema, but the memberOf attributes are missing. Also, the
master server contains the lines:

- Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com --
attribute memberOf not allowed
NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20
NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for
replica dc=example,dc=com does not match the data in the changelog.
 Recreating the changelog file. This could affect replication with
replica's  consumers in which case the consumers should be
reinitialized.
[06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account
inactivation,cn=accounts,dc=example,dc=com--no templates found

The rest of the replication appears to be working correctly (as far
as
I can tell).

I have tried using ipa-replica-manage init and synch to try to fix
the
replication, but I suspect this has something to do with the schema
definition.

Does anyone have any pointers/ideas for how I can fix this?


  

Dan, the memberof attribute is explicitly not replicated, and should
be
simply re-generated on the receiving replica when member attributes
are replicated.




So does this imply that there is some corruption in the schema on the
replica server?



  

Are the IPA versions on the master and the replica the same ?




They are both the same version: ipa-server-1.2.2-4.fc13.x86_64

Thanks,

Dan Scott


  

It is complaining that memberOf isn't allowed in the admins group which
is
pretty strange.

Can you show us the admins group out of the replica and master?

ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins




Neither one has the inetUser objectclass which allows the use of
memberOf.
 But why is it attempting to add memberOf to this entry which is itself a
group entry?  Is this some sort of nested group?



thanks

rob



 

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users