On Tue, Jul 24, 2012 at 7:44 PM, David Benfell
<benfell@xxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Because it's summer, and I'd really rather not try to figure all this
> out during the school year, I'm trying to figure out systemd *now*,
> rather than waiting until rc.conf goes away.
>
> I actually had trouble with rc.conf when I first installed Arch on my
> Linode. Some daemons mysteriously wouldn't start and I couldn't figure
> out how to get the networking to come up properly. (And, of course, I
> was in a hurry.) So I wound up hacking rc.local to bring up both the
> network and the daemons. (Yes, I know: ewwwww!)
>
> This is the shell snippet I'm using to bring up my network now:
>
> rc.d start network #successfully gets some address and a route
> for i in 74.207.225.79/32 74.207.227.150/32 173.230.137.73/32
> 173.230.137.76/32
> do
> ip addr add "${i}" dev eth0
> done
> ip -6 addr add 2600:3c02::f03c:91ff:fe96:64e2/64 dev eth0
> for j in $(seq 0 1)
> do
> for i in $(seq 0 9) a b c d e f
> do
> ip -6 addr add "2600:3c02::02:70${j}${i}/64" dev eth0
> done
> done
>
> Basically, with the IPv4 address, my intent is to make sure I've got
> all four of those addresses up. But I wasn't getting a route unless I
> used the network start script.
>
> In my copy of the Arch wiki, I"m not seeing how to do something
> similar under systemd. How, ideally, should I be doing this?
>
> Thanks!
hi David,
i've been prototyping the idea of a complete network management
solution driven purely by unit files (or a generator) ... i don't have
a general solution, but i use the following to handle a common case --
perform DHCP on an interface when it is available, and tear it down
when it's not (disregard the `u.` [user] prefixes, i use them to
guarantee no-conflicts with upstream units):
# cat /etc/systemd/system/sys-subsystem-net-devices-wan0.device.wants/u.net.dhcp@wan0.service
=========================================
# network interfaces bindings
[Unit]
Description=[u] DHCP Interface [%I]
StopWhenUnneeded=true
Wants=network.target
Before=network.target
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
After=basic.target
[Service]
Type=simple
TimeoutSec=0
Restart=always
RestartSec=30
ExecStart=/usr/sbin/dhcpcd -C resolv.conf --nobackground --timeout 30 %I
[Install]
Alias=sys-subsystem-net-devices-wan0.device.wants/u.net.dhcp@wan0.service
=========================================
... notice the use of `BindTo` and how it's triggered by the presence
of the actual device. this is a `simple` service because it has an
actual process associated with it ... i also use a similar `oneshot`
unit for static devices that is closer to what you need:
# cat /etc/systemd/system/sys-subsystem-net-devices-lan0.device.wants/u.net.static@lan0.service
=========================================
# network interfaces bindings
[Unit]
Description=[u] Static Interface [%I]
StopWhenUnneeded=true
Wants=network.target
Before=network.target
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
After=basic.target
[Service]
Type=oneshot
TimeoutSec=0
Restart=always
RestartSec=30
RemainAfterExit=yes
ExecStart=-/usr/sbin/ip addr add 10.50.250.1/24 dev %I
ExecStart=/usr/sbin/ip link set %I up
[Install]
Alias=sys-subsystem-net-devices-lan0.device.wants/u.net.static@lan0.service
=========================================
... take particular notice of multiple `ExecStart` directives --
`oneshot` type units allow for several commands to be executed
sequentially, and the unit fails if any command fails (use
`ExecStart=-[...]` to ignore the return code of one command, note the
dash). you could use this last unit as a base, then add all of your
commands to it, one after the other. note how i ignore the result of
the `ip addr add` because the address might already exists (couldn't
find a cleaner way to handle this).
that said, i'm not sure systemd is really intended to handle these
things directly, but in simple cases it seems to work pretty good --
i've used the DHCP unit file on 3 physical servers and 5 virtual
machines for about 18 months now, without issue.
HTH,
--
C Anthony
