- Running under Tomcat
- Accessing our CVS server
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!
- If I ran Tomcat under the Windows system account, I cannot access CVS
- 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
- 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.
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!