I wrote a new script today to keep me up-to-date on how full the boot partition is on my Ubuntu servers. I actually administer quite a few of them and it can become a real issue if the boot drive hits 100% full, which it commonly does. The reason for this is that the boot partition by default is quite small (usually under 200 MB) and will fill up, often over the course of only a few months, with kernel files.

I have seen some servers carry on just fine when this occurs, I have also seen other servers exhibit some really odd behavior. Either way, it is best avoided.

The problem (and the blessing) is that Ubuntu Server is Linux… which means it requires very little administrative intervention month to month because (unlike another well-known and much used server platform) Linux tends to just work and work and work and work.

Very early on I went in for a job interview in IT. At the time I was a freshly minted MCITP, and knew very little about anything outside of Microsoft. The gentleman interviewing me asked me what my experience with Linux was, to which I replied “very little.” He then thought for a moment and said, “Well that really doesn’t matter, we have several Linux servers and the primary issue we run into is that we forget about them for 3 – 5 years until a power supply or spinning disk dies.”

That sums up most Linux setups in a nutshell. All that to say, it legitimately might be several months in-between administrative server logins. A fact which most admins are quite thrilled about.

When I started realizing that Ubuntu Server was going to require regular intervention, albeit fairly lightweight stuff, I was a bit bummed. It probably isn’t a horrible thing, rock solid stability aside it is still a good idea to login now and again to keep your software packages up to date. However that tendency to “set it and forget it” remains.

Long story short, I needed an automated alert system.

Solution, a shell script running as a cron job that will shoot me an email.

If you are following along, we are now going to dive in to the practical instruction bit. (more…)

This is the final article (I think…) on MySQL database backup. In my previous article I discussed how to craft a very efficient script for automated LOCAL backup of your MySQL databases. But that isn’t the whole story. What happens if your server burns to the ground… or more likely the hard drive gives up the ghost, corrupting everything and effectively leaving you up the proverbial creek without a paddle? Today I want to finish our script by adding a couple of extra components and giving you a paddle in the form of “offsite” backups. (more…)

Earlier this year I wrote an article about creating scripts for backing up your MySQL databases.

A week ago I wrote another article about automated and secure root user login to your root MySQL database account.

I have also been learning Python on and off and learning quite a bit about variables and loops. While the syntax doesn’t carry over to BASH, the the logic does.

Combining the ability of password-less root login and for-do loops, I was able to drastically clean up the size of my original database backup script (my first reference above). To be exact, I had nine databases and 35 lines of code. My new script has 10 lines of code. Furthermore, my original script wasn’t “intelligent” in the sense that you would have to update it (and make it longer) anytime you wanted to backup an additional database. The script I am going to discuss in this article should stay at ~10 lines regardless of how many databases are being backed up on the server.

So today’s script is vastly shorter and, better yet, will automatically backup any new database you add to your MySQL instance! Awesome right? (more…)