On Mon, Feb 4, 2019 at 7:10 PM Grant Taylor <gtay...@gentoo.tnetconsulting.net> wrote: > > On 02/04/2019 02:58 PM, Rich Freeman wrote: > > So, I think we're miscommunicating a bit here... > > It happens. >
Yeah, I think you're over-reading into my posts. I'm mostly reacting to your ideas and not trying to be prescriptive. For example, you talked about running openrc inside the container, and then I talked about how you might do that, and then you asked why would you want to run openrc inside the container. Well, since I don't know exactly what you're doing I don't know - if it doesn't make sense then don't do it... :) > > 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. Essentially. It isn't like it won't work if you do something else - it is just a design principle. Suppose you want to manually launch a container without using the init.d script, just as you might launch a non-forking server process to do some console debugging if you were having an issue. And so on. It is just a shell script, so it isn't like it won't work if you do it all in the script. > > 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 > Interesting. I didn't realize that linux even supported creating network namespaces without an associated process. Maybe you don't need one after all. I guess since network interfaces can do their netfilter/etc logic without any processes actually listening on them it makes sense that these namespaces might have their own existence. > So, I'm not sure why those commands need to or should live inside > something other than the init script. They don't need to. IMO they should, but that is like saying that your 5000 line C program should actually have 5000 lines and whitespace, and not look like the javascript source to gmail. It is somewhat subjective, as gcc doesn't care if the whole thing is one big mass of punctuation... :) > 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. Can you actually start openrc in a container using a parameter-driven runlevel that isn't a number? I believe you can pass a numeric runlevel to init and it will start on that runlevel (though I'm not sure you can start openrc that way in non-trivial configs as that might skip the boot runlevel, assuming openrc doesn't override this sysvinit behavior). You can't use the kernel command line since containers don't have a separate kernel. You can of course change the default runlevel for openrc using config files in /etc, but those are shared with the host in your proposed design. Maybe you could hack something together here, but honestly I'm not sure what you're getting by not having a separate /etc or at least a bind mount for the openrc config. Again, assuming you need openrc in the container at all. -- Rich
