Subject: Re: Sched/Script MIB issues

From: Alan Luchuk <[email-masked]>
Date: Wed, 5 Jan 2000 10:47:01 -0500 (EST)

Hello all,

Thanks for the clarifications.

(Text deleted to shorten this E-mail.)

>Alan> Issue Script-02:
>>> o Restartable scripts
>
>Scripts that are automatically launched when an agent starts up (or
>some other event happens).

I believe Eamonn has a simple and elegant solution for launching 
scripts when the DISMAN-SCRIPT-MIB agent starts.  If the smLaunchName
begins with an asterisk, the corresponding launch 'button' is pressed 
automatically when the agent starts.  I have added this to SNMP 
Research's DISMAN-SCRIPT-MIB implementation.

>Alan> Issue Script-03:
>>> o Error message during script retrieval or compilation
>>> (smScriptError)
>
>So you argue in favour of adding such an object. Do you have a
>concrete proposal for the definition of such an object?

I suggest adding a single octet string MIB object to the
smScriptTable that can return compile-time error messages.
This would provide a single-line error message that would
describe the first compile-time error that occurred.  

Other solutions are possible, like a _table_ of octet strings
that would describe all compile-time errors that occurred.

SNMP Research's DISMAN-SCRIPT-MIB implementation would work 
just fine with a single-line error message, but I can see
the value of an error message table.

Based upon the preferences of the DISMAN WG for one or the
other of these solutions, I'll be glad to write up first-cut
additions to the DISMAN-SCRIPT-MIB.

>Alan> Issue Script-04:
>>> o Scripts that can run forever without having to reset
>>> smRunLifeTime
>
>Alan> Eamonn solved this very simply and elegantly in his
>Alan> implementation.  I forget the exact details, but conceptually it
>Alan> works like this: If smRunLifeTime is set to its maximum allowed
>Alan> value (2147483647), the smRunLifeTime is never decremented.  We
>Alan> have added Eamonn's solution to our implementation of the
>Alan> DISMAN-SCRIPT-MIB.
>
>So you and Eamonn are happy with this solution. I have no problem with
>it. So the strawman position is to add text to the description of
>smLaunchLifeTime and smRunLifeTime to give 2147483647 a special
>meaning.

Works for me.

>Alan> Issue Script-07:
>>> o Storage type of script code versus storage type of script meta
>>> information
>
>Alan> What does this mean?  (A cut-and-paste from archived discussion
>Alan> of this topic would be fine.)
>
>There has been ongoing confusion about the precise meaning of the
>smScriptStorageType object. It affects the meta information of a
>script (everything which is in a smScriptTable row) and the storage
>of the script itself.

Yes, I believe I discovered this during implementation.  I solved
the problem by shadowing the smScriptStorageType in each row of
the smCodeTable.

>Issue Schedule-02:
>
>Can the SNMP manager modify CalendarGroup Objects and schedInterval
>object when the schedRowStatus is in 'active' state?

SNMP Research's implementation lets you change the schedInterval
while the schedRowStatus is 'active', and the row's schedAdmin-
Status is 'enabled'.   If the user resets the schedInterval, when
the set occurs, the existing interval is cancelled and the new 
interval takes effect.   Note that I did not re-check RFC 2591 to 
determine how this is _supposed_ to work.

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

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jan 2000 12:14:26 +0100

>>>>> Alan Luchuk writes:

Alan> Issue Script-02:
>>>> o Restartable scripts
>>  Scripts that are automatically launched when an agent starts up
>> (or some other event happens).

Alan> I believe Eamonn has a simple and elegant solution for launching
Alan> scripts when the DISMAN-SCRIPT-MIB agent starts.  If the
Alan> smLaunchName begins with an asterisk, the corresponding launch
Alan> 'button' is pressed automatically when the agent starts.  I have
Alan> added this to SNMP Research's DISMAN-SCRIPT-MIB implementation.

Not sure I really like this solution. I understand that it is easy to
implement. A cleaner solution would IMHO be to have the autostart bit
encoded somewhere else. One could for example define a BITS object
which has a bit set if the launch butten should be pressed by a
restart event. A BITS object also allows to add additional flags over
time without playing even more games with the name. The other ultimate
solution is to define a mechanism which allows to launch scripts (or
better perform sets on INTEGER valued objects) when a notification is
generated or received. But this gets hairy when it comes down to
passing notification details to the script or whatever got invoked.

So I currently tend to prefer an object which indicated autostart
behaviour and to leave a more general mechanism for future work (which
would be a nice small MIB module independent from the schedule MIB
itself).

>> concrete proposal for the definition of such an object?

Alan> I suggest adding a single octet string MIB object to the
Alan> smScriptTable that can return compile-time error messages.  This
Alan> would provide a single-line error message that would describe
Alan> the first compile-time error that occurred.

Alan> Other solutions are possible, like a _table_ of octet strings
Alan> that would describe all compile-time errors that occurred.

Alan> SNMP Research's DISMAN-SCRIPT-MIB implementation would work just
Alan> fine with a single-line error message, but I can see the value
Alan> of an error message table.

Alan> Based upon the preferences of the DISMAN WG for one or the other
Alan> of these solutions, I'll be glad to write up first-cut additions
Alan> to the DISMAN-SCRIPT-MIB.

I would prefer a single object to keep things small. I think it should
be an SnmpAdminString or do we really care about binary data?

>> object when the schedRowStatus is in 'active' state?

Alan> SNMP Research's implementation lets you change the schedInterval
Alan> while the schedRowStatus is 'active', and the row's schedAdmin-
Alan> Status is 'enabled'.  If the user resets the schedInterval, when
Alan> the set occurs, the existing interval is cancelled and the new
Alan> interval takes effect.  Note that I did not re-check RFC 2591 to
Alan> determine how this is _supposed_ to work.

I think this is a reasonable interpretation. Strawman: Add a note
which clarifies that sets on schedInterval and friends are legal if
the schedRowStatus is 'active' and the row's schedAdminStatus and
schedOperStatus is 'enabled'.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Jan 2000 15:54:25 +0100

>>>>> Eamonn McManus writes:

Eamonn> I quite agree with Juergen about this.  In the project I
Eamonn> implemented the Script MIB for, I wanted to be able to say
Eamonn> that the implementation conformed to a (future) standard, and
Eamonn> in particular I set myself the constraint that I would add no
Eamonn> new SNMP objects.  Without this constraint, I agree that
Eamonn> overloading the name to hold the auto-start flag is hacky.

>> The other ultimate solution is to define a mechanism which allows
>> to launch scripts (or better perform sets on INTEGER valued
>> objects) when a notification is generated or received. But this
>> gets hairy when it comes down to passing notification details to
>> the script or whatever got invoked.

Eamonn> In principle this is indeed a nicer solution, but if made
Eamonn> appropriately general it is in danger of being very
Eamonn> complicated, and in particular perhaps too complicated for
Eamonn> embedded systems.

Thanks for your feedback. So here is a strawman proposal:

We add a new object to the smLaunchTable which controls whether the
associated script is restarted during reboot. We make this new object
a BITS object so that it is possible to add additional start
conditions in the future (if we ever need to do this) and we leave a
more general solution for this problem for future work.

Let me know if there are any concerns or objections.

/js