The misadventures of setting up

What a week. I've run into some interesting challenges setting up a new combination Weblog/magazine site called, a nonprofit portal dedicated to serving the VAR and channel communities. (For those of you who are unfamiliar with the term, a Weblog is a site where a community gathers to share news links and other information.) I've also decided to host my own mail server,, which means I've been out of touch with most of the world while I've been busy getting everything working.

I'll share my war stories during the next few weeks. Hopefully you'll be able to learn from my mistakes when setting up your SOHO (small office/home office) or MOFO (medium office/field office).

I'm starting small by running these sites from my home office. I put together a 1GHz Athlon machine for about US$750, and ordered DSL with a 384K bps uplink to host two domain name servers and the site.

All my machines are running various distributions of Linux. My name servers are running BIND 8.2.3, which runs as a nonprivileged user, so they are safe from the recently overhyped Linux Lion worm that infects poorly configured name servers. I'm using Apache 1.3.14 for my Web server and will probably start with a custom version of PHP-Nuke 4.4.1a as my publishing system (see

The first thing I had to do was set up the name servers. I was suddenly introduced to the concept of classless subnets. DNS is not designed to work with a subnet of fewer than a block of 256 addresses. The idea behind classless subnets is that they allow an ISP to delegate authority over a small number of IP addresses to a site. (My subnet contains eight IP addresses, but only five of them are available for servers and workstations.) You and your ISP will have to play some tricks to make this work.

It took a couple of days for me to fully grok classless subnets. Unfortunately, it's not enough to understand how they work when setting up your name servers. You also have to know how your ISP has configured your specific set of IP addresses. You'll need to contact your ISP's DNS administrator for that information.

That introduced the first of two serious obstacles: the Pacific Bell automated phone navigation system. No matter how many combinations of phone menu choices I tried, I was either routed back to where I started or to a person who couldn't help me. The only way I could get any useful answers was to search the PacBell Web site for e-mail addresses that looked as if they had something to do with DNS and then send questions via e-mail. (I had to use my Pacific Bell e-mail account because wouldn't work until I had these issues resolved.)That did the trick. A DNS administrator responded to an e-mail with exactly the information I needed. As it turns out, Pacific Bell, my ISP, deviates from the examples in the RFC2317 specification ( so I had no chance of guessing how to configure my server on my own. I reconfigured my servers according to the technician's instructions, but it still didn't work.

That led me to the second of my serious obstacles: brain mush. When the PacBell DNS administrator mentioned that he couldn't access my name servers, I realized that I had forgotten to reconfigure my Cayman DSL router as a bridge. Until I did so, I could get to the Internet, but the Internet couldn't get to me. Once I reset the router, everything fell into place. I knew I had achieved success when I immediately received a ton of e-mail messages that had been piling up while was offline.

I was finally ready to tackle PHP-Nuke when I hit another obstacle. I noticed some problems with my Reiserfs file system, so I updated my Linux kernel to include the latest fixes. The next thing I knew was that my network had gone bahooties. I'll take you on that ride next week.

Nicholas Petreley is founding editor of LinuxWorld ( Now that he's back online, reach him at

Join the newsletter!

Error: Please check your email address.

More about ApachePacBellPacific

Show Comments

Market Place