Re: using screen logs

[Trent W. Buck]

"Jae Norment" <address@hidden> writes:

> I fairly pretty uncomfortable running any of the solutions presented
> here: I know enough about C/C++ to know that it's pretty easy to write
> code that can be pretty destructive to an instance of an operating
> system.  The last thing I want to do is bring down the production
> servers that I'm maintaining that are important enough to make
> activity logs with a program designed to make the logs readable...

The obvious solution would be to copy the log to somewhere non-critical
(such as your desktop) and run the log scrubber there.

> I ended up cobbling something together with Python.  Thanks to the
> suggestions from Micah Cowan and Will Stevenson, I had source code to
> look at while cobbling...

Python isn't going to be significantly less destructive than C; they are
both general-purpose languages and their processes will have the same
access (unless you are using a customized selinux).  I suppose you could
argue that it's easier to write underhanded C than underhanded Python.

The benefit you got from writing your own solution was probably that, as
a side-effect, you audited the existing solutions.  Personally I'd be
more inclined (in general) to trust a mature program to work as desired
than an untested rewrite of it I built myself. YMMV, etc.

As for security auditing, I recommend you read _Reflections on Trusting
Trust_ to understand just how limited your ability to take an "I don't
wanna run someone else's untrusted code" policy is.

> I should probably get in the habit of cat'ing the files I change,
> before and after the changes made, so that the changes are included in
> the maintenance logs...

I strongly recommend using version control.  This captures not only what
has changed, but (theoretically) who did it, and why.

For version-controlling a server's configuration (i.e. the contents of
/etc), there is a package called "etckeeper" which integrates with the
package manager and (in recent versions) also commits unrecorded changes
daily, by default.  This means that you can ask the VCS (e.g. git)

    WTF?  Why is resolv.conf using the wrong search domain?  Who did
    this, when, and why?

And get a reasonably coherent answer.  If etckeeper isn't available for
your platform, then you can do it by hand.  Historically I have used RCS
for this, because it's lightweight and (was) ubiquitous.

I realize that tracking changes to /etc doesn't include the output of
your equivalent of "apt-get upgrade", which I guess is the primary thing
you're trying to track in screen logs above.  But I think it is an
excellent supplementary tracking system.

PS: if you are trying to use screen logging to track edits to files in
/etc, I recommend you avoid graphical editors like vi and mg.  Instead
you would want to use a line editor like ed (or GNU sed --in-place),
since changes made with these editors will be easier to understand when
looking at a printout of the session.