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

[Grant Taylor]

On 02/04/2019 11:55 AM, Rich Freeman wrote:
> IMO I would separate your container logic from your service manager logic.

I'm not exactly sure what you mean by "container logic" vs "service 
manager logic" and how they differ.  I'm assuming that the former 
creates / destroys the container and that the latter manages 
(re)starting/stopping services where ever they are at.

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

I guess that's one way to do it.  But that doesn't seem very Gentoo<ish> 
to me.

I'd like to see a way that I can have standard service init scripts and 
use them where ever I want them, either inside a container or outside on 
the host.

As long as I don't want to run the same service in multiple places, I 
don't see a problem with doing that.  Multiple instances starts to get 
more tricky, but is still possible, and should be location agnostic.

> 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.

I'm wanting to avoid having an init script that creates the container 
and starts services therein.  I'd rather start the container and then 
start the services therein using the same type of init scripts, just 
called within different contexts.

> 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.

Yes, I could have all the interfaces on the host.  But I'm doing a 
number of different things and don't want to spoil the host.

The nice containers that I mentioned are long standing containers.  I 
routinely stand up 10 ~ 100 more for various tests.

I'm also using network namespaces as an isolation so that I can easily 
do various things with networking without the added complexity of 
isolating things from each other via command line or policy based 
routing.  Each network namespace can easily have it's view of 0.0.0.0 
(as a good example) and it's own routing table.  I don't need to bother 
with PBR / ip rules / iptables complexities.  Each NetNS just knows 
about it's local 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.

I mostly agree.  I am running BIRD inside the container, but that's more 
of a would be nice to have and I can work around not having it.  There 
are also the occasional commands that I want to run to do 
troubleshooting (ping, traceroute, etc) as well as dynamically modifying 
the containers which is usually done via "nsenter …" or "ip netns exec 
$NetNSname …" commands.

> As a result, I'd suggest considering using sysvinit inside your
> containers to do the work.

That is a possibility.  But I feel like that's tantamount to saying 
"Gentoo doesn't have an answer for what you're wanting to do, so just 
use Sys V init scripts."  I don't like it.

I like the idea of re-using standard OpenRC / NetifRC scripts inside the 
containers too.  Especially if the services don't conflict anywhere.  To 
me, this re-uses the existing Gentoo methodology in different contexts.

> 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...

The more that I think about it, largely in response to emails in this 
thread, I believe that I want the same overall thing to create the 
network between the default / main / unnamed NetNS and the container, as 
well as likely re-using the OpenRC / NetifRC scripts to configure things 
inside the container.

I think, and would be curious to have someone confirm or refute, that I 
could add configuration information to /etc/conf.d/net for the xyz123 
interface inside the container and use an /etc/init.d/net.xyz123 init 
script sym-linked to /etc/init.d/net.lo script.

My host would not have net.xyz123 in any runlevel.  Certainly not boot 
or default.

I think that would mean that I could run rc-service net.xyz123 start 
inside the container and re-use existing Gentoo methodology.

Now I wonder if I could use custom runlevels for each container and rely 
on standard init system.  }:-)  But that's a different question.



-- 
Grant. . . .
unix || die