Mike Gerdts wrote: > 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. >
Yes, this is what I'm envisioning too. > >> - /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? > Perhaps. One thing that's confusing me about the definition is that /var/log/syslog is obviously a log file, but its of type e. What I'm intending to mean here is probably type e and v files. > <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>. > Yes, I agree these don't belong in /var, but I'm not sure about type e part. > >> - 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. > The issue is that any directory that we're sharing across BEs can't contain any pkg registered subdirectories because if a future update to that package removes or even just changes those subdirectories, that affects all other BEs, which we can't allow. There'd need to be some special handling or /var/share by the software update mechanism to support this. > >> 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. > Precisely. Getting 'pkg' into the loop and defining special handling for /var/share could certainly curtail the limitation described above, but that's not yet been probed or questioned in this proposal. I hadn't been going down this route because of requirement #3 in the proposal. But lets discuss this a little bit more now. What are the special provisions that would be needed to be handled by 'pkg' (or whatever software update mechanism is used) to enable the entire /var/share directory to be shareable across BEs? A couple that I can think of are: - a 'pkg remove' from any BE can't ever remove a package's contents from /var/share - a 'pkg update' to any BE can't ever remove or change a package's contents in /var/share, but can only add to /var/share (change would include even simple changes like the permissions on a file or directory) - a 'pkg install' to any BE can't ever replace or change existing content in /var/share even if it conflicts with the what's being installed. -ethan > Perhaps this gets into points you want to talk about later - if so I > am happy to defer this part of the conversation. >
