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 | [email protected] /\/\|=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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
