Ok, I will be honest, I’m excited for achieving this thing. I’ll explain here all the process I did to get Trac 0.12.3 with AccountManagerPlugin 0.2.1 (yes, I know the current is 0.3.2 but it’s not on the python cheese shop) on a shared server via One-Click Install.

THESE INSTRUCTIONS REQUIRE ADVANCED KNOWLEDGE, YOU’RE ON YOUR OWN HERE. AT MARCH 31, 2012 THEY’RE STILL UNTESTED IN THE WAY THEY’RE WRITTEN HERE.

Requirements:

- Have a Working virtualenv (in my case an environment with Python 2.7)

Assumptions:

- You have a user with SSH access.
- You will not use a SVN repository at installation time.

1.- Create a new domain

I’m sure you know to do this. Just go to “Manage Domains” and create one.

2.- Activate HtAccess on the domain/folder

In my use case the domain was the root of the trac project but you can use a folder inside the domain to handle your project, just create the directory. Go to “Goodies -> HtAccess/WebDAV“, pick your domain and click “Set up a new directory“.

If you use the domain as the trac directory you don’t have to put anything in “Directory name” field. If you use a directory, put it there.

After that you need to activate “Password protected directory” and put your users in the “User accounts for this area” in the format that comes in the example. After that click on “Configure this directory”

3.- One Click Install Trac 0.11.4

For starters: there is a known bug in the DreamHost server that will make the Python interpreter to execute the system Trac, which is 0.11.1.

Go to “Goodies -> One Click Installers“. Select Trac and install it on your domain, do not select any repository. After you get the mails everything will be installed.

4.- Trying our new trac and messing around with HtAccess

If you try to access your new Trac you will see that asks for a username and password even before showing up: ouch!, that’s not what we want. We want a publicly visible Trac.

Now you need to access your account via SSH and enter your trac directory or domain. You will realize that there are two important files: .htaccess and .htpasswd.

We only need the .htpasswd file for trac, so we will tell the DreamHost server that we don’t want the .htaccess messing with us. Open the .htaccess file and you will see a section like this:

1
2
3
4
5
6

### Generated by Dreamhost. DO NOT modify!!! ###
AuthType Basic
AuthUserFile /home/username/yourtracdomain/.htpasswd
AuthName "members"
require valid-user
################################################

Comment it entirely (don’t delete it, you may need to use it later). Now go and rename the .htpasswd file to trac.htpasswd.

I’m not sure about this part, at this step I was struggling with AccountManager and already modified the config thousands of times

Open your trac.ini file (located at yourpirjectdir/conf/trac.ini) and modify the route to the .htpasswd file to your new trac.htpasswd.

Now you can access to your trac publicly. We just need to create an admin user. You can do it with:

trac-admin yourtracdir/ permission add USERNAME_IN_HTPASSWD TRAC_ADMIN

Now we have our administrator. I’m sure you want to enjoy your newly created Trac instance, but there is still work to do.

From here on, the method I followed is not the best, in fact it’s a WTF! hack, but I didn’t find a better way to do it.

5.- Installing Trac (what?) and AccountManagerPlugin

Ok, we need to upgrade our Trac installation, and for that we will need to install it again, but this time, on the virtualenv. As you might already noticed, our One-Click Trac is installed in a directory with the same name as the domain but with underscores, that’s where DreamHost messed everything. Do not delete that directory unless you REALLY know what you’re doing and how to fix the mess it will cause.

So, this is the easy part:

pip install -U trac tracaccountmanager

It will install (as of March 31, 2012) Trac 0.12.3 and AccountManager 0.2.1-dev.

You may notice two things, the first is that the python interpreter keeps using Trac 0.11.1 and second, it does not detect the AccountManagerPlugin.

6.- Warrior’s March.

We need to “redirect” all the petitions that FastCGI makes to the new Trac in our virtualenv. This will include modifying several files.

If you don’t know it I’ll tell you that when your server receives a petition to the trac, it loads the file “index.fcgi” located at your trac directory, so we will start there.

You will need to add the virtualenv directory to the PATH, so edit the “index.fcgi” file and add (right after TRAC_ENV):

export PYTHONPATH=”/home/YOUR_USER/YOUR_VIRTUALENV/lib/python2.7/site-packages”

After this, you can see in the file that the petition is redirected to the One-Click Trac, at the cgi-bin directory. Let’s go there, we will find two files: trac.fcgi and trac.cgi that contains almost the same code.

This is actually the real trigger of the trac installation, we need to tell him that when executed, it must import the trac module from our virtualenv. For that we will need to specify what interpreter to use and where to look for that module.

In both files you need to put at the first line this:

#!/home/YOUR_USER/YOUR_VIRTUALENV/bin/python

and just after the comment we must specify him a new route for the site-packages. If we don’t do it, it will load the system-wide Trac module.

1
2

import sys
sys.path.insert(0, '/home/YOUR_USER/YOUR_VIRTUALENV/lib/python2.7/site-packages/Trac-0.12.3-py2.7.egg')

This should be enough for the virtualenv trac to load, but we’re not finished. We didn’t update the Trac environment!!

First we need to check if your virtualenv works ok, so enter your home directory and check what trac-admin binary will be executed:

which trac-admin

If your virtualenv trac-admin will be executed there’s no problem, if not, you will have to specify the complete route to the executable. Now execute this:

trac-admin yourtracdir/ upgrade

It should upgrade your trac DB and stuff to the 0.12.3 version and also suggest you to update the wiki. Do it, you never know.

OK, we’re ready to go, aren’t we?

7.- Testing our Trac installation

We can now load our Trac 0.12.3 installation. Everything should be ok, but wait, what’s that?

<acct_mgr.web_ui.MessageWrapper? object at 0xa2a102c>

I don’t want that on my Trac!! I can’t access the admin! I don’t see anything working ok!

I haven’t investigated about this, but it’s a known bug in the AccountManager plugin that can be solved editing your trac.ini and adding this line:

acct_mgr.web_ui.emailverificationmodule = disabled

That’s it. Now you have a working Trac 0.12.3 in a shared DreamHost server.
Please make me know if it worked for you or if you had any troubles. I’ll do what I can to help you.

UPDATE: I’ve rewrited the post since the instructions are much easier than I did put here (and more secure)

You will probably say: “Hey!, what’s in your mind to need django 1.3, it has been released just a week ago!”. The answer is: long-term development. Currently I’m working on e-cidadania, an e-democracy tool designed for participative processes. The development will take some time, and we’ve just started. It’s better to update everything now than later, but to the point, installing django 1.3 in dreamhost.

NOTE: I assume you know how to install a django project in DH. If not, please see this wiki

Let’s start.

STEP 1: CREATE A VIRTUALENV

You can create a virtualenv with the system-wide python installation (currently 2.5.2) or install your own python interpreter if you need it. We will use the system-wide python for convenience, since it’s still supported by django 1.3.

This part is extracted from here

NOTE: These commands must be typed at your home directory

$ wget http://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.5.2.tar.gz
$ tar xzf virtualenv-1.5.2.tar.gz
$ python virtualenv-1.5.2/virtualenv.py $HOME/env

This will create a directory called “env” with all the stuff you need to work. Let’s do this virtual environment our default.

STEP 2: STABLISH THE VIRTUALENV PYTHON AS DEFAULT

The following instructions about stablishing the virtual python as default only work at shell level. For passenger the system-wide python is the default.

On ~/.bash_profile write:

export PATH=$PATH:$HOME/env/bin

This will stablish the directory ~/env/bin (where our virtual python is) before the system-wide python. To work right now without logging in again, we can do:

$ source .bash_profile

That will make the executables in ~/env/bin available for using right now, and between them, it’s easy_install, properly configured to install any python module locally without problem.

STEP 3: INSTALL DJANGO 1.3 AND ANY OTHER PACKAGES

Let’s install django 1.3 and some common python packages needed in almost every project:

$ easy_install -U django

For the moment we will install just django, because the rest of python packages are provided by the DH server. If you need non standard modules (p.e. python-dateutil) or other version of an already provided package, you must install them after django.

If you try to execute some django project right now you’ll see that the system-wide installation of django is the preferred. Let’s change that.

STEP 4: CONFIGURING PASSENGER_WSGI.PY

In our passenger_wsgi.py we must modify the PYTHONPATH, let’s do it:

import sys, os
 
# Python has no prepend function, so we must do an insert. We insert the key directories
# BEFORE ANYTHING, so the python installation sees them before the system-wide libraries.
 
sys.path.insert(0,'/home/USERNAME/env/bin')
sys.path.insert(0,'/home/USERNAME/env/lib/python2.5/site-packages/Django-1.3-py2.5.egg')
sys.path.insert(0,'/home/USERNAME/env/lib/python2.5/site-packages')
 
os.environ['DJANGO_SETTINGS_MODULE'] = "YOURPROJECT.settings"
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Remember that if any of your modules fails, python will not fall back to the system-wide installation. Once a module is loaded, python does not seek another. Also, if you installed another package apart from django, you must do an insert including it.

That’s it! Now when you receive a visitor, Passenger will load you desired django version and packages.