Guía de Administración de Redes con Linux - Ficheros de configuración de UUCP (II)

Cómo informar a UUCP sobre otros sistemas mediante el fichero sys

En el fichero sys se describen los sistemas que conoce su máquina. La clave system nos presenta una nueva entrada; las líneas siguientes hasta la próxima directiva system detallan las variables específicas de cada sitio. Comúnmente, una entrada de sistema define variables como el número de teléfono y el diálogo de entrada.

Las variables anteriores a la primera línea system especifican valores predeterminados a usar en todos los sistemas. Normalmente, colocará en esta sección variables del protocolo y similares.

Los campos más importantes se tratan en detalle en las siguientes secciones.

Nombre del sistema

La orden system nombra el sistema remoto. Debe especificar el nombre correcto del sistema remoto, no un alias que se invente, porque uucico lo comparará con la identificación que reciba del sistema remoto una vez se conecte a él. [4]

Cada nombre de sistema puede aparecer una sola vez. Si quiere usar varias configuraciones para un mismo sistema (por ejemplo, números de teléfono diferentes que uucico puede usar alternativamente), puede especificar alternativas, que se describen más adelante.

Número de teléfono

Si va a conectarse con el sistema remoto por vía telefónica, en el campo phone se especifica el número que debería marcar el módem. Puede contener varios separadores que interpretará el procedimiento de marcado de uucico. Un signo de igual (=) significa esperar un tono de marcado secundario y un guión (-) genera una pausa de un segundo. Algunas instalaciones telefónicas pueden atrancarse si no se realizan pausas entre códigos de acceso especiales y los números de teléfono.[5]

A menudo resulta conveniente usar nombres en vez de números para describir los códigos de marcado según la zona. El fichero dialcode le permite asociar un nombre con un código que use al especificar números de teléfono para las máquinas remotas. Suponga que tiene el siguiente fichero dialcode:

|| # /usr/lib/uucp/dialcode - traducción de los códigos de marcación Bogoham 024881 Coxton 035119 ||

Con estas traducciones, puede usar un número de teléfono tal que Bogoham7732 en el fichero sys, que lo hará probablemente algo más legible y mucho será mucho más fácil actualizar el código de marcación para Bogoham cada vez que cambie.

Puerto y velocidad

Las opciones de puerto y velocidad se usan para elegir el dispositivo a usar para llamar al sistema remoto y la velocidad máxima a la que debería ajustarse el dispositivo.[6] En una entrada de system se puede usar una opción o varias de manera conjunta. Cuando se busca un dispositivo adecuado en el fichero port, sólo se eligen los dispositivos con un nombre de puerto y/o rango de velocidad que coincidan con los especificados.

Por lo general debería ser suficiente utilizar únicamente la opción speed. Si sólo dispone de un dispositivo serie definido en port, uucico siempre toma el adecuado por lo que sólo tiene que especificar la velocidad deseada. Si tiene varios módems conectados a sus sistemas, con frecuencia no querrá nombrar un puerto concreto, porque si uucico encuentra que muchos coinciden prueba con cada dispositivo hasta que encuentra uno que no se esté usando.

Antes ya nos encontramos con la macro del diálogo de entrada, que le dice a uucico cómo entrar en el sistema remoto. Consiste de una lista de palabras clave, que especifican el texto que se espera y el que se envía por el proceso local de uucico. El objetivo es hacer que uucico espere hasta que la máquina remota envíe una línea pidiendo el nombre de usuario, y entonces enviar el nombre de usuario, luego esperar a que pida la palabre clave, y enviar dicha clave. Los textos de espera y de envío se dan alternativamente. uucico automáticamente añade un avance de línea (\r) a cualquier texto enviado. Por lo tanto, una macro de diálogo sencilla sería parecida a esta:

|| ogin: vstout ssword: catch22 ||

Dése cuenta de que los campos de texto de espera probablemente no contendrán el texto completo. Esto es así para asegurarse de que el proceso de entrada se lleve a cabo aunque el sistema remoto nos envíe Login: en vez de login:. Si la cadena que está esperando o enviando contiene espacios u otros caracteres de espacios en blanco, debe usar comillas para delimitar el texto.

uucico también permite usar estructuras condicionales, por ejemplo en el caso de que el programa getty de la máquina remota necesite ser reinicializado antes de enviar una pregunta. Por esta razón, usted puede añadir un sub-diálogo a un texto de espera, separado con un guión. El sub-diálogo se ejecuta sólo si el primer texto de espera falla, ej. si expira un temporizador. Una manera de usar esta característica es enviar un BREAK si el sistema remoto no envía una pregunta de nombre de usuario. El siguiente ejemplo muestra un ejemplo de una macro de diálogo que debería funcionar también en el caso de que usted tenga que pulsar Enter antes de que aparezca la pregunta de entrada. El primer parámetro vacío, ##, comunica a UUCP que no espere nada sino que continúe con la siguiente cadena de envío: || \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22 ||

Hay un par de cadenas de caracteres especiales y caracteres de escape que pueden aparecer en la macro de diálogo. Esta es una lista incompleta de caracteres legales en la pregunta de espera:

## La cadena vacía comunica a **uucico** que no espere nada, sino que siga de inmediato con la siguiente cadena enviada. \t Carácter de tabulador. \r Carácter de retorno de línea. \s Carácter de espacio. Se necesita para incluir espacios en un diálogo. \n Carácter de línea nueva. \\ Carácter de barra invertida. En cadenas de caracteres de envío se pueden incluir, además de los mencionados anteriormente, los siguientes caracteres: EOT Carácter de fin de transmisión (**^D**). BREAK Carácter Break. \c Suprime el envío del carácter del línea nueva al final de cada cadena de caracteres. \d Retrasa el envío 1 segundo. \E Activa la comprobación de eco. De esta forma, **uucico** esperará a leer el eco de todo lo que escribe en el dispositivo antes de que continúe con el diálogo. Se usa principalmente en diálogos de modems (que veremos más adelante). La comprobación de eco está desactivada por omisión. \e Desactiva la comprobación del eco. \K Lo mismo que BREAK. \p Pausa de una fracción de segundo. ==== Alternativas ==== A veces es deseable tener múltiples entradas para un mismo sistema, por ejemplo si se puede acceder al sistema en diferentes líneas de módem. Con Taylor UUCP se puede hacer esto definiendo una //alternativa// Una entrada alternativa mantiene todas las características de la entrada principal, y especifica solamente aquellos valores que tienen que ser cambiados, o añadidos. Una alternativa está separada de la entrada principal por una línea que contiene la palabre clave alternate Para usar dos números de teléfono para pablo, habría que modificar su entrada ##sys## de la siguiente manera: || system pablo phone 123-456 .. lo mismo de antes ... alternate phone 123-455 || Ahora, cuando llame a pablo, el programa **uucico** marcará primero el 123-456, y si no funciona, probará la alternativa. La entrada alternativa retiene toda la otra información de la entrada de sistema principal, y altera sólo el número de teléfono. ==== Restringir horas de llamada ==== Taylor UUCP proporciona varios métodos para restringir las horas a las que se pueden efectuar llamadas a un sistema remoto. Una razón para hacer esto sería por las limitaciones que el sistema remoto impone en sus servicios durante horas de oficina, o simplemente para evitar las horas más caras. Siempre se pueden desactivar las restricciones con la opción ##–S## o ##–f## en el programa **uucico**. Por defecto, Taylor UUCP no permite conexiones a ninguna hora, así que usted //tiene que// especificar algún horario en el fichero ##sys##. Si no le importan las restricciones, puede especificar la opción **time** con un valor de Any en su fichero ##sys##. La manera más sencilla de restringir los horarios de las llamadas es incluir una entrada time seguida de una cadena formada por los subcampos día y hora. Día puede ser una combinación de Mo, Tu, We, Th, Fr, Sa, y Su. También puede especificar Any, Never, o Wk para los días laborables. La hora está formada por dos valores de reloj de 24 horas separados por un guión. Especifican las horas durante las que pueden efectuarse llamadas. La combinación de estos elementos se escribe sin espacios en blanco entre ellos. Se pueden especificar varios pares día-hora separados por comas, tal y como se muestra en esta línea: || time MoWe0300-0730,Fr1805-2200 || En este ejemplo se permiten llamadas en Lunes y Miércoles, de 3 de la mañana a 7:30, y los Viernes entre las 6:05 y las 8:00 de la tarde. Cuando un campo de hora incluye la medianoche, como Mo1830-0600, en realidad quiere decir el Lunes, entre medianoche y las 6 de la mañana, y entre las 6:30 de la tarde y medianoche. Las palabras especiales Any y Never significan que se pueden hacer llamadas siempre o nunca, respectivamente. Taylor UUCP también tiene algunos elementos especiales que puede usar en cadenas de tiempo como NonPeak y Night. Estos elementos especiales son abreviaturas de Any2300-0800,SaSu0800-1700 y Any1800-0700,SaSu respectivamente. La orden //time// tiene una segunda variable opcional que describe el tiempo a esperar para reintentar en minutos. Cuando un intento de conexión falla, **uucico** no permitirá otro intento de llamar al ordenador remoto hasta que transcurra un cierto tiempo. De manera predeterminada, **uucico** usa un algoritmo de espera exponencial, según el cual el intervalo de espera se incrementa con cada intento fallido. Por ejemplo, si especifica un tiempo de reintento de 5 minutos, **uucico** no aceptará llamar otra vez en los 5 minutos después del ultimo intento fallido. La orden **timegrade** le permite adjuntar un rango máximo de cola a un calendario. Por ejemplo, asuma que tiene las siguientes órdenes **timegrade** en una entrada system: || timegrade N Wk1900-0700,SaSu timegrade C Any || Esto permite que los trabajos con rango de cola de C o mayor (normalmente el correo se pone en la cola con rango B o C) sean transferidos siempre que se establece una comunicación, mientras que las noticias (normalmente con rango N) serán transferidas sólo durante la noche y los fines de semana. Al igual que **time**, la orden **timegrade** toma un intervalo entre reintentos de minutos como una tercera variable opcional. De todas formas, hay que hacer una observación sobre los rangos de la cola. Primero, la opción **timegrade** sólo se afecta a lo que //sus// sistemas envían; el sistema remoto puede transferir lo que quiera. Puede usar la opción **call-timegrade** para solicitarle de manera explícita que envíe solamente tareas por encima de un determinado rango de cola; pero no hay hay ninguna garantía de que vaya a obedecer a su petición.[7] De manera similar, el campo ##//timegrade//## no se comprueba cuando llama un sistema remoto, por lo que se le enviará cualquier tarea de la cola que sea para él. De todos modos, el sistema remoto puede solicitar explícitamente a su **uucico** que se ocupe únicamente de cierto rango de la cola. ===== [[ Identificar dispositivos disponibles mediante el fichero port]] ===== El fichero ##port## hace saber a **uucico** los puertos disponibles. Se trata normalmente de puertos de módem, pero también se soportan otros tipos como las líneas serie y los sockets de TCP. Al igual que el fichero ##sys##, ##port## está formado por entradas separadas que comienzan con la palabra clave port seguida del nombre del puerto. Este nombre también puede usarse en la sentencia port del fichero ##sys##. No es necesario que el nombre sea único; si hay muchos puertos con el mismo nombre, **uucico** probará con cada uno hasta que encuentre alguno que pueda usar. La orden **port** debería estar seguida inmediatamente por la sentencia type, que indica qué tipo de puerto se describe. Tipos válidos son modem, direct para conexiones directas y tcp para sockets de TCP. De no existir la orden **port** se usará de manera predeterminada módem como tipo de puerto. En esta sección sólo hablaremos de puertos de módem; los puertos TCP y las líneas directas se tratarán en una sección posterior. Tanto para el módem como para los puertos directos, debe especificar el dispositivo para llamar por medio de la directiva device. Normalmente, se trata del nombre del fichero especial de dispositivo del directorio ##/dev##, como ##/dev/ttyS1##. En el caso de un módem, la entrada del puerto también determina qué tipo de módem hay conectado al puerto. Los diferentes tipos de módem tienen que configurarse de manera diferente. Incluso los módems que dicen ser compatibles con Hayes no son siempre realmente compatibles unos con otros. Por lo tanto, tiene que comunicarle a **uucico** cómo inicializar el módem y hacerle marcar el número deseado. Taylor UUCP mantiene las descripciones de todos los marcadores en un fichero llamado ##dial##. Para usar cualquiera de éstos, tiene que especificar el nombre del marcador mediante la orden **dialer**. A veces querrá usar un módem de diferentes maneras dependiendo de a qué sistema llame. Por ejemplo, algunos módems antiguos no entienden cuando un módem rápido trata de conectar a 56 kbps; simplementen dejan caer la línea en vez de negociar una conexión a 9.600 bps, por ejemplo. Cuando sabe que el sitio pesado usa un módem tan tonto, tiene que configurar su módem de una manera diferente cuando le llame. Para esto, necesita una entrada de puerto adicional en el fichero ##port## en la que especificar un marcador diferente. Ahora puede darle al nuevo puerto un nombre diferente, como serie1-lento y usar la directiva port en la entrada del sistema pesado en ##sys##. Otra manera de distinguir los puertos es por la velocidad que usan. Por ejemplo, las dos entradas de puerto de la situación anterior pueden ser así: || # módem Nakwell; conectar a alta velocidad port serie1 # port name type modem # modem port device /dev/ttyS1 # this is COM2 speed 115200 # supported speed dialer nakwell # normal dialer # módem Nakwell; conectar a baja velocidad port serie1 # port name type modem # modem port device /dev/ttyS1 # this is COM2 speed 9600 # supported speed dialer nakwell-slow # don't attempt fast connect || La entrada de sistema para el sitio pesado daría ahora serie1 como el nombre del puerto, pero solicitaría usarlo sólo a 9.600 bps. **uucico** usa entonces automáticamente la segunda entrada de puerto. Al resto de sitios que tengan una entrada de 115.200 bps en la entrada del sistema se les llamará usando la primera entrada de puerto. De manera predeterminada, se usará la primera entrada con una velocidad que coincida. ===== Cómo marcar un número usando el fichero dial ===== En el fichero ##dial## se describen las maneras de utilizar diferentes marcadores. Tradicionalmente, UUCP habla de marcadores y no tanto de módems, porque antaño era habitual disponer de un (caro) dispositivo de marcado automático que servía a un completo banco de módems. Hoy en día la mayoría de los módems llevan ya el soporte de marcación integrado, por lo que esta distinción ha tendido a desvanecerse. No obstante, marcadores o módems diferentes pueden requerir una configuración diferente. Puede describir cada uno de ellos en el fichero ##dial##. Las entradas de ##dial## comienzan con la orden **dialer** que proporciona el nombre del marcador. La entrada más importante aparte de **dialer** es el diálogo del módem, especificado por la orden **chat**. Similar al diálogo de entrada en el sistema, consta de una secuencia de cadenas que **uucico** envía al marcador y las respuestas que espera como respuesta. Suele usarse para reiniciar el módem a algún estado conocido y marcar el número. En la siguiente entrada de dialer de ejemplo se muestra un típico diálogo de módem para un módem compatible con Hayes: || # módem NakWell; conectar a alta velocidad dialer nakwell # nombre del marcador chat AT&F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT chat-fail BUSY chat-fail ERROR chat-fail NO\sCARRIER dtr-toggle true ||

El diálogo comienza con "", la cadena vacía esperada. uucico envía entonces la primera orden AT&F. AT&F es la orden Hayes para reiniciar el módem a la configuración predeterminada de fábrica. uucico espera entonces hasta que el módem haya enviado OK y envía la siguiente orden, que desactiva el eco local y cosas así. Tras devolver el módem OK nuevamente, uucico envía la orden de marcado ATDT. La secuencia de escape \T de esta cadena se sustituye por el número de teléfono tomado de la entrada de sistema del fichero sys. uucico espera entonces a que el módem le devuelva la cadena CONNECT, que indica que se ha establecido con éxito la conexión con el módem remoto.

A veces el módem falla al conectar con el sistema remoto; por ejemplo, si el otro sistema está comunicándose con alguien más y la línea está ocupada. En este caso, el módem devuelve un mensaje de error indicando la razón. Los diálogos de módem son incapaces de detectar este tipo de mensajes; uucico sigue esperando la cadena esperada hasta que se agota el temporizador. El fichero de registro de UUCP sólo muestra entonces un “tiempo agotado en el guión de diálogo” en vez de la razón específica.

No obstante, Taylor UUCP le permite informar a uucico sobre estos mensajes de error usando la orden chat-fail como se ve en el ejemplo. Cuando uucico detecta una cadena de caracteres de error en el diálogo mientras lo ejecuta, interrumpe la llamada y anota el error en el fichero de registro de UUCP.

En la última orden del ejemplo anterior se comunica a UUCP que cambie la línea de control DTR (Terminal de Datos Preparado) antes de iniciar el diálogo del módem. Normalmente, el controlador serie levanta DTR cuando un proceso abre el dispositivo para decirle al módem conectado que alguien quiere hablar con él. La prestación dtr-toggle deja caer DTR, espera un momento, y lo levanta de nuevo. Muchos módems pueden configurarse para reaccionar ante una caída de DTR entrando en "off-hook", entrando en estado de órdenes o reiniciándose ellos mismos. [8]

Por muy absurdo que suene en principio, el uso de UUCP para transferir datos sobre TCP no es una idea tan mala, especialmente cuando se transfieren grandes cantidades de datos como los grupos de noticias Usenet. En conexiones basadas en TCP, los grupos de noticias se transmiten generalmente usando el protocolo NNTP, según el cual los artículos se piden y se transmiten individualmente, sin compresión ni ninguna otra optimización. Aunque es una técnica adecuada para ordenadores grandes con varias fuentes de grupos de noticias simultáneas, esta técnica no es favorable para pequeños sistemas que reciben los grupos a través de una conexión lenta, como RDSI. Estos ordenadores normalmente desean combinar las cualidades de TCP con las ventajas de enviar artículos en grandes lotes, que se pueden comprimir y por lo tanto transferir con muy poco gasto. Un método estándar de enviar estos lotes es usando UUCP sobre TCP.

En sys, especificaríamos que se llamase a un sistema por TCP de esta manera:

|| system gmu address news.groucho.edu time Any port tcp-conn chat ogin: vstout word: clouseau ||

La orden address da la dirección IP de la máquina o su nombre de dominio completamente cualificado. La entrada port correspondiente sería tal que así:

|| port tcp-conn type tcp service 540 ||

En la entrada se afirma que debería usarse una conexión TCP cuando una entrada sys hiciese referencia a tcp-conn, y que uucico debería intentar conectarse al puerto 540 de la red TCP en la máquina remota. Éste es el número de puerto predeterminado del servicio UUCP. En vez del número de puerto, también puede proporcionar un nombre de puerto simbólico a la orden service. El número de puerto correspondiente a este nombre se buscará en /etc/services. El nombre común para el servicio UUCP es uucpd.

Usar una conexión directa

Supongamos que usa una línea directa para conectar su sistema vstout con tiny. Al igual que en el caso del módem tiene que escribir una entrada de sistema en el fichero sys. La orden port identifica el puerto serie en el que está conectado tiny:

|| system tiny time Any port direct1 speed 38400 chat ogin: cathcart word: catch22 ||

En el fichero port, tiene que describir el puerto serie para la conexión directa. Una entrada dialer no es necesaria porque no hay necesidad de marcar:

|| port direct1 type direct speed 38400 device /dev/ttyS1 ||

Notas

|| [1] || Si sólo quiere probar UUCP, obtenga el número de un sistema cercano a usted. Apunte el nombre de usuario y la clave— son públicos para permitir posibles transferencias anónimas. En la mayoría de los casos, son algo como uucp/uucp o nuucp/uucp. ||
|| [2] || La única limitación es que no puede ser más largo que siete caracteres, para no confundir a algunos nodos con sistemas de ficheros que imponen un estrecho límite en los nombres de ficheros. ||
|| [3] || El Proyecto de Mapeado UUCP registra los nombres de nodos UUCP en todo el mundo y asegurándose de que sean únicos. ||
|| [4] || Los UUCPs Versión 2 antiguos no hacen saber su nombre cuando se les llama; de todos modos, sí lo hacen las implementaciones más recientes, y así lo hace Taylor UUCP. ||
|| [5] || Por ejemplo, muchas instalaciones de compañías privadas requieren que marque un 0 o un 9 para obtener línea hacia el exterior. ||
|| [6] || La velocidad en baudios del terminal tty debe configurarse al menos como la máxima velocidad de transferencia. ||
|| [7] || Si el sistema remoto usa también Taylor UUCP es seguro que obedecerá. ||
|| [8] || A algunos módems parece no gustarles esto y se cuelgan ocasionalmente. ||