Subject: Re: Script MIB implementation question

From: [email-masked]
Date: Mon, 29 Mar 1999 08:36:49 -0500 (EST)

Thanks for the response.  It's interesting and useful to hear about 
other implementors' experiences.

>We are currently working on scripts for "distributed service
>testing". The core idea is similar to the remote operations work.
>However, we focus on more complex services and test. For example, we
>have written a script which monitors the accessibility of documents on
>Web servers. The DISMAN-SCRIPT-MIB allows to run our test scripts from
>multiple distributed test points in the Internet. We currently use
>Java plus a Java package which provides access to the Script MIB
>implementation.

Sounds like a practical (and useful) application to me.

>Yes, the DISMAN-SCRIPT-MIB is currently silent about this. I agree
>that a standards mechanism for launching scripts at startup would be
>valuable. This is probably something to look at once we start work on
>a revision of the DISMAN-SCRIPT-MIB. (I personally have no problem to
>work out the details now so that we can implement any additions that
>may be needed fast without having to resort to private MIB extensions.)

If I can assist with this in any way, please let me know I'll be glad 
to do so.  For the moment, in my DISMAN-SCRIPT-MIB implementation, I'm 
adding a proprietary MIB extension to support auto-launch of scripts.
If anyone is interested, I'll gladly to provide more details.

>luchuk> 2) The DISMAN-SCRIPT-MIB has no way to let a script run
>luchuk> perpetually without automatic expiration;
>
>The model right now requires the `manager' to periodically reset
>smRunLifeTime if you want a script to run forever. The argument here
>was that a manager should take care and responsibilty for the scripts
>that are running (and thus consuming resources). It is sufficient to
>reset smRunLifeTime once per year if you pick large numbers. Sure, for
>a script which only monitors a MIB object and does rate calculations,
>you probably don't care about the resources. This is perhaps another
>issue where we want to work on.

I omitted alot of "thinking out loud" here, but my personal preference
would be a "special" value for smRunLifeTime that basically means "let
this script run forever" without cancellation.  After looking up the
syntax of the TimeInterval textual convention in RFC1902, I suggest
the possibility of setting smRunLifeTime to -1, or maybe it's maximum
acceptable value, to allow this.  But this suggestion may be a syman-
tically incorrect use of the TimeInterval textual convention -- I'll 
defer the issue to the more experienced.

>luchuk> 3) The DISMAN-SCRIPT-MIB cannot have anything but an octet
>luchuk> string stuffed into the smRunResult MIB object.
>
>This is on purpose. There was some discussion about this in the past.
>In particular, we discussed whether there should be a "discriminated"
>union table for script results. The conclusion of our discussion was
>that a script should export results in their own MIB. In other words,
>your script for rate calculations will instantiate MIB objects defined
>in a MIB module implemented by your script. This means that you ship
>the script together with the MIB module describing the results
>produced by running your script. This approach has the advantage that
>you can document the semantics of the MIB objects your script
>instantiates.

Hmmmmm.  Interesting thought.  Might be a pain to write scripts that
use this kind of facility though.  Each script would have to maintain
a list of MIB objects it supports, and somehow hand this list to the
agent.  Running multiple instantiations of a script would require that
the scripts coordinate their use of MIB object instances.  I'm going 
to have to think about this a bit more.

A couple of other questions about the DISMAN-SCRIPT-MIB:

1)  The DISMAN-SCRIPT-MIB appears to have no facility for returning
    diagnostic messages when script compiles fail.  That is, the
    DISMAN-SCRIPT-MIB _does_ provide the smScriptOperStatus that
    lets you know that a script compilation failed, but the MIB has
    no facility for determining _why_ the script failed.  This could
    be problematic.

2)  Has anyone attempted to implement the DISMAN-SCRIPT-MIB in a more
    resource-limited embedded system?  Something without lots of memory,
    disk storage, and system services like real-time clocks and complete
    protocol stacks?   As it's written, the DISMAN-SCRIPT-MIB script MIB 
    seems to be designed for resource-rich and feature-rich systems.

Thanks again for all your insights!

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 1999 13:20:15 +0200

>>>>> luchuk  writes:

luchuk> If I can assist with this in any way, please let me know I'll
luchuk> be glad to do so.  For the moment, in my DISMAN-SCRIPT-MIB
luchuk> implementation, I'm adding a proprietary MIB extension to
luchuk> support auto-launch of scripts.  If anyone is interested, I'll
luchuk> gladly to provide more details.

I see two ways to handle this. The first and obvious approach is to
add objects to the DISMAN-SCRIPT-MIB that control which scripts are
launched during startup.

The second and more general approach is to define another MIB module
which allows to bind arbitrary actions to events. This MIB module
would basically contain a table like this:

       bindEntry :: SEQUENCE {
           bindOwner		SnmpAdminString, -- INDEX
	   bindName		SnmpAdminString, -- INDEX
	   bindDescr		SnmpAdminString,
	   bindFilterName	SnmpAdminString,
	   bindContextName	SnmpAdminString,
	   bindVariable		VariablePointer,
	   bindValue		Integer32
	   bindAdminStatus	INTEGER,
	   bindOperStatus	INTEGER,
	   bindFailures		Counter32,
	   bindLastFailure	SnmpPduErrorStatus,
	   bindLastFailed	DateAndTime,
	   bindStorageType	StorageType,
	   bindRowStatus	RowStatus
       }

(Note, this is basically a variation of the scheduling MIB.)

Such a table can be used to turn scripts on and off on arbitrary
events. In your specific case, one would bind a set operation to write
a given launch button on a coldStart event. But this table allows to
do even more interesting things like e.g. binding a script to linkDown
events, or even starting scripts on a linkUp event and turning them
off on a linkDown event.

The question is whether we want a general (and thus more expensive)
solution or if we prefer a special purpose solution for the coldStart
event, which can be done a bit easier.

luchuk> I omitted alot of "thinking out loud" here, but my personal
luchuk> preference would be a "special" value for smRunLifeTime that
luchuk> basically means "let this script run forever" without
luchuk> cancellation.  After looking up the syntax of the TimeInterval
luchuk> textual convention in RFC1902, I suggest the possibility of
luchuk> setting smRunLifeTime to -1, or maybe it's maximum acceptable
luchuk> value, to allow this.  But this suggestion may be a syman-
luchuk> tically incorrect use of the TimeInterval textual convention
luchuk> -- I'll defer the issue to the more experienced.

We can not use -1 since it is outside the range of TimeInterval. But
giving the value 2147483647 a special meaning would be fine with me.

luchuk> Hmmmmm.  Interesting thought.  Might be a pain to write
luchuk> scripts that use this kind of facility though.  Each script
luchuk> would have to maintain a list of MIB objects it supports, and
luchuk> somehow hand this list to the agent.

I think this would also happen if we were adding a "discriminated
union" table to the script MIB. The running script still needs to tell
the SNMP agent which objects it wants to instantiate (unless we put
serious restrictions into place such as only one result object
instance per running script).

luchuk> Running multiple instantiations of a script would require that
luchuk> the scripts coordinate their use of MIB object instances.  I'm
luchuk> going to have to think about this a bit more.

I consider this to be an advantage. For example, your script does
calculations based on the ifTable. The natural way to represent the
results is by creating object instances indexed by ifIndex. This way,
the computed values really look like normal MIB objects extending the
ifTable. And you can document the semantics in a MIB module. This way,
the manager does not have to be aware whether the object is realized
by a script or if it is a `traditional' MIB object.

I think this is a much cleaner solution than having the manager to
look into some "discriminated union" tables where the result instances
are most likely indexed by the running script (where the instance
identifier may have different lifetime constraints than the
semantically meaningful instance identifer, ifIndex in the example).

luchuk> A couple of other questions about the DISMAN-SCRIPT-MIB:

luchuk> 1) The DISMAN-SCRIPT-MIB appears to have no facility for
luchuk> returning diagnostic messages when script compiles fail.  That
luchuk> is, the DISMAN-SCRIPT-MIB _does_ provide the
luchuk> smScriptOperStatus that lets you know that a script
luchuk> compilation failed, but the MIB has no facility for
luchuk> determining _why_ the script failed.  This could be
luchuk> problematic.

We may want to add another error message for this in a future revision
of the MIB or we may want to special define notifications, similar to
the stuff in the notification logging MIB. Our implementation has no
compilation step since we move Java byte codes around.

luchuk> 2) Has anyone attempted to implement the DISMAN-SCRIPT-MIB in
luchuk> a more resource-limited embedded system?  Something without
luchuk> lots of memory, disk storage, and system services like
luchuk> real-time clocks and complete protocol stacks?  As it's
luchuk> written, the DISMAN-SCRIPT-MIB script MIB seems to be designed
luchuk> for resource-rich and feature-rich systems.

I think the implementation done by Eamonn McManus is running in an
embedded environment. But I have not heard from him lately.

Sure, a full blown implementation may need some ressources. However,
it is possible to strip the resource usage down. In the extreme case,
you do not support dynamic installation of scripts at all and you use
the script MIB only to call pre-installed 'hard-wired' scripts.

My answer to the real-time clocks argument is written down in
draft-schoenw-snmpv2-mib-ext-00.txt.
							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)