(Incoherant summary follows...)
The problem seems to relate to a number of problems the Enhanced Security
subset is having with relation to the /etc/auth/system/ttys file
(see man ttys(4) for details). The quick fix I used was to generate
entries for each and every tty (using a short script - attached).
This should work, but possibly only for a while. This will depend on
how successful the Dec patches to Enhanced security are. Indeed, I
experienced the same problem again today, but this was straight
after my machine decieded to reboot itself, and this could be the cause
of the corrupted ttys file (it isn't my week...). Enhanced Security patches
from Dec have been installed. Some people claim that this fixed their
problems (corrupt ttys files etc.). Others claim that all the patches
available from Dec won't solve the problems.
From what I can gather from the replies I have received, there are a number
of bugs in C2 that will corrupt the /etc/auth/system/ttys file. Another
problem is with wildcard entries in this file, being that occasionally
OSF will clobber the ttys(4) file, including the wildcard entry, and
noone (not even root - another bug) will be able to log on unless they
happen to get a valid tty. One quick fix I received for this problem is a
short script, run from cron regularly, that fixes it up. Not at all nice,
but I can't think of a better way to do it. (Perhaps I could write a short
script to replace telnetd & rlogind which will add the wildcard entry if
missing, and then run the actual daemon...)
I havn't been able to run any tests to verify the wildcard bug, as the
only Alpha around in almost constant use and the lecturers/students
around here have been annoyed enough :-). I do know that MY ttys file
didn't have a wildcard entry, and neither did the other Alpha on campus.
authchk does not complain if there is a wildcard entry in devassign, and
NOT in ttys. Nor does it complain if the wildcard entry IS in ttys. There
is no mention of wildcard entrys in ttys(4), only in devassign(4). If
wildcard entries are NOT supposed to go in /etc/auth/system/ttys, then
MAKEDEV should add valid entries, which it doesn't.
My original post:
> From: "Stuart 'Zen' Bishop" <zen_at_bf.rmit.edu.au>
> Subject: Cannont obtain database information for terminal blah-process limit?
>
> (The SCSI tape drive problem is temporarily on hold for those interested
> until this one is fixed)
>
> Currently, when I have between 40 and 80 users logged onto our
> Alpha 2100 A500 running OSF/1 3.0 + C2, users will start getting the
> error message when logging in with telnet and rlogin:
>
> cannot obtain database information for terminal ttyr2
>
> The terminal will change. This message, in the early stages of the problem,
> will occur after the user has entered their login name. A short while
> later, users will not even get a chace to enter their user name.
> I'm hitting some sort of limit, but I don't know what. Perhaps number
> of processes? Number of processes owned by root?
>
> MAXUSERS is set in the kernal configuration file to 738. I have created
> as many pseudo terminals as possible. I know this is overkill, but it
> was a possible solution to the problem.
>
> Has anyone noticed similar behaviour?
>
> I've talked to dec support, and I am currently waiting on some security
> patches the guy at digital thinks might help. The other suggestion, which
> I will be doing, is to enable the auditing system so I can track down
> where things are failing. uerf is not logging anything relevant. Neither
> is syslog.
From: Lau Bee Leong <ccelaubl_at_cobra.nus.sg>
> We had this problem last time when we turned on Enhanced
> Security too. The cause of the problem was due to the corruption
> of the /etc/auth/system/ttys file. Maybe you can take a look at
> that file to see if you an entry for each of your terminal, or
> whether you have the generic line:
> *:t_devname=*:chkent:
>
> Hope this helps.
>
> Lau Bee Leong
> Computer Center
> National University of Singapore
From: "Richard L Jackson Jr" <rjackson_at_portal.gmu.edu>
> The problem is with the poorly designed C2 Enhanced Security databases.
> In particular, /etc/auth/system/ttys is completely re-written every time a
> person does something with a port. Sometimes the file becomes corrupt,
> sometimes the attempt to modify the file, during the login process,
> times out. It has nothing to do with MAXUSERS.
>
> Oh, A simple answer also is to make sure you have ttys and devassign
> entries for ttyr2 in /etc/auth/system/.
>
> --
> Regards,
> Richard Jackson George Mason University
> UNIX Systems Engineer UCIS / ISO
> Computer Systems Engineering
From: Spider Boardman <spider_at_Orb.Nashua.NH.US>
> There are patches available from DEC for this. If the ones you
> get from the CSC aren't recent enough, they may not do the job,
> but Corporate Support (here in Nashua, NH) does have a patch that
> will help. (This involves a fix around corruption of the
> /etc/auth/system/ttys file.)
>
> --
> Spider Boardman (at home) spider_at_Orb.Nashua.NH.US
> The management (my cats) made me say this ...!decvax!orb!spider
From: David Brady <dave_at_lynx.dac.neu.edu>
> It's a C2 bug. What's happening is that there is a file
> /etc/auth/system/ttys, which contains an entry for each tty, giving
> their immediate login history.
>
> This file also contains a wildcard line, which gives the system a
> format to follow whenever a terminal's entry is updated.
>
> Every once in a while the system will clobber that wildcard line, and
> all entries save a few. You then get that error message. No one
> (including the console) can login.
>
> I have the patches DEC wrote to fix that problem, (and some others).
> It didn't work for me.
>
> I have a perl script that I wrote to take care of the problem, through
> a cron job. If you like, I can mail it to you.
>
> ====================================================================
> Dave Brady Phone: 617-373-4579
> Sr Systems Programmer FAX: 617-373-8600
> Division of Academic Computing Internet: dave_at_lynx.neu.edu
> Northeastern University BITNET: dave%lynx.neu.edu_at_cunyvm
> Boston, MA 02115
> ====================================================================
And Dave Brady's Repair script:
=-=-=-=-=-=-=-=-=-= >8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl
# ----------------------------------------------------------------------
# check_tty.pl
#
# This script will make sure the necessary wildcard line exists in the C2
# ttys file, and will fix the file if the line does not exist.
#
# Dave Brady 10/28/94
# ----------------------------------------------------------------------
$ttys = "/etc/auth/system/ttys";
# Load up the ttys file into an array
open(TTYS, "+>> $ttys") || die "Couldn't open the ttys file: $!\n";
_at_lines = <TTYS>;
# Look for the required wildcard line (needed to log activity
# on the ttys; without it, no one can log in. The error message:
#
# Cannot obtain database information on this terminal
#
# will appear if this line isn't present.)
# If it's not there, insert it.
# The ? delimiting the pattern in the grep statement causes
# the search to stop after the first match.
if (! grep(?^\*:t_devname=\*:chkent:?, _at_lines)) {
print TTYS "*:t_devname=*:chkent:\n";
}
close(TTYS);
=-=-=-=-=-=-=-=-=-= >8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My script for generating entries for /etc/auth/system/ttys:
=-=-=-=-=-=-=-=-=-= >8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/local/bin/perl -w
# This script will generate dummy ttys(4) entries for all tty's.
# You just need to then delete all of the existing entries in
# /etc/auth/ttys and copy the output of this program into it.
open(BLAH,'ls -1 /dev/tty??|');
while(<BLAH>) {
chop;
s|/dev/||;
print <<"EOM"
$_:t_devname=$_:t_uid=root:t_logtime#794702693:t_unsuctime#794701631:chkent:
EOM
}
=-=-=-=-=-=-=-=-=-= >8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
__END__
_____
// // __ For a good time call
http://www.bf.rmit.edu.au/~zen //
// / \ I\ I zen_at_bf.rmit.edu.au //
// (-- I \I Unix Systems Administrator //
// \__/ I I alias Stuart Bishop Business Faculty, RMIT //
((_______________________________________________________________________//
Received on Thu Mar 16 1995 - 01:14:49 NZDT