wiley-logo-sm.gif
> wiley.com

50 Fast Mac OS X Techniques

Joe Kissell

Chapter 9: Server Techniques for Nongeeks

In this chapter:
Technique 41. Giving Your Machine a Domain Name
Technique 42. Turning Your Computer into a Web Server
Technique 43. Using PHP to Create Dynamic Web Sites
Technique 44. Creating and Sharing Databases
Technique 45. Running Your Own Mail Server

Technique 41. Giving Your Machine a Domain Name

Discuss This TechniqueReport Errors

Determining Your IP Address

  • Click here to find out the current IP address of your computer (or router, if you’re using NAT): www.whatismyip.com.

Domain Registrars

DNS Providers

Dynamic DNS Client Software

Technique 42. Turning Your Computer into a Web Server

Discuss This TechniqueReport Errors

Dealing With ISPs That Use Filtering

Some ISPs don’t want their customers running servers from their homes. There are a number of reasons for this, and although I have some strong opinions about why this should not be done, the fact remains: it happens. Of the ISPs that discourage servers, some are more insistent than others. There are those that forbid it outright (and will cancel your account if they catch you), and then there are those that simply block or filter port 80 (used by Web servers) on the upstream router, so that no requests on port 80 could ever get through to your computer. If your ISP falls into the latter category, there is a somewhat awkward technical workaround you can employ, and I’ll describe that here. Be aware, though: if you run afoul of your ISP’s Terms of Service and they catch you, you could have your account cancelled even if everything is working perfectly well. That disclaimer aside, here is the workaround.

First, you need to get your Web server to listen on some port other than 80. (This will also need to be a port that no other service is using, and that your ISP isn’t blocking for some other reason. It’s common to choose ports numbered 8000 and above for this purpose.) This can be done by editing /etc/httpd/httpd.conf using pico (following the instructions in the book). You will need to change two lines; use Control-W (“where is”) to find them.

First, find a line that looks like this:

#Listen 3000

Uncomment it by removing the # sign, and change the number 3000 to whatever port you want to use, for example:

Listen 8000

Then look for this line:

Port 80

Again, change the number 80 to whatever port you want to use, for example:

Port 8000

Close and save the file as usual, then restart apache (turn Personal Web Sharing off then back on in Sharing Preferences). It is now listening on port 8000. Because of this, when someone wants to access your Web site, they will need to add a colon and the new port number to the end of the domain name in the URL. For example:

  • http://www.mydomain.com becomes http://www.mydomain.com:8000
  • http://www.mydomain.com/yadda/blah.html becomes http://www.mydomain.com:8000/yadda/blah.html

If you really don’t want people visiting your site to type in a port number, there may be a way around that as well. By using an external DNS provider (as discussed in Technique 41), you can sometimes set up a type of port redirection on the DNS server, so that requests to www.mydomain.com (that is, to the default port of 80) are automatically redirected to www.mydomain.com:8000. ZoneEdit, for example, offers this capability, as described in this FAQ.

Learning More about HTML

There are hundreds of books on HTML, and I could not begin to provide an exhaustive survey. Here are a few books, however, with recent editions that discuss the latest permutation of HTML, known as XHTML. XHTML is a modular flavor of HTML that also conforms to the XML (eXtensible Markup Language) specification; as such, it improves the separation between form and content and provides for a more flexible, platform-neutral page description.

If you prefer to learn HTML by reading Web sites, consider these:

Technique 43. Using PHP to Create Dynamic Web Sites

Discuss This TechniqueReport Errors

PHP Software for Mac OS X

Sample PHP Code

Learning More PHP

Books on PHP

Technique 44. Creating and Sharing Databases

Discuss This TechniqueReport Errors

MySQL Software Resources

Setting Up a Secure Realm

If you want to keep phpMyAdmin—or any other pages on your Web server—safe from casual Web browsers, you need to set up a secure realm. A secure realm is simply part of your Web site that asks for authentication (entering a username and password) when someone tries to access it. If the username and password are entered correctly, the pages are served; if not, an error message will result. (Note that this is different from SSL—Secure Sockets Layer. SSL encrypts information sent to and from your Web server but does not automatically restrict access to it; a secure realm restricts access but does not encrypt the information.)

Setting up a secure realm involves creating a file to hold passwords, and then modifying the Apache configuration to use that information for files in a certain directory within your Web site. The official Apache documentation on authentication does a pretty good job of explaining this, but note that this procedure wasn’t included in the book because it is not fast. If you’re interested in a more concise, user-friendly explanation, please let me know.

Using PHP with MySQL

Technique 45. Running Your Own Mail Server

Discuss This TechniqueReport Errors

UNIX SMTP Servers

UNIX IMAP Servers

WebMail Servers

Other Mail Server Resources

Dealing with ISPs That Use Filtering

As discussed above under Technique 42, some ISPs don’t want their customers running servers from their homes; this extends to mail servers as well as Web servers. Unfortunately, with mail servers the situation is quite a bit more complicated: you will need outgoing access on port 25 (for sending mail); incoming access on port 25 (for receiving mail); and, if you want to access your mail server from somewhere outside your local network, incoming access on port 110 (for POP) and/or port 143 (for IMAP). Thus, depending on your needs and how aggressively your ISP blocks ports used for servers, there are potentially three different problems to solve. I’ll look at each one in turn.

  1. Outgoing access on port 25 (for sending mail)

    If your ISP only blocks outgoing, but not incoming, access on port 25, this is a relatively easy problem to solve. James Duncan Davidson has written an extensive article titled Configuring sendmail on Jaguar for O’Reilly’s MacDevCenter. On the the last page of his article, scroll down about halfway to the heading Working with Lame ISPs. You’ll find instructions for editing your sendmail configuration file to route outgoing mail through your ISP’s server, which is certainly the easiest way of solving this problem. This method is not foolproof, however. Depending on just how lame your ISP is, the method described there (adjusting the smart_host setting in sendmail.conf) may not work unless you authenticate with it (send your user name and password) first.

  2. Incoming access on port 25 (for receiving mail)

    If your ISP blocks incoming access on port 25, you will not be able to receive mail using your own mail server—period. Unlike the trick for Web server port redirection, you can’t simply tell someone to send you e-mail at a different port number. Even if you could get your SMTP server to listen on a different port, you would have no way to tell other e-mail servers to use that new port to send mail to your domain. The workaround, in this case, is simply not to use your machine to process incoming mail. Use your DNS provider to have all mail for your domain forwarded to an external machine (perhaps your .Mac account, or one of the many other e-mail providers). Then configure your e-mail application to retrieve mail from that external server. I’ll be the first to admit this isn’t a great setup, as it defeats much of the point of running your own mail server. A better solution would be to find an ISP with more lenient rules.

  3. Incoming access on ports 110 and/or 143 (for POP and IMAP)

    This is only an issue if you’re running your own mail server at home and want to retrieve your mail from somewhere else, outside your local network—local machines will not be blocked from using those two ports. There’s an easy way and a hard way to deal with this. The easy way is to install SquirrelMail (or another WebMail client) and access your mail using a Web browser. The hard way is to reconfigure imapd to listen on different ports, then set up the preferences of the e-mail client on other machines to use that same port. Because the “hard way” is usually more trouble than it’s worth, I’m going to refrain from going into the details here.

Making Your Mail Server More Secure

The mail server software installed in Technique 45 will certainly get the job done, and for many users with basic needs, it should be perfectly adequate. However, as noted in the book, the trade-off for something relatively easy to set up is a lack of security. What exactly does that mean? Well, in terms of mail servers there are two main security issues: Authentication for outgoing mail and privacy for incoming mail.

Authentication

First, you may want to prevent people you don’t know from using your SMTP server (sendmail) to send outgoing mail. A mail server without any restrictions on who can use it (an “open relay”) can be used by spammers to send vast quantities of junk mail—something most of us would like to prevent. In the book, I showed you how to prevent this by giving sendmail a list of trusted IP addresses. This is fine if you always use the same machines for sending mail, and if those machines always use the same IP addresses. But if you want to be able to send outgoing mail through your server from any machine, that method won’t work. A more robust method is to use something called SMTP authentication. This means that whenever someone tries to send mail using your server, the server will first query the user for a username and password. If the username and password are on the server’s list of trusted users, the mail can pass through; otherwise, it’s rejected.

Sendmail can be configured to use SMTP authentication, but the procedure is rather difficult and error-prone. This article gives you an overview, and this one provides more details. But beware: these are both very tech-heavy and not for the faint of heart. Among other things, adding SMTP authentication will require you to rebuild sendmail from the source code. If authentication is important to you, I recommend ditching sendmail altogether and instead using Exim, an SMTP server that is much easier to configure if you need to go beyond the basics. This article discusses setting up Exim for use with Mac OS X Server, but the directions are also applicable to the client version of Mac OS X, as long as you use UW IMAP as your POP/IMAP server. After setting up your server to use SMTP authentication, be sure authentication is also enabled in your mail client’s preferences, with your username and password entered.

Privacy

If you ever send or receive e-mail with confidential contents, you will want to make sure that nobody other than the sender and the recipient can read it. Unfortunately, e-mail ordinarily travels from the sender, through several e-mail servers, and finally into your e-mail client software, in plain, unencrypted text. This means that someone with access to one of those servers (or any of the intermediate infrastructure) could potentially intercept and read your e-mail. In the real world, this happens relatively rarely, but when it does, the consequences can be severe.

The first thing you can do to increase your privacy is to make sure mail being sent to and from your mail server from a client machine is encrypted. Again, this is ordinarily not an issue if the client and server are the same machine, or in the same room—but if you’re accessing them from another location, you might want to use SSL (Secure Sockets Layer) to encrypt the messages as they travel back and forth.

One part of the privacy puzzle is using SSL for outgoing mail you send to your server; another is using SSL for retrieving mail using POP or IMAP. In both cases, you must configure both the client and the server software to use SSL. Changing settings in your e-mail client is usually quite straightforward, but configuring your SMTP and POP/IMAP servers to use SSL is, shall we say, nontrivial—way beyond the sort of fast technique the book is about. (The SMTP server Exim, mentioned above, does make the SSL setup considerably easier than sendmail.) If there is sufficient interest, I’ll add some information here to get you on the right track, though I can’t promise an exhaustive discussion.

There are, however, at least two other approaches to keeping your e-mail secure. One is to use an SSH tunneling utility to make a secure connection to your mail server, then send and receive e-mail normally. Another is to use a program such as PGPMail to encrypt the text of the e-mail message itself. This is a more secure solution in the sense that it protects your mail even after it leaves your own mail server; on the other hand, it also requires the recipient to use the same software and go through additional steps to decrypt the message using a passkey you provide.



Cover

ISBN 0-764-53911-6
432 Pages
April, 2003

Wiley Technology Publishing
Timely. Practical. Reliable.

[ Home ]

[ Contents ]

[ Preface ]

[ Chapter 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ Appendix B ]