In a previous note, I described how to enable DNSSEC validation on Slackware using a local resolver (Unbound) coupled to dnssec-trigger. Since then, I have modified my Slackware setup in two ways:
I installed NetworkManager using the package provided in Slackware64
14.1, and enabled it to start by setting the executable bit on
In NetworkManager’s main configuration file
/etc/NetworkManager/NetworkManager.conf, I hade to change
the following line
to have NetworkManager use dhclient instead of dhcpcd to perform DHCP auto-configuration. I found that using dhcpcd led to some weird problems when connecting to a dual IPv4/IPv6 nework—notably, some variables supposed to be set in the environment of NetworkManager’s hook scripts were not set when using dhcpcd.
Then, I reseted Slackware’s
/etc/rc.d/rc.inet1 script does not activate any
network interface, in order to let NetworkManager do its job.
From that moment on, the only task of the
/etc/rc.d/rc.inet1 script is to activate the loopback
interface. It would thus be possible to get rid of that script
completely and replace it by a much simpler script which would do only
With NetworkManager up and running, I used nm-applet, the NetworkManager, to actually configure the network connections.
Getting NetworkManager to work with Unbound as a local resolver caused one little problem.
Upon establishing a connection, NetworkManager attempts to fill the
/etc/resolv.conf file with the nameservers that it deems
appropriate for the network it just connected to (in general, the
nameservers that were indicated in the DHCP reply). But on my system,
that file should always contain nothing else than the following
so that all name resolution requests always go to the local resolver
Unbound. Unfortunately, as far as I can tell NetworkManager does not
provide any configuration option to prevent it from always overwriting
The simplest method to overcome that problem is to set the
immutable attribute on the
# chattr +i /etc/resolv.conf
so that the file cannot be overwritten. It works, although NetworkManager will regularly complain in its log that it failed to “update the DNS configuration”—that’s the desired effect.
However, a cleaner method in my opinion is to inform NetworkManager
that there is a local resolver around and that
/etc/resolv.conf should point to it. For that,
NetworkManager has the concept of “DNS plugins”, which it can use to
interact with a local resolver. As of NetworkManager-0.9.8.8, the only
available DNS plugin is nm-dns-dnsmasq, allowing NetworkManager
to interact with Dnsmasq.
I patched NetworkManager to add a new DNS plugin called
nm-dns-none. It is a “dummy” plugin that really does nothing,
apart from telling NetworkManager that a local resolver is present, thus
leading NetworkManager to write
nameserver 127.0.0.1 in the
NetworkManager-0.9.8.8-dns-plugin-none.patch (text/x-diff, 5.6K)
Once applied, the patch will have no effect unless the plugin is specifically activated by putting the following line in NetworkManager’s configuration file:
UPDATE (2014/12/21): NetworkManager 1.0.0, released
on December 19th, 2014, already includes a similar mechanism
(using the same
dns=none syntax) and the above patch is
thus no longer necessary.
Before switching to NetworkManager, I used to have my DHCP client run a custom script after establishing a connection. This script configured the NTP client, mounted remote filesystems, and performed some other tasks depending on the network my laptop was connected to.
NetworkManager allows to run the same kind of hook scripts, if they
are stored in
a dhcpcd script into a NetworkManager script is straightforward, but
NetworkManager does not allow one of its script to run for more than
about 3 seconds before killing it. Consequently: