Subject: Fwd: Re: Sched/Script MIB issues

From: Randy Presuhn <[email-masked]>
Date: Wed, 12 Jan 2000 11:57:09 -0800 (PST)

Hi -

Another forwarded post.

 ------------------------------------------------------------------------
 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 KAA00939
> 	for <[email-masked]>; Wed, 12 Jan 2000 10:26:43 -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 MAA16177
> 	for <[email-masked]>; Wed, 12 Jan 2000 12:27:07 -0600 (CST)
> Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) 
>           by smtprch1.nortel.com; Wed, 12 Jan 2000 12:26:44 -0600
> Received: from zsc4c012.corpwest.baynetworks.com ([134.177.2.159]) 
>           by zsc4c002.corpwest.baynetworks.com 
>           with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
>           id ZAR19R3Y; Wed, 12 Jan 2000 10:26:43 -0800
> Received: from dlevi-pc3.corpwest.baynetworks.com (DLEVI-PC3 [134.177.69.61]) 
>           by zsc4c012.corpwest.baynetworks.com 
>           with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
>           id CGZPRVR3; Wed, 12 Jan 2000 10:26:42 -0800
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: Windows Eudora Pro Version 3.0 (32)
> Date: Wed, 12 Jan 2000 10:22:14 -0800
> To: [email-masked]
> From: "David Levi" <[email-masked]>
> Subject: Re: Sched/Script MIB issues
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> 
> >Return-Path: <[email-masked]>
> >Date: Wed, 12 Jan 2000 15:54:25 +0100
> >From: Juergen Schoenwaelder <[email-masked]>
> >To: [email-masked]
> >Subject: Re: Sched/Script MIB issues
> >References: <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> >Sender: [email-masked]
> >List-Id: IETF disman Working Group mailing list <[email-masked]>
> >X-SMTP-HELO: tangelo.bmc.com
> >X-SMTP-MAIL-FROM: [email-masked]
> >X-SMTP-RCPT-TO: [email-masked]
> >X-SMTP-PEER-INFO: fw-us-hou-2.bmc.com [198.207.223.251]
> >
> >
> >
> >>>>>> 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.
> 
> A more general solution would be to add this BITs object to the
> schedTable in the schedule mib, so that you can perform a set
> at startup.
> 
> -Dave
> -----------------------------------------------------------------------------
> David B. Levi             Nortel Networks         [email-masked]
> Voice: +1 865 686 0432    Fax: +1 865 686 0433    Voice Mail: +1 408 495 3622
> -----------------------------------------------------------------------------
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jan 2000 16:03:36 +0100

>>>>> David Levi writes:

Dave> A more general solution would be to add this BITs object to the
Dave> schedTable in the schedule mib, so that you can perform a set at
Dave> startup.

What are the pros and cons?

+ You can set an arbitrary INTEGER objects when the agent (re)starts,
  which is definately more than just being able to fire up scripts.

- Right now, the DISMAN-SCHEDULE-MIB does periodic and calendar
  schedules. Putting the auto start flag into this MIBs means that it
  now does periodic schedules, calendar schedules and "special event"
  schedules, which probably goes beyond what it was designed to do.

- A pure script MIB implementation now needs to implement at least a
  degenerated version of the DISMAN-SCHEDULE-MIB in order to auto
  start scripts. This is much more work and code compared to just
  checking a bit and kicking the script when you read the
  configuration.

- Configuration of auto start scripts now requires to keep pointers
  from the DISMAN-SCHEDULE-MIB to the scripts and you have to look at
  two tables in order to figure out if a script will be restarted.

Given the fact that the auto start feature is very cheap to implement
in the smLaunchTable and that I do not really mind if we also have
another more generalized way of doing the same thing, I would prefer
to put the auto start bit in the smLaunchTable and to keep the
DISMAN-SCHEDULE-MIB for schedules only.

The other option I see is to define a MIB which triggers sets based on
notification OIDs. Such a MIB will be very similar to the scheduling
MIB - only the event source mechanism would be different. The only
problem with this approach is that it is hard to pass event details
around through a MIB. Doing this will lead to complex tables whose
value is questionable. So I would propose that passing the event
details around is something that is outside the scope of the MIB and
depends on what got set (a script may get access to the event details
through scripting language features).

I am willing to write such a MIB if there is interest. But independent
of this, I think we should add the auto start bit to the smLaunchTable.

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