Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


A copy of slave.jar can be downloaded from http://yourserver:port/jnlpJars/slave.jar . Many people write scripts in such a way that this 160K jar is downloaded during the running of said script, to make sure the ensure that a consistent version of slave.jar is always used. The Such an approach eliminates the slave.jar updating issue discussed below. Note that the SSH Slaves plugin does this automatically, so slaves configured using this plugin always use the correct slave.jar.


Example: Configuration on Unix

This section describes my current Kohsuke Kawaguchi's set up of Jenkins slaves that I use he used inside Sun for my his day job. My His master Jenkins node is running on a SPARC Solaris box, and I have he had many SPARC Solaris slaves, Opteron Linux slaves, and a few Windows slaves.

  • Each computer has an user called jenkins and a group called jenkins. All computers use the same UID and GID. (If you have access to NIS, this can be done more easily.) This is not a Jenkins requirement, but it makes the slave management easier.
  • On each computer, /var/jenkins directory is set as the home directory of user jenkins. Again, this is not a hard requirement, but having the same directory layout makes things easier to maintain.
  • All machines run SSHDsshd. Windows slaves run cygwin sshd.
  • All machines have ntp client /usr/sbin/ntpdate installed, and synchronize clock regularly with the same NTP server.
  • Master's /var/jenkins have all the build tools beneath it --- a few versions of Ant, Maven, and JDKs. JDKs are native programs, so I have JDK copies for all the architectures I need. The directory structure looks like this:
    No Format
      +- .ssh
      +- bin
      |   +- slave  (more about this below)
      +- workspace (jenkins creates this file and store all data files inside)
      +- tools
          +- ant-1.5
          +- ant-1.6
          +- maven-1.0.2
          +- maven-2.0
          +- java-1.4 -> native/java-1.4 (symlink)
          +- java-1.5 -> native/java-1.5 (symlink)
          +- native -> solaris-sparcv9 (symlink; different on each computer)
          +- solaris-sparcv9
          |   +- java-1.4
          |   +- java-1.5
          +- linux-amd64
              +- java-1.4
              +- java-1.5
  • Master's /var/jenkins/.ssh has private/public key and authorized_keys so that a master can execute programs on slaves through ssh, by using public key authentication.
  • On master, I have he had a little shell script that uses rsync to synchronize master's /var/jenkins to slaves (except /var/jenkins/workspace) I use this . He also used the script to replicate tools on all slaves.
  • /var/jenkins/bin/launch-slave is a shell script that Jenkins uses to execute jobs remotely. This shell script sets up PATH and a few other things before launching slave.jar. Below is a very simple example script.
    Code Block
    export PATH
    java -jar /var/jenkins/bin/slave.jar


Access an Internal CI Build Farm (Master + Slaves) from the Public Internet

One might consider setting up make the Jenkins master accessible on the public network (so that people can see it), while leaving the build slaves within the firewall (because having a lot of machines on the internet is expensive.typical reasons: cost and security) There are two several ways to make it work:

  • Equip the master node with a network interface that's exposed to the public Internet (simple to do, but not recommended in general)
  • Allow port-forwarding from the master to your slaves within the firewall. The port-forwarding should be restricted so that only the master with its known IP can connect to slaves. With this set up in the firewall, as far as Jenkins is concerned it's as if the firewall doesn't exist.  If multiple hops are involved, you may wish to investigate how to do ssh "jump host" transparently using the ProxyCommand construct.  In fact,  with a properly configured "jump host" setup, even the master doesn't need to expose itself to the public Internet at all - as long as the organization's firewall allows port 22 traffic.