Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/18/2012 07:22 AM, Dan Scott wrote: On Tue, Apr 17, 2012 at 15:32, Rich Megginson wrote: On 04/17/2012 09:59 AM, Dan Scott wrote: On Tue, Apr 17, 2012 at 10:29, Richard Megginson wrote: - Original Message - On Tue, Apr 17, 2012 at 09:26, Rich Megginson wrote: On 04/17/2012 07:26 AM, Dan Scott wrote: On Fri, Apr 13, 2012 at 17:44, Rich Megginson wrote: On 04/13/2012 03:40 PM, Dan Scott wrote: I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? The entry should exist, but the deleted servers should not be present in the nsds50ruv attribute. OK, so it's safe to delete replica entries which have ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a replica) but not for the other servers? Yes. Following the CLEANRUV procedure: http://port389.org/wiki/Howto:CLEANRUV Thanks. I think I'm getting there - removed the tombstones from the main directory and the PKI-IPA directory (only one server so far though). I still have a few strange entries though: [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b dc=ecg,dc=mit,dc=edu '(&(nsuniqueid=---)(objectclass=nstombstone))' Enter LDAP Password: dn: nsuniqueid=---,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e7b746e0004 nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f50e685001d0006 4f8d787400020006 nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f88cf450001002b000 0 4f8d7814002b nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f5047ad001d0005 4f8d77c30005 nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 4f7363d2001d0008 4f73640200070008 dc: ecg nsruvReplicaLastModified: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f8d7 806 nsruvReplicaLastModified: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f8d 77a6 nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f8d7 756 nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 0 000 Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with 2 entries for fileserver3. How do I know which one to delete? Whichever one is the one currently in use. ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config cn=replica What is the replica ID? That is the one that is currently in use. You should be able to safely delete the others. Excellent thanks. Nearly there now. I think my only remaining problems are: 1. The fileserver5.ecg.mit.edu entry (dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu) which I cannot delete due to: [LDAP: error code 66 - Not Allowed On Non-leaf] It won't let you delete the tombstones? Or it is not showing any tombstones? If this is due to "orphan" tombstone entries, the only resolution will be to db2ldif, then ldif2db. It's not showing any tombstones. Is there any documentation for "db2ldif, then ldif2db"? I guess it's the scripts in /var/lib/dirsrv/scripts-ECG-MIT-EDU/. But I'm not sure if there are any options I should be using? 2. One inconsistency in my replication agreements: ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only fileserver2. ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both fileservers 1 and 2. So, fileserver3 thinks that it's replicating fine with fileserver1, but fileserver1 is not replicating with fileserver3. Any ideas? Not sure. You can look at the replication agreements directly using ldapsearch: ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config objectclass=nsds5replicationagreement The agreements agree with the output of ipa-replica-manage list i.e. There's an entry on fileserver3 pointing to fileserver1: dn: cn=masterAgreement1-fileserver1.ecg.mit.edu-pki-ca,cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config but no equivalent entry on fileserver1. Is there an easy way to fix this? Add it using the ipa-csreplica-manage or ipa-replica-manage tool? I think I have also found yet another problem. On fileserver2, the output of: ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config objectclass=nsds5replicationagreement Shows lots of entries for missing replicas: nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 4 ldap://fileserver3
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Tue, Apr 17, 2012 at 15:32, Rich Megginson wrote: > On 04/17/2012 09:59 AM, Dan Scott wrote: >> >> On Tue, Apr 17, 2012 at 10:29, Richard Megginson >> wrote: >>> >>> - Original Message - On Tue, Apr 17, 2012 at 09:26, Rich Megginson wrote: > > On 04/17/2012 07:26 AM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson >> wrote: >>> >>> On 04/13/2012 03:40 PM, Dan Scott wrote: I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? >>> >>> >>> The entry should exist, but the deleted servers should not be >>> present in >>> the >>> nsds50ruv attribute. >> >> OK, so it's safe to delete replica entries which have >> ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a >> replica) but not for the other servers? > > Yes. Following the CLEANRUV procedure: > http://port389.org/wiki/Howto:CLEANRUV Thanks. I think I'm getting there - removed the tombstones from the main directory and the PKI-IPA directory (only one server so far though). I still have a few strange entries though: [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b dc=ecg,dc=mit,dc=edu '(&(nsuniqueid=---)(objectclass=nstombstone))' Enter LDAP Password: dn: nsuniqueid=---,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e7b746e0004 nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f50e685001d0006 4f8d787400020006 nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f88cf450001002b000 0 4f8d7814002b nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f5047ad001d0005 4f8d77c30005 nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 4f7363d2001d0008 4f73640200070008 dc: ecg nsruvReplicaLastModified: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f8d7 806 nsruvReplicaLastModified: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f8d 77a6 nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f8d7 756 nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 0 000 Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with 2 entries for fileserver3. How do I know which one to delete? >>> >>> Whichever one is the one currently in use. >>> >>> ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config >>> cn=replica >>> >>> What is the replica ID? That is the one that is currently in use. You >>> should be able to safely delete the others. >> >> Excellent thanks. >> >> Nearly there now. >> >> I think my only remaining problems are: >> >> 1. The fileserver5.ecg.mit.edu entry (dn: >> cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu) >> which I cannot delete due to: [LDAP: error code 66 - Not Allowed On >> Non-leaf] > > > It won't let you delete the tombstones? Or it is not showing any > tombstones? > If this is due to "orphan" tombstone entries, the only resolution will be to > db2ldif, then ldif2db. It's not showing any tombstones. Is there any documentation for "db2ldif, then ldif2db"? I guess it's the scripts in /var/lib/dirsrv/scripts-ECG-MIT-EDU/. But I'm not sure if there are any options I should be using? >> 2. One inconsistency in my replication agreements: >> ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only >> fileserver2. >> ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both >> fileservers 1 and 2. >> >> So, fileserver3 thinks that it's replicating fine with fileserver1, >> but fileserver1 is not replicating with fileserver3. >> >> Any ideas? > > > Not sure. You can look at the replication agreements directly using > ldapsearch: > > ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config > objectclass=nsds5replicationagreement The agreements agree with the output of ipa-replica-manage list i.e. There's an entry on fileserver3 pointing to fileserver1: dn: cn=masterAgreement1-fileserver
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/17/2012 09:59 AM, Dan Scott wrote: On Tue, Apr 17, 2012 at 10:29, Richard Megginson wrote: - Original Message - On Tue, Apr 17, 2012 at 09:26, Rich Megginson wrote: On 04/17/2012 07:26 AM, Dan Scott wrote: On Fri, Apr 13, 2012 at 17:44, Rich Megginson wrote: On 04/13/2012 03:40 PM, Dan Scott wrote: I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? The entry should exist, but the deleted servers should not be present in the nsds50ruv attribute. OK, so it's safe to delete replica entries which have ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a replica) but not for the other servers? Yes. Following the CLEANRUV procedure: http://port389.org/wiki/Howto:CLEANRUV Thanks. I think I'm getting there - removed the tombstones from the main directory and the PKI-IPA directory (only one server so far though). I still have a few strange entries though: [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b dc=ecg,dc=mit,dc=edu '(&(nsuniqueid=---)(objectclass=nstombstone))' Enter LDAP Password: dn: nsuniqueid=---,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e7b746e0004 nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f50e685001d0006 4f8d787400020006 nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f88cf450001002b000 0 4f8d7814002b nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f5047ad001d0005 4f8d77c30005 nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 4f7363d2001d0008 4f73640200070008 dc: ecg nsruvReplicaLastModified: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f8d7 806 nsruvReplicaLastModified: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f8d 77a6 nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f8d7 756 nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 0 000 Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with 2 entries for fileserver3. How do I know which one to delete? Whichever one is the one currently in use. ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config cn=replica What is the replica ID? That is the one that is currently in use. You should be able to safely delete the others. Excellent thanks. Nearly there now. I think my only remaining problems are: 1. The fileserver5.ecg.mit.edu entry (dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu) which I cannot delete due to: [LDAP: error code 66 - Not Allowed On Non-leaf] It won't let you delete the tombstones? Or it is not showing any tombstones? If this is due to "orphan" tombstone entries, the only resolution will be to db2ldif, then ldif2db. 2. One inconsistency in my replication agreements: ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only fileserver2. ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both fileservers 1 and 2. So, fileserver3 thinks that it's replicating fine with fileserver1, but fileserver1 is not replicating with fileserver3. Any ideas? Not sure. You can look at the replication agreements directly using ldapsearch: ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config objectclass=nsds5replicationagreement Thanks for all your help. It's looking good now. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Tue, Apr 17, 2012 at 10:29, Richard Megginson wrote: > - Original Message - >> On Tue, Apr 17, 2012 at 09:26, Rich Megginson >> wrote: >> > On 04/17/2012 07:26 AM, Dan Scott wrote: >> >> >> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson >> >> wrote: >> >>> >> >>> On 04/13/2012 03:40 PM, Dan Scott wrote: >> >> I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] >> does >> not contain element" errors in the logs for each of fileservers >> 1, 2 >> and 3. The ldapsearch for >> >> >> '(&(nsuniqueid=---)(objectclass=nstombstone))' >> is still showing entries though. Is that OK? >> >>> >> >>> >> >>> The entry should exist, but the deleted servers should not be >> >>> present in >> >>> the >> >>> nsds50ruv attribute. >> >> >> >> OK, so it's safe to delete replica entries which have >> >> ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a >> >> replica) but not for the other servers? >> > >> > Yes. Following the CLEANRUV procedure: >> > http://port389.org/wiki/Howto:CLEANRUV >> >> Thanks. I think I'm getting there - removed the tombstones from the >> main directory and the PKI-IPA directory (only one server so far >> though). I still have a few strange entries though: >> >> [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W >> -b >> dc=ecg,dc=mit,dc=edu >> '(&(nsuniqueid=---)(objectclass=nstombstone))' >> Enter LDAP Password: >> dn: >> nsuniqueid=---,dc=ecg,dc=mit,dc=edu >> objectClass: top >> objectClass: nsTombstone >> objectClass: extensibleobject >> nsds50ruv: {replicageneration} 4e7b746e0004 >> nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} >> 4f50e685001d0006 >> 4f8d787400020006 >> nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} >> 4f88cf450001002b000 >> 0 4f8d7814002b >> nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} >> 4f5047ad001d0005 >> 4f8d77c30005 >> nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} >> nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} >> nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} >> 4f7363d2001d0008 >> 4f73640200070008 >> dc: ecg >> nsruvReplicaLastModified: {replica 6 >> ldap://fileserver1.ecg.mit.edu:389} 4f8d7 >> 806 >> nsruvReplicaLastModified: {replica 43 >> ldap://fileserver2.ecg.mit.edu:389} 4f8d >> 77a6 >> nsruvReplicaLastModified: {replica 5 >> ldap://fileserver3.ecg.mit.edu:389} 4f8d7 >> 756 >> nsruvReplicaLastModified: {replica 4 >> ldap://fileserver3.ecg.mit.edu:389} 0 >> 000 >> nsruvReplicaLastModified: {replica 9 >> ldap://fileserver3.ecg.mit.edu:389} 0 >> 000 >> nsruvReplicaLastModified: {replica 8 >> ldap://fileserver3.ecg.mit.edu:389} 0 >> 000 >> >> Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with >> 2 >> entries for fileserver3. How do I know which one to delete? > > Whichever one is the one currently in use. > > ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config > cn=replica > > What is the replica ID? That is the one that is currently in use. You > should be able to safely delete the others. Excellent thanks. Nearly there now. I think my only remaining problems are: 1. The fileserver5.ecg.mit.edu entry (dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu) which I cannot delete due to: [LDAP: error code 66 - Not Allowed On Non-leaf] 2. One inconsistency in my replication agreements: ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only fileserver2. ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both fileservers 1 and 2. So, fileserver3 thinks that it's replicating fine with fileserver1, but fileserver1 is not replicating with fileserver3. Any ideas? Thanks for all your help. It's looking good now. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
- Original Message - > On Tue, Apr 17, 2012 at 09:26, Rich Megginson > wrote: > > On 04/17/2012 07:26 AM, Dan Scott wrote: > >> > >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson > >> wrote: > >>> > >>> On 04/13/2012 03:40 PM, Dan Scott wrote: > > I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] > does > not contain element" errors in the logs for each of fileservers > 1, 2 > and 3. The ldapsearch for > > > '(&(nsuniqueid=---)(objectclass=nstombstone))' > is still showing entries though. Is that OK? > >>> > >>> > >>> The entry should exist, but the deleted servers should not be > >>> present in > >>> the > >>> nsds50ruv attribute. > >> > >> OK, so it's safe to delete replica entries which have > >> ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a > >> replica) but not for the other servers? > > > > Yes. Following the CLEANRUV procedure: > > http://port389.org/wiki/Howto:CLEANRUV > > Thanks. I think I'm getting there - removed the tombstones from the > main directory and the PKI-IPA directory (only one server so far > though). I still have a few strange entries though: > > [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W > -b > dc=ecg,dc=mit,dc=edu > '(&(nsuniqueid=---)(objectclass=nstombstone))' > Enter LDAP Password: > dn: > nsuniqueid=---,dc=ecg,dc=mit,dc=edu > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 4e7b746e0004 > nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} > 4f50e685001d0006 > 4f8d787400020006 > nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} > 4f88cf450001002b000 > 0 4f8d7814002b > nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} > 4f5047ad001d0005 > 4f8d77c30005 > nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} > nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} > nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} > 4f7363d2001d0008 > 4f73640200070008 > dc: ecg > nsruvReplicaLastModified: {replica 6 > ldap://fileserver1.ecg.mit.edu:389} 4f8d7 > 806 > nsruvReplicaLastModified: {replica 43 > ldap://fileserver2.ecg.mit.edu:389} 4f8d > 77a6 > nsruvReplicaLastModified: {replica 5 > ldap://fileserver3.ecg.mit.edu:389} 4f8d7 > 756 > nsruvReplicaLastModified: {replica 4 > ldap://fileserver3.ecg.mit.edu:389} 0 > 000 > nsruvReplicaLastModified: {replica 9 > ldap://fileserver3.ecg.mit.edu:389} 0 > 000 > nsruvReplicaLastModified: {replica 8 > ldap://fileserver3.ecg.mit.edu:389} 0 > 000 > > Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with > 2 > entries for fileserver3. How do I know which one to delete? Whichever one is the one currently in use. ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config cn=replica What is the replica ID? That is the one that is currently in use. You should be able to safely delete the others. > > On my PKI-IPA server, the CLEANRUV task doesn't seem to work. It > keeps > re-adding entries after I remove them. I have 3 entries for my > non-existent fileserver4 - They disappear when I remove them, but > they > come back after a few minutes. Right, because they are being replicated from another master. You will need to run the CLEANRUV on all masters at the same time. > > Thanks, > > Dan > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Tue, Apr 17, 2012 at 09:26, Rich Megginson wrote: > On 04/17/2012 07:26 AM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson wrote: >>> >>> On 04/13/2012 03:40 PM, Dan Scott wrote: I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? >>> >>> >>> The entry should exist, but the deleted servers should not be present in >>> the >>> nsds50ruv attribute. >> >> OK, so it's safe to delete replica entries which have >> ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a >> replica) but not for the other servers? > > Yes. Following the CLEANRUV procedure: > http://port389.org/wiki/Howto:CLEANRUV Thanks. I think I'm getting there - removed the tombstones from the main directory and the PKI-IPA directory (only one server so far though). I still have a few strange entries though: [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b dc=ecg,dc=mit,dc=edu '(&(nsuniqueid=---)(objectclass=nstombstone))' Enter LDAP Password: dn: nsuniqueid=---,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4e7b746e0004 nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f50e685001d0006 4f8d787400020006 nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f88cf450001002b000 0 4f8d7814002b nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f5047ad001d0005 4f8d77c30005 nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 4f7363d2001d0008 4f73640200070008 dc: ecg nsruvReplicaLastModified: {replica 6 ldap://fileserver1.ecg.mit.edu:389} 4f8d7 806 nsruvReplicaLastModified: {replica 43 ldap://fileserver2.ecg.mit.edu:389} 4f8d 77a6 nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 4f8d7 756 nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 0 000 nsruvReplicaLastModified: {replica 8 ldap://fileserver3.ecg.mit.edu:389} 0 000 Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with 2 entries for fileserver3. How do I know which one to delete? On my PKI-IPA server, the CLEANRUV task doesn't seem to work. It keeps re-adding entries after I remove them. I have 3 entries for my non-existent fileserver4 - They disappear when I remove them, but they come back after a few minutes. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/17/2012 07:26 AM, Dan Scott wrote: On Fri, Apr 13, 2012 at 17:44, Rich Megginson wrote: On 04/13/2012 03:40 PM, Dan Scott wrote: I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? The entry should exist, but the deleted servers should not be present in the nsds50ruv attribute. OK, so it's safe to delete replica entries which have ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a replica) but not for the other servers? Yes. Following the CLEANRUV procedure: http://port389.org/wiki/Howto:CLEANRUV fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) This is a real connection error - could be cert or hostname lookup related. How do I find out if it's cert or hostname lookup? Which hostname? Fileserver3 runs DNS, and it seems to be working fine. Try ldapsearch - on server3 LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" If that works, check to make sure the replication agreement has the correct server2.fqdn If that doesn't work, use ldapsearch -d 1 -x . to get further debugging information. The replication agreements (according to ipa-replica-manage) all have the correct host names - I'm not sure what ldapsearch command to run to check the replication agreements. ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. Ok. And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is working? It returns a load of supportedExtension: and supportedControl: entries - I guess that means 'working'? :) Yes. Then I'm not sure why TLS/SSL connections with replication are not working. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 17:44, Rich Megginson wrote: > On 04/13/2012 03:40 PM, Dan Scott wrote: >> I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does >> not contain element" errors in the logs for each of fileservers 1, 2 >> and 3. The ldapsearch for >> >> '(&(nsuniqueid=---)(objectclass=nstombstone))' >> is still showing entries though. Is that OK? > > > The entry should exist, but the deleted servers should not be present in the > nsds50ruv attribute. OK, so it's safe to delete replica entries which have ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a replica) but not for the other servers? fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) >>> >>> >>> This is a real connection error - could be cert or hostname lookup >>> related. >> >> How do I find out if it's cert or hostname lookup? Which hostname? >> Fileserver3 runs DNS, and it seems to be working fine. > > > Try ldapsearch - on server3 > > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H > ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" > > If that works, check to make sure the replication agreement has the > correct > server2.fqdn > > If that doesn't work, use ldapsearch -d 1 -x . to get further > debugging > information. The replication agreements (according to ipa-replica-manage) all have the correct host names - I'm not sure what ldapsearch command to run to check the replication agreements. >>> >>> >>> ipa-replica-manage --list? or something like that? >> >> That's what I was using - they are all correct. > > > Ok. And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is > working? It returns a load of supportedExtension: and supportedControl: entries - I guess that means 'working'? :) Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 03:40 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 16:41, Rich Megginson wrote: On 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginsonwrote: It's not a problem until it's a problem :-) I would go ahead and run CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN 4f031e76001d000b not found, we aren't as up to date, or we purged Is it safe to run: [root@fileserver3 ~]# ipa-replica-manage re-initialize --from fileserver1.ecg.mit.edu I want to make sure I get it the correct way round! Are you sure that fileserver1 has the correct data? Maybe? :) I've snapshotted both VMs and re-initialized from fileserver1 - looking good so far. I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? The entry should exist, but the deleted servers should not be present in the nsds50ruv attribute. Also, the PKI-CA error logs are showing RUV errors, should I clean those too? I guess that I need to modify the commands (-b o=ipaca -p 7389 -h localhost). Yes. fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) This is a real connection error - could be cert or hostname lookup related. How do I find out if it's cert or hostname lookup? Which hostname? Fileserver3 runs DNS, and it seems to be working fine. Try ldapsearch - on server3 LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" If that works, check to make sure the replication agreement has the correct server2.fqdn If that doesn't work, use ldapsearch -d 1 -x . to get further debugging information. The replication agreements (according to ipa-replica-manage) all have the correct host names - I'm not sure what ldapsearch command to run to check the replication agreements. ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. Ok. And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is working? The /var/log/dirsrv/slapd-ECG-MIT-EDU/errors is now full of: [13/Apr/2012:14:59:19 -0400] NSMMReplicationPlugin - conn=1 op=571 csn=4f70a9e500010006: Can't created glue entry cn=fileserver4.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu uniqueid=6949d104-775b11e1-abce82a1-a45dd3c3, error 68 Should I delete the LDAP entry which is trying to replicate fileserver2 with fileserver4? Yes. And it may be due to the fact that the entry it is trying to delete has those tombstone children that have to be deleted too. OK, I'll see how this goes, once the tombstones are gone. The tombstones for ECG-MIT-EDU are gone now, still receiving this message in the logs. I think that's enough for this week - I'll look into it more next week. Thanks for your help, have a good weekend. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 16:41, Rich Megginson wrote: > On 04/13/2012 02:30 PM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: >>> It's not a problem until it's a problem :-) I would go ahead and run >>> CLEANRUV. >> >> I cleaned up a load of these entries, but now I think I've broken the >> replication between fileserver1 and 3: >> >> fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN >> 4f503996002b not found, we aren't as up to date, or we purged >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required >> to update replica has been purged. The replica must be reinitialized. >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental >> update failed and requires administrator action >> >> fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN >> 4f031e76001d000b not found, we aren't as up to date, or we purged >> >> Is it safe to run: >> [root@fileserver3 ~]# ipa-replica-manage re-initialize --from >> fileserver1.ecg.mit.edu >> >> I want to make sure I get it the correct way round! > > > Are you sure that fileserver1 has the correct data? Maybe? :) I've snapshotted both VMs and re-initialized from fileserver1 - looking good so far. I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? Also, the PKI-CA error logs are showing RUV errors, should I clean those too? I guess that I need to modify the commands (-b o=ipaca -p 7389 -h localhost). >> fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: >> [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send >> startTLS request: error -1 (Can't contact LDAP server) errno 107 >> (Transport endpoint is not connected) > > > This is a real connection error - could be cert or hostname lookup > related. How do I find out if it's cert or hostname lookup? Which hostname? Fileserver3 runs DNS, and it seems to be working fine. >>> >>> >>> Try ldapsearch - on server3 >>> >>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H >>> ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" >>> >>> If that works, check to make sure the replication agreement has the >>> correct >>> server2.fqdn >>> >>> If that doesn't work, use ldapsearch -d 1 -x . to get further >>> debugging >>> information. >> >> The replication agreements (according to ipa-replica-manage) all have >> the correct host names - I'm not sure what ldapsearch command to run >> to check the replication agreements. > > > ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. The /var/log/dirsrv/slapd-ECG-MIT-EDU/errors is now full of: [13/Apr/2012:14:59:19 -0400] NSMMReplicationPlugin - conn=1 op=571 csn=4f70a9e500010006: Can't created glue entry cn=fileserver4.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu uniqueid=6949d104-775b11e1-abce82a1-a45dd3c3, error 68 Should I delete the LDAP entry which is trying to replicate fileserver2 with fileserver4? >>> >>> >>> Yes. And it may be due to the fact that the entry it is trying to delete >>> has those tombstone children that have to be deleted too. >> >> OK, I'll see how this goes, once the tombstones are gone. The tombstones for ECG-MIT-EDU are gone now, still receiving this message in the logs. I think that's enough for this week - I'll look into it more next week. Thanks for your help, have a good weekend. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: On 04/13/2012 01:03 PM, Dan Scott wrote: If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [snip] Is it safe to delete them? Yes. I deleted them, but it's still complaining about a non-leaf: [root@fileserver1 ~]# ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# Wow - never seen this one before I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 This error usually means a replica was deleted and the RUV needs to be cleaned. see http://port389.org/wiki/Howto:CLEANRUV and https://fedorahosted.org/freeipa/ticket/2303 and https://fedorahosted.org/389/ticket/337 OK, I've seen this before - is it important to remove them? I've had to add and remove replicas so much that I don't really want to do it unless it's necessary. I'm happy to live with them if it's not a problem. It's not a problem until it's a problem :-) I would go ahead and run CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN 4f031e76001d000b not found, we aren't as up to date, or we purged Is it safe to run: [root@fileserver3 ~]# ip
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: > On 04/13/2012 01:03 PM, Dan Scott wrote: If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. >>> >>> You are correct. Try this: >>> >>> ldapsearch -D 'cn=directory manager' -W -v -b >>> >>> 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' >>> '(|(objectclass=nstombstone)(objectclass=*))' >> >> Ahh, so there are some 'child' entries: >> [snip] >> Is it safe to delete them? > > Yes. I deleted them, but it's still complaining about a non-leaf: [root@fileserver1 ~]# ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# >> I also see >> inconsistent replication states on the servers. i.e. server1 shows >> that it's replicating with server2 but server2 does not show that it's >> replicating with server1. > > > Do you have errors in the server2 log showing that it is attempting to > replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 >>> >>> >>> This error usually means a replica was deleted and the RUV needs to be >>> cleaned. >>> see http://port389.org/wiki/Howto:CLEANRUV >>> and >>> https://fedorahosted.org/freeipa/ticket/2303 >>> and >>> https://fedorahosted.org/389/ticket/337 >> >> OK, I've seen this before - is it important to remove them? I've had >> to add and remove replicas so much that I don't really want to do it >> unless it's necessary. I'm happy to live with them if it's not a >> problem. > > > It's not a problem until it's a problem :-) I would go ahead and run > CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 01:03 PM, Dan Scott wrote: Thanks for the quick response. Simo: Thanks - I'd prefer to clean it up properly rather than start from scratch. I haven't changed the LDAP schema at all. All I've done is the use the IPA tools for user admin and add/remove replicas. I just felt like I've been emailing this list once a week or so for the past few months - I was beginning to think that it was beyond repair! :) On Fri, Apr 13, 2012 at 14:38, Rich Megginson wrote: On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginsonwrote: On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize() Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # aaa2c704-63cf11e1-ac8dadbd-35182efb, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=aaa2c704-63cf11e1-ac8dadbd-35182efb,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 17708e04-63dd11e1-9b079095-05c635b0, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=17708e04-63dd11e1-9b079095-05c635b0,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 5ceb8604-63f211e1-bc108552-1fbf39e2, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=5ceb8604-63f211e1-bc108552-1fbf39e2,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # c480f184-83f011e1-90d1df13-bba55eff, HTTP, fileserver5.ecg.mit.edu, masters , ipa, etc, ecg.mit.edu dn: nsuniqueid=c480f184-83f011e1-90d1df13-bba55eff,cn=HTTP,cn=fileserver5.ecg. mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: nsContainer objectClass: ipaConfigObject objectClass: top objectClass: nsTombstone ipaConfigString: enabledService ipaConfigString: startOrder 40 cn: HTTP nsParentUniqueId: 1eba8a03-642311e1-9b95afe9-fc1b53ef # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 Is it safe to delete them? Yes. I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ip
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
Thanks for the quick response. Simo: Thanks - I'd prefer to clean it up properly rather than start from scratch. I haven't changed the LDAP schema at all. All I've done is the use the IPA tools for user admin and add/remove replicas. I just felt like I've been emailing this list once a week or so for the past few months - I was beginning to think that it was beyond repair! :) On Fri, Apr 13, 2012 at 14:38, Rich Megginson wrote: > On 04/13/2012 12:22 PM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: >>> >>> On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. >>> >>> >>> What version of 389-ds-base is this? Do you get any errors? It just >>> silently fails to delete this particular entry? >> >> [root@fileserver1 ~]# rpm -qa|grep 389 >> 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 >> 389-ds-base-1.2.10.4-2.fc16.x86_64 >> [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory >> manager' -W >> Enter LDAP Password: >> deleting entry >> "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" >> ldap_delete: Operation not allowed on non-leaf (66) >> >> [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b >> 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' >> '(objectclass=*)' >> ldap_initialize( ) >> Enter LDAP Password: >> filter: (objectclass=*) >> requesting: All userApplication attributes >> # extended LDIF >> # >> # LDAPv3 >> # >> base >> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu >> dn: >> cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu >> cn: fileserver5.ecg.mit.edu >> objectClass: top >> objectClass: nsContainer >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> [root@fileserver1 ~]# >> >> If I'm interpreting this correctly, it can't be deleted because it's >> not a leaf node, but it doesn't have any sub-entries that I can delete >> first. > > > You are correct. Try this: > > ldapsearch -D 'cn=directory manager' -W -v -b > 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' > '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # aaa2c704-63cf11e1-ac8dadbd-35182efb, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=aaa2c704-63cf11e1-ac8dadbd-35182efb,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 17708e04-63dd11e1-9b079095-05c635b0, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=17708e04-63dd11e1-9b079095-05c635b0,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 5ceb8604-63f211e1-bc108552-1fbf39e2, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=5ceb8604-63f211e1-bc108552-1fbf39e2,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # c480f184-83f011e1-90d1df13-bba55eff, HTTP, fileserver5.ecg.mit.edu, masters , ipa, etc, ecg.mit.edu dn: nsuniqueid=c480f184-83f011e1-90d1df13-bba55eff,cn=HTTP,cn=fileserver5.ecg. mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: nsContainer objectClass: ipaConfigObject objectClass: top objectClass: nsTombstone ipaConfigString: enabledService ipaConfigString: startOrder 40 cn: HTTP nsParentUniqueId: 1eba8a03-642311e1-9b95afe9-fc1b53ef # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 Is it safe to delete them? I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize( ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 This error usually means a replica was deleted and the RUV needs to be cleaned. see http://port389.org/wiki/Howto:CLEANRUV and https://fedorahosted.org/freeipa/ticket/2303 and https://fedorahosted.org/389/ticket/337 fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) This is a real connection error - could be cert or hostname lookup related. [13/Apr/2012:13:57:39 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver2's non-PKI replication agreements to both fileserver1 and 3 are in place, but both say: Incremental update has failed and requires administrator actionSystem error. When I try to re-initialize: [root@fileserver2 ~]# ipa-replica-manage re-initialize --from fileserver3.ecg.mit.edu Directory Manager password: [fileserver3.ecg.mit.edu] reports: Replica Busy! Status: [1 Replication error acquiring replica: replica busy] This is a transient condition. this command has been running for 1/2hr and produced no mo
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, 2012-04-13 at 13:39 -0400, Dan Scott wrote: > Hi, > > I've been using FreeIPA for a couple of years (Upgraded/Migrated from > FreeIPA 1). The servers are in various states (Some upgraded from > Fedora 10/11 through each release, some fresh installs of Fedora > 15/16). I've also had to add/remove replicas many times - and run into > problems installing which required some manual intervention. > > I'm convinced that my LDAP directories contain lots of cruft which has > built up and is causing problems on my system. There may even be some > corruption since there's an entry which I'm unable to remove - this > entry does not get replicated to the other servers. I also see > inconsistent replication states on the servers. i.e. server1 shows > that it's replicating with server2 but server2 does not show that it's > replicating with server1. > > Is there some way that I can refresh/clean my LDAP directories and > ensure that everything's running correctly. Well it really depends on what you need to achieve. Of course you have the big hammer of setting up a brand new realm and then migrating over users/groups, but that would require to start from scratch with hbac and related rules and re-enrollment of users and hosts. In general if you haven't willfully changed stuff manually over ldap you should be in good shape. It should be sufficient to find out and fix why DS is not allowing you to delete that entry you want to delete and then you should be able to clean up stuff trhough the CLI or the WebUI tools. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: > On 04/13/2012 11:39 AM, Dan Scott wrote: >> I'm convinced that my LDAP directories contain lots of cruft which has >> built up and is causing problems on my system. There may even be some >> corruption since there's an entry which I'm unable to remove - this >> entry does not get replicated to the other servers. > > > What version of 389-ds-base is this? Do you get any errors? It just > silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize( ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. >> I also see >> inconsistent replication states on the servers. i.e. server1 shows >> that it's replicating with server2 but server2 does not show that it's >> replicating with server1. > > > Do you have errors in the server2 log showing that it is attempting to > replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [13/Apr/2012:13:57:39 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver2's non-PKI replication agreements to both fileserver1 and 3 are in place, but both say: Incremental update has failed and requires administrator actionSystem error. When I try to re-initialize: [root@fileserver2 ~]# ipa-replica-manage re-initialize --from fileserver3.ecg.mit.edu Directory Manager password: [fileserver3.ecg.mit.edu] reports: Replica Busy! Status: [1 Replication error acquiring replica: replica busy] this command has been running for 1/2hr and produced no more output (fileserver2 is the remaining server running Fedora 15, the others are Fedora 16 with latest updates). >> Is there some way that I can refresh/clean my LDAP directories and >> ensure that everything's running correctly. > > We first need to find out what's going on and why you are seeing these > failures before we can recommend a particular course of action. There is > currently no "find all of my problems and fix them" command. :) Wish there was. It's just that I've been having lots of problems recently and I was thinking that there is something f
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 11:39 AM, Dan Scott wrote: Hi, I've been using FreeIPA for a couple of years (Upgraded/Migrated from FreeIPA 1). The servers are in various states (Some upgraded from Fedora 10/11 through each release, some fresh installs of Fedora 15/16). I've also had to add/remove replicas many times - and run into problems installing which required some manual intervention. I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? Is there some way that I can refresh/clean my LDAP directories and ensure that everything's running correctly. We first need to find out what's going on and why you are seeing these failures before we can recommend a particular course of action. There is currently no "find all of my problems and fix them" command. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users