A starter guide to using Iceberg to package Google Chrome
Hi Everyone. With the bulk of my Munki starter guides now out, I’m taking a short break and concentrating on other blogs. Don’t worry, Munki will return this year!
In line with this, today’s blog is a simple starter guide to using Iceberg to package Google Chrome with a post-flight script.
Iceberg is one of our most used ‘packaging’ tools and is available free from WhiteBox. To copy the explanation from their website:
“ Iceberg is an Integrated Packaging Environment (IPE) that allows you to create packages or metapackages conforming to the Mac OS X specifications. With Iceberg, you can quickly create your installation packages using a graphic user interface similar to your favorite development tools. Iceberg can also be useful for Administrators who want to gather in a metapackage numerous packages for remote distribution via Apple Remote Desktop.”
With that out of the way, let’s get on with it.
1. Launch the Iceberg application. The default storage location is the Applications folder (/Applications). Also as default the application will not open any windows. Select “File” in the Menu bar, then “New Project”.
2. Under the “Core Templates” section, select “Package” and click “Next”.
3. On the next page you are asked to give the project a name and where to save the project’s working directory. The name should reflect what software it will install and (if known) the version number of the final project. For example: “Chrome_v22.0.1229.94”. The directory can be set to anywhere in the OS, as long as the current user has read/write/execute access. The default location is “~/” which is the root of the current user’s home. This is typically fine. Once set, click “Finish”.
4. Iceberg will now open its main project window. Select the name of your project on the left hand side to show the full content in the right hand window.
5. Settings > Description. The settings here should / can be set as follows:
- Title: The name of the Package. This can be changed or set to anything, but it would be best to stick to the same constraints as the project name to avoid confusion.
- Version: This can be left as default (“1.0”) and has no real bearing on the installer.
- Description: This again is not shown during the installation and therefore should be left blank.
- Delete warning: Same as description, this should just be left blank.
6. Settings > Display Information. The settings here should / can be set as follows:
- Display Name: This is the name that is shown in the top window bar.
- Identifier: This is an individual identifier for the package. This should be formatted as reverse DNS. For example: “co.uk.amsys.Chrome_v22.0.1229.94”
- Get-Info String: This is the information that is shown in the “Get-Info” window in the Finder. This is typically in the format “[package name] [version] Copyrights © [Current Year] [Company name]”
- Short Version: This is the version that is shown in the “Get-Info” window in the Finder. This should match the version number set above.
- Icon File: This can be used to set a custom icon on the package. If left blank it will use the default installer package icon.
7. Settings > Version. This is where you can set the major and minor version numbers of the installer package. These are safe to be left at default.
8. Settings > Options. The settings here should / can be set as follows:
- Restart: Unless the application install specifically requires it, leave this as the default “No Restart Required”. If the installer does require a restart, then it cannot be used with the Deployment Application.
- Authorization: This should always be set to “Root Authorization” to prevent installation failures.
Please Note: Always test new installation packages before carrying out live installations. There is a danger that they would replace existing directories instead of adding to them.
- Flags: These are additional options that can be enabled on the package. Due to the type of packages that would be created with Iceberg, it is recommended that these be left as defaults (no boxes ticked).
9. Documents > Background Image. The settings here should / can be set as follows:
- Default: This will use the default Installer background. This is typically more then sufficient for these custom installers. This is the option we’d recommend.
- Path: This is where you can specify the background image to be used with the installation package.
- Scaling: If ‘Path’ is used, this can also be used to scale the background image as required.
- Alignment: If ‘Path’ is used, this can also be used to position the background image relative to the installation window.
10. Documents > Welcome / > ReadMe / > License. These path boxes are used to package in a Welcome message on the first installer window, a ReadMe page and a License Agreement page. With this use of Iceberg, we would recommend leaving these as default (blank) but it might be something worth trying if it is features that is required.
11. Scripts > Requirements. In this area you can configure additional restrictions on the package it self (such as OS version). These are considered advanced options and we would not recommend their use in packaging applications for internal use.
12. Scripts > Installation Scripts. In this area you can add a number of scripts to run in different sections. If you wish to have an installer that just runs a shell script and doesn’t install anything, we would recommend adding it here under the “postflight” option, and ensuring to tick the box.
Please note: In the example below, the script line is red. This is because the file entered doesn’t exist on the machine I am building the project on. The best way to add scripts to the package is by drag and drop.
13. Scripts > Additional Resources. This area is for adding additional items into the package that are not installed. This is for advanced configuration only and it is not recommended to change this without thorough testing.
14. Plugins. This area is provided for you to add additional Plugins into the installer at the listed points. This is for advanced configuration only and it is not recommended to change this without thorough testing.
15. Files > Default Destination. This area allows you to change the default installation location. It is highly recommended to leave this at the default setting.
16. Files > Archiving Options. This allows advanced modification of the payload for the installer. It is highly recommended to leave this at the default settings
17. Files > [File System Box]. This box is where you can add the applications for installation. Simply drag the require files from their location, into their containing folder in the provided system. If the parent directory is not present, you can drag this instead. This area also allows you to modify the permissions that will be set when the files are installed.
18. Once complete, and you are happy that the settings are correct, click “Build” in the menu bar, followed by “Build” again (the keyboard shortcut for this is “cmd” and “B”). This will now build the installation package. Depending on the size of the payload, this can take from a few seconds, up to 30 minutes.
19. Iceberg will open and display its log window during the build process. Once all of the icons have turned green (grey means ‘in progress’) the package is complete and ready for collection. This is stored in the directory you specific at the start of the project, within the “build” folder. This .pkg file is your completed package.
20. This package can be installed by either double clicking, or with the use of the Deployment Application.
Please Note: It is heavily recommended to take the new installation package and run at least 2 test installations on different Macs to ensure it will behave as expected.
There you have it, a guide to getting you started in Iceberg, hopefully giving you a solid start to expand on.
Any interesting or helpful tools you use? Let us know in the comments below and I’ll try to respond to as many as I can.
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.
This feature has been tested using OS X v10.9.1 which was the latest Mac OS release at the time of writing.