Fixing privileges to mount USB Keys with polkit

After switching to Devuan, I got suddenly dolphin complaining that it cannot mount an USB Key. Since Devuan is back to polkit to get rid of systemd (but polkit is probably part of the problem too), the fix is to add a /etc/polkit-1/localauthority/50-local.d/auto-mount.pkla with:

[Allow Automount]

And make sure users belong to plugdev.

Providing different DNS records (spoofed or not) depending on the client with Bind9

I did some major changes to my local server Bind9 setup. I was at the begin caching apt and steam depots on this server using dnsspoof from dsniff. After a few upgrades dnsspoof started to do nothing: it was up, on the proper device, noticing requests relevant to be spoofed but the end clients were still getting the real DNS records, not the spoofed ones.

So, I eventually decided to use directly Bind9, already up as a cache server, to do the spoofing.

Good, except that then nginx, running on the same server as Bind9, then required another resolver than Bind9 in order to get the real DNS records, since Bind9 was replying spoofed crap.

Bind9 is fully featured and I found that the easier way to get it do gives tailored replies depending on the clients is to use the views. But using views implies that every zones are included into views. You cannot just add a “view” for a given purpose and let your general setup.

A setup that should work more or less out of the box is provided with my packages -utils-cache-steam and -utils-cache-apt.

Using this, you must edit your /etc/bind/named.conf so it no longer directly include zones definition files but include the /etc/bind/named.conf.views that in turn will include relevant zones. Clients are set in /etc/bind/named.conf.acl and by default handle, and as server host (the two later are being used in my silent low energy consumption home server proposed setup).

It includes /etc/bind/ that will (re-)generate zones definition files (named.conf.cache…) depending on the services you are actually caching.

This could probably be improved (annoying to make differences between 192.168, 10.0.0 and 10.0.1…) but it works fine. You can test by pinging from the server (loopback) or any clients.

Moving away from systemd with Devuan

A while ago, I was encouraging to give a try to systemd. Well, now I know better and decided to get away from this tool that clearly wants to replace many parts of my system at once. There are many articles about systemd, why it’s good and why it’s not. I kept on open mind of the topic, I tried systemd on many boxes. Some stuff just stopped to work, or did not work as I expected it to work. Maybe I’m clueless but I’m not alone. Point is with systemd, I’m able to do less and it takes me more time.

Now devuan is installable so I installed it already on two of my boxes. So far, no problem. I wonder how Devuan will cope with bugs reports and stuff in the long run.

The process is as simple as:

# select ascii (= testing)
dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb
cd /etc/apt/sources.list.d/
# comment  debian sources
nano sources.list
apt-get install devuan-keyring
apt-get update && apt-get upgrade
apt-get --purge remove systemd systemd-shim
dpkg --list | grep systemd
apt-get --purge remove libsystemd-journal0 libsystemd-login0
apt-get --purge autoremove