Tiny Deathstars of Foulness

There’s a quick and easy IT Business Edge slideshow at that I helped with about 5 Mobile Apps You Really Need for SMB Success.

Screen Shot 2015-08-10 at 2.55.35 PM

Hope you enjoy!

August 10th, 2015

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

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

sFlow is an industry standard that allows network equipment with the appropriate agents to send data to sFlow collectors, which then analyze network traffic. You can install sFlow on routers, switches, and even put agents on servers to monitor traffic. Brocade (along with most other switch manufacturers) supports sFlow.

Before you do anything log into the switch and check the current flow configuration:

show sFlow

To configure, log into the switch and use the the int command to access an interface. From within the interface, use the following command:

sflow forwarding

Then exit the interface using the very difficult to remember exit command:


Repeat the enablement of forwarding for any other necessary interfaces. Next, we’ll configure a few globals that would be true across all interfaces. The first is the destination address, done using the destination verb followed by the IP and then the port (I’m using the default 6343 port for sFlow):

sflow destination 6343

Set the sample rate:

sflow sample 512

Set the polling interval:

sflow polling-interval 30

Finally, enable sFlow:

sflow enable

January 2nd, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure, Xsan

Tags: , , , , , , , , ,

I was recently building some preflight scripts and was looking to record some information about a machine live, before proceeding with a script. I found the cheapest way to determine information about architectures and chipsets when scripting preflight scripts for OS X to be the arch and machine commands respectively. For example, to verify the architecture is i386, use the arch command with no options:


Which simply outputs “i386”:


To check the machine type, simply use the machine command:


Which outputs as follows:


December 14th, 2014

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

Tags: , , , , , , ,

The other day, my daughter said “it’s opposite day” when it was time to do a little homework, trying to get out of it! Which reminded me of a funny little command line tool called rev. Rev reads a file and reverses all the lines. So let’s touch a file called rev ~/Desktop/revtest and then populate it with the following lines:


Now run rev followed by the file name:

rev ~/Desktop/revtest

Now cat it:

cat !$

Now rev it again:

rev !$

You go go forward and back at will for fun, much more fun than homework… Enjoy!

December 12th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure, Programming, Ubuntu, Unix

Tags: , , , , , , ,

OS X has a command called rvictl, which can be used to proxy network communications from iOS devices through a computer over what’s known as a Remote Virtual Interface, or RVI. To setup an rvi, you’ll need the udid of a device and the device will need to be plugged into a Mac and have the device paired to the Mac. This may seem like a lot but if you’ve followed along with a couple of the other articles I’ve done recently this should be pretty simple. First we’ll pair:

idevicepair pair

Then tap Trust on the device itself. Then we’ll grab that udid with idevice_id:

idevice_id -l

Next, we’ll setup a rvi with rvictl and the -s option (here I’m just going to grab the udid since I only have one device plugged into my computer):

rvictl -s `idevice_id -l`

Then we can list the connections using rvictl with the -l option:

rvictl -l

Next, we’ll run a tcpdump using this newly constructed rvi0:

tcpdump -n -i rvi0

Next, we’ll get a lot of logs. Let’s fire up the Nike FuelBand app and refresh our status. Watching the resultant traffic, we’ll see a line like this:

22:42:29.485691 IP > Flags [S], seq 3936380112, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 706439445 ecr 0,sackOK,eol], length 0

There’s an IP in there, We can look this up and see that the servers are sitting on Amazon Web Services and verify it’s Nike. Watching the traffic with tcpdump we can then obtain GET, POST and other information sent and received. Using wireshark we could get even more detailed data.

Overall though, this article is meant to focus on the iOS side of this and not on debugging and refining the approach to using tcpdump/wireshark. rvictl is a great tool in the iOS development cycle and for security researchers that are looking into how many of the apps on iOS devices exchange data. Enjoy.

November 19th, 2014

Posted In: iPhone, Mac Security, Network Infrastructure

Tags: , , , , , , , , ,

Xcode and other tools can be used to view logs on iOS devices. One of those other tools is libimobiledevice. I usually install libimobiledevice using homebrew, as there are a few dependencies that can be a little annoying. To install homebrew if you haven’t already, run the following command:

ruby -e "$(curl -fsSL"

Once run, follow the prompts to complete the installation. Once homebrew is installed, run the following brew command to download the required components and then libimobiledevice:

brew install -v --devel --fresh automake autoconf libtool wget libimobiledevice

Then run ideviceinstaller:

brew install -v --HEAD --fresh --build-from-source ideviceinstaller

Once these are installed, you can plug in a paired device, unlock it and use the following command to view the logs on the screen:


This is akin to running a tail against the device. Again, the device must be paired. You can use the command line (e.g. if you’re running this on Linux) to view the logs, but if you’re not paired you’ll need to use idevicepair to pair your device, followed by the pair verb (which is very different from the pear verb):

idevicepair pair

You can also unpair using the unpair verb:

idevicepair unpair

When pairing and unpairing, you should see the appropriate entries in /var/db/lockdown. The final option I’m going to cover in this article is the date (very useful when scripting unit tests using this suite. To obtain this, use the idevicedate command, no operators or verbs required:


November 14th, 2014

Posted In: iPhone, Mac OS X, Mac OS X Server, MobileMe, Network Infrastructure

Tags: , , , , , , , ,

The Directory Utility application has moved to /System/Library/CoreServices/Applications. Once open, you can use it to bind to directory services, change search policies and even dink around with NIS if you still rock the flannel with your ripped up jeans. But, the thing that I tend to do in Directory Utility the most is look at user and group attributes. To do so, open Directory Utility and click on the Directory Editor tab. In the bar directly below, you’ll see Viewing and In Node. The Viewing option is what type of object you’re going to look at. The In Node option shows the directory domain you’re viewing. Below, we show the local users in /Local/Default. Screen Shot 2014-10-30 at 9.02.04 AM

Click on a user and you will see all of the attributes that exist for that user. Not all users are created equal when it comes to attributes, so if you’re looking for a specific attribute then you can go through different users to see what they have.

Screen Shot 2014-10-30 at 9.12.18 AM

Change the In Node option to /LDAPV3/ (or the name of your directory service such as your Active Directory) to see all the attributes available there. You can then note the names and use them in scripts, etc.

Screen Shot 2014-10-30 at 9.04.11 AM

You can also access this information via dscl, but I’ve covered that enough times in the past to be bored with myself for even making the reference. Enjoy.

November 6th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure

Tags: , , , ,

Setting up OS X Server has never been easier. Neither has upgrading OS X Server. In this article, we’ll look at upgrading a Mac from OS X 10.8 or 10.9 running Server 2 or Server 3 to OS X 10.10 (Mavericks) running Server 4.

The first thing you should do is clone your system. The second thing you should do is make sure you have a good backup. The third thing you should do is make sure you can swap back to the clone should you need to do so and that your data will remain functional on the backup. The fourth thing you should do is repeat all that and triple check that your data is there!

Once you’re sure that you have a fallback plan, let’s get started by downloading OS X Yosemite from the App Store. I would also purchase the Server app first while Yosemite is downloading. Screen Shot 2014-11-04 at 7.15.56 PM Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad. Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad, as well as in the /Applications folder.

Screen Shot 2014-11-04 at 5.09.18 PM

Open the app and click Continue (provided of course that you are ready to restart the computer and install OS X Yosemite).

Screen Shot 2013-10-04 at 4.45.46 PMAt the licensing agreement, click Agree (or don’t and there will be no Mavericks for you).

Screen Shot 2013-10-04 at 4.45.48 PMAt the pop-up click Agree again, unless you’ve changed your mind about the license agreement in the past couple of seconds.

Screen Shot 2013-10-04 at 4.45.52 PMAt the Install screen, click Install and the computer will reboot and do some installation fun stuff.

Screen Shot 2013-10-04 at 4.45.54 PMOnce done and you’re looking at the desktop, download the latest version of the Server app you should have purchased previously, if you haven’t already. Then open it.

Screen Shot 2014-11-04 at 5.13.05 PM
If prompted that the Server app was replaced, click OK. Then open the app.

Screen Shot 2013-10-04 at 5.48.52 PMAt the Update screen, click Continue (assuming this is the server you’re upgrading).

Screen Shot 2014-11-04 at 5.13.09 PMAt the Licensing screen, click Agree.

Screen Shot 2014-11-04 at 5.13.12 PMWhen prompted for an administrator account, provide the username and password of an administrator and click OK.

Screen Shot 2014-11-04 at 7.28.07 PMWhen the app opens, verify DNS (absolutely the most important element of this upgrade), etc and then check that configured services still operate as intended. If you end up deciding that you no longer need OS X Server, just delete the app and the contents of /Library/Server and you’re good. Handle with Care.

November 4th, 2014

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

Tags: , , , , , ,

OS X Server has long had a VPN service that can be run. The server is capable of running the two most commonly used VPN protocols: PPTP and L2TP. The L2TP protocol is always in use, but the server can run both concurrently. You should use L2TP when at all possible.
Sure, “All the great themes have been used up and turned into theme parks.” But security is a theme that it never hurts to keep in the forefront of your mind. If you were thinking of exposing the other services in Yosemite Server to the Internet without having users connect to a VPN service then you should think again, because the VPN service is simple to setup and even simpler to manage.

Setting Up The VPN Service In Yosemite Server

To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has two options available in the “Configure VPN for” field, which has two options:

  • L2TP: Enables only the L2TP protocol
  • L2TP and PPTP: Enables both the L2TP protocol and the PPTP protocol


The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:

  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPNvpn2
  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.vpn3
  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over. vpn4
  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (OS X using the profiles command, iOS using Apple Configurator or both using Profile Manager).

Once configured, open incoming ports on the router/firewall. PPTP runs over port 1723. L2TP is a bit more complicated (with keys bigger than a baby’s arm), running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at

Using The Command Line

I know, I’ve described ways to manage these services from the command line before. But, “tonight we have number twelve of one hundred things to do with your body when you’re all alone.” The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required:

sudo serveradmin start vpn

And to stop the service:

sudo serveradmin stop vpn

And to list the available options:

sudo serveradmin settings vpn

The output of which shows all of the VPN settings available via serveradmin (which is many more than what you see in the Server app:

vpn:vpnHost = "mavserver.krypted.lan" = "/var/log/ppp/vpnd.log" = 1 = 128 = _empty_array = _empty_array = "1" = "" = "2" = "" = yes = "PPTP" = "PPP" = 5 = 1 = "EAP-RSA" = "DSACL" = 1 = 0 = 1 = 1 = 60 = 1 = "MSCHAP2" = 0 = "DSAuth" = "/var/log/ppp/vpnd.log" = 1 = 7200 = "MPPE" = "Manual" = "" = "" = _empty_array = _empty_array = _empty_array = "" = 128 = 0 = "/var/log/ppp/vpnd.log" = 1 = _empty_array = _empty_array = "1" = "" = "2" = "" = yes = "L2TP" = "PPP" = 5 = 1 = "EAP-KRB" = "DSACL" = 1 = 0 = 1 = 60 = 1 = "MSCHAP2" = "DSAuth" = "/var/log/ppp/vpnd.log" = 7200 = "Keychain" = "" = "" = "SharedSecret" = "" = "None" = <> = "Manual" = "" = "" = _empty_array = _empty_array = _empty_array = "IPSec" = "yaright"

To disable L2TP, set to no:

sudo serveradmin settings = no

To configure how long a client can be idle prior to being disconnected:

sudo serveradmin settings = 10

By default, each protocol has a maximum of 128 sessions, configureable using

sudo serveradmin settings = 200

To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option:

sudo serveradmin fullstatus vpn

Which returns output similar to the following:

vpn:servicePortsAreRestricted = "NO"
vpn:readWriteSettingsVersion = 1 = "MSCHAP2" = 0 = yes = "MPPEKeySize128" = "PPP" = "PPTP" = "DSAuth" = "MSCHAP2" = "PPP" = yes = 0 = "L2TP" = "DSAuth"
vpn:servicePortsRestrictionInfo = _empty_array
vpn:health = _empty_dictionary
vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log"
vpn:configured = yes
vpn:state = "STOPPED"
vpn:setStateVersion = 1

Security folk will be stoked to see that the shared secret is shown in the clear using: = "a dirty thought in a nice clean mind"

Configuring Users For VPN Access

Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar.


At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.


At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user. If not, click Manage Service Access, click Manage and then check the VPN box.


Setting Up Client Computers

As you can see, configuring the VPN service in Yosemite Server (OS X Server 2.2) is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so in OS X, open the Network System Preference pane. From here, click on the plus sign (“+”) to add a new network service.vpn8

At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create.


At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings.


At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection.


Setting Up the VPN service in OS X Yosemite Server is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into Yosemite at /usr/sbin/natd and can be managed in a number of ways. But it’s likely that the days of using an OS X Server as a gateway device are over, if they ever started. Sure “feeling screwed up at a screwed up time in a screwed up place does not necessarily make you screwed up” but using an OS X Server for NAT when it isn’t even supported any more probably does. So rather than try to use the server as both, use a 3rd party firewall like most everyone else and then use the server as a VPN appliance. Hopefully it can do much more than just that to help justify the cost. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

October 17th, 2014

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

Tags: , , , , , , , , , ,

Next Page »