Re: [Freeipa-users] routing requests to local servers - DNS SRV + view?
Yes, this is exactly what I am trying to accomplish. I've already been looking in to the BIND views clause and would like to hear if anyone has any feedback as to how well this works in the real world. In this case the implementation of IPA is using an external standard BIND implementation loading from text files. However, views would be very useful for IPA to be able to do internally, so figuring out how to get this option in to BIND using 389ds backend would be a useful step. Thanks, Brian --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Apr 13, 2012, at 2:41 PM, Petr Spacek wrote: > On 04/13/2012 10:28 PM, Jakub Hrozek wrote: >> 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. > > Greetings, > > if I understand correctly, you need to set different priority for SRV records > and this new priority has to be dependent on client's IP address. > > AFAIK only way how to accomplish this is BIND "view" clause. You have to: > - create copy of original zone for each location and modify SRV record > priorities > - then you have to set "views" and create mapping between IP address <-> new > zone > > > This way requires multiple copies of original zone, each with little > differences. > In case of classical zone files is not a big problem: You can keep SRV > records separated in small files and "$INCLUDE" normal records to them from > single place. > > In cases with LDAP database it's a much harder, because there is no simple > $INCLUDE clause, I think. > We have to consult this problem with 389 guys ... It can be task for some > kind of directory server plugin. > > > Some examples and documentation: > http://wiki.sipfoundry.org/display/sipXecs/Location+based+DNS+views+for+sipXecs+using+BIND > (It belongs to some SIP solution, but it's exactly what you want.) > > http://www.zytrax.com/books/dns/ch7/view.html > > http://ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.ch06.html#view_statement_grammar > > > I'm adding BIND maintainer to this discussion. > > Petr^2 Spacek > > ___ > 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 04/13/2012 03:40 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 16:41, Rich Megginson wrote: On 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginsonwrote: It's not a problem until it's a problem :-) I would go ahead and run CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN 4f031e76001d000b not found, we aren't as up to date, or we purged Is it safe to run: [root@fileserver3 ~]# ipa-replica-manage re-initialize --from fileserver1.ecg.mit.edu I want to make sure I get it the correct way round! Are you sure that fileserver1 has the correct data? Maybe? :) I've snapshotted both VMs and re-initialized from fileserver1 - looking good so far. I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? The entry should exist, but the deleted servers should not be present in the nsds50ruv attribute. Also, the PKI-CA error logs are showing RUV errors, should I clean those too? I guess that I need to modify the commands (-b o=ipaca -p 7389 -h localhost). Yes. fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) This is a real connection error - could be cert or hostname lookup related. How do I find out if it's cert or hostname lookup? Which hostname? Fileserver3 runs DNS, and it seems to be working fine. Try ldapsearch - on server3 LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" If that works, check to make sure the replication agreement has the correct server2.fqdn If that doesn't work, use ldapsearch -d 1 -x . to get further debugging information. The replication agreements (according to ipa-replica-manage) all have the correct host names - I'm not sure what ldapsearch command to run to check the replication agreements. ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. Ok. And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is working? The /var/log/dirsrv/slapd-ECG-MIT-EDU/errors is now full of: [13/Apr/2012:14:59:19 -0400] NSMMReplicationPlugin - conn=1 op=571 csn=4f70a9e500010006: Can't created glue entry cn=fileserver4.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu uniqueid=6949d104-775b11e1-abce82a1-a45dd3c3, error 68 Should I delete the LDAP entry which is trying to replicate fileserver2 with fileserver4? Yes. And it may be due to the fact that the entry it is trying to delete has those tombstone children that have to be deleted too. OK, I'll see how this goes, once the tombstones are gone. The tombstones for ECG-MIT-EDU are gone now, still receiving this message in the logs. I think that's enough for this week - I'll look into it more next week. Thanks for your help, have a good weekend. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 16:41, Rich Megginson wrote: > On 04/13/2012 02:30 PM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: >>> It's not a problem until it's a problem :-) I would go ahead and run >>> CLEANRUV. >> >> I cleaned up a load of these entries, but now I think I've broken the >> replication between fileserver1 and 3: >> >> fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN >> 4f503996002b not found, we aren't as up to date, or we purged >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required >> to update replica has been purged. The replica must be reinitialized. >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental >> update failed and requires administrator action >> >> fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN >> 4f031e76001d000b not found, we aren't as up to date, or we purged >> >> Is it safe to run: >> [root@fileserver3 ~]# ipa-replica-manage re-initialize --from >> fileserver1.ecg.mit.edu >> >> I want to make sure I get it the correct way round! > > > Are you sure that fileserver1 has the correct data? Maybe? :) I've snapshotted both VMs and re-initialized from fileserver1 - looking good so far. I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=---)(objectclass=nstombstone))' is still showing entries though. Is that OK? Also, the PKI-CA error logs are showing RUV errors, should I clean those too? I guess that I need to modify the commands (-b o=ipaca -p 7389 -h localhost). >> fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: >> [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send >> startTLS request: error -1 (Can't contact LDAP server) errno 107 >> (Transport endpoint is not connected) > > > This is a real connection error - could be cert or hostname lookup > related. How do I find out if it's cert or hostname lookup? Which hostname? Fileserver3 runs DNS, and it seems to be working fine. >>> >>> >>> Try ldapsearch - on server3 >>> >>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H >>> ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" >>> >>> If that works, check to make sure the replication agreement has the >>> correct >>> server2.fqdn >>> >>> If that doesn't work, use ldapsearch -d 1 -x . to get further >>> debugging >>> information. >> >> The replication agreements (according to ipa-replica-manage) all have >> the correct host names - I'm not sure what ldapsearch command to run >> to check the replication agreements. > > > ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. The /var/log/dirsrv/slapd-ECG-MIT-EDU/errors is now full of: [13/Apr/2012:14:59:19 -0400] NSMMReplicationPlugin - conn=1 op=571 csn=4f70a9e500010006: Can't created glue entry cn=fileserver4.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu uniqueid=6949d104-775b11e1-abce82a1-a45dd3c3, error 68 Should I delete the LDAP entry which is trying to replicate fileserver2 with fileserver4? >>> >>> >>> Yes. And it may be due to the fact that the entry it is trying to delete >>> has those tombstone children that have to be deleted too. >> >> OK, I'll see how this goes, once the tombstones are gone. The tombstones for ECG-MIT-EDU are gone now, still receiving this message in the logs. I think that's enough for this week - I'll look into it more next week. Thanks for your help, have a good weekend. Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] routing requests to local servers - DNS SRV + view?
On 04/13/2012 10:28 PM, Jakub Hrozek wrote: 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. Greetings, if I understand correctly, you need to set different priority for SRV records and this new priority has to be dependent on client's IP address. AFAIK only way how to accomplish this is BIND "view" clause. You have to: - create copy of original zone for each location and modify SRV record priorities - then you have to set "views" and create mapping between IP address <-> new zone This way requires multiple copies of original zone, each with little differences. In case of classical zone files is not a big problem: You can keep SRV records separated in small files and "$INCLUDE" normal records to them from single place. In cases with LDAP database it's a much harder, because there is no simple $INCLUDE clause, I think. We have to consult this problem with 389 guys ... It can be task for some kind of directory server plugin. Some examples and documentation: http://wiki.sipfoundry.org/display/sipXecs/Location+based+DNS+views+for+sipXecs+using+BIND (It belongs to some SIP solution, but it's exactly what you want.) http://www.zytrax.com/books/dns/ch7/view.html http://ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.ch06.html#view_statement_grammar I'm adding BIND maintainer to this discussion. Petr^2 Spacek ___ 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 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. >> 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 04/13/2012 02:30 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: On 04/13/2012 01:03 PM, Dan Scott wrote: If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [snip] Is it safe to delete them? Yes. I deleted them, but it's still complaining about a non-leaf: [root@fileserver1 ~]# ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# Wow - never seen this one before I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 This error usually means a replica was deleted and the RUV needs to be cleaned. see http://port389.org/wiki/Howto:CLEANRUV and https://fedorahosted.org/freeipa/ticket/2303 and https://fedorahosted.org/389/ticket/337 OK, I've seen this before - is it important to remove them? I've had to add and remove replicas so much that I don't really want to do it unless it's necessary. I'm happy to live with them if it's not a problem. It's not a problem until it's a problem :-) I would go ahead and run CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN 4f031e76001d000b not found, we aren't as up to date, or we purged Is it safe to run: [root@fileserver3 ~]# ip
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 15:24, Rich Megginson wrote: > On 04/13/2012 01:03 PM, Dan Scott wrote: If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. >>> >>> You are correct. Try this: >>> >>> ldapsearch -D 'cn=directory manager' -W -v -b >>> >>> 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' >>> '(|(objectclass=nstombstone)(objectclass=*))' >> >> Ahh, so there are some 'child' entries: >> [snip] >> Is it safe to delete them? > > Yes. I deleted them, but it's still complaining about a non-leaf: [root@fileserver1 ~]# ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# >> I also see >> inconsistent replication states on the servers. i.e. server1 shows >> that it's replicating with server2 but server2 does not show that it's >> replicating with server1. > > > Do you have errors in the server2 log showing that it is attempting to > replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 >>> >>> >>> This error usually means a replica was deleted and the RUV needs to be >>> cleaned. >>> see http://port389.org/wiki/Howto:CLEANRUV >>> and >>> https://fedorahosted.org/freeipa/ticket/2303 >>> and >>> https://fedorahosted.org/389/ticket/337 >> >> OK, I've seen this before - is it important to remove them? I've had >> to add and remove replicas so much that I don't really want to do it >> unless it's necessary. I'm happy to live with them if it's not a >> problem. > > > It's not a problem until it's a problem :-) I would go ahead and run > CLEANRUV. I cleaned up a load of these entries, but now I think I've broken the replication between fileserver1 and 3: fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN 4f503996002b not found, we aren't as up to date, or we purged [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required to update replica has been purged. The replica must be reinitialized. [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental update failed and requires administrator action
Re: [Freeipa-users] 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] 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. 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
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] 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] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 01:03 PM, Dan Scott wrote: Thanks for the quick response. Simo: Thanks - I'd prefer to clean it up properly rather than start from scratch. I haven't changed the LDAP schema at all. All I've done is the use the IPA tools for user admin and add/remove replicas. I just felt like I've been emailing this list once a week or so for the past few months - I was beginning to think that it was beyond repair! :) On Fri, Apr 13, 2012 at 14:38, Rich Megginson wrote: On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginsonwrote: On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize() Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # aaa2c704-63cf11e1-ac8dadbd-35182efb, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=aaa2c704-63cf11e1-ac8dadbd-35182efb,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 17708e04-63dd11e1-9b079095-05c635b0, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=17708e04-63dd11e1-9b079095-05c635b0,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 5ceb8604-63f211e1-bc108552-1fbf39e2, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=5ceb8604-63f211e1-bc108552-1fbf39e2,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # c480f184-83f011e1-90d1df13-bba55eff, HTTP, fileserver5.ecg.mit.edu, masters , ipa, etc, ecg.mit.edu dn: nsuniqueid=c480f184-83f011e1-90d1df13-bba55eff,cn=HTTP,cn=fileserver5.ecg. mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: nsContainer objectClass: ipaConfigObject objectClass: top objectClass: nsTombstone ipaConfigString: enabledService ipaConfigString: startOrder 40 cn: HTTP nsParentUniqueId: 1eba8a03-642311e1-9b95afe9-fc1b53ef # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 Is it safe to delete them? Yes. I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ip
[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?
Thanks for the quick response. Simo: Thanks - I'd prefer to clean it up properly rather than start from scratch. I haven't changed the LDAP schema at all. All I've done is the use the IPA tools for user admin and add/remove replicas. I just felt like I've been emailing this list once a week or so for the past few months - I was beginning to think that it was beyond repair! :) On Fri, Apr 13, 2012 at 14:38, Rich Megginson wrote: > On 04/13/2012 12:22 PM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: >>> >>> On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. >>> >>> >>> What version of 389-ds-base is this? Do you get any errors? It just >>> silently fails to delete this particular entry? >> >> [root@fileserver1 ~]# rpm -qa|grep 389 >> 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 >> 389-ds-base-1.2.10.4-2.fc16.x86_64 >> [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory >> manager' -W >> Enter LDAP Password: >> deleting entry >> "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" >> ldap_delete: Operation not allowed on non-leaf (66) >> >> [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b >> 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' >> '(objectclass=*)' >> ldap_initialize( ) >> Enter LDAP Password: >> filter: (objectclass=*) >> requesting: All userApplication attributes >> # extended LDIF >> # >> # LDAPv3 >> # >> base >> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu >> dn: >> cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu >> cn: fileserver5.ecg.mit.edu >> objectClass: top >> objectClass: nsContainer >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> [root@fileserver1 ~]# >> >> If I'm interpreting this correctly, it can't be deleted because it's >> not a leaf node, but it doesn't have any sub-entries that I can delete >> first. > > > You are correct. Try this: > > ldapsearch -D 'cn=directory manager' -W -v -b > 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' > '(|(objectclass=nstombstone)(objectclass=*))' Ahh, so there are some 'child' entries: [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (|(objectclass=nstombstone)(objectclass=*)) # requesting: ALL # # aaa2c704-63cf11e1-ac8dadbd-35182efb, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=aaa2c704-63cf11e1-ac8dadbd-35182efb,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 17708e04-63dd11e1-9b079095-05c635b0, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=17708e04-63dd11e1-9b079095-05c635b0,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # 5ceb8604-63f211e1-bc108552-1fbf39e2, fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: nsuniqueid=5ceb8604-63f211e1-bc108552-1fbf39e2,cn=fileserver5.ecg.mit.edu, cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: top objectClass: nsContainer objectClass: nsTombstone cn: fileserver5.ecg.mit.edu nsParentUniqueId: 4fff591e-e48611e0-bf3681aa-d1a3957d # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # c480f184-83f011e1-90d1df13-bba55eff, HTTP, fileserver5.ecg.mit.edu, masters , ipa, etc, ecg.mit.edu dn: nsuniqueid=c480f184-83f011e1-90d1df13-bba55eff,cn=HTTP,cn=fileserver5.ecg. mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu objectClass: nsContainer objectClass: ipaConfigObject objectClass: top objectClass: nsTombstone ipaConfigString: enabledService ipaConfigString: startOrder 40 cn: HTTP nsParentUniqueId: 1eba8a03-642311e1-9b95afe9-fc1b53ef # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 Is it safe to delete them? I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 12:22 PM, Dan Scott wrote: On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: On 04/13/2012 11:39 AM, Dan Scott wrote: I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize( ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. You are correct. Try this: ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(|(objectclass=nstombstone)(objectclass=*))' I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 This error usually means a replica was deleted and the RUV needs to be cleaned. see http://port389.org/wiki/Howto:CLEANRUV and https://fedorahosted.org/freeipa/ticket/2303 and https://fedorahosted.org/389/ticket/337 fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) This is a real connection error - could be cert or hostname lookup related. [13/Apr/2012:13:57:39 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver2's non-PKI replication agreements to both fileserver1 and 3 are in place, but both say: Incremental update has failed and requires administrator actionSystem error. When I try to re-initialize: [root@fileserver2 ~]# ipa-replica-manage re-initialize --from fileserver3.ecg.mit.edu Directory Manager password: [fileserver3.ecg.mit.edu] reports: Replica Busy! Status: [1 Replication error acquiring replica: replica busy] This is a transient condition. this command has been running for 1/2hr and produced no mo
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, 2012-04-13 at 13:39 -0400, Dan Scott wrote: > Hi, > > I've been using FreeIPA for a couple of years (Upgraded/Migrated from > FreeIPA 1). The servers are in various states (Some upgraded from > Fedora 10/11 through each release, some fresh installs of Fedora > 15/16). I've also had to add/remove replicas many times - and run into > problems installing which required some manual intervention. > > I'm convinced that my LDAP directories contain lots of cruft which has > built up and is causing problems on my system. There may even be some > corruption since there's an entry which I'm unable to remove - this > entry does not get replicated to the other servers. I also see > inconsistent replication states on the servers. i.e. server1 shows > that it's replicating with server2 but server2 does not show that it's > replicating with server1. > > Is there some way that I can refresh/clean my LDAP directories and > ensure that everything's running correctly. Well it really depends on what you need to achieve. Of course you have the big hammer of setting up a brand new realm and then migrating over users/groups, but that would require to start from scratch with hbac and related rules and re-enrollment of users and hosts. In general if you haven't willfully changed stuff manually over ldap you should be in good shape. It should be sufficient to find out and fix why DS is not allowing you to delete that entry you want to delete and then you should be able to clean up stuff trhough the CLI or the WebUI tools. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 13:43, Rich Megginson wrote: > On 04/13/2012 11:39 AM, Dan Scott wrote: >> I'm convinced that my LDAP directories contain lots of cruft which has >> built up and is causing problems on my system. There may even be some >> corruption since there's an entry which I'm unable to remove - this >> entry does not get replicated to the other servers. > > > What version of 389-ds-base is this? Do you get any errors? It just > silently fails to delete this particular entry? [root@fileserver1 ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10.4-2.fc16.x86_64 389-ds-base-1.2.10.4-2.fc16.x86_64 [root@fileserver1 ~]#ldapmodify -f rmfileserver5.ldif -D 'cn=directory manager' -W Enter LDAP Password: deleting entry "cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu" ldap_delete: Operation not allowed on non-leaf (66) [root@fileserver1 ~]# ldapsearch -D 'cn=directory manager' -W -v -b 'cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu' '(objectclass=*)' ldap_initialize( ) Enter LDAP Password: filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # fileserver5.ecg.mit.edu, masters, ipa, etc, ecg.mit.edu dn: cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu cn: fileserver5.ecg.mit.edu objectClass: top objectClass: nsContainer # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@fileserver1 ~]# If I'm interpreting this correctly, it can't be deleted because it's not a leaf node, but it doesn't have any sub-entries that I can delete first. >> I also see >> inconsistent replication states on the servers. i.e. server1 shows >> that it's replicating with server2 but server2 does not show that it's >> replicating with server1. > > > Do you have errors in the server2 log showing that it is attempting to > replicate with server1 but failing with some error? [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver1.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:39+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver2.ecg.mit.edu Directory Manager password: fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 fileserver3.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:41+00:00 [root@fileserver1 ~]# ipa-csreplica-manage list -v fileserver3.ecg.mit.edu Directory Manager password: fileserver2.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:44+00:00 fileserver1.ecg.mit.edu last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-04-13 17:57:43+00:00 [root@fileserver1 ~]# fileserver1's (and fileserver2s) /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:57:43 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [13/Apr/2012:13:57:39 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=ipaca: 20 fileserver2's non-PKI replication agreements to both fileserver1 and 3 are in place, but both say: Incremental update has failed and requires administrator actionSystem error. When I try to re-initialize: [root@fileserver2 ~]# ipa-replica-manage re-initialize --from fileserver3.ecg.mit.edu Directory Manager password: [fileserver3.ecg.mit.edu] reports: Replica Busy! Status: [1 Replication error acquiring replica: replica busy] this command has been running for 1/2hr and produced no more output (fileserver2 is the remaining server running Fedora 15, the others are Fedora 16 with latest updates). >> Is there some way that I can refresh/clean my LDAP directories and >> ensure that everything's running correctly. > > We first need to find out what's going on and why you are seeing these > failures before we can recommend a particular course of action. There is > currently no "find all of my problems and fix them" command. :) Wish there was. It's just that I've been having lots of problems recently and I was thinking that there is something f
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/13/2012 11:39 AM, Dan Scott wrote: Hi, I've been using FreeIPA for a couple of years (Upgraded/Migrated from FreeIPA 1). The servers are in various states (Some upgraded from Fedora 10/11 through each release, some fresh installs of Fedora 15/16). I've also had to add/remove replicas many times - and run into problems installing which required some manual intervention. I'm convinced that my LDAP directories contain lots of cruft which has built up and is causing problems on my system. There may even be some corruption since there's an entry which I'm unable to remove - this entry does not get replicated to the other servers. What version of 389-ds-base is this? Do you get any errors? It just silently fails to delete this particular entry? I also see inconsistent replication states on the servers. i.e. server1 shows that it's replicating with server2 but server2 does not show that it's replicating with server1. Do you have errors in the server2 log showing that it is attempting to replicate with server1 but failing with some error? Is there some way that I can refresh/clean my LDAP directories and ensure that everything's running correctly. We first need to find out what's going on and why you are seeing these failures before we can recommend a particular course of action. There is currently no "find all of my problems and fix them" command. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[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] 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. 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
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. 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: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. >> 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: 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. 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
[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. 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
[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