Subject: Re: Sched/Script MIB issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Jan 2000 17:10:39 +0100

>>>>> Alan Luchuk writes:

Alan> Issue Schedule-01:
>> o Sets on arbitrary objects triggered by the scheduler

Alan> Further explanation, please.  Does this mean that the scheduler
Alan> will be able to set:

Alan>      A.  MIB objects of type other than Integer32; and/or B.
Alan> Several MIB objects with a single trigger;

Alan> at the trigger time?

Yes, I think this is the issue on the table. The question here is
whether we can borrow infrastructure from the event MIB or whether we
redo some of the work. (This is why I was arguing that we (as a WG)
should have done a better job to align things.)

Alan> Issue Script-02:
>> o Restartable scripts

Alan> What does this mean?  (A cut-and-paste from archived discussion
Alan> of this topic would be fine.)

Scripts that are automatically launched when an agent starts up (or
some other event happens).

Alan> Issue Script-03:
>> o Error message during script retrieval or compilation
>> (smScriptError)

Alan> We have solved this problem by adding such an object to a
Alan> proprietary MIB that extends the DISMAN-SCRIPT-MIB.  But this
Alan> kind of object is something that many implementations probably
Alan> have use for, so extending the DISMAN-SCRIPT-MIB makes sense.

So you argue in favour of adding such an object. Do you have a
concrete proposal for the definition of such an object?

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.

Alan> Issue Script-05:
>> o Index smLangTable and smExtsnTable by name rather than Integer32

Alan> No opinion on this one.  I can align with whatever the DISMAN WG
Alan> decides.

Alan> Issue Script-06:
>> o Dependencies between scripts and script versioning (Eamonn)

There is a bit more about this in Eamonn's Simple Times article.

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.

Alan> Also, as time allows, I'll re-read RFC 2592 and make additional
Alan> notes and comments about issues I recall.  I've slept since I
Alan> last read RFC 2592, so I can't remember the issues without
Alan> looking at the RFC :-)

That would be great.

I also just received another question regarding RFC 2591:

Issue Schedule-02:

Can the SNMP manager modify CalendarGroup Objects and schedInterval
object when the schedRowStatus is in 'active' state?

/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: Alan Luchuk <[email-masked]>
Date: Thu, 6 Jan 2000 11:37:36 -0500 (EST)

Hello,

Juergen>Why do you want to restrict this object to compilation errors? Would
Juergen>it not make more sense to have something like the following:
Juergen>
Juergen>smScriptErrorMessage OBJECT-TYPE
Juergen>    SYNTAX	SnmpAdminString
Juergen>    MAX-ACCESS	read-only
Juergen>    STATUS	current
Juergen>    DESCRIPTION
Juergen>	"This object contains a descriptive error message whenever
Juergen>	 the corresponding smScriptOperStatus variable indicates
Juergen>	 a non-transient error state.
Juergen>
Juergen>	 This object must be cleared whenever the value of
Juergen>	 smScriptOperStatus changes to one of the values `enabled',
Juergen>	 `disabled', `editing', `retrieving', or `compiling'."
Juergen>    ::= { smScriptEntry 10 }
Juergen>
Juergen>This way, the object can also hold a descriptive error message in
Juergen>cases such as a failed download (e.g. protocolFailure).

I did not think of this generalized message.  I agree that your idea 
(a more general-purpose descriptive message) is superior. 

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: Randy Presuhn <[email-masked]>
Date: Wed, 12 Jan 2000 09:43:03 -0800 (PST)

Hi -

Relevant non-subscriber post to the disman list.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

> 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 GAA29235
> 	for <[email-masked]>; Wed, 12 Jan 2000 06:23:31 -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_17135)/8.8.6) with SMTP id IAA21601
> 	for <[email-masked]>; Wed, 12 Jan 2000 08:23:55 -0600 (CST)
> Received: from France.Sun.COM ([129.157.188.1])
> 	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA08568;
> 	Wed, 12 Jan 2000 06:23:48 -0800 (PST)
> Received: from bebop.France.Sun.COM by France.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205)
> 	id PAA19962; Wed, 12 Jan 2000 15:23:46 +0100
> Received: from noname.France.Sun.COM by bebop.France.Sun.COM (8.8.8+Sun/SMI-SVR4) id PAA15569 
>         for ; Wed, 12 Jan 2000 15:23:43 +0100 (MET)
> Received: from france.sun.com (localhost [127.0.0.1])
> 	by noname.France.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA01001;
> 	Wed, 12 Jan 2000 15:23:20 +0100 (MET)
> Sender: [email-masked]
> Message-ID: <[email-masked]>
> Date: Wed, 12 Jan 2000 15:23:20 +0100
> From: Eamonn McManus <[email-masked]>
> Organization: Sun Microsystems, France
> X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
> X-Accept-Language: ga, fr, en
> MIME-Version: 1.0
> To: Juergen Schoenwaelder <[email-masked]>
> CC: [email-masked], [email-masked]
> Subject: Re: Sched/Script MIB issues
> References: <[email-masked]> <[email-masked]>
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id GAA29236
> 
> Juergen Schoenwaelder wrote:
> > >>>>> 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.
> 
> I quite agree with Juergen about this.  In the project I implemented the Script
> MIB for, I wanted to be able to say that the implementation conformed to a
> (future) standard, and in particular I set myself the constraint that I would
> add no new SNMP objects.  Without this constraint, I agree that 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.
> 
> In principle this is indeed a nicer solution, but if made appropriately general
> it is in danger of being very complicated, and in particular perhaps too
> complicated for embedded systems.
> 
> Éamonn
>