You realize that your hardware is getting old the second time you go to boot one of your desktop computers and the BIOS's settings are reset again like the day before, and you figure out it happens because the computer motherboard's CMOS battery cell is depleted.
Looking at the bright side, this PC is so old that is not tainted by Intel's differently named backdoor tool1, so I can blissfully ignore their latest security advisory2.
I suppose for marketing reasons, it's called with various acronyms: ME, ISM, AMT, vPro ↩
Recently I've found out that lighttpd doesn't start and bails out with an error if it can't find its log file.
The backstory is that my home NAS uses an Intel Z-U130 USB SSD as the system disk1 and unfortunately it's tragically slow, especially writing data. According to Intel documentation the write speed is rated at 24 GiB/s, I've never bothered to measure it but it feels way slower.
Anyway, to offset the subjective slow write speed and somewhat extend the lifespan of the device, I decided to mount /tmp and /var/log to the RAM file-system.
First of all, I'm not suggesting to indiscriminately mount log files on tmpfs, the reader should evaluate the pros and the cons of such arrangement starting from considering RAM usage and clearly the ephemeral nature of log files stored on tmpfs.
Another thing that I'm not suggesting is avoiding to save the contents of /var/log during shutdown.
In my case I don't bother, so it's not a surprise that at boot time the log directory is empty and lighttpd fails to start. The fix is trivial tho, before launching the daemon the required path needs to be created.
A simple way to do it is using systemd and a sensible way to do it is appending the required actions in a local configuration file instead of modifying the service file directly. In this way changes are preserved when installing new versions of the package.
This is accomplished by creating a directory with the same name of the service, in this specific case /etc/systemd/system/lighttpd.service.d and storing inside a file ending with the .conf suffix with the required instructions.
For example local.conf will do:
[Service]
# When mounting log on tmpfs, creating the lighttpd log path
ExecStartPre=/bin/sh -c 'mkdir -p /var/log/lighttpd && chown www-data:adm /var/log/lighttpd'
As a side note, on Debian the canonical way to configure the use of tmpfs is using the /etc/defaults/tmpfs file but it looks like it's missing an option for logs. I reverted to use the mount options in the /etc/fstab file.
# log on tmpfs
tmpfs /var/log tmpfs defaults,mode=0755 0 0
tmpfs /var/log/apt tmpfs defaults,mode=0755 0 0
To the astute reader it would be clear that this post is not about how to use lighttpd with log mounted as tmpfs but more as a example to a proper way to do it with systemd, as I can probably find half a dozen different ways to do it.
A friend, after reading a draft of this post, invited me to enumerate at least 6 different ways to do it.
OK, let's see:
editing rc.local
putting a script in /etc/init.d
using a shell helper/trampoline script
exploiting cron (gnu cron has a @reboot directive)
using overlayfs 2
modifying the source
Mic drop.
Picking up the mic from the floor: apparently, the proper way to fix it with systemd3 is to create a file in /etc/tmpfiles.d directory with the necessary parameters. In this case this is the content of my lighttpd-log.conf file:
D /var/log/lighttpd/ 0755 www-data adm
The details are explained on the freedesktop.org site.
Mic drop again.
Some time ago I started to have a feeling that the time required to move files using Wi-Fi between my NAS and PCs has increased. About this, I noticed that the reported wireless link speed of my systems was 145 Mbit/s but I was reasonably sure that in the past that value was 300 Mbit/s.
My access point is a relatively old TP-Link model that runs a somewhat recent version of OpenWRT that I compiled and flashed, so yes, to the aficionado reader this may resemble my typical tinkering scenario, only this time I didn't touched the thing for a year or more.
According to the OpenWRT's Atheros chip-set documentation, for 802.11n the /etc/config/wireless configuration file looks correct:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
option channel 'auto'
option htmode 'HT40'
option txpower '15'
option country 'IT'
So 802.11n is basically 802.11g plus HT 1 mode with 40 MHz channel width, but strangely all the NICs in my home were connecting using only a width of 20 MHz.
Until yesterday I was unaware that there is a part of the 802.11 protocol that it's called "20/40 coexistence" or "good neighbor policy", so in few words, when a different AC is found, to avoid contemption of the Wi-Fi media, the channel's width is kept at 20 instead of 40 MHz.
I suppose, in the past few months, one or more of my neighbors has added or changed a Wi-Fi router and now my AC is correctly occupying less bandwidth.
I wanted to confirm it was really the case, and yes, using the OpenWRT's noscan option and a throughput test with iperf3 confirmed it's the presence of nearby ACs that reduces my wireless link speed.
Unfortunately the noscan is not a reasonable option2 as I can force the larger channel size but I still can't avoid contemption3 with the other ACs, so it looks like I need to move to the 5 GHz band and, with the occasion upgrade to 802.11.ac, with all the considerations that this imply.