AddThis Social Bookmark Button

Listen Print Discuss
Apache Web Serving With Mac OS X

Apache Web-Serving with Mac OS X: Part 3

by Kevin Hemenway
01/04/2002

Editor's note: In the first part of this series, Kevin showed you how to easily start serving Web pages from your Mac OS X computer. In the second article, he explored the world of CGI access. Today, he moves forward with a look at PHP.

Turning on PHP4

We're on the last legs of our trip down Feature Lane, Impressiville. This will be the easiest section of our journey, mainly because we'll be going through the paces based on what we already know. Much like CGI, PHP is very popular and well supported, and very often installed on Web hosts by default. Much like SSI, the code is included and interpreted into the actual HTML of your Web pages.

Just like our other sections on CGI and SSI, turning on PHP involves searching for the feature name ("php") within our Apache configuration file. The first entries we come up against are:

    # LoadModule php4_module     libexec/httpd/libphp4.so
    # AddModule mod_php4.c

These lines are just like those we encountered when we were messing around with CGIs -- they enable or disable the loading of PHP on a restart of our Apache Web server. Since they're commented with that little "#" character, we've got to remove the "#" to enable them. Do that now.

Moving on to our next search result, we see: 

    # For example, the PHP 3.x module will typically use:
    #
    # AddType application/x-httpd-php3 .php3
    # AddType application/x-httpd-php3-source .phps
    #
    # And for PHP 4.x, use:
    #
    # AddType application/x-httpd-php .php
    # AddType application/x-httpd-php-source .phps

Apache: The Definitive GuideApache: The Definitive Guide
By Ben Laurie & Peter Laurie
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari

We saw these same sorts of lines when we were enabling SSI. In essence, they're saying that any file with the .php extension should be processed by the PHP module we just enabled. As we'll see soon enough, Mac OS X (versions 10.1 and above) comes pre-installed with PHP 4, so go ahead and uncomment the two "for PHP 4.x" lines. Save the Apache configuration file, and stop and start the Web server using the "Sharing" preference panel.

We're going to return to our Apache error log for a second to illustrate a simple, yet helpful bit of information. Each time you start Apache, it will spit out a single line telling you that everything has started successfully. Often times, it will look like so:

    [notice] Apache/1.3.20 (Darwin) configured 
        -- resuming normal operations

When you add a third party module or feature (like PHP, mod_perl, mod_ssl, etc.), Apache will graciously make mention of it in its startup line. If you just restarted the Apache Web server now, take a look at the error log by typing:

    tail /var/log/httpd/error_log

You should see Apache wax poetic with:

    [notice] Apache/1.3.20 (Darwin) PHP/4.0.6 
        configured -- resuming normal operations

Apache tells us that PHP is enabled, but how do we really know for sure? Rather easily, actually. Take that index.shtml file that we were testing SSIs with, and rename it to index.php. Now, replace the contents with the following:

    <html><body>
        <h1>Gleefully Served By Mac OS X</h1>
        <? phpinfo()?>
    </body></html>

Finally, go to http://127.0.0.1/index.php and you should see a long page full of PHP diagnostic information. If so, rub your hands with a gleam in your eye, because PHP has now been added to your arsenal. Want to add a simple Web-based email program for your traveling coworkers? Check out PHPost. Note: Most PHP applications require a sophisticated database backend, like MySQL or Postgres -- PHPost is one of the few that doesn't. While installing and configuring these database systems is relatively easy on Mac OS X, it would be outside the scope of this primer. Want to see an article on this? Let us know by commenting below.

Choosing Who Sees What

Comment on this articleThis concludes our original vision for this series on Apache web serving with Mac OS X. In addition to your questions, what areas would you like us to explore next?
Post your comments

It's five in the morning. You've gone through three six packs of soda, two tins of Penguin Reds, and an untold number of delicious snacky treats. You've got a CGI poll script ready to quiz the employees on the menu for the next company picnic, an SSI image gallery that happily sends the marketing department into a drool-dripping feature panic, and a PHP app with which your developers can track and monitor their sloppy code.

Now what?

After all you've done, something rather minor. We've just got to throw a little access control on our spunky new intranet -- we wouldn't want the outside world seeing the insanely great job we've done (we'd rather wait and show them the really cool stuff we're gonna do on our personal time, right? Wink, wink, nudge, nudge).

While Apache can certainly handle authenticated access control, we're only going to touch on the location-based side of it. To do so, we're going to return to a snippet of configuration file that we've messed around with before, back when we were enabling SSIs:

    <Directory "/Library/WebServer/Documents">
        Options Includes Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

I mentioned we'd eventually touch on the remaining lines, and now is said time (although, we're still going to rudely skip AllowOverride). Quite simply, the "Order allow, deny" and "Allow from all" lines are the magic that will stop outside visitors from perusing our intranet. Right now, as these lines stand, our intranet is wide open to the public.

This is what we're going to end up with:

    <Directory "/Library/WebServer/Documents">
        Options Includes Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from gatesmcfaddenco.org
    </Directory>

See what we've done here? The first thing we did is flip our "Order" directive. This tells Apache to process all "Deny" rules first, and then all the remaining "Allow" rules. Likewise, our first "Deny" is "from all," meaning no one can come knocking. If we denied everyone, of course, no one would be able to see our Macstrosity (rather phenomic, eh?), so we add an "Allow" rule for our GatesMcFaddenCo domain. We can also allow and deny by IP, like "Allow from 209.204.146". This will allow access to anyone from within the GatesMcFaddenCo network, but no one from without.

Conclusion

Before you know it, it's seven in the morning and time to show off your efforts. You're confident, feigning a yawn of boredom, not sleepiness. As the morning sun glints off the silver of your glorious G4 tower, you smile privately -- as has been typical since time began, doing something amazing on the Mac has been incredibly simple. Your boss is impressed, your coworkers are disbelieving, and you're signing a purchase order for the newest mystery item from MacWorld. Oh, life is good.

Don't think we've exhausted everything Apache and Mac OS X has to offer, though. You still haven't touched mod_ssl, which allows secure server capabilities, nor have you fiddled with mod_perl, which can speed up your CGI scripts immensely. You haven't touched the authentication capabilities of Apache's access control, or even tweaked Apache's configuration with .htaccess files. And sadly, if someone types in a bad URL for your intranet, you still get an ugly and generic 404 page.

Only 7:30? Plenty of time to bust those out before lunch. Good luck!

Kevin Hemenway is the coauthor of Mac OS X Hacks, author of Spidering Hacks, and the alter ego of the pervasively strange Morbus Iff, creator of disobey.com, which bills itself as "content for the discontented."