[distcc] Thoughts on distcc enhancements

[Dan Kegel]

I've been using distcc heavily for several years now.
It's great, but could use improvements in:
  - configuration (e.g. autoconfiguration)
  - load balancing (e.g. dealing with servers on sometimes-busy desktops)
  - security

My 'lsdistcc' helper app does a pretty good job of
resolving the autoconfiguration problem, at least
at my (large) site.  'dmucs' might help with both
autoconfiguration and load balancing, but I haven't tried it.
But nobody has much looked at improving distcc's
security since the addition of the allowed client ip address feature.
(ssh is arguably a solution, but it requires users to be
able to log in to the servers, which isn't practical for me.)

So I'm giving it a whack.  I, Jeff Evarts, and Dongmin Zhang
are looking at using kerberos and ldap for authentication and
authorization.   Because those services are too slow to use
on each invocation of distcc, we're going to switch to a persistant
connection model.  In our prototype, a local per-user client proxy
will start up authorized connections to the distcc servers ahead of time,
and distcc will grab already-open connections from the local proxy.
We ought to have some results before the end of the year (knock on wood).

It's tempting to go a bit further, and have the server start a new
chroot jail for each connection.  Figuring out how to set up
a new chroot jail on the fly, quickly and safely, is an interesting
challenge.

Since it's hard to make software truly secure, it's common
practice to have a very small, simple part that handles
security; that makes it easier to avoid security holes.
So it's tempting to refactor distcc into two parts:
a simple, secure job queuing service, and a gcc-aware service
built on top of it.  I've only just started thinking about this.

Anyway, those are my thoughts at the moment.  With luck, I'll
get to do something about them in the next year!
- Dan