[lxc-users] Creating a Linux container that is just a sandbox of my actual installation

[james harvey]

On Sat, May 30, 2015 at 8:29 PM, Fajar A. Nugraha <list at fajar.net> wrote:
> On Sun, May 31, 2015 at 6:58 AM, james harvey <jamespharvey20 at gmail.com> 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.