Tag: Advanced Packaging Tool

Network Interface Utilization in Solaris

A friend asked me how he could see the network utilization in Solaris. It seems like a fairly simple request but for some reason this is not a simple command line away.

In Linux I would instinctively go straight to iptraf. I don’t know if iptraf is the tool of choice these days but I’m pretty sure it is an apt-get away if not already installed.

If you are a DTrace wizard, you could whip something up. Maybe you could get the information from one of the of the DTraceToolkit scripts if their installed. The DTraceToolkit scripts I’ve seen seem to give too much information as most of them are concentrated on not only telling you if the network is loaded but what is loading it as well.

For the sake of practice I wrote the following script:

#!/usr/bin/perl -w
print "Interface: ";
$max=`dladm show-dev -p $if | awk -F= '{print \$3}' | awk '{print \$1*1024*1024/8}'`;
print "Max speed: ",$max,"\n";
@kstat=`kstat ${module}:${instance}:mac:/[or]bytes\$/ |awk '{print \$2}'`;
sleep 1;

This script will ask you which interface you want to watch and then print out the utilization percentage on a new row every ~second.

On a side note, it seems strange to me the the received bytes are stored in kstat as rbytes while the transmitted bytes are stored in obytes. The only answer I can come up with is that if they would have chosen ibytes (in bytes) instead of rbytes, then the ‘i’ and ‘o’ might become interchanged in typos since they are next to each other on the keyboard. If they would have chosen tbytes (transmitted bytes), the same situation occurs- ‘r’ next to ‘t’. Still, as a friend pointed out, they could have used sbytes (sent bytes) which makes more sense than obytes.

CFEngine in mixed Solaris, Linux, environments

If you’ve ever tried to use CFEngine for package management, you know that it is basically useless.

  1. CFEngine only supports installing packages and not removing them (yet).
  2. It has some crazy limit defined at compilation time which limits the number of packages you can install. (see Google://cfengine “Too many arguments in embedded script”)
  3. It merges all your package work into one logical section even if you logically split up the sections and had them in a certain order etc.
  4. etc.

What comes out of all this is that you are better off using repository aware package management tools via the shellcommands actions (IMHO).

In the case of Solaris, the choice of champions seems to be pkg-get ala bolthole and blastwave.
In the case of Debian/Ubuntu, use apt-get.
This also means you no longer need to copy your package files using the cfengine copy actions since these tools will automatically retrieve them from your custom repository.

For those wanting to set up a pkg-get repository, the makecontents script should help you on your way.