  TERM Como
  Patrick Reijnen, patrickr@bart.nl
  Traducción de Alfonso Belloso, alfon@bipv02.bi.ehu.es (-- Revisión
  0.1, Fco. J. Montilla, pacopepe@nova.es--)
  v1.0, 1 Enero de 1995

  Lo que sigue es una guía detallada de configuración del programa Term
  en Linux.
  ______________________________________________________________________

  Índice General:

  1.      Información

  1.1.    Copyright statement

  1.2.    DISCLAIMER

  2.      Introducción

  2.1.    Sobre este Documento

  2.2.    ¿Qué es el TERM?

  3.      Cómo funciona el TERM

  3.1.    Nomenclatura

  4.      Poniendo a punto las cosas.

  4.1.    Qué necesitas tener de antemano.

  4.2.    Explicación de conceptos.

  4.2.1.  ``Sharing''  (compartición).

  4.2.2.  `` Full TERM networking '' (conexión de red completamente
  TERM)

  4.3.    Compilación del TERM

  4.3.1.  Construir el term  hasta la versión 1.15

  4.3.2.  Construir el term , versiones 1.16 hasta 1.19

  4.3.3.  Construir el TERM , versiones 2.0.0  y superiores

  4.4.    client.a, libtermnet.a, libtermnet.sa, libtermnet.so

  4.5.    Estableciendo variables de entorno.

  4.6.    Probar el TERM

  4.7.    TERM  y los programas de comunicaciones.

  4.7.1.  kermit

  4.7.2.  seyon

  4.8.    Hacer un enlace transparente.

  4.9.    Ejecutar linecheck

  4.10.   Prueba a correr el TERM

  4.11.   Terminar tu conexión term

  4.12.   Cómo eliminar TERM  de tus particiones.

  4.13.   Optimización de la conexión

  4.14.   Resolución de problemas

  5.      Clientes TERM

  6.      X y TERM

  7.      tredir

  7.1.    ¡ tredir  puede morder!

  7.2.    Trucos tontos de tredir

  7.2.1.  X window

  7.2.2.  Correo con TERM

  8.      tudpredir

  9.      Automatizando las cosas.

  10.     Portando software para usarlo con term .

  10.1.   Portar y compilar los fuentes.

  10.2.   Termificar  ( termify ).

  11.     Clientes term .

  11.1.   Clientes term  disponibles en los servidores ftp .

  11.2.   El paquete termnet .

  11.3.   Solicitado, pero aún no soportado:

  12.     Term  y la seguridad

  12.1.   trsh .

  12.2.   txconn  y xauth

  12.3.   sxpc , xhost  y xauth

  13.     Cosas a recordar

  14.     Estabilidad de las versiones de term

  15.     Tabla de velocidad de term .

  16.     Pistas y trucos encontrados en la red

  17.     Otras Cosas

  18.     Reconocimientos

  19.     Anexo: Grupos LiNUXeros en España.
  ______________________________________________________________________

  1.  Información

  1.1.  Copyright statement

  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.

  1.2.  DISCLAIMER

  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.

  2.  Introducción

  2.1.  Sobre este Documento

  Este COMO intenta aclarar algunas de las confusiones al usar term, 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 term 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 term y detallar los pasos para
  conseguir algunos de los servicios de red más comunes trabajando bajo
  term. Se debe hacer hincapié en que este documento no cubre todo lo
  que se debe saber sobre el term.  Después de leerlo, deberían leerse
  las manpages sobre term, ya que éstas incluyen información que no se
  encuentra aquí.

  2.2.  ¿Qué es el TERM?

  term es un programa, escrito por Michael O'Reilly,
  michael@iinet.com.au , 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
  term también se puede usar para abrir ventanas de cliente X sobre una
  conexión serie.  Por medio de las utilidades tredir y tupredir de las
  versiones 2.0.x y superiores del term, éste puede proporcionar muchos
  de los servicios de red ``tradicionales'':  mail, news, ftp, telnet,
  xarchie, etc. En esencia, term es muy parecido a otros protocolos
  serie como SLIP o PPP. La ventaja de term 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 SLIP o 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 TERM.

  3.  Cómo funciona el TERM

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

  3.1.  Nomenclatura

  Asumo que estás llamando a un sistema a través de algún tipo de
  servidor de terminal. Utilizo los términos ``local'' y ``remoto'' 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 :-).

  term 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 telnet o 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).

  SLIP y 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 SLIP o 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 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
  term es básicamente automatizar y multiplexar este proceso.  El term
  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 daemon del term local, el cual
  transmite la petición al daemon del term 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
  ftp. Primero necesitas una versión de ftp que pueda hablar con term.
  Invocas termftp como lo haces con un ftp normal, pongamos 'termftp
  nethost.gov', pero esta versión especial hace su solicitud de red al
  daemon del term local en vez de al kernel. El term local transfiere
  esta petición, a través de la línea del módem, al term remoto, el cual
  establece una conexión con nethost.gov, y transmite los datos de
  vuelta sobre el enlace módem.

  term 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 termtelnet mientras
  continúa la transferencia del termftp.

  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
  dos copias del term corriendo, una a cada lado del enlace módem.

  4.  Poniendo a punto las cosas.

  4.1.  Qué necesitas tener de antemano.

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

  4.2.  Explicación de conceptos.

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

  4.2.1.  ``Sharing''  (compartición).

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

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

  Por supuesto, sólo necesitas instalar el ``shared'' TERM en el extremo
  en el que quieres permitir a la gente usar la misma conexión TERM 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 TERM. De
  esta forma toda esta gente puede acceder a tu máquina a la vez
  compartiendo la misma conexión TERM entre sí y contigo mismo. (NOTA:
  el primer ejemplo necesitaba habilitar la característica shared en el
  extremo local de la conexión TERM).

  NOTA para la instalación como root:

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

       term::16:root

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

  Después de compilar e instalar coloca al TERM y sus clientes el SGID
  term:

       chgrp term <cliente_term>
       chmod g+s <cliente_term>

  También cualquier programa que hagas utilizable con TERM debe tener
  SGID TERM.

  4.2.2.  `` Full TERM networking '' (conexión de red completamente
  TERM)

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

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

       telnet localhost

  no usa el TERM para conectar, pero

       telnet zeus.cs.kun.nl

  usará el TERM 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 bind (0) actúe siempre en el host remoto. En esencia hace
  que muchos programas puedan usarse sin ir a través del TERM mientras
  el TERM está corriendo. Desafortunadamente, la mayoría de programas y
  demonios UDP no funcionarán con TERM sin estos incómodos trucos.

  4.3.  Compilación del TERM

  Si tienes suerte esto sólo debe implicar un make. Sin embargo, lo más
  probable es que necesites hacer más. Debido a nuevas opciones en las
  versiones nuevas del TERM (sharing, configure) ahora es un poco más
  complicado crear el ejecutable del TERM. 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 TERM vamos a dividir esta sección en tres partes:

  1. Construir el TERM hasta la versión 1.15

  2. Construir el TERM, versiones 1.16 hasta 1.19

  3. Construir el TERM, versiones 2.0.0 y superiores

  4.3.1.  Construir el term  hasta la versión 1.15

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

       make DO=install OS-type
       make installman

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

  Además, necesitarás crear un directorio $HOME/term. Este directorio lo
  usará el term para buscar su fichero termrc.

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

  4.3.2.  Construir el term , versiones 1.16 hasta 1.19

  Para construir el term ahora puedes elegir una de las siguientes
  formas:

  1. Como un usuario normal, construir el term en modo privado

  2. Como un usuario normal, construir el term en modo shared

  3. Como root, construir el term en modo privado

  4. Como root, construir el term en modo shared

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

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

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

          make DO=install OS-type
          make installman

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

  Además, necesitarás crear un directorio $HOME/term. Este directorio lo
  usará el term para buscar su fichero termrc.

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

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

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

          make DO=installshare USERSHARE=$HOME/term OS-type
          make installman

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

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

  3. Eres root y NO quieres COMPARTIR (SHARE) la conexión term con otros
     usuarios.

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

     make DO=install OS-type
     make installman

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

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

  4. Eres root y quieres COMPARTIR (SHARE) la conexión term.

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

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

          make DO=installshare OS-type
          make installman

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

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

  4.3.3.  Construir el TERM , versiones 2.0.0  y superiores

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

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

  1. Generar el term en modo privado sin full term networking

  2. Generar el term en modo privado con full term networking

  3. Generar el term en modo shared sin full term networking

  4. Generar el term en modo shared con full term networking

  En estas versiones de term ha aparecido una nueva forma de compilar,
  usando el script configure. Cuando se ejecuta configure éste chequea
  en que sistema operativo estás tratando de instalar el term, si el
  directorio origen está disponible o no, y si hay puesta alguna opción
  runtime.  De acuerdo con las cosas encontradas configure crea entonces
  un Makefile usando Makefile.in que se entrega con el paquete del term.
  Dos de las opciones más importantes para configure son --root y --user
  que establecen si el term será instalado por root o por un usuario
  cualquiera. Se pueden usar otras opciones para instalar el term de la
  forma que quieras (con paths no estándar, por ejemplo).

  1. Generar el term en modo privado sin full term networking

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

          make install installman

  Esto genera los binarios, instalándolos junto con las páginas de man­
  ual.

  2. Generar el term en modo privado con full term networking

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

          make installnet installman

  Esto genera los binarios, instalándolos junto con las páginas de man­
  ual.

  3. Generar el term en modo shared sin full term networking

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

          make share installman

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

  4. Generar el term en modo shared con full term networking

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

          make share installnet installman

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

  4.4.  client.a, libtermnet.a, libtermnet.sa, libtermnet.so

  Con el term se suministra una librería con funciones para clientes
  term.

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

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

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

  Finalmente se ejecuta ldconfig para crear los enlaces necesarios y el
  caché (para uso del enlazador dinámico, 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 /etc/ld.so.conf,
  y en los directorios permitidos (/usr/lib y /lib).

  Si la instalación se hace correctamente, los tres ficheros de librería
  podrán ser usados por los clientes de term 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 term (ver más adelante).

  4.5.  Estableciendo variables de entorno.

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

  ·  TERMDIR

  ·  TERMSHARE

  ·  TERMMODE

  Definiendo estas variables puedes controlar el modo en que se ejecuta
  el term.

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

       setenv TERMDIR $HOME     # csh o tcsh
       export TERMDIR=$HOME     # bash

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

  1. Ejecutar term en modo privado puede hacerse definiendo las
     variables TERMDIR y TERMMODE de la siguiente forma:

     Para csh o tcsh:

          setenv TERMDIR $HOME
          setenv TERMMODE 0

  Para bash:

       export TERMDIR=$HOME export TERMMODE=0

  2. Si quieres usar el term en modo compartido hay dos formas de
     definir las variables:

     a. Si term se instala como un programa SUID sólo se debe definir
        TERMMODE. (README en el paquete del term).

                setenv TERMMODE 'numero'    # csh o tcsh
                export TERMMODE='numero'    # bash

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

     b. Si term se instala como un programa SGID las variables se deben
        definir del siguiente modo:

        Para csh o tcsh:

                setenv TERMMODE 1
                setenv TERMDIR /usr/local/lib/term
                setenv TERMSHARE $TERMDIR

     Para bash:

             export TERMMODE=1
             export TERMDIR=/usr/local/lib/term
             export TERMSHARE=$TERMDIR

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

  A partir de la versión 2.0.0, term también reconoce la variable
  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 term con un nombre de servidor:

       nohup term -v /dev/modem1 Connection1 & nohup term -v /dev/modem2 Connection2 &

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

       setenv TERMSERVER Connection1           # csh o tcsh
       export TERMSERVER=Connection2           # bash

  4.6.  Probar el TERM

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

        tupload ./term /usr/tmp

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

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

  4.7.  TERM  y los programas de comunicaciones.

  Antes de poder usar term, tienes que establecer una conexión vía módem
  usando un programa de comunicaciones como kermit o 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 term,
  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.

  4.7.1.  kermit

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

  4.7.2.  seyon

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

  Añade al fichero $HOME/.seyon/protocols lo siguiente:

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

  Ahora, cuando inicies linecheck o term en la máquina local, selecciona
  en el menú Transfer el ítem ``Line Check'' o ``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
  linecheck o term. Esto mismo hace redirección automática al comando.

  4.8.  Hacer un enlace transparente.

  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 kermit o
  seyon para comunicar con tu módem (los ejemplos de este documento usan
  el 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 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 (help o ?
  suele ser un buen comienzo). Busca la opción 8 bits siempre que sea
  posible. Esto puede implicar cambiar la forma en que accedes a tu
  sistema, por ejemplo, si el servidor usa rlogin, tendrás que usarlo
  poniendo el parámetro -8 para hacerlo transparente.

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

  4.9.  Ejecutar linecheck

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

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

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

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

  1. En el sistema remoto, ejecuta  linecheck linecheck.log

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

  3. En el sistema local ejecuta

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

  Cuando termine linecheck encontrarás un conjunto de números al final
  de los ficheros linecheck.log. Estos son los que deberías poner como
  linecheck.log local decía que 'escape' era el 29 y 157. Así que, mi
  termrc local escapa (evita) estos caracteres y mi 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 linecheck se cuelga, prueba a usar

  linecheck linecheck.log 17 19

  en el sistema remoto, y

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

  en el sistema local. Esto evitará tus caracteres de xon/xoff (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 termrc. Si tu servidor de terminal
  tiene otros caracteres que lo cuelguen, prueba a correr lineckeck con
  esos caracteres escapados como el ejemplo de arriba. Puedes marcar
  esos caracteres si 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 termrc local tiene las líneas:

       escape 29
       escape 157

  y mi termrc remoto tiene las líneas:

       ignore 29
       ignore 157

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

  4.10.  Prueba a correr el TERM

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

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

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

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

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

  -l $HOME/tlog. Esto registra los errores en el fichero tlog en mi
  directorio home. Muy útil para depurar. No hay razón para no ponerlo.

  -s 38400 : Tengo un módem 14400, con compresión. Para ratios de
  compresión óptimos, necesito poder mandar bits al 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 UART 16450 en tu puerto serie, las velocidades altas
  pueden provocar pérdida de datos por desbordamiento del chip de tu
  puerto serie.  term se recuperará de esto, pero si ves muchos mensajes
  en tu log, (o recibes ``overrun warnings'' en versiones del kernel
  0.99pl15 en adelante) necesitarás reducir este número.

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

  -w 10 -t 150 : De nuevo estas son opciones para optimizar mi enlace de
  módem rápido. Pongo mi ventana a 10 y mi timeout a 150.  Esto lo hago
  de acuerdo con la recomendación de la página de manual de term_setup.

  Vuelve sobre tu máquina local y suspende tu programa de comunicaciones
  (^Z en kermit). No querrás que esté corriendo a la vez que term, ya
  que lucharía con el term 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 DTR), podrías salir del programa en
  este punto.

  Ahora lanza el term local. Yo uso:

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

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

  term debería de funcionar ya :-). Prueba con trsh, a ver qué pasa. Si
  se cuelga, o el enlace parece lento, echa una ojeada a tu tlog en
  ambos extremos. ¿Tienes 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 :-). 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.

  4.11.  Terminar tu conexión term

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

  1. Matar (kill) los programas term a ambos lados de la conexión. Esta
     es la forma menos recomendada de terminar tu conexión.

  2. Una forma mejor es ejecutar el siguiente comando localmente:

          echo '00000' > /dev/modem

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

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

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

  4.12.  Cómo eliminar TERM  de tus particiones.

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

  ·  Eliminar directorios con su contenido. Dependiendo de cómo hayas
     instalado term, tendrás uno o más de los siguientes directorios:

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

  Estos directorios pueden eliminarse con su contenido, usando

  /bin/rm -rf

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

  ·  Los ejecutables y paquetes del term. Esta es la parte más difícil.
     Para los ejecutables, busca en el directorio /usr/local/bin o
     $HOME/bin.

     Con otros ejecutables que hiciste compatibles con term 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.

  ·  Ficheros de librería. Lo mejor es teclear lo siguiente:

       cd /
       find . -name libtermnet* -exec /bin/rm {} \;

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

  ·  Ficheros include. De nuevo, lo mejor es que teclees esto:

       cd /
       find . -name termnet.h -exec /bin/rm {} \;

  ·  Manuales en línea. Cuando instalaste term los manuales se colocaron
     en uno de los directorios siguientes:

       /usr/local/man/man1
       /usr/local/man/cat1
       $HOME/man/man1
       $HOME/man/cat1

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

  ·  Directorio temporal del usuario. Borra el directorio
     /usr/tmp/private y sus contenidos.

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

  4.13.  Optimización de la conexión

  Una vez que consigues ejecutar el term, puede que quieras intentar
  optimizar las cosas. Una buena forma de medir la velocidad de tu
  enlace es corriendo tmon 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 baudrate [velocidad del puerto]  (-s), compression (-c), windows
  [tamaño de ventana]  (-w), timeout [tiempo de espera] (-t) y retrain
  (-A).

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

  Baudrate: el número máximo de bits por segundo que el term intentará
  enviar a través del enlace serie. term 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 baudrate está indicada para sistemas que
  almacenan en buffer la salida al módem. Durante la configuración y el
  ajuste es mejor usar un baudrate pequeño que uno que sea demasiado
  grande. Para enlaces de alta velocidad (> 38400), ponerlo sin límite
  será probablemente ventajoso. Esto se consigue usando el valor off.
  term confiará entonces solamente en el kernel para controlar el flujo.

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

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

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

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

  4.14.  Resolución de problemas

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

  ·  ¿Has borrado la estructura de directorios del term? En las nuevas
     versiones del term ha cambiado un par de veces la estructura del
     árbol de directorios bajo /usr/local/lib/term. 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
     /usr/local/lib/term (salvando tu termrc) y entonces instalar la
     nueva versión. De esta forma evitas pelearte con un árbol de
     directorios lioso.

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

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

  ·  ¿El termtest te está presentando el error:

       Term: failed to connect to term socket '/root/.term/sockettest'

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

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

  Para ello hay que hacer algo parecido a esto:

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

  ·  ¿Estás usando el binario adecuado? El term 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 linecheck. Puede
     usarse una orden del tipo bash -a, o el comando whereis para saber
     qué programa se está ejecutando. Las versiones de term 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.)

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

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

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

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

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

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

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

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

       escape 1,4,30,255
       ignore 1,4,30,255

  Aunque si term no reconoce lo anterior tampoco avisará de ello. Sim­
  plemente lo ignorará.

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

  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

  ·  ¿Está montado tu directorio term o .term con NFS? Si tu directorio
     term o .term está montado con NFS necesitas poner el parámetro
     -DTERM_NFS_DIR en la línea CFLAGS del Makefile. Aunque, al autor el
     usar este parámetro le produce un error de compilación al compilar
     term 1.19 en una máquina con SunOS 4.*.

  ·  ¿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 term debes
     prevenirte de ello.  También cuando se cambia el modo en que esta
     trabajando term (por ejemplo de modo privado a modo shared) deben
     adaptarse las propiedades y permisos de ficheros y directorios.

  ·  ¿Estás obteniendo el error gethostbyname: <hostname>: Non-
     authoritative `host not found', o `server failed'?

     Para resolver esto tienes que chequear las siguientes cosas:

     1. ¿Está configurado correctamente el fichero /etc/hosts?
        <hostname> no es el nombre de tu host (las versiones viejas de
        SLS y algunas viejas y nuevas versiones Slackware se entregan
        con el hostname 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):

          # 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

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

     2. ¿Puede leer todo el mundo tus ficheros /etc/rc* y
        /etc/resolv.conf?

          chmod ugo+r

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

          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

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

          IP Protocols: ICMP, UDP, TCP

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

  ·  ¿Estás obteniendo todo tipo de mensajes timed out en tus ficheros
     log de term? Esto significa que tu conexión de term 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 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 ``''. 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.

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

  5.  Clientes TERM

  Term proporciona varios clientes por defecto. Esto incluye trsh, tmon,
  tupload, tredir, txconn y en nuevas versiones trdate, trdated.
  Además, a partir de la versión 2.0.0 está disponible tudpredir y desde
  la versión 2.1.0 también tdownload.  Esta sección hará referencia a
  trsh, tmon, tupload, tdownload, trdate y trdated. El resto tiene su
  propia sección cada uno.  No funcionará ningún cliente de term hasta
  que se haya establecido un enlace term.
  tmon 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 tmon. Desde la versión 1.11,
  tmon ha tenido un bug que provoca que alguna información se trunque
  (??).

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

  tupload 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ó term en el otro extremo.
  Para colocar los ficheros en otro directorio se deben poner sus
  nombres como segundo argumento a tupload. Por ejemplo, si se desea
  poner una copia del fichero term114.tar.gz en /usr/tmp en el sistema
  remoto, se escribiría tupload term114.tar.gz /usr/tmp.

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

  tdownload 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 term en el
  lado local. Para colocar los ficheros en otro directorio, hay que
  indicar sus nombres como segundo argumento a tdownload. Por ejemplo si
  se quiere poner una copia del fichero term114.tar.gz en /usr/tmp del
  sistema local, escribiría tdownload term114.tar.gz /usr/tmp.

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

  trdate 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 root.

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

  6.  X y TERM

  term 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 txconn. txconn se ejecuta en el remoto, la máquina
  conectada en red; se invoca simplemente como txconn. Se coloca en
  background y devuelve un número a la salida estándard; este número es
  el número de 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 trsh, en mi host remoto, llamado ``foo''.
  En foo realizo lo siguiente:

  foo$ txconn
  Xconn bound to screen 10
  :10
  foo$

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

       setenv DISPLAY foo:10

  (para bash debería usarse export DISPLAY=foo:10). En algunos casos
  además de eso puede ser necesario hacer un xhost + foo en la máquina
  local. Ahora, cuando arranque el cliente, intentará conectar con la
  pantalla 10 de la máquina foo, pero txconn estará escuchando en esa
  pantalla, y pasará todos los paquetes con protocolo X vía term 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 tredir.

  txconn no es terriblemente seguro; cualquiera puede conectar con el
  servidor local vía term y provocar todo tipo de daños. Si este tipo de
  cosas son preocupantes, podría ser una buena idea considerar el uso de
  xauth para autorizar las conexiones. Consulte la página de manual
  sobre 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, LBX. Si, por el contrario, se está
  usando X11R5 puede recurrirse a una utilidad llamada sxpc que comprime
  el protocolo X, mejorando la respuesta sobre líneas serie. sxpc
  incluye un texto sobre cómo hacerlo funcionar con term, y está
  recomendado. El paquete sxpc también explica como usar xauth; por lo
  que está doblemente recomendado.

  7.  tredir

  tredir es una de las utilidades más potentes de term, permitiendo que
  la mayoría de los servicios de red importantes puedan obtenerse en un
  enlace term. Antes de explicar cómo se usa tredir, 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 telnet, que
  proporciona logins entre máquinas, el ftp (File Transfer Protocol), o
  Protocolo de Transferencia de Ficheros, que transfiere ficheros entre
  máquinas, y 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 /etc/services. 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 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 inetd en particular. Cuando se hace una solicitud de
  red, inetd conoce exactamente qué servicio está implicado, por el
  número de puerto al que se hizo la solicitud. Si se configura inetd
  para hacerlo, proporcionará el servicio adecuado a la conexión que lo
  solicita. La configuración de inetd es la que se da en el fichero
  /etc/inetd.conf, que contiene una lista de los servicios que
  proporciona inetd. Para más información vea las páginas de manual de
  inetd e inetd.conf.

  Se puede comunicar directamente con los servicios de red usando telnet
  (nótese bien, no termtelnet). Por ejemplo, para hablar con el demonio
  de sendmail (o smtp) en la máquina nombre_de_máquina;, se puede hacer
  un telnet nombre_de_máquina smtp , o telnet nombre_de_máquina 25, (ya
  que 25 es el puerto asignado a smtp en /etc/services). 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 tredir (ver abajo).

  tredir funciona de modo similar a inetd. Funciona en 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 inetd, tredir traslada la solicitud a través
  del enlace term hasta el term remoto, quien hace la solicitud a la
  red, devolviendo el resultado de nuevo por el enlace hasta el cliente
  local. tredir 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
  term.  tredir ``redirige'' los servicios TCP (Transmision Control
  Protocol) a través del enlace term.

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

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

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

  El principio general de uso del tredir 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 term desde un
  servidor de News de la red. Las News las proporciona el servicio 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 news.domain.org;
  entonces le diremos al software de lectura de News que el servidor
  nntp se encuentra en el puerto 2119 del host local. Como esto
  dependerá del lector de News que se use, probaremos el enlace con
  telnet en lugar de ejecutar un lector de News:

       $ 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).

  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
  term.  (nótese bien, si lee las News de este modo, asegúrese de que en
  todos los mensajes que deje ponga una cabecera 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 From:).

  7.1.  ¡ tredir  puede morder!

  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 tredir
  119 news.domain.org:119 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
  tredir un programa suid, o ejecutar tredir como root, entonces se
  pueden redirigir puertos reservados y evitar así la molestia de
  renombrar servicios.

  Otro problema de usar los puertos reservados es que 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 inetd.conf de modo que 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 # al comienzo de la
  misma. El superusuario tiene que mandar una señal HUP a inetd (kill -1
  <inetd-pid>) para hacer que vuelva a leer su configuración.

  7.2.  Trucos tontos de tredir

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

  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 txconn.
  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 term. ¿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: puerto = 6000 + número de display, 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 DISPLAY en maquinaX:n, los
  clientes X tratarán de conectar con el puerto 6000+n 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
  xterm, 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:

       $ tredir 6002 xmachine:6000
       $ setenv DISPLAY localhost:2
       $ xterm

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

  Observe que en lo que concierne a maquinaX, la solicitud X viene de la
  máquina del extremo remoto del enlace term (máquinaremota) - de modo
  que si necesita autorizar la conexión, debería hacer bien xhost +
  máquinaremota en maquinaX, o bien usar xauth para actualizar el
  fichero .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
  sxpc, que incluye una explicación sobre cómo usar tredir para
  establecer el enlace y autorizarlo usando xauth.

  7.2.2.  Correo con TERM

  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 term 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
  comp.mail.misc, disponible en el ftp anónimo de
  ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc.

  También tiene a su disposición 2 paquetes en el ftp anónimo de
  sunsite.unc.edu que le ayudarán a poner en marcha el correo bajo term
  - son term.mailerd+smail de Byron A. Jeff y 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 Agente de
  Correo de Usuario (MUA - Mail User Agent). Los MUAs ayudan a leer,
  componer y mandar mensajes. Ejemplos de MUAs son el elm, pine, mail y
  vm. Los MUAs 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 (MTA - Mail
  Transfer Agent). Estos son invocados desde los MUAs. Toman el mensaje,
  deciden dónde enviarlo observando la dirección, y finalmente lo envían
  a través de la red.

  Los dos MTAs mas comunes en sistemas Linux son sendmail y smail. La
  idea básica es hacer que su MTA se conecte a otro 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 smtp de
  la máquina en red.  Entonces debe indicar a su 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 MTA de la máquina remota, la
  cual encaminará los mensajes hacia su destino correcto.

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

       tredir XXXX mailhost:25

  donde XXXX es el número de puerto al que se conecta smail en el host
  local (tenga en cuenta que hay que dar un nombre al puerto en
  /etc/services para hacer que smail lo reconozca). smail tiene varios
  ficheros de configuración que generalmente están en
  /usr/local/lib/smail.  Los que nos interesan son config, routers y
  transports.  Observar que presumimos que ya ha configurado 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 config, ponemos la siguiente definición:

       smart_path=localhost

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

  En routers ponemos:

       smart_host:
       driver=smarthost,
       transport=termsmtp;
       path = localhost

  En transports ponemos:

       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,

  En el de arriba, las líneas header cambian la cabecera From en todo
  correo saliente por la dirección SU_DIRECCION_DE_RED, que será la
  dirección de red a la que quiere que le envíen el correo. Si su enlace
  term 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 From:.

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

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

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

  Aquí, PORTNUMBER 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 sendmail a que máquina conectarse, y ponemos
  a termsmtp como mailer por defecto.

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

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

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

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

       tredir PORTNUMBER internet.host:25
       /usr/lib/sendmail -q

  Pasamos ahora a la recepción de correo electrónico usando term.
  Asumiremos que el correo se envía a su cuenta en el servidor de correo
  (mailhost) de la red. La solución más simple es usar trsh o termtelnet
  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 Post Office
  Protocol, (POP). POP fue diseñado precisamente para este propósito:
  enviar correo a máquinas que tienen conexiones de red esporádicas.

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

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

  $ 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

  Si no tiene un servidor POP disponible, el paquete BCRMailHandler
  tiene un programa para capturar su correo desde un enlace term 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
  term.mailerd+smail para este propósito. Sin embargo, BCRMailHandler y
  term.mailerd+smail ya no funcionan con versiones de term 2.0.0 o
  superiores.

  8.  tudpredir

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

  El formato de una llamada a tupredir es:

       tudpredir [esta_maquina:]puerto [la_otra_maquina:]puerto

  9.  Automatizando las cosas.

  Ahora que ya sabe cómo conseguir todos los servicios de red sobre
  term, 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 fet: un front-end para term. Está diseñado para
  introducirle en un sistema remoto y poner en marcha term y todos sus
  tredirs. Cualquier comentario sobre fet será bienvenido.

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

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

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

  La script .kerm_term viene dada por:

       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

  y finalmente, el script tstart que lanza los clientes term es:

  #!/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

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

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

  10.  Portando software para usarlo con term .

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

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

  El último modo de compatibilizar sus programas con term es
  termificándolos.

  10.1.  Portar y compilar los fuentes.

  Portar software a term se puede hacer usando un procedimiento bastante
  sencillo:

  Si está instalado en /usr/local por root:

  1. Añada a los flags de compilación -include
     /usr/local/include/termnet.h

  2. y añada a la lista de librerías -ltermnet

  Si está instalado en su directorio home:

  1. Añada a los parámetros de compilación -include $HOME/term/termnet.h

  2. y añada a la lista de librerías -L$HOME/term -ltermnet

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

  En este momento los comandos deberían funcionar con y sin term.

       telnet localhost

  no usa term para conectar, pero

       telnet bohr.physics.purdue.edu

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

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

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

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

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

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

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

  10.2.  Termificar  ( termify ).

  Este paquete convertirá los binarios enlazados dinámicamente para usar
  term.

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

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

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

       termify <programa>

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

       termify -u <programa>

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

  11.  Clientes term .

  11.1.  Clientes term  disponibles en los servidores ftp .

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

  1. ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/apps

  2. ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/extra

  ¡Allá vamos! :-)

  paquete TERM:

  tupload
  tdownload           (versiones 2.1.0 y posteriores)
  trsh
  tmon
  tredir
  tudpredir           (versiones 2.0.0 y posteriores)
  txconn
  trdate(d)
  tshutdown
  libtermnet

  Transferencia de ficheros:

       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

  Sistemas de Información:

       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

  Acceso remoto:

       termtelnet          sunsite.unc.edu
       rlogin              physics.purdue.edu:/pub/bcr/term/extra
       rsh                 physics.purdue.edu:/pub/bcr/term/extra

  Noticias (news):

       tin 1.3             sunsite.unc.edu:/pub/Linux/system/Mail/news
       news2               sunsite.unc.edu

  Correo:

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

  Scripts automatizadores:

       JoelTermStuff       sunsite.unc.edu
       autoterm            sunsite.unc.edu
       fet                 sunsite.unc.edu

  Otros programas:

       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

  11.2.  El paquete termnet .

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

       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

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

  11.3.  Solicitado, pero aún no soportado:

  1. DOOM: El problema con este juego parece ser el hecho de que usa el
     puerto 5029 ya sea como cliente o como servidor.

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

  12.  Term  y la seguridad

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

  12.1.  trsh .

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

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

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

       denyrsh on

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

  12.2.  txconn  y xauth

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

  12.3.  sxpc , xhost  y xauth

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

  Usar xauth es muy importante para mantener la seguridad cuando se usa
  sxpc. Si no usas xauth al usar sxpc, será muy peligroso tener xhost +.
  Algunos peligros son:
  ·  Alguien puede saber lo que hay en tu pantalla

  ·  Alguien puede saber lo que tecleas

  ·  Alguien puede teclear sobre alguna de tus ventanas (por ejemplo, un
     comando que borre tus ficheros :-( )

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

  NOTA: cuando uses xauth asegúrate que la variable $DISPLAY no tiene el
  valor localhost (o localhost:loquesea). Si tu variable $DISPLAY vale
  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 README, y compilas sin la
  variable -DNOGETHOSTNAME puede que todo funcione.

  Sea C la máquina que ejecuta clientes, y 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 <clave> en este ejemplo:

  En C:

       % 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

  En D:

       % 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

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

       #!/bin/sh
       exec X  -auth $HOME/.Xauthority $*

  Asegúrate que el fichero .Xauthority es legible sólo por C y por D.

  13.  Cosas a recordar

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

  Ftp:

  ·  ftp://sunsite.unc.edu:/pub/Linux/apps/comm/term/

  ·  ftp://sunsite.unc.edu:/pub/Linux/docs/HOWTO/

  ·  ftp://physics.purdue.edu:/pub/bcr/term/

  URL:

  ·  http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html

  ·  http://www.bart.nl/~patrickr/term-howto/Term-HOWTO.html (siempre
     tiene la última versión)

  ·  http://physics.purdue.edu/~bcr/homepage.html

  Netnews:

       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.

  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 term, de qué modo establece su
  conexión, etc.).

  En este momento hay en uso muchas versiones de 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 term está usando. De
  lo contrario, en algunos casos sólo por adivinación será posible
  ayudarle a resolver sus problemas.

  Documentos relacionados:

  ·  Using Term to Pierce an Internet Firewall HOWTO de Barak
     Pearlmutter,
     bap@learning.scr.siemens.com

  ·  Cortafuegos-Como (-- Disponible en castellano, consulte la sección
     ``''--) de David Rudder, drig@execpc.com

  ·  Serial HOWTO, de Greg Hankins, gregh@cc.gatech.edu

  ·  Net-2/Net-3 HOWTO de Terry Dawson, terryd@extro.ucc.su.oz.au

  14.  Estabilidad de las versiones de term

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

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

  15.  Tabla de velocidad de term .

  Gracias a Bill McCarthy ahora disponemos de una tabla con información
  de la velocidad de term para diferentes módems, versiones de term 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.

                             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.

  16.  Pistas y trucos encontrados en la red

  En los grupos de news relacionados con Linux surgen de nuevo muchas
  preguntas sobre term 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.

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

     1. Acceda al sistema remoto usando:

          trsh -s telnet <hostname>

     2. Ponga resize; clear en su fichero .login

     3. La mejor solución parece ser poner lo siguiente en el remoto:

          stty 38400

  ·  Mucha gente parece tener problemas con caídas de la conexión term,
     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
     term sigue viva o no. Esto se puede probar usando estos pequeños
     ejemplos de shell scripts:

     Si está usando tcsh:

       if ( { trsh -s true } ) then
         ...
       endif

  Si está usando bash:

       if trsh -s true; then
         ...
       fi

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

     1. Termificar el netscape

     2. Lanzar termnetscape. En el menú Options | Preferences |
        Mail/Proxys dejar todos los campos proxy en blanco; poner en el
        campo SOCKS: remotehost y 80

     3. Ignorar el error que saldrá en el menú de opciones.

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

     5. Ignorar el error que saldrá en el menú de opciones.

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

  ·

           tredir local:8080 remota:80

  Donde remota es el nombre remoto del servidor proxy.

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

                       export http_proxy=http://localhost:8080/
                       export ftp_proxy=http://localhost:8080/

  17.  Otras Cosas

  Algunas cosas que se podrían incluir:

  ·  Aumento de soluciones a problemas

  ·  Extensión del tema sobre seguridad

  ·  termwrap

  ·  Sugerencias

  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 Term-COMO. Se me puede encontrar
  (actualmente) en patrickr@cs.kun.nl o en patrickr@sci.kun.nl.

  18.  Reconocimientos

  Hay que dar las gracias a mucha gente. Primero y principalmente a
  Michael o'Reilly y todos los desarrolladores del term, 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.
  19.  Anexo: Grupos LiNUXeros en España.

  Francisco José Montilla, pacopepe@nova.es, FidoNet 2:345/402.22 es
  coordinador del INSFLUG: (Impatient & Novatous Spanish Fidonet LiNUX
  Users Group) uno de los varios grupos de usuarios existentes en
  España, y más concretamente en la mejor ;-) área de FidoNet: R34.LINUX
  junto con LuCas (LinUx en CAStellano).

  El INSFLUG se orienta preferentemente a la traducción de documentos
  breves, como los Howtos y PUFs (-- Preguntas de Uso Frecuente, las
  FAQs. :)--) , etc.

  LuCas Coordina y realiza las traducciones de las guides, es decir,
  documentos más extensos.

  Por supuesto, la orientación de cada grupo no tiene carácter
  excluyente;  si quieres colaborar en las dos, ¡mejor! ;-).

  Actualmente están siendo traducidos varios COMOs y FAQs, además de las
  ``guides''.

  Otra fuente de información obligada para el recién incorporado son las
  FAQ elaboradas a partir del correo circulante por R34.LINUX por Pablo
  Gómez, pgomez@laereas.aiva.com, 2:341/43.40, disponibles próximamente
  en los formatos habituales de documentación (ps, dvi, html, sgml, etc)
  en los servidores de Internet especificados más adelante, así como en
  el mismo área.

  ¡Necesitamos tu colaboración para futuras traducciones! si quieres
  unirte a nosotros ponte en contacto con:

  INSFLUG:

  Francisco José Montilla, pacopepe@nova.es, FidoNet 2:345/402.22

  LuCas:

  1. Juan José Amor, jjamor@infor.es, FidoNet 2:341/12.19

  2. Alfonso Belloso, alfon@bipv02.bi.ehu.es, FidoNet 2:344/17.2

  Puedes obtener traducciones de:

  FidoNet:

  ·  Elektra (95) 4164934/4161749 33k6/14k4

  ·  La Voix (95) 4275081/4275321 28k8/14k4

  Si se da el caso de que carezcas de acceso a Internet, y no encuentras
  los COMOs en alguna de estas dos direcciones, no dudes en ponerte en
  contacto conmigo, y me encargaré de subirlas a alguna de las dos.

  Por último, recordarte que un inmejorable lugar para estar informado,
  así como consultar y discutir todo lo relacionado con LiNUX lo tienes
  en FidoNet, en R34.LINUX.

  Actualmente, ambos grupos poseen las siguientes listas de correo:

  ·  LuCas: lucas@bipv02.bi.ehu.es

  ·  INSFLUG: insflug@nova.es

  Ambas son listas tipo majordomo; para suscribirte, por ejemplo a la
  del INSFLUG, envía un email a majordomo@nova.es, con "subscribe
  insflug" en el cuerpo del mensaje.

  Dispones de todos los ``COMOs'' traducidos hasta ahora, así como
  información puntual sobre el INSFLUG y temas relacionados en:

  http://www.insflug.nova.es en sus versiones html, y listas para bajar,
  en http://ftp.insflug.nova.es

  Otro buen punto de búsqueda, consulta, y obtención de la documentación
  traducida, en formato HTML, con links a los demás formatos, así como
  las traducciones de las guías traducidas por LuCAS es:

  http://www.infor.es/LuCAS/

  junto con su ftp:

  ftp://ftp.infor.es/pub/LuCAS/

  Tanto el INSFLUG, como LuCAS, y todos los traductores implicados,
  esperamos que esta traducción te haya sido de utilidad.

