Work? What work?

January 27, 2009 by · 1 Comment
Filed under: Configuration Management, Linux 

So, just a brief update. I’ve recently (a few months back *cough*) taken over our Linux “education” group at work, and it’s interesting. The sad part is, we mostly only see people who already knows what Linux is as we’re working internally in a world where most people are rather Computer savvy as it is. It’s given me a few new viewing angles though, and I’ll get back to that at a later point.

Currently working on some Trac guidelines for our Change Management process as well. Working from home today to actually get something done with it, as most of the days I wind up getting too many disturbing calls, talks and discussions to be very efficient. Our first two tries at making a decent workflow winded up a bit messy, and I think we really must get this down properly this time.

There are some other things I react on, and want to fix, for example, as it looks now, every single project sets up their own bugtracking/ticketsystem, and every project uses a different system (trac, mantis, clearcase, dimensions, etc). Preferably, this should be centralized in some fashion, and if possible I’d love to get a bit more homogenized environment. As it is, I try to tell people “look, here’s a system for handling your day to day tasks, use it!”. First time, the workflow got overly complex, second shot was also overly complex, and people where put off by all the choices and steps to take. This problem mainly stems from project/change management criterion.

My latest and greatest (yeah yeah) workflow should alleviate some of these problems by making some of the choices less visible to normal users. Ie, we have one task management system and a problem and change management system baked into one, but normal users (programmers) only use the task management system, while the project manager, tech project manager and CM also have the ability to handle problems and changes in separate workflows.

We’re also adding the ability to have supertickets, where a single problem report can contain several tasks. This is a pseudo development so far, as we’re not actually adding the whole deal right now, we’re just adding the idea of it, not bounds checking or views/reports of it. Basically, every ticket can have a superticket (we add a numeric field to the ticket), which can point to another ticket, which is the “parent” ticket. This makes it possible to handle a large and complex bug in several smaller tickets. Anyways, the idea is there, but it’s not fully implemented. If our management likes it, and the others like it, we could implement it for future usage. I’m worried it’s too complex however. At the same time, one complex system might be better than 6 alltogether different systems as it allows for longer time to learn? Kind of like… well, unix for example. Once you find ls, its a darn good bit faster than having to click your way through a whole heap of paths to find the specified file list.

At the same time, both me and PM are a bit tired of Trac’s shortcomings, maybe change to Mantis for example? My general thought to this however is, we need to stick it out i’m afraid… one more system will just make the normal user less interested in the new tool and hence taking even longer to learn. As it is, people use it at a bare minimum cause they dont know it, give them time to learn it properly, and they might come to like it. Comments on this line of thinking?

For now, tata. Back to writing.

Trac on separate server from subversion

September 11, 2008 by · Leave a Comment
Filed under: Configuration Management, Windows 

It is possible to have Trac on a different server than the subversion server, albeit a bit convoluted. This is slightly stolen note from

Set up the master subversion server as you would normally. We will get back to this one.

On the trac server, install subversion etc as well. This server will rely on svnsync to become a secondary/mirror subversion server. It must not be used for checking in or working against, it is purely a repository for reading.

Set up trac and all other tools required on the mirror server.

Now, you need to set up user accounts on the mirror server. To start with, create the mirror subversion repository, it will be empty to begin with:

svnadmin create MIRROR_REPOS_PATH

After that, create authz authentication files for the repositories to stop anyone from writing/working against the mirror repository, such as the following:

* = r
svnsync = rw

You could extend this by writing hook scripts blocking anything but the svnsync user.

If the master subversion repository is live while adding the trac database, all of the following must be done during server maintenance window (ie, close it down from any kind of access, except the mirror machine).

Once all that is done, its time to initialize the the mirror server with the master subversion repository (ie, move over the data).

svnsync initialize URL_TO_MIRROR_REPO URL_TO_MASTER_REPO –username=svnsync –password=svnsyncpassword

And once that has successfully been done, do as follows:

svnsync synchronize URL_TO_MIRROR_REPO –username=svnsync –password=svnsyncpassword

The final step is to either add a scheduler (cron.d) script, or a post-commit hook script running the following:

# Example for synchronizing one repository from the post-commit hook
$SVNSYNC synchronize URL_TO_MIRROR_REPO –username=svnsync –password=svnsyncpassword &
exit 0

Preferably run it from post-commit as it gives better refresh rate.

You can now run the trac against the mirrored subversion server.

Trac on windows

September 10, 2008 by · 1 Comment
Filed under: Configuration Management, Windows 

Trac is a rightfull bitch to install on win32 as it requires very specific version matching of packages. This is a long winded installation note with the more or less latest versions available as of this writing.

I’m hoping to get working on TortoiseSVN and Trac integration once this is done (ie, make tortoise automatically set variables etc sent in change notes, which can hence update the issue tracking systems in trac and so forth. The way of working is really really sweet imho, and I think it could be a really nice way of working. I’m just sad that I have to set all this serverstuff up on windows though.

Let’s begin with a list of all the installation files used:




These packages should be fairly simple to get started with. Install them straight on, in the order mentioned.

Install the above packages in that order. Some errors i ran into:

Unsupported version control system “svn”

I accidentally used svn-python-1.5.0.win32-py2.5.exe. It also complained about not finding SSLEAY32.DLL which threw me off course, looking for the wrong solution.
Secondary applications
On top of this, the following applications where installed (not yet configured/set up).

The Apache2.2.9 must be installed before files are, and the .so files must be put in 2.2.9 as that package will not run on Apache2.2.8. Apache 2.2.8 with will die silently without hint as to why it died.
Once all of the above is installed, create a svn repository in c:\projects\svn\test (create directories, and then right click test and choose TortoiseSVN -> Create repository here.
Now create a trac database in c:\projects\trac\test\ by running
c:\python2.5\trac-admin.exe c:\projects\trac\test\ initenv

Answer the questions asked by trac-admin.exe. To test the trac at this point, run tracd.exe per ordinations from trac-admin.exe.
Contains required files to make dav_svn work in apache2.2, edited extract on how to install:
For an Apache server here’s the essentials:
1. Copy bin/ and bin/ to the Apache modules directory.
2. Add the Subversion/bin directory to the SYSTEM PATH.
3. Edit the Apache configuration file (httpd.conf) and make the following changes:
3a. Uncomment the following two lines:

#LoadModule dav_fs_module modules/
#LoadModule dav_module modules/
3b. Add the following two lines to the end of the LoadModule section:
LoadModule dav_svn_module modules/
LoadModule authz_svn_module modules/
3c. Add the following to end of the file.
<location /svn>
DAV svn
SVNPath c:\projects\svn\test
AuthType Basic
AuthName “My Subversion repository”
AuthUserFile “c:\projects\svn\test\conf\passwd” Require valid-user
Add users to passwd file above:
C:\wampbin\apache\apache2.2.9\bin\htpasswd.exe -b \projects\svn\test\conf\passwd myuser hejhej

Finally installing Trac in apache2.2

To run trac via apache, you need the above module for apache as well. Once this is done, add the following to modules section of apache:
LoadModule python_module modules/

To test the python installation add the following to the end of your httpd.conf:

<location /mpinfo>

SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler mod_python.testhandler

And if that works, test the following:

<Location /trac>

SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv “c:/projects/trac/test/”
PythonOption TracUriRoot /trac

Further reading—design-choices.aspx