Mercurial, Apache, and OpenSuse 11.1

Mercurial’s Web Interface

Funny how some things can turn out to be much easier than you fear. I’d been meaning to make some of my code accessible via a web interface. It turned out to be much easier than I expected.

Getting Apache Setup

I didn’t want to run Mercurial as .cgi script. I’d had some initial problems with mod_python and decided I wanted to try out the newer wsgi interface.

Installing mod_wsgi

mod_wsgi was not installed by default. I went to ([] to find an RPM. I got it and installed it:

www# wget
www# rpm -i apache2-mod_wsgi-2.5-1.1.i586.rpm

I then needed to activate the wsgi module in apache2:

www# a2enmod wsgi
www# /etc/init.d/apache restart

Configuring Apache

WSGIScriptAlias /hg /path-to-repository/scripts/hgwebdir.wsgi
    Order deny,allow
    Allow from all

The WSGIScriptAlias directive is similar to the Apache Alias directive in that it specifies either a directory as containg wsgi scripts or in this case that “/hg” should map to the script hgwebdir.wsgi.

Installing hgwebdir.wscgi

You’ll need to copy mercurial’s wsgi script to where you put it in the apache config

cp path-to-mercurial-source/mercurial-1.2.1/contrib/hgwebdir.wsgi /path-to-repository/scripts

You then modify scripts/hgwebdir.wsgi and setup the absolute path to your repository. Something like:

CONFIG = '/path-to-repository/hgweb.config'
application = hgwebdir(CONFIG)

It’s really the assignment to application that matters (as that’s what wsgi uses).

Setting up hgweb

style = gitweb
contact = Pete Ware
/ = /path-to-repository/**

The [web] section sets up defaults for all the repositories.
The [paths] directive combined with the “/**” means to find all mercurial repositories under that directory.

Setting up a project

You can clone any project you’d like to put it under the web interface. The web interface works on the underlying DB so it’s always up to date (wrt to the repository).

# cd /path-to-repository
# hg clone /orig-repository project

If you want people to be able to push to it, everything needs to be owned by the same as the web server. In the case of OpenSuse, that’s wwwrun:

# cd /path-to-repository/
# chown -R wwwrun  project

Controlling who can access the project

Within each project. the .hg/hgrc controls who can access it. For example, the following allows a user “testuser” to push. I allow push to not happen over ssl. Probably not the best idea but this isn’t critical software.

allow_push = testuser
push_ssl = false

The above uses apache’s authorization.


OpenSuse 11.1, kdm_greet, slow ssh login

I was suffering from slow ssh logins — it’d take 20 seconds to get a login prompt. I noticed this process, kdm_greet, running. Google found a posting message that said the problem is kdm_greet is having to examine a bunch of fonts:
kdm_greet takes a long time to run due to out-of-date font-cache
It didn’t seem reasonable but I went ahead and ran:

fc-cache -f

Login was so fast I thought at first nothing happened.
Well, it started to get slow again. I monitored what was happening and it looks like sshd was taking a long time (30 seconds). That made me think of reverse DNS lookups. I checked


and it had an out-of-date nameserver entry. Removed it and things are fast again.


Installing OpenSuse 11.0

A little late to the party (11.1 is going to be available in 5 days on Dec 18, 2008) but I finally upgraded my server, including going to OpenSuse 11.0. Btw, installing from a DVD is way better than poping CDs in and out. Some notes along the way:

  • I had to enable DHCP explicitly
  • After enabling DHCP, I had to do /etc/init.d/network restart
  • Ran updates
  • Installed printer. Via timecapsule, Network print direct
  • Installed apache2, mod_python, etc
  • Installed mercurial
  • Installed gcc/g++ (4.3)
  • qt4-devel, qt4-devel-doc, PyQt qt
  • emacs, emacs-lisp, xemacs, xemacs-packages
  • texlive, texlive-latex
  • boost
  • doxygen
  • make
  • scons