schweigl@edvvie.at (Johnny Schweigl) (11/22/90)
We are currently encountering a major problem with no idea how to solve it. Machine configuration is as follows: Hardware: COMPAQ Systempro two 386/33 CPU boards 12 MB mem 1.6 GB Disk, configured for data guarding 3COM Etherlink II network adapter Adaptec SCSI controller GIGATAPE DAT streamer SCO UNIPATH SDLC comms board Computone controller with 1 Async feature box attached Software: SCO UNIX 3.2 Runtime TCP/IP 1.1.1 Runtime SCO (Corollary) MPX COMPAQ EISA supplement Operating environment: Machine serves as time accounting system with industrial terminals connected via RS232. Users (>25) telnet from WANG VS (great, BTW) to SCO box, using accounting software. 32 pty's are configured into the kernel (maximum allowed by TCP/IP). C2 security mode is relaxed (from sysadmsh). Error: After entering userid and passwd (telnet session is ok) SCO UNIX responds with "Cannot obtain database information on this terminal". when logging on as root on /dev/console, the system tells me that "The security databases are corrupt". No new logins are allowed after this error had occured. The error seems to have no systematic behaviour. It appears at random points in time, with 3 telnet sessions or 20, or something like that. RTFM: SCO TCP/IP release notes predict this error if pty's and vty's are not correctly configured. Nope. As far as I can see I did it right. Simply followed the instructions in the manual. No further reference to this error in the complete runtime docs. Also, the TCP/IP manual says, that if streams ressources are insufficient, unpredictable errors. Possible sources of error: Someone modified /etc/passwd manually. System will be reinstalled completely this weekend. If this was the only problem, shouldn't the error occur permanently? Quite contrary, it is not reproducible. Actions taken so far: Analyzed streams ressource usage with crash and strstat subcommand, reconfigured kernel. Should now be sufficient. Ran a brute force test with 32 concurrent telnets and some parallel ftp's. Error did not occur. Next day, error occured 8 times. One day later 3 times, and so on ... Problem: Angry users wanting to tear our heads off. So if you know any solution, or if this is a known error, corrected in release x.y.z pleeeaaase tell me. Thanks in advance, -- This does not reflect the | Johnny Schweigl opinions of my employer. | USENET: schweigl@edvvie.at I am busy enough by talking | about my own ... | EDVG Vienna/Europe, Tel (+43 222) 59907-0
ralfi@pemstgt.PEM-Stuttgart.de (Ralf Holighaus) (12/02/90)
schweigl@edvvie.at (Johnny Schweigl) writes: >Error: > After entering userid and passwd (telnet session is ok) SCO UNIX > responds with "Cannot obtain database information on this terminal". > when logging on as root on /dev/console, the system tells me that > "The security databases are corrupt". No new logins are allowed after > this error had occured. > The error seems to have no systematic behaviour. It appears at random > points in time, with 3 telnet sessions or 20, or something like that. >Possible sources of error: > Someone modified /etc/passwd manually. System will be reinstalled > completely this weekend. If this was the only problem, shouldn't the > error occur permanently? Quite contrary, it is not reproducible. Do you have any software installed on your system which maybe changes either /etc/passwd or /etc/group directly? We had a problem with some database software which behaved like that and therefore had to reinstall the entire system! Rgds Ralf -- Programmentwicklung fuer Microcomputer | Ralf U. Holighaus PO-Box 810165 Vaihinger Strasse 49 | >> PEM Support << D-7000 Stuttgart 80 West Germany | holighaus@pemstgt.PEM-Stuttgart.de VOICE: x49-711-713045 FAX: x49-721-713047 | ..!unido!pemstgt!ralfi
mju@mudos.ann-arbor.mi.us (Marc Unangst) (12/05/90)
schweigl@edvvie.at (Johnny Schweigl) writes: > Error: > After entering userid and passwd (telnet session is ok) SCO UNIX > responds with "Cannot obtain database information on this terminal". > when logging on as root on /dev/console, the system tells me that > "The security databases are corrupt". No new logins are allowed after > this error had occured. > The error seems to have no systematic behaviour. It appears at random > points in time, with 3 telnet sessions or 20, or something like that. Check /etc/auth/system for files that begin with "ttys". Like "ttys-t" or "ttys-o". These are lock files that SCO Unix uses when it updates the terminal control database, and SCO Unix will not log you in if ttys-t exists. (I dunno why it doesn't just fork off a background process to update it when the file becomes free, or why it doesn't just say "Terminal database locked; waiting...".) Find the version of the file that looks "rightest" and rename it to ttys, removing the -t and -o versions. Another possibility: You don't have lines in the ttys file for all the pty's. Make sure they're there. > Possible sources of error: > Someone modified /etc/passwd manually. System will be reinstalled > completely this weekend. If this was the only problem, shouldn't the > error occur permanently? Quite contrary, it is not reproducible. This is a possibility, but if this happened, my experience leads me to believe that it would happen ALL the time. Here's something SCO-style for fixing problems with manually-modified /etc/passwd files: KEYWORDS: security passwd /etc/passwd pw_id_map gr_id_map secureware bug RELEASE: All versions of SCO Unix System Vr3.2 PROBLEM: The system replies "Cannot rewrite terminal control database entry; see Authentication Administrator." when I try to log in. Also, the /etc/auth/system/pw_id_map file is missing. SOLUTION: This message probably stems from a manual edit of the /etc/passwd file. If a blank line was inadvertently left in the file (even at the end), this error will occur. Delete this blank line, remove /etc/auth/system/{pw,gr}_id_map, and try to log in again. In this case, the "cannot rewrite..." error message is misleading and should be ignored. Yes, this is a bug. Yes, SecureWare knows about it. No, it's not fixed in r3.2v2.0. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |