Dec 18

Finally got together and uploaded my second rsync script I mentioned earlier in this posting.  Instead of mirroring one internal drive (all partitions) to another, this will copy contents of one path to the external drive, optionally delete old files on removable disk from the previous rsync and finally eject/spin-down the drive if wanted.

Download or wiki.

Dec 17

So I was wondering why I could not turn on syntax highlighting in vim. It returned an error “the command is not available in this version”. Apparently Ubuntu comes with a gimped vi or something and I didn’t even realize I did not have vim proper installed. apt-get install vim solved the problem.  Whoops :)

Dec 17

So I figured out the reason why the secondary drive in my server would spin back up shortly after stopping it. As I was looking through my dmesg log I noticed an entry where it was enabling the swap space on sdb. Whoops, forgot about that.  On the other hand, I also noticed that my SMART monitoring configuration works just fine, as briefly after I successfully spun down the drive I received an “SMART failure” email – it could not detect the drive and perform the self-diagnostic.  I have configured my systems to forward the local root email to my personal domain, then to my Blackberry with urgent notification.  Glad to see it worked this time!

Dec 16

I’ve been using my rsync mirror script for a few weeks now and have implemented an additional one or two tweaks after deploying it on my desktop system as well.

  • Firstly, now you can you use the same script across multiple boxes – the UUIDs are configurable per hostname
  • A bug was fixed where the script would fail if the destination disks were not already mounted.
  • You can also customize the rsync invocation on a host-basis as well.  This was needed on my desktop machine where a /home account was mounted via NFS on a different file system causing IO errors and subsequently skipping the file deletion.

One final enhancement I want to add is the ability to spin the backup disk down after rsync is complete – this will not only help to increase drive life but also help reduce power use (however small it may be).  For some odd reason on my machines whenever I stop (umount, sync, then spin-down) an internal disk it works for a few seconds, then the drive spins back up again and I’m seeing ATA link reset messages as if it was just being plugged in.  External drives connected with eSATA seem to work just fine however.  Need to look into that more.

Also shortly available:

  • A similar but different script I use for syncing my RAID storage array with an backup external drive connected via eSATA.  It’s a bit of a hack in some spots, but the nice thing is that it is almost fully automated.  Use this on a machine with one of those eSATA docks and you have a good way of making a quick backup of an array or disk.
  • Sample service account script implementation with the ‘chattr’ command.

Download or wiki.

Dec 4

If you have read my brief posting Intrepid upgrade done I mentioned I would shorlty be implementing SSH keys for my systems.  This is a simple HOWTO to cover the steps I used.  In my case I’m implementing this only a small home network, please adjust as needed.  I will be setting up a key for my primary user account plus an additional phrase-less key used for automation purposes.  This second key will act as a service account, restricted to running only a few particular applications and/or scripts.

  1. Run ssh-keygen -t rsa.  I specified a simple passphrase for general-purpose logins.  We will be adding the second phrase-less key later.
    (adechiaro@desktop:pts/6)-(4/0 @ 17k)-(09:22 PM)
    ~$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/adechiaro/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in id_rsa.
    Your public key has been saved in id_rsa.pub.
    The key fingerprint is:
    5d:34:f1:de:ad:be:ef:65:34:36:a4:0d:75:d6:3c:47 adechiaro@desktop
    The key's randomart image is:
    +--[ RSA 2048]----+
    ...
    +-----------------+
    (adechiaro@desktop:pts/6)-(4/0 @ 17k)-(9:22 PM)
    ~$ cat .ssh/id_rsa.pub
    ssh-rsa <key> adechiaro@desktop
  2. Any machine you want to be able to connect to with this key, login and copy the contents of your public key (id_rsa.pub) to the authorized_keys file.  These are all in your $HOME/.ssh/ directory.  There are various ways to do this: you could copy the file over with scp and cat/append it, you could remote in to the host and cut & paste the data, if you had a large infrastructure you could use ssh-copy-id or similar custom script.  It’s up to you, something like what is below should work in the general case.  Also the <key> is your public key in base64 encoded format.
    desktop:~$ scp .ssh/id_rsa.pub adechiaro@server:~
    id_service.pub                           100%  399     0.4KB/s   00:00
    desktop:~$ ssh adechiaro@server
    server:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
  3. Now for an example of making the key more secure, you can add additional options to the authorized_keys file.  These come before the “ssh-rsa <key>” part of the entry (prefix the line with them): Read the rest of this entry »