How To Allow MacOS X 10.4, 10.5, and 10.6 Client Computers To Update Against a MacOS X 10.6 Sofware Update Server Using a Single Common URL

Posted on Posted in Apple

UPDATE: There is an Apple support doc that covers this subject. The document covers a few other different techniques of doing this: http://support.apple.com/kb/HT4069

————

UPDATE 2: The Apple support doc mentioned above lists a solution using Apache mod_rewrite. That was the solution I needed to work since it allows for this change to be completely server-side and I wouldn’t need to touch my clients. Unfortunately after making the suggested changes mentioned in the support doc, upon restart of my Software Update Service, all those changes were automatically deleted by the service. The service appears to automatically delete any customized changes you make outside of the GUI interface. This is similar to behavior I have noticed with the web service and trying to make direct changes to its Apache conf files instead of using the Server Admin app.

————

Update 3: To make the Apple support doc recommended Apache mod_rewrite changes stick, you need to also add the lines to the “template” swupd.conf file located at /System/Library/PrivateFrameworks/SUServer.framework/Versions/A/Resources/swupd.conf

Problem Description

In an Open Directory setup that supports multiple different versions of MacOS X and where you are pointing the client computers to a local MacOS X 10.6 Software Update server, according to Apple you need to specify a different update server URL for MacOS X 10.4, 10.5, and 10.6 clients. This poses a problem because if all of the other Open Directory preferences that you are pushing out to clients are the same, the unique Software Update Server URL requirement will require you to create a separate computer group for computers of each MacOS X version. This will result in you having to triple all of your computer groups and preference settings on those groups just for this one setting. Very inefficient.

Solution

Each of the unique MacOS X software update URLs you are supposed to use loads a unique XML file containing the list of updates for the version of MacOS X the XML file is for. So you need to create a single URL that can return the correct XML file based on the version of MacOS X on the client computer that loads the URL. This can be accomplished by creating a PHP script that detects the MacOS X version of the client computer loading the URL and return the contents of the correct XML file that is needed.

The Software Update agent on MacOS X computers is basically just a web client that accesses the Software Update Service URL using standard HTTP protocols. If you look at the Software Update Service access logs, you can see the information that clients send to the server in the request headers. One of those pieces of information sent to the Software Update Service is the operating system version. So once you know this, you just need a PHP script that parses out the Software Update agent request header looking for the operating system version. Then the PHP script returns the correct XML file for the client operating system. Here is a sample of what a MacOS X 10.6 client computer’s software update agent header file looks like in the Max OS X 10.6 server access log file:

softwareupdate.mydomain.com 192.168.1.234 - - [02/Apr/2010:16:23:25 -0400] "GET /index-leopard-snowleopard.merged-1.sucatalog HTTP/1.1" 200 1238893 "-" "Software%20Update/254 CFNetwork/454.4 Darwin/10.0.0 (i386) (MacBook2%2C1)"

The operating system information from that log entry is:

Darwin/10.0.0

Here are the steps to set this up:

1. Enable the web service on the MacOS X 10.6 Software Update Server. You can leave the default website running on the default service port (TCP 80), but it would be better, security-wise, to change it to something else like TCP 8089.

2. Enable the PHP module in the website so that you can run PHP scripts.

3. Delete the default web service web content files in the directory /Library/WebServer/Documents/

4. Create the PHP file at this location and with the following contents /Library/WebServer/Documents/update.php (hopefully WordPress doesn’t mangle the code below):

<?php
$userAgent =  $_SERVER['HTTP_USER_AGENT'];
 
// MacOS X 10.6
$osSubstringSnowLeopard = 'Darwin/10.';
$fileSnowLeopard = "/var/db/swupd/html/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog";
 
// MacOS X 10.5
$osSubstringLeopard = 'Darwin/9.';
$fileLeopard = "/var/db/swupd/html/content/catalogs/others/index-leopard.merged-1.sucatalog";
 
// NonLeopard (10.4-)
$filePreLeopard = "/var/db/swupd/html/content/catalogs/index.sucatalog";
 
if( strrpos( $userAgent, $osSubstringSnowLeopard ) )
  $contents = file($fileSnowLeopard);
elseif ( strrpos( $userAgent, $osSubstringLeopard ) )
  $contents = file($fileLeopard);
else
  $contents = file($filePreLeopard);
 
$string = implode($contents);
echo $string;
?>

5. Configure the Software Update Server URL in your Open Directory preferences for your client computers to be:

http://softwareupdate.mydomain.com:8089/update.php

6. Done.

3 thoughts on “How To Allow MacOS X 10.4, 10.5, and 10.6 Client Computers To Update Against a MacOS X 10.6 Sofware Update Server Using a Single Common URL

  1. nice post! i’m using Apple’s apache mod_rewrite to achieve the same – any benefits of one over the other? maybe future os x updates could break the apache method…

    also (more important to me at the moment), do you know a way to serve software updates (the same application) to multiple clients at the same time? that is, for example, there are safari updates for 10.4, 10.5 and 10.6 – but only one can be chosen at a time. do i choose the 4.1.3 update for 10.4 clients, update them all, then go back and choose 5.0.3 for my 10.6 clients? there must be a way to serve up both safari updates at the same time to all clients… urg!

  2. I was looking for that article for a friend, but in reading it seems that the update for 10.6.7 server cleared the need to do this mod! This was very useful though!

Leave a Reply

Your email address will not be published. Required fields are marked *