Subversion with Cyrus SASL

I’ve been keeping my programming stuff in svn repositories for quite some time now, and I came to running my own server software instance, after one free service had unexpectedly changed its rules and another just vanished. The server infrastructure my account is on runs FreeBSD 9.2 with nginx 1.4.7, and while this seems robust enough, it did not make setting up subversion easier. I reckon you should encrypt just about everything, to keep Uncle Sam entertained (or any of your other uncles, for that matter), even if what you put there is just your kitchen recipes or your favourite deformed convolutions no one really cares about. But being a user with no root rights behind an nginx server, with just a virtual web server means that the https access is out, having it this way would require my own IP number, and my own Apache instance, and I was not ready to go that way. That leaves one possibility: run the svnserve (1.8.8) server coupled with Cyrus SASL 2.1.26 encryption layer.

Now comes the tricky part, because the standard documentation for Cyrus SASL usually assumes that it is the root that installs it. I had to make a custom build, so that the database file be in a directory of mine. Attempts to follow the standard ./configure way with some additional guessed parameters: ./configure --with-configdir=$HOME/lib/sasl2 --prefix=$HOME --with-dbpath=$HOME/lib/sasl2/gdbmpwd --with-dblib=gdbm --with-gdbm=/usr/local --with-plugindir=$HOME/lib/sasl2 failed, everything seemed to build fine, but the auxprop list displayed with the installed pluginviewer utility said: Installed and properly configured auxprop mechanisms are: <none>. dgbm is a key-value file database library, one of the three supported by cyrus sasl, and it was present on the server, dbpath is the file in which gdbm is supposed to store passwords, prefix=$HOME tells make to install files in your user’s account rather than system directories. I then tried to add --enable-static=yes --disable-shared, and this failed at build time, saying that the code references functions from gdbm that are undefined. Mysterious, since the lib was at the path indicated. There were also other messages from the linker, since it turns out that cyrus sasl has dependencies on more libraries. These are poorly documented, if you’re not a specialist, you may miss that fact and have it thrown at yourself by the build. However, if you don’t need some services, you may disable them at configure time. I decided that the minimum I want is the DIGEST-MD5 method, so finally my configure parameters that did work were as follows:
./configure --enable-sample=no --enable-obsolete_cram_attr=no --enable-static=yes --enable-shared=no --disable-alwaystrue --enable-cram=no --enable-otp=no --disable-krb4 --enable-gssapi=no --disable-plain --disable-anon --disable-sql --without-des --with-openssl=$HOME --with-configdir=$HOME/lib/sasl2 --prefix=$HOME --with-dbpath=$HOME/lib/sasl2/gdbmpwd --with-dblib=gdbm --with-gdbm=/usr/local --with-plugindir=$HOME/lib/sasl2 --without-saslauthd --without-authdaemond LDFLAGS='-L/usr/local/lib' LIBS='-lgdbm'
The last part, LDFLAGS and LIBS is there to tell the build where to find the dgbm functions it was missing. Why that needs to be done is a mystery to me, doing it that way results in some build instructions getting it twice or even three times, but apparently a handful is getting just those. If you fiddle with it, just don’t put any enable or with directives after the LDFLAGS parameter, they would be ignored, and belong before. Now, running pluginviewer from $HOME/sbin should tell you that
Installed and properly configured auxprop mechanisms are:
sasldb
List of auxprop plugins follows
Plugin "sasldb" , API version: 8
supports store: yes

Installed and properly configured SASL (server side) mechanisms are:
DIGEST-MD5 EXTERNAL
Available SASL (server side) mechanisms matching your criteria are:
DIGEST-MD5

Cyrus SASL is one of the dependencies that SVN needs. The other ones I installed locally on my account are Apache Portable Runtime and APR-utils, since I had trouble with versions installed globally on the server some time ago, zlib and serf, but they configured and built without much trouble, just as their respective documentation said, I just had to take care to indicate again the prefix, and tell configure that some dependent libraries were to be found in $HOME:
APR: ./configure --prefix=$HOME, then gmake and gmake install
APR-utils: ./configure --prefix=$HOME --with-apr=$HOME, then gmake and gmake install
zlib: ./configure --prefix=$HOME, then gmake and gmake install
The one exception was serf with
scons APR=$HOME APU=$HOME PREFIX=$HOME
(APU is just APR-util), which displayed some error messages, but seemed to build nevertheless. I am not sure if these errors will not induce problems later on, but for now everything seems to work.

At last comes the build of subversion itself. An attempt at ./configure --with-apr=$HOME --with-apr-util=$HOME --with-sasl=$HOME --with-zlib=$HOME --with-serf=$HOME --prefix=$HOME produced a message that configure cannot find Cyrus SASL. Looking into the config.log file I found out that the problem is that again, as during the SASL build, the linker complains about not being able to find definitions of symbols related to gdbm. So the next attempt was ./configure --with-apr=$HOME --with-apr-util=$HOME --with-sasl=$HOME --with-zlib=$HOME --with-serf=$HOME --prefix=$HOME LDFLAGS='-L/usr/local/lib' LIBS='-lgdbm', which succeeded, but the following make did not, saying relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC. All right, SASL was built as static, so finally I tried this:
./configure --with-apr=$HOME --with-apr-util=$HOME --with-sasl=$HOME --with-zlib=$HOME --with-serf=$HOME --prefix=$HOME --enable-static --disable-shared LDFLAGS='-L/usr/local/lib' LIBS='-lgdbm'
and it worked, as did the subsequent make and make install.

I wrote that in the hope that it may save someone three workdays of sheer guessing. I am not really able to explain why this works, and why the more standard configurations do not on my account. Trying to do standard builds on my debian box seemed to be more successful, but that was not the point. I don’t know if the above hacks are the right method to solve the problem, I would be curious to know a better way. I will also have to look at OTP-One Time Passwords, turning them on now breaks the builds, and I don’t yet know how to deal with it. Any hints?

To finish, I must tell you that the only library of those mentioned above, that does not have any signature or integrity hash is the fundamental security library Cyrus SASL. How lame.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: