| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 19, 2011 16:52 UTC (Sat) by jmorris42 (subscriber, #2203)In reply to: The Journal - a proposed syslog replacement by cmccabe Parent article: The Journal - a proposed syslog replacement
> I'm going to have to disagree. Security is a pretty major issue, and
> anything that improves system security on desktop and server Linux is > probably a win.
Except it isn't. It greatly complicates the system for little or no net gain in security. First rule: if the host might be compromised you must not trust it. They admit the existence of this rule and admit the only solution is to put some of the checkpoints on a different system. They fail to see the obvious, put them ALL on a different system. The people who designed syslog understood security better than Lennart does.
That is The UNIX Way. We learn what works and keep it.
"The access is granted by a shared library and a command line tool."
Haven't we seen this story enough times to see the pattern? The tool will be minimal, just for quick use by UNIX diehards to shut them up, while all 'serious' use will be expected to be through the API/library.
For a 'real programmer' it doesn't matter, but UNIX philosophy envisions a spectrum of skills, not a binary user/developer divide. Windows philosophy on the other hand is different. Remember that a key Microsoft design goal for the registry was to fit into their overarching project to end 'power users.' Professional developers write code, users click on widgets and nothing in the middle.
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 19, 2011 23:07 UTC (Sat) by cmccabe (guest, #60281) [Link]
The problem with putting all your syslogs on a remote system is that it can eat quite a bit of bandwidth. I honestly haven't seen any systems actually configured for remote syslog in my time in the industry. In contrast, sending a single hash to a central single-purpose server every hour doesn't raise any bandwidth issues.
This whole project was motivated by the administrators' inability to trust the kernel.org syslogs after the breakin. It's always a good sign when a project solves a real problem that some smart people encountered.
> Haven't we seen this story enough times to see the pattern? The tool will
I agree that there is a lot of DBUS-itis and shared-library-itis out there, especially from the GNOME devs. (The GNOME devs have done a lot of good work as well, but I have to call it like I see it.) But I don't think this falls into that category.
As long as 'logger' continues to work, and there is some way to cat the syslog to a file, it will be as easy to use syslog on the command line as it ever was. I mean, syslogd has been a daemon and syslog(2) has been an API since the seventies; you can hardly complain that Lennart is adding yet more daemons and APIs to the system. If you add a FUSE interface that exposes a writable file named /var/log/syslog that has all the log entries, it's as scriptable as it ever was.
The Journal - a proposed syslog replacement Posted Nov 23, 2011 21:14 UTC (Wed) by jeremiah (subscriber, #1221) [Link]
> I honestly haven't seen any systems actually configured for remote syslog in my time in the industry.
um... We do this on all of our servers. I love being able to tail one single file and get everything going on. Now, we don't do this outside of our local network. But a gig network seems to be able to handle the bandwidth just fine. I'd love a nice tool that would allow us to securely archive log files. And to me it seems that Journal is trying to do both, Archive, and transport. I don't think these two processes should effect each other. We also find that Splunk works pretty for the archiving and searching. As well as getting a hold of log files that don't output to syslog ie. request.log.
The Journal - a proposed syslog replacement Posted Nov 23, 2011 23:36 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
splunk is great for searching logs (I have a large cluster of machines for doing exactly this), but in terms of gathering and transporting logs, it's far from the best.
take a look at syslog-ng and rsyslog and the options they have to gather data from log files written by other apps.
The Journal - a proposed syslog replacement Posted Nov 25, 2011 15:02 UTC (Fri) by jeremiah (subscriber, #1221) [Link]
those are on my list. It's mostly an issue of upgrading servers at this point to version that support them.
|
|||||||||||||