IT life is never dull. There’s always a crisis or rampant issue that’s affecting the site, staff, or all of the above. One common link between help desk and sysadmins is the ever increasing need to stay on top of application updates.
Application management is serious business, and it’s easy to fall way behind after just a few missed updates, not to mention the increased security vulnerabilities that are sure to follow closely behind.
For OS X, many open and closed source management suites exist to easily manage hundreds or even thousands of Macs across the LAN. But for smaller environments–or those short on IT staff–easier to manage solutions, like Apple Remote Desktop or DeployStudio, may be used in conjunction with Packages to create and deploy application installers in a similar fashion.
The key is to create the installers to be deployed or repackage them altogether in the PKG format, which make them easier to deploy silently across the network. IT can even simply store them as a repository on a shared folder, allowing end users to install apps on an as-needed basis, if policy permits.
Before diving into the sea of app packaging, let’s first take a minute to look over the technical requirements:
- Apple computer running OS X 10.5+
- Display resolution of 1,200 x 800 (minimum)
- Packages app
With that out of the way, let’s repackage our first app to get a feel for the process.
- Launch Packages.app, and you’ll be greeted by the wizard. There are two possible selections to begin the process. Depending on the choice, it will dictate what type of package you’ll be creating. Raw Package pertains to the majority of OS X installations that use the drag-and-drop method of app installation. However, Distribution refers to the traditional installer format that will guide the user through the process. Distributions are usually found with larger app suites, like Microsoft Office, that are multi-path to allow for multiple selections during the installation. For the purposes of this article, select Raw Package and click Next (Figure A).
- On the following page, provide a Project Name and location to store the project files. Click Finish to proceed (Figure B).
- With the wizard selection complete, the project window will appear with several tabs to delineate each category. In the Project tab, give the project a name and select the build path (Figure C).
- In the event that certain files or folders need to be excluded, clicking the plus sign [+] will allow you to choose what to exclude from the final product (Figure D).
- Next, the Settings tab. This section is broken into three sections: Tag, Post-Installation Behavior, and Options. Tag is very important, because it contains information pertaining to the app and will be used in the event of future upgrades. Post-Installation behavior allows you to set how the computer will behave after the install is complete. If you’d prefer the Mac reboot or shutdown, that can be set from the drop-down menu (Figure E). Lastly, Options allows you to toggle settings for the application installer, such as if you wish to disable admin rights to be prompted during install. These should be set as desired to best match your environment’s needs.
- The Payload tab is the meat and potatoes of the repackaging. Essentially, this is where applications, PLISTs, aliases–generally, any files you wish to include in this package–will be added to the file hierarchy in the Contents portion of the Payload section. Additionally, security attributes may be modified here at a granular level for each of the files (and folders) being added to the package, plus their respective path(s) when adding one or more items (Figure F). Scripts may be included as well.
- As far as required information to process and build the package, that’s basically all there is to it. Once you’ve double and triple-checked the settings and payload, select Build | Build from the Packages menu, and the package will go through a series of checks. Ultimately, it will be created at the path designated earlier. Upon build completion, Packages will itemize each check to provide feedback based on each step in the process and the outcome. This makes troubleshooting errors much easier, since the problem areas will be highlighted and easier to identify (Figure G).
- With a successful build indicating no errors, the newly created package will be ready to deploy throughout the organization. Though, as a precaution, don’t forget to test it out first. It’s best to measure twice and cut once (Figure H).
A note about the Scripts and Comments tabs. The Scripts tab is available to add pre- and post-flight installation scripts, if your installation requires them (Figure I). A good example of this would again be Microsoft Office. The application installer may be included along with the latest service pack update to create one customized installer package instead of downloading multiple files. This will not only save users time and storage space, but it will also ensure IT that each custom package is deploying the same exact version of Office across the board to each device each time it is run–no version differences or missing updates.
The Comments tab (Figure J) serves its function admirably by allowing sysadmins to include comments that can later be used to aid in package creation, such as tips about deployments, notes pertaining to certain behaviors that should be fixed in a future build, or modifications that may need to be further analyzed. It’s a small but useful addition, especially when multiple admins are working on packages.
Have a better way to reinvent the wheel? Did this method work/not work for your environment? Sound off in the comments section below. Your feedback is always welcome.