Recent Hudson improvements with various OS
When run on Unix, Hudson can now authenticate users through the operating system, by using its user database and group database.
I noticed that many Unix deployment of Hudson chooses LDAP for the authentication, but the problem with LDAP is that there are too many things that you need to configure. You have to configure the root DN, you need to tweak the queries, and you often need to give you what's commonly referred to as "manager DN". You make mistake on any one of them, and authentication won't work. I've seen a number of user reports about failed LDAP configurations, and to make the matter even worse, there's nothing I can do to help them, since the set up differs from one LDAP to another.
But often, the same people manages to set up Unix correctly so that it does authentication against the same data that's in LDAP. This is often easier partly because there are more documents, and partly because some identity solutions speak native protocols for authentication (like NIS.)
This new addition to Hudson enables users to simply take advantages of existing configuration on the OS. Users will use the same Unix login name/password for accessing the system, and you can use Unix groups for access controls. And this option doesn't require any additional configurations at all.
On Windows front, Hudson can now start a Windows slave completely remotely, without any human intervention.
In the past, managing Windows slaves have been painful for many users, because of the lack of remote access technologies like ssh. You either have to install Cygwin, or do some interactive set up on each slave. With this new feature, you just need to give Hudson an administrator user name and password. By using DCOM and WMI, Hudson will talk to Windows remotely, and start the slave agent automatically. And even better, this works even when your Hudson master runs on Unix.
The administrative access to Windows will enable Hudson to do more than just starting/stopping slave. In the future, I plan to use this to synchronize clocks, restart Windows if necessary, or even determine the system capacity automatically.
And finally, on Solaris, if Hudson notices that you have ZFS, it'll switch its workspace to a ZFS file system, upon your approval. Again, as with everything else in Hudson, this happens automatically. Hudson on ZFS will make a lot of things possible, such as consistent back-up without down time, guaranteed clean build without forcing you to check out for each build, and forking a matrix build without duplicated check-outs. Stay tuned for more progress on this front.