Forgot your password?
typodupeerror

Comment: Re:One of the worst points about systemd (Score 0) 514

by Peter H.S. (#48175613) Attached to: Debian Talks About Systemd Once Again

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

When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.

If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.

The problem is that nobody really develops for non-systemd distros anymore. Sure, a loud minority is constantly attacking systemd, but they don't bother with developing crucial software needed to run non-systemd distros, nor do they help upstream projects to support them either.

The reason why upstream projects depend on systemd, is because systemd provides essential low level stuff that nothing else really provides on Linux.
There will probably be no problem with running Gimp etc. on Windows (or OSX) simply because those OS's have the necessary low level stuff to keep modern software running, so the projects can just use that instead of systemd.

Comment: Re:Remove It (Score 1) 514

by Peter H.S. (#48175591) Attached to: Debian Talks About Systemd Once Again

It is pretty common to "vet" academic papers before publishing, so that other people can give a qualified input etc. So it is hardly surprising that Lennart had "early access" to the paper. As I understand it, then "Forward security" is a pretty old crypto concept. What Marson and Poettering did was tweaking the concept to log files which represents special problems to more static texts like emails, and use the concept for sealing, not encryption. The concept seems sound and have been formally peer reviewed.

Here is the paper in case you haven't read it:
https://eprint.iacr.org/2013/3...

Comment: Re:Remove It (Score 0) 514

by Peter H.S. (#48175541) Attached to: Debian Talks About Systemd Once Again

Sure, systemd's journal with its advanced and rich meta data works very well with database logging, much better than the old legacy style syslog text dumps. This is hardly surprising.

But database logging is also much more complex which is why it is only used on large setups with syslog, and the systemd's journal is designed with simplicity as a primary design goal, so it works with all the standard Linux text tools like grep, tee, less, etc.

Systemd's journal can be used as a drop in replacement for syslog with total backwards compatibility, including in-house made watch scripts, or it can be used as a next generation syslog with a stable API for generating watch scripts (finally!), and providing rich meta data like monotonic timestamps.

I don't know how you got the idea that grep etc. doesn't work with the journal?
"journalctl -b -p err | grep -i ata | tee sata-errorlog.txt" works brilliantly: show all log entries from this boot that have error log level "error", grep it for "ata" and tee the result into a textfile. Think of "journalctl" as the most powerful log filter tool you have ever seen. It works perfectly with the standard Linux tools.

Anyway, you can still use rsyslog or whatever together with systemd. You even gain the benefits of early boot logs (journald can log from before the root filesystem is even mounted while living in initramfs). I did too in the beginning, but removed it when I got to know systemd better. Forget about what other people say about systemd's binary logs, and try them yourself; it is really good stuff.

Comment: Re:One of the worst points about systemd (Score 1) 514

by Peter H.S. (#48174455) Attached to: Debian Talks About Systemd Once Again

Yes, you are correct. Status quo can't be maintained without development. ConsoleKit worked, and if it was maintained it could still be a working solution, but it has been deprecated for years now.

That is the problem in a nutshell; the non-systemd distros have the sole responsibility for maintaining and developing the necessary code for making a non-systemd distro run.

Oh, and stop getting your "information" about systemd from the tin foil hat systemd hate-blogs, they are so filled of misinformation it is laughable. Gnome, including the lates Gnome 3.14 still supports ConsoleKit: http://blogs.gnome.org/ovitter...

They are not happy about developing against dead software that can't be bugfixed though, and they have said so for years. But the systemd-opponents don't care at all about that, they don't care about helping upstream projects support their ever dwindling numbers of distros, all they seemingly wants to do, is ranting all day long about how bad systemd is.
All rant and no code.

Comment: Re:One of the worst points about systemd (Score 1) 514

by Peter H.S. (#48173409) Attached to: Debian Talks About Systemd Once Again

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

No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.

The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.

There is nothing forced anywhere. The problem the non-systemd crowd is facing is they have no developers and no development taking place. Upstream projects like Gnome and KDE uses systemd features because they are necessary for having a modern DE, and because nothing else provide such features.

Gnome developers have said for years that people would have to either maintain ConsoleKit or make something similar so Gnome could function on non-systemd distros. But no one is listening and no one is developing an alternative, so Gnome is left to use systemd-logind that is maintained, take bug fixes and have good features, or try to support ConsoleKit (they still do in Gnome 3.14 despite what people claim on systemd hate blogs). But as said; ConsoleKit isn't maintained, so Gnome can't have urgent CK bugs fixed.
Same with Wayland. The non-systemd crowd simply aren't helping upstream projects to make them still support non-systemd distros.

This Debian proposal is exactly about this; if this GR succeed, the non-systemd Debian crowd can _force_ developers to work on features that SysVinit needs. It is simply impossible to gather the necessary developer talent for doing so without such force.

Comment: Re:There's a solution: (Score 0) 514

by Peter H.S. (#48173127) Attached to: Debian Talks About Systemd Once Again

Break up systemd into its components and let certain functionality of it be augmented or replaced by sysvinit.

There is actually good reason for why systemd is designed like it is. If people tried to re-implement systemd, they would face the exact same dilemmas that the systemd developers did, and probably solve them the same way.
If you remove certain parts from PID1, you will get an awful lot of overhead and communication between the new module and PID1. This isn't a trivial problem.

Another thing worth considering, that most of the things systemd deals with, are really hard low level stuff. Very few developers actually have the skills needed for dealing with session management like in "systemd-logind". So there are almost no independent developed "modules" that can be used to replace systemd "modules"; The no serious full alternative to "udev" or logind on any other init system. There is multi-seat support outside systemd either. Even journald has no real alternative, since rsyslog etc. can't get early boot log info, since unlike journald, they can't log info before the root filesystem is mounted.

So the alternative doesn't really exist anyway. The non-systemd proponents simply lack developers, especially low-level OS developers.

Comment: Re:Remove It (Score 2) 514

by Peter H.S. (#48172913) Attached to: Debian Talks About Systemd Once Again

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

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)

There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...

Comment: Re:Remove It (Score 2) 514

by Peter H.S. (#48172859) Attached to: Debian Talks About Systemd Once Again

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...

Comment: Re:Remove It (Score 1) 514

by Peter H.S. (#48172775) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48172443) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48172277) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48172117) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48172055) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48171841) Attached to: Debian Talks About Systemd Once Again

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) 514

by Peter H.S. (#48171603) Attached to: Debian Talks About Systemd Once Again

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.

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...