[Buildbot-devel] Masters behind firewalls?
warner-buildbot at lothar.com
Tue Sep 7 19:11:04 UTC 2004
> I'd like to be able to set up a master behind a firewall, and allow slaves
> to be behind other firewalls. Is there a way to set things up like this? I
> want to avoid having to host the master off-site.
Not really. The build slaves have to be able to make a TCP connection to the
master. I designed it that way because I figured it was more likely that a
publically-visible project would have a publically-visible master, and
because it allows the build slaves to be behind NAT boxes.
Doing it the other way around (having the master connect to the slaves) would
let you have a master behind a NAT box, but it would prevent NATed home
systems from participating as build slaves, and the whole idea of the
buildbot is to get as many (diverse) build slaves as possible. Requiring that
all those slaves be available on the open internet would unnecessarily limit
the set of people could provide build slaves.
That said, if your firewall arragement is such that you can allow the slaves
to connect to the master, then you can do it. The slaves make a TCP
connection to the host and port you configure into them at mktap time. Any
kind of filtering holes / port forwarding / ssh tunneling / ipsec tunneling /
SOCKS proxy you can think of will work, as long as it allows that one TCP
connection to be established. For two systems behind firewalls, if you have a
common system under your control, you may be able to rig a pair of SSH
tunnels that do it:
slogin -L5555:localhost:6666 common.example.com
slogin -R6666:localhost:7777 common.example.com
The hard part about this approach is setting up those tunnels automatically.
I think there is an ssh/slogin option to not run a command at the other end
(or close stdin/stdout or something) which might be appropriate.
Of course, the slaves will have to be able to check out the sources too,
which may be difficult unless the source repository is outside both
firewalls. I'm considering adding a source-acquiring BuildStep which would
perform a source checkout *on the master* and then send a tarball with the
results down to each slave: chews up a lot of bandwidth (on a system that may
not have have a lot), but could be useful in certain configurations like that
one, particularly for small trees.
That technique could also help if the sources are not quite available
publically and there is some secret or SSH key you need to get a copy. In
particular, for the meta-buildbot I'm trying to set up, I'm thwarted by
sf.net's 5-hour latency between the time you check something in and the time
it appears on the public (read-only) anonymous-CVS repository. I must either
use a tree-stable-timer of like 6 hours, or use something gnarly in which I
push a local copy of the current source tree over to the machine that hosts
the master each time I make a commit, and then have the master distribute
that source tree to the slaves. Like I said, ugly, but could be useful if
your requirements are weird enough.
So anyway, your mission (should you choose to accept it) is to find a way to
let those slaves make those TCP connections to the master.
More information about the devel