Version 2


    We have 2 (two) Master instances. One is with public access ( thus secured to view only activity without a password. It's accessible through https too. The other one is less secured and is VPN accessible only. All slaves are connected to the internal master instance and all jobs are executed within the JBoss QA Lab. The reason is that we can't afford duplicating resources we have in the lab externally.


    So selected builds are copied to the external instance and are public accessible.


    Internal and external instance communicate with the specially developed plug-in through https so password is cannot be easily sniffed. IT supplied a security certificate. Authentication is form based that is https only accessible. To be working with current plug-ins certificate must be trusted so either ordered from a well recognized authority (like now) or CA installed in the JVM.


    JBoss EAP 4.2 is used to run hudson.


    We have a test Hudson installation within the lab. It's a stripped down version of the production one with few slaves so we can test new plug-ins and Hudson versions without breaking CI system which many teams seem to heavily rely on.


    Current master nodes' configuration

    There are startup and stop scripts designed to not mess JBoss EAP instance startup environment with that of the hudson executor. That btw turned out to be pretty useless after we moved all jobs off master.


    We have customized hudson jboss-web.xml and web.xml so in the server deploy dir there is symlink to ~/hudson_release which in turn is a symlink to hudson_/unzipped.


    Workspace is set to ~/hudson_workspace through an environment variable.


    Java processes are started with -Xmx so we have enough memory for reports. For hudson/EAP it is set by the start-up scripts as well for slaves. Master has to have memory to accept big junit reports. Slave has to have memory to send them...

    Internal instance

    • redirect jsp so no need to manually write /hudson (deploying to root makes problems)

    • iptables DNAT to have http and https on the default ports

    Public instance

    • Configured for https

    • redirect jsp so no need to manually write /hudson (deploying to root makes problems)

    • login form marked confidential in web.xml

    • iptables DNAT to have http and https on the default ports

    • Read only protected


    Better look at actual configuration. The idea is to implement better protection of both - internal and external instance using jboss-security.


    Unix slaves setup

    Currently linux slaves have to be configured to use LDAP and mount the common NFS drives. Hudson user has to be able to ssh to them.

    Packages of the standard installation are as follows: screen, vnc-server (requires: xorg-x11, xterm, xorg-x11-twm), vim-enhanced, vim-X11, mc, compat-libcom_err, lynx, emacs. Probably vnc-server is only important as we use the vnc plug-in for some projects.


    Unix slaves are started by a very simple script because actually environment is handled by the bash login scripts. Look at ~/.profile.d/ for host local configuration.


    Basically for every slave there are JAVA,ANT, mvn and svn in path as well MYTESTIP_X, MCAST_ADDR and MAX_JAVA_MEM set.


    Windows slaves setup

    Look at Windows slaves setup.