DragonFly kernel List (threaded) for 2004-03
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Unionfs etc Re: Packaging
Matthew Dillon wrote:
:# mkdir /tmp/a
:# mount_union /tmp/a /usr/local
:
:works fine and if I create a file in /usr/local it gets "really"
:created in /tmp and is only visible there after umounting /usr/local
:-- just what I wanted. However,
:
:# mount_union /tmp/a /
:says
:mount_union: /tmp/a (/usr/tmp/a) and / (/) are not distinct paths
:
:Is there a way around this? I ask because I'd rather not assume
:anything about PREFIX, and I'd like this to be usable for
:badly-behaved installers that put stuff into other places like /etc,
Well, /tmp/a on top of / creates a recursion within unionfs, which is
why it is not allowed. Actually, the more interesting mount is:
mount_union -b / /tmp/a
Which would create an image of the entire filesystem in /tmp/a, suitable
for chroot'ing into /tmp/a. But this is not currently allowed either.
If you (or someone) would like to fix this, I think it's a fairly simple
matter to have unionfs detect the recursion (e.g. /tmp/a/tmp/a) and
disallow access to it.
This would make unionfs a *very* powerful tool.
(lurk mode off)
Well, I have no right to say anything at this point, but this discussion
lies close to my heart so I might add some of the things I've been
thinking about.
I was hoping to write up an organized and critiqued summary of my
thoughts.... but it hasn't happened in the last two weeks so I see no
reason it will happen in the next two. So... this is messy and
full-of-holes.
Ever since I've been using FreeBSD I've been intrigued by the potential
of jails and union mounts. And I've been perplexed by the
schizophrenic directory layout: eg
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
and it is worse for configuration files.
I would like to set up virtual machines via union mounts and jails, such
that inside each machine you have precisely the programs, libraries,
config files that you need. And nothing else.
I want to have no doubts about where in the directory tree something
can/should be found.
That is... libraries are in /lib, config files in /etc, and so on.
I think that as much of the base install as possible should be relocated
to the ports/packages system.
I imagine that building a package would involve:
Creating a jailed process on top of a multi-layered union mount
- top level is empty (to begin) .
path in the base system might be:
/pkg/<name>-<version>-<port_rev>-<ENV?>
- next level has source and makefiles, etc for the port.
path in the base system might be:
/src/<name>-....
- lower levels get dependencies mounted as appropriate.
path in the base system might be:
/pkg/<dep-name>-....
If the port has dependencies, need to request the base-system to
mount the dependencies on lower layers, possibly building them
first.
Build the package. Hmmm, maybe the top level shouldn't be
mounted until after this stage.
Install the package. PREFIX=/
Now every thing gets installed in /bin /sbin /lib /etc. Yay.
In the base-system they appear under /pkg/<name>-..../bin
and so on.
Now all packages are ready to be union mounted into
our virtual machine. Yay.
The above process is still too simplistic (as well as being
full-of-holes) becos we would sometimes want only the libraries from a
package in our virtual machine.
A virtual machine is now a jail on top of a multi-layered union mount.
Top level is empty (to begin)
path in base-system might be:
/jails/<hostname>
Lower layers are from the /pkg/<name>-.... tree as desired
Configuration changes happen in /etc of the top layer,
and affect this VM only (can't even be accessed by other VMs).
Command line options to set a special location for config file
lose their relavence. World peace ensues.
I suspect that the root of the base-system should be static binaries
(maybe in a boot-time loaded mfs) and that everything else can (should?)
be dynamically linked.
Okay. A bit of a dog's breakfast, I know.
I'm a big believer in "the proof of the pudding..." so if it is too hard
to understand without some sort of prototype implementation (or if it is
all just a piece of crap) then it is probably not worth responding...
It probably requires a lot of attention to union mount and other VFS
voodoo. It might be slow or resource intensive... my gut-feeling is
otherwise but I have no basis for this.
Anyway... it's said.
cheers,
SDH
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]