If you don’t belong to the cult of Mac, you might ignore the release of Apple’s new OS X Server 10.5, codenamed Leopard. That would be a shame, particularly for small and midsize enterprises, including those with mixed Apple and Windows clients, or even all-Microsoft shops.

Stop snickering. Apple produces a pretty decent server operating system and server hardware. We chased Leopard around our Real-World lab and came away pleased on most fronts. This new server OS is ready for work. The e-mail platform connects to Active Directory and bundles AV and anti-spam software without pesky client access licenses. A spiffed-up calendar application can serve as a group scheduler. VPN services can host 500 users per Intel Xserve. In a first for Apple, IP failover provides high availability, and TimeMachine enables easily deployed server-based client backup. Leopard Server can even mimic an NT domain controller.

Everyone knows Mac is great for creating multimedia. Leopard maintains that reputation, and also makes it easier to distribute content online, including audio, video and photos.

On the downside, Leopard sometimes keeps things too simple. For instance, the calendar service and Web hosting are easy to set up and configure for one-server shops, but may require serious tweaking to function in more complex environments. When hiccups occur during setup or management, experienced administrators may find the built-in help and product documentation lacking. Apple also stumbles with a RADIUS deployment that’s only checked out for Apple Airport.

Get To Work

Apple says it wants to make Leopard a viable option for SMEs and workgroups in larger organizations. To that end, the Leopard dev team significantly overhauled OS X’s mail server, named Mail (wonder how long it took to think up that one). Leopard improves the client interface and offers ClamAV, SpamAssassin and SSL/TLS to boost security on the server end. Setup and configuration are fairly straightforward when integrated with Apple’s native Open Directory and LDAP, and Apple’s directory services can mimic an NT domain controller via Samba 3 for Windows clients, and/or connect to an existing Windows Active Directory.

OS X’s long-in-the-tooth calendar app, iCal, has graduated from single-user productivity tool to group scheduler and is now CalDAV-, iTIP- and iMIP-compliant. iCal supports robust scheduling options for users, groups and other resources listed and tagged in your corporate directory. Anyone familiar with Google Calendar will feel right at home with iCal. While the Exchange team probably isn’t getting nervous, these upgrades represent a huge leap for Apple in the corporate marketplace and are a solid platform for future development.

Also of note, Mail and iCal Server are free in 10.5, with none of the client-access licenses that Exchange requires. Is anyone outside of Cupertino going to run an enterprise messaging system on iCal and Mail? Probably not. Should a SME look to Leopard as a messaging platform on top of an Apple client base, a mixed Mac/Windows environment or, dare we say it, for a Windows shop? Yes. The price is right, and installation and management are simple.

Apple knows most folks (and IT shops) buy Macs in part for media creation and editing. The iLife suite bundled with every Mac client offers robust photo, video, audio, Web and DVD editing and publishing tools. Leopard has a number of complementary server-side applications to leverage iLife output in the enterprise. Past versions of OS X server bundled Mac-tuned Apache Web servers and other open-source ports for fairly straightforward Web and application hosting. Leopard does a much better job of simplifying the setup and administration of Web services.

And just as iLife simplifies media production on the client end, Leopard’s integrated Web services, Wiki Server, Quicktime Streaming Server, iChat/Jabber server and Podcast Producer simplify distribution of content. Podcast Producer absorbs feeds from client Macs, processes audio and video, and serves content in a variety of formats. This is neat stuff for a number of reasons: It streamlines content creation, centralizes media repositories, and simplifies the user experience. Podcast Producer is Xgrid-enabled, allowing the Leopard server to bring idle networked Macs into a distributed-computing grid to share the processing load. It’s render-farm technology brought to the masses.

We built and tore down a number of Web servers, collaborative wikis, and department file shares. We load tested a quad-core Xeon Xserve with twenty real simultaneous Mac and Windows clients against a “departmental” wiki-share and Mail server and barely impacted CPU utilization. We tied Leopard to an existing Open Directory/OpenLDAP with 500 users. We auth’ed a Leopard server to Kerberos. Everything worked just as expected from a network integration perspective.

Leopard’s initial setup from DVD or network image offers basic choices: Do you want this server to be a basic, workgroup or advanced server? What services do you want to host? Startup helpers load all required services based on your choices at installation, while the streamlined Server Preferences app simplifies management of key services once you’re up and running. Basic and workgroup configurations offer a streamlined server management application that is almost maddeningly simple for experienced administrators—on/off toggles with minimal configuration options.

The look and feel of the user interface mirrors Leopard client, with more animations, a revised dock, and a number of minor tweaks designed to simplify the look and feel of OS X. Overall this works, especially the automatic clean-up tools that organize the desktop and pop-up animations for dock folder contents. We like the evolutionary changes, and we were surprised at how much we grew to enjoy cover-flow browsing of network resources.

Apple offers both a system preloaded with the new OS, or the standalone software. Apple’s current Xserves (the company’s name for its server appliances) are a surprisingly good deal: Two dual-core 64-bit Woodcrest Xeons in a base configuration are bundled with an unlimited client 64-bit server OS for under $3,000. It’s all wrapped in a pretty 1U case to boot. Apple has come a long way from pushing over-priced dual G4 Xserves at educational clients.

If preloading isn’t to your liking, Apple says its new server OS will run on any Intel or PowerPC G5 server or desktop Mac, and on any G4 Mac clocked at 867MHz or faster. A gig of RAM and 20GB of drive space are your other ticket to the party. Based on our experience, stick with dual-G5 or multi-core Intel Macs with 2GB RAM or better. Lower spec machines will run file or basic network services under Leopard, but will cripple the full feature set.

And let’s get one thing clear: Leopard server needs a Mac hardware platform to run; you should not try to run OS X on an extra Dell box. All efforts of the OSX86 project aside, you will end up frustrated and dissatisfied with the results.

The installation DVD contains 32- and 64-bit code for Intel and PowerPC Mac platforms. In fact, every in-place build of Leopard is 32/64 and Intel/PPC. To test Apple’s claims, we built a server on a dual G5 server using an external Firewire drive as our boot partition. We then successfully booted and ran Leopard from the Firewire drive on a six-year-old dual G4 Xserve and a 13″ Macbook (32-bit platforms) and Xeon and G5 Xserves for 64-bit goodness. All platforms had wildly different hardware configurations, yet the OS ran without a single issue on each box, all server functionality intact.

Anyone out there willing to try that with Windows 2003?

Seeing Spots

One major knock against the new OS is that the built-in RADIUS service is vetted to support only Apple Airport base stations, though it is based on the open-source FreeRadius. You may get other APs to connect, but this is a significant gaffe if Apple is really serious about positioning Leopard for more than just Apple shops. Owners of PowerPC-based servers hoping to ramp up their podcasting will also be disappointed. It seems Podcast Producer is not universal; the server app is Intel-only due to Apple’s decision to go with the hardware acceleration in the Quartz-Extreme video chipset offered on all Intel Macs.

And despite the dead-simple installation, not everything was smooth sailing. Though iCal was a breeze to set up when we built a single-server “workgroup” configuration on a dual G5 Xserve with 2GB of RAM, we ran into hurdles elsewhere. For instance, we tried to configure iCal on a quad Xeon box configured as a member server in a Mac OS X 10.4 (Tiger) Open Directory environment. We couldn’t get iCal running without forcing a trusted bind back to our directory master.

We found this solution trolling the Apple support boards. We also found an alternate solution: a command-line edit of /etc/caldavd.plist that we didn’t have time to test in prep for this review. Two points to take away: We needed to go to the command line on a Mac, and our solution came from the user community. Linux users will appreciate the irony.

Finally, we lost access to one of our test platforms when we “demoted” it from a stand-alone directory master to being a member server. We were able to log in via network-based user accounts, but we were unable to administer the box. We ended up paving the installation. Apple rightly pointed out that most users would not be faced with our situation, and that Apple’s response would most likely be to rebuild, which we did.

On the whole, this is a substantial upgrade to Apple’s server offering, and we recommend shops running 10.4 to investigate. We also think non-Apple SMEs should take look, whether as a mail server, for collaboration or to facilitate the creation and distribution of multimedia content. OS X 10.5 Leopard is $499 for 10 clients, and $999 unlimited.

Joe Hernick is a contributing technical editor with InformationWeek and Network Computing. Write to him at jhernick@nwc.com.

Building a website is a complicated process, and testing your finished product on every possible browser can be even more daunting. However, because modern browsers such as Safari, Mozilla, and Internet Explorer 6 are compliant with the World Wide Web Consortium’s (W3C) standards, testing your pages with the W3C Validation Tool is a great way to ensure that your pages work with modern browsers. The W3C Validator provides a line-by-line level of feedback, such as error information with references to the standards, on any URL you submit or HTML file you upload.

But what if your pages are accessible only within your firewall? Or what if your organization is reluctant to have their pages submitted to any external site for validation—even if it’s fully automated? This article describes how you can host the same W3C standards validation service within the confines of your own network and security constraints. You just need to download a number of open-source components that are freely available, and then configure them properly. By following this recipe, you will have an internal validation tool that will not only be accessible to your web developers as needed, but can actually be integrated into your production process. You have the code—you can make it fit your workflow.

Validator Files

First be sure to have the Xcode Tools 1.5 or higher installed.

Besides the Xcode Tools, you need to download the validator and supporting files:
Base Code: http://validator.w3.org/validator.tar.gz
DTD Library: http://validator.w3.org/sgml-lib.tar.gz

Once you download these files, you need to decompress them, move them to the proper location, and set the permissions for the executable file. The above downloaded files will download to your downloads folder, ours was on the Desktop, as shown below. Do this in the Terminal Window. The following is an example of where to move the files to (assuming they were downloaded to your desktop).

Welcome to Darwin!
macosx:~ macosx$ cd Desktop
macosx:~/Desktop macosx$ tar xf validator.tar
macosx:~/Desktop macosx$ tar xf sgml-lib.tar
macosx:~ macosx$ cd /Library/WebServer/Documents
macosx:/Library/WebServer/Documents/ macosx$ mkdir validator/
macosx:/Library/WebServer/Documents/ macosx$ cp -R ~/Desktop/validator-0.7.0/ validator/
macosx:/Library/WebServer/Documents/ macosx$ cd validator/htdocs/
macosx:/Library/WebServer/Documents/validator/htdocs macosx$ cp ../httpd/cgi-bin/check .
macosx:/Library/WebServer/Documents/validator/htdocs macosx$ sudo chmod 755 check

Edit the validator.conf file

Now, edit the validator.conf file (located at /Library/WebServer/Documents/validator/htdocs/config/validator.conf) with your favorite text editor. Do not cut and paste from the example file below, this will create an invalid config file.

1. Change the ‘Maintainer’ email address on line 73 to your email address.
2. Change the ‘Home Page’ URL on line 77 to the correct URL for your installation.
3. Uncomment & change the base path of ‘/usr/local/validator’ to ‘/Library/WebServer/Documents/validator’ on line 24.
4. Change ‘SGML Parser’ from ‘/usr/bin/onsgmls’ to ‘/sw/bin/onsgmls’ on line 37, this is where Fink will install the OpenSP software later in these instructions.
5. Save the file.

Here is what our file looked like when we finished:

#
# Main Configuration File for the W3C Markup Validation Service.
#
# $Id: validator.conf,v 1.24 2005/07/08 08:31:09 ot Exp $
#
# See 'perldoc Config::General' for the syntax, and be aware that the
# 'SplitPolicy' is 'equalsign', ie. keys and values are separated by '\s*=\s*',
# and that 'InterPolateVars' is in effect.
#

#
# Base Path for Markup Validator files.
#
# You MUST set these unless you use the default locations for the files.
# e.g. the config files in "/etc/w3c/" and everything else in
# "/usr/local/validator/".
#
# Make sure all file paths below do NOT end with a slash

<Paths>
  #
  # Base path.  Defaults to the value of the W3C_VALIDATOR_HOME environment
  # variable or /usr/local/validator if the variable does not exist.
  Base = /Library/WebServer/Documents/validator

  #
  # Location of template files
  Templates = $Base/share/templates

  <SGML>
    #
    # The SGML Library Path.
    Library = $Base/htdocs/sgml-lib

    #
    # The SGML Parser to use.  Defaults to /usr/bin/onsgmls.
    Parser = /sw/bin/onsgmls
  </SGML>
</Paths>

#
# This controls whether the debugging options are allowed to be enabled.
Allow Debug = yes

#
# This lets you permanently enable the debugging options. Can be overridden
# with CGI options (unlike "Allow Debug" above).
Enable Debug = no

#
# Whether private RFC1918 addresses are allowed.
Allow Private IPs = no

#
# Whether the (highly experimental!) SOAP support should be enabled.
Enable SOAP = no

#
# Whether the validator will check its own output.
# 0 means it will refuse to check its own output, 1 means it will but it will
# refuse to check the results of it checking itself. Etc.
Max Recursion = 0

#
# Protocols the validator is allowed to use for retrieving documents.
# The default is to allow http and https.
<Protocols>
  Allow = data,http,https
</Protocols>

#
# Email address of the maintainer of this service.
Maintainer = web-dev@lists.apple.com

#
# The "Home Page" for the service.  Make sure this ends with a slash.
Home Page = http://localhost/validator/htdocs/

#
# Base URI for the Element Reference.
Element Ref URI = http://www.htmlhelp.com/reference/html40/

#
# Mapping tables etc...
#

#
# Maps element names to URLs (cf. "Element Ref URI" above).
<Elements>
  Include eref.cfg
</Elements>

#
# Main document Type Registry; contains all information on the types
# of documents we support and how they are processed.
<Types>
  Include types.conf
</Types>

#
# Mapping of charset names to their IANA names and how iconv(3) knows them.
<Charsets>
  Include charset.cfg
</Charsets>

#
# Map MIME Media Type to Parse Mode mapping.
<MIME>
  text/xml              = XML
  image/svg             = XML
  image/svg+xml         = XML
  application/smil      = XML
  application/xml       = XML
  text/html             = TBD
  text/vnd.wap.wml      = XML
  application/xhtml+xml = XML
  application/mathml+xml = XML
</MIME>

#
# Source for the "Tip of The Day" blurbs.
<Tips>
  Include tips.cfg
</Tips>

Once you have edited this file, you need to move it to the proper location. Again, do this in the Terminal Window, as shown below.

Welcome to Darwin!
macosx:~ macosx$  cd /etc
macosx:/etc macosx$ sudo mkdir w3c
macosx:/etc macosx$ cd w3c
macosx:/etc/w3c macosx$ sudo cp /Library/WebServer/Documents/validator/htdocs/config/*.* .

Edit the apache httpd.conf file

Now, edit the apache config file—this example uses the application pico—to tell apache some information about the validator; we again use the Terminal Window for this:

Welcome to Darwin!
macosx:~ macosx$ sudo pico /etc/httpd/httpd.conf

This opens the apache config file into the pico text editor. Scroll to the bottom of the file and add the following lines:

# This is the directory where you have the validator's "check"
# script as well as its and *.html, *.css etc files.

<Directory /Library/WebServer/Documents/validator/htdocs>
  Options              ExecCGI IncludesNOEXEC Indexes MultiViews
  AllowOverride        None
  AddHandler           server-parsed .html
  AddCharset           utf-8         .html
</Directory>

# Tell httpd that "check" is a CGI script.

<Location "/validator/htdocs/check">
  SetHandler           cgi-script
</Location>

Save the file by pressing Control-X and answering ‘Y’ to the prompt.

Now, restart personal web sharing from the Terminal Window:

Welcome to Darwin!
macosx:~ macosx$ sudo apachectl graceful

Install Fink & OpenSP

Install Open SP (this is needed in order for the validator to run). The easiest way to install Open SP is via Fink. Follow the Fink Installation Instructions for Mac OS X if you don’t already have Fink installed.

Once you have completed a full Fink installation and Fink selfupdate, then install OpenSP via Fink, using the Terminal Window:

Welcome to Darwin!
macosx:~ macosx$ Fink install openSP3

Installing the Necessary Perl Modules

The easiest way to install the required Perl modules is via CPAN. The W3C has provided a CPAN bundle that will install all the required Perl modules. If this is the first time you are using CPAN, you must first go through a configuration of CPAN. All the default answers to the prompts should be sufficient—just press the Return key at each prompt.

Open the Terminal Window and run CPAN:

Welcome to Darwin!
macosx:~ macosx$ sudo perl -MCPAN -e shell

After configuring CPAN, you get a cpan> command prompt. Now you are ready to install the bundle via CPAN as shown below. You will need to accept ‘recursively get missing modules’

cpan> install Bundle::W3C::Validator

Success!

Your validator should now be working now at http://localhost/validator/htdocs/ on your local Mac.

If you have any questions or comments, you can post to the Apple Web Development Mailing List.

This article was tested on Mac OS X (10.4). The original panther tested version of this article is located at http://developer.apple.com/internet/opensource/validatorpanther.html

MySQL has become one of the most popular databases for Web applications. The database is well suited for common Web-related tasks like content management, and for implementing Web features like discussion boards and guestbooks. For a time, some developers avoided MySQL for commercial applications because it did not implement certain features, such as transactions. But this is no longer the case, and MySQL is a great choice for just about any Web-based application.

In this article I’ll give you an overview of MySQL’s features and drawbacks, show you how to install MySQL on Mac OS X, and introduce you to some of MySQL’s notable technical aspects.

MySQL Features

Perhaps the most prominent feature of MySQL is its speed when running SQL SELECT statements. MySQL was built for speed. The core of the MySQL engine is very small and streamlined, and the default table type (a modified ISAM table) was designed specifically for running SELECTs quickly. If your application calls for the advantages of a relational structure but the database contents are relatively static — as is often the case with Web content — MySQL’s speed is a great advantage.

MySQL is also undeniably stable. In both your production and serving environments, you can be reasonably confident that MySQL will be up and processing queries as long as power flows to your machine.

Another important benefit is that MySQL is relatively easy to learn. Even if you’re new to relational databases, you can learn MySQL and create very sophisticated Web applications in a short period of time.

The popularity of MySQL is a benefit as well, because if you run into difficulty, you can lean on the active community that supports MySQL. There are many mailing lists dedicated to MySQL, and most questions find quick and thorough answers.

MySQL Drawbacks

If you are an advanced database user, you should be aware of some of MySQL’s limitations. MySQL’s implementation of standard query language is missing support for sub-selects, foreign key constraints (for some table types), stored procedures, and views. If you feel you need these features, you’re probably better off looking into PostgreSQL, FrontBase, or another database.

Lack of support for transactions used to be a drawback of MySQL, but this has been addressed. Now, on Mac OS X, you can use the MySQL InnoDB table type and have access to row-level locking and robust transaction support, as well as foreign key constraints.

Installing MySQL

If you’re running Mac OS X Server, you are in luck — MySQL is already there. Just go to Applications/Server/MySQL Manager to access it. If you are running Mac OS X Client, you’ll have to install MySQL. if you have already installed a version of MySQl and want to upgrade, I can recommend the upgrade instructions from http://www.entropy.ch. For a new installation, follow the Mac OS X installation instructions for the MySQL provided binary distribution ( a true Mac OS X installer package file) at http://dev.mysql.com/doc/refman/5.0/en/mac-os-x-installation.html and be done with it. However, sometimes you want to compile and install directly from the source, either because you are changing the default build settings, or you want the latest and greatest version before there’s a binary installer. The following will help you through that process.

When installing MySQL, you need to be aware of the potential effect this will have on the security of your system, as a database server can open an avenue of attack. In the example below, I show how to install MySQL on Mac OS X while maintaining the security of your system.

One basic security tenet is that of “least privilege.” In short, this means that everyone and everything should have only the privileges required for it to complete its task(s). Those privileges should be available for the least amount of time possible—ideally, once the task is completed, the privileges should be revoked.

I’m also choosing to build MySQL from source, rather than install a pre-built binary. This gives greater control over the installation, as you’ll see below.

Configuring and Compiling MySQL

I plan to install mysql in /usr/local/mysql. I also plan to locate the mysql UNIX socket under the /usr/local/mysql/ directory as /usr/local/mysql/run/mysql_socket so that it will be publicly available, but associated with the MySQL installation. Note that in a standard installation, the socket file would be placed in /tmp.

You can now download the source via a Web browser.

Once you have the source, you can pretty much follow the quick install directions from the mysql documentation pages, adding only debug support ( — with-debug) and the build environment comment ( — with-comment). The configure command should look like:

./configure --prefix=/usr/local/mysql
--with-unix-socket-path=/usr/local/mysql/run/mysql_socket
--with-mysqld-user=mysql --with-comment --with-debug

Once the configuration completes, running make, and then sudo make install, installs mysql in /usr/local/mysql. Running sudo /usr/local/mysql/bin/mysql_install_db --force adds the var/ space for databases and creates the default databases (mysql and test). You also need to add the run/ directory where the mysql UNIX socket will live, with sudo mkdir /usr/local/mysql/run. Once all of that is done, a directory listing should look like:

% ls -Fla /usr/local/mysql/
total 26
drwxr-xr-x 13 root wheel 1024 Jun 5 13:42 ./
drwxr-xr-x 11 root wheel 1024 Jun 5 12:19 ../
drwxr-xr-x  2 root wheel 1024 Jun 5 12:20 bin/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:19 include/
drwxr-xr-x  2 root wheel 1024 Jun 5 12:19 info/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:19 lib/
drwxr-xr-x  2 root wheel 1024 Jun 5 12:20 libexec/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:20 man/
drwxr-xr-x  6 root wheel 1024 Jun 5 12:21 mysql-test/
drwxr-xr-x  2 root wheel 1024 Jun 5 13:42 run/
drwxr-xr-x  3 root wheel 1024 Jun 5 12:20 share/
drwxr-xr-x  7 root wheel 1024 Jun 5 12:21 sql-bench/
drwx------  4 root wheel 1024 Jun 5 13:37 var/

Note that at this point everything is owned by root — meaning the mysql account won’t be able to write to the databases under var/ nor be able to create the mysql UNIX socket in the run/ directory. Since we want to run the MySQL database under the mysql account, and not under the root account, we need to change the group association of /usr/local/mysql to the group mysql, and the ownership of /usr/local/mysql/run and /usr/local/mysql/var to the mysql account, as follows:

sudo chgrp -R mysql /usr/local/mysql
sudo chown -R mysql /usr/local/mysql/run /usr/local/mysql/var

The directory listing now looks like:

% ls -Fla /usr/local/mysql
total 26
drwxr-xr-x 13 root  mysql 1024 Jun 5 13:42 ./
drwxr-xr-x 11 root  wheel 1024 Jun 5 12:19 ../
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:20 bin/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:19 include/
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:19 info/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:19 lib/
drwxr-xr-x  2 root  mysql 1024 Jun 5 12:20 libexec/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:20 man/
drwxr-xr-x  6 root  mysql 1024 Jun 5 12:21 mysql-test/
drwxr-xr-x  2 mysql mysql 1024 Jun 5 13:42 run/
drwxr-xr-x  3 root  mysql 1024 Jun 5 12:20 share/
drwxr-xr-x  7 root  mysql 1024 Jun 5 12:21 sql-bench/
drwx------  4 mysql mysql 1024 Jun 5 13:37 var/

You can now start mysql and perform a few important tasks, like setting a mysql password to protect the database itself. Note that, while starting the database requires system root privileges, actions within the database itself do not require system root privileges, but database root privileges. It is somewhat confusing that MySQL uses the account name “root” for its all-powerful account, just as the system does, even though they are completely separate entities.

Starting mysql is accomplished with:

sudo /usr/local/mysql/bin/mysqld_safe --user=mysql &

Now you can run through some of the basic tests — but first, go ahead and secure the database by adding a password for the database “root” user, as follows:

/usr/local/mysql/bin/mysqladmin -u root password sniggle

Here “sniggle” is the password you are assigning to the database root account. In MySQL, a single user is associated with a username and a host. Most often on your development machine you will be connecting to the database locally, so the host will be “localhost”. However, if you are attempting to connect from a different machine, you will have to assign permissions based on both username and hostname. For more information on users and passwords within MySQL, read about MySQL’s grant tables, and the grant and revoke statements.

Conclusion

MySQL is a great database for Web applications and a great complement to a Mac OS X development environment. Install it on your machine and create applications in Perl, PHP, JSP, or whatever languages you like best. To administer a MySQL installation on Mac OS X, you can look to popular tools such as the Web-based phpMyAdmin from phpwizard.net, or MacSQL from Runtime Labs.

For information about starting MySQL on startup, see this article from macosxfaq.com.

Okay, so this was very much a case of fumbling around in the dark until stuff worked, lot’s of Googling and breaking stuff. The end result is a dev server on OS X that is running Textpattern with clean URLs and a copy of WordPress for good measure. These notes are primarily so I don’t forget how I did it, if they are useful to someone else, great! Be warned, though, I have no idea how secure this set up is and what flaws it has, so you follow these instructions at your own risk! Also, I am using OS 10.3.9 so I don’t know if this would work on Tiger.

Turn off Personal Web Sharing

OS X does, as you probably know, ship with Apache and it’s real easy to switch on and for a while I did use it. I am quite interested in learning a bit more about the whole serving up websites business, so first job is to do away with all the pre-installed Mac stuff.

Go to System Preferences > Sharing and make sure Personal Web Sharing is stopped.

Software

I started off with Mamp and that is probably good enough for a basic set up but I wanted to run Textpattern with clean URLs. Getting mod_rewrite to work on Mamp just wouldn’t happen for me. So after a bit of Googling I came up with these downloads in preparation for my mission… gulp!

• Complete MySQL
• Complete Apache2
• Complete PHP4
• CocoaMySQL
• Web Control (Scroll down the page a bit)

Terminal

You will need to have at hand Terminal in order to do some of the stuff. This is located in Applications > Utilities. This is the best bit actually because you get to feel like Neo for five minutes! Be careful though, I am told you can do some serious damage with Terminal.

Show hidden files

Having already had a play with Mamp, I noticed that I couldn’t see .htaccess files. Also when installing Complete MySQL there was another hidden file I needed to get to. Eventually I found a note on Apple’s developer site that describes how to show hidden files. It’s gonna make your Mac look at little messier than before but it’s kind of essential:

Open up Terminal and type in the following:

defaults write com.apple.Finder AppleShowAllFiles true

And that should be that.

Complete installs

The links to the three Complete packages are self explanatory. Each comes with a detailed Install document, follow them and you can’t go wrong, much.

The only problem I ran into was creating a .bash_profile document in the home directory. With hidden files now showing I could see that my home directory (the house with my name on it) had no .bash_profile in it, so I created one with TextEdit. Again, something to watch out for is TextEdit saving it with an extension e.g. .bash_profile.rdf. If this happens click on the file and press COMMAND + I which will bring up the File Info panel and you can simply delete the .rdf from the Name & Extensions panel

In truth this had little effect for me when trying to access mysql via Terminal, unless I used the complete path i.e. /Library/MySQL/bin/mysql. Given that I have no intention of using Terminal for accessing MySQL I didn’t worry about it and it has not had any impact on this setup thus far. Note: If anyone does know why I was getting a command not found error, I’d love to know.

One other note with these complete installs is the location they end up in. Obvious now but it caused me a bit of confusion, they are in the root library file and not the library file in you home directory. To find this spot open up your hard drive and look for the Library folder

phpMyAdmin versus CocoaMySQL

I had a bash at installing phpMyAdmin but to be honest they may as well have written the instructions in Wookie. I stumbled across CocoaMySQL after a bit of Googling, opened it up, it found the path to my MySQL server and within five minutes I had created a database as was running a local copy of Joshuaink. I thoroughly recommend it for the less technically minded.

Also worth noting is that which ever way you access MySQL, you can use your root account and the password you set when setting up MySQL for all your databases which is pretty damn convenient.

Httpd.config

Certainly if you are going to be experimenting, the httpd.config file will come into play. I started off with the Web Control app because it makes back ups, reverts easily back to the original file if you mess it up and it can check your syntax for you and if you aren’t feeling confident it’s a great way to start. It soon started to get a bit frustrating though because I couldn’t do a find search to locate bits of the document.

I ended up going back to TextEdit but found I could no longer save the file from that app (though I could from Web Control). I am not sure if this happens by default or whether Web Control did it when it first ran but it turned out that the conf directory, located at /Library/Apache2/conf was locked, so again clicking on the directory and COMMAND + I brings up the info and I changed the Ownership & Permissions details from Owner: system to Owner: [my username]. I also did the same to the httpd.conf file for good measure and made sure they were both set to Read & Write for owners.

Virtual hosts

Virtual hosts were one of the big things I wanted to get done and I found two tutorials. One over at Mezzoblue and one over at SitePoint (scroll down the tutorial a bit). In the end I opted for the SitePoint one because it was getting late and my head seemed to manage with it a little better, though the URLs it produces are no where near as cool as Dave’s. Again something to consider if you do use the SitePoint one, be careful with your naming conventions because it can impact how you use the web. For example I had a directory called joshuaink and where I used to just type joshuaink — as opposed to the full URL — into Firefox to reach my live site, I was now being taken to my localhost.

DirectoryIndex

It wasn’t until I opened up the WordPress admin that I noticed I was getting a directory listing and had to manually click on index.php to get to the login page. This seems to be something to do with the DirectoryIndex bit of httpd.conf. Initially I was dropping the .htaccess file that ships with Textpattern into each and every directory with an index.php as it’s starting point and it did solve the problem but that was getting a bit tiresome. Eventually I found out that there is something called DirectoryIndex in the httpd.conf file and having located it I changed it to this so that Apache recognises an index.php:

DirectoryIndex index.html index.htm index.php index.html.var

I really don’t know if that is correct but it seems to have solved the problem.

Deleting .htaccess files

My final problem was deleting those .htaccess files I had spread everywhere and OS X wouldn’t let me because it is a hidden file. To solve this I renamed it to .htaccess.txt and then I could delete it.

Conclusions

I have got a lot to learn about Apache but it was an interesting start and well worth the effort. With my iBook mostly offline, security is not a big deal for me. No doubt I will continue to fiddle until it breaks. If you have any tips or see something very wrong with the way I have setup, please do say.

FTP Only Accounts Under Mac OS X

The following howto describes how to set up ftp only accounts using Apple Mac’s built in ftp server (lukemftpd).

This outline requires you to use the terminal, NetInfo Manager and have admin privileges on the machine in question.

Warning: You can muck things up quite seriously using NetInfo Manager. At the very least make sure you have a recent, full back-up of the machine you’re planning to setup before going any further.

To create ftp only accounts we need to:

1. Create an ftp login shell
2. Restrict our prospective ftp user to their folder
3. Create the user account
4. Create a folder for the new user
5. Give the user a password

Create An FTP Login Shell

To create an ftp login shell we need to copy or link /sbin/nologin to /sbin/ftplogin. We’ll create a symbolic link from /sbin/nologin to /sbin/ftplogin. To do this:

1. Fire up Terminal
2. Type “sudo ln -s /sbin/nologin /sbin/ftplogin” (without the quotes)
3. Hit return
4. Type in your admin user’s password when prompted

Now we need to add the new “shell” to the list of shells available to the system. To do this we need to add “/sbin/ftplogin” to the list of shells given in the file found at /etc/shells. In Terminal:

1. Type “sudo pico /etc/shells”. This’ll open up the file “shells” in a simple text editor in Terminal
2. Hit return
3. Type in your admin user’s password if prompted
4. Add the string “/sbin/ftplogin” (without the quotes) on a new line at the end of the list of shells available. This’ll give you a final list similar to:

   /bin/bash
   /bin/csh
   /bin/sh
   /bin/tcsh
   /bin/zsh
   /sbin/ftplogin

5. Type ctl + “o”. That’s the letter “o” while holding down the control key
6. Hit return
7. Type ctl + “x” to eXit Pico

Restrict User To Their Folder

We’re setting this up now so that as soon as the user we’re creating gains access to our machine, they’re restricted to their log-in or root folder. All we have to do is create the file /etc/ftpchroot if it doesn’t exist and then add the prospective user’s username to the file.

1. In Terminal, type “cd /etc” (without the quotes. From here on in, I’ll assume you’re ignoring the quotes)
2. Check to see whether the file “ftpchroot” exists. If it doesn’t, type “sudo touch ./ftpchroot” and give you admin password if prompted for it

Now we need to add the username to the created file. Using pico:

1. In Terminal type “sudo pico ./ftpchroot”. This’ll open up the file “ftpchroot” in a simple text editor in Terminal
2. Type in your prospective ftp user’s username. Ours is “fred”. For safety, make the username all lowercase letters only – although we’ll let you have the underscore (“_”) too.
3. Type ctl + “o”. That’s the letter “o” while holding down the control key
4. Hit return
5. Type ctl + “x” to eXit Pico

Create User Account

We do this in NetInfo Manager. I’m going to talk you through doing this the long winded way – but once you’ve got one account set-up, I’d suggest you duplicate an existing account and modify it as appropriate.

1. Fire up NetInfo Manager
2. At the bottom of the pane, click the little lock symbol and supply your admin username and password to unlock NetInfo Manager
3. In the lefthand column, select “/”
4. In the middle column select “users”
5. Click the “New” icon at the top of the pane. This will create a new user called “new_directory”.

Now we need to modify this user account to give it the properties we’re after. Some of these properties will depend on your setup and how you want to administer your machine. We’ll use some reasonable settings but you may want to change these.

Before we go further, we do need to check what the next available user id (uid) is. To do this, click through your users in NetInfo Manager (ignoring the system users if you know what these are) making a note of the highest uid. In my case it’s 503. This means that my next user is going to be 504. Alternatively, start a new series for ftp users starting at 601.

Having done this, with the user “new_directory” selected in NetInfo Manager:

1. Select the “name” property in the bottom half of the pane. Double click on the Value “new_directory” to select it and type in your username. In our example our username, as added to the ftpchroot file is “fred” – so that’s what we’ll type here.
2. Create a new property by clicking in the “New” icon at the top of the pane. This will create a new property called “new_property”. Change the property value to “uid”. Now change its value “new_value” to the next available uid – or, if you’re starting a new series, 601.
3. Add a new property for the group id – “gid”. We’ll set this to “20″. i.e. Create the new property, select “new_property” and type “gid”. Select “new_value” and type “20″.
4. Follow this procedure to add:
   

   Property		Value(s)
   expire		0
   change		0
   shell		/sbin/ftplogin
   home		/Users/<username>

   Where the text “<username>” in the last property (“home”) is the username of the user you’re adding. In our example “fred”. So the value for the property “home” would be “/Users/fred”. This means the bottom of your NetInfo Manager pane should end up looking something like:

   Property		Value(s)
   home		/Users/fred
   shell		/sbin/ftplogin
   change		0
   expire		0
   gid		20
   uid		504
   name		fred

   2006-04-18: We’ve been contacted by Esben Sørensen and Antoine Durr over the weekend, both of whom make the observation that “realname” needs to be added to the properties listed here. i.e. we should end up with:

   Property		Value(s)
   home		/Users/fred
   shell		/sbin/ftplogin
   change		0
   expire		0
   gid		20
   uid		504
   name		fred
   realname		Fred

   So, add the “realname” property “else the account’s system preference pane will henceforth come up blank due to an incorrect/invalid realname” (Antoine Durr).

   Thanks to Esben and Antoine.

5. Make sure you remember the uid as you’ll need it in a sec.
6. Close NetInfo Manager saving and confirming the save as you go.

Create A User Folder

We need to create a user folder and then change its ownership (and permissions) to reflect those of the newly created user.

1. In Terminal, type “cd /Users”. Typing “ls” will give you a list of all the users on your machine
2. Type “mkdir <username>” where <username> is the new user’s username. We’ll be typing “mkdir fred”
3. Change the owner of this file by typing “sudo chown <uid>:20 ./<username>. Where <uid> is the uid for the user you added (and made a mental note of) and <username> is the username…. OK. You’ve got the idea. Oh. If your prompted for a password, give your admin password.
4. Change the permissions of this file so that we can all access it (if you know what you’re doing here, set the permissions as you see fit). “sudo chmod 777 ./<username>”

Now we’re on the home stretch.

Give The User A Password

The next step is to give the newly created user a password. To do this, in Terminal:

1. Type “sudo passwd <username>”. (So we’ll be typing “sudo passwd fred”).
2. Type in the new password at the prompt.
3. Retype it as prompted.

NAT?

If you’re behind a router or firewall which does Network Address Translation (NAT), there’s one more thing. Passive FTP requires the machine offering the FTP service to return its IP address and a port on which it’ll be listening. If you’re on a NATed network, it’s likely that the FTP server is going to return its internal IP number rather than the external address you’d prefer it to give. To get around this:

Create the file /etc/ftpd.conf

Add the line “advertise all <host>” where <host> is either the host name or external IP address for the FTP server.

Done

Restart the FTP server to ensure that all the caches are flushed and then see whether you can log-in via ftp as the new user. The easiest way of doing this is to turn FTP off and then on again in System Preferences -> Sharing.

Darwin: Kernel and BSD

Mac OS X Server starts with Darwin, the same open source foundation used in Mac OS X, Apples operating system for desktop and mobile computers. Darwin is built around the Mach 3.0 microkernel, which provides features critical to server operations, such as fine-grained multi-threading, symmetric multiprocessing (SMP), protected memory, a unified buffer cache (UBC), 64-bit kernel services and system notifications. Darwin also includes the latest innovations from the open source BSD community, particularly the FreeBSD development community.

Next-Generation Computing Power

Mac OS X Server v10.4 brings the power of 64-bit computing to mainstream servers opening up opportunities to process exponentially larger problems. Now with 64-bit addressing, Mac OS X Server can access massive amounts of memory, transcending the 4GB memory limitation of 32-bit systems. Its high-performance 64-bit file system enables you to create very large, exabyte-sized volumes for enormous databases and media storage. And its 64-bit optimized math libraries enable extremely accurate mathematical calculations. While Mac OS X Server is the ideal platform for next-generation networking applications and services, it also runs todays 32-bit applications natively no modification required.

Advanced BSD Networking

To increase the performance and security of your server deployments, Mac OS X Server incorporates industry-standard protocols and the latest in security standards such as multilink multihoming, IPv6, IPSec, IP over FireWire and 802.1X network authentication. New in Mac OS X Server v10.4 is Ethernet link aggregation and network interface failover (IEEE 802.3ad) for higher aggregated throughput and increased server availability. And with Mac OS X Server on Xserve G5, you also get support for Virtual Local Area Network (VLAN) tags and Ethernet Jumbo Frames. Using the time-tested BSD sockets and TCP/IP stack, these advanced networking features ensure compatibility and integration with IP-based networks.

Secure from the Start

Thanks to its UNIX foundation, Mac OS X Server contains robust security features in its core. To protect your server, your network and your organizations data, it also includes state-of-the-art technologies such as a built-in firewall with stateful packet analysis, strong encryption and authentication services, data security architectures and support for access control lists (ACLs) for fine-grained control of file system permissions. Simple interfaces and configuration tools allow you to set up systems easily and securely. In fact, when you take an Apple server out of the box, its already configured with the most secure settings.

Standards-Based Directory Services Architecture

Mac OS X Server features Open Directory, Apples directory and authentication services architecture. Open Directory allows you to integrate your server with any LDAP directory, leveraging the infrastructure you already have in place. It even integrates with proprietary services such as Microsofts Active Directory or Novell eDirectory. Also integrated is MITs Kerberos tcehnology, enabling single sign-on support in both Open Directory and Active Directory environments.

Optimized for Business-Critical Server Deployments

While Mac OS X Server has the same robust core as Mac OS X, it adds industrial-strength features required for server deployments. Designed for headless operation, Mac OS X Server enables you to install and configure services without connecting a monitor to the server. Powerful remote management tools allow you to securely manage services from anywhere on the network, and support for SSH2 provides secure access from the UNIX command line. To keep your systems up and running, Mac OS X Server has built-in tools for system monitoring, preventing accidental shutdown and recovering services quickly in case of network or power failure.

A single Xserve is ideally suited for smaller scale Web hosting, where the task is to host a handful of moderate-traffic sites. (With a fleet of Xserves, you could host an eBay or an Apple.com, but that’s a topic for another article.) The Xserve’s Apache Web server software has a multitude of configuration options. In this article, I will go over how to set up Apache to serve multiple Web sites from the same machine—so-called “virtual hosting.” I will also look at ways to optimize the server’s setup for fast, robust Web hosting. This article assumes that you have already followed the steps in the Mac OS X Server Administrator’s Guide to start Web service. (You can find the Guide on the Mac OS X Server Manuals page.)

Hosting Multiple Domains on One Server

The out-of-the-box behavior of Apache is to have one IP address and to serve one domain. However, it is quite easy to transparently host thousands of domains on a single Xserve, and the users need never know that it’s one machine behind the scenes and not a whole farm. There are two approaches to this sort of “virtual hosting”—IP-based and name-based. With IP-based hosting, each domain name is mapped to its own individual IP address. Name-based hosting uses a little trickery so that many domains can be served from the same IP address. IP-based hosting is a little more robust—it allows for secured HTTPS transactions, which are important for Web commerce, reverse DNS, and some other features; but IP addresses are scarce, so name-based hosting, which works perfectly well, is probably preferable for most applications. Name-based hosting depends on a certain header sent by the browser, and as a result it doesn’t work with some browsers released before 1997, but that is less and less of an issue as those browsers become increasingly scarce. I will go over how to set up both kinds of virtual hosting.

IP-Based Hosting

Assuming you have already acquired the domain names and IP addresses you’ll be using, the first step in creating an IP-based hosting setup is to configure the Xserve to have multiple IP addresses on the same Ethernet card. This can be done from System Preferences on the Xserve. Open the Network Preferences pane. Select “Active Network Ports” from the Show drop-down menu. Choose the port corresponding to the Ethernet card that you want to assign multiple IP addresses to, and click “Duplicate.” Then simply change the duplicate configuration to reflect the second IP address. It is necessary also to make sure that the Subnet Mask setting for all but one of the ports is 255.255.255.255. This will prevent conflicts in the routing tables.

On a headless Xserve, the same thing can be accomplished with the IPAliases startup item. If the file /etc/IPAliases.conf doesn’t exist, create it. For each additional IP address, this file should contain one line of the form

interface:IPaddress:netmask

For example, to add the IP address 192.168.50.210 to the en0 network interface, the following line would be used:

en0:192.168.50.210:255.255.255.255

The netmask should always be 255.255.255.255.

In addition, IP aliases must be turned on, by adding to /etc/hostconfig the line

IPALIASES=-YES-

Every time the system is booted, the aliases listed in /etc/IPAliases.conf will be added. The file can contain any number of aliases.

With multiple IP addresses configured, the next step is to add DNS entries. For each domain that you want mapped to an IP address, create an A record in the DNS pointing the address to the site. In BIND, the A record might look like this:

firstdomain.com.   A   10.151.90.2

All of the records for the various domains can be in the same DNS file or in different ones, depending on the preferences of your users and whether you host your own DNS or not.

Finally, tell Apache how to deal with requests for the various addresses. In Server Settings, click Web in the Internet tab. Choose “Configure Web Service” from the drop-down menu. In the Sites tab, you can add as many sites as you like, just by entering the domain name and IP address for each one. The content for each site should be placed in the folder you specify in the “Web folder” field here.

Name-Based Hosting

Setting up name-based hosting is a bit simpler. Add DNS records for each domain to be hosted, such that each domain name resolves to the same single IP address—the one associated with your Xserve. When a user’s browser makes a request for one of the domains, it will send an HTTP Host header indicating which domain it is requesting. Apache interprets this header and returns the appropriate content.

After the DNS is configured, go to Server Settings’ Internet tab, and choose “Configure Web Service” from the Web drop-down menu. Go to the Sites tab. Here you can create an entry for each site you want to serve. Give each one the same IP address but different domain names. Content will be served from the location specified in the “Web folder” field.

If desired, name-based and IP-based hosting can co-exist.

Handling A Lot Of Domains

If you are hosting quite a few domains, or adding new ones frequently, it can be inconvenient to add an entry for each one in Server Settings. The process can be automated to a degree, so that simply adding a DNS entry and creating a new directory for content on the Xserve is sufficient to launch each new domain. NOTE that this method and that of adding sites via Server Settings are mutually exclusive—new domains added in this way will not be reflected in Server Settings, and adding or editing sites in Server Settings will alter the configuration of the automatically created domains with unpredictable results. This method also precludes turning the performance cache on and off on a per-domain basis. That said, here are the basic steps.

First, configure a single site in Server Settings, with the correct IP address. The domain name you give it doesn’t matter. Save the changes.

Edit /etc/httpd/httpd.conf to uncomment the two lines beginning:

LoadModule vhost_alias_module

and

AddModule vhost_alias_module

Also, change the line

UseCanonicalName On

to

UseCanonicalName Off

Next, edit /etc/httpd/httpd_macosXserver.conf. There should be a long comment section starting with the line:

## The section below contains a block for each site (virtual host).

Below this comment section is the stanza to edit. It looks something like this:

#<RAdmin 100>NameVirtualHost 192.168.0.25:80

Listen 192.168.0.25:80

<VirtualHost 192.168.0.25:80>

#WebPerfCacheEnable Off

#SiteAutomaticallyDisabled Off

ServerName example.com

ServerAdmin webmaster@example.com

DocumentRoot "/Library/WebServer/Documents/"

DirectoryIndex index.html index.php

CustomLog "/private/var/log/httpd/access_log" "%{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"

ErrorLog "/private/var/log/httpd/error_log"

and so on.

The stanza may look somewhat different if performance caching is enabled.

There are just a few changes to make to this. First, on the ServerName line, you can place the fallback domain to which users of pre-1997 browsers will be sent. This line has to exist, but for users of modern browsers, it will be ignored.

Then modify the DocumentRoot line to look like this:

VirtualDocumentRoot /Library/WebServer/Documents/%0

and the CustomLog line to include %v :

CustomLog "/private/var/log/httpd/access_log" "%v %{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"

Save the file and restart Apache.

The VirtualDocumentRoot directive tells Apache to interpolate information from the server name, which in this case is read on the fly from the user’s browser, into the pathname. “%0” is a specifier representing the requested domain name. Thus, a browser request for http://domain-ten.com/index.html will be answered with the file at /Library/WebServer/Documents/domain-ten.com/index.html.

As a result, to host a new domain, all that has to be done is to create a new directory corresponding to the domain name in /Library/WebServer/Documents, and to place content to be served in that directory.

The various specifiers understood by the VirtualDocumentRoot directive are explained on the apache.org website. For example, if you have hundreds of domains hosted, they can be sorted into 36 directories based on their first alphanumeric character with the following directive:

VirtualDocumentRoot /Library/WebServer/Documents/%1.1/%0

A side-effect of this aliasing technique is that log data for all the virtual domains is sent to the same file. Adding the “%v” specifier to the CustomLog line prepends the name of the domain to each log line. A simple script can be used to parse this master log file into individual files for each domain, if so desired. More information on CustomLog specifiers is available on the apache.org website.

Tuning Web Server Performance

When setting up an Xserve for use as a Web server, there are a number of things you can do to improve performance. Some of these techniques improve the performance of the machine in general; others involve examining where bottlenecks may be occurring and tuning the Web server to work around them.

First, it is important to make sure the hardware is up to speed. Even a low-end Xserve has a very nice feature set, including fast disk access, fast Ethernet, and a minimum of 256MB of RAM out of the box. The RAM allotment can be increased to 2 gigs: if the Web server at full-throttle seems to be using a lot of memory, buying more RAM could speed things up considerably. In terms of hardware, there are several options that will increase reliability, including IP failover to a second server, which is described in detail in the Admin Guide, and adding an Xserve RAID for ultra-fast and reliable storage.

In addition to the hardware approaches, there are a number of software-based strategies for optimizing a Web server. I will detail some of these below.

Apple’s Performance Cache

Included in the OS X Server installation is Apple’s performance cache. This acts as an intermediary between the Apache Web server and the user: the cache stores a copy of commonly requested pages from the sites served, and, upon receiving a user request for one of these pages, sends it along. This involves much less overhead than invoking Apache each time the page is requested. Apache is still kept busy serving dynamic and less common pages. The cache can be enabled and disabled individually for each of the sites served from the machine. In general, the cache is very helpful for highish-traffic sites that consist primarily of static HTML pages. The total size of the site’s popularly requested static pages should be small enough to fit in the machine’s RAM; otherwise caching may actually slow things down. For sites with primarily dynamic content, the cache will not be helpful.

To turn the performance cache for a particular site on or off, go to the Internet tab in Server Settings and click Web. Choose “Configure Web Service,” and then select the Sites tab. Edit the site you want to change, and go to the Options tab. Check or uncheck “Enable performance cache” and save. The changes take effect when the Web server is restarted from the Web drop-down menu. Note that this cannot be done with a server configured with dynamic site addressing, as explained above.

Aspects of the behavior of the cache can be configured in the file /etc/webperfcache/webperfcache.conf. The default settings seem to work quite well, but they can be adjusted to make the cache work better with tweaked Apache settings (see below) or unusual server configurations.

Tweaking Apache

Apache has various settings which control how it handles requests. Tuning these can make a big difference in the performance of the server.

Apache’s performance can be monitored by viewing yourhosteddomain.com/server-status in a browser. Configure the <Location /server-status> section in /etc/httpd/httpd_macosXserver.conf to control who can view the status: it’s set by default to deny all but localhost.

Eliminating Unnecessary Modules

The first step in speeding up Apache is to remove any unnecessary modules. To see which modules are compiled in, do the following:

In httpd.conf, there is a section that looks like this:

#<Location /server-info>#    SetHandler server-info

#    Order deny,allow

#    Deny from all

#    Allow from .your-domain.com

#</Location>

Remove the # from the beginning of each line to uncomment the directive. Change “.your-domain.com” to the actual domain(s) that you wish to access server information from, and then restart Apache.

Now http://yoursite.com/server-info should display a variety of detailed information about the server, including which modules are compiled in, and configuration information for each module.

Modules that are compiled in statically can’t be removed without recompiling the Web server. The out-of-the-box configuration of Apache on Xserve has almost every module compiled as dynamically loadable, so it is easy to turn off unnecessary ones without recompiling the Web server. Dynamic modules are loaded when Apache starts, according to the LoadModule and AddModule directives in the file /etc/httpd/httpd.conf.

The base installation of Apache that ships with OS X Server loads quite a few dynamic modules by default. Each of these takes up some memory, and some of them, such as mod_status, cause Apache to do extra work with every request. Any modules that aren’t necessary to the functioning of the sites you host should not be loaded. This can be controlled by commenting out (by prefixing a # on each line) the relevant LoadModule and AddModule directives for each module in /etc/httpd/httpd.conf. Every module has both a LoadModule and and AddModule directive—be sure to comment out both when disabling a module. Mod_include and mod_rewrite, among others, are notorious performance hogs.

Adjusting Processes

There are several directives that can be adjusted to modify how Apache handles traffic. Apache will spawn new versions of itself to handle requests. MaxClients sets the maximum number of these that will be spawned. The more of these there are, the faster Apache can handle a large number of requests—up to the limitations of the machine’s memory. The default is 500. Figure on about 1 MB of RAM for each httpd instance, and set MaxClients accordingly in Server Settings (or /etc/httpd/httpd_macosXserver.conf).

The MinSpareServers and MaxSpareServers directives, in /etc/httpd/httpd.conf, set how many spare server processes are running to handle sudden requests. StartServers sets how many are created when Apache first starts. You may want to increase StartServers and MaxSpareServers if Apache seems to be slowing down when it has to create new processes. When Apache spawns more than four child processes per second—a sign that it may need more spare servers—it logs that fact to its error log. Keep an eye on the log and tune if necessary.

MaxRequestsPerChild keeps a lid on potential memory leaks by killing off each child process after it has served a certain number of requests. The default setting on OS X Server is 100,000, which is reasonable. A setting of 0 means that Apache’s children are never killed.

The KeepAlive settings in /etc/httpd/httpd_macosXserver.conf control how each server process listens for new requests on a connection that has been established. Increasing KeepAlive requests reduces traffic from new connections, but increases server load with many Apache processes waiting around for orders.

Removing Extra Steps

Another key to speeding up Apache’s behavior is to minimize the number of things it has to do for each request. If the Web server is receiving a lot of requests, these extra tasks can bog it down tremendously.

HostnameLookups causes Apache to perform a DNS lookup for every incoming request, so it can log the domain name as well as the IP address in the access log. This should be turned off, as it is by default, if performance is an issue. The DNS lookups can be performed after the fact, on another machine, using a tool such as logresolve.

If AllowOverride is turned on, then Apache checks for the presence of .htaccess files containing overriding directives at every level of the hierarchy. This repetitive checking eats up server resources. For maximum performance, set AllowOverride None. (This is the default setting for OS X Server.)

FollowSymLinks is a directive that instructs Apache to follow symbolic links without performing an additional security check on them. If this is turned off, Apache slows down to check each symbolic link.

Finally, logging is very important for 95 percent of Web-hosting activities, but if you are not using it, turning it off will improve performance. All that file access slows things down considerably. Set TransferLog /dev/null in /etc/httpd/httpd.conf.

Temporary Adjustments

Sometimes, if you’re lucky, you have advance warning of a peak in Web traffic; say, a well-read news site is planning to link to one of the domains you host tomorrow. There are a few emergency preparations that can be made to allow for that kind of situation.

First, free up memory and CPU by offloading everything you can. If the Xserve is acting as a mail server, database server, or what-have-you, as well as a Web server, move those duties to another machine if possible. If there are other medium-traffic domains that could be hosted elsewhere temporarily, do it. Shut down unnecessary processes and cron jobs.

Second, make sure you have enough bandwidth. If you use a firewall, you may want to reconfigure its socket handling to maximize throughput.

If it is possible, making changes to the content of the
domain to be served can be very effective. Remove images, reduce
their file sizes, or simply move them to another server and
serve them from there.

Apache’s MaxClients limit is hard-coded at 2048 in OS X
Server. For peak traffic, you may want far more clients than
this. It is necessary to recompile Apache to make this change.
You will have to download the source code from the
href=”http://httpd.apache.org/download.cgi”>apache.org website. In the source file src/include/httpd.h,
change the line

#define HARD_SERVER_LIMIT 2048

to

#define HARD_SERVER_LIMIT 4096

Or whatever number seems appropriate. Note that the number given here is usually a factor of 2.

Then recompile according to the instructions in the INSTALL file included with the source.

Careful deployment of all of these tips should significantly improve the way the Xserve handles Web serving. If, after all of the above, your server simply can’t handle the load it’s getting, that’s when you should consider adding a second machine to share the burden.

Mac OS X Server makes it easy for groups to collaborate and communicate through their own wiki-powered intranet website complete with group calendar, blog, and mailing list. Users can create and edit wiki pages, tag and cross-reference material, upload files and images, add comments, and search content with point-and-click ease.

You don’t need to be an experienced webmaster to host your own home page, website, or Web 2.0 application with Mac OS X Server. With its intuitive administrative interface, you can immediately start up a static website or deploy even the most sophisticated of sites.

Powered by Apache.

Included in Mac OS X Server is Apache, the most widely used HTTP server on the Internet. Apache is preconfigured with default settings, so deployment is as simple as starting the Web service. Any HTML content saved to the server’s default web folder will be served over the Internet automatically. Mac OS X Server offers experienced webmasters support for using either Apache 2.2 or Apache 1.3 from within the Server Admin application.

Deploy the Web 2.0.

Everything you need to develop, deploy, and host reliable Web 2.0 applications is included. Mac OS X Server ships with a full complement of server applications and frameworks including Apache 2, Ruby on Rails, Tomcat 5, and WebObjects 5.4. For hosting enterprise-class applications, Mac OS X Server includes a 64-bit Java VM optimized for the latest generation of Intel multicore processors.

Hosting multiple websites.

Support for virtual hosting in Mac OS X Server allows you host multiple websites on a single server. Using Server Admin, you can configure each website on your server to have a different domain name (using virtual domains) and even a different IP address. In addition, each website can be configured with unique security options and separate log files for tracking and reporting.

Apache Performance

Up to 50% improvement over Tiger Server^*

Leopard Server Xserve Quad Xeon

1.56x

Tiger Server Xserve Quad Xeon

Baseline

Apache performance

Be dynamic.

Apache is extremely flexible, so you can add dynamic content for a more interactive Internet solution. Dynamic content enables you to host stores, auctions, shared calendars, portal systems, polls, and other database-driven services. The robust server-side architecture in Apache supports dynamic content generated by server-side includes (SSIs), PHP, Perl, Apache modules, and custom CGIs — as well as by JavaServer Pages (JSPs) and Java Servlets.

Secure web services.

Mac OS X Server integrates OpenSSL with the Apache web server, providing support for strong 128-bit encryption and public key infrastructure (PKI) authentication using X.509 digital certificates. This high-grade security architecture protects credit card information and other confidential personal and business data transmitted during web transactions.