Custom-Compiling Apache and Subversion

Listen Print Discuss

Custom-Compiling Apache and Subversion
Pages: 1, 2

Compiling Subversion

I downloaded the latest Subversion source code. At the time of this writing, that was 1.1.3.

[root@localhost conf]# cp /downloads/subversion-1.1.3.tar.gz /usr/local/src
[root@localhost conf]# cd /usr/local/src/
[root@localhost src]# tar -xzvf subversion-1.1.3.tar.gz
[root@localhost src]# cd subversion-1.1.3

(Again, note that if you are not using GNU tar, you will first have to gunzip the source code and then untar it.)

As you can see with my runconfigure.sh wrapper script for Subversion, I was very specific about which features I did and did not want in my Subversion installation. Because I knew exactly what I wanted, I could afford to do this, and it spared me from prerequisite hell.

#!/bin/sh
# runconfigure.sh -- wrapper script for ./configure
./configure \
--with-apr=/usr/local/apache2 \
--with-apr-util=/usr/local/apache2 \
--without-berkeley-db \
--without-zlib \
--without-jdk \
--without-jikes \
--without-swig \
--without-junit

Once I saved runconfigure.sh, I ran it and installed Subversion:

[root@localhost src]# ./runconfigure.sh
[root@localhost src]# make
[root@localhost src]# make install

For the convenience of whoever has shell access to the machine, I wanted to ensure that Subversion was in the path (and, in fact, first in the path, because I wanted it to run by default over any older version that may have shipped with my operating system).

First, I needed to ensure that the binary could find Subversion's shared libraries. On Linux, I did this by ensuring that /etc/ld.so.conf contained the directory /usr/local/lib. (The /etc/ld.so.conf layout is just a list of directories, one per line--a refreshingly simple syntax, in this age of XML.) If your copy of /etc/ld.so.conf is missing /usr/local/lib, add it, and then run ldconfig with no arguments. On Solaris, ensure that $LD_LIBRARY_PATH contains /usr/local/lib. If that directory is not present, add it in /etc/profile and export LD_LIBRARY_PATH so that all users automatically pick it up when they log in. Also, if you are on Solaris, change your current environment so that you have access to Subversion's libraries right away:

LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH

On any Linux/Unix system, be sure to add Subversion to your path. On my machine, I placed it first in the path, so that it would override any older Subversion that might be in /usr/bin:

PATH=/usr/local/bin:$PATH
export PATH

On any Linux/Unix system, you may want to ensure that anyone who logs on to the system has Subversion in the path. Here's a nifty way I did that without having to open a text editor:

[root@localhost src]# cat >> /etc/profile <<EOR
> PATH=/usr/local/bin:\$PATH
> export PATH
> EOR

Creating the Repository

Next, I needed to create a Subversion repository. In real life, I actually used cvs2svn to port an entire CVS repository to Subversion; as long as you already have Python installed on your system, cvs2svn is fantastic. You may not have an existing repository to migrate, though, so here's how to create a sample repository and check in a one-file project:

[root@localhost src]# mkdir /usr/local/svn_repository
[root@localhost src]# svnadmin create /usr/local/svn_repository
[root@localhost src]# cd /tmp
[root@localhost tmp]# mkdir -p test_project/trunk
[root@localhost trunk]# cd test_project/trunk
[root@localhost trunk]# cat > test_file.txt <<EOS
> this
> is
> a
> test
> file
> EOS
[root@localhost trunk]# svn import -m "initial checkin" .
    file:///usr/local/svn_repository/test_project/trunk

Integrating Subversion with Apache

I wanted to use basic authentication to restrict access to my repository, so I created a .htpasswd file. What better location for this than the repository's configuration directory? Please note that for illustrative purposes, I used htpasswd's ability to accept passwords on the command line; you may want to make htpasswd prompt you for the passwords instead. I also used ridiculously insecure example passwords for illustrative purposes. Note how the first invocation of htpasswd used the -c switch to create the password file, whereas subsequent ones did not. Finally, if you don't mind having the passwords briefly shown in clear text, and you have to create a lot of users, consider making this a shell script that you can just run once and then delete when you are done:

[root@localhost trunk]# /usr/local/apache2/bin/htpasswd -c -m
    -b /www/svn_repository/conf/htpasswd user1 password1
[root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m
    -b /www/svn_repository/conf/htpasswd user2 password2
[root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m
    -b /www/svn_repository/conf/htpasswd user3 password3

One step I didn't want to forget was making the repository readable and writable by the user nobody, which Apache runs by default. (Forgetting this step would produce sorts of errors from Apache.)

[root@localhost trunk]# chown -R nobody /usr/local/svn_repository

Finally, I changed httpd.conf to let Apache know about my repository and the fact that only authorized users should read and write to it. I plan to use my Apache installation only for Subversion, so I made the Subversion repository the root of Apache's filesystem. In /usr/local/apache2/conf/httpd.conf, I made the line containing DocumentRoot look like:

DocumentRoot /usr/local/svn_repository

Next, I added these lines to the end of /usr/local/apache2/conf/httpd.conf to let Apache know that /usr/local/svn_repository is a Subversion repository and that access uses SSL and basic authentication:

<Location />
    DAV svn
    SVNPath /usr/local/svn_repository

    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /usr/local/svn_repository/conf/htpasswd
    Require valid-user
    SSLRequireSSL
</Location>

After those lines in /usr/local/apache2/conf/httpd.conf, I added the following mod_rewrite lines as a nice way to forward browsers from http to https:

# redirect all port 80 requests to 443
RewriteEngine on
RewriteCond "%{SERVER_PORT}"    "^80$"
RewriteRule "^(.*)$"            "https://%{SERVER_NAME}$1" [R,L]

Ensuring Apache Starts When the Server Does

Chances are your Linux/Unix installation shipped with Apache already installed. My Fedora Core system did, so I disabled it to keep it from interfering with my custom Apache, which wanted to use the same ports.

The method for disabling the automatic startup of Apache is different from system to system. Fedora Core uses a spiffy system utility called chkconfig to manage the starting and stopping of system services at various runlevels. I asked chkconfig what runlevels Apache was running at:

[root@localhost etc]# chkconfig --list httpd
httpd           0:off   1:off   2:off   3:on    4:on    5:on    6:off

I told chkconfig not to run Apache at the three runlevels where it was on, and then I shut down Apache manually (as it was currently running).

[root@localhost etc]# chkconfig --level 345 httpd off
[root@localhost etc]# chkconfig --list httpd
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@localhost etc]# /etc/rc.d/init.d/httpd stop
Stopping httpd:                                            [  OK  ]

At that point, I needed to put a different script in /etc/rc.d/init.d to start and stop my custom Apache. Fortunately, /usr/local/apache2/bin/apachectl is a shell script that already mostly follows the conventions of a Unix init script: it already takes start and stop as arguments. However, it uses the nonstandard startssl and stopssl to make Apache use SSL, so I had to do some editing.

First, I copied Apache's control script into Fedora Core's standard location for init scripts:

[root@localhost etc]# cp /usr/local/apache2/bin/apachectl
    /etc/rc.d/init.d/apache_svn

Next I borrowed, in altered form, the first few lines of Fedora Core's /etc/rc.d/init.d/httpd script and put them at the top of /etc/rc.d/init.d/apache_svn, so that Fedora Core's spiffy chkconfig program could use apache_svn. (Note that chkconfig's parameters in init scripts seem to be only comments, but they are more than that.) Here are the lines I added just below #!/bin/sh in /etc/rc.d/init.d/apache_svn:

#
# apache_svn        Startup script for the Apache HTTP Server
#
# chkconfig: - 85 15
# description: This Apache installation is really a Subversion repository.
# processname: httpd
# config: /usr/local/apache2/conf/httpd.conf

Then, I removed these two stanzas:

stopssl|sslstop|stop-SSL)
    $HTTPD -k stop -DSSL
    ERROR=$?
    ;;
startssl|sslstart|start-SSL)
    $HTTPD -k start -DSSL
    ERROR=$?
    ;;

Next, I changed this stanza:

start|stop|restart|graceful)
    $HTTPD -k $ARGV
    ERROR=$?
    ;;

to this:

start|stop|restart|graceful)
    echo -n $"Apache + SVN $ARGV, status: "
    $HTTPD -k $ARGV -DSSL
    ERROR=$?
    [ "$ERROR" -eq 0 ] && echo "OK" || echo "FAILED"
    ;;

to define the property SSL for all four targets captured by that stanza, as well as to give some feedback on the command line (though not as pretty as Fedora Core's scripts).

Next I told chkconfig to add apache_svn to its setup, and to make it active at runlevels 3, 4, and 5:

[root@localhost init.d]# chkconfig --add apache_svn
[root@localhost init.d]# chkconfig --list apache_svn
apache_svn      0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@localhost init.d]# chkconfig --level 345 apache_svn on
[root@localhost init.d]# chkconfig --list apache_svn
apache_svn      0:off   1:off   2:off   3:on    4:on    5:on    6:off

Then I started Apache using its new init script.

[root@localhost init.d]# /etc/rc.d/init.d/apache_svn start
Apache + SVN start, status: OK

Testing the Connection

The moment of truth came when I got to test repository access from my web browser. I went to https://localhost/, accepted the cert, entered one of the sample usernames and passwords, and browsed my Subversion repository.

The command-line client worked too:

[root@localhost init.d]# cd /tmp
[root@localhost tmp]# svn co https://localhost/test_project/trunk test_project
Error validating server certificate for 'https://localhost:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Test-Only Certificate
 - Valid: from Mar 12 00:48:54 2005 GMT until Mar 12 00:48:54 2006 GMT
 - Issuer: Test-Only Certificate
 - Fingerprint: 56:f8:be:cc:df:69:c4:64:43:ba:d4:0b:5d:65:a2:0e:9f:9f:5d:ee
(R)eject, accept (t)emporarily or accept (p)ermanently? t
Authentication realm: <https://localhost:443> Subversion Repository
Password for 'root':  # there is no user root, so just hit enter here
Authentication realm: <https://svn1.digitas.com:443> Subversion Repository
Username: user1
Password for 'user1':
A  test_project/test_file.txt
Checked out revision 1.

Get What You Want

Custom-compiling Apache and Subversion can certainly be involved, but it's the best way to configure your repository just the way you want it. Hopefully this article will make it easier for you to get what you want out of Apache and Subversion.

Manni Wood leads teams at a Boston advertising company in building Java-based, database-backed web sites for clients like General Motors and FedEx.

Return to the Apache DevCenter.

What defaults did you choose, and how did you do it?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 8 of 8.

Works with FC5
2006-09-13 09:11:49 k1mgy [Reply | View]

I followed this process for svn 1.1.4 and httpd 2.2.3 on a fedora core 5 box acting as a local server. I had been using svn on another junk server but needed to migrate to the new box with raid, etc.

I skipped the ssl parts. The server won't be accessed from outside. In fact with the script modifications (for apache startup) apache wouldn't start properly, telling me that startssl was no longer supported and I should, instead, make changes in httpd.conf.

I also had to manually delete the /bin/svn* stuff to make certain the builtin stuff did not conflict.

It may be worth noting that despite issuing the --without-berkeley-db configure parameter for apache, configure still warned that it couldn't find a berkeley install and that it would create it when make is invoked. This may be an issue with apache, and not the author's suggested ./configure parameters.

This article should be used as a template for any "how to". It provided not only the commands to invoke, but more important - it explains why each one is needed and what they do. Most of us are probably capable of a good RTFM to gain the needed understanding, but some, like me, are suffering time overload and just want to get some basic results to build on. This article serves both camps nicely.

Well done!

connection
2005-11-17 14:47:18 mu-acm [Reply | View]

We are considering running multiple instances configured for different connection types to our repository. Is this possible? Is there a reason not to do this?

We plan on using the repository as a versioning teaching facility for our student members as well as a version control system for their projects.

Where can I find more on this subject?

Thank you,

MU-ACM

NFS
2005-11-17 14:32:34 mu-acm [Reply | View]

Seems solid. What was the point of using FSFS instead of Berkdb? Why was using NFS one of your objectives?

Thanks,

MU-ACM

thank you!
2005-09-09 13:26:13 gregg_tavares [Reply | View]

You RULE! I would never have figured out how to get it all working without this article. I also never understood until now why fedora/redhat always had stuff installed in someplace other than the default for most programs.

I did notice a typo I think

[root@localhost trunk]# /usr/local/apache2/bin/htpasswd -c -m -b /www/svn_repository/conf/htpasswd user1 password1 [root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m -b /www/svn_repository/conf/htpasswd user2 password2 [root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m -b /www/svn_repository/conf/htpasswd user3 password3

should be

[root@localhost trunk]# /usr/local/apache2/bin/htpasswd -c -m -b /usr/local/svn_repository/conf/htpasswd user1 password1 [root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m -b /usr/local/svn_repository/conf/htpasswd user2 password2 [root@localhost trunk]# /usr/local/apache2/bin/htpasswd -m -b /usr/local/svn_repository/conf/htpasswd user3 password3

Good Catch!
2005-09-09 16:10:21 manni_lee_wood [Reply | View]

Good catch!

That is indeed a typo: the system where I did my testing had /usr/local/svn_repository and /www/svn_repository symlinked, and I failed to catch that one.

-Manni

Nice work
2005-07-30 19:25:34 k1mgy [Reply | View]

After hassling with Apache, Subversion and Tortoise SVN for a few days I stumbled upon this well-done piece that led me through the process nicely.

Thanks for sharing your efforts.

Minor tip for systems without a gzip-aware tar
2005-07-17 23:39:13 aristotle [Reply | View]

Instead of gunzipping the file on disk, decompress it to stdout and pipe the result into tar. That means instead of tar xvzf foo.tar.gz you say gzip -cd foo.tar.gz | tar xvf -. This can usually be abbreviated by using the zcat synonym for gzip -cd where it is present (most systems), yielding zcat foo.tar.gz | tar xvf -.

Doing it this way avoids unnecessary roundtrips to the disk, and also having to recompress the whole shebang, which means it’s much faster.

OS X changes
2005-07-10 20:01:48 jrh05 [Reply | View]

I made three minor changes to run under 10.4.

1. Change the Apache runconfig to this:

ac_cv_func_poll=no ./configure \ --enable-mods-shared="most ssl dav" \ --disable-status --disable-userdir

2. Add these lines to httpd.conf

AcceptMutex flock
LockFile /usr/local/apache2/logs/httpd.lock

3. Modify the subversion runconfig to this:

#!/bin/sh
# runconfigure.sh -- wrapper script for ./configure
GXX=yes ./configure \
--with-apr=/usr/local/apache2 \
--with-apr-util=/usr/local/apache2 \
--without-berkeley-db \
--without-zlib \
--without-jdk \
--without-jikes \
--without-swig \
--without-junit

Compiling Subversion

Creating the Repository

Integrating Subversion with Apache

Ensuring Apache Starts When the Server Does

Testing the Connection

Get What You Want

Tagged Articles

subversion

apache

tutorial

unix

linux

Sponsored Resources

Compiling Subversion

Creating the Repository

Integrating Subversion with Apache

Ensuring Apache Starts When the Server Does

Testing the Connection

Get What You Want

Recommended for You

Tagged Articles

subversion

apache

tutorial

unix

linux

Sponsored Resources