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

[Michał Górny]

Dnia 2015-01-27, o godz. 02:46:37
Andrew Savchenko <bircoph@g.o> napisał(a):

> 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);

Adding SOCKSv5 support is something of potentially generic benefit
unlike adding Gentoo-specific hacks.

> 2) will require a _separate_ solution for icecream and thus a
> double effort;

It would require a separate solution for icecream anyway. If icecream
had SOCKSv5 support, the solution would be as simple as exporting extra
variable for it. Unlike the other case when Portage needs to become
aware of layout of another tool.

> 3) adds additional latency for distcc network path, which is
> undesirable.

Unlikely to be measurable. ~20 extra bytes over UNIX socket. In fact,
this provides us with ability to do some tricks to actually improve
the latency -- like caching extra connections in the proxy.

In fact, the other solution is more complex and therefore more likely
to cause delays.

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

I know. Forgive me the wording but it's pretty much crap code.
Involving ideas such as enabling non-blocking I/O just to read it
in loops to get blocking behavior.

I would rewrite it from scratch if it were simpler. But the pump mode
and other extra features makes it require too much effort. At least
it's not something I could do in my free time.

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

I'm not convinced it's worth the effort to support it in distcc. I once
published a blog post how to use gcc output to replace -march=native
with the expanded flags. I find that saner.

That said, pump mode is the only significant change in late distcc
history. And it's broken anyway, and I doubt anybody's going to fix it
since the failures are pretty random and hard to reproduce.

-- 
Best regards,
Michał Górny