Subject: Re: Script MIB implementation question

From: Eamonn McManus <[email-masked]>
Date: Tue, 18 May 1999 13:04:25 +0200

I was suspended from the DISMAN mailing list two months ago, apparently
due to transient mailer problems, and have only just realised it, thanks
to an automatic reminder from the list manager.  Hence my rather late
reply to Alan Luchuk's message of the 26th of March and the brief
discussion that followed.

Alan Luchuk <[email-masked]> writes:
> Have any of you with DISMAN-SCRIPT-MIB implementations attempted to
> do practical network management tasks with it?  What sort of things
> have you done, and how did you achieve it?   What languages did you
> use and what extensions did you have to have (or provide) to make
> your application work?

I implemented the Script MIB on a smallish embedded device with a Java
Virtual Machine.  My implementation only supports scripts in Java.
I'll describe a couple of the extensions below.

> 1)  The DISMAN-SCRIPT-MIB has no facility for automatically
>     launching scripts at agent start-up;

Extension number 1, very straightforward: if the name of a launch
button starts with "*", then it is triggered on startup.  This doesn't
require any change to the MIB, just a little extra interpretation.  It
also fits in easily with the graphical script administration tool we
created.

> 2)  The DISMAN-SCRIPT-MIB has no way to let a script run perpetually
>     without automatic expiration;

Extension number 2, also very straightforward, and suggested elsewhere
in the discussion: if a duration is specified as 4294967295 (the maximum
value of a TimeTicks variable, not 2147483647 as suggested here) then
instead of being interpreted as 497 days it is interpreted as infinite.
It is not the Script MIB's business to guess whether the script will
need or even be able to get further attention from the manager after
its launch or not, so the argument that "a manager should take care
and responsibility for the scripts that are running (and thus consuming
resources)" is unconvincing.

Again this extension doesn't require any changes to the MIB.

> 3)  The DISMAN-SCRIPT-MIB cannot have anything but an octet string
>     stuffed into the smRunResult MIB object.

I haven't found this to be a problem.  If you want more detailed
information from the script you can get it by communicating with the
script while it is still running, using SNMP or some other
protocol.

Alan Luchuk <[email-masked]> writes in a later message:
> 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.

I agree that this is an annoying drawback in the existing MIB.
There should be an smScriptError variable, like the existing smRunError
variable, that provides a text string explaining what went wrong, in
addition to the smScriptOperStatus currently available.  This would apply
not just to compilation, but to other problems such as network failures
or an invalid code signature.  Our script administration tool has to
guess what the problem is based on a very general error code, when with
this extra information it could provide a meaningful and precise message.

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

Juergen Schoenwaelder <[email-masked]> replied:
> I think the implementation done by Eamonn McManus is running in an
> embedded environment. But I have not heard from him lately.

Now you know why :-).  Our implementation is indeed on a fairly small
device, and notably there is no disk storage (just flash memory) and no
real-time clock (so we have to lie about start and end times of script
runs).  It would be possible to add a real-time clock by downloading a
script to do NTP, or the solution mentioned by Juergen of sending the
time to the device through SNMP is also possible.  We haven't in fact
done either of those things.

We do have a complete protocol stack, though I don't really see why the
availability of anything beyond SNMP over UDP is relevant.

,
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: Eamonn McManus <[email-masked]>
Date: Thu, 20 May 1999 10:08:58 +0200

Juergen Schoenwaelder <[email-masked]> writes:
> >>>>> Randy Presuhn writes:
> Randy> Would anyone also be willing to also allow noauth/nopriv or
> Randy> "public" read-only access to their implementation?
> Our implementation is accessible via the Internet. You can find the
> details at <URL:http://www.ibr.cs.tu-bs.de/projects/jasmin/>. Please
> drop us a note if the agent does not respond and we will see what has
> happened.

I used Juergen's site during the development of my implementation, so
the two are compatible at least insofar as our client software works
with both.  I don't think it would be possible for me to give out our
implementation or make it accessible, but I would be willing to try other
client software against it if anyone wants to send me theirs (source or
binary for any of a fairly wide variety of machines we have here).

Although the tu-bs implementation and ours both support Java programs
as scripts, the same script cannot run on both because we use
different conventions for startup.  The Java VM we're using doesn't
support reflection so we couldn't have execution start at a static
method.

,
Eamonn

---

From: Eamonn McManus <[email-masked]>
Date: Fri, 21 May 1999 15:25:51 +0200

> > To: [email-masked]
> > Subject: Re: Script MIB implementation question 
> > Date: Thu, 20 May 1999 10:08:58 +0200
> > From: Eamonn McManus <[email-masked]>
> ...
> ...
> Does this mean that, for purposes of this MIB, that these would have
> to be considered different scripting languages?  If not, how would
> a management system be able to know what's going on?

Actually, what I said is not strictly true.  It would be easy to write a
Java program that respected both startup conventions and would therefore
run on both systems.  But our scripts are specific to the device in
question, so we are not particularly interested in interoperability with
scripts written for other devices.

The main advantages for us of the Script MIB as opposed to a proprietary
MIB were, first, that we didn't have to do the work of designing the
MIB, and second, that any client tool for the Script MIB can be used to
download our scripts to the device.  In other words, we were interested
in protocol interoperability but not script interoperability.

Certainly some Java programs using only standard Java interfaces could
usefully be run on our device, but we don't see that as a goal.

,
Eamonn