“Simple Network Management Protocol” is a relative term. To the uninitiated, raw SNMP output, along with arcane technobabble like “MIB” and “ASN.1,” looks a little daunting. Developing some understanding of how to parse and filter SNMP information doesn’t take long, though, and can put you on a fast track to making SNMP bend to your whim.
The first thing to know about SNMP is that it is a service that is structured such that an SNMP agent sitting on a target host can be queried by remote hosts for various bits of information. Only the target host (the one you want information about) needs to be running an SNMP daemon. The client making the queries just needs some tool capable of making SNMP queries and parsing the output. Most Linux server and client tools are supplied by the Net-SNMP project. A quick poke around your system to locate snmpwalk or snmpget should let you know in short order if you have the client tools installed. The server daemon is called, predictably, snmpd.
The easiest way to get familiar with how SNMP works is to set it up on your own Linux system. Since this might be the piece of machinery with which you are also the most familiar, it’ll also be a great way to see the sheer power of SNMP. Since most Linux distributions come with a Net-SNMP daemon, I’m going to forgo discussing installation and head right to configuration.
Configuring snmpd
If you maintain a lot of services, you’re probably tired of having to remember which directive handles what in all of the differently formatted config files. Apache, BIND, Sendmail, LDAP, NIS, NFS, and SSH all have different formats — and that’s just the beginning. You’ll be relieved to know that SNMP has a really great configuration tool called snmpconf. Veteran sysadmins will be happy to know that this is a command-line tool. New admins will have to suck it up!
Seriously, though, if you just want to get a very quick configuration put together, try running snmpconf -g basic_setup, and you’ll be able to set up what you need in order to see what the daemon has to offer. For those who have more than three minutes on their hands and want more control over the configuration, simply running snmpconf will prompt you with menus to configure the different aspects of the running daemon. The questions are very easy and completely self-explanatory (I’d even venture to say elementary) for any Linux or Unix sysadmin. Once you finish, move the resulting snmpd.conf file into place, and start the snmpd daemon.
Once the daemon is started, try pasting this into your terminal and pressing Enter: snmpwalk -v2c -c public localhost tcp. Here’s some output from my laptop:
TCP-MIB::tcpConnState.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.111.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.199.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.32768.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.25.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.631.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.32769.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.32776.127.0.0.1.631 = INTEGER: closeWait(8)
This is just a chunk of output, and as you can probably discern, it’s telling me which ports I have open (they’re in state “listen”). For the record, recent Net-SNMP packages come with a command called snmpnetstat that does this and more for you. But the point is that SNMP can tell you just about anything you want to know about the running system, but this output doesn’t reveal very much about SNMP itself.
Let’s alter the command like this: snmpwalk -On -v2c -c public localhost tcp. The -On flag tells the client to return the numeric OID or object ID string instead of abbreviating it using the MIB used to parse said OID. What’s an OID? Glad you asked. Let’s look at the output:
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.111.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.199.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.32768.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.25.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.631.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.32769.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.32776.127.0.0.1.631 = INTEGER: closeWait(8)
My favorite output flag, though, is -Of, which parses each of the numbers above into a human-readable (if very long) name.
The OID in the above output is everything before the equals-sign. It’s called an object ID because SNMP stores every piece of data as an object. Furthermore, those objects are identified internally as numbers, which get parsed into names on the client side, using a Management Information Base (MIB) file. A MIB is a human-readable text file which is actually extremely handy, since it contains all of the descriptions for the different pieces of data returned. If you’re not sure if a particular piece of data is what you’re looking for, heading for the MIB file that parsed it is usually a good way to find the answer.
For example, in the first output listing, you can see something called “tcpConnState.” At the very beginning of each line, you also see “TCP-MIB.” If you want to see a better description of what this value really means, you need to find a file on your system called TCP-MIB.txt; on my Fedora Core 2 machine, MIBs are in /usr/share/snmp/mibs. grep for “tcpConnState” in the file, and scroll down to the description to see what it says. NOTE: Descriptions aren’t always useful. Generally, though, the standard MIBs (i.e., not vendor-supplied ones) are good enough to get a clue.
So what’s with the long numbers as OIDs? That’s ASN.1 notation. Abstract Syntax Notation provides a standard way of describing data independent of any language or application. Agents are written to provide data using ASN.1, and client applications are written to handle that data in any language and in any way the developers see fit. The goal is generalization, and it would appear that it works. LDAP and SNMP both use ASN.1 notation, and the tools built around these two protocols (snmpwalk, ldapsearch, etc.) handle the task of making the output readable by humans. In LDAP parlance, a MIB is called a “schema.” The rest is very similar from a data representation perspective.
For SNMP data (as well as LDAP), the ASN.1 numbers actually represent a hierarchical structure — similar to the way the directory on your system is hierarchical in nature. In fact, you could look at the numeric output above, and think of .1 as the / or root directory. The fact that it’s followed by a 3 would seem to imply that there are at least two other nodes under that top-level node, and you’d be right in assuming that. The same goes for all of the numbers all the way down the line. In fact, you could think of the command snmpwalk -Of -v2c -c public localhost tcp as simply running ls -lR on the tcp directory within the hierarchy.
What SNMP can do for you
Here are some quick one-liners that illustrate some cool stuff about your system. These were tested on my FC2 laptop, as well as a SUSE 9.1 workstation:
* snmpwalk -Ov -OQ -v2c -c public localhost .1.3.6.1.2.1.25.6.3.1.2
This lists the names of every installed package on the machine. It essentially does the same thing as rpm -qa on an RPM-based distro, but it’s slightly easier to grab the information from a remote location using SNMP. There are lots of those -O flags available. The O stands for “output,” and you can stack them as I’ve done here in order to strip out everything but the actual value. For more on this, see the snmpcmd manpage.
* snmpwalk -Of -v2c -c public localhost interfaces | grep “.2 =”
This walks the interfaces directory and grabs anything pertaining to what amounts to “interface 2.” The interfaces are indexed numerically, and interface 1 is generally the loopback. For each interface, a host of values is displayed, so if you run something like this on a huge switch and aggregate and parse the data, you can create some extremely useful data.
* snmpwalk -OQ -Ov -v2c -c public localhost .1.3.6.1.2.1.25.4.2.1.2
This gets you a quick list of the programs running on a remote (or in this case, a local) host. The processes are also indexed, and you can get other information about them if you want to do a little scripting.
Plenty more where this came from
This is the tip of the iceberg. For avid scripters, I’ve used both the Perl and PHP SNMP interfaces, and both are immensely useful. Also, don’t think that SNMP is limited in use to Linux boxen; SNMP agents have been written for everything from large UPS units to tiny humidity sensors that’ll send a trap if your machine room starts to resemble a swampland. If there’s something in your environment with an Ethernet jack on it, there’s probably an SNMP agent for it.
I haven’t even mentioned the notion of actually making configuration changes via the snmpset command, but I urge you to investigate it for yourself. There’s a whole SNMP world out there waiting for you, and taking advantage of it can make your life as an administrator infinitely easier.
转载自：http://www.linux.com/archive/articles/113774