- it propagated changes to every non-global zone by default
- it complained about packages dependencies with messages such as:
# /opt/csw/bin/pkg-get -uOne solution to avoid propagating packages to non-global zones would be using the -G pkgadd flag, which Blastwave packages use indirectly, and this can be achieved by setting the ADMINFLAG variable:
## Verifying packagedependencies in zone
## Verifying packagedependencies in zone
The packagedepends on package currently
being removed from zone.
The packagedepends on package currently
being removed from zone.
The packagedepends on package currently
being removed from zone.
The packagedepends on package currently
being removed from zone.
Dependency checking failed for packageon zones .
Do you want to continue with the removal of[y,n,?]
export ADMINFLAG=' -G'Thanks to some suggestion by the LQ guys, I also discovered that, to comply with Solaris/SVR4 standards, Blastwave CSW packages should (but don't) separate configuration files by providing the /var/opt/csw and /etc/opt/csw directories.
The solution I chose was creating a non-global zone to install Blastwave's software and loopback mount /opt/csw in the other zones. I then created a sparse zone and installed all the Blastwave's packages I needed there. The last thing I had to do was loopback mounting the non-global zone's /opt/csw directory into the global zone (to give desktop users access to the software) just adding this line in /etc/vfstab:
/export/home/zones/blastwave/root/opt/csw - /opt/csw lofs - yesBlastwave's packages are now isolated in their zone and management is straightforward via Blastwave's pkg-get command.
No comments:
Post a Comment