On 2017-09-20 11:15, Martin Gregorie wrote: > I don't know why you'd want to do that since you should be running > named instead of dnsmasq. > > Delete the version you just installed via the apt package manager and > do a search and destroy mission to get rid of both the other copy of > it and the associated configuration. > > Running "updatedb; locate dnsmasq" is probably the fastest way of > finding it and its associated files. Anything with a similar name in > /etc/init.d is probably its launcher script, so that can go too. If > you have an /etc/rc.local file, check its contents because its run as > part of the sysVinit process. It shouldn't have anything about dnsmasq > in it but you never know...
Another thing to check in this kind of mess (and I think it wasn't mentioned yet) is the state of /etc/resolv.conf. In Debian (and so in Ubuntu, too) packages that provide DNS daemons, whether authoritative or caching only, attempt to manage that file automatically, if the resolvconf (traditionally) or openresolv package is also installed. If you do something "unexpected" you can end up with /etc/resolv.conf in a strange state. To avoid that, on my Debian hosts I usually purge resolvconf/openresolv, make sure that /etc/resolv.conf is a real file (not a symlink), and manually edit it to the correct state. If the host is on DHCP I also make sure the ISC DHCP client is in use (not dhcpcd which seems to be much less flexible), and change /etc/dhcp/dhclient.conf to not request (or override) the DNS info provided by DHCP, as that also messes with resolv.conf. Finally (and getting really OT), it helps to keep relevant /etc files under version control, so you know when the system helpfully shifts the ground under you. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
