Apple

Clearing Font Caches

Wrote up a handy script to clear all the font caches for the Mac OS, Adobe, MIcrosoft Office and Apple iWorks.

I am using this in Casper, so I have it running as root and having a reboot happen after.  If you are going to run this on your own, you may want to put a root check in there and make sure to reboot after.

#!/bin/bash
## Author: C. Tangora
## Purpose: Remove Font Cache from Adobe, Microsoft, iWork and Mac OS.
## If run outside of Casper, be sure to be root & reboot after.

## Adobe Font Caches are stored in the User's Libraries, and will have "Fnt" in the name and end in ".lst".
echo "Removing Adobe Font Caches (Lists)"
find -x /Users -mindepth 5 -type f -iname *Fnt*.lst -delete
sleep 1

## Next it will remove the font caches from Microsoft Office.
echo "Removing Office Font Caches"
find -x /Users -mindepth 7 -type f -name *Office\ Font\ Cache* -delete
sleep 1

## iWorks is next on the chopping block
echo "Removing iWork Font Caches"
find -x /Users -type f -name com.apple.iwork.fonts -delete
sleep 1

## Next we will restart the Apple Type Server.
# This is the one we want to make sure we reboot (or at least logout) to restart.
echo "Removing OS Font Caches"
atsutil databases -remove
sleep 1

echo "Restarting Apple Type Service Server"
atsutil server -shutdown
atsutil server -ping
sleep 1
echo "Completed Font Clearing."
echo "Please restart ASAP."

exit 0
’till next time

Fastest ways to get a Mac’s serial number from the command line

Getting a Mac’s serial number is often a task that is prelude to other work in a shell script. I was toying around with a script and noticed that it was taking longer than I liked on the client machines, but really fast on my machine. Looking around the web I found a great page that listed the times it took another person to query for the Serial Number, on jaharmi.com. It made me stop and do some time test for myself.

I started timing each component to track down the culprit. Turns out the serial number logic was taking over  a second to run to run the first time it was called, but then was dropping dramatically on consecutive calls. I decided to do some time test myself, first to see if Jaharmi’s post was still relevant (it was from 2008) and second to see if I couldn’t tweak it further to gain a few more fractions of a second improvement.

First was what the script had at first, using system_profile. When I tested just using system_profile I found that the first run of the script would take over 1 second on my Mid-2010 MacBook Pro. The next few times I ran it the time dropped from 1.722 seconds down to as low as 0.226 seconds.  The trimmed mean for running it five times was 0.227 seconds.

system_profiler SPHardwareDataType | grep "Serial Number" | awk '{ print $4; }'

Next I took the ioreg approach, first off what Jaharmi had posted…

ioreg -l | awk '/IOPlatformSerialNumber/ { split($0, line, "\""); printf("%s\n", line[4]); }'

But this took even longer!  The trimmed mean time for this was 0.470 seconds.  That would definitely not do.  However, I still felt that ioreg should return a better time than system_profiler, something in my gut told me that.  So I took a closer look at the script and modified it to return a smaller data set before sorting it.

ioreg -c IOPlatformExpertDevice -d 2 | awk '/IOPlatformSerialNumber/ { split($0, line, "\""); printf("%s\n", line[4]); }'

Now we’re cooking.  This returned a trimmed mean time of 0.007 seconds. I tried tweaking it a bit more with a different sorting logic to see if this could be dropped even further. But alas, it didn’t really make much of a difference when dealing with thousandth’s of a second. I ended up using this code…

ioreg -c IOPlatformExpertDevice -d 2 | grep SerialNumber | awk -F "\"" '{print $4}'

… as it required less code to get the same speed result. I’m now adding this to my useful unix file for future reference.

’till next time

What version is my Mac OS X installer?

One of the things that I do for Mac imaging is use InstaDMG to make my master image.  Part of the InstaDMG imaging process requires the build version of the installer OS to match a specified key in the catalog.  I figured out where this was, months ago, but as time has passed I forgot it.

Luckily, I didn’t need to use it for a while.  But now I do.  We’re having to go to Lion for a few months to get the Mac Book Airs out the door.  I can’t put an unsupported OS on a production machine.  So, we’ll brave new waters for a few months and try to keep that momentum up for a quick adoption to Mountain Lion.

Anyways!  Back to the point of this post!!!!

To find out what version of Lion your installer is (for use with InstaDMG), simply mount the InstallESD.dmg, and open

MacOSXInstallESD/System/Library/CoreServices/SystemVersion.plist.

Now look at the value for ProductBuildVersion.  That is your version number.

I’m posting this, so if I ever need it again, I know where to look.  Thanks to Allister on AFP548.com’s InstaDMG forum for pointing this one out!

Till next time.

Extension Attribute Check for Installed Files

Some applications do not have actual .app packages installed when you run the installer.  One example of this is Lab Stats.  The installer will install multiple files and some UNiX applications, so how do you know if the application is on a machine?  Casper offers a few options:

  1. Turn on UNiX application gathering for your inventory collection.
  2. Only install via Casper and look at the application package receipts.
  3. Run a script via an Extension Attribute to check for installed files.

The first two are good options, but some people do not want to turn on the UNiX application list due to the size & time it takes to gather the inventory report.  If you are implementing Casper on a site you will already have some computers with applications installed outside of Casper, so you may not be able to rely on an accurate installer receipt.  The third option will work regardless of which installer was used (as long as they all install the same files), and doesn’t increase the report time drastically.

The first two options are common tasks in Casper, the third is also but requires a bit of your own scripting.  Under Settings -> Inventory Options -> Inventory Collection Preferences -> Extension Attributes you can create a new extension attribute by clicking on “Add Extension Attributes” and change the Input Type to Populated By Script.  The script is simple, in this example I’ll show how to see if a specific file (foo.bar) is in the Shared User’s directory.

#!/bin/bash

if [ -e /Users/Shared/foo.bar ]
then
echo <result>TRUE</result>
else
echo <result>FALSE</result>
fi

The extension attribute will now show TRUE if the file is there and FALSE if it is not.  You can create smart computer groups filtering on this attribute.

If you want to change the type of file it searches for (say you just want to know if a specific directory is in a specific location).  Fire up the terminal and do a ‘man if’ to see all options available.

Till Next Time.

Virtual Box, the easy way with Casper

We’ve been deploying VirtualBox on a one-to-one basis for the past year.  Each time someone requested vBox we would get their machine and install it.  Casper came along, and after some politics, we decided to give it a shot at building a Virtual Box installer with Windows 7 built-in.  While the end result still requires some hands-on to modify some settings (such as computer naming & binding to the AD), it is by far faster and easier to get a Mac to run Windows 7 in Virtual Box now.

The following are some considerations when planning your vBox.

  1. Not all software is legally allowed to be distributed “on image”.  Sometimes you’ll have to create a post-install process to do this (such as a GPO or Kace, BigFix, etc).
  2. Binding requires unique name, so you’ll want to bind after it is deployed.
  3. Do not have multiple partitions on the windows drive, you won’t be able to use the dynamic disk size of Virtual Box if your second partition has space left on it.
  4. You’ll want to make sure you setup the storage area to be in a shared space, so it is accessible by more than just the user who created the package.

These are just some of the warnings, however the pay-off is worth it.  If you have a paid application for virtualization (Parraellels, VMWare) it is far easier than with vBox (in my opinion), but again you can’t beat the price of Virtual Box.  That advantage of Casper is that you can push the user preferences for VirtualBox out as a separate package, available For Exisiting Users, or For User Template.  We’re in the testing stages now, but if all goes as planned, we’ll have a simplified Virtual Box deployment in the near future.

I’ll post updates when complete (maybe even the file paths if I get the time).

Till next time.

How to Remove Symantec Endpoint Protection 11 (SEP11) with the Casper Suite

Symantec Endpoint Protection 11’s removal is never perfect, few software titles are when you remove or install at the Enterprise level, there’s always a need for further testing and refining.  At the current time I have come up with this method for removing Symantec Endpoint Protection and it seems to work fair enough.  There may be a better way, but this way works for my purpose.

First go to Symantec’s Mac Removal page and download the SymantecRemovalTool from the bottom of the page, not the one that comes up on the top of the page.  Create a folder in the Library/Application Support folder with your business’ name (I use this as a location for storing files and such that can be used in scripts).  Alternatively you could put it in the /tmp folder if you want it to be erased after the reboot.

Now copy the SymantecRemovalTool folder you downloaded (as a zip) into that folder.  Launch Composer and drag the /Library/Application Support/businessname/SymantecRemovalTool folder into Composer.  Let Composer do it’s thing and see the copied files.  Close up Composer and all your windows and move on to the script part.

Launch your favorite shell script editor (XCode, TextEdit, whatever) and put this in the file…

#!/bin/sh
/Library/Application\ Support/businessname/SymantecRemovalTool/SymantecRemovalTool.command / -q

… save the file as SymantecRemovalScript.sh.  Fire up the terminal and make that file executable (chmod +X SymantecRemovaScript.sh).  Launch Casper Administrator and add the script you just made and the package you made from the SymantecRemovalTool folder.

Create a Policy that installs the package, then runs the script after installation.  You can also add the Anti-Virus installer that you are using to replace Symantec with.  I gave a notice that their anti-virus had changed and requested them to reboot.  If nobody was logged in then I had the machine do an automatic restart.

You should be set for the action, but my inventory seemed to not update (though I checked update inventory).  I made three Smart Computer groups to watch this and run an update.  The first group is the Group of computers that still have Symantec Endpoint Protection on them.  The second group had the new Anti-Virus on them, and the third group had both installed.

On the first group you assign the removal/replacement policy.  On the third group (the both group) you assign an update inventory policy.  The second group (new AV) you do nothing as they should all be happy.

Alternate Option:  postinstall script

You should be able to use the postinstall script to launch the SymantecRemovalScript.sh from the installer or even run the script from the postinstall, I tried both and neither worked.  The packages say it installed, but the postinstall script didn’t run.  It should have.  Your mileage may vary.  I found a work around and used that.  Let me know if it works for you as it would remove the need for the script to be uploaded separately.

Till next time.

Deploying InDesign CS 5.5 with JAMF Casper Suite without Extension errors

Save the intro for later.  Down to business.

Adobe has come a long way in the Mac installers for their products, the Adobe Application Manager Enterprise Edition (AAMEE).  However deploying it is still a process that requires some finessing.  JAMF’s Casper does a great job, but if you are not running Casper on a Mac server you are most likely going to run into issues getting it deployed without issue.  Specifically if you have your repository served out via HTTP or SMB.

The issue is a known issue, and knowing Adobe they are not going to fix it.  What I have done doesn’t fix it either, but it does get rid of the extensions so InDesign only loads 223 extensions and not 233.  The ten I took out are all related to InCopy, so if you don’t know what InCopy is or you know what it is and you don’t use it, feel free to use this code to get your InDesign CS 5.5 deployed without users calling back asking why there are errors.

The first part is to use AAMEE to create the installer.  This is documented well on JAMF’s site and Adobe’s.  Just make sure you disable AIR and continue on errors.

The second part is simple, make a script that will run after the installation and just ‘rm’ those pesky extensions away.  When InDesign launches it will register the remaining extensions and launch without issue.  I’ve opted to nuke the whole lot InCopy extensions, but you could get selective if you like.

#!/bin/sh
rm -fdr /Applications/Adobe\ InDesign\ CS5.5/Plug-Ins/InCopyWorkflow

Of course, I highly suggest you just type it out, but if you want to copy it, feel free.

Till next time.