Decrease Address Book sync frequency (And some keychain tips)

Snow Leopard's "new" Address Book sync with Gmail's Contacts works great - though I'm not sure why it defaults to sync every hour; I certainly don't change contact info that frequently. :)

If you keep your keychain locked most of the time* being bothered to authenticate OR click cancel, twice, is a needless bother.

So, here's the command to set the frequency to whatever duration you like (in seconds); I chose a full day, since that's more than enough for me:

defaults write ~/Library/LaunchAgents/com.google.GoogleContactSyncAgent StartInterval -int 86400

It's also apparently necessary to log out and back in, to get the change to take effect.

*Keychains can hold some pretty sensitive info. If you don't have the keychain lock itself after X minutes inactivity, you should consider it. Pop open the "Keychain Access" app (in /Applications/Utilities/) and take a look at what's in your own keychain - sure you want to leave that unlocked? If not:

• Click the "Edit" menu
• Select "Change settings for Keychain 'login'..."

  I recommend turning both checkboxes ON and setting a short lock time.

Now, once you've done this, you may find that Safari is pestering you mercilessly, to authenticate. This is because it's being very careful and storing virtually everything you type in Safari, in the keychain - since it can't tell how sensitive everything is, though it knows that some of it might be credit card numbers and the like. Fortunately there's a solution that's both secure and convenient; tell it not to store that info:

• Click the "Safari" menu
• Select "Preferences..."
• Select the "Autofill" tab
• Turn OFF the checkbox for "Other forms".

  (If you're curious, you can see what it's been storing by clicking the "Edit..." button to the right of the checkbox. It's mostly web searches and other such innocuous stuff. As you can see by the other checkboxes, passwords are stored separately.)

"So don't do that"

Interesting... :)

I just upgraded to Mac OS X Snow Leopard and coincidentally started trying to dig into why my MacBook has been running out of battery "early", shutting down ungracefully.

Of course it just starts right back up and the worst I'm left with, is trying to figure out where I was. Which I make unnecessarily worse by stopping to check to see if there is anything in the logs, and getting further distracted. There never is - except today. Excellent. :)

I've been following Apple's docs on this and running the battery right down to the end, to calibrate it. This morning I made it happen again and when I jacked back into AC power, it started up just fine - and entered an infinite loop.

Strange; it looked like it was just about to display the Login Window, but then went back to the old-school text screen that comes before that - and then started cycling back and forth. Drat.

Double drat: I'd turned off ssh ("Remote Access" in the Sharing Preferences Pane) and so, couldn't ssh in, to check what was going on.

So I powered off and tried a shift-boot ("Safe Mode"), but no go; same behavior.

OK; So I booted into Single User Mode and started spelunking...

Several tangets later :) I saw a log message; something that was consulting /etc/authentication* had failed with an "unexpected character"... Sure enough, that file was hosed. (More on that in a moment.)

So... I pulled that file off the Install DVD and was on my way. (Running the Installer from DVD - amazingly well-written! - may have worked, though I didn't try.)

*More on /etc/authentication:

• Interestingly, /etc/authentication is a dynamic file; it was modified on reboot. The changes were not huge, though interesting to track down manually via the XML, since the order changes (which is not important to XML).
  
• This file is critical in determining who (or what process) is allowed to do what - and since it contained invalid data, Mac OS X could not even get to the Login Window.
  
• My fault: I had inadvertently caused etc/authentication to be at risk by running system_profiler in a tight shell loop, to eat battery (since it not only spews data, but also consults hardware) and it (I have since learned :) consults /etc/authorization - which my command had kept open (and vulnerable) FAR more than normal. Live and learn. :)

Snow Leopard "safe sleep" tweak

A quick bash script to dynamically adjust the sleep behavior under Snow Leopard - to avoid the expense of maintaining the sleepimage if the battery is above a certain level.

Thanks again to Joe Kissell for the original script from (TidBITS#893/20-Aug-07).

#!/bin/sh

#
# 20090902 mvgfr: rules have changed (ex: hibernatemode; there is no 7) so recode
#                 AND be more fault-tolerant...
#                 (setpoints raised, & cron freq increased, since lately been losing power before sleep)
# 20090901 mvgfr: Snow Leopard now defaults to "Secure Virtual Memory" so change safe mode to 7
#    (need programmatic way to check, anything better than system_profiler?)
# 20090728 mvgfr: reduce setpoints by 10 (%)
# 20070908 mvgfr: impl setpoints, tweak msgs, Trash vs rm, debug...
# original: Joe Kissell ,  (TidBITS#893/20-Aug-07)
#

debugMe="" # simple toggle; empty means NO & anything else means YES

setpointLow=20
setpointHigh=25

MODE=`/usr/bin/pmset -g | awk '/hibernatemode/ { print $2 }'`
LEFT=`/usr/bin/pmset -g batt | grep Internal | awk '{ print $2 }' | awk -F % '{ print $1 }'`

if [ $LEFT == "(removed)" ] ; then LEFT=0; fi # catch case in which no batt is seen

if [ $debugMe ] ; then /usr/bin/logger -t "hibernatemode" "current mode (on entry): $MODE; batt % remaining: $LEFT"; fi

if [ $LEFT -le $setpointLow ] && [ $MODE == 0 ] ; then
  {
  /usr/bin/logger -t "hibernatemode" "Battery level ${LEFT}%; setting hibernatemode ON"
  /usr/bin/pmset -a hibernatemode 3
  }
elif  [ $LEFT -ge $setpointHigh ] && [ $MODE != 0 ]; then
  {
  /usr/bin/logger -t "hibernatemode" "Battery level is ${LEFT}%; setting hibernatemode OFF"
  /usr/bin/pmset -a hibernatemode 0
  mv /var/vm/sleepimage /Users/mvgfr/.Trash
  }
fi

if [ $debugMe ] ; then
    MODE=`/usr/bin/pmset -g | awk '/hibernatemode/ { print $2 }'`;
    LEFT=`/usr/bin/pmset -g batt | grep Internal | awk '{ print $2 }' | awk -F % '{ print $1 }'`;
    /usr/bin/logger -t "hibernatemode" "current mode (on exit): $MODE; batt % remaining: $LEFT";
fi

#end

macports notification of outdated

A quick and dirty bash/shell script to get automatic notification of outdated macports:

#!/bin/bash

# 20090902 mvgfr: tweaks
# 20071110 mvgfr: check for outdated macports & notify if any - via growl & stdout (emailed when cron'd)
# 20080209 mvgfr: must run sync before, so it can learn about updates!
#                 also added "-H localhost" workaround for growl Leopard bug (ignores some)

debugMe="" # presume we'll only use alphanum; like "YES" or empty string for NO

# may take awhile; is this an issue?
if [ ! $debugMe ] ; then /opt/local/bin/port sync; fi

if [ $debugMe ] ; then
    potentialOutput="`echo 'debugging:';ls -1|head -1`"
else
    potentialOutput=`/opt/local/bin/port outdated`
fi

if [ "$potentialOutput" != "No installed ports are outdated." ] ; then
    echo "$potentialOutput" # for cron to email to root
    if [ -f /usr/local/bin/growlnotify ]; then
 NumLinesToDisplay=$((`echo "$potentialOutput" | wc -l` -1))
 if [ $NumLinesToDisplay -lt 1 ]; then
     echo "underflow error; see log" | /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 elif [ $NumLinesToDisplay -gt 20 ]; then
     echo "overflow error; see log" | /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 else
  echo "$potentialOutput" | tail -`echo $NumLinesToDisplay` | \
      /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 fi
    fi
fi

if [ $debugMe ] ; then echo "`date "+%Y%m%d-%H%M%S"`: $potentialOutput" >> /var/log/port-outdated.log; fi

#end

(Old 2007/12/01 script here.)