1 |
Dnia 2015-01-21, o godz. 16:00:55 |
2 |
Alexis Ballier <aballier@g.o> napisał(a): |
3 |
|
4 |
> On Wed, 21 Jan 2015 11:05:34 +0100 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > Hello, developers. |
8 |
> > |
9 |
> > As you may recall, the main blocker for wide-establishment of |
10 |
> > FEATURES=network-sandbox prohibiting network access within the build |
11 |
> > environment is distcc. Since all connectivity is disabled, distcc can |
12 |
> > no longer reach other distcc servers and build efficiently. I |
13 |
> > therefore find it important to figure out a solution. |
14 |
> > |
15 |
> > I see two generic approaches possible here: |
16 |
> > |
17 |
> > 1. proxying distcc from within the build environment, or |
18 |
> > |
19 |
> > 2. moving distcc-spawned processes back to parent's namespace. |
20 |
> |
21 |
> [...] |
22 |
> |
23 |
> > |
24 |
> > Any other ideas? |
25 |
> > |
26 |
> |
27 |
> I haven't followed this at all, so this might be very stupid: |
28 |
> Isn't it possible to whitelist distcc hosts ? |
29 |
|
30 |
No because the child process is completely disconnected from parent's |
31 |
network stack. It has only a brand new loopback that's even separate |
32 |
from host's loopback. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |