The Grumpy Troll

Ramblings of a grumpy troll.

Pangolin update

The two exceptions: certificates/subversion and bind.

I had set up my system to just check out of svn the same layout used on my FreeBSD machine, which has a set of certificates under my control, some adjusted c_* scripts (mostly c_rehash which generates hash symlinks for both OpenSSL pre-1 and 1, with the two different hash schemes used, so applications using either system can still find the certs) and a Makefile, so that updates are just a “make”.

I know of the update-ca-certificates system used on Debian (and thus Ubuntu) and have used it in the past, putting my own certs into my own directory, but I've opted to nuke certain CA certs from the defaults and prefer to use my own definitions.

Of course the upgrade stomped all over this. It did leave my certs alone, but svn is (now?) using GnuTLS instead of OpenSSL, ssl-authority-files in ~/.subversion/servers is ignored and the default certificate location is undocumented. strace(1) to the rescue, it's ‘/etc/ssl/certs/ca-certificates.crt’. Appended ‘globnixCA3.pem’ to that, svn could now trust my server and I did not have to compromise identity verification to run ‘svn up’ and get my certs back. I did, however, end up deciding to blow away all symlinks in /etc/ssl/certs to get rid of the symbolic links created by the Debian tools, so that svn would stop complaining:

There were too many UTF-8 filenames unloved by svn; I assume that I need to configure svn somehow to know that the local filesystem is in UTF-8, but declined to chase down yet another rat-hole at this time.

After an svn update and a make I had everything working once more; I replaced the default ca-certificates file with a symlink to my main generated one and will update my Makefile to do so.

With that in hand, I could look into why my chroot'd install of bind was not working. Errors:

When I set up bind, I couldn't spot where modern Linux was shoving chroots these days and the setup wasn't using a chroot, so I tinkered myself. /var/chroot/bind using another svn checkout and a build script, which gets a similar layout to my primary nameserver's setup, just slightly different configuration so as to secondary zones from the primary.

This: {% codeblock lang:console %} $ strace -o fred -ff -v -s 512 named -t /var/chroot/bind -u bind -f -g -d 9 -E "” {% endcodeblock %} got me a bunch of fred.pid files; an fgrep for DST over them identified the path being used for finding the OpenSSL engine libraries. Also, some searching via Google revealed that apparmor is now being used and some updates would be needed there.

If it's not already obvious, I keep copious plain-text notes of the install for every OS of my own, and really need to get around to the overkill engineering of setting up puppet for my two boxes. :)

I edited /etc/apparmor.d/usr.sbin.named to gain the rules: {% codeblock %}

phil

/var/chroot/bind/** r, /var/chroot/bind/var/** rw, /var/chroot/bind/dev/null rw, /var/chroot/bind/etc/bind/secondary/** rw, {% endcodeblock %}

and ran: {% codeblock lang:console %}

mkdir -p /var/chroot/bind/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines

mount –bind /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines \

/var/chroot/bind/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines

mount -o remount,ro /var/chroot/bind/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines

{% endcodeblock %}

That worked; some minor tinkering of start-up scripts later, to mount and umount the bind-mount automatically and I have a functioning nameserver once more.

All this, so I can install the default libgnutls28 packages to test GnuTLS 3 on Ubuntu and see if there is anything useful I can adjust in Exim's src/EDITME suggestion for Local/Makefile to encourage GnuTLS 3 usage.

-The Grumpy Troll

Categories: exim bind GnuTLS Ubuntu svn certificates