MacTech magazine May 2012

The May 2012 issue of MacTech is available via the iPad app; dead-tree mailings can’t be far behind.

In this month’s issue I detail a method for creating packages to create a local admin account on your managed machines. This same package will create a working local admin account on Leopard through Lion (and possibly beyond), and will work in the stripped-down Lion install environment. If you need to update the local admin password, you can just install a newer version of the exact same package.

This fits in with my general theme for 2012: which is “Don’t Repeat Yourself!”

Advertisement

New Munki tools

A new release candidate of the Munki tools is available here:

http://munki.googlecode.com/files/munkitools-0.8.2.1475.0.mpkg.dmg

Fixing packages with expired signatures

In my previous post, I provided a tool to enable you to check your collection(s) of packages to determine if any are affected by the Package Apocalypse.

But what to do once you’ve found packages with expired signatures? If Apple has provided an updated replacement package at http://support.apple.com/downloads/, it’s probably best to replace the package with the expired signature with the updated one.

But that might not always be possible — Apple has not provided replacements for every package that has been affected, or the replacement might not be practical to use.

Package Apocalypse

Earlier this week a certificate Apple had used to sign flat packages over the last couple of years or so expired. This caused Apple to have to reissue a lot of update packages. This greatly affected sites running an Apple software update server, either Apple’s flavor, or the open-source Reposado replacement. See http://support.apple.com/kb/HT5198 for more info on how this affects Software Update.

This also affects some update packages you might have downloaded from http://support.apple.com/downloads. If they are flat packages, it’s possible they may also be signed with an expired certificate. Such packages can be manually installed – Installer.app will display a warning, but you can choose to ignore the warning and proceed.

But if you have a mechanism that uses Apple’s command-line installer tool, these packages will fail to install. This will affect popular tools like InstaDMG, DeployStudio, Apple’s System Image Utility, and any software distribution mechanism that makes use of the command-line installer tool. Some examples include Munki, Casper, and AbsoluteManage.

Worse, this problem affects at least one software package originally distributed on DVD: iLife ’11. If you’ve imported the packages for iLife ’11 into your software distribution mechanism, they may now fail to install because of the expired certificate.

I am working on a tool to fix affected packages. (UPDATE: see this post.) But in the meantime, if you want to get an idea of how many packages you have that are affected by this issue, you might want to make use of a tool I wrote. It will scan a directory of packages or disk images containing packages and print information on any packages with bad or expired certificates.

Get it here.

The tool relies on a pkgutil option introduced in Lion, so you’ll need to run this on Lion!

An example of checkPackageSignatures.py in use:

./checkPackageSignatures.py /Volumes/LaCie/InstaDMG/pkgs-10.6.8/

/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/Install iTunes.pkg:
Package "Install iTunes":
Status: signed by a certificate that has since expired
/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/JavaForMacOSX10.6Update4.pkg:
Package "JavaForMacOSX10.6Update4.pkg":
Status: signed by a certificate that has since expired
/Volumes/LaCie/SIU/Snow Leopard/pkgs-10.6.8/MacOSXUpdCombo10.6.8.pkg:
Package "MacOSXUpdCombo10.6.8.pkg":
Status: signed by a certificate that has since expired


Use this tool to scan any collection of packages you have to see which are affected by this issue. If a replacement package is available from Apple, you should replace it. If there is no replacement, there is hope. Keep checking back here for an update soon.

Local MCX update

I’ve done some testing now with MCX records moved into a new local node as described here. It seems to work well. In practice, it’s really no different than putting the MCX info in the Default local node, but there are a few advantages:

1. This refinement eliminates the MCXCCacheGraph() warnings in the system.log. They seemed to be harmless, but one can never be certain.
2. The underlying reason for the above error is now addressed – active computer records are now properly cached in the local directory service node. Specifically, you’ll find a cached copy of the active computer record from /var/db/dslocal/nodes/MCX/computers stored in /var/db/dslocal/nodes/Default/computers. When computer records were stored in the default local node, the caching mechanism failed because it was trying to cache a computer record in the same place and with the same name as the original record.
3. I’m hopeful that this will also address an issue I’ve seen on occasion myself, and have heard of others seeing — that during startup, some of the computer records in the default local node seem to get deleted. I think this is a result of the MCX caching mechanism as well.
4. Finally, this organization (putting all the MCX records in a separate directory node) makes it really easy to temporarily turn off all MCX management for a machine. You might see this as a net plus or a net minus. To temporarily turn off all MCX management, just remove the /Local/MCX node from the authentication search path, using Directory Utility or dscl. When you want to turn MCX back on, re-add the /Local/MCX node.

Some additional notes:

Brian Warsing made the excellent suggestion of adding a local admin user to the new /Local/MCX node as a way to be able to authenticate to that node using Workgroup Manager. I really didn’t want to keep track of a second local admin account and associated password, so I tried copying a local admin plist from the default local node to the /Local/MCX node. This failed to work to authenticate in Workgroup Manager, I suspect for much the same reason local accounts “mask” network accounts with the same name: OS X searches the directory services in the order given in the authentication search path. So it found my local admin account in the default local node and did not even check the new MCX node. It might be possible to at least link the passwords of an admin account in the default local node and the mcxadmin password by linking their shadow files in /var/db/shadow/hash — this way when you change your local admin account’s password, the mcxadmin’s password changes at the same time.
I haven’t tested this approach yet, but will soon.

Setting up this configuration for Local MCX is a bit more work than simply using the default local node, but I think it will be worth it.

Leopard, MobileAccounts, and NFS homes

On the MacEnterprise maillist, Arjen van Bochoven wrote of problems with automatic HomeSyncs under Leopard with NFS home directories. Manual syncs worked fine, but the automatic background syncs would fail with errors that looked like this:

1:: [228] Peer "network" is unable to sync. (-[SPeer_FS_PHD mountPeerVolume] (Peer-FS-PHD.m:140): "'((homePath))' is nil")
0:: [228] [2009/02/19 10:45:10.640] Peer "network" is unable to sync. Not enough peers will be available to continue syncing.
0:: [228] [2009/02/19 10:45:10.640] Aborting sync of "HomeSync_Mirror".

I saw the exact same problem in my environment. This also affected login and logout syncs. Here’s the (ugly) fix.

Network and Portable Home slides

Here is a slightly modified version of the slides I used at presentation earlier in 2008 on the topic of Network and Portable Home Directories.

Macworld 2009 MCX presentation

Here is a PDF of my presentation at Macworld SF 2008 on Managing OS X Clients with or without Open Directory.

Converting NetInfo accounts to dslocal

If you are doing an in-place upgrade from Tiger to Leopard without using the Apple Leopard Install DVD, you may need a way to convert existing local or mobile accounts from NetInfo to the dslocal store.

Here’s a script that converts local accounts; it requires the nicl binary, which you can copy from any Tiger installation.

For local accounts, it uses nicl to read the account info, and dscl to create a new corresponding account. For mobile accounts, it uses createmobileaccount to recreate the mobile account.

Enjoy.

Managed Client: managed Dock folders have incorrect behavior on Leopard

Folders added to the Dock on Leopard machines do not behave as stacks or folders.

Steps to Reproduce:
1. Open Workgroup Manager.
2. Select a user object to manage.
3. Click the Preferences icon.
4. Click the Dock item in the Preferences management view.
5. Select Manage: Once
6. Add some folders to the User’s dock. (For example, /Applications and /Applications/Utilities)
7. Click Apply Now and Done
8. On a managed Leopard machine, log in as the user.
9. Note that the folders now appear in the user’s dock, but…

The newly added dock folder items should behave as Stacks or Folders. Instead, they behave like documents – clicking on them opens them in the Finder, but there is no other folder-like behavior in the Dock (no pop-up menu, no stacks behavior)

Workaround:
In the Preferences Details view in WGM, select com.apple.dock, then Once->Document Tiles->Document Tile->Tile Type and edit the value from “file-tile” to “directory-tile”. This causes the expected behavior in the managed Dock, but causes Workgroup Manager to throw a bunch of assertion errors if you select the Dock in Preferences->Overview view. This may also exhibit undesired behavior with Tiger clients – so test.