Chapter 9 |
Additional Specifications for a Module |
This chapter covers the following sections:
# # 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 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>
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.
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.
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.
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.
This section contains information on the 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.
Module parameters may be referenced from the Agent file using the following syntax:
% <parameter name>
For example, to reference the moduleName parameter use:
% moduleName
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.
com.sun.symon.base.modules.solaris-example.moduleName=Solaris Example |
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.
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.
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.
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:
|
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:
|
These qualifers log data to the file /var/opt/SUNWsymon/log/history.log. No other circular log file can be specified.
The following example automatically logs data of a scalar node to an internal cache.
myscalarnode = { historyInterval = 120 historyTargets(cache) = "{}" historyLength() = 100 }
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 }
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.
CODE EXAMPLE 9-1 shows how to specify the availability property in the agent file:
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.
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).
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".
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.
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.
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
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.
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.
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).
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.
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.