Projects that are newly created on master/slave-enabled Hudson will be by default configured to roam freely.
Master on public network, slaves within firewall
One might consider setting up the Hudson master 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.) This can generally be made to work in two means:
- Allow port-forwarding from the master to your slaves within the firewall. The port-forwarding should be restricted so that only the master with known IP can connect to slaves.
- Use JNLP slaves and have slaves connect to the master.
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.
- 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