This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from, and , these chapters are available only to ; see  for details.
Assuming you’ve worked your way through this book in order, congratulations! You should have a fully functional server that’s providing you and your users with the services you need. I’ve sprinkled a variety of maintenance tips that are specific to different services throughout the book, but to close out, I want to offer some general advice to keep your server running happily.
Don’t assume that you need to do much here—I’ve visited clients for whom I’ve installed OS X Server years before to find that the uptime on the server is over 1,000 days (that means nothing was rebooted for 3 years!). That’s pretty impressive, if only in that they didn’t install new versions of OS X or Server itself, suffer a power outage, or even need to move the server for 3 years. You shouldn’t expect that level of stability in every situation, especially given the move to annual major releases of operating systems.
No person is an island, and neither is a system administrator. There’s a strong sense of community among Apple system administrators because we’ve all gone through the same things, good and bad. So if you have a problem or are confused about something, there are a number of places you can ask for help. And of course, if you run across a particularly useful tip, please share it! Here are a few of my favorites:
Part of being a system administrator is responding to the unexpected. That’s why you turned on alerts in, back in Chapter 3, . Server will notify you when various things go wrong, and you should deal with them as they come up. Some things that you might encounter include running out of disk space, OS X Server updates, certificates expiring, and so on.
Plus, you’ll undoubtedly hear about problems from your users or from the outside. If you’re running a mail server, for instance, and it ends up on an RBL, the monitoring service you configured in, in Chapter 8, , will send you an email alert. Or, if a user is having problems that might be solved by an update you’ve delayed releasing (see  in Chapter 12, ), you may get a direct request to enable that update.
A few tips then, about what to do in some common situations.
Updates to OS X Server should be installed only if you need the fixes or promised new features. I mean it—if your server is running well, why mess with it? Most problems I’ve seen are caused by changes we administrators make to our systems. Therefore, I recommend a one- to two-week cooling-off period before installing any major updates on your server, either to OS X in general or OS X Server in specific.
When you are ready to update, first look around on the sites mentioned above to see if others are reporting problems related to the update. If you don’t see anyone complaining about any problems—and trust me, people will complain if there are issues!—you can move ahead with the update, preferably at a time when most users won’t be impacted by downtime.
Before you install the update, make a separate bootable duplicate of the server, just in case something goes wrong during the update or the upgrade causes any unexpected problems. (And you are backing up the server in general, right?) You can make your bootable duplicate with a tool like or . Once you have a good clone of the server to fall back on, use Software Update to install the update.
Once the update is complete, make sure that everything works as intended, and even if it seems fine, keep a close eye on your services for a few days!
The boot volume should fill up on a server only if your service data is on that drive, which is likely if your server has only a single drive. When this happens there are a few things you can do, listed in order of increasing difficulty:
As I mentioned above, when a shared folder causes a drive to fill up, the easiest thing to do is move the folder. To do so, first let everyone know that the share in question will be unavailable for a while. Next, I recommend taking a screenshot of the existing shared folder’s settings, so you have a record of what its name is, what the permissions are, and what services have been enabled (Figure 1).
Then, either stop the File Sharing service entirely or if you have other shared folders that should remain available, deselect the selected Share Over checkboxes. This step ensures that no files will be changed while you’re moving data.
Next, create a folder on the new drive with the same name as the old shared folder. (It’s not essential to maintain the same name, but it’s usually a good idea.) Then copy the data from the old shared folder to your new folder, and recreate the shared folder in Server with the same settings.
Once everything is configured and file sharing is enabled again, test the new shared folder. In particular, be sure to test any aliases you or other users of the server may have created to files or folders on the server.
It’s a good idea to check in on your server every week to make sure it’s running smoothly. But it’s also all too easy to get busy and forget to do these tasks, so I recommend putting a recurring event on your schedule.
Obviously, files can’t be saved to a drive that doesn’t have enough free space, and worse, OS X can slow down or even crash if the boot drive runs out of space. I’ve discussed how to address this problem earlier in this chapter, but ideally you’d anticipate the need for more space well in advance of it becoming a problem. To do this, you should keep track of the free space on your server's drives, as well as on how quickly they are filling up.
In general, every drive should have at least 10 to 15 percent of its overall space free. But keep in mind, storage is relative to how the drive is used. For example, for a drive with 10 GB of free space that’s being used to share a small database, that amount of free space might be fine. But if your users are editing video, 10 GB of free space could be consumed before lunch.
A number of services can track things like free drive space for you, such as (which can report on over 100 different issues). But for just drive space, I recommend looking at your drives manually. You could do this in the Finder by selecting a drive and choosing File > Get Info, though you undoubtedly knew that. For a faster check of all mounted drives, the Storage screen in the Server app is the easiest. Click the name of your server in Server’s sidebar, and then click the Storage button (Figure 2).
Free space is an important metric to track, but so are memory and CPU utilization, especially once you have a full complement of users hitting your server. For this, I like using two tools: Server itself and Activity Monitor.
On a weekly basis, it’s a good idea to glance at the Stats screen in Server; just click Stats in the sidebar. In the Stats screen, you can get a sense of the overall performance of the server by four metrics and over periods of time ranging from 1 hour to 7 days (Figure 4).
The graphed metrics you can see in the Stats screen include:
Server’s Stats screen is useful for the historical overview of what has been happening on the server, but it’s not at all helpful when it comes to figuring out what’s happening now or what process is causing some sort of a problem. For that, turn to Activity Monitor, which is installed by OS X by default in
In Activity Monitor, I mostly look at the CPU and Memory panes; switch by clicking the buttons at the top (Figure 5). To get a sense of what’s happening, click the %CPU column header (in the CPU screen) or the Memory column header (in the Memory screen) to sort the list of processes by that column. You may have to click it again to see the piggiest processes at the top—those that are using the greatest percentage of the CPU and the most RAM.
The other panes—Energy, Disk, and Network—can occasionally provide some insight into a problem, but are less useful than CPU and Memory.
Modern Unix-based operating systems like OS X are extremely chatty, logging all sorts of messages and errors for troubleshooting purposes. The same is true of the applications that run OS X Server’s various services, and if you’re having a problem with a particular service, you should always start the troubleshooting process by looking at its logs.
However, it’s also worthwhile to scan logs every so often to see if something might be happening that neither you nor your users have yet noticed. That said, don’t worry too much about errors; Unix apps are loquacious to a fault, and many “errors” are irrelevant to normal usage. If you’re uncertain, run some Google searches on the error text, removing anything specific to your server, like its name. If others have discussed the error and included the same error text, those pages can help you figure out whether it’s interesting data or just background noise.
As with processor and memory usage, Server includes a Logs screen that does a nice job of showing each individual service’s logs, along with the general System Log. There’s nothing wrong with using Server’s Logs screen for these weekly checks, but to track down a problem, I prefer using Console, another bundled utility with OS X that’s in
Console is a more capable log viewer than Server (thanks largely to being able to filter the log to just those entries that match a search term, rather than just being able to search for a term, as Server can do), and it helps with connecting a log entry with similar events in the same time frame. That’s key because many issues are caused by something from another service or a process that’s entirely outside OS X Server.
Each service will have a different pattern to search for. Any entries that start with
mdworker, the most common entry in most logs, indicate that Spotlight is indexing a drive. You can likely disregard any issues there.
servermgrd, shown in Figure 6, contains information about the global service and then most logs in Server will be called out by the impacted service (unless they’re a part of
Once you identify the log entries of interest, run some Google searches on them to see if you can find some indication of what they mean. And if all else fails, ask in one of the venues I mentioned earlier, in.
If you’re running the Software Update service (see in Chapter 12), you may wish to release software updates to your users on a regular basis so they can become accustomed to updates appearing over the weekend, say, or on Wednesday mornings.
When it comes to backups, the most important thing is consistency. Years ago, I developed a checklist to ensure that I’m executing my backup strategy properly, and versions of this checklist are still in use by my old consulting company and by many of my former clients.
It starts with checking backup logs to see if any files were skipped. It then has me rotate my offsite backup drives (or replace tapes or make sure my cloud storage hasn’t evaporated). The checklist also keeps me honest by making me test a restore of some backed-up data to verify that the backups are working.
Every environment will have specific things you consider to be important. Decide what’s important to you and make your own checklist to run through each week.
A weekly schedule would be overkill for some tasks, so consider settings aside a few minutes at a regular time each month for tasks aren’t likely to crop on an weekly basis but still need to be done periodically.
As users leave, you should disable their accounts to prevent them from becoming security holes. You don’t want to keep those accounts in the system indefinitely, though, so after a cooling-off period of about a month, I recommend deleting those disabled accounts.
Although this is something of a personal preference and is most important in a situation where the server can be accessed by multiple people, I like to change the password of accounts that can administer my server routinely. Monthly password changes would be excessive for some environments, but I’d change them at least quarterly.
Keep in mind that by the time you’re done setting up a server like this, you may have created a Directory Administrator user, a local administrative user, the root user and local network user, all with administrative access. If you’re changing passwords for security reasons, you need to change the passwords for all these accounts and any others that can administer the server.
Finally, we come to those tasks that come up extremely infrequently. It’s not so much that you need to do these every year in January, for instance, but that they may need to be done once a year or so.
The Apple Push Notifications certificate needs to be renewed every 2 years. If you have set up alerts (see, in Chapter 3), you will receive a routine alert indicating as much.
Renewing is simple. To do so, in Server, click the name of the server in the sidebar, then click the Settings button. Click the Edit button for “Enable Apple push notifications” and then click Renew (Figure 7).
You are prompted for the Apple ID credentials associated with the certificate. Enter them and then click OK to complete the process.
Think of drive maintenance like taking Omega-3s to keep your brain in good shape! But while you can’t eat too much salmon, you can perform disk maintenance too frequently, and some people go overboard when it comes to using Disk Utility’s Repair Permissions and Repair Disk options.
I generally recommend these maintenance tools only if the server is experiencing a problem that could be traced to permissions (and only to Apple software; Repair Permissions doesn’t affect third-party software) or to directory corruption. That said, it’s worth using these tools once a year or so, to make sure that problems aren’t sneaking up on you. Always make sure you have a complete backup before running any drive maintenance procedures!
The client whose server hadn’t been rebooted in 3 years notwithstanding, computers really should be rebooted every so often. Certain housecleaning routines run only when the server is rebooted, so at least once a year, when no one is using the server, restart it. You could do this as often as monthly, or you could just reboot the server whenever it starts acting a little funky.
This might seem like a strange task to end the book with. But it does matter, and far more than you might expect. Dust gets into computers, where it coats logic boards and blocks fans, causing systems to overheat and ultimately fail. So once a year or so, shut the server down, open it up, and use compressed air to clean it out well. (While you’re at it, clean your Mac as well!)
I also suggest that you take the opportunity to vacuum the area around the server so there isn’t a lot of dust for it to suck back in, tidy all the cables connected to the server to prevent inadvertent disconnections, and remove any nearby clutter. If nothing else, it shows others that you care about the server both virtually and physically.
Read More: Chapter 12 |  |  |  |  |  |  |  |  |  |  |  |  |  |