[lxc-devel] [PATCH 3/3] Let lxc-start read container name from rcfile if not specified on command line

[Andrian Nord]

> No. It should just be lxc-start which shall be able to act on a
> config file only.

That's strange. One utility will behave different from other. But ok,
let's assume, that this is not a problem for server software.

> So i have one rcfile in /etc/lxc/ and use this for many containers? This
> would be confusing in terms of administration in my opinion. The beauty
> of having /etc/lxc/auto/*.conf would be to be able to see with one ls
> which containers are started automatically. So i really want to have one
> config file for each container. The shared aspect might be better suited
> by allowing to include another rcfile in the container specific one.

This could be very useful for spawning very similar temporary hosts, changing
only few values (probably utsname and networking). For example, it's
useful for testboxes.

Also, with few patches, only config could be used for spawning networkless
containers.

> A configless container has no config and can therefore obviously not be 
> started by a generic init.d script which would not even know what to 
> start. 

Configless - application containers - it's fairly simple to implement
init.d that will call another init.d in spawned container, than patch every
affected init.d to make it spawn container on its own.

Or course, it could be done by different init.d, with another config
syntax, but that would be even more confusing, imo.

> Also i wonder if such a container if of any use whatsoever. You call it
> a safe sandbox, but is it? It protects from virtually nothing a malicious
> user or binary can do in it, at least if one can get/hack root.

I suppose Daniel done this to test scalability =). Use of this is
spawning cgroup and running into new namespaces (exept network). Cgroups
allow resource shaping. Namespaces, in theory, should protect filesystem
and IPCs (but currently this is not true - same uid in different
user-namespaces means same access, but this may change in future (and I
hope it will, but I don't see a clear way)).

So, that's not a protection from hacking inside, but protection from
DoSing whole server, fork bombs, memory leaks. Also, it could be
possible to mount/umount some filesystems for this applications without
affecting other applications (and invisible for ordinary users).

Also, you may use configless containers not exactly configless - you may
configure them via
cat <<CONFIG | lxc-start -f /proc/self/fd/0 -n <some name>
lxc.root = ...
lxc.network. ...
...
CONFIG

But, this situation still don't has config _file_. Shared config could
be maked by same technique (I'd make patch, that adds including support,
but it was rejected as "this is 'low-level utilities'")

> > As you see, there is no way basing on configs anyhow if you want to
> > cover with your init.d all this possible configurations.
> 
> I beg to differ. It can be done and i think it would be for the better
> anyway. Having (the possibility to put) as much as possible in a rcfile
> is a good thing because it makes it much more simple to see the 
> configuration of a container. Heck, we could even get rid of lxc-execute
> and allow to specify the binary to execute in the rcfile. Which probably
> makes sense in any case.

I'm talking on logic ;) I'm not against you patch, it will not harm
anyone, i'm just trying to guess if there is better way of doing things.

Why not just specify name and other-options-you-what-to in
shell-sourceble file? You may do this on per-container,
per-container-group, whatever-you-like-to basis.

> I'm really -1000 to deriving a config value from a file name. This is
> ugly and it will break at the worst possible moment. I want to be able
> to cd /etc/lxc/auto ; cp ../domain1.conf ./test.conf ; edit test.conf ;
> lxc-start test and have the domain started and still be "domain1" as
> specified in the conffile.

lxc-start -f /etc/lxc/auto/test.conf, I suppose?

Naming configs unrelated to their contents is even more confusing, imo.
Let's guess I what to see what containers are started.
# ls /etc/lxc/auto/
test.conf domain4.conf my_super_container.conf yoyoyo.conf

Hm... But wait - this could be just everything! I need to grep for name
then, to see what 'exactly' is started.

Same thing, if I want to change config for particular hostname (I'm
using my varitables patch to always have utsname==name+suffix) - I need
to grep for name.

I suppose it whould be much nicer to make symlinks. But original
configs should have container-names in filename.
# ls -1 /etc/lxc/auto
test.conf -> ../conf/domain1.conf

And what about order? (You may want to start your nameserver before other
containers). You may use
# ls -l /etc/lxc/
00 -> ../conf/apache.conf
01 -> ../conf/nginx.conf

But now we just go into, imo, much better thing:
# ls -1 /etc/lxc/lxc.*
/etc/init.d/lxc.apache -> lxc
/etc/init.d/lxc.nginx -> lxc

And then you may control your containers using your distro's rc system!
You may start some containers before some other services, other after
them.

Yeap, if you have hundreds of containers, most of which is not depending
on anything except some very basic config, you may want to start them
all, without messing with order and other things - and here symlinks
into autostart dir (runlevel into runlevel) would be nice. But I don't
see much sense in naming them otherwise than original configs - if I
will later decide to remove them from autostart, I'll be forced to, at
least, run ls -l into autostart directory, instead of just tabbing it.

Guessing name from filename is not nice, I agree, but, personally, I
prefer to guess config path from name, than name from config path, when
i'm playing with containers manually, so config path is always related
to name, not otherwise, for me.

Still, again, I'm not against this patch, if, from Daniel's view it's
not adding complexity, it might be useful for one single case. Other
cases will still require some script-magic ;)