Subject: Re: script mib issue # 20

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2001 08:59:09 +0100

>>>>> Juergen Quittek writes:

JQ> If you want to run a script in the background you want the launch
JQ> entry to expire immediately after you lauched the script, which is
JQ> hard to specify as a timer value. Here, the 'onetime' status would
JQ> be more desirable switching to 'expired' immediately after the
JQ> first launch.

Which can be done easily by setting the expire timer to zero when you
launch the script, as Eamonn already pointed out.

Sure, there is always in theory the problem that you create a launch
table row which is then used by someone else to launch a script before
you actually get to it. But this is due to the lack of a transactional
model in SNMP and I think we (a) should not try to solve it and (b) I
doubt that it is a real problem in practice, especially since we have
owner string indexing which allows you to define sandboxes via VACM so
that multiple managers can't step on each other.

/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 Quittek <[email-masked]>
Date: Thu, 01 Feb 2001 09:12:12 +0100

Éamonn McManus wrote:
> 
> Juergen Quittek wrote:
> > I like the idea of the 'expired' status, but I do not like a timer
> > as a solution for running scripts 'in the background'. If you want to
> > run a script in the background you want the launch entry to expire
> > immediately after you lauched the script, which is hard to specify
> > as a timer value. Here, the 'onetime' status would be more desirable
> > switching to 'expired' immediately after the first launch.
> 
> As I mention, this leaves the problem where the creator of the button
> dies (or loses contact) before pushing the button.  I do not think it is
> possible to create an smLaunchTable entry and launch it in a single SNMP
> request.

So would this be your solution?:
  - create the entry with a single SNMP request with an expiry time
    of some seconds
  - push the launch button
  - (optionally) set expiry time to zero

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2001 09:54:06 +0100

>>>>> Juergen Quittek writes:

JQ> So would this be your solution?: 

JQ> - create the entry with a single SNMP request with an expiry
JQ>   time of some seconds
JQ> - push the launch button
JQ> - (optionally) set expiry time to zero

I would do the following:

- create the entry like you create all other entries (e.g. by
  following the procedure in section 7.5 of RFC 2592) (plus
  setting the expiry time to some seconds in step 2)

- push the launch button and set the expiry time to zero

This means that the launch button goes away as soon as the script
expires from the run table. In addition, the launch button goes away
automatically if the manager dies between the two steps listed
above. Seems good to me.

/js

---

From: Éamonn McManus <[email-masked]>
Date: Thu, 01 Feb 2001 10:16:42 +0100

> automatically if the manager dies between the two steps listed

The only question I would have is whether it would not be possible to
create and push a oneshot button in a single SNMP request.  I.e., one
SET request containing:
- appropriate values for smLaunchOwner and smLaunchName in the OID;
- appropriate values for smLaunchScriptOwner, smLaunchScriptName,
smLaunchArgument, smLaunchLifeTime, smLaunchExpireTime;
- an explicit 0 for smLaunchStart to push the button;
- oneshot(4) for smLaunchAdminStatus;
- createAndGo for smLaunchRowStatus.

In this case there would be no need to add an smLaunchEntryLifeTime (or
whatever) attribute.  But it seems hard to do: the semantics for the
order in which the set fields are considered have to be just right
(tricky to specify and implement), and there is a risk of exceeding
packet size limitations.

Éamonn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2001 11:57:10 +0100

>>>>> =?iso-8859-1?Q?=C9amonn?= McManus writes:

Eamonn> The only question I would have is whether it would not be
Eamonn> possible to create and push a oneshot button in a single SNMP
Eamonn> request.  

[...]

Eamonn> In this case there would be no need to add an
Eamonn> smLaunchEntryLifeTime (or whatever) attribute.  But it seems
Eamonn> hard to do: the semantics for the order in which the set
Eamonn> fields are considered have to be just right (tricky to specify
Eamonn> and implement), and there is a risk of exceeding packet size
Eamonn> limitations.

I think the MIB definition allows you to actually launch a script in a
single SNMP set operation. But as you said, it won't work in general.
The procedures in RFC 2592 were written for the general case.

An implementor is welcome to shortcut the procedures - if he/she takes
the responsibility for doing so. It probably means to revert back to
the more complex procedure if the shortcut does not work for some
reason. (In SNMP theory, the agent should be able to handle such a
shortcut launch, but in reality, this does not work in most cases.)

/js