TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
Hello All,
I find that relying on the Realsecure Console to "be there" for alerts isnt good
enough, especially in a complex environment where Realsecure has many sensors and you
rely on it to a certain extent. This is becuase should you close the application, you
lose all state and require manual intervention to reconnect all sensors to get things
going again.
We have heard that ISS wil release a seperately licensed Enterprise Console in a
future release. I do hope that some of the functionality that I describe below will be
included.
We have chosen to send SNMP Traps to HP OpenView, as the product runs on one of our
high end unix systems its considered "more stable and robust".
The MIB that ISS supplies does work with Openview network node manager to an extent,
in that it does a certain amount of pre-filtering of traps and assigning values within
the traps to variable fields which can then be massaged into a more attractive format
by a skilful Openview IT/O administrator.
I do not know how the MIB works with other SNMP trap receiver products.
In this context the function of the Realsecure Console is deprecated to that of a
reporting station. But, in order to achieve this, you must automate the data download
using some sort of script and process automation based around Enginemgr.
I had not yet got around to rotating the database, but this is what I am looking at
right now. As I plan to integrate Decisions "real soon now", I dont want zero the
database (SSD will do that via the Safelink Agent), just ensure that
a) it isnt corrupted by ensuring that we have adequate backups of it (and I have been
bitten by this)
b) the file doesnt exceed 1GB, or we need to take some remedial action.
What I read here implies that I CANNOT have the Realsecure console running when I wish
to copy or backup the database or I will get a sharing error, is this correct?
Stephen
>>> "Lindley, Jim (ISSAtlanta)" <[EMAIL PROTECTED]> 05/12/00 19:58:09 >>>
TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
Your project manager may be confused about the difference between RS
responses. "Sending alerts to the console" is a separate response from
"logging to the sensor's db files." Using the enginemgr -a getdb does not
interfere with the sensor sending alerts to any monitoring console. The
only requirement is that the enginemgr used needs to be on the Master
Controller console. But both the master console GUI and all non-master GUIs
will continue to receive alerts.
Unless the master console is listening, automatic db sync will not take
place. So your alternative (as designed) is either manual sync or using the
enginemgr.
For enginemgr, open up an alternative GUI (no additional license required),
catch the alerts on the alternative while closing the master, copying the
rs*.mdb as backup, and copying an empty rs*.mdb over the now backed-up
original. As another alternative, place an empty rs*.mdb, open the master
console's database administration option tab, and redirect the sensor data
flow by changing the target of the RS DSN to point to the empty rs*.mdb. I
don't believe you have to close down the master for the dataflow to re-flow.
But, of course, I'm always subject to being wrong.
8-{)}
BTW, using the database admin tab also allows you to cancel an exclusive
lock on the rs*.mdb during normal operations. (Once, again, I think!).
Jim Lindley
-----Original Message-----
From: Tim Brown [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 10:49 AM
To: [EMAIL PROTECTED]
Subject: RS Console DB Backup/LogSwitch
We are in the midst of deploying RealSecure and need some advice on
console log switching and backup. The person working this project six
months ago came up with a rexx script that uses enginemgr to synch the
sensor DB prior to doing a kill on rsconsole.exe and then copying the
mdb to another location. The last step is to copy an empty DB back to
the realsecure directory. The problem this solution creates is the
inability to restart the console and reattach to the sensors and
establish master console status.
Without the console started, will the automatic db synch take place from
the sensor when the DB threshold limit is hit on the sensor? When I
look at netstat on the console workstation it is not listening on the
port needed to allow this communication without the console being active
and the sensor being actively monitored. I called ISS last week and was
was told this is a known issue and a product enhancement has been
requested from engineering that would allow the console to automatically
start monitoring sensors when the console is started. I have suggested
to the Project Mgr. running enginemgr -a getdb on a set schedule to sync
the DB, but this is not viable since our she wants the visual alerts to
go to the console at all times. I also suggested we get away from the
console for visual alerts and rely on SNMP traps for the visuals. We
have Spectrum, but I have not found a plug-in for the RealSecure OIDs.
What are other people doing with SNMP traps sent from RealSecure?
Back on the backup issue. Has anyone had any success in backing up the
Console DB while the console is actively monitoring sensors? It appears
to me rsconsole.exe has an exclusive lock on the rsntclientlog.mdb while
running. Could a sensor synching to console log during the backup cause
some problems? A way around this would be to stop the engines during
the backup using enginemgr, but this would mean no ID during that time.
Wouldn't it be great if the console had options to synch the sensors and
age the DB on a scheduled interval (i.e. 24 hours)?
Any suggestions are appreciated?
--
Tim Brown ([EMAIL PROTECTED])
Network Analyst
Office of Information Technology Services (ITS)
State of North Carolina
DISCLAIMER: Any e-mail messages from the Bank for International Settlements are sent
in good faith, but shall not be binding nor construed as constituting any obligation
on the part of the Bank.
CONFIDENTIALITY NOTICE: This e-mail contains confidential information, which is
intended only for the use of the recipient(s) named above. If you have received this
communication in error, please notify the sender immediately via e-mail and return the
entire message. Thank you for your assistance.
