Re: [Freeipa-users] Replication stopped working
On 09/04/2014 05:11 PM, Guillermo Fuentes wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo Hello, I think we would need more troubleshooting information that are available in /var/log/dirsrv/slapd-EXAMPLE-COM/errors, especially on m2, m3, m4. Few pointers what I would try myself: 1) Check that all masters have time synced (difference in matter of seconds is OK) 2) Check that DNS is all right - all replicas can resolve master's forward and reverse address. Master can resolve all replicas forward and reverse address. This is common source of replication/Kerberos errors (http://www.freeipa.org/page/Troubleshooting#Kerberos_does_not_work) The error Can't contact LDAP server may point to DNS issues. 3) Check that you can do plain ldapsearch from replica to master. Ideally even authenticated with keytab from /etc/dirsrv/ds.keytab HTH, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
On 09/04/2014 10:31 PM, Ron wrote: So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? Exactly. How do I unlink the entry? Would I use the following? ipa group-detach userxyz You would normally use it, but I am not sure it would work given that group DN is changed with the nsuniqueid RDN. However, you can manually detach the group with ldapmodify: $ kinit admin $ ipa group-show fbar --all --raw dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test cn: fbar description: User private group for fbar gidnumber: 8264 ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top $ ldapmodify -Y GSSAPI -h `hostname` SASL/GSSAPI authentication started SASL username: ad...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify delete: objectClass objectClass: mepManagedEntry - delete: mepManagedBy mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test Now the ldapdelete on group should work. Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using 389-console with FreeIPA 3
On 09/04/2014 11:24 PM, Andrew Krause wrote: I realize this question has been brought forth previously, but I am unable to find a clear answer. I have a 389-ds environment that is serving as an authentication back end for a python application. The plan was to use this as a kind of SSO for other future applications and we have MANY users/groups/OUs and different policies involved already. Since it's not really feasible to re-create everything, and it will not integrate directly with FreeIPA I would like to be able to import my subtree to the 389-ds instance within my new FreeIPA install and manage that subtree separately from all my hosts and POSIX users. The short question, how can I manage to get the admin console working with the 389-ds that is included in FreeIPA? I'd really like to use FreeIPA for all my host based authentication, but it becomes a non-option if we have to run multiple directory clusters. The best way is to use ipa migrate-ds command to load the users from the external LDAP server. You can connect a console to IPA DS instance but we do not recommend doing modifications via it because IPA creates all sorts of object classes on the entries on top of usual posix account. You can use the console to validate on the low level that all data has been properly migrated. But again ipa has ipa user-find and user-show commands that allow you to validation too so console might actually not be needed. Please refer to ipa help and online downstream manuals on how to use migrate-ds command. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using 389-console with FreeIPA 3
On 09/05/2014 02:54 AM, Andrew Krause wrote: I realize this question has been brought forth previously, but I am unable to find a clear answer. I have a 389-ds environment that is serving as an authentication back end for a python application. The plan was to use this as a kind of SSO for other future applications and we have MANY users/groups/OUs and different policies involved already. Since it's not really feasible to re-create everything, and it will not integrate directly with FreeIPA I would like to be able to import my subtree to the 389-ds instance within my new FreeIPA install and manage that subtree separately from all my hosts and POSIX users. The short question, how can I manage to get the admin console working with the 389-ds that is included in FreeIPA? Hi Andrew, I assume you are running FreeIPA server on Fedora19/20 or above. If that assumption is correct, then you can do yum install 389-ds 389-admin-console idm-console-framework. All versions of fedora has these packages by default. Thanks, -Sankar R I'd really like to use FreeIPA for all my host based authentication, but it becomes a non-option if we have to run multiple directory clusters. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
On 09/05/2014 12:44 AM, Martin Kosek wrote: On 09/04/2014 10:31 PM, Ron wrote: So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? Exactly. How do I unlink the entry? Would I use the following? ipa group-detach userxyz You would normally use it, but I am not sure it would work given that group DN is changed with the nsuniqueid RDN. However, you can manually detach the group with ldapmodify: $ kinit admin $ ipa group-show fbar --all --raw dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test cn: fbar description: User private group for fbar gidnumber: 8264 ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top $ ldapmodify -Y GSSAPI -h `hostname` SASL/GSSAPI authentication started SASL username: ad...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify delete: objectClass objectClass: mepManagedEntry - delete: mepManagedBy mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test Now the ldapdelete on group should work. Is this procedure documented somewhere? Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using 389-console with FreeIPA 3
On 09/05/2014 03:32 AM, Sankar Ramlingam wrote: On 09/05/2014 02:54 AM, Andrew Krause wrote: I realize this question has been brought forth previously, but I am unable to find a clear answer. I have a 389-ds environment that is serving as an authentication back end for a python application. The plan was to use this as a kind of SSO for other future applications and we have MANY users/groups/OUs and different policies involved already. Since it's not really feasible to re-create everything, and it will not integrate directly with FreeIPA I would like to be able to import my subtree to the 389-ds instance within my new FreeIPA install and manage that subtree separately from all my hosts and POSIX users. The short question, how can I manage to get the admin console working with the 389-ds that is included in FreeIPA? Hi Andrew, I assume you are running FreeIPA server on Fedora19/20 or above. If that assumption is correct, then you can do yum install 389-ds 389-admin-console idm-console-framework. All versions of fedora has these packages by default. Actually, just yum install 389-console installs the console. However, that is not sufficient. You will need a configuration directory server, which has been configured with the o=NetscapeRoot tree, among other things. You will need to install the 389-admin package on the machines that have 389-ds-base installed. You will need to run the register-ds-admin.pl script to create your configuration ds and to register directory servers with the config ds. And, since we do not test this at all, there is no guarantee that it will not break your IPA deployment, so be sure to backup/snapshot/etc. before going down this road. Thanks, -Sankar R I'd really like to use FreeIPA for all my host based authentication, but it becomes a non-option if we have to run multiple directory clusters. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] DNS not responding properly....
I've got an odd situation with one of our networks. Our systems are properly registered in DNS within IPA, and the web interface and IPA queries work to resolve the hosts, but named isn't playing along with us. [root@ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk Record name: asterisk A record: 192.168.252.155 Number of entries returned 1 [root@ipa1 data]# host asterisk.foo.net Host asterisk.foo.net not found: 3(NXDOMAIN) [root@ipa1 data]# cat /etc/resolv.conf search foo.net nameserver 192.168.252.61- This is ipa1 nameserver 192.168.252.62 nameserver 192.168.252.63 [root@ipa1 data]# ifconfig ens192: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20link ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) RX packets 2189 bytes 332143 (324.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1523 bytes 428925 (418.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 1037 bytes 718872 (702.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1037 bytes 718872 (702.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ipa1 data]# When I dig into the named.run file, I see the trace below (I ran an rndc reload after seeing the request to do so at the end of an earlier section of the file; it obviously didn't help much). I'm not sure where else to look. /etc/named.conf and /var/named/named.ca both are in line with what we have on another similar system where everything is working just fine. Any thoughts? 05-Sep-2014 12:04:47.111 received control channel command 'reload' 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 80.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 81.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 82.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199
Re: [Freeipa-users] DNS not responding properly....
Hello, On 5.9.2014 18:14, Bret Wortman wrote: I've got an odd situation with one of our networks. Our systems are properly registered in DNS within IPA, and the web interface and IPA queries work to resolve the hosts, but named isn't playing along with us. [root@ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk Record name: asterisk A record: 192.168.252.155 Number of entries returned 1 [root@ipa1 data]# host asterisk.foo.net Host asterisk.foo.net not found: 3(NXDOMAIN) [root@ipa1 data]# cat /etc/resolv.conf search foo.net nameserver 192.168.252.61- This is ipa1 nameserver 192.168.252.62 nameserver 192.168.252.63 [root@ipa1 data]# ifconfig ens192: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20link ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) RX packets 2189 bytes 332143 (324.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1523 bytes 428925 (418.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 1037 bytes 718872 (702.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1037 bytes 718872 (702.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ipa1 data]# When I dig into the named.run file, I see the trace below (I ran an rndc reload after seeing the request to do so at the end of an earlier section of the file; it obviously didn't help much). I'm not sure where else to look. /etc/named.conf and /var/named/named.ca both are in line with what we have on another similar system where everything is working just fine. Any thoughts? Please double check output from $ ipa dnszone-show foo.net It should contain line like: Active zone: TRUE Petr^2 Spacek 05-Sep-2014 12:04:47.111 received control channel command 'reload' 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic
Re: [Freeipa-users] Replication stopped working
Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! On Fri, Sep 5, 2014 at 12:43 PM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hi Martin, Attached are m2.log, m3.log and m4.log files. 1) All masters are time synced with same NTP server pool. 2) DNS is fine. Forward and reverse lookup. 3) ldapsearch: m1 to m2 and m3 work: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` # getting ticket on m1 ldapsearch -Y GSSAPI -H ldaps://m2.example.com -b dc=example,dc=com uid=testuser ldapsearch -Y GSSAPI -H ldaps://m3.example.com -b dc=example,dc=com uid=testuser m1 to m4 fails: # ldapsearch -Y GSSAPI -H ldaps://m4.example.com -b dc=example,dc=com uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: FINDING_SERVER_KEY) m2 to m1, and m3 to m1 work fine: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b dc=example,dc=com uid=testuser m4 to m1 fails: # ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b dc=example,dc=com uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-14): authorization failure: security flags do not match required m2 and m3 are at the same state now where connections between them and m1 are fine but the updates won't happen logging the following on m1 (/var/log/dirsrv/slapd-EXAMPLE-COM/errors) for both: [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb0004) [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb0004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb0004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb0004): [05/Sep/2014:12:30:49 -0400] agmt=cn=meTom3.example.com (m3:389) - load=1 rec=38 csn=53d66ecb00020004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb00020004) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb00020004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb00020004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb00020004): [05/Sep/2014:12:30:49 -0400] agmt=cn=meTom3.example.com (m3:389) - load=1 rec=39 csn=53d66ecc00010004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecc00010004) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecc00010004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecc00010004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecc00010004): [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): No more updates to send (cl5GetNextOperationToReplay) [05/Sep/2014:12:30:49 -0400] - repl5_inc_waitfor_async_results: 0
Re: [Freeipa-users] Replication stopped working
Good to hear Guillermo, I am glad you are back up and running. I am just curious, what as the root cause of your replication errors in the end? I did not catch that from the thread. Is it something we can fix in FreeIPA or is it just a configuration error? Thanks, Martin On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication stopped working
Hi Martin, That's a good question! We're not sure what was the root cause of the replication errors. When we realized the replication wasn't happening, we had recently updated FreeIPA from 3.0.0-36 to 3.0.0-37 (on CentOS 6.5) and we had shutdown m1 and m2 in order to do a snapshot of the VMs. We've been doing that for several months and never had a problem. Note that m3 wasn't shutdown and the replication stopped for it as well. The configuration wasn't change so I don't think it was a configuration problem. I did have to get a new ldap service keytab for the m2 replica (/etc/dirsrv/ds.keytab) but not for m3. I'll do more research on what happened and report back if I find anything relevant. Thanks again, Guillermo On Fri, Sep 5, 2014 at 4:22 PM, Martin Kosek mko...@redhat.com wrote: Good to hear Guillermo, I am glad you are back up and running. I am just curious, what as the root cause of your replication errors in the end? I did not catch that from the thread. Is it something we can fix in FreeIPA or is it just a configuration error? Thanks, Martin On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
So, just for completeness in case someone else experiences the same issue, what I did in the end was install JXplorer and then use it to delete the problem entries. They appeared as (for example): nsuniqueid=4034e309-d63711e3-9b7eb928-a98b9061+uid=disk100,cn=users,cn=accounts,dc=xxx,dc=abc,dc=ca Just right-clicked and selected delete. Based on ease of installation and ease of use, I highly recommend JXplorer (for solving problems like this). It can also be run in a readonly mode which is nice just to poke around without the possibility of messing things up. Regards, Ron On 09/04/2014 02:17 PM, Rich Megginson wrote: On 09/04/2014 02:31 PM, Ron wrote: So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? How do I unlink the entry? Would I use the following? ipa group-detach userxyz Yes, see https://fedorahosted.org/freeipa/ticket/75 Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
