hudson on kubuntu

1. Since I knew I had hudson deployed in tomcat, I fired up kubuntu Software Management control panel and searched for it. It turns out, once you install tomcat6, you also want tomcat6-admin. But tomcat manager installation through apt-get doesn't prompt you for a manager username and password. You'll need to reconfigure the users and add a manager role and set a user up as the manager. Slightly different from tomcat7, I would add.
2. Once you can get into the manager, you can follow these steps to eat a custom hudson deb. It will print a warning on omplete installation because tomcat is sitting on port 8080. That's ok. With the deb placing hudson.war on your machine and handling its updates, you could symlink it into place in tomcat. I just installed it using the web manager war copy deploy.
3. Browsing to http://localhost:8080/hudson throws a huge callstack. It turns out, tomcat is preconfigured with java security enabled, which breaks hudson. Turn it off and restart the init.d/tomcat6.
4. Damn. Get there, and it can't create HUDSON_HOME. Unable to create the home directory. Boo. Web suggests setting hudson environment variables in java options for the tomcat container.
5. So, this is like the opposite of most debian-based distro software configurations. Usually apt-get has you covered. Maybe I absolutely don't want tomcat installed. But I go, add the HHUDSON_HOME to /etc/tomcat6/context.xml as describe in a useful post at http://malor.se/blog/?p=57, set the permissions on /var/lib/hudson to tomcat.adm, and set the UTF-8-ness again. UTF isn't sticking.
   
6. So, after more doc reading, it becomes clear that you don't need to run your slaved node in a container, but rather spawn as a windows service (untested), or login from the slave and run the slave applet from the main hudson server. So I tried this from the vm, but it exploded when running from hudson, because I don't have dns working on my home machines and hudson doesn't gracefully work between resolved names and the ip address. The stacktrace reads something like "java.net.UnknownHostException: <hostname> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)". Spent a few minutes making sure home machines have reserved dns leases, and then set up bind9 to resolve fully qualified dns names. Maybe now running the slaved java applet will work.
7. No, clicking the slave spawning button on the slave machine just starts a mysterious window with picture of hudson in it, which fails to start the slave with no diagnostic info. Maybe because I already installed a master on the vm? I halt tomcat instance. No go. I uninstall the deb and try again. No go. Geezus. I guess Cruise has a leg up on the 'easy deployment' over Hudson. Seems like if they go to the trouble of making a hudson deb, they should just rename it to hudson master and make a hudson slave deb, prompting you for the master url in config step. Srsly.
8. Get distracted and do a dist-upgrade on the intended slave. Also find that kubuntu dist upgrade does not invoke an editor for merging changes. Weak. Oh well, see you tomcat config. I don't really need you for the slave instance (that I know of). Maybe I can deploy the slave in tomcat and document that. It kinda seems like that should be part of a client installer.
9. It seems like this is a lot harder than it needs to be. Whomever rebuilds a hudson master/slave installer for windows would probably get a lot of traction. It seems like it's possible, just taking so darn long it's not quite worth it.

Well, that's as far as I'm going to take that. Clearly, as usability goes, hudson has some room for improvement. On the other hand, it's not any different from our current home brew software, since we just spawn links on individual build machines with build steps.