Date: Wed, 5 Feb 1997 15:35:54 +1100 From: davidn@labs.usn.blaze.net.au (David Nugent) To: terry@lambert.org (Terry Lambert) Cc: freebsd-current@freebsd.org Subject: Re: getty patches Message-ID: <19970205153554.HM65449@labs.usn.blaze.net.au> In-Reply-To: <199702050233.TAA13904@phaeton.artisoft.com>; from Terry Lambert on Feb 4, 1997 19:33:58 -0700 References: <19970203132504.RZ25585@usn.blaze.net.au> <199702050233.TAA13904@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > If the init chat fails, it logs via syslog and exits. There is no > > other sane thing to do. > > So is the initd expected to say "getty repeating too quickly on > port %s, sleeping" for this? If GETTY_SPACING in init.c was to be increased from 5 seconds, yes. But this may have undesirable side-effects, and I'm not sure if I'd want this behaviour in any case. > It seems that the current getty isn't expected to fail this way, > but the modified getty might. The "modified getty" won't act any differently from the existing getty until and unless it is configured to act differently. > Waiting an average of 5 minutes for a login when this happens (while > initd is busy sleeping it off) seems a bad thing. ? > Right. I guess I was really asking "why does a modem need to be > initialized again if it was already initialized? Does initialization > (somehow) 'wear off'?". No of course not, modems can often have problems related to heat and other conditions, including buggy code. > It seems silly to do this, but there might be a perfectly valid > reason for it, which I don't see, but which you can now tell me. 8-). The point isn't simply to initialise the modem. The point is to see that it is still functioning correctly - and yes, they do sometimes have problems - and when they do, it is a Good Thing if the sysadmin has early notification if the simple act of dropping DTR by recycling getty does not work. If you've ever run a dialup system on a rotary, a single line going out early in the group causes problems for all users attempting to dial in. If your modems don't happen to have problems like this (well, we can all be optimists, right?), well and good - you don't need to do this, so don't. > > No, it doesn't. Since I've been doing most of the login.conf work, > > I can't see how it would. Login classes can't be activated until > > after a user logs in, and the issue file is sent before getty > > prompts for a login name. > > I thought different transports could be given different classes > in the BSDI implementation. No. This is seen as a "service" to the authenticator. Login classes may have different combinations of service/authenticator values, but which ones are valid are still driven by the user's login class. > If the BSDI version isn't the design, that's fine (I guess). > If the BSDI version can't do it, then it's "generically fine". 8-). It appears that you simply misunderstand how it works. The manpages are there if you're interested, although login_auth(3) is a little thin right now. :-) > > > I also find it alarming to allow the open to succeed without a > > > call being present... how do I use the same modem port for > > > outbound traffic? > > > > You don't use this feature. > > Uh... yeah, I do. I only have one modem. 8-). What's your point? > > Any way you like, Terry. If you don't wish to use the inbound call > > features, then don't. That's why it is optional. :-) A blocking > > open() is still done unless you enable the "ac" capability. > > Ah. I see. So I can use the same modem inbound vs. outbound, > as long as I turn this feature off. "Unless you enable it in the first place" is a more accurate picture. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970205153554.HM65449>