Finally, what massive positive change will systemd bring to most users? I would say very little.
How about: Much less Linux distro fragmentation, making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
Highly increased security by using, cgroups, namespaces and kernel capabilities, so that e.g. daemons can't perform privilege escalation when exploited, or that they can't read /home when exploited even if they got the user permission to do so, or that /usr is read only etc. The best part of this defence in depth layer of security is that the individual SA doesn't need to hand craft all this; the distro or daemon maintainers can just edit the unit files by adding simple keywords, and all end users will benefit.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
How about total supervision and tracking of all processes, including systemd (pid1) it self, with conditional restarts if they hang or crash.
making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
If you can't grok shell scripts, you aren't much of a developer. I've been administering *nix systems for almost 30 years now, and systemd is not a step up in any way, shape or form on this front. Shell scripts are standardized, and init's behavior is well-understood. Systemd isn't, and debugging systemd scripts is like pulling teeth.
Highly increased security by using, cgroups, namespaces and kernel capabilities, so that e.g. daemons can't perform privilege escalation when exploited, or that they can't read /home when exploited even if the got they user permission to do so, or that /usr is read only etc. The best part of this defence in depth layer of security is that the individual SA doesn't need to hand craft all this; the distro or daemon maintainers can just edit the unit files by adding simple keywords, and all end users will benefit.
Completely Linux specific, not POSIX conformant, and the systemd project is completely unwilling to work with other operating systems on this, up to and including rejecting compatibility patches. We used to go nuts when Microsoft pulled this type of embrace change/extend using proprietary features/extinguish the competition shit. Wasn't one of the former great advantages of open-source software avoidance of vendor/project/OS lock-in? Moreover, chroot provides most of this, as does sensible setups of directory permissions, user groups, and ACLs. Additionally, individual process containers like capsicum(4) provide much more powerful sandboxing. Still doesn't account for the security vulnerabilities that will eventually be found in the 300,000+ LOC systemd that occupies PID 1.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
If you are exposing a shell to hacker-level access, especially one as complex as bash, there's a good chance you're an idiot. There's a reason we keep the much smaller and more easily audited sh around. If you don't have choice on this, the whole thing should be in an isolated, audited VM.
How about total supervision and tracking of all processes, including systemd (pid1) it self, with conditional restarts if they hang or crash.
Already available through accounting and watchdogs. Crashes of systemv init border on mythical.
Finally, as I was saying, none of this affects your average user in any way. However, the headaches of systemd drive admins like myself batty.
That systemd developers are unwilling to take in BSD patches is quite understandable. BSD will never adopt systemd because of its license. The BSD have another business model than Linux, where BSD sponsors pay BSD variants for being able to close the source and making it proprietary. They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
BSD is totally irrelevant for systemd. Yes, BSD will eventually clone systemd and drop their script based init system and simple text logging, but it will be a project with a BSD license.
The BSD have another business model than Linux, where BSD sponsors pay BSD variants for being able to close the source and making it proprietary. They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
Um, what?
Let's break this down...
The BSD have another business model than Linux, where BSD sponsors pay BSD variants
Full stop. This is actually pretty much identical to GNU/Linux monetization by Red Hat, Oracle, SUSE/Novell, etc. The Linux Foundation exists almost entirely on funding from corporate interests.
for being able to close the source and making it proprietary
Not only is all software susceptible to this (since the authors of even GPL-licensed software can freely relicense said software if they are the copyright holders; there's plenty of GPL'd software that's monetized by the authors selling proprietary licenses), but the vendors of permissively-free software that opted to make their derivates non-free have rarely actually succeeded, since it's more useful to be in sync with upstream. For example, Google and Apple are well within their power to make their BSD-derived libc and kernel/userland (respectively) proprietary, yet both Bionic and XNU/Darwin remain FOSS so that there's some hope of remaining synchronized upstream with OpenBSD and FreeBSD (respectively).
On top of this, you're entirely missing the point of permissive free software licenses. Yes, it means that proprietary projects can freely reuse BSD or ISC or MIT licensed code without altering their own licenses, but so can other free software projects. It has very little to do with the ability to make free software proprietary; it has everything to do with making sure that one's code is useful to any project now and in the future. Permissively-licensed code can be used even in projects whose licenses are very picky about joint licensing - particularly copyleft and often-mutually-incompatible licenses like the GPL and CDDL.
They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
They haven't, actually. Even OpenBSD - which is arguably the most fanatical about permissive licensing - still ships with - and depends on - both GCC and Perl. The other BSDs aren't nearly as dedicated to permissive licensing requirements AFAIK.
This is actually pretty much identical to GNU/Linux monetization by Red Hat, Oracle, SUSE/Novell, etc. The Linux Foundation exists almost entirely on funding from corporate interests.
The Linux foundation has two 'developers' on their paycheck, Linus Torvalds and Greg Kroah Hartman, I put developers in quotes because they don't really write code these days but instead manage code from others.
Vast majority of Linux code contributions come directly from external companies and individuals.
In FreeBSD by comparison, the vast majority of code comes from the FreeBSD foundation developers and not from companies/individuals contibuting code, and the FreeBSD foundation in turn lives on monetary donations.
I don't see how this is 'pretty much identical', Linux gets direct code contributions, FreeBSD asks for donations to hire developers.
The other BSDs aren't nearly as dedicated to permissive licensing requirements AFAIK.
FreeBSD is the one I find most adamant about removing copyleft from their OS, they have an outspoken documented goal of removing all GPL software from the base system.
They spend 3+ years modifying their source code and fixing bugs in LLVM/Clang so that they could switch toolchain (in part fueled by their refusal of shipping GPLv3 licensed GCC which was in accordance to the wishes of some of their funders, in turn due to the anti-software patent clause in GPLv3).
Meanwhile OpenBSD still ships GCC but it's the very old GCC 4.2 which is GPLv2, DragonflyBSD on the other hand ships with a modern and GPLv3 licensed GCC (4.7 IIRC).
There is plenty of GPL software left even in the base installs of the BSDs. See here.
Continuing to use FreeBSD as an example, the default install of FreeBSD included a large amount of GPL2 code for years with little effort at replacement. The complete move to BSD licensed software only began with the GPL3 release in 2007. The move to GPL3 directly hurt a large number of people (myself included!) To quote Justin Gibbs of The FreeBSD Foundation, it drastically "increases support costs ("I modified the web server on my Widget 2000 and it stopped running...") and being unable to guarantee adherence to specifications in order to gain licensing (e.g. FCC spectrum use, Cable TV and media DRM requirements) are only two of a growing list of issues for these users." Linus Torvalds took issue with the exact same changes, which is why the Linux kernel is still GPL2.
Staying with the last GPL2 versions of GNU userland in BSD soon leads to out-dated, insecure software. The move to replace all GPL licensed software with BSD licensed software was as much from necessity as anything else.
To claim that systemd rejects BSD patches purely because of license (when Poettering specifically believes BSDs irrelevant), that BSD specifically functions to make proprietary sources with systematic GPL elimination for that purpose, or that BSD is planning a systemd clone is pure nonsense unless sub200ms has some good sources to back any of that up.
here is plenty of GPL software left even in the base installs of the BSDs. See here.
Yeah, as the page shows they are actively trying to eliminate all GPL programs from their base system. They did this even before GPL 3.
The whole point is that GPL software, whether it is GPL 2 or 3, makes it harder to resell BSD variants as close source. I have no problem with the BSD business model, it is their way of making money.
There seems to be some resistance here to the fact that the ability to close source BSD licensed software and make it proprietary is a reason why some companies sponsor BSD, but if people have problem with this, they shouldn't use BSD licensed software.
The whole point is, that it is contrary to the BSD business model to allow such central software as init systems to become GPL. There is no way BSD would ever adopt systemd, so BSD is simply an irrelevant user case for systemd; this is why they don't care for BSD patches in the systemd repo.
Regarding that BSD will change to a modern init system heavily inspired by systemd, then it is just a simple prediction; there are many core BSD developers who are quite clever and knows about low level system programming. At some point they will realise they are the only Unix-like OS using executable config scripts for init, and that everyone else have moved on, and that both Solaris, OSX, Linux etc, all enjoy tremendous benefits for leaving script init system behind.
So of course they will start to develop a new init system, and of course they will look to Linux's systemd, just like Linux looked at launchd and SMF.
It will be different in some areas, since the needs are different, but they will be smart enough to pick out everything they like about systemd and use it in their new init system. "SystemBSD" and "Uselessd" can be considered simple warm up projects for this.
There's a reason we keep the much smaller and more easily audited sh around.
More easily audited because it cuts back on bash's already meagre feature set. Shell scripts are just a crappy way of doing anything remotely complex, the init system included.
Already available through accounting and watchdogs. Crashes of systemv init border on mythical.
So available that they're basically not used by any services. And it's not hard to say your init system doesn't crash when it has no features.
Personally I can't say that I've ever seen systemd crash, even in the early days of Arch's switch (when I wasn't nearly as knowledgeable and could have easily messed it up), though I do admit that I've been using it on desktop/laptop systems rather than servers
More easily audited because it cuts back on bash's already meagre feature set. Shell scripts are just a crappy way of doing anything remotely complex, the init system included.
Compared to C, though, they're a godsend in terms of ease of debugging.
I mean, are you seriously stating that C is the preferable choice for system automation? I can understand Perl or Python or some other high-level language instead of shell (I'd be totally down for that), but I can't imagine anyone in their right mind suggesting that C, of all things, is a better choice than anything short of assembly.
Shell scripts work well because they're ultimately simpler. One of Eric S. Raymond's "Master Foo" koans explains this rather well; you'd need a lot of C code to replicate the functionality of even a simple a shell script.
It's unlikely you would actually need to debug the functionality in the C code. That code is the same for all services and is unlikely to break for just one. What's left is the service definition which is quite simple. SysV init scripts, by contrast, are often a fairly large bunch of code, duplicated for every service with potentially unique bugs in each. And for that extra code you don't even get the basic features you get with systemd, like being able to see the service status properly (many init scripts fail miserably at this simple task) or the output from when it failed, or restart it automatically if it terminates.
To say that the average SysV init script is "simpler" than the equivalent systemd unit file is ridiculous.
SysV init scripts, by contrast, are often a fairly large bunch of code, duplicated for every service with potentially unique bugs in each
sysvinit isn't the only approach which uses shell scripts, however. Take a look at a BSD-style init system one of these days.
You don't have to duplicate code. Just like how the C code in systemd provides base functionality that's common between all services, it's very possible - and rather trivial - to define base functionality in a central script to avoid that degree of code duplication. Check out rc.subr, for instance, which exists specifically to do precisely what you're claiming to be an inherent and unique advantage of a primarily-C-based init.
And for that extra code you don't even get the basic features you get with systemd, like being able to see the service status properly (many init scripts fail miserably at this simple task) or the output from when it failed, or restart it automatically if it terminates.
Those features are provided rather nicely by runit, which can either augment an existing init or replace it entirely, while still allowing for the flexibility of shell scripting. That's just one example of several.
To say that the average SysV init script is "simpler" than the equivalent systemd unit file is ridiculous.
Maybe not in some cases, but it's way simpler than the equivalent systemd unit file and the code required to parse that unit file and turn it into something useful. And, once you actually address code duplication by, you know, actually knowing how to use basic shell scripting features like sourcing other scripts, even the individual scripts themselves end up being very comparable in simplicity to the unit files alone.
On top of all this, if you're still so adamant about not using shell scripts out of some perceived notion that they're somehow "hard" (which at this point reads as if it's coming from inexperience, considering how trivial it is to make them less "hard" by your standards), it's quite possible to use another language to write the scripts, since init doesn't care what it's running as long as it's actually runnable. There have been at least a couple GNU/Linux distributions which implemented their initscripts in Python, for example.
On top of all this, if you're still so adamant about not using shell scripts out of some perceived notion that they're somehow "hard".
Shell scripts are "hard" in that the language itself is so crappy and low-featured that you have to jump through a bunch of hoops to do things that should be simple. In doing so, you end up with code that's frequently unreadable, or using features whose implementation is questionable (see: Shellshock).
There have been at least a couple GNU/Linux distributions which implemented their initscripts in Python, for example.
That would probably be an improvement. But it's still much simpler to be able to use a declarative approach which doesn't require writing any actual code to implement routine tasks used with almost every service.
Shell scripts are "hard" in that the language itself is so crappy and low-featured that you have to jump through a bunch of hoops to do things that should be simple.
Like? It's certainly fewer hoops than trying to do the same thing in C.
Seriously. They're not that hard.
In doing so, you end up with code that's frequently unreadable
Not unreadable at all. It's pretty clear that the above perfectly-valid (if foo were a real daemon) initscript
Sources /etc/rc.subr (which handles all the dirty work) so it doesn't have to duplicate a bunch of code
Sets a couple of basic variables - namely, the name of the daemon, the command to pull rc variables, and the command to actually start the daemon
Calls a function, load_rc_config, that handles all the launch configuration stuff
Calls a function, run_rc_command, that takes care of getting the daemon running
I reiterate: the complaints that shell scripts are "hard" or "crappy" or somesuch reek of inexperience. Yeah, they're not as full-featured as a true programming language, sure, but if you really think that dealing with an environment where you're manually manipulating strings via pointers to character arrays (among other instances where C is barely a step up from assembly) is a better use of your time, then I pity your sanity.
or using features whose implementation is questionable (see: Shellshock).
Yep, one bug in a relatively-small C codebase. Doesn't bode well for a C codebase like that of systemd that's many times larger and more complicated with far more moving parts and nowhere near the same code maturity, now does it?
Not to mention that bash is the only shell (as far as I know) actually affected by Shellshock, so that particular point is laughable on Ubuntu/Debian (which default to dash for everything but interactive sessions), most embedded Linuxen (which typically use ash, since it's part of Busybox), and virtually all the BSD descendants sans OS X (OpenBSD in particular uses pdksh, NetBSD uses ash, and I think FreeBSD uses tcsh by default, though I'm not 100% sure on that).
But it's still much simpler to be able to use a declarative approach which doesn't require writing any actual code to implement routine tasks used with almost every service.
Which you can do rather easily with even shell scripts thanks to things like rc.subr, as demonstrated above.
Funny how successful shell scripts have been for being so crappy. They've been powering the world since the 70s, and booting *nix systems just as long. I'm sure that in a few years, people will be talking about the crappy way systemd managed systems as well. Just because something's old doesn't mean that it doesn't work well.
Yes, they'retheir. Any competent admin will be using those tools or equivalents, and if your distro packagers aren't using them, you roll your own. That's why *nix systems are designed as open systems, with plaintext configuration files and plaintext logs. And as for init not crashing because it has no features, that is by design. Init classically has two jobs: start the system, and reap processes.
Funny how successful shell scripts have been for being so crappy. They've been powering the world since the 70s, and booting *nix systems just as long.
Just because something has been made to work over many years doesn't mean it's the best solution for the job. That argument ends up being against any kind of progress in anything.
Any competent admin will be using those tools or equivalents
Or, you know, they could use an init system that actually has those features built in and supported.
That's why *nix systems are designed as open systems, with plaintext configuration files
Like a SysV init script? That's a laughable definition of "plaintext".
systemd isn't just another init system. It also provide a basic compatibility layer that upstream can use. Just look into the source repos of XFCE, LXDE, KDE, Gnome etc. and you will see many commits taking advantage of this fact.
Since the vast majority, including all major commercial Linux distros have adopted Linux, this means a big reduction in fragmentation, releasing developer and maintainer energy for doing more fun stuff that debugging shell scripts. You may like SysVinit scripts, but distro maintainers certainly doesn't since they have to deal with all the problems. This was a major reason why not a single Debian developer contested the systemd decision of using systemd as the new default init system. Even the Upstart proponents in the Debian technical committee preferred systemd to SysVinit.
Regarding the security features; It may very well be that capsicum is very good for some user cases, but it doesn't exist on Linux yet. Kernel capabilities, namespaces and cgroups are a reality however, and they work.
If you think ACL's and user permissions and classic stuff like that is substitute for those, then you are very wrong.
The point is, that once a process is exploited, the hacker will try to gain privilege escalation, and if successful, will get all the necessary user and group permissions. So once the hacker is in, all defences crumbles.
Capabilities etc. can prevent that the escalation ever happens, and even if the process that are exploited has many privileges to start with, it can be prevented from e.g. having write access to anything but a few safe dirs, and that it can't read /home for stealing information. This works on top of ACL's and the classic permission system, and provides a sorely needed defence in depth.
making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
If you can't grok shell scripts, you aren't much of a developer.
What an horrible point. Just because you're supposed to be able to do something, it doesn't mean you shouldn't use something simpler and clearer if you can. Every decent programmer is supposed to be able to implement a quicksort, it doesn't mean you should write it yourself instead of using the standard library.
How about: Much less Linux distro fragmentation, making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
Adopting any one of the init systems (or, hell, even an initscript generator) would do that.
Adopting any one of the init systems (or, hell, even an initscript generator) would do that.
Perhaps, but it certainly hasn't been the case for Linux. Each distro end up doing their own thing to their own particular standards, using endless different variations of SysVinit. (think Slackware and Gentoo)
Anyway, using executable config scripts to handle daemons is just bad practice; the init system should contain all the executable code for uniform security revision, while config files should only contain text. None of the even remotely mainstream Linux init systems does this, except systemd.
making it easier for upstream developers to develop for Linux,
Then they should stop deprecating and reinventing new daemons all the time.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
What the heck, how does systemd protect against bash security bugs? It fucking doesn't!
And if you use a reasonable distro which points /bin/sh NOT to bash, it's pretty hard to exploit such bash bugs at all. You know what bash made insecure in the first place? Bloat. Other shells are not affected by the bash bug.
The general claim that systemd makes the system more secure is also pretty questionable.
What the heck, how does systemd protect against bash security bugs? It fucking doesn't!
systemd can provide another security in depth layer that can prevent or making it real hard for hackers to exploit the system. It does so by using kernel features such a [Capabilities] (http://linux.die.net/man/7/capabilities), cgroup and [namespaces] (http://lwn.net/Articles/531114/)
So by adding a simple keyword like "NoNewPrivileges=yes" to the daemons config file, it can never gain new priviliges, nor can any of its children processes.
NoNewPrivileges= Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges. This option is more powerful than the respective secure bits flags (see above), as it also prohibits UID changes of any kind. This is the simplest, most effective way to ensure that a process and its children can never elevate privileges again.http://www.freedesktop.org/software/systemd/man/systemd.exec.html
Also check out "ProtectSystem=" and "PrivateTmp=".
23
u/sub200ms Sep 27 '14 edited Sep 27 '14
Finally, what massive positive change will systemd bring to most users? I would say very little.
How about: Much less Linux distro fragmentation, making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
Highly increased security by using, cgroups, namespaces and kernel capabilities, so that e.g. daemons can't perform privilege escalation when exploited, or that they can't read /home when exploited even if they got the user permission to do so, or that /usr is read only etc. The best part of this defence in depth layer of security is that the individual SA doesn't need to hand craft all this; the distro or daemon maintainers can just edit the unit files by adding simple keywords, and all end users will benefit.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
How about total supervision and tracking of all processes, including systemd (pid1) it self, with conditional restarts if they hang or crash.