AutoCasperNBI, AutoImagrNBI & El Capitan

Standard

The Captain

Update 25/10/15: The post has been updated with my findings & explains the additions in AutoCasperNBI & AutoImagrNBI where applicable.

On Wednesday Apple unleashed the 11th iteration of OS X, El Capitan.

This release has had a number of under the hood changes that have affected AutoCasperNBI & AutoImagrNBI, some like csrutil have been detailed here.  The two main issues can be found in greater detail below.

Now, don’t fret, these changes are not insurmountable. They just mean that neither AutoCasperNBI nor AutoImagrNBI will have 10.11 releases available for a few weeks.

This should be fine as there’s no urgency for 10.11 NBIs as, at the time of writing, all current Macs can boot to 10.10.

AutoImagrNBI

As AutoImagrNBI is based off of AutoCasperNBI I have been making some changes to AutoCasperNBI  for 10.11 that will make their way to  AutoImagrNBI in the next release.

Also, in the below where I mention AutoCasperNBI in the below, that can largely be interchanged with AutoImagrNBI

System Integrity Protection (SIP)

You’re going to hear ALOT about SIP & csrutil.

If SIP is unknown to you, crawl out from your rock & hop over to Derflounder.

I have been seeing if there is a way in AutoCasperNBI that I can pull a list of NetBoot servers via the JSS API & then add them to a Macs whitelist via csrutil. Forget the chicken & egg nature of that for now, it’s an idea to see if I can reduce some of this new faffing around.

However, 10.11 NBI’s created with a pre-release AutoCasperNBI have had SIP enabled.

Screenshot 2015-09-29 21.03.34

BUT, I’ve seen the same with NBI’s created with Apple’s System Image Utility.

This issue is here, tbh this may not be resolvable in a scalable or not hacky way. So this may not be resolved.

Update

As mentioned above, even NBI’s created with Apple’s System Image Utility have SIP enabled & adding the automator action “Bless NetBoot Server” does not add the NetBoot servers to the whitelist due to SIP being enabled.

It therefore appears that that action only works in an Install or Recovery environment, I have logged a bug (23251163) to ask for better clarification within the Automator action on this limitation.

PlatformSupport.plist & NBImageInfo.plist

This is actually the bigger release stopping issue.

I’ve blogged about the Enabled/Disabled identifiers in NBImageInfo.plist before.

Well on 10.11 Apple have removed/omitted the “SupportedModelProperties” array from the PlatformSupport.plist found at: /System/Library/CoreServices/PlatformSupport.plist.

Instead there is a mechanism using the SIU private framework that takes a devices boardID such as: Mac-031B6874CF7F642A & spits out the corresponding Model, like: MacPro6,1. (They have been picked at random).

This issue will affect offering NBI’s to the correct clients via OS X server & BSDPy, & can be found here.

Also, as AutoCasperNBI can create 10.7+ NBI’s on 10.9+, with OS’s not needing to match.. Utilising that private framework will bust this & I am very keen to keep this functionaility.

I’m thinking about something along the lines of AutoDMG’s Update Profiles, where AutoCasperNBI holds a NBImageInfo.plist pre-populated with a “SupportedModelProperties” per each 10.11 OS Build.

That’s a fair amount of change however & whilst I have logged a bug with Apple about this new behaviour, (22677569). It was closed as a dupe of 22799473, so potentially this behaviour is incorrect.

Update

10.11’s PlatformSupport.plist found at: /System/Library/CoreServices/PlatformSupport.plist only contains “SupportedBoardIDs” & not the “SupportedModelProperties” needed to model filter on NetBoot servers such as BSDPy.

When generating a NBI on 10.11 via SIU a private framework included within 10.11 is called to resolve the “SupportedBoardIDs” to “SupportedModelProperties”. However, as AutoCasperNBI & AutoImagrNBI allow for the creation of 10.7+ NBI’s on 10.9+ this private framework cannot be used by either AutoCasperNBI & AutoImagrNBI.

Therefore, within AutoCasperNBI’s & AutoImagrNBI’s /Contents/Resources/ is a folder called “10.11NBImageInfo”

Within which NBImageInfo.plists for each build of 10.11 can be found (these are named per build). Also a NBImageInfo.plist called “Latest.plist”

Screenshot 2015-10-25 21.42.27

If an OS.dmg is selected for a build that does not have an NBImageInfo.plist within AutoCasperNBI or AutoImagrNBI, then AutoCasperNBI or AutoImagrNBI will attempt to download the missing NBImageInfo.plist from here.

Screenshot 2015-10-25 16.08.00

If the build specific NBImageInfo.plist is found, it will be downloaded to the app bundle for use when creating NBI’s for that build. However, if the build specific NBImageInfo.plist cannot be found or downloaded due to lack of internet connectivity then the “Latest.plist” will be used & a dialog box like the below will be shown:

Screenshot 2015-10-25 16.08.21

Many thanks for msardes & foigus on the macadmins.org Slack for their help with the above.

Update to the Update

With 10.11.2 Apple have added the the “SupportedModelProperties” array missing from the PlatformSupport.plist on 10.11-10.11.1.

So I’ve made appropriate changes to AutoCasperNBI & soon AutoImagrNBI.

Want to Help?

PULL REQUESTS ACCEPTED!!

The latest commit of AutoCasperNBI should contain all of the amendments for 10.11 support so far, please pull & attempt to resolve the above.

Especially the “PlatformSupport.plist & NBImageInfo.plist” issue, I may well be looking at this in the wrong way & options appreciated.

Thanks in advance!!

 

 

3 thoughts on “AutoCasperNBI, AutoImagrNBI & El Capitan

  1. Excellent work I must say, glad we have guys like you making our jobs easier, and I hope you get figure this stuff, would be very useful. Would be cheeky of me to make a small feature request?

    Would be great if you can add in a way for us to add dock items. I love how everything is set, but it would be nice if I can add say a link to the Utilities folder on the dock for example.

    Keep up the great work, we are counting on you (no pressure).

    • Hi Kamal,

      This has been requested a few times, but would honestly be a bit of a faff to write.

      The workaround would be for you to deploy as custom dock as you wished to the root account via an Additional Package.

      That’s what I do.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.