Tiny Deathstars of Foulness

The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in OS X Mountain Lion Server. To do so, use the serveradmin command.

To enable ARD using the serveradmin command, use the settings option, with info:enableARD to set the payload to yes:

sudo serveradmin settings info:enableARD = yes

Once run, open System Preferences and click on Sharing. The Remote Management box is then checked and the local administrative user has access to ARD into the host.

The Server app will also have the “Enable screen sharing and remote management” option checked.

There are also a few other commands that can be used to control settings. To enable SSH for administrators:

sudo serveradmin settings info:enableSSH = yes

To enable SNMP:

sudo serveradmin settings info:enableSNMP = yes

To enable the dedication of resources to Server apps (aka Server Performance Mode):

sudo serveradmin settings info:enableServerPerformanceMode = yes

August 14th, 2012

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

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

When working at scale, and particularly with hosts that need to have the same configuration or you want to perform the same queries on, the issue becomes how do I ‘reach out and touch’ my fleet? Without centralized infrastructure backed by a messaging broker or a heavier process that leaves hooks in systems and/or requires its own domain specific language, sometimes you can get by with… plain ol’ ssh. Apple Remote Desktop can take us a lot of the way there, and one of the announced features of Mountain Lion is that screen sharing gets another piece of ARD’s pie, the ability to drag-and-drop files to transfer them to the remote machine. But when trying to use features other than screen control, ARD has been found to be hit-or-miss (or misreporting the functionality of hosts) in some circumstances.

csshX in action

‘Scripty’ folks look at these issues and craft tools to meet the challenge-slash-obscure-use case. Perl has long been relied upon for network-aware utilities, and csshX is a tool for managing a ‘cluster’ of  ssh sessions on the Mac. You can download or checkout the code from its googlecode site, and it has a man page that can be accessed when calling the binary directly with the -m switch. Options include telling it the login and/or password to use, feeding it a text file of hosts to access, or merely list hosts by DNS name or IP with spaces in between. Even if user names or passwords are different, fully-functional windows open as it attempts ssh connections to each host, with a red window you can use to control them all once you’ve authenticated to the ssh sessions.
From that point on, the world is your proverbial jerry-rigged oyster! To mimic ARD’s file transfers you could scp back to your machine (as kludges go, smileyface,) and another random tip: using the emacs readline functionality to jump to the beginning of a line with Ctrl-a still works, even though csshX uses that for a special purpose (as does the terminal multiplexer screen,) simply hit Ctrl-a again and the program will understand you wanted to send that to the remote sessions. Enjoy!

June 28th, 2012

Posted In: Mass Deployment

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

I recently spent a few days trimming down the amount of space consumed by my home folder. In so doing I discovered a number of things I could be doing better with regards to utilization of my drive space. So I decided to offload most of my media (photos, movies, etc) off my laptop and onto my Mac Mini server. I also decided that one thing I’d like to live on both is iTunes.

Note: Before you do anything in this article you should verify you have a good back up. Also, both machines will end up needing to be Authorized for your iTunes account.

There are a lot of ways to keep two iTunes libraries in sync. There are also a number of 3rd party tools that can help you do so. I tested all the tools I could find and decided I’d rather just script it myself. Scripting a synchronization operation in Mac and Linux always seems to come down to a little rsync action. Given that rsync is a little old in Mac OS X, I started out by updating rsync to the latest (3.0.7) using the steps provided on (I added using /tmp):

mkdir /tmp/rsyncupdate
cd /tmp/rsyncupdate
curl -O
tar -xzvf rsync-3.0.7.tar.gz
curl -O
tar -xzvf rsync-patches-3.0.7.tar.gz
cd rsync-3.0.7
curl -o patches/hfs_compression.diff
curl -o patches/crtimes-64bit.diff
curl -o patches/crtimes-hfs+.diff
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/crtimes-64bit.diff
patch -p1 <patches/crtimes-hfs+.diff
patch -p1 <patches/hfs_compression.diff
sudo make install
sudo rm -Rf /tmp/rsyncupdate
/usr/local/bin/rsync –version

Provided the version listed is 3.0.7 then we have a good build of rsync and can move on with our next step, getting a target volume mounted. In this case, I have a volume shared out called simply Drobo (I wonder what kind of RAID that is?!?!). Sharing was done from System Preferences -> Sharing -> File Sharing -> click + -> Choose Drobo and then assign permissions. The AFP server is on an IP address of For the purposes of this example, the username is admin and the password is mypassword. So we’ll do a mkdir in /Volumes for Drobo:

mkdir /Volumes/Drobo

Then we’ll mount it using the mount_afp command along with a -i option:

mount_afp “afp://admin:mypassword@” /Volumes/Drobo

Now that we have a mount we’ll need to sync the library up. In this case, the Music directory on the Drobo has a symlink from ~/Music. This was created by copying my Music folder to the drobo and then rm’ing it (fails when trying from Finder):

rm -Rf ~/Music

Then using ln to generate the symlink:

ln -s ~/Music /Volumes/Drobo/Music

Now sync the files. I’m not going to go into all of the options and what they do, but make sure you have permissions to both the source and the target (using the username and password from the user whose data your changing helps):

/usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music

Note: If you get a bunch of errors about operations failing then consider disabling the Ignore ownership on this volume setting for any external media you may be using.

Now fire up iTunes on the target machine and make sure it works. At this point, I could also share out the Music folder from my laptop and sync back as well, which would effectively allow me to make changes on both machines. However, for now, I only want to make changes on the laptop and not the desktop so there’s no need for a bidirectional sync.

Once the sync is complete, we can tear down our afp mount:

diskutil unmount /Volumes/Drobo

Now that we can sync data, we still need to automate the process as I’m not going to want to type all this every time I run it. First up, I’m going to create a .sh file (let’s just say /scripts/

touch /scripts/

Then I’m going to take the commands to mount the drive, sync the data and then unmount the drive and put them in order into the script:

/bin/mkdir /Volumes/Drobo
mount_afp “afp://admin:mypassword@” /Volumes/Drobo
/usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music
/usr/sbin/diskutil unmount /Volumes/Drobo

Once created, the script should be run manually and provided it succeeds then it can be automated (ie – creating a LaunchDaemon). If it works after a little while, then you can consider synchronizing your iPhoto and anything else if you so choose. Also, I ended up actually using ssh pre-shared key authentication and doing rsync over ssh. That allows you not to put the password for a host on your network into an unencrypted form in a script. You could do some trickeration with the password, but you might as well look into pre-shared keys if you’re going to automate this type of thing to run routinely. Finally, I also later ended up removing the iTunes Genius files as I started to realize they were causing unneeded data to sync and they would just rebuild on the other end anyway. Hope this helps anyone else looking to build an iLife server of their own!

December 20th, 2010

Posted In: Mac OS X, Mac OS X Server, MobileMe

Tags: , , , , , , , , ,

Sometimes it can be really useful to have an SSH connection into your AppleTV. If I need to explain why then you probably won’t want to do it. Unless of course, you’re just after getting something like Boxee running, which we’ll look at as well. Before we get into doing anything to your AppleTV, when we’re done I do not know how Apple will feel about your warranty moving forward, so do this stuff at your own risk (but that’s pretty much true for many articles on this site)…

So first up, let’s install SSH. To get started, plug in a jump drive you don’t mind reformatting. Then run the df command and look at which filesystem that the jump drive was mounted as. In most cases this should be /dev/disk1s1 or /dev/disk2s1 or something like that. Note this location and while you’re at it, double-check that the data is trivial to you and that you really don’t mind reformatting the jump drive.

Next, let’s download atvusb-creator, a little utility that will generate a new patchstick based on that jump drive (a patchstick being the term applied to usb sticks that will hax0r an AppleTV). Once downloaded, run the tool. Select ATV-Patchstick in the Choose an Installation dialog, and then select the version of the AppleTV OS you have (if you’re fully software updated then as of the date of this writing that would be 3.x). Next, choose ssh tools from the 3rd field in the Installation Options section, making sure that the box is checked. If you are just trying to get XBMC or Boxee running then you can check the boxes for those as well at this point.

ATV USB Creator Screenshot

ATV USB Creator

Next, set the USB Target Device field to be the filesystem you selected earlier and then click the Create Using button and wait for the process to finish. Once the patchstick has been created, plug it into your AppleTV and reboot the unit. You’ll see a bunch of code, similar to starting Mac OS X into verbose mode. When the screen tells you that you’re done, unplug the patchstick and reboot the device. Upon reboot it will be running SSH with a username and password of frontrow. If you’re not using a static IP address then if you open iTunes and connect to the device you’ll have an entry in your arp table for it. You can run arp and find the IP fairly easily. Once found, use the SSH command to connect to the device. For example, if mine is on an IP address of then I would use the following command to connect to it:

ssh frontrow@

Now you have an AppleTV running SSH. Even though this article isn’t meant to be about Boxee or XBMC, you can then install those by going to the new Launcher menu and then to Downloads and downloading those applications (otherwise if you try to access them you’ll get an error that the .app bundle can’t be found). Once those are in place it should open pretty easily.

Now that you’re running SSH, let’s look at one of the uses. I want a web browser on the AppleTV (even though typing a URL in it is pretty painful unless you install a keyboard too). For this instance, I’m going to use CouchServer, ’cause I like the way the keyboard works and because there’s a silverlight that kinda’ sorta’ works with it. First, download the files for CouchSurfer here. Then copy the files that were downloaded up to the device (assuming the filename is CouchSurfer-Lite.tar) from your client computer:

scp ~/Desktop/CouchSurfer-Lite.tar frontrow@

Next, SSH into the AppleTV and extract the tar file:

tar -xvpf CouchSurfer-Lite.tar

Then move the extracted data into the PlugIns directory (which will display the appliance similar to how Launcher would be displayed at this point:

sudo mv CouchSurfer.frappliance /System/Library/CoreServices/

(your password will be frontrow in case you have hard core add and have forgotten it already)

We’re gonna’ give ownership to wheel:

sudo chown -R root:wheel /System/Library/CoreServices/

Then reboot the AppleTV. Upon reboot, you will then have a shiny new web browser making your AppleTV even more like a full fledged Mac with Front Row. Now you’re in pretty good shape. You’ve pretty much put more stuff on your AppleTV than you can possibly use, but you still probably just want NetFlix to work on it. For that, you’ll need to get Silverlight working with CouchSurfer and just browse to the movies in the web browser at as the Boxee implementation for AppleTV doesn’t yet work with NetFlix and there aren’t any native Plug-Ins that work with it yet either (that I’m aware of). Also, if you’re going to use any of the 3rd party media browsers, keep in mind that they’re sitting on top of the OS layer and that their resource utilization seems pretty poor compared to the native media browser on the device (given the abstraction there, it seems logical it would be so no complaints).

BTW, another fun little app (to help make your AppleTV more like your iPad):

And the most intriguing one that I haven’t actually gotten to work yet (haven’t had time to get past the second or third step – busy) is:

What I’d like to see – the ability to run my AppleTV as a Zwave controller… Or iPad… Or Newton… 🙂

April 23rd, 2010

Posted In: Home Automation, Mac OS X

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

Sorry, I can’t help it. That whole “iPhone Security Problems” thread I’ve seen on a few sites recently due to that worm. Oh, then there was a second worm that did the same thing. Really? Did these awesome security gurus realize that the device has to be jailbroken? Oh and they have to still have the default password used for SSH? I would hope that if you know enough to jailbreak the device without bricking it that you know enough to change the default SSH password.

Interestingly enough though, an estimated 6 to 8 percent of iPhones are jail-broken… If there have been 21 million sold, that provides an attack surface of around a 1.2 million if you just target jail-broken phones. A PC needs to be running on the same network infected with a totally different worm that tries to log into the phone and steal things. By the way, here’s a huge new security vulnerability I should write – if you leave your LinkSys with the default password AND you allow administration over the WAN then someone can break in over the WAN and mess it up… Of course, in that case you should maybe be with the LinkSys (although the power adapter might cause more damage in terms of hit points), but for some reason people aren’t being beaten over the head with an iPhone but instead so-called security experts find spreading FUD is far more helpful than doing something for a living, like real research.

I just have to reiterate this. There’s a worm out there that scans a subnet and attempts a specific SSH user name and password, if it works then it tries to steal some data, or in a different variant just Rick Rolls ya’. Somehow the fact that in order to put an SSH server on the subnet in the first place you had to void a warranty and forklift SSH onto a device, which took great pains to do, and subsequently forgot to change the password for that SSH server means nothing; nor does the fact that you also need a frickin’ Windows computer to carry the worm to you that’s also infected. Crap, just crap.

November 25th, 2009

Posted In: iPhone

Tags: , , , ,

ssh -X serveraddress gui-tool

September 24th, 2007

Posted In: Mac OS X, Mac Security

Tags: , ,

Control access by editing the SSH configuration file and using the AllowUsers directive like so:

AllowUsers cedge

To add multiple entries, either separate users with a space:

AllowUsers cedge kklein
Or you can write an entirely new line:
AllowUsers cedge
AllowUsers kklein

January 11th, 2005

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

Tags: ,

« Previous Page