Apple have for quite some time being warning Mac Admins to switch to using DEP as a means of configuring Macs instead of various forms of disk imaging workflows. Linked to using DEP they clearly also assume everyone will get a brand new Mac or they or their admins will use RecoveryHD or Internet Recovery to wipe and reinstall them. (It is necessary to wipe and reinstall the operating system in order to trigger DEP enrolment.)
Whilst there indeed some advantages to the DEP approach there are also some disadvantages - something Apple seem blinkered to. In particular contrary to what Apple seem to believe it is the case that every new employee gets a brand new Mac fresh out of the box, it is in reality far, far more common they will get issued a previously used laptop that needs wiping and rebuilding.
Yes it is possible to do this with DEP and using RecoveryHD or worse Internet Recovery to first wipe and reinstall the operating system but this is orders of magnitude slower than a local disk imaging system. This is made worse by the fact that Apple have not provided a means of 'caching' Internet Recovery images. With Recovery images being now over 6GB in size even organisations with generous high speed Internet links will find this a pain.
Imagine the torture suffered by Mac admins in countries with far less advanced Internet links or worse still capped usage levels!
So, I maintain there still is a case for having a disk imaging solution. (Using a disk imaging approach does not prevent then using DEP after imaging a clean copy of the operating system.)
Apple as mentioned have been discouraging disk imaging and possibly thought they had managed to completely disable this approach in High Sierra. This was because they removed the --volume option from the startosinstall command. Fortunately for me at least somehow the way I used this via a High Sierra based DeployStudioRuntime image it still worked even though it is not supposed to. Sadly DeployStudio has not been updated to allow successfully creating Mojave DeployStudioRuntime images.
Trying to run the equivalent script under Mojave to run the startosinstall command does not work because with this approach the --volumes command definitely is killed off. Therefore the startosinstall command will only target the active boot drive which is no help.
I therefore started to consider previous approaches that had worked for older OS releases, for example the old approach of restoring a previously installed boot drive - an approach commonly referred to as 'thick' imaging. This approach is far from desirable but I might have been driven to it. Before I tried that however I decided to look at my previous 'thin' imaging approach which was based on creating a thin install image using the popular AutoDMG tool and then using a DeployStudio workflow to restore that to an APFS volume.
Well lucky me and ya boo sucks to you to Apple! It turns out AutoDMG does now support making a Mojave thin image, it also turns out that by booting from a full working Mojave disk and running the DeployStudioRuntime utility you can then run the workflow to restore this thin image.
Note: To use an external drive on new Macs so you can boot in to a copy of Mojave and run the DeployStudioRuntime tool you need to turn off SecureBoot.
This approach which I had previously abandoned for High Sierra historically does not include triggering any Firmware updates but so far the only models of Mac I need to use this approach for i.e. Macs that can only boot in to Mojave e.g. the Mac mini Late 2018 do not yet have any firmware updates. Older Macs even the MacBook Pro 15" 2018 can boot in to High Sierra and use my startosinstall based approach even to install Mojave.
Friday 9 November 2018
Tuesday 16 October 2018
UK - Dumb Boilers vs Smart Thermostats
It is increasingly common these days for home owners to buy a 'smart' thermostat to control their central heating. Indeed arguably smart thermostats are the number one category of smart home device. The leading member of this category is of course the Nest Learning Thermostat. (Now version 3.)
Originally such smart thermostats whilst indeed having various additional smartness actually worked in the same way as original dumb thermostats in that they basically sent a signal to the boiler asking for heat or saying stop I am warm enough, i.e. a basic on or off control. This approach involves the boiler either running at 100% power or 0% power i.e. fully on or fully off.
However newer models of smart thermostat including the aforementioned Nest Learning Thermostat v3 also support an alternative approach which allows setting a target temperature for the boiler so that the boiler can adjust the level it needs to run at to keep at that target temperature. This means that instead of constantly starting and stopping the boiler it will run continuously at a lower power level to keep the temperature more even. This can create additional energy savings on top of more efficient schedules and might add an additional 5% savings. This approach is referred to as modulating control.
As you can see from these diagrams with traditional on/off control the boiler runs at 100% until it reaches the desired temperature and then turns off, it however will overshoot the desired temperature as the heat is released by your radiators, it will then undershoot as the radiators cool down whilst waiting for the boiler to heat them up again. With a modulating control the amount of power (heat) the boiler produces is reduced as it approaches the desired temperature meaning it does not overshoot and instead reduces power to the level needed to keep it at that level.
Now in order to benefit from this more efficient modulating control you need both a smart thermostat that supports this feature and a boiler that also supports this feature. As mentioned the Nest Learning Thermostat v3 supports this, as do various Honeywell Evohome smart thermostats and so does the Tado Thermostat. There is an official open standard called OpenTherm which was original devised by Honeywell and later released as an open standard. This OpenTherm standard is supported by the Nest v3, Evohome and Tado amongst others. Even Drayton offer an OpenTherm compatible thermostat. There seems to be also another alternative standard generally referred to as eBus aka energy Bus, however only Tado support this as well as OpenTherm. (It is not supported by Nest or Evohome.)
Unfortunately here in the UK many of the various boiler manufacturers are proving very unhelpful. Most do now provide at least some boiler models that support modulating control as well as the traditional on/off control but only support modulating control with their own proprietary thermostats. Whilst they do not say so it seems their proprietary thermostats are using the eBus standard. As such this precludes using the Nest etc. in modulating mode although the Tado would still work.
What is even more annoying is that Vaillant a leading brand actually sell their boiler with OpenTherm support in the Netherlands, they do this by selling their own eBus to OpenTherm bridge module - VR33 to convert their eBus signals to OpenTherm signals. However Vaillant do not sell this module in the UK and if you get one and have it fitted even by an official Vaillant engineer they will invalidate the warranty on your entire Vaillant system. Remember this is an official Vaillant part and one that does work on UK boilers.
Worcester-Bosch are a little better, they have their own proprietary variation on eBus called EMS. Bosch own several brands throughout Europe, Worcester-Bosch in the UK, Nefit in the Netherlands, Junkers in I believe Portugal and of course Bosch in Germany. Since OpenTherm is very common in the Netherlands Nefit have produced a module to convert Bosch's EMS to OpenTherm. See - this. However there is also another interesting possibility. Worcester-Bosch also sell an adapter to allow connecting their EasyControl smart thermostat which speaks only their proprietary EMS protocol to OpenTherm boilers, it should also work with their older Wave smart thermostat. This adapter however is described as bi-directional which might mean it can also do the reverse and allow an OpenTherm smart thermostat to connect to a Worcester-Bosch EMS boiler. The Nefit module is not sold in the UK but the Worcester-Bosch adapter is officially available.
Both OpenTherm and eBus have additional benefits, they can provide error diagnostics to your smart thermostat so that you can be far better informed of either a potential problem or an actual fault, they also allow a smart thermostat to not only control the central heating but also to control your hot water scheduling as well. I have not seen anything official but Tado at least suggest that the eBus standard is technically superior to the much older OpenTherm standard. I also get the impression eBus maybe a purely European standard at this point - hence the fact Nest and Honeywell aka Evohome do not support it.
To summarise -
So either you have to run your boiler in old fashioned dumber on/off mode, or get the Tado Thermostat or accept being locked in to the boiler manufacturers own proprietary 'smart' thermostat.
Note: If your Vaillant boiler is out of warranty you could consider using that VR33 module.
A list of potentially OpenTherm compatible boilers is available here.
Originally such smart thermostats whilst indeed having various additional smartness actually worked in the same way as original dumb thermostats in that they basically sent a signal to the boiler asking for heat or saying stop I am warm enough, i.e. a basic on or off control. This approach involves the boiler either running at 100% power or 0% power i.e. fully on or fully off.
However newer models of smart thermostat including the aforementioned Nest Learning Thermostat v3 also support an alternative approach which allows setting a target temperature for the boiler so that the boiler can adjust the level it needs to run at to keep at that target temperature. This means that instead of constantly starting and stopping the boiler it will run continuously at a lower power level to keep the temperature more even. This can create additional energy savings on top of more efficient schedules and might add an additional 5% savings. This approach is referred to as modulating control.
 |
| Figure 1 - Traditional on/off control |
 |
| Figure 2 - Modulating control |
As you can see from these diagrams with traditional on/off control the boiler runs at 100% until it reaches the desired temperature and then turns off, it however will overshoot the desired temperature as the heat is released by your radiators, it will then undershoot as the radiators cool down whilst waiting for the boiler to heat them up again. With a modulating control the amount of power (heat) the boiler produces is reduced as it approaches the desired temperature meaning it does not overshoot and instead reduces power to the level needed to keep it at that level.
Now in order to benefit from this more efficient modulating control you need both a smart thermostat that supports this feature and a boiler that also supports this feature. As mentioned the Nest Learning Thermostat v3 supports this, as do various Honeywell Evohome smart thermostats and so does the Tado Thermostat. There is an official open standard called OpenTherm which was original devised by Honeywell and later released as an open standard. This OpenTherm standard is supported by the Nest v3, Evohome and Tado amongst others. Even Drayton offer an OpenTherm compatible thermostat. There seems to be also another alternative standard generally referred to as eBus aka energy Bus, however only Tado support this as well as OpenTherm. (It is not supported by Nest or Evohome.)
Unfortunately here in the UK many of the various boiler manufacturers are proving very unhelpful. Most do now provide at least some boiler models that support modulating control as well as the traditional on/off control but only support modulating control with their own proprietary thermostats. Whilst they do not say so it seems their proprietary thermostats are using the eBus standard. As such this precludes using the Nest etc. in modulating mode although the Tado would still work.
What is even more annoying is that Vaillant a leading brand actually sell their boiler with OpenTherm support in the Netherlands, they do this by selling their own eBus to OpenTherm bridge module - VR33 to convert their eBus signals to OpenTherm signals. However Vaillant do not sell this module in the UK and if you get one and have it fitted even by an official Vaillant engineer they will invalidate the warranty on your entire Vaillant system. Remember this is an official Vaillant part and one that does work on UK boilers.
Worcester-Bosch are a little better, they have their own proprietary variation on eBus called EMS. Bosch own several brands throughout Europe, Worcester-Bosch in the UK, Nefit in the Netherlands, Junkers in I believe Portugal and of course Bosch in Germany. Since OpenTherm is very common in the Netherlands Nefit have produced a module to convert Bosch's EMS to OpenTherm. See - this. However there is also another interesting possibility. Worcester-Bosch also sell an adapter to allow connecting their EasyControl smart thermostat which speaks only their proprietary EMS protocol to OpenTherm boilers, it should also work with their older Wave smart thermostat. This adapter however is described as bi-directional which might mean it can also do the reverse and allow an OpenTherm smart thermostat to connect to a Worcester-Bosch EMS boiler. The Nefit module is not sold in the UK but the Worcester-Bosch adapter is officially available.
Both OpenTherm and eBus have additional benefits, they can provide error diagnostics to your smart thermostat so that you can be far better informed of either a potential problem or an actual fault, they also allow a smart thermostat to not only control the central heating but also to control your hot water scheduling as well. I have not seen anything official but Tado at least suggest that the eBus standard is technically superior to the much older OpenTherm standard. I also get the impression eBus maybe a purely European standard at this point - hence the fact Nest and Honeywell aka Evohome do not support it.
To summarise -
- UK boiler manufacturers try and lock you in to their own proprietary 'smart' thermostat
- Most UK boilers do not support OpenTherm and do not say they support eBus (but in reality many do)
- Vaillant who do at least in the Netherlands support OpenTherm are deliberately refusing to do this in the UK and even go as far as punishing anyone who gets their own OpenTherm bridge module
So either you have to run your boiler in old fashioned dumber on/off mode, or get the Tado Thermostat or accept being locked in to the boiler manufacturers own proprietary 'smart' thermostat.
Note: If your Vaillant boiler is out of warranty you could consider using that VR33 module.
A list of potentially OpenTherm compatible boilers is available here.
Sunday 5 August 2018
Extracting EFI firmware for standalone install in High Sierra
When Apple released High Sierra they included built-in to the Install macOS High Sierra.app an EFI firmware updater as well. This was mainly to add additional support for booting from APFS volumes but also as part of a plan to continuously check that the Mac firmware had not been infected by malware and also as a way of adding potentially regular EFI firmware updates.
Unfortunately since this firmware update was not available separately and because it could not be automated as part of a traditional disk image based imaging process e.g. DeployStudio this caused some difficulties for Mac admins. As a result Mac admins quickly created a workaround in the form of 'extracting' the EFI firmware updater from a standard Install macOS High Sierra.app so it could be run separately. This indeed worked fine for High Sierra 10.13.1 but Apple changed things again in subsequent versions at least in 10.13.3, I don't have a copy of 10.13.2 to check and the suggested approach then became broken.
Note: Because correctly deploying High Sierra with the built-in firmware updates is effectively impossible with a disk imaging approach Apple say you should instead use the DEP - Device Enrolment Program approach instead. This has its own complexities hence why some Mac admins came up with the original means of extracting the EFI firmware updater.
This script gets round the change introduced in 10.13.3 once more and works for 10.13.6 and I would expect also 10.13.3 to 10.13.5 inclusive. Basically it includes a copy of a sub-script that is no longer included by Apple as of 10.13.3 and later. I also use the munkipkg tool rather than pkgutil so you will need to download munkipkg from here https://github.com/munki/munki-pkg and install it in /usr/local/bin
It should be noted that the change that Apple made in presumably 10.13.3 was to add further firmware updaters to the same mechanism in addition to the original EFI firmware update that is of most concern to Mac admins. Some of the other additional updaters cover SSD firmware and USB-C firmware. It is to me at least, impossible to tell if my 'fixed' version happens to install those as well, I would suspect not.
Therefore as Apple say you should not do this. However at your own risk here is my fixed script.
https://github.com/jelockwood/extract-firmware
If the script completes successfully the custom built installer package is available at /tmp/FirmwareUpddateStandalone/FirmwareUpdateStandalone.pkg
You may want to also check your Mac to see if it has the correct EFI firmware, this is most easily done by downloading and running this free tool - https://github.com/duo-labs/EFIgy-GUI
Unfortunately since this firmware update was not available separately and because it could not be automated as part of a traditional disk image based imaging process e.g. DeployStudio this caused some difficulties for Mac admins. As a result Mac admins quickly created a workaround in the form of 'extracting' the EFI firmware updater from a standard Install macOS High Sierra.app so it could be run separately. This indeed worked fine for High Sierra 10.13.1 but Apple changed things again in subsequent versions at least in 10.13.3, I don't have a copy of 10.13.2 to check and the suggested approach then became broken.
Note: Because correctly deploying High Sierra with the built-in firmware updates is effectively impossible with a disk imaging approach Apple say you should instead use the DEP - Device Enrolment Program approach instead. This has its own complexities hence why some Mac admins came up with the original means of extracting the EFI firmware updater.
This script gets round the change introduced in 10.13.3 once more and works for 10.13.6 and I would expect also 10.13.3 to 10.13.5 inclusive. Basically it includes a copy of a sub-script that is no longer included by Apple as of 10.13.3 and later. I also use the munkipkg tool rather than pkgutil so you will need to download munkipkg from here https://github.com/munki/munki-pkg and install it in /usr/local/bin
It should be noted that the change that Apple made in presumably 10.13.3 was to add further firmware updaters to the same mechanism in addition to the original EFI firmware update that is of most concern to Mac admins. Some of the other additional updaters cover SSD firmware and USB-C firmware. It is to me at least, impossible to tell if my 'fixed' version happens to install those as well, I would suspect not.
Therefore as Apple say you should not do this. However at your own risk here is my fixed script.
https://github.com/jelockwood/extract-firmware
If the script completes successfully the custom built installer package is available at /tmp/FirmwareUpddateStandalone/FirmwareUpdateStandalone.pkg
You may want to also check your Mac to see if it has the correct EFI firmware, this is most easily done by downloading and running this free tool - https://github.com/duo-labs/EFIgy-GUI
Nest Hello, Skybell and Ring - UK smart doorbell installations
As you will know if you have come looking for this article these are the three leading smart door bells all of which are US products. This unfortunately means they are more complex to install in the UK and Europe due to the differences between normal wired doorbells in the US and the EU.
In the UK and Europe doorbells typically use an 8V AC transformer like this -
However the US typically uses a 16V AC transformer like this -
The above is a 16V AC transformer but is for 110V not the European standard of 220V. The reason the US can get away with a lethal looking transformer like this is that it is converting from 110V and this is less dangerous than the European 220V.
So, these smart door bells are designed to use a higher voltage than a typical UK/EU wired doorbell and this means we cannot unless we are very lucky use an existing door bell transformer. As I mentioned typically UK/EU wired doorbells come with an 8V transformer as shown, however 12V AC transformers are also widely available and this difference is usually still within the bounds an 8V doorbell will accept in fact some Friedland wired doorbells will accept 16V AC.
First what do each of the three smart doorbell brands say they actually need?
As we can see from the above table the most common requirement is for 16V AC which happens to be the hardest to find in the UK.
As far as I can tell Nest, Skybell and Ring do the following.
So Nest are the least helpful for DIYers. Considering they did a very good job making UK/EU versions of their Thermostat and Protect fire alarm this is very surprising. Skybell's European agent has a solution but it is only suitable for Skybell being only 12V. Ring have themselves completely solved the problem but as I mentioned created a new one.
Whilst a typical UK/EU wired doorbell as mentioned uses 8V AC it can cope with 12V AC or even 16V AC as this is still low voltage. However I consider it unlikely it would cope with 24V AC which after all is three times the more typical 8V AC. Ring acknowledge this and their solution requires you to stop using the wired door chime and to use instead Ring's own wireless ringer. As far as I am aware neither Nest or Skybell support wireless ringers.
In my own case I planned to buy a Skybell Trim Plus and in theory an easily obtainable 12V transformer would do the job but I wanted to have the most flexible solution so I myself wanted to get a transformer that could do ideally 12V, 16V and 24V - just in case. There are a few multi voltage bell transformers doing 8V, 12V and 24V but ones doing 16V as well as 12 and 24 are extremely rare. Fortunately I did manage to find one. See - http://protekuk.co.uk/24V-8VA-2-Module-Bell-Transformer-BT8-24
Whilst as shown above all three brands claim to support using 16V AC I have seen reports of problems doing this with the Ring Pro such as losing connectivity and their own transformer included as standard is a 24V one suggesting 16V might indeed not be sufficient for the Ring Pro. See - https://support.ring.com/hc/en-us/articles/115000148786-Ring-Video-Doorbell-Pro-European-Version
Interestingly one can see from the above Ring article that it has four screw holes at the top like the above Protek model. This might suggest it does support additional voltages to the 24V but the picture is too low resolution to read the text on the Ring transformer to confirm this.
Note: The various plugin transformers listed for smart doorbells might, indeed should work for the smart doorbell but do not support using an existing wired chime.
So I have bought the Protek transformer and fitted it with my existing doorbell and chime and wired it to use 16V AC. This is working fine. I then tried to order to the Skybell Trim Plus from the European agent - https://www.topsolute.com/ only to find they are temporarily out of stock.
In the UK and Europe doorbells typically use an 8V AC transformer like this -
However the US typically uses a 16V AC transformer like this -
So, these smart door bells are designed to use a higher voltage than a typical UK/EU wired doorbell and this means we cannot unless we are very lucky use an existing door bell transformer. As I mentioned typically UK/EU wired doorbells come with an 8V transformer as shown, however 12V AC transformers are also widely available and this difference is usually still within the bounds an 8V doorbell will accept in fact some Friedland wired doorbells will accept 16V AC.
First what do each of the three smart doorbell brands say they actually need?
|
Nest Hello
|
Skybell HD
|
Skybell Trim Plus
|
Ring 2
|
Ring Pro
|
|
16-24V AC
|
10-36V AC
|
10-36V AC
|
Battery pack
|
16-24V AC
|
As far as I can tell Nest, Skybell and Ring do the following.
- Nest tell you to find your own 16V transformer or to get a professional installer - and they offer to include professional installation for you
- Skybell have a European agent who sells 12V transformers
- Ring include in the box in Europe a 24V transformer as standard - although this creates a new problem as you will see
So Nest are the least helpful for DIYers. Considering they did a very good job making UK/EU versions of their Thermostat and Protect fire alarm this is very surprising. Skybell's European agent has a solution but it is only suitable for Skybell being only 12V. Ring have themselves completely solved the problem but as I mentioned created a new one.
Whilst a typical UK/EU wired doorbell as mentioned uses 8V AC it can cope with 12V AC or even 16V AC as this is still low voltage. However I consider it unlikely it would cope with 24V AC which after all is three times the more typical 8V AC. Ring acknowledge this and their solution requires you to stop using the wired door chime and to use instead Ring's own wireless ringer. As far as I am aware neither Nest or Skybell support wireless ringers.
In my own case I planned to buy a Skybell Trim Plus and in theory an easily obtainable 12V transformer would do the job but I wanted to have the most flexible solution so I myself wanted to get a transformer that could do ideally 12V, 16V and 24V - just in case. There are a few multi voltage bell transformers doing 8V, 12V and 24V but ones doing 16V as well as 12 and 24 are extremely rare. Fortunately I did manage to find one. See - http://protekuk.co.uk/24V-8VA-2-Module-Bell-Transformer-BT8-24
Whilst as shown above all three brands claim to support using 16V AC I have seen reports of problems doing this with the Ring Pro such as losing connectivity and their own transformer included as standard is a 24V one suggesting 16V might indeed not be sufficient for the Ring Pro. See - https://support.ring.com/hc/en-us/articles/115000148786-Ring-Video-Doorbell-Pro-European-Version
Interestingly one can see from the above Ring article that it has four screw holes at the top like the above Protek model. This might suggest it does support additional voltages to the 24V but the picture is too low resolution to read the text on the Ring transformer to confirm this.
Note: The various plugin transformers listed for smart doorbells might, indeed should work for the smart doorbell but do not support using an existing wired chime.
So I have bought the Protek transformer and fitted it with my existing doorbell and chime and wired it to use 16V AC. This is working fine. I then tried to order to the Skybell Trim Plus from the European agent - https://www.topsolute.com/ only to find they are temporarily out of stock.
Monday 9 July 2018
JAMF JSS and checking Mac firmware versions
JAMF's JSS has a built-in capability to show what version of firmware a Mac has but this as of itself does not tell you if the firmware is too old, the correct version or even a newer than expected version.
With support for APFS boot drives in High Sierra and later requiring some Macs to have their firmware updated this is more of an issue than it used to be. Sadly Apple no longer provide standalone firmware updaters meaning there is no official Apple source of information to check what firmware version a Mac should be running.
Historically you in theory used to be able to ensure your Macs firmware was up-to-date simply by regularly running Apple's Software Update check and if there was a firmware update you would be informed and could run it.
Worryingly as per this article https://duo.com/assets/ebooks/Duo-Labs-The-Apple-of-Your-EFI.pdf many Macs even if supposedly covered by Apple firmware updates via the Software Update mechanism still failed to get installed the correct version.
Duo-Labs therefore wrote their own tool to check whether a Mac has the correct firmware version. See - https://github.com/duo-labs/EFIgy both a GUI version you can run locally and a command line version are available.
The purpose of this article is to describe how you can use the command line version of the EFIgy tool with JAMF to audit all your Macs and thereby find out whether any of your Macs has an out-of-date version of firmware.
Note: Since Apple no longer provide standalone firmware updaters the only official way to get newer firmware versions installed now is to either install the latest High Sierra version or the (at the time of writing) Mojave beta version. (Yes Mojave has for at least the Mac Pro 2010/2012 models even newer firmware than that included with the High Sierra installer.)
In order to get a result from EFIgy we need to use the command line version and have the result returned as an extension attribute to JSS. The following issues needed to be solved in order to achieve this.
In order of what needs to be done, here is how I solved these issues.
Note: This means you cannot use the (current) standard version of EFIgyLite_cli.py you must you my modified version. I have however submitted an enhancement request to the original authors and provided them with details of the change I made to achieve this.
Note: As an aside, whilst creating this solution I discovered that JSS runs shell scripts on client machines from working directory of /private/var/<nameofjamfaccount>/
Here is how you need to configure the Extension Attribute in JSS.
Here is the script - including the encoded EFIgyLite_cli.py and cacert.pem files. If your being paranoid - and you always should, you should either run this first on a test Mac or otherwise decode the encoded files and examine their content to reassure yourself they are not malicious.
firmware_checker.sh
For the more adventurous amongst you, some people have found a way to extract the firmware installers from a High Sierra installer app to produce a standalone firmware installer package file. I have used this approach myself on a few Macs. See https://github.com/grahamgilbert/imagr/wiki/High-Sierra-Notes
With support for APFS boot drives in High Sierra and later requiring some Macs to have their firmware updated this is more of an issue than it used to be. Sadly Apple no longer provide standalone firmware updaters meaning there is no official Apple source of information to check what firmware version a Mac should be running.
Historically you in theory used to be able to ensure your Macs firmware was up-to-date simply by regularly running Apple's Software Update check and if there was a firmware update you would be informed and could run it.
Worryingly as per this article https://duo.com/assets/ebooks/Duo-Labs-The-Apple-of-Your-EFI.pdf many Macs even if supposedly covered by Apple firmware updates via the Software Update mechanism still failed to get installed the correct version.
Duo-Labs therefore wrote their own tool to check whether a Mac has the correct firmware version. See - https://github.com/duo-labs/EFIgy both a GUI version you can run locally and a command line version are available.
The purpose of this article is to describe how you can use the command line version of the EFIgy tool with JAMF to audit all your Macs and thereby find out whether any of your Macs has an out-of-date version of firmware.
Note: Since Apple no longer provide standalone firmware updaters the only official way to get newer firmware versions installed now is to either install the latest High Sierra version or the (at the time of writing) Mojave beta version. (Yes Mojave has for at least the Mac Pro 2010/2012 models even newer firmware than that included with the High Sierra installer.)
In order to get a result from EFIgy we need to use the command line version and have the result returned as an extension attribute to JSS. The following issues needed to be solved in order to achieve this.
- EFIgyLite_cli.py as its name suggests is a python script, it is more typical to use shell scripts to populate Extension Attributes but I suspect it would in theory be possible with a python script as it obeys the same shebang mechanism as a shell script. However as it turns out I needed to front-end it with a standard shell script so the fact it is a python script became immaterial.
- EFIgyLite_cli.py either needs the python certifi module to be installed or a cacert.pem file to be in the same location as the python script.
- EFIgyLite_cli.py as standard requires human interaction to answer a question with a yes or no answer.
- The result from EFIgyLite_cli.py is rather verbose, my current solution condenses this significantly down to a single line but it could in theory be further abbreviated down to one of 'up2date', 'outofdate', 'newer', 'model_unknown' or 'build_unknown'.
In order of what needs to be done, here is how I solved these issues.
- I modified the standard EFIgyLite_cli.py script to add an additional command line parameter -a which when used will automate the running of the script - in other words if you include this parameter it will not ask you the Y/N question but will run as if you said Y. (Fixes issue 3)
- I used my previously discussed solution on how to use the shell script CAT EOF feature to include multiple files, via this I encoded both the EFIgyLite_cli.py and the cacert.pem files inside my shell script and my script will then automatically 'restore' them in to a temporary folder. My script will then run the python script from that temporary folder. (Fixes issues 1 & 2)
- My shell script then takes the result returned by the python EFIgyLite_cli.py script and extracts just the single line that contains the desired result. (Fixes issue 4)
Note: This means you cannot use the (current) standard version of EFIgyLite_cli.py you must you my modified version. I have however submitted an enhancement request to the original authors and provided them with details of the change I made to achieve this.
Note: As an aside, whilst creating this solution I discovered that JSS runs shell scripts on client machines from working directory of /private/var/<nameofjamfaccount>/
Here is how you need to configure the Extension Attribute in JSS.
Here is the script - including the encoded EFIgyLite_cli.py and cacert.pem files. If your being paranoid - and you always should, you should either run this first on a test Mac or otherwise decode the encoded files and examine their content to reassure yourself they are not malicious.
firmware_checker.sh
For the more adventurous amongst you, some people have found a way to extract the firmware installers from a High Sierra installer app to produce a standalone firmware installer package file. I have used this approach myself on a few Macs. See https://github.com/grahamgilbert/imagr/wiki/High-Sierra-Notes
Wednesday 6 June 2018
Me and Apple's DHCP Server - a long history…
I have had a long and involved relationship with Apple with regards to their DHCP support.
I have in the past successfully persuaded Apple to :-
I also wrote myself a GUI tool to make it far easier for people to generate the encoded values Apple required for DHCP option codes in their bootpd.plist config file. See http://jelockwood.blogspot.com/2013/06/dhcp-server-on-os-x-server.html
This tool still works by the way.
However the one thing I did not succeed in persuading Apple to do was adding an IPv6 capable DHCP server. Apple's DHCP server is based on an extremely modified bootpd package which never was able to support IPv6.
With the recent(ish) announcement from Apple of yet more services going to be removed from their Server.app including the DHCP server it is clear that IPv6 is never going to be added. It also means my tool will no longer have a purpose.
:'(
I have in the past successfully persuaded Apple to :-
- Add support to macOS X aka OS X aka macOS to be able to use WPAD i.e. Web Proxy Auto Discovery which Apple calls 'Auto Proxy Discovery'
- and add support to their DHCP server for DHCP option codes as used by VoIP handsets and other network equipment
I also wrote myself a GUI tool to make it far easier for people to generate the encoded values Apple required for DHCP option codes in their bootpd.plist config file. See http://jelockwood.blogspot.com/2013/06/dhcp-server-on-os-x-server.html
This tool still works by the way.
However the one thing I did not succeed in persuading Apple to do was adding an IPv6 capable DHCP server. Apple's DHCP server is based on an extremely modified bootpd package which never was able to support IPv6.
With the recent(ish) announcement from Apple of yet more services going to be removed from their Server.app including the DHCP server it is clear that IPv6 is never going to be added. It also means my tool will no longer have a purpose.
:'(
Using Cat << EOF in a shell script to restore binary files
Unix/Linux/Mac shell scripts support what is commonly called 'Cat << EOF' whereby an entire file can be included in a shell script and 'restored' to a separate file stored on the drive.
As should be obvious this derives from the fact that at the command line you can do a command such as -
cat /etc/hosts > newfile.txt
In this scenario we want to be able to use a shell script to create the desired file. You might think that this could be simply achieved as follows -
#!/bin/sh
echo "This is the content of a file" > newfile.txt
exit
and yes this to some extent is possible, however if your file is going to contain multiple lines - some of which might be blank lines and some might contain commands or special characters this soon becomes effectively impossible with a simple echo command. Therefore shell scripts can use the Cat << EOF feature instead. Here is a simple example -
#!/bin/sh
cat <<- 'EOF' > newfile.txt
This is the content of a file
This is more content
Yet more content still
EOF
exit
You should now be able to see where the reference to Cat << EOF comes from, however the official term is a 'heredoc', see https://en.wikipedia.org/wiki/Here_document
This approach is commonly used to include and generate a single text file as shown above. However what if you want to do something more complicated? What if you want to either do an entire directory, or nested set of directories/files or binary files? Is this even possible?
The answer fortunately is yes. To do this the easiest way I have found is as follows -
tar -cv nameofdirectory | openssl base64 -e
This uses the standard tar command to convert the specified directory (or binary files) and then pipes the result to openssl, openssl is then told to encode the input in to base64 format, base64 is an ASCII i.e. text encoded version of the binary data. In this case the result is then displayed to standard output in your terminal and can be copy/pasted in to your shell script in the Cat << EOF section.
Here therefore is an example shell script which would 'restore' a file
#!/bin/sh
cd /where/you/want/to/restore
/usr/bin/openssl base64 -d << EOF | tar xf -
exit
Whilst the command format is quite different it should be clear it is using the same openssl command to decode the base64 text and then sending it to the tar command to be 'restored'.
So this approach allows storing and restoring either a single or multiple binaries files or an entire hierarchy of directories and text or binary files. This approach can even cope with restoring an Apple disk image or an ISO image and after you restore it could then use another command to mount the image and copy or run something from that image.
As should be obvious this derives from the fact that at the command line you can do a command such as -
cat /etc/hosts > newfile.txt
In this scenario we want to be able to use a shell script to create the desired file. You might think that this could be simply achieved as follows -
#!/bin/sh
echo "This is the content of a file" > newfile.txt
exit
and yes this to some extent is possible, however if your file is going to contain multiple lines - some of which might be blank lines and some might contain commands or special characters this soon becomes effectively impossible with a simple echo command. Therefore shell scripts can use the Cat << EOF feature instead. Here is a simple example -
#!/bin/sh
cat <<- 'EOF' > newfile.txt
This is the content of a file
This is more content
Yet more content still
EOF
exit
You should now be able to see where the reference to Cat << EOF comes from, however the official term is a 'heredoc', see https://en.wikipedia.org/wiki/Here_document
This approach is commonly used to include and generate a single text file as shown above. However what if you want to do something more complicated? What if you want to either do an entire directory, or nested set of directories/files or binary files? Is this even possible?
The answer fortunately is yes. To do this the easiest way I have found is as follows -
tar -cv nameofdirectory | openssl base64 -e
This uses the standard tar command to convert the specified directory (or binary files) and then pipes the result to openssl, openssl is then told to encode the input in to base64 format, base64 is an ASCII i.e. text encoded version of the binary data. In this case the result is then displayed to standard output in your terminal and can be copy/pasted in to your shell script in the Cat << EOF section.
Here therefore is an example shell script which would 'restore' a file
#!/bin/sh
cd /where/you/want/to/restore
/usr/bin/openssl base64 -d << EOF | tar xf -
dGVzdC50eHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADAwMDY0NCAAMDAwNzY3IAAwMDAwMjQgADAwMDAwMDAwMDA1IDEzMzA1NzY0
MzUzIDAxNDUyNQAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMGpvaG4ubG9ja3dvb2QAAAAAAAAAAAAA
AAAAAAAAAAAAc3RhZmYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAg
ADAwMDAwMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXN0CgAAAAAAAAAAAAAA
many lines deleted for the sake of readability
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
EOFexit
Whilst the command format is quite different it should be clear it is using the same openssl command to decode the base64 text and then sending it to the tar command to be 'restored'.
So this approach allows storing and restoring either a single or multiple binaries files or an entire hierarchy of directories and text or binary files. This approach can even cope with restoring an Apple disk image or an ISO image and after you restore it could then use another command to mount the image and copy or run something from that image.
Subscribe to:
Posts (Atom)