This article originally appeared in TidBITS on 2014-06-02 at 8:20 a.m.
The permanent URL for this article is: http://tidbits.com/article/14799
Include images: Off

Take Control of OS X Server, Chapter 3: Preparation and Installation

by Charles Edge

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 Chapter 1: Introducing OS X Server [1], and Chapter 2: Choosing Server Hardware [2], these chapters are available only to TidBITS members [3]; see “Take Control of OS X Server” Streaming in TidBITS [4] for details.


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. Plus, I’ll guide you through the entire process.

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).

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.

Key Assumptions

My instructions below assume you will 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 is 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.

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

Understand Network Basics

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.

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: There are zero-configuration networking options in OS X (aka Bonjour) but don’t assume that they will 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 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 Picking a Static IP Address [5]) 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 Remote Access [6] 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 many other dynamic DNS services.

Note: A number of routers support dynamic DNS. The agent is simple enough to install on a Mac, but if you are going to 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 is a problem and you are 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 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.

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 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. (Take Control of Your 802.11n AirPort Network [8] 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 [9].

Warning! For security reasons, you should open only those ports that are absolutely necessary, and unless you’re running a mail or Web server, consider using a virtual private network (VPN) instead of opening any other ports.

Install and Configure Mavericks

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.

Install OS X 10.9 Mavericks

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.

Note: If you need more help, I recommend Joe Kissell’s Take Control of Upgrading to Mavericks [10], which discusses how to create partitions in Disk Utility and includes a few pages on installing OS X Server.

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 (in some cases a reservation for a given IP address is used, but that’s beyond the scope of this chapter).

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 for you 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 likely taken by your router, the 2nd and 254th are the easiest to remember.
  • 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 is assigned dynamically to normal computers that appear and disappear from the network. If you’re installing the server on a consumer network, this likely 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 likely also your router) to avoid serving up that IP address to client computers. See the manufacturer’s documentation for your router for steps on 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:

  1. Open System Preferences > Network and choose the interface (likely Ethernet) that clients will use to connect to the server.
  2. 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 seen 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

  3. [image link]

    Figure 1: Configure your server’s IP address.

  4. Click Advanced.
  5. Click the DNS button.
  6. 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.)
  7. Click OK, and then click Apply to save the changes to the interface.

Tip: While you are 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.

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 [11], which offers lots of basic instructions.

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:

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, 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.

Set Up Host Names

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:

  • 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 instance, 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 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:

  • LocalHostName: mavserver
  • HostName: mavserver.pretendco.lan
  • ComputerName: mavserver.pretendco.lan

To set the names, use scutil via Terminal on the soon-to-be server. In the steps below, replace the names shown (mavserver.pretendco.lan and mavserver) with the names you want your server to have:

  1. Set the HostName using this command:

    sudo scutil --set HostName mavserver.pretendco.lan

  2. Set the ComputerName:

    sudo scutil --set ComputerName mavserver.pretendco.lan

  3. Finally, set the LocalHostName:

    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.

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:

  1. Open System Preferences > Energy Saver. If you’re using a laptop, it should be running on a power adapter when acting as server, so click the Power Adapter button if available (and if this is true, you’ll see slightly different options).
  2. Move the Computer Sleep slider all the way to the right, to Never (Figure 2). This prevents the server from sleeping 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.
    [image link]

    Figure 2: Configure Energy Saver options.

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

    If you’re running the server headless, set Display Sleep to Never, since there’s no point in sleeping a non-existent screen.

  4. Deselect the checkbox for “Put hard disks to sleep when possible.”
  5. 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 [12].

Note: If you are installing the Server app onto multiple computers, you can copy the app to each rather than downloading it again. The Apple ID used to acquire the Server app will be required each time the app is updated, so make sure to use an organization-owned Apple ID rather than your own if installing for a company.

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.

[image link]

Figure 3: 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 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.

[image link]

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

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.

Configure Global Settings

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.

[image link]

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

On the Settings pane, you’ll see the following options, which should be configured only if you need them (Figure 6):

  • Allow remote login using SSH for: Use this checkbox and pop-up menu to specify if 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 screen of the server.
  • 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.
  • 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 as I’ll explain how to configure Apple push notifications in Configure Alerts [13].
  • Service Data: Edit this option if you will be using external storage, such as a Thunderbolt drive, to house your service data (such as files, software updates, etc.). 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.
[image link]

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

Finish Network Configuration

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 Configure DNS [14], in Chapter 5.

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 to make sure your new server’s host name matches with its IP address. And, this is important, so make sure you have a reverse DNS record set up for it as well. The changeip test below 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. In the Host Name field, enter the HostName you created in Set Up Host Names [15], and in the IP Addresses field, enter the IP address of the server that you set up in Configure the Server’s IP Address [16] (Figure 7). When you’re done, click the Create button.

[image link]

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

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).

[image link]

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

Update OS X’s DNS Setting

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.

[image link]

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

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 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 Configure the Server’s IP Address [17], Set Up Host Names [18], and all the steps under ⁠Finish Network Configuration [19].

Configure Alerts

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:

  1. Click Alerts in the sidebar, and then click the Delivery button.
  2. On 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.
    [image link]

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

  3. Click the Edit button for Push, and if Push notifications are not already enabled, you will run through the Push Notification assistant, which creates a certificate after you enter your Apple ID and password. I’ll talk more about certificates and Push Notifications in Chapter 8, in Prepare for Profile Manager [20].
  4. 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 icon at the bottom of the Alerts pane and choosing Send Test Alert.

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 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:

  • Many other services require Open Directory, including Calendar server.
  • If you ever get a second server, you’ll want to run Open Directory so 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 Chapter 4, Directory Services [21].

Read More: About [22] | Chapter 1 [23] | Chapter 2 [24] | Chapter 3 [25] | Chapter 4 [26] | Chapter 5 [27] | Chapter 6 [28] | Chapter 7 [29] | Chapter 8 [30] | Chapter 9 [31] | Chapter 10 [32] | Chapter 11 [33] | Chapter 12 | Chapter 13 [34] | Chapter 14 [35]

[1]: http://tidbits.com/article/14748
[2]: http://tidbits.com/article/14749
[3]: http://tidbits.com/member_benefits.html
[4]: http://tidbits.com/article/14744
[5]: chap03.xhtml#PickingaStaticIPAddress
[6]: http://dyn.com/remote-access/
[7]: http://www.dmoz.org/Computers/Internet/Protocols/DNS/Service_Providers/Dynamic_DNS/
[8]: http://www.takecontrolbooks.com/airport-n?pt=INTERNAL
[9]: http://support.apple.com/kb/TS1629
[10]: http://www.takecontrolbooks.com/mavericks-upgrading?pt=INTERNAL
[11]: http://www.takecontrolbooks.com/command-line?pt=INTERNAL
[12]: https://itunes.apple.com/us/app/os-x-server/id714547929?mt=12&at=10l5PW
[13]: chap03.xhtml#ConfigureAlerts
[14]: chap05.xhtml#ConfigureDNS
[15]: chap03.xhtml#SetUpHostNames
[16]: chap03.xhtml#ConfiguretheServersIPAddress
[17]: chap03.xhtml#ConfiguretheServersIPAddress
[18]: chap03.xhtml#SetUpHostNames
[19]: chap03.xhtml#FinishNetworkConfiguration
[20]: chap08.xhtml#PrepareforProfileManager
[21]: chap04.xhtml#DirectoryServices
[22]: http://tidbits.com/article/14744
[23]: http://tidbits.com/article/14748
[24]: http://tidbits.com/article/14749
[25]: http://tidbits.com/article/14799
[26]: http://tidbits.com/article/14821
[27]: http://tidbits.com/article/14840
[28]: http://tidbits.com/article/14861
[29]: http://tidbits.com/article/14883
[30]: http://tidbits.com/article/14950
[31]: http://tidbits.com/article/14967
[32]: http://tidbits.com/article/14987
[33]: http://tidbits.com/article/15005
[34]: http://tidbits.com/article/15037
[35]: http://tidbits.com/article/15055