Tag Archives: iMaging

Mac OS X Mac OS X Server Mass Deployment

Keynote From JAMF Nation

In case you were there and would like a copy, here’s the slides from the presentation I did this week at the JAMF Nation User Conference 2012. If you weren’t there, then perhaps they will help you in some way.

JNUC2012

The session was recorded so I’ll try and post when it becomes available for download.

Mac OS X Mac OS X Server Mac Security Mass Deployment

What Changed On My Mac?

According to Wikipedia, fsevents is an API from Apple that allows applications to register for notifications of changes to a given directory tree. This means that when something changes, an application (or daemon/agent) can see the change and take action or track what happened. For Linux, there’s a similar tool in iNotify.

This time of the year, a lot of imaging and packaging is going on at schools and companies around the world. A lot of people are also moving various settings out of images and into either post-flight packages, automations or managed preferences of some sort. In OS X, it’s easy to make a change on a computer and then isolate what files the change touched. Therefore, you can quickly and easily figure out what changes to make (e.g. to a property list via a management profile if you’re getting away from Managed Preferences or even to a configuration file).

One tool that can help you discover what files were changed on a system is fseventer. This small donateware app is easy to use and quickly informative. To use it, just open and click on the play button at the empty screen.

Once the tool starts running it will show you what’s changing in the background on the computer. Now make the changes that you need to make and click on the pause button.

Click on the middle button beside the play/pause button and you’ll also

Looking at the files changed then tells you what the changes are. Toggling changes back and forth and looking at the impact on the file results in knowing the changes to script/automate/profile manage for each.

You will encounter tons of apps that write generated keys here and there rather than easy to find settings such as what you see above. In those cases there are almost always command line interfaces specifically developed for changing a setting. For example, networksetup should be used to change settings that would otherwise be configured in the Network System Preference pane. This is only one of about 1,000,000,000 ways I’ve seen to do this. Happy to invite others to comment on their favorite way to track what’s changing and script it in OS X and other platforms as well.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Automated Regression Testing Mac OS X Clients Using Sikuli

Imaging can be a complicated task. Many imaging environments have a lot of scripts, packages, base images and other aspects of automation. The more of these that you have, the more potential combinations you have for the state of a system once they’ve been run. This gets complicated when you want to make sure that each possible combination of images will have a consistent result when installed. For example, take something simple, like a property list. Each possible combination of packages, scripts images and even managed preferences might have a different impact on that poor property list.

A simple defaults command can often give administrators the ability to see what settings have been applied to a system. For simple tasks that can be programatically trapped for, this might be enough. You can argue that everything can be programatically discovered, but I would argue that is an immature way to look at such things. The example I used in the Enterprise Mac Administrator’s Guide was looking at Microsoft Word. Let’s say that you install 24 fonts. When you open Word, you end up needing to check and make sure that each font loads. You can verify fonts test clean, but you can’t verify that they show up in Word. Microsoft gives you the ability to list fonts that appear in the font menu programatically. But you would literally need to open Word and look in the fonts menu on each regression of each system image in order to tell if the fonts actually appear in the list and if so, whether they look right. One small example. In many environments, each application will have 10 or more tests, with a lot of applications potentially being deployed – and the list grows as failures are discovered year over year…

Now let’s say you’ve got 80 packages in your self service library. At this point, in order to tell that every combination is cool, you’d need to manually open Word on a lot of image combinations in order to verify that your fonts load properly. EggPlant is a tool that enables administrators to run a script that clicks on things for us and reports back on what happens when we do. Now, AppleScript can do some of this as well. But eggPlant gets very in depth in terms of scripting logic and is cross platform. EggPlant leverages a Vine server that gets installed on clients. Screen shots are then taken through a Vine client and compared to screen shots you make and save in eggPlant to compare to the ones that are captured from Vine. That’s a bit of overs implication, but at the end of the day, bolt some simple scripting on top of that and you’ve got a pretty advanced solution. EggPlant now also supports iOS by jail breaking devices to load the Vine server.

EggPlant is one of the best tools for this kind of thing for the Mac platform. It’s more popular amongst those who do a lot of web testing, but it shoehorns nicely into post-flight imaging regression testing. I had a good conversation with @tvsutton at the Penn State Mac Admins conference about eggPlant and he mentioned a tool called Sikuli that I hadn’t used before, so hat tip to him for the rest of this article. While eggPlant has way more logic in it, for simple regression testing, you can leverage Sikuki in its place, which wouldn’t cause some of the potential conflicts that running a localized Vine server might cause on client systems.

Sikuli is a simple tool that allows administrators to script graphical events. You can effectively automate anything you see on a screen using the same type of screen shots; however, with Sikuli, you dump the screen shots directly into the script via the scripting interface, known as the Sikuli IDE.

The first step to using Sikuli is to download the IDE from their site and run the installer. Once installed, open Sikuli.

The options along the left side are some common commands that can be run, in serial from top to bottom. Not all of the possible methods are exposed in the GUI sidebars, but many of the more common ones are. Let’s go ahead and manually enter switchApp followed by an application you’d like to open with your script. In my example, I’m going to use Server.app:

switchApp("Server.app")

While the command says switchApp, it might as well say openApp, as the application will open when you run the command. Go ahead and see for yourself (assuming you have a Lion Server and can therefore open Server.app. Now, let’s look at some graphical interfacing, go ahead and click on click in the sidebar, which will dim the screen and bring up crosshairs for taking a screenshot. Here, select some part of the screen. I’m using Users for my example:

Once you take the screenshot, it should appear in the parenthesis after click. Next, we’re going to send a screenshot command to the computer itself. To do so, we’re going to use the type command, which conveniently types content into the screen. You can also use this for dialog boxes and other such things, but we’re going to just use it to send a screenshot command to the server. To do so, we’re going to tell it to type the 3 key, along with KeyModifier.SHIFT and KeyModifier.CMD:

type("3", KeyModifier.SHIFT + KeyModifier.CMD)

Now your screen will look something like this:

Running the workflow should result in a screenshot on your desktop, of the users on the system. Next, let’s just repeat this process by clicking on all the screens, grabbing a little screenshot of each and producing results on the desktop. All we’re going to do is cut/copy/paste the actual commands and then loop through each of the services and screens in Server Admin until we’ve gotten a screenshot of each:

Now is when things can start getting a little more interesting. We could have done everything we did up to now using Automator. But Sikuli has some built in logic. Here, we’re going to use the wait option in the Find section of the sidebar to go ahead and wait each screen that can be latent to show content. After we click the services, we’ll wait for a pattern on the screen not specific to any given system but that only appears when the settings appear, as follows:

This is a basic configuration of Sikuli, with a simple task, take some screenshots of the Server application. It can then be anchored to an imaging workflow by invoking the workflow from the command line. The command line is just a shell script sitting in the Sikuli-IDE, which is by default dropped into Applications. Because you won’t need it for standard systems, you can use it in special regression testing workflows from your imaging solution. Save the workflow you’ve been running as some title (I’ll use ServerApp) with the .sikuli extension. Then, to run it from the command line, fire up sikuli along with the actual project and a -r operator to tell it to run:

/Applications/Sikuli-IDE.app/sikuli-ide.sh ~/Desktop/ServerApp.sikuli -r

You can also use the sikuli-ide.jar or sikuli-script.jar to get an even lighter install, documented at http://sikuli.org/docx/faq/010-command-line.html#cmdoption-t on the sikuli.org site. On that page, it also explains how to pass arguments to Jython’s sys.argv using the –args option as well as using -stderr. The scripting environment from there becomes jython, a mashup language that takes python and java and uses a little duct tape to hold them together. Overall, it’s an interesting concept. There isn’t a lot of logic, unless you’re willing to script things. But if you are willing to script things then you can do pretty much anything you might want. For example, you can have it play bejeweled for you, so you can actually get some work done (although perhaps you’d rather play bejeweled and script your meetings…):

Mac OS X Mac OS X Server Mac Security Mass Deployment

Disable AirDrop in Mac OS X Lion

Lion comes with this nifty option called AirDrop, which allows users to share files directly. In many environments, this represents a perceived security risk (whether real or not) and must be disabled. To disable AirDrop:

defaults write com.apple.NetworkBrowser DisableAirDrop -boolean YES

To turn it back on:

defaults write com.apple.NetworkBrowser DisableAirDrop -boolean NO

This is done per-user and so can also be done via Managed Preferences, profiles and/or at imaging time.

Mac OS X Mass Deployment

LANDesk Client In Image

LANDesk stores its data files in the /Library/Application Support/LANDesk/data directory. However, there is a uuid file for LANDesk that, if you put the LANDesk client in your image will need to be deleted. The uuid is in the /Library/Preferences/com.landesk.uuid.plist property list. If you rm this file as a postflight imaging task then your client can be deployed on your image:

rm /Library/Preferences/com.landesk.uuid.plist

Mac OS X Mac OS X Server Mass Deployment

DeployStudio From the Command Line

Recently I did a little article on importing computers into DeployStudio lists. I got an overwhelming number of email requests to go a step further and look at importing computers into DeployStudio from the command line. I’m guessing lots of people want to bolt some middleware onto their mass deployment tools (can’t say I blame ‘em).

The first thing to know is that DeployStudio stores most everything in standard property lists. This includes workflows, computer groups and computers. When you install DeployStudio you selected a location to place your database. For the purpose of this example, we’re going to use /DSDatabase as our location. Within this directory is a folder called Databases. In this folder you’ll see ByHost, which stores each computer in a property list that is the computers MAC address followed by .plist. For example, if my computer has a MAC address of 00254bcc76fa then 00254bcc76fa.plist would be the file that houses information about my computer in DeployStudio. In the ByHost folder is an additional property list called group.settings.plist. In here is the information about the computer groups that you have created. In the Databases folder there is also a directory called Workflows, which houses all of your workflows. These can be seen in the example folder structure here.
When DeployStudio is started, it dynamically loads the items from the property lists to compile its database. You can add additional property lists easily, but when you do you will need to restart DeployStudio each time (or each batch).

There are a number of keys in the property lists, with many of which mirroring data that can be imported using the DSImporter.csv template in my previous article. These include:

  • dstudio-auto-disable: Used to disable the DeployStudio Runtime following the initial imaging
  • dstudio-auto-reset-workflow: Used to disable the automate checkbox for the workflow
  • dstudio-auto-started-workflow: Used to assign a workflow. When populating this via the command line you will need to specify the ID of the workflow (remember that the Workflows are in property lists in the Workflows directory. Each has a key for ID, which is what would be used here
  • dstudio-group: Adds the client to a computer group
  • dstudio-host-ard-field-1: Fills in the Info 1 Computer Information field from ARD
  • dstudio-host-ard-field-2: Fills in the Info 2 Computer Information field from ARD
  • dstudio-host-ard-field-3: Fills in the Info 3 Computer Information field from ARD
  • dstudio-host-ard-field-4: Fills in the Info 4 Computer Information field from ARD
  • dstudio-host-interfaces: Arrays to configure static IP addresses for each NIC
  • dstudio-host-new-network-location: Sets up a Location in the Network System Preferences pane
  • dstudio-hostname: Sets the HostName
  • dstudio-mac-addr: The MAC address of the client

To add a computer, you can use plistbuddy or just the defaults command. In the following example, we’ll continue to house our DeployStudio Repository in the /DSDatabase directory and write in only the computer MAC address and whether it will receive a network location, which from what I can tell are the only required keys:

defaults write /DSDatabase/Databases/ByHost/00254bcc76f2 ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:76:f2″;}’
Next, we’re going to add another key to set the first ARD field for a different computer when it is imaged. Your database (ERP, SIS, etc) kicks off the following script, which also puts the intended user’s Active Directory user name in the first ARD field:
defaults write /DSDatabase/Databases/ByHost/00254bcc53ab ‘{“dstudio-host-new-network-location” = NO;”dstudio-mac-addr” =”00:25:4b:cc:53:ab”;”dstudio-host-ard-field-1″=”cedge882″;}’
Once you have done so, open System Preferences and then click on the DeployStudio preference to restart the DeployStudio Server. You can also restart the DeployStudio Server using launchctl with the com.deploystudio.server daemon. Once restarted, your new computer (or computers if you ran both examples) should be listed in DeployStudio. Happy scripting!
Mac OS X Mac OS X Server Mass Deployment

ASR Setup Tool Open Sourced

Originally Posted to the 318 TechJournal
318 has decided to open source our ASR Setup Tool, which can now be found at http://asrsetup.sourceforge.net. The ASR Setup Tool is built as a wrapper for the asr command line suite from Apple. The description from SourceForge:

Developed by 318 Inc., ASR Setup Tool is an application for setting up Apple Software Restore (“ASR”). In the context of the ASR Setup Tool, ASR is used for setting up a multicast stream that can then be leveraged for imaging Mac OS X computers. We hope you enjoy!

Mac OS X Mass Deployment

Hiding a Partition in Mac OS X

Utility or restore partitions are often meant to be hidden for users. The setfile command can be used to change attributes of files and volumes in Mac OS X, including the hidden attribute. To hide a volume called Restore you can use the following command:

setfile -a V /Volumes/Restore

Mac OS X Mac OS X Server Mass Deployment

DeployStudio: Creating a New Master Image

Once you have been using DeployStudio for a time, you’ll invariably end up creating a new master image.  This is a hot topic this summer, given that Apple will be releasing Mac OS X 10.6 later this year and many people integrating DeployStudio want to make sure that they can manage the solution themselves during the subsequent updates.  Provided you have been leveraging all of the best in package based imaging this might be a relatively small file, or if you are using a monolithic image for distribution it might be a fairly large file.  Either way, DeployStudio makes it fairly straight forward to create a new master image.  To do so, first get your imaging station ready using similar techniques to how you have created your master images (known in DeployStudio as Masters) in the past.  Then follow these straight forward instructions:

Creating a Master Image from an Imaging Station Using DeployStudio

Creating a Master Image from an Imaging Station Using DeployStudio

Mac OS X Mac OS X Server Mass Deployment

Imaging Maturity for Mac OS X environments

Seems like most companies start out manually installing their computers.  This works for awhile but then they run into a situation where they’re manually installing too many and realize that for the most part they’re all pretty much the same.  That’s when products like Carbon Copy Cloner and Ghost (for those pesky Windows workstations) come into play.  Suddenly they’re saving time by mounting up an image and restoring it.  Then there is a collection of post-flight tasks they perform, like setting up user environments, settings and directory services bindings.  Then, there are just too many for this, so people start doing network based imaging.  Something like NetInstall, NetRestore, ASR or Ghost.  Some do unicast and then move into multicast but this seems to be the next step.  At this step people are typically still doing monolithic imaging, or one image as one big file.  

The next step is where things start to get really interesting.  And NetInstall, NetRestore and Ghost Enterprise still have options for it.  But in some cases, not a lot.  This is where specialty options come into play.  This is Jamf software’s Casper Suite, LANrev, etc.  At this point, people are typically building a package based set of installer files and distributing them along with a base image, which is basically just a bare metal image.  At this point many environments start to save a lot of time by doing what, in essence, is object-oriented imaging.

Once people start building out all these packages, some start to realize that they can then start to automate more and more.  Suddenly you’re writing shell scripts for everything, including getting you coffee and donuts and even putting down small revolts in the Balkans.  But there’s still one more step.  And this is where things get really interesting.  Regression testing.  The software isn’t cheap, but in a Mac environment you can leverage Eggplant from Redstone Software to do it.  Eggplant uses VNC to perform image recognition and uses those images to process scripts.  Eggplant takes a few days to get used to, but once you do you will start finding that if you want to open Office and verify there are no errors on 15 different image sets that you can do so easily and effectively without manually going through your images.