Postflight script to install a pkg inside a dmg - why doesn't this work?

If the script truly looks exactly like that, it's no wonder it doesn't work.

installer -pkg /path/to/pkg -target /

It's really unlikely there is an installable pkg at the literal path of "/path/to/pkg".

I'm guessing that's not really the script. We'll have a lot easier time helping you figure it out if we can see the actual script.

Also, some other bits not entirely clear from your posting:

Is the script in the bundle-style package's Resources directory?
Is it named exactly "postflight"? (No filename extension)
Does it have the executable bit set?

...er, is this right?

Composer-made dmg with a postflight script

Composer DMGs just lay down files. If you are wrapping something for deployment, you'll need to output a PKG.

...also

## Not supported for flat packages.

Raw PKG is easier to create/deploy, and supports "pre-installation" and "post-installation" scripts.

Rich Trouton has a great article on this:

http://derflounder.wordpress.com/2013/11/03/re-packaging-installer-packages-with-packages/

PS, I'm not a huge fan of Composer...Packages.app is a much better tool for creating proper PKG installers.

Don

Hey everyone,

Not going to debate on the DMG vs PKG, but A DMG can in fact have pre and post flight scripts. In a policy that deploys said package you can add scripts and they have the option of running before and after a policy.

Looking at the original post, it looks like they may have a vendor supplied PKG that is not a flat package at all, and they wrapped it up in a DMG for HTTP distribution. So the work flow would be to download the DMG, mount it, and install the PKG from the mount path to the target drive. This is totally just my assumption. Which all of this can be easily done in one policy. Have the policy cache the DMG file, then use the after option for the script and it can mount the DMG, install the PKG, and then do all the clean up.

Thanks,
Tom

Hey, everyone, thanks so much for the responses.

As this is my first time playing around with post-flights as they appear in Composer, maybe I should just say what I'm doing and see what you might think would be the best solution.

I'm installing WinZip for Mac. Instructions from them on how to register the app (i.e., kill the trial) is to download their pkg installer and a registration file, then run the pkg. If the registration file is in the same directory as the pkg, it will register.

What I've done via Composer is create a dmg that puts the vendor pkg and reg file into a directory on the client. I then created a script with the command "installer -pkg /path/to/pkg -target /". That works. It installs the package and it registers fine, yay.

I could live with that, but Composer has the option for postlfight scripts and such (if you open the disclosure triangle). I was thinking if I added a postflight script there, to do the same thing as the script above, all the functionality I needed would be in the dmg item and I wouldn't need the other script (i.e., one item in the JSS is easier simpler than two).

So I copy and pasted the contents of the original script into the postflight script in Composer. It doesn't work. So I came here because you guys are so amazing.

Michael

@tlarkin wrote:

Not going to debate on the DMG vs PKG

No need to, but it's good to understand the different possibilities/scenarios, like you mentioned. :)

@tuinte wrote:

but Composer has the option for postlfight scripts and such (if you open the disclosure triangle).

That was my point, sure it's possible to have a DMG in Casper and deploy along with a script...but seems like fragile and proprietary, and doesn't lend itself to the possibility that a Help Desk or Desktop Support person may need to double-click, or even run the policy via Casper Remote...all three would be possible if you "wrap" the vendor's PKG and include a post-installation script.

Stephen Sudre has excellent documentation on how to PKG, including describing the different types of packages (PKG, MPKG, flat vs bundle, and what kinds of scripts are supported by each method). Lastly, consider not using Composer at all and use Packages.app (same vendor).

http://s.sudre.free.fr/Software/Packages/about.html

At the end of the day you'll want to embrace the workflow that makes most sense for your environment. Packages is a mature, well supported and highly documented tool that saves you cycles that are better spent on other things. And it adheres/supports Apple's guidelines for package deployment.

Try adding hw/sw requirements in Composer and you'll get the idea, Packages makes that uber-simple and easy. ;) Not a fan of proprietary workflows (Composer DMG) either...FWIW...

Don

Are you trying to add scripts into a DMG? If so, that doesn't work. While you can add them into Composer, when you build it out as a DMG its going to ignore those scripts.
You can run pre or post scripts from the JSS the way @tlarkin mentions, but they can't be included within the DMG and then run automatically when deployed, at least not without developing some complicated process. That's not a Casper limitation.
If you're looking to contain this all into one deployment package (note when I say package that could mean a PKG, MPKG or DMG) then I'd wrap it up as PKG and forget the DMG, unless there is some really compelling reason you need it in the other format.
Its possible to wrap an existing package into another one. We do that actually quite often. So the format is something like:

package.pkg
   /path/to/package/location/installer.pkg
   /path/to/package/location/registrationfile
   postinstall script

So inside the "package.pkg" you can include your "post" script to do a command line install, targeting the pkg at /path/to/location/installer.pkg

Also note that the newer flat package format only supports preinstall and postinstall scripts. The older bundle style package format can support those plus preflight, postflight and a couple of others. But generally speaking my recommendation would be to stick with flat packages since they present less trouble with various share point types.

(deleted: @mm2270 my apologies, you had the script names right: http://s.sudre.free.fr/Software/Packages/Q&A_5.html)

Whole lotta help going on here, appreciated so very much.

I've got it working perfectly via @mm270's advice, with some $3 help from Don.

Packages.app looks promising. Going to play with that.

Thanks again, everybody.

Michael

@tuinte Good to hear, hopefully the $3 doesn't get confusing. There's a $3 used by Installer and there's a $3 used by JSS. ;)

Script Parameters
https://jamfnation.jamfsoftware.com/article.html?id=146

Mac OS X Deplohyment v10.6 <-- dated but in this case still relevant
http://books.google.com/books?id=H3awpzaO7IwC&pg=PA111&lpg=PA111&dq=os+x+installer+target+volume+$3&source=bl&ots=_Vm--UtC6A&sig=TBVFtOtSfhAWi_1eMTIg9NrjcBg&hl=en&sa=X&ei=nyD5UuyON4Hh0QGOnICICQ&ved=0CEIQ6AEwBA#v=onepage&q=os%20x%20installer%20target%20volume%20%243&f=false

Hey All,

How to remove or hide ZipShare & iCloud options on WinZip for Mac