Subject: Script MIB: questions about non-volatile scripts

From: Randy Presuhn <[email-masked]>
Date: Tue, 8 Dec 1998 16:57:36 -0600 (CST)

Hi -

I agree that there appears to be a contradiction between what
smScriptStorageType and smScriptSource say, and would like to avoid
the complex side-effects that the current definitions depend on.

Is this proposal a possible solution?

Randy Presuhn

> From [email-masked]  Fri Nov 20 09:05:21 1998
> Return-Path: <[email-masked]>
> Received: from tangelo.bmc.com ([172.17.7.166])
> 	by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA13632
> 	for <[email-masked]>; Fri, 20 Nov 1998 09:05:20 -0600 (CST)
> Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65])
> 	by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA21835;
> 	Fri, 20 Nov 1998 09:04:15 -0600 (CST)
> Received: from tangelo.bmc.com ([email-masked] [172.17.7.166])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04121
> 	for <[email-masked]>; Fri, 20 Nov 1998 07:04:09 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250])
> 	by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA21792
> 	for <[email-masked]>; Fri, 20 Nov 1998 09:04:03 -0600 (CST)
> Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5])
> 	by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id KAA03810;
> 	Fri, 20 Nov 1998 10:00:10 -0500 (EST)
> Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA04635 for <[email-masked]>; Fri, 20 Nov 1998 09:55:48 -0500 (EST)
> Received: from carabosse.oleane.net (carabosse.oleane.net [194.2.28.5])
> 	by guelah.nexen.com (8.8.8/8.8.8) with ESMTP id JAA11087
> 	for <[email-masked]>; Fri, 20 Nov 1998 09:55:37 -0500 (EST)
> Received: from gr.opengroup.org  (mailhost.opengroup.fr [62.160.165.1])  by carabosse.oleane.net  with ESMTP id PAA13266 for <[email-masked]>; Fri, 20 Nov 1998 15:55:23 +0100
> Received: from hal.gr.osf.org ([email-masked] [62.160.165.110])
> 	by gr.opengroup.org (8.8.6/8.8.6) with ESMTP id PAA17889
> 	for <[email-masked]>; Fri, 20 Nov 1998 15:55:04 +0100 (MET)
> Message-Id: <[email-masked]>
> X-Mailer: exmh version 2.0.2
> To: [email-masked]
> Subject: Script MIB: questions about non-volatile scripts
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Date: Fri, 20 Nov 1998 15:55:01 +0100
> From: Eamonn McManus <[email-masked]>
> 
> 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
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 1998 13:17:23 +0100

>>>>> Eamonn McManus writes:

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

It is about time to address your questions. But I first have a
procedural question to our AD. Randy, I need guidance!

I actually thought that we are not going to change anything in the ID
(other than typos or wording problems) at this point in time and that
we defer the resolution of Eamonn McManus questions until the spec is
approved as Proposed Standard and we start work on a revision. Your
email from Tue, 8 Dec 1998 indicates that you want to have a
resolution of the questions, but it is unclear whether you want them
to go into the next ID (probably risking another WG last call) or
whether you want to get the resolution into the next update after
approval as Proposed Standard. Please tell me what you expect me to
do.

Now back to the technical issues:

Eamonn> 1. When are non-volatile scripts loaded?

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

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

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

I think the problem here is the interpretation of phrases such as
"loading a script" or "reading a script from local non-volatile
storage". The intention is that the meta information associated with a
script (e.g. the attributes that appear in the smScriptTable) is
indeed restored at agent startup time. However, it is not necessary
(and in some cases even impossible) to load the script code into the
runtime system at agent startup time. Our implementation actually
loads the script code when a script is started since it sets up a
runtime environment which reflects the security profile associated
with the invoker of the script.

Your suggested answer is that non-volatile scripts are loaded only
when the agent starts. I think this does not work in some environments
and we need to better distinguish in the text between script meta
information and the script code itself. I actually think that we
should not over specify how and when the script code is loaded into a
runtime systems and give some degrees of freedom to the implementor
here.

Eamonn> 2. When are remote scripts downloaded?

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

The intention is what is written down in section 7.2 and 5.2. The text
in the smScriptSource description is mis-leading and needs to be fixed
(by actually removing the 4 state transitions and adding text to the
description of smScriptAdminStatus). This is basically what you
suggested with one exception: The intention is to actually reload a
script from a URL if the smScriptOperStatus changes from `enabled' to
`disabled' and back again, regardless whether smScriptSource has
changed or not. (This is really handy if you make changes to a script
and you want to reload it without having to destroy the row in the
smScriptTable.)

Eamonn> 3. When are non-volatile scripts saved?

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

You suggestion is as soon as the condition (smScriptStorageType ==
nonVolatile && smScriptOperStatus == enabled) becomes true. I agree
with this interpretation.

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

This might be useful. But I would really like to defer the addition of
another error state enumeration until we actually have a Proposed
Standard and more implementation experience.

Eamonn> 4. When are non-volatile scripts removed?

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

Your suggestion is:

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

I agree.

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

[snip]

Thanks for the suggested changes. They are very welcome, even though I
think that some of them need changes if we agree to the resolution of
the questions as described above. Before I start making edits, I would
first like to hear from our chair whether this should be done now or
whether this should be deferred so that we do not hold off the script
MIB from IESG last call.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)