possible bug in munki using old cached manifests after upgrading to higher OS X?

[MiqViq]

Hi all,

I had a strange problem after I upgraded one 10.6 Mac to 10.8 using OSXInstallPkg.

OS X 10.8 upgrade went fine.

ClientIdentifier was pointing to 10.8 version of manifest for that computer (written locally using defaults).

But when running munki it still picked up those old 10.6 manifests which were in "/Library/Managed Installs/manifests"

And those old manifests were definetly not included in new specific manifest for that computer.

Because of that munki tried to install components from those manifests resulting to errorrs as they could not be installed on OS X 10.8.

Problem was fixed by removing all items in "/Library/Managed Installs/manifests" and re-running munki.

So there may be an issue with munki using cached manifests...?

 

Anybody having the same problems?

[Rob Middleton]

On 09/10/2012, at 9:09 PM, MiqViq wrote:

> Hi all,
>
>
> I had a strange problem after I upgraded one 10.6 Mac to 10.8 using OSXInstallPkg.
>
> OS X 10.8 upgrade went fine.
>
> ClientIdentifier was pointing to 10.8 version of manifest for that computer (written locally using defaults).

When was this plist re-written? During a munki preflight or earlier?

What version of munki?

(I suspect the included manifests were not the problem, but that the wrong primary manifest was downloaded on the first run in 10.8)

Rob.

[Miq Viq]

Munki version 0.8.3.1634.

ClientIdentifier should be modified with set_munki_id.pkg which I included in OSXInstallPkg.pkg

Thinking this further it could be that munki did run before the new ClientIdentifier was written...

I guess I have to create a pkg which:
-disables munki-launchd
-removes old cached manifests
-ensures that new ClientIdentifier is valid for the new OS version
-re-enables munki launchd and munki-run-at-boot.


-MiqViq

[Rob Middleton]

On 09/10/2012, at 10:46 PM, Miq Viq wrote:

> Munki version 0.8.3.1634.
>
> ClientIdentifier should be modified with set_munki_id.pkg which I included in OSXInstallPkg.pkg

Is that the only place you set the ClientIdentifier? Is there a backup way it is set if that doesn't take? (ie: I'm still suspecting the ClientIdentifier isn't actually in place as early as you intended).

As this occurs outside of any standard munki workflow (munki doesn't have a standard way to do this) I easily interpret if the timing of your steps should work.

>
> Thinking this further it could be that munki did run before the new ClientIdentifier was written...
>
> I guess I have to create a pkg which:
> -disables munki-launchd
> -removes old cached manifests
> -ensures that new ClientIdentifier is valid for the new OS version
> -re-enables munki launchd and munki-run-at-boot.

I think you are over-complicating. Perhaps check the order everything occurs (including the pkg that should update the pref file) in --
/var/log/install.log
/Library/Managed Installs/Logs/ManagedSoftwareUpdate.log (runtype & ClientIdentifier)
/var/log/system.log

Stale cached manifests will be deleted by munki -- so long as the appropriate main manifest has been downloaded.

Rob.

[Josh Malone]

Well - I don't have anything useful to add on the particulars of the
problem, but I would recommend not using OS-specific manifests but
rather use a single site_default manifest with conditional items that
include the proper OS-specific manifest. I've just switched over to
this scheme and I'm VERY happy with it.

<key>conditional_items</key>
<array>
<dict>
<key>condition</key>
<string>os_vers BEGINSWITH "10.7"</string>
<key>included_manifests</key>
<array>
<string>lion_manifest</string>
</array>
</dict>
<dict>
<key>condition</key>
<string>os_vers BEGINSWITH "10.8"</string>
<key>included_manifests</key>
<array>
<string>mountain_manifest</string>
</array>
</dict>
</array>

[Miq Viq]

Thanks for your insight.

I have thought I should use more those conditionals…


-MiqViq