On Tue, Jul 15, 2008 at 11:46, Jordan Brown <[EMAIL PROTECTED]> wrote:
> Before diving too far down this rathole... aren't the package scripts
> run in the context of the zone?
I did some testing with this, and it appears that the postinstall
scripts aren't being run in the right context when the packages are
installed!  Specifically, our cfengine package runs "cfkey" if a
particular file doesn't exist, and creates it.  That doesn't happen
when a zone is installed.  But if I remove and then re-add the package
(from the same source) it works properly.  To show the difference,
here's output from execsnoop -Z when the zone is installed:
global         0   8174   8173 /sbin/sh
and when the package is reinstalled:
cfengine       0   8348   8342 /sbin/sh
ypmaster       0   8359   8353 /sbin/sh
mail           0   8371   8364 /sbin/sh

DTrace shows the postinstall scripts executing, and files being
opened.  I have opensnoop -Z and execsnoop -Z logs for an entire zone
install if anyone's interested.

On Mon, Jul 14, 2008 at 20:22, Ralf Weber <[EMAIL PROTECTED]> wrote:
> Well Solaris installs and packages, especially package scripts can not
> rely on the fact that the install root = /, it can e.g /a with jumpstart
> or your zone path when the package gets created inside a zone. So I
> would rewrite your scripts as:
When I checked this with zones, I saw that $BASEDIR is set to
$zoneroot when installing to zones initially, but when packages are
installed later, they are run in the context of the zone with
$BASEDIR=/ and a different zone name (in e.g. uname output).  Is there
a reason for this discrepancy?

> Try this and tell me if you still
> have problems.
I've tried several things to resolve this and haven't found any way that works.

If I specify SUNW packages that include the requirements to chroot as
dependencies of my packages, will chrooting in my postinstall scripts
be safe?

zones-discuss mailing list

Reply via email to