This was a sort of FHS-style dir convention I worked on a while back (2011), and have been using on a RHEL machine for a couple of years now. Basically I wanted a place to put things might be shared in common by multiple VMs or hypervisors (like VM images). Nowadays, I'd leave the distro's normal fs alone and use something like the OpenStack images service to worry about where these things go. Also, other work has been done to make parts of the fs read-only to make things more instance-friendly. So this whole idea is kind of obsolete. It was an attempt to hierarchize that which cannot be done so.
So nobody should ever actually try what this draft says. But I'm putting this up now (2014) in case it's ever interesting to anyone and catalyzes thought. ...Which is unlikely.
There are some annoyances that can pop up, like how moving lots of important stuff like VM dirs can burn you when SELinux is running and mmm was created with a poor context. But that's my fault, not SELinux's. SELinux is great.
So nobody should ever actually try what this draft says. But I'm putting this up now (2014) in case it's ever interesting to anyone and catalyzes thought. ...Which is unlikely.
There are some annoyances that can pop up, like how moving lots of important stuff like VM dirs can burn you when SELinux is running and mmm was created with a poor context. But that's my fault, not SELinux's. SELinux is great.
mmm
- mmm - Multi-Machine Magazine
- A convention that may promote more useful network sharing of non-host-specific files.
- Copyright and License: This document is licensed under the GNU FDL 1.3.
- Abstract:
- A personal convention is described that facilitates sharing of files among networked computers via migration of these files to designated physical volume and application of a novel path schema. A logically defined inversion of the migrated path allows allows utility of application or VM host commonality to emerge at the top level of a hierarchical directory tree. This is applied to an example schema for the hierarchical presentation of files and directories in the Linux® VFS.
- Motivation:
- Much configuration/convention needs to be accessed by multiple hosts/machines.
- A significant subset of this information has appeared
more recently due to increased use of VM guests and software
repositories (mirrors) aboard Linux servers.
- Especially for files/directories containing:
- VM information (configurations, disk image files)
- software repositories/metadata (yum caches, channel dumps)
- certain types of build trees (i.e. mocks)
- database files that may be used in more than one machine context
- mail spools
- enclave-wide security settings
- Especially for files/directories containing:
- This data is currently distributed in files that can seem scattered, due to a preexisting legacy directory schema adopted from Unix® (/home, /usr, /etc).
- They could be collected by a more useful schema reflecting utility/purpose/application, however...
- Parts of current filesystem schema may not work well as this collection place.
- e.g. /var cannot be made nearly "machine-context-free":
- /var/run -- holds machine dependent process information,
- /var/lock -- ...same,
- /var/spool/mail -- ...is really application-specific, not machine-specific.
- e.g. /etc doesn't fit, either, as it contains a mixture of "app-machine-context", "machine-context", and "app-context".
- /etc/qemu -- app-context, although much of /etc is host-specific data,
- /etc/libvirt/qemu -- VM guest context, not host context,
- /etc/sysconfig -- however, is machine-context, like much of /etc.
- e.g. /var cannot be made nearly "machine-context-free":
- Therefore, designation of a new location for such files/directories can be helpful to users.
- These files can be moved, and then symlinked back into their original places.
- This designation and use can only be worthwhile if performed without significant disruption to the well-known (and FHS-specified) Linux filesystem tree.
- Moreover, an analysis of file commonality indicates that creation of a convention of a new colocation affords an opportunity of utility. Filing the data in a manner that encourages collection by purpose (application) also enhances visibility to potential users. This is done by refactoring portions of the hierarchy according to purpose (machine-context-free application data) as opposed to a normal directory hierarchy (which has some machine-context-specific schema that can hide and scatter common data if applied past the symlink).
- Moreover, such a new location will likely contain files with similar security ACLs, promoting a more fitting default file-creation ACL for that location. This utility is most especially noticed as useful among users of virtual machine images created (or moved to) directories that contain ACLs too restrictive for presentation to a hypervisor (even though the ACLs are generally appropriate).
- Convention:
- context -- part of a directory path/tree schema
precipitated or influenced by machine (OS or filesystem specific)
requirement or convention.
- a path that reflects some combination of OS/distro/sw/version,
- aka MCF -- Machine Context-Specific.
- non-context -- may (perhaps somewhat
needlessly) reflect some machine context, but could be structured more
usefully if removed from the bounds of the machine-specific context,
- aka MCF -- Machine Context-Free.
- axis -- the segment of a machine-context pathname betwen the above that can be multi-machine-mapped
- the most specific item common to all contexts
- all elements before the chosen axis are machine-context-free
- all elements after the chosen axis are machine-context-specific
- e.g. for /var/cache/yum/x86_64/, [[move this below]]
- fixture -- the MCS part of a path, kept due to the differences in context.
- pivot - the MCF part of a path.
- tovip -- a fully-reversed MCF part of a path (please excuse my presumption of neologism for the reverse spelling of pivot).
- mmmm -- a multi-machine mappable magazine (the thing whose name will be mmm)
- the actual magazine containing actual data,
- contents could be non-OS-specific,
- contents could be non-app-version-specific,
- could be a volume,
- could contain a filesystem,
- filesystem subdirs could be done as:
- [dirname] -- mappable dirs,
- [appname] -- common app or package names,
- [axis]
- elements before the axis are pivoted/reversed on the mmmm and appended to the axis
- [/botdir/middir/topdir] is mapped into via symlink from machine context wanting a /topdir/middir/botdir when [botdir] is an [appname] axis
- [OS_ver] -> [dirname]
- [SW_ver] -> [dirname]
- .mmm
- a file describing specific available mappings
- each mapping could describe OS- or software-version-specific mappings when non-eliminable
- format (LON)
- could contain a filesystem,
- /mmm - a mapping for a set of axes (colloquially: a remapping)
- top level pivot dir used in a machine context for mapping
- could be a direct mount, i.e.:
- /dev/sdn on /mmm
- /dev/mapper/mmmm on /mmm
- could be a symlink into an actual mount point, i.e.:
- /mmm > /media/volname
- when /dev/sdn on /media/volname
- /mmm > /media/volname
- apps could symlink to the top axis, e.g.:
- [pivot]/[axis]/[fixture] -> [mmm]/[axis]/[tovip]/[fixture]
- /var/lib/libvirt -> /mmm/var/lib/libvirt
- /var/lib/libvirt -> /mmm/libvirt/lib/var
- /etc/libvirt -> /mmm/libvirt/etc
- /var/cache/yum -> /mmm/yum/cache/var
- /var/lib/yum -> /mmm/yum/lib/var
- /var/cache/yum/x86_64/6Workstation/ -> /mmm/yum/cache/var/x86_64/6Workstation
- context -- part of a directory path/tree schema
precipitated or influenced by machine (OS or filesystem specific)
requirement or convention.
- Usage:
- path/dir naming conventions:
- for package repos:
- [distro]/[distro-version]
- /var/cache/yum/x86_64/13
- for compatibility assemblies:
- [arch]/[exe-ABI-format]/[exe-load/linkability-format]/[exe-dependent-library-matrix]
- for package repos:
- path/dir naming conventions:
