16.2. Ficheros de configuraci�n de UUCP

16.2.1. Una ligera introducci�n a Taylor UUCP

Decir que la configuraci�n de UUCP es dif�cil ser�a una descripci�n insuficiente. Es cierto que es un asunto peliagudo, y el formato a veces demasiado conciso de los ficheros de configuraci�n no hace las cosas m�s f�ciles (aunque el formato de Taylor es casi f�cil de leer comparado con los formatos m�s antiguos en HDB o Versi�n 2).

Para darle una idea de c�mo se interact�a con estos ficheros, le introduciremos los m�s importantes, y echaremos un vistazo a algunos ejemplos. No explicaremos ahora todo en detalle; una explicaci�n m�s precisa se describe en secciones posteriores. Si quiere configurar su ordenador para UUCP, puede comenzar con los ficheros de ejemplo, y adaptarlos gradualmente. Puede elegir los que se muestran a continuaci�n, o los que se incluyen en su distribuci�n de Linux preferida.

Todos los ficheros descritos en esta secci�n se guardan en /etc/uucp o en un subdirectorio de �ste. Algunas distribuciones de Linux contienen binarios de UUCP con soporte tanto para la configuraci�n HDB como Taylor activado, y emplean diferentes subdirectorios para cada grupo de ficheros de configuraci�n. Seguramente habr� un fichero README en /usr/lib/uucp.

Para que UUCP funcione correctamente, estos ficheros tienen que pertenecer al usuario uucp. Algunos de ellos tienen claves y n�meros de tel�fono, y por lo tanto deber�an tener permisos de 600. Aunque la mayor�a de los comandos de UUCP tienen que tener el setuid a uucp, tiene que asegurarse de que el programa uuchk no lo es. Si no, los usuarios ser�an capaces de ver las claves aunque tengan modo 600.

El principal fichero de configuraci�n de UUCP es /etc/uucp/config, que se usa para establecer las variables generales. La m�s importante (y por ahora la �nica) es el nombre UUCP de su m�quina. En la Cervera Virtual, usan vstout como su pasarela UUCP:

# /etc/uucp/config - principal fichero de configuraci�n de UUCP nodename vstout

El siguiente fichero de configuraci�n en importancia es el fichero sys. �ste contiene toda la informaci�n espec�fica al sistema de los ordenadores con los que usted se conecta. Esto incluye el nombre del ordenador, e informaci�n sobre la propia conexi�n, tal como el n�mero de tel�fono cuando se usa una conexi�n por m�dem. Un ejemplo t�pico para un ordenador llamado pablo que se conecta por m�dem ser�a:

# /usr/lib/uucp/sys - vecinos UUCP # system: pablo system pablo time Any phone 123--456 port serial1 speed 38400 chat ogin: vstout ssword: lorca

time especifica las horas a las que puede llamarse al sistema remoto. chat describe la macro del di�logo de entrada —la secuencia de caracteres que deben intercambiarse para permitir que uucico entre en pablo. Volveremos a las macros m�s tarde. El elemento port simplemente nombra una entrada en el fichero port. (Acuda a Figura 16-1.) Puede asignar cualquier nombre siempre que haga referencia a una entrada v�lida en port.

El fichero port contiene informaci�n espec�fica a la propia conexi�n. Para conexiones por m�dem, describe el fichero de dispositivo a usar, el conjunto de velocidades soportadas, y el tipo de equipo de marcaci�n conectado al puerto. La entrada a continuaci�n describe /dev/ttyS1 (o sea, el puerto COM 2), en el cual hay un m�dem NakWell conectado que es capaz de funcionar a velocidades de hasta 38400 bps. El nombre de la entrada se puede elegir para que coincida con el nombre usado en el fichero sys.

# /etc/uucp/port - puertos de UUCP # /dev/ttyS1 (COM2) port serial1 type modem device /dev/ttyS1 speed 38400 dialer nakwell

La informaci�n que afecta al propio marcador se mantiene en otro fichero, llamado —lo adivinaste—dial. Para cada tipo de marcador, contiene b�sicamente la secuencia de instrucciones necesarias para llamar a otro ordenador, dado el n�mero de tel�fono. Una vez m�s, esto se especifica como una macro de di�logo. Por ejemplo, la entrada para el anterior NakWell puede parecerse a esta:

# /etc/uucp/dial - informaci�n por marcador # m�dems NakWell dialer nakwell chat "" AT&F OK ATDT\T CONNECT

La l�nea que empieza con chat especifica el di�logo del m�dem, que no es sino la secuencia de �rdenes enviadas y recibidas del m�dem para inicializarlo, y para hacerle marcar el n�mero deseado. La secuencia \T ser� reemplazada con el n�mero de tel�fono por el programa uucico.

Para darle una idea a grandes rasgos de c�mo utiliza uucico estos ficheros de configuraci�n, suponga que utiliza la orden:

$ uucico -s pablo

Lo primero que hace uucico es buscar pablo en el fichero sys. A partir de la entrada en el fichero sys para pablo, el programa averigua que deber�a usar el puerto serial1 para establecer la conexi�n. El fichero port le dice a uucico que se trata de un puerto de m�dem al que hay conectado un m�dem NakWell.

uucico busca ahora en dial la entrada en la que se describe el m�dem NakWell, y al encontrarla, abre el puerto serie /dev/ttyS1 y ejecuta el di�logo de marcaci�n. Es decir, env�a AT&F, espera la respuesta OK, etc. Cuando encuentra la cadena \T, la sustituye por el n�mero (123--456) extra�do del fichero sys.

Cuando el m�dem devuelve CONNECT, la conexi�n se ha establecido y el di�logo de marcaci�n se ha completado. uucico vuelve ahora al fichero sys y ejecuta el di�logo de entrada. En nuestro ejemplo, esperar�a al login:, enviar�a entonces su nombre de usuario (vstout), esperar�a a que se le solicitase el password: y enviar�a la contrase�a (lorca).

Tras completar la autorizaci�n, se supone que el sistema remoto ejecuta su propio uucico. Entran los dos entonces en la fase de negociaci�n descrita en la secci�n previa.

Figura 16-1 ilustra las dependencias entre los ficheros de configuraci�n.

16.2.2. Lo que UUCP necesita saber

Antes de empezar a escribir los ficheros de configuraci�n, debe conseguir cierta informaci�n que UUCP necesita.

Primero, tiene que averiguar a qu� puerto serie est� conectado su m�dem. Normalmente, los puertos (DOS) COM1: a COM4: se corresponden con los ficheros especiales de los dispositivos /dev/ttyS0 a /dev/ttyS3. Algunas distribuciones, como Slackware, crean un enlace llamado /dev/modem apuntando al fichero del dispositivo ttyS* apropiado, y configuran kermit, seyon y cualquier otro programa de comunicaciones para usar este fichero gen�rico. En ese caso, deber�a usar /dev/modem en la configuraci�n de UUCP tambi�n.

La raz�n para esto es que todos los programas, para llamar por tel�fono, usan unos ficheros de bloqueo para indicar cu�ndo un puerto serie est� en uso. Los nombres de estos ficheros cerrojo son una concatenaci�n del texto LCK.. y el nombre del fichero de dispositivo, por ejemplo, LCK..ttyS1. Si los programas usasen nombres diferentes para un mismo dispositivo, no podr�an reconocer los ficheros cerrojo de los otros programas. En consecuencia, perturbar�an la sesi�n de conexi�n de cada uno si se ejecutan a la vez. Esto no es raro que ocurra cuando organiza sus llamadas de UUCP usando una entrada en el fichero crontab. Para m�s detalles sobre la configuraci�n de puertos serie, acuda a Cap�tulo 4.

A continuaci�n tiene que averiguar a qu� velocidad se comunicar�n su m�dem y GNU/Linux. Tendr� que ajustar este valor a la velocidad de transferencia efectiva m�xima que espere obtener. La velocidad efectiva puede ser mucho mayor que la velocidad f�sica de tranferencia de su m�dem. Por ejemplo, muchos modems env�an y reciben datos a 56 kbps. Usando protocolos de compresi�n como V.42bis, la velocidad real de transferencia puede alcanzar los 100 kbps.

Por supuesto, si quiere que UUCP sirva de algo, necesitar� el n�mero de tel�fono al que llamar. Tambi�n necesitar� un nombre de usuario v�lido y probablemente una clave en el sistema remoto.[1]

Tambi�n necesitar� saber exactamente c�mo entrar en el sistema. Por ejemplo, �tiene que pulsar la tecla Enter antes de que aparezca la pregunta de nombre de usuario?. �Muestra el sistema remoto un login: o user?. Esto es necesario para escribir la macro de di�logo, que es un gui�n que le dice a uucico c�mo entrar. Si no lo sabe, o si la macro de di�logo normal no funciona, intente llamar al sistema con un programa como kermit o minicom, y apunte exactamente lo que tiene que hacer.

16.2.3. Nomenclatura de nodos

Al igual que en redes basadas en TCP/IP, todas las m�quinas necesitan tener un nombre para la red de UUCP. Mientras s�lo quiera usar UUCP para transferencia de ficheros desde y hacia ordenadores que usted llama directamente, o en una red local, el nombre no tiene que ajustarse a ninguna regla.[2]

De todas formas, si usa UUCP para una conexi�n de correo o noticias, deber�a pensar en registrar el nombre en el Proyecto de Mapeado UUCP. [3] El Proyecto de Mapeado UUCP se describe en Cap�tulo 17. Incluso aunque forme parte de un dominio, deber�a considerar tener un nombre UUCP oficial para su sitio.

Con frecuencia la gente elige su nombre UUCP de forma que coincida con el primer elemento de su nombre de dominio completamente cualificado. Suponga que la direcci�n de su dominio es swim.twobirds.com; entonces el nombre de su nodo UUCP ser�a swim. Piense en los nodos UUCP como si s�lo se conociesen entre ellos por sus respectivos nombres propios. Por supuesto, tambi�n puede usar un nombre UUCP que no tenga nada que ver con su nombre de dominio completamente cualificado.

No obstante, aseg�rese de no emplear un nombre de sitio no cualificado en direcciones de correo a menos que lo haya registrado como su nombre UUCP oficial. En el mejor de los casos, el correo a una m�quina UUCP no registrada se perder� en alg�n enorme agujero negro digital. Si emplea un nombre que alguien ya est� usando, el correo se dirigir� a ese lugar causando al administrador del correo de ese lugar un sinf�n de dolores de cabeza.

De manera predeterminada, UUCP usa el nombre especificado como hostname como el nombre UUCP del sitio. Este nombre suele adjudicarlo una orden en los guiones rc durante el arranque del sistema, y se suele guardar en /etc/hostname. Si su nombre UUCP difiere del de su m�quina, tendr� que usar la opci�n hostname en el fichero config para comunicarle a uucico su nombre UUCP. Esto se describe m�s tarde.

16.2.4. Ficheros de configuraci�n de Taylor

Volvemos ahora a los ficheros de configuraci�n. Taylor UUCP obtiene su informaci�n de los siguientes ficheros:

Los ficheros de configuraci�n de Taylor se componen generalmente de l�neas que contienen pares clave-valor. Una almohadilla inicia un comentario que se extiende hasta el final de la l�nea. Para emplear el signo de la almohadilla como tal, esc�pelo con una barra invertida de esta manera: \#.

Hay unas cuantas opciones que puede ajustar con estos ficheros de configuraci�n. No podemos repasar todos los par�metros, sino que cubriremos s�lo los m�s importantes. Con �stos usted podr� configurar una conexi�n de UUCP por m�dem. Otras secciones describir�n las modificaciones necesarias si quiere usar UUCP en TCP/IP o sobre una l�nea serie. Junto con el c�digo fuente de Taylor UUCP se incluye una referencia de �rdenes completa en los documentos Texinfo.

Cuando crea haber configurado su sistema UUCP completamente, puede compobar su configuraci�n con la herramienta uuchk (que puede encontrar en /usr/lib/uucp). uuchk lee sus ficheros de configuraci�n y le muestra un informe detallado de los valores de configuraci�n usados para cada sistema.

16.2.5. Opciones generales de configuraci�n usando el fichero config

Normalmente no usar� este fichero para otra cosa que especificar el nombre de su nodo UUCP. De manera predeterminada, UUCP usar� el nombre que haya establecido con la orden hostname, pero por lo general resulta una buena idea especificar el nombre UUCP expl�citamente. He aqu� un fichero config de ejemplo:

# /usr/lib/uucp/config - principal fichero de configuraci�n UUCP hostname vstout

Por supuesto, tambi�n existen otros par�metros configurables aqu�, como los referentes al nombre del directorio de colas, o los nombres de acceso para el UUCP an�nimo. Esto �ltimo se describir� posteriormente en este cap�tulo, en la secci�n “UUCP an�nimo.”

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

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

16.2.8. 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]

16.2.9. UUCP sobre TCP

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.

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