subversion compile and install

 

as non-privileged user…

Most Open Source software projects invite persons using their product to experience the joys of compiling the product. Subversion does not.

 

from INSTALL in the 1.5.6 subversion source code:

This document is written for people who intend to build Subversion from source code. Normally, the only people who do this are Subversion developers and package maintainers.

If neither of these labels fits you, we recommend you find an appropriate binary package of Subversion and install that.

 

why non-privileged?

I work on Solaris 10, in a large financial environment, with separation of responsibilities and a restricted availability of “root”. Most software packages assume that you will be installing as root and they use common and accessible directory locations like “/usr/local”. Most software will build easily or with slight difficulty on linux, and can be much more difficult on Solaris. You will be missing tools and libraries common to Linux.

I currently use CVS, and that’s got some shortcomings – it doesn’t handle binaries easily or consistently, you can’t move a directory without losing history, and it is no longer under development. I have a new container, a Solaris 10 sparse container, in which I wanted to compile and install apache2 and subversion as a non-privileged user. No root. No access to install extra needed packages on /usr/local. On the other hand, complete control over the application without having to consult with the group responsible for root on the container…

what worked

Here’s what worked. Not the dead ends, but what actually resulted in apache and subversion installed, along with apr, apr-util and serf, in a filesystem /apps. This compilation uses serf and FSFS in subversion – it blocks out Berkeley DB and neon.

Berkeley was installed in /usr/local, but I couldn’t get the configure script to find it – and in reading further FSFS is the default in subversion, and has stabilized and become a better solution than Berkeley DB. If you reboot in an unstable state, FSFS will simply recover, where Berkeley DB can require a DBA to recover the database before the system returns to useful.

neon seemed from some errors I encountered to have filesystem access issues (I got a long dump at one point of memory addresses during the make process, all locations for neon libraries and files). Once I eliminated neon, I also got an svnadmin binary that could create a repository without causing “BUS ERROR: segmentation fault”. Of course, I also dropped back from subversion 1.6.0 code to 1.5.6, and compiled and pointed to apr and apr-util from subversion-deps for 1.5.6, and serf from google. It could be any one of those changes.

This was not as simple as compile and go – this was running “configure” and resolving errors, then “make” and resolve yet more errors, and finally, building mod_dav_svn in subversion successfully, installing and finding a “BUS Error: segmentation fault” on running “./svnadmin create /apps/repos/testme”.

I compiled subversion fairly quickly to use svnserver. That compile and install worked, and didn’t create a core file, didn’t seg fault. But it left some problems.

svn + apache2

Many of my developers work from windows. Creating secure access over ssh and svn (svn+ssh://) using eclipse SDK and subclipse (subversion plugin for eclipse) was the initial idea, from a quick pass over subversion, but once svnserver was up and running and I tried it, this wasn’t as simple. There are several articles on integrating subversion, ssh and windows. None of the solutions looked simple or elegant. And wide open unsecured traffic was not acceptable.

I determined best practice pointed us to subversion access through web_dav_svn -> web_dav -> apache2 (https://). This brought authentication away from centralized auth and allowed fine grained control over the access granted via htpasswd and .htaccess files. It allowed us to restrict unsecured access and redirect http to https, and encrypt using SSL. It kept us from having to work ssh onto windows for each developer, instead we could have a simple eclipse/subclipse plugin access demonstrated and from that point they were able to customize on their own.

What I wanted was:

  • untar subversion-1.5.6 and subversion-deps-1.5.6 in /apps/src (they layer over each other)
  • first build and install the -deps apr and apr-util into /apps/local
  • then build apache2 against /apps/local/apr and /apps/local/apr-util
  • install apache2
  • build and install serf
  • remove serf, apr, and apr-util subdirectories and source code from within subversion-1.5.6
  • build 1.5.6 against apxs in apache, without Berkeley DB, without neon, and specifying /apps/local/apr, /apps/local/apr-util, and /apps/local/serf
  • install and test

process

  • create subdirectory /apps/src, place all tarballs in this directory
  • untar subversion & subversion-deps version 1.5.6 (these tar onto each other)
  • cd subversion-1.5.6/apr
  • ./configure –prefix=/apps/local/apr
  • make && make install
  • cd ../apr-util
  • ./configure –prefix=/apps/local/apr-util –with-apr=/apps/local/apr
  • make && make install
  • apache2: untar httpd-2.2.11
  • ./configure –enable-dav –enable-so –prefix=/apps/apache2_2.2.11 –enable-ssl –with-ssl=/usr/local/ssl –with-apr=/apps/local/apr –with-apr-util=/apps/local/apr-util –enable-modules –enable-mods-shared=”most ssl dav”
  • make && make install

    This way apache2 builds against apr and apr-util compatible with subversion 1.5.6
    and then build subversion against it as well..

  • ln -s /apps/apache2_2.2.11 /apps/apache2
  • compile and install serf
  • ./configure –prefix=/apps/local/serf –with-openssl=/usr/local/ssl
  • make && make install
  • remove serf, pr and apr-util from subversion

compile subversion

./configure –prefix=/apps/svn –with-ssl –with-libs=/usr/local/ssl –without-berkeley-db –with-apxs=/apps/apache2/bin/apxs –with-openssl=/usr/local/ssl –without-neon –with-serf=/apps/local/serf –with-apr=/apps/local/apr –with-apr-util=/apps/local/apr-util

make && make install

test:

[appadmin@sccvsapp01p bin] $ ./svnadmin create /apps/repos/testtoo
[appadmin@sccvsapp01p bin] $

no core dump…
ONWARD to configure and test apache2 and subversion…

httpd.conf:

  • change all references to apache2_2.2.11 to apache2 (makes the httpd.conf generic rather than subject to needing a migration after a point release upgrade…)
  • change port 80 to a non-priveliged port (8080)
  • check for
    • LoadModule dav_module modules/mod_dav.so
    • LoadModule dav_module modules/mod_dav.so
    • LoadModule ssl_module modules/mod_ssl.so
  • add in ServerName hostname.domain.com:8443 Some of the apache level sanity validation requires a statement of the local host.
  • add in SSL stuff (this IS httpd from source – the default httpd.conf had the ssl-module load statement, but no explicit SSL configuration

    #
    # Note: The following must must be present to support
    # starting without SSL on platforms with no /dev/random equivalent
    # but a statically compiled-in mod_ssl.
    #


    <IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin
    </IfModule>


    # =================================================
    # SSL/TLS settings
    # =================================================


    Listen 0.0.0.0:8080
    Listen 0.0.0.0:8443


    SSLEngine on
    #SSLOptions +StrictRequire


    #<Directory />
    # SSLRequireSSL
    #</Directory>


    SSLProtocol -all +TLSv1 +SSLv3
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM


    SSLMutex file:/apps/apache2/logs/ssl_mutex


    SSLRandomSeed startup file:/dev/urandom 1024
    SSLRandomSeed connect file:/dev/urandom 1024


    SSLSessionCache shm:/apps/apache2/logs/ssl_cache_shm
    SSLSessionCacheTimeout 600


    SSLPassPhraseDialog builtin
    SSLCertificateFile /apps/apache2/conf/ssl.crt/server.crt
    SSLCertificateKeyFile /apps/apache2/conf/ssl.key/server.key


    SSLVerifyClient none
    SSLProxyEngine off


    <IfModule mime.c>
    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl
    </IfModule>

  • create ssl certificate (self-signed). I installed in /apps/apache2/conf/ssl.crt and ssl.key, naming the .crt and ,key files for the server hostname and then symbolically linking them to the generic “server.crt” and “server.key”.
  • restart apache2 and test https://host:8443/ – you should get the “It works!” apache test page, thus validating the SSL certificate and setup from a browser level
  • parent directory for svn

    <Location /svn>
    DAV svn
    SVNParentPath /apps/repos
    </Location>

Restart apache2, and go look at the log – should now show the svn component:


[Tue Mar 31 11:01:52 2009] [notice] Digest: generating secret for digest authentication ...
[Tue Mar 31 11:01:52 2009] [notice] Digest: done
[Tue Mar 31 11:01:52 2009] [notice] Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8d configured -- resuming normal ope
rations
[Tue Mar 31 15:15:44 2009] [notice] caught SIGTERM, shutting down
[Tue Mar 31 15:15:48 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Tue Mar 31 15:15:51 2009] [notice] Digest: generating secret for digest authentication ...
[Tue Mar 31 15:15:51 2009] [notice] Digest: done
[Tue Mar 31 15:15:51 2009] [notice] Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8d SVN/1.5.6 configured -- resuming
normal operations

validate

I used eclipe with subclipse installed in it – the url for the repository was https://host:8443/svn/testme

On the command line

[dsm@dali ~] $ svn checkout https://hostname:8443/svn/testme
Error validating server certificate for 'https://hostname:8443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: hostname.domain.com
 - Valid: from Wed, 01 Apr 2009 14:44:42 GMT until Thu, 01 Apr 2010 14:44:42 GMT
 - Issuer: issuer, Massachusetts, US
 - Fingerprint: ec:74:42:f4:98:0b:5c:62:14:34:85:14:60:38:73:1b:bc:8d:18:27
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Checked out revision 0.
[dsm@dali ~] $

more…

From here, I need security, and then to import existing cvs repositories into subversion one by one, in liaison with the developers. I also need to restrict access to SSL only, install a third-party certificate, and work further to validate subclipse and eclipse, to where I can roll up a development environs they can just unzip and use.

 

— doug