Martin Pool wrote:
It seems like this approximates the other proposed behaviour of having
distcc.$SITE.company.com have A records for all the servers, and then
doing locking etc by ip address. It has the advantage of requiring
less cooperation from the DNS administrators, but the disadvantage of
being a bit more of a special purpose hack.
I like to think of it as "appropriate technology". It's
darn hard to get the attention of the IT staff at
most large companies, so minimizing their involvement
is a key to success in many environments.
Also, the idea you mention has a problem when the set of A
records is larger than 512 bytes, doesn't it? (Or is RFC2671
universally deployed already?) That would make it hard
to use for large clusters.
I've polished and debugged the patch; the new version is at the same URL,
http://kegel.com/distcc-domain.patch
It no longer has any appreciable overhead beyond an extra stat
when the feature is not in use, so it's safe to always enable.
I haven't deployed it yet, but I'll try to do that this week.
Incidentally, my init.d script that starts up distccd will read
the list of allowed networks from /etc/distcc/$domain/hosts.allow,
so the idea of a $domain subdir for /etc/distcc
seems to be more than just a special purpose hack.
I suspect it will be generally useful at large multisite companies.
- Dan
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
