1. Navigate to a .app file in the Finder, e.g. /Applications/Mail.app
2. Control-click the app icon and select “Show Package Contents”
3. Navigate to Contents/Info.plist
4. Open with a plist editor or your favorite text editor.

These files advertise a number of interesting attributes including the application’s official version and copyright strings. They also include important clues to the system about what kinds of files the application knows how to read and write, and what its minimum system requirements are.

Minimum System Requirements

Declaring the right Info.plist values not only allows a developer to control which operating systems a product should run on, but which of the application’s architectures should be considered for a particular operating system. For example, Black Ink uses a number of keyed values describing its requirements:

	<key>LSArchitecturePriority</key>
	<array>
		<string>x86_64</string>
		<string>i386</string>
		<string>ppc</string>
	</array>
	<key>LSMinimumSystemVersion</key>
	<string>10.4.0</string>
	<key>LSMinimumSystemVersionByArchitecture</key>
	<dict>
		<key>i386</key>
		<string>10.4.0</string>
		<key>x86_64</key>
		<string>10.6.0</string>
		<key>ppc</key>
		<string>10.4.0</string>
	</dict>

Notice the fidelity of some of these options. Black Ink is an application that is compiled with binary code for three separate architectures embedded into it: 64-bit Intel, 32-bit Intel, and 32-bit PowerPC. In order to give the user the best possible experience after they double-click the application icon, the system consults the Info.plist values to determine which binary is most appropriate to load on the current system.

The options for Black Ink start by indicating that all things being equal, it prefers to run as 64-bit Intel, but will settle for 32-bit Intel or PowerPC in a pinch. Next, it conveys that it should not be run on any operating system earlier than Mac OS X 10.4. Finally, it adds an additional restriction by architecture, stating that in the case of 64-bit Intel, the system should consider Mac OS X 10.6 the minimum required OS.

Why so picky? For example, Mac OS X 10.5 will run on computers that are new enough to support 64-bit Intel code, but the 10.5 operating environment itself doesn’t contain enough compatible libraries to make it very useful to a full-featured Cocoa application. So we need to convince the 10.5 system to ignore our 64-bit Intel code. And this is how it’s done.

Embedding Info.plist

This is all well and good for applications, but what about other code that may be run on a variety of hardware and operating systems? In particular, command-line tools do not come in the same bundled-folder format that applications do. Fortunately, Apple thought of this when they implemented support in their developer tools for embedding the contents of an Info.plist directly into the binary itself. You just have to pass the Info.plist path to Apple’s linker tool when it’s constructing your binary file. (Thanks to Paul Kim for reminding me of this functionality). What this means in practice is adding arguments like this to your Xcode target’s “Other Linker Flags” build setting:

-sectcreate __TEXT __info_plist $(INFOPLIST_FILE)

This instructs the linker to crete a new text segment named “__info_plist” in the resulting binary, and to fill it with the contents of the referenced Info.plist file. To make sure the INFOPLIST_FILE expands correctly, just make sure you set it in the separate build setting for identifying the Info.plist (the one you’d normally use in an app, and that is just ignored by default for a command-line tool target).

I brushed up on all this information because I wanted to help ensure that some recent work I did to create a standalone MultiMarkdown tool would be backward compatible with older systems. This required adding an embedded plist much as I’m describing here.

(Note: I have gotten some feedback to the effect that the __info_plist segment’s minimum system version requirements may not actually be consulted properly on Mac OS X 10.5. This would be a bummer, and in fact sort of reject the whole point of embedding the Info.plist in this case. I’m going to see if I can confirm whether it doesn’t in fact work.)

You could technically embed all kinds of stuff in the binary, with different section names. But the contract in this case is that when Mac OS X is determining information about an executable, it will consult the bundle’s Info.plist file, if it happens to be an executable in a bundle, or the binary’s __info_plist segment, if it happens to have one.

Another common reason for needing to embed Info.plist information into a standalone binary is if you are using Apple’s code signing mechanism to sign an individual binary tool. Code signing uses information from the Info.plist of a product, and in the case of standalone binaries, the only product-cohesive place to put this is in the binary itself.

Examining Binary Info.plists

After you’ve performed the magic above, you’ll probably be keen to inspect your command-line tool’s Info.plist to see if it worked. To do this, you can use the otool command from the Finder. If you run otool with the “-l” option to show all load commands, it will include the load command that identifies the __info_plist segment. Use grep to narrow it down to the part you’re interested in:

otool -l ./yourTool | grep info_plist -B1 -A10

Any results at will confirm that there is Info.plist information in the binary, but how does it look? The “-s” option to otool lets you examine the contents of a specific segment in a binary, but it dumps it out as hex code. Fortunately, another system-bundled tool called “xxd” is capable of easily converting between hex-dump and text formats. As it turns out, some of Apple’s bundled developer tools (at least on my Mac) contain these embedded __info_plist sections, so if you don’t have a command line tool of your own to try this on, you can peek at what the “atos” tool has to say for itself:

otool -s __TEXT __info_plist /usr/bin/atos | xxd -r

In Summary

Info.plist values are important for conveying information about your product, from the crudest, most obvious stuff like version number, to the most nuanced details such as which architectures are supported. Knowing how to specify an application or tool’s requirements as precisely as possible will ensure that the product performs optimally on whatever supported system your user happens to be using. I’ve barely scratched the surface here with a few common deployment keys that control execution behavior on Mac OS X. Be sure to skim Apple’s Information Property List Key Reference to see if there are other useful bits of information you can share for your application or for your command-line tool.

Handy Sudo Settings – Dave Dribin’s Blog

I knew about the ability to change the sudo timeout, but have never gotten around to looking into exactly how it’s done. Now, I’ll be annoyed a lot less often when I’m in an “administrative” frame of work.

Dave’s post inspired me to finally do a little more research into sudo and the configuration options. For starters, now that I’ve upped my timeout value to something longer than the default 5 minutes, I might want to occasionally “logout” of my sudo authenticated session. The “kill” option does just this, putting you back in a “password required” state:

% sudo -k

As for the options Dave described, they and many others like them are described in the “sudoers” man page:

% man 5 sudoers

Hmm. What’s this option called insults? I turned it on, but Apple appears to have “cleaned up” this option in Mac OS X. It doesn’t do anything. On the Linux installation that runs red-sweater.com, I turned on the option to see what would happen:

yarn% sudo ls
daniel's password:
... and it used to be so popular...
daniel's password:
You do that again and see what happens...
daniel's password:
It's only your word against mine.
sudo: 3 incorrect password attempts

One of the things I love about UNIX heritage is the sense of humor that pervades most of the software. The Mac used to have much more of this itself. I guess we traded it in for a greater sense of professionalism and solidity, but I still miss the corny humor sometimes.

One big benefit of launchd to end-users is that most of what gets launched can be easily examined by perusing the configuration files. Launchd looks in five well-defined locations for launchable items:

/System/Library/LaunchDaemons
/System/Library/LaunchAgents
/Library/LaunchDaemons
/Library/LaunchAgents
~/Library/LaunchAgents

So all you have to do to get a feel for (most of) what launchd is up to is start poking around in those directories. For each independent “launch” that launchd controls, you’ll find a corresponding configuration property list file. For instance, you’re guaranteed to find a bunch of examples in /System/Library/LaunchDaemons, and depending on which third-party packages you’ve installed, you might find things in other places, as well.

Launchd In Context: FTP

Take a quick look at ftp.plist, one of the system launch daemons. Depending on how you’ve configured your system, you’ll either see that a “Disabled” key is present and set to “true,” or it is absent. This corresponds directly to the “FTP Access” item in the System Preference’s “Sharing” panel. Go ahead and toggle the setting in your preferences, and observe that the ftp.plist file is immediately updated to reflect the new setting. This tells launchd that it should no longer consider launching the ftp daemon when an incoming ftp connection is attempted.

What constitutes an incoming ftp connection? Look further down the ftp.plist and you’ll find an entry with key name “SockServiceName” and a value of “ftp”. Launchd uses this name to lookup the socket port/protocol information for the named service from /etc/services. In this case, when an incoming connection is attempted on port 21, launchd will, if this item is not disabled, launch the daemon at /usr/libexec/ftpd, in order to handle the incoming connection. Groovy, huh? Read more about network handlers and other on-demand daemons.

Boot-Time King

I said above that these configuration files reveal “most of” what launchd is up to with regard to running things on your system. Because launchd can’t handle all types of configurations, and because its introduction has been sort of gently staged, it’s responsible for running a lot of the older mechanisms like /etc/rc, StartupItems, etc. This means that launchd is basically responsible for everything from when the kernel gets loaded on. That includes booting your Mac!

Things have been in such flux over the past few years that it’s hard to keep a straight answer when it comes to exactly what takes place at boot time. Excellent overviews such as Mac OS X System Startup by Amit Singh, or The Boot Process by Apple, are liable to become outdated as launchd continues to evolve.

Fortunately, the entire process is transparently observable, because launchd is open source. If you’re ever in doubt about any nuance of the startup process, just look at the source code. The repository even contains the boot-time configuration file “/etc/rc”, and the source for antiques like SystemStarter. You can even check out how the boot process is going to look in Leopard. (Note: free registration on macosforge.com required). I couldn’t figure out how to check out those repository URLs from the command-line, but I discovered an alternate URL that works, and doesn’t seem to require registration.

Editing Launchd Configuration Files

It won’t take you long to discover that the launchd configuration files, while elegant and modular, are a bit of a pain to read, let alone edit. Fortunately, a couple of third-party solutions exist to ease this task.

Lingon, by Peter Borg, is a very powerful editor which also serves as a sort of browser for all the existing configuration files on your Mac. You can selectively start or stop any existing configuration, and it takes care of asking you to authenticate for editing those system-owned files (after warning you profusely not to do so!). It even sports a “wizard” interface that asks in relatively plain English what it is you’re trying to accomplish, and guides you through the creation of new, custom launchd configurations.

While Lingon is essentially easy to use, it has some rough edges which scream for refinement. I’d really like to see the application receive a UI overhaul. Lots of little awkward UI elements and poorly phrased dialog make it slightly less than a 100% success. But it sure beats editing in vi, or even Property List Editor.

One of Lingon’s nicest features is its “Expert” pane, which allows you to examine and edit the raw XML of a configuration at any time. This is so useful that I’d like to see if featured as a full-time view, perhaps in a hideable split view pane. It would be fun to be able to watch the changes live in the XML source while tweaking details in the UI. But Lingon is, in the spirit of launchd itself, open source. So any shortcomings that ultimately get me down can be remedied to my own (or your own) liking.

Apparently I wasn’t the only person to object slightly to the UI of Lingon. Launchd Editor is a $5, closed-source alternative that bites off a much smaller feature set, while trying to improve on the UI of Lingon. It’s clear by observing some of the configuration panes that Launchd Editor was inspired by Lingon (or vice-versa, I’m not positive which came first, but I’d guess Lingon did). Some of the control layout is almost identical to Lingon, but touched up a bit in alignment and wording, mostly for the better.

Launchd Editor is limited by its adoption of a document-centric model, such that the user has to specifically locate and open a configuration file. It also lacks the start/stop/load features of Lingon. Overall I’d say it’s worth using Lingon in spite of its rough UI, but minimalists might prefer Launchd Editor.

Launchd For Developers

So far I’ve talked about how the system uses launchd for its services, and sort of alluded to the fact that you might come up with your own configurations to suit your personal needs. But developers should also take heed of launchd as a mechanism for automating tasks on behalf of users. One example of this is Noodlesoft’s Hazel, which uses launchd configuration rules to periodically check the status of “watched folders” and perform housekeeping tasks on them. By saving configurations to the user’s LaunchAgents folder, and then loading them with the launchctl command-line tool, it pushes off timing responsibility to launchd. Nifty!

Summary

Launchd is a super addition to Mac OS X, and a stellar example of Apple’s commitment to improving Unix for both end-user and architectural benefit. Hopefully if you hadn’t gotten a chance to take a close look at it before, you’ll be encouraged to do so after reading this article.

It’s this kind of detailed analysis combined with a casual writing style that makes for great technical blog entries. File this one under “understanding what the eff is going on with my custom kernel extension.” You’d have no idea where to look if you just took Xcode’s template as a black box.

John Siracusa recently wrote about Apple’s almost universally condemned strategy of distributing recorded conference materials after the show is over. He asks “Why does Apple jealously guard the content presented at WWDC?”

It’s a good question, and it probably has to do with compelling future attendance at conferences. After all, Apple is probably thinking, if you can get the milk for free, why … uhm, go to the cow? By “jealously guarding” the content that makes up the “intellectual reward” for conference attendees, they’re making it clear that the best way to stay on top of Mac OS X technical issues is by attending the conference.

This rationale makes sense on paper, but there are major problems with it.

Being In The Room

The first mistake is in assuming that reproduced content will approximate the value of “being in the room.” I’ve watched a fair number of the WWDC 2005 videos through the (painful) streaming ADC Select interface. Aside from the benefits of being able to pause, rewind, and skip the boring parts, let me tell you, it’s no conference. I am roughly able to absorb all the data that my peers who attended did, but they benefitted from a much richer experience.

Watching the WWDC sessions from home is like watching the New York New Years Eve party on television. You are a passive recipient of the information, but you don’t get to participate. You know when the new year arrives at very close to the same moment as all the thousands of people in the crowd, but you don’t get the satisfaction of washing the champagne stains out the next morning.

Even though the information (the passing of the year) from this great event is free and widely spread, the event is hugely successful. Why do those thousands of people travel to downtown NYC to participate in an event they could watch at home? It’s about being in the room.

The value of being in the room at WWDC is about 10 bajillion times greater than being in the room at new years. At WWDC, you can ask questions. If the line was too long and you missed your chance, you can recognize the speaker in the halls and track her down for clarification. At WWDC, you can participate in hands-on sessions, working through the new technology as you learn about it. At WWDC you can visit the labs and work in an environment where smart people are hovering about, waiting to answer your questions. Unless you’ve found a particularly well-stocked IRC room, these benefits are not available to you at home.

Being Outside The Room

The other major motivation for attending WWDC has nothing to do with the conference itself, but with the milieu surrounding it. There is quite simply no other time of year that such a concentration of like-minded Mac software developers exists in any one point on the globe. The closest thing you’ll find to this amazing congregation of Mac nerds, is the sizable number of them that reside permanently during working hours in Cupertino, California. The rest of us are lucky if we’ve found a half-dozen similarly inspired people within a 50 mile radius of where we live or work.

Apple takes this benefit to the ultimate level by opening its own doors for one evening during the conference, inviting attendees to relax, have a beer, and mingle with conference attendees and Apple employees on the Apple campus. This degree of access is totally incomparable to anything a developer can hope for via the web, email lists, chat rooms, or forums. The Apple campus on one summer Thursday becomes an absolutely sizzling hotbed of Mac nerdiness for 3 hours every year.

And Apple’s party is only the tip of the iceberg. Events like the Buzz Andersen’s annual party are gaining momentum with each passing year. The number of extra-cirricular activities is so great that groups of developers with niche interests find it difficult to find a spare lunch or evening in which to meet. In summary? WWDC produces a week of nearly non-stop hot developer-on-developer action. You can’t buy that at home (ahem – nor, with that particularly risque choice of words, would you want to!).

To top it all off, WWDC has for the past several years been held in San Francisco, one of the most attractive tourist destinations in the world. The conference is epic, the scenery is epic, the attendees are epic. Attendance is an almost irresistible proposition for companies and developers alike. Apple has nothing to fear from making the information free.

Ask For What You Want

The value of WWDC is about 5% information and 95% being in the room and being with your peers. If New Years were celebrated like WWDC, only a few thousand people would be running around on January 1 knowing whether it had truly come to pass. I agree with John Siracusa – it’s time to free the WWDC content. We want high quality, downloadable archive versions of all WWDC sessions. These should be available to any ADC member at any level of membership under the terms of their NDA.

If you also agree, let’s stop talking about it and start telling about it. Telling Apple, that is. Use the ADC contact form to let Apple know how you feel. You want this information freed! This is not just for whiny non-attendees, either. Those of you who attend every year have also bemoaned the loss of DVD archives of the sessions, for instance. Take this opportunity to make yourself heard. We’re all in this together!

I encourage you to write whatever you feel in your feedback to Apple, but this is what I am writing and it might spark some motivation in you to “make the call”:

A much-overlooked perk of Mac OS X’s BSD underpinnings is the presence of full-fledged support for NFS (network file system) in every shipping version of the operating system. This support serves as the underlying technology for the “Network Domain,” the fourth member of a family of directory hierarchies that also includes the System, Local, and User domains. Within each of these domains, a predictable directory layout allows for the storage of applications, preferences, fonts, etc., in such a way that a properly-written application can transparently make such resources available to the user as a unified whole.

Most users are probably not familiar with the concept of file-system domains at all. Among those who are, it probably boils down to a vague understanding that stuff in /Library is shared, stuff in the home directory is private, and stuff in /System should not be modified. The mysterious /Network directory is occasionally used to sluggishly locate shared directories from other computers on the LAN (local area network), but is rarely configured to fulfill its complete potential as the Network domain.

A FastScripts user recently contacted me. He works in a newspaper office, and is curious about whether there is any facility in FastScripts for sharing a directory of scripts to his entire team. Frustratingly, I have to tell users like this one that there is support for just such a setup – the network domain – but that setting it up is about the most convoluted Mac OS X task imaginable. It’s so beyond the scope of what any average user should be asked to do, that I’m tempted to implement a custom inter-computer sharing system, just so I can offer my customers a “do it for me” switch. Apple’s advice? “Implementation of the network domain is the responsibility of the network administrator.”

But the network domain is an awesome idea! So it looks like you get to be the network administrator. By setting it up correctly you gain a centralized share for all users of a LAN that benefits not only FastScripts, but any other application that correctly iterates the four domains for supporting files! For this reason, it’s worth knowing how to set up, and worth pressuring Apple to make the setup easier for everyday users. The remainder of this article details the steps you may take to both publish a shared “Library” folder from one computer and subscribe to it from any number of other computers on your LAN.

Configuration: A High Level Overview

Before you tackle the task of setting up your network domain Library folder, you should be familiar with some terms used by the technologies on the Mac.

NetInfo is a unique Mac OS X technology inherited from NeXT. NetInfo is a database that manages many of the attributes of a computer and network that would, on more conventional UNIX systems, be managed entirely with text-based configuration files. Among NetInfo’s many responsibilities is the management NFS automount server and client information for particular machines on a network.

NFS is a UNIX technology for exposing shared directories from one system and mounting them to another. Unlike Apple’s legacy AppleShare system, where mounted servers appear functionally identical to mounted disks, NFS volumes can be attached virtually anywhere in the filesystem you desire (this is true for regular disks as well, but is rarely exploited). For instance, if you want to publish your music collection from one computer and have it show up on all other computers at the path “/MyStuff/ObscurePath/Whatever/Music/”, NetInfo can make that happen. The arbitrary location at which you decide to attach the shared directory is called a “mount point.”

A cool feature of NFS is a sort-of lazy loading technique whereby a mount point can remain unconnected until it is actually needed by some application. The technology responsible for this magic is called “automount.” What’s really cool about automounting an NFS shared volume is that it gracefully handles the absence of either the server or the client. So when you wander outside the realm of your LAN, the funky Music mount point described above simply fails to locate the network resource. Instead of starting a 4-alarm fire, you simply get an “empty” directory.

So bringing this all together, how do we employ the underlying technologies such that we achieve our primary goal? We want a shared network domain Library folder, and the way to do that is by publishing an NFS volume that gets subscribed to with an automount mount point at “/Network/Library”.

On the Server: Publish an NFS Volume

First things first, we need to pick a directory on our “server” box and publish that to the LAN via NFS. In NFS terminology this is called an “export,” and the way this is configured on Mac OS X is via a top-level NetInfo directory entry called “exports.” NetInfo can get really complicated and to make things simple I’m just going to show you how you can add a plain-vanilla NFS export for a folder located at “/Library/MyNetworkShares/Library”. The “nicl” command-line utility makes this relatively straightforward:

sudo nicl . -create /exports/\\/Library\\/MyNetworkShares\\/Library opts alldirs maproot=nobody

Note the crazy backslash overload. That’s because we want to get slashes into the actual name of the directory entry in NetInfo. The same task could be accomplished from the NetInfo Manager application, where you can also confirm visually that the configuration has been made as expected:

Once the NetInfo database has been updated, you can either attempt to ensure that all of the required daemons are reset and recognize the new exports settings, or you can just reboot, which should get the NFS startup item to reload and configure everything corectly. By default the NFS server is enabled, and starts at boot time if there are any exports defined.

To confirm the NFS export is set up and your daemon is operational, simply run the showmount command from the command line on the server:

showmount -e
Exports list on localhost:
/Library/MyNetworShares/Library           Everyone

Now from another machine (or the same – doesn’t really matter), confirm the ability to actual mount the “volume”. My server machine is identifiable on the local network as “danielG5.local”, so I mount the exported directory on my laptop with:

mkdir /tmp/testmount
mount_nfs danielG5.local:/Library/MyNetworkShares/Library /tmp/testmount

Et voila! /tmp/testmount now looks and acts exactly as the /Library/MyNetworkShares/Library folder on the server.

On the Client: Configure the Network Mount Point

Now that we’ve confirmed the ability to mount the server on a whim, we need to arrange for the client machine to automatically “wire up” to the server whenever the /Network/Library directory is accessed. We do that by configuring a similar NetInfo node to the “exports” item above.

This time, the node resides in “mounts” and serves to inform the automounter about where the network resource is and where it should appear on the local machine. Run the following commands in the terminal, substituting the appropriate computer name for “danielG5.local”:

sudo nicl . -create /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library type nfs
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library dir /Network/Library
sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library opts ""

And another visual confirmation from NetInfo Manager puts me at ease:

Again, rebooting is probably the safest way to ensure that the changes are picked up by the automount daemon, but since automount is normally running by default, you should be able to simply restart the daemon:

sudo kill -1 `cat /var/run/automount.pid`

Go ahead and try it out – navigate in the Finder to /Network/Library. You should see the contents of “/Library/MyNetworkShares/Library” from the server computer. I have found the Finder’s concept of /Network to sometimes be a little flakey, so if it doesn’t seem to be working, try changing to the directory from the Terminal instead. I think this kind of thing irons itself out after a reboot. Once you’ve got it wired up, you can start putting junk in the folder that you want to have at your disposal on all machines on the LAN. Fonts, Scripts, etc. If an application doesn’t behave as you expect it to with the Network domain, let the application’s author know (in fact, FastScripts could benefit from a few tweaks to improve its functionality, though it basically works). This is a powerful and very cool infrastructure that more of us should be taking advantage of.

Simplifying the Process

If repeating this process on all the clients in your LAN sounds daunting, fear not. A real network administrator would probably have some kind of sophisticated NetInfo hierarchy through which she could easily manipulate the “mounts” values for all of the machines in the network, but I’m going to assume you’re like me and are just hacking together a solution for a few machines in your house. We can use the “nidump” and “niload” commands to essentially copy and paste the successful settings from one client to another. First, obtain a raw text format copy of the mounts data:

nidump -r /mounts . > MyEasyMounts.txt

Now take that text file to whatever client you like, and load it into that client’s NetInfo database:

sudo niload -m -r /mounts . < MyEasyMounts.txt

Don’t forget to either reboot or confidently reset the automount daemon again.

The process described above can be repeated for other top-level Network domain folders like “Applications.” Just make a different folder on the server and add appropriate exports and mounts entries to the server and clients. Have fun, and enjoy your Network domain!