Most of my examples for launchctl have been per-user, per-agent, per-daemon. But you can also control multiple launchctl targets concurrently. One example would be that you can unload everything in the user domain by not specifying a path but providing the userid. In the following example, we’ll just use $userid as a variable, but it’s worth noting that that would be, as an example, 501 for the :
sudo launchctl bootout gui/$userid
There’s another option that can be used to do the opposite from within single user mode, called bootshell. Bootshell is called similarly from single user mode:
For those that have had the pleasure of working with certain Windows-based laptops, there may be one particularly crazy-making design choice: the radio-disable switch. To paraphrase Seinfeld, what’s up with that? It’s a ‘feature’ (ahem) not utilized often enough to remind folks they have it, nor explained properly to the customer by the manufacturer. And it can drive IT support personnel nuts, as almost nobody in their right mind turns off wireless access voluntarily… yet it still happens from time to time, causing both sides to be confused for quite some time until they employ Occam’s Razor. And there are various locations it might be on the laptops, too, depending on the vendor and model.
Even on the shinier side of the aisle, sometimes the ‘service order’ as its called on Macs isn’t as we’d like it, especially in the age of USB or Thunderbolt ethernet adapters. Therefore an Apple laptop might look over a wireless network even when a live ethernet cable is plugged in. For myself, in the past I had relied on the order of icons in the top right of the menu bar, using keyboard shortcuts to navigate to the (formerly Airport) Wi-Fi icon to turn wireless off when I got to my desk, and on when leaving.
An item appeared on the Hacker News recently which led me to revisiting my process, sourcing the same illustrious individual who compiled a list of ‘defaults write’ commands which was then dubbed “OSX for Hackers” on news.ycombinator.com (Hacker News). Feeding off the work of another gentleman from back before Lion, they purported to have found a dead-simple way to run scripts that look like application bundles. The comments on that announcement post are littered with folks looking for help, leading one MagerValp to chime in on the Hacker News with “please use Platypus instead, it’ll save you a lot of trouble”
Not one to ignore the word of Per, I looked into Platypus, which did exactly what I needed: I wrapped up two shell scripts that used networksetup, one to turn the power off and one to turn it on.
Now I can launch the ‘apps’ from Spotlight and control airport power, even without my laptop being fitted with an insanity-causing, havoc-wrecking hardware switch.
OK, by now I’m sure everyone has heard that OS X Server is a download off the App Store. For a whoppin’ $50 you get the OS that was once called “Open Source Made Easy” until someone at Apple realized that GPLv3 might mean that Open Source doesn’t always mean “free as in beer”. Wait, did I say that out loud? Point is, there are bigger changes here than just moving the server to the App Store.
There are also some pretty big changes to the GUI of OS X Server. The first and most obvious is the LoginWindow, which is different in OS X in general. It obviously looks different. The ability to click on the items above the username and password is gone. You can still see indicators of green and orange in the username field to indicate directory service availability though, which was one of the bigger things we’ve used that for over the past few years.
Once downloaded, the Server app will be in the /Applications directory, in Launchpad and useable. But the Server Admin tools are a separate (free) download from the Apple downloads page. This is a nice nickel and dime way of keeping the Server app small. Once installed, note that if you open About this Mac, the OS does reflect that you are running Mac OS X Server Lion (not OS X Server Lion btw for all you marketing nerds), so it is actually a registered different version of the operating system.
Now open up Workgroup Manager. The Inspector option in Workgroup Manager is gone. Actually, this is kinda’ true. The option is greyed out in the Workgroup Manager prefs (com.apple.WorkgroupManager.plist) but easily enabled using defaults to add the -dict for “Application Preferences” with a key of “Show \”All Records\” Tab” set to a value of 1. But more importantly, there’s now a tool called the Directory Editor that is part of Directory Utility (still located at /System/Library/CoreServices). It looks a lot like the Inspector, but it’s a bit more appropriate for local stuff.
Now open up Server Admin. Most of the services are gone. We’re left with nat (does anyone really still use OS X Server as a border device?!?!) and a few other services that were either too boring to get moved to the Server app or too unwanted. Expect these to disappear one by one if there are future releases of OS X Server. In fact, if OS X Server is $50 I’d say building a better DHCP (that maybe has a GUI for DHCP options and other cool stuff) or a better DNS is a worthy of a $10 or $20 app on the app store. After all, given the Mini platform it seems a decent platform as a network appliance in that fashion… But back to it.
Now go into Server. Wow. Super easy. The only challenging thing in here is Profile Manager. And the only challenging thing about it is that it a) most people aren’t going to let it build Open Directory for them (but should) and b) some people are going to get stumped when asked for a username and password for a developer account. Get yourself an Apple ID with a developer cert and Profile Manager will be really easy to use, especially if you’re used to working with Workgroup Manager to build Managed Preference manifests. Once in, if you will even note that you can assign specific defaults domains and push keys to clients. Of course, the big thing here is the wipe. The most important thing to note about that is that the clients need to run FileVault and there’s not a great mass deploy strategy for that yet (IMHO).
While I said Profile Manager could be challenging, there are some really cool things waiting for people to start hacking away at. The fist is scripting profile creation and management. Profiles are stored in /var/db/ConfigurationProfiles/Store. Much to the chagrin of 3rd party MDM developers, this solution works great for OS X and iOS. Much to the delight of MDM developers, the whole App Store look and feel that someone like JAMF has is still something that really sets them apart and the ability to have Casper assist you with managing those VPP keys is what will be the crazy huge value add that it will continue to bring to the table. Having said that, a lot of smaller organizations can now use Profile Manager where they might have just used iPhone Config Utility before.
Profiles can be pushed out in a number of ways. The user can download it out of the goodness of their heart. In iOS you’re kinda’ stuck with that deployment methodology. But not in OS X. Help comes in the form of the profiles command, located in /usr/sbin. Profiles is explained further in this other post of mine here.
The serveradmin app (serveradmin list shows a few less results than it used to), slap* commands and other tools server admins are used to are all still there. There’s a better webmail (much, much better), Wiki’s are a little different (not much), NFS (kinda’) and FTP are gone, Podcast Producer keeps getting easier, the twisted stuff (iCal and Address Book Server) is the same as it was in Snow Leopard and Server app gets more functional whereas Server Admin gets less functional. Server got a little easier. Or at least on the outside. But presumably it can, given that it’s likely to be asked to do less than it once was moving forward.
But as with previous versions of OS X Server, there are a lot of settings under the hood that aren’t exposed in any app. Let’s look at the devicemgr service, which is Profile Manager in the GUI:
sudo serveradmin settings devicemgr
One thing I do find interesting is the inclusion of postgres in serveradmin but not in Server app or Server Admin. MySQL is gone, but postgres is there.
You’ll also see settings like mdm_acl and user_timeout that can be pretty helpful (which is why they’re in there in the first place) but aren’t in the GUI. I’m all for keeping GUI’s clean, not giving admins the ability to easily enable something they shouldn’t and keeping away from having screens and screens of rolling settings. So for the most part I’m OK with this. My point with this paragraph (and every paragraph should have a point even though I forget that sometimes) is that if there’s a setting you need that you think got taken out or if there’s a setting that would be cool to have, check serveradmin settings and see if it’s there before just taking the Server app’s word for it…
TFTP, or Trivial File Transfer Protocol is a protocol that can be used for quickly shuttling files about. While similar to FTP, TFTP has no username and password (in most cases) and should not be running when you do not need it. It’s still in use today for a number of appliances such as routers and switches, to get firmware and occasionally configuration files.
There’s a nice little GUI utility that can be used to house a TFTP server on Mac OS X. It’s funny enough, called TFTPServer. You can obtain it at http://ww2.unime.it/flr/tftpserver. Once you have downloaded it, you can open the application and you will be placed into the main application screen. By default, the TFTP server will share out the /private/tftpboot directory. If you’ve already got DeployStudio running then you’ve already got some form of tftp services that you can use and might already have some data in there.
You can change the path (if you use DeployStudio with Windows clients you might not want to or you might break the PXE booting) by clicking in the currentpath field and typing the path to the directory you’d like to share out via TFTP. You can also click on the Change Path button to bring up a browse box.
Once you are satisfied with the directory that you’re sharing out, click on the Start TFTP button. Then, once you’re complete with the tasks at hand that require TFTP go ahead and stop it again by clicking on the Stop TFTP button. If there are any problems with the TftpServer application accessing the data shared out then you will more than likely want to click on the Fix button at the bottom of the screen, which will likely be red. As with TFTP it’s really straight forward to use!
You can also use the tftpd located in /usr/libexec, but most of the time you’ll just need a quick GUI to accomplish a task, which the TftpServer app is great for.
Now as far as TFTP clients go, a number of devices can require you to TFTP into them to upload a configuration file or a firmware version. It can also be helpful for testing functions of the server that rely on TFTP. There is a TFTP command line client located in /usr/bin called appropriately tftp. You can use the get, put and quit verbs much as with other similar tools.
There is also a GUI application for Mac OS X in Mac TFTP client. It’s somewhat dated, but still works. It has a Send and a Receive (Get) option. You simply put the name of the server, select the file and click start. Couldn’t be easier.
DSDebug is a small, quick little tool that just puts a server into Directory Services debug mode, waits for a specified amount of time and then drops a file on your desktop with the logs, placing the server back into a non-Directory Services debug mode. That’s all. It’s mostly designed to send to an Open Directory server’s administrator, tell them to double-click on it and not have to step anyone through typing much. It waits mostly so you can know how long it’s going to wait… Nice, small and compact. In the future I will likely build in a pattern matcher with some known, common errors, color coding, etc (or maybe I’ll forget like I sometimes do) but for now it fits my need so I thought it might fit yours as well… Oh, and it cleans up after itself, deleting the DirectoryService.debug.log file in case you captured a massive log or want to run it later without a bunch of crap already in the file…
It seems like playing an asr stream is still a bit of a conundrum for many people. Apple has added the ability to leverage asr streams in NetBoot images in Mac OS X Server (aka NetRestore), but no tool for actually serving up a stream. That’s why I decided to write a little app to wrap your asr and fire up a quick and dirty multicast asr stream. When you open it, it will ask you a couple of questions and let you select the dmg file that you’ll be serving up. Main points, the data rate, which you can see here.
Then the multicast address that your stream will be served from:
Overall, a little, quick application thrown together. If there is interest I’ll post over at Google Code; otherwise it’s just here for your use if anyone wants it. I’m not much of a graphics guy, so no flashy whatnot by the way…
For those that would like to see a graphical inventory of the files on your system there is Disk Inventory X. Cool little app, although you could do something similar using the command line. But this is a nice little GUI app that shows disk usage statistics in a tree map.