Vnstat is a useful tool for keeping an eye on your bandwidth usage. This utility doesn’t require any special type of access to your ethernet interfaces either, as it reads all of its data from the /proc filesystem.

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.

It’s simple really.
Create a file /etc/sysconfig/network-scripts/ifcfg-eth0:0 [eth1:x for 2nd interface etc.] containing:

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.

I stumbled across an interesting little tool on the weekend, a whois system for the .bw ccTLD.

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]

Unless they’re implemented flawlessly, they’re more opaque than transparent.

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.

As a system administrator, it is inevitable that one day you will be required to recover data. How you go about preparing for this day will determine whether or not you will be a successful system administrator.

I’ve seen my fair share of data loss and recovered my fair share of data from backup media, be it dvd’s, disks or tape. This has instilled in me the following philosophy regarding data safety, “Prepare, Implement and Test.” Here are the basic rules:

1. Do what you can to safeguard the primary data medium through redundency, but be damned sure you don’t rely on that alone.
2. Prepare, implement and TEST your backup plan.
3. Test the hardware by physically pulling a disk out of the RAID array.
4. Destroy the data and follow your documented procedures to restore the system from tape.

Follow these simple rules and you will have a reasonably good chance of becoming a data saviour in the time of need. And that time will come.

So after a slight meander around, it’s time to proceed with the topic of this post, namely our mysql database backups.

Hardware safety aside, what do we do to look after our mysql databases? Well, we have two flavours of mysql database to safeguard, namely:

• Those under our provider’s direct control
• Those under our direct control

The databases under our provider’s control are currently not of great importance, so they are being manually exported as and when changes are made, which is quite infrequently.

The databases under our direct control are more important and thankfully these are still very small, so we have a script that runs on a daily basis to back them up. The script takes three options, namely database name, database user and email recipient.

And what does the script do, you might wonder? Well, it uses mysqldump to export the database given as database name by the user given as database user, encrypts it using gpg, stores a local copy on the host and emails the encrypted database to the email address given as email recipient.

This ensures that I have a compressed and encrypted local copy available for restore as well as a compressed and encrypted offsite copy, in case the box self destructs.

The script is run automatically by cron every day and can be run  several tines a day should it be necessary. As soon as the compressed filesize becomes too large for email to manage efficiently, then we will begin to look at other alternatives such as slave servers and remote synchronisation etc.

Well, I hope this little tidbit helps to keep at least one person’s data safe and sound.