Wanted: Intelligent getty program for SYS V
Leslie Mikesell
les at chinet.chi.il.us
Tue Dec 13 09:35:22 AEST 1988
In article <822 at kimbal.UUCP> rick at kimbal.UUCP (Rick Kimball) writes:
>I'm in search of the source code to an intelligent getty.
>Before I run off half-cocked and write my own, I thought
>I'd query the net to see if someone has already done it.
I started to work on something like this a few months ago but haven't
had time to do much (and it doesn't look good for the near future either).
>Have I missed anything? I'm aware of "uutty" and it's
>almost exactly what I want. But ...
I think you have the right ideas. My main problems with the normal
getty/uugetty are:
1) Poor support for multiple speed modems.
2) Slow login when the passwd file is large.
3) No logfile.
One of the machines I work with handles a live database of agricultural
market information on a subscription basis. It is accessed by a large
number of fairly non-technical users who want to log in quickly, make
their requests and log off. Making getty also handle the login process
should speed things up, especially if it could use a hash table to
index the names (followed by a linear scan if the hash file happens to
be out of date). The usual getty-type speed change (send a break, wait
a while, ad infinitum) is pretty annoying also, considering that the
modem tells you what speed it is going to use. The logfile information
that I would like to see (only if the login fails) is every character
that was sent to the getty/login program and the date and time of the
call. We have run across things like terminals (or emulators) that
send CR/LF/NULL when you hit return or XOFF/XON after each line. The
current solution is to hook up a monitor terminal, which is difficult
because the inbound lines are on a roll-over and the subscribers often
don't have a second line to talk during the call. A decent logfile would
make problem-solving much easier.
> o Provide dial in/out on same line.
> Probably what I need is a wrapper proram that
> will work with uucp, cu, etc... It could
> communicate with the getty program and let it know
> when to stop and start.
The HDB uucp style locking and uugetty work pretty well.
Les Mikesell
More information about the Comp.unix.wizards
mailing list