Posted on in Linux, Server

WordPress on Docker: The 1-2-3 approach

There’s an official WordPress docker image on the hub. Which means I have no good excuse to go make my own. Here’s my bad excuse: The official approach contains Apache and WordPress files all mashed up in one image. This feels icky to me partly because I don’t know Apache, having decided early on to hitch my wagon to Nginx, partly because it feels un-containerly to have everything in one big pot.

I cannot argue the merits and demerits of the official image with regards to performance, scalability, or security. What I saw was an opportunity to solve the problem in a way that felt more correct to me – 1 network, 2 volumes, 3 containers,  – that would also work as a learning experience. Here’s how I did it.

(more…)
Posted on in Linux, Server

Let’s do Dovecot slowly and properly: Part 2 – Proper authentication

In part 1 we set up the very most basic dovecot install we could get away with. In this part we will try to redeem it a bit by improving the security of the the authentication mechanism and the storage of passwords on the server. In other words we will make it much harder to snoop on our communications with the imap server and decrease the overall likelihood of somebody learning our password, including anybody with access – legitimate or otherwise – to our server.

(more…)

Posted on in Linux, Server

Let’s do Dovecot slowly and properly – Part 1: PLAIN as day

This post follows up on the fifth installment in my Let’s do Postfix series. We’re not really done setting up Postfix but a) it’s about time we had a better way of accessing incoming mail than ssh’ing into our server and using cat to read and b) we are at a juncture where the two will soon start depending on (SASL) and interacting with (LMTP) each other

This tutorial presumes knowledge of Postfix and the setup we’re aiming for is one that complements the Postfix one that we’ve set up in previous installments. As with the Postfix series I want to arrive at a working setup from the very first post but knowing full well that it’s not an ideal or final setup. The advantage (over importing somebody else’s full featured setup) is that we’ll actually understand what we have on our hands (and it’s shortcomings). This makes it a lot easier to build and improve upon it and fix it should the need arises.

A note on safety: The setup we’ll end up with today is not going to be confidential in any way, shape, or form. It will expose both the contents of the account’s emails and whatever password you choose to the entire internet. Therefore you should obviously use either a test account or a brand new one that has nothing important on it yet. As for passwords you should pick one for testing that you have not used nor intend to use for any non-testing purposes. That said, un-confidential is not the same as unsafe. Any public facing service is a potential attack vector but this setup is – to the best of my knowledge – no more of one than a more properly confidential setup.

(more…)

Posted on in Linux, Server

Setting up Postfix and Dovecot Slowly and Properly

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.

(more…)

Posted on in Desktop, Linux

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.

(more…)

Posted on in Desktop, Hardware, Linux

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.

(more…)