Entries posted in April 2012

So I have a new bathroom

Wednesday, 25 April 2012

The work on my bathroom is complete. The two weeks of noise and mess were well worth it.

The old and unpleasant room is now completely different. The only issue I see is that I've managed to fill up the storage already.

I'm particularly impressed with the sink, but special mention must go to the step, and the light switch (this is touch-sensitive and apparently incapable of electrocuting me).

Rest assured that despite all the changes none of my dinosaurs are missing!

Oh well I can always mount a new shelf, or three.

ObQuote: - "Tell me of your homeworld, Usul.", Dune.



Work on my bathroom continues

Sunday, 22 April 2012

Work on my bathroom continues. I had expected it to be complete on Friday but it lookse like the new completion date will be Tuesday or Wednesday.

It will be very nice to have a working shower, and a toilet I don't need to "flush" with a bucket.

The only interesting thing I've been doing is planning on a kernel to support long-term for some poor unfortunate souls who cannot use Debian-based kernels.

I know building, supporting, and maintaining a kernel will be a pain. But at the moment it looks like a valid thing to be suggesting.

Otherwise life goes on. I've been hit by the DIY bug, largely as the result of seeing all the bathroom work going on, and figuring I was going to live with dust/mess anyway - so I've erected some more book-shelves, and ordered a pair of ceiling fans.

The only other thing to report is that I've started deleting emails. (shock!)

I look after a few machines for myself, friends and so on. Each one will send me automated emails at times. I've got them going back years - but no longer:

#  Prune old mailboxes.
for maildir in .Automated.backups .machines.spotlight .machines.skx; do
   nrecent --keep=150 $HOME/Maildir/${maildir}/cur

Another new use for my nrecent tool. (Note: Only delete files from ./cur, to avoid deleting messages I've not read. Maildir is your friend!)

ObQuote: "I'm sorry I'm sweating on you... " - Knocked Up.



moreutils makes a lot of sense to me

Sunday, 15 April 2012

I've installed moreutils on several hosts now, and each time I find a new use for one of those tools I'm very happy.

Unfortunately I suspect that too many of us continue to hoard our little shell script archives, continuing to re-invent wheels with slightly different colours, shapes, and sizes.

I suspect I've just re-invented the wheel again, writing nrecent, because there seems to be no "simple" way of doing the job of keeping the most N recent files in a directory.

I guess the standard approach would be to use "ls", or "find", to find all files in a directory, reverse-sorted by mtime, then use "tail +n2 to skip the ones you want to keep, removing the rest.

Anyway nrecent - keep the most recent N files in a directory:

nrecent --keep 20 /tmp

Written as naively/hurridly as possible as it solved, and continues to solve, a real need.

ObQuote: "You're like the drummer from REO Speedwagon. Nobody knows who you are. " - Employee of the month



Bye-bye AOL

Monday, 9 April 2012

Today I took that final step:

touch /srv/_global_/blacklisted/domains/aol.com

I remember, even a couple of years ago, I had friends who would mail me from their @aol.com email addresses. These days people have moved on.

The two single biggest mail-providers I see in terms of spam are:

  • @yahoo.com - 832 in the past nine days.
  • @aol.com - 242 in the past nine days.

I'd like to drop @yahoo.com but I have some (misguided) friends who continue to use it to mail me. I might start dropping non-friend mails from that domain, but that's a bigger job.

Yes, this is a dull entry. Sorry. My existing bathroom has been ripped out and turned into this as a stepping stone into its new incarnation. I'm trapped in my office. Dust almost everywhere. Noise everywhere else.

ObQuote: "There can be no understanding between the hand and the brain unless the heart acts as mediator. " - Metropolis



So I want a backup solution

Thursday, 5 April 2012

I look after a lot of systems, and most of them want identical and simple backups taking of their filesystems. Currently I use backup2l which works but suffers from a couple of minor issues.

In short I want to take a full filesystem backup (i.e. Backup "/"). I wish to only exclude a few directories and mounted filesystems.

So my configuration looks like this:

# List of directories to make backups of.
# All paths MUST be absolute and start with a '/'!
SRCLIST=(  / /boot -xdev )

# The following expression specifies the files not to be archived.
SKIPCOND=( -path '/var/backups/localhost' -o -path '/var/run/' -o \
    -path '/tmp'  -o -path '/var/tmp' \
    -o -path '/dev' -o -path '/spam' \
    -o -path '/var/spool/' )

The only surprising thing here is that I abuse the internals of backup2l because I know that it uses "find" to build up a list of files - so I sneakily add int "-xdev" to the first argument. This means I don't accidentally backup any mounted gluster filesystem, mounted MySQL binary/log mounts, etc.

backup2l then goes and does its jobs. It allows me to define things to run before and after the backup runs via code like this:

# This user-defined bash function is executed before a backup is made
   if [ -d /etc/backup2l/pre.d/ ]; then
      run-parts /etc/backup2l/pre.d/

So what is my gripe? Well I get a daily email, per-system, which shows lots of detail - but the key thing. The important thing. The thing I care about more than anything else, the actual "success" or "fail" result is only discoverable by reading the mail.

If the backup fails, due to out of disk, I won't know unless I read the middle of the mail.

If the pre/post-steps fail I won't know unless I examine the output.

As I said to a colleague today in my view the success or failure of the backup is the combination of each of three distinct steps:

  • pre-backup jobs.
  • backup itself
  • post-backup jobs.

If any of the three fail I want to know. If they succeed then ideally I don't want a mail at all - but if I get one it should have:

Subject: Backup Success - $(hostname) - $(date)

So I've looked around at programs such as backup-ninja, backup-manager and they seem similar. It is a shame as I mostly like backup2l, but in short I want to do the same thing on about 50-250 hosts:

  • Dump mysql, optionally.
  • Dump postgresql, optionally.
  • Dump the filesystem. Incrementals are great, but full copies are probably tolerable.
  • Rsync those local filesystem backups to a remote location.

In my case it is usually the rsync-step that fails. Which is horrific if you don't notice (quota exceeded. connection reset by peer. etc). The local backups are good enough for 95% of recovery times - but if the hardware is fried having the backups be available, albeit slowly, is required.

Using GNU Tar incrementally is trivial. If it weren't such a messy program I'd probably be inclined to hack on backup2l - but in 2012 I can't believe I need to.

(Yes, backuppc rocks. So does duplicity. So does amanda. But they're not appropriate here. Sadly.)

ObQuote: "Oh, I get it. I see now. You've been training for two years to take me out, and now here I am. Whew! " - Blade II - An example of a rare breed, a sequel that doesn't suck. No pun intended.



Recent Posts

Recent Tags