The Twitter OAuthpocalypse arrived on September 1st. Starting on that date Twitter API clients are required to use OAuth and are no longer allowed to use basic authentication. This change broke more than a few applications that were unprepared for the change. One of those apps is Keynote Tweet.

Keynote Tweet is a simple AppleScript utility that allows you to send tweets from your Keynote presentations. Keynote Tweet uses the curl command-line utility to submit tweets to the Twitter API. Unfortunately there is no easy way to implement OAuth using the curl command-line. It also appears that it would be very difficult to implement OAuth directly in AppleScript.

One solution to making Keynote Tweet work again is to replace curl with twurl. twurl is a curl-like command-line utility for the Twitter API written in Ruby. twurl’s installation and OAuth setup is simple. The twurl syntax is not identical to curl’s, but it is simple to swap twurl out for curl in the Keynote Tweet AppleScript. Simply change the call to curl:

do shell script "curl --user " & twitter_login & " --data-binary " & twitter_status & " http://twitter.com/statuses/update.json"

 

To a call to twurl:

do shell script "twurl -d " & twitter_status & " /1/statuses/update.xml"

 

The keyring code in the original script is no longer necessary and can be ripped out of the script. You can download the updated script and documentation here:

Download Keynote Tweet 2
 

June 21, 2010 Update: Apple appears to have solved the problem for many of us with the release of Snow Leopard 10.6.4.

To save you time I’ll give you the solution first then describe how I found it: Turn off Unix extensions in your Samba server by adding the following line to smb.conf in the global settings block and then restart Samba:

unix extensions = no
 

You might also need to unmount and re-mount your Samba volumes from OS X after you make this change.
 

After installing the OS X Snow Leopard 10.6.3 update I found that I could no longer write to Samba (SMB) volumes shared from my Linux server (running Ubuntu 9.10 Karmic Koala) that I had mounted on OS X. Whenever I tried to copy a file from OS X to the mounted Samba drive I got the error message:

The operation can’t be completed because you don’t have permission to access some of the items.
 

Apparently a lot of other people are having the problem as well:

• 10.6.3 Update Breaking SMB Mounted Volume Write Access for Many
• Topic : After update to 10.6.3 copy to a Samba share fails
• Topic : No rights to write on SMB mounted volume after updating on 10.6.3

I couldn’t find the solution anywhere on Google, and I spent hours today searching. I finally found the solution serendipitously while trying to fix another Samba issue. While scouring the system and Samba logs on my Linux server to try to find a clue to the first problem I found a bunch of warnings like the following repeated over and over in the Samba log:

[2010/04/05 00:08:37, 0] param/loadparm.c:9783(widelinks_warning)
Share 'documents' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
 

This warning started logging on March 24th, the same day that Ubuntu announced and patched a vulnerability related to the Samba wide links option: Ubuntu Security Notice USN-918-1. According to Using Samba by Robert Eckstein, David Collier-Brown and Peter Kelly you should not turn off the wide links option for performance reasons. (See Appendix B: Samba Performance Tuning.) Since I use Samba for just about everything I decided that performance was more important than Unix extensions so I added the following to my smb.conf in the global settings block and restarted Samba:

unix extensions = no
 

To my amazement and delight, this had the welcome side effect of solving the Samba write access issue I was having with OS X. To verify that this is really what solved the problem I re-enabled Unix extensions and restarted Samba and the write access problem returned. Then I turned Unix extensions off again and restarted Samba and I could write to all of the Samba mounts again from OS X. So if you are having problems writing to Samba mounts from OS X ask your system administrator to turn off Unix extensions in the server’s Samba configuration.
 

I’ve had emails and comments that point out that there are advantages to having Unix extensions on. That’s true and this should be considered a workaround rather than a fix. When (if?) Apple fixes the underlying problem you should turn Unix extensions back on in your Samba server.

A very brief introduction to virtualization on the Macintosh and a high level comparison of VMWare Fusion 3 and Parallels Desktop 5. [View on SlideShare to see the notes]

I recently had several tracks stop playing in iTunes and they all had one thing in common, a duration of 789:57:13. The recommended solution for this problem is to re-rip or re-download the track. That wasn’t an option for some of these tracks because I purchased them through iTunes and the official Apple stance is that you are only allowed to download a purchased track once and I didn’t want to re-purchase the tracks. Restoring from backup also wasn’t an option for some of the tracks because they were munged in even my oldest backups.

The solution I found was faad and faac – Freeware Advanced Audio Decoder/Coder. It will decode unencrypted AAC/MP4 files and will happily ignore and correct the munged frame duration in the MP4 wrapper. I recovered a damaged track like this:

faad "09 This Devil's Workday.m4a" -o "09 This Devil's Workday.wav"

mv "09 This Devil's Workday.m4a" "09 This Devil's Workday.m4a.bad"

faac -w --artist "Modest Mouse" --title "This Devil's Workday" --album "Good News for People Who Love Bad News" --track 9 --disc 1 --year 2004 "09 This Devil's Workday.wav"

As faad was decoding the original track it showed that the MP4 wrapper’s duration was, but it corrected as it decoded it.

MP4 seems to have incorrect frame duration, using values from AAC data.
Decoding 09 This Devil's Workday.m4a took: 1.62 sec. 85.94x real-time.

When faad/faac were done I was able to re-import the track into iTunes and play it successfully.

Caveats

I lost some of the iTunes metadata from the original track, mainly the cover art. iTunes automatically added the cover art when I re-imported it, but that only works for music in the iTunes library. In those cases, faac has an option to import cover art from an external image file. You can do the same thing with iTunes as well.

If you have a lot of tracks to repair, adding the metadata manually on the command line is tedious. However, it could be automated with a simple script that captures and processes the output of faad since it displays all the track metadata as it is processing.

How I hate Microsoft Word's Edit|Paste Special menu item. Why can't Microsoft assign a keyboard shortcut to it? It is a maddening oversight and it makes me crazy when I just want to past some unformatted text – stop typing, reach for the mouse, click Edit, click Paste Special, click Unformatted Text and finally click OK. Four mouse clicks and one interrupted workflow later I have my unformatted text. Apple applications have a Paste and Match Style menu item with a keyboard shortcut – ???V. That shortcut is a bit of a handful but it still beats the tar out of doing it the Microsoft way.

Today I found a solution, at least for Word:mac 2008. TidBITS published the AppleScript-based workaround over a year ago in Word 2008 and the Paste Plain Text Dance and then updated it with a better version of the script in Updated Paste Plain Text AppleScript for Word 2008. Follow those tips and you'll soon be pasting unformatted text from the keyboard in Word.

I made one small change when I implemented it on my MacBook. I wanted the keyboard shortcut to match Apple's so that I only have to remember one shortcut. To assign ???V as the shortcut instead of ??V as in the tip, change the name of the script to Paste Plain Text\smoV.scpt. Adding the “o” adds the Option (?) key to the shortcut.

I use ssh all the time, but I rarely use it to connect to my MacBook. Today my MacBook froze hard and I tried to ssh to it from my Linux box in an attempt to recover. The ssh failed with the following error message:

    dean@xbrain:~$ ssh 192.168.1.200

    Received disconnect from 192.168.1.200: 2: Too many authentication failures for dean

My first thought was that DenyHosts had borked me but that turned out not to be the case. (If you aren't running DenyHosts you should be.) I tried ssh with debug messages turned on and the client was offering the correct public key but the server was rejecting it. I ended up just doing a hard reboot of the MacBook but I still wanted to solve the prolem.

Next I assumed that something in my private or public ssh keys was borked. Searching on the error message I was getting led me to believe that I had file permission problems somewhere but my .ssh directory had all the correct permissions – 0700 for the directory and 0600 for all the files inside. I edited sshd_config with the intention of enabling PAM and password authentication. Instead the following two lines caught my eye:

    StrictModes yes

    MaxAuthTries 1

First I changed the value of MaxAuthTries to 3. I was rewarded with a new error message from the ssh client.

    dean@xbrain:~$ ssh 192.168.1.200

    Permission denied (publickey).

After that when I turned on debug messages for the ssh client I could see that after the initial public key authentication failed it tried to find other allowed authentication methods and when it failed gave me the error above. Next I changed the value of StrictModes to no. After making that change I could successfully ssh. This confirmed that there was a file permission problem on the server side.

    StrictModes

    files world-writable. The default is "yes".

I had always assumed that StrictModes only applies to the user's .ssh directory. It turns out that it also checks the file permissions on the user's home directory and will balk if the home directory is writable by group or other (everyone). My home directory was writable by group and this was the root cause of the errors I had been getting. (The default user group is staff on OS X but it varies on different operating systems and distributions.) After removing group write permissions from my home directory and restoring my original sshd_config settings everything started working the way it was supposed to. From a review of my Time Machine backups it looks like some time in December I accidentally (or perhaps even intentionally) changed my home directory to a drop box which turned on group write permissions. Doh!

I should have looked before I wrote my last post on MySQL because there is an updated version of the MySQL package for OS X 10.5. (And it has been available for quite a while too.) I undid everything I had done previously to get MySQL working before and I downloaded and installed the 64-bit version of this new package. I even took myself out of the wheel group.

After installing the updated package I found that I could not start MySQL from the command line or the prefpane. I tried adding myself back to the wheel group but I still couldn't start MySQL. To fix the problem I still had to follow the recommendation to change the ownership of /usr/local/mysql/data that I originally found here. Then I removed myself from the wheel group and I could still start and stop MySQL from both the command line and the prefpane. I'm not sure that changing the permissions is either really necessary or the best solution to the problem but it works.

Then I tried restarting the system to see if the permissions on /usr/local/mysql/data/<computer name>.local.err were getting reset like they were before. They weren't, so that's one less problem to deal with.

Finally I tried enabling automatically starting MySQL on system start and that works now even if your user is not in the wheel group.

So now (almost) everything in the MySQL package for OS X 10.5 works out of the box.

In an earlier post I explored how to install MySQL from a package on OS X Leopard, but I left unsolved the problem of how to make MySQL start automatically on system startup. This morning while reading Mac OS X Hints a post titled “10.5: Join 'wheel' group as possible fix for system issues” caught my eye and started me thinking that perhaps it might also be a solution for the MySQL auto-start problem I had been unable to solve.

First I had to find a way to add myself to the wheel group so followed a link from that hint to another hint titled “10.5: Manage users and groups using a GUI tool“*. From there I downloaded and installed Apple's Server Admin Tools for 10.5. These tools are not meant to be used with the desktop version of OS X, but the Workgroup Manager tool works and can be used add a user to a group. I followed the steps described and added myself to the wheel group. It took me a couple of minutes to find the wheel group because the Workgroup Manager displays the groups' long names instead of their short names. In the case of the wheel group the long name is System Group.

After adding myself to the wheel group I opened the MySQL prefpane in System Preferences and checked “Automatically Start MySQL Server on Startup”. Then I shut down and restarted my MacBook. When it finished booting I logged in and MySQL was already running. Problem solved!

*Mac OS X Hints offers the following warning for this hint:

Warning: You should not play around with these settings if you don't know what you're doing. It is possible to break certain parts of the operating system, or to render it unusable.

You should definitely not add users to the wheel group unless you are reasonably confident that you know what you are doing and what the security implications are.

Apple made a minor but welcome improvement to Stacks with the 10.5.2 upgrade. You can now change the stack icon on the toolbar to a folder icon. So now instead of seeing this:

I see this:

I am much happier seeing the Application folder as my Application stack icon than I was seeing the 1Password icon. To change your Stacks icon display, right-click on the stack you want to change and select Display as: Folder. If you don't like it then change it back to Display as: Stack to see 1Password, Address Book, Adium or whatever icon is first in your Applications folder.

I installed the OS X 10.5.2 upgrade yesterday. Shortly after installing it I turned 802.11n back on in my D-Link DIR-655. It is much more stable now, at least so far. In thirty-six hours I have had just one dropped connection. Before the 10.5.2 upgrade I was experiencing dropped connections every few minutes. Unfortunately the 10.5.2 upgrade has caused WiFi problems for many users. It would be easy to blame other manufacturers like D-Link because 802.11n is still draft but many of the problems are with either older 802.11g equipment or with Apple's own Airport Extreme product. And WiFi problems aren't the only problems being reported with 10.5.2. I consider myself lucky to have had a problem free upgrade.