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.]
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide