On Fri, Mar 21, 2008 at 6:22 PM, Ethan Quach <Ethan.Quach at sun.com> wrote:
> Definition
> ----------
> The /var/share directory will be defined as the directory where
> data that could be shared across multiple instances of Solaris on
> the same host should be placed. The multiple instances of Solaris
> may have different versions of Solaris software installed.
The way I have envisioned this, only one active instance of Solaris
may write to /var/share at a time. That is, a system with 3
non-global zones will have 4 instances of /var/share (1 global zone, 3
non-global zones). If Snap Upgrade is used to create a new instance
of each of those Solaris instances (assuming one calls a non-global
zone an instance) there would be still be 4 instances of /var/share.
When the upgraded instances are booted, they will use the same
/var/share instances that the pre-upgrade environment used.
> - /var/share may not contain any pkg registered static files.
> Editable files are okay.
filesystem(5) says:
/var
Root of a subtree for varying files. Varying files are
files that are unique to a machine but that can grow to
an arbitrary (that is, variable) size. An example is a
log file. An approved installation location for bundled
Solaris software. The analogous location for add-on sys-
tem software or for applications is
/var/opt/packagename.
prototype(4) says:
ftype A one-character field that indicates the file
type. Valid values are:
. . .
e a file to be edited upon installation or
removal (may be shared by several packages)
. . .
v volatile file (one whose contents are
expected to change, like a log file)
. . .
According to filesystem(5) editable files do not belong in /var and by
extension, /var/share. Any package that delivers editable files in
/var is violating the Solaris file system hierarchy standard. Perhaps
you mean that volatile files may be delivered under /var/share?
<rant>/var/svc/manifest/*/*.xml are of type f and as such belong in
/usr or maybe /etc (but then should be type e)</rant>.
> - Pkg registered directories under /var/share should be only one
> level deep.
>
> For example,
> /var/share/mail
> /var/share/mqueue
> /var/share/stuff
Is there some magic that you intend to do later that makes this
necessary? This would seem to suggest that /var/spool/lp or similar
schemes would need some major re-work that would eventually lead to
hundreds of directories in /var/share.
> Because of the single level of pkg registered directories under
> /var/share, any structure or directory organization that an
> application might want to deliver to /var/share must be delivered
> elsewhere and create symlinks into /var/share for each directory
> that needs to be shared.
I fail to see the value with this. My thoughts were to encourage
packages to put volatile data that should be shared in a subdirectory
of /var/share. In my initial suggestion and examples, symbolic links
were there only for legacy compatibility.
>
> For example, an application cannot deliver this in their package:
>
> /var/share/app/logsA
> /var/share/app/dir1/logsB/
> /var/share/app/dir2/logsC/
>
> Instead, the application must deliver this directory structure
> elsewhere on the system, and deliver single level directories in
> /var/share for the directories that need to be shared, and create
> symlinks to them:
>
> /var/app/logsA/ -> ../share/logsA/
> /var/app/dir1/logsB/ -> ../../share/logsB/
> /var/app/dir2/logsC/ -> ../../share/logsC/
> /var/share/logsA/
> /var/share/logsB/
> /var/share/logsC/
filesystem(5) and I think the Application Packaging Developer's Guide
(or whatever it has morphed into) suggest the right way to do things
is:
/var/opt/MYCOwebserver/htdocs
/var/opt/MYCOwebserver/log
/var/opt/MYCOappserver/log
/var/opt/MYCOappserver/...
If /var/share/log already exists, the web and app server logs get
intermingled with, and possibly conflict with, logs delivered as part
of Solaris or other third-party packages.
> Unregistered subdirectories however, may exist underneath the
> pkg registered directory.
I'm not sure of the value in this statement.
One key point that is essential for the functionality of /var/share
with Snap Upgrade or similar schemes is that if the packaging tools
will add/remove/modify files or directories in /var/share there needs
to be provisions for not whacking them during upgrade operations. In
particular, the running Solaris instance should not be modified when
altering the upgrade environment and fallback needs to be possible.
Perhaps this gets into points you want to talk about later - if so I
am happy to defer this part of the conversation.
--
Mike Gerdts
http://mgerdts.blogspot.com/
