On 2/5/19 10:55 AM, Rich Freeman wrote:
Yeah, I think you're over-reading into my posts. I'm mostly reacting
to your ideas and not trying to be prescriptive.
So we have a feedback loop. I'm trying to understand why you're saying
what you're saying.
I'm still looking for possibilities and pros / cons of each.
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... :)
Seeing as how my container really is the same as the host, at least when
it comes to file system and files, OpenRC is what is there. Hence my
interest in re-using what's already there.
That is /if/ doing such does not have too many cons.
Essentially. It isn't like it won't work if you do something else -
it is just a design principle.
ACK
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.
I see what you're saying by starting a typical daemon manually vs init
scripts.
Given that what I'm talking about doing doesn't leave a process running
(I'm ignoring BIRD for the moment) there's nothing to kill to stop it.
What I'm doing is really a series of commands that stand the service up
and a command that stops it.
I guess that I could have an independent script for this and then have
the init script do nothing more than call the script with a start
parameter. But I feel like my independent script is functionally
identical to an init script.
It is just a shell script, so it isn't like it won't work if you do it
all in the script.
*nod*
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've been using network namespaces without a process for quite a while.
They are extremely handy.
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.
;-)
They don't need to.
Which is why I was back to putting the (re)start / stop commands in the
init script.
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... :)
Yes, there is subjectivity to it. But there are also Gentoo
methodologies and guidelines.
Can you actually start openrc in a container using a parameter-driven
runlevel that isn't a number?
I don't know. I'll have to try and find out.
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.
I think I understand what you're saying. I also doubt that I will need
a boot runlevel in a container the way that I'm doing them.
I can see needing a net.<something> and maybe a BIRD init script in the
target runlevel. But other than that, there's virtually nothing that
does not already exist from the host's file system / environment.
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.
ACK
I /can/ use a mount namespace and have a different /etc. But I'd rather
not do that unless there is a need to do so.
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.
I currently have no need for a separate /etc. So why have something
that I don't currently need?
Again, assuming you need openrc in the container at all.
Seeing as how the container has the same files as the host, that means
that OpenRC is already in the container. So if I can make use of it
without causing problems, then why not?
