Tadek’s Blog

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.

While upgrading my server, I had to create a new version of Cyrus-SASL packages with the crypt patch. This turned out to be more difficult as I thought as just patching the raw source would conflict with debian patches applied after that and the package building would fail. Fortunately, I learned about (dpatch)[http://www.tuxmaniac.com/blog/2008/01/25/dpatch-just-superb-a-short-how-to/], which is a standard mechanism for patching stuff in Debian.

Once I figured out how to do it, it tunred out to be very simple:

1. Unpack the original orig.tar.gz
2. Apply the Debian diff (this would create a debian subdirectory)
3. Edit changelog file to add a new release (so that we can keep track of it).
4. Run dpatch-edit-patch fixing_foo to create a patch. This will create a shell with mounted source package and any changes you make there will be included in the diff.
5. Exit the shell without changing anything. You will change things after making sure that the patch is applied in the correct order.
6. Edit 00list to set the patch ordering.
7. Run dpatch-edit-patch again now, with all the previous patches applied.
8. Make the necessary changes.
9. Build the target package with debuild-pbuilder (this will download all the dependencies too).
10. Install the pakcages with dpkg -i (I could also create my private apt-repository for this. I wrote about in in a blog entry about pbuilder).
11. Pin the packages so that they will not get upgraded echo "package hold" | dpkg --set-selection

I found this essay on Slashdot yesterday: how to recognize a good programmer. Some of the comments were quite insightful, but many followed the following pattern.

"I am a good programmer myself and I match X% of the qualities you mentioned. Therefore, your article is excellent/good/not so good/crap (depending on the value of X)

I also read two other articles on the topic:

• Confessions of a Terrible Programmer.
• Where are Software Engieers of Tomorrow.

I just came across this website: http://md5.rednoize.com, http://md5.cryptobitch.de, http://passcracking.com They have a large dictionaries of unsalted MD5/SHA passwords. I played with it for a little bit. It’s amazing and scary how little entropy there is in a simple dictionary-based passwords with few modifications! Another conclusion is that you should never use unsalted passwords in your programs.