Change... to what?

Posted Nov 25, 2011 4:33 UTC (Fri) by HelloWorld (guest, #56129)
In reply to: Change... to what? by dlang
Parent article: That newfangled Journal thing

> when you say that syslog is so horribly designed and so limited it makes me think that you haven't used a modern syslog (rsyslog or syslog-ng). Those are both good examples of projects that have added a lot of capabilities to logging, but have done so in ways that are compatible with the existing system while providing the additional power to those who want/need it
The Journal _is_ compatible with the syslog(3) api. And while it doesn't implement the syslog protocol, it is easily possible to write a gateway tool that implements the protocol and forwards messages to the Journal in order to be stored; in fact this possibility is mentioned in the proposal.
It would be really helpful if people would actually _read_ such proposals before whining about them.

to post comments

Change... to what?

Posted Nov 25, 2011 5:34 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

I have read the proposal

It's "compatible" with syslog in that if you are willing to throw out it's advantages of being structured and trusted you can encapsulate syslog data in journal messages.

but if you have done this, what exactly is the advantage of this new tool?

and if you can go the other way and have the journal entries put into nicely formatted structured syslog messages, why do you need the journal to do this again instead of just writing the nicely formatted messages to syslog in the first place?

Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

Change... to what?

Posted Nov 25, 2011 9:18 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

Except that clients will still be able to lie to the syslog service about their identity, etc. Structured messages are one thing that The Journal is about, but Lennart and Kay do address a fair number of other concerns. Some of these might be amenable to changes to rsyslogd, but others are more difficult to treat within that framework while Lennart and Kay do seem to have a handle on them. I think their proposal at least bears thinking about.

Change... to what?

Posted Nov 25, 2011 9:25 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

>> Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

> Except that clients will still be able to lie to the syslog service about their identity, etc. Structured messages are one thing that The Journal is about, but Lennart and Kay do address a fair number of other concerns. Some of these might be amenable to changes to rsyslogd, but others are more difficult to treat within that framework while Lennart and Kay do seem to have a handle on them. I think their proposal at least bears thinking about.

actually, journald is only able to avoid the application lieing to it for programs that are started by systemd and do all their logging through systemd.

This could be done with normal syslog by creating a unique /dev/log replacement for each application group that's started and then tagging to indicate which one the log arrives on (modern syslog daemons already allow you to have multiple sources and to know which source the log came from)

If anything else generates logs to journald in any way that bypasses the library, that thing could also lie about who it is. good programs won't do this, but good programs won't lie about who they are in the first place (unless they have a good reason to do so, which is very possible)

Change... to what?

Posted Nov 25, 2011 9:58 UTC (Fri) by michich (guest, #17902) [Link] (1 responses)

It does not matter what library you use to talk to journald. It is not possible to lie about who you are. Search for SCM_CREDENTIALS in the proposal. See also SCM_CGROUPS, SCM_COMM in http://0pointer.de/blog/projects/plumbers-wishlist.html

rsyslog now has 'trusted properties'

Posted Dec 1, 2011 3:43 UTC (Thu) by dlang (guest, #313) [Link]

it turns out that rsyslog already used SCM_CREDENTIALS to let you log the pid of the program, it's now added the ability to log some additional values

_UID The userid under which the logging process is being executed.
_GID The group id under which the logging process is being executed.
_PID The PID of the logging process. Note that this PID, if configured, is also put into the syslog tag.
_EXE Path to the binary that is logging
_COMM The name (as visible by top) of the logging process.
_EXE The full command line of the logging process. Note that this string can contain spaces, thus it is always provided in quoted form.

http://blog.gerhards.net/2011/11/trusted-properties-in-rs...

http://www.rsyslog.com/what-are-trusted-properties/

now that didn't take scrapping all existing logging practice to get did it?

Change... to what?

Posted Nov 25, 2011 9:20 UTC (Fri) by michich (guest, #17902) [Link]

Even with the syslog(3) api you still get some of the benefits: addition of the underscore-prefixed fields, indexing by these fields, per-user read access to their own logs.