[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