Subject: Re: Report on Script MIB action item

From: Randy Presuhn <[email-masked]>
Date: Thu, 29 Mar 2001 10:03:56 -0800 (PST)

Hi -

> Date: Fri, 23 Mar 2001 17:31:58 +0100
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked], [email-masked]
> In-reply-to: <[email-masked]> (message from Andy Bierman on Fri,
> 	23 Mar 2001 08:05:48 -0800)
> Subject: Re: Report on Script MIB action item
> References: <[email-masked]> <[email-masked]> <[email-masked]>
...
> Andy> It is desirable to support unique integer task IDs across the
> Andy> agent. Yet smRunIndex is only unique within the scope of a
> Andy> particular smLaunchOwner, smLaunchName pair, which means the
> Andy> task ID is rather bulky (2 strings and an integer).  Some of the
> Andy> SEE tables need this global task ID, and their INDEX clauses
> Andy> will be rather large and complicated.
> 
> I agree that it would be nice to require that run index values are
> unique across all running scripts. I came across this myself when I
> was writing a management application.
> 
> I will put text in the MIB which says that smRunIndex values must be
> globally unique and spin another ID. If someone has an issue with
> making smRunIndex unique, please speak up now.
...

Writing as a technical contributor...

I think that requiring the task IDs to be unique across all
<smLaunchOwner, smLaunchName> pairs won't simplify things
THAT much.  Even if the task IDs are unique, in order to
keep the provisioning of access control tractable, one would
still need to include at least smLaunchOwner in the indexing
of the SEE tables.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Mar 2001 11:30:39 -0800

> still need to include at least smLaunchOwner in the indexing

The indexing structure of the seeEnvVarTable can't really support
another string. It doesn't really make sense to scope
the env vars by smLaunchOwner. The { task, group, agent }
scoping rules don't work if you add smLaunchOwner as the
first INDEX component. The max length of the env var names
will be reduced by adding this to the INDEX as well.

You are raising an important issue though, which is the
questionable practice of inserting INDEX components purely
for the benefit of access control (VACM configuration).
VACM can be configured with stable integer task IDs
just as well as with strings.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Mar 2001 16:26:46 +0200

>>>>> Randy Presuhn writes:

Randy> Writing as a technical contributor...

Randy> I think that requiring the task IDs to be unique across all
Randy> <smLaunchOwner, smLaunchName> pairs won't simplify things THAT
Randy> much.  Even if the task IDs are unique, in order to keep the
Randy> provisioning of access control tractable, one would still need
Randy> to include at least smLaunchOwner in the indexing of the SEE
Randy> tables.

Perhaps. But even without the SEE extension (which I do not consider
done yet), I think unique smRunIndex values simplify RFC 2592
management applications. In fact, in some cases, an application does
not want to expose the launch table machinery to the user at all. The
user just wants to know which "process" executes which script. Having
a unique smRunIndex means that you can expose a simple index at the
user interface which is also meaningful at the MIB interface. Right
now, I have to use a triple (launch owner, launch name, runindex)
which takes in the worst case about 70 characters to display and
nearly fills up a line on a 80 character display. Or I must do some
mappings in the application, which is however confusing if the user
also uses other tools to look at the MIB.

/js