Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Debian Networking Open Source Linux

SystemD Gains New Networking Features 553

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.
This discussion has been archived. No new comments can be posted.

SystemD Gains New Networking Features

Comments Filter:
  • Fuck Me (Score:5, Interesting)

    by MightyMartian ( 840721 ) on Wednesday January 14, 2015 @06:34PM (#48814763) Journal

    Christ almighty, this beast is a fucking monster. What's next, a shell and a userland?

    Glad I'm heading to FreeBSD. Linux is going down the tubes.

    • Re: Fuck Me (Score:5, Funny)

      by chill ( 34294 ) on Wednesday January 14, 2015 @06:35PM (#48814775) Journal

      Shell and userland? What do you think it is, Emacs?

    • Re:Fuck Me (Score:5, Informative)

      by Trepidity ( 597 ) <`delirium-slashdot' `at' `hackish.org'> on Wednesday January 14, 2015 @06:40PM (#48814831)

      You might be surprised to find that FreeBSD's jails have their own network-virtualization features too.

      • Re:Fuck Me (Score:5, Insightful)

        by MightyMartian ( 840721 ) on Wednesday January 14, 2015 @06:41PM (#48814847) Journal

        I'm sure they do. But FreeBSD doesn't have a massive init system intruding itself into every single aspect of the operating system.

        Just what the fuck is SystemD supposed to be?

        • Re:Fuck Me (Score:5, Informative)

          by phantomfive ( 622387 ) on Wednesday January 14, 2015 @06:49PM (#48814919) Journal

          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 [youtube.com].

          • Re: (Score:3, Insightful)

            by lgw ( 121541 )

            Ahh, so it's ripping off Windows' Service Control Manager, a.k.a. "scum". This will certainly end well.

          • Re:Fuck Me (Score:4, Insightful)

            by bytestorm ( 1296659 ) on Wednesday January 14, 2015 @07:34PM (#48815227)

            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.

            The task you have described seems like something that could be sanely done outside pid1 without worrying that a defect in its significantly larger-than-average-init codebase could cause the entire system to reboot.

            Though I guess some might consider that a feature; at least you know you'll never be running without systemd.

            • Re:Fuck Me (Score:5, Informative)

              by Trepidity ( 597 ) <`delirium-slashdot' `at' `hackish.org'> on Wednesday January 14, 2015 @08:49PM (#48815711)

              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 [freedesktop.org], plus a third-party comment here [lwn.net].

            • Re:Fuck Me (Score:5, Insightful)

              by Anonymous Coward on Wednesday January 14, 2015 @09:59PM (#48816115)

              Or the echo chamber could be wrong about PID 1.

              Like all great lies, it includes a bit of truth:

              1. More lines of code equals more bugs.
              2. The systemd project has lots of lines of code.
              3. PID 1 must be super reliable or bad things will happen.

              So far so good right? Stay tuned for the lie:

              4. All of systemd is in PID 1. Therefore systend's PID 1 must be buggy and dangerous.

              It's about as right as including Bash's line count in a discussion about sysvinit PID1. But don't take my word for it. Echo on bro.

        • Re:Fuck Me (Score:5, Informative)

          by Trepidity ( 597 ) <`delirium-slashdot' `at' `hackish.org'> on Wednesday January 14, 2015 @06:55PM (#48814971)

          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 [bsdstore.ru]. That has some pros and cons as well.

          • 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.

            But you can literally manage cgroups with a few simple commands. I know none of them because I never do it, but I looked up just how it's done and at least one of my earlier comments here on the dot will give you specifics, if you can find it. Obviously, it was part of a rant against systemd.

            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

            The former of which is hated by all, and the latter of which is hated by most.

        • Re:Fuck Me (Score:5, Funny)

          by sexconker ( 1179573 ) on Wednesday January 14, 2015 @07:41PM (#48815293)

          I'm not sure, but it will soon have an email client/server and the ability to publish PDFs.

        • Just what the fuck is SystemD supposed to be?

          An all in one system management daemon intruding on the init system.

          To think of it the other way is to ignore everything about the project including all the project pages and project descriptions. No one who works on systemd considers it an init system. Only Slashdot users do.

    • Re:Fuck Me (Score:5, Informative)

      by mlts ( 1038732 ) on Wednesday January 14, 2015 @06:49PM (#48814909)

      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.

      • Re:Fuck Me (Score:4, Insightful)

        by by (1706743) ( 1706744 ) on Wednesday January 14, 2015 @07:48PM (#48815345)

        Parallel startup?

        And even this is -- in my experience -- terrible on systemd. My admittedly-"old" (2009-era i7 laptop), with systemd, will sit at a (text-only) login screen for 10 seconds or so before it's responsive (type username, hit enter, password displays in cleartext because the "password:" prompt hasn't even shown up). Meanwhile, the disk is whirring away trying to start Postgres, etc. So yeah, you technically got me my login prompt nice and fast, but it's completely useless.

        And, like you said, I don't reboot my laptop much (that's what suspend-to-RAM is for...), and my desktop/server just stays on all the time.

        • Re:Fuck Me (Score:5, Interesting)

          by BronsCon ( 927697 ) <social@bronstrup.com> on Wednesday January 14, 2015 @08:48PM (#48815703) Journal
          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).

          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.

          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.

          Instead, I ended up leaving LDAP optional, with a single user able to sign in, locally only, who can only su, and a local admin account that can only sudo and su, but can't log in. At least that minimizes the risk of not being able to unilaterally change either user's password across multiple systems in a timely manner; an attacker knowing the password for the user who can log in locally would have to be at the machine, and they still couldn't do anything without also knowing the username and password of the user who can sudo+su. In the end, I guess I get the benefit of being able to log in to said machines even when the LDAP server is unavailable, but it still shouldn't be necessary to implement such workarounds.
      • Re:Fuck Me (Score:4, Interesting)

        by allfieldsrequired ( 3886123 ) on Wednesday January 14, 2015 @10:21PM (#48816229)

        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.

        Thank you, these are pretty much exactly my thoughts as well. I am very happy that all the systemd people have found a project to be productive in, and I appreciate some of the things they are trying to do. However, I run a large server farm, I don't need any containers, I don't need parallel boot, and so far, I have seen that they are highly adept at politicking their way into acceptance by various mainstream distro's as a default, and sometimes only init system.

        I recently had to recompile Nginx on Ubunty Trusty in order to add some module, and this broke due to an unsatisfied systemd library dependency. Wait, what? Nginx now magically needs to be linked to systemd to compile? The madness is complete in my eyes.

        I have since started playing around with Alpine Linux, which is a breath of fresh air in many ways, and barring any unforeseen issues, we will probably slowly migrate our fleet to Alpine. I resent the fact that I am forced to divert time, effort, and resources away from our jobs to deal with this shit. Part of my motivation in using Linux extensively is freedom of choice. The choice to go and roll my own distro isn't the kind of choice I signed up for though. Ubuntu was mostly nice, mostly functional, mostly stable and has mostly up to date packages for everything I need. With Debian, and so Ubuntu, chosing SystemD as a default, and especially looking at all the acrimony surrounding the issue in Debian, I am very fucking worried about where Linux is going to go in the next few years.

        I wish I had more time to get into BSD....

    • by Anonymous Coward on Wednesday January 14, 2015 @06:58PM (#48814989)

      Systemd is truly the best thing that has ever happened to the BSD community.

      Systemd alone is making Linux totally unsuitable for serious use. So what are people doing when a formerly-stable distro like Debian adopts systemd and becomes a disaster? They're moving to FreeBSD, OpenBSD, NetBSD, Dragonfly BSD and PC-BSD.

      Just today we find out that DigitalOcean now supports FreeBSD [digitalocean.com]. There's clearly a very bright future ahead for the BSDs.

      And it's clear now that Linux is on its way out. While Linux and Linux systems will still be around for some time, of course, everyone important who made Linux great in the past is fleeing from it. We're moving to BSD, because unlike the Linux community, the BSD community does things right. Something like systemd would never be taken seriously by them.

      • Checking out your link, it says that DigitalOcean is 'unique in that the development of both its kernel and user space utilities are managed by the same core team, ensuring consistent development standards across the project.' In short, it has little to do w/ systemd and more to do w/ the kernel and userland coming together, rather than one part made by Linus and another by GNU.
      • by Aighearach ( 97333 ) on Wednesday January 14, 2015 @11:40PM (#48816651) Homepage

        I hope so, it is always nice for a big group of haters to have a mass-migration. It is a lot healthier than to stay and whine. Those that leave can enjoy their greener grass, and those that stay have them off the lawn. Everybody wins.

        If you hate systemd, don't use it. Problem solved!

    • by dissy ( 172727 )

      Christ almighty, this beast is a fucking monster. What's next, a shell and a userland?

      According to the slashdot editors, the next thing is clearly debiand!

      Apparently it is to be the systemd module which uses the Debian logo/filter on front page /. articles to clearly indicate a story about generic linux software made by a guy at redhat that emulates behavior in microsoft windows...

      After that they will install the new shutupd module, that does nothing but write "Woah slow down there cowboy, you last posted 140*10^12 minutes ago, try again later to give others a chance" to stdout - before repe

  • systemd... (Score:5, Insightful)

    by aardvarkjoe ( 156801 ) on Wednesday January 14, 2015 @06:40PM (#48814835)

    systemd seems dead set on becoming an alternative operative system.

    Which wouldn't be a bad thing if it wasn't ruining perfectly good operating systems like Debian while it grows.

    I've stuck with Debian for a pretty long time (since around 2000) mostly because I know how everything works. But in the last year running testing, more and more frequently I'll find that something has been yanked out and replaced by something harder to use and understand. Maybe it's finally time to switch to BSD instead.

    • I'm already heading out the door. New database server is FreeBSD, and probably our Postfix relays within the next couple of months. Routers will stay Linux for a while, I suppose, but that will be about it.

  • by MikeTheGreat ( 34142 ) on Wednesday January 14, 2015 @06:42PM (#48814851)

    Y'know, for all it's flaws, warts, and Dice-y-ness, I think it's a good sign that the clickbait here is stuff about systemd.
    Seriously - on other websites they'll drive up pageviews by posting something like "This just in: politicians you disagree with are EVIL!! EEEEEEVIIIIIL!".

    What whips up the /. crowd into a frothy frenzy?
    Systemd :)

  • by Russ1642 ( 1087959 ) on Wednesday January 14, 2015 @06:43PM (#48814859)

    Samsung is coming out with a new line of phones that run SystemD instead of Android.

  • I'm sticking with OpenBSD. At least with that OS, features are well thought out and not jammed into every release because "it's teh l337!"
  • by Anonymous Coward on Wednesday January 14, 2015 @06:46PM (#48814881)

    What the hell is happening to the Linux ecosystem?

    I've been a user of it for a couple of decades now. Although it wasn't perfect, for years it provided a better environment for me than Windows or even OS X could provide.

    But that's really started to change maybe within the past 5 years. The first major debacle I can think of is GNOME 3. They went out of their way to ignore everything good about GNOME 2, and instead forced all sorts of stupid ideas upon us.

    Firefox is the next debacle I can think of. It's a lot like GNOME 3 in many ways. There was a good, reliable, usable browser in Firefox 3.5. Then it all went to hell in Firefox 4 and beyond.

    Now we have systemd, which is obviously dumb in pretty much all respects. It just doesn't fit within the Linux ecosystem at all. That's probably why it's so disruptive.

    What makes systemd worse, though, is the impact it has had on pretty much all of the major Linux distros. Pretty much all of the most usable and useful ones (sorry, Slackware, this excludes you) have switched to it, with horrible results.

    The stability of my Debian testing system has gone down the shitter since they switched to systemd some time ago. I've had more problems properly booting my system in the past six months than I had in the 15 years prior to systemd getting installed.

    I'm torn at this point. I'm probably going to buy a Mac and move to OS X for my personal system, while moving all of my servers over to FreeBSD as soon as I can. I'm pretty sure that I'm done with Linux at this point. I just don't think the ecosystem can be salvaged. So much good software has been ruined.

    • by sjames ( 1099 )

      The common thread seems to be freedesktop.org. Beware of anything that comes from there.

    • by amiga3D ( 567632 ) on Wednesday January 14, 2015 @08:00PM (#48815409)

      I think they intend to bring stability and unity to Linux by eliminating modularity and choice.

  • by Anonymous Coward on Wednesday January 14, 2015 @06:47PM (#48814897)

    When the only tool you have is a hammer, every problem is a nail.

    Noob coders who simply throw more and more code and "problems" are a perfect example. They don't know when to stop coding up solutions in search of problems.

    Systemd devs are a perfect example.

    • I wish these asshats would go work for Microsoft or Oracle. Those companies deserve this diseased monolithic kind of project development.

  • I'm sure they'll get around to adding Emacs and NetHack functionality to it sooner or later...

  • by CrashNBrn ( 1143981 ) on Wednesday January 14, 2015 @07:30PM (#48815215)
    I asked a few months back now, about the possibility of BSD on Digital Ocean due to all of the SystemD shenanigans of late. Got an email notification today that FreeBSD droplets are now available on Digital Ocean. It will be interesting to see if other VPS/Linux providers follow suit.

    CB.
  • by the_B0fh ( 208483 ) on Wednesday January 14, 2015 @07:42PM (#48815303) Homepage

    /vmlinuz /boot/bzImage /sbin/systemd /usr/bin/emacs -> /sbin/systemd

    You think I'm kidding... Here, in Lennart's own words:

    http://0pointer.net/blog/revis... [0pointer.net]

    • by turbidostato ( 878842 ) on Wednesday January 14, 2015 @10:09PM (#48816179)

      "Here, in Lennart's own words"

      No, *this* are Lennart's own words:
      let's summarize what we are trying to do:
      * We want an efficient way that allows vendors to package their software
      * We want to allow end users and administrators to install these packages on their systems, regardless which distribution they have installed on it.
      * We want a unified solution that ultimately can cover updates for full systems, OS containers, end user apps, programming ABIs, and more.
      * We want our images to be trustable (i.e. signed). In fact we want a fully trustable OS

      So my reading is: we want Linux ecosystem to disappear and be substituted by Microsoft's business model where there's just one OS (Red Hat) and a set of corporate software vendors.

  • by thatkid_2002 ( 1529917 ) on Wednesday January 14, 2015 @09:00PM (#48815783)

    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.

    • We who have critical thinking skills don't hate systemD for any alleged replacement of iptables. Its poor design, bugs and errant execution are enough reason. There is the kind of person with high IQ who has no common sense and so cannot make anything of practical value in the real world, instead floundering around making rube goldberg contraptions of needless complexity; such are the SystemD developers.

      • I always thought there was a kind of natural selection happening in the linux world.

        If systemD is so bad, how is it now the standard in pretty much every distro? It must serve some purpose. On the other hand, complaining about it seems to serve no purpose at all. If the teams who put together every distro thought this way, they wouldn't have used it. No doubt there are some distros that don't use it.

        I just don't see the point in all of these complaints. What good does it do?

        The existing systems must be infe

        • by guruevi ( 827432 ) <evi@noSpaM.smokingcube.be> on Wednesday January 14, 2015 @10:57PM (#48816421) Homepage

          systemd is fine if you don't want to fiddle with anything. It is great for the current cloud/virtualization hype because it doesn't use arcane text files which are different for each daemon but rather everything is uniformly structured so you can spin up entirely self-automated datacenters with a few presses of a button in a web interface. If you want to change your hostname, you issue a command and everything that supports systemd now has your new hostname.

          However if it breaks, it is bad. Things are a mess for humans to read or change, it seems to be entirely built to be used in purpose-built GUI's and web interfaces. It has or will become the registry of Linux. If you want to use something that's not systemd-aware you're either stuck encapsulating old scripts in systemd scripts or building an entire infrastructure of dependencies and requirements around the daemon.

        • by dbIII ( 701233 )
          Why do you think things are chosen by merit alone? Pulseaudio, NetworkManager, and the optical media writing fork were all options chosen when they had less functionality than the alternatives (as with the rewrite of gnome with deliberate breakage of gnome2 software - DLL hell on linux for the first time ever). It's "office politics" in the linux community that drives these things and not function. The people behind systemd are in an influential faction so this stuff is being pushed hard despite problems
    • by phantomfive ( 622387 ) on Wednesday January 14, 2015 @11:15PM (#48816521) Journal

      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.

  • by beaverdownunder ( 1822050 ) on Wednesday January 14, 2015 @09:23PM (#48815911)

    It annoys me that someone like Poettering, who only had PulseAudio come into use because of the ability distributions had to easily change core operating system components (and wouldn't have had the existing audio-subsystem been entrenched), would then proceed to develop something specifically intended to lock down its own existence and prevent its replacement by something else. It's hypocritical.

    While I totally understand why he did it -- nobody wants to put a great amount of time into something only to have it superseded -- it flies in the face of open source in general, where you contribute to an evolving 'thing', and that while your specific contribution may not exist in the future, you can be happy that you took part in the evolution of the whole, and not feel the need to stamp your face on it for perpetuity.

    It also sets a dangerous precedent. What's going to be locked down next, in the name of stability, or speed, or whatever else (when it's really about someone trying to 'make their mark'?) Do we lock down the file system? Only one file system for Linux, full stop? Do we lock down the network transports? The window manager? The terminal? The command-line applications?

    Then what? Do we then create a global committee, made up of people who maintain the existing components (of course), to make decisions about those components and whatever's left into the future?

    I mean, yes, I agree in that case something else will surely (and quickly) rise in Linux's place (I mean, who wants to put in the time to help projects who only exist to serve their creator's vanity) but it seems a shame that Linux should end this way.

  • by ilsaloving ( 1534307 ) on Thursday January 15, 2015 @10:37AM (#48819159)

    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.

Dynamically binding, you realize the magic. Statically binding, you see only the hierarchy.

Working...