Hi We've exhausted all the possibilities over on the samba list and think we have a bug with the Lubuntu version of 1.11.5 against a Samba4 DC. We have 1.11.5 ddns working perfectly against the same DC and nsupdate works fine from the failing lubuntu laptop. I hope you don't mind in me quoting from the samba lists below. Any help would be most gratefully received:
sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = hh3.site [nss] [pam] [domain/hh3.site] ad_server = hh16.hh3.site id_provider = ad auth_provider = ad access_provider = ad ldap_id_mapping = False
log: tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server not found in Kerberos database. (Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [child_sig_handler] (0x0020): child [6460] failed with status [1]. (Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [sdap_dyndns_update_done] (0x0080): nsupdate failed, retrying with server name tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server not found in Kerberos database. (Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [child_sig_handler] (0x0020): child [6464] failed with status [1]. (Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [1432158228]: Dynamic DNS update failed (Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158228]: Dynamic DNS update failed
On 21/05/14 10:07, steve wrote:
On 20/05/14 15:35, Rowland Penny wrote:
On 20/05/14 14:12, steve wrote:
Hi I'm trying to get an Ubuntu 14.04 client to update its rr to a working bind dns DC with Samba 4.1.7. The setup is the same as with our openSUSE clients with sssd 1.11.15 /etc/hosts 127.0.0.1 lubuntu-laptop.hh3.site lubuntu-laptop 127.0.1.1 localhost
DC log:
Kerberos: ENC-TS Pre-authentication succeeded -- LUBUNTU-LAPTOP$@HH3.SITE using arcfour-hmac-md5 Kerberos: AS-REQ authtime: 2014-05-20T14:01:35 starttime: unset endtime: 2014-05-21T00:01:35 renew till: 2014-05-21T14:01:35 Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, arcfour-hmac-md5, des3-cbc-sha1, 25, 26, using arcfour-hmac-md5/arcfour-hmac-md5 Kerberos: Requested flags: renewable-ok Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40240 for ldap/hh16.hh3.site@HH3.SITE [canonicalize, renewable] Kerberos: TGS-REQ authtime: 2014-05-20T14:01:35 starttime: 2014-05-20T14:01:35 endtime: 2014-05-21T00:01:35 renew till: 2014-05-21T14:01:35 Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for server DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for
(&(objectClass=trustedDomain)(|(flatname=ROOT-SERVERS.NET)(trustPartner=ROOT-SERVERS.NET))):
got 0 Kerberos: samba_kdc_fetch: could not find principal in DB Kerberos: Server not found in database: krbtgt/ROOT-SERVERS.NET@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40241 Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40242 for DNS/a.root-servers.net@HH3.SITE [renewable] Kerberos: Server not found in database: DNS/a.root-servers.net@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40242 Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40243 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for server DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for
(&(objectClass=trustedDomain)(|(flatname=ROOT-SERVERS.NET)(trustPartner=ROOT-SERVERS.NET))):
got 0 Kerberos: samba_kdc_fetch: could not find principal in DB Kerberos: Server not found in database: krbtgt/ROOT-SERVERS.NET@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40243 Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40244 for DNS/a.root-servers.net@HH3.SITE [renewable] Kerberos: Server not found in database: DNS/a.root-servers.net@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40244
The worrying thing is that we can still get tickets even though it has the wrong A record in DNS. What is this, 'a.root-servers.net' business? Why not our domain? What have we overlooked? Thanks, Steve
OK It works fine with nsupdate on the Administrator's tgt:
Kerberos: AS-REQ Administrator@HH3.SITE from ipv4:192.168.1.22:35207
for krbtgt/HH3.SITE@HH3.SITE
Kerberos: Client sent patypes: 149 Kerberos: Looking for PKINIT pa-data -- Administrator@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- Administrator@HH3.SITE Kerberos: No preauth found, returning PREAUTH-REQUIRED --
Administrator@HH3.SITE
Kerberos: AS-REQ Administrator@HH3.SITE from ipv4:192.168.1.22:60295
for krbtgt/HH3.SITE@HH3.SITE
Kerberos: Client sent patypes: encrypted-timestamp, 149 Kerberos: Looking for PKINIT pa-data -- Administrator@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- Administrator@HH3.SITE Kerberos: ENC-TS Pre-authentication succeeded --
Administrator@HH3.SITE using arcfour-hmac-md5
Kerberos: AS-REQ authtime: 2014-05-21T10:51:46 starttime: unset
endtime: 2014-05-21T20:51:46 renew till: 2014-05-22T10:51:42
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, 25, 26, using arcfour-hmac-md5/arcfour-hmac-md5
Kerberos: Requested flags: renewable-ok Kerberos: TGS-REQ Administrator@HH3.SITE from ipv4:192.168.1.22:57157
for DNS/hh16.hh3.site@HH3.SITE [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2014-05-21T10:51:46 starttime:
2014-05-21T10:52:50 endtime: 2014-05-21T20:51:46 renew till: 2014-05-22T10:51:42
and named responds: R 2014-05-21T10:52:50.315641+02:00 hh16 named[1965]: samba_dlz:
starting transaction on zone hh3.site
2014-05-21T10:52:50.319042+02:00 hh16 named[1965]: samba_dlz:
allowing update of signer=Administrator@HH3.SITE name=lubuntu-laptop.hh3.site tcpaddr=192.168.1.22 type=A key=3111087606.sig-hh16.hh3.site/160/0
2014-05-21T10:52:50.321707+02:00 hh16 named[1965]: samba_dlz:
allowing update of signer=Administrator@HH3.SITE name=lubuntu-laptop.hh3.site tcpaddr=192.168.1.22 type=A key=3111087606.sig-hh16.hh3.site/160/0
2014-05-21T10:52:50.322267+02:00 hh16 named[1965]: client
192.168.1.22#48170/key Administrator@HH3.SITE: updating zone 'hh3.site/NONE': deleting rrset at 'lubuntu-laptop.hh3.site' A
2014-05-21T10:52:50.325538+02:00 hh16 named[1965]: samba_dlz:
subtracted rdataset lubuntu-laptop.hh3.site 'lubuntu-laptop.hh3.site.#0113600#011IN#011A#011192.168.1.22'
2014-05-21T10:52:50.326263+02:00 hh16 named[1965]: client
192.168.1.22#48170/key Administrator@HH3.SITE: updating zone 'hh3.site/NONE': adding an RR at 'lubuntu-laptop.hh3.site' A
2014-05-21T10:52:50.329767+02:00 hh16 named[1965]: samba_dlz: added
rdataset lubuntu-laptop.hh3.site 'lubuntu-laptop.hh3.site.#0113600#011IN#011A#011192.168.1.22'
2014-05-21T10:52:50.644113+02:00 hh16 named[1965]: samba_dlz:
committed transaction on zone hh3.site
Note, that via sssd, nothing is logged by bind, I suppose because the
KDC throws it out before it gets there.
So, can we now point the blame at whatever Ubuntu have done with sssd
1.11.5? The sssd guys tell me that all they do is call out to nsupdate for the ddns. As a 1.11.5 build from source on openSUSE works OK, do I have enough information to narrow it down to the Ubuntu package? Do I now have to build sssd on the laptop to prove my point?
@Rowland. Do you have a 'debianified' build method for 1.11.5?
Sorry, but no, Ubuntu 14.04 comes with 1.11.3 and I am using this. It must be possible though, Timo Aaltonen builds it for the Ubuntu 12.04 PPA here: https://launchpad.net/~sssd/+archive/updates
Perhaps you need to move this post to the sssd mailing list, you seem to have tried everything possible, so could it be a problem with the Ubuntu sssd package itself ?
Rowland
Thanks everyone for their patience. Steve
On Wed, May 21, 2014 at 11:54:03AM +0200, steve wrote:
Hi We've exhausted all the possibilities over on the samba list and think we have a bug with the Lubuntu version of 1.11.5 against a Samba4 DC. We have 1.11.5 ddns working perfectly against the same DC and nsupdate works fine from the failing lubuntu laptop. I hope you don't mind in me quoting from the samba lists below. Any help would be most gratefully received:
I see you tried nsupdate with the Administrator account, but does it work with the machine account as well?
On 21/05/14 12:16, Jakub Hrozek wrote:
On Wed, May 21, 2014 at 11:54:03AM +0200, steve wrote:
Hi We've exhausted all the possibilities over on the samba list and think we have a bug with the Lubuntu version of 1.11.5 against a Samba4 DC. We have 1.11.5 ddns working perfectly against the same DC and nsupdate works fine from the failing lubuntu laptop. I hope you don't mind in me quoting from the samba lists below. Any help would be most gratefully received:
I see you tried nsupdate with the Administrator account, but does it work with the machine account as well?
Yes:
steve@lubuntu-laptop:/tmp$ sudo kinit -kt /etc/krb5.keytab LUBUNTU-LAPTOP$ [sudo] password for steve:
steve@lubuntu-laptop:~$ sudo klist [sudo] password for steve: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: LUBUNTU-LAPTOP$@HH3.SITE
Valid starting Expires Service principal 21/05/14 12:19:54 21/05/14 22:19:54 krbtgt/HH3.SITE@HH3.SITE renew until 22/05/14 12:19:54
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39621 ;; flags: qr aa ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;lubuntu-laptop.hh3.site. IN SOA
;; AUTHORITY SECTION: hh3.site. 0 IN SOA hh16.hh3.site. hostmaster.hh3.site. 805 900 600 86400 0
Found zone name: hh3.site The master is: hh16.hh3.site start_gssrequest send_gssrequest Outgoing update query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56505 ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;359059288.sig-hh16.hh3.site. ANY TKEY
;; ADDITIONAL SECTION: 359059288.sig-hh16.hh3.site. 0 ANY TKEY gss-tsig. 1400667719 1400667719 3 NOERROR 1328 YIIFLAYGKwYBBQUCoIIFIDCCBRygDTALBgkqhkiG9xIBAgKiggUJBIIF BWCCBQEGCSqGSIb3EgECAgEAboIE8DCCBOygAwIBBaEDAgEOogcDBQAg AAAAo4ID6GGCA+QwggPgoAMCAQWhChsISEgzLlNJVEWiHzAdoAMCAQGh FjAUGwNETlMbDWhoMTYuaGgzLnNpdGWjggOqMIIDpqADAgEXoQMCAQGi ggOYBIIDlLiL8nFs9p8cWni0RMsj2Ugfe2TtlWejVv9eKaHncqoxvaE+ ym7ponHzrRoam1LdKNHFu8M63srvJ/cj5LnDkIXh9N8p3Y546yUXdPGv FH9sonE/Yt6UQUcAsJlESYMqyTIMiFWDVxw+dIxai6C16j27AXCQIJ0g Jwi95pTxcbzrngDAV6am8Xt1rh6fBaiGEUa1pDyMPvy61A/MY4eEFIGa cpHTldCL2rnd7G+jLR2GHcAU3Zg9s23WCNJMO8aVjoYqFH0TxI+s/dlU Gyh9VSNbGWp81kHGGRtsvhGh4jLidCFnGP+6f1xN90O8xmzDHRvUlucm P+cYBP7NN6/TaG4Lig/X04tM3r8Cvy81VXys1mQwufsZwK54mra5tDqX xnpUMfJOLFjX4T80R+wNsI2eQw+B+kxyktDCutpjePHSHCCiJBAGywtz LWohuM2WHoZ/uAWJ0CXFjbPJVQLsEkLjYqt7TGAh/9uuVVR/0ELeV0l4 oRfnPP81AzhxI1xT5dZwvX1RC77PBDPIkZZUDRTfBTyRBsu5RcVp3KU8 LdwOjHraFdKa/NcTZopNuBpjbjZMeB6NlPjZ+1sHF1XMGcU8oYoqtQa9 LhdvMzTj8YQcGSm5P39bNrAiFMUSWHq3U2UjoIfZFGI5i5vTIzNrvTnK jek5s+IK/Ftq2uleBy7ANmSUDM7QA5nlQXy60iELtJrgLqv3sOjWYhtp UYe4cMwGwhBRp6sWkevLzJL3Z85sscbbxo2jZ3WOlkiRoReRqnSwbvet WrwoaRDAQ8id1F4uIkpCAZc7xgigL7WNxIWP9SDHu3qgCgWDCUHPQPVK dpqxC66chvrkTyh2r6jvM6vCPSzBeZMllzcr91zSS5pSmWw5CAqow4nj J85aP1LAHLHSV5336iE651vzbwZsjaIV7X7zSIx4vp3SqW7a9L4BQ9Nb ZIqgrNh/F2i2P/Wlhr4WQ4NVEaJzGTNwwWMq4rCmU6lVKJYuvPPmrxud Rkq5p1QUtrRyWnYXCoqOkfZD+IV3gT/r3rmQOe7kE+2hLvVEPCYQfoxA zK4L5UEJ+kFnTxb5uRINMTcndandftIVa19I/xADiyDukaJ1tHRVTFeX fBps6pn5FBVSRIkNrbdNimn88sVzluUN2rXp4nhFwN0rPOX2mFC9xy6G HpLMmtl6MkXlurjrDRjEdMHN3xSXuwcBz62Kxf6BeuxjaRW1y5AUUmCk geowgeegAwIBF6KB3wSB3CVaebAMoW+vTvCEVpQt5Y9Lc46T5lwgKN80 4NsoIb4NK31YETJMad9uMUHSK89JGnS4bR0m6Y0LfGmppQlMEH8vQ3i3 WJh4c9IoLMj3sp/8av/1RauU67Ids436JKWI6UJki6s9vX/jhIpd6Rku 4asp67rtTdbGgy2qE+TPeVP2Eq+knxTzauPRyf2W7mxwIG8Mop4hDvuB qVjWASN4uViGJcprh7btM21vosUIO4zOifD1I4vLzGsPctQp6CUYaw99 Q3OtszFT7MYYyiAhcezAiwSy93FJwWT22k8= 0
recvmsg reply from GSS-TSIG query ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56505 ;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;359059288.sig-hh16.hh3.site. ANY TKEY
;; ANSWER SECTION: 359059288.sig-hh16.hh3.site. 0 ANY TKEY gss-tsig. 1400667720 1400671320 3 NOERROR 182 oYGzMIGwoAMKAQChCwYJKoZIhvcSAQICooGbBIGYYIGVBgkqhkiG9xIB AgICAG+BhTCBgqADAgEFoQMCAQ+idjB0oAMCAReibQRrmG2aUzTud750 dAxBNQT7BT/drSv220n3U6ng4sjW3+MEgGOPagMSt1EwIPV0JgC1vU6I HU3GgmSJwA6Gqm/OFJ8iFB1nIsk43DqNLo8UzZyv1ZE2nA5VtI+r/Cso 17XZaklnnDkhWe0hBCg= 0
Sending update to 192.168.1.16#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 61044 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 1 ;; UPDATE SECTION: lubuntu-laptop.hh3.site. 0 ANY A lubuntu-laptop.hh3.site. 3600 IN A 192.168.1.22
;; TSIG PSEUDOSECTION: 359059288.sig-hh16.hh3.site. 0 ANY TSIG gss-tsig. 1400667720 300 28 BAQE//////8AAAAAJqqHjzxJfbqs+6sTpuxvHA== 61044 NOERROR 0
Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 61044 ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;hh3.site. IN SOA
;; TSIG PSEUDOSECTION: 359059288.sig-hh16.hh3.site. 0 ANY TSIG gss-tsig. 1400667720 300 28 BAQF//////8AAAAAMz5NEdNzQNm3fDU6PirFMA== 61044 NOERROR 0
quit
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for
server
DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for
This is not going to work. It seem the DNS server your client is attached to is sending back bogus NS information ?
Simo.
On 21/05/14 12:18, Simo Sorce wrote:
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for
server
DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for
This is not going to work. It seem the DNS server your client is attached to is sending back bogus NS information ?
Simo.
So why does nsupdate work but sssd doesn't? Cheers, Steve
On Wed, 2014-05-21 at 12:28 +0200, steve wrote:
On 21/05/14 12:18, Simo Sorce wrote:
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for
server
DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for
This is not going to work. It seem the DNS server your client is attached to is sending back bogus NS information ?
Simo.
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
On Wed, 2014-05-21 at 12:02 -0400, Simo Sorce wrote:
On Wed, 2014-05-21 at 12:28 +0200, steve wrote:
On 21/05/14 12:18, Simo Sorce wrote:
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from > ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE > [canonicalize, renewable] > Kerberos: Searching referral for a.root-servers.net > Kerberos: Returning a referral to realm ROOT-SERVERS.NET for
server
> DNS/a.root-servers.net@HH3.SITE that was not found > Failed find a single entry for
This is not going to work. It seem the DNS server your client is attached to is sending back bogus NS information ?
Simo.
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
Ah just saw this in your other reply:
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
So I guess the trick is finding out what sssd puts in the 'server' field, I suspect it puts the AD DC name, and then nsupdate somehow has issues resolving which DNS server that refers to ..
If you raise the SSSD debug level to include SSSDBG_TRACE_FUNC messages you should see a dump of the generated nsupdate msg file. Then you can use it manually with nsupdate to find out what breaks in your setup.
simo.
On 21/05/14 18:16, Simo Sorce wrote:
On Wed, 2014-05-21 at 12:02 -0400, Simo Sorce wrote:
On Wed, 2014-05-21 at 12:28 +0200, steve wrote:
On 21/05/14 12:18, Simo Sorce wrote:
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from >> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net@HH3.SITE >> [canonicalize, renewable] >> Kerberos: Searching referral for a.root-servers.net >> Kerberos: Returning a referral to realm ROOT-SERVERS.NET for
server
>> DNS/a.root-servers.net@HH3.SITE that was not found >> Failed find a single entry for
This is not going to work. It seem the DNS server your client is attached to is sending back bogus NS information ?
Simo.
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
Ah just saw this in your other reply:
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
So I guess the trick is finding out what sssd puts in the 'server' field, I suspect it puts the AD DC name, and then nsupdate somehow has issues resolving which DNS server that refers to ..
If you raise the SSSD debug level to include SSSDBG_TRACE_FUNC messages you should see a dump of the generated nsupdate msg file. Then you can use it manually with nsupdate to find out what breaks in your setup.
simo.
Hi OK. How do I 'include SSSDBG_TRACE_FUNC messages'?
The thing is that 1.11.5 works fine with our openSUSE clients but not with the package which comes with Ubuntu 14.04. Anyway, we would like to know why. Thanks. Steve
On Wed, May 21, 2014 at 09:07:23PM +0200, steve wrote:
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
Ah just saw this in your other reply:
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
So I guess the trick is finding out what sssd puts in the 'server' field, I suspect it puts the AD DC name, and then nsupdate somehow has issues resolving which DNS server that refers to ..
If you raise the SSSD debug level to include SSSDBG_TRACE_FUNC messages you should see a dump of the generated nsupdate msg file. Then you can use it manually with nsupdate to find out what breaks in your setup.
simo.
Hi OK. How do I 'include SSSDBG_TRACE_FUNC messages'?
The thing is that 1.11.5 works fine with our openSUSE clients but not with the package which comes with Ubuntu 14.04. Anyway, we would like to know why. Thanks. Steve
Put debug_level=7 (or higher, up to 10) to the [domain] section of the sssd.conf and run the test case again.
The logs should then include the full nsupdate message.
Also, did you kinit as the same principal the SSSD uses? Typically we'd use shortname$@realm. That should be visible from the logs as well.
On 21/05/14 22:14, Jakub Hrozek wrote:
On Wed, May 21, 2014 at 09:07:23PM +0200, steve wrote:
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
Ah just saw this in your other reply:
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
So I guess the trick is finding out what sssd puts in the 'server' field, I suspect it puts the AD DC name, and then nsupdate somehow has issues resolving which DNS server that refers to ..
If you raise the SSSD debug level to include SSSDBG_TRACE_FUNC messages you should see a dump of the generated nsupdate msg file. Then you can use it manually with nsupdate to find out what breaks in your setup.
simo.
Hi OK. How do I 'include SSSDBG_TRACE_FUNC messages'?
The thing is that 1.11.5 works fine with our openSUSE clients but not with the package which comes with Ubuntu 14.04. Anyway, we would like to know why. Thanks. Steve
Put debug_level=7 (or higher, up to 10) to the [domain] section of the sssd.conf and run the test case again.
The logs should then include the full nsupdate message.
Also, did you kinit as the same principal the SSSD uses? Typically we'd use shortname$@realm. That should be visible from the logs as well.
Hi sssd sends:
update add lubuntu-laptop. 3600 in A 192.168.1.22 this fails with the short hostname, dot or no dot.
It works with nsupdate manually only with the fqdn: update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22
Can we get sssd to send the fqdn rather than the short hostname? Cheers, Steve
On 22/05/14 12:37, steve wrote:
On 21/05/14 22:14, Jakub Hrozek wrote:
On Wed, May 21, 2014 at 09:07:23PM +0200, steve wrote:
So why does nsupdate work but sssd doesn't?
Can you show me how do you invoke nsupdate manually ? (sssd just invokes nsupate itself, so it must be some difference in the command file I guess).
Simo.
Ah just saw this in your other reply:
steve@lubuntu-laptop:/tmp$ nsupdate -g -d
server 192.168.1.16 realm HH3.SITE update delete lubuntu-laptop.hh3.site 3600 A update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22 send
So I guess the trick is finding out what sssd puts in the 'server' field, I suspect it puts the AD DC name, and then nsupdate somehow has issues resolving which DNS server that refers to ..
If you raise the SSSD debug level to include SSSDBG_TRACE_FUNC messages you should see a dump of the generated nsupdate msg file. Then you can use it manually with nsupdate to find out what breaks in your setup.
simo.
Hi OK. How do I 'include SSSDBG_TRACE_FUNC messages'?
The thing is that 1.11.5 works fine with our openSUSE clients but not with the package which comes with Ubuntu 14.04. Anyway, we would like to know why. Thanks. Steve
Put debug_level=7 (or higher, up to 10) to the [domain] section of the sssd.conf and run the test case again.
The logs should then include the full nsupdate message.
Also, did you kinit as the same principal the SSSD uses? Typically we'd use shortname$@realm. That should be visible from the logs as well.
Hi sssd sends:
update add lubuntu-laptop. 3600 in A 192.168.1.22 this fails with the short hostname, dot or no dot.
It works with nsupdate manually only with the fqdn: update add lubuntu-laptop.hh3.site 3600 A 192.168.1.22
Can we get sssd to send the fqdn rather than the short hostname? Cheers, Steve
(Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]]
[nsupdate_msg_create_common] (0x0200): Creating update message for realm [HH3.SITE]. (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm HH3.SITE update delete lubuntu-laptop. in A send update delete lubuntu-laptop. in AAAA send update add lubuntu-laptop. 3600 in A 192.168.1.22 send (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [be_nsupdate_create_fwd_msg] (0x0400): -- End nsupdate message -- (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [sdap_get_generic_ext_done] (0x0400): (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [be_nsupdate_args] (0x0200): Search result: Success(0), no errmsg set nsupdate auth type: GSS-TSIG (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [ad_subdomains_get_slave_domain_done] (0x1000): There are no changes (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu May 22 12:18:20 2014) [sssd[be[hh3.site]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server not found in Kerberos database. (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [child_sig_handler] (0x1000): Waiting for child [3529]. (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [child_sig_handler] (0x0020): child [3529] failed with status [1]. (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [sdap_dyndns_update_done] (0x0080): nsupdate failed, retrying with server name (Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [hh16.hh3.site] and realm [HH3.SITE] .(Thu May 22 12:18:21 2014) [sssd[be[hh3.site]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- server hh16.hh3.site realm HH3.SITE update delete lubuntu-laptop. in A send update delete lubuntu-laptop. in AAAA send update add lubuntu-laptop. 3600 in A 192.168.1.22 send
here is the DC: ] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:50954 for DNS/a.root-servers.net@HH3.SITE [canonicalize, renewable] Kerberos: Searching referral for a.root-servers.net Kerberos: Returning a referral to realm ROOT-SERVERS.NET for server DNS/a.root-servers.net@HH3.SITE that was not found Failed find a single entry for (&(objectClass=trustedDomain)(|(flatname=ROOT-SERVERS.NET)(trustPartner=ROOT-SERVERS.NET))): got 0 Kerberos: samba_kdc_fetch: could not find principal in DB Kerberos: Server not found in database: krbtgt/ROOT-SERVERS.NET@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:50954 Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from ipv4:192.168.1.22:50955 for DNS/a.root-servers.net@HH3.SITE [renewable] Kerberos: Server not found in database: DNS/a.root-servers.net@HH3.SITE: no such entry found in hdb Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:50955
On 22/05/14 12:41, steve wrote:
On 22/05/14 12:37, steve wrote:
On 21/05/14 22:14, Jakub Hrozek wrote:
On Wed, May 21, 2014 at 09:07:23PM +0200, steve wrote:
> So why does nsupdate work but sssd doesn't?
OK, Fixed it, but we don't like it: /etc/hostname has to contain the fqdn, not the hostname. So now, hostname is wrong but hostname -s and hostname -f return correctly.
More importantly, the ddns updates go fine. However, I'm sure that'll break something else somewhere else down the line.
What is also worrying is that even with a non-updated DNS, we could still log in, reach the file server, get tickets etc.
This is only on Ubuntu 14.04. openSUSE works fine with the short hostname in /etc/hostname. Any comments? Cheers and thanks for your patience, Steve
On Thu, 22 May 2014, steve wrote:
/etc/hostname has to contain the fqdn, not the hostname. So now, hostname is wrong but hostname -s and hostname -f return correctly.
More importantly, the ddns updates go fine. However, I'm sure that'll break something else somewhere else down the line.
What is also worrying is that even with a non-updated DNS, we could still log in, reach the file server, get tickets etc.
This is only on Ubuntu 14.04. openSUSE works fine with the short hostname in /etc/hostname. Any comments?
shorthostname in /etc/hosts as the primary is wrong. fqdn should be first entry, followed by aliases.
hostname returning fqdn is correct behaviour.
jh
On 22/05/14 13:38, John Hodrien wrote:
On Thu, 22 May 2014, steve wrote:
/etc/hostname has to contain the fqdn, not the hostname. So now, hostname is wrong but hostname -s and hostname -f return correctly.
More importantly, the ddns updates go fine. However, I'm sure that'll break something else somewhere else down the line.
What is also worrying is that even with a non-updated DNS, we could still log in, reach the file server, get tickets etc.
This is only on Ubuntu 14.04. openSUSE works fine with the short hostname in /etc/hostname. Any comments?
shorthostname in /etc/hosts as the primary is wrong. fqdn should be first entry, followed by aliases.
hostname returning fqdn is correct behaviour.
jh
Not on Ubuntu it isn't ;-)
hostname clientname
hostname -f clientname.domain.tld
hostname -s clientname
hostname -d domain.tld
Rowland
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
On 22/05/14 13:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
Thats all very well for a machine with a fixed ip but what about DHCP ?
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
Yes, that is what Ubuntu does out of the box, but without the domain name in /etc/hosts, hostname & hostname -f just returns the short-hostname.
Rowland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/22/2014 08:55 AM, Rowland Penny wrote:
On 22/05/14 13:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
Thats all very well for a machine with a fixed ip but what about DHCP ?
Well, once they adopt systemd, they'll get to start using hosts: files dns myhostname
This properly populates gethostby*() with the appropriate values from DHCP.
On 22/05/14 14:06, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/22/2014 08:55 AM, Rowland Penny wrote:
On 22/05/14 13:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
Thats all very well for a machine with a fixed ip but what about DHCP ?
Well, once they adopt systemd, they'll get to start using hosts: files dns myhostname
OK, 'files dns' I understand but 'myhostname' ? I think that means that DHCP will store the machines identity in a file somewhere, is this correct and if so where ?
Rowland
This properly populates gethostby*() with the appropriate values from DHCP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN99kMACgkQeiVVYja6o6M0RgCgjIrcRxplNbuEP07EPvPy9ucu FF4An1xeW/58DI+8WEG+J9lcrLx7bDEV =4BYY -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/22/2014 09:28 AM, Rowland Penny wrote:
On 22/05/14 14:06, Stephen Gallagher wrote: On 05/22/2014 08:55 AM, Rowland Penny wrote:
On 22/05/14 13:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
Thats all very well for a machine with a fixed ip but what about DHCP ?
Well, once they adopt systemd, they'll get to start using hosts: files dns myhostname
OK, 'files dns' I understand but 'myhostname' ? I think that means that DHCP will store the machines identity in a file somewhere, is this correct and if so where ?
myhostname is a name-service module that just asks systemd to tell it what IP addresses the system has and what the system's hostname is supposed to be. Then it "magically" returns all the correct and up-to-the-minute information.
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
and /etc/hostname has fqdn only Putting _anything_ else in /etc/hostname gives 'can't resolve' errors: sudo: imposible resolver el anfitrión lubuntu-laptop.hh3.site lubuntu-laptop (Spanish: 'impossible to resolve host resolve host fqdn hostname'
That is with: /etc/hostname containing: fqdn hostname
On Thu, 2014-05-22 at 15:05 +0200, steve wrote:
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
and /etc/hostname has fqdn only Putting _anything_ else in /etc/hostname gives 'can't resolve' errors: sudo: imposible resolver el anfitrión lubuntu-laptop.hh3.site lubuntu-laptop (Spanish: 'impossible to resolve host resolve host fqdn hostname'
That is with: /etc/hostname containing: fqdn hostname
If you have to keep the short hostname in the system you can configure sssd to use ipa_hostname (for ipa provider) or ad_hostname (for ad provider) and put there whatever you want.
That string will be used instead of performing a gethostname() call. It *should* work with all parts of sssd, if it doesn't please open a bug.
Simo.
On 22/05/14 14:05, steve wrote:
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
127.0.0.1 is ipv4 for 'localhost' so try changing it to this:
127.0.0.1 localhost.localdomain localhost 127.0.1.1 fqdn hostname
Rowland
and /etc/hostname has fqdn only Putting _anything_ else in /etc/hostname gives 'can't resolve' errors: sudo: imposible resolver el anfitrión lubuntu-laptop.hh3.site lubuntu-laptop (Spanish: 'impossible to resolve host resolve host fqdn hostname'
That is with: /etc/hostname containing: fqdn hostname
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 22/05/14 15:10, Rowland Penny wrote:
On 22/05/14 14:05, steve wrote:
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
127.0.0.1 is ipv4 for 'localhost' so try changing it to this:
127.0.0.1 localhost.localdomain localhost 127.0.1.1 fqdn hostname
Yes, that's fine. But only with fqdn in /etc/hostname
On 22/05/14 14:18, steve wrote:
On 22/05/14 15:10, Rowland Penny wrote:
On 22/05/14 14:05, steve wrote:
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
127.0.0.1 is ipv4 for 'localhost' so try changing it to this:
127.0.0.1 localhost.localdomain localhost 127.0.1.1 fqdn hostname
Yes, that's fine. But only with fqdn in /etc/hostname
This works for me with Linux Mint 15 aka Ubuntu 13.04, what version of lubuntu are you using?
Rowland
On 22/05/14 15:23, Rowland Penny wrote:
On 22/05/14 14:18, steve wrote:
On 22/05/14 15:10, Rowland Penny wrote:
On 22/05/14 14:05, steve wrote:
On 22/05/14 14:50, John Hodrien wrote:
On Thu, 22 May 2014, Rowland Penny wrote:
Not on Ubuntu it isn't ;-)
I'd argue that Ubuntu just has incorrect behaviour then.
If you look at man hosts on an ubuntu machine (13.10), you'll see how they describe it, and the example they provide. The format described is:
IP_address canonical_hostname [aliases...]
The example is:
127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo 192.168.1.13 bar.mydomain.org bar
That's the correct format, whether or not Ubuntu applies it.
That said, the only machine I have with ubuntu defined a hosts file with:
127.0.1.1 short-ubuntu-13.10 short-ubuntu-13
That, in a slightly unpleasant way, follows the way I'd do it.
jh
How do you send the fqdn with dhcp then?
we have: 127.0.0.1 fqdn hostname localhost
127.0.0.1 is ipv4 for 'localhost' so try changing it to this:
127.0.0.1 localhost.localdomain localhost 127.0.1.1 fqdn hostname
Yes, that's fine. But only with fqdn in /etc/hostname
This works for me with Linux Mint 15 aka Ubuntu 13.04, what version of lubuntu are you using?
14.04 And it's really fast.
On 22/05/14 14:43, Rowland Penny wrote:
@Rowland Sorry to trouble. We've messed up nsswitch Can you send your working version of: hosts: files mdns_minimal [NOTFOUND=return] dns or whatever is the right answer? Our line is working but several of us have left commented rubbish there. Cheers, Steve
On 22/05/14 14:28, steve wrote:
On 22/05/14 14:43, Rowland Penny wrote:
@Rowland Sorry to trouble. We've messed up nsswitch Can you send your working version of: hosts: files mdns_minimal [NOTFOUND=return] dns or whatever is the right answer? Our line is working but several of us have left commented rubbish there. Cheers, Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK
cat /etc/nsswitch.conf # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file.
passwd: compat sss winbind group: compat sss winbind
shadow: compat
#hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 hosts: files dns networks: files
protocols: db files services: db files ethers: db files rpc: db files
netgroup: nis sss automount: sss
sudoers: files sss
This is what is on my laptop ;-)
Rowland
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Rowland Penny -
Simo Sorce -
Stephen Gallagher -
steve