Subject: Re: Script MIB: questions about non-volatile scripts

From: Randy Presuhn <[email-masked]>
Date: Thu, 21 Jan 1999 23:42:45 -0800 (PST)

Hi - 

(Apologies for the delay.)

> Date: Fri, 18 Dec 1998 13:17:23 +0100
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked], [email-masked]
> CC: [email-masked]
> Subject: Re: Script MIB: questions about non-volatile scripts
> References:  <[email-masked]>
> 
> 
> >>>>> 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.

The issues you discuss below still fall within the domain of what
could rightly be called clarifications.  I agree that things could
be clearer, but I share your desire to avoid over-specification.

> 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.

I suspect this is a common situation.

> 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.

100% Agreed.

> 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.)

This change clearly should be made.

> 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.

ok, let's see how these work out in practice.

> 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.
...

Make the clarifications.  We do not need another WG last call.
When the draft is submitted, we'll point the AD's at it and proceed.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------