[Lxc-users] Proposal for an FHS-compliant default guest filesystem location

[Michael H. Warfield]

On Mon, 2010-11-08 at 14:45 -0500, Brian K. White wrote:

> Why in the world would you want to break the ability to safely back up 
> just /etc and know that you got practically everything needed to 
> re-create a server without having to back up the entire server full of 
> redundant junk that would be better to come from new install media?

Precedent is already set.  I presume you're not running any Samba
servers or MailMan servers or MySQL servers or PostgresQL servers or a
host of other servers that store their state data in /var/lib.  /etc is
fine for simple basic configuration.

> Yes there are already special cases that break this assumption but they 
> are few and should be reduced and avoided not embraced and increased.

Not few at all in my experience.

> I have rsync/backup scripts that just grab /etc, /home, /srv, and a 
> couple application specific data dirs, and this not only makes my 
> backups (and restores, and migrations, and clones) small and fast, it 
> makes it easier to move to newer versions of the distribution, different 
> cpu platforms, and even different OS's.

> I'd like config files in /etc/lxc/<guestname>/config just like most 
> other things work.

If it's just the "config" file(s) then I agree and that agrees with the
OpenVZ paradigm on which I generally follow.  But it use to be more and
if it is still more, then /etc/ is not the best place and maybe things
need to be split.  I concur on the configs and only the configs.

I also think an global /etc/lxc/lxc.conf file might be in order to store
some "across the board" variables like the locations for the
mounts/pivot points and other common characteristics that are hard coded
now and may be distro dependent / variable.

> /srv/lxc sounds good to me for the rootfs's for the same reason I want 
> /etc/lxc for the configs.

Concur.

> cgroups is another issue.
> /cgroup makes sense because of /proc /sys /dev etc, but there are also 
> /dev/pts and /sys/kernel/debug etc so mounting kernel virtual fs's on / 
> is not universal.

That was discussed on the containers group ages ago.  Also discussed
was /dev/cgroup, /proc/cgroup, and /sys/cgroup, all of which proved to
be untenable for various reasons.  I seriously doubt you find a
migration to yet another top level directory here but I could we wrong.

> I think, just talking about the undifferentiated (distribution agnostic) 
> default here, it might make sense to have a lxc-specific cgroup mount 
> point in one of:
> /var/run/lxc/cgroup
> /var/lxc/cgroup
> This way lxc can organize itself and tend to it's own needs without 
> caring how/where/if the distribution mounts a generic system cgroup fs 
> or not. Your lxc start/stop/status scripts can safely know the location 
> of the mount, and can safely write the notify/release options and/or 
> delete the unused cgroups itself and/or lxc-stop/start could manipulate 
> them itself safely too.

The scripts already figure that out from mount itself.  I don't see a
need for worrying about that.

> And the expect and encourage most distributions to override that with 
> their particular system wide generic or separate cgroup mount points 
> organized according to their particular design principles.

Again...  The scripts are already smart enough to adjust.

> The special empty directory for the pivot_root mount point should 
> probably be in /usr/lib/lxc as was discussed some time ago. (I don't 
> remember if that's what was decided, just that it was discussed)

No.  /usr/lib/lxc should be considered static and potentially read only
and potentially prohibited from mounting.  /var/lib/lxc is the best
candidate for that and fits the intend.

> -- 
> bkw

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20101109/3fb8217e/attachment.pgp>