Deploy VMware Fusion With VM constantly reinstalls

[Jeremiah Baker]

So I am trying to deploy VMWare Fusion 6 (eventually 7) with a volume license and custom settings. To do so, you have to use a specific package within "VMware Fusion.app" called "Deploy VMware Fusion.mpkg". From there you can modify a desktop.ini file with the license, settings, etc. This part is all good and well. However, theres another option with this deployment method to add a pre-configured VM, so that it too will be deployed through this metapackage.

Besides being fairly huge, munkiimport works great and creates a .dmg of this .mpkg, adds it to the repo, etc. to make it available. The issue I'm having is that it will install perfectly, putting Fusion where it needs to be and the VM. But then on next check, it tries to install again, and again. I have tried adding 2 "installs" key, because it appeared that the issue was the receipts, as referenced by this topic: https://groups.google.com/forum/#!topic/munki-dev/tvYFjahA1OE

I added 2 installs keys, one that looked for the actual VMware Fusion.app (this one worked) and one that looked for the VM called Windows7_x64.vmware (this one did not work). Now I assume it couldn't recognize the VM because from what I can tell, Munki doesn't see .vmware as a file, or if it does it for some reason doesn't think it exists. So I decided to change the installs to look for hidden text file that is created as a post-install script using /usr/bin/touch. It still didn't like that and continues to try and re-install the package.

Any help would be greatly appreciated as constantly downloading a 9GB file is getting somewhat vexing.

Here is the 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>_metadata</key>

<dict>

<key>created_by</key>

<string>sysadmin</string>

<key>creation_date</key>

<date>2014-10-01T16:34:39Z</date>

<key>munki_version</key>

<string>2.0.0.2212</string>

<key>os_version</key>

<string>10.9.5</string>

</dict>

<key>autoremove</key>

<false/>

<key>catalogs</key>

<array>

<string>IT-Dev-Test</string>

</array>

<key>category</key>

<string>Productivity</string>

<key>description</key>

<string>VMware Fusion 6.0.4 with DCO Windows 7 Image</string>

<key>developer</key>

<string>VMware</string>

<key>display_name</key>

<string>VMware Fusion with Win7</string>

<key>installer_item_hash</key>

<string>d6533bd9cc1c99ff321eaaf67032bb10e92f1cd7ec47d12cd0907fea138b65ba</string>

<key>installer_item_location</key>

<string>Productivity/VMware/VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg</string>

<key>installer_item_size</key>

<integer>9647286</integer>

<key>installs</key>

<array>

<dict>

<key>path</key>

<string>/Applications/VMware Fusion.app</string>

<key>type</key>

<string>application</string>

</dict>

<dict>

<key>path</key>

<string>/Users/Shared/Virtual Machines/.vm_installed.txt</string>

<key>type</key>

<string>file</string>

</dict>

</array>

<key>minimum_os_version</key>

<string>10.4.0</string>

<key>name</key>

<string>VMware Fusion with win7</string>

<key>postinstall_script</key>

<string>#!/bin/bash

/usr/bin/touch /Users/Shared/Virtual\ Machines/.vm_installed.txt</string>

<key>receipts</key>

<array>

<dict>

<key>installed_size</key>

<integer>0</integer>

<key>packageid</key>

<string>com.vmware.fusion.pkg.massdeploy</string>

<key>version</key>

<string>1.0</string>

</dict>

</array>

<key>uninstall_method</key>

<string>removepackages</string>

<key>uninstallable</key>

<true/>

<key>version</key>

<string>1.0</string>

</dict>

</plist>

[Jeremiah Baker]

As a follow-up, here is what managedsoftwareupdate -vvvv spits out:

    * Processing manifest item VMware Fusion with win7 for optional install

    Looking for detail for: VMware Fusion with win7, version latest...

    Considering 1 items with name VMware Fusion with win7 from catalog IT-Dev-Test

    Considering item VMware Fusion with win7, version 1.0 with minimum os version required 10.4.0

    Our OS version is 10.9.5

    Found VMware Fusion with win7, version 1.0 in catalog IT-Dev-Test

    Found Info.plist at /Applications/VMware Fusion.app/Contents/Info.plist

ERROR: Missing plist path or version!

    Adding VMware Fusion with win7 to the optional install list

    **Processing self-serve choices**

    * Processing manifest item VMware Fusion with win7 for install

    Looking for detail for: VMware Fusion with win7, version latest...

    Considering 1 items with name VMware Fusion with win7 from catalog IT-Dev-Test

    Considering item VMware Fusion with win7, version 1.0 with minimum os version required 10.4.0

    Our OS version is 10.9.5

    Found VMware Fusion with win7, version 1.0 in catalog IT-Dev-Test

    Need to install VMware Fusion with win7

    Download base URL is: http://munki.dco-intranet.lan/repo/pkgs/

    Package name is: VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg

    Download URL is: http://munki.dco-intranet.lan/repo/pkgs/Productivity/VMware/VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg

    Downloading to: /Library/Managed Installs/Cache/VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg

    Downloading VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg from Productivity/VMware/VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg

    Downloading VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg from Productivity/VMware/VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg

    follow_redirects is False

    HTTP/1.1 200 OK

    Date: Thu, 02 Oct 2014 14:51:59 GMT

    Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.30 mod_fastcgi/2.4.6 mod_ssl/2.2.26 OpenSSL/0.9.8za

    Last-Modified: Wed, 01 Oct 2014 16:46:15 GMT

    ETag: "27cad-24cd2d9d4-5045f3cfa63c0"

    Accept-Ranges: bytes

    Content-Length: 9878821332

    MS-Author-Via: DAV

    Content-Type: application/x-apple-diskimage

    Downloading VMware-Fusion-6.0.4-VolumeLicense-Win7-1.0.dmg...

[Jeremiah Baker]

Sorry, one more follow-up, I see the error in that output about not being able to find the plist or the version, however I can confirm that both the plist AND the version exist where Munki is looking for them.

[Timothy Sutton]

The issue here is that you've defined the Fusion app as an 'application' type, but without any additional information that would normally be generated by `makepkginfo -f`.

My VMware Fusion 6 installs array looks like this:

<key>installs</key>
<array>
<dict>

<key>CFBundleIdentifier</key>
<string>com.vmware.fusion</string>
<key>CFBundleName</key>
<string>VMware Fusion</string>
<key>CFBundleShortVersionString</key>
<string>6.0.4</string>
<key>CFBundleVersion</key>
<string>1887983</string>
<key>minosversion</key>
<string>10.7.0</string>

<key>path</key>
<string>/Applications/VMware Fusion.app</string>
<key>type</key>
<string>application</string>

<key>version_comparison_key</key>
<string>CFBundleShortVersionString</string>
</dict>
</array>

An alternative way to check for whether the VM itself is installed: you should be able to just put the path to the VM for 'path', as long as the type is 'file' as you've shown in your pkginfo, as long as you don't expect this path to change after it's been installed.


Tim

> --
> 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/d/optout.

[Gregory Neagle]

On Oct 2, 2014, at 8:03 AM, Jeremiah Baker <jeremia...@dean.com> wrote:

Sorry, one more follow-up, I see the error in that output about not being able to find the plist or the version, however I can confirm that both the plist AND the version exist where Munki is looking for them.

It's looking for them as part of the pkginfo, and you did not provide them!

Compare:

<dict>

<key>path</key>

<string>/Applications/VMware Fusion.app</string>

<key>type</key>

<string>application</string>

</dict>

with an example in the wiki, or the output of `makepkginfo -f /Applications/VMware Fusion.app`. You've deleted or failed to include several important keys that Munki needs to compare applications.

-Greg

[Jeremiah Baker]

So I think there may have been a few issues, but you all were correct. Originally I was getting constant reinstalls because it couldn't find the correct receipts, at which I point I added two installs keys to look for the app and the VM. I did use makepkginfo -f specifically for VMware Fusion.app and it classified Fusion as a "file" and was able to find it, and then I added manually added the installs key for the VM (possibly a bad idea) and munki couldn't find it. After looking through the wiki, I mistakenly changed the installs key for Fusion to look for it as an application, when I should have just left it alone.

I think that is what was causing this most recent error as you all suggest! Thanks for the help.

Let me ask this, it would seem like having an installs key for the text file I create post-install is a bit redundant. I originally had it check for the file thinking it would be a way to ensure the VM was deployed correctly, but I assume Munki would probably just fail if it didn't deploy it correctly. So I could change it back to look for the VM, but as I said it was failing before saying that it couldn't see that file (again maybe that was due to my manual addition of that installs key). But I'm not sure how I could use makepkginfo -f for that since it is embedded in the .mpkg, or am I missing something?

[Timothy Sutton]

It's always a bit more work to create an installs item for an app that's installed as part of a package, vs. a drag-n-drop dmg item. But normally, if you pass makepkginfo -f a .app, it should populate all the bundle metadata and consider it an 'application' type.

One way to help ensure correct paths when making installs items with makepkginfo, is to run it on the _client_ after you've done a test install, i.e.:

makepkginfo -f /Users/Shared/path/to/my/vm.vmware

Since that's a folder, it may consider the type just 'file' and provide only the path, which is probably all you want. If you run makepkginfo -f against a regular file (and that's not a bundle), typically what you'll get back will also contain an 'md5checksum' key, which Munki will use to check whether exactly that file (according to the checksum) is installed. You probably don't want to do this for components of a VM, as parts of it will undoubtedly change over time. Just checking for the existence of the top-level .vmware path is probably sufficient. Because this is getting deployed with a package, if the package install fails somehow in deploying the VM, Munki will report the failure, and the payload of VM likely wouldn't be installed.

Also re: makepkginfo -f, you can run it on your admin station as well against any path just to generate the right syntax, but just be aware that the paths are absolute and that you might need to change it to be what the real installed path would be.


Tim

[Jeremiah Baker]

Thanks again for all of your very quick and helpful responses! I just used makepkginfo on the VM itself and it generated the info and classified it as a file. I tried again with that installs key and it worked perfectly. So I must have just made a mistake before, but all is working as expected now!

Thanks so much again!