I guess not many people using SCO OpenServer, but my office stills running an outdated SCO Unix v5.0.6 to host a legacy system :(
Nobody, especially novice, dares to touch that bloody old “junk”. Luckily, it stills running fine except this harmless (low risk) glitch – slow login password prompt at console, which delays to about a minute after entering login ID.
With reference to SCO technical article, this is a known issue caused by a bug in the bundled telnet server (but surprisingly it affects the console login too) and you might find some of these entries on /usr/adm/syslog:
failed to read terminal control database entry
can’t rewrite terminal control entry
cannot obtain database information on this terminal
To fix it, the official SCO reference suggests to install Release Supplement rs506a or create a shell script to execute
Well, we opt to do nothing at this moment, as long as it running fine until we convert and dismantle it eventually – why bother to fix such a low risk problem encountered on an outdated system that has no secondary support we (administrators) can escalate to?
Note, if it is not caused by bug in telnetd, it could be due to DNS or network-related issues, as noted in this SCO article.
Nobody, especially novice, dares to touch that bloody old “junk”. Luckily, it stills running fine except this harmless (low risk) glitch – slow login password prompt at console, which delays to about a minute after entering login ID.
With reference to SCO technical article, this is a known issue caused by a bug in the bundled telnet server (but surprisingly it affects the console login too) and you might find some of these entries on /usr/adm/syslog:
failed to read terminal control database entry
can’t rewrite terminal control entry
cannot obtain database information on this terminal
To fix it, the official SCO reference suggests to install Release Supplement rs506a or create a shell script to execute
tcbck (make this script to run automatically after system boots up):
while [ true ]; do
if [ -f /etc/auth/system/ttys-t ];
then
tcbck
fi
sleep 5
done
Well, we opt to do nothing at this moment, as long as it running fine until we convert and dismantle it eventually – why bother to fix such a low risk problem encountered on an outdated system that has no secondary support we (administrators) can escalate to?
Note, if it is not caused by bug in telnetd, it could be due to DNS or network-related issues, as noted in this SCO article.
Custom Search
2013 •