7.3 Defining Custom Symbols and FieldsCustom device symbols may be created and used in NNM submaps. The process requires creating the symbol using a bitmap editor, creating the class registration file (optional), and creating the subclass registration file. Both the class and subclass registration files are Symbol Registration Files (SRFs). 7.3.1 Description of the SRFWhen creating custom symbols, you must decide whether or not to use an existing symbol class. To display existing symbol classes, select Edit $OV_SYMBOLS/C . SRFs must be located in this directory structure. Create a separate subdirectory for each symbol class. The symbol class and subclass files are located in the same directory. The symbol class file defines the outside shape of the symbol. It also defines some basic attributes of the symbol such as the status source, isComputer , and isNode . The Filebase keyword references the basename of the bitmap to be used for the symbol. You only need to create a class file if you are not using an existing outside shape. Listed below is the Computer class file, which defines the outside shape of a square. 7.3.1.1 The Computer Symbol Class FileSymbolClass "Computer" { Scale 7; Segment (-8, -8) to (8, -8) to (8, 8) to (-8, 8) DefaultStatusSource Compound; DefaultLayout RowColumn; Variety Icon; Filebase "computer"; Capabilities { isComputer = 1; isNode = 1; } } The symbol subclass file resides in the same directory as the symbol class file. The SymbolType keyword defines the class and subclass of the symbol. While the name of the file is not used, the naming convention is class_subclass . For example, the HP-UX subclass filename is Computer_hpux . (The name of the class file is simply Computer .) The Filebase keyword references the basename of the bitmap to be used for the symbol. If a symbol subclass file exists, the Filebase listed in the subclass file overrides the Filebase listed in the class file. The subclass file can also set attributes such as isWorkstation .[2] Listed in the following section is the [2] Many object attributes are set by SNMP queries. Attributes may also be set in SRFs. 7.3.1.2 The HP-UX Symbol Subclass FileSymbolType "Computer" : "HP-UX" { Filebase "hpux"; CursorSize 38; Capabilities { isWorkstation = 1; } } 7.3.2 Creating Your Own SRFSRFs require a symbol class file, a symbol subclass file, and bitmaps. If you plan on customizing bitmaps, obtain a decent bitmap editor. HP-UX ships with the Icon Editor application, which can be used to create and edit bitmaps. For Windows systems, obtain an evaluation copy of Paint Shop Pro® from Table 7-1.
[*] No modification required Because this example uses an existing outside shape (Computer), there is no need to create a new symbol class file. The symbol class Computer is used. The basename of the bitmap described by the Filebase is toaster . The new object attribute isToaster is used to describe the new symbol. New attributes such as isToaster must also be defined in the Field Registration File described in the next section. Create a new subclass file named Computer_toaster in the directory $OV_SYMBOLS/C/Computer with the contents listed. 7.3.2.1 The Toaster Subclass FileSymbolType "Computer" : "Toaster" { Filebase "toaster"; CursorSize 38; Capabilities { isWorkstation = 1; isToaster = 1; } } After creating the bitmap and defining the SRF, create or modify an existing entry in the $OV_CONF/oid_to_sym file. The OID used in this example is that of an HP-UX workstation. The oid_to_sym file entry for this example is: 1.3.6.1.4.1.11.2.3.2.5:Computer:Toaster # The Toaster 7.3 Defining Custom Symbols and Fields After modifying the oid_to_sym file, exit the NNM GUI and update the database for all objects having the same OID by performing the following steps: Stop netmon. ovstop c netmon Update the database entries. ovtopofix a o .1.3.6.1.4.1.11.2.3.2.5 Start netmon. ovstart netmon The toaster symbol should be displayed as shown in Figure 7-13 for any object defined in the oid_to_sym file with the subclass Figure 7-13. The toaster is a custom symbol referenced in an SRF.Verify that the newly added symbol is available from the symbol class in which it was defined. The Toaster symbol was defined in the Computer symbol class. Select Edit?Add Object from any submap. Then select the Computer class to display the subclass Toaster , as shown in Figure 7-14. Figure 7-14. Custom symbols are available from the symbol class when you add an object. The Toaster is listed as a subclass of the Computer symbol class.The toaster SRF file and bitmaps are available for download from the server http://www.phptr.com/title/0130352098 for both Unix and Windows systems. Obtain the Readme file for this chapter for a description of the files available and install procedures. You can parse a Unix or Windows SRF to check for accurate syntax by executing the command ovw verify . While the toaster example might not be the most practical use of a custom symbol, defining symbols might actually be more useful. Tape libraries, disk arrays, and security devices frequently run SNMP agents. However, these devices are displayed with a generic computer when discovered by NNM because there is no custom symbol for the devices, unless the Vendor provides a plug-in application. 7.3.3 Description of the FRFField Registration Files (FRFs) can be used to define new attributes such as isToaster . Attributes are set in Symbol Registration Files as previously defined in the Toaster symbol registration file. Defining a field provides the ability to locate an object by the new attribute. The FRF listed in Section 7.3.3.1 assigns the Boolean attribute isToaster . The keyword locate in the FRF provides the ability to search on the field, as shown in Figure 7-15. Figure 7-15. Custom fields such as isToaster may be used as locatable attributes. To search by attribute, select Edit7.3.3.1 Creating Your Own Field Registration FileField "isToaster" { Type Boolean; Flags capability, locate; } FRFs reside in the $OV_FIELDS/C directory. Whenever you modify existing FRFs or add new ones, you must re-register the fields in the object database. Perform the following steps to re-register the fields: Exit the NNM GUI. Stop the object database: ovstop ovwdb Re-register the object fields: ovw fields Start the object database: ovstart v ovwdb Start NNM and search for the new field isToaster: Edit When the fields are re-registered, start up the NNM GUI and search for object with the newly defined attribute isToaster . If no devices are found, you may need to demand poll the device. Select the symbol and select Fault [Object Properties] , as shown in Figure 7-16. Double-click [Capabilities] to display the isToaster attribute, shown in Figure 7-17. Figure 7-16. Check the Object Properties of the custom symbol to verify the value of a field.Figure 7-17. The isToaster attribute is set to TRUE for the toaster symbols. Fields are defined in the Field Registration Files and referenced in the Symbol Registration Files.The toaster SRF, FRF, and bitmap files are available for download from the server http://www.phptr.com/title/0130352098 for both Unix and Windows systems. Obtain the Readme file for Chapter 7 for a description of the files available and install procedures. You can parse a Unix or Windows FRF for accurate syntax by executing the command ovw fields . If NNM is used as your primary asset database, consider defining and populating fields such as Serial Number, Contract Number, or Product ID. The ability to track fields allows you to find the devices of interest more quickly, allowing better productivity. 7.3.4 Limiting Access to Custom Symbols and FieldsThe $OVwSymbolDir and $OvwFieldDir environment variables may be set to define the symbol and field registration directories for individual users. This is helpful to limit access to symbols and fields. For example, a user might need access to applications that work only with networking devices. The symbols and fields for networking devices might not need to be available to everyone. The SRFs and FRFs can be located in any directory. For example, if custom SRFs are located in /etc/opt/OV/customSymbolDir and custom FRFs are located in /etc/opt/OV/customFieldDiron a Unix system, define the environment variable in a user's export OVwSymbolDir=/opt/OV/share/symbols/C:/etc/opt/OV/ customSymbolDir export OVwFieldDir=/opt/OV/share/fields/C:/etc/opt/OV/ customFieldDir By defining these environment variables, you have limited user access to the SRFs and FRFs. Symbol and field directories are separated by a colon (:). For Windows systems, you could add the custom directories to the user's system variable list or modify and execute the |