Tiny Deathstars of Foulness

When you’re regression testing, you frequently just don’t want any delays for scripts unless you intentionally sleep your scripts. By default Safari has an internal delay that I’d totally forgotten about. So if your GUI scripts (yes, I know, yuck) are taking too long to run, check this out and see if it helps:

defaults write WebKitInitialTimedLayoutDelay 0

With a script I was recently working on, this made the thing take about an hour less. Might help for your stuffs, might not.

If not, to undo:

defaults delete WebKitInitialTimedLayoutDelay


February 1st, 2017

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , , , ,

The directory services options in macOS has quietly been going through some slow changes over the past couple of years. Many of the tools we use to manage accounts look similar on the outside but sometimes work a little differently under the hood. Account information is still stored in the /var/db/dslocal/nodes directory. Here, the local directory service pulls files from within directories recursively when accountsd loads. You can still create a second instance of the local directory service by copying the Default directory. For example, here we’ll copy the Default directory node to a directory node called NEW:

sudo cp -prnv /var/db/dslocal/nodes/Default /var/db/dslocal/nodes/NEW

If you killall accountsd then wait (this is slower than doing a killall of DirectoryService was), you’ll then see and be able to use this new directory node:

<code>sudo killall accountsd</code>

This is one way to go about forklifting large collections of accounts from one system to another. The dsmemberutil account can still be used to obtain certain information from accounts. For example, you can check group membership by feeding in a uid with the -u option (here using the uid of 509) and a gid with the -g (here a gid of 10) option:

<code>dsmemberutil checkmembership -u 509 -g 10</code>

Each account still has a uuid. This can be obtained with -u for a user or -g for a group (ids):

<code>dsmemberutil getuuid -u 509</code>

And, you can use dsmemberutil to flush the directory services cache resolver, using the flushcache verb:

<code>dsmemberutil flushcache</code>

The files that comprise accounts can also be viewed and changed manually. Here, we’re going to just look at an account called charles:

<code>sudo defaults read /var/db/dslocal/nodes/Default/users/charles.plist</code>

If we used a tool like defaults, plistbuddy or plutil to manually augment one of these accounts, we’d also need to kill accountsd as we did earlier.

October 3rd, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , ,

When I plug my iPad in, Photos opens. I want it to stop opening when I plug it in. To make it stop, write a disableHotPlug key into as true:

defaults -currentHost write disableHotPlug -bool true

To enable Photos opening when you plug in a device again, just delete the disableHotPlug key:

defaults -currentHost delete disableHotPlug

February 7th, 2016

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security

Tags: , , ,

I’ve written a couple of articles about the Caching service in OS X Server 5 for El Capitan. As of OS X Server 5, the Caching service now caches local copies on the computer running the Caching service of iCloud content. This allows you to cache content once and then have it accessed by multiple devices faster. I’m torn on this option. On the one hand, I love the fact that I can cache things and on the other hand I find it frightening that a random user can cache things I might not want them to cache on behalf of another user. I know, I know, they’re encrypted with a device key. But when you have data on disk, it can always be decrypted. I almost feel like there should be a plist on machines that whitelists allowed caching servers. Maybe I should make a feature request on that.

Either way, as it stands now, I might be disabling this option in larger offices. To do so, I can write an AllowPersonalCaching key into the Config.plist file at /Library/Server/Caching/Config/. The most graceful way to do this is using the serveradmin command, followed by the settings verb and then caching:AllowPersonalCaching option, setting that equals no, as follows:

sudo serveradmin settings caching:AllowPersonalCaching = no

To turn it back on:

sudo serveradmin settings caching:AllowPersonalCaching = yes

This can also be done by dropping a Config.plist file into the correct location for new server installations. I’ll have an article out shortly on doing so, as you’d want to normalize a few options in the file before deploying en masse (e.g. if you have a large contingent of Caching servers to manage.

October 16th, 2015

Posted In: Mac OS X Server

Tags: , , , , , , ,

The tools to automate OS X firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.

Some tricks I’ve picked up with the Mac Firewall/alf scripting:

  • Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper, FileWave, Munki, or Absolute Manage where you might kick yourself out of your session otherwise).
  • Whatever you do, you can always reset things back to defaults by removing the file from /Library/Preferences replacing it with the default plist from /usr/libexec/ApplicationFirewall/
  • Configure global settings, then per-application settings, then enable the firewall. If a remote system, do ;wait; and then enable the first time to make sure everything works before enabling the firewall for good.
  • To debug, use the following command: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”

In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:

/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

To see if block all is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall

The output would be as follows, if successful:

Firewall is set to block all non-essential incoming connections

A couple of global options that can be set. Stealth Mode:

/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

To check if stealth mode is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode

Firewall logging:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on

You can also control the verbosity of logs, using throttled, brief or detail. For example, if you need to troubleshoot some issues, you might set the logging to detail using the following command:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingopt: detail

To start the firewall:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:

/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on

To check if you allow signed apps:

/usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned

This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

To check if an app is blocked:

/usr/libexec/ApplicationFirewall/socketfilterfw –getappblocked /Applications/

This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):

/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/

Once signed, verify the signature:

/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/

Once signed, trust the application using the –add option:

/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/

To see a list of trusted applications. You can do so by using the -l option as follows (the output is pretty ugly and needs to be parsed better):

/usr/libexec/ApplicationFirewall/socketfilterfw -l

If, in the course of your testing, you determine the firewall just isn’t for you, disable it:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off

To sanity check whether it’s started:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Or to manually stop it using launchctl (should start again with a reboot):

launchctl unload /System/Library/LaunchAgents/
launchctl unload /System/Library/LaunchDaemons/

If you disable the firewalll using launchctl, you may need to restart services for them to work again.

July 16th, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

You can customize the number of times that you enter an incorrect password before you get the password hint in the loginwindow on OS X. To do so, use the defaults command to send a RetriesUntilHint integer key into stored at /Library/Preferences using the following command:

defaults write /Library/Preferences/ RetriesUntilHint -integer 10

March 25th, 2014

Posted In: Mac OS X, Mass Deployment

Tags: , , , , ,

Here’s the thing: I’m not very good with computers. So to keep me from hurting myself too badly, I need the simplest interface available that allows me to run multiple applications. But most of the command keys shouldn’t work in this interface and I should only have Finder, file and Help menus.

Luckily for my poor MacBook Airs, Apple thought of people like me when they wrote the Finder and invented something called Simple Finder which makes OS X even simpler than it is by default to use. To enable Simple Finder, just go to Parental controls, enable controls for a user and then check the box for Simple Finder. Or, if you have an entire population of users like me, who simply can’t be trusted with a full operating environment, you can send the InterfaceLevel key with the contents of simple (easy to remember for those of us who resemble said key) to and restart our friendly neighborhood Finder:

defaults write InterfaceLevel simple; killall Finder

Come to think of it, maybe I’m not so awful. Let’s say I want to turn that whole Simple Finder thing right back off. Well, all we have to do is delete that key we created and then restart the Finder:

defaults delete InterfaceLevel; killall Finder

Actually, I am terrible with these things. So much so that it’s not appropriate for me to use a computer. Therefore, just take it away. I’ll be better off using that Samsung with Windows 8 for awhile. At least there, I won’t be able to get any of my apps open or find any of the administrative tools that could damage the computer!

May 17th, 2013

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

For many environments, securing OS X is basically trying to make the computer act more like an iOS device. Some of the easier tasks involve disabling access to certain apps, sandboxing and controlling access to certain features. One of the steps en route to building an iOS-esque environment in OS X is to disable that Go to Folder… option. To do so, set the ProhibitGoToFolder key as true in

defaults write ProhibitGoToFolder -bool true

Then reboot, or kill the Finder:

killall Finder

To undo, set the ProhibitGoToFolder as false:

defaults write ProhibitGoToFolder -bool false

November 11th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , ,

There are a few ways I like to extend my battery life on my MacBook Air. These days, it’s increasingly important to conserve battery life as the transition to Mountain Lion (Mac OS X 10.8) has caused my battery life to spiral into so much of a vortex that I am concerned that my laptop must be shooting raw electricity out of the bottom (which would certainly explain why my hair has a tendency to be perpendicular with the ground when I exit a plane). Ever since moving to Mountain Lion (yes, this includes 10.8.2), I’m lucky to get 3 hours of battery life out of the Mac that used to give me at least 5 hours…

There are a number of tricks that I use to extend battery life. Some are obvious, such as dimming the screen, only using an app at a time, killing off menu items, temporarily stop Spotlight Indexing and killing off LaunchDaemons and LaunchAgents that I’m not using. I even used to used an app called CoolBookController to throttle my processor speeds while flying. But that doesn’t work as of Lion (certainly not in Mountain Lion).

One thing that I’ve been able to do that extends my battery life a little more (maybe an extra half hour) is to kill off Notification Center (I wrote about customizing Notification Center earlier here). I know, I know, it shouldn’t matter… But recently, a customer asked me to script disabling Notification Center. Since I’ve been killing it off with a script, this was a pretty straight forward task. It’s easy to disable Notification Center temporarily using the GUI. Simply click on the Notification Center icon in the menu bar and then scroll up to see the “Show Alerts and Banners” button. Click OFF or ON to toggle it off and on. As you can see, Notification Center then starts back up the next day.

To disable Notification Center from the command line, write a KeepAlive key that is false into the /System/Library/LaunchAgents/ like so:

sudo defaults write /System/Library/LaunchAgents/ KeepAlive -bool false

Then, if you kill NotificationCenter off, it’ll stay off:

killall NotificationCenter

If you want to re-enable Notification Center, you’d just run the same with a true:

sudo defaults write /System/Library/LaunchAgents/ KeepAlive -bool true

The easy way to then get it back is to reboot. Now, just for giggles, Notification Center is actually the /System/Library/CoreServices/ and in there lies the /System/Library/CoreServices/ binary. If you open it, you’ll get multiple Notification Center icons in the menu bar. I’m not sure why I decided to try that at some point. But it’s kinda’ fun…

Ultimately, I travel with multiple MacBooks, so rather than toss one of them in a checked bag, or one destined for the overhead, I am temporarily just keeping a second 11 in the bag I keep under the seat in front of me for now…

October 22nd, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , ,

When I’m writing, I like to listen to music in the background. When writing, I also like to have everything minimized so I can quickly grab a screenshot of the desktop where needed. This means that when I run into a track that doesn’t work with whatever I’m writing that I would need to unminimize iTunes, click the next button and then re-minimize iTunes. Awhile back I found a better way but can’t remember where for attribution. So, part of my default user template and imaging framework now includes setting the iTunes Dock icon to show the track that I’m playing so I can easily go to the next song, filing away the current song to remove from whatever playlist at a later date in case I’ve forgotten who the artist was. By default the iTunes Dock icon doesn’t show the current playing track. To tell it to:

defaults write itunes-notifications -bool TRUE

Then killall Dock:

killall Dock

Now when you click on iTunes in the dock and hold the mouse down, you’ll see the following:

If you later decide you don’t like this:

defaults write itunes-notifications -bool FALSE

And then killall Dock:

killall Dock

July 29th, 2012

Posted In: Mac OS X

Tags: , , , , , , , ,

Next Page »