|
Lee showed me his Mustang and how he had it set up:
1. Looking on the back of the box, there are two terminal
ports. They have funny 9-pin male EIA connectors, into
which he has plugged a little rectangular plug that has
a 9-pin female EIA connector on one end and a DECconnect
6-pin "telephone type" jack on the other. Into the
telephone jack he has plugged a null-modem DECconnect
cable, and that is plugged into the back of a VT320
terminal, whose comm port is set up at 9600 baud, 8 bits
no parity.
2. (Optional:) He showed how you test local loopback in his
config, in which he has installed the kdebug subset:
(Note this is not a headless workstation).
On the Mustang console monitor, log in as root, and type
at the prompt:
# tip kdebug
connected
If you type on the VT320 it displays on the above window.
If you type on the Mustang keyboard with the pointer in
the window, it displays on the VT320.
By default in /etc/remote an entry has been created for
kdebug.
To exit, type:
<CR>~.
(return tilde period)
on the Mustang console window. That exits tip.
3. Observe the file /etc/gettydefs
It contains definitions that you can use in /etc/inittab.
4. In /etc/inittab, he put an entry:
tty00:3:respawn:/usr/sbin/getty tty00 console vt100
This says run getty on dev tty00 when you get an interrupt;
the device setup is "console" (from /etc/gettydefs) and
the device type is vt100 (I should think you could say
vt300 but didn't try it).
5. If a getty is already running (first time you attempt setup
there won't be one, but if you repeat this changing inittab
or gettydefs entries, there may be one), kill it. E.g.,
# ps auxww | grep getty
If that returns a /usr/sbin/getty running the line that
is in /etc/inittab, kill -9 the PID.
6. Restart inittab values:
# init q
7. Hit Return on the VT300 and you will see a login prompt.
That's how it works on his Mustang.
|