SoylentNews is people
SoylentNews
from the Boot-him?-I-just-met-him! dept.
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 5, Interesting) by c0lo on Wednesday February 26 2014, @12:53PM
What the hell is systemd? Why it was needed in the first place?
Also from here [0pointer.de]
If there's a niche where a company specialized in consulting services for systemd can live, it smells like an awful big trouble with the complexity: no longer a simple man page to get to the bottom of your troubles, but maybe (or... very probable?) a book 850+ pages thick.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Informative) by glyph on Wednesday February 26 2014, @01:13PM
There is a company offering "niche" consulting for pretty much every service under the sun... even wiping your ass. But that's just business, baby. Complexity doesn't have anything to do with it.
(Score: 1) by morgauxo on Wednesday February 26 2014, @04:26PM
I wonder if they really even are a company specializing in systemd or just run lots of ads targeting specific "specialties". They might even use different names.
(Score: 4, Insightful) by MrNemesis on Wednesday February 26 2014, @02:52PM
As a heavy linux user on the server-side but with almost no exposure to desktop linux in the last few years I'm also one of those people who views systemd with a bemused "Whuh...?". Then lots of people complaining "there are no more text-based log files". I was even more concerned when I see things like audio and network management being brought under the helm of this increasingly all-encompassing and apparently rather byzantine program.
I can understand the use-case for the desktop ecosystem - linux was always a little hinky with hibernate/resumes for example, but when I hear things like "systemd will also start incorporating networkd for network management" and thinking of the complete fustercluck that network manager wreaked for headless systems (/etc/network/interfaces, cold dead hands, etc). Lots of people harping on about how it boots so much faster and what have you - but again a nearly meaningless benchmark for servers (most of ours go from GRUB to login in less than five seconds in any case).
So as someone who hasn't used it yet, can anyone tell me, aside from better desktop support, what it brings into the server arena? Many of us are curious about it but sceptical since we've not yet seen what need it's meant to be fulfilling.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 4, Informative) by Bill, Shooter Of Bul on Wednesday February 26 2014, @03:55PM
Off the top of my head:
Good Daemon management by default.
Daemons can't escape monitoring. ( no amount of forking can confuse it)
Easily get the status & last couple of log lines.
All daemon output logged.
Binary log files ( prevents tampering with them).
Aggregated logging makes event correlation easier.
Socket based activation of daemons/services.
Nothing ground breaking that couldn't have been done before, but its all preconfigured to do it. And the tools are integrated with each other to work well together.
Basically systemd is cgroups applied to daemon management. That's the unifying thread that ties everything together. It turns out that its a very powerful tool that's useful in a lot of situations. So some people look at everything that systemd does and cries "bloat!" "Its taking everything over!!11", while others look at it and say "Wow that is a really useful concept that has applications everywhere. Great code reuse!"
(Score: 1, Interesting) by Anonymous Coward on Wednesday February 26 2014, @04:28PM
How so? I'd expect the typical binary file format to be easier to tamper with, because typically binary data has well-defined data boundaries. So to change a number from 3 to 127, you'll typically just have to change one byte, while with text files you'll have to insert the bytes, changing the file length.
If you want to secure your log files against tampering, why not hash/digitally sign them? And if you now say that this is not secure because the key would have to be on the same computer, well, it's no less safe than binary files. If you want true tamper security for your log files, you'll not get to avoid sending them to a place where they cannot be rewritten from the computer generating the log files.
But even without a second computer, a certain security can be achieved be regularly generating new keys and destroying the old private keys (keeping the public keys for integrity checking, of course). Then the attacker cannot replace any entry in the log file before the latest key change (because the old key is gone).
(Score: 3, Informative) by Bill, Shooter Of Bul on Wednesday February 26 2014, @05:02PM
Yeah, I was kind of fast and loose with that explanation.
Here's Lennartt's description of the security from https://docs.google.com/a/nmi.com/document/pub?id= 1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1 [google.com]
"The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-once location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected."
Why he uses googledocs for some things, his blog for others, and freedesktop for still other parts, is kind of beyond me. I wish he and the systemd team would aggregate their documentation/raison d'etre for all of systemd in one spot.
(Score: 1) by MrNemesis on Wednesday February 26 2014, @05:19PM
Damnit, ninja'd! But thanks for including the extract as google docs in on the firewall blacklist :) But it seems to reinforce the point in my post below that you still need to be using a "write only" syslog server for it to have any guarantee of integrity.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 1, Insightful) by Anonymous Coward on Wednesday February 26 2014, @05:35PM
OK, so he uses cryptographic hashes for security. But that doesn't need binary log files. It can be done with text files quite fine.
(Score: 1, Insightful) by Anonymous Coward on Wednesday February 26 2014, @06:06PM
And the irony here is, that all of this could have been done with text based logs. Git's trees and blobs, afterall are just text once decompressed, and it 'authenticates' just like LP's explanation.
No need to "go binary" just to get tamper detection.
(Score: 1, Interesting) by Bill, Shooter Of Bul on Wednesday February 26 2014, @08:01PM
Yeah, that make sense. My crazy mind combined those two for some reason. The binary nature of the log is to allow you to log binary objects as well as text, I think. It also allows for some of the meta data, event correlation, and searching capabilities I believe.
(Score: 1) by weilawei on Wednesday February 26 2014, @08:17PM
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @10:46PM
Just so you see this, that was my mistake linking binary to the hash chain not anyone elses.
If it makes you feel better, it can be converted to text very easily. journalctl spits out text, so it can be piped into other text based tools if you want.
In general, anyone who complains about breaking UNIX philosopy should take a deeper look into it. There are some good reasons why it is the way it is, and why many competing distros have adopted it. They aren't all idiots willing to sacrafice the UNIX way for a flash in the pan. I'd also argue that UNIX is very much a part of systemd, but most who would rationally debate it won't bother to consider any arguments at all.
(Score: 1) by weilawei on Thursday February 27 2014, @01:45AM
I've seen this one a lot, but not one single person (not one!) who has said this has provided an actual example of a reason for moving toward a monolithic tool, specifically. Not one single person has raised an actual argument, based on anything more than "they're not idiots" for why it needs to be monolithic, and the bits implemented by systemd couldn't be done better in a modular fashion. Modular code is more maintainable, more extensible, and has a clear separation of concerns--something lacking in systemd. Someone who is a systemd supporter needs to step up to the plate and illustrate how this monolithic structure is better in those categories.
(Score: 1) by weilawei on Thursday February 27 2014, @01:49AM
Replying again, since I should have made this point as well. Saying that they're not all idiots who are willing to sacrifice the UNIX way for a flash in the pan, saying that they're maintainers of distros, is not an argument--that's an appeal to authority. Please, stop with the fallacious appeals and provide REAL arguments based in actual software engineering concerns, usability concerns, system administration concerns, etc.. I don't care if you want to play sheep to the shepherd, but I want to know WHY systemd should be monolithic and not modular.
(Score: 1) by MrNemesis on Wednesday February 26 2014, @05:16PM
Thanks, that makes a little more sense at least. But...
Can you expand on this a little perhaps?
I'd have to agree with the AC above on this - I don't see what about binary log files makes them any more actively tamper-resistant than text-based ones, there doesn't seem to be any checksumming involved in the systemd implementation. In any case, if you're worried about log integrity you'd redirect to a syslog server - how is this accomplished with systemd? Is an equivalent command for `tail -f access.log|grep someuser` (or tail/ack)? Or even just plain grep?
I assume you mean easier to match the timestamps from one to another? Granted this can be a pain in the arse especially when you have your system/kernel log measuring things from the time of boot whilst others base on various other formats (and a colossal case of haemorrhoids when you're correlating between two different time zones in three different formats), but for that there's tools like SEC [sourceforge.net]. Even so, what I'd love even more was if there was just a simple way for force an entire system to use the YYYY-MM-DD hh:mm:ss format globally like wot you can do in windows. Manually changing the locale (the only way I know to force it) is... ugly. Very ugly.
I'm guessing this is to be used for dependency-based daemon startup? I'm not really sure what it entails otherwise.
I think that's probably the biggest problem people like me have with the concept - maybe it's because I don't really do anything advanced with finagling init scripts, but I've never had any problems with the ones in debian, they all seem to tie nicely together, and murmurs from a people about a lot of things changing (there was a comment here about single user mode no longer working for example) for what seems like a largely philosophical reason; I'm a pragmatist rather than idealist in that regard and I'll go with what works rather than something that might be more technically perfect but with considerable caveats.
Guess I'll have to see how I get on with it once it's rolled into Jessie.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 3, Informative) by VLM on Wednesday February 26 2014, @07:35PM
"Guess I'll have to see how I get on with it once it's rolled into Jessie."
Can try it today, if you're on testing or have a testing VM or a sacrificial box to test on.
apt-get install systemd
Maybe there was more to it, I don't remember.
To run it, at the grub boot menu you hit e to edit your boot line (this one time) and add init=/lib/systemd/systemd to the kernel command line thingy and boot the temporarily edited config.
Did you work, awesome, might want to think about editing /etc/default/grub and put the above into a GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/syst emd" and run update-grub of course.
Or if it blew up just reboot and avoid hitting E and changing your init, or if it blew up after changing the file "permanently" you can probably guess that on boot you edit the command line kernel params and remove that init line.
Now forcibly removing sysvinit and keeping it out and only having systemd installed is going way beyond what I've done and I don't think its currently (easily) possible.
I suppose a truly pathological event could happen if systemd blew up while you were hand editing binary database files or some such and screw up the whole machine or something. So the usual, "make backups" applies and so on. Although I've had no problems that doesn't prove your hardware can't etc etc etc.
(Score: 0) by Anonymous Coward on Friday September 12 2014, @05:14PM
Qgxh2a xnwpcuovrvok [xnwpcuovrvok.com], [url=http://omokoyaevqka.com/]omokoyaevqka[/url], [link=http://beuggjufoucf.com/]beuggjufoucf[/link], http://ixxpequimsbu.com/ [ixxpequimsbu.com]
(Score: 1) by weilawei on Wednesday February 26 2014, @08:22PM
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @10:56PM
Socket based activation of daemons/services
You can do crazy things like have a daemon that isn't started until it gets a request. Systemd listens on the port and then starts the daemon and hands of the port. This way the daemon doesn't have to be running all the time, and/or you can better utilize system resources depending on service demands. They're also working on integrating it into linux containers, so a service that lives inside a container gets started up upon request.
Kind of cool.
(Score: 1) by pe1rxq on Thursday February 27 2014, @01:28AM
So they are also reinventing inetd?
(Score: 0) by Bill, Shooter Of Bul on Friday February 28 2014, @05:39PM
http://en.wikipedia.org/wiki/Inetd#inetd_replaceme nts [wikipedia.org]
Integrated and expanded the functionality, yes.
(Score: 1) by marcello_dl on Thursday February 27 2014, @04:13PM
Real world test: on one side a 3ghz core duo with a 10 yrs old 250gb disk and debian wheezy. On the other side, the same cpu dual booting on a 2 years old 1tb disk and debian jessie with systemd. Desktop with no servers except for openssh.
Time booting the new system? same as the old one, since the bottleneck is the adsl router connecting to the net. Thanks for playing.
No, seriously, i guess systemd is 20% faster, except the time taken for IP acquisition. That amounts to a negligible amounts of seconds.
Verdict: systemd is not much useful by itself, and it's a hassle if you factor in the amount of work needed to convert existing stuff to it. It probably was chosen because it introduces incompatibilities and sadly the software market feeds itself on incompatibilities. I think I'll end up on slackware.