Friday, February 13, 2009

Deploying Final Cut Pro to a Lab: Multicast ASR

For the past couple of weeks I have been working on and off on a project to deploy Final Cut Pro in a fresh install for our Macintosh lab.  Previous to this the process was to image the machines and then install Final Cut Pro through a script.  Then on each machine I would need to enter in a site license for the software.  This took a lot of time, usually two days for a sizable class of 8 or so.  And, it didn't give me a huge margin of error either.  

At first I wanted to do something with NetBoot, because it makes it so easy.  Just set the NetInstall image as the default image on the server, and then deploy by booting the system off the NetInstall image.  it's really easy to set up, really easy for anyone to deploy.  Unfortunately, it doesn't handle large images very well.  And when I say large images, I mean large images over 38 GB.  I had often wondered why, until I took the Mac OS X Deployment class, and found out that NetBoot uses a unicast method of installing, which is very inefficient.  It actually surprised me that was the case.  

The only other option that was even remotely feasible would be to use a multicast ASR server.  Every Macintosh (either server or client install) supports the server aspect of this project, so it's very easy to deploy.  The only drawback:  It requires understanding of the command line.  Here is the process I took in order to get Final Cut Pro installed. 

Problems:  

  1. Fresh Install of Mac OS X 10.5 with all necessary updates

  2. Fresh installation of Final Cut Pro, Motion, Color, and Compressor (these are the Pro classes we offer here in Edtech).  

  3. Practice files for the class.

  4. License key already included. 

  5. An administrator and a student account setup and ready to go.


I began the project by going through the Modular system image creation process.  In this process, you use a sparse image to install your OS and software, place your necessary files, and manipulate any configuration needed for the final deployment.  This is ideal for initial OS setups and system images.  So I installed the OS from a disk image of the install DVD with the following command: 
sudo installer -pkg /Volumes/Mac OS X Install DVD/System/Installation/Packages/OSInstall.pkg -target /Volumes/MacintoshHD/ -verbose

Now, I could have added a reference to an XML file that would have removed all unnecessary installations (like printer drivers), but the default install was good enough for the project and hand.  In this case, the MacintoshHD drive is actually an external FireWire drive.  I could also have done this on a machine in Target Disk Mode, but I thought this would  be sufficient, and it saved a lot of time, actually.  

Once completed, I installed the updates.  To find out what I needed, I actually booted up a machine with this default install and ran Software Update, which gave me the names of the packages.  I then downloaded the disk images, moved them to my machine, mounted the images, and installed with a command like this: 
sudo installer -pkg /Volumes/Mac OS X Update Combined/MacOSXUpdCombo10.5.6.pkg -target /Volumes/MacintoshHD/ -verbose

I kept the verbose switch on just so that I could see when it was done and judge when I needed the next update.  When I got to the Quicktime update, I ran into a problem:  You can't update Quicktime to 7.6 on an non-booted system disk.  That through a wrench into the whole "modular image" process.  Not to worry though, it didn't set back my image creation.  

Once I finished with all the updates that I needed, I then booted off of the FireWire drive and created my users in the directory.  I began with the admin account, which I used to install the remaining updates and Final Cut Pro and Motion Content from their respective disk images.  The installation let me enter in my site license for Final Cut Studio, and saved me a lot of time on each machine.  I than ran updates for The Pro Apps, which took only a couple more updates to finish.  Once done, I created my Student account with the standard login, and rebooted back into my regular computer. 

Note:  Do not try Final Cut Pro at this stage!  It will create the scratch disk with your UUID, which will make it unusable for any other machine after imaged! I found this out the hard way.

So now I have a system that is completely imaged, has the users created and ready to go, and has not launched Final Cut Pro quite yet.  Now I need to create my disk image that I'm going to use for my restore.  This is really easily done in Disk Utility, particularly if you have the image on a FireWire drive.  

Open Disk Utility, and then select the disk volume you created.  Do NOT select the physical drive!  That would result in a larger image than you need, taking up your entire drive.  Want to learn why?  Take the Mac OS X Deployment class.  ^_^  

Once the disk is selected, click on the New Image button at the top.  It will then let you name it (this is just the name of the new image, not the name of the disk), and ask you which type of image you would like.  I named the file ClonedImage.dmg.  The image needs to be Read Only, and Not Encrypted.  If you choose, you can make the image compressed, though it does take a little away from the performance.  I kept it as uncompressed for simplicity's sake.  Then settle in, this can take a while.  For a 38+ GB image, this can take almost up to an hour (time varies on the machine you use, RAM size, processor speed, etc.).

Once it's done, click on Disk Utility's Images menu, and then select Scan Image for Restore.  This can take some more time, though not as much as creating the disk image.  So settle in, have a good book to read or clean out your email.  

Once done, it's ready for deployment.  Some may suggest that you fix your permissions on the disk before you get to this point.  I've not needed to so far, but it is a good practice to adopt.  This would be a case of do as I say, not as I do.  ^_^ 

Now copy your new image to the "Server".  It can be Mac OS X Server, or a Mac OS X computer.  Either will support the ASR command.  I chose to use a Mac OS X Server that also had NetInstall images for the Macintosh 10.5 Leopard Install DVD.  You will know why in a minute.  I copied the file to the root directory ( / ) for convenience.

Once copied over, boot up the new machine and log in as an Administrator.  Open your Terminal, and create a config.plist file somewhere on the system.  The config.plist file should have at least the following parameters: 
defaults write /Volumes/Backup/Apple/Images/config "Data Rate" -int 6000000
defaults write /Volumes/Backup/Apple/Images/config "Multicast Address" 244.0.0.10 

I put it in the root directory as well for convenience, though you can place it anywhere you can remember it.  Then enter this command: 

sudo asr -server /config.plist -source /ClonedImage.dmg

Press enter, and you should get a notification that your ASR server is ready to begin multicasting.  Once done, you now just need to get to your computers you wish to restore and run the restore image there.  

In this case, I find it simpler to boot off of the Install DVD image.  By making a NetInstall image, it's easy to do and doesn't require multiple disks (and the disks don't walk away unexpectedly).  It also guarantees that your restore system is on the same subnet as your Server, and will have an assigned DHCP address.  Once booted off of the Install DVD, select your language and then click the continue error.  It will ask you if you want to run the install, instead click on the Tools menu, and then select Terminal. 

Now you should only have the Terminal window open.  Here, type the following command to start the restore, assuming your ASR Server has an IP address of 10.1.0.1: 

asr restore -source asr://10.1.0.1 -target /Volumes/Macintosh HD/ -erase

This command will search for an ASR server at that IP address, and then erase the target drive and restore from that image.  Then let it go!  For my image it took about 5 hours to complete, but just about all the machines completed the restore at almost the same time.  So I could have completed one install or 22 at the same time from the same server, and saw little difference in the time it takes to make the image.  

Now, this is the process I used.  It worked great, and our Compressor class (the guinea pig class for this image) ran just fine.  But what if you don't have the time, or the confidence to run the command line tools?  You can do roughly the same thing with NetRestore, which is currently no longer in development, or Deploy Studio.  Both of these tools can do the same thing I do here, but have a nice GUI interface and management is simpler.  

So you may ask why I chose to do it the hard way?  Because I love the command line, and I want to be sure I have the process down pat.  After all, unless you understand the process behind the scenes of a GUI tool, what do you do when the GUI tool doesn't work or has an error?  Where can you troubleshoot the problem?

No comments: