TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
> 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".
This is also what we do and it works extremely well - it allows us to
integrate the alerting into our current 24x7 monitoring and allows other
actions to be taken on certain events.
> 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
Erm, Your mileage may vary but we have found that although SSD will clean up
its own files it does not manage the database of the datasource being sunk.
i.e. You still need to manage file growth within the original databse even
if you are using SSD. If you manage to get this working we would be
extremely interested in the details.
ISS have published an unsupported method to rotate databases within RS at
http://www.iss.net/customer_care/resource_center/realsecure_tech_center/
under Tip & Tricks [Because that is the right place for a utility like this,
right ? Rather than the Utilities tab - sure...]
File Name:RSdbcopy.zip
Description:This program was designed to make backup copies of the
RSNTCLIENTLOG.MDB File use by ISS RealSecure. The program will copy and
rename an existing database and replace a blank one for you.
That might be just what you are looking for - we have implemented this
functionality ourselves within the scripts we use to getdb from the CLI for
each agent without using this utility but there is no reason why everyone
else should re-invent the wheel - in the loop that goes around each agent we
check that db size is <500meg before starting each sync - if it isn't then
we rotate the db and start syncing to a new blank one.
The main problem we have with this is then we have to manually put these
"full" dbs back and kick off a manual SSD sync to copy the data across -
we'd love SSD to clear the database on RS as it copied it across then we
could just run an hourly SSD job and never have to worry - hint hint ISS.
We do not have a console running during the database actions as we do a move
out of the "full" db and then a move in of a blank one. If you really need
the console then the suggestion to run a backup one without taking Master
status (despite having to manually release it for each agent you manage from
that console) [ISS request - why not have a optional setting within the
console to choose if it tries to take Master status for the agents you
connect to?] and manually having to distribute the new keys to each agent
[ISS request - why not allow an option to push additional keys for other
consoles from the current Master ?] will allow you to have continual
monitoring via the GUI without the database ever becoming an issue on that
device.
Another disadvantage of the CLI is that all the features like the auto-sync
and the highwater mark no longer function but until the GUI can keep state
between being stopped and started and can support > 250 agents at one time
there is no real way a large site can use it.
Stephen
-----Original Message-----
From: Stephen Cooper [mailto:[EMAIL PROTECTED]]
Sent: 06 December 2000 12:21
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: RS Console DB Backup/LogSwitch
***********************************************************************
IMPORTANT - This email originates from the Internet & therefore may not
be from the apparent sender.
If you have any doubts about the origin or content of the email please
contact PC Support on ext. 2288.
***********************************************************************
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.
----------------------------------------------------------------------
The information contained in this e-mail is confidential and solely for
the intended addressee(s). Unauthorised reproduction, disclosure, modification,
and/or distribution of this email may be unlawful. If you have received
this email in error, please notify the sender immediately and delete it
from your system. The views expressed in this message do not necessarily
reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies.
----------------------------------------------------------------------
