Hardware

Red Hat's 6.1 covert action bug alerts (or remember the errata)

Out of the box, Red Hat Linux 6.1 contains several bugs. Red Hat's errata page contains the necessary fixes, and Jack Wallen, Jr.'s here to describe a couple of those fixes in detail.

It caught me by surprise. After I took the frightening initiative of upgrading my main machine from Red Hat 6.0 to 6.1, it seemed that all was going well... until it happened. At first it was just the annoying little bother of hearing my loud-as-thunder external modem (on the first serial port) run through the connection sequence twice every time that I wanted to connect. Not a joy, but tolerable. I could live with this little bug. I was sure that Red Hat would come out with a fix soon enough. Unfortunately, it didn't end with this little bug. There were more little bugs that sent me into a handspring realization: always check the errata!

What are the errata?
The Red Hat errata contain the most recent information about important updates, fixes, and corrections for Red Hat Linux. On this site, you can find all of the necessary updates and fixes to secure and fix anything from Red Hat 4.0 to 6.1. Many of the priority updates are for security purposes, some are bug fixes (my focus here), and some are package updates.

Why use the errata?
Throughout Red Hat's history, users have looked to the errata to keep their Linux machines running securely and with stability (with a primary emphasis on security). Lately, however, with the release of 6.1, the focus has switched to making the distribution work. Out-of-the-box Red Hat 6.1 has a few key features that are broken, and some applications contain security holes: specifically, lpr (line printer daemon), the rp3 dial up tool, bind, initscripts, ypserv, wu-ftpd, screen, and pam. It’s crucial that these packages be updated as soon as possible.

Let's look at some of the more annoying bugs that are fixed on the Red Hat errata.

Red Hat dial up tool
After about a week of hearing my modem scream, things took a turn for the worse, and Red Hat 6.1 hosed my modem connection. Historically, I connected my modem to my ISP with either the netcfg tool or the /sbin/ifup comand without fail. With the release of 6.1, Red Hat Linux decided to change the favored method of connecting a dial up from the ifcfg-ppp tool to the WvDial dialup tool. Anyone who was used to configuring a modem with netcfg, linuxconf, or netconf was out of luck. Not only did Red Hat change the tool, but the tool that it now deploys (rp3) is broken out-of-the-box.

The primary indicators that your currently working dial-up connection is about to fall-down-go-boom are:
  • The modem dials twice to make connection
  • The modem connection doesn’t break completely on disconnect (a problem that’s simple to discern with an external modem)
  • The modem doesn’t make a connection at all

The above steps to dial-up Armageddon took place within a week’s time and came completely without warning. Looking into the issue brought about a rather interesting development, which led to a severe loss of sleep and social life. Fortunately, my diligence paid off, and I now bring you one solution (that will, more than likely, be the first of many) to this rather frustrating problem.

The first step in solving this issue is to re-think the way you go about setting up a dial-up connection. Until now, the standard method took one of two courses:
  • GUI with either netcfg or linuxconf
  • Text base configuration of chat and chap scripts

The GUI applications were nothing more than front ends that handled the configuration of the necessary scripts (chat, chap, chap-secrets, etc). In this respect, things have not changed.

The Red Hat PPP Dialer application is merely a front end that configures the proper scripts. However, the involved scripts are different, and the front end (nicknamed rp3) doesn't handle the writing of these scripts correctly. Your only recourse is to make the upgrades to the latest rp3 and PPP packages and to do a bit of script hacking.

First things first. IT’S CRITICAL THAT YOU MAKE THESE UPDATES BEFORE YOU CONFIGURE YOUR CONNECTION. Before you start the rp3 application, there are two updates that you need in order to get things rolling.
The first update is for the rp3 tool itself .
The second update is for the PPP application .

As the rp3 update states, “When users attempted to add a new modem in the PPP Configuration Tool (the rp3-config program), rp3-config died of a segmentation violation. Also, already-existing PPP configurations could confuse rp3-config; it would try to edit them as if it had set them up in the first place, causing those configurations to quit working.”

The PPP update states: “A subtle bug in pppd showed up more often in the Red Hat Linux environment than other environments, causing pppd to dial twice when trying to bring up a PPP connection. Running ‘modprobe ppp’ before bringing up the connection causes the problem to happen only once until reboot. The real fix is this new version of pppd, ppp-2.3.10-3.”

With these two packages installed, you’re ready to begin the process of setting up the dial-up connection.

With the help of the Dialup Configuration Tool (executable from the GNOME main menu or from the command line by typing rp3-config), you’ll enter simple information in order to set up your ISP connection. Necessary information includes:
  • Modem device and baud rate; both are auto-detected but can be user-configured
  • User-defined account name
  • Phone number for ISP
  • User name and password for the account

Setting up an account with the Red Hat Dialup Configuration Tool is simple and user-friendly. The biggest problem occurs when, as one of the bug fixes states, “Also, already-existing PPP configurations could confuse rp3-config. This point is where starting from a clean slate will save you from hours upon hours of frustrated re-writing of the wvdial.conf script. (In fact, after I spent many hours in frustration, it took a complete re-install and re-update for the rp3 dialer tool to work properly.)

The wvdial.conf script is the file that the new rp3 application uses for all of the configuration settings. The wvdial.conf file is broken into sections (much like the smb.conf file) and is set up like a Windows ini file: variable = value.

A sample wvdial.conf section will look something like:
[Dialer Defaults]
Modem = /dev/ttyS2
Baud = 57600
Init = ATZ
Init2 = AT S11=50
Phone = 555-4242
Username = chumpzilla
Password = mechagodzilla
[Dialer phone2]
Phone = 555-4243
[Dialer shh]
Init3 = ATM0
[Dialer pulse]
Dial Command = ATDP

What is most unique about this application is its ability to use the same tool and the same command (with various arguments) to call up different dial ups or even the same dial ups with different configurations. Say, for example, that you want to call up your default connection as-is in one instance and in the next you want to use a different initialization string. It's possible. A quick examination of the above wvdial.conf file shows us a simple setup with a default configuration:
[Dialer Defaults]
Modem = /dev/ttyS2
Baud = 57600
Init = ATZ
Init2 = AT S11=50
Phone = 555-4242
Username = chumpzilla
Password = mechagodzilla


This configuration will be used when the command wvdial is called without arguments. This particular section, Defaults, will dial out through the modem that’s connected to /dev/ttyS0 (com 1) and that has an initialization string of ATZ, a phone number of 555-4242, the username of chumpzilla, and a password of mechagodzilla.

Let's say, however, that you use two different ISP's (both having the same username and password). In order to dial the second ISP, you would call the wvdial command with wvdial phone2, which would use all the default arguments but would override the phone number (hence connecting to a different ISP).

The next example shows you the flexibility of the wvdial tool. Let's say that you want to connect to your ISP but that (for some odd reason) you don't want to hear the siren sound of the modem. With the above wvdial.conf file, you’d simply have to run the command wvdial shh, which would override the default initialization string, with ATM0, and would keep the modem silent.

The final example from the above wvdial.conf file allows you to switch from tone to pulse dialing (which is helpful because laptops move from dial-type to dial-type). When wvdial pulse is run, the default initialization string is over-ridden with ATDP, and the dial-type is switched to pulse.

The wvdial isn’t limited to these examples—man wvdial will enlighten you even further.

Although the configuration frustrations were running rampant, once wvdial (and the rp3 application) were configured and working, Red Hat 6.1's dial up capability was shown to be much more flexible and powerful than its previous incarnations were. Use a bit of caution and patience. The rewards are worth the time that you'll put into learning wvdial.

Printing woes
The next major broken tool to come out of Red Hat 6.1's box is lpr. The problem with the out-of-the-box lpr is twofold. The first problem exploits a race between the access check and the actual file that’s opening; lpr reads a file that the user doesn’t have access to as root. The second problem is that lpr blindly opens queue files as root so that the user can print files that are owned by root.

The solution to the 6.1 lpr problem doesn’t stop with the mere upgrade of the lpr rpm. Local printing was broken due to a missing alias in the /etc/conf.modules file. The /etc/conf.modules file sets up aliases for much of the often-interchangeable hardware (sound cards, Ethernet cards, modems) and must have the following entry for local printing to work:
alias parport_lowlevel parport_pc

Once this entry is in place, restart the lpd (from printtool, click the lpd drop-down and click Restart or, from the command line, run /usr/sbin/lpd &). Then, run a test print. (Again, printtool allows for this action.)

The two bug fixes are the most notable requirements for the Red Hat 6.1 release. There are, however, a few security fixes to note: bind, initscripts, ypserv, wu-ftpd, screen, and pam. Each of these patches should be put into place for security purposes, and they’re described on the errata page.

The errata page is a necessity for anyone who deals with the Red Hat Linux distribution. As each release is refined and re-examined, more patches, bug fixes, and security fixes are added. The errata page should be on every Red Hat Linux user’s main bookmark (or wget cron job) to keep the user and the community abreast of the latest, greatest updates to Red Hat Linux. As each new release comes out, the Linux community should see fewer and fewer instances on the errata page. However, knowing the persistence of the avid Linux fan, the stringent developer ethics of Red Hat, and the history of Linux, the bug and security patches will be forthcoming forever in an attempt to keep Red Hat on the edge of the computing revolution.

Keep your eyes focused here on TechProGuild. We’ll bring you more and more updates as the patches and fixes are posted.

Jack Wallen, Jr. is very pleased to have joined the TechRepublic staff as Editor in Chief of Linux content. Jack was thrown out of the "Window" back in 1995, when he grew tired of the "blue screen of death" and realized that "computing does not equal rebooting."

Prior to Jack's head-first dive into the computer industry, he was a professional actor, with film, TV, and Broadway credits. Now, Jack is content with his new position of Linux Evangelist. Ladies and gentlemen—the poster boy for the Linux Generation!

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

0 comments

Editor's Picks