At Apple’s recent event, the release date for the next release of OS X (El Capitan) was “leaked” in the above shown email.
Not only is this release going to be the most magical since the last one, it’s main focus seems to be on performance & security. The latter of which will affect us admins, especially System Integrity Protection (read: SIP).
This post will try to explain one way SIP may affect you, & possibly how to prepare.
System Integrity Protection
Apple has some documentation on SIP here, the key concepts of which can be found below:
- System Locations Cannot Be Written To
- System Processes Cannot Be Attached To
- Kernel Extensions Must Be Signed
- System Integrity Protection Is Configured On Recovery OS
Rich Trouton has a great post on the first key concept, & that can be found here, it’s the last concept that I’m going to go into more detail in this post.
NetBooting and System Integrity Protection
As Rich Trouton (again) has blogged & noted, Apple have taken the unusual & welcome step of releasing a KB article on the changes in 10.11 in the KB (despite some confusion on the KB): Prepare for NetBoot, NetInstall, and NetRestore requirements in OS X El Capitan.
Rich has an awesome image to depict whether or not this will affect you:
Chicken & Egg
So, if you need to NetBoot your clients via the bless command how &/or when can you add a trusted NetBoot server to the Macs whitelist & where is this record kept?
The below command can be run when booted from a 10.11 Recovery Partition & when booted into a 10.11 NetInstall & NetRestore, (a 10.11 NetBoot may well work too, but i’ve not tested yet).
To get a list of the whitelisted address enter:
The issue comes in that if you need to use bless to NetBoot a Mac, then you’ll need to first boot the Mac into the Recovery Partition & then add the netboot servers to the whitelist.
That’s not a particularly uncommon troubleshooting technique, & will then undo the hard work you put into whitelisting your NetBoot servers.
Less Faff More NetBooting
So rather than faffing around with csrutil, what other options are there? Well, there are two alternatives:
- Move your NetBoot Servers onto the same VLAN as your NetBooting clients
- Add IP Helpers.
The 1st option is probably the most drastic & could possibly be logistically unfeasible, & the latter is the one that seemingly makes network admins panic.
IP Helper addresses are used within environments for things such as DHCP, NetBoot & PXE.
The fact that the IP Helpers are used for DHCP is what seems to make network admins get all twitchy.
However, IP Helpers can be put in place for both DHCP & NetBoot. The below is somewhat the process involving those when NetBooting a Mac:
- The NetBooting Mac makes both a DHCP & BSDP Discover (BSDP stands for Boot Service Discovery Protocol).
- The DHCP server responds with the clients DHCP Discover with an IP address (the Offer).
- The Mac responds to DHCP server the Offer with a Request to be allocated the address Offered.
- The DHCP server then Acknowledges the Request.
- The NetBoot server responds to the BSDP Discover, Informing the client of the available images.
- The Mac Acknowledges the Information from the NetBoot server &
- The Mac then Selects a NetBoot image to boot from.
The above is “kind of” right, it’s been cobbled together mostly from this Mike Bombich article. But the important take aways are:
- NetBoot is not DHCP.
- DHCP & NetBoot can be run the on same network, they will both be sent the Discover requests but will only answer the requests for the service they are offering (DHCP will only answer to DHCP, NetBoot will only answer to NetBoot).
If you Network Admins prefer more diagrams, Parallels also have this KB.
Less Faff, More NetBooting
With the IP Helpers in place, Mac clients will send their BSDP Discover requests via to the addresses defined in the IP Helpers without needing any whitelisting.
So, if resetting NVRAM is a thing you do regularly & you currently need to use the bless command to NetBoot.. IP Helpers can greatly simplify the process.