Request for Comments: 3165 Nortel Networks
Obsoletes: 2592 J. Schoenwaelder
Category: Standards Track TU Braunschweig
August 2001
Definitions of Managed Objects for the
Delegation of Management Scripts
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow the
delegation of management scripts to distributed managers.
Table of Contents
1 Introduction ................................................. 3
2 The SNMP Management Framework ................................ 3
3 Overview ..................................................... 4
3.1 Terms ...................................................... 5
4 Requirements and Design Issues ............................... 6
4.1 Script Languages ........................................... 6
4.2 Script Transfer ............................................ 7
4.3 Script Execution ........................................... 8
5 Structure of the MIB ......................................... 9
5.1 Language Group ............................................. 9
5.2 Script Group ............................................... 10
5.3 Code Group ................................................. 11
5.4 Launch Group ............................................... 11
5.5 Run Group .................................................. 11
6 Definitions .................................................. 12
7 Usage Examples ............................................... 49
7.1 Pushing a Script via SNMP .................................. 49
7.2 Pulling a Script from a URL ................................ 50
7.3 Modifying an Existing Script ............................... 50
7.4 Removing an Existing Script ................................ 51
7.5 Creating a Launch Button ................................... 51
7.6 Launching a Script ......................................... 52
7.7 Suspending a Running Script ................................ 52
7.8 Resuming a Suspended Script ................................ 53
7.9 Terminating a Running Script ............................... 53
7.10 Removing a Terminated Script .............................. 54
7.11 Removing a Launch Button .................................. 54
8 VACM Configuration Examples .................................. 54
8.1 Sandbox for Guests ......................................... 55
8.2 Sharing Scripts ............................................ 55
8.3 Emergency Scripts .......................................... 56
9 IANA Considerations .......................................... 57
10 Security Considerations ..................................... 57
11 Intellectual Property ....................................... 59
12 Changes from RFC2592 ....................................... 59
13 Acknowledgments ............................................. 61
14 References .................................................. 61
15 Editors' Addresses .......................................... 63
16 Full Copyright Statement .................................... 64
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow the
delegation of management scripts to distributed managers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
2. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC1155 [RFC1155], STD 16, RFC1212 [RFC1212] and RFC1215
[RFC1215]. The second version, called SMIv2, is described in STD
58, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [RFC1157]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [RFC1901]
and RFC1906 [RFC1906]. The third version of the message protocol
is called SNMPv3 and described in RFC1906 [RFC1906], RFC2572
[RFC2572] and RFC2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[RFC1905].
o A set of fundamental applications described in RFC2573 [RFC2573]
and the view-based access control mechanism described in RFC2575
[RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
3. Overview
The Script MIB module defined in this memo can be used to delegate
management functions to distributed managers. Management functions
are defined as management scripts written in a management scripting
language. This MIB makes no assumptions about the language itself
and even allows distribution of compiled native code, if an
implementation is able to execute native code under the control of
this MIB.
The Script MIB defines a standard interface for the delegation of
management functions based on the Internet management framework. In
particular, it provides the following capabilities:
1. Capabilities to transfer management scripts to a distributed
manager.
2. Capabilities for initiating, suspending, resuming and terminating
management scripts.
3. Capabilities to transfer arguments for management scripts.
4. Capabilities to monitor and control running management scripts.
5. Capabilities to transfer the results produced by running
management scripts.
This memo does not address any additional topics like the generation
of notifications or how to address remote agents from a Script MIB
implementation.
3.1. Terms
This section defines the terms used throughout this memo.
o A `distributed manager' is a processing entity which is capable of
performing network management functions. For the scope of this
memo, a distributed manager is assumed to implement the Script
MIB.
o A `higher-level manager', or just `manager', is a processing
entity or human who initiates and controls the operations
performed by one or more distributed managers.
o A `management script' is a set of instructions written in an
executable language which implements a management function.
o A `management scripting language' is a language used to write
management scripts. The term scripting language does not imply
that the language must have the characteristics of scripting
languages (e.g., string orientation, interpretation, weak typing).
The MIB defined in this memo also allows to control management
scripts written in arbitrary compiled system programming
languages.
o A `distributed manager' can be decomposed into an `SNMP entity'
which implements the Script MIB defined in this memo and the `
runtime system' that executes scripts. The Script MIB sees the
runtime system as the managed resource which is controlled by the
MIB.
The runtime system can act as an SNMP application, according to
the SNMP architecture defined in RFC2571 [RFC2571]. For example,
a runtime system which sends SNMP requests to other SNMP entities
will act as a command generator application. The SNMP
applications in the runtime system may use the same SNMP engine
which also serves the command responder application used to
implement the Script MIB, but they are not required to do so.
o A `launch button' is the conceptual button used to start the
execution of a management script. It assigns control parameters
to a management script. In particular, it defines the ownership
of the scripts started from a launch button. The ownership can be
used by the language runtime system to enforce security profiles
on a running management script.
4. Requirements and Design Issues
This section discusses some general requirements that have influenced
the design of the Script MIB.
o The Script MIB must not make any assumptions about specific
languages or runtime systems.
o The Script MIB must provide mechanisms that help to avoid new
management problems (e.g., script version problems).
o The Script MIB must provide SNMP interfaces to all functions
required to delegate management scripts. However, other protocols
might be used in addition if they provide a significant
improvement in terms of convenience for implementation or
performance.
o The Script MIB must be organized so that access can be controlled
effectively by using view-based access control [RFC2575].
The following sections discuss some design issues in more detail.
4.1. Script Languages
The Script MIB defined in this memo makes no assumption about the
script language. This MIB can therefore be used in combination with
different languages (such as Tcl or Java) and/or different versions
of the same language. No assumptions are made about the format in
which management scripts are transferred.
The Script MIB provides access to information about the language
versions supported by a Script MIB implementation so that a manager
can learn about the capabilities provided by an implementation.
Languages and language versions are identified as follows:
1. The language is identified by an object identifier. Object
identifier for well-known languages will be registered by the
Internet Assigned Numbers Authority (IANA). Enterprise specific
languages can also be registered in the enterprise specific OID
subtree.
2. A particular version of a language is identified by a language
version number. The combination of a language object identifier
and a language version is in most cases sufficient to decide
whether a script can be executed or not.
3. Different implementations of the same language version might have
differences due to ambiguities in the language definition or
additional language features provided by an implementor. An
additional object identifier value is provided which identifies
the organization which provides the implementation of a language.
This might be used by scripts that require a particular
implementation of a language.
4. Finally, there might be different versions of a language
implementation. A version number for the language implementation
is provided so that the manager can also distinguish between
different implementations from the same organization of a
particular language version.
The version numbers can either be used by a manager to select the
language version required to execute a particular script or to select
a script that fits the language versions supported by a particular
Script MIB implementation.
An additional table lists language extensions that provide features
not provided by the core language. Language extensions are usually
required to turn a general purpose language into a management
language. In many cases, language extensions will come in the form
of libraries that provide capabilities like sending SNMP requests to
remote SNMP agents or accessing the local MIB instrumentation. Every
extension is associated with a language and carries its own version
numbers.
4.2. Script Transfer
There are two different ways to transfer management scripts to a
distributed manager. The first approach requires that the manager
pushes the script to the distributed manager. This is therefore
called the `push model'. The second approach is the `pull model'
where the manager tells the distributed manager the location of the
script and the distributed manager retrieves the script itself.
The MIB defined in this memo supports both models. The `push model'
is realized by a table which allows a manager to write scripts by
sending a sequence of SNMP set requests. The script can be split
into several fragments in order to deal with SNMP message size
limitations.
The `pull model' is realized by the use of Uniform Resource Locators
(URLs) [RFC2396] that point to the script source. The manager writes
the URL which points to the script source to the distributed manager
by sending an SNMP set request. The distributed manager is then
responsible for retrieving the document using the protocol specified
in the URL. This allows the use of protocols like FTP [RFC959] or
HTTP [RFC2616] to transfer large management scripts efficiently.
The Script MIB also allows management scripts that are hard-wired
into the Script MIB implementation. Built-in scripts can either be
implemented in a language runtime system, or they can be built
natively into the Script MIB implementation. The implementation of
the `push model' or the `pull model' is not required.
Scripts can be stored in non-volatile storage. This allows a
distributed manager to restart scripts if it is restarted (off-line
restart). A manager is not required to push scripts back into the
distributed manager after a restart if the script is backed up in
non-volatile storage.
Every script is identified by an administratively assigned name.
This name may be used to derive the name which is used to access the
script in non-volatile storage. This mapping is implementation
specific. However, the mapping must ensure that the Script MIB
implementation can handle scripts with the same administrative name
owned by different managers. One way to achieve this is to use the
script owner in addition to the script name in order to derive the
internal name used to refer to a particular script in non-volatile
storage.
4.3. Script Execution
The Script MIB permits execution of several instances of the same or
different management scripts. Script arguments are passed as OCTET
STRING values. Scripts return a single result value which is also an
OCTET STRING value. The semantic interpretation of result values is
left to the invoking manager or other management scripts. A script
invoker must understand the format and semantics of both the
arguments and the results of the scripts that it invokes.
Scripts can also export complex results through a MIB interface.
This allows a management application to access and use script results
in the same manner as it processes any other MIB data. However, the
Script MIB does not provide any special support for the
implementation of MIBs through scripts.
Runtime errors terminate active scripts. An exit code and a human
readable error message is left in the MIB. A notification containing
the exit code, the error message and a timestamp is generated when a
script terminates with an error exit code.
Script arguments and results do not have any size limitations other
than the limits imposed by the SMI and the SNMP protocol. However,
implementations of this MIB might have further restrictions. A
script designer might therefore choose to return the results via
other mechanisms if the script results can be very large. One
possibility is to return a URL as a script result which points to the
file containing the script output.
Executing scripts have a status object attached which allows script
execution to be suspended, resumed, or aborted. The precise
semantics of the suspend and resume operations are language and
runtime system dependent. Some runtime systems may choose to not
implement the suspend/resume operations.
A history of finished scripts is kept in the MIB. A script invoker
can collect results at a later point in time (offline operation).
Control objects can be used to control how entries in the history are
aged out if the table fills up.
5. Structure of the MIB
This section presents the structure of the MIB. The objects are
arranged into the following groups:
o language group (smLangTable, smExtsnTable)
o script group (smScriptTable)
o script code group (smCodeTable)
o script launch group (smLaunchTable)
o running script group (smRunTable)
5.1. Language Group
The smLanguageGroup is used to provide information about the
languages and the language extensions supported by a Script MIB
implementation. This group includes two tables. The smLangTable
lists all languages supported by a Script MIB implementation and the
smExtsnTable lists the extensions that are available for a given
language.
5.2. Script Group
The smScriptGroup consists of a single table, called the
smScriptTable. The smScriptTable lists all scripts known to a Script
MIB implementation. The smScriptTable contains objects that allow
the following operations:
o download scripts from a URL (pull model)
o read scripts from local non-volatile storage
o store scripts in local non-volatile storage
o delete scripts from local non-volatile storage
o list permanent scripts (that can not be changed or removed)
o read and modify the script status (enabled, disabled, editing)
A status object called smScriptOperStatus allows a manager to obtain
the current status of a script. It is also used to provide an error
indication if an attempt to invoke one of the operations listed above
fails. The status change of a script can be requested by modifying
the associated smScriptAdminStatus object.
The source of a script is defined by the smScriptSource object. This
object may contain a URL pointing to a remote location which provides
access to the management script. The script source is read from the
smCodeTable (described below) or from non-volatile storage if the
smScriptSource object contains an empty URL. The smScriptStorageType
object is used to distinguish between scripts read from non-volatile
storage and scripts read from the smCodeTable.
Scripts are automatically loaded once the smScriptAdminStatus object
is set to `enabled'. Loading a script includes retrieving the script
(probably from a remote location), compiling the script for languages
that require a compilation step, and making the code available to the
runtime system. The smScriptOperStatus object is used to indicate
the status of the loading process. This object will start in the
state `retrieving', switch to the state `compiling' and finally reach
the state `enabled'. Errors during the retrieval or compilation
phase will result in an error state such as `compilationFailed'.
5.3. Code Group
The smCodeGroup consists of a single table, called the smCodeTable,
which provides the ability to transfer and modify scripts via SNMP
set requests. In particular, the smCodeTable allows the following
operations:
o download scripts via SNMP (push model)
o modify scripts via SNMP (editing)
The smCodeTable lists the code of a script. A script can be
fragmented over multiple rows of the smCodeTable in order to handle
SNMP message size limitations. Modifications of the smCodeTable are
only possible if the associated smScriptOperStatus object has the
value `editing'. The Script MIB implementation reloads the modified
script code once the smScriptOperStatus changes to `enabled' again.
The implementation of the smCodeGroup is optional.
5.4. Launch Group
The smLaunchGroup contains a single table, the smLaunchTable. An
entry in the smLaunchTable represents a launch button which can be
used to start a script. The smLaunchTable allows the following
operations:
o associate a script with an owner used during script execution
o provide arguments and parameters for script invocation
o invoke scripts with a single set operation
The smLaunchTable describes scripts and their parameters that are
ready to be launched. An entry in the smLaunchTable attaches an
argument to a script and control values which, for example, define
the maximum number of times that a script invoked from a particular
row in the smLaunchTable may be running concurrently.
An entry in the smLaunchTable also defines the owner which will be
used to associate permissions with the script execution.
5.5. Run Group
The smRunGroup contains a single table, called the smRunTable, which
lists all scripts that are currently running or have terminated
recently. The smRunTable contains objects that allow the following
operations:
o retrieve status information from running scripts
o control running scripts (suspend, resume, abort)
o retrieve results from recently terminated scripts
o control the remaining maximum lifetime of a running script
o control how long script results are accessible
Every row in the smRunTable contains the argument passed during
script invocation, the result produced by the script and the script
exit code. The smRunTable also provides information about the
current run state as well as start and end time-stamps. There are
three writable objects in the smRunTable. The smRunLifeTime object
defines the maximum time a running script may run before it is
terminated by the Script MIB implementation. The smRunExpireTime
object defines the time that a completed script can stay in the
smRunTable before it is aged out. The smRunControl object allows
running scripts to be suspended, resumed, or aborted.
6. Definitions
DISMAN-SCRIPT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Unsigned32, mib-2
FROM SNMPv2-SMI
RowStatus, TimeInterval, DateAndTime, StorageType, DisplayString
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
scriptMIB MODULE-IDENTITY
LAST-UPDATED "200108210000Z"
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"WG EMail: disman@dorothy.bmc.com
Subscribe: disman-request@dorothy.bmc.com
Chair: Randy Presuhn
BMC Software, Inc.
Postal: Office 1-3141
2141 North First Street
San Jose, California 95131
USA
EMail: rpresuhn@bmc.com
Phone: +1 408 546-1006
Editor: David B. Levi
Nortel Networks
Postal: 4401 Great America Parkway
Santa Clara, CA 95052-8185
USA
EMail: dlevi@nortelnetworks.com
Phone: +1 423 686 0432
Editor: Juergen Schoenwaelder
TU Braunschweig
Postal: Bueltenweg 74/75
38106 Braunschweig
Germany
EMail: schoenw@ibr.cs.tu-bs.de
Phone: +49 531 391-3283"
DESCRIPTION
"This MIB module defines a set of objects that allow to
delegate management scripts to distributed managers."
REVISION "200108210000Z"
DESCRIPTION
"Revised version, published as RFC3165.
This revision introduces several new objects: smScriptError,
smScriptLastChange, smLaunchError, smLaunchLastChange,
smLaunchRowExpireTime, smRunResultTime, and smRunErrorTime.
The following existing objects were updated: the maximum
value of smRunLifeTime now disables the timer, an
autostart value was added to the smLaunchAdminStatus
object, and a new expired state was added to the
smLaunchOperStatus object.
A new smScriptException notification has been added to
support runtime error notifications.
Created new conformance and compliance statements that
take care of the new objects and notifications.
Clarifications have been added in several places to remove
ambiguities or contradictions that were discovered and
reported by implementors."
REVISION "199902221800Z"
DESCRIPTION
"Initial version, published as RFC2592."
::= { mib-2 64 }
--
-- The groups defined within this MIB module:
--
smObjects OBJECT IDENTIFIER ::= { scriptMIB 1 }
smNotifications OBJECT IDENTIFIER ::= { scriptMIB 2 }
smConformance OBJECT IDENTIFIER ::= { scriptMIB 3 }
--
-- Script language and language extensions.
--
-- This group defines tables which list the languages and the
-- language extensions supported by a Script MIB implementation.
-- Languages are uniquely identified by object identifier values.
--
smLangTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmLangEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists supported script languages."
::= { smObjects 1 }
smLangEntry OBJECT-TYPE
SYNTAX SmLangEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular language."
INDEX { smLangIndex }
::= { smLangTable 1 }
SmLangEntry ::= SEQUENCE {
smLangIndex Integer32,
smLangLanguage OBJECT IDENTIFIER,
smLangVersion SnmpAdminString,
smLangVendor OBJECT IDENTIFIER,
smLangRevision SnmpAdminString,
smLangDescr SnmpAdminString
}
smLangIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally arbitrary, but unique identifier associated
with this language entry.
The value is expected to remain constant at least from one
re-initialization of the entity's network management system
to the next re-initialization.
Note that the data type and the range of this object must
be consistent with the definition of smScriptLanguage."
::= { smLangEntry 1 }
smLangLanguage OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The globally unique identification of the language."
::= { smLangEntry 2 }
smLangVersion OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version number of the language. The zero-length string
shall be used if the language does not have a version
number.
It is suggested that the version number consist of one or
more decimal numbers separated by dots, where the first
number is called the major version number."
::= { smLangEntry 3 }
smLangVendor OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object identifier which identifies the vendor who
provides the implementation of the language. This object
identifier SHALL point to the object identifier directly
below the enterprise object identifier {1 3 6 1 4 1}
allocated for the vendor. The value must be the object
identifier {0 0} if the vendor is not known."
::= { smLangEntry 4 }
smLangRevision OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version number of the language implementation.
The value of this object must be an empty string if
version number of the implementation is unknown.
It is suggested that the value consist of one or more
decimal numbers separated by dots, where the first
number is called the major version number."
::= { smLangEntry 5 }
smLangDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the language."
::= { smLangEntry 6 }
smExtsnTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmExtsnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists supported language extensions."
::= { smObjects 2 }
smExtsnEntry OBJECT-TYPE
SYNTAX SmExtsnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular language extension."
INDEX { smLangIndex, smExtsnIndex }
::= { smExtsnTable 1 }
SmExtsnEntry ::= SEQUENCE {
smExtsnIndex Integer32,
smExtsnExtension OBJECT IDENTIFIER,
smExtsnVersion SnmpAdminString,
smExtsnVendor OBJECT IDENTIFIER,
smExtsnRevision SnmpAdminString,
smExtsnDescr SnmpAdminString
}
smExtsnIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally arbitrary, but unique identifier associated
with this language extension entry.
The value is expected to remain constant at least from one
re-initialization of the entity's network management system
to the next re-initialization."
::= { smExtsnEntry 1}
smExtsnExtension OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The globally unique identification of the language
extension."
::= { smExtsnEntry 2 }
smExtsnVersion OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version number of the language extension.
It is suggested that the version number consist of one or
more decimal numbers separated by dots, where the first
number is called the major version number."
::= { smExtsnEntry 3 }
smExtsnVendor OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object identifier which identifies the vendor who
provides the implementation of the extension. The
object identifier value should point to the OID node
directly below the enterprise OID {1 3 6 1 4 1}
allocated for the vendor. The value must by the object
identifier {0 0} if the vendor is not known."
::= { smExtsnEntry 4 }
smExtsnRevision OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version number of the extension implementation.
The value of this object must be an empty string if
version number of the implementation is unknown.
It is suggested that the value consist of one or more
decimal numbers separated by dots, where the first
number is called the major version number."
::= { smExtsnEntry 5 }
smExtsnDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the language extension."
::= { smExtsnEntry 6 }
--
-- Scripts known by the Script MIB implementation.
--
-- This group defines a table which lists all known scripts.
-- Scripts can be added and removed through manipulation of the
-- smScriptTable.
--
smScriptObjects OBJECT IDENTIFIER ::= { smObjects 3 }
smScriptTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmScriptEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists and describes locally known scripts."
::= { smScriptObjects 1 }
smScriptEntry OBJECT-TYPE
SYNTAX SmScriptEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular script. Every script that
is stored in non-volatile memory is required to appear in
this script table."
INDEX { smScriptOwner, smScriptName }
::= { smScriptTable 1 }
SmScriptEntry ::= SEQUENCE {
smScriptOwner SnmpAdminString,
smScriptName SnmpAdminString,
smScriptDescr SnmpAdminString,
smScriptLanguage Integer32,
smScriptSource DisplayString,
smScriptAdminStatus INTEGER,
smScriptOperStatus INTEGER,
smScriptStorageType StorageType,
smScriptRowStatus RowStatus,
smScriptError SnmpAdminString,
smScriptLastChange DateAndTime
}
smScriptOwner OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The manager who owns this row in the smScriptTable."
::= { smScriptEntry 1 }
smScriptName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally-unique, administratively assigned name for this
script. This object allows an smScriptOwner to have multiple
entries in the smScriptTable.
This value of this object may be used to derive the name
(e.g. a file name) which is used by the Script MIB
implementation to access the script in non-volatile
storage. The details of this mapping are implementation
specific. However, the mapping needs to ensure that scripts
created by different owners with the same script name do not
map to the same name in non-volatile storage."
::= { smScriptEntry 2 }
smScriptDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A description of the purpose of the script."
::= { smScriptEntry 3 }
smScriptLanguage OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object type identifies an entry in the
smLangTable which is used to execute this script.
The special value 0 may be used by hard-wired scripts
that can not be modified and that are executed by
internal functions.
Set requests to change this object are invalid if the
value of smScriptOperStatus is `enabled' or `compiling'
and will result in an inconsistentValue error.
Note that the data type and the range of this object must
be consistent with the definition of smLangIndex."
::= { smScriptEntry 4 }
smScriptSource OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object either contains a reference to the script
source or an empty string. A reference must be given
in the form of a Uniform Resource Locator (URL) as
defined in RFC2396. The allowed character sets and the
encoding rules defined in RFC2396 section 2 apply.
When the smScriptAdminStatus object is set to `enabled',
the Script MIB implementation will `pull' the script
source from the URL contained in this object if the URL
is not empty.
An empty URL indicates that the script source is loaded
from local storage. The script is read from the smCodeTable
if the value of smScriptStorageType is volatile. Otherwise,
the script is read from non-volatile storage.
Note: This document does not mandate implementation of any
specific URL scheme. An attempt to load a script from a
nonsupported URL scheme will cause the smScriptOperStatus
to report an `unknownProtocol' error.
Set requests to change this object are invalid if the
value of smScriptOperStatus is `enabled', `editing',
`retrieving' or `compiling' and will result in an
inconsistentValue error."
DEFVAL { ''H }
::= { smScriptEntry 5 }
smScriptAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
editing(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object indicates the desired status of
the script. See the definition of smScriptOperStatus for
a description of the values.
When the smScriptAdminStatus object is set to `enabled' and
the smScriptOperStatus is `disabled' or one of the error
states, the Script MIB implementation will `pull' the script
source from the URL contained in the smScriptSource object
if the URL is not empty."
DEFVAL { disabled }
::= { smScriptEntry 6 }
smScriptOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
editing(3),
retrieving(4),
compiling(5),
noSuchScript(6),
accessDenied(7),
wrongLanguage(8),
wrongVersion(9),
compilationFailed(10),
noResourcesLeft(11),
unknownProtocol(12),
protocolFailure(13),
genericError(14)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The actual status of the script in the runtime system. The
value of this object is only meaningful when the value of
the smScriptRowStatus object is `active'.
The smScriptOperStatus object may have the following values:
- `enabled' indicates that the script is available and can
be started by a launch table entry.
- `disabled' indicates that the script can not be used.
- `editing' indicates that the script can be modified in the
smCodeTable.
- `retrieving' indicates that the script is currently being
loaded from non-volatile storage or a remote system.
- `compiling' indicates that the script is currently being
compiled by the runtime system.
- `noSuchScript' indicates that the script does not exist
at the smScriptSource.
- `accessDenied' indicates that the script can not be loaded
from the smScriptSource due to a lack of permissions.
- `wrongLanguage' indicates that the script can not be
loaded from the smScriptSource because of a language
mismatch.
- `wrongVersion' indicates that the script can not be loaded
from the smScriptSource because of a language version
mismatch.
- `compilationFailed' indicates that the compilation failed.
- `noResourcesLeft' indicates that the runtime system does
not have enough resources to load the script.
- `unknownProtocol' indicates that the script could not be
loaded from the smScriptSource because the requested
protocol is not supported.
- `protocolFailure' indicates that the script could not be
loaded from the smScriptSource because of a protocol
failure.
- `genericError' indicates that the script could not be
loaded due to an error condition not listed above.
The `retrieving' and `compiling' states are transient states
which will either lead to one of the error states or the
`enabled' state. The `disabled' and `editing' states are
administrative states which are only reached by explicit
management operations.
All launch table entries that refer to this script table
entry shall have an smLaunchOperStatus value of `disabled'
when the value of this object is not `enabled'."
DEFVAL { disabled }
::= { smScriptEntry 7 }
smScriptStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this row and the script
controlled by this row are kept in volatile storage and
lost upon reboot or if this row is backed up by
non-volatile or permanent storage.
The storage type of this row always complies with the value
of this entry if the value of the corresponding RowStatus
object is `active'.
However, the storage type of the script controlled by this
row may be different, if the value of this entry is
`non-volatile'. The script controlled by this row is written
into local non-volatile storage if the following condition
becomes true:
(a) the URL contained in the smScriptSource object is empty
and
(b) the smScriptStorageType is `nonVolatile'
and
(c) the smScriptOperStatus is `enabled'
Setting this object to `volatile' removes a script from
non-volatile storage if the script controlled by this row
has been in non-volatile storage before. Attempts to set
this object to permanent will always fail with an
inconsistentValue error.
The value of smScriptStorageType is only meaningful if the
value of the corresponding RowStatus object is `active'.
If smScriptStorageType has the value permanent(4), then all
objects whose MAX-ACCESS value is read-create must be
writable, with the exception of the smScriptStorageType and
smScriptRowStatus objects, which shall be read-only."
DEFVAL { volatile }
::= { smScriptEntry 8 }
smScriptRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control that allows entries to be added and removed from
this table.
Changing the smScriptRowStatus from `active' to
`notInService' will remove the associated script from the
runtime system.
Deleting conceptual rows from this table may affect the
deletion of other resources associated with this row. For
example, a script stored in non-volatile storage may be
removed from non-volatile storage.
An entry may not exist in the `active' state unless all
required objects in the entry have appropriate values. Rows
that are not complete or not in service are not known by the
script runtime system.
Attempts to `destroy' a row or to set a row `notInService'
while the smScriptOperStatus is `enabled' will result in an
inconsistentValue error.
Attempts to `destroy' a row or to set a row `notInService'
where the value of the smScriptStorageType object is
`permanent' or `readOnly' will result in an
inconsistentValue error.
The value of this object has no effect on whether other
objects in this conceptual row can be modified."
::= { smScriptEntry 9 }
smScriptError OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains a descriptive error message if the
transition into the operational status `enabled' failed.
Implementations must reset the error message to a
zero-length string when a new attempt to change the
script status to `enabled' is started."
DEFVAL { ''H }
::= { smScriptEntry 10 }
smScriptLastChange OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when this script table entry was last
modified. The value '0000000000000000'H is returned if
the script table entry has not yet been modified.
Note that the resetting of smScriptError is not considered
a change of the script table entry."
DEFVAL { '0000000000000000'H }
::= { smScriptEntry 11 }
--
-- Access to script code via SNMP
--
-- The smCodeTable allows script code to be read and modified
-- via SNMP.
--
smCodeTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmCodeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the script code for scripts that are
written via SNMP write operations."
::= { smScriptObjects 2 }
smCodeEntry OBJECT-TYPE
SYNTAX SmCodeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular fragment of a script."
INDEX { smScriptOwner, smScriptName, smCodeIndex }
::= { smCodeTable 1 }
SmCodeEntry ::= SEQUENCE {
smCodeIndex Unsigned32,
smCodeText OCTET STRING,
smCodeRowStatus RowStatus
}
smCodeIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index value identifying this code fragment."
::= { smCodeEntry 1 }
smCodeText OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..1024))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The code that makes up a fragment of a script. The format
of this code fragment depends on the script language which
is identified by the associated smScriptLanguage object."
::= { smCodeEntry 2 }
smCodeRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control that allows entries to be added and removed from
this table.
The value of this object has no effect on whether other
objects in this conceptual row can be modified."
::= { smCodeEntry 3 }
--
-- Script execution.
--
-- This group defines tables which allow script execution to be
-- initiated, suspended, resumed, and terminated. It also provides
-- a mechanism for keeping a history of recent script executions
-- and their results.