Basic Configuration and Preparing the Way for Extra Software OS X Server Needs

If you’ve already run through the earlier suggestions about OS X Server preliminaries — mainly including backup and recovery strategies — then it’s time to move on to some very basic configuration.

Moving On: Basic Setup

Your host or colo provider will probably have already set up or included instructions for networking (DNS details, router or gateway, etc.) as well as basic environmental settings to tweak via System Preferences, such as shutting off Wi-Fi, Bluetooth and the remote control IR receiver. We also want the server never to sleep and never sleep the hard disks; nor do we want the power button to put the computer to sleep. We do want the server to restart automatically in the case of power failure, start up or wake up every day at a certain time (just in case!), and wake for network administrator access. For obvious reasons, we also don’t want automatic login enabled.

There are at least two schools of thought regarding screensaver settings. Generally speaking, it is best never to leave a user logged in via Screen Sharing except when you’re actively using it — and provided that you adhere to this general principal, it is arguably better to leave the screensaver switched off so as to avoid the incremental load which it creates and the hassle of entering a password when the screen is locked. On the other hand, if you do need for some reason to leave a user logged in and unattended for a time, then it may be preferable to set the screensaver to activate after a very short interval and to require a password whenever the screen is locked. Note that in addition to a bit of extra load, this approach brings with it two other disadvantages:

1. if someone does successfully connect to your machine, the locked screen password request will reveal the username of the logged in user, and
2. an aggressive screensaver setting may make it harder for support staff at your colocation provider to help you out with ‘hands on’ interaction with the server, should they need to.

For performance and ease of use when screen sharing, we’ll also want the desktop to be set to a solid colour, and it’s useful to include seconds in your menu bar clock display; the latter will give a visual indicator to let you know if your connection and the machine are still responding. (I.e., if the menu bar clock stops, you’ll know something is wrong.)

Finally, it’s time to create a new admin account to use for normal server maintenance, retiring the original administrator account to be used only in emergencies. Why bother to create a second administrator account? Two reasons:

1. an additional admin account should always be on hand for troubleshooting purposes, and
2. recovery after a total system meltdown will be easier if our main account has nothing valuable associated with it.

With regard to number 2, if you’ve followed along with the earlier suggestions I made about backup and recovery for your new server, you’ll know that we set up an ASR (Apple Software Restore) image almost immediately after connecting to the server for the first time. That image can be used in lieu of a clean install, should we ever need one. But if we do need it, we’ll also need to recover our account and Server.app data using Migration Assistant, and Migration Assistant will balk if we try to recover two different accounts with the same name. It will make things more straightforward at recovery time if we’re not tied to that original administrator account in any way and any important stuff we might have for admin purposes is actually sitting in a second admin account. So fire up the Users & Groups preferences pane and set up a second administrator; while you’re at it, it’s probably a good idea to change the password on the original admin account (but keep a record of it, since that original admin account with its original password is part of your restore image!).

Now, log out of the original administrator account, log in using the new administrator account credentials, and hope you never see the original admin account again! Yes, you’ll need to tweak most of those individual settings again once you’ve logged into the new account, but the duplication of effort right now is worth it just in case you ever do need the original admin account: if you need to go back to the original one, you’re probably trying to fix or recover something, and you won’t want to spend time clicking around in System Preferences to ensure that everything is as it should be.

Now is also a good time to tweak the Finder settings to your liking, although hopefully you won’t need to spend much time at all working in the graphical environment via VNC once the server is set up.

And now that the administrator’s account is set up to your liking, let’s optionally return to the Users & Groups pane for one last task. It can save some time to create a non-admin web overseer account, which we’ll use to handle all the routine uploading, etc. for individual websites we’re going to host on the server. If you’re coming from a cPanel/WHM hosting background, you’ll probably be accustomed to having entirely separate users to handle each individual website — and you can continue doing that just as you always have, if you wish. But if you’re managing several of your own websites, as distinct from setting them up for other people to manage, it can be quite a bit easier to assign all the sites to just one user, who can then tap into each for SFTP or more general SSH purposes. Later on, when we start setting up individual sites using Server.app, we’ll be able to assign ownership to the contents of individual site directories very easily:

If you do choose to go with a single web overseer account, it may also be useful to add that user to the ‘_www’ group using Workgroup Manager. (Note, however, that files saved by the Apache user will, by default, carry permissions 644, so membership in the ‘_www’ group won’t by itself be enough to enable the web overseer to delete them.)

A single web overseer account can also make it easier to share chunks of code between sites. For example, to share a WordPress theme, you might just create a symbolic link to a copy of theme which you’ve stored centrally somewhere, also changing the permission of the resulting symbolic link for superfluous aesthetic reasons:

Three small caveats are worth noting if you do make use of symbolic links to re-use code in this way, two specific to WordPress and one more general. First, note that not all WordPress themes or plugins are amenable to being relocated elsewhere; many load additional files in a way that breaks when relocated outside the main WordPress plugins directory or theme directory.

Second, if you provide WordPress with SSH2 credentials which match those of a web overseer account, and your shared plugin or theme files are owned by that web overseer, then selecting ‘delete’ via the WordPress admin screen for a theme or a plugin which is specifically housed in a directory will delete your shared resources under that directory through the symbolic link. WordPress will delete your resource without any additional warning, and this will clobber any other sites which may use those same resources. If you select a plugin which is a single file, on the other hand, WordPress will merely delete the symbolic link itself. You can at least partly mitigate the potentially disastrous nature of this behaviour by setting permissions of 555 rather than 755 on all directories — including nested directories — which you plan to use with WordPress via symbolic linking. Alternatively, you can assign ownership to a different user just for those plugins or themes which will be symlinked, allowing the web overseer to read them but not delete them.

Finally, when running APC (which I’ll cover shortly), beware that if you load a resource via a symbolic link, then move the resource itself and recreate the link to it, you’ll receive the cached version of the resource when you load it again. This is a problem if the resource itself needs to load another resource using a relative path, because it is itself no longer in the same place.

Preparing for Extra Software We’ll Need

One of the first ‘extras’ in the list of essentials is Apple’s own Workgroup Manager, which enables more fine-grained configuration of users and groups.

We’ll also need a few other bits and pieces of extra software from other sources to help bring full functionality to the Mac Mini server, and one thing we’ll need to help bring those together is the command line tools from Xcode. You can download and install Xcode for free from the App Store. Once it’s up and running, a quick visit to its preferences shows “Command Line Tools” available under “Downloads”:

With this in hand, we’ll be ready to install several other bits and pieces to make working with the server easier; I’ll cover these in separate articles. If your Mac Mini uses a non-Apple SSD, you may also wish to enable TRIM support for the SSD at this point. I’ll cover that in a separate article.

• macOS