Back in 2015 I embarked on an ambitious plan to blog my entire way through setting up my own selfhosted email server. I got a fair bit in (5 posts) before the setting up got ahead of the blogging and I lost track of scribbled notes and halfwritten posts. Moving to a fresh Ubuntu 18.04 install I decided to move as many services as possible to containers, including my email setup and so, rather than just copy paste my old config files I dug into the basics of email setup again.
Down the drain: The elusive ‘default’ PulseAudio sink
There is no such thing as a default output device (or sink) in PulseAudio. It say so right there in the official documentation. There is something referred to as a fallback device which is used “if the stream has not been seen before”. Yet there is a configuration command called set-default-sink.
So where does that leave the user who wants a default device persistent across boots? The answer is: With a few challenges to climb, the greatest probably being insufficient documentation. Sadly people seem to prefer griping about PulseAudio to tipping in and producing good docs.
In the name of documentation (and SCIENCE!) I have tried to test a few of the availabe and potentially default-relevant PulseAudio settings ro see if I could get a surefire way for new streams to always play on the device I want them to. Here’s what I’ve come up with.
Fixing the SteelSeries Arctis 7 outputs on Ubuntu 18.04/PulseAudio 11
IMPORTANT: If you dualboot with Windows and run the Steelseries Engine software you should exercise caution when considering updating the headset firmware. Steelseries Engine version 3.2.18 introduced a new configuration of the headset that initially invalidated this fix (Thanks to Steve Brueggeman for help in making it work again). The Steelseries Engine Windows package itself is ‘safe’ to update – it’s only the headset firmware updates that may endanger the device’s working on linux.
The SteelSeries Arctis 7 headset works out of the box on linux. Sort of. You get a mono input from the mic and a mono output from the cans.
Mono output? Yup. The reason for this is that the Arctis 7 features two virtual output devices, one mono and one stereo. The headset then mixes these two channels in the hardware according to a conveniently placed mixer knob going from 100% channel 0 (mono) to 100% channel 1 (stereo). When it is working you can have two entirely different streams going to each device and mix them on the go. While there is no reason you cannot use it to have a movie playing in one channel and an opera in the other, the idea is to direct chat and phone applications (discord, Skype, etc.) to use the mono channel while everything else (including games) goes to the stereo channel. This allows you to give audio preference to the in-game footsteps coming up from behind you or idle coop chit-chat. Alas, PulseAudio only recognises the first of these two devices.
The good news is somebody has pushed a fix to the Pulseaudio git repository. The bad news is that it didn’t make it into the 11.x releases of Pulseaudio which is what is included in the spring of 2018 batch of distro releases (e.g. Ubuntu 18.04, Fedora 28).
The patch is tagged 11.99.1 which means that it will in all probability be included in version 12.0. Looking back at Ubuntu LTS releases, however, none of them ever upgraded to a major new version of Pulseaudio during their lifetime. 14.04 stays on 4.0, 16.04 stays on 8.0. So it’s probably a fool’s errand sitting around waiting for 12.0 to arrive on my new bionic install. Time for some DIY.
Note-to-self: update-manager
I don’t need a pesky GUI notifier to do updates, that’s what the command line is for.
apt-get remove update-manager removes the package containing the “Software Updater”.
Homeserver: NUC vs Raspberry Pi
I have tried at various points to write a followup to my “so what’s it like using a NUC for a homeserver/HTPC?” post. Mostly it strands on there not really being anything new to add. It works. The added workload of more applications (and maybe more traffic?) over the past two years has made it run a bit warmer and louder than it used to despite being de-dusted a couple of times. But it’s still doing it’s job. I have thrown in some docker containers and they work just fine. Run a virtual machine with kvm? Sure. As of now the main threat to it’s immortality is it’s inability to transmit 4K over HDMI. Not that I’m about to buy a 4k TV but some day, yeah?
The main thing that has kept me wondering if it is the right pick is the question: Did I splunge needlessly? Could I have gone for something cheaper without sacrificing anything? Specifically: Could a Raspberry Pi have done the job just as well?
I picked a Raspberry Pi 3 up at the post office on monday so I should finally be able to get an answer. I’m not replacing my own machine; my dad need a new home server after his Atom-powered fit-pc2 gave up the ghost. I quizzed him about his needs and found that they were fairly basic: A ‘LEP’ web server (Linux, Nginx, PHP, no MySQL) and for HTPC purposes access to the national broadcaster whether through browser or a Kodi plugin would suffice. This, I thought, had to be a good test case for picking a Pi over a full x86-based machine.
Trying out Fedora 26: No way-land?
My relationship with Fedora is of the sort where every two years I look at screenshots and go ‘Nice, why am I not running this again?’ Then I install it and everything looks fine. Then bit by bit the seams start to show.
Fedora 26 was to have been my grand entry into all things Wayland. The laptop running Ubuntu 16.04 started to feel like it needed something fresh or maybe I was just bored. I went in with open eyes, knowing that the move from Xorg to Wayland would invalidate a whole swathe of hacks I have used since times immemorial. It was going to be painful but a) it’s the cost of progress, might as well bite the bullet now and b) something something profit? Profit being some unforeseen advantage to doing things the new way.
To cut to the punchline, Wayland-Gnome runs and is perfectly servceable and I applaud the Fedora team for being the vanguard of the future and all that. I’m just not convinced that I as a regular user want to be on that frontline.
Why my udev backup script kept failing and how I fixed it
I wanted to use udev to sync my backups to an external usb drive but the rsync-based shell script kept mysteriously stopping before the job was done.
When I say ‘use udev for backup’ what I mean is to use udev’s discovery of me plugging in the offline backup drive to fire off the backup script. Plug it in and the synchronization starts automatically. When it’s done it will automatically unmount the drive and inform me of the outcome via email. Sometimes there would be several weeks of new backups equalling gigabytes of data and so it would be convenient to just plug it in and leave it to do it’s thing.
The script was not apparently crashing wildly, just at one point it is running and the next it is not. htop shows it to be running. iotop shows that data are being transferred. And then poof, suddenly it’s gone, even though there were still tens of Gbs left to transfer.
Luckily, the explanation is simple. Udev can fire off scripts but they are supposed to be very shortlived. Syncing 40 Gb over a USB 2.0 connection takes over an hour. The script is killed by the system after a few minutes. I found this elegant solution in an opensuse forum post.