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 rmegg...@redhat.com wrote:
On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginsonrmegg...@redhat.com
wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@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=---)(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?
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
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 Megginsonrmegg...@redhat.com wrote:
On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginsonrmegg...@redhat.com
wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@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=---)(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
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 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=---)(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/17/2012 07:26 AM, Dan Scott wrote: On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@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=---)(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 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 Megginsonrmegg...@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=---)(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?
- 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 Megginsonrmegg...@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=---)(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 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 Megginsonrmegg...@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=---)(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?
On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginsonrmegg...@redhat.com wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@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=---)(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
[Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
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. 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 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
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 rmegg...@redhat.com 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( DEFAULT ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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
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 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginsonrmegg...@redhat.com 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(DEFAULT ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # basecn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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
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 rmegg...@redhat.com wrote: On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginsonrmegg...@redhat.com 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(DEFAULT ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # basecn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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 cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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
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 Megginsonrmegg...@redhat.com wrote: On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginsonrmegg...@redhat.comwrote: 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(DEFAULT) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # basecn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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 # basecn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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
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 rmegg...@redhat.com 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 cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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 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
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 Megginsonrmegg...@redhat.com 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 # basecn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu 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,
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 rmegg...@redhat.com wrote: On 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginsonrmegg...@redhat.com 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 03:40 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 16:41, Rich Megginsonrmegg...@redhat.com wrote: On 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginsonrmegg...@redhat.comwrote: 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
