AUTO option in /etc/gettydefs
Mark Delany
MDelany at hbapn1.prime.com
Wed Dec 27 14:43:13 AEST 1989
From: Mark Delany <mdelany at hbapn1.prime.com>
To: <info-unix at sem.brl.mil>
Date: 27 Dec 1989 (14:31)
Subject: AUTO option in /etc/gettydefs
>
> From: David Ward <dward at runxtsa.runx.oz.au>
> Subject: AUTO option in /etc/gettydefs
>
> I am experimenting with the AUTO option in the /etc/gettydefs, and cannot
> seem to be getting it to work. Does it work ??????
>
Well it works for the XENIX version I'm running (2.3.1), you didn't
mention your version, so possibly it could be a bug in your release
but...
> Please don't tell me that I should use this as I makes for poor security,
> because I know this. But I have some clients that don't have a modem and
> don't won't to have to use the login.
>
> The problem is getting the getty :-) to recognise the login name. I've tried
>
> # AUTO /etc/login logname
> # logname AUTO
> # AUTO logname
> logname # AUTO
> logname # m # AUTO
>
> but either get errors or the terminal hangs running 'login'.
... David, I presume that you've created a user with an ID that matches
the device name of the line in question (eg tty3a or whatever)?
As far as I can tell, all that AUTO does for you is to use the device name
as an automatic response to getty's login prompt. (Also, I don't think
that you can over-ride the device name ID with an entry in the gettydefs
file, as your sample gettydefs entries suggests.)
What happens next depends on the login prog and /etc/passwd.
To illustrate, I have entries for some of the multiscreens (tty02, tty03,
tty04 etc) and the user ID has been created sans password so that the
screens automagically log in at boot time. Beat that for poor security!
Mind you, on a portable 386 I find that a night-stick provides better
security than a password :-)
It may be of interest to you that the XENIX System Admin Guide (pp 14-10)
claims that defining a login-program in gettydefs is unique to XENIX. I
have no idea whether this is true or not, but if it is, you may want to
avoid portability problems by using .profile/.login as a vehicle for start
the users script.
Regards,
Mark D.
More information about the Comp.unix.questions
mailing list