shards mvgfr: geek

Quick Look should display Spotlight comments as "alt text"

2011-10-04T06:04:00.000-04:00

A modest suggestion for Apple's OS X:

When hovering over a "Quick Look" display, Spotlight comments should be displayed just like "alt text" in a browser window.

Lion: Hardware Growler crashes

2011-08-30T08:26:00.002-04:00

For anyone using Lion and Hardware Growler (part of the excellent Growl package), you may have noticed that it crashes under some circumstances. (For example, see )

And if you're using it faceless, you may not even notice for awhile - say, til you realize you're waiting for a Growl that'll never come.

Fortunately, this is easy to slap a bandage over, with a simple bash script (all on one line):

while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done

(I know; a hard-coded path - you'll have to fix it if your path differs - if you know a better way, feel free post in the comments.)

I tried using a longer sleep, though the resource utilization was indistinguishable, so I left it at "1", which means it recovers almost instantly.

This can be "automated" even further: Into a text document, paste this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WindowSettings</key>
<array>
<dict>
<key>ExecutionString</key>
<string>while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done</string>
<key>Columns</key>
<string>44</string>
<key>Rows</key>
<string>15</string>
<key>WinLocULY</key>
<string>678</string>
<key>WinLocX</key>
<string>611</string>
<key>WinLocY</key>
<string>0</string>
</dict>
</array>
</dict>
</plist>

Save it as "something.term".

Double-click / launch the document and it opens Terminal.app for you. Add it to your Login Items, in the Users & Groups (nee Account) preference pane, and it's automatic.

(I believe the "WinLoc" keys are ignored in favor of an offset from the most recent Terminal window; pity - I'd like to place this at the same location on the screen each time. Though of course, Lion's "Auto Resume" handles this nicely too. :)

Lion: Use spacebar to scroll or page

2011-08-15T15:09:00.000-04:00

In Lion, using the space bar to scroll doesn't work very well - or, sometimes, at all. Even if it just worked a moment ago, in the same page.

Here are a few workarounds I've discovered:

1) Click in the area you want to scroll (ex: within a web page) and then press space.

2) Press the down or up arrows and then press space.

3) This is weird: Press a shift key and then press space!

coreaudiod using too much cpu

2011-02-12T08:22:00.002-05:00

Strange; my MacBook was performing fine, though I happened to notice that the CPU usage of the "coreaudiod" process was constant at about 10%.

There was plenty of idle, though it was enough of an irritant - especially since it had the highest cumulative CPU time of all processes - that I wanted to look into it.

(BTW: Nice concise man page for coreaudiod. :)

Interestingly, CPU usage dropped down under 2% as soon as I plugged in headphones, and jumped back up to 10% when I unplugged the headphones - very consistently, each time.

I profiled coreaudiod with Instruments (part of the Apple Developer Tools).

It was spending a lot of time in DspFuncHelper::process_IIR_xmm_LR(). The interesting symbols in the symbol stack under that: DspFuncEQ, IOAudioEngineUserClient, IOA_HWDevice, IOA_SingleDevice, IOA_Device, CAPThread.

I tried turning the iTunes EQ off. And then toggled it a few more times. No change. I tried quitting iTunes. Nothing I tried made a difference. I don't have any other audio apps (*) so I dropped it there.

There's some chatter online about it, though none seemed useful. (Mostly the standard voodoo of "Have you tried turning it off and on again?" (ref: The IT Crowd)

However there was one suggestion by a user named "bompi" in the Apple Discussions, to use launchctl to stop the process gracefully:

sudo launchctl stop com.apple.audio.coreaudiod

It automatically restarts - and even if you're listening to something at the time, there's only a very brief interruption.

I'd still like to figure out what happened, why, and how to prevent it, however this at least is a temporary fix.

*Correction: Obviously there are other apps that use audio, though no significant ones came to mind at the time. However, I do use Skype and that can obviously use audio - and I'd been conferencing about 12 hours earlier -- with some audio trouble (on my end only; the other side reported that it was fine). FWIW, it was Skype v5.0.0.7980 and I see that v5.0.0.7994 is available so I'll try that and see if that makes any difference...

Apple to drop Xserve

2010-11-12T07:42:00.002-05:00

(For reference, Apple's Xserve Transition Guide.)

This has been written about by some good folks:

A Eulogy for the Xserve: May It Rack in Peace (By Chuck Goolsbee, via TidBITS.)
On the Xserve thing... (By John Welch (Bynkii), with a link to his full MacWorld article.)

They cover the downsides, however:

Apple's target market is the end user. Overwhelmingly.

As such, the server market has always been a straddle of the world of the end user and that of the IT department - though clearly there are still some markets where an Apple server is a great fit, such as organizations where there is no IT department.

However, the target for the Xserve in particular has moved - in large part, to the cloud (such as AWS (Amazon Web Services).

And the cloud is built, in large part, with commodity hardware - not Apple's business at all. The cloud is much less about serious high-quality equipment, as it is about lots of cheap stuff that is configured so that failure is fully expected; just toss it (while something else automatically takes over its load) and slot in another.

That's the hardware side, which is all Apple plans to drop (in January).

On to software:

Apple explicitly will continue to develop Mac OS X Server and will continue to develop some server configs based on its other CPUs; a Mac mini with Mac OS X Server is a very nice server - and fits Apple's target market much better. It's no Xserve - and many of us have no need for all the Xserve does -- nor any need to pay for it.

Though this transition will cause some pain for those of us who find great utility in the Xserve, this is a great move for Apple and aligns its resources where they fit best.

Oh - and by the way, here's a left-field idea:

Apple is in a far stronger position now, than when it first started selling Mac OS X Server. At which time, tightly tying it to Apple's hardware made great sense. And Apple's very firm policy (full price) on licensing even virtualized instances of Mac OS X Server, while rather painful, made a certain amount of sense too.

Now? The landscape is significantly different. The business case can be much more solidly made, that Apple could license Mac OS X Server on commodity hardware - including in the cloud.

A stretch, yes. But within reach.

Strong passwords

2010-09-06T08:05:00.003-04:00

Microsoft has a page to check your password, which rates its strength.

Good idea - to help people choose stronger passwords - however:

I certainly wouldn't want to tell anyone my password, especially over the Internet; I'll keep it between me and whatever service I need a password for. (Yes, as it notes at the bottom of the page "The password you enter is checked and validated on your computer. It is not sent over the Internet." however I'd have to read the code to confirm that - and that it hasn't been changed since the last time I read the code. An unlikely requirement for the intended audience.)
I certainly wouldn't want to tell Microsoft in particular; regardless whether you trust them or not, they're a big target, so why take the chance of being "collateral damage"?
The page has little intelligence behind it; here are some example strength ratings:
- Medium: qwertyuiopas (12 characters - straight across the keyboard)
- Strong: abcdefghijklmn (the first 14 letters of the alphabet)
- Strong: 12345678912345678912 (20 digits, in order)
- BEST: 28 of any letter.

Whoops.

Recipes for tm-diff (Time Machine difference)

2010-06-28T05:54:00.006-04:00

A few recipes for using the tm-diff.sh script that I posted earlier (see link for details):

Ignore errors/warnings (ex: "Permission denied"):
```
tm-diff.sh folder1 folder2 2> /dev/null
```
Find all files, regardless of their privileges/permissions:
```
sudo tm-diff.sh folder1 folder2
```
Display disk usage, in "human-readable" sizes (ex: KB, MB, GB...):
```
tm-diff.sh folder1 folder2 | while read f; do du -h "$f"; done
```

Display disk usage, with a grand total at the end (sizes in KB):

tm-diff.sh folder1 folder2 | while read f; do du -k "$f"; done | awk '{ sum += $1; print; } END { print sum; }'

Display the largest 50 files (sizes in MB):

tm-diff.sh folder1 folder2 | while read f; do du -m "$f"; done | sort -n | head -50

Display the smallest 100 files (sizes in KB):

tm-diff.sh folder1 folder2 | while read f; do du -k "$f"; done | sort -rn | head -100

Display a full listing (with mode/privileges, owner, group...):

tm-diff.sh folder1 folder2 | while read f; do ls -l -h "$f"; done

Notes:

This presumes you've set your PATH so it'll find the tm-diff.sh script. (Or use its full path.)

In the commands above, "folder1" and "folder2" of course represent the paths to the two Time Machine backup folders to compare; they'll look something like:
```
/VOLUMENAME/Backups.backupdb/USERNAME/2009-07-20-091153
```

The script explicitly searches for regular files only; no directories or other special files.

I use a read loop, since this will get the full path, including "special" characters like spaces and double-quotes.

Sizes are in the classic style ("as God intended"): KB = 1024 bytes; MB = 1024 KB; GB = 1024 MB ...

Most Time Machine backups contain tens of thousands of files, so these will take awhile. The ones that sort will display no files, until all of them have been found, to be sorted - so they will seem to take even longer.

Show differences between two Time Machine backups

2010-06-27T10:52:00.013-04:00

Below is a quick Bash script to display the difference between two Time Machine backups.

The output is simply the pathnames of the files that were added to Time Machine in that time period. This may of course be piped to another command/script to provide further info - say, the amount of space used.

Cheat: Provide a simple date (formatted the same way that Time Machine does) instead of the "older" backup pathname, and it'll work whether or not there was a backup then. (The order of the arguments is unimportant; the script will figure it out.)

#!/bin/bash

LF=$'\n'
usage="Usage: $(basename $0) Time-Machine-folder-1 Time-Machine-folder-2"
usage=$usage$LF"(Compare the two Time Machine backup folders;"
usage=$usage"find and display files that were backed up in that time period.)"

function tweakDate { # to a fmt understood by find cmd
   echo "$1" | awk -v FS="" '{print $1$2$3$4$5$6$7$8$9$10" "$12$13":"$14$15":"$16$17}'
}

if [ ! $# == 2 ] ; then
{
   echo "$0 requires two arguments; the Time Machine folders to compare." >&2
   echo "$usage" >&2
   exit 1
}
fi

baseName1=$(basename $1)
baseName2=$(basename $2)

# NB: operator must be escaped or will signify redirection
if [ "$baseName1" \< "$baseName2" ] ; then
{
   olderFldr=$1
   recentFldr=$2
   olderFldrName=$baseName1
   recentFldrName=$baseName2
}
else
{
   reverse=TRUE
   olderFldr=$2
   recentFldr=$1
   olderFldrName=$baseName2
   recentFldrName=$baseName1
}
fi

if [ ! -d "$olderFldr" ] ; then
{
   echo -n "Warning: $olderFldr doesn't seem to exist;" >&2
   echo " maybe you're just using it to specify a date?..." >&2
}
fi

olderFldrParent=$(dirname $olderFldr)
recentFldrParent=$(dirname $recentFldr)

if [ ! $olderFldrParent == $recentFldrParent ] ; then
{
   echo -n "Warning: These folders are not in the same parent folder;" >&2
   echo " this may not be what you want..." >&2
}
fi

olderFldrDate=$(tweakDate $olderFldrName)
recentFldrDate=$(tweakDate $recentFldrName)

if [ ! -d "$recentFldr" ] ; then
{
   latestBackup="${recentFldrParent}/$(ls -1 $recentFldrParent | tail -2 | head -1)"

   echo "Can't find $recentFldr; searching the latest backup" >&2
   echo "    ($latestBackup)" >&2
   echo "    for files modified between $olderFldrDate and $recentFldrDate." >&2
   echo "    This may take awhile..." >&2
   echo $LF >&2

   find -x "$latestBackup" -type f -newermt "$olderFldrDate" \! -newermt "$recentFldrDate" -print
}
else
{
   echo "Now searching for backups in $recentFldrName" >&2
   echo "    that are more recent than $olderFldrDate." >&2
   echo "    This may take awhile..." >&2
   echo $LF >&2

   find -x "$recentFldr" -type f -newermt "$olderFldrDate" -print
}
fi

# eof

Cloudera Desktop setup tip: DNS, DNS, DNS

2010-02-23T09:13:00.003-05:00

Yes, it's important with Cloudera Desktop, just like everything else - try to fudge domain names and get bit.

Strange errors like:

"An unknown error occurred: hdfs put returned bad code: 255 stderr: 10/02/18 18:41:52 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:8020... Bad connection to FS. command aborted."

When attempting to upload a file - and I know that localhost is indeed responding properly on that port because it works find from the command line.

Solution: Spend the few minutes to determine what the real domain names are (*1) and set up the config files (*2) properly.

*1: ifconfig will tell you the IP address of the node you're on; host will tell you the domain name. If there is none, see *3 below.

*2: config files of potential interest:

/usr/share/cloudera-desktop/conf/cloudera-desktop.ini

/etc/hadoop/conf/masters

/etc/hadoop/conf/slaves

/etc/hadoop/conf/core-site.xml

/etc/hadoop/conf/hdfs-site.xml

/etc/hadoop/conf/mapred-site.xml

/etc/hadoop/conf/hadoop-metrics.properties

/etc/hadoop/conf/hadoop-env.sh

/etc/hadoop/conf/configuration.xsl

/etc/hadoop/conf/fair-scheduler.xml

*3: No domain name? See whoever's in charge of DNS, to fix it. That you? Well, you can either do it right (a little effort up front, pays big in the long run...) or you can try to handle it via /etc/hosts - good luck with that though.

Note to self: Don't shortcut DNS!

Snow Leopard pestering for keychain password

2009-10-24T09:09:00.006-04:00

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)

2009-09-04T07:35:00.007-04:00

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"

2009-09-03T19:44:00.003-04:00

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

2009-09-03T10:18:00.003-04:00

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

2009-09-03T10:02:00.003-04:00

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

2009-08-31T18:17:00.004-04:00

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

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. :)
It seems to have wiped out the /opt/local/mysql symlink to /opt/local/mysql-version_spec; also easily fixed.
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

2009-08-28T06:35:00.003-04:00

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

2009-08-02T07:35:00.005-04:00

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!

2009-03-15T11:01:00.006-04:00

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?!

2009-03-05T06:34:00.014-05:00

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"

2009-01-17T09:32:00.002-05:00

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.

Gmail: Bad Request; Error 400

2008-12-20T06:49:00.005-05:00

First time I've seen this: Tried to log in to gmail (via browser) and all I got was:

Bad Request
Error 400

I figured it was momentary, so went off to do other things. (So many other things to do...)

A few hours later, same thing. Next day, same thing.

This is unlike gmail. So tried a simple Google search... slow, but it did return.

Maybe Google is under a DoS attack? No news, and now Google is returning just fine, but still no gmail.

So I started searching around for anyone with a similar problem. Saw a few, though they were old.

Tried the gmail Google Group and went through what seemed to be the procedure to enter a new issue (after reviewing current open issues), but that did not give an opportunity, at the end, to open a new issue.

So, some more generic searching, using both Google and Yahoo, turned up the typical low-level support "decision tree" request to empty cache and delete cookies. Well, I'm certainly not going to delete all my cookies right away, however...

I tried a different browser and got right in - OK; we're on the right track.

I then saved my cookies (always have a backup) and looked for which cookies might be the culprit.

Got it in one: There were probably well over a hundred (!) separate cookies for the mail.google.com domain (both with and without a leading dot), that also used a path of "/mail". I deleted them, and gmail loaded right up on the next try!

Update 2009/03/20: Apparently there's a similar problem with Firefox.

Browser password managers leak like sieves

2008-12-19T08:36:00.006-05:00

We're browsing away, maybe checking our bank account balance and up pops the requirement to type in the password to unlock the password manager. Ah, we think, another indication that we're safe - it required me to type the password AND I was so careful to make sure it was the right site, etc.

Unfortunately, that's a false sense of security - which is worse than no security at all.

Click through the link above to read the gory detail if you like; even if you don't understand it all, at least some will make sense.

Even better, try the test yourself - watching it pull passwords out of YOUR very own password manager will really drive the point home.

I know of no actual exploits yet, and they do seem to require a compromise of the site from which the attacker wants to steal your password - however, as we've seen, such compromises are not at all uncommon.

One other item of note: For Safari in particular, I note that the default, when creating a new entry, is to give Safari blanket permission (via Access Control). While convenient, it is far less safe - and it seems that the problems detailed in the CIS article, might well be avoided if Safari did not do this; at least the user would be required to type in the keychain password each time and thus get some warning.

"What To Look For in a CIO"

2008-11-26T08:32:00.002-05:00

Economic constraints mean there's business out there that others are pulling back from, for the rest of us to pick up - opportunity!

What's an org to do? Get crazy - like a fox.

http://www.cio-today.com/story.xhtml?story_id=12200AVJWGKE

We have lots of tech already, and there are people who can do amazing things with it, even before investing in anything new.

Kerio 6.6 upgrade disastrous

2008-11-04T06:45:00.006-05:00

On 11/1 I upgraded JDK's Kerio server from 6.5.2 to 6.6.

While I had a downtime window, I also applied the latest MOSX updates: ARD 3.2.2, QT7.5.5, Java 10.5 Upd2, MOSX 10.5.5, and SecUpd2008-007.

Extensive research beforehand indicated no potential issues with any of the above.

Those processes went smoothly with the exception of one boot that strangely resulted in securityd crashing and failing to restart. A simple shutdown & restart fixed it.

I did some testing and everything looked good, so opened it back up to users. Shortly after that, users reported they were unable to modify their own calendar events. It seems that KMS no longer sees them as the owner of the event; the event "Organizer".

LOTS of debugging resulted in Nate Herzog (http://isitcreative.blogspot.com) finding the key: KMS is now doing a case-sensitive compare; "john_smith@domain" is not allowed to modify an event that is assigned to the Organizer "John_Smith@domain". (Nate's done a great deal of work understanding calendaring in KMS.)

Further, merely modifying the file on the server that corresponds to the event, such that the case matched, allows a user to modify the event. (No other action is necessary; no reset of an index.fld file and no reboot.)

And according to our experience, the case of the Organizer may appears either way (since before the upgrades) so we can't just do a one-time edit to force it one way; the problem will simply reappear.

It's the compare operation that's the problem; somehow case-sensitivity was newly introduced to it.

After trying for most of a day to fix it or find workarounds (Kerio support has no responded yet), we gave up and downgraded to 6.5.2. The problem persisted.

We restored the boot volume to an image made just before upgrading. The problem persists.

The backup we restored includes the OS & KMS code (/usr/local/kerio) not the data; the mailstore is on a separate volume.

This makes very little sense; apparently there's something changed in the mailstore that carries this problem forward, since the problem did not exist before this weekend's upgrades.

And in the mean time, after 14+ hours straight out, calendaring is still horribly broken.

Today, as a sanity check, I'm going to restore the entire server (code & mailstore) to its pre-upgrade state, to another machine and see if the problem somehow magically persists there.

20081104-0918 update:

1) Overnight, our IS Director, Nate Herzog (http://isitcreative.blogspot.com) had an idea that seems so far to work: Modifying the aliases for each account to be all lowercase. Simply editing the case doesn't take (it seems there remains a case-INsensitive compare there); it's necessary to remove the entry and then add it back in, with all lowercase. Editing the users.cfg file directly may also work, though we didn't want to take the server offline.

2) There's some chatter about Kerio releasing a patch to V6.6.

Safari (or other WebKit) browser fails on secondary/internal pages

2008-10-30T17:12:00.007-04:00

This is a a REALLY weird one, that I've been tearing my hair out, for several months:

You open a website and it loads fine; click on an internal link (a sub-page, search, whatever) and it fails - with a WebKit browser like Safari.

It's not a connectivity problem, though that's what it looks like at first.

As a matter of fact, browsers base on a non-WebKit rendering engine (ex: Firefox or Camino) are fine.

Safari gets the SYN/ACK from the target webserver and then *nothing* more from it; Safari just keeps resending the http request.

Wireshark shows "[TCP retransmission] [TCP segment of a reassembled PDU]" for the packets Safari sends after the Mac ACKs the webserver's SYN/ACK. This sends you looking for things like MTU (Maximum Transmission Unit), PMTU (Path MTU) and MSS (Maximum Segment Size) though it won't help.

My IS Director, Nate Herzog

http://isitcreative.blogspot.com/

just found the solution on MacInTouch

http://www.macintouch.com/readerreports/safari3/topic4614.html

and I found some more chatter about it, using the search terms from that article, such as Ed Marczak's

http://www.radiotope.com/content/safari-and-sonicwall

I'm blogging here, with a few more keywords, in the hope it'll save someone else some hair-tearing! :)

MOSX: video mode wedged?

2008-04-02T15:18:00.010-04:00

OK; this finally bit me one time too many - took me way too long to figure it out, but here it is, since I don't see it anywhere else:

For some reason, the video mode gets stuck (ex: 640 x 480 only) and you can't change it - here's how to fix it:

The info is stored in several files:

/Library/Preferences/.GlobalPreferences.plist
/Library/Preferences/com.apple.windowserver.plist
/Users/⟨short-name⟩/Library/Preferences/ByHost/.GlobalPreferences.⟨MAC-addr⟩.plist
/Users/⟨short-name⟩/Library/Preferences/ByHost/com.apple.preference.displays.⟨MAC-addr⟩.plist
/Users/⟨short-name⟩/Library/Preferences/ByHost/com.apple.windowserver.⟨MAC-addr⟩.plist

And there may be some in PRAM though that doesn't seem to be the case on recent systems.

To reset the video mode:

defaults delete /Library/Preferences/.GlobalPreferences ColorSyncDevices
defaults delete /Users/⟨short-name⟩/Library/Preferences/ByHost/.GlobalPreferences.⟨MAC-addr⟩ ColorSyncDevices

(Each of the above on its own line; the first requires admin.)

(Simply removing the windowserver plists has never done it for me - even from single-user mode, immediately followed by a restart and PRAM reset (multiple times). And FWIW, those files have still not reappeared on my system; perhaps they're no longer used.)

Why might this happen? It's probably related (at least in my case) to moving a boot volume from one system to another - that has a different video card. Which means this might be of some help for moving from one machine to another (ex: upgrade) or deploying an image to multiple machines.

NB: The above info is from a Mac OS X Server 10.4.11 system, though at least most of this should apply to Mac OS X (Client) as well, and other releases.

Trouble joining a domain? (MSWin)

2008-03-19T11:48:00.004-04:00

Strange; this has happened more than a few times now, so time to expose my ignorance:

We have a Citrix server running on Win2K3 Server.
It's configured to bind to a domain in order to allow use of the accounts there.
The PDC is on a Mac OS X Server box (10.4.11).

The initial bind is fine and authentication works great - until it breaks.

When it breaks, simply re-entering the info yields a 1326 error; it thinks the credentials are wrong. It seems there may be some caching of credentials, though I haven't found where or how to flush; rebooting the Citrix server doesn't help.

It also doesn't help to re-bind to a workgroup, reboot, and then attempt to re-bind to the domain - same error.

What does seem to fix it is this:

On the PDC, rename the domain & save.
On the domain client, confirm a bind to new/different domain.
Rename the domain back to the original. (On the PDC.)
Confirm a bind to the original domain. (On the domain client.)

Theory: Caching is forced to flush by temporarily binding to another domain - we've only got one, hence the rename; it's probably not necessary if you've another domain to temporarily bind to.

(Update: If it's an option in your situation, a simple restart of the PDC may suffice.)

Xserve RAID disassembly

2008-03-15T09:48:00.002-04:00

If you ever need to take apart an Xserve RAID, watch for the extra screw on the case bottom!

It's essential and not in the Service Manual I've got. (Hopefully it's in a newer version.)

When you get to just about the last step and you need to rotate the front half of the chassis up (say, for replacing the midplane board) take a break. Don't keep slamming it up, muttering "I'm following the directions!" :)

Pull the whole chassis forward a bit, over the edge of the table and remove the tiny screw that's front and center on the bottom of the chassis. Then pull the front of the front half of the chassis up and over the peg - simply sliding it forward does not seem to give enough room to get the midplane board clear.

And don't forget to put it back when re-assembling. :)

Leopard: Periodic scripts don't email results (postfix)

2008-03-15T09:02:00.011-04:00

I've been round-and-round on this one and can't find the break; hopefully someone will jump in and point out my error!

I configure /etc/aliases so that postfix knows where to send stuff addressed to root. I use "mail root" to test and it works.

Here's the first strangeness: Postfix no longer logs the send, as it did by default in Tiger. And I can't find where to bump the logging level.

I then configure /etc/periodic.conf.local to send output of the periodic scripts to both root and /var/log. The scripts run (both interactively via "periodic daily" and timed, via launchd) and logs are written in /var/log, but no email.

The behavior is consistent across every Leopard machine I've configured.

So both pieces of the puzzle seem to be working properly, though not the combination - what's missing?

AHA! After a false start, simply trying to explain it, did indeed bring on the solution, and it's painfully easy: Update to 10.5.2. :)

I had forgotten two factors:

1) Running "periodic " interactively did indeed email the results properly.

2) One of my Leopard installs "strangely" did, when kicked off by launchd, email the periodics' results properly - the one updated to 10.5.2. :))

(Credit to an Apple Discussion for the final kick to put all the pieces together.)

Update #2: It's not quite so easy (as updating to 10.5.2); the default config on a Mac OS X *Server* box is somewhat different: Comment out the references to Cyrus in both master.cf & main.cf (in /etc/postfix); for those of us simply wanting to email cron/launchd results out, it's just getting in the way.

BTW: Increasing the postfix logging level is so simple it's embarrassing: Edit /etc/syslog.conf. :)

Kerio 6.5.0 update/upgrade - WAIT

2008-03-07T05:54:00.006-05:00

Wow; a 15-hour day yesterday, and I'm up at 4am still thinking about our failed attempt to upgrade from Kerio 6.4.2 to 6.5.0.

Though I woke up early, because I think I have a solution.

HOWEVER, this won't be an option for some shops, so if you're considering 6.5.0, please consider carefully, and have a rollback* plan.

It seems that there's a bug in the new 6.5.0 code (my own conjecture - as well as the two Kerio Support people I spoke with yesterday).

For us the manifestation was, as soon as everyone arrived and started logging in, the response for the users ranged from terribly slow to simply unable to log in. Users accessing via web were able to, after several minutes, log in and work almost normally. Users on Entourage (the vast majority) were frequently unable to log in at all, and when they were it took, I kid you not, hours, to sync - and the sync rarely completed before an error message. (The error messages were actually varied, with some that I haven't seen before, which were something to the effect that if you selected one of the choices, you'd be wiping mail out.)

A very painful day all around.

Back and forth with Kerio Support and nothing we tried was able to improve the situation to a noticeable degree.

However, after catching almost 5 whopping hours of sleep, I think I may have the answer.

First, a few words about our config, that are probably significant: Kerio is configured with accounts "imported" from an Open Directory server (LDAP on Mac OS X Server). Neither the OD server nor the Kerio server (also on Mac OS X Server) broke a sweat (CPU idle on both was in the 8X-9X% range, and there was plenty of free RAM; network bandwidth was fine too) during the festivities yesterday, but something was bogging down Kerio's queries of the OD server. Actually it appears that the queries and responses were fine and specifically, quick. However Kerio seemed to be getting bogged somewhere in its process around the queries. It also, for most of the day, reported almost every minute, that it had reached its limit of LDAP queries (32 simultaneous) - increasing that limit to 64 didn't help and 128 didn't either; something else was going on.

There does seem to be a correlation between the problem and lots of Entourage users, however I now think Entourage is a red herring; the issue that everyone missed so far is spam - specifically spam addressed to non-existent addresses. In which case, the message goes through to Kerio, Kerio hammers OD with (I believe) buggy code and gets bogged down for any operation, including Entourage which ends up collateral damage. (Not that Entourage is totally innocent. :)

Here's my theory for a fix: We have a Barracuda and can configure it to talk to OD directly. It's a standard anti-spam feature and it will hammer OD for exactly the same queries, only directly. Kerio will not only not bog, it'll be *faster* than it was before, since it'll never see any of that spam.

So far just a theory...

(*Speaking of rollback: Kerio support would only give me "no guarantees" and "your plan sounds good" (grumble) however it appears to be as simple as this: Shut the server down; run the upgrade installer to UNinstall; restore your mailserver.cfg file from before the upgrade; replace the prior mailserver.cfg file (BEFORE re-running the upgrade); re-run the upgrade - which auto-starts the server; check, test, confirm...)

Login freezes in the Finder, at the Spotlight icon?

2008-03-02T14:07:00.004-05:00

sudo bash -c 'rm -rf /System/Library/Caches/com.apple.ATS* /Library/Caches/com.apple.ATS/* /System/Library/Caches/fontTablesAnnex; shutdown -r now'

# must be on a single line
# I just tweaked it a bit; credit to the Russian Bear :)

Enumerate "shares"

2008-03-02T13:57:00.003-05:00

Handy to place into the periodic/daily script, to keep track of shares and/or similar sub-folders. (For example, you can watch how usage changes over time, to notice patterns of usage before they become a problem.)

# display usage of sharepoints
# (whereis enables it to be run on non-MOSXS system w/o err)
# ((anyone know of a call available on MOSX (client) system?))
if [ `whereis sharing` ] ; then sharing -l | grep path | awk '{print $2}' | xargs -n1 du -ks; fi

# OR

# show usage of dirs in /shares - if it and they exist
if [ -d /shares ] ; then if [ "`find /shares -type d -mindepth 1 -maxdepth 1`" ] ; then { find /shares -type d -mindepth 1 -maxdepth 1 -print0 | xargs -0n1 du -ks; } ; fi; fi

(NB: Both are single lines and must be run as root.)

The nice thing about the second variation is: If you config your servers so that all "shares" are in the "/shares" directory (or maybe the "shares" directory at the root of each mounted volume), it shows the status even if they're not shared at the moment, which can be handy.

PX502 and Retrospect (update)

2008-01-08T06:55:00.000-05:00

(Update to previous post.)

I now have it working; here are the changes:

New replacement PX502 from Quantum.
Directly connected (via FC) to Retro CPU.
(And therefore using only a single drive, since this CPU has only 2 FC interfaces. :()

Points to Quantum for (FINALLY) sending the full, new replacement unit instead of continuing to "nickel & dime" parts.

Points to EMC Insignia for suggesting a direct connect.

Serious points taken away from EMC Insignia for not working via a FC switch! :(

More points taken away from EMC Insignia for not adequately testing the PX502 - contrary to explicit support ("Qualified - Passed extensive in-house certification. Storage device is fully supported.") on their website.

More points taken away from EMC Insignia for saying they finally got a PX502 to test (!) and stringing me along on the results - still haven't heard and they last told me they'd give me an update a few weeks ago. :(

More points taken away from EMC Insignia for trumpetting that they'll be at MacWorld - talking about the moribund V6.1. I just hope and pray that's a smokescreen for the REALLY LONG overdue next version. We'll see soon enough...

MOSX username/password login from the icon view

2007-12-23T17:35:00.000-05:00

Here's one that's simple - and then you forget, since you don't use it that often -- and then you can never find the sequence for doing it again!

You're at a standard iconic login screen and you want a username/password login instead - from which you can use ">console", ">restart", or log in as a user not otherwise shown.

Press an arrow key; it doesn't matter which. One of the icons highlights - but doesn't bring you to the next screen, where it asks for that user's password.

NOW press Option-Enter - bingo; the username/password login window.

ARD Admin "screen sharing available" - and nothing else

2007-12-21T10:32:00.001-05:00

Strange ARD Admin behavior recently; some machines starting showing a status of "Screen sharing available" - and that's it; other functions (ex: "Send UNIX command", "Upgrade Client Software", etc.) do not work.

Probably something to do with the new "Screen Sharing" feature standard on Leopard, though I don't know exactly how.

Deleting that node (all occurrences) in ARD Admin, and then re-adding did not work. Nor did running the latest ARD Client upgrade on the target machine. Nor kickstart, nor...

Then I noticed the same machines worked properly from another machine's ARD Admin, so I started looking at its config on mine. Interesting, though no smoking gun.

So I re-ran the installer for ARD Client 3.2.0 (which is actually 3.2.1) and ARD Admin 3.2.0 - all's well again. And I don't have to rebuild all my carefully-crafted lists of machines - nice!

Xsan 1.4.2

2007-12-20T20:08:00.002-05:00

Unfortunately, another vote for sticking with Xsan 1.4.1 - I just downgraded and my Xsan is _much_ happier and much less flaky. Luckily a fairly simple process.

A few random Xsan tips and tricks

2007-12-19T21:12:00.000-05:00

Make absolutely certainly DNS works and is configured properly. Absolutely.
Be really careful doing anything that might interrupt the Xsan volumes. Especially if those volumes are shares; that can get ugly, maybe requiring a forced power down. Best policy is to dismount the volumes from all Xsan clients, stop the Xsan volumes, and _then_ do whatever you need.
Anything at all; some XSR (Xserve RAID) operations cause _both_ controllers to restart (ex: firmware upgrade) - including the other one, that's part of the Xsan, that you thought wouldn't be affected.
When copying files with extended attributes (ex: ACLs or resource forks) to an Xsan volume, the extended attributes are automagically copied to an "AppleDouble Header" file that's named the same as the original file, except with "._" prepended. (Transparent to the user and/or application; slick.) Interestingly, the mod date on the AppleDouble Header file is the date of the copy. Also, if you want to sanity-check the copy, good luck - most tools (ex: diff and cmp) simply ignore the AppleDouble Header file and if you attempt to compare the extended attributes directly, you'll see that their order is not guaranteed, so you must compare attribute-by-attribute.
How to decommission a Controller? I don't know, however if you demote it to a Client first, at least the logs won't fill up with messages about how the Controller can't be found. I say "first" because I believe it's necessary to do it while the machine is still live on the Xsan.
It's critical for all Controllers to agree - and can be ugly if you perform operations on a Controller that's lost sync with the rest - so sanity-check by adding the following (single line) to the periodic/daily (presuming you read the results, maybe by email) on each:
if [ -d /Library/Filesystems/Xsan ] ; then echo ""; echo "Xsan status:"; cvadmin -e select | grep -F '>'; fi
Do run multiple MDCs; even if you never have an unplanned event, you _will_ have a planned event (ex: software upgrade) that multiple MDCs will render trivial.
Check all the docs (PDFs, "ReadMe"s, KB articles, AFP548, Xsanity...) carefully - and consult with someone else before performing anything dramatic. Like, just for the sake of example, "cvfsck -j" and "cvfsck -wv".
Sometimes it's the simple stuff that gets you: For example, check _both_ Ethernet interfaces; the one used by the Xsan MDCs and the one used to talk to the rest of the world; just because you can ping out, doesn't mean the Xsan Ethernet cable didn't come loose.
Sharing an Xsan volume out? Watch out for the 16TB limit; I believe this applies to SMB as well as AFP; not sure about NFS.
Do use hot spares; the performance you lose is rarely missed - though your weekend might be, without them.
Do configure the Xsan email warnings; it should be quite infrequent and you will want to know, even if its "just" switching Controllers and none of the users noticed.
Same goes for battery backup modules; it's "penny wise, pound foolish" to skip them.
No, you can't shrink a volume and re-allocate a LUN; only grow. (BTW: It's possible to grow an XSR LUN - though there's no Apple volume format yet capable of surviving this; you must back up before and restore after.)
Yes; you can configure multiple LUNs on a single XSR side. Not optimal, though a reasonable tradeoff for some situations.
Just because it's so big, makes it difficult to back up - and, critically, that much more important to back up.
Make any modifications using Xsan Admin logged into to the Xsan via the Xsan Ethernet interface of the Primary (active) Controller. Maybe not strictly necessary, but safer.
Be aware of the power config; if one XSR is on a UPS that's loaded, and it runs out of power before the MDCs shut down, it'll be ugly. (BTW: Take advantage of the redundant power supplies on the XSRs; plug each into separate UPS units.)
Make notes as you go; you never know what you might need later, in a rather frantic time.

Leopard keyboard problem (solved?)

2007-12-15T20:51:00.000-05:00

Interesting; Now and then, since upgrading the Leopard, the keyboard becomes unresponsive - no reaction at all.

Update 2 (prev in comments): Apple released MacBook, MacBook Pro Software Update 1.1 today; just installed so confirmation to come...

No idea what the problem is (and 10.5.1 does not solve it) though here are some workarounds I've found:

- Sleep, wait at least 30 seconds, wake.
- Press the option key five times in a row. Or the shift key. Then try a key. If not yet, try again.

Pressing the option or shift key, five times in a row may be total voodoo, though it does appear to work; it occurred to me by accident, though those are actually defined key sequences: the shift variation turns on "Sticky Keys"; option is for "Mouse Keys". (See the Universal Access preference pane for more info.)

And since they can change how the keyboard input is interpreted, it may indeed kick something back into gear.

Also: Here's a hint to tell if the keyboard is responding: Press "Caps Lock"; you'll either see its light go on or not; immediate feedback, without wondering.

(I've also seen, though only a few times, the mouse cursor get _very_ confused; maybe a strange USB gremlin has crept in.)

BTW: Fire up the "International" preference pane, click the "Input Menu" tab and check "Keyboard Viewer". (Or if it is already checked, check the "Show input menu in menu bar" item at the bottom.) Now select "Keyboard Viewer" from the international menu (which uses an icon of the flag of the localization you're using) and you've got keyboard input by way of the mouse/trackpad; handy when the keyboard isn't working. :)

smarter ping

2007-12-05T20:47:00.001-05:00

while true ; do echo "`date`: `ping -qc1 domain-name | grep round-trip`"; sleep 5; done

A one-liner that does, in order:

show the date/time
show the *results* of a single ping (or nothing), on the same line
wait 5 seconds
do it all over again

And it simply does this til you kill it.

Why? Simply ping'ing doesn't give you any info on *when* things are happening - like when the server that you're waiting to reboot, did; or when the node you're testing stopped responding.

ID a card/port pair, given a simple serial jack number

2007-12-04T22:08:00.001-05:00

We recently installed a really nice Foundry switch (highly recommended) and its admin (as is generally the case) requires addressing ports by the combination of card and port number. However the cables jacking into it are numbered serially; from 1 to whatever.

So when you need to find which cart/port corresponds to which jack, it can get messy - here's a simple script (easily adapted to other scenarios) to simplify:


#!/bin/bash

# simple script to calc the card/port pair, given the patch cable #
# - result is returned as an integer, in format: port + (100 * card#)

# History:
#
# 20070523 mvgfr: incep

# minimal error trapping:
if [ -z "$1" ] ; then exit 0; fi
if [ "$1" -le 0 ] ; then exit 0; fi

patch=$1
# fudge for discountinuity; jump from card #8 to #13 (since there are no port cards in slots 9-12)
if [ "$patch" -gt 192 ] ; then let patch+=96 ; fi

card=$(( ( ( $patch * 100 / 24 ) + 99 ) / 100 ))
port=$(( $patch - ( ( $card - 1 ) * 24 ) ))

echo "$card, $port"

result=$(( ( $card * 100 ) + $port))
echo $result

exit $result #send the result back as the exit code, for potential further processing...

#end

MOSXS 10.4.11 & Xsan 1.4.2

2007-12-04T22:00:00.001-05:00

Haven't seen much discussion of this, so here's a "vote":

Just upgraded a three-node Xsan to MOSXS 10.4.11 and Xsan 1.4.2; worked like a champ on all three: dual G4 (800MHz) desktop, dual G5 desktop and dual G5 Xserve. (FWIW: It's attached to four XSRs of widely-varying ages, via a QLogic SANbox 5200.)

The volume stayed online, as designed, the whole time, including four reboots - I missed the 10.4.10 update (required for Xsan 1.4.2) on one of the nodes, so had to install 10.4.11, reboot, then Xsan 1.4.2 and reboot on that one.

Apple changed the specs since the 1.4(.0) release (of Xsan) to exclude G4 desktops, so I'll probably replace it with another G5 desktop/Xserve at some point soon, though I don't see any need for urgency.

find the mdns name for an IP addr

2007-12-01T21:37:00.000-05:00

This seemed like it might be useful and then after I dug through to finally solve the problem, it may be for only a very limited set of circumstances. :)

And interesting script anyway: Given an IP address, find the mdns (AKA ZeroConf or Bonjour; formerly Rendezvous) name - which might help give you a better idea who's there):


#!/bin/bash

# use mdns (local subnet only) to show machine name for a given host IP addr
# (ex: for machines w/ DHCP addrs and therefore unintersting domain names)

if [ -z "$1" ] ; then echo "must supply a host as 1st/only arg"; exit; fi

if [ -n "$2" ] ; then echo "must supply only one arg"; exit; fi

# is it necessary to ping it first, to make sure it's in the ARP table?
#if ! $(ping -c1 "$1") ; then echo "error pinging host"; exit; fi

if ! arpOutput=$(arp "$1") ; then echo "error in arp host"; exit; fi

arpMAC=$(echo "$arpOutput" | sed 's/.*\([a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2
\}:[a-zA-Z0-9]\{1,2\}\).*/\1/g')
arpMAC=$(echo "$arpMAC" | sed 's/^\(.\):/0\1:/' | sed 's/:\(.\):/:0\1:/g' | sed 's/:\(.\):/:0\1:/g')

echo "starting mdns browse; you'll have to hit ^C to get control back..."

dns-sd -B _workstation._tcp | grep "$arpMAC"

# end

Script to notify if any outdated MacPorts

2007-12-01T21:29:00.002-05:00

Updated version here.

-----

Add the script below as a cron job and it'll notify* you if you have any outdated MacPorts.

*Presuming you're configured to have cron job output emailed to you, it'll notify by email. If you have growl installed, it growl at you too. Lastly, it logs to /var/log (which probably requires creating that log file first).

(Updated for recent tweaks.)


#!/bin/bash

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

# may take awhile; is this an issue?
/opt/local/bin/port sync

potentialOutput=`/opt/local/bin/port outdated`

if [ "$potentialOutput" != "No installed ports are outdated." ] ; then
    echo "$potentialOutput"
    if [ -f /usr/local/bin/growlnotify ]; then
        /usr/local/bin/growlnotify -H localhost -s -m "macports: $potentialOutput"
    fi
fi

echo "`date "+%Y%m%d-%H%M%S"`: $potentialOutput" >> /var/log/port-outdated.log

#end

timestamp bash history entries

2007-12-01T21:06:00.000-05:00

Wow; bash3 has a terrific feature; the shell variable HISTTIMEFORMAT will timestamp entries in your history - so you can get a *much* better idea of what happened, especially since it's so easy to have multiple sessions going at the same time, so that commands in the history get somewhat interleaved.

Add

HISTTIMEFORMAT='%Y%m%d-%H%M%S: '

to (for example) your .bash_profile.

And Leopard (MOSX 10.5) has bash3 by default; nice.

MOSX: My $PS1

2007-12-01T20:55:00.000-05:00

PS1='\[\e]0;\u@\h\a\]\D{%Y%m%d-%H%M%S} \u@\h \W [\j]\n$ '

This sets the Terminal title bar to:

user@node - current-command

Which is dynamic; it changes as you issue commands. (Slick.)

And it sets the prompt to:

date-time user@node working-dir [jobs]
$

It's an awfully long prompt, so it wraps, and puts the familiar "$" at the start of the *second* line.

Why? It's sometimes *very* handy to have the prompt indicate when that command was issued.

(BTW: Bracketing the window title bar potion in "\[" and "\]" is critical; otherwise (since it doesn't print those char in the prompt itself) readline will miscalculate where you are on the line and things get ugly.)

Show ALL recently-modified prefs

2007-12-01T20:45:00.000-05:00

Search 'full-path' for plist (pref) files that were modified more recently than 'ttt' (ex: '5 minutes ago') and dump them in human-readable format:

find 'full-path' -iname '*.plist' -newermt 'ttt' -print | xargs -n1 | sed 's/.plist$//' | xargs -n1 defaults read

(Note: It is important to specify a *full* path.)

Issue a sequence of commands, and walk away

2007-12-01T20:18:00.000-05:00

You're ssh'd into a server and need to issue a sequence of commands that'll take awhile - and your connection might drop, terminating those commands. Try this:

nohup bash -c "cmd1; cmd2; cmd3" &

Which starts the sequence and sends it immediately to the background (the trailing ampersand) - and also sets it so that even if the controlling terminal goes away, it continues to run (via "nohup"). If you really do need to kill it, use the -KILL signal.

Caveats: Watch your stdin/stdout/etc - this is generally most useful for commands that require no input and generate no output, since, for example, you just disconnected stdin and stdout by sending it to the background.

The above is handy to know if you need to sudo the commands - since you will: a) not see the "Password:" prompt, and b) not be able to respond to it. Here's the cheat: As long as you're in a default ssh config, there's a timeout; sudo commands issued within the timeout don't prompt. So if you need to sudo the above, issue an innocuous "sudo ls" (or some such) just before, to authenticate and get the timer running.

To find out what background jobs there are:

jobs -l

Which also shows the process ID, so you can watch it via top or some such.

Want a little more feedback? How about:

nohup time bash -c "date; cmd1; cmd2; cmd3" &

Which will display the date the inner commands started and then some stats about the time the other commands took, after they're all done.

Need to make sure they each work, before going to the next? Try this:

nohup bash -c "cmd1 && cmd2 && cmd3" &

The double ampersand tells bash to execute following commands ONLY if the previous one succeeded. (More specifically, if it's exit code was zero.)

And you can get more fancy by putting some "echo" commands in there, piping the output to mail, etc.

Validate/verify MD5 or SHA1 hashes

2007-12-01T20:00:00.000-05:00

Want to confirm that download hasn't been altered?

MD5:

if [ $(md5 -q pathHere) == 'md5-hash' ] ; then echo "OK"; else echo 'md5 hash mismatch!'; fi

SHA1:

if [ $(/usr/bin/openssl sha1 pathHere | awk '{print $NF}') == 'sha1-hash' ] ; then echo "OK"; else echo 'sha1 hash mismatch!'; fi

Substitute the path of the file to validate for "pathHere" above; similarly, the published hash for "md5-hash" or "sha1-hash".

Sure you could wrap it in a script, by why bother, when you have QuickSilver?

MOSX: Open a subfolder on a share, whether the share is already mounted or not

2007-12-01T19:47:00.000-05:00

Mac OS X's "open" shell command is powerful - though strangely dependent on the mount state of shares.

Executing

open afp://server.example.com/share/top-folder/sub1/sub2

Will open the share - and, if the share was already mounted, ignore the rest of the path.

So, here's a quick command (make sure it's all one one line) that will open the subfolder, whether the share is already mounted or not:

if [ -d /Volumes/share ]; then open /Volumes/share/top-folder/sub1/sub2 ; else open afp://server.example.com/share/top-folder/sub1/sub2 ; fi

Adaptation for other protocols (ex: SMB), other mountpoints and error-checking are left as an exercise for the reader. :)

Help! (PX502 and Retrospect)

2007-12-01T19:34:00.000-05:00

I've got a Quantum PX502 tape library on Fibre Channel that I'm *attempting* to use with the EMC (formerly Dantz) Retrospect backup application (running under Mac OS X Server 10.4.10) - and it's giving me fits!

It won't complete a backup; each time, Retrospect loses contact with the PX502 before it completes; usually *well* before it completes. At this stage, it's usually an error 205 (from Retrospect) and "Bad reply received" from the PX502.

Quantum has sent NCR techs out to work on it, though it's actually gotten worse since they started. :/

EMC says the detailed SCSI log shows activity they're not familiar with - and they *just* got a PX502 to test (!) -- even though the EMC compatibility DB specifically shows this config as supported. (Quantum's DB also shows this is a supported config.)

Is there *anyone* out there using a PX502 with Retrospect? I'd appreciate *any* feedback at all!

Kerio, Palm, VersaMail & ActiveSync

2007-12-01T10:54:00.000-05:00

Interesting mix of several technologies that looks pretty useful.

Had some trouble putting all the pieces together, so here are some clues for anyone else in a similar boat:

Check the Kerio config; what ports is it using? Are the services you want (ex: https) on?
Triple-check the firewall config. (It's the *really* silly things that get you...)
Yes, you probably do need the magical EAS SP2 update though check the Palm Support site for some model/service -specific info first.
VersaMail apparently allows only a single account to be configured for ActiveSync; the choice simply does not appear if another account is already using it.
If you're using a self-signed cert, there are some pitfalls; see info in links below.
If you're using a wildcard, it likely will not work. If you're a DigiCert customer, they've got you covered: They issue a credit to your account to cover a single domain name cert which will be fine. And if you need to change the server name, they've got a handy (and fast) "Reissue" button for you. Well done, folks!
And the key my boss found: Specify the server address (in VersaMail) via IP address instead of domain name; strange.

Some other refs that may be helpful:

And the Right Shall Inherit the Earth

2005-01-27T08:19:00.000-05:00

You did see that coming, didn't you?

Whingers and infosec

2005-01-14T07:23:00.000-05:00

Was looking for a definition of this British-ism (whinger basically equals whiner) and came up with a great one [original link; stale] [Google cache link] - and a bonus! A really good discussion of the realities of infosec; why the "no one understands me" that we often whine, is dysfunctional - and what to do about it.

A big thank you to the author, Jay Heiser.

Dancing with HotSync

2005-01-03T20:35:00.000-05:00

Had an interesting dance with Palm today, trying to get my Kyocera 7135 to HotSync under Mac OS X:

The computer wasn't responding at all, when I pressed the HotSync button, and I was pretty sure it wasn't a hardware failure of some kind. But I tried a few things anyway, and found no hardware faults - the Mac actually saw that the 7135 was plugged in. (Via the USB tab in "System Profiler".)

(BTW: The 7135 is still the best out there, for what I'm looking for: A real Palm device (for apps, Mac compatibility (though the future looks cloudy...), reminders even when "off net", etc.) and a real phone. Bonus that it's a flip format which I still prefer.)

So I started playing software games.

I'd seen lots of reports of HotSync problem under recent versions of Mac OS X, but had never had them myself, so always chalked them up to other problems. I looked at those reports anyway. I looked at related links. I compared other systems that were able to HotSync successfully. I checked out my backups. Nothing.

I tried re/installing. I'd been putting it off for awhile, since the latest minor release didn't have anything that I was interested in, but now seemed like a good time to do it - maybe in a bit of spring cleaning, I'd yanked a critical piece, and the installer would put it back. This was an adventure I wasn't looking for.

First, the installer is stupid; it wants to run as root. Otherwise (even after authenticating as an admin user) it whines at the end about failing, giving you a chance to try again - and fail again -- with zero indication of what the real problem is.

Running as root works great - except if you're logged in as root to do it, since it of course isn't installing the stuff in your user folder and therefore won't sync when you log in as yourself. Here's where knowing some command line or having something like Pseudo can be pretty handy. Luckily, not too many installers are still stupid. (BTW: Is FirstClass still in this category?)

Anyway, even this didn't help (but at least the installer wasn't erroring out), so I did a bit more Googling. (I coined the phrase "Never underestimate the power of Google." And it is oh so true.) Anyway, I found a few things to try, but nothing freed the logjam.

The I remembered something I'd see again recently, in a few blogs (ex: [Link]): Holding down the shift key: either while booting (for a "safe boot") or while logging in (to skip user startup items). I tried the latter and suddenly it was able to HotSync!

I remembered that I'd cleaned out a few of the startup items (via the Accounts System Preference pane) recently, so maybe that was the root of the problem. I noted the remaining ones and started to attempt to find where the problem was. I say "attempted", since I never found out - they're all back on and HotSync'ing is working fine. I don't know if it was some combination of the earlier debugging steps, or just plain voodoo. Yuck. :(

But at least I can HotSync again and get on with my life! :)

Get an ID card or we'll shoot you

2004-12-09T13:21:00.000-05:00

Should be interesting to see what this sort of thing yields - even in a war zone.

Probably a good boundary condition for the general case...

Super HiRes photos

2004-12-09T13:14:00.000-05:00

Not really a huge shock for photographers, but a big one for the digital folks. :)

Lise, Damned Lies, and Statistics (Disraeli)

2004-12-09T13:02:00.000-05:00

No matter which side you're on, a quite humourous dip into stats. :)

Home tech support

2004-12-08T19:15:00.000-05:00

PowerBook video issues

2004-12-08T10:23:00.000-05:00

Having a wierd problem with a PowerBook G4/12" and a ViewSonic PJ350:

Suddenly can't get video over the projector (same equip has worked well in the past) - but the PowerBook thinks it's sending video that way, since it has moved the primary output over to that, so all that's on the built-in LCD, is blank desktop and a moving cursor. Removing the video adapter from the PowerBook causes it to switch back to the LCD, so it's not a hang/crash.

Not sure what the fix is yet, but found some great resources/info at SFSU AV:

Portable Mirroring Activation Chart.
PB G4 mirroring tips.
AV Tutorials and Hints.

and the best collection I've seen, of magic Mac key combos.

Security: Not just theoretical & not just for geeks

2004-12-06T10:19:00.000-05:00