[Freeipa-users] multiple domains/realms?
HiI have multiple domains her but I want to use one user/group etc. database. How can I do it? Options:1. Different realm for each domain, but how to share the user/group etc infos betwen different ipa servers?2. One realm for al domains. Possible? (it is possible to change the realm after install/config?)3. ?Does someone have experience with multiple domains and ipa and can give some tips?TiAMfGChristoph Kaminskiwww.biotronik.comBIOTRONIK SE Co. KGWoermannkehre 1, 12359 Berlin, GermanySitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501Vertreten durch ihre Komplementärin:BIOTRONIK MT SESitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 BGeschäftsführende Direktoren: Christoph Böhmer, Dr. Werner Braun, Dr. Lothar Krings, Dr. Torsten WolfBIOTRONIK - A global manufacturer of advanced Cardiac Rhythm Management systems and Vascular Intervention devices. Quality, innovation, and reliability define BIOTRONIK and our growing success. We are innovators of technologies like the first wireless remote monitoring system - Home Monitoring®, Closed Loop Stimulation and coveted lead solutions as well as state-of-the-art stents, balloons and guide wires for coronary and peripheral indications. We highly invest in the development of drug eluting devices and are leading the industry with our drug eluting absorbable metal scaffold program.This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what looks
to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network /etc/sysconfig/network.orig
/var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem exists
there.
I was surprised to see that most network services were working when the file
was empty. It turns out that many network services start properly with an
empty /etc/sysconfig/network file, but some do not. It appears to be down to
the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ] exit 0
vs.
[ ${NETWORKING} != yes ] exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd and
friends to run correctly?
Thanks,
Kelvin=
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what looks
to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network /etc/sysconfig/network.orig
/var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem exists
there.
I was surprised to see that most network services were working when the file
was empty. It turns out that many network services start properly with an
empty /etc/sysconfig/network file, but some do not. It appears to be down to
the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ] exit 0
vs.
[ ${NETWORKING} != yes ] exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd and
friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is
ensure that the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what
looks to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network
/etc/sysconfig/network.orig /var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem
exists there.
I was surprised to see that most network services were working when the file
was empty. It turns out that many network services start properly with an
empty /etc/sysconfig/network file, but some do not. It appears to be down
to the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ] exit 0
vs.
[ ${NETWORKING} != yes ] exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd
and friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is ensure
that the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
ipa-client-2.1.3-1.el5
Thanks,
Kelvin=
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
Kelvin Edmison wrote:
On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what looks
to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network /etc/sysconfig/network.orig
/var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem exists
there.
I was surprised to see that most network services were working when the file
was empty. It turns out that many network services start properly with an
empty /etc/sysconfig/network file, but some do not. It appears to be down to
the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ] exit 0
vs.
[ ${NETWORKING} != yes ] exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd and
friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is ensure that
the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
ipa-client-2.1.3-1.el5
Hmm, strange. I don't think this is specific to el5, you were just the
lucky contestant to find this bug. Can you provide the contents of the
original network file? It is probable that our replacement function
isn't doing the right thing.
thanks
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
On 2012-04-13, at 1:18 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what
looks to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network
/etc/sysconfig/network.orig /var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem
exists there.
I was surprised to see that most network services were working when the
file was empty. It turns out that many network services start properly
with an empty /etc/sysconfig/network file, but some do not. It appears to
be down to the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ] exit 0
vs.
[ ${NETWORKING} != yes ] exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd
and friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is ensure
that the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
ipa-client-2.1.3-1.el5
Hmm, strange. I don't think this is specific to el5, you were just the lucky
contestant to find this bug. Can you provide the contents of the original
network file? It is probable that our replacement function isn't doing the
right thing.
Gladly.
[root@kelvin-c5 ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=kelvin-c5
[root@kelvin-c5 ~]#
The hostname is not a FQDN because we are growing from an environment where the
domainname is assigned via DHCP.
Thanks,
Kelvin=
___
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
[Freeipa-users] routing requests to local servers
Has anyone worked any magic to keep DNS, kerberos and LDAP request routed to local servers in an IPA setup where topology is separated by WAN links? I have looked at things like doing sorts in the DNS client configuration, BIND views, etc. but I would like to know if anyone else has tried to tackle this issue. Thanks, Brian --- Brian Cook ___ 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 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] routing requests to local servers
Brian Cook wrote: Has anyone worked any magic to keep DNS, kerberos and LDAP request routed to local servers in an IPA setup where topology is separated by WAN links? I have looked at things like doing sorts in the DNS client configuration, BIND views, etc. but I would like to know if anyone else has tried to tackle this issue. Which clients? For some things (logins, etc) you can reverse the order of the servers in /etc/sssd/sssd.conf so a fixed server comes before the _srv_ entry in ipa_server. This way you can point at a desired server but still be able to fall back to DNS if it is down. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] routing requests to local servers
Ideally I would rely on a -group- of servers, and then rely on DNS if it is down. I don't want to hammer one server. We're talking about 500-1000 servers running virtual machines, so potentially a lot of traffic. Got any suggestions for that? --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Apr 13, 2012, at 12:30 PM, Rob Crittenden wrote: Brian Cook wrote: Has anyone worked any magic to keep DNS, kerberos and LDAP request routed to local servers in an IPA setup where topology is separated by WAN links? I have looked at things like doing sorts in the DNS client configuration, BIND views, etc. but I would like to know if anyone else has tried to tackle this issue. Which clients? For some things (logins, etc) you can reverse the order of the servers in /etc/sssd/sssd.conf so a fixed server comes before the _srv_ entry in ipa_server. This way you can point at a desired server but still be able to fall back to DNS if it is down. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
Kelvin Edmison wrote:
On 2012-04-13, at 1:18 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what looks
to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was not
starting. I traced that back to an empty /etc/sysconfig/network file, and
ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network /etc/sysconfig/network.orig
/var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem exists
there.
I was surprised to see that most network services were working when the file
was empty. It turns out that many network services start properly with an
empty /etc/sysconfig/network file, but some do not. It appears to be down to
the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ]exit 0
vs.
[ ${NETWORKING} != yes ]exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get rpcidmapd and
friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is ensure that
the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
ipa-client-2.1.3-1.el5
Hmm, strange. I don't think this is specific to el5, you were just the lucky
contestant to find this bug. Can you provide the contents of the original
network file? It is probable that our replacement function isn't doing the
right thing.
Gladly.
[root@kelvin-c5 ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=kelvin-c5
[root@kelvin-c5 ~]#
The hostname is not a FQDN because we are growing from an environment where the
domainname is assigned via DHCP.
Ok, I'll open a ticket on this. It may be that we assume that the
hostname is always found.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] routing requests to local servers
On Fri, Apr 13, 2012 at 01:04:55PM -0700, Brian Cook wrote: Ideally I would rely on a -group- of servers, and then rely on DNS if it is down. I don't want to hammer one server. We're talking about 500-1000 servers running virtual machines, so potentially a lot of traffic. Got any suggestions for that? Hello Brian, I'm not sure I understand what you are trying to achieve. Are you trying to spread the client load among replicas? If so, then I think the SRV records in DNS are really the best answer. You can organize the servers in tiers by using the priority field and then spread the load in a tier by using the weight field. ___ 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 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] ipa-client-install on CentOS 5 creating zero-length /etc/sysconfig/network file
On 2012-04-13, at 4:25 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
On 2012-04-13, at 1:18 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
Kelvin Edmison wrote:
Hi,
When troubleshooting what I thought was an NFS4 issue, I have found what
looks to be a bug in ipa-client-install.
On a CentOS 5.8 machine, I ran
ipa-client-install --no-ntp --force --hostname=kelvin-c5.dnsdomainname
and successfully bound to the domain.
I am now trying to get nfs4 up and running, and found that idmapd was
not starting. I traced that back to an empty /etc/sysconfig/network
file, and ipa-client-install looks to be the cause.
[root@kelvin-c5 ~]# ls -al /etc/sysconfig/network
/etc/sysconfig/network.orig /var/lib/ipa-client/sysrestore/*-network
-rw--- 1 root root 0 Apr 13 11:58 /etc/sysconfig/network
-rw-r--r-- 1 root root 54 Aug 12 2011 /etc/sysconfig/network.orig
-rw-r--r-- 1 root root 54 Aug 12 2011
/var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
I looked back on another CentOS 5 machine we have, and the same problem
exists there.
I was surprised to see that most network services were working when the
file was empty. It turns out that many network services start properly
with an empty /etc/sysconfig/network file, but some do not. It appears
to be down to the structure of the test in the init scripts; e.g.
[ ${NETWORKING} = no ]exit 0
vs.
[ ${NETWORKING} != yes ]exit 6
So, is this a bug in ipa-client-install?
Can I just copy my network.orig back into place in order to get
rpcidmapd and friends to run correctly?
Yes, it should be safe to copy that file back. What we try to do is
ensure that the hostmae provided to ipa-client-install is reflected in
/etc/sysconfig/networking.
What rpm version of ipa-client-install are you using?
ipa-client-2.1.3-1.el5
Hmm, strange. I don't think this is specific to el5, you were just the
lucky contestant to find this bug. Can you provide the contents of the
original network file? It is probable that our replacement function isn't
doing the right thing.
Gladly.
[root@kelvin-c5 ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=kelvin-c5
[root@kelvin-c5 ~]#
The hostname is not a FQDN because we are growing from an environment where
the domainname is assigned via DHCP.
Ok, I'll open a ticket on this. It may be that we assume that the hostname is
always found.
Some info that may help reproducing the issue:
On that host, I found that dnsdomainname was returning nothing, which is
unusual in our environment.
It turned out that was because the bare hostname (kelvin-c5) was in the
/etc/hosts for 127.0.0.1. This was different than other machines we have, and
deleting the kelvin-c5 from the 127.0.0.1 entry actually made dnsdomainname
work again.
Regards,
Kelvin
___
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 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
