On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginson<rmegg...@redhat.com> wrote:
----- Original Message -----
On Tue, Apr 17, 2012 at 09:26, Rich Megginson<rmegg...@redhat.com>
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginson<rmegg...@redhat.com>
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=ffffffff-ffffffff-ffffffff-ffffffff)(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=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))'
Enter LDAP Password:
dn:
nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=ecg,dc=mit,dc=edu
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e7b746e000000040000
nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389}
4f50e685001d00060000
4f8d7874000200060000
nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389}
4f88cf450001002b000
0 4f8d78140000002b0000
nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389}
4f5047ad001d00050000
4f8d77c3000000050000
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}
4f7363d2001d00080000
4f736402000700080000
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} 00000
000
nsruvReplicaLastModified: {replica 9
ldap://fileserver3.ecg.mit.edu:389} 00000
000
nsruvReplicaLastModified: {replica 8
ldap://fileserver3.ecg.mit.edu:389} 00000
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
