[erlang-questions] SNMP app questions: ?StorageType_volatile, Mnesia storage in general
Scott Lystig Fritchie
fritchie@REDACTED
Fri Mar 16 08:18:23 CET 2007
Hi, I've been playing quite a bit with the OTP SNMP app. It's quite a
nifty pice of work. But I'm still (uncomfortably) a blind man patting
the elephant, trying to discover its shape. So perhaps my questions
are silly, my apologies in advance.
1. I've been using Unbrowse 1.5(*) to test my SNMP v3 agent
application.
a. Create a group with Unbrowse
b. Stop the SNMP agent application
c. Start the SNMP agent application
... but after the restart, my new group is gone. If I capture the
packet SNMP SET datagram, I see that my client is requesting
StorageType...
Hm, I don't really grok how to decode these things ... I have an
annotated "wireshark" output below (see the "SLF" marks) ... it looks
like the Unbrowse client is *not* sending anything for the
"vacmAccessStorageType" attribute.
But diving into the guts of snmpa_vacm.erl, when the agent restarts,
it reads the contents of {db_dir}/snmpa_vacm.db, finds the entry for
my new group, but then ignores it because it's a volatile type,
?'StorageType_volatile'.
Is this a feature? Perhaps the Unbrowse app is silly/broken for not
specifying a value for "vacmAccessStorageType", but this behavior
really is confusing. It doesn't appear to be configurable, so I may
have to hack code to change it.
2. Why does the SNMP app use local dets storage so frequently (with no
config option to use Mnesia? And why does the snmpa_vacm table use
ets:tab2file() instead of Mnesia or event dets?
It would seem to me advantageous from a high-availability
point-of-view to have all that stuff in Mnesia. If Node A fails, how
is the SNMP app on node B going to look at all that dets and tab2file
stuff over on node A?
-Scott
(*) Ask Mr. Google about it. It's a Windows SNMP app that claims to
manipulate SNMP v3 servers, including adding/modifying/deleting SNMP
v3 users, groups, and views. I found it because some search engine
told me it might be good for something. {shrug}
--- snip --- snip --- snip --- snip --- snip --- snip ---
No. Time Source Destination Protocol Info
3 0.109612 10.1.1.253 10.1.1.12 SNMP set-request
Frame 3 (239 bytes on wire, 239 bytes captured)
Linux cooked capture
Internet Protocol, Src: 10.1.1.253 (10.1.1.253), Dst: 10.1.1.12 (10.1.1.12)
User Datagram Protocol, Src Port: 4968 (4968), Dst Port: 4000 (4000)
Source port: 4968 (4968)
Destination port: 4000 (4000)
Length: 203
Checksum: 0xf844 [correct]
Simple Network Management Protocol
msgVersion: snmpv3 (3)
msgGlobalData
msgAuthoritativeEngineID: 656E67696E656130
0... .... = Engine ID Conformance: RFC1910 (Non-SNMPv3)
Engine Enterprise ID: Unknown (1701734249)
<Data not conforming to RFC1910>
msgAuthoritativeEngineBoots: 10
msgAuthoritativeEngineTime: 376
msgUserName: foouser
msgAuthenticationParameters: 2546C72089B42A036498DCDC
msgData: plaintext (0)
plaintext
contextEngineID: 656E67696E656130
data: set-request (3)
set-request
request-id: 28497
error-status: noError (0)
error-index: 0
variable-bindings: 3 items
Item
name: 1.3.6.1.6.3.16.1.4.1.5 <-- SLF: vacmAccessReadViewName?
name: 1.3.6.1.6.3.16.1.4.1.5.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.5.9.98.108.97.114.98.108.97.114.51.0.0.1)
valueType: value (0)
value: simple (4294967295)
simple: string-value (1)
Value: STRING: "blar2view"
Item
name: 1.3.6.1.6.3.16.1.4.1.4 <-- SLF: vacmAccessContextMatch?
name: 1.3.6.1.6.3.16.1.4.1.4.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.4.9.98.108.97.114.98.108.97.114.51.0.0.1)
valueType: value (0)
value: simple (4294967295)
simple: integer-value (0)
Value: INTEGER: 1
Item
name: 1.3.6.1.6.3.16.1.4.1.9 <-- SLF: vacmAccessStatus?
name: 1.3.6.1.6.3.16.1.4.1.9.9.98.108.97.114.98.108.97.114.51.0.0.1 (SNMPv2-SMI::snmpModules.16.1.4.1.9.9.98.108.97.114.98.108.97.114.51.0.0.1)
valueType: value (0)
value: simple (4294967295)
simple: integer-value (0)
Value: INTEGER: 4
More information about the erlang-questions
mailing list