When I come across software I might need to add into Mac OS X that requires compilation, I typically want to produce one Universal Binary. Make it a four-way UB and you get both 32- and 64-bit support.

A single binary is ideal for a Radmind transcript (or other package, if you wanted to bundle it into an installer) that can be deployed on both PowerPC and Intel Macs on Leopard.

Since [Bad link] 3.0.2 with some patches is apparently working [Bad link] — passing the [Bad link] tests — I thought I'd try my hand at a four-way Universal Binary.

What worked for me, using a Mac Pro 4x2.8 GHz with Mac OS X 10.5.2 and Xcode 3.0, was to start with [Bad link] and modify them with some [Bad link]. The configure and compile were both less than a minute on this system.

I have seen the use of "-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk," in the LDFLAGS environment variable when compiling some applications but this did not work for me with rsync; when I removed it, rsync 3.0.2 configured successfully for me.

The result of the above build process appears to be a full four-way UB:

A local transfer on the build system appears to have worked correctly. I did not test with Backup Bouncer, sync with a non-Mac system, or when shuttling data between architectures. So, accept these results with a grain of salt; I’m just happy I got rsync to compile for now.

Microsoft released Service Pack 1 to update Office 2008 for Macintosh on Tuesday, May 13. The update makes a significant number of changes — spread across Entourage, Word, Excel, and PowerPoint — so if you are a system administrator, I would recommend examining the [Bad link] in its release notes.

The update is downloadable via Microsoft AutoUpdate (invoke that helper program with Help > Check for Updates in any of the Office applications, or look inside /Library/Application Support/Microsoft in the file system) as well as the [Bad link] Web site.

It took me a little while to figure out how I could tell what DirectoryService directory nodes are available to a Mac OS X system. I could perform the task interactively, just issuing an “ls” command at the dscl “>” prompt. But for a non-interactive one-liner, I was bedeviled by what I thought was a pretty basic function for the dscl tool.

I wanted to find all of the top-level nodes — because, for example, that could [Bad link].

It turns out that I was missing the use of “localhost” as the datastore parameter, which reliably returns the information I wanted in a parsable form. Rather than “/” (simply doesn’t work) or just a period (only uses the local directory) — or even listing "/Active\ Directory" explicitly — “localhost” specifies all of the directories available to the local host. I was incorrectly assuming “localhost” would tie me to the local directory, as with “localonly,” and I thus avoided trying it until I felt like an utter failure.

$ dscl localhost -list .

This produces the following output on a Leopard-based system which only has local accounts in DSLocal:

$ dscl localhost -list .
BSD
Local
Search
Contact

If your system happens to be bound to a Microsoft Active Directory, you’ll instead see it prepended:

$ dscl localhost -list .
Active Directory
BSD
Local
Search
Contact

Or if you’re on Tiger — again bound to Active Directory — you’ll still see “Bonjour,” “NetInfo,” and “SLP” in the mix:

I used the same drag-and-drop-to-export methodology as in my previous article. The iCalendar .ics file for the existing event that I dropped out of my Entourage calendar contained these unique identifiers:

Both I and the meeting organizer are Entourage users in this case. That may be why both the event and the cancellation had X-ENTOURAGE_UUID properties at all. The UID property has appeared consistently for me in both events and their updates, no matter what their source.

Because of the discrepancy between unique identifiers, Entourage apparently couldn’t determine whether the cancellation was for the event that existed in my calendar. When Entourage “processed” the cancellation, it removed nothing from my calendar.

This seems entirely reasonable, although I would personally like Entourage to do deeper matching if it could: how about “is there an existing event by the same organizer and/or with the same name at the time of the update or cancellation?” Matching UIDs has got to be simpler.

How does this happen? Well, for me, it could have happened any number of ways: There could have been a past error when:

Entourage was trying to synchronize to my Exchange account

my Entourage calendar was synchronizing with Sync Services on Tiger or Leopard

Missing Sync for Palm OS, which I use with my Palm Treo 650, was performing its synchronization with Sync Services on Tiger or Leopard

I was using Microsoft Outlook in cached mode with my Exchange account

I used [Bad link] to remove massive numbers of duplicate calendar entries from my Outlook/Exchange calendar (which could have resulted in the loss of events with their original UIDs).

As far as I can determine, when you have data synchronization problems, you’re going to have one of the following outcomes:

data is added

data is deleted

data is modified

nothing happens.

Not all of these are pleasant, mind you — and that can depend on the circumstances involved. Deleting data is perfectly acceptable in some scenarios where it needed to be removed, but not others where it means it has just been lost. Adding data is great, unless it results in unwanted duplicates.

Anyway, I hope this helps you understand how Microsoft Entourage works a bit better.

Now that I have my dual-monitor Gateway FPD2485W setup, I’ve got a few complaints. Of course!

The two monitors take an awfully long time to wake up from their power-saving mode. Then, when they finally wake up — invariably at different times, the newer one first — I get the on-screen display (OSD) overlay telling me that they’ve chosen to accept the DVI input.

Well, duh, that’s the only video source hooked up to them, so it’s not helpful. This wouldn’t be so bad, but the OSD overlay stays on the screen for what seems like eons. Since the overlays are smack dab in the middle of the screen and are opaque, they block important visual elements like Mac OS X’s login window.

So far, I haven’t been able to find out how to get rid of the OSD overlay. If I could do that, I think I’d tolerate the wake up delay more readily.

Certainly, some of this is Gateway’s fault. I guess I can’t blame them much since they specifically don’t support Macs and that’s what I’ve hooked the flat panels up to. I could have gone with some brand that did advertise Mac support, but I didn’t. This must be my payback. Grin.

I’ve found that trying to explain the Mac OS X keychain at all tends to make peoples’ eyes glaze over. The keychain is poorly-understood overall, perhaps because it tries to bridge the gap between security and convenience.

A few thoughts:

A keychain has its own password which may or may not be set to the same as the password for the login account.

The keychain password is completely independent of the login account’s password, even if it is the same text as the login account’s password. They can be changed independently. When they are the same, they are just two passwords which happen to be the same.

User keychains are created within user home directories, and are protected by file system permissions while they are enforced.

Keychain keys are further protected by 3DES encryption. Directory or metadata information is in cleartext.

If the password is shared between the login account and that account’s default keychain, the keychain will be unlocked during the login process. This is the default for accounts created by the Mac OS X Setup Assistant and Accounts System Preferences.

If the default keychain’s password does not match the login account’s password, the keychain will not be unlocked automatically during the login process. The user may be prompted to unlock it, using the keychain password, if other applications require a key stored within.

The only time that a password change for a login account changes that user’s default keychain password is when the login account is logged in and changes its own password through Accounts System Preferences.

If the computer is bound to a directory service, a login account may be tied to that. However, the keychain is not. Changing the login account’s password through a directory service does not reset the keychain’s password. The keychain’s existing password will remain until or unless it is changed.

A third-party software utility, Keychain Minder, can help to keep login and keychain passwords in sync, if desired. This may be especially helpful in a directory service environment, where you are more likely to change account passwords externally rather through Mac OS X’s built-in means. It also provides an opt-out capability for those who specifically want different login and keychain passwords.

If the computer is bound to a directory service, and a directory service-based login account was compromised, there is a chance that the password for the default keychain in that account is also compromised. Changing the password for the login account in the directory service will protect the login account. However, that will not necessarily protect the keychain stored within the account’s home directory on disk. Whether or not the keychain password was the same as the former password for the login account — the keychain’s password should probably also be changed.

The long-term use of the same password for a keychain can be a risk; as it gets stale, it lessens the protection on each key in the keychain.

There is currently no policy enforcement mechanism, akin to pwpolicy, for keychain passwords.

When Microsoft Entourage is handling meeting updates or cancellations between Exchange users, it’s critically important that it can match up the change to an event with the correct event in a calendar. It does so by comparing unique identifiers between the update/cancellation message and existing calendar events. As nearly as I can tell, this depends on having the right UID, which makes sense.

How can you see the UID for events? Drag the event from an Entourage calendar to a Finder window, where it will become an vCalendar/iCalendar-formatted file with a .ics extension. You can open the resulting file in a text editor. Here’s a sample from a repeating event in an Entourage calendar, with the UID highlighted:

Similarly, you can drag and drop a proposed change to an event, which is received by e-mail (because Exchange is largely an e-mail based — rather than a network-based — calendar system), to the Finder. This will save the message as the text source of the e-mail, with a .eml extension. That file can also be opened in a text editor, where you can see that it contains a siginficant amount of vCalendar/iCalendar data. Here’s a sample cancellation notice that removes one instance of the recurring event from Entourage — for reference, not the instance shown above, but another one from the same sequence:

If you are troubleshooting a problem where an update/cancellation does not modify an existing event as you expected, and the UIDs of each do not match, that’s probably the source of your problem. Of course, you still have to figure out why the UIDs don’t match. In that case, I’d personally start by looking at what other synchronization software (besides Entourage’s own Exchange sync) and devices are involved.

Here is a table that combines each unique package whose Bill of Materials (BOM) file is checked by Disk Utility when running the Repair Permissions routine. These package names are directly listed in the DiskManagementTool (Panther, Tiger, and Leopard) or DiskFirstAid (Jaguar) executables.

I would say that “many Bothans died for this,” but that would be overly sensational. I’m not sure anyone really cares besides me, so its importance in the galactic scheme of things is in doubt. Beyond that, it just took some time to generate each of the OS installs via InstaDMG; with the resulting disk images mounted, I just had to read files with the strings utility. I didn’t even need to boot them. (Although, had I wanted to boot them, realize that Mac system administrators, like their developer friends, [Bad link].)

How did I construct this table? I got the raw data from the techniques described in the previous post. I saved the results into one text file for each OS version.

I ran the following command to get the the unique package names from my four text files:

The sed commands strip the beginning and end of each line, which contain the beginning and ending of the full package and BOM path. This is the same for each package, and thus becomes superfluous in the table. The sort command sorts the results, ignoring case (-f). Then, uniq can determine which of the packages names are unique from the sorted data.

I pasted the output into Excel as a column. I then ran another set of commands to grep for the package names in the original files, reviewed that output, and put an “x” in the right columns to denote which OS versions had which packages listed. Sorry, I didn’t write a script for that and the commands to get there were just:

There has long been confusion and misunderstanding about what, exactly, the Repair Permissions routine in Apple’s Disk Utility does. What started as the Repair Privileges Utility available separately for Mac OS X 10.1 has become the subject of some controversy in the intervening years.

“What permissions does it verify?” and “Where does it get the list of permissions it uses for comparison?” are two reasonable questions users and system administrators alike may ask in order to understand the software better.

The answers to these questions are important to prevent the abuse of this technique in the no man’s land of troubleshooting voodoo. Repair Permissions has been debated ad nauseum, but confusion blankets it like a thick fog. It’s 2008 and yet I still come across reasonable people who don’t know what the software is doing — sometimes even holding that it is doing something it isn’t.

Well, there is information available on this topic. First, let’s look at [Bad link]. As of this writing, it states:

“When you use Disk Utility to verify or repair disk permissions, it reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature).”

That seems to imply that all of the Bills of Material (BOM) files for every package listed in /Library/Receipts are reviewed. But, the article further explains:

“No [Disk Utility does not check permissions on all files]. Files that aren’t installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked. For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn’t created. This is expected. Some applications are designed to be installed in one of those ways.”

The article implies that every package receipt is reviewed, but only the files and directories listed in an Apple-originated package are checked and repaired by Repair Permissions. This is somewhat confusing, since it doesn’t really explain how third-party software installed through an Apple installer package relates to this — particularly in the case where a file or directory is in both an Apple-originated package as well as a third-party one.

Macworld magazine’s Dan Frakes tackles the situation with the article [Bad link]. The author tracks what BOMs Disk Utility is using while running Repair Permissions via fs_usage. He also runs strings on the tool that repairs permissions to find what, if any, BOMs are listed in the executable. Based on that evidence, he finds that a limited subset of BOMs are consulted by Repair Permissions — and all of them are Apple-originated; none are from a third party.

This dovetails nicely with the discussion of Repair Permissions in Michael Bartosh’s excellent [Bad link] book from O’Reilly. While Mike is no longer around to explain how he obtained the list of BOMs — printed on page 163 — that are referenced by Disk Utility, it is likely he used one or both of the methods above. It is also likely he had access to information from Apple itself before he made the assertion. He always seemed to prize strong evidence and a deep understanding of the software, and so I trust what he wrote.

Mac OS X Leopard’s online help probably has the best clarification of the matter from an official source. It is succinct and much better than the Apple KB article when it spells out:

You can verify or repair permissions only on a volume with Mac OS X installed.

It’s best to start up your computer using a disk with the latest version of Mac OS X, including software updates. Software updates may change file permissions to improve security.”

I think we can consider this matter settled; Disk Utility’s Repair Permissions routine is limited in scope. It only uses BOM files from Apple installer packages, and the only packages examined by the utility are those from Apple. Third-party software, even when installed by an Apple package, is not in the mix. The repair process only needs to be run as a troubleshooting technique when you think there is a problem related to the permissions-on-disk.

If you want to do your own sleuthing, the MacWorld article shows how to run strings against the DiskManagementTool executable to find which BOMs it lists. Modifying that a bit to get the information from any given disk you’ve mounted, and placing the output on the pasteboard (so you can paste it in the editor of your choice), you get the following (substituting the volume’s path for “/path/to/startupvolume,” or just take that text out to use your current startup disk):

Neither the DiskManagement framework nor the DiskManagementTool exists in Jaguar, however. I found that the [Bad link]. After discovering that change, I thought I’d need to substitute “Disk Utility.app/Contents/Resources/Disk Utility Agent” for DiskManagementTool, but even that executable didn’t contain any references to “Receipts.” Instead, I settled upon the following for Jaguar: