Preparing Firefox for deployment without Composer

What's your purpose for eliminating Composer? Creating your own .dmg package with the one application to install seems far easier than devising a scripted solution.

I would tend to agree with @talkingmoose here. The whole idea behind Composer is to package up applications in a manner that allows Casper (.DMG) or Apple's built-in Installer tools (.PKG) to deploy the payloads without the need to come with a mechanism yourself. Is there a particular reason why you are trying to remove Composer from your workflow? Otherwise I would stick with using Composer, since it's a lot simpler. In fact, I use Composer to build .pkg packages for deployment for other management platforms besides JSS/Casper, because it's such a great app!

~Ted

If I can avoid turning on my packaging clean machine, running Composer, and then re-imaging my clean machine for each Firefox update, that sounds great. It also avoids the chance of my making a mistake while running Composer.

I can more easily train someone to upload a vendor DMG into Admin and make a minor change to an existing policy compared to adding Composer to the mix. Now I've delegated almost all of my package preparation duties, and can spend all of that free time on my next project.

And why repackage something that's already packaged? A 4-line script takes a few minutes to write, a bunch more to test, and then I've reduced the time for the task each time I have to perform it.

As soon as I use Composer, I own the package I just created, forever. Any time a new version comes out, any time there's a problem, I'm on the hook. If I take a vendor package and use a simple script, I can use the script on any new version of the vendor package, and nobody can blame the packaging process when an app misbehaves.

So I'm eliminating a repetitive task, saving time, reducing potential errors and enabling delegation. Composer is a great program, but I save using it for situations where I actually need to.

Your last post there is pretty close to what I do when I need to deploy the latest FF - trash the old version, mount the dmg, copy the Ff app to Applications, eject the dmg; open Composer, drag the FF app from Applications into Composer. Rename the package to better indicate the version number, save as dmg, add to Casper Admin, index the prior version and tick the Uninstallable option.

Then run/policy it however you want.

As soon as I use Composer, I own the package I just created, forever. Any time a new version comes out, any time there's a problem, I'm on the hook. If I take a vendor package and use a simple script, I can use the script on any new version of the vendor package, and nobody can blame the packaging process when an app misbehaves.

Not sure i get what you're saying here, nor can I agree. If you're devising a script to install a vendor package and something goes wrong, you're still on the hook since you made the script. I understand what you mean by misbehaving apps potentially being blamed on a snapshot Composer package, but for something like Firefox? Its just an app bundle dropped into /Applications. As there's no "installer" for it, I'm not sure what you're trying to avoid there.

Easiest way I've seen to deploy Firefox is to just open Composer, drag and drop the new Firefox from your Applications folder into an empty space in Composer's sidebar and it copies it up with the correct path. You end up with a nice clean /Applications/Firefox.app in your package and nothing else, and it sets the name to "Firefox.app" which you can just rename if you don't like that. Make it a DMG or PKG, upload to Casper and deploy.
The only possible issue I've seen in the past is Firefox sometimes doesn't like being overwritten, and will sometimes need to be deleted prior to the new app being copied down. I'm not sure if this is still an issue with more recent releases of it though. I've had a hard time keeping up with the rapid release schedule they're using now. :)

And why repackage something that's already packaged? A 4-line script takes a few minutes to write, a bunch more to test, and then I've reduced the time for the task each time I have to perform it.

This is a case where the flexibility of Casper makes it a great asset. There are always several different methods to get something done in Casper. We'll have to agree to disagree on this one though, but I respect the principal of why you want to package it in this manner.

I don't consider "drag-and-drop" .DMG files from vendors, packages. They aren't aimed at enterprise level, or for use in silent deployment or imaging, so I don't treat them as such. I just view .DMG as the container format for a file you're getting off a disk or the Internet. Substitute .DMG with .ZIP or .RAR, and it's the same type of archive in my opinion. The .DMG that the JSS/Casper uses are formatted differently than those that come from software vendors and publishers.

If something changes with the disk image, you're not going to get support from the vendor anyway, as it's being used in a method that was not intended. If your .DMG changes, your script most likely breaks as well, so you're back at square one anyway, re-architecting your script.

The best practice from the folks at JAMF is to drag-and-drop these types of applications onto a master computer, then package them up in a .DMG or .PKG. I have a preinstall/preflight script for Firefox that I add to each new installer. Never takes me more than 5 minutes to package up a new version of Firefox in Composer, but YMMV.

I don't really have anyone to delegate packaging responsibilities to - I own all of Casper in my environment, including the packaging, so perhaps my opinion is skewed by this difference.

you're bumping up against one of my annoyances with casper and its handling of installer pkgs vs. drag & drop apps.

doing things the "casper way," you have at least the following choices:

1. drag the app to composer to produce a deployable container format. since the app download's already wrapped in a dmg, i find it pretty dumb to re-wrap it as another dmg. dmg "packages" also aren't really installable packages in the first place, so they're only viable within the casper deployment model. if you wrap the app as a pkg, you at least gain flexibility.

2. use the unmodified dmg downloaded from the vendor and couple it with the installPKGfromDMG.sh script to copy it to /applications. this adds steps, and you need to track multiple things now, but it does work without messing with re-packaging the vendor app.

3. do something similar to 2, but write it yourself.

avoid repackaging apps distributed as pkgs already. casper's support for pkg installers is okay. support for drag & drop app bundles is lame, in my opinion.

i automate wrapping up deployment pkgs using the luggage. for firefox and other free apps, when a new version is released, i just edit the version number, run make, and i get a nicely bundled pkg that's ready to go. it's repeatable and auditable. my ff recipe is here: https://github.com/rockpapergoat/luggage/tree/master/firefox

some folks around these parts are probably sick of my saying this, but munki does a better job with app deployment and removals. take a look and save yourself some trouble.

+1 rockpapergoat :-)

+2 rockpapergoat

@natkins, a good middle-ground might be Packages for a flat pkg that'd take 3 minutes to whip up. Bonus: if you want to make it non-admin-updatable, change the group for the app to staff and modify permissions via Packages before the build.

It's a great app and what I have used/will use until I get my feet under me with theluggage.

I wonder how much of this is frustration with Mozilla for being on a six week release cycle. However I will add at least one opinion in favor of re-wrapping the dmg. I simply use the uninstall feature (made possible by using indexed Casper packages) on ff before installing the new version. It's not the only way to do it of course but it's an easy work flow.

P.S. why would you have to re-image your package making computer to make a ff dmg even given your current workflow? Composer would catch it anyways.

"Packages" is indeed a nice application that I used recently to whip up a custom installer. Its made by the same team that created Iceberg. What I needed to do was a bit beyond the capabilities of Composer, so Packages fit the bill.
Since Nate (rockpapergoat) talks so much about The Luggage here I may just have to take a look at that closer as well.

to add my .02, you own the package and installer whether or not you repackage it. You work in IT so therefore you own anything and everything to do with an end users' computer.

I for one will never NOT repackage a drag-n-drop app. Too many features are lost by not repackaging, whether you make a dmg or pkg. I prefer pkg's for flexibility in different imaging environments and the ability to add pre- and post- scripts.

i also agree about ownership. it's your job to make it work, whatever "it" might be. you can be the type of admin who requires vendor support and points fingers, or you can figure stuff out and adapt. i choose to live and work in the "tool builder" camp.

anyway, i'll try to keep my off-topic rants to a minimum.

generally, here's my advise: automate everything, version control all your stuff, document your code and infrastructure, use sane tools that don't create more work for you, don't reinvent the wheel, collaborate and listen, find mentors and community support, strive to work with people who push boundaries, and always be hacking.

also, i think mozilla's quick release cycle is only frustrating to orgs with slow, outdated IT practices.

they could release new versions every day, and it wouldn't matter much to me. automate away the frustration. if you stress about it, that's your choice.

im sticking with ESR.

This is what i do

1. Customize by adding some essential add-ons (uncompresses) within the app bundle putting them here

/Applications/Firefox.app/Contents/MacOS/distribution/bundles/

1. chown -R root:admin /Applications/Firefox.app

2. chmod -R 775 /Applications/Firefox.app

3. Drag to Composer source

4. Add preinstall bash script. It looks complicated and probably not the best but it works and im not gonna screw with that :)

#!/bin/sh
## preinstall

pathToScript=$0
pathToPackage=$1
targetLocation=$2
targetVolume=$3

consoleuser=ls -l /dev/console | cut -d " " -f4
mobileusers=ls /Users | grep @rufusleonard.hq

# Remove the users previous Firefox bookmarkbackups
rm -rf /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups

# Sleep 3 seconds
sleep 3

# Making the bookmarkbackup folder
mkdir /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups

# Making the Temp Directory
mkdir /Users/"${mobileusers}"/Temp

# Sleep 3 seconds
sleep 3

# Copy the bookmark backups
cp -R /Users/"${mobileusers}"/Library/Application Support/Firefox/Profiles/**.default/bookmarkbackups /Users/"${mobileusers}"/Temp/

# Sleep 3 seconds
sleep 3

# Copy the bookmark backups
cp -R /Users/"${mobileusers}"/Temp/bookmarkbackups /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups/

# Sleep 3 seconds
sleep 3

# Removing the Temp directory as the currently logged in user
rm -rf /Users/"${mobileusers}"/Temp

# Correcting permissions on the /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups/
chown -R "${mobileusers}" /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups/

# Quit Firefox
sudo killall -9 firefox
sudo killall -9 firefox-bin

# Make sure Safari the default web browser for a moment using duti
su - "${consoleuser}" -c '/usr/local/bin/duti -s com.apple.Safari public.html'
su - "${consoleuser}" -c '/usr/local/bin/duti -s com.apple.Safari http'
su - "${consoleuser}" -c '/usr/local/bin/duti -s com.apple.Safari https'
su - "${consoleuser}" -c '/usr/local/bin/duti -s com.apple.Safari ftp'

# Restart launch services unregistering Firefox if a user is logged in

su - "${consoleuser}" -c '/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -u /Applications/Firefox.app'

# Pause 10 seconds
sleep 10

# Delete Firefox
sudo rm -rf /Applications/Firefox.app

# Delete Previous Settings files
sudo rm -rf /Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/*

# Remove Firefox from the users dock
/Library/Management/Applications/dockutil --remove 'Firefox' --allhomes

exit 0 ## Success
exit 1 ## Failure

1. Add a postinstall script

#!/bin/sh
## postinstall

pathToScript=$0
pathToPackage=$1
targetLocation=$2
targetVolume=$3

consoleuser=ls -l /dev/console | cut -d " " -f4
mobileusers=ls /Users | grep @rufusleonard.hq

# Find the users bookmarks and copy them back
cp -R /Users/"${mobileusers}"/Documents/Firefox_bookmarkbackups/ /Users/"${users}"/Library/Application Support/Firefox/Profiles/**.default/

# Pause 5 seconds
sleep 5

# Correct permissions on the users ffbackup app data
chown -R "${mobileusers}" /Users/"${users}"/Library/Application Support/Firefox/

#Check to see if Firefox exists
if
ls -la /Applications/Firefox.app/Contents/Resources
then
# Set the architecture preference order to 32-bit for Firefox because the pdf addon only works in 32-bit!
defaults write /Applications/Firefox.app/Contents/Info "LSArchitecturePriority" '(i386, "x86_64")'

# Making sure the permissions on the Info.plist are correct
chmod -R 775 /Applications/Firefox.app
fi

# Removing the Firefox updater
rm -rf /Applications/Firefox.app/Contents/MacOS/updater.app/
m -rf /Applications/Firefox.app/Contents/MacOS/updater.ini

# Force registration through launch services if a user is logged in
su - "${consoleuser}" -c '/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f /Applications/Firefox.app'

# Pause 10 seconds
sleep 10

# Make sure Firefox is the default web browser using duti
su - "${consoleuser}" -c '/usr/local/bin/duti -s org.mozilla.firefox public.html'
su - "${consoleuser}" -c '/usr/local/bin/duti -s org.mozilla.firefox http'
su - "${consoleuser}" -c '/usr/local/bin/duti -s org.mozilla.firefox https'
su - "${consoleuser}" -c '/usr/local/bin/duti -s org.mozilla.firefox ftp'

# Add Firefox back to the users dock
/Library/Management/Applications/dockutil --add /Applications/Firefox.app --allhomes

exit 0 ## Success
exit 1 ## Failure

1. Keep Firefox in my Composer source list.

2. Package up my addons (unzipped) in /Applications/Firefox.app/Contents/MacOS/distribution/bundles/ and always keep that "Firefox_Setting.pkg

3. Cache to Machines in a policy scoping a smart group

4. Have a policy to install cached at start up

5. Machines boot up at 3am for periodic maintenance scripts

:)

There's a lot of great input here from a number of different backgrounds and environments. To explain a little more where I'm coming from, whenever possible, I keep a process as vanilla as possible, as modular as possible, and as easy to update as possible. This is important in our organization, where roles (phone support, desktop support, Casper admin) are separate, and the environment is barely managed (everyone local admin, end users are mostly responsible for their own computers). See: higher education, but not the computer lab type. I'm not concerned about updating software on people's computers, only in keeping the "image" up to date that goes on new machines.

When it comes to 'on the hook', perhaps that's too strong a term. If I can reduce the potential causes of a problem, it means the problem is resolved faster. If I can emulate the vendor's distribution method (in this case, mount the vendor DMG and copy the app to /Applications), the desktop/phone techs can handle the issue entirely with the tools and knowledge they have available, they don't have to wonder if there was an issue with the Composer package. Inserting me into the ticket escalation process just adds one more moving part. And when something genuinely has to be escalated to a vendor, I want to remove all the possible things they could point a finger at so the problem can be fixed as quickly as possible.

generally, here's my advise: automate everything, version control all your stuff, document your code and infrastructure, use sane tools that don't create more work for you, don't reinvent the wheel, collaborate and listen, find mentors and community support, strive to work with people who push boundaries, and always be hacking.

I couldn't agree more. I happily automated and documented myself out of my last job, you could even say I replaced myself with a (not) very small shell script and a wiki. I'll have to look deeper into The Luggage, it sounds like it could work.

On a bit of a tangent, but a closely related issue: whether to use a master computer to create your OS image each time a point release comes out, or whether to use InstaDMG to create an OS+Combo DMG. I can script the latter, but not the former, and grabbing a master image means I have to trust that no machine or installation specific remnants are left behind. Spending the time upfront to create the InstaDMG script is preferable to me over having to spend x minutes every time a point release comes out. It also means everything is up to date in case I can't prioritize updating the master.

Also closely related: do you use Composer to create a snapshot DMG of Office 2011 and all the patches, or do you make a policy that installs Office 14.2.0 and then 14.2.1? There's no universal right answer to these questions.

For any of you Windows deployment people out there, an example:
I would rather create an MST instead of modifying the MSI directly, rather create an InstallShield ISS answer file, or even write a simple script that runs after an EXE, instead of repackaging the EXE as an MSI.

I'm not claiming my goals match the goals of everyone else out there, especially due to the variation in environment. But I stand behind the concept of vanilla, modular and easy to update, and the less time I can spend troubleshooting the more I can spend automating even more, freeing me up to work on new projects.

Hey Guys,

This is a great conversation here, and I think a lot of great points have been made. Everyone's environment will be different and that means different requirements will be established based on a lot of factors particular to your job. So, there is hardly ever a blanketed best practice that works everywhere.

At my old job I automated everything. In fact, I made it a personal challenge to automate myself out of a job. I had scheduled tasks, policies, and scripts automating everything. I built my work flows to be one click installs of everything. I had cascading SUS servers, netboot limited to certain subnets, and I had one master compiled image with all packages packaged up separately and updated on a semi-regular basis.

Here is what I learned from doing this. Yes it is possible, and yes you can leverage the Casper Framework to build whatever you want. I had Python and Shell scripts running everything for me. I think I got to around 30% to 40% total automation. However, when I left that job, the next guy had to deal with my complete custom solution. Does the new guy know Python and BASH? I hope so.

Easiest way I've seen to deploy Firefox is to just open Composer, drag and drop the new Firefox from your Applications folder into an empty space in Composer's sidebar and it copies it up with the correct path. You end up with a nice clean /Applications/Firefox.app in your package and nothing else, and it sets the name to "Firefox.app" which you can just rename if you don't like that. Make it a DMG or PKG, upload to Casper and deploy.

This is the method I used. It took all of a few minutes to download, drop in Composer, set permissions and build. If this work flow doesn't work for you then I suppose different methods need to be addressed. The above quoted text will allow you to drag and drop these packages into any work flow.

As for my old job I didn't even use Casper Imaging to image machines. Instead I had it kick off a set of asr scripts that block copied a master compiled DMG of OS + updates + standard apps, then package based deployment and separate OD bindings based on smart configurations. So in a "Lord of the Rings," sort of way I had one master image to rule them all. I was managing 8,000 Macs with this set up, so it made sense to me to build that modular standard and deploy it out. My image had zero users in it, zero managed preferences and it worked on iMacs, Mac Minis, Macbooks, Macbook Pros and Macbook Airs. We had all of those at my old job. Then post asr script a post image script ran at first boot which created local user accounts, set some specific settings and so forth. I had separate scripts for each user/group in my deployment. That way I only maintained one image, a few scripts, and then all my packages on an individual basis. I personally owned everything I built there. No one else built it but me.

There are many ways to accomplish the same goals and some will be a best practice and some won't. It will depend on your individual needs and your environment. That is what makes this community so great is we can share ideas that some of us may not have ever thought of.

The new thing I was getting into at my old job before I left was not even imaging at all, but rather thin imaging out of the box Macs. Then only image for break/fix scenarios. Now with target disk mode imaging over thunderbolt you cannot even unbox your Macs fast enough to keep up with how fast that process is.

So, I am a bit lost here on the actual higher goal and I apologize for this, but you want to drop in place a new version of Firefox with out having to modify, lose, or break a user's current settings with Firefox? Like their bookmarks, add ons, and so forth? Then also looking for maybe a package manager with version control?

Thanks,
Tom

We are also performing thin imaging, although I am not entirely sold, mostly due to the amount of time it takes if a point release has come out since the machine shipped (not uncommon when buying by the pallet) and the need to still keep something around for break/fix situations. Also: block transfers are fast. Current process is: NetBoot to DeployStudio which creates a user, adds a launch agent due to 802.1x behaviour on our network, SUS, installs the Casper client and calls 'jamf policy -trigger stufffornewmacs' which installs all the software/scripts/etc for a new Mac. DeployStudio was chosen for the ability to ACL based on AD group membership, a feature I am eager to see in Casper.

So, I am a bit lost here on the actual higher goal and I apologize for this, but you want to drop in place a new version of Firefox with out having to modify, lose, or break a user's current settings with Firefox?

I am purely trying to reduce the number of tools that are used in the process of starting with a vendor DMG and ending with a deployment through Casper. I am lucky in that I am only deploying new computers - once they hit a user's desk I don't need to worry about their software. So there's no existing user data to worry about, no default settings to be applied, I just want the simplest way to make sure the newest version of Firefox is included when a computer is deployed.

The Composer process:
Download Firefox vendor DMG
Mount, copy Firefox.app to /Applications
Launch Composer, select /Applications/Firefox.app, Create DMG
Launch Casper Admin, upload Composer DMG
Log into JSS web interface, modify policy to include new Composer DMG

The script process:
Download Firefox vendor DMG
Launch Casper Admin, upload vendor DMG
Log into JSS web interface, modify policy to include new vendor DMG (script is already part of this policy)

In my mind, that cuts out two steps, and removes the need for the person performing this updating to have any knowledge of Composer, or have to keep the up to date Casper Suite tools around. If I wanted to get fancy, I could even cut out the need for Casper Admin by writing directly to the distribution share and adding it through the JSS web interface (helpful due to Admin's lack of real multi-user support). Or name the DMGs the same and overwrite the old one (although this has downsides for sure).

This is somewhat of an academic point, since Firefox is really easy to package using Composer, which is how I have been doing it in the meantime. As I said above, my question is not based on criticism of Composer, but an exercise to figure out how to best do things in my environment, with the best path to simplify, automate and delegate. After 3 years as a solo SCCM admin, then switching to the Mac side, I don't have the depth of experience compared to Windows.

Great points about leaving the next person with something understandable. I also like to, when possible, use the most widely used/known tools, which makes hiring the next person easier. In the Firefox example, I would hope any replacement would understand a 4 line shell script. When I left my previous SCCM job, things were sufficiently simple to maintain (updating packages to newer versions, for example) to hold them over until they find a new SCCM admin. Big fan of the "Hit by bus" principle.

Thanks for the input.

Hey Noel,

Yeah man I totally get what you are saying. You are trying to avoid reinventing the wheel and keep up to date documentation and knowledge on many different products. I totally get it, and I totally agree. I just wasn't sure from the previous posts but now that you explained it more directly my tired mind wrapped around it.

So, with that in mind a few things I'd like to point out. First of them being welcome to the Mac community. I was once a PC guy back in the day and slowly switched over to Macs over the years once Apple used NeXT as the basis for OS X. So, some things to consider:

1) creating a package properly gives you flexibility, and ensures it gets deployed properly. You may find a vendor supplied package may actually have improper permissions or say something that doesn't fly in your environment. You can use Casper Remote, a policy, a custom trigger policy, pre and post flight scripts, and you can add it into imaging work flows once you build it wit that sort of flexibility. So, as your organization grows and uses more Macs and the demands from the users get higher, creating a standard practice of package creation does have it's benefits. Whatever method you use, make sure it works for you in this manner. This is my opinion not fact.

2) I love to script and can do so in a few languages moderately competently. However, all modern enterprise tools are built to be used with out using the command line. I won't argue that a System Administrator should know such things, because I 100% agree that they should, but it is not required. Also, in the IT world, we have such a dynamic set of user bases that people's skills vary so much and experience does too. There are small businesses that have zero IT staff, and they just make the most computer savvy employee the default IT person. Then you have work places that scale from the newly college grad, up to the senior been in the business for 30+ years IT person. Enterprise tools are developed at a median of this range. I haven't really ran across an Enterprise tool (commercial with full support) at least that requires a user use the command line to use it. There are some open source tools that do so, but there is no commercialized support. Only community based support. So, when building solutions with scripts I fully understand that I solely own the work flow. Even if another person who knows BASH comes and looks at my shell script and I don't comment my code, they may have no clue what I am even trying to do.

3) Time versus reward. This is the biggest factor I think when deciding to custom build solutions. At my old job since I was managing so many I decided to build the solution I outlined in my previous post. With my solution we were able to un-box 6,000 Macbook Airs from pallets and mass image them over netboot in about 4 to 5 weeks. This also included asset tagging them. That is not a bad turn around time for that many including metal asset tags stuck on them. There was a lot of reward me taking the time to build that solution. It was also a one click solution. So in the end it saved us mass amounts of time, which is why we were able to un-box, asset tag and mass image 6,000 Macbook Airs in approximately 5 weeks. It helped I had co-workers who got my work flow though totally too.

4) Thin imaging is great for out of the box Macs, and thunderbolt TDM imaging is insanely fast. I was at a customer site last week and when we demoed imaging over thunderbolt we pushed at 12 gig image to a Macbook Air over thunderbolt in under 3 minutes. You cannot netboot that fast sometimes. Since you are already using manual trigger policies, try adding some to a quick add package on the post flight script to add them into inventory and then deploy apps to them over the network. I know this method is not preferred for lots of people's environments. I personally find it pretty rad!

The process you choose to use will be the right one for you. No one can really tell you how to run your environment and not every solution I outlined would work best for you, or maybe they could all work for you.

Nice to meet a new Mac admin and welcome to JAMF Nation. You'll find a lot of good information here. I can tell you that as you work more and more with Macs you will probably change your work flow several times. I know I did. I always found better ways to accomplish my goals.

Let me know if you have any specific questions about any of this and I will do my best to help answer them.

Thanks,
Tom

After 3 years as a solo SCCM admin, then switching to the Mac side

This may be the telltale sign why folks are confused by the desire to avoid repackaging.

Most Windows installers download as Microsoft .msi or .exe files. These are equivalent to Apple's .pkg and .app formats. However, most Mac OS X installers download enclosed in .dmg disk images. This is an extra layer of complexity Windows admins don't normally handle. They're certainly not use to deploying a standalone executable from a .iso file.

You've probably gleaned this by now but a downloaded .dmg file shouldn't be considered a ready-to-deploy package simply because you can't guarantee the contents are always going to be ready to deploy. Yes, Casper can use a .dmg as a deployment vehicle but that's only with its contents in a certain order such as putting the Firefox application within an Applications folder.

I think I'm safe saying that if you were to move to a new company supporting Macs the scripted method you're using would be considered non-standard. If you're looking for ideas for best practices then my suggestion is to use Composer to repackage because that's what most other organizations would probably be doing. They do it because it's an efficient method of delivery regardless of how they received it in the first place. It's certainly no less efficient than what you're wanting to do with a script.

Well, I still don't like the idea of repackaging things, but your insights have mostly brought me around to the fact that I can't get away from it. I'm new to being a Mac admin, but not new to Macs. I remember DMGs being such a novel and useful concept, and still think they make a lot of sense for end users in a non-managed environment (ability to prominently display documentation, a link to /Applications, etc), but they're frustrating from an admin's point of view (see: Windows EXE installers).

The idea of a self contained app is that you can drop it anywhere and run it. Your home folder, a thumb drive, an external hard drive, the Applications folder, Utilities Folder, so on and so forth.

So, to me, that really isn't a vendor supplied installer, but rather a self contained application you can put anywhere. There is not a registry or the like from other OSes that apps need to install library files into.

Packing it up yourself allows you to choose where it goes and what goes with it. It is a lot different than Linux or Windows. It be nice for a command line package manager for OS X like YUM or APT where you could just tell the computer to fetch the update from the Internet and it just updates it in place.

Welcome to managing Macs and our community forums. Once you get a feel for your own work flows and how they would work best in your environment you will know what to do. Anytime you want to get some feedback here though please feel free to post. A lot of us have many years experience managing Macs and will gladly help you with some input.

Have a good weekend,
Tom

I agree the idea of repackaging is sometimes not for the faint hearted. Out of choice I wouldn't if possible. I was forced for 2 reasons

1. Management implementing systems compatible only with Firefox without Their engineer consultation...yeah nice! (offsite web system etc, plus user PDF guide on intranet where Firefox PDF adding only work in 32-bit!)

2. Mozilla breaking external extensions. Now only seems possible by actually putting them in the app bundle it's self!

Chrome has improved dramatically and in my opinion are better. Mobile account with @ symbols can now install extensions, you can configure automatic background updates.... Yes that right AUTO Updating even when the user is non admin! I have only packaged chrome up once after configuring the auto updating mechanism and snapshoting using Composer, and that was many months ago and versions back :) Chrome is less management and hastle...that's nice :)

If you don't have systems relying on Firefox i would ditch it completely. I have been in the past in discussions with Mozillas Enterprise list and unfortunately they are still not listening enough. It took a few of us to shout to try and force them to do something. But instead of deciding to bring back external extensions they brought in ESR. Better than nothing but not what we wanted :(

@natkins - why don't you use Munki instead of Casper for deploying standard packages. Munki is far more capable, easier, and more reliable to use than Casper Suit for package deployment and patch updates. You only need a Mac Mini to setup Munki, and it doesn't take long at all to get up and running on your clients with the right manifest.

Munki Overview
Munki setup on OSX

With most apps, there is very rarely any reason to repackage them with Composer because they already come packaged, and if you combine Munki with autopkg and AutoPkgr, you have an automated package deployment and patching system. Packages in Munki can also be set to recognise dependencies with other applications, and can ensure that apps aren't updated in place while they are being used (possibly corrupting or crashing the app), but set to require logout before updating.

I find there are very, very few times that I need to use Composer now, and only do so if it really is necessary to package preferences or settings that need to be pushed out to User Templates, etc. Even then, sometimes it is safer or provides more control for future changes just to script this and use defaults to write the preferences in plist files using a LaunchAgent. I use this method to kill the MS Office 2011 first run launch screens.