Blog

If you're like me, you've noticed that a bunch of other people helpfully put the date and time before quoted text in their messages:

On 12/21/2009 05:26 AM, Alex Dehnert wrote: 
> Foo Bar Baz

Meanwhile, you're left with the way less cool:

Alex Dehnert wrote: 
> Foo Bar Baz

This is pretty easy to change. Go to Edit -> Preferences. Select Advanced -> General -> Config Editor. Using the filter box, find mailnews.reply_header_type, double-click, and change the value to "2" instead of "1". (If you set it to "0" you'll apparently get no header, and if you set it to "3" you can use an even-more-customized header --- see the Tips & Tricks for details.

I've been installing a bunch of new VMs recently, so I've been coming across various problems and changes in the way Linux works since last time I was doing a bunch of configuration.

One change is that Subversion has apparently decided that storing passwords unencrypted was a bad idea. (Who'd have thought, right?)

These days, if you try to perform an operation that want to cache your credentials, you'll get something like:

alex@olinda ~ [14:39] $ svn switch --relocate https://svn.dehnert.arctic.org/ https://svn.dehnerts.com/
Authentication realm: <https://svn.dehnerts.com:443> alex's subversion repositories
Password for 'alex': 
-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <https://svn.dehnerts.com:443> alex's subversion repositories

   can only be stored to disk unencrypted!  You are advised to configure
   your system so that Subversion can store passwords encrypted, if
   possible.  See the documentation for details.

   You can avoid future appearances of this warning by setting the value
   of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
   '/home/alex/.subversion/servers'.
   -----------------------------------------------------------------------
   Store password unencrypted (yes/no)?

While I had been okay with storing my password (I don't use it for anything else, and it isn't like my repository stores anything interesting...), this seemed like functionality worth pursuing.

There are two main steps to setting this up. First, you'll need to enable storing the password.

Edit your ~/.subversion/config and add:

[auth]
### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
### Valid password stores:
###   gnome-keyring        (Unix-like systems)
###   kwallet              (Unix-like systems)
###   keychain             (Mac OS X)
###   windows-cryptoapi    (Windows)
password-stores = gnome-keyring , kwallet

If you're like me, though, you're trying to do this on slightly-customized Ubuntu/JeOS install from python-vm-builder, which turns out not to have such software as gnome-keyring.

To do that, run:

aptitude install gnome-keyring # Install the daemon and some libraries
aptitude search seahorse # GUI --- probably not needed

This took about 100MB total additional disk space --- non-negligible, but acceptable for a machine that is not trying to be particularly minimal.

In each session you'll need to connect to the keyrings: eval $(gnome-keyring-daemon --daemonize); export GNOME_KEYRING_SOCKET SSH_AUTH_SOCK GNOME_KEYRING_PID. Presumably adding that to .bashrc or something would be a good idea.

I believe you'll also need to add a keyring to store the password in. Run seahorse (after running the daemon, of course), and then go to File -> New... (Ctrl-N), select "Password Keyring", and then name it (I named it "login", which I think matches the default; other names may or may not work).

When you run Subversion, it'll ask you for keyring password. If you get the password right, it should just unlock the keyring. If you get it wrong, it'll give you a slightly confusing error message:

$ svn update
Password for 'login' GNOME keyring: 
svn: OPTIONS of 'https://svn.dehnerts.com/svn/reponame': authorization failed: Could not authenticate to server: rejected Digest challenge (https://svn.dehnerts.com)

Anyway, hopefully that'll help someone. Let me know if you try this, and whether or not it helps.

Getting SNI working in Apache these days is pretty straightforward. Add an appropriate "<VirtualHost *:443>" snippet and it basically works out-of-the-box. Personally, I'm fond of creating an include file for the bulk of each vhost's configuration that I include from the <VirtualHost *:80> and <VirtualHost *:443> blocks so that I know the configuration of the two is in sync, but that isn't exactly necessary.

The rough spot that I encountered is that by default, name-based virtual hosting on port 443 isn't enabled. Since name-based virtual hosting is enabled on port 80, this is easy to miss (or, at least, I spent a long time assuming there was another issue).

/etc/apache2/ports.conf claims:

<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

Which is nonsense, given SNI (and was probably nonsense before SNI if you had a wildcard cert). What you actually want is:

<IfModule mod_ssl.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>

Adding a snarky comment too is always an option...

(Relatedly... You can now use https://alex.mit.edu/, https://adehnert.mit.edu/, or https://masada.mit.edu/, and each will give you an appropriate MITCA-signed certificate.)

Since I last posted any useful site news, I've:

• Added a LiveJournal crossposter to the blog --- most of my posts will be ending up on LiveJournal, if you'd rather read them there
• Made some minor tweaks to the software that runs this site and the blog --- less stupid host autodetection, nicer URLs for blog entries, etc.
• Moved to new hosting --- I have a new server (lushan, replacing borobudur), a new hosting VM (masada, replacing borobudur), and a new location (my desk at ET, replacing under my desk at home). This should provide better network connectivity, more IP addresses, and physical access if problems arise during the large fraction of the year when I'm in Massachusetts.
• Gotten a certificate trusted by orders of magnitude more people (though still not the general public...) --- it's now signed by the MIT CA instead of me
• Gotten a somewhat cooler URL --- https://alex.mit.edu/ --- no tilde, arguably cooler domain name

There's probably something else, but...

As you may have noticed, recently I've been setting up some new systems --- mostly VMs on my new server.

I name my servers alphabetically after UNESCO heritage sites. You can also take a look at my current names.

My new server is now lushan (UNESCO WP), a pretty awesome looking mountain with spiritual significance in China.

My main VM, which currently serves my website and will be taking over copan's role serving DNS and mail as well, is called masada (UNESCO WP) --- an old Judean fortress that shares a name with a fairly important planet in the Honor Harrington series.

For N, my leading candidates are:

• Nessebar (UNESCO WP), home of a variety of historic buildings
• Novgorod (UNESCO WP), a former Russian capital

I haven't found any names yet for O --- if you can find something that matches my naming scheme and sounds awesome, let me know.

For P:

• Pirin (UNESCO WP), another awesome mountain range
• Potosi (UNESCO WP), an old, massive industrial complex (as a bonus, it's in South America, which I think is currently under-represented amongst my names)

I encourage people to weigh in on what names I should pick, or suggest new ones (especially for the letters I don't having anything for yet).