FreeBSD svn and passwords

I have been getting the message about storing un-encrypted svn passwords for ages on FreeBSD and Ubuntu. I finally thought I would look into how you store encrypted passwords.

-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://dev.sinodun.com:443> Sinodun Projects Subversion Repository
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/jad/.subversion/servers'.
-----------------------------------------------------------------------

Lots of goggling later the best I could find was an article about gnome-keyring-daemon and subversion which mentions the need for libsvn_auth_gnome_keyring-1.so. A quick search found this was missing on my system. A moment of dumbness later I remembered make config and found the port config option needed.

Screenshot

re-installing the port unfortunately broke svn with the following message:

svn: E175002: OPTIONS of 'https://dev.sinodun.com/svn/projects': SSL handshake failed: SSL disabled due to library version mismatch (https://dev.sinodun.com)

Thanks to this that was quickly fixed by rebuilding neon:

sudo portupgrade -f neon*

Library Versioning

I have been discovering all about library versioning. What I found came as a surprise to me and others especially those from a sysadmin background.

Basically it all comes down to the fact that the numbers on the end of a library name may not be what you expect and it is even more complex on OS X.

Libtool on Linux

For example consider the following libraries on a recent CentOS 6.2 install:

  • /lib64/libparted-2.1.so.0.0.0
  • /lib64/libproc-3.2.8.so
  • /lib64/libgcrypt.so.11.5.3

These show the three different ways in which a library may be versioned. Chapter 7 of the libtool manual discuses this subject. Libtool library versions are purely concerned with the supported API or interface that the library supports. It determines what the linker will allow to be linked.

libtool library versions are described by three integers:

  • current
    • The most recent interface number that this library implements.
  • revision
    • The implementation number of the current interface.
  • age
    • The difference between the newest and oldest interfaces that this library imple- ments. In other words, the library implements all the interface numbers in the range from number current – age to current.

If two libraries have identical current and age numbers, then the dynamic linker chooses the library with the greater revision number.

This is (or should be) what you see for libgcrypt.so.11.5.3. Running gpg –version shows that the version of libgcrypt is in fact

# gpg --version
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5

The version of libgcrypt is 1.4.5 but its API is 11.5.3.

In order to set the Libtool library version you set the  -version-info 11:5:3 flag using libmylib_la_LDFLAGS in your Makefile.am (See the automate manual).

By contrast /lib64/libproc-3.2.8.so has no numbers after the .so. They all appear before it. This reflects the fact that the developers, for whatever reason decided to use the version number of the application in the library. Running free gives

# free -V
procps version 3.2.8

This is achieved by using the flag  -release in place of -version-info in Makefile.am.

libparted-2.1.so.0.0.0 shows both. Running parted gives

# parted -v
parted (GNU parted) 2.1

OS X

According to Fink the situation on OS X is slightly different. There is a “strict distinction between shared libraries and dynamically loadable modules”. On linux any “shared code can be used as a library and for dynamic loading”. On OS X there are two types of library MH_DYLIB (a shared library) and MH_BUNDLE (a module). MH_DYLIB carry the extension .dylib and can be linked against in the familiar -lmylib at compile/link time. They can not be loaded as a module using dlopen(). MH_BUNDLE on the other hand can be dlopened. Apple suggest naming these .bundle however, much ported software uses .so instead. It is not directly possible to link against bundles as if they were shared libraries.

Selecting an interval from a integer column in PostgreSQL

I needed to create a select that combined a timestamp in one column with an interval specified in minutes from another column. After much manual reading and searching I found the answer on stackoverflow. My SQL looked something like:

SELECT d.time AT TIME ZONE 'UTC' + interval '1 minute' * d.minute as time FROM my data d ...

Much faster than using Perl’s DateTime::Format::Pg and DateTime::Duration modules to do the addition.

Upgrading the Subversion plugin on Jenkins

Since upgrading our subversion server to 1.7 I have tried several times to upgrade the subversion plugin on Jenkins (v1.457) from 1.34 to 1.39. Using the plugin manager it downloads the plugin and asks you to restart. However, when you restart the jenkins.war expands and overwrites the newly downloaded plugin with the 1.34 version that I guess is shipped in the war.

The solution is easy. Use the plugin manager to download the plugin and change the ownership of the subversion.jpi file so that the jenkins user can not overwrite it. Then restart. (This will make future upgrades more difficult as you will have to revert the ownership).

Cutting down the noise of automake

Adding AM_SILENT_RULES([yes]) to your configure.ac will greatly reduce the output of make. It will look very similar to the linux kernel build:

Making all in common
  CC     strlcat.o
  CC     strlcpy.o
  AR     libcompat.a
Making all in netconf/src/ncx
  CC     libncx_a-b64.o
  CC     libncx_a-blob.o
  CC     libncx_a-bobhash.o
  CC     libncx_a-cap.o

This line must go after your AM_INIT_AUTOMAKE initialization. You need to be using automake >= 1.11. There is a good explanation here.