On Wed, Jul 23, 2008 at 10:11 AM, Ian Baker <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc