<div>Hi all,</div><div><br></div><div>I thought I'd share some thoughts after exploring InstaDMG. I assume that those of you who are familiar with both Casper and InstaDMG will probably agree, the two tools have a certain similarity in approach to the problem of imaging. There was something about InstaDMG that caught my attention and interest, so I decided to investigate. Here's what I found.</div>
<div><br></div><div>The reason I wanted to explore InstaDMG was that some of the concepts that Josh Wisenbaker put forth as reasons for creating the project made sense to me, namely avoiding so called "boot cruft" and "testing cruft".</div>
<div><br></div><div>Boot cruft (and I'm paraphrasing and interpreting here) is the collection of files, settings and configurations that get created when you boot an OS for the first time. The worst of these, in my opinion, are duplicate and dead-end network settings.</div>
<div><br></div><div>Test cruft would be things like browser histories and other bits, typically found in the admin and/or generic user account(s) after doing a "burn-in" test of the image.</div><div><br></div><div>
The idea of a never-booted base OS image that lacked this "cruft", and from which to build my configurations in Casper Admin, was very appealing.<br></div><div><br></div><div>So I read up on InstaDMG, watched Mr. Wisenbaker's archived webcast, downloaded the tool and started experimenting. What I found was the following (and these are just my opinions and observations):</div>
<div><br></div><div>InstaDMG is intended for people who are still building monolithic images and do not use a system management & deployment suite such as Casper. In "Image Creation Revolution" (<a href="http://www.afp548.com/article.php?story=ImageCreationRevolution" target="_blank">http://www.afp548.com/article.php?story=ImageCreationRevolution</a>), Mr. Wisenbaker talks about modularizing your deployments via packages in order to simplify altering and/or updating your deployments. If you're using the Casper Suite, I imagine you're probably already doing that. In addition, the InstaDMG implementation (numbered folders, building payload-free packages to deploy scripts) seems clunky compared to Casper.</div>
<div><br></div><div>Boot cruft and test cruft can be undesirable, but it can also be excised via scripting. In fact, nearly anything on a Mac OS X system can be scripted, and those scripts can be added to Casper and used in Configurations and/or Policies. networksetup, systemsetup, defaults, plistbuddy and the standard BSD tools allow you to alter just about any setting you'd need to via scripting. Add Applescript to that and I'd say there's very little you can't do via some form of scripting.</div>
<div><br></div><div>As for potentially "bad" things appearing in browser histories, the pragmatic lifelong Brooklynite in me wants to say, "if your techs are browsing questionable material when they're testing an image, then maybe they shouldn't be techs and maybe a social problem shouldn't be solved with technology." However, the reality is, it could happen, and who wants to explain to the CIO, School Board, or whomever you ultimately report to that "Dopey the technician" put naughty content on the iMacs? Scripting can save you here too.</div>
<div><br></div><div>I have an even broader, sweeping, foolproof (if it works) idea on eliminating these unwanted account settings... build your base image, then enable root, and delete all local accounts other than root. Create all local accounts via Casper Imaging at deployment, or via Policy or Casper Remote once deployed. If there's no account present, it can't have cruft in it. I haven't tried this yet, but I will and I'll let you know if I discover any reason not to go this route.</div>
<div><br></div><div>Another option I'm considering is creating an Apple Netinstall image of the OSX Install Disc and using the automator workflows built into System Image Utility to add your own Casper QuickAdd.pkg The benefit here is that you know you have a clean installation, and the contents of a retail install are known, so you can customize to your heart's content by scripting any changes to or removal of items and packaging any additions. You would also need to suppress the Setup Assistant and script the initial naming of the computer unless you want to have a local admin account created at first boot. In this scenario, I might give all machines the same name and scope a smart group to that computer name to install all company-wide software and configurations. Another option could be autorun data that specifies an OS-free configuration.</div>
<div><br></div><div>All in all, InstaDMG is an interesting idea. In fact, InstaDMG reminds me of a set of scripts I was using before I first purchased Casper. I was also reminded why I abandoned homebrew scripts in favor of the Casper Suite. I believe that as Casper users, we have a better tool (dare I say best of breed?), with top-notch customer service, that can achieve the same goals for us with less work. Not to mention that imaging is just one piece of the Casper pie that also comes with Inventory, A policy engine, ongoing deployment & maintenance and a logged VNC solution.</div>
<div><br></div><div>These are just my thoughts and observations. Test, test and re-test anything and everything before using it in production. Only you know your own environment and only you can say what is acceptable in that environment. If you take any of my ideas into a production environment, I take no responsibility for anything that might go wrong up to and including loss of data, termination of employment and the destruction of the known universe.</div>
<div><br></div>----------<br>Miles A. Leacy IV<br><br> Certified System Administrator 10.4<br>
Certified Technical Coordinator 10.5<br> Certified Trainer<br>Certified Casper Administrator<br>----------<br>voice: 1-347-277-7321<br><a href="mailto:miles.leacy@themacadmin.com" target="_blank">miles.leacy@themacadmin.com</a><br>
<a href="http://www.themacadmin.com" target="_blank">www.themacadmin.com</a><br>
<br><br>