I'm top-posting because I want to start a new thought, but allow reference
to what's below...
Yes, I think the light just went on... I've misunderstood
run-on-read/run-on-set.
Let's see if I have it correct now:
If the nsExtendRunType is run-on-read, then any snmpget of the output values
will run the command and return the results (or just return the cached
results without running the command)
If the nsExtendRunType is "run-on-set", then if I use snmpset to change
nsExtendArgs, the command is NOT run until also set nRunType to
run-command(3).
So, let;s say I have a command I want to run in either of two ways:
1 - with no arguments, the command returns some data
2 - with arguments, the command changes something, based on the arguments
Using snmp to get the results of my custom query, I should
snmpget nsExtendOutputFull."myname"
then to effect a change, I would
snmpset nsExtendArgs."myname" = "new args" nsExtendRunType = 3
then
snmpset nsExtendArgs."myname" = ""
That last one is to remove the args so a subsequent "get" will run the
command with no arguments again.
If that's the case, I think it will be better for me to have two extensions,
one to get and another to change.
So then the process becomes...
snmpget nsExtendOutputFull."mygetname""
snmpset nsExtendAgs."mysetname" = "new string args" nsRunType."mysetname" =
3
OK, that's cool.... is there a way to define a run-on-set item in the config
file?
I can "extend myname mycommand" but that creates a run-on-read, but how to
create a run-on-set instance?
GOT IT!
extend name command
extendfix name command
extendfix creates a "nameFix" entry with RunType run-on-set
OK, this is fantastic.... it was a longroad to get here, but now that I have
it figured out, it's realy quite simple. :-)
Thanks so much...
On Tue, Mar 22, 2011 at 08:59, Dave Shield <[email protected]>wrote:
> On 22 March 2011 15:38, Donald Russell <[email protected]> wrote:
> > Now, I want to
> > snmpset -v 2c -c rwcommunity host
> > NET-SNMP-EXTEND-MIB::nsExtendCommand.\"cmm\" s "some new value"
> >
> > and expect that "some new value" be passed to my /usr/local/bin/cmm
> program,
>
>
> That would be handled by
> snmpset .... nsExtendArgs.\"cmm\" s "some new value"
> or
> snmpset .... nsExtendArgs.\"cmm\" s "some new value"
> nsExtendRunType.\"cmm\" i 3
>
> depending on whether this is a run-on-read, or run-on-set entry.
>
>
> This would then trigger
> /usr/local/bin/cmm "some new value"
>
>
> Setting the nsExtendCommand value would *change* the command that's
> invoked.
> Something like
>
> snmpset ... nsExtendCommand.\"cmm\" s /usr/local/bin/cmm-v2
>
>
>
>
> > Yes, I could
> > snmpset ... nsExtendArgs.\"cmm\" s "some new value"
> > snmpget ... nsExtendOutputFull.\"cmm\"
>
> That's how things have been designed to work - yes.
>
>
> > I don't like this for the following reasons:
> > 1 - I end up using an snmpget command to effect a change
>
> I don't understand this objection.
> Even if the agent did invoke the script with the new arguments,
> you'd still need to query nsExtendOutputFull in order to see the results.
>
> What's the difference between
>
> snmpset ... nsExtendArgs.\"cmm\" s "some new value"
> snmpget ... nsExtendOutputFull.\"cmm\"
> and
> snmpset ... nsExtendCommand.\"cmm\" s "some new value"
> snmpget ... nsExtendOutputFull.\"cmm\"
>
>
>
>
> > 2 - multiple snmpgets will effect mulitple sets until I can change the
> args again.
>
> No.
> Multiple GETs will return the output of the command (either cached or
> re-run),
> yes. But you've only got one SET.
> And if you don't like this model - you can still use the
> 'run-on-set' approach.
> so the command will *only* be run if you invoke a suitable SET command.
> However many times you run the GET, you'll still get the cached output.
>
>
> I can't help feeling you're still confusing exec/extend with pass
> behaviour.
>
> The whole idea of "/some/script -s " to apply a SET assignment is
> *only*
> relevant to the "pass" directive. It's not applicable to exec/extend
> scripts.
>
>
> > 3 - with the nature of snmp and udp, what if the snmpset to change the
> args
> > fails for some reason
>
> Presumably your application will check the result of the SET, and
> won't proceed with the GET if it fails.
>
> > but the get is successful... the get uses the old args... not what I
> want.
>
> If you ignore the error message from the SET, then I don't have
> much sympathy :-)
>
>
>
> > From what I can determine, extend can't be used so that snmpset will pass
> > the new requested value to the arbitrary program.
>
> See above.
>
> 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
