16.1. Transferencias UUCP y ejecución remota

El concepto de tarea resulta vital para entender UUCP. Cada transferencia que inicia un usuario con uucp o uux se llama tarea. Consta de una orden a ejecutar en un sistema remoto, una recopilación de ficheros a transferir entre sitios o ambas cosas.

Por ejemplo, la siguiente orden hace que UUCP copie el fichero netguide.ps a un sistema remoto llamado pablo y ejecute la orden lpr en pablo para imprimir el fichero:

    $ uux -r pablo!lpr !netguide.ps

Por lo general, UUCP no llama al sistema remoto de inmediato para llevar a cabo una tarea (o cualquier otra cosa que pueda hacer con kermit). En cambio, guarda la descripción de la tarea de manera temporal. Esto se conoce como encolar. El árbol de directorios bajo el que se guardan las tareas se llama por lo tanto directorio de cola y se encuentra generalmente en /var/spool/uucp. En nuestro ejemplo, la descripción de la tarea contendría información sobre la orden remota a ejecutar (lpr), el usuario que ordenó la ejecución y un par de elementos más. Además de la descripción de la tarea, UUCP tiene que guardar el fichero de entrada netguide.ps.

La localización y nomenclatura exactas de los ficheros de cola puede varias dependiendo de algunas opciones en tiempo de compilación. Los UUCPs compatibles con HDB guardan por lo general los ficheros de cola en el subdirectorio /var/spool/uucp con el nombre del sistema remoto. Cuando se compilan para la configuración Taylor, UUCP crea subdirectorios bajo el directorio de cola específico del sitio para diferentes tipos de ficheros de cola.

A intervalos regulares, UUCP llama al sistema remoto. Cuando se establece una conexión con el sistema remoto, UUCP transfiere los ficheros en los que se describe la tarea, además de los ficheros de entrada. Las tareas entrantes no se ejecutarán de inmediato, sino sólo tras haber terminado la conexión. La ejecución la gestion uuxqt, quien también se ocupa de redirigir cualquier tarea designada a otro sitio.

Para distinguir entre tareas más o menos importantes, UUCP asocia un nivel a cada tarea. Se trata de un único dígito de 0 a 9, de A a Z, y de a a z, en precedencia decreciente. El correo se suele colocar en la cola con nivel B o C, mientras que las noticias se colocan con un nivel N. Las tareas con niveles más altos se transfieren antes. Los niveles pueden asignarse por medio de la opción –g al invocar a uucp o uux.

También se puede prohibir la transferencia de trabajos bajo un cierto nivel a horas determinadas. Esto también se llama máximo nivel de cola permitido durante una conversación y el valor predeterminado es z. Percátese de la ambigüedad de esta terminología: un fichero se transfiere sólo si es igual o mayor que el máximo nivel de cola.

16.1.1. El funcionamiento interno de uucico

Para comprender por qué uucico necesita saber ciertas cosas, una rápida descripción de cómo se conecta realmente a un sistema remoto resultará de ayuda.

Cuando usted ejecuta uucico -s sistema desde la línea de órdenes, primero tiene que conectarse físicamente. Las acciones a tomar dependen del tipo de conexión a usar. Por ejemplo, cuando se usa una línea telefónica, tiene que encontrar un módem, y marcar un número de teléfono. Sobre TCP, tiene que llamar gethostbyname(3) para convertir el nombre a una dirección de red, averiguar qué puerto abrir, y conectar la dirección al puerto correspondiente.

Una vez que se ha establecido la conexión, hay que pasar un proceso de autorización. Normalmente consiste en que el sistema remoto pide un nombre de usuario y posiblemente una clave. Esto se llama el diálogo de entrada. El proceso de autorización se lleva a cabo mediante el usual getty/login, o en conexiones TCP por el propio uucico. Si la autorización es permitida, la parte remota de la conexión ejecuta uucico. La copia local de uucico que inició la conexión se denomina maestro, y la copia remota se denomina esclavo.

Ahora viene la fase de handshake : El maestro envía su nombre, además de varias opciones. El esclavo comprueba el nombre para ver si tiene permiso para conectarse, para enviar y recibir ficheros, etc. Las opciones describen (entre otras cosas) el nivel máximo de ficheros de cola que hay que transferir. Si esta opción está activada, tiene lugar una cuenta de conversación, o comprobación de la secuencia de llamada. Con esta característica, ambos ordenadores mantienen una cuenta de conexiones exitosas, que se comparan. Si las cuentas no son iguales, la negociación de protocolos no tendrá lugar. Esto es útil para protegerse de impostores.

Finalmente los dos uucico tratan de ponerse de acuerdo en un protocolo de transferencia común. Este protocolo gobierna la manera en que los datos se transfieren, la manera en que se comprueba la consistencia de los datos, y la manera en que se retransmiten en caso de error. Hacen falta protocolos diferentes debido a los diferentes tipos de conexiones que se soportan. Por ejemplo, las líneas de teléfono precisan un protocolo “seguro” que es pesimista respecto a errores, mientras que una transmisión de TCP es fiable y puede usar un protocolo más eficiente que carece de la mayoría de las comprobaciones de errores.

Una vez que las negociaciones se han completado, comienza la fase de la verdadera transmisión. Ambos extremos ponen en funcionamiento el controlador del protocolo elegido. Los controladores posiblemente lleven a cabo alguna secuencia específica del protocolo para la inicialización.

Primero el maestro envía todos los ficheros en la cola de este sistema remoto cuyo nivel de cola es suficientemente alto. Cuando ha finalizado, informa al esclavo que ha terminado, y que el esclavo puede ahora colgar. El esclavo puede entonces colgar, o tomar el control de la conversación. Esto es un cambio de papeles: ahora el sistema remoto se convierte en maestro y el local en esclavo. El nuevo maestro envía ahora sus ficheros. Cuando ha terminado, ambos uucico s intercambian mensajes de terminación, y cierran la comunicación.

Si necesita información adicional sobre UUCP acuda al código fuente. También hay un artículo bastante antiguo escrito por David A. Novitz pululando por la red en el que se proporciona una descripción detallada del protocolo UUCP. [1] En las PUF sobre Taylor UUCP también se discuten algunos detalles de la implementación de UUCP. Se envía a comp.mail.uucp con relativa frecuencia.

16.1.2. Opciones en la línea de órdenes para uucico

En esta sección describimos las opciones de la línea de órdenes más importantes para uucico :

– – system, –s sistema

Llama al sistema si no está prohibido por restricciones en la hora de llamada.

–S sistema

Llama al sistema sin condiciones.

– –master, –r1

Inicia uucico en modo maestro. Éste es el modo predeterminado cuando se indica –s o –S. Por sí misma, la opción –r1 provoca que uucico intente llamar a todos los sistemas en el fichero sys que se describe en la siguiente sección de este capítulo, a no ser que sea prohibido por las restricciones de la hora de llamada o las veces que se puede reintentar la misma.

– –slave, –r0

Inicia uucico en modo esclavo. Éste es el modo predeterminado cuando no se indica –s ni –S. En modo esclavo, tanto la entrada como la salida estándar se asume que están conectadas a un puerto serie, o al puerto TCP especificado por la opción –p si se usa.

– –ifwork, –C

La opción suplementa –s o –S y comunica a uucico que llame al sistema mencionado sólo si hay tareas en la cola para él.

– –debug tipo, –x tipo, –X tipo

Activa la depuración del tipo especificado. Pueden proporcionarse muchos tipos en forma de lista separada por comas. Los siguientes tipos son válidos. abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming, y outgoing. Si usa all activará todas las opciones. Por compatibilidad con otras implementaciones de UUCP, también puede especificar un número, que activará la depuración para los primeros n elementos de la lista anterior.

Los mensajes de depuración se registrarán en el fichero Debug bajo /var/spool/uucp.

Notas

[1]

También se incluye en el Manual del Administrador de Sistemas 4.4BSD.