Introduction

Mercurial

Mercurial is a great distributed version control system written in Python. It is a "fast, lightweight source control management system designed for efficient handling of very large distributed projects".¹ It is used by such projects as Aptitude, Mozilla, OpenJDK, OpenSolaris, Python, and Xen, among many others.² However, I have always found that hosting Mercurial repositories is painful. There are many options, including CGI/FastCGI and SSH based approaches. But none easily provided what I was looking for: anonymous cloning and use of the web interface, with HTTP authorization required for pushing.

hg serve

hg serve is a Mercurial command that starts a lightweight, built-in Web server. However, it provides no authentication.

Nginx

Nginx is a lightweight, fast web server and proxy. It powers WordPress.com, Hulu, Github, and Ohloh, among others³, and is the fifth most popular server on the web today.⁴ It was already in heavy use on my server, so I decided to find a way to solve my Mercurial hosting problems with it.

Configuring Nginx

The first step is to configure Nginx.

server {
    listen      80;
    server_name <your-server-name>;
    access_log  /path/to/access/log;
    error_log   /path/to/error/log;

    location / {
        limit_except GET {
            auth_basic           "Restricted";
            auth_basic_user_file /path/to/htpasswd/file;
            proxy_pass           http://localhost:8080;
        }
    proxy_pass http://localhost:8080;
    }
}

The first line simply starts a server directive, inside which configuration for that server is defined. The next lines are standard directives for any server block. The limit_except block says to do the following for all requests except GETs: set the authentication realm to "Restricted", (or whatever you want to call it), use the specified htpasswd file for authentication (created in the next section), and then proxy to port 8080 on localhost if authentication succeeds. Since clones and web interface views are GETs, this means you will not have to be authorized for them. The proxy_pass directive simply needs to point at whatever port you have hg serve running on.

Configuring htpasswd

htpasswd is a utility used to manage flat files that store usernames and passwords for basic HTTP authentication. It is most likely provided in whatever package in your distribution provides the Apache server. To use it, cd into the directory you specified for auth_basic_user_file directive, and run htpasswd -c [file-name] [username] and enter a password. This creates (-c) an htpasswd file with the specified file name, with a user identified by the provided password. If you need to add another user, simply cd back to that directory and run htpasswd [file-name] [new-username].

Configuring Mercurial

The final step is to configure Mercurial. cd into the root of where you want your repositories to be served from, and create the hgweb.config file as discussed here. Then, inside each repository, modify /.hg/hgrc to contain the following in the [web] section:

push_ssl = false
allow_push = *

This disables SSL, and turns off the Mercurial repository trying to authenticate, since Nginx is taking care of that.

Launch

Now, in the directory where your repositories are stored and your hgweb.config is, run hg serve --webdir-conf hgweb.config (the -d option, which daemonizes the process, is also useful). If all went well, you should be able to browse your repositories via the web interface and clone repositories with no authentication, but when it comes time to push you will need a username and password from the htpasswd file.

Caveats

There are drawbacks to this approach. First, authentication is done over HTTP, not HTTPS. For me, hosting personal projects, this isn't a big deal. Second, authentication is done site wide, so once someone has push privileges to one repository they have them to all. This is easily worked around by creating a location /[repo-name] block for each repository, and point auth_basic_user_file to a different htpasswd file for each repository.

Sources

1. http://www.selenic.com/mercurial/wiki/
2. http://mercurial.selenic.com/wiki/ProjectsUsingMercurial
3. http://wiki.nginx.org/Main
4. http://news.netcraft.com/archives/2009/07/28/july_2009_web_server_survey.html

I’ve typically been pretty conservative when choosing a web server. Typically, I’ll use Apache to run most sites, and possibly Lighttpd for static files. Experimenting never really has been something done with a web server once I’m past the initial setup.

I’m willing to change that, however, especially after seeing the Cherokee web server in action. At first glance it seems to just be another lightweight web server, and in the end, it is.

The Cherokee website has its own benchmarks against Apache, Lighttpd, and Nginx, with Cherokee coming out on top in terms of the most requests. They are fairly comprehensive, though if you’re not one to trust benchmarks these may not seem any different from those conducted by others.

The one sole feature that could really give Cherokee a solid place in the server market is its method of administration. Most free software server solutions typically offer plenty of organized configuration files to tune and edit at your leisure. If you really have the desire to do so, Cherokee won’t prevent you from directly editing its own configuration. However, there is something much better:

The entire server can be managed using cherokee-admin, the web interface you see above. In fact, it’s highly recommended to manage the server using this administration interface. Your first thoughts may include security issues of a web-managed server, but many of those are dissolved quickly: cherokee-admin must be run in a console, and then a one-time-use password is generated for the administration interface. When you are done, stop cherokee-admin, and everything is safely closed away once more.

The administration interface alone may be responsible for converting many websites to Cherokee. Any entry barrier that may have existed from editing config files might nearly disappear: right after installation, all you must do is fire up cherokee-admin and begin configuring your new web server.

There are a lot of other cool gems included as well. A panic script can be invoked should Cherokee crash, alerting the administrator immediately. It natively supports fcgi and FastCGI, and includes a default rule to help set up PHP in a few moments. Even things such as switching users, accomplished by compiling suexec in Apache, are only a text entry away in Cherokee.

Version 0.99.9 was recently released, so 1.0 can’t be too far around the corner. If you’re looking to find a server that doesn’t need to be manually configured, or just want something speedy, Cherokee is definitely the path to take.

I recently posted about using nohup to run a command, particularly on a remote machine, that keeps running even when you close the terminal or connection that started it.

Several people in the comments there also suggested GNU Screen for a similar purpose.

So, what is Screen? It describes itself as:

... a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

Basically, among other things, it can create multiple 'virtual terminals' that run inside a single physical terminal or connection, and offers you additional features, such as resuming sessions later and basic copy and paste.

What we're interested in in the context of my other post is running commands in the background on remote machines, so I can start a command running, disconnect from SSH, but the command will stay running.

Screen, unlike Nohup, will allow me to come back later and interact directly with the terminal that I started, not just dump the results of a command to a file.

On your remote machine, start the program:

$ screen

You'll get a brief copyright notice and such, just press Space as directed. You are now running Screen (although it won't look any different to a normal terminal session by default).

Now, feel free to go off and start that important task. Once it's up and running, press Ctrl+A, then Ctrl+D. Screen sends you back to your shell and you can now disconnect.

Later, when you want to come back, run:

$ screen -r

Your old session is restored! Anything you started should still be running.

Screen is a lot more powerful than just offering this feature, however, but we'll save the rest for another day.

Finally, when you are actually done with a Screen session for good, quit it by pressing Ctrl+A, then Ctrl+\ or you can simply type exit into the terminal as normal.

[image source]