Subject: smLangTable indexing: why int?

From: Wes Hardaker <[email-masked]>
Date: 13 Apr 1999 10:24:57 -0700

So, I've finally gotten around to looking at the DISMAN-SCRIPT-MIB (a
bit late, I know)...

Why was the smLangTable indexed with an integer instead of, say, the
OID for the language in the first place?  This means that once an
entry is put into the table with a given index (say #2 = java) then
entry #2 can never be deleted and replaced with something different
(say perl) without a carefully checking to make sure the scripts in
the other tables don't point to the wrong language all of a sudden.
Using an index of the language OID would result in less problems like
this wouldn't it?

Just curious,
-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Apr 1999 10:12:55 +0200

>>>>> Wes Hardaker writes:

Wes> Why was the smLangTable indexed with an integer instead of, say,
Wes> the OID for the language in the first place?  This means that
Wes> once an entry is put into the table with a given index (say #2 =
Wes> java) then entry #2 can never be deleted and replaced with
Wes> something different (say perl) without a carefully checking to
Wes> make sure the scripts in the other tables don't point to the
Wes> wrong language all of a sudden.  Using an index of the language
Wes> OID would result in less problems like this wouldn't it?

Please note that the OID does not identify a language since there can
be multiple versions and revisions of a given language.  Therefore, we
need an artificial key to index the table (since we really do not want
to have a complex index here).

The Script MIB uses an Integer32 because of its history (early
versions of the MIB used integer indexes everywhere). If I were doing
it again, I would probably switch to names. Anyway, such a name would
be just a name and not e.g. a path to the binary or something like
that. How you locate the binary is IMHO a matter of a local
configuration.

The second issue you are talking about is the fact that scripts refer
to the language they are written in using the smScriptLanguage object.
You are correct that this relationship must be kept consistent when
you install a new language. Since the table is readonly, you can not
install new languages via SNMP set operations. In our implementation,
you can install new languages by editing the Script MIB configuration
file of the Script MIB and restarting the (sub)agent. Keeping the
references in sync in our configuration file is simple since we use
identifiers to refer to languages rather than numbers. (That is why I
would probably use names in the MIB as well if I were doing it again.)

Here is an excerpt from our Jasmin configuration file:

language ianaLangJavaVM1main
{
    binary                  "/usr/home/jasmin/bin/jvrun"
    smLangVersion           "1.1"
    smLangLanguage          1.3.6.1.3.9876.1
    smLangDescr             "The Java virtual machine language."
}

language ianaLangTcl80
{
    binary                  "/usr/home/jasmin/bin/smx-tclsh8.0"
    smLangVersion           "8.0"
    smLangLanguage          1.3.6.1.3.9876.2
    smLangDescr             "The Tool Command Language (Tcl)."
}
extension Tnm30
{
    language                ianaLangTcl80
    smExtsnVersion          "3.0.0"
    smExtsnExtension        1.3.6.1.4.1.1575.1.1
    smExtsnDescr            "SNMP extension for Tcl."
}

script never-ending
{
    language ianaLangJavaVM1main
    smScriptOwner           "utils"
    smScriptName            "NeverEnding"
    smScriptDescr           "has to be halted by manager or smLaunchLifeTime"
    smScriptSource          "http://www.ibr.cs.tu-bs.de/~jasmin/Endless.jar"
    smScriptAdminStatus     enabled
}

launch never-ending-junior
{
    script                  never-ending
    smLaunchOwner           "junior"
    smLaunchName            "never-ending"
    smLaunchAdminStatus     enabled
    smLaunchExpireTime      30000
    smLaunchLifeTime        6000
}

The smLangIndex and smExtsnIndex values are simply computed by the
agent after reading the configuration file. The downside here is that
the indexing will change if you install a new language and the manager
therefore needs to synchronize itself after such a change. (This is
where names instead of Integer32 indexes would give some benefits
since the change of such a name is less likely - but it still can and
will happen.)
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Apr 1999 18:06:05 +0200

>>>>> Wes Hardaker writes:

Wes> Yep, again, because you have to do something like that.  Wouldn't
Wes> it be just keen if the table would be constructed with an index
Wes> that you could use without having to synchronize everything
Wes> separately?  (For you, and probably me, it won't be a problem
Wes> because you've already done it and I'm about to...  But we could
Wes> save time for people in the future?)

As I said, I would probably do it different if I were to start from
scratch again. Whether we want to change the MIB needs to be discussed
once we open it up again. I have noted this issue in my open issues
list so that it will not get lost.

Wes> Bingo.  What happens if a manager is in mid stream of putting a
Wes> new mib on an agent.  It gets the smLangTable entry index for the
Wes> language it wants (which it must do by walking the smLangLanguage
Wes> column, rather than a single get to test for support) and before
Wes> it does its row creation, the agent on the far side reboots and
Wes> re-numbers everything, and the manager creates a script
Wes> associated with the wrong language (admittedly because the
Wes> manager was stupid enough not to notice that sysUpTime just went
Wes> down not up).

A name makes it less likely that you get wrong index numbers but it
does not protect you. Anyway, a manager not checking sysUpTime will
most likely experience a wrongLanguage later down the road.

							Juergen

---

From: Wes Hardaker <[email-masked]>
Date: 14 Apr 1999 08:50:05 -0700

>>>>> On Wed, 14 Apr 1999 10:12:55 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> The Script MIB uses an Integer32 because of its history (early
Juergen> versions of the MIB used integer indexes everywhere).

As many other early mibs have, my own included...  I've finally
learned better ;-)  (don't read that the wrong way, integer indexes are 
definitely valid many times).

Juergen> If I were doing it again, I would probably switch to
Juergen> names. Anyway, such a name would be just a name and not
Juergen> e.g. a path to the binary or something like that. How you
Juergen> locate the binary is IMHO a matter of a local configuration.

I wasn't suggesting a binary path name as the index.  In fact, all
semblances of path names probably don't belong in OS-independent mibs, 
as there is no way to design for all OS's path name styles...  I meant 
a name like "java" or some such.

Juergen> The second issue you are talking about is the fact that
Juergen> scripts refer to the language they are written in using the
Juergen> smScriptLanguage object.  You are correct that this
Juergen> relationship must be kept consistent when you install a new
Juergen> language.

Yep.  And sadly, this means that I have to use an independent scheme
for doing so and use a different internal index to make sure things
stay in synch.

Juergen> Keeping the references in sync in our configuration file is
Juergen> simple since we use identifiers to refer to languages rather
Juergen> than numbers.

So when someone creates a new script via a set, you immediately grab
the number from the smLangTable, and translate it into an oid and
store the association that way.  Understandable, as I was going to do
something similar.

My whole point (and its a small one thats been taken too broadly):
Wouldn't it be easier, since everyone will do something similar, just
to index it with the oid in the first place?

(Maybe this is too great a change for people at proposed, who knows)

Juergen> script never-ending
Juergen> {
Juergen> language ianaLangJavaVM1main

Whoops.  You do the association by name, sorry...  Either way, you're
associating it differently than the tables themselves do, because you
have to.  Thats what I'd love to fix.

Juergen> The smLangIndex and smExtsnIndex values are simply computed
Juergen> by the agent after reading the configuration file.

Yep, again, because you have to do something like that.  Wouldn't it
be just keen if the table would be constructed with an index that
you could use without having to synchronize everything separately?
(For you, and probably me, it won't be a problem because you've
already done it and I'm about to...  But we could save time for people 
in the future?)

Juergen> The downside here is that the indexing will change if you
Juergen> install a new language and the manager therefore needs to
Juergen> synchronize itself after such a change.

Bingo.  What happens if a manager is in mid stream of putting a new
mib on an agent.  It gets the smLangTable entry index for the language
it wants (which it must do by walking the smLangLanguage column,
rather than a single get to test for support) and before it does its
row creation, the agent on the far side reboots and re-numbers
everything, and the manager creates a script associated with the wrong 
language (admittedly because the manager was stupid enough not to
notice that sysUpTime just went down not up).

Anyway, its a nit in many books, but it'd sure be nice...

(on a side note, the smExtsnTable should change as well, of course,
even though its not used for an index anywhere.  It is, however, more
convenient to test for capability by a single get rather than a series
of getnexts).

---

From: Wes Hardaker <[email-masked]>
Date: 14 Apr 1999 11:25:34 -0700

>>>>> On Wed, 14 Apr 1999 18:06:05 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> As I said, I would probably do it different if I were to
Juergen> start from scratch again. Whether we want to change the MIB
Juergen> needs to be discussed once we open it up again. I have noted
Juergen> this issue in my open issues list so that it will not get
Juergen> lost.

Cool, thanks.

Juergen> A name makes it less likely that you get wrong index numbers
Juergen> but it does not protect you.

Yep.  A name or an oid would make me happy, I don't really care
which.  (I'd vote for a name too, for that matter).

Juergen> Anyway, a manager not checking sysUpTime will most likely
Juergen> experience a wrongLanguage later down the road.

Yep.  Though, if the manager initially checked sysUpTime at time 5
(seconds) and then thought for a while (15 seconds) and checked it
again and found the value to be 10, it would probably assume that
since the went up it was safe to assume its previous notion was still
valid...

But, thats being really really picky and you should ignore me.