4:54 a.m.
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$(a)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$(a)HH3.SITE from
>> ipv4:192.168.1.22:40240 for ldap/hh16.hh3.site(a)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$(a)HH3.SITE from
>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net(a)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(a)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(a)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$(a)HH3.SITE from
>> ipv4:192.168.1.22:40242 for DNS/a.root-servers.net(a)HH3.SITE [renewable]
>> Kerberos: Server not found in database:
>> DNS/a.root-servers.net(a)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$(a)HH3.SITE from
>> ipv4:192.168.1.22:40243 for DNS/a.root-servers.net(a)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(a)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(a)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$(a)HH3.SITE from
>> ipv4:192.168.1.22:40244 for DNS/a.root-servers.net(a)HH3.SITE [renewable]
>> Kerberos: Server not found in database:
>> DNS/a.root-servers.net(a)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(a)HH3.SITE from ipv4:192.168.1.22:35207
for
krbtgt/HH3.SITE(a)HH3.SITE
Kerberos: Client sent patypes: 149
Kerberos: Looking for PKINIT pa-data -- Administrator(a)HH3.SITE
Kerberos: Looking for ENC-TS pa-data -- Administrator(a)HH3.SITE
Kerberos: No preauth found, returning PREAUTH-REQUIRED --
Administrator(a)HH3.SITE
Kerberos: AS-REQ Administrator(a)HH3.SITE from ipv4:192.168.1.22:60295
for krbtgt/HH3.SITE(a)HH3.SITE
Kerberos: Client sent patypes: encrypted-timestamp, 149
Kerberos: Looking for PKINIT pa-data -- Administrator(a)HH3.SITE
Kerberos: Looking for ENC-TS pa-data -- Administrator(a)HH3.SITE
Kerberos: ENC-TS Pre-authentication succeeded --
Administrator(a)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(a)HH3.SITE from ipv4:192.168.1.22:57157
for
DNS/hh16.hh3.site(a)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\(a)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\(a)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\(a)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\(a)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
5:16 a.m.
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?
5:18 a.m.
On Wed, 2014-05-21 at 11:54 +0200, steve wrote:
>>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$(a)HH3.SITE from
>>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net(a)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(a)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.
--
Simo Sorce * Red Hat, Inc * New York
5:28 a.m.
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$(a)HH3.SITE from
> >>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net(a)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(a)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
5:28 a.m.
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$(a)HH3.SITE
Valid starting Expires Service principal
21/05/14 12:19:54 21/05/14 22:19:54 krbtgt/HH3.SITE(a)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
11:02 a.m.
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$(a)HH3.SITE from
>> >>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net(a)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(a)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.
--
Simo Sorce * Red Hat, Inc * New York
11:16 a.m.
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$(a)HH3.SITE from
> >> >>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net(a)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(a)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.
--
Simo Sorce * Red Hat, Inc * New York
2:07 p.m.
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$(a)HH3.SITE from
>>>> >>> ipv4:192.168.1.22:40241 for
DNS/a.root-servers.net(a)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(a)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
3:14 p.m.
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.
5:37 a.m.
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
5:41 a.m.
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$(a)HH3.SITE from ipv4:192.168.1.22:50954
for DNS/a.root-servers.net(a)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(a)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(a)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$(a)HH3.SITE from ipv4:192.168.1.22:50955
for DNS/a.root-servers.net(a)HH3.SITE [renewable]
Kerberos: Server not found in database: DNS/a.root-servers.net(a)HH3.SITE:
no such entry found in hdb
Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:50955
7:25 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
7:38 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
7:43 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
7:50 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner
7:55 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
8:05 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
8:06 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN99kMACgkQeiVVYja6o6M0RgCgjIrcRxplNbuEP07EPvPy9ucu
FF4An1xeW/58DI+8WEG+J9lcrLx7bDEV
=4BYY
-----END PGP SIGNATURE-----
8:10 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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.
--
Simo Sorce * Red Hat, Inc * New York
8:10 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
8:18 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
8:23 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
8:28 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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
8:28 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
8:33 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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(a)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
8:39 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
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.
8:44 a.m.
New subject: 1.11.5 ddns failure on Ubuntu 14.04 [SOLVED]
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN9/zAACgkQeiVVYja6o6P8hQCggdW2ZtWNYzS9ARsVdXhpDyvH
7+4AoIHnHW4BCv4mm+VwDZxHZuBJkrrK
=VGKa
-----END PGP SIGNATURE-----
3625
days inactive
3626
days old
sssd-users@lists.fedorahosted.org
26 comments
6 participants
participants (6)
-
Jakub Hrozek -
John Hodrien -
Rowland Penny -
Simo Sorce -
Stephen Gallagher -
steve