Managing Apple updates (unattended, forced, etc.)

[Heig Gregorian]

Greetings munki users!

For those of you who have wanted to manage Apple-provided updates without having to import them into your munki repo, this change is definitely for you!

Supported keys/behaviors.

Here's a list of keys you can apply/manipulate by creating an "apple_update_metadata" pkginfo in your munki repo:

blocking_applications

description

display_name

force_install_after_date

unattended_install

RestartAction

Applying Apple Update Metadata keys in your organization:

Both 'makepkginfo' and 'munkiimport' are aware of the new option '--apple-update' which is intended to accept an Apple update 'productKey'.  Let's use the recent iTunes 11.0.2 update as an example:

$ ./makepkginfo --apple-update zzzz041-9597

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>catalogs</key>

<array>

<string>testing</string>

</array>

<key>installer_type</key>

<string>apple_update_metadata</string>

<key>name</key>

<string>zzzz041-9597</string>

<key>version</key>

<string>1.0</string>

</dict>

</plist>

Note: Other options referring to additional keys such as '--unattended_install' can be used, however no other keys other than the ones listed at the top of this posting will be honored.

Naturally, as with any pkginfo, additional changes can be made after the fact in order to alter the effect.

Some guidelines:

The admin must supply a specific Apple update product key for '--apple-update'.  For example, the above example referencing zzzz051-9597 specifically refers to the iTunes 11.0.2 update.

This new installer_type named 'apple_update_metadata' is applied to any applicable Apple update(s) matching the product key for a client thereby allowing an admin to apply familiar pkginfo keys such as 'unattended_install', 'force_install_after_date', etc.

Pkginfo files of the 'apple_update_metadata' installer_type can be included in any catalog included in the primary client manifest and will be applied on any client which has applicable Apple updates.

Just as with munki packages, an Apple update which is specified as an unattended_install will be ignored if it also contains a restart action ('RestartAction') or if there is a blocking application ('blocking_applications') currently running.

A restart action specified in metadata must be the same or greater (a logout is greater than none; a restart is greater than logout, etc.) than the Apple update's specified restart action (provided by Apple) or else it will not be applied.

Blocking applications specified replace Apple-provided blocking applications...be careful!

-------------------

Documentation on the munki wiki to follow shortly.

Judging by the number of requests I've seen in the forums, this should be pretty popular!  Bug reports and feature requests welcome!

--Heig

[Heig Gregorian]

And before anyone asks the following:

Why doesn't the pkginfo contain "nice" Apple update names (display_name = iTunes)?

Do I have to manually find an Apple update's product key in order to use this feature? (the answer is yes)

Can I use an Apple update's name with the new '--apple-update' option instead of some weird 'productKey' in order to generate a proper pkginfo (the answer is no)

Solutions for all of the above are being investigated, I assure you!  However, in the end, the overall described functionality probably won't change.

--Heig

[Gregory Neagle]

On Feb 19, 2013, at 6:56 PM, Heig Gregorian <the...@gmail.com> wrote:

And before anyone asks the following:

Why doesn't the pkginfo contain "nice" Apple update names (display_name = iTunes)?

Do I have to manually find an Apple update's product key in order to use this feature? (the answer is yes)

Can I use an Apple update's name with the new '--apple-update' option instead of some weird 'productKey' in order to generate a proper pkginfo (the answer is no)

Apple updates are uniquely identified by productKey. So ultimately that is what Munki must use to map an apple_update_metadata item to an Apple update.

Anything that allows you to search for updates based on human-meaningful names will still ultimately use the productKey.

If you run a reposado server, finding the productKey for a given update should be trivial, so don't let this slow down testing and feedback.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Gregory Neagle]

Testing this code is easier if you have a way to repeatedly cause an Apple update to be available.

I use iTunes. The dist file in the iTunes 11.0.2 update checks the file /System/Library/PrivateFrameworks/iTunesAccess.framework/Versions/A/Resources/version.plist for version info.

If change the CFBundleShortVersionString in that file to "11.0", Apple Software Update offers to install iTunes 11.0.2 (or 11.0.1 if that's what's currently available in your current repo).

You should be able to use this or similar techniques to test the new Munki code.

-Greg

[Rob Middleton]

Heig,

Could you quickly list out which functions have changed? Git just has a raft of partial changes in there at the moment from multiple people, hard to review the right bits.

Cheers,

Rob.

[Heig Gregorian]

Rob,

That's kind of a broad request...

It's not just a few functions that have changed, but some have been relocated, and some are new...

Here's the clone's branch that I worked on for this feature:

http://code.google.com/r/theheig-conditionals/source/list?name=apple-update-metadata

This is the commit where I started work:

d92127c24189

I merged from master once (early on) here, in this commit:

e25b5aacf777

Every commit thereafter is purely in support of this feature.

--Heig

[Gregory Neagle]

+1 to just browsing Heig's clone: http://code.google.com/r/theheig-conditionals/source/browse/?name=apple-update-metadata

I've been reviewing Heig's changes over the last week, but certainly welcome another set of eyes on them.

-Greg

[Rob Middleton]

Great - thanks. I don't like to deploy without reading through any code changes that alter logical flow :). Will feedback if any logic doesn't appear solid.

I'll note on "Blocking Applications" that actually over-riding these may often be a good idea .. actually ideally, not fully override, but add additional constraints (different syntax would be required to over-ride vs add).

In recent times I think the dist file may have changed a little (or there are multiple formats) such that we cannot reliably read the blocking application list.

I've noticed Safari updates installing without munki requesting that Safari be closed. However, a system popup then occurs during the install requesting Safari be closed. That may be a bug we can fix, or it may end up being a good use of overrides where magic detection cannot work.

Cheers,

Rob.

[Gregory Neagle]

Right now blocking_applications in an apple_update_metadata item replaces any blocking applications derived from the Distribution file. I can't think of any scenario where this would not be sufficient to get the desired behavior.

-Greg

[Heig Gregorian]

On Feb 19, 2013, at 10:09 PM, Gregory Neagle <gregn...@mac.com> wrote:

Right now blocking_applications in an apple_update_metadata item replaces any blocking applications derived from the Distribution file. I can't think of any scenario where this would not be sufficient to get the desired behavior.

-Greg

On Feb 19, 2013, at 10:06 PM, Rob Middleton <rrmid...@gmail.com> wrote:

Great - thanks. I don't like to deploy without reading through any code changes that alter logical flow :). Will feedback if any logic doesn't appear solid.

I'll note on "Blocking Applications" that actually over-riding these may often be a good idea .. actually ideally, not fully override, but add additional constraints (different syntax would be required to over-ride vs add).

In recent times I think the dist file may have changed a little (or there are multiple formats) such that we cannot reliably read the blocking application list.

I've noticed Safari updates installing without munki requesting that Safari be closed. However, a system popup then occurs during the install requesting Safari be closed. That may be a bug we can fix, or it may end up being a good use of overrides where magic detection cannot work.

There was a bug in detecting running applications for Apple updates which stemmed from previous changes to 'appleupdates.GetBlockingApps'.  This function was returning full paths which were never being matched against the process list.  Consequentially, as a result of testing, a full exact path name may be specified as blocking application and 'appleupdates.GetBlockingApps' now returns paths which exclude their dirnames: ie "/Applications/Xcode.app/Contents/MacOS/Xcode" becomes "Xcode.app/Contents/MacOS/Xcode" (note the missing, prefixed "/").

--Heig

[Rob Middleton]

On 20/02/2013, at 5:27 PM, Heig Gregorian wrote:

On Feb 19, 2013, at 10:09 PM, Gregory Neagle <gregn...@mac.com> wrote:

Right now blocking_applications in an apple_update_metadata item replaces any blocking applications derived from the Distribution file. I can't think of any scenario where this would not be sufficient to get the desired behavior.

-Greg

On Feb 19, 2013, at 10:06 PM, Rob Middleton <rrmid...@gmail.com> wrote:

Great - thanks. I don't like to deploy without reading through any code changes that alter logical flow :). Will feedback if any logic doesn't appear solid.

I'll note on "Blocking Applications" that actually over-riding these may often be a good idea .. actually ideally, not fully override, but add additional constraints (different syntax would be required to over-ride vs add).

In recent times I think the dist file may have changed a little (or there are multiple formats) such that we cannot reliably read the blocking application list.

I've noticed Safari updates installing without munki requesting that Safari be closed. However, a system popup then occurs during the install requesting Safari be closed. That may be a bug we can fix, or it may end up being a good use of overrides where magic detection cannot work.

There was a bug in detecting running applications for Apple updates which stemmed from previous changes to 'appleupdates.GetBlockingApps'.  This function was returning full paths which were never being matched against the process list.  Consequentially, as a result of testing, a full exact path name may be specified as blocking application and 'appleupdates.GetBlockingApps' now returns paths which exclude their dirnames: ie "/Applications/Xcode.app/Contents/MacOS/Xcode" becomes "Xcode.app/Contents/MacOS/Xcode" (note the missing, prefixed "/").

--Heig

Great - thanks.

Less necessary to have a way of merging the two lists of blocking_apps in that case.

I'd noticed the bug but not been able to spend time on it. I'd guessed we were not always successfully reading the "must-close" parameter from the .dist files. Appears I was looking for the problem in the wrong place!

Rob.

[Gregory Neagle]

I haven't seen a lot of feedback or testing except for an issue Nate W reported.

This new functionality, together with Apple Updates and Munki updates in the same session is a big deal, and a not-insignificant change to Munki.

It's quite likely that there are edge cases where certain features don't mess together cleanly. We need more people testing this to find those edge-cases.

Please do some testing and provide feedback!

-Greg

[Joe Wollard]

I've not tested the finge cases yet, but I can say that in bootstrap mode, nothing is broken. In manual run (click the icon after login) everything works as advertised.

I've not yet attempted to manage apple updates in a manifest, but that's next on the agenda.

So far so good.

--

Joe Wollard

[Heig Gregorian]

Sent from my iPhone

On Feb 25, 2013, at 12:18 PM, Joe Wollard <joe.w...@gmail.com> wrote:

I've not tested the finge cases yet, but I can say that in bootstrap mode, nothing is broken. In manual run (click the icon after login) everything works as advertised.

I've not yet attempted to manage apple updates in a manifest, but that's next on the agenda.

I'm sure you'd figure this out when you implement, but there's no manifest entry for Apple update metadata.  When a client determines it has applicable Apple updates, the catalogs in the primary manifest are sourced for metadata which correspond to an update's productKey.

[Nate Walck]

So long as the apple update is in a given catalog, it will find the keys I've specified? Where would the pkginfo itself go then?  Just make an arbitrary folder and place it there?

Nate

[Heig Gregorian]

Sent from my iPhone

On Feb 25, 2013, at 1:03 PM, Nate Walck <nate....@gmail.com> wrote:

So long as the apple update is in a given catalog, it will find the keys I've specified? Where would the pkginfo itself go then?  Just make an arbitrary folder and place it there?

Apple updates aren't part of any catalog.  Metadata for Apple updates are in any catalog(s) of your choosing as defined by their 'catalogs' array as is with any pkginfo.  As such, regardless of the folder your pkginfo is in, makecatalogs scans them all, creating respective catalogs in the repo's 'catalogs' directory.  An Apple update metadata pkginfo that specifies foo, bar, baz as catalogs will be included in catalogs foo, bar, baz.

Does this make sense now?  I'd like to make some changes to the documentation so that this is clearer and with feedback from questions like this, I can tailor them better...

--Heig

[Nate Walck]

Ah yes, I meant Apple Update Metadata, not the update itself.  This method makes complete sense, I just wasn't sure about the details.

Nate

[Nate Walck]

I'm on build 1750 and I noticed the following:

1.  I open MSU.app and it shows that Java is available

2.  I click Optional Installs

3.  I select a few items and add them to the install list

4.  When the list of things to install comes back, Java is missing and only the optional items are present

I am not sure if this is by design or not, but I thought I would mention it.

Nate

[Gregory Neagle]

What were the optional items you added? If Munki thinks any of them are from Apple, you will see the behavior you've described.

(None of which has anything to do with apple_update_metadata items)

-Greg

[Nate Walck]

They were iOS Simulators.  5.0, 5.1 and 6.0.  Not normally available as an Apple update (I grabbed them via wireshark capture).

Nate

[Gregory Neagle]

So this is expected behavior, then.

-Greg

[Erik]

Shouldn't we specify a path for the pkginfo? I'm not really sure what the benefit is of giving them the option on where to store it.

It seems like it could get messy for someone just starting out.

[Gregory Neagle]

This is up to the admin. Like "normal" things imported into Munki, the organization is up to you. Munki does not care.

(And when the data is stored in a database, as it is with munkiserver and Simian, the path is not relevant anyway)

-Greg

On Feb 25, 2013, at 1:56 PM, Erik <eriknico...@gmail.com> wrote:

Shouldn't we specify a path for the pkginfo? I'm not really sure what the benefit is of giving them the option on where to store it.

It seems like it could get messy for someone just starting out.

[Justin McWilliams]

On Mon, Feb 25, 2013 at 4:27 PM, Heig Gregorian <the...@gmail.com> wrote:
>
>
> Sent from my iPhone
>
>

> On Feb 25, 2013, at 1:03 PM, Nate Walck <nate....@gmail.com> wrote:
>
> So long as the apple update is in a given catalog, it will find the keys
> I've specified? Where would the pkginfo itself go then? Just make an
> arbitrary folder and place it there?
>
>
> Apple updates aren't part of any catalog. Metadata for Apple updates are in
> any catalog(s) of your choosing as defined by their 'catalogs' array as is
> with any pkginfo. As such, regardless of the folder your pkginfo is in,
> makecatalogs scans them all, creating respective catalogs in the repo's
> 'catalogs' directory. An Apple update metadata pkginfo that specifies foo,
> bar, baz as catalogs will be included in catalogs foo, bar, baz.

I haven't dug into the code yet, but why combine Munki and Apple
package metadata into the same catalog(s)? I don't see any benefit
other than development ease, and it makes an already large catalog
much larger and cluttered with two different types of metadata. Why
not have separate Apple Update metadata catalogs, given that they
contain different data and are used differently in the codebase as
well?

In my organization, we'll likely make 90%+ of Apple updates
unattended_install=True, which will substantially grow our catalogs.

[Nate Walck]

The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.

Nate

[Gregory Neagle]

On Feb 25, 2013, at 2:07 PM, Justin McWilliams <og...@google.com> wrote:

> On Mon, Feb 25, 2013 at 4:27 PM, Heig Gregorian <the...@gmail.com> wrote:
>>
>>
>> Sent from my iPhone
>>
>>
>> On Feb 25, 2013, at 1:03 PM, Nate Walck <nate....@gmail.com> wrote:
>>
>> So long as the apple update is in a given catalog, it will find the keys
>> I've specified? Where would the pkginfo itself go then? Just make an
>> arbitrary folder and place it there?
>>
>>
>> Apple updates aren't part of any catalog. Metadata for Apple updates are in
>> any catalog(s) of your choosing as defined by their 'catalogs' array as is
>> with any pkginfo. As such, regardless of the folder your pkginfo is in,
>> makecatalogs scans them all, creating respective catalogs in the repo's
>> 'catalogs' directory. An Apple update metadata pkginfo that specifies foo,
>> bar, baz as catalogs will be included in catalogs foo, bar, baz.
>
> I haven't dug into the code yet, but why combine Munki and Apple
> package metadata into the same catalog(s)?

To allow the same development, testing, production workflow as with "normal" Munki items.

You don't _have_ to put them in the same catalogs, but you can.

If you want to put them only in an "apple_updates_metadata" catalog, you can do that.

Or, you could have a "apple_updates_permissive" catalog where the metadata only specified unattended_installs,
and a "apple_updates_draconian" where the metadata specified "force_install_after_date"

> I don't see any benefit
> other than development ease, and it makes an already large catalog
> much larger and cluttered with two different types of metadata.

If that's a concern, don't combine your catalogs then. I won't force you.

> Why
> not have separate Apple Update metadata catalogs,

You can if you want.

[Justin McWilliams]

On Mon, Feb 25, 2013 at 5:09 PM, Nate Walck <nate....@gmail.com> wrote:
> The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.

Yes. But it's still going to grow my catalog size by 2-3x in terms of
raw numbers of items. And catalogs are simply lists of pkginfos,
which Munki iterates over and evaluates 1 by 1. If they were separate
catalogs, and a new metacatalog was formed as a dictionary, O(1)
lookups could be made for better efficiency, and standard Munki
updatecheck cycles would not needlessly loop over the Apple updates.

[Gregory Neagle]

On Feb 25, 2013, at 2:13 PM, Justin McWilliams <og...@google.com> wrote:

> On Mon, Feb 25, 2013 at 5:09 PM, Nate Walck <nate....@gmail.com> wrote:
>> The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.
>
> Yes. But it's still going to grow my catalog size by 2-3x in terms of
> raw numbers of items. And catalogs are simply lists of pkginfos,
> which Munki iterates over and evaluates 1 by 1. If they were separate
> catalogs, and a new metacatalog was formed as a dictionary, O(1)
> lookups could be made for better efficiency, and standard Munki
> updatecheck cycles would not needlessly loop over the Apple updates.

So put them in separate catalogs! You have that capability.

-Greg

[Justin McWilliams]

On Mon, Feb 25, 2013 at 5:15 PM, Gregory Neagle <gregn...@mac.com> wrote:
>
> On Feb 25, 2013, at 2:13 PM, Justin McWilliams <og...@google.com> wrote:
>
>> On Mon, Feb 25, 2013 at 5:09 PM, Nate Walck <nate....@gmail.com> wrote:
>>> The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.
>>
>> Yes. But it's still going to grow my catalog size by 2-3x in terms of
>> raw numbers of items. And catalogs are simply lists of pkginfos,
>> which Munki iterates over and evaluates 1 by 1. If they were separate
>> catalogs, and a new metacatalog was formed as a dictionary, O(1)
>> lookups could be made for better efficiency, and standard Munki
>> updatecheck cycles would not needlessly loop over the Apple updates.
>
> So put them in separate catalogs! You have that capability.

Again I haven't fully read the code, so correct me if I'm wrong (doc?
link to source?), but it seems required to place all desired catalogs
in a client manifest. So, Munki's normal updatecheck will still
iterate over all items in any Apple-only catalog(s) an admin creates,
even if you spend the time to separate them.

[Gregory Neagle]

On Feb 25, 2013, at 2:18 PM, Justin McWilliams <og...@google.com> wrote:

> On Mon, Feb 25, 2013 at 5:15 PM, Gregory Neagle <gregn...@mac.com> wrote:
>>
>> On Feb 25, 2013, at 2:13 PM, Justin McWilliams <og...@google.com> wrote:
>>
>>> On Mon, Feb 25, 2013 at 5:09 PM, Nate Walck <nate....@gmail.com> wrote:
>>>> The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.
>>>
>>> Yes. But it's still going to grow my catalog size by 2-3x in terms of
>>> raw numbers of items. And catalogs are simply lists of pkginfos,
>>> which Munki iterates over and evaluates 1 by 1. If they were separate
>>> catalogs, and a new metacatalog was formed as a dictionary, O(1)
>>> lookups could be made for better efficiency, and standard Munki
>>> updatecheck cycles would not needlessly loop over the Apple updates.
>>
>> So put them in separate catalogs! You have that capability.
>
> Again I haven't fully read the code, so correct me if I'm wrong (doc?
> link to source?), but it seems required to place all desired catalogs
> in a client manifest. So, Munki's normal updatecheck will still
> iterate over all items in any Apple-only catalog(s) an admin creates,
> even if you spend the time to separate them.

As long as those catalogs are in the primary manifest, yes.

Not sure what your concern is here.
If we add data, and tell Munki to use it, it will take more space and time, yes.

-Greg

[Justin McWilliams]

On Mon, Feb 25, 2013 at 5:20 PM, Gregory Neagle <gregn...@mac.com> wrote:
>
> On Feb 25, 2013, at 2:18 PM, Justin McWilliams <og...@google.com> wrote:
>
>> On Mon, Feb 25, 2013 at 5:15 PM, Gregory Neagle <gregn...@mac.com> wrote:
>>>
>>> On Feb 25, 2013, at 2:13 PM, Justin McWilliams <og...@google.com> wrote:
>>>
>>>> On Mon, Feb 25, 2013 at 5:09 PM, Nate Walck <nate....@gmail.com> wrote:
>>>>> The metadata is very lightweight. It isn't *all* the metadata for the Apple Updates like reposed stores, only the bits that are important to the admin.
>>>>
>>>> Yes. But it's still going to grow my catalog size by 2-3x in terms of
>>>> raw numbers of items. And catalogs are simply lists of pkginfos,
>>>> which Munki iterates over and evaluates 1 by 1. If they were separate
>>>> catalogs, and a new metacatalog was formed as a dictionary, O(1)
>>>> lookups could be made for better efficiency, and standard Munki
>>>> updatecheck cycles would not needlessly loop over the Apple updates.
>>>
>>> So put them in separate catalogs! You have that capability.
>>
>> Again I haven't fully read the code, so correct me if I'm wrong (doc?
>> link to source?), but it seems required to place all desired catalogs
>> in a client manifest. So, Munki's normal updatecheck will still
>> iterate over all items in any Apple-only catalog(s) an admin creates,
>> even if you spend the time to separate them.
>
> As long as those catalogs are in the primary manifest, yes.
>
> Not sure what your concern is here.
> If we add data, and tell Munki to use it, it will take more space and time, yes.

My concern is the Apple-only pkginfo items are adding time when
processing regular Munki updates *and* Apple updates. That is,
Apple-only pkginfo items are processed twice, when they're only needed
in one place. This is probably still on the order of a few seconds at
absolute max, but this sort of inefficiency adds up over the code
base.

I won't have time to investigate this further in the next few days,
but I'll look closer and provide some profiling data when I can.

[Gregory Neagle]

I'd have to be convinced this is a big deal to further complicate things for Munki admins by defining an entire new class of "catalog" like objects specifically for Apple Update metadata.

-Greg

[Justin McWilliams]

On Mon, Feb 25, 2013 at 5:32 PM, Gregory Neagle <gregn...@mac.com> wrote:
> I'd have to be convinced this is a big deal to further complicate things for Munki admins by defining an entire new class of "catalog" like objects specifically for Apple Update metadata.

Interesting, as that's the design we originally agreed upon a year and
a half ago when discussing this feature. But the sentiment is noted,
and I'll refrain from further critique until I am able to take a
closer look.

[Gregory Neagle]

On Feb 25, 2013, at 2:43 PM, Justin McWilliams <og...@google.com> wrote:

> On Mon, Feb 25, 2013 at 5:32 PM, Gregory Neagle <gregn...@mac.com> wrote:
>> I'd have to be convinced this is a big deal to further complicate things for Munki admins by defining an entire new class of "catalog" like objects specifically for Apple Update metadata.
>
> Interesting, as that's the design we originally agreed upon a year and
> a half ago when discussing this feature.

That's a long time ago. Heig and I had further discussions when he started working on the implementation.

I think the chosen implementation allows more flexibility and control (and enables more admin control) than putting all Apple updates into a hard-coded catalog.

If we can address your concerns without overly complicating things for the Munki admin, that would be good.

-Greg

[Rob Middleton]

On 26/02/2013, at 9:47 AM, Gregory Neagle wrote:

>
> On Feb 25, 2013, at 2:43 PM, Justin McWilliams <og...@google.com> wrote:
>
>> On Mon, Feb 25, 2013 at 5:32 PM, Gregory Neagle <gregn...@mac.com> wrote:
>>> I'd have to be convinced this is a big deal to further complicate things for Munki admins by defining an entire new class of "catalog" like objects specifically for Apple Update metadata.
>>
>> Interesting, as that's the design we originally agreed upon a year and
>> a half ago when discussing this feature.
>
> That's a long time ago. Heig and I had further discussions when he started working on the implementation.
>
> I think the chosen implementation allows more flexibility and control (and enables more admin control) than putting all Apple updates into a hard-coded catalog.
>
> If we can address your concerns without overly complicating things for the Munki admin, that would be good.
>
> -Greg

I think it makes plenty of sense to have this controlled by the primary manifest, but it does not to me follow that they should be in the same catalog.

Manifest (per client / category / whatever) --
<key>catalogs</key>
… production ...
<key>apple_update_meta</key>
… apple_meta_production ...
<key>included_manifests / managed_installs / etc


That said -- I'm not hugely fussed by the compute time -- while some of the iterative walking we do is expensive, none of the options you can add to an apple update would cause munki to waste time (eg: installs / receipts).

And for splitting management, as Greg says, we can put this in a manifest:
<key>catalogs</key>
<array>
<string>production</string>
<string>apple_meta_production</string>
</array>

I still think it would be nice to have the future flexibility to point the "apple_update_meta" catalog to a server other than the munki one (ie: a fully qualified http/https address). That's because I don't see this meta info clearly sitting on either the munki side or apple-update-release side. It should be a valid choice to manage this meta info from the server someone might use to manage the apple updates.

The overall design works for me either way.

Rob.

[Gregory Neagle]

On Feb 25, 2013, at 6:57 PM, Rob Middleton <rrmid...@gmail.com> wrote:

I think it makes plenty of sense to have this controlled by the primary manifest, but it does not to me follow that they should be in the same catalog.

It's info about a installer item - it's pkginfo. I don't know that it follows they should go in separate catalogs, especially to a new Munki admin.

Manifest (per client / category / whatever) --
<key>catalogs</key>
… production ...
<key>apple_update_meta</key>
… apple_meta_production ...
<key>included_manifests / managed_installs / etc


That said -- I'm not hugely fussed by the compute time -- while some of the iterative walking we do is expensive,

A catalog is walked once to build a dictionary that allows us to quickly access data within. The time to access items after the initial processing of the catalog is small.

none of the options you can add to an apple update would cause munki to waste time (eg: installs / receipts).

And for splitting management, as Greg says, we can put this in a manifest:
<key>catalogs</key>
<array>
 <string>production</string>
 <string>apple_meta_production</string>
</array>

I still think it would be nice to have the future flexibility to point the "apple_update_meta" catalog to a server other than the munki one

Gosh, I see almost no benefit to providing that level of complexity. We're telling Munki what to do; they data to do so really should all come from one source.

(ie: a fully qualified http/https address). That's because I don't see this meta info clearly sitting on either the munki side or apple-update-release side.

I do. It's Munki data.

It should be a valid choice to manage this meta info from the server someone might use to manage the apple updates.

Nothing other than Munki would ever use this extra data.

(And my Munki server and my Reposado server are the same box anyway!)

The overall design works for me either way.

I'm glad. This idea has been on the to-do list for 20 months. Kudos to Heig for actually getting working code out there.

Rob.

[Justin McWilliams]

Consider a world where an admin used Munki and Reposado, but decided
to host Munki and Reposado on separate boxes, possibly even _had_ to
for valid technical reasons. This is the case Rob was mentioning,
where an admin may wish to centralize Apple Update metadata with the
actual updates themselves, not on his/her Munki box, for ease of
management purposes ;)

>
> The overall design works for me either way.
>
>
> I'm glad. This idea has been on the to-do list for 20 months. Kudos to Heig
> for actually getting working code out there.
>
>
> Rob.
>
>

[Gregory Neagle]

Munki and Reposado share no data.

I mentioned that I run them on the same box, but that really has no bearing.

Again: this is _Munki_ information that happens to apply to Apple updates. There's no reason to put it on a Reposado/Apple Software Update/NetSUS server, and no way to put it on Apple's servers.

There is a cost (at least to me) to allowing infinite customization.

-Greg

[Justin McWilliams]

On Mon, Feb 25, 2013 at 10:53 PM, Gregory Neagle <gregn...@mac.com> wrote:
> Munki and Reposado share no data.
>
> I mentioned that I run them on the same box, but that really has no bearing.
>
> Again: this is _Munki_ information that happens to apply to Apple updates.
> There's no reason to put it on a Reposado/Apple Software Update/NetSUS
> server, and no way to put it on Apple's servers.

Hrmm... no reason? 1) to centralize management of Apple updates in
one place, instead of two, and 2) someone could even wrap Reposado in
a new CLI for managing it along with the Munki metacatalog together.

FYI, we'll be extending Simian's Apple Update admin UI to allow for
such centralized management, so I personally don't need to point at
another server. I simply acknowledge the reason someone would
potentially want do to that.

> There is a cost (at least to me) to allowing infinite customization.

Agreed. Infinite customization is bad for everyone. But we also
shouldn't design things in a way which makes future customization very
difficult. Having no distinction between the catalog types (both in
the manifest's <key>catalogs</key>) makes it impossible to fetch from
CatalogURL vs a potential future AppleMetaCatalogURL, should demand
arise.

> -Greg
>
> On Feb 25, 2013, at 7:44 PM, Justin McWilliams <og...@google.com> wrote:
>
> Nothing other than Munki would ever use this extra data.
>
> (And my Munki server and my Reposado server are the same box anyway!)
>
>
> Consider a world where an admin used Munki and Reposado, but decided
> to host Munki and Reposado on separate boxes, possibly even _had_ to
> for valid technical reasons. This is the case Rob was mentioning,
> where an admin may wish to centralize Apple Update metadata with the
> actual updates themselves, not on his/her Munki box, for ease of
> management purposes ;)
>
>

[Gregory Neagle]

On Feb 25, 2013, at 8:20 PM, Justin McWilliams <og...@google.com> wrote:

> On Mon, Feb 25, 2013 at 10:53 PM, Gregory Neagle <gregn...@mac.com> wrote:
>> Munki and Reposado share no data.
>>
>> I mentioned that I run them on the same box, but that really has no bearing.
>>
>> Again: this is _Munki_ information that happens to apply to Apple updates.
>> There's no reason to put it on a Reposado/Apple Software Update/NetSUS
>> server, and no way to put it on Apple's servers.
>
> Hrmm... no reason? 1) to centralize management of Apple updates in
> one place, instead of two, and 2) someone could even wrap Reposado in
> a new CLI for managing it along with the Munki metacatalog together.
>
> FYI, we'll be extending Simian's Apple Update admin UI to allow for
> such centralized management, so I personally don't need to point at
> another server. I simply acknowledge the reason someone would
> potentially want do to that.
>
>> There is a cost (at least to me) to allowing infinite customization.
>
> Agreed. Infinite customization is bad for everyone. But we also
> shouldn't design things in a way which makes future customization very
> difficult. Having no distinction between the catalog types (both in
> the manifest's <key>catalogs</key>) makes it impossible to fetch from
> CatalogURL vs a potential future AppleMetaCatalogURL, should demand
> arise.

If demand should arise, we can reopen the discussion. This seems to me to be an edge case unlikely to have much real-world use. As you've said, you won't need it or use it, and neither will I.

I like the current implementation -- it provides flexibility and leverages existing admin knowledge.

-Greg

[Erik]

I have my ASUS on a separate box from my Munki configuration and the only annoyance I have is having to remote into both boxes to find the update_name. I don't see why I would personally want to point the pkginfo the the ASUS. I believe it should be on the same box munki is on. (just my two cents).

[Erik]

On build 1750, is there a threshold where Munki will not install both AU's and MU's?

I have been doing some testing and I have noticed that machines already in the field are install both type's of updates, but in my "new machine" testing, 1750 is only finding MU's. Once the first set of MU's install (about 18 of them), on the second round it will see AU's.

[Heig Gregorian]

Do you have any Apple updates in your repo that are being installed?  If so, applicable Apple updates (from SUS) aren't offered until whatever managed installs don't contain Apple updates that you've included.

Sent from my iPhone

On Feb 28, 2013, at 9:01 AM, Erik <eriknico...@gmail.com> wrote:

On build 1750, is there a threshold where Munki will not install both AU's and MU's?

I have been doing some testing and I have noticed that machines already in the field are install both type's of updates, but in my "new machine" testing, 1750 is only finding MU's. Once the first set of MU's install (about 18 of them), on the second round it will see AU's.

--

[Gregory Neagle]

Munki will not check for/offer Apple update from a Software Update server if it is installing or removing what it thinks is an Apple update/product that happens to come from your _munki_ server.

I'm guessing there is one or more Apple product in your set of 18 items.

-Greg

On Feb 28, 2013, at 9:01 AM, Erik <eriknico...@gmail.com> wrote:

On build 1750, is there a threshold where Munki will not install both AU's and MU's?

I have been doing some testing and I have noticed that machines already in the field are install both type's of updates, but in my "new machine" testing, 1750 is only finding MU's. Once the first set of MU's install (about 18 of them), on the second round it will see AU's.

[Erik]

That would be it then. I'm serving Java and Garageband Extra Content.

With the recent changes to munki, can I import the pkginfo for these two items, thereby allowing munki do to both?

[Erik]

Sorry for the double post, but I did have a question about the pkginfo --au that Heig implemented. I noticed on my 10.8.2 server, my iTunes 11.0.2 was quite different than yours (I'm not using Reposado).

There are two of them specifically:

zzzz041-9792 and zzzz041-9793. I went ahead and imported both of them and just added a RestartAction-RequireLogout, figuring it would be an almost instantaneous way of seeing a different in MSU. The only problem is, the icon did not appear showing that it require a logout.

I haven't made a pkginfo based of Heig's 11.0.2, but could this be the issue? I wanted to post this last week but I simply forgot until Greg's new thread asking for feedback.

[Timothy Sutton]

There are multiple threads, will just add to longer older one.

I've just done a couple cursory tests but haven't seen issues so far. I tried an unattended_install of Java updates, customizing display/description info, and I'm also happily waiting to get kicked off for a force_install_after_update.

One question, there is the version pkginfo key in apple_update_metadata types, but this isn't actually reflected in MSU. I don't know if it's supposed to, though I can't think of many cases where an admin would ever want to override version numbers from a SUS product. Or, is the version key just there so make the rest of the munki check pipeline happy?


I also quite like the implementation - it's very simple for the admin to add metadata for specific packages without crowding and complicating manifests.


-Tim

[Gregory Neagle]

On Feb 28, 2013, at 1:10 PM, Timothy Sutton <t...@synthist.net> wrote:

> There are multiple threads, will just add to longer older one.
>
> I've just done a couple cursory tests but haven't seen issues so far. I tried an unattended_install of Java updates, customizing display/description info, and I'm also happily waiting to get kicked off for a force_install_after_update.
>
> One question, there is the version pkginfo key in apple_update_metadata types, but this isn't actually reflected in MSU. I don't know if it's supposed to, though I can't think of many cases where an admin would ever want to override version numbers from a SUS product. Or, is the version key just there so make the rest of the munki check pipeline happy?

That, mostly.

But it also follows the "normal" Munki rules in that if you have multiple pkginfo items for item "foo", it picks the one with the highest version number.

So if you add apple_update_metadata for something as version 1.0, you can 're-do' it or add it again as version 2.0 and Munki will grab the most recent version.

The version does _not_ override the version as displayed from Apple Software Update data.

-Greg

[Timothy Sutton]

Ok, that's useful. Thanks for clarifying!

[Gregory Neagle]

On Feb 28, 2013, at 12:21 PM, Erik <eriknico...@gmail.com> wrote:

That would be it then. I'm serving Java and Garageband Extra Content.

With the recent changes to munki, can I import the pkginfo for these two items, thereby allowing munki do to both?

What would that accomplish? Software Update doesn't offer either of those updates be default, though it will offer _updates_ to Java if you have some version of Apple's Java installed.

Creating apple_update_metadata cannot force Software Update to offer items. It can only affect Munki's behavior as far as _installing_ them.

-Greg

On Thursday, February 28, 2013 11:53:42 AM UTC-6, gregn...@mac.com wrote:

Munki will not check for/offer Apple update from a Software Update server if it is installing or removing what it thinks is an Apple update/product that happens to come from your _munki_ server.

I'm guessing there is one or more Apple product in your set of 18 items.

-Greg

On Feb 28, 2013, at 9:01 AM, Erik <eriknico...@gmail.com> wrote:

[Erik]

So if they don't offer them by default, why would it hold back Munki from offering other updates to the client?

Let me be clear - What I want to accomplish is to have Munki do both AU and MU upon initial bootstrap. While it is theoretically only one session away, it would be nice to just have both done. Obviously Munki is the one refusing to offer _other_ updates, so I am simply trying to figure out a solution to this.

Those two updates are going to be MU's no matter what, but it somewhat defeats the enhancements if Munki refuses to install both. I understand the methodology between not showing them, but surely there is a case where the new pkginfo could help (if the logic was created).

[Gregory Neagle]

On Feb 28, 2013, at 1:46 PM, Erik <eriknico...@gmail.com> wrote:

So if they don't offer them by default, why would it hold back Munki from offering other updates to the client?

Let me be clear - What I want to accomplish is to have Munki do both AU and MU upon initial bootstrap.

That might not happen in a single run, sorry!

While it is theoretically only one session away, it would be nice to just have both done. Obviously Munki is the one refusing to offer _other_ updates, so I am simply trying to figure out a solution to this.

"Get used to disappointment." - The dread pirate Roberts.

Those two updates are going to be MU's no matter what, but it somewhat defeats the enhancements if Munki refuses to install both.

"Defeats"?

Maybe "doesn't solve every single problem that one might have".

I understand the methodology between not showing them, but surely there is a case where the new pkginfo could help (if the logic was created).

So do the thinking, the writing and the testing! The current behavior is as good as I can come up with. Please compare it to all the other solutions out there.

[Nick McSpadden]

If you used the Munki bootstrap at /Users/Shared/.com.googlecode.munki.checkandinstallatstartup, Munki will continue to run until there are no more available updates of any kind, right?  So even though it may take more than one "run," Munki will keep going until all the MU and AU are complete.

--

Nick McSpadden

Client Systems Manager

Schools of the Sacred Heart, San Francisco

[Erik]

I meant no disrespect by my comment, Greg.

Yes, Nick, I was just trying to figure out if there was an easy solution or not.

[Gregory Neagle]

No disrespect taken.

Maybe some annoyance that it was suggested that because this solution, a marked improvement over what existed a month ago, doesn't solve _all_ the issues around doing Munki updates and Apple updates in the same session, that it "defeats the enhancements".

Sometimes we have to accept that there are tradeoffs and "perfect" solutions are difficult to find.

-Greg

On Feb 28, 2013, at 2:02 PM, Erik <eriknico...@gmail.com> wrote:

I meant no disrespect by my comment, Greg.

Yes, Nick, I was just trying to figure out if there was an easy solution or not.

[Gregory Neagle]

On Feb 28, 2013, at 12:28 PM, Erik <eriknico...@gmail.com> wrote:

Sorry for the double post, but I did have a question about the pkginfo --au that Heig implemented. I noticed on my 10.8.2 server, my iTunes 11.0.2 was quite different than yours

What does this mean?

(I'm not using Reposado).

There are two of them specifically:

zzzz041-9792 and zzzz041-9793.

I see those as well. This is the second set of iTunes 11.0.2 updates from Apple; they were previously released as zzzz041-9596 and zzzz041-9597. Is that what you are referring to?

I went ahead and imported both of them and just added a RestartAction-RequireLogout, figuring it would be an almost instantaneous way of seeing a different in MSU. The only problem is, the icon did not appear showing that it require a logout.

I can't reproduce your issue:

/usr/local/munki/munkiimport --apple-update zzzz041-9792 --RestartAction=RequireLogout

/usr/local/munki/munkiimport --apple-update zzzz041-9793 --RestartAction=RequireLogout

$ sudo /usr/local/munki/managedsoftwareupdate 

Managed Software Update Tool

Copyright 2010-2013 The Munki Project

http://code.google.com/p/munki

Starting...

    Performing preflight tasks...

Checking for available updates...

    Retrieving list of software for this machine...

    Retrieving catalog "development"...

0..20..40..60..80..100

    Retrieving catalog "testing"...

0..20..40..60..80..100

    Retrieving catalog "production"...

0..20..40..60..80..100

Checking Apple Software Update catalog...

    Skipping Apple Software Update check because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check.

    The following Apple Software Updates are available to install:

        + iTunes-11.0.2

           *Logout required

Run managedsoftwareupdate --installonly to install the downloaded updates.

Finishing...

    Performing postflight tasks...

Done.

Note the mention of "*Logout required".

Managed Software Update.app shows the expected icon and message as well:

I've also tested with --RestartAction=RequireRestart and it behaves as expected.

I haven't made a pkginfo based of Heig's 11.0.2, but could this be the issue?

Not sure what "Heig's 11.0.2" is, unless you are referring to the older updates, since deprecated.

[Erik]

On Thursday, February 28, 2013 5:08:52 PM UTC-6, gregn...@mac.com wrote:

What does this mean?

I see those as well. This is the second set of iTunes 11.0.2 updates from Apple; they were previously released as zzzz041-9596 and zzzz041-9597. Is that what you are referring to?

Yes.

I went ahead and imported both of them and just added a RestartAction-RequireLogout, figuring it would be an almost instantaneous way of seeing a different in MSU. The only problem is, the icon did not appear showing that it require a logout.

I can't reproduce your issue:

I figured out the error in my ways (catalog issue), although now I do have a bit of feedback.

When I initially ran munkiimport, I gave it a display_name and a description, mainly because that's what I am accustomed to do when importing MA's and munkiimport asked me. When MSU is ran, the pretty descriptions given from the ASUS aren't there. Also, the display_name (obviously) changing what MSU will show the user as well.

Should we write this in the documentation that it may be preferred to leave as default, or should munkiimport by default skip these values and let the admin add these entries later if desired? It looks like the less we touch the pkginfo, the more "Apple like" the updates become.

My original pkginfo

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>

    <key>catalogs</key>
    <array>
        <string>production</string>

    </array>
    <key>description</key>
    <string>iTunes 11.0.2</string>
    <key>display_name</key>
    <string>iTunes 11</string>

    <key>installer_type</key>
    <string>apple_update_metadata</string>
    <key>name</key>

    <string>zzzz041-9793</string>

    <key>version</key>
    <string>1.0</string>

    <key>RestartAction</key>
    <string>RequireLogout</string>
</dict>
</plist>

The one I believe should be default for admins.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>

    <key>catalogs</key>
    <array>
        <string>%YOURCATALOG%</string>

    </array>
    <key>installer_type</key>
    <string>apple_update_metadata</string>
    <key>name</key>

    <string>zzzz041-9793</string>

[Gregory Neagle]

On Mar 1, 2013, at 9:37 AM, Erik <eriknico...@gmail.com> wrote:

On Thursday, February 28, 2013 5:08:52 PM UTC-6, gregn...@mac.com wrote:

What does this mean?

I see those as well. This is the second set of iTunes 11.0.2 updates from Apple; they were previously released as zzzz041-9596 and zzzz041-9597. Is that what you are referring to?

Yes.

I went ahead and imported both of them and just added a RestartAction-RequireLogout, figuring it would be an almost instantaneous way of seeing a different in MSU. The only problem is, the icon did not appear showing that it require a logout.

I can't reproduce your issue:

I figured out the error in my ways (catalog issue), although now I do have a bit of feedback.

When I initially ran munkiimport, I gave it a display_name and a description, mainly because that's what I am accustomed to do when importing MA's and munkiimport asked me. When MSU is ran, the pretty descriptions given from the ASUS aren't there.

munkiimport has no idea what "zzzz041-9793" _is_.  In the future, some tool (maybe munkiimport, maybe another) could download and parse the Apple sucatalog and and Distribution files to find this info. This will require time and disk space, especially the first time around.

Also, the display_name (obviously) changing what MSU will show the user as well.

Obviously.

Should we write this in the documentation that it may be preferred to leave as default,

I think "preferences" are just that.

or should munkiimport by default skip these values

That could happen.

and let the admin add these entries later if desired? It looks like the less we touch the pkginfo, the more "Apple like" the updates become.

Yes.

[Erik]

I have been trying to think of a solution for AU's that are munki managed.

I know personally, the only reason I ever imported Java is because at the time, munki couldn't do what 1749+ did (unattended, force after date) and I needed to push out it out quickly. I also do a post_install script on Java. Would anyone be opposed to also adding pre/post scripts to AU's? If so, I could remove Java from being a MU.

I still haven't thought of a full solution for AU's that require preceding installations (GB Extra Content, FCPX Supplemental Content) but what if we could add an "include_apple_update" key? If Munki sees this item being installed (for instance a user installs FCP X from optional install), it would then look for AU's, find what it needs and also add the specific zzzz item we added. We may also need to add "requires" to the AU's to be safe.


Example:

    <key>name</key>
    <string>Final Cut Pro X</string>
    <key>include_apple_update</key>
    <string>zzzz041-4538</string>
    <key>version</key>
    <string>10.0.7</string>


If such a thing could be implemented, it would allow me to remove these items completely from MU's. Thoughts, Greg/Heig?

[Gregory Neagle]

On Mar 1, 2013, at 12:10 PM, Erik <eriknico...@gmail.com> wrote:

> I have been trying to think of a solution for AU's that are munki managed.
>
> I know personally, the only reason I ever imported Java is because at the time, munki couldn't do what 1749+ did (unattended, force after date) and I needed to push out it out quickly. I also do a post_install script on Java. Would anyone be opposed to also adding pre/post scripts to AU's?

Adding support for pre and postinstall scripts would necessitate a very large number of additional changes to how Apple updates are installed, and also probably require refactoring code out of installer to some other place. Since we've already made a large number of changes to Munki, I'd rather let these percolate a while, then later discuss what additional pkginfo keys might be useful and how best (or if) to implement support for them.

> If so, I could remove Java from being a MU.
>
> I still haven't thought of a full solution for AU's that require preceding installations (GB Extra Content, FCPX Supplemental Content) but what if we could add an "include_apple_update" key? If Munki sees this item being installed (for instance a user installs FCP X from optional install), it would then look for AU's, find what it needs and also add the specific zzzz item we added. We may also need to add "requires" to the AU's to be safe.
>
>
> Example:
>
> <key>name</key>
> <string>Final Cut Pro X</string>
> <key>include_apple_update</key>
> <string>zzzz041-4538</string>
> <key>version</key>
> <string>10.0.7</string>
>
>
> If such a thing could be implemented, it would allow me to remove these items completely from MU's. Thoughts, Greg/Heig?

You may not understand how Apple Software Update works. We call it, and it tells us was _it_ wants to install. We can't tell it "hey please install update zzzz041-4538, even if you don't want to."

Similarly, "requires" doesn't make a lot of sense, either: Apple Software Update will not offer updates if the requirements have not yet been met.

-Greg

[Heig Gregorian]

Sent from my iPhone

On Mar 1, 2013, at 12:10 PM, Erik <eriknico...@gmail.com> wrote:

I have been trying to think of a solution for AU's that are munki managed.

I know personally, the only reason I ever imported Java is because at the time, munki couldn't do what 1749+ did (unattended, force after date) and I needed to push out it out quickly. I also do a post_install script on Java. Would anyone be opposed to also adding pre/post scripts to AU's? If so, I could remove Java from being a MU.

You make a valid point as the overall intention of Apple update metadata is to remove the need for importing Apple updates into one's repo just to provide some extra treatment that an admin deems as necessary.  I suppose there's no harm in adding preinstall/postinstall scripts as supported Apple update metadata keys.  Guess I'll take a crack at it since I'm freshly familiar with the overall implementation...

I still haven't thought of a full solution for AU's that require preceding installations (GB Extra Content, FCPX Supplemental Content) but what if we could add an "include_apple_update" key? If Munki sees this item being installed (for instance a user installs FCP X from optional install), it would then look for AU's, find what it needs and also add the specific zzzz item we added. We may also need to add "requires" to the AU's to be safe.


Example:

    <key>name</key>
    <string>Final Cut Pro X</string>
    <key>include_apple_update</key>
    <string>zzzz041-4538</string>
    <key>version</key>
    <string>10.0.7</string>

I'm not sure why this is needed.  If you install a piece of Apple software that requires updating, softwareupdate called by munki will add the appropriate updates to ApplicableUpdates.plist which is used to generate AppleUpdates.plist.

It seems that you're asking that if an Apple update or total software package is offered via a munki repo that we somehow denote that there's an Apple update that goes with this.  Given that if an Apple package is offered by munki as a managed_install, it essentially disables the combined munki/Apple update functionality (for multiple reasons previously discussed), I don't know how such a feature would be beneficial.  Not to mention the fact that softwareupdate would have to be circumvented to download the productKey that's been specified in some type of pre-staging fashion.

In short, I'd say let's let softwareupdate do it's job of properly presenting applicable updates to the user based on currently installed software and not to be installed software.

--Heig

If such a thing could be implemented, it would allow me to remove these items completely from MU's. Thoughts, Greg/Heig?

[Erik]

I understood the process but was hoping someone smarter than me would agree and have a better solution (pushing a dist to trick SUS etc) but now that I've thought about it, it would be much more error prone if such a trick could even occur. I'll concede for now on the thought unless I come up with another thought.

At least the pre/post is an option for later.