Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc

[Andrew Savchenko]

Hi,

On Sun, 25 Jan 2015 14:59:01 +0100 Michał Górny wrote:
> Dnia 2015-01-21, o godz. 11:05:34
> Michał Górny <mgorny@g.o> napisał(a):
>
> > Generic proxy solution
> > ----------------------
> >
> > The simplest solution so far seems to be setting a generic SOCKS proxy
> > inside the build environment, and wrapping distcc so that it will use
> > it for network access.
> >
> > Unless we do some extra magic which don't want to do, this means that
> > other apps can also abuse the proxy to reach outside sandbox. However,
> > network-sandbox is not really a security feature, so I don't think that
> > is important. At least as long as we don't export it globally :).
> >
> > Of course, software is a problem. We'd need at least some SOCKS server
> > for Portage (at least a very simple one), and as far as I'm aware
> > distcc does not support SOCKS directly, so tsocks in addition to that.
>
> So finally went this way instead.

I still don't understand why. This solution:
1) is intrusive, it requires patching distcc and upstream as good
as dead (see below);
2) will require a _separate_ solution for icecream and thus a
double effort;
3) adds additional latency for distcc network path, which is
undesirable.

Parent namespace solution looks like the most reasonable for me
based on both arguments above and years of heavy distcc usage
experience.

> [2]:https://code.google.com/p/distcc/issues/detail?id=149

Chances to have this upstream are close to zero. If it is not
dead, it is very close to it. Number of bugs and patches is
accumulating without any response. No releases from 2011.
Probably someone should fork it...

Distcc has a problem with -march=native right now:　it just falls
back to local compilation if encountered it. I sent them a patch
1.5 years ago [1] and still no reply... It also requires some
patches for successful cross-compilation when plain gcc is invoked
by the client. (I have patches for amd64 <-> x86 only and they may
broke pump mode (never used it anyway), thus I haven't send them
upstream.

[1] https://groups.google.com/forum/#!topic/distcc-patches/eeP-9pTgz7E

In short, this patch expands "native" argument using gcc output,
caches result (based on fingerprint of compiler being invoked)
and sends expanded string to distcc servers. It is in my overlay
(bircoph) if someone is interested. Works fine for me all these
time.

Best regards,
Andrew Savchenko