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
