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
