On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
> For example, it doesn't know dependencies between Interfaces, which is
> rather common for a server jockey (consider a VLAN on a bridge which
> is connected to the network via a bonding device)
I haven't had to solve that example, but I have had a problem again
involving bridges that sounds similar. It was solvable with ifup/down -
by calling ifup in the /etc/network/interfaces pre-up. I'll grant you
it's not pretty, but I've only had to do it once so I forgive aj.
> [ifupdown] it doesn't handle IP addresses that come and go
> at run time (as it is to be expected on IPv6 networks).
Could you explain when IPv6 addresses come and go? You are talking to a
IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do
come and go. It's true that isn't handled by ifupdown, but that's not a
problem because if you want to do something about it, you do it in the
dhclient hook. It seems the right place to me.
That aside, I don't see anything in "man systemd.network" that allows
you to watch for IPv6 addresses coming and going, or for that matter
anything else coming and going except devices.
> And, when it comes to scriptability and flexiblity, systemd-networkd
> is vastly superior. It was made with a server in mind.
This para is the real reason I'm responding. I must be missing
something, because nowhere in "man systemd.network" do I see to a way to
run a script of any sort. For me the acid test is "can it do totally
manual configuration", ie the equivalent of ifupdown's "manual" method.
(I occasionally use manual - it's a great way of ensuring there are no
surprises.) systemd.network's [Match] section combined with the sort of
demonstrated by ifupdown's manual method would be a match made in
heaven. But if it exists I've missed it. You could perhaps emulate it
if it were possible to make a systemd.service depend on a
systemd.network, but that appears to be right out of scope. As it
stands, networkd looks to be one of the least scriptable networking
configuration options I've seen since ... oh redhat 7.0 or so.
> Otoh, it is much harder to debug, extend and modify than ifupdown,
> which has a _very_ flexible script interface.
Up until recently I thought the systemd mob had solved the "visibility"
problem by logging everything written to stdout and stderr with
journald. I was disabused of that notion just this weekend, when
apache2 failed to start after an apt-get dist-upgrade. journalctl -xn
helpfully told me:
$ ssu journalctl -xn
-- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 22:22:42 AEST. --
May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control process exited, code=exited stat
May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 web server.
-- Subject: Unit apache2.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit apache2.service has failed.
--
-- The result is failed.
Which is about as useful as a hip pocket in a singlet. In the end this
told me what was going on:
$ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start
[FAIL] Starting web server: apache2 failed!
[warn] The apache2 configtest failed. ... (warning).
Output of config test was:
apache2: Syntax error on line 141 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/mods-enabled/php5_cgi.conf: No such file or directory
Action 'configtest' failed.
The Apache error log may have more information.
Having to troll through scripts in /var/lib/lsb in order to figure out
how to disable the systemd redirect in order to see the error message
the sysV init script sent to stdout is NOT an improvement. (The Apache
error log was empty.)
If debugging networkd stuff is harder, then ... *shudder*.
Attachment:
signature.asc
Description: This is a digitally signed message part