+++ This bug was initially created as a clone of Bug #680442 +++ If only a single server name is given in ipa_server the dynamic update of the DNS record of the IPA DNS server succeeds. If there are more servers or _srv_ given the update fails. https://fedorahosted.org/sssd/ticket/810
1) install client with --enable-dns-updates 2) check on server that DNS record exists # ipa dnsrecord-show --all Zone name: testrelm Record name: dhcp-100-19-69 dn: idnsname=dhcp-100-19-69,idnsname=testrelm,cn=dns,dc=testrelm Record name: dhcp-100-19-69 Time to live: 1200 A record: 10.16.19.69 objectclass: idnsRecord, top 3) test ssh sso # kinit jennyg Password for jennyg@TESTRELM: [root@dhcp-100-19-202 quickinstall]# ssh dhcp-100-19-69.testrelm The authenticity of host 'dhcp-100-19-69.testrelm (10.16.19.69)' can't be established. RSA key fingerprint is 25:ea:ff:72:c8:7f:a1:67:0a:c6:d3:65:53:84:84:a5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'dhcp-100-19-69.testrelm,10.16.19.69' (RSA) to the list of known hosts. Last login: Wed Jun 1 12:55:23 2011 from 10.16.19.189 4) change IP address and reboot client machine, ssh to another machine in IPA realm, getent on non existent user - nothing is triggering a dns update on the server - IP address should be 10.16.19.70 now. # ipa dnsrecord-show --all Zone name: testrelm Record name: dhcp-100-19-69 dn: idnsname=dhcp-100-19-69,idnsname=testrelm,cn=dns,dc=testrelm Record name: dhcp-100-19-69 Time to live: 1200 A record: 10.16.19.69 objectclass: idnsRecord, top And can no longer ssh to the client from the server # ssh dhcp-100-19-69.testrelm ssh: connect to host dhcp-100-19-69.testrelm port 22: No route to host
Do the IPA domain logs say anything? > And can no longer ssh to the client from the server > > # ssh dhcp-100-19-69.testrelm > ssh: connect to host dhcp-100-19-69.testrelm port 22: No route to host Are you sure that the DHCP client did not overwrite your /etc/resolv.conf with some stock DNS server? Please check if the IPA server is set as the DNS server in /etc/resolv.conf
Name server is set to the IPA Server in /etc/resolv.conf - both client and server
Can you check the SSSD logs to see if the the DNS update is being attempted and is reporting a failure? Also, on the IPA server(s), please check /var/log/messages for named errors.
seeing the following in sssd_testrelm.log on client: (Tue Jun 7 09:41:00 2011) [sssd[be[testrelm]]] [child_sig_handler] (1): child [16783] failed with status [1]. (Tue Jun 7 09:41:00 2011) [sssd[be[testrelm]]] [ipa_dyndns_child_handler] (1): Dynamic DNS child failed with status [256] (Tue Jun 7 09:41:00 2011) [sssd[be[testrelm]]] [child_sig_handler] (1): child [16788] failed with status [1]. (Tue Jun 7 09:41:00 2011) [sssd[be[testrelm]]] [ipa_dyndns_child_handler] (1): Dynamic DNS child failed with status [256] (Tue Jun 7 09:41:00 2011) [sssd[be[testrelm]]] [ipa_dyndns_update_done] (1): Updating DNS entry failed
oh and nothing from named on server in /var/log/messages.
Can you add the following section to /etc/named.conf on the server: ----- logging { channel default_debug { file "data/named.run"; severity dynamic; }; channel update_log { file "data/update.log"; severity debug 9; print-time yes; }; category update { update_log; }; category update-security { update_log; }; }; ------ (The channel default_debug might already be there, not sure) Then restart named. /var/named/data/update.log should have some more info. btw, Stephen, what do you think about printing the update message as a DEBUG() message in SSSD? Would it contain anything sensitive?
(In reply to comment #8) > btw, Stephen, what do you think about printing the update message as a DEBUG() > message in SSSD? Would it contain anything sensitive? I was just looking into doing exactly that. I don't think it contains any sensitive data, but I need to run a few tests.
Adding logging to named server still nothing logged when client attempt for dnsupdate fails in /var/log/messages and /var/named/data/update.log is empty
version of RPM on RHEL 5 is too old to support the arch-specific Requires:. this bug can neither be verified nor actually fixed on RHEL 5 without updates to rpm No issues seen during automation regressions. Marking as VERIFIED SANITYONLY. # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 36.el5 Build Date: Tue 31 May 2011 12:15:53 PM EDT Install Date: Fri 03 Jun 2011 11:59:38 AM EDT Build Host: x86-008.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-36.el5.src.rpm Size : 3486788 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon
sorry, wrong bug
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Release Note: Known bug: The System Security Services Daemon does not support the ipa_dyndns_update option in Red Hat Enterprise Linux 5.7.
Upstream ticket: https://fedorahosted.org/sssd/ticket/810
Upstream ticket: https://fedorahosted.org/sssd/ticket/1138
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0164.html