• Choose a category
• All
• Classic-Fiction

By Root 910 0

but brace yourself for instant failure. There’s a high probability that trying to visit this URL will fail, and there are many possible reasons for this. In fact, you’re likely to stumble over almost every one of the possible errors below, so please read carefully. The following are all of the problems I ran into on a system running Fedora 7, with a fresh installation of Apache, and a user account that I created specifically to perform this exercise.

Your web server may have per-user directories disabled. If you’re using Apache, search your config file for a UserDir directive. If there’s none present, per-user directories will be disabled. If one exists, but its value is disabled, then per-user directories will be disabled. Otherwise, the string after UserDir gives the name of the subdirectory that Apache will look in under your home directory, for example public_html.

Your file access permissions may be too restrictive. The web server must be able to traverse your home directory and directories under your public_html directory, and read files under the latter too. Here’s a quick recipe to help you to make your permissions more appropriate.

chmod 755 ~

find ~/public_html -type d -print0 | xargs -0r chmod 755

find ~/public_html -type f -print0 | xargs -0r chmod 644

The other possibility with permissions is that you might get a completely empty window when you try to load the script. In this case, it’s likely that your access permissions are too permissive. Apache’s suexec subsystem won’t execute a script that’s group- or world-writable, for example.

Your web server may be configured to disallow execution of CGI programs in your per-user web directory. Here’s Apache’s default per-user configuration from my Fedora system.

AllowOverride FileInfo AuthConfig Limit

Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

Order allow,deny

Allow from all

Order deny,allow Deny from all

If you find a similar-looking Directory group in your Apache configuration, the directive to look at inside it is Options. Add ExecCGI to the end of this list if it’s missing, and restart the web server.

If you find that Apache serves you the text of the CGI script instead of executing it, you may need to either uncomment (if already present) or add a directive like this.

AddHandler cgi-script .cgi

The next possibility is that you might be served with a colorful Python backtrace claiming that it can’t import a mercurial-related module. This is actually progress! The server is now capable of executing your CGI script. This error is only likely to occur if you’re running a private installation of Mercurial, instead of a systemwide version. Remember that the web server runs the CGI program without any of the environment variables that you take for granted in an interactive session. If this error happens to you, edit your copy of hgweb.cgi and follow the directions inside it to correctly set your PYTHONPATH environment variable.

Finally, you are certain to be served with another colorful Python backtrace: this one will complain that it can’t find /path/to/repository. Edit your hgweb.cgi script and replace the /path/to/repository string with the complete path to the repository you want to serve up.

At this point, when you try to reload the page, you should be presented with a nice HTML view of your repository’s history. Whew!

Configuring lighttpd

To be exhaustive in my experiments, I tried configuring the increasingly popular lighttpd web server to serve the same repository as I described with Apache above. I had already overcome all of the problems I outlined with Apache, many of which are not server-specific. As a result, I was fairly sure that my file and directory permissions were good, and that my hgweb.cgi script was properly edited.

Once I had Apache running, getting lighttpd to serve the repository was a snap (in other words, even if you’re trying to use lighttpd, you should read