Archive

Archive for the ‘Bash scripting’ Category

First Boot Package Install With Automated Apple Software Update.pkg

August 31, 2014 2 comments

While working recently on First Boot Package Install.pkg, I decided to implement a way to automatically install all available Apple software updates along with enabling other packages to be installed at first boot. After some work and testing, I’m happy to announce the release of First Boot Package Install With Automated Apple Software Update.pkg.

The main difference between First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg is that before installing the user-selected packages, all available Apple software updates are downloaded and installed. By design, the First Boot Package Install With Automated Apple Software Update.pkg script will use Apple’s softwareupdate tool to check for and install available updates, then reboot the Mac automatically until all available updates have been installed.

Screen Shot 2014-08-30 at 9.34.24 PM

Screen Shot 2014-08-30 at 9.36.48 PM

As not all shops that may want to use First Boot Package Install.pkg will find this functionality to be needed or desirable, I’ve set up a new repo on Github for First Boot Package Install With Automated Apple Software Update.pkg. That way, Mac admins will be able to choose which one they want to use.

All First Boot Package Install With Automated Apple Software Update.pkg components and scripts are available at my GitHub repo:

https://github.com/rtrouton/First-Boot-Package-Install-With-Automated-Apple-Software-Update

Please see the README available at the repo for how to use First Boot Package Install With Automated Apple Software Update.pkg. The Iceberg project files are also available via the link above if you want to build a customized First Boot Package Install With Automated Apple Software Update.pkg for your own environment.

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…

Follow

Get every new post delivered to your Inbox.

Join 151 other followers

%d bloggers like this: