At the time of writing, vnstat is not available in the native CentOS repositories, so installation requires downloading, compiling and installing the application from source.

The following steps will walk you through that:

1.) Get the source:
cd /usr/local/src
wget http://humdi.net/vnstat/vnstat-1.9.tar.gz

9.) Start the vnstat daemon:
/etc/init.d/vnstat start

That’s all there is to it. Now you can keep an eye on your bandwidth usage. e.g. set up a simple script run via cron to email you your stats each day.

DEVICE=eth0:0
ONPARENT=yes
IPADDR=192.168.1.1
BROADCAST=192.168.1.255
NETMASK=255.255.255.0
NETWORK=192.168.1.0

Manipulating the interface manually:
Bring it up: /sbin/ifup eth0:0
Take it down: /sbin/ifdown eth0:0

The ONPARENT option will automatically bring it up and down in conjunction with the parent interface eth0.
To remove automatic behaviour, just delete or move the file away somewhere else.

Looks experimental and lacks a complete data set, but it’s a start. :)

go go go!

[edit]

Well, looks like it was highly experimental because I just checked and it’s completely gone. The entire domain has been removed. dig says NXDOMAIN.

Oh, well. It was a nice thought…

[/edit]

[update=2009/11/07]
Looks like it’s back online again, still at the same address.
[/update]

Take BTC’s supposedly transparent proxy (cache-1-0.btc.bw) for example.

I must have missed the email that announced this new layer between us and the Internet, so I’m not exactly sure when it was implemented, but I have a gut feeling that it could be as much as a month or so ago. Maybe more, but it’s been about that long that I have been seeing some occasional weirdness on my Internet connections. Of course, I didn’t know the cause of the weirdness until recently, so it’s hard to say in retrospect.

Anyway, once I had identified this new obstacle to a better browsing experience, I set about finding out whether it was really the cause of my sluggish browsing and 503 (gateway timeout) errors. This necessitated establishing a browsing session that did not route through BTC, which is a reasonably painless exercise thanks to Mascom’s 3G network. Sure enough, after going 3G and browsing to the same sites that gave persistent 503’s, those annoyances disappeared.

So it was only a matter of implementing a bypass mechanism for the home and office systems, in order to regain a decent browsing experience.

Next on the list of things to do is to find someone at BTC that knows about this new hurdle and see if they can explain why I was getting the 503’s in the first place. Actually, if it hadn’t been for the fact that it was blocking my ubuntu security updates, I’d probably still be scratching my head over this.