On Sat, May 30, 2015 at 8:29 PM, Fajar A. Nugraha <[email protected]> wrote: > On Sun, May 31, 2015 at 6:58 AM, james harvey <[email protected]> > wrote: >> I want to create a container that starts out being identical to my >> top-level no-container installation. I want any changes performed >> within the container to be kept in the container. I want anything >> added to my top-level no-container installation to automatically show >> up in already made containers. >> >> It looks like I want to use an overlayfs. I'm not having success. > > overlayfs won't be able to do exactly what you want. For example: > - a container is created using overlay of the host > - you change root password inside the container, thus making the > container has its own copy of some files (e.g /etc/passwd, > /etc/shadow) > - you install new package on the host, which also creates a new user > > The new user will not be available inside the container, thus possibly > making the newly-installed package broken inside the container.
Quite true. I'd like to be able to avoid these problems, but can live with them if it's the only way I can go. I use Sandboxie for Windows, which I'll discuss below, and I have to keep a few things straight through it too, to avoid problems like this. >> $ sudo dnf install lxc >> $ sudo lxc-create -n test -t none >> lxc-create: lxc_create.c: main: 274 Error creating container test > > >> I think I need -t none though, since I don't want new packages to be >> installed inside my container. > > I don't think "-t none" works. > > An easier way would be to copy config file created by the download > template (-t download) for the same distro, and then modify it. Sounds like not what I'm looking for, so I think I'll continue on. > >> >> If I create a container and I "touch hello.message", I basically want >> the entire container to be taking up only a few bytes for the extra >> filehandle -- plus whatever "overhead" lxc has -- but without >> basically duplicating a full install. > > In practice, it will be MUCH more than "a few bytes". Anything the > container writes to (e.g. /var/log/messages, /var/lib/mysql/*) will be > copied and disconnected from the original. That's all perfect, and exactly what I'd like it to do. I just meant a few bytes plus whatever overhead for if a single file is created, with nothing else like system messages or logging having happened... Just to illustrate the point that if I wanted inside the container to be like outside the container, just with changes localized to the container, that I didn't want it to have to have a full new install that I'd have to keep in sync. > What is your primary goal? My primary goal is that I want to have a program like Sandboxie in Linux, but it only runs on Windows. It certainly isn't perfect, but basically creates a C:\Sandbox\XYZ directory, and any processes running in the XYZ sandbox are transparently to them locked to making changes in that folder. I can install Visual Studio 2013 in one Sandboxie sandbox. Later, when 2015 release candidate comes out, I can install that in another sandbox. When 2015 release comes out, I can install that in yet another. Once I'm happy with it, I can just delete the previous sandboxes, and all traces of it are gone. (Sandboxie allows you to specify per sandbox to allow un-sandboxed access to certain things, like my documents, so if you set it up that way, deleting a visual studio sandbox doesn't delete any of your code.) On Linux, I'm fine being limited to terminal logins and graphical programs started from a terminal. I don't think I would ever want to graphically login to a container/sandbox. I want to have a container for building gcc/gcc-c++, and install via dnf (replacement for yum) the dependencies for building it... And only installing the dependencies for running it on the base o/s. I want to be able to sudo make install for source builds within a container/sandbox, and be able to delete the container/sandbox, for those that don't have a make uninstall option. > If it's space saving, then IMHO the best option would be to use > zfs/btrfs for your host, with compression enabled, and then clone it > for the container's fs. The space savings thru clone will be visible > as long as you do NOT upgrade packages on the host or container. The > savings thru compression will always be visible. I definitely do want to upgrade packages in the host, and have the container see them as upgraded. > If it's "installing/upgrading a package on the host will also install > it on the container", then your best choice would probably be to use > read-only bind mounts. By bind-mounting only /usr, /bin, and /sbin, > most package install/upgrade on the host should be usable on the > container as well, as long as you also take necessary steps to > manually sync non-bind directories (e.g. /etc) and run the necssary > post-install steps (e.g. create users). Personally I find this too > much of a hassle, so I just use zfs + compression + clone. Hoping everything can be accessible in the container, including /etc, users, and anything in their home directories. _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
