1 |
On Mon, Feb 4, 2019 at 7:10 PM Grant Taylor |
2 |
<gtaylor@×××××××××××××××××××××.net> wrote: |
3 |
> |
4 |
> On 02/04/2019 02:58 PM, Rich Freeman wrote: |
5 |
> > So, I think we're miscommunicating a bit here... |
6 |
> |
7 |
> It happens. |
8 |
> |
9 |
|
10 |
Yeah, I think you're over-reading into my posts. I'm mostly reacting |
11 |
to your ideas and not trying to be prescriptive. |
12 |
|
13 |
For example, you talked about running openrc inside the container, and |
14 |
then I talked about how you might do that, and then you asked why |
15 |
would you want to run openrc inside the container. Well, since I |
16 |
don't know exactly what you're doing I don't know - if it doesn't make |
17 |
sense then don't do it... :) |
18 |
|
19 |
> > I'm saying that an init.d script shouldn't try to do anything other |
20 |
> > than initialize a service, which should be implemented outside the |
21 |
> > init.d script. |
22 |
> |
23 |
> It sounds like you are saying that an init script shouldn't do anything |
24 |
> other than (re)start/stop a service and that there should be a separate |
25 |
> script (binary / command) that is the service. |
26 |
|
27 |
Essentially. It isn't like it won't work if you do something else - |
28 |
it is just a design principle. |
29 |
|
30 |
Suppose you want to manually launch a container without using the |
31 |
init.d script, just as you might launch a non-forking server process |
32 |
to do some console debugging if you were having an issue. And so on. |
33 |
|
34 |
It is just a shell script, so it isn't like it won't work if you do it |
35 |
all in the script. |
36 |
|
37 |
> |
38 |
> ip netns add myContainer |
39 |
> ip link add myContainer type veth peer name myHost netns myContainer |
40 |
> ip link set myContainer up |
41 |
> ip addr add 192.0.2.1/24 dev myContainer |
42 |
> ip netns exec myContainer ip link set myHost up |
43 |
> ip netns exec myContainer ip addr add 192.0.2.2/24 dev myHost |
44 |
> |
45 |
|
46 |
Interesting. I didn't realize that linux even supported creating |
47 |
network namespaces without an associated process. Maybe you don't |
48 |
need one after all. |
49 |
|
50 |
I guess since network interfaces can do their netfilter/etc logic |
51 |
without any processes actually listening on them it makes sense that |
52 |
these namespaces might have their own existence. |
53 |
|
54 |
> So, I'm not sure why those commands need to or should live inside |
55 |
> something other than the init script. |
56 |
|
57 |
They don't need to. |
58 |
|
59 |
IMO they should, but that is like saying that your 5000 line C program |
60 |
should actually have 5000 lines and whitespace, and not look like the |
61 |
javascript source to gmail. It is somewhat subjective, as gcc doesn't |
62 |
care if the whole thing is one big mass of punctuation... :) |
63 |
|
64 |
> Why can't I have a single /etc/runlevels/myContainer that is never used |
65 |
> outside of the container and only used inside the container? Remember |
66 |
> that the host and container share the same file system. |
67 |
|
68 |
Can you actually start openrc in a container using a parameter-driven |
69 |
runlevel that isn't a number? I believe you can pass a numeric |
70 |
runlevel to init and it will start on that runlevel (though I'm not |
71 |
sure you can start openrc that way in non-trivial configs as that |
72 |
might skip the boot runlevel, assuming openrc doesn't override this |
73 |
sysvinit behavior). You can't use the kernel command line since |
74 |
containers don't have a separate kernel. |
75 |
|
76 |
You can of course change the default runlevel for openrc using config |
77 |
files in /etc, but those are shared with the host in your proposed |
78 |
design. |
79 |
|
80 |
Maybe you could hack something together here, but honestly I'm not |
81 |
sure what you're getting by not having a separate /etc or at least a |
82 |
bind mount for the openrc config. |
83 |
|
84 |
Again, assuming you need openrc in the container at all. |
85 |
|
86 |
-- |
87 |
Rich |