Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
User Journal

Journal bittmann's Journal: Annoyances - RedHat 8.0 Dial-up networking 1

Note To Those Who Build System Configuration Scripts: Make Sure What You're Doing Carries Through To The Rest Of The System!

Yes, most of this is my fault for not completely auditing the system that I sent away with my parents. However, I do think that there is something in here that says *something* about the lack of coordination within the RedHat 8.0 install.

Bear with me, here...

Just set up RH8 for my parents. They dug it. Looked good to them, gave them a good, integrated "feel", and did away with most of their complaints about arcane commands/editing config files, etc.

They took it home and set up dial-up-networking themselves (the wizard actually runs well enough that they had the modem configured and DUN up and running on the first try!) However, my folks are hooked on the "Modem Lights" applet that shipped with RH7.x. No demand dial for them! No problem...they added the applet to the panel. Except that, in its default state, it doesn't work.

A phonecall and a couple of "ssh" sessions later, and here's what I found:

1) Modem Lights is (by default) pointing at "ifup" and "ifdown" as the commands to do the dirty deeds--commands which aren't in a base user's path. So for root this ran just fine, but the basic user couldn't use it. Click on Modem Lights, get no error message, no response, no nothing. No problem...I saw that one fairly quickly, and told them to change the path to the commands. It would now dial...

2) But now, it won't disconnect. Grrr...it's pointing at the wrong lockfile, so it doesn't know it's connected, so it doesn't try to disconnect (it wants to connect again!). The Internet Cofiguration Wizard sets up the device to generate a lockfile using the device name (/var/lock/LCK..ttyS0 or some such). Modem Lights by default was looking for /var/lock/LCK..modem). What gets to me is that the hardware detection seemingly created the correct link in the device directory (/dev/modem > /dev/ttyS0). Why the networking setup didn't use /dev/modem (or even /dev/modemn for that matter), along with the appropriate lockfile, I can't fathom.

OK, so we got THAT figured out and changed. But wait, it gets better! Being a parent ("Dad, why did you do that?" "I don't know. I just did."), the next thing that happened was that *somehow* the applet was removed from the panel. So it was put it back--And lo and behold! All of the changes that he made were reset to the default values, losing all of the work we just went through. Now, this may have taken place because he hadn't exited/saved, but then again, I didn't want to risk him losing this data later, so...

No problem, we'll just symlink ifup/down from /usr/local, and change the Networking setup to use /dev/modem. But the next time the networking wizard was run...grrr. Back to the tty device.

So: in a nutshell, here's what I'd like to see fixed:

1) RedHat's configuration of the basic tools/configurators/applets/etc. that they deliver in the base desktop install are not necessarily configured in a compatible fashion. This is frustrating to the adept, and confusing/maddening to the newbie, which doesn't help for user acceptance at all. Audit your system installs, and make certain that all tools/applets/etc. can agree on the basics. If something doesn't, then change it (to use a config file/command-line arguments/whatever) and submit the source back to the author. After all, that's what your value-add is supposed to be: Making things "just work". Otherwise, you're no better than (insert distrubution name here).

2) Some of the apps that RedHat ships don't give the user ANY indication of an error. Again...fix the problem! If all they did was give the user some easy/consistent way to view stdout/stderr, at least he'd get some feedback about what was happening. It's made even more tough to troubleshoot when GDM runs...there isn't even a pseudoterminal that's easy/quick to get to. And no, this didn't appear in the System Log, either. As far as my parents were concerned, they were flying blind.

So: Here's what I suggest.

1) If you're going to support abstract devices, make the configurators abstract the devices in a consistent fashion. Add a number if you have more than one of a given device (/dev/modem and /dev/modem1 instead of /dev/ttyS0 and /dev/ttyS1 or whatever).

2) Make all applications that use these devices default to the lowest-common-denominator abstract device (/dev/mouse or /dev/mice, /dev/modem, /dev/cdrom, etc.). Worst-case scenario: Tell the user that they can add a number if they need to differentiate between devices. But in most cases, the device should select "appropriately".

3) And for pity's sake: Test the system install as a user, not just as root. How RedHat managed to ship something that a user would run (Modem Lights) with a command path that is completely non-functional is beyond me. Imagine how much flack M$ would get if THEY pulled this. Hey--maybe their wizards make things run at the lowest common denominator...but at least they kinda-sorta run, or at least pop up an undecipherable error message or blue screen...they don't just sit there and do NOTHING!

OK. I feel better now. Got *that* off my chest!

This discussion has been archived. No new comments can be posted.

Annoyances - RedHat 8.0 Dial-up networking

Comments Filter:

"A car is just a big purse on wheels." -- Johanna Reynolds

Working...