views:

806

answers:

2

For some months we've run Hudson on a Windows XP "server" under a user account. This means someone manually logs in and starts Hudson via a .bat file (that sets up a few environment variables, then runs java -jar hudson.war)

However a few recent power cuts have resulted in the requirement to have Hudson start automatically at the time the server boots up. So I've turned to looking at Hudson running as a Windows Service. This would allow Hudson to start automatically with Windows, and would not require a specific user account.

I've managed to install it as a service, and I've changed hudson.xml so that the batch file is run rather than java directly. I do this because we build with git on Cygwin and SHELLOPTS=igncr must be set before bash starts java/Hudson.

The service seems to start properly, and the web interface is present and functional. However, it appears that the user that Hudson is now running under is unable to write/modify existing jobs in C:\hudson:

FATAL: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
hudson.plugins.git.GitException: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
    at hudson.plugins.git.GitAPI.checkout(GitAPI.java:382)
    at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:529)
    at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:521)
    at hudson.FilePath.act(FilePath.java:676)
    at hudson.FilePath.act(FilePath.java:660)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:521)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:833)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
    at hudson.model.Run.run(Run.java:948)
    at hudson.model.Build.run(Build.java:112)
    at hudson.model.ResourceController.execute(ResourceController.java:93)
    at hudson.model.Executor.run(Executor.java:118)
Caused by: hudson.plugins.git.GitException: Error performing c:\cygwin\bin\git.exe checkout -f 4a121704f178123c36f6ab4e861b3c771953b187
    at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:302)
    at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:276)
    at hudson.plugins.git.GitAPI.checkout(GitAPI.java:380)
    ... 12 more
Caused by: hudson.plugins.git.GitException: Command returned status code 1: error: git checkout-index: unable to create file .gitignore (Permission denied)
error: git checkout-index: unable to create file .gitmodules (Permission denied)
error: git checkout-index: unable to create file Makefile (Permission denied)

I'm not really a Windows sort of person, but I thought perhaps if I added "Full Access" Security permissions to C:\hudson for the user "LOCAL_SERVICE" then that might fix it. Alas, it did not. I also tried full permissions for the user "Everyone" but that also did not solve the problem.

What am I missing here? Is there any way to allow a process running as a Service unfettered access to a subdirectory on a local disk?

A: 

Instead of running it as a service, maybe you should use Task Scheduler to set the process to run at logon, then have the user account auto-login. This is probably going to be much less hassle than dealing with service permissions, especially if you have to communicate with other machines.

Paul Betts
That sounds like a reasonable idea - I'll look into it.The problem will be that our corporate IT policy does not permit 'utility' accounts, and it would be a brave person who would let their personal account be used for this purpose. I hate IT politics.I think the Service idea would work if somehow I could make c:\Hudson writable by the service.
meowsqueak
Ok, I tried this out. It seems to work well except there's one problem - if I log in with the same account that the Scheduler is using to run Hudson, then log out, it seems to kill the scheduled task too. This is rather unfortunate, as I do have a need to log in occasionally. It seems if I log in at least once, then I'm back where I started because I have to run Hudson manually from then on.I suppose it will still work in the event of a power cut and reboot.
meowsqueak
I'd recommend talking to someone who actually administers the IT policy, they'd be mad not to concede the security benefits of running a service in a dedicated account. Also, the account doesn't have to be company-wide, a local machine account will do the job just as well.
Kevin Wright
+2  A: 

How about you change the user that the service is running as. So create a new "technical" user account whose password nobody knows (except an envelope in your safe) and make this user the owner of all your hudson job folders. This also has the advantage that you can take permissions away from hudson. This way a Hudson job can not act as an admin on your windows machine.

The advantage of a service compared to a scheduled job is, that it restarts when it crashes.

Peter Schuetze