Linux syslog on the way out?

I'd love to see something like that implemented - for the benefit of having semi-structured messages... Oh wait, there are lots of daemons which already do that. And they use properly documented formats, like GELF. And they support forwarding over network. And they store data inside a proper database, instead of yet-another-file-format.

I'd much rather they simply blessed one of the existing solutions (greylog2, fluent, loads of others) and created a compatible minimal daemon which can be included by default in a distribution. Currently they're neither providing new good solution, nor solving the structured log problem (flat k/v? why not just go json/bson?). They're also trying to solve single-host security, which seems pretty close to impossible without moving logging into something like TPM - just send the logs outside, so that the logging channel is append only.

There is also one point which makes me really worried about what the hell are they thinking... "The timestamps generally do not carry timezone information, even though some newer specifications define support for it." Simple solution is to log in UTC, always, everywhere. Run your servers in UTC too - unless it's your local desktop, there's no reason not to.

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.

Using PKI, this isn't necessarily true. Even constructing a system with simple one-way hashes might be sufficient.

If the logging system is based on a hash of the current and prior records, you get chaining and integrity validation prior to the attack (one problem of attacks is wiping out immediate or all prior history). If you've got remote storage / logging, particularly on multiple systems with independent trust models (compromising system A doesn't necessitate compromise of B and/or C), you're in better shape still.

A signature which required periodic updating of a key from a key provider via a mechanism that prevents later key reuse would mean that past records couldn't be fabricated or modified after the fact. This might require passing data through two or more systems to accomplish the signing in a trusted fashion (not particularly amenable to high-rate logging).

The verification key need not be on the logging system at all (and ideally wouldn't be). You'd access and verify logs from a standalone hardened and highly trusted system (say: booted from known good static media).

Much of which is good for the extreme case, but as I note in my other comments, isn't particularly practical for day-to-day needs. Which means it's also likely to be unfamiliar to technical staff, rarely practiced, rarely exercised, and buggy.

init / sysvinit / upstart / systemd: dependencies, reliable process monitoring & restarts, parallelization.

cron: take your pick, but I'd like a scheduler which would produce useful email / messaging reports when things go wrong, and shut the fuck up when they don't, while logging activity in markedly more detail than current jobs do. To accomplish this today you'd need to follow a strict template on your actual cronjobs. Stuff like: what host am I on, what crontab am I being run out of, what user am I running as, what script(s) / program(s) am I invoking.

nfs: performance, reliability, security, arbitrary group limits.

Generally: performance monitoring. We're still relying on top, uptime, vmstat, iostat, strace, ltrace, (sometimes systemtap/dtrace), wireshark, netstat, lsof, and related tools. There are a few new tricks coming out, and some ways to integrate data from multiple sources, but often tuning systems (especially where VMs or application engines are concerned) resembles a seance / archaeological dig / bro knowledge / myth / wishful thinking / Republican plank. For the love of Dennis, it's been 40 years, give me some goddamned insights.

There are probably a bunch of others, though I'm trying to stick with basics that you might find in The UNIX Programming Environment or similar -- really foundational basics (or reasonable extensions of same).

The barrier to change is that most of this stuff works well enough most of the time, and too much depends on it. I'm seeing a lot of exploration of alternatives around some core systems though, and suspect we'll see significant changes in the next 5-10 years. Possibly even sooner, though history suggests slower adoption.

They're going to need really good import and export tools. If they can provide those, then most of the objections to the change go away. If they can't, then I doubt it will gain traction.