[2]Don't blindly follow this example, or I'll look for anything interesting in your logs and post it in some prominent public location. Do not log to someone else's logging host!

Reporting with SNMP

The report emails are good, but they're very general, and logs are difficult to read for long−term trends. To learn more about how your server is doing, either now or in the long term, use the Simple Network Management Protocol (SNMP) reporting tool. SNMP is an industry−standard way to gather information from hosts across a network. Many different vendors support SNMP, and you can use the techniques we discuss here to monitor any SNMP−speaking device.

You can use free tools to tell SNMP to generate nice, pretty pictures of how well your system is working. To use those tools effectively, however, you must have some basic understanding of what SNMP is and how it works. Once you understand that, we'll consider the most popular set of SNMP tools for FreeBSD.

Basics of SNMP

SNMP works on a standard client/server model. The SNMP client, or agent, sends a request across the network to an SNMP server running on a computer. The SNMP server, snmpd, then gathers information from the local system and returns it to the client.

An SNMP agent can also send a request to make changes to the SNMP server. If your system is properly (or improperly, depending on your point of view) configured, you can issue commands via SNMP. This "write" configuration is most commonly used in routers, switches, and other network devices.

UNIX has its own configuration system, and doesn't usually let you issue instructions via SNMP. (Some daemons might allow you to configure them via SNMP, and you can write shell scripts to be called by setting an SNMP value, but those are special cases.) For our purposes, we don't want to be able to write configurations at all. Writing system configurations or instructions via SNMP requires careful setup and raises all sorts of security issues; it's an excellent topic for an entire book.

MIBs

SNMP manages its information via a Management Information Base, or MIB. (We saw an example of a MIB tree in Chapter 4, when discussing sysctls.)

Each SNMP server has a list of information it can extract from the local computer. The server arranges these bits of information into a hierarchical system, or Management Information Base tree. Each SNMP MIB tree has a very general main category, network, physical system, programs, and so on, with more specific subdivisions. Think of these trees as well−organized directories, where subdirectories contain more specific information. Similarly, the uppermost MIB contains a variety of MIBs beneath it.

MIBs are referred to by name or by number. For example, here's a MIB pulled off a sample system:

...............................................................................................

interfaces.ifTable.ifEntry.ifOutErrors.1

...............................................................................................

The first term in this MIB, interfaces, shows us that we're looking at the network interfaces on the system (network cards, parallel ports, and so on). If there were no interfaces on this particular

433

system, this first category would not even exist. The ifTable is the interface table, or a list of all the interfaces on the system. ifEntry shows one particular interface, and ifOutErrors means that we're looking at the outbound errors on this particular interface. Finally, the trailing 1 means that we're interested in interface number 1.

MIBs can also be expressed as numbers, and most SNMP tools prefer numerical MIBs. Unfortunately (or not) our feeble brains prefer words, but your poor brain must be capable[3] of working with either. (We'll learn exactly how to do this translation with a particular piece of software in the section "Translating Between Numbers and Names"; for now, just trust me.) The preceding example can be translated to this:

...............................................................................................

.1.3.6.1.2.1.2.2.1.20.1

...............................................................................................

Expressed as words, the MIB has five terms separated by periods. Expressed as numbers, the MIB has 11. That doesn't look right if they're supposed to be the same. What gives?

The numerical MIB is longer because it includes the default .1.3.6.1.2.1, which means

.iso.org.dod.internet.mgmt.mib−2. This is the standard subset of MIBs used on the Internet (SNMP could also be used to manage non−Internet devices). Almost every MIB you encounter will have this leading string, which is why almost nobody bothers writing it down anymore.

If you're in one of those kinky moods, you can even mix words and numbers:

...............................................................................................

.1.org.6.1.mgmt.1.interfaces.ifTable.1.ifOutErrors.1

...............................................................................................

These MIBs look useful, but how do you find out what each one means? SNMP MIBs can vary from device to device and with the server used. Check the documentation for your SNMP agent, or your device, to see which MIBs are available.

When you make an SNMP query, you'll use the MIB to extract exactly the information you want. Since most networked devices shouldn't give out information to just anyone, let's look at how SNMP provides basic security with communities.

Net−snmp

Net−snmp (http://net−snmp.sourceforge.net/) is the best set of SNMP programs that runs on FreeBSD. It's small, extensible, and efficient, and it's included as a FreeBSD port (/usr/ports/net/net−snmp4). This is a popular package, and the port is generally quite up to date because the net−snmp folks are actively interested in FreeBSD and are quite responsive to useful problem reports, requests for help, or (better still) patches.

Note Just to make things slightly difficult, net−snmp was previously called ucd−snmp. The University of California at Davis is no longer quite so involved in the project, hence

434

the name change. You'll see references to both net−snmp and ucd−snmp.

When you install net−snmp from ports, the build process will ask you several different questions. Go ahead and accept the defaults; you can override them later with the configuration file we'll create.

The net−snmp port includes an SNMP client, an SNMP server, and a translation tool. We'll consider each in turn.

Snmpwalk

The net−snmp port includes a generic tool, snmpwalk(1), that you can use to examine the SNMP tree on other hosts. Snmpwalk works well on any sort of server: I use my FreeBSD system to snmpwalk Cisco routers, assorted switches, other BSD machines, and even Windows−based systems. To use snmpwalk, give it the name of the host you want to check and the SNMP community name:

...............................................................................................

# snmpwalk hostname community

...............................................................................................

Try snmpwalk on a system running an SNMP daemon, using the default community of "public":

...............................................................................................

# snmpwalk hostname public > snmpwalk.out

#

...............................................................................................

The snmpwalk command generates a lot of output, so in this example we've redirected it to a file. Look at the output. You may be surprised at the amount of information a system offers via SNMP.

Specific Snmpwalk Queries

You can also make very specific queries via SNMP simply by specifying the portion of the tree you're interested in. For example, suppose you want to know the value of the MIB

.1.3.6.1.4.1.2021.11.9.0. (This is the percentage of CPU time spent on user programs when running the net−snmp server. The next section tells us how to get that information.) You can add this MIB to the end of your snmpwalk query to just ask about that MIB.

...............................................................................................

#snmpwalk localhost public .1.3.6.1.4.1.2021.11.9.0

enterprises.ucdavis.systemStats.ssCpuUser.0 = 1

#

...............................................................................................

This tells me that 1 percent of my system CPU time is being spent running user programs. Nifty, eh?

You can use snmpwalk to get information from any device that speaks SNMP. For example, the Windows NT documentation tells us that the MIB 1.3.6.1.4.1.311.1.1.3.1.1.1.1 represents available memory. How about using snmpwalk from your FreeBSD system to check this value

435

without bothering to log on to the NT system? Try this:

...............................................................................................

# snmpwalk windowsserver public .1.3.6.1.4.1.311.1.1.3.1.1.1.1.0

enterprises.311.1.1.3.1.1.1.1.0 = 154447872

#

...............................................................................................

It can be much simpler to use specific queries like this than it would be to log into a system to run top; and these queries work on any system with SNMP tools. Later, we'll automatically query servers by MIB and use the results to generate our pretty graphs of server status.

Commercial solutions for checking SNMP servers run to hundreds or thousands of dollars. Using these free SNMP tools is an excellent way to begin using FreeBSD on any network.

Translating Between Numbers and Names

So you want to know how to translate between the numbers and the words? And you wonder what MIBs are available on your system and perhaps even what they mean? Well, that's not entirely unreasonable. The net−snmp port includes the translation tool snmptranslate(1).

First, choose a MIB that you want to translate. You have the output of an snmpwalk run on your system saved, right? Well, let's pluck a bit of output from it and see what we have. I'll pick the following line from my local system:

...............................................................................................

enterprises.ucdavis.memory.memAvailSwap.0 = 204672

...............................................................................................

This looks important, doesn't it? Available swap would be handy to know.

To begin with, you need to know that snmpwalk gives only the last section of the MIB. You have to know that the enterprises tree is always prefaced by .1.3.6.1.4. (This is common knowledge in the SNMP world.) Now, armed with that esoteric knowledge, give this full MIB, and the −Td switch, to snmptranslate:

...............................................................................................

# snmptranslate −Td .1.3.6.1.4.enterprises.ucdavis.memory.memAvailSwap.0

.1.3.6.1.4.1.2021.4.4.0

memAvailSwap	OBJECT−TYPE
−− FROM	UCD−SNMP−MIB
SYNTAX	INTEGER
MAX−ACCESS	read−only
STATUS	current
DESCRIPTION	"Available Swap Space on the host."

::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) ucdavis(2021) memory(4) memAva

#

...............................................................................................

This gives you a heap of useful information about the MIB, including its numerical equivalent (.1.3.6.1.4.1.2021.4.4.0) and its description ("Available Swap Space on the host."). Note the numerical MIB; we'll need it soon. The last tidbit is the name of each part of the MIB and its

436