[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] VRFs / Jails / Containers
From:       Grant Taylor <gtaylor () gentoo ! tnetconsulting ! net>
Date:       2019-02-06 3:29:49
Message-ID: 7d3cc33e-f3c3-e09b-a57b-76b6397b8469 () spamtrap ! tnetconsulting ! net
[Download RAW message or body]

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?

[prev in list] [next in list] [prev in thread] [next in thread]