Tadek’s Blog

I recently started getting nagmails about running out of quota on my home directory. Being a very messy user, I had no idea where the space went. I tried playing with du manually, but it’s much easier with xdu:

sudo apt-get install xdu
du > /tmp/blah
xdu -n /tmp/blah

Real-time map of planes approaching the Zurich airport. Now I know why my plane was making crazy circles before landing. http://radar.zhaw.ch/radar.html

(almost) real-time map of Swiss trains http://www.swisstrains.ch

http://net.its.hawaii.edu/advanced/make_work/IPSec/MacOSXTiger/mactigercert.html – how to import a trusted CA certificate in OSX.

http://www.linotype.com/ – a (commercial) site about fonts: let’s search in numerous ways has an amazingly comprehensive information about the creator and the history of each font.

http://picsfromtheoffice.blogspot.com/ – awesome in-flight photos. I wish my “office” had such views

I know it’s easy, but every time I write it I have to study the man page of find to figure out the correct parameters:

File only deletion:

find <dir> -atime +7 -type f -print | xargs rm -f

Recursive deletion (be careful):

find <dir> -atime +7 -print | xargs rm -rf

I just enabled SVN access on my server through the web interface. It was quite easy and, since we have a Postgres DB authentication, there’s no need to edit inconvenient password files

All I had to do was to enable the SVN module: link dav_svn.{load|conf} in mods-enabled and add the following line to the SSL-ed vhost.

<Location "/svn/foo">
   SVNPath /var/lib/svn/foo
   Dav svn
  <LimitExcept OPTIONS GET>
    Require user user@example.com user2@example.com
  </LimitExcept>
</Location>

Since the SSL-ed vhost already requires authentication, I didn’t have to change anything. I also had to create an SVN repository svnadmin create --fs-type fsfs /var/lib/svn/foo and change the permissions to www-data.

The checkout command is:

svn –username user@example.com –password my_secret_password co https://my.example.com/svn/foo

SVN caches the username and password, so any further operations are done without prompting you for it. If you don’t like it, you can disable it with --no-auth-cache.

Finally, one annoying thing. Initially, I would just try to connect without –username and SVN would first try my Unix user name and then ask for it. Unfortunately, some (but not all) users I tried in this way would get a mysterious:

svn: PROPFIND request failed on '/svn/foo'
svn: PROPFIND of '/svn/foo': authorization failed (https://example.com)

WTH?

While upgrading apache 2.0 -> 2.2 I found that two configuration options have changed:

• AuthAutoritative -> AuthBasicAuthoritative (needs to be set to Off for mod_auth_pgsql to work).
• AuthDigestFile -> AuthUserFile

Plus there has been a log of changes in apache2.conf. I looked at the changes we made (keeping /etc/ in SVN comes in handy, in spite of occasional pain) and pasted them to the vanilla apache2.conf that came with 2.2.

While upgrading a remote server from sarge to etch including the new kernel, the server did not come up. After attaching a console (thanks Hetzner!) I found out that the network interface got mysteriously renamed to eth2!

After snooping around a bit, I found out that the culprit was udev, more specifically /etc/udev/rules.d/z25_persistent-net.rules which says:

 # This file was automatically generated by the /lib/udev/write_net_rules
 # program, probably run by the persistent-net-generator.rules rules file. 
 #
 # You can modify it, as long as you keep each rule on a single line.
 # MAC addresses must be written in lowercase.
 # PCI device 0x1106:0x3065 (via-rhine)
 SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:76:af:2f:9d", NAME="eth0"

It also contained two entries for bogus eth0 and eth1 (usb dongle got identified as a network card?). After removing the and relabeling interfaces everything is back to normal now.