Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux syslog on the way out?

itworld.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Linux syslog on the way out?

#41

Post by ciupicri »

wmf wrote: post #26
saljam wrote: post #13

Plan 9 has an extra permission for files; "append." When set, this means programs are only allowed to append text to the end of the file. Both simplifying logging (just open the file and write) and making it more secure (no arbitrary writes.) I wonder if Lennart and Kay would accept a solution that simple...

Linux also has append-only files, although as usual root can override it.

Are you referring to chatattr +a log? The problem with these files is that they can't be renamed:

    # mv log log.old
    mv: cannot move `log' to `log.old': Operation not permitted

Re: Linux syslog on the way out?

#43

Post by rbanffy »

dredmorbius wrote: post #18
rbanffy wrote: post #16

Earlier quoted context omitted.

A second read makes me believe it solves no problem except disk space usage. The fact it's binary and signed protects against nothing - whoever has control of the machine also controls the signing keys of the log and can generate whatever log they want, with whatever event they want. Are we doomed to repeat every stupid mistake Microsoft made? Is the "if you don't know Windows you are doomed to reimplement its bugs"…

The solution to integrity, IMO, is distributing the log (multiple independent logservers). You can hash individual line items if you want, or sign them, or do any number of other things to make it easier to find discrepancies. There's the problem of log lossieness in general, which is a tough nut to crack. Some form of log entry UUID might also be useful (though hostname + millisecond/jiffy timestamp comes close). An…

> The solution to integrity, IMO, is distributing the log (multiple independent logservers).

Isn't this already solved by rsyslogd?

Re: Linux syslog on the way out?

#44

Post by dredmorbius »

rbanffy wrote: post #43
dredmorbius wrote: post #18

Earlier quoted context omitted.

The solution to integrity, IMO, is distributing the log (multiple independent logservers). You can hash individual line items if you want, or sign them, or do any number of other things to make it easier to find discrepancies. There's the problem of log lossieness in general, which is a tough nut to crack. Some form of log entry UUID might also be useful (though hostname + millisecond/jiffy timestamp comes close). An…

> The solution to integrity, IMO, is distributing the log (multiple independent logservers). Isn't this already solved by rsyslogd?

Yes.

Re: Linux syslog on the way out?

#45

Post by alextingle »

oneweekwonder wrote: post #33
alextingle wrote: post #24

Earlier quoted context omitted.

CVS?

I believe this is a bad example. Because CVS is only under maintenance there is no new feature getting added and the last stable release was in 2008. Also anyone that does a bit of research on version control software would realize CVS is only around for legacy purposes and there is enough paths to convert to SVN or a more "newish" DVCS.

CVS uses a text-based format. SVN is an "improved" version that uses a binary format. I think the parallels are quite striking.

(FWIW I don't think that syslog is broken, but then I'm a programmer. Source control is a key tool in my craft, so I'm keenly aware of CVS's limitations. If I were a ststems administrator, perhaps I'd feel the same way about syslog?)

Re: Linux syslog on the way out?

#46

Post by naner »

rhizome wrote: post #21
naner wrote: post #11

Earlier quoted context omitted.

I disagree. A lot of these old *nix tools are showing their age and could use a refresh based on known deficiencies. Creating new tools won't harm the old ones so I don't see a problem.

What are a few examples of other "old *nix tools" that are showing their age and have "known deficiencies?"

Well pretty much everything if you ask the plan9 guys. ;)

Over the years a lot of the Linux system infrastructure has been reworked:

/dev --> udev

SysV init --> systemd/upstart

su/sudo --> policykit (for desktop stuff)

sockets/shmem for IPC --> dbus (IPC for desktop apps)

xorg --> wayland (not quite yet)

I personally think cron and atd need to be updated and combined and possibly integrated with init.

If you're not running a server and instead are using Linux for a desktop or laptop then nearly all these daemons could be reconsidered as well.

Of course, sometimes you might decide that known deficiencies are better than unknown deficiencies or that simplicity and familiarity means the old tools are still preferred. FreeBSD is pretty old school and very functional after all. But there is plenty of room for experimentation.

Post reply on HN