> > Is there anything wrong with > > making a remote machine [a] distcc system? > > Not really, but you do need to realize that distcc doesn't guarantee that > jobs will be sent to the remote machines and will not prevent jobs from > being run locally. If there are not enough distcc hosts to support the > number of jobs being run, or the network is down to 1 or more, or other > such issues, you might end up having too many compiles being run locally. > This applies even if you put something like localhost/2 in your distcc > hosts -- when distcc runs out of hosts it unconditionally uses local > compilation.
Good to know for sure. > Also, distccd is a wide-open security hole: there's little to no > restriction on what a client can run on the host, and AFAIK only > ip/host-based restrictions on who can connect. A few, well-placed IP > packets with spoofed sources could theoretically result in a rooted box > (depending on other security features like firewalls, syn cookies, > restricted shells, chroot jails, and presence of local privilege > escalation exploits). Not good. The remote machine I'm considering using distcc on is my business's server. I can't have break-ins there. > It's probably better to use distcc over ssh, using an ssh-agent and PKI > authentication. That does involve giving shell access to an account, but > you probably already have an account that will work. :) Unfortunately, > this removes the host's ability to limit simultaneous distcc jobs AFAIK. > It also makes it quite a bit harder to distcc from cron, but most of the > time that shouldn't be an issue. So using distcc along with ssh and PKI would be sufficient to prevent the rooted box mentioned above? How would ssh and PKI be set up in the workflow? It isn't mentioned here: http://www.gentoo.org/doc/en/distcc.xml - Grant -- gentoo-user@gentoo.org mailing list
