Tips for sharing /opt/csw across machines or zones

We strive to make our packages friendly to both individual, inexperienced users, and also large scale experienced admins. This page is geared towards the latter group. The comments on this page are targetted towards sharing /opt/csw read-only between multiple machines, or between zones.We recognize the usefulness of having a single install of CSW packages across all (or at least “many”) of the machines at a particular site. Usually in this kind of situation, /opt/csw would be NFS-shared read-only, and mounted onto /opt/csw on client machines, with identical configurations everywhere.

Somewhat similar to the NFS sharing model, is the example of sharing /opt/csw across multiple zones on the same machine.

Zone tips

Important: Use inherit-pkg-dir for /opt/csw

If you choose to do your package management from the global zone, rather than individually to each zone, then the simplest strategy is to have all desired zones “inherit” them from the global zone (define /opt/csw as type inherit-pkg-dir in the zone configs). This has the very definate advantage, of having preinstall/postinstall scripts and class actions being automatically applied in each zone, and is the recommended deployment method.

This strategy is our only “fully supported” configuration for zones getting CSW packages from the global zone(rather than locally installed). Most of our packages should support configuration files in the local /etc/opt/csw directory, when configuration local to each zone is needed. If one does not, please file a bug against it.

If you forget to use inherit-pkg-dir on /opt/csw, things will still 99% work for you. However, there are some edge cases where things will fail. (For example, our BugID 4538 ). So please use it.

Special case cswclassutils: Do be aware that if you do not follow the above configuration, and keep your zone installations of CSW packages separate from your global zones (that is, doing pkgadd at a NON-global level), you will have to be careful what you do reguarding the special package CSWcswclassutils. It is unique in our packages, in that for security reasons, it delivers some files to /usr.  Make sure that the global zone always has the most up to date version of it before looking at non-global zones.  Otherwise, pkgutil may attempt to update that package in a non-global sparse zone, but fail due to lack of permissions.

If your special zones are not sparse-root zones, this is not an issue.

Special zone master: Some people do not like having extra packages in their global zone. For those people, it may be of interest to define one zone as the “master” for opencsw package installs, and then having other zones share the /opt/csw filesystem as a loopback mount.
The Disadvantage to having a “special zone master” for /opt/csw, is basically the same as having a shared read-only NFS /opt/csw. You will have to pay attention to any preinstall and postinstall scripts that may run on that special zone, and then manually apply them to all your other related zones if needed.

“Creative” options

Generally speaking, we would recommend that individual machines have their own individual /opt/csw. However, recognising that this is not always possible, we offer the following suggestions to make it seems more like packages are locally installed, even on a “shared-/opt/csw” configuration.

Local /opt/csw/etc and /opt/csw/var(for legacy packages only)

Note that we strive to have our packages not write to /opt/csw/var any more; unfortunately, some older packages might still do this. please file a bug against any that do this.In contrast, use of /opt/csw/etc as a configuration file location is a design choice by the packager. In theory, if it is judged that in the majority of cases, a “globally consistant configuration” is most beneficial, a package may be configured to look in /opt/csw/etc rather than the always-local /etc/opt/csw directory. You may actually agree with this in general, yet have one or two machines that you wish to make exceptions of.

A brute force method to make a machine with local configurations, while still shared /opt/csw, would be to make local writable /opt/csw/etc and /opt/csw/var(this location is deprecated) filesystems, “on top of” the shared read-only /opt/csw filesystem.

Adding the following lines to /etc/vfstab would accomplish this (adjust as needed)

# /etc/vfstab entries
/local/etc - /opt/csw/etc lofs - yes -
/local/var - /opt/csw/var lofs - yes -

Individual config redirection, for individual packages

Sometimes, you want MOST things to be the same everywhere, but just a few things different. There are a few potential strategies for this.

Some packages and programs directly support looking in /etc/opt/csw first. In this case, you can directly override it by just creating the config file you want, in the local /etc/opt/csw directory, on specific machines. This allows for a particular program to usually have a particular shared config file in /opt/csw/etc, but have host-specific overrides where needed.

In other cases, if you wish a particular program will ALWAYS have a machine-local configuration, even though it is normally configured to look in /opt/csw/etc for configurations, you can make a soft link on the NFS server,
/opt/csw/etc/file.conf -> /etc/opt/csw/file.conf

Written by Philip Brown