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 Megginson<rmegg...@redhat.com>
wrote:
Dan Scott wrote:
Hi,
ohm_admins.ldif and curie_admins.ldif attached. I added a '-h
$hostname' to the command to ensure that I queried both servers. The
results look identical to me, apart from the ordering.
Thanks,
Dan
On Wed, Oct 6, 2010 at 15:34, Rob Crittenden<rcrit...@redhat.com>
wrote:
Dan Scott wrote:
Hi,
On Wed, Oct 6, 2010 at 11:32, Simo Sorce<sso...@redhat.com>
wrote:
On Wed, 6 Oct 2010 10:26:48 -0400
Dan Scott<danieljamessc...@gmail.com> wrote:
Hi,
I have master and slave FreeIPA servers. I recently upgraded the
slave
by wiping, re-installing Fedora 13 and re-creating the
replication
using ipa-replica-prepare and ipa-replica-install.
For some reason, the slave is having difficulty replicating the
memberOf attribute. I can attach an LDAP viewer to the
replica, and
view the schema, but the memberOf attributes are missing.
Also, the
master server contains the lines:
- Entry "cn=admins,cn=groups,cn=accounts,dc=example,dc=com" --
attribute "memberOf" not allowed
NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20
NSMMReplicationPlugin - replica_reload_ruv: Warning: new data
for
replica dc=example,dc=com does not match the data in the
changelog.
Recreating the changelog file. This could affect replication
with
replica's consumers in which case the consumers should be
reinitialized.
[06/Oct/2010:09:58:33 -0400] - skipping cos definition
cn=account
inactivation,cn=accounts,dc=example,dc=com--no templates found
The rest of the replication appears to be working correctly
(as far
as
I can tell).
I have tried using ipa-replica-manage init and synch to try
to fix
the
replication, but I suspect this has something to do with the
schema
definition.
Does anyone have any pointers/ideas for how I can fix this?
Dan, the memberof attribute is explicitly not replicated, and
should
be
simply re-generated on the receiving replica when "member"
attributes
are replicated.
So does this imply that there is some corruption in the schema
on the
replica server?
Are the IPA versions on the master and the replica the same ?
They are both the same version: ipa-server-1.2.2-4.fc13.x86_64
Thanks,
Dan Scott
It is complaining that memberOf isn't allowed in the admins
group which
is
pretty strange.
Can you show us the admins group out of the replica and master?
ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com'
cn=admins
Neither one has the inetUser objectclass which allows the use of
memberOf.
But why is it attempting to add memberOf to this entry which is
itself a
group entry? Is this some sort of nested group?
thanks
rob
------------------------------------------------------------------------
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
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
