Sunday, July 27, 2008

apache didn't start after installing subversion

I installed apache long before. Recently I installed subversion and thought everything is OK. But actually it wasn't. When I tried to start apache, i got this error:

$ /usr/local/apache2/bin/apachectl start
[Mon Jul 28 11:13:10 2008] [warn] module ferite_module is already loaded, skipping
[Mon Jul 28 11:13:11 2008] [warn] module php5_module is already loaded, skipping
Syntax error on line 1048 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_dav_svn.so into server: /usr/local/apache2/modules/mod_dav_svn.so: undefined symbol: dav_xml_get_cdata

This time, it took little time to solve this problem. I reinstalled apache using these steps:

$ ./configure --prefix=/usr/local/apache2 --enable-dav --enable-so
$ make
$ sudo make install

And everything is ok now :)

Monday, July 21, 2008

Using svn and got "Unrecognized URL scheme."

This morning, I built subversion-1.5.0 from source using the ./configure, make and make install. Then I tried to check out a repository and got this error:
$ svn checkout http://svn.assembla.com/svn/blog1/ --username azim.babu
svn: Unrecognized URL scheme for 'http://svn.assembla.com/svn/blog1'

It seemed to be a curious problem to analyze. So I did some googling and found these from http://subversion.tigris.org/faq.html :

Subversion uses a plugin system to allow access to repositories. Currently there are three of these plugins: ra_local allows access to a local repository, ra_dav which allows access to a repository via WebDAV, and ra_svn allows local or remote access via the svnserve server. When you attempt to perform an operation in Subversion, the program tries to dynamically load a plugin based on the URL scheme. A `file://' URL will try to load ra_local, and an `http://' URL will try to load ra_dav.

The error you are seeing means that the dynamic linker/loader can't find the plugins to load. This normally happens when you build Subversion with shared libraries, then attempt to run it without first running 'make install'. Another possible cause is that you ran make install, but the libraries were installed in a location that the dynamic linker/loader doesn't recognize. Under Linux, you can allow the linker/loader to find the libraries by adding the library directory to /etc/ld.so.conf and running ldconfig. If you don't wish to do this, or you don't have root access, you can also specify the library directory in the LD_LIBRARY_PATH environment variable.

So what I got is that I was not able to setup the SVN on my ubuntu box properly. Here even after compiling the source I was not able to enable the support of ra_dav module for http and https protocol. So I did a little googling again and found that I was missing neon. So I download neon from http://www.webdav.org/neon/neon-0.28.1.tar.gz , extract the tarball and install neon using ./configure, make and make install.
Then I recompile subversion as follows:
$ ./configure --with-ssl --with-apr=/usr/local/apache2/bin/apr-config --with-apr-util=/usr/local/apache2/bin/apu-config --with-neon=/usr/local
$ make
$ sudo make install

A little explanation of the above options are:

--with-apr : prefix for installed APR, path to APR build tree, or the full path to apr-config

--with-apr-util : prefix for installed APU, path to APU build tree, or the full path to apu-config

--with-neon : Determine neon library configuration based on 'PREFIX/bin/neon-config'. Default is to search for in a subdirectory of the top source directory.

As I installaed neon without any option during configure, it should be /usr/local for my case :P

Although all these steps may seem to be very much intuitive for many, I think for newbies, this type of blog post may provide some sort of quick help. :)