Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Re:Remove It (Score 1) 522

Binary logs are also far more secure, but I guess that doesn't matter to you.

That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?

The systemd logs have better security in a number of ways; there is "Forward Secure Sealing" (FFS) that allows for cryptographically ensured verification, even if root is compromised on the host. It also have a integrated logfile verification, much less strong, but "free" and default.

Also, journald have kernel guarantees that log entries are made by the exact binary/program the log entry claims. On syslog, any program can claim anything in the text log file. Of course, the kernel guarantee is only truly secure with FFS turned on, but it is an improvement never the less; on a syslog system, the hacker only have to alter a text file. On a systemd machine, he has to have exploit booth root and journald, and then alter the logfiles in such a way that the internal log verification still works. Not trivial at all.

Comment Re:One of the worst points about systemd (Score 2) 522

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

Comment Re:Remove It (Score 1) 522

It is trivial to read systemd journal files from a boot media. They can also just be copied to a USB stick or whatever and moved to another system for analyzing.

Every log entry line has rich meta-data, including machine name, UUID etc, so you will never be in doubt on which machine the log was generated on

You can forward journald messages directly to syslog-ng just by adding a line to /etc/systemd/journal.conf

rsyslog can now natively read (and write) systemd journal files, and make the usual text logs if that is what you want (or use forwarding). http://www.rsyslog.com/doc/imj...

the journald daemon listen to /dev/log where all log messages from all programs are directed to, and the journald then forward these messages to another syslog. It will strip them of meta data first.
Since the journald can get log messages from early boot before even the root filesystem is mounted, this is actually an enhancement of just using syslog.

The journald journal is primarily an append based system, so it is quite resistant to file corruption. The journald files are basically text files with another line delimiter and an index. journald has integrated logfile-verification and can therefore discover if something is wrong (it will then log-rotate etc).

Comment Re:Remove It (Score 1) 522

What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?

If you want binary log files that require tools to dump them to text, use Windows.

I want systemd's binary logfiles because they are so much better than old style text log files. Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.

systemd's journal is really cool stuff. Don't be prejudiced against it and try it out in earnest.

Comment Re:Remove It (Score 1) 522

I'm a Linux noob, but Wikipedia says systemd's logfile is binary. I know one of the big complaints has been that it doesn't use plain text files the way Unix systems traditionally have.

If you are new to Linux, the systemd bianry logfiles are great; they are much easier to deal with than learning and memorizing a lot of "grep" switches.". Not that you can't use all the standard Linux text tools with the systemd logfiles, but you don't _have_ to.

Since the systemd journal has a stable API to accessing log file information, it is now actually possible to make a GUI log viewer that works properly.

I was skeptical about binary log files too, until I actually tried systemd properly and read up upon how systemd's journal functions. I am totally converted now, and will never go back to simple text log-files. Systemd's log implementation is simply so much better.

Comment Re:Hope! (Score 1) 522

Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.

You don't have to use systemd tools to read systemd journal files. There already exist alternative readers, and systemd provides both a journal library and Python/Ruby/etc bindings for accessing the logs.

Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.

If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.

There are two ways of doing it: having rsyslog reading(and writing directly to the systemd journal:
http://www.rsyslog.com/doc/imj...
I think this is the default behavior these days with modern versions. More info here:

Else check :
"/etc/systemd/journald.conf"
And set:
"ForwardToSyslog=yes"

(only for syslog-ng or rsyslog versions that can't read the journal directly)

Comment Re:Hope! (Score 1) 522

Great, so what happens when journald breaks>?

It is trivially easy to read systemd journal logs on remote machines.
Also, there already exist several journal readers since the log format is defined and have an API. So it is easy to have many different log readers installed for the "belt and suspender" types.
Even rsyslog reads journal files these days.

Comment Re:Hope! (Score 4, Informative) 522

Binary logs are anti-*nix. Rebut that.

That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.

Comment Re:On the ignorance of this debate (Score 1) 774

I don't agree about logging. I think the systemd journal is a great improvment over legacy style old text dumps. Stuff like "journalctl -b -p err" (show only messages from this boot at log level "error"). So useful, so simple. Or "journalctl --since -15m" that shows the last 15 minutes of logging. Or "journalctl -f -u firewalld.service" that just tails the firewall service. There is bash completion of everything, from parameters to servicenames. There is kernel guarantee the entries aren't faked (all those field starting with underscore), meaning that if cups is writing "lpt0 on fire" in the journal, you can see if its a fake or real. (on syslog anything can pretend to be cups).
systemd is also able to gain logging info from when the system is only in the "initramfs" stage (systemd lives in initramfs during boot and then jumps to rootfs), before the root system is even mounted, something rsyslog can only dream of.

The journal is primarily an append only system (basically a text file with another newline separator + index), so it is quite robust against RW corruptions.

systemd's primary design goal is simplicity; it isn't a log sink like rsyslog, and won't have db drivers. It is however easy to export its content in e.g. JSON format by the journald-gateway, or let rsyslog, who can natively read journal files, convert it into any supported format etc. So using Splunk is trivial these days.

Monit and systemd aren't completely overlapping, so you can still run Monit on top of systemd, that way systemd can restart Monit if it fails :-). But it is a major selling point for systemd, that it comes with integrated service supervision "out-of-the-box" and in easy way too. Just add some keywords to a textfile, and away you go. Because systemd uses cgroups, it can track all processes and their child processes with ease, so its supervision abilities are quite awesome.
To simplify both projects; systemd has the technological superiority when it comes to the low level supervision stuff, while Monit has all the high level monitoring stuff, like graphs etc.

OS containers predates systemd deployment. But systemd intend to make them much better: systemd intend to make OS containers that runs unmodified on top of the host OS. As it is now, there isn't much security, but that is the next round: unmodified, secure OS containers; run a standard Ubuntu and a standard Fedora on top of CentOS (and make them socket activated too). Nobody else have such high ambitions.

Regarding RH. They hardly need to make themselves "relevant" since their revenue actually keeps on growing despite the international crisis. Not many other Linux distro vendors experience that. No slant intended against Canonical, but AFAIK they still loose money every year.

Besides, while Lennart Poettering is employed by RH, systemd have long been a multi-distro collaboration, with half a dozen developers from different distros and companies that have git commit access. There has been more than 600 independent contributors too. So it is a huge open source project, not a Red Hat solo show.

Comment Re:On the ignorance of this debate (Score 1) 774

I know the pain of changing systems and workflow. It is understandable that people working close to systems have an aversion against changing stuff that works for them. Few people get paid for the luxury of learning new technology.

But systemd is actually a very rare watershed moment in Linux where some old fundamentals are being changed, and IMHO, systemd is an improvement in every area it touches; it is a better init system, provides awesome logging, exposes hard to use kernel features like cgroups, "capabilities(7)" and "namespaces", and make them a breeze to use: just ad a single keyword in a text config file, restart the service and you can enable cgroups features or prevent privilege escalation etc.

Total service supervision, including systemd itself. Really advanced rate limiting and service restart features, like "don't restart the service if manually shut down", or "don't try to restart the service more than 3 times within 10 minutes".

You can drop hard to maintain code if your service needs to drop privileges after startup, and just use systemd's inbuilt features.

start a new OS container in seconds to play around with, etc.

I can only encourage you to start learning systemd properly; at the moment all the commercial and non-commercial LTS distros will switch to systemd. I think even Slackware will change to systemd down the road, since there is practically zero development going on in the non-systemd camp at the moment.

Take it a bit at the time; there is so much new to learn. Try a systemd distro like Fedora 20's KDE spin, or Debian "Jessie" (should be in beta by now), perhaps in a VM.
systemd really is the future, and it really have a lot to offer.

Comment Re:On the ignorance of this debate (Score 1) 774

Is condescension your default response?

I can see what you mean, but it wasn't intended as such.

I've been developing software on Linux for years and using it for longer. There is no need for the console terminal emulator to be part of systemd; none whatsoever

Well, it is the opinion of David Hermann that it exactly belongs in systemd. Since he is the author of kmscon and consoled, I doubt that anybody knows more about VT's than he does at the moment. Since the vast majority of Linux distros are going to be systemd based in the future, it makes so much sense to make systemd optimized VT's. Just the fact that systemd is the only game in town when it comes to multi-seat is justification alone.

- you say as much yourself. Systemd is becoming a single package that does everything but your windowing system, this is a terrible state of affairs. No matter how much they claim that it's modular it's really not, everything ends up coupled together for no good reason that it's easier for Lennart to think about when it is.

Really, what is the problem with systemd gaining features like consoled? It takes nothing away for the tiny minority of non-systemd distros; they can still use kernel VT's if they want, or use kmscon if they care about features and bug fixing. Why are non-systemd user so obsessed and possessive about the systemd code? Use it if you want, fork it and use it they way you want, or make an alternative.

I can't really take your comment seriously about systemd features being coupled together with no good reason. I have yet to see a systemd-opponent that have any real experience with systemd or even have read all the documentation and man pages.

The systemd developers give good and detailed reasons for why they do what they do, but systemd-opponents seemingly prefer to get their systemd information from the many tin foil hat, swivel eyed, systemd-hating, loony blogs, instead of actually reading up on the subject.

Don't like systemd? Fine by me, just remember that it is all up to you to make the non-systemd distro working. So don't whine about what systemd developers does or doesn't, but concentrate on making your own alternative. Just attacking systemd gets you nowhere.

Comment Re:On the ignorance of this debate (Score 1, Interesting) 774

Why do you like systemD? What's so great about it?

I could probably write pages on how great systemd is, but the bottom line is, that systemd is "Linux-done-right!" in all aspects it covers:
It is by far the most advanced, feature rich init-system available for Linux (and probably Unix too).

There are several reasons that make systemd a great project;
Its developers (Poettering et al) have really studied all parts extremely well before they started coding, so all the systemd functionality is really well thought out, and implemented in a superb way; everything is an improvement, often by a huge distance. They have dealt with all the hard problems like backwards compatibility, no flag day, service dependencies etc, by solving them in the most correct manner instead of just patching things up, so systemd pc's have a fast boot, not because systemd is optimized for speed, but because by doing system and service initialization in the most predictable and correct way, leads to a boot speedups as a side effect.

Ubuntu's Upstart was an important, well coded, pioneering effort for improving Linux init systems and a serious improvement over SysVinit, but it also demonstrated, that by staying too close to traditional init systems, you didn't get rid of their inherit problems.

Just the logging alone is worth everything; it provides superb and powerful log filter capabilities that enhances the standard Linux text tools like "grep", but since it is structured, indexed and have a programmatic API, it will also mean that GUI developer now can make a functional GUI for viewing logs on Linux. So there is great stuff for the hardcore sysadmin, and the new Linux user at the same time.

systemd makes using advanced kernel feature like cgroup a breeze; no need to read advanced tutorials or cooking up bash scripts, just ad a single keyword like "CPUShares=20%" in the service config file, and systemd will use cgroup to ensure that that process will never get more than 20% CPU time on one CPU. It is so easy, and no coding required.

I could go on, but I recommend that you study systemd yourself:
http://www.freedesktop.org/wik...
Lots of great documentation there, that will make you think; this is great stuff!

Comment Re:On the ignorance of this debate (Score 4, Informative) 774

I guess you don't know much about systemd and kernel VT's. The explanation is quite long and technical, but the bottom line is that systemd provides needed infrastructure to allow eg. user switching in user space for VT's, and nothing else really does, so of course all the advanced features are going to be systemd only; nothing else provides what it does.

Furthermore, what some distros want is to turn off kernel space VT's completly, so something else in user space need to manage such VT's, whether the init system is SysVinit or systemd. What this is all about, is that systemd is adding support for this so you can use user space consoles in early boot for logging in or having en emergency shell and what not.

Hermann has made all the necessary tools for the non-systemd distros, so they can enjoy most of the benefits. I have a hard time imagining that ultra-conservative distros like Slackware are going to use it though, so they can just continue to use kernel VT's.

Comment On the ignorance of this debate (Score 5, Informative) 774

It is pretty sad to see, that after so many comments nobody really has a clue about what the story is about, and what is happening in the Linux kernel.
The kernel VT system has been considered a monstrosity by kernel developers the last decade and everyone is of the opinion that it should be used to user space.

The finally a really smart guy actually attacks and solve the problem. His name is David Herrmann, and he has tirelessly worked on this for years. Systemd distros will get the full support of his research, simply because almost all Linux distros are using, or a going to use systemd. But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon"
https://github.com/dvdhrm/kmsc...

Here is his fosdem talk:
https://archive.fosdem.org/201...

Here is his blog that will tell you more about VT's than you ever knew:
http://dvdhrm.wordpress.com/

Here is a wiki link about VT:
http://en.wikipedia.org/wiki/L...

Here is an old blog post about the problems with the old kernel VT:
http://dvdhrm.wordpress.com/20...

In short, no need for the systemd opponents to get their panties in a bunch; they can either use Hermanns user space tools, or pretend there isn't a problem and use the present kernel system.

For the rest of us who really likes systemd, this is great news. Thanks to Hermann's work, there will be much better console support for early boot debugging, better security, better keyboard and language handling etc.

Slashdot Top Deals

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Working...