UUCP fue diseñado a finales de los años setenta por Mike Lesk en los laboratorios Bell de AT&T con el objetivo de crear una simple red sobre líneas de teléfonos para conectarse mediante llamadas telefónicas. Dado que la mayoría de la gente que quiere tener correo electrónico y noticias de Usenet en sus ordenadores personales todavía se comunican por módem, UUCP ha seguido siendo muy popular. Aunque hay muchas implementaciones funcionando en una gran variedad de plataformas y sistemas operativos, todas son bastante compatibles.

Sin embargo, como con cualquier programa que se ha convertido en "estándar" con el tiempo, no hay un UUCP que se pueda denominar el UUCP. Ha sufrido un continuo proceso de evolución desde la primera versión que fue implementada en 1976. En la actualidad hay dos especies principales que se diferencian principalmente en su soporte del hardware y en su configuración. A su vez, hay varias implementaciones de estas dos clases, todas con ligeras diferencias respecto a sus familiares.

Una de las clases es la llamada "UUCP Version 2", que es una implementación de 1977 de Mike Lesk, David A. Novitz, y Greg Chesson. Aunque es bastante antigua, todavía se usa frecuentemente. Las implementaciones mas recientes de la Version 2 ofrecen muchas de las características de los tipos mas nuevos de UUCP.

La segunda clase de UUCP se desarrolló en 1983, y se conoce comúnmente como BNU (Utilidades Básicas de Red)1, HoneyDanBer UUCP, o HDB abreviado. El nombre fue derivado de los nombres de los autores, P. Honeyman, D. A. Novitz, y B. E. Redman. HDB fue creado para eliminar algunas deficiencias de la Version 2. Por ejemplo, se añadieron nuevos protocolos de transferencia, y el directorio de cola fue dividido de manera que ahora solo haya un directorio para cada ordenador con el que mantenga tráfico de UUCP.

_____________________________________________
1 N. del T.: BNU son las siglas de Basic Network Utilities.

La implementación de UUCP que se distribuye con Linux es Taylor UUCP 1.04,2 que es la versión en la que se basa este capítulo. La versión 1.04 de Taylor UUCP esta disponible desde Febrero de 1993. Además de los tradicionales ficheros de configuración, Taylor UUCP también se puede compilar para que use ficheros de configuración de un nuevo estilo: el estilo "Taylor".

La versión 1.05 ha aparecido recientemente, y pronto se incluirá en la mayoría de las distribuciones. Las diferencias entre estas versiones afectan en su mayor parte a aspectos que usted nunca usara, así que con lo poco que contamos aquí le debería bastar para configurar Taylor UUCP 1.05 en su sistema.

Tal y como se incluye en la mayoría de las distribuciones de Linux, el Taylor UUCP viene compilado para ser compatible con BNU, con el estilo de configuración de Taylor, o ambos.

Dado que el segundo es mucho más flexible, y probablemente más fácil de entender que los usualmente oscuros ficheros de configuración de BNU, describiré aquí el estilo Taylor.

El propósito de este capítulo no es ofrecer una explicación exhaustiva de las opciones de la línea de comando para los comandos de UUCP y lo que hacen, sino darle una introducción sobre como poner en marcha un nodo de UUCP. La primera sección presenta una introducción de como UUCP implementa ejecución remota y transmisión de ficheros. Si usted tiene ya algunos conocimientos de UUCP, quizá desee saltarse esto y continuar con la sección "Ficheros de configuración de UUCP", que explica los distintos ficheros usados para configurar UUCP.

Sin embargo, asumiremos que usted está familiarizado con los programas de usuario del paquete UUCP. Estos son uucp y uux. Si no los conoce suficientemente, consulte las correspondientes páginas de manual.

Aparte de los programas de usuario, uux y uucp, el paquete UUCP contiene algunos comandos más, usados solamente para fines administrativos. Se usan para observar el tráfico de UUCP en su nodo, deshacerse de viejos ficheros de registro, o crear estadísticas.

No describiremos ninguna de estas utilidades, porque son periféricas a las tareas principales de UUCP. Dichas utilidades están bien documentadas y son bastante fáciles de entender. Sin embargo, hay una tercera categoría, que forma los "motores" del UUCP. Estas son uucico (donde "cico" significa "copy-in copy-out"), y uuxqt, que ejecuta trabajos enviados desde sistemas remotos.

_____________________________________________
2 Escrito por Ian Taylor en 1993.

Aquellos que no encuentren todo lo que necesiten en este capítulo pueden leer la documentación que viene con el paquete. Viene en un grupo de ficheros de texinfo que describen la configuración usando el estilo de configuración de Taylor. Los ficheros texinfo se pueden convertir a DVI y a ficheros "GNU info" usando tex y makeinfo respectivamente.

Si quiere usar ficheros de configuración de BNU o incluso de la Version 2 (!), existe un libro muy recomendable, "Managing UUCP and Usenet" ([OReilly89]). Es muy útil. Otra buena fuente de información sobre UUCP en Linux es el UUCP-HOWTO de Vince Skahan, que aparece regularmente en comp.os.linux.announce.

También hay un grupo de noticias sobre UUCP, llamado comp.mail.uucp. Si usted tiene preguntas especificas sobre Taylor UUCP, puede que sea mejor que las pregunte en ese grupo, en vez de en los grupos comp.os.linux.

El concepto de trabajos es vital para entender el UUCP. Cada transferencia que un usuario inicia con uucp o uux se denomina un trabajo. Se compone de un comando para ser ejecutado en un sistema remoto, y una colección de ficheros para ser transferidos entre redes. Una de estas partes puede faltar.

Por ejemplo, el siguiente comando describe un trabajo UUCP, que conlleva copiar el fichero netguide.ps en el ordenador pablo, y ejecutar luego el comando lpr para imprimir el fichero.

Generalmente UUCP no llama al sistema remoto inmediatamente para ejecutar el trabajo (se puede hacer con kermit). En lugar de esto, UUCP guarda la descripción del trabajo temporalmente. Esto se denomina spooling.3 El árbol de directorios en el que se almacenan los trabajos se llama directorio de cola, y se encuentra normalmente en /var/spool/uucp.

En nuestro ejemplo, la descripción del trabajo contendría información sobre el comando remoto que hay que ejecutar (lpr ), el usuario que ha iniciado la ejecución, y otro par de cosas. Además de la descripción del trabajo, UUCP tiene que guardar el fichero de datos netguide.ps.

_____________________________________________
3 N. del T.: spooling puede traducirse por "poner en una cola". Spooling se refiere a la acción de poner varios trabajos en una cola para ser usados mas tarde.

La localización exacta y la nomenclatura de los ficheros de cola puede variar, dependiendo de las opciones de compilación. Los UUCPs que son compatibles con HDB generalmente guardan los ficheros de cola en un directorio llamado /var/spool/uucp/maquina, donde maquina es el nombre del ordenador remoto. Si fue compilado para usar ficheros de configuración de Taylor, UUCP crea subdirectorios bajo el directorio de cola especifico a un ordenador para diferentes tipos de ficheros de cola.

En intervalos regulares UUCP se conecta al sistema remoto. Cuando se ha establecido una conexión, UUCP transfiere los ficheros que describen el trabajo, junto con los ficheros de datos. Los trabajos que entran en el ordenador remoto no se ejecutan de inmediato, sino después de que la conexión haya finalizado. Esto lo hace uuxqt, que también se ocupa de reenviar cualquier trabajo que este designado para otro ordenador diferente.

Para diferenciar trabajos importantes y trabajos menos importantes, UUCP asocia un nivel a cada trabajo. El nivel es una sola letra o dígito, de 0 a 9, de A a Z y de a a z, con precedencia decreciente. El correo se suele poner en cola con nivel B o C, mientras que las noticias se suelen poner con nivel N. Los trabajos con un nivel mas alto se transfieren mas pronto. Los niveles pueden ser asignados usando la opción -q cuando se ejecuta 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 por defecto es z. Percátese de la ambigüedad de esta terminología: un fichero se transfiere solo si es igual o mayor que el máximo nivel de cola.

3 Para comprender por que uucico necesita saber ciertas cosas, hemos de revisar como se conecta a un sistema remoto.

Cuando usted ejecuta uucico -s sistema desde la línea de comandos, 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 que 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 inicio la conexión se denomina maestro, y la copia remota se denomina esclavo.

A continuación viene la fase de negociacion4: 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 esta 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 mas 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 especifica 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 uucicos intercambian mensajes de terminación, y cierran la comunicación.

No vamos a profundizar en mas detalle: para esto, diríjase a las fuentes o a cualquier buen libro sobre UUCP. También existe un articulo muy antiguo en la red, escrito por David A. Novitz, que da una descripción detallada del protocolo UUCP. La FAQ5 de Taylor UUCP también trata algunos detalles de como UUCP esta implementado. Se puede encontrar regularmente en comp.mail.uucp.

_____________________________________________
4 N. del. T.: Literalmente, del ingles handshake o "apretón de manos". En este contexto significa "negociación de protocolos", fase en la que los programas uucico de cada extremo de comunicación deciden que protocolo común usar para enviar los ficheros.
5 N. del T.: Del ingles Frecuently Asked Questions o Lista de Preguntas Comunes.

En esta sección de describen las opciones mas importantes de la línea de comandos del programa uucico. Para obtener una lista completa, consulte la página del manual de uucico(1).

Al contrario que programas de transferencia de ficheros mas simples, UUCP fue diseñado para ser capaz de llevar a cabo todas las transferencias automáticamente. Una vez que esta correctamente configurado, no es necesaria una constante participación del administrador. La información necesaria para esto se guarda en un par de ficheros de configuración que residen en el directorio /usr/lib/uucp. La mayoría de estos ficheros se usan solo para conectarse a otro ordenador.

Decir que la configuración de UUCP es difícil seria 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 mas fáciles (aunque el formato de Taylor es casi fácil de leer comparado con los formatos mas antiguos en HDB o Version 2).

Para darle una idea de como se interactúa con estos ficheros, le introduciremos los mas importantes, y echaremos un vistazo a algunos ejemplos. No explicaremos ahora todo en detalle; una explicación mas 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 /usr/lib/uucp o un subdirectorio de éste. Algunas distribuciones de Linux contienen programas de UUCP que tienen soporte para ambos ficheros de HDB y Taylor, y usan diferentes subdirectorios para cada grupo de ficheros de configuración. Normalmente hay 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.6

El fichero central de configuración es /usr/lib/uucp/config, y se usa para establecer los parámetros generales. El mas importante de ellos (y por ahora, el único), es el nombre de su ordenador anfitrión de UUCP. En la Cervecera Virtual, se usa vstout como su ordenador de conexión a UUCP.

El siguiente fichero de configuración en importancia es el fichero sys. Este contiene toda la información especifica 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 seria:

_____________________________________________
6 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 serian capaces de ver las claves aunque tengan modo 600.

port especifica el puerto a usar, y time especifica las horas a las que se puede llamar a ese ordenador. chat describe la macro del diálogo de entrada - la secuencia de caracteres que hay que intercambiar para permitir a uucico que conecte con pablo. Volveremos a las macros mas tarde. El comando port no usa un nombre de fichero de un dispositivo como /dev/cua1, sino que usa el nombre de una entrada en el fichero port. Se pueden asignar estos nombres como se desee siempre y cuando hagan referencia a una entrada válida en port.

El fichero port contiene información especifica 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/cua1 (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.

La información que afecta al propio marcador se mantiene en otro fichero, llamado dial. Para cada tipo de marcador, contiene básicamente la secuencia de comandos necesarios para llamar a otro ordenador, dado el número de teléfono. Una vez mas, esto se especifica como una macro de diálogo. Por ejemplo, la entrada para el anterior NakWell puede parecerse a esta:

La línea que empieza con chat especifica el diálogo del módem, que no es sino la secuencia de comandos enviados y recibidos 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.

Figura 12.1: Interacciones de los Ficheros de Configuración de Taylor UUCP.

Para darle una idea a grandes rasgos de como uucico utiliza estos ficheros de configuración, suponga que utiliza el comando

en la línea de comandos. Lo primero que uucico hace es buscar pablo en el fichero sys. A partir de la entrada en el fichero sys para pablo, el programa ve que debería usar el puerto serial1 para establecer la conexión. El fichero port le dice que ese puerto es un puerto de módem, y que tiene un módem NakWell conectado.

uucico busca ahora en dial la entrada que describe el módem NakWell, y al encontrar una, abre el puerto serie /dev/cua1 y ejecuta el diálogo de marcación. Esto es, envía "ATZ", espera a que el módem responda con "OK", etc. Cuando se encuentre los caracteres "\T ", sustituye el número de teléfono (123-456) obtenido 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 ahora vuelve al fichero sys y ejecuta el diálogo de entrada. En nuestro ejemplo, esperaría la pregunta "login:", enviaría su nombre de usuario (neruda), esperaría la pregunta "password:", y enviaría la clave, "lorca".

Tras completar la autorización, se supone que el sistema remoto ejecuta su propio uucico. Los dos entrarán entonces en la fase de negociación de protocolos descrita en la sección anterior.

La relación de dependencia de los ficheros de configuración se puede ver en la figura 12.1.

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

Primero tiene que saber en que dispositivo serie esta su módem. Normalmente, los puertos (de DOS) COM1 hasta COM4 se corresponden con los ficheros de dispositivos /dev/cua0 hasta /dev/cua3. La mayoría de las distribuciones, como Slackware, crean un enlace simbólico /dev/modem al fichero de dispositivo donde está el módem, y configuran kermit, seyon, etc, para que usen este fichero. En este caso, usted también debería usar /dev/modem en la configuración de UUCP.

La razón para esto es que todos los programas, para llamar por teléfono, usan unos ficheros cerrojo para indicar cuando un puerto serie esta 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..cua1. 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 obtener mas detalles sobre como configurar sus puertos serie, lea el capítulo 4.

A continuación tiene que averiguar a que velocidad se comunicaran su módem y 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 transferencia de su módem. Por ejemplo, muchos módems envían y reciben datos a 2400bps (bits por segundo). Usando protocolos de compresión como V.42bis, la velocidad real de transferencia puede alcanzar los 9600bps.

Por supuesto, si quiere que UUCP sirva de algo, necesitara el número de teléfono al que llamar. También necesitara un nombre de usuario valido y probablemente una clave en el sistema remoto.7

_____________________________________________
7 Si solo 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.

También necesitara saber exactamente como entrar en el sistema. Por ejemplo, ¿tiene que pulsar la tecla BREAK 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 script que le dice a uucico como 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.

Al igual que en redes basadas en TCP/IP, todas las maquinas necesitan tener un nombre para la red de UUCP. Mientras solo quiera usar UUCP para transferencia de ficheros desde y a ordenadores que usted llama directamente, o en una red local, el nombre no tiene que ajustarse a ninguna regla.8

Sin embargo, si usa UUCP para tener una conexión a correo y noticias, se debería pensar en registrar el nombre con el proyecto de Mapa de UUCP, que se describe en el capítulo 13.

Incluso si usted participa en un dominio, podría considerar el tener un nombre oficial de UUCP para su ordenador.

Frecuentemente la gente elige su nombre de UUCP para que corresponda con el primer componente de su nombre de dominio completamente cualificado. Suponga que la dirección de su dominio es swim.twobirds.com, entonces su nombre de UUCP podría ser swim.

Piense en los nodos de UUCP como si se conociesen entre ellos por el nombre propio. Por supuesto, también puede usar un nombre de UUCP completamente desvinculado de su nombre de dominio, y por consiguiente, un nombre no cualificado.

Sin embargo, asegúrese de no usar el nombre no cualificado en direcciones de correo a no ser que lo haya registrado como su nombre de UUCP oficial.9 Lo mejor que puede pasar es que el correo dirigido a un nombre de UUCP no registrado se pierda en algún agujero negro digital. Si utiliza un nombre que alguien ya esta usando, este correo será dirigido a ese sitio, y le causara al administrador del correo un sinfín de dolores de cabeza.

Los programas de UUCP usan el nombre devuelto por hostname como el nombre de UUCP por defecto. Este nombre se encuentra normalmente en la macro /etc/rc.local. Si su nombre de UUCP es diferente del que le dio a su ordenador, tiene que usar la opción hostname en el fichero config para indicar a uucico su nombre de UUCP. Esto se describe a continuación.

_____________________________________________
8 La única limitación es que no puede ser mas largo que 7 caracteres, para no confundir a algunos nodos con sistemas de ficheros que imponen un estrecho limite en los nombres de ficheros.
9 El Proyecto de Mapa de UUCP registra todos los nodos de UUCP de todo el mundo y comprueba que sean únicos. Para registrar su nombre de UUCP, pregúntele a los responsables del nodo que gestiona su correo; ellos podrán ayudarle.

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

config
Este es el fichero principal de configuración. Aquí puede definir el nombre de UUCP de su ordenador.

sys
Este fichero describe todos los nodos conocidos por el sistema. Por cada nodo, especifica su nombre, a que horas llamarlo, que número marcar, que tipo de dispositivo usar, y como entrar.

port
Contiene entradas que describen cada puerto disponible, junto con la velocidad de línea soportada y las instrucciones de marcación.

dial
Describe las instrucciones de marcación usados para establecer una conexión telefónica.

dialcode
Contiene expansiones simbólicas para códigos de marcación.

call
Contiene el nombre de usuario y la clave a usar cuando llame a un sistema. No se suele usar.

passwd
Contiene nombres de usuario y claves que los sistemas pueden usar cuando entren en su ordenador. Este fichero se usa solo cuando uucico hace su propia comprobación de claves.

Los ficheros de configuración de Taylor se componen generalmente de líneas que contienen pares palabra - valor. Una almohadilla (#) indica un comentario que ocupa toda una línea. Para usar una almohadilla por si misma, puede poner una barra invertida delante de la almohadilla.

Hay unas cuantas opciones que puede ajustar con estos ficheros de configuración. No podemos repasar todos los parámetros, sino que cubriremos solo los mas importantes. Con estos 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 comandos completa en los documentos Texinfo.

Cuando crea que ha configurado su sistema de UUCP completamente, puede comprobarlo usando la utilidad uuchk (que se encuentra en /usr/lib/uucp). uuchk lee sus ficheros de configuración, e imprime un informe detallado de los valores de configuración usados para cada sistema.

Normalmente no usara este fichero para otra cosa que describir su nombre de nodo UUCP. Por defecto, UUCP usara el nombre establecido con el comando hostname, pero generalmente es una buena idea configurar el nombre de UUCP explícitamente. A continuación mostramos un fichero de ejemplo:

Por supuesto, también existen otros parámetros configurables aquí, como los referentes al nombre del directorio de colas, o los derechos de acceso para el UUCP anónimo. Esto ultimo se describirá en una sección posterior.

El fichero sys describe los sistemas que su ordenador conoce. Una entrada comienza con la palabra system; las líneas siguientes hasta la siguiente system proporcionan detalles sobre los parámetros específicos sobre ese sistema o nodo. Comúnmente, una entrada de un sistema definirá parámetros tales como el número de teléfono y el diálogo de entrada.

Los parámetros antes de la primera línea con system determinan los valores por defecto usados para todos los sistemas. Lo normal es que los parámetros de protocolos y similares se incluyan en la sección por defecto.

A continuación se tratan los campos más importantes con cierto detalle.

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 alternavias, que se describen mas adelante.

_____________________________________________
10 Algunas de las versiones 2 de UUCP antiguas no envían su nombre cuando son llamadas; sin embargo, las implementaciones mas recientes si lo hacen, y Taylor UUCP también.

Cualquier lista de caracteres se puede usar para esconder información que depende de cada nodo, como el prefijo de provincia. Estos caracteres se traducen en un código de marcación usando el fichero dialcode. Suponga que tiene el siguiente fichero dialcode:

Con estas traducciones, se puede usar un número de teléfono como Bogoham7732 en el fichero sys, lo cual hace las cosas un poco mas legibles.

Normalmente es suficiente con usar la opción speed. Si solo tiene un dispositivo serie definido en port, uucico, de cualquier modo, siempre escogerá el correcto, así que solo tiene que especificar la velocidad deseada. Si tiene varios módems conectados a su sistema, tampoco es una buena idea nombrar un puerto en particular, porque si uucico encuentra que hay varios puertos con el mismo nombre, trata de usarlos todos hasta que encuentra uno que no esta en uso.

_____________________________________________
11 La velocidad en baudios del terminal (tty) tiene que ser por lo menos igual o mayor que la velocidad máxima de transmisión.

Dése cuenta de que los campos de texto de espera (ogin: y ssword:) no contienen 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:.

uucico también permite usar estructuras condicionales, por ejemplo en el caso de que el programa getty de la maquina 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 solo si el primer texto de espera falla, ej. si expira un temporizador (timeout). 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 return antes de que aparezca la pregunta de entrada.

Hay un par de tiras 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 tira vacía. Le dice a uucico que no espere nada, sino que siga con la siguiente tira de enviado inmediatamente.

\t Un carácter de tabulador.

\r Un carácter de retorno de línea.

\s El carácter de espacio. Lo necesitamos para incluir espacios en un diálogo.

\n Carácter de nueva línea.

\\ Carácter de barra invertida.

En tiras de caracteres de envío se pueden incluir, además de los mencionados anteriormente, los siguientes caracteres:

EOT Carácter de fin de la transmisión (^D).

BREAK Carácter Break.

\c Suprime el envío del carácter nueva línea al final de cada tira de caracteres.

\d Retrasar el envío 1 segundo.

\E Activar 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 módems (que veremos mas adelante). La comprobación de eco esta desactivada por defecto.

\e Desactivar la comprobación de eco.

\K Lo mismo que BREAK.

\p Pausa de una fracción de un segundo.

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 esta separada de la entrada principal por una línea que contiene la palabra clave alternate.

Para usar dos números de teléfono para pablo, habría que modificar su entrada sys de la siguiente manera:

Ahora, cuando llame a pablo, el programa uucico marcara primero el 123-456, y si no funciona, probara la alternativa. La entrada alternativa retiene toda la otra información de la entrada de sistema principal, y altera solo el número de teléfono.

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 seria por las limitaciones que el sistema remoto impone en sus servicios durante horas de oficina, o simplemente para evitar las horas mas 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 mas sencilla de restringir horas de llamada es con la entrada time, seguida de una tira de caracteres que consta de dos campos, día y hora. El día puede ser cualquiera de los siguientes: Mo, Tu, We, Th, Fr, Sa, Su (que corresponden a Lunes, Martes, Miércoles, Jueves, Viernes, Sábado y Domingo, respectivamente) combinados, Any (cualquiera), Never (nunca), o Wk para los días laborables. La hora consiste en dos números de un reloj de 24 horas, separados por un guión. Especifican el grupo de horas durante las que se pueden efectuar llamadas. La combinación de los símbolos se escribe sin ningún espacio en blanco entre ellos. Se pueden especificar varios grupos de dia-hora separados por comas. Por ejemplo,

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

El comando time tiene un segundo argumento 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. Por defecto, 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 aceptara llamar otra vez en los 5 minutos después del último intento fallido.

El comando timegrade le permite añadir un rango máximo de cola a un calendario. Por ejemplo, asumiendo que usted tiene los siguientes comandos timegrade en una entrada system:

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 (news) (normalmente con rango N) serán transferidas solo durante la noche y los fines de semana.

Al igual que time, el comando timegrade acepta un intervalo de reintento en minutos como un tercer argumento opcional.

Sin embargo, hay que hacer una observación: la opción timegrade solo se aplica a lo que su sistema envía; el sistema remoto puede transferir todo lo que le plazca. Usted puede usar la opción call-timegrade para forzar explícitamente que envíe solamente trabajos sobre cierto rango de cola; pero no hay ninguna garantía de que obedecerá esta peticion.12

Igualmente, el campo timegrade no se comprueba cuando un sistema remoto hace una llamada a éste, de manera que cualquier trabajo puesto en la cola para el sistema que llama al nuestro será enviado. Sin embargo, el sistema remoto puede pedir explícitamente a nuestro uucico que se mantenga a si mismo en un cierto rango de cola.

El fichero port indica a uucico que puertos tiene disponibles. Pueden ser puertos de módem, pero cualquier otro tipo, como líneas serie directas o sockets de TCP también se pueden usar.

Al igual que el fichero sys, el fichero port consta de entradas separadas que empiezan con la palabra port, seguida del nombre del puerto. Este nombre puede ser usado por la palabra port en el fichero sys. El nombre no tiene por que ser único; si hay varios puertos con el mismo nombre, uucico intentara cada uno de los puertos hasta que encuentre uno que no esta siendo utilizado.

El comando port tiene que estar seguido por el comando type que especifica que tipo de puerto se esta describiendo. Tipos validos son módem, direct para comunicaciones directas, y tcp para sockets de TCP. Por defecto, cuando el comando port no se incluye en el fichero, el tipo de puerto asumido será módem.

En esta sección solo hablaremos de puertos de módem; los puertos de TCP y las líneas directas serán tratados en una sección posterior.

_____________________________________________
12 Si el sistema remoto esta ejecutando Taylor UUCP, obedecerá.

Para puertos directos y de módem, tiene que especificar el dispositivo para llamar usando la directiva device. Usualmente es el nombre de un fichero de dispositivo en el directorio /dev, como por ejemplo /dev/cua1.13

En el caso de un dispositivo de módem, la directiva port también determina que tipo de módem esta conectado al puerto. Cada tipo de módem tiene que configurarse de manera diferente. Incluso los módems que dicen ser compatibles con Hayes no tienen por que ser realmente compatibles entre si mismos. Por lo tanto, tiene que decirle a uucico como inicializar el módem y como hacer que marque 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 usando el comando dialer.

Es posible que usted quiera usar el módem de maneras diferentes, dependiendo del sistema al que esta llamando. Por ejemplo, algunos módems antiguos no entienden cuando un módem rápido trata de conectar a 14400bps; simplemente desconectan la línea en vez de negociar la conexión a 9600bps por ejemplo. Si sabe que el ordenador plasta usa un módem tan tonto, usted tiene que configurar su módem de manera diferente cuando llame a ese ordenador. Para hacer esto, necesita una entrada adicional del comando port en el fichero port que especifica un marcador diferente. Ahora puede dar un nombre diferente al nuevo puerto, como por ejemplo serial1-lento, y usar la directiva port en la entrada del sistema plasta en el fichero sys.

Otra manera de distinguir los puertos es por la velocidad que usan. Por ejemplo, las dos entradas port de la situación anterior pueden ser así:

La entrada de sistema para el ordenador plasta usaría ahora serial1 como el nombre del puerto, pero pediría usar la velocidad de 9600bps solamente. uucico usara automáticamente la segunda entrada de port. Todos los otros ordenadores con velocidad de 38400bps en la entrada de sistema serán llamados usando la primera entrada de port.

_____________________________________________
13 Hay quien usa los dispositivos ttyS*, que son solamente para aceptar llamadas.

El fichero dial describe como se usan los distintos marcadores. Tradicionalmente, UUCP habla de "marcadores" en vez de módems, porque en los viejos tiempos era normal que un dispositivo de marcación automático (que era caro) sirviese un banco entero de módems.

Hoy, la mayoría de los módems tienen soporte para marcar incluido, así que la distinción tiende a desaparecer. De cualquier modo, cada marcador o módem puede necesitar una configuración diferente.

Se puede describir cada uno de ellos en el fichero dial. Las entradas en dial empiezan con el comando dialer que indica el nombre del marcador.

La entrada mas importante, aparte de ésta, es el diálogo del módem, especificado por el comando chat. Similar al diálogo de entrada (login), consta de una secuencia de caracteres que uucico envía al marcador y de la secuencia que espera recibir como respuesta. Se usa normalmente para reiniciar el módem a un estado conocido, y marcar el número. El siguiente ejemplo de una entrada de un marcador muestra un diálogo típico para un módem compatible con Hayes:

El diálogo del módem comienza con "", es decir, que espera una cadena vacía. uucico entonces envía el primer comando (ATZ) de inmediato. ATZ es el comando de Hayes para reiniciar el módem. Entonces espera hasta que el módem envíe OK, y a continuación envía el siguiente comando que desactiva el eco local, y cosas parecidas. Después de que el módem envíe OK otra vez, uucico envía el comando de marcación (ATDT). La secuencia de escape \T en esta cadena es reemplazada con el número de teléfono obtenido de la entrada de sistema en el fichero sys. uucico espera a que el módem devuelva la cadena CONNECT, que indica que se ha establecido una conexión exitosa con el módem remoto.

A menudo el módem no puede conectarse con el sistema remoto, por ejemplo si el otro sistema esta conectado con otro ordenador y la línea esta ocupada. En este caso, el módem devuelve algún mensaje de error indicando la razón. Los diálogos de módem no pueden detectar estos mensajes; uucico seguirá esperando la cadena esperada hasta que un temporizador se agote. El fichero de recopilación de información (log) de UUCP mostrará solamente el mensaje "timed out in chat script" (tiempo agotado en la macro de diálogo) en vez de la razón real.

Sin embargo, Taylor UUCP le permite informar a uucico sobre estos mensajes de error usando el comando 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 log de UUCP.

El último comando en el ejemplo anterior indica a UUCP que cambie la línea DTR antes de empezar el diálogo de módem. La mayoría de los módems se pueden configurar para conectarse cuando detectan un cambio en la línea DTR, y entrar en modo de comando.14

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 simultaneas, 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 el fichero sys, hay que especificar al sistema a llamar con TCP de la siguiente forma:

El comando address da la dirección de internet (IP) del ordenador, o su nombre de dominio completo (FQDN). La entrada correspondiente en el fichero port seria así:

_____________________________________________
14 También se pueden configurar algunos módems para que se reinicien a si mismos cuando detecten una transición en DTR. Sin embargo, a algunos módems no parece gustarles esto y en ocasiones se bloquean.

Esta entrada indica que hay que usar una conexión de TCP cuando una entrada en el fichero sys hace referencia a tcp-conn, y que el programa uucico deberá tratar de conectarse al puerto TCP 540 en el sistema remoto. Este es el puerto por defecto del servicio UUCP. En vez del número de puerto, también se puede especificar un nombre de puerto simbólico. El número de puerto correspondiente será buscado en el fichero /etc/services.

Supongamos que usted usa una línea directa que conecta su sistema vstout con el ordenador tiny. Al igual que en el caso del módem, tiene que escribir una entrada de sistema en el fichero sys. El comando port identifica el puerto serie en el que tiny esta conectado.

En el fichero port, tiene que describir el puerto serie para la conexión directa. La entrada dialer no hace falta porque no hay que marcar ningún número.

La tarea de UUCP es copiar ficheros de un sistema a otro, y pedir la ejecución de ciertos comandos en sistemas remotos. Por supuesto, usted como administrador querrá control sobre los derechos que concede a otros sistemas - permitirles que ejecuten cualquier comando en su sistema no es una buena idea en absoluto.

Los únicos comandos que Taylor UUCP permite a otros sistemas ejecutar en su ordenador son rmail y rnews, que se usan comúnmente para intercambiar correo y noticias de Usenet sobre UUCP. El directorio en el que uuxqt busca es una opción que se elige al compilar el programa, pero normalmente incluye /bin, /usr/bin, y /usr/local/bin. Para cambiar el conjunto de comandos para un sistema en particular, se puede usar la palabra commands en el fichero sys. Igualmente, el directorio de búsqueda se puede cambiar con el comando command-path. Por ejemplo, usted puede querer dar acceso al sistema pablo para que ejecute el comando rsmtp además de mail y rnews:15

Taylor UUCP también le permite ajustar, en gran medida, las transferencias de ficheros. Por un lado, usted puede desactivar las transferencias hacia y desde un sistema determinado.

Simplemente necesita dar el valor no al comando request, y el sistema remoto no será capaz de obtener ficheros de su sistema ni de poner otros ficheros. De igual modo, puede prohibir que sus usuarios transfieran ficheros desde o hacia otro sistema poniendo la palabra no en el campo transfer. Por defecto, los usuarios del sistema local y el remoto pueden enviar y obtener ficheros.

Además, usted puede configurar los directorios de y a los que quiere que se puedan copiar ficheros. Usualmente se prohibe el acceso de sistemas remotos a una sola estructura de directorios, pero aun así se permite a los usuarios locales que envíen ficheros de sus directorios. Comúnmente, a los usuarios remotos se les permite que reciban ficheros solo del directorio publico de UUCP, /var/spool/uucppublic. Este es el lugar tradicional para poner los ficheros disponibles públicamente; muy parecido a un servidor de FTP en Internet.

Normalmente se refiere a este directorio con el carácter tilde.

Por lo tanto, Taylor UUCP provee cuatro comandos diferentes para configurar los directorios para enviar y recibir ficheros. Estos son local-send, que especifica la lista de directorios desde los que un usuario puede pedir a UUCP que envíe ficheros; local-receive, que da la lista de directorios donde un usuario puede pedir que se reciban los ficheros; y remote-send y remote-receive, que hacen lo correspondiente para las peticiones que vienen de un sistema remoto. Consideremos el siguiente ejemplo:

_____________________________________________
15 El programa rsmtp se usa para manejar el correo con SMTP por lotes. Esto se explica en los capítulos sobre correo.

El comando local-send permite a los usuarios de su sistema que envíen cualquier fichero bajo /home y en el directorio publico de UUCP al sistema pablo. El comando local-receive les permite recibir ficheros bien en el directorio recibir con permiso de escritura universal en uucppublic, o en cualquier directorio que tenga permiso de escritura universal bajo /home. La directiva remote-send permite que el sistema pablo obtenga ficheros de /var/spool/uucppublic, excepto los ficheros bajo los directorios entrada y recibir. Esto se indica a uucico poniendo un signo de exclamación delante de los nombres de los directorios.

Finalmente, la última línea permite que pablo ponga ficheros en entrada. 

Uno de los mayores problemas con la transferencia de ficheros usando UUCP es que solo recibe ficheros en los directorios con permiso de escritura universal. Esto puede tentar a algunos usuarios a poner trampas para otros usuarios, etc. Sin embargo, no hay salida a este problema excepto la desactivación total de la transferencia de ficheros por UUCP.

UUCP provee un mecanismo para que otros sistemas ejecuten transferencias de ficheros por usted. Por ejemplo, esto le permite que el sistema seci obtenga un fichero de uchile por usted, y lo envíe a su sistema. El siguiente comando haría esto:

Esta técnica de pasar un trabajo a través de varios sistemas se llama forwarding (reenvío). En el ejemplo anterior, la razón para usar el reenvío puede ser que seci tiene acceso por UUCP a uchile, pero su sistema no lo tiene. Sin embargo, si usted tiene un sistema de UUCP, es deseable limitar el servicio de reenvío a unos pocos sistemas en que usted confía, para que no se le acumule una factura telefónica horrenda cuando alguien use su sistema para obtener la última versión de X11R6.

Por defecto, Taylor UUCP no permite el reenvío. Para permitirlo para un sistema en particular, puede usar el comando forward. Este comando especifica una lista de ordenadores desde y hacia los cuales el sistema remoto puede pedirle que reenvíe trabajos. Por ejemplo, el administrador de UUCP del sistema seci tendría que añadir las siguientes líneas al fichero sys para permitir que pablo obtenga ficheros de uchile:

La entrada forward-to para uchile es necesaria para que cualquier fichero devuelto por el sea en efecto pasado a pablo. De otro modo, UUCP se desharía del fichero. Esta entrada usa una variación del comando forward que permite que uchile solo envíe ficheros a pablo a través de seci, no al revés.

Para permitir el reenvío a cualquier sistema, use el comando especial ANY (tiene que estar en mayúsculas).

Si quiere configurar su sistema para que otros se conecten a éste llamándole, tiene que permitir conexiones en su puerto serie, y modificar ciertos ficheros del sistema para proveer cuentas de UUCP. Este es el tema de esta sección.

Si quiere usar una línea serie como un puerto de entrada, tiene que activar un proceso getty en ese puerto. Sin embargo, algunas implementaciones de getty no son válidas para esto porque normalmente se desea usar un puerto para entrada y para salida. Por lo tanto tiene que asegurarse de usar un getty que es capaz de compartir la línea con otros programas como uucico, o minicom. Un programa que se comporta así es uugetty del paquete getty_ps. La mayoría de las distribuciones de Linux lo tienen; busque uugetty en el directorio /sbin. Otro programa que existe es mgetty, de Gert Doering, que además hace recepción de facsímiles.

También puede obtener la última versión de estos programas en sunsite.unc.edu, tanto en binario como en código fuente.

La explicación de las diferencias de como uugetty y mgetty manejan la entrada al sistema esta mas allá del alcance de esta pequeña sección; para mas información, vea el HOWTO Serial de Greg Hankins16 , así como la documentación que viene con getty_ps y mgetty.

_____________________________________________
16 También disponible en Castellano (Serial-COMO), en LuCAS

A continuación tiene que configurar las cuentas de usuarios que permiten a sistemas remotos entrar en su sistema y establecer una conexión de UUCP. Generalmente tendrá que suministrar un nombre de usuario para cada sistema que se conecte con usted. Cuando configura una cuenta para el sistema pablo, puede darle el nombre de usuario Upablo.

Para los sistemas que se conectan con el suyo a través del puerto serie, usualmente tiene que añadir estas cuentas al fichero de claves del sistema, /etc/passwd. Es buena idea poner todos los usuarios de UUCP en un grupo especial como uuguest. El directorio raíz de cada cuenta de UUCP tiene que ser el directorio publico /var/spool/uucppublic; el shell de entrada tiene que ser uucico.

Si tiene el paquete de claves ocultadas (shadow password) instalado, podremos hacer esto con el comando useradd:

Si no utiliza la aplicación de claves ocultas, probablemente tendrá que editar /etc/passwd a mano, añadiendo una línea como la siguiente, donde 5000 y 150 son el número de identificación de usuario (uid) y el número de grupo asignado al usuario Upablo y al grupo uuguest, respectivamente.

Una vez creada la cuenta, tiene que activarla asignándole una clave con el comando passwd.

Para servir a sistemas de UUCP que se conectan a su sistema por TCP, tiene que configurar inetd para que reconozca correctamente conexiones en el puerto uucp. Esto se consigue añadiendo la siguiente línea al fichero /etc/inetd.conf :17

La opción -l hace que uucico haga su propia autorización de entrada. Pedirá un nombre de usuario y una clave, igual que el programa estándar login, pero usara su propia base de datos de claves, en vez de /etc/passwd. Este fichero privado de claves se llama /usr/lib/uucp/passwd y contiene pares de nombres de entrada y claves:

Por supuesto, este fichero tiene que pertenecer al usuario uucp y tener permiso 600.

_____________________________________________
17 Normalmente, tcpd tiene modo 700, así que tiene que invocarlo como usuario root, no como usuario uucp, como haría normalmente.

Si esta base de datos parece una idea tan buena que le gustaría usarla en verificación normal de entrada (login) por serie también, se desilusionara al saber que esto no es posible por el momento de manera sencilla. Para empezar, necesita Taylor UUCP 1.05 para hacer esto, porque permite a getty que pase el nombre del usuario que llama al programa uucico usando la opción -u.18 Luego tiene que engañar al programa getty que este usando para que llame a uucico en vez del usual login. Con getty_ps, esto se puede hacer poniendo la opción LOGIN en el fichero de configuración. Sin embargo, esto desactiva los logins interactivos por completo. mgetty, por otro lado, tiene una característica atractiva que le permite invocar diferentes comandos de entrada (login) según el nombre de usuario suministrado.

Por ejemplo, puede decirle a mgetty que use uucico para todos los usuarios cuyo nombre de usuario comience con una U mayúscula, pero dejar que todos los demás usen el comando estándar login.

Para proteger a sus usuarios de UUCP de otros que den un nombre de sistema falso y les lean todo el correo, tiene que añadir comandos called-login a cada entrada de sistema en el fichero sys. Esto se describe en la sección siguiente.

Uno de los mayores problemas con UUCP es que el sistema que nos llama puede mentir acerca de su nombre; comunica su nombre al sistema que llama después de entrar, pero el servidor no tiene manera de comprobarlo. Por consiguiente, un atacante podría entrar con su propia cuenta de UUCP, pretender ser otra persona, y coger el correo de esa otra persona.

Esto representa un grave problema, especialmente si usted ofrece entrada mediante UUCP anónimo, que tiene una clave publica.

A menos que usted sepa que puede confiar en todos los sistemas que llaman al suyo, usted tiene que protegerse de esta clase de impostores. La cura de esta enfermedad es requerir que cada sistema use un nombre de entrada particular, poniendo un comando called-login en el fichero sys. Un ejemplo de esto podría ser así:

_____________________________________________
18 La opción -u también existe en 1.04, pero no hace nada.

La ventaja de este método es que cuando un sistema entra y pretende ser pablo, el programa uucico comprobara que haya entrado como usuario Upablo. Si no es así, el sistema que nos llama será desconectado. Debería acostumbrarse a incluir el comando called-login en todas las entradas de sistema que añada a su fichero sys. Es importante que haga esto para todos los sistemas, independientemente de si llamaran a su sistema o no. Para aquellos sistemas que nunca le llamaran, usted puede indicar en called-login un nombre ficticio, como nuncallama.

Otra manera de defenderse de impostores es usando la comprobación de secuencia de llamadas. La comprobación de secuencia de llamadas le ayuda a protegerse de intrusos que de alguna manera consiguieron la clave con la que usted entra en su sistema de UUCP.

Cuando usa comprobación de secuencia de llamadas, ambas maquinas mantienen una cuenta del número de conexiones establecidas hasta el momento. Se incrementa con cada conexión. Después de entrar, el llamador envía su número de secuencia de llamadas y el sistema llamado lo comprueba con su propio número. Si no son iguales, el intento de conexión es rechazado. Si el número inicial se elige aleatoriamente, los atacantes lo tendrán mas difícil para adivinar el número de secuencia de llamadas correcto.

Pero la comprobación de la secuencia de llamada sirve para mas que esto: aunque una persona muy inteligente descubriese su número de secuencia de llamada así como su clave, usted sabrá que esto ha ocurrido. Cuando el atacante llama al sistema de UUCP que le provee el correo a usted y roba su correo, esto incrementa el número de secuencia de llamada en uno. La siguiente vez que usted se conecta con su proveedor de correo e intenta entrar, el uucico remoto le rechazara, porque los números de secuencia ya no son iguales.

Si usted activa la comprobación de secuencia de llamadas, debería comprobar los ficheros históricos regularmente para buscar mensajes de error que puedan significar posibles ataques. Si su sistema rechaza el número de secuencia de llamada que el sistema remoto le ofrece, uucico pondrá un mensaje en el fichero histórico que dirá algo como "Out of sequence call rejected" ("Llamada fuera de secuencia rechazada"). Si su sistema es rechazado por el proveedor de correo porque los número de secuencia no están sincronizados, pondrá un mensaje en el fichero histórico que dice "Handshake failed (RBADSEQ)" ("Negociación fallida (RBADSEQ)").

Para activar la comprobación del número de secuencia, tiene que añadir el siguiente comando en la entrada de sistema:

Aparte de esto, tiene que crear el fichero que contiene el número de secuencia. Taylor UUCP mantiene el número de secuencia en un fichero llamado .Sequence en el directorio de cola (spool) del sistema remoto. Tiene que pertenecer al usuario uucp, y debe tener permisos 600 (es decir, visible y escribible solo por uucp). Lo mejor es inicializar este fichero con un valor arbitrario que ambas partes hayan acordado. De otro modo el atacante podría apañárselas para adivinar el número probando todos los valores menores que, digamos, 60.

Por supuesto, el sistema remoto también tiene que activar la comprobación del número de secuencia, y empezar usando el mismo número que usted.

Si quiere ofrecer acceso anónimo de UUCP a su sistema, primero tiene que establecer una cuenta especial como se describió anteriormente. Es practica común darle a esta cuenta el nombre y la clave uucp.

Además, tiene que especificar algunas opciones de seguridad para sistemas desconocidos. Por ejemplo, usted podría querer prohibirles que ejecuten comandos en su sistema. Sin embargo, estos parámetros no se pueden poner en una entrada del fichero sys, porque el comando system requiere el nombre del sistema, que en este caso no tenemos. Taylor UUCP resuelve este dilema con el comando unknown. unknown se puede usar en el fichero config para especificar cualquier comando que puede aparecer normalmente en una entrada de sistema:

Esto limita a los sistemas desconocidos a que se bajen ficheros del directorio pub y que dejen ficheros en el directorio incoming bajo /var/spool/uucppublic. La siguiente línea hace que uucico ignore cualquier petición del sistema remoto de activar la comprobación de errores (debugging) localmente. Las dos últimas líneas permiten que los sistemas desconocidos ejecuten rmail ; pero el camino de búsqueda de comandos especificado hace que uucico busque el comando rmail solamente en un directorio privado llamado anon-bin. Esto le permite a usted suministrar algún programa rmail especial que, por ejemplo, reenvíe todo el correo al superusuario para examinarlo. Esto permite a los usuarios anónimos contactar con el administrador del sistema, pero al mismo tiempo evita que ellos manden correo a otros sistemas.

Para activar UUCP anónimo, tiene que especificar por lo menos un comando unknown en el fichero config. Si no, uucico rechazara cualquier sistema desconocido.

Para negociar el control de la sesión y las transferencias de ficheros con el sistema remoto, uucico usa un grupo de mensajes estándar. Esto es lo que se llama normalmente protocolo de alto nivel. Durante la fase de inicialización y la fase de desconexión éstos se envían simplemente como tiras de caracteres. Sin embargo, durante la fase de transferencia, se usa también un protocolo de bajo nivel, que resulta transparente para los niveles superiores. De esta manera es posible comprobar errores cuando se usan líneas poco fiables, por ejemplo.

Dado que UUCP se usa sobre diferentes tipos de conexiones, como líneas serie, TCP, o incluso X.25, es preciso usar protocolos de bajo nivel específicos. Además, varias implementaciones de UUCP han introducido diferentes protocolos para hacer lo mismo.

Los protocolos se pueden dividir en dos categorías: de corriente o flujo (streaming) y por paquetes. La primera clase de protocolos transfiere un fichero entero, posiblemente calculando una suma de comprobación (checksum). Esto apenas supone un gasto extra de tiempo, pero precisa una conexión fiable, porque cualquier error causaría que todo el fichero tenga que volver a ser enviado. Estos protocolos se suelen usar sobre conexiones de TCP, pero no sobre líneas telefónicas. Aunque los módems modernos hacen un buen trabajo corrigiendo errores, no son perfectos, y tampoco lo es la detección de errores entre el ordenador y el módem.

Por su lado, los protocolos por paquetes parten el fichero en varias partes de igual tamaño. Cada paquete se envía y recibe por separado, se realiza una suma de comprobación, y se devuelve al origen un paquete de confirmación. Para que sea mas eficiente, se inventaron protocolos de ventanas deslizantes, que permiten un número limitado (una ventana) de paquetes sin esperar confirmación en un momento dado. Esto reduce considerablemente la cantidad de tiempo que uucico tiene que esperar durante una transmisión. Aun así, todos los cálculos extra necesarios en comparación a un protocolo de flujo hace que los protocolos de paquetes sean ineficientes sobre TCP.

El ancho de los datos también supone una diferencia. A veces, el envío de caracteres de ocho bits sobre una conexión serie es imposible, por ejemplo si la conexión atraviesa un estúpido servidor de terminales. En este caso, los caracteres con el octavo bit igual a uno tienen que ser especialmente tratados. Cuando se envían caracteres de ocho bits sobre una conexión de siete bits, tienen que estar bajo la suposición del peor caso posible. Esto duplica la cantidad de datos a transmitir, aunque la compresión que se hace por hardware puede compensar esto. Las líneas que pueden transmitir caracteres de ocho bits se llaman preparadas para ocho bits. Este es el caso de todas las conexiones TCP, así como la mayoría de los módems.

Existen los siguientes protocolos con Taylor UUCP 1.04:

g Este es el protocolo mas común y debería ser entendido por prácticamente todos los uucico's. Hace comprobación de errores en profundidad y es, por lo tanto, apropiado para las ruidosas conexiones telefónicas. g require una conexión preparada para ocho bits. Es un protocolo orientado a paquetes que usa una técnica de ventana deslizante.

i Este es un protocolo bidireccional de paquetes que puede enviar y recibir ficheros al mismo tiempo. Requiere una conexión que permita comunicación bidireccional simultanea (full-duplex) y preparada para ocho bits. Actualmente solo es usado por Taylor UUCP.

t Este es un protocolo diseñado para usarse sobre una conexión de TCP, u otras redes libres de errores. Usa paquetes de 1024 bytes y requiere una conexión de ocho bits.

e Este protocolo básicamente hace lo mismo que t. La principal diferencia es que e es un protocolo de flujo.

f Este protocolo esta pensado para usarse sobre conexiones fiables X.25. Es un protocolo de flujo y espera una conexión de siete bits. Los caracteres de ocho bits son codificados, lo cual lo hace muy ineficiente.

G Esta es la versión del Unix SVR419 del protocolo g. También se utiliza en algunas otras versiones de UUCP.

a Este protocolo es similar a ZMODEM. Requiere una conexión de ocho bits, pero codifica ciertos caracteres como XON y XOFF.

_____________________________________________
19 N. del T.: Unix Sistema V Version 4

Todos los protocolos permiten alguna variación en el tamaño de los paquetes, el cronometro y similares. Usualmente, los valores por defecto funcionan bien, pero puede no ser óptimo para su configuración. El protocolo g, por ejemplo, usa tamaños de ventanas de 1 a 7, y tamaños de paquetes en potencias de 2 desde 64 a 4096.20 Si su línea telefónica es tan ruidosa que ignora el 5 por ciento de los paquetes, probablemente debería disminuir el tamaño de los paquetes y de la ventana. Sin embargo, en líneas de teléfono muy buenas el hecho de enviar acuses de recibo por cada 128 bytes puede resultar un desperdicio, así que podría incrementar el tamaño de los paquetes a 512 o incluso 1024.

Taylor UUCP provee un mecanismo para satisfacer sus necesidades mediante el ajuste de estos parámetros con el comando protocol-parameter en el fichero sys. Por ejemplo, para ajustar el tamaño de los paquetes del protocolo g a 512 cuando se conecte con el sistema pablo, tiene que añadir:

Los parámetros ajustables y sus nombres varían entre protocolos. Para ver una lista completa de éstos puede consultar la documentación que acompaña al código fuente de Taylor UUCP.

No todas las implementaciones de uucico hablan y entienden cada protocolo, de modo que durante la fase de negociación de protocolos, ambos procesos tienen que ponerse de acuerdo en uno común. El uucico maestro ofrece al esclavo una lista de protocolos soportados enviando Pprotlist , de la cual el esclavo elige uno.

Según el tipo de puerto usado (módem, TCP o directo), uucico crea una lista por defecto de protocolos. Para módem y conexiones directas, esta lista normalmente incluye i, a, g, G, y j. Para conexiones TCP, la lista es t, e, i, a, g, G, j, y f. Esto se puede cambiar con el comando protocols, que se puede especificar en una entrada de sistema o en una de puerto.

Por ejemplo, usted podría modificar la entrada del fichero port para su puerto de módem de esta manera:

port serial1
...
protocols igG

Esto requiere que cualquier conexión entrante o saliente en este puerto use i, g o G. Si el sistema remoto no soporta ninguno de éstos, la negociación fallara.

_____________________________________________
20 La mayoría de los programas incluidos en las distribuciones de Linux usan por defecto un tamaño de ventana de 7 y paquetes de 128 bytes.

Esta sección describe lo que puede ir mal con su conexión de UUCP y sugiere donde buscar el error. Sin embargo, solo he puesto las preguntas que se me han ocurrido, por lo que pueden surgir otras muchas cosas que no diga aquí.

En cualquier caso, active la opción de encontrar errores con -xall, y observe el resultado en el fichero Debug del directorio de cola. Esto debería ayudarle rápidamente a reconocer donde reside el problema. Siempre me ha servido de ayuda el activar el altavoz del módem cuando no se conecta. Con un módem compatible Hayes, esto se consigue añadiendo "ATL1M1 OK" en el diálogo del módem en el fichero dial.

La primera cosa a comprobar siempre debería ser si todos los permisos de los ficheros están ajustados correctamente. uucico debe tener identificación de usuario uucp, y todos los ficheros en /usr/lib/uucp, /var/spool/uucp y /var/spool/uucppublic tienen que pertenecer a uucp. También hay algunos ficheros ocultos21 en el directorio de cola que tienen que pertenecer a uucp.

uucico dice constantemente "Wrong time to call": Esto probablemente significa que en la entrada de sistema en sys, usted no especifico el comando time que determina a que horas se puede llamar al sistema remoto, o bien especifico unas horas que en realidad prohiben llamar en este momento. Si no se especifica cuando se puede llamar, uucico asume que no se puede llamar nunca a ese sistema.

uucico se queja de que el sistema ya esta en uso: Esto significa que uucico detecto un fichero cerrojo (lock) para el sistema remoto en /var/spool/uucp. El fichero cerrojo puede pertenecer a una llamada anterior al sistema que fue interrumpida. Sin embargo, también es posible que haya otro uucico ejecutándose en el sistema que este intentando llamar al sistema remoto y se atasco en una macro de diálogo, etc. Si este uucico no consigue conectarse al sistema remoto, mátelo con una señal de colgar (SIGHUP), y borre cualquier fichero de bloqueo que haya dejado.

Me puedo conectar al sistema remoto, pero la macro de diálogo falla: Mire el texto que recibe del sistema remoto. Si esta salteado, esto puede ser un problema relacionado con la velocidad. Si no, confirme que realmente envía lo que su macro de diálogo espera recibir. Recuerde, la macro de diálogo empieza con una cadena de caracteres esperada. Si usted recibe la invitación de entrada al sistema (login), después envía su nombre pero luego no se le pregunta por la clave de acceso, inserte un retraso antes de enviarlo, o incluido entre las letras. Puede ser que usted sea demasiado rápido para su módem.

_____________________________________________
21 Es decir, ficheros cuyo nombre empieza con un punto. Estos ficheros normalmente no aparecen con un comando ls.

Mi módem no marca: Si su módem no indica que la línea DTR ha sido elevada cuando uucico hace una llamada, posiblemente no le ha dado el dispositivo correcto a uucico. Si su módem reconoce DTR, compruebe con un programa terminal que usted puede escribir comandos. Si esto funciona, active el eco con el comando \E al comienzo del diálogo del módem. Si esto no produce un eco de sus comandos durante el diálogo del módem, compruebe si la velocidad de la línea es demasiado alta o demasiado baja para su módem. Si que ve el eco, compruebe si ha desactivado las respuestas del módem, o las ha configurado como códigos numéricos. Verifique que la macro de diálogo en si misma es válida. Recuerde que tiene que poner dos barras invertidas para enviar una al módem.

Mi módem intenta marcar, pero la llamada no sale: Inserte un retraso en el número de teléfono. Esto es especialmente útil cuando se llama fuera de la red interna de una compañía. Para la gente en Europa, que normalmente marca con pulsos (pulse-tone), pruebe con tonos (touch-tone). En ciertos países, los servicios telefónicos han actualizado sus redes recientemente. "touch-tone" ayuda a veces.

El fichero de registro (log) dice que tengo un ratio de paquetes perdidos extremadamente alto: Esto parece un problema de velocidad. Puede ser que la conexión entre su ordenador y su módem sea demasiado lenta (recuerde adaptarla a la mayor velocidad efectiva posible). O puede ser que su hardware sea demasiado lento para servir las interrupciones a tiempo. Con un chip NSC 16550A en su puerto serie, 38kbps puede funcionar razonablemente bien; sin embargo, sin FIFOs (como el chip 16450), el limite es 9600. También tiene que asegurarse de que la negociación hardware esta incluida en la línea serie.

Otra posible causa es que la negociación hardware no este activada en el puerto. Taylor UUCP 1.04 no tiene mecanismos para activar la negociación de RTS/CTS. Tiene que activarla explícitamente en el fichero rc.serial usando el siguiente comando:

Puedo entrar en el otro sistema, pero la negociación falla: Bien, puede ser debido a muchas causas. Los mensajes en el fichero de registro deberían decirle un montón de cosas. Mire que protocolos ofrece el sistema remoto (envía un Pprotlist durante la negociación). A lo mejor no tienen nada en común (¿seleccionó algún protocolo en sys o port?).

Si el sistema remoto envía RLCK, hay un fichero de bloqueo (lock) para su sistema en el sistema remoto. Si no es porque usted ya esta conectado al sistema remoto en otra línea, pida que lo borren.

Si envía RBADSEQ, el otro sistema tiene la comprobación de la cuenta de conversación activada para su sistema, pero los números no se corresponden. Si envía RLOGIN, no le fue permitido entrar con ese nombre de usuario.

Cuando se compila el paquete de UUCP para usar ficheros de registro al estilo Taylor-UUCP, se tendrán tres ficheros históricos globales, y todos residirán en el directorio de cola. El fichero principal se llama Log y contiene toda la información sobre las conexiones establecidas y los ficheros transferidos. Un extracto típico podría ser como el siguiente (después de formatearlo para que quepa en la página):

El siguiente fichero importante es Stats, que lista las estadísticas de transferencias de ficheros. La sección de Stats que corresponde a la transferencia anterior se muestra aquí:

Como en el caso anterior, las líneas han sido partidas para que quepan en la página.

El tercer fichero es Debug. Este es el sitio donde se incluye toda la información para buscar errores. Si usted usa detección de errores (debugging), tiene que asegurarse de que este fichero tenga modo de protección de 600. Dependiendo del modo de búsqueda de errores que haya elegido, este fichero puede incluir el nombre de usuario y la clave que usted usa para conectarse al sistema remoto.

Algunos programas de UUCP que incluyen algunas distribuciones de Linux han sido compilados para usar el estilo de fichero de registro histórico de HDB. HDB UUCP usa muchos ficheros de registro archivados bajo /var/spool/uucp/.Log. Este directorio contiene tres directorios mas, llamados uucico, uuxqt y uux. Estos contienen el resultado de información histórica generada por cada uno de los comandos correspondientes, ordenada en diferentes ficheros para cada sistema. Por lo tanto, la salida del programa uucico cuando se llama a pablo acabara en .Log/uucico/pablo, mientras que el uuxqt correspondiente escribirá en .Log/uuxqt/pablo. Las líneas escritas a cada uno de estos ficheros son sin embargo iguales que en Taylor UUCP.

Cuando active la opción de búsqueda de errores con el estilo HDB, la información será escrita en el directorio .Admin bajo /var/spool/uucp. Durante llamadas salientes, la información se envía al fichero .Admin/audit.local, mientras que la salida de uucico cuando alguien nos llama se graba en .Admin/audit.