Developing SMUX peers for SNMP agents

MIB modules

The first task in implementing an SMUX peer is to create the MIB module that the peer registers. It contains the variables used to configure or administer the device to be managed. This topic describes how to define a MIB module and compile it so that the peer can read it. It also describes the syntax of a compiled module.

Defining MIB modules

First, write a MIB module to define the actual managed objects which the SMUX peer is to manage. RFC 1212 ``Concise MIB Definitions'' defines a format for writing MIB modules; you may find it a useful place to start While describing these rules is not within the scope of this topic, you may find some of the following basic information helpful.

Define the MIB module in a file called .my; for the reference peer, the file is called foosmuxd.my. MIB modules fall into 3 broad categories:

If you are defining a MIB module for something specific to a UNIX system, it should probably go under the BSD UNIX MIB. Contact Marshall Rose or Keith Sklower to get a number under the UNIX enterprise tree; refer to ``References'' for address information. In this case, the definition might start something like this:
```
SendMail-MIB { iso(1) org(3) dod(6) internet(1) private(4)
               enterprises(1) unix (4) sendmail (99) }

DEFINITIONS ::= BEGIN

IMPORTS
        unix --*, OBJECT-TYPE *--
            FROM RFC1155-SMI;

sendMail OBJECT IDENTIFIER ::= { unix 99 }
```
If you are defining a MIB module on a multilateral, experimental basis (for example, for a protocol like the NTP), then you should contact the Internet Assigned Numbers Authority (iana@isi.edu) and ask for an experimental number. In this case, the definition might start something like this:
```
FOO-MIB DEFINITIONS ::= BEGIN

IMPORTS
        experimental, OBJECT-TYPE
            FROM RFC1155-SMI;

foo OBJECT IDENTIFIER ::= { experimental 99 }
```
In most cases, you will be defining a MIB module for something specific to your enterprise. You should contact the Internet Assigned Numbers Authority (iana@isi.edu) and ask for an enterprise number (assuming you do not already have one). In this case, the definition might begin as does our example in foosmuxd.my:
```
FOO-MIB DEFINITIONS ::= BEGIN

IMPORTS
        enterprises, OBJECT-TYPE
            FROM RFC1155-SMI;

foo OBJECT IDENTIFIER ::= { enterprises 9999 }
```

In any event, the final OBJECT IDENTIFIER points to the root of the tree that your program is going to manage. foo is the root of the subtree managed by foosmuxd. For simplicity's sake, foosmuxd manages the entire foo MIB. In real life, this would not be the case because it precludes other peers from managing subtrees of the foo MIB.

Following this start, you have the actual definitions of the MIB objects, followed by

END

Compiling MIB modules

Once you have defined a MIB module, you can compile it. This step is not absolutely necessary, because the make command runs the mosy compiler automatically when make compiles the entire peer program (see ``Compiling an SMUX peer''). You can invoke make on the MIB module to verify that mosy will compile the module into a form that the peer program can read. The command to run mosy on foosmuxd.my is:

make -f foosmuxd.mk foosmuxd.defs

Replace the string ``foo'' with the identifying string for your peer.

The syntax of the compiled module foosmuxd.defs is:

Comments start with ``--'' or ``#'' at the beginning of a line.
Object identifiers are defined thus:

# # #name value # internet iso.3.6.1
Object types are defined thus:

# # #name oid syntax access status # productName serialBoard.1 DisplayString read-only mandatory
where ``name'' and ``oid'' are obvious. For the rest:
- ``syntax'' is the name of a defined syntax
- ``access'' is one of read-only, read-write, or none
- ``status'' is one of mandatory, optional, deprecated, or obsolete
Names of objects are always case-sensitive.

Run the post_mosy program on the compiled output to produce an ASCII file containing the names and numeric object identifiers of each object in the compiled output.

post_mosy -i foosmuxd.defs

The resulting ASCII file looks something like this:

"ccitt"		"0"
"iso"	"1"
"internet"	"1.3.6.1"
"directory"	"1.3.6.1.1"
"mgmt"	"1.3.6.1.2"
"experimental"	"1.3.6.1.3"
"private"	"1.3.6.1.4"
"enterprises"	"1.3.6.1.4.1"
"foo"	"1.3.6.1.4.1.9999"
"serialBoard"	"1.3.6.1.4.1.9999.1"
"productName"	"1.3.6.1.4.1.9999.1.1"
"boardStatus"	"1.3.6.1.4.1.9999.1.2"
"exampleIpAddr"	"1.3.6.1.4.1.9999.1.3"
"exampleObjectID"	"1.3.6.1.4.1.9999.1.4"
"numberLines"	"1.3.6.1.4.1.9999.1.5"
"serialLineTable"	"1.3.6.1.4.1.9999.1.6"
"serialLineEntry"	"1.3.6.1.4.1.9999.1.6.1"
"serialLineNumber"	"1.3.6.1.4.1.9999.1.6.1.1"
"serialLineBaudRate"	"1.3.6.1.4.1.9999.1.6.1.2"
"serialLineTermLocation"	"1.3.6.1.4.1.9999.1.6.1.3"
"joint-iso-ccitt"	"2"

This output file is meant to be read as configuration data by network management utilities.

Instead of running mosy and post_mosy separately on the command line, run the /usr/sbin/mibcomp.sh script. This runs the two utilities on one or more specified object modules, adding a number of object definitions to the ASCII file. For details, see the mibcomp(1Msnmp) manual page.