1 |
The 23/02/14, Canek Peláez Valdés wrote: |
2 |
|
3 |
> >> networkd (again, netctl is the command-line front-end) is not for |
4 |
> >> enterprise networks; on the contrary, is for the trivial cases. For |
5 |
> >> example, in a little web server I administer I have: |
6 |
> >> |
7 |
> >> $ cat /etc/systemd/system/network.service |
8 |
> >> [Unit] |
9 |
> >> Description=Static network service |
10 |
> >> After=local-fs.target |
11 |
> >> Before=network.target |
12 |
> >> Documentation=man:ifconfig(8) |
13 |
> >> Documentation=man:route(8) |
14 |
> >> |
15 |
> >> [Service] |
16 |
> >> Type=oneshot |
17 |
> >> RemainAfterExit=yes |
18 |
> >> ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 |
19 |
> >> netmask 255.255.255.0 up |
20 |
> >> ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 |
21 |
> >> |
22 |
> >> [Install] |
23 |
> >> WantedBy=multi-user.target |
24 |
> >> |
25 |
> >> (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time |
26 |
> >> yet). |
27 |
> >> |
28 |
> >> I'm going to get rid of this trivial network.service unit file when |
29 |
> >> 209 (or better 210) hits Gentoo. Cases like this are the use-cases for |
30 |
> >> networkd. |
31 |
> > |
32 |
> > what i don't understand is if you look at how openRC does it, it only |
33 |
> > really cares about up/down events and the /etc/conf.d/net is very |
34 |
> > comprehensive, in part because it passes everything to iproute2 to handle, |
35 |
> > the only thing i can't do without an additional shell script is tc qdiscs. |
36 |
> > i don't need or want a network manager, just need something that applies |
37 |
> > confs on startup / stop of interfaces. I'm a little surprised that there |
38 |
> > isn't an iproute2 .service file |
39 |
> > |
40 |
> > reading through your example, in fact this is preferrable to me than using |
41 |
> > a network manager but using iproute2. I would rather you keep this |
42 |
> > example in, and have this shown on the wiki or somewhere as this neatly |
43 |
> > resolves my network concern. |
44 |
> |
45 |
> Mmmh. Maybe I wasn't clear; in your case, it seems that |
46 |
> iproute2+OpenRC *is* your network manager. |
47 |
> |
48 |
> Perhaps at some point networkd will gain the ability to use iproute2 |
49 |
> (or even absorb it), but right now is only for tiny little setups. |
50 |
|
51 |
The way systemd services handle network whatever "network manager" you |
52 |
enable is the last thing preventing me from using systemd on servers. |
53 |
Seting up manual advanced setups on systemd looks crappy (if even |
54 |
possible with the provided tools) compared to OpenRC. |
55 |
|
56 |
Notice that iproute2 is the default everywhere for long time, here. |
57 |
|
58 |
The OpenRC comprehensive configuration set for network management is |
59 |
actually what I would expect in systemd. |
60 |
|
61 |
<...> |
62 |
|
63 |
> Having a "network manager" doesn't necessarily means having a big |
64 |
> monolithic thing that sets up your network. If you use some |
65 |
> scripts+conf with iproute2 to set up your network, then *that's* your |
66 |
> network manager. |
67 |
> |
68 |
> The point of networkd (if I understand correctly), is that if you |
69 |
> *need* iproute2 (I don't have it installed in any of my machines), or |
70 |
> highly dynamic non-trivial network configurations, then networkd will |
71 |
> not be enough. |
72 |
> |
73 |
> And, by the way, someone make me notice that netctl is an Arch'ism, |
74 |
> and that the command-line front-end for networkd is actually |
75 |
> networkctl. |
76 |
|
77 |
Yes, it was taken from Arch in order to allow better network support for |
78 |
advanced configurations whitout requiring to write yet another tool. |
79 |
|
80 |
The thing is that I would expect systemd to handle the whole thing on |
81 |
its own (with the help of iproute2) so that services have nice |
82 |
grain-level dependencies. |
83 |
|
84 |
-- |
85 |
Nicolas Sebrecht |