It finally rained today in Zürich. For the first time all week it's not been so humid as to be hellishly uncomfortable. Awesome storm to watch too. Pity I'm going back home first thing tomorrow morning.

I'm not sure if it's Amazon's S3 that sucks or my hotel internet connection, but fucking hell it's annoying. I suspect my hotel internet connection. I hope it's my hotel internet connection.
Almost total lack of python docs for S3 aside, it's quite easy to work with. If I have the time this weekend I'll write a script to send all my backups there.

spew - a tiny web server for serving single files as needed so you can exchange files quickly and easily with other people locally (like when you're at a conference and everyone's using a laptop). All requests to the server will be redirected to the served file.

Usage: spew.py [options]

Options:
-h, --help            show this help message and exit
-f FILENAME, --filename=FILENAME
Name of file to serve
-p PORT, --port=PORT  Port to listen on. Default: 8000

e.g.: on the serving machine:

$ ./spew.py -f spew.py

And on the recipient:

$ wget 192.168.9.98:8000
--2008-05-26 21:32:40-- http://192.168.9.98:8000/
Connecting to 192.168.9.98:8000... connected.
HTTP request sent, awaiting response... 302 Found
Location: /spew.py [following]
--2008-05-26 21:32:40-- http://192.168.9.98:8000/spew.py
Connecting to 192.168.9.98:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2135 (2.1K) [text/x-python]
Saving to: `spew.py'

100%[======================================>] 2,135 --.-K/s in 0s

2008-05-26 21:32:40 (153 MB/s) - `spew.py' saved [2135/2135]

TODO: Use threads or fork/exec to handle multiple connections simultaneously
Add option to limit number of downloads.
Add option to compress files

A fun day of eating Indian food, playing pool and watching spaced. Good times.

Supposedly the 10 worst entry-level tech jobs. People these days seem to have an interesting definition of "worst". Sure the jobs seem mundane and kind of dull, but since when is a $70-80k job "entry level"? Where are the dead-end jobs that pay fuck all and work you to death?

check_ldap.py - a simple script to check if an ldap server is alive and responding.

Kerberized WebDAV Subversion

I recently switched to using kerberos with apache and DAV for auth on svn.evil.ie. I use Heimdal kerberos on my servers (running ubuntu), but the configuration should be pretty similar for MIT-KRB5.

Install some packages:

$ apt-get install libapache2-mod-auth-kerb libapache2-svn

Enable the modules:

$ a2enmod dav dav_svn auth_kerb

Extract a keytab for HTTP/your.host.name:

$ ktutil -k /etc/apache2/http_svn.keytab get HTTP/your.host.name

Make sure your apache user can read the keytab:

$ chown root:www-data /etc/apache2/http_svn.keytab
$ chmod 640 /etc/apache2/http_svn.keytab

Add the necessary bits to your apache config.

<Location /svn>
    Dav svn
    SVNPath /usr/local/svn
    <LimitExcept PROPFIND GET OPTIONS REPORT>
        AuthName "Authentication Required"
        AuthType Kerberos
        KrbAuthRealms YOUR.REALM
        KrbServiceName HTTP
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        Krb5Keytab /etc/apache2/http_svn.keytab
        Require valid-user
    </LimitExcept>
</Location>

Using LimitExcept as above allows anonymous reading of the repository - commits will require auth. If you're not ok with unauthenticated people accessing the repo, you should remove the LimitExcept tags.
KrbMethodK5Passwd on will prompt for a password if you don't have valid kerberos credentials.
The apache user requires write access to SVNPath or write operations will fail. Use of ssl is recommended at all times :)

Individual/group read/write access can be further restricted using the AuthzSVNAccessFile directive, though your auth file should specify usernames in the format username@YOUR.REALM, as mod_auth_kerb will get the kerberos principal with the realm attached.
i.e:

[/]
*@REALM = r
joeuser@REALM = rw

om nom nom

Today I found my new favourite Indian restaurant. Serious awesomeness.

The python-gdata package in Fedora 9 is way out of date (1.0.9) and lacks support for things like the picasaweb api, so I packaged 1.0.13

Firefox 3 and its insistence on making you jump through hoops to view sites using a self-signed ssl cert or certs signed by a root cert you don't have installed (i.e. CAcert) is making me angry. In fact, if ff3 is just going to deny access to a page secured with a CAcert certificate by default, what's the point in using the things if you can't guarantee visitors will have the root certificate installed in their browser? Someone remind me why using cacert is better than using a cert signed by my own CA again.

Tried an upgrade from ubuntu gutsy to hardy earlier. Looks like the only brokenness is openldap changing from openssl to gnutls - searches now die with

ldap_sasl_interactive_bind_s: Can't contact LDAP server

Good times.

Update: Seems that previous versions of openldap in ubuntu didn't care that the certificate CN didn't match the hostname. Using the correct hostname in the ssl cert makes it all better, which I did using subjectAltName
Future note to self, because I'll need to know this again sooner or later:
Make openssl do subjectAltName
/etc/ssl/openssl.cnf:
[ req ]
x509_extensions = v3_ca
req_extensions = v3_req

[ v3_req ]
subjectAltName = "DNS:ldap2.evil.ie, DNS:ldap3.evil.ie"

Generate a new key/certificate
$ openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
View the cert
$ openssl x509 -in server.pem -noout -text