Enjoy!

Software you’ll need:

• cwRsync – A Windows build of the oh-so-useful Linux rsync utility.
• TweakUI – Needed to create an “official” AutoRun handler.

We’ll use a Window’s batch script that will handle setting up the executing environment and launching.  Save the backupthumb.txt script to your USB disk, rename to backupthumb.cmd and tweak to your own needs.  By default the script will log everything to the logs directory on your USB disk.  See the rsync man page for all of the options available to you.

Next create the file that will tell rsync what files and directory to backup.  Just place the path to each file or directory on a separate line.  Using my script, the path is relative to the root of the USB disk and could look like:

data/accounts.kdb
docs/

Note the trailing slash which is important. Without it the files inside docs would NOT be backed up.  Also by default, rsync will not process the named paths in a recursive manner.  If you want it to, add –recursive as an argument to the rsync command in the script.

The next step is to create the autorun.inf file in the root of the USB disk with at least the following:

[autorun]
action=Backup Thumb Drive
open=bin\backupthumb.cmd

The open parameter’s value is relative to the root of the thumb drive.  Here I assume you saved the script to the bin directory on your USB disk.  Please note that I had issues if I prefixed it with a slash.  You can also pimp out the USB disk’s display in My Computer by adding a few more parameters to the autorun.inf file:

icon=data\cruzer.ico
label=Thumb Drive
shell\bkup=Backup Thumb Drive
shell\bkup\command=bin\backupthumb.cmd

This will use the cruzer.ico and label it Thumb Drive instead of the defaults.    It also adds a shell extension labeled “Backup Thumb Drive” which will execute our batch script when selected.  Handy to force a backup manually.  For the icon I just googled for cruzer icons and used ConvertICO.com to convert the PNG to ICO format.  If you’re like me and are lazy, you can just download the complete autorun.inf file.

If you stop at this point you will have an option in the Autoplay menu to “Backup Your Thumb Drive” when you insert your USB disk.  However our goal is to have it automatically perform the backup.  For this we need to use TweakUI to add a custom AutoPlay handler to launch our script.  Launch TweakUI and click on My Computer > AutoPlay > Handlers.  Click on the Create button.  For <description> type Backup Thumb Drive.  For <program name> type my backup script.  Then click on the Change Program… button and browse to the batch script.  Delete everything in the Args text box.  You can also set a custom icon to make it complete.  Again just use google to find something appropriate.

Then in My Computer, right click on your USB disk and select Properties.  On the AutoPlay tab, select Mixed content from the drop-down option box.  Change the action to Select an action to perform, and select our new Backup Thumb Drive option.  Lastly click the OK button.

And there you have it.  A nice and automatic backup method for your USB thumb drives.  Next up will be to show you how to replicate this in Linux.

I had suspected a device or the BIOS was the culprit.  The event log wasn’t any help; all it noted was Windows had went to sleep, then woke up.  Duh.  A quick Google search revealed a command line utility powercfg, which can help point you to the last device which woke the system.  By running powercfg -lastwake you can list the device which did just that.  Nice!

Now I have a very nice system that scales back the CPU speed when not needed, then sleeps when it makes sense.  Finally just like my Linux system!

As a basis for my rant, let me start by saying that I’ve had no problems picking up the other UNIX’s (HP-UX and AIX) LVM implementations.  Both are structured similar to Linux (or should that be Linux is structured similar to them? ).  Anyways, both follow the relatively simple notion of physical volumes, volume groups and logical volumes.  Physical volumes are your physical devices (disks and other block devices).  Volume groups are pools of physical volumes.  Lastly logical volumes are your partitions upon which you create your file systems.

Solaris doesn’t implement any of this.  At least not in the same manner.  Near as I can tell, they roll the last two layers together to form what they simply call a volume.  The worst though is the CLI tools used to create and manage them.  It doesn’t help that I inherited this box from the guy that left, and without much notes.  He didn’t split the file system up very well.  If this were the other boxes I’d simple add another PV to the VG and then expand the drowning LV’s.  Instead I can read through books on this subject to understand Sun’s take on LVM.

I ended up skirting the issue and not using their SVM.  Since this is just for emergency sake, LVM isn’t really neccessary.  Still it would be nice to conquer SVM.

Damn, its done…

So that went really, really quick!  This is really just my trial install: a generic base install that I can build upon in a modular framework.  The ultimate goal is an autonomous install where we define a system’s config in a database for use with cfengine/puppet and the system automatically builds itself.  But I gauge that will be sometime out in the future.

For now, I’m just nailing down our base RHEL install plus local rpms for OV agents, HP stuff and EMC stuff.

I also took the opportunity to move the blog into its own subdirectory. Again an easy task with Wordpress. In fact, the good folks at wordpress.org already have a quick guide on do this.

There are a few other lingering quarks, but like the other problems, I’m sure they easy to remedy.

• Repository location – I know how to use the old RCS version control software, which kept everything in the same directory of what you were controlling. So with SVN I would designate a different location in the filesystem (say /var/lib/svn) and store everything there? This seems nice as it would be the same root location for all my repos (assuming an increased usage of SVN down the road).  Answer: Not a big deal.  I ended up placing the repo in /var/svn/systems/<hostname>/etc hoping this will prove to be a generic enough layout to hold more system stuff in the future.  Then /etc is just a working copy of the repo; no need to edit the files in one location and check them out to /etc.  However, that turns out to be the added benefit as I could… To any machine running subversion too.
• However, in the normal daily routine would I have to checkout everything to a different directory so that I can edit it using my non-su account? Using my regular user account would be the preferred route (and more SA-correct way) but really I’m the only one who access the files so do I just use root for everything? Answer: Not really an issue.  I su to root, make modifications, then when checking everything back into the repo I use the –username arg and specify my name.  It is not error-proof, but it works.
• File owner/group permissions – How would this work? If I use my regular account, would I simply su to root and checkout files to /etc to “activate” them?   Answer: This might be the only real problem.  It appears that subversion doesn’t keep track of either of these which could pose quite a problem.  However, there isn’t an issue with editing as I am doing so with root (or sudo) anyways.

The main thing to remember is once I’m done with editing, I have to run some additional subversion commands.  Namely, svn update to verify what’s changed, make any add or rm’s depending on additions or deletions, then svn ci -m “whats changed” –username <myname> to check it all in, and finally svn up to keep everything in line.  Now I can run svn log to see my change history.  Schweet.