Bug #8288

Sun package provider should include '-G' flag to pkgadd on install

Added by eric sorenson 11 months ago. Updated 4 months ago.

Status:Accepted Start date:07/07/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:Solaris
Target version:2.7.x
Affected Puppet version: Branch:
Keywords:
Votes: 0

Description

One of our teams ran into trouble using the sun package provider on zoned hosts. Without the ‘-G’ flag, when run on a global zone, pkgadd attempts to install into all non-global zones, which isn’t right if the non-global zones also run puppet. According to the man page:

     -G

         Add package(s) in the current zone only.  When  used  in
         the global zone, the package is added to the global zone
         only and is not propagated to any  existing  or  yet-to-
         be-created  non-global  zone.  When used in a non-global
         zone, the package(s) are added to  the  non-global  zone
         only.

Locally I forked provider/package/sun.rb and made a one-line change to its ‘install’ method, please consider taking this upstream


125c125
<         cmd = []
---
>         cmd = ["-G"]

History

#1
Updated by James Turnbull 9 months ago

  • Category set to Solaris
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Michael Stahnke

Mike – any views?

#2
Updated by Jeff McCune 9 months ago

+1 to -G from me.

Ideally, it would be a parameter that defaults to the behavior of installing to the current zone only if left unspecified.

#3
Updated by Daniel Pittman 8 months ago

  • Target version set to 2.7.x

Mike, Jeff, this looks like correct behaviour, but I am concerned: as far as I know zones are a fairly recent Solaris feature, and we support anything from Solaris 7 upwards. Is it safe to apply this universally, or are we going to have to make it conditional on the Solaris version? When did it start being supported?

Additionally, are “zones” a feature you can disable? If so, does that alter the behaviour of the package provider combined with this option? (eg: will it fail if zones are disabled, and I invoke with it?)

#4
Updated by Bill Proud 8 months ago

Solaris zones are not really a new feature – they are a core feature of Solaris 10 (first released in 2005).

Zones cannot be disabled. Even if you do not create any zones the OS runs in a global zone. So the -G option is always valid but without a non-global zone it will have no meaning.

I would prefer this to be a parameter but I’m not sure if I can summon up a really good argument.

#5
Updated by Bill Proud 8 months ago

Sorry, it occurs to me that my comment could have been clearer. The -G option does not exist prior to Solaris 10 and therefore you would indeed have to check the OS version.

#6
Updated by James Turnbull 7 months ago

  • Assignee changed from Michael Stahnke to Daniel Pittman

#7
Updated by Daniel Pittman 5 months ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Daniel Pittman)

#8
Updated by Bill Proud 5 months ago

Hi,

I now realise that there are a couple of complications with this bug:

  • Packages with the parameter SUNW_PKG_ALLZONES set to true must be installed in the global zone and are automatically installed in all of the non-global zones. The installation of such a package will fail if the “-G” option is used or if an installation is attempted in a non-global zone. Mostly this isn’t an issue as these packages will almost always be from the Solaris distribution and therefore probably installed in the initial server build. You can check for this parameter with “pkgparam SUNW_PKG_ALLZONES”, for instance “pkgparam SUNWaccr SUNW_PKG_ALLZONES” returns true – incidentally this is a good example of a package that might not have been included in the server installation and therefore might need to be added by puppet.

  • Packages that include files located in shared filesystems cannot be installed in sparse non-global zones – they can only be installed in the non-global zones by installing them in the global zone without the “-G” option. If you are not familiar with the distinction between a whole root and a sparse root zone, the latter is configured so that some directory trees in the global zone are mounted as read-only loopback filesystems in the non-global zone.

Handling the above exceptions is probably too much for this bug so it would be enough for this feature to be an option. But the point is that, unlike what I first thought, it really has to be a parameter and not hardcoded into the provider.

#9
Updated by Daniel Pittman 5 months ago

Bill Proud wrote:

I now realise that there are a couple of complications with this bug:

  • Packages with the parameter SUNW_PKG_ALLZONES set to true must be installed in the global zone and are automatically installed in all of the non-global zones. The installation of such a package will fail if the “-G” option is used or if an installation is attempted in a non-global zone. Mostly this isn’t an issue as these packages will almost always be from the Solaris distribution and therefore probably installed in the initial server build. You can check for this parameter with “pkgparam SUNW_PKG_ALLZONES”, for instance “pkgparam SUNWaccr SUNW_PKG_ALLZONES” returns true – incidentally this is a good example of a package that might not have been included in the server installation and therefore might need to be added by puppet.

  • Packages that include files located in shared filesystems cannot be installed in sparse non-global zones – they can only be installed in the non-global zones by installing them in the global zone without the “-G” option. If you are not familiar with the distinction between a whole root and a sparse root zone, the latter is configured so that some directory trees in the global zone are mounted as read-only loopback filesystems in the non-global zone.

Handling the above exceptions is probably too much for this bug so it would be enough for this feature to be an option. But the point is that, unlike what I first thought, it really has to be a parameter and not hardcoded into the provider.

OK. Thanks for the update; one of the biggest constraints from our point of view is going to be testing. Specifically, that getting infrastructure in place to test all this is going to require a whole bunch of time and money investment getting the scope mapped and the machines and zones configured. It is certainly not low priority, but that does put some time constraints on this – especially since we don’t want to break existing machines when we do change.

#10
Updated by Bill Proud 4 months ago

If it helps, my company would be quite happy to install and give you access to a Solaris 10 VM (also a Solaris 11 VM for that matter). And I’ll do whatever configuration you require.

Contact me on my company email address if you want to take me up on this.

Also available in: Atom PDF