ANNOUNCE: MIB Smithy SDK - SMI/SNMP Extension for Tcl (Commercial)
Michael Kirkham
Muonics is pleased to announce the availability of MIB Smithy SDK.
Based on the core library upon which Muonics' MIB Smithy Visual MIB
Development Environment (designer/editor/compiler) has been built, the
SDK provides an extension to Tcl/Tk (8.1+) that allows development of
custom scripts for controlling SNMP agents or manipulating SMI
definitions, conversions, etc. The SDK provides complete read-write
access to all elements of SMI/MIB Module definitions, unlike similar
extensions that provide only read access to a limited subset. Supports
SMIv1 and SMIv2 as well as SNMPv1/v2c and SNMPv3 with HMAC-SHA-96 and
HMAC-MD5-96 authentication and CBC-DES privacy.
Major Benefits over similar extensions:
* It's a commercial product, so it's supported.
* It is part of the core of Muonics' flagship product, so you know
we have no intention of abandoning it or ceasing improvements.
* It's current: we use it with Tcl/Tk 8.4.
* It supports SNMPv3 (and earlier versions, of course).
* It's both one of the most thorough and flexible MIB compilers in
existence -and- an SNMP management extension rolled into one.
Major Features:
* Linked to the Tcl "Stubs" Library so it will work with Tcl 8.1 or
later versions.
* Import/Export SMIv1 MIB Modules (RFCs 1065, 1155, 1212, 1215)
* Import/Export SMIv2 MIB Modules (RFCs 2576, 2578, 2579, 2580)
* ALL information from MIB definitions is available via the APIs,
right down to the ASN.1 comments: not just a tiny subset provided
by an external compiler.
* Import modules from XML or SMI format directly (no external
compiler needed).
* Provides both read and write access to MIB definitions, rather than
read-only access provided by similar extensions.
* Full support for even the most obscure areas of the SMI that
similar extensions lack.
* Duplicate record names are not a problem with the SDK's flexible
search algorithm and complex indexing mechanisms.
* Ability to create custom compiler output formats
* SNMPv1, SNMPv2 and SNMPv3 Management APIs with Authentication and
Privacy support.
* Provides both blocking and non-blocking/callback modes for request
processing.
* Unlimited number of concurrent SNMP Sessions
* Unlimited number concurrent SMI Databases for isolating MIBs for
different agents/projects.
* Unlimited number of MIB files/modules in each database
* Each session can be configured to use its own SMI Database or
to use the default.
* Built-in Compiler/Validation API
* Configurable output channel for compiler messages
* Automatic SMI syntax checking and error correction can work around
many common MIB design errors.
* Well over 560 MIB Validation checks performed to ensure SMI
compliance.
Platforms Supported:
* Microsoft Windows (95, 98, NT, 2000, XP)
* FreeBSD (4.3 or compatible)
* Linux (Red Hat 7.3 or compatible)
* Solaris 2.7+ (SPARC)
* Other platforms are negotiable.
Further information can be found at:
http://www.muonics.com/Products/MIBSmithySDK/
....and...
http://www.muonics.com/Products/MIBSmithy/
The developer's guide (still undergoing some revision) is available
online at:
http://www.muonics.com/Docs/MIBSmithy/DevGuide/
Questions/comments/etc. may be directed to sales or support at
muonics.com as appropriate. Thanks!
--
Michael Kirkham
Muonics
http://www.muonics.com/
[[Send Tcl/Tk announcements to tcl-an...@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announ...@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]
Cameron Laird
Michael Kirkham <mikek...@muonics.com> wrote:
>
>Muonics is pleased to announce the availability of MIB Smithy SDK.
.
.
Cool!
So, 'want to say a few words of explicit comparison to MOODS and
Scotty?
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
x@y.z
> So, 'want to say a few words of explicit comparison to MOODS and
> Scotty?
I'll do my best.
MOODS uses Scotty/tnm, right? So I'm not sure there's anything to
compare to directly there: the SDK does not (currently) provide any GUI
widgets, just the APIs for importing, creating, querying MIB module
definitions, and for performing SNMP management operations. I haven't
used MOODS, but I'd imagine it would be fairly easy to integrate the SDK
with it.
As for Scotty:
The most recent "official" release of Scotty is (so I hear) not well
integrated with Tcl 8.x. The 3.0.0 version supposedly is better. The
SDK, as mentioned, is linked against the stubs library so Tcl 8.1+ should
work fine.
Getting into specific features...
MIB/SMI Information --
MIB Smithy SDK supports importing modules written XML according to the
XML Schema at www.muonics.com/XMLSMI/. This is the same format that MIB
Smithy Pro/Std export to and MIB Smithy Pro imports. Scotty does not
support importing from XML. (I should note that libsmi, another project
that Juergen (the Scotty developer) is deeply involved with supports
exporting modules to the format of a DTD from an expired internet draft.
The SDK does not support this DTD because it is very incomplete and has a
number of bugs. I worked with Juergen and others a bit to develop the
XML Schema that we support.)
The SDK allows for multiple databases for isolated groups of MIB modules
(so you can, e.g., load the appropriate modules for one agent into one
database, and those for another into another database. Or load multiple
revisions of the same module into different databases without them
conflicting). Scotty does not.
Scotty provides read-only access to a fairly limited subset of the
information to be garnered from a source file. For example, the only
textual field it provides is the description field (at least according to
the man page), and there are no commands for getting at conformance
(MODULE-COMPLIANCE/AGENT-CAPABILITIES) information. The SDK provides
both read and write access to all MIB definitions -- everything from the
normal syntax/value stuff necessary for management operations right down
to the comments associated with records and individual enumeration
values. This makes lossless conversion between different custom file
formats possible (if, for example, you have an existing MIB compiler that
you want to replaced with the SDK).
By "write" access to MIB definitions, I mean you can use the APIs
provided by the SDK to build module definitions internally (as if they'd
been imported from file) and then export them to your desired format.
This is not possible with Scotty.
Scotty can only import modules directly from files. The SDK can import
modules either from files or parse the data passed directly to the import
(useful for importing file formats that require first extracting the
modules). The SDK, however, also as a built-in "validate" command to run
through the 560+ tests (based on messages alone, many are used in
multiple tests) for SMI conformance/etc. So if you wanted to implement a
drop-in replacement for another compiler and get much better validation,
all you need to deal with is generating the output format.
There are a lot of more obscure/less commonly used areas of the SMI that
are not supported by Scotty (or, for that matter, most other MIB
compilers etc). Namely, things like local module names for IMPORTS where
the FROM module name is different from the actual module name when
importing two modules with the same name, where an OID is included after
the module name that uniquely identifies it, as well as
"module.descriptor" references within the module:
EXAMPLE-MIB DEFINITIONS ::= BEGIN
IMPORTS
ambiguous
FROM OTHER-MIB
experimental, OBJECT-TYPE
FROM SNMPv2-SMI
...
;
someObject1 OBJECT-TYPE
...
::= { ambiguous 1 }
ambiguous OBJECT IDENTIFIER ::= { experimental 99999 }
someObject2 OBJECT-TYPE
...
::= { OTHER-MIB.ambiguous 1 }
...
END
EXAMPLE2-MIB DEFINITIONS ::= BEGIN
IMPORTS
aa FROM M1 { 0 0 999999 1 }
aa FROM M2 { 0 0 999999 2 }
...
bb NOTIFICATION-TYPE
...
OBJECTS { M1.aa, M2.aa }
...
::= { ... }
END
The SDK also provides much greater flexibility in referencing MIB
definitions. In addition to referencing them just by name or OID, you
can specify from 1 to 5 "envelopes" that represent containment or
namespace. e.g., if EXAMPLE2-MIB is loaded into file #2, then 'bb' can
be referenced by OID, by 'bb', by 'EXAMPLE2-MIB!bb', by
'@File2!EXAMPLE2-MIB!bb' or by '@File2!bb' as necessary to avoid
conflicts if multiple modules define the symbol 'bb'.
SNMP --
The first caveat I should probably note is that the current version of
the SDK does not yet support receiving traps/notifications, but this is
only due to running into time constraints with getting the 2.0 version of
the main MIB Smithy product out. This is the #1 priority thing to
address and we will do so within the next week or two, after getting all
the documentation updated/etc.
The most recent "official" release of Scotty does not support SNMPv3.
There is an alpha version (3.0.0) that supports noAuth/noPriv. MIB
Smithy SDK supports SNMPv3 with both authentication (MD5/SHA) and
privacy (DES). We will probably be adding AES privacy support fairly
soon (the AES privacy protocol for SNMPv3/USM is currently still in last
call, I believe).
MIB Smithy SDK currently provides only SNMP management support.
Scotty/Tnm does provide interfaces for other protocols such as ICMP, DNS,
etc. We may look into adding some of these in the future, but our focus
is on SNMP for now.
Scotty supports SNMPv2u (user-based SNMPv2). The SDK does not; but
SNMPv2u never reached "standard" status, is not widely implemented, and
is thus a bit useless for modern purposes. SNMPv2c is not a standard
either, but it is widely implemented because it is a useful stepping
stone from taking an SNMPv1 implementation towards implementing SNMPv3
(SNMPv2c shares the same message format and security model as SNMPv1 and
the same PDUs as SNMPv3).
The variable bindings list is basically the same between Scotty and the
SDK (a list of oid/type/value triplets), except that the OIDs and types
can be referenced using the more precise search string format described
in the developer's guide. (e.g., in addition to specifying sysDescr.0 in
the OID part, you could use SNMPv2-MIB!sysDescr.0 or
@File3!SNMPv2-MIB!sysDescr.0 if necessary because the descriptor
'sysDescr' means different things to different modules). Same goes for
types.
Both provide multiple SNMP session support.
Both provide blocking and non-blocking interfaces for sending requests.
For callbacks, Scotty provides a number of format codes (such as %V, %R,
etc.) for a limited number of parameters that get replaced with
appropriate values when the callback is called. The SDK callbacks follow
a more general form: proc callback { id args }, where 'id' is the unique
number identifying the pending request, and 'args' is a list of
name/value pairs suitable for use with 'array set' that provide a greater
level of detail of the response.
Scotty provides some tracing information (e.g. a hex dump of
sent/received packets in realtime) that the SDK does not, but this will
be addressed soon.
The SDK's interfaces are somewhat more generic. For example, Scotty's
get-bulk command requires the non-repeaters and max-repetitions values to
be specified as the first two arguments. The SDK uses default values
unless you provide the -nonreps and -maxreps options.
Scotty can send informs and traps. This is partially implemented but not
fully tested in the SDK yet.
Scotty provides some agent-role functionality that the SDK does not.
This is also something we are looking toward supporting in the near
future (and part of the reason traps weren't addressed yet - we'd like to
keep the APIs consistent between them).
Michael Kirkham
says...
Oops. Sorry about the bogus address. I really need to quit entering the
address manually on a per-newsgroup basis so that default junk doesn't
happen when I forget. :)
Cameron Laird
.
.
.
.
Interesting. Michael, I think people outside
of Tcl will want to know of this opportunity.
Thanks for the detail; I'm going to be passing
it on to others.
Michael Kirkham
> Interesting. Michael, I think people outside
> of Tcl will want to know of this opportunity.
> Thanks for the detail; I'm going to be passing
> it on to others.
I hope you're right. :) It has been mentioned on comp.protocols.snmp,
and in Muonics' press release for MIB Smithy 2.0
(http://www.marketwire.com/mw/release_html_b1?release_id=053402)
although unfortunately we made the mistake of sending it out on a Friday
so it didn't get nearly as much coverage as earlier PR's, despite being a
much more significant one -- oh well!
Anyway, thanks much for passing it on. Hopefully we can make a demo for
the standalone SDK available within a few days.
If you think people would be interested in a version of the extension for
other languages (e.g. perl, php...) I would be interested to hear about
it. I know both have net-snmp based extensions, so the niche might
already be sufficiently filled.
Jean-Luc Fontaine
> In article <vbdepu3...@corp.supernews.com>, cla...@lairds.com says...
>
> > So, 'want to say a few words of explicit comparison to MOODS and
> > Scotty?
>
> I'll do my best.
>
> MOODS uses Scotty/tnm, right?
Correct: the Tnm package is used in the snmp and snmptrap modules.
> So I'm not sure there's anything to
> compare to directly there: the SDK does not (currently) provide any GUI
> widgets, just the APIs for importing, creating, querying MIB module
> definitions, and for performing SNMP management operations. I haven't
> used MOODS, but I'd imagine it would be fairly easy to integrate the SDK
> with it.
Sounds reasonable.
> As for Scotty:
>
> The most recent "official" release of Scotty is (so I hear) not well
> integrated with Tcl 8.x. The 3.0.0 version supposedly is better.
It sure would be very useful to have a free SNMP package that works
with Tcl 8.4... Any plans for that? Is anybody working on Scotty
still? I'd be very interested in testing that...
> The
> SDK, as mentioned, is linked against the stubs library so Tcl 8.1+ should
> work fine.
>
> Getting into specific features...
Thank you very much for this complete and very interesting
information. Your product looks great: too bad it is not free ;-).
Jean-Luc
Michael Kirkham
jfon...@free.fr says...
> > The most recent "official" release of Scotty is (so I hear) not well
> > integrated with Tcl 8.x. The 3.0.0 version supposedly is better.
>
> It sure would be very useful to have a free SNMP package that works
> with Tcl 8.4... Any plans for that?
As nice as that would be, the MIB Smithy series represents a huge
investment of time and money in creating that we're still far from
recouperating. Scotty has (or had) the luxury of being a university-
funded project. We have no such luxury, so it's all been funded out of
my own pocket. That said, perhaps a few months down the line as we add
more and more features to the SDK perhaps there will be an appropriate
subset that we could release as a free module. Among other things, it
wouldn't include DES privacy support, however, as there are still export
restrictions to contend with here in the US. (They've been relaxed such
that you don't have to get an export permit for the key length used by
DES, but it's still forbidden to export to certain countries/etc.)
> Is anybody working on Scotty
> still? I'd be very interested in testing that...
Don't know.
> Thank you very much for this complete and very interesting
> information. Your product looks great: too bad it is not free ;-).
Thank you. I will contact you offline. Perhaps we can work a special
arrangement of some sort.
Marc Spitzer
> In article <4244613b.03050...@posting.google.com>,
>
> As nice as that would be, the MIB Smithy series represents a huge
> investment of time and money in creating that we're still far from
> recouperating. Scotty has (or had) the luxury of being a university-
> funded project. We have no such luxury, so it's all been funded out of
> my own pocket. That said, perhaps a few months down the line as we add
> more and more features to the SDK perhaps there will be an appropriate
> subset that we could release as a free module. Among other things, it
> wouldn't include DES privacy support, however, as there are still export
> restrictions to contend with here in the US. (They've been relaxed such
> that you don't have to get an export permit for the key length used by
> DES, but it's still forbidden to export to certain countries/etc.)
What is the policy for deployment, how much do runtime licences cost?
>
> > Is anybody working on Scotty
> > still? I'd be very interested in testing that...
>
I have gotten it working under 8.3 on solaris and freebsd.
> Don't know.
>
> > Thank you very much for this complete and very interesting
> > information. Your product looks great: too bad it is not free ;-).
Why? It is only fair to charge for your work, no? The product looks
to be useful and fairly priced.
marc
Michael Kirkham
mspi...@optonline.net says...
> What is the policy for deployment, how much do runtime licences cost?
Single-host (ie., installation on a single computer) licenses start at
$349. We will probably make volume discounts available, as with our
other products, but we're still working out the numbers. Redistributable
licenses (ie., if you want to use the library in a commercial product)
are a possibility, and we're open to negotiations, but we haven't put a
lot of thought into pricing/terms/etc. for such yet.
A license includes all updates/upgrades at no charge for a period of 1
year after purchase, and that can be renewed annually for a small
percentage as desired (the license its self does not expire -- it's not
a subscription-based license). We do employ software-based node locking,
but we do not charge for changing hosts (e.g. for reasons of hardware
failure or upgrades) up to twice annually.
Also, our policy with regards to platforms that we don't currently
support is basically that we're willing to support any platform that
Tcl/Tk will run on so long as we can cover the hardware costs/etc. If
someone wants to trade hardware for a number of licenses of equal value
or purchase enough licenses to cover the cost of the hardware, we're all
for it. I've been trying to judge interest in OS X support in
particular, but haven't really found there to be any significant
migration to that platform for network management (at least not for
developers).
Cameron Laird
Michael Kirkham <NOSPAM.mi...@muonics.com.NOSPAM> wrote:
.
.
.
>for it. I've been trying to judge interest in OS X support in
>particular, but haven't really found there to be any significant
>migration to that platform for network management (at least not for
>developers).
.
.
Me, neither, from the tiny evidence before me. More's the pity.
Jean-Luc Fontaine
>>>Thank you very much for this complete and very interesting
>>>information. Your product looks great: too bad it is not free ;-).
>
>
> Why? It is only fair to charge for your work, no? The product looks
> to be useful and fairly priced.
I think you slightly misunderstood me or missed the smiley ;-). The
problem I have is that in order to try writing code against that
library, I would have to buy it, which is something that I cannot do due
to the highly administrative and procedural nature of my work
environment. I very sincerely wish the MIB Smithy SDK product a lot of
sales.
Anyway, Michael Kirkham of Muonics very kindly offered to make a free
license available to me so that I can write a moodss module for Smithy,
which I agreed to do.
I'll keep this newsgroup posted on my progress.
--
Jean-Luc Fontaine mailto:jfon...@free.fr http://jfontain.free.fr/
Marc Spitzer
> Marc Spitzer wrote:
>
> >>>Thank you very much for this complete and very interesting
> >>>information. Your product looks great: too bad it is not free ;-).
> > Why? It is only fair to charge for your work, no? The product looks
> > to be useful and fairly priced.
>
> I think you slightly misunderstood me or missed the smiley ;-). The
> problem I have is that in order to try writing code against that
> library, I would have to buy it, which is something that I cannot do
> due to the highly administrative and procedural nature of my work
> environment. I very sincerely wish the MIB Smithy SDK product a lot of
> sales.
>
> Anyway, Michael Kirkham of Muonics very kindly offered to make a free
> license available to me so that I can write a moodss module for
> Smithy, which I agreed to do.
Cool and sorry for the misunderstanding on my part.
marc
Michael Kirkham
cl...@muonics.com says...
>
> Muonics is pleased to announce the availability of MIB Smithy SDK.
> Based on the core library upon which Muonics' MIB Smithy Visual MIB
> Development Environment (designer/editor/compiler) has been built, the
> SDK provides an extension to Tcl/Tk (8.1+) that allows development of
> custom scripts for controlling SNMP agents or manipulating SMI
> definitions, conversions, etc.
I just wanted to follow up on this announcement and let folks know that a
15-day evaluation version of the extension is now available for download.
The evaluation version has a few limitations: there is a 4-module limit,
CBC-DES encryption is disabled, and loaded module definitions are "read
only" (ie., the same way similar SNMP/SMI extensions work - you can query
MIB definitions such as OIDs, types, group members, etc., but you cannot
modify them via the APIs as you can with the full version). Otherwise,
the evaluation is fully functional.
The demo can be downloaded from:
http://www.muonics.com/Products/MIBSmithySDK/
...or..
http://www.muonics.com/Downloads/
Consult the online developer's guide for instructions on loading and
using the extension:
http://www.muonics.com/Docs/MIBSmithy/DevGuide/
Let me know if you have any difficulties. Thanks!