On 04/18/2012 07:22 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 15:32, Rich Megginson<rmegg...@redhat.com> wrote:
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.
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} 00000
000
nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 00000
000
nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 00000
000
Do you see deleted replicas in the nsds50ruv attribute, or only the
nsruvReplicaLastModified attribute?
But these entries do not show up in the output of:
ldapsearch -xLLL -D "cn=directory manager" -W -s sub -b cn=config
objectclass=nsds5replica
Do I need to run the cleanruv task for the above replica IDs?
Only if you see them in the nsds50ruv attribute
Thanks,
Dan
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
