-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/08/13 11:30 AM, Douglas Freed wrote: > On Aug 20, 2013 11:20 AM, "Michał Górny" <mgo...@gentoo.org > <mailto:mgo...@gentoo.org>> wrote: >> >> Dnia 2013-08-20, o godz. 11:04:35 Alexis Ballier >> <aball...@gentoo.org <mailto:aball...@gentoo.org>> > napisał(a): >> >>> On Tue, 20 Aug 2013 12:26:03 +0200 Michał Górny >>> <mgo...@gentoo.org <mailto:mgo...@gentoo.org>> wrote: >>>> >>>> 2. FEATURES=network-sandbox >>>> >>> >>> does distcc work with this ? >> >> You could say that. It just can't connect to any other host :). >> >> We may try to handle this somehow but I can't immediately think >> of any sane way of 'escaping' the sandbox. > > You could do it the same way as LXC does, with a virtual interface > which is then NAT-ed to the real network interface, but I'm not > sure I'd consider this sane. The overhead required to set this up > on every execution of gcc, let alone the modifications needed for > NAT, pretty much makes rules this out completely. You might be > able to exploit iptables and ip6tables to allow only distcc to > communicate out, but that's still painful and is a hack at best. > > -Doug >
It's a feature; all features are optional. It's just not going to be able to be enabled along with FEATURES="distcc" is all. I'm sure we have other features that collide with one-another too, so i don't see this being a big issue. ... similarly, though, i wonder if this would cause issues with i.e. diskless systems or others, that use nfs-mounts for /var/tmp/portage ..? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlITjmgACgkQ2ugaI38ACPBf2QEAvr1vWy6hDQjvZga1ijS2Zqf9 bnaDrxjvdIo8gh+xtooA+QFxZHLiH83KCgKGLuxYMIjpjWo1pHe+Qcy20s8woKMj =74dq -----END PGP SIGNATURE-----
