One silly feature omission in Apple Remote Desktop is the lack of a "Open SSH connection" command. To be able to open a Terminal window with a connection to the currently selected machine. Luckily we can create this ourselves pretty easily:

tell application "Remote Desktop"
    set theIp to Internet address of selection
    set defaultUser to current user of selection
    set theUser to text returned of (display dialog "" default answer defaultUser)
    tell application "Terminal"
        activate
            do script "ssh -l " & quoted form of theUser & " " & theIp
        end tell
end tell

Save that as a script with AppleScript Editor named "Open SSH connection" under ~/Library/Scripts/Applications/Remote Desktop and now you have way to do just that straight from the menu bar.

There's a bug in iCal that in some situations will show every name twice when adding attendees to an event. Adding one of them will always give an error (the oh-so-not-helpful tiny exclamation mark next to the name). iCal will still add that "ghost", but the invitation will obviously never be sent.

At first this looked a bit like the proxy bug, but since this isn't about delegates, but actual user accounts (and since running proxyclean didn't find any errors) I turned my attention to Open Directory. Luckily, iCal Server 2 comes with actually helpful logging, even at Information log level, just:

    tail -f /var/log/caldavd/error.log

and you'll be able to see exactly how caldavd is talking to OD. Looking at that I was able to determine that OD was actually returning all the right search results (when the user was typing a name of the attendee). But even when OD returned just 1 record, iCal would still show 2. Then I remembered seeing a button iCal > Preferences > Advanced called "Clear Attendee Cache"

"Yes! The attendee cache! Sounds like just the thing!" - I yelled, only to find the button no longer there, in 10.6:

Well, let's make that "button" ourselves. Fire up Remote Desktop, select the ailing machines, Click "Send UNIX command" (as the currently logged in user), and:

    killall -m '^iCal$'
    mv ~/Library/Caches/com.apple.iCal ~/.Trash/
    open /Applications/iCal.app/

And voilà! Problem solved!

If your organisation uses Nokia phones, then by default, a stock 10.6 mail server will be pretty much useless to them. Even with some fairly recent hardware (E72), the phones won't be able to send or receive any mail. Here's how to make it work:

• Enable PLAIN authentication for IMAP, POP and SMTP. This isn't such a big issue if you're using SSL. Some Nokia's might actually do CRAM-MD5 off the bat, but sooner or later you will run into a user who can't log in.

• Enable "SMTPS" support in Postfix. "SMTPS", on port 465, was a "brilliant" Microsoft idea to start using port 465 for secured SMTP connections after they apparently couldn't get Outlook 2000 to work with port 25. They just missed the fact that 465 had already been assigned to another protocol by IANA. What's fine for Microsoft's fine for Nokia, unfortunately, changing the mail client on a mobile is a bit more difficult than moving your poor Outlook user to Thunderbird, so:

  sudo nano -B +30 /etc/postfix/master.cf
  <uncomment lines 30-33> and save
  sudo postfix reload
  

And also don't forget to forward tcp/465 to your mail server in your firewall.

In my experience the thing that Mail users have the most problems with (even before the confusion about how IMAP folders are organized compared to Outlook) is how it handles attachments. Or rather how incompatible the default behaviour is with a lot of Outlook clients out there. A couple of preferences that I've found improve things quite a bit are:

defaults write com.apple.com SendWindowsFriendlyAttachments -bool Yes
defaults write com.apple.com AttachAtEnd -bool Yes

It's the second one, disabling inline attachments, that really makes a difference. Now if only there was a way to always display attachments as icons...

A customer was having problems with server-side Spotlight searching in Finder giving inccurate results - basically using a partial file name would give less results than with the whole name. When rebuilding the index didn't help I began to study this problem closely...

... which lead me to the discovery of yet another "undocumented (bad) feature" in Finder and more importantly, Spotlight. When you use the built-in search field, the search term is not "any name that contains this" or even "any name that starts with this", but rather "any *word within a name* that contains this".

The following illustrates this (I use mdfind to save bandwidth, but the results are the same from the Finder GUI):

$ mkdir sltest
$ cd sltest
$ touch summertime.txt
$ alias mdfind="mdfind -count -onlyin $PWD"
$ mdfind summer
1
$ mdfind time
0
$ mv summertime summerTime.txt
$ mdfind time
1
$ mv summerTime.txt summer\ time.txt
$ mdfind time
1
$ mv summer\ time.txt sumMertime.txt
$ mdfind time
0

... you get the idea. The default search in Finder and mdfind uses a weird matching logic which differs from what most people would assume. The problem exists on both server and workstation versions of 10.5.6.

The good news is that there is a workaround - always use the Cmd-F Name > contains criteria for the broadest search, giving you this:

instead of this:

Spotlost indeed. :-)

HansaWorld Enterprise is probably the most used enterprise-level business software for the Mac in Europe (maybe because it's the only one). It's been around for ages and so has picked up a bit of cruft along the way (I hear there's a native Cocoe port in the works, but we'll see). This means that when it works, it works, but when it starts to crash, you're options are to try what little tricks you may know yourself, pay an insane amount of money to have some guy look at it, or just restart it.

You can easily automate the latter with combining launchd and a bit of shell:

#!/usr/bin/env bash
# /Library/Scripts/hansakicker.sh

if ps -Ac | grep -q hansa51 ; then
  logger "Hansa is running, no need to restart"
  sleep 10
else
  sleep 10
  logger "Hansa crashed, restarting"
  launchctl start my.hansa.launchd
fi

exit 0

A couple of obvious things to note: in this case the Hansa binary is called "hansa51", it may differ in your install. The sleep commands are there to calm launchd down. The second sleep comes before everything else to give CrashReporter time to finish up. Also this assumes that Hansa's being started from launchd, ie with something like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">   
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>fi.humac.hansa5</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Applications/Hansa5/hansa51</string>
  </array>
  <key>RunAtLoad</key>
  <true/>

  <key>WorkingDirectory</key>
  <string>/Applications/Hansa5</string>

</dict>
</plist>

In the launchd part, we are simply looking for the moment Hansa's crash log is modified:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.$
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>my.hansa.hansakicker</string>
  <key>OnDemand</key>
  <true/>
  <key>ProgramArguments</key>
  <array>
    <string>/Library/Scripts/hansakicker.sh</string>
  </array>
  <key>WatchPaths</key>
  <array>
    <string>/Library/Logs/CrashReporter/hansa51.crash.log</string>
  </array>
</dict>
</plist>

Once everything's been set up and loaded in, we can do a test:

touch /Library/Logs/CrashReporter/hansa51.crash.log

... which should trigger the script.

Obviously this is little more than a band-aid and you should really do something about it if this happens daily, but is more than useful for those intermittent Saturdays when you're salesforce is working and you're not. :-)

Syncing notes from Mail.app to your iPod touch is not as bad as it may seem. I wanted to put a shopping list on mine, and almost joined the angry hordes when I couldn't find a "Notes" checkbox in the syncing prefs, but it turns out all you have to do is save the note on any IMAP account (must have "Store notes in Inbox" option checked under Mailbox Behaviours) and then check your mail on the iPod.

This isn't as slick as a local sync and it litters your Inbox, but it works and is certainly better than having to jailbreak your iPod or buying a 3rd party app just to get a piece of text onto it.

Notes are simply HTML-encoded "emails" with the special header "X-Uniform-Type-Identifier: com.apple.mail-note" and no "To:" header.

Just remember to check your mail before you leave the house - at least our grocer doesn't have free WiFi (yet). ;-)

Every now and again you run into silly (but useful) sites with silly (and useless) session timeouts with no means of changing them. So you do something else while working with the sites only to come back and find out you've been logged out.

Well, here's a little script to help with this situation:

property reloadInterval : 120
property reloadUrls : {"gsx", "mac.com"}

on idle
    tell application "System Events"
        if (application "Safari" is not frontmost) then
            tell application "Safari"
                repeat with anUrl in reloadUrls
                    repeat with theDoc in (every document whose URL contains anUrl)
                        do JavaScript "window.location = window.location" in theDoc
                    end repeat
                end repeat
            end tell
        end if
        return reloadInterval
    end tell
end idle

Just set your preferred interval in seconds. This hack is particularly nice IMHO in that it even lets you set a list of partial URLs the pages to be reloaded should contain. Also, it checks System Events to make sure we're not actually in Safari. Just don't forget to switch to another app for this to work. ;)

Oh, and the on idle stuff only works if you save it as an application and check "Stay Open".

At least once a week, I run into a situation where I want to revisit a site I had visited earlier but forgot to bookmark or didn't even think of bookmarking. All I can remember is a part of the page's title. Wouldn't it be nice if there was a slick tool that would allow you to quickly search your browser history? I was all ready to fire up XCode when I discovered that the Safari team had already thought of this.

Simply hit Cmd-Option-B and type something in the little search field in the bottom of the window.

Could maybe be a tad quicker (without having to click to focus on the search field), but a really useful feature nonetheless.

This came up on comp.sys.mac.system - how could you easily change a users password without having admin access to the system? Say a customer asks you to install Final Cut Studio before going into a meeting and forgets to give you his password (or writes down the wrong one, or whatever). Do you just wait for the customer to return and tell them they'll have to wait another 45 mins for the 30+ GB to finish installing?

You could always just reset the password with the help of the OS X install disc, but there's an easier way and one that will actually let you restore the old password. All you need to know is the owner's user name (actually you can do some more dscl digging to use their real name as well).

You start off by booting into Single User mode (Cmd-S) and then:

mount -uw /; sh /etc/rc
cd /var/db/shadow/hashes
guid=`dscl . -read /Users/username GeneratedUID | awk '{print $2}'`
cp $guid $guid.old
passwd username
reboot

You can now log in as that user with your new password. When you're done, just boot back into Single User mode and mv the .old hash file back in place. Just make sure you test that the owner can log in when they get back. ;-)