This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from, and , these chapters are available only to ; see  for details.
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. Plus, 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 when that can prevent later problems.
This chapter covers getting the server up and running. It’s the most important chapter in the book, and one 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.
Don’t panic if you don’t get the installation right on the first try. You can delete the
/Library/Server folder and reboot to start over. In the worst case, if other artifacts are hanging around due to not starting from a clean slate, you can reformat the drive, reinstall OS X, and start over. So tinker until you get everything right, then have people start accessing the server and migrating data to the drives on the server.
Just as you needed to plan your server hardware ahead of time, so too you should 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.
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.
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 you limit changing the state of the network interface by making sure that 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) 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 don’t wish to afford one or can’t get one, there’s an alternative, a dynamic DNS service such as Dyn’s many other dynamic DNS services. 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 IP address any time 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
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 pre-assigned ports (although these can often be customized).
If you’re having trouble visualizing 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 those 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 up port 80. If you are running an Apple File Protocol (AFP) file server, you’d make it available via port 443.
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.
To sum up, if you or any of your users will be accessing your server from outside of your LAN, you’ll need to open ports for that to work. When accessing your server from inside your network there is 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 are different depending on the brand of router or firewall—later on, if you need help, consult the manual that came with your device. ( explains how to handle port mapping on Apple’s newer base stations—including 802.11ac base stations.)
It’s time to install a fresh copy of Mavericks on your server Mac! In this topic, I talk about installation and then walk you through a few important ways to customize Mavericks before you run OS X Server for the first time.
Whether your Mac is already running Mavericks or not, it is important to start with a new clean installation of Mavericks. That’s because you want to give your server a stable foundation—when you centralize assets (files, services, etc.) 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 that computer up, reformat its disk, and install a clean version of Mavericks.
What if you set up the Mac cleanly but have been running it for some time? I recommend that you set it up from scratch again and manually migrate the data into shares 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 Mavericks, 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 Mavericks using the App Store application and work through the default installation process. There’s nothing outside the ordinary to do at this point.
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 (in some cases a reservation for a given IP address is used, but that’s beyond the scope of this chapter).
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:
255.255.255.0), and the IP address of your router as seen in Figure 1.
Once the address is configured, test 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:
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, then 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.
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 less than 16 characters long and contain only letters, numbers, dashes, 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 HostName and the ComputerName, which are frequently the same. In my examples, the LocalHostName is the name of the computer, and the HostName and ComputerName add 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:
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 example, if you set the server’s LocalHostName to
mavserver, and your domain is
pretendco.lan (an intentionally made-up domain that won’t conflict with any real domain), then you could use these names:
To set the names, use
scutil via Terminal on the soon-to-be server. In the steps below, replace the names shown (
mavserver) with the names you want your server to have:
sudo scutil --set HostName mavserver.pretendco.lan
sudo scutil --set ComputerName mavserver.pretendco.lan
sudo scutil --set LocalHostName mavserver
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.
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:
If you’re running the server headless, set Display Sleep to Never, since there’s no point in sleeping a non-existent screen.
Your server will now stay awake and keep its resources available to clients who need them.
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.
Next, from the App Store, click the price button to buy the software, or if you’ve already purchased the software, click the Install button as shown in Figure 3.
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 deep within 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 are prompted to set up your server. Click Continue. Agree to the licensing agreement by clicking Agree, and then authenticate with an administrative password when you are prompted to do so.
Once you authenticate, services are prepared, which means all the right things for a server to be a server are being put where the app needs them. You can watch some of this by looking in the
/Library/Server directory. Be patient, as stopping this 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 them all and come back in a few weeks when you’re done. Actually, you can just close this screen, although Apple’s tutorials are well done and I do recommend you read them when you have time (choose Help > Server Tutorials to access them again). Once you close the Server Tutorials screen, you are in the app and your base server install 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. Below that 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 at the very bottom of the sidebar. Hover the pointer over a section name and a Hide/Show control appears to the right; 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 chapter, later in this book.
Now that the server is installed, there are 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 decide later to use.
First up, click the name of the server in the sidebar and then click the Settings button.
On the Settings pane, you’ll see the following options, which should be configured only if you need them (Figure 6):
Remember when you configured the server’s names? Now that you have 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 be able to continue with other setup jobs; if you want to run DNS to host names for other internal servers on your LAN, you should also be sure to read, in Chapter 5.
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. In the Host Name field, enter the HostName you created in, and in the IP Addresses field, enter the IP address of the server that you set up in  (Figure 7). When you’re done, click the Create button.
That takes care of mapping your server’s host name to its IP address, but there’s one more thing to do in the DNS pane, which is to configure the DNS servers that will handle other requests. 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).
Now that you’ve configured Server’s DNS service, you need to tell OS X on the the server Mac itself to use it 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.
Then click the DNS button, select whatever is entered there, and replace it with the IP address of the server itself (Figure 9). Telling the server to look up IP addresses on itself may seem odd, but Server’s DNS service is doing all the work.
Lastly, you need to check that your server’s IP address and hostname match using the
changeip command in Terminal. Enter:
sudo changeip -checkhostname
changeip command should output something similar to the following:
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 success, you’ll need to work back through , , and all the steps under .
OS X Server can alert administrators with push notifications (e.g. alerts on your iPhone) or email when there are problems with the server. To configure alerts:
Once done, you should receive the desired alerts when appropriate. You can test this by clicking the gear icon at the bottom of the Alerts pane and choosing Send Test Alert.
Now that OS X Server is installed and fully functional, it’s time to install some services. The first service that 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:
Read More: Chapter 12 |  |  |  |  |  |  |  |  |  |  |  |  |  |