Tiny Deathstars of Foulness

Deploying iCal Server across a large number of systems at first seems somewhat time consuming. But there are a few options to make things easier than manually touching each system, or trying to script the setup process.

When you first open iCal, it will allow you to do an Automatic setup using your email account and password. The server that it will setup this information for is based on a service record (SRV) for CalDAV being found in DNS. For automatic deployment of an iCal Server you can build a service record in DNS that will point to the server. The record should have the following settings (you can leave the Service Name empty):
Service Type: _caldav.tcp (non-ssl)
Host: the name of your server (ie –
Port: 8008

The port setting can change if you’ve manually set a new port for your server. To verify the port number use this command:
sudo serveradmin settings calendar:HTTPPort

May 28th, 2010

Posted In: Mac OS X Server, Mass Deployment

When scripting login events for Mac OS X, there are a number of ways to pull the name of the existing user. The easiest is likely to use the whoami command, which reports back the user name that is currently logged into a system. To do so you can simply run whoami. You can also place `whoami` in scripts where you want the current user to run, unless you have elevated privileges when running the script. For example, when a user logs in, if you want to mount their home directory and it’s on a server called then you could use: mkdir /Volumes/`whoami` mount_afp ‘afp://`whoami` /Volumes/`whoami` If you run this with sudo then it would still be run where whomai is expanded as the user. However, if you su your environment, which a number of ways of running certain scripts will do, then you would end up having `whoami` expand as root so it is not recommended to use in all scenarios. When you are using su you might find that looking at the user(s) with a loginwindow will be a better way to obtain the user the script should possibly be run against even when the user is logged in. There are other ways; one method would be to use ps to look at who is running loginwindow: ps -Axjc | grep loginwindow | awk ‘{print $1}’ Whoami doesn’t work when you are configuring managed preferences (I guess if you were doing local MCX you could use it to populate data, but it seems a bit annoying to do so). Therefore, you have %@, which expands to be a user’s short name. If, for example, you are configuring mail settings using a managed preference in Workgroup Manager, you can put %@ in place of where a user name goes and each user who that managed preference is applied to will expand the %@ as their user name. If you domain name is, then you could use as the email address. Therefore, if I log in as cedgeit would expand to be in the client.

May 27th, 2010

Posted In: Mass Deployment

There are a number of ways to handle quotas in Mac OS X Server. To enable quotas is simple enough. If you open Server Admin and then click on Share Points and then the volume, you can check the box for enable quotas on this volume. It will take awhile for the data to load once you’ve clicked save, but then it will show you how much space is in each users quota. You’ll then notice the .quota.ops.user and .quota.user files at the root of the file system you just enabled quotas for. If you enable group quotas then you will see and as well. Since these are not created automatically, you can create an empty shell for the with touch: touch At this point, if you attempt to look at the user quota files then you aren’t going to see anything of interest as they’re binary files. You can then use the quota, edquota and reqquota commands to manage the quota. If you use the repquota command, you can see similar output to what you see in Server Admin, but with a little more information (here we’ll use the -a and -v options to see quotas for all volumes (the -a) and see a list of which volume each listing is for (the -v option): repquota -av Next, we can set a quota. If you have an existing user then you can set the quota for that user and then base subsequent users from that one using the edquota command. In the following example, we’ll take a look at a user called mytemplate and base the quota for a user called newuser on the one used for mytemplate: edquota -u -p mytemplate newuser Alternatively, you could replace these with the $templateuser and $newuser variable if you were scripting this: edquota -u -p $templateuser $newuser You can also enable a group quota for a specific group by using the edquota command: edquota -g mygroupname Once you’ve enabled quotas, you can check each user quota using the quota command with the -u option or the -g for groups. I like to add a -v for posterity. So you if you ended up with a user named cedge you could use: quota -vu cedge

May 25th, 2010

Posted In: Uncategorized

I seem to remember that Google once made a promise to do no evil. This doesn’t mean they don’t occasionally do wrong, but they continue to react in ways that are appropriate and keep the wrong from becoming evil. Google Maps is one of my favorite parts of the web. Before I book a hotel room I usually check out the area from a few different angles. In part, this is made possible by the Google street view cars. These little cars zip around the globe taking images of the front of our homes, out potential hotels and even catch people doing things they shouldn’t. But those same cars were also war driving. Really, I’m sure they were mostly collecting SSID and MAC addresses to allow non-GPS enabled computers to be physically aware of their location based on approximate wireless connections. This service, included from another vendor in Mac OS X, looks up close wireless networks and based on unique values from those networks can set your time zone. There are a myriad of other uses with mapping out wireless access point locations, but other than winning competitions at DefCon, that’s the most popular. Those little cars that Google sends around were also capturing information that they weren’t intended to capture: live network traffic from networks lacking encryption. Not much, as the wireless equipment in those cars changes channels a few times a second… Sniffing wireless traffic is something that has been possible for a long time. But few could have sniffed as much traffic as Google given our lack of fleets of automobiles running around the world doing so. But Google did the right thing. It was uncovered, they posted it to their blog and sought out a third party to help them to review and then dump the data. So good going Google. Thanks for not being evil, and please keep those cars running around the world and helping to make the web a more interesting place to visit. Oh and if you’re not securing your wireless networks, take this as yet another reason to do so…

May 18th, 2010

Posted In: Mac Security

Yesterday I showed a way to get the serial number from a Mac OS X machine. However, as a couple of people pointed out, Apple will soon be adding another character to the serial number. This means that rather than use cut I should have used awk to allow for either serial number length. To grab the serial this way:
ioreg -l | grep IOPlatformSerialNumber | awk ‘{print $4}’
Or without the quotes:
ioreg -l | grep IOPlatformSerialNumber | awk ‘{print $4}’ | sed ‘s/”//g’

May 13th, 2010

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

Tags: , , ,

During various automations in Mac OS X it helps to grab some key unique identifiers for machines. Two very common identifiers are the serial number of a computer and the MAC Address. To grab a systems serial number I usually use ioreg to run the following, which simply outputs a systems serial number:
ioreg -l | grep IOPlatformSerialNumber | cut -c 37-46
Because a system can have multiple MAC addresses (one per unique adapter), I will also use ioreg to grab those:
ioreg -l | grep IOMACAddress
Or to just see an output of the first in the list (en0):
ioreg -l -w 0 | grep IOMACAddress | cut -c 37-48 | head -n 1

May 12th, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , , ,

Haven’t had much time to read, but now that I have a couple of books completely finished I can sit back and get caught up on my reading. And it is worth mentioning that the very first reading that I’ll do is getting caught up on the articles in MacTech Magazine, which is the only magazine I actually pay for. If you don’t get it yet, you really should check it out:

May 9th, 2010

Posted In: Articles and Books, Mac OS X

Tags: , ,

Minneapolis has a HackerSpace located at 3119 E. 26th Street in Minneapolis, MN 55406. Monthly donations are $50, but there are a number of free events that can be found on their twitter page: HackFactory of Minneapolis Tour from David Bryan on Vimeo. Find them on the web at

May 8th, 2010

Posted In: personal

Tags: ,

Now that all of the Peachpit books are available for 10.6 Certification purposes I thought it might be a good time to post a link to all of them. Here goes: Or for ACMA (the Final Cut below could be swapped out with Support Essentials, Directory Services or Deployment):

May 7th, 2010

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

Tags: , ,

When I’m running a script that might be somewhat time intensive I like to check the battery of the MacBooks first. Otherwise I might end up hosing some machines that die out in the middle of a script. To do so I’ll use ioreg to grab the maximum load that a battery can sustain, stored in MaxCapacity:
capacity=`ioreg -l | grep MaxCapacity | cut -c 35-39`
Then I’ll grab the current load on the battery, stored in CurrentCapacity:
current=`ioreg -l | grep CurrentCapacity | cut -c 39-43`
Finally I’ll grab a percentage:
echo “scale=2; $current*100/$capacity” | bc
If the percentage is above a certain threshold then I’ll run the script, if not I’ll exit the script. Usually I’ll return a different code on success or failure for the sanity check than I would for success or failure of the actual payload, if only to ease deployment troubleshooting.

May 6th, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , , , ,

Next Page »