Video Screencast Help

Patch for Macintosh Clients Using Notification Server 6

Created: 23 Apr 2009 • Updated: 15 May 2009 | 9 comments
Language Translations
dougj's picture
+8 8 Votes
Login to vote

Utilizing built-in apple utilities and a good Perl script, it is possible to create Software Delivery for Macintosh packages and policies to automate the updating of Macintosh client computers. This  document will focus on setting up Patch for Macintosh in the Notification Server 6.x environment.

Overview

In order to automate the use of the attached Perl script to update Macintosh clients, the following steps must be taken:

  1. Create a package directory on the NS to be the ‘MacPatch’ package directory.
  2. Copy the Perl script into the newly-created package directory.
  3. Create a Software Delivery for Macintosh package.
  4. Create one or more command lines to be used with this package, depending on the desired options provided by the Perl script.
  5. Create one or more Software Delivery for Macintosh policies, depending on the desired options provided by the Perl script, collections to be used in the environment, scheduling requirements for various collections, etc.

Use of this Perl script in a Software Delivery setting requires knowledge of the updates that are available on a client macintosh computer. By default, Inventory Solution for Macintosh returns the results of the ‘softwareupdate –l’ command. The resulting data will be found in the Altiris database in the inv_mac_sw_available_updates table. It will only be as current as the most recent Inventory received for each client computer.

Prerequisite

This document assumes the following which may be considered prerequisites:

  1. A full inventory has run on client computer in a recent past in order to have a more current state of the inv_mac_sw_available_updates table, which holds the results of the Apple softwareupdate utility, explained later.

The Perl Script

The Perl script can be used as-is or it can be modified to suit the needs of any given environment. It is attached to this article and is provided ‘as-is’. Symantec provides no warranty as to the usability or accuracy of this script and it is incumbent on the user of this script to validate the usability of this script in a given environment.

As-is, this Perl script does the following:

  • Expects Perl to be found at: /usr/bin/perl. This is the default location on a Macintosh. If Perl is installed elsewhere, by chance, then the script will need to be updated.
  • It accepts a single command line parameter.
  • The following command lines are valid:

              ALL
              REQUIRED
              RESTARTONLY
              NONRESTARTONLY
             "packageName"

  • The following return code values can be returned by the Perl script:

             A return value of “0” indicates a successful run of the Perl script as well as the software installations. 
             A return value of “-10” indicates that a command line parameter was not specified. 
             A return value of “-15” indicates that an invalid command line parameter was specified. 
             A return value of “3010” indicates that a restart is required. This appears to be standard Apple numbering for indicating that a restart is required. 
             Any other non-zero return value indicates a problem was encountered during the actual installation of the Macintosh software update. This could be the value returned by the actual ‘softwareupdate’ command rather than something generated by the Perl script.

  • The script will run one of the following command lines:

             ALL – “softwareupdate -ia”
             REQUIRED – “softwareupdate -ir”
             RESTARTONLY – run “softwareupdate -l” and, for any that indicate a ‘restart’ is required, run ‘softwareupdate -i <name of update file>”. 
             NONRESTARTONLY - run “softwareupdate -l” and, for any that do NOT indicate a ‘restart’ is required, run ‘softwareupdate -i <name of update file>”.
             “PackageName” - run “softwareupdate -l” and parse through all available updates until the matching software package is found, then run ‘softwareupdate -i <name of update file>”. The package name listed as a command line parameter is found by running ‘softwareupdate -l’ from a terminal window. The actual package name is on the line beginning with an ‘*’, e.g., “AirPortUtility_Leopard_5.3.2”. It is NOT the name listed in the GUI Software Update utility or on the second line of ech entry found by the software update utility ran in a terminal window, e.g., “Airport Utility” or “Airport Utility (5.3.2), 10780K [recommended]”.

  • As-is, the Perl script will not automatically restart the system if a restart is required.

About Apple’s SoftwareUpdate Utility

Apple provides a system utility named ‘softwareupdate’. It is a standard Unix/Linux command and can be invoked from a command line. Of course, they also provide a nice Mac-like GUI interface for this utility. This document and Perl script will refer to the command line utility and will not reference the GUI interface to this command.

Following are screen shots of the GUI interface and corresponding command line output of ‘softwareupdate –l’.

imagebrowser image

imagebrowser image

The command allows for the following options:

  • -l, --list: list available updates
  • -d, --download: download updates
  • -i, --install: install updates – either a specific update (-i item <packagename>), all (-ia) or required updates (-ir).
  • --ignore: ignore specified updates. Package names are required.
  • --reset-ignored: clear the list of ignored updates
  • --schedule: schedule per-user installations. This is either ‘on’ or ‘off’.

This Perl script will only work with the list and install options.

The output of the softwareupdate utility is stored in the inv_mac_sw_available_updates table in the Altiris database, as shown below.

imagebrowser image

Note that any command line used in a policy that installs a specific update must match the value shown in the UpdateKey column. More about this later.

Create and Populate a ‘MacPatch’ package directory

On a Notification Server or in an appropriate, accessible share directory, create a directory that will contain the Perl script. It is recommended that the package directory be located within the NSCap directory, but this is not required. In this case, we will use: c:\mystuff\SWDPackages\MacPatch. Sharing has been enabled for this directory and all subdirectories.

Download and copy the Perl script into the new package directory.

Note that the entire contents of any package directory are downloaded to all package servers and to all client computers included in collections applied to Software Delivery policies. Don’t add anything you don’t want being downloaded to the client computers. In this case, the only thing in the package directory should be the attached Perl script.

imagebrowser image

Create a Software Delivery for Macintosh Package

To make use of the newly created package directory, a Software Delivery package must be created within the Notification Server environment. To do this:

      1. In the NS Console, browse to the Resources tab then expand Resources, Software Management and Software Delivery Packages.
      2. Right-click on ‘Macintosh’ and select ‘New’, then ‘Macintosh Package’.

imagebrowser image

      3. A new ‘Packages’ maintenance window will appear.
      4. On the ’Package’ tab, 
          a. Enter a name for the package, e.g., ‘MacPatch’ or ‘Patch for Mac’. Note: Only one single package is required but this package will have multiple command lines that can be ran from it.
          b. In the ‘Package source’ drop-down, select the appropriate option for your setup. In this case, it will be ‘Access package from a local directory on the NS…’. 
          c. Enter the path to, or browse to, the ‘MacPatch’ directory containing the Perl script.
          d. Click ‘Apply’.

imagebrowser image

Create One or More Command Lines for the Package

At this point, it must be determined which command line parameters will be used. A different command line is required for each command line parameter to be implemented in the environment. For example, there could be a command line to run All updates, Restart, NonRestart plus a separate command line for each individual software package available. If a new software package is made available by Apple via the softwareupdate utility, a new command line must be created here to install that package individually. You may revisit this screen often over the course of time.

To create a new Command Line:

  1. Click on the ‘Programs’ tab.
  2. 2. Click on the ‘New’ button toward the upper-right of the screen.
  3. Enter a name, e.g., ‘MacPatch – NONRESTARTONLY’.
  4. Enter a command line, e.g., “perl ./install.pl NONRESTARTONLY”.
  5. Click ‘Apply’.

imagebrowser image

To create a command line for an individual software package, use a command line such as:  
 
      “perl ./install.pl “AirPortUtility_Leopard-5.3.2”.

Remember, this is the actual file name that is downloaded, not the formal name of the software package listed in the GUI Sofware Update utility. The actual file name is listed in the command line utility on the line beginning with an asterisk (*). It is also found in the inv_mac_sw_available_updates table in the UpdateKey column.

imagebrowser image

Create one or more Software Delivery for Macintosh policies

Typically, a unique policy is created for each command line. This example will show how to create a policy for the ‘airport’ update listed above. 

  1. In the NS6 console, click on the Tasks tab and expand Software Management, Software Delivery, Macintosh.
  2. Right-click on ‘Software Delivery Tasks’ and select ‘New’, then ‘Macintosh Software Delivery Task’. A new window will appear.
  3. Enter a descriptive name for this policy.
  4. Select the correct Package in the “Package Name” section.
  5. Select the correct Program from the ‘Program Name” drop-down list.
  6. Select an appropriate collection for this policy. 
  7. Select an appropriate run method and schedule, as needed. 
  8. Enter other options as needed.
  9. Check the ‘Enable’ check box. 
  10. Click ‘Apply’.

A Note on Collections: It is recommended that dynamic collections be made for each policy, especially those that install specific updates. (In this case, a collection includes a single demo Macintosh client.)

imagebrowser image

At this point, clients should update configuration and run the policy.

It may be possible to check the evt_aex_swd_execution table to verify the status of the policy execution on the client.

It is also recommended that another Inventory be ran on the client machines to get the most recent status of available updates.

Comments 9 CommentsJump to latest comment

jpellet2's picture

 So far this looks promising. I am having difficulty with a few of the options though. The All works fine it appears but the nonrestartonly and the restart only don't seem to function. Perl just hangs out and pegs the processor but softwareupdate never launches. My clients are almost completely 10.5 so that could be the issue. I know that perl is located in /usr/bin/perl and not /usr/loca/bin/perl so I changed that in the script. Any ideas?

0
Login to vote
jpellet2's picture

 I've been taking a harder look at this and it seems that the command-line options are working with the exception of the nonrestartonly. The array count doesn't increment itself correctly like it does with the restartonly option. It stays at 0 so the loop becomes infinite but I can't seem to find anything wrong with the statement directly. 

0
Login to vote
jpellet2's picture

 OK. I think I've got it working now. First change was to the first line to reflect the location of perl on Leopard to /usr/bin/perl.
The second change, which may not be the preferred method since my perl is quite rusty, but in the nonrestartonly clause, I added a $count++; to ensure that the count was incrementing. It now looks something like this:

for ($count = 0; $count < $arraySize; $count++)
{

$count++;

if($softwareUpdates[$count] !~ m/\[restart\]$/)
{

Again, it seems to be working for now. There may be a side effect but I haven't seen one yet.

 
0
Login to vote
dougj's picture

I think I know why it is not incrementing. It is due to the following statement in that 'for' loop, which causes $count to decrement. This line is necessary to get the correct $updateName. If $count is incremented again at the beginning of the 'for' loop, the correct updatename may not be returned.

     if($softwareUpdates[--$count] =~ m/\*/)

I will update the perl script and have it reattached.

Thanks for the heads-up!

0
Login to vote
dougj's picture

 .

0
Login to vote
williamske's picture

All works well for me, but I get an error code of -194 after installing an update (for example 10.5.7). It does install OK but I do not get 3010.

Are you sure that 3010 is also used by Apple as a restart required code, or am I doing somehting wrong.

Kev

0
Login to vote
KSchroeder's picture

How Microsoft-y of Apple to use Windows Installer's 3010 code instead of something obtuse like -12323453 ... :)

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

0
Login to vote
dougj's picture

Apple must have used it first. Microsoft couldn't have thought of it on their own. :) 

0
Login to vote
Andrew Bosch's picture

The 3010 return code is hardcoded in the script.  It is NOT a return code from the 'softwareupdate' command line utility.  It is simply returned when an update has been installed that requires a restart.  In other words, it's a manufactured return code...:) 

------------------------------------
Sr. Principal SQA Engineer
Symantec

0
Login to vote