The server admin web panel basically sets up vHosts when you are configuring "Sites". The configuration files are stored in /etc/apache2/sites/. For the tweak inclined if you want to modify these files in any way at all then you can add an include line at any part of the file to include any extra configuration that you want to make (or override). Server Admin likes to overwrite these files a lot but it wont remove any extra configuration files you may have included!
So another little tid bit is that the order matters. I've mentioned this before but it can't be said enough. The entries at the top override the ones lower down in the list. This means that if you add a particularly broad wildcard server alias to any site that you configure near the top of the list then that site will serve the request, not any site below it that may have a more specific hostname match.
This on its own would not be too much of a problem but I've both read around the internet and seen first hand that server admin seems to have a habit of adding * to the server aliases randomly and of its own accord. This means that a particular site answers all queries, effectively blocking off sites lower in the list. <virtual sigh>
Now the wiki services. Whatever your opinion on the wiki services (its only apache underneath so feel free to roll your own) you need to be very, very careful about making sure the boxes in the web services section are either ticked or unticked to your liking. Even if you have a different document root for the site and its serving 100% your own content (not the wiki server) and you accidentally have the calendar box ticked then you are opening up a potential attack vector to your server without realising it. When the calendar box is ticked directives are added to the site configuration generated by server admin that effectively turn apache into a proxy server for the calDAV server, whether thats local or another server on your network!! You can try it out by ticking the calendar box and then navigating to
While great for enabling easy access to calDAV for any devices you may have on the internet it makes me a little uneasy that its so easy to set up proxying to a calendar server on your local network (it can use any calendar server see Settings>Wiki>External Web Services) that you may not be looking at for intrusion attacks. Especially when a site may be responding to the internet that you didn't expect. Also it may bypass the remote access server if you have that configured. This would mean any user could access calendars remotely even if you have set a whitelist in remote access.
So I thought I would post my configuration and maybe you can figure out why I've done what I've done and with the information in this article you can avoid some of the pitfalls with the web service in snow leorpard server.
I have 2 default sites, one for SSL and one for normal web services (port 80) that are very restrictive and only serve a page saying "Default Configuration". Make sure to disable all options, including CGI-Execution, Overrides and Directory Listings (you wouldn't want to completely fail would you). These have * in the alias section. I can then play around with my DNS server to check that my server isn't responding in an insecure way to unexpected domain names.
I then layer my other services up on top and here you can see my SVN Repo site, my main domain website, and my developer portal which uses wiki server. I have calendar services enabled on SSL for my main domain so that I can sync calendars with my iPhone on the go.
Any questions, leave a comment!