Re: [gentoo-user] VRFs / Jails / Containers

[Rich Freeman]

On Mon, Feb 4, 2019 at 1:44 PM Grant Taylor
<gtaylor@×××××××××××××××××××××.net> wrote:
>
> I'm starting to wonder if I'm going to be better off writing new scripts
> that will match existing init scripts and their methodology to
> (re)start/stop namespaces / containers / jails.  Perhaps firejail will
> give me what I want or provide insight.
>

IMO I would separate your container logic from your service manager logic.

If you have a script that launches a container, then all you need is a
generic init.d script that runs it.

I launch nspawn containers from systemd units all the time.  The only
logic in the units is running the command line to start nspawn.

IMO if you start mixing the two it will just make it harder to
maintain.  Sure, an init.d script CAN do anything, but that doesn't
mean that you should do it this way.

Without creating a separate reply I wanted to react to your other
email detailing your config.  It strikes me that you might not even
need containers to set up all those interfaces and the routing between
them.  However, the container probably still makes sense so that
random processes trying to listen on 0.0.0.0 on the host don't end up
attaching to all those virtual interfaces.

Really all you need is some initialization inside each container and
then the kernel is doing all the work.  You don't really need any
userspace process running in the container except for the fact that
kernel namespaces are attached to processes.  As a result, I'd suggest
considering using sysvinit inside your containers to do the work.  You
might run openrc/netifrc to do the network setup inside each
container, or just have sysvinit run a shell script that initializes
and then terminates, leaving init running childless indefinitely (I
assume it supports this).  If you want a process to noop indefinitely
at minimal cost that is basically the definition of what sysvinit
does...

-- 
Rich