| Gu�a de Administraci�n de Redes con Linux | ||
|---|---|---|
| Anterior | Cap�tulo 16. Administraci�n deTaylor UUCP | Siguiente |
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.
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.
En esta secci�n describimos las opciones de la l�nea de �rdenes m�s importantes para uucico :
Llama al sistema si no est� prohibido por restricciones en la hora de llamada.
Llama al sistema sin condiciones.
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.
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.
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.
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.
| [1] | Tambi�n se incluye en el Manual del Administrador de Sistemas 4.4BSD. |