A Django site.
August 1, 2008

Jeremy Robb
scothoser
Scothoser's Corner
» Final Cut Pro Software Deployment: My Final Deployment Success

Next week we are running a Final Cut Pro 5-day class to prepare students for the Final Cut Pro exam and get more familiar with the software.  It’s great, except the software is huge and doesn’t load into a monolithic system image very well.  As such, I had to find a way to deploy the software in a timely manner without a lot of work or overhead.  

I started first with a modular NetInstall image.  The idea was that I would include the software packages in the install image, it would create the image, and I could install it without worrying about configuration.  Boy was I being hopeful!  At first it would not recognize the software, and then it finally accepted the mounted disk images as I dragged them into the Automator Action.  I thought all was well, until I tested the image.  

It installed the OS just fine, but didn’t include the Final Cut Pro packages.  Well, I thought, I would just need to create a base install, and then deploy the software through a package.  Seemed easy enough, at least..

Mac OS X 10.5 has a great feature with PackageMaker (available with the XCode Tools Development package) that is called a Snapshot Package.  Basically, you can install software on your Macintosh Computer while this is running, and PackageMaker can tell the difference between the original state of the machine and the new improved state.  You can then create a package that would install all the changes across the board, and you would be all set.  

I started by using PackageMaker on the MacBook Pro that I would be using for the class.  I then started the process on the MacBook Pro, installed Final Cut Pro and the Motion Content, and waited.  Once done, I stopped the snapshot, reviewed the changes, and tried to make the package.  PackageMaker crashed on me every time.  I tried three different MacBook Pros, each with the same result.  

At that point, I started to get frustrated.  I tried the same process on my office Mac Pro, and it worked!  I was able to make the snapshot image, and create the package.  I then transferred it to a MacBook Pro computer and started the package.  It ran, told me it was successful, and I was sitting on cloud nine!  Until I tried to run Final Cut Pro, that is.  It would crash every time I tried to run it.  It could have been a permissions issue, but by this time I was running out of time.  I have a busy week with a surprise class and some instructor interviews to conduct, and I needed to come up with a solution quickly.  

So, I tried installing the software on a MacBook Pro from disk images using the installer command from the Command Line.  It worked, installed a bit more than we usually do, but otherwise was successful.  Well, if this would work, surely I could create a script that would mount the images, install the packages, unmount the images, and delete the images to free up space.  It was worth a try. 

The script was easy to write, and is below: 

 

#!/usr/bin/env bash

# This script should install Final Cut Pro and Motion from disk images.
# The script will need to be run as root, which the package should do
# automatically.
# First it will mount the images, and then it will run the Installer
# scripts for Final Cut Pro, and then Motion.

# The Images are assumed to be in /Users/Shared

hdiutil mount /Users/Shared/Final\ Cut\ Studio.cdr
hdiutil mount /Users/Shared/Motion\ Content.cdr

# Now the Installation will be run.

installer -pkg /Volumes/Final\ Cut\ Studio/Installer/FinalCutStudio.mpkg -target /
installer -pkg /Volumes/Motion\ Content/Installer/MotionContent.mpkg -target /

# Once finished, the script needs to unmount the images.

umount Volumes/Final\ Cut\ Studio
umount Volumes/Motion\ Content

# Now no longer needed, the disk images can be deleted.

rm -rf /Users/Shared/*.cdr

 

The Script worked on my inital testing, as long as it was run in sudo (installer needs to be run as root).  So I took it a step further and set it up as a package.  I opened PackageMaker again, added both the disk images to it and set the install location to the /Users/Shared directory.  I then added the script to the last package (in this case Motion) as a postinstall script, so that it would run after the Motion image was copied.  I created the images without any errors, and tried the deployment:  Success!  It installed just fine, and everything worked in Final Cut Pro that was expected to work.  

So, I then figured that if this worked, surely it would work if I added it to a NetInstall image, right?  So I created a new NetInstall image workflow that would add this image to the NetInstall.  I then tested it out, and it still didn’t install the package.  So, I copied the package to the server, shared it out, sent the package to each machine, and installed it manually from there.  In the end, I got the deployment working, and the total deployment (not counting the time taken to try and create images and such) took about half the amount of time it would have if I installed everything with the CD’s.  It could have taken even less time if I had Apple Remote Desktop installed and used it to deploy the image.  

So, that was my experience.  I’m going to look at the NetInstall workflow to see if I missed something in how I placed the Automator Action for the package install.  Until then, I still have a very viable deployment solution that takes less time than I would have expected.  ^_^

November 6, 2007

Clint Savage
herlo
Sexy Sexy Penguins » Tech
» Thoughts on the Fedora Upgrade - Part 1

So its been a whole two days since I upgraded to Werewolf. I love it! Most everything works out of the box (OOTB), wireless, bluetooth, even suspend/resume seem to be possible for the first time!

But one of the oddities I encountered while upgrading was the names of the packages. Mind you, this is just my twisted mind being interested in some of the funny odd or strange package names I found while the yum upgrade was taking place.

So here’s the list anyway, with a short description of each. Enjoy:

  • gwenhywfar - A multi-platform helper library for networking and security applications and libraries.
  • meanwhile - Lotus Sametime session functionality.
  • neon - An HTTP and WebDAV client library.
  • coolkey - Linux Driver support for the CoolKey and CAC products.
  • rarian - Designed as a replacement for scrollkeeper; A documentation meta-data library.
  • openjade - An implementation of the ISO/IEC 10179:1996 standard DSSSL.
  • sox - (Sound eXchange) is a sound file format converter.
  • cadaver - A command-line WebDAV client.
  • booty - Small python library for use with bootloader configuration.
  • orca - A flexible, extensible, and powerful assistive technology.
  • zenity - Lets you display Gtk+ dialog boxes from the command line and through shell scripts.
  • eog - Eye of GNOME (EOG) is an image viewer.
  • gok - Enables users to control their computer without relying on a standard keyboard or mouse, leveraging GNOME’s accessibility framework
  • devilspie - A window-matching utility.*

This information was gathered using the command ‘rpm -qi <packagename>’.  This provided enough information to help understand at least the basics of each of these packages and whether to consider using them in the future.

The packages in italics above are packages that I consider interesting, and I plan to attempt to blog about each of them in turn as part of my POW series.

The devilspie package has a * which means that I’ve used this program before.  I quite enjoyed using the Devil’s Pie, and plan to take a look at it again in Fedora 8 as the previous package had some real limitations and lacked needed flexibility.

Please watch for the upcoming articles on these utilities.  Also, if there are packages that you found interesting during your upgrade, please comment and let me know what they are so I can learn and possibly use them as well.

Cheers,

Herlo