-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/01/2012 02:19 AM, Angus Gratton wrote: > On Mon, 30 Apr 2012 09:58:04 +0200 Stéphane Graber > <stgra...@stgraber.org> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 04/30/2012 09:22 AM, Angus Gratton wrote: >>> On Mon, 30 Apr 2012 16:15:49 +1000 Angus Gratton >>> <g...@projectgus.com> wrote: >>> >>>> Hi everyone, >>>> >>>> I'm a long-time LTSP user and fan. I recently decided to >>>> upgrade our work LTSP system to 12.04 LTS, especially enticed >>>> by promises of improved fat clients in 5.3. >>> >>> One other little thing I noticed, in the generated image >>> >>> /etc/resolvconf/resolv.conf.d/tail is symlinked to >>> /etc/resolvconf/resolv.conf.d/original. >> >> That's indeed the new behavior in 12.04 (not only LTSP), although >> it may affect your ability to do DNS queries when chrooting into >> /opt/ltsp/i386, it shouldn't affect an actual thin client as >> /etc/resolv.conf will be re-generated with the DNS servers >> received from DHCP at boot time. >> http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ >> > > Hi Stéphane, > > That's not quite the behaviour I'm getting, at least in the fat > clients. > > On my server, my resolvconf looks like this: > > :/etc/resolvconf/resolv.conf.d $ ls -la drwxr-xr-x 2 root root 4096 > Apr 27 15:04 . drwxr-xr-x 5 root root 4096 Apr 27 15:04 .. > -rw-r--r-- 1 root root 0 Aug 9 2006 base -rw-r--r-- 1 root > root 151 Aug 9 2006 head -rw-r--r-- 1 root root 125 Nov 3 > 2010 original -rw-r--r-- 1 root root 0 Nov 3 2010 tail > > > And my generated server /etc/resolv.conf looks like this: > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES > WILL BE OVERWRITTEN nameserver 127.0.0.1 search mydomain > > > On a brand new fat-client chroot, it looks like this: > > :/etc/resolvconf/resolv.conf.d# ls -la drwxr-xr-x 2 root root 4096 > May 1 08:51 . drwxr-xr-x 5 root root 4096 May 1 09:11 .. > -rw-r--r-- 1 root root 0 Mar 30 07:37 base -rw-r--r-- 1 root > root 151 Mar 30 07:37 head -rw-r--r-- 1 root root 204 May 1 > 08:49 original lrwxrwxrwx 1 root root 8 May 1 08:51 tail -> > original > > (Note symlink back to "original" /etc/resolv.conf from server) > > > ... so then when I boot the fat client, resolvconf generates this > at boot time: > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES > WILL BE OVERWRITTEN nameserver 172.16.0.1 search mydomain # Dynamic > resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES > WILL BE OVERWRITTEN nameserver 127.0.0.1 search mydomain > > > ... the first part comes from DHCP and the second part comes from > "tail -> original". DNS doesn't work with this resolv.conf. > > There are two possible easy fixes for me to make: > > - Change the server to refer to its network address (172.16.0.1) > not localhost address for DNS, so I get matching duplicate > entries. > > - Remove the 'tail' symlink to original and replace it with a > zero-length file in the image, so I just get the values set by > DHCP (this seems more correct.) > > > So, this definitely might boil down to a bad server configuration > on my part, but I thought I'd explain it anyhow. > > Cheers, > > - Angus
I don't see anything wrong with the config generate on the thin client. Sure we certainly could and should remove the tail -> original symlink from the chroot so that the second section of your resolv.conf disappears. However the libc resolver always uses the first server it finds in resolv.conf, so in your case it'll still be using 172.16.0.1 which from what you said above, sounds like the right thing to use. That's obviously assuming that 172.16.0.1 is indeed a valid DNS server, if it's not, then update your /etc/ltsp/dhcpd.conf to contain a valid DNS server, restart isc-dhcp-server, reboot your thin client and you should be good. The dnsmasq you have running on 127.0.0.1 on your server is the local resolver spawned by Network Manager, this resolver isn't meant to be used from external clients, which is why it only listens on the loopback interface. - -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPn5xgAAoJEMY4l01keS1nLJAQAJmxfwU4h8QyXFqHX7Tx6CJW IdahJzOsk3MNdbhWtalU7gsQA5Rwt6zJUd51UZ1sr3hoNc1bMa/yCUvDF49kbP02 KH4hZPJjfleeOiHEVN1K1FI0IWeyWUNfCGTxzeph3dEWTOC2yOuljk1egsDF0HhK c6tHzngXEz97CYsGcqzcA0cA2MLf4ReqG1VKvyEkGmYmoUxqN+2XOv5ym6QINo+8 4PDcXyJqQTN9OZthMeF/phCxWYzeIOr6r59Jp2rRK7GnKZFt3u+epgtoJRf8iYMb mvaWrAzws3yCXhB8pkwu1dc5JRGG5eZt7sHVjWJ8//ogsB1kntvJ/j+Sb8KdbEUp Bx0OUpkOMxUTIeSd91I4WdtyO5FKhORnYWmVVvJizcja5HzG9MFuvU9eCTdbMUNE ttxrFR3rP3bEUBq+YgrbZM+7iUV2l1SuPtAqCED3FXKIQl0j+hUaD5KDnV3Q6fH6 vWXTlBtZMqr43sNq9xfuoYmjVNN1+gMSO3XgruPzc0oPQg8/syuHt8NMoEy2swRC 3zkQ9EyM7MsgRsIqjz5o6maaFR0pVdnNetBy2+4b80sgDckvEisWGhttxvN7nF8L D1x/U2aU/KoUl7OZhohgC1ETEqItyaAwMJ9zLQKc50Ye9Ey9R5PFylSF4qIuw0G+ CKMzHL9tMIS6P6oTMaWa =LCTU -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
