Yesterday night, while reading Planet Debian I found a post from John Goerzen about tools to replace Trac, including the option to use Git as the project VCS.

In the post he talks about different options, mainly projects that I would categorize as issue tracking systems (mantis, roundup, etc.), but it also talks about Redmine, a project management system implemented using the Ruby on Rails framework that is similar to Trac.

As it looked interesting I downloaded, installed and executed an instance in about 15 minutes (I love the systems that support sqlite3 for this quick tests, not having to touch real database servers speeds up simple tests a lot).

I played a little bit with the system and I believe that I will spend some more time testing it at work next week, as it looks quite promising; the standard version has almost all the features I'm interested in without the need to install additional plugins and it can do most of the things I was missing from Trac to do lightweight project management.

I evaluated ]project-open[ to use it together with Trac for our internal project management tasks, mainly because we miss important features from Trac, like having clean systems to view the tasks of a user in all projects or a clean way to do the project planning using tickets and gantt charts. Of course there are ways to do it, but the plugins I've tried are not as good and simple as I would like.

The problem with the use of ]project-open[ is that I don't really like it for us, as it has tons of features that I feel we don't need nor will use and, on a first try, the system seemed difficult to deploy and maintain, probably because my lack of knowledge about OpenACS and TCL.

In fact we still don't have ]po[ running at work because I was unable to to integrate the authentication system with our LDAP server on my first tries and have had no time to investigate further since then.

The good thing about trying Redmine is that if we don't end up using it at least I can take the most of this opportunity by looking at Ruby on Rails and the Ruby Programming Language, at least from the administration side, as I have never looked at it seriously.

On a couple of Debian Etch systems we have a plone-site that is published using a backport of the nginx web server.

The Zope instance is running on the standard port and serves the Plone contents under the /plone path.

Initially we were publishing the site to the external world using an https site served by nginx using the following entry on the configuration:

  location /plone/ {
    proxy_pass http://plone:9673;
    include    /etc/nginx/proxy.conf;
  }

The proxy.conf contents are quite standard:

  # proxy.conf
  proxy_redirect                  off;
  proxy_set_header                Host $host;
  proxy_set_header                X-Real-IP $remote_addr;
  proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
  client_max_body_size            0;
  client_body_buffer_size         128k;
  proxy_connect_timeout           90;
  proxy_send_timeout              90;
  proxy_read_timeout              90;
  proxy_buffer_size               4k;
  proxy_buffers                   4 32k;
  proxy_busy_buffers_size         64k;
  proxy_temp_file_write_size      64k;

With this settings we see the /plone contents using the same path that is used by the Zope instance, but after testing we have decided to change the /plone path and server the contents under the /web path.

The Wrong Solution

The fist option I though about was quite simple, rename the Zope's plone object to web.

Seems reasonable and simple for someone without Zope experience (I don't administer the internals of the Zope/Plone site), but now I know that it is a very big mistake, because renaming objects in Zope in not cheap, as it implies that the server has to modify all the contents of the renamed object and the operation can take a very long time.

With my ignorance I tried to rename the plone object using the Zope administrative interface and after a minute or so I cancelled the page loading that was running on my browser, thinking that I had cancelled the rename operation.

To make a long story short I'll tell you that the operation was still running and after several hours the folder was renamed (in fact I noticed when the good solution broke, as I had already solved the problem using the next method), but something went wrong and part of the site functionality was broken... the final solution to the debacle has been to recover a backup of the Zope instance older than the rename operation and continue from that copy.

The Right Solution (TM)

It seems that Zope has a couple of systems to do Virtual Hosting and the best option is the use of the product called Virtual Host Monster, a weird and confusing system (IMHO, of course), that does the job once the right configuration settings are in place.

The best solution to our problem was to modify the requests done by the reverse proxy without touching anything on the Plone site (the original one already had a Virtual Host Monster object installed and that was the only thing that we needed to add).

The nginx configuration for the new /web path is the following:

  location /web/ {
    proxy_pass http://plone:9673/plone/VirtualHostRoot/_vh_web/;
    include    /etc/nginx/proxy.conf;
  }

With this change, when the user asks for anything under the /web/ path the Zope server gets the contents traversing the /plone object and adding to it the elements that appear after the VirtualHostRoot component, ignoring components that start with the _vh_ prefix (the protocol and host name of the requests are not modified, as we did not touched that).

Once the object is found, the server rewrites the URLs included on the HTML files using the path components that appear after the VirtualHostRoot one, including the suffix of the components that start with the prefix _vh_.

For example, when the Zope server receives a request for an URL like:

  http://plone:9673/plone/VirtualHostRoot/_vh_web/home

it publishes the content found on:

  http://plone:9673/plone/home

but the HTML files returned assume that their base URL is:

  http://plone:9673/web/home

Anyway now I'm starting to believe that I should write more, at least about technical matters; I've been doing a lot of system administration tasks lately and probably it is a good idea to keep a log of the things I've tried and learnt on this Blog, as my notes can be useful to others or at least for myself.

I'm going to bed now, but lets start by enumerating some of the things I must Blog about:

• Virtualization using the Linux-VServer technology.

• Postfix configurations for the virtual hosts.

• Trac installations.

• Monit for local monitorization.

• HTTP servers and reverse proxies: Pound, Lighttpd, Nginx, Apache2.

• ... probably a lot of other things I don't remember now ...

The things I would like to look into, if I find the time:

• Other virtualization technologies like OpenVZ and Xen.

• Distributed Version Control Systems like Bazaar, Darcs, GIT or Mercurial.

• Firewalling and VPN software like Shorewall and OpenVPN.

• ... and again, another big list of things I don't remember now ...

And the Operating System I'm using to test all those programs:

• Debian

I've changed my address at the page templates by a tr command:

`echo -n abweqsq@@@uqfqvmb.vmb | tr -s @a-z@ @s-za-r@`

I don't know if it will be useful, but at least it looks a lot more freaky ;).

This post is written using Markdown to give it a try, but I wrote a simple plugin to add (partial) support for rst to be able to keep all my old entries without additional editing. I've sent the file to joeyh and I hope it gets into the upstream code (improved, if possible), as that will remove the need to keep my local changes in sync with the debian package.

I have not enabled the ikiwiki.cgi because the machine I'm running it is quite slow and anyway I only need it for comments, and I usually don't have many of them. Instead of enabling comments I've added a footer asking people to send comments to echo -n klgoaca@@@eapafwl.fwl | tr -s @a-z@ @i-za-h@ instead.

To avoid flooding planet I've used the ikiwiki flood prevention mechanism, previous posts can be reached through the categories and/or using the full Blog index.

Update

I've been told that there is a Perl library to parse rst.

I knew someone was working on it, but have not seen code until now; the package is called Text-Restructured and it is available from the URL http://search.cpan.org/dist/Text-Restructured/.

Probably my hack could be replaced by code that uses this module instead of calling python to parse the files... any volunteers?