Extra Pepperoni

To content | To menu | To search

Tag - security

Entries feed - Comments feed

Thursday, January 24 2008

Keychain Sync without .Mac

After getting burned too many times, I dropped my .Mac subscription. I never trusted my Apple keychains to iDisk anyway, but this means I have different subsets of passwords on different machines, and no good way to keep them in sync. I thought of a solution for manual sync last week: One keychain per Mac. Say I have 3 systems: work, home, and other. Each system has 3 Apple keychains: work.keychain, home.keychain, and other.keychain, with each host using its own as the default. Then I can rsync work.keychain to home.keychain & other.keychain, etc. This is awkward with rsync because it's inherently unidirectional, but keychains are small so it's quite feasible to script.

In Tiger, I know the keychain is actually stored in memory once it's unlocked, so it's good to lock (unload) all keychains with "security lock-keychain -a" before updating the files -- this goes in the same script. I also set mine to lock after 2 hours of inactivity, or (on those systems where I run SSHKeychain) when sleeping or activating the (locking) screen saver.

Wednesday, April 11 2007

Backups and Moving into Subversion

I do not have a comprehensive backup strategy. I keep reading well-reasoned arguments for at least 3 complete (bootable) backups, scratching my head, and saying, "Yeah, if I had a couple thousand unused, I could do that." Yes, I know drives are cheap, but I have 3 important systems to back up, and 4 more where perhaps a dozen files matter combined. Between the important systems, I'd need about 600gb usable, and Joe thinks you need 3 bootable backups, and I'm a strong believer in keeping the backups permanently away from the originals (not on a rotating cycle, but never-the-twain-shall-meet time -- what else is broadband for?).


Unfortunately, whenever I kick off an rsync job to update my remote backups (one set, not 3), Amy complains every day because Internet access is so slow. I think I have throttled it back enough to be unintrusive, but I just don't remember, and (especially at an unobtrusive fraction of our 384kbps DSL uplink), it just takes so dang long.


But I'm not too worried, because 95%+ of my important data is in Eudora on my iPod (yes, I know iPods die -- I've killed more than my fair share, along with Zip disks, Orb disks, and even a 2.5" FireWire drive), and I use Synchronize Plus X to back up my iPod to my primary home and work machines automatically, every time I plug it in. This is a great feature of Synchronize, which mitigates my annoyance with their licensing.

Every morning when I get to work, I dock the iPod; Synchronize sees it, launches Eudora, backs up changed files to my work desktop's hard disk, and launches an AppleScript to bring up a couple applications. When I'm done, I type eject in a Terminal window, my iPod unmounts, and login.keychain is locked (flushing ssh keys in the process). On my home PowerBook, the process is the same.

So I know my backup system works well, because I test restores whenever there's a problem with the iPod (perhaps twice a year). But I still feel nervous erasing it before sending it away. I actually did this today -- a couple months after its 2-year anniversary, my 60gb iPod photo's battery won't last an hour. Apple told me they'd fix it under extended AppleCare, but changed their minds and cancelled the repair -- without telling me. I paid the $70 and sent it in today; I'm running off our old 10gb iPod in the interim.

For the next step, I'm moving my website into Subversion. I already keep Julia's school site & Bjorn's site & documentation in Subversion, and last week I got sick of making manual backups of a piece I'm writing for TidBITS, so I reorganized and checked in my writing (not that there's much of it). Tonight, I threw out 4gb of my 7gb ~/public_html in preparation for checking in (most of) the rest of it.

Backing up a Subversion repository is easy, and will bring me to about 99% of important data backed up (not counting MP3s -- are already replicated to 2 Macs & an iPod -- or iPhoto libraries, which require different handling, but should back up quite well via rsync; but I have to get Julia's few [important] pages into Subversion too).

Friday, December 29 2006

BBEdit and Subversion: the Fruit Roll-up Post

I use vi daily, but much prefer BBEdit. The way I integrate them has evolved over time (see previous posts here, Useful subversion shell aliases, and BBEdit Gems (which appears to be down right now). In particular, I no longer configure BBEdit directly in ~/.subversion/config.

The new improved integration uses BBEdit whenever it's available (I'm in front of the Mac), and falls back to the default (vi) when I'm connected via ssh.

First, I created ~/bin/edit.sh to hand off to BBEdit. I use edit.sh whenever BBEdit is appropriate:

# Edit in BBEdit, for programs that don't support arguments in $EDITOR.
bbedit --wait --resume "$@"

Next, I configured my bash profile to prefer edit.sh when I'm not connected via ssh (which means when I am in front of the Mac or using ARD/VNC), as my EDITOR and PAGER. My profile doesn't automatically determine whether to use bbdiff for Subversion, because I sometimes find it necessary to use non-BBEdit diff for Subversion (there are cases where the svn-to-bbedit handoff doesn't work well, and I have ended up editing scratch files instead of the real files, for instance). Here's the snippet that does this, from my profile:

if [[ ! $SSH_TTY ]]
  if [ -x ~/bin/edit.sh ]
      export EDITOR=~/bin/edit.sh
    else export EDITOR=vi
  if [ -x /usr/bin/bbedit ]
    then export PAGER="col -b | bbedit --clean --view-top"
else export EDITOR=vi
fi # [[ ! $SSH_TTY ]]

In addition, I set up aliases for reviewing output from the svn command, based on Bob's suggestions. I just copy and paste one or more lines from svn output to review changes in BBEdit:

alias  A='bbedit --wait'
alias AM='bbedit --wait'
alias  C='bbedit --wait'
alias  D='true'
alias  G='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  I='true'
alias  M='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  R='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  U='bbedit --wait'

I update and then review status so often that I built my own TLA:

alias sus='svn update

Monday, May 22 2006

BBEdit and Subversion

BBEdit and Subversion now play well together (actually it's since BBEdit 8.1, but I hadn't noticed at the time). I added a few lines to ~/.subversion/config:

diff-cmd = bbdiff
extensions = --wait --resume

Now "svn diff" (with or without arguments) does the right thing.

Update: svn honors $EDITOR.