Note that in both cases, once the master is compromised, all your slaves can be easily compromised (IOW, malicious master can execute arbitrary program on slaves), so both set-up leaves much to be desired in terms of isolating security breach. Build publisher plugin (which looks almost ready as of this writing) provides another way of doing this, in more secure fashion.
Running Multiple Slaves on the Same Machine
It is possible to run multiple slave instaces on a Windows machine, and have them installed as separate Windows services so they can start up on system startup.While the correct use of executors largely obviates the need for multiple slave instances on the same machine, there are some unique use cases to consider:
- You want more configurability between the configured nodes. Say you have one node set to be used as much as possible, and the other node do be used only when needed.
- You may have multiple Hudson master installations building different things, and so this configuration would allow you to have slaves for more than one master on the same box. That's right, with Hudson you really can serve two masters.
Follow these steps to get multiple slaves working on the same Windows box:
- Add the first slave node in Hudson and give it its own working dir (e.g. hudson-slave-a).
- Go to the slave page from the slave box and launch by JNLP, then use the menu to install it as a service instead.
- Once the service is running, you'll get hudson-slave.exe and hudson-slave.xml in your slave's work dir.
- Bring up windows services and stop the Hudson Slave service.
- Open a shell prompt, cd into the slave work dir.
- First run "hudson-slave.exe uninstall" to uninstall the one that the jnlp-launched app installed. This should remove it from the service list.
- Now edit hudson-slave.xml. Modify the id and name values so that your mutliple slaves are distinct. I called mine hudson-slave-a and Hudson Slave A.
- Run hudson-slave.exe install and then check the Windows service list to ensure it is there. Start it up, and watch Hudson to see if the slave instance becomes active.
- Now repeat this process for a second slave, beginning with configuring the new node in the master config.
When you go to create the second node, it is nice to be able to copy an existing node, and copy the first node you setup. Then you just tweak the Remote FS Root and a couple other settings to make it distinct. When you are done you should have two (or more) Hudson slave services in the list of Windows services.
- Every time Hudson launches a program locally/remotely, it prints out the command line to the log file. So when a remote execution fails, login to the computer that runs the master by using the same user account, and try to run the command from your shell. You tend to solve problems quickly in this way.
- Each slave has a log page showing the communication between the master and the slave agent. This log often shows error reports.
- If you use binary-unsafe remoting mechanism like telnet to launch a slave, add the
slave.jarso that Hudson avoids sending binary data over the network.
- When the same command runs outside Hudson just fine, make sure you are testing it with the same user account as Hudson runs under. In particular, if you run Hudson master on Windows, consult How to get command prompt as the SYSTEM user.
- Feel free to send your trouble to