If you can read this, that means my transition to ikiwiki has happened.

I've been interested in ikiwiki ever since Joey first wrote about it back in 2006, but it took me until just recently to finally bite the bullet and migrate to ikiwiki.

The plan was to retain everything, including comments, and I've mostly achieved that. Still, a few things were lost along the way:

• There were a few blog entries that had special characters in their filename which blosxom didn't care about but ikiwiki didn't like. Since there were only a handful of them, I've ignored those for now. It does mean those are now dead links, but I decided it's not worth bothering about much.
• My previous setup had a fairly intricate way to choose a different stylescript which I'm fairly sure nobody (but me) ever used. To keep things simple, I've decided not to port that over to ikiwiki. Instead, only the most recent 'grass' stylesheet has been retained (though it required some changes to accomodate for the fact that elements have different class names and ids in ikiwiki as compared to my own stuff, obviously)
• My own comment system had threading support, which ikiwiki does not seem to have. I did consider adding it, but I've decided not to care much.

I should note that at this point I've only ported the blog itself, not the rest of my website. While ikiwiki can be used for that as well, the parts outside of my blog are fairly static and don't change all that often. In addition, those bits are set up in an even uglier way, and I didn't want to fix them up just yet.

Things I've learned:

• ikiwiki does not track timestamps across git moves. Not sure whether this is a bug. It meant I couldn't rename the "special-characters entries" that I mentioned above, since the dates would be all wrong.
• You can cherry-pick an entire git branch onto another branch (without having to specify each and every commit individually), if you need/want to avoid a merge commit. Apparently ikiwiki got confused about the merge commit, and we ran in the above same issue; but with cherry-picking the commits from the git-svn branch on which they were, stuff was done correctly.

My talk proposal for LOADays 2014 has been accepted. That makes the fifth consecutive time I'll be speaking there. I like this little event; it's small but always seems to come with some good content. And as someone who's ended up being a system administrator for most of my career, I can always find something interesting to talk about.

This time around, my talk will be about debian-installer automation. I plan to explain a bit how d-i is structured internally so as to help people understand better how things work, and will then run a little demo on how we used preseeding to install the 45 laptops for FOSDEM with (almost) no user input.

I've also decided to use libreoffice impress this time around, so I can try out the impress remote. Let's see how it goes.

See you there?

"Given a Debian system with just the set of essential packages installed, find a single package name that, together with its dependencies, will increase the used diskspace of the system by as much as possible."

My entry: openarena.

Off to bed, now.

I know, I know, I should resist saying this. But every time I see it, I wonder why it happens, and I should just get this off my chest.

The difference between "its" and "it's" is something that many people, even native english speakers, seem to miss. Yet, it's so extremely simple that I, a non-native english speaker, have been baffled about that common mistake for as long as I can remember.

The apostrophe (') in any sentence usually means that something at the location of that apostrophe is gone out to lunch. In this particular case, it means that the " " and the "i" in the phrase "it is" were hungry. So rather than "it is", we contract that to "it's", and allow the space and the i to enjoy their meal while the apostrophe keeps their seats warm.

Practically, what that means is that every time you want to write "it's", you should consider whether you can replace it with "it is" without making the sentence sound like junk. If you can't, you probably meant to write "its" rather than "it's".

For instance, consider the following sentence:

"It's not possible to repair this car within the budget that its owner wants to pay"

It's perfectly possible to say "it is not possible" here, so we need to have the apostrophe keep a seat warm for the space and the i.

It makes no sense to say "it is owner", unless you're trying to speak a much deformed form of english, so that makes it a possessive pronoun (similar to "hers", "his", "theirs", etc) and you shouldn't use an apostrophe.

Speaking of food, it's time for lunch now.

Kerberos is a great protocol for single sign-on authentication. It's supported by many protocols, allowing you to not have to enter a password to each and every one of them; instead, the protocols behind the scenes (not "just" Kerberos, but also the things that embed tickets, such as GSSAPI, or the things that embed GSSAPI, such as SASL or SPNEGO) use your ticket-granting-ticket to ask for security credentials for the service you're trying to use, magic happens, and you're authenticated. I blogged about kerberos before (even if it was ages ago); since then, I've not only used it on my own systems, but also on the systems of various customers.

One thing I've learned in that time, however, is that most web application developers have a bad case of NIHilism when it comes to authentication. Most webservers that I've seen have a wide range of methods to do authentication in the webserver through various means, including things like certificate-based authentication, one-time password modules, and, yes, kerberos. Yet almost no webapp out there will look at the magic variables that those webservers set to explain we're authenticated, instead reinventing the wheel through webforms and other various stupid means. Sigh.

So, that means, no kerberos authentication for webapps. Worse, if the application has no way to pass on authentication to something external, that means users will now have to learn another password: one for Kerberos, one for the webapp. And, probably, one for this other webapp, too -- because once you add one webapp, people expect you to add more of them.

Well, mostly. In some cases, webapps do have ways to externalize authentication. In most cases this means "store passwords in a database", or "try authenticating against this other service here".

When "this other service here" is an IMAP server, then all you need to do is make sure cleartext authentication on the IMAP server eventually ends up trying to authenticate against the Kerberos server, and you're all set. When "this other service here" is an LDAP server, however, you're out of luck. Right?

It turns out that no, you're not. I recently learned that OpenLDAP can, in fact, check "simple" bind requests by checking some other service, and that this other service can be a Kerberos realm. Doing so is called "Pass-through authentication" in the OpenLDAP documentation, and this is how you do it:

• Add a "userPassword" attribute to the user who will authenticate, with a value of the form "{SASL}principal@KERBEROS.REALM". That is, take the user's principal name, tack "{SASL}" in front of it, and put that in the userPassword attribute.
• Make sure you have saslauthd installed and running, with the kerberos5 mechanism active. In Debian, that means you have to install sasl2-bin, and edit /etc/default/saslauthd, so it has the variable START set to yes (yuck), and the variable MECHANISMS set to kerberos5.
• Create a file /etc/ldap/sasl/slapd.conf, and add the following contents:

mech_list: plain
pwcheck_method: saslauthd

This directs the SASL libraries, loaded by slapd, to talk to saslauthd when trying to authenticate some SASL things - Make sure slapd has the correct permissions to access the saslauthd unix domain socket. On Debian, that means you need to add the "openldap" user to the "sasl" group:

`adduser openldap sasl`

(obviously that won't be active until the next slapd restart)

And that's it; if you now try a simple bind against the LDAP directory, and enter your Kerberos password, you should be in. If it doesn't work, try running "testsaslauthd"; if that works, it means the error is in your slapd configuration. If it doesn't, then the problem is in saslauthd.

Some notes:

• this is not the same thing as using Kerberos authentication for LDAP. OpenLDAP has the ability to allow SASL binds for LDAP, which is way more interesting (since it allows authentication to actually be done by Kerberos rather than by "entering a password"); instead, with this method, it is possible to verify a password for a simple bind against a Kerberos password.
• Since this can't use hashed passwords, this method is inherently insecure. Only use it if all else fails, and for the love of $DEITY, at least make sure all the network connections which are going to contain such passwords are encrypted with SSL or TLS or similar. Otherwise, everyone who can sniff anything on your network will learn all the Kerberos passwords, which is a very very bad thing.

Oh, and if you're a webapp developer: please please please make it easy for me to use an external authentication mechanism. This isn't hard; all you need is a separate page that will read the magic variables (probably REMOTE_USER if you're using apache), set a session variable or whatever, and then redirect to your normal "we've just logged in" page. ikiwiki gets this right; you can too!

(for added bonus points, have some way to declare a mapping from REMOTE_USER values to internal, readable, usernames, but it's not too crucial)

While reading up on dnssec-keygen and other related stuff in order to update my puppet bind module to support DNSSEC transparently, I accidentally stumbled across something in the BIND Administrator's Reference Manual called GSS-TSIG. Intrigued, I set out to learn more, and found that this is terribly easy to set up with BIND:

• create a DNS/<nameserver address> principal inside your realm. Note that the "nameserver address" really needs to be the name of the primary name server as specified in the SOA record of the zone; this is in contrast to pretty much every other use of Kerberos out there, where it has to be the name of the machine as specified by the PTR record of the IP address you're talking to.
• Write that principal to a file which is readable by named. I used /etc/bind/bind.keytab for this purpose. Make sure this file is owned by the UID that named runs as.
• Add a tsig-gssapi-keytab stanza to the options block in your named.conf file (or named.conf.local) on Debian. This stanza wants a string specifying the filename of your keytab file. In the above example, that becomes tkey-gssapi-keytab "/etc/bind/bind.keytab";
• In the zone block of the relevant zones, add an update-policy statement for each of the users that you want to allow to make updates; e.g., update-policy { grant exampleuser@EXAMPLE.COM zonesub any; }; will allow a user with principal exampleuser@EXAMPLE.COM to perform updates for this zone.
• exampleuser@EXAMPLE.COM can now use nsupdate -g to perform any GSSAPI-authenticated updates of the zone file.

There are a few more interesting features; e.g., krb5-self can be used to allow the host/machine@REALM principal to update the A record for machine, and there are ways to specify ACLs by wildcard. For more information, see the BIND administrator's reference manual, chapter 6, in the section entitled "Dynamic Update Policies".