Archive

Archive for the ‘Bash scripting’ Category

Installation error reporting now available in First Boot Package Install

August 23, 2014 2 comments

Following up on a pull request by Matthew Kweskin, I’ve updated First Boot Package Install so that it now reports whether an installation has succeeded or failed. This error reporting is in addition to the error logging recorded by OS X’s installer tool to /var/log/install.log.

Screen Shot 2014-08-23 at 11.13.23 AM

For those interested, here are the changes to First Boot Package Install‘s firstbootpackageinstall.sh script.

I’ve updated the First Boot Package Install GitHub repo with the new First Boot Package Install installer package, along with updating the posted firstbootpackageinstall.sh script and the Iceberg project files with the changes.

Automating Oracle Java 8 updates

August 17, 2014 Leave a comment

To go along with my earlier post about automating Oracle Java 7 updates, I’ve also posted a script to download and install the latest Java 8 update from Oracle. The method is identical, with the exception of referring to Java 8’s SUFeedURL value in Java 8’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file.

Screen Shot 2014-08-16 at 10.31.44 PM

For more information, see below the jump.

Read more…

Automating Oracle Java 7 updates

August 16, 2014 Leave a comment

Something I’ve wanted to do for a while was to write a script to download and install the latest Java 7 update from Oracle. I’ve been using AutoPkg to download the latest Java 7 updates using AutoPkg’s OracleJava7 recipes, but I wanted to develop a script that would do the following:

  1. Download the latest Java 7 installer from Oracle’s website
  2. Install the latest Java 7 update
  3. Clean up after itself

Oracle didn’t make this an easy task, as the download URL seems to change on a per-update version. AutoPkg handles its update task by scraping Oracle’s manual download page for the current correct URL to use.

Oracle does provide a Sparkle-based update mechanism for Java 7 on OS X, so I wanted to see if there was a way to leverage that to pull down updates. The only address I could find in that regard was the SUFeedURL value included in Java 7’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file. I checked that value using the following command:

defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" SUFeedURL

The output I received for Java 7 Update 67 was the following:


https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml

I decided to see what output would come back from Oracle’s site when accessed, so I used the following curl command to see what was returned:

/usr/bin/curl --silent https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml 

The following XML was returned and I was gratified to see that it contained a download link to a Java 7 Update 67 disk image.

Screen Shot 2014-08-16 at 5.58.35 PM

One of the important things I was able to establish is that the XML address embedded with Java 7 Update 67 is not special in this regard. As part of my testing, I verified that using the SUFeedURL value for Java 7 Update 15 and 65 will also work to pull the address of the latest Oracle Java 7 installer disk image.

Using this information, I was able to build a script that can download and install the latest Java 7 update. See below the jump for details.

Read more…

Session videos available from Penn State MacAdmins Conference 2014

July 22, 2014 Leave a comment

The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:

The Extending OS X Management Systems with Scripting session I co-hosted with Jeremy Reichman is linked here:

Upgrading from Casper 8.73 to 9.32

June 28, 2014 4 comments

Since Casper 9.x was first released, I’ve been preparing for my shop’s own upgrade from Casper 8.x to 9.x. As of the morning of Saturday, June 28th, those preparations have ended with my shop’s successful upgrade to Casper 9.32. When I mentioned this on Twitter, I heard from a few folks who mentioned that they were planning to also do this in the near future and @theycallmebauer asked if I was going to post about my experience.

Screen Shot 2014-06-28 at 3.48.47 PM

I thought that was a good idea, so please see below the jump for the details.

Read more…

Automatically fixing MDM certificate enrollment with Casper 9.x

June 15, 2014 1 comment

A while back, I wrote a post on fixing Casper Mac MDM enrollment. This post covered my experiences with Casper 8.7.x and provided a method to automatically fix any problems with the MDM certificate. Unfortunately, the method that works in 8.7.x does not work in 9.x because the command that I use to do the MDM enrollment in Casper 8.x is jamf mdm. As part of the change from Casper 8.x to 9.x, the function performed by the jamf mdm command is now handled by the jamf manage command in Casper 9.x. The jamf mdm command itself does not exist in Casper 9.x

To duplicate the general process which I’m using in Casper 8.x, I needed to run the following commands:

/usr/sbin/jamf removeMdmProfile -verbose
/usr/sbin/jamf manage -verbose
/usr/sbin/jamf recon

The issue I ran into is that jamf manage waits until all policies are finished running, which meant that the MDM fix is running after the jamf recon command completes its inventory update and sends it on to the Casper server. The consequence is that the Casper server would never be informed that the machine had actually been fixed, which potentially cues an infinite loop of fixing a problem which is already fixed.

So I had two issues:

1. I wanted to fix my problem with a Casper smart group that would contain only affected machines and an associated Casper policy that would fix the machines in the smart group. This would allow the problem to be automatically detected and then fixed without the need for human intervention.
2. I needed to make reasonably sure all policies were finished running before trying to run the jamf manage command. Otherwise, running jamf manage would result in the recon running before the MDM certificate gets fixed.

On top of that, I preferred that jamf manage only be run once rather than building a process that potentially ran it a large number of times.

To sum up:

A) I wanted to fix the problem automatically with a Casper policy.
B) I couldn’t directly fix this with a Casper policy. Running the commands above using a policy would mean that jamf manage and jamf recon would not run in the order I wanted them to, with the undesired “infinite loop” consequences described above.

Shea Craig gave me the idea of using a LaunchDaemon and script to run the commands I needed, but I still needed a reliable way of determining if Casper policies were running. Shea’s approach relies on killing the jamf process as needed, but that ran the risk of interrupting any active policies or other tasks that were running.

After mulling over the problem for a while, I thought of another way to determine if a policy was running. /var/log/jamf.log is updated when Casper policies or check-ins run on an individual Mac, so if the log hasn’t been updated in a while, it is very unlikely that a policy is running.

Using this idea, I wrote a script and an associated LaunchDaemon to perform the following tasks:

1. Verify that the Mac can contact the Casper server.
2. Verify that /var/log/jamf.log has not been written to in the past five minutes.
3. If /var/log/jamf.log has not been written to in the past five minutes, fix the MDM certificate and communicate that it is fixed to the Casper server.
4. Delete itself and its associated launchdaemon.

For the details, see below the jump.

Read more…

Understanding Payload-Free Packages

June 1, 2014 2 comments

Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle that could send them over ARD. Payload-free installer packages were the answer.

Installer packages are Apple’s preferred way to install software. Apple built into ARD the ability to install software on remote machines using the Install Packages… function. One useful feature of installer packages is that you can have them run a script before or after the package is installed. You can even set up a number of scripts and have them run in the order you designate. Best of all, you can build a payload-free installer package that run scripts but does not install files. So, when I needed to run a Unix command on one or more of my managed Macs, I’d normally build a payload-free package and use the Install Packages… function to push it out to the relevant machines.

With Apple Remote Desktop 2 and later, Apple included a Send Unix Command… function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a payload-free installer package. However, the practice of building payload-free packages and using those to run my Unix commands stayed with me for the following reasons:

  

1. Ease of use – Running a script contained within a payload-free package does not require any special knowledge or training. All the person using it has to know is how to run an installation using an installer package.

2. Portability – When my management methods evolved beyond using ARD as my primary management tool, I found that different management tools had their own ways to deploy scripts but a common denominator of system management and deployment tools for Macs is that they can deploy installer packages. Using payload-free packages allows me to run scripts on managed machines in a consistent manner regardless of which management or deployment tool is being used.

Read more…

Follow

Get every new post delivered to your Inbox.

Join 151 other followers

%d bloggers like this: