Subject: Script MIB: questions about non-volatile scripts

From: Eamonn McManus <[email-masked]>
Date: Fri, 20 Nov 1998 15:55:01 +0100

I'm just now starting to implement non-volatile storage of scripts in
my Script MIB implementation and I've run into some confusing areas in
the draft standard.

1. When are non-volatile scripts loaded?

   The draft standard implies in a couple of places that some specific
   action must be taken before a script will be loaded from
   non-volatile storage into the agent.  Section 5.2 includes in the
   list of operations controlled by smScriptTable objects "read
   scripts from local non-volatile storage".  The description of
   smScriptSource says that if the URL is empty the script source is
   loaded from local, non-volatile storage.

   But it also says in the description of smScriptEntry, "every script
   that is stored in non-volatile memory is required to appear in this
   script table", and in smScriptStorageType, "the agent has to make
   sure that scripts controlled by a row where smScriptStorageType is
   `nonVolatile' or permanent are loaded at agent startup time.

   If scripts are *already* loaded at agent startup time, what does it
   mean to set smScriptSource to load from local, non-volatile
   storage?  It seems to me that there should *not* be any way to
   ask for scripts to be loaded from non-volatile storage; it should
   just happen automatically when the agent starts.

2. When are remote scripts downloaded?

   There is contradictory information here.  The smScriptSource
   description implies that the download starts immediately this
   object is given a non-empty value.  But that makes no sense to me,
   because how can you tell whether the download has been successful?
   It also contradicts the example usage in section 7.2, "pulling a script
   from a URL", where the download only starts when smScriptAdminStatus
   is set to `enabled', and the download status is obtained by polling
   smScriptOperStatus; and it contradicts the smScriptGroup summary in
   section 5.2.

3. When are non-volatile scripts saved?

   smScriptSource says it happens when a non-empty source string is
   changed to an empty one.  smScriptStorage says it is when this
   object is set to `nonVolatile', and so do the examples in 7.1 and
   7.2, which additionally imply that the store only happens if the
   smScriptOperStatus is `enabled'.

   Incidentally it might be useful to add an smScriptOperStatus value
   that indicated that the attempt to save to non-volatile storage
   failed.  As it is, I'm forced to fall back on noResourcesLeft or
   genericError, which are unnecessarily vague.

4. When are non-volatile scripts removed?

   smScriptSource says it happens when an empty value changes to a
   non-empty value.  smScriptStorageType says it happens when the
   object is changed from nonVolatile to volatile.  smScriptRowStatus
   additionally says it happens when the row is deleted.

Here are my answers to the above questions.

1. When are non-volatile scripts loaded?

   When the agent starts.  Only.

2. When are remote scripts downloaded?

   When smScriptOperStatus is `disabled', smScriptSource is non-empty,
   and smScriptAdminStatus is set to `enabled'.  Scripts are not
   re-downloaded if the smScriptOperStatus changes from `enabled' to
   `disabled' and back again without changing smScriptSource.
   If smScriptSource is empty, setting smScriptAdminStatus to `enabled'
   results in an inconsistentValue error.  I don't implement the
   smCodeTable, but if I did then the agent would attempt to load the
   code from there when smScriptSource was empty.

3. When are non-volatile scripts saved?

   As soon as the condition
    (smScriptStorageType == nonVolatile && smScriptOperStatus == enabled)
   becomes true.

4. When are non-volatile scripts removed?

   When an smScriptEntry is destroyed, or when smScriptStorageType
   changes from nonVolatile to volatile.  Not when smScriptOperStatus
   becomes `disabled', though.

Here are the changes I would make to the draft if that were possible:

   Section 5.2: delete "read scripts from local non-volatile storage"
	 from the list of operations controlled by smScriptTable
	 operations.  Change the paragraph beginning "The source" to:

	 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. If this
	 object contains an empty URL, the script source
	 source is read from the smCodeTable (described below).

   smScriptSource: change the description to this:
           "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 1738. The allowed character sets and the
            encoding rules defined in RFC 1738 section 2.2 apply.

            When the smScriptAdminStatus object is set to `enabled',
	    the Script MIB implementation will `pull' the script
            source from the URL contained in this object if the URL
            is not empty.

            An empty URL indicates that the script source is loaded
            from the smCodeTable.

            Set requests to change this object are only valid if the
            value of smScriptOperStatus is `disabled'."

   In other words, this removes all the stuff about special behaviour
   when changing between empty and non-empty values.  THIS IS THE MOST
   IMPORTANT CHANGE.

   smScriptStorageType: change the second paragraph to this:
	    Setting this object to `nonVolatile' indicates that the script
	    controlled by this row is to be stored into non-volatile
	    storage: the script will be stored when this object is
	    `nonVolatile' and the smScriptOperStatus is `enabled'.
	    Setting this object to volatile removes a script from
	    non-volatile storage if the script has been in non-volatile
	    storage before. Attempts to set this object to permanent
	    will always fail with an inconsistentValue error.

I *think* that my implementation is a reasonable interpretation of the
draft as it stands, and it seems to be consistent with the
implementation running on osborne.ibr.cs.tu-bs.de, but it would be
nice to know that I am not completely on the wrong track.

,
Eamonn
--
The Open Group Research Institute, 2 ave de Vignate, 38610 Gieres, France.
Phone +33 476.63.48.82.  Fax +33 476.51.05.32.  http://www.gr.osf.org/~emcmanus