TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
On Nov 17, 10:18am, Audra Eng wrote:
> Subject: Re: Backing up log file
>
> TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message
to
> [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any
problems!
> --------------------------------------------------------------------------
--
>
> Have the log automatically synchronize to the console at a certain % full
> on the engine log... The console database is an Access Database, and the
> name of the file is rsclientlog.mdb - I believe. If you would like to see
> an archival function put into the product, email [EMAIL PROTECTED]
>
> thx,
> Audra Eng
Just to point out a couple of other related factors here. On our Solaris
engine we occasionally (sometimes too often) see the engine core and die
when the autosync goes wrong - the raw files on the engine are 'corrupt'
(whatever that actually means) and all data is lost. If I do not use
the autosync and the raw files hit the maximum then the engine also
cores and dies. Either way we lose the IDS functions except in the
non-autosync mode the database can be transferred to the mgmt console.
I would be interested to hear if anyone else has found a workaround?
The bug is elusive and obscure so I am not taking a swipe at ISS - wish
it was predictable as they would have been able to fix it.
As for backing up the db files on the mgmt NT box - I simply copy them
a month or week at a time to a folder on another disk, stop monitoring
that engine, delete by date range, shut down the console application
and then use Access' database utility tools to 'compact' the mostly
empty rsclientlog.mdb, then re-start (after exiting Access of course so
that the lock file is available).
The one real enhancement I would like to see is the engine keep flinging
stuff to the console event logs even if it cannot write to the
database (with lots of visual/audible/mail alerts, etc) so that I
can at least see what we missed rather than it crashing out entirely.
Hopefully it could also keep functioning with the mail/rst-kill/opensec
handling aspects. I guess I ought to write a script to keep looking for
the core file and then move the NETWORK_ENGINE.* files and stop/start
the init scripts - now there is a good reason for choosing UNIX!
As for the logs - having multiple weekly or monthly copies of old
rsclientlog.mdb can be a pain as I haven't found a way to merge them
all back in to one db when I am looking for similar or other events
over time.
Great product though and buying Crystal Reports was a lot easier than
trying to work with Access.
Cheers
Neil
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr Neil J Long, Computing Services, University of Oxford
13 Banbury Road, Oxford, OX2 6NN, UK Tel:+44 1865 273232 Fax:+44 1865
273275
EMail: [EMAIL PROTECTED]
PGP: ID 0xE88EF71F OxCERT: [EMAIL PROTECTED] PGP: ID 0x4B11561D
