TERM
Como
patrickr@bart.nl
alfon@bipv02.bi.ehu.es
Revisión 0.1, Fco. J. Montilla,
pacopepe@nova.es
Term
en Linux.
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.
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.
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í.
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
.
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.
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.
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.
En las versiones nuevas del term
han aparecido dos conceptos
nuevos. Estos dos conceptos se explican en los siguientes apartados.
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
.
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.
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:
TERM
hasta la versión 1.15TERM
, versiones 1.16 hasta 1.19TERM
, versiones 2.0.0 y superiores
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.
term
, versiones 1.16 hasta 1.19
Para construir el term
ahora puedes elegir una de las siguientes
formas:
term
en modo privadoterm
en modo sharedroot
, construir el term
en modo privadoroot
, construir el term
en modo sharedAbajo se explicará cómo habilitar/deshabilitar la opción shared
durante la compilación del term
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.
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=
).
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=
).
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=
).
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:
term
en modo privado sin full term networkingterm
en modo privado con full term networkingterm
en modo shared sin full term networkingterm
en modo shared con full term networkingEn 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).
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 manual.
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 manual.
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.
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.
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).
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.
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
term
en modo compartido hay dos formas
de definir las variables:
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
).
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
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.
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.
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
.
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.
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.
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:
linecheck linecheck.log
^Z
en kermit
) (si no te robará caracteres del linecheck
).
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
'escape' en el termrc
al otro lado del enlace. Por ejemplo, mi
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'.
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.
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:
kill
) los programas term
a ambos lados de la
conexión. Esta es la forma menos recomendada de terminar tu conexión.
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.
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.
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.
TERM
de tus particiones.
Ok, me habéis preguntado por esto. Así que voy a presentar los pasos a
seguir para desinstalar term
:
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
/etc/group
una línea
con ese grupo y bórrala.
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.
cd /
find . -name libtermnet* -exec /bin/rm {} \;
Esto encontrará y borrará todos los ficheros de librería relacionados
por todo tu disco duro.
include
. De nuevo, lo mejor es que teclees esto:
cd /
find . -name termnet.h -exec /bin/rm {} \;
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
.
/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
.
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
.
En esta sección se dan algunas opiniones sobre qué comprobar cuando se
tienen problemas ejecutando el term
o alguno de sus clientes.
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.
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
.
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.
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 similar).
Para ello hay que hacer algo parecido a esto:
ln -s /usr/local/bin/term /usr/src/term-<numero_de_version>/term
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.)
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
!).
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
.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. Simplemente lo ignorará.
Cuando tienes que ignorar o ``escapar'' caracteres, tendrás que ponerlos
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
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.*.
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.
gethostbyname: <hostname>:
Non-authoritative `host not found', o `server failed'
?
Para resolver esto tienes que chequear las siguientes cosas:
/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
pongas otros nodos de Internet en ese fichero, pues term
no
trabajará con ellos.
/etc/rc*
y
/etc/resolv.conf
?
chmod ugo+r
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.
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
optimizando
. Además, esta
parte de la instalación es un proceso de prueba y error. No se pueden dar
unas reglas fijas sobre los valores a colocar en los variados parámetros
ya que son muchos los factores que influyen en la conexión. Estos
factores difieren entre las conexiones e incluso en el tiempo.
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 TERM
ificada de ftp
o ncftp
. Sin embargo, algunas de estas aplicaciones adaptadas tampoco
funcionarán.
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.
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.
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:
).
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.
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.
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 <@@formula>6000+n@@endformula> 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
.
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.
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
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
.
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.
Portar software a term
se puede hacer usando un procedimiento bastante
sencillo:
Si está instalado en /usr/local
por root
:
-include
/usr/local/include/termnet.h
-ltermnet
Si está instalado en su directorio home:
-include $HOME/term/termnet.h
-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
.
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:
.
term
.
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:
ftp://sunsite.unc.edu/pub/Linux/apps/comm/term/apps
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
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.
DOOM
: El problema con este juego parece ser el hecho de que
usa el puerto 5029 ya sea como cliente o como servidor.
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
.
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.
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.
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.
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:
:-(
)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.
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:
bap@learning.scr.siemens.com
Disponible en castellano, consulte la sección Gruposde David Rudder,
drig@execpc.com
gregh@cc.gatech.edu
terryd@extro.ucc.su.oz.au
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 -->
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.
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.
vi
porque les muestra menos de 24 líneas en ventanas con 24
líneas. Hay dos formas de resolver este problema:
trsh -s telnet <hostname>
resize; clear
en su fichero .login
stty 38400
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
netscape
causa a la gente
problemas para funcionar con term
. La buena noticia es que puede
funcionar. He aquí cómo:
termnetscape
. En el menú Options | Preferences |
Mail/Proxys
dejar todos los campos proxy
en blanco; poner en el
campo SOCKS
: remotehost
y 80Options | Preferences |
Mail/Proxys
dejar todos los campos proxy
en blanco, poner en el
campo SOCKS
: none
y 80
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.
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/
Algunas cosas que se podrían incluir:
termwrap
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
.
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.
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:
jjamor@infor.es
, FidoNet 2:341/12.19
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@bipv02.bi.ehu.es
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:
junto con su ftp
:
Tanto el INSFLUG, como LuCAS, y todos los traductores implicados, esperamos que esta traducción te haya sido de utilidad.