[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
sharing.
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
<http://distcc.googlecode.com/svn/trunk/doc/web/faq.html>.


> 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
details.

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
optional).

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


More information about the distcc mailing list