Take Control of OS X Server

Charles Edge

This book is for sale at http://leanpub.com/tco-osx-server

This version was published on 2014-12-03

*   *   *   *   *

*   *   *   *   *

© 2014 Charles Edge

ISBN for EPUB version: 9781615424351

ISBN for MOBI version: 9781615424351

Read Me First

Welcome to Take Control of OS X Server, version 1.0, published in November 2014 by TidBITS Publishing Inc. This book was written by Charles Edge and edited by Adam Engst, Tonya Engst, and Caroline Rose.

This book explains how those in home or small office environments can set up Apple’s OS X Server to provide file sharing, shared calendars, a group wiki, cached software updates, and a Time Machine–compatible backup destination, among much else. This book was written and tested with OS X 10.9 Mavericks and OS X Server 3.2.2, and nearly all the instructions also work with 10.10 Yosemite and OS X Server 4.0 (see What about Yosemite and Yosemite Server?).

Copyright © 2014, Charles Edge. All rights reserved.

Updates and More

You can access extras related to this ebook on the Web (use the link in Ebook Extras, near the end; it’s available only to purchasers). On the ebook’s Take Control Extras page, you can:

Download any available new version of the ebook for free, or buy any subsequent edition at a discount.

Download various formats, including PDF, EPUB, and Mobipocket. (Learn about reading on mobile devices on our Device Advice page.)

Read the ebook’s blog. You may find new tips or information, links to author interviews, and update plans for the ebook.

If you bought this ebook from the Take Control Web site, it has been added to your account, where you can download it in other formats and access any future updates. However, if you bought this ebook elsewhere, you can add it to your account manually; see Ebook Extras.

Basics

If you need basic directions in order to understand what I mean when I talk about working with menus, paths, or any other Mac 101–type topic, please read Read Me First: A Take Control Crash Course, available for free on the Web or as a standalone ebook in PDF, EPUB, and the Kindle’s Mobipocket format.

Following Links in This Book

All blue text in this ebook is hot, meaning you can click (or tap) it, just like a link on the Web. If you click a link that takes you to a different part of the ebook, you can return quickly to where you were if your ebook reader offers a “back” feature.

For example, if you use iBooks to read the EPUB of this ebook, you can click the “Back to” link at the lower left. Or, if you use Preview on the Mac to read the PDF of this ebook, you can choose Go > Back or press Command-[.

Introduction

Do you want to provide file, Web, networking, and other services to computers—Macs and iOS devices, and for some services even Windows-based PCs and Android devices—on a local area network? Or, perhaps you want to distribute content to other computers on the Internet? Or manage iOS devices and OS X computers from a central location? Whether you’re a normal Mac user or an experienced server administrator, you can do all this with a standard installation of Apple’s OS X Server and a little elbow grease!

Long gone are the days when the 10.6 Snow Leopard version of OS X Server cost $499 and required a completely different operating system installation. Now OS X Server is encompassed in an app called Server. It is available in the Mac App Store for $19.99 and installs on top of a stock version of 10.9 Mavericks.

In 2005 when I wrote my first book about Mac servers, they were usually big, expensive beasts running on Apple’s Xserve hardware. Apple smartly retired the Xserve, and now the typical machine you find running OS X Server is a Mac mini. But there’s no requirement that you use a Mac mini or any other particular Mac model. I’ve installed the Server app on everything from an old MacBook Air to a shiny new Mac Pro. You can make any Mac running 10.9 Mavericks or later into a server, using the steps in this book.

Back in the Xserve days, Apple tried to make OS X Server do a lot. It had podcasting, streaming media, and other services that have since been retired. No outsider knows why Apple removed these services. Perhaps a service wasn’t being used enough to justify development, or perhaps it didn’t fit into Apple’s overall plans. OS X Server is still a great solution, provided you use it for what Apple intends (although some of my favorite work has been deploying OS X Server for customers doing crazy things Apple never imagined).

An advantage of Apple dropping some services is that OS X Server has become easier to use, which, combined with the massive price reduction and the simplified app installation, makes OS X Server more accessible to the masses. The adoption rate is up, and a lot more people are taking advantage of what OS X Server can do.

That’s all good, but just because OS X Server is easier to use than ever before, that doesn’t mean it’s something anyone can set up, at least not without help! No matter how easy Apple makes the Server app, Macs running it are still servers, so there are terms, concepts, and procedures that you should understand before you take on server installation and management tasks. Look at it this way: the Server app may provide a friendly interface to configuring various services, but unless you know what to enter and why, things won’t work.

This book is intended for new administrators of OS X Server and for those who want to refresh their Server know-how. Perhaps you’re entirely new to OS X Server but want a centralized file server for your ripped DVDs and so that you can manage your kids’ iPads. Or perhaps you’ve managed OS X Server in the past but are looking to catch up on what’s possible in the current version.

To provide some boundaries, for the purposes of this book I’m going to assume that the average reader has one router (such as an AirPort base station running DHCP and NAT), one network, and one server. In other words, if you’re setting up multiple servers running OS X Server on a campus-wide network where every machine is directly accessible from the Internet, you’ll find good information in these pages, but your configuration will be different by necessity.

Note: Similarly, I don’t go into detail on imaging and Xsan. Both services should have entire books of their own, as their management is complicated and should not be taken on lightly.

Whether you’re an individual user at home or the administrator of dozens of computers in a busy office—and whether you’re a relative beginner or a professional system administrator—you’ve come to the right place to start using OS X Server!

What about Yosemite and Yosemite Server?

It’s not lost on me that OS X 10.10 Yosemite was recently released, and with it came OS X Server 4.0, which we system administrators call Yosemite Server. You’re probably wondering whether this book will still be helpful.

If you’re just getting started now, stick with OS X Server 3.2.2, also called Mavericks Server. You can still buy and install it from this link as along as your server Mac is running Mavericks, not Yosemite. (If you instead search for “OS X Server” in the Mac App Store, you’ll find only Yosemite Server, so be sure to use that link.)

With respect to existing installations, I strongly recommend against upgrading to Yosemite Server right away. The first major releases of a new version of OS X Server traditionally have problems, so I suggest you wait until at least OS X Server 4.0.1 or 4.0.2 before considering an upgrade, and even then only after checking what others are saying (see Additional Resources). And then only on a test machine, not your production server. Smart system administrators are cautious.

That said, the vast majority of the instructions in this book apply to Yosemite Server. The changes found in Yosemite Server that matter for this book are:

The configuration pane for each service has a Permissions button, which provides a new way to access controls for specifying the users and subnets allowed to access that service.

The File Sharing service has an Encrypt Connections option that you can use to secure traffic.

You can enable graylist filtering in the Mail Filtering section of the Mail service.

In short, if you’re already running Mavericks Server, consider upgrading only after Yosemite Server has seen some updates and gotten a clean bill of health from the system administrator community. What you’ll learn here won’t in any way be wasted.

Because the changes appear to be so small between Mavericks and Yosemite, we are hoping to release an update to this title in early 2015 that will fully cover Yosemite. See Ebook Extras for information about how to access any available updates to this title.

Using Terminal with OS X Server

Although the vast majority of the work you’ll do in setting up and managing OS X Server happens in the Server app, it doesn’t account for everything you might want to do. As a result, we’ll use Terminal now and then in this book to work at the command line. I’ll guide you through the commands to use, all of which will be clearly formatted so you can follow along easily.

Over the many years I’ve been installing and managing OS X Server, I’ve learned that having a general comfort level with the command line is helpful. No matter how simple Apple makes Server, every now and then I need to go into the command line. But don’t worry, working at the command line doesn’t mean it’s all that complicated.

And, if you need help with the basics of working on the command line, read Take Control of the Command Line with Terminal, by Joe Kissell.

OS X Server Quick Start

I strongly encourage everyone to read the first three chapters, but after that you can read each chapter independently, focusing on those that correspond with the services you want to run. For example, if your goal in setting up OS X Server is to run a file server for your small business, you need to read only the first three chapters and the chapters on File Sharing and Backup, along with the final chapter on Server Maintenance.

Get started with OS X Server:

Decide which Mac you want to install OS X Server on, with advice about CPU, RAM, disk space, and bandwidth in Choosing Server Hardware.

The most important chapter in the book, Preparation and Installation, shares key network-related steps you should follow before installing OS X Server and walks you through the initial installation and configuration.

Many services in OS X Server depend on the users and groups you set up in Apple’s directory service, Open Directory, so it’s important to set that up early—see Directory Services.

For improved performance and access to internal servers via name rather than IP address, you’ll want to go a bit beyond the basics of OS X Server’s DNS Service.

Set up services for collaboration and communication:

File Sharing discusses how you can set up a centralized repository for files and control access to those files.

The Contacts service enables individual users to share contacts between their devices, but unfortunately it does not enable contact sharing between people; see Using the Contacts Service.

With the Calendar service, users can share calendars with one another without relying on iCloud or another public service. See Using the Calendar Service.

For organizations interested in privacy, the Messages service allows users to exchange instant messages within the local network, without using a public network. See Configuring the Messages Service.

Mail Services looks at the simple task of configuring a mail server and the far more complex task of preparing to host a mail server.

Web Services explains how to set up a Web server running the industry-standard Apache software.

In Wiki Services, you’ll learn how to set up and run wikis and blogs on your server.

Manage devices on your network:

Mobile Device Management looks at Profile Manager, a tool that allows you to control apps and settings, and set up restrictions on Macs and iOS devices. Profile Manager also lets you lock and wipe those devices.

To save bandwidth and control which Apple and App Store updates your users see, you’ll want to Configure the Caching Service and Configure the Software Update Service.

To set up your server as a destination for Time Machine backups for users on your network (just like backing up to a Time Capsule), you’ll want to Enable Time Machine Backups.

Manage your server:

Make a plan for how you’ll Back Up the Server—and carry it out. This is key for ensuring that all your work in setting everything up isn’t lost when a drive goes south!

Once your server is running smoothly, read Server Maintenance for key maintenance tips on how to keep it that way, plus a smidgen of problem-solving advice.

Choosing Server Hardware

Perhaps the hardest part of using OS X Server is getting started. What computer should you use for your server? How much RAM and storage space should it have?

As the carpenter’s saying goes, “Measure twice, cut once.” Rarely is this truer than when planning to deploy a server. The more people who will access the shared resources of the server, the more the saying applies.

There are three main areas to consider: Storage, Server Resources (CPU and RAM), and Bandwidth. Plus, how you configure your server depends on what types of services you’ll be hosting, how many of them you plan to run, and how many users will be connecting.For instance, file servers typically need more storage and bandwidth. Web and database servers typically need more CPU and RAM. Servers managing network services such as Open Directory, DHCP, and DNS are often not taxed at all, so it would be better to have redundant servers than to pour additional resources into a single server.

Note: A particular app that provides a specific type of content to other computers is called a service. Each of the subsequent chapters in the book focuses on a specific service (or two if related).

Running a Headless Server

If you want to keep your server headless most of the time, you’ll control it via screen sharing, so make sure to enable that in the Sharing pane of System Preferences before removing the display.

Also, at least some Macs stop using graphics acceleration when no display is attached, which can result in poor screen rendering performance even via screen sharing. See this article from Softron Media Services on how to trick a Mac into thinking a display is connected.

Other Hardware You’ll Need

Your server should also have a keyboard, pointing device (trackpad or mouse), and display. You can run the server headless, or without these items, but make sure you have them handy (for example, shared with another computer you use) in case your server won’t boot and you need to troubleshoot why.

More important is an uninterruptible power supply (UPS), which provides battery backup in case of power failure. Any machine that you’re setting up as a server will be running 24/7, and in the event of a power failure you at least want the option to shut it down gracefully if the outage is likely to last longer than the UPS’s battery. UPSes also condition power, removing spikes and dropouts that can degrade a computer’s power supply and chips over time. Well-known UPS manufacturers include APC and Tripp Lite.

How large a UPS you should get depends on the Mac you’re using and what else you plan to attach to the server, plus any networking hardware necessary for the server to remain accessible. Both APC and Tripp Lite offer buying guides to help you choose the right model and size of UPS.

Storage

File sizes are growing astronomically. For file servers and backup servers, you really can’t purchase enough storage, and that’s especially true if you’re storing video. There are two elements to consider when it comes to storage:

How much? The total amount of storage should correlate to your needs, with a bit of future-proofing built in.

Throughput: Throughput to storage is especially pertinent for video, database servers, and other data-intensive systems. For most smaller environments, unless you want to stream video, a Thunderbolt or USB 3 storage array is sufficient, with enough space to back up your data. Throughput to storage can mean that the server boots faster, as when using SSD as a boot volume or when performing database lookups; however, for the most part the standard boot volumes will be fine in smaller environments.

Choosing a Storage Vendor

There are numerous storage vendors, making it hard to find quality products that you can trust. It’s also a fast-moving market, so any list here would likely be out of date by the time you read it.

I’m going to go out on a limb and say that you can trust the equipment Apple sells. There are certainly other great vendors, and if you know one that you trust or that’s recommended by someone you trust, by all means purchase from that vendor. Otherwise, check the Apple online store, since Apple vets the equipment they sell.

When planning storage, consider having a smaller drive or partition (maybe 100 GB) as the boot volume and a larger one as your data volume. Separate disks are always fine, but it’s often easier (and a better use of resources) to make multiple partitions on a disk by partitioning it in Disk Utility. Also, separating your data and your operating system keeps the server stable even if you fill up the data drive and, in the event of corruption or failure, lets you restore one without having to restore both.

The only time you want to avoid partitioning is if you’re using SQL databases or anything else that’s disk-intensive, since performance will suffer. In such a situation, each volume should ideally have either its own dedicated drive or dedicated drives in a RAID configuration.

Don’t Forget Backup Storage!

You can never have enough backup storage for a file, database, or Web server. I’ll cover this in Choose Backup Hardware, but the more storage you have, the more versions of old files you can keep and the less likely you are to have to tweak backups manually once you’ve completed setting up the server.

Server Resources (CPU and RAM)

A stock Mac mini or older Mac Pro usually has ample resources for offering basic services such as file serving. When figuring out what Mac to buy or press into service, and how to equip it, you’ll need to keep two basic variables in mind: CPU power and amount of RAM.

There’s no magic formula for planning a server deployment; however, the more services that you will be running, the more memory you will need, and the more users that will access each service, the more CPU you will usually need so that each service can process requests faster.

Can a Mac Do Double Duty?

Can you run OS X Server on a Mac that you’re using for personal desktop operations as well? Yes, but I don’t recommend it unless you’re using OS X Server purely as a personal data syncing solution to avoid using iCloud for contact and calendar sharing with your own iOS devices (and even that’s less necessary now—see the TidBITS article Local Contact/Calendar Syncing Returns in iTunes 11.2).

As soon as you other users are accessing services on your Mac, your need to restart or let your Mac go to sleep is guaranteed to cause interruptions for your users, and that’s equally guaranteed to make them cranky. Do yourself a favor and dedicate a Mac to OS X Server.

What about a MacBook or iMac as a Server?

Although it’s possible to run OS X Server on a MacBook Pro—or even an 11-inch MacBook Air!—I don’t recommend using a laptop as a server. They’re not designed to run nonstop, and they’re likely to have cooling problems.

Conversely, although the iMac works fine as a server, you may not want to dedicate a Mac with a built-in display to server tasks, since you likely won’t be looking at its screen much after setup. Opting for less expensive hardware is fine.

CPU

How heavily each service will be used determines how powerful a CPU your server will need. For some environments, such as a home file server, Apple’s cylindrical Mac Pro would be overkill, unless you’re also using it for home decor. Stick with a Mac mini for a home file server.

On the other hand, if you expect to have more than 50 users accessing your file server, or if your server will be engaged in a CPU-intensive process like video transcoding, then the top-of-the-line performance of the Mac Pro may be welcome. And if your budget doesn’t have room for a new Mac Pro, a previous-generation Mac Pro tower would be a good compromise.

RAM

As I said, the key thing to realize when it comes to RAM is that the more services you run on a single server, the more memory that server should have. For example, if a server is going to run directory services, file services, and shared calendars, plus manage DNS for the network and manage incoming backups, you’ll need much more memory than a server that’s hosting only directory services or file services.

Each service requires memory, and I generally recommend at least 4 GB per service, though many services can’t utilize more than 8 GB. You should always start a Mac server with at least 8 GB of memory and go up from there, depending on how many services you want to run.

When to Add RAM or Buy a New Server

Let’s say you’ve set up a server using an old Mac mini with 8 GB of RAM, and performance is lagging. There are two possible causes: the CPU could be insufficient, or you could need more RAM.

If you can add more RAM, that’s the easiest thing to try. All Mac minis since the mid-2010 model can take up to 16 GB of RAM, so max out the RAM and see if your performance problems disappear. If adding RAM doesn’t help, consider a faster CPU, which in the Mac world means buying a new machine, since no modern Macs accept processor upgrades.

There is one other possible solution. If you can’t add enough RAM to support all the services you want to run, or if you’re concerned that even a faster CPU won’t solve the problem, it may make sense to offload some services to another server and run two, rather than replacing it with a beefier Mac that has a faster CPU and can accept the necessary amount of RAM.

Bandwidth

When it comes to thinking about server performance, you must always keep bandwidth in mind, but it can be a bit more complex than some of the other topics in this chapter. At a base level, you must consider the network interfaces on the clients, the network interface on the server, and the network link between them.

Since all recent Macs have (or can add via an adapter, in the case of the MacBook Air) gigabit Ethernet ports, you’ll get the best performance if client computers access the server using Ethernet (assuming your Ethernet cabling is in good shape and you have a gigabit Ethernet switch) rather than over Wi-Fi connections.

You can run into trouble with Wi-Fi. In theory, 802.11g maxes out at 54 megabits per second (Mbps), 802.11n can hit 150 Mbps, and 802.11ac can go as high as 1.3 gigabits per second. In the real world, though, throughput is dependent on many variables and never reaches the advertised maximums. In short, Wi-Fi is likely to be a lot slower than Ethernet.

The practical upshot is that your server should be connected to your network solely via Ethernet, and any client computers for whom performance is important should also be on Ethernet.

But even then, meeting bandwidth requirements is a growing challenge, thanks to the continual increase in the amount of data being pushed through servers. If you’re deploying a file server, consider how many people will be opening and saving files from your server simultaneously, such as first thing in the morning when everyone comes in, or at the end of the day.

A small ad production company, for instance, might have ten people who have to work on a 5 GB video file. Even if the company’s server is a Mac Pro with gigabit Ethernet, it could take well over a minute for a user to open the file. That’s an eternity.

When you think about bandwidth requirements, note that the potential throughput required is the number of users accessing files multiplied by the size of the typical files accessed. So consider how a typical user would access files and multiply that person’s maximum throughput by the number of users, keeping in mind what your network type can do. For instance, with ten users going over gigabit Ethernet interfaces, you could have a maximum throughput of 10 gigabits, which a single gigabit Ethernet interface can’t provide.

What to do?

Luckily, there are three main ways of increasing bandwidth, and while the specifics are beyond the scope of this book, the following advice should set you on the right path. All of these options can be pricey and are listed in order of increasing expense, but time is money, so if you need the speed …

Provide an interface for each user. Mac Pros have a lot of Thunderbolt ports, each of which can have a Thunderbolt to Gigabit Ethernet Adapter with its own IP address, making it possible for each user to have a dedicated network interface.

Consider bonding multiple Ethernet ports together using link aggregation. To use link aggregation, you need a switch that supports the feature. A beneficial side effect of link aggregation is redundancy: if one Ethernet port goes down, the overall connection remains active, with the remaining ports maintaining connections.

If you’re using a Mac Pro as your server, invest in a 10-gigabit Ethernet interface. This will require 10-gigabit switches and network adapters, plus at least Cat6 Ethernet cabling.

Realistically, most people reading this book won’t need to go to such lengths. If the amount of time users will have to wait for files to open and save is satisfactory to all parties, there’s no need to have more than the standard gigabit Ethernet interface. And if you’re running an outwardly facing Web server on a network with a 10 Mbps uplink, you aren’t likely to ever saturate a gigabit Ethernet interface.

When and Where to Buy

Now that you have a sense of what to shop for, where should you buy it? The Apple Store and Apple resellers can sell you all the hardware you need. Contact them with a list of your requirements to place an order.

When a new model of a Mac first comes out, there’s often a delay in getting it. Plus, most servers are built to order, with faster CPUs and more RAM, so expect to wait 1–3 weeks for components to ship, according to the supply. For example, fibre channel RAIDs usually take a few weeks to ship; however, a stock Mac mini with OS X Server will usually ship on the day it’s ordered.

Ordering hardware is usually the easiest (and costliest) aspect of setting up a server. When you place an order, you can ask your sales professional to give you a sanity check on whether you’re purchasing the right hardware. Unless you’re purchasing a Mac mini with OS X Server, the Server app will be an additional download (covered in Download and Install the Server App).

Plan for Ongoing Costs

Don’t forget about annual costs! When budgeting, consider that you are likely to replace the server every 3–4 years and that Apple servers will get free upgrades to OS X every year or two.

Although OS X upgrades are free, plan on spending $19.99 each time to upgrade the Server app, given that OS X Server typically has a new version that corresponds with the annual release cycle of the operating system.

Also budget time for care and feeding. I usually like to plan on someone spending about an hour per month for each service running on the server. This time is spent troubleshooting, updating, and managing the server and is an approximate average of what I see across the hundreds of servers that my team manages at my office.

Preparation and Installation

Now that you have your server hardware, it’s time to install OS X Server. Don’t worry, though—there’s no reason to be intimidated by OS X Server, largely because it’s just an app, albeit one that installs and manages other apps that provide content to other computers. I’ll guide you through the entire process.

There are a few places where my instructions may seem more complicated than necessary. That’s because I’ve learned over the years that the simplest approach can lead to significant trouble later on. It’s better to put extra effort in at the start to prevent later problems.

This chapter covers getting the server up and running. It’s the most important chapter in the book, and one that almost everyone should read, since the best way to end up with a fast, reliable server is to start from scratch and build it carefully. Only at the very end, when you’re sure everything is working properly, should you put important data on the server.

Key Assumptions

My instructions assume that you’ll be placing your server behind a router, such as an AirPort base station, that will handle assigning IP addresses to computers on your network via DHCP. It’s possible to use the server as a router and/or put the server directly on a publicly accessible IP address; however, I don’t recommend doing so because the security concerns are much higher.

I also assume you’re running a single subnet (a class C, for the technically minded) with a single router. Plus, I assume your server has only a single network interface, without using a virtual LAN (VLAN) or bonding network interfaces.

Starting Over

Don’t panic if you don’t get the installation right on the first try. It’s important to get it right in the end, but there’s no shame in starting over if you do something wrong along the way and things don’t work.

In theory, you can delete the /Library/Server folder and reboot to start over. You might also delete Server-related files in /Library/Preferences and ~/Library/Preferences (everything with “server” in the name other than com.apple.CoreRAIDServer.cfdb in the first folder). I say “in theory” because in practice this often doesn’t work due to cruft hanging around.

For a guaranteed clean slate, boot from another disk or the Recovery partition, reinstall OS X (this is easier if you’ve saved a copy of the installer previously), and run through this chapter again.

If you want to migrate data from a bootable duplicate back to your reformatted drive, resist the urge to do this in the installer, since it will likely bring back some of that cruft. Instead, install OS X, install Server, run through the basic configuration, and, once you’re done, use the Migration Assistant in /Applications/Utilities to bring back applications and account data. Do not bring back any settings!

When you run Migration Assistant, if you cannot deselect any options, you’ll need to back out of Migration Assistant and delete four items from the backup before continuing:

The Server app in the Applications folder

/Library/Preferences/com.apple.serverd.plist

/Library/Preferences/com.apple.servermgrd.plist

The folder /Library/Server

If, after you run Migration Assistant, any previous data appears or any services are turned on unexpectedly, that indicates that you’ll have to reformat and reinstall again, avoiding Migration Assistant entirely and restoring apps and settings from your backup manually. It may be worthwhile to use Bender (see Backing up Server Settings with Bender) to back up (along the way) and restore your settings.

I realize this all sounds fussy, and I apologize for that, but while editing this book, Adam Engst needed to reconfigure Server, and he ran into problem after problem until he resorted to this clean-slate approach.

Understand Network Basics

Just as you needed to plan your server hardware ahead of time, so too should you prepare for the changes necessary on your network: the server needs an IP address that won’t change, and if you want your services to be accessible from the outside Internet, you’ll want to get your head around ports and port forwarding.

IP Address

The most important aspect of any server’s network configuration is that its IP address not change. (If it did, clients wouldn’t be able to find the server on the network.) This is particularly important for OS X Server. Also, Open Directory, Profile Manager, and other services can stop functioning properly if the IP address (or name) of a server changes.

Note: OS X has a zero-configuration networking option, called Bonjour, but don’t assume it’ll be reliable. As a network environment grows, Bonjour’s reliability decreases sharply.

Because there are often unexpected negative consequences from changing an IP address after the Server app is installed, you should always try to limit the amount of change to a server’s network configuration throughout the lifecycle of that computer.

I like to plan the IP address and name of each server even before I install the operating system, ensuring that it’s a static IP address on the local area network (LAN) and a name that won’t need to change. I also recommend that you limit changing the state of the network interface by making sure the server uses only Ethernet and not unplugging the Ethernet cable while the server is active unless you absolutely must.

If clients will be accessing the server from outside your office or home network, you need to ensure not only a static IP address within the local network (see Picking a Static IP Address) but also a consistent external static IP address, if possible.

An external static IP address costs around $5 per month from most Internet service providers, but some ISPs charge exorbitant “business” rates. If you can’t get one, there’s an alternative: a dynamic DNS service, such as Dyn’s Remote Access service (previously called DynDNS Pro). With such a service, a tiny agent application runs on your server and updates the Remote Access service with your new external IP address anytime it changes, so your domain name can always point at the current IP address. If Dyn’s service isn’t to your liking, there are many other dynamic DNS services as well.

Note: A number of routers support dynamic DNS, though this isn’t true of Apple’s AirPort base stations. The agent is simple to install on a Mac, but if you use such a service rather than getting a static IP address, I recommend running the service on the router. Doing so provides one less thing that can prevent access to your server if there’s a problem and you’re physically unable to get to the server.

Ports

A static IP address on your local network is a necessity no matter what, but if you want your server to be accessible from the outside Internet as well, there’s another thing to consider: ports, which enable your server to direct incoming requests from the Internet—for Web pages, email, and SFTP—to the appropriate service. And more to the point, you’ll need to open ports for the specific services you want accessible.

Ports are numbers ranging up into the 60,000s. Each service (or protocol) usually uses one or more preassigned ports (although these can often be customized).

To visualize this, imagine that your server is like a post office. Its street address is analogous to an IP address, and its post office boxes are analogous to ports. Each incoming letter needs to be routed to the appropriate box for pickup by a customer. Ports are akin to individual customer mailboxes. So, just as an incoming letter to Stanley Frobisher might go to box 112, for someone on the Internet to access a Web page on your server you need to open port 80. If you’re running an Apple Filing Protocol (AFP) file server, you’d make it available via port 548.

The analogy goes further. Just as post office boxes are locked to keep people out, you can keep a port closed to prevent access. So, if you don’t want allow anyone to upload files via FTP from the outside, you keep port 21 closed.

Note: You can also block certain types of outgoing traffic, although for the purposes of this book I focus solely on managing incoming traffic.

To sum up, if you or any of your users will be accessing your server from outside your LAN, you’ll need to open ports in order for that to work. When a user is accessing your server from inside your network there’s no need to open any ports unless you have a very (and likely overly) complex network.

I’ll mention when port forwarding is necessary in upcoming chapters. For now, what you need to know is that to open a port on your server, you’ll configure your router to connect incoming traffic on one of its ports to a port on your server for each type of incoming traffic you want to support. This is called port mapping. Port mapping is done within the user interface for configuring the router or firewall, and the details differ depending on the brand of router or firewall; if you need help later on, consult the manual that came with your device. (Take Control of Your Apple Wi-Fi Network explains how to handle port mapping on Apple’s newer base stations—including 802.11ac base stations.)

Note: Apple has compiled a list of common ports used in OS X Server in this Knowledgebase article.

Warning! For security reasons, you should open only those ports that are absolutely necessary.

Install and Configure OS X

It’s time to install a fresh copy of OS X on your server Mac—10.9 Mavericks in this case! In this topic, I talk about installation and then walk you through a few important ways to customize OS X before you run OS X Server for the first time. (If you’re wondering how 10.10 Yosemite affects these instructions, see the sidebar What about Yosemite and Yosemite Server?)

Install OS X

It’s important to start with a new, clean installation of OS X, to give your server a stable foundation. When you centralize assets (files, services, and so on) on one computer, that computer becomes more important than it was before; you don’t want to use a computer that has cruft on it. In other words, don’t turn a computer with your kids’ Dora the Explorer apps on it into a server. Instead, back up that computer, reformat its disk, and install a clean version of OS X.

What if you set up the Mac cleanly but have been running it for some time? I suggest that you set it up from scratch again and manually migrate the data into shared folders or new Web site configurations. You want your new server installation to run for a long, long time without problems!

Since you are likely already comfortable with the task of installing OS X, I’m not going to cover that in any detail. In short, use Disk Utility to erase the partition or disk onto which you’ll be installing, and then download the latest version of OS X using the App Store application and work through the default installation process. There’s nothing outside the ordinary to do at this point.

Note: If you need more help, I recommend Joe Kissell’s Take Control of Upgrading to Mavericks, which discusses how to create partitions in Disk Utility. And yes, Joe also has Take Control of Upgrading to Yosemite.

Configure the Server’s IP Address

Once you’ve installed the operating system, the next step is to configure the network settings for the server. This important step involves assigning a static IP address to the network interface that clients will use to access resources on the server.

Computers use TCP/IP addresses to communicate with one another. By default, these addresses on client computers can change, using a protocol called DHCP (Dynamic Host Configuration Protocol), but servers need a consistent IP address so that clients can access them. So servers typically are not configured using DHCP. (You could create a DHCP reservation for a given IP address at the router level, but I prefer a static IP to avoid future confusion.)

Picking a Static IP Address

If you don’t already have a scheme for choosing which IP address to assign to your server, here are a few factors to consider:

Memorization: The address should be easy to remember. Since a given subnet can have 254 IP addresses (192.168.1.1 through 192.168.1.255, for instance) and the first is usually taken by the router, the .2 address is what I generally recommend. It’s easy to remember and the .255 address is typically reserved for the broadcast address.

Conflict avoidance: A server’s IP address needs to stay out of conflict with any other devices on the local network. That means it shouldn’t be part of a pool of IP addresses that’s assigned dynamically to normal computers that appear and disappear from the network. If you’re installing the server on a consumer network, this means that if you assign the second IP address (192.168.1.2) to the server, you would then customize your DHCP server (which is usually also your router) to avoid serving that IP address to client computers. See the manufacturer’s documentation for your router for how to make that change.

Once you’ve picked the best IP address to assign to your server, it’s time to configure the soon-to-be server. To assign a static IP address:

Open System Preferences > Network and choose the interface (likely Ethernet) that clients will use to connect to the server.

At the right, choose Manually from the Configure IPv4 pop-up menu and then enter the IP address you chose, the subnet mask (generally 255.255.255.0), and the IP address of your router, as shown in Figure 1.

Note: You can choose Using DHCP with Manual Address or Using DHCP if you have a good understanding of networks. But I recommend setting the IP address manually, to reduce troubleshooting later on if something else breaks.

Figure 1: Configure your server’s IP address.

Click Advanced.

Click the DNS button.

Use the plus button to add the addresses of your name servers to the DNS Server list. (If you don’t have your name server IP addresses handy, use Google’s at 8.8.8.8 and 8.8.4.4.)

Click OK, and then click Apply to save the changes to the interface.

Tip: While you’re in the Network pane, you can reduce the chance of your server inadvertently switching away from Ethernet by deleting unused network interfaces: select the interface in the left column and then click the minus button beneath.

Once the address is configured, confirm that the address works by trying to ping the computer from another computer on the network. Simply use the ping command in Terminal, followed by the IP address of the soon-to-be server:

ping 192.168.210.2

The response should appear as multiple lines that look like this (stop ping by pressing Control-C):

64 bytes from 192.168.210.2: icmp_seq=0 ttl=63 time=75.184 ms

If the response looks like this, you’re done and you can move on to configuring the name of the computer you’ll be using as a server. Otherwise, check the Network pane of System Preferences and verify that the settings are entered appropriately.

Note: If you aren’t familiar with using the Unix command line via the Terminal app, check out Joe Kissell’s Take Control of the Mac Command Line with Terminal, which offers lots of basic instructions.

Set Up Hostnames

After you’ve set up a static IP address, it’s time to give the server a name. Just as with the IP address, you don’t want to change the name once you’ve opened the Server app for the first time.

The name should be fewer than 16 characters long and contain only letters, numbers, hyphens, and underscores. Additionally, try not to use a name that ends in .local (as in computerName.local), as that can lead to unstable connections.

A server actually has three names: the LocalHostName and the ComputerName, which are generally the same, and the HostName. In my examples, the LocalHostName and the ComputerName are the name of the computer, and the HostName adds the domain name to the LocalHostName to create the fully qualified domain name of the server.

What names you choose depends on whether you want your server to be accessible from the outside Internet or not:

Local only: If you don’t need your server to be accessible via the Internet, the domain name you choose simply needs to avoid conflicting with any real domain on the outside Internet. The easiest way to ensure this is to use a fake top-level domain—something like .lan or .foobar.

Internet: If you plan to run a public Web server, for instance, you need to use a domain name whose settings you control via a DNS provider like easyDNS or DynDNS. For example, you might use a domain name like myhost.example.com. Although there’s nothing wrong with doing this, beware that it will require more setup effort and ongoing maintenance, particularly with regard to security.

For the examples in this book, I’ll set the server’s LocalHostName to mavserver, and use as our domain pretendco.lan (an intentionally made-up domain that won’t conflict with any real domain). That results in these names:

LocalHostName: mavserver

ComputerName: mavserver

HostName: mavserver.pretendco.lan

To set the names, use scutil via Terminal on the soon-to-be server.

In the steps below, replace mavserver and mavserver.pretendco.lan with the names you want your server to have:

Set the LocalHostName:

sudo scutil --set LocalHostName mavserver

Set the ComputerName:

sudo scutil --set ComputerName mavserver

Finally, set the HostName using this command:

sudo scutil --set HostName mavserver.pretendco.lan

You’ll need to do one more thing to check that you’ve entered your names correctly, but that has to wait until after you’ve installed the Server app itself and configured DNS a bit more.

Disable Sleep

Luckily, servers don’t need their rest and should never go to sleep. That way, the files and services on the server can be accessible even if it’s 2 AM.

To keep your server awake at all times:

Open System Preferences > Energy Saver. If you’re using a laptop, it should be running on a power adapter when acting as a server, so click the Power Adapter button if available (in which case you’ll see slightly different options than shown in the figure below).

Move the Computer Sleep slider all the way to the right, to Never (Figure 2). This prevents the server from going to sleep automatically. If you’re using a laptop and there’s an option for “Prevent computer from sleeping automatically when the display is off,” select it.

Figure 2: Configure Energy Saver options.

To save power, set the Display Sleep slider to a short duration. If you do this, it’s best to disable the screen saver entirely, in the Desktop & Screen Saver pane of System Preferences, to reduce the chance that the screen saver itself could crash or cause problems.

Note: If your server is physically accessible to people who shouldn’t be allowed to mess with its configuration, consider leaving the screen saver enabled and also require a password to unlock the screen in the Security & Privacy preference pane.

If you’re running the server headless, set Display Sleep to Never, since there’s no screen.

Deselect “Put hard disks to sleep when possible.”

Select “Start up automatically after a power failure” so your server comes back up on its own if the power goes out and your UPS can’t keep it running long enough.

Your server will now stay awake and keep its resources available to clients who need them.

Download and Install the Server App

Downloading OS X Server is as easy as buying anything else from the Mac App Store. First, open the App Store app and search for OS X Server, or visit its description page on the Web.

Note: If you are installing the Server app onto multiple computers, you can copy the app to each one rather than download it again. The Apple ID used to acquire the Server app will be required each time the app is updated, so especially if you are installing for a company, make sure to sign in to the App Store with the right Apple ID.

Next, from the App Store, click the price button to buy the software, or if you’ve already purchased it, click the Install button (Figure 3).

Figure 3: Click the Install button to download the Server app.

The Server app downloads to your /Applications directory. If you feel that the download is taking too long (it’s about 180 MB), you can check on its progress in the Purchase view of the App Store app. While the Server app is downloading, I recommend adding its icon to the Dock so you can access it quickly in the future.

Once the download is complete, restart your Mac. This is necessary because there’s a command-line tool buried in the Server app that you’ll need to use later to confirm that the server’s names are correct.

When the Mac comes back up, open the Server app to start the initial configuration assistant. You’re prompted to set up your server. Click Continue. Agree to the licensing agreement, and then authenticate with an administrative password when you’re prompted to do so.

Once you authenticate, services are prepared, which means all the things required for a server to be a server are put where the app needs them. You can watch some of this by looking in the /Library/Server directory. Be patient, as stopping this somewhat lengthy process can have bad results, such as an incomplete copy leading to services not functioning when you get ready to start them.

The Server Tutorials screen opens when the process is complete. Read all the tutorials and come back in a few weeks when you’re done. Seriously, you can close this screen, although Apple’s tutorials are well done and I do recommend you read them later when you have time (choose Help > Server Tutorials). Once you close the Server Tutorials screen, you’re in the app and your base server installation is complete.

The next thing you should do is check out the interface of the Server app. Notice that the global settings for the server are listed in the top Server section of the sidebar, as you can see in Figure 4.

Figure 4: The basic Server app interface includes a sidebar on the left and a pane on the right. Click an item in the sidebar to work with it in the pane.

Below the Server section of the sidebar is the Accounts section, with the Users and Groups configurations. Next comes the Services section, containing the typical services most people run on Apple servers. Finally, the Advanced section, hidden by default, contains the more advanced services. Hover the pointer over a section name to see a Hide/Show control; click it to hide or show the entries in that section.

Click each entry in the sidebar to see the options that correspond with it. We’ll review most of the services in the appropriate chapters later in this book.

Note: All service configuration takes place in the Server app, and it also offers some monitoring tools (see Server Maintenance), but I don’t recommend that you leave the Server running all the time. I find that it tends to make the system less stable when it has been open for a long time, so I open it only when I’m actively administering the server. All services continue to run in the background even if the Server app isn’t open.

Configure Global Settings

With Server installed, you should take a few steps that are beneficial no matter which services you plan to run. These steps help keep you informed about the server and reveal a few options that I won’t describe in detail here but that you may later decide to use.

First, click the name of the server in the sidebar (Figure 5).

Figure 5: Click the name of the server in the sidebar.

Now, you can open the Settings pane (Figure 6).

Figure 6: Consider the options in the Global Settings pane.

The options in the Settings pane should be configured only if you need them:

Allow remote login using SSH for: With this checkbox and pop-up menu you can specify whether to use and who can use the SSH command-line tool to manage the server.

Enable screen sharing and remote management: Select this option if you plan to use the screen sharing or Apple Remote Desktop tools to take over the server’s screen.

Allow remote administration using Server: Select this if you plan to download the Server app onto another computer in order to manage this server. This is particularly handy if you’re running the server headless. See Where to Use the Server App.

Enable Apple push notifications: This is where you configure the server to send push notifications for mail, calendar events, and Profile Manager. You don’t need to configure this option now; I’ll explain how to configure Apple push notifications in Configure Alerts.

Service Data: Edit this option if you’ll be using external storage, such as a Thunderbolt drive, to house your service data (such as files and software updates). If you aren’t ready to configure this setting when you first set up the server, don’t worry, because you can always use it to move data to an external drive at a later time.

Where to Use the Server App

An interesting fact about the Server app is that it can control services running on another Mac over your network. So, you could copy the Server app from the server Mac to the Mac you use for everyday tasks. Just make sure to select “Allow user to administer this server” when creating the user you’ll use for administration, and then enter that username and password when prompted by the Server app on the client Mac.

That said, I don’t recommend this. It works fine, but with one errant click on the wrong button on Server’s login window, the Server app can become a CPU and battery hog even when not running, making it annoying to have on your personal Mac. Instead, stick with OS X’s built-in screen sharing, and run the Server app on the server itself.

Finish Network Configuration

Remember when you configured the server’s names? With the Server app installed and running, it’s time to finish the networking setup, which—unless you have a DNS server on your network already—likely requires enabling the DNS service within OS X Server, configuring it, and updating the server’s DNS settings in the Network pane of System Preferences.

The directions here are for a quick-and-dirty job meant to get DNS working sufficiently to enable you to continue with other setup jobs; if you want to run DNS to hostnames for other internal servers on your LAN, you should also be sure to read DNS Service.

Hosting DNS Elsewhere

There’s no requirement that you run DNS on this server, but if you’re going to host it on another server on your network, you’re on your own for configuration. Just remember, the goal is ensure that your new server’s hostname matches with its IP address. Make sure you have a reverse DNS record set up for it as well. The changeip test described shortly will fail if reverse DNS isn’t set up properly.

Turn On DNS

To enable DNS, click DNS in the Advanced section of the Server app’s sidebar (if necessary, hover over Advanced and click Show). Then click the ON button in the upper right of the DNS pane.

Under the Host Names list, click the plus button to create a new entry (if you see the slightly different plus button, click the gear icon and deselect Show All Records). In the Host Name field, enter the hostname you created in Set Up Hostnames, and in the IP Addresses field, enter the IP address of the server that you set up in Configure the Server’s IP Address (Figure 7). When you’re done, click the Create button (not shown).

Figure 7: Enter your server’s hostname and IP address in the appropriate fields.

That takes care of mapping your server’s hostname to its IP address, but there’s one more thing to do in the DNS pane. You need to configure the DNS servers that will handle requests to machines outside your network. Under Settings, click the Edit button to the right of Forwarding Servers, and enter your usual name server IP addresses. Again, if you don’t have those handy, you can use Google’s public name servers (Figure 8).

Figure 8: Enter the IP addresses of your name servers.

Forwarding Servers

In DNS, a forwarding server or forwarder is where a server looks when resolving a request if the necessary record isn’t available.

If your server can’t resolve a name with its own DNS records, it asks the forwarding server for help. For example, if a user on your local network tries to visit www.takecontrolbooks.com and your DNS server has records only for mavserver.pretendco.lan, it passes the request to a forwarding server. The forwarding server then resolves that request by matching the name to the appropriate IP address and returns the information to your DNS server and then on to the user.

The forwarding server could be a DNS server provided by your ISP or a site like OpenDNS. For more information, see DNS Service.

Restricting DNS Lookups

By default, the Perform Lookups For pop-up menu is set to Only Some Clients, and if you choose that menu item, you’ll see a dialog that lets you restrict lookups to the server itself, to clients on the local network, and to clients on specified networks. The first two options are enabled by default, and it’s unlikely that anyone reading this book will need to provide access to clients on other networks.

Stick with the defaults, unless you plan to run a full-fledged DNS server that can be used by any client on the Internet and you have an appropriate network setup for that. When Adam Engst chose All Clients from the pop-up menu, his ISP, Time Warner Cable, disabled his entire Internet connection until he switched back to Only Some Clients.

Update OS X’s DNS Setting

Now that you’ve configured Server’s DNS service, you need to configure OS X on the server Mac itself to use Server’s DNS service instead of your normal name servers:

In the Network pane of System Preferences, select the network adapter in use (likely Ethernet), and click the Advanced button.

Click the DNS button.

Select whatever is entered in the DNS Servers list at the left, and replace it with the IP address of the server itself (Figure 9).

Figure 9: Enter the server’s own IP address in the DNS Servers list on the DNS screen of the Network preference pane.

Click OK, and then click Apply to save your changes.

Telling the server to look up IP addresses on itself may seem odd, but Server’s DNS service is doing all the work.

Verify That the IP and Hostname Match

Lastly, you need to check that your server’s IP address and hostname match, using the changeip command in Terminal. Enter:

sudo changeip -checkhostname

The changeip command should show something similar to the following output:

Primary address = 192.168.210.2 Current HostName = mavserver.pretendco.lan DNS HostName = mavserver.pretendco.lan The names match. There is nothing to change. dirserv:success = "success"

In the last two lines of output from changeip, if you don’t see that the names match and then “success” (or if you get a “command not found” error), first restart the server Mac, which is sometimes necessary for everything to settle down. If that doesn’t help, you’ll need to work back through Configure the Server’s IP Address, Set Up Hostnames and all the steps under ⁠Finish Network Configuration.

Note: The changeip command exists only inside the Server app, so it won’t be available until you’ve installed Server and restarted the Mac.

Configure Alerts

OS X Server can alert administrators with push notifications (such as alerts on your iPhone) or email when there are problems with the server. To configure alerts:

Click Alerts in the sidebar, and then click the Delivery button.

In the Delivery view (Figure 10), click the Edit button for Email Addresses, enter every email address that should receive alerts from the server, and click OK.

Figure 10: Pick which server alerts you want to receive and whether you want to receive them through email, push notifications, or both.

Click the Edit button for Push Notifications.

If you need to set up an Apple ID, click the “Create one now” arrow icon (Figure 11). Otherwise, provide the desired Apple ID and then click Get Certificate.

Note: In an organizational setting, be sure to use an Apple ID that can stay with the organization. That way, if you leave the organization, the Apple ID can stay.

Figure 11: Enable Push Notifications. If you need to create a new Apple ID account to receive them, click the tiny arrow icon beneath the Password field.

An Apple Push Notification certificate downloads to your server—it’s used for a wide variety of services.

In the Settings list, select the checkboxes for Email or Push for each alert that you want each email address to receive.

Once done, you should receive the desired alerts when appropriate. You can test this by clicking the gear pop-up menu at the bottom of the Alerts pane and choosing Send Test Alert.

Note: When it’s time for the biannual renewal, you’ll rerun this assistant to renew your certificate; see Renew Push Notification Certificates.

Move On to Directory Services

Now that OS X Server is installed and fully functional, it’s time to install some services. The first service I like to enable is Apple’s directory service, Open Directory. My reasoning is that if I create users and groups, which is what comes next, I want those users to go into Open Directory rather than the local directory service built into the Mac.

Here are more important reasons for setting up Open Directory next:

Many other services, including File Sharing and the Calendar service, take advantage of the users and groups in Open Directory.

If you ever get a second server, you’ll want to run Open Directory so that the other server can share the users and groups you create.

Chances are you’ll eventually need Open Directory, so you might as well configure it now. To do so, check out Directory Services.

Directory Services

A directory service is a shared repository of usernames, passwords, network resources, and other information. Mac network clients (by “client,” I mean a computer) use a directory service to look up various things.

For the typical reader of this book, a directory service is where you’ll create and store user accounts for services including File Sharing, Calendar, and Contacts.

The directory service is at the heart of many large networks. But a directory service is really just a database that lives on a server, along with some underlying technologies that Apple collectively refers to as Open Directory. Some directory services can have roles that are broken out among a number of servers, but for the purposes of this book I’ll assume you need only one directory server (or at most two) to keep this chapter from expanding into a book of its own.

Note: Because we’re focusing on just one or two servers in a small network, we’re going to stay near the surface of the Open Directory ocean, where there’s plenty of light, everything is pretty simple, and most things work well. As you dive deeper into Open Directory, everything becomes murkier, what you need to do becomes significantly harder, and monsters lurk in the depths. Get dragged down too far and you can spend huge amounts of time getting everything configured and working properly.

As you work through this chapter, you’ll set up your Open Directory master and (optionally) create a replica. After that, you can add users to your directory service in Work with Users and—since some aspects of user management are easier if you manage groups of users—we’ll talk about how to Work with Groups.

The chapter concludes with a topic about how to Bind Clients, a procedure that a typical reader of this book won’t need to perform, but I’ve included it for completeness.

Set Up the Open Directory Master

If you have only one server, it will be an Open Directory master. Should you happen to have two servers, one will be the Open Directory master and the other a replica. (And, if you have even more servers, the rest of them will be clients to the directory service and so will be able to use the usernames and passwords entered in the master.)

Before setting up your Open Directory master, verify that the DNS and hostnames are configured properly. To do this, run the changeip command with the -checkhostname option to verify that the IP, DNS, and hostname all match, as was covered in Verify That the IP and Hostname Match.

If—and only if!—you get the message below should you move on to setting up the Open Directory service.

The names match. There is nothing to change.

Otherwise, go back to Set Up Hostnames and make sure your DNS is set up correctly.

Run the Open Directory Assistant

To set up the Open Directory master, work in the Server app. In the Advanced section of the sidebar, click Open Directory (Figure 12) (if necessary, hover over Advanced and then click Show). From here, click the ON button in the upper right of the Open Directory pane.

Figure 12: To turn on the Open Directory service, start by selecting Open Directory in the sidebar.

For the purposes of this example, we’re setting up an entirely new Open Directory environment. On the Configure Network Users and Groups screen (Figure 13), select “Create a new Open Directory domain” and click the Next button.

Figure 13: Select “Create a new Open Directory domain” to start from scratch.

On the Directory Administrator screen (Figure 14), it’s not necessary to change the defaults in the Name and Account Name fields, although it’s never a bad idea to use something less generic. (The Account Name is the username for the directory administrator account.) Once you’ve handled the name fields and entered the password twice—and made sure it’s recorded somewhere secure, like 1Password or Keychain Access—click Next.

Figure 14: Enter your desired username and password for the Directory Administrator account.

Note: You could use this administrative Open Directory account on a daily basis; however, I recommend that you use it only to manage Open Directory. You should manage the server Mac with a local administrator account (such as the one created when you installed OS X) and use any services offered by the server from a local network user account that you create for yourself (I explain how later in this chapter). I’ve learned the hard way that you don’t want to accidentally click something and damage the server!

In the assistant’s next step, we’re going to create an SSL certificate, which is used to encrypt and therefore secure communication between client computers and the server. Luckily, this isn’t difficult, since the Server app merely asks a few questions and creates and installs the proper certificate for you.

Self-signed vs. Third-party SSL Certificates

There are two types of certificates: self-signed certificates, which are what the Server app creates for you, and third-party certificates, which generally cost upward of $100 per year and are verified by an external certificate authority (CA).

For home and small office servers whose services are accessible only within a local network, a self-signed certificate is sufficient. More important, if you’re using a fake domain name (see Set Up Hostnames), you can use only a self-signed certificate, since you can’t get a third-party certificate for a name like mavserver.pretendco.lan.

If you have a real domain name and need a third-party certificate, follow Apple’s instructions for creating a certificate signing request, and then work with a CA like Comodo to create and import a certificate. These steps are beyond the scope of this book; they’re highly specific and involved, and it’s easy to make mistakes. If you venture down this path and have trouble, I suggest calling AppleCare for assistance (OS X Server purchased from the Mac App Store comes with 90 days of unlimited phone support).

On the Organization Information screen, enter a name in the Organization Name field and a valid email address to be used in the SSL certificate in the Admin Email Address field (Figure 15). These names are displayed to users if they view the certificate, so make sure they’re descriptive enough so as not to confuse people who are accepting the certificate. Click Next.

Figure 15: Create the Open Directory certificate.

On the Confirm Settings screen, make sure these settings are okay (click Back if you want to change anything), and then click the Set Up button.

When the Open Directory master has been configured, there’s no need to reboot or anything, and the indicator status icon for the Open Directory service should turn green, as in Figure 16.

Figure 16: The Open Directory setup is complete. Notice the new server, highlighted in the Servers list.

Configure Password Policies

Once the Open Directory master setup is complete, the server appears in the Servers list. To set the parameters that passwords must meet in order to be usable on the system, select the server in the Servers list and then choose Edit Global Password Policy from the Settings menu to view the Global Password Policy dialog (Figure 17).

Figure 17: Set up your Open Directory global password policy.

Some policies disable accounts or force password changes on scheduled intervals, or make passwords meet certain criteria. Take a moment to consider your policy so you set the right balance between security and convenience. A secure environment is important, but if your policy overly complex, users will start recording passwords on sticky notes attached to monitors, and that’s even less secure!

Select each box that corresponds with your requirements, and then click OK.

Set Up the Open Directory Replica

Previously, we set up the Open Directory master with SSL enabled. As you work further in this book, you’ll see how numerous services rely on the availability of the Open Directory master. But what if it isn’t available? If you have only a single server, it probably doesn’t matter, since if Open Directory isn’t available the entire server is probably offline and you have bigger problems.

But if you’re working on a larger network, in which there are network services beyond those on the computer running the Open Directory master, you don’t want your users to be twiddling their thumbs while you try to bring the Open Directory master back online. The solution is an Open Directory replica, which keeps a copy of the Open Directory database available for users even when the master goes offline.

So, skip this section if you have only a single server, but if you have two servers, then on the secondary server that you want to be your Open Directory replica, launch the Server app, select the Open Directory service, and click the ON button to start the configuration process.

When prompted, select “Join an existing Open Directory domain as a replica” and click Next.

Now, enter the hostname of the Open Directory master, the directory admin username (the diradmin or custom username that you entered in the Account Name field when you configured the Open Directory master in Run the Open Directory Assistant), and the directory admin password. Click Next to set up the services.

On the Confirm settings screen, verify that the settings are okay (click Back if you want to change anything), and then click the Set Up button.

Provided there are no issues with your configuration, the Server app finishes setting up the replica. On both the replica and the master computer, look in the Server app and confirm that the replica server is listed under the master.

Work with Users

Once you’ve set up your directory server, it’s time to create local network users, and after that, groups. Calendar, Profile Manager, and certain other services require local network users.

Types of Users

A directory domain is a repository of account data, which can include two types of users:

Local users: These are users local to the Mac running OS X Server, including the user you created when installing OS X and any others created in the Users & Groups preference pane. If, as described in this chapter, you’re running an Open Directory master, you should use local accounts only to manage local tasks, such as backups. (If you aren’t running Open Directory, all users are local.)

Local network users: These users, created in the Server app, can access network services on the server. If you set them up as I recommend, they won’t have home folders on the server Mac itself. When you view users on an Open Directory master, most will be local network users.

When I set up a server Mac, I typically end up with these accounts:

Local administrator: This is the account that OS X created for me when I installed the operating system. If I want to perform administrative tasks on the server Mac, such as configuring Time Machine backups, I log in with this administrator account.

Local network user: For everyday use of services provided by the server (accessing calendars, files, contacts, and so on), I log in with an Open Directory non-administrative account that I set up for myself. Most users will use an account of this type.

Open Directory administrator: This is the account that Open Directory created as I set it up. If I want to perform administrative tasks within Open Directory (for example, add users or reset passwords), I log in to the Server app with the Open Directory administrator account. This way I don’t ever accidentally click something and break my server as part of everyday use.

There are four places you can create users: the Server app, Workgroup Manager (available as a separate download), the Users & Groups preference pane, and the command line. I focus on creating users in the Server app because users created via any of the other approaches won’t have access to network services by default, since the other tools don’t create the access controls required for most services.

To add and manage local network users in the Server app, click Users in the sidebar, under Accounts. As you can see in Figure 18, the list of users appears, based on the directory domain(s) being browsed. From the pop-up menu, choose Local Network Users. (The pop-up menu also lets you display only local users, or both.)

Figure 18: The Directory Domain browser, showing the Local Network Users list.

Add a User

Assuming the server is an Open Directory master, which it will be if you followed the steps above in Set Up the Open Directory Master, any accounts you create will be local network users, stored in Open Directory. You don’t have to set up all your users now; it’s fine to add more later.

To create a new local network user, click the plus button. Server asks for information about the new user (Figure 19).

Figure 19: Enter the user’s account details.

Enter the account information, keeping these pointers in mind:

Full Name: Usually this is the first and last name of the user. It’s easy to come back later and change this name.

Account Name: This name, known technically as the short name, is nearly impossible to change later, so you want to enter it correctly here. It’s a short representation of the full name, with no spaces or special characters. Each account on the server Mac must have a unique short name. (When I mistype a short name, instead of changing it later, I delete the account and recreate it. This erases all the user data for that account, so if you do this make sure you first back up calendars, contacts, and other data that user may have!)

Email Address: This email address will be alerted if the account goes over quota or receives calendar invitations. If you run the Mail service, this address will also be used for email hosted on the server.

Password: The user will use this password to access services on the server.

Verify: Type the same password a second time to make sure you got it right the first time.

Allow user to administer this server: Select this checkbox to grant the user administrative access to the server. (See Where to Use the Server App, just after this list.)

Home Folder: Choose None - Services Only unless you are absolutely certain that you want local home folders, which I don’t recommend. With this option chosen, the user will be able to access services like file sharing, calendar, and contacts but will not be able to log in to a client Mac using these credentials, as with the other two options discussed in the sidebar, Other Home Folder Choices, slightly ahead.

Limit Disk Usage To: This setting appears only if you choose Local Only from the Home Folder pop-up menu, which I don’t recommend. It’s where you define the amount of disk space an account can take up. If you’ve chosen None - Services Only for Home Folder, this setting doesn’t appear.

Keywords: This optional field provides a place where you can enter keywords to help you identify users on a large network, such as a room number, building, or department.

Notes: Similarly, this optional field lets you record notes about the user that might be helpful in the future.

Tip: You can drag a photo onto the image shown in the New User screen, to give the user an avatar. Or click the image and choose Edit Picture to assign a built-in image.

Once the account details are set as you would like, click the Create button. The full name associated with the account appears in the list of available accounts.

Other Home Folder Choices

There are two choices in the Home Folder pop-up menu beyond None - Services Online: Local Only and Network home folder, but they require explanation, since I don’t recommend them and you won’t see Network home folder option if you’re reading this book in order.

Local Only: If you were to choose this option, the user would get a local home folder on the server and would be able to log in to the server as a normal local user. If the user logged in to a client Mac with the account’s credentials, a new, clean home folder would be created on the client Mac, but there would be no link between the home folder on the server and the one on the client Mac. This approach requires binding the client Mac to the server; see Bind Clients, at the end of this chapter. In most cases, there’s no reason to log in like this, since most users will already be logging in using normal accounts on client Macs.

Network home folder: For this “portable home folder” option to be available, file sharing must be turned on (see File Sharing), a shared folder must be set up, and the “Make available for home directories over” checkbox must be selected for the shared folder. In theory, if all this is true, and you’ve bound the client Mac to the server (see Bind Clients), when you log in to a client Mac with this account’s credentials the home folder would be copied from the server to the client Mac, and when you logged out your changes would be copied back. It sounds cool, but in reality there are significant performance and reliability problems that make this approach an increasingly bad idea in most environments today. Avoid it.

Manage Users

With at least one local network user account created, you can manage it from within the Users pane as follows:

Edit the account information: Double-click the account in the list; you can change the user’s full name and email address, along with keywords and notes, but not the short name.

Reset the password: Select the account in the list and then choose Reset Password from the gear pop-up menu.

Give the user access to services: Select the account, and then choose Edit Access to Services from the gear pop-up menu. Deselect any services that the user should not have access to (Figure 20). If the service isn’t running, there’s no reason to remove access.

Figure 20: Specify which services the selected account can access.

Tip: You can select multiple accounts at once and choose Edit Access to Services to disable services for many users en masse. However, if you have a lot of users you may want to group them first and then enable (or disable) services on a group-by-group basis.

Add the user to a group: I talk more about this option next, in Work with Groups.

Disable the account without deleting it: Double-click the account and then deselect the “log in” checkbox. This disables the account from being able to log in to the server but leaves the account in place so you can reactivate it later if needed. For example, if a temporary employee is leaving you could leave the account dormant in case the employee is rehired.

Delete the account entirely: Select the account and click the minus button.

Tip: If you give a user a local home folder, deleting the account won’t remove the folder in the Finder; you’ll have to do that manually.

Notice that the gear pop-up menu has more account-related commands, such as Edit Mail Options, which I cover in Mail Services

Note: The gear menu also enables you to create a template from a user and, once that’s done, edit the template. This is useful if you’re creating numerous accounts with the same access settings, rather than having to configure each one manually in exactly the same way.

Note: There are actually a lot more accounts on your server; to see them all, choose View > Show System Accounts. Needless to say, don’t mess with any of these accounts.

Work with Groups

Although you can edit service access for multiple users at once, it’s easier to control access to services by adding users to groups and then giving appropriate access to the group. That way, for instance, you could have a Travelers group whose members are granted access to your VPN service and a Temps group whose members you don’t trust to access your network via the VPN.

As with users, it is possible to have both local groups and local network groups, with much the same caveats (local groups are relevant only to the Mac itself, and local network groups are what you create to control service access for local network users; see Types of Users, earlier in this chapter).

Add a Group

To create a new group, click Groups in the Accounts section of the Server app sidebar. In the Groups pane (Figure 21), choose Local Network Groups from the pop-up menu and click the plus button.

Figure 21: To add a local network group, open the Groups pane, choose Local Network Groups, and click the plus button.

On the New Group screen, provide a name for the group in the Full Name field. This name can include spaces. Then enter a short name—which can’t have spaces—in the Group Name field (Figure 22). Click Create to create the group.

Figure 22: When you create a group, the title at the top of the pane becomes the Full Name of the group.

Your new group appears in the Groups list. But don’t stop now; continue with the first set of steps for managing your group, next.

Note: For the purposes of this discussion, ignore the Workgroup group that appears by default in the Groups pane.

Manage Groups

Group management happens in the Groups pane, so if you aren’t already there, select Groups in the sidebar. To manage a group, select it from the Groups list and then click the gear pop-up menu below the list. From that pop-up menu, you can edit the group, edit its access to network services, create a template from it (if you plan to create many groups), and edit templates.

In particular, take note of these important options, which you may want to set up immediately after adding a new group:

Double-click the group name, or select it and choose Edit Group from the gear pop-up menu.

A dialog opens (Figure 23).

Figure 23: When you edit a group, you can specify more details than you can on the group creation screen.

In the edit group dialog, add members, keywords, or notes:

To add a member, click the plus button and type the username. (To remove a member, select the account name and click the minus button.)

Optionally put a few terms in the Keywords field. If you have many groups, typing a few keywords here now might help you find the group later.

For documentation purposes, even if this is a personal server, leave yourself a few notes about why you created the group and what its purpose is.

Once you’ve made your changes, click OK to save them.

Select the group, click the gear pop-up menu, and choose Edit Access to Services. Now you can toggle access to various services for all accounts in the group. If you aren’t sure which services you want to enable or disable, that’s okay; you can come back here anytime.

Click OK.

You can also configure the following options for a group, but don’t mess with anything here just yet, since I cover these options in later chapters:

Give this group a shared folder: Select this box to create a shared directory for the group, or a group with an ACL (access control list) that grants all group members access. Read more about this in File Sharing.

Make group members Messages buddies: Selecting this box adds each group member to the other members’ buddy lists in the Messages client. I cover this in Configuring the Messages Service.

Enable group mailing list: You can select this box to create an email list, where all members receive email messages sent to an address based on the short name of the group. However, I don’t recommend that you use this feature (or that you run a mail server at all); instead, consider a third-party service, such as MailChimp. (See Mail Services for why.)

Create Group Wiki: Click this button to open the interface for creating a wiki for the group. This option is disabled if you haven’t yet enabled the Wiki service; to do so, see Configure the Wiki Service.

Bind Clients

When you “bind a client,” you establish a connection between a computer and your Open Directory master. There are a few reasons to do this, and while there’s no real downside to doing it, binding isn’t necessary if you have no interest in the following features, which are primarily useful in very large networks:

Network-based login: As discussed in Other Home Folder Choices, it’s possible to use a local network user account’s credentials to log in to a client Mac, either creating a fresh home folder or using the one from the server. But since I don’t recommend network-based login, it’s not a reason to bind a client Mac.

Single sign-on: In a large network, with hundreds of users, single sign-on is tremendously useful, since it allows the user to log in using a local network account’s credentials and automatically be able to access multiple services, potentially on multiple servers. On a small network with a single server, a handful of services, and client Macs that are already set up with local users, it’s not worth the trouble.

Server-to-server authentication: Again, in the scenario of a large network with multiple servers, binding servers to Open Directory is essential to enable single sign-on. If you have only a single server, this use case falls away.

Policy management: Being able to configure client Macs from the server with policy information is again primarily of interest in large network scenarios, and binding is necessary for that. Policy management is important for two purposes, neither of which is likely to be useful for people reading this book:

Configure new clients: Policy management enables you to set the list of available printers, configure Dock location and contents, remove the capability of connecting to external volumes (for security reasons), and so on. That’s a big win when setting up numerous client Macs from scratch.

Update existing clients: Similarly, if you add a printer to your network, policy management lets you push the connection details for that printer to multiple client Macs, which is easier than configuring them all manually.

So, if you’re setting up only a single server for file sharing and a few other services, and you have relatively few client Macs on your network, you can skip binding, as it will only complicate the environment more than it likely needs to. That said, if you do need to bind client Macs, you need to know what I discuss here.

Tip: If you’re setting up OS X Server for a production network at work, I suggest that you bind a test computer first, before binding computers that are in production or being used by users. If you don’t have a computer for testing, make a clone of yours with Carbon Copy Cloner or another tool on another drive, boot from the clone, and test with that to avoid messing up your Mac.

Note: The name—which you set in the Sharing pane of System Preferences—of any computer being bound to any directory service (including Microsoft’s Active Directory) should be fewer than 16 characters long and contain only letters, numbers, hyphens, and underscores. Other characters in the name of a computer can cause the binding process to fail or be unstable. Additionally, try not to use names in the .local top-level domain (as in computerName.local), as they can also lead to unstable connections once bound.

Binding clients can be done in a few different ways. You can use a script, a profile, or the Users & Groups pane of System Preferences, or, if you’re dealing with a very large network, build binding into the imaging process. For the purpose of this example, we’ll use the System Preferences pane, since it’s the easiest to understand:

On each client Mac, open the Users & Groups preference pane.

Click Login Options.

Click the lock in the lower left of the pane, providing an administrator username and password when prompted.

Next to Network Account Server, click the Join button.

In the dialog that slides down, select the desired server from the pop-up Server menu if the server is automatically discovered via Bonjour, or, if not, enter the name of the Open Directory master (the HostName you set back in Set Up Hostnames) (Figure 24).

Figure 24: Connect to Open Directory by choosing the server.

Assuming you’re using a self-signed certificate (which you are if you created the certificate using the steps above in Run the Open Directory Assistant), click the Trust button when prompted.

If you’re alerted that the server doesn’t provide a secure SSL connection, click Continue. That happens with self-signed certificates, and it’s nothing to be concerned about.

In some cases, the binding dialog expands to show more options when you enter the hostname, although for the purposes of this chapter we’ll leave those as the default, as shown in Figure 25. If your dialog didn’t expand, don’t worry about it.

Figure 25: The basic Open Directory binding options.

Click OK to accept the certificate (again assuming it’s self-signed).

The system finishes binding and a new checkbox appears in the Login Options view: “Allow network users to log in at login window.” Checking this box allows credentials configured on the server to be entered on clients when logging in; a new Other button appears on the Login screen in the list of users, though it may take 5–10 seconds to show up.

DNS Service

Now that you’ve configured your server and set up Open Directory, we can move on to configuring other services. The first we’ll look at is DNS, or Domain Name System, which is a system for naming computers, resources, and services. If you’ve been following along in this book, you’ve already turned on the DNS service to enable Open Directory. Now it’s time to improve and extend your DNS configuration.

Although DNS configuration beyond what you already did in Turn On DNS isn’t absolutely necessary, a little additional configuration can provide improved performance due to cached domain-name lookups and allow your client Macs to use names rather than IP addresses to refer to the server and its services. For example, your users will have an easier time remembering mavserver.pretendco.lan than 192.168.210.2. And, to make it even easier, you can associate names with certain services, like file sharing, since it’s easier to remember that the internal file server is called files.pretendco.lan than mavserver.pretendco.lan (even if they’re just two names for the same server).

Another benefit of using names rather than IP addresses is that if you move certain services to other servers in the future, you can just, for instance, repoint files.pretendco.lan at a different machine, and your users don’t have to change anything to access your file server.

Finally, if you have multiple servers, running DNS internally becomes increasingly important for distinguishing between the servers.

The order in which you set up services and their associated DNS names isn’t important; you obviously can’t use a DNS name until you’ve set it up, but every server and service is accessible via its IP address until then. It’s easiest to create DNS names for the services you anticipate enabling now, but if you forget one, just come back and set it up later.

Note: I don’t provide instructions for configuring OS X Server’s DNS service to host the DNS records for an Internet-accessible domain. Although that’s technically possible, it’s far better handled by a service like your domain registrar. For Internet services, where you want 24/7 uptime, let a big company with redundant servers and generator-backed data centers do the work. I own dozens of Internet domains and host them all with domain registrars rather than on my own servers.

Note: OS X Server should run only as many services as are necessary, so if you already have another DNS server you should skip this chapter and continue using your existing DNS server.

Understand Zone and Record Types

Before I get into how to configure DNS, let’s take a step back and make sure you understand what sort of DNS records you can work with in OS X Server. For basic usage, many of these will be created for you or aren’t necessary, but you’ll likely want to create machine, alias, and mail exchanger records, depending on the internal services you set up.

Each domain you create is known as a zone. Each item that you want to point somewhere is known as a record. You can see and create the following in Server’s DNS screens:

Primary zone: The DNS domain. For example, www.pretendco.lan would have a primary zone of pretendco.lan. The primary zone is created for you when you create your first machine record.

Machine record: A machine record, or, in DNS-speak, an A record, maps a computer’s name to its IP address. Every server should have a machine record, and you created one in Turn On DNS. In our example, the machine record maps mavserver.pretendco.lan to 192.168.210.2.

Alias record: Also known as a CNAME, the alias record maps one name to another. For instance, if you’re running both file and Web services on mavserver.pretendco.lan, you might want to define alias records for files.pretendco.lan and www.pretendco.lan, pointing both of them back at mavserver.pretendco.lan. There’s nothing special about these aliases; you can make them whatever you want (as long as they’re short and use only letters, digits, and hyphens), with the primary goal being to make them sensible for your users.

Nameserver record: The nameserver, or NS, record specifies the authoritative DNS server for each zone. If you have only one DNS server on your network, it should be the server itself. The Server app creates the nameserver record automatically when you create your first domain.

Service record: Service, or SRV, records hold special types of data that describe where to look for services for a given zone. For example, iCal can leverage service records so that users can just type their usernames and passwords during the setup process. You shouldn’t need to create service records unless you’re setting up a DNS server to do some pretty advanced stuff.

Mail exchanger record: Also known as an MX record, a mail exchanger record points to the mail server for a given domain. You need a mail exchanger record only if you’re running a mail server.

Text record: Although it would seem impossible to create a text, or TXT, record in Server, there’s a trick. When you create a machine (A) record, there’s a Text field; you can enter the necessary text in that field to get a TXT record. TXT records are primarily useful for specifying SPF and DKIM details (both aimed at improving bulk email deliverability), so it’s unlikely that you’d need any TXT records.

Reverse zone: This automatically created zone maps IP addresses back to names. Don’t worry about it.

Reverse mapping: In the DNS world, reverse mapping is handled through a PTR record that maps an IP address to a domain name—exactly the reverse of normal DNS. It’s necessary only for mail servers, since many Internet mail servers are configured to reject incoming messages from any IP address that doesn’t have a reverse DNS PTR record. You can’t create a reverse mapping manually in Server; it’s created automatically for the first IP address listed in each machine record.

Secondary zone: You won’t need to worry about secondary zones either; they’re read-only copies of primary zone information stored on other DNS servers.

Configure DNS on the Server

As I noted at the start of this chapter, there are two main reasons to run a DNS server in a small home or office network: caching and mapping names to IP addresses. The good news is that there’s absolutely nothing to do to take advantage of Server’s DNS caching capabilities; it automatically caches every request and serves the cached information on subsequent requests if the information hasn’t aged out.

Setting up additional records to map names to IP addresses is a bit more work, but not much. First you create alias records to the machine record you created in Turn On DNS and a mail exchanger record in Server, and then you need to adjust the DNS settings on client Macs so that they know about your new DNS names.

Follow these steps to create your alias records, as well as a mail exchanger record. For the purposes of this example, we’ll create alias records for file and Web servers:

In the sidebar’s Advanced category, click DNS. The DNS pane appears at the right.

From the gear pop-up menu, choose Show All Records to display all the zones and records that Server has created for you, and to put the DNS pane in a mode where you can create record types other than machine records.

Click the plus button, and from the pop-up menu that appears, choose Add Alias Record.

Leave the Zone pop-up menu alone, but in the Host Name field enter files (Figure 26), and in the Destination field enter the name of your server, such as mavserver.pretendco.lan. Click Create.

Figure 26: Enter the alias name for your file server in the Host Name field.

Repeat Steps 3 and 4, but enter www in the Host Name field this time.

Click the plus button again, and from the pop-up menu, choose Add Mail Exchanger Record. You can skip this step and the next one if you don’t plan to enable OS X Server’s mail services.

Once again, leave the Zone pop-up menu alone, but in the Mail Server field enter your server’s domain name prefixed with mail, as in mail.pretendco.lan (Figure 27). Leave the Priority field at 0; if you had multiple mail servers, higher numbers in this field would cause them to be used as backups. Click Create (not shown).

Figure 27: Enter the name you want to map to your mail server.

An Even Easier Solution

These steps are easy, but in fact, Apple has made them even easier. I wanted to walk you through them so you’d see a bit more of what’s happening behind the scenes, but you could have done all this from the screen for your initial machine record (Figure 28).

Figure 28: You can create alias and mail exchanger records from the machine record screen, as long as Show All Records is not selected.

As long as Show All Records is not selected in the gear pop-up menu, the screen for a machine record lets you add a list of aliases and includes a checkbox to create an MX record. The MX record will be for the same name as the machine record in this setup, so you’ll need to use Show All Records if you want to change it to something else.

Configure DNS on Client Macs

The simplest way to configure the client Macs on your network to use your new DNS server is to reconfigure your DHCP server (often your DSL or cable modem, or an AirPort base station or similar router) to provide the new server as the first DNS entry, as shown in Figure 29. It’s safest to enter another DNS server—either one run by your ISP or a major public one like Google’s 8.8.8.8—in the second DNS Servers field, since that will be used as a backup for DNS lookups if your local DNS server were to go down for some reason.

Figure 29: If you point your DHCP server at your DNS server, all the client Macs on your network that get their information from the DHCP server will automatically start using your new DNS server.

If you can’t control the DHCP server for your network, you can assign the DNS server manually on each client Mac, though this should be avoided for laptop Macs that need to use other networks or they might lose Internet access when offsite:

Open the Network pane of System Preferences.

Select the interface for which you want to adjust DNS settings (likely Ethernet or Wi-Fi).

Click the Advanced button, and then click the DNS button to open the DNS view (Figure 30).

Figure 30: Configure the DNS Server settings on client computers to look to your new server.

In the DNS view, beneath the left-hand DNS Servers list, click the plus button to get a new entry in the list, and then enter the IP address of your DNS server. It’s a good idea to repeat the process with one or two additional DNS server IP addresses that the client Macs can use for DNS lookups if OS X Server should go down.

Click the OK button, and then click Apply to save your changes.

If all has gone well, you’re now running a DNS server for your network, and all the client Macs on the network are using that DNS server to look up IP addresses for both internal and external machines.

File Sharing

Despite the popularity of file sharing services like Dropbox, the most common server used on internal networks today remains the file server, a central repository that stores files for a workgroup. These stalwarts have been connecting users to their files seemingly since before time began. Whether in a home, school, or business, file sharing is often the impetus for setting up a server.

OS X Server’s File Sharing service offers a number of file sharing protocols, including AFP, SMB, and WebDAV (the sidebar just ahead explains these File Sharing Protocols).

By default:

File Sharing has some built-in shared folders, but not all environments require them. I recommend that you remove the built-in shared folders and add your own.

Each shared folder can make its files available via AFP, SMB, and WebDAV, or any combination thereof.

Each shared folder has permissions that Apple provides. These permissions will work in some cases, but you may need to modify them to meet your particular needs.

The basic steps to set up a file server are to Remove Default Shared Folders, Create a New Shared Folder as needed, Configure Permissions for each shared folder, and finally Enable File Sharing. Because file sharing is the most mature service in OS X Server, it’s also one of the easiest to manage. When you’re done setting it up, you’ll want close the loop on file sharing by having your clients Connect to Shared Folders.

Note: If you haven’t already created the necessary local network users and groups that will need access to shared folders, go back and turn on Directory Services and then Work with Users and Work with Groups in that chapter as needed.

File Sharing Protocols

OS X Server’s File Sharing service offers three different file sharing protocols, each focused on a different environment.

AFP: Apple Filing Protocol, as the name suggests, is an Apple-created file sharing protocol. Traditionally, if you’re sharing files to Mac clients, you’ll want to enable AFP for your shared folders.

SMB: SMB (Server Message Block) is the predominant file sharing protocol in the Windows world. If you have Windows clients on your network, you’ll want to enable SMB for your shared folders. Macs can access SMB shared folders too, and SMB now appears to be used preferentially by Mac clients running Mavericks as well.

WebDAV: Created with the goal of making the Web read/write instead of just read-only, WebDAV (Web Distributed Authoring and Versioning) is a more modern file sharing protocol that is most used by iOS apps. The main reason to enable WebDAV is for specific iOS apps that require it. The OS X Finder does support WebDAV, but it’s a clunky way to access shared folders.

You can enable multiple protocols for each shared folder. For example, you could have iOS devices and Windows computers accessing the same shared folder through WebDAV and SMB respectively.

Remove Default Shared Folders

Exactly which default shared folders will have been created for you depends on what you’ve done previously. For instance, the Groups shared folder appears if you selected the “Give this group a shared folder” checkbox in Add a Group. You might also see a Public folder and one called Backups, if you’ve enabled Time Machine Server.

The default file sharing configuration won’t work for everyone, because you don’t get to say where the default shared folders actually live on your server’s drive. Therefore, before we do anything else, let’s remove the unnecessary default shared folders, after which you can create new ones that do exactly what you want.

Warning! If the Backups shared folder or another folder with a Time Machine logo on it appears, do not remove it, since Time Machine Server relies on specific shared folders in the File Sharing service!

In the Server app, select File Sharing from the Services category in the sidebar. The File Sharing pane appears at the right, showing a list of available shared folders as in Figure 31.

Figure 31: To get started with File Sharing, remove unnecessary default shared folders.

In our example, we’ll remove the built-in Groups shared folder. To do so, in the Shared Folders list, select Groups and click the minus button. A confirmation dialog appears (Figure 32). Click Remove.

Figure 32: Server asks for confirmation if you try to disable a built-in shared folder.

Disabling Protocols Instead of Deleting Shared Folders

If you’re uncomfortable with deleting these default shared folders, you can instead disable them by removing access to all the file sharing protocols. To do so, for example, double-click Public and then, in the Settings area, make sure all the checkboxes are deselected, as shown in Figure 33.

Figure 33: You can disable a folder’s sharing capability by unchecking all of its Settings checkboxes.

When you’ve deselected all the checkboxes, click the OK button to save your changes.

More generally, it’s a good security practice to share files only over the protocols you need for accessing them. You can always enable other protocols at a later date by simply checking a box here.

Create a New Shared Folder

Now that you’ve cleaned up the default shared folders, it’s time to create one or more new shared folders. As an example, let’s assume that you have a large external hard drive sharing files for members of your household, or perhaps for a small department at work.

To create the shared folder:

In the Finder, on the server computer, make a folder for the shared folder. You may also want to create subfolders within it to pre-populate the hierarchy.

Make sure the location where you create the folder is on a drive with plenty of room for future files and is backed up regularly. If you followed my recommendation in Storage and used a relatively small partition or drive to hold OS X and applications, then you’d want your shared folder to be on a larger drive or volume.

Tip: It’s totally fine to specify the shared folder as the top level of a hard drive, if you want to share the entire volume.

In the Server app, from the File Sharing pane, click the plus button.

In the file dialog that appears, browse to the location of your shared folder, Family in Figure 34, and then click the Choose button.

Figure 34: Find the shared folder and then click Choose.

Back in the File Sharing pane, double-click the new shared folder (Family in this example).

On the configuration screen for the shared folder (Figure 35), the text that appears in the Name field is the name of the folder you just selected, but you can edit it to adjust how it appears to users if you like.

Figure 35: Specify how the new shared folder will work.

In the Settings checkboxes, enable just those file sharing protocols that your users need, as explained earlier in File Sharing Protocols.

If you enable guest access, then anyone can connect without entering account credentials.

Note: If you select “Make available for home directories over” and choose the appropriate protocol from the pop-up menu, the shared folder becomes available as a network home folder directory location for those using portable home directories. As noted back in Other Home Folder Choices, portable home folders are beyond the scope of this book.

When you’re done, click OK to save your changes.

Server creates your new shared folder. Your next step is either to set up custom permissions for the shared folder, if needed, or to turn on File Sharing. I cover each option just ahead.

Create a WebDAV Share for iOS Users

Another common use for shared folders is to provide a central repository where iPhone and iPad users can store files on your server. For that, you’d want to follow the steps above, but when it comes time to select protocols, be sure to select Share over WebDAV. Obviously, enabling WebDAV is helpful only if the iOS apps your users rely on support WebDAV, but in iOS, WebDAV support is more common than support for AFP or SMB.

Configure Permissions

The specific permissions that are assigned to a shared folder vary based on where in the filesystem the folder was created, so it’s important to look at the permissions and make sure the correct users and groups have the appropriate access to the folder. You may also want to restrict access to particular subfolders within the shared folder.

Here are some examples of how you can use permissions:

Home: A parent might allow children read-only access to a shared folder containing media. That way, nothing can be deleted accidentally by a child. Or parents might store legal and financial documents in a shared folder where children don’t even have accounts.

School: Each student might need read/write access to a private folder but only write access to a folder where homework is handed in.

Business: The human resources department might want a shared folder that most employees can’t view, while the marketing department might have read/write access to a shared folder that holds logos, brochures, and product descriptions. That same marketing shared folder might be available on a read-only basis to the rest of the company so that employees can distribute marketing materials.

To specify permissions:

In Server, open the File Sharing pane and double-click the shared folder’s entry in the Shared Folders list.

Examine the left column in the Access panel to verify that the correct users and groups have access. To add a user or group, click the plus button and enter the name or choose Browse from the menu that pops up once you start typing (Figure 36). Or, to delete a user or group, select it and click the minus button.

Figure 36: Click the plus button to activate a new entry in the Access panel.

Work with the pop-up menus on the right side of the Access panel to set what each user or group may do when accessing the shared folder: Read & Write, Read Only, Write Only.

Click OK to save your changes.

Understanding the Access Entries

The bottom three entries in the Access list correspond to the folder’s Unix owner, group, and world classes, and as such can’t be deleted. However, if you want to remove access, they each have a None option in the permissions pop-up menu.

Any entries above the bottom three are part of an access control list (ACL) and lack a None option because you should delete them if you want to remove access. The permissions pop-up menu for each of these ACL entries has the options Read and Write instead of Read Only and Write Only, but they mean the same thing.

You can also limit who has access to folders within the shared folder, as you might do with a folder that contains sensitive or private items like accounting or grades. If these more granular permissions are required, follow these steps, which take place in a different part of Server’s interface:

Click the name of the server in the sidebar and then click the Storage button.

Using the expansion triangles or column browser (switch with the View buttons), browse to and select a subfolder, click the gear pop-up menu, and choose Edit Permissions.

In the dialog that appears (Figure 37), use the plus and minus buttons to add or remove users or groups from this folder, and choose your desired permissions from the pop-up menus at the right.

Figure 37: Manage permissions for a subfolder within a shared folder.

When you’re done, click OK.

If you need to specify permissions for additional subfolders, repeat the appropriate steps above.

Enable File Sharing

Although it’s okay to come back later and modify your File Sharing setup, before you turn on file sharing you should do the things in this list so you aren’t inadvertently exposing anything sensitive:

You’ve deleted or removed permissions from any default shared folders that you don’t need.

You’ve created any new shared folders that you need.

For each shared folder, you’ve ensured that it’s using only the necessary file sharing protocols (that is, AFP, SMB, and WebDAV).

For each shared folder, you’ve configured the appropriate permissions.

With all of the above taken care of, select File Sharing in the sidebar and click the ON button (at the upper right) to start the File Sharing service.

Connect to Shared Folders

Now that you’ve turned on File Sharing, it’s time to help users connect to shared folders.

To connect to a shared folder from the Mac Finder:

Choose Go > Connect to Server (Command-K).

In the Connect to Server dialog, users can type the name or IP address of your server, but they may prefer to click Browse to view servers available on the network in a Finder window, or work with the Favorite Servers list or the Recent pop-up menu.

If your shared folder is accessible via multiple file sharing protocols, specify which should be used by prefixing the name or IP address in the Server Address field with afp://, smb://, or webdav://, as Figure 38 shows with AFP.

Figure 38: You can connect to a shared folder by IP address or by clicking the Browse button to locate it in a Finder window.

Click Connect.

If the Mac asks for authentication information (Figure 39), which it will unless the credentials have already been stored in the user’s keychain, leave the Registered User radio button selected and enter the username and password that you set up for that user in directory services (see Work with Users).

Tip: If guest access has been enabled for the shared folder, a Guest radio button appears in the login dialog shown in Figure 39. To log in as a guest, select it; no username or password is necessary.

Figure 39: Enter the user’s credentials when prompted.

After the user enters a username and password, if he selects the checkbox “Remember this password in my keychain,” the next time he connects he won’t have to authenticate. (Needless to say, remembering the password generally makes things easier.) Click Connect.

If you’ve created multiple shared folders, a list of available shared folders appears in a dialog (Figure 40). You can select one or more by Command-or Shift-clicking. Click OK to mount them.

Figure 40: Select one or more shared folders to mount.

The shared folder (or folders) can now be accessed through the Shared category in the sidebar of any Finder window, in the hidden /Volumes directory, and in Open and Save dialogs. Plus, the shared folder works just like any other local folder when it comes to making an alias or adding it to the Finder window’s sidebar or toolbar.

Tip: If a user would like a shared folder to mount on startup, she can open the Users & Groups pane of System Preferences, click Login Items, and drag the icon for the shared folder from the Finder into the list of login items. Exactly when the shared folder mounts during startup isn’t entirely predictable, so it’s best not to have other login items rely on its presence.

Collaboration Services

Many of the services provided by OS X Server enable collaboration of one sort or another, but for the purposes of this chapter, I want to focus on three types of collaboration: contact sharing, calendar sharing, and instant messaging, which map to the Contacts, Calendar, and Messages services in OS X Server.

Note: Mail is often lumped in with the rest of the collaboration services and may be necessary if you want the Calendar service to send email invitations; however, given the complex nature of managing mail, I don’t delve into those details until Mail Services.

Before you wade into turning on these services, think about why you’re doing so, since contact sharing can in many cases be done more simply with a secondary iCloud account, you can more easily share calendars via iCloud (or Google Calendar), and Apple’s iMessage service is generally the easiest way to trade instant messages back and forth. If you’re setting up OS X Server for your family, turning on Contacts, Calendar, and Messages may be overkill.

Also, I need to be up front about what’s feasible with contact sharing. With OS X Server’s Contacts service, you can share contacts between your Mac and your iPhone, for instance, but you cannot inherently share contacts with other people. The workaround in the Contacts services is the same as for iCloud—create an account dedicated to sharing contacts—but each time I’ve done this for clients they’ve been unhappy when someone (or some client app) deleted or duplicated shared contacts inadvertently. Put bluntly, there’s no good solution here; sorry!

Tip: You can also share calendars on a LAN using BusyMac’s BusyCal, but such sharing works only between copies of BusyCal running on Macs; no other clients (like Apple’s Calendar app) or platforms (like iOS) can participate. For more information, read the free Take Control of Calendar Syncing and Sharing with BusyCal, by Joe Kissell.

But there are good reasons to enable these services. A shared iCloud account works only within a small family group, since the password must be shared with all members, making for an awkward situation if you have to change the password when an employee leaves. Plus, some older devices and operating system aren’t compatible with iCloud but do support the underlying protocols that Contacts, Calendar, and Messages rely on. And, depending on what your organization does or your general comfort with Apple’s online services, you may not want confidential client and meeting data on iCloud, where you aren’t in control of the security measures.

Note: Apple’s iCloud requirements for Contacts and Calendar are a minimum of iOS 5, 10.7.5 Lion, Windows Vista or later, or Outlook 2007; see Apple’s System requirements for iCloud article. See Joe Kissell’s Take Control of iCloud for more about sharing calendars in iCloud and setting up a secondary account for sharing contacts.

Turning on Contacts, Calendar, and Messages in OS X Server is easy, but understanding how your users will interact with them and configuring their client apps is a bit more involved.

Before you begin, make sure you’ve set up Open Directory, as detailed back in Set Up the Open Directory Master, and turned on push notifications, which you did in Configure Alerts. Push notifications are important because they enable your server to automatically send updated information to available clients that are configured to receive push notifications. Thus, if one user changes the address in a contact’s record or adds an event to a calendar, that change is rapidly sent to all other devices.

Testing Your Services

The collaboration services take a little getting used to. I recommend that you set them up and use them between a couple of test accounts before configuring the clients for all your users. Send calendar invitations, create contacts, and see what data synchronizes and how. Get used to the workflow before you expect anyone else to.

Using the Contacts Service

Unsurprisingly, the Contacts service in OS X Server is designed to talk to the Contacts apps in both OS X (10.8 Mountain Lion and later) and iOS. It does this through CardDAV, an open source protocol designed to store contact information on Web servers such that it is quickly and efficiently retrievable and digestible by apps on client devices. Because CardDAV is a widely used standard, you should be able to connect to the Contacts service from a variety of software and devices, not just those from Apple.

What about LDAP?

There’s another protocol involved with Contacts: LDAP, or Lightweight Directory Access Protocol, which is the foundation of Open Directory. It’s often used by large organizations to distribute directory information such as contact data to users. The Contacts service can theoretically act as a one-way conduit from an Open Directory server to a Contacts client, so that the client can display information from Open Directory. In reality, however, it’s extremely difficult to set up and maintain Open Directory–based contact information in OS X Server, since Apple doesn’t provide a functional interface for doing so.

The Contacts client apps in both OS X and iOS can access existing LDAP servers directly, so if you’re in a large organization that already runs an LDAP server, you can set up those apps to look up (but not sync) LDAP-based contact data.

Enable the Contacts Service

I know I’ve said this about other services in OS X Server, but the Contacts service couldn’t be easier to configure. You’ll have no trouble following along with these steps:

Select Contacts in the Services section of the sidebar to open the Contacts pane (Figure 41).

Click the ON button at the upper right to enable the service.

Figure 41: To enable the Contacts service, flip the switch.

Note: Don’t select the “Allow users to search the directory using the Contacts application” checkbox; it’s what enables the Contacts service to connect to LDAP-based contact information, and as noted in What about LDAP? above, that’s not worth doing.

The Contacts service starts and a small green icon appears beside the Contacts entry in the sidebar.

Configure Contacts Clients

When you set up a client, you’ll be signing in to the Contacts service with authentication information for a user that you set up back in Work with Users. You’ll also need to have turned on the Contacts service for that user (see Manage Users) or for a group that the user is in (see Manage Groups). It’s okay to add or modify a user at any time, so go back and do that now if needed.

Obviously, the specific steps for configuring a client to access your Contacts service depend on the particular app. Fortunately, it’s easy to generalize from one piece of software to the next, and we’ll look at configuring the Contacts apps in OS X and iOS.

Note: Keep in mind that turning on the Contacts service in Server and connecting to it from the Contacts apps doesn’t populate the server with any actual contacts. You’ll have to copy contacts from other locations to the server, or create new contacts on the server.

Configure Contacts in OS X

To connect to the Contacts service in OS X, follow these steps:

In Contacts for OS X, choose Contacts > Preferences > Accounts.

At the bottom of the accounts list on the left, click the plus button, select “Other contacts account” at the bottom of the account types dialog, and click Continue (Figure 42).

Figure 42: To connect from the Contacts client app to the Contacts service, select “Other contacts account.”

In the CardDAV slide-down dialog (Figure 43), choose CardDAV from the pop-up menu and then provide a valid username and password for one of your users.

Figure 43: To make the connection, you need to authenticate as a user on OS X Server and give the server’s name or IP address.

In the Server Address field, type the server’s name or IP address.

Click the Create button.

Tip: If you need to change the server address or access the Contacts service on a custom port, you can do that in the Server Settings view for the account later on.

Once you’re done, close the Preferences window and look at the sidebar in the Contacts app, where you see another top-level entry for your server. There won’t be any contacts stored there yet, so try two things:

To create a new group on the server, hover over the name of the server in the sidebar and then click the plus button that appears. Give it a reasonable name.

Drag a contact from another source (On My Mac or iCloud) to the group you just created. If it’s not selected already, click the group.

If the contact you dragged appears, you know everything is working, and you can double-check by looking for that contact from another device that connects to the same account.

Tip: For contacts to sync to other devices, they must be in the server in the sidebar; if they’re in On My Mac or iCloud, they won’t sync.

Configure Contacts in iOS

To configure the Contacts app in iOS to access your Contacts service, follow these steps:

Navigate to Settings > Mail, Contacts, Calendars, and then tap Add Account.

At the bottom of the list of account types, tap Other.

In the Contacts section, tap Add CardDAV Account.

On the CardDAV screen, enter the server name along with your username and password (Figure 44).

Figure 44: To connect to the Contacts services from iOS, you need to add a CardDAV account in Settings > Mail, Contacts, Calendars.

To verify that everything is working, open the iOS Contacts app, tap Groups, and select only the group you created previously; you should see the single contact you added to it.

Using the Calendar Service

Whereas the Contacts service relies largely on CardDAV, the Calendar service is built on CalDAV, another open-source protocol that’s used by the Calendar apps in both OS X (10.8 Mountain Lion and later) and iOS. CalDAV enables clients to access scheduling information on a server and is itself based on the iCalendar format for event data. Because CalDAV is a widely used standard, you should be able to connect to the Calendar service from many different apps and devices.

Does that all sound familiar from just above in Using the Contacts Service? It should; Apple has intentionally focused its efforts on making contact and calendars work the same everywhere, and the CardDAV and CalDAV standards are a big part of that.

Once you enable the Calendar service, your users will be able to create calendars on your server and share them with one another. As with the Contacts service, merely creating the Calendar service and connecting to it from clients doesn’t result in any data appearing; your users need to create calendars and populate them with events before anyone sharing those calendars will see anything.

There is one exception to that rule: you can create special calendars for locations and resources, and you do that in the Calendar service itself. You might do this to avoid scheduling conflicts, as might be important in an office with a heavily used conference room, or even for families with teenagers competing to borrow the car. By adding events to those special calendars, people can reserve places and resources on a first-come, first-served basis (or at least negotiate with those who have already reserved them).

Configure the Calendar Service

Although not quite as easy as enabling the Contacts service, configuring the Calendar service is a simple, straightforward process:

In Server, click Calendar in the Services section of the sidebar to display the Calendar pane, as shown in Figure 45.

Figure 45: Turn on the Calendar service with the ON button in the upper right; all the other settings are optional.

Click the ON button at the upper right to enable the service.

That’s all you need to do, unless you want to create special calendars for locations and resources or you want to enable the Calendar service to send event invitations by email.

Create Location and Resource Calendars

To create individual calendars for locations (like meeting rooms) or resources (like a family car), follow these steps:

In the main Calendar pane, click the plus button at the lower left to open a configuration pane.

From the Type pop-up menu, choose whether the calendar is for a location or a resource and enter a name that your users will understand in the Name field (such as 1964 Dodge Dart).

From the Accept Invitations pop-up menu, choose whether requests to schedule the resource are accepted automatically by the server or must be approved by a delegate (or be from a user who is in an authorized group; see Work with Groups).

In the Delegate field, enter the names of users or groups that are allowed to manage this calendar (if you don’t remember them exactly, click the Browse item that appears). The people associated with these accounts can also approve requests.

If you chose With Delegate Approval, an Accept Group field appears (Figure 46). Requests from users in a group entered here will be accepted automatically, without delegate approval.

Figure 46: Working in the Server app, you can name and configure a resource calendar.

Click Create (not shown) to complete the setup.

The new calendar appears in the Calendar pane in the Locations and Resources list. To adjust any of its settings, double-click its entry. Repeat these steps to create more locations and resources, as desired.

Enable Email Invitations

Let’s say you have a location calendar for a conference room, and you want to schedule a meeting for next Tuesday. (This example assumes that you’ve already connected your Calendar app on the Mac to the Calendar service, which I’ll get to in Configure Calendar Clients; bear with me for a minute.)

You can invite specific people to your meeting, and if they all have accounts on your server and have set up their calendar apps as well, they’ll receive notifications within their apps.

But what if you want to invite people from outside your company too? You can also do that, but the Calendar service won’t send them in-calendar invitations. What the Calendar service can do, however, is create and send an email message to each invitee automatically, and if the invitee replies to it, the Calendar service can update the event to reflect whether or not the person is coming. To do that, you must run through some additional steps to configure the email account to send and receive these invitations and responses.

You can take either of two approaches here:

External: Rely on an external mail service—even something like a free Gmail or iCloud account. That works fine, but make sure this account is used only for invitations; it shouldn’t be a personal account or one used for any other purpose.

Internal: If run OS X Server’s internal Mail service, the Calendar service can use it to send and receive invitation-related email. That’s harder, not because configuring the Mail service is particularly difficult but because running a mail server means trying to maintain 24/7 uptime while facing a constant onslaught of spam. Simply put, mail is a toxic hellstew, and one that’s best left to large organizations with money and people to throw at the problem.

If you want to use the internal Mail service, you can follow the steps below, but no email can be sent until you also enable Mail Services. Or you can skip these steps for now and come back after you’ve enabled the mail server.

Regardless of whether you go the external or internal route, follow these steps to enable email invitations:

In the main Calendar pane, select “Enable invitations by email,” which invokes the Configure Server assistant.

In the slide-down dialog that appears (Figure 47), Server suggests an email address to use for outgoing event invites:

If you’re going to use an external mail service, enter the address for the account you’ve created for that purpose.

If you’re going to use the internal Mail service, stick with the default address, since it maps to an existing built-in account.

Figure 47: Enter the address that will be used to send Calendar invitations.

Click Next to open the next Configure Server Email Address screen (Figure 48).

Figure 48: Set up the incoming mail account.

Specify the email account you previously defined in the Email Address field (again, this could be on an external mail server or the Mail service running on your server), as follows:

Mail Server Type: Choose the type of incoming mail service that will receive incoming invitation replies. If the mail server you’re using offers IMAP, I recommend sticking with that so you can access the messages yourself for troubleshooting if needed.

Incoming Mail Server: Enter the name or IP address of the mail server. If you’re using the internal Mail service, this will be the name of your server (see Configure DNS on the Server).

Port and SSL: Unless you’re messing around with custom ports, leave the Port field set to 993. Leave the SSL checkbox selected.

User Name: This is the username portion of the email address you configured in Step 2.

Password: If you’re using an external mail service, enter the password for the associated email account. If you’re using the default entries for the internal mail server, the Password field for the com.apple.calendarserver account is filled in for you. Do not change it!

Click the Next button to move along to specifying the outgoing mail server (Figure 49) through which invitations will be sent.

Figure 49: Enter the necessary settings for the SMTP server that will be used to send invitations.

Set up the outgoing mail account as follows:

Outgoing Mail Server: Enter the name or IP address of the outgoing SMTP server. Again, if you’re using the internal Mail service, this will be the name of your server or its mail exchanger (MX) DNS record.

Port and SSL: Again, unless you know what you’re doing, leave the port set to 587 and leave the SSL checkbox selected.

Authentication Type: From this pop-up menu, you can choose None, Plain, Login, CRAM-MD5, or Kerberos. Stick with Login unless you’re using the internal Mail service and plan to restrict the authentication methods (see Configure the Mail Service).

User Name: This is once again the username portion of the email address that sends and receives invitations.

Password: This password is most likely the same as the one you entered previously if you’re using an external mail service; if you’re using Server’s internal Mail service, it’s pre-filled for you and should not be changed.

Click Next.

At the Mail Account Summary screen, review the settings, and click Finish if they’re correct. If you see any mistakes, click the Back button and make your corrections.

Note: As I mentioned earlier, if you’re using Server’s Mail service, you’ll need to click it in the sidebar and turn it on for anything to work, but I recommend waiting until you’ve read Mail Services.

Configure Calendar Clients

Once the Calendar service is configured and you’ve enabled the Calendar service for the users set up on Open Directory (described in Work with Users), you can connect to it from various clients, such as the Calendar app in OS X and iOS. Once a user’s client has established a connection, he can create calendars that will be stored on the server and that can be shared with other users set up in Open Directory.

Note: It’s important to realize that calendars can be shared only with other users on the same service. That’s the same reason iCloud calendars can be shared only with other iCloud users. Apple’s Calendar app in OS X adds confusion by suggesting people who aren’t on the local server when you’re sharing a calendar.

Configure Calendar for OS X

To start, we’ll look at how to connect from Calendar for OS X:

Working on a client Mac, open the Calendar app and choose Calendar > Preferences > Accounts.

Beneath the Accounts list on the left, click the plus button to display a dialog of account types you can add.

Select Add CalDAV Account, and click Continue.

From the Account Type pop-up menu in the dialog that appears next, choose Manual.

Note: You could choose Automatic and enter the username and server address in the form of an email address, but that’s no easier and might not work, depending on other configurations. Choosing the Advanced menu option adds fields for Server Path and Port, and checkboxes for using SSL and using Kerberos v5 for authentication. None of that is necessary.

Enter the user’s username and password as configured on the server, and type the name or IP address of the server (Figure 50). Click Create.

Figure 50: Enter the user’s credentials and the server name or IP address.

Once a connection is confirmed between the server and the client, the server appears in the list of accounts in the sidebar of the Calendar app (click the Calendars button at the top left to show and hide this sidebar).

Configure Calendar for iOS

Adding a CalDAV account in iOS is much like adding a CardDAV account, as explained in Configure Contacts in iOS:

Navigate to Settings > Mail, Contacts, Calendars > Add Account > Other > Add CalDAV Account.

Enter the name of your server and the appropriate username and password, and tap Next (Figure 51, left).

Tap a switch to turn on (or off) calendar events or reminders for the CalDAV server and tap Save (Figure 51, right).

Figure 51: Add a CalDAV account in Settings > Mail, Contacts, Calendars.

You can create and share calendars in iOS, but I find it easier to do in OS X (next).

Create and Share Calendars

Back in Calendar for OS X, it’s now time to create a calendar and share it with other users:

Choose File > New Calendar > ServerName.

A new calendar appears under the server’s name in Calendar’s sidebar; give it a sensible name.

To share your new calendar, either hover over its name until the Wi-Fi–like broadcast icon appears and click that, or just Control-click the calendar and choose Share Calendar, as shown in Figure 52.

Figure 52: Share your newly created calendar.

In the Share Calendar With popover, enter the user accounts with which you want to share the calendar, as I’ve done with Emerald Edge in Figure 53.

Figure 53: Enter the names of users with whom you want to share the calendar.

Once the invited user adds a CalDAV account pointing at the server as well, she will receive a notification near the upper left of the Calendar app’s toolbar, adjacent to the plus button. If she clicks the Join button to accept the invitation, the shared calendar appears in her sidebar under the server name, and changes made on one client are reflected quickly on all the rest.

Issuing Invitations to Events

Remember our example of creating a meeting event and wanting to invite people from outside the company via email? To do that, when you create an event or edit one you’ve created, enter names or email addresses in the Add Invitees area in the event’s Info dialog. Users on your server get a notification in Calendar itself (that upper left area); those not on the server receive an email invitation with the event attached as a .ics file that they can double-click to add to their own calendar.

The only problem is that if you invite a user on the server to an event on a shared calendar, when that user accepts the invitation, Calendar duplicates the event on another calendar for that user. In general, it’s better to issue invitations only to events on private calendars.

What’s a Delegate?

Technically speaking, when you “share” a calendar, you are “delegating administration to” the accounts you share with, meaning that someone logged in with one of those accounts can help you maintain the calendar. That’s why you’ll see terminology about “delegates” throughout the Calendar service and Calendar app.

This points to a way to share a calendar other than the steps above.

If I wanted to delegate administration to my office assistant, I could also go to Calendar > Preferences > Accounts on my Mac, select the entry for my calendar server, click the Delegation button, click the Edit button, enter my assistant’s name, and select the Allow Writes checkbox (without Allow Writes, my assistant would only be able to read my calendar). Then, on his Mac, he’d open to Calendar > Preferences > Accounts, select the calendar server entry, and click the Delegation button, but he’d then select the Show checkbox for my user. A new Delegates heading would appear in the sidebar in his copy of Calendar, with my calendars showing under it.

Configuring the Messages Service

Let’s change gears and configure the Messages service, which relies on the Extensible Messaging and Presence Protocol (XMPP, also called Jabber) to let users exchange instant messages, using your server as the intermediary.

The big advantage of using a Messages server is that your communications are never stored on Apple’s servers, and those within your network never touch the outside Internet. Here are a few typical reasons you might want to use the Messages service:

Transcript retention. This could be important for auditing reasons, for example.

Confidential conversations that need to remain under your control.

Making instant messaging available internally while restricting the use of external chat services.

Getting started with the Messages service couldn’t be easier:

In the Server app, click Messages in the sidebar to open the Messages pane.

In the Messages pane, there are only two options:

Enable server-to-server federation: If you’d like to enable chats between users on different servers, select this checkbox and click its associated Edit button to enter specific details. Federation links two Messages servers, or a Messages server and another server that supports XMPP; however, it’s beyond the scope of what we’re trying to do here, so see the Apple server documentation to learn more about federation.

Archive all messages: Select this checkbox if you want the Messages service to save a copy of every message sent. Once enabled, every message sent through the server will be stored in the /Library/Server/Messages/Data/message_archives directory, which you can access quickly by clicking the arrow icon adjacent the checkbox.

Click the ON button at the upper right (Figure 54).

Figure 54: Configuring the Messages service is trivial—just click ON.

You now have a fully functional Messages server!

Configure Messaging Clients

Now it’s time to configure client apps. Any Jabber-compatible app should work, but I’ll focus on Apple’s Messages for OS X.

Before you begin, make sure that your users are set up in Open Directory with accounts and that those accounts have access to the Messages service (see Work with Users, earlier.)

To set up Messages for OS X:

In Messages, choose Messages > Add Account; then select “Other messages account,” as shown in Figure 55, and click Continue.

Figure 55: To connect to a Messages server from the Messages app, select “Other messages account.”

In the Add a Messages Account dialog, choose Jabber from the Account Type pop-up menu (Figure 56).

Figure 56: Tell the messages client how to connect to the Messages service by providing the account and server details.

In the Account Name field, enter the user’s short name and the server name in the form of an email address, as in krypted@mavserver.pretendco.lan (the short name is the Account Name described in Add a User, earlier).

Enter the user’s password in the Password field.

Click Create to set up the new account.

You can take the new account online and use it like any other instant messaging account in the Buddies window in Messages.

Mail Services

Despite the constant claims about how email is dead (to be replaced by Facebook, Twitter, instant messaging, or whatever), no communication medium is more important to most organizations than email. Even people who claim they don’t use email much get testy when they miss an important message or can’t log in a while. Email is important.

It’s also conceptually simple: the SMTP, IMAP, and POP protocols on which email relies have been around for decades, and there’s not much to maintaining the databases of users and messages. In OS X Server, enabling all the Unix apps that provide mail services under the hood is merely a matter of clicking an ON button and twiddling a few checkboxes.

But there’s a huge catch. Email is an ecosystem; no mail server can stand on its own, because it must be willing to accept messages from anywhere on the Internet and be capable of sending to anywhere. And due to spammers and other nogoodniks, every email server on the Internet is constantly being bombarded with spam, viruses, and malware, often sent by zombie computers marching in massive international botnets. And don’t get me started about dealing with distributed denial of service (DDoS) attacks, having your server used to relay spam, or the massive blowback that happens when the address of one of your users is used as the return address for spam. As I said in an earlier chapter, email is a toxic hellstew, and I strongly recommend that you avoid running your own mail server. I don’t, not any more.

Here are my recommendations:

For an individual hoping to run a mail server for a family, OS X Server will work, but unless you have vast amounts of free time to tinker with settings and deal with spam, you’re better off signing up everyone in your family for individual email accounts with iCloud, Gmail, FastMail, or the like.

For a small business in need of mail services, the amount of time you’ll spend (or pay a consultant to spend) on OS X Server makes it a poor investment. Instead, try something like Google Apps for Business, which costs $50 per user per year, or Microsoft’s Office 365 for Business, which starts at $60 per year but includes a full Microsoft Office subscription for $150 per year. In general, Office 365 is better if you need Exchange compatibility or have predominately Windows clients; otherwise Google Apps is a bit cheaper.

For an organization that must run its own mail server, look at Kerio Connect. It isn’t cheap, starting at $465 for five users for a year, but it is an industrial-strength mail server.

As much as I’m trying to warn you off enabling mail services in OS X Server, I’d be remiss if I didn’t walk you through the basics so you can either turn on mail services or reflect on what would be involved.

If you do turn on the Mail service, I keep these configuration options and policies in mind as you go, because they’ll help secure your server:

Use SSL so that your users’ email passwords can’t be sniffed when they check mail at public hotspots like Starbucks. This option is enabled by default, using the self-signed certificate you created when setting up push notifications. I explain how to confirm your certificate at the beginning of Configure the Mail Service, ahead.

Use all of Server’s options for scanning incoming and outgoing mail for viruses and spam. See Edit Filtering Settings, ahead.

Ensure that your users have strong passwords with good password policies. See Configure Password Policies, previously.

Protecting Your Mail Server with a Cloud Service

If you’re hell-bent on running your own mail server with OS X Server, let me encourage you to look into an email security system like McAfee’s SaaS Email Protection and Continuity, which sits (virtually) between your mail server and the rest of the Internet, filtering incoming spam and enforcing outgoing mail policies. Should your mail server go down, it can also cache incoming mail and hold it until you bring the server back online. It costs about $20 per user per year.

Mail under the Hood

I haven’t revealed which Unix applications are running under the hood for most of what we’ve done in Server so far, but because there are a number of well-known Unix mail servers it might be useful for you to know which ones Server uses. For SMTP, Server uses Postfix, and for IMAP and POP, it uses Dovecot.

If you’re ever looking for instructions on how to configure an SMTP milter (mail filter) or an IMAP plug-in, you’ll be looking for information surrounding Postfix and Dovecot.

Prepare to Run a Mail Server

Before you start configuring in the Server app, you have some ducks to line up. These tasks vary (widely) depending on your specific situation, but the general instructions below should get you started.

So far, we’ve configured your server with the assumption that it will be used only inside your LAN and will not be accessible to the outside Internet. For a mail server, that obviously won’t work. (Technically, you could set up the mail server to provide email for just staff in an office without any connections to the outside world, but in my experience that’s a nonstarter, because users always want to exchange email with other Internet users.) So, some of these tasks relate to putting your server on the Internet.

Static IP Address

Back in Configure the Server’s IP Address, you ensured that your server would have a static IP address on the LAN. It’s also essential that it have a static IP address for the outside Internet (in networking jargon, the WAN, or wide area network). You’ll need to set that up with your ISP.

In IP Address, I talked about how you might be able to use dynamic DNS instead, dynamic DNS is a bad idea for a mail server. Any interruptions in service will likely cause mail delivery failures, which will make your users crazy.

DNS Configuration

Along with that external static IP address, you need to have a real domain under which all this mail will be handled, and an external hostname for the server. So, where we’ve been using mavserver.pretendco.lan as an example for the internal domain name, for the purposes of this discussion we’ll assume you want to receive email at pretendco.com. And we’ll assume that your server’s hostname (and thus machine, or A record) will be osx.pretendco.com.

Tip: To refresh your memory about all these DNS record types, look back at Understand Zone and Record Types.

Tasks to complete with your external DNS provider and ISP include:

Create a machine or A record for osx.pretendco.com, pointing it at your external static IP address.

Set up an alias or CNAME for mail.pretendco.com, pointing it at osx.pretendco.com.

Set up a mail exchanger or MX record that says mail destined for pretendco.com should be handled by mail.pretendco.com.

Get your ISP to create a reverse mapping, or PTR record, that associates your external static IP address with mail.pretendco.com. This is necessary because some mail servers need to verify that your mail is coming from a legitimate server, and the presence of a PTR record is one of the ways they determine that.

Port Forwarding

It’s also essential that you open particular ports on your router so that email can flow in and out. This is easily done in AirPort Utility, if you’re using an AirPort base station as your router; other routers should be similar. The ports you need to forward may include the following (but if you’re not planning to let clients use POP, for instance, don’t forward those ports):

SMTP: 25

SMTP alternate submission port: 587

IMAP: 143

IMAP with SSL: 993

POP: 110

POP with SSL: 995

Happily, AirPort Utility lets you choose these from a pop-up menu (Figure 47), making configuration even easier, since it fills in the Public TCP Ports, Private IP Address (that of your server), and the Private TCP Ports fields for you.

Figure 57: Setting up port mapping for mail services in AirPort Utility is just a matter of choosing from the Description pop-up menu.

(To view the menu, edit your base station in AirPort Utility, click the Network button, and then click the plus button beneath the Port Settings list.)

Connecting to a Mail Server When Port 25 Is Blocked

If one of your users is in a hotel or other place that blocks port 25 to protect against spam, she won’t be able to send mail unless one of these workarounds is in place:

She can use a VPN to connect to the server to send email.

Your server accepts incoming SMTP connections on port 587, the alternate submission port.

On the router, you can forward a custom port to port 25 in order to connect to SMTP. For this solution to work, you must set her mail client to use this custom port for SMTP outgoing mail.

Checking the RBLs

One of the main ways that server administrators configure their mail servers to block spam is via real-time blackhole lists, or RBLs. The basic idea is that as soon as a mail server is identified as sending spam, its IP address is added to an RBL. When receiving messages, other mail servers consult RBLs to see if the sending server is known to relay spam, and if so, the receiving server rejects the message.

In general, RBLs are good, since they reduce the impact of spam on the Internet immeasurably. However, if your IP address is on an RBL when you set up your mail server, the mail your server sends may be rejected or even dropped silently without being delivered. So, it’s important to check the RBLs before you start, to make sure your IP address isn’t on such a list.

(Why would this happen? Depending on how your ISP sets things up, other clients may share the same IP address as you, or if you’ve gotten the IP address recently, it’s possible the previous user’s mail server had been taken over and used to send spam, landing the IP address on an RBL.)

Luckily, there are multiple services that will check a long list of different RBLs for your IP address. A popular checking site is MX Toolbox (Figure 58); you might also try the Multi-RBL Check of The Anti-Abuse Project.

Figure 58: With the free MX Toolbox service, it’s easy to check whether your IP address is on an RBL.

Tip: It’s a good idea to subscribe to an automatic RBL checking service like MX Toolbox’s free plan or RBLmon, since they’ll alert you if your mail server ends up on any RBLs in the future. If that happens, it’s imperative that you fix whatever problem got you on the list and try to get off it as soon as possible, or delivery of outgoing mail from your server may be impaired.

Backing up Users, Mail, and Settings

Mail is critical for most businesses, and even many home users live and die by their email (which is stored on the server for IMAP users), so it’s not only essential that your mail server be up and running 24/7 but also imperative that you back it up constantly and be able to restore it quickly in the event of a disk failure or other catastrophe.

The later Backup chapter is devoted to the topic of backups, so I won’t say much about it here, but before you bring your mail server online, jump forward to that chapter and make sure you’re backing up appropriately.

Note: For more information about backing up, see Joe Kissell’s Take Control of Backing Up Your Mac.

Configure the Mail Service

Once all the tasks listed in the previous topic are taken care of (and I mean all), it’s time to start working in the Server app.

The first step is to make sure you have an SSL certificate associated with various mail services, since it will be used to encrypt your logins. Luckily, since you configured push notifications back in Configure Alerts, this is just a quick confirmation step.

In the Server app, click Certificates in the Server section of the sidebar. Under Settings, the Secure Services Using pop-up menu should be set to your server’s hostname, indicating that the self-signed certificate you created when enabling push notifications is being used to secure all services. To verify that it’s being used for mail in particular, click that menu and choose Custom. In the dialog that slides down, you should see two Mail entries (Figure 59). Click OK.

Figure 59: Make sure your self-signed certificate is selected for Mail (IMAP and POP) and Mail (SMTP).

Note: If you had a trusted certificate installed in Server, you could select it instead of the self-signed certificate.

Now let’s configure the mail service. Click Mail in the Services section of the sidebar. Although there are only six controls in the Mail pane, plus the main ON button (Figure 60), some of them require a fair amount of explanation.

Figure 60: Mail settings in the Server app.

Provide Mail For

The first setting is the primary domain for which you’re going to provide mail services. This is not the fake domain we’ve been working with all along, but the real domain that you configured at your DNS provider earlier in this chapter. Since OS X Server defaults to the domain in the server’s hostname, you’ll need to change it to your real domain.

Click the Edit button to the right of Provide Mail For, enter the desired domain in place of the fake one, and if you want to provide mail for additional virtual domains (which would require additional DNS setup at your DNS host), click the plus button and enter them as well (Figure 61). Click OK.

Figure 61: Enter the real domain for which you want to provide mail services.

Each user account that you’ve set up on your server has a short name, and you’ll end up with an email address for each short name at each domain. For example, if you have accounts for charles and emerald, those accounts will be able to receive email at charles@pretendco.com and emerald@pretendco.com. And if you set up a virtual domain of toxichellstew.com, those users could also receive mail at charles@toxichellstew.com and emerald@toxichellstew.com.

Authentication

Your users must authenticate whenever they try to exchange mail with your server, both incoming and outgoing. OS X Server supports a wide variety of authentication protocols, including Kerberos, Digest (CRAM-MD5), Cleartext, APOP (for POP only), and Digest-MD5, and a number of sources for that authentication information, including Open Directory, Active Directory, and the set of local users.

The easiest approach here is to stick with Automatic, which will query your Open Directory master for authentication information and allow any of the authentication protocols.

If you want to set particular authentication sources or protocols, click the Edit button next to Authentication. Make your choices using the Authenticate Using pop-up menu and, if you choose Custom, the protocol checkboxes (Figure 62). Click OK.

Figure 62: Stick with Automatic for authentication, but if you need to be more specific, it’s possible.

Push Notifications

There’s nothing to do here, since you turned on push notifications long ago, in Configure Alerts. What you actually did was to enable push notification of new email messages. What does that mean?

Imagine that a new message arrives at the mail server for charles@pretendco.com. With push notifications on, the mail server notifies that user’s email client that it should retrieve the message via IMAP. Push notifications are just an alert to the client that it should check in. The utility of push notifications, particularly for a mobile email client, is that the client doesn’t have to check for new email unless there is some. This reduces network traffic, CPU usage on the device, and battery drain, all while providing near instant delivery of new email.

Relay Outgoing Mail through ISP

To reduce the damage done by badly set up (and thus easily compromised) mail servers, many ISPs block all SMTP traffic on their networks that doesn’t go through one of their own servers. In other words, depending on your ISP, your mail server may not be able to send mail at all to any outside server on the Internet.

The workaround is to relay all outgoing mail through your ISP’s SMTP servers, which will accept your outgoing messages and send them on to their eventual destinations. Even if you can send mail directly, you may not want to, because relaying mail through another server reduces the chance that your server will be blacklisted for some bad behavior.

There are three main approaches for relaying through another server:

Your ISP: Talk to your Internet service provider and see if they require that you relay through them. Even if they don’t require it, see if they would allow you to relay through one of their servers.

An email appliance: There are a variety of devices you can buy, such as a Barracuda Spam Firewall, that sit between your mail server and the Internet, filtering both incoming and outgoing mail. They cost about the same as a computer ($2,000) and may have annual upgrade fees.

External filtering service: A cloud-based service, like McAfee’s SaaS Email Protection and Continuity, may be more cost-effective than an email appliance and offers basically the same incoming and outgoing filtering capabilities.

To configure your mail relay, click the checkbox for Relay Outgoing Mail through ISP, and, in the dialog that appears, enter the hostname of the other mail server, adding your username and password if SMTP authentication is necessary (Figure 63).

Figure 63: Configure your outgoing mail relay if necessary.

Limit Mail To

Many users don’t delete incoming email, which has both pros and cons. On the pro side, thinking about which messages to delete and which to keep takes time that could be spent more productively, and it can be useful to have a complete archive of old email. On the con side, that email can take up a lot of disk space, especially if your users tend to receive a lot of large attachments. Plus, for some businesses, archived mail can prove a legal liability if subpoenaed in a lawsuit.

OS X Server doesn’t have any way of enforcing email retention policies, but you can set the total amount of mail each user can keep: select the Limit Mail To checkbox and enter the mail store size in megabytes. It defaults to 200 MB, but you can enter any number of megabytes you like.

Storing User Email on a Different Drive

By default, Server stores its service data, including user email messages and attachments, on the boot drive. If that drive doesn’t have as much space as you’d like, or if you want to separate the service data from your boot drive, you can move the data to another drive.

Click the name of your server in the sidebar, click the Settings button in the main pane, click the Edit button to the right of Service Data, select a different drive, and click Choose. Server moves the service data.

If, on the other hand, you’re moving mail to a new server, you’ll likely use the Migration Assistant to migrate Server, which is the only easy way to retain mail settings and data. This process can fail, so patience and repetition may be required.

Edit Filtering Settings

Unless you’re using an email filtering service like McAfee’s SaaS Email Protection and Continuity, you’ll certainly want to turn on Server’s email filtering capabilities. To view these controls (Figure 64), in the Mail pane click the Edit Filtering Settings button.

Figure 64: Turn on filtering services unless your mail server is already protected by a cloud-based filtering service or email appliance.

Apple packs a lot into a single dialog, so let’s go through all of the filtering services in turn:

Virus filtering: Handled by a Unix app called ClamAV, this service scans all messages for known viruses. To keep up with newly discovered viruses, Server relies on a process called freshclam, which downloads updated virus definitions from the Internet periodically.

Messages containing viruses aren’t delivered but rather are stored in /var/virusmails, and notification is sent to the address configured for email alerts.

Blacklist filtering: You don’t want your server to appear on a real-time blackhole list, but it’s a good idea to take advantage of RBLs when filtering incoming mail for spam. By default, Server is set to use Spamhaus, but there are numerous other RBLs you can employ (an overwhelming number, in fact). If you want to use multiple RBLs, separate them with commas.

Greylist filtering: Whereas a blacklist is definitive—either a server is on it or it’s not—greylist filtering is fuzzy. When you enable greylist filtering, your mail server temporarily rejects all mail from unknown senders while recording the IP address of the sending server, the address of the sender, and the address of the recipient. Legitimate mail servers won’t be offended and will just retry the message some minutes later, and on the second try the message will be accepted. Greylisting works because spam apps don’t generally retry rejected messages; they’re trying to send so many messages that they can’t afford the delay in retrying.

Junk mail filtering: This last option provides an interface to the well-known SpamAssassin package. SpamAssassin evaluates all incoming messages against a massive set of rules, assigning points for aspects of messages that are “spammy.” Each message ends up with a SpamAssassin score, which is compared against the slider setting (note the number of points associated with each slider setting). If the number of points accumulated by a message is greater than the SpamAssassin setting, SpamAssassin adds ***JUNK MAIL*** to the Subject of the message and delivers it. Users can then configure their email clients to filter such messages to a Junk Mail mailbox.

Enable Mail Services

Once you’ve configured all the settings for the Mail service, click the ON button to enable the service. It may take a few minutes while Server starts all the various related services and downloads new virus definitions.

You can set up a mail client to check your work, but for the moment it’s easier to launch Terminal on another computer and use the telnet command to see if your mail server is working. Enter this command in Terminal, changing the hostname to that of your mail server:

telnet mail.pretendco.com 25

If it’s working, you should see a response like the following:

Zeus:~ adam$ telnet `mail.pretendco.com` 25

Trying `mail.pretendco.com`...

Connected to `mail.pretendco.com`.

Escape character is '^]'.

220-`mail.pretendco.com` ESMTP Postfix

To exit the conversation with your server, type quit and press Return.

Adding Webmail to Your Server

One glaring omission in OS X Server is a good webmail interface. Webmail enables your users to access their mail from a Web browser. This can be handy, if you’re sitting in an Internet café in Budapest and you need to check the itinerary of your upcoming flight to Gothenburg.

There are a variety of free webmail clients, but I like Roundcube because it’s more modern than many of the others, which make you feel like you’re checking email in 1998. Roundcube can be a bit challenging to set up and configure manually, but the good people at Topicdesk have packaged it into a nice little installer that does all the work for you.

Tweak Mail Settings via Command Line

Apple has exposed relatively few settings for Postfix, Dovecot, ClamAV, and SpamAssassin via Server’s graphical interface. As you might expect from mature Unix apps, there are many more settings you might want to configure, which must be done from the command line.

First, there’s a useful command-line invocation that will give you details of the status of each service. In Terminal on the server itself, enter this command:

sudo serveradmin fullstatus mail

Next, to see a full list of mail-related options, enter:

sudo serveradmin settings mail

To be clear, many of the default settings are fine and shouldn’t be messed with unnecessarily. If you’re going to change something, make a note of what the setting was before you change it, in case you break something and need to put it back. Here are a few settings that people commonly want to change.

Note: All these commands must be entered on a single line, so if you’re copying from a source in which they wrap, paste into a text editor first and make sure they’re on one line before you paste into Terminal.

Reset SpamAssassin’s Subject Line

If you don’t like SpamAssassin’s default ***JUNK MAIL*** Subject tag, you can change it with this command:

sudo serveradmin settings mail:postfix:spam_subject_tag = "***DIE SPAMMER DIE***"

Enable Virus Notifications

By default, the administrator doesn’t receive an email notification when ClamAV catches an email containing a virus-infected attachment. To enable this option and configure the address that will receive notification, use these commands, changing the address as desired:

sudo serveradmin settings mail:postfix:virus_notify_admin = yes

sudo serveradmin settings mail:postfix:virus_notify_admin_email = "virus-admin@example.com"

Change Message Size Limits

I find that a lot of Mac environments want to accept email messages of pretty much any size rather than reject messages with too-large attachments. By default, message size limits are enabled. To disable them, use this command:

sudo serveradmin settings mail:postfix:message_size_limit_enabled = no

Even better, set a new limit (in bytes). The default is 10 MB, and this example sets it to 50 MB:

sudo serveradmin settings mail:postfix:message_size_limit = 52428800

Other Settings

Look through the rest of the settings that are listed when you enter sudo serveradmin settings mail and see if any pique your curiosity—but again, don’t go changing things willy-nilly, or you’ll likely break your mail server. If you’re not certain what a particular setting does, run a Web search on it and see what you can find. Apple has documented many of them in various spots, and other users may have discussed the setting as well.

Configure Mail Clients

Now that you have mail services running in OS X Server, it’s time to set up the client side, which is straightforward. Although the specifics vary a little by app, I’m going to look at setting up the Mail client that comes with OS X. The same types of settings—IMAP and SMTP server names, and authentication credentials—apply to all mail clients, whether in Windows or in iOS.

Wait for DNS to Propagate

If your external DNS settings haven’t yet propagated, in Step 3 below, Mail will report “Account must be manually configured” and you’ll have to click Next to continue. Don’t worry about this; the only downside is that in the subsequent dialogs, you must use your server’s IP address rather than its name.

You may also see additional dialogs for both Incoming and Outgoing Mail Server Info, asking for authentication information. Just go with the defaults and you’ll be fine.

If you later change the server settings to the name of the server, you’ll likely find that the mail needs to download again. Therefore, when possible, it’s best to wait until DNS propagation occurs before doing much with the Mail service. You can also always proceed without using SSL until any issues you’re running into are resolved.

To set up Mail for yourself (the steps will be the same for other users), follow these steps:

In Mail, choose Preferences from the Mail menu, and click Accounts to display the Accounts pane.

Click the plus button at the bottom of the list of accounts on the left, and in the dialog that asks what sort of mail account to add, select Add Other Mail Account and click Continue (Figure 65).

Figure 65: Add a new account in Mail’s Preferences window.

In the Add a Mail Account dialog, enter the name you’d like people to see when receiving mail from you, the email address associated with your account on the server (your username), and your password, and then click Create (Figure 66).

Figure 66: Enter your name, email address, and password.

In the Incoming Mail Server Info dialog, your username and password are already filled in, so you only have to choose between IMAP (the most common choice; see Choosing between IMAP and POP) and POP, enter the mail server name or IP address, and click Next (Figure 67).

Figure 67: Choose between IMAP and POP, and enter the hostname or IP address of your mail server.

Next comes the Outgoing Mail Server Info dialog, where you again enter the hostname or IP address of your mail server, along with your username and password this time (Figure 68).

Figure 68: Enter the hostname or IP address of the server again, for outgoing mail.

Click Create to finish the process and set up the account in Mail.

Choosing between IMAP and POP

When it comes to picking up mail from your server, you have two choices, IMAP and POP. The most common choice today is IMAP, because with IMAP all mail remains on the server, making it possible to access the entire mail store from different computers and devices. (It can also be cached locally, for a backup.)

With the older POP, all messages are downloaded and then removed from the server, which is appropriate only when the user wants to check mail from a single computer. Put simply, IMAP is better if your users ever plan to check mail from an iPhone or iPad or from multiple computers.

Mobile Device Management

From the enterprise angle, a significant feature of OS X Server is mobile device management or MDM—that is, software and services that make it easy for a system administrator to configure numerous devices (iPads, iPhones, and even Macs) with consistent settings and policies. With MDM, an administrator can manage these devices by deploying apps, wiping lost devices, unlocking devices when passcodes are forgotten (yes, it happens), and more.

It may be easy to set up a single iPad as you like, but setting up 25 classroom iPads manually with the same settings might cause insanity. And you don’t even want to contemplate manual configuration of 5,000 iPads for a large business!

Profile Manager is an MDM tool that is built into OS X Server and is designed to simplify the task of managing a fleet of Apple devices in a wide variety of ways. It works with iOS devices running iOS 5 and later and with Macs running OS X 10.7 Lion and later.

What can you do with Profile Manager? Lots, including:

Push apps and Web clips to multiple iOS devices

Set and enforce passcode policies

Configure email settings

Set iOS device restrictions

Remotely unlock, lock, or wipe a missing device

Control login screen options

Set up printers in OS X

Launch certain apps at login

Automatically configure Exchange and Google Apps accounts

Require that Macs sleep when not in use

Note: You can even remove apps that you supplied from devices, which might be handy in a school situation, for instance, where you need to replace the apps on the iPads of outgoing kindergarteners with first-grade apps but put those kindergarten apps on new iPads for the incoming kindergartners.

Before we go further, though, I need to offer a caveat. OS X Server’s Profile Manager is entirely functional, and if you already have a Mac set up as a server, $19.99 for OS X Server is cheap. But Profile Manager is far from the only—or the best, for many environments—MDM tool available. If you’re contemplating buying a Mac and getting started with OS X Server purely for Profile Manager, I recommend you look at third-party MDM solutions like AirWatch, FileWave, and JAMF Casper Suite. (Full disclosure: I am currently employed by JAMF.)

Third-party MDM tools have several advantages over OS X Server’s Profile Manager:

Cost: If you consider the cost of a server Mac, the software-as-a-service solutions can be notably cheaper.

Function: These tools often provide more coherent management consoles that are integrated with other capabilities or that fit into other management consoles, such as those for Microsoft Exchange. These tools can be more stable and can even be clustered for larger environments.

Upgrading: Upgrades to OS X Server, such as the jump from 10.7 Lion to 10.8 Mountain Lion, have sometimes required that iOS devices be re-enrolled in Profile Manager. It’s not the end of the world, but it can be annoying.

The Volume Purchase Program

The Volume Purchase Program, which requires that you set up a special account with Apple, enables you to use an institutional credit card to buy apps from the App Store and books from the iBooks Store (but neither music nor videos from the iTunes Store) in bulk and then distribute them to your users’ devices. For more information and to start enrolling your organization, visit the Volume Purchase Program for Education and Volume Purchase Program for Business pages on Apple’s Web site.

The Device Enrollment Program

As with the Volume Purchase Program, the Device Enrollment Program is outside the scope of this book, but you should still be aware of it.

With this program, very large organizations can buy numerous iOS devices from Apple and associate each device with an organizational Apple ID automatically, making it possible to hand sealed iPad boxes to users and have your MDM solution automatically configure the iPads as they’re activated. The Device Enrollment Program also allows you to force devices to remain enrolled by an MDM solution.

Enable Profile Manager

On the face of it, Profile Manager seems like the most time-consuming and complicated OS X Server service to configure because there are a lot of technical parts moving in the background and configuration of Profile Manager takes place in a Web browser, not in the Server app. But, in fact, you can get Profile Manager up and running quickly provided you understand MDM and meet the prerequisites.

It’s essential that you have push notifications and Open Directory properly configured before starting with Profile Manager, so if you’ve jumped directly to this chapter rather than working your way through Preparation and Installation and Directory Services, swing back and run through those steps.

Once you’ve handled these prerequisites, open the Server app and follow these steps.

Turn on device management:

Click Profile Manager in the sidebar to open the Profile Manager pane at the right (Figure 69).

Figure 69: Profile Manager’s main screen.

In the Profile Manager pane, click the Configure button to the right of the Device Management label to start the Device Management assistant.

Click Next.

On the Organization Information screen, enter your name, administrator email address, and phone number (Figure 70). This information appears in the code signing certificate that protects Profile Manager communications. Since users will see what you enter, don’t be too cheeky. Click Next.

Figure 70: Enter your contact information on the Organization Information screen.

Note: If, despite my admonitions, you haven’t set up push notifications yet, additional screens will walk you through that setup.

On the Configure an SSL Certificate screen, choose an SSL certificate (Figure 71). The easiest approach is to choose the self-signed certificate you created back in Configure Alerts. Click Next.

Figure 71: Choose an SSL certificate to protect the communications between your server and your users’ devices.

Note: If you’ve obtained a trusted SSL certificate, you can use that here instead, but the main advantage is one less confirmation dialog when enrolling devices in Profile Manager.

On the Confirm Settings screen, click the Finish button to complete the Device Management assistant.

Back in the Profile Manager pane, “Enabled” appears next to the Device Management label and the Configure button has disappeared.

Create a default configuration file:

Click the Edit button to the right of Default Configuration Profile.

Give the profile a name, such as Everyone (Figure 72).

Figure 72: Name your default configuration profile and select the checkbox if you run all your services on this server.

If you host any services (Calendar, Contacts, VPN, and so on) on this server, select the “Include configuration for services” checkbox; icons indicating which services are included in the default profile appear to the right of the checkbox. Otherwise, leave the checkbox unselected. You can enable other services later and have them configured for devices at enrollment time.

Click OK.

The name of the profile appears adjacent the Default Configuration Profile label.

Maximize the security of your configuration:

Select the “Sign configuration profiles” checkbox.

In the Code Signing Certificate dialog that appears (Figure 73), choose your SSL certificate from the Certificate pop-up menu.

Figure 73: Choose a code signing certificate; unless you’ve installed a third-party certificate, your existing self-signed certificate is the only choice.

Click OK.

Tip: Security is important here, since enrolled devices can be locked or wiped and you don’t want a troll to mess with your users’ devices.

Now that everything you need is in place, click the ON button to start Profile Manager, and wait for it to start, which could take a minute or so.

Warning! Don’t click anything while waiting for Profile Manager to start! The Web service isn’t fully started until the path to the default Web site is shown (the correct entry, as shown in Figure 74, should be “Available at host.domain.name/profilemanager”) and an Open Profile Manager link is shown at the bottom of the screen. If you touch anything too early, you’ll mess something up, so be patient.

With Profile Manager fully started, the Profile Manager pane has new links that open the user portal (described next) and the Profile Manager Web interface (described a little later in this chapter).

Figure 74: Once Profile Manager is enabled, the Profile Manager pane shows a green circle next to the Status label as well as links to the Profile Manager Web interface and the user portal.

Starting from Scratch

If you run into problems when you’re getting started, never fear, because you can always run the wipeDB.sh script that resets the Profile Manager database:

sudo /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/wipeDB.sh

Any devices you’ve enrolled in Profile Manager will need to be re-enrolled, needless to say, so don’t use the wipeDB.sh script unless you’re certain you want to blow away all your Profile Manager work.

Enroll Devices

Before you start enrolling all your devices in Profile Manager, pick one device that you don’t mind wiping repeatedly as you play with all the available options. If you don’t have a completely sacrificial device, remember that you can make a backup of a production device, wipe it for testing, and then restore your backup once your testing is complete.

Speeding up Enrollment

Because the steps below have you relying on your self-signed SSL certificates, you’ll get two extra warnings during the process. You can avoid those either by purchasing third-party trusted certificates for the server or by installing self-signed certificates on devices prior to enrollment. The extra warnings are the only downside; the encryption and technical security are the same.

If you want to enroll a large number of devices at once, consider using Apple Configurator, a free app from Apple that does much of what Profile Manager does (but via a USB connection to a Mac). In this context, Apple Configurator is perhaps most useful for pushing out Profile Manager’s enrollment profile to many devices so you don’t have to fuss with the Web browser on each device. But, in fact, if you don’t require over-the-air management (via a network), Apple Configurator can stand in entirely for Profile Manager.

Apple Configurator may be free, but it’s complicated enough that I co-authored (with TJ Houston) an entire book about it, Instant Apple Configurator How-to.

Any device that you want to enroll must be able to connect to the Profile Manager user portal Web interface, so if you haven’t already updated the DNS settings for the device so that it can see your server, do that now. For example, to update the DNS on an iOS device, tap Settings > Wi-Fi, edit your Wi-Fi network configuration, and change the DNS entry to point at your server (Figure 75).

Figure 75: If necessary, change the DNS setting for the device so it can see your server on the local network.

Once a device has its DNS set properly, you can enroll it (the steps below are for an iOS device, but you can follow them to enroll a Mac):

Open Safari and load the Profile Manager user portal by visiting host.domain.name/MyDevices. For example, if the name of the server is mavserver.pretendco.lan, visit https://mavserver.pretendco.lan/MyDevices.

Tip: Be careful when typing the URL, since if you get it wrong Safari may prefix the hostname with www. It may be easier to send the URL to the device via email or instant messaging.

Because of your self-signed SSL certificate, a prompt tells you that the server identity can’t be verified; tap Continue (Figure 76, left).

Enter the user’s Open Directory credentials, and then tap Log In (Figure 76, right).

Figure 76: Tap Continue to accept the self-signed certificate (left), and then log in using your administrator credentials (right).

After you log in, you’re presented with the My Devices screen.

Tap the Enroll button to enroll your device; this involves installing a profile, so tap Install (Figure 77).

Figure 77: Tap the Enroll button (left), and if necessary tap Install to accept your self-signed certificate (right).

Because iOS takes security seriously, it presents another warning (Figure 78, left); tap Install in the upper right to acknowledge that you’ve seen it, and if prompted enter the device’s passcode.

Once the profile is installed, tap Done (Figure 78, right).

Figure 78: Tap Install to acknowledge the warning (left), and once the profile is installed tap Done (right).

With the device now enrolled, you can find the profile in Settings > General > Profile (Figure 79).

Figure 79: Find the profile in Settings > General > Profile.

Note: If you’ve enrolled a Mac instead of an iOS device, the profile appears in a new Profiles pane in System Preferences.

Note: You can delete the profile from the Settings app (or System Preferences) unless the device was configured via the Device Enrollment Program, at which point it’s presumably owned by the organization and shouldn’t be controlled by an individual.

After enrollment, there isn’t much that can be done from the user portal, though the user can log in to it at anytime from any device, to lock or wipe the device (including the device logged in to the portal) or clear the passcode.

Why might a user want to do this? Imagine that she has boarded a plane and realized after takeoff that she left her work iPhone in the boarding area. Maybe she’ll get it back and maybe she won’t, but she can use the in-flight Wi-Fi from another passenger’s Windows laptop to visit the Profile Manager user portal to lock or even wipe the iPhone (Figure 80).

Figure 80: From the Profile Manager user portal, the user can lock or wipe the device or clear its passcode.

Of course, the point of mobile device management isn’t what the user can do; it’s about what the system administrator can do, such as configuring devices remotely. And that’s where we turn our attention next.

Manage Devices

Now that a device is enrolled, it’s time to visit the Profile Manager Web interface. Either click Open Profile Manager on the Profile Manager pane in the Server app or access it from any computer on your network in a Web browser by appending profilemanager to your server’s hostname in a URL. (For the host mavserver.pretendco.lan, the URL would be https://mavserver.pretendco.lan/profilemanager.)

At the login page, enter the administrator credentials you use to sign in to the Server app (Figure 81).

Figure 81: Log in to Profile Manager in a Web browser.

When you’re logged in, you see Profile Manager’s Web interface (Figure 82). In the left-hand sidebar, you can switch among managing apps, devices, device groups, users, and user groups and see both currently active tasks and a log of completed tasks. The pane in the middle displays the contents of the item selected in the Library section, and the large right-hand pane lets you manage that item’s settings.

Figure 82: In Profile Manager’s Web interface, to manage an item’s settings, select it in the sidebar and then select an item in the middle pane (in this screenshot, my default configuration profile, Everyone).

Setting up Device Groups

Notice that if you click Groups in the sidebar and then click Everyone (or whatever you named your default configuration profile back in Enable Profile Manager), you can apply settings to all enrolled devices (see Figure 82, above). You can also manage devices individually or in smaller groups.

To create a group, select Device Groups in the sidebar, click the Add Device Group button (or the plus button below the sidebar), name the group, and click the Save button.

Then, to add a device to the group, click the plus button below the right-hand pane, click Add Devices (Figure 83), and, in the dialog that appears, click the Add button for the desired device.

Figure 83: To manage multiple devices at a time, add them to a device group.

Click Save when you’re done.

Regardless of whether you’ve selected a device, device group, user, or user group, you manage settings in essentially the same way. The best way to explore the many available settings is to click Settings in the right-hand pane and then click Edit.

I’ll walk you through the two most common management tasks: forcing a passcode on a device and wiping a device remotely.

Force a Passcode

Users can set up their own passcodes, but you can take matters into your own hands and ensure that an appropriate passcode is in place:

In Profile Manager’s Web interface, click Devices in the sidebar and then, in the middle pane, select a device.

The initial About pane shows information about the device: last check-in time, available capacity, battery life remaining, Do Not Disturb setting, Activation Lock status, installed apps, and more (Figure 84).

Figure 84: Profile Manager’s About pane for a device displays a vast amount of info that could be useful to a system administrator.

Click the Settings button in the right-hand pane, and then click the Edit button next to General to bring up a dialog showing all the possible settings, listed in a sidebar on the left and separated into three groups of settings: both OS X and iOS; just iOS; and just OS X.

Click Passcode, and then click Configure at the right to reveal all the possible passcode settings.

Select Allow Simple Value and set Minimum Passcode Length to 4 (Figure 85). Click OK to commit the changes.

Figure 85: Configure the passcode settings as desired.

Note: With iOS, a 4-character passcode is usually sufficient, since the device will wipe itself long before someone can guess the 4-character passcode. Anything longer becomes a drag to enter every time the user needs to unlock the iPhone, unless the device has Touch ID.

Back in the main settings screen for the device, click Save to save your changes (Figure 86).

Figure 86: Make sure you save your changes!

If the device didn’t previously have a passcode, it will prompt the user to set one a few moments later. If it did previously have a passcode, the passcode can no longer be turned off in Settings > Passcode.

Wipe a Device

The next task I want to showcase is wiping a device, which is something system administrators often want to do when a device is lost or stolen. Follow these steps:

In the sidebar of the Profile Manager Web interface, click Devices.

From the middle pane, select the device you want to wipe.

At the bottom of the right-hand pane, click the gear button; from the pop-up menu that appears, choose Wipe (Figure 87).

Figure 87: From the gear menu, choose Wipe.

In the Wipe dialog that appears, select the device again and click Wipe.

The device is wiped instantly; if you were being a cowboy and trying this on a device that’s not actually lost, now’s the time to restore it from backup.

Web Services

The World Wide Web has untold millions of sites providing information and interactive services to billions of users. There are many ways to create and host a Web site, whether for an individual, family, club, school, or business or as a staging site for another site to be hosted elsewhere. With OS X Server and a few minutes of configuration, you can have your own Web server.

Note: Server’s Websites and Wiki services are not tied together; you can set up a wiki without turning on the Websites service, and you can run a Web site that doesn’t include a wiki.

Although Server’s Websites service relies on the industrial-strength Apache Web server software, setting up Server on your own Mac to serve a Web site raises a few issues that you should consider before diving in:

Uptime: Although 24/7 uptime isn’t quite as important for some Web servers as for a mail server (since users will just get a “site not available” error rather than having their email bounce), it’s still the goal for most Web servers. If 24/7 uptime (or close to it) matters for your Web site, you might prefer to host it elsewhere and rely on OS X Server for just internal services (what’s commonly called an intranet) or testing (also called staging).

Performance: Although OS X Server can undoubtedly handle a low-volume Web site with no trouble, performance problems are likely if you anticipate significant traffic (hundreds of simultaneous users). Areas that could cause slowdowns for users include:

Your connection to the Internet might not have sufficient bandwidth. Remember that some connections have much more downstream bandwidth for incoming requests than upstream bandwidth for returning requested data, such as pages and images.

Your server hardware might not be up to the task. Although Web services don’t generally require a vast amount of CPU power or RAM, or particularly fast storage, all three can impact performance in high-load situations. Dedicating a high-performance machine to the task can help.

Interface: OS X Server doesn’t expose many of Apache’s settings, and for a production Web server accessed by a large number of users you’ll likely want to tweak several hidden settings via Apache’s configuration text files. You can work in both Apache’s configuration files and Server’s graphical interface, but be aware that updates to Server—and sometimes even just settings tweaks to the Websites service in Server—can overwrite configuration changes you’ve made in Apache’s files.

Why TidBITS Moved Away from OS X Server

Back in the days of Mac OS X 10.5 Leopard, my publishers hosted the main TidBITS Web site on an Xserve G4 running Leopard Server. For the most part, it worked well, but a variety of issues eventually forced the move to a virtual private server (initially Rackspace, now Linode). Their problems included:

Performance: Although Leopard Server on the Xserve could handle normal loads, TidBITS articles are sometimes linked by heavily read sites like Slashdot and Daring Fireball. Those links can generate tens of thousands of visits in a day, and the combination of Apache and the available hardware couldn’t keep up. A modern Intel-based Mac would likely fare much better.

Configuration: Any custom configuration of Apache (in its text files) was overwritten—and had to be restored from backup—whenever changes were made in Leopard Server’s graphical interface. This is still true, still annoying, and worth keeping in mind.

Ease of access: To ensure access to a high-bandwidth Internet connection, the Xserve lived at a Seattle colocation facility. That meant that any hands-on maintenance required travel to the facility, which was awkward. When that travel involved a cross-country plane flight, it became even less tenable.

Reliability: Although the Xserve had a pair of hard drives, with one mirroring the other as a live backup, the inevitable drive failures were still tremendously stressful. Worse, and the straw that finally broke the camel’s back, is that even being able to troubleshoot sporadic problems would have required purchasing a second $3,000 Xserve.

The eventual solution was to move to a virtual private server, which looks and works like a standalone Unix server but is actually a virtual machine running on top of a large collection of shared CPU, RAM, and storage resources. The virtual private server eliminates performance problems, since it can access additional hardware resources and bandwidth as necessary. It also eliminates any need for physical access (there is none) and is immune to most reliability problems.

All this is by way of saying that there’s no shame in relying on a Web hosting service or a virtual private server for a high-volume Web server while utilizing OS X Server’s Web services in a less public scenario.

In this chapter, I’ll walk you through setting up a Web server.

Prepare to Run a Web Server

It’s possible to run a Web server—and any associated Web apps—purely for internal network users. If that’s what you intend to do, you don’t need to worry about the list below. However, for your Web server to receive requests from the Internet and respond to them, it must be open to the outside, just as a mail server must be open to the outside Internet to send and receive Internet email. If you’ve already opened OS X Server to the Internet for mail in Prepare to Run a Mail Server, you’re well on your way. Here’s what you need to set up:

Static IP address: Any Internet server needs a static external IP address so that it’s always available. If you worked with your ISP to assign a static IP address to your server for mail services, nothing more needs to be done in this regard. If not, make sure your server has a static IP address.

External DNS: As with the mail server, your fake internal domain (mavserver.pretendco.lan in our example) won’t work for a public Web server since it’s restricted to your LAN. For the purposes of this discussion, we’ll assume that you control pretendco.com as well, and that you have a machine (A) record pointing osx.pretendco.com at your static IP address. You should also set up an alias (CNAME) record that maps www.pretendco.com to osx.pretendco.com.

Port forwarding: Fewer ports are necessary for Web services than for mail services, but you should still open port 80 for standard HTTP communication (used for normal http URLs) and port 443 for SSL-encrypted HTTP communications (used for URLs that start with https).

Tip: If you want your server to be accessible to your users from the outside Internet but slightly hidden from other users, you can have it respond only on different ports, such as 8080 and 4343. Users must specify those custom ports in URLs, such as http://www.pretendco.com:8080/index.html, and your site will enjoy a small amount of security through obscurity.

When it comes to enabling OS X Server’s Web server, it’s important early on to draw a distinction between the default sites (one of them accessible on port 80, and the other, an SSL-encrypted site, accessible on port 443) and custom sites, which offer a few more options.

The key fact about the default sites is that they answer requests that are aimed at any hostname or IP address. So, if your server is called osx.pretendco.com and you point a DNS record at the server for www.pretendco.com, the same site will load for both hostnames. In contrast, custom sites answer requests aimed only at the hostnames for which they’re configured.

The easiest approach by far is to stick with the default sites, but if you need additional flexibility, it’s easy to set up a custom site as well.

Where Are Apache’s Logs?

Figuring out what’s happening on your server requires looking at Apache’s access and error logs. They’re stored in /var/log/apache2 by default, but OS X Server adds a symlink that lets you find them more easily in the Finder, at /Library/Logs/WebServer. In that directory, look for access_log and error_log. Both can be dragged onto the Console app’s icon in the Dock for easy viewing.

Configure the Websites Service

To turn on the default Web sites, click Websites in the Server app’s sidebar and then click the ON button.

If you want to be able to run Web applications written in either the PHP or the Python scripting language, select the appropriate checkbox: Enable PHP Web Applications or Enable Python Web Applications. These settings apply to both the default sites and any custom sites. Don’t select these checkboxes if you aren’t sure you need them; you can always do so later, and it’s good security practice to leave unused services disabled.

Once the Status icon turns green, click the View Server Website link at the bottom of the pane, as shown in Figure 88.

Figure 88: Enable OS X Server’s Web server by clicking the ON button in the Websites pane.

Assuming that the stock OS X Server page (Figure 89) loads in the machine’s default Web browser, you’re ready to use OS X Server as a Web server.

Figure 89: The default sites display this page by default, but you can always replace it later.

The default page is a file located deep within the guts of the Server app’s package file, and you probably won’t want to keep using it. To swap it out, navigate to /Library/Server/Web/Data/Sites/Default/, where you’ll find a bunch of default.html.xx files (where xx indicates the language used). These files are aliases to the files stored within the Server app. You can either leave the aliases in place or throw them out, since you can put your own default page in place by copying an HTML file named default.html to the Default folder (Figure 90). (I talk more about Index Files later in this chapter.)

Figure 90: The files that make up your Web site go in the Default folder.

Useful Web Folders

Several folders in /Library/Server/Web are worth knowing about:

Config/apache2: If you need to make changes to Apache’s configuration beyond what’s possible within Server’s interface, you’ll find the necessary files here. Always back up any manually changed files, since any upgrades to Server will overwrite your changes.

Config/php: If you need to configure Server’s PHP installation, you can open its configuration files from this directory.

Data/Sites: The necessary files for your default site live in the Default directory in Sites, but if you create additional custom sites, their files will be stored in Sites/hostname.

Data/WebApps: If you’ve enabled Python Web apps in Server, copy the necessary files for your Web app to this directory. Additional configuration will also be necessary; refer to the Web app’s documentation or support forums for details.

Configure Web Sites

Server provides a couple of settings that you can adjust for the default sites, but since custom sites have the same settings and more, let’s look at them all together. To get at the site configuration dialog, first open the Websites pane in Server and then do one of the following:

Configure a default site or an existing custom site: In the Websites list, double-click the site. The site configuration dialog appears (Figure 91). When you finish making changes (described ahead), click the Done button.

Create and configure a custom site: Click the plus button to open the site configuration dialog (Figure 91). Once you’ve set up the site in the dialog (explained ahead), click the Create button.

Figure 91: You set up a Web site in the site configuration dialog. (Depending on the nature of the site, your options in this dialog may be slightly different.)

Many settings shown in the figure above require explanation; we’ll go through them all.

Domain Name

The first and most important setting for a custom site is the domain name (really the hostname) that the site will be accessible from. If the site is meant to be accessible from the outside Internet, this hostname must be configured appropriately in your external DNS so external users can find your server.

The default sites lack this option, since they respond to all names that resolve to your server. Or, to be more precise, they respond to all names that are not explicitly assigned to a custom site.

In our example, the internal name of the server is mavserver.pretendco.lan and we’ve defined external names of osx.pretendco.com and www.pretendco.com. Initially, the default site will appear when you enter any of those hostnames in a Web browser. But if you create a custom site that answers to www.pretendco.com, the files within /Library/Server/Web/Data/Sites/www.pretendco.com/ will be used instead.

Tip: The default sites can’t be disabled, so it’s a good idea to redirect their index pages to the primary site. More on Redirects shortly.

IP Address

The IP Address pop-up menu lets you choose which IP address the site listens on. In most cases, leave it set to Any, which means the site will be accessible from every IP address that the server is configured to use.

The default sites lack this option, since they automatically listen to all IP addresses that the server has.

Port

Web sites default to running on port 80 for http URLs and port 443 for SSL-encrypted https URLs. But you can run a Web server on any port you like; just enter the port here. 8080 is a common alternative port, but all that matters is that you map it from the outside to the inside on your router (Port Forwarding looks briefly at doing this on an AirPort base station) and that it not conflict with any other service’s port.

The default sites lack this option, since they’re hard-wired to work on ports 80 and 443.

SSL Certificate

If you want to protect your site’s communications with SSL encryption, you must choose an SSL certificate from this pop-up menu. There are many reasons for running a site with SSL-encrypted communications, but a simple way to think about it is that if your site includes any forms, particularly those that ask for personal information from users, using SSL is a good idea.

Throughout this book, I’ve said that you can generally stick with the self-signed SSL certificate that was created when you enabled push notifications. This is the one place where that’s not true: if you choose your self-signed SSL certificate from the pop-up menu, all communications to and from your Web server will be encrypted, but whenever users connect to your site they’ll be told that your certificate can’t be trusted (Figure 92). Needless to say, in this day and age of sites being exploited, that message will scare off most users, and it is usually a bad idea to tell users to ignore scary security warnings.

Figure 92: If you rely on your self-signed certificate to protect an SSL-encrypted site, users will see this dialog every time they visit.

The solution is to purchase a trusted certificate from a Certificate Authority. Start the process by generating a certificate signing request (CSR) and submitting it to a certificate vendor. In the Server app, click Certificates in the sidebar and then click the plus button to get started with generating the CSR.

Note: There are numerous certificate vendors out there and I don’t have experience with many, so I’m hesitant to recommend one. Check out the SSL Certificate Wizard at SSLShopper to compare certificate providers and prices and to read reviews.

The default site that listens on port 80 doesn’t have an SSL Certificate option, but the default site that listens on port 443 does.

Store Site Files In

By default, the files that make up your Web site are stored in /Library/Server/Web/Data/Sites/, but there’s no requirement that they stay there. There are two main reasons you might want to move them:

The Library folder is located on your boot drive, but it’s often a good idea to separate service data from the operating system, by putting the service data on an external drive. That way, if the machine dies, you can easily move the external drive to a different machine running Server and point that copy of Server at the drive.

Anyone who will be building or maintaining the Web site needs access to the site’s folder, and the easiest way to enable that is to store it in a place that’s shared via file sharing. You can even share it as its own volume, so that anyone working on it can mount it in the Finder and work with files as though they were local.

To change the location, choose Other from the Store Site Files In pop-up menu and select the desired folder.

Tip: To jump quickly to the site’s folder in the Finder, click the arrow that appears next to the Store Site Files In pop-up menu.

Note: If you change the location of service data in the Settings pane for the server as a whole (click the name of the server in the Server category at the top of the sidebar, then click Settings), that will change the default location of the Web site files as well.

Who Can Access

The Who Can Access pop-up menu is set to Anyone by default, which means that anyone can access all the pages on your site without needing to authenticate. If you’re placing sensitive information on your site, you might want to restrict access to particular groups of users (see Work with Groups).

You can either restrict access to the entire site or limit access on a folder-by-folder basis:

Restrict the entire site: Choose a particular group from the Who Can Access pop-up menu. Now, when a user tries to access any page on the site from a browser, he sees an HTTP authentication dialog (Figure 93).

Figure 93: To load a page in a restricted Web site, enter the credentials of a user in the appropriate group.

Limit access to part of the site: Choose Customize from the Who Can Access pop-up menu to bring up the Customize Access dialog showing all the folders at the top level of the site’s folder. For each folder, click the Group pop-up menu and choose the group that may view the content of that folder (Figure 94). Click OK.

Figure 94: Specify which group should be able to view each folder in the Customize Access dialog.

Additional Domains

It’s common to configure a Web site to respond to both the domain name and the full hostname of the machine—pretendco.com and www.pretendco.com in our example. But by default, a custom site responds to only the name specified in the Domain Name field (and the default site responds to everything else).

To specify any additional hostnames that a custom site should respond to, click the Edit button next to Additional Domains, click the plus button in the Additional Domain Names dialog, and enter the desired hostname (Figure 95). As needed, you can click the plus button repeatedly to enter more domain names. Click OK when finished.

Figure 95: Your site will respond to additional hostnames entered here.

Redirects

As you set up your Web site, I’m sure you’ll put lots of thought into naming and organizing its files and folders so that the site has sensible URLs (you will, right?). But over time, things change, and you may end up with multiple Web sites running on one or more Web servers. To keep the URLs from your original site working (which users may have bookmarked, or which may have been crawled by search engine robots), you can create redirects from one site to another. Or, if you want all traffic to and from your site to be encrypted, you might want to redirect your default site on port 80 to the SSL-encrypted site on port 443.

To set up redirects, click the Edit button next to Redirects and then click the plus button to open the configuration dialog (Figure 96).

Figure 96: Configure your redirect with the pop-up menus and fields.

In the configuration dialog, pick an option from the When Users Visit pop-up menu:

A URL matching the following path: Choose this, for instance, to redirect everything in the path /cn to the company’s Chinese-language version of the site at http://china.pretendco.com/. In the field below the pop-up menu, enter a path at the current site.

A URL matching the following regular expression: A regular expression matches patterns of text rather than specific strings. You can get started with regular expressions in redirects in the Apache mod_rewrite module’s documentation. If you’ve chosen this option, then in the field below the pop-up menu, enter a regular expression to match in a requested URL.

With the two options above, choose from the Because pop-up menu, whether the original has moved temporarily (HTTP status code 302) or permanently (HTTP status code 301). The difference matters mostly to search engine robots, which know to stop visiting a URL that is redirected permanently, replacing it with the new URL. With a temporary redirect, search engine robots continue visiting the original URL in the future.

This website: If you choose this option, enter the URL for the destination Web site in the field that appears. If you’re configuring a redirect for Server’s default site running on port 80, then in addition to redirecting to a URL that you enter by hand you can choose the SSL-encrypted default site running on port 443, or any custom site defined in Server.

To save your changes, click OK in the configuration dialog and again in the Redirects dialogs.

Be sure to test your redirect right away to ensure that it’s doing what you expect.

Aliases

Aliases are a little like redirects, but for folders on local volumes. Imagine that you want to make a collection of videos accessible via the Web but you don’t want to bury the Video folder containing them in the hierarchy of your Web site. You might think you can put a normal Finder alias of the Video folder in your site’s folder, but that won’t work (Web browsers will download the Finder alias file, rather than seeing it as a directory).

To solve this problem, click the Edit button next to Aliases, and then click the plus button to add an alias.

As with the redirect configuration dialog (discussed just above), you can choose between “A URL matching the following path” and “A URL matching the following regular expression” in the When Users Visit pop-up menu. Then enter the path or regular expression in the field below the pop-up menu, click the downward-pointing arrow to the right of “Show the contents of,” and select a folder (Figure 97).

Figure 97: Enter the path that you want to resolve and the folder to which the alias should point.

To save your changes, click OK and then click OK again in the Aliases dialog.

Index Files

Whenever a browser requests a URL that ends in a slash, like http://www.pretendco.com/, the Web server actually sends what’s called an index file. This file may be a standard HTML file, or it may be something like a PHP script for a dynamic site—and in fact a site can have multiple files that are considered index files.

By default, all Web sites in Server understand five index files: index.html, index.php, /xcode/, /wiki/, and default.html. (The /xcode/ and /wiki/ entries are for Server’s internal use.)

Although adding or reprioritizing index files isn’t terribly common, it might be useful, for example, if you’re moving a bunch of files over from a site previously running on Windows that used index.htm or home.htm as the index file name.

Click the Edit button adjacent the Index Files label. In the Index Files dialog, you can add files (by clicking the plus button), and you can rearrange them (by dragging them) so that Server uses the most likely ones first.

Advanced Settings

This chapter has already discussed quite a few settings, but Server has more. Click the Edit Advanced Settings button at the bottom of the site configuration dialog to see the Advanced Settings dialog (Figure 98).

Figure 98: Access more settings in the Advanced Settings dialog.

You’re less likely to need these settings, so let’s look at them quickly:

Enable Server Side Includes: A server side include is a directive that, when placed in an HTML file, is replaced on the fly with other content by the server. Server side includes are useful for inserting today’s date, the modified date of a file, the results of a CGI, or even the contents of another HTML file. For instance, a server side include could insert the contents of a footer.html file at the bottom of every page on your site. Select this checkbox to make it possible to use server side includes. For more information on creating them, see Apache’s Introduction to Server Side Includes.

Allow overrides using .htaccess files: In OS X Server in general and the Websites service in particular, authentication to restricted directories is handled via groups defined in Server (read Who Can Access, earlier). In a generic Apache environment, however, access is controlled via a .htaccess file. Select this checkbox to override OS X Server’s access controls with a .htaccess file. Place the file at the top level of the site’s folder.

Be aware that you won’t be able to see the .htaccess file in the Finder, since OS X doesn’t display files that start with a period, but you’ll still be able to see and work with it in Terminal.

Warning! Don’t select this checkbox unless you really need it, since using .htaccess can result in security problems if it’s configured incorrectly, and forcing Apache to consult it on every page load unnecessarily could slightly affect performance.

Allow folder listing: If a directory doesn’t have an index file (see Index Files, earlier), selecting this checkbox causes Server to return a fully linked listing of all the files and folders within the directory. Although it’s a handy way of providing downloadable files via a Web site, don’t select this option unless you intend to use it, and plan to be careful, since letting users see into directories that lack index files is a bit of a security hole.

Allow CGI execution: CGIs, or Common Gateway Interface scripts, are a way of extending the capabilities of a Web server with custom applications. If you want CGIs to work on your server, select this checkbox. For a huge collection of CGIs that you can download to add forums, run surveys and polls, build a shopping cart, and more, check out The Resource Index.

Given the severity of the Shellshock vulnerability that was discovered in September 2014, I don’t recommend allowing CGI execution unless you’re certain that your server is as protected (via patches and other security fixes) as possible (e.g. if you’re using this book with a slightly older version of OS X Server). Since more is being learned about Shellshock as I write this, I won’t link to what would likely be outdated resources; you’ll need to do your own research to determine whether or not your server is vulnerable.

Note: Store CGIs in /Library/WebServer/CGI-Executables, making sure their filenames end in .cgi.

Use custom error page: If you want to get clever, as Scott Adams of Dilbert fame did, you can select this checkbox and specify a custom error page to appear whenever a user tries to access a URL that doesn’t exist on your server (Figure 99). Error pages are also known as 404 pages, after the HTTP status code that’s returned.

Figure 99: When in doubt, drain the Internet.

Make these Web apps available on this Web site: To install additional Web apps on your site, select this checkbox. However, you must also do a significant amount of additional configuration that varies by the app, so refer to any OS X Server-specific installation directions for the app in question.

Wiki Services

A wiki is a Web application that allows various people to add to, modify, and delete from the same content. Wikipedia is the most popular example of a wiki, but wikis can be used for knowledge management, documentation, shared process lists, note taking, and more. Unlike blogs, which tend to use a chronological posting approach, wikis have little implicit structure, allowing users to organize the site in any way they want.

Wikis are tremendously flexible. How you use them is limited only by your imagination. Wikis are easily accessible from any device that can browse the Web, so users can access them from anywhere, at any time.

In an educational setting, because wikis work well even from iOS devices, and since wiki pages include many basic formatting options, a wiki might be the best way for students to collaborate on projects. Plus, because files can be uploaded to a wiki and accessed via WebDAV, I’ve helped a variety of schools set up wiki pages for different classes, enabling students to submit projects for each class and teachers to comment on the work right within the wiki.

In the business world, I’ve seen companies store human resources documents, employee manuals, and more on company-wide wikis, relying on the wiki’s text processing capabilities for quick edits in order to keep documents current. One company I’ve worked with even creates a wiki page for each employee, storing a variety of information about that employee on the page. And plenty of tech firms (including mine) use wikis to track information about the systems they manage.

In essence, a wiki is the world’s simplest database, accessible to anyone, using any device, from anywhere. That’s hard to beat.

Note: You can set up the Wiki service regardless of whether you run a full-fledged Web site using Server’s Websites service. If you enable both, they neither conflict nor integrate with one another.

Configure the Wiki Service

To begin setting up the Wiki service, open the Server app and select Wiki in the sidebar. Because a setting in the Wiki pane involves permissions, we’ll run through the basic configuration before clicking the ON button:

Access permissions: These permissions tie into the users and groups described back in Work with Users and Work with Groups. To make it so that only certain users can create wikis (such as only teachers or system administrators in a school), choose Only Some Users from the Permissions pop-up menu, and in the Wiki Creators dialog click the plus button and type the name of the user or group you want to enable (Figure 100). Since you’ll probably want to be able to create a wiki, be sure to include yourself or a group you’re in! Once everyone is added, click OK.

Figure 100: Enter the name of a user or group that should be allowed to create wikis.

An Edit button appears to the right of the Permissions pop-up menu; click it if you later want to adjust the permissions list.

Note: The access permissions control only who is allowed to create wikis; additional permissions within a wiki control who can do what to individual wiki pages.

WebDAV: Enabled by default, WebDAV makes it possible for iWork users to access documents stored in the wiki. When “Enable WebDAV access to Wiki files” is selected, users can connect to the wiki from within Pages, Numbers, and Keynote and access those apps’ files in the wiki’s document repository.

Note: This option does not provide access to files in shared folders, even if WebDAV is enabled (see File Sharing), but only access to files uploaded specifically to the wiki.

With your access and WebDAV options set, click the ON button at the upper right. A green Status icon in the Wiki pane (Figure 101) indicates that all systems are go.

Figure 101: After you click the ON button to turn on the Wiki service, a green Status icon indicates that it’s ready to go.

That’s all there is to do in Server; the rest of the wiki configuration takes place in a Web browser.

Create a Wiki

Once the Wiki service has started, click the View Wiki link at the bottom of the Wiki pane. Or, if you want to work on another computer, connect to the server in a Web browser, appending wiki to the URL. So, if the hostname of your server is mavserver.pretendco.lan, connect to http://mavserver.pretendco.lan/wiki.

You should now see the portal for the wiki service (Figure 102).

Figure 102: The main wiki page.

Now that you’re on the wiki portal page, you can create a wiki:

In the small toolbar at the upper right, click the lock button, enter your credentials, and click the Log In button (make sure you’ve given yourself permission to create wikis). Then click the Wikis button to see a list of all the wikis you have access to; if you’re just getting started, none will be listed.

From the toolbar, click the plus button; then click New Wiki (Figure 103).

Figure 103: Create a wiki from the toolbar of the Web page.

In the Create a New Wiki dialog, provide a name for your wiki and a brief description of it. Click Continue.

In the Set Permissions dialog (Figure 104), define who can access your wiki.

Figure 104: Add users and groups and set their access privileges in the Set Permissions dialog.

Use the Permissions field to add the name of any user or group on your server, but only if you aren’t already covered by the default built-in groups: All Logged In Users (people with accounts on your server) and All Unauthenticated Users (everyone who lacks an account). To delete a user or a group, hover over the blue lozenge and click the blue X button that appears to the left of the name.

For each user or group, you can choose from four levels of access using the pop-up menu to the right:

Owner: This option appears only for specific users or groups that you add. There can be only one owner, who has full read and write access and is identified as the owner on the wiki page.

Read & write: Choose this option to give the user or group full access to view and edit pages in the wiki.

Read only: This option restricts the associated user or group to viewing pages. It’s useful when you want a particular group to be able to consult the wiki for reference but not make changes.

No access: These users and groups are locked out entirely.

When you’re done, click Continue.

Note: You don’t have to set the permissions perfectly now, since you can edit them later. When in doubt, assign only the minimum level of permissions. Also, except for wiki owners, always try to manage permissions based on groups rather than individual users.

In the Set Appearance dialog, you can upload an icon for your wiki and choose a color scheme. The icon appears in the wiki list and when you open the wiki; so, particularly if you plan to have multiple wikis, choose something that users will be able to associate with the wiki’s purpose or contents. Similarly, it’s handy to set different color schemes when you have multiple wikis, to give users context about where they are. As with permissions, you can adjust the icon and color scheme later. To upload an icon, click the Upload button and locate an appropriate image file.

Tip: The easiest way to find a good icon is to search Google Images for “icon” plus a word or two associated with the wiki. The icon will be scaled to a small size, so stick with simple images.

When you’re done (Figure 105), click Create.

Figure 105: Choose a color scheme and a representative icon.

In the Setup Complete dialog, click Go to Wiki to see your wiki’s Home page (Figure 106).

Figure 106: Your wiki is ready to use.

Planning Your Wiki Ahead of Time

Although wikis don’t require any particular structure, expecting users to create the pages you desire and to link them in a consistent and coherent fashion is a recipe for disappointment. I recommend that you first map out the kinds of pages you want in a standard outline in Microsoft Word, OmniOutliner, or the like. Once you have a content hierarchy that you like, go into your wiki and create pages that users can edit, adding boilerplate and instructions about what you expect.

Customize a Wiki

Now that you’ve created a wiki, you can set more options. If you’re not already looking at the Home page for your new wiki, click the wiki on the All Wikis screen.

Adjust the Wiki’s Settings

Click the gear button, then Wiki Settings. The Wiki Settings dialog contains three panes, which allow you to modify the options you set while creating the wiki and give you additional options:

General: Checkboxes for Calendar (if the Calendar service in Server is enabled) and Blog appear. Select Calendar to embed a shared calendar from Server, and select Blog to create a standard blog page. The Calendar option is probably most helpful if you’re hosting a wiki for unauthenticated users with whom you wouldn’t otherwise share a particular calendar, since a full-fledged calendar app will be more useful for known users.

If you select one of these checkboxes, you’ll find a corresponding top-level link in the wiki’s navigation bar, alongside Home, Activity, Documents, and Tags.

Appearance: Along with the icon and color scheme specified previously, you can upload a custom banner (124 pixels tall) and background image (keep it light colored).

Permissions: In addition to the previously configured users and groups and their associated permissions, the Permissions pane lets you set who should be allowed to make comments (Nobody, Anybody, or Authenticated Users) and if moderation should be available for no comments, all comments, or only anonymous comments.

If you choose Nobody, the feature is turned off entirely. Otherwise, how you configure these permissions depends largely on how public your wiki is: the more open you make it, the more you may want to exert some control over commenting.

Click the Save button after making changes in the Wiki Settings dialog.

Set Up the Wiki’s Notifications

On the right side of the Home page, in the Notifications area, notice that “Include in All Activity” is selected by default, so all changes to the Home page will appear in the Activity page (accessed by clicking Activity in the navigation bar). If you also want to be alerted via email whenever a change is made to the Home page, select “Email me when updated.”

Navigate a Wiki

The colored navigation bar at the top of every wiki page contains several important links (Figure 107).

Figure 107: Use the links in the navigation bar to access different parts of your wiki.

Here’s a quick rundown of what you should know about the pages these links take you to:

Home: It’s a good idea to edit the text on this page to give users an overview of the wiki and to add links to any key pages that are not linked from the navigation bar.

Activity: The Activity page logs all changes made within the wiki, identifying who made the change and sorting them newest first. Since a busy wiki could have many changes, you can click the “Mark all as read” button and then later view just unread changes. To save an important change, click the star button next to it, and then use the Favorites view. Click any item in Activity to jump to the associated page.

Documents: One problem with wikis is losing track of pages, but Server’s wiki lists all pages on the Documents screen. You can sort by title, most recent, or least recent.

Tags: If you want to categorize similar pages, assign a tag to each of them (see Use the Document Info Sidebar, ahead shortly). All tags you create appear in the Tags page, and when you click a tag there, it displays all the pages associated with that tag.

Calendar: Assuming you’ve selected the Calendar checkbox in the General settings pane for the wiki (discussed just above), clicking the Calendar link in the navigation bar opens a graphical calendar.

Blog: If you’ve selected the Blog checkbox in the General settings pane for the wiki (discussed just above), a Blog link appears in the navigation bar. Click it to display a standard chronological listing of posts (see Add a Blog Post).

Create and Edit Wiki Pages

Now that you’ve created and customized your wiki overall, it’s time to work with individual pages. In this topic, you’ll learn how to add and edit a page (just below), Format a Page, Use the Document Info Sidebar, Add a Blog Post, and Delete or Move a Page.

There are two basic ways to create wiki pages: either from the menu that appears when you click the plus button or by creating a new page as a destination for a link. I generally recommend the link destination approach, because then you’re less likely to end up with pages without links leading to them.

Follow these steps, starting on the Home page for now (though they’ll work on any wiki page):

In the gray toolbar at the top of the page, click the pencil button to enter Edit mode. Notice how the toolbar changes to provide editing controls. Less obvious is the fact that you can now type in the white text area in the page.

Click at the bottom of the white text area, and type the name of the page you want to create.

Select the name you typed, click the Link button in the toolbar, and choose New Page from the menu that appears (Figure 108).

Figure 108: Choose New Page from the menu that appears after you click the Link button.

In the New Page dialog, click the Add button.

At the far right of the toolbar, click Save.

A new link and a new page are created, linking the text you selected to a new page. You see the old page, but the previously selected text now has the formatting of a link. Click the link to jump to the new page, which has the same boilerplate instruction text as the home page; feel free to replace that as I’ve done in Figure 109.

Figure 109: Notice that the new page looks basically like the home page and can be edited in the same way.

In fact, what you’ve done here is classic wiki work: you edited a page by adding text that you turned into a link to a new page. In the real world, you’d probably put more work into writing and formatting the text on each page, but the process is the same: click the pencil button in the toolbar, edit the page, and click the Save button to save your changes.

Format a Page

To format a page, navigate to it in the wiki and then click the pencil button in the toolbar. Make sure the text you want to format is selected (or the insertion point is in the relevant paragraph), and then click a button in the editing toolbar (Figure 110). When you finish, click Save (or click Cancel to toss out your changes).

Figure 110: Format your wiki pages with the editing toolbar.

In case a button in the editing toolbar isn’t immediately obvious to you, let’s take a closer look at what they do. From left to right:

Attach: Marked with a paper clip icon, this button allows you to upload a file and attach it to the page. Uploaded graphics appear directly in the page. Other attachments appear on the page as buttons; click the button to download the file.

Table: Click this button to insert a table and add a Table Settings button to the toolbar. Hover over a column or row header and click the triangle that appears in order to add or delete a row or column, or sort the contents by row.

HTML snippet: For formatting beyond what’s possible with the rest of the wiki editing controls, click this button and enter raw HTML.

Paragraph: Click this button to choose a style: paragraph, block quote, monospace, or any of three heading sizes.

Character: For character-level formatting—plain, bold, italic, underline, important, emphasis, and highlight—click the Character button.

Link: Click this button to create a link to a new page (as described earlier in this chapter), search for pages to link to within the wiki, link text to a URL elsewhere on the Web, or unlink text. The bottom of the menu lists recent pages; click one to insert a link to it.

Alignment: Click one of the four alignment buttons for left, center, right, or full justification.

List: Click here to pick a list format: bulleted, numbered, or none.

Indent: The two indent buttons are particularly handy for formatting nested lists.

Use the Document Info Sidebar

For pages that you add, the Document Info sidebar appears on the right (Figure 111).

Figure 111: The Document Info sidebar has controls for adding tags, related pages, comments, and more.

Click the tiny triangles at the left of the Document Info sidebar to reveal special controls:

Tags: Use tags to mark pages that have something in common, like insects, fourth period, or planning. All tags you enter here appear in the Tags page (accessible by clicking Tags in the navigation bar); click a tag on that page to see a linked list of all the pages marked with that tag.

Related: To make it easy for users of the wiki to move from one page to another without creating an explicit link in the text of the page, add the page to the Related section.

Comments: To have a discussion about the contents of the page without having to conduct it within the text of the page, use the Comments section. See Customize a Wiki, earlier, for more on who can leave comments and whether or not they’ll be moderated.

Notifications: Particularly as your wiki grows, being notified of updates and comments via email can be a handy way of staying up to date on what’s happening.

History: The wiki automatically keeps track of all changes and who made them. Even better, it keeps all previous versions; click any entry under History to see that version, and click the Show Changes button that appears at the top of the page to see how that version differs from what’s current.

Tip: You can hide the Document Info sidebar by clicking its close button, and reveal it again by clicking the info button that appears in the wiki page.

Add a Blog Post

If you’ve enabled the wiki’s blog feature, clicking the plus button displays a New Blog Post in “Wiki” command in the menu. Click it to create a new blog post.

Apart from how you create it and where it appears, a blog post is essentially identical to any other wiki page in terms of how you edit it and what you can put on it.

Blog posts are collected in the Blog page (accessible by clicking Blog in the navigation bar). They don’t appear in the Documents page.

Delete or Move a Page

To delete any page on the wiki, navigate to it, click the gear button, and click Delete Page. Be aware that deleting a page will cause links to that page to stop working, which may confuse users. It may be better to edit the page to indicate that its content is obsolete.

Also available in the menu that appears when you click the gear button is a Move to Wiki command, which enables you to move a page to another wiki on the server.

Store and Access Files in a Wiki

So far we’ve created pages that contain text, graphics, links, and attachments. However, there’s another way to store files in a wiki, assuming you selected the “Enable WebDAV access to Wiki files” box in the Wiki pane in Server (see Configure the Wiki Service, earlier).

Files uploaded this way aren’t attached to a particular page, but they still appear in the Activity, Documents, and Tags lists, and they have a Document Info sidebar that enables you to tag them, add related pages, make comments, sign up for email notifications, and see the file’s history (which doesn’t include download activity, unfortunately).

People tend to store files in a wiki for two main purposes:

In class situations, teachers like to use a wiki as a sort of dropbox where students submit homework.

In businesses and other organizations, a wiki can be used to share files; it’s similar to a normal shared folder (see File Sharing) but with the added benefits of tagging, related pages, comments, and notifications.

Upload a File

Uploading a file is easy. Click the plus button and then click Upload File to “Wiki” (Figure 112).

Figure 112: Start uploading files by clicking the wiki’s plus button.

In the Upload File dialog, click Choose File, navigate to the file you want to upload, and click Choose. The filename appears in the File field (Figure 113). Click Upload.

Figure 113: Click Choose File to navigate to the file you want to upload; once the filename appears in the File field, click Upload.

Tip: In all major Web browsers, you can drag a file from the Finder to the Choose File button instead of navigating through the Open dialog.

Once the file uploads, it appears much like a new wiki page, complete with a preview if it’s the sort of file that a Web browser can display usefully (Figure 114). Although you can’t add text to the page containing the file, you can add tags, related pages, and comments in the Document Info sidebar.

Figure 114: Uploaded files are shown much like other wiki pages.

If you uploaded the wrong file or want to upload a new version of a file, click the gear button and then click Replace File. You can also click Delete File there, to remove the file from the wiki (though it is possible to restore the file from links in the Activity screen).

Access Uploaded Wiki Files

There are two main ways to access files that have been uploaded to a wiki: either directly in the wiki or in a WebDAV-enabled program like the iOS versions of Apple’s Pages, Numbers, and Keynote.

Note: You can access only files that were uploaded directly to the wiki in these ways, not files that were attached to wiki pages with the Attach button in the editing toolbar.

Download from the Wiki

The most obvious way to download a file from a wiki is to navigate to the file’s page and then click the download button in the toolbar. The file downloads instantly to the browser’s default Downloads folder, just like any other file you’d download with a Web browser.

Open in iWork

In a WebDAV-enabled app like Pages for iOS, open the document manager, tap the Add Document button, and then tap Copy from WebDAV. In the WebDAV Sign In dialog, enter the hostname of the server, prefixed with http://, along with your user credentials (shown in Figure 115). Tap Sign In when you’re ready.

Figure 115: Enter the wiki’s address and your login credentials.

In the document picker that appears, navigate into Wikis and then into the name of the wiki that holds the files you want. Tap the filename to copy it into Pages (Figure 116).

Figure 116: Tap the name of the file to copy it into Pages.

Once that’s done, you can work with the file as you would any other file in Pages.

Although you can’t save your changes back to the original file on the wiki, back in the document manager you can tap the Share button, tap Send a Copy, and tap the WebDAV icon (Figure 117). Enter the server address and your credentials, if necessary; then choose a format for the file, navigate to the desired wiki, and tap the Send button to save it.

Figure 117: After tapping the Share button and Send a Copy, tap the WebDAV button to send a copy of the file back to the wiki.

You can also upload a new file from Pages to the wiki using the Share button; the file doesn’t have to originate on the wiki.

WebDAV in the Finder?

Although it seems like it should be possible to access files on the wiki via the Finder, which is a WebDAV client, that didn’t work in my testing with current versions (I’ve filed a bug report with Apple). If it did work, you’d choose Go > Connect to Server in the Finder, enter the hostname of your server prefixed with http://, enter your user credentials when prompted, and then work with the files as you would those on any other remote volume.

The problem is that although the wiki’s files show up, they all appear to be 4 bytes large and can’t be successfully copied or opened. Plus, attempting to copy files to the wiki via WebDAV consistently generated inexplicable errors claiming the file was already present.

It’s possible that these bugs will have been fixed by updates by the time you read this; if you want to access your wiki via the Finder or another WebDAV client, it’s worth giving it a try.

Software Updates

Frequent software updates have become a fact of life, thanks to Apple continually rolling out new versions of the software in order to fix bugs and plug security holes. Apple has put a great deal of effort into making it easier for Macs and iOS devices to discover, download, and install various updates, for both individuals and groups.

In this chapter, I’ll focus on groups, since OS X Server contains a pair of services that help you manage these updates for your home, office, or entire organization. In particular, OS X Server aims to give administrators two important capabilities:

Limit bandwidth usage: Software updates keep increasing in size, with major updates to OS X and iOS hitting multiple gigabytes. iOS apps and Mac apps from the Mac App Store are also an issue, given the number that users download and how often they’re updated. All that data adds up, and while you can’t avoid downloading one copy of each item, if you have a few devices in a household, or a number of users in an office or school, there’s no reason to tax your Internet connection by downloading multiple copies of each item simultaneously as users update en masse.

Control update distribution: Although Apple and independent developers always intend for their updates to address bugs, it’s not uncommon for an update to cause its own unanticipated problems. I’ve seen OS X and security updates break printing, prevent certain fonts from displaying, and cause certain apps to crash on startup. In each case, a subsequent update resolved the problems, but if you support numerous users, vetting updates before allowing them to be installed can save you significant headaches.

These ideas—caching software updates to reduce bandwidth usage and giving administrators control over which updates are made available to users—underpin two services in OS X Server: Caching and Software Update. They do roughly similar things but don’t overlap entirely, so you may want to run one, the other, or both, depending on your needs.

Decide Which Update Services to Use

Both the Caching service and the Software Update service are designed to download updates from Apple and provide them to users on your local network. But that’s where the similarities end, so let’s look at each in turn so you can decide which to run.

About the Caching Service

OS X Server’s Caching service is one of the easiest to configure and provides an immediate benefit to any network that hosts Apple devices. The Caching service caches all updates from Apple on your server, and all Macs and iOS devices download from your server rather than directly from Apple. This offers two big benefits: reduced bandwidth and faster updating for users.

The Caching server downloads only a single copy of each update, and each device that needs the update gets it from the server rather than from Apple. So if Apple releases a new version of iOS or an update to the iWork apps for OS X, your Internet connection won’t bog down as each device struggles to download those large updates.

Similarly, because each device gets updates from the server over the fast local network rather than over a much slower Internet connection, users shouldn’t have to wait nearly as long for updates to download.

Other than music and video from the iTunes Store, the Caching service makes a local copy of nearly everything a Mac or iOS device can download from Apple, including:

OS X and iOS updates

Mac apps from the Mac App Store and updates

iOS apps and updates

Books from the iBooks Store

Apps and books from iTunes U

Internet Recovery software

Note: For a full list, see Apple’s support article Content types supported by the Caching service.

Running the Caching service is a no-brainer, since any home, school, or company with more than a couple of Apple devices will benefit, and it takes only moments to set up. The only thing the Caching service doesn’t do is let you choose which updates your users see; for that, turn to the Software Update service.

Note: The Caching services works only when it’s behind a NAT gateway, such as those used by AirPort base stations and most other consumer-level routers. This requirement prevents it from being used on a campus-wide network, for instance.

About the Software Update Service

It’s less clear whether you should run the Software Update service, since it works only with Mac software from Apple (not apps from the Mac App Store) and requires more configuration, in terms of both choosing which updates to release on the server and pointing client devices at the server.

The main reason to run the Software Update service is if you want more control over which Mac updates are made available to users on your network. This likely isn’t important in a home environment and might not be worth the effort in a small office, but once you’re at the enterprise level it’s essential for ensuring that users don’t install an update before you’ve had a chance to vet it.

That said, if you’re serious about centralizing software updates for your organization, you may want to investigate a third-party option. In my experience, the Software Update service has three limitations:

Software Update cannot be configured to serve update packages from other vendors, such as Microsoft and Adobe. If you want to centralize those updates, Software Update won’t help.

You can’t release updates to only a group of Macs, making it hard to maintain a testing group.

Although this isn’t OS X Server’s fault, many Apple updates require the user to enter an administrative password. If you haven’t given your users administrator accounts on their Macs, you’ll need another tool (such as Apple Remote Desktop) for automatic installing.

Many organizations have addressed these issues with third-party solutions, such as the comprehensive Absolute Manage, FileWave, and JAMF’s Casper Suite, all of which are commercial software and offer a wide variety of features. (Full disclosure: I am currently employed by JAMF.) On the open-source side, there’s Reposado, a replacement for Software Update that can run on any Unix-based system and lets you create an unstable/testing/release workflow.

But don’t get me wrong; overall, the Software Update service is easily configured and managed, and works well for deploying updates. It is what it needs to be for many OS X Server administrators.

Differences between Caching and Software Update

To summarize the differences between the Caching and Software Update services:

The Caching service caches updates and most purchases for both Macs and iOS devices. In contrast, the Software Update service caches only Mac updates.

The Caching service requires no client-side configuration; Macs and iOS devices use it automatically if it’s available on the local network. The Software Update service requires that you configure each client Mac to use it manually.

The Software Update service enables administrators to restrict which updates are made available to users. The Caching service offers no such capability.

With the Caching service, laptop Macs will update directly via the Internet if they aren’t on your server’s LAN. However, Macs configured to use the Software Update service won’t update at all if they can’t access your server.

The Caching service downloads updates over time, based on device requests, whereas the Software Update service downloads and caches all available updates when it first starts up.

So which should you use? Everyone should enable the Caching service, but only those who need to approve Mac updates before they’re presented to users need to turn on Software Update.

Note: If you turn on both, Software Update takes precedence over Caching for OS X updates, which makes sense, since administrators wouldn’t want Mac users getting inappropriate updates, and Caching offers no update management controls.

Configure the Caching Service

To get started with the Caching service, open the Server app and click Caching in the sidebar. There are only three settings: where the cached data should live, how large the cache should be, and whether or not to cache content for users on other subnets. Configure them before you click the ON button (Figure 118).

Figure 118: Configure the Caching service by choosing a destination and setting a cache size.

First, decide whether you want the cached data to live on the volume that contains service data for OS X Server (generally the startup drive). If not, click the Edit button to the right of Volume and choose a new volume for the cached content.

Note: If you move the cached data, you’ll see a /Library/Server/Caching/Data directory appear in the new location. The contents of that directory aren’t human-readable, so there’s nothing useful you can do with them.

I recommend choosing a drive with plenty of free space, since your cache size should be at least 100 GB. It’s best to do this before turning the Caching service on, to avoid needing to move gigabytes of data.

Once you’ve chosen the appropriate destination, drag the Cache Size slider to the desired amount of space. Allot at least 100 GB, but since the slider doesn’t allow for much precision, you may not be able to choose the exact size you want. The smaller the cache, the more likely that older updates will be deleted to make room for new ones, forcing the Caching service to download them again when requested. You can always increase the size later, as long as there’s room on the drive.

Note: To reclaim space used by the Caching server temporarily, click the Reset button to the right of the Cache Used statistic. There’s no harm—apart from a little wasted bandwidth—in doing this, since the Caching service will download necessary updates again automatically.

Most people should leave the “Only cache content for local networks” checkbox selected; deselect it only if you have a complex local network with multiple subnets and you want to provide cached content for users on other subnets.

That’s it. Click the ON button to enable the Caching service, and it starts downloading updates and purchases from Apple as they are requested. Each downloaded update then becomes available to other devices on the network.

Nothing needs to be done to alert Macs and iOS devices on the network to the presence of the Caching server; they discover and use it automatically, taking advantage of high-performance Wi-Fi and Ethernet connections and leaving the Internet connection free for what’s important: Netflix!

Note: Because no configuration is necessary for client Macs and iOS devices, when they’re away from your network they’ll get updates directly from Apple.

Configure the Software Update Service

Enabling the Software Update service isn’t significantly more difficult than enabling the Caching service, but it requires a bit more thought, and potentially quite a bit more time.

To begin, open the Server app and select the Software Update service in the sidebar. By default, Software Updates works in Automatic mode, in which it mirrors Apple update servers, making every OS X update Apple publishes available to your users unless you disable it manually. Plus, when updates are no longer supported by Apple, they’re removed automatically, which often isn’t desirable (since you likely want to keep an older update available while you test the new one).

Instead, I assume you want more control over which updates are offered to your users; to get that control, select Manual. Then click the ON button to enable the service and start downloading the list of updates (Figure 119).

Figure 119: Run the Software Update service in manual mode to gain full control over which updates are offered to your users.

Click the Updates button to see them, but don’t expect anything to appear right away. It can take 15–30 minutes to download just the list of updates from Apple, even with a decently fast Internet connection, so go read your email or get a cup of coffee. I’ll wait.

Once the Updates pane has populated with the list of updates from Apple (there are a lot—773 as of this writing!), you need to decide whether you want to store them all locally or not. If so, you’ll select the “Automatically download new updates” checkbox—but read on before you do.

The problem is that Software Update needs a lot of space—assume at least several hundred gigabytes—and you can’t easily control how much space is used. Annoyingly, unlike with the Caching service, you can’t relocate just the Software Update data; it is always kept with the rest of OS X Server’s service data.

Moving Service Data

If you need to store Software Update data somewhere other than on the current service data drive, click the name of your server at the top of the sidebar in Server, click Settings, and click the Edit button next to Service Data. Choose a drive with sufficient free space, and wait for the service data to be moved before continuing.

Now it’s time to work with individual updates (Figure 120). With so many items, it’s essential to remember that you can sort the list by clicking the header of any of the columns: Name, Version, Date, Size, and Status. Click the column header a second time to reverse the sort. Equally useful is the Filter Updates field, which limits the updates listed to those that match an specified search term.

Figure 120: Work with individual updates in the Updates screen.

Each individual update can have one of four statuses:

Available: If “Automatically download new updates” isn’t selected, this status means that the update is available to download but isn’t currently stored locally.

Waiting: While an update is being downloaded, the status changes to Waiting. You’re more likely to see it for large updates.

Enabled: When an update’s status is Enabled, it has been downloaded and is available for users to install.

Disabled: An update with the Disabled status remains local but isn’t available for users to install.

To change the status and control the storage of each update, you have the following options, available from the gear menu at the bottom of the screen and from the pop-up menu to the right of each item:

Download: You can download Available updates manually; they remain disabled after downloading and must be enabled separately.

Download and Enable: This option downloads and enables available updates in one action.

Enable: Updates that have been downloaded and are disabled can be made available to users with this command.

Disable: If you want to prevent users from accessing an update that was previously enabled, choose Disable.

Note: If you chose Automatic mode instead of Manual mode on the Settings screen, Disable is the only option available.

Remove: To reclaim the space used by an update, whether it’s enabled or disabled, choose Remove. Needless to say, removing an enabled update disables it as well.

View Update: To read the release notes for a selected update, choose View Update (or just press Return). The status and gear menu are replicated in the Update Summary view (Figure 121).

Figure 121: Learn more about an individual update by selecting it and pressing Return.

Tip: You can select multiple updates in the list and choose an option from the gear menu to work on them all at once.

Note: There’s one more item in the gear menu: Check for Updates. When you’re working in Manual mode, if a new update doesn’t appear in the list automatically, choose Check for Updates to force a check.

Once you’ve configured all the appropriate updates as desired (which takes time, since there are many to go through), it’s time to configure client Macs.

Point Clients at the Software Update Service

There are two ways to configure client Macs to look to your Software Update server instead of Apple’s, but neither is particularly pretty. If you’re using Profile Manager and distributing profiles to each Mac, the best approach is to add a custom setting to the profile. If that’s not possible, you’ll have to Configure Software Update via the Command Line on each client Mac.

Configure Software Update with a Profile

If you haven’t already, run through the steps in Mobile Device Management, to Enable Profile Manager and Enroll Devices. Then follow the instructions in Manage Devices to edit the settings for the appropriate group, after which you can follow these steps:

Scroll to the bottom of the list of settings and click Custom Settings.

On the Configure Custom Settings screen, click Configure.

In the Preference Domain field, enter com.apple.SoftwareUpdate.

Click Add Item to add a key/value pair.

In the Key field, change New Item to CatalogURL.

Leave the Type pop-up menu set to String.

In the Value field, enter the URL of your server, on port 8080 and with index.sucatalog appended, as in http://mavserver.pretendco.lan:8080/index.sucatalog (Figure 122).

Figure 122: Use a custom setting to point Macs at your Software Update server via Profile Manager.

Note: The 8080 port is essential; Software Update runs on that port.

Click OK, and then click Save to save your changes.

Configure Software Update via the Command Line

This approach is conceptually simpler, but it requires touching each individual Mac. Open Terminal and enter a command like this one, replacing mavserver.pretendco.lan with the hostname of your server:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://mavserver.pretendco.lan:8080/index.sucatalog

To verify that you entered the right information, check your work with this command:

defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

To switch back to using Apple’s default Software Update server again, enter this command:

sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

Check for Updates

Once all this is done, open the App Store app and click Updates to see the updates that you’ve made available for that particular Mac. Remember that only the updates that are necessary for that Mac will appear, so if it was up to date before you set up the Software Update service, you may not see anything until a new update appears.

Backup

The much-lamented Dantz Development, creators of the Retrospect backup application, had a wonderful tagline for their product:

To go forward, you must backup.

Dantz trademarked that phrase in 1992, but it hasn’t lost any of its applicability today, over 2 decades later. The backup world may have changed hugely since then, but backing up remains absolutely essential.

When it comes to OS X Server, there are two aspects of backup that you’ll want to consider: backing up the server itself and running the Time Machine–compatible backup server for your users to back up to over the network. Let’s look at each in turn.

Alternatives to the Time Machine Service

The Time Machine service does a good job on its own, but other developers go significantly further with features such as:

Data deduplication, to back up only a single copy of identical files that exist on multiple machines

Compression, to reduce the amount of space required for backed-up files

Comprehensive management consoles with extensive reporting

More fluid management of backup destinations

Support for additional types of backup destinations, including tape

Access to backed-up files from mobile devices

Cross-platform compatibility for backing up Windows PCs or Linux boxes

As always, you’ll pay—potentially a lot—for these features, but if you need them, they’re worthwhile. Two of the main entrants in this field are Code42 Software’s CrashPlan PROe and Archiware’s P5 Backup.

Back Up the Server

Luckily, when it comes to backing up your server, there’s little that’s different from backing up any other Mac, so I strongly encourage you to read Joe Kissell’s Take Control of Backing Up Your Mac, which is the most comprehensive guide to the subject available. It talks about the need for three types of backups:

Versioned backups: Most Mac users rely on Time Machine, which creates versioned backups—copies of each file as it exists at different points in time. Time Machine works fine with a server.

Bootable duplicate: Create and regularly update a bootable duplicate of your server on an external drive so that you can bring your server back online quickly should its hard drive die.

Offsite copies: It’s essential to have a copy of your data in another location in the event of fire, flood, or theft. Think about using a cloud-based backup service for this, or rotating one of several bootable duplicates offsite on a regular basis.

Take Control of Backing Up Your Mac also points out that you should consider what you’d do if your server Mac itself dies. It’s easy to think that you could just move a hard drive to another Mac, but make sure that other Mac has sufficient CPU and RAM to run your services. I also make a few recommendations in Manage Backups.

Excluding Cached Data from Time Machine Backups

You don’t need to back up files cached by either the Caching service or the Software Update service, since they’re automatically recreated by OS X as necessary. (For details, see Configure the Caching Service and Configure the Software Update Service.) So make sure you add these directories to Time Machine’s exclusion list (click Options in the Time Machine preference pane).

Caching: /Library/Server/Caching/Data, or wherever you set the Caching service to store files

Software Update: /Library/Server/Software Update/Data

Backing up Server Settings with Bender

Sometimes you don’t want to restore an entire machine just to recover from corrupted settings, but OS X Server stores settings in so many locations that it’s infeasible to figure out what to recover.

A free tool called Bender, based on some code I wrote years ago, automates the backup of OS X Server settings, so you can easily restore settings in the event of corruption, or use them when upgrading or migrating to a new system. Every evening at 10 PM, Bender backs up the following files and folders in a directory labeled with the date and time the backup was run:

An Open Directory archive if the server is running as an Open Directory master

A single backup file of all of Server’s settings

A series of individual backup files of each setting in Server, so you can restore or import select settings

A backup of the Postgres database used by Profile Manager and Wiki services.

For instructions on restoring backups created by Bender, see the Bender Web page. And be sure to back up Bender’s backups as well!

Enable Time Machine Backups

Turning on the Time Machine service is easy, but before you do, you should make sure you have sufficient drive space available for backups.

Choose Backup Hardware

How much drive space will you need to allot to backups? Time Machine requires, at a bare minimum, that the destination drive have 1.2 times the space occupied by the data you’re backing up. But since the entire point of Time Machine is to let users go back in time to recover older versions of files, you’ll want to allocate more space for each user. How much more depends on how much space you have to play with and how much data each user creates. If someone mostly does email and Web browsing, with some light word processing and spreadsheet work thrown in, 1.5 times the current data would probably be fine. On the other hand, if a user is working with large graphics or audio files, 2 or 3 times the current data wouldn’t be inappropriate.

And of course, to come up with a total you need to add up the amount needed by all users. If you haven’t done this before, you might be shocked by the space necessary, but rest assured there are plenty of products into which you can slot multiple large hard drives, including those from Drobo, Promise, and Synology.

Of these three vendors, Drobo’s products are the most unusual, relying on the proprietary BeyondRAID technology and offering in-place upgrading of drives and mix-and-match drive sizes. Promise’s Thunderbolt-based RAIDs are extremely fast and have the implicit blessing of Apple, being sold through the Apple online store. Finally, Synology’s NAS (network attached storage) units are also highly regarded. Needless to say, don’t skimp on your storage box or how it connects to your server; USB 2 isn’t acceptable.

Also consider the possibility that you’ll want to swap between a pair of these devices, so you can have one that’s offsite at all times. Imagine what would happen if your office were to burn down or be badly damaged in an earthquake or flood: you’d lose all the original data on user Macs and the onsite backup.

Note: At the moment, 3-terabyte hard drives are the sweet spot in the cost per byte spectrum, but pay attention, because the price of storage always goes down (natural disasters such as the 2011 floods in Thailand notwithstanding).

Configure the Time Machine Service

To enable the Time Machine service, just select Time Machine in Server’s sidebar and click the ON button. You’re then immediately presented with the New Destination screen, which is where you choose a spot to store user backups and you limit the size of each user’s backup to a specified size.

Note: Macs running versions of OS X prior to 10.9 Mavericks won’t honor your backup size setting.

Click the Choose button next to Store Backups In and select the desired destination, usually the top level of a hard drive. Then, if you want, select the Limit Each Backup checkbox and enter a size in gigabytes (Figure 123). Click Create.

Figure 123: Choose a destination for your users’ backups and optionally set a limit on how much data each user can store.

Tip: You can’t select the top level of the boot drive, although you can store backups in a subfolder, such as /Users/Shared.

If you’ve selected the top level of a drive, Server creates a shared folder called Backups, storing it inside another folder called Shared Items. This Backups folder is a true shared folder, since Time Machine relies on the File Sharing service (see File Sharing).

Note: If you haven’t yet turned File Sharing on, the Time Machine service enables it for you.

The Settings screen in the Time Machine service lists your newly created destination, showing at a glance how much space remains available on the drive (Figure 124).

Figure 124: The Settings screen of the Time Machine service lists all your backup destinations.

If you want to change the backup size limit for a backup destination, double-click the destination in the Settings screen and enter a new number.

Although you cannot easily change where a backup destination’s files are stored on a given drive (and thus you can’t move them to a larger drive), you can define additional destinations, which appear to users as separate drives. To make a new destination, click the plus button, choose a location, and set a backup size limit.

Note: You cannot change where a backup destination’s files are stored on disk by editing a destination; the easiest way to change a location is by creating a new destination, resetting the client Macs to point at the new destination, and deleting the old one (by clicking the minus button).

Tip: When you create another destination at the top level of a different hard drive, it’s called “Backups-1” by default (with the underlying folder still called “Backups”). You can change that name, or the name of any backup destination, in the File Sharing service (see Create a New Shared Folder).

Back Up to the Time Machine Service

Configuring Time Machine on client Macs to back up to your new Time Machine service differs only slightly from configuring it to back up to any other drive, as explained in Joe Kissell’s Take Control of Backing Up Your Mac. Follow these basic steps:

Open the Time Machine pane of System Preferences.

Click Select Disk, choose your new backup destination from the list (Figure 125), and click Use Disk. If desired, select the Encrypt Backups checkbox.

Figure 125: On each client Mac, choose your server’s backup destination.

Note: The Time Machine service uses the Bonjour discovery service to make the backup destination visible to client Macs automatically.

Since your backup destination is really a shared folder, you must enter the name and password of a user who has access to the shared folder (Figure 126). Then click Connect.

Figure 126: When prompted, enter appropriate credentials to connect to the shared folder.

Time Machine starts backing up to the backup destination.

Needless to say, initial backups will take a long time as Time Machine copies all of each user’s data, but subsequent backups should be much faster.

Tip: For the best possible performance, make sure client Macs are on Ethernet, not Wi-Fi, for the initial backup and any significant restores.

Tip: If Time Machine on a client Mac complains about not being able to back up because the backup is in use, click File Sharing in Server’s sidebar, click Connected Users, select the user corresponding with the client Mac, and click the Disconnect button. Unfortunately, there’s no way to prevent this from happening generally.

Manage Backups

To keep track of the backup status of your users, and how much drive space their backups are taking up, click the Backups view on Server’s Time Machine pane (Figure 127).

Figure 127: The Backups screen lists all your users.

There isn’t much you can do here, but pay special attention to the Last Backup column. If you have a lot of users, you can sort the list by clicking the Last Backup column header; if someone hasn’t backed up in a few days, it’s worth checking in to see what the problem may be, given that Time Machine runs automatically.

Similarly, sorting by Total Size is useful to identify which users are backing up the most data—information you could then use to adjust backup size limits or plan for new backup drives.

To learn more about a particular backup, double-click it to bring up the Summary screen (Figure 128).

Figure 128: The Summary screen provides additional information about a particular backup.

Finally, if necessary—such as when a user leaves your organization—you can delete unnecessary backups by selecting them in the Backups screen and clicking the minus button. Needless to say, deleted backups can’t be restored, so be careful!

Server Maintenance

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 maintenance tips that are specific to different services throughout the book, but to close, I want to offer some general advice for keeping your server running happily.

Don’t assume that you need to do much here; more than once, I’ve come back years after installing OS X server for a client and found that that the server’s uptime is over 1,000 days (in essence, that Mac wasn’t rebooted for over 3 years!). That’s impressive, if only in that the client didn’t install new versions of OS X or Server itself, suffer a power outage, or just need to move the computer. You shouldn’t expect that level of stability, especially given Apple’s move to annual major releases of its operating systems.

Document All Server Changes in a Wiki

The biggest problem that most long-term servers have is that changes are made willy-nilly with no record of what the settings were before, why the change was made, whether there were any unintended side effects that had to be worked around, and so on.

I strongly recommend that you create a Server Admin wiki and use its blog to document all changes that are made to the server, by you or anyone else. You can also create standalone wiki pages that document how to handle particular situations that may arise more than once. (Or, if you want to keep the change list outside Server to ensure access in case the server dies, consider using Google Docs.)

Additional Resources

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:

Internet resources:

AFP548: The first major site for OS X Server administrators, AFP548 has remained relevant for a decade and shows no sign of slowing down. Originally started as a blog, it now offers podcasts, articles, and discussion forums.

MacEnterprise: The “MacE” list, as I’ve always referred to it, is a great resource for system administrators. You’ll find a lot of smart people who like to help other admins with a wide variety of Apple products.

Krypted: This is my personal Web site, but I post a lot of relevant content for OS X Server.

Apple OS X Server + Enterprise Support: Apple’s main server support site contains helpful articles about OS X Server and other enterprise-related products. Also don’t miss Apple’s OS X Server Advanced Administration site, whose information varies between documenting obvious interfaces and providing useful behind-the-scenes details.

Conferences:

MacTech BootCamp and Conference: MacTech BootCamp conferences are 1-day intensive events in a variety of North American cities with talks aimed at consultants and support personnel. MacTech Conference takes place over several days and has a track aimed at IT professionals. I often speak at MacTech Conference, and Take Control’s Adam and Tonya Engst are frequent attendees; it’s worthwhile for the networking alone.

MacIT: MacIT is another multi-day conference that’s a great central location for finding sessions that focus on OS X-based system administration and servers.

MacSysAdmin: The only major conference for Apple administrators in Europe, MacSysAdmin offers tons of sessions revolving around OS X, OS X Server, and iOS administration. And if you can’t make it to Sweden, the sessions are posted online (in English) for free after the conference every year!

Tasks to Perform As Necessary

Part of being a system administrator is responding to the unexpected. That’s why you turned on alerts in Configure Alerts. 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 Checking the RBLs 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 Configure the Software Update Service), you may get a request to enable that update.

Here are a few tips, then, about what to do in some common situations.

OS X Server Is Updated

Updates to OS X Server should be installed only if you need the fixes or the 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. I recommend a 1- to 2-week cooling-off period before installing any major updates on your server, to either OS X in general or OS X Server specifically.

Note: If your server is accessible from the outside Internet, and particularly if it also contains sensitive information, it’s more important to install updates sooner, since they will likely contain fixes for security vulnerabilities.

When you’re ready to update, first check the sites mentioned above, in Additional Resources, to see if others are reporting problems related to the update. If you don’t see anyone complaining about 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 affected 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 a bootable duplicate with a tool like Carbon Copy Cloner or Super Duper. Once you have a good clone of the server to fall back on, use Software Update to install the update.

Tip: Don’t necessarily believe Server when it says the update will take “a few minutes” to install. When I installed OS X Server 3.2.1, that message appeared for nearly an hour.

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!

Boot Drive Runs Low on Space

The boot volume for a server should fill up only if your service data is also on that volume, which is likely if your server has only a single drive. When this happens there are a few things you can do to free up space, listed here in order of increasing difficulty:

Reduce clutter: We all keep too much junk these days. Delete unneeded data or move some data off the server. The free GrandPerspective is a useful tool for visualizing where the drive’s space is being used.

Move shared folders: This manual process is easy to carry out; see Shared Folder Causes a Drive to Run Low on Space, next.

Reduce caching space: Decrease the amount of space used for software updates in Caching (see Configure the Caching Service) and Software Update (see Configure the Software Update Service).

Move service data: If you move service data to a different drive, that drive should be more than large enough to store all your data, since you’ll want room to grow. The transfer will move settings for a lot of services, so it could cause a good bit of downtime. To initiate the transfer from Server, click the name of your server at the top of the sidebar, click the Settings button, and click the Edit button next to Service Data.

Clone the boot drive: With this recommendation, you clone the drive to a much larger drive. You can buy really large drives these days, or even arrays of drives. Such a drive or array can be used as a boot volume and thus eliminate the need for the previous steps, if you want to stick with a single-volume server environment.

Shared Folder Causes a Drive to Run Low on Space

As I mentioned above, when a shared folder causes a drive to fill up, an easy fix is to move the folder:

Let everyone know that the shared folder will be unavailable for a while.

Take a screenshot of the shared folder’s settings, so that you have a record of what its name is, what the permissions are, and what services have been enabled (Figure 129).

Figure 129: Before moving a shared folder, record its settings with a screenshot.

Either stop the File Sharing service entirely or, if you have other shared folders that should remain available during this folder-moving process, deselect the folder’s selected Share Over checkboxes (for example, in the figure above, you would deselect “Share over SMB” and “Share over AFP”). This step ensures that no files will be changed while you’re moving data.

Create a folder on the new drive with the same name as the soon-to-be old shared folder. (It’s not essential to maintain the same name, but it’s usually a good idea.)

Copy the data from the shared folder to your new folder.

In Server, re-create the shared folder with the same settings that you recorded with a screenshot earlier in these steps.

If you turned off File Sharing earlier, turn it back on.

Once everything is configured, test the new shared folder. In particular, be sure to test any aliases that you or other users of the server may have created to files or folders on the server.

Weekly Tasks

It’s a good idea to check your server every week to make sure it’s running smoothly. But it’s also easy to get busy and forget to do these tasks, so I recommend putting a recurring event on your schedule.

Check Free Space on All Mounted Drives

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 discussed how to address this problem earlier in this chapter, but ideally you’d anticipate the need for more space well before it becomes a problem. You should keep tabs on your drives’ free space, as well as on how quickly it is going away.

In general, a drive should have at least 10 to 15 percent of its overall space free. But this depends on how the drive is used. For example, 10 GB of free space on a drive that’s used to share a small database might be fine; however, if your users are editing video, 10 GB of free space could be consumed before lunch.

Several services can track things like free drive space, such as Watchman Monitoring (which can report on over 100 different issues). But for just drive space, you can check in the Finder by selecting a drive and choosing File > Get Info—though you undoubtedly knew that already. For a faster check of all mounted drives, the Storage screen in the Server app is the easiest approach: click the name of your server in Server’s sidebar, and then click the Storage button (Figure 130).

Figure 130: Check the amount of free space on all mounted drives regularly in Server’s storage screen.

Tip: Track the amount of free space (and the overall capacity, of course) in a spreadsheet so you can get a sense of the rate at which the capacity of your drives is being consumed. Over time this provides a good idea of when you’ll need to upgrade.

Server Alerts When a Drive Runs Out of Space

Although Server posts an alert when a drive is almost out of space, that may be too late to prevent problems (see Configure Alerts). The drive in Figure 131 is a Time Machine drive, so it’s not a problem that it ran out of space; Time Machine takes that as indication to delete older backups.

Figure 131: Server alerts you when a drive fills up.

These alerts appear in the Alerts screen in Server (click Alerts in the sidebar); depending on how you set things up, Server may also alert you via email, push notifications, or both.

Check Stats in Server

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’s Stats screen and Activity Monitor, which is installed in by default in /Applications/Utilities.

Server Stats

It’s a good idea to glance at the Stats screen in Server on a weekly basis; just click Stats in the sidebar. In the Stats pane, you can get a sense of the overall performance of the server from four metrics and over periods of time ranging from 1 hour to 7 days (Figure 132).

Figure 132: Check CPU, memory, and network traffic usage on a regular basis.

The graphed metrics you can see in the Stats pane include:

Processor Usage: If the processor usage spikes to 80–100% occasionally, you have nothing to worry about. But if it’s pegged in that range for lengthy periods, think about spinning up another server and migrating some services to it (or moving to that Mac Pro you’ve been lusting after; see the sidebar When to Add RAM or Buy a New Server). If the server runs hot at night when no one should be using it much, use Activity Monitor to look for runaway processes.

Memory Usage: The first solution to having all available memory used all the time is to add more RAM. Once you’ve maxed out RAM, the only way to relieve pressure is to offload some services to another server.

Network Traffic: Depending on how your network is designed and how your server is set up, there may not be a lot you can do if the network traffic graphs show excessive usage—or, rather, there may not be much you can do reasonably. It’s always possible to replace old cabling and pre-gigabit Ethernet switches, and even add multiple network adapters to a server. But that can be difficult or expensive.

Caching Bytes Served: This screen displays how much data the Caching server transfers, both incoming from the Internet and outgoing to client devices.

Note: The other thing these usage graphs can tell you is if someone is using the server at unexpected times, indicating either a dedicated employee or people present on the premises when they shouldn’t be, possibly using company resources for unauthorized projects.

Activity Monitor

Server’s Stats pane is useful for the historical overview of what has been happening on the server, but it’s not at all helpful for figuring out what’s happening now or what process is causing a certain problem. For that, turn to Activity Monitor.

In Activity Monitor, I mostly look at the CPU and Memory panes; switch by clicking the buttons at the top (Figure 133).

Figure 133: Use Activity Monitor to check memory utilization.

To get a sense of what’s happening, click the %CPU column header (in the CPU pane) or the Memory column header (in the Memory pane) to sort the list of processes by the appropriate column. You may have to click again to display the piggiest processes at the top—those using the most CPU or RAM.

The other panes—Energy, Disk, and Network—can occasionally provide insight into a problem, but they’re less useful than CPU and Memory.

When Should You Run Activity Monitor?

If users complain about things being slow, that’s a hint that you should fire up Activity Monitor on the server and watch what’s happening. Also, if your regular checks of the Stats pane in Server show that there are spikes in processor or memory usage at specific times of day, those would be good times to look in Activity Monitor at what processes are in play. Needless to say, looking at Activity Monitor at night, when server resources are unlikely to be in use, probably won’t tell you much.

Handling a Runaway Process

It’s difficult to make sweeping recommendations about what you should do if you identify a process as the cause of out-of-control processor or memory usage. If it’s related to a service in OS X Server, try shutting the service down and starting it up again. If it’s an app that’s not part of OS X Server, try quitting and relaunching the app, if possible. If all else fails, try restarting the server.

Skim Logs for Key Services

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. So, if you’re having a problem with a particular service, you should always start the problem solving process by looking at any related logs.

It’s also worthwhile to scan logs every so often just 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, the search results 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 when it comes to tracking down a problem, I prefer using Console, another bundled utility with OS X that’s stored in /Applications/Utilities.

In Server you can search a log for a term, but in Console you can view a lot more logs than just those for each service and perform more advanced searching. Console also makes it easier to connect a log entry with other events for other services in the same time frame. That’s key, because many issues are caused by something from another service or a process that’s outside OS X Server.

Each service’s log entries start with a unique name and therefore give you a different pattern to search for. For example, any entries that start with mdworker, a common entry, reflect Spotlight indexing the drive. You can usually disregard any issues there. A more useful example is servermgrd, shown in Figure 134, whose log entries contain information about the global service and then most log entries in Server will be called out by the impacted service (unless they’re a part of servermgrd).

Figure 134: View logs using the Console app.

Over time, you’ll learn which names correspond to which services; if you need help looking items up, check Triviaware’s All Known Processes page. Once you identify log entries of interest, run some Google searches on them to see if you can find an indication of what they mean. And if all else fails, try a venue I mentioned earlier in Additional Resources.

Release Software Updates You’ve Vetted

If you’re running the Software Update service (see Configure the Software Update Service), you may want to release software updates to your users on a regular basis so that they can become accustomed to having updates appear over the weekend, say, or on Wednesday mornings.

Manage Backups

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.

Here’s a general overview of the most important tasks:

Check backup logs to see if any files were skipped.

Rotate offsite backup drives (or replace tapes, or make sure cloud storage hasn’t dried up).

Restore some backed-up data to verify that the backups are working.

Each backup situation will require a checklist that focuses on its specific needs. Consider what’s important to you and make your own checklist to run through each week.

Monthly Tasks

A weekly schedule would be overkill for some tasks, so consider settings aside a few minutes at a regular time each month for tasks that aren’t likely to crop up weekly but still need to be done periodically.

Audit Users

As users leave your organization, you should disable their accounts to prevent them from being used as a security hole. 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 them.

Change Passwords

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 any account that can administer a server routinely. Monthly password changes would be excessive for many environments, but I’d change them at least quarterly.

By the time you’ve finished setting up a server, you may have created a Directory Administrator user, local administrative user, 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.

Annual Tasks

Finally, we come to tasks that come up infrequently. Some may need to be done at least yearly, while others need to occur at a particular time of year, such as renewing certificates before their expiration date.

Renew Push Notification Certificates

The Apple Push Notifications certificate needs to be renewed every 2 years. If you set up alerts (see Configure Alerts), you’ll receive a routine alert indicating as much.

You can easily renew in Server by clicking the name of the server in the sidebar and then clicking the Settings button. Click the Edit button for “Enable Apple push notifications” and then click Renew (Figure 135).

Figure 135: Renewing an Apple Push Notifications certificate is easy in Server.

You’re prompted for the Apple ID credentials associated with the certificate. Enter them and then click OK to complete the process.

Maintain the Server’s Drives

Drive maintenance is like taking Omega-3s to keep your brain in good shape—and just as you can eat too much salmon, you can perform disk maintenance too often. Some people go overboard when it comes to using Disk Utility’s Repair Permissions and Repair Disk options.

Although I generally recommend that you repair permissions or repair the disk only if the server is experiencing a problem that can be traced to permissions or to directory corruption, it’s worth running these checks 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!

Note: Repairing permissions applies only to Apple software; it doesn’t affect third-party software.

Reboot the Server

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 just reboot the server whenever it starts acting a little funky.

Clean the Server

I’ve ended this book with this task because although it might seem strange, it does matter, 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 too!)

Also, take the opportunity to vacuum the area around the server so that 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. This could extend the life of the server, and it shows others in a physical way that you care about the server. A tidy server exterior suggests a carefully configured set of services running on the inside.

About This Book

Thank you for purchasing this Take Control book. We hope you find it both useful and enjoyable to read. We welcome your comments.

Ebook Extras

You can access extras related to this ebook on the Web. Once you’re on the ebook’s Take Control Extras page, you can:

Download any available new version of the ebook for free, or buy a subsequent edition at a discount.

Download various formats, including PDF, EPUB, and Mobipocket. (Learn about reading on mobile devices on our Device Advice page.)

Read postings to the ebook’s blog. These may include new information and tips, as well as links to author interviews. At the top of the blog, you can also see any update plans for the ebook.

If you bought this ebook from the Take Control Web site, it has been automatically added to your account, where you can download it in other formats and access any future updates. However, if you bought this ebook elsewhere, you can add it to your account manually:

If you already have a Take Control account, log in to your account, and then click the “access extras…” link above.

If you don’t have a Take Control account, first make one by following the directions that appear when you click the “access extras…” link above. Then, once you are logged in to your new account, add your ebook by clicking the “access extras…” link a second time.

Note: If you try these directions and find that your device is incompatible with the Take Control Web site, contact us.

About the Author

Charles Edge has written 9 books and over 3,000 blog posts on technology, with a focus on large-scale systems and server management. When he started writing this book, he was the chief technology officer of 318, a national consultancy and managed services provider with a focus on Apple’s platforms. Midway through this project, became a product manager for JAMF Software. When not playing with computers at work, he can probably be found at home tinkering with computers for fun.

Acknowledgments

A special thanks to my little girl for giving up a bit of time with Daddy so he could write yet another book!

Shameless Plug

For ongoing details about technology-related topics (and occasional musings about other things), check out my Krypted Web site.

About the Publisher

TidBITS Publishing Inc., publisher of the Take Control ebook series, was incorporated in 2007 by co-founders Adam and Tonya Engst. Adam and Tonya have been creating Apple-related content since they started the online newsletter TidBITS in 1990. In TidBITS, you can find the latest Apple news, plus read reviews, opinions, and more.

Credits

Publisher: Adam Engst

Editor in Chief: Tonya Engst

Editors: Adam Engst, Tonya Engst

Copy editor: Caroline Rose

Production Assistant: Oliver Habicht

Cover design: Sam Schick of Neversink

Logo design: Geoff Allen of FUN is OK

Take Control of OS X Server was first published as a polished draft on the TidBITS Web site for TidBITS supporting members, with a new chapter going live most weeks during May–September 2014. Thanks to the TidBITS members, including Criss and Chris, whose questions and ideas helped us to shape this ebook!

Tip: TidBITS members can save 30% off on any Take Control ebook and enjoy discounts on many other Mac-related products.

More Take Control Books

This is but one of many Take Control titles! Most of our books focus on the Mac and OS X, but we also publish titles that cover iOS, along with general technology topics.

You can buy Take Control books from the Take Control online catalog as well as from venues such as Amazon and the iBooks Store. But it’s a better user experience and our authors earn more when you buy directly from us. Just saying…

Our ebooks are available in three popular formats: PDF, EPUB, and the Kindle’s Mobipocket. All are DRM-free.

Copyright and Fine Print

Take Control of OS X Server
ISBN: 978-1-61542-435-1
Copyright © 2014, Charles Edge. All rights reserved.

TidBITS Publishing Inc. 50 Hickory Road, Ithaca, NY 14850 USA

Why Take Control? We designed Take Control electronic books to help readers regain a measure of control in an oftentimes out-of-control universe. With Take Control, we also work to streamline the publication process so that information about quickly changing technical topics can be published while it’s still relevant and accurate.

Our books are DRM-free: This ebook doesn’t use digital rights management in any way because DRM makes life harder for everyone. So we ask a favor of our readers. If you want to share your copy of this ebook with a friend, please do so as you would a physical book, meaning that if your friend uses it regularly, he or she should buy a copy. Your support makes it possible for future Take Control ebooks to hit the Internet long before you’d find the same information in a printed book. Plus, if you buy the ebook, you’re entitled to any free updates that become available.

Remember the trees! You have our permission to make a single print copy of this ebook for personal use, if you must. Please reference this page if a print service refuses to print the ebook for copyright reasons.

Caveat lector: Although the author and TidBITS Publishing Inc. have made a reasonable effort to ensure the accuracy of the information herein, they assume no responsibility for errors or omissions. The information in this book is distributed “As Is,” without warranty of any kind. Neither TidBITS Publishing Inc. nor the author shall be liable to any person or entity for any special, indirect, incidental, or consequential damages, including without limitation lost revenues or lost profits, that may result (or that are alleged to result) from the use of these materials. In other words, use this information at your own risk.

It’s just a name: Many of the designations in this ebook used to distinguish products and services are claimed as trademarks or service marks. Any trademarks, service marks, product names, or named features that appear in this title are assumed to be the property of their respective owners. All product names and services are used in an editorial fashion only, with no intention of infringement. No such use, or the use of any trade name, is meant to convey endorsement or other affiliation with this title.

We aren’t Apple: This title is an independent publication and has not been authorized, sponsored, or otherwise approved by Apple Inc. Because of the nature of this title, it uses terms that are registered trademarks or service marks of Apple Inc. If you’re into that sort of thing, you can view a complete list of Apple Inc.’s registered trademarks and service marks.