Setting Up UUCP
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.rpm
To 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 perrin
The 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-6789
The 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 generic
The 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 ATM0DTT CONNECT chat-fail BUSY chat-fail ERROR chat-fail VOICE chat-fail NOsCARRIER chat-fail NOsANSWER chat-fail NOsDIALTONEThe 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.]
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
2 hours 42 min ago
- Not only you I too assumed
3 hours 17 sec ago
- another very interesting
4 hours 53 min ago
- Reply to comment | Linux Journal
6 hours 46 min ago
- Reply to comment | Linux Journal
13 hours 40 min ago
- Reply to comment | Linux Journal
13 hours 56 min ago
- Favorite (and easily brute-forced) pw's
15 hours 48 min ago
- Have you tried Boxen? It's a
21 hours 40 min ago
- seo services in india
1 day 2 hours ago
- For KDE install kio-mtp
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?