Tiny Deathstars of Foulness

You can query whether a process is running by name. You can do this with ps and pipe the output to grep. It’s not hard, but you can do this more quickly with pgrep. You can also kill that process with pkill. Which includes the ability to send a signal.

So, let’s look at closing down iTunes with pkill:

pkill iTunes

Or we can send it with a signal (9):

pkill -9 iTunes

Or you could just grab the pid of a process by name:

pgrep Safari

It might display:


And that’s it. Easy Peasy.

August 2nd, 2015

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

Tags: , , , ,

Leave a Comment

Safari has a bookmarks bar. Some people want to hide it. A lot of people used to do stuff like this by modifying the default user template in OS X. Not something we’ll be doing much in the future. So to do so with a script:

defaults write ShowFavoritesBar -bool false

To turn it back on:

defaults write ShowFavoritesBar -bool true

July 31st, 2015

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

Tags: , , , , ,

Leave a Comment

As of OS X 10.9 (and in many cases more importantly in OS X Server for 10.9 and higher), OS X now performs ARP cache validation when trying to pass traffic over a router. If you are double NAT’d/use redundant gateways then the traffic can be interpreted as network redirection and cause some pretty bad packet loss/latency. You can disable this feature by turning off using sysctl:

sysctl -w

That will only disable unicast arp validation until the next reboot. If it fixes a latency problem you’re having then you can go ahead and make it permanent by adding the following line into /etc/sysctl.conf:

If you’re still having issues with latency, you should turn it back on. To enable it again, repeat, swapping the 0 with a 1.

July 19th, 2015

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

Tags: , , , , , , ,

Leave a Comment

So a few months ago, closing in on 3,000 posts, the database got too big and started suffering from innodb corruption, resulting in database outages. While I was able to get the site up, it was using a read-only database that kept me from doing any new articles or updates. It was a strange time in my life, like suddenly being single after living with someone since Y2K (when I started the site). But I got through it and was able to repair the relation… er, site. Now, with a new database that is free from corruption we’re ready to get to 6,000 posts!

Also, I had a little feedback on the usability of the site. I had thought people would scroll down to find the search box. Apparently there’s a reason most sites put it at the top. It’s now there here. I also made a couple of new pages (in addition to the articles I’ve been posting since it came back up) and removed a couple of pages. Most of the pages have gotten fresh information and had at least something retired. No changes to articles in all of this, just pages.

Finally, I know I’ve made this offer in the past, but I welcome any guest authors that would love a place to store their stuff. Talk about anything technical you’d like, from Arduino to BRU to Casper to Munki to OpenMDM to Linux to PowerShell. It should just be technical…

July 17th, 2015

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


One Comment

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: , , , , , , , , ,

Leave a Comment

For a long time, we used the bless command to startup systems to a specific volume in OS X. Back in 2009 I started using the systemsetup command for more and more tasks. These days, I’m being guided to replace all of my bless options in scripts to systemsetup. The easy way to configure your startup volumes using systemsetup is to list the available volumes, set one as the startup volume and then check to see which one is the current volume. The first task is to list the available startup volumes, using the -liststartupdisks option:

sudo systemsetup -liststartupdisks

You can then set the disk as one that was listed by the above command:

sudo systemsetup -setstartupdisk /Volumes/HAVOKMELTDOWN

You can finally check the current startup disk as a sanity check in your script to verify the desired disk is the startup volume using -getstartupdisk

sudo systemsetup -getstartupdisk

July 15th, 2015

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

Tags: , , , , , , ,


The options for Open Directory continue to get more refined, aligning with opendirectoryd. The odutil command is becoming more and more useful with each version of OS X. Let’s inspect the directory service cache, using odutil with the show verb and the cache option:

odutil show cache

You can also view statistics for opendirectoryd using that show verb but with the statistics option:

odutil show statistics

And to see everything, use odutil with the show verb and the all option to get plenty of data to grep through:

odutil show all

The final show option we’ll look at is configuration. Here, you will also need to feed a directory nodename into the command:

odutil show configuration /Search

Now, /Search is a node but there are a lot. You can use show with nodes to see a listing of all the nodes:

odutil show nodes

You can then see which pids have references to opendirectoryd as well as the nodenames, reference IDs, and session IDs.

All of this can be very helpful when troubleshooting Open Directory issues. One thing I find I do pretty frequently is resetting statistics then repeating a process that is causing a problem so I can view only the updated statistics. To do so:

odutil reset statistics

You can also disable statistics (I’ve seen them create performance concerns:

odutil set statistics off

Or to turn them back on:

odutil set statistics on

Once upon a time you could killall DirectoryService with a -usr level to set various logging levels. With opendirectoryd, we can still do that, but it’s less cludgy with odutil. Here, we’ll set the logging level as detailed as we can get:

odutil set log debug

Other levels, in ascending order of verbosity, include alert, critical, error, warning, notice, and info.

July 10th, 2015

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

Tags: , , , , , , ,

Mac admins spend a lot of time building images. In System Image Utility this can mean baking an image that just looks for a path of a NetRestore source and restores an operating system. Constantly making these is a pretty duplicative task. The goal of this article is to take a generic NetRestore NetBoot image and augment it in such a way that you don’t need to create new NetBoot images unless there’s a new build train. Instead, all you need to do is edit a file that changes the path (uri) of your image so that it can be restored. Using this, you can just stop the NetInstall service in OS X Server, edit a file, start the service back up and boot clients into the NetBoot environment.

Screen Shot 2015-07-09 at 5.21.31 PM

When you make a NetBoot Set, you’ll select a source. This can be a local volume or a network volume. Once your NetBoot nbi is created, you’ll see a NetInstall.dmg. If you open that dmg, you’ll see a directory called Packages. If you open that, you’ll see an InstallPreferences.plist.

Let’s cat that real quick:

cat /Volumes/NetInstall/Packages/InstallPreferences.plist

The output would be as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
<string>Unicast Image</string>

Here, let’s look at a few specific keys that we can edit:

  • descriptionKey: A simple, human readable description of the image that will be installed
  • sourceKey: The URI to the image that asr will connect to in order to install the image
    sourcePath: This is the path to the dmg file within the nbi. This is usually best left untouched unless you’ve switched something around within the nbi (which I’ve only seen done a couple of times).
  • restoreSourcesBrowseMulticast: Set to true to allow for multicast imaging. Obviously, DeployStudio or asr would be used to make this work and you’d need to provide a multicast address.
  • installRecoveryPartition: Set this to false if you don’t want to install a recovery partition. You probably should be creating one.
  • restoreSourcesAllowManual: Allows for manual entry of an image source.
  • restoreSourcesBrowseOthers: Allows for browsing over Bonjour for an image source.
  • restoreSourcesArray: Not present if you chose a local path.

You can also edit the NBImageInfo.plist file to set some of the other items you might otherwise edit in System Image Utility. Here, you’ll need to covert the plist to xml to edit it:

plutil -convert xml1 /Volumes/NetBootSP/NetInstall\ OS\ X\ Yosemite.nbi/NBImageInfo.plist

In here, you’ll see a plist similar to the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

The important keys to look at here are:

  • SupportsDiskless: Switch this on and off if you want NetBoot to run for diskless systems (e.g. if you’re a 3 letter government agency).
  • Index: Typically use unique index IDs.
  • IsDefault: Makes that image the default image.
  • RootPath: The path to that NetInstall.dmg file from earlier.
  • ImageType: netrestore versus netinstall.
  • DisabledSystemIdentifiers: Disables certain models of Macs, which you’d edit by adding and removing items from that array.

So you can edit these files, and once you do so, you won’t need to be baking NetBoot sets all the time. Just when there’s a new build train of OS X and you can’t boot those new machines to NetBoot.


July 9th, 2015

Posted In: Mac OS X, Mac OS X Server, Mass Deployment, Network Infrastructure

Tags: , , , , , , , ,

The serveradmin command has an option to run commands. I’ve talked about these in past articles, for doing tasks like asking how many concurrent NFS connections are open on a host. Well, here’s another, and it’s a simple command. Here, we’re going to look at whether the Open Directory server has a CA. To do so, we’ll use the serveradmin command, along with the command verb. Then, we’ll add the certs option, followed by command= and then the payload of the command. In this case that’s isODCAPresent:

sudo serveradmin command certs:command = isODCAPresent

This is a simple, informational command, similar to the web:command of getSites or the mail:command of getConnectedUsers. Enjoy!

July 8th, 2015

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

Tags: , , , , , , ,

___ “is an application downloaded from the Internet. Are you sure you want to open it?” is a warning dialog that appears when you open an application that you downloaded from the Internet. When you install those software titles with automation, you can clear the attribute that causes the prompt, so you don’t get a lot of confusion from end users. TO do so, use the xattr command, using -d to delete the attribute. Here, we’re going to do so recursively, using the -r option and finally defining the application:

sudo xattr -d -r /Applications/

July 6th, 2015

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

Tags: , , , ,

Next Page »