I recently challenged myself to come up with a way to make udev automatically backup when you plug in a USB harddrive. I did all my testing with a USB stick drive, but since they both show up as block devices to the kernel, it shouldn’t matter.

UDEV Rules

To start with, we need to set up static naming for the storage device that you want to make into backup disk.  Start by plugging in the disk.  (Now I’m not using Gnome or KDE so I’m not sure what their automounter will do.  So, you might have to find a way to exclude it from the automounter.  We need to find out the “model” of the drive.  My udev rules are pretty basic, and will work since most people don’t have more than one the same model of USB drive laying around that they would use.  You can always modify the udev rules to work for you.

udevadm info -a -p /sys/block/sdc | grep model

Here we are looking at the block device sdc (which is what the kernel named it since we don’t have any udev rules yet).  This could change depending on how many block devices you currently have.  Now we take this information, and feed it into a udev rule.  I created a file /etc/udev/rules.d/50-backup.rules The name isn’t really important, however, the number 50- is.  That is the order in which it runs.  We want that number to be less than 90 so that hal doesn’t run first.  Inside that file, we have the following:

KERNEL==”sd?1″, SUBSYSTEM==”block”, ATTRS{model}==”MODEL GOES HERE”, SYMLINK+=”backup”, RUN+=”/usr/local/bin/backup.sh”

Replace “MODEL GOES HERE” with the output from the udevadm command

The backup script

Now we udev running our script /usr/local/bin/backup.sh we need to make that script

#!/bin/bash

NOTIFYUSER="pcon"
MAINDIR="/home/pcon/"
BACKUPDIR="/mnt/backup"

su $NOTIFYUSER alt-notify-send backup "Waiting for things to settle" 0
sleep 5

su $NOTIFYUSER alt-notify-send backup "Starting backup" 0
echo "$(date) - Mounting /dev/backup to $BACKUPDIR" > /tmp/backup.log
mount /dev/backup $BACKUPDIR >> /tmp/backup.log 2>&1
echo "$(date) - Staring rsync of $MAINDIR to $BACKUPDIR" >> /tmp/backup.log
rsync -arvuz --inplace --delete $MAINDIR $BACKUPDIR >> /tmp/backup.log 2>&1
echo "$(date) - Mounting /dev/backup to $BACKUPDIR" >> /tmp/backup.log
umount $BACKUPDIR >> /tmp/backup.log 2>&1
su $NOTIFYUSER alt-notify-send backup "Backup completed" 0

We have a couple of things to setup here.  First we need to create /mnt/backup as root, and fill out the other variables in the top of the script.  Aslo, if we want notification in gnome, we need to make a notify-send work around.  Put the following in /usr/local/bin/alt-notify-send

#!/bin/sh
user=`whoami`
pids=`pgrep -u $user gnome-panel`
title=$1
text=$2
timeout=$3

if [ -z "$title" ]; then
    echo You need to give me a title >&2
    exit 1
fi
if [ -z "$text" ]; then
     text=$title
fi
if [ -z "$timeout" ]; then
     timeout=60000
fi

for pid in $pids; do
    # find DBUS session bus for this session
    DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
    /proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
    # use it
    DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
    notify-send -u low -t $timeout "$title" "$text"
done

Now chmod +x the two scripts, and everything should be good to go.  You can download the scripts used in this post below:

• 50-backup.rules
• backup.sh
• alt-notify-send (Taken from here)

Screen is a great tool, and it allows you do to alot of neat things.  One of my favorites is binding commands to key strokes.  So all you have to do is hit F5 and it will start something in the background.  Such as a build command.  The problem is, you either get no output, or you get spam all over your screen.  Well I’ve finally found a way around that.  The answer lies in ANSI Privacy Messages.

In your .screenrc, make sure you have a place that will show messages.  If you start up screen and you see “New screen…” then you’ve got this.  Next add your script to your .screenrc

bind -k k5 exec /home/pcon/bin/build_script.sh

Now everything in your screen is ready to go.  Now, on to build_script.sh

#!/bin/bash

echo -n -e “\033^Starting Build\033\\”

# Do something here

echo -n -e “\033^Ending Build\033\\”

That’s it.  Now your screen will display “Starting Build” and “Ending Build” on your display.  If the stuff in between happens too fast, you may only see your last message.  The key thing is that your message has to start with “\033^”  and end with “\033\\” otherwise you’ll loose your cursor.  And you have to have the -e on the echo so that it will interpret the octal codes correctly.

I’ve come across the need to simply the dvd playing process.  I’m having to set up a laptop to play a dvd and use a remote presenter control.  Now in the past I’ve just been in charge of this setup, and haven’t had to worry about explaining how to start it up for others.  This time, I need to make it as user friendly as possible.  So, I’ve decided to do this with a couple of bash scripts and a couple of xsessions.
Goals

• Generic user with a generic password to hand to the person in charge
• Ability to play dvd stored locally.  (Called presentation_dvd)
• Ability to play any dvd inserted.
• Require no user input except to choose presentation_dvd or dvd

Preperation

To get ready, we need to do a couple of things

• Create a presenter user
• Install xine and xine-lib-extras-freeworld
• Copy our presentation_dvd to an iso
  

  dd if=/dev/dvd of=/home/presenter/presentation_dvd.iso

Xesssions

Xsessions are what defines your window manager.  It’s what tells X11 what to run when you say Session->Gnome or Session->fluxbox.  These files are stored in /usr/share/xsessions.

[Desktop Entry]
Encoding=UTF-8
Name=Presentation_DVD
Comment=Start the presentation DVD
Exec=/usr/local/bin/presentation_dvd
Terminal=False

[Window Manager]
SessionManaged=true

This is our file in /usr/share/xesssions/presentation_dvd.desktop We then create one in /usr/share/xesssions/dvd.desktop and replace presentation_dvd with dvd.

The Scripts

Our /usr/local/bin/presentation_dvd looks like this:

#!bin/bash
amixer set Master playback 100%
xine -f -g –no-splash dvd:/home/presenter/presentation_dvd.iso

This will turn the volume up to 100% and then start xine on the iso.  To exit, just right click and say exit.  This will take you back to the login screen.

Now to handle any dvd with the /usr/local/bin/dvd

#!/bin/bash
amixer set Master playback 100%
xine -f -g –no-splash dvd://

And the final touch, make them both executable

chmod a+x /usr/local/bin/dvd /usr/local/bin/presentation_dvd

NOTE:  The xine parameter is dash dash no dash splash.  The font I’m using doesn’t render two dashes well

Usage

From the login menu, choose your presenter user, and then choose the appropriate session at the bottom.  Then type in the password.  Like magic, everything should work.

Potential problems

If you don’t see your session in the list, you might have a typo in your xsession file

If one of the xine scripts don’t work, try logging into gnome and running the script from the command-line to see why.

From what I’ve been able to tell, there is no real version control built into Salesforce.com and this is a problem when pushing from a sandbox instance into a production instance.  To fix this problem (at least until Salesforce does something), I think the best option is to use the Force.com plugin and the Subclipse plugin for Eclipse.  With both of these in place, it should make version control a reality.

1. Install Eclipse for your platform (it’s eclipse-platform if you are using Fedora)
2. Install both the Force.com and Subclipse plugin (eclipse-subclipse)
3. Add your Force.com project to Eclipse (Howto)
4. Add your SVN repo to Eclipse.  (Howto)
5. Share your Force.com project (Right-click on Project name -> Team -> Share Project -> SVN -> Choose repo)
6. Then after updating a file in the Force.com project, commit the update to SVN before deploying to the server ()

Now if you want to use this in another Eclipse instance then, you’ll want to do the first two steps to prepare your Eclipse environment.  Then:

1. Add the existing SVN repo to Eclipse (Howto)
2. Right click on the Project Force.com -> Project Properties   and update the username / password

When using this in a collaborative setting, the following workflow should be followed whenever possible.

1. Team -> Update
2. Make changes to code
3. Team -> Update
4. Make changes to resolve collisions if needed
5. Team -> Commit
6. Force.com -> Deploy to Server

Just setup a TF2 server following this article

In Fedora, you need to do the following as root before running any of the commands from the article

ln -s /usr/bin/gunzip /usr/bin/uncompress

Now.  To figure out how the server.cfg

1. Prior to starting up the AppleTV or even unboxing it, get your patchstick ready by following these instructions
2. Unbox and setup the AppleTV to your LAN.
3. Then, navigate to the setup->general->updates and make sure you STOP the update if you can.  The update won’t technically break anything, but there are some problems with the newest firmware.  If you can stop it it’s better
4. Insert your patchstick, and reboot the AppleTV
   
5. Once it’s done open up your favorite terminal, and get ready to ssh to make sure that AppleTV can run any updates.  The password is ‘frontrow‘
   

   ssh frontrow@appletv
   sudo bash -c ‘echo “127.0.0.1 mesu.apple.com” >> /etc/hosts’

6. From the menu select ‘XBMC/Boxee’->Updates and select the non-alpha boxee
7. Wait and wait some more
8. Download the darwinx86 iso from here you can get a free login for this by following the links
9. Mount it up on the loop back and scp the /usr/bin/vim and /sbin/mount_nfs to the AppleTV
10. You will need to make sure you nfs export has the option insecure or the AppleTV won’t be able to mount it
11. Reboot one last time.  You can do this with ’sudo /sbin/reboot now’
12. Choose boxee from the menu and launch it.  There are a couple of known bugs with the latest firmware and boxee version.

• Boxee starts with a black screen.  The only real ‘fix’ for that is to restart it a bunch until it starts up right.
• Boxee freezes on the menu.  Remove the ‘/Users/frontrow/Library/Application Support/BOXEE/UserData/’ folder.
• For more information, go here

Something I’ve found very interesting, is the recent trend to move apps away from the desktop, and out into the “cloud.” Now, for the most part I agree with this. I rejoiced the day I moved from a pop3 account to an imap account. And then rejoiced again, when I moved my mail hosting to Google Apps. This is just the way most things are moving.  Most people don’t need apps outside of email and word processing.  And if that information can be stored in the cloud then that means I don’t have to be without my documents.

That brings me to the real point.  If you haven’t gotten a chance to check out some of the apps that make desktop apps out of web apps, try them.

• I like fluid for OSX, it seems a little more full featured
• Then Prism is looking really promising for all platforms (yes, even linux)

So, I’ve figured out how to add in a “fail-safe” to the perpetual screen, so that if you want to ssh without starting screen you can.  And it’s pretty easy.  First add the following to your sshd_config and restart ssh

AcceptEnv NO_SCREEN

Then add the following to the bottom of you .bashrc:   (Note: I named my screen ‘main’ you can name yours whatever you want)

NO_SCREEN=`echo "."$NO_SCREEN`
# Hack to get around if the variable is not set

if [ $TERM = "screen" ]
# If we are already in a screen do nothing
then
     echo -n ""
elif [ $TERM = "dumb" ]
# If we are using scp do nothing
then
     echo -n ""
elif [ $NO_SCREEN = ".true" ]
# Our fail safe to ssh w/o screen
then
     echo -n ""
else
# Startup screen
     screen -Rd main && exit
fi

Then, you can either ssh like normal to start the screen, or do the following to login without screen starting

export NO_SCREEN=”true”

ssh -o “SendEnv NO_SCREEN” user@host

Works like a champ