Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Dnia 2015-01-27, o godz. 02:46:37 Andrew Savchenko 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 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 pgpNKxnYyGjOn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Dnia 2015-01-25, o godz. 16:44:20 "Thomas D." napisał(a): > Hi, > > Michał Górny wrote: > > I see two generic approaches possible here: > > > > 1. proxying distcc from within the build environment, or > > > > 2. moving distcc-spawned processes back to parent's namespace. > > > > > > distcc client/server solution > > - > > > > The most obvious solution to me is to employ a client/server model > > where a system-wide daemon is running, parsing /etc/distcc/hosts > > and doing all the network activity. > > > > [...] > > It is not only distcc. Please don't forget things like sys-devel/icecream. I care for what I use. If people want their icecreams, they have to write a patch themselves :). -- Best regards, Michał Górny pgpejbGCkMACU.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Dnia 2015-01-27, o godz. 03:03:31 Andrew Savchenko napisał(a): > On Sat, 24 Jan 2015 12:03:27 +0100 Michał Górny wrote: > > Dnia 2015-01-21, o godz. 11:05:34 > > Michał Górny napisał(a): > > > > > Parent namespace solution > > > - > > > > > > The alternative is to wrap distcc so that parent network namespace is > > > regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to > > > parent's /proc entry (so root privileges). > > > > > > We obviously don't want to lose userpriv, so we have to do with setuid > > > wrapper. Of course, setuid wrappers need to be written in C, so we need > > > to introduce C compiled executable in Portage. Then we need to take some > > > special care for it not to be abused, e.g. to access restricted network > > > namespaces of other processes. > > > > I've started to work on this, and I have all the setup.py code ready. > > Now it's just the C program and wrapping it all in Portage. > > > > The only remaining big issue is how to pass the correct namespace (or > > PID) to the distcc process, assuming it may be a deep child of > > the ebuild process. > > > > Possibilities: > > > > 1. Environment variables. Can't do because: > > > > a. one of the parent processes may scrub the environment, > > > > b. malicious process may override the variable, giving subprocess > > access to restricted system network namespace. > > > > 2. Files. Can't do because we would have to pass the path somehow (see > > 1.), and if we go for static path, we have collisions between multiple > > emerge processes. > > If we're not going to use PID isolation in future, PID-dependent > "static" file name may be used, where PID belongs to emerge. This > should solve the collision issue. I didn't want to make network-sandbox depend on another FEATUREs. > > 3. Parent process hierarchy. Seems fragile, requires a lot of scanning > > on every spawn and may end up in the wrong namespace if a subprocess > > calls setsid() and user put emerge in a separate namespace. > > Why not to use cgroups here? Not sure if cgroups help here. In our cgroup hierarchy, only child processes are governed. Not sure if setsid() behaves any different with that. > > 4. IPv4 socket. While it may seem a real dumb idea, it fits the case > > perfectly since it is only run if process is network-namespaced. We can > > surely reserve a static port early and run a daemon outputting > > the correct PID. Since the port is namespaced, every Portage process > > can have its own PID-daemon, and I don't know if there's any way of > > overriding the result from parent process. > > Looks fine, though the very idea to have extra daemons is > unpleasant. Yes, that's one of the issues. And spawning anything from inside ebuild process is terribly hacky and fragile since it doesn't do any proper process management. My initial implementation had even more issues: PATH changes were permanent because of env saving (so post-distcc phases still had distcc wrappers) and ld.so complained because setuid caused libsandbox not to be preloaded. Such errors could break configure checks. -- Best regards, Michał Górny pgpxKYzNyUNS1.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-27, o godz. 10:18:37 Alexis Ballier napisał(a): > On Mon, 26 Jan 2015 20:09:18 +0100 > Michał Górny wrote: > > > Dnia 2015-01-26, o godz. 16:40:35 > > Alexis Ballier napisał(a): > > > > > On Mon, 26 Jan 2015 16:20:10 +0100 > > > Michał Górny wrote: > > > > > > > Dnia 2015-01-26, o godz. 12:41:00 > > > > Alexis Ballier napisał(a): > > > > > > > > > On Sat, 24 Jan 2015 00:35:39 +0100 > > > > > Michał Górny wrote: > > > > > > > > > > > Title: CPU_FLAGS_X86 introduction > > > > > > Author: Michał Górny > > > > > > Content-Type: text/plain > > > > > > Posted: 2015-01-xx > > > > > > Revision: 1 > > > > > > News-Item-Format: 1.0 > > > > > > Display-If-Keyword: amd64 ~amd64 x86 ~x86 > > > > > > > > > > but why ? > > > > > will you write another news item for other arches ? > > > > > > > > Are there other arches using CPU_FLAGS_X86? ;) But seriously, the > > > > item is quite arch-specific. Other arches are likely to have > > > > kinda specific flags with rules for choosing them, another script > > > > etc. > > > > > > I think it is better to have it done all in one pass: even if there > > > is no script, it is just as good as it is today. > > > > > > My concern is: This will clutter e.g. ffmpeg ebuild by having two > > > ways to pass cpu flags, depending on the arch, and will give a kind > > > of silly output with "altivec" or "neon" as standard useflags but > > > x86 cpu flags as USE_EXPAND. This is too much inconsistent to me. > > > > I understand your concern but unless someone's going to do the work > > for other arches, I doubt there's a point in waiting forever. Script > > is a minor issue, but someone has to figure out how various packages > > behave and what flags to use. > > > > It doesn't have to be perfect, just consistent. As of figuring out how > to have such flags, I already gave you the link: profiles/base/use.mask. I'm afraid this mail pretty much proves why we shouldn't do this. > Let's see: > > # ppc arch specific USE flags > altivec > pbbuttonsd Is this even a USE flag? Maybe you meant USE=macbook or something like this? > ppcsha1 This is not a CPU feature, and i'm not sure if this should be an explicit flag at all. This sounds like 'use ppc' + 'use asm'. > # mips arch specific USE flags > n32 > n64 Those are rather covered in ABI_MIPS. > fixed-point > loongson2f > mips32r2 > mipsdspr1 > mipsdspr2 > mipsfpu The MIPS team will likely want to drop some of the prefixes. > # sparc arch specific USE flags > vis > ultra1 > > etc. > > grep their desc in use.desc or .local.desc and paste these to > profiles/desc/cpu_flags_xxx.desc, and you're done. > if you want to do things better, open a bug for relevant arch team to > review it, improve it or remove useless stuff; it'd be better tracked > than a discussion here. True, a bug is a good idea. > Anyway, flags renamings will have to be done on a per-package basis, > probably with a bug openened and certainly with proper review done, so > that being x86* only or all arches makes little to no difference. Even > better: you won't have me on your back ranting against pointless > inconsistencies :) The point is not to publish a news item telling people to update flags before we decide on the final flags. The list pretty much covered x86 flag review, and found issues that we were able to fix before committing. -- Best regards, Michał Górny pgpkqiqGHcOlF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Review: USE=libav news item
On 27/01/15 01:19, Gordon Pettey wrote: Chromaprint will work /differently/ depending on which is used. I added libav support to it, but the fingerprints are not the same as fingerprints generated when using ffmpeg. I've not gotten around to fixing that, so if such a list is being compiled it should be noted on the "don't arbitrarily switch between ffmpeg and libav if this tool is important to you" list. chromaprint uses a coarse (and quick) resampler if I recall correctly and that would lead to differences if the resampler used is different, I never had the time to check if would be possible to set it to use a specific resampler that would work in the same way. lu
Re: [gentoo-dev] Review: news item and script for CPU_FLAGS_X86
On Mon, 26 Jan 2015 20:09:18 +0100 Michał Górny wrote: > Dnia 2015-01-26, o godz. 16:40:35 > Alexis Ballier napisał(a): > > > On Mon, 26 Jan 2015 16:20:10 +0100 > > Michał Górny wrote: > > > > > Dnia 2015-01-26, o godz. 12:41:00 > > > Alexis Ballier napisał(a): > > > > > > > On Sat, 24 Jan 2015 00:35:39 +0100 > > > > Michał Górny wrote: > > > > > > > > > Title: CPU_FLAGS_X86 introduction > > > > > Author: Michał Górny > > > > > Content-Type: text/plain > > > > > Posted: 2015-01-xx > > > > > Revision: 1 > > > > > News-Item-Format: 1.0 > > > > > Display-If-Keyword: amd64 ~amd64 x86 ~x86 > > > > > > > > but why ? > > > > will you write another news item for other arches ? > > > > > > Are there other arches using CPU_FLAGS_X86? ;) But seriously, the > > > item is quite arch-specific. Other arches are likely to have > > > kinda specific flags with rules for choosing them, another script > > > etc. > > > > I think it is better to have it done all in one pass: even if there > > is no script, it is just as good as it is today. > > > > My concern is: This will clutter e.g. ffmpeg ebuild by having two > > ways to pass cpu flags, depending on the arch, and will give a kind > > of silly output with "altivec" or "neon" as standard useflags but > > x86 cpu flags as USE_EXPAND. This is too much inconsistent to me. > > I understand your concern but unless someone's going to do the work > for other arches, I doubt there's a point in waiting forever. Script > is a minor issue, but someone has to figure out how various packages > behave and what flags to use. > It doesn't have to be perfect, just consistent. As of figuring out how to have such flags, I already gave you the link: profiles/base/use.mask. Let's see: # ppc arch specific USE flags altivec pbbuttonsd ppcsha1 # mips arch specific USE flags n32 n64 fixed-point loongson2f mips32r2 mipsdspr1 mipsdspr2 mipsfpu # sparc arch specific USE flags vis ultra1 etc. grep their desc in use.desc or .local.desc and paste these to profiles/desc/cpu_flags_xxx.desc, and you're done. if you want to do things better, open a bug for relevant arch team to review it, improve it or remove useless stuff; it'd be better tracked than a discussion here. Anyway, flags renamings will have to be done on a per-package basis, probably with a bug openened and certainly with proper review done, so that being x86* only or all arches makes little to no difference. Even better: you won't have me on your back ranting against pointless inconsistencies :) Alexis.
Re: [gentoo-dev] Review: USE=libav news item
On Mon, 26 Jan 2015 20:13:36 +0100 Michał Górny wrote: > > Thanks, applied your suggestions. Please read now ;). > LGTM, thanks
