3

I have a Solaris 11.3 system without (presently) a support contract. I am therefore using the IPS repository at http://pkg.oracle.com/solaris/release/, which I have now mirrored locally using pkgrecv.

I am using pkg change-facet to change version-lock to false on a large number of packages, such that I can update these packages to their latest version. This works fine.

The 'issue' is that these changed facets are not being inherited by my non-global zones. So while in the global zone I see the changed facet, and can upgrade the affected packages, the same is not true in any non-global zone I later create: it shows the original, unchanged facet, and cannot upgrade the affected packages.

pkg(5) indicates that changes to facets are inherited by child images, such as a non-global zone inheriting from a global zone. But this is not happening for me.

Initially I thought this was a problem, but after further reflection I've realised that in fact I probably wouldn't want facet changes in the global to always inherit into non-globals. This was proved to me when shortly afterwards I found I wanted to install test zones with base software, without changing these facets.

Nonetheless, I'm still confused by the documentation indicating they do inherit, and I believe that ideally there should be a way to configure certain facets to inherit.

Therefore, my questions are:

  1. Is there a way to optionally make certain facets inherit into all non-globals - perhaps by creating a new IPS image?
  2. Why does the IPS documentation indicate facets do inherit - is it talking about only certain types of facets?

This is what I am doing in full:

I have been investigating the use of the new FOSS packages that Oracle provides. I have been following the guide here: How to access selected FOSS Evaluation packages for Oracle Solaris 11.3.

This guide explains that it is necessary to change the facet version-lock to false before packages can be updated, and that updated FOSS packages can be found in bulk in the Release repo with a version number string matching \*@\*-5.12.0.0.0.122. The document recommends manipulating the output of pkg list to create pkg change-facet commands to unlock all versions.

I have done this in my global zone, and subsequently doing pkg update --accept successfully results in a large number of upgraded packages.

But if I then install a new non-global zone, it will default to the base version for these packages. If in that global zone I run pkg facet, I will see the facets are unchanged in the zone. For example, here a zone shows the unchanged version-lock=True for Bash:

root@goldenzone:~# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          True  system

Whereas its global shows the correct, newly changed version-lock=False:

root@magrathea:/system/zones# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          False local

Workaround:

As per my comment below, I am now solving this issue by installing my golden zone with custom auto_install manifest that includes <facet set="false">facet.version-lock.*</facet>.

This works OK (albeit at the cost of unlocking all version locks, rather than only those that have FOSS updates), but it would still be good to know if there is a way to make facets inherit between globals and non-globals, as the documentation seems to indicate they should.

Thanks in advance.

TheBloke
  • 65
  • 6
  • For now I am using the following workaround: I am creating my zones using a custom manifest, which contains the following: `facet.version-lock.*` in the .. section. This works, causing the zone to use the latest FOSS packages on install. I still don't get why the facet changes don't automatically inherit, but this is an acceptable workaround for now (albeit I am removing _all_ version locks, not only those that have FOSS updates, and I don't yet know if there might be later implications from that) – TheBloke Jun 04 '17 at 00:05

1 Answers1

1

I'm one of the primary authors and designers of the Image Packaging System.

I imagine your confusion is due to a misunderstanding of what the documentation states. In particular, note carefully what this sentence from pkg(5) says:

...a non-global zone can inherit a facet from the global zone. Inherited facets are evaluated before, and take priority over, any locally set facets.

Note it says can, not will. So the documentation describes what will happen when facets are inherited, but intentionally (I believe) does not state when they will be inherited. That is, it tells you how to determine whether they are inherited (by looking for "parent" in the SRC column of "pkg facet"), but not under which conditions they will be inherited:

https://docs.oracle.com/cd/E53394_01/html/E54739/glmke.html

Now for the missing part -- in general, inherited facets only usually apply to facet.version-lock.* facets used in packages, because some of the related packages have parent dependencies on themselves like this:

depend type=parent fmri=feature/package/dependency/self

A parent dependency, expressed as above, simply states that to install this package in a non-global zone, the same package must be present at the same version in the global zone first. This is used for packages that must be in-sync between the global and non-global zone(s).

In short, inheritance doesn't usually apply to most facets. The logic for determining which facets will be inherited can be found here:

https://github.com/oracle/solaris-ips/blob/master/src/modules/client/linkedimage/common.py#L3462

This was intentional because zones are a container technology intended to allow isolated environments where administrators can setup configurations that differ from the global zone.

Now with that said, if you want to apply a change-facet operation to the global zone and all non-global zones, you can do so by using the '-r' (recursive) option to change-facet:

pkg change-facet -r ...

(See pkg(1), as apparently I can't post more than two links.)

You can even apply it to specific zones using -z.

Oh, and finally, you really don't want to set the facets to False for all version-locks. Not only will that make the system incredibly slow to update, but you lose all of the safeties that make sure you're actually using a tested combination of components.

Shawn Walker-Salas
  • 81
  • 3
  • Shawn, thanks so much for the very detailed answer - and it's great to know I'm hearing it from one of the original authorities! That all makes sense. Yeah I realised shortly afterwards that always inheriting would definitely be undesirable, but was confused by my misunderstanding of the docs, as you said. – TheBloke Jun 09 '17 at 14:51
  • One final question then: is there then no way to specify a facet change will apply to new non-globals? pkg -r will apply it to all non-globals that exist now, but presumably if I later install a new non-global, it will not apply there? So there's no way to say "this facet should always apply to any subsequently created non-global" - I must simply keep applying it to any newly created non-globals, eg with an AI manifest, or perhaps a new IPS package I create to gather those facet changes and then add to the installation of any subsequent zones? Thanks again. – TheBloke Jun 09 '17 at 14:52
  • And finally, thanks for the warning on version-lock.*. I was a bit worried about that. I suppose I should work on a facet.version-lock list that applies only to the FOSS packages I actually plan to install, and maybe make a new IPS package to gather those changes which I ensure is installed in each zone on install, at the same time as the base OS. – TheBloke Jun 09 '17 at 14:55
  • At this time, the only way to specify configuration that applies to a new zones is through a custom AI manifest. That's probably how it will remain as well, since AI is what is used for the deployment and provisioning of zones. Currently, there's intentionally no way to apply facets/variants/mediators via a package as there are a variety of complex interface issues that are unresolved (e.g. configuration paradoxes where a variant must be set to install a package that also changes it). – Shawn Walker-Salas Jun 10 '17 at 17:29
  • Your best option for now is to indeed specify only the version-lock facets you need in the AI manifest. I apologise for the difficulty you are encountering; the evaluation packages were primarily intended for use with a supported release of Solaris so is even more challenging for use with the base update release found in the /release repository. I will look into what we can do to make this simpler. – Shawn Walker-Salas Jun 10 '17 at 17:31
  • Thanks very much again Shawn. Don't worry at all, I'm quite used to treading an unbeaten path into unsupported configurations! And I realise that not having a support contract makes things harder. I'm looking into getting one if/when I can afford it (the server is not yet making me any money.) I'll forever be sad that Sun died and Solaris was locked away, but I'm also very grateful that you and many others have continued working on it, continuing the ground-breaking work that makes it the best server OS by a mile. And especially grateful to you for all this off-the-clock help. Thanks again! – TheBloke Jun 10 '17 at 21:02