[sudo-users] centralized iolog deployment

[Patrick Spinler]

It's not yet clear to me that structured data (e.g. JSON) beyond the
binary format already used would be useful here.  Nor is it clear to me
how one would include e.g. JSON into a syslog stream.

I posted a suggested implementation back in this message:
http://www.sudo.ws/pipermail/sudo-users/2011-September/004800.html which
I'd be willing to work on.  I'd not heard any response though, so have
held off on attempting to cut any actual code.

Might you be willing to contrast your ideas to that proposal, and
suggest where your ideas have the advantage, and/or disadvantage?

Thanks,
-- Pat

On 03/28/2012 06:14 PM, konrad rzentarzewski wrote:
> i've seen recent discussion ("sudoreplay logs from syslog-server") from
> mid-september and i'd like to add 3 cents about it.
> 
> i think syslog sink is superior over sslogger for several reasons.
> recent deployments allow reliable delivery of large messages (tcp, relp)
> and structured data delivery (ie. cee). additionally it may employ
> signed storage, so that tampering with data on destination server is not
> possible. last but not least - with disk buffering all sessions will
> eventually be delivered to loghost, even when sudo has been used on
> server (temporarly) without network connection. i don't think that
> sslogger provide any of those features, and i'm sure there are more
> advantages on running standard syslog daemon (ie. no additional network
> daemon exposed infrastructure-wide, some complex routing and relaying
> rules between data centers, and possibly others).
> 
> performance-wise i think it shouldn't be a problem, as most of
> interactive sessions are being run with ssh, so any server that can
> handle concurent interactive sessions should be also able to log them in
> real time.
> 
> the biggest problem i can see here is that there is a need to abstract a
> structured stream data for centralized logging, so that anybody can
> attach some "sink" and - on the other side "consumer" that will be able
> to parse and search logs like sudoreplay does currently with plain
> files.
> 
> one nice solution would be to use some structured data (like json or
> yaml with proper encoding) and pipe it into external process, which may
> implement data storage or transport (either with relp, rest or whatever
> is suitable for site administrator). the same deserialized structured
> data should be subject for analysis and reporting. it may be needed to
> assume given (fixed) layout of structured logs (splited accross files
> and directories) on receiver side, which should take into account
> that multiple sources (originating servers) may be multiplexed in
> output or sorted by directories.
> 
> once we would have a plugin that could export such structured data i'd
> be very happy to write experimental adapters for relp and/or restful api
> in some scripting language to evaluate its performance and suitability
> for centralised deployments.
> 
> what do you think? is anybody else working on similiar approach?
>