Re: Using script(1) to log all user sessions

[Karel Zak <kzak@redhat.com>]

On Fri, Apr 25, 2014 at 10:21:34AM +0200, Jesper Dahl Nyerup wrote:
> Firstly, script(1) is clearly and sanely designed to be invoked from the

 Well, from my point of view it current code is a bit fragile regards
 to signals. Maybe it would be nice to use signalfd() and check for
 signals together with changes on master/slave file descriptors by
 select/poll. But this is not so important for your plans.

> command line to record a limited portion of a user's session. In order
> for the user to have the logging started without manual invocation, it
> may come in handy to support config files, to supply configurable
> default values for some of the concepts normally passed in the
> environment or as command line arguments.

 OK.

> Secondly, we're considering to add functionality for script(1) to
> transmit the session transcript over the network to a collection daemon,
> to be able to store transcripts from multiple machines on one or more
> central systems.

 Hmm.. "Every program attempts to expand until it can read mail. Those
 programs which cannot so expand are replaced by ones which can."

 I like git concept: here are files and it's your problem to transfer the
 staff over the network. You can use rsync, http, ssh, ...

 Maybe all you need is to store timing and typescript data to the one
 place (e.g. /var/log/typescripts/user/<timestamp>.{session,timing})
 and use ssh or so to transfer the data to another place.

> 1. Adding a daemon next to script(1) and scriptreplay(1), eg.
> scriptcollect(1), to be in the receiving end of the traffic, optionally
> handling the timing functionality, and finally storing data in the same
> manner script(1) would.

 Seem like overkill.

> 2. Optionally linking against some crypto library to avoid putting
> users' console data on the wire in clear text.

 Yep, but we have generic solutions like ssh, again see git.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com