Web Publishing with a DAMP System
DAMP is an acronym for Darwin, Apache, MySQL, and PHP/Perl/Python, the
components necessary to create a powerful and scalable open source web-
publishing platform on a Mac OS X system. It’s actually a play on the older term
LAMP, where the L stands for Linux.
The idea is quite simple. The site’s content is stored in anMysql database running
alongside the web server. Except for a handful of static pages that don’t need to
change (such as the site’s splash page or the company’s “About us” page), every
web page on the site is built on the fly through programs that output HTML
based on information pulled from the database. This can be done through a
sophisticated template system, simple CGI scripts, or anything in between. This
chapter details the elements involved in setting up a system like this on Mac OS X.
Elements of a DAMP System
Mac OS X ships with every technology that this section mentions, short of a data-
base server. Fortunately, MySQL, the software that puts the “M” in DAMP, is
easy to obtain and install; see the next section.
We refer specifically to Darwin in this chapter, since running a DAMP plat-
form means running a collection of network services (see Chapter 13) and
software that runs solely on the Unix layer of Mac OS X. It doesn’t use any of
the application or user interface layers that make up the top half of the oper-
ating system’s architecture as depicted in Figure P-1.
Through the Apache web server’s module system (see “Apache Modules” in
Chapter 13), you can enable extensions to the default web server. These
embed Perl, PHP, or Python interpreters into the server, letting you use and
write software in these languages that runs very fast and has access to
Apache’s internal information and variables.
To be truly robust and scalable, a dynamic web site—be it an e-commerce
site, an online journal, or a research results catalog—should keep all of its
content in a database.
MySQL is a very popular open source database system from the Swedish
company MySQL AB (http://www.mysql.com). It’s fast, scales well, and has
enjoyed years of support as the favorite of the open source programming
community. MySQL is free to use for projects that run on your own servers,
but you do have to purchase licenses for it if you bundle it as part of a pack-
aged, commercial solution.
You don’t have to run MySQL per se to run a DAMP (or at least
DAMP-like) system; any SQL database that your language of choice
can work with will do. This can include other open source data-
base systems like PostgreSQL, or commercial packages like
Microsoft SQL Server or Oracle.
Due to its advantage of community support and the fact that it
comes preinstalled with recent Mac OS X versions, the rest of this
chapter covers the MySQL configuration specifically.
PHP, Perl, Python
These are three interpreted, portable languages well known for their ability to
serve up dynamic web pages. All are open source, with online support
communities several years old, and all come standard with recent versions of
Mac OS X. (Older versions included only Perl.) See “Choosing a Language”
for a brief comparison between these languages.
Whichever language (or combination thereof) you go with, its function
within a DAMP system is the same, acting as a glue between Apache and
MySQL. Specifically, upon receiving a request, the web server will (instead of
simply fetching an HTML file and returning it to the client) run a separate
computer program that itself generates an HTML page, built by combining
templates with information that it fetches from the database. There are many,
many ways you might go about this, from simple CGI scripts to intricate
templating and content management systems.
Setting Up DAMP
This section will help you decide on the language for your DAMP system (the port), how to install and configure MySQL, and how to further configure
Apache to use Perl and PHP.
Retrieve this CD image from one of the following URL:
Choosing a Language
You should probably have some proficiency in at least one of the “P” languages,
even if your site is going to run code written by others. The following is a very
brief rundown on the individual strengths of these languages.
Preparing the Language for Database Connections
The language you choose will need a way to connect to your mysql database and
pass queries to it.
PHP is the only language of the three designed entirely with web program-
ming in mind; it boasts web-page embedability among its core features. It is
arguably the best of the three for building very simple database-backed web
applications, and may be the fastest to pick up and learn, given its ability to
immediately show results in a web browser.
However, it’s very hard to extend, since adding new functionality means
recompiling the PHP software itself; it isn’t modular, as Perl and Python are.
Perl is a general-purpose programming language that excels at handling text—
since any web page is really just a long string of text, Perl has been a natural
choice for crafting dynamic web sites for as long as the Web has existed.
Perl is the oldest of the three languages, with a history going all the way back
into the 1980s. Without a doubt, it enjoys the most support. Anyone can
extend Perl through writing modules (in either Perl or C), and the famous
Comprehensive Perl Archive Network (CPAN, headquartered at http://www.
cpan.org) serves as a globally shared repository of these modules, most of
which have an object-oriented interface.
The language’s “love it or hate it” features include a “there’s more than one
way to do it” philosophy (which lets you express most fundamental—and, by
extension, all higher-level—program structures in a variety of ways), and its
punctuation-heavy syntax (an amalgamation of the many older, Unix-based
languages that Perl borrows from with the designer’s ideas about natural
language). Many programmers feel that these make Perl an extremely flexible
language that’s a joy to work with; others think that the language’s very broad
range of allowable programming styles makes the typical Perl program look like
unreadable garbage. In truth, you can (and probably should) write readable,
well-documented, and easily maintainable Perl programs and modules, but you
can also write horrible and opaque code. Perl won’t complain if you really want
to act that way (if you specifically ask it not to complain by deactivating its
built-in warning and strictness compiler pragmas).
Like Perl, Python is a general-purpose language that is strong in text
processing, so it too works well for cranking out HTML pages. Python
quickly earned a lot of support as an alternative to Perl due to its own design
philosophies, which in some ways are the reverse of Perl’s: it uses a much
cleaner syntax and limits the number of ways a programmer can express
fundamental structures. Python’s fans think that this leads to much more
readable code than Python’s peers have.
Python is also extensible through user-written modules, though its support
community isn’t quite as vast as Perl’s. Still, it’s managed to earn a reputa-
tion over the years as a good first programming language, balancing power
with clarity and its insistence on good programming practices.
PHP features various built-in commands to connect to databases, with
different commands for different kinds of database servers.
Perl uses a common API called DBI (for database interface) for all its data-
base connections. Connecting to an SQL database in Perl requires at least two
pieces of software: the DBI module and a database driver (DBD) module that
is specific to a certain kind of database system.
You can fetch DBI.pm and the MySQL/mSQL DBD module by downloading
them from CPAN. Visit http://www.cpan.org or use Perl’s interactive CPAN
module, like this:
If you haven’t configured CPAN on your system before, issuing the
first command in this example can do this for you. Just use the
defaults—the items within brackets ([…])—and then you’re ready
% sudo perl -MCPAN -e shell
cpan> install DBI
[… lots of build, test, and install
cpan> install DBD::MySQL
[… yet more build, test, and install
Python uses a different, single module for each kind of database. While they
don’t use a common superclass’s API, as with Perl’s DBI module, database
modules must adhere to a specific API (defined at http://www.python.org/
topics/database/modules.html) in order to receive the Python community’s
Python’s “official” MySQL module is from SourceForge, at http://sourceforge.
Setting Up MySQL
Once installed, MySQL requires no special setup for use on a DAMP system; it
doesn’t have to be aware of the other components, as does Apache and your
language of choice. So long as it’s ready to receive connections and queries from
your code, it’s good to go.
Unless you are running Mac OS X Server, you must download and install MySQL
yourself. Fortunately, since it’s such a popular database solution, others have
already wrapped it up into easy-to-install packages for you. The following is a list
of options that exist at the time of this writing.
• A MySQL distribution available through the Fink package manager. Once
you set up Fink on your machine as described in Chapter 24, you can install
its MySQL package through the Terminal command apt-get install mysql. As
is Fink’s way, it will probably also take the opportunity to install a handful of
other packages that it depends upon, once it gets your permission to do so.
• A Finder-launchable installation package built and maintained by Marc Liy-
anage, available at http://www.entropy.ch/software/macosx/. (You’ll note a
PostgreSQL package available on the same page as well, should you want to
try SQL databases other than MySQL, or already have a preference for
• You can get a “raw” binary distribution at http://www.mysql.com.
Starting the database
In the Terminal, cd to the directory created by the install (/usr/local/mysql,
unless you used Fink with its default /sw/ working directory, in which case you’ll
go to /sw/mysql). Run the following commands as root (we’ll use the sudo
command to achieve this):
chown -R mysql /usr/local/mysql/*
./bin/safe_mysqld –user=mysql &
Now test it, by requesting to start an interactive Terminal session with the server’s
% mysql test
Welcome to the MySQL monitor.
Commands end with ; or \g.
Your MySQL connection id is 2 to server version: 3.23.51-entropy.ch
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
Generally, with a new MySQL install, you should follow these steps:
1. Assign a password to the MySQL root user (not to be confused with the
system root user).
2. Create a database that your DAMP application will use.
3. Create a user within the MySQL system that’s able to access that database, can
connect from localhost only, and can’t do anything else. This is the user that
your programs will use when working with the database to build web content.
Now you get to configure it! If you already know MySQL, from this point on
everything will work as you expect. Otherwise, you have a bit of a learning curve
to overcome. You can read MySQL’s excellent online documentation about this
(and every other) topic at http://www.mysql.com/documentation/index.html,* or
you might turn to a third-party application for help, such as the free and open
source web-based mysqltool, found at http://dajoba.com/projects/mysqltool/. (A
CGI-based program written in Perl, this software gives you the bonus of being a
DAMP application itself, when running on Mac OS X.)
Setting Up Apache
The /etc/httpd/httpd.conf file (see “Apache Configuration” in Chapter 13) contains
a few commented-out lines that activate language-relevant Apache modules:
[ … later in the file … ]
To use PHP, uncomment the php4_module and mod_php4.c lines. This allows you to
start using PHP embedded in web pages right away, such as with the following
example, a simple HTML page that looks at the client’s user agent:
echo <?php phpinfo(); ?> >> info.php
If you’re going to use Perl with your DAMP system, it will behoove you to acti-
vate mod_perl, an Apache module that places a persistent Perl interpreter within
your web server (http://perl.apache.org). This not only makes Perl-based CGI
programs run faster (since Apache need not launch a Perl interpreter every time it
runs a CGI program), but also lets them access and modify information about the
current web server request. This lets you write very sophisticated programs and
modules that control server behavior on a deep level, and also opens the door for
using many existing Perl modules that use mod_perl and packages on your site.*
To activate mod_perl, uncomment the perl_module and mod_perl.c lines from
httpd.conf. As with any change to Apache’s configuration file, you must restart the
web server to have the changes take effect. Either send a HUP signal to its process
or just stop and then restart it through the Sharing pane.
Once mod_perl is running, you’ll typically want to start running all Perl-based
CGI scripts (including any that you might already have) through the
* When browsing CPAN (at http://www.cpan.org), note the Apache module directory.
Apache::Registry module. This requires adding a block of configuration informa-
tion to your /etc/httpd/httpd.conf file, like this:
The XML-like <Location> tag is a block-style Apache directive; all the directives
that it contains (SetHandler, PerlHandler, and Options, in this case) apply only to
the relative path that it defines—here, all the scripts contained within the /perl
directory. Modify this to suit your own site setup; to have it apply across the
board, define the location as / instead.
Modules and packages that use mod_perl often rely on variables you define in
Location or Directory blocks in your /etc/httpd/httpd.conf file.
Jason McIntosh, Chuck Toporek,
and Chris Stone
with contributions by Scott Gever, Dave Carrano,
and Leon Towns-von Stauber
Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo