Tadek’s Blog

I recently wanted to test TLS with SMTP. I followed instructions on 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.

SVNPath /var/lib/svn/foo
Dav svn

Require user user@example.com user2@example.com

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](http://frost.ath.cx/software/cyrus-sasl-patches/). 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.