Building an OpenBSD Wireguard server

In my previous post, I mentioned that I somehow ended up with a corrupted filesystem on the WireGuard server I had set up earlier this year. That iteration of my VPN server was built on Linux as I expected I would get better performance using the kernel-based WireGuard implementation. It had taken me a while to set it up right, and I didn’t get the impression that the performance was so much better anyway. Keep in mind that I mostly use my VPN server from hotel WiFi and we all know how “good” that tends to be performance wise.

While I’ve done a fair bit of Linux admin work, I didn’t fancy re-doing the whole setup again. I also hadn’t scripted it up using Ansible or similar. I tend to prefer BSD anyway, and most of my personal servers run some flavour of BSD Unix. As I didn’t want to spend too much time securing this server, I used OpenBSD as it is a little more secure out of the box compared to FreeBSD. I also hadn’t experimented with OpenBSD for a while so I was curious to see the more recent improvements.

OpenBSD WireGuard Server setup at Vultr

I re-used the VPS I already had set up for the old Linux WireGuard VPN server at Vultr. Heck, it was corrupted already so formatting it was the only choice. In the interest of getting the VPN up and running quickly again, I used Vultr’s preconfigured OpenBSD image. With hindsight I probably wouldn’t do that again. More about this later. I followed a combination of instructions, mainly from the Cryptsus blog post on setting up WireGuard on an OpenBSD 6.6 server, but also referencing Jasper.La’s blog and Ankur Kothari’s blog. Setting up WireGuard on OpenBSD took me a lot less time than configuring the Linux version. I think it took me an hour or two to get the basic VPN tunnel up and working, including configuring the macOS client.

Overall I found this approach simpler than setting up WireGuard on Linux. I think there are two reasons for this – using the precompiled binaries for the user mode processes means you don’t have to futz around with kernel modules, third party repos and all that fun stuff, plus I personally find FreeBSD and to a certain extent OpenBSD easier to set up. This is obviously a personal preference. Plus, no systemd :).

Notes on the default Vultr OpenBSD Image

The Cryptsus instruction include setting up OpenBSD using full disk encryption. This is more secure than using Vultr’s default, preconfigured VPS image as that one doesn’t support full disk encryption out of the box. Using the preconfigured image makes the installation process easier and quicker, but at the expense of not getting the full official OpenBSD configuration out of the box. With hindsight, I probably what should have used a custom (well, the official) OpenBSD 6.6 image instead of the preconfigured Vultr one, but as mentioned I was in a bit of a rush and it was a case of “good enough and working” trumping “more secure”. When setting up a VPN server, there are basically multiple issues you want to protect yourself against:

  1. Someone remotely logging into your VPN server and getting hold of the encryption keys, and/or being able to capture traffic on your VPN server. That’s obviously the worst-case scenario from a security and privacy perspective, and the main one that I wanted to protect myself against. For that, I rely on OpenBSD’s security with strong passwords and key-based SSH authentication to log into the machine.
  2. Someone getting hold of the disk image – that’s what the full disk encryption part protects against. Something I will want to add to the server sooner or later – it does require a reinstall first, though. The risk of this is considerably lower than someone breaking into the VPN server itself and requires either an infrastructure fluke or an infrastructure compromise.
  3. Someone getting a level of access to the VPS host such that they can observe the running VPS and dump out its memory. Again, that’s possible but it requires a lot of work to get there. I like to think that there are a lot juicier targets than myself out there that would warrant this level of effort. So for right now, I’m discounting this threat model.

I’ve got the first point covered right now, will probably address the second one at some point and do my best to ignore the third one for now.

What’s still left to be done

The basic setup for my OpenBSD WireGuard server is up and running, and I’ve successfully used it while traveling. It’s definitely fast enough even on one of Vultr’s $5 instances. Most of the time, when I use the VPN I don’t need lots of bandwidth, but even when “testing” by watching YouTube videos, the performance was more than good enough.

I’m currently using the AdGuard DNS servers that were mentioned in the Cryptsus blog post I linked to above, but I really want to move to an Unbound DNS server on the VPN host itself that a) validates domains were possible and b) uses something like the Pi-hole blocklists to block ads and trackers. The latter is somewhat optional as I don’t really use the VPN for normal browsing, but it’s a definite nice to have.

Looks like I get to redo my WireGuard VPN server

I’ve blogged about setting up a WireGuard VPN server earlier this year. It’s been running well since, but I needed to take care of some overdue maintenance tasks. Trying to log into the server this morning and I am greeted with “no route to host”. Eh? A quick check on my Vultr UI showed that the VPS had trouble booting. The error suggests a corrupted boot drive. Oops.

Guess what the maintenance task I was looking at was? Creating an Ansible script so I’d be able to stand up the server from scratch in case something like this happened. And yes, the irony of being the guy who regularly preaches to his clients about the need for backups doesn’t quite escape me.

Anyway, at least this gives me an excuse to set up my WireGuard server on OpenBSD. This is something I’ve been thinking about for a while so now I have the perfect excuse for it. I realise that OpenBSD can only use the user space daemon for WireGuard rather than the in-kernel version Linux uses. This is generally good enough for my use case as I’m only looking for added security when I’m on public WiFi and don’t need really high performance.

And yes, this time I’m going to create the Ansible script either as part of the build or directly after :).

How to rename a database in MongoDB

MongoDB has a handy command to rename a collection, db.collectionName.renameCollection(). There is currently no equivalent to rename a database. Now if we accept that from time to time, one positively, absolutely just has to rename a database in MongoDB, well, there are a couple of options. Unfortunately they aren’t quite as straight forward as single MongoDB command. All methods for renaming a database in MongoDB also take a fair amount of time and/or disk space to complete. Keep this in mind when you try to use any of them.

Read More

[HOWTO] Installing Emacs 26.3 on Ubuntu or XUbuntu 19.04

My previous instructions for installing a newer Emacs version on Ubuntu still work. Ubuntu (and in my case, XUbuntu) 19.04 ships with Emacs 26.1 out of the box. As usual I want to run the latest version – Emacs 26.3 – as I run that on my other Linux, FreeBSD and macOS machines.

I only had to make one small change compared to the older instructions. Instead of running the versioned sudo apt-get build-dep emacs25 I rand sudo apt-get build-dep emacs. Once the dependencies are installed, you’re a configure/make/make install away from having a working Emacs 26.3:

timo@timos-thinkpad:~/Downloads/emacs-26.3$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 19.04
Release:	19.04
Codename:	disco
timo@timos-thinkpad:~/Downloads/emacs-26.3$ $HOME/local/bin/emacs --version
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Some of the other instructions on the web mention that there is now a PPA for the latest stable Emacs versions. I’ve not personally used it as I’m comfortable with building Emacs from the command line. The other advantage with building Emacs from scratch is that it coexists with any other version that you installed from the Ubuntu repositories or other PPAs. This way you can avoid problems like the one described in this askubuntu Stackexchange discussion.

Installing leiningen on Manjaro Linux

I like Lispy languages. One I’ve been playing with – and occasionally been using for smaller projects – is Clojure. Clojure projects usually use Leiningen for their build system. There are generally two ways to install leiningen – just download the script as per the Leiningen web site, or use the OS package manager. I usually prefer using the OS package manager, but Manjaro doesn’t include leiningen as a package in its repositories. Installing leiningen is pretty easy via the package manager and I’ll show you how.

Read More

How to speed up macOS Time Machine backups

macOS Time Machine is usually set up to work in the background and not overly affect anything that’s going on in the foreground while the user is working. Under normal circumstances, this is desirable behaviour. It is not desirable when you try to take one last backup of a failing SSD before it keels over completely. Which was the unfortunate situation I found myself in.

Turns out there is a sysctl that can be used to disable or enable this behaviour. If you turn it off, the backup in macOS Time Machine runs much faster, at the expense of additional network bandwidth and disk IOPS. The backup daemon will increase disk IOPS usage both for reading and writing.

The sysctl to turn off the low priority backup in the background is:

sudo sysctl debug.lowpri_throttle_enabled=0

Obviously, set the value back to its default of 1 if you want to restore the original behaviour. Based on the atop stats on my home server, network bandwidth usage went up from 5-10% to about 20%, and disk IOPS usage from 7-8% to about 65-70%. The backup is not maxing out the server or client. On my old 6 core Mac Pro, I have no problem running the backup at the higher speed without a big impact to my main work. I suspect that it would be different if I were to run disk intensive applications, though.

Wrapping up the Emacs on Mac OS X saga

In a previous post I mentioned that I upgraded my homebrew install of Emacs after Emacs 26.2 was released, and noticed that I had lost its GUI functionality. That’s a pretty serious restriction for me as I usually end up with multiple frames across my desktop. I did end up installing the homebrew Emacs for Mac tap which restored the GUI functionality. It had have one niggling problem for me, though. My muscle memory says that I use Shift-Meta-7 (aka Meta-/ ) for keyword expansion as I use a German keyboard layout most of the time. Unfortunately, with Meta mapped to the Apple Command key, Shift-Meta-7 is a menu shortcut. Instead of expanding keywords, I kept opening menus. That clearly wouldn’t do.

Malcolm Purvis had been kind enough to point out in a comment to my original homebrew Emacs post that Davide Restivo had created a brew tap that brings the necessary –with-cocoa build option back. He just upgraded it to Emacs 26.2, so this morning I rebuild my Emacs on OSX again and ended up where I wanted to be, with the latest version of Emacs, keyword expansion as I expected it to work, and a working GUI. Thanks, Davide!

And yes, it might come across as silly to rebuilding the editor just to get my preferred key combination back. It probably is – after all, I could’ve just remapped the key combination in my .emacs. I tend to run Emacs across a myriad of platforms (Linux, OSX, Windows, FreeBSD to just list a few) and having a “stock” Emacs experience on all of these platforms means that my .emacs has only a minimal amount of OS-based conditionals in it. For example, it has the following OS X specific combo:

;; On OS X/Darwin, make sure we add the path to the homebrew installs
(when (string-equal system-type "darwin")
  (setq exec-path (append exec-path '("/usr/local/bin")))
  (global-set-key [home] 'move-beginning-of-line)
  (global-set-key [end] 'move-end-of-line))

In fact, the above block is the only OS-specific configuration in my whole .emacs file. I’d like to keep it that way.

Emacs 26.2 on WSL with working X-Windows UI

I’ve blogged about building Emacs 26 on WSL before. The text mode version of my WSL build always worked for me out of the box, but the last time I tried running an X-Windows version, I ran into rendering issues.  Those rendering issues unfortunately made the GUI version of Emacs unusable on WSL. Nothing like missing the bottom third of your buffer to cramp your style. Or your editing.

Going all in with Emacs 26.2 with Cairo

I’ve just built the newly released Emacs 26.2 on my Ubuntu WSL with the options –with-cairo –with-x-toolkit=gtk and it looks like the rendering has improved massively. I’ve also recently upgraded VcXsrv to version, so it’s not quite clear to me if this is due to improved compatibility of WSL itself, changes between Emacs 26.1 and 26.2, or the fact that I turned on Cairo or VcXSrv upgrade.

Screenshot of a freshly built Emacs 26.2 running on WSL
Emacs 26.2 with Cairo on WSL

I’m still seeing a couple of odd rendering issues that I can’t fully reproduce. They’re mostly around the resizing and buffer splitting, which I can live with for now. The Cairo renderer is known to still have a few bugs, so that might be contributing to the problems I’m seeing. I’m just happy that I do have a 95% working Emacs on WSL.

One other oddity I noticed is that I have to specify -d to set the display if I want to enable the GUI. Setting DISPLAY in the environment doesn’t quite seem to do the trick for now. I will keep playing with this a little more to see if I’m overlooking the blindingly obvious.

There’s also a little issue with Emacs not being able to connect to VcXsrv if I just specify -d localhost:0.0. This should work but the only way I can get it to work is by using -d I suspect that’s because I recently added IPV6 capabilities to my home network and for some reason, VcXsrv doesn’t listen on the IPV6 interface. And no, -d ::1:0.0 doesn’t work, either.

Anyway, here we have another self-referential screenshot of the Emacs UI showing me working on this blog post:

Working on this blog post, still with Cairo turned on
Working on this blog post, still with Cairo turned on

Here we go again, this time without Cairo

I ended up rebuilding the Emacs binary without Cairo support as the rendering issues got a little annoying. Disabling Cairo seems to have taken care of the rendering issues during buffer splits for now. I’ll still have to look into the IPV6 issue at some point, but for now I’m pretty happy with the final result. So for our final, final result for today, here’s a non-Cairo screenshot running the anti-zenburn theme with powerline with its default theme.

Emacs, no Cairo, anti-zenburn with powerline
Emacs, no Cairo, anti-zenburn with powerline


And now, an Emacs with a working org2blog installation again

I mentioned in my previous post that I somehow had ended up with a non-working org2blog installation. My suspicion is that this was triggered by my pinning of the htmlize package to the “wrong” repo. I had it pinned to marmalade rather than melpa-stable, and marmalade had an old version of htmlize (1.39, from memory). The fact that marmalade is erroring out with an expired certificate is most likely a sign that I need to stop using it. Anyway, re-pinning htmlize to melpa-stable unclogged that particular problem and the updated org2blog flowed onto my machine.

As a bonus, I ended up following the instructions for installing org2blog v1.1.0. While that version is not yet available on melpa-stable, it exposed me to use-package, which is something I’ve been meaning to look at but haven’t got around to so far. A quick glance at the docs – which is all I’ve had time for so far – suggests that I really need to look at use-package in depth and possibly update my .emacs to make use of it rather than continuing to maintain the home grown package installation wrapper I’ve been using for the last few years.

Either way, I’m happy to be able to blog from Emacs again rather than having to suffer WordPress’s built-in editor.

Unwelcome surprise – homebrew Emacs has no GUI after OS X Mojave update

I finally got around to upgrading my OS X installation from Mojave to High Sierra – my OS update schedule is usually based on the old pilot wisdom of “don’t fly the A model of anything”. As part of the upgrade, I ended up reinstalling all homebrew packages including Emacs to make sure I was all up to date. That proved to be a big mistake as I suddenly had a GUI-less Emacs. Of course I found the post on Irreal about the Emacs homebrew package being broken on Mojave after, well, I noticed that my Emacs GUI wasn’t working. Oops.

A bit more poking around the Internet brought me to the homebrew cask for the Emacs Mac Port. As the screenshot below shows, it works with a UI on Mojave, so if you’re looking for an alternative to the regular Emacs port, this one seems to be fine, at least based on a quick “test drive”.

Screenshot of a GUI Emacs 26.1.92 running on Mac OS X Mojave
Working Emacs For Mac on OS X Mojave

Time to make sure that the installed packages are also working as it doesn’t seem to recognise org2blog and I ended up having to write this post in the WordPress editor. Can’t have that.