As part of a project to assess the deployment options for National Instruments’ LabVIEW 2013 Pro, I was asked to see if I could deploy it through Casper’s Self Service. After some work, I was able to repackage the installer in a way that deploys smoothly. In the process, I saw a number of ways that this particular installer went against The Commandments of Packaging. See below the jump for details.
National Instruments shipped us a DVD with the installer on it and the installation instructions were essentially “put the DVD into the machine and then run the installer.” I followed those instructions in a test virtual machine and everything installed fine.
So far, so good. But I wouldn’t be able to install LabVIEW from Self Service this way, so I copied the LabVIEW 2013 Pro installer metapackage from the DVD and then tried to install into an otherwise identical VM. This time, the installation succeeded but now I had no drivers. I also saw errors showing up in the installation log that complained about missing installers.
I went back and double-checked the metapackage carefully to make sure that it was only referring to packages contained within itself. As far as I could tell, it was.
Then I started going through the metapackage’s embedded installer packages and found three installer packages with post-installation scripts that made me unhappy.
Postflight script from LabVIEWServiceLocator 2013.pkg
#!/bin/sh chmod g-w /Library/LaunchDaemons launchctl load /Library/LaunchDaemons
This postflight script assumes that the installer is being installed on the same drive that the Mac is currently running from. That goes against Commandment #1: Do not assume that your package will be installed interactively via the GUI or on the currently booted volume.
Postinstall from LabVIEWGPIBShell 3.0.1.pkg
#!/bin/sh sudo rm "/Library/Application Support/National Instruments/.placeholder" sudo installer -pkg "$PACKAGE_PATH/../../../../Drivers/GPIB/ni4882.mpkg" -target / -dumplog -verboseR
Postinstall from LabVIEWVISAShell 5.4.0.pkg
#!/bin/sh sudo rm "/Library/Application Support/National Instruments/.placeholder" sudo installer -pkg "$PACKAGE_PATH/../../../../Drivers/VISA/nivisai.mpkg" -target / -dumplog -verboseR
These two packages also go against Commandment #1 and find unusual ways to do so. These scripts assume that the installer is being installed on the same drive that the Mac is currently running from. The script also assumes that the additional ni4882.mpkg and nivisai.mpkg installers that are being installed by these scripts are at a certain fixed location. This assumption is true if you’re installing the LabVIEW 2013 Pro installer from the DVD. Change anything about where the LabVIEW 2013 Pro installer is located and the referenced installers won’t be found.
This explained why I was seeing errors in the install log. It also explained why the drivers weren’t being installed, as the installer packages referenced in the scripts installed the drivers. The fact that the scripts were using sudo to run the included commands with root privileges, when the scripts’ commands were already being run with root privileges, was just a bad scripting bonus.
Once I had this information and understood what was going on, here’s how I repackaged LabVIEW so that it could be deployed via Casper’s Self Service.
Prerequisites:
A disk image made of the LabVIEW 2013 install DVD
1. Set up a new Packages project and select Raw Package.
2. In this case, I’m naming the project LabVIEW 2013 Pro
3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)
In this example, I’m not changing any of the options from what is set by default.
4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.
To accomplish this, I’m choosing the following options in the Settings section:
In the Post-Installation Behavior section, set On Success: to Do Nothing
In the Options section, check the box for Require admin password for installation.
NOTE: The LabVIEW Pro software does require a restart to allow the application to work properly. I am planning to handle the restart via Casper, but if you’re installing via other means, you may want to set the Post-Installation Behavior to On Success: Require Restart.
5. Click on the Scripts tab in your Packages project.
6. Select the LabVIEW 2013 disk image and drag it into the Additional Resources section of your Packages project.
7. The last piece is telling the LabVIEW installer to run. For this, you’ll need a postinstall script. Here’s the one I’m using:
#!/bin/bash # Determine working directory install_dir=`dirname $0` # # Installing LabVIEW 2013 Pro # # Specify location of the LabVIEW 2013 Pro disk image TOOLS=$install_dir/"LabVIEW 2013 Pro.dmg" # Mount the latest LabVIEW disk image to /Volumes hdiutil attach "$TOOLS" -nobrowse -noverify -noautoopen # Install the LabVIEW software /usr/sbin/installer -dumplog -verbose -pkg "/Volumes/LabVIEW 2013 Pro/LabVIEW 2013 Pro.mpkg" -target "$3" # Clean-up # Unmount the LabVIEW disk image from /Volumes /usr/bin/hdiutil detach "/Volumes/LabVIEW 2013 Pro" # Fix world-writable permissions in /Applications/National Instruments chmod -R o-w "/Applications/National Instruments" exit 0
The logic of this script is as follows:
Since I was only successful when installing the software from the DVD, mimic the environment that the DVD creates.
A. Mount the disk image in /Volumes using the same volume name as the DVD
B. Run the installer from the mounted disk image, so that all of the assumptions made by the install scripts mentioned above will be true.
8. Once you’ve got the postinstall script built, run the following command to make the script executable:
sudo chmod a+x /path/to/postinstall
9. Once completed, add the postinstall script to your Packages project.
10. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)
Once the package has been built, test it by taking it to a test machine that does not have LabVIEW 2013 and install it. The end result should be that LabVIEW 2013 installs along with the correct drivers.
Once it was installed, one thing I noted about the National Instruments directory that is installed by the LabVIEW Pro installer into /Applications was that it seemed to have a number of world-writable files and directories. When I ran a check for world-writable files and folder inside /Applications/National Instruments, here’s the list I got back:
World-writable files can be a security issue, so I added a line in my postinstall script to fix this by removing the world-writable permissions. The application is owned by root and gives write permissions to members of the admin group (like a number of other Mac applications), so I figured that would be fine. That opinion lasted until I actually tried to save a driver template in LabVIEW Pro. By default, LabVIEW wants to save the new driver into a subfolder located inside the National Instruments directory in /Applications.
This flies in the face of how saving files on the Mac is supposed to work, but it did explain why so many files and folders were world-writable; the application assumes the user will be saving files into those directories or otherwise writing to them.
In my case, the users who would be running this software have admin privileges so removing the world-writable permissions won’t affect my shop. Environments who don’t give users admin rights may need to make other arrangements to deal with this issue.
