<!-- 0,1 -->
<!-- TERM,0 -->
<!-- Patrick,Reijnen,patrickr@bart.nl -->
<!-- 1.0,1995-01-01 -->
<!-- TERM -->
<!-- Alfonso,Belloso,alfon@bipv02.bi.ehu.es -->
<!-- 1.0,1996-12-21 -->
<!-- TERM,term -->
<!-- Software,Protocolos,TERM -->

<!doctype linuxdoc system>

<!-- TERM-Howto, traducido por Alfonso Belloso, alfon@bipv02.bi.ehu.es -- >
<!--                                            Fidonet:    2:344/17.2 -- >
<!-- Txt2Sgml por Juan José Amor, jjamor@ls.fi.upm.es -- >
<!--  Hombre, ya puestos a meter comentarios: SGMLizado totalmente, (para  -- >
<!--  que se lo trague el sgml2latex) reorganización y revisión del texto  -- >
<!--  así como corrección de la sintaxis de un par de comados (find)       -- >
<!--  por Francisco J. Montilla, pacopepe@insflug.org "Revisión" del 21/12/96  -- >
 
<article>

<title><tt>TERM</tt> Como

<author>Patrick Reijnen, <tt><htmlurl url="mailto:patrickr@bart.nl" 
name="patrickr@bart.nl"></tt> &nl;
Traducción de Alfonso Belloso, <tt><htmlurl url="mailto:alfon@bipv02.bi.ehu.es"
name="alfon@bipv02.bi.ehu.es"></tt>

<date>v1.0, 1 Enero de 1995

<abstract>
 Lo que sigue es una guía detallada de configuración del programa
de comunicaciones <tt>term</tt> en Linux.
</abstract>

<toc>

<sect>Información

<p>

<sect1>Copyright statement

<p>

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>Introducción

<p>

<sect1>Sobre este Documento

<p> 

Este COMO intenta aclarar algunas de las confusiones al usar
<tt>term</tt>, el gran programa de Michael O'Reilly que permite
multiplexar tu línea serie y establecer una conexión de red. De principio a
fin, los documentos que vienen con el <tt>term</tt> son bastante buenos,
y este COMO no pretende reemplazarlos.  La intención de este documento es
dar una idea de fondo de cómo trabaja el <tt>term</tt> y detallar los
pasos para conseguir algunos de los servicios de red más comunes
trabajando bajo <tt>term</tt>. Se debe hacer hincapié en que este
documento no cubre todo lo que se debe saber sobre el <tt>term</tt>.
Después de leerlo, deberían leerse las <it/manpages/ sobre <tt>term</tt>, 
 ya que éstas incluyen información que no se encuentra aquí.

<sect1> ¿Qué es el <tt>TERM?</tt>

<p>

<tt>term</tt> es un programa, escrito por Michael O'Reilly,
<tt><htmlurl url="mailto:michael@iinet.com.au" name="michael@iinet.com.au"></tt>
, que corre sobre una línea serie para permitir a
conexiones múltiples operar de forma concurrente --es decir, puedes estar
recibiendo un fichero con tu módem mientras trabajas en un sistema remoto
(distinto)-- a través de la misma conexión módem. El <tt>term</tt> también
se puede usar para abrir ventanas de cliente X sobre una conexión serie. 
Por medio de las utilidades <tt>tredir</tt> y <tt>tupredir</tt> de las
versiones <tt/2.0.x/ y superiores del <tt>term</tt>, éste puede proporcionar
muchos de los servicios de red ``tradicionales'':<tt>  mail, news, ftp, telnet,
xarchie</tt>, etc. En esencia, <tt>term</tt> es muy parecido a otros protocolos
serie como <tt/SLIP/ o <tt/PPP/. La ventaja de <tt>term</tt> es que puede correr
enteramente desde el espacio de usuario, sin requerir soporte del kernel
ni del sistema o administradores de red.

A diferencia de <tt/SLIP/ o <tt/PPP/, tu máquina no llega a tener su propia
dirección IP. Todo el tráfico deberá ir dirigido al host remoto, y
será redirigido a tu máquina mediante <tt>TERM</tt>.

<sect>Cómo funciona el <tt>TERM</tt>

<p>

 Antes de experimentar con <tt>term</tt> es altamente aconsejable leer
primero este capítulo completo y el fichero <tt/INSTALLATION/ que viene con el
paquete. También conviene echar una ojeada a las páginas de manual de
<tt>linecheck</tt>, <tt>(term)test</tt> y <tt>term</tt>. Esto te ayudará a
trabajar más fácil y más rápido. 

<sect1> Nomenclatura

<p>

Asumo que estás llamando a un sistema a través de algún tipo de servidor
de terminal. Utilizo los términos <it>``local''</it> y <it>``remoto''</it>
para referirme a los sistemas conectados en casa y en la red
respectivamente (a no ser que los use para referirme a alguna otra cosa :-).

<tt>term</tt> proporciona a la máquina local, que no tiene conexión de
red, pero que está conectada por una línea serie a una máquina remota, la
cual a su vez está conectada a una red, servicios de red. Observemos cómo
una máquina con una conexión de red ``tradicional'' proporciona estos
servicios. 

Primero el usuario invoca un programa, como <tt/telnet/ o <tt/ftp/,
 que requiere un servicio de red. Lo que estos programas hacen es hacer una
llamada del sistema solicitando servicios de red. El sistema operativo
obtiene entonces estos servicios a través de su interface de red (por
ejemplo, manda y recibe paquetes sobre la ethernet). 

<tt/SLIP/ y <tt/PPP/ hacen exactamente esto, convirtiendo la línea módem
en un interface de red, lo cual en principio no es diferente de una
ethernet. La pega está en que estos protocolos hacen de la máquina
conectada por módem parte de la red, justo como cualquier otra máquina.
Esto exige toda la tarea administrativa asociada al hecho de ser un nodo
de la red (más aún, ya que el enlace módem también hay que administrarlo). 
 
En ausencia de una conexión de red como <tt/SLIP/ o <tt/PPP/, ¿qué es lo
que se hace típicamente?. Bien, llamas a tu máquina conectada a la red,
lees tu correo, tus news, etc, si necesitas un fichero, primero te lo
transfieres a la máquina remota y entonces te lo envías a la máquina local
usando el <tt/kermit/ o algún otro programa de comunicaciones.

Esto es una pena, especialmente porque en realidad sólo puedes hacer que
una cosa use el enlace módem a la vez. La idea que hay detrás del
<tt>term</tt> es básicamente automatizar y <it/multiplexar/ este proceso.
El <tt>term</tt> se invoca en ambas máquinas, local y remota, y los dos
procesos se comunican entre sí por la línea módem.  Cuando necesitas un
servicio de red, haces una solicitud al <it/daemon/ del <tt>term</tt>
local, el cual transmite la petición al <it/daemon/ del <tt>term</tt> en
la máquina remota (conectada a la red). El resultado se devuelve a través
de la línea módem.

Para ser más precisos, pongamos que quieres conseguir un fichero por
<tt/ftp/. Primero necesitas una versión de <tt/ftp/ que pueda hablar con
<tt>term</tt>.  Invocas <tt>termftp</tt> como lo haces con un <tt/ftp/
normal, pongamos <tt>'termftp nethost.gov'</tt>, pero esta versión
especial hace su solicitud de red al daemon del <tt>term</tt> local en vez
de al kernel. El <tt>term</tt> local transfiere esta petición, a través de
la línea del módem, al <tt>term</tt> remoto, el cual establece una
conexión con <tt/nethost.gov/, y transmite los datos de vuelta sobre el enlace
módem. 

<tt>term</tt> es lo suficientemente listo como para tener muchas cosas
diferentes funcionando a la vez, por lo que puedes tener varias sesiones
de red distintas usando el mismo enlace módem; por ejemplo puedes estar
dentro de otra máquina lejana vía <tt>termtelnet</tt> mientras continúa la
transferencia del <tt>termftp</tt>.

Si esto es demasiado abstracto (o engorroso) no te preocupes; la
información importante que hay que extraer de esta sección es que hay
<it>dos copias</it> del <tt>term</tt> corriendo, una a cada lado del
enlace módem.

<sect>Poniendo a punto las cosas.

<p>

<sect1>Qué necesitas tener de antemano.

<p>

Antes de comenzar a construir y usar el <tt>TERM</tt> debes asegurarte de que 
tienes incluido el soporte <it>TCP/IP</it> en el kernel. Además, asegúrate de
que esté activo el interface <it/loopback/ de <it>TCP/IP</it>. Si éste es tu 
caso, puedes seguir con el resto de esta sección.

<sect1>Explicación de conceptos.

<p>

En las versiones nuevas del <tt>term</tt> han aparecido dos conceptos
nuevos. Estos dos conceptos se explican en los siguientes apartados. 

<sect2><it>``Sharing''</it> (compartición).  

<p> 

A partir de la versión 1.16 aparece el concepto de compartir la conexión
<tt>TERM</tt> con otros usuarios. Esto significa que cuando habilitas la
característica <it/``shared''/ (compartida), más gente podrá usar la misma
conexión <tt>TERM</tt> que tú estás usando, es decir, cuando estás
trabajando en tu máquina remota a través de tu conexión <tt>TERM</tt> (has
usado <tt/trsh/ en tu máquina local para acceder, por ejemplo) otra
persona en tu máquina local podrá usar la misma conexión <tt>TERM</tt> al
mismo tiempo para transmitir un fichero con <tt/ftp/ a su cuenta en tu
máquina local desde un <tt/ftp/ <it/site/ de cualquier lugar del mundo.

Cuando deshabilitas la característica <it/``shared''/ (compartida) (o sea,
ejecutas <tt>TERM</tt> en modo privado) tú y solo tú (sin contar a
<tt/root/ :-) puede usar la conexión <tt>TERM</tt>. 

Por supuesto, sólo necesitas instalar el <it/``shared''/ <tt>TERM</tt> en
el extremo en el que quieres permitir a la gente usar la misma conexión
<tt>TERM</tt> que tú estés usando. Así que, si otra gente tiene cuenta en
tu máquina local y quieren usarlo desde algún lugar de tu red remota
habilitas la característica shared en el extremo remoto de tu conexión
<tt>TERM</tt>. De esta forma toda esta gente puede acceder a tu máquina a
la vez compartiendo la misma conexión <tt>TERM</tt> entre sí y contigo
mismo. (NOTA: el primer ejemplo necesitaba habilitar la característica
shared en el extremo local de la conexión <tt>TERM</tt>).

<bf>NOTA para la instalación como <tt/root/</bf>: 

Cuando instalas <tt>TERM</tt> como <tt/root/, primero debes crear un grupo
<tt>TERM</tt> (antes de compilar) sin miembros, añadiendo la siguiente
línea en <tt>/etc/group</tt>: 

<tscreen><verb>
term::16:root
</verb></tscreen>

o cualquier otro <tt/GID/ no usado en lugar del 16 si éste ya está en uso.

Después de compilar e instalar coloca al <tt>TERM</tt> y sus clientes el
<tt/SGID/ <it/term/: 

<tscreen><verb>
chgrp term <cliente_term>
chmod g+s <cliente_term>
</verb></tscreen>

También cualquier programa que hagas utilizable con <tt>TERM</tt> debe tener 
SGID <tt>TERM</tt>.

<sect2>``<it/Full TERM networking/'' (conexión de red completamente TERM)  

<p>

A partir de la versión <tt/2.0.0/ de <tt>TERM</tt> se usa el concepto
<it>full TERM networking</it> (conexión de red totalmente TERM). Cuando tu
única conexión con el mundo exterior es una conexión <tt>TERM</tt>, tienes
una red <it/full TERM/ (completamente TERM) y deberías compilar el
<tt>TERM</tt> con full <tt>TERM</tt> networking.  En este caso se ha
puesto un fichero llamado <tt>termnet</tt> en el directorio compartido.
Esto dice a <tt>TERM</tt> que tu única conexión con el exterior es a
través del <tt>TERM</tt>. 

Cuando también tienes algún otro tipo de conexión de red además de los
programas (pasados a <tt>TERM</tt>) de la conexión <tt>TERM</tt>, primero
intenta que realicen su trabajo usando esta otra conexión. Si ésta falla
entonces se invoca el <tt>TERM</tt> y se intenta realizar el trabajo a
través de la conexión <tt>TERM</tt>. Para aclarar esto, ahora se da un
ejemplo en el que el se usa <tt/telnet/ hecho utilizable en <tt>TERM</tt>.
Este <tt/telnet/ debería funcionar con y sin <tt>TERM</tt>. 

<tscreen><verb>
telnet localhost
</verb></tscreen>

no usa el <tt>TERM</tt> para conectar, pero

<tscreen><verb>
telnet zeus.cs.kun.nl
</verb></tscreen>

usará el <tt>TERM</tt> sólo si no tienes otro tipo de conexión de red.

El full TERM networking también implica el mentir sobre el nombre del
host local, diciendo que es el host remoto en su lugar. Además, provoca que
<tt/bind (0)/ actúe siempre en el host remoto. En esencia hace que muchos
programas puedan usarse sin ir a través del <tt>TERM</tt> mientras el
<tt>TERM</tt> está corriendo. Desafortunadamente, la mayoría de programas
y demonios <tt/UDP/ no funcionarán con <tt>TERM</tt> sin estos incómodos
trucos.
 
<sect1>Compilación del <tt>TERM</tt>

<p>

Si tienes suerte esto sólo debe implicar un <tt>make</tt>. Sin embargo, lo
más probable es que necesites hacer más. Debido a nuevas opciones en las
versiones nuevas del <tt>TERM</tt> (<tt/sharing/, <tt/configure/) ahora es
un poco más complicado crear el ejecutable del <tt>TERM</tt>. Hoy en día
pueden seguirse un par de caminos para obtener el ejecutable. 

Para cubrir todos los caminos a seguir con los que puede construirse el 
<tt>TERM</tt> vamos a dividir esta sección en tres partes:

<enum>
<item>Construir el <tt>TERM</tt> hasta la versión 1.15
<item>Construir el <tt>TERM</tt>, versiones 1.16 hasta 1.19
<item>Construir el <tt>TERM</tt>, versiones 2.0.0 y superiores
</enum>

<sect2> Construir el <tt>term</tt> hasta la versión 1.15

<p>

Para estas versiones del <tt>term</tt>, la compilación no debería implicar 
ejecutar más que estos comandos

<tscreen><verb>
make DO=install OS-type
make installman
</verb></tscreen>

Encontrarás el <tt>term</tt>, sus clientes y las páginas de manual
(<tt>man</tt>)  cómodamente construidas e instaladas y listas para usar
después de esto. 

Además, necesitarás crear un directorio <tt>&dollar;HOME/term</tt>. Este
directorio lo usará el <tt>term</tt> para buscar su fichero
<tt>termrc</tt>. 

La única cosa que puedes querer hacer es cambiar algunos de los paths
en el <tt/Makefile/, o cambiar alguna opción del compilador.

<sect2> Construir el <tt>term</tt>, versiones 1.16 hasta 1.19 

<p> 

Para construir el <tt>term</tt> ahora puedes elegir una de las siguientes
formas: 

<enum>
<item>Como un usuario normal, construir el <tt>term</tt> en modo privado
<item>Como un usuario normal, construir el <tt>term</tt> en modo shared
<item>Como <tt/root/, construir el <tt>term</tt> en modo privado
<item>Como <tt/root/, construir el <tt>term</tt> en modo shared
</enum>

Abajo se explicará cómo habilitar/deshabilitar la opción <tt/shared/
durante la compilación del <tt>term</tt>

<enum>

<item>Eres un usuario normal (sin acceso de <tt/root/) y NO quieres
COMPARTIR (SHARE) la conexión <tt>term</tt> con otros usuarios.

Como usuario que no quiere compartir la conexión <tt>term</tt> con otros
usuarios deberías hacer lo siguiente para construir el <tt>term</tt>:

<tscreen><verb>
   make DO=install OS-type
   make installman
</verb></tscreen>

Después de esto, el <tt>term</tt>, sus clientes y las páginas de manual están
generados e instalados.

Además, necesitarás crear un directorio <tt>&dollar;HOME/term</tt>. Este
directorio lo usará el <tt>term</tt> para buscar su fichero
<tt>termrc</tt>.

La única cosa que puedes querer hacer es cambiar algunos de los paths
en el <tt/Makefile/ o cambiar algún parámetro del compilador.

<item>Eres un usuario normal (sin acceso de <tt/root/) y SI quieres COMPARTIR
(SHARE) la conexión <tt>term</tt> con otros usuarios.

Como usuario que quiere compartir la conexión <tt>term</tt> con otros
usuarios deberías hacer lo siguiente para construir el <tt>term</tt>:

<tscreen><verb>
   make DO=installshare USERSHARE=$HOME/term OS-type
   make installman
</verb></tscreen>

Después de esto, el <tt>term</tt>, sus clientes y las páginas de manual 
estarán compiladas e instaladas.

Además, tendrás un directorio <tt>&dollar;HOME/term</tt> (por defecto) con
permisos <tt>drwxrwxr-x</tt>. En este directorio encontrarás al menos el
<it/socket/ usado por el <tt>term</tt> para sus conexiones
(<tt>tmp/private/socket=</tt>).

<item>Eres <tt/root/ y NO quieres COMPARTIR (SHARE) la conexión <tt/term/ con
otros usuarios.

   Como <tt/root/ que no quiere compartir la conexión <tt>term</tt> con otros
   usuarios deberías hacer lo siguiente para construir el <tt>term</tt>:

<tscreen><verb>
   make DO=install OS-type
   make installman
</verb></tscreen>

Después de esto, el <tt>term</tt>, sus clientes y las páginas de manual 
estarán compiladas e instaladas.

Además, tendrás un directorio llamado <tt>/usr/local/lib/term</tt> (por
defecto) con permisos <tt>drwxr-xr-x</tt>. En este directorio encontrarás
al menos el <it/socket/ usado por el <tt>term</tt> para sus conexiones
(<tt>tmp/private/socket=</tt>).

<item>Eres <tt/root/ y quieres COMPARTIR (SHARE) la conexión <tt>term</tt>.

   Primero, asegúrate de haber leído la sección sobre ``sharing'' anterior.

   Como <tt/root/ que quiere compartir la conexión <tt/term/ deberías hacer lo
   siguiente:

<tscreen><verb>
   make DO=installshare OS-type
   make installman
</verb></tscreen>

Después de esto, el <tt>term</tt>, sus clientes y las páginas de manual
estarán compiladas e instaladas.

Además, tendrás un directorio llamado <tt>/usr/local/lib/term</tt> (por
defecto) con permisos <tt>drwxrwxr-x</tt>. En este directorio encontrarás
al menos el <it/socket/ usado por el <tt>term</tt> para sus conexiones
(<tt>tmp/private/socket=</tt>). 

</enum>

<sect2> Construir el <tt>TERM</tt>, versiones <tt/2.0.0/ y superiores

<p>

Primero asegúrate de haber leído la sección sobre ``full term networking''
de arriba.

Para las versiones de <tt>term 2.0.0</tt> y superiores hay muchas formas
de generar el binario del <tt>term</tt> y los clientes. Todo esto puede
hacerse tanto por <tt/root/ como por un usuario cualquiera: 

<enum>  
<item>Generar el <tt>term</tt> en modo privado sin full term networking
<item>Generar el <tt>term</tt> en modo privado con full term networking
<item>Generar el <tt>term</tt> en modo shared sin full term networking
<item>Generar el <tt>term</tt> en modo shared con full term networking
</enum>

En estas versiones de <tt>term</tt> ha aparecido una nueva forma de
compilar, usando el script <tt/configure/. Cuando se ejecuta <tt/configure/
éste chequea en que sistema operativo estás tratando de instalar el
<tt>term</tt>, si el directorio origen está disponible o no, y si hay
puesta alguna opción <it/runtime/.  De acuerdo con las cosas encontradas
<tt/configure/ crea entonces un <tt/Makefile/ usando <tt/Makefile.in/ que
se entrega con el paquete del <tt>term</tt>. 

Dos de las opciones más importantes para <tt/configure/ son <tt/--root/ y
<tt/--user/ que establecen si el <tt>term</tt> será instalado por
<tt/root/ o por un usuario cualquiera. Se pueden usar otras opciones para
instalar el <tt>term</tt> de la forma que quieras (con paths no estándar,
por ejemplo). 

<enum>
<item>Generar el <tt>term</tt> en modo privado sin full term networking

   Para generar el <tt>term</tt> de este modo necesitas ejecutar los siguientes 
   comandos (tanto para <tt/root/ como para cualquiera):

<tscreen><verb>
   make install installman
</verb></tscreen>

Esto genera los binarios, instalándolos junto con las páginas de manual.

<item>Generar el <tt>term</tt> en modo privado con full term networking

   Para generar el <tt>term</tt> de este modo necesitas ejecutar los siguientes 
   comandos (tanto para el <tt/root/ como para cualquiera):

<tscreen><verb>
   make installnet installman
</verb></tscreen>

Esto genera los binarios, instalándolos junto con las páginas de manual.

<item>Generar el <tt>term</tt> en modo shared sin full term networking
   
   Para generar el <tt>term</tt> de este modo necesitas ejecutar los siguientes 
   comandos (tanto para el <tt/root/ como para cualquiera):

<tscreen><verb>
   make share installman
</verb></tscreen>

Esto genera los binarios e instala estos binarios y las páginas de manual.

<item>Generar el <tt>term</tt> en modo shared con full term networking

   Para generar el <tt>term</tt> de este modo necesitas ejecutar los siguientes 
   comandos (tanto para el <tt/root/ como para cualquiera):

<tscreen><verb>
   make share installnet installman  
</verb></tscreen>

Esto genera los binarios e instala estos binarios y las páginas de manual.

</enum>

<sect1><tt>client.a, libtermnet.a, libtermnet.sa, libtermnet.so</tt>

<p>

Con el <tt>term</tt> se suministra una librería con funciones para
clientes <tt>term</tt>. 

Hasta la versión 1.16 esta libreria se llamaba <tt/client.a/. Durante la
compilación de <tt>term</tt> se generaba esta librería, que después se
usaba en la compilación de los clientes <tt>term</tt>. No se instalaba en
otro directorio. 

A partir de la versión 1.16 se cambió el nombre de la librería por
<tt/libtermnet.a/. Hasta la versión 1.19 esta librería se crea en el
directorio <tt>term</tt> y después se usa durante la compilación de los
clientes <tt>term</tt>. No se instala en otro directorio.

A partir de la versión 2.0.0, además de <tt/libtermnet.a/ también se crean
<tt/libtermnet.so/ y <tt/libtermnet.sa/ (libreria <it/shared/ y librería
<it/exported initialized/) durante la instalación del paquete
<tt>term</tt>. Durante la instalación de todas las partes del paquete,
estos tres ficheros de librerías se instalan en el directorio
<tt>/usr/local/lib</tt> (por defecto).  Y después se hace un enlace desde
<tt/libtermnet.so.2/ a <tt/libtermnet.so.2.x.x/. 

Finalmente se ejecuta <tt/ldconfig/ para crear los enlaces necesarios y el
caché (para uso del enlazador dinámico, <tt/ld.so/) para las librerías
compartidas más recientes que se encuentran en los directorios
especificados en la línea de comandos, en el fichero
<tt>/etc/ld.so.conf</tt>, y en los directorios permitidos
(<tt>/usr/lib</tt> y <tt>/lib</tt>). 

Si la instalación se hace correctamente, los tres ficheros de librería
podrán ser usados por los clientes de <tt>term</tt> que son generados con
librerías dinámicas en lugar de estáticas. Estas librerías también se
pueden usar ahora para portar tu software propio a fin de poderlo usar con
el <tt>term</tt> (ver más adelante).

<sect1> Estableciendo variables de entorno.

<p>

<tt>term</tt> reconoce un par de variables de entorno que pueden definir los
usuarios. Las tres primeras de éstas que se explicarán son:

<itemize>
<item><tt/TERMDIR/
<item><tt/TERMSHARE/
<item><tt/TERMMODE/
</itemize>

Definiendo estas variables puedes controlar el modo en que se ejecuta el 
<tt>term</tt>.

Para versiones del <tt>term</tt> hasta la 1.15 sólo es importante la
variable <tt/TERMDIR/ (estas versiones no reconocen el modo <it/shared/).
Para estas versiones <tt/TERMDIR/ se debería definir como sigue: 

<tscreen><verb>
setenv TERMDIR $HOME     # csh o tcsh
export TERMDIR=$HOME     # bash
</verb></tscreen>

A partir de la versión 1.16 <tt>term</tt> también reconoce las variables
<tt/TERMSHARE/ y <tt/TERMMODE/. Con estas variables se le puede indicar al
<tt>term</tt> que funcione en modo privado o en modo compartido. 
Explicaremos como definir las variables para ambos modos.

<enum> 
<item> Ejecutar <tt>term</tt> en modo privado puede hacerse
definiendo las variables <tt/TERMDIR/ y <tt/TERMMODE/ de la siguiente forma:

   Para <tt/csh/ o <tt/tcsh/:
<tscreen><verb>
   setenv TERMDIR $HOME
   setenv TERMMODE 0
</verb></tscreen>

Para <tt/bash/: 

<tscreen><verb> 
export TERMDIR=$HOME export TERMMODE=0 
</verb></tscreen>
 
<item>Si quieres usar el <tt>term</tt> en modo compartido hay dos formas
de definir las variables:

<enum>
<item> Si <tt>term</tt> se instala como un programa <tt/SUID/ sólo se debe 
definir <tt/TERMMODE/. (<tt/README/ en el paquete del <tt>term</tt>).

<tscreen><verb>
      setenv TERMMODE 'numero'    # csh o tcsh
      export TERMMODE='numero'    # bash
</verb></tscreen>

   En <tt/'numero'/ debe ponerse 1 si se está usando una versión del
<tt>term</tt> entre la 1.16 y la 1.19 (<tt/README.share/ en el paquete del
<tt>term</tt>) y 2 si se está usando la versión de <tt>term</tt> <tt/2.0.0/ o
superior (<tt/README.security/ en el paquete del <tt>term</tt>). 

<item> Si <tt>term</tt> se instala como un programa <tt/SGID/ las variables se 
deben definir del siguiente modo:

Para <tt/csh/ o <tt/tcsh/:

<tscreen><verb>
      setenv TERMMODE 1
      setenv TERMDIR /usr/local/lib/term
      setenv TERMSHARE $TERMDIR
</verb></tscreen>


Para <tt/bash/:

<tscreen><verb>
   export TERMMODE=1
   export TERMDIR=/usr/local/lib/term
   export TERMSHARE=$TERMDIR
</verb></tscreen>

Poniendo las variables de esta forma hará posible que se ejecuten clientes
viejos (<it/linkados/ con una versión antigua del <tt/client.a/) en modo 
compartido (shared).

</enum> 

</enum>

A partir de la versión <tt/2.0.0/, <tt>term</tt> también reconoce la variable
<tt/TERMSERVER/.  Se necesita definir esta variable cuando se tienen
varios módems y mas de una conexión a la vez. Para especificar que
conexión usar, se debe ejecutar el <tt>term</tt> con un nombre de
servidor: 

<tscreen><verb> 
nohup term -v /dev/modem1 Connection1 & nohup term -v /dev/modem2 Connection2 &
</verb></tscreen> 

Los usuarios deberían definir la variable <tt/TERMSERVER/ con el nombre
de conexión que quieran usar:  

<tscreen><verb> 
setenv TERMSERVER Connection1     	# csh o tcsh  
export TERMSERVER=Connection2     	# bash  
</verb></tscreen>

<sect1> Probar el <tt>TERM</tt>

<p> 

Haz un <tt>make test</tt> (o <tt>make termtest</tt> para versiones nuevas
del <tt>term</tt>) para generar el demonio de prueba del <tt>term</tt>. 
<tt>(term)test</tt> funciona ejecutando dos copias del <tt>term</tt> en tu
sistema, una ``local'' y una ``remota''. Ambas leerán tu <tt/termrc/; de
modo que puedas ajustar su comportamiento. Ahora ejecuta
<tt>(term)test</tt>. Deberías poder hacer un <tt>trsh</tt> y un
<tt>tupload</tt>.  Prueba con:

<tscreen><verb>
 tupload ./term /usr/tmp
</verb></tscreen>

deberías de conseguir tener una copia del binario <tt>term</tt> en
<tt>/usr/tmp</tt> ). La salida del <tt>term</tt> local debería aparecer en
<tt>local.log</tt> y la remota en <tt>remote.log</tt>. Puedes ejecutar
<tt>term</tt> con el parámetro <tt>-d255</tt> para poder registrar lo que
ocurra en estos ficheros, o habilitar el <it/debugging/ en tu <tt/termrc/.

NOTA: Ejecuta el <tt>test</tt> como <tt>./test</tt> para evitar el
<tt>test</tt> del sistema. 

<sect1><tt>TERM</tt> y los programas de comunicaciones.

<p>

Antes de poder usar <tt>term</tt>, tienes que establecer una conexión vía
módem usando un programa de comunicaciones como <tt/kermit/ o <tt/seyon/.
En la documentación del programa encontrarás qué tienes que hacer para
conectarte con la máquina remota. 

Cuando hayas establecido la conexión y quieras ejecutar <tt>term</tt>,
necesitas suspender o salir del programa de comunicaciones sin cerrar la
conexión. 

A continuación explicaré cómo hacer esto con algunos programas de
comunicaciones.

<sect2><tt/kermit/

<p>

Iniciar <tt>term</tt> cuando se usa <tt/kermit/ es fácil. En el
<it/prompt/ local de <tt/kermit/ se teclea ``<it/suspend/'', de modo que
volverás al prompt de Linux. Desde este prompt puedes ya establecer la
conexión <tt>term</tt>.

<sect2><tt/seyon/

<p>

Una forma de iniciar chequeo de línea o <tt>TERM</tt> cuando usas
<tt/seyon/ es poner <tt/linecheck/ y <tt>TERM</tt> en el menú
<tt/Transfer/ (controlado por el fichero 
<tt>&dollar;HOME/.seyon/protocols</tt>). 

Añade al fichero <tt>&dollar;HOME/.seyon/protocols</tt> lo siguiente:

<tscreen><verb>
"Line check" "$cd /tmp; linecheck"
"Term" "$term -c off -w 10 -t 150 -s 38400 -l $HOME/tlog"
</verb></tscreen>

Ahora, cuando inicies <tt/linecheck/ o <tt>term</tt> en la máquina local,
selecciona en el menú <tt/Transfer/ el ítem ``<tt/Line Check/'' o
``<tt/Term/''. 

Por supuesto, también podrías usar el botón de comando de shell y
teclear en el cuadro de diálogo que se te abrirá los comandos <tt/linecheck/ o
<tt/term/. Esto mismo hace redirección automática al comando.

<sect1> Hacer un enlace transparente.

<p>

Presumiblemente, puedes establecer una conexión módem entre tus hosts 
local y remoto. Típicamente lo que haces es, llamar a algún tipo de 
servidor de terminales y conectas con tu host remoto a través de él. 

También sueles usar para ello software de terminal, como <tt/kermit/ o
<tt/seyon/ para comunicar con tu módem (los ejemplos de este documento
usan el <tt/kermit/, ya que es el que usa el autor). Si estás teniendo
problemas con el módem, o con el software de terminal, echa una ojeada al
<it/Serial HOWTO/; esto debería ayudarte. 

Una vez establecido el enlace, querrás hacerlo lo más transparente
posible.  Comprueba los comandos en el servidor de terminal (<tt/help/ o
<tt/?/ suele ser un buen comienzo). Busca la opción <it/8 bits/ siempre
que sea posible. Esto puede implicar cambiar la forma en que accedes a tu
sistema, por ejemplo, si el servidor usa <tt/rlogin/, tendrás que usarlo
poniendo el parámetro <tt/-8/ para hacerlo transparente. 

Especialmente vigila el control de flujo por <it>xon/xoff</it>. No lo
necesitas. Intenta habilitar el control de flujo por hardware,
<it>rts/cts</it>. Puede que tengas que mirar la documentación de tu módem para
saber cómo configurarlo para hacer comunicaciones <it>rts/cts</it> de 8
bits. 

<sect1>Ejecutar <tt/linecheck/

<p>

<bf>ATENCIÓN:</bf> En algunos documentos las opciones de línea de comandos
para <tt>linecheck</tt> se citan en orden incorrecto. He comprobado esto y
he hallado que el orden de las opciones que menciono aquí abajo es el
correcto. 

<bf>NOTA:</bf> a partir de la versión de <tt>term</tt> 2.3.0
<tt/linecheck/ ya no necesitará tener el nombre del fichero de log en la
línea de comandos.  Escribirá su salida al fichero <tt/linecheck.log/ en
el directorio desde el que se ejecute <tt/linecheck/.

<tt/linecheck/ es un programa que se entrega con el <tt>term</tt>.
Comprueba la transparencia de un enlace, produciendo información de
configuración que necesita el <tt/term/ para funcionar correctamente.
<tt/linecheck/ manda todos los 256 caracteres de 8 bits posibles sobre el
enlace y verifica que cada uno se transmite correctamente. 

Hay que configurar <tt/term/ para manejar caracteres que no pueden ser
transmitidos por el enlace, y <tt/linecheck/ determina cuáles son estos
caracteres. Debes usar <tt/linecheck/ después de haber establecido un
enlace módem lo más transparente posible. Para correr <tt/linecheck/ haz
lo siguiente:

<enum>  
<item>En el sistema remoto, ejecuta  <tt>linecheck linecheck.log</tt>

<item>Vuelve a tu sistema local y suspende tu programa de comunicaciones
(<tt/^Z/ en <tt/kermit/) (si no te robará caracteres del <tt/linecheck/).

<item>En el sistema local ejecuta 

<tscreen><verb>
linecheck linecheck.log > /dev/modem < /dev/modem
</verb></tscreen>

</enum>

Cuando termine <tt/linecheck/ encontrarás un conjunto de números al final
de los ficheros <tt/linecheck.log/. Estos son los que deberías poner como
'escape' en el <tt/termrc/ al otro lado del enlace. Por ejemplo, mi
<tt/linecheck.log/ local decía que 'escape' era el 29 y 157. Así que, mi
<tt/termrc/ local escapa (evita) estos caracteres y mi <tt/termrc/ remoto
ninguno. Si se escapa (evita) un carácter en un extremo, también debo
ignorarlo (ignore) en el otro; así que, en este ejemplo, debería ignorar
29 y 157 en mi sistema remoto. 

Si <tt/linecheck/ se cuelga, prueba a usar

<tscreen><verb>
linecheck linecheck.log 17 19
</verb></tscreen>

en el sistema remoto, y 

<tscreen><verb>
linecheck linecheck.log 17 19 > /dev/modem < /dev/modem
</verb></tscreen>

en el sistema local. Esto evitará tus caracteres de <it>xon/xoff</it>
(control de flujo), que colgarán tu línea si tienes control de flujo por
software. Si soluciona los problemas de cuelgues, tendrás que
escapar/ignorar 17/19 en ambos <tt/termrc/. Si tu servidor de terminal
tiene otros caracteres que lo cuelguen, prueba a correr <tt/lineckeck/ con
esos caracteres escapados como el ejemplo de arriba. Puedes marcar esos
caracteres si <tt/linecheck/ se cuelga.  Si es este el caso, mátalo, y
luego mira en los logs. Los últimos caracteres transmitidos es probable
que sean los culpables. Vuelve a intentarlo escapando estos caracteres. 

En resumen, mi <tt/termrc/ local tiene las líneas:

<tscreen><verb>
escape 29
escape 157
</verb></tscreen>

y mi <tt/termrc/ remoto tiene las líneas:

<tscreen><verb>
ignore 29
ignore 157
</verb></tscreen>

ya que mi <tt/linecheck.log/ remoto decía que 'escape 29 y 157'.

<sect1> Prueba a correr el <tt>TERM</tt> 

<p> 

Accede a tu sistema remoto, haciendo el enlace lo más transparente posible
(si no lo has hecho aún).  Arranca <tt>term</tt> en el extremo remoto. Yo
lo hago así: 

<tscreen><verb> 
exec term -r -l $HOME/tlog -s 38400 -c off -w 10 -t 150
</verb></tscreen> 

Vamos a desgranar las opciones una por una (ten en cuenta que con igual
facilidad podría poner estas opciones en mi <tt/termrc/. Lo hice así
porque evitaba tener que editar un fichero mientras ponía a punto el
<tt>term</tt>).

<tt>exec</tt> implica destruir la <it/shell/ actual, corriendo en su lugar
el programa indicado. Ejecuto las cosas con <tt/exec/ porque no pretendo
usar mi <it/shell/ de login de nuevo; estaría desperdiciando memoria. Si
estás depurando el enlace y eres capaz de abortar el <tt>term</tt> remoto,
puede que no quieras hacer el <tt/exec/.

La opción <tt/-r/ es necesaria sólo en un extremo. <tt>term</tt> verá a
este extremo como el remoto de la conexión (ten en cuenta que el extremo
remoto del <tt>term</tt> puede ser tu propia máquina local). Si no usas
esta opción en un extremo los clientes de <tt>term</tt> se caerán
espontáneamente. 

<tt>-l &dollar;HOME/tlog</tt>. Esto registra los errores en el fichero
<tt/tlog/ en mi directorio <it/home/. Muy útil para depurar. No hay razón
para no ponerlo. 

<tt>-s 38400</tt> : Tengo un módem 14400, con compresión. Para ratios de
compresión óptimos, necesito poder mandar bits al <it/pipe/ lo más rápido
posible. Para un módem más lento, debería ser un número menor. Fíjate que
si tienes una <it/UART/ 16450 en tu puerto serie, las velocidades altas
pueden provocar pérdida de datos por desbordamiento del chip de tu puerto
serie.  <tt>term</tt> se recuperará de esto, pero si ves muchos mensajes
en tu log, (o recibes <it/``overrun warnings''/ en versiones del kernel
<tt/0.99pl15/ en adelante) necesitarás reducir este número. 

<tt>-c off</tt> : Desactiva la compresión de datos. Tengo un módem con
compresión, y no necesito comprimir las cosas dos veces.

<tt>-w 10 -t 150</tt> : De nuevo estas son opciones para optimizar mi
enlace de módem rápido. Pongo mi <it/ventana/ a 10 y mi <it/timeout/ a 150.
Esto lo hago de acuerdo con la recomendación de la página de manual de
<tt/term&lowbar;setup/. 

Vuelve sobre tu máquina local y suspende tu programa de comunicaciones
(<tt/^Z/ en <tt/kermit/). No querrás que esté corriendo a la vez que
<tt>term</tt>, ya que lucharía con el <tt>term</tt> por el puerto serie.
Si puedes convencer a tu módem de que no cuelgue cuando salgas de tu
programa de comunicaciones (cuando cambia el <tt/DTR/), podrías salir del
programa en este punto.

Ahora lanza el <tt>term</tt> local. Yo uso:  

<tscreen><verb> 
term -c off -l $HOME/tlog -s 38400 -w 10 -t 150 < /dev/modem > /dev/modem &
</verb></tscreen>

Necesito decirle al <tt>term</tt> donde está el módem; Así que apunto
tanto la entrada como la salida estándar a <tt>/dev/modem</tt> (eso es lo
que hacen <tt>&lt;</tt> y <tt>&gt;</tt>).  También lo hago correr en
<it/background/; de modo que puedo usar esta consola para otra cosa si la
necesito. 

<tt>term</tt> debería de funcionar ya <tt/:-)/. Prueba con <tt>trsh</tt>,
a ver qué pasa. Si se cuelga, o el enlace parece lento, echa una ojeada a
tu <tt/tlog/ en ambos extremos. ¿Tienes <it/timeouts/ o mensajes de error?
Si es así, entonces es que has configurado algo mal. Vuélvelo a intentar
(después de que hayas terminado de leer esto <tt/:-)/. Observa que la
conexión no parecerá muy rápida, especialmente si usas compresión - será
un poco a saltos. La velocidad real aparece durante transmisiones de
ficheros y similares.

<sect1>Terminar tu conexión <tt>term</tt> 

<p> 

Muy probablemente, una vez que hayas hecho un montón de trabajo usando el
<tt>term</tt>, querrás terminar el trabajo y deshacer tu conexión
<tt>term</tt>. Para poder hacer esto hay cuatro formas: 

<enum>
<item>Matar (<tt/kill/) los programas <tt>term</tt> a ambos lados de la
conexión. Esta es la forma menos recomendada de terminar tu conexión.
<item>Una forma mejor es ejecutar el siguiente comando localmente:

<tscreen><verb>
   echo '00000' > /dev/modem
</verb></tscreen>

 Esto terminará la conexión <tt>term</tt> correctamente. Funcionará en
todas las versiones del <tt>term</tt>. Hay que asegurarse de que la
secuencia contiene al menos cinco ceros. 

<item>En el <tt/termrc/ de versiones 2.0.0 y superiores se puede incluir
una sentencia <tt>terminate &lt;cualquier cadena&gt;</tt>. Esto establece
una cadena que hará que salga del <tt>term</tt> (``<tt/00000/'' por
defecto). Debe ser de una longitud de 5 caracteres por lo menos, para
evitar terminaciones accidentales. 

<item>A partir de la versión 1.14 existe el programa <tt/tshutdown/
(realmente para la versión 1.14 está disponible como <it/patch/, para
versiones más recientes se incluye en el paquete). Ejecutando
<tt/tshutdown/, la conexión <tt>term</tt> finalizará perfectamente. 

</enum>

<sect1>Cómo eliminar <tt>TERM</tt> de tus particiones.

<p>

Ok, me habéis preguntado por esto. Así que voy a presentar los pasos a
seguir para desinstalar <tt>term</tt>:

<itemize>
<item>Eliminar directorios con su contenido. Dependiendo de cómo hayas
instalado <tt>term</tt>, tendrás uno o más de los siguientes directorios:

<tscreen><verb>
$HOME/.term/termrc
$HOME/.term/termrc.<servidor>
$HOME/term/termrc
$HOME/term/termrc.<servidor>
/usr/local/lib/term/termrc
/usr/local/lib/term/termrc.<servidor>
/etc/termrc
/etc/termrc.<servidor>
</verb></tscreen>

Estos directorios pueden eliminarse con su contenido, usando 

<tscreen><verb>
/bin/rm -rf 
</verb></tscreen>

<item>El grupo <it/term/. En algún momento de la instalación tuviste que
crear un grupo llamado <it/term/. Busca en <tt>/etc/group</tt> una línea
con ese grupo y bórrala. 

<item>Los ejecutables y paquetes del <tt>term</tt>. Esta es la parte más
difícil. Para los ejecutables, busca en el directorio
<tt>/usr/local/bin</tt> o <tt>&dollar;HOME/bin</tt>. 

Con otros ejecutables que hiciste compatibles con <tt>term</tt> no puedo
ayudarte. Necesitas saber qué ejecutables modificaste para saber cuáles
borrar. No olvides ficheros de configuración y otros que vengan con esos
ejecutables. 

<item>Ficheros de librería. Lo mejor es teclear lo siguiente:

<tscreen><verb>
cd /
find . -name libtermnet* -exec /bin/rm {} \;
</verb></tscreen>

Esto encontrará y borrará todos los ficheros de librería relacionados
por todo tu disco duro.

<item>Ficheros <tt>include</tt>. De nuevo, lo mejor es que teclees esto:

<tscreen><verb>
cd /
find . -name termnet.h -exec /bin/rm {} \;
</verb></tscreen>

<item>Manuales en línea. Cuando instalaste <tt>term</tt> los manuales
se colocaron en uno de los directorios siguientes:

<tscreen><verb>
/usr/local/man/man1
/usr/local/man/cat1
$HOME/man/man1
$HOME/man/cat1
</verb></tscreen>

Debes buscar por lo menos las siguientes páginas de manual:  <tt>term,
term_clients, term_setup, tdownload, linecheck, trdate, trdated, termrc,
termtest, tmon, tredir, trsh, tshutdown, tudpredir, tupload,
txconnand</tt> y por último, <tt/tiptest/. 

<item>Directorio temporal del usuario. Borra el directorio
<tt>/usr/tmp/private</tt> y sus contenidos. 

</itemize>

Después de todo este ejercicio, podrás estar bastante seguro de que
has borrado todo lo relacionado con <tt>term</tt>.

<sect1> Optimización de la conexión <label id="optimizando">

<p> 

Una vez que consigues ejecutar el <tt>term</tt>, puede que quieras intentar
optimizar las cosas. Una buena forma de medir la velocidad de tu enlace es
corriendo <tt>tmon</tt> en una ventana mientras transfieres un fichero en
otra. Intenta con ficheros de texto y ficheros comprimidos suficientemente
grandes; el texto a secas debería dar un factor del doble de rápido que el
comprimido. Los parámetros que querrás ajustar son <tt/baudrate/
&lsqb;velocidad del puerto&rsqb;  (<tt>-s</tt>), <tt/compression/
(<tt>-c</tt>), <tt/windows/ &lsqb;tamaño de ventana&rsqb;  (<tt>-w</tt>),
<tt/timeout/ &lsqb;tiempo de espera&rsqb; (<tt>-t</tt>) y <tt/retrain/
(<tt>-A</tt>). 

Cuidado con el parámetro <tt/retrain/. Con la versión 1.19 del
<tt>term</tt> obtengo peor rendimiento, que va de un 80% a un 90%
comparado con la ejecución del <tt>term</tt> sin el parámetro
<tt/retrain/. No está claro si se trata de un <it/bug/ en la versión 1.19
y si este problema existe sólo en la versión 1.19 del <tt>term</tt>. 

<tt>Baudrate</tt>: el número máximo de bits por segundo que el
<tt>term</tt> intentará enviar a través del enlace serie. <tt>term</tt>
evitará enviar caracteres a una velocidad superior a ésta. Por defecto se
usa la velocidad del puerto serie del ordenador, pero hay que avisar 
que ésta puede ser demasiado alta si el módem funciona a una velocidad
menor sobre la línea telefónica. La opción <tt/baudrate/ está indicada
para sistemas que almacenan en <it/buffer/ la salida al módem. Durante la
configuración y el ajuste es mejor usar un <tt/baudrate/ pequeño que uno
que sea demasiado grande. Para enlaces de alta velocidad (&gt; 38400),
ponerlo sin límite será probablemente ventajoso. Esto se consigue usando
el valor <it/off/. <tt>term</tt> confiará entonces solamente en el kernel
para controlar el flujo.

<tt>Compression</tt>: necesitarás poner en <it/on/ si no tienes un módem
con compresión. Si tienes un módem de éstos, pon <it/compression off/, de
lo contrario estarás comprimiendo las cosas dos veces, lo que
habitualmente <it>incrementa</it> la cantidad de datos transmitidos. Los
módems con compresión son aquellos que usan los protocolos <it/MNP-5/ o
<it/V42.bis/. Observa la documentación del módem y el mensaje del módem
cuando conecta. 

<tt>Windows</tt>: este es el número de unidades de datos, o paquetes, que
el <tt>term</tt> enviará por la línea antes de obtener reconocimiento
(<it/ack/) desde el <tt>term</tt> remoto. Para módems rápidos, aumentar
esto puede ser una mejora; para enlaces más lentos esto puede saturar el
extremo remoto.

<tt>Timeout</tt>: el tiempo que el <tt>term</tt> esperará a un <it/ack/.
Si has aumentado <tt/windows/ y estás teniendo <tt/timeouts/ en el fichero
de log, prueba a aumentar este valor. 

Para un <it>14400/V42.bis</it>, yo uso <tt/-c off -w 10 -t 150/. Consigo
unos 1700 <it/cps/ en ficheros comprimidos y 3500 <it/cps/ en ficheros
ASCII usando <tt/tupload/.

<sect1>Resolución de problemas

<p>

En esta sección se dan algunas opiniones sobre qué comprobar cuando se
tienen problemas ejecutando el <tt>term</tt> o alguno de sus clientes.

<itemize> 

<item>¿Has borrado la estructura de directorios del <tt>term</tt>? En las
nuevas versiones del term ha cambiado un par de veces la estructura del
árbol de directorios bajo <tt>/usr/local/lib/term</tt>. Si no te has dado
cuenta de ello, puedes haber causado todo tipo de mensajes de error.  Lo
mejor es borrar el árbol de directorios bajo <tt>/usr/local/lib/term</tt>
(salvando tu <tt/termrc/) y entonces instalar la nueva versión. De esta
forma evitas pelearte con un árbol de directorios lioso. 

<item>¿Borraste los <it/sockets/ antiguos? Cuando pongas al día tu versión
del <tt>term</tt> borra todos los <it/sockets/ (llamados <tt/socket=/) creados
por el <tt>term</tt>. El no hacer esto puede causar extraños problemas.
Para averiguar qué <it/socket/ está atendiendo el <tt>term</tt>, puedes
usar el programa <tt/netstat/. 

<item> ¿El <tt>term</tt> no compila correctamente en SunOS 4.1.3? Has
configurado el <tt>term</tt> con <tt>./configure --user</tt>. Durante la
compilación estás teniendo un error de ensamblador, relacionado con que el
parámetro <tt/-k/ no es reconocido.  La razón de este error es
desconocida. La solución es configurar el <tt>term</tt> con librerías
estáticas. Es decir, tendrás que hacer <tt>./configure --user
--static</tt> y entonces seguir con el proceso de compilación como sueles
hacerlo normalmente. Ahora el <tt>term</tt> debería compilar correctamente.

<item>¿El <tt>termtest</tt> te está presentando el error: 

<tscreen><verb>
Term: failed to connect to term socket '/root/.term/sockettest'
</verb></tscreen>

(Term: falla la conexión al socket de <tt>term '/root/.term/sockettest'</tt>) 

Cuando <tt/termtest/ corre espera que el ejecutable <tt/term/ esté en el
mismo sitio que éste. Cuando haces un <tt/make install/ antes de ejecutar
<tt/termtest/, el binario de <tt/TERM/ es movido a <tt>/usr/local/bin</tt>
(u otro similar). 

Para ello hay que hacer algo parecido a esto:

<tscreen><verb>
ln -s /usr/local/bin/term /usr/src/term-<numero_de_version>/term
</verb></tscreen>
</item>

<item>¿Estás usando el binario adecuado? El <tt>term</tt> se ha modificado
bastante, y muchos sistemas tienen versiones diferentes de los programas
rondando por ellos. Asegúrate de que estás usando la versión correcta.
Esto también se aplica al <tt/linecheck/. Puede usarse una orden del tipo
<tt/bash -a/, o el comando <tt/whereis/ para saber qué programa se está
ejecutando. Las versiones de <tt>term</tt> posteriores a 1.11 deberían
mostrar su número de versión al comenzar. (Aunque la versión 1.14 dice ser
la 1.12. Sigh.) 

<item>¿Tienes el <tt/termrc/ correcto en el lugar adecuado? Dependiendo de
la versión de <tt>term</tt> que estés corriendo y el modo en que
instalaste el <tt>term</tt> (siendo <tt/root/ o usuario) este fichero debe
estar en uno de los siguientes directorios: 

<tscreen><verb>
   /usr/local/lib/term/termrc
   /usr/local/lib/term/termrc.<servidor>
   /etc/termrc
   /etc/termrc.<servidor>
</verb></tscreen>  

Algunos sistemas tienen <tt/termrc/'s preinstalados; asegúrate de que no
estén antes de instalar. Si estás ejecutando cosas como <tt/root/, busca
en <tt>/.term</tt>. 

El <tt>term</tt> crea ficheros (<it/sockets/ en realidad) mientras se
ejecuta;  de modo que tiene su propio directorio, <tt>&tilde/.term</tt>,
donde está el fichero <tt/termrc/ (nótese, ¡no hay un punto precediendo a
<tt/termrc/!). 

<item>¿Encuentra el <tt>term</tt> su fichero <tt/termrc/? Cuando inicias
<tt>term</tt> a ambos lados, deberías ver mensajes como este de abajo: 

<tscreen><verb>
   Term version: 2.2.9
   Reading file:  /usr/local/lib/term/termrc
   Using shared mode.
</verb></tscreen>

Cuando falta la segunda línea el <tt>term</tt> no puede encontrar su
fichero <tt/termrc/ y sabes que algo ha ido mal durante la instalación (a no
ser que no estés usando el fichero <tt/termrc/ y estés introduciendo todas
las opciones en línea de comandos <tt/:-)/. Comprueba la localización y
los permisos del fichero <tt/termrc/ en el lugar donde <tt>term</tt> no
puede encontrar su fichero <tt/termrc/.</item>

<item>¿Es correcta la sintaxis de las entradas en el <tt/termrc/? Un
problema común es que la gente que necesite usar el escape e ignorar
ciertos caracteres, los introduzca así en el fichero <tt/termrc/: 

<tscreen><verb>
escape 1,4,30,255
ignore 1,4,30,255
</verb></tscreen>

Aunque si <tt>term</tt> no reconoce lo anterior tampoco avisará de
ello. Simplemente lo ignorará.

Cuando tienes que ignorar o ``escapar'' caracteres, tendrás que ponerlos
en diferentes líneas del fichero <tt/termrc/, cada línea comenzando por la
palabra <tt>escape</tt> o <tt>ignore</tt>. Sólo cuando haya que hacerlo
con varios caracteres deberá hacerse de la siguiente forma: 

<tscreen><verb>
escape 16-19      # escapar caracteres 16, 17, 18, 19
escape 23         # 23
escape 255        # ...y 255
ignore 16-19      # ignorar caracteres 16, 17, 18, 19
ignore 23         # 23
ignore 255        # ...y 255
</verb></tscreen>

<item>¿Está montado tu directorio <tt/term/ o <tt/.term/ con <it/NFS/? Si
tu directorio <tt/term/ o <tt/.term/ está montado con <it/NFS/ necesitas
poner el parámetro <tt/-DTERM&lowbar;NFS&lowbar;DIR/ en la línea
<tt/CFLAGS/ del <tt/Makefile/. Aunque, al autor el usar este parámetro
le produce un error de compilación al compilar <tt>term</tt> 1.19 en una
máquina con <it/SunOS 4.*/. 

<item>¿Pertenecen los ficheros y directorios al usuario y grupo correcto y
tienen los permisos adecuados? Esto no debería ser problema ya que estos
permisos se ponen durante la fase de instalación. Sin embargo, cuando
portas tus propios programas a <tt>term</tt> debes prevenirte de ello.
También cuando se cambia el modo en que esta trabajando <tt>term</tt> (por
ejemplo de modo privado a modo shared) deben adaptarse las propiedades y
permisos de ficheros y directorios. 

<item>¿Estás obteniendo el error <tt>gethostbyname: &lt;hostname&gt;:
Non-authoritative `host not found', o `server failed'</tt>?

   Para resolver esto tienes que chequear las siguientes cosas:

<enum> 

<item>¿Está configurado correctamente el fichero <tt>/etc/hosts</tt>? 
<tt/&lt;hostname&gt;/ no es el nombre de tu host (las versiones viejas de SLS y
algunas viejas y nuevas versiones Slackware se entregan con el
<tt/hostname/ <it/darkstar/, por ejemplo). Cambia esto en el fichero. Debe
contener al menos una línea como la que sigue (el formato se describe
encima de ella): 

<tscreen><verb>
# Formato del fichero:
#  IP_NUMBER            HOSTNAME        ALIASES
#
# Este es el nombre de tu maquina, en primer lugar, seguido de aliases
#
127.0.0.1       localhost       linuxpc.dominio  linuxpc
</verb></tscreen>

Cuando tu única conexión con el exterior se hace mediante <tt>term</tt>,
la línea anterior es la única que debe aparecer en <tt>/etc/hosts</tt>. No
pongas otros nodos de Internet en ese fichero, pues <tt>term</tt> no
trabajará con ellos. 

<item>¿Puede leer todo el mundo tus ficheros <tt>/etc/rc*</tt> y
<tt>/etc/resolv.conf</tt>? 

<tscreen><verb>
chmod ugo+r
</verb></tscreen>

<item>Por último, asegúrate de haber instalado el <it/loopback-interface/
de <it>TCP/IP</it> en tu máquina. Puedes comprobarlo ejecutando el comando
<tt/ifconfig/. Cuando está instalado dicho interface, se verá lo siguiente
en pantalla: 

<tscreen><verb>
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.255.255.0
          UP BROADCAST LOOPBACK RUNNING  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0
          TX packets:4984 errors:0 dropped:0 overruns:0
</verb></tscreen>

Durante el arranque también puedes ver qué protocolos se utilizan. En
mi máquina aparece lo siguiente:

<tscreen><verb>
IP Protocols: ICMP, UDP, TCP
</verb></tscreen>

Para más información sobre cómo instalar el <it/loopback-interface/, léete
el <it/NET-HOWTO/.

</enum>

<item>¿Estás obteniendo todo tipo de mensajes <tt/timed out/ en tus
ficheros log de <tt>term</tt>? Esto significa que tu conexión de
<tt>term</tt> no está optimizada. Un pequeño número de esos mensajes nunca
es problema. Estos son debidos muy posiblemente a que los factores
temporales influyen en la conexión física entre tus <it/hosts/ remoto y
local. 

Cuando tienes un montón de estos mensajes todo el tiempo, tu conexión se
ralentizará considerablemente. Tienes que ajustar los parámetros
mencionados en la anterior sección <ref id="optimizando">. Además, esta
parte de la instalación es un proceso de prueba y error. No se pueden dar
unas reglas fijas sobre los valores a colocar en los variados parámetros
ya que son muchos los factores que influyen en la conexión.  Estos
factores difieren entre las conexiones e incluso en el tiempo. 


<item>¿No te funcionan los <tt/ftp/ con puertos redirigidos? Es un
problema habitual con <tt/ftp/, que necesita trabajar con los puertos 20 y
21. La única solución es usar una versión <tt>TERM</tt>ificada de <tt/ftp/
o <tt/ncftp/. Sin embargo, algunas de estas aplicaciones adaptadas tampoco
funcionarán. 

</itemize>

<sect>Clientes <tt>TERM</tt> 

<p> 

<tt>Term</tt> proporciona varios clientes por defecto. Esto incluye
<tt>trsh</tt>, <tt>tmon</tt>, <tt>tupload</tt>, <tt>tredir</tt>,
<tt>txconn</tt> y en nuevas versiones <tt>trdate</tt>, <tt>trdated</tt>.
Además, a partir de la versión 2.0.0 está disponible <tt>tudpredir</tt> y
desde la versión 2.1.0 también <tt>tdownload</tt>.  Esta sección hará
referencia a <tt>trsh, tmon, tupload, tdownload, trdate</tt> y
<tt>trdated</tt>. El resto tiene su propia sección cada uno.  No
funcionará ningún cliente de <tt>term</tt> hasta que se haya establecido
un enlace <tt>term</tt>.

<tt>tmon</tt> es una utilidad simple para monitorizar las estadísticas del
enlace. Imprime un diagrama de tiempo de caracteres transmitidos y
recibidos. Se invoca simplemente como <tt/tmon/. Desde la versión 1.11,
<tt>tmon</tt> ha tenido un bug que provoca que alguna información se
trunque (??). 

<tt>trsh</tt> es similar a <tt>rsh</tt>. Sin argumentos, genera una shell
interactiva en el sistema remoto (esto es, te introduce directamente en el
sistema remoto). <tt>trsh</tt> es uno de las principales maneras de
acceder al extremo remoto del enlace a través de <tt>term</tt>. Si se le
pasa un argumento, <tt>trsh</tt> ejecuta ese argumento como un comando en
el sistema remoto. Por ejemplo, con <tt/trsh ls/ se obtendría una lista de
ficheros del directorio <it/home/ del sistema remoto.

<tt>tupload</tt> transfiere un fichero, si se indica como primer
argumento, desde el sistema local al remoto. Por defecto los ficheros se
pondrán en el mismo directorio desde el que se invocó <tt>term</tt> en el
otro extremo. Para colocar los ficheros en otro directorio se deben poner
sus nombres como segundo argumento a <tt>tupload</tt>. Por ejemplo, si se
desea poner una copia del fichero <tt/term114.tar.gz/ en <tt>/usr/tmp</tt>
en el sistema remoto, se escribiría <tt>tupload term114.tar.gz
/usr/tmp</tt>.

Cuando se usa <tt>tupload</tt> es posible utilizar comodines como en
<tt>tupload a.*</tt>.  La shell expande los comodines y llama a
<tt>tupload</tt> como <tt>tupload a.1 a.2 .....</tt>. 

<tt>tdownload</tt> transferirá un fichero, si se indica como primer
argumento, desde el sistema remoto al local. Por defecto, los ficheros se
colocarán en el mismo directorio desde el que se invocó al <tt>term</tt>
en el lado local. Para colocar los ficheros en otro directorio, hay que
indicar sus nombres como segundo argumento a <tt>tdownload</tt>. Por
ejemplo si se quiere poner una copia del fichero <tt/term114.tar.gz/ en
<tt>/usr/tmp</tt> del sistema local, escribiría <tt>tdownload
term114.tar.gz /usr/tmp</tt>. 

Cuando se usa <tt>tdownload</tt> no es posible utilizar comodines como
<tt/tdownload a.*./ La razón es que el directorio remoto no está
disponible para la shell local cuando se usa <tt>tdownload</tt>; de modo
que la shell local no puede expandir los comodines.

<tt>trdate</tt> es una utilidad de puesta en hora. Lee la hora en la
máquina remota y pone el reloj local con la hora del remoto. Se debe
ejecutar como <tt/root/. 

<tt>trdated</tt> es la versión demonio de <tt/trdate/. Cuando se pone en
marcha en <tt/rc.local/ se ejecuta como un demonio en cuyo caso ajusta el
tiempo cada 5 minutos (por defecto). Incluso si no existe conexión
<tt>term</tt>, este demonio se pondrá en marcha si se coloca en
<tt/rc.local/. Una vez que se cree una conexión <tt>term</tt>, comenzará a
ajustar la hora.

<sect>X y <tt>TERM</tt>

<p>

<tt>term</tt> permite a los usuarios abrir ventanas X en la máquina local
desde clientes que están corriendo en una máquina de la red. Esto se hace
usando el cliente <tt/txconn/. <tt/txconn/ se ejecuta en el remoto, la
máquina conectada en red; se invoca simplemente como <tt/txconn/. Se
coloca en background y devuelve un número a la salida estándard; este
número es el número de <it/display/ que los clientes deben usar para
acceder al servidor X de la máquina local. Un ejemplo aclarará ésto. Estoy
accediendo a mi cuenta, vía <tt/trsh/, en mi host remoto, llamado
``<tt/foo/''. En <tt/foo/ realizo lo siguiente: 

<tscreen><verb>
foo$ txconn
Xconn bound to screen 10
:10
foo$
</verb></tscreen>

Ahora, para cualquier host en el que quiera correr un cliente X, o sea, 
verlo en el servidor X de mi máquina local, haré:

<tscreen><verb>
setenv DISPLAY foo:10
</verb></tscreen>

(para <tt/bash/ debería usarse <tt>export DISPLAY=foo:10</tt>). En algunos
casos además de eso puede ser necesario hacer un <tt/xhost + foo/ en la
máquina local. Ahora, cuando arranque el cliente, intentará conectar con la
pantalla 10 de la máquina <tt/foo/, pero <tt/txconn/ estará escuchando en
esa pantalla, y pasará todos los paquetes con protocolo X vía
<tt>term</tt> al servidor X en el host local; es decir, la ventana se
abrirá en la máquina local. 

Es posible trabajar en el otro sentido - correr un cliente en la máquina
local y tener abierta la ventana en una máquina remota de la red; sin
embargo, retrasaremos esta explicación hasta después de haber comentado
<tt/tredir/. 

<tt/txconn/ no es terriblemente seguro; cualquiera puede conectar con el
servidor local vía <tt>term</tt> y provocar todo tipo de daños. Si este
tipo de cosas son preocupantes, podría ser una buena idea considerar el
uso de <tt/xauth/ para autorizar las conexiones. Consulte la página de
manual sobre <tt/xauth/. 

El protocolo X no es muy eficiente; desperdicia algo de ancho de banda. 
Esto no suele ser un problema en una ethernet, pero puede ser un crimen
vía módem. Se supone que X11R6 presenta una versión de bajo ancho de banda
del protocolo X, <it/LBX/. Si, por el contrario, se está usando X11R5
puede recurrirse a una utilidad llamada <tt/sxpc/ que comprime el
protocolo X, mejorando la respuesta sobre líneas serie. <tt/sxpc/ incluye
un texto sobre cómo hacerlo funcionar con <tt>term</tt>, y está
recomendado. El paquete <tt/sxpc/ también explica como usar <tt/xauth/;
por lo que está doblemente recomendado. 
 
<sect><tt>tredir</tt> 

<p> 

<tt>tredir</tt> es una de las utilidades más potentes de <tt>term</tt>,
permitiendo que la mayoría de los servicios de red importantes puedan
obtenerse en un enlace <tt>term</tt>. Antes de explicar cómo se usa
<tt>tredir</tt>, es necesario dar algunas nociones sobre los servicios de
red.

Ya se ha hablado antes sobre los servicios de red, pero no se ha dicho
exactamente qué son. Los servicios son justo eso - servicios que
proporciona la red. Ejemplos de servicios incluyen <tt/telnet/, que proporciona
logins entre máquinas, el <tt/ftp/ (<it/File Transfer Protocol/), o
Protocolo de Transferencia de Ficheros, que transfiere ficheros entre
máquinas, y <it/smtp/, el protocolo de transmisión de correo, que se usa
siempre que se envía un correo electrónico.

Cada servicio de red tiene un número de puerto asociado a él. El mapeo de
números de puerto con los servicios correspondientes se da en el fichero
<tt>/etc/services</tt>. Este fichero debería ser el mismo en todas las
máquinas conectadas a Internet.

¿Como se accede a estos servicios? Cada máquina en red corre un demonio
llamado <tt/inetd/, el cual escucha los intentos de conexión a los puertos
de red. Estas peticiones pueden llegar tanto desde la red, como desde la
propia máquina. Un servicio de red se obtiene conectando con un puerto
<tt/inetd/ en particular. Cuando se hace una solicitud de red, <tt/inetd/
conoce exactamente qué servicio está implicado, por el número de puerto al
que se hizo la solicitud. Si se configura <tt/inetd/ para hacerlo,
proporcionará el servicio adecuado a la conexión que lo solicita. La
configuración de <tt/inetd/ es la que se da en el fichero
<tt>/etc/inetd.conf</tt>, que contiene una lista de los servicios que
proporciona <tt/inetd/. Para más información vea las páginas de manual de
<tt/inetd/ e <tt/inetd.conf/. 

Se puede comunicar directamente con los servicios de red usando
<tt/telnet/ (nótese bien, no <tt/termtelnet/). Por ejemplo, para hablar
con el demonio de <tt/sendmail/ (o <it/smtp/) en la máquina
<tt/nombre&lowbar;de&lowbar;máquina;/, se puede hacer un <tt>telnet
nombre&lowbar;de&lowbar;máquina smtp</tt> , o <tt>telnet
nombre&lowbar;de&lowbar;máquina 25</tt>, (ya que 25 es el puerto asignado
a <tt/smtp/ en <tt>/etc/services</tt>). Debería obtener una agradable
bienvenida del demonio de la máquina remota. Este es un truco muy útil
para depurar problemas de red y chequear puertos redirigidos con
<tt>tredir</tt> (ver abajo). 

<tt>tredir</tt> funciona de modo similar a <tt/inetd/. Funciona en
<it/background/ como un demonio, escuchando los puertos de red, esperando
a una petición. Cuando se hace una solicitud de un servicio, en vez de
proporcionar ese servicio, como hace <tt/inetd/, <tt>tredir</tt> traslada
la solicitud a través del enlace <tt>term</tt> hasta el <tt>term</tt>
remoto, quien hace la solicitud a la red, devolviendo el resultado de
nuevo por el enlace hasta el cliente local. <tt>tredir</tt> puede
trasladar la solicitud a cualquier máquina de la red, pero por defecto la
envía a la máquina al otro extremo del enlace <tt>term</tt>.
<tt>tredir</tt> ``redirige'' los servicios <tt/TCP/ (<it/Transmision Control
Protocol/) a través del enlace <tt>term</tt>.

Un ejemplo lo aclarará. Vamos a redirigir un puerto local al puerto <tt/telnet/
de la máquina remota. Para hacer esto pondríamos <tt>tredir 2023 23</tt>.
Ahora, cualquiera que conecte al puerto 2023 de la máquina local será
redirigido al puerto 23 (<tt/telnet/) de la máquina remota. Aquí va una
sesión de ejemplo; la máquina local es <tt/mimaquina.modem.casa/ y la
remota es <tt/netsun/. 

<tscreen><verb>
$ tredir 2023 23
Redirecting 2023 to 23
$ telnet localhost 2023
Trying 127.0.0.1...
Connected to mimaquina.modem.casa
Escape character is '^]'.


SunOS UNIX (netsun)
login:
</verb></tscreen>

Este ejemplo es realmente muy útil. Si en su lugar hiciera el
<tt>tredir</tt> sobre <tt/netsun/, entonces podría hacer <tt/telnet/ a
<tt/mimaquina/ desde la red simplemente conectándome al puerto redirigido
de la máquina en red (usando <tt/telnet/) - esto es, <tt/telnet netsun
2023/.

El principio general de uso del <tt>tredir</tt> es redirigir el servicio
deseado a una máquina de la red. El siguiente ejemplo nos permitirá leer
las News en la máquina local a través del enlace <tt>term</tt> desde un
servidor de News de la red. Las News las proporciona el servicio
<tt/nntp/, puerto 119. Todos los lectores de News decentes permiten
especificar qué puerto van a utilizar, ya sea en un fichero de
configuración o en una variable de entorno. Vamos a especificar que el
puerto local sea el 2119.  Ahora supongamos que el servidor de News es
<tt/news.domain.org/; entonces le diremos al software de lectura de News
que el servidor <tt/nntp/ se encuentra en el puerto 2119 del <it/host/
local. Como esto dependerá del lector de News que se use, probaremos el
enlace con <tt/telnet/ en lugar de ejecutar un lector de News:

<tscreen><verb>
$ tredir 2119 news.domain.org:119
Redirecting 2119 to news.domain.org:119
$ telnet localhost 2119
Trying 127.0.0.1...
Connected to mimaquina.modem.casa.
Escape character is '^]'.
200 news.domain.org InterNetNews NNRP server INN 1.4 07-Dec-41 ready
(posting ok).
</verb></tscreen>

Si ha podido llegar tan lejos, todo lo que tiene que hacer es configurar
su lector de News para poder leer las News desde casa vía <tt>term</tt>. 
(nótese bien, si lee las News de este modo, asegúrese de que en todos los
mensajes que deje ponga una cabecera <tt/Reply-To:/ a una dirección de
correo en la que pueda ser localizado, o de lo contrario la gente que
quiera ponerse en contacto con Ud. mandará el correo a cualquier dato que
su lector de News ponga en la cabecera <tt/From:/).

<sect1> ¡<tt>tredir</tt> puede morder!

<p>

El astuto lector, tras leer el último ejemplo se preguntará porqué se
redirigió en puerto 2119 al puerto 119 --ya que el puerto por defecto de
los lectores de News es el 119--, ¿porqué no podría hacer un <tt>tredir
119 news.domain.org:119</tt> y evitar la configuración del lector de News?
La respuesta es que todos los puertos con números inferiores a 1024 son
``puertos reservados'', y únicamente el superusuario puede escucharlos. Si
se desea tomar un riesgo en seguridad y hacer de <tt/tredir/ un programa
<it/suid/, o ejecutar <tt/tredir/ como <tt/root/, entonces se pueden
redirigir puertos reservados y evitar así la molestia de renombrar
servicios. 

Otro problema de usar los puertos reservados es que <tt/inetd/ a menudo ya
está escuchando en esos puertos, y solamente un programa puede escuchar un
puerto a la vez. Si se quiere usar tal puerto, se debe cambiar
<tt/inetd.conf/ de modo que <tt/inetd/ ya no escuche en ese puerto que se
quiere redirigir.  Esto se hace fácilmente comentando la línea
correspondiente al servicio poniendo el carácter <tt/&num;/ al comienzo de
la misma. El superusuario tiene que mandar una señal <tt/HUP/ a
<tt>inetd</tt> (<tt>kill -1 &lt;inetd-pid&gt;</tt>) 
 para hacer que vuelva a leer su configuración. 

<sect1> Trucos tontos de <tt>tredir</tt>

<p>

En esta sección describiremos algunos de los usos más comunes de
<tt/tredir/. Ya hemos descrito como redirigir los servicios <tt/nntp/ y
<tt/telnet/; Ahora daremos algunos ejemplos más complicados. 
<sect2> X window

<p>

En una sección previa, se describió como hacer que un cliente X que corre
en la red abra una ventana en la máquina de casa usando <tt>txconn</tt>. 
La misma técnica se podría usar en la máquina de casa para mostrar un
cliente en la máquina del lado remoto del enlace <tt>term</tt>. ¿Pero cómo
puede uno ver un cliente X en una máquina de red que no es el extremo
remoto? La respuesta se basa en conocer que X usa un servicio de red
concreto igual que los otros programas que hemos explicado. Un servidor X
escucha peticiones de red en un puerto cuyo número viene dado por la
fórmula: <it>puerto = 6000 + número de display</it>, p.ej. un servidor X
manejando la pantalla 0 en una máquina escucharía el puerto 6000, si
estuviéramos manejando la pantalla 2, escucharía el puerto 6002. Si se
pone la variable de entorno <tt/DISPLAY/ en maquinaX:n, los clientes X
tratarán de conectar con el puerto <f>6000+n</f> de maquinaX.

Podemos usar esto para trucar los clientes X de la máquina local y abrir
ventanas en displays remotos. Supongamos que quiero abrir un
<tt>xterm</tt>, corriendo en mi máquina local, en el display 0 de la
máquina maquinaX, que esta corriendo en algún lugar de la red. Primero
escogeré un número de display local, digamos que el 2 (no se usa el 0, ya
que es el que estará usando el servidor X local). Mapearé este display al
display 0 de maquinaX.  En término de puertos, esto significa que quiero
redirigir el puerto local 6002 al puerto remoto 6000. Haré lo siguiente: 

<tscreen><verb>
$ tredir 6002 xmachine:6000 
$ setenv DISPLAY localhost:2
$ xterm 
</verb></tscreen>

Esto debería abrir un <tt>xterm</tt> en la máquina maquinaX. Observe que
he puesto el <tt/DISPLAY/ a <tt>localhost:2</tt>. Esto es porque los
clientes X usan a veces <it/sockets/ de dominio unix en lugar de
<it/sockets/ de dominio Internet, a su propio criterio, cuando conectan con
un display local, si <tt/DISPLAY/ se pone a <tt>:2</tt>.
<tt>localhost:2</tt> indica que use una conexión <tt/TCP/.

Observe que en lo que concierne a maquinaX, la solicitud X viene de la
máquina del extremo remoto del enlace <tt/term (máquinaremota)/ - de modo
que si necesita autorizar la conexión, debería hacer bien <tt>xhost +
máquinaremota</tt> en maquinaX, o bien usar <tt/xauth/ para actualizar el
fichero <tt/.Xauthority/ en su máquina local para el display número 2,
usando la clave de maquinaX.

De nuevo, para acelerar las conexiones X, se puede usar el programa
<tt>sxpc</tt>, que incluye una explicación sobre cómo usar <tt>tredir</tt>
para establecer el enlace y autorizarlo usando <tt>xauth</tt>.

<sect2> Correo con <tt>TERM</tt>

<p>

Está bien, vosotros lo pedísteis. El correo electrónico tiene la
justificada reputación de ser una de las cosas más dificiles de hacer
funcionar bien en un sistema UNIX. Para conseguir que el <tt>term</tt>
funcione correctamente con el correo es preciso entender cómo funciona el
correo, lo cual va más allá del objetivo de este documento.

Para aprender más sobre correo, debería consultar un libro de
administración de sistemas UNIX y/o la FAQ de la conferencia
<tt/comp.mail.misc/, disponible en el <tt/ftp/ anónimo de
<tt><htmlurl url="ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc"
name="ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc"></tt>.

También tiene a su disposición 2 paquetes en el <tt/ftp/ anónimo de
<tt/sunsite.unc.edu/ que le ayudarán a poner en marcha el correo bajo
<tt>term</tt> - son <tt/term.mailerd+smail/ de Byron A. Jeff y
<tt/BCRMailHandlerXXX/ de Bill C. Riemers. 

Como se ha dicho, haremos una breve descripción de como funciona el correo
electrónico. Hay dos partes que hacen funcionar el correo, el envío de
mensajes y la recepción de los mismos. Comenzaremos con el envío de
mensajes desde su ordenador local a la red. 

Hay dos clases de programas de correo. El primero es el <it/Agente de
Correo de Usuario/ (<it/MUA - Mail User Agent/). Los <it/MUA/s ayudan a
leer, componer y mandar mensajes. Ejemplos de <it/MUA/s son el
<tt>elm</tt>, <tt>pine</tt>, <tt>mail</tt> y <tt>vm</tt>. Los <it/MUA/s no
usan para nada la red; solamente agrupan los mensajes - el trabajo duro de
envío de correo se hace a través de la segunda clase de programas, los
agentes de transferencia de correo (<it/MTA - Mail Transfer Agent/). Estos
son invocados desde los <it/MUA/s. Toman el mensaje, deciden dónde
enviarlo observando la dirección, y finalmente lo envían a través de la
red. 

Los dos <it/MTA/s mas comunes en sistemas Linux son <tt>sendmail</tt> y
<tt>smail</tt>. La idea básica es hacer que su <it/MTA/ se conecte a otro
<it/MTA/ que esté corriendo en otra máquina de la red que sepa qué hacer
con su mensaje. Esto se consigue redirigiendo un puerto local hacia el
puerto <tt/smtp/ de la máquina en red.  Entonces debe indicar a su
<it/MTA/ que tome todos los mensajes con los que no sepa que hacer, y los
envíe fuera a través del puerto redirigido de su máquina local al <it/MTA/
de la máquina remota, la cual encaminará los mensajes hacia su destino
correcto.

¿Cómo hacemos esto usando <tt/smail/? Primero redirigiremos un puerto al
puerto <tt/smtp/ de la máquina de correo de la red (<tt>mailhost</tt>): 

<tscreen><verb>
tredir XXXX mailhost:25
</verb></tscreen>

donde <tt/XXXX/ es el número de puerto al que se conecta <tt>smail</tt> en
el host local (tenga en cuenta que hay que dar un nombre al puerto en
<tt>/etc/services</tt> para hacer que <tt/smail/ lo reconozca). <tt/smail/
tiene varios ficheros de configuración que generalmente están en
<tt>/usr/local/lib/smail</tt>.  Los que nos interesan son <tt>config,
routers</tt> y <tt/transports/.  Observar que presumimos que ya ha
configurado <tt/smail/ correctamente para el correo local - envío a
ficheros y tuberías y demás cosas. De nuevo, consulte la documentación si
no lo ha hecho.

En el fichero <tt/config/, ponemos la siguiente definición:      

<tscreen><verb>
smart_path=localhost
</verb></tscreen> 

<tt/localhost/ es la máquina a la que se conecta <tt/smail/ cuando no sabe que 
hacer con un mensaje.

En <tt/routers/ ponemos:

<tscreen><verb> 
smart_host: 
driver=smarthost, 
transport=termsmtp; 
path = localhost 
</verb></tscreen>

En <tt/transports/ ponemos:

<tscreen><verb>  
termsmtp:        driver=tcpsmtp, 
	inet,                    
	return_path, 
	remove_header="From", 
	append_header="From: SU_DIRECCION_DE_RED", 
	-received, 
	-max_addrs, -max_chars; 
	service=SU_SERVICIO_SMTP, 
</verb></tscreen>

En el de arriba, las líneas <tt/header/ cambian la cabecera <tt>From</tt>
en todo correo saliente por la dirección
<tt>SU_DIRECCION_DE_RED</tt>, que será la dirección de red a la que quiere
que le envíen el correo. Si su enlace <tt>term</tt> va a ser usado por más
de una persona, tendrá que hacer algo más laborioso, como mantener una
base de datos de direcciones de red de usuarios locales e insertar las
mismas en las cabeceras <tt>From:</tt>. 

La línea <tt/service/ es el nombre del número de puerto local que ha
redirigido al puerto <tt/smtp/ de la máquina conectada a la red. En mi
versión de <tt/smail/ no es posible ponerlo como un número, asi que tengo
que ponerlo como un nombre, como ``<tt/foo/'', y entonces definir
``<tt/foo/'' en <tt>/etc/services</tt> de modo que sea el número del
puerto redirigido. Si usa un <it/suid/ de <tt/tredir/ y se redirige el
puerto <tt/smtp/ (25), no es necesario definir esto. 

Esto debería ser suficiente para hacerlo funcionar. Si decide usar
<tt>sendmail</tt> la base es la misma pero difiere en los detalles. Ronald
Florence (<tt><htmlurl url="mailto:ron@mlfarm.com" 
name="ron@mlfarm.com"></tt>) me dijo que el <tt>sendmail</tt> de <it/Sun/
no mandará mensajes múltiples encolados a través de un puerto redirigido;
el <tt>sendmail</tt> 8.6.9 de <it/BSD/ funciona bien. Él hizo los
siguientes cambios al <tt/sendmail.cf/ para que funcionase con <tt/term/.
En este caso se usa el puerto por defecto de <tt>sendmail</tt> (25) para
el tráfico sobre una ethernet local de forma que el correo Internet se
pasa al puerto <tt/TCP/ redirigido. 

<tscreen><verb>
#
# Crear el mailer termsmtp, el cual envia el correo via el puerto TCP 
# redirigido
#
Mtermsmtp,P=[TCP], F=mDFMuCXe, S=22, R=22, A=TCP $h PORTNUMBER
</verb></tscreen>

Aquí, <tt>PORTNUMBER</tt> es el número del puerto redirigido en la máquina
local. Este debería ser un puerto sin usar por encima del 2000.
Seguidamente le decimos a <tt/sendmail/ a que máquina conectarse, y
ponemos a <tt/termsmtp/ como <it/mailer/ por defecto. 

<tscreen><verb>
#
# relevo de correo principal
#
DMtermsmtp
#
# maquina del relevo principal: usa el mailer $M para enviar el
# correo de otros dominios
#
DR HOSTNAME
CR HOSTNAME
</verb></tscreen>

Aquí <tt>HOSTNAME</tt> es el nombre de tu host local (¿funcionará
<tt>localhost</tt>?). La última entrada va debajo de <tt/Rule 0/ para pasar
el correo Internet.

<tscreen><verb>
# Pass other valid names up the ladder to our forwarder
R$*<@$*.$+>$*		$#$M    $@$R $:$1<@$2.$3>$4	user@any.domain
</verb></tscreen>

Cuando la conexión <tt>term</tt> se haya establecido con el host Internet,
ejecute los siguientes comandos en la máquina local. 

<tscreen><verb>
tredir PORTNUMBER internet.host:25
/usr/lib/sendmail -q
</verb></tscreen>

Pasamos ahora a la recepción de correo electrónico usando <tt>term</tt>.
Asumiremos que el correo se envía a su cuenta en el servidor de correo
(<tt/mailhost/) de la red. La solución más simple es usar <tt>trsh</tt> o
<tt>termtelnet</tt> para acceder al servidor y leer su correo allí. 

Sin embargo, también es posible hacer pasar el correo automáticamente a su
máquina local. Una forma de hacer esto es usar el <it/Post Office
Protocol/, (<it/POP/). <it/POP/ fue diseñado precisamente para este
propósito: enviar correo a máquinas que tienen conexiones de red
esporádicas.

Para usar <it/POP/ ha de tener instalado un servidor <it/POP/ en
<it/mailhost/. Suponiendo que lo tiene, puede usar entonces un cliente
<it/POP/ para recoger su correo cada poco tiempo. Esto se hace, como
podría esperar, usando <tt>tredir</tt>. El servicio <it/POP/ es el 110
(Observe que hay un protocolo más antiguo, <it/POP-2/, que usa el puerto
109; en este documento describiremos <it/POP-3/, que es la última versión
de <it/POP/). Hay varios clientes <it/POP/ disponibles. Uno, escrito en el
lenguaje de scripts <tt>perl</tt>, es <tt/pop-perl-1.X/, escrito por
William Perry y mantenido por mí mismo - puede encontrarse en <tt/sunsite/
en <tt>/pub/Linux/system/Mail</tt>.

Para usar <it/POP/ se redirige un puerto local al puerto 110 de
<tt/mailhost/ y se configura el cliente para recoger su correo de
<tt/localhost/ usando el puerto local. Como ejemplo, supongamos que hay un
servidor <it/POP/ corriendo en <tt/mailhost/. Redirigiremos en puerto
local 2110, y ejecutamos el cliente pop-perl: 

<tscreen><verb>
$ tredir 2110 mailhost:110
Redirecting 2110 to mailhost:110
$ pop 
Username: bill
Password: <introduzca su password para mailhost>
Pop Host: name of local 
Pop Port: 2110 
Starting popmail daemon for bill 
</verb></tscreen>

Si no tiene un servidor <it/POP/ disponible, el paquete
<tt/BCRMailHandler/ tiene un programa para capturar su correo desde un
enlace <tt>term</tt> hasta su máquina local. No lo he usado, pero
cualquier comentario de alguien que lo haya hecho será bienvenido. También
puede usar el paquete <tt>term.mailerd+smail</tt> para este propósito. Sin
embargo, <tt>BCRMailHandler</tt> y <tt>term.mailerd+smail</tt> ya no
funcionan con versiones de <tt/term/ 2.0.0 o superiores.

<sect><tt>tudpredir</tt>

<p>

<tt>tudpredir</tt> es similar a <tt/tredir/ si se observa lo que estos
programas hacen y cómo se ejecutan. La gran diferencia entre los dos es
que <tt/tredir/ se usa para redirigir servicios de red <tt/TCP/, mientras
<tt/tudpredir/ redirige servicios de red <tt/UDP/ (<it/User Datagram
Protocol/) a través de un enlace <tt>term</tt>. Una diferencia más
importante entre los dos programas es que <tt/tredir/ se convierte en un
demonio en segundo plano una vez que se ha establecido el puerto local,
mientras los comandos <tt/tudpredir/ hay que ponerlos en segundo plano
manualmente. 

El formato de una llamada a <tt>tupredir</tt> es:

<tscreen><verb>
tudpredir [esta_maquina:]puerto [la_otra_maquina:]puerto
</verb></tscreen>

<sect>Automatizando las cosas.

<p> 

Ahora que ya sabe cómo conseguir todos los servicios de red sobre
<tt>term</tt>, sería bonito colocar las cosas de tal modo que su enlace se
establezca y configure automáticamente. Básicamente hay infinitas formas
de hacerlo, dependiendo de que programa de comunicación utilice y cómo
acceda a su sistema remoto.

Un programa que yo no he usado, pero que he oído que es bastante
agradable, es <tt>fet</tt>: un <it/front-end/ para <tt>term</tt>. Está
diseñado para introducirle en un sistema remoto y poner en marcha
<tt>term</tt> y todos sus <tt/tredirs/. Cualquier comentario sobre
<tt/fet/ será bienvenido. 

Le daré un ejemplo de una serie de comandos que usa <tt>kermit</tt> para
introducirse en el sistema remoto y que efectúa todas las inicializaciones
de <tt>term</tt>. Obviamente, si usa estos ejemplos, tendrá que
modificarlos para sus propios procedimientos de acceso.

El comando que se invoca en este caso es la <it/shell script/ <tt/knet/, dada 
por:


<tscreen><verb>
#!/bin/sh
/usr/bin/kermit -y $HOME/.kerm_term > $HOME/klog < /dev/null 2>&ero 1 
exec $HOME/bin/tstart >> $HOME/klog 2>&ero 1
</verb></tscreen>

La script <tt/.kerm&lowbar;term/ viene dada por:

<tscreen><verb> 
pause 2 
# El numero al que llamar
output atdtXXXXXXX \13 
# Acceso al servidor de terminal
input 145 {name: } 
output MYNAME \13 
input 3 {word: } 
output MYPASSWORD \13 
input 5 {xyplex>} 
# Hacer la linea transparente
output term telnet-t \13 
output term stopb 1 \13 
# Conectar al host remoto
output telnet remotehost.somedomain.org \13 
input 10 {ogin: } 
output MYOTHERNAME \13 
input 3 word: 
output MYOTHERPASSWORD \13 
pause 5  
# Lanzar term en el host remoto
output exec term -s 38400 -l $HOME/tlog -w 10 -t 150  \13
! /usr/bin/term -r -l $HOME/tlog -s 38400 -c off -w 10 -t 150 < /dev/modem  > /dev/modem &
# Abrir otros clientes aqui
suspend 
!killall -KILL term 
</verb></tscreen>

y finalmente, el <it/script/ <tt/tstart/ que lanza los clientes <tt/term/ es:

<tscreen><verb> 
#!/bin/sh 
# 
# Esto hace que salga el correo, pueda leer news, y pueda recoger correo.
# 
/usr/local/bin/tredir 2025 25 2119 newshost:119 2110 pophost:110 
# 
# Puedo abrir una Xwindow aqui
# 
/usr/local/bin/trsh -s txconn 
# 
# Ahora recibire el correo....
# 
/usr/local/bin/pop 
# 
# Limpiar la cola, en caso de boo-boos
# 
/usr/bin/runq 
# 
# Acabado
# 
echo ^G^G > /dev/console 
</verb></tscreen>

Cuando por fin quiera cerrar la conexión, retoma y termina el <tt/kermit/.
La última línea del <it/script/ mata el <tt>term</tt> local y al sistema a
su estado inicial.<footnote> Nota del autor: en lugar de hacer
<tt>!killall -KILL term</tt>, creo que sería posible hacer solamente
<tt/!tshutdown/. ¿Funcionará esto también?  </footnote>

Como ya dije, hay <it/zillones/ de formas de hacerlo; estas sólo se han
citado como ejemplos para que pueda comenzar. Otros ejemplos pueden
encontrarse en los paquetes <tt>autoterm</tt> y <tt>JoelTermStuff</tt>. 

<sect>Portando software para usarlo con <tt>term</tt>.

<p>

En principio, todos los programas que se puedan usar sobre una red pueden
usarse en combinación con <tt>term</tt>. Algunos de ellos podrá
encontrarlos ya como binarios con soporte para <tt>term</tt>. Esto incluye
<tt>telnet, (nc)ftp, mosaic</tt> y muchos otros. La mayoría de estos
programas se han compilado para <tt>term</tt> 1.17 o anteriores. A pesar
de eso, aún deberían funcionar con versiones más nuevas de <tt>term</tt>.

Otra forma de hacer que los programas funcionen con <tt>term</tt> es
portarlos usted mismo. Este proceso es el que se describe en la siguiente
subsección. 

El último modo de compatibilizar sus programas con <tt>term</tt> es
<it>termificándolos</it>. 

<sect1>Portar y compilar los fuentes. 

<p>

Portar software a <tt>term</tt> se puede hacer usando un procedimiento bastante 
sencillo:

Si está instalado en <tt>/usr/local</tt> por <tt/root/:

<enum>

<item> Añada a los flags de compilación <tt>-include
/usr/local/include/termnet.h</tt>

<item> y añada a la lista de librerías <tt>-ltermnet</tt>
</enum>

Si está instalado en su directorio <it/home/:

<enum>

<item> Añada a los parámetros de compilación
<tt>-include &dollar;HOME/term/termnet.h</tt>

<item> y añada a la lista de librerías 
<tt>-L&dollar;HOME/term -ltermnet</tt>

</enum>

Ahora compile el software como se describe en el documento <tt/INSTALL/ o
<tt/README/ que venga con el software. ¡Ya estaría todo! 

En este momento los comandos deberían funcionar con y sin <tt>term</tt>.

<tscreen><verb>
telnet localhost
</verb></tscreen>

no usa <tt>term</tt> para conectar, pero

<tscreen><verb>
telnet bohr.physics.purdue.edu
</verb></tscreen>

usará <tt>term</tt> sólo si no hay otro tipo de conexión de red.

Algunos comandos, como <tt>rlogin</tt>, sólo pueden ser usados por
<tt/root/ y por el propietario de la conexión <tt>term</tt> (personas
privilegiadas). 

Algunos comandos <tt>term</tt> serán transparentes a <tt>term</tt> y sólo
usarán <tt>term</tt> cuando no haya otra opción. Algunos ejemplos típicos
son <tt/telnet/ y <tt/ftp/. 

Otros requieren un parámetro externo para indicarles que les es posible
usar <tt>term</tt>. En estos programas se incluyen <tt>xarchie, fsp</tt> e
<tt/ytalk/. 

Se puede poner el parámetro a estos programas para que usen <tt>term</tt>,
bien colocando la variable de entorno <tt/TERMMODE/ como se especifica en
<tt/README.security/, o bien, ejecutando <tt>make installnet</tt>. 
Eventualmente, el fichero <tt/termnet/ creado contendrá instrucciones de
red específicas, pero por ahora sólo está probada su existencia.

Si se añade una <it>conexión ethernet</it>, puede simplemente quitar el
fichero <tt/termnet/ y ¡continuar usando los mismos binarios! 

NOTA: Aquellos programas que fueron portados en los tiempos del <tt/client.a/,
aún pueden ser recompilados para usarlos con versiones nuevas de <tt>term</tt> 
cambiando simplemente la referencia a <tt/client.a/ por <tt/libtermnet.a/.

<sect1><it>Termificar</it> (<tt/termify/).

<p>

Este paquete convertirá los binarios enlazados dinámicamente para usar
<tt>term</tt>. 

Antes de poder <it>termificar</it> deberá asegurarse de que tiene una
versión 2.2i (en esta versión 2.2.8?) de <tt>term</tt> o posterior y
<tt/libc.so.4.5.26/ o posterior.  Entonces hay que crear el fichero
<tt/libt.so.4/ en el directorio <tt>/lib</tt> (ver el fichero <tt/README/
del paquete).

El problema en este momento es que hay que rehacer el fichero <tt/libt.so.4/ 
cada vez que renueve la versión de <tt>term</tt>.

Después de crear la librería podrá dejar que <tt>termify</tt>
<it/``digiera''/ al programa que se quiere hacer <it>term-compatible</it>,
usando el comando: 

<tscreen><verb>
termify <programa>
</verb></tscreen>

Si no le gusta el resultado puede <it>des-termificar</it> el programa que
acaba de termificar, usando el comando: 

<tscreen><verb>
termify -u <programa>
</verb></tscreen>

Por fin, el paquete también contiene un <it/script/ para <it/termificar/
completamente <tt/smail/; de modo que no son necesarias definiciones
especiales de transporte. La única cosa que quizá quiera cambiar es la
dirección del <tt/From:/. 
     
<sect>Clientes <tt/term/.

<p>

<sect1>Clientes <tt/term/ disponibles en los servidores <tt/ftp/.

<p>

A continuación se da una lista de aplicaciones que corren con
<tt>term</tt>. Yo no digo que esta lista esté completa; así que cualquier
añadido será bienvenido. Siempre que sea posible indicaré el <it/site/ y
directorio donde se pueda encontrar la aplicación. Si indico
<tt>sunsite.unc.edu</tt><footnote>
En España contamos con un magnífico y veloz <it/mirror/ de SunSite,
localizable en <tt><htmlurl url="ftp://sunsite.rediris.es"
name="sunsite.rediris.es"></tt></footnote> como el lugar donde encontrar
la aplicación, quiero decir que puede encontrarla en uno de los dos
directorios siguientes:

<enum>

<item>
<tt><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/apps"
name="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/apps"></tt>

<item>
<tt><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/extra"
name="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/extra"></tt>

</enum>

¡Allá vamos! <tt/:-)/

<bf>paquete <tt>TERM</tt>:</bf>

<tscreen><verb>
tupload
tdownload           (versiones 2.1.0 y posteriores)
trsh
tmon
tredir
tudpredir           (versiones 2.0.0 y posteriores)
txconn
trdate(d)
tshutdown
libtermnet
</verb></tscreen>

<bf>Transferencia de ficheros:</bf>

<tscreen><verb>
ftpd                sunsite.unc.edu
termncftp           sunsite.unc.edu
ncftp185            sunsite.unc.edu:/pub/Linux/system/Network/file-transfer
fsp                 sunsite.unc.edu:/pub/Linux/system/Network/file-transfer
</verb></tscreen>

<bf>Sistemas de Información:</bf>

<tscreen><verb>
lynx                
Mosaic              sunsite.unc.edu:/pub/Linux/system/Network/info-systems/Mosaic
chimera
netscape            sunsite.unc.edu:/pub/Linux/system/Network/info-systems
httpd
xgopher
gopher              sunsite.unc.edu
</verb></tscreen>

<bf>Acceso remoto:</bf>

<tscreen><verb>
termtelnet          sunsite.unc.edu
rlogin              physics.purdue.edu:/pub/bcr/term/extra
rsh                 physics.purdue.edu:/pub/bcr/term/extra
</verb></tscreen>

<bf>Noticias (news):</bf>

<tscreen><verb>
tin 1.3             sunsite.unc.edu:/pub/Linux/system/Mail/news
news2               sunsite.unc.edu
</verb></tscreen>

<bf>Correo:</bf>

<tscreen><verb>
slurp               sunsite.unc.edu
smail               sunsite.unc.edu
term.mailerd+smail  sunsite.unc.edu
BCRMailHandlerXXX   physics.purdue.edu:/pub/bcr/term
</verb></tscreen>

<bf>Scripts automatizadores:</bf>

<tscreen><verb>
JoelTermStuff       sunsite.unc.edu
autoterm            sunsite.unc.edu
fet                 sunsite.unc.edu
</verb></tscreen>

<bf>Otros programas:</bf>

<tscreen><verb>
inetd               sunsite.unc.edu
rdate               sunsite.unc.edu
xgospel             sunsite.unc.edu:/pub/Linux/games/x11/networked
termify             physics.purdue.edu:/pub/bcr/term/extra
xboard              sunsite.unc.edu
ircII               sunsite.unc.edu:/pub/Linux/system/Network/chat
whois               
xwebster            sunsite.unc.edu
sxpc                ftp.x.org:/R5contrib
xztalk              sunsite.unc.edu:/pub/Linux/apps/sound/talk
</verb></tscreen>

<sect1>El paquete <tt/termnet/.

<p>

El paquete <tt>termnet-2.0.4-Linux-bin.tar.gz</tt> 
(<tt><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term" 
name="ftp://sunsite.unc.edu/pub/Linux/apps/comm/term"></tt>) contiene un
par de clientes precompilados, un par de scripts, páginas de manual y
<tt/libtermnet.so.2.00.04/.  Los clientes se han compilado usando esta
versión de <tt/libtermnet.so/. El paquete contiene los siguientes
clientes: 

<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>

AVISO: El paquete también contiene el conjunto completo de clientes
compilados de <tt>term</tt> 2.0.4 incluyendo el mismo <tt>term</tt>. No
instale este paquete hasta que esté seguro de lo que quiere. Destruirá
otras versiones de <tt>term</tt> y sus clientes si empieza a enredar con
los ejecutables.

<sect1>Solicitado, pero aún no soportado:

<p>

<enum> 

<item> <tt>DOOM</tt>: El problema con este juego parece ser el hecho de que
usa el puerto 5029 ya sea como cliente o como servidor. 

<item> <tt>NFS</tt>: El servidor <tt/NFS/ se supone que sólo acepta
llamadas si el <it/socket/ que solicita la conexión está ligado a un
puerto por debajo del 1024. Esto parece ser problemático. Sin embargo,
algunos servidores <tt/NFS/ tienen una opción <it/insegura/. En este caso
<tt/NFS/ podría funcionar ocasionalmente, si se le añade al <tt/term/
soporte <tt/RPC/.  

</enum>

<sect><tt>Term</tt> y la seguridad

<p>

En esta sección puntualizaré algunos aspectos sobre la seguridad
usando <tt>TERM</tt>. Los problemas serán expuestos junto a un
mecanismo para aumentar su seguridad.

<sect1><tt/trsh/.

<p>

<tt>trsh</tt> es inseguro si se usa para acceder al Linux local desde
el sistema remoto. El problema con <tt>TERM</tt> y sus clientes es que
en el otro extremo de la comunicación el superusuario puede ejecutar
programas de <tt>TERM</tt>.

Esto también indica que el ``<tt/root/'' del otro sistema puede ejecutar
<tt/trsh/ y entrar con los privilegios del propietario de la conexión
fácilmente. Si este propietario es ``<tt/root/'' la <it/habremos liado/. 

La solución es simple: poner la siguiente línea en el fichero <tt/termrc/
de la máquina local:

<tscreen><verb>
denyrsh on
</verb></tscreen>

Con esto, nadie podrá usar <tt/trsh/ desde el sistema remoto para entrar
en el local. Cuando tú mismo quieras entrar, podrás hacerlo aún usando
<tt>telnet</tt> y puertos redirigidos. 

<sect1><tt/txconn/ y <tt/xauth/

<p>

<tt/txconn/ no es terriblemente seguro; cualquiera puede conectar al
servidor local con <tt>term</tt> y hacer de todo. Si te preocupa, puedes
usar <tt/xauth/ para establecer las autorizaciones de acceso. Mira el
ejemplo de la siguiente sección. 

<sect1><tt/sxpc/, <tt/xhost/ y <tt/xauth/

<p>

<tt>sxpc</tt> en combinación con <tt/xhost +/ es muy peligroso si no usas
<tt>xauth</tt>. 

Usar <tt/xauth/ es muy importante para mantener la seguridad cuando se usa
<tt/sxpc/. Si no usas <tt/xauth/ al usar <tt/sxpc/, será muy peligroso
tener <tt/xhost +/.  Algunos peligros son: 

<itemize>
<item>Alguien puede saber lo que hay en tu pantalla
<item>Alguien puede saber lo que tecleas
<item>Alguien puede teclear sobre alguna de tus ventanas (por ejemplo,
un comando que borre tus ficheros <tt/:-(/ )
</itemize>

<tt/xauth/ forma parte de las versiones R4 y posteriores de X. Aquí
describiremos cómo usar básicamente el <tt/xauth/. Esta configuración es
vulnerable al husmeo de la red, pero puede convivir con ella fácilmente. 

<bf>NOTA:</bf> cuando uses <tt/xauth/ asegúrate que la variable
<tt>&dollar;DISPLAY</tt> no tiene el valor <tt/localhost/ (o
<tt/localhost:loquesea/). Si tu variable <tt/&dollar;DISPLAY/ vale
<tt/localhost/, los clientes no podrán encontrar la información de
autorización. Lo mejor es usar el nombre real de la máquina. Si sigues las
instrucciones de compilación del <tt/README/, y compilas sin la variable
<tt/-DNOGETHOSTNAME/ puede que todo funcione. 

Sea <it/C/ la máquina que ejecuta clientes, y <it/D/ la máquina que pone la 
pantalla.

Primero, elige una ``clave'', de hasta 16 pares de dígitos hexadecimales
(números del rango 0-9 y a-f). Necesitarás proporcionar esta clave en
el lugar de <tt/&lt;clave&gt;/ en este ejemplo:

En <it/C/:

<tscreen><verb>
% xauth
xauth:  creating new authority file $HOME/.Xauthority
Using authority file $HOME/.Xauthority
xauth> add Nombre_de_C:8 MIT-MAGIC-COOKIE-1 <clave>
xauth> exit
</verb></tscreen>

En <it/D/:

<tscreen><verb>
% xauth
xauth:  creating new authority file $HOME/.Xauthority
Using authority file $HOME/.Xauthority
xauth> add Nombre_de_D/unix:0 MIT-MAGIC-COOKIE-1 <clave>
xauth> add Nombre_de_D:0 MIT-MAGIC-COOKIE-1 <clave>
xauth> exit
</verb></tscreen>

Cuando inicies el servidor X en <it/D/ deberías poner el parámetro
<tt>-auth &dollar;HOME/.Xauthority</tt>. Puede que necesites crear o
editar el fichero <tt>&dollar;HOME/.xserverrc</tt> para controlar el
inicio del servidor X. Por ejemplo: 

<tscreen><verb>
#!/bin/sh
exec X  -auth $HOME/.Xauthority $*
</verb></tscreen>

Asegúrate que el fichero <tt>.Xauthority</tt> es legible sólo por <tt/C/ y
por <it/D/. 

<sect>Cosas a recordar

<p>

En esta sección intento obsequiarle con una lista de direcciones <tt/ftp/
de utilidad, <it/URL/'s, etc. donde puede encontrar software e información
sobre <tt>term</tt>. 

<bf>Ftp:</bf>

<itemize>
<item><tt><htmlurl url="ftp://sunsite.unc.edu:/pub/Linux/apps/comm/term/"
name="ftp://sunsite.unc.edu:/pub/Linux/apps/comm/term/"></tt>
<item><tt><htmlurl url="ftp://sunsite.unc.edu:/pub/Linux/docs/HOWTO/"
name="ftp://sunsite.unc.edu:/pub/Linux/docs/HOWTO/"></tt>
<item><tt><htmlurl url="ftp://physics.purdue.edu:/pub/bcr/term/"
name="ftp://physics.purdue.edu:/pub/bcr/term/"></tt>
</itemize>

<bf>URL:</bf>

<itemize>
<item><tt><htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html"
name="http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html"></tt>
<item><tt><htmlurl url="http://www.bart.nl/&tilde;patrickr/term-howto/Term-HOWTO.html"
name="http://www.bart.nl/&tilde;patrickr/term-howto/Term-HOWTO.html"></tt>
(siempre tiene la última versión)
<item><tt><htmlurl url="http://physics.purdue.edu/&tilde;bcr/homepage.html"
name="http://physics.purdue.edu/&tilde;bcr/homepage.html"></tt>
</itemize>

<bf>Netnews:</bf>

<tscreen><verb>
comp.os.linux.announce           aqui se anuncian nuevas versiones de term
comp.os.linux.help               aqui puede poner sus dudas sobre term
comp.os.linux.misc               o aqui
comp.protocols.misc              las respuestas a las preguntas son enviadas aqui.
</verb></tscreen>

Cuando comience a hacer preguntas en las news, por favor, asegúrese de que
da a la gente del grupo tanta información como necesitan para resolver su
problema (versión de <tt/term/, de qué modo establece su conexión, etc.). 

En este momento hay en uso muchas versiones de <tt/term/ y todas ellas
tienen sus problemas comunes y específicos. Además, cuando quiera una
respuesta útil, al menos indique qué versión de <tt/term/ está usando. De
lo contrario, en algunos casos sólo por adivinación será posible ayudarle
a resolver sus problemas. 

<bf>Documentos relacionados:</bf>

<itemize>

<item><it/Using Term to Pierce an Internet Firewall HOWTO/ 
de Barak Pearlmutter, &nl;
<tt><htmlurl url="mailto:bap@learning.scr.siemens.com" 
name="bap@learning.scr.siemens.com"></tt>

<item><it/Cortafuegos-Como/<footnote>Disponible en castellano, consulte 
la sección <ref id="Grupos"></footnote> de David Rudder,
<tt><htmlurl url="mailto:drig@execpc.com" name="drig@execpc.com"></tt>

<item><it/Serial HOWTO/, de Greg Hankins,
<tt><htmlurl url="mailto:gregh@cc.gatech.edu" name="gregh@cc.gatech.edu"></tt>

<item><it>Net-2/Net-3 HOWTO</it> de Terry Dawson,
<tt><htmlurl url="mailto:terryd@extro.ucc.su.oz.au" 
name="terryd@extro.ucc.su.oz.au"></tt>

</itemize>

<sect>Estabilidad de las versiones de <tt>term</tt>

<p>

Hay muchas versiones de <tt>term</tt> rondando en estos momentos. El que
mantiene el <tt>term</tt>, Bill Riemers, ha hecho una lista de versiones
de <tt>term</tt> indicando qué versiones son estables y qué versiones es
mejor evitar. La lista es la siguiente: 

<tscreen><verb>
      term110          --> no puedo decir con seguridad
      term111          --> no puedo decir con seguridad
      term112          --> no puedo decir con seguridad
      term113          --> no puedo decir con seguridad
      term114          --> version BETA bastante estable
      term115          --> version BETA inestable BETA
      term116          --> version BETA inestable BETA
      term117          --> version BETA inestable BETA
      term118          --> version BETA semiestable
      term119          --> version GAMMA estable
      term-2.0.X       --> BETA versiones BETA semiestables
      term-2.1.X       --> mas versiones BETA estables
      term-2.2.X       --> nuevas versiones BETA
      term-2.3.X       -->
</verb></tscreen> 

<sect>Tabla de velocidad de <tt>term</tt>.

<p>

Gracias a Bill McCarthy ahora disponemos de una tabla con información de
la velocidad de <tt>term</tt> para diferentes módems, versiones de
<tt>term</tt> y condiciones de conexión. El propósito es dar, tanto a los
usuarios nuevos como a los experimentados, una idea de lo que otra gente
está usando y los resultados que consiguen.

<tscreen><verb>
			   LINUX TERM CHART 8/14/94


|___velocidad/marca____|___vel. linea__|__cps med__|__max.__|__ver term_|
| 1)  USR SP 14.4      |   9600        |  950      |  963   | 1.17      |
| 2)  USR SP 14.4      |  14400        | 1376      |  n/a   | 1.18p06   |
| 3)  Zoom 2400        |   2400        |  220      |  230   | 1.19      | 
| 4)  Boca V.32bis 14  |  57600        | 1400      |  n/a   | 1.01/09?  |
| 5)  Viva 14.4        |  14400        | 1300      |  n/a   | 1.16      |
| 6)  USR SP 14.4      |  14400+       | 1550      | 1680   | 1.19      |
| 7)  Intel 14.4 Fax   |  14400        | 1400      | 1650   | 2.0.4     | 
| 8)  cable tv hookup  |  57600        | 1500      | 1800   | 1.18p06   |
| 9)  Twincom 144/DFi  |  57600        | 1500      | 4000?  | 2.0.4     |
| 10) USR SP 14.4      |  14400        | 1200      | 1500   | 1.08      |
| 11) cable tv hookup  |  19200        | 1300      | 1800   | 1.19      |
|-----------------------------------------------------------------------|

+parametros en el termrc:

1) default escapes   2) window 5       3) baudrate 2400    4) n/a            
 baudrate 9600        timeout 200       window 3
 window 10                              noise on
 timeout 150

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

Escapar caracteres en un extremo implica ignorarlos en el otro extremo.
</verb></tscreen>

<sect>Pistas y trucos encontrados en la red

<p>

En los grupos de news relacionados con Linux surgen de nuevo muchas 
preguntas sobre <tt>term</tt> cada 15 días, junto con las respuestas a estas 
preguntas. Para reducir el tráfico del grupo de news, intentaré hacer un 
resumen de esas preguntas y las respuestas a las mismas. Algunas de las
respuestas han sido probadas por mí, ya que también tuve los citados 
problemas. Otras simplemente las he tomado sin comprobarlas.

<itemize>
<item>Mucha gente, en especial los que usan <it/Ultrix/, parecen tener 
problemas 
   con el <tt/vi/ porque les muestra menos de 24 líneas en ventanas con 24 
   líneas. Hay dos formas de resolver este problema:

<enum>
<item>Acceda al sistema remoto usando: 

<tscreen><verb>
trsh -s telnet <hostname>
</verb></tscreen>

<item>Ponga <tt/resize; clear/ en su fichero <tt/.login/

<item>La mejor solución parece ser poner lo siguiente en el remoto:

<tscreen><verb>
stty 38400
</verb></tscreen>

</enum>

<item> Mucha gente parece tener problemas con caídas de la conexión
<tt>term</tt>, cualesquiera que sean los motivos de la caída. Así que
antes de poner en marcha aplicaciones, la gente quiere saber si su
conexión <tt>term</tt> sigue viva o no. Esto se puede probar usando estos
pequeños ejemplos de <it/shell scripts/: 

Si está usando <tt/tcsh/:

<tscreen><verb>
if ( { trsh -s true } ) then
  ...
endif
</verb></tscreen>

Si está usando <tt/bash/:

<tscreen><verb>
if trsh -s true; then
  ...
fi
</verb></tscreen>

<item> El navegador de <it/WWW/ <tt>netscape</tt> causa a la gente
problemas para funcionar con <tt>term</tt>. La buena noticia es que puede
funcionar. He aquí cómo: 

<enum>

<item>Termificar el netscape

<item>Lanzar <tt/termnetscape/. En el menú <tt>Options | Preferences |
Mail/Proxys</tt> dejar todos los campos <tt/proxy/ en blanco; poner en el
campo <tt/SOCKS/: <tt/remotehost/ y 80
<item>Ignorar el error que saldrá en el menú de opciones.

<item>Si no funciona bien: en el menú <tt>Options | Preferences |
Mail/Proxys</tt> dejar todos los campos <tt/proxy/ en blanco, poner en el
campo <tt/SOCKS/: <tt/none/ y 80

<item>Ignorar el error que saldrá en el menú de opciones.

</enum>

Scott Blachowicz me envió un mensaje diciendo que hay una forma fácil
de hacer que Netscape u otro navegador funcione bien con <tt>term</tt>
si tiene instalado un servidor proxy (como el <tt/httpd/ del CERN) para ser
usado en el lado <it>remoto</it> del enlace <tt>term</tt>. En el lado
local tendrás que hacer esto entonces:

<itemize>
<item>
<tscreen><verb>
    tredir local:8080 remota:80
</verb></tscreen>

Donde <tt/remota/ es el nombre remoto del servidor <it/proxy/.

<item> Ejecuta el navegador, y en las opciones o como se llame,
pon los proxies como <tt/local/, puerto 8080. En algunos navegadores esto
se hace mediante variables de entorno como:

<tscreen><verb>
                export http_proxy=http://localhost:8080/
                export ftp_proxy=http://localhost:8080/
</verb></tscreen>

</itemize>
</itemize>

<sect>Otras Cosas

<p>

Algunas cosas que se podrían incluir:

<itemize>
<item>Aumento de soluciones a problemas
<item>Extensión del tema sobre seguridad
<item><tt/termwrap/
<item>Sugerencias
</itemize>

De todos modos, si tiene sugerencias, críticas, o cualquier otra cosa que
decir sobre este documento, por favor, ¡hágalo!. Como Bill Reynolds está muy
ocupado en estos momentos, yo, Patrick Reijen, me he hecho cargo de la 
autoría del <tt>Term</tt>-COMO. Se me puede encontrar (actualmente) en 
<tt><htmlurl url="mailto:patrickr@cs.kun.nl" name="patrickr@cs.kun.nl"></tt> 
o en 
<tt><htmlurl url="mailto:patrickr@sci.kun.nl" name="patrickr@sci.kun.nl"></tt>.

<sect>Reconocimientos

<p>

Hay que dar las gracias a mucha gente. Primero y principalmente a Michael
o'Reilly y todos los desarrolladores del <tt>term</tt>, que nos han
proporcionado esta gran herramienta. También quisiera agradecer a todos
los que dieron su experiencia y contribuyeron a este COMO. Esto incluye a
Ronald Florence, Tom Payerle, Bill C. Riemers, Hugh Secker-Walker, Matt
Welsh, Bill McCarthy, Sergio y todos los que me olvido de mencionar.


<sect>Anexo: El INSFLUG <label id="Grupos">
<p>

El <em/INSFLUG/ forma parte del grupo internacional 
<it/Linux Documentation Project/, 
encargándose de las traducciones al castellano de los Howtos (Comos),
así como la producción de documentos originales en aquellos casos
en los que no existe análogo en inglés.

En el <bf/INSFLUG/ se orienta preferentemente a la traducción de documentos
breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de
<bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del INSFLUG para más información al respecto.

En la sede del INSFLUG encontrará siempre las <bf/últimas/ versiones 
de las traducciones:  <tt><htmlurl url="http://www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última versión 
disponible en el Insflug antes de bajar un documento de un servidor réplica.

Se proporciona también una lista de los servidores
réplica (<it/mirror/) del Insflug más cercanos a Vd.,  
e información relativa a otros recursos en castellano.

Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org"
name="pacopepe@insflug.org"></tt>.

</article>

