Web Apps with Tiger: Getting Startedby Kevin Hemenway
Yeah, yeah, yeah. You've got your Dashboard, your Automator, your Spotlight, your uber-Safari, and your RSS screensaver. And they're great, dandy, zippidity-doo-dah. It'd be terrific if there were something new under the hood for web serving, right? Apache 2.0! Some, any, version of MySQL. Oooh! Ooooh! I want this one, and that one, and whee! Well, guess what, dear readers? You got nothin'. An incremental update here, a minor tweakage there, but there really hasn't been many changes under the hood when it comes to web serving. This is the exact same swan song from Panther: little new, bub.
And you know what? There's absolutely nothing wrong with that. With very minor modification, and even then only GUI related, the articles I wrote two years ago are still relevant. Everything you've learned about the Apache web server still applies. If you've read my previous series, you still know how to look in the
error_log for debugging purposes,
install CGI scripts, enable and test PHP, restrict access by host, IP, or password, customize errors, create .htaccess files, and more. If we go back further to my series from 2002, there's more on aliasing directories, pretty autoindexes, and anonymous or environment access. All this stuff still works! Once you learn how to do something with Apache, it's pretty much guaranteed to always function.
Where does that leave us? In this new series, we're going to focus on the application level: instead of learning more about Apache, we're going to treat it as the serving framework it really should be. We'll talk about setting up our own Wiki, content management system (no, no, not weblog software), and some helper utilities that'll make our management of databases a bit easier. If you've got some particular applications you'd like a tutorial on, leave a comment below and we'll consider it for inclusion.
But first, let's whirlwind through the basics: turning on the Apache web server, learning a teensy bit of its configuration, and enabling and testing PHP. If you need a calmer, smoother recap than what follows, I heartily suggest rereading one of my earlier series; save for a few minor changes, they hold up to time. Don't hesitate to ask questions in the comments section below.
Getting Started with Apache and Tiger
The easiest way to begin is through System Preferences. Click the Apple Menu, choose System Preferences, and then Sharing. Under the Services tab you'll see a number of options, only one of which is of immediate value. See that Personal Web Sharing service? Select it and click the Start button to fire up the built-in Apache web server.
By default, Apache has been configured to serve your personal web pages from a directory based on your Mac OS X short username. You can find your short username in the Accounts preference panel. If your short username is "morbus," you can access your personal web site by opening a local web browser and typing
localhost) is pretty special--every computer has one. Both names represent the computer itself; by accessing
127.0.0.1 in your browser, you visit the Apache activated via the Sharing preference panel.
But, how do you make your web pages available to folks on the World Wide Web? The answer is found back in Sharing. Click the Personal Web Sharing service and note the IP or hostname at the bottom of the window--that address is how others can access your web server. If you're behind a router, you'll probably see a local address instead. You can find your publicly available IP at checkip.dyndns.org/.
In some cases, outsiders may not be able to access your server:
- Your internet service provider (ISP) deliberatively prevents incoming access to port 80, the web-serving port. They often do this to prevent users from "running their own server," a common restriction of Terms of Service (TOS). The quickest solution (though possibly in violation of said TOS) is to change the port Apache binds to. Once you do this, you'll have to refer to the port in any URL you serve, such as
- Your ISP, or network, has a firewall or routing issue that blocks or restricts access to your internal web server (or entire computer). Since step-by-step solutions to this differ depending on your specific configuration, we won't be getting into them--talk to your network administrator.
An Apache Cartography
There are a number of locations and files that are vitally important to the configuration and serving of content available through Apache. What follows is a quick rundown of the six most crucial bits:
- The two most important files, even before configuration, are your logs. The
error_logwill provide everything you need to know when something goes wrong. These files are located in
/var/log/httpd/, and most technical support (such as
#apache) will want to know exactly what your
error_logsays before even suggesting a fix. While you can certainly use the
tailshell utility to peer at these files whenever necessary, I've found it much easier to simply run a few tailDash Dashboard widgets instead (use "httpd log" and "error log"). The importance of the
error_logcan not be understated: even if the error you're seeing in your browser doesn't tell you much (by design), the one found in your
error_logwill always be dead-on.
- The next two files of import relate to configuration. The default Apache configuration file is
/etc/httpd/httpd.conf. This file has been slightly tweaked by Apple to support some additional features, but remains relatively similar to the defaults you'll see with Apache under Windows or any version of Linux. Apple has also gone a step further, however, and created
/etc/httpd/users/, which contains one configuration file per graphical user you've created. If your username is "morbus", you should have a
morbus.conffile. By default, these user files contain a minimal bit of configuration to support user websites, such as
http://127.0.0.1/~morbus/. When changing the web server config, it ultimately doesn't matter which of these files you put your additions in, but I've come to prefer the user version, just because it has less of a chance of being modified during the next OS update. Server-wide configuration additions within a user-configuration file work just fine.
- Last are the directories that contain the actual files to be served. The default directory, or the one accessed when someone requests just your IP (
/Library/WebServer/Documents/. User URLs, like
http://127.0.0.1/~morbus/are located at
/Users/morbus/Sites/. If you navigate to these locations in your Finder, you'll see some introductory files that tell you more about Apache and web serving under OS X. Read 'em and delete 'em (or back 'em up).
Pages: 1, 2