Since we’ve examined some ways to script around Software Update’s limitations, I thought maybe now would be a good time to describe changes I’d like to see to Apple’s Software Update so we don’t have to hack at it…

When a client is managed via MCX to use an internal Software Update Server, there should be an additional management option that causes Apple Software Update to behave in the following manner:

1. Available updates are downloaded in the background. (This exists currently)
2. When all available updates have been downloaded, if a user is logged in, the user is notified that updates are available (This also exists currently)
3. When the user clicks “Install”, the updates should be installed without requiring administrator credentials. Since the admin has “approved” the updates by making them available on the internal Software Update Server, and has enabled the proposed “non-admin” install option via MCX client management, no further administrative approval should be needed/required. (This would be new behavior).
4. If no user is currently logged in, all managed updates (those on the internal SUS) are installed, but there is a progress window displayed over/instead of the loginwindow so a user does not login or power off a machine during a software update session. (This would be new behavior).

These changes would allow systems administrators to deploy Apple software updates to a group of machines without resorting to scripting hacks, running background command-line processes that can interfere with active users, or third-party tools that largely (and incompletely) duplicate Apple’s solutions.

In addition:

1. Admins should be able to mark updates on their internal Software Update Servers as mandatory.
2. When an OS X Client is managed to use an internal SUS, updates marked as mandatory should not be able to be deselected by the user.

This change would allow systems administrators to use an internal Software Update Server to deploy critical updates (like Security Updates) without resorting to scripting hacks or third-party tools.

At work, I’ve been working on a solution for handling Apple Software Updates for non-administrative users. Each approach I’ve tried has serious obstacles. Here’s a brief history of what I’ve tried and what worked and what didn’t.

First, a little background: Apple provides a Software Update Server as part of Mac OS X Server. This allows you to cache Apple’s updates on a local server for more efficient use of Internet bandwidth, and more importantly, a local Software Update Server allows you to choose which items you want to make available to your organization — for example, you can choose to not make an update available to machines in your organization until after you’ve finished testing it in your environment.

But hosting a local Software Update Server does not solve a fundamental problem: how to get the updates onto a machine without requiring administrator privileges for the machine’s user(s). Hosting a local Software Update Server is no different than relying on Apple’s servers in this regard; someone must authorize Software Update.app with administrative credentials.

So if you want to use Software Update to distribute updates to your machine, this means either providing all your users with administrative credentials, or having admins visit each machine. It would be better if we could find a way to install updates without requiring a user to type in an admin password.

If you are using a third-party solution for installing software and handling non-Apple updates, something like radmind, LANrev, FileWave, or Casper, these products may have their own mechanisms for handling Apple Software Updates. If they don’t, you always have the option of downloading the updates from Apple and importing them into your management system just as you would any third-party software.

But a downside to doing this is that you may lose the logic Apple uses to determine which updates are applicable to each machine. You may find yourself having to replicate this logic in some way. The larger the number of unique hardware and software configurations you have, the harder and more tedious this becomes. So you may want to find a way to leverage Apple’s tools.

The obvious first approach: as root (via cron, launchd, ARD or ssh), run the command-line Software Update tool:

/usr/sbin/softwareupdate -i -a

This is simple, but has several problems:

1. The only safe time to do this is when no-one is logged in, since a restart may be required, or applications that are in use might be updated. But if you do it when no-one is logged in, and you provide no user feedback as to what is happening, you run the risk that the user will shutdown, restart, or log in while the process is happening. The first two could cause you to have an unbootable machine; a user logging in could be a problem if a restart is required or the user attempts to use applications that are being updated.
2. Since a user might be waiting to use the machine while this process is happening, ideally you’d want to have some sort of progress indicator, and also you’d like to do the downloads separately from the install so that the time your users are forced to be logged out is minimized. But /usr/sbin/softwareupdate’s output is almost impossible to use to construct meaningful progress info, and it has no way to download items in advance.
3. You are thinking “But what about softwareupdate -d -a? Doesn’t that download all the available updates?” Why yes, it does. Unfortunately, there’s no way to tell softwareupdate to use those downloads, if you later run softwareupdate -i -a, it will download them all over again.

If you are willing to make the user wait for the entire download and install process while the machine is logged out with no real progress feedback, then this approach might work. If you have a bunch of desktop machines that will be on (or can be set to wake up/power up) in the wee hours of the morning, this approach might work, as the lengthy updating can happen when no-one is around. If, on the other hand, you have a large number of laptop machines, this approach is less likely to be accepted by your users. They’ll have to participate in the updating of their machines, and won’t like having no indication of how long an update might take. They are more likely to get annoyed or impatient and simply turn off the machine in the middle of the update, because it may appear that the machine is locked up.

So that brings us to the next approach: again, with a script running as root, use softwareupdate -d -a to find and download the available updates, then use /usr/sbin/installer to install them. This seems promising, because /usr/sbin/installer gives reasonable progress feedback that you could then pass to the user.

Unfortunately, not everything downloaded via softwareupdate -d -a is in a format that /usr/sbin/installer knows how to install. And so far, I haven’t been able to preflight these items to know in advance what can be successfully installed and what cannot — you just have to try and see if /usr/sbin/installer throws an installation error back at you. So unless we can figure out how to detect and deal with the “broken” downloads, this is not an ideal solution, as there will be updates that are not installable via this method.

Now for the third approach.

It is possible to trigger the process that downloads updates in the background into /Library/Updates/ — the same one that, when updates are available, then opens the Software Update.app and prompts you to install them. (On Snow Leopard, this is essentially the same thing as running softwareupdate -d -a; on Leopard, softwareupdate -d -a does something different, downloading them into the Downloads directory of the current user.)

Once these items are staged in /Library/Updates, you can re-write the /Library/Updates/index.plist and touch a file to tell Software Update to install these upon restart; this is a variation of the built-in behavior when you use the Software Update app and choose to install items that require a restart – you are logged out, the items are installed, and then the machine is restarted.

Here’s a shell script that gets the basic steps done:

#!/bin/sh

defaults -currentHost write com.apple.SoftwareUpdate AgreedToLicenseAgrement -bool YES
defaults -currentHost write com.apple.SoftwareUpdate AutomaticDownload -bool YES
defaults -currentHost write com.apple.SoftwareUpdate LaunchAppInBackground -bool YES

#Take away execute & read rights so Software Update doesn't open during a user session
chmod 700 /System/Library/CoreServices/Software\ Update.app
#Check for new updates
/System/Library/CoreServices/Software\ Update.app/Contents/Resources/SoftwareUpdateCheck
#Put execute and read rights back
chmod 755 /System/Library/CoreServices/Software\ Update.app

#This sets up all the files so that it will install on restart
installarray=`defaults read /Library/Updates/index ProductPaths | grep -v "[{}]" | awk -F "=" '{print $1}' | grep -o "[^\" ]\+"`
defaults write /Library/Updates/index InstallAtLogout -array "$installarray"
touch /var/db/.SoftwareUpdateAtLogout
chmod og-r /var/db/.SoftwareUpdateAtLogout

Leveraging this has several attractions: you are using Apple’s processes and logic for installing updates; you get progress feedback for free, since you are using Apple’s tools, and the updates can be downloaded in advance, minimizing the time required at logout to install the updates.

There are some drawbacks:

• You have to trigger a restart to initiate the install; even for items that don’t require a restart.
• When the restart is triggered, a dialog appears telling the user there are updates to be installed and giving them two choices “Restart”, or “Install and Restart”. While it’s good to have the choice, it’s an additional bit of noise if you’ve already asked them to restart to install the updates.
• And the big one: there’s no clean, Apple-supported way to programmatically trigger the install if you are already sitting at the loginwindow.

  If a user is logged in, you can do this:

  osascript -e 'tell application "System Events" to restart

  But if no user is logged in, the above doesn’t work. If you do shutdown -r now, the machine just restarts without installing. If you click the Restart button in the loginwindow, you are prompted to allow the installs to happen, which is what we want. It turns out that in Leopard and Snow Leopard, after a little setup, we can do just that programmatically with:

  osascript -e 'tell application "System Events" to tell process "SecurityAgent" to click button "Restart" of window 1'

  This doesn’t work, obviously, if the administrator (or user!) has disabled the Restart button from appearing in the loginwindow, so it’s not particularly robust, but it’s the best we have right now.

A fourth approach:

A script running as root launches the Software Update.app:

#/bin/sh
/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Ideally, you’d use a launchd job that watched a path writable by non-privileged users. When that path was modified, the launchd job would fire, launching Software Update as root.

Advantages:

• Once Software Update is running as root, the user can download and install anything Software Update makes available without having to enter administrative credentials.
• You’re using even more of Apple’s code and relying less on your own, making this a robust solution.

Possible disadvantages:

• The user can choose to not install some items — this could make it more difficult to apply Security Updates in a timely manner
• Since Software Update.app is running as root, there are potential security risks; it might be possible to use a flaw in Software Update.app to can root privileges elsewhere.
• This approach doesn’t help you install updates when no-one is logged in; it only works with user involvement and cooperation.

So there you are. Four ways to get Apple Software Updates installed on machines without requiring your end users have administrative credentials.

No one approach works in all situations, but perhaps one of these approaches will work for you.

While digging into the Adobe install process, I needed to be able to translate from “AdobeCodes” like “{27B54140-8302-4B5D-83DD-AEE4B18BC7A4}” to product names like “Adobe Encore CS4″ and the installer payload name like “AdobeEncore4All”.

I ended up writing a Python script to crawl through the payloads directory of Adobe install media to generate a table. The script is below, and called like:

python adobeparser.py /path/to/payloads

It’s probably not generally useful, though I include it just for completeness…

#!/usr/bin/env python
# encoding: utf-8
"""
adobeparser.py

Created by Greg Neagle on 2009-10-07.
"""

import sys
import os
import optparse
from xml.dom import minidom

def parseAdobeProxyXML(filename):
    payloadinfo = {}
    dom = minidom.parse(filename)
    installer_properties = dom.getElementsByTagName("InstallerProperties")
    if installer_properties:
        properties = installer_properties[0].getElementsByTagName("Property")
        if properties:
            for prop in properties:
                if 'name' in prop.attributes.keys():
                    propertyname = prop.attributes['name'].value
                    propertyvalue = ""
                    for node in prop.childNodes:
                        propertyvalue += node.nodeValue
                    payloadinfo[propertyname] = propertyvalue

    return payloadinfo

def analyzePayloads(dirname):
    payloads = []
    dirname = dirname.rstrip("/")
    if dirname.endswith('payloads'):
        for payloaditem in os.listdir(dirname):
            payloaditempath = os.path.join(dirname, payloaditem)
            if os.path.isdir(payloaditempath):
                for item in os.listdir(payloaditempath):
                    if item.endswith(".proxy.xml"):
                        proxyxmlfile = os.path.join(payloaditempath, item)
                        payloadinfo = parseAdobeProxyXML(proxyxmlfile)
                        payloadinfo['ComponentName'] = payloaditem
                        if payloadinfo:
                            payloads.append(payloadinfo)
                        break

    return payloads

def main():
    p = optparse.OptionParser()
    options, arguments = p.parse_args()
    if arguments:
        payloads = analyzePayloads(arguments[0])
        print "Adobe Code\tName\tVersion"
        for payload in payloads:
            print "%s\t%s\t%s\t%s" % (payload['AdobeCode'], payload['ProductName'], payload['ProductVersion'], payload['ComponentName'])

if __name__ == '__main__':
	main()

I ran this script against the payloads folder on the Adobe CS4 Master Collection installation media. I then sorted the output by AdobeCode and added a header line, and here is the result: a tab-delimited list of AdobeCodes, ProductNames, ProductVersions, and PayloadNames.

I hope this list is useful to someone other than me! Combine this with the info here and you can get a pretty good idea of everything that’s installed.

This post will act as a running log of today’s struggles with the CS4 Deployment Toolkit. This post was updated several times today, so if you read it earlier today, there may be new stuff added….

• Start with the install media for Adobe CS4 Master Collection.
• Run the CS4 Deployment Toolkit app and create a “package” that installs only Flash, Dreamweaver, Fireworks, and Contribute.
• Move the package and install media files to the test machine
• Run the AdobeUberInstaller

Result?

Flash, Dreamweaver, Fireworks and Contribute are installed. But…

So are:
After Effects, Encore, Premiere Pro, and Soundbooth. Or are they?

The application folders are there, but inside: broken apps.

Sheesh.

If you look at the AdobeUberInstaller.xml generated by the CS4 Deployment Toolkit, and go through the painful process of translating “AdobeCodes” like “{3EE73408-5536-4C99-9CEB-06C2A7A726B4}” into product names, we find that After Effects, Encore, Premiere Pro, and Soundbooth are not referenced at all in the XML file. I definitely unchecked them in the CS4 Deployment Toolkit, but they are not mentioned at all. Perhaps the default behavior is supposed to be “donotinstall”, but in actual practice, it seems to be something else.

In my case, the observed behavior is “partially install as broken”.

So I tried a few things; including manually editing the AdobeUberInstall.xml file, adding explicit “donotinstall” actions for the four unwanted apps:

	<!--added by gneagle-->
        <!--Adobe After Effects CS4-->
        <Payload adobeCode="{F706302E-1402-4D8D-8ABB-26B18ECAEFBB}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Encore CS4-->
        <Payload adobeCode="{27B54140-8302-4B5D-83DD-AEE4B18BC7A4}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Premiere Pro CS4-->
        <Payload adobeCode="{21EEB50A-C615-4B7B-928B-4262121A7C78}">
          <Action>donotinstall</Action>
        </Payload>
        <!--Adobe Soundbooth CS4-->
        <Payload adobeCode="{5AC26AE4-130C-4296-9BA8-563A99AE1946}">
          <Action>donotinstall</Action>
        </Payload>

But still no go – directories were still created under /Applications with broken application bundles for Premiere, After Effects, Soundbooth, and Encore.

So I started poking through the install log in /Library/Logs/Adobe/Installers, in this case named “Adobe Creative Suite 4 Master Collection 4.0 10-07-2009.log”.

I found a section that looked like this:

BEGIN InstallOperationsQueue Unordered operations
  {02FD2912-C5C4-41f0-B7D2-0C1871EB9565} Adobe Flash CS4 Extension - Flash Lite STI es: with operation none
  {046EB5D9-BDAB-4D5A-BC23-45583F6B8EF0} Adobe Premiere Pro CS4 Functional Content: with operation none
  {064F0D64-1F54-4F4B-953E-BAED5D7E69B2} PDF Settings CS4: with operation install

This looked promising. Buried in this section of the log were these lines (they weren’t all next to one another; I’ve put them all together here for brevity):

{0AEC3900-1F89-4649-9D10-B0469D5F6A0B} Adobe Premiere Pro CS4 Third Party Content: with operation install
{D5AD1A24-F381-4D67-BA1C-A2661AEB06A5} Adobe Soundbooth CS4 Codecs: with operation install
{575C8FA0-8180-4554-828A-1AD52446CAA1} Adobe Encore CS4 Codecs: with operation install
{568E0A79-996C-4B04-B613-F06CBE7B320B} Adobe After Effects CS4 Third Party Content: with operation install

Aha!

Somehow, some subcomponents for Premiere, Soundbooth, Encore, and After Effects were being selected for install. A peek inside the broken application bundles seemed to match the payload descriptions above, so I think I’ve found the culprit.

Now to figure out how I can get these items deselected for install…

Back to CS4 Deployment Toolkit.

Start creating a package. Point it at the install files for the CS4 Master Collection. Proceed to the Product Options screen and search for:

Adobe After Effects CS4 Third Party Content
Adobe Premiere Pro CS4 Third Party Content
Adobe Soundbooth CS4 Codecs
Adobe Encore CS4 Codecs

They do not exist in the GUI, and cannot be deselected! Grrrr….

No matter – I’ll just add them manually to the AdobeUberInstaller.xml file:

<!--added by gneagle-->
<!--Adobe Premiere Pro CS4 Third Party Content-->
<Payload adobeCode="{0AEC3900-1F89-4649-9D10-B0469D5F6A0B}">
  <Action>donotinstall</Action>
</Payload>
<!-- Adobe Soundbooth CS4 Codecs-->
<Payload adobeCode="{D5AD1A24-F381-4D67-BA1C-A2661AEB06A5}">
  <Action>donotinstall</Action>
</Payload>
<!--Adobe Encore CS4 Codecs-->
<Payload adobeCode="{575C8FA0-8180-4554-828A-1AD52446CAA1}">
  <Action>donotinstall</Action>
</Payload>
<!--Adobe After Effects CS4 Third Party Content-->
<Payload adobeCode="{568E0A79-996C-4B04-B613-F06CBE7B320B}">
  <Action>donotinstall</Action>
</Payload>

And now to test…

FAIL. Broken app bundles for After Effects, Encore, Premiere Pro, and Soundbooth.

Is this thing just broken? Let’s go back a bit.

I remove all the Adobe apps and shared files from my test machine (AdobeUberUninstall plus some manual cleanup), and then manually run the Setup.app from the CS4 Master Collection media, and choose the same options I chose with the CS4 Deployment Toolkit.

Same result. Broken app bundles for apps I didn’t choose to install.

So in this case, it’s not the Enterprise Deployment Toolkit that’s failing, it’s the underlying install process — you get the same broken results with a manual install.

After getting lots of suggestions, and spending a few days tearing apart the JavaScript files that are part of the Adobe setup/install process, I have some progress to report on the task of getting Adobe Enterprise Deployment Toolkit “packages” to work from disk images.

I was hoping to wrap up the installation files, the AdobeUber* programs and the AdobeUber*.xml files into a disk image. I could then copy that disk image to a given machine, mount it, and run AdobeUberInstaller.

My initial testing failed miserably – Adobe’s Setup application failed with “Exit Code 7″ when I tried to run the install from a mounted disk image, yet the same files copied to a local folder installed fine.

A little more digging into the various logs, and I found this:

Found deployment properties:
Setting property "INSTALLDIR" to: /Applications
Setting property "installLanguage" to: en_US
[       0] Fri Oct  2 10:23:26 2009 DEBUG
Supported languages:
[       0] Fri Oct  2 10:23:26 2009 FATAL
Exception: Could not get the list of supported languages
Exit code: 7
[       0] Fri Oct  2 10:23:26 2009  INFO

I tore into the various JavaScript files that are part of the install process, and even added some debugging/logging code to some of the JavaScripts so I could see what was happening. I eventually determined that it failed to get the list of supported languages because it was looking in the wrong place for the payloads! Instead of looking under the InstallerLocation path as specified in the AdobeUberInstaller.xml file, it was looking in “/Volumes/Adobe Photoshop CS4/Adobe Photoshop CS4/payloads/”.

Hmmm. That would be the path if we had mounted the original ESD disk media from Adobe. So as an experiment, I simply mounted the original ESD disk image, and tried again with a new AdobeUberInstaller.xml pointing to this path.

Success.

It appears that there is a bug somewhere in the Setup code (and I have looked at the JavaScripts to no avail, so it’s probably buried in the Setup.app itself) that checks to see if the payloads are on a disk image, and then just assumes the original disk image path from there on, ignoring any other info.

You should then be able to get an Adobe deployment to work from disk image one of these ways:

1. Convert the ESD disk to a read-write image and add the AdobeUber* files to it. Optionally convert it back to read-only.
2. Create a separate disk image containing the AdobeUber* files. Deliver this disk image _and_ the ESD diskimage to the target machine. Mount them both, then invoke AdobeUberInstaller from its disk image.
3. Create a new disk image with the AdobeUber* files and the same folder structure to the payloads as the original ESD disk image. Make sure it has the same name for the mounted volume as the original ESD image.
4. Create a new diskimage with the AdobeUber* files, and embed the original ESD disk image inside that image.
5. Some other variation on these.

For all of these, you must mount the disk image containing the installation payloads at the “normal” place – i.e.: /Volumes/Adobe Photoshop CS4 or whatever. No mounting under /tmp or any other fancy handling. You can pass -nobrowse to hdiutil to prevent the mounted disk from showing up in the Finder.

There is one more way to get diskimages to work without jumping through all these hoops, and that is to trick the Setup.app into thinking it’s not a diskimage.

hdiutil attach diskimage.dmg -notremovable -kernel

This makes the OS treat the mounted filesystem as a non-removable disk, and the Adobe Setup.app now acts just like it would if the files are on the local disk. (It’s the ‘-notremovable’ switch that does the magic, but for some reason I kept getting “No mountable filesystems” until I added the ‘-kernel’ switch.) You can even mount it somewhere other than /Volumes (I like -mountRandom /tmp) and you almost certainly want to use -nobrowse.

Thanks to Brian Ling for this method — he originally suggested the ‘-notremovable’ switch and mentioned he needed to add ‘-kernel’ to get this to work in Snow Leopard; it may not be needed in Leopard, but probably doesn’t hurt, either.

There’s a big downside to this approach, however. When you attach a disk image as -notremovable, you cannot detach it completely without a restart. You can unmount any volumes mounted from the image, but the unmounted disk(s) will still show up in `diskutil list` until a reboot.

This is a bit ugly, but may not be a real issue for you, especially if you restart anyway after the installation.

In any case, we now have a few ways to wrap the Adobe Enterprise Deployment packages and their installation files into a disk image we can store on a fileserver which may not support HFS or AFP.

Of course, all is not rosy yet. I’m still fighting with the actual _results_ of the Adobe Enterprise Deployment Toolkit install – it seems to sometimes install things even though I’ve unchecked them using the CS4 Deployment Toolkit…. And the format of the AdobeUberInstaller.xml file, where each component is identified by an “AdobeCode” like “{3EE73408-5536-4C99-9CEB-06C2A7A726B4}” makes investigating this stuff really tedious.

So I know I’m late to the party here. I’ve just recently started playing with the Adobe Enterprise Deployment Toolkit for deploying CS4 applications. I’ve found all sorts of annoyances and oddities that I wanted to do a sanity check and see if I’m missing anything…

For the rest of this post, AEDT = Adobe Enterprise Deployment Toolkit.

1) “Silent” install?

One of the points of using the AEDT is to create a “silent” installer. Adobe has a funny idea of what “silent” is. If a user is logged in, you see the Setup icon appear in the Dock (sometimes bouncing _forever_ before finally settling down), and worse, a series of alphanumerically-named disk images appear and disappear from the Desktop and/or Finder sidebar. It’s obnoxious and distracting. Yes, it doesn’t make any _sounds_, so I guess it’s silent.

If you try to run this same installer when no-one is logged in, it may not complete at all, but instead hang forever in the middle of the install. I could reproduce this problem over and over, but but poking around with ‘top’ and ‘lsof’ and looking at the system log, I figured out it was hanging while trying to install Adobe AIR. Funny, I was pretty sure I deselected that when I created the AdobeUberInstaller/Uninstaller.xml files… Rebuilt the “package” again using AEDT and now that issue seems to have gone away. Still, another reason to avoid Adobe AIR.

2) Disk image?

AEDT “packages” are really just copies of the AdobeUberInstaller and AdobeUberUninstaller and two XML files that tell those tools what to do. Each XML file contains a path to the contents of Adobe installation media; typically copied from DVDs or disk images into a folder somewhere. You can put these installation media contents on a file server (AFP only, please, SMB and NFS not supported!), or copy the media to the local machine before installing. Although the XML files generated by the AEDT contain absolute paths to the installation files, you can edit them using a text editor and provide a relative path (relative to the directory containing AdobeUberInstaller and AdobeUberUninstaller). So you can set up a folder like so:

PhotoshopCS4/
	AdobeUberInstaller
	AdobeUberInstaller.xml
	AdobeUberUninstaller
	AdobeUberUninstaller.xml
	PhotoshopCS4InstallMedia/

And set the InstallerLocation in the XML files to look like this:

<InstallerLocation>./PhotoshopCS4InstallMedia</InstallerLocation>


This works if you copy the folder to the target machine – say to /Users/Shared/, and then run the UberInstaller:

/User/Shared/PhotoshopCS4/AdobeUberInstaller

Success. Adobe Photoshop CS4 is installed. Run the AdobeUberInstaller, and it is uninstalled. (Except for Adobe Media Player.app, which you specified you didn’t want installed in the first place, but it did it anyway, but that’s a rant for another time…) So far, so good. Now you want to encapsulate this a bit to make it easier to store and copy to a machine, so you build a read-only, compressed disk image of the PhotoshopCS4 folder.
Next, you mount the disk image and try to run the UberInstaller.

/Volumes/AdobePhotoshopCS4/AdobeUberInstaller

It churns for a while, then:

FAIL with Exit code 7, which means “Unable to complete the Silent workflow”. That’s helpful. The logs are not too helpful either. Go back to the folder you created the disk image from, and it installs fine. Uninstall from the folder. OK. Now try the disk image again.

FAIL.

Has anyone gotten this to work from a disk image? Am I missing something? Gah.

John Welch has written passionately about Adobe installers many times over the years. Here’s another to add to the list, though not as colorfully as Mr. Welch might have done…

The Lightroom 2.3 installer is an order of magnitude better than most other Adobe installers:

• It is a standard Apple Installer package.
• It installs just one thing: Adobe Lightroom 2.3.
• It does not secretly install Flash, or Air, or Adobe Reader.
• It stores its registration info in a separate file from the Adobe CS2, CS3, and CS4 apps, so you don’t have to worry about registrations clobbering each other.

But it’s not perfect.

Problem #1: the postinstall script at Contents/Resources/postinstall:

#!/bin/bash
#
# This postinstall script copies the camera raw profiles into the
# application support folder

ditto -kx "$1/Contents/Resources/profiles.zip" "/Library/Application Support/Adobe/CameraRaw/CameraProfiles"

This uses ditto to copy stuff out of a ZIP archive to /Library/Application Support/Adobe/CameraRaw/CameraProfiles/

Why? Why couldn’t this just be in the package payload? Or why couldn’t this be a metapackage, where one package installed Adobe Lightroom and another installed the CameraProfiles?

As an administrator, I don’t want to read scripts to see what else a package has installed – it should be in the bom files for the installer. Worse, we’ll never see a useful uninstall capability as long as software vendors pull this sort of thing. Ideally, we should be able to look at /Library/Receipts to see what has been installed, and in the future, be able to use this same info to uninstall things. Postflight or postinstall scripts that install additional things break this concept.

But it gets worse.

Let’s look at the postflight script at Contents/Resources/postflight:

#!/bin/bash
#
# remove the receipt file, which causes problems if people try to reinstall
# an earlier version

RMPATH="/Library/Receipts/`basename "$1"`"
echo "removing receipt $RMPATH"
rm -rf "$RMPATH"

It removes its own receipt! Now we’re really horked if we want to find out what’s been installed. Adobe destroys the evidence!

Sigh.

Here’s a version of a script we use on all our machines in an attempt to reduce energy usage with a minimum of visible impact on users. Our machines are set to not sleep during the day. This script runs hourly, and if it’s after 7pm and the machine has been idle for 20 minutes or more, it tries to sleep the machine if someone is logged in, or shut it down if no-one is logged in.
The machine is also set to automatically startup or wake at 6am M-F. The net result is that most of our desktop machines go to sleep or shutdown a little after 7pm each weeknight and wake up at 6am each week morning, and our users are none the wiser.

#!/bin/sh

# Sleep or shutdown script
# tryin' to be 'green'.....

# look for exception file
if [ -f "/var/db/.dontSleep" ]; then
	exit 0
fi

# if we're a laptop, exit.
# No shutting down laptops (or waking them up unbidden!)
IS_LAPTOP=`/usr/sbin/system_profiler SPHardwareDataType | grep "Model" | grep "Book"`
if [ "$IS_LAPTOP" != "" ]; then
	exit 0
fi

# check the time; exit if it's between 5 am and 7 pm
current_hour=`/bin/date +%H`
if [ $current_hour -gt 5 -a $current_hour -lt 19 ]; then
	exit 0
fi

# now check idle time;
# exit if we've been idle less than 20 minutes
idleTime=`ioreg -c IOHIDSystem | perl -ane 'if (/Idle/) {$idle=int((pop @F)/1000000000); print $idle,"\n"; last}'`
if [ $idleTime -lt 1200 ]; then
	exit 0
fi

# tell Power Manager to wake us up or turn us on at 6am M-F
pmset repeat wakeorpoweron MTWRF 06:00:00

# check to see if a user's logged into the console
login_status=`/usr/bin/who | /usr/bin/awk '{ print $2 }'`
for i in $login_status; do
  if [ $i = "console" ]; then
       # someone's logged in, sleep
       osascript -e 'tell application "System Events" to sleep'
       exit 0
  fi
done

# if we got this far, it's OK to shut down.
/sbin/shutdown -h now
exit 0

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.

For each mobile account, you’ll need to make two modifications to the account info in the local DS:

/usr/bin/dscl . create /Users/$USERNAME dsAttrTypeStandard:OriginalHomeDirectory "nfs://$NFSEXPORT$USERNAME"

where $USERNAME is the short username, and $NFSEXPORT is the nfsserver and its export.

This gives HomeSync a nfs:// URL to use to mount the network home directory (It shouldn’t have to do this, since the network home is already available at the autofs mountpoint for the network home, and obviously really doesn’t need it since manual syncs work), but we have to do it anyway.

The OriginalHomeDirectory attribute has two parts – a URL describing the mount, and a path describing the path to the actual home dir, relative to the mount. In my case, when I type `mount`, my home autofs mount looks like this:

homeserver:/vol/home/fahome on /home/fahome

and my NFS home path is /home/fahome/gneagle

So the URL is ‘nfs://homeserver/vol/home/fahome/’ and the path is ‘gneagle’.

Depending on how the home mounts are setup in your environment, the division between the URL and the path might be different, for example, we might have had this instead:

URL ‘nfs://homeserver/vol/home/’ with a path of ‘fahome/gneagle’.

The next change:
/usr/bin/dscl . append /Users/$USERNAME dsAttrTypeNative:preserved_attributes dsAttrTypeStandard:OriginalHomeDirectory

This prevents the OriginalHomeDirectory attribute from being overwritten by the empty value presumably coming from the network. (If there was a useful value in the network directory, this hack wouldn’t be needed.)

You may be able to create the accounts “correctly” in the first place by using /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount and passing the syncURL with the -u option in the form “nfs://homeserver/export/home/gneagle”. This didn’t work in my environment, and even if it did, it wasn’t really an option to use createmobileaccount, so I instead wrote a login hook that “fixes” the mobile account if needed. WordPress will cut off the right side of the script when displaying it, but you can select, copy and paste into your favorite text editor for examination:

#!/bin/sh

# Leopard bug workaround as of 10.5.2. March 5 2008
# inserts nfs:// URL into OriginalHomeDirectory attribute
# for mobile accounts so that login/logout/background syncs
# work reliably
#
# Greg Neagle, Walt Disney Animation Studios

# the following is the actual NFS share that is mounted via autofs
NFSEXPORT="homeserver.example.com/vol/home/fahome/"

USERNAME=$1
LOCALACCT=`/usr/bin/dscl . read /Users/$USERNAME 2>/dev/null`
if [ "$LOCALACCT" != "" ]; then
  # $USERNAME is a local account
  NETHOME=`/bin/echo $LOCALACCT | /usr/bin/grep OriginalNFSHomeDirectory`
  if [ "$NETHOME" != "" ]; then
    # $USERNAME is a mobile account
    # in our case, the path and the username are one and the same
    /usr/bin/dscl . create /Users/$USERNAME dsAttrTypeStandard:OriginalHomeDirectory "nfs://$NFSEXPORT$USERNAME"
    PRESERVED_ORIG_HOME=`/usr/bin/dscl . read /Users/$USERNAME dsAttrTypeNative:preserved_attributes | /usr/bin/grep dsAttrTypeStandard:OriginalHomeDirectory`
    if [ "$PRESERVED_ORIG_HOME" = "" ]; then
      /usr/bin/dscl . append /Users/$USERNAME dsAttrTypeNative:preserved_attributes dsAttrTypeStandard:OriginalHomeDirectory
    fi
  fi
fi

The user logs in with their network account. MCX computer group settings cause the user to be asked if they want to create a mobile account, if they agree the mobile account is created and the home directory is encrypted with FileVault. As they log in, the login hook runs and if needed, inserts the additional info into the cached local account info so that automatic HomeSyncs work.

Though this fixed the issue for our environment, I still consider this a bug.

UPDATE 1/23/09: some commenters asked about cleanup of the LKDC (new in Leopard) – I’ve added that to the script.

At the Macworld Expo 2009 Power Tools System Imaging and Deployment session today, I was asked to share a “checklist” of cleanup steps I use when building images the “classic” way. (The InstaDMG methodology of image building makes cleanup steps unneeded.)

Here’s a cleaned-up version of the script I use, with site-specific stuff removed for the most part.

If you use this, you’ll need to modify the paths to any local user home directories for any local users you have on your image. There are generic examples for a local admin user named “admin” and the root user (which if you never login as root, you shouldn’t have to clean up!)

#!/bin/sh
#this script does some cleanup in preperation for building an image
#best to run this from single user mode, or at least right before you shutdown
#run this as root, or with sudo rights

#set machine names back to generic
/usr/sbin/scutil --set ComputerName "OSX_Standard_Image"
/usr/sbin/scutil --set LocalHostName "osximg"

#delete swapfiles
rm /private/var/vm/swapfile*

#delete volume info DB
rm /private/var/db/volinfo.database

#cleanup local admin's home dir
rm -rf /Users/admin/Desktop/*
rm -rf /Users/admin/Documents/*
rm -rf /Users/admin/Library/Caches/*
rm -rf /Users/admin/Library/Recent\ Servers/*
rm -rf /Users/admin/Library/Logs/*
rm -rf /Users/admin/Library/Keychains/*
rm -rf /Users/admin/Library/Preferences/ByHost/*
rm -f /Users/admin/Library/Preferences/com.apple.recentitems.plist
rm -rf /Users/admin/Movies/*
rm -rf /Users/admin/Music/*
rm -rf /Users/admin/Pictures/*
rm -rf /Users/admin/Public/Drop\ Box/* 

#cleanup root's home dir
rm -rf /private/var/root/Desktop/*
rm -rf /private/var/root/Documents/*
rm -rf /private/var/root/Downloads/*
rm -rf /private/var/root/Library/Caches/*
rm -rf /private/var/root/Library/Recent\ Servers/*
rm -rf /private/var/root/Library/Logs/*
rm -rf /private/var/root/Library/Keychains/*
rm -rf /private/var/root/Library/Preferences/ByHost/*
rm -f /private/var/root/Library/Preferences/com.apple.recentitems.plist
rm -rf /private/var/root/Public/Drop\ Box/*

#clean up global caches and temp data
rm -rf /Library/Caches/*
rm -rf /System/Library/Caches/*
rm -rf /Users/Shared/*
rm -f /private/etc/ssh_host*

#network interfaces - this is regenerated on reboot and can differ on different hardware
rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

#Leopard - cleanup local KDC, see http://support.apple.com/kb/TS1245
/usr/sbin/systemkeychain -k /Library/Keychains/System.keychain -C -f
rm -rf /var/db/krb5kdc
/usr/bin/defaults delete /System/Library/LaunchDaemons/com.apple.configureLocalKDC Disabled

#log cleanup.  We touch the log file after removing it since syslog
#won't create missing logs.
rm /private/var/log/alf.log
touch /private/var/log/alf.log
rm /private/var/log/cups/access_log
touch /private/var/log/cups/access_log
rm /private/var/log/cups/error_log
touch /private/var/log/cups/error_log
rm /private/var/log/cups/page_log
touch /private/var/log/cups/page_log
rm /private/var/log/daily.out
rm /private/var/log/ftp.log*
touch /private/var/log/ftp.log
rm -rf /private/var/log/httpd/*
rm /private/var/log/lastlog
rm /private/var/log/lookupd.log*
rm /private/var/log/lpr.log*
rm /private/var/log/mail.log*
touch /private/var/log/lpr.log
rm /private/var/log/mail.log*
touch /private/var/log/mail.log
rm /private/var/log/monthly.out
rm /private/var/log/run_radmind.log
rm -rf /private/var/log/samba/*
rm /private/var/log/secure.log
touch /private/var/log/secure.log
rm /private/var/log/system.log*
touch /private/var/log/system.log
rm /private/var/log/weekly.out
rm /private/var/log/windowserver.log
touch /private/var/log/windowserver.log
rm /private/var/log/windowserver_last.log
rm /private/var/log/wtmp.*