With the end of the year growing close, the nights growing long, and a foot of snow paralyzing a completely unprepared Seattle, our thoughts here at Make Mac Work turn to all the gifts we've received this year to make our jobs easier.
So we've collected some of our favorite free tools for Macintosh administration. We feel enormously lucky to have received these gifts from their developers, and we're sharing them here in the spirit of giving.
Some of these utilities we've already reviewed, some we're reviewing in the upcoming months, some of them we use every day, while some we only tinker with. But every single one of these applications is highly recommended, and completely free.
AirRadar:
There are many wireless scanners for Macintosh, but none as customizable or pleasant to use as AirRadar, Koingo Software's beautifully-designed and profoundly Mac-like little application.
Flame:
More a proof-of-concept that a full-fledged application, Flame is nonetheless invaluable for tracking down unsanctioned Bonjour sharing on your network. Simple, functional, and free.
FSEventer:
Fern Lightning's FSEventer doesn't just log file system changes, it charts them graphically in real time. Wonderful for understanding the systems you're supposed to keep running, and the horrible things that software does to them.
Lingon:
Peter Borg's handy front-end for Leopard's complex launchd doesn't make building system daemons easier, but it does make it faster. We've reviewed Lingon before, and we've only used (and liked) it more since then.
Password Expiration Checker:
If you've got Macs bound to Active Directory, this little AppleScript can be set as a login item, warning users that their AD password is set to expire. It may only do one thing, but Peter Bukowinski's Password Expiration Checker does one thing that's badly needed.
QuotaMonitorMenu:
Great for users new to Portable Home Directory environments, Adam Gerson's QuotaMonitorMenu displays how much space their account has left on the server. Another single-feature utility that should have come with the operating system.
Suspicious Package:
By bringing the convenience of Leopard's QuickLook to the arduous task of vetting software installers, Suspicious Package from Mothers' Ruin Software manages to be both deeply geeky and extremely elegant.
Time Machine Perspective:
Pierce T. Wetter III hacked the open source disk space monitor GrandPerspective, tuning it to only find files Time Machine had backed up once. Time Machine Perspective helps prune backups of unwanted cruft, reclaiming valuable disk space.
Wireshark:
Despite it's colorful GUI, Wireshark is anything but easy or friendly. Instead, this enormously popular Unix tool is the most powerful weapon in your network troubleshooting arsenal. Learning it could be the best gift you get yourself this year.
Special Thanks: Our friends Damien Barrett, Eddie Kelley, Jasson Lewellen, Aaron Robinson, Shayne Sandison, and Craig Swanson all helped compile this excellent holiday offering. Thanks to everyone, and we'll see you all in the new year...
Posted on 22 December 2008 by Ellis Jordan Bojar
If you've tried to upgrade Tiger server to Leopard, you've probably already learned that it's a bumpy road. The process is so fraught with bugs that Apple themselves recommend against it in their Server Essentials manual, stating it should never be preformed on "production" machines. Unfortunately, not every organization has a spare XServe to experiment on, and those sharing files off internal disks may not want the hours of data shuffling that installing from scratch would entail.
The issues inherit in a Leopard Server upgrade can be addressed quickly and easily if you know what to look for. With a little advance preparation, and this article as a checklist, you can make sure the process is safe and successful for most OS X installations.
You'll want to have checked in advance that any third-party applications you need run on Leopard, and you'll definitely need a known-good backup in case something goes awry. Now let's get started.
Document Server Settings:
The big problem with the Leopard upgrade isn't that it loses data. In fact, it's the opposite, with the newly upgraded volume turning on new services, adding duplicate users, or even sharing out random (and sometimes private) directories. The most important part of the process, then, is to document all your Server Admin settings prior to upgrade. You'll want to have notes (or screenshots) detailing all your DNS zones, web sites, firewall configuration, etc. If your team doesn't already document all their server settings in a change log, now's the time to catch up on the paperwork.
Archive Open Directory:
The next step you'll want to take is to export all your Open Directory settings. This includes not just your users and groups, their passwords, their managed preferences, but also all your Kerberos and Password Server data. After you've upgraded your server, you'll restore this information to insure nothing's been corrupted in the upgrade process.
You can do this easily by using the "Archive" pane in the "Open Directory" options of Server Admin. Simply click the "Choose..." button to set the location the collected data should be saved to, then click the "Archive..." button to set the name and password for the disk image that's created. Type very carefully, and since the password isn't verified before the image is created, test that you can open it before you proceed.
Install Leopard Server:
With your preparations made, you can run the Leopard Server install normally. You'll be asked to enter your new Leopard serial number, but otherwise the process shouldn't require any configuration. The upgrade takes about a half hour on the current generation of XServe, and you can fill the time by downloading any recent updates you plan on installing. When your server reboots, it'll likely have a host of services you don't want turned on, so it's best to restart it with the network cable unplugged.
Reconfigure Services:
If all went well (or at least as expected), you should now have a fully functional Leopard Server. Maybe a little too functional, even. Leopard tends to turn on a bunch of undesired services during the upgrade process. Was your XServe an email or NFS server previously? There's a good chance it might be now.
Open Server Admin, and select the your local machine from the left column. Now take a good, hard look at the services listed below it. Turn off the services you weren't running prior to upgrade, then check your remaining service settings to make sure nothing unexpected has been added or changed. If you don't need Apache 1.3, it's a good time to upgrade to version 2.2 in the Web options as well. Now it's time to plug back in the network cable and wrap up the job.
Restore Open Directory:
Now that the rest of the damage has been undone, you'll want to clean up your account information. If your server remained an OD master through this process, you're in luck. Otherwise, you'll need to promote it in the "Settings" pane of the Open Directory options, then return to the "Archive" pane.
Choose the archive disk image you made earlier, and click "Restore..." to return your Open Directory domain to it's pre-upgrade state. Once you've confirmed Open Directory accounts work locally, test each of the services you're offering over the network as well, making sure that everything functions as it did prior to the upgrade process.
And voila! While not exactly fast or automatic, you should now have a newly upgraded and properly functioning Leopard Server. Now you can go find out what's going to break when you upgrade your client machines...
Recommended Reading: While it may contradict some real-world experience, Apple nonetheless publishes an excellent guide on Upgrading and Migrating 10.5, essential reading for anyone planning a complex upgrade to Leopard Server.
Posted on 15 December 2008 by Ellis Jordan Bojar
Disk mirroring, where data is written to two disks simultaneously, is a great low cost method to protect against single-disk failure and improve read-intensive performance. Apple's Disk Utility provides an easy way to set two disks up as a RAID mirror at installation, but once the operating system has been installed OS X can't mirror an existing drive without reformatting and reinstalling.
What began as a missed opportunity in Tiger became a buggy implementation in Leopard, and in the past year the procedure for mirroring an existing volume has changed no less than three times. This is an essential feature for storage management, and it inexplicably still only works from the command line. While not the most convenient, this method works with any Tiger or Leopard machine.
This process has the potential to destroy all the data on your machine, so make sure you have a current backup of the drive you're going to mirror and confirm the backup is both restorable and bootable. Next, if you're mirroring your existing startup disk, you'll need to boot off an installation DVD or external drive for the first part of the operation. When you're ready to proceed, type the following into the Terminal:
diskutil list
This will produce a listing of the attached disks, along with their types, names, sizes, and identifiers, like so:
/dev/disk1
#: type name size identifier
0: Apple_partition_scheme *465.8 GB disk1
1: Apple_partition_map 31.5 KB disk1s1
2: Apple_HFS Server Disk 465.6 GB disk1s2
Use the name of the volume you wish to mirror to find it's identifier. If your machine only has one internal hard drive, for instance, the identifier of your boot volume will most likely be disk1s2, the second slice (after the partition scheme and map) of disk 1. Once you've determined which disk you're working with, type the following, replacing IDENTIFIER appropriately:
sudo diskutil enableRAID mirror IDENTIFIER
If all goes well, the disk will unmount, reappearing in the Finder a moment later along with "The disk has been converted into a RAID" reported in the Terminal. At this point you can insert the additional disk you wish to use in the mirrored RAID array (assuming it's not installed already), then reboot the machine off the original drive.
Now when when you run diskutil list from the Terminal you should see two new listings, one for the new virtual RAID array (the one without slice information) and the other for the additional physical disk you installed.
/dev/disk2
#: type name size identifier
0: Apple_HFS Server Disk *465.6 GB disk2
/dev/disk3
#: type name size identifier
0: GUID_partition_scheme *465.6 GB disk3
1: EFI 200.0 MB disk3s1
2: Apple_HFS New Disk 465.4 GB disk3s2
Now with the necessary identifier information, you can assign the physical disk to the mirrored RAID array, replacing RAIDARRAY with the RAID volume (in our example disk2) and NEWDISK with the hard drive being added (here disk3):
sudo diskutil addToRAID member RAIDARRAY NEWDISK &
How long the RAID mirror takes to build depends on how much data is on the original volume, but the ampersand at the end of the command tells it to run in the background. When the process is completed you'll have two fully mirrored and redundant disks, built from your existing installation without ever having to erase the original volume.
Posted on 8 December 2008 by Ellis Jordan Bojar
One of the best features of OS X is the built-in ability to clone a customized installation to other machines. By creating a .dmg image of an existing installation in Disk Utility, then using the "Restore" feature to copy it to another disk, you can install a pre-configured OS onto any number of Macintosh workstations.
As much time as this saves, however, you're still cloning one machine at a time. What if you have tens or even hundreds of machines in your organization? Fortunately, there's a built-in system to handle that as well. All you have to do is deploy NetInstall.
Creating NetInstall Images:
Ten years ago, when Apple's administrative tools were aimed more squarely at academia, schools began using NetBoot to deploy their lab machines. By booting workstations off a central server-side system image, machines could run custom configurations that reset cleanly for each user. NetInstall was built on that same technology, allowing your servers to host similar custom images, but install them over the network onto each machine's local disk.
Creating that image is now done with the System Image Utility, found on OS X Server in the /Applications/Server directory. While an image can be built directly from the OS X installation DVD, they're hard to customize and seldom up-to-date. You're better off creating a customized installation on an external drive (or saved as a disk image), then mounting it on your server. While Leopard theoretically allows network installation onto both Intel and PowerPC hardware from the same image, preparing separate images can save time and frustration in the long run.
When you're ready, launch System Image Utility, and in the "Create an Image" window select "NetInstall Image". Click "Continue", then on the next screen enter a name and description of the image you're preparing. For basic deployment just click "Create", and save the image in the default location of /Library/NetBoot/NetBootSP0. For more complex configurations, click "Customize" to add post-install scripts, filtering by hardware type, or allow more client-side installation options.
You may want to go take lunch while your image builds, but when it's done you can repeat the process for each image you'll need to deploy over your network.
Configuring The NetBoot Service:
Once your images are prepared, the next step is to configure NetInstall on your network. Launch Server Admin and select the NetBoot service from the left column. Click the "Settings" icon in the toolbar, then choose the "General" pane. Here you'll choose the network interface for NetInstall to run on (typically Ethernet 1), and the volume to store images and client data (the system array, in this example, though you may prefer another volume if you're mixing NetBoot and NetInstall).
Now move to the "Images" pane. Check "default" if you've got a single image, or there's an image you'd like to force if one isn't specified. Next check "enable" for each of the images you're planning to deploy, and choose the protocol over which you'll offer them.
The NetBoot service can run over either HTTP or NFS. Given that most companies filter HTTP traffic, or engage some kind of web proxy for port 80, utilizing NFS is usually the better choice. In these circumstances, be sure to allow traffic over port 1049 on your internal network.
With these options set, click "Save", then click "Start NetBoot" to take the service live.
Configuring Clients For NetInstall:
Once NetInstall is running happily on your network, all that's left is to boot your client machines. If you're only offering one image (and you've marked it as the "default" in the "Images" pane), you can simply restart your machines while holding down the "n" key. If you're offering multiple NetInstall images, open System Preferences on your client machines, and choose the appropriate image to install from the "Startup Disk" pane. When you restart, the computer will boot into the installer automatically. You'll need each computer connected to the network during this procedure, and you'll save yourself a world of trouble if they're using ethernet rather than wireless.
That's all there is to it. Allowing you to save hours, if not days, of work on every rollout, NetInstall is one of the most powerful, and easiest, tricks up the Macintosh administrator's sleeve.
Recommended Reading: There's no better, or more extensive, explanation of BSDP (the protocol on which NetInstall is built) than the amazing How NetBoot Works by the even more amazing Mike Bombich.
Posted on 1 December 2008 by Ellis Jordan Bojar
While a lot of iPhones sold to corporate customers are connected to the company's Exchange server, even more float around officially unsupported. At least until something goes wrong. When your VP of Marketing signs a two-year contract on a new toy, your IT department has just gotten into the iPhone business. Which is why it's so frustrating when you see a message like this sitting in your trouble ticket queue:
iTunes cannot sync information with the iPhone "3G" because
syncing has been disabled on this computer.
The dialog even offers you the opportunity to enable syncing again, but the option doesn't actually result in anything. Once this error appears, you can't synchronize any of the data in the iTunes "Info" tab (including contacts, calendars, bookmarks, and mail accounts), though music, picture, and video syncs work normally. Home users might not notice for months, but if an iPhone is meant for business this issue renders it basically useless.
The problem is corrupt SyncServices data, the system that keeps track of information between Macintosh systems and applications. The solution is to delete the the files in ~/Library/SyncServices and ~/Library/Application Support/SyncServices, log the user out and back in, then reset the sync preferences in iTunes. This forces OS X to rebuild the SyncServices database, resolving the issue.
Posted on 19 November 2008 by Ellis Jordan Bojar
Earlier Posts »
