On 09/05/13 15:28, steve wrote:
On 09/05/13 15:03, steve wrote:
On 09/05/13 13:32, Jakub Hrozek wrote:
On Thu, May 09, 2013 at 01:00:02PM +0200, steve wrote:
Hi sssd seems to be sending the wrong request to the DNS server:
(Thu May 9 12:57:04 2013) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): DNS update finished (Thu May 9 12:57:06 2013) [sssd[be[default]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Error de entrada/salida (Thu May 9 12:57:06 2013) [sssd[be[default]]] [nsupdate_get_addrs_done] (0x0040): Could not resolve address for this machine, error [5]: Error de entrada/salida, resolver returned: [11]: Could not contact DNS servers
The logs are telling you that the SSSD cannot resolve the machine's host name. Can you try overriding it with "ad_hostname" or adding the hostname to /ec/hosts ?
Hi I added: ad_hostname = pinoso.hh3.site to sssd.conf. It was already in /etc/hosts
Now the request is sent and we can see it on the Samba4 DC:
Tkey handshake completed Got a dns update request. update count is 1 Looking at record: discard_const(update): struct dns_res_rec name : 'pinoso.hh3.site' rr_type : DNS_QTYPE_A (0x1) rr_class : DNS_QCLASS_IN (0x1) ttl : 0x00000e10 (3600) length : 0x0004 (4) rdata : union dns_rdata(case 0x1) ipv4_record : 192.168.1.100 unexpected : DATA_BLOB length=0 Terminating connection - 'dns_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[dns_tcp_call_loop: tstream_read_pdu_blob_recv()
- NT_STATUS_CONNECTION_DISCONNECTED]
Terminating connection - 'dns_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' (Thu May 9 14:55:21 2013) [sssd[be[default]]]
But the IP is not updated. We changed it from 192.168.1.100 to 192.168.1.101. It does update if we reboot the machine
[sdap_dyndns_update_done] (0x0080): nsupdate failed, retrying with server name ; TSIG error with server: tsig verify failure ; TSIG error with server: tsig verify failure ; TSIG error with server: tsig verify failure update failed: SERVFAIL (Thu May 9 14:55:21 2013) [sssd[be[default]]] [child_sig_handler] (0x0020): child [1809] failed with status [2]. (Thu May 9 14:55:21 2013) [sssd[be[default]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512] (Thu May 9 14:55:21 2013) [sssd[be[default]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158226]: Dynamic DNS update failed (Thu May 9 14:55:21 2013) [sssd[be[default]]] [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [1432158226]: Dynamic DNS update failed (Thu May 9 14:55:21 2013) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158226]: Dynamic DNS update failed (Thu May 9 14:55:36 2013) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): DNS update finished (Thu May 9 14:55:52 2013) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): DNS update finished (Thu May 9 14:56:08 2013) [sssd[be[default]]] [ad_dyndns_nsupdate_done] (0x0040): DNS update finished
It is sending the old IP. 101 is the old IP. We changed it to 100, restarted the network, removed the cache and restarted sssd:
server hh16.hh3.site realm HH3.SITE update delete pinoso.hh3.site. in A send update delete pinoso.hh3.site. in AAAA send update add pinoso.hh3.site. 3600 in A 192.168.1.101 send
We can only make it get the new IP by rebooting the client. Must we reboot each time? Thanks
__
Hi OK. It's working fine, (but the TSIG errors are worrying).
We don't really want to have to restart sssd after a dnydns update, so to make your test case at: https://fedoraproject.org/wiki/QA:Testcase_sssd_ad_dns_update a little more realistic, how about:
e.g., using our lan IP's: Set the test client to static IP 192.168.1.100: ifconfig eth0 192.168.125.100 netmask 255.255.255.0 up domain user logs in and logs out
Set the test client to static IP 192.168.1.101: ifconfig eth0 192.168.125.101 netmask 255.255.255.0 up domain user logs in
check: the IP of the client has been updated The database always seems to be contacted upon login, not the cache.
Is this the expected outcome of dyndns_update?
Thanks for your help and a nice utility. Steve