Update of /cvsroot/leaf/doc/howto/dachstein
In directory sc8-pr-cvs1:/tmp/cvs-serv7373
Added Files:
mrtg-logging.html
Log Message:
converted to html, changed dublerfamily links to sourceforge
--- NEW FILE: mrtg-logging.html ---
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>Mrtg logging for Dachstein/LEAF</TITLE>
<META NAME="Template" CONTENT="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot">
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080">
<B><FONT SIZE=4><P>Mrtg logging for Dachstein/LEAF (rev 3/11/02)</P>
</B></FONT><FONT SIZE=2><P>Pete Dubler ([EMAIL PROTECTED])</P>
<B><P>Scope:</B> Provide a helpful guide to getting the necessary stuff in place to
run mrtg logging of a Dachstein/LEAF system. Mrtg is run on another linux system (in
my case Redhat 7.1). Mrtg is highly configurable and flexible. One can log anything
from network traffic to weather history with mrtg. We will only worry about getting a
Dachstein-based LEAF router set-up to be accessed by another system which is running
mrtg.</P>
<P>Appendix A provides information on using mrtg to remotely log signal strength and
quality for a Cisco Aironet 802.11b wireless lan card in your Dachstein system.</P>
<B><P>Concept:</B> Mrtg provides a full set of automatically scaled, automatically
updated graphs for each NIC specified on a given router. Mrtg automatically assembles
the graphs into a web page for each NIC. The router must be running a version of snmpd
to allow mrtg to gather the necessary information. The html files generated by mrtg
are most easily accessed if the mrtg server has a web server (like apache). </P>
<B><P>Files Needed: </P>
</B><P>	<B>On the router:</P><DIR>
<DIR>
</B><P>netsnmpd.lrp, libm.lrp, and libdb.lrp available from:</P>
</FONT><P><A HREF="http://www.dublerfamily.com/leaf/mrtg"><FONT
SIZE=2>http://leaf.sourceforge.net/devel/petedd/</FONT></A></P>
<FONT SIZE=2><P>(This is the most complete and functional version I have found and
includes my edited <BR>
snmpd.conf file). This .conf file is also a great reference as it is loaded with
comments and explanations. (It also has the hooks in it, ready to be un-commented, for
implementing radio signal logging)</P></DIR>
</DIR>
<P>	<B>On the mrtg server:</P>
</B><P>	perl (must be running on your server since large parts of mrtg are written
in perl</P>
<P>	mrtg </P>
<P>	You can build it from source from: </FONT><A
HREF="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/"><FONT
SIZE=2>http://people.ee.ethz.ch/~oetiker/webtools/mrtg/</FONT></A></P>
<FONT SIZE=2><P>	OR, you can find an rpm and get on the air right away� </FONT><A
HREF="http://www.rpmfind.net/"><FONT SIZE=2>http://www.rpmfind.net</FONT></A></P>
<FONT SIZE=2><P>	</P>
<B><P>Documentation Recommended:</P>
</B><P>The following documentation tells you how to build mrtg, but also provides
valuable configuration and start-up information: </FONT><A
HREF="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/unix-guide.html"><FONT
SIZE=2>http://people.ee.ethz.ch/~oetiker/webtools/mrtg/unix-guide.html</FONT></A></P>
<B><FONT SIZE=2><P>Information Needed:</P>
</B><P>	You must have the following information available:</P>
<UL>
<UL>
<LI>IP address of interfaces on router you wish to monitor. </LI>
<LI>IP address of the server on which you will be running mrtg.</LI></UL>
</UL>
<OL>
<B><LI>Adding snmp to Dachstein:</LI></OL>
<UL>
<UL>
</B><LI>Download netsnmpd.lrp, libm.lrp, and libdb.lrp files listed above. Save them
on your Dachstein system where all of your other .lrp files are saved. </LI>
<LI>Edit syslinux.cfg on Dachstein system. Add netsnmpd, libm, and libdb to list of
lrps loaded. (NOTE: If the length of the lines in your syslinux.cfg file must not
exceed 256 characters or the lrp's will not load correctly. There is a workaround in
the Dachstein release, and a generic workaround, written by Jim Moy, in Appendix B..)
</LI>
<LI>Reboot Dachstein system </LI>
<LI>Check that netsmnpd is running by looking for smnpd in output of: </FONT><FONT
FACE="Courier New" SIZE=2>ps �ef </FONT><FONT SIZE=2>If it is not running, you can
start it via: <BR>
</FONT><FONT FACE="Courier New" SIZE=2>/etc/init.d/smnpd start</FONT><FONT SIZE=2> <BR>
If it is running, you can restart it via:<BR>
</FONT><FONT FACE="Courier New" SIZE=2>/etc/init.d/snmpd restart</LI></UL>
</UL>
</FONT><FONT SIZE=2><P> </P>
<OL START=2>
<B><LI>Configuring for snmpd on Dachstein:</LI></OL>
<UL>
<UL>
</B><LI>On the Dachstein system, run lrcfg. Select network, edit
network.conf:</LI></UL>
</UL>
<DIR>
<DIR>
<DIR>
<DIR>
<P>- Set SNMP_BLOCK=NO in /etc/network.conf so the firewall isn't blocking ports
161:162.</P></DIR>
</DIR>
</DIR>
</DIR>
<UL>
<UL>
<LI>Set SNMP_MANAGER_IPS, to the IP of the machine on which you will be running mrtg .
</LI>
<LI>Don�t change anything in the modules configuration for snmp. It will work great as
is..</LI></UL>
</UL>
<OL START=3>
<B><LI>Install mrtg on server:</LI></OL>
<UL>
<UL>
</B><LI>Here you are kinda on your own. The simplest method is to find an rpm for your
system and run "</FONT><FONT FACE="Courier New" SIZE=2>rpm �i</FONT><FONT SIZE=2>" on
it. </LI></UL>
</UL>
<OL START=4>
<B><LI>Configure mrtg on server:</LI></OL>
<UL>
<UL>
</B><LI>You now just have to edit the mrtg.conf file to tell it what router to monitor
and how often. My mrtg.conf file lives in /etc/mrtg (yours may be elsewhere). Edit the
file as follows:</LI></UL>
</UL>
<DIR>
<DIR>
<DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=2><P># mrtg.cfg</P>
<P>WorkDir: /var/www//html/mrtg #this is as directory on your web server </P>
<P>Options[_]: growright,bits #this makes the charts grow from l to r</P>
<P>RunAsDaemon: Yes			#you can choose yes or no, see doc</P>
<P>Interval: 5				#probe router every 5 minutes</P>
<P>Target[fwext]: /123.456.123.456:[EMAIL PROTECTED]</P>
<P>MaxBytes[fwext]: 1250000</P>
<P>Title[fwext]: Stats for External</P>
<P>PageTop[fwext]: <H1>Stats for External</H1></P>
<P># end of mrtg.cfg</P></DIR>
</DIR>
</DIR>
</DIR>
</FONT><FONT SIZE=2><P> </P>
<P>	123.456.123.456 is the ip of the port of the router you will be monitoring (eg.
the external port {eth0})</P>
<P>	123.555.666.777 is the ip of the port of the router that your mrtg server can
access (eg. the internal port {eth1})</P>
<P>	fwext is the name you assign for mrtg to use for the files it will store
related to these statistics</P>
<P>	The Title and PageTop are up to you. Keep it simple at first.</P>
<P>	NOTE: There must be no spaces at the beginning of each line of the mrtg.conf
file for the parameters to take.</P>
<OL START=4>
<B><LI>Run mrtg:</LI></OL>
<UL>
<UL>
</B><LI>I can�t add any value here. Please just read the RUNNING MRTG section of the
above referenced documentation:</LI></UL>
</UL>
<DIR>
<DIR>
</FONT><P><A
HREF="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/unix-guide.html"><FONT
SIZE=2>http://people.ee.ethz.ch/~oetiker/webtools/mrtg/unix-guide.html</FONT></A></P></DIR>
</DIR>
<B><FONT SIZE=2><P>6 �</B> <B>View mrgt files via server�s web server.</B> Files will
have names like fwext.html (based on the on the name you assigned in step 4 above.
Wow! Can you believe how easy it was to create such detailed, auto-scaling,
auto-updating graphic web pages!</P>
<P>You can do lots more with mrtg, just check out the mrtg website: </FONT><A
HREF="http://www.mrtg.org/"><FONT SIZE=2>www.mrtg.org</FONT></A><FONT SIZE=2> for more
ideas.</P>
</FONT><B><P>APPENDIX: A:</B> <B>Using MRTG to Log Signal Strength and Quality on a
Wireless Dachstein LEAF </P>
</B><FONT SIZE=2><P>Mrtg is very versatile and can log just about anything
graphically. There is a great document on this at: </P>
</FONT><P><A HREF="http://www.willy.com/Scripps/mrtg-data.html"><FONT
SIZE=2>http://www.willy.com/Scripps/mrtg-data.html</FONT></A></P>
<FONT SIZE=2><P>In less than two pages, Willy describes how to log other data using
mrtg. I will leverage that to document how I remotely log the signal strength and
quality of my Cisco Aironet ISA-342 card.</P>
<B><P>CONCEPTS:</B> Snmpd has the ability to execute a command on the target system
(in our case, the Dachstein firewall) and return the output (and other infomation)
from the script. We will use this feature to run two short and simple scripts,
checksig1 and checksig2 to output the signal strength and signal quality numbers
respectively. We can then probe the respective OID for these exec commands using mrtg
or for testing purposes, you could use snmpget or snmpwalk.</P>
<B><P>DETAILS:</B> Snmpd.conf, as provided, has closed snmpd to probes outside of the
"system" subset. In order to probe the OID for the output of scripts or commands
specified by "exec" in snmpd.conf, we must open up the system to such probes. If you
search the snmpd.conf file suggested at the beginning of this document
(http://www.dublerfamily.com/leaf/snmpd.conf) for the word CHECKSIG, you will find
exactly what to comment out and what uncomment to get this working. (Once you have it
up and running, you can try to make the security tighter by tightening up the OID
specifier in the view setting, if you like.)</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=1><P>view systemview included system</P>
<P># for CHECKSIG comment out the above line and uncomment the next line</P>
<P>#view all included .1</P></DIR>
</DIR>
<P> </P><DIR>
<DIR>
<P>access notConfigGroup "" any noauth exact systemview none none</P>
<P># for CHECKSIG comment out the above line and uncomment the next line</P>
<P>#access notConfigGroup "" any noauth exact all none none</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P> </P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=1><P># for CHECKSIG, uncomment the next two
lines</P>
<P>#exec .1.3.6.1.4.1.2021.51 pete /root/checksig1</P>
<P>#exec .1.3.6.1.4.1.2021.52 pete /root/checksig2</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P> </P>
<P>The first two sets of commented lines will open up the snmpd to other probes beyond
the system subset. The last set of commented lines, flagged by the word CHECKSIG, are
the exec commands. Note that the complete OID for the single line of output you need
for each signal strength and signal quality are specified here and that they begin
with a period.</P>
<P>You must of course have these scripts on your system. (sorry for the grep� but I�m
not that great at regular expressions). So, copy checksig1 and checksig2 to /root or
wherever you would like to keep it. Make sure the permissions are set to 755.</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=1><P>#!/bin/sh</P>
<P>#</P>
<P># checksig1 outputs signal strength</P>
<P># OID .1.3.6.1.4.1.2021.52.101.1</P>
<P>cat /proc/aironet/eth0/Status | grep Signal | sed -e '2d' -e 's/[^0-9]*: //'</P>
<P>exit</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P> </P>
<P>AND</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=2><P>#!/bin/sh</P>
<P>#</P>
<P># checksig2 outputs signal quality</P>
<P># OID .1.3.6.1.4.1.2021.52.101.1</P>
<P>cat /proc/aironet/eth0/Status | grep Signal | sed -e '1d' -e 's/[^0-9]*: //'</P>
<P>exit</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P> </P>
<P>Now, on the system that is running mrtg, you simply add the following to your
mrtg.cfg file:</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=1><P>Target[fwsig]:
.1.3.6.1.4.1.2021.51.101.1&.1.3.6.1.4.1.2021.52.101.1:public@firewall</P>
<P>MaxBytes[fwsig]: 80</P>
<P>Options[fwsig]: gauge, nopercent, growright</P>
<P>Title[fwsig]: Radio Signal Strength and Quality</P>
<P>ageTop[fwsig]: <H1>Radio Signal Strength and Quality</H1></P>
<P>YLegend[fwsig]: strength/signal</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P>	</P>
<P>(since mrtg wants to probe for two numbers, using two separate OIDs and exec works
quite nicely here)</P>
<P>Restart mrtg on your server and check at the results in the file fwsig.html.</P>
<P>Hopefully you can now see how to log other things remotely using the combination of
snmpd with exec, and mrtg. Good luck!</P>
<P> </P>
<B><P>APPENDIX B: Workaround for syslinux.cfg Line Length Limit</P>
<P>DACHSTEIN FEATURE</B>: (From Charles Steinkuehler) the hack to linuxrc to extend
the kernel command line [show below] is not necessary in Dachstein.</P>
<P>Long package paths and module lists can be added to the files pkgpath.cfg and
lrpkg.cfg, respectively, on the boot= device. Details are documented in</P>
<P>the Dachstein-CD Readme, but the functionality is in the floppy releases as well...
</FONT><A
HREF="http://lrp.steinkuehler.net/Packages/LRP-CD.htm">http://lrp.steinkuehler.net/Packages/LRP-CD.htm</A></P>
<B><FONT SIZE=2><P> </P>
<P>GENERIC WORKAROUND:</B> (edited from work by Jim Moy, thanks Jim!)</P>
<P>There's a 256 char limit on the syslinux.cfg kernel params line. Go and do
this:</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=2><P>$ cat /proc/cmdline</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P>and if it looks like your module list is getting truncated,
well, there's the problem. If yours looks right then you haven't hit the limit yet, so
you're fine As you add more functionality to your leaf, you might hit this limit. If
you want to fix it, go look for the line in /linuxrc that looks like this:</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=2><P>ROOTMAP="`sed 's/.*LRP=/\1/; s/ .*//1'
/proc/cmdline`"</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P>and replace it with this:</P><DIR>
<DIR>
</FONT><FONT FACE="Courier New" SIZE=2><P>pkglist=`cat /boot/etc/lrppkgs.cfg`</P>
<P>ROOTMAP=`echo $pkglist | sed 's/ /,/g'`</P></DIR>
</DIR>
</FONT><FONT SIZE=2><P>then put all your module names in /boot/etc/lrppkgs.cfg in a
simple list, one per line. Backup the root module. Actually, I'm probably going to
move it to somewhere in /etc, the root module takes longer to backup :-P From then on,
it ignores the LRP= value in syslinux.cfg. </P>
<P> </P>
<P> <B>REVISION HISTORY:</P><DIR>
<DIR>
</B><P>3/11/02: converted to html, changed dublerfamily links to sourceforge</P>
<P>3/13/02: Corrected Appendix B to add Dachstein Feature.</P>
<P> </P></DIR>
</DIR>
<P>### end of document</P></FONT></BODY>
</HTML>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Leaf-cvs-commits mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits