Tadek’s Blog

I recently wanted to test TLS with SMTP. I followed instructions on http://qmail.jms1.net/test-auth.shtml and got it to work in less than 30s

In short:

perl -MMIME::Base64 -e 'print encode_base64("\000user\000password")'
openssl s_client -starttls smtp -crlf -connect <ip>:<port>
auth <auth_command>
mail from:<tadek@pietraszek.org>
rcpt to:<tadek@pietraszek.org>
data
...
.

Interestingly, when I tried typing RCPT s_client would interpret it as “renegotiate”, which confused me a bit, but you can inhibit it with --quiet or type it in lowercase like I did

T.

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

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

Writing some shell scripts I needed to do some a little fancier variable substitution than the standard shell offers. The heavyweight solution would be to write a perl one-liner, but this is, well…, heavyweight?

Here’s a couple of patterns I used:

• --parameter=$(sed -re 's/ /,/g' -e 's/(^|,)/\1file:/g' <<<$INPUT) - replaces spaces with commas and prepends file to every file.
• --parameter=$(awk '{split($0, a, /@/); printf "%s-?????-of-%05d", a[1], a[2]} <<<$INPUT)'
- replaces file@5 with file-?????-of-00005
• --parameter=$(awk '{sub(/.*:/, ""); print $0}' <<<$INPUT) - removes everything before the colon.