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!”

MacTech magazine May 2012

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.
Continue reading “Fixing packages with expired signatures”

Fixing packages with expired signatures

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.

Package Apocalypse

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.

Local MCX update

Leopard, MobileAccounts, and NFS homes

HomeSyncOn 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. Continue reading “Leopard, MobileAccounts, and NFS homes”

Leopard, MobileAccounts, and NFS homes