On Wed, 30 Oct 1996, Jukka Marin wrote:

> I have an enhanced getty (based on the standard NetBSD getty) which has two
> new features: It can initialize a modem when getty first starts up and it
> can perform a callback operation.

The modem init stuff was actually something that I was thinking
about, since when I was debugging I happened to get the modem
disagreeing with getty about the speed. That tends to open a bit
of a rat's nest, however, because you have to decide how much modem
functionality you really want. Is it satisfactory just to open the
modem and send it a string? Or do you want to do an send-expect
sequence? If the latter, what do you do if the S-E sequence fails?
Error out? Continue? Make it configurable? (My instinct would be
to do it like Portmasters do: an S-E sequence where each commmand
gets retried a few times if the expected response doesn't come
back, and then just give up and continue if you don't get your
expected responses after a few tries. This could be implemented
with a new option in gettytab.)

I'm not sure what the point of the dialback is if the user actually
logs in and runs a program that does the dialback. After all, the
whole point generally is that security is increased because the
user can't get a shell or any other access until after the dialback.
Although if the call is a toll call, I suppose it makes some sense
as one can reverse the charges this way. Regardless, that really
seems to me to be heading toward the realm of mgetty. (I originally
wrote my patch because it was faster to write than to figure out
how to install mgetty and work out all the options, and I just
didn't want mgetty doing a lot of the stuff it wants to do.)

I think what's really necessary, at this point, is some direction
from core on what they want to commit in terms of an improved getty,
if anything. I think the indications from the NetBSD user community
so far are that:

a) we should add locking to getty;

b) we should be able to call it uugetty, and have the locking happen,
and we should also have a command line option (-u or -l?) for it that
will make it lock regardless of the name.

It occurs to me, however, that if we're going to add this sort of
thing to getty, perhaps now is the time to add a lockpid() or
similar function to the standard library that performs a lock of
this sort, and modify getty and pppd to use it. (I'd say modify
uucp as well, except that it's imported source.) My suggested
prototype would be lockpid(char *file, int type), where _type_
would be one of LOCKPID_BINARY or LOCKPID_ASCII to use a binary or
ASCII PID written to the file, respectively. (And perhaps add a
LOCKPID_NONE for those applications that want a lockfile not
associated with a particular process. Perhaps we shouldn't even be
calling it lockpid().)

I will be happy to do this and integrate whatever folks think is
appropriate, assuming someone's going to commit it.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.