The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.
Here’s an excerpt:
The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 1,500,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 64 days for that many people to see it.
For the first time since fdesetup‘s initial release in OS X Mountain Lion 10.8.x, Apple has not added new features to fdesetup as part of a new OS release. Instead, fdesetup maintains the same set of features in OS X El Capitan 10.11.x as it had in OS X Yosemite 10.10.x.
This decision may mean that fdesetup, an essential command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption, is now considered by Apple to be a fully-developed toolset for managing FileVault 2.
fdesetup gives Mac administrators the following command-line abilities:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.
After writing a Casper Extension Attribute script to report on the status of System Integrity Protection, I realized that I hadn’t accounted for reporting SIP’s custom configurations. These are configurations where SIP is enabled, but one or more of SIP’s protections or restrictions has been disabled. I’ve now updated the script to also report on the following SIP configurations:
- Kext Signing: disabled
- Filesystem Protections: disabled
- NVRAM Protections: disabled
- Debugging Restrictions: disabled
- DTrace Restrictions: disabled
For more details, please see below the jump.
To follow up on Apple’s changing the output of csrutil status when System Integrity Protection (SIP) is disabled, I’ve posted the following Casper extension attribute to my GitHub repo to report on whether SIP is enabled or disabled.
The script has the following functions:
If the Mac is running 10.10.x or earlier
The script reports System Integrity Protection Not Available For and then reports the relevant version of OS X. For example, the script returns the following output on a Mac running OS X 10.10.5:
System Integrity Protection Not Available For 10.10.5
If the Mac is running 10.11.x or later
This script uses csrutil status to check SIP’s status. If System Integrity Protection is disabled, the script returns the following output:
If System Integrity Protection is enabled, the script returns the following output:
For those interested, the script is available on my GitHub repo:
In order to check whether System Integrity Protection (SIP) is enabled or disabled on a Mac running OS X El Capitan, you can use the csrutil command to report on SIP’s current status. For example, to learn if SIP is enabled or disabled, run the following command:
This command can be run without root privileges and will tell you if SIP is on or off.
If SIP is enabled on 10.11.0 or higher, you should receive the following message:
System Integrity Protection: enabled
If SIP is disabled on OS X 10.11.0 or 10.11.1, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.
It appears that Apple has updated the status message on OS X 10.11.2 to make it much more clear when SIP is disabled. On 10.11.2, if SIP is disabled, you now should receive the following message:
System Integrity Protection: disabled
Starting with VMware Fusion 7.x Professional, it’s been possible to transfer virtual machines from VMware Fusion to VMware ESXi. This ability has been improved with VMware Fusion 8.x Professional, but there is a recurring issue with OS X VMs transferred from VMware Fusion to VMware ESXi 6.x. The symptoms normally look like this:
1. An OS X VM running OS X 10.10.x or 10.11.x is created in VMware Fusion 8.x Professional
2. The hardware version of the OS X VM is changed to Hardware Version 11, to allow compatibility with ESXi 6.x
3. The VM is transferred successfully to VMware Fusion 8.x Professional to the ESXi 6.x server
4. Following the transfer, the OS X VM is started but does not successfully complete the OS startup process.
The root cause is that there is some OS information which is not transferred successfully along with the VM, but it’s relatively straightforward to fix. For more details, see below the jump.
As part of keeping an eye on my support systems, I’ve been using a script for my Casper servers running on Linux which emails me a status report on a daily basis. I adapted this script from an earlier one I wrote to monitor Tomcat and alert me if Tomcat was having issues. The script tells me a number of things that are useful to know, including the following:
- Free space on all attached drives
- Who’s logged in via SSH or in the console
- Virtual memory statistics
- Current system tasks
- SMB connections information
- Recent entries in the Apache server logs
- Recent entries in the JSS server log
In my case, my Casper servers are hosted on Red Hat Enterprise Linux so I’ve focused this script’s development and testing on compatibility with RHEL-based Linux distributions. That said, nothing in it is RHEL-specific so it should also work on other Linux distributions. For more information, see below the jump.