On Mon, Feb 4, 2019 at 1:44 PM Grant Taylor <gtay...@gentoo.tnetconsulting.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
