Chapter 10 |
Modules and SNMP |
This section covers the following topics:
RFC 1903 defines the RowStatus textual convention to manage the creation and deletion of conceptual rows using SNMP. To provide support for management of SNMP tables in a module, the table must:
To support SNMP management of a table, a managed property that stores the state of each row is required. This managed property must inherit from the ROWSTATUS primitive and is typically hidden from the end-user. Nodes that inherit from ROWSTATUS primitive do not need to inherit from any data or alarm types. These values are set automatically by the ROWSTATUS primitive.
<node> = { [ use ROWSTATUS MANAGED-PROPERTY ] ... consoleHint:hidden = true }
To be able to distinguish rows in the table, an instance node in the table is required. The index qualifier for the table refers to this node. The instance node must also specify a instance data format. Typically, the specific instance value for each row is specified by the user when adding a row.
<table entry node> = { [ use MANAGED-OBJECT-TABLE-ENTRY ] index = <instance node> ... <instance node> = { [ use STRING MANAGED-PROPERTY ] dataFormat = instance } ... }
Managed properties whose values must be specified by a user when a row is added in the table must specify the following qualifier:
required = true
dataFormat = { instance | nospace | unicode | boolean | list:<a>|<b>|... | timex}
where:
- instance indicates that the value entered cannot contain any white space or special characters such as \ & * $. This is required for the instance node.
- nospace indicates that the value entered cannot contain any spaces.
- unicode indicates that the value entered does not need to be restricted to ASCII characters.
- boolean indicates that parameter iw displayed as a yes/no check box when adding a row. The value that is set to the agent is a 1 or 0, respectively.
- list:<a>|<b>... specifies "|" separated list that is displayed as a picklist when adding a row. To internationalize the values, the list elements can be replaced with <a>,base.modules.<module><-subspec>:<keya>. <keya> is the key in the Properties file corresponding to the internationalized text used for display purposes. <a> is the value set in the agent if that option is selected.
- timex indicates that the value entered must conform to the required time specification. Using this value also places an Advanced... button in the row adder window to facilitate the entry of the time specification.
Shown below are fragments of the model file for the Filesize table module from the Appendix C.
Support is provided for actions operating on the entire table or an individual row in the table. These global actions are initiated after the completion of an SNMP set of one or more rows in the table. Global set actions are executed only once for a entire row or table, as opposed to individual actions performed for every column in which a SNMP set is done, for example, a table with N columns whose values must be written to a file.
If a new row is created, the new data could be written to the file in one of two ways:
To provide support for global actions, each node whose value must be set before the global action is executed must inherit from one of two primitives:
<node> = { [ use <globprimitive> <data/alarm type> MANAGED-PROPERTY ] { ... |
where:
- <node> is the name of the node whose value must be set before the global action is executed.
- <globprimitive> is either GLOBTABLENODE or GLOBROWNODE.
- <data/alarm type> is the data and/or alarm type primitive.
If multiple nodes in a table inherit from the global primitives, they must all use the same primitive. In this case, the global actions are only executed after an SNMP set to all nodes inheriting from the global primitive is complete.
The difference between the two primitives is that the GLOBROWNODE executes the global actions for each row that has been set. The GLOBTABLENODE executes the global actions once only, regardless of the number of rows that were set. For example, if a table containing nodes that inherit the GLOBTABLENODE primitive, has 2 rows added using a single SNMP set, the global actions are only executed once. However, if the table nodes inherited from the GLOBTABLEROW primitive, the global actions are executed twice. Once for each row that was set.
A managed object (cannot be used for managed properties) can be assigned an icon to display in the Sun Management Center console. To do so, the following must be specified in the node:
consoleHint:smallIcon(DFT) = stdimages/<name>16x16-j.gif consoleHint:largeIcon(DFT) = topoimages/<name>32x32-j.gif
By convention, the larger icon (32x32) is used only in the topology view in the Sun Management Center console. In all other instances, the smaller icon (16x16) is used in the Sun Management Center console.
When adding support for SNMP table management, the table must specify which of its managed properties must have its values set in order to create a new row. The value of the remaining managed properties of the table is set to a predefined default value when a new row is created.
To indicate which managed properties must have their values set to create a new row, the managed property must be made externally SNMP-writable. For more information on rw access, refer to "To Specify a Managed Property as Writable".
When using the Sun Management Centerconsole to add a new row, the values for all writable managed properties can be specified by the user. If you wish to have a managed property that is SNMP writable, but not have its value specified using the Sun Management Center console, use:
access = rw
consoleHint:editAccess = ro
By default, all nodes have consoleHint:editAccess set to rw. As indicated above, all non-writable managed properties of table must specify a default value. The managed property is initialized to this value when a new row is created. If non-writable node does not specify a default value, the set to create a new row fails. To specify a default value, use:
defaultvalue = <value>
The default value can also be specified for SNMP writable nodes. In this case, the default value is presented to the user in the Sun Management Center console when creating a new row.
The Sun Management Center agent supports the ability to execute user-defined actions that are triggered when a managed property is created or when values are set into the managed property. The specification for user actions is:
<type>Actions[(<qualifier>)] = <action> [<action> <action> ... ]
where:
- <type> is the type of event used to trigger the execution of the actions. The available <type> of actions are described in the following sections.
- <qualifier> is optional and dependent on the <type> of actions to execute.
- <action> is a space separated list of logical names of the actions to be executed in the order that they are listed.
- Each action name must be associated with a corresponding service and command that is used to execute the action.
<type>Service(<action>) = <service> <type>Command(<action>) = <command>
- where:
- <service> is the service used to run the command. Conceptually, the <command> is sent to the service to be run.
- <command> is the command that is run.
The specific actions of <type>s are described in the following sections.
User-defined actions can be executed before or immediately after a MIB node has been created.
_
To specify actions to be executed before the node is created, use:
activateActions(pre) = <action> [<action> ...]
_
To specify actions to be executed after the node is created, use:
activateActions(post) = <action> [<action> ...]
A service and command must be defined for each <action> specified:
|
For example, to set a default value (0) for a scalar node use:
|
The Sun Management Center agent MIB supports the specification of actions to be executed when the value of MIB objects are set. Managed property values can be set by the data cascade from a refresh command or from external SNMP sets. For a node to allow sets by external SNMP sets, the node must be made to be SNMP-writable. This is done using:
access = rw
At several points during the set value process, user-defined actions can be triggered. The set value process consists of:
1. | Prevalidate the set. |
2. | Set the value (no actions can be defined at this stage). |
3. | Post-set check for ROWSTATUS nodes only. |
4. | Post-validate the set. |
5. | Row set actions for ROWSTATUS nodes only. |
6. | Set actions. |
If any of these actions (after the prevalidate step) fails, the value automatically rolls back to its preset value. User-defined rollback actions can also be specified. Each of these actions is described in the next section.
Prevalidate actions can be specified to execute before a value is set into a managed property. The purpose of prevalidate actions is to ensure that the value can be set into the node. Nodes that inherit from the ROWSTATUS and TESTANDINCR primitives have predefined prevalidate actions. User-defined pre-validate actions can be defined using:
validateActions(pre) = <action> [<action> ... ]
The service and commands for each <action> must be defined using:
validateService(<action>) = <service> validateCommand(<action>) = <command>
The parameter %value is available to the <command> for reference. The <command> must return a 0 if the validation was not successful. Returning a zero value generates an inconsitentValue SNMP error and the value is not set.
Nodes that inherit from the ROWSTATUS primitive (see "Adding Support for SNMP Table Management" in the previous chapter), have predefined postrow actions. Users can also specify postrow actions. These actions are triggered to execute after the set but before the postvalidate actions. These actions can be specified using:
postrowActions(<rowstatus state>) = <action> [ <action> ... ]
where:
- <rowstatus state> is the state of the ROWSTATUS node corresponding to the value that is set into it. TABLE 10-1 lists the allowable states.
TABLE 10-1 Allowable rowstatus States SNMP Set Value
State
0
doesNotExist
1
active
2
notInService
3
notReady
4
createAndGo
5
createAndWait
6
destroy
For each <action> specified, a service and command must be defined.:
postrowService(<action>) = <service> postrowCommand(<action>) = <command>
The value and row index parameters are available to the <command> using %value and %index respectively. <command> must return a 0 if the action was not successful. Returning a zero value generates an inconsitentValue SNMP error and the object returns to its pre-set value. A zero return code also triggers any user-defined rollback actions.
Post-validate actions can be specified to validate the set value. Nodes that inherit from the ROWSTATUS, GLOBROWNODE, and GLOBTABLENODE primitives have predefined postvalidate actions. User-defined postvalidate actions can be defined using:
validateActions(post) = <action> [<action> ... ]
The service and commands for each <action> must be defined using:
validateService(<action>) = <service> validateCommand(<action>) = <command>
The parameter %value is available to the <command> for reference. The <command> must return a 0 if the validation was not successful. Returning a zero value generates an inconsitentValue SNMP error and returns the object to its preset value. A zero return code also triggers any user-defined rollback actions.
If validateActions(post) actions are specified for a node that inherits from either the GLOBROWNODE or GLOBTABLENODE primitives the actions list must include incrglob. For example:
validateActions(post) = myaction incrglob
The incrglob service and command are predefined and need not be stated again.
Nodes that inherit from the ROWSTATUS primitive have predefined setrow actions. Users can also specify setrow actions. These actions are triggered to execute after the post-validate check but before the set actions. These actions can be specified using:
setrowActions(<rowstatus state>) = <action> [ <action> ... ]
where:
- <rowstatus state> is the state of the ROWSTATUS node corresponding to the value that is set into it. The allowable states are described in TABLE 10-1.
For each <action> specified a service and command must be defined:
setrowService(<action>) = <service> setrowCommand(<action>) = <command>
The value and row index parameters are available to <command> using %value and %index respectively. <command> must return a 0 if the action was not successful. Returning a zero value generates an inconsitentValue SNMP error and returns the object to its preset value. A zero return code also triggers any user-defined rollback actions.
Set actions are triggered after all validation checks have passed and the value has been set. All nodes that have an <alarm type> specified as well as nodes that inherit from the ROWSTATUS, GLOBROWNODE and GLOBTABLENODE primitives have predefined set actions. User-defined set actions can be specified using:
setActions = <action> [<action> ... ]
If no setActions are specified, the value of the object is set to the value specified in the set.
An asterisk (*) can be prepended to a single action to indicate that the value returned by the corresponding setCommand must be the value set into the object at the end of the execution of the setActions. If more than one action has a (*) prepended to it, the return value from the last action with the (*) is used. If no action has an (*) prepended, the value remains as it was set.
Each set action must specify a service and a command:
setService(<action>) = <service> setCommand(<action>) = <command>
The value that was set as well as the row name and corresponding index for tables can be referenced by the <command> using %value, %rowname, and %index respectively.
If the setService is a shell service and if the setCommand script returns any data on stderr, the set action fails. Any data returned, from stdout for a script or Tcl return value can be used as the new value for the object.
If setActions actions are specified for a node that inherits from either the GLOBROWNODE or GLOBTABLENODE primitives the actions list must include decrglob, for example:
setActions =+ myaction decrglob
- The decrglob service and command are predefined and need not be stated again.
CODE EXAMPLE 10-2 Set Actions setObjectNode = { access = wo setActions = *run_script run_tcl_proc decrglob setService(run_script) = _services.sh setCommand(run_script) = script.sh %value setService(run_tcl_proc) = otherObject setCommand(run_tcl_proc) = tcl_proc %value }
Rollback actions are triggered if the set, postrow, postvalidate or setrow actions fail. Nodes that inherit from GLOBROWNODE and GLOBROWTABLE primitives have predefined rollback actions. The purpose of rollback actions is to restore the state of the object after the failed set. Rollback actions can be specified using:
rollbackActions = <action> [<action> ... ]
Each <action> specified must have a service and command defined.
rollbackService(<action>) = <service> rollbackCommand(<action>) = <command>
If rollbackActions actions are specified for a node that inherits from either the GLOBROWNODE or GLOBTABLENODE primitives the actions list must include clearglob, for example:
rollbackActions = myaction clearglob
The clearglob service and command are predefined and need not be stated again.
Tables that support global table or row actions can specify global actions using:
globActions = <action> [ <action> .. ]
Each <action> specified must also define a service and command to execute.
globService(<action>) = <service> globCommand(<action>) = <command>
The value that was set plus the row name and corresponding index for tables can be referenced by the <command> using %value, %rowname, and %index respectively.
These global action qualifiers must be specified in the table node that inherits from the MANAGED-OBECT-TABLE-ENTRY primitive.
The Sun Management Center agent MIB supports the specification of multiple levels of SNMP read or write access controls. These access control (ACL) specifications define the minimum security level required of users and/or groups to perform SNMP read or write operations on objects in the MIB.
ACLs for the module can be specified in any node. If the ACL is specified in a branch, the ACL applies to the entire subtree (unless it is overridden by another ACL specification in an inferior node). ACLs specified in a leaf apply to the leaf node only.
ACLs are specified using the following format:
userAccess(<userName>,<accessType>) = <securityLevel> groupAccess(<groupName>,<accessType>) = <securityLevel>
where:
- <userName> can be a UNIX user name or a logical user or community name. Logical user and community names are defined below.
- <groupName> can be a UNIX group or a logical group name. Logical group names are defined below.
- <accessType> can be read or write and is the SNMP operation that is to be controlled.
- <securityLevel> can be none, priv, auth or noauth and defines the minimum level of security required for this type of access.
In general, if the default ACLs are insufficient, module designers must specify their own ACLs at the root node of the module. Where applicable, additional ACLs can be specified for specific subtrees and nodes within the module.
Note - As a design rule, UNIX users and groups must not be hard-coded for <userName> and <groupName> respectively. Doing so assumes that such users and groups always exist. Instead, the use of logical users and groups is encouraged.
Logical users, groups, and community names are used to enable module designers to grant access to the MIB based on a space separated list of UNIX users, UNIX groups, and community names that is modifiable at run-time. The list of UNIX users and groups must be defined in the UNIX domain of the Sun Management Center server layer and are logically OR'ed together to determine membership.
Three levels of logical users, groups, and community names are defined:
- admin--users, groups, and communities belonging to this category are able to perform all operations
- operator--users, groups, and communities in this category are allowed to perform selected operations.
- general--users, groups, and communities in this category have read access only
- To specify logical users in the ACL specifications use %adminUsers, %operatorUsers, or %generalUsers for the three different levels of logical users.
- To specify logical groups in the ACL specifications use %adminGroups, %operatorGroups, or %generalGroups for the three different levels of logical users.
- To specify logical communities in the ACL specification use %adminCommunities, %operatorCommunities, and %generalCommunities.
The default memberships to the logical users, groups, and communities are defined in the file agent-acls-d.dat and are specified as:
CODE EXAMPLE 10-3 Default Memberships to Logical Users, Groups and Communities %adminUsers = %operatorUsers = %generalUsers = %adminGroups = esadm %operatorGroups = esops %generalGroups = ANYGROUP %adminCommunities = %operatorCommunities = %generalCommunities = public
These default values can be overridden by copying this file to /var/opt/SUNWsymon/cfg and modifying it. The esadm and esops UNIX groups are created during installation. The keyword ANYGROUP is not a true UNIX group, but rather is a special keyword that means that any user that was allowed to log into Sun Management Center.
Note - The UNIX groups esadm and esops are only required to be defined in the UNIX domain where the Sun Management Center server layer is running. That is, the Sun Management Center server layer resolves all logical user and group lists.
The possible security levels that can be specified for <securityLevel> in the ACL specification are:
CODE EXAMPLE 10-4 Default ACL settings for All Nodes |
userAccess(%adminUsers,read) = auth userAccess(%operatorUsers,read) = auth userAccess(%generalUsers,read) = auth userAccess(%adminUsers,write) = auth userAccess(%operatorUsers,write) = auth userAccess(%generalUsers,write) = none groupAccess(%adminGroups,read) = auth groupAccess(%operatorGroups,read) = auth groupAccess(%generalGroups,read) = auth groupAccess(%adminGroups,write) = auth groupAccess(%operatorGroups,write) = auth groupAccess(%generalGroups,write) = none userAccess(%adminCommunities,read) = noauth userAccess(%operatorCommunities,read) = noauth userAccess(%generalCommunities,read) = noauth userAccess(%adminCommunities,write) = noauth userAccess(%operatorCommunities,write) = noauth userAccess(%generalCommunities,write) = none
These specifications define the following behavior:
The following examples demonstrate how ACLs can be specified and what impact they will have.
CODE EXAMPLE 10-5 Specifying Authenticated/Encrypted SNMP get and set Requests |
userAccess(fly, read) = auth userAccess(fly, write = auth
CODE EXAMPLE 10-6 Specifying Requests without SNMP set operations for UNIX User |
userAccess(fly, read) = auth read) = auth userAccess(fly, write) = auth write) = none
CODE EXAMPLE 10-7 Permitting admin/operator to Perform SNMP get and set |
userAccess(%adminUsersread) = auth userAccess(%adminUserswrite) = auth userAccess(%operatorUsersread) = auth userAccess(%operatorUserswrite) = auth groupAccess(%adminGroupssread) = auth groupAccess(%adminGroupsswrite) = auth groupAccess(%operatorGroupsread) = auth groupAccess(%operatorGroupswrite) = auth
For modules that support SNMP management of tables, ad hoc commands can be added to manage table rows from the Sun Management Center console. These commands can be used to add, remove, edit, disable and enable rows.
In the following examples, only the italicized parts of the commands must be replaced. Others, such as %targetHost, are keywords and should be typed in exactly. For more information on the URL syntax, refer to Appendix E.
![]() |
To Add a Row |
The commandSpec to add a row to a table is:
consoleHint:commandSpec(<command>) = launchUniqDialog
%windowID .templates.tools.rowadder objectUrl=snmp:// %targetHost:%targetPort/mod/<path to table entry>#%targetFragment
where:
<path to table entry> is a slash (/) delimited path to the table node that inherits from the MANAGED-OBJECT-TABLE-ENTRY primitive.
![]() |
To Remove a Row |
The commandSpec to remove a row from a table is:
consoleHint:commandSpec(<command>) = requestTableRowOperation %windowID snmp://
%targetHost:%targetPort/mod/<path to rowstatus \ node>#%targetFragment unload
where <path to rowstatus node> is a slash (/) delimited path to the table node that inherits from the ROWSTATUS primitive. This action sets the state of the rowstatus node for this row to destroy.
![]() |
To Edit a Row |
The commandSpec to edit an existing row in a table is:
consoleHint:commandSpec(<command>) = launchUniqDialog
%windowID .templates.tools.roweditor objectUrl=snmp://
%targetHost:
%targetPort/mod/<path to table entry>#%targetFragment
where <path to table entry> is a "/" delimited path to the table node that inherits from the MANAGED-OBJECT-TABLE-ENTRY primitive.
![]() |
To Disable a Row |
The commandSpec to disable a row in a table is:
consoleHint:commandSpec(<command>) = requestTableRowOperation
%windowID snmp://%targetHost:%targetPort/mod/<path to rowstatus \
node>#
%targetFragment disable
where:
- <path to rowstatus node> is a slash (/) delimited path to the table node that inherits from the ROWSTATUS primitive. This action sets the state of the rowstatus node for this row to notInService.
![]() |
To Enable a Row |
The commandSpec to enable a row in a table is:
consoleHint:commandSpec(<command>) = requestTableRowOperation
%windowID snmp://
%targetHost:%targetPort/mod/<path to rowstatus node>#
%targetFragment enable
where:
- <path to rowstatus node> is a slash /) delimited path to the table node that inherits from the ROWSTATUS primitive. This action sets the state of the rowstatus node for this row to active.
![]() |
To Load a Module Instance |
For modules that can be loaded multiple times, the consoleHint:commandSpec qualifier requires the %targetInstance specification.
For example, if the Solaris example module can be loaded multiple times, then the consoleHint:commandSpec for the top probe query is:
consoleHint:commandSpec(top) = probeview
%windowID snmp:// %targetHost:
%targetPort/mod/solaris-example+
%targetInstance/system load?runadhoccommand.top
CODE EXAMPLE 10-8 Adhoc SNMP Table Management Commands |
# Examle for using adhoc snmp table management commands # Additional data model realization specifics pertaining to the # mySystems object in the solaris-example-d.x file. mySystems{ [ use templates......] myTable = { myEntry = { consoleHint:tableCommands = enable disable unload addrow editrow consoleHint:commandLabel(enable) = enable consoleHint:commandSpec(enable) = requestTableRowOperation %windowID snmp://%targetHost:%targetPort/mod/fscan+%targetInstance/fscanstats\ /myTable/myEntry/rowstatus#%targetFragment enable consoleHint:commandLabel(disable) = disable consoleHint:commandSpec(disable) = requestTableRowOperation %windowID snmp://%targetHost:%targetPort/mod/fscan+%targetInstance/fscanstats\ /myTable/myEntry/rowstatus#%targetFragment disable consoleHint:commandLabel(unload) = unload consoleHint:commandSpec(unload) = requestTableRowOperation %windowID snmp://%targetHost:%targetPort/mod/fscan+%targetInstance/fscanstats\ /myTable/myEntry/rowstatus#%targetFragment unload consoleHint:commandLabel(addrow) = addrow consoleHint:commandSpec(addrow) = launchUniqueDialog %windowID .templates.tools.rowadder objectUrl=snmp://%targetHost:%targetPort\ /mod/fscan+%targetInstance/fscanstats/myTable/myEntry#%targetFragment consoleHint:commandSpec(addrow) = \ launchUniqueDialog %windowID .templates.tools.rowadder objectUrl=snmp://%targetHost:%targetPort\ /mod/fscan+%targetInstance/fscanstats/myTable/myEntry#%targetFragment consoleHint:commandLabel(editrow) = editrow consoleHint:commandSpec(editrow) = launchUniqueDialog %windowID .templates.tools.roweditor objectUrl=snmp://%targetHost:%targetPort/mod/\ fscan+%targetInstance/fscanstats/myTable/myEntry#%targetFragment consoleHint:tableHeaderCommands = addrow rowstatus = { [ use _procedures ] setrowService() = fscanstats setrowActions(active) = on setrowCommand(on) = activatePattern %index %rowname setrowActions(notInService) = off setrowCommand(off) = deactivatePattern %index %rowname setrowActions(createAndGo) = add setrowActions(createAndWait) = add setrowCommand(add) = addPattern %index %rowname %newvalue setrowActions(destroy) = remove setrowCommand(remove) = removePattern %index %rowname } } } }
CODE EXAMPLE 10-9 Additional Objects to the Solaris Example Model d.x File |
#Additional object to the solaris-example-model-d.x file mySystems = { [ use MANAGED-OBJECT ] mediumDesc = example myTable = { [ use MANAGED-OBJECT-TABLE ] mediumDesc = myTable consoleHint:mediumDesc = myTable myEntry = { [ use MANAGED-OBJECT-TABLE-ENTRY ] mediumDesc = my Entry index = idnum consoleHint:mediumDesc = my Entry rowstatus = { [ use GLOBROWNODE ROWSTATUS MANAGED-PROPERTY ] shortDesc = row status mediumDesc = Row Status fullDesc = The row status consoleHint:hidden = true consoleHint:mediumDesc = Row Status } idnum = { [ use INT MANAGED-PROPERTY ] shortDesc = number mediumDesc = ID Number fullDesc = ID number consoleHint:mediumDesc = ID Number } name = { [ use STRING MANAGED-PROPERTY ] shortDesc = name mediumDesc = Users Name fullDesc = Users Name required = true consoleHint:mediumDesc = Users Name } hobby = { [ use STRING MANAGED-PROPERTY ] shortDesc = hobby mediumDesc = Users Hobby fullDesc = Users hobby consoleHint:mediumDesc = Users Hobby } } } }
When the value of one or more managed properties changes in the module, the agent can notify the console immediately of the changes by sending a refresh trap. The refresh trap command should be executed in the context of the managed property (that is, the MIB node ) that is being refreshed. These commands can be included either in the .prc file or the .flt files.
The following are the different ways of sending refresh traps:
_
refreshValueAndTrap When this command is executed in the context of a MIB node, it refreshes the value of the node by running the appropriate refreshCommand, sends a trap to the server, thus notifying the console of the changes in that node, and the console updates the GUI with the new values.
_
setTrapInfo refreshOID When this command is executed in the context of a MIB node, it sends a trap to the server indicating that the values of that node has been refreshed. The console upon receiving the refreshed values updates the GUI.
CODE EXAMPLE 10-10 Example of the Agent File |
Example: Agent File .. .. .. createNode = { [ use _procedures ] type = passive access = rw setActions = cmd setService(cmd) = _internal setCommand(cmd) = runShellCmd %value %rowname } AnotherNode = { .. .. type = active initInterval = 2 refreshService = _services.sh refreshCommand = get-data.sh refreshInterval = 300 } .. .. # The corresponding procedure file .. .. .. proc runShellCmd{ val rowname} { # Do some processing .. .. set file [ open /tmp/$rowname w ] puts $file "Refresh in progress" close $file toe_send [ locate anotherNode ] setValue 0 $val toe_send [ locate anotherNode ] setTrapInfo refreshOID set file [ open /tmp/$rowname w ] puts $file "Refresh Successful" close $file .. .. }
The mib2x tool allows you to:
The <module>-models-d.x file defines the data model of the corresponding module. It also define the OIDs corresponding to the data modeled.
Using this tool, you can generate the data model file of an SNMP MIB with ease, and you can plug in additional qualifiers for the data as required by your module. This speeds up the data model creation part of the module development, when you are developing the module from an already existing SNMP MIB.
The mib2x syntax is:
/opt/SUNWsymon/sbin/es-run mib2x -f <filename> [-r [<prefix>:]<root>] [-m <mode>] [-b <base mibs directory>] [-i <index directory>] [-a <additional mib files to import>]
The following table describes the syntax and its options.
TABLE 10-2 mib2x Syntax and Options Syntax
Description
Req'd
Default
-f <filename> The absolute path to the ASN.1 MIB file read by mib2x (specify the file's directory name along with the file name)
Yes
None
-r [<prefix>:]<root> Specifies the starting node of the output of mib2x. mib2x only prints out information on the mib tree under this node. If the optional <prefix> is specified, node names are prefixed with the path from <prefix> to <root>.
For example, if iso:sun is specified, then the output is:
iso/org/dod/internet/private = 1.3.6.1.4
iso/org/dod/internet/private/enterprises = 1.3.6.1.4.1
iso/org/dod/internet/private/enterprises/sun = 1.3.6.1.4.1.42
No
iso
-m <mode> <mode> can be: syntax|oid|module:
syntax prints out variable name to syntax mapping oid prints out variable name to OID mapping module converts ASN.1 MIB text files to agent module definition file. Must specify the -r option
No
oid
-b \ <base mibs directory> The directory that contains the basic MIB file required by mib2x.
No
<Install_Dir_of_Sun Management Center>/util/cfg
-i <index directory> The directory that contains the machine dependent directory with frozen images of the MIB files.
No
/tmp
-a \ <list of mib files> The list of mibs files is used to resolve import clauses in <filename>. For example: -a "file1 file2 file3"
No
-
The output of mib2x is always written to the standard output. You can redirect this output to an appropriate file.
![]() |
To generate the models file for the MIB file mymib.txt and to store the output in
mymib-models-d.x, enter the following command:
|
![]() |
To generate the OIDs for the MIB file mymib.txt and to store the output in
mymib-oids.dat, enter the following command:
|
Note - When using the mib2x utility, you may sometimes see messages, such as:
mib2x: unknown macro NOTIFICATION-TYPE Using branch.
mib2x: unknown macro MODULE-COMPLIANCE. Using branch.
mib2x: unknown macro OBJECT-GROUP. Using branch.
These messages are harmless. The mib2x utility models the nodes using the above macros as branches in the module.