how package up App Store apps to distribute via munki

[Bernstein, Gary]

I was wondering how people are packaging up App Store apps to distribute via munki?

I can think of several ways to do this using copy_dmg or composer or packagemaker. I tried to make a disk image of iBooks Author (free) and I am running into error messages.

Thanks

-Gary

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 -- "The reward for work well done is the opportunity to do more."

 -- "I tried, but it didn't work" is a lot better than "I wish I'd tried."

        Gary R. Bernstein

Assistant Director for Strategic Technology Planning

College of Fine and Applied Arts - IT Services

University of Illinois - Urbana-Champaign

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

[Samuel Keeley]

I have Aperture, Final Cut Pro, Motion, Composer, iWork, and iLife apps which all work fine by just running them through munkiimport.  Apple's applications do not check the app store receipts, so you do not need to do anything else.

--
Samuel Keeley

[Bernstein, Gary]

[Greg Neagle]

On Aug 21, 2012, at 7:27 AM, Bernstein, Gary wrote:

I was wondering how people are packaging up App Store apps to distribute via munki?

/usr/local/munki/munkiimport /Applications/some.app

[Jim Zajkowski]

On Aug 21, 2012, at 10:27 AM, "Bernstein, Gary" <bern...@gmail.com> wrote:

> I was wondering how people are packaging up App Store apps to distribute via munki?
>
> I can think of several ways to do this using copy_dmg or composer or packagemaker. I tried to make a disk image of iBooks Author (free) and I am running into error messages.

We distribute directly from the App Store downloaded installer, which is a bit complicated. This may be vast overkill but we haven't had any trouble with it. Note that you can only redistribute apps from the App Store that don't check their receipt, which is most free apps.

1. Start and pause the download immediately.

2. With Terminal, find the temporary com.apple.appstore directory under /var/folders. Something like "find /var/folders -name com.apple.appstore 2>/dev/null" - if you're not root you'll get some permission errors here so redirect stderr to null.

3. Under that you'll find a directory with some large number, and a few files inside that - flyingIcon, mzm.junk.pkg, preflight.pfpkg, and receipt. the mzm.junk.pkg is the actual app. Now if you resume downloading it will get deleted after installation, but if you make a hardlink to the file, the hardlink will stay around. For example, ln /var/folders/1v/6c9xr5zn6nz92c_vnj3jv17m0000gn/C/com.apple.appstore/12345678/mzm.exgoawfi.pkg ~/Desktop/

4. Resume the download and let it finish.

5. It would seem like you can use this linked mzm pkg directly, but it won't work. Instead, we expand it to get to the pkg inside, and then flatten that.

pkgutil --expand mzm.exgoawfi.pkg appstore.pkg
pkgutil --flatten appstore.pkg/whatever.pkg whatever.pkg

6. You can now use the whatever.pkg with makepkginfo. We sometimes unpack the Payload file from inside the expanded pkg (e.g. appstore.pkg/whatever.pkg/Payload) using pax, and then feed that as -f's to makepkginfo.

--Jim

[Ken Elliott]

nice…

[The Immoral Tristy]

a big thanks for that. I've been puzzling over what to do and how. what a mission.

tristan

[Greg Neagle]

Jim:

Have you found any issues with just munkiimporting the app from /Applications that are avoided by using this method to capture the package from the App Store?

IOW, I'm wondering why one would decide to do this instead of just doing `munkiimport /Applications/foo.app`.

-Greg

[Ricky Chilcott]

Agreed.

We are just packing up the apps as is. I think the only thing that might be better about the approach is that if the update is a delta update, it would apply just the delta as opposed to the whole app. Make sense?

That said, if your network and server can handle the load, it seems like a bit more work and possibly more error prone if people don't get all the deltas.

Ricky Chilcott

[Jim Zajkowski]

Hi Greg,

While non-Apple apps have to be packaged into a single bundle, we assume that Apple is free to break their own rules and produce an App Store item that installs a framework or two.

We generally only use makepkginfo and hand-tweak the plist. When I got started, munkiimport was really new, and I had to redo some of its decisions (if I remember right munkiimport expected a flat package repo, for example). I've not used it since - makepkginfo + a text editor works really well for me.

By working with pkgs and dmgs directly we don't end up installing directly on our desktops - we unpack payloads to temp directories and use that to feed installs entries.


Our munki repo may be a bit more complex than most: we have around 30 business units, three mostly-seperate teams adding packages, 2,300 systems, 300+ pkginfos, 25+ catalogs, and a web UI that lets tier-1 support pick packages for systems.


Oh one other reason is our Mac Pros can't install FCPX, so we download that on one of our test systems and then do the packaging work on our desktops.


--Jim

On Aug 25, 2012, at 8:29 PM, Greg Neagle <gregn...@mac.com> wrote:

[Timothy Sutton]

What's a bit more interesting about this method is that it does not leave a _MASReceipt file in the bundle (which I assume is taken care of by the storeagent installation process). Most of the receipt data seems to be in the 'receipt' file alongside the temp package. So, any application that has some dependency on the receipt would have issues with this installation method.

GarageBand from the MAS expects the receipt to be there on launch; and, its package wrapper's PackageInfo file contains logic related to whether the receipt is present, so that App Store.app will present the right option to the user (requiring Software Update to update the app).

Installing Xcode with this method seems to result in a launchable app, but I believe Rich Trouton had issues with the MAS download on his clients, and whether that was related to a _MASReceipt file being present I don't know. Xcode on the MAS saves a lot of bandwidth with the deltas, but it still seems like a lot of extra work to support, especially if the deltas would ever be OS-specific.


It's interesting to have some insight on the hidden installation process – especially for the purposes of examining Apple's own installers more carefully – but I can't really see the advantage to doing this over pushing the .app bundle as-is, assuming an app's vendor supports mass distribution of the App Store version.


Side note:
If you want to find the MAS download folder a bit more easily, enable the Debug menu:

defaults write com.apple.appstore ShowDebugMenu -bool true

…which provides a handy "Show Download folder" menu option.


-Tim

[Jim Zajkowski]

Again this may or may not be the best solution for everyone. It works for us.

We distribute the GB additional content as an updates_for package, which is what GarageBand looks for (it either comes down as a software update or as a first-launch download if it's not present). Just grabbing /Applications/GarageBand.app will miss the first-launch download (the massive 3+ GB content files), so that's not a one-size-fits-all strategy.

You can snag the receipt file and put it into the app if that helps it along.

We are distributing Xcode 4.4.1; we don't capture deltas though (bandwidth for us is not an issue - we have five package servers). We additionally install the "mobile development" and "command line tools" as updates.

--Jim

[Timothy Sutton]

Interesting - we do the same for GB.

My experience of the standard MAS download of GB was it showing a window explaining that it's retrieving additional content, whereas using the .pkg installer method just prompted for admin credentials, and also complained about a missing bundle in /Library, so my assumption was that it was behaving as though it was not downloaded from the MAS.


-Tim

[Greg Neagle]

Get rid of the final slash.

munkiimport /Applications/CollageIt\ Free.app

will work.

munkiimport /Applications/CollageIt\ Free.app/

will fail.

On Sep 17, 2012, at 4:20 PM, Karl Bunnell wrote:

I tried this method and munkiimport returns: "/Applications/foo.app" is an unknown type.
Following is the actual syntax:
munkiimport /Applications/CollageIt\ Free.app/

/Applications/CollageIt Free.app/ is an unknown type.

I tried this with several free apps from the app store without success.

I'm using the most current munki tools (munkitools-0.8.2.1475.0.mpkg.dmg).

That's not the most current...

What version of the tools are you using. Is there a particular app from the AppStore that worked for you so I can try it just as a sanity check?

[Timothy Sutton]

Either get the latest preview release from the Google code site, or if you want to quickly get the latest auto-build on a machine for _testing_ purposes:

curl http://munkibuilds.org/latest.sh | sh

This is the equivalent of downloading the latest autobuild and installing it to the root volume.


Tim