diff options
Diffstat (limited to 'doc/rfc/rfc2592.txt')
| -rw-r--r-- | doc/rfc/rfc2592.txt | 2971 |
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc2592.txt b/doc/rfc/rfc2592.txt new file mode 100644 index 0000000..3d0fa8d --- /dev/null +++ b/doc/rfc/rfc2592.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group D. Levi +Request for Comments: 2592 Nortel Networks +Category: Standards Track J. Schoenwaelder + TU Braunschweig + May 1999 + + + 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 (1999). 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 ................................................. 2 + 2. The SNMP Management Framework ................................ 2 + 3. Overview ..................................................... 3 + 3.1 Terms ...................................................... 4 + 4. Requirements and Design Issues .............................. 5 + 4.1 Script Languages ........................................... 5 + 4.2 Script Transfer ............................................ 6 + 4.3 Script Execution ........................................... 7 + 5. The Structure of the MIB ..................................... 8 + 5.1 The smLanguageGroup ........................................ 9 + 5.2 The smScriptGroup .......................................... 9 + 5.3 The smCodeGroup ............................................ 10 + 5.4 The smLaunchGroup .......................................... 10 + 5.5 The smRunGroup ............................................. 11 + 6 Definitions .................................................. 11 + 7. Usage Examples ............................................... 41 + 7.1 Pushing a script via SNMP .................................. 41 + + + +Levi & Schoenwaelder Standards Track [Page 1] + +RFC 2592 Script MIB May 1999 + + + 7.2 Pulling a script from a URL ................................ 42 + 7.3 Modifying an existing script ............................... 42 + 7.4 Removing an existing script ................................ 43 + 7.5 Creating a launch button ................................... 43 + 7.6 Launching a script ......................................... 44 + 7.7 Terminating a script ....................................... 44 + 7.8 Removing a launch button ................................... 45 + 8. VACM Configuration Examples .................................. 45 + 8.1 Sandbox for guests ......................................... 45 + 8.2 Sharing scripts ............................................ 46 + 8.3 Emergency scripts .......................................... 47 + 9. IANA Considerations .......................................... 48 + 10. Security Considerations ..................................... 48 + 11. Intellectual Property ....................................... 49 + 12. Acknowledgments ............................................. 49 + 13. References .................................................. 50 + 14. Editors' Addresses .......................................... 52 + 16. Full Copyright Statement .................................... 53 + +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 RFC 2119 [21]. + +2. The SNMP Management Framework + + The SNMP Management Framework presently consists of five major + components: + + o An overall architecture, described in RFC 2271 [1]. + + 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, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 + [4]. The second version, called SMIv2, is described in STD 58, + RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. + + + + + + + + +Levi & Schoenwaelder Standards Track [Page 2] + +RFC 2592 Script MIB May 1999 + + + o Message protocols for transferring management information. The + first version of the SNMP message protocol is called SNMPv1 + and described in STD 15, RFC 1157 [8]. A second version of the + SNMP message protocol, which is not an Internet standards + track protocol, is called SNMPv2c and described in RFC 1901 + [9] and RFC 1906 [10]. The third version of the message + protocol is called SNMPv3 and described in RFC 1906 [10], RFC + 2272 [11] and RFC 2274 [12]. + + o Protocol operations for accessing management information. The + first set of protocol operations and associated PDU formats is + described in STD 15, RFC 1157 [8]. A second set of protocol + operations and associated PDU formats is described in RFC 1905 + [13]. + + o A set of fundamental applications described in RFC 2273 [14] + and the view-based access control mechanism described in RFC + 2275 [15]. + + 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. + + 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. + + + +Levi & Schoenwaelder Standards Track [Page 3] + +RFC 2592 Script MIB May 1999 + + + 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. Note, 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 RFC 2271 [1]. For example, a + runtime system which sends SNMP requests to other SNMP entities + will act as a command generator application. The SNMP + + + +Levi & Schoenwaelder Standards Track [Page 4] + +RFC 2592 Script MIB May 1999 + + + 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 assignes 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 [15]. + + 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: + + + + + + +Levi & Schoenwaelder Standards Track [Page 5] + +RFC 2592 Script MIB May 1999 + + + 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. + + + + +Levi & Schoenwaelder Standards Track [Page 6] + +RFC 2592 Script MIB May 1999 + + + 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) [17] 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 [18] or HTTP + [19] 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. + + + + + + +Levi & Schoenwaelder Standards Track [Page 7] + +RFC 2592 Script MIB May 1999 + + + 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. The Structure of the MIB + + This section presents the structure of the MIB. The objects are + arranged into the following groups: + + o language group (smLanguageGroup) + + o script group (smScriptGroup) + + o script code group (smCodeGroup) + + o script launch group (smLaunchGroup) + + o running script group (smRunGroup) + + + + + + + +Levi & Schoenwaelder Standards Track [Page 8] + +RFC 2592 Script MIB May 1999 + + +5.1. The smLanguageGroup + + 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. The smScriptGroup + + 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 + + + +Levi & Schoenwaelder Standards Track [Page 9] + +RFC 2592 Script MIB May 1999 + + + 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. The smCodeGroup + + 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. The smLaunchGroup + + 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. + + + + + + +Levi & Schoenwaelder Standards Track [Page 10] + +RFC 2592 Script MIB May 1999 + + +5.5. The smRunGroup + + 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 "9902221800Z" + + + +Levi & Schoenwaelder Standards Track [Page 11] + +RFC 2592 Script MIB May 1999 + + + ORGANIZATION "IETF Distributed Management Working Group" + CONTACT-INFO + "David B. Levi + Nortel Networks + 4401 Great America Parkway + Santa Clara, CA 95052-8185 + U.S.A. + Tel: +1 423 686 0432 + E-mail: dlevi@nortelnetworks.com + + Juergen Schoenwaelder + TU Braunschweig + Bueltenweg 74/75 + 38106 Braunschweig + Germany + Tel: +49 531 391-3283 + E-mail: schoenw@ibr.cs.tu-bs.de" + DESCRIPTION + "This MIB module defines a set of objects that allow to + delegate management scripts to distributed managers." + ::= { 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 + + + +Levi & Schoenwaelder Standards Track [Page 12] + +RFC 2592 Script MIB May 1999 + + + 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, 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. + + + +Levi & Schoenwaelder Standards Track [Page 13] + +RFC 2592 Script MIB May 1999 + + + 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 identifer which identifies the vendor who + provides the implementation of the language. This object + identifer 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 } + + + +Levi & Schoenwaelder Standards Track [Page 14] + +RFC 2592 Script MIB May 1999 + + + 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. + + + + +Levi & Schoenwaelder Standards Track [Page 15] + +RFC 2592 Script MIB May 1999 + + + 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 identifer which identifies the vendor who + provides the implementation of the extension. The + object identifer 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. + -- + + + +Levi & Schoenwaelder Standards Track [Page 16] + +RFC 2592 Script MIB May 1999 + + + 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 + } + + 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 + 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. + + + +Levi & Schoenwaelder Standards Track [Page 17] + +RFC 2592 Script MIB May 1999 + + + 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. + + Note, 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 RFC 2396. The allowed character sets and the + encoding rules defined in RFC 2396 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. + + + + +Levi & Schoenwaelder Standards Track [Page 18] + +RFC 2592 Script MIB May 1999 + + + 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. A 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), + + + +Levi & Schoenwaelder Standards Track [Page 19] + +RFC 2592 Script MIB May 1999 + + + 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 + + + +Levi & Schoenwaelder Standards Track [Page 20] + +RFC 2592 Script MIB May 1999 + + + 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 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 + + + +Levi & Schoenwaelder Standards Track [Page 21] + +RFC 2592 Script MIB May 1999 + + + 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. + The value of smScriptOperStatus will be reset to `disabled'. + + Deleting conceptual rows from this table includes the + deletion of all resources associated with this row. This + implies that a script stored in non-volatile storage is + 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 script is executing 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." + ::= { smScriptEntry 9 } + + + -- + -- Access to script code via SNMP + -- + -- The smCodeTable allows script code to be read and modified + -- via SNMP. + -- + + + +Levi & Schoenwaelder Standards Track [Page 22] + +RFC 2592 Script MIB May 1999 + + + 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 + + + +Levi & Schoenwaelder Standards Track [Page 23] + +RFC 2592 Script MIB May 1999 + + + this table." + ::= { 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. + -- + + smRunObjects OBJECT IDENTIFIER ::= { smObjects 4 } + + smLaunchTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmLaunchEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists and describes scripts that are ready + to be executed together with their parameters." + ::= { smRunObjects 1 } + + smLaunchEntry OBJECT-TYPE + SYNTAX SmLaunchEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describing a particular executable script." + INDEX { smLaunchOwner, smLaunchName } + ::= { smLaunchTable 1 } + + SmLaunchEntry ::= SEQUENCE { + smLaunchOwner SnmpAdminString, + smLaunchName SnmpAdminString, + smLaunchScriptOwner SnmpAdminString, + smLaunchScriptName SnmpAdminString, + smLaunchArgument OCTET STRING, + smLaunchMaxRunning Unsigned32, + smLaunchMaxCompleted Unsigned32, + smLaunchLifeTime TimeInterval, + smLaunchExpireTime TimeInterval, + smLaunchStart Integer32, + smLaunchControl INTEGER, + smLaunchAdminStatus INTEGER, + smLaunchOperStatus INTEGER, + smLaunchRunIndexNext Integer32, + smLaunchStorageType StorageType, + + + +Levi & Schoenwaelder Standards Track [Page 24] + +RFC 2592 Script MIB May 1999 + + + smLaunchRowStatus RowStatus + } + + smLaunchOwner OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + "The manager who owns this row in the smLaunchTable. Every + instance of a running script started from a particular entry + in the smLaunchTable (i.e. entries in the smRunTable) will be + owned by the same smLaunchOwner used to index the entry in + the smLaunchTable. This owner is not necessarily the same as + the owner of the script itself (smLaunchScriptOwner)." + ::= { smLaunchEntry 1 } + + smLaunchName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (1..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The locally-unique, administratively assigned name for this + launch table entry. This object allows an smLaunchOwner to + have multiple entries in the smLaunchTable. The smLaunchName + is an arbitrary name that must be different from any other + smLaunchTable entries with the same smLaunchOwner but can be + the same as other entries in the smLaunchTable with different + smLaunchOwner values. Note that the value of smLaunchName + is not related in any way to the name of the script being + launched." + ::= { smLaunchEntry 2 } + + smLaunchScriptOwner OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The value of this object in combination with the value of + smLaunchScriptName identifies the script that can be + launched from this smLaunchTable entry. Attempts to write + this object will fail with an inconsistentValue error if + the value of smLaunchOperStatus is `enabled'." + ::= { smLaunchEntry 3 } + + smLaunchScriptName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-create + + + +Levi & Schoenwaelder Standards Track [Page 25] + +RFC 2592 Script MIB May 1999 + + + STATUS current + DESCRIPTION + "The value of this object in combination with the value of + the smLaunchScriptOwner identifies the script that can be + launched from this smLaunchTable entry. Attempts to write + this objects will fail with an inconsistentValue error if + the value of smLaunchOperStatus is `enabled'." + ::= { smLaunchEntry 4 } + + smLaunchArgument OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The argument supplied to the script. When a script is + invoked, the value of this object is used to initialize + the smRunArgument object." + DEFVAL { ''H } + ::= { smLaunchEntry 5 } + + smLaunchMaxRunning OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The maximum number of concurrently running scripts that may + be invoked from this entry in the smLaunchTable. Lowering the + current value of this object does not affect any scripts that + are already executing." + DEFVAL { 1 } + ::= { smLaunchEntry 6 } + + smLaunchMaxCompleted OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The maximum number of finished scripts invoked from this + entry in the smLaunchTable allowed to be retained in the + smRunTable. Whenever the value of this object is changed + and whenever a script terminates, entries in the smRunTable + are deleted if necessary until the number of completed + scripts is smaller than the value of this object. Scripts + whose smRunEndTime value indicates the oldest completion + time are deleted first." + DEFVAL { 1 } + ::= { smLaunchEntry 7 } + + + + +Levi & Schoenwaelder Standards Track [Page 26] + +RFC 2592 Script MIB May 1999 + + + smLaunchLifeTime OBJECT-TYPE + SYNTAX TimeInterval + UNITS "centi-seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The default maximum amount of time a script launched + from this entry may run. The value of this object is used + to initialize the smRunLifeTime object when a script is + launched. Changing the value of an smLaunchLifeTime + instance does not affect scripts previously launched from + this entry." + DEFVAL { 360000 } + ::= { smLaunchEntry 8 } + + smLaunchExpireTime OBJECT-TYPE + SYNTAX TimeInterval + UNITS "centi-seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The default maximum amount of time information about a + script launched from this entry is kept in the smRunTable + after the script has completed execution. The value of + this object is used to initialize the smRunExpireTime + object when a script is launched. Changing the value of an + smLaunchExpireTime instance does not affect scripts + previously launched from this entry." + DEFVAL { 360000 } + ::= { smLaunchEntry 9 } + + smLaunchStart OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is used to start the execution of scripts. + When retrieved, the value will be the value of smRunIndex + for the last script that started execution by manipulating + this object. The value will be zero if no script started + execution yet. + + A script is started by setting this object to an unused + smRunIndex value. A new row in the smRunTable will be + created which is indexed by the value supplied by the + set-request in addition to the value of smLaunchOwner and + smLaunchName. An unused value can be obtained by reading + the smLaunchRunIndexNext object. + + + +Levi & Schoenwaelder Standards Track [Page 27] + +RFC 2592 Script MIB May 1999 + + + Setting this object to the special value 0 will start + the script with a self-generated smRunIndex value. The + consequence is that the script invoker has no reliable + way to determine the smRunIndex value for this script + invocation and that the invoker has therefore no way + to obtain the results from this script invocation. The + special value 0 is however useful for scheduled script + invocations. + + If this object is set, the following checks must be + performed: + + 1) The value of the smLaunchOperStatus object in this + entry of the smLaunchTable must be `enabled'. + 2) The values of smLaunchScriptOwner and + smLaunchScriptName of this row must identify an + existing entry in the smScriptTable. + 3) The value of smScriptOperStatus of this entry must + be `enabled'. + 4) The principal performing the set operation must have + read access to the script. This must be checked by + calling the isAccessAllowed abstract service interface + defined in RFC 2271 on the row in the smScriptTable + identified by smLaunchScriptOwner and smLaunchScriptName. + The isAccessAllowed abstract service interface must be + called on all columnar objects in the smScriptTable with + a MAX-ACCESS value different than `not-accessible'. The + test fails as soon as a call indicates that access is + not allowed. + 5) If the value provided by the set operation is not 0, + a check must be made that the value is currently not + in use. Otherwise, if the value provided by the set + operation is 0, a suitable unused value must be + generated. + 6) The number of currently executing scripts invoked + from this smLaunchTable entry must be less than + smLaunchMaxRunning. + + Attempts to start a script will fail with an + inconsistentValue error if one of the checks described + above fails. + + Otherwise, if all checks have been passed, a new entry + in the smRunTable will be created indexed by smLaunchOwner, + smLaunchName and the new value for smRunIndex. The value + of smLaunchArgument will be copied into smRunArgument, + the value of smLaunchLifeTime will be copied to + smRunLifeTime, and the value of smLaunchExpireTime + + + +Levi & Schoenwaelder Standards Track [Page 28] + +RFC 2592 Script MIB May 1999 + + + will be copied to smRunExpireTime. + + The smRunStartTime will be set to the current time and + the smRunState will be set to `initializing' before the + script execution is initiated in the appropriate runtime + system. + + Note, the data type and the range of this object must + be consistent with the smRunIndex object. Since this + object might be written from the scheduling MIB, the + data type Integer32 rather than Unsigned32 is used." + DEFVAL { 0 } + ::= { smLaunchEntry 10 } + + smLaunchControl OBJECT-TYPE + SYNTAX INTEGER { + abort(1), + suspend(2), + resume(3), + nop(4) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is used to request a state change for all + running scripts in the smRunTable that were started from + this row in the smLaunchTable. + + Setting this object to abort(1), suspend(2) or resume(3) + will set the smRunControl object of all applicable rows + in the smRunTable to abort(1), suspend(2) or resume(3) + respectively. The phrase `applicable rows' means the set of + rows which were created from this entry in the smLaunchTable + and whose value of smRunState allows the corresponding + state change as described in the definition of the + smRunControl object. Setting this object to nop(4) has no + effect." + DEFVAL { nop } + ::= { smLaunchEntry 11 } + + smLaunchAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + enabled(1), + disabled(2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Levi & Schoenwaelder Standards Track [Page 29] + +RFC 2592 Script MIB May 1999 + + + "The value of this object indicates the desired status of + this launch table entry." + DEFVAL { disabled } + ::= { smLaunchEntry 12 } + + smLaunchOperStatus OBJECT-TYPE + SYNTAX INTEGER { + enabled(1), + disabled(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object indicates the actual status of + this launch table entry. An `enabled' launch table + entry can be used to start scripts while a `disabled' + launch table entry will refuse any attempts to start + scripts. The value `enabled' requires that the + smLaunchRowStatus object is active. The value + `disabled' requires that there are no entries in the + smRunTable associated with this smLaunchTable entry." + DEFVAL { disabled } + ::= { smLaunchEntry 13 } + + smLaunchRunIndexNext OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable is used for creating rows in the smRunTable. + The value of this variable is a currently unused value + for smRunIndex, which can be written into the smLaunchStart + object associated with this row to launch a script. + + The value returned when reading this variable must be unique + for the smLaunchOwner and smLauchName associated with this + row. Subsequent attempts to read this variable must return + different values. + + This variable will return the special value 0 if no new rows + can be created. + + Note, the data type and the range of this object must be + consistent with the definition of smRunIndex." + ::= { smLaunchEntry 14 } + + smLaunchStorageType OBJECT-TYPE + SYNTAX StorageType + + + +Levi & Schoenwaelder Standards Track [Page 30] + +RFC 2592 Script MIB May 1999 + + + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines if this row is kept in volatile storage + and lost upon reboot or if this row is backed up by stable + storage. + + The value of smLaunchStorageType is only meaningful if the + value of the corresponding RowStatus object is active. + + If smLaunchStorageType has the value permanent(4), then all + objects whose MAX-ACCESS value is read-create must be + writable, with the exception of the smLaunchStorageType and + smLaunchRowStatus objects, which shall be read-only." + DEFVAL { volatile } + ::= { smLaunchEntry 15 } + + smLaunchRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A control that allows entries to be added and removed from + this table. + + Attempts to `destroy' a row or to set a row `notInService' + while scripts started from this launch table entry are + running will result in an inconsistentValue error. + + Attempts to `destroy' a row or to set a row `notInService' + where the value of the smLaunchStorageType object is + `permanent' or `readOnly' will result in an + inconsistentValue error." + ::= { smLaunchEntry 16 } + + + smRunTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmRunEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists and describes scripts that are currently + running or have been running in the past." + ::= { smRunObjects 2 } + + smRunEntry OBJECT-TYPE + SYNTAX SmRunEntry + MAX-ACCESS not-accessible + + + +Levi & Schoenwaelder Standards Track [Page 31] + +RFC 2592 Script MIB May 1999 + + + STATUS current + DESCRIPTION + "An entry describing a particular running or finished + script." + INDEX { smLaunchOwner, smLaunchName, smRunIndex } + ::= { smRunTable 1 } + + SmRunEntry ::= SEQUENCE { + smRunIndex Integer32, + smRunArgument OCTET STRING, + smRunStartTime DateAndTime, + smRunEndTime DateAndTime, + smRunLifeTime TimeInterval, + smRunExpireTime TimeInterval, + smRunExitCode INTEGER, + smRunResult OCTET STRING, + smRunControl INTEGER, + smRunState INTEGER, + smRunError SnmpAdminString + } + + smRunIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The locally arbitrary, but unique identifier associated + with this running or finished script. This value must be + unique for all rows in the smRunTable with the same + smLaunchOwner and smLaunchName. + + Note, the data type and the range of this object must be + consistent with the definition of smLaunchRunIndexNext + and smLaunchStart." + ::= { smRunEntry 1 } + + smRunArgument OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The argument supplied to the script when it started." + DEFVAL { ''H } + ::= { smRunEntry 2 } + + smRunStartTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + + + +Levi & Schoenwaelder Standards Track [Page 32] + +RFC 2592 Script MIB May 1999 + + + STATUS current + DESCRIPTION + "The date and time when the execution started. The value + '0000000000000000'H is returned if the script has not + started yet." + DEFVAL { '0000000000000000'H } + ::= { smRunEntry 3 } + + smRunEndTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The date and time when the execution terminated. The value + '0000000000000000'H is returned if the script has not + terminated yet." + DEFVAL { '0000000000000000'H } + ::= { smRunEntry 4 } + + smRunLifeTime OBJECT-TYPE + SYNTAX TimeInterval + UNITS "centi-seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies how long the script can execute. + This object returns the remaining time that the script + may run. The object is initialized with the value of the + associated smLaunchLifeTime object and ticks backwards. + The script is aborted immediately when the value reaches 0. + + The value of this object may be set in order to increase or + reduce the remaining time that the script may run. Setting + this value to 0 will abort script execution immediately, + and, if the value of smRunExpireTime is also 0, will remove + this entry from the smRunTable once it has terminated. + + The value of smRunLifeTime reflects the real-time execution + time as seen by the outside world. The value of this object + will always be 0 for a script that finished execution, that + is smRunState has the value `terminated'. + + The value of smRunLifeTime does not change while a script + is suspended, that is smRunState has the value `suspended'. + Note, this does not affect set operations. It is legal to + modify smRunLifeTime via set operations while a script is + suspended." + ::= { smRunEntry 5 } + + + +Levi & Schoenwaelder Standards Track [Page 33] + +RFC 2592 Script MIB May 1999 + + + smRunExpireTime OBJECT-TYPE + SYNTAX TimeInterval + UNITS "centi-seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This value specifies how long this row can exist in the + smRunTable after the script has terminated. This object + returns the remaining time that the row may exist before it + is aged out. The object is initialized with the value of the + associated smLaunchExpireTime object and ticks backwards. The + entry in the smRunTable is destroyed when the value reaches 0 + and the smRunState has the value `terminated'. + + The value of this object may be set in order to increase or + reduce the remaining time that the row may exist. Setting + the value to 0 will destroy this entry as soon as the + smRunState has the value `terminated'." + ::= { smRunEntry 6 } + + smRunExitCode OBJECT-TYPE + SYNTAX INTEGER { + noError(1), + halted(2), + lifeTimeExceeded(3), + noResourcesLeft(4), + languageError(5), + runtimeError(6), + invalidArgument(7), + securityViolation(8), + genericError(9) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object indicates the reason why a + script finished execution. The smRunExitCode code may have + one of the following values: + + - `noError', which indicates that the script completed + successfully without errors; + + - `halted', which indicates that the script was halted + by a request from an authorized manager; + + - `lifeTimeExceeded', which indicates that the script + exited because a time limit was exceeded; + + + + +Levi & Schoenwaelder Standards Track [Page 34] + +RFC 2592 Script MIB May 1999 + + + - `noResourcesLeft', which indicates that the script + exited because it ran out of resources (e.g. memory); + + - `languageError', which indicates that the script exited + because of a language error (e.g. a syntax error in an + interpreted language); + + - `runtimeError', which indicates that the script exited + due to a runtime error (e.g. a division by zero); + + - `invalidArgument', which indicates that the script could + not be run because of invalid script arguments; + + - `securityViolation', which indicates that the script + exited due to a security violation; + + - `genericError', which indicates that the script exited + for an unspecified reason. + + If the script has not yet begun running, or is currently + running, the value will be `noError'." + DEFVAL { noError } + ::= { smRunEntry 7 } + + smRunResult OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The result value produced by the running script. Note that + the result may change while the script is executing." + DEFVAL { ''H } + ::= { smRunEntry 8 } + + smRunControl OBJECT-TYPE + SYNTAX INTEGER { + abort(1), + suspend(2), + resume(3), + nop(4) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The value of this object indicates the desired status of the + script execution defined by this row. + + Setting this object to `abort' will abort execution if the + + + +Levi & Schoenwaelder Standards Track [Page 35] + +RFC 2592 Script MIB May 1999 + + + value of smRunState is `initializing', `executing', + `suspending', `suspended' or `resuming'. Setting this object + to `abort' when the value of smRunState is `aborting' or + `terminated' will result in an inconsistentValue error. + + Setting this object to `suspend' will suspend execution + if the value of smRunState is `executing'. Setting this + object to `suspend' will cause an inconsistentValue error + if the value of smRunState is not `executing'. + + Setting this object to `resume' will resume execution + if the value of smRunState is `suspending' or + `suspended'. Setting this object to `resume' will cause an + inconsistentValue error if the value of smRunState is + not `suspending' or `suspended'. + + Setting this object to nop(4) has no effect." + DEFVAL { nop } + ::= { smRunEntry 9 } + + smRunState OBJECT-TYPE + SYNTAX INTEGER { + initializing(1), + executing(2), + suspending(3), + suspended(4), + resuming(5), + aborting(6), + terminated(7) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object indicates the script's execution + status. If the script has been invoked but has not yet + begun execution, the value will be `initializing'. If the + script is running, the value will be `executing'. A script + which received a request to suspend execution but which + did not actually suspend execution will be `suspending'. + A script which has suspended execution will be `suspended'. + A script which received a request to resume execution but + which is not yet running is `resuming'. The resuming state + will finally lead to the `executing' state. A script which + received a request to abort execution but which is still + running is `aborting'. A script which stopped execution + is `terminated'." + ::= { smRunEntry 10 } + + + + +Levi & Schoenwaelder Standards Track [Page 36] + +RFC 2592 Script MIB May 1999 + + + smRunError OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This contains a descriptive error message if the script + terminates in an abnormally. An implementation must store a + descriptive error message in this object if the script exits + with the smRunExitCode `genericError'. + + The value of this object is the zero-length string as long + as the smRunExitCode has the value `noError'" + DEFVAL { ''H } + ::= { smRunEntry 11 } + + -- + -- Notifications. The definition of smTraps makes notification + -- registrations reversible (see STD 58, RFC 2578). + -- + + smTraps OBJECT IDENTIFIER ::= { smNotifications 0 } + + smScriptAbort NOTIFICATION-TYPE + OBJECTS { smRunExitCode, smRunEndTime, smRunError } + STATUS current + DESCRIPTION + "This notification is generated whenever a running script + terminates with an smRunExitCode unequal to `noError'." + ::= { smTraps 1 } + + smScriptResult NOTIFICATION-TYPE + OBJECTS { smRunResult } + STATUS current + DESCRIPTION + "This notification can be used by scripts to notify other + management applications about script results. It can be + used to notify managers about a script result. + + This notification is not automatically generated by the + script MIB implementation. It is the responsibility of + the executing script to emit this notification where it + is appropriate to do so." + ::= { smTraps 2 } + + -- conformance information + smCompliances OBJECT IDENTIFIER ::= { smConformance 1 } + smGroups OBJECT IDENTIFIER ::= { smConformance 2 } + + + + +Levi & Schoenwaelder Standards Track [Page 37] + +RFC 2592 Script MIB May 1999 + + + -- compliance statements + + smCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities which implement + the script MIB." + MODULE -- this module + MANDATORY-GROUPS { + smLanguageGroup, smScriptGroup, smLaunchGroup, smRunGroup + } + GROUP smCodeGroup + DESCRIPTION + "The smCodeGroup is mandatory only for those implementations + that support the downloading of scripts via SNMP." + OBJECT smScriptSource + MIN-ACCESS read-only + DESCRIPTION + "The smScriptSource object is read-only for implementations + that are not able to download script code from a URL." + OBJECT smLaunchArgument + DESCRIPTION + "A compliant implementation has to support a minimum size + for smLaunchArgument of 255 octets." + OBJECT smRunArgument + DESCRIPTION + "A compliant implementation has to support a minimum size + for smRunArgument of 255 octets." + OBJECT smRunResult + DESCRIPTION + "A compliant implementation has to support a minimum size + for smRunResult of 255 octets." + OBJECT smRunState + DESCRIPTION + "A compliant implementation does not have to support script + suspension and the smRunState `suspended'. Such an + implementation will change into the `suspending' state + when the smRunControl is set to `suspend' and remain in this + state until smRunControl is set to `resume' or the script + terminates." + ::= { smCompliances 1 } + + smLanguageGroup OBJECT-GROUP + OBJECTS { + smLangLanguage, + smLangVersion, + smLangVendor, + smLangRevision, + + + +Levi & Schoenwaelder Standards Track [Page 38] + +RFC 2592 Script MIB May 1999 + + + smLangDescr, + smExtsnExtension, + smExtsnVersion, + smExtsnVendor, + smExtsnRevision, + smExtsnDescr + } + STATUS current + DESCRIPTION + "A collection of objects providing information about the + capabilities of the scripting engine." + ::= { smGroups 1 } + + smScriptGroup OBJECT-GROUP + OBJECTS { + smScriptDescr, + smScriptLanguage, + smScriptSource, + smScriptAdminStatus, + smScriptOperStatus, + smScriptStorageType, + smScriptRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + installed scripts." + ::= { smGroups 2 } + + smCodeGroup OBJECT-GROUP + OBJECTS { + smCodeText, + smCodeRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects used to download or modify scripts + by using SNMP set requests." + ::= { smGroups 3 } + + smLaunchGroup OBJECT-GROUP + OBJECTS { + smLaunchScriptOwner, + smLaunchScriptName, + smLaunchArgument, + smLaunchMaxRunning, + smLaunchMaxCompleted, + smLaunchLifeTime, + + + +Levi & Schoenwaelder Standards Track [Page 39] + +RFC 2592 Script MIB May 1999 + + + smLaunchExpireTime, + smLaunchStart, + smLaunchControl, + smLaunchAdminStatus, + smLaunchOperStatus, + smLaunchRunIndexNext, + smLaunchStorageType, + smLaunchRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects providing information about scripts + that can be launched." + ::= { smGroups 4 } + + smRunGroup OBJECT-GROUP + OBJECTS { + smRunArgument, + smRunStartTime, + smRunEndTime, + smRunLifeTime, + smRunExpireTime, + smRunExitCode, + smRunResult, + smRunState, + smRunControl, + smRunError + } + STATUS current + DESCRIPTION + "A collection of objects providing information about running + scripts." + ::= { smGroups 5 } + + smNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + smScriptAbort, + smScriptResult + } + STATUS current + DESCRIPTION + "The notifications emitted by the script MIB." + ::= { smGroups 6 } + + END + + + + + + +Levi & Schoenwaelder Standards Track [Page 40] + +RFC 2592 Script MIB May 1999 + + +7. Usage Examples + + This section presents some examples that explain how a manager can + use the Script MIB defined in this memo. The purpose of these + examples is to explain the steps that are normally used to delegate + management scripts. + +7.1. Pushing a script via SNMP + + This example explains the steps performed by a manager to push a + script into a distributed manager. + + 1. The manager first checks the smLanguageTable and the + smExtensionTable in order to select the appropriate script or + language. + + 2. The manager creates a row in the smScriptTable by issuing an + SNMP set-request. The smScriptRowStatus object is set to + `createAndWait' and the smScriptSource object is set to an empty + string. The smScriptLanguage object is set to the language in + which the script was written. The smScriptStorageType object is + set to `volatile' to indicate that the script will be loaded via + the smCodeTable. The smScriptOwner is set to a string which + identifies the principal who owns the new row. The smScriptName + defines the administratively assigned unique name for the + script. + + 3. The manager sets the smScriptRowStatus object to `active' and + the smScriptAdminStatus object to `editing'. + + 4. The manager pushes the script to the distributed manager by + issuing a couple of SNMP set-requests to fill the smCodeTable. + + 5. Once the whole script has been transferred, the manager sends a + set-request to set the smScriptAdminStatus object to `enabled'. + The Script MIB implementation now makes the script accessible to + the runtime system. This might include the compilation of the + script if the language requires a compilation step. + + 6. The manager polls the smScriptOperStatus object until the value + is either `enabled' or one of the error status codes. The + script can only be used if the value of smScriptOperStatus is + `enabled'. + + 7. If the manager wants to store the script in local non-volatile + storage, it should send a set-request which changes the + smScriptStorageType object to `nonVolatile'. + + + + +Levi & Schoenwaelder Standards Track [Page 41] + +RFC 2592 Script MIB May 1999 + + +7.2. Pulling a script from a URL + + This example explains the steps performed by a manager to cause a + distributed manager to pull a script from a URL. + + 1. The manager first checks the smLanguageTable and the + smExtensionTable in order to select the appropriate script or + language. + + 2. The manager creates a row in the smScriptTable by issuing an + SNMP set-request. The smScriptRowStatus object is set to + `createAndWait' and the smScriptSource object is set to the URL + which points to the script source. The smScriptLanguage object + is set to the language in which the script was written. The + smScriptOwner is set to a string which identifies the principal + who owns the new row. The smScriptName defines the + administratively assigned unique name for the script. + + 3. The manager sets the smScriptRowStatus object to `active'. + + 4. The manager sends a set-request to set the smScriptAdminStatus + object to `enabled'. The Script MIB implementation now makes the + script accessible to the runtime system. This causes a retrieval + operation to pull the script from the URL stored in + smScriptSource. This retrieval operation might be followed by a + compile operation if the language requires a compilation step. + + 5. The manager polls the smScriptOperStatus object until the value + is either `enabled' or one of the error status codes. The + script can only be used if the value of smScriptOperStatus is + `enabled'. + + 6. If the manager wants to store the script in local non-volatile + storage, it should send a set-request which changes the + smScriptStorageType object to `nonVolatile'. + +7.3. Modifying an existing script + + This section explains how a manager can modify a script by sending + SNMP set-requests. + + 1. First, the script is de-activated by setting the + smScriptAdminStatus to `disabled'. + + 2. The manager polls the smScriptOperStatus object until the value + is `disabled'. + + + + + +Levi & Schoenwaelder Standards Track [Page 42] + +RFC 2592 Script MIB May 1999 + + + 3. The manager sets smScriptSource to an empty string and + smScriptAdminStatus to `editing'. This makes the script source + available in the smCodeTable. + + 4. The manager polls the smScriptOperStatus object until the value + is `editing'. + + 5. The manager sends SNMP set-requests to modify the script in the + smCodeTable. + + 6. The manager sends a set-request to set the smScriptAdminStatus + object to `enabled'. The Script MIB implementation now makes the + script accessible to the runtime system. This might include the + compilation of the script if the language requires a compilation + step. + + 7. The manager polls the smScriptOperStatus object until the value + is either `enabled' or one of the error status codes. The + script can only be used if the value of smScriptOperStatus is + `enabled'. + +7.4. Removing an existing script + + This section explains how a manager can remove a script from a + distributed manager. + + 1. First, the manager sets the smScriptAdminStatus to `disabled'. + This will ensure that no new scripts can be started while + running scripts finish their execution. + + 2. The manager polls the smScriptOperStatus object until the value + is `disabled'. + + 3. The manager sends an SNMP set-request to change the + smScriptRowStatus object to `destroy'. This will remove the row + and all associated resources from the Script MIB implementation. + +7.5. Creating a launch button + + This section explains how a manager can create a launch button for + starting a script. + + 1. The manager, who is identified by an smLaunchOwner value, first + chooses a name for the new row in the smLaunchTable. The manager + sends an SNMP set-request to set the smLaunchRowStatus object + for this smLaunchOwner and smLaunchName to `createAndWait'. + + + + + +Levi & Schoenwaelder Standards Track [Page 43] + +RFC 2592 Script MIB May 1999 + + + 2. The manager fills the new smLaunchTable row with all required + parameters. The smLaunchScriptOwner and smLaunchScriptName + values point to the script that should be started from this + launch button. + + 3. The manager sends a set-request to change smLaunchAdminStatus to + `enabled' once the new smLaunchTable row is complete. + + 4. The manager polls the smLaunchOperStatus object until the value + is `enabled'. + +7.6. Launching a script + + This section explains the suggested way to launch a script from a + given launch button. + + 1. The manager first retrieves the value of smLaunchRunIndexNext + from the launch button selected to start the script. + + 2. The manager sends an SNMP set-request to set the smLaunchStart + object to the value obtained in step 1. This will launch the + script if all necessary pre-conditions are satisfied (see the + definition of smLaunchStart for more details). The manager can + also provide the smLaunchArgument in the same set-request that + is used to start the script. Upon successful start, a new row + will be created in the smRunTable indexed by smLaunchOwner, + smLaunchName and the value written to smLaunchStart. + + Note, the first step is not required. A manager can also try to guess + an unused value for smRunIndex if he wants to start script in a + single transaction. A manager can also use the special value 0 if he + does not care about the results produced by the script. + +7.7. Terminating a script + + This section explains two ways to terminate a running script. The + first approach is as follows: + + 1. The manager sets the smRunControl object of the running script + or the smLaunchControl object of the launch button used to start + the running script to `abort'. Setting smLaunchControl will + abort all running scripts started from the launch button while + smRunControl will only abort the running script associated with + the smRunControl instance. + + + + + + + +Levi & Schoenwaelder Standards Track [Page 44] + +RFC 2592 Script MIB May 1999 + + + The second way to terminate a script is to set the smRunLifeTime to + zero which causes the runtime system to terminate the script with a + `lifeTimeExceeded' exit code: + + 1. The manager changes the value of smRunLifeTime to 0. This causes + the Script MIB implementation to abort the script because the + remaining life time has expired. + + Note, changing the smRunLifeTime value can also be used to increase + the permitted lifetime of a running script. For example, a manager + can choose to set smRunLifeTime to a small fixed time interval and + increase the value periodically. This strategy has the nice effect + that scripts terminate automatically if the manager loses contact + with the Script MIB engine. + +7.8. Removing a launch button + + This section explains how a manager can remove a launch button from a + distributed manager. + + 1. First, the manager sets the smLaunchAdminStatus to + `disabled'. This will ensure that no new scripts can be started + from this launch button while running script will finish their + execution. + + 2. The manager polls the smLaunchOperStatus object until the value + is `disabled'. + + 3. The manager sends an SNMP set-request to change the + smLaunchRowStatus object to `destroy'. This will remove the row + and all associated resources from the Script MIB implementation. + +8. VACM Configuration Examples + + This section shows how the view-based access control model defined in + RFC 2275 [15] can be configured to control access to the script MIB. + +8.1. Sandbox for guests + + The first example demonstrates how to configure VACM to give the + members of the VACM group "guest" limited access to the script MIB. + The MIB views defined below give the members of the "guest" group a + sandbox where they can install and start their own scripts, but not + access any other scripts maintained by the Script MIB implementation. + + vacmAccessReadView."guest"."".usm.authNoPriv = "guestReadView" + vacmAccessWriteView."guest"."".usm.authNoPriv = "guestWriteView" + + + + +Levi & Schoenwaelder Standards Track [Page 45] + +RFC 2592 Script MIB May 1999 + + + The guestReadView grants read access to the smLangTable, the + smExtsnTable and to all the table entries owned by "guest": + + guestReadView: + smLangTable (included) + smExtsnTable (included) + smScriptObjects.*.*.*."guest" (included) + smRunObjects.*.*.*."guest" (included) + + The guestWriteView grants write access to all the table entries owned + by "guest": + + guestWriteView: + smScriptObjects.*.*.*."guest" (included) + smRunObjects.*.*.*."guest" (included) + +8.2. Sharing scripts + + This example demonstrates how VACM can be used to share a repository + of scripts between the members of the "senior" and the members of the + "junior" VACM group: + + vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView" + vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView" + + juniorReadView: + smLangTable (included) + smExtsnTable (included) + smScriptObjects.*.*.*."junior" (included) + smRunObjects.*.*.*."junior" (included) + smScriptObjects.*.*.*."utils" (included) + + juniorWriteView: + smScriptObjects.*.*.*."junior" (included) + smRunObjects.*.*.*."junior" (included) + + The definitions above allow the members of the "junior" VACM group to + start the scripts owned by "utils" in addition to the script the + members of the "junior" VACM group installed themself. This is + accomplished by giving the members of "junior" read access to scripts + in "utils". This allows members of "junior" to create entries in the + smLauchTable which refer to scripts in "utils", and to launch those + scripts using these entries in the smLaunchTable. + + + + + + + + +Levi & Schoenwaelder Standards Track [Page 46] + +RFC 2592 Script MIB May 1999 + + + vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView" + vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView" + + seniorReadView: + smLangTable (included) + smExtsnTable (included) + smScriptObjects.*.*.*."senior" (included) + smRunObjects.*.*.*."senior" (included) + smScriptObjects.*.*.*."utils" (included) + + seniorWriteView: + smScriptObjects.*.*.*."senior" (included) + smRunObjects.*.*.*."senior" (included) + smScriptObjects.*.*.*."utils" (included) + + The definitions for the members of the "senior" VACM group allow to + start the scripts owned by "utils" in addition to the script the + members of the "senior" VACM group installed themself. The third + write access rule in the seniorWriteView also grants the permission + to install scripts owned by "utils". The members of the "senior" VACM + group therefore have the permissions to install and modify scripts + that can be called by the members of the "junior" VACM group. + +8.3. Emergency scripts + + + This example demonstrates how VACM can be used to allow the members + of the "junior" VACM group to launch scripts that are executed with + the permissions associated with the "emergency" owner. This works by + adding the following rules to the juniorReadView and the + juniorWriteView: + + juniorReadView: + smScriptObjects.*.*.*."emergency" (included) + smRunObjects.*.*.*."emergency" (included) + + juniorWriteView + smLaunchStart."emergency" (included) + smLaunchArgument."emergency" (included) + + The rules added to the juniorReadView grant read access to the + scripts, the launch buttons and the results owned by "emergency". The + rules added to the juniorWriteView grant write permissions to the + smLaunchStart and smLaunchArgument variables ownded by "emergency". + Members of the "junior" VACM group can therefore start scripts that + will execute under the owner "emergency". + + + + + +Levi & Schoenwaelder Standards Track [Page 47] + +RFC 2592 Script MIB May 1999 + + + seniorReadView: + smScriptObjects.*.*.*."emergency" (included) + smRunObjects.*.*.*."emergency" (included) + + seniorWriteView: + smScriptObjects.*.*.*."emergency" (included) + smRunObjects.*.*.*."emergency" (included) + + The rules added to the seniorReadView and the seniorWriteView will + give the members of the "senior" VACM group the rights to install + emergency scripts and to configure appropriate launch buttons. + +9. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) is responsible for + maintaining a MIB module which provides OID registrations for well- + known languages. The IANA language registry is intented to reduce + interoperability problems by providing a single list of well-known + languages. However, it is of course still possible to register + languages in private OID spaces. Registering languages in private + spaces is especially attractive if a language is used for + experimentation or if a language is only used in environments where + the distribution of MIB modules with the language registration does + not cause any maintenance problems. + + Any additions or changes to the list of languages registered via IANA + require Designated Expert Review as defined in the IANA guidelines + [20]. The Designated Expert will be selected by the IESG Area + Director for the IETF Operations and Management Area. + +10. Security Considerations + + This MIB provides the ability to distribute applications written in + an arbitrary language to remote systems in a network. The security + features of the languages available in a particular implementation + should be taken into consideration when deploying an implementation + of this MIB. + + To facilitate the provisioning of access control by a security + administrator using the View-Based Access Control Model (VACM) + defined in RFC 2275 [15] for tables in which multiple users may need + to independently create or modify entries, the initial index is used + as an "owner index". Such an initial index has a syntax of + SnmpAdminString, and can thus be trivially mapped to a securityName + or groupName as defined in VACM, in accordance with a security + policy. + + + + + +Levi & Schoenwaelder Standards Track [Page 48] + +RFC 2592 Script MIB May 1999 + + + All entries in related tables belonging to a particular user will + have the same value for this initial index. For a given user's + entries in a particular table, the object identifiers for the + information in these entries will have the same subidentifiers + (except for the "column" subidentifier) up to the end of the encoded + owner index. To configure VACM to permit access to this portion of + the table, one would create vacmViewTreeFamilyTable entries with the + value of vacmViewTreeFamilySubtree including the owner index portion, + and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. + More elaborate configurations are possible. + + The VACM access control mechanism described above provides control + over SNMP access to Script MIB objects. There are a number of other + access control issues that are outside of the scope of this MIB. For + example, access control on URLs, especially those that use the file + scheme, must be realized by the underlying operating system. A + mapping of the owner index value to a local operating system security + user identity should be used by an implementation of this MIB to + control access to operating system resources when resolving URLs or + executing scripts. + +11. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +12. Acknowledgments + + This document was produced by the IETF Distributed Management + (DISMAN) working group. + + + + +Levi & Schoenwaelder Standards Track [Page 49] + +RFC 2592 Script MIB May 1999 + + +13. References + + [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for + Describing SNMP Management Frameworks", RFC 2271, January 1998. + + [2] Rose, M. and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based Internets", STD 16, RFC + 1155, May 1990. + + [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, March 1991. + + [4] Rose, M., "A Convention for Defining Traps for use with the + SNMP", RFC 1215, March 1991. + + [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, + RFC 2579, April 1999. + + [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Conformance Statements for SMIv2", STD + 58, RFC 2580, April 1999. + + [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, May 1990. + + [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Introduction to Community-based SNMPv2", RFC 1901, January + 1996. + + [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport + Mappings for Version 2 of the Simple Network Management Protocol + (SNMPv2)", RFC 1906, January 1996. + + [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2272, January 1998. + + [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2274, January 1998. + + + + + + +Levi & Schoenwaelder Standards Track [Page 50] + +RFC 2592 Script MIB May 1999 + + + [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol + Operations for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1905, January 1996. + + [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC + 2273, January 1998. + + [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access + Control Model (VACM) for the Simple Network Management Protocol + (SNMP)", RFC 2275, January 1998. + + [16] Hovey, R. and S. Bradner, "The Organizations Involved in the + IETF Standards Process", BCP 11, RFC 2028, October 1996. + + [17] Berners-Lee, T., Fielding, R. and L. Masinter, " Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + + [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC + 959, October 1985. + + [19] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC + 2068, January 1997. + + [20] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + + + + +Levi & Schoenwaelder Standards Track [Page 51] + +RFC 2592 Script MIB May 1999 + + +14. Editors' Addresses + + David B. Levi + Nortel Networks + 4401 Great America Parkway + Santa Clara, CA 95052-8185 + U.S.A. + + Phone: +1 423 686 0432 + EMail: dlevi@nortelnetworks.com + + + Juergen Schoenwaelder + TU Braunschweig + Bueltenweg 74/75 + 38106 Braunschweig + Germany + + Phone: +49 531 391-3683 + EMail: schoenw@ibr.cs.tu-bs.de + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Levi & Schoenwaelder Standards Track [Page 52] + +RFC 2592 Script MIB May 1999 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Levi & Schoenwaelder Standards Track [Page 53] + |