Well, after struggling half the day I finally (well, almost) have SNMP and MRTG working well together on Coyote (Linux coyote 2.4.26-1-386). The problem was that I couldn't seem to read any interesting information (network statistics, CPU usage, etc.) using SNMP. All I could do was get the basic stuff in the system tree like contact information. So here is a hopefully half decent writeup.

INITIAL PROBLEM
Using the Debian snmpd package in combination with the mrtg package produces graphs of no activity.

SYMPTOMS

• MRTG displays no network activity out of the box, although that is clearly not really the case.
• Doing a simple manual lookup of CPU usage like this:
  snmpgetnext -v2c -c public localhost ucdavis.version.versionTag
  returns an "End of MIB" message instead of data

CAUSES
Out of the box -- after running the "snmpconf -g basic_setup" command -- the access controls are set to be pretty restrictive. When prompted by snmpconf, I chose to call my community name "public" at first, so if you've done it differently the examples below might be different for you.

Here's what the access portion of /etc/snmp/snmpd.conf looked like for me:

####
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):

#       sec.name  source          community
com2sec paranoid  default         public
#com2sec readonly  default         public
#com2sec readwrite default         private

####
# Second, map the security names into group names:

#               sec.model  sec.name
group MyROSystem v1        paranoid
group MyROSystem v2c       paranoid
group MyROSystem usm       paranoid
group MyROGroup v1         readonly
group MyROGroup v2c        readonly
group MyROGroup usm        readonly
group MyRWGroup v1         readwrite
group MyRWGroup v2c        readwrite
group MyRWGroup usm        readwrite

####
# Third, create a view for us to let the groups have rights to:

#           incl/excl subtree                          mask
view all    included  .1                               80
view system included  .iso.org.dod.internet.mgmt.mib-2.system

####
# Finally, grant the 2 groups access to the 1 view with different
# write permissions:

#                context sec.model sec.level match  read   write  notif
access MyROSystem ""     any       noauth    exact  system none   none
access MyROGroup ""      any       noauth    exact  all    none   none
access MyRWGroup ""      any       noauth    exact  all    all    none

You can see in the first section that the source/community pair of "default"/public are assigned to a name of "paranoid". In the second section, the "paranoid" name is assigned to the "MyROSystem" group. In the fourth (skipping third for now) section, the MyROSystem group is granted read access only to the "system" view that was created in the third section. The end result is that people coming from "default" (anywhere, I think) using the community name "public" will only be able to see the system section and nothing else. So that's the problem I was running in to.

SOLUTION
The best thing to do, in my opinion, is to create a edit /etc/snmpd/snmpd.local.conf and create a new set of access rights with access to everything. Note that you'll need to use a DIFFERENT source/community pair if you're going to leave snmpd.conf alone. The reason is that if you have two source community pairs that are the same, only the first one will be used. Since snmpd.conf is read first, it'll probably be reading the wrong one. In any case, it's good to have a community name other than the default of "public", so the best thing to do is create new rights for a new community name. Also in my example, I've restricted the source so that only localhost has rights to see everything. Here's what I have in snmpd.local.conf:

####
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):

#       sec.name  source          community
com2sec localro   localhost       newcommunityname

####
# Second, map the security names into group names:

#               sec.model  sec.name
group MyROGroup v1         localro
group MyROGroup v2c        localro
group MyROGroup usm        localro
# I took a shortcut here. The MyROGroup is already defined in snmpd.conf and has permissions to read everything, which is what we want. Instead of creating a new group I just reused this one.

####
# Third, create a view for us to let the groups have rights to:

#           incl/excl subtree                          mask
# Nothing changes here...

####
# Finally, grant the group access to the 1 view with different
# write permissions:

#                context sec.model sec.level match  read   write  notif
# Nothing changes here, either...

Then just restart the snmpd daemon with "/etc/init.d/snmpd reload" and viola, it works.