Tag: 10.5

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

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.

Terminal Command for Xserve Intel Hardware RAID Card

To control the hardware RAID card in the terminal on Intel Xserves with a hardware RAID card, you need to use the terminal command “raidutil”. To see a list of command line options run the following command in a terminal window:

raidutil -h

Mac OS X Terminal

How to Enable Open Directory Debugging

By default the MacOS X Open Directory debugging log file is disabled. You can temporarily reenable it by running the following command in the Terminal app:

sudo killall -USR1 DirectoryService

After you reboot, debugging will be disabled again. If you want to enable Open Directory debugging so that it stays enabled across reboots, run the following command in the Terminal app:

touch /Library/Preferences/DirectoryService/.DSLogAtStart

To disable debugging again just delete that file:

sudo rm /Library/Preferences/DirectoryService/.DSLogAtStart

The debugging log file is located at:

/Library/Logs/DirectoryService/DirectoryService.debug.log

Leopard ByHost Plist Preference File Naming Convention Change

In Mac OS X 10.4 Tiger some system preferences were unique to a particular computer and so were named using a naming convention that included the MAC address of the first network device in the computer (en0). In Mac OS X 10.5 Leopard this naming convention was changed to use a different unique identifier other than the first network adapter’s MAC address. Leopard now uses something called the UUID for this unique identifier. You can determine a UUID of a Leopard computer by running the terminal command:

ioreg -rd1 -c IOPlatformExpertDevice | grep -E '(UUID)'

Terminal