Edward Pilatowicz wrote:
> hm.  from what i remember mount mode actually puts the zone root at
> <zoneroot>/a and lofs mounts stuff from the global zone at <zoneroot>,
> all so that the svr4 packaging code can "enter" the zone to do packaging
> operations.  i thought this dance was necessary because we wanted packaging
> scripts to execute inside a zone (since for security reasons, we wouldn
> t want them to be able to muck with stuff outside a zone).  but IPS doesn't
> have packaging scripts.  so will this complicated setup really be necessary
> for IPS?  ie, could we do away with the /a mount in mount mode for IPS?
> 
> i'm asking about this because the /a mount code in zoneadmd has lots of hard
> coded paths and makes zoneadmd pretty complicated.  (just look at
> mount_filesystems() and build_mounted_post_var().)  i've had to modify this
> code a few times, i've broken it a couple times, and been confused by it all
> the time...

Ed,

Yes, this description is correct but not because of the pkging
code.  We want to be able to enter the zone while running the
sw that is installed in the global zone, irrespective of what is
inside the non-global zone.  All of the global zone sw is mounted
read-only in a mounted zone so we can login into the zone and
have a safe environment that matches the global zone.  The non-global
zone is mounted under /a so we can safely operate on it within the zone
using the global zones sw.  None of this has any relationship to
the pkging code in either zone.  All the mount is doing is setting
up a safe zone that is compatible with the global zone.  With this
definition, you can use mount to safely do any kind of admin work,
not just running pkging code.  The problem with the current mount
is it lofs mounts the zone's etc and var back into the global zone
mount area.  This obviously won't work for non-native zones or even
older zones that we are migrating to the new host, which is why I
had to fix this for update on attach.

Jerry

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to