On 21 March 2011 19:33, Donald Russell <[email protected]> wrote:
>> [exec/extend and pass] are two very different approaches to extending the 
>> agent.
>> Don't try and equate the two.
>
>
> I see them as evolutionary....
> Seems we first had "exec" which allowed snmpget, but the order of things
> would change if new ones were added or old ones removed.
> Along comes extend... now the OID is indexed by a name instead of simply
> enumerated from the config file

That's essentially correct, yes.
I wrote "extend" a few years ago,  based on our experiences with
the limitations of "exec".    One of which was indeed the way that
the indexing depended on the order of entries in the config file.


> Then comes "pass"... here's an OID.... handle it.

The timing here is rather different.
"exec" and "pass" both date back to the beginning of the UCD project.
The earliest version that I can find (v3.1.1 - from 1996) includes both
of them.   You'd have to ask Wes as to which came first - and I'm
not sure that he'd remember!




> I wonder why the authors didn't think it would be worthwhile for the
> extend feature to accept the value specified on snmpset.

But the value specified on 'snmpset' will always be 3
What use would it be to pass this to the script?

If you want to pass request-specific information to the script
when it's invoked, you can always issue a SET request that
assigns new values to the nsExtendArgs and/or nsExtendInput
instances,  as well as the nsExtendRunType trigger.

Surely that's more flexible than passing a fixed value to the script?

Dave

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to