Sysadmin

What a week. I've run into some interesting challenges setting up a new combination weblog/magazine site called VarLinux.org, a nonprofit portal dedicated to serving the VAR and channel communities. (For those of you 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, petreley.com, which means I've been out of touch with most of the world while I've been busy setting everything up.

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

I'm starting small by running these sites from my home office. I put together a 1-GHz Athlon machine for about $750, and ordered DSL with a 384K uplink in order 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 VarLinux.org with a custom version of PHP-Nuke 4.4.1a as my publishing system (please see Resources for more information).

I want to control my own domains, so the first thing I had to do was set up name servers. In doing so, I was suddenly introduced to the concept of classless subnets. Domain name service (DNS) is not designed to work with blocks of fewer than 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). But you and your ISP have to play some tricks to make this work.

It took a couple days for me to fully grok classless subnets. Unfortunately, it's not enough to understand how they work in order to set up your name servers. You 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 automated phone navigation system of my ISP -- Pacific Bell Telephone Co. No matter how many combinations of phone menu choices I tried, I was routed back either 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 Website for e-mail addresses that looked like they had something to do with DNS, and send questions by e-mail. (I had to use my PacBell e-mail account, since petreley.com 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 deviates from the examples in the RFC2317 specification (please see Resources for more information) so it was unlikely that I could have guessed how to configure my server on my own.

The DNS details

Here is an example of how PacBell set up its DNS to allocate the addresses to me. I have substituted the real IP addresses with fake ones and substituted PacBell's DNS servers with isp-dns. Any half-wit can figure out the real addresses by looking up the IP addresses of my name servers on the Internet and deducing the rest, but I'd rather not encourage people to cut-and-paste my settings.

176        NS      ns0.bogus-dns.net.
           NS      ns1.bogus-dns.net.
           NS      ns1.isp-dns.net.
           NS      ns2.isp-dns.net.
177     CNAME   177.176.1.168.192.in-addr.arpa.
178     CNAME   178.176.1.168.192.in-addr.arpa.
179     CNAME   179.176.1.168.192.in-addr.arpa.
180     CNAME   180.176.1.168.192.in-addr.arpa.
181     CNAME   181.176.1.168.192.in-addr.arpa.
182     CNAME   182.176.1.168.192.in-addr.arpa.

It is not an accident that this group of IP addresses starts with 176. In my case, PacBell allocates groups of eight IP addresses to its classless subnets. 176 is a multiple of 8.

In this example, the ISP has transferred authority over the address 192.168.1.176 to the name servers starting with ns0.bogus-dns.net. The addresses 192.168.1.177-182 all point back to 192.168.1.176. So if anyone tries to resolve any of the remaining addresses (192.168.1.177-182), the requests will be under the authority of the name server that controls 192.168.1.176.

At my end, I configured named.conf to include the primary zone for 192.168.1.176 and the remaining equivalents that further resolve the addresses 192.168.1.179-182. The following example is incomplete to save space, since the remaining zone definitions for 192.168.1.179-182 should be obvious:

zone "176.1.168.192.in-addr.arpa" {
        type master;
        file "/var/bind/176.1.168.192.db";
        allow-query { any; };
        allow-transfer {
                ns0.isp-dns.net;
                ns1.isp-dns-net;
                ns1.bogus-dns.net;
        };
};
zone "178.176.1.168.192.in-addr.arpa" {
        type master;
        file "/var/bind/178.176.1.168.192.db";
        allow-query { any; };
        allow-transfer {
                ns0.isp-dns.net;
                ns1.isp-dns-net;
                ns1.bogus-dns.net;
        };
};
zone "bogus-site.org" {
        type master;
        file "/var/bind/bogus-site.org.db";
        allow-query { any; };
        allow-transfer {
                ns0.isp-dns.net;
                ns1.isp-dns-net;
                ns1.bogus-dns.net;
        };
};

Notice that this configuration instructs the name server to transfer information about the zones to the ISP name servers and to the secondary name server hosting the eight IP addresses. I'm not sure if is necessary to allow transfers for the 176.1.168.192.in-addr.arpa zone. It works so I'm not going to fix it unless someone tells me otherwise. Generally, an ISP will allow transfers only where they are valid, so any attempt by my name server to transfer information for which it has no authority should be denied. So if I've made a mistake for this zone, it shouldn't cause any problems.

Here is what the zone file 176.176.1.168.192.db might look like:

;
; BIND reverse data file for 192.168.1.176.178
;
$TTL 8H
@ IN SOA ns0.bogus-dns.net. root.bogus-dns.net. (
                     2001032401    ; Serial
                          10800    ; Refresh
                           1800    ; Retry
                        1209600    ; Expire
                          43200 )  ; Default TTL
 
@       IN      NS      ns0.bogus-dns.net.
@       IN      NS      ns1.bogus-dns.net.
@       IN      NS      ns1.isp-dns.net.
@       IN      NS      ns2.isp-dns.net.
  
@       PTR     ns0.bogus-dns.net.
@       PTR     bogus-site.org.

Then you go on to configure the bogus-site.org.db zone file in the way you would normally configure such a zone to include things like Web and mail servers.

Now I must sternly warn you that the above methodology may not be perfect. It may not even be close. I'm not a DNS wizard by any means. But it worked -- eventually. If you are a DNS wizard and have a better way, by all means let me know and I'll pass on the information.

The dire results

It didn't work at first. Which leads me to the second of my serious obstacles: brain mush. I realized when the DNS admin mentioned that he couldn't access my name servers 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 achieved success when I immediately received a ton of e-mail messages that had been piling up while petreley.com was offline.

I was finally ready to tackle PHP-Nuke when I hit another obstacle. I noticed some problems with my Reiserfs filesystem, 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.