I want to get a bandwidth usage graph for my machine, but don't have a switch with SNMP. Can I get this directly from the Linux box?
I want to get a bandwidth usage graph for my machine, but don’t have a switch with SNMP. Can I get this directly from the Linux box?
You can get a lot of information from a Linux machine via SNMP, including network traffic to build bandwidth graphs. I’ll explain a method using mrtg (Multi Router Traffic Grapher).
You’ll first need to install the SNMP daemon, preferably using your distribution’s package management system. The installation should start the SNMP daemon. You can check for this by running the following:
You should see an snmpd program running here. If you do not, you may need to start the daemon yourself. Depending on the distribution you are running, you’ll probably need to type:
# /etc/init.d/SNMPd start
# /etc/rc.d/init.d/snmpd start
If this starts successfully, you’ll want to make sure that snmpd is appropriately started by init in your startup scripts. If this does not start the SNMP daemon, or if an init file does not exist, you should check to see if SNMPd is, in fact, installed.
There is a lot to learn about SNMP. For now, you need to know that it provides several ways to access and control data, and it organizes much of this information in groups called “communities.” By default, most Linux installations will create a community called public that will contain basic information. This should be available on the local machine via localhost.
You can test this by using a program called snmpwalk to peruse the exports on your machine. To do this, try issuing the command:
# snmpwalk -c public localhost
You should see a lot of information dumped to screen. Anything less than this and you’ll need to ensure the operation of snmpd and that a public community has been created and is viewable by localhost. Since there are a myriad of options here, if this default setup doesn’t work for you, please visit the SNMP page at http://net-snmp.sourceforge.net/.
Once snmpd is running on your system and access is properly set up, you will be able to use programs like mrtg, which can use the SNMP data for various purposes. mrtg itself is a graphing program that you will probably need to install. All major Linux distributions call the package mrtg. You can check if the program exists by typing:
For now, let’s setup a basic bandwidth graph available through your Web server. I’ll be using /var/www as the document root and /etc/mrtg.cfg as the preferred location for the mrtg configuration file in the examples here. You’ll need to create a /var/www/mrtg directory, which will then be accessed as http://yourserver/mrtg/ to access the mrtg graphs.
If you don’t have one already, create an mrtg.cfg, as shown in the Listing One. The data that follows is for my own server at dtype.org. Substitute all the appropriate values for your own server, including a name for this mrtg block config (mine is verio228). Multiple configs such as these can exist in the same mrtg.cfg file.
Listing One: A Basic mrtg.cfg File
Title[^]: Traffic Analysis for dtype.org
Title[verio228]: Verio 184.108.40.206
PageTop[verio228]: <H1>dtype.orgat Verio 220.127.116.11</H1>
With this file in place, you should be able to run the following:
The first two times you run this, mrtg will complain that it does not have previous values. This is normal, as mrtg works by comparing numbers (from SNMP in this case) at regular intervals. The first time you run mrtg with this config, there will be no basis data for the interval. You should also see files appear in /var/ www/mrtg/.
Pointing a browser at http://yourserver/mrtg should give a file listing, including a .html file that includes the graphs you’re looking for. The numbers will be disturbingly low right now because you haven’t given mrtg time to run and collect data. By default, mrtg needs to run on five-minute crons.
You can learn a lot more about mrtg at the homepage: http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html.
mrtg and snmpd both have options far beyond setting up simple bandwidth graphs. They are both very powerful and can be very useful to system administrators looking to monitor and control boxes remotely.
I want to upgrade a kernel on a server running remotely, but I am afraid of rebooting the machine and having it fail on startup. Is there a way to guarantee it comes back up?
I wish. There are a few steps you can take, however, to try to minimize your headaches here.
I’ll outline my own procedure for doing this, which I must stress is only one way. It is, however, something I’ve done several times with some reliability. I have to assume that you’re somewhat familiar with how to upgrade a kernel, or else you really shouldn’t be attempting to do so remotely.
It helps a lot if you have the old kernel source; you can use this to retrieve the configuration for the kernel you are now running. The important file to find is the .config file for the running kernel.
1) Prep the new kernel: Download the new kernel source. It is a good practice to name the kernel source directory with a version number, so assuming you are upgrading to the 2.4.2 kernel, make sure there is no existing /usr/ src/linux (by moving it elsewhere or deleting the symlink) and then execute the commands found in Listing Two.
If you were able to get an existing .config file from the /usr/src/linux/ directory, then execute:
This will only ask about configuration items that have changed since your last config. If your kernel versions are similar, this may be a small list, otherwise, it may take a while.
Regardless of whether or not you had the old config, you should really now check the config for your machine options. If you didn’t have an old config, you’ll need to do this from scratch. I like menuconfig.
It is very important to verify at least the basic hardware configuration of the box. I can’t emphasize enough the need to carefully check configurations for hard drive types and drivers (SCSI and IDE), Ethernet adaptors, and other hardware your machine will need to boot and get onto the network.
Keep in mind that you will not be able to compile as a module something that you need to mount the root partition, because modules will not be available until the root partition is mounted.
2) Make and install kernel modules: Usually when I mess up a remote reboot it is because I forgot to install the new modules.
3) Check network setup: Be sure that your box defaults to its current network setup. This sounds redundant, but if you configured the box locally via an ifconfig line and didn’t change the default interface behavior, you’ll be out of luck if you don’t check this.
While playing with network configs, keep in mind that you’re currently logged into the box via the network. An ifdowneth0 command will likely leave you stranded.
4) Check basic network daemons: If you are logging in through ssh, make sure that this starts in the init scripts.
5) Edit lilo.conf: Be sure to leave your existing kernel in the options as the default. After running lilo, your current kernel will still be the default. At this point, run:
This will set lilo to boot newlinuxname (change as appropriate) for the next boot, but will still default to the old kernel for subsequent boots. This is very helpful if you hang the box, because then you can simply get an onsite person to power cycle it and boot into the known working kernel.
After a successful boot, don’t forget to change the default back!
Good luck. No matter how many times I do this, I’m always anxious until the ping finally returns.
Drew Streib is a coder, admin, and writer with VA Linux Systems. He can be reached at email@example.com.