[distcc] Proposed Enhancements/Changes

Fergus Henderson fergus at google.com
Wed Jul 23 18:40:26 GMT 2008

On Wed, Jul 23, 2008 at 10:11 AM, Ian Baker <Ian.Baker at cern.ch> wrote:

> Good afternoon to everyone.  My name is Ian Baker and I'm currently at
> CERN as a technical student working on the following enhancements/changes
> to
> distcc:

Hi Ian,

Welcome aboard!  Thanks heaps for sending your email; it really helps to
discuss these sort of design ideas before launching into implementation.

> User Authentication
> Implemented through the GSS-API and specified through a command line
> argument to distcc, distccd will be initiated with the appropriate option.
> Initially only mutual authentication will be implemented, at a later stage
> confidentiality and integrity services may be optionally configurable if
> this is something that's needed.

Have you considered using ssh mode for user authentication?
With ssh connection sharing, the performance may be good enough,
and by using ssh you get a number of important benefits:
  - the "trusted code base" that your security depends on has already been
very thoroughly vetted
  - you get confidentiality and integrity services for free
  - less code to maintain in distcc

As far as I know, no-one has run any benchmarks of ssh with connection
So that would definitely be what I would recommend as a first step.

For more details on ssh connection sharing, see "How can I use SSH
connection multiplexing?" in the distcc FAQ

> Service Discovery
> Existing Zeroconf mechanism with the advertisement of specific build
> platforms for targeted builds.

That sounds like a good idea. But I would like to hear more about the

Targeted Builds
> Command line argument to distcc which causes the appropriate subset of
> servers to be extracted from the Zerconf services list.

This clearly goes hand-in-hand with the previous item.
Something along those lines sounds good.
Although I wonder whether maybe it should go in DISTCC_HOSTS rather than in
a command line option?

Node Protection
> The --randomize flag should be turned on by default,

Seems reasonable to me.  At Google we always use the --randomize flag.

> with the possibility of extending this behaviour over slots.

Yes, the current randomization is clearly suboptimal - patches here would be
very welcome.

Monitoring and Accounting
> In addition to standard logging activity authentication information is to
> be written to the distccd log files.  A centralized service is to extract
> these log files and parse their contents, possibly linked to an HTTP server
> for
> browser access.

Sounds reasonable, assuming that this is a separate component that is not
tightly coupled to the distcc client and server (e.g. it should be

Fergus Henderson <fergus at google.com>
-------------- next part --------------
HTML attachment scrubbed and removed

More information about the distcc mailing list