|
|
This chapter contains the following sections:
This section is meant to provide additional information for the configuration of event processing (refer to the the "Configuring Event Processing" section of "Configuration Management"), and includes the following topics:
Before you can set up e-mail notification, complete the steps for setting up the event processing infrastructure in the "Configuring Event Processing" section of "Configuration Management."
Then follow these steps:
Step 1 In the currently applied version of nrConfigure, double-click Event Processing.
The Event Processing dialog box opens.
Step 2 Click the E-mail tab (see Figure 9-1).
Step 3 Type a valid Organization ID in the Organization ID field.
Step 4 Under Event E-mail Addresses, edit the fields to customize what type and level of alarm triggers a notification to recipients.
Click Add to add rows to the listing, and click Delete to delete rows from the listing.
Each row has five columns:
(a) Event Type---Select either IP Logs, Errors, Commands, or Alarms from the field's drop-down list.
(b) Severity Level---Type a number. Valid numbers are 1 through 5.
(c) Source and Destination---Select IN, OUT, or EITHER from the field's drop-down list.
(d) Recipients---Type the e-mail address of the person to notify. You can type more than one recipient using commas to delimit the list, for example:
root,user1,user2
Step 5 Click OK to close the Device Management dialog box.
Writing and using custom notification scripts with NetRanger requires some knowledge of how the /usr/nr/bin/eventd/event script works. This script gathers information about alarms, errors, and commands and stores this information in variables. The script can then be configured, through nrConfigure, to pass this parsed data to your custom script.
The nrSnmpTrap script operates on this principle, taking NetRanger security data parsed by the /usr/nr/eventd/event script and creating SNMP traps via existing HP OpenView functionality. For more information on SNMP traps, refer to the "SNMP Support" section of this chapter.
To create a custom script that understands the /usr/nr/eventd/event parsed data, follow these steps:
Step 1 Create a new file with a text editor.
Step 2 Include the contents of Example 9-1 and Example 9-2 (which can be found on the following pages) in your script, in that order. These listings will make the data parsed by the /usr/nr/eventd/event script understandable by your script.
Step 3 Complete your custom script and save your work.
Step 4 On the Director, start nrConfigure by clicking Configure on the Security menu.
Step 5 In the currently applied version, double-click Event Processing.
The Event Processing dialog box opens.
Step 6 Click the Applications tab.
Step 7 Click Add to add your custom script.
Step 8 Type a severity level and the name of your custom script.
Step 9 Click OK to close the Event Processing dialog box.
Step 10 Refer to the "Configuring an Event Source to Send Events to eventd" section of "Configuration Management" to send notifications to your custom script.
Example 9-1 provides a listing of the common parsed message fields for NetRanger alarms, commands, and errors.
MessageType=${1}
RecordID=${2}
GlobalTime=${3}
LocalTime=${4}
DateStr=${5}
TimeStr=${6}
ApplID=${7}
HostID=${8}
OrgID=${9}
The following variables are common to all NetRanger data:
Example 9-2 displays the decision mechanisms that populate fields that are specific to errors, commands, and alarms.
if [[ $MessageType -eq 2 ]]; then
ErrorMessage=${10}
else
if [[ $MessageType -eq 3 ]]; then
SrcApplID=${10}
SrcHostID=${11}
SrcOrgID=${12}
CommandMessage=${13}
else
if [[ $MessageType -eq 4 ]]; then
SrcDirection=${10}
DstDirection=${11}
EventLevel=${12}
EventSigID=${13}
EventSubSigID=${14}
ProtocolType=${15}
if [[ "${ProtocolType}" = "TCP/IP" ]]; then
SrcIpAddr=${16}
DstIpAddr=${17}
SrcIpPort=${18}
DstIpPort=${19}
SourceAddr=${20}
EventMessage=${21}
fi
fi
fi
fi
If the record is an error message, then the contents of the error message is stored in the variable $ErrorMessage.
If the record is a command, then the following variables are populated:
If the record is an alarm, then the following variables are populated:
If the protocol type in $ProtocolType is TCP/IP, the following variables are populated:
This section describes the following topics:
SNMP defines a standard, cross-platform protocol for sending unsolicited messages to a network management platform. Using SNMP allows the Director to send NetRanger events to a non-HP OpenView platform.
HP OpenView provides SNMP Event Browsers, which allow viewing of both NetRanger and non-NetRanger events on the same display. Along with an Event Browser, HP OpenView also provides trap filtering, processing, and customization utilities that allow execution of other actions when certain traps are received.
There are two ways to generate SNMP traps with NetRanger:
To generate SNMP traps using eventd's infrastructure, refer to the "Configuring Event Processing" section of "Configuration Management."
To generate SNMP traps manually, follow these steps:
Step 1 On the Director interface, click one or more Alarm/Alarm Set icons.
Step 2 Click Create>SNMP Trap on the Security menu.
After configuring NetRanger to generate SNMP traps, you can use HP OpenView's built-in SNMP Event Browser to view SNMP traps.
To view SNMP traps, follow these steps:
Step 1 On the Director interface, deselect any previously selected icons.
Step 2 If your Director machine has OpenView 4.x or 5.x, click Events on the Fault menu.
If your Director machine has OpenView 6.x, click Alarms on the Fault menu.
Traps are displayed as a comma-delimited string of values, with the following fields:
MessageType, RecordID, GlobalTime, LocalTime, DateStr, TimeStr, ApplID, HostID, OrgID
The MessageType can be Error, Command Log, or Alarm, which are defined as follows:
In HP OpenView, a filed named trapd.conf stores all SNMP traps in ASCII format. This allows you to use standard UNIX tools like grep and awk to generate reports.
HP OpenView allows you to automate certain actions when certain traps are received.
To enable automated event processing of SNMP traps, click Event Configuration on the Options menu.
You can generate a popup window whenever an alarm trap is received by following these steps:
Step 1 If your Director machine has OpenView 4.x or 5.x, click Events on the Fault menu.
If your Director machine has OpenView 6.x, click Alarms on the Fault menu.
Step 2 Double-click your organization name in the list of enterprises.
Step 3 Double-click the trap.
Step 4 To generate a popup window when an alarm trap is received, type the following information in the Popup Notification field:
Alarm! Sig: $13, Src: $16, Dst: $17
To disable SNMP functionality, follow these steps:
Step 1 On the Director interface, click Configure on the Security menu.
Step 2 Double-click the currently applied version of code (it will display in bold).
Step 3 Double-click Event Processing.
The Event Processing dialog box opens.
Step 4 Click the Applications tab.
Step 5 Remove the line that contains the nrSnmpTrap script.
Step 6 Click OK to close the Event Processing dialog box.
Step 7 On nrConfigure, click Apply.
Step 8 Double-click Director Forwarding.
The Director Forwarding dialog box opens.
Step 9 Click the Forwarding tab.
Step 10 Click the eventd entry and click Delete.
Step 11 Click OK to close the Director Forwarding dialog box.
Step 12 Close nrConfigure by clicking Exit on the File menu.
If you change a Sensor's IP address, or change its NetRanger communication infrastructure characteristics (like Host ID, Org ID, Host Name, or Organization Name), you must ensure that the appropriate configuration files have been changed on all your NetRanger machines, including the Director machine.
If you are only changing a Sensor's IP address, follow these steps:
Step 1 On the Director interface, click Configure on the Security menu.
nrConfigure opens.
Step 2 On nrConfigure, double-click the Sensor icon for which you want to change the IP address.
Step 3 For the currently applied configuration version, double-click the System Files folder.
Step 4 Double-click Routes.
The Routes dialog box opens.
Step 5 Change the Sensor's IP address to the new value and click OK.
Step 6 Highlight the newly created transient version, click Save, and then click Apply.
Step 7 Click Close.
Step 8 Log on to the Sensor as user root.
Step 9 Type sysconfig-sensor to run sysconfig-sensor.
Step 10 Type 1 and type the same IP address that you entered into nrConfigure.
Step 11 Type x to exit sysconfig-sensor.
Step 12 On the Director interface, delete the Sensor icon by clicking it and clicking Delete>From All Submaps on the Edit menu.
Step 13 On nrConfigure, double-click the Director icon.
Step 14 For the currently applied configuration version, double-click the System Files folder.
Step 15 Double-click Routes.
The Routes dialog box opens.
Step 16 Change the Sensor's IP address to the new value and click OK.
Step 17 Highlight the newly created transient version, and click Save and then Apply.
Step 18 Click Close.
If you need to change a Sensor's Host ID and/or Org ID, follow these steps:
Step 1 On the Director interface, click Configure on the Security menu.
nrConfigure opens.
Step 2 Right-click the Sensor icon and click Delete Host from the popup menu.
Step 3 On the Director interface, delete the Sensor icon by clicking it and clicking Delete>From All Submaps on the Edit menu.
Step 4 Log on to the Sensor as user root.
Step 5 Type sysconfig-sensor to run sysconfig-sensor.
Step 6 If you need to change the Sensor's IP address or netmask, choose the appropriate options from the sysconfig-sensor menu before changing the NetRanger communication parameters.
Step 7 Type 7 and type the new values when prompted.
 | Caution When you change a Sensor's Host ID and/or Org ID, you are in effect creating a new Sensor which has to be completely reintroduced to the NetRanger communications network. |
Step 8 Type x to exit sysconfig-sensor.
Step 9 Complete the steps outlined in the "Complete the Sensor Configuration" section of "Installation and Configuration."
It is not recommended that you change a Director's IP address, Host ID, or Org ID. Doing so necessitates that you disable all NetRanger services while you change NetRanger information on all Sensors and Directors that communicate with the Director, and then restarting all the disabled services on all systems.
If you need to change the Director's parameters, consult the Technical Assistance Center for assistance.
This section describes the following topics:
All OVw Applications have registration files that instruct the User Interface (OVw) how to treat the application. On HP systems, registration files are kept in $OV_REGISTRATION/C. Registration files contain the command that launches the OVw Application. Editing the OVw Application's command-line parameters in the registration files help you customize your user interface environment.
The command line parameters are:
All of nrdirmap's command line parameters are summarized in Table 9-1.
| Parameter | Function | Example |
|---|---|---|
-a | Sets the default Alarm consolidation threshold for new maps (default is 2) | |
-c | Sets the default Critical value threshold for new maps | |
-d | Disables nrdirmap for new maps by default | |
-f | Forces Full synchronization between database and maps | |
-k | Keeps icon copies during delete | |
-m | Sets the default Marginal value threshold for new maps | |
-o | Sets the maximum number of Objects represented on any map | |
-s | Secures new map creation | |
-t | Enables Tracing | |
An alarm consolidation threshold is configurable for each Application icon represented in the map.
The "-a" option is used to define a new default alarm consolidation threshold. This default value is applied to all application objects that are created after you change the default value. For example, if all of the application icons in your map have an alarm consolidation of 2, and then you set the "-a" option to 5, then whenever a new application is created, the new application will have the threshold of 5. The "-a" option has no effect on existing application entities.
The default is 2. A value of 0 means no alarm consolidation. Any integer that is zero or higher is valid.
By default, if nrdirmap receives an event with a severity level of 4 or higher, the icon that represents that alarm will have "Critical" status. Unless the user specifies otherwise, an icon with Critical status is displayed as red.
A critical value threshold is configurable for each application object that is represented in the map.
The "-c" option is used to define a new default critical value threshold. This default value is applied to all application objects that are created after you change the default value. For example, if all of the application icons in your map have a critical threshold of 4, and you set the "-c" option to 3, whenever a new application is created, the new application will have the threshold of 3. The "-c" option has no effect on existing application entities.
By default, when a new map is created, nrdirmap is enabled, which means that nrdirmap will display security information on the new map. If you prefer nrdirmap to be disabled for new maps by default, add the "-d" option to the nrdirmap registration file.
See "Limiting Access to NetRanger Director Security Information" in this chapter for more information about enabling and disabling nrdirmap.
By default, when an icon that exists in multiple maps is deleted from a map, the icon will not be redrawn on the map when the user interface is stopped and restarted. After you delete an icon from a map, the icon is deleted permanently. Once an icon is deleted from all maps, the object that the icon represents is deleted from the object database.
It is possible to have objects in the database that might not be represented as icons in one or more of your maps (for instance, if you have two maps with the same alarm on them, and you delete an alarm icon from the first map, the alarm object is still in the database, but there is no icon for that object in the second map).
To "refresh" a map to ensure that all objects in the database are represented on a map, use the "-f" option. This forces nrdirmap to represent all objects in the database as icons on a map.
By default, when you delete an entity (for instance, a machine, application, or alarm) from a submap in the Director submap hierarchy, all icons for the entity are removed from the map. If you make a copy of an icon and then delete the original icon, nrdirmap deletes the copy of the icon, too. If you want to keep copied icons on the map when you delete a NetRanger icon, use the "-k" option.
Use the default setting unless you have a specific reason to create and retain icon copies.
By default, if nrdirmap receives an event with a severity level greater than or equal to 3 and less than the critical threshold value (discussed previously), the icon that represents that alarm will have "Marginal" status. Unless the user specifies otherwise, an icon with Marginal status will appear yellow.
A marginal value threshold is configurable for each application object that is represented in the map.
The "-m" option is used to define a new default marginal value threshold. This default value is applied to all application objects that are created after you change the default value. For example, if all of the application icons in your map have a critical threshold of 3, and then you set the "-m" option to 2, then whenever a new application is created, the new application will have the threshold of 2. The "-m" option has no effect on existing application entities.
The nrdirmap application creates an object in the OpenView Windows Object Database (ovwdb) for every Alarm (or Alarm Set) icon represented in a map. If the number of objects in the Object Database grows beyond a certain level, OpenView performance can deteriorate and in extreme cases, OpenView can fail.
To prevent these problems, nrdirmap by default represents no more than 10,000 entities (alarms, machines, applications, etc.) in a map at a given time and no more than 1,000 icons on a given submap (window). If a new event comes in that would cause nrdirmap to exceed either of these threshold values, then nrdirmap prints a warning message to standard out and then redirect the alarm data to a buffer file in /usr/nr/var for safekeeping, thus ensuring the integrity of your OpenView data.
To pull the buffer data from the file into the OpenView user interface, delete enough alarms from the user interface (using the Delete Object menu function) to reduce the number of icons and database objects and then bring the user interface down and back up again. nrdirmap reads the file and creates the new alarm icons.
If you are routinely receiving tens of thousands of severe alarms in short periods of time from a given application, you should consider redefining the security policy on your Sensor, or increase the Minimum Marginal Status Severity level for that application object.
High-end workstations with plenty of RAM may be able to handle more than 10,000 objects in a map. If you want to increase (or decrease) this maximum number of Objects value, add the text "-o" value to the nrdirmap registration file. It is not recommended that value exceed 50,000. If you increase this value, you may wish to increase ovwdb's cache size by editing the $OV_LRF/ovwdb.lrf file to improve ovwdb's performance (see the appropriate OpenView documentation for more information).
The 1000 icons per submap (window) limit is not configurable because this limitation is based on the number of pixels that can be devoted to a window, rather than a value that is user-configurable (such as RAM, disk space).
Use this option to ensure that only authorized users can create maps that contain NetRanger information. When the "-s" option is enabled, maps with nrdirmap enabled can only be created from maps that already have nrdirmap enabled. This ensures that a user who does not have access to nrdirmap-enabled maps (and therefore, does not have access to security information) will not be able to create a map that has nrdirmap enabled.
Refer to the "Limiting Access to NetRanger Director Security Information" section in this chapter for more information about enabling and disabling nrdirmap.
If nrdirmap is malfunctioning, your authorized service representative might instruct you to enable tracing by adding the "-t" option. After you set this option, it is best to bring down the user interface, and then bring it back up by typing the following command:
ovw > /usr/nr/tmp/nrdirmap.out
To enable tracing, type the following in the registration file:
Command -Shared -Initial -Restart "nrdirmap -t";
To create marginal icons for level 2 alarms and critical icons for level 3 and higher alarms, type the following in the registration file:
Command -Shared -Initial -Restart "nrdirmap -m 2 -c 3";
To enable tracing and to create Alarm Sets once 15 similar alarms are received, type the following in the registration file:
Command -Shared -Initial -Restart "nrdirmap -t -a 15";
When you click a Machine or Application icon and click Show Current Events on the Security menu, the last 100 events associated with that entity are displayed (if less than
100 events are known, then all of the events are displayed). To change the number of events that are displayed, use a text editor to modify the nrdirmap file, which is stored in $OV_REGISTRATION/C on HP and Sun systems, and /usr/OV/registration/C on IBM systems.
As illustrated in Example 9-3, replace the "100" with the number of your choice on the line shown in bold.
Action show_events {
SelectionRule (isWheelGroup && (isMachine || isApplication));
MinSelected 1;
Command "sh -c `unset OVwSessionLoc \;
$OV_BIN/xnmappmon \
-selectList \" ${OVwSelections} \" \
-commandTitle \" Show Current Events for \" \
-appendSelectList \
-appendSelectListToTitle \
-multipleDialogs \
-headingLine 2 \
-geometry 900x600 \
-followOutput \
-unbufIO \
-stopSignal 9 \
-cmd /usr/nr/bin/filterLogByHostApp -l 100' ";
}
This section provides information on the functions that allow modifications to the OpenView user interface, and includes the following topics:
| Caution The user interface allows a user to change data in ways that can confuse the nrdirmap application. This section describes which user modifications are allowed and which are not. |
You can make Object Modifications in OpenView 4.x and 5.x by clicking an object and clicking Describe/Modify Object on the Edit menu. In OpenView 6.x, click
Object Properties on the Edit menu.
You can change the Comments field, or any attribute field that is editable from the window that is accessed by selecting NetRanger/Director and clicking View/Modify Object Attributes. Any changes you make to an object applies to all maps. Remember that icons are map-specific, but database objects are shared among all maps.
You should not edit the Selection Name. The Selection Name field is a field that is used to uniquely identify an object.
To make icon modifications, follow these steps:
Step 1 Click the icon on the Director interface.
Step 2 If your Director machine has OpenView 4.x or 5.x, click Modify Symbol on the Describe menu.
If your Director machine has OpenView 6.x, click Object Properties on the Edit menu.
You can change the Display Label setting, and you can change an icon from explodable to executable.
| Caution Do not change the icon status source. nrdirmap expects all icons (except alarm icons) to have Compound Status Source. This ensures that an alarm's status is always propagated upward in the submap hierarchy. Changing the status source jeopardizes the upward propagation of the alarm's status. |
| Caution Do not change the icon type. Doing so will cause capability fields in the object database to change, and this will affect many different functions---including synchronization and callback communication between nrdirmap and ovw. |
To make submap modifications, follow these steps:
Step 1 On the Director interface, navigate to the submap you want to modify.
Step 2 If your Director machine has OpenView 4.x or 5.x, click Submap>Describe/Modify on the Map menu.
If your Director machine has OpenView 6.x, click Submap>Properties on the Map menu.
You can change the Comments and the Background Graphics fields.
When an icon has Compound Status Source, the status (color) of the icon is based solely on the status of the icon(s) in that icon's child submap. OpenView provides the user with user-selectable sets of "rules" that the User Interface uses to determine the status of an icon based on the status of the icons in the child submap. These rulesets are called Compound Status Source Propagation Schemes, and the ruleset you choose affects the color of the icons on the map.
To change the status propagation scheme, follow these steps:
Step 1 If your Director machine has OpenView 4.x or 5.x, click Maps>Describe/Modify on the Map menu.
If your Director machine has OpenView 6.x, click Maps>Properties on the Map menu.
Step 2 Click Propagate Most Critical.
Step 3 Click OK.
Refer to the documentation provided with your network management platform for more information about Compound Status Source.
In OpenView there are special ASCII files called Application Default files that contain parameters, which, when customized, can change the look and feel of certain applications. To change fonts, window sizes, colors, etc. for the user interface in general, edit the OVw file which is in $APP_DEFS.
To modify the attributes of the various XNm applications, modify the XNm* files. The Show Current Events window uses an application called xnmappmon (X-Node Manager Application Monitor) to display data. If you want to change the appearance of this window, make the necessary modifications to this file.
The NetRanger Director supports the use of multiple OpenView Windows (ovw) maps. Using multiple maps in OpenView is a complex operation, so consider reading the appropriate OpenView documentation before creating multiple maps.
Multiple maps have special rules regarding database objects and multiple users:
To create a customized map for a user, either click Maps>New on the Map menu, or use the "-m" command-line parameter when invoking ovw (see the appropriate OpenView documentation for details).
When the new map is created, nrdirmap represents all of the objects in the database on the new map. Once the new map has stopped synchronizing, you can click Delete on the Edit menu to remove the icons that you do not want represented on the map.
Usually, Machine icons are deleted to create a "user domain" with a subset of the configured Sensor Machines.
If you delete a Machine from one map, but the Machine is also represented on another map, and that Machine generates an alarm, then the alarm is only represented on the map containing the Machine.
If you delete the Machine from all maps, then the machine object will be deleted from the database. If that Machine generates a new alarm, then a new database object will be created for that Machine, and the Machine will be represented on all maps again.
If you have a Sensor that sends alarms to the Director, but you do not want the Sensor Machine to be represented on any maps, you should reconfigure the Sensor machine to stop sending the alarms to the smid process running on the Director. This prevents nrdirmap from receiving the events and creating the Sensor Machine icon. If you still want the events from the Sensor Machine to be logged in the Director machine, but not displayed by nrdirmap, configure the Sensor Machine to send events to the loggerd daemon on the Director rather than the smid daemon.
If you want to put back icons that you previously deleted, there are two things you can do if the objects that the icons represented are still in the object database.
1. You can click Add Object on the Edit menu to add the object back to the map.
nrdirmap only creates icons for alarms that are received after the machine/application are added to the map. If you want to add a Machine or Application that already exists in the database and you want to also see what alarms already exist, use Option 2.
2. If you have many objects that you want to add back to the map, it might be faster to bring the user interface down, and then add the "-f" option to the nrdirmap registration file. This forces nrdirmap to represent all objects in the database on the map. Refer to "Customizing the Director with nrdirmap Options" earlier in this chapter for more information on the "-f" option.
If one map is open (being viewed with ovw) and a second map is closed, and an event comes in, an alarm is displayed on the open map. If the alarm is deleted from the open map before the second map is opened, then the alarm is deleted from the database, and the alarm will not be represented on the second map when the second map is opened. On the other hand, if the second map is opened before the alarm is deleted from the first map, the alarm will be read from the database and will be represented in the second map.
This section provides information on multi-user support in HP OpenView, and includes the following topics:
Some additional configuration of your Director system is required if more than one user needs access to the HP OpenView user interface. To decide what configuration is needed, consider the following three questions:
1. Will some users need access to the HP OpenView user interface but not to NetRanger data?
2. Will multiple users need concurrent HP OpenView user interface sessions that access NetRanger data?
3. Do users need access to NetRanger data from their current Unix accounts, or must they log on to the Director as user netrangr?
Knowing the answer to these questions helps you with the following tasks:
The way to deny access to NetRanger data is to:
The exact procedure for this can be found in the "Limiting Access to NetRanger Director Security Information" section of this chapter.
If you need concurrent access to NetRanger data, then you may need to create multiple nrdirmap-enabled maps. For more information about concurrent access, refer to the "Running Multiple User Interface Sessions Concurrently" section of this chapter.
The nrdirmap application will operate with full functionality only if it is run by a user in the Unix group netrangr. At install time, a netrangr account is created for you that is in the netrangr group. If you do not want your users to have to log on as the user netrangr to have full access to nrdirmap, then you must modify each user's Unix accounts to be in the Unix group netrangr, and then make a few additional modifications.
For more information, refer to the "Configuring Non-netrangr Users" section of this chapter.
This section provides information on limiting access to Director security information, and includes the following topics:
There are functions in the NetRanger Director and in HP OpenView that can be used together to control which HP OpenView users have access to security management information.
If you have multiple users who have permissions to run the HP OpenView user interface, but if you want only a subset of those users to be able to view security information, read the following section.
Limiting access to security information is done by disabling the nrdirmap application for one or more HP OpenView maps. Once nrdirmap is disabled for a map, nrdirmap does not try to display security information on that map.
Once you have one or more maps that have nrdirmap disabled, and one or more maps that have nrdirmap enabled, you can set the permissions of the HP OpenView maps to limit which users can access which maps. The result is that only the users with permissions to open the nrdirmap-enabled maps have the ability to view security information.
nrdirmap can be disabled on a per-map basis. You must decide whether or not to disable nrdirmap whenever you create a new map.
Disabling nrdirmap can be done in two different ways, depending on how the map is created:
1. If you create the map by clicking Maps>New on the Map menu, click NetRanger/Director on the list of configurable applications, and click Configure. The following message appears:
Should nrdirmap be enabled for this map?
Choose True to enable nrdirmap or choose False to disable nrdirmap. The default is False if the "-d" option appears in the nrdirmap registration file; the default is True otherwise.
2. If you create the map from the command line using the ovw "-m" option, nrdirmap is disabled if the "-d" option appears in the nrdirmap registration file; nrdirmap is enabled otherwise.
All users who should have access to security information must be in the group netrangr. Furthermore, all users who should not have access to security information should not be in the group netrangr.
On HP systems, users can be added to and removed from groups using the SAM utility. On Sun systems, the admintool can be used.
After you have created your maps, you can use the ovwchgrp and ovwchmod commands to set map permissions.
Maps that have nrdirmap enabled should be readable by users who have access to the
/usr/nr subdirectory. This means that maps that have nrdirmap enabled should be owned by the group netrangr, and/or be owned by a user who is in the group netrangr.
Ensure that map permissions are set so that the nrdirmap-enabled maps are not readable by people not in the netrangr group. For example, to allow only the user netrangr and users in the group netrangr to read and write a map called default, type:
ovwchown netrangr default ovwchgrp netrangr default ovwchmod 660 default
Use the $OV_BIN/ovwls command to list the maps and verify the permissions.
In the following procedure, two maps are created. The map called secinfo has nrdirmap enabled, and it will be accessible only by the user angie and by other users in the group netrangr. The map called nosecinfo has nrdirmap disabled, and it will be accessible only by the user bob and users in the group staff.
Step 1 Ensure that user angie is in the Unix group netrangr.
Step 2 Ensure that user bob is not in the Unix group netrangr.
Step 3 Log on as user angie.
Step 4 Create the secinfo map by typing:
ovw -m secinfo &
Step 5 Set secinfo's permissions by typing:
ovwchown angie secinfo ovwchgrp netrangr secinfo ovwchmod 660 secinfo
Step 6 To create the nosecinfo map, click Maps>New on the Map menu.
Step 7 Type nosecinfo as the map name, click NetRanger/Director on the list of configurable applications, and click Configure.
Step 8 Choose False in response to the following question:
Should nrdirmap be enabled for this map?
Step 9 Click OK to create the nosecinfo map.
Step 10 Set nosecinfo's permissions by typing the following:
ovwchown bob nosecinfo ovwchgrp staff nosecinfo ovwchmod 660 nosecinfo
The map viewable by user bob will not contain security information, but the map viewable by user angie will.
HP OpenView allows more than one copy of the user interface (ovw) to be run at the same time. How the user interface sessions behave depends on which HP OpenView maps are being accessed by the ovw sessions.
Only one user interface session can have a particular map open with read/write access at a time. If the same map is opened by two or more concurrently running ovw sessions, then the first ovw session with the proper map permissions obtains a read-write copy of the map, and all other sessions are granted read-only access.
If you need concurrent access to NetRanger data, but you do not mind read-only access for some users, then you will only need a single nrdirmap-enabled map. If you do mind read-only access, then you will have to create multiple maps, and then assign each map to a particular user. For more information on creating multiple maps, refer to the "Creating and Using Multiple Maps" section of this chapter.
The NetRanger Director supports the use of read-only user interface sessions. Using read-only maps in HP OpenView is somewhat complex, so consider reading the appropriate HP OpenView documentation before using read-only maps.
Here are some things to remember about read-only maps:
It is possible to configure your Director system to allow users other than netrangr to view NetRanger data with the HP OpenView user interface (ovw).
Configuring other users to view NetRanger data is somewhat complex and requires knowledge of how to create Unix accounts and modify user profiles. Consult a Unix system administrator if necessary. Because of the complex nature of this task, Cisco Systems only supplies limited support for this functionality.
To configure a non-netrangr account to view NetRanger data, you must do the following:
After these steps are completed, nrdirmap should function correctly and completely when the user opens a map that has nrdirmap enabled.
Please note the following caveats:
Posted: Wed Jul 19 15:19:42 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.