Difference between revisions of "TUT:mib2c-update"

From Net-SNMP Wiki
Jump to: navigation, search
(About mib2c-update)
m (Running mib2c-update: cleanup)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== About mib2c-update ==
 
== About mib2c-update ==
  
[[http://www.net-snmp.org/docs/man/mib2c.html mib2c] generates template code which you must customize. So what happens when the configuration file you chose is updated to fix a bug or add a new feature? Traditionally, you have had to manually merge the changes into your code, or merge your customizations into a freshly generated code set. (see pseudo-algorithm for the manual steps needed).  
+
[http://www.net-snmp.org/docs/man/mib2c.html mib2c] generates template code which you must customize. So what happens when the configuration file you chose is updated to fix a bug or add a new feature? Traditionally, you have had to manually merge the changes into your code, or merge your customizations into a freshly generated code set. (see pseudo-algorithm for the manual steps needed).  
  
 
The shell script mib2c-update is a wrapper around mib2c and other utilities to help you take advantage of updates to the configuration file you chose for your mib module without having to manually merge code changes.
 
The shell script mib2c-update is a wrapper around mib2c and other utilities to help you take advantage of updates to the configuration file you chose for your mib module without having to manually merge code changes.
Line 51: Line 51:
 
  ... XXX: EXAMPLE RUN HERE ...  
 
  ... XXX: EXAMPLE RUN HERE ...  
  
Once you have generated the code, I strongly recommend that you check it in to a source code [http://en.wikipedia.org/wiki/Version_control version control] system, such as CVS, Subversion, RCS, ClearCase or (shudder) Microsoft SourceSafe. This will help you recover if a bug in mib2-update causes any problems. Both the current and original directories should be put under version control.
+
Once you have generated the code, it is strongly recommended that it be checked in to a source code [http://en.wikipedia.org/wiki/Version_control version control] system, such as CVS, Subversion, RCS, ClearCase or (shudder) Microsoft SourceSafe. This will help you recover if a bug in mib2-update causes any problems. Both the current and original directories should be put under version control.
  
== Running mib2c-update==
 
 
If you are trying to use mib2c-update after the fact (i.e. you originally generated you code with mib2c directly), you have to do a little work to be able to use mib2c-update.
 
 
... XXX: TBD ...
 
 
 
== Manual updates ==
 
== Manual updates ==
  

Latest revision as of 01:08, 27 January 2009

About mib2c-update

mib2c generates template code which you must customize. So what happens when the configuration file you chose is updated to fix a bug or add a new feature? Traditionally, you have had to manually merge the changes into your code, or merge your customizations into a freshly generated code set. (see pseudo-algorithm for the manual steps needed).

The shell script mib2c-update is a wrapper around mib2c and other utilities to help you take advantage of updates to the configuration file you chose for your mib module without having to manually merge code changes.

If all goes well, there might not be any conflicts. If you changed any configuration option, or there were lots of changes to the configuration files, you may have to do quite a bit of manual patching.

Basic Configuration

mib2c-update does not take any command-line parameters. All configuration information is kept in the file .mib2c-updaterc in the directory where the code is generated. This configuration file needs to contain two pieces of information: the table name, and the mib2c configuration file to use. The format is:

 #
 # example mib2c-update configuration file
 #
 
 # UPDATE_OID should contain the table for which code will be generated
 #
 UPDATE_OID=ipAddressTable
 
 #
 # UPDATE_CONF should contain the mib2c configuration file to be used
 #
 UPDATE_CONF=mib2c.mfd.conf

Those are the only required options. If you want to pass additional arguments to mib2c, you can set the options in UPDATE_MIB2C_OPTS:

 UPDATE_MIB2C_OPTS="-q -f ipAddress"

You can also configure the directories that mib2c-update will use to generate temporary code. The available options, and their defaults, are:

UPDATE_CURR=.
Determines where the current code is. The default is the current working directory.
UPDATE_ORIG=.orig
Determines where the original template code is. In this case, originial means the template used for the code in current.
UPDATE_NEW=.new
Determines where the new template code should be generated.
UPDATE_PATCH=.patch
Determines where the template and custom code patches should be generated.
UPDATE_MERGED=.merged
Determines where the merging of the new code with the patches should occur.
UPDATE_BACKUP=.backup
Determines where the current and original code will be backed up.

Running mib2c-update

Note: if you are trying to use mib2c-update after the fact (i.e. you originally generated you code with mib2c directly) skip ahead to using mib2c-update retroactively.

The first run of mib2c-update is very easy. Simply create your configuration file, .mib2c-updaterc, as described above, and then run mib2c-update. The temporary directories will be created, and mib2c will be run to generate the initial code.

... XXX: EXAMPLE RUN HERE ... 

Once you have generated the code, it is strongly recommended that it be checked in to a source code version control system, such as CVS, Subversion, RCS, ClearCase or (shudder) Microsoft SourceSafe. This will help you recover if a bug in mib2-update causes any problems. Both the current and original directories should be put under version control.

Manual updates

If you want to manage the process manually, it goes something like this:

  1. In a new directory (eg orig), generate the code for your table using the same mib2c configuration file and options that were originally used to generate the code.
  2. use diff to compare the unmodified template code to your existing code, and save the output to create a patch of your changes.
  3. in a new directory (eg new), generate the code for your table using the updated mib2c configuration files, but with the same options that were originally used to generate the code.
  4. use diff to compare the original template code to the updated template code, and save the output to create a patch of the configuration file changes.
  5. copy the new code to a new directory (eg merge), and apply the configuration file patch.
  6. apply your custome changes patch to the merge directory
  7. resolve any conflicts or failed patches.

Tutorial Sections

About the SNMP Protocol

These tutorial links talk about SNMP generically and how the protocol itself works. They are good introductory reading material and the concepts are important to understand before diving into the later tutorials about Net-SNMP itself.

Net-SNMP Command Line Applications

These tutorial pages discuss the command line tools provided in the Net-SNMP suite of tools. Nearly all the example commands in these tutorials works if you try it yourself, as they're all examples that talk to our online Net-SNMP test agent. Given them a shot!

Application Configuration

All of our applications support configuration to allow you to customize how they behave.

Net-SNMP Daemons

Net-SNMP comes with two long-running daemons: a SNMP agent (snmpd) for responding to management requests and a notification receiver (snmptrapd) for receiving SNMP notifications.

Coding Tutorials

Net-SNMP comes with a highly flexible and extensible API. The API allows you to create your own commands, add extensions to the agent to support your own MIBs and perform specialized processing of notifications.

Debugging SNMP Applications and Agents

All our tools and applications have extensive debugging output. These tutorials talk about how the debugging system works and how you can add your own debugging statements to you code:

Operating System Specific Tutorials