Snow Leopard pestering for keychain password

Interesting new behavior in Mac OS X 10.6 (Snow Leopard):

Services that formerly required a single authentication of the keychain (at launch) now ask every time, if the keychain is locked.

I've noticed this at least with Apple Mail and Google Contact Sync (ex: the gconsync process asks access the keychain).

The new behavior is certainly more secure (formerly, the passwords read from the keychain had to be stored somehow, to use later, thus providing an additional potential place to steal them). However, I don't agree it's worth the trade for the level of bother.

And it forces me to either:

1) Type my keychain password frequently (some risk there; ex: if someone's watching).

OR

2) Adjust the automatic keychain locking to be less frequent - which could well result in it never being locked (since it would continually be a accessed, resetting the countdown to automatic locking).

I didn't like either, so I found a way to tell Mail to check (poll) less frequently; every six hours:

defaults write /Users/mvgfr/Library/Preferences/com.apple.mail PollTime 360

(The above is to be issued to a command line prompt, all on one line. If you're not familiar with the command line, here's a beginner's guide. Standard warnings for the command line apply; if you're not careful you can do serious damage.)

This works for me, since I'm using Mail only as a backup of my mail messages; I compose and read mail in other ways.

(The Mail Preferences window allows a maximum of 60 minutes - and this is what shows when set as above, though the custom setting is thankfully maintained and not overwritten.)

Google Contact Sync (gconsync) took a little more effort; documented at the previous link. The concept may apply to other types of synching, though would require changing another parameter, since the above is specific to Google Contact Sync.

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.)

Snow Leopard upgrade notes

Words of warning for anyone who's customized "under the hood" a little:

1. The Snow Leopard installer (doing an upgrade) wipes out /var/log/.
   

   Not only would I have preferred to keep the old logs (historical reference; maybe to compare pre- and post- Snow Leopard), but I also had some custom stuff logging into there (ex: freshclam) that was just gone. And my code was quick-and-dirty so it didn't recover gracefully (ex: to the logs not existing) so I had to do a bit of cleanup.
   

   No huge deal (this is not-unexpected behavior for /var/) though it is new behavior for the Installer, so I'm adding this to the great Internet KnowledgeBase, so maybe it saves someone else a bit of effort. :)
   

2. It seems to have wiped out the /opt/local/mysql symlink to /opt/local/mysql-version_spec; also easily fixed.
   
   
3. MacPorts wouldn't selfupdate for me, so I just reinstalled from the latest disk image (1.8.0 for 10.6). I also installed the new Snow Leopard Xcode Tools (3.2; newer even than the version I downloaded last week!) on the Snow Leopard DVD.

BTW: If you have done some customizing, look for files with these strings added to the name (not just appended): "~previous", "~orig", or (maybe) "disabled". Such as:

• /etc/syslog.conf~previous
• /etc/postfix/main.cf~orig

As you may need to bring some customizations back. (Though in both the above cases, I was happy with the way the Installer had done it.)

(Thanks to Apple for putting some nice info in various logs.)

Otherwise, smooth sailing! Definitely a must-have upgrade, especially considering the price and what it sets up for the near future.

Macs are more secure

Check out the Macalope's column "Lies, damned lies, and statistics" in which he discusses yet another (strange) survey trumpeting trouble for Apple.

He also discusses Apple trumpeting about Macs being more secure, and makes a good analogy to be somewhat more realistic: "no matter how nice the neighborhood, you can only leave your houses unlocked for so long before something bad happens".

Clearly, no matter how secure Macs are to start, if you make insecure choices (ex: easy password, auto-login, etc.) you may find yourself in trouble.

The comments below the article are worth reading too; and indeed security does include many things.

One factor is the default config. In MS Windows, virtually everything defaults to "on" whereas the Mac defaults to "off"; you can't be attacked via a door that isn't there.

Another factor is monoculture vs. diversity; much malware depends on the targets running IE or Outlook or whatever - whereas the Mac market benefits from a different and more varied environment and so is more difficult to target.

Macs are certainly not immune (nothing is) - however they do suffer from far less malware and one reason is that they start out more secure than MS Windows. The rest is up to you.

Pruning Time Machine Backups

Here's an interesting twist; Apple seems to be protecting me from myself again:

I noticed that Time Machine (TM) is backing up the Thumb64Segment.data (etc) files in my iPhoto bundle/folder and since those files are large and easily replaced, I want to skip them; easily added to the exception list ("Do not back up", via the "Options" button in the Time Machine preference pane) for future backups - HOWEVER I can't figure out how to prune them from previous TM backups.

(Tip: If you don't already use Eriban's Grand Perspective, check it out - it's terrific for exploring just where your disk space is spent, and it properly counts the hard links that TM makes such heavy use of. BTW: I also recommended Robert Pointon's tms, a command line utility to get lots of great info on your TM backups, including what exactly was backed up each time.)

Now, back to the problem that software exposed:

Of course I can open the iPhoto bundle in a Finder window, but as soon as I "Enter Time Machine", the window changes and moves to its parent. If I first open a Finder window to a subfolder within the bundle, that does stay viewed in Time Machine, but as soon as I click on the Thumb64Segment.data file to "Delete all Backups..." of it, the window immediately moves up another level.

Apparently Apple wants to prevent me from messing with bundles. I do understand the reasoning, however I'd argue the protections in the Finder are enough; if I've explicitly chosen to navigate into a bundle (hard to do by mistake) then let me work there! :)

So, there appears to be no GUI way to prune TM backups of bundles in this way; does anyone know how to prune by command line, within Time Machine? Of course it's easy enough to simply find and delete files via command line, however I don't know if that's safe within a Time Machine backup - anyone?

It's such a drag when you can't drag!

Strange problem that's been bugging me for awhile now:

For no apparent reason, the (Mac OS X) Finder suddenly chooses not to respond to an attempt to drag a file - say, to move it into another folder.

No error message; just that dislocated feeling when you realize that you didn't really pick it up - and can't.

Nothing interesting in syslog (asl) / system.log (even temporarily logging *.debug messages). Nothing in Console. Nothing in any other log that had recently been modified.

Tools like fs_usage and sc_usage didn't yield any promising clues.

Quitting and restarting the Finder didn't help.

HUP'ing SystemUIServer didn't help.

Checking the SystemUIServer plist ("defaults read /Users/username/Library/Preferences/com.apple.systemuiserver.plist") showed nothing unusual - and I don't just delete prefs to see what happens; that's sledgehammer voodoo.

Google searches turned up lots of discussion - but really nothing more interesting than the standard "Repair Permissions" voodoo or "Have you tried turning it off and on again?"

Quitting all open apps (and menu extras, etc.) had no effect.

Restarting will clear the problem (as will, if I recall, logging out and back in) - for awhile - however of course it's then necessary to reconstruct the 17 things you were trying to do at the moment; not good.

I noticed that other apps were affected - for instance, TextWrangler reports an error -4960 when attempting a drag.

The very cool "Technical Note TN2124 - Mac OS X Debugging Magic" (on the Apple Developer site) had a promising idea (launch an app with "-NSDragManagerLogLevel 6"), though that didn't yield anything for either Finder (probably because it's not a Cocoa app :) or TextWrangler (is it a Cocoa app?).

Looking into the Drag Manager some more didn't yield anything promising.

Well, then I started searching more deeply, including into some of the coding discussions. That's when I found mentions of the pasteboard (AKA clipboard). It didn't seem related, however that was the trick:

sudo killall -s pboard

(HUP'ing it apparently is not sufficient, but the default signal (-TERM) will do it. The "-s" flag means it'll show you what it'll do; if you approve, re-issue the command without the "-s" to really do it.)

It seems that - even for dragging a file in the Finder - the pasteboard is engaged and if it's wedged the operation fails silently.

If I can discover a little more background, I'll submit to RADAR.)

UPDATE: Apparently a little more background is required: While killing pboard re-allows dragging, it apparently is a BAD thing, causing apps to hang, probably expecting to hear back from the old process. Back to the drawing board...

Update 2009/03/20: It happened again and while I confirmed that logging out will clear it, that's not good enough. I did however find that there was a "Recovered Items" folder in my Trash; it contained a folder called "msoclip1" with four files (clip_image001.gif, clip_image002.wmf, clip_image003.png, clip_oledata.mso) so maybe the problem is related to some MS Office app's use of the clipboard?

Debugging 101 - Drat! Now What?!

What to do when something goes wrong.

(A presentation and interactive debugging session for the February 18, 2009 MacChamp (Apple User Group) meeting - though virtually all of it is applicable to any debugging scenario.)

Intro: The steps below may seem daunting, however this is the typical process - even if you call someone else for help, it can be handy to know. For instance, it removes some of the mystery and can help you gather critical info you might otherwise have missed. And every advantage to get you closer to a solution and more quickly on your way, is a good thing.

Step 1: STOP!

• Don't make things worse.
  
• Take a moment to assess; is it a genuine emergency?
  
• If immediate action is required, do what's absolutely necessary and then re-assess. (Ex: Dropped mobile phone in puddle: IMMEDIATELY remove battery!)

Step 2: What happened?

• Before you can fix it, you must understand just what occurred.
  
• Understanding requires hard (precise) information.
  
• Write down the time it is NOW.
  
• Write down when it happened:
  
  • If known: The exact time, using the clock on the problem device if possible.
    
  • If not known: When was the last time things were OK? How certain are you of that?
  
  
• Take snapshots:
  
  • Of the screen:
    
    • Shift-Control-3.
      
    • Use a camera if need be!
    
    
  • Of specific files:
    
    • Copy to ANOTHER disk.
      
    • If there are possible problems with a disk, avoid making any changes and especially adding any files to it. Just about anything can cause changes...
    
    
  • Of a whole disk:
    
    • CCC, SuperDuper, Disk Utility...
  
  
• In as much detail as possible, write down:
  
  • What you were expecting.
    
  • What actually happened.
    (Nothing is too small to mention; it's like "brainstorming".)

Step 3: Backups?

• What's the state of your backups?

Step 4: Background.

• List ANYTHING that happened recently that was out of the ordinary.
  
• List EVERYTHING you changed recently, REGARDLESS if it seems unrelated.

Step 5: Why?

• Why did it happen; what's the cause? Using the info you've gathered, generate some theories.
  (ex: Juxtapose what happened with what you were expecting.)

Step 6: Form a plan.

• For each theory, develop a test plan.
  
• Flesh each plan out in as much detail as possible, into a step-by-step checklist.
  (This is important; it may indicate the solution or help avoid a problem.)
  
• TIP: Test one thing - the smallest thing possible - at a time.

Step 7: Backups?

• Should you make additional backups, if possible, before doing anything?

Step 8: Test theories methodically.

• Use checklists & write down results at each step; it may be necessary to backtrack.
  
• Don't make things worse; change as little as possible.
  
• If a theory looks promising, retest to confirm *before* making changes.
  
• If no theories remain, review the info you now have; this may lead to new theories.

Step 9: Fix?

• If you think you have a fix, try it (one at a time!) and take notes about what happens.
  
• Retest to confirm.
  (Better to find out now, that it's not really a fix.)
  
• If a promising fix doesn't pan out, review the info you now have; this may lead to new theories.
  
• If a fix works, does it indicate anything that can be done to avoid problems in the future?

Step 10: Clean up.

• File your notes away; you may need them later; ex: long-term effects, multiple variables.

Mac AirPort (WiFi) and "promiscuous mode"

Interesting; I'm not sure when it happened or whether it's due to hardware or software (my money's on the latter), however:

I can now use Wireshark to capture packets over the built-in AirPort in a MacBook!

The Model Identifier is "MacBook4,1"; it's 2.10GHz 13.3" White, Model Number MB402LL/A.

And I'm using Mac os X 10.5.6 now.

Last time I tried, was with a 15" MacBook Pro (I think it was a 2006 model) and an earlier version of 10.5.

Whatever the reason, it's nice that simply attempting to use Wireshark (or, likely, attempting "promiscuous mode" in general) no longer renders the AirPort connection totally deaf, requiring something like switching Locations to recover.