On Mon, 11 May 2015 22:37:40 +1000, Russell Stuart <russell-deb...@stuart.id.au> wrote: >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.
Of course you can do that with /e/n/i, it's just clumsy and manual. >> [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. In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. End systems with privacy extensions enabled will automatically allocate an (additional?) random IP address and change it after a given amount of time. IP address change happens by first configuring the new address and then deprecating, but not deconfiguring, the old IP address. A deprecated IP address is not used for new connections, but allows already existing connections to live. >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. As far as I know, this is not yet implemented, but systemd as a central daemon with dbus and other links is predestined to take care of IP address changes as well. Unfortunately, it does not yet have appropriate hooks, but I guess that it will advertise interfaces and addresses coming and going via dbus so that third party software can act on those events. I have never actually tried that and am not familiar enough with dbus to even look what's happening here. >> 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. It cannot do that, no. It doesn't need to. Manual configuration can still be done from a regular systemd unit or old fashioned /e/n/i. Afaik, it only acts on interface it can find configuration for, so you're free to have it ignore interfaces you want to handle manually. >(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. the systemd people are working hard to eliminate scripts from system administration. Hence they're quite reluctant to add interfaces to plug new scripts into. This is indeed one of the biggest turn-offs with systemd for me. >> 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. systemctl status apache2 said what in this situation? >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*. Don't take anything I said for granted. I only have a few weeks of systemd experience. I don't like it too much, but it's unavoidable so one better learn to know it. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrqbi-0000mb...@swivel.zugschlus.de
