01 December 2009

Hudson updates, Linux and the corporate proxy

My Hudson build server is running on Red Hat Linux. This became important when I figured out that I couldn't update Hudson automatically because of some sort of proxy problem.

I would select Manage Hudson > Manage Plugins and then select a plugin or two to update and click the "Install" button to do it. It would give me an error "NoRouteToHost" and show a Java stack trace.

First Try

I was running Hudson 1.309 and, though it might be a bug in that version (but don't quote me on that), entering the corporate proxy server's IP and port on the "advanced" tab of that "Manage Plugins" page didn't fix the problem. (There was a wierd bug where, if I used FireFox 3 to enter the proxy info, it would default the user and password to those I used to log into Hudson. This didn't happen on IE 6.)

This seemed to make no difference at all. The same error popped up as before.

Second Try

I use the command line to start Hudson. Its a command like "java -jar ..." with a zillion options included. So I added "-Dhttp.proxyHost= and -Dhttp.proxyPort=" to the command line.

This had a different result. The plugin upload would work but Hudson could no longer access my Subversion server. The error message appeared in the console log when a job would run but it still said "No route to host".

Third Try

Well, I thought, I will need to exclude the Subversion server from Java's proxy information. This should have worked by adding "-Dhttp.nonProxyHosts=*.domain.com" to the command line.

This didn't work either. I don't know why not but the errors were the same as in the 2nd try.

I took all that stuff off the command line.

Fourth Try

Now, I though, isn't there some way to tell Linux about a proxy to use by adding an environment variable of some sort. I had to Google around to find it. You add an entry to the environment with a command like "export HTTP_PROXY=http://proxy.domain.com:8080/" if you are just typing. I left off the "export" part for the shell script that starts Hudson running.

This worked. Things would update inside Hudson. The jobs can get to the Subversion server. All seems to be cool now.

Disclaimer

I don't claim to know why the last method worked. I don't know if it would work the same way if I was using Tomcat to run the hudson.war. I don't know if the "advanced" tab's proxy settings work better in a later release of Hudson.

All this ignorance on my part bothers me. But, for now, I'm just happy it works.

-- Lee