From heco0701 at stcloudstate.edu Tue Oct 5 16:53:38 2010 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Tue, 5 Oct 2010 11:53:38 -0500 Subject: [Freeipa-users] FreeIPA V1.2 UBUNTU 10.04LTS Client Authentication Message-ID: <28D2327D43A0C84D89CF661F17B0D3A01666D9D451@SCSU81.campus.stcloudstate.edu> I was wondering if anyone knew of a good guide to get the new Ubuntu LTS 10.04 OS to authenticate against a FreeIPA server. It would also be a good one to add to the client config list as a Debian/Ubuntu client guide. Then I think you'd cover the majority of popular OS's in the client config guides. I noticed in the ubuntu apt repo that there is an sssd package version 1.0.6-0ubuntu1~lucid1. Just not sure how to configure it for authentication and FreeIPA. From sgallagh at redhat.com Tue Oct 5 18:34:36 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 05 Oct 2010 14:34:36 -0400 Subject: [Freeipa-users] FreeIPA V1.2 UBUNTU 10.04LTS Client Authentication In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A01666D9D451@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A01666D9D451@SCSU81.campus.stcloudstate.edu> Message-ID: <4CAB6FBC.5010106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2010 12:53 PM, Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > I was wondering if anyone knew of a good guide to get the new Ubuntu LTS 10.04 OS to authenticate against a FreeIPA server. It would also be a good one to add to the client config list as a Debian/Ubuntu client guide. Then I think you'd cover the majority of popular OS's in the client config guides. I noticed in the ubuntu apt repo that there is an sssd package version 1.0.6-0ubuntu1~lucid1. Just not sure how to configure it for authentication and FreeIPA. > Just so you know, the version of SSSD in Lucid right now is very old (and no longer supported upstream). The Maverick APT repositories have SSSD 1.2.1, which is much more recent and still supported. I'd recommend using that as your IPA client, rather than 1.0.x First, you'll need to create a host keytab for your client. You can do this on the server by following these instructions: http://freeipa.org/docs/1.2/Administration_Guide/en-US/html/sect-Administration_Guide-Configuring_Authentication-Managing_Service_Principals.html You'll need to create a service principal for host/fully.qualified.domain at REALM.COM, then generate a keytab and transfer it over to the client. With IPA 1.2, you'd want to set it up as an LDAP+Kerberos system. See https://fedorahosted.org/sssd/wiki/HOWTO_Configure#Example3:AuthenticatingagainstaKerberosserver for an example of how to do this. As an option, you can also add the lines: ldap_sasl_mech = gssapi ldap_krb5_keyrab = /path/to/keytab This will use your kerberos keytab to encrypt communications with your LDAP server (an optional, but nice feature). There is no documentation currently for Ubuntu because no one has tried to write one. If you would like to record your notes and submit them later, we can have one of our doc people take a look and see if we can add it to the formal documentation. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrb7wACgkQeiVVYja6o6MC7QCdHVrnUDActC3cuuqnVogiaFTy k9gAn16wUSy50Qv3vEHz0+u4vhT1GwX1 =k4f5 -----END PGP SIGNATURE----- From danieljamesscott at gmail.com Wed Oct 6 14:26:48 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 10:26:48 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes Message-ID: 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 From ssorce at redhat.com Wed Oct 6 15:32:14 2010 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 6 Oct 2010 11:32:14 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: Message-ID: <20101006113214.3532e46d@willson.li.ssimo.org> 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 From danieljamesscott at gmail.com Wed Oct 6 18:28:11 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 14:28:11 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <20101006113214.3532e46d@willson.li.ssimo.org> References: <20101006113214.3532e46d@willson.li.ssimo.org> Message-ID: 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 From rcritten at redhat.com Wed Oct 6 19:34:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Oct 2010 15:34:41 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> Message-ID: <4CACCF51.9050408@redhat.com> 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 From danieljamesscott at gmail.com Wed Oct 6 19:56:36 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 15:56:36 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CACCF51.9050408@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> Message-ID: 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: curie_admins.ldif Type: text/x-ldif Size: 619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ohm_admins.ldif Type: text/x-ldif Size: 619 bytes Desc: not available URL: From rmeggins at redhat.com Wed Oct 6 20:17:56 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 Oct 2010 14:17:56 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> Message-ID: <4CACD974.6050604@redhat.com> 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From danieljamesscott at gmail.com Wed Oct 6 22:08:27 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 18:08:27 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CACD974.6050604@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> Message-ID: 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 at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > From rmeggins at redhat.com Wed Oct 6 22:30:09 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 Oct 2010 16:30:09 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> Message-ID: <4CACF871.9030701@redhat.com> 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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >> From danieljamesscott at gmail.com Wed Oct 6 23:20:14 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 19:20:14 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CACF871.9030701@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> Message-ID: 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: [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc 162 324 3564 [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: inetUser'|wc 162 324 3564 [djscott at 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 >>>>> >>>>> >>>>> >>>>> ?------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>> >>> > > From nkinder at redhat.com Wed Oct 6 23:29:21 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 06 Oct 2010 16:29:21 -0700 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> Message-ID: <4CAD0651.1000406@redhat.com> 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 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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >> >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From danieljamesscott at gmail.com Wed Oct 6 23:46:34 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 6 Oct 2010 19:46:34 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAD0651.1000406@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CAD0651.1000406@redhat.com> Message-ID: 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 at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>> >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rmeggins at redhat.com Thu Oct 7 02:02:08 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 Oct 2010 20:02:08 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> Message-ID: <4CAD2A20.303@redhat.com> 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: > > [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b > 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc > 162 324 3564 > [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b > 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: > inetUser'|wc > 162 324 3564 > [djscott at 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 at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>> >> From rmeggins at redhat.com Thu Oct 7 02:03:34 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 06 Oct 2010 20:03:34 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CAD0651.1000406@redhat.com> Message-ID: <4CAD2A76.70505@redhat.com> 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 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 at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From danieljamesscott at gmail.com Thu Oct 7 14:11:49 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 7 Oct 2010 10:11:49 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAD2A20.303@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> Message-ID: 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: >> >> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >> ? ?162 ? ? 324 ? ?3564 >> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >> inetUser'|wc >> ? ?162 ? ? 324 ? ?3564 >> [djscott at 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: [root at 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 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 at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From rmeggins at redhat.com Thu Oct 7 14:20:17 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 07 Oct 2010 08:20:17 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> Message-ID: <4CADD721.2040603@redhat.com> 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: >>> >>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>> 162 324 3564 >>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>> inetUser'|wc >>> 162 324 3564 >>> [djscott at 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: > > [root at 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? >>>>>> >>>>>> >>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-users mailing list >>>>>>>> Freeipa-users at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> From danieljamesscott at gmail.com Thu Oct 7 14:43:15 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 7 Oct 2010 10:43:15 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CADD721.2040603@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> Message-ID: 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: >>>> >>>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>>> ? 162 ? ? 324 ? ?3564 >>>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>>> inetUser'|wc >>>> ? 162 ? ? 324 ? ?3564 >>>> [djscott at 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: >> >> [root at 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 >>>>>>>>>>>> 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 at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From james.roman at ssaihq.com Thu Oct 7 14:56:29 2010 From: james.roman at ssaihq.com (James Roman) Date: Thu, 07 Oct 2010 10:56:29 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> Message-ID: <4CADDF9D.8030308@ssaihq.com> > 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. From rcritten at redhat.com Thu Oct 7 14:58:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Oct 2010 10:58:02 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> Message-ID: <4CADDFFA.4060908@redhat.com> 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: >>>>> >>>>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >>>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>>>> 162 324 3564 >>>>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >>>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>>>> inetUser'|wc >>>>> 162 324 3564 >>>>> [djscott at 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: >>> >>> [root at 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 From ssorce at redhat.com Thu Oct 7 14:58:56 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 7 Oct 2010 10:58:56 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> Message-ID: <20101007105856.3eb68be6@willson.li.ssimo.org> 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 From danieljamesscott at gmail.com Thu Oct 7 15:16:20 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 7 Oct 2010 11:16:20 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CADDFFA.4060908@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> Message-ID: 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: >>>>>> >>>>>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >>>>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>>>>> ? 162 ? ? 324 ? ?3564 >>>>>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >>>>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>>>>> inetUser'|wc >>>>>> ? 162 ? ? 324 ? ?3564 >>>>>> [djscott at 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: >>>> >>>> [root at 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 From rmeggins at redhat.com Thu Oct 7 15:20:29 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 07 Oct 2010 09:20:29 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> Message-ID: <4CADE53D.1020503@redhat.com> 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: >>>>>>> >>>>>>> [djscott at ohm ~]$ ldapsearch -h curie.example.com -x -b >>>>>>> 'cn=users,cn=accounts,dc=example.com' |grep 'objectClass: inetUser'|wc >>>>>>> 162 324 3564 >>>>>>> [djscott at ohm ~]$ ldapsearch -h ohm.example.com -x -b >>>>>>> 'cn=users,cn=accounts,dc=example,dc=com' |grep 'objectClass: >>>>>>> inetUser'|wc >>>>>>> 162 324 3564 >>>>>>> [djscott at 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: >>>>> >>>>> [root at 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 > From james.roman at ssaihq.com Thu Oct 7 15:32:43 2010 From: james.roman at ssaihq.com (James Roman) Date: Thu, 07 Oct 2010 11:32:43 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CADE53D.1020503@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> Message-ID: <4CADE81B.6070508@ssaihq.com> 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 From ssorce at redhat.com Thu Oct 7 15:45:08 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 7 Oct 2010 11:45:08 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CADE53D.1020503@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> Message-ID: <20101007114508.29cf464c@willson.li.ssimo.org> 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 From danieljamesscott at gmail.com Thu Oct 7 15:47:53 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 7 Oct 2010 11:47:53 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CADE81B.6070508@ssaihq.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> Message-ID: 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: [root at 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 From nkinder at redhat.com Thu Oct 7 15:52:44 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 07 Oct 2010 08:52:44 -0700 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAD2A76.70505@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CAD0651.1000406@redhat.com> <4CAD2A76.70505@redhat.com> Message-ID: <4CADECCC.10603@redhat.com> 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 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 at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From Steven.Jones at vuw.ac.nz Thu Oct 7 21:01:22 2010 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 8 Oct 2010 10:01:22 +1300 Subject: [Freeipa-users] When does freeipa make it to the Red Hat tree? some years off? RHEL7? In-Reply-To: <4CADECCC.10603@redhat.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CAD0651.1000406@redhat.com> <4CAD2A76.70505@redhat.com> <4CADECCC.10603@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE4DE3FBA09D@STAWINCOEXMAIL1.staff.vuw.ac.nz> regards Steven Jones Technical Specialist Linux/Vmware Tele 64 4 463 6272 Victoria University Kelburn New Zealand From danieljamesscott at gmail.com Fri Oct 8 14:15:38 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 8 Oct 2010 10:15:38 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> Message-ID: 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: > > [root at 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 From danieljamesscott at gmail.com Fri Oct 8 16:33:40 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 8 Oct 2010 12:33:40 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAF3B4F.2040203@ssaihq.com> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> Message-ID: 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 From rmeggins at redhat.com Fri Oct 8 17:18:51 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Oct 2010 11:18:51 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> Message-ID: <4CAF527B.2040301@redhat.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From danieljamesscott at gmail.com Fri Oct 8 17:49:23 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 8 Oct 2010 13:49:23 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAF527B.2040301@redhat.com> References: <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> Message-ID: 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 From james.roman at ssaihq.com Fri Oct 8 18:52:01 2010 From: james.roman at ssaihq.com (James Roman) Date: Fri, 08 Oct 2010 14:52:01 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> Message-ID: <4CAF6851.606@ssaihq.com> 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. From danieljamesscott at gmail.com Fri Oct 8 19:08:09 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 8 Oct 2010 15:08:09 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAF6851.606@ssaihq.com> References: <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> <4CAF6851.606@ssaihq.com> Message-ID: 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 From rmeggins at redhat.com Fri Oct 8 19:47:37 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Oct 2010 13:47:37 -0600 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> Message-ID: <4CAF7559.7080400@redhat.com> 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 > From nkinder at redhat.com Fri Oct 8 20:28:14 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 08 Oct 2010 13:28:14 -0700 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: References: <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> <4CAF6851.606@ssaihq.com> Message-ID: <4CAF7EDE.8010205@redhat.com> 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 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From danieljamesscott at gmail.com Fri Oct 8 21:56:43 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 8 Oct 2010 17:56:43 -0400 Subject: [Freeipa-users] Replica not syncing 'memberOf' attributes In-Reply-To: <4CAF7EDE.8010205@redhat.com> References: <4CACD974.6050604@redhat.com> <4CACF871.9030701@redhat.com> <4CAD2A20.303@redhat.com> <4CADD721.2040603@redhat.com> <4CADDFFA.4060908@redhat.com> <4CADE53D.1020503@redhat.com> <4CADE81B.6070508@ssaihq.com> <4CAF3B4F.2040203@ssaihq.com> <4CAF527B.2040301@redhat.com> <4CAF6851.606@ssaihq.com> <4CAF7EDE.8010205@redhat.com> Message-ID: 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 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 where it's coming from. I can find 'nsAccountLock' though.... I haven't seen the admins memberOf log message since I removed admins as a nested group (as expected). Thanks, Dan From dpal at redhat.com Mon Oct 11 13:46:06 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Oct 2010 09:46:06 -0400 Subject: [Freeipa-users] When does freeipa make it to the Red Hat tree? some years off? RHEL7? In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE4DE3FBA09D@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <20101006113214.3532e46d@willson.li.ssimo.org> <4CACCF51.9050408@redhat.com> <4CACD974.6050604@redhat.com> <4CAD0651.1000406@redhat.com> <4CAD2A76.70505@redhat.com> <4CADECCC.10603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE4DE3FBA09D@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4CB3151E.7070606@redhat.com> Steven Jones wrote: > regards > > Steven Jones Technical Specialist Linux/Vmware > Tele 64 4 463 6272 > Victoria University > Kelburn > New Zealand > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Red Hat is working on this. I can't give any specifics but the intent is to have it supported some time in the middle of next year. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From miljank at gmail.com Thu Oct 14 15:41:13 2010 From: miljank at gmail.com (Miljan Karadzic) Date: Thu, 14 Oct 2010 17:41:13 +0200 Subject: [Freeipa-users] Problem with FreeIPA v2 and kpasswd on Solaris 10 Message-ID: <4CB72499.6060708@gmail.com> Hi, I am having problems configuring Solaris 10 client to work with FreeIPA v2 server. Everything seems to be working fine except for password change. When I try to change the password I get this error: $ kpasswd kpasswd: Changing password for user at EXAMPLE.COM. Old password: kpasswd: Cannot establish a session with the Kerberos administrative server for realm EXAMPLE.COM. Database error! Required KADM5 principal missing. In KDC log I can see this entry: AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: SERVER_NOT_FOUND: user at EXAMPLE.COM for changepw/freeipa.example.com at EXAMPLE.COM, Server not found in Kerberos database (freeipa.example.com is my FreeIPA server) And this is how it looks like when it's working: AS_REQ (2 etypes {3 1}) 192.101.1.73: NEEDED_PREAUTH: user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required AS_REQ (2 etypes {3 1}) 192.101.1.73: ISSUE: authtime 1287068308, etypes {rep=3 tkt=18 ses=1}, user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: NEEDED_PREAUTH: kadmin/changepw at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM for ldap/freeipa.example.com at EXAMPLE.COM It seems that Solaris is requiring changepw/freeipa.example.com at EXAMPLE.COM Kerberos principal for password changes, instead of kadmin/changepw at EXAMPLE.COM. I have a landscape with AIX, HP-UX, Linux and Solaris servers, and all other systems do not use mentioned principal, so this seems to be something specific to Solaris (or maybe specific to my configuration :)). Is there a way to instruct Kerberos client which principal to use for password changes? Or, if not, how to add the missing principal (I do not see a way of doing it with FreeIPA commands)? Installed software: Client: SUNWkrbr/SUNWkrbu 11.10.0,REV=2005.01.21.16.34 Server: 389-ds-base-1.2.6.1-2.fc13.i686 ipa-admintools-1.9.0.pre4-0.fc13.i686 ipa-client-1.9.0.pre4-0.fc13.i686 ipa-python-1.9.0.pre4-0.fc13.i686 ipa-server-1.9.0.pre4-0.fc13.i686 ipa-server-selinux-1.9.0.pre4-0.fc13.i686 krb5-libs-1.7.1-14.fc13.i686 krb5-server-1.7.1-14.fc13.i686 krb5-server-ldap-1.7.1-14.fc13.i686 krb5-workstation-1.7.1-14.fc13.i686 pam_krb5-2.3.11-1.fc13.i686 python-iniparse-0.4-1.fc13.noarch python-krbV-1.0.90-1.fc13.i686 Thanks, Miljan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Oct 14 19:23:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Oct 2010 15:23:41 -0400 Subject: [Freeipa-users] Problem with FreeIPA v2 and kpasswd on Solaris 10 In-Reply-To: <4CB72499.6060708@gmail.com> References: <4CB72499.6060708@gmail.com> Message-ID: <4CB758BD.8040403@redhat.com> Miljan Karadzic wrote: > Hi, > > I am having problems configuring Solaris 10 client to work with FreeIPA > v2 server. Everything seems to be working fine except for password > change. When I try to change the password I get this error: > > $ kpasswd > kpasswd: Changing password for user at EXAMPLE.COM. > Old password: > kpasswd: Cannot establish a session with the Kerberos administrative > server for realm EXAMPLE.COM. Database error! Required KADM5 principal > missing. > > In KDC log I can see this entry: > > AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: SERVER_NOT_FOUND: > user at EXAMPLE.COM for changepw/freeipa.example.com at EXAMPLE.COM, Server > not found in Kerberos database > > (freeipa.example.com is my FreeIPA server) > > And this is how it looks like when it's working: > > AS_REQ (2 etypes {3 1}) 192.101.1.73: NEEDED_PREAUTH: user at EXAMPLE.COM > for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required > AS_REQ (2 etypes {3 1}) 192.101.1.73: ISSUE: authtime 1287068308, etypes > {rep=3 tkt=18 ses=1}, user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM > AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: NEEDED_PREAUTH: > kadmin/changepw at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, > Additional pre-authentication required > AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime > 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM > for krbtgt/EXAMPLE.COM at EXAMPLE.COM > TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime > 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM > for ldap/freeipa.example.com at EXAMPLE.COM > > It seems that Solaris is requiring > changepw/freeipa.example.com at EXAMPLE.COM Kerberos principal for password > changes, instead of kadmin/changepw at EXAMPLE.COM. I have a landscape with > AIX, HP-UX, Linux and Solaris servers, and all other systems do not use > mentioned principal, so this seems to be something specific to Solaris > (or maybe specific to my configuration :)). > > Is there a way to instruct Kerberos client which principal to use for > password changes? Or, if not, how to add the missing principal (I do not > see a way of doing it with FreeIPA commands)? > > Installed software: > > Client: > SUNWkrbr/SUNWkrbu 11.10.0,REV=2005.01.21.16.34 > > Server: > 389-ds-base-1.2.6.1-2.fc13.i686 > ipa-admintools-1.9.0.pre4-0.fc13.i686 > ipa-client-1.9.0.pre4-0.fc13.i686 > ipa-python-1.9.0.pre4-0.fc13.i686 > ipa-server-1.9.0.pre4-0.fc13.i686 > ipa-server-selinux-1.9.0.pre4-0.fc13.i686 > krb5-libs-1.7.1-14.fc13.i686 > krb5-server-1.7.1-14.fc13.i686 > krb5-server-ldap-1.7.1-14.fc13.i686 > krb5-workstation-1.7.1-14.fc13.i686 > pam_krb5-2.3.11-1.fc13.i686 > python-iniparse-0.4-1.fc13.noarch > python-krbV-1.0.90-1.fc13.i686 > > Thanks, > Miljan The good news is that I can reproduce this on my Solaris 10 system. The bad news is I'm not sure what the solution is yet. I'll keep looking. regards rob From rcritten at redhat.com Thu Oct 14 19:50:31 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Oct 2010 15:50:31 -0400 Subject: [Freeipa-users] Problem with FreeIPA v2 and kpasswd on Solaris 10 In-Reply-To: <4CB758BD.8040403@redhat.com> References: <4CB72499.6060708@gmail.com> <4CB758BD.8040403@redhat.com> Message-ID: <4CB75F07.7070209@redhat.com> Rob Crittenden wrote: > Miljan Karadzic wrote: >> Hi, >> >> I am having problems configuring Solaris 10 client to work with FreeIPA >> v2 server. Everything seems to be working fine except for password >> change. When I try to change the password I get this error: >> >> $ kpasswd >> kpasswd: Changing password for user at EXAMPLE.COM. >> Old password: >> kpasswd: Cannot establish a session with the Kerberos administrative >> server for realm EXAMPLE.COM. Database error! Required KADM5 principal >> missing. >> >> In KDC log I can see this entry: >> >> AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: SERVER_NOT_FOUND: >> user at EXAMPLE.COM for changepw/freeipa.example.com at EXAMPLE.COM, Server >> not found in Kerberos database >> >> (freeipa.example.com is my FreeIPA server) >> >> And this is how it looks like when it's working: >> >> AS_REQ (2 etypes {3 1}) 192.101.1.73: NEEDED_PREAUTH: user at EXAMPLE.COM >> for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required >> AS_REQ (2 etypes {3 1}) 192.101.1.73: ISSUE: authtime 1287068308, etypes >> {rep=3 tkt=18 ses=1}, user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM >> AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: NEEDED_PREAUTH: >> kadmin/changepw at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >> Additional pre-authentication required >> AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime >> 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM >> for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime >> 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM >> for ldap/freeipa.example.com at EXAMPLE.COM >> >> It seems that Solaris is requiring >> changepw/freeipa.example.com at EXAMPLE.COM Kerberos principal for password >> changes, instead of kadmin/changepw at EXAMPLE.COM. I have a landscape with >> AIX, HP-UX, Linux and Solaris servers, and all other systems do not use >> mentioned principal, so this seems to be something specific to Solaris >> (or maybe specific to my configuration :)). >> >> Is there a way to instruct Kerberos client which principal to use for >> password changes? Or, if not, how to add the missing principal (I do not >> see a way of doing it with FreeIPA commands)? >> >> Installed software: >> >> Client: >> SUNWkrbr/SUNWkrbu 11.10.0,REV=2005.01.21.16.34 >> >> Server: >> 389-ds-base-1.2.6.1-2.fc13.i686 >> ipa-admintools-1.9.0.pre4-0.fc13.i686 >> ipa-client-1.9.0.pre4-0.fc13.i686 >> ipa-python-1.9.0.pre4-0.fc13.i686 >> ipa-server-1.9.0.pre4-0.fc13.i686 >> ipa-server-selinux-1.9.0.pre4-0.fc13.i686 >> krb5-libs-1.7.1-14.fc13.i686 >> krb5-server-1.7.1-14.fc13.i686 >> krb5-server-ldap-1.7.1-14.fc13.i686 >> krb5-workstation-1.7.1-14.fc13.i686 >> pam_krb5-2.3.11-1.fc13.i686 >> python-iniparse-0.4-1.fc13.noarch >> python-krbV-1.0.90-1.fc13.i686 >> >> Thanks, >> Miljan > > The good news is that I can reproduce this on my Solaris 10 system. The > bad news is I'm not sure what the solution is yet. I'll keep looking. > regards > I can't test this completely because for some reason kinit is segfaulting on my machine. I can get it to use the right principal for kpasswd though, try adding kpasswd_protocol = SET_CHANGE to your [realm] section in /etc/krb/krb5.conf, something like: [realms] EXAMPLE.COM = { kdc = freeipa.example.com:88 admin_server = freeipa.example.com:749 kpasswd_protocol = SET_CHANGE } rob From miljank at gmail.com Thu Oct 14 22:42:14 2010 From: miljank at gmail.com (Miljan Karadzic) Date: Fri, 15 Oct 2010 00:42:14 +0200 Subject: [Freeipa-users] Problem with FreeIPA v2 and kpasswd on Solaris 10 In-Reply-To: <4CB75F07.7070209@redhat.com> References: <4CB72499.6060708@gmail.com> <4CB758BD.8040403@redhat.com> <4CB75F07.7070209@redhat.com> Message-ID: <4CB78746.1070804@gmail.com> On 10/14/10 9:50 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Miljan Karadzic wrote: >>> Hi, >>> >>> I am having problems configuring Solaris 10 client to work with FreeIPA >>> v2 server. Everything seems to be working fine except for password >>> change. When I try to change the password I get this error: >>> >>> $ kpasswd >>> kpasswd: Changing password for user at EXAMPLE.COM. >>> Old password: >>> kpasswd: Cannot establish a session with the Kerberos administrative >>> server for realm EXAMPLE.COM. Database error! Required KADM5 principal >>> missing. >>> >>> In KDC log I can see this entry: >>> >>> AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: SERVER_NOT_FOUND: >>> user at EXAMPLE.COM for changepw/freeipa.example.com at EXAMPLE.COM, Server >>> not found in Kerberos database >>> >>> (freeipa.example.com is my FreeIPA server) >>> >>> And this is how it looks like when it's working: >>> >>> AS_REQ (2 etypes {3 1}) 192.101.1.73: NEEDED_PREAUTH: user at EXAMPLE.COM >>> for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required >>> AS_REQ (2 etypes {3 1}) 192.101.1.73: ISSUE: authtime 1287068308, >>> etypes >>> {rep=3 tkt=18 ses=1}, user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM >>> AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: NEEDED_PREAUTH: >>> kadmin/changepw at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>> Additional pre-authentication required >>> AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime >>> 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM >>> for krbtgt/EXAMPLE.COM at EXAMPLE.COM >>> TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.10.19.35: ISSUE: authtime >>> 1287068319, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at EXAMPLE.COM >>> for ldap/freeipa.example.com at EXAMPLE.COM >>> >>> It seems that Solaris is requiring >>> changepw/freeipa.example.com at EXAMPLE.COM Kerberos principal for >>> password >>> changes, instead of kadmin/changepw at EXAMPLE.COM. I have a landscape >>> with >>> AIX, HP-UX, Linux and Solaris servers, and all other systems do not use >>> mentioned principal, so this seems to be something specific to Solaris >>> (or maybe specific to my configuration :)). >>> >>> Is there a way to instruct Kerberos client which principal to use for >>> password changes? Or, if not, how to add the missing principal (I do >>> not >>> see a way of doing it with FreeIPA commands)? >>> >>> Installed software: >>> >>> Client: >>> SUNWkrbr/SUNWkrbu 11.10.0,REV=2005.01.21.16.34 >>> >>> Server: >>> 389-ds-base-1.2.6.1-2.fc13.i686 >>> ipa-admintools-1.9.0.pre4-0.fc13.i686 >>> ipa-client-1.9.0.pre4-0.fc13.i686 >>> ipa-python-1.9.0.pre4-0.fc13.i686 >>> ipa-server-1.9.0.pre4-0.fc13.i686 >>> ipa-server-selinux-1.9.0.pre4-0.fc13.i686 >>> krb5-libs-1.7.1-14.fc13.i686 >>> krb5-server-1.7.1-14.fc13.i686 >>> krb5-server-ldap-1.7.1-14.fc13.i686 >>> krb5-workstation-1.7.1-14.fc13.i686 >>> pam_krb5-2.3.11-1.fc13.i686 >>> python-iniparse-0.4-1.fc13.noarch >>> python-krbV-1.0.90-1.fc13.i686 >>> >>> Thanks, >>> Miljan >> >> The good news is that I can reproduce this on my Solaris 10 system. The >> bad news is I'm not sure what the solution is yet. I'll keep looking. >> regards >> > > I can't test this completely because for some reason kinit is > segfaulting on my machine. I can get it to use the right principal for > kpasswd though, try adding kpasswd_protocol = SET_CHANGE to your > [realm] section in /etc/krb/krb5.conf, something like: > > [realms] > EXAMPLE.COM = { > kdc = freeipa.example.com:88 > admin_server = freeipa.example.com:749 > kpasswd_protocol = SET_CHANGE > } > > rob Hi Rob, After adding kpasswd_protocol entry into krb5.conf file, kpasswd is using correct principal, but now it fails before setting the new password. $ kpasswd kpasswd: Changing password for user at EXAMPLE.COM. Old password: New password: New password (again): kpasswd: Malformed request error And password is not changed after this. KDC log says: AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: NEEDED_PREAUTH: user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required AS_REQ (6 etypes {18 17 16 23 3 1}) 10.134.19.22: ISSUE: authtime 1287095138, etypes {rep=18 tkt=18 ses=18}, user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM I'll take a closer look at this tomorrow, as it is quite late here. :) From kambiz at mcnc.org Fri Oct 22 15:46:10 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Fri, 22 Oct 2010 11:46:10 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 Message-ID: <4CC1B1C2.6010108@mcnc.org> Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) and the procedure took an extremely long time (at least 2 hours). There appears to be an upgrade script that runs as part of %posttrans which runs: /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > /dev/null 2>&1 I don't have the error logs unfortunately, as when I reverted the ESX VM, I forgot to save off the log files, but what I recall was that there were messages indicating that there were multiple passes (each took about 4-5 minutes) and each time the rate of update dropped below a certain amount, the update would move on to the next "pass". There were about 25 passes through before the upgrade completed. Mind you, this installation is rather small IMO, as there are only 130-ish entries under cn=users,cn=accounts. The other thing that I noticed after the upgrade procedure was that not all the users were defined in the directory (most appeared to be there, but some critical users were missing). Suffices to say that many of our processes were broken after the upgrade and 4 hours into the planned upgrade, I ended up backing out. (This same upgrade had been tested on a smaller directory and the upgrade seemed to go without incident). I'm wondering if there might be an easier way for me to go about upgrading the installation. For example, could I, instead of going through the "upgrade", instead, re-install a replacement 389-ds based ipa-server host, create a new winsync agreement with my AD environment, and then export the password data for the users in DS from the current fedora-ds-base-1.1.3 and import it into the directory running 389-ds-base ? If this is do-able, what all do I need to copy from the fedora-ds-base host to the 389-ds-base host? Thanks Kambiz -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From rmeggins at redhat.com Fri Oct 22 16:14:43 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 22 Oct 2010 10:14:43 -0600 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1B1C2.6010108@mcnc.org> References: <4CC1B1C2.6010108@mcnc.org> Message-ID: <4CC1B873.8090207@redhat.com> Kambiz Aghaiepour wrote: > Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I > attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) > and the procedure took an extremely long time (at least 2 hours). There > appears to be an upgrade script that runs as part of %posttrans which runs: > > /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > > /dev/null 2>&1 > > I don't have the error logs unfortunately, as when I reverted the ESX > VM, I forgot to save off the log files, but what I recall was that there > were messages indicating that there were multiple passes (each took > about 4-5 minutes) and each time the rate of update dropped below a > certain amount, the update would move on to the next "pass". There were > about 25 passes through before the upgrade completed. Mind you, this > installation is rather small IMO, as there are only 130-ish entries > under cn=users,cn=accounts. The other thing that I noticed after the > upgrade procedure was that not all the users were defined in the > directory (most appeared to be there, but some critical users were > missing). Suffices to say that many of our processes were broken after > the upgrade and 4 hours into the planned upgrade, I ended up backing > out. (This same upgrade had been tested on a smaller directory and the > upgrade seemed to go without incident). > This may be https://bugzilla.redhat.com/show_bug.cgi?id=572018 but I can't be sure without more information. We are testing a potential fix for this which will be available in 389-ds-base-1.2.7.a2 > I'm wondering if there might be an easier way for me to go about > upgrading the installation. For example, could I, instead of going > through the "upgrade", instead, re-install a replacement 389-ds based > ipa-server host, create a new winsync agreement with my AD environment, > and then export the password data for the users in DS from the current > fedora-ds-base-1.1.3 and import it into the directory running > 389-ds-base ? If this is do-able, what all do I need to copy from the > fedora-ds-base host to the 389-ds-base host? > > Thanks > Kambiz > > > From dpal at redhat.com Fri Oct 22 16:14:27 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 22 Oct 2010 12:14:27 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1B1C2.6010108@mcnc.org> References: <4CC1B1C2.6010108@mcnc.org> Message-ID: <4CC1B863.7010909@redhat.com> Kambiz Aghaiepour wrote: > Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I > attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) > and the procedure took an extremely long time (at least 2 hours). There > appears to be an upgrade script that runs as part of %posttrans which runs: > > /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > > /dev/null 2>&1 > > I don't have the error logs unfortunately, as when I reverted the ESX > VM, I forgot to save off the log files, but what I recall was that there > were messages indicating that there were multiple passes (each took > about 4-5 minutes) and each time the rate of update dropped below a > certain amount, the update would move on to the next "pass". There were > about 25 passes through before the upgrade completed. Mind you, this > installation is rather small IMO, as there are only 130-ish entries > under cn=users,cn=accounts. The other thing that I noticed after the > upgrade procedure was that not all the users were defined in the > directory (most appeared to be there, but some critical users were > missing). Suffices to say that many of our processes were broken after > the upgrade and 4 hours into the planned upgrade, I ended up backing > out. (This same upgrade had been tested on a smaller directory and the > upgrade seemed to go without incident). > > I'm wondering if there might be an easier way for me to go about > upgrading the installation. For example, could I, instead of going > through the "upgrade", instead, re-install a replacement 389-ds based > ipa-server host, create a new winsync agreement with my AD environment, > and then export the password data for the users in DS from the current > fedora-ds-base-1.1.3 and import it into the directory running > 389-ds-base ? If this is do-able, what all do I need to copy from the > fedora-ds-base host to the 389-ds-base host? > What is your final goal and why are you trying to do the upgrade of the DS under IPA? > Thanks > Kambiz > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mike at cchtml.com Fri Oct 22 20:06:04 2010 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 22 Oct 2010 15:06:04 -0500 Subject: [Freeipa-users] Do I need to install FreeIPA? Message-ID: <4CC1EEAC.4050806@cchtml.com> Hi all, I have a server running 389, DNS (bind) with DHCP (dynamic dns), Samba (Domain Controller), httpd for Wiki and a Koji instance, and Cobbler for network installing RHEL. It runs everything great right now for Fedora and Windows clients and it is easy to admin with the 389 console or Webmin for the other things. I looked at FreeIPA and it seems to be just a fancy front-end to configure those same tools. What benefits would I see if I installed FreeIPA given my server config above? Thanks, Michael P.S. I attempted to install it but I ran into a dependency conflict with mod_ssl. I require that for Koji, so there seems to be a problem there. From kambiz at mcnc.org Fri Oct 22 20:12:34 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Fri, 22 Oct 2010 16:12:34 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1B863.7010909@redhat.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> Message-ID: <4CC1F032.9090100@mcnc.org> Dmitri Pal wrote: > Kambiz Aghaiepour wrote: >> Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I >> attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) >> and the procedure took an extremely long time (at least 2 hours). There >> appears to be an upgrade script that runs as part of %posttrans which runs: >> >> /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > >> /dev/null 2>&1 >> >> I don't have the error logs unfortunately, as when I reverted the ESX >> VM, I forgot to save off the log files, but what I recall was that there >> were messages indicating that there were multiple passes (each took >> about 4-5 minutes) and each time the rate of update dropped below a >> certain amount, the update would move on to the next "pass". There were >> about 25 passes through before the upgrade completed. Mind you, this >> installation is rather small IMO, as there are only 130-ish entries >> under cn=users,cn=accounts. The other thing that I noticed after the >> upgrade procedure was that not all the users were defined in the >> directory (most appeared to be there, but some critical users were >> missing). Suffices to say that many of our processes were broken after >> the upgrade and 4 hours into the planned upgrade, I ended up backing >> out. (This same upgrade had been tested on a smaller directory and the >> upgrade seemed to go without incident). >> >> I'm wondering if there might be an easier way for me to go about >> upgrading the installation. For example, could I, instead of going >> through the "upgrade", instead, re-install a replacement 389-ds based >> ipa-server host, create a new winsync agreement with my AD environment, >> and then export the password data for the users in DS from the current >> fedora-ds-base-1.1.3 and import it into the directory running >> 389-ds-base ? If this is do-able, what all do I need to copy from the >> fedora-ds-base host to the 389-ds-base host? >> > > What is your final goal and why are you trying to do the upgrade of the > DS under IPA? Ah. Ok, the goal is to be able to instantiate additional replicas. However, when I try, I get: [13/Oct/2010:10:04:24 -0400] - import userRoot: Import failed. [13/Oct/2010:10:04:24 -0400] - process_bulk_import_op: NULL backend I am told this could be fixed with 389-ds-base, though I cannot be certain. If I can resolve the issue of creating additional replicas, there would not necessarily be a compelling reason for me to update to 389-ds-base, and I would happily stay running fedora-ds-base-1.1.3 Kambiz > > >> Thanks >> Kambiz >> >> >> > > -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From dpal at redhat.com Fri Oct 22 20:18:18 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 22 Oct 2010 16:18:18 -0400 Subject: [Freeipa-users] Do I need to install FreeIPA? In-Reply-To: <4CC1EEAC.4050806@cchtml.com> References: <4CC1EEAC.4050806@cchtml.com> Message-ID: <4CC1F18A.1050506@redhat.com> Michael Cronenworth wrote: > Hi all, > > I have a server running 389, DNS (bind) with DHCP (dynamic dns), Samba > (Domain Controller), httpd for Wiki and a Koji instance, and Cobbler > for network installing RHEL. It runs everything great right now for > Fedora and Windows clients and it is easy to admin with the 389 > console or Webmin for the other things. > > I looked at FreeIPA and it seems to be just a fancy front-end to > configure those same tools. What benefits would I see if I installed > FreeIPA given my server config above? > It is domain controller in itself. It is more targeted for UNIX/Lunix environments for now. It would replace your DS with DS + Kerberos. In future it will replace Samba part too as a DC for Windows client - it will reuse samba code not a different implementation rahter different packaging and better integration with Linux portion. If you are talking about IPA v1 there is not much value for you other than Kerberos but I assume you use Samba 4 as DC and have it as a Kerberos KDC, right? If you talk about v2 that we have in alphas then there is also better integration and management of hosts, host based access control with SSSD, netgroups, automounts etc. But it has not beed released yet. You can try one of the daily builds if you want. Thanks Dmitri > Thanks, > Michael > > P.S. I attempted to install it but I ran into a dependency conflict > with mod_ssl. I require that for Koji, so there seems to be a problem > there. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Oct 22 20:21:34 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 22 Oct 2010 16:21:34 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1F032.9090100@mcnc.org> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> Message-ID: <4CC1F24E.5080803@redhat.com> Kambiz Aghaiepour wrote: > Dmitri Pal wrote: > >> Kambiz Aghaiepour wrote: >> >>> Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I >>> attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) >>> and the procedure took an extremely long time (at least 2 hours). There >>> appears to be an upgrade script that runs as part of %posttrans which runs: >>> >>> /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > >>> /dev/null 2>&1 >>> >>> I don't have the error logs unfortunately, as when I reverted the ESX >>> VM, I forgot to save off the log files, but what I recall was that there >>> were messages indicating that there were multiple passes (each took >>> about 4-5 minutes) and each time the rate of update dropped below a >>> certain amount, the update would move on to the next "pass". There were >>> about 25 passes through before the upgrade completed. Mind you, this >>> installation is rather small IMO, as there are only 130-ish entries >>> under cn=users,cn=accounts. The other thing that I noticed after the >>> upgrade procedure was that not all the users were defined in the >>> directory (most appeared to be there, but some critical users were >>> missing). Suffices to say that many of our processes were broken after >>> the upgrade and 4 hours into the planned upgrade, I ended up backing >>> out. (This same upgrade had been tested on a smaller directory and the >>> upgrade seemed to go without incident). >>> >>> I'm wondering if there might be an easier way for me to go about >>> upgrading the installation. For example, could I, instead of going >>> through the "upgrade", instead, re-install a replacement 389-ds based >>> ipa-server host, create a new winsync agreement with my AD environment, >>> and then export the password data for the users in DS from the current >>> fedora-ds-base-1.1.3 and import it into the directory running >>> 389-ds-base ? If this is do-able, what all do I need to copy from the >>> fedora-ds-base host to the 389-ds-base host? >>> >>> >> What is your final goal and why are you trying to do the upgrade of the >> DS under IPA? >> > > Ah. Ok, the goal is to be able to instantiate additional replicas. > However, when I try, I get: > > [13/Oct/2010:10:04:24 -0400] - import userRoot: Import failed. > [13/Oct/2010:10:04:24 -0400] - process_bulk_import_op: NULL backend > > I am told this could be fixed with 389-ds-base, though I cannot be certain. > > If I can resolve the issue of creating additional replicas, there would > not necessarily be a compelling reason for me to update to 389-ds-base, > and I would happily stay running fedora-ds-base-1.1.3 > > > Kambiz > > Rich, Rob Is this a known issue with creating replicas using IPA 1.2.x? Replica creation worked in v1.2 AFAIR. >> >>> Thanks >>> Kambiz >>> >>> >>> >>> >> > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Fri Oct 22 20:29:10 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 22 Oct 2010 14:29:10 -0600 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1F24E.5080803@redhat.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> <4CC1F24E.5080803@redhat.com> Message-ID: <4CC1F416.6080108@redhat.com> Dmitri Pal wrote: > Kambiz Aghaiepour wrote: > >> Dmitri Pal wrote: >> >> >>> Kambiz Aghaiepour wrote: >>> >>> >>>> Currently running ipa-server-1.2.1-4 with fedora-ds-base-1.1.3-6. I >>>> attempted to upgrade to 389-ds-base-1.2.6.1-2 (and supporting packages) >>>> and the procedure took an extremely long time (at least 2 hours). There >>>> appears to be an upgrade script that runs as part of %posttrans which runs: >>>> >>>> /usr/sbin/setup-ds.pl -l /dev/null -u -s General.UpdateMode=offline > >>>> /dev/null 2>&1 >>>> >>>> I don't have the error logs unfortunately, as when I reverted the ESX >>>> VM, I forgot to save off the log files, but what I recall was that there >>>> were messages indicating that there were multiple passes (each took >>>> about 4-5 minutes) and each time the rate of update dropped below a >>>> certain amount, the update would move on to the next "pass". There were >>>> about 25 passes through before the upgrade completed. Mind you, this >>>> installation is rather small IMO, as there are only 130-ish entries >>>> under cn=users,cn=accounts. The other thing that I noticed after the >>>> upgrade procedure was that not all the users were defined in the >>>> directory (most appeared to be there, but some critical users were >>>> missing). Suffices to say that many of our processes were broken after >>>> the upgrade and 4 hours into the planned upgrade, I ended up backing >>>> out. (This same upgrade had been tested on a smaller directory and the >>>> upgrade seemed to go without incident). >>>> >>>> I'm wondering if there might be an easier way for me to go about >>>> upgrading the installation. For example, could I, instead of going >>>> through the "upgrade", instead, re-install a replacement 389-ds based >>>> ipa-server host, create a new winsync agreement with my AD environment, >>>> and then export the password data for the users in DS from the current >>>> fedora-ds-base-1.1.3 and import it into the directory running >>>> 389-ds-base ? If this is do-able, what all do I need to copy from the >>>> fedora-ds-base host to the 389-ds-base host? >>>> >>>> >>>> >>> What is your final goal and why are you trying to do the upgrade of the >>> DS under IPA? >>> >>> >> Ah. Ok, the goal is to be able to instantiate additional replicas. >> However, when I try, I get: >> >> [13/Oct/2010:10:04:24 -0400] - import userRoot: Import failed. >> [13/Oct/2010:10:04:24 -0400] - process_bulk_import_op: NULL backend >> >> I am told this could be fixed with 389-ds-base, though I cannot be certain. >> >> If I can resolve the issue of creating additional replicas, there would >> not necessarily be a compelling reason for me to update to 389-ds-base, >> and I would happily stay running fedora-ds-base-1.1.3 >> >> >> Kambiz >> >> >> > Rich, Rob > > Is this a known issue with creating replicas using IPA 1.2.x? > This happened intermittently with some 389 releases. We think it has been fixed in 389-ds-base-1.2.6.1-2 but we need more testing. > Replica creation worked in v1.2 AFAIR. > > >>> >>> >>>> Thanks >>>> Kambiz >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > > From mike at cchtml.com Fri Oct 22 21:55:41 2010 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 22 Oct 2010 16:55:41 -0500 Subject: [Freeipa-users] Do I need to install FreeIPA? In-Reply-To: <4CC1F18A.1050506@redhat.com> References: <4CC1EEAC.4050806@cchtml.com> <4CC1F18A.1050506@redhat.com> Message-ID: <4CC2085D.3080602@cchtml.com> Dmitri Pal on 10/22/2010 03:18 PM wrote: > It is domain controller in itself. It is more targeted for UNIX/Lunix > environments for now. It would replace your DS with DS + Kerberos. > In future it will replace Samba part too as a DC for Windows client - it > will reuse samba code not a different implementation rahter different > packaging and better integration with Linux portion. > > If you are talking about IPA v1 there is not much value for you other > than Kerberos but I assume you use Samba 4 as DC and have it as a > Kerberos KDC, right? Ah... I get it now. I'm actually using Samba 3 as I wasn't sure how stable Samba 4 would be. > If you talk about v2 that we have in alphas then there is also better > integration and management of hosts, host based access control with > SSSD, netgroups, automounts etc. But it has not beed released yet. > You can try one of the daily builds if you want. The majority of clients are Windows, so having the other options aren't that necessary. Thanks for the heads up. I'll keep my eye on the project, but I don't think I need to make the switch just yet. From ide4you at gmail.com Sun Oct 24 15:11:49 2010 From: ide4you at gmail.com (Uzor Ide) Date: Sun, 24 Oct 2010 11:11:49 -0400 Subject: [Freeipa-users] certmonger selinux issue and freeipa dns database error problem Message-ID: We have a network that relies on kerberos, 389-ds, bind and nfs4. I am currently testing out the freeipa version 2 to see if we can use it to consolidate the various configuration into one interface. For the most part it works great apart from the obvious area where it has not been completed. However there are somethings that I have noticed. 1.) The DNS logging always logs database error every time it access the ldap. even though the query returns okay and the dns reply is fine. here is an excerpt of the log named.run 24-Oct-2010 10:32:33.025 edns-disabled: info: success resolving ' www.mailscanner.tv/A' (in 'mailscanner.tv'?) after reducing the advertised EDNS UDP packet size to 512 octets 24-Oct-2010 10:34:41.137 database: error: querying 'idnsName=wpad, idnsname= uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' 24-Oct-2010 10:34:41.140 database: error: querying 'idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' 24-Oct-2010 10:34:41.143 database: error: entry count: 1 24-Oct-2010 10:34:41.146 database: error: querying 'idnsName=wpad, idnsname= uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' 24-Oct-2010 10:39:43.581 database: error: querying 'idnsName=wpad, idnsname= uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' 24-Oct-2010 10:39:43.583 database: error: querying 'idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' 24-Oct-2010 10:39:43.586 database: error: entry count: 1 24-Oct-2010 10:39:43.589 database: error: querying 'idnsName=wpad, idnsname= uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)' here is our logging configuration // ******************* // Logging definitions // ******************* // Logging logging { channel "named_log" { file "data/log/named.run" versions 5 size 4m; severity dynamic; print-category yes; print-severity yes; print-time yes; }; channel "security_log" { file "data/log/security.log" versions 5 size 10m; severity dynamic; print-category yes; print-severity yes; print-time yes; }; channel "query_log" { file "data/log/query.log" versions 5 size 50m; #severity dynamic; severity debug; print-category yes; print-severity yes; print-time yes; }; channel "transfer_log" { file "data/log/transfer.log" versions 5 size 10m; severity dynamic; print-category yes; print-severity yes; }; category "default" { "named_log"; "default_syslog"; "default_debug"; }; category "general" { "named_log"; }; category "queries" { "query_log"; }; category "lame-servers" { null; }; category "security" { "security_log"; }; category "config" { "named_log"; }; category "resolver" { "query_log"; }; category "xfer-in" { "transfer_log"; }; category "xfer-out" { "transfer_log"; }; category "notify" { "transfer_log"; }; category "client" { "query_log"; }; category "network" { "named_log"; }; category "update" { "transfer_log"; }; category "dnssec" { "security_log"; }; category "dispatch" { "security_log"; }; }; This error message keeps triggering our monitoring systems. 2.) I currently have only one ipa-client; and certmonger keeps getting seliux AVC denials Oct 24 10:57:24 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 Oct 24 10:57:56 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 Oct 24 10:58:26 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 Oct 24 10:58:57 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2 Summary: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. Detailed Description: SELinux denied access requested by certmonger. It is not expected that this access is required by certmonger and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:certmonger_t:s0 Target Context system_u:object_r:bin_t:s0 Target Objects /usr/libexec/certmonger/ipa-submit [ file ] Source certmonger Source Path /usr/sbin/certmonger Port Host ulasi.uzdomain.ca Source RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 Target RPM Packages certmonger-0.32-0.2010101515git5920eca.fc13 Policy RPM selinux-policy-3.7.19-65.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name ulasi.uzdomain.ca Platform Linux ulasi.uzdomain.ca2.6.34.7-61.fc13.i686.PAE #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 Alert Count 1646 First Seen Sat Oct 23 15:48:48 2010 Last Seen Sun Oct 24 10:59:52 2010 Local ID 8db766a3-6100-4be5-aec6-2a3a713290e2 Line Numbers Raw Audit Messages node=ulasi.uzdomain.ca type=AVC msg=audit(1287932392.282:21690): avc: denied { execute } for pid=3472 comm="certmonger" name="ipa-submit" dev=dm-0 ino=790251 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file node=ulasi.uzdomain.ca type=SYSCALL msg=audit(1287932392.282:21690): arch=40000003 syscall=11 success=no exit=-13 a0=9f99490 a1=9f99450 a2=9f98e60 a3=9f99450 items=0 ppid=1555 pid=3472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certmonger" exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 key=(null) I was using certmonger-0.30-1.fc13.i686 from source [ freeipa-devel ] because of the problem I updated to the nightly build certmonger-0.32-0.2010101515git5920eca.fc13 but the problem continues. These are the selinux rpms selinux-policy-targeted-3.7.19-65.fc13.noarch selinux-policy-3.7.19-65.fc13.noarch libselinux-python-2.0.94-2.fc13.i686 libselinux-utils-2.0.94-2.fc13.i686 Thanks Ide -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 25 01:09:35 2010 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 24 Oct 2010 21:09:35 -0400 Subject: [Freeipa-users] certmonger selinux issue and freeipa dns database error problem In-Reply-To: References: Message-ID: <4CC4D8CF.40701@redhat.com> Uzor Ide wrote: > > We have a network that relies on kerberos, 389-ds, bind and nfs4. I > am currently testing out the freeipa version 2 to see if we can use it > to consolidate the various configuration into one interface. For the > most part it works great apart from the obvious area where it has not > been completed. However there are somethings that I have noticed. > > 1.) The DNS logging always logs database error every time it access > the ldap. even though the query returns okay and the dns reply is fine. > Opened https://fedorahosted.org/freeipa/ticket/409 > > 2.) I currently have only one ipa-client; and certmonger keeps > getting seliux AVC denials Opened https://bugzilla.redhat.com/show_bug.cgi?id=646225 > Thanks > Thanks for the input! > Ide > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kambiz at aghaiepour.com Mon Oct 25 16:54:29 2010 From: kambiz at aghaiepour.com (Kambiz Aghaiepour) Date: Mon, 25 Oct 2010 12:54:29 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC1F416.6080108@redhat.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> <4CC1F24E.5080803@redhat.com> <4CC1F416.6080108@redhat.com> Message-ID: <4CC5B645.1060808@aghaiepour.com> Would there be any way to identify what causes this during replication creation (versions ipa-server-1.2.1-4 and fedora-ds-base-1.1.3, on centos-5.4): <--- snip ---> Starting replication, please wait until this has completed. Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress [rhds-test-01.example.org] reports: Update failed! Status: [2 Total update abortedLDAP error: Protocol error] creation of replica failed: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. <--- snip ---> The errorlog section is also attached. Kambiz -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-replica-errorlog.txt URL: From rmeggins at redhat.com Mon Oct 25 16:59:27 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Oct 2010 10:59:27 -0600 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC5B645.1060808@aghaiepour.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> <4CC1F24E.5080803@redhat.com> <4CC1F416.6080108@redhat.com> <4CC5B645.1060808@aghaiepour.com> Message-ID: <4CC5B76F.8030302@redhat.com> Kambiz Aghaiepour wrote: > Would there be any way to identify what causes this during replication > creation (versions ipa-server-1.2.1-4 and fedora-ds-base-1.1.3, on > centos-5.4): > 389-ds-base-1.2.6.1 cannot replicate to previous versions of 389/fedora ds 389-ds-base-1.2.7.a3 fixes this problem and should be going into the testing repos soon - if you want, you can download the rpm directly from koji and try it out: http://koji.fedoraproject.org/koji/buildinfo?buildID=201596 > <--- snip ---> > Starting replication, please wait until this has completed. > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > [rhds-test-01.example.org] reports: Update failed! Status: [2 Total > update abortedLDAP error: Protocol error] > creation of replica failed: Failed to start replication > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > <--- snip ---> > > The errorlog section is also attached. > > Kambiz > > From kambiz at aghaiepour.com Mon Oct 25 17:00:40 2010 From: kambiz at aghaiepour.com (Kambiz Aghaiepour) Date: Mon, 25 Oct 2010 13:00:40 -0400 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC5B76F.8030302@redhat.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> <4CC1F24E.5080803@redhat.com> <4CC1F416.6080108@redhat.com> <4CC5B645.1060808@aghaiepour.com> <4CC5B76F.8030302@redhat.com> Message-ID: <4CC5B7B8.7060506@aghaiepour.com> Well ... in this case I am running fedora-ds-1.1.3 across the board still as this is pertaining to my production environment. I attempted to upgrade the production environment, but the %post script took about 2 hours to run, after which several userIDs were missing from the directory, including several test accounts used by our nagios, as well as the company CEO's account. :( So I reverted to fedora-ds-1.1.3. But I really need to get the remote replica up and running. Kambiz Rich Megginson wrote: > Kambiz Aghaiepour wrote: >> Would there be any way to identify what causes this during replication >> creation (versions ipa-server-1.2.1-4 and fedora-ds-base-1.1.3, on >> centos-5.4): >> > 389-ds-base-1.2.6.1 cannot replicate to previous versions of 389/fedora ds > > 389-ds-base-1.2.7.a3 fixes this problem and should be going into the > testing repos soon - if you want, you can download the rpm directly from > koji and try it out: > http://koji.fedoraproject.org/koji/buildinfo?buildID=201596 >> <--- snip ---> >> Starting replication, please wait until this has completed. >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> [rhds-test-01.example.org] reports: Update failed! Status: [2 Total >> update abortedLDAP error: Protocol error] >> creation of replica failed: Failed to start replication >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> <--- snip ---> >> >> The errorlog section is also attached. >> >> Kambiz >> >> > -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From rmeggins at redhat.com Mon Oct 25 17:06:06 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Oct 2010 11:06:06 -0600 Subject: [Freeipa-users] update procedure failed fedora-ds-base-1.1.3 -> 389-ds-base-1.2.6.1 In-Reply-To: <4CC5B7B8.7060506@aghaiepour.com> References: <4CC1B1C2.6010108@mcnc.org> <4CC1B863.7010909@redhat.com> <4CC1F032.9090100@mcnc.org> <4CC1F24E.5080803@redhat.com> <4CC1F416.6080108@redhat.com> <4CC5B645.1060808@aghaiepour.com> <4CC5B76F.8030302@redhat.com> <4CC5B7B8.7060506@aghaiepour.com> Message-ID: <4CC5B8FE.6030706@redhat.com> Kambiz Aghaiepour wrote: > Well ... in this case I am running fedora-ds-1.1.3 across the board > still as this is pertaining to my production environment. I attempted > to upgrade the production environment, but the %post script took about 2 > hours to run, after which several userIDs were missing from the > directory, including several test accounts used by our nagios, as well > as the company CEO's account. :( We believe this is also a bug that has been fixed by 1.2.7.a3 > So I reverted to fedora-ds-1.1.3. > > But I really need to get the remote replica up and running. > > Kambiz > > Rich Megginson wrote: > >> Kambiz Aghaiepour wrote: >> >>> Would there be any way to identify what causes this during replication >>> creation (versions ipa-server-1.2.1-4 and fedora-ds-base-1.1.3, on >>> centos-5.4): >>> >>> >> 389-ds-base-1.2.6.1 cannot replicate to previous versions of 389/fedora ds >> >> 389-ds-base-1.2.7.a3 fixes this problem and should be going into the >> testing repos soon - if you want, you can download the rpm directly from >> koji and try it out: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=201596 >> >>> <--- snip ---> >>> Starting replication, please wait until this has completed. >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> [rhds-test-01.example.org] reports: Update failed! Status: [2 Total >>> update abortedLDAP error: Protocol error] >>> creation of replica failed: Failed to start replication >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> <--- snip ---> >>> >>> The errorlog section is also attached. >>> >>> Kambiz >>> >>> >>> > > > From kambiz at mcnc.org Wed Oct 27 17:09:36 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Wed, 27 Oct 2010 13:09:36 -0400 Subject: [Freeipa-users] replica creation failure with ipa-server-1.2.1 and fedora-ds-base-1.1.3 Message-ID: <4CC85CD0.2010206@mcnc.org> Still struggling to create a replica. Here's what the debug output is showing in the consumer error log: [---snip---] [27/Oct/2010:12:53:30 -0400] - activity on 64r [27/Oct/2010:12:53:30 -0400] - read activity on 64 [27/Oct/2010:12:53:30 -0400] - listener got signaled [27/Oct/2010:12:53:30 -0400] - activity on 64r [27/Oct/2010:12:53:30 -0400] - read activity on 64 [27/Oct/2010:12:53:30 -0400] - listener got signaled [27/Oct/2010:12:53:30 -0400] - activity on 64r [27/Oct/2010:12:53:30 -0400] - read activity on 64 [27/Oct/2010:12:53:30 -0400] - listener got signaled [27/Oct/2010:12:53:35 -0400] - activity on 64r [27/Oct/2010:12:53:35 -0400] - read activity on 64 [27/Oct/2010:12:53:35 -0400] - ber_get_next failed for connection 11 [27/Oct/2010:12:53:35 -0400] - conn 11 activity level = 83 [27/Oct/2010:12:53:35 -0400] - conn 11 turbo rank = 0 out of 1 conns [27/Oct/2010:12:53:35 -0400] - conn 11 entering turbo mode [27/Oct/2010:12:53:35 -0400] - listener got signaled [27/Oct/2010:12:53:35 -0400] - ERROR bulk import abandoned [27/Oct/2010:12:53:35 -0400] - import userRoot: Aborting all import threads... [---snip---] The access log on the consumer reads: [---snip---] [27/Oct/2010:12:53:30 -0400] conn=11 op=80 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" [27/Oct/2010:12:53:30 -0400] conn=11 op=80 RESULT err=0 tag=120 nentries=0 etime=0 [27/Oct/2010:12:53:30 -0400] conn=11 op=81 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" [27/Oct/2010:12:53:30 -0400] conn=11 op=81 RESULT err=0 tag=120 nentries=0 etime=0 [27/Oct/2010:12:53:30 -0400] conn=11 op=82 EXT oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" [27/Oct/2010:12:53:30 -0400] conn=11 op=82 RESULT err=0 tag=120 nentries=0 etime=0 [27/Oct/2010:12:53:35 -0400] conn=11 op=-1 fd=64 closed error 90 (Message too long) - B2 [27/Oct/2010:12:53:42 -0400] conn=12 fd=64 slot=64 SSL connection from 152.45.5.155 to 152.45.5.166 [27/Oct/2010:12:53:42 -0400] conn=12 SSL 256-bit AES [27/Oct/2010:12:53:42 -0400] conn=12 op=0 BIND dn="cn=replication manager,cn=config" method=128 version=3 [27/Oct/2010:12:53:42 -0400] conn=12 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config" [---snip---] (note error 90, message too long). This is between a consumer and supplier on the same subnet. The supplier error log reads (sanitized with "hostname"): [---snip---] [27/Oct/2010:12:53:30 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meTohostname636" (hostname:636)". [27/Oct/2010:12:53:42 -0400] NSMMReplicationPlugin - agmt="cn=meTohostname636" (hostname:636): Failed to send extended operation: LDAP error 81 (Can't contact LDAP server) [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - agmt="cn=mehostname636" (hostname:636): Received error 89: NULL for total update operation [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - agmt="cn=meTohostname636" (hostname:636): Received error 89: NULL for total update operation [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - agmt="cn=meTohostname636" (hostname:636): Received error 89: NULL for total update operation [---snip---] I'm at a loss as to what I can do next. Any help would be appreciated. Kambiz -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From rmeggins at redhat.com Wed Oct 27 20:56:09 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 27 Oct 2010 14:56:09 -0600 Subject: [Freeipa-users] replica creation failure with ipa-server-1.2.1 and fedora-ds-base-1.1.3 In-Reply-To: <4CC85CD0.2010206@mcnc.org> References: <4CC85CD0.2010206@mcnc.org> Message-ID: <4CC891E9.6090701@redhat.com> Kambiz Aghaiepour wrote: > Still struggling to create a replica. Here's what the debug output is > showing in the consumer error log: > > [---snip---] > [27/Oct/2010:12:53:30 -0400] - activity on 64r > [27/Oct/2010:12:53:30 -0400] - read activity on 64 > [27/Oct/2010:12:53:30 -0400] - listener got signaled > [27/Oct/2010:12:53:30 -0400] - activity on 64r > [27/Oct/2010:12:53:30 -0400] - read activity on 64 > [27/Oct/2010:12:53:30 -0400] - listener got signaled > [27/Oct/2010:12:53:30 -0400] - activity on 64r > [27/Oct/2010:12:53:30 -0400] - read activity on 64 > [27/Oct/2010:12:53:30 -0400] - listener got signaled > [27/Oct/2010:12:53:35 -0400] - activity on 64r > [27/Oct/2010:12:53:35 -0400] - read activity on 64 > [27/Oct/2010:12:53:35 -0400] - ber_get_next failed for connection 11 > [27/Oct/2010:12:53:35 -0400] - conn 11 activity level = 83 > [27/Oct/2010:12:53:35 -0400] - conn 11 turbo rank = 0 out of 1 conns > [27/Oct/2010:12:53:35 -0400] - conn 11 entering turbo mode > [27/Oct/2010:12:53:35 -0400] - listener got signaled > [27/Oct/2010:12:53:35 -0400] - ERROR bulk import abandoned > [27/Oct/2010:12:53:35 -0400] - import userRoot: Aborting all import > threads... > [---snip---] > > The access log on the consumer reads: > > [---snip---] > [27/Oct/2010:12:53:30 -0400] conn=11 op=80 EXT > oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" > [27/Oct/2010:12:53:30 -0400] conn=11 op=80 RESULT err=0 tag=120 > nentries=0 etime=0 > [27/Oct/2010:12:53:30 -0400] conn=11 op=81 EXT > oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" > [27/Oct/2010:12:53:30 -0400] conn=11 op=81 RESULT err=0 tag=120 > nentries=0 etime=0 > [27/Oct/2010:12:53:30 -0400] conn=11 op=82 EXT > oid="2.16.840.1.113730.3.5.6" name="Netscape Replication Total Update Entry" > [27/Oct/2010:12:53:30 -0400] conn=11 op=82 RESULT err=0 tag=120 > nentries=0 etime=0 > [27/Oct/2010:12:53:35 -0400] conn=11 op=-1 fd=64 closed error 90 > (Message too long) - B2 > [27/Oct/2010:12:53:42 -0400] conn=12 fd=64 slot=64 SSL connection from > 152.45.5.155 to 152.45.5.166 > [27/Oct/2010:12:53:42 -0400] conn=12 SSL 256-bit AES > [27/Oct/2010:12:53:42 -0400] conn=12 op=0 BIND dn="cn=replication > manager,cn=config" method=128 version=3 > [27/Oct/2010:12:53:42 -0400] conn=12 op=0 RESULT err=0 tag=97 nentries=0 > etime=0 dn="cn=replication manager,cn=config" > [---snip---] > > > (note error 90, message too long). This is between a consumer and > supplier on the same subnet. > Maybe tcpdump/wireshark or some sort of TCP/IP debugging tool could help? I just don't know how to solve this at the application layer - we don't do anything with TCP message sizes in the directory server or the ldap c sdk - we just pass everything to send()/recv() and expect it will do the rest. I don't know if there is some sort of TCP tuning you could do to help this situation. > The supplier error log reads (sanitized with "hostname"): > > [---snip---] > [27/Oct/2010:12:53:30 -0400] NSMMReplicationPlugin - Beginning total > update of replica "agmt="cn=meTohostname636" (hostname:636)". > [27/Oct/2010:12:53:42 -0400] NSMMReplicationPlugin - > agmt="cn=meTohostname636" (hostname:636): Failed to send extended > operation: LDAP error 81 (Can't contact LDAP server) > [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - > agmt="cn=mehostname636" (hostname:636): Received error 89: NULL for > total update operation > [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - > agmt="cn=meTohostname636" (hostname:636): Received error 89: NULL for > total update operation > [27/Oct/2010:12:53:43 -0400] NSMMReplicationPlugin - > agmt="cn=meTohostname636" (hostname:636): Received error 89: NULL for > total update operation > [---snip---] > > I'm at a loss as to what I can do next. Any help would be appreciated. > > Kambiz > > From heco0701 at stcloudstate.edu Thu Oct 28 16:56:02 2010 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Thu, 28 Oct 2010 11:56:02 -0500 Subject: [Freeipa-users] FreeIPA v2 Message-ID: <28D2327D43A0C84D89CF661F17B0D3A0166933A2A5@SCSU81.campus.stcloudstate.edu> Is their a rough estimate when the next version 2.0 prealpha 5 or V2.0 Final will be out? From dpal at redhat.com Thu Oct 28 17:23:20 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 28 Oct 2010 13:23:20 -0400 Subject: [Freeipa-users] FreeIPA v2 In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A0166933A2A5@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A0166933A2A5@SCSU81.campus.stcloudstate.edu> Message-ID: <4CC9B188.8060304@redhat.com> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > Is their a rough estimate when the next version 2.0 prealpha 5 or V2.0 Final will be out? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Next alpha is brewing as we are speaking. Realistically it should be ready next week. Final is at least December - January. Beta might be somewhere in the middle like early December... -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From amrossi at linux.it Fri Oct 29 07:04:24 2010 From: amrossi at linux.it (Andrea Modesto Rossi) Date: Fri, 29 Oct 2010 09:04:24 +0200 (CEST) Subject: [Freeipa-users] FreeIPA v2 In-Reply-To: <4CC9B188.8060304@redhat.com> References: <28D2327D43A0C84D89CF661F17B0D3A0166933A2A5@SCSU81.campus.stcloudstate.edu> <4CC9B188.8060304@redhat.com> Message-ID: <63abc6276b5108305792177ddc462ba2.squirrel@picard.linux.it> On Gio, 28 Ottobre 2010 7:23 pm, Dmitri Pal wrote: > Next alpha is brewing as we are speaking. Realistically it should be > ready next week. > Final is at least December - January. Beta might be somewhere in the > middle like early December... > That's interesting ;-) -- Andrea Modesto Rossi Fedora Ambassador From natxo.asenjo at gmail.com Fri Oct 29 07:43:38 2010 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 29 Oct 2010 09:43:38 +0200 Subject: [Freeipa-users] FreeIPA v2 In-Reply-To: <4CC9B188.8060304@redhat.com> References: <28D2327D43A0C84D89CF661F17B0D3A0166933A2A5@SCSU81.campus.stcloudstate.edu> <4CC9B188.8060304@redhat.com> Message-ID: On Thu, Oct 28, 2010 at 7:23 PM, Dmitri Pal wrote: > Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >> Is their a rough estimate when the next version 2.0 prealpha 5 or V2.0 Final will be out? > Next alpha is brewing as we are speaking. Realistically it should be > ready next week. > Final is at least December - January. Beta might be somewhere in the > middle like early December... I can't wait :) -- natxo From loris at lgs.com.ve Fri Oct 29 16:17:45 2010 From: loris at lgs.com.ve (Loris Santamaria) Date: Fri, 29 Oct 2010 11:47:45 -0430 Subject: [Freeipa-users] Question about dogtag integration Message-ID: <1288369065.2962.4365.camel@arepa.pzo.lgs.com.ve> Hi all while trying the latest nightly build of IPAv2 I noticed the integrated certification authority is installed in a second 389DS instance, so a full IPAv2 server would have (at least) two 389DS instances running. Why is it installed that way, instead of simply adding another suffix in the main instance? Using an alternative suffix in the main instance would consume less memory, would be a service less to monitor, and IMHO a cleaner design having only one ldap server in the system answering all possible queries. -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ -O9 -omg-optimize -fomit-instructions From rmeggins at redhat.com Fri Oct 29 16:41:28 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 29 Oct 2010 10:41:28 -0600 Subject: [Freeipa-users] Question about dogtag integration In-Reply-To: <1288369065.2962.4365.camel@arepa.pzo.lgs.com.ve> References: <1288369065.2962.4365.camel@arepa.pzo.lgs.com.ve> Message-ID: <4CCAF938.70007@redhat.com> Loris Santamaria wrote: > Hi all > > while trying the latest nightly build of IPAv2 I noticed the integrated > certification authority is installed in a second 389DS instance, so a > full IPAv2 server would have (at least) two 389DS instances running. > > Why is it installed that way, instead of simply adding another suffix in > the main instance? Using an alternative suffix in the main instance > would consume less memory, would be a service less to monitor, and IMHO > a cleaner design having only one ldap server in the system answering all > possible queries. > > dogtag uses a "private" instance of directory server for its private, internal database. This server/database should not be queried by external entities for security reasons. From dpal at redhat.com Fri Oct 29 16:40:00 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 29 Oct 2010 12:40:00 -0400 Subject: [Freeipa-users] Question about dogtag integration In-Reply-To: <1288369065.2962.4365.camel@arepa.pzo.lgs.com.ve> References: <1288369065.2962.4365.camel@arepa.pzo.lgs.com.ve> Message-ID: <4CCAF8E0.6010102@redhat.com> Loris Santamaria wrote: > Hi all > > while trying the latest nightly build of IPAv2 I noticed the integrated > certification authority is installed in a second 389DS instance, so a > full IPAv2 server would have (at least) two 389DS instances running. > > Why is it installed that way, instead of simply adding another suffix in > the main instance? Using an alternative suffix in the main instance > would consume less memory, would be a service less to monitor, and IMHO > a cleaner design having only one ldap server in the system answering all > possible queries. > > > AFAIR the CA instance of the DS is completely internal and hidden from the outside world. Combining them in one would require rigorous access control which might be hard to maintain. While I agree that having one instance will save some resources the security risk is much higher. We can definitely look into this some time in future but I suspect it will be a substantial amount of work to accomplish the optimization you suggest. Currently we use all the install tools provided by Certificate System. The approach you suggest will require a fair amount of custom code. Is it worth to spend time doing this work or rather integrate other CS components like key management and user cert management? I would vote for latter. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From contact at kikinovak.net Sat Oct 30 08:13:29 2010 From: contact at kikinovak.net (Niki Kovacs) Date: Sat, 30 Oct 2010 10:13:29 +0200 Subject: [Freeipa-users] General question about FreeIPA : roaming profiles in a school? Message-ID: <1288426409.10341.20.camel@babasse.presbytere.montpezat> Hi, I'm an Austrian Linux user living in South France, and I recently installed a 100% Linux computer room in a school here. Currently every machine only has one "public" user, and then every single user (teacher as well as student) has his own directory on a Samba File server. This is an intermediary solution, while I try to get a grasp on configuring roaming profiles. The server is running CentOS 5.5 (headless, e. g. without X), and the desktops are either a personal mix of CentOS and Fedora, or openSUSE 11.3. I've spent some time wading through LDAP, NFS, NIS, Samba and autofs documentation and the various mixes of these, but it all seems like a mysterious mess. Someone from the CentOS mailing list suggested I take a peek on FreeIPA. So I took a look on the website, and now I thought I'd simply ask on this list. Here's basically what I need. 1) One simple server, running CentOS 5.5. All the user accounts (teachers, students) should be managed centrally on the server. 2) All the user data are stored centrally on the server, preferably with quotas (for example max. 1 GB per user). 3) Ideally every user should be able to connect to his or her account from any client machine in the computer room. 4) Ideally, this solution should work for both CentOS 5.5 and openSUSE 11.3 client machines. 5) Ideally, users can be managed (added / removed) graphically through some dedicated tool, so I can leave this to someone who doesn't necessarily have system administration skills. 6) Ideally, the whole setup should not be a nightmare to secure. So here's my simple question : is FreeIPA the right tool for this ? Can it do all these things without me having to jump through burning loops ? I'm no lamer for RTFM, so if you simply say "yes, it is", I'll happily dive into the documentation. Cheers from the storm-swept South of France, Niki Kovacs From miljank at gmail.com Sat Oct 30 08:31:06 2010 From: miljank at gmail.com (Miljan Karadzic) Date: Sat, 30 Oct 2010 10:31:06 +0200 Subject: [Freeipa-users] General question about FreeIPA : roaming profiles in a school? In-Reply-To: <1288426409.10341.20.camel@babasse.presbytere.montpezat> References: <1288426409.10341.20.camel@babasse.presbytere.montpezat> Message-ID: <4CCBD7CA.7000608@gmail.com> Hi Niki, Apart from having to manually maintain user shared folders and quota, FreeIPA covers everything pretty well. Plus it comes with many additional nice features you might or might not need. Dig in the documentation and don't hesitate to ask questions in case of problems, people here are always helpful. :-) Regards, Miljan On 10/30/10 10:13 AM, Niki Kovacs wrote: > Hi, > > I'm an Austrian Linux user living in South France, and I recently > installed a 100% Linux computer room in a school here. Currently every > machine only has one "public" user, and then every single user (teacher > as well as student) has his own directory on a Samba File server. This > is an intermediary solution, while I try to get a grasp on configuring > roaming profiles. The server is running CentOS 5.5 (headless, e. g. > without X), and the desktops are either a personal mix of CentOS and > Fedora, or openSUSE 11.3. > > I've spent some time wading through LDAP, NFS, NIS, Samba and autofs > documentation and the various mixes of these, but it all seems like a > mysterious mess. > > Someone from the CentOS mailing list suggested I take a peek on FreeIPA. > So I took a look on the website, and now I thought I'd simply ask on > this list. > > Here's basically what I need. > > 1) One simple server, running CentOS 5.5. All the user accounts > (teachers, students) should be managed centrally on the server. > > 2) All the user data are stored centrally on the server, preferably with > quotas (for example max. 1 GB per user). > > 3) Ideally every user should be able to connect to his or her account > from any client machine in the computer room. > > 4) Ideally, this solution should work for both CentOS 5.5 and openSUSE > 11.3 client machines. > > 5) Ideally, users can be managed (added / removed) graphically through > some dedicated tool, so I can leave this to someone who doesn't > necessarily have system administration skills. > > 6) Ideally, the whole setup should not be a nightmare to secure. > > So here's my simple question : is FreeIPA the right tool for this ? Can > it do all these things without me having to jump through burning > loops ? > > I'm no lamer for RTFM, so if you simply say "yes, it is", I'll happily > dive into the documentation. > > Cheers from the storm-swept South of France, > > Niki Kovacs > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Sat Oct 30 15:27:09 2010 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 30 Oct 2010 11:27:09 -0400 Subject: [Freeipa-users] General question about FreeIPA : roaming profiles in a school? In-Reply-To: <1288426409.10341.20.camel@babasse.presbytere.montpezat> References: <1288426409.10341.20.camel@babasse.presbytere.montpezat> Message-ID: <4CCC394D.2030105@redhat.com> Niki Kovacs wrote: > Hi, > > I'm an Austrian Linux user living in South France, and I recently > installed a 100% Linux computer room in a school here. Currently every > machine only has one "public" user, and then every single user (teacher > as well as student) has his own directory on a Samba File server. This > is an intermediary solution, while I try to get a grasp on configuring > roaming profiles. The server is running CentOS 5.5 (headless, e. g. > without X), and the desktops are either a personal mix of CentOS and > Fedora, or openSUSE 11.3. > > I've spent some time wading through LDAP, NFS, NIS, Samba and autofs > documentation and the various mixes of these, but it all seems like a > mysterious mess. > > Someone from the CentOS mailing list suggested I take a peek on FreeIPA. > So I took a look on the website, and now I thought I'd simply ask on > this list. > > Here's basically what I need. > > 1) One simple server, running CentOS 5.5. All the user accounts > (teachers, students) should be managed centrally on the server. > > We do development of IPA on Fedora but you can try CentOS. FreeIPA is the domain controller so all the data is centrally managed. The version in Fedora is 1.2. It is a bit old. We are actively working on the v2 that will come pretty soon. We have released several alphas in the past. See the website. The next alpha is brewing. Here are some latests builds. They are work in progress so can be bumpy but it now has much more than you ask. The repository is located at: http://jdennis.fedorapeople.org/ipa-devel The Fedora repo config file can be downloaded here: http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo Also project trac instance for issues is here: https://fedorahosted.org/freeipa/ On the client you might want to consider using SSSD. https://fedorahosted.org/sssd/ it is now a part of many distributions. But you can start with nss_ldap/pam_ldap or pam_krb5 and move to SSSD later. > 2) All the user data are stored centrally on the server, preferably with > quotas (for example max. 1 GB per user). > > 3) Ideally every user should be able to connect to his or her account > from any client machine in the computer room. > > 4) Ideally, this solution should work for both CentOS 5.5 and openSUSE > 11.3 client machines. > > 5) Ideally, users can be managed (added / removed) graphically through > some dedicated tool, so I can leave this to someone who doesn't > necessarily have system administration skills. > > 6) Ideally, the whole setup should not be a nightmare to secure. > > So here's my simple question : is FreeIPA the right tool for this ? Can > it do all these things without me having to jump through burning > loops ? > > I hope it really is. And we will be glad to work with you if you spot any leaking loops or burning hoops :-). > I'm no lamer for RTFM, so if you simply say "yes, it is", I'll happily > dive into the documentation. > > Cheers from the storm-swept South of France, > > Niki Kovacs > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/