FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-26-2012, 07:43 PM
Rich Freeman
 
Default Portage FEATURE suggestion - limited-visibility builds

On Thu, Jul 26, 2012 at 2:40 PM, Michael Mol <mikemol@gmail.com> wrote:
> (Really, this observation is more about simply making the information
> available; distcc could consume that information if someone chose to
> do the work to add that functionality.)

Well, I'm not sure how to get the info out of the internals of portage
itself (I have to imagine it would be fast since portage has to know
about it already), but for a list of packages you can xargs them into
qlist to get a list of all files, and then pipe that into a script
that will populate a chroot for you.

Quick script for those curious to try it out:

mkdir newroot
mount -t tmpfs none newroot
cd newroot
unshare -m /bin/bash
echo "list of packages" | xargs qlist | linkfile
(poke around)
exit
(note that bind mounts are gone)
cd ..
umount newroot ; rmdir newroot
(note that all traces gone)

Contents of linkfile script:
#!/bin/bash
install -D /dev/null "./$1"
mount -n --bind "$1" "./$1"

(That -n is important if you don't want to muck up your /etc/mtab )

BTW, unshare is a fun command to play around with if you've never used
namespaces. You can do things like replace commands by bind-mounting
right over them.

Rich
 
Old 07-26-2012, 09:45 PM
Alec Warner
 
Default Portage FEATURE suggestion - limited-visibility builds

On Thu, Jul 26, 2012 at 8:26 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I've been messing around with namespaces and some of what systemd has
> been doing with them, and I have an idea for a portage feature.
>
> But before doing a brain dump of ideas, how useful would it be to have
> a FEATURE for portage to do a limited-visibility build? That is, the
> build would be run in an environment where the root filesystem appears
> to contain everything in a DEPEND (including @system currently) and
> nothing else? It might be useful both in development/testing, and
> also in production use (not sure how performance would work in the
> real world - I was able in a script to get it to build an enviornment
> in a few seconds for a few packages).

You mean like cowbuilder?

http://wiki.debian.org/cowbuilder

>
> I really crazy idea would be to try to run packages in a similar
> environment, but I think that needs better kernel/etc level support
> since the performance hit would be much more noticeable, except for
> things like daemons that only start once.
>
> Implementing it wouldn't necessarily be hard - just create a tmpfs
> under /var/tmp/portage, unshare off a new mount namespace, and
> read-only bind-mount everything needed from the root filesystem
> (including /var/tmp/portage/...), and chroot into it. When the build
> is done the process governing it terminates and the kernel wipes out
> all the mounts and then portage unmounts the tmpfs. You wouldn't need
> to use a tmpfs for the build - it would actually be zero-size as
> reported by df since it just contains a bazillion bind mounts, though
> all those mounts would consume slab memory.
>
> Thoughts?
>
> Rich
>
 
Old 07-26-2012, 10:35 PM
Zac Medico
 
Default Portage FEATURE suggestion - limited-visibility builds

On 07/26/2012 11:26 AM, Rich Freeman wrote:
> Implementing it wouldn't necessarily be hard - just create a tmpfs
> under /var/tmp/portage, unshare off a new mount namespace, and
> read-only bind-mount everything needed from the root filesystem
> (including /var/tmp/portage/...), and chroot into it. When the build
> is done the process governing it terminates and the kernel wipes out
> all the mounts and then portage unmounts the tmpfs. You wouldn't need
> to use a tmpfs for the build - it would actually be zero-size as
> reported by df since it just contains a bazillion bind mounts, though
> all those mounts would consume slab memory.

It seems like you might need some kind of copy-on-write support, at
least to run pkg_setup. Apparently cowbuilder uses cow hardlinks for
that. Another way would be to use fiemap (cp --reflink).
--
Thanks,
Zac
 
Old 07-27-2012, 12:31 AM
"Gregory M. Turner"
 
Default Portage FEATURE suggestion - limited-visibility builds

On 7/26/2012 11:26 AM, Rich Freeman wrote:

I've been messing around with namespaces and some of what systemd has
been doing with them, and I have an idea for a portage feature.

But before doing a brain dump of ideas, how useful would it be to have
a FEATURE for portage to do a limited-visibility build? That is, the
build would be run in an environment where the root filesystem appears
to contain everything in a DEPEND (including @system currently) and
nothing else? It might be useful both in development/testing, and
also in production use (not sure how performance would work in the
real world - I was able in a script to get it to build an enviornment
in a few seconds for a few packages).


In practice I think it's going to be very hard to make this work in a
platform-independent way; however in principle this is a ridiculously
sexy idea that has crossed my mind more than once.


The challenge is that it requires either

o Building very large sandboxes on a per-package basis

or

o Python-level access to unionfs/aufs-style COW features.

Imagine the tree of dependencies which would need to be thrown together
for, i.e.: kmail or firefox! This makes the former approach seem damn
nearly infeasible. The latter approach holds more promise, I think, but
represents a pretty big development effort.


Still.... very sexy idea, if a python-fs-layering API could be coded up.

One thing to consider: even if it does work, continuing to support the
"old" way without fancy COW features is going to be required if portage
is still going to support Gentoo/Alt in all of its flavors (either that,
or unionfs/aufs features would need to be coded up for all those
platforms that lack them).


-gmt
 
Old 07-27-2012, 03:04 PM
Michael Palimaka
 
Default Portage FEATURE suggestion - limited-visibility builds

Autodep[1][2] is a current implementation of this idea, with library
hook and FUSE options.


Would definitely love to see more development in this area.

[1]: https://dev.gentoo.org/~neurogeek/guidexml/
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/autodep.git;a=summary
 
Old 07-27-2012, 03:37 PM
Rich Freeman
 
Default Portage FEATURE suggestion - limited-visibility builds

On Thu, Jul 26, 2012 at 6:35 PM, Zac Medico <zmedico@gentoo.org> wrote:
>
> It seems like you might need some kind of copy-on-write support, at
> least to run pkg_setup. Apparently cowbuilder uses cow hardlinks for
> that. Another way would be to use fiemap (cp --reflink).

Reflinks would be a much clearer implementation if you can assume
everything is on a single COW filesystem.

However, that seems like a bit of a strong restriction to have.
Cowbuilder seems to use hard links which are also limited to the same
filesystem, and it seems to use its own private build image besides.

I was thinking mainly in terms of giving limited visibility only to
those stages which should have it - the setup/postinst/etc phases
probably should have access to the real root.

A more ambitious undertaking would be to extend this to running
applications and not just building them. That is clearly beyond
portage (other than maybe maintaining the list of files requiring
runtime access), and would probably require either a namespace
extension to ld.so, use of MAC, or changes to the kernel itself. One
implementation might be auto-creating SELinux policies at install time
based on declared RDEPENDS.

Ideally I'd love to see something like this be usable on an end-user
system - and not just be a QA tool. Thanks to those who chimed in
with similar projects - glad to see some work already done in this
area.

Rich
 
Old 07-31-2012, 02:48 PM
"Paweł Hajdan, Jr."
 
Default Portage FEATURE suggestion - limited-visibility builds

On 7/26/12 8:26 PM, Rich Freeman wrote:
> I've been messing around with namespaces and some of what systemd has
> been doing with them, and I have an idea for a portage feature.
>
> But before doing a brain dump of ideas, how useful would it be to have
> a FEATURE for portage to do a limited-visibility build? That is, the
> build would be run in an environment where the root filesystem appears
> to contain everything in a DEPEND (including @system currently) and
> nothing else?

I was thinking about something similar too. In my opinion it's a great
feature. If/when there are any bugs to get this implemented, please let
me know.

A possible alternative implementation would be to make the sandbox deny
access to anything outside DEPEND. One totally crazy idea to make that
fast are extended attributes (portage would record which package a file
belongs to when merging the file). Another possible solution is using a
cache.
 
Old 07-31-2012, 02:55 PM
Michael Mol
 
Default Portage FEATURE suggestion - limited-visibility builds

On Tue, Jul 31, 2012 at 10:48 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 7/26/12 8:26 PM, Rich Freeman wrote:
>> I've been messing around with namespaces and some of what systemd has
>> been doing with them, and I have an idea for a portage feature.
>>
>> But before doing a brain dump of ideas, how useful would it be to have
>> a FEATURE for portage to do a limited-visibility build? That is, the
>> build would be run in an environment where the root filesystem appears
>> to contain everything in a DEPEND (including @system currently) and
>> nothing else?
>
> I was thinking about something similar too. In my opinion it's a great
> feature. If/when there are any bugs to get this implemented, please let
> me know.
>
> A possible alternative implementation would be to make the sandbox deny
> access to anything outside DEPEND. One totally crazy idea to make that
> fast are extended attributes (portage would record which package a file
> belongs to when merging the file). Another possible solution is using a
> cache.

We already have the ability to run commands like 'equery b $somefile'
to map a file back to a package, so the data for a filesystem helper
should already be available in whatever database equery is using.

--
:wq
 
Old 07-31-2012, 02:56 PM
Ian Stakenvicius
 
Default Portage FEATURE suggestion - limited-visibility builds

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/07/12 10:55 AM, Michael Mol wrote:
> On Tue, Jul 31, 2012 at 10:48 AM, "Paweł Hajdan, Jr."
> <phajdan.jr@gentoo.org> wrote:
>> On 7/26/12 8:26 PM, Rich Freeman wrote:
>>> I've been messing around with namespaces and some of what
>>> systemd has been doing with them, and I have an idea for a
>>> portage feature.
>>>
>>> But before doing a brain dump of ideas, how useful would it be
>>> to have a FEATURE for portage to do a limited-visibility build?
>>> That is, the build would be run in an environment where the
>>> root filesystem appears to contain everything in a DEPEND
>>> (including @system currently) and nothing else?
>>
>> I was thinking about something similar too. In my opinion it's a
>> great feature. If/when there are any bugs to get this
>> implemented, please let me know.
>>
>> A possible alternative implementation would be to make the
>> sandbox deny access to anything outside DEPEND. One totally crazy
>> idea to make that fast are extended attributes (portage would
>> record which package a file belongs to when merging the file).
>> Another possible solution is using a cache.
>
> We already have the ability to run commands like 'equery b
> $somefile' to map a file back to a package, so the data for a
> filesystem helper should already be available in whatever database
> equery is using.
>

Although that is true, it would be -WAY- too slow to generate said
list via equery/q* helpers; I think that's where the
extended-attributes and/or cache idea comes into play.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAX8jUACgkQ2ugaI38ACPAm8wEAlfvF3KgQi5 ZsH7FbCfALxOn0
hF9Y+vhH8I5Ki0NUbAYA/0uDWlPlx2RIpK8Z7B8E/n//Fuii8ZFppVC440g3djjT
=/xMA
-----END PGP SIGNATURE-----
 
Old 07-31-2012, 07:16 PM
Rich Freeman
 
Default Portage FEATURE suggestion - limited-visibility builds

On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> Although that is true, it would be -WAY- too slow to generate said
> list via equery/q* helpers; I think that's where the
> extended-attributes and/or cache idea comes into play.

I agree. This needs to be high-performance when it comes to
individual file access. If it takes 10 seconds per build to populate
some database or set up a bazillion bind mounts that isn't the end of
the world, but if it takes an extra 0.1 seconds every time a file is
read that could add up VERY fast on a large build.

Ideally I'd like to see the same thing extended to run-time, and short
of writing some entirely new security model into the kernel or taking
namespaces to a whole new level, part of me thinks that
auto-generating SELinux policies might be the solution, so that the
existing mechanism can be extended.

The mad scientist in me keeps thinking up crazy schemes so that
package collisions can be handled by each package just seeing whatever
it wants to see - maybe the entire filesystem looks different
depending on what app you use. Then I realize that bash is an
application, and how on earth would a human make sense of a system
where no file has any stable identifier other than maybe a
content-hashed key. Then that makes me wonder why we link to
libraries by filename anyway, when we could just give each library a
GUID and version, and maybe a more general identifier for cases where
you have alternate implementations.

But, as long as we're still just running Gentoo on Unix-like OSes
maybe tweaking the jail is a good place to start...

Rich
 

Thread Tools




All times are GMT. The time now is 05:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org