1 |
So, I think we're miscommunicating a bit here... |
2 |
|
3 |
On Mon, Feb 4, 2019 at 4:10 PM Grant Taylor |
4 |
<gtaylor@×××××××××××××××××××××.net> wrote: |
5 |
> |
6 |
> On 02/04/2019 11:55 AM, Rich Freeman wrote: |
7 |
> > IMO I would separate your container logic from your service manager logic. |
8 |
> |
9 |
> I'm not exactly sure what you mean by "container logic" vs "service |
10 |
> manager logic" and how they differ. I'm assuming that the former |
11 |
> creates / destroys the container and that the latter manages |
12 |
> (re)starting/stopping services where ever they are at. |
13 |
|
14 |
I'm saying that an init.d script shouldn't try to do anything other |
15 |
than initialize a service, which should be implemented outside the |
16 |
init.d script. |
17 |
|
18 |
So, if you have a shell script that launches a container, then you |
19 |
should call it from the init.d script. You shouldn't merge them into |
20 |
a single init.d script that has 30 lines of container setup logic or |
21 |
whatever. |
22 |
|
23 |
> |
24 |
> I'd like to see a way that I can have standard service init scripts and |
25 |
> use them where ever I want them, either inside a container or outside on |
26 |
> the host. |
27 |
|
28 |
Of course. That shell script that launches a container could very |
29 |
well just launch sysvinit which runs openrc which runs another set of |
30 |
init.d scripts INSIDE the container to initialize it. |
31 |
|
32 |
> I'm wanting to avoid having an init script that creates the container |
33 |
> and starts services therein. I'd rather start the container and then |
34 |
> start the services therein using the same type of init scripts, just |
35 |
> called within different contexts. |
36 |
|
37 |
Yup - though I would think the scripts inside the container would be |
38 |
fairly different, as they are doing different things. The scripts |
39 |
inside the container aren't starting containers, for a start... |
40 |
|
41 |
> > As a result, I'd suggest considering using sysvinit inside your |
42 |
> > containers to do the work. |
43 |
> |
44 |
> That is a possibility. But I feel like that's tantamount to saying |
45 |
> "Gentoo doesn't have an answer for what you're wanting to do, so just |
46 |
> use Sys V init scripts." I don't like it. |
47 |
> |
48 |
> I like the idea of re-using standard OpenRC / NetifRC scripts inside the |
49 |
> containers too. Especially if the services don't conflict anywhere. To |
50 |
> me, this re-uses the existing Gentoo methodology in different contexts. |
51 |
|
52 |
OpenRC/Netifrc are run by sysvinit in Gentoo, as I mention later on. |
53 |
These two are not mutually exclusive. |
54 |
|
55 |
> The more that I think about it, largely in response to emails in this |
56 |
> thread, I believe that I want the same overall thing to create the |
57 |
> network between the default / main / unnamed NetNS and the container, as |
58 |
> well as likely re-using the OpenRC / NetifRC scripts to configure things |
59 |
> inside the container. |
60 |
|
61 |
Not sure how much of it would be re-use. The scripts inside/outside |
62 |
the container would likely have different roles. |
63 |
|
64 |
> I think, and would be curious to have someone confirm or refute, that I |
65 |
> could add configuration information to /etc/conf.d/net for the xyz123 |
66 |
> interface inside the container and use an /etc/init.d/net.xyz123 init |
67 |
> script sym-linked to /etc/init.d/net.lo script. |
68 |
> |
69 |
> My host would not have net.xyz123 in any runlevel. Certainly not boot |
70 |
> or default. |
71 |
|
72 |
Honestly, I wouldn't go sticking container init.d scripts inside the |
73 |
host init.d. I mean, I guess you could, but again, separation of |
74 |
concerns and all that. You're going to have to use a separate |
75 |
/etc/runlevels, so why not just a whole separate /etc? |
76 |
|
77 |
-- |
78 |
Rich |