John, I am not sure that I even want to get into this "flay" but some
comments about my own observations with the issue are:
Some ISPs using CHAP present the "username"/"password" sort of thing (of
course "username:" might be something else like "login:", "account:", etc.
but actually don't use them for ppp logins. If the script "wakes up
getty" on such systems, a ppp login attempt will fail.
I personally am trying to play around with the multiple ISP problem here
and while in principle it ought to be "trivial" it is proving to be
anything but! I believe that in part, a problem is that it is not at all
clear "who is doing what with whom (and which whom)" as far the files are
concerned when trying to use such things as xisp or dunc and the like.
Inasmuch as hamm seems to create the "/etc/ppp/peer" directory and the
"etc/chatscripts/provider" file, I would suggest that any user
configuration tool default to naming the "provider" files with name
related to the users input thus in effect making the existing "provider"
files "example" files. "pon" itself seems only to lack the ability to
accept either an arguement (which might be a security problem) or a
"choice" which should not be a problem. I am strongly in favor of the
idea that "pon" should be setup to use "named" provider files and never
use a file actually named "provider" (of course this is an "issue" with
the maintainer of that package and not you). I believe that if the
pacakge configuration for pon worked that way, it would be much more
obvious to the "sysadm" how the system works and what changes need to be
made to enable other ISPs.
I also feel as though the whole process, as it currently exists (in bo),
of setting up an ISP connection is horribly messy. It seems like some
options and parameters are "stuffed" into unlikely places (and often
duplicated). I am pretty sure that this is at least in part due to
several different "philosophies" about how to establish a connection all
in use "at the same time" as well as evolution occurring in the
fundamental software used for the process (pppd changes probably being the
most significant influence). In addition the existing documentation that
the individual is likely to encounter that deals with setting up just ONE
ISP much less multiple, conflicts on how to go about the process.
It looks to me as if the latest version of ppp provides for the solution
of the options file problem in a clean manner as long as the pppd
developers remain consistant in their default settings for future
upgrades.
As I am sure that you are aware; this really is a _SERIOUS_ problem for
Linux in general and is anything but a trivial one for you to solve. New
user perception is likely to be that "getting on-line" should be a simple
matter--after all to get onto AOL, Worldnet, <fill in the blank> is just a
simple matter of answering a few simple questions and letting the software
take care of everything else."
I doubt that most people starting off with Linux have any idea of just how
difficult it is to obtain some of the critical information that is "built
into" these custom ISP "sign up programs".
I don't know your own priorities but suggest that ALL connection methods
be considered for eventual inclusion in your setup software, even slip.
Again, it is a bit presumptive for any of us to assume that something like
slip will not be the "critical factor" for someone new wishing to use
Debian Linux. I do agree that the priority for something like that should
be lower than trying to make it "nearly foolproof" to connect to a "main
line" ISP.
best,
-bill
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
-->Please note [EMAIL PROTECTED] does not work<--
-->nor does <anyone>@<anyhost>.wconsult.com<--
==>and yes eventually I'll get the mailer figured out<==
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
See! They do get some things right!
On 7 Dec 1997 [EMAIL PROTECTED] wrote:
> Richard G. Roberto writes:
> > This was supposed to be as generally useful to as many people as
> > possible.
>
> Yes. And the most generally useful thing to do for the most people is to
> make it easy for them to get a single connection working so that they can
> email for help and ftp files.
>
> > It was originally suppose to support slip and diald as well, but I never
> > had the chance to get that part developed.
>
> I see no urgent need to add slip support. Diald may become obsolete when
> demand-dialing is debugged, but I think it should have its own config
> utility anyway.
> ... [much relevent info snipped]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
