354 lines
13 KiB
Plaintext
354 lines
13 KiB
Plaintext
|
@open -@
|
||
|
|
mib2c has multiple configuration files depending on the type of
|
||
|
|
code you need to write. You must pick one depending on your need.
|
||
|
|
|
||
|
|
You requested mib2c to be run on the following part of the MIB tree:
|
||
|
|
OID: $name
|
||
|
|
numeric translation: $name.objectID
|
||
|
|
@eval $numS = count_scalars@
|
||
|
|
number of scalars within: $numS
|
||
|
|
@eval $numT = count_tables@
|
||
|
|
number of tables within: $numT
|
||
|
|
@eval $numN = count_notifications@
|
||
|
|
number of notifications within: $numN
|
||
|
|
|
||
|
|
First, do you want to generate code that is compatible with the
|
||
|
|
ucd-snmp 4.X line of code, or code for the newer Net-SNMP 5.X code
|
||
|
|
base (which provides a much greater choice of APIs to pick from). You
|
||
|
|
can also generate C-header files containing define statements for
|
||
|
|
column numbers, enums, etc. Or do you simply want to translate the
|
||
|
|
MIB structures into documentation?
|
||
|
|
|
||
|
|
1) ucd-snmp style code
|
||
|
|
2) Net-SNMP style code
|
||
|
|
3) Generate header files
|
||
|
|
4) Generate documentation
|
||
|
|
|
||
|
|
@prompt $ans Select your choice : @
|
||
|
|
@if $ans == 1@
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING CODE FOR THE 4.X LINE OF CODE (THE OLDER API)
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
using the mib2c.old-api.conf configuration file to generate your code.
|
||
|
|
@run mib2c.old-api.conf@
|
||
|
|
|
||
|
|
@elsif $ans == 4@
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING DOCUMENTATION
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
Which type of documentation would you like to generate:
|
||
|
|
|
||
|
|
1) HTML
|
||
|
|
2) Emacs Org-Mode
|
||
|
|
|
||
|
|
@prompt $ansdocs Select your choice : @
|
||
|
|
@if $ansdocs == 1@
|
||
|
|
*** Generating ${name}.html:
|
||
|
|
@run mib2c.genhtml.conf@
|
||
|
|
@elsif $ansdocs != 2@
|
||
|
|
ERROR: invalid selection; terminating.
|
||
|
|
@else@
|
||
|
|
*** Generating ${name}.org:
|
||
|
|
@run mib2c.org-mode.conf@
|
||
|
|
@end@
|
||
|
|
@elsif $ans == 3@
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING HEADER FILES
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
Which type of header file would you like to generate:
|
||
|
|
|
||
|
|
1) column definitions
|
||
|
|
2) column enums
|
||
|
|
|
||
|
|
@prompt $ansheaders Select your choice : @
|
||
|
|
@if $ansheaders == 1@
|
||
|
|
*** Generating ${name}_columns.h:
|
||
|
|
@run mib2c.column_defines.conf@
|
||
|
|
@elsif $ansdocs != 2@
|
||
|
|
ERROR: invalid selection; terminating.
|
||
|
|
@else@
|
||
|
|
*** Generating ${name}_enums.h:
|
||
|
|
@run mib2c.column_enums.conf@
|
||
|
|
@end@
|
||
|
|
@elsif $ans != 2@
|
||
|
|
Invalid answer.
|
||
|
|
@else@
|
||
|
|
@if $numS > 0 && $numT > 0@
|
||
|
|
**********************************************************************
|
||
|
|
MIXED MIB TEMPLATE
|
||
|
|
**********************************************************************
|
||
|
|
The portion of the MIB tree that you have selected contains both
|
||
|
|
scalar objects and MIB tables. The automatically generated Net-SNMP
|
||
|
|
style code cannot handle both of these simultaneously (though you
|
||
|
|
could generate the two files separately, and then merge the two).
|
||
|
|
|
||
|
|
Which code do you want to generate:
|
||
|
|
|
||
|
|
1) Scalar objects
|
||
|
|
2) MIB tables
|
||
|
|
|
||
|
|
@prompt $ans Select your choice : @
|
||
|
|
@if $ans == 1 @
|
||
|
|
@eval $numT = 0@
|
||
|
|
@elsif $ans == 2@
|
||
|
|
@eval $numS = 0@
|
||
|
|
@else@
|
||
|
|
Invalid answer
|
||
|
|
@eval $numS = 0@
|
||
|
|
@eval $numT = 0@
|
||
|
|
@end@
|
||
|
|
@end@
|
||
|
|
@if $numS > 0@
|
||
|
|
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING CODE FOR SCALAR OBJECTS:
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
It looks like you have some scalars in the mib you requested, so I
|
||
|
|
will now generate code for them if you wish. You have two choices
|
||
|
|
for scalar API styles currently. Pick between them, or choose not
|
||
|
|
to generate any code for the scalars:
|
||
|
|
|
||
|
|
1) If you're writing code for some generic scalars
|
||
|
|
(by hand use: "mib2c -c mib2c.scalar.conf $name")
|
||
|
|
|
||
|
|
2) If you want to magically "tie" integer variables to integer
|
||
|
|
scalars
|
||
|
|
(by hand use: "mib2c -c mib2c.int_watch.conf $name")
|
||
|
|
|
||
|
|
3) Don't generate any code for the scalars
|
||
|
|
|
||
|
|
@prompt $ans Select your choice: @
|
||
|
|
@if $ans == 1@
|
||
|
|
using the mib2c.scalar.conf configuration file to generate your code.
|
||
|
|
@run mib2c.scalar.conf@
|
||
|
|
@elsif $ans == 2@
|
||
|
|
using the mib2c.int_watch.conf configuration file to generate your code.
|
||
|
|
@run mib2c.int_watch.conf@
|
||
|
|
@elsif $ans != 3@
|
||
|
|
WARNING: Unknown response. Skipping code generation for scalars.
|
||
|
|
@end@
|
||
|
|
@end@ # scalars
|
||
|
|
|
||
|
|
@if $numT > 0@
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING CODE FOR TABLES:
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
The Net-SNMP agent API is extremely extensive and, in fact, lets
|
||
|
|
each programmer write agent code according to the style that works
|
||
|
|
best for them based on their experience and their preference. We're
|
||
|
|
going to ask you a serious of questions that will help mib2c
|
||
|
|
generate code that best suits *your* needs, as the programmer that
|
||
|
|
will be responsible for taking the code and further refining it. If
|
||
|
|
you don't like how the results look, you are always welcome to
|
||
|
|
re-run mib2c and select a different set of options.
|
||
|
|
|
||
|
|
There are essentially two tasks involved in processing requests
|
||
|
|
for OIDs within a MIB table - firstly identifying the relevant row
|
||
|
|
of the table for a given request, and then returning (or updating)
|
||
|
|
the appropriate column value within that row. Many MIB tables model
|
||
|
|
the state of some external system (the kernel, a device, processes,
|
||
|
|
etc), and the MIB implementation module (the code we're about to
|
||
|
|
produce a template for) acts as an interface between this underlying
|
||
|
|
system and the SNMP side. Other tables hold data internally that is
|
||
|
|
only available within the agent itself, or at least the master copy
|
||
|
|
of the data is held within the agent.
|
||
|
|
|
||
|
|
There are a number of different code templates that can be used to
|
||
|
|
implement MIB tables, using various approaches to these two tasks.
|
||
|
|
|
||
|
|
There are three basic approaches to identifying the relevant row:
|
||
|
|
|
||
|
|
1) Pass the request through to the table-specific code, and
|
||
|
|
identify the requested row there (for both GET and GETNEXT
|
||
|
|
requests). This is typically the most efficient way to get
|
||
|
|
up-to-date information, but relies on suitable
|
||
|
|
(programmer-provided) code within the MIB handler.
|
||
|
|
Most importantly, you should be an expert to use this choice.
|
||
|
|
|
||
|
|
This will produce code based on the table_dataset handler.
|
||
|
|
|
||
|
|
2) Have table-specific code to provide information about which
|
||
|
|
rows exist in the table (by iterating through them in turn),
|
||
|
|
but utilise standard helper code to select the appropriate
|
||
|
|
row for a given request. This is particularly suitable for
|
||
|
|
tables where the data is naturally stored in a "random" order
|
||
|
|
(or differently to the MIB table index), or where rows are
|
||
|
|
frequently added to or removed from the table.
|
||
|
|
|
||
|
|
However searching for the requested row is not very efficient,
|
||
|
|
and performance can be slow - particularly for large tables with
|
||
|
|
many rows.
|
||
|
|
|
||
|
|
3) Hold a locally cached copy of the contents of the table (or at
|
||
|
|
least a cache of which rows are valid), and utilise standard
|
||
|
|
helper code to select the appropriate row. This is
|
||
|
|
significantly faster than the iterator-based approach, but
|
||
|
|
cached data is inevitably slightly "stale" with respect to the
|
||
|
|
data from the underlying system being managed. This approach,
|
||
|
|
since it relies on caching of data, is also results in a larger
|
||
|
|
memory footprint. It is less appropriate for tables where rows
|
||
|
|
are frequently added or removed externally to the agent (i.e.,
|
||
|
|
not via SNMP requests).
|
||
|
|
|
||
|
|
This approach can also be used where _all_ use of the table is
|
||
|
|
via SNMP, and there is no external "underlying system". In
|
||
|
|
this case, the local cache is the canonical version of the
|
||
|
|
table.
|
||
|
|
|
||
|
|
4) Do not generate code for the tables.
|
||
|
|
|
||
|
|
@prompt $ans1 Select the option that best fits your requirements: @
|
||
|
|
|
||
|
|
@if ($ans1 == 2) || ($ans1 == 3)@
|
||
|
|
|
||
|
|
Having identified the appropriate row for a given request, there are
|
||
|
|
three basic styles of code for returning (or updating) the requested
|
||
|
|
column value from within this row:
|
||
|
|
|
||
|
|
1) A single handler routine, which contains all the code needed to
|
||
|
|
handle GET and SET requests for each of the column objects.
|
||
|
|
|
||
|
|
@if $ans1 == 2@
|
||
|
|
The code typically looks like a single function with a large 'case'
|
||
|
|
statement covering each of the columns.
|
||
|
|
|
||
|
|
This will produce code based on the 'iterator' hepler.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
2) A set of individual routines, each of which is concerned
|
||
|
|
with a particular aspect of processing the request.
|
||
|
|
@if $ans1 == 2 @
|
||
|
|
Each column object within the table has one routine for
|
||
|
|
retrieving the current value, and another for setting a new one.
|
||
|
|
|
||
|
|
This will produce code based on the 'iterate_access' hepler.
|
||
|
|
@else@
|
||
|
|
There is one routine for reporting values for GET requests,
|
||
|
|
and one routine for each stage of processing a SET request.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
3) A (different) set of individual routines, each of which is
|
||
|
|
smaller and more tightly focused than the code generated by
|
||
|
|
style 2. The aim here is to reduce the amount of SNMP specific
|
||
|
|
knowledge required to implement a module, and hide much of the
|
||
|
|
SNMP terminology and processing within standard generated code
|
||
|
|
(which can simply be used sight unseen).
|
||
|
|
@if $name !~ /Table$/i@
|
||
|
|
However this style of code can only be generated when mib2c
|
||
|
|
is run on an individual MIB table. To use this approach, you
|
||
|
|
will need to re-invoke mib2c with the name of a single MIB table.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
This will produce code based on the 'mfd' hepler ('MIB for Dummies').
|
||
|
|
|
||
|
|
4) Do not generate code for the tables.
|
||
|
|
|
||
|
|
(In all cases, GETNEXT requests are automatically converted
|
||
|
|
into the equivalent GET request, so the MIB specific code
|
||
|
|
need only be concerned with GET and SET requests.).
|
||
|
|
|
||
|
|
@prompt $ans2 Select the code style you wish to use: @
|
||
|
|
@end@
|
||
|
|
|
||
|
|
@eval $template = NONE@
|
||
|
|
@if $ans1 == 1@
|
||
|
|
@eval $template = "create-dataset"@
|
||
|
|
|
||
|
|
@elsif $ans1 == 2@
|
||
|
|
@if $ans2 == 1@
|
||
|
|
@eval $template = iterate@
|
||
|
|
@elsif $ans2 == 2@
|
||
|
|
@eval $template = iterate_access@
|
||
|
|
@elsif $ans2 == 3@
|
||
|
|
@eval $template = mfd@
|
||
|
|
@elsif $ans2 != 4@
|
||
|
|
WARNING: Unknown response. Skipping code generation for tables.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
@elsif $ans1 == 3@
|
||
|
|
@if $ans2 == 1@
|
||
|
|
There are actually two alternative templates that use this
|
||
|
|
style of code - differing primarily in the data structure
|
||
|
|
used for representing a row of the table
|
||
|
|
|
||
|
|
1) The first is well suited for situations where there is a
|
||
|
|
natural existing data structure, or where the contents of
|
||
|
|
the table may need to be interpreted for some additional
|
||
|
|
purpose, other than simply implementing the table in SNMP.
|
||
|
|
|
||
|
|
This will produce code based on the 'table_data' hepler.
|
||
|
|
|
||
|
|
2) The second is slightly more efficient, but introduces some
|
||
|
|
minor constraints on the form of the per-row data structure.
|
||
|
|
|
||
|
|
This will produce code based on the 'container' hepler.
|
||
|
|
|
||
|
|
@prompt $ans3 Select the row representation you wish to use: @
|
||
|
|
|
||
|
|
@if $ans3 == 1@
|
||
|
|
@eval $template = table_data@
|
||
|
|
@elsif $ans3 == 2@
|
||
|
|
@eval $template = container@
|
||
|
|
@else@
|
||
|
|
WARNING: Unknown response. Skipping code generation for tables.
|
||
|
|
@end@
|
||
|
|
@elsif $ans2 == 2@
|
||
|
|
@eval $template = "array-user"@
|
||
|
|
@elsif $ans2 == 3@
|
||
|
|
@eval $template = mfd@
|
||
|
|
@else@
|
||
|
|
WARNING: Unknown response. Skipping code generation for tables.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
@elsif $ans1 != 4@
|
||
|
|
WARNING: Unknown response. Skipping code generation for tables.
|
||
|
|
@end@
|
||
|
|
|
||
|
|
@if $template ne NONE@
|
||
|
|
The same template code can be generated using
|
||
|
|
mib2c -c mib2c.${template}.conf $name
|
||
|
|
@run mib2c.${template}.conf@
|
||
|
|
@end@
|
||
|
|
@end@ # tables
|
||
|
|
|
||
|
|
@if $numN > 0@
|
||
|
|
**********************************************************************
|
||
|
|
GENERATING CODE FOR NOTIFICATIONS:
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
Would you like to generate code for sending notifications from within
|
||
|
|
the agent?
|
||
|
|
|
||
|
|
@prompt $ans "y" or "n": @
|
||
|
|
@if ("$ans" eq "y") or ("$ans" eq "yes")@
|
||
|
|
using mib2c.notify.conf to generate code for sending notifications
|
||
|
|
@run mib2c.notify.conf@
|
||
|
|
@end@
|
||
|
|
|
||
|
|
# GENERATING HEADER FILE DEFINITIONS
|
||
|
|
#
|
||
|
|
# To generate just a header with a define for each column number in
|
||
|
|
# your table:
|
||
|
|
#
|
||
|
|
# mib2c -c mib2c.column_defines.conf ${name}
|
||
|
|
#
|
||
|
|
# To generate just a header with a define for each enum for any
|
||
|
|
# column containing enums:
|
||
|
|
#
|
||
|
|
# mib2c -c mib2c.column_enums.conf ${name}
|
||
|
|
|
||
|
|
@end@ # notifications
|
||
|
|
@end@ # new style code
|
||
|
|
|
||
|
|
**********************************************************************
|
||
|
|
* NOTE WELL: The code generated by mib2c is only a template. *YOU* *
|
||
|
|
* must fill in the code before it'll work most of the time. In many *
|
||
|
|
* cases, spots that MUST be edited within the files are marked with *
|
||
|
|
* /* XXX */ or /* TODO */ comments. *
|
||
|
|
**********************************************************************
|