Profiles for Different Users (Essential SNMP)

B.3. Profiles for Different Users

Some users may have specific ways in which they want to use NNM. For example, an operator who is watching the network for problems may need a fairly limited set of menus and tools; a senior network engineer might want a substantially larger set of options. You can use the $OV_REGISTRATION directory and the $OVwRegDir environment variable to customize NNM on a per-user basis.

The previous section shows how to add menus by modifying files in the $OV_REGISTRATION/C directory. By default, this is the directory NNM uses when it starts. However, you can create as many profiles as you need under the $OV_REGISTRATION directory. Once you have created another profile directory, you can change the $OVwRegDir environment variable to point to that new directory. Then, when NNM starts, it will use the new profile.

One way to set up user-specific profiles is to create an account that anyone can use for starting an NNM session. With this account, the network map is opened read-only [76] and has only the minimal menus ("File Figure B.3

Exit," "Map Figure B.3

Refresh," "Fault Figure B.3

Alarms," etc.). Create a new profile for this account in the directory $OV_REGISTRATION/skel by copying all the files in the default profile $OV_REGISTRATION/C to the new skel directory. Then modify this profile by removing most of the menu choices, thus preventing the operator from being able run any external commands.[77] To start NNM using this profile, you must point the $OVwRegDir environment variable to the new profile directory. To test the new profile, give the following Bourne shell commands:

[76]When starting NNM via the command line, use $OV_BIN/ovw -ro to open the default map in read-only mode. This will prevent the user from making any map changes (moves, add, deletes, etc.).

[77]Just because a map is opened read-only does not mean that users cannot make changes to the backend of NNM. A user who has the ability to launch the menu items can make changes just like the superuser can. The best way to prevent these changes is to take out any/all configuration menu options.

[root][nms] /> OVwRegDir=/etc/opt/OV/share/registration/skel
[root][nms] /> export OVwRegDir
[root][nms] /> $OV_BIN/ovw

Once you're confident that this new profile works, create an account for running NNM with minimal permissions and, in the startup script for that account, set $OVwRegDir appropriately (i.e., to point to your skeleton configuration). Then make sure that users can't run NNM from their normal accounts -- perhaps by limiting execute access for NNM to a particular group, which will force users not in that group to use the special account when they want to run NNM. You should also make sure that the users you don't trust can't modify the $OV_REGISTRATION directory or its subdirectories.