This document may be distributed freely as a whole in any form and free of charge. Parts of this document may be distributed, provided that this copyright message is included and the reader is informed that this is not the full HOWTO document. Furthermore, there is to be a pointer as to where the full document can be obtained. Specifically, it may be included in commercial distributions, without prior consent. However, I would like to be informed of such usage.
This HOWTO may be translated into any language, whatsoever, provided that you leave this copyright statement and the disclaimer intact, and that a notice is appended stating who translated the document.
<sect1>DISCLAIMER
<p>
While I have tried to include the most correct and up-to-date information available, I cannot guarantee that usage of the information in this document does not result in loss of data. I provide NO WARRANTY about the information in this HOWTO and I cannot be made liable for any consequences for any damage resulting from using information in this HOWTO.
<sect>Introduction
<p>
<sect1>This Document
<p>
This HOWTO attempts to clear up some of the confusion of using
<tt>TERM</tt>, Michael O'Reilly's remarkable program that allows you
to multiplex your serial line and set up a network connection.
By and large, the documents that come with <tt>TERM</tt> are quite
good, and this HOWTO is not intended to replace them. The intention of
this document is to give some background on how <tt>TERM</tt> works
and detail the steps in getting some of the more common networking
services working under <tt>TERM</tt>. It should be emphasized that this
document does not cover everything there is to know about
<tt>TERM</tt>. After reading it, the <tt>TERM</tt>
manual pages should be read, since they include information not contained here.
<sect1> What is <tt>TERM?</tt>
<p>
<tt>TERM</tt> is a program, written by Michael O'Reilly
(michael@iinet.com.au) and maintained by Bill Riemers (bcr@physics.purdue.edu), that is run over a serial line to allow
multiple connections to operate concurrently - <it>i.e.</it> you may
be down-load a file via your modem while working on a (different)
remote system via the same modem connection. <tt>TERM</tt> can also
be used to open up X client windows over a serial connection. Through
the <tt>tredir</tt> utility and the <tt>tudpredir</tt> utility <tt>TERM</tt> can provide almost all of the
``traditional'' TCP/IP and UDP network services: mail, news, ftp, telnet, xarchie, etc. In a
sense, <tt>TERM</tt> is very much like other serial protocols such
as SLIP or PPP. <tt>TERM</tt>'s advantage is that it can be run
entirely from user space, requiring no support
from system or network administrators.
Unlike SLIP or PPP, your machine does not have its own IP address. All incoming traffic must be addressed to your remote host, and it will be redirected to your local computer by <tt>TERM</tt>.
<sect>How <tt>TERM</tt> works
<p>
Before experimenting with <tt>TERM</tt> it is strongly advised to first read this complete chapter and the INSTALLATION file provided with the package. Also take a look at the manual pages <tt>linecheck</tt>, <tt>(term)test</tt> and <tt>TERM</tt>. This will help you to work easier and faster.
<sect1> Nomenclature
<p>
I assume you are dialling a system through some sort of terminal
server. I use the terms <it>local</it> and <it>remote</it> to refer to the home
and network connected systems respectively (unless I use them to mean
something else :-).
<tt>TERM</tt> provides the local machine, which has no network
connection, but is connected, via a serial line, to a remote machine
which is in turn connected to a network with network services. Let us look at how a machine with a
'traditional' network connection provides these services. First the
user invokes a program, like <tt>ftp</tt> or <tt>telnet</tt>, that
requests a network service. What these programs do is make a system
call requesting network services. The operating system then obtains
these services via its network interface (<it>e.g.</it> it sends and
receives packets over the ethernet). SLIP and PPP do exactly this, by
converting your modem line into a network interface, which is in
principle no different from an ethernet. The downside of this is that
these protocols make the modem-connected machine part of the network,
just like any other machine. This implies all the administrative
burdens associated with being a network node (more actually, since the
modem link must also be administered).
In the absence of a network connection like SLIP or PPP, what does one
typically do? Well, you dial your network connected machine, read
your mail, your news etc; if you need a file, you first transfer it to
the remote machine and then download it to your local machine using
<tt>kermit</tt> or some other communication program. This is a bit of a pain, especially since
you can only really do one thing at a time that uses your modem link.
The idea behind <tt>TERM</tt> is basically to automate and multiplex
this process. <tt>TERM</tt> is invoked on both the local and remote
machines, and the two processes communicate with one another over the
modem line. When you need a network service, you make a request to the
local <tt>TERM</tt> daemon, which forwards the request to the
<tt>TERM</tt> daemon on the remote, network-connected, machine. The
result is then returned over the modem line.
To be more concrete, say you want to retrieve a file by <tt>ftp.</tt>
First you need a version of <tt>ftp</tt> that can speak to
<tt>TERM</tt>. You invoke this <tt>termftp</tt> as you do a regular
<tt>ftp</tt>, say <tt>termftp nethost.gov</tt>, but this special
version makes its network request to the local <tt>TERM</tt> daemon
instead of the kernel. The local <tt>TERM</tt> forwards this request,
over the modem line, to the remote <tt>TERM</tt>, which opens an ftp
connection to <tt>nethost.gov</tt>, and transmits the data back over
the modem link. <tt>TERM</tt> is smart enough to have many different
things going on at once; so you can have several different network
sessions using the same modem link, <it>e.g.</it> you can be logged
into another distant host via <tt>termtelnet</tt> while the <tt>
termftp</tt> transfer is going on.
If this is too abstract (or unclear) do not worry; the important piece
of information to get out of this section is that there are <it>two
</it> copies of <tt>TERM</tt> running, one on each end of the modem
link.
<sect>Setting Things Up
<p>
<sect1>What has to be available
<p>
Before you start building and using <tt>TERM</tt> you have to make sure that you have built TCP/IP support into the kernel. Furthermore, make sure that the TCP/IP loopback interface is activated. When this is the case you can go on with the rest of this section.
<sect1>Explanation of concepts
<p>
In newer <tt>TERM</tt> version two new concepts have entered <tt>TERM</tt>. These two concepts will be explained in the next two subsections.
<sect2>Sharing
<p>
Starting with version 1.16 the concept of <tt>sharing</tt> the <tt>TERM</tt> connection with other users has entered <tt>TERM</tt>. This means that when you enable shared features, other people can use the same <tt>TERM</tt> connection you are using, i.e. when you are working on your remote machine via your <tt>TERM</tt> connection (say, from your local machine you used trsh to get in) another person on your local machine can use the same <tt>TERM</tt> connection at the same time to ftp a file to his login on your local machine from an ftp site somewhere in the world.
When you disable shared features (i.e. you execute <tt>TERM</tt> in private mode) you and only you (we do not count root :-) can use the <tt>TERM</tt> connection.
Of course, you only need to install shared <tt>TERM</tt> at the end at which you want to allow people to use the same <tt>TERM</tt> connection you are using. So, if other people have a login on your local machine and they want to use it from somewhere on your remote network you enable shared features on the remote end of your <tt>TERM</tt> connection. In this way all these people can login on your machine at the same time sharing the same <tt>TERM</tt> connection with each other and with you. (NOTE: the first example needed shared features to be enabled at the local end of the <tt>TERM</tt> connection).
<bf>NOTE for installation as root:</bf>
When you install <tt>TERM</tt> as root you have to create a 'term' group first (before compilation) with no member by adding the following line in '/etc/group':
<verb>
term::16:root
</verb>
or any other unused GID than 16 when 16 is already in use.
After compilation and installation make <tt>TERM</tt> and its clients SGID 'term':
<verb>
chgrp term <term_client>
chmod g+s <term_client>
</verb>
Also any other program that you make TERM-aware must be made SGID 'term'.
<sect2>Full TERM networking
<p>
Starting with <tt>TERM</tt> version 2.0.0 the statement <tt>full TERM networking</tt> is used. When your only connection with the outside world is a <tt>TERM</tt> connection, you have a full <tt>TERM</tt> network and you should build <tt>TERM</tt> with full <tt>TERM</tt> networking. In this case in the shared directory a file called <tt>termnet</tt> is placed. This tells <tt>TERM</tt> that your only connection to the outside world is via <tt>TERM</tt>.
When you also have some other type of network connection beside your <tt>TERM</tt> connection TERM-aware programs first try to fulfil their job using this network connection. When this fails <tt>TERM</tt> is invoked and it is tried to fulfil the job via the <tt>TERM</tt> connection. To make this more clear now an example is given in which <tt>TERM-aware telnet</tt> is used. This telnet should work both with and without <tt>TERM</tt>.
<verb>
telnet localhost
</verb>
does not use <tt>TERM</tt> to connect, but
<verb>
telnet zeus.cs.kun.nl
</verb>
will use <tt>TERM</tt> only if you do not have some other type of network connection.
<tt>Full TERM networking</tt> also means to lie about the host name, and say it is the remote host instead. Furthermore, it causes bind(0) to always act on the
remote host. In essence it makes many programs unusable when they are not going through <tt>TERM</tt>, while <tt>TERM</tt> is
running. Unfortunately, most UDP programs
and daemons will not work with <tt>TERM</tt> without these nasty tricks.
<sect1>Build <tt>TERM</tt>
<p>
When you are lucky, this should just involve a <tt>make</tt>. Most probably however, you need to do more. Due to new features in newer versions of <tt>TERM</tt> it is now a bit more complicated to create your <tt>TERM</tt> binary. A couple of ways can be followed to obtain your binary.
To cover all these ways <tt>TERM</tt> can be built this section will be split into three parts:
<enum>
<item>Build <tt>TERM</tt>, versions 2.0.0 and higher</item>
<item>Build <tt>TERM</tt>, versions 1.16 up to 1.19 </item>
<item>Build <tt>TERM</tt> up to version 1.15 </item>
</enum>
<sect2> Build <tt>TERM</tt>, versions 2.0.0 and higher
<p>
First, make sure you have read the section about 'full TERM networking' above.
For <tt>TERM</tt> versions 2.0.0 and higher there are many ways to build the <tt>TERM</tt> binary and the clients. All of these can be done both by root and by ordinary user:
<enum>
<item>Build <tt>TERM</tt> in private mode without full <tt>TERM</tt> networking</item>
<item>Build <tt>TERM</tt> in private mode with full <tt>TERM</tt> networking</item>
<item>Build <tt>TERM</tt> in shared mode without full <tt>TERM</tt> networking</item>
<item>Build <tt>TERM</tt> in shared mode with full <tt>TERM</tt> networking</item>
</enum>
In these versions of <tt>TERM</tt> a new way for compilation has entered <tt>TERM</tt> using the script <tt>configure</tt>. When configure is run it checks on what operating system you are trying to install <tt>TERM</tt>, whether the source directory is available or not, and if any runtime options are set. According to the things found configure then creates a <tt>Makefile</tt> using Makefile.in which is provided in the <tt>TERM</tt> package.
Two of the more important options to configure are <tt>--root</tt> and <tt>--user</tt> which state whether <tt>TERM</tt> will be installed by root or an ordinary user. Other options can be used to install <tt>TERM</tt> the way you want (non-standard paths for example).
<enum>
<item> Build <tt>TERM</tt> in private mode without full <tt>TERM</tt> networking.
To build <tt>TERM</tt> in this way you need to execute the following commands (both for root and ordinary user):
<verb>
./configure --root OR --user
make install installman
</verb>
This builds the binaries and installs these binaries and the manual pages.
</item>
<item> Build <tt>TERM</tt> in private mode with full <tt>TERM</tt> networking.
To build <tt>TERM</tt> in this way you need to execute the following commands (both for root and ordinary user):
<verb>
./configure --root OR --user
make installnet installman
</verb>
This builds the binaries and installs these binaries and the manual pages.
</item>
<item> Build <tt>TERM</tt> in shared mode without full <tt>TERM</tt> networking.
To build <tt>TERM</tt> in this way you need to execute the following commands (both for root and ordinary user):
<verb>
./configure --root OR --user
make share installman
</verb>
This builds the binaries and installs these binaries and the manual pages.
</item>
<item> Build <tt>TERM</tt> in shared mode with full <tt>TERM</tt> networking.
To build <tt>TERM</tt> in this way you need to execute the following commands (both for root and ordinary user):
<verb>
./configure --root OR --user
make share installnet installman
</verb>
This builds the binaries and installs these binaries and the manual pages.
</item>
</enum>
<sect2> Build <tt>TERM</tt>, versions 1.16 up to 1.19
<p>
To build these versions of <tt>TERM</tt> you can now choose one of the following ways:
<enum>
<item>As an ordinary user, build <tt>TERM</tt> in private mode</item>
<item>As an ordinary user, build <tt>TERM</tt> in shared mode</item>
<item>As root, build <tt>TERM</tt> in private mode</item>
<item>As root, build <tt>TERM</tt> in shared mode</item>
</enum>
Below, it will be explained how to enable/disable shared features during the compilation of <tt>TERM</tt>.
<enum>
<item>You are an ordinary user (no root access) and you do NOT want to SHARE the <tt>TERM</tt> connection with other users.
As a user who does not want to share the <tt>TERM</tt> connection with other users you should do the following to build <tt>TERM</tt>:
<verb>
make DO=install OS-type
make installman
</verb>
After this <tt>TERM</tt>, its clients and the manual pages are built and installed.
Furthermore, you need to create a directory '$HOME/.term'. This is the directory in which <tt>TERM</tt> will look for its 'termrc' file.
</item>
<item>You are an ordinary user (no root access) and you want to SHARE the <tt>TERM</tt> connection with other users.
As a user who wants to share the <tt>TERM</tt> connection you should do the following:
<verb>
make DO=installshare USERSHARE=$HOME/term OS-type
make installman
</verb>
After this <tt>TERM</tt>, its clients and the manual pages are built and installed.
Furthermore, you will have a directory '$HOME/term' (default) with permissions 'drwxrwxr-x'. In this directory you will find at least the socket used by <tt>TERM</tt> for its connection ('tmp/private/socket=').
</item>
<item>You are <tt>root</tt> and you do NOT want to SHARE the <tt>TERM</tt> connection with other users.
As root who does not want the <tt>TERM</tt> connection to be shareable you should do the following to build <tt>TERM</tt>:
<verb>
make DO=install OS-type
make installman
</verb>
After this <tt>TERM</tt>, its clients and the manual pages are built and installed.
Furthermore, you now have a directory called '/usr/local/lib/term' (default) with permissions 'drwxr-xr-x'. In this directory you will at least find the socket used by <tt>TERM</tt> for its connection ('tmp/private/socket=').
</item>
<item>You are <tt>root</tt> and want to SHARE the <tt>TERM</tt> connection.
First, make sure you have read the section about 'sharing' above.
As root who wants to share the <tt>TERM</tt> connection you should do the following:
<verb>
make DO=installshare OS-type
make installman
</verb>
After this <tt>TERM</tt>, its clients and the manual pages are built and installed.
Furthermore, you now have a directory called '/usr/local/lib/term' (default) owned by group <tt>TERM</tt> and with permissions 'drwxrwxr-x'. In this directory you will at least find the socket used by <tt>TERM</tt> for its connection ('tmp/private/socket=').
</item>
</enum>
<sect2> Build <tt>TERM</tt> up to version 1.15
<p>
For these versions of <tt>TERM</tt> building should invoke no more than the commands
<verb>
make DO=install OS-type
make installman
</verb>
You will find <tt>TERM</tt>, its clients and the manual pages nicely built and installed and ready for use after this.
Furthermore, you need to create a directory '$HOME/term'. This directory <tt>TERM</tt> will use to look for its termrc file.
The only thing you may want to do is change some of the paths in the <tt>Makefile</tt> or change some of the compiler flags.
With <tt>TERM</tt> a library with functions for <tt>TERM</tt> clients is provided.
Up to version 1.16 this library was called <tt>client.a</tt>. During compilation of <tt>TERM</tt> this library was built and then used during the compilation of the <tt>TERM</tt> clients. It was not installed in another directory.
Starting with version 1.16 the name of the library is changed to <tt>libtermnet.a</tt>. Up to version 1.19 this library is created in the <tt>TERM</tt> directory and then used during compilation of the <tt>TERM</tt> clients. It is not installed in another directory.
Starting with version 2.0.0, beside libtermnet.a also <tt>libtermnet.so</tt> and <tt>libtermnet.sa</tt> (shared library and exported initialized library data) are created during compilation of the <tt>TERM</tt> package. During the installation of all the parts of the package also these three library files are installed in the directory '/usr/local/lib' (default). Then a link is made from libtermnet.so.2 to libtermnet.so.2.x.x. Finally, <tt>ldconfig</tt> is run to create the necessary links and cache (for use by the run-time linker, ld.so) to the most recent shared libraries found in the directories specified on the command line, in the file '/etc/ld.so.conf', and in the trusted directories ('/usr/lib' and '/lib'). If the installation is done correctly the three library files can now be used by <tt>TERM</tt> clients which are built with dynamic instead of static libraries. Also, these libraries can now be used to port your own software to make it <tt>TERM</tt> aware (see belo!
w).
<sect1> Setting environment variables
<p>
<tt>TERM</tt> knows a couple of environment variables which can be set by users. The first three of those that I will explain are
<itemize>
<item>TERMDIR</item>
<item>TERMSHARE</item>
<item>TERMMODE</item>
</itemize>
By setting these variables you can control the way <tt>TERM</tt> is run.
For <tt>TERM</tt> versions up to 1.15 only the variable <tt>TERMDIR</tt> is important (these versions do not know the shared mode). For these versions TERMDIR should be set as follows:
<verb>
setenv TERMDIR $HOME (csh or tcsh)
export TERMDIR=$HOME (bash)
</verb>
Starting with version 1.16 <tt>TERM</tt> also knows the variables <tt>TERMSHARE</tt> and <tt>TERMMODE</tt>. With these variables <tt>TERM</tt> can be told to run in <tt>private</tt> mode or in <tt>shared</tt> mode. I will explain how to set the variables for private mode and shared mode.
TERMMODE knows the following three values;
<itemize>
<item> 0 = private</item>
<item> 1 = system shared</item>
<item> 2 = user shared</item>
</itemize>
<enum>
<item>Running <tt>TERM</tt> in private mode can be done setting the variables TERMDIR and TERMMODE in the following way:
For csh or tcsh
<verb>
setenv TERMDIR $HOME
setenv TERMMODE 0
</verb>
For bash
<verb>
export TERMDIR=$HOME
export TERMMODE=0
</verb>
</item>
<item>When you want to use <tt>TERM</tt> in shared mode there are two ways of setting the variables:
<enum>
<item>When <tt>TERM</tt> is installed as a SUID program only TERMMODE has to be set.
<verb>
setenv TERMMODE 2 (csh or tcsh)
export TERMMODE=2 (bash)
</verb>
</item>
<item>When <tt>TERM</tt> is installed as a SGID program the variables have to be set in the following way:
For csh or tcsh
<verb>
setenv TERMMODE 1
setenv TERMDIR /usr/local/lib/term
setenv TERMSHARE $TERMDIR
</verb>
For bash
<verb>
export TERMMODE=1
export TERMDIR=/usr/local/lib/term
export TERMSHARE=$TERMDIR
</verb>
Setting the variables in this way makes it possible to start old clients (clients linked to an older version of <tt>client.a</tt>) in shared mode.
</item>
</enum>
</enum>
Starting with version 2.0.0 <tt>TERM</tt> also knows the variable <tt>TERMSERVER</tt>. You need to set this variable when you have multiple modems and you have more than one connection at a time. To specify which connection to use, you must start <tt>TERM</tt> with a server name:
<verb>
nohup term -v /dev/modem1 Connection1 &
nohup term -v /dev/modem2 Connection2 &
</verb>
Users should then set the variable TERMSERVER to the connection name they want to use:
<verb>
setenv TERMSERVER Connection1 (csh or tcsh)
export TERMSERVER=Connection2 (bash)
</verb>
<sect1> Test <tt>TERM</tt>
<p>
Do a <tt>make test</tt> (or <tt>make termtest</tt> for newer versions of <tt>TERM</tt>) to build <tt>TERM</tt>'s test daemon. (term)test
works by running two copies of <tt>TERM</tt> on your system, a
'local' and a 'remote'' copy. Both of these will read your
'termrc'; so you can adjust their behaviour. Now execute (term)test. You
should now be able to do a <tt>trsh</tt> and a <tt>tupload</tt> (try
<verb>
tupload ./term /usr/tmp
</verb>
- you should get a copy of the
<tt>TERM</tt> binary in '/usr/tmp'). The local
<tt>TERM</tt>'s output should show up in 'local.log', the
remote's one in 'remote.log'. You can start <tt>TERM</tt> up with
a <tt>-d255</tt> flag to enable debugging output to be written to
these files, or enable debugging in your 'termrc' file.
NOTE: Run <tt>test</tt> as <tt>./test </tt> so as to avoid your system's <tt>test</tt>.
<sect1><tt>TERM</tt> and communication programs
<p>
Before you can use <tt>TERM</tt> you must have established a connection via the modem using a communication program like kermit or seyon. In the documentation of your communication program you can find what you need to do to establish the conection with the remote machine.
when you have established the connection with the remote machine and you want to run <tt>TERM</tt> you need to suspend or quit your communication program without closing the connection with the remote machine. This needs to be done as otherwise the communication program will steal characters from linecheck or <tt>TERM</tt>.
Below for some communication programs I will explain how you can make sure that the connection will stay alive and the communication programs will not steal characters from linechech or <tt>TERM</tt>.
<sect2>
Kermit
<p>
Starting <tt>TERM</tt> when you use kermit is easy. At the local kermit prompt you type <it>suspend</it>. Now you see back your Linux prompt. From this prompt you can establish your <tt>TERM</tt> conection.
<sect2>
Seyon
<p>
An easy way to start linecheck or <tt>TERM</tt> when you are using seyon is to put linecheck and <tt>TERM</tt> in the Transfer Menu (controlled by the file '$HOME/.seyon/protocols').
Then, when you want to execute linecheck or <tt>TERM</tt> on the local machine, you can select the Transfer Menu, either the "Line check" or the "Term" item, and Go.
Of course, you can also use the shell command button, and type 'linecheck' or 'term' in the pop-up dialog box. This also does automatic redirection of input and output.
<sect1>
Make a Transparent Link
<p>
Presumably, you can establish a modem connection between your local
and remote hosts. Typically, you are dialling into some kind of terminal
server and connecting to your remote host from there. You are also
using some kind of terminal software, such as <tt>kermit</tt> or
<tt>seyon</tt> to talk to your modem (the examples in this document
will use kermit, since that is what its author uses). If
you are having trouble with your modem, or your terminal software, take
a look at the Serial-HOWTO; that should help you out.
Having established your link, you want to make it as transparent as
possible. Check the commands on the terminal server (help or ? will
usually get you started). Go for the 8 bit options whenever possible.
This may mean changing the way you log in to a system, <it>e.g.</it> if
the server uses rlogin, you may have to use it and give it the -8 flag
to make it transparent. Especially watch out for xon/xoff flow
control. You do not want that. Try to enable rts/cts (hardware) flow
control. You may need to check your modem documentation to learn how to
configure it to do 8-bit rts/cts communications.
<sect1>
Run linecheck
<p>
<bf>WARNING:</bf> In some of the documents the command line options for <tt>linecheck</tt> are mentioned in an incorrect order. I have checked this and found the order of options mentioned below to be the correct ones.
<bf>NOTE:</bf> Starting with <tt>TERM</tt> version 2.3.0 linecheck no longer needs to have the name of a log-file on its command line. It will write its output to the file 'linecheck.log' in the directory you start linecheck in.
<tt>Linecheck</tt> is a program that is supplied with <tt>TERM</tt>.
It checks the transparency of a link, providing configuration
information that <tt>TERM</tt> needs to run correctly.
linecheck will send each of the 256 possible eight bit
characters over the link and verify that each was transmitted
successfully. <tt>TERM</tt> needs to be configured to deal with
characters that cannot be transmitted over the link, and
linecheck determines what characters these are. You use linecheck after you have established as transparent a modem
link as possible. To run linecheck, do the following
<enum>
<item> On the remote system run
<verb>
linecheck linecheck.log
</verb>
</item>
<item> Escape back to your local system and suspend your communication program (see above)</item>
<item> On the local system run
<verb>
linecheck linecheck.log > /dev/modem < /dev/modem
</verb>
</item>
</enum>
When linecheck is done, you will find a set of numbers at the
bottom of the 'linecheck.log' files. These should be escaped
in the termrc at the other end of the link. For example, in my system my local 'linecheck.log' said nothing and my remote 'linecheck.log' said to escape 29 and 157. Therefore, my local
'termrc' escapes these characters and my remote 'termrc' escapes nothing. If I <it>escape</it> a character at one end,
I have to also <it>ignore</it> it at the other; so, in this example,
I shall have to ignore 29 and 157 in my remote system.
on the local system. This will escape your xon/xoff (flow control) characters, which will
hang your line if you have got software flow control. If this solves the
hanging problems, you will want to <it>escape</it> /<it>ignore</it>
17/19 in both 'termrc's'. If your terminal server has other characters that will shut it down, try running linecheck with
those characters escaped, as above. You can spot these characters if
linecheck hangs. If this is the case, kill it, then look in
the log-files. The last characters transmitted are likely to be the
culprits. Try it again with these characters escaped.
In summary, my local termrc has the lines
<verb>
escape 29
escape 157
</verb>
and my remote termrc has the lines
<verb>
ignore 29
ignore 157
</verb>
since my <it>remote</it> 'linecheck.log' said to escape 29
and 157.
<sect1>
Try Running <tt>TERM</tt>
<p>
Log into the remote system, making the link as transparent as possible
(if you have not already done so). Fire up <tt>TERM</tt> at the remote end.
I use the following:
<verb>
exec term -r -l $HOME/tlog -s 38400 -c off -w 10 -t 150.
</verb>
Let us run down each option one by one (note that I could just as
easily have put these options in my termrc. I did it this way because
it saves editing a file while getting <tt>TERM</tt> set up).
<tt>exec</tt> means to destroy your current shell, running the given
program in its place. I exec things because I do not intend
to use my login shell again; so it is just wasting memory. If you are
debugging the link and can reliably kill the remote <tt>TERM</tt>,
you might not want to do an exec.
The <tt>-r</tt> option is needed at exactly one end. <tt>TERM</tt> will then see this end as the remote end of the connection (Note that <tt>TERM</tt>'s remote end can thus be your local machine). If you do not use this option at one end <tt>TERM</tt> clients will spontaneously crash.
<tt>-l $HOME/tlog</tt>. This logs errors to the file <tt>tlog
</tt> in my home directory. Very useful for debugging. No reason not
to do this.
<tt>-s 38400</tt> : I have got a 14400 baud modem, with compression.
For optimal compression ratios, I want to be able to push bits down
the pipe as fast as possible. For a slower modem, you should use
something lower. Note that if you have a slower machine with 16450
uart on your serial port, high baud rates can cause data loss by
overloading the chip on your serial port. <tt>TERM</tt> will recover
from this, but if you see a lot of error messages in your log file,
(or get overrun warnings from linux kernel versions 0.99pl15 and up)
you again might want to lower this number.
<tt>-c off</tt> : This turns data compression off. I have got a
compressing modem, and I do not want to compress things twice.
<tt>-w 10 -t 150</tt> : Again, these are options to optimize my fast
modem link. I have set my window to 10 and my timeout to 150. This is
according to the recommendation in the <tt>term_setup</tt> man page.
Escape back to your local machine and suspend your communication program (see above). You do not want
it running while <tt>TERM</tt> is running, because it will fight
with <tt>TERM</tt> over the serial port. If you can convince your
modem to not hang up when you exit your communication program (when it toggles
DTR), you could just exit the program at this point.
Now run <tt>TERM</tt> locally. I use:
<verb>
term -c off -l $HOME/tlog -s 38400 -w 10 -t 150 < /dev/modem > /dev/modem &
</verb>
I need to tell <tt>TERM</tt>
where the modem is; so I point both standard input and output at '/dev/modem' (that is what the <tt><</tt> and <tt>></tt> do). I
also run it in the background; so I can use this screen for something
else if I want to.
<tt>TERM</tt> should work now :-). Try a <tt>trsh,</tt> and see
what happens. If you hang, or your link seems slow, take a look at
your 'tlog' at each end. Are you getting timeouts or error
messages? If so, then you have configured something incorrectly. Try
again (after you have finished reading this :-). Note that the
connection will not seem blazingly fast, especially if you are using
compression - it will be a little jumpy. The real speed comes in
during file transfer and the like.
<sect1>Terminate your <tt>TERM</tt> connection
<p>
Most certainly, after you have done a lot of work using <tt>TERM</tt>, you want to finish your work and bring your <tt>TERM</tt> connection down. For this to be realized there are four ways:
<enum>
<item>Kill the <tt>TERM</tt> programs at both sides of the connection. This is the least recommended way of terminating your connection.</item>
<item>A better way is to execute the following command locally:
<verb>
echo '00000' > /dev/modem
</verb>
This will nicely terminate your <tt>TERM</tt> connection. It will work for all version of <tt>TERM</tt>. Make sure that the sequence of zeros contains at least <it>five</it> zeros.</item>
<item>In the termrc of <tt>TERM</tt> versions 2.0.0 and higher you can now enter a statement called <tt>terminate '<some string>'</tt>. This sets a string that will cause <tt>TERM</tt> to exit ('00000' by default). It must be at least <it>five</it> characters long, to avoid accidently terminations. </item>
<item>Starting with version 1.14 there is the program <tt>tshutdown</tt> (actually for version 1.14 it is available as a patch, for newer versions it is in the package). Executing tshutdown nicely terminates your <tt>TERM</tt> connection.</item>
</enum>
<sect1>
Removing <tt>TERM</tt> from your partition
<p>
Ok, you asked for this. As some of you want to get rid of <tt>TERM</tt> I here
present you the steps to be done in removing <tt>TERM</tt>. In the process of
removing <tt>TERM</tt> you have to fulfil the following steps:
<itemize>
<item>Removing directories with their contents. Depending on how you installed
<tt>TERM</tt>, one or more of the following directorieswill exist on your machine:
<verb>
$HOME/.term/termrc
$HOME/.term/termrc.<server>
$HOME/term/termrc
$HOME/term/termrc.<server>
/usr/local/lib/term/termrc
/usr/local/lib/term/termrc.<server>
/etc/termrc
/etc/termrc.<server>
</verb>
These directories can be removed together with their contents. Use '/bin/rm -rf' to get this done.</item>
<item>The group 'term'. For some of the ways of installation you had to create a group 'term'. Check the file '/etc/group' for the 'term' entry. When it exists you can remove the entry.</item>
<item>The <tt>TERM</tt>-package and <tt>TERM</tt>-aware executables. This is probably the hardest part in removing <tt>TERM</tt>. For the executables coming with the <tt>TERM</tt>-package you have to look in the directory '/usr/local/bin' or the directory '$HOME/bin'.
With executables you made <tt>TERM</tt>-aware yourself I cannot help you. You need to know what executables you made <tt>TERM</tt>-aware in order to know what executables you have to remove. Do not forget configuration, default and other files coming with some of these executables.</item>
<item>Library files. To remove these you best can execute the following commands:
<verb>
cd /
find . -name libtermnet* -exec /bin/rm {}
</verb>
This will find and remove the library files.</item>
<item>Include file. Also for this one the easiest way is to execute the following two commands:
<verb>
cd /
find . -name termnet.h -exec /bin/rm {}
</verb>
This will remove the include file.</item>
<item>Manual pages. When you have installed the <tt>TERM</tt> manual pages you can now find them back in one of the following directories:
<verb>
/usr/local/man/man1
/usr/local/man/cat1
$HOME/man/man1
$HOME/man/cat1
</verb>
At least you have to check for the following manual pages: term, term_clients, term_setup, tdownload, linecheck, trdate, trdated, termrc, termtest, tmon, tredir, trsh, tshutdown, tudpredir, tupload, txconnand finally tiptest.</item>
<item>Temporary user directory. This is de directory '/usr/tmp/private' and its contents.</item>
</itemize>
After this exercise you can be quite sure that you have removed everything related to <tt>TERM</tt>.
<sect1>
Optimizing your connection
<p>
Once you have got <tt>TERM</tt> running, you might want to try to get
things optimized. A good way to measure the speed of your link is to
run <tt>tmon</tt> in one window while up/downloading a file in
another. Try both (big) text files and compressed files; the plain
text should go a factor of two-ish faster than the compressed files.
The parameters you want to fiddle with are baud rate (<tt>-s</tt>), compression (<tt>-c</tt>), windows (<tt>-w</tt>), timeout (<tt>-t</tt>) and retrain (<tt>-A</tt>).
Watch out with the retrain parameter. With <tt>TERM</tt> version 1.19 I got a performance decrease of 80&percnt to 90&percnt compared to running <tt>TERM</tt> without the retrain parameter. It is not clear if this is a bug in <tt>TERM</tt> version 1.19 and if this problem exists only with <tt>TERM</tt> version 1.19.
<tt>Baudrate</tt>: the maximum number of bits per second <tt>TERM</tt> will try to send over the serial link. <tt>TERM</tt> will avoid sending characters at a higher data rate than this. The default is to use the speed of your computer's serial port, but be warned that this may be too high if your modem runs at a lower rate over the phone line. The baud rate option is intended for systems that buffer output to the modem. During setup and tuning it is better to use a small baud rate rather than one which is too large. For high speed links (> 38400), making it unlimited is probably advantageous. This is achieved by using the value 'off'. <tt>TERM</tt> will then rely solely on your kernel to do flow control.
<tt>Compression</tt>: you want this on if you do not have a
compressing modem. If you do have such a modem, turn compression off,
otherwise you will be compressing things twice, which typically <it>
increases</it> the amount of data transmitted. Compressing modems are
those that use the MNP-5 or V42.bis protocols. Check your modem
documentation and the message when your modem connects.
<tt>Windows</tt>: this is the number of chunks of data, or packets,
that <tt>TERM</tt> will let go over the line before it gets an
acknowledgment (or ack) from the remote <tt>TERM</tt>. For fast
modems, increasing this can be a win; for slower links this can
overwhelm the remote end.
<tt>Timeout</tt>: the time <tt>TERM</tt> will wait for an ack. If
you have increased windows, and you are getting timeouts in your log-file,
try increasing this.
For 14400/V42.bis, I use <tt>-c off -w 10 -t 150</tt>. I get around 1700 cps on compressed files and 3500 cps on ASCII files
using tupload.
<sect1>
Troubleshooting
<p>
In this section some thoughts are given about what to check when you have problems executing <tt>TERM</tt> or one of its clients.
<itemize>
<item>Did you clean up the <tt>TERM</tt> directory structure? With newer versions of <tt>TERM</tt> the structure of the directory tree under '/usr/local/lib/term' has changed a couple of times. If you are not aware of this, it can cause all kinds of error messages. The best thing to do is to delete the directory tree under '/usr/local/lib/term' (save your 'termrc') and then install your new <tt>TERM</tt> version. This way, you avoid the struggle with a messed up directory tree.</item>
<item>Did you remove old sockets? When you update your <tt>TERM</tt> version remove all the sockets (called 'socket=') created by <tt>TERM</tt>. No doing this can cause strange problems. To find out what socket <tt>TERM</tt> is listening to you can use the "netstat" program.</item>
<item><tt>TERM</tt> does not compile correct on sunOS 4.1.3? You have configured <tt>TERM</tt> with './configure --user'. During compilation you are getting a assembler error on a unknown '-k' flag. The reason of this error is unknown. The solution to this error is to configure <tt>TERM</tt> with static libraries. So, you have to do './configure --user --static' and then continue with the compilation process the way you normally do. Now <tt>TERM</tt> should compile correct.
<item><tt>termtest</tt> is presenting you the error: 'Term: failed to connect to term socket '/root/.term/sockettest''? When termtest runs it expects the executable 'term' to be in the same directory as termtest. When you do a 'make install' prior to running termtest, the TERM binary is moved to '/usr/local/bin' (or some other bin directory).
The workaround for this is to link the binary to the source directory:
<item>Are you running the right binary? <tt>TERM</tt> has been updated
quite a lot, and many systems have different versions of the programs
floating around. Make sure you are using the right version. Note that
this applies to linecheck too. You can use bash's <tt>type -a</tt>
or the <tt>whereis</tt> command to find which program is being run.
<tt>TERM</tt> versions after 1.11 should print out their version
number when they start up. (Although version 1.14 claims to be 1.12.
Sigh.)</item>
<item>Do you have the right 'termrc' in the right place? Depending on the version of <tt>TERM</tt> you are running and the way you installed <tt>TERM</tt> (being root or user) this file has to be in one of the following directories:
<verb>
$HOME/.term/termrc
$HOME/.term/termrc.<server>
$HOME/term/termrc
$HOME/term/termrc.<server>
/usr/local/lib/term/termrc
/usr/local/lib/term/termrc.<server>
/etc/termrc
/etc/termrc.<server>
</verb>
Some systems have pre-installed 'termrc' files; make
sure they are gone before you set things up. If you are running things
as root, lookout for '/.term'. <tt>TERM</tt> creates files
(sockets actually) while it is running; so it has its own directory,
'$HOME/.term', where the file 'termrc' goes
(note, there is <it>no</it> leading dot in 'termrc'!). </item>
<item>Does <tt>TERM</tt> find its 'termrc' file? when you start up <tt>TERM</tt> at both sides, you should see messages like the one below:
<verb>
Term version: 2.2.9
Reading file: /usr/local/lib/term/termrc
Using shared mode.
</verb>
When the second line is missing <tt>TERM</tt> cannot find its 'termrc' file and you know that something is gone wrong during the installation (unless you are not using a 'termrc' file and enter all the options to the command line :-). Check the place and the permissions of the 'termrc' file on the site <tt>TERM</tt> cannot find its 'termrc' file.</item>
<item>Do the entries in the 'termrc' file have the correct syntax and spelling? A known problem is that people who need to escape and ignore several characters enter
them like this in the 'termrc' file:
<verb>
escape 1,4,30,255
ignore 1,4,30,255
</verb>
Although <tt>TERM</tt> does NOT like this it will not complain. It only escapes or ignores the first character presented to the escape or ignore statement. The others characters are silently handled as not being there.
When you have to escape or ignore several characters you have to put them on separate lines in your 'termrc' file, each line starting with the keyword <bf>escape</bf> or <bf>ignore</bf>. Only when you have to escape or ignore a range of characters you can do it the following way:
<verb>
escape 16-19 # escape characters 16, 17, 18, 19
escape 23 # 23
escpae 255 # and 255
ignore 16-19 # ignore characters 16, 17, 18, 19
ignore 23 # 23
ignore 255 # and 255
</verb>
</item>
<item>Is you 'term' or '.term' directory mounted with NFS? If your 'term' or '.term' directory is mounted with NFS you need to set the flag -DTERM_NFS_DIR in the CFLAGS line of the Makefile. Alas, for the author this flag causes a compile error when <tt>TERM</tt> 1.19 is compiled on a machine running sunOS 4.*.</item>
<item>Are all files and directories owned by the correct user and group and do they have the correct permissions? This should be no problems as these permissions are set during the installation phase. However, when you port your own programs to <tt>TERM</tt> you must be aware of this. Also when you change the mode <tt>TERM</tt> is working in (i.e. from private mode to shared mode) file and directory ownerships and permissions have to be adapted.
<item>You are getting the error <it>gethostbyname: <hostname>: Non-authoritative `host not found', or, server failed</it>
To solve this you have to check the following things:
<enum>
<item>Is the file '/etc/hosts' configured correctly? <hostname> is not the name of your host (old SLS releases and some old and new Slackware releases are shipped with hostname 'darkstar' for example). Change this in this file. It must at least contain a line like below (the format is described above it):
<verb>
# Local Hosts Format:
# IP_NUMBER HOSTNAME ALIASES
#
# Here is the name of your host, first, followed by any aliases
127.0.0.1 localhost linuxpc.domain linuxpc
</verb>
When your only connection to the outside world is by <tt>TERM</tt> the line above
is the only one that may appear in the file '/etc/hosts'. Do not put actual addresses of frequently visited destinations in '/etc/hosts'. <tt>TERM</tt> does not like these to be in '/etc/hosts' and it will hang on them.
</item>
<item>Are your '/etc/rc*' and '/etc/resolv.conf' files world readable (chmod ugo+r)?</item>
<item>Last, make sure that you have installed the TCP/IP loopback-interface on your machine. You can check for loopback by running the command 'ifconfig'. When you have installed the loopback-interface you will at least get something like:
on your screen. During boot time you can furthemore check which protocols are in use. On my machine a line like the one below then appears:
<verb>
IP Protocols: ICMP, UDP, TCP
</verb>
For the installation of TCP/IP and the loopback-interface, please read to the NET-HOWTO.
</item>
</enum>
</item>
<item>You are getting all kinds of 'timed out' messages in your <tt>TERM</tt> log files? This means that your <tt>TERM</tt> connection is not optimized. A small number of these messages every now and then is not a problem. These are most certainly due to temporal factors influencing the physical connection between your local and remote hosts.
When you get a lot of these messages all the time your connection will slow down considerably. You have to fiddle with the parameters mentioned in the section 'Optimizing your connection' above. Alas, this part of the installation is a process of trial and error. No hard rules can be given about the numbers to be presented to the various parameters as many factors have an influence on the connection. These factors differ between the connections and even in time.</item>
<item>Normal FTP with redirected ports does not work for you? Alas, it is a known problem that redirection of the ports needed by FTP (20 and 21) does not give you a working FTP. The only solution is to get a <tt>TERM</tt>-aware ftp or ncftp version. Alas, also some <tt>TERM</tt>-aware ftp versions seem not to work.</item>
</itemize>
<sect><tt>TERM</tt> clients
<p>
<tt>TERM</tt> provides several default clients. They include <tt>
<tt>txconn</tt> and in newer versions <tt>trdate</tt>, <tt>trdated</tt>. Furthermore, starting with version 2.0.0 <tt>tudpredir</tt> is available and from version 2.1.0 <tt>tdownload</tt> is available. This section will deal with <tt>
trsh</tt>, <tt>tmon</tt>, <tt>tupload</tt>, <tt>tdownload</tt>, <tt>trdate</tt> and <tt>trdated</tt>.
The others each have their own section. No <tt>TERM</tt> client
will work until you have established a <tt>TERM</tt> link.
<tt>tmon</tt> is a simple utility to monitor the statistics of your
link. It prints a time histogram of characters transmitted and
received. It is invoked simply as tmon. Since around
version 1.11, tmon has had a bug that causes some
information to be garbled (??).
<tt>trsh</tt> is similar to <tt>rsh</tt>. Without arguments, it spawns
an interactive shell on the remote system (<it>i.e.</it> it logs you
in). trsh is one of the primary means of accessing the
remote end of the link via <tt>TERM</tt>. If given an argument,
trsh executes that argument as a command on the remote
system. For example
<verb>
trsh ls
</verb>
would give you a listing of the
files in your home directory on the remote system.
<tt>tupload</tt> will transfer a file, given as its first argument, from local to remote. By default, the files will be put in the
same directory that you invoked <tt>TERM</tt> from at the other
side. To put files in another directory, give their names as a second
argument to tupload. For example, if I want to put a copy
of the file 'term114.tar.gz' in '/usr/tmp' on the
remote system, I would type
<verb>
tupload term114.tar.gz /usr/tmp
</verb>.
When you use tupload you can use wild cards like in 'tupload a.*'. The shell expands the wild card and tupload is called as 'tupload a.1 a.2 ......'.
<tt>tdownload</tt> will transfer a file, given as its first argument, from remote to local. By default, the files will be put in the
same directory that you invoked <tt>TERM</tt> from at the local
side. To put files in another directory, give their names as a second
argument to tdownload. For example, if I want to put a copy
of the file 'term114.tar.gz' in '/usr/tmp' on the
local system, I would type
<verb>
tdownload term114.tar.gz /usr/tmp
</verb>.
When you use tdownload you <it>cannot</it> use wild cards like in 'tdownload a.*'. Reason for this is that the remote directory is not available to your local shell when you use tdownload; so your local shell cannot expand the wild cards.
<tt>trdate</tt> is a time setting utility. It reads the time on the remote machine and sets the local clock to the remote time. It must be run as root.
<tt>trdated</tt> is the daemon version of trdate. When it is started in 'rc.local' it is run as daemon in which case it updates the time every 5 minutes (default). Even when there is no <tt>TERM</tt> connection, this daemon will start up when set in the rc.local. Once a <tt>TERM</tt> connection is created it starts updating the time.
<sect>X and <tt>TERM</tt>
<p>
<tt>TERM</tt> allows users to open up X windows on the local machine
from clients that are running on a machine on the network. This is
done by using the <tt>txconn</tt> client. txconn is
executed on the remote, network-connected machine; it is invoked
simply as txconn. It goes into the background and returns a
number on the standard output; this number is the display number that
clients should use to access the X server on the local machine. An
example should make this clear. I am logged in, via trsh,
to my remote <tt>TERM</tt> host, named <tt>foo.</tt> On foo, I do the following
<verb>
foo$ txconn
Xconn bound to screen 10
:10
foo$
</verb>
Now, on any host that I wish to run an X client on, that is to display on
my local machine's X server, I do
<verb>
setenv DISPLAY foo:10
</verb>
(for <tt>bash</tt> you should use <tt>export DISPLAY=foo:10</tt>). In some cases it can furthermore be necessary to do a
<verb>
xhost + foo
</verb>
or even a
<verb>
xhost +
</verb>
on your local machine. Now when I start the client, it will try to connect to
screen 10 on machine foo, but txconn is listening to
this screen, and will forward all X protocol packets via <tt>TERM</tt>
to the X server on the local host - <it>i.e.</it> the window will open
up on your local machine.
It is possible to go the other way - run a client on your local
machine and have it open up a window on a remote machine on the
network; however we will defer explaining this until after we have
discussed tredir.
The X protocol is not very efficient; it wastes some bandwidth. This
is usually not a problem over an ethernet, but can be murder over a
modem. X11R6 is supposed to introduce a low bandwidth version of the X
protocol, LBX. If however you are using X11R5 you can use a utility named sxpc which compresses the X protocol, improving response over
serial lines. Sxpc includes a write-up on how to get it
working with <tt>TERM</tt>, and is recommended. The sxpc package also explains how to use xauth; so it is
doubly recommended.
<sect><tt>tredir</tt>
<p>
<tt>tredir</tt> is one of <tt>TERM</tt>'s most powerful utilities,
allowing most important network services to be performed over a <tt>
TERM</tt> link. Before we explain how to use tredir, it is
necessary to give some background on network services. We have talked
about network services before, but we have not said exactly what they
are. Services are just that - services that are provided by the
network. Examples of services include <tt>telnet</tt>, which provides
logins between machines, the File Transfer Protocol, <tt>ftp</tt>,
which transfers files between machines, and smtp, the Simple Mail
Transfer Protocol, which is used whenever you send electronic mail.
Each network service has a <it>port number</it> associated with it.
The mapping of port numbers to services is given in the file
'/etc/services'. This file should be the same on all
internet-connected machines.
How are these services invoked? Each networked machine runs a daemon
called <tt>inetd</tt>, which listens for attempts to connect to the
network ports. These requests can come from either the network or the
local machine. A network service is obtained by connecting to a
particular inetd port. When a network request is made,
inetd knows exactly which service is involved by the port
number the request is made on. If inetd is configured to do
so, it provides the relevant service to the requesting
connection. inetd's configuration is given by the file '/etc/inetd.conf', which has a list of the services that inetd provides. For more information, see the man pages for inetd and inetd.conf.
You can communicate directly with network services by using
<tt>telnet</tt> (<it>n.b.</it> not <tt>termtelnet</tt>). For example,
to talk to the <tt>sendmail</tt>, (or smtp) daemon on machine
<tt>machine_name</tt>, you can do a <tt>telnet machine_name smtp,</tt>
or <tt>telnet machine_name 25</tt>, (since 25 is the number assigned
to smtp in '/etc/services'). You should get a polite greeting
from the daemon on the remote machine. This is a very useful trick for
debugging network problems and checking ports redirected with tredir (see below).
Tredir works very much like inetd. It runs in the
background as a daemon, listening to the network ports, waiting for a
request. When a request for a service is made, instead of providing
that service, as inetd does, tredir forwards the
request over the <tt>TERM</tt> link to the remote <tt>TERM</tt>, which
makes the request over the network, returning the result back over the
link to the local client. Tredir can forward the request to
any machine on the network, but by default sends it to the machine at
the other end of the <tt>TERM</tt> link. Tredir <it>redirects</it> TCP (Transmission Control Protocol) network services over the <tt>TERM</tt> link.
The common command format of tredir is:
<verb>
tredir [this_computer:]port [that_computer:]port
</verb>
An example should make this clear. Let us redirect a local port to the
telnet port on the remote machine. To do this we would do
<verb>
tredir 2023 23
</verb>
Now, anyone who connects to port 2023 on the local
machine will be redirected to port 23 (telnet) on the remote machine.
Here is an example session; the local machine is <tt>
mymachine.modem.home</tt> and the remote machine is <tt>netsun</tt>.
<verb>
$ tredir 2023 23
Redirecting 2023 to 23
$ telnet localhost 2023
Trying 127.0.0.1...
Connected to mymachine.modem.home
Escape character is '^]'.
SunOS UNIX (netsun)
login:
</verb>
This example is actually quite useful. If I were instead to do the
tredir on <tt>netsun</tt>. I could then telnet in to <tt>mymachine
</tt> from the network simply by connecting to the redirected port on
the networked machine (using telnet) - <it>i.e.</it> <tt>telnet
netsun 2023</tt>.
The general principle in using tredir is to redirect the
desired service to a machine on the network. Our next example will
allow us to read news on the local machine over our <tt>TERM</tt> link
from a news server on the network. News is provided by the nntp
service, port number 119. All decent news readers allow you to specify
what port number they will use, either via a configuration file or an
environment variable. Let us specify this local port to be 2119. Now,
let us say that our news server is <tt>news.domain.org</tt>. We will
redirect port 2119 to port 119 on <tt>news.domain.org</tt>; we will
then tell our news reading software that the nntp server is located at
port 2119 on the local host. Since this will depend on the news reader
that you use, I will just test the link with <tt>telnet</tt> instead
of firing up a news reader:
<verb>
$ tredir 2119 news.domain.org:119
Redirecting 2119 to news.domain.org:119
$ telnet localhost 2119
Trying 127.0.0.1...
Connected to mymachine.modem.home.
Escape character is '^]'.
200 news.domain.org InterNetNews NNRP server INN 1.4 07-Dec-41 ready
(posting ok).
</verb>
If you can get this far, all you have to do is configure your news
reader to be able to read news via <tt>TERM</tt>. (<it>n.b.,</it> if
you read news like this, be sure that in all your posts you set a
Reply-To: header to an network email address that you can be reached
at, otherwise people who want to get in touch with you will be sending
mail to whatever (wrong) data your news reader puts in the From:
header).
<sect1> <tt>tredir</tt> can bite!
<p>
The astute reader, after reading the last example will be wondering
why port 2119 was redirected to port 119 - since news readers default
to port 119, why could I not do a <tt>tredir 119 news.domain.org:119
</tt> and skip the news reader configuration? The answer is that all
ports numbered less than 1024 are ``reserved ports'', and only the
superuser can listen to them. If one is willing to take a security
risk and make tredir an SUID program, or run tredir as root, then one can redirect reserved ports and avoid the
hassle of renaming services.
Another problem with using reserved ports is that inetd is
often already listening to these ports, and only one program at a time
can listen to a port. In order to use such a port, you must change
'inetd.conf' so that inetd no longer listens to the
port you want to redirect. This is most easily done by commenting out
the line with the offending service by putting a <tt>&num</tt>
character at the beginning of the line. The superuser must then send
inetd a HUP signal (kill -1 inetd-pid) to get it to reread its configuration.
<sect1> Stupid <tt>tredir</tt> tricks
<p>
In this section we will describe some of the more common uses for tredir. We have already described how to redirect nntp and
telnet services; here we will give some more complicated examples.
<sect2> X windows
<p>
In a previous section, we described how to get an X client running on
the network to open a window on your home machine using <tt>txconn</tt>. The same technique could be used on your home machine to display
a client on the machine at the remote end of your <tt>TERM</tt> link.
But how does one display an X client on a network machine that is not
the remote end? The answer lies in knowing that X uses a particular
network service just like the other programs we have been discussing. An
X server listens for a network request on a port whose number is given
by the formula <f> port = 6000 + display number</f>, <it>e.g.</it> an X
server managing screen 0 on a machine would listen to port 6000, if it
were managing screen 2, it would listen to port 6002. When you set
your DISPLAY environment variable to <tt>xmachine:n</tt>, your X
clients will try to connect to port <f>6000 +n</f> on <tt>xmachine</tt>.
We can use this to trick X clients on your local machine to open up
windows on remote displays. Let us say I want to open up an <tt>xterm
</tt>, running on my local machine, on display 0 of machine <tt>
xmachine</tt>, which is running some place on the network. I first
pick a local display number, say 2 (do not use 0, since that is what
your local X server will be using). I will map this display to display
0 on <tt>xmachine</tt>. In terms of ports, this means I want to
redirect the local port 6002 to the remote port 6000. I do the
following
<verb>
$ tredir 6002 xmachine:6000
$ setenv DISPLAY localhost:2
$ xterm
</verb>
This should open up an <tt>xterm</tt> on machine <tt>xmachine</tt>.
Note that I set the DISPLAY to <tt>localhost:2</tt>. This is because X
clients will sometimes use unix domain sockets instead of internet
domain sockets, at their own option, when connecting to a local
display, if DISPLAY is set to <tt>:2</tt>. <tt>localhost:2</tt> says
to use a TCP connection.
Note that as far as <tt>xmachine</tt> is concerned, the X request is
coming from the machine on the remote end of your <tt>TERM</tt> link
(<tt>remotemachine</tt>) - so if you need to authorize the connection,
you should either do an <tt>xhost + remotemachine</tt> on <tt>
xmachine</tt> or use xauth to update the '.Xauthority' file on your local machine for display number 2, using the key
from <tt>xmachine</tt>.
Again, to speed up X connections, you can use the program sxpc, which includes an explanation of how to use tredir
to establish the link and authorize it using xauth.
<sect2> Mail with <tt>TERM</tt>
<p>
Well, you asked for it. Electronic mail has the justifiable
reputation of being one of the most difficult things to get working
right on a UNIX system. To really get <tt>TERM</tt> working
correctly with mail means that you have to understand how mail works,
which is beyond the scope of this document. To learn more about mail,
you should consult a book on UNIX system administration and/or the
comp.mail.misc FAQ, available for anonymous ftp on rtfm.mit.edu:pub/usenet/comp.mail.misc. There are also currently two
packages available for anonymous ftp on sunsite.unc.edu that will help you get mail running under <tt>TERM</tt> - they are
<tt>term.mailerd+smail</tt> by Byron A. Jeff and the <tt>
BCRMailHandlerXXX</tt> by Bill C. Riemers.
That being said, we will give a thumbnail description of how mail works.
There are two parts to getting mail running, sending messages and
receiving messages. We will begin with sending messages from your local
box to the network.
There are two classes of mail programs. The first is the mail user
agent (MUA). MUA's help you read, compose and send messages. Examples
of MUA's are <tt>elm</tt>, <tt>pine</tt>, <tt>Mail</tt> and
<tt>vm</tt>. MUA's do not really do any networking; they just put the
messages together - the real work of sending mail is done by the
second class of mail programs, the mail transfer agents (MTA's). These
are invoked by the MUA's. They take the message, decide where to send
it by looking at the address, and then actually deliver it over the
network.
The two most common MTA's on Linux systems are <tt>sendmail</tt> and
<tt>smail</tt>. The basic idea is to get your MTA to connect to
another MTA running on a machine on the net that will know what to do
with your message. This is done by redirecting a local port to the
smtp port on the net machine. You then have to tell you MTA to take
any message it does not know what to do with, and send it out over the
redirected port on your local machine to the MTA on the remote
machine, which will then route your message to its correct
destination.
How do we do this using smail? We first redirect a port to
the smtp port on the network mail machine (<tt>mailhost</tt>):
<tt>
tredir XXXX mailhost:25
</tt>
here XXXX is the port number that the <tt>smail</tt> on the
localhost will connect to (note that I have to give this port a name
in my '/etc/services' to get smail to recognize
it). Smail has several configuration files that usually
live in '/usr/local/lib/smail'. The ones we care about are
'config', 'routers' and 'transports'. Note
that I am assuming you have already got smail configured
correctly for local mail - delivery to files and pipes and such things.
Again, consult the documentation if you have not.
In the file 'config', we put the following definition:
<verb>
smart_path=localhost
</verb>
localhost is the machine that smail connects to when
it does not know what to do with a message.
In 'routers' we put
<verb>
smart_host:
driver=smarthost,
transport=termsmtp;
path = localhost
</verb>
In 'transports' we put
<verb>
termsmtp: driver=tcpsmtp,
inet,
return_path,
remove_header="From",
append_header="From: YOUR_NET_ADDRESS",
-received,
-max_addrs, -max_chars;
service=YOUR_SMTP_SERVICE,
</verb>
In the above, the header lines change the <tt>From</tt> header in all
your outgoing mail to the address, <tt>YOUR_NET_ADDRESS</tt>, which is
the network address you want mail sent to. If more than one user is
going to be using your <tt>TERM</tt> link, you will have to do something
more fancy, like keep a database of local user's network addresses and
insert these in the <tt>From:</tt> headers.
The service line is the name of the local port number that you have
redirected to the smtp port on the network connected machine. In my
version of smail, I cannot just set this to a number, I have
to set it to a name, like ``foo'', and then define ``foo'' in my '/etc/services' to be the number of my redirected port. If you use
a SUID tredir and just redirect the smtp port (25), you
do not need to define this.
This should be enough to get you going. If you decide to use <tt>
sendmail</tt>, the principles are the same but the details differ.
Ronald Florence (ron@mlfarm.com) told me that the stock Sun
sendmail will not send multiple queued messages over a
redirected port; BSD sendmail 8.6.9 works fine. He made the following
changes to '/etc/sendmail.cf' to get it working with <tt>TERM</tt>. In his
case, the default sendmail port (25) is used for SMTP traffic over a
local ethernet so Internet mail is forwarded to a redirected TCP
port.
<verb>
#
#Create the termsmtp mailer, which sends mail via a re-directed TCP port
When the <tt>TERM</tt> connection is established to the Internet host, run the
following commands on the local machine.
<verb>
tredir PORTNUMBER internet.host:25
/usr/lib/sendmail -q
</verb>
We now turn to receiving electronic mail using <tt>TERM</tt>. We will
assume that mail is sent to your account on the network machine <tt>
mailhost</tt>. The simplest solution is to just use trsh or
termtelnet to log on to <tt>mailhost</tt> and read your mail
on there. However, it is also possible to have your mail
automatically downloaded to your local machine. One way to do this is
to use the Post Office Protocol, (POP). POP was designed for exactly
this purpose: to deliver mail to machines that have intermittent
network connections. To use POP, you must have a POP server installed
on <tt>mailhost</tt>. Assuming that you do, you can then use a POP
client to download your mail every few minutes. This is done, as you
might expect, using tredir. The POP service is 110 (<bf>
note</bf> that there is an older protocol, POP-2, which uses port 109;
in this document we describe POP-3, which is the latest version of
POP). There are several POP clients available. One, written in the
script language <tt>perl</tt> is pop-perl-1.X, written by William
Perry and maintained by myself - it can be found on sunsite.unc.edu:pub/Linux/system/Mail.
To use POP, you redirect a local port to port 110 on <tt>mailhost
</tt> and configure your client to retrieve your mail from localhost
using the local port. As an example, we will assume that there is a POP
server running on <tt>mailhost</tt>. We will redirect the local port
2110, and fire up the pop-perl client:
<verb>
$ tredir 2110 mailhost:110
Redirecting 2110 to mailhost:110
$ pop
Username: bill
Password: <enter your password for mailhost>
Pop Host: name of local
Pop Port: 2110
Starting popmail daemon for bill
</verb>
If you do not have a POP server available, the BCRMailHandler package
has a program to download your mail over a <tt>TERM</tt> link to
your local machine. I have not used it, but anyone who has is welcome
to comment. You can also use the term.mailerd+smail package for this purpose.
Alas, both BCRMailHandler and the term.mailerd.smail package do not work anymore with <tt>TERM</tt> versions 2.0.0 and higher.
<sect><tt>tudpredir</tt>
<p>
<tt>tudpredir</tt> is similar to tredir when you look at what these programs do and how they are executed. The big difference between the two programs is that tredir is used to redirect TCP network services while tudpredir redirects UDP (User Datagram Protocol) network services over the <tt>TERM</tt> link. One more important difference between the two programs is that tredir becomes a background daemon once it has successfully established the local port, while tudpredir commands must be placed in the background manually.
When finally you want to close the connection, you
resume and terminate kermit. The last line of the script kills
the local <tt>TERM</tt> and returns the system in its initial state.
(<tt> Note of the author: instead of doing '!killall -KILL term', I think it should be possible just to do '!tshutdown'. This should also work?</tt>)
As I said, there are zillions of ways to do so; these are just meant
as examples to get you started. Other examples can be found in the packages <tt>autoterm</tt> and <tt>JoelTermStuff</tt>.
<sect>
Porting software for use with <tt>TERM</tt>
<p>
In principle, all programs that can be used over a network can also be used in combination with <tt>TERM</tt>. Some of them you can get as binaries with <tt>TERM</tt> support already built in. These include telnet, (nc)ftp, Mosaic and many others. Most of these programs are compiled for <tt>TERM</tt> 1.17 or earlier. They should, however, still work with the newer versions of <tt>TERM</tt>.
Another way to make programs <tt>TERM</tt> aware is to port them yourself. This process will be described in the next subsection.
The last way to make your programs <tt>TERM</tt>-aware is to <tt>termify</tt> them.
<sect1>
Port and compile the sources
<p>
Porting software to <tt>TERM</tt> can be done using a fairly simple porting procedure:
If installed in '/usr/local' by root:
<enum>
<item> Add to the compile flags <tt>-include /usr/local/include/termnet.h</tt></item>
<item> and add to the library list <tt>-ltermnet</tt></item>
</enum>
If installed in your home directory:
<enum>
<item> Add to the compile flags <tt>-include $HOME/term/termnet.h</tt></item>
<item> and add to the library list <tt>-L$HOME/term -ltermnet</tt></item>
</enum>
Now compile the software as described in the INSTALL or README document that came with the software. That should do!
At this point the commands should work both with and without <tt>TERM</tt>.
<verb>
telnet localhost
</verb>
does not use <tt>TERM</tt> to connect, but
<verb>
telnet bohr.physics.purdue.edu
</verb>
will use <tt>TERM</tt> only if you do not have some other type of network connection.
Some commands like <tt>rlogin</tt> can only be executed by root and the owner
of the <tt>TERM</tt> connection (privileged persons).
Some <tt>TERM</tt> commands will be <tt>TERM</tt> transparent and only use <tt>TERM</tt> when there is not another option. Some common examples are telnet and ftp.
Others require an external flag to tell them it is all right to use <tt>TERM</tt>. These programs include xarchie, fsp and ytalk.
You can either flag these programs to use <tt>TERM</tt> by setting the environmental variable TERMMODE as specified in README.security, or running <tt>make installnet</tt>. Eventually, the 'termnet' file created will contain special networking instructions, but for now only its existence is checked.
If you add an <tt>ethernet connection</tt>, you can then simply remove the 'termnet' file and continue to use the same binaries!
<tt>NOTE</tt>: Programs that were ported back in the days of <tt>client.a</tt>, can still be recompiled for use with newer versions of <tt>TERM</tt> simply by changing the <tt>client.a</tt> reference to <tt>libtermnet.a</tt>.
<sect1>Termify
<p>
This package will convert dynamically linked binaries for <tt>TERM</tt> use.
Before you can use <tt>termify</tt> you have to make sure that you have <tt>TERM</tt> version 2.2i (is this version 2.2.8?) or later and libc.so.4.5.26 or later. Then you have to create the file 'libt.so.4' in the directory '/lib' (see the README file in the package).
Problem at this moment is that you have to remake the file 'libt.so.4' every time you upgrade <tt>TERM</tt> versions.
After you have created the library you can let termify 'crunch' the program you want to make <tt>TERM</tt>-aware, by using the command:
<verb>
termify <command name>
</verb>
When you do not like the result you can 'un'termify the program you have just termified using the command:
<verb>
termify -u <command name>
</verb>
Last, the package also contains a script for completely termifying 'smail'; so no special transport definitions are necessary. The only thing you possibly want to change is the 'From: ' address.
<sect>Term clients
<p>
<sect1>Term clients available on ftp sites.
<p>
Below a list of application running with <tt>TERM</tt> is given. I am not stating that this list is complete; so any completion is welcome. As far as possible I will present the site and directory where the application can be found (all to my knowledge). When I state <tt>sunsite.unc.edu</tt> as the place to find the application I mean that you can find it in one of the following two directories:
The package <tt>termnet-2.0.4-Linux-bin.tar.gz</tt> (sunsite.unc.edu:/pub/Linux/apps/comm/term) contains a couple of pre-compiled <tt>TERM</tt> clients and a couple of scripts, manual pages and libtermnet.so.2.00.04. The clients are compiled using this version of libtermnet.so. The package contains the following clients:
<tscreen><verb>
fet perl sperl4.036 tmon tshutdown xgopher
finger perl4.036 suidperl trdate tudpredir ytalk
ftp rcp taintperl trdated tupload
fwhois rlogin telnet tredir txconn
ncftp rsh term trsh xarchie
</verb></tscreen>
WARNING: The package also contains the complete set of compiled clients of <tt>TERM</tt> 2.0.4 including <tt>TERM</tt> itself. Do not install this package before you are sure about what you want. You will destroy other versions of <tt>TERM</tt> and its clients when you start moving executables around.
<sect1>Asked for but not yet supported
<p>
<enum>
<item> <tt>DOOM</tt>: The problem with this game seems to be the fact that it uses port 5029 both as client and as server.</item>
<item> <tt>NFS</tt>: The NFS server is only supposed to accept requests
if the socket requesting the connection is bound to a port below 1024. This seems to be troublesome. However, some NFS servers have an 'insecure' option. In this case NFS might work eventually, if RPC support is added to Term. </item>
</enum>
<sect>Term and Security
<p>
In this section I will point to some security aspects of <tt>TERM</tt>. The problems will be explained and a way to improve security will be given.
<sect1>trsh
<p>
<tt>Trsh</tt> is insecure when it is used to access the local Linux box from the remote system. The problem with <tt>TERM</tt> and its clients is that beside the owner of the <tt>TERM</tt> connection also 'root' can execute <tt>TERM</tt>-aware programs over the connection.
This also means that 'root' on the remote system can execute trsh and thus can enter the login which owns the <tt>TERM</tt> connection quite easy. If this owner on the local box is 'root' then you will be in hell.
The solution to this problem is easy: you just have to put the following line in the termrc┤ file on the local box:
<verb>
denyrsh on
</verb>
With this set in the 'termrc' file, nobody can use trsh on the remote site anymore to access your machine. When you and others want to access your local Linux box over the <tt>TERM</tt> connection this can still be done using <tt>telnet</tt> and redirected ports.
<sect1>txconn and xauth
<p>
Txconn is not terribly secure; anyone can connect to your local server via <tt>TERM</tt> and perform all sorts of mischief. I you are worried about this sort of thing, it might be a good idea to consider using xauth to authorize your connections. See the next section for an example of using xauth for securing your connections.
<sect1>sxpc, xhost and xauth
<p>
<tt>Sxpc</tt> in combination with 'xhost +' is very dangerous when you are not using <tt>xauth</tt>.
Using xauth is very important to maintaining security when using sxpc. If you do not use xauth when using sxpc all the dangers of running with 'xhost +' apply. These dangers include but are not limited to:
<itemize>
<item>Someone watching what is displayed on your screen</item>
<item>Someone watching what you type</item>
<item>Someone typing in one of your windows (for example: a command to delete all your files :-(</item>
</itemize>
Xauth is available in X releases R4 and later. Here I will describe how to set up basic usage of xauth. This configuration is vulnerable to network snooping, but if you can live with that it should be fine.
<bf>NOTE:</bf> when using xauth your $DISPLAY variable must NOT be set to localhost (or localhost:whatever). If your $DISPLAY variable does use localhost the clients will be unable to find the appropriate authorization information. The workaround is to use the real hostname of the machine. If you follow the compilation instructions in the README, and compile without -DNOGETHOSTNAME then everything should work.
The machine where you will be running clients will be called C, the machine where you wish to display them will be called D.
First choose a 'key', up to 16 pairs of hexadecimal digits (so an even number of characters from the ranges 0-9 and a-f). You will need to supply this key in place of <key> in the example below.
On C:
<verb>
% xauth
xauth: creating new authority file $HOME/.Xauthority
Using authority file $HOME/.Xauthority
xauth> add Chostname:8 MIT-MAGIC-COOKIE-1 <key>
xauth> exit
</verb>
On D:
<verb>
% xauth
xauth: creating new authority file $HOME/.Xauthority
When starting the X server on D you should give the flag <it>-auth $HOME/.Xauthority</it>. You may need to edit or create a '$HOME/.xserverrc' to control how the X server is started. For example:
<verb>
#!/bin/sh
exec X -auth $HOME/.Xauthority $*
</verb>
Make sure that your '.Xauthority' file is readable only by you on both C and D.
<sect>Things to remember
<p>
In this section I try to present you with a list of useful ftp addresses, URL's etc. where you can find software and information about <tt>TERM</tt>.
http://www.bart.nl/~patrickr/term-howto/Term-HOWTO.html (always the newest version)
http://physics.purdue.edu/~bcr/homepage.html
</verb>
<bf>Netnews:</bf>
<verb>
comp.os.linux.announce announce of new TERM versions and Term-HOWTO
comp.os.linux.help ask your questions about TERM here
comp.os.linux.misc or here
comp.protocols.misc answers to TERM questions are also posted here.
</verb>
<bf>Related documents:</bf>
<verb>
Using Term to Pierce an Internet Firewall HOWTO by Barak Pearlmutter,
bap@learning.scr.siemens.com
Firewall HOWTO by David Rudder,
drig@execpc.com
Serial HOWTO by Greg Hankins,
gregh@cc.gatech.edu
Net-2/Net-3 HOWTO by Terry Dawson,
terryd@extro.ucc.su.oz.au
</verb>
When you start asking questions on netnews please make sure that you give people in the groups as much information as they need to solve your problem (<tt>TERM</tt> version number, way you set up your connection etc.). At this moment many <tt>TERM</tt> versions are in use and all have their specific and common problems. Therefore, when you want a useful answer, at least state the version of <tt>TERM</tt> you are using. Otherwise, in some cases only wild guesses are possible to help you solve your problems.
<sect>
Reliability of <tt>TERM</tt> versions
<p>
Many versions of <tt>TERM</tt> are around now. The maintainer of <tt>TERM</tt>, Bill Riemers, has made a list of <tt>TERM</tt> versions stating what versions are reliable and what versions you had better avoid. This list is the following:
<tscreen><verb>
term110 --> cannot really say
term111 --> cannot really say
term112 --> cannot really say
term113 --> cannot really say
term114 --> fairly stable BETA version
term115 --> unstable BETA version
term116 --> unstable BETA version
term117 --> unstable BETA version
term118 --> semi-stable BETA version
term119 --> stable GAMMA version
term-2.0.X --> semi-stable BETA versions
term-2.1.X --> more stable BETA versions
term-2.2.X --> new BETA versions
term-2.3.X -->
</verb></tscreen>
<sect>Term speed table
<p>
Thanks to Bill McCarthy we now have a table with <tt>TERM</tt> speed information for different modems, <tt>TERM</tt> versions and connection conditions. Its purpose is to give new and experienced users some idea what other people are using and the results they are getting.
5) compress off 6) baudrate 19200 7) ignore 19+17 8) compress off
window 10 compress on window 4 escape 0, 13,
timeout 150 timeout 90 16-19, 255
baudrate 38400 baudrate 0
shift 224
flowcrtl 500
window 10
timeout 70
retrain on
breakout 24
9) compress off 10) compress off 11) baudrate 19200
baudrate 57600 baudrate 38400 compress on
window 10 escape 17, 19 shift 224
timeout 200 remote escape 0, 13 16-17
noise on 19, 255
share on window 10
remote timeout 40
Escaping characters at one end also implies ignoring them on the other end.
</verb></tscreen>
<sect>
Hints and Tricks found on the net
<p>
In the Linux related newsgroups many questions about <tt>TERM</tt> are coming back every couple of weeks, together with the answers to these questions. To reduce traffic to the newsgroup, in this section I shall try to make a composition of these questions and the answers to them. Some of the answers have been checked by me as I also had related problems. Others, I have just taken from the newsgroups without testing them.
<itemize>
<item>Many people, especially those who are using Ultrix, seem to have trouble with <tt>vi</tt> presenting less than 24 lines on a window with 24 lines. There are three ways to get rid of this problem:
<enum>
<item>Log in into the remote system using:
<verb>
trsh -s telnet <hostname>
</verb></item>
<item>Put 'resize; clear' in your '.login' file
</item>
<item>The best solutions seems to be to enter the following remote:
<verb>
stty 38400
</verb></item>
</enum></item>
<item>
Many people seem to have problems with crashing <tt>TERM</tt> connections, whatever may be the reason of the crashes. So before starting applications people want to know whether their <tt>TERM</tt> connection is still alive or not. This can be checked using the following small shell script examples:
When you are using tcsh:
<verb>
if ( { trsh -s true } ) then
...
endif
</verb>
When you are using bash:
<verb>
if trsh -s true; then
...
fi
</verb>
</item>
<item>
The WWW browser <tt>Netscape</tt> is causing people problems to get it to work with <tt>TERM</tt>. The good news is that it will work under <tt>TERM</tt>. Here is how:
<verb>
1. Termify netscape
2. Fire up termnetscape
under Options | Preferences | Mail/Proxys
leave _all_ of the proxy boxes blank
set the SOCKS box to 'remotehost' & 80
3. Ignore the error you get when you exit the Options menu.
4. If termnetscape fails to work right:
under Options | Preferences | Mail/Proxys
leave _all_ of the proxy boxes blank
set the SOCKS box to 'none' & 80
5. Ignore the error you get when you exit the Options menu.
</verb>
Scott Blachowicz mailed me stating that it is even easier to get Netscape or any other browser to work with <tt>TERM</tt> if you have a proxy server (e.g. CERN's httpd)
installed for use on the <it>remote</it> side of your <tt>TERM</tt> link. On the local
side, you can then do this:
<verb>
1. tredir localhost:8080 remotehost:80
where 'remotehost' is the hostname of your proxy server system.
2. Run your particular browser, then in the preferences or options or
whatever it is called, point your proxies at 'localhost' port
8080.
Some browsers might like environment variables like
export http_proxy=http://localhost:8080/
export ftp_proxy=http://localhost:8080/
</verb>
</item>
</itemize>
<sect>Other Things
<p>
Some things that might be included:
<itemize>
<item>Extension of troubleshooting</item>
<item>Extension of security issues</item>
<item>Termwrap</item>
<item>Suggestions</item>
</itemize>
Anyway, if you have suggestions, criticism, suggestions, or anything else to say about this document, please fire away. At the moment I, Patrick Reijnen, have taken over the authorship of the <tt>TERM</tt>-HOWTO. I can (currently) be reached at <tt>patrickr@bart.nl</tt>.
<sect>Acknowledgements
<p>
A lot of people have to be thanked. First and foremost Michael O'Reilly and all the developers of <tt>TERM</tt>, who have provided us with such a great tool. I would also like to thank everyone who gave feedback and contributed to this HOWTO. They include Bill Reynolds, the former author of this HOWTO, Ronald Florence, Tom Payerle, Bill C. Riemers, Hugh Secker-Walker, Matt Welsh, Bill McCarthy, Sergio, Weyman Martin and everybody I forgot to mention.
