Comment 12 for bug 959037

Revision history for this message
Alkis Georgopoulos (alkisg) wrote : Re: Don't start local resolver if a DNS server is installed

Hi Mathieu,

> If you're installing dnsmasq on top of the standard desktop install, why is it such an issue to edit the NetworkManager configuration to cater it to your needs?
> except-interface=lo may be a good idea here to avoid listening on the loopback interface

It's not about me; it's that the default dnsmasq/bind installations are now broken on desktop installations.
For the needs of our schools here in every LTS release we're making repositories with custom packages for automated installation + configuration, so the nm configuration editing is just a sed away, much less trouble than even reporting the bug in the first place.

> Wouldn't it make sense it this case to go further steps and make sure the network connection is setup in /etc/network/interfaces rather than NM, to ensure you don't suddenly get a different IP address from DHCP?

No, network manager supports static IPs (even though we don't always need them even on LTSP servers) and doing it without /etc/network/interfaces allows teachers to see the network status from the nm applet.

> and setting up a special upstart job to spawn a local resolver won't work (NM spawns it itself, using a custom configuration on purpose).

Right, that's why I'm saying that the local resolver implementation is immature, it doesn't integrate with the rest of the distro, but it breaks other packages by launching a DNS server from hardcoded C code instead of a regular sysvinit/upstart script like all the other daemons.

> I guess a workable solution would be to check for /etc/default/dnsmasq and not spawn dnsmasq if the value of ENABLED is 1.

That would indeed be workable, please do implement it.

> listen-address probably shouldn't contain 127.0.0.1 if dnsmasq is meant to be used to resolve things for ltsp clients

Thin client sessions run on the server, and would be resolved from the nm-spawned dnsmasq instance without caching, while LTSP fat client sessions would be resolved from the normal dnsmasq instance with caching.
Having one DNS server for half of the clients and another for the other half is bound to cause confusion and problems.

Anyway, I think I've made my point, if it's too difficult to do for Precise just postpone it until the next release. To workaround the problem for Greek schools I'll make an ltsp-server-dnsmasq package and sed the nm configuration in its postinst.

Cheers,
Alkis