mrtg unwilling to get some information from my machine.
Ariel Burbaickij
Unfortunately , only thing I get is the default in/out bytes per interface.
I loaded the neccesary MIB (UCD-SNMP-MIB) but it was of no avail.
Information is indeed maintained by the machine(i.e. I can get the information
I am interested in by means of snmpget) .
How is it possible to see what mrtg tries to do during retrieval and see the
relevant debug information in case something indeed runs amiss ?
Regards
Jeff Liebermann
begin mini-rant()
What operating system are you running UCD-SNMP?
What version?
What version of MRTG?
end mini rant()
My guess is that you have RedHat 6.x which is delivered with a highly
secure but useless UCD-SNMP sercurity arrangement. If finally got fed up
decided to fix it. Edit /etc/snmp/snmpd.conf and make it look something
like the following. Be sure to tweak you community names and LAN IP
address. Test with:
snmpwalk localhost public iso
You should get pages and pages and pages and pages and pages of OID's.
Note the MRTG only does V1 security.
I just threw this together with limited testing, so I'm not 100% sure
it's perfect or optimum.
###############################################################################
# /etc/snmp/snmpd.conf:
# Sample for RedHat 6.1
# by Jeff Liebermann 02/08/2001
###############################################################################
# System contact information
syscontact je...@comix.santa-cruz.ca.us
syslocation Ben Lomond
###############################################################################
#
# The rules:
# localhost has read and write access.
# local class C network has read and write access.
# Everyone else gets just the system group.
#
# sec.name source community
com2sec Mybox localhost public
com2sec LocalLan 192.168.111.0/24 public
com2sec Outside default public
#
# group.name sec.model sec.name
group RWGroup V1 Mybox
group ROGroup V1 LocalLan
group Others V1 Outside
#
# incl/excl subtree mask
view all included .1 80
view system included system fe
#
# context sec.model sec.level prefix read write notif
access ROGroup "" V1 noauth exact all none none
access RWGroup "" V1 noauth exact all all all
access Others "" V1 noauth exact system none all
###############################################################################
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Dave Shield
Jeff Liebermann <je...@comix.santa-cruz.ca.us> writes:
|> I just threw this together with limited testing, so I'm not 100% sure
|> it's perfect or optimum.
[snip]
Niels is our expert on the access control stuff, but I'd say that looks
more or less what I'd expect. (With the appropriate value for the local
network address, of course).
The only thing I'd question would be the 'Others' notification access:
|> # context sec.model sec.level prefix read write notif
|> access ROGroup "" V1 noauth exact all none none
|> access RWGroup "" V1 noauth exact all all all
|> access Others "" V1 noauth exact system none all
^^^
I'd probably simply have
access Others "" V1 noauth exact system none none
^^^^
but I don't believe anything actually uses this field yet, so it doesn't
really matter anyway.
(That's one more thing to look at when we redo the trap generation code!)
Dave
--
Dave Shield D.T.S...@csc.liv.ac.uk
Dept. of Computer Science,
Liverpool University, "He who brings [computers] on to his premises
PO Box 147, should be absolutely liable ... for any mischief
Liverpool, L69 7ZF that ensues." Haddock v. Computer 1578/32/W1
Jeff Liebermann
>|> # context sec.model sec.level prefix read write notify
>|> access ROGroup "" V1 noauth exact all none none
>|> access RWGroup "" V1 noauth exact all all all
>|> access Others "" V1 noauth exact system none all
> ^^^
>I'd probably simply have
>
> access Others "" V1 noauth exact system none none
> ^^^^
>but I don't believe anything actually uses this field yet, so it doesn't
>really matter anyway.
Thanks, you're right. I think "notify" controls who can initiate traps,
but I'm not sure.
I also screwed up in my description where I declared that the local Class
C lan and read and write, but set it up for ROGroup which can only read.
# The rules:
# localhost has read and write access.
# local class C network has read only access.
# Everyone else gets just the system group.
Note that UCD-SNMP is now Net-SNMP located at:
http://net-snmp.sourceforge.net
with docs for snmpd.conf at:
http://net-snmp.sourceforge.net/man/snmpd.conf.html
Dave Shield
Jeff Liebermann <je...@comix.santa-cruz.ca.us> writes:
|> On Fri, 9 Feb 2001 14:41:41 GMT, da...@csc.liv.ac.uk (Dave Shield) wrote:
|> >I'd probably simply have
|> >
|> > access Others "" V1 noauth exact system none none
|> > ^^^^
|> >but I don't believe anything actually uses this field yet, so it doesn't
|> >really matter anyway.
|>
|> Thanks, you're right. I think "notify" controls who can initiate traps,
|> but I'm not sure.
That's the intention according to RFC 2575, certainly.
So it ought to apply to 'snmptrap' (which doesn't read snmpd.conf anyway),
and the trap-generation aspects of 'snmpd' (which does read this file, but
doesn't take any notice of the VACM settings when it comes to generating traps).
We may change this when we re-write that bit of the agent - but at the moment,
I'm pretty much 100% confident that this value is never used.
|> I also screwed up in my description where I declared that the local Class
|> C lan and read and write, but set it up for ROGroup which can only read.
So you did - never mind, no-one reads comments anyway!