Apple has released the client and server updates for Apple Remote Desktop. Both are now available on the App Store. For official information of the server update, see http://support.apple.com/kb/HT5896?viewlocale=en_US.
New features include:
The client update documentation is at http://support.apple.com/kb/HT5896?viewlocale=en_US&locale=en_US.
krypted October 24th, 2013
SSH allows administrators to connect to another computer using a secure shell, or command line environment. ARD (Apple Remote Desktop) allows screen sharing, remote scripts and other administrative goodness. SNMP allows for remote monitoring of a server. You can also connect to a server using the Server app running on a client computer. To enable all of these except SNMP, open the Server app (Server 3), click on the name of the server, click the Settings tab and then click on the checkbox for what you’d like to enter.
All of these can be enabled and managed from the command line as well. The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in OS X Mavericks Server (Server 2.2). 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.
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
When you enable SSH from the serveradmin command you will not see any additional checkboxes in the Sharing System Preferences; however, you will see the box checked in the Server app.
To enable SNMP:
sudo serveradmin settings info:enableSNMP = yes
Once SNMP is enabled, use the /usr/bin/snmpconf interactive command line environment to configure SNMP so you can manage traps and other objects necessary.
Note: You can’t have snmpd running while you configure SNMPv3. Once SNMPv3 is configured snmpd can be run.
To allow other computers to use the Server app to connect to the server, use the info:enableRemoteAdministration key from serveradmin:
sudo serveradmin settings info:enableRemoteAdministration = yes
To enable the dedication of resources to Server apps (aka Server Performance Mode):
sudo serveradmin settings info:enableServerPerformanceMode = yes
krypted October 22nd, 2013
Posted In: Mac OS X Server
Tags: 10.9 server, Apple Remote Desktop, ARD, Command line, enable remote access, enableARD, enableSSH, Mac Server, OS X Server, remote server app, server 3, server.app, serveradmin, serveradmin settings info, snap, ssh
When you’re kickstarting ARD/Screen Sharing, you might notice times when you are asked if you want to connect to the local logged in user or to a new session, which shows the login window. In most cases, I want to connect to the console user, or that locally logged in user. To go right there, instead of seeing the OS X login window, you can use the defaults command to write a VNCAlwaysStartOnConsole key (boolean, true) into com.apple.RemoteManagement.plist in /Library/Preferences, as follows:
defaults write /Library/Preferences/com.apple.RemoteManagement VNCAlwaysStartOnConsole -bool true
krypted October 20th, 2013
The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo serveradmin start swupdate
To stop the service, replace start with stop:
sudo serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo serveradmin swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.
Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.
krypted August 5th, 2012
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.
‘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!
krypted June 28th, 2012
Posted In: Mass Deployment
The latest update of Lion for Mac OS X 10.7.2 comes with an interesting new option, where it prompts users to log into iCloud. This setting is stored in com.apple.SetupAssistant.plist in the DidSeeCloudSetup key. Configuring the boolean with a positive value then suppresses the prompt for the user:
defaults write /System/Library/User Template/Non_localized/Library/Preferences/com.apple.SetupAssistant DidSeeCloudSetup -boolean YES
If you have configured it and you want to run it again, just revert to NO:
defaults write /System/Library/User Template/Non_localized/Library/Preferences/com.apple.SetupAssistant DidSeeCloudSetup -boolean NO
These commands can be sent out through Apple Remote Desktop, or some other patch management system.
krypted October 15th, 2011
Posted In: Mac OS X
Lion comes with this nifty option called AirDrop, which allows users to share files directly. In many environments, this represents a perceived security risk (whether real or not) and must be disabled. To disable AirDrop:
defaults write com.apple.NetworkBrowser DisableAirDrop -boolean YES
To turn it back on:
defaults write com.apple.NetworkBrowser DisableAirDrop -boolean NO
This is done per-user and so can also be done via Managed Preferences, profiles and/or at imaging time.
krypted September 10th, 2011
DigiNotar got hacked awhile back. And more and more issues seem to continue to surface as a result (most notably spoofing Google). Read this article for more info on it, but I’m not gonna’ rehash it all right now. Instead, let’s correct it. To do so, we’ll use the security command. Then we’ll use the delete-certificate option along with the -Z operator, which allows inputing (or outputting when installing certificates) a SHA1 has of a certificate. Root Certificates (those that appear under the System Roots section of the Keychain Access application) are all located in the /System/Library/Keychains/SystemRootCertificates.keychain keychain and so we’ll specify that as well:
sudo security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C "/System/Library/Keychains/SystemRootCertificates.keychain"
And that’s it, push out the security command through ARD or a policy and you’re untrusting DigiNotar. To verify removal, use the find-certificate option and either attempt to find via the SHA1 hash (-Z again) or use the email address as follows:
security find-certificate -e email@example.com "/System/Library/Keychains/SystemRootCertificates.keychain"
Keep in mind that the certificate can always be re-added to the SystemRootCertificates.keychain when they get all their little issues sorted out.
krypted September 7th, 2011
In Mac OS X 10.5-based Open Directory (or higher) and Apple Remote Desktop 3.3 (or higher) you can now add directory services objects as computer lists. Simply open Apple Remote Desktop from a bound computer, click on Scanner and then click on the drop-down list for the type of scanner. Here, select Directory Server and you should start to see your Open Directory objects populating the list, obviating a previous article on populating lists at deployment time.
BTW, if you’re interested in creating computer lists based on Active Directory, start with cn=computer_lists.
Note: Turns out Randy Saeks has also done an article on this topic. Find it here: http://rsaeks.wordpress.com/2009/11/23/using-opendirectory-computer-lists-with-apple-remote-desktop/
krypted October 17th, 2009
In order to enable a system to be used as a Task Server, open Remote Desktop, click on the Remote Desktop menu item and click on Preferences. Then click on the Task Server tab and click on Use Task Server on this Computer. Then check the box for Allow Remote Connections to this Server.
To utilize the task server that you have just setup, go to one of the computers that will use Remote Desktop for management and open Remote Desktop, click on the Remote Desktop menu item and click on Preferences. Then click on the Task Server tab and click on Use Remote Task Server. Then enter the address of the remote task server and close the window. This will enable your system to take use of the newly integrated Task Server.
Task Servers are primarily used for pushing out packages and scripts, not for Control and Observe functionality.
krypted April 14th, 2008