The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.
Here’s an excerpt:
The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 530,000 times in 2013. If it were an exhibit at the Louvre Museum, it would take about 23 days for that many people to see it.
If you want others to be able to temporarily use your computer, but you don’t want to create an account for each user, Mac OS X allows you to create a guest account. This guest account allows a person to log in to the Mac without entering a password, but the account type has the following limitations:
- Guest users can’t make changes to other user accounts.
- Guest users can’t change setting on the computer.
- Guest users can’t log in remotely.
- Files created by guest users are deleted when the user logs out. As part of this, a temporary home folder is created for the guest’s files but this folder and its contents are deleted when the user logs out.
By default, OS X only allows the creation of a single guest account with the name of Guest. That said, it is possible to create custom guest accounts with names that are different from Guest. This would allow Mac admins to create multiple guest accounts if needed. See below the jump for more details.
A change that occurred between Mountain Lion and Mavericks is that it’s no longer possible to add additional users with fdesetup by using a non-enabled admin user’s credentials. Instead, you must use either a previously-enabled user’s credentials or use a personal recovery key (aka an individual recovery key) to authorize adding a user account with fdesetup add.
The recovery key option is specifically for the personal recovery key; there is not an option in fdesetup add to use the institutional recovery recovery. This is an issue for IT shops that are using fdesetup enable with the -defer option in combination with an institutional recovery key because the Mavericks way to authorize additional accounts depends on an enabled user’s password (which in this case would be an end-user’s password) or a personal recovery key (which doesn’t exist.)
There is a way to fix this in a roundabout way, by leveraging the ability of fdesetup in Mavericks to generate a new personal recovery key using fdesetup changerecovery. fdesetup changerecovery allows the use of an institutional recovery keychain to authorize the generation of a new personal recovery key. To do this, run the following command:
sudo fdesetup changerecovery -personal -key /path/to/keychain_with_both_private_and_public_recovery_keys_inside.keychain
You’ll be prompted for the password to unlock the institutional recovery keychain. Once that password is provided, a new personal recovery key will be generated.
To verify that this new recovery key is valid, run the following command:
sudo fdesetup validaterecovery
If the new personal recovery key is valid, you should receive a result of “true”.
fdesetup can also export the recovery key to a plist file by using the -outputplist flag. To generate a new personal recovery key and have it exported to a plist, run the following command:
sudo fdesetup changerecovery -personal -key /path/to/FileVaultMaster.keychain -outputplist > /path/to/new_recovery_key.plist
The plist should contain information similar to what’s shown below and include the new personal recovery key information in the RecoveryKey plist value.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Change</key> <true/> <key>EnabledDate</key> <string>2013-12-20 13:51:58 -0500</string> <key>HardwareUUID</key> <string>00000000-0000-1000-8000-000C2991B2C4</string> <key>HasMasterKeychain</key> <true/> <key>RecoveryKey</key> <string>MLZA-NZTC-MVLM-O82Q-Y8TW-F8FX</string> <key>SerialNumber</key> <string>VM401BlpPKGn</string> </dict> </plist>
fdesetup changerecovery doesn’t currently include a way to utilize the institutional recovery keychain without requiring a password to be entered, but it is possible to automate the password entry process using an expect script or other means. As an example, I’ve written an expect script which automates running the fdesetup changerecovery process described above to generate a new personal recovery key and export it to a plist.
With Apple’s release of OS X 10.9.1, it looks like the automated FV 2 unlock process that Apple built into the Mavericks install process has been included with OS X updates. To illustrate, I’ve made a video showing the following process:
- Logging into a FileVault 2 encrypted Mac
- Verifying that I was on 10.9.0 and encrypted
- Opening the Mac App Store and installing the 10.9.1 update
- Mac reboots and bypasses the FileVault 2 pre-boot login screen
- Mac automatically logs into my account
Note: The video has been edited to artificially reduce the amount of time the install process takes to run. Run time of the pre-edited video was 14 minutes.
How is the pre-boot login screen bypassed?
During the upgrade process, an unlock key is being put into the SMC by the update process to unlock the encrypted volume at boot. The reboot process then automatically clears the key from the SMC. This process is similar to how fdesetup authrestart works, except that the user is not being prompted to authorize it.
How is the Mac automatically logging into my account following the update?
This question is unresolved at this time and this behavior is worrisome to me. Walking away at the wrong moment may give an opportunity for someone to get physical access to my Mac without my knowledge.
The length of that window of vulnerability is going to be determined by when the screensaver kicks in, as enabling FileVault 2 will also set your Mac to require your account’s password before exiting the screensaver.
Do you have information about how the Mac is automatically logging into an account after an update? Please let me know in the comments.
Before IRC, AOL Instant Messenger and Apple’s Messages, there was talk. talk is a Unix text chat program, allowing messaging between users of Unix-based systems. While it’s been largely superseded by other chat applications, it’s still included with OS X Mavericks as the ntalk service.
Setting up a talk server on OS X
To start the talk server on OS X, run the following command to start the ntalk service:
sudo launchctl load -w /System/Library/LaunchDaemons/ntalk.plist
To stop a running talk server, run the following command to stop the ntalk service:
sudo launchctl unload -w /System/Library/LaunchDaemons/ntalk.plist
It’s pretty straightforward to use talk. To talk to another user logged in on the same host, use this command:
To talk to a user on another host, use this command:
Once communication is established, the two parties may type simultaneously, with their output appearing in separate windows. One thing to know is that output is reflected live to both sides; every character typed (typos and all) will be visible.
Reprint screen – Typing control-L will cause the screen to be reprinted.
Clear screen – Typing control-D will clear both parts of your screen to be cleared, while the control-D character will be sent to the remote side (and just displayed by this talk client).
Exit current talk session – To exit, type control-C.
For more information on talk, please see the man page:
As part of a project to assess the deployment options for National Instruments’ LabVIEW 2013 Pro, I was asked to see if I could deploy it through Casper’s Self Service. After some work, I was able to repackage the installer in a way that deploys smoothly. In the process, I saw a number of ways that this particular installer went against The Commandments of Packaging. See below the jump for details.
One of my users ran into an issue recently when launching Microsoft Lync. When the Lync application logged into the Lync server, a Microsoft Lync wants to use OC_KeyContainer_username@company.com. Please enter the keychain password prompt appeared.
The curious thing was that the keychain prompt would not accept the user’s current login password. When I checked, the user’s login keychain was unlocked and using the current password, so it didn’t appear to be caused by the login keychain password issues that I normally deal with.
After some research, I was able to find the answer and get this issue fixed. See below the jump for the details.