Skip to main content

Recent Hudson improvements with various OS

Posted by kohsuke on February 27, 2009 at 10:32 PM PST

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.

Related Topics >>

Comments

I'm subscribed to the feed through FeedDemon on Windows. For the last two weeks, each time I opened up FeedDemon, this post here shows up as a new post, no matter how often I mark it as read. Anybody else having this problem?

I should have mentioned that, too. A recent version of Hudson lets you override tool locations per slaves to finally fix that problem.

Thank you for the Windows slave functionality. This is exactly the missing part I was looking for to give windows based slaves (in a mainly unixoid environment) a try. The different paths (for Ant, Java, etc.) are still a pain yet. Is there any possibility to have node specific paths configured?

I'm running tomcat on AIX (5.3) and got exception. Look like this only works on Sun since it calls Sun's native library? Thanks. Phi /////////////////////////////// SEVERE: Servlet.service() for servlet Stapler threw exception java.lang.NoClassDefFoundError: com.sun.jna.Native (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:132) at com.sun.jna.Structure.(Structure.java:108) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:194) at java.lang.J9VMInternals.initialize(J9VMInternals.java:159) at org.jvnet.libpam.PAM.(PAM.java:49) at hudson.security.PAMSecurityRealm$1.authenticate(PAMSecurityRealm.java:74) at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter. java:71) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java: 249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:66 5) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:810)