A problem upgrading blastwave packages with zones

crisostomo_enrico · 12-21-2007, 10:50 AM

Hi.

I installed some packages in the global zone and later I created two native zones as well. The configuration is a bare sparse zone:

Quote:

zonename: ssh-zone
zonepath: /export/home/zones/ssh-zone
brand: native
autoboot: true
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr

However, I never realized that these two zones inherited some way blastwave packages while I expected they didn't: indeed /opt/csw is there, in the two zones root directory.

Today, running pkg-get -u I got the following errors:

Quote:

# /opt/csw/bin/pkg-get -u
## Verifying package <CSWpython> dependencies in zone <sjsas-zone>
## Verifying package <CSWpython> dependencies in zone <ssh-zone>

The package <CSWbittorrent> depends on package <CSWpython> currently
being removed from zone <sjsas-zone>.

The package <CSWbittorrent> depends on package <CSWpython> currently
being removed from zone <ssh-zone>.

The package <CSWbittorrent> depends on package <CSWpython> currently
being removed from zone <sjsas-zone>.

The package <CSWbittorrent> depends on package <CSWpython> currently
being removed from zone <ssh-zone>.

Dependency checking failed for package <CSWpython> on zones
<sjsas-zone, ssh-zone>.

Do you want to continue with the removal of <CSWpython> [y,n,?]

Why did this happen? What should I do then?

jlliagre · 12-21-2007, 01:56 PM

At their creation, zones inherit all packages already installed in the global zone. You can limit new package installation to the global zone by using the -G pkgadd flag.

I've read that this can be done with the ADMINFLAG variable:

Code:

export ADMINFLAG=" -G"

crisostomo_enrico · 12-21-2007, 04:28 PM

I didn't know that inheriting packages would imply copying packages installed in /opt, I thought that in sparse zones only lib, platform, sbin and usr would be used from root zones and other packages ignored.

I'll investigate about the environment variable you told me, thanks.

By the way, how do you explain then pkg-get behaviour? Why can it upgrade packages in the global zone but cannot do it in the other zones? Installed packages are the same!

jlliagre · 12-22-2007, 07:23 AM

Quote:

Originally Posted by crisostomo_enrico

I didn't know that inheriting packages would imply copying packages installed in /opt, I thought that in sparse zones only lib, platform, sbin and usr would be used from root zones and other packages ignored.

Don't confuse directories and packages. Package files can spread many directories. The lib, platform and so on directories are lofs mounted instead of copied in the case of sparse zones, but most packages, outside those specifically to be excluded by design (see http://docs.sun.com/app/docs/doc/817...hahuosk?a=view for details), are propagated to all zones zone.

Quote:

By the way, how do you explain then pkg-get behaviour?

Something might be broken in the CSWpython package dependency.

Quote:

Why can it upgrade packages in the global zone but cannot do it in the other zones? Installed packages are the same!

What happens if you let the installer continue ?

crisostomo_enrico · 12-22-2007, 09:39 AM

Thanks jlliagre.

If I let the script go on, it removes the python package from all the zones, then it seems to install another one, then informs me of another such problem for another package:

Quote:

The package <CSWlibcairo> depends on package <CSWpng> currently being
removed from zone <sjsas-zone>.

The package <CSWlibcups> depends on package <CSWpng> currently being
removed from zone <sjsas-zone>.

The package <CSWpango> depends on package <CSWpng> currently being
removed from zone <sjsas-zone>.

The package <CSWgtk2> depends on package <CSWpng> currently being
removed from zone <sjsas-zone>.

The package <CSWsdlimage> depends on package <CSWpng> currently being
removed from zone <sjsas-zone>.

The package <CSWarts> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWvlc> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWimlib2> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWgdkpixbuf> depends on package <CSWpng> currently
being removed from zone <ssh-zone>.

The package <CSWlibxine> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWxineui> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWlibcairo> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWlibcups> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWpango> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWgtk2> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

The package <CSWsdlimage> depends on package <CSWpng> currently being
removed from zone <ssh-zone>.

Dependency checking failed for package <CSWpng> on zones <sjsas-zone,
ssh-zone>.

Do you want to continue with the removal of <CSWpng> [y,n,?]

I'll follow on until the end and let's see if the installed packages will work. What's strange to me is that pkg-get -u informs about broken dependencies in zone, but not in the global zone and it should be performing the same operation in all the zones!

jlliagre · 12-22-2007, 09:57 AM

I guess a better approach would be to install Blastwave's packages on a non global zone, and possibly to share its /opt/csw to other ones.

One issue is that csw packages do not separate configuration directories from the rest. There should have been /var/opt/csw and /etc/opt/csw to comply with Solaris/SVR4 standards.

crisostomo_enrico · 12-26-2007, 02:27 AM

Quote:

I guess a better approach would be to install Blastwave's packages on a non global zone, and possibly to share its /opt/csw to other ones.

Thanks for the suggestion jlliagre, it indeed seems the best option I have. I'll migrate the few users I have in the global zone!

I suppose it's safe, then, to do this. Would you then directly loopback mount the non global zone's /opt dir in the other zones?

Quote:

One issue is that csw packages do not separate configuration directories from the rest. There should have been /var/opt/csw and /etc/opt/csw to comply with Solaris/SVR4 standards.

Thanks for pointing out this.

Thanks and happy new year.
Enrico

jlliagre · 12-26-2007, 12:26 PM

Quote:

Originally Posted by crisostomo_enrico

I'll migrate the few users I have in the global zone!

I suppose it's safe, then, to do this.

The best practice would probably be to keep the global zone for administrative tasks and to have end users (outside you) only in non global zones. Of course this is tricky to implement if your users log in graphically on the machine itself.

Quote:

Would you then directly loopback mount the non global zone's /opt dir in the other zones?

Not the whole opt, just /opt/csw. And as I wrote, the fact blastwave's is mixing global and local files in a single directory imply you need to have it mounted read-write.

Quote:

Thanks and happy new year.

Thanks, but you are one week early ...

crisostomo_enrico · 12-26-2007, 02:31 PM

Thanks jlliagre.

Quote:

The best practice would probably be to keep the global zone for administrative tasks and to have end users (outside you) only in non global zones. Of course this is tricky to implement if your users log in graphically on the machine itself.

Yes, I got the idea. Indeed, I once posted because I have one user which logs on the machine itself and I had a problem which I described here http://www.linuxquestions.org/questi...a-zone-597976/
and unfortunately I never solved. I should try and check it another time.

Quote:

Not the whole opt, just /opt/csw. And as I wrote, the fact blastwave's is mixing global and local files in a single directory imply you need to have it mounted read-write.

Thanks, I indeed meant /opt/csw. Yes, I don't like it either.

Quote:

Thanks, but you are one week early ...

Yes it's true but as I'm traveling and I'll fly back home on that date, I didn't want to be too late...

Bye,
Enrico.