Slashdot Mirror
SystemD Gains New Networking Features
jones_supa writes A lot of development work is happening on systemd with just the recent couple of weeks seeing over 200 commits. With the most recent work that has landed, the networkd component has been improved with new features. Among the additions are IP forwarding and masquerading support (patch). This is the minimal support needed and these settings get turned on by default for container network interfaces. Also added was minimal firewall manipulation helpers for systemd's networkd. The firewall manipulation helpers (patch) are used for establishing NAT rules. This support in systemd is provided by libiptc, the library used for communicating with the Linux kernel's Netfilter and changing iptables firewall rulesets. Those wishing to follow systemd development on a daily basis and see what is actually happening under the hood, can keep tabs via the systemd Git viewer.
You might be surprised to find that FreeBSD's jails have their own network-virtualization features too.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I've already had it fail to boot on one system and fail to shut down on another. It failed to unmount disks because they were "in use" by systemd, and this resulted in filesystem corruption on the hard power-off.
I try to stay out of the systemd fray... but it goes against the core of UNIX... which is the KISS principle.
Init should start tasks, possibly stick them into jails or containers, and set resource limitations. Having something do everything including the kitchen sink is just asking to get hacked down the road unless millions of dollars are spent on source code audits.
As an IT person, results are important. What does systemd provide that previous mechanisms didn't. Parallel startup? I don't boot servers that often where asynchronous startup of processes is a big issue. Resource limits? Doable with the shell script that gets plopped into /etc/rc.d. I'm just not seeing the benefit, but what I am seeing is a gigantic amount of code which touches the entire system, giving me concerns about security and stability, and there have been a number of articles on /. about systemd, to the point where people are even forking distros just so they don't have to deal with it.
Routers are probably the first thing you want to change. I don't use FreeBSD, but it features zero copy networking for insanely fast routing, which Linux does not.
Be relentless!
Just what the fuck is SystemD supposed to be?
A services manager, actually. It starts and stops services on the system, and if they go down, it optionally restarts them. The fact that many services need to start when the system starts is somewhat incidental to the purpose of systemD.
On top of the services manager, they've built a lot of services. Here is the video that explains launchD, which is heavily copied by systemD.
"First they came for the slanderers and i said nothing."
It's a process supervisor / service management system. Booting the machine isn't really the most difficult job of such a system, just the special case of starting some things on boot. More of the work goes into the non-boot case, and at the moment a lot of interest is in container-based virtualization. The kernel cgroups system provides the basic primitives for building such systems: hierarchical process groups, resource limits, etc., but you need a userspace layer to make it usable, e.g. managing creation/destruction of containers (and their associated networking, resources, etc.). Systemd is the userspace layer.
There are fairly similar approaches in other Unixes, though with pros and cons. Solaris uses SMF, and OSX uses launchd, both of which replaced more old-school shell-script-based systems for similar reasons. FreeBSD has toyed on and off with porting launchd from OSX, but the porting effort stalled. For the moment it relies on a more "DIY" solution where it's up to the sysadmin to maintain a tangle of shells scripts plugging things together, e.g. integrating jail management with resource constraints (RCTL), services, and networking. All the pieces are there, but either you write your own shell scripts to glue them together, or you can use something like cbsd. That has some pros and cons as well.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
> Why do you care how other people build their Linux systems?
I don't. If Poettering and company had simply forked GNOME Lenna-X off of GNU Linu-X, there wouldn't be all this complaining. The problem is that Poettering and company have hijacked mainstream linux that almost all linux users use and changed it into something unrecognizable. udev is now built into systemd. The "udev install process" on Gentoo consists of building systemd, but only installing the udev portion. That's why the eudev fork. And some people are running with busybox/mdev in place of udev.
Then there's also dbus, which is being rammed into the kernel. Gnumeric was a great spreadsheet a couple of years ago. But now it's picking up GNOME dependancies all over the place, including dbus. And Skype now requires PulseAudio, another piece of crud from Lennart.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
No, it's not, you're wrong. It's ripping off OSX's launchD. He's an Apple copier, not a Microsoft copier (and as far as system design goes, that is much, much better; launchD is infinity times cleaner than Service Control Manager).
"First they came for the slanderers and i said nothing."
Apparently, you're the idiot, because the fact that systemD integrates itself so closely with my GNU^H^H^HSystemD/Linux as PID 1
The features discussed by this article aren't implemented in a program that runs with a PID of 1.
I wish a different name had been chosen for the project that includes, as one of its components, an init daemon named "systemd"; it probably would have avoided some bad press and confusion.
Perhaps those other components were designed under the assumption that the daemon named "systemd" would start them, tying them to that daemon, so maybe that's the rationale for calling the project "systemd" (or "SystemD").
Putting it in pid1 is mostly driven by cgroups (the Linux kernel's hierarchical process-grouping/resource-management system). The initial kernel design for cgroups was that it was a shared resources managed via a pseudofilesystem (cgroupfs), but the developers of that subsystem seem to have decided that design was unworkable, and are moving towards a design where there can be exactly one userspace controller of the cgroups system at any given time. That more or less has to also be the process supervisor, or else you can't really do sensible things with tying resource-management to services (and increasingly, containers). And that all has to happen when the system is brought up, too. So either it needs to be in PID1, or it needs to be in several PIDs that are tightly coupled via an IPC mechanism. The systemd designers consider the second design more complex and error-prone. See e.g. here, plus a third-party comment here.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
unless of course you want to start a script with a unit file but then are you sure that iptables is up?
In all my time using Linux, wondering if iptables had crashed has never been a problem I've had. I've had lots of problems, but never that one. Same with filesystems. Fstab has always just worked.
And an extra layer in front of iptables is the last thing I need. That is a huge negative. I don't even understand why anyone would think that's a good idea.
"First they came for the slanderers and i said nothing."
It does have a built in logger that stores in binary but you can still have rsyslog running as per normal if you wish to configure it so you are not stuck with binary only logging. The binary logging is on operation long before rsyslog can be started and long after it finishes and its more comprehensive. Thats the lovely bit about configuration
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)