| 1 |
On 2/5/19 10:55 AM, Rich Freeman wrote: |
| 2 |
> Yeah, I think you're over-reading into my posts. I'm mostly reacting |
| 3 |
> to your ideas and not trying to be prescriptive. |
| 4 |
|
| 5 |
So we have a feedback loop. I'm trying to understand why you're saying |
| 6 |
what you're saying. |
| 7 |
|
| 8 |
I'm still looking for possibilities and pros / cons of each. |
| 9 |
|
| 10 |
> For example, you talked about running openrc inside the container, and |
| 11 |
> then I talked about how you might do that, and then you asked why would |
| 12 |
> you want to run openrc inside the container. Well, since I don't know |
| 13 |
> exactly what you're doing I don't know - if it doesn't make sense then |
| 14 |
> don't do it... :) |
| 15 |
|
| 16 |
Seeing as how my container really is the same as the host, at least when |
| 17 |
it comes to file system and files, OpenRC is what is there. Hence my |
| 18 |
interest in re-using what's already there. |
| 19 |
|
| 20 |
That is /if/ doing such does not have too many cons. |
| 21 |
|
| 22 |
> Essentially. It isn't like it won't work if you do something else - |
| 23 |
> it is just a design principle. |
| 24 |
|
| 25 |
ACK |
| 26 |
|
| 27 |
> Suppose you want to manually launch a container without using the init.d |
| 28 |
> script, just as you might launch a non-forking server process to do some |
| 29 |
> console debugging if you were having an issue. And so on. |
| 30 |
|
| 31 |
I see what you're saying by starting a typical daemon manually vs init |
| 32 |
scripts. |
| 33 |
|
| 34 |
Given that what I'm talking about doing doesn't leave a process running |
| 35 |
(I'm ignoring BIRD for the moment) there's nothing to kill to stop it. |
| 36 |
|
| 37 |
What I'm doing is really a series of commands that stand the service up |
| 38 |
and a command that stops it. |
| 39 |
|
| 40 |
I guess that I could have an independent script for this and then have |
| 41 |
the init script do nothing more than call the script with a start |
| 42 |
parameter. But I feel like my independent script is functionally |
| 43 |
identical to an init script. |
| 44 |
|
| 45 |
> It is just a shell script, so it isn't like it won't work if you do it |
| 46 |
> all in the script. |
| 47 |
|
| 48 |
*nod* |
| 49 |
|
| 50 |
> Interesting. I didn't realize that linux even supported creating network |
| 51 |
> namespaces without an associated process. Maybe you don't need one |
| 52 |
> after all. |
| 53 |
|
| 54 |
I've been using network namespaces without a process for quite a while. |
| 55 |
They are extremely handy. |
| 56 |
|
| 57 |
> I guess since network interfaces can do their netfilter/etc logic |
| 58 |
> without any processes actually listening on them it makes sense that |
| 59 |
> these namespaces might have their own existence. |
| 60 |
|
| 61 |
;-) |
| 62 |
|
| 63 |
> They don't need to. |
| 64 |
|
| 65 |
Which is why I was back to putting the (re)start / stop commands in the |
| 66 |
init script. |
| 67 |
|
| 68 |
> IMO they should, but that is like saying that your 5000 line C program |
| 69 |
> should actually have 5000 lines and whitespace, and not look like the |
| 70 |
> javascript source to gmail. It is somewhat subjective, as gcc doesn't |
| 71 |
> care if the whole thing is one big mass of punctuation... :) |
| 72 |
|
| 73 |
Yes, there is subjectivity to it. But there are also Gentoo |
| 74 |
methodologies and guidelines. |
| 75 |
|
| 76 |
> Can you actually start openrc in a container using a parameter-driven |
| 77 |
> runlevel that isn't a number? |
| 78 |
|
| 79 |
I don't know. I'll have to try and find out. |
| 80 |
|
| 81 |
> I believe you can pass a numeric runlevel to init and it will start |
| 82 |
> on that runlevel (though I'm not sure you can start openrc that way |
| 83 |
> in non-trivial configs as that might skip the boot runlevel, assuming |
| 84 |
> openrc doesn't override this sysvinit behavior). You can't use the |
| 85 |
> kernel command line since containers don't have a separate kernel. |
| 86 |
|
| 87 |
I think I understand what you're saying. I also doubt that I will need |
| 88 |
a boot runlevel in a container the way that I'm doing them. |
| 89 |
|
| 90 |
I can see needing a net.<something> and maybe a BIRD init script in the |
| 91 |
target runlevel. But other than that, there's virtually nothing that |
| 92 |
does not already exist from the host's file system / environment. |
| 93 |
|
| 94 |
> You can of course change the default runlevel for openrc using config |
| 95 |
> files in /etc, but those are shared with the host in your proposed design. |
| 96 |
|
| 97 |
ACK |
| 98 |
|
| 99 |
I /can/ use a mount namespace and have a different /etc. But I'd rather |
| 100 |
not do that unless there is a need to do so. |
| 101 |
|
| 102 |
> Maybe you could hack something together here, but honestly I'm not sure |
| 103 |
> what you're getting by not having a separate /etc or at least a bind |
| 104 |
> mount for the openrc config. |
| 105 |
|
| 106 |
I currently have no need for a separate /etc. So why have something |
| 107 |
that I don't currently need? |
| 108 |
|
| 109 |
> Again, assuming you need openrc in the container at all. |
| 110 |
|
| 111 |
Seeing as how the container has the same files as the host, that means |
| 112 |
that OpenRC is already in the container. So if I can make use of it |
| 113 |
without causing problems, then why not? |
Archives