|
|
|
|
|
|
|
|
Does setting up UUCP scare the hell out of you? No more! Read on.
by Jim Hill
Discovering the Internet in a college environment, I was always very casual about the time I spent on-line. Since I didn't get a direct bill from the university, there was no reason to keep track of it. All that changed when I left the college world and got a commercial Internet service provider (ISP). As I read news and mail on-line, I realized the vast majority of my on-line time was spent not in transferring data, but in moving my eyes back and forth across the screen. From that simple observation began my long, strange journey into UUCP. Despite the fancy hardware and software in use today, UUCP remains an ideal way for those of us in the backwaters of the Internet to be connected. This article is
This article covers the simple setup: one computer, one phone line, one ISP, and calls originating only from the reader's machine. Those with more complicated setups are referred to The Linux Network Administrator's Guide by Olaf Kirch; Vince Skahan's excellent FAQs (see http://www.ssc.com/linux/howto.html) on UUCP, Mail, and News; Managing UUCP and Usenet by Tim O'Reilly and Grace Todino; and a competent psychiatrist.
Dating back to the late 70s, UUCP (Unix-to-Unix CoPy) was developed at AT&T Bell Labs to provide them with simple dial-up networking capabilities. As is typical with such software, improvements and enhancements were quickly implemented so that, today, several distinct ``flavors'' of UUCP exist. The most noticeable difference to the user is in the names and locations of the various configuration files UUCP uses. The original style, Version 2, is mostly defunct and is mentioned only for completeness. The HoneyDanBer (HDB) implementation, developed in 1983, uses rather hard-to-understand configuration files, but by virtue of its age, it is in fairly heavy use. Increased flexibility and ease of use are provided by Ian Taylor's Taylor UUCP package. As an added bonus, Taylor UUCP is capable of understanding HDB configuration files. Most, if not all, Linux distributions are released with Taylor UUCP; the current release is v1.06.
I run Red Hat Linux, but I prefer to compile my own packages, so installing UUCP was as simple as installing the SRPM file and compiling:
rpm -i uucp-1.06.1-4.src.rpmTo compile, edit the top-level Makefile.in to define your installation directories. Run sh configure to produce the Makefile and the configuration header, config.h. Browse through these files to make sure they say what you expected them to say. Edit the policy.h header file to customize it to your system; this is heavily commented, so the only thing to look out for is the default to HDB-style configuration files. I'd suggest changing these to Taylor format. Type make to build the software, then uuchk to verify your configuration file formats. make install installs the software, and now you're ready to begin configuration.
Taylor UUCP uses a handful of interdependent configuration files which I chose to put in /etc/uucp. The first configuration file, called config, sets the most general properties:
# /etc/uucp/config -- UUCP main # configuration file hostname perrinThe hostname is the UUCP name you and your ISP agree upon--mine is perrin. If this entry is absent, UUCP will attempt to obtain it via hostname(), but if your UUCP name and your system name are different, you will be unable to log in to your ISP. Once you have UUCP set up, don't change this arbitrarily, as your ISP will have entries in his config files which correspond to this name. A change will prevent you from accessing his machine. Other parameters in this file can be set to override compiled defaults, but I recommend specifying the defaults in the UUCP Makefile when you compile.
The next required file is sys, which contains information about the systems to which perrin can connect. There will be only one entry in this file, since perrin will be connecting only to my ISP's machine. Its UUCP name, by the way, is sloth. Here's my sys file:
# /etc/uucp/sys - name UUCP neighbors # system: sloth remote-send ~ remote-receive ~ local-send ~ local-receive ~ command-path /usr/sbin commands rmail rnews system sloth time any phone 123-4567 port serial1 speed 38400 chat ogin: UUCP_LOGIN_NAME \ ssword: UUCP_LOGIN_PASSWORD alternate phone 123-6789The remote-send, remote-receive, local-send, and local-receive entries specify the directories in which UUCP expects to find the files it will be manipulating. By default, this is /var/spool/uucp for a Taylor UUCP configuration.
The command-path and commands entries specify what programs uuxqt is allowed to execute and where to look for them. I spent two days trying to figure out why my ISP couldn't feed me news articles before noticing I hadn't put rnews in a directory in the command-path, so look out for this item. If you want uuxqt to be able to execute other programs, you must include entries for them. For example, to allow Fred in Pittsburgh to use your expensive color laser printer, add lpr to the list of commands.
The system entry must be the UUCP name of the system you're calling, because HDB and Taylor UUCP check system names. Ask your ISP what his UUCP name is for this entry.
The time entry is used to specify times when connections to sloth are permitted. I don't know about the average Linux user, but when I think of running specific jobs at specific times, my thoughts turn naturally to cron. By specifying any time in the config file, I can initiate a UUCP connection via a crontab entry and not worry about UUCP quibbling over the time of the call.
The phone entry, unsurprisingly, specifies the ISP's phone number. If your ISP has several access numbers, they can be specified with the alternate field. In the above example, if a call to 123-4567 fails for any reason, UUCP will attempt to place a call to 123-6789, with all other configuration data remaining unchanged.
The port entry is not the port to use, but an entry in a file named port which specifies the port to use. For single-modem machines like mine, the port file will contain a single entry, which we'll look at in a moment.
The speed entry is the speed at which the port will be transferring data.
The chat entry contains a brief chat script used for logging in, which should be familiar to anyone who has used SLIP or PPP. The space-separated fields represent messages which are alternately sent and received. In most cases, the only essential data which must be transferred are the login name and password. If you want a more detailed look at the messages sent out by the ISP's machine, check with your ISP.
Now the port file:
# /etc/uucp/port - UUCP ports port serial1 type modem device /dev/modem speed 38400 dialer genericThe port entry here must correspond to the port entry in config. The type, device, and speed entries let UUCP know the device file and speed to use. UUCP will create a lockfile based on the device name, so you should use the same device your other communication software specifies. This way, you will avoid having one process disrupt another. (If you are running UUCP via cron jobs, it's extremely likely the time to connect will come around at least once while you are already using your modem, such as for web browsing.) The last entry, dialer, specifies an entry in the last configuration file, called dial.
# /etc/uucp/dial -- per-dialer info # My modem dialer generic chat "" ATZ OK ATM0DT\T CONNECT chat-fail BUSY chat-fail ERROR chat-fail VOICE chat-fail NO\sCARRIER chat-fail NO\sANSWER chat-fail NO\sDIALTONEThe dialer entry again matches that in port. The chat entry specifies a chat script which initializes the modem and places the actual call. When this entry is read, \T is replaced by the phone entry in sys. The chat-fail entries provide a list of conditions under which the connection fails and the whole process aborts, or tries an alternate phone number if one is provided.
I've had a problem using the phone line for voice conversation--when cron tells the system to call, the modem will dial, producing the touch tones and interrupting my conversation. Only after dialing does it check for any of the chat-fail conditions and abort. If you know of a way to make the call abort as soon as the modem activates and doesn't ``hear'' a dial tone, please let me know. My friends and family are growing tired of my automated machine. [I think checking for dial tone is a configurable option on most modern modems.--Ed.]
UUCP is actually a suite of programs to do very specific tasks. For example, uucp itself is used for copying files between nodes (the machines connected via UUCP) and uux is used for executing programs on another node. Programs exist for all kinds of maintenance, like logfile-trimming and spool-checking. For my purposes (and the purposes of this article), the most important programs are uucico and uuxqt. uucico actually places the phone call and sets up file transfers, while uuxqt tells the other machine what program needs to be run for proper handling of the files.
The following sequence of events is typical:
Typing uucico -s sloth causes uucico to look up sloth in config. Seeing it should use serial1 to connect to sloth, it looks in port and sees that serial1 is the modem, which is activated by the dialer entry. Peeking at this entry in dial, uucico initializes the modem and calls the number specified in sys. When the CONNECT string is received, it executes the chat script from sys and logs into sloth.
When the login procedure is complete, perrin is in ``master'' mode and sloth is in ``slave'' mode. Files to be uploaded will be in the spool directory /var/spool/uucp/sloth/D./filename. If these files exist, perrin will upload them with instructions for the slave. The instruction files will be in /var/spool/news/uucp/sloth/C./filename. When the transfer is complete, the master and slave exchange roles, with perrin now receiving any files spooled on sloth, as well as execution instructions. When both sides have transferred all the necessary files, the connection is terminated. Logging is done in /var/log/uucp, so take a look in there for an exhaustive roster of an average session's work.
When the connection is broken, the second important UUCP program is fired up: uuxqt. uuxqt looks in the UUCP spool directory for execution requests and (if permitted) executes them. For example, files consisting of mail messages must be delivered and news postings must be moved into the news spool. By default, UUCP permits only two local programs, rmail and rnews, to be executed, which not-so-coincidentally accomplish the tasks just mentioned.
With UUCP configured and tested, it's now time to set up the transfer of mail and news.
For mail transport and delivery, the two most obvious choices are sendmail and smail. I have read that for small sites the two are roughly equivalent in configuration difficulty, but I've also seen O'Reilly's sendmail book. Nothing that massive could possibly be required for my little project. Accordingly, I chose smail. The current release is v3.1.29--while not part of Red Hat's distribution, some kindly soul has made an RPM available in the /pub/contrib directory at ftp.redhat.com.
After looking at a full source tree for smail, I chickened out and grabbed a precompiled rpm from Red Hat's /pub/contrib directory, then installed it:
rpm -i smail-3.1.29.1-6.i386.rpm
Two links to smail are needed: usr/bin/rmail and /usr/sbin/sendmail. The former is invoked when mail comes in for delivery via UUCP; the latter is often hardcoded into mail user agents, such as elm. To create these links, use the following commands:
ln -s /path_to_smail/smail /usr/bin/rmail ln -s /path_to_smail/smail /usr/sbin/sendmailNote that rmail, or a link to it, must be placed in the command-path specified in etc/uucp/sys or this will fail. Your ISP might have permission to run rmail, but if he can't find it then he'll get all sorts of error messages in his UUCP logs and might just send you a nasty e-mail message. Of course, if you've already arranged for mail to be sent via UUCP, this will backfire on the ISP, and you will quickly find yourself less than popular. Or so I hear.
The main configuration file for smail is etc/smail/config. For a site which will be doing all its mailing through a UUCP link, this is a remarkably simple file, especially since the smail package comes with very nice sample files in etc/smail/config.linux. Of the four files smail will use, I had to modify only config for my particular setup:
# /etc/smail/config smart_path=sloth smart_transport=uux visible_name=swcp.com uucp_name=perrin.swcp.comThe smart_path entry is the UUCP name of your ISP's machine. This will match the system name in /etc/uucp/sys. Any non-local mail address will be shipped off to this machine for DNS resolution and delivery. Specifying uux as the transport agent will cause any outgoing mail messages to be queued in the UUCP spool to await the next UUCP connection. I will return to this when I discuss the other configuration files for smail.
The visible_name entry identifies your smail domain. If you have registered your UUCP name, append :uucp to this entry. In many cases, this is unnecessary. Using my system as an example, the .swcp.com portion is guaranteed by the InterNIC (and my ISP's hard-earned dollars) to be unique. Therefore, the only machines which could have already taken perrin would be connected to my ISP, who would notify me of a conflict.
The uucp_name entry is (surprise) your system's UUCP name. By default, smail will generate return paths from the hostname command, in my case perrin. Since I have not registered perrin, someone else might. Without this entry, any mail returned to perrin will go to that other machine. By specifying a fully qualified domain name, I am guaranteed (because of the way DNS and UUCP addressing are resolved) the message will go first to swcp.com, which will recognize perrin as my UUCP account. For a machine named ``perrin'', this is a negligible concern, but a more common name, e.g., ``darkstar'', might cause problems.
For the stand-alone system under discussion, smail is best run as a daemon all by itself. Make sure this entry appears in etc/services:
smtp 25/tcp #Simple Mail Transfer ProtocolThis will specify port 25 for SMTP connections, which the mail transport agent (MTA) will use for delivery.
Run smail as a daemon by having a system startup script run the following:
/path_to_smail/smail -bd -q10mThe -bd option causes smail to run as a daemon; -q10m tells it to process the message queue every 10 minutes. If you do light mailing (or do a lot during a solid block of time), consider increasing this, perhaps to two hours or more with a command line option like -q2h. When a connection to the SMTP port is detected (such as when UUCP hands off the latest batch of local mail), smail will fork and handle the SMTP connection.
When smail gets a wake-up call from a mailer (like rmail, for incoming UUCP deliveries, or elm, for outgoing messages), it looks in the file /etc/smail/routers to see what to do with the message. Here's my file:
# /etc/smail/routers
smart_host:
driver=smarthost,#What do I do with nonlocal mail?
transport=uux; # Deliver it via UUCP-path
# to the machine specified with the
# smart_path option in ./config
Upon receiving a message intended
for a non-local address, smail checks this
file. It sees it is to use the smart_host,
which is defined in /etc/smail/config as sloth,
the ISP's machine. The message is to be
forwarded to sloth using the transport option,
which is set to uux. uux is another program in
the UUCP suite that queues the message with
instructions to run mail in the UUCP spool to
await the next UUCP connection.
Local mail is handled partially by an entry in the /etc/smail/directors file. The purpose of the directors file is to tell smail about some of the special options available locally, such as aliasing, forwarding to another user or to a pipe, or just about anything else you could set up. (Mailing lists on a two-user machine, anyone?) I've cut all but the entries which handle .forward files and the generic ``What to do if we have a user who just wants his mail spooled?'' scenario. Read the /etc/smail/config.linux/directors file for full gory detail:
# /etc/smail/directors dotforward: # general-purpose forwarding director driver = forwardfile, # problems go to the site mail admin owner = Postmaster, nobody, # sender never removed from expansion sender_okay; # .forward file in home directories file = ~/.forward, # the user can own this file checkowner, # or root can own the file owners = root, # it should not be globally writable modemask = 002, # don't run things as root or daemon caution = daemon:root, # be extra careful of remotely accessible home # directories unsecure = "~uucp:~nuucp:/tmp:/usr/tmp" # user - match users on the local host with # delivery to their mailboxes user: # driver to match usernames driver = user; # local transport goes to mailboxes transport = localOnce a delivery option is matched in directors, the transports file is searched to see what, if any, special options that particular delivery mode requires. For the trimmed directors file above, the corresponding transports file would be:
# /etc/smail/transports
# append message to a file
local: driver=appendfile,
# include a Return-Path: field
return_path,
# supply a From_ envelope line
from,
# insert > before From in body
unix_from_hack,
# comment out the above line for
# MMDF mailbox format and for
# use with the Content-Length
# header fields.
# use local forms for delivery
local;
# location of mailbox files
file=/var/spool/mail/${lc:user},
# group to own file for System V
group=mail,
# For BSD: only the user can
# read and write file
mode=0600,
# append an extra newline
suffix="\n",
# notify comsat daemon of delivery
notify_comsat,
Note that there is no transport for the forwarding option. This is compiled
into smail to send the message on to the forwarding address, with a few
extra headers. Forwarding to a non-local address would send the message off
to the UUCP queue for the next phone call.
Now that you've set up smail to wait for UUCP to deliver mail from the outside world and to send mail to UUCP for transfer from your machine, you need to tell UUCP when to transfer files. This is most easily done via a crontab entry. Create it by typing su uucp, then typing crontab -e. The resulting file should look something like this:
# Call for transfers
25 0,9,11,13,15,17,18-23 * * * \
/usr/sbin/uucico -s sloth
# Trim logfile
35 03 * * * find /var/log/uucp \
-size +16k -exec cp /dev/null {} \;
The first line calls sloth every few hours during the day and hourly
through prime time. Every afternoon it trims UUCP's logfile, which can grow
spectacularly with frequent transfers.
Setting up mail didn't take much time, and I was feeling pretty smug when I got my first e-mail from ``the outside''. Humility came back with a vengeance when I turned my attention to setting up news.
Like mail, a variety of software packages are available for getting news on and off a local machine. Again like mail, the best known is big and intimidating. Unlike mail, the lesser known is also big and intimidating. The ``big boy'' in news transport is InterNet News (INN). A close second is the C News package. I took a look at the documentation available for these two packages before deciding which to try. INN runs as a daemon and can be a disk and memory hog. While it can be configured to operate in a situation such as mine, it really is intended to be run on dedicated news servers with high-speed connections and many users. C News is a collection of binaries and scripts that are executed by cron and consumes minimal disk resources. While there's more documentation available for INN, I decided that C News was the way to go. Besides, I just wouldn't feel right as a Linux user if I could just follow directions and have a working system.
C News is sufficiently system-dependent that compiling from a source distribution is the only logical thing to do. The current release of C News can be found at ftp.cs.toronto.edu in /pub/c-news/c-news.tar.Z. After uncompressing and extracting the source tree, take a moment to read through the files in the docs/ subdirectory; there's some interesting material in there.
To configure C News for your system, follow the instructions in the file README.install. Before getting started, edit the file conf/update.ran. It lacks an initial line of #!/bin/sh and will cause the Makefile to exit with an error. After reading through the documentation, begin installing.
# NEWSCTL/batchparms # 500KB, after compress, is 4 minutes at # 1000cps 20 batches is somewhat arbitrary, # about 5MB per site # site class size queue command # - -- - -- -- sloth u 500000-750000 20 batcher| \ compcun | viauuxAs with mail, sloth is my ISP's UUCP host. The u class option specifies that batches will be transferred via UUCP. The size of a batch is set to 500KB nominally, with a maximum size of 750KB. If a single value is specified, it is the nominal value, with the maximum being 3 times the nominal. The queue field allows up to 20 batches enqueued. The pipelined command in the final field specifies what to do with a batch. The batcher takes the spool of outgoing news articles and assembles them into batches of nominal size. It passes the batches off to compcun, which compresses the batches. By default, compcun uses the compress function which, while not as efficient as GNU's gzip, is certain to be understood by any system. If you feel passionately about using gzip, contact your ISP to see if his system has gzip installed. (Don't laugh, some ISPs use software from their hardware providers and refuse to install any Free Software Foundation products. Now I'm serious: stop laughing.) compcun now hands off its compressed articles to viauux, a C News front end to UUCP, which delivers the compressed and split articles into the UUCP spool for delivery. Incoming news goes through the reverse process if it is batched: delivery by UUCP, decompression, unbatching, and off to the news spool.
grouplist perm times archiveThe grouplist is a comma-separated list of newsgroups to which the line is to apply. Subhierarchy expansion is automatic, so to expire the entire rec.* hierarchies, a grouplist of rec is sufficient. The perm entry indicates the type of group: u = unmoderated, m = moderated, x = either.
The times entry is generally a single number, though it can be a dash-separated list of three. If the former, the entry indicates how many days after arrival at your site an article should be kept. Of course, if the article itself contains an Expires: header which evaluates to an earlier date, it will expire then. If the times entry is a trio of numbers, the first represents the number of days that must pass after arrival before the article is considered ``expirable''. I'm sure someone could come up with a reason why a number other than zero is desired, but I'm at a loss. The second number is the days-to-expiration as seen in the single-digit format, and the third is an absolute number of days the article is permitted to dodge expiry.
The archive field takes a dash if no archiving is to be done, a full path name to an archive file, or an @ sign. If @ is used, the archive file must be specified with the -a option when doexpire is run.
# NEWSCTL/explist #grouplist perm times archive # hold onto history lines 14 days, nobody gets # >90 days /expired/ x 14 - /bounds/ x 0-1-90 - # High-traffic or trivial groups get dumped # quickly control,junk,swcp,perrin x 3 - # default: 14 days all x 14 -Note that the earliest match is accepted, so when doexpire sees the 3-day limit on the control group, it takes precedence over the 14-day catch-all at the end. If you want to mix full group names (such as rec.arts.tv) and hierarchies (such as rec.arts.*), remember to put entries into the explist file in increasing generality.
A final comment: the /expired/ grouplist tells doexpire how long to leave article entries in the history file. For multiple feeds, duplicate articles may arrive from time to time. C News keeps a list of articles in the NEWSCTL/history file and junks any duplicates. Lines in the history file are kept the number of days specified by /expired/ so that if a duplicate arrives a few days after the original has expired, it will not be reposted. If you have a single feed which is properly configured and doesn't send multiple copies out to its leaf sites, you can keep this value small.
# NEWSCTL/mailname perrin.swcp.com
# NEWSCTL/mailpaths comp.os.linux.announce linux-announce@news.ornl.gov
site[/exclusions]:grouplist[/distlist][:flags[:cmds]]Any article coming from site not in the (comma-separated) grouplist is junked. The distlist is a (comma-separated) list of distributions we are willing to forward. Any article whose Path: header contains a machine in the list of exclusions is not forwarded.
There are quite a few flags that can be set, but only one is relevant. The f flag tells C News to use batching. If you are using batching, the cmd entry contains not a command but a file name. If the file name does not begin with a slash, it is relative to /var/spool/news/out.going. If the cmd field is empty, the file is remote-system/togo.
With this in mind, let's take a closer look at my sys file:
# NEWSCTL/sys ME:all/all:: sloth/sloth.swcp.com:all,!perrin/all,!local:f:I gave my ISP a list of the newsgroups I wanted fed to me; he entered them into a configuration file on his end. As a result, I can safely use all/all in the ME entry and not worry about trying to download an entire Usenet feed at 14.4kbps.
The sloth entry again specifies my ISP's machine. By putting sloth.swcp.com into the exclusion list, I don't try to send articles back. I created a perrin.* hierarchy for some simple tests; the grouplist entry in my sys file shows I send all newsgroups except perrin up to my ISP. Similarly, articles intended for all distributions (world, usa, nm, whatever) except local are sent up. I will be using batching, and the articles are going to be stored in /var/spool/news/out.going/sloth/togo.
#/var/spool/cron/news 09 * * * * /usr/lib/news/input/newsrun 22 * * * * /usr/lib/news/batch/sendbatches 59 0 * * * /usr/lib/news/expire/doexpire 17 8 * * * /usr/lib/news/maint/newsdaily 05 * * * * /usr/lib/news/maint/newswatch 3000 300 100At 9 minutes past the hour, newsrun takes the batched articles delivered by UUCP, unpacks them, and stores them into the news spool.
At 22 minutes past every hour, sendbatches takes the outgoing articles, batches and compresses them, and delivers them to the UUCP spool for uploading. These files will be transferred whenever the next UUCP connection takes place, so su to uucp and edit the crontab, as you did with mail.
At 12:59 AM, doexpire takes care of expiring old articles.
Every morning at 8:17, newsdaily tidies up some of the various log files and sends mail to the news admin if something is amiss.
At 5 minutes past the hour, newswatch takes a look at the system to see if there are any problems. Stale locks, full disks, and the like are reported to the newsadmin.
su news -c "/usr/lib/news/maint/newsboot"onto the end of my rc.sysinit file.
cnewsdo addgroup my-site.test yand post to it. If you made readpostcheck you can do this with the postnews package. Look in NEWSARTS/in.coming and you should see the article, with header information thoughtfully provided by postnews. Leave the computer room and share some time with your family until after newsrun executes again. Now, your article should have appeared in NEWSARTS/my-site/test and should also have entries in the history and log files in NEWSCTL. If you installed readpostcheck, use readnews -n my-site.test and you should see your message. Pat yourself on the back; you've got yourself a Netnews site.
news.group.name highest lowest perms:Highest and lowest are the upper and lower bounds of available articles in news.group.name. For setting up, set highest to 00000000 and lowest to 00001. To save time, C News never updates the lowest value, so if your newsreader (such as trn) looks at lowest, you will need to set up a crontab entry to run updatemin from time to time. The relevant perameterss are y: users can post to the group; n: users can read but not post; m: the newsgroup is moderated. Posts to this newsgroup will actually be sent to the moderator address specified in the $NEWSCTL/mailpaths.
As news comes in, C News will continually update the active file. Here's a snippet of mine:
alt.tv.homicide 0000000002 00001 y alt.tv.nypd-blue 0000000010 00001 y comp.os.linux.announce 0000000009 00001 m comp.os.linux.misc 0000000504 00001 y linux.dev.kernel 0000000048 00001 y rec.arts.sf.written.robert-jordan 00033 00001 y rec.arts.tv 0000000334 00001 y swcp.test 0000000005 00005 yIn addition to ``real'' newsgroups, you should also have groups for control, junk, to.feed-site and to.my-site.
This file can be maintained by hand or by using addgroup and delgroup. Second Warning: do not send newgroup or rmgroup messages; these commands create groups for all of Usenet and are not for the likes of us mortals. As much as you might want to newgroup alt.fan.back-hair on your own initiative, procedures exist for creating new Usenet groups and violating them is a good way to find yourself unpopular.
Something I noticed after a day or three of running C News: control messages were responsible for about 80% of my news spool. To cut back on disk space, I had my ISP remove control from the list of groups he was feeding me. I can no longer receive newgroups, rmgroups or cancels, but it's worth it to save disk space. Forty non-binary newsgroups, most low-traffic, were eating up nearly 8MB of my disk spool after only three or days. Multiply that by the control-group factor of five and you can see why my poor 50MB spool can't afford control messages. Make sure your ISP still accepts control from you, however, as you might need to cancel a stupid question or hastily-posted flame someday.
Jim Hill is a graduate assistant at Los Alamos National Lab who has been playing with Linux since somewhere in the .99 kernel series. Armed with total ignorance of the topic of this article, he set out to learn a little something and maybe help somebody else. Thanks to Mark Costlow at Southwest Cyberport (cheeks@swcp.com), without whose help and patience this article would have read ``It doesn't work; it can't be done.''
