Previous Next Contents Generated Index Home


Chapter 9

Additional Specifications for a Module




This chapter covers the following sections:


Additional Parameter Specifications

The following is an example of a Solaris m.x file.



#
# Parameter file for Solaris Example module
#
[ load default-m.x ]
 
#
# Create multiple groups
#
consoleHint:moduleParamGroups = param misc
?misc:?description = base.modules.solaris-example:misc
#
# Specify which parameters belong to which group
#
consoleHint:moduleParams(param) = module i18nModuleName 
i18nModuleDesc version enterprise i18nModuleType
consoleHint:moduleParams(misc) = instance instanceName line 
rootPassword favouriteFood foodGroup
#
# Mandatory Parameters
#
param:module     = solaris-example
param:moduleName = Solaris Example
param:version    = 1.0
param:console    = solaris-example
param:moduleType = operatingSystem
param:enterprise = halcyon
param:location   = 
.iso.org.dod.internet.private.enterprises.halcyon.
primealert.modules.solaris.example
param:oid        = 1.3.6.1.4.1.1242.1.2.90.1
param:desc       = This is an example module monitoring cpu, load, 
and filesystem statistics.
param:i18nModuleName  = base.modules.solaris-example:moduleName
param:i18nModuleType  = base.modules.solaris-example:moduleType
param:i18nModuleDesc  = base.modules.solaris-example:moduleDesc
?param:i18nModuleName?format = i18n
?param:i18nModuleType?format = i18n
?param:i18nModuleDesc?format = i18n
#
# Additional Parameters
#
param:instance      =
param:instanceName  =
param:rootPassword  =



param:favouriteFood = base.modules.solaris\
-example:favouriteFoodValue

param:foodGroup = vegetable
?param:favouriteFood?i18n = yes
 
?param:instance?description = base.modules.default:instance
?param:instance?reqd        = yes
?param:instance?format      = instance
 
?param:instanceName?description = 
base.modules.default:description
?param:instanceName?reqd        = yes
 ?param:line?format              = separator

?param:rootPassword?format      = password
?param:rootPassword?description = base.modules.\
solaris-example:rootPassword
 
?param:favouriteFood?description = base.modules.\
solaris-example:favouriteFood

?param:foodGroup?description = base.modules.\
solaris-example:foodGroup
?param:foodGroup?format = list:meat,base.modules.\
solaris-example:meat|
vegetable,base.modules.solaris-example:vegetable|\
fruit,base.modules.solaris-example:fruit

Example: Solaris m.x File


Additional Parameters

Additional parameters may be specified for the module, and are used to prompt the user for additional information when the module is loaded. For each additional parameter, this file must contain the following lines:

param:<parameter> = <default value>
?param:<parameter>?description = \
base.modules.<module><-subspec>:<key>

where:

<parameter> is an identifying name for the parameter. The name must be a single string with no whitespace.
<default value> is the default initial value for the parameter.
<module> is the module name.
<subspec> is the optional module subspec.
<key> is a key used to look up the internationalized string in the properties file. This key must be unique in the module. When a user loads a module, this string is displayed to the user (along with the default initial value for the parameter).

For every additional parameter there must be an additional entry in the properties file for that module. This entry is the internationalized description (?param:<parameter>?description) for the parameter and has the following format:



<key>=<internationalized text>

where

<key> is the same key used in the Parameter file for the parameter
<internationalized text> is the internationalized string describing the parameter

If you want to internationalize the <default value> of the parameter, then you must replace <default value> with base.modules.<module><-subspec>:<key>.

param:<parameter> = base.modules.<module><-subspec>:<key>

The corresponding line in the module properties file must also be added:

<key>=<internationalized text>

If the internationalized default value is to be editable by the user when the module is loaded, then the following is also required:

?param:<parameter>?i18n = yes

If this value is to be read-only, then ?param:<parameter>?i18n = yes can be replaced with:

?param:<parameter>?format = i18n

or

?param:<parameter>?format = i18ncomment

The i18ncomment indicates that the value is a multiline entry. In this case, the <internationalized text> would have \n to indicate new line separations.

To be able to view additional parameters in the console, each optional parameter that is specified must also be added to the space separated list of the consoleHints:moduleParams(param) specification. The order in which the parameters are displayed in the Sun Management Center console is defined by the order in which the parameters are listed.

consoleHint:moduleParams(param) = module i18nModuleName 
i18nModuleDesc version enterprise i18nModuleType <parameter>


Predefined Additional Qualifiers

Any of the following optional qualifiers can be specified for any parameter:

TABLE  9-1   Predefined Additional Qualifiers 
Parameter
Values
Description
?param:<parameter>?access =   ro|rw  

Specifies if the parameter is read-only (ro) or read-write (rw) access. A parameter with rw access can be edited by the end user when the module is loaded. This does not need to be specified when using ?i18n = yes. Default is rw.

 

?param:<parameter>?editaccess =   ro|rw  

Specifies if the parameter can be edited after the module has been loaded (there is an "Edit Module Parameters" function available to the end user from the console). Default is rw.

 

?param:<parameter>?reqd =   yes|no  

yes specifies that the parameter is required. This means that the value must not be left blank when the module is loaded. Default is no.  

?param:<parameter>?format =   separator  

Specifies a dummy parameter that is displayed as a solid line. This is used for console formatting purposes.

 

?param:<parameter>?format =   blank  

This dummy parameter is displayed as a blank line. It is to be used for console formatting purposes.

 

?param:<parameter>?format =   header  

The description and value of this parameter is displayed as read-only in bold and larger font.  

?param:<parameter>?format =   comment  

The value of this parameter is displayed as read-only in a multiline text format.  

?param:<parameter>?format =   boolean  

This parameter is displayed as a yes/no check box.  

?param:<parameter>?format =   list:<a>|<b>|<c>  

Specifies that the parameter can take a list of values. The possible values are specified as "|" separated entries. Each value in the list may include white space. The available options are displayed in a picklist. To internationalize list elements, the elements must be replaced with <a>,base.modules.<module><-subspec>:<keya>. The internationalized text for <keya> is displayed in the console. However, the value <a> is set in the agent. The corresponding <keya> must be added to the module properties file. An example is given at the end of this Chapter.  

?param:<parameter>?format =   password  

Any value entered for this parameter is displayed as *. Also, values of such parameters are returned as a string of asterisks in response to an SNMP get request. This qualifier must be set for parameters such as database administration passwords, which must not be accessible through SNMP get.  

?param:<parameter>?format =   timex  

The value for this parameter must conform to the agent time specification (refer to the Appendix B for more information). An Advanced button is added to facilitate entering the correct time specification.  

?param:<parameter>?format =   timewindow  

Same as timex but only comparison time specifications are allowed. This is used for module active time windows.  

?param:<parameter>?format =   multi-line  

The value of this parameter is displayed as multiline writable text.  

?param:<parameter>?format =   width=<pixels>  

The input field for this parameter remains at the specified fixed pixel size.  

?param:<parameter>?format =   nodisplay  

If no default value for this parameter is set, the parameter will not be displayed.  

?param:<parameter>?format =   unicode  

Allow non-ASCII text to be entered as the value.  

?param:<parameter>?format =   instance  

Specifies that the value must contain at least one alpha character, no whitespace, and no special characters such as \, $, ;, &, and *. This setting must be used for `instance' parameters.  

?param:<parameter>?i18n =   yes  

The default value for this parameter can be edited as multi byte text.  

?param:<parameter>?type =   int  

Restricts the value entered for this parameter to be an integer.  

?param:<parameter>?type =   float  

Restricts the value entered for this parameter to be a floating point value.  

?param:<parameter>?type =   nospace  

Does not allow any spaces in the value entered for this parameter.  


Note - The mandatory parameter param:location cannot be used for a module that can be loaded more than once.

 

To Specify a Managed Property as Writable

To specify that a managed property is writable, use the following construct in the data model realization file:

access = rw

By default, all nodes are set to read only (ro) so access only needs to be specified for those managed properties that must have their values set to create a row. If the value of any writable managed property is not specified in an SNMP set, the set fails and the row is not created. Inherits from the ROWSTATUS primitive automatically have access set to rw.


Creating Multiple Instances of a Module


Instance Specification

For some types of modules, multiple instances of the module can be run simultaneously on a single host. For example, consider a module designed to monitor the health of a single printer. For a system with several printers, the printer monitoring module would be loaded multiple times, once for each printer. In that scenario, there would be several separate instances of the printer module running simultaneously.

For such modules, it is necessary to distinguish the different instances that are loaded and running (this step is optional). This is done by specifying two additional parameters in the parameter file: instance and instanceName.

The instance parameter identifies the module instance uniquely and is used internally by the agent. This is used with the <location> module parameter to determine the location where the module is to be loaded. The instanceName parameter is a description of the instance and is combined with the display name for the module (moduleName) for display purposes on the Sun Management Center console and in status messages.

The end user is prompted to enter values for both parameters when the module is loaded. Here is an example of some values a user might enter to distinguish two printers. The user would load the module twice, specifying different values each time.

First Printer:
	instance = p1
	instanceName = 4th floor

Second Printer:
     instance = p2
     instanceName = 3rd floor

If the module name was printer monitoring, then the display names used on the console for the two printers would be a combination of the instance name and the module name:

printer monitoring [ 4th floor ]
printer monitoring [ 3rd floor ]

To include instance and instance name parameters in a module, the following lines must be included in the parameter file:

param:instance =
param:instanceName =
?param:instance?description = <display label for instance entry>
?param:instance?reqd = yes
?param:instance?format = instance

?param:instanceName?description = <display label for instanceName 
entry>
?param:instanceName?reqd = yes

Both the instance and the instanceName parameters must be marked as required (?reqd=yes).

The instance parameter must be qualified with ?format=instance. This forces the value entered for instance to begin with an alpha character and contain no whitespace or special characters such as /, &, or $. The instanceName value entered by the end user may contain spaces.


Note - If the module can be loaded multiple times, the following specification is required in the agent file:
consoleHint:mediumDesc = base.modules.<modules><-subspec>:moduleDetail
The corresponding entry in the properties file woul be:
moduleDetail = <internationalized module name>[{O}]
[{O}]
allows the Sun Management Center console to display the internationalized module name with instance and it is required.


Organizing Module Parameters

Each additional parameter added to the consoleHint:moduleParams(param) specification is added to the list of parameters shown to a user when loading the module. For organizational purposes (optional step), the parameter list may be split and shown on separate console views. To specify the number of parameter groups to be displayed, add the following to the parameter file:

consoleHint:moduleParamGroups = param <group> [<group> <group> 
...]
?<group>:?description = base.modules.<module><-subspec>:<key>

where

<group> is the name given to each grouping of parameters.
<module> is the module name.
<subspec> is the optional module subspec.
<key> is the key used to identify the internationalized text describing the parameter group.

To internationalize the group name, the following line must be added to the module properties file:

<key>=<internationalized text>

where

<key> is the same key used in the Parameter file
<internationalized text> is the string that is displayed to identify the group of parameters
The preceding specification indicates that the module parameters is grouped into multiple views. The param group, by default, will contain the mandatory module parameters. Parameters can be added to additional groups using:

consoleHint:moduleParams(<group>) = <param> [ <param> <param>... ]

where

<group> is the name of the group to which the parameters are to be added.
<param> is the parameter name to be added to this group.

An example is provided in this chapter.


Making a Module Not Loadable

There can be a need to make a particular module not loadable in an agent. (This is optional step). For example, modules that are of serverSupport module type are not loadable. The serverSupport modules are not visible in the standard hierarchy view of the agent in the console. More importantly, modules of this type do not contribute to the overall status of the agent. This module type should only be used for modules that are used internally by the agent.

The specification agentHint:loadable = false in the module parameters file can be used to restrict the loading of a module from the Sun Management Center console. The agentHint:loadable specification overrides the consoleHint:loadable.

In addition, the ability to prevent older agents from loading a module that is designed for newer agents can be specified using:

agentHint:loadable = true
agentHint:requiresVersion = <version>

The agentHint:requiresVersion is only used if agentHint:loadable is explicitly set to true. If the version of the agent is greater than or equal to <version>, then the module is loadable, otherwise, the module is not loadable. For example, if <version> is 1.1, and the agent version is 1.0.1, then the module will not be able to be loaded.


Alternate Way of Specifying a Module Location

This section contains information on the enterprise module parameter.


Enterprise Module Parameter

The enterprise module parameter is used to specify the OIDs file in which the location of the module is defined. Modules defined to use the sun or halcyon enterprise must define the location of where the module is to be loaded in the base-oids-sun-d.dat or base-oid-halcyon-d.dat file respectively. The contents of the OIDs file is:

<symbolic OID> = <numeric OID>

where

<symbolic OID> is a `/' delimited symbolic OID value for the module. This OID must also contain the appropriate enterprise and moduleType values.
<numeric OID> is the numeric sub id for this branch.

For example, the <enterprise> and <moduleType> specifications for the Solaris Example module are:

param:enterprise = halcyon
param:moduleType = operatingSystem

Based on the above specifications, the corresponding lines in the
base-oids-halcyon-d.dat file could be:

/iso/org/dod/internet/private/enterprises/halcyon/primealert/
modules/operatingSystem/solaris = 5
/iso/org/dod/internet/private/enterprises/halcyon/primealert/
modules/operatingSystem/solaris/example = 2


Note - Since there exists a Solaris Standard module (more complete than the Solaris Example module), the example node is given the numeric sub id of 2.
Using the above specifications, the Solaris Example module is loaded under the following MIB location:

.iso.org.dod.internet.private.enterprises.halcyon.primealert.hal
cyon.operatingSystem.solaris.example

If an enterprise other than Sun and Halcyon is specified, a new file base-oids-<enterprise>-d.dat must be created and released. This file needs to contain the symbolic to number OID mapping of the location where the module for that enterprise is to be loaded.


Referencing Parameters

Module parameters may be referenced from the Agent file using the following syntax:

% <parameter name>

For example, to reference the moduleName parameter use:

% moduleName 


Improving Performance using Server Override Properties File


Server Override Properties File

The Server Overrides properties file contains a list of internationalized module names which the Sun Management Center server consults before reading the module properties files for module names when filling in the Load Module pick list window. Specifying the module name in this file will remove the need in the server to read the entire properties file for the module name. Not having the module name in this file will increase the time require to fill in the Load Module window.

To specify the module name in the Server Overrides properties file use:

com.sun.symon.base.modules.<properties file>.moduleName=<value>

where:

<properties file> is the name of the module properties file without the suffix (.properties). If standard module naming convention is being followed this will be <module><-subspec>.
<value> is the internationalized module name.

Example Server Override Properties File

com.sun.symon.base.modules.solaris-example.moduleName=Solaris Example


Additional Data Model Specifications


Specifying Hidden Managed Properties

By default all managed properties and their data are visible in the Sun Management Center console. To make a managed property and its data invisible in the Sun Management Center console, specify the following in the managed property:

consoleHint:hidden = true

Typically, this specification is used in managed properties that store data that would be meaningless to end users but are required for the module.


Note - consoleHint:hidden = true is also applicable for managed objects. It is available for managed properties and managed objects.

Data Logging Support


Automatic Data Logging

Sun Management Center agents support the logging of data to a file or to an internal cache. Logging to a file can be used for long term data storage, while data logged to the internal cache is used by the Sun Management Center console graphing. Typically, data logging is turned on or off manually using the Sun Management Center console. However, a module can turn on data logging automatically when it is first loaded.

To do this, the following must be specified in the managed property whose data values are to be logged in the data file (note that the following files go into the agent file):

historyInterval = <time specification>
historyTargets(<type>) = <rowname> [ <rowname> ... ]

where:

<time specification> is the interval at which the data is logged. This value is independent of the interval at which new data is collected.
<type> is either cache or file. cache specifies that the values is logged to an internal cache, and file specifies that the data values is logged to a file.
<rowname> specifies the name of the row (for a table managed property) whose value is to be logged. Multiple rows can be logged by specifying a space separated list of row names. If the node is a scalar node, <rowname> must be set to {}.

Based on the <type> of data logging to be done, additional qualifiers are required.


Logging To Internal Cache

To log data to the internal cache, the following additional qualifier is required:

historyLength(<rowname>) = <num>

where:

<rowname> is the name of the row (for a table managed property) whose data values are to be logged. If the node is a scalar, <rowname> must be empty.
<num> is the number of data points to be stored internally. The maximum value can be set to 1500.

Logging To File

Data can be logged to two different file types:


Note - Use caution when automatically turning on data logging to a flat file. Since there are no restrictions to the maximum size of the file, the file can get very large. The circular log file format maintains a fixed file size. However, the disadvantage of this is that log file eventually wraps and old data is lost.

 

To Log Data to a Typical Flat File

   Specify the following qualifiers:

historyFileType(<rowname>) = text
historyChannel(<rowname>) = "file://localhost/../log 
<filename>;flags=rw+;mode=644"

_

where:

<rowname> is the name of the row (for a table managed property) whose data values are to be logged. If the node is a scalar, <rowname> must be empty.
<filename> is the name of the file where the data is logged. This file is located in
/var/opt/SUNWsymon/log.

 

To Log Data to a Circular Log File

   Specify the following qualifiers:

historyFileType(<rowname>) = circular
historyChannel(<rownam) = history

_

These qualifers log data to the file /var/opt/SUNWsymon/log/history.log. No other circular log file can be specified.


Logging Data of a Scalar Node to an Internal Cache

The following example automatically logs data of a scalar node to an internal cache.

myscalarnode = {
    historyInterval = 120
    historyTargets(cache) = "{}"
    historyLength() = 100
}


Logging Two Rows of a Table Managed Property

The following example automatically logs two rows of a table managed property. One row is logged to a flat file, the other a circular log file.

myvectornode = {
    historyInterval = 120
    historyTargets(file) = row1 row2

    historyFileType(row1) = text
    historyChannel(row1) = "file://localhost/../log\
/myfile.txt;flags=rw+;mode=644"

    historyFileType(row2) = circular
    historyChannel(row2) = history
}


Specifying Module Availability

For MANAGED-MODULES, an availability managed property can be used by the module developer to flag if the entire module becomes unavailable. An example of a module becoming unavailable would be a database like Oracle that is down.

Use of the availability property is entirely optional. It does not make sense for all modules. The most common use is for database modules.

When the availability property indicates that the module is unavailable, all periodic data updates for the underlying objects within the module cease. The module enters a DOWN state, and the LEDs for the module turn black. The associated status message is <module> Is Not Accessible.


Specifying the Availability Property in the Agent File

CODE EXAMPLE 9-1 shows how to specify the availability property in the agent file:

CODE  EXAMPLE  9-1 Specifying Availability Property
[ use MANAGED-MODULE ]
[ load <module><-subspec>-m.x ]
[ requires template <module><-subspec>-models-d ]

_procedures = { [ use PROC ] 
    	[ source <modules><-subspec>-d.prc ]
}
#
# Module Availability
#
availability = { [ use _procedures ]
    refreshCommand = moduleAvailability
    refreshInterval = 60
    initInterval = 0
    initHoldoff = 2
}

The initInterval and initHoldoff values must be set so that the availability check runs before any of the other refresh command within the module so that when the module is first started, the availability check is performed first and has a chance to turn off all other refresh operations if the module is not available. The values shown in the preceding example are appropriate in most cases.


Note - initHoldoff must be at least 2.

Within the <module><-subspec>-d.prc file is a function named moduleAvailability that returns AVAILABLE or UNAVAILABLE. An example of such a function is:

proc moduleAvailability {} {
   if { [ <some type of test> ] == true } {
      set return_code AVAILABLE
   } else {
      set return_code UNAVAILABLE
   }
   return $return_code

}

The data acquisition for the availability object can be performed in any of the ways discussed in the previous sections. However, the only limitation is that the availability object must return the string AVAILABLE if the module is to be available. Returning any other string puts the module in a unavailable state.


Persistence

persistentSlices = <slice1>[:<file2>] [<slice2>[:<file2>]]
persistWhenUnloaded = true

A persistentSlices qualifier can be specified in the agent file. This qualifier is a space separated list of slices that are to be saved to a file whenever a change in the slice value occurs. Slices represent internal data storage used by the agent, and are used to store, among other things, values that can be set by an end-user from the console (like alarm limits). The persistence functionality is required to ensure that such settings are written to a disk file, so that their values are preserved across restarts of the agent.

By default this qualifier is set to:

persistentSlices = value alarmlimit

All changes to the value and alarmlimit slices are saved to a file. The name of the file defaults to <module><-subspec>-d.dat, and is read by the agent on restarts.


Note - Currently, persistence is only supported for value and alarmlimit slices.

Note - By default, unloading the module deletes the persistence file. To retain the file, even if the module is unloaded, set the persistWhenUnloaded qualifier to true (default is false).


Specifying Adhoc Commands

Ad hoc commands provide the ability to execute certain commands in the Sun Management Center agent using the Sun Management Center console. Currently, two types of ad hoc commands are supported. They are probe commands and SNMP table management commands. SNMP table management commands are discussed in the "Using SNMP Table Management Commands".


Command Specification

To specify an ad hoc command for a managed object, the following is required in the agent file:

consoleHint:commands = <command1> [<command2> ... ]

The consoleHint:commands qualifier specifies a space separated list of logical names for commands. Each logical command name must have the following additional qualifiers in the agent file:

consoleHint:commandLabel(<command>) = base.modules.<module><-subspec>:<key>
consoleHint:commandSpec(<command>) = <adhoc command>

The consoleHint:commandLabel(<command>) specifies the internationalization key for the text that appears in the Sun Management Center console for the command. Remember a corresponding entry in the module properties file is required. This entry has the following form:

<key>=<internationalized text>

The consoleHint:commandSpec(<command>) specifies the action command that runs in the agent. This command varies depending on the type of command required.


Row-Specific Commands

Adhoc commands can also be specified for vector data. As such, the commands can be differentiated based on the row of the table data on which it is executed. To do so, the consoleHint:commands qualifier must be replaced with consoleHint:tableCommands.

To specify commands that are only available at the table header use consoleHint:tableHeaderCommands. The usage is the same as the consoleHint:commands specification.


Probe Commands

Many data acquisition functions need not be performed on a periodic basis. Also, some queries (such as screen grabs) are not well suited for SNMP transport. To deal with these cases, a probe system is used that enables secure ad hoc commands and queries to be performed to remote hosts. Any module-specific functions that are not well suited to implementation within the MIB tree of the agent can be placed in the probe config file for that module.


 

To Specify a Probe Command

The consoleHint:commandSpec for a probe command must be specified as:

consoleHint:commandSpec(<command>) = probeview %windowID snmp://
%targetHost:%targetPort/mod/<module><-subspec>/\
<path to node>?runadhoccommand.<command>

The consoleHint:commandSpec(<command>) launches a new window to display the results of the command that is executed in the agent. The <path to node> is a "/" delimited path to the node in the agent that specifies the command to execute. The command that is executed is specified using:

adhocCommand(<command>) = probeserver -c <unix command>

where <unix command> can be any UNIX command with arguments. Tcl and TOE commands can also be used to specify arguments. In this case, <unix command> can include \[ <Tcl/Toe command> \]. The Tcl or TOE command is evaluated before calling the Unix command. For example, probeserver -c df -k \[ myFunction \] would use the return value from myFunction as an argument to the UNIX command df.

To specify a probe command that runs top for the load object in the Solaris example module, the following is required in the agent file:

load = { [ use _filters ]
    type                        = active
    refreshService              = _services.sh
    refreshCommand              = uptime
    refreshFilter               = loadFilter
    refreshInterval             = 120
 
    consoleHint:commands        = top
      
    consoleHint:commandLabel(top) = base.modules.solaris-example:top
    consoleHint:commandSpec(top)  = probeview %windowID snmp://
%targetHost:%targetPort/mod/solaris-example/system\
/load?runadhoccommand.top 
 
    adhocCommand(top)             = probeserver -c /common/local/bin/top
}

The corresponding entry in the properties file would be:

#
# Probe Queries 
#
top=Top


Row Dependent Probe Queries

To differentiate the rows on which the query is executed, %targetFragment can be added to the consoleHint:commandSpec qualifier and %fragment to the adhocCommand qualifier. When used, both values are set to the value of that row in the column referenced by the index qualifier as shown in the following example.


Find Files Example

In this example, a Probe command is added to the filesystems node to allow users to search for files that are greater than 2 Mbytes.

CODE  EXAMPLE  9-2 Find Files
#
# Filesystem Information
#
filesystems = { [use templates.solaris-example-models-d.filesystems _filters ]
    type                = active
    refreshService      = _services.sh
    refreshCommand      = df -kF ufs
    refreshFilter       = fileFilter
    refreshInterval     = 120
 
  adhocCommand(findallgt2m) = probeserver -c find %fragment -local -mount \
( -type b -o -type c ) -prune -o ( -size +4096 ) -ls

fileTable = {
        fileEntry = {
            index = mount
            consoleHint:tableCommands = findallgt2m
             consoleHint:commandLabel(findallgt2m) = base.modules.\
solaris-example:findallgt2m
            consoleHint:commandSpec(findallgt2m)  = probeview %windowID snmp:\
//%targetHost:%targetPort/mod/solaris-example/
filesystem?runadhoccommand.findallgt2m %targetFragment
        }
    }
}

In this example, the first argument to the find command will be the value stored in the mount column for the row on which this Probe command is executed. The corresponding entry in the Solaris Example Properties File would be:

CODE  EXAMPLE  9-3 Entry in the Solaris Example Properties File
#
# Probe Queries
#
top=Top
findallgt2m=Find All Files > 2M


Note - In this example, the consoleHint qualifiers are specified under the fileEntry node. These are required at this level for all tables. However, the adhocCommand is specified at the filesystems node level. The adhocCommand can be specified at any level as long as the <path to node> specification describes the proper path to the command.

Probe Command Security

Execution of probe commands are done through the agent's shadow MIB. As such, security access of probe commands is controlled by shadow ACLs specifications. Specifically, the runadhoccommand shadow MIB attribute is used to run Probe commands.

By default, all probe commands are executable by all users who have read access. To limit access to specific Probe commands, the security access for the runadhoccommand shadow attribute needs to be overridden in the node where the probe command is defined.


 

To Limit Top Probe Command

To limit access to the top probe command to users who have write access based on the standard MIB ACLs, specify the following in the load node:

load = { [ use _filters ]
    ...
    shadowMIBAccessMode(runadhoccommand) = useMIBAccess
}

This allows users with write access to the load node to be able to run any Probe commands for the load node only (it does not affect the subtree below this node).


Enabling Modules for Metadata

Sun Management Center introduces a series of new services some of which use the available Sun Management Center module information in various operations and applications that include the following features:

This section describes the steps that developers need to take to ensure that their module is enabled for these services. The subsequent text in this section assumes that Sun Management Center is installed in the /opt (default) as the base directory.

For a module to be enabled for new services, some module files (see below for list of module files) of the module should be installed on the Sun Management Center server machine. These module files must be present in the following directory of server machine:

/opt/SUNWsymon/mdr/modules/cfg 

These files are exact copies of the files that may be existing on a machine hosting Sun Management Center agent at the following location:

/opt/SUNWsymon/modules/cfg  

Not all the module files of a module need to be installed in this location. Only the following files need to be present in the above mentioned directory.

It is not mandatory that your module consists of all the above files. If your module does no't have some of the above listed files, then you need not create (and install) these files. The following files are not required to be installed on the server machine:

In general, all modules are suitable for this feature except:

Even if you have a module that depends on Hardware type, OS release, and such, it may be still suitable for this feature and can be installed on the Sun Management Center server machine.


Error Reporting

If you want to report any errors or messages to the Sun Management Center agent logs, you can do so by using the following command in any Tcl/TOE procedure:

ddl print <channel_name> <message>

where:

channel_name is one of error, warning, info, debug, and trace.

messsage is the string you want to print.

This message will appear in the agent log provided the channel is enabled.




Previous Next Contents Generated Index Home

Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.