[munki] push by gregnea...@mac.com - Better processing of requires and update_for items when names have ver... on 2012-02-29 21:42 GMT

170 views
Skip to first unread message

Greg Neagle

unread,
Feb 29, 2012, 5:02:23 PM2/29/12
to munk...@googlegroups.com
http://code.google.com/p/munki/source/detail?r=f97b63a9bf10

Some non-trivial changes to the updatecheck code in Munki today.

I've changed (or refined) behavior around what happens if a version number is included in sub-items of the requires and update_for keys. For example, consider this:

<key>update_for</key>
<array>
<string>Xcode-4.3</string>
</array>

Previously this would never have been applied. When processing "Xcode" for install, Munki only looked for "Xcode" in the update_for lists of other items, and would have never matched "Xcode-4.3".

When processing a managed_installs item like "Xcode", if the version to be installed is "9.0", Munki will look for updates for "Xcode" and "Xcode-9.0".

When managed_installs item like "Xcode-9.0", and Xcode-9.0 is already installed, Munki will look for updates for "Xcode-9.0". If a version later than 9.0 is installed, Munki will not look for updates. (You've specified a specific version, a later version is installed, so we leave it alone.)

Changes were made to the processRemoval() code to do the right thing with "Xcode-4.3" style specifiers in requires and update_for during removals as well.

These changes were triggered by the release of Xcode 4.3 (are you surprised?) 

I wanted to also install some of the "extras" when installing Xcode 4.3 -- the command line tools, the MobileDevice Framework, and PackageMaker.  All of these "updates" are specific to version 4.3 of Xcode and not applicable to version 4.2.1 or earlier.

I did not want an install of Xcode on Snow Leopard (currently 4.2.1 for Snow Leopard) to result in ether an erroneous install of the 4.3 extras or a lot of warnings about not finding a version of these extras that could be installed on 10.6.x.  And I wanted an uninstall of Xcode 4.3 to remove the "extra" packages (or "requires" would have sufficed).

Since this is a non-trivial change to the processing of "requires" and "update_for" items, if/when you start using this code, be on the lookout for unintended problems I might have caused with these changes.

-Greg

Childress, Matt

unread,
Feb 29, 2012, 8:05:39 PM2/29/12
to munk...@googlegroups.com

This may not be specifically munki-related, but I’d like to come up with a way to distribute and keep FCPX (Final Cut Pro X) up-to-date via Munki, and several of our video editors want to keep FCP7 on the machine.  I tried this earlier and munki saw FCP7 and updated it to FCPX as I had it in the managed updates (similar to the FireFox3 vs. FireFox methodology) 

 

Also we’ve got some copies of Apple Remote Desktop that are out there and currently one is purchased through the Apple store (and there’s no place to enter a serial number).  Apple’s concept of Enterprise App Store where end-users download and install when admins e-mail them app store codes doesn’t work in our (educational) environment – we need to be able to distribute apps to the desktop like with Munki. 

 

Have you solved this in your organization?  If so I’d appreciate an e-mail off-list so we don’t clog it up with potentially non-munki relevant chatter.

Thanks,
M@

 

Brandon Penglase

unread,
Mar 1, 2012, 9:20:24 AM3/1/12
to munk...@googlegroups.com, Childress, Matt

I think the approach we ended up taking is similar to how others might be doing it. Basically we started redeeming the codes for FCPX, Motion, and Compressor through one general ITS account. Then with one machine, log into that account, and either download it initially, or download the update. Once it’s downloaded, you would need to repackage it (without running it first, typically). Once you have your package made up, you can push it out with Munki.

Specifically with FCPX here, we decided to treat it the same as it was with FCPS, and give FCP X, Motion and Compressor to those who requested the upgrade (We ended up getting 3x redeem codes for each FCPS License we had for upgrade, one for each product). We then take those three apps, and put them in a “Final Cut Pro X” folder when packaging them up so the end users can keep Suite 3 and Pro X (and associates).

We then offered it as an Optional Install to the departments that requested the upgrade, and they have been able to upgrade when they wanted to, instead of having to wait for someone from ITS to come out and install it for them.

                As for Apple Remote, we have not purchased any new copied to do it this way, but I would most likely just do something similar to repackage and offer it, or at least repackage it for specific installs later.

 

                Thanks,

                                Brandon Penglase

                                Technical Support Analyst

                                Pennsylvania College of Technology

Greg Neagle

unread,
Mar 1, 2012, 9:25:15 AM3/1/12
to munk...@googlegroups.com, munk...@googlegroups.com, Childress, Matt
On Mar 1, 2012, at 6:20 AM, Brandon Penglase <bpen...@pct.edu> wrote:

I think the approach we ended up taking is similar to how others might be doing it. Basically we started redeeming the codes for FCPX, Motion, and Compressor through one general ITS account. Then with one machine, log into that account, and either download it initially, or download the update. Once it’s downloaded, you would need to repackage it (without running it first, typically)


Since App Store downloads are self-contained app bundles, you should be able to just munkiimport /Applications/Final\ Cut\ Pro.app (or whatever). No need to build a package.

. Once you have your package made up, you can push it out with Munki.

Specifically with FCPX here, we decided to treat it the same as it was with FCPS, and give FCP X, Motion and Compressor to those who requested the upgrade (We ended up getting 3x redeem codes for each FCPS License we had for upgrade, one for each product). We then take those three apps, and put them in a “Final Cut Pro X” folder when packaging them up


Oh. Still don't absolutely need to package, but this makes more sense. 

Brandon Penglase

unread,
Mar 1, 2012, 9:46:58 AM3/1/12
to munk...@googlegroups.com, Childress, Matt

This is true, I should have included that.

I also forgot to mention that I downloaded the ProAppQTCodecs, Motion Content, and FCP Content and included them in Munki, and specified them as an update_for the FCPX package I build, this way when FCPX is installed, it gets the content and plugins too.

 

                Thanks,

                                Brandon Penglase

                                Technical Support Analyst

                                Pennsylvania College of Technology

 

Rhon Fitzwater

unread,
Mar 1, 2012, 11:33:13 AM3/1/12
to munk...@googlegroups.com
You may want to look into a pre-flight script within munki that moves your existing installation of Final Cut Studio to its own folder (this is what will happen if you install through the App Store if it detects a previous installation).  Some more info can be found here: <http://support.apple.com/kb/HT4722?viewlocale=en_US&locale=en_US>.  I haven't wrote this script yet, or seen if it can be extracting from the Final Cut X app bundle, but I will be soon as we will be deploying Final Cut X this summer while still keeping Final Cut Studio around.

-Rhon

Heig Gregorian

unread,
Mar 8, 2012, 12:22:07 PM3/8/12
to munk...@googlegroups.com
Greg,

I'm having some difficulty implementing this, but I'm going to assume that I'm not understanding something.

Here's my understanding: If I have a a sub-package, which I'd like to include as an "update_for" another package (whose name is "MainPackage"), but want to ENSURE that it's only deployed for a specific version of the MainPackage, the particular "update_for" string in the sub-package would look like: "MainPackage-1.2.3"

Is this correct?

Thanks,
--Heig

Greg Neagle

unread,
Mar 8, 2012, 12:26:45 PM3/8/12
to munk...@googlegroups.com
Yes. That is the intention, at least.

This does limit the update to that SPECIFIC version, not that version as a "minimum" version.

-Greg

Heig Gregorian

unread,
Mar 8, 2012, 12:45:58 PM3/8/12
to munk...@googlegroups.com, munk...@googlegroups.com
Ok, then I'm feeling dumb, because I can't get it to work as I described!

Main Package name is: XcodeLion

It's in my main client manifest as a managed_install.

I have 2 versions "active" in the same catalog: 4.3 and 4.3.1.

I have a sub-package whose name is "MobileDevice"

It is in the same catalog as above, only 1 version.

Since it's the "MobileDevice.pkg" from Xcode 4.3.1 I only want it to be an update_for Xcode 4.3.1

Soooo...the update_for string in its array is: <string>XcodeLion-4.3.1</string>

(the version is from the version key of XcodeLion)

Totally not working and no sign of "MobileDevice" in verbose managedsoftwareupdate.

Thoughts?
--Heig

Greg Neagle

unread,
Mar 8, 2012, 12:56:20 PM3/8/12
to munk...@googlegroups.com
On Mar 8, 2012, at 9:45 AM, Heig Gregorian wrote:

Ok, then I'm feeling dumb, because I can't get it to work as I described!

Main Package name is: XcodeLion

It's in my main client manifest as a managed_install.

I have 2 versions "active" in the same catalog: 4.3 and 4.3.1.

I have a sub-package whose name is "MobileDevice"

It is in the same catalog as above, only 1 version.

Since it's the "MobileDevice.pkg" from Xcode 4.3.1 I only want it to be an update_for Xcode 4.3.1

Soooo...the update_for string in its array is: <string>XcodeLion-4.3.1</string>

What is the value for the version key in the pkginfo you are referring to as "XcodeLion-4.3.1"

When did Xcode 4.3.1 come out? I can't keep up....

(the version is from the version key of XcodeLion)

Totally not working and no sign of "MobileDevice" in verbose managedsoftwareupdate.

Thoughts?
--Heig


I only have Xcode 4.3, but this works for me:

Xcode:
<key>name</key>
<string>Xcode</string>
<key>version</key>
<string>4.3</string>

Command Line Tools for Xcode 4:
<key>name</key>
<string>Xcode_command_line_tools</string>
<key>update_for</key>
<array>
 <string>Xcode-4.3</string>
</array>
<key>version</key>
<string>4.2.0.9000000000.1.1249367152</string>

Xcode 4 Mobile Device Framework:
<key>name</key>
<string>Xcode_MobileDevice_Framework</string>
<key>update_for</key>
<array>
 <string>Xcode-4.3</string>
</array>
<key>version</key>
<string>5.0.0.9000000000.1.1206372128</string>

When installing Xcode 4.3, the Command Line Tools for Xcode 4 and the Xcode 4 Mobile Device Framework are also downloaded and installed.

...and one more thought occurs to me. Did you have Xcode 4.3 or earlier installed on this machine? If so, is the MobileDevice framework already installed and maybe the same version?

What does `pkgutil --pkg-info com.apple.pkg.MobileDevice` say?

Some of the receipts and versions have not changed from Xcode 4.2.1, and so may already be in place.

Heig Gregorian

unread,
Mar 8, 2012, 1:00:06 PM3/8/12
to munk...@googlegroups.com
On Mar 8, 2012, at 9:56 AM, Greg Neagle wrote:


On Mar 8, 2012, at 9:45 AM, Heig Gregorian wrote:

Ok, then I'm feeling dumb, because I can't get it to work as I described!

Main Package name is: XcodeLion

It's in my main client manifest as a managed_install.

I have 2 versions "active" in the same catalog: 4.3 and 4.3.1.

I have a sub-package whose name is "MobileDevice"

It is in the same catalog as above, only 1 version.

Since it's the "MobileDevice.pkg" from Xcode 4.3.1 I only want it to be an update_for Xcode 4.3.1

Soooo...the update_for string in its array is: <string>XcodeLion-4.3.1</string>

What is the value for the version key in the pkginfo you are referring to as "XcodeLion-4.3.1"


4.3.1

When did Xcode 4.3.1 come out? I can't keep up....

Yesterday along with all the other announcements :)

Along with updates to nearly all of the other "extra" packages...most are compatible with Xcode 4.3 as well (like Command Line Tools for Xcode)

Greg Neagle

unread,
Mar 8, 2012, 1:05:35 PM3/8/12
to munk...@googlegroups.com
There were more comments and questions in-line later on. I assume you are still working on the answers... :-)

-Greg

Heig Gregorian

unread,
Mar 8, 2012, 1:22:37 PM3/8/12
to munk...@googlegroups.com
Sorry, got too excited to reply!

Yes, Xcode 4.3 was installed previously.  I checked on another machine and the "MobileDevice" receipt HAS been incremented, so there should be no problem with that.  Nonetheless, a verbose output of managedsoftwareupdate should actually show that the sub package (MobileDevice) update is being considered and it does not.  Lopping off the version in the update_for string causes it to work, but that's not what I'm looking to do.

--Heig

Greg Neagle

unread,
Mar 8, 2012, 1:40:44 PM3/8/12
to munk...@googlegroups.com
I think I see the problem.

It's difficult to determine with 100% certainty what the currently installed version of something is if it has multiple installs items or receipts. I've run into this issue before. Munki considers an item installed if all of the receipts or installs items are present and the versions match those in the pkginfo or are higher.

I'm guessing Xcode 4.3.1 is installed on your test machine. So Munki thinks Xcode, version (4.3.1 or higher) is installed and doesn't look for version-specifc updates.

If you remove Xcode 4.3.1, does Munki behave as expected? That is, does it offer to install not only Xcode 4.3.1, but also the MobileDevice package?

-Greg

Heig Gregorian

unread,
Mar 8, 2012, 2:08:18 PM3/8/12
to munk...@googlegroups.com
Uggggh...

I setup another test to knock Xcode out of the equation (main package is AdobeReader and sub-package is just a test package).  I know I may not completely understand all the moving pieces but, in "lookForUpdates()" the list comprehension never "finds" itemname (AdobeReader) in the "catalogitem.get('updatefor', [])" array if the array element contains the version such as "AdobeReader-10.1.2"

I'm completely baffled by how this is working for you...

I appreciate your help though :)

--Heig

On Mar 8, 2012, at 10:05 AM, Greg Neagle wrote:

Greg Neagle

unread,
Mar 8, 2012, 2:24:58 PM3/8/12
to munk...@googlegroups.com
Heig, try the latest Git push:


It may or may not fix things, but it adds more detail to the verbose output. Here's a snippet during the processing of Xcode:

* Processing manifest item Xcode for install
    Looking for detail for: Xcode, version latest...
    Considering 1 items with name Xcode from catalog development
    Considering item Xcode, version 4.3 with minimum os version required 10.7.3
    Our OS version is 10.7.3
    Found Xcode, version 4.3 in catalog development
    Checking bundle /Applications/Xcode.app for version 4.3...
    Found Info.plist at /Applications/Xcode.app/Contents/Info.plist
    Xcode version 4.3 (or newer) is already installed.
    Looking for updates for Xcode
    Found these updates: []
    Looking for updates for Xcode-4.3
    Found these updates: [u'Xcode_command_line_tools', u'Xcode_MobileDevice_Framework']
    Looking for updates for Xcode--4.3
    Found these updates: []
    * Processing manifest item Xcode_command_line_tools for install
    Looking for detail for: Xcode_command_line_tools, version latest...
    Considering 1 items with name Xcode_command_line_tools from catalog development
    Considering item Xcode_command_line_tools, version 4.2.0.9000000000.1.1249367152 with minimum os version required 10.7.3
    Our OS version is 10.7.3
    Found Xcode_command_line_tools, version 4.2.0.9000000000.1.1249367152 in catalog development
    Checking bundle /System/Library/PrivateFrameworks/LLDB.framework for version 1.112...
    No Info.plist found at /System/Library/PrivateFrameworks/LLDB.framework/Contents/Info.plist
    Found Info.plist at /System/Library/PrivateFrameworks/LLDB.framework/Resources/Info.plist
    Checking bundle /usr/share/git-gui/lib/Git Gui.app for version 0.12.2...
    Found Info.plist at /usr/share/git-gui/lib/Git Gui.app/Contents/Info.plist
    Xcode_command_line_tools version 4.2.0.9000000000.1.1249367152 (or newer) is already installed.
    Looking for updates for Xcode_command_line_tools
    Found these updates: []
    Looking for updates for Xcode_command_line_tools-4.2.0.9000000000.1.1249367152
    Found these updates: []
    Looking for updates for Xcode_command_line_tools--4.2.0.9000000000.1.1249367152
    Found these updates: []
    * Processing manifest item Xcode_MobileDevice_Framework for install
    Looking for detail for: Xcode_MobileDevice_Framework, version latest...
    Considering 1 items with name Xcode_MobileDevice_Framework from catalog development
    Considering item Xcode_MobileDevice_Framework, version 5.0.0.9000000000.1.1206372128 with minimum os version required 10.4.0
    Our OS version is 10.7.3
    Found Xcode_MobileDevice_Framework, version 5.0.0.9000000000.1.1206372128 in catalog development
    Looking for package com.apple.pkg.MobileDevice, version 5.0.0.9000000000.1.1206372128
    Xcode_MobileDevice_Framework version 5.0.0.9000000000.1.1206372128 (or newer) is already installed.
    Looking for updates for Xcode_MobileDevice_Framework
    Found these updates: []
    Looking for updates for Xcode_MobileDevice_Framework-5.0.0.9000000000.1.1206372128
    Found these updates: []
    Looking for updates for Xcode_MobileDevice_Framework--5.0.0.9000000000.1.1206372128
    Found these updates: []

Heig Gregorian

unread,
Mar 8, 2012, 2:32:18 PM3/8/12
to munk...@googlegroups.com
Will do...

You were right btw:

When an update_for specifies a name-version and the name (the main package) is already installed, the sub-package containing the update_for string appears to be completely skipped regardless if it was installed or not.  HOWEVER, if the main package is removed (i.e. drag an application to the trash), the sub-package containing the name-version update_for schema is picked up!

This is different behavior to that of the traditional plain "name" in update_for as the sub-package will ALWAYS be evaluated for installation.

--Heig

Greg Neagle

unread,
Mar 8, 2012, 2:34:20 PM3/8/12
to munk...@googlegroups.com, munk...@googlegroups.com
Which I've attempted to address in the latest Git push. 

Sent from my iPhone

Heig Gregorian

unread,
Mar 8, 2012, 2:39:46 PM3/8/12
to munk...@googlegroups.com, munk...@googlegroups.com
Rockin'...I'll give it a shot and let you know how it works out for me.

Sent from my iPhone

Heig Gregorian

unread,
Mar 8, 2012, 3:25:27 PM3/8/12
to munk...@googlegroups.com
Greg,

Works great now, so thanks for the speedy response!

--Heig
Reply all
Reply to author
Forward
0 new messages