Category: Systems Administration

Apple Surveying 32-Bit Third-Party Kernel Extensions

Today I noticed something new in my LaunchDaemons folder: /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist. It starts a Ruby script (/usr/libexec/third_party_32b_kext_logger.rb) when your Mac starts up that (and I could be totally wrong, as I don’t know Ruby) appears to use /usr/sbin/kextfind -system-extensions to identify third-party kernel extensions (e.g. kernel extensions for which the identifier does not begin with com.apple) that exist only in i386 or PPC forms. It makes sense why Apple would do this, as a move to 64-bit only would be in keeping with their typical attitude on leaving old hardware platforms behind, but this particular file is odd in that it’s in /Library/LaunchDaemons and not /System/Library/LaunchDaemons, where most Apple-created jobs are. Maybe this was a task given to a programmer new at Apple who was unfamiliar with the typical folder hierarchy on a Mac, but this smells odd. The only result I found for it in Google was this Apple Support forum post.
So, I did some investigation, and found that it uses the domain “com.apple.kexts.32bitonly” with the defaults command, and in my system log is this line:

/var/log/system.log:Mar 22 19:31:30 Jeff-Kelleys-MacBook defaults[3439]: \nThe domain/default pair of (com.apple.kexts.32bitonly, lastRan) does not exist

That is reason enough for me to believe that it’s installed as a part of Mac OS X 10.6.7, as that message signifies its last run time (the script quits if it’s been less than a week since it last ran). So, being the diligent former sysadmin that I am, I looked at the 10.6.7 update’s files, and didn’t see anything (else) of note. I don’t see a point in the script that reports this to Apple, so I don’t know if this constitutes a breach of privacy on their part, but it’s interesting nonetheless that it would appear that Apple is gauging whether or not they can leave 32-bit kernel extensions behind with minimal customer fuss.

Xcode 3.2: Using GDB as a Non-Admin User

New in Xcode 3.2 is an authorization setting that looks like this:

<dict>
	<key>allow-root</key>
	<false/>
	<key>class</key>
	<string>rule</string>
	<key>comment</key>
	<string>For use by Apple.  WARNING: administrators are advised not to
	        modify this right.</string>
	<key>k-of-n</key>
	<integer>1</integer>
	<key>rule</key>
	<array>
		<string>is-admin</string>
		<string>is-developer</string>
		<string>authenticate-developer</string>
	</array>
	<key>shared</key>
	<true/>
</dict>

The upshot of this is that if you aren’t in the _developer group in the local directory, you’ll have to authenticate as an administrator to use gdb or some of the performance tools. For the vast majority of developers on Mac OS X, who run as an administrator, this is fine, but if you’re running as a regular user, either for security reasons or because you’re in something like a lab setting, this can be a problem. To add a user to the _developer group, use the dscl command:

dscl . -append /Groups/_developer GroupMembership UserName

Replace UserName with the short name of your user account (or $(whoami)) and you should be all set.

If you’re administering Mac OS X in a lab setting, you can either create a LaunchAgent that handles this or a login hook. See the Apple tech note “Running At Login” for more information on login hooks. As an added touch, my login and logout scripts to handle this also remove all users from the group, like so:

dscl . -delete /Groups/_developer GroupMembership

If the GroupMembership key doesn’t exist, dscl will create it—and it doesn’t exist by default—so deleting it outright shouldn’t cause any problems.

How-To: Run a LaunchDaemon That Requires Networking

I’m a big fan of using launchd to automate things in Mac OS X. That serves me well, as that’s how Apple wants things done moving forward. That said, one of launchd’s biggest shortcomings is a lack of a dependency system. There is currently no way, for instance, to specify in a LaunchDaemon’s property list that the daemon requires the network to be active in order to run. This is problematic for some things, such as a script I wrote to automatically set the computer’s hostname based on the DNS server (more on that later). Luckily, Apple has already defined a function, CheckForNetwork, in /private/etc/rc.common. Here it is in all its glory:

##
# Determine if the network is up by looking for any non-loopback
# internet network interfaces.
##
CheckForNetwork()
{
	local test

	if [ -z "${NETWORKUP:=}" ]; then
		test=$(ifconfig -a inet 2>/dev/null | sed -n -e '/127.0.0.1/d' -e '/0.0.0.0/d' -e '/inet/p' | wc -l)
		if [ "${test}" -gt 0 ]; then
			NETWORKUP="-YES-"
		else
			NETWORKUP="-NO-"
		fi
	fi
}

In your code, simply include rc.common, then call CheckForNetwork as needed. An example:

#!/bin/bash

# Example Daemon Starter
. /etc/rc.common

CheckForNetwork

while [ "${NETWORKUP}" != "-YES-" ]
do
        sleep 5
        NETWORKUP=
        CheckForNetwork
done

# Now do what you need to do.

Note that this will keep the script running indefinitely until CheckForNetwork sets NETWORKUP to “-YES-,” so if there’s a networking problem your code may never execute.

Google Earth Now Available Without Automatic Updates

A while back I blogged about Google Earth’s stealthy, silent automatic update feature. That post continues to be pretty popular, so I wanted to share an update: Google has released a version of Google Earth, including the Web plug-in, that does not include the self-updater. On the download page, the EULA features this paragraph:

(b) Automatic Updates. The Google Earth software may communicate with Google servers from time to time to check for available updates to the software, such as bug fixes, patches, enhanced functions, missing plug-ins and new versions (collectively, “Updates”). By installing the Google Earth software, you agree to automatically request and receive Updates.

However, if you navigate to the advanced setup page, there’s a box you can un-check labeled “Allow Google Earth to automatically install recommended updates.” This box directs you to a separate download that does not include the updater. The EULA, however, does not change when you deselect it. I don’t think that really matters as much in the grand scheme of things, so I’ve really got to give Google some kudos here for listening to systems administrators and concerned users on this one.

Updating dyld Shared Caches with Radmind: Best Practices

Similar to my last post about updating kernel extensions, you can run into problems with Radmind due to the dyld shared cache. You may see messages like this in your system log:

current cache invalid because /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit has changed

Running the update_dyld_shared_cache command will fix this, but there’s a better way. Sure, there’s almost no overhead to that command, but where’s the fun in that? Here’s a pre-apply script that will delete any shared caches that have changed, which will then be re-built at reboot.

#!/bin/sh

# update_dyld_caches: Inspects the applicable transcript for something that
#                     might cause a dyld cache to become outdated. If it exists,
#                     delete the cache so it's re-created at startup.

DYLD_CACHE_FOLDER="/private/var/db/dyld"
DYLD_PREFIX="dyld_shared_cache_"
ARCHITECTURES="i386 x86_64 rosetta ppc ppc64"

for arch in ${ARCHITECTURES}; do
	cache="${DYLD_CACHE_FOLDER}/${DYLD_PREFIX}${arch}"
	map="${DYLD_CACHE_FOLDER}/${DYLD_PREFIX}${arch}.map"

	if /bin/test -f "${cache}"; then
		if /bin/test -f "${map}"; then
			/bin/cat "${map}" | grep ^/ | sort --unique --ignore-case | while read line; do
				if /bin/test -n "$(grep ${line} ${1})"; then # found a match
					/bin/rm -f "${cache}"
					/bin/rm -f "${map}"
					break;
				fi
			done
		else
			# Cache exists, but there's no map.
			/bin/rm -f "${cache}"
		fi
	fi
done