jasonwryan.com

Miscellaneous ephemera…

Install scripts

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.

OpenVPN and Time on the Raspberry Pi

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.”1

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:


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.

Writing with Vim

Vim is not just an editor (and not in the way that Emacs is more than just an editor); it is for all intents and purposes a universal design pattern. The concept of using Vim’s modes and keybinds extends from the shell through to file managers and browsers. If you so choose (and I do), then a significant amount of your interactions with your operating system are mediated by Vim’s design principles. This is undeniably a good thing™ as it goes some way to standardising your command interface (whether at the command line or in a GUI).

To that end, I have been spending more time working with Vim and trying to improve both my understanding of it’s capabilities, the environment in which I use it and how I can optimise both of those conditions to not necessarily just be more productive, but to minimise friction in my work flows.

A large part of my job involves writing and, happily, so does a good deal of what constitutes my leisure activity. Whether it is emails written in Mutt, these blog posts, longer documents written in LaTeX, or just roboposting to forums; it is Vim all the way down. So I have spent some effort setting up Vim to make that experience as comfortable as possible.

The first step, and one I took several years ago now, was to write custom colour schemes, depending on whether I am in the console or X. Several weeks ago, I came across a Vim plugin called DistractFree, which is described as “enabling a distraction free writing mode.” I had always been slightly (well, perhaps scathingly would be more accurate) cynical when reading about these sorts of things when they first started to appear, but—after playing with two or three of them—this one has really grown on me (see the screenshot on the right).

I adapted my colour scheme for it, added a line to my ~/.vimrc to enable it for specific document types, and have not looked back.

autocmd BufRead *.markdown,*tex call DistractFree#DistractFreeToggle() | wincmd w

The final piece was to set up spell checking to work properly. As well as using English, I wanted to share my personal whitelist of words between all of my machines, so I define a location in ~/.vimrc as well:

set spelllang=en_gb                               " real English spelling
set dictionary+=/usr/share/dict/words             " use standard dictionary
set spellfile=$HOME/Sync/vim/spell/en.utf-8.add   " my whitelist

Then it is just a matter of ensuring that misspelled or other flagged words (like those that should be capitalised) are highlighted correctly. This required a couple of lines in my colour schemes:

" Spell checking  --- 
if version >= 700
  hi clear SpellBad
  hi clear SpellCap
  hi clear SpellRare
  hi clear SpellLocal
  hi SpellBad    ctermfg=9
  hi SpellCap    ctermfg=3    cterm=underline
  hi SpellRare   ctermfg=13   cterm=underline
  hi SpellLocal  cterm=None
endif

The most significant change, however, was that I recently purchased a hard copy of Drew Neill’s excellent Practical Vim. I have long been a fan of Drew’s excellent podcast, Vimcasts, and the book is every bit as impressive as the collection of those episodes, and more. Reading it on my commute over the last week, I have been constantly amazed at the power and flexibility of this editor and Drew’s ability to clearly articulate how to work economically and efficiently with it. I’m convinced this is an invaluable resource for anyone that currently uses Vim or wants to learn.

I expect that, over time, as I become more proficient with Vim, that I will adapt some of these settings, but for the time being they feel very comfortable and allow me to focus on hacking words together (and to do the occasional bit of scripting on the side)…

Notes

Image is from the cover of Drew Neill’s Practical Vim, by Ben Cormack.