support external usr/portage

[globalcitizen]

should be possible to avoid duplicating usr/portage contents in to container

[globalcitizen]

Someone helpful @ http://en.gentoo-wiki.com/wiki/LXC#Option:_Shared_.2Fusr.2Fportage.2Fdistfiles reports "If you want to share distfiles from your host, you can set the PORTAGE_RO_DISTDIRS variable to a space-separated list of directories to search. Portage will create a symlink in DISTDIR to the first matching file found in PORTAGE_RO_DISTDIRS if the file does not already exist in DISTDIR."

[hujuice]

Simply add this kind of line to your configuration: lxc.mount.entry=/usr/portage /path/to/your/virtualmachine/usr/portage reiserfs bind 0 0

[globalcitizen]

Your solution is different to the above, and requires more disk space due to redundant storage of the portage distfiles. On the plus side, it's closer to what people expect and are used to. A negative is that it requires an additional mount.

[PoPoutdoor]

To make this works, you have to:

1. Set bind mount hosts' portage/distfiles in guest config file
2. create mount point for (1) above in guest
3. set PORTAGE_RO_DISTDIRS to (2) above in guest make.conf
4. create mount point ${PORTAGE_RO_DISTDIRS} as set in (3) above
5. set DISTDIR in guest make.conf if you are not using default value

Try emerge -f any_new/package in guest, symlink will be created in guest's ${DISTDIR} if file exist in hosts' distfiles.

[globalcitizen]

Glad this has been tested. I have not spent time implementing this in the past because it leaks host information to the guest (packages installed/upgraded, frequency and timing of admin login, etc.). However, in some situations it makes a lot of sense.

[globalcitizen]

I have tried this out and am not seeing the contents appearing within the container. There appears to be some notes at http://osdir.com/ml/lxc-chroot-linux-containers/2012-02/msg00018.html about this issue (bind mounts don't work). Resolution under investigation.

[PoPoutdoor]

Just check, my setup still working.

1. /etc/lxc/${LXC_SVR}.conf

Add

lxc.mount.entry = /usr/portage /path-to-${LXC_SVR}/usr/portage none bind 0 0 lxc.mount.entry = /usr/portage/distfiles /path-to-${LXC_SVR}/usr/portage/distfiles none bind 0 0

1. login to ${LXC_SVR}

   edit /etc/portage/make.conf

   add PORTAGE_RO_DISTDIRS="/usr/portage/distfiles" modifies DISTDIR="/usr/portage/${lxc_distdir}"

   save and logout

2. create DISTDIR on host

   mkdir /usr/portage/${lxc_distdir}

3. logout and restart ${LXC_SVR}

*note: I have /usr/portage, /usr/portage/distfiles in 2 lvm partition.

[specing]

In what way should this be implemented? I am currently bind mounting my host portage tree read-only.

So if the host is Gentoo itself we only grep PORTDIR form config files and bind mount accordingly.

What if the host is not Gentoo?

Do we just unpack the entire ~700MB tree with 170000!!!! files into /var/cache/lxc/...? If so, how do we update it if all VMs only have read-only mounts? do we maintain a seperate rsync update functionality?

I currently have the portage tree inside a ~60 MB SquashFS image, should we support that, too?

Having the tree bind mounted would mean the VM wouldn't be able to downloads distfiles into it. Should we ship a minimal Portage configuration that puts files at the following places: /var/portage/tree - read-only bind mount /var/portage/distfiles - read-write mount shared by ALL Gentoo VMs

• I think this is safe because packages are checked by a slew of hashes.

[globalcitizen]

I think rather than expanding the script's capacity we should look at finding the easiest routes to well-defined inputs. This is in the spirit of "do one thing and do it well". Right now we've just added support for custom stage3 tarballs.

In the same spirit, custom mounts might be a better area to aim for than magic kernel feature dependent what-if configurations that are specific to gentoo's portage tree. However, your SquashFS tree does sound pretty cool, particularly if the write area (${portage_root}/distfiles) is separately mounted to remove any write requirement.

How about this solution: maybe you could provide an extra script that can execute as cronjob to create, download, and then periodically sync the portage tree to an arbitrary location and/or loopback-mounted filesystem of choice? That way the extra mount parameter could be added to lxc-gentoo and it would be insulated from any of the potentially complex related configuration choices.

Some script like: gentoo-portage-treesync /path/to/dir

If the script detects that the passed path is a filesystem image (eg. with file) then it can attempt to mount it in a predefined temporary location prior to executing a sync.

If the path doesn't exist but the parent path exists, it could create the path if an extra argument is provided, which specifies the image type to create (eg. gentoo-portage-treesync create <files|squashfs|tmpfs|...> /path/to/dir). Just brainstorming.

With regards to the security question, if the host is compromised then the guest can't do anything about it. However, it is important not to share the host's tree or share a writeable tree between guests as this will either leak host information to the guests or allow bad guests to compromise other guests, respectively.

[globalcitizen]

Further thought - filesystem specification could potentially be checked against /proc/filesystems to achieve open support. Some kind of additional mkfs.${FILESYSTEM} argument passing methodology could potentially be included, perhaps as an environment variable.

[specing]

My script is here, supports both aufs (autodetect) and rsync/tmpfs fallback https://github.com/specing/utils/blob/master/ptree-update though it depends on emerge and currently isn't flexible enaugh to be used all over the place.

[globalcitizen]

Hrrm, I was thinking we could include a tool in the lxc-gentoo repository... but depending on emerge is no good, we'd need to support other Linux distributions for the host environment.