At Last — Firing Up OS X Server

Earlier articles in this series covered some useful preliminaries for getting the best out of OS X Server; with those out of the way, at last it’s time to fire it up. Smooth, fast, and hassle-free hosting of multiple virtual hosts on OS X Server is right around the corner.

At last! If you’ve been following along with the earlier dozen or so articles in this series on setting up OS X Server, you’ll already have completed a bunch of precursor steps to help keep your server ticking over happily. You’ll have set up an initial backup and recovery strategy, installed a few extra bits and pieces of software to help the server run smoothly, optionally enabled TRIM support to help any non-Apple SSDs work faster and last longer, and more. Now we’re ready to fire up Server.app itself.

OS X Server, Domain Names, and DNS

Before getting started, you should already have a domain name registered and ready to go for your new server. It’s also a good idea to update your bootable clone immediately before launching Server; that way, if anything at all goes wrong, you can boot from the clone, copy the clone over the startup drive, and start over with Server.app. (See “OS X Server First Things First: Backup and Recovery and Other Preliminaries”.)

On first launch, you’ll be asked to set up your computer name and host name. Be sure to get this right, using the domain name you’ve registered for the purpose; although it’s possible to change it later, it can cause hiccups with existing services, so better to start as you intend to continue. I think it’s a good idea to use a separate domain name for your server that has nothing to do with any of your other sites, keeping the server’s name only for administration purposes. In other words, if you want to serve up sites for the domains examplesite1.com, examplesite2.com, and examplesite3.com, you wouldn’t name your server using any of these domain names; instead, you would call it something like server.sittinginthebackground.com and serve up the other three as virtual hosts. This kind of functional separation will make it much easier later on to move a site, should you need or want to, as well as simplifying many routine maintenance tasks and the implementation of various security measures.

In any case, once you’ve given it a name to work with, Server.app will then run through a longish sequence of getting everything set up for you and (hopefully!) announce that it’s been successful. Right away at this stage, you may want to exclude the server’s entire folder hierarchy from Spotlight; if you do so, you’ll obviously lose the ability to find things inside your server setup with Spotlight, but you also won’t have Spotlight continually indexing every last change on a live website once you’re up and running. Server stores everything in /Library/Server, so if you like, you can drag that folder straight into Spotlight’s “Privacy” list.

Immediately, Server.app will launch DNS services, and you should find entries already populated for your primary zone and reverse zone in your DNS list, showing your IP address and chosen host name. You’ll need to select “Show All Records” to see the full details of what has been included.

You should also find that one or two forwarding servers have been set up, which will match the DNS machines supplied by your colocation provider and specified via the Network pane of System Preferences. Throughout this series of articles, we’ve been working on the assumption that the server is being set up specifically in a colo facility and specifically for the primary purpose of serving websites. If this is the case — and you’re not, for example, managing a set of multiple servers and providing directory services, etc. — then it’s also important at this stage to click on “Edit…” next to “Perform lookups for” and ensure that the server is providing DNS for itself. This will help ensure that the server’s FQDN (fully qualified domain name) is properly resolved by the server.

By now, you’re probably itching to get started with setting up the server, but right now is actually a good time to stop and do two things:

1. submit a support ticket to your colo provider asking that reverse DNS be set up to point your server’s IP to your chosen hostname, and
2. head to your registrar and DNS provider to set up the basic DNS needed to resolve your host by name from the outside world.

The significance of the first above is two-fold:

• accurate reverse DNS is needed for any mail services on your domain to be trusted, and
• accurate reverse DNS can prevent a perpetual stream of headaches with Server.app, with networking in general, and with Apache in particular later on.

And as for setting up DNS back at your registrar, I would also suggest going a step further and setting up DNS via a third-party DNS provider and using that for all the domains you’ll host on the server — or, at least, all of those which you consider particularly important. (Personally I’m a fan of DNS Made Easy, which provides very decent value and fantastic tutorials to guide you through just about anything you’d ever want to do with DNS.) If you’re coming from a WHM/cPanel background, you might wonder: “Why on Earth would I want to do that, when WHM automatically creates appropriate DNS records for every new domain I set up?” Although that “all your eggs in one basket” approach is common on WHM/cPanel, it turns out there are plenty of reasons to move to a third-party DNS provider, including:

• speed
• redundancy
• flexibility, control, and independence

A third-party DNS provider will typically be running a global network, so DNS requests can be served from a fast and relatively local machine, rather than winding their way all the way through to your own server. They’ll also be highly redundant, with multiple fallbacks, so that even if your server goes down, it can still be resolved — which also means that you can, for example, keep providing backup email services via Google Apps or some other provider, ensuring uninterrupted email service regardless of any temporary interruptions at your own server. And finally, the level of flexibility, control, and independence from your registrar that third-party DNS provides can’t really be had any other way unless you are already running a global network of servers yourself (in which case, you won’t be reading this article anyway).

Once DNS is done and dusted, you may want to visit the Mac App Store from your local machine and install OS X Server there, if you haven’t already done so. This will enable you to talk to the server and manage it through the same interface, but without the fun of screen sharing l…a…g. Be sure to “Allow remote administration using Server” first, via the checkbox under Hardware > hostname > Settings.

Tidying Up

During Server.app’s first launch, many different bits and pieces are dropped into place, including, as I mentioned in a separate article about enabling WordPress to use SSH2, a php.ini in /private/etc. (See “Enabling WordPress to Work with SSH2 Upgrades — Without Extravagant Permissions”.) If you’ve installed it but have not yet completed the job of enabling the SSH2 extension there, now’s the time to add:

extension=ssh2.so

In addition, the default server php.ini file doesn’t have an include path; one common option is:

include_path = ".:/usr/lib/php:/usr/local/lib/php"

If you’d like pear includes available, you can also add pear to the include path as mentioned in the SSH2 article.

And if you use any PHP scripts that can send email from your sites — like “tell a friend” scripts, etc. — you may also wish to switch off the automatic addition of a script identifier header in your outgoing emails, which will have been set to ‘On’:

; Add X-PHP-Originating-Script: that will include uid of the script followed by the filename
mail.add_x_header = Off

(Although leaving this setting to ‘On’ is arguably a security risk, at the same time it is indispensable in tracking down abuse of your scripts — so if you ever encounter a problem with unsolicited outbound email from your server, one of the first troubleshooting steps would be to turn this setting back on so you can see where they’re originating.)

The process of enabling other services from here on out is oddly fraught with puzzling errors that need to be stamped out one by one. I’ll mention some of these individually as they arise for other services like mail, but for the moment, I’d suggest two quick checks before going any further with other services. First, if you see an error like the following in your log, you may have a ‘missing’ home folder for user ‘_teamserver’:

You may be able to fix this by by opening Workgroup Manager, selecting “Show System Records” from the “View” menu, and selecting “TeamsServer” from the list; if you select the “Home” tab, you can then click on the “Create Home Now” button if /var/teamsserver is in fact missing.

In my experience, however, even when authenticating as root, Workgroup Manager will fail and simply say “An error occurred”, in which case it’s a job for the command line. Navigate to /var, create the missing directory, and set its ownership and permissions:

Also in the “why on Earth?” department, if you have more than one IP address set up for your server — for example, because you’re planning to host sites with SSL certificates — you may find that when you launch Server.app, it will auto-populate the DHCP service section with multiple copies of the same network ranges, one for each of the IP addresses you’ve assigned to the server. Oddly, even if you do not enable the DHCP service, having multiple copies of the same network ranges in Server.app’s DHCP configuration will yield errors like this in your logs:

To fix this, click on the DHCP service and delete those extra copies of the same network range.

• macOS
• PHP