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."
You sound like an idiot criticizing SystemD because it's the trendy thing to do. You probably have no idea how SystemD works, and I'd wager you would actually find it easier to use and more efficient. Saying that it integrates itself too far with your system is not a real answer, in fact it makes SystemD actually sound more useful. You are only saying it because you heard somebody else say it. It's just a slogan, not a real case against it.
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
Have you tried to run Debian 8 without systemd? Systemd-less laptop is not just usable anymore at least on XFCE; usb automount and anything related to gvfs is gone, laptop special keys (backlight, volume) do not work, etc.
> 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."
Kind of hard to do on Debian.
"apt-get install openrc" is hard???
Why are you trolling? Debian might BE switching to systemd, but it is still optional in Jessie, all the other init systems still work.
Besides systemd is modular, you only need to install the modules you want and need.
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
SystemD is not replacing iptables, all they have done is integrate with iptables. Systemd's approach to configuring init "scripts" is superior (no really, it is) but it means that you can't just issue a straight "iptables -t nat..." command and instead have to call it via IPForwarding=yes and IPMasquerade=yes - unless of course you want to start a script with a unit file but then are you sure that iptables is up? Is the filesystem for the script up?
I don't know why I even bother reading the Slashdot comments about SystemD as they always lack critical thinking and instead prefer to cite hyperbole and FUD.
You might want to read this post from a few years ago when the GNOME and GTK 3.x were replacing thir 2.x branches. Of particular interest is the quotes of Allan Day (GNOME dev and RedHat employee):
So not only is this about enforcing a monoculture, the reason to enforce a monoculture is because the desktop isn't about getting work done. No, the desktop - according to GNOME - is for branding/advertizing.
*sigh*
While we're on the subject, I recommend everybody read this post by the same author. It's speculative, but it does explain a lot of what has been happening to linux over the last few years... and how it may fit into the large picture.
Ce n'est pas une signature automatique.
He's listening to you about the same amount as you know have read about systemd. Which is to say zero, nothing, not at all, as continued by your regurgitated lie about systemd being bloated running in PID1.
Each systemd component is actually quite small.
Only one component and one of the smallest components runs as PID1.
Now please STFU until you actually have used systemd.
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)
1. "What the hell is with these new commands? Great, now I have to learn a whole new way of administration cause people had to change something that was never broken."
2. "Where's all the init files? How am I supposed to configure anything? I don't have time for this..."
3. "Everything is done with service descriptors? Okay..."
4. "So wait, I no longer have to write massive shell scripts that manage the entire process lifecycle, or scour google in the hope that someone else has already written said script so I don't have to?"
5. "Wow, I never realized how much I hated dealing with init scripts until I didn't have to anymore. This is SO much cleaner!"
6. "Whoa, I can monitor and control entire *heirarchies* of dependant services from one command? That's pretty damn slick..."
I still don't completely understand systemd, but now that I'm getting a handle on it, I find it conceptually and functionally cleaner, and more rigorous than the old init system. The downsides are that it's new and therefore has a learning curve, and that it blackboxes the actual service controller which is going to piss off anyone with an ounce of control-freakery in them.
Even worse, try requiring LDAP (not just making it an option when an account isn't found locally, actually requiring it) for logins on a system booting via SystemD. Have your recovery media handy, you'll have to boot from it in order to remove the LDAP requirement when SystemD can't su because the network isn't up yet (or, if the LDAP server is localhost, slapd hasn't started because, guess what, it needs to su to its configured user during its init process).
What is this nonsense ? I use LDAP since before adopting systemd in 2009, and I never had any of these problems on my own made Linux systems. /etc/passwd contained only root and messagebus accounts (now it also has the new systemd accounts).
Are you implying distributions are even worse than when I quit using them in 2000?
Are you implying that distribution maintainers are incompetent?
What I'm sure is that it's a distribution problem, not a systemd problem. I never had the problem you describe which doesn't even make sense, even before I used sssd, and my
And my systemd systems work just fine even when network is not up yet, localhost is always there and slapd as well as sssd listen on it.
Major issue affecting Ubuntu and, as far as I know, all Debian-based systems. The workaround should be simple: allow local account logins right up until TTYs actually become available, regardless of configuration. But, apparently, LDAP isn't considered important, so this has been an issue for as long as Debian has used SystemD and will likely remain so until Debian moves on to something else.
This is BS, I can't even believe Debian and Ubuntu maintainers are so bad, where's the bug report ?
The current "recommended" workaround is a pair of ifup/down scripts that requires LDAP when the interface is up and makes it optional when it interface is down, which is great until your system crashes or you lose power and the "optional" config doesn't get applied. Then, it's time to whip out the recovery media so you can manually change the config and have a bootable system again. Needless to say, I refuse to implement that hack of a fix.
So this must actually be a bug tied to sysv compatibility, as you're talking about these broken ifup/ifdown scripts.
Granted, I instantly moved to full systemd configuration, it's not so easy for a distribution. Most of their problems seem to come from the compatibility layer.
sysvinit scripts are so insane, I can't blame them for having problems with them. Surely it makes them maintainers push forward to quit using these sysvinit scripts as soon as possible, even faster than before.
CP/M, which ran on 8-bit Intel and Zilog chips, and was (I think) much of the inspiration for QDOS (that became MS-DOS), had a multiprocessing version called MP/M. I never used it, and never read reviews, but the commands were printed on the CP/M command cheat sheet I bought.
Knowing the power and capabilities of 8-bit processors, I suspect it was less than satisfactory in use.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes