When I first installed Blastwave software on Solaris 10 or Solaris Express, I just installed it on the global zone. I soon realized that this decision would cause some problems. Blastwave packages were replicated in every Solaris zone I created and, letting aside the waste of disk space, the process of upgrading Blastwave's packages was painful because:
- 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.
0 komentar:
Posting Komentar