Managing passwords is a necessary evil. You can choose a number of different strategies for keeping track of all of your login credentials; from using the same password for every site which prioritises convenience over sanitysecurity, through to creating heinously complex unique passwords for every service and then balancing the relief of knowing your risks of being hacked have been minimised with the very real fear you will only remember any of them for a short period—if at all—and will shortly be locked out of everything.

Fortunately, this is a solved problem. There are a number of password managers available, both as desktop clients and cloud services. Personally, I find the idea of storing my passwords in the cloud has all the fascination of bungee jumping; it’s apparently mostly safe, but that can be cold comfort… The first application that I used, and used happily for quite a long time, was KeePassX.

Around the end of 2012, I started experimenting with KeePassC, a curses-based password manager that is completely compatible with KeePassX and has very little in the way of dependencies. I have been using it solidly on my home and work laptops ever since and, after recently uninstalling Skype on my desktop, have switched over to it completely¹. I’m still not entirely clear why I haven’t written about it previously.

Written in Python 3, KeePassC is entirely keyboard driven (naturally enough, you can use Vim keybinds) and integrates seamlessly with your browser and clipboard. My experience of the software over the last eighteen-odd months is that it has been incredibly stable and the developer, Karsten-Kai, has been exceptionally responsive and helpful in the forum thread.

Like most good software, there is not a lot to it. You pull up the login page, switch to a terminal and run keepassc, enter your passphrase (I use a Yubikey for this and it works wonderfully) and then search for your desired entry with / and then hit c to copy the password to your clipboard before switching back to the browser and you are in.

KeePassC also has a set of simple command line options, run keepassc -h to see them. Additionally, you can set up KeePassC as a server, I haven’t experimented with this as I sync my database. The only functionality that the X application offers in addition, as far as I can tell, is the auto-filling of your username and password fields bound to a keybind; undoubtedly, this is a very handy feature, but I haven’t really missed it at all.

As I said, I store the database in a directory synced between all my machines² (using Syncthing), so I have access to an up-to-date versions of my credentials everywhere. Well, almost everywhere. I don’t use the Android client because the mobile web is just such a fundamentally insecure environment and I see it as just being sensible, rather than any sort of inconvenience.

Notes

1. Skype and KeePassX were the only two applications I used that required Qt, so once Skype was gone there was no reason to keep KeePassX installed.
2. And, after a nasty scare very early on with a corrupt database, I back that file up daily.

Creative Commons image on Flickr by xserv.

It is now almost exactly two years since the AIF was put out to pasture. At the time, it caused a degree of consternation, inexplicably causing some to believe that it presaged the demise of—if not Arch itself, then certainly the community around it. And I think it would be fair to say that it was the signal event that launched a number of spin-offs, the first of which from memory was Archbang; soon followed by a number of others that promised “Arch Linux with an easy installation,” or something to that effect…

Of course, if you look back at the Installation Guide immediately before the move to the new scripts, for example the version that shipped with the last AIF in October, 2011, it is pretty evident that the current approach is a lot simpler. Sure, there is no curses GUI to step you through each part of the install but the introduction of pacstrap and arch-chroot meant that you no longer need those prompts.

There is also the added advantage that these scripts are useful outside the installation process itself; they can be used for system maintenance and, in the rare event that your recent bout of experimentation at 2am after a few drinks doesn’t pan out the way you anticipated, repair.

One of the other responses to the new approach, however, has been the steady proliferation of “helpful” install scripts. These are essentially bash scripts that emulate the behaviour of the AIF and walk people through an automated install of their system. Well, not really their system, more accurately a system. So you run one of these scripts, answer a few prompts and then, when you reboot, you have a brand spanking new Arch Linux install running KDE with the full panoply of software and, in a few special cases, some customized dot files to “enhance” your experience.

From a certain perspective, I can see how these things appeal. “I wonder if I could script an entire install, from the partitioning right through to the desktop environment?” That sounds like a fun project, right? Where it all comes unstuck, unfortunately, is when the corollary thought appears that suggests sharing it with the wider community would be a good idea. It is at this point that a rigorous bout of self-examination about the outcomes that you are seeking and your base motivations for this act of selflessness are called for.

Whatever those motivations are, whether driven by altruism or the naked desire for fame and fortune that have—from time to time—alighted on these projects when they appear on /r/archlinux and the adoring throngs bestow their favours in equal measures of upvotes and bitcoin, they are grotesquely misplaced. No good comes from these things, I tell you; none.

Why not? Because, in the guise of being helpful, you are effectively depriving people of the single most important part of using Arch: building it themselves. It’s like inviting someone to a restaurant for an amazing haute cuisine meal, sitting them down across the table from you and then them watching as the staff bring out a mouth-watering array of dishes, each of which you ostentatiously savour before vomiting it all back into their mouth.

Now, I am sure there is a small minority (well, at least from my own sheltered experience I imagine it is small) who would relish this scenario, but for most it would qualify as a pretty disappointing date.

Then, after the technicolour table d'hôte, there is the matter of the clean up. Recently, we had someone show up on the Arch boards who had “installed Arch” but who did not understand how to edit a text file; literally had no clue how to open a file like /etc/fstab make some changes and then save it. This is beyond stupid; it is a drain on the goodwill of the community that has to deal with this ineptitude, it is unfair on people to put them in a position where they feel they are at the mercy of their technology, rather than in control of it, and it does nothing to advance the interests of Arch.

If you want to write something like this to improve your scripting skills, by all means proceed. If you want to contribute to Arch, then pick a project to contribute to, some bugs to squash, wiki edits, whatever; just don’t publish another one of these idiotic scripts, because you aren’t doing anyone any favours, quite the contrary.

Notes

Flickr Creative Commons image, Measuring spoons by Theen Moy.

After relieving my Pi of seedbox duties, I was looking around for some other use for it. I decided, after looking over the Arch wiki article on OpenVPN, that the Pi would be a terrific VPN server; when I am out and about I can access a secure connection to my home network, thereby significantly reducing the risk of my privacy being compromised while using connectivity to the Internet provided by the notoriously security conscious sysadmins that run networks in hotels and other public places.

Setting it up was straightforward enough, the wiki is typically clear and thorough; the only bottleneck in the process was waiting for the Pi’s tiny chip to chug through the creation of public keys. Once it was done, and I had tested that it was indeed working as intended, a more vexing issue presented itself. The service wouldn’t come up after rebooting. Not a deal breaker, I could always just SSH in and manually bring the server up, but that sort of defeats the purpose of being able to have the thing running reliably.

The reason that it fails on boot is that, without a hardware clock, the Pi resets its time to UNIX time until the NTP daemon can start, which in turn depends upon the network being up. So, after rebooting, the journal would show the VPN server as having failed as the date was nearly half a century ago.

There are a variety of fixes floating around, the most amusing being a wrapper for init. Suffice to say, this wasn’t an option for me. Looking at the problem logically, it occurred to me that the issue was actually a trivial one: the correct sequencing of different services post boot. Isn’t this, I asked myself, one of the issues systemd was supposed to address?

I just had to ensure that the network came up as quickly as possible after boot, that the time was reset correctly once there was a viable connection, and that the openvpn.service waited for those things to happen before launching.

I have fitted the Pi with a wireless dongle, so the first step was to ditch netctl (the default network manager on the ARM image) and replace it with systemd-networkd. This is the point at which all the wingnuts that think that systemd is some sort of conspiracy to overthrow the old UNIX gods and replace them with false idols in chapeau rouge start foaming at their retrognathic mouths about “viral takeovers” and—seriously what fucking planet do these imbeciles hail from?—“an abhorrent and violent slap in the face to the Unix philosophy.”¹

For those of us that accept the theory of evolution, this technology is both effective and non-threatening; in fact, it is quite an improvement over its by now ageing predecessor. So, a few minutes later, /etc/systemd/network/wlan0.network and /etc/wpa_supplicant/wpa_supplicant-wlan0.conf had pretty much written themselves and then it was just a matter of enabling the eponymous services as well as systemd-resolved.service. Reboot and the network is up seemingly instantly.

Compounding my heresy, I then switched out NTP for systemd-timesyncd and the Pi’s clock was now reset with the same alacrity. The final piece, ensuring that the openvpn service waited for this to happen, was to add two lines to the service file:

1
2
3

After=network-online.target
Wants=network-online.target

That is all there is to it. Reboot and the network comes up, the clock is reset and then the OpenVPN server starts. Like magic. The sort of heathen magic that threatens to sap and impurify all of our precious bodily fluids.

Notes

1. No, Virginia, I did not make that up… And I don’t really understand how you can slap a philosophy in the face, but then rationality is anathema to zealots; irrespective of which chimæra they prostrate before.