160 lines
6.4 KiB
Plaintext
160 lines
6.4 KiB
Plaintext
=head1 NAME
|
|
|
|
Ktools - General description of the Ktools commands
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
This manual page describes background information about the ktools,
|
|
configuration information about the annex boxes, and miscellanous
|
|
related information.
|
|
|
|
=head2 What's an Annex Box anyways?
|
|
|
|
Annex boxes (made by Xylogics, now Bay Networks) are ethernet terminal
|
|
servers that can connect up to 64 terminals. They are being used 'in
|
|
reverse' -- console ports on lab machines are hooked up to the
|
|
terminal lines off the Annex boxes.
|
|
|
|
While the ktools were designed with the Annex box terminal servers in
|
|
mind, there is little reason why other terminal servers couldn't be used.
|
|
|
|
Connections to the console ports on connected machines are made via
|
|
B<telnet>ing to a specific port number on the Annex box. For example,
|
|
to connect to the host attatched to port 1 of os-annex.engr:
|
|
|
|
telnet os-annex.engr 5001
|
|
|
|
However, this has the disadvantage of having to remember which hosts are
|
|
connected to which ports on which annex box. Given that there are 64 ports
|
|
on most annex boxes, this idea quickly becomes useless. Thus were born the
|
|
B<ktools>.
|
|
|
|
=head2 Ktools: YAFE (Yet Another Front End)
|
|
|
|
By telneting to port 5000 of the Annex box, it is possible to get a
|
|
list of the current users by issuing a 'w' command. Thus, B<kwho> was
|
|
born. Kwho simply contacts all the annexes listed in
|
|
F</usr/annex/portsfile>, gets a list of users, and prints it out in a
|
|
nice fashion.
|
|
|
|
Two additional status commands, B<klist> and B<kfree> grew out of the
|
|
need to determine what was attatched to the annex boxes, and which
|
|
machines were free. They simply invoke kwho and then cross-reference
|
|
it against the main ktools database.
|
|
|
|
B<kcons> and B<kgrab> eliminate the need to remember port numbers for
|
|
hosts. They also use the ktools database to determine the correlation
|
|
between a host name, port number, and annex box.
|
|
|
|
With the advent of console-grabbing tools, there was no easy way to
|
|
steal a console out from someone who had forgotten to let go of it
|
|
before the weekend. B<ksteal> addresses this problem. If the idle
|
|
time is greater than 2 hours, the machine is assumed idle and is free
|
|
for stealing. For times when it was really necessary to get at a
|
|
machine, a I<-force> option was added that ignores idle times. All
|
|
B<ksteal> invocations send mail to the pilfered party.
|
|
|
|
To fully realize remote debugging, it is necessary to provide remote
|
|
reset capability. Not surprisingly, B<kreset> is the command to reset
|
|
a system. If supported, it also allows sending an NMI (Non Maskable
|
|
Interrupt) to a system as well as power cycling it on and off.
|
|
|
|
=head2 CU access: PROM debugging and remote kernel debugging via kdbx.
|
|
|
|
Telnet is a fine protocol for most things, but it doesn't have any way
|
|
of downloading a file nor does it have an easy entry point for other
|
|
programs to get to, like a tty. This is where B<rtelnetd> and B<cu>
|
|
step in.
|
|
|
|
B<Rtelnetd> is a billed as a reverse telnet, but all it really does is
|
|
act as a medium between a pseudo-tty and the telnet connection to the
|
|
Annex box. Upon startup, it looks for a 'rtelnetd' flag in the
|
|
portsfile, and creates an entry in I</dev/annex> for each machine that
|
|
it finds with such a flag. It then listens on all the devices it
|
|
created, and upon receiving an open on the device, spawns off a telnet
|
|
connection to the appropriate port (and annex) and passes the data
|
|
back and forth.
|
|
|
|
This gives the capability to use any program that groks ttys (such as
|
|
B<cu>, and B<kermit> ) on these pseudo-ttys. B<cu> has the capability
|
|
to download files, which is very useful for downloading PROM code to a
|
|
developing system.
|
|
|
|
=head2 Annex Booting
|
|
|
|
Annex boxes net boot. Unfortunately, they don't use a standard
|
|
tftp/bootp combo, they use a homebrew protocol, B<erpc>, which
|
|
requires a deamon to run on a server so that Annexes can boot.
|
|
|
|
The inst package B<annex_boot> found in B<dist.engr:/sgi/hacks> can be
|
|
installed on a host to allow an Annex to boot from it. Note that later
|
|
model Annexes (Annex3s, MicroAnnex) have the capability to self-boot,
|
|
thus requiring *no* boot server.
|
|
|
|
=head2 Annex status info
|
|
|
|
A program called B<na> is responsible for communicating with the Annex
|
|
boxes and updating status and configuration info such as user name,
|
|
location, baud rate, etc. B<kcons> and related programs talk to B<na>
|
|
and update the user_name for kwho. B<na> is also used by B< kreset>
|
|
to reset ports. Find the I< Annex Network Administrator's Guide> for
|
|
information on na.
|
|
|
|
=head2 Annex Configuration and the Ktools database
|
|
|
|
The ktools rely on a database to map a machine name to a host:port
|
|
combination. Normally, this is a I<NIS (yp)> map called, unsurprisingly,
|
|
B<ktools>. For sites that don't have NIS service, such as home machines,
|
|
there is the -noyp option for the ktools commands that looks at
|
|
F</usr/annex/ktools.map> instead.
|
|
|
|
The master ktools database for the SGI Mountain View Campus is located
|
|
on the machine I<relay.engr> and can be changed with the command
|
|
B</usr/annex/kedit>. If you are in a different domain, use the command
|
|
I<ypwhich -m ktools> to determine where the ktools database is stored.
|
|
|
|
=head2 Ktools background
|
|
|
|
The initial idea and shell scripts by Curtis Anderson (curtis@sgi.com).
|
|
Evolved over several years into its current condition by
|
|
Chan Wilson (cwilson@sgi.com).
|
|
|
|
The "ktools" are B<kwho>, B<klist>, B<kfree>, B<kcons>, B<kgrab>, B<kreset>,
|
|
and B<ksteal>. Source for the ktools can be found in the irix source tree
|
|
under F<isms/irix/cmd/ktools>. Please I<cc> Chan on any TAKEs that you do,
|
|
so that the images can be rebuilt.
|
|
|
|
=head1 FILES
|
|
|
|
F</usr/annex/portsfile> - to determine the annex boxes to contact,
|
|
hardware configuration and notes of the systems when NIS is not in use.
|
|
|
|
F</usr/annex> where all the commands live.
|
|
|
|
F</dev/annex> the device directory that B<rtelnetd> uses.
|
|
|
|
=head1 SEE ALSO
|
|
|
|
kcons(1), kgrab(1), kreset(1), ksteal(1), annex-intro(1)
|
|
|
|
The ktools pages in the SGI FAQ:
|
|
|
|
B<http://infohub.engr.sgi.com/FAQ/faq.sgi/ktools.description.html>
|
|
|
|
=head1 NOTES
|
|
|
|
B<kcons>, B<kgrab>, B<ksteal>, and B<kreset> invoke B<kwho> to
|
|
determine the status of the system before proceeding with the desired
|
|
action.
|
|
|
|
=head2 Bugs, Pitfalls, etc.
|
|
|
|
Support for anything but Annex boxes is primitive, including a
|
|
dependency on port 5000 for telnet access.
|
|
|
|
Running w/o NIS requires manually copying over the database file from
|
|
the relay host.
|
|
|
|
If the I<erpc> protocol was known, then it wouldn't be necessary to invoke
|
|
B<na> to change the user name on the annex.
|