My current issues with systemd's networkd in Fedora 21
On the whole I'm happy with my switch to
I made for reasons covered here; my networking
works and my workstation boots faster. But right now there are some
downsides and limitations to networkd, and in the interests of equal
time for the not so great bits I feel like running down them today.
I covered some initial issues in my detailed setup entry; the largest one is that there is no syntax
checker for the networkd configuration files and networkd itself
doesn't report anything to the console if there are problems.
Beyond that we get into a collection of operational issues.
What I consider the largest issue with networkd right now is that
it's a daemon (as opposed to something that runs once and stops)
but there is no documented way of interacting with it while it's
running. There are two or three sides to this: information, temporary
manipulation, and large changes. On the information front, networkd
exposes no good way to introspect its full running state, including
what network devices it's doing what to, or to wait for it to
complete certain operations. On the temporary manipulation front,
there's no way I know of to tell networkd to temporarily take down
something and then later bring it back (the equivalent of
ifup). Perhaps you're supposed to do those with manual commands
outside of networkd. Finally, on more permanent changes, if you add
or remove or modify a configuration file in
and want networkd to notice, well, I don't know how you do that.
Perhaps you restart networkd; perhaps you shut networkd down, modify
things, and restart it; perhaps you reboot your machine. Perhaps
networkd notices some changes on its own.
(Okay, it turns out that there's a
that queries some information from networkd, although it's not
actually documented in the Fedora 21 version of systemd. This still
doesn't allow you to poke networkd to do various operations.)
This points to a broader issue: there's a lot about networkd that's
awfully underdocumented. I should not have to wonder about how to
get networkd to notice configuration file updates; the documentation
should tell me one way or another. As I write this the current
systemd-networkd manpage is
a marvel of saying very litte, and there's also omissions and lack
of clarity in the manpages for the actual configuration files. All
told networkd's documentation is not up to the generally good systemd
The next issue is that networkd has forgotten everything that systemd
learned about the difference between present configuration files
and active configuration files. To networkd those are one and the
same; if you have a file in
/etc/systemd/network, it is live.
Want it not to be live? Better move it out of the directory (or
edit it, although there is no explicit 'this is disabled' option
you can set). Want to override something in
I'm honestly not sure how you'd do that short of removing it or
editing it. This is an unfortunate step backwards.
(It's also a problem in some situations where you have multiple
configurations for a particular port that you want to swap between.
In Fedora's static configuration world you can have multiple
files, all with
ONBOOT=no, and then
ifdown them as
you need them; there is no networkd equivalent.)
I'm not going to count networkd's lack of general support for 'wait
for specific thing <X> to happen' as an issue. But it certainly
would be nice if
systemd-networkd-wait-online was more generic
and so could be more easily reused for various things.
I do think (as mentioned) that some of
networkd's device and link configuration is unnecessarily tedious
and repetitive. I see why it happened, but it's the easy way instead
of the best way. I hope that it can be improved and I think that
it can be. In theory I think you could go as far as optionally
.link files with
.network files to
cover many cases much simpler, as the sections in each file today
basically don't clash with each other.
In general I certainly hope that all of these issues will get better over time, although some of them will inevitably make networkd more complicated. Systemd's network configuration support is relatively young and I'm willing to accept some rough edges under the circumstances. I even sort of accept that networkd's priority right now probably needs to be supporting more types of networking instead of improving the administration experience, even if it doesn't make me entirely happy (but I'm biased, as my needs are already met there).
(To emphasize, my networkd issues are as of the state of networkd in Fedora 21, which has systemd 216, with a little bit of peeking at the latest systemd 219 documentation. In a year the situation may look a lot different, and I sure hope it does.)
My Linux container temptation: running other Linuxes
We use a very important piece of (commercial) software that is only supported on Ubuntu 10.04 and RHEL/CentOS 6, not anything later (and it definitely doesn't work on Ubuntu 12.04, we've tried that). It's currently on a 10.04 machine but 10.04 is going to go out of support quite soon. The obvious alternative is to build a RHEL 6 machine, except I don't really like RHEL 6 and it would be our sole RHEL 6 host (well, CentOS 6 host, same thing). All of this has led me to a temptation, namely Linux containers. Specifically, using Linux containers to run one Linux as the host operating system (such as Ubuntu 14.04) while providing a different Linux to this software.
(In theory Linux containers are sort of overkill and you could do most or all of what we need in a chroot install of CentOS 6. In practice it's probably easier and surer to set up an actual container.)
Note that I specifically don't want something like Docker, because the Docker model of application containers doesn't fit how the software natively works; it expects an environment with cron and multiple processes and persistent log files it writes locally and so on and so forth. I just want to provide the program with the CentOS 6 environment it needs to not crash without having to install or actually administer a CentOS 6 machine more than a tiny bit.
Ubuntu 14.04 has explicit support for LXC with documentation and appears to support CentOS containers, so that's the obvious way to go for this. It's certainly a tempting idea; I could play with some interesting new technology while getting out of dealing with a Linux that I don't like.
On the other hand, is it a good idea? This is certainly a lot of work to go to in order to avoid most of running a CentOS 6 machine (I think we'd still need to watch for eg CentOS glibc security updates and apply them). Unless we make more use of containers later, it would also leave us with a unique and peculiar one-off system that'll require special steps to administer. And virtualization has failed here before.
(I'd feel more enthused about this if I thought we had additional good uses for containers, but I don't see any other ones right now.)