THIS PAGE is basically an extended version of those little footers
which many sites carry on their home pages -- 'Powered by Linux',
'Microsoft BackOffice(TM)' and so on. Despite what Microsoft try and
tell you, you always surmise there was a bit more to it than that, and
this page is an attempt to explain what it was I had to do to bring
www.iota.co.uk, the Web site of the company I used to work for,
and its allies on other IP port numbers, to the seamless quality
broadcasting you see today.
The tone of this page varies fairly randomly between things I've done because I didn't know any better, and things I've done which were so compellingly the Right Thing that I'll not merely recommend but instruct that you do the same thing if in anything like my situation!
I Built a Linux Internet Server With My Bare HandsIOTA SOFTWARE Limited have got a Web site. Yes, this is obvious to you already if you've followed that link, but what I'd like to dwell on is what this leads you to assume about Iota Software Limited. Many of you (this is ignoring the uncomfortable possibility that only my mates will ever, ever, read this page) will thus be assuming that somewhere inside Iota is someone whose thought processes communicate in TCP/IP and who speaks English only through a special gateway daemon; who can't open his or her mouth without speaking Great Wisdom about Unix networking just out of habit; who is, in a word, comfortable with this whole Internet server business.
Well, there wasn't. There was only me. I did a degree in Computer Science, but unless you have done, too, there's no way you can appreciate how little use that is. Yes, there had been lectures about Unix, but I spent several of them doing the Telegraph crossword and almost all the others asleep -- sometimes still in bed, but not infrequently actually in the lecture hall. I'm sure I was once taught what zombie processes were, but I never bothered taking it in, and now I'm a Unix system administrator the things just stare at me reproachfully (as, I suppose, zombies are meant to) from the ps aux listing, as if they're trying to shame me into recognising that intimate knowledge of the Unix process model is a more important Life Skill than the ability to do cryptic crosswords.
I don't agree with them that it is, though. I'm a quick learner and a good guesser, which two skills can substitute for many others: enough others, in fact, that I was able to goad and levitate an Internet server (or, in a piece of jargon I saw at the BETT show, really took to and am trying to promote, provide a large scale telepresence) without ever, at any stage, really having the foggiest.
The hardwareIota Software Limited have a 64kbps leased-line connection through Demon Internet. This was, we discovered after careful investigation, the cheapest leased-line solution the UK had to offer, but it's still pretty expensive if you ask me. It's £500 per month. Connection costs are linear with bandwidth for really quite a long way, despite the fact that the genuine excess cost to BT of providing, say, a 256kbps line as opposed to a 64kbps one must be almost precisely zero.
What we get for this is a British Telecom Kilostream connection, which is BT's 64kbps digital point-to-point service, that goes from the storeroom ("the underworld") at Iota House to Demon Internet's headquarters in London. There's a box on the wall in the underworld which looks just like an ordinary BT small plastic wallbox such as domestic phones use -- except for the label which says "Circuit ID:" and some tortuous number and "Destination: London".
Plugged into this is a box the size of a thickish hardback book which says BT on the front and is a Line Termination Unit, or LTU. This has five LEDs on the front, one of which is lit during normal use, and two connectors on the back. Neither connector is labelled, but it turns out the 15-pin D is an X.21 port. X.21 is a fast serial port standard (able, in fact, to go at 2Mbps, not just the 64kbps at which we're using it). We don't use the other connector, so I hope it's not important.
Plugged into the LTU, via the X.21 port, is another box about the same size, which we bought from Netland and is a router and says ACC Danube on the front. This is one of the most expensive electronic devices per pound weight that I've ever seen, and is well up there in the charts of number of configuration options per pound weight, too. It has two LEDs on the front; in normal use one is steadily lit and the other is flashing. It has a bunch of LEDs on the back, too. Also on the back is an X.21 port (obviously); a conventional, 9600bps serial port (with an RJ45 connector, of all things, and marked "Console"); and a 10Base-T Ethernet port. The router performs the task of converting incoming IP packets on Ethernet into PPP going out over the X.21 line, and vice versa.
Though I've said I built this site with my bare hands, I have to say at this point that I couldn't get the router to work for the life of me, and had to make substantial use of Demon's technical support line. (In case anyone else gets in the same boat I was in, I'll explain: I was doing everything I could and it was blankly refusing to work. The "display physical port table" command on the router told me that WAN1, the X.21 port, had "Admin Status: Up" but "Operational Status: Down". The problem, Demon discovered, was something called LQM or Line Quality Management, which occasionally takes it into its head that the line has no quality whatsoever and determines that its maximum safe bandwidth is zero bits per second.)
Plugged into the router is talisker itself, our Internet server machine. There was some debate as we were getting our connection sorted out as to whether a Pentium/133 was up to the job, or whether we should spend the extra on a Pentium/150 or 166. This dilemma was solved in the end when we noticed that Stu's PC wasn't really being used for anything, and it duly got upgraded from Windows NT to Linux for use as our Internet server. And was Stu's machine a 133 or a 166MHz Pentium? Er, well, no, really.
It's a 486DX2/66. It's got 20Mb of RAM, a 420Mb IDE hard disc (motherboard IDE), and a SoundBlaster card with a good ol' Panasonic CR562 CD-ROM. It's also, crucially, got two network cards in it: one is connected to the router via a crossover-wired UTP cable (rather than using a hub), and the other is connected to Iota's internal 10Base-2 backbone.
Note I have the nagging worry that some of this baroque chain of conversion boxes is in fact unnecessary. If there was such a thing as an X.21 serial port card for ISA PCs, we could surely dispense with the router altogether -- and such a card could safely be very expensive and still be cheaper than a router. A search on Alta Vista for X.21 and Linux shows up several -- for instance, this one.
Another note The underworld now contains:
The softwareThe Linux system I started with was Slackware 2.1, which I got from the CD-ROM inside Que's book "Using Linux Special Edition: The Most Complete Reference". More complete than others it may be, but it's certainly not totally complete, which is why I ended up buying a couple of other books too. In particular, I ended up buying O'Reilly Associates' book "Linux Network Administrator's Guide", which has been a very present help in trouble. The text of LNAG is also available online as part of the Linux Documentation Project, but if your system is working well enough for you to groove off and find LDP Web sites, then you don't need the book at that point anyway. And besides, it's almost worth the cover price just for the woodcut reproduced at the top of the chapter "Managing Usenet News".
The kernel on talisker is version 1.1.59, which is not the latest by some margin, but seems to do the job. During the Slackware installation process, I'd told it I didn't need SLIP support, so the installer didn't configure it -- but as I had an SBPCD CD-ROM, I needed to install a Christmas-tree, all-options-on kernel, including a lot of SLIP code which would cause the machine to hang when booting. I got round this by booting Linux from a floppy -- the boot message says something like "In a pinch, you can mount your filesystem with a command like root=/dev/hda1", and I was in a pinch, so I did just that. Once into the system, I then recompiled the kernel (which is an activity nothing like as difficult as it sounds) with SBPCD but no SLIP, and since then it's been fine.
The kernel is compiled with packet forwarding switched off. Zero tolerance for crime! This means, of course, I have to run daemons for each protocol which needs to cross the firewall, but this only comprises Web and news and maybe one day RealAudio (SMTP mail gets as far as the firewall and then stops, continuing its journeys by POP3 or NFS) -- it's not a great hardship. For this to work perfectly, all the machines inside Iota should really have RFC 1597 IP addresses. They don't, but the Class C network they do use is widely rumoured to be unallocated anyway, and even if it is allocated there is no possibility of harm being done to us by it -- the firewall's two Ethernet cards and its static routing table ensure that no sensible conversation can occur between the server and any outside machine bearing those addresses. All it would mean is that we wouldn't be able to access any Web or other servers on those machines.
(Of course, any theoretical system with one Ethernet card and one X.21 serial port card set up for PPP could be configured in an identical fashion.)
Setting up DNS was probably the hardest software task in configuring the server. All I can suggest is that you stick like glue to the example files in LNAG -- not the example files in the Slackware distribution. No, you don't need a DOMAIN line in /etc/named.conf. Yes, you do need an NS record. Check every damn thing you can using nslookup, then get a friend at a nearby university to check that your site appears kosher to them, too. I'd mistakenly used a hostname instead of a FQDN (or vice versa, I can't remember) once in the DNS configuration files, and discovered that everywhere in the world my IP address resolved not to talisker.iota.co.uk but talisker.50.217.194.in-addr.arpa -- it was so embarrassing.
We currently use CERN's cacheing, proxying HTTP server daemon, version 3.0 -- though I may one day demote this to proxy-only duties, and deploy Spinner or Apache as the externally visible server. I get it to log proxy use and "real" use into separate log files; every midnight it processes the "real" log file with Analog 1.9b3, and the proxy log file with process_proxy, a program I wrote myself which just adds up per-client, per-day statistics and spits out a nice HTML page where it's all in a <table>.
For email, the server runs Smail 3.1.29, configured to use post.demon.co.uk as an SMTP smart-host. Inside Iota, everyone uses Acorn's (unreleased) !Email program for RiscOS, except for Allison (the only employee with a PC but no Acorn) who uses Eudora Light. !Email expects to find a user's mail intray in /home/<user>/Mail/Intray, and it was easy to configure Smail to put it there; Eudora, on the other hand, uses POP3, and the Slackware in.pop3d expects, quite reasonably, to find the intray in /var/mail/spool/<user>. Sorting this out meant finding the source of in.pop3d on the Slackware CD and recompiling it with the non-standard location in. Running !Email also means we need to run a program called m.send every five minutes from cron, but if you use !Email you probably already know about m.send -- you almost certainly have the source of it somewhere on the Acorn Riscix box which you almost certainly have. It compiles under Linux with no problems.
Our Usenet news connection is something about which I can write with less certainty, as Demon's news service is, as I write this, completely shot. When it comes back up, though, what we'll be doing is using dnntpd as a proxying NNTP daemon to Demon's news server. Inside Iota we'll be using Microsoft Internet Explorer 2.0, or even ANT Marcel, to read news, and our server will be pretending really to be a news server, while in fact just asking Demon for messages on a one-by-one basis.
-- Peter Hartley, 15th March 1996