Discussion:
how to use "extend" and run-on-set?
Donald Russell
2011-03-18 23:52:13 UTC
Permalink
I have net-snmp 5.3 on Linux and I've been able to use the "exec" and
"extend" config statements with great success.

"pass" on the other hand is driving me crazy... I can't get snmpwalk to walk
the OID I specify at all...

But, back to "extend"... I'd like to have an OID that I may both query and
set, and when I look at NET-SNMP-EXTEND-MIB it appears I can have a
"run-on-set" (2) value for nsExtendRunType...

How do I configure an extend config statement to support both snmpget and
snmpset?

Or, the man page says "extend" items can be added dynamically.... that would
be great... I can have a system start up script dynamically add the
run-on-get and the run-on-set scripts. (Actually the same script, args would
determine action taken)

When the script is run due to run-on-set, is the new value simply passed as
the args or is it more structured than that? Similar to "pass" which passes
-s OID TYPE VALUE

Thanks
Dave Shield
2011-03-21 09:40:46 UTC
Permalink
Post by Donald Russell
I have net-snmp 5.3 on Linux and I've been able to use the "exec" and
"extend" config statements with great success.
"pass" on the other hand is driving me crazy... I can't get snmpwalk to walk
the OID I specify at all...
What does your pass script look like?
Remember that "exec" and "extend" scripts are SNMP-ignorant.
You can run arbitrary commands here, and the agent will report
back the output - applying a suitable MIB framework to structure this.

"pass", on the other hand, can be used to report back information
in a user-defined structure. The price for this is that it does needs
to know about SNMP processing, and there is a very clearly defined
way of both invoking the command, and how it should return the results.
You can't simply use an arbitrary command with "pass", in the way that
you can with "exec" or "extend".
Post by Donald Russell
But, back to "extend"... I'd like to have an OID that I may both query and
set, and when I look at NET-SNMP-EXTEND-MIB it appears I can have a
"run-on-set" (2) value for nsExtendRunType...
How do I configure an extend config statement to support both snmpget and
snmpset?
Try using "extendFix" instead of "extend"
Post by Donald Russell
Or, the man page says "extend" items can be added dynamically.... that would
be great... I can have a system start up script dynamically add the
run-on-get and the run-on-set scripts. (Actually the same script, args would
determine action taken)
That would use SET requests to build up the entry in the nsExtendConfigTable.
Try configuring a row using "extend", and walk this table to see what the
entry looks like. Then use "snmpset" with equivalent varbinds (and an
nsExtendStatus value of 'createAndGo')
Post by Donald Russell
When the script is run due to run-on-set, is the new value simply passed as
the args or is it more structured than that?
It's actually simpler than that.
When the nsExtendRunType instance is set to 'run-command(3)',
then the corresponding nsExtendCommand is invoked (using the
arguments from nsExtendArgs and input from nsExtendInput).

The "new value" for nsExtendRunType is never actually used
(other than as a trigger for invoking the command). If you read
the nsExtendRunType instance again, it will still have the value
'run-on-set(2)'
Post by Donald Russell
Similar to "pass" which passes -s OID TYPE VALUE
No
"pass" is SNMP-knowledgable (and runs a closely defined command)
"extend" is SNMP-ignorant (and can run an arbitrary command)

These are two very different approaches to extending the agent.
Don't try and equate the two.

Dave
Donald Russell
2011-03-21 19:33:04 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
I have net-snmp 5.3 on Linux and I've been able to use the "exec" and
"extend" config statements with great success.
"pass" on the other hand is driving me crazy... I can't get snmpwalk to
walk
Post by Donald Russell
the OID I specify at all...
What does your pass script look like?
First, my snmpd.local.conf file has:
pass .1.3.6.1.4.1.15966.1 /usr/local/bin/passtest

The passtest script is:
#!/bin/sh -f

PATH=$path:/bin:/usr/bin:/usr/ucb

PLACE=".1.3.6.1.4.1.15966.1"
REQ="$2"

echo "--- $(date) ---" >> /tmp/passtest.log
echo $* >> /tmp/passtest.log

case "$1" in
-s)
# snmpset
if [[ "$REQ" != "$PLACE.1" ]]; then
echo "not-writable"
else
TYPE=$3
shift 3
VALUE="$*"
RESULT=$(/usr/local/bin/cmm $VALUE)

echo "Set OID $REQ result: $RESULT" >> /tmp/passtest.log
fi
exit 0
;;

-n)
# getnext... REQ is the requested OID, return the next OID, or exit
if none.
case "$REQ" in
$PLACE) RET=$PLACE.1 ;;
$PLACE.0) RET=$PLACE.1 ;;
$PLACE.1) RET=$PLACE.2 ;;
*) exit 0 ;;
esac
;;

-g)
# get .. return the OID, type and value
case "$REQ" in
$PLACE) RET=$PLACE.1 ;;
*) RET=$REQ ;;

esac
;;
esac

# NOTE: snmpset already exited (above)
# Reply to get/getnext with three lines: OID, type, value
case "$RET" in
$PLACE.1) type="integer"; value="42" ;;
$PLACE.2) type="string"; value="life the universe and everything" ;;
*) type="string"; value="ack... $RET $REQ" ;;
esac

echo -e "\tRET=$RET; TYPE=$type; VALUE=$value" >> /tmp/passtest.log
echo "$RET"
echo $type
echo $value
exit 0

I have an alias for snmp* commands to include the -v -c and hostname parts -
I use localhost for testing

#snmpget .1.3.6.1.4.1.15966.1.1
SNMPv2-SMI::enterprises.15966.1.1 = No Such Instance currently exists at
this OID

Yet in my /tmp.passtest.log file I see
-g .1.3.6.1.4.1.15966.1.1
RET=.1.3.6.1.4.1.15966.1.1; TYPE=integer; VALUE=42
So the script was invoked

#snmpwalk .1.3.6.1.4.1.15966.1
SNMPv2-SMI::enterprises.15966.1 = No Such Instance currently exists at this
OID


I think I'm missing something very basic. :-(
Post by Dave Shield
Remember that "exec" and "extend" scripts are SNMP-ignorant.
You can run arbitrary commands here, and the agent will report
back the output - applying a suitable MIB framework to structure this.
Yes, I use "extend" to get some read-only data, works great, and couldn't be
simpler to get working with snmp.
Post by Dave Shield
"pass", on the other hand, can be used to report back information
in a user-defined structure. The price for this is that it does needs
to know about SNMP processing, and there is a very clearly defined
way of both invoking the command, and how it should return the results.
You can't simply use an arbitrary command with "pass", in the way that
you can with "exec" or "extend".
Post by Donald Russell
But, back to "extend"... I'd like to have an OID that I may both query
and
Post by Donald Russell
set, and when I look at NET-SNMP-EXTEND-MIB it appears I can have a
"run-on-set" (2) value for nsExtendRunType...
How do I configure an extend config statement to support both snmpget and
snmpset?
Try using "extendFix" instead of "extend"
Post by Donald Russell
Or, the man page says "extend" items can be added dynamically.... that
would
Post by Donald Russell
be great... I can have a system start up script dynamically add the
run-on-get and the run-on-set scripts. (Actually the same script, args
would
Post by Donald Russell
determine action taken)
That would use SET requests to build up the entry in the
nsExtendConfigTable.
Try configuring a row using "extend", and walk this table to see what the
entry looks like. Then use "snmpset" with equivalent varbinds (and an
nsExtendStatus value of 'createAndGo')
Post by Donald Russell
When the script is run due to run-on-set, is the new value simply passed
as
Post by Donald Russell
the args or is it more structured than that?
It's actually simpler than that.
When the nsExtendRunType instance is set to 'run-command(3)',
then the corresponding nsExtendCommand is invoked (using the
arguments from nsExtendArgs and input from nsExtendInput).
The "new value" for nsExtendRunType is never actually used
(other than as a trigger for invoking the command). If you read
the nsExtendRunType instance again, it will still have the value
'run-on-set(2)'
Similar to "pass" which passes -s OID TYPE VALUE
No
Post by Dave Shield
"pass" is SNMP-knowledgable (and runs a closely defined command)
"extend" is SNMP-ignorant (and can run an arbitrary command)
These 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

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

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


Thanks very much...
Dave Shield
2011-03-22 09:35:16 UTC
Permalink
Post by Donald Russell
Post by Dave Shield
What does your pass script look like?
pass .1.3.6.1.4.1.15966.1 /usr/local/bin/passtest
[snip]
Post by Donald Russell
Yet in my /tmp.passtest.log file I see
-g .1.3.6.1.4.1.15966.1.1
        RET=.1.3.6.1.4.1.15966.1.1; TYPE=integer; VALUE=42
So the script was invoked
#snmpwalk .1.3.6.1.4.1.15966.1
SNMPv2-SMI::enterprises.15966.1 = No Such Instance currently exists at this OID
Are you running this agent as root, or as a non-privileged user?

When I tried this (running the agent as myself), and walked this OID,
the agent printed the error:

can not create cache file
/var/net-snmp/.snmp-exec-cache: Permission denied

and I didn't see anything.
When I restarted the agent as root (with exactly the same setup),
I could walk the tree as expected.

Might that be the problem you are seeing?
Does the agent log anything when you query the pass tree?

Dave
Donald Russell
2011-03-22 16:40:17 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
Post by Dave Shield
What does your pass script look like?
pass .1.3.6.1.4.1.15966.1 /usr/local/bin/passtest
[snip]
Post by Donald Russell
Yet in my /tmp.passtest.log file I see
-g .1.3.6.1.4.1.15966.1.1
RET=.1.3.6.1.4.1.15966.1.1; TYPE=integer; VALUE=42
So the script was invoked
#snmpwalk .1.3.6.1.4.1.15966.1
SNMPv2-SMI::enterprises.15966.1 = No Such Instance currently exists at
this OID
Are you running this agent as root, or as a non-privileged user?
I believe the agent is running as root.
It is started automatically on system boot by chkconfig.
When I make config changes in snmpd.local.conf I "service snmpd restart" as
root.

#service snmpd status
snmpd (pid 1330) is running...

#ps -U root -u root u | grep 1330
root 1330 0.0 0.8 83308 8204 ? S<l 16:12 0:00
/usr/sbin/snmpd -Lsd -p /var/run/snmpd.pid -a


I run the snmpget/set/walk commands as a non-privileged user.
I also tried running snmpwalk as root and still get this error:
#snmpwalk .1.3.6.1.4.1.15966.1
SNMPv2-SMI::enterprises.15966.1 = No Such Instance currently exists at this
OID
Post by Dave Shield
When I tried this (running the agent as myself), and walked this OID,
can not create cache file
/var/net-snmp/.snmp-exec-cache: Permission denied
That file is present with mode 644, owner:group is root:root and has a time
stamp matching the date/time I run the snmpwalk command
Post by Dave Shield
and I didn't see anything.
When I restarted the agent as root (with exactly the same setup),
I could walk the tree as expected.
Damn! It's like when you take your car to the mechanic and the funny noise
doesn't happen.
Post by Dave Shield
Might that be the problem you are seeing?
I don't think so.
Post by Dave Shield
Does the agent log anything when you query the pass tree?
I do not see any messages in /var/log/snmpd.log. it has a timestamp of March
11, and is zero bytes in length.

FYI, this is version
#snmpd -v

NET-SNMP version: 5.3.2.2
Web: http://www.net-snmp.org/
Email: net-snmp-***@lists.sourceforge.net

#cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.6 (Tikanga)
Dave Shield
2011-03-22 17:18:07 UTC
Permalink
Post by Donald Russell
I run the snmpget/set/walk commands as a non-privileged user.
I also tried running snmpwalk as root and still get [the same] error
That won't be relevant.
Problems with the agent will purely depend on what the agent can do
The client side won't require any special privileges.
Post by Donald Russell
Post by Dave Shield
Does the agent log anything when you query the pass tree?
I do not see any messages in /var/log/snmpd.log. it has a timestamp of March
11, and is zero bytes in length.
Zero length? Even if you restart the agent?
That sounds as if the agent isn't actually logging there.

Try running the agent by hand (perhaps on a non-standard port),
using something like

snmpd -f -Le .... 9999

(including any other settings that the main agent would normally specify)
and then run the query against localhost:9999
That way you should see any output from the agent.
Post by Donald Russell
FYI, this is version
#snmpd -v
NET-SNMP version:  5.3.2.2
Web:               http://www.net-snmp.org/
Hmmm... That's a relatively old version of the agent.
But I've just tried with the current 5.3.x code,
which should be reasonably similar. And I get the same
behaviour as before - running unprivileged complains
about /var/net-snmp/.snmp-exec-cache
Running the agent as root runs the pass script correctly.

Dave
Dave Shield
2011-03-22 09:49:06 UTC
Permalink
Post by Donald Russell
[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.
Post by Donald Russell
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!
Post by Donald Russell
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
Donald Russell
2011-03-22 15:38:15 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
[exec/extend and pass] are two very different approaches to extending
the agent.
Post by Donald Russell
Don't try and equate the two.
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?
I have not made myself clear.... :-)

I have this extend directive in the snmpd.local.conf file:
extend cmm /usr/local/bin/cmm

That is fantastic... within 5 minutes I have a new "OID" I can query. I get
the results of my /usr/local/bin/cmm program.

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,
possibly like:
/usr/local/bin/cmm -s STRING "some new value"

Or, failing that, allow more information in the config file. Perhaps
something like:
extend cmm /usr/local/bin/cmm %t %s

Where "%t" and "%s" are a place holders for the type and value as specified
on the snmpset command.

Yes, I could
snmpset ... nsExtendArgs.\"cmm\" s "some new value"
snmpget ... nsExtendOutputFull.\"cmm\"

I don't like this for the following reasons:
1 - I end up using an snmpget command to effect a change
2 - multiple snmpgets will effect mulitple sets until I can change the args
again.
3 - with the nature of snmp and udp, what if the snmpset to change the args
fails for some reason, but the get is successful... the get uses the old
args... not what I want. So, I could "set args", get args" to make sure they
are correct"... if not try the set again, rinse and repeat.

exec is deprecated in favour of extend... that's fine, extend is great.
Dave Shield
2011-03-22 15:59:01 UTC
Permalink
Post by Donald Russell
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
Post by Donald Russell
Yes, I could
snmpset ... nsExtendArgs.\"cmm\" s "some new value"
snmpget ... nsExtendOutputFull.\"cmm\"
That's how things have been designed to work - yes.
Post by Donald Russell
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\"
Post by Donald Russell
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.
Post by Donald Russell
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.
Post by Donald Russell
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 :-)
Donald Russell
2011-03-23 18:37:12 UTC
Permalink
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...
Post by Donald Russell
Post by Donald Russell
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
Post by Donald Russell
Yes, I could
snmpset ... nsExtendArgs.\"cmm\" s "some new value"
snmpget ... nsExtendOutputFull.\"cmm\"
That's how things have been designed to work - yes.
Post by Donald Russell
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\"
Post by Donald Russell
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.
Post by Donald Russell
3 - with the nature of snmp and udp, what if the snmpset to change the
args
Post by Donald Russell
fails for some reason
Presumably your application will check the result of the SET, and
won't proceed with the GET if it fails.
Post by Donald Russell
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 :-)
Dave Shield
2011-03-23 22:20:00 UTC
Permalink
Post by Donald Russell
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)
Correct.
Post by Donald Russell
If the nsExtendRunType is "run-on-set", then ...
the command is NOT run until also set nRunType to run-command(3).
Correct
Post by Donald Russell
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"
Yes.
Post by Donald Russell
then to effect a change, I would
snmpset nsExtendArgs."myname" = "new args" nsExtendRunType = 3
then
snmpset nsExtendArgs."myname" = ""
That's one approach, certainly.
Post by Donald Russell
If that's the case, I think it will be better for me to have two extensions,
one to get and another to change.
That would be my preference, yes.
Post by Donald Russell
So then the process becomes...
snmpget nsExtendOutputFull."mygetname""
snmpset nsExtendAgs."mysetname" = "new string args" nsRunType."mysetname" = 3
And of course, if the arguments are fixed, then any subsequent
invocations would just need to be

snmpset nsExtendRunType."mysetname" = 3
Post by Donald Russell
OK, that's cool.... is there a way to define a run-on-set item in the config file?
GOT IT!
extend name command
extendfix name command
Zigactly


Dave
Donald Russell
2011-03-23 21:45:34 UTC
Permalink
Post by Dave Shield
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.
OK, I now have two "extensions" in my config file and have restarted snmpd
(as root)...

extend cmm /usr/local/bin/cmm
extendfix cmm /usr/local/bin/cmm

snmpwalk ... nsExtendConfigTable
shows what I expect... "cmm" items and "cmmFix" items

So, now I want to send my specific set request

$snmpset nsExtendArgs.\"cmmFix\" = "some new args"
nsExtendRunType.\"cmmFix\" = 3
Error in packet.
Reason: notWritable (That object does not support modification)
Failed object: NET-SNMP-EXTEND-MIB::nsExtendArgs."cmmFix"


Note: snmpset is aliased to use the -v and ic rwcommunity and host

I'm so close... the error makes sense; in the MIB file I see those variables
have a max access of read-create, so I sort of expect a write to fail.

So, how do I set the new nsExtendArgs value and run the command?
Dave Shield
2011-03-23 22:29:16 UTC
Permalink
OK, I now have two "extensions" in my config file...
extend cmm /usr/local/bin/cmm
extendfix cmm /usr/local/bin/cmm
snmpwalk ... nsExtendConfigTable
shows what I expect... "cmm" items and "cmmFix" items
So, now I want to send my specific set request
$snmpset nsExtendArgs.\"cmmFix\" = "some new args"
nsExtendRunType.\"cmmFix\" = 3
No - that won't work.

Typically, any entry configured via the snmpd.conf file will be "read-only".
( I can explain the reasoning behind this if you like,
but it's essentially concerned with what happens of the agent is restarted)

The simplest approach here would be to configure

extend cmm /usr/local/bin/cmm
extendfix cmm /usr/local/bin/cmm some new args

and then issue
snmpset nsExtendRunType."cmmFix" = 3



Alternatively, set the entry up using SET commands.
That will allow the settings to be changed subsequently.
I'm so close... the error makes sense; in the MIB file I see those variables
have a max access of read-create, so I sort of expect a write to fail.
No - an access of read-create is sufficient to allow changes to the table.
The issue here is that nsExtendStorageType is set to 'read-only' for
snmpd.conf entries.
So, how do I set the new nsExtendArgs value and run the command?
See above

Dave
Donald Russell
2011-03-24 16:07:13 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
Or, the man page says "extend" items can be added dynamically.... that
would
Post by Donald Russell
be great... I can have a system start up script dynamically add the
run-on-get and the run-on-set scripts. (Actually the same script, args
would
Post by Donald Russell
determine action taken)
That would use SET requests to build up the entry in the
nsExtendConfigTable.
Try configuring a row using "extend", and walk this table to see what the
entry looks like. Then use "snmpset" with equivalent varbinds (and an
nsExtendStatus value of 'createAndGo')
I thought I'd try a simple example...

ext='\"dnr\"'
snmpset -v 2c -c private localhost \
nsExtendStatus.$ext = 'createAndGo' \
nsExtendRunType.$ext = 'run-on-set' \
nsExtendCommand.$ext = '/bin/date' \
nsExtendArgs.$ext = ''

But that resulted in a bunch of (the same) errors:
nsExtendStatus.\"dnr\": Unknown Object Identifier (Index out of range:
\"dnr\" (nsExtendToken))
nsExtendRunType.\"dnr\": Unknown Object Identifier (Index out of range:
\"dnr\" (nsExtendToken))
nsExtendCommand.\"dnr\": Unknown Object Identifier (Index out of range:
\"dnr\" (nsExtendToken))
nsExtendArgs.\"dnr\": Unknown Object Identifier (Index out of range: \"dnr\"
(nsExtendToken))


So then I thought, maybe the extension name should not be specified on the
nsExtendStatus... nope.
Maybe I need to set nsExtendToken (though the MIB says it's inaccessible)
Then I tried leaving my extension name off all the items, only specifying it
for the token...
Nope, still not created...

I'm at the very last step of understanding how this works. :-)

Will you please provide a simple example (as above) of how to dynamically
create an nsExtend item?

Thanks very much
Dave Shield
2011-03-24 16:15:50 UTC
Permalink
Post by Donald Russell
ext='\"dnr\"'
Untested, but try
either

ext='"dnr"' (i.e. single quote, double quote
then the string,
then double quote, single quote

or

ext=\"dnr\"

You only need one of these to escape the double quote
Using *both* of them passes the backlashes through to the 'snmpset' command.
This needs to see the double quote characters - but nothing else.

Dave
Dave Shield
2011-03-24 17:01:30 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
ext='\"dnr\"'
Untested, but try
either
   ext='"dnr"'
or
  ext=\"dnr\"
I can now confirm that both of these work as expected.

Also, it's not necessary to explicitly set nsExtendArgs to be the
empty string - this is the default value.

Setting nsExtendStatus + nsExtendCommand is sufficient to
configure a (run-on-read) entry.
nsExtendStatus+nsExtendCommand+nsExtendRunType is sufficient
to configure a run-on-set entry


Dave
Donald Russell
2011-03-24 17:04:01 UTC
Permalink
Post by Dave Shield
Post by Donald Russell
ext='\"dnr\"'
Untested, but try
either
ext='"dnr"' (i.e. single quote, double quote
then the string,
then double quote, single quote
or
ext=\"dnr\"
You only need one of these to escape the double quote
Using *both* of them passes the backlashes through to the 'snmpset' command.
This needs to see the double quote characters - but nothing else.
(In my best Peter Sellers/Inspector Clouseau voice) Ah, the ol' bash quotes
ploy... :-)

Thanks... but bad news (for me)

Now, the request times out, and snmpd crashes....

Timeout: No Response from localhost

$sudo service snmpd status
snmpd dead but pid file exists

That's version 5.3.2.2

I did try the above with snmpd 5.5 and it worked as expected... I'll see if
I can get an update for the systems I want to do this on.

Thanks very much for all your help with this.

If you're interested, I'll write up some information that would have helped
me immensely and you may include it in future man pages, or not. I found the
doc a bit unclear...

Cheers
Dave Shield
2011-03-25 13:30:03 UTC
Permalink
Post by Donald Russell
Thanks... but bad news (for me)
Now, the request times out, and snmpd crashes....
That's version 5.3.2.2
Hmmm... I've just tried this with the current 5.3.x code
(essentially 5.3.4.pre1), and it works as expected.

I haven't checked the list of changes between 5.3.2.2 and
5.3.4.pre1 to see if there's anything relevant, but it might be
worth you checking with the 5.3.4.pre1 tarball, to see whether
it works for you or not.

Dave

Niels Baggesen
2011-03-24 16:15:48 UTC
Permalink
Post by Donald Russell
ext='\"dnr\"'
snmpset -v 2c -c private localhost \
nsExtendStatus.$ext = 'createAndGo' \
nsExtendRunType.$ext = 'run-on-set' \
nsExtendCommand.$ext = '/bin/date' \
nsExtendArgs.$ext = ''
\"dnr\" (nsExtendToken))
Too much quoting ... take the \ (or ') away ...

/Niels
--
Niels Baggesen -- @home -- Århus -- Denmark -- ***@baggesen.net
The purpose of computing is insight, not numbers -- R W Hamming
Continue reading on narkive:
Loading...