Setting Up Web Services on OS X Server

Photo of Greg
Photo by jurvetson - http://flic.kr/p/87mryX

With Server.app up and running, DNS configured, and a plan in place for locking down access to the default site when it becomes visible, it’s time to enable web services.

If you’ve been following along with this series of articles, then by this point, Server.app should be alive and well, with only DNS running, and DNS plus reverse DNS should be all set up. The next task will be to switch on the web service, but before doing that, let’s prepare to lock the server down so that no nefarious characters except those of our own choosing will be allowed to interact with the default site the server will immediately create. Why do that? Now that DNS is fully set up, your server is both visible and findable by the outside world; it may well have already been probed a few times by malicious bots or botnets. What we can do, however, is set up a simple .htaccess file or (even better) a web app to at least make it slightly more challenging for anyone intent on banging away at your new hardware.

A separate article (“Password Protecting Directories, Files or Whole Domains via a Web App”) describes how to password protect directories and/or files using .htaccess files or web apps on OS X Server. This allows you to leverage the existing user and group structure of OS X rather than manually managing password files for each separate occasion you want to require authentication, and I would suggest applying the method described in that article to restrict access to the whole of the default site.

Obviously, for the method described there to work, you’ll need to create either a suitable group and add yourself to it, or just use a plain “require” together with your username rather than “require group”. Either way, if you enable the web app version or place the digest authentication code in an .htaccess file and drop it into /Library/Server/Web/Data/Sites/Default/, you’ll be good to go.

If you’ve followed the suggestion from an earlier article about keeping the domain for your server entirely separate from the domains you’ll be hosting on it, you may well want to leave this .htaccess file in place (or keep the web app enabled) forever. If not, and you decide to serve an actual functioning website from the server’s main domain, you’ll of course want to remove it later on, but for now let’s leave it in place.

If you’ve opted for a single web administrator account as suggested earlier (“Basic Configuration and Preparing the Way for Extra Software OS X Server Needs”), you may want first to alter the permissions on the default site like so, replacing “webuseraccount” with the name of your web admin account:

sudo chown -R webuseraccount:staff Default

Alternatively, and especially if you don’t intend to use the default site for anything, you can just leave it as root/wheel.

With your digest authentication in place, we’re nearing the moment of truth. Click on “Websites” to configure the default site, and under “Advanced Options”, you’ll find a checkbox to enable .htaccess.

websites-enable

Tick that box if you’re not using the web app approach, then go ahead and flick the switch to turn the web service on! (I’m assuming you’ll also want to enable PHP for your sites and perhaps Python as well.)

htaccess-enable

Presto! Now you can head over to your server’s new default site, enter your details to authenticate, and confirm that all is well.

No doubt you’ll have noticed that you can actually restrict access to the site directly via Server.app via “Who Can Access”.

enabling-access

Unfortunately, though, the authentication pane which appears in this case gives the full server path to the files you’re attempting to browse, whereas the .htaccess or .conf and web app methods send only whatever you have specified with “AuthName”. Given a choice, the latter is preferable.

If you have enabled PHP and you have existing code for your include path, now would be a great time to add it wherever you previously specified as the include path (see “At Last — Firing Up OS X Server”).

Last but not least, it might be tempting to think that switching off web services in Server.app would be enough to stop Apache, but this is not the case. Therefore, whenever doing something that requires specifically restarting Apache, it’s best to do this from the command line, with the usual:

sudo apachectl graceful

Or:

sudo apachectl restart

On the other hand, if you only want to start and then stop the web service — one of several things which rely on Apache — then the preferred OS X Server commands are:

sudo serveradmin stop web

sudo serveradmin start web

Similarly, you can check the status of the web service like so:

sudo serveradmin fullstatus web

And the full settings:

sudo serveradmin settings web

Speaking of restarting things, I would suggest setting up only the default website initially, and moving on to other things (such as performance adjustments, mail, and so on) before setting up more domains. The reason is that as I mentioned in the previous article about first starting up Server.app, each time a new service is enabled, it may create numerous new entries in the logs which require attention, some of which may need restarts — not just of the service, but of the whole machine — in order to clear. I’m working on the assumption that it’s your websites which are most important to you, and if this is true, then it is far preferable to set up just one default site initially rather than immediately launching into hosting multiple sites, only to discover that troubleshooting this or that problem requires restarting the whole machine, with a consequent impact on your websites’ availability.

On that same note, should you ever need to do so, the following will restore everything in the web service setup back to factory settings:

sudo serveradmin command web:command=restoreFactorySettings

Later articles will cover extras like performance tuning Apache, rotating log files, enabling the wiki service for more than one virtual host, and more.

All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .

This site is provided for informational and entertainment purposes only. It is not intended to provide advice of any kind.