Tag Archives: ARD

Mac OS X

Disable Dock Autohide

One of those annoying little things is when you ARD into a system and the Dock is nowhere to be seen. Why do we (or should I say they) autohide Docks on servers? Either way, when I ARD into a box and I don’t see a Dock I have this line saved as a Template:

defaults write com.apple.dock autohide -bool false; killall Dock

By writing an autohide key that is false into com.apple.dock for the currently logged in user, I don’t have to deal with the Dock disappearing any more. You need to kill the Dock and let it respawn, thus the killall as well.

Once I’m done working with the box, I can show the dock again:

defaults write com.apple.dock autohide -bool true; killall Dock

Or, instead of all this, as diskutant once pointed out, just use Command-Option-d when you ARD in and then again when you log out!

Mac OS X Server Mac Security Mass Deployment

Enabling ARD, SSH & SNMP On Mountain Lion Server Using serveradmin

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

Mass Deployment

One Teletype to Bind Them (Or, Clustered SSH for OS X)

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!

Football Mac OS X Mac OS X Server Mac Security Mass Deployment Time Machine

2012 Penn State MacAdmins Conference

Don’t let the theft of the Paternoville sign fool ya’, State College is as safe as ever. That is, until a bunch of Mac guys descend on the Nittany Lion Shrine. Yes, it’s that time of the year again when Mac guys from around the world (and yes, all of the speakers are male) descend upon Pennsylvania State University from throughout the Big 10 and beyond to discuss the Penn State mascot, the Nittany Lion. Actually, it’s a mountain lion, so we can’t discuss it quite yet at that point, but we can talk about a slightly bigger cat: Lion.

Lion deployment, scripted tools, Munki, InstaDMG, Puppet, migrations, “postPC,” PSU Blast, Dual Boot, NetBoot, reboot (just threw that in there because it sounded like it fit, but I’m sure much rebooting will be done anyway) and even iOS. Oh, and don’t forget lecture capture, launchd, monitoring, scripting, Boot Camp via BitTorrent (wait, what?), Damn Logs, Subversion (long live git), IPv6 (long live IPv4), DeployStudio (long live the French), Reposado (long live the mouse), Luggage, Casper (long live Minnesota!), ARD (long live the friggin’ App Store), troubleshooting, FileVault (long live Howard Hughes’ legacy), Tivoli (long live that 1984 video), Munki (crap, I already said that) and even iPad (which runs iOS I think).

Overall, the lineup is superb and looking at it, I am honored to be giving a session on Lion Server amidst all the cool stuff going on around me. I’m very impressed with the number and level of speakers and very excited to be a part of it. I’m also excited to be participating with Allister Banks, a cohort from 318, who will be giving talks on InstaDMG and Munki. Overall, it is sure to be a great conference and I look forward to hopefully seeing you all there if I don’t get arrested at the airport for wearing University of Minnesota socks.

Speaking of the Big 10. Did you know there are 12 teams in the Big 10? Did you know the Big East now has teams in Idaho and California? Did you know that the Big 12 has 10 teams? Did you know that the Pac 12 has 4 teams in 3 states that don’t touch the Pacific ocean? What does all this mean? No, it does not mean that we will discuss basic arithmetic and geography at the conference; however, we might show off some apps that can help the math professors at the member institutions of these higher education conferences teach these basic subjects a bit better. Disclaimer: I went to the University of Georgia and am required by having done so to poke fun at other conferences whenever it is possible. Having said that: how many Georgia programmers does it take to change a light bulb?


They can’t, it’s a hardware problem! OK, terrible joke. So here’s a picture of the Georgia mascot chomping down on an opposing (Auburn) player.

Seems like I’m going through football season withdrawals all of a sudden… Point of all this, go to the conference. It’s sure to be a hoot, and I’m sure there will be plenty of talk about football, er, I mean Mountain Lions, er, wait, I mean Mac OS X and iOS!

Mac OS X

Command Keys and ScreenSharing

I like to send the command, control and other system keys to hosts that I’m using ScreenSharing or Remote Desktop to access. But as I recently discovered, not everyone does. You can turn this feature off using the defaults command to augment the DoNotSendSystemKeys key of the com.apple.ScreenSharing.plist property list file. Simply run the following command:

defaults write com.apple.ScreenSharing DoNotSendSystemKeys -bool YES

To turn them back on:

defaults write com.apple.ScreenSharing DoNotSendSystemKeys -bool NO

Or for Remote Desktop, augment the com.apple.

defaults write com.apple.RemoteDesktop DoNotSendSystemKeys -bool YES

To turn it back off for Remote Desktop:

defaults write com.apple.RemoteDesktop DoNotSendSystemKeys -bool NO

FYI, if you don’t want to send the command keys I think you’re a little weird, but that’s OK. Hope you enjoy anyway…

Mac OS X Mac OS X Server Mac Security Mass Deployment Xsan

Programatic Screen Sharing

You can remotely start ARD with kickstart, which I have previously covered at length. But Screen Sharing is a bit of a different little beast. To start up Screen Sharing, you can just use the following command:

echo -n enabled > /Library/Preferences/com.apple.ScreenSharing.launchd

I still prefer kickstart, but this method functions when you need something quick and easy. To then disable Screen Sharing, you can just toss the launchd item:

rm /Library/Preferences/com.apple.ScreenSharing.launchd

Once you have Screen Sharing started, you can then open the Screen Sharing application from a client by using the open command, followed by the protocol, which would be vnc and then the IP address. As with FTP you can also inject the user name and password into the open, following the //, by placing the user name followed by a colon (:) followed by the password and then the @ symbol (all before the IP address). For example, to connect to a computer with an IP address of 192.168.200.2 using the username of krypted and the password of mypass you would use the following command.

open vnc://krypted:mypass@192.168.200.2

You may encounter an encryption error, which if you are attempting to script can be annoying to click on. To suppress it, use defaults to set the dontWarnOnVNCEncryption key of the com.apple.ScreenSharing.plist to True:

defaults write com.apple.ScreenSharing dontWarnOnVNCEncryption -bool TRUE

Have fun!

Mac OS X Mac OS X Server Mass Deployment

Sending Command Keys Through ARD

You can send Command keys (aka – Open Apple and Closed Apple) through Apple Remote Desktop (ARD), or not send the Command keys through ARD. Your call:

defaults write com.apple.RemoteDesktop DoNotSendSystemKeys 1

P.S. – Of course these are short, I’m on the road. Sorry for brevity but typing posts on the iPhone is not all it’s cracked up to be…

Mac OS X Mac OS X Server Mass Deployment

Apple Remote Desktop Issues + Xsan

The build_hd_index process is spiking! What to do?!?! In an Xsan
environment where you have a number of clients and Apple Remote Desktop is running on an administrative computer, the Application Usage Data and User Accounting Data collectors can cause the build_hd_index process to run more often than is needed (okay so spiking is a bit extreme but a dropped frame once every couple of days is the end of the world to some people), especially in cases where you don’t actually use the collected data for business intelligence. If you do a Get Info on a computer in Remote Desktop you can uncheck Collect Application Usage Data and Collect User Accounting Data, which will free it all up. Here’s the trickeration (too much ESPN, sorry about that), you have to do this on all computers that run Remote Desktop since it’s the app that stores the settings.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Kickstarting ARD

The Command Line Fibre Channel Management and Setting up the Network Stack from the Command Line articles I did on Xsanity covered a couple of tasks that you more than likely perform on every client system you setup.  Now let’s look at another.   Whether you are deploying Xsan or managing it, assuming you have more than 1 machine to manage (and why would you use Xsan if you don’t) then a little Apple Remote Desktop (ARD) can make your life a lot easier.  You might be deploying a package to install the Final Cut Server.app or you might be installing Xsan remotely.  Or maybe you’re quitting Final Cut Pro or closing a Finder window so that you can unmount that volume that otherwise just won’t unmount.  Either way, centralized administration almost requires you to enable Remote Management and if you’re looking to automate every aspect of a deployment then you’ll certainly be doing so.

To enable Remote Management for the ARD client is easy enough.  Simply open up System Preferences, click on the Sharing System Preference pane, check the box for Remote Management and then check the boxes for the features you’d like to enable (eg – Observe, Control, etc).  By default, all users have access to do whichever tasks you define.  Straight forward enough…

But what if you are deploying 40 Xsan and Final Cut Server clients, 2-3 Metadata Controllers along with 20 members of a render farm?  Let’s just say that during the process you decide that you need to limit only your companies admin account to control the computers (otherwise users will start messing around with one anothers stuff)?  Even if you enabled Remote Management at installation time, now you need to go touch 65 computers?  Or what if you can SSH into a metadata controller but not tap in through Remote Management?  Or need to configure that shiny new Xserve that didn’t ship with a video dongle?

Enter kickstart.  The kickstart command is located in the /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources directory (the rest of this article assumes this to be your working directory, and assumes you are running these commands with elevated privileges).  To start off, we’re going to configure Remote Management.  To do so we’re going to use the -configure option with kickstart and enable access to the host (-access), checking all the boxes from the Remote Management Options… button (-privs -all) for the xsan admin user (-users xsanadmin):

./kickstart -configure -access -on -privs -all -users -xsanadmin

You can also enable access to Open Directory accounts if your Xsan includes those.  In the following we’ll configure Remote Management to allow Open Directory logins (-setdirlogins yes and then enable the specific groups that will have access (-setdirgroups -dirgroups) to the Open Directory group called xsanadmins:

./kickstart -configure -clientopts -setdirlogins yes -setdirgroups -dirgroups xsanadmins

You can also configure each of the check boxes for each permission independently, using -DeleteFiles, -ControlObserve, -TextMessages, -ShowObserve, -OpenQuitApps, -GenerateReports, -RestartShutDown, -SendFiles, -ChangeSettings and -ObserveOnly.

The global options for the Remote Desktop client can also be set.  To do so you would add the -clientopts option and specify which of the features to configure. Other than the Directory Services options, these include those settings accessible through the Computer Settings… button.  Show Remote Management status in menu bar can be enabled using -setmenuextra yes.  Anyone may request permission to control screen can be enabled using -setreqperm yes.  VNC viewers may control screen with password can be enabled using -vnclegacy yes.  You can also set the password using -vncpw followed by the password you would like to use.  You can also set the Computer Information fields using -computerinfo followed by -set1, -set2, -set3 and -set4.

But kickstart isn’t just for setting up the ARD client.  You can also restart Remote Management when you are having problems by running the -restart option when SSH’d into a host:

./kickstart -restart -agent -console

And what the Xsan admin giveth the Xsan admin can taketh away; you can disable Remote Management access by setting -access to off:

./kickstart -configure -access -off

You can also use kickstart to install and uninstall packages, but in my experience you’re gonna’ want to use the Remote Desktop software to do that.  For more on the options available in kickstart, check out:

./kickstart -help

Finally, if you would rather perform a file drop to deploy settings (or use the defaults/plutil commands to deploy settings) then you’ll need to know the property lists, or domains that the preference files are stored in.  Because kickstart is not compiled you can find these in the variable definitions at the beginning of the script.

Mac Security

ARD Root Escalation Using AppleScript

They can explain it better than me:

http://it.slashdot.org/it/08/06/18/1919224.shtml

(this has been fixed with the August 2008 Security Update).