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

[Grant Taylor]

On 02/04/2019 02:58 PM, Rich Freeman wrote:
> So, I think we're miscommunicating a bit here...

It happens.

> I'm saying that an init.d script shouldn't try to do anything other
> than initialize a service, which should be implemented outside the
> init.d script.

It sounds like you are saying that an init script shouldn't do anything 
other than (re)start/stop a service and that there should be a separate 
script (binary / command) that is the service.

(I'm going to assume that's accurate unless / until you say otherwise.)

Does this apply if the ""service is something as simple as enabling or 
disabling IP forwarding?  Should the init script call a separate script 
to write the proper value to the requisite proc entry?

> So, if you have a shell script that launches a container, then you should
> call it from the init.d script.  You shouldn't merge them into a single
> init.d script that has 30 lines of container setup logic or whatever.

I think the issue that I'm having, and part of what you're calling out 
is that the script for a ""container (network namespace) is more than it 
should be.

Consider the following commands to start the ""container:

ip netns add myContainer
ip link add myContainer type veth peer name myHost netns myContainer
ip link set myContainer up
ip addr add 192.0.2.1/24 dev myContainer
ip netns exec myContainer ip link set myHost up
ip netns exec myContainer ip addr add 192.0.2.2/24 dev myHost

Consider the following command to stop the ""container:

ip netns del myContainer

I feel like those two sections could easily fit within an OpenRC init 
script:

start() {
    ip netns add myContainer
    ip link add myContainer type veth peer name myHost netns myContainer
    ip link set myContainer up
    ip addr add 192.0.2.1/24 dev myContainer
    ip netns exec myContainer ip link set myHost up
    ip netns exec myContainer ip addr add 192.0.2.2/24 dev myHost
}

stop() {
    ip netns del myContainer
}

So, I'm not sure why those commands need to or should live inside 
something other than the init script.

Please help me understand what I'm missing or not understanding.

> Of course.  That shell script that launches a container could very well
> just launch sysvinit which runs openrc which runs another set of init.d
> scripts INSIDE the container to initialize it.

Now I'm starting to think that you are under the impression that the 
""container(s) that I'm working with are more complicated and have many 
things running in them, more akin to a full OS.  That's not the case for 
me or my use case.

About the only other added complication might be launching BIRD and / or 
an additional network interface.

> Yup - though I would think the scripts inside the container would be
> fairly different, as they are doing different things.  The scripts inside
> the container aren't starting containers, for a start...

The contents of the ""container(s) that I'm using are identical to the 
host.  They actually /are/ the host.  I'm not using mount namespaces. 
So the ""container ~> network namespace sees the exact same files as the 
host.

The only reason that I (sometimes) use the UTS namespace is so that 
uname (et al) return a different name when run inside the NetNS.

> OpenRC/Netifrc are run by sysvinit in Gentoo, as I mention later on.
> These two are not mutually exclusive.

Okay.

> Not sure how much of it would be re-use.  The scripts inside/outside
> the container would likely have different roles.

I would think that I could (re)start / stop BIRD inside the NetNS the 
exact same way I do on the host.  I would expect that I could use the 
same "rc-service bird …" command inside and outside.

> Honestly, I wouldn't go sticking container init.d scripts inside the host
> init.d.  I mean, I guess you could, but again, separation of concerns
> and all that.  You're going to have to use a separate /etc/runlevels,
> so why not just a whole separate /etc?

Why do I need to use a separate /etc/runlevels?

Why can't I have a single /etc/runlevels/myContainer that is never used 
outside of the container and only used inside the container?  Remember 
that the host and container share the same file system.



-- 
Grant. . . .
unix || die