Getting Hudson going on a Windows server

After getting all giddy about the ease of running Hudson (java -jar Hudson.war), I ran into rough weather pretty quickly. The main problems:

1. Running under Tomcat
2. Accessing our CVS server
   

As the saga unfolded the two issues got inexorably intertwined. After the Winstone experiment worked swimmingly, I cranked up Tomcat and dropped the Hudson WAR into the Tomcat webapps directory and it dutifully deployed up the application. I then configured Tomcat to run as a service.

Here was the first sign of trouble. When I ran a project build from Hudson, it reported a problem accessing CVS. It gave the vanilla CVS response to login first. Login as whom? The trouble was that the Tomcat service was running as the Windows system account. However, the system account is not authorized on the CVS server. Hmm...

Methinks I'll run Tomcat under the credentials of the account that does have access to CVS. I restart the service after this change and try to start another build.....however....I can't access Hudson. The Tomcat admin console reported that Hudson was running. Yet, when I accessed its URL, I didn't get a response. Uh oh!

To recap,

1. If I ran Tomcat under the Windows system account, I cannot access CVS
2. If I ran Tomcat with an account that could access CVS, Hudson's pages weren't being delivered....and let me throw in to the mix
3. To make matters a little more intractable, CVS passwords when using CVSNT (the common CVS client on Windows servers) is stored in the registry and not in a .cvspass file.
   

Given all these facts, we decide to hack the registry by copying the CVS-authorized user's password into the profile of the system account. We had to go to some Microsoft web site to find out the arcane SID for the System account. Once we located the account, we created a cvspass entry for it and copied the password from the authorized user's account. Then, we reverted the Tomcat service to use the system account account and triggered a project build. No dice :-(

It became clear that the solution had to be found while running Tomcat as the CVS-authorized user. However, why wouldn't Tomcat serve the Hudson pages?

It turned out the reason was that Tomcat had been installed by the administrator to a location that the CVS-authorized user did not have write-access. However Hudson required write-access to the logs directory! Once we gave this account the necessary permission, everything was hunky dory.

Phew! That was quite a workout. I am not sure how typical/atypical is our user and environment set up. For sure it highlighted several of the moving parts and many of the things that can go wrong.

Here's hoping you aren't here because you ran into similar problems!