Guia de Administracion de Redes con Linux _______________________________________________________________________________________________________________ Copyright Oc 1992-1994 Olaf Kirch (Traduccion Proyecto LuCAS) Version final 1.0, 1 de Junio de 1999. Fecha de montaje: 30 de mayo de 1999 Para Britta | | | | | | | | || || _________________________________________________________________________________________________________|| | | | Legal Notice | | | | UNIX is a trademark of Univel. | | | | Linux is not a trademark, and has no connection to UNIXTM or Univel. | | | | | | | | Copyright Oc 1994 Olaf Kirch | | | | Kattreinstr. 38, 64295 Darmstadt, Germany | | okir@monad.swb.de | | | | | | | | "The Linux Network Administrators' Guide" may be reproduced and distributed in whole | | | | or in part, subject to the following conditions: | | | | | | 0. The copyright notice above and this permission notice must be preserved complete | | | | on all complete or partial copies. | | | | 1. Any translation or derivative work of "The Linux Network Administrators' Guide" | | | | must be approved by the author in writing before distribution. | | | | | | 2. If you distribute "The Linux Network Administrators' Guide" in part, instructions | | | | for obtaining the complete version of "The Linux Network Administrators' Guide" | | must be included, and a means for obtaining a complete version provided. | | | | | | 3. Small portions may be reproduced as illustrations for reviews or quotes in other | | | | works without this permission notice if proper citation is given. | | | | 4. If you print and distribute "The Linux Network Administrators' Guide", you may | | | | not refer to it as the "Official Printed Version". | | | | | | 5. The GNU General Public License referenced below may be reproduced under the | | | | conditions given within it. | | | | 6. Several sections of this document are held under separate copyright. When these | | | | sections are covered by a different copyright, the seperate copyright is noted. If | | | | you distribute "The Linux Network Administrators' Guide" in part, and | | | | that part is, in whole, covered under a seperate, noted copyright, the | | | | conditions of that copyright apply. | | | | | | Exceptions to these rules may be granted for academic purposes: Write to Olaf Kirch at | | the above address, or email okir@monad.swb.de, and ask. These restrictions are here to | | | | protect us as authors, not to restrict you as educators and learners. | | | | | | | | All source code in "The Linux Network Administrators' Guide" is placed under the GNU | | | | General Public License. See appendix C for a copy of the GNU "GPL." | | | | The author is not liable for any damages, direct or indirect, resulting from the use of | | information provided in this document. | |________________________________________________________________________________________________________| | | | | | | | | || || _________________________________________________________________________________________________________|| | | | Nota Legal | | | | UNIX es una marca registrada de Univel. | | | | Linux no es una marca registrada, y no tiene relacion con UNIXTM o Univel. | | | | | | | | Copyright Oc 1994 Olaf Kirch | | | | Kattreinstr. 38, 64295 Darmstadt, Alemania | | okir@monad.swb.de | | | | | | | | La "Guia de Administracion de redes con Linux" puede ser total o parcialmente reprodu- | | | | cida y distribuida, bajo las siguientes condiciones: | | | | | | 0. La nota de copyright anterior y esta nota de permiso debe preservarse en toda | | | | reproduccion total o parcial. | | | | 1. Cualquier traduccion o trabajo derivado de la "Guia de Administracion de redes | | | | con Linux" debe ser aprobado por el autor antes de su distribucion. | | | | | | 2. Si Vd. distribuye la "Guia de Administracion de redes con Linux" en parte, debera | | | | incluir instrucciones para obtener la version completa. | | | | 3. Pueden reproducirse peque"nas partes como ilustraciones o citas, en otros trabajos | | | | y sin permiso expreso, siempre que se cite la procedencia. | | | | | | 4. Si imprime o distribuye la "Guia de Administracion de redes con Linux", no podra | | referirse a ella como la "Version Oficial Impresa". | | | | | | 5. La Licencia Publica General de GNU citada puede reproducirse bajo sus propias | | | | condiciones. | | | | | | 6. Algunas partes de este libro estan sujetas a diferentes copyrights. Cuando esto | | suceda, el copyright especifico se incluira. Si distribuye una parte de la "Guia | | | | de Administracion de redes con Linux" que este cubierta por un copyright | | | | especifico, se aplicaran a dicha copia las condiciones de dicho copyright. | | | | | | Se admiten excepciones en el cumplimiento de estas reglas con propositos | | | | academicos: escribase a Olaf Kirch a la direccion anterior o por correo electronico | | | | (okir@monad.swb.de), y preguntese. Estas restricciones estan para protegernos como | | autores, no para limitarles como educadores o estudiantes. | | | | | | | | Todo el codigo fuente incluido en la "Guia de Administracion de redes con Linux" se rige | | | | bajo la Licencia Publica General GNU (GNU General Public License). El apendice C | | | | contiene una copia de dicha licencia. | | | | El autor no se hace responsable de cualquier da"no, directo o indirecto, que pueda producirse | | por el uso de la informacion proporcionada en este libro. | |________________________________________________________________________________________________________| Indice General Prologo a la Edicion en Castellano vi Nota Acerca de Esta Traduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Prefacio viii Documentacion de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Sobre Este Libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x La Version Impresa Oficial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Mas Informacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Sobre los autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Convenciones Tipograficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv El Proyecto de Documentacion de Linux . . . . . . . . . . . . . . . . . . . . . . . xvi El Proyecto LinUx en CAStellano (LuCAS) . . . . . . . . . . . . . . . . . . xvi Estandares de Sistema de Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . xviii 1 Introduccion a las Redes 1 1.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Redes UUCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1 Como usar UUCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Redes TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Introduccion a las Redes TCP/IP . . . . . . . . . . . . . . . . . . . 5 1.3.2 Ethernets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.3 Otros tipos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.4 El Protocolo IP (Internet Protocol) . . . . . . . . . . . . . . . . . . . 9 1.3.5 IP en Lineas Serie, SLIP . . . . . . . . . . . . . . . . . . . . . . . . . 11 iv _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 1.3.6 El Protocolo de Control de Transmision, TCP . . . . . . . . . . . . . 11 1.3.7 El Protocolo de Datagramas de Usuario, UDP . . . . . . . . . . . . 12 1.3.8 Mas sobre Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.9 La Libreria de Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4 Redes con Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4.1 Diferentes Etapas de Desarrollo . . . . . . . . . . . . . . . . . . . . . 15 1.4.2 Donde Conseguir el Codigo . . . . . . . . . . . . . . . . . . . . . . . 15 1.5 Mantenimiento del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.5.1 Seguridad del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.6 Vistazo a los Siguientes Capitulos . . . . . . . . . . . . . . . . . . . . . . . . 18 2 Cuestiones sobre redes TCP/IP 20 2.1 Interfaces de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 Resolucion de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Encaminamiento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.1 Redes IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.2 Subredes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.3 Pasarelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.4 Tablas de Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.5 Metricas de Encaminamiento . . . . . . . . . . . . . . . . . . . . . . 28 2.5 Protocolo de Mensajes de Control de Internet (ICMP) . . . . . . . . . . . . 29 2.6 El sistema de nombres DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.1 Resolucion de nombres . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.2 Introduccion al DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3 Busquedas de nombres con DNS . . . . . . . . . . . . . . . . . . . . 33 2.6.4 Servidores de Nombres . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.6.5 La Base de Datos DNS . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6.6 Resolucion inversa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3 Configuracion del Hardware de Red 39 3.1 Dispositivos, Controladores, y todo lo demas . . . . . . . . . . . . . . . . . 39 3.2 Configuracion del nucleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 3.2.1 Opciones del nucleo de Linux 1.0 o Versiones Posteriores . . . . . . . 42 3.2.2 Opciones del nucleo de Linux 1.1.14 y Versiones Posteriores . . . . . 44 3.3 Una Visita a los Dispositivos de Red de Linux . . . . . . . . . . . . . . . . . 46 3.4 Instalacion Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.1 Cableado de Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.2 Tarjetas Compatibles . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.3 Autoverificacion de red Ethernet . . . . . . . . . . . . . . . . . . . . 49 3.5 El controlador PLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.6 Los controladores SLIP y PPP . . . . . . . . . . . . . . . . . . . . . . . . . 52 4 Configuracion del Software Serie 53 4.1 Software de Comunicaciones con Modem . . . . . . . . . . . . . . . . . . . . 53 4.2 Introduccion a los Dispositivos Serie . . . . . . . . . . . . . . . . . . . . . . 54 4.3 Acceso a los Dispositivos Serie . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4 Hardware Serie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 Configuracion del Protocolo TCP/IP 59 5.1 Configuracion del Sistema de Ficheros proc . . . . . . . . . . . . . . . . . . 60 5.2 Instalacion de los Ejecutables . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Otro Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.4 Establecimiento del Nombre de la Maquina . . . . . . . . . . . . . . . . . . 61 5.5 Asignacion de una direccion IP . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.6 Preparacion de los ficheros hosts y networks . . . . . . . . . . . . . . . . . . 64 5.7 Configuracion de la Interface para IP . . . . . . . . . . . . . . . . . . . . . . 65 5.7.1 La Interface de Bucle o Loopback . . . . . . . . . . . . . . . . . . . . 66 5.7.2 Interfaces Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.7.3 Encaminamiento a traves de una Pasarela . . . . . . . . . . . . . . . 71 5.7.4 Configuracion de una Pasarela . . . . . . . . . . . . . . . . . . . . . 72 5.7.5 La Interface PLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.7.6 Las Interfaces SLIP y PPP . . . . . . . . . . . . . . . . . . . . . . . 73 5.7.7 La Interface Comodin . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.8 Todo sobre ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.9 Comprobacion mediante netstat . . . . . . . . . . . . . . . . . . . . . . . . . 77 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 5.9.1 Consulta de la Tabla de Encaminamiento . . . . . . . . . . . . . . . 77 5.9.2 Consulta de las Estadisticas de una Interface . . . . . . . . . . . . . 78 5.9.3 Mostrar Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.10 Comprobacion de las Tablas ARP . . . . . . . . . . . . . . . . . . . . . . . 80 5.11 El Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6 Servicio de nombres. Configuracion 84 6.1 La biblioteca de resolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.1 El fichero host.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.2 Variables de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.1.3 Configuracion del fichero resolv.conf . . . . . . . . . . . . . . . . . . 87 6.1.4 Robustez del sistema de resolucion . . . . . . . . . . . . . . . . . . . 88 6.2 Ejecucion de named . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.1 El fichero named.boot . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.2 Ficheros de base de datos DNS . . . . . . . . . . . . . . . . . . . . . 91 6.2.3 Escribiendo los ficheros . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2.4 Comprobacion del funcionamiento del servidor de nombres . . . . . 98 6.2.5 Otras utilidades interesantes . . . . . . . . . . . . . . . . . . . . . . 100 7 SLIP: IP por linea serie 102 7.1 Requisitos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.2 Utilizacion de SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.3 Utilizacion de dip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.1 Un script de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.2 Guia de Referencia de dip . . . . . . . . . . . . . . . . . . . . . . . . 107 7.4 Funcionamiento en Modo Servidor . . . . . . . . . . . . . . . . . . . . . . . 111 8 El Protocolo Punto_a_Punto (PPP) 113 8.1 Desenredando las Pes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 8.2 PPP en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 8.3 Conexiones con pppd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 8.4 Los Ficheros de Opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 8.5 Realizacion de la Llamada con chat . . . . . . . . . . . . . . . . . . . . . . . 117 8.6 Depuracion de la Configuracion PPP . . . . . . . . . . . . . . . . . . . . . . 120 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 8.7 Opciones de Configuracion IP . . . . . . . . . . . . . . . . . . . . . . . . . . 120 8.7.1 Eleccion de las Direcciones IP . . . . . . . . . . . . . . . . . . . . . . 120 8.7.2 Encaminamiento a traves de una Conexion PPP . . . . . . . . . . . 121 8.8 Opciones de Control de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . 123 8.9 Consideraciones Generales sobre Seguridad . . . . . . . . . . . . . . . . . . 125 8.10 Autentificacion con PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 8.10.1 CHAP frente a PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 8.10.2 El fichero de claves CHAP . . . . . . . . . . . . . . . . . . . . . . . . 127 8.10.3 El Fichero de Claves PAP . . . . . . . . . . . . . . . . . . . . . . . . 128 8.11 Configuracion de un Servidor PPP . . . . . . . . . . . . . . . . . . . . . . . 130 9 Algunas Aplicaciones de Red 131 9.1 El Super-Servidor inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.2 La herramienta de control de acceso tcpd . . . . . . . . . . . . . . . . . . . 133 9.3 Los ficheros services y protocols . . . . . . . . . . . . . . . . . . . . . . . . . 136 9.4 Llamada a Procedimientos Remotos . . . . . . . . . . . . . . . . . . . . . . 138 9.5 Configurar los Comandos r . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 10 El Sistema de Informacion de Red (NIS) 143 10.1 Familiarizacion con NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.2 NIS frente a NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.3 El lado cliente de NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.4 Ejecucion de un servidor NIS . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.5 Configurar un Cliente NIS con NYS . . . . . . . . . . . . . . . . . . . . . . 150 10.6 Eleccion de los Mapas Correctos . . . . . . . . . . . . . . . . . . . . . . . . 151 10.7 Uso de los mapas passwd y group . . . . . . . . . . . . . . . . . . . . . . . . 153 10.8 Uso de NIS con Soporte Shadow . . . . . . . . . . . . . . . . . . . . . . . . 155 10.9 Uso del Codigo NIS Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . 156 11 El Sistema Ficheros en Red (NFS) 157 11.1 Preparacion de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 11.2 Montaje de un volumen NFS . . . . . . . . . . . . . . . . . . . . . . . . . . 159 11.3 Demonios de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 11.4 El fichero exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 11.5 El sistema de automontado en Linux . . . . . . . . . . . . . . . . . . . . . . 164 12 Administracion de Taylor UUCP 166 12.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 12.1.1 Mas Informacion Sobre UUCP . . . . . . . . . . . . . . . . . . . . . 168 12.2 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 12.2.1 Disposicion de Transferecias de UUCP y Ejecucion Remota . . . . . 168 12.2.2 El Funcionamiento Interno de uucico . . . . . . . . . . . . . . . . . . 169 12.2.3 Opciones de la linea de comandos de uucico . . . . . . . . . . . . . . 171 12.3 Ficheros de configuracion de UUCP . . . . . . . . . . . . . . . . . . . . . . 171 12.3.1 Una Ligera Introduccion a Taylor UUCP . . . . . . . . . . . . . . . 172 12.3.2 Lo que UUCP necesita saber . . . . . . . . . . . . . . . . . . . . . . 175 12.3.3 Nomenclatura de nodos . . . . . . . . . . . . . . . . . . . . . . . . . 176 12.3.4 Ficheros de configuracion Taylor . . . . . . . . . . . . . . . . . . . . 177 12.3.5 Opciones Generales de Configuracion - el Fichero config . . . . . . . 178 12.3.6 Como informar a UUCP sobre otros sistemas - el fichero sys . . . . 178 12.3.7 Que dispositivos hay - el fichero port . . . . . . . . . . . . . . . . . . 183 12.3.8 Como marcar un numero - el fichero dial . . . . . . . . . . . . . . . 185 12.3.9 UUCP sobre TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 12.3.10 Uso de una conexion directa . . . . . . . . . . . . . . . . . . . . . . . 187 12.4 Los sies y noes de UUCP - Ajuste de Permisos . . . . . . . . . . . . . . . . 187 12.4.1 Ejecucion de comandos . . . . . . . . . . . . . . . . . . . . . . . . . 187 12.4.2 Transferencias de Ficheros . . . . . . . . . . . . . . . . . . . . . . . . 188 12.4.3 Reenvio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 12.5 Configuracion de su sistema para ser llamado. . . . . . . . . . . . . . . . . . 190 12.5.1 Configuracion de getty . . . . . . . . . . . . . . . . . . . . . . . . . . 190 12.5.2 Proveer Cuentas de UUCP . . . . . . . . . . . . . . . . . . . . . . . 191 12.5.3 Proteccion contra estafadores . . . . . . . . . . . . . . . . . . . . . . 192 12.5.4 Vuelvase Loco - Comprobacion de Secuencia de Llamadas . . . . . . 193 12.5.5 UUCP Anonimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 12.6 Protocolos de bajo nivel de UUCP . . . . . . . . . . . . . . . . . . . . . . . 195 12.6.1 Resumen del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . 195 12.6.2 Ajuste del protocolo de transmision . . . . . . . . . . . . . . . . . . 197 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 12.6.3 Seleccion de protocolos especificos . . . . . . . . . . . . . . . . . . . 197 12.7 Solucion de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 12.8 Archivos de registro historico (Log Files) . . . . . . . . . . . . . . . . . . . . 200 13 Correo Electronico 202 13.1 >Que es un mensaje de correo? . . . . . . . . . . . . . . . . . . . . . . . . . 203 13.2 >Como se reparte el correo? . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 13.3 Direcciones de correo electronico . . . . . . . . . . . . . . . . . . . . . . . . 207 13.4 >Como funciona el encaminado del correo? . . . . . . . . . . . . . . . . . . . 209 13.4.1 Encaminado de correo en la Internet . . . . . . . . . . . . . . . . . . 209 13.4.2 Encaminado de correo en el mundo UUCP . . . . . . . . . . . . . . 210 13.4.3 Mezcla de UUCP y RFC 822 . . . . . . . . . . . . . . . . . . . . . . 211 13.5 Formatos de Fichero Mapa y Alias de Ruta . . . . . . . . . . . . . . . . . . 213 13.6 Configuracion de elm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.6.1 Opciones Globales de elm . . . . . . . . . . . . . . . . . . . . . . . . 216 13.6.2 Conjuntos de Caracteres Nacionales . . . . . . . . . . . . . . . . . . 216 14 Como configurar y poner en marcha smail 219 14.1 Configuracion de UUCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 14.2 Configuracion para una red local . . . . . . . . . . . . . . . . . . . . . . . . 222 14.2.1 Como escribir los archivos de configuracion . . . . . . . . . . . . . . 223 14.2.2 Como ejecutar smail . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 14.3 Si no logra pasar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 14.3.1 Como compilar smail . . . . . . . . . . . . . . . . . . . . . . . . . . 226 14.4 Modos de entrega de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 14.5 Otras opciones del fichero config . . . . . . . . . . . . . . . . . . . . . . . . 228 14.6 Encaminamiento de mensajes y entrega . . . . . . . . . . . . . . . . . . . . 229 14.7 Mensajes de encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.7.1 La base de datos de trayectorias paths . . . . . . . . . . . . . . . . . 232 14.8 Como entregar mensajes a las direcciones locales . . . . . . . . . . . . . . . 232 14.8.1 Usuarios locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 14.8.2 Reenvio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 14.8.3 Archivos de alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 14.8.4 Listas de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 14.9 Transportes basados en UUCP . . . . . . . . . . . . . . . . . . . . . . . . . 236 14.10 Transportes basados en SMTP . . . . . . . . . . . . . . . . . . . . . . . . . 237 14.11 Calificacion de nombre de anfitrion . . . . . . . . . . . . . . . . . . . . . . . 237 15 Sendmail+IDA 239 15.1 Acerca del autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 15.2 Reconocimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 15.3 Introduccion a Sendmail+IDA . . . . . . . . . . . . . . . . . . . . . . . . . 239 15.4 Archivos de configuracion _ Preliminares . . . . . . . . . . . . . . . . . . . 240 15.5 El archivo sendmail.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 15.5.1 Un ejemplo del archivo sendmail.m4 . . . . . . . . . . . . . . . . . . 242 15.5.2 Parametros de uso comun en sendmail.m4 . . . . . . . . . . . . . . . 242 15.6 Un viaje por las tablas de Sendmail+IDA . . . . . . . . . . . . . . . . . . . 248 15.6.1 mailertable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 15.6.2 uucpxtable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 15.6.3 pathtable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 15.6.4 domaintable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 15.6.5 alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 15.6.6 Tablas utilizadas en raras ocasiones . . . . . . . . . . . . . . . . . . 253 15.7 Instalacion de sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 15.7.1 Desempaquetado de la distribucion ejecutable . . . . . . . . . . . . . 255 15.7.2 Elaboracion del fichero sendmail.cf . . . . . . . . . . . . . . . . . . . 255 15.7.3 Comprobando el fichero sendmail.cf . . . . . . . . . . . . . . . . . . 256 15.7.4 Integracion global - Prueba de integracion del fichero sendmail.cf y las tablas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 15.8 Trucos y trivialidades sobre administracion de correo . . . . . . . . . . . . . 261 15.8.1 Reenvio de correo a un sistema inteligente . . . . . . . . . . . . . . . 261 15.8.2 Envio de correo a Sistemas Remotos mal configurados . . . . . . . . 262 15.8.3 Envio Forzado de correo a traves de UUCP . . . . . . . . . . . . . . 263 15.8.4 Prevencion de que el correo sea enviado via UUCP . . . . . . . . . . 263 15.8.5 Procesado de la cola de correo a voluntad . . . . . . . . . . . . . . . 264 15.8.6 Informe sobre las estadisticas de correo . . . . . . . . . . . . . . . . 264 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 15.9 Integracion y puesta a punto de Distribuciones Ejecutables . . . . . . . . . 265 15.10 Donde obtener mas informacion . . . . . . . . . . . . . . . . . . . . . . . . . 266 16 Netnews 267 16.1 Historia de Usenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 16.2 >Que es, en definitiva, Usenet? . . . . . . . . . . . . . . . . . . . . . . . . . 268 16.3 >Como maneja Usenet las noticias? . . . . . . . . . . . . . . . . . . . . . . . 270 17 C-News 272 17.1 Entrega de Noticias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 17.2 Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 17.3 El fichero sys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 17.4 El fichero active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 17.5 Procesado de articulos por lotes . . . . . . . . . . . . . . . . . . . . . . . . . 281 17.6 Noticias caducadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 17.7 Ficheros diversos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 17.8 Mensajes de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 17.8.1 El Mensaje cancel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 17.8.2 newgroup y rmgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 17.8.3 El Mensaje checkgroups . . . . . . . . . . . . . . . . . . . . . . . . . 290 17.8.4 sendsys, version, y senduuname . . . . . . . . . . . . . . . . . . . . . 291 17.9 C-News en un Entorno NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 17.10 Herramientas y Tareas de Mantenimiento . . . . . . . . . . . . . . . . . . . 292 18 Una descripcion de NNTP 295 18.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 18.2 Instalacion del servidor NNTP . . . . . . . . . . . . . . . . . . . . . . . . . 297 18.3 Restricciones de acceso NNTP . . . . . . . . . . . . . . . . . . . . . . . . . 298 18.4 Autorizacion NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 18.5 Interaccion de nntpd con Cnews . . . . . . . . . . . . . . . . . . . . . . . . . 300 19 Configuracion del lector de noticias 301 19.1 Configuracion de tin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 19.2 Configuracion de trn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 _______________________________________________________________________________________________________________INDICE G* *ENERAL @ 19.3 Configuracion de nn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 A Un Cable de Impresora para PLIP 306 B Ejemplos de Archivos de Configuracion para smail 307 C The GNU General Public License 316 C.1 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 C.2 Terms and Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 C.3 How to Apply These Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Glosario 323 Bibliografia Comentada 330 Libros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Libros sobre Internet en general . . . . . . . . . . . . . . . . . . . . . . . . . 330 Temas de Administracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Conocimientos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 HOWTOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 >Cuales son los HOWTOs de Linux? . . . . . . . . . . . . . . . . . . . . . . 333 >Donde se consiguen los HOWTOs de Linux? . . . . . . . . . . . . . . . . . 333 Indice de HOWTOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Asuntos varios y cuestiones legales . . . . . . . . . . . . . . . . . . . . . . . 335 Los HOWTOs en Castellano . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Indice de Figuras 1.1 Los tres pasos para enviar un datagrama desde erdos a quark. . . . . . . 10 2.1 Division de una red clase B en subredes . . . . . . . . . . . . . . . . . . . . 25 2.2 Vista parcial de la topologia de la red de la UGM. . . . . . . . . . . . . . . 27 2.3 Parte del espacio de dominios . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 Extracto del fichero named.hosts del departamento de Fisicas. . . . . . . . 35 2.5 Extracto del fichero named.hosts de la UGM. . . . . . . . . . . . . . . . . . 36 2.6 Extracto del fichero named.rev de la subred 12. . . . . . . . . . . . . . . . 37 2.7 Extracto del fichero named.rev de la red 149.76. . . . . . . . . . . . . . . 38 3.1 Relacion entre controladores, interfaces, y hardware. . . . . . . . . . . . . . 40 5.1 Cervecera Virtual y Vinatera Virtual - las dos subredes. . . . . . . . . . . 63 6.1 El fichero named.boot para vlager. . . . . . . . . . . . . . . . . . . . . . . . 90 6.2 Fichero named.ca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.3 Fichero named.hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.4 Fichero named.local. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.5 Fichero named.rev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 7.1 Un script de ejemplo para dip . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.1 Un ejemplo de fichero /etc/inetd.conf. . . . . . . . . . . . . . . . . . . . . . 134 9.2 Un ejemplo de fichero /etc/rpc. . . . . . . . . . . . . . . . . . . . . . . . . 139 10.1 Fichero nsswitch.conf de ejemplo. . . . . . . . . . . . . . . . . . . . . . . . 153 12.1 Interacciones de los Ficheros de Configuracion de Taylor UUCP. . . . . . . 174 xiv _______________________________________________________________________________________________________________INDICE D* *E FIGURAS @ 15.1 Archivos de apoyo de sendmail. . . . . . . . . . . . . . . . . . . . . . . . . 241 15.2 Un archivo muestra de sendmail.m4 para vstout. . . . . . . . . . . . . . . 243 16.1 Flujo de noticias a traves de la Universidad Groucho Marx . . . . . . . . . 269 17.1 Flujo de noticias mediante relaynews. . . . . . . . . . . . . . . . . . . . . . 274 oPrlogo a la Edicion en Castellano Losultimos a"nos de la decada de los 90 son, claramente, los de la explosion definitiva de la Informatica Personal. Es laepoca en la que ordenadores de mediana potencia pueblan las casas particulares. Tambien es el momento en el que Internet se hace popular. Y como ya no es dificil que en un hogar haya mas de un PC, tal vez interesaria tenerlos conectados en red local: al fin y al cabo una tarjeta Ethernet puede costar menos de 5000 pesetas. Este libro trata sobre Linux y su capacidad de red, capacidad que no tiene nada que envidiar a la que pueda tener cualquier otro sistema un?x. Otros sistemas operativos quieren tener ahora, a toda prisa, capacidades de acceso a la Red, pero recordemos que la tecnologia de Internet nacio en Unix. Por esto, esos sistemas seguiran estando, durante mucho tiempo, a a"nos luz de lo que Unix puede ofrecer. Por lo tanto, le doy mi enhorabuena si ha elegido Linux u otro Unix para acceder a la Red y para trabajar. Lo que aqui explicamos intentara echarle una mano en las tareas de administracion de red. Le sera especialmenteutil si su sistema Linux o Unix es servidor de una peque"na red local o de Internet. Nuestro intento como traductores ha sido acercar las ventajas de Unix en red al usuario hispanohablante, ya que creemos que es un asunto aun no cubierto por la bibliografia existente en nuestro idioma. Hemos intentado hacer una traduccion homogenea, pese a haber colaborado en ella gran cantidad de gente. Gracias a la propia Internet, hemos podido tener un canal de comunica- cion fluido para discutir cualquier duda que pudiera surgir entre los traductores, adoptando finalmente un glosario comun de terminos informaticos. Esperamos que el resultado merezca la pena. Ahora es el momento de dar las gracias a todos aquellos que han colaborado en la tra- duccion o en las posteriores revisiones. Estas personas son Corsino Alvarez, I"naki Arenaza, xvi _______________________________________________________________________________________________________________Nota Ace* *rca de Esta Traduccion @ Cesar Ballardini, Alfonso Belloso, Javier Bravo, Santiago Crespo, David Escorial, Maxi- mo Escobar, Manuel Jesus Garrido, Luis F. Gonzalez, Eduardo Hernandez, Jesus Jimenez, Jose Andres Jimenez, Urko Lusa, Carlos Martinez Txakartegi, Max de Mendizabal, Fran- cisco J. Montilla, Jose Manuel Puerta, Angel Luis Pinazo, Pedro Soria Rodriguez y Enrique Zanardi. Porultimo, debo agradecer el nacimiento y desarrollo de la idea de documentar Linux en nuestro idioma, a Ramon Gutierrez y de nuevo a Alfonso Belloso y Francisco J. Montilla. Juan Jose Amor Mayo de 1997 revisado en Abril de 1999 Nota Acerca de Esta Traduccion Esta guia es traduccion de la version 1.0 del libro "Linux Network Administration Guide", escrito por Olaf Kirch entre 1992 y 1994. Es un trabajo mas del proyecto LuCAS, el LDP espa"nol; y ha sido coordinado por Juan Jose Amor, quien desea recibir cualquier tipo de comentario acerca de erratas o sugerencias en su direccion de correo electronico: jjamor@ls.fi.upm.es. Prefacio Las redes de ordenadores parecen estar acercandose a la situacion de los televisores y los hornos microondas, debido a la publicidad que Internet esta teniendo, y el hecho de que la gente de opinion mas respetada en el mundo de la Informatica, este todo el tiempo hablando de las virtudes de la red. Es decir, Internet esta teniendo una cobertura informativa inusual, y las autoridades en ciencia social estan integrandose en los grupos de noticias de Usenet para dirigir las investigaciones sobre la "Cultura Internet". Las compa"nias suministradoras trabajan en la introduccion de nuevas tecnicas de transmision como ATM, que ofrecen un ancho de banda varias veces superior al que ofrecen las redes utilizadas actualmente. En realidad, las redes han estado presentes durante bastante tiempo. La conexion de ordenadores para formar redes de area local ha sido practica comun incluso en instalacio- nes peque"nas, asi como lo han sido los enlaces a larga distancia usando lineas telefonicas publicas. Un rapido crecimiento del conglomerado de redes a nivel mundial ha hecho, sin embargo, que integrarse en la aldea global sea una opcion viable incluso para peque"nas organizaciones sin beneficio de usuarios de ordenadores privados. Instalar un nodo de In- ternet con capacidad de correo y noticias ofreciendo acceso telefonico ha pasado a ser algo accesible, y con la RDSI acelerara sin duda esta introduccion. Hablar de redes de ordenadores a menudo significa hablar de UNIX. Por supuesto, UNIX no es elunico sistema operativo con capacidades de red, ni seguira siendo la puerta de entrada, pero si ha estado en el negocio de las redes por mucho tiempo y seguramente continuara haciendolo al menos durante bastante tiempo. Lo que lo hace particularmente interesante para los usuarios privados es que ha habido gran actividad para conseguir sistemas operativos tipo UNIX gratuitos para PC, como 386BSD, FreeBSD _ y Linux. Sin embargo, Linux no es UNIX. Eso es una marca comercial xviii _______________________________________________________________________________________________________________Document* *acion de Linux @ registrada de quien actualmente tenga los derechos sobre ella (Univel, en el momento de escribir este libro). Linux, en cambio, es un sistema operativo que lucha por ofrecer toda la funcionalidad que requieren los estandares POSIX para sistemas operativos tipo UNIX, aunque es una reimplementacion completa, desde cero. El nucleo de Linux fue escrito enteramente por Linus Torvalds, quien lo comenzo como un proyecto para conseguir conocer el Intel i386, y para "hacer un MINIX mejor". MINIX era entonces otro sistema operativo popular para PC que ofrecia los ingredientes vitales de la funcionalidad un?x, y fue escrito por el Profesor Andrew S. Tanenbaum. Linux esta cubierto por la Licencia Publica General (GPL) GNU, que permite la libre distribucion del codigo (lease, por favor, la GPL en el apendice C para tener una definicion de lo que es "software libre" ("free software")). Superando sus males de joven, y atraido por una siempre creciente base de programas de aplicacion gratuitos, se esta convirtiendo rapidamente en el sistema operativo de eleccion de muchos usuarios de PC. Tanto el nucleo como la libreria C han llegado a ser tan buenos que la mayoria del software estandar se puede compilar sin esfuerzo mayor que el que se requiere en cualquier otro sistema tipo un?x, y una amplia variedad de distribuciones empaquetadas de Linux le permiten practicamente volcarlo en su disco duro y comenzar a manejarlo. Documentacion de Linux Una de las quejas que se recogen frecuentemente en torno a Linux (y al software gratuito en general) es sobre el lamentable estado de la documentacion o su completa carencia. En los primeros dias lo usual era que un paquete viniese con unasutiles notas de instalacion y README s (LEAME s). Estos daban a los magos de un?x, moderadamente experimen- tados, suficiente informacion para instalarlo y ejecutarlo conexito, pero dejaban al tipico novato fuera de juego. Alla por finales de 1992, Lars Wirzenius y Michael K. Johnson sugirieron la formacion del Linux Documentation Project (Proyecto de Documentacion de Linux), o LDP, con el fin de proporcionar un conjunto coherente de manuales. Lejos de contestar preguntas tipo ">Como?", o ">Por que?", o ">Cual es el significado de la vida, el universo y todo lo demas?", estos manuales intentan cubrir la mayoria de aspectos del uso y funcionamiento de un sistema Linux sin necesidad de graduarse previamente en un?x. Entre los logros del LDP estan el Installation and Getting Started Guide1 , escrita por Matt Welsh, el Kernel Hacker's Guide2 de Michael K. Johnson, y el proyecto de paginas de manual coordinado por Rik Faith, que hasta ahora ha producido un conjunto de unas 450 paginas de manual para la mayoria de las llamadas al sistema y librerias de C. La System _____________________________________________1 N. del T.: Y traducida, como este manual, por el Proyecto LuCAS, y cuyo titulo en castellano es "Linux: Instalacion y Primeros Pasos" 2 N. del T.: Guia sobre el Nucleo _______________________________________________________________________________________________________________Sobre Es* *te Libro @ Administrators' Guide3 , escrita por Lars Wirzenius, esta aun en estado alpha. Tambien se esta preparando una Guia de Usuario. Este libro, la Guia de Administracion de Redes con Linux, es tambien parte de la serie LDP. Como tal, puede ser copiado y distribuido libremente bajo la licencia de copia del LDP que se reproduce en la segunda pagina. Sin embargo, los libros del LDP no son launica fuente de informacion en Linux. En este momento hay mas de una docena de HOWTOs (COMOs) que se publican regularmente en comp.os.linux.announce y es posible encontrarlos en multiples servidores de FTP. Los HOWTOs son documentos cortos de unas pocas paginas que dan una breve introduccion a materias como el soporte de Ethernet bajo Linux, o la configuracion del software de noticias Usenet, y responde a las preguntas mas frecuentes. Generalmente proporcionan la informacion mas precisa y actualizada disponible sobre la materia. Podra encontrar una lista de los HOWTOs disponibles en la "Bibliografia" hacia el final de este libro. Sobre Este Libro Cuando me uni al Linux Documentation Project en 1992, escribi dos peque"nos capitulos sobre UUCP y smail, con los que quise contribuir a la System Administrator's Guide. El desarrollo del TCP/IP acababa de comenzar, y cuando esos "peque"nos capitulos" comen- zaron a crecer, me pregunte si no estaria bien tener una Guia de Red. "Fantastico", dijo todo el mundo, "Yo diria, por que querria Ud. pagar dinero por algo que puede conseguir gratis? >Esta loco Tim O'Reilly por publicar algo que todos pueden imprimir e incluso vender por si mismos?5 >O hay alguna diferencia entre estas versiones? Las respuestas son "depende", "no, definitivamente no" y "si y no". O'Reilly and Associates asume un riesgo al publicar la Guia de Red, pero espero que finalmente merezca la pena. Si es asi, creo que este proyecto puede servir como ejemplo de como el mundo del software libre y las compa"nias pueden cooperar para producir algo que beneficia a los dos. Desde mi punto de vista, el gran servicio que esta dando a la comunidad Linux (aparte del libro que tiene disponible en su libreria) es que puede ayudar a que Linux sea reconocido como algo que puede ser tomado en serio: una alternativa util y viable a los sistemas operativos UNIX de PC comerciales. >Entonces, que hay de las diferencias entre la version impresa y la version en linea? Andy Oram se ha esforzado enormemente en transformar mis primeros pasos en algo que merezca la pena imprimirse (el tambien ha estado revisando los otros libros salidos del Proyecto de Documentacion de Linux, intentando contribuir con sus habilidades profesionales a la comunidad Linux). Desde que Andy empezo a revisar la Guia de Red y a editar las copias que yo le mandaba, el libro ha mejorado enormemente frente a lo que era hace medio a"no. No estaria tan cerca _____________________________________________4 El aviso de copyright se reproduce en la pagina inmediantemente posterior a la del titulo. 5 Observe que mientras usted puede imprimir la version en linea, Ud. no puede fotocopiar el libro de O'Reilly, y mucho menos vender ninguna de esas (hipoteticas) copias. _______________________________________________________________________________________________________________Mas Info* *rmacion @ de lo que es ahora sin su contribucion. Todas estas ediciones han recalado en la version en linea, como lo sera cualquier cambio que se haga a la Guia de Red durante la fase de edicion en O'Reilly. De modo que no habra diferencia en contenido. Aun asi, la version de O'Reilly sera diferente: Por un lado, la gente de O'Reilly ha trabajado mucho en el aspecto y forma, dando lugar a un dise"no mucho mas agradable que jamas se lograria con el LATEX estandar. Por otro lado, contara con un par de avances como un indice mejorado, y mas y mejores figuras. Mas Informacion Si sigue las instrucciones de este libro y algo no funciona, por favor, sea paciente. Algunos de sus problemas pueden deberse a fallos estupidos por mi parte, pero tambien pueden ser causados por cambios en el software de red. Ademas, probablemente deberia preguntar primero en comp.os.linux.help. Hay muchas posibilidades de que usted no sea elunico con esos problemas, y probablemente ya se conozca una solucion o al menos se este trabajando en ello. Si tiene oportunidad, deberia intentar conseguir elultimo nucleo y version de red de alguno de los servidores de FTP de Linux, o de una BBS proxima a usted. Muchos problemas vienen de usar software en distintas fases de desarrollo, que fallan al intentar funcionar juntos. Despues de todo Linux es un "trabajo en progreso". Otro buen lugar donde informarse del estado actual de desarrollo es el Networking HOWTO6. Lo mantiene Terry Dawson7. Se incluye en comp.os.linux.announce una vez al mes, y contiene la informacion mas actualizada. La version actual puede obtenerse de (entre otros) tsx-11.mit.edu, en /pub/linux/doc. Para problemas que no puede resolver de ninguna forma, tambien puede contactar con el autor de este libro en la direccion que se facilita en el prefacio. Sin embargo, por favor, abstengase de pedir ayuda a los desarrolla- dores. Ellos ya estan dedicando la mayor parte de su tiempo libre a Linux, y a veces incluso viven mas alla de la red :-). Sobre los autores Olaf ha sido un usuario de UNIX y administrador a tiempo parcial por un par de a"nos mientras estudiaba matematicas. Actualmente, trabaja como programador de UNIX y esta escribiendo un libro. Uno de sus deportes favoritos es hacer cosas con sed que otra gente hace con su interprete perl. El se divierte tanto con esto como con ir al monte con una mochila y una tienda de campa"na. Vince Skahan ha estado administrando gran numero de sistemas UNIX desde 1987 y actualmente ejecuta sendmail+IDA en aproximadamente 300 estaciones UNIX para unos _____________________________________________6 N. del T.: El HOWTO sobre redes 7 A Terry Dawson se le puede localizar en terryd@extro.ucc.su.oz.au. _______________________________________________________________________________________________________________Agradeci* *mientos @ 2000 usuarios. Admite haber perdido un considerable numero de horas de sue"no editando unos pocos ficheros sendmail.cf "a pelo" antes de descubrir sendmail+IDA en 1990. Tam- bien admite haber esperado ansiosamente el envio de la primera version de sendmail basada en perl incluso para sus diversiones mas oscuras8. . . A Olaf se le puede encontrar en la siguiente direccion: Olaf Kirch Kattreinstr. 38 64295 Darmstadt Germany okir@monad.swb.de A Vince se le puede encontrar en: Vince Skahan vince@victrola.wa.com Estamos abiertos a sus preguntas, comentarios, postales, etc. Sin embargo, le pediriamos que no nos telefonee a no ser que sea realmente importante. Agradecimientos Olaf dice: Este libro debe gran parte de su contenido a gente que dedico tiempo a revisarlo y ayudo a depurar muchos fallos, tanto tecnicos como gramaticos (jamas supe que existiera algo como un participio oscilante9). El mas riguroso de ellos fue Andy Oram de O'Reilly and Associates. Estoy muy en deuda con Andres Sepulveda, Wolfgang Michaelis, Michael K. Johnson, y todos los desarrolladores que dedicaron su tiempo a comprobar la informacion de la Guia de Red. Tambien quiero agradecer a todos los que leyeron la primera version de la Guia de Red y me enviaron sus correcciones y sugerencias. Espero que puedan encontrar una lista completa de los que han contribuido en el fichero Thanks de la distribucion en linea. Por fin, este libro no hubiese sido posible sin el apoyo de Holger Grothe, quien me facilito lo crucial, la conexion a Internet. Tambien quisiera agradecer a los siguientes grupos y compa"nias que imprimieron la primera version de la Guia de Red y han donado dinero incluso para mi, o para el Proyecto de Documentacion de Linux en su conjunto. _____________________________________________8 >No crees que lo podriamos hacer con sed, Vince? 9 N. del T.: Realmente no se si en ingles existe algo asi, o es simplemente una broma del autor _______________________________________________________________________________________________________________Agradeci* *mientos @ o Linux Support Team, Erlangen, Germany o S.u.S.E. GmbH, Fuerth, Germany o Linux System Labs, Inc., United States Vince dice: Mis agradecimientos van para Neil Rickert y Paul Pomes por su gran ayuda estos a"nos concerniente al cuidado y mantenimiento de sendmail+IDA y a Rich Braun por portar inicialmente el sendmail+IDA a Linux. El mayor agradecimiento va para mi esposa Susan por todo su apoyo en este y otros proyectos. _______________________________________________________________________________________________________________Convenci* *ones Tipograficas @ Convenciones Tipograficas Al escribir este libro se han usado ciertas convenciones tipograficas para marcar comandos de shell, argumentos variables, etc. Se detallan a continuacion. Fuente Negrita Se usa para marcar nombres de maquinas y direcciones de correo, asi como nuevos conceptos y avisos. Fuente Italica Se usa para marcar nombres de fichero, comandos UNIX, y palabras clave en ficheros de configuracion. Tambien se usa para enfatizar texto. Fuente de maquina de escribir Se usa para representar interaccion con la pantalla, como la interaccion del usuario ejecutando un programa. Tambien se usa para ejemplos de codigo, ya sea un fichero de configuracion, un script de shell, o algo asi. Fuente de maquina de escribir inclinada Se usa para marcar meta-variables en el texto, especialmente en representa- ciones de la linea de comandos. Por ejemplo, $ ls -l ejemplo donde ejemplo "representaria" un nombre de fichero, como, por ejemplo, /tmp. ________ |_Tecla_ | Representa una tecla a pulsar. Lo vera a menudo de esta forma: _________ Pulse |_return_ |para continuar. 3 Un rombo en el margen, como un rombo negro en una pista de esqui, marca "peligro" o "precaucion". Lea los parrafos marcados asi cuidadosamente. $ y # Cuando preceden a un comando de shell a escribir, esto denota el prompt del shell. El simbolo `$' se usa cuando el comando puede ser ejecutado como un usuario normal; `#' significa que el comando requiere privilegios de superusuario. _______________________________________________________________________________________________________________El Proye* *cto de Documentacion de @ El Proyecto de Documentacion de Linux El Linux Documentation Project (Proyecto de Documentacion de Linux), o LDP, es un amplio equipo de escritores, revisores, y editores que estan trabajando juntos para facilitar documentacion completa para el sistema operativo Linux. El coordinador general de este proyecto es Matt Welsh, quien esta ayudado en gran medida por Lars Wirzenius y Michael K. Johnson. Este manual esta dentro de un grupo de varios que estan siendo distribuidos por el LDP, incluyendo una Guia de Usuarios de Linux, otra de Administradores de Sistemas, otra para Administradores de Red, y la Guia de Desarrolladores del Nucleo. Estos manuales estan disponibles en formato fuente LATEX, formato .dvi, y salida postscript por FTP anonimo desde nic.funet.fi, en el directorio /pub/OS/Linux/doc/doc-project, y desde tsx-11.mit.edu, en el directorio /pub/linux/docs/guides. Animamos a todo aquel con aficion a la escritura o a la edicion que se una a nosotros para mejorar la documentacion de Linux. Si tiene acceso a correo Internet, puede unirse al canal DOC de la lista de correo Linux-Activists enviando un correo a linux-activists-request@niksula.hut.fi con la linea X-Mn-Admin: join DOC en la cabecera o como primera linea del cuerpo del mensaje. Un correo vacio sin la linea de cabecera adicional hara que el servidor de correo devuelva un mensaje de ayuda. Para abandonar el canal, envie un mensaje a la misma direccion, incluyendo la linea X-Mn-Admin: leave DOC El Proyecto LinUx en CAStellano (LuCAS) La version en Castellano que tiene en sus manos es un fruto mas del proyecto LuCAS (LinUx en CAStellano). Es un proyecto para documentar el Linux en el idioma de Cervantes, coordinado inicialmente por Alfonso Belloso10 y actualmente por Juan Jose Amor11 e Ismael Olea12 . Los manuales que produce el grupo se encuentran disponibles en las paginas de WWW, http://lucas.hispalinux.es/ asi como en el servidor de FTP slug.ctv.es, _____________________________________________10 Alfonso esta localizable en alfon@iies.es 11Juan Jose esta disponible en la direccion jjamor@ls.fi.upm.es 12cuya direccion de correo es olea@iname.com _______________________________________________________________________________________________________________El Proye* *cto LinUx en CAStellano @ directorio pub/LuCAS. Parte del contenido de este servidor se encuentra reflejado en sunsite.unc.edu. En particular, este manual se encuentra en el directorio /pub/Linux/docs/linux-doc-project/network-guide/translations/es de esa maqui- na. El grupo LuCAS trabaja codo con codo, con el grupo INSFLUG (Impatient & Novatous Spanish Fido Linux User's Group), dedicado a la traduccion de documentos cortos HOWTO (COMOs); y coordinados por Francisco Jose Montilla13 . Sus trabajos pueden encontrarse en el servidor www.insflug.org asi como en el propio LuCAS. Si desea unirse al grupo, no dude en escribirnos. Mientras lo piensa, escuche un poco lo que se cuenta en la lista de correo que mantenemos: escriba a lucas- request@hispalinux.es un mensaje con la orden subscribe. _____________________________________________13 La direccion electronica de Francisco Jose es pacopepe@insflug.org _______________________________________________________________________________________________________________Estandar* *es de Sistema de Fichero@ Estandares de Sistema de Ficheros En el pasado, uno de los problemas que aquejaban las distribuciones de Linux, asi como los paquetes separados, era que no habia ununico sistema de ficheros aceptado. Esto generaba incompatibilidades entre paquetes diferentes, y enfrentaba a usuarios y administradores con la tarea de localizar varios programas y ficheros. Para mejorar esta situacion, en Agosto de 1993, varias personas formaron el Grupo del Estandar de Sistema de Ficheros de Linux o Grupo FSSTND para abreviar, coordinado por Daniel Quinlan. Despues de seis meses de discusion, el grupo presento un dise"no que muestra una estructura de sistema de ficheros coherente y define la localizacion de los programas mas esenciales y ficheros de configuracion. Este estandar se supone que va a implementarse en la gran mayoria de distribuciones y paquetes de Linux. A lo largo de este libro, ademas, asumiremos que todos los ficheros que se traten residen en el lugar especificado por este estandar; solo donde haya una larga tradicion que choque con esta especificacion se mencionaran emplazamientos alternativos. El Estandar de Sistema de Ficheros de Linux puede obtenerse de la mayoria de servidores FTP de Linux y sus imagenes; por ejemplo, puede encontrarlo en sunsite.unc.edu bajo /pub/linux/docs. Daniel Quinlan, coordinador del grupo FSSTND puede ser localizado en quinlan@bucknell.edu. Capitulo 1 Introduccion a las Redes 1.1 Historia La idea de red es probablemente tan vieja como la de las telecomunicaciones. Conside- remos a la gente que vivia en la edad de piedra, donde los tambores se habrian utilizado para transmitir mensajes entre individuos. Suponga que el cavernicola A quiere invitar al cavernicola B a un partido de lanzamiento de rocas contra el otro, pero viven demasiado lejos como para que B oiga a A golpear su tambor. >Cuales son las opciones de A? Podria 1) ir a la choza de B, 2) hacerse con un tambor mas grande, o 3) pedirle a C, que vive a mitad de camino entre los dos, que retransmita el mensaje. Laultima opcion es lo que se llama una red. Claro, que ya ha pasado un tiempo desde los primeros intentos de nuestros antepasados. Hoy en dia tenemos ordenadores que hablan entre si a traves de vastas conexiones de cables, fibrasopticas, microondas, y otros medios parecidos, para quedar para el partido del sabado. A continuacion trataremos sobre las maneras en que esto se realiza, pero olvidandonos de los cables, asi como de la parte del partido. En esta Guia escribiremos sobre dos tipos de redes : las basadas en UUCP, y las basadas en TCP/IP. Estos son conjuntos de protocolos y paquetes de software que proporcionan medios para transportar datos entre dos ordenadores. En este capitulo veremos ambos tipos y discutiremos sus principios fundamentales. Definiremos una red como un conjunto de nodos que son capaces de comunicarse en- tre si, a menudo contando con los servicios de varios nodos especializados que conmutan datos entre los participantes. Los nodos suelen ser ordenadores, aunque no es necesario; podemos considerar tambien terminales X o impresoras inteligentes como nodos. Peque"nas 1 _______________________________________________________________________________________________________________1.2. R* *edes UUCP @ aglomeraciones de nodos tambien se llaman instalaciones.1 La comunicacion seria imposible sin algun tipo de lenguaje o codigo. En las redes de or- denadores, estos lenguajes son llamados colectivamente protocolos. Sin embargo, no deberia pensar en protocolos escritos, sino mas bien en el codigo de comportamiento altamente for- malizado que se observa cuando se encuentran los jefes de estado. De un modo muy similar, los protocolos usados por las redes de ordenadores no son sino normas muy estrictas para el intercambio de mensajes entre dos o mas nodos. 1.2 Redes UUCP UUCP es una abreviatura de Unix-to-Unix Copy (Copia de Unix a Unix). Comenzo siendo un paquete de programas para transferir ficheros sobre lineas serie, programar esas transfe- rencias, e iniciar la ejecucion de programas en el lugar remoto. Ha experimentado grandes cambios desde su primera implementacion a finales de los setenta, pero aun es bastante espartano en los servicios que ofrece. Su principal aplicacion es todavia en redes dearea metropolitana (WAN) basadas en enlaces telefonicos. UUCP comenzo a desarrollarse por los Laboratorios Bell en 1977 para la comunicacion entre sus laboratorios de desarrollo de Unix. A mediados de 1978, esta red ya conectaba a mas de 80 centros. Se ejecutaban aplicaciones de correo electronico, asi como de impresion remota; sin embargo, el uso principal del sistema era distribuir software nuevo y mejo- ras.2 Hoy dia, UUCP ya no esta confinado en el entorno un?x. Hay versiones comerciales disponibles para diversas plataformas, incluyendo AmigaOS, DOS, TOS de Atari, etc. Una de las principales desventajas de las redes UUCP es su bajo ancho de banda. Por un lado, el equipo telefonico establece un limite rigido en la tasa maxima de transferencia. Por otro lado, los enlaces UUCP raramente son conexiones permanentes; en su lugar, los nodos se llaman entre si a intervalos regulares. Es por ello, que la mayoria del tiempo que le lleva a un mensaje viajar por una red UUCP permanece atrapado en el disco de algun nodo, esperando al establecimiento de la proxima conexion. A pesar de estas limitaciones, aun hay muchas redes UUCP funcionando en todo el mundo, utilizado principalmente por aficionados, ya que ofrecen acceso de red a usuarios privados a precios razonables. La razon fundamental de la popularidad del UUCP es que es baratisimo comparado con tener el ordenador conectado al Gran Cable de Internet. Para hacer de su ordenador un nodo UUCP, todo lo que necesita es un modem, software UUCP, y otro nodo UUCP que desee suministrarle correo y noticias. _____________________________________________1 N. del T.: Del ingles site 2 No parece que con el tiempo haya cambiado mucho esto. . . _______________________________________________________________________________________________________________1.2. R* *edes UUCP @ 1.2.1 Como usar UUCP La idea que hay detras de UUCP es bastante simple: como su nombre indica, basicamente copia ficheros de un nodo a otro, pero tambien permite realizar ciertas acciones en el nodo remoto. Suponga que le esta permitido que su maquina acceda a un nodo hipotetico llamado swim, y le va ha hacer ejecutar el comando de impresion lpr para Ud. Entonces, podria escribir lo siguiente en su linea de comandos para que le imprima este libro en swim:3 $ uux -r swim!lpr !netguide.dvi Esto hace que uux, un comando del repertorio UUCP, planifique un trabajo para swim. Este trabajo consta del fichero de entrada, netguide.dvi, y la peticion de enviar este fichero a lpr. La opcion -r indica a uux que no llame al sistema remoto inmediatamente, sino que almacene el trabajo hasta que se establezca la proxima conexion. A esto se le llama spooling, o almacenamiento en la cola. Otra propiedad de UUCP es que permite reenviar trabajos y ficheros a traves de varios nodos, suponiendo queestos colaboren. Asumiremos que swim, el nodo del ejemplo ante- rior, tiene un enlace UUCP con groucho, el cual mantiene un gran numero de aplicaciones un?x. Para transferir el fichero tripwire-1.0.tar.gz hasta su maquina deberia indicarlo asi: $ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz El trabajo creado pedira a swim que traiga el fichero desde groucho, y lo envie hasta su maquina, donde UUCP lo almacenara en trip.tgz y le notificara por correo la llegada del fichero. Esto ocurrira en tres pasos. Primero, su maquina envia el trabajo a swim. La siguiente vez que swim establezca contacto con groucho, se transferira el fichero de groucho a swim. El ultimo paso es la transferencia del mismo desde swim hasta su maquina. Los servicios mas importantes que proporcionan las redes UUCP hoy en dia son el correo electronico y las noticias. Lo introduciremos brevemente y despues lo veremos en mas detalle. El correo electronico - e-mail4 para abreviar - le permite intercambiar mensajes con usuarios de nodos remotos sin tener realmente que saber como acceder a estos nodos. La _____________________________________________3 Si usa bash, la shell GNU Bourne Again SHell, tendria que quitar los signos de exclamacion, porque los usa como su caracter de historico. 4 En el idioma castellano comienzan a aparecer adaptaciones mas o menos afortunadas, como e-milio _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ tarea de dirigir un mensaje desde su maquina destino la realiza enteramente el sistema de manejo de correo. En un entorno UUCP, el correo generalmente se transporta ejecutando el comando rmail en el nodo vecino, pasandole la direccion del receptor y el mensaje. rmail reenviara entonces el mensaje a otro nodo, y seguira asi, hasta que alcance el nodo destino. Veremos esto en detalle en el capitulo 13. La mejor forma de definir el servicio de noticias es considerarlo como un sistema de tablon de anuncios distribuido. Muy a menudo, este termino se refiere a las noticias de Usenet, que es, con mucho, la mas conocida red de intercambio de noticias, con un numero de nodos participantes estimado en 120.0005. Los origenes de Usenet se remontan a 1979, cuando, tras la aparicion del UUCP con el nuevo Unix V7, tres estudiantes graduados tuvieron la idea de un intercambio de informacion general entre la comunidad Unix. Estos escribieron algunos scripts, creando el primer sistema de noticias en red. En 1980, esta red conectaba duke, unc, y phs, y dos Universidades de Carolina del Norte, de forma aislada. Usenet crecio mas todavia posteriormente. Aunque su origen fue como una red basada en UUCP, ya no esta limitada a ununico tipo de redes. La unidad basica de informacion es el articulo, que puede ser enviado a una jerarquia de grupos de noticias dedicadas a temas especificos. La mayoria de los nodos reciben unicamente una seleccion de todos los grupos de noticias, que transportan una media de 60Mb6 de articulos por dia. En el mundo UUCP, las noticias generalmente se envian a traves de un enlace UUCP, recolectando todos los articulos de los grupos de noticias solicitados, y empaquetandolos en varios lotes7 . Estos se envian al lugar receptor, donde se pasan al comando rnews que los desempaqueta y procesa posteriormente. Finalmente, UUCP es tambien el medio elegido por muchos servidores de ficheros que ofrecen acceso publico. Generalmente podra acceder a ellos llamando con UUCP, accediendo como usuario invitado, y transferiendose los archivos desde unarea de ficheros publicamente accesible. Estas cuentas de invitado tienen, a menudo, un nombre de acceso y password como UUCP/nuucp o algo similar. 1.3 Redes TCP/IP Aunque UUCP puede resultar una eleccion razonable para enlaces de red mediante llamada de bajo coste, hay muchas situaciones en las que su tecnica de almacenamiento y reenvio se muestra demasiado inflexible, por ejemplo en Redes de Area Local (LANs, o RALs). Estas _____________________________________________5 Teniendo en cuenta que hace tiempo que se escribio este libro, es seguro que son muchos mas. 6 De nuevo son datos no actualizados 7 N. del T.: Del ingles batches _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ redes estan compuestas generalmente por un peque"no numero de maquinas localizadas en el mismo edificio, o incluso en la misma planta, que estan interconectadas para proporcionar un entorno de trabajo homogeneo. Es tipico que se quiera compartir ficheros entre estos nodos, o ejecutar aplicaciones distribuidas en diferentes maquinas. Estas tareas requieren una aproximacion completamente diferente a las redes. En lugar de reenviar ficheros completos con una descripcion del trabajo, todos los datos se fragmentan en peque"nas unidades (paquetes), que se envian inmediatamente al nodo destino, donde son reensamblados. Este tipo de redes son llamadas redes de intercambio de paquetes. Entre otras cosas, esto permite ejecutar aplicaciones interactivas a traves de la red. El coste de esto supone, por supuesto, una complejidad adicional al software. La solucion que han adoptado los sistemas un?x _ y muchos no-un?x _ es conocida como TCP/IP. En esta seccion echaremos un vistazo a sus conceptos basicos. 1.3.1 Introduccion a las Redes TCP/IP El TCP/IP tiene sus origenes en un proyecto de investigacion fundado en Estados Unidos por el DARPA (Defense Advanced Research Projects Agency, Agencia de Proyectos Avanzados de Investigacion en Defensa) en 1969. Esta fue una red experimental, la red ARPANET, que paso a ser operativa en 1975, despues de haber demostrado ser unexito. En 1983, fue adoptado como estandar el nuevo conjunto de protocolos TCP/IP, y todos los nodos de la red pasaron a utilizarlo. Cuando ARPANET por fin dio paso a Internet (con la propia ARPANET integrandose en su existencia en 1990), el uso del TCP/IP se habia extendido a redes mas alla de la propia Internet. Las mas destacables son las redes locales un?x, pero con la llegada de los equipos telefonicos digitales rapidos, como la RDSI, tambien tiene un futuro prometedor como transporte en redes telefonicas. Para ilustrar las explicaciones que demos en las siguientes secciones, tomaremos como ejemplo una red tipica: la de una universidad, concretamente la hipotetica Universidad Groucho Marx (GMU) situada, por ejemplo, en algun lugar de Libertonia. En esta univer- sidad, la mayoria de los departamentos mantienen sus propias redes dearea local, mientras que algunos comparten una, y otros poseen varias. Todos ellos estan interconectados, y estan enganchados a Internet a traves de un solo enlace de alta velocidad. Supongamos una maquina Linux conectada a una LAN de nodos un?x en el Departa- mento de Matematicas, y su nombre es erdos. Para acceder a un nodo del Departamento de Fisicas, por ejemplo quark, introducira el siguiente comando: $ rlogin quark.physics Last login: Mon Feb 2 21:06:19 on tty1 _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ Linux 2.0.0 #1 Sun Dec 7 19:07:05 MET 1997 (POSIX) [...] En la linea de comandos, introducira su nombre de acceso, pongamos que es andres, y su clave. Entonces dispondra de una shell de quark, sobre la que puede escribir como si estuviera sentado en la consola del sistema. Tras salir de la shell volvera a tener la linea de comandos de su propia maquina. Acaba de utilizar una de las aplicaciones de interactividad instantanea que proporciona TCP/IP: el acceso remoto. Mientras este conectado a quark, podria tambien desear ejecutar una aplicacion X, como un programa de dibujo de funciones, o un visor de Postscript. Para indicar a esta aplicacion que desea ver las ventanas en su monitor local, debe modificar la variable de entorno DISPLAY: $ export DISPLAY=erdos.maths:0.0 Si pone en marcha ahora su aplicacion, esta contactara con su servidor X en lugar del de quark, y mostrara todas las ventanas en su monitor. Por supuesto, esto requiere que este ejecutando X11 en erdos. La clave esta en que TCP/IP permite a quark y a erdos enviarse paquetes X11 en ambos sentidos para darle a Ud. la impresion de que esta en un unico sistema. La red es casi transparente en este caso. Otra aplicacion muy importante en redes TCP/IP es NFS, abreviatura de Network File System (Sistema de Ficheros de Red). Es otra forma de hacer trasparente la red, porque basicamente permite montar jerarquias de directorios de otras maquinas, de modo que aparezcan como sistemas de ficheros locales. Por ejemplo, todos los directorios "home", o personales, de los usuarios pueden estar en una maquina servidor central, desde la cual montan los directorios el resto de maquinas de la LAN. El efecto de esto es que los usuarios pueden acceder a cualquier maquina, y encontrarse a si mismos en el mismo directorio. De forma similar, es posible instalar aplicaciones que requieren gran cantidad de espacio en disco (tales como TEX) en unaunica maquina, y exportar estos directorios a otras maquinas. Volveremos sobre NFS en el capitulo 11. Por supuesto, esto son solo ejemplos de lo que se puede hacer en un entorno de redes TCP/IP: las posibilidades son casi ilimitadas. Ahora echaremos una mirada mas de cerca al modo en que trabaja TCP/IP. Esto es necesario para comprender como y por que tiene que configurar su maquina. Comenzaremos examinando el hardware, y poco a poco recorreremos todo el camino. _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ 1.3.2 Ethernets El tipo de hardware mas utilizado en LANs es lo que comunmente conocemos como Ethernet. Consta de un solo cable con los nodos colgando deel a traves de conectores, clavijas o transceptores. Las ethernet simples, son baratas de instalar, lo que unido a un flujo de transferencia neto de 10 Megabits por segundo avala gran parte de su popularidad. Hay tres tipos de Ethernet, en funcion de su cable, llamadas gruesas, finas y de par trenzado. Tanto el fino como el grueso utilizan cable coaxial, diferiendo en el grosor y el modo de conectar este cable a los nodos. El Ethernet fino emplea conectores "BNC" con forma de T, que se pinchan en el cable y se enganchan a los conectores de la parte trasera del ordenador. El Ethernet grueso requiere que realice un peque"no agujero en el cable, y conecte un transceptor utilizando un "conector vampiro". Entonces se pueden conectar uno o mas nodos al transceptor. Los cables Ethernet fino y grueso pueden alcanzar una distancia de 200 y 500 metros, respectivamente, y es por ello que se les llama tambien 10base-2 y 10base-5. El par trenzado usa un cable hecho de dos hilos de cobre como las que se encuentran en las instalaciones telefonicas ordinarias, pero generalmente necesitan hardware adicional. Tambien se conoce como 10base-T. A pesar de que a"nadir un nodo a una Ethernet gruesa es un poco lioso, eso no tirara abajo la red; sin embargo, para a"nadir un nodo en una instalacion de cable fino, se debe interrumpir el servicio de red al menos por unos minutos ya que se debe cortar el cable para insertar el conector. La mayoria de gente prefiere el Ethernet fino porque es barato: las tarjetas de PC pueden encontrarse por unos 50 dolares americanos (unas 5000 pesetas), o incluso menos, y el cable esta por unos centavos el metro. Sin embargo, para instalaciones de gran escala, es mas apropiado el Ethernet grueso. Por ejemplo, la Ethernet del Departamento de Matematicas de la GMU utiliza Ethernet gruesa, de modo que no se interrumpe el trafico cada vez que se a"nade un nodo a la red. Uno de los inconvenientes de la tecnologia Ethernet es su limitada longitud de cable, que imposibilita cualquier uso fuera de las LANs. Sin embargo, pueden enlazarse varios segmentos de Ethernet entre si utilizando repetidores, puentes o encaminadores8. Los repe- tidores simplemente copian las se"nales entre dos o mas segmentos, de forma que todos los segmentos juntos actuan como si fuese unaunica Ethernet. Debido a requisitos de tiempos, no puede haber mas de cuatro repetidores entre cualquier par de nodos de la red. Los puentes y encaminadores son mas sofisticados, analizan los datos de entrada y los reenvian solo si el nodo receptor no esta en la Ethernet local. Ethernet funciona como un sistema de bus, donde un nodo puede mandar paquetes (o _____________________________________________8 N. del T.: Respectivamente, repeaters, bridges y routers _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ tramas) de hasta 1500 bytes a otro nodo de la misma Ethernet. Cada nodo se direcciona por una direccion de seis bytes grabada en el firmware de su tarjeta Ethernet. Estas direcciones se especifican generalmente como una secuencia de numeros hexadecimales de dos digitos separados por dos puntos, como en aa:bb:cc:dd:ee:ff. Una trama enviada por una estacion la ven todas las estaciones conectadas, pero solo el nodo destinatario la toma y la procesa. Si dos estaciones intentan emitir al mismo tiempo, se produce una colision, que se resuelve por parte de las dos estaciones abortando el envio, y reintentandolo al cabo de un rato. 1.3.3 Otros tipos de Hardware En instalaciones mayores, como la Universidad de Groucho Marx, Ethernet no es elunico tipo de red que puede utilizarse. En la Universidad de Groucho Marx cada LAN de un departamento esta enlazada a la troncal del campus, que es un cable de fibraoptica funcio- nando en FDDI (Fiber Distributed Data Interface). FDDI emplea un enfoque totalmente diferente para transmitir datos, que basicamente implica el envio de un numero de testigos, de modo que una estacion solo pueda enviar una trama si captura un testigo. La principal ventaja de FDDI es una velocidad de hasta 100 Mbps, y una longitud de cable maxima de hasta 200 km. Para enlaces de red de larga distancia, se utiliza frecuentemente un tipo distinto de equipos, que se basa en el estandar X.25. Muchas de las llamadas Redes Publicas de Datos, como Tymnet en Estados Unidos, Datex-P en Alemania, o Iberpac en Espa"na, ofrecen este servicio. X.25 requiere un hardware especial, llamado Ensamblador/Desensamblador de Paquetes o PAD. X.25 define un conjunto de protocolos de red de derecho propio, pero sin embargo se usa frecuentemente para conectar redes bajo TCP/IP y otros protocolos. Ya que los paquetes IP no se pueden convertir de forma simple en X.25 (y viceversa),estos deben ser encapsulados en paquetes X.25 y enviados a traves de la red. Frecuentemente, los radioaficionados usan sus propios equipos de radio para conectar sus ordenadores en red; esto se llama packet radio o ham radio. El protocolo utilizado por el packet radio es el llamado AX.25, que deriva del X.25. Otras tecnicas implican el uso de las lentas pero baratas lineas serie para acceder bajo demanda. Esto requiere aun otros protocolos para la transmision de paquetes, como SLIP o PPP, que se describen mas adelante. _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ 1.3.4 El Protocolo IP (Internet Protocol) Por supuesto, Ud. no querra que su red este limitada a una Ethernet. Idealmente, Ud. desearia poder acceder a la red sin importarle ni el hardware del que dispone ni el numero de subestaciones. Por ejemplo, en instalaciones grandes como la Universidad de Groucho Marx, habra varias Ethernets separadas, que han de conectarse de alguna manera. En la GMU, el departamento de matematicas tiene dos Ethernets: una red de maquinas rapidas para profesores y graduados, y otra con maquinas mas lentas para estudiantes. Ambas redes estan colgadas de la red troncal FDDI del campus. Esta conexion se gestiona con un nodo dedicado, denominado pasarela, o gateway, que maneja los paquetes entrantes y salientes copiandolos entre las dos Ethernets y el cable de fibraoptica. Por ejemplo, si se encuentra en el Departamento de Matematicas, y quiere acceder a quark situada en la LAN del Departamento de Fisicas desde su maquina Linux, el software de red no puede mandar paquetes a quark directamente, porque no esta en la misma Ethernet. Por tanto, tiene que confiar en la pasarela para que actue como re- transmisor. La pasarela (llamemosla sophus) reenvia entonces estos paquetes a su pasarela homologa niels del Departamento de Fisicas, usando la troncal, y por fin niels los entrega a la maquina destino. El flujo de datos entre erdos y quark se muestra en la figura 1.1 (con disculpas a Guy L. Steele). Este esquema de envio de datos al nodo remoto se llama encaminamiento, y en este contexto a los paquetes se les denomina a menudo datagramas. Para facilitar las cosas, el intercambio de datagramas esta gobernado por un unico protocolo que es independiente del hardware utilizado: IP, o Internet Protocol. En el capitulo 2, trataremos el IP y el encaminamiento en mayor detalle. El principal beneficio del IP es que convierte a redes fisicamente distintas en una red aparentemente homogenea. A esto se le llama internetworking (interconexion de redes), y a la resultante "meta-red" se la denomina internet. Observe aqui la sutil diferencia entre una internet y La Internet. Elultimo es el nombre oficial de una internet global particular. Claro que el IP tambien necesita un esquema de direccionamiento independiente del hardware. Esto se consigue asignando a cada nodo un numerounico de 32 bits, que define su direccion IP. Una direccion IP se escribe normalmente como 4 numeros en decimal, uno por cada division de 8 bits, y separados por puntos. Por ejemplo, quark podria tener una direccion IP 0x954C0C04, que se escribiria como 149.76.12.4. A este formato se le llama notacion de puntos. Se dara cuenta de que ahora tenemos tres tipos distintos de direcciones: primero, te- nemos el nombre del nodo, quark, despues tenemos las direcciones IP, y por fin estan las direcciones hardware, como la direccion Ethernet de 6 bytes. De alguna forma todas ellas deben relacionarse, de modo que cuando escriba rlogin quark, se le pueda pasar la direc- _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ Dorsal del Campus (FDDI) 2 niels sophus Ethernet Fisicas Ethernet Matematicas 3 1 quark erdos Figura 1.1: Los tres pasos para enviar un datagrama desde erdos a quark. _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ cion IP al software de red; y cuando el nivel IP envie datos a la Ethernet del Departamento de Fisicas, de algun modo tiene que encontrar a que direccion Ethernet corresponde la direccion IP. Lo cual no resulta trivial. No entraremos en esto aqui, sino que lo dejamos para el capitulo 2. De momento, es suficiente con indicar que estos pasos para encontrar las direcciones se llaman resolucion de nombres, para mapear nombres de nodo con direcciones IP, y resolucion de direcciones, para hacer corresponder estasultimas con direcciones hardware. 1.3.5 IP en Lineas Serie, SLIP Para lineas serie se usa frecuentemente el estandar "de facto" conocido como SLIP o Serial Line IP (IP sobre linea serie). Una modificacion del SLIP es el CSLIP, o SLIP Comprimido, que realiza compresion de las cabeceras IP para aprovechar el bajo ancho de banda que proporcionan los enlaces serie.9 Un protocolo serie distinto es el PPP, o Point-to-Point Protocol (Protocolo Punto a Punto). PPP dispone de muchas mas caracteristicas que SLIP, incluyendo una fase de negociacion del enlace. Su principal ventaja sobre SLIP es, sin embargo, que no se limita a transportar datagramas IP, sino que se dise"no para permitir la transmision de cualquier tipo de datagramas. 1.3.6 El Protocolo de Control de Transmision, TCP Pero la historia no se acaba con el envio de datagramas de un nodo a otro. Si desea acceder a quark, necesita disponer de una conexion fiable entre su proceso rlogin en erdos y el proceso de shell en quark. Para ello, la informacion enviada en uno y otro sentido debe dividirse en paquetes en el origen, y ser reensamblada en un flujo de caracteres por el receptor. Esto que parece trivial, implica varias tareas complejas. Una cosa importante a saber sobre IP es que, por si solo, no es fiable. Suponga que diez personas de su Ethernet comienzan a transferirse laultima version de XFree86 del servidor de FTP de GMU. La cantidad de trafico generada por esto podria ser excesiva para que la maneje la pasarela, porque es demasiado lenta, y anda escasa de memoria. Si en ese momento Ud. envia un paquete a quark, sophus podria tener agotado el espacio del buffer durante un instante y por tanto no seria capaz de reenviarlo. IP resuelve este problema simplemente descartandolo. El paquete se pierde irrevocablemente. Lo cual traslada la responsabilidad de comprobar la integridad y exactitud de los datos a los nodos extremos, y su retransmision en caso de error. _____________________________________________9 SLIP esta descrito en la norma RFC 1055. La compresion de cabeceras CSLIP, basada en el, se describe en la RFC 1144. _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ De esto se encarga otro protocolo, TCP, o Transmission Control Protocol (Protocolo de Control de la Transmision), que construye un servicio fiable por encima de IP. La propiedad esencial de TCP es que usa IP para darle la impresion de una conexion simple entre los procesos en su equipo y la maquina remota, de modo que no tiene que preocuparse de como y sobre que ruta viajan realmente sus datos. Una conexion TCP funciona basicamente como una tuberia de doble sentido en la que ambos procesos pueden escribir y leer; puede imaginarla como una conversacion telefonica. TCP identifica los extremos de tal conexion por las direcciones IP de los dos nodos implicados, y el numero de los llamados puertos de cada nodo. Los puertos se pueden ver como puntos de enganche para conexiones de red. Si vamos a explotar el ejemplo del telefono un poco mas, uno puede comparar las direcciones IP con los prefijos dearea (los numeros representarian ciudades), y los numeros de puerto con los codigos locales (numeros que representan telefonos de personas concretas). En el ejemplo de rlogin, la aplicacion cliente (rlogin) abre un puerto en erdos, y se conecta al puerto 513 de quark, en el que se sabe que esta escuchando el servidor rlogind. Esto establece una conexion TCP. Usando esta conexion, rlogind realiza el procedimiento de autorizacion, y entonces muestra la shell. La entrada y salida estandar de la shell se redirigen a la conexion TCP, de modo que cualquier cosa que escriba a rlogin en su maquina sera pasado a traves del canal TCP y entregado a la shell como entrada estandar. 1.3.7 El Protocolo de Datagramas de Usuario, UDP Tambien es cierto que TCP no es elunico protocolo de usuario en redes TCP/IP. Aunque adecuado para aplicaciones como rlogin, la sobrecarga que impone es prohibitiva para apli- caciones como NFS. Por contra,este usa un protocolo derivado de TCP llamado UDP, o User Datagram Protocol (Protocolo de Datagramas de Usuario). De igual modo que TCP, UDP tambien permite que una aplicacion contacte con un servicio en un puerto concreto de la maquina remota, pero no establece una conexion para ello. En cambio, puede usarlo para enviar paquetes sueltos al servicio destino - de ahi su nombre. Suponga que ha montado la jerarquia del directorio TEX del servidor de NFS central del departamento, galois, y desea ver un documento que describe como usar LATEX. Arranca su editor, y lee el fichero completo. Sin embargo, le llevaria demasiado tiempo establecer una conexion TCP con galois, enviar el fichero, y liberarla de nuevo. En cambio, se hace una peticion a galois, que envia el fichero en un par de paquetes UDP, que es mucho mas rapido. Sin embargo, UDP no se hizo para controlar la perdida o corrupcion de paquetes. Es responsabilidad de la aplicacion - en este caso NFS - tener en cuenta esto. _______________________________________________________________________________________________________________1.3. R* *edes TCP/IP @ 1.3.8 Mas sobre Puertos Los puertos se pueden ver como puntos de anclaje para conexiones de red. Si una aplicacion quiere ofrecer un cierto servicio, se engancha a un puerto y espera a los clientes (a esto tambien se le llama escuchar en un puerto). Un cliente que quiera usar este servicio consigue un puerto libre en su nodo local, y se conecta al puerto del servidor en el nodo remoto. Una propiedad importante de los puertos es que una vez que se ha establecido una conexion entre el cliente y el servidor, otra copia del servidor puede engancharse al puer- to servidor y esperar a mas clientes. Esto permite, por ejemplo, varios accesos remotos simultaneos al mismo nodo, usando todos ellos el mismo puerto 513. TCP es capaz de distinguir unas conexiones de otras, ya que todas ellas provienen de diferentes puertos o nodos. Por ejemplo, si accede dos veces a quark desde erdos, entonces el primer cliente rlogin usara el puerto local 1023, y el segundo usara el puerto numero 1022; sin embargo, ambos se conectaran al mismo puerto 513 de quark. Este ejemplo muestra el uso de puertos como puntos de encuentro, donde un cliente contacta con un puerto especifico para obtener un servicio especifico. Para que un cliente sepa el numero de puerto adecuado, se ha tenido que llegar a un acuerdo entre los admi- nistradores de los dos sistemas para asignar estos numeros. Para servicios ampliamente usados, como rlogin, estos numeros tienen que administrarse centralmente. Esto lo realiza el IETF (o Internet Engineering Task Force), que regularmente publica un RFC (Request For Comment) denominado Assigned Numbers (Numeros Asignados). Describe, entre otras cosas, los numeros de puerto asignados a servicios reconocidos. Linux utiliza un fichero que mapea nombres con numeros, llamado /etc/services. Se describe en la seccion 9.3. Merece la pena indicar que aunque las conexiones TCP y UDP se basan en puertos, estos numeros no entran en conflicto. Esto significa que el puerto TCP 513, por ejemplo, es diferente del puerto UDP 513. De hecho, estos puertos sirven como puntos de acceso para dos servicios diferentes, como rlogin (TCP) y rwho (UDP). 1.3.9 La Libreria de Sockets En sistemas operativos un?x, el software que realiza todas las tareas y protocolos descri- tos anteriormente es generalmente parte del kernel, y por tanto tambien del de Linux. El interface de programacion mas comun en el mundo un?x es la Libreria de Socket de Ber- keley, Berkeley Socket Library. Su nombre proviene de una analogia popular que ve los puertos como enchufes, y conectarse a un puerto como enchufarse. Proporciona la llamada bind(2) para especificar un nodo remoto, un protocolo de transporte, y un servicio al que un programa pueda conectarse o escuchar (usando connect(2), listen(2), y accept(2)). La libreria de sockets, sin embargo, es algo mas general, ya que proporciona no solo una clase _______________________________________________________________________________________________________________1.4. R* *edes con Linux @ de sockets basados en TCP/IP (los sockets AF_INET ), sino tambien una clase que maneja conexiones locales a la maquina (la clase AF_UNIX ). Algunas implementaciones pueden manejar tambien otras clases, como el protocolo XNS ((Xerox Networking System), o X.25. En Linux, la libreria de sockets es parte de la libreria C estandar libc. Actualmente solo soporta los sockets AF_INET y AF_UNIX, pero se hacen esfuerzos para incorporar el soporte de los protocolos de red de Novell, de modo que se a"nadirian eventualmente una o mas clases de sockets. 1.4 Redes con Linux Siendo el resultado del esfuerzo concentrado de programadores de todo el mundo, Linux no habria sido posible sin la red global. Asi que no sorprende que ya en los primeros pasos del desarrollo, varias personas comenzaran a trabajar para dotarlo de capacidades de red. Casi desde el principio existia ya una implementacion de UUCP para Linux; y fue en el oto"no de 1992 cuando se comenzo a desarrollar el soporte de TCP/IP, cuando Ross Biro y otros crearon lo que ahora se conoce como Net-1. Despues de que Ross dejara el desarrollo activo en Mayo de 1993, Fred van Kempen comenzo a trabajar en una nueva implementacion, reescribiendo gran parte del codigo. Este esfuerzo continuado se conoce como Net-2. En el verano de 1992 salio la primera version publica de Net-2d (como parte del kernel 0.99.10), y ha sido mantenida y ampliada por varias personas, muy especialmente por Alan Cox, dando lugar al Net-2Debugged. Tras una dura correccion y numerosas mejoras en el codigo, cambio su nombre a Net-3 despues de que saliese Linux 1.0. Esta es la version del codigo de red que se incluye actualmente en las versiones oficiales del kernel. Net-3 ofrece controladores de dispositivo para una amplia variedad de tarjetas Ethernet, asi como SLIP (para enviar trafico de red sobre lineas serie), y PLIP (para lineas paralelo). Con Net-3, Linux tiene una implementacion de TCP/IP que se comporta muy bien en entor- nos de red dearea local, mostrandose superior a algunos de los Unix comerciales para PCs. El desarrollo se mueve actualmente hacia la estabilidad necesaria para su funcionamiento fiable en nodos de Internet. Ademas de estas facilidades, hay varios proyectos en marcha que mejoraran la versatili- dad de Linux. Un controlador para PPP (el protocolo punto a punto, otra forma de enviar trafico de red sobre lineas serie) esta en estado Beta actualmente, y otro controlador AX.25 para ham radio esta en estado Alfa. Alan Cox tambien ha implementado un controlador para el protocolo IPX de Novell, pero el esfuerzo para un paquete de red completo compa- tible con el de Novell se ha paralizado por el momento, debido a la negativa de Novell a facilitar la documentacion necesaria. Otro proyecto muy prometedor es samba, un servidor _______________________________________________________________________________________________________________1.4. R* *edes con Linux @ de NetBIOS gratis para Unix, escrito por Andrew Tridgell.10 1.4.1 Diferentes Etapas de Desarrollo Mientras tanto, Fred siguio desarrollando, continuando con el Net-2e, que dispone de un dise"no mas revisado de la capa de red. En el momento de escribir esto, Net-2e es aun software Beta. Lo mas notable sobre Net-2e es la incorporacion del DDI, el Device Driver Interface (Interface del controlador de dispositivo). DDI ofrece un acceso y un metodo de configuracion uniforme a todos los dispositivos y protocolos de red. Otra implementacion mas de red TCP/IP es la realizada por Matthias Urlichs, quien escribio un controlador de RDSI para Linux y FreeBSD. Para ello, integro algo del codigo de red de BSD en el kernel de Linux. En un futuro previsible, sin embargo, Net-3 parece que llegara para quedarse. Alan tra- baja actualmente en una implementacion del protocolo AX.25 usado por radioaficionados. Sin duda, la modularizacion, aun por desarrollar para el kernel, traera tambien nuevos im- pulsos al codigo de red. Los modulos le permiten a"nadir controladores al kernel en tiempo de ejecucion. Aunque todas estas diferentes implementaciones de red intentan dar el mismo servicio, hay grandes diferencias entre ellas a nivel de kernel y dispositivos. Ademas, no podra con- figurar un sistema con un kernel Net-2e con utilidades de Net-2d o Net-3, y viceversa. Esto solo se aplica a comandos que tienen mucho que ver con el funcionamiento interno del ker- nel; las aplicaciones y los comandos de red comunes como rlogin o telnet se ejecutan en cualquiera de ellos. A pesar de todo, todas estas diferentes versiones de red no deben preocuparle. A no ser que este participando en el desarrollo activo, no tendra que preocuparse de que version del codigo TCP/IP esta utilizando. Las versiones oficiales del kernel siempre estaran acom- pa"nadas de un conjunto de herramientas de red que son compatibles con el codigo de red presente en el propio kernel. 1.4.2 Donde Conseguir el Codigo Laultima version del codigo de red Linux se puede obtener mediante FTP anonimo de varios sitios. El servidor oficial del Net-3 es sunacm.swan.ac.uk, copiado en sunsite.unc.edu en el directorio system/Network/sunacm. Elultimo parche para el Net-2e y los binarios _____________________________________________10 NetBIOS es el protocolo en el que se basan las aplicaciones como lanmanager y Windows para Trabajo en Grupo. _______________________________________________________________________________________________________________1.5. M* *antenimiento del Sistema@ se encuentran disponibles en ftp.aris.com. El codigo de red basado en BSD de Matthias Urlichs se puede conseguir en ftp.ira.uka.de, directorio /pub/system/linux/netbsd. Se pueden encontrar los ultimos kernels en nic.funet.fi, en el directorio /pub/OS/Linux/PEOPLE/Linus; Los nodos sunsite y tsx-11.mit.edu tienen copias de este directorio. 1.5 Mantenimiento del Sistema En este libro, vamos a tratar principalmente los temas de instalacion y configuracion. Sin embargo la administracion es mucho mas importante _ despues de instalar un servicio, tambien hay que mantenerlo funcionando. Para la mayoria de ellos, solo se necesitara una peque"na atencion, mientras que algunos, como el correo y las news, requieren realizar tareas rutinarias para mantener actualizado el sistema. Discutiremos estas tareas en los capitulos finales. La tarea minima de mantenimiento es comprobar regularmente el sistema y los ficheros de registro de cada aplicacion buscando condiciones de error y eventos inusuales. Por lo general, es posible hacer esto escribiendo un par de scripts de shell y ejecutandolos periodicamente mediante el comando cron. La distribucion fuente de algunas aplicaciones importantes como smail o C News, ya contiene esos scripts. Solo tendra que retocarlos para adecuarlos a sus necesidades y preferencias. La salida de cualquiera de sus trabajos del cron se deberia enviar a una cuenta de administracion. Por defecto, muchas aplicaciones enviaran informes, estadisticas de uso, o resumenes del fichero de registro a la cuenta de root. Esto solo tiene sentido si accede como root frecuentemente; una idea mucho mejor es redirigir el correo del root a su cuenta personal estableciendo un alias de correo como se describe en el capitulo 14. Por muy cuidadoso que sea configurando su maquina, la ley de Murphy garantiza que surgira algun problema en cualquier momento. Por lo tanto, el mantenimiento de un sis- tema implica tambien estar disponible para quejas. Generalmente la gente espera que se pueda contactar con el administrador del sistema al menos por correo electronico (como root), pero tambien hay otras direcciones que se usan con frecuencia para informar a la persona responsable de un aspecto concreto del mantenimiento. Por ejemplo, las quejas so- bre una configuracion de correo que funciona mal se dirigiran generalmente al postmaster (encargado del correo); y los problemas con el sistema de noticias pueden ser comunicados a newsmaster o usenet. El correo a hostmaster se deberia redirigir a la persona encargada de los servicios basicos de red del nodo, y del servicio de nombres DNS si esta corriendo un servidor de nombres. _______________________________________________________________________________________________________________1.5. M* *antenimiento del Sistema@ 1.5.1 Seguridad del Sistema Otro aspecto muy importante de la administracion de sistemas en un entorno de red es pro- teger al sistema y a sus usuarios de intrusos. Los sistemas administrados sin ningun cuidado ofrecen muchos huecos a los malintencionados: los ataques van desde averiguar las claves hasta acceder a nivel de Ethernet, y el da"no causado puede ser desde mensajes de correo falsos hasta perdida de datos o violacion de la privacidad de los usuarios. Mencionaremos algunos problemas concretos cuando discutamos el contexto en el que pueden ocurrir, y algunas defensas comunes contra ellos. Esta seccion comentara algunos ejemplos y tecnicas basicas para pelearse con la seguri- dad del sistema. Por supuesto, los temas relatados no pueden tratar exhaustivamente todos los aspectos de seguridad con los que uno se puede encontrar; sirven meramente para ilus- trar los problemas que pueden surgir. Por tanto, la lectura de un buen libro sobre seguridad es absolutamente obligada, especialmente en un sistema en red. "Practical UNIX Security" de Simon Garfinkel (vease [Spaf93 ]) es una de las lecturas recomendadas. La seguridad del sistema comienza con una buena administracion del mismo. Esto inclu- ye comprobar la propiedad y permisos de todos los ficheros y directorios vitales, monitorizar el uso de cuentas privilegiadas, etc. El programa COPS, por ejemplo, comprobara su siste- ma de ficheros y ficheros de configuracion comunes en busca de permisos inusuales u otras anomalias. Tambien es conveniente usar un sistema de claves que fuerce ciertas reglas en las claves de los usuarios que las hagan dificiles de adivinar. El sistema de claves ocul- tas (shadow password), por ejemplo, requiere que una clave tenga al menos cinco letras, y contienen tanto mayusculas como minusculas y numeros. Cuando un servicio se hace accesible a la red, asegurese de darle el "menor privilegio", lo que quiere decir que no se permita hacer cosas que no son imprescindibles para que trabaje como se dise"no. Por ejemplo, deberia hacer sus programas con setuid root o alguna otra cuenta privilegiada solo si realmente lo necesitan. Tambien, si quiere usar un servicio solo para una aplicacion muy limitada, no dude en configuarla tan restrictivamente como su aplicacion especial lo permita. Por ejemplo, si quiere permitir a maquinas sin disco arrancar desde su maquina, debe facilitar el TFTP (Trivial File Transfer Service) de modo que pueda obtener los ficheros de configuracion basicos del directorio /boot. Sin embargo, cuando se usa sin restringir, TFTP permite a cualquier usuario de cualquier lugar del mundo leer cualquier fichero de su sistema. Si esto no es lo que desea, >por que no restringir el servicio TFTP al directorio /boot ?11 Pensando en la misma linea, podria restringir ciertos servicios a usuarios que acceden desde ciertos nodos, digamos que solo para su red local. En el capitulo 9, presentaremos tcpd, que hace esto para una variedad de aplicaciones de red. _____________________________________________11 Volveremos sobre esto en el capitulo 9. _______________________________________________________________________________________________________________1.6. V* *istazo a los Siguientes @ Otro punto importante es evitar software "peligroso". Claro que cualquier software que utilice puede ser peligroso, porque el software puede tener fallos que algunos listos pueden explotar para acceder a su sistema. Cosas comoesta ocurren, y no hay proteccion segura contra ello. Este problema afecta al software libre y a productos comerciales por igual. 12 Sin embargo, programas que requieren privilegio especial son inherentemente mas peligrosos que otros, ya que un agujero de estos puede tener consecuencias drasticas.13 Si instala un programa setuid con propositos de red, sea doblemente cuidadoso y no deje de leerse toda la documentacion, de modo que no cree una brecha en la seguridad por accidente. Nunca olvide que sus precauciones pueden fallar, por muy cuidadoso que haya sido. Por eso deberia asegurarse de que detecta pronto a los intrusos. Comprobar los ficheros de actividad es un buen comienzo, pero el intruso probablemente sea bastante listo, y borrara cualquier huella que haya dejado. Sin embargo, hay herramientas como tripwire14 que permite comprobar ficheros vitales del sistema para ver si sus contenidos o permisos han cambiado. tripwire realiza varios checksums15 fuertes sobre estos ficheros y los almacena en una base de datos. En las siguientes ejecuciones, se reevaluan y comparan los checksums con los almacenados para detectar cualquier modificacion. 1.6 Vistazo a los Siguientes Capitulos Los siguientes capitulos tendran que ver con configurar Linux para redes TCP/IP, y con la ejecucion de algunas aplicaciones importantes. Antes de que se manche las manos con la edicion de ficheros y similares, examinaremos IP algo mas de cerca en el capitulo 2. Si ya sabe como funciona el encaminamiento IP, y como se realiza la resolucion de direcciones, quiza desee saltarse este capitulo. El capitulo 3 trata los aspectos mas basicos de configuracion, como construir un kernel y configurar su tarjeta Ethernet. La configuracion de los puertos serie se relata en un capitulo aparte, ya que la discusion no se aplica solo a redes TCP/IP, sino que tambien es relevante para UUCP. El capitulo 5 le ayudara a configurar su maquina para redes TCP/IP. Contiene pasos de instalacion para nodos aislados (solamente con enlace local), y nodos conectados a una Ethernet. Tambien le presentara unas pocas herramientasutiles que puede utilizar para _____________________________________________12 Ha habido sistemas un?x comerciales, por los que hay que pagar un monton de dinero, que venian con un script de shell con setuid-root que permitia a los usuarios obtener privilegios de root utilizando un conocido truco. 13En 1988, el gusano RTM llevo a gran parte de Internet a un colapso, en parte por explotar un agujero que habia en algunos programas sendmail. Este agujero ya ha sido reparado con creces. 14Escrita por Gene Kim y Gene Spafford. 15N. del T.: Sumas de bytes con objeto de comprobar alguna modificacion no "autorizada" en el fichero. _______________________________________________________________________________________________________________1.6. V* *istazo a los Siguientes @ comprobar y retocar su configuracion. El siguiente capitulo expone como configurar la resolucion de nombres, y explica como montar un servidor de nombres. Esto va seguido de dos capitulos que tratan de la configuracion y uso de SLIP y PPP, respectivamente. El capitulo 7 explica como establecer conexiones SLIP, y da una referencia detallada de dip, una herramienta que le permite automatizar la mayoria de pasos necesarios. El capitulo 8 cubre PPP y pppd, el demonio que se necesita para ello. El capitulo 9 da una corta introduccion a la instalacion de las aplicaciones de red mas importantes, como rlogin, rcp, etc. Esto tambien abarca la gestion de los servicios por el inetd, y como puede restringir ciertos servicios de seguridad relevante a un grupo de nodos de confianza. Los dos capitulos siguientes hablan de NIS, el sistema de informacion de red (Network Information System), y NFS, el sistema de ficheros de red (Network File System). NIS es una herramientautil para distribuir informacion de administracion, como las claves de usuario, en red dearea local. NFS le permite compartir sistemas de ficheros entre varios nodos de su red. El capitulo 12 le dara una amplia introduccion a la administracion del UUCP de Taylor, una implementacion gratis del paquete UUCP. El resto del libro sera un viaje guiado por temas como el correo electronico y las Noticias de Usenet. El capitulo 13 le conduce a los conceptos centrales del correo electronico, como que aspecto tiene una direccion de correo, y como se las arregla el sistema de manejo de correo para llevar su mensaje hasta el destinatario. Los capitulos 14 y 15 cubren respectivamente la puesta en marcha de smail y sendmail, dos agentes de transporte de correo que puede utilizar en Linux. Este libro explica ambos, ya que smail es mas facil de instalar para un principiante, mientras que sendmail es mas flexible. Los capitulos 16 y 17 explican la forma en que se manejan las noticias en Usenet, y como instalar y usar C News, un paquete de software popular para la gestion de las noticias de Usenet. El capitulo 18 trata brevemente de como instalar un demonio NNTP para ofrecer el acceso a lectura de noticias para su red local. El capitulo 19 muestra finalmente como configurar y mantener varios lectores de noticias. Capitulo 2 Cuestiones sobre redes TCP/IP Vamos a entrar en los detalles que deben tenerse en cuenta cuando se conecta una maquina Linux a una red TCP/IP. De este modo, hablaremos de direcciones IP, nombres y cuestiones sobre el encaminamiento. Este capitulo le ense"nara la base con la que podra entender los pasos para su configuracion particular, pasos que son cubiertos exhaustivamente en otros capitulos. 2.1 Interfaces de Red Para ocultar la diversidad de hardware que puede usarse en una red, TCP/IP define una interfaz a traves de la cual accedemos al hardware. Esta interfaz ofrece un conjunto de ope- raciones identicas en cualquier tipo de hardware y que basicamente consisten en operaciones para enviar y recibir paquetes. Para cada dispositivo que quiera utilizarse para conectarse a la red, se mantendra en el nucleo del sistema la correspondiente interfaz. Por ejemplo, las interfaces con Ethernet en Linux son eth0 y eth1, mientras que las interfaces SLIP se llaman sl0, sl1, etcetera. Estos nombres de interfaz se deben conocer durante la configuracion de la red, cuando queramos referirnos a un dispositivo hardware concreto. Para que podamos usarlo en una red TCP/IP, la interfaz debera tener asignada una direccion IP que sirva como identificacion deesta ante los demas ordenadores de la red. Esta direccion es diferente del nombre de interfaz considerado anteriormente; puede realizarse la siguiente analogia: la interfaz seria la "puerta" de su sistema, mientras que la direccion vendria a ser un numero enmarcado y colgado de la "puerta". Por supuesto, hay otros parametros configurables para cada dispositivo, como el numero maximo de datagramas que pueden ser procesados por el dispositivo, conocido como Unidad 20 _______________________________________________________________________________________________________________2.2. D* *irecciones IP @ Maxima de Transferencia o MTU1. Otros parametros seran introducidos mas tarde. 2.2 Direcciones IP Como se dijo en el capitulo anterior, las direcciones utilizadas en el protocolo de red IP la forman numeros de 32 bits, y cada maquina debe tener una direccion propia. Si las maquinas se encuentran en una red TCP/IP que no se conecta a otras redes, dichas direcciones podran asignarse a las maquinas librememente. Sin embargo, si las maquinas se conectan a Internet, las direcciones de los ordenadores seran asignadas por una autoridad principal, el NIC2 o Centro de Informacion de la Red3. Para facilitar la lectura, las direcciones IP se dividen en cuatro numeros de 8 bits lla- mados octetos. Por ejemplo, si la maquina quark.physics.groucho.edu tiene una direc- cion IP 0x954C0C04, normalmente la escribiremos con la notacion de puntos divisorios, que separa los octetos, de esta forma: 149.76.12.4. Otra razon para usar esta notacion es que las direcciones IP se pueden dividir en el numero de red y el numero de nodo. Cuando pedimos al NIC un conjunto de direcciones, este organismo nos concedera, no una direccion para nuestra maquina, sino un rango de direcciones validas, que en realidad es un numero de red concreto (el numero de nodo lo pondremos nosotros, contando con todos esos nodos disponibles). Dependiendo del tama"no de la red, la parte de la direccion correspondiente al nodo puede ser mas o menos grande. Para adaptarse a diferentes necesidades, se conceden diferentes clases de redes, que definen diferentes maneras de dividir la direccion IP en parte de red y parte del nodo. Clase A La clase A comprende redes desde 1.0.0.0 hasta 127.0.0.0. El numero de red esta en el primer octeto, con lo que solo hay 127 redes de este tipo, pero cada una tiene 24 bits disponibles para identificar a los nodos, lo que se corresponde con poder distinguir en la red unos 16 millones de nodos distintos. Clase B La clase B comprende redes desde 128.0.0.0 hasta 191.255.0.0; siendo el numero de red de 16 bits (los dos primeros octetos). Esto permite 16320 redes de 65024 nodos cada una. _____________________________________________1 N. del T.: MTU son las siglas de "Maximum Transfer Unit". 2 N. del T.: Network Information Center 3 Frecuentemente, las direcciones IP le seran asignadas directamente por el proveedor que le conecte a la red. No obstante, se puede contactar directamente con el NIC para obtener direcciones, escribiendo a hostmaster@internic.net. _______________________________________________________________________________________________________________2.3. R* *esolucion de direcciones@ Clase C Las redes de clase C tienen el rango de direcciones desde 192.0.0.0 hasta 223.255.255.0, contando con tres octetos para identificar la red. Por lo tanto, hay cerca de 2 millones de redes de este tipo con un maximo de 254 nodos cada una. Clases D, E, y F Comprenden las direcciones entre 224.0.0.0 y 254.0.0.0, y estan reservadas para uso futuro, o con fines experimentales4. No especifican, pues, ninguna red de Internet. Volviendo al ejemplo del capitulo anterior, veremos que en la direccion 149.76.12.4 de la maquina quark, 12.4 es el identificativo del nodo dentro de la red de clase B 149.76.0.0. Se puede observar que en la lista anterior no se consideraban todas las posibilidades en la parte que identifica al nodo; concretamente, se excluian siempre el identificador 0 y el 255. Estos dos identificadores se reservan para propositos especiales. Una direccion con los bits del nodo a cero identifica a la red, mientras que si tiene todos los bits a uno, identifica a todos los nodos de la red (lo que se conoce como direccion de broadcast, lo que indica que un mensaje enviado a esa direccion sera procesado por todos los nodos de la red). Asi pues, en nuestro ejemplo la direccion de la red seria 149.76.0.0 y la de broadcast, la 149.76.255.255. Ademas, otras dos direcciones de red estan reservadas: la 0.0.0.0 y la 127.0.0.0. La primera se conoce como direccion de encaminamiento por defecto, y la segunda, como di- reccion de loopback. El encaminamiento por defecto se utiliza para saber a donde enviar los datagramas por defecto, tema que abordaremos despues. La red 127.0.0.0 se reserva para el trafico local, dirigido al propio nodo. Normalmente, se asigna la direccion 127.0.0.1 a un dispositivo de la maquina llamado interfaz de loopback 5 o de circuito cerrado. Cualquier paquete enviado a esa direccion sera recibido por el propio nodo. Esto permite probar aplicaciones de red con uno mismo, sin estar conectado a una red "real". Otra aplicacion util es la de ejecutar aplicaciones de red que afectan solo al nodo local. Por ejemplo, muchos sistemas UUCP no tienen conexion IP pero ejecutan un sistema de noticias INN. Para que esto funcione, INN utiliza la interfaz de loopback. 2.3 Resolucion de direcciones Ahora que conocemos que son las direcciones IP, nos preguntaremos como se utilizan en una red Ethernet. Despues de todo, el protocolo Ethernet usa direcciones identificativas de _____________________________________________4 Por ejemplo, se esta utilizando la red 224.0.0.0 para la Internet multidestino o multicast 5 N. del T.: Tambien conocida como interfaz de lazo _______________________________________________________________________________________________________________2.3. R* *esolucion de direcciones@ seis octetos que no tienen que ver con los numeros IP. En efecto, se necesita un mecanismo de traduccion de direcciones IP a direcciones Et- hernet o fisicas. Esto se hace con el Protocolo de Resolucion de Direcciones o ARP6. ARP no se limita a las redes Ethernet, sino que se extiende a otros tipos de redes como las de radio paquetes. La idea es la misma que tendriamos para localizar al se"nor X entre 150 personas: preguntar por su nombre a todo el mundo; y el se"nor X nos respondera. Cuando queremos localizar la direccion fisica correspondiente a una direccion IP, hare- mos uso de una caracteristica de la red Ethernet, que es la posibilidad de enviar mensajes a escuchar por todos los nodos, o mensajes broadcast. En el mensaje ARP, que es de este tipo, se incluye la direccion IP cuyo propietario estamos buscando. El nodo que posea esa direccion enviara una respuesta ARP al nodo llamante, con su direccion fisica. Por supuesto, le preocupara saber como puede funcionar esto para localizar un nodo entre millones de Ethernets conectadas en el mundo. Esto se trata en la proxima seccion: se trata del encaminamiento. Sigamos hablando, de momento, sobre ARP. Una vez que se conoce la direccion fisica del nodo, el que hizo la peticion guardara la informacion obtenida en una cache ARP, para asi no preguntar por lo mismo cada vez que envie un paquete a ese nodo. Sin embargo, no podemos guardar esa direccion para siempre ya que puede perder su validez (por ejemplo, si cambiamos la tarjeta de red a los nodos por averia, sus nuevas direcciones fisicas seran distintas). Por ello, cada cierto tiempo, lo que hay en la cache ARP pierde su validez, obligando a realizar de nuevo la pregunta ARP. A veces, un nodo necesita tambien conocer su direccion IP a partir de su direccion fisica. Por ejemplo, en terminales X o PCs sin disco, que cuando arrancan solo saben la direccion de su tarjeta pues esta grabada en memoria no volatil. Para ello, se usa el Protocolo de Resolucion Inversa de Direcciones o RARP7: la peticion RARP la hace el nodo cuando arranca, mediante mensaje broadcast, y es contestado por un servidor de direcciones que, a partir de la direccion fisica, consulta su base de datos y conoce la direccion IP correspondiente. Existe ademas otro protocolo, el BOOTP o protocolo de arranque8, que permite a las maquinas sin disco conocer como ponerse en marcha en la red. _____________________________________________6 N. del T.: Address Resolution Protocol 7 N. del T.: Reverse Address Resolution Protocol 8 N. del T.: Del ingles Boot Protocol _______________________________________________________________________________________________________________2.4* *. Encaminamiento IP @ 2.4 Encaminamiento IP 2.4.1 Redes IP 3 Cuando escribimos una carta a alguien, normalmente incluimos la direccion completa en el sobre: pais, provincia, codigo postal, etc. De este modo el servicio de correos podra llevar la carta a su destino: un servicio la enviara al del pais que corresponda, yesteultimo la entregara al de la provincia o ciudad de destino. La ventaja de este esquema jerarquico es que el servicio postal del remitente apenas tiene que saber acerca del destino final, sino solo a que pais entregarla. Las redes IP se organizan de manera similar. Internet consta de varias redes, conocidas como sistemas autonomos y cada una realiza por su cuenta el encaminamiento interno entre sus nodos miembro. Cuando un paquete tiene como destino un nodo de otra red, se entregara al encaminador correspondiente, sin preocuparse del destino final del paquete. 2.4.2 Subredes La estructura de subredes se obtiene al dividir las direcciones IP en parte del nodo y parte de la red, como ya hemos explicado. Por defecto, la red de destino se deriva de la parte de red de la direccion IP. Es decir, los nodos con la misma direccion de red se encontraran en la misma red TCP/IP9. Pero en una red puede interesar hacer una division en cientos de peque"nas redes, por ejemplo segmentos de Ethernet. Para ello se subdivide la red en subredes. Una subred tiene la responsabilidad de la entrega de los datagramas a un determinado rango de direcciones IP de la red en la que se encuentra. Como sucede con las clases A, B o C, se identifica en la parte del numero IP correspondiente a la red. Sin embargo, esa parte incluira ahora algunos bits de la parte del nodo. Los bits que se interpretan como direccion de subred se obtienen con la llamada mascara de red. Es un numero de 32 bits que especifica una mascara para identificar los bits de la subred. La red del campus de la Universidad de Groucho Marx es un ejemplo de red de clase B, poseedora de la red 149.76.0.0, con mascara 255.255.0.0. Internamente, la red de la UGM se divide en peque"nas subredes, como las LAN de cada departamento. Concretamente se divide en 254 subredes, desde la 149.76.1.0 hasta la 149.76.254.0. Por ejemplo, el Departamento de Fisica Teorica tendra asignada la subred 149.76.12.0. La dorsal del campus es en si mismo una subred, la 149.76.1.0. Las subredes _____________________________________________9 Los sistemas autonomos son algo mas generales. Pueden tener mas de una red IP. _______________________________________________________________________________________________________________2.4. E* *ncaminamiento IP @ Parte de la Red Parte del Nodo 149 76 12 4 149 76 12 4 Parte de la Red Parte del Nodo Figura 2.1: Division de una red clase B en subredes comparten el mismo numero de red, pero se usa el tercer octeto deesta para distinguir las distintas subredes. Por lo tanto, tendran una mascara de subred igual a 255.255.255.0. En la figura 2.1 se muestra como el nodo quark (149.76.12.4) se ve de distinta forma segun se vea desde el punto de vista de la red de clase B, o desde el punto de vista de las subredes. Notese que la division en subredes es visible solo internamente a la red. Normalmente las organiza el administrador de red para reflejar diferentes ubicaciones geograficas, distinguir segmentos de red, o bien por motivos administrativos (departamentos, redes de alumnos, etc). Pero esta division es totalmente invisible desde fuera de la organizacion. 2.4.3 Pasarelas La organizacion en subredes no solo se hace por motivos administrativos, tambien es con- secuencia de cuestiones del hardware. Lo que ve un nodo en una red es limitado: solo ve los nodos con los que directamente este conectado (por ejemplo, en la Ethernet), mientras que a los demas los accede a traves de lo que se conoce como pasarela10 , que no es mas que un nodo conectado a dos o mas redes fisicas, configurado para pasar paquetes de una red a otra. Para reconocer si una direccion IP se encuentra en la red local fisica, cada LAN debe tener una direccion de red IP diferente. Por ejemplo, las maquinas de la (sub)red 149.76.4.0 serian las que estan en la LAN del Departamento de Matematicas. Cuando se envia un datagrama a la maquina quark, el software de red de erdos ve que su direccion de red es otra (149.76.12.4) con lo que sabe que tiene que enviar los datagramas a traves de la pasarela (sophus por defecto). sophus se encuentra conectado a dos subredes: la del Departamento de Matematicas _____________________________________________10 N. del T.: Del ingles gateway _______________________________________________________________________________________________________________2.4. E* *ncaminamiento IP @ y la de la dorsal del campus, accediendo a cada una a traves de una interfaz diferente, respectivamente eth0 y fddi0. Nos preguntaremos entonces, que direccion IP debe tener la pasarela, una de la subred de Matematicas o bien una de la dorsal. Pues bien, la respuesta es ambas. Cuando la pasarela comunique con un nodo de la LAN de Matematicas, usara la direccion 149.76.4.1, mientras que si lo hace con un nodo de la dorsal, usara 149.76.1.4. Es decir, la pasarela tiene tantas direcciones IP como conexiones a redes fisicas tenga. En definitiva,este sera el esquema de interfaces, direcciones y mascara de sophus, nuestra pasarela: ____________________________________________________ | interfaz | direccion | mascara | |____________|______________|____________________|___ | eth0 |149.76.4.1 | 255.255.255.0 | | | | | | fddi0 |149.76.1.4 | 255.255.255.0 | | | | | | lo | 127.0.0.1 | 255.0.0.0 | |_____________|____________|____________________|___ Laultima entrada describe el dispositivo loopback, que se comento anteriormente. En la figura 2.2 se muestra una parte de la topologia de la red de la Universidad de Groucho Marx (UGM). Los nodos que estan en dos subredes tendran dos direcciones IP. 2.4.4 Tablas de Encaminamiento Vamos ahora a centrarnos en como se selecciona una pasarela para entregar un datagrama a una red remota. Hemos visto que erdos, cuando envia un datagrama para quark, comprueba que la direccion destino no se encuentra en la red local, por lo que lo envia a la pasarela, sophus, quien basicamente hace lo mismo: ve que quark no esta en una de las redes a las que se conecta directamente y busca otra pasarela a quien entregarle el paquete. La eleccion correcta es niels, la pasarela del Departamento de Fisicas. sophus necesita informacion para poder tomar estas decisiones. La informacion de encaminamiento que se usa en IP es basicamente una tabla donde se relacionan (sub)redes y pasarelas. Ademas, debe incluirse una entrada de encaminamiento por defecto, que se asocia en la tabla a la red 0.0.0.0. Todos los paquetes que van a una red desconocida, se enviaran a la pasarela del encaminamiento por defecto. Asi pues,esta seria la tabla para sophus: _______________________________________________________________________________________________________________2.4. E* *ncaminamiento IP @ Departamento de Matematicas Departamento de Fisica Teorica 4.23 4.17 12.4 4.0 12.0 gauss erdos quark 4.1 12.1 sophus niels 1.4 1.12 Dorsal del Campus 1.1 gcc1 2.1 1.0 Centro de Calculo de la UGM Figura 2.2: Vista parcial de la topologia de la red de la UGM. _______________________________________________________________________________________________________________2.4. E* *ncaminamiento IP @ _______________________________________________ | Red | Pasarela | Interfaz | |________________|______________|_____________|__ | 149.76.1.0 | - |fddi0 | | | | | | 149.76.2.0 | 149.76.1.2 | fddi0 | | | | | | 149.76.3.0 | 149.76.1.3 | fddi0 | | | | | | 149.76.4.0 | - |eth0 | | | | | | 149.76.5.0 | 149.76.1.5 | fddi0 | | | | | | . . . .|. . |. . . | | | | | | 0.0.0.0 | 149.76.1.2 | fddi0 | |________________|_____________|_____________|_ Las rutas a una red a la que sophus este directamente conectado no necesitan pasarela, sino que los datagramas se entregan directamente. Esto se indica en la tabla anterior cuando en lugar de la pasarela aparece un "-". Las tablas de encaminamiento pueden construirse de varias formas. Para redes pe- que"nas, sera mas eficiente construirlas a mano usando el comando route de Linux (vease el capitulo 5). Para redes mas grandes, las tablas se mantienen y modifican automaticamente mediante los demonios de encaminamiento. Estos corren en nodos centrales e intercambian informacion de encaminamiento entre ellos para tener en todo momento las rutas "optimas" entre subredes. Dependiendo del tama"no de la red, se utilizan distintos protocolos de encaminamien- to. Dentro de los sistemas autonomos (como la Universidad Groucho Marx) se utilizan los protocolos internos o IGP11 . El mas utilizado es RIP12 o protocolo de informacion de encaminamiento, que implementa el demonio routed de BSD. Para encaminamiento entre redes se usan protocolos EGP13 , como BGP. Se implementan en programas como gated de la Universidad de Cornell.14 . 2.4.5 Metricas de Encaminamiento El encaminamiento dinamico basado en RIP elige la mejor ruta a un determinado nodo o red a partir del numero de "saltos", es decir, las pasarelas que tiene que atravesar el datagrama hasta llegar a su destino. La ruta mas corta sera la elegida, y si hay 16 o mas saltos se descartara por exceso de distancia. Para usar RIP tiene que ejecutar gated en todas las maquinas. Al arrancar, gated comprueba cuantas interfaces estan activas. Si hay mas de una (sin contar la de loopback) asumira que el nodo es una pasarela. Si no, entrara en modo pasivo, dedicandose a recibir cualquier actualizacion RIP y cambiando sus tablas en consecuencia. _____________________________________________11 N. del T.: Internal Gateway Protocol 12N. del T.: Routing Information Protocol 13N del T.: External Gateway Protocol 14gated tambien implementa RIP y en general se recomienda usarlo en lugar de routed _______________________________________________________________________________________________________________2.5* *. Protocolo de Mensajes de @ Para enviar a las demas pasarelas la informacion de su tabla local de rutas, gated cuenta la longitud de cada una a partir de una metrica especifica (que es decidida por el admi- nistrador del sistema y debe reflejar el coste de esa ruta). Asi, la metrica de una ruta a una subred con conexion directa sera siempre cero, mientras que una ruta que atraviese dos pasarelas debera tener un coste de dos. 2.5 Protocolo de Mensajes de Control de Internet (ICMP) IP tiene otro protocolo aun no mencionado. Es el protocolo de mensajes de control de Internet o ICMP15 , y lo usa el software de gestion de red para comunicar mensajes de error entre nodos. Por ejemplo, si estamos en la maquina erdos y hacemos un telnet al puerto 12345 del nodo quark y no hay procesos escuchando en ese puerto, recibira un mensaje ICMP de "puerto inalcanzable". Hay mas mensajes ICMP, muchos de ellos referidos a condiciones de error. Sin embargo, hay uno interesante que es el de redireccion. Lo genera el modulo de encaminamiento al detectar que otro nodo esta usandolo como pasarela, a pesar de existir una ruta mucho mas corta. Por ejemplo, tras configurarse la tabla de encaminamiento de sophus, esta puede estar incompleta, conteniendo rutas a traves del encaminador por defecto gcc1. Por lo tanto, los paquetes enviados inicialmente a quark iran por gcc1 en lugar de niels. En este caso gcc1 notificara a sophus que esta usando una ruta costosa y reenviara el datagrama a niels, al mismo tiempo que devolvera un mensaje ICMP de redireccion a sophus informandole de la nueva ruta. Con lo visto, queda claro que se puede evitar tener que establecer las rutas a mano. Sin embargo, usar solo esquemas de encaminamiento dinamico no es siempre una buena idea. La redireccion de ICMP y el protocolo RIP no incluyen mecanismos de verificacion de la autenticidad de los mensajes. Esto permite a los piratas corromper el trafico de la red mediante mensajes ICMP. Por ello, algunas versiones del codigo de Linux tratan los mensajes de redireccion que afectan a rutas de red como si fueran redirecciones de rutas a nodos. 2.6 El sistema de nombres DNS 2.6.1 Resolucion de nombres 3 Como se comento antes, el direccionamiento en TCP/IP se basa en numeros de 32 bits. Evidentemente, esos numeros no son faciles de recordar, mientras que si lo es el nombre que _____________________________________________15 N. del T.: Internet Control Message Protocol _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ se le asigna a cada maquina, como gauss o strange. Existe una aplicacion que es capaz de traducir nombres a direcciones IP, y es conocida como sistema de resolucion de nombres o DNS16 . Una aplicacion que desee encontrar la direccion IP correspondiente a una maquina de la que conoce su nombre, no tiene que incluir rutinas para ello, ya que en las librerias estandares (libc) existen ya rutinas preparadas, como gethostbyname(3) o gethostbyaddr(3). En otros sistemas se encuentran en otras librerias distintas de la libc pero esto no sucede en Linux. Al conjunto de rutinas que hacen estas tareas se les conoce como "sistema de resolucion". En una red peque"na no es dificil mantener una tabla /etc/hosts en cada maquina, y modificarla al agregar, eliminar o modificar nodos. Pero resulta complicado cuando hay muchas maquinas ya que, en principio, cada una necesita una copia de /etc/hosts. Una solucion a esto es compartiresta y otras bases de datos con el NIS, o sistema de informacion de red 17, desarrollado por Sun Microsystems y conocido tambien como paginas amarillas. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS central y los clientes accederan a ellas de forma transparente al usuario. En todo caso, esta solucion solo es aconsejable para redes peque"nas o medianas, ya que implican mantener un fichero central /etc/hosts que puede crecer mucho, y luego distribuirlo entre los servidores NIS. En Internet, se comenzo almacenando la informacion en un fichero similar al hosts, mantenido por el NIC, y obtenido regularmente por los demas servidores. Cuando la red crecio comenzaron los problemas de sobrecarga de servidores, ademas de que el NIC tenia que ocuparse de todos los nombres de los nodos de Internet, y evitar la duplicidad de los mismos. Por esto, en 1984 se dise"no y adopto oficialmente un nuevo sistema, el DNS o sistema de nombres por dominios, dise"nado por Paul Mockapetris. 2.6.2 Introduccion al DNS DNS organiza los nombres de los nodos en una jerarquia de dominios. Un dominio es una coleccion de nodos relacionados de alguna manera, como estar en la misma red o pertenecer a una misma organizacion o pais. Por ejemplo, las universidades norteamericanas se agrupan en el dominio edu, y cada universidad mantiene un subdominio dentro de edu. Nuestro ejemplo, la Universidad de Groucho Marx, mantendria el dominio gmu.edu y las maquinas del departamento de Matematicas se encontrarian dentro del dominio maths.gmu.edu. _____________________________________________16 N. del T.: Domain Name System 17N. del T.: Network Information System _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ De este modo el nombre completo de la maquina erdos sera erdos.maths.gmu.edu. El nombre completo se conoce como nombre totalmente cualificado o FQDN18 , e identifica a ese nodo en todo el mundo. . com edu net groucho maths physics gauss erdos sophus theory collider quark otto niels up down strange Figura 2.3: Parte del espacio de dominios En la figura 2.3 se muestra una seccion del espacio de dominios. La entrada de la raiz delarbol, que se indica con un punto, se puede denominar dominio raiz, y agrupa al resto de los dominios. Para indicar que un nodo se expresa en notacion FQDN, se puede terminar el nombre en un punto, indicando asi que el nombre incluye al del dominio raiz. Dependiendo de su localizacion en la jerarquia, un dominio puede ser de primer, segundo o tercer nivel. Pueden existir otros niveles pero no son frecuentes. Por ejemplo, algunos dominios de primer nivel muy usuales son los siguientes: edu Aqui se incluyen casi todas las universidades o centros de investigacion nor- teamericanos. com Compa"nias u organizaciones con fines comerciales. org Organizaciones no comerciales. Las redes UUCP privadas se encuentran aqui. net Pasarelas y otros nodos administrativos de la red. mil Nodos militares norteamericanos. _____________________________________________18 N. del T.: Fully Qualified Domain Name _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ gov Nodos del gobierno norteamericano. uucp Oficialmente, todos los nombres de nodos UUCP sin dominio han sido mo- vidos a este nuevo dominio, .uucp. En general, los dominios anteriores pertenecen a redes norteamericanas. Algo especial- mente cierto con los dominios mil o gov. Fuera de los Estados Unidos, existe un dominio de primer nivel para cada pais, de dos letras segun se define en la norma ISO-3166. Finlandia, por ejemplo, usa el dominio fi; el dominio de corresponde a Alemania y el dominio es corresponde a Espa"na. Cada pais organiza por debajo del primer nivel, los dominios de segundo nivel, de manera parecida a los americanos en algunos casos (por ejemplo, con dominios com.au o edu.au) o directamente por organizaciones, como sucede en Espa"na (con dominios como upm.es para la Universidad Politecnica de Madrid). Por supuesto, un nodo dentro del dominio de un pais puede no estar fisicamente enel. El dominiounicamente identifica al nodo como registrado en el NIC de ese pais. Asi, un comerciante sueco puede tener una delegacion en Australia, y tener sus nodos australianos registrados dentro del dominio de primer nivel sueco, se. Esta organizacion por dominios soluciona el problema de la unicidad de nombres. Ademas, los nombres totalmente cualificados no son dificiles de recordar. Pero DNS tiene otras ventajas: permite delegar la autoridad sobre un determinado subdominio a sus administradores. Por ejemplo, los subdominios maths y physics de la UGM son creados y mantenidos por el Centro de Calculo de dicha universidad. Y si el mantenimiento del subdominio maths.gmu.edu fuese complicado (por numero elevado de nodos, existencia de subdominios internos, etc), el Centro de Calculo de la UGM puede delegar la autoridad sobre ese subdominio al departamento de Matematicas. La delegacion de un subdominio implica el control total del mismo por parte de la organizacion en la que se delego, con total libertad para crear nuevos subdominios internos, asociar nombres a nodos, etc. Para este fin, el espacio de nombres se divide en zonas, cada una asociada a un do- minio. Notese que existe una diferencia entre zona y dominio: el dominio groucho.edu incluye todos los nodos de la UGM, mientras que la zona groucho.edu incluye solo los nodos que mantiene directamente el Centro de Calculo, ya que los nodos del subdominio physics.groucho.edu pertenecen a la zona controlada por el Departamento de Fisicas. En la figura 2.3 se marca el inicio de una zona con un peque"no circulo a la derecha del nombre del dominio. _______________________________________________________________________________________________________________2.6. * *El sistema de nombres DNS@ 2.6.3 Busquedas de nombres con DNS Trataremos aqui el problema de como resolver el nombre de un determinado nodo. DNS es una gigantesca base de datos distribuida. Se implementa a traves de los llamados servidores de nombres. Cada uno deestos mantiene la informacion de uno o varios dominios. Para cada zona hay al menos dos (o mas) servidores de nombres que mantienen informacion autorizada sobre los nodos de esa zona. Para obtener la direccion IP del nodo erdos, lo que hay que hacer es contactar con el servidor de nombres de la zona para groucho.edu y este nos devolvera los datos pedidos. Esto parece facil de decir pero dificil de implementar pues nos preguntaremos como localizar al servidor de nombres de la UGM. Si su ordenador no implementa un adivi- no, le ayudara el DNS. Cuando su aplicacion desea encontrar informacion acerca de er- dos, contactara en primer lugar con un servidor de nombres local, quien realizara una busqueda por otros servidores. Empieza por preguntar a un servidor de nombres raiz por erdos.maths.groucho.edu. Al comprobaresteultimo queel no mantiene ese dominio, contactara con los servidores del dominio edu y les preguntara las direcciones de los servi- dores de nombres, que retornara al servidor local. Ahora nuestro servidor preguntara a estos ultimos yestos a su vez iran haciendo llegar a nuestro servidor hasta los que mantienen la zona groucho.edu. Finalmente, se preguntara a uno de estosultimos por el nodo erdos y se enviara la respuesta al usuario. Aparentemente esto provoca mucho trafico, aunque en todo caso siempre sera menor que preguntar siempre a los mismos servidores que mantenian el fichero HOSTS.TXT antes de que se dise"nara el DNS. Sin embargo, aun se puede mejorar algo mas. La informacion obtenida en una busqueda puede que se necesite despues. Por ello, el servidor de nombres local la guardara en una cache local. Asi, cuando volvamos a preguntar por un nodo de groucho.edu, el servidor local ya podra dirigirse directamente el servidor de nombres de esa zona sin pasar por los servidores raiz. Por supuesto, el servidor de nombres no puede mantener la cache eternamente; debe descartarla cada cierto tiempo. Este tiempo de expiracion se conoce como TTL19 o tiempo de vida. En la base de datos del DNS queda especificado este parametro. 2.6.4 Servidores de Nombres Cuando un servidor de nombres mantiene toda la informacion acerca de una zona se le llama autorizado para esa zona. Cualquier peticion para esa zona sera enviada a uno de _____________________________________________19 N. del T.: Time To Live _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ esos servidores maestros. Para tener una representacion coherente de la zona, sus servidores maestros deben estar sincronizados. Para ello, a uno de ellos se le nombra servidor primario, que obtiene la informacion de zona a partir de unos ficheros locales, y a los demas se les nombra servidores secundarios. Estosultimos cargan la informacion de la zona pidiendosela al primario cada cierto tiempo. Las razones para que existan varios servidores autorizados por cada zona son dos: re- partir la carga de trabajo y lograr tolerancia a fallos. Asi, si un servidor cae, todas las peticiones se repartiran entre los demas servidores autorizados que haya. Por supuesto, esto no protege contra fallos internos o bugs del propio software DNS. Pero ademas, tambien es posible tener servidores de nombres que no mantengan infor- macion autorizada de ningun dominio20 . Este tipo de servidores esutil pues, al mantener una cache con los nombres que resuelven, disminuye la carga de la red y de otros servidores. 2.6.5 La Base de Datos DNS En las bases de datos del DNS se mantiene mas informacion que la necesaria para traducir nombres a direcciones IP. Dicho de otra forma, en DNS se mantienen distintos tipos de registros. La unidad de informacion en el DNS se conoce como registro de recurso o RR. Cada registro tiene un tipo asociado ael, describiendo que clase de datos contiene, y una clase indicando el tipo de red al que se aplica. Se trata de acomodarse a diferentes esquemas de red, aunque para direcciones IP se usa siempre la clase IN (INternet), pero hay otras como las redes Hesiod (que se usan en el MIT21 ). El registro mas habitual es el de tipo A, que relaciona un nombre totalmente cualificado con una direccion IP. Un nodo puede admitir mas de un nombre. Pero solo uno de ellos sera "oficial" o canonico, mientras que los demas son alias del primero. La diferencia es que el canonico se define en un registro de tipo A, mientras que los alias se definen en registros CNAME que apuntan al nombre canonico. En un capitulo posterior se trata todo esto en profundidad. Aqui nos vamos a limitar a ver algunos ejemplos. En la figura 2.4 se muestra una parte de la base de datos para la zona physics.groucho.edu. Ademas de los registros A y CNAME, se puede ver que hay un registro especial al _____________________________________________20 Aunque al menos debera tener informacion autorizada para el localhost y la resolucion inversa de 127.0.0.1 21Instituto Tecnologico de Massachusets _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ ; ; Informacion Autorizada de physics.groucho.edu @ IN SOA ( niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 1034 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl ) ; ; Servidores de nombres autorizados IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23 ; ; Fisica Teorica (subred 12) niels IN A 149.76.12.1 IN A 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 ... ; Laboratorio Collider (subred 14) boson IN A 149.76.14.1 muon IN A 149.76.14.7 bogon IN A 149.76.14.12 ... Figura 2.4: Extracto del fichero named.hosts del departamento de Fisicas. _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ principio del fichero, con varias lineas. Se trata del registro SOA o de inicio de autoridad, que mantiene informacion general sobre el servidor de nombres. Por ejemplo, el tiempo de vida por defecto de todos los registros que mantiene. Notese que aquellos nombres que no finalicen en un punto seran interpretados como re- lativos al dominio en cuestion. El nombre especial "@" usado en el registro SOA representa al dominio completo. Hemos visto que los servidores para el dominio groucho.edu deben tener conocimiento sobre los servidores de la zona physics para poder reenviarles las peticiones paraesta. Esto se suele incluir en los registros NS que incluyen el nombre de los servidores en notacion FQDN, y un registro A que da la direccion IP para ese servidor. Vease, por ejemplo, la figura 2.5. ; ; Datos de zona para groucho.edu. @ IN SOA ( vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl ) .... ; ; Registros de la zona. physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ... Figura 2.5: Extracto del fichero named.hosts de la UGM. 2.6.6 Resolucion inversa Ademas de la obtencion de una direccion IP a partir del nombre, a veces interesa lo contrario: conocida la direccion, obtener el nombre canonico. Esto se conoce como traduccion inversa y la utilizan algunas aplicaciones de red para verificar la identidad del llamante. Cuando se usa un fichero hosts, la resolucion inversa supone una simple busqueda en el mismo. En cambio, para el DNS se ha creado un dominio especial, el in-addr.arpa, que contiene _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ direcciones de los nodos en notacion de puntos divisorios invertida. Por ejemplo, a la direccion IP 149.76.12.4 le corresponde el nombre 4.12.76.149.in-addr.arpa. El tipo de registro para estos datos se llama PTR. Cuando se crea una zona de autoridad suele significar que sus administradores tienen control total sobre como asignan sus nombres. Pero a una subred se le puede delegar un subdominio. Esto sucede con la UGM, donde se delega la zona de Fisicas (subdominio physics) al correspondiente Departamento. Las direcciones de resolucion inversa tambien se delegan. En la figura 2.6 se muestra el contenido del fichero de zona para el servidor de la subred 12. Los registros "importantes" de delegacion se muestran en la figura 2.7. ; ; Dominio 12.76.149.in-addr.arpa @ IN SOA ( niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 233 360000 3600 3600000 3600 ) 2 IN PTR otto.physics.groucho.edu. 4 IN PTR quark.physics.groucho.edu. 5 IN PTR down.physics.groucho.edu. 6 IN PTR strange.physics.groucho.edu. Figura 2.6: Extracto del fichero named.rev de la subred 12. Una importante consecuencia de esto es que las zonas solo pueden crearse como super- conjuntos de redes IP, y ademas, las mascaras de red deberan redondearse a nivel de octeto. Es decir, las subredes de la UGM tendran una mascara 255.255.255.0, y para cada subred debera existir una zona in-addr.arpa. Sin embargo, si la mascara fuese 255.255.255.128, la creacion de zonas para la subred 149.76.12.128 seria imposible ya que no hay forma de decir en DNS que el dominio 12.76.149.in-addr.arpa ha sido dividido en dos zonas de autoridad, con nombres de nodos desde el 1 al 127, y desde el 128 al 255, respectivamente. _______________________________________________________________________________________________________________2.6. E* *l sistema de nombres DNS@ ; ; Dominio 76.149.in-addr.arpa domain @ IN SOA ( vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 360000 3600 3600000 3600 ) ... ; subred 4: Departamento de Matematicas 1.4 IN PTR sophus.maths.groucho.edu. 17.4 IN PTR erdos.maths.groucho.edu. 23.4 IN PTR gauss.maths.groucho.edu. ... ; subred 12: Departamento de fisicas, zona separada 12 IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics.groucho.edu. IN A 149.76.12.1 gauss.maths.groucho.edu. IN A 149.76.4.23 ... Figura 2.7: Extracto del fichero named.rev de la red 149.76. Capitulo 3 Configuracion del Hardware de Red 3.1 Dispositivos, Controladores, y todo lo demas Hasta ahora, hemos estado hablando bastante sobre los interfaces de red pero sin explicar realmente que es lo que pasa cuando el "codigo de red" en el nucleo accede a una parte del hardware. Para ello, y antes que nada, tenemos que hablar un poco sobre los conceptos de interface y controladores. Primero, evidentemente, esta el hardware por si mismo; por ejemplo, una tarjeta Et- hernet es: una oblea de Silicio, atiborrada de montones de peque"nos chips con estupidos numeros en el lomo e insertada en una ranura de su PC. Esto es lo que por lo general denominamos un dispositivo. Para poder utilizar la tarjeta Ethernet son necesarias una serie de funciones especiales definidas en el nucleo de Linux que seran capaces de entender la forma particular de acceso al dispositivo. Esta serie de funciones son los denominados controladores1 del dispositivo. Por ejemplo, Linux tiene controladores de dispositivos para varias marcas de tarjetas Ethernet que son muy parecidas en su funcionamiento. Son conocidos como los "Controladores de la Serie Becker", debido a su autor, Donald Becker. Otro ejemplo puede ser el del controlador D-Link, que gestiona un adaptador de bolsillo D-Link conectado a un puerto paralelo. Pero >que es lo que queremos decir con que un controlador "gestione" un dispositivo? Volvamos a la tarjeta Ethernet que examinamos antes. El controlador tiene que ser capaz de comunicarse de alguna forma con la logica interna de la tarjeta: tiene que enviarordenes y datos a la tarjeta, mientras que la tarjeta debe transmitir al controlador cualquier dato _____________________________________________1 N. del T.: Con frecuencia, la bibliografia especializada en espa"nol tambien los llama manejadores 39 _______________________________________________________________________________________________________________3.1. D* *ispositivos, Controlador@ Codigo de Red en Nucleo Interfaz Red eth0 eth2 eth1 eth3 Manejador Dispositivo Manejador SMC Manejador 3Com Hardware Figura 3.1: Relacion entre controladores, interfaces, y hardware. recibido. En un PC, esta comunicacion tiene lugar a traves de unarea de memoria de E/S que se corresponde con los registros internos de la tarjeta y a la inversa. Todas lasordenes y datos que el nucleo envia a la tarjeta tienen que ir a traves de estos registros. Elarea de memoria de E/S de la tarjeta se describe por lo general mediante su direccion base o de comienzo. Direcciones habituales para tarjetas Ethernet son la 0x300 o la 0x360. Normalmente no hay que preocuparse por factores de hardware como las direcciones base, ya que en tiempo de arranque el nucleo hace un intento para detectar la localizacion de la tarjeta. Esto se denomina autoverificacion2, que implica que el nucleo lea varias posiciones de memoria y compare los datos leidos con los que deberia haber si existiese una tarjeta Ethernet instalada alli. De todas maneras, puede haber tarjetas Ethernet que no sean detectadas automaticamente; esto ocurre a veces con tarjetas Ethernet baratas que no son replicas exactas de tarjetas estandar de otros fabricantes. Por otro lado, el nucleo intentara detectar ununico dispositivo Ethernet al arrancar. Si se utiliza mas de una tarjeta, hay que indicarselo explicitamente al nucleo. Otro de los parametros que se pueden decir de forma explicita al nucleo es el canal de peticion de interrupcion. Los componentes hardware normalmente interrumpen al nucleo cuando tienen necesidad de queeste se ocupe de ellos, por ejemplo cuando han llegado datos, _____________________________________________2 N. del T.: Del ingles autoprobing _______________________________________________________________________________________________________________3.1. D* *ispositivos, Controlador@ o se presenta una condicion especial. En un PC, las interrupciones pueden comunicarse mediante uno de los 15 canales de interrupcion numerados 0,1 y del 3 al 15. El numero de interrupcion asignado a un componente hardware se denomina su numero de peticion de interrupcion, o IRQ34 . Como se explicaba en el capitulo 2, el nucleo accede a un dispositivo mediante lo que llamabamos una interfaz. Las interfaces ofrecen un conjunto abstracto de funciones que es el mismo para todo tipo de hardware. Por ejemplo, con funciones para enviar o recibir datagramas. Los interfaces se identifican mediante nombres. Estos nombres se definen internamente en el nucleo, y no son ficheros de dispositivos del directorio /dev. Nombres tipicos para los interfaces Ethernet son eth0, eth1, etc. La asignacion de interfaces a los dispositivos depende normalmente del orden en el que los dispositivos son configurados; por ejemplo la primera tarjeta Ethernet instalada sera eth0, la siguiente eth1, y asi sucesivamente. Una excepcion a esta regla son las interfaces SLIP y algunas otras, que son asignadas de forma dinamica; es decir, al establecerse una conexion SLIP, se asigna una interface al puerto serie. El grafico de la figura 3.1 muestra la relacion entre el hardware, los controladores de dispositivos e interfaces. Al arrancar, el nucleo muestra cada dispositivo que es detectado, y que interfaces se estan instalando. Lo siguiente es un extracto de la pantalla de arranque: . . This processor honours the WP bit even when in supervisor mode. Good. Floppy drive(s): fd0 is 1.44M Swansea University Computer Society NET3.010 IP Protocols: ICMP, UDP, TCP PPP: version 0.2.1 (4 channels) OPTIMIZE FLAGS TCP compresssion code copyright 1989 Regents of the University of California PPP line discipline registered. SLIP: version 0.7.5 (4 channels) CSLIP: code copyright 1989 Regents of the University of California dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95 Checking 386/387 coupling... Ok, fpu using exception 16 error reporting. Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994 Esta indica que el nucleo ha sido compilado para TCP/IP, y se incluyen los controladores para SLIP, CSLIP, y PPP. La tercera linea antes del final indica que se ha detectado un _____________________________________________3 Los IRQs 2 y 9 son los mismos debido a que el PC tiene dos procesadores de interrupciones en cascada con 8 IRQs cada uno; el procesador secundario esta conectado al IRQ 2 del primario. 4 N. del T.: Del ingles Interrupt ReQuest _______________________________________________________________________________________________________________3.2. C* *onfiguracion del nucleo @ adaptador de bolsillo D-Link e instalado como el interface dl0. Si usted tiene un tipo diferente de tarjeta Ethernet, el nucleo mostrara normalmente una linea comenzando por eth0, seguida por el tipo de tarjeta detectado. Si usted tiene una tarjeta Ethernet instalada pero no se refleja en ningun mensaje, significa que el nucleo es incapaz de detectar su tarjeta adecuadamente. Trataremos este problema posteriormente. 3.2 Configuracion del nucleo La mayoria de las versiones de Linux se distribuyen con discos de arranque que funcionan en casi cualquier PC. Esto significa que el nucleo tiene en esos discos todo tipo de controladores configurados que rara vez utilizara, pero que ocupan un espacio innecesario en el sistema de memoria ya que con el nucleo no puede hacerse swapping. Por tanto seria conveniente crear un nucleo propio, incluyendo solo los controladores que realmente necesite o desee. Al trabajar con un sistema Linux, le debera resultar familiar el proceso de construccion del nucleo. Los conceptos basicos de como realizarlo se explican en la Guia de Matt Welsh: "Instalacion y primeros pasos", que tambien forma parte de la serie de Documentacion del Proyecto Linux. Por tanto, en esta seccion solo trataremos las opciones de configuracion que afectan a la red. Al ejecutar make config, se le preguntara por una serie de configuraciones generales, por ejemplo si desea emulacion matematica del nucleo o no, etc. Una de las preguntas sera si desea o no soporte para red TCP/IP. Si desea un nucleo capaz de trabajar con la red debe ser contestada con y (SI). 3.2.1 Opciones del nucleo de Linux 1.0 o Versiones Posteriores Tras completar la parte de opciones generales, se pasara a configurar distintos componentes: controladores SCSI, etc. La siguiente lista contiene las preguntas que son sobre el soporte de red. Notese que el conjunto de opciones de configuracion esta en constante cambio debido al continuo desarrollo. Una lista tipica de opciones que ofrecen los nucleos de versiones entre la 1.0 y la 1.1 se parece aesta (los comentarios estan en cursiva): * * Network device support * Network device support? (CONFIG ETHERCARDS) [y] A pesar de que se muestre la contestacion por defecto entre corchetes, la pregunta debe ser contestada con y si desea utilizar cualquier tipo de dispositivos de red, no importa si _______________________________________________________________________________________________________________3.2. C* *onfiguracion del nucleo @ son Ethernet, SLIP o PPP. Si contesta a la pregunta con y, se activara automaticamente el soporte para dispositivos tipo Ethernet. El soporte para otros tipos de controladores de red debe ser activado por separado: SLIP (serial line) support? (CONFIG SLIP) [y] SLIP compressed headers (SL COMPRESSED) [y] PPP (point-to-point protocol) support (CONFIG PPP) [y] PLIP (parallel port) support (CONFIG PLIP) [n] Estas preguntas conciernen a los diversos protocolos de nivel de enlace soportados por Linux. SLIP permite transportar datagramas IP a traves de lineas serie. La opcion de compresion de cabecera proporciona el soporte CSLIP, una tecnica que reduce las cabeceras TCP/IP a tres bytes. Tenga en cuenta que esta opcion del nucleo no activa automaticamente el soporte para CSLIP, solamente proporciona las funciones necesarias del nucleo para ello. PPP es otro de los protocolos para enviar trafico a la red a traves de lineas serie. Es mucho mas flexible que SLIP, y no se limita a IP, sino que, una vez que se implemente, tambien soportara IPX. Ya que el soporte para PPP ha sido incluido hace poco, esto opcion puede no aparecer en su nucleo. PLIP proporciona una forma de enviar datagramas IP a traves de un puerto paralelo. Se utiliza generalmente para comunicar dos PCs bajo DOS. El resto de las preguntas son acerca de tarjetas Ethernet de diversos fabricantes. A medida que se desarrollan mas controladores, la lista de preguntas se hace mayor. Si desea construir un nucleo que quiera utilizar en varias maquinas, tiene la posibilidad de activar mas de un controlador. NE2000/NE1000 support (CONFIG EN2000) [y] WD80*3 support (CONFIG WD80x3) [n] SMC Ultra support (CONFIG ULTRA) [n] 3c501 support (CONFIG EL1) [n] 3c503 support (CONFIG EL3) [n] HP PCLAN support (CONFIG HPLAN) [n] AT1500 and EN2100 (LANCE and PCnet-ISA) support (CONFIG LANCE) [n] AT1700 support (CONFIG AT1700) [n] DEPCA support (CONFIG DEPCA) [n] D-Link DE600 pocket adaptor support (CONFIG DE600) [y] AT-LAN-TEC/RealTek pocket adaptor support (CONFIG ATP) [n] * * CD-ROM drivers * ... Porultimo, en la seccion del sistema de ficheros, el script de configuracion le preguntara, entre otras cosas, si desea soporte para NFS (networking filesystem), el sistema de ficheros _______________________________________________________________________________________________________________3.2. C* *onfiguracion del nucleo @ en red. NFS le permitira exportar sistemas de ficheros a diversos nodos, de forma que parezcan como si estuviesen en un disco duro normal conectado a la maquina local. NFS filesystem support (CONFIG NFS FS) [y] 3.2.2 Opciones del nucleo de Linux 1.1.14 y Versiones Posteriores Comenzando con Linux 1.1.14, que incluia una version alpha de IPX, el proceso de con- figuracion vario muy poco. Ahora las opciones de caracter general preguntan si se desea soporte de red en general. A continuacion aparecen un par de preguntas adicionales. * * Networking options * TCP/IP networking (CONFIG INET) [y] Para utilizar protocolos TCP/IP, se debe contestar con y. Pero aunque conteste de forma negativa todavia sera capaz de poder compilar el nucleo para que soporte IPX. IP fordwarding/gatewaying (CONFIG IP FORWARD) [n] Tendra que activar esta opcion si su sistema actua como un puente entre dos redes Ethernet, o entre una red Ethernet y un enlace SLIP, etc. Aunque no cuesta nada activar esta opcion por defecto, podria querer desactivarla para configurar la maquina como un cortafuegos5. Los cortafuegos son nodos que se conectan a una o mas redes, pero no encaminan trafico entre ellos. Se utilizan normalmente para proporcionar a los usuarios en una empresa acceso a Internet con un riesgo minimo para la red interna. A los usuarios se les permitira acceder al cortafuegos y utilizar servicios Internet, pero las maquinas de la empresa estaran protegidas de ataques externos ya que cualquier conexion entrante no puede cruzar el cortafuegos. * * (it is safe to leave these untouched) PC/TCP compatibility mode (CONFIG INET PCTCP) [n] Esta opcion evita incompatibilidades con algunas versiones de PC/TCP, una implemen- tacion comercial de TCP/IP basada en DOS para PCs. Si activa esta opcion, todavia sera capaz de comunicarse con maquinas un?x normales, pero bajara el rendimiento cuan- do el enlace sea lento. _____________________________________________5 N. del T.: Del ingles firewall _______________________________________________________________________________________________________________3.2. C* *onfiguracion del nucleo @ Reverse ARP (CONFIG INET RARP) [n] Esta funcion activa RARP, Protocolo de Resolucion de Direcciones Inverso. RARP se utiliza en clientes sin disco y terminales X para pedir su direccion IP al arrancar. Debera ac- tivar RARP solo cuando planee que su maquina sea un servidor para este tipo de clientes. Elultimo paquete de utilidades de red (net-0.32d ) contiene una peque"na utilidad llamada rarp que permite a"nadir direcciones de nodos a una cache RARP. Assume subnets are local (CONFIG INET SNARL) [y] Al mandar datos TCP, el nucleo tiene que dividir los envios en diversos paquetes antes de pasarselo al nivel IP. Para maquinas accesibles en redes locales como Ethernet , se utilizaran paquetes mas grandes que para maquinas cuyos datos son enviados a traves de enlaces de larga distancia.6 Si no se activa la opcion SNARL, el nucleo asumira como locales solo a aquellas redes con las que en ese momento tenga una interface. Si revisa la red de clase B en la Universidad Groucho Marx, toda la red de clase B es local pero la mayoria de los hosts mantienen una interface con solo una o dos subredes. Si se activa la opcion SNARL, el nucleo asumira todas las subredes como locales y utilizara paquetes grandes cuando se comunique con todos los nodos del campus. Si no desea utilizar tama"nos de paquete peque"nos para enviar datos a maquinas es- pecificas (si, por ejemplo, utiliza un enlace SLIP para la transmision de datos), tendra que hacerlo mediante la opcion mtu del encaminamiento (route), que se describe brevemente al final de este capitulo. Disable NAGLE algorithm (normally enabled) (CONFIG TCP NAGLE OFF) [n] La formula de Nagle es un metodo heuristico para evitar enviar paquetes IP particu- larmente peque"nos, tambien denominados pequegramas7. Los pequegramas son utilizados normalmente por herramientas de red interactivas que transmiten pulsaciones unicas de teclas, como telnet o rsh (remote shell). Los pequegramas pueden llegar a ser particular- mente ineficientes bajo enlaces de banda estrecha como SLIP. El algoritmo de Nagle intenta evitarlos reteniendo por poco tiempo la transmision de datos TCP en algunas circustancias. Es recomendable desactivar el algoritmo de Nagle si tiene graves problemas por paquetes perdidos. The IPX protocol (CONFIG IPX) [n] _____________________________________________6 Esto evita la fragmentacion por enlaces que tienen un tama"no de paquete maximo muy peque"no. 7 N. del T.: Del inges tinygrams _______________________________________________________________________________________________________________3.3. U* *na Visita a los Disposit@ Activa la capacidad de soportar el protocolo IPX, el protocolo de transporte utilizado por Novell Networking; que sigue todavia bajo desarrollo, y aun no es realmenteutil. Una ventaja de esto sera cuando algun dia se intercambien datos con utilidades IPX basadas en DOS, y encaminen trafico entre redes Novell mediante un enlace PPP. El soporte para protocolos de alto nivel de redes Novell no esta todavia a la vista, ya que las especificaciones de estos protocolos tienen un coste economico muy elevado. A partir de la version 1.1.16 del nucleo, Linux soporta otro tipo de controlador: el controlador vacio (dummy). La siguiente pregunta aparece hacia el comienzo de la seccion de controladores de dispositivos: Dummy net driver support (CONFIG DUMMY) [y] El controlador vacio no hace realmente gran cosa, pero es bastante util en maquinas aisladas o conectadas mediante SLIP. Es basicamente un interface en bucle cerrado. La razon de tener este tipo de interface es que en las maquinas que se conectan con SLIP que no disponen de Ethernet, es necesario tener un interface que continuamente maneje las direcciones IP. Esto se discute mas profundamente en las seccion La Interface Comodin del capitulo 5. 3.3 Una Visita a los Dispositivos de Red de Linux El nucleo de Linux soporta controladores de hardware de diversas clases. En esta seccion se introducen brevemente las familias de controladores disponibles, y los nombres de interfaces que utilizan. Hay un conjunto de nombres estandares para los interfaces en Linux, que se enumeran a continuacion. La mayoria de los controladores soportan mas de un interface, en cuyo caso las interfaces se numeran de la forma: eth0, eth1, etc. lo Interface de bucle local o de lazo. Se utiliza para realizar pruebas, y para un par de aplicaciones de red. Funciona como un circuito cerrado en el que cualquier datagrama que se le pase como parametro sera inmediatamente devuelto a la capa de red del sistema. En el nucleo siempre hay un dispositivo de bucle local, no tiene sentido tener mas de uno. ethn Tarjeta Ethernet n -sima. Este es el nombre de interface generico para la mayoria de las tarjetas Ethernet. dln Esta interface accede a un adaptador de bolsillo D-Link DE-600, otro dispo- sitivo Ethernet. Tiene un caracter un poco especial ya que esta conectado a _______________________________________________________________________________________________________________3.4. I* *nstalacion Ethernet @ un puerto paralelo. sln Interface SLIP n -sima. Las interfaces SLIP se asocian a lineas serie en el orden en el que son instalados; por ejemplo, sl0, sera la primera linea serie en ser configurada para SLIP, etc. El nucleo soporta hasta cuatro interfaces SLIP. pppn Interface PPP n -sima. Como ocurre con las interfaces SLIP, una interface PPP se asocia a una linea serie una vez que se ha convertido a modo PPP. De momento, se pueden soportar hasta cuatro interfaces de este tipo. plipn Interface PLIP n -sima. PLIP transporta datagramas IP en lineas parale- las. Se soportan hasta tres interfaces PLIP. El controlador PLIP asigna las interfaces en tiempo de arranque, y se mapean a los puertos paralelos. Para otros controladores de interfaces que puedan ser a"nadidos en el futuro como RDSI (Red Digital de Servicios Integrados) o AX.25, se utilizaran otros nombres. Controladores como el de IPX (protocolo Novell de red) o AX.25 (utilizado por radio aficionados) estan ya en desarrollo, aunque todavia en versiones preliminares (alpha). En las secciones siguientes se discutiran los detalles de uso de los controladores anteriores. 3.4 Instalacion Ethernet El codigo de red actual de Linux soporta diversas marcas de tarjetas Ethernet. Donald Becker (becker@cesdis.gsfc.nasa.gov) desarrollo la mayoria de los controladores, una familia para tarjetas basadas en el chip 8390 de National Semiconductor; y se la conoce como los la Serie de Controladores Becker. Tambien hay un par de productos de D-Link, entre ellos el adaptador de bolsillo D-Link que permite acceder a una red Ethernet a traves de un puerto paralelo. Un controlador para este dispositivo fue programado por Bjorn Ekwall (bjorn@blox.se), mientras que el controlador DEPCA lo programo David C. Davies (davies@wanton.lkg.dec.com). 3.4.1 Cableado de Ethernet Si usted esta instalando una red Ethernet por primera vez en su vida, son necesarios al- gunos comentarios respecto al cableado. Ethernet tiene una caracteristicas muy especiales de cableado. El cable debe terminar en ambos extremos con una resistencia de 50 Ohm, y no debe tener ninguna ramificacion (p.e. tres cables conectados en estrella). Si esta utili- zando cable coaxial fino con conectores BNC en forma de T, estos conectores deben estar _______________________________________________________________________________________________________________3.4. I* *nstalacion Ethernet @ directamente conectados al de la tarjeta; no debe insertarse el cable directamente. Si se conecta a una instalacion con cable grueso, debe conectar el ordenador utilizando un transceptor (a veces denominado Unidad de Conexion Ethernet). Puede conectarse el transceptor a un puerto AUI de 25 pines de la tarjeta mediante un cable protegido. 3.4.2 Tarjetas Compatibles Una lista completa de las tarjetas compatibles esta disponible en los Ethernet HOWTOs, publicada mensualmente en comp.os.linux.announce por Paul Gortmaker.8 Incluimos una lista de las tarjetas mas conocidas y utilizadas que soporta Linux. La lista actual del HOWTO es casi tres veces mayor. Aunque encuentre su tarjeta en esta lista, busquela tambien en el HOWTO; a veces hay detalles importantes sobre el modo de operacion de estas tarjetas. Por ejemplo, algunas tarjetas Ethernet basadas en DMA que utilizan los mismos canales DMA que los que el controlador de SCSI Adaptec 1542 usa por defecto. Si no se cambia el canal de DMA en alguno de las dos, la tarjeta Ethernet podria escribir paquetes de datos en posiciones arbitrarias del disco duro. 3Com EtherLink Se soporta 3Com EtherLink tanto 3c503 como 3c503/16, ademas de las ver- siones 3c507 y 3c509. La 3c501 tambien se soporta aunque es demasiado lenta como para merecer la pena. Novell Eagle Se soportan Novell Eagle NE1000 y NE2000, asi como diversas clonicas. Tambien soporta las NE1500 y NE2100. Western Digital/SMC Hay que incluir entre las compatibles a la Western Digital/SMC WD8003 y WD8013 (igualmente la SMC Elite y la SMC Elite Plus), y tambien la nueva SMC Elite 16 Ultra. Hewlett Packard Las HP 27252, HP 27247B, y la HP J2405A. D-Link El adaptador de bolsillo D-Link DE-600, DE-100, DE-200 y DE-220-T. Tam- bien hay un kit de ampliacion para la DE-650-T, denominado tarjeta PCM- CIA9. DEC DEC DE200 (32K/64K), DE202, DE100, y DEPCA rev E. _____________________________________________8 Paul puede ser localizado en gpg109@rsphysse.anu.edu.au. 9 Puede conseguirse - junto con otro material relacionado con Laptop - en tsx-11.mit.edu, en packa- ges/laptops. _______________________________________________________________________________________________________________3.4. I* *nstalacion Ethernet @ Allied Teliesis AT1500 y AT1700. Para utilizar cualquiera de estas tarjetas con Linux, debe utilizar un nucleo precompilado de una de las distribuciones de Linux. Estas versiones incluyen normalmente controladores para todas las tarjetas. Aunque a la larga sera mejor confeccionarse su propio nucleo y compilarlo solo con los controladores que se necesiten en ese momento. 3.4.3 Autoverificacion de red Ethernet En tiempo de arranque, el codigo para Ethernet intentara localizar la tarjeta y determinar su tipo. Se comprueban por orden las siguientes direcciones: ____________________________________________________________________ | Tarjeta | Verificacion de las direcciones | |___________________|__________________________________________|____ | WD/SMC | 0x300, 0x280, 0x380, 0x240 | | | | | SMC 16 Ultra | 0x300, 0x280 | | | | | 3c501 | 0x280 | | | | | 3c503 | 0x300, 0x310, 0x330, 0x350, 0x250, | | | | | |0x280, 0x2a0, 0x2e0 | | | | | NEx000 | 0x300, 0x280, 0x320, 0x340, 0x360 | | | | | HP | 0x300, 0x320, 0x340, 0x280, 0x2C0 | | | | | |0x200, 0x240 | | | | | DEPCA | 0x300, 0x320, 0x340, 0x360 | |________________|__________________________________________|_______ El codigo de autoverificacion tiene dos limitaciones. Una de ellas es que no reconoce todas las tarjetas correctamente. Esto ocurre frecuentemente con algunas de las tarjetas clonicas mas baratas, pero tambien con algunas tarjetas WD80x3. La otra limitacion es que el nucleo no verificara mas de una tarjeta por defecto. Esto se hace asi porque se asume que se desea tener control sobre que tarjeta es asignada a que interface. Si esta utilizando mas de una tarjeta, o si el proceso de autoverificacion no consigue detectar su tarjeta, debe indicar explicitamente al nucleo el nombre y direccion base de la tarjeta. Con Net-3, se tienen dos posibilidades diferentes ante un caso de fallo en la autoveri- ficacion. Una de ellas es cambiar o a"nadir informacion en el fichero del codigo fuente del nucleo drivers/net/Space.c, que contiene toda la informacion sobre controladores. Solo es recomendable en el caso de que el codigo de red le sea familiar. Una forma mucho mejor es proporcionar al nucleo esta informacion en tiempo de arranque. Si utiliza lilo al arrancar el sistema, puede pasarle parametros al nucleo, especificandolos mediante la opcion append en _______________________________________________________________________________________________________________3.4. I* *nstalacion Ethernet @ el fichero lilo.conf. Por ejemplo, para informar al nucleo sobre la existencia de un dispositivo Ethernet, puede pasarse el siguiente parametro: ether=irq , dir_base , param1 ,param2 ,nombre Los cuatro primeros argumentos son numericos, mientras que elultimo es el nombre de un dispositivo. Todos los valores numericos son opcionales: si se omiten o se dejan a cero, el nucleo intentara averiguar su valor mediante autoverificacion, o utilizando un valor por defecto. El primer parametro indica el IRQ asignado al dispositivo. Por defecto, el nucleo inten- tara autodetectar el canal IRQ del dispositivo. El controlador 3c503 tiene un funcionamiento especial seleccionando un canal libre IRQ de la lista 5, 9, 3, 4, y configura la tarjeta para utilizar esta linea. El parametro dir_base define la direccion base de E/S de la tarjeta; si vale cero, el nucleo probara con las direcciones de la lista anterior. Los dos parametros restantes pueden ser utilizados de forma diferente por controladores diferentes. Para tarjetas de memoria compartida como la WD80x3, especifican la direccion de comienzo y de fin delarea de memoria compartida. Otras tarjetas utilizan normalmente el param1 para seleccionar el nivel de informacion de depuracion para el usuario. Los valores del 1 al 7 denotan niveles de detalle en la informacion, mientras que el valor 8 desactiva todos; por defecto se toma el valor cero. El controlador 3c503 utiliza el param2 para seleccionar el transceptor interno (por defecto) o un transceptor externo (valor 1). El primero utiliza un conector de tarjeta tipo BNC; elultimo utiliza su puerto AUI. Si se tienen dos tarjetas Ethernet, puede hacerse que Linux autodetecte una de ellas, y pasar los parametros de la segunda mediante lilo. Sin embargo, hay que estar seguros de que el controlador accidentalmente no encuentra la segunda tarjeta primero, en cuyo caso la otra no se detectara. Esto se consigue pasando la opcion reserve a lilo, que indica explicitamente al nucleo que no verifique el espacio de E/S reservado para la segunda tarjeta. Por ejemplo, para hacer que Linux instale una segunda tarjeta Ethernet en la direccion (0x300) como eth1, hay que pasarle los siguientes parametros al nucleo: reserve=0x300,32 ether=0,0x300,eth1 La opcion reserve asegura que ningun controlador accede al espacio de E/S del nucleo cuando verifica algun dispositivo. Tambien pueden utilizarse los parametros del nucleo para evitar realizar la verificacion para eth0 : _______________________________________________________________________________________________________________3.5. E* *l controlador PLIP @ reserve=0x340,32 ether=0,340,eth0 Para evitar completamente la fase de autoverificacion, se especifica el argumento dir_base a -1: ether=0,-1,eth0 3.5 El controlador PLIP PLIP permite trabajar con una Linea Paralela IP, y es una forma barata de interconexion cuando se desea conectar solamente dos maquinas. Utiliza un puerto paralelo y un cable especial, alcanzando velocidades entre 10kBps a 20 kBps. PLIP fue desarrollado en principio por Crynwr, Inc. Su dise"no es mas que ingenioso (o, si se prefiere, mas propio de un hacker): durante muchos a"nos, los puertos paralelos del PC se utilizaban como puertos para impresora unidireccionales; es decir las ocho lineas de datos podrian ser utilizados solamente para envios desde el PC al dispositivo periferico, pero no en sentido inverso. El PLIP saca un mejor provecho utilizando la linea de estado numero cinco del puerto, que se limita a transferir todos los datos simplemente como nibbles (es decir medio byte). Hoy en dia, estos puertos unidireccionales no son muy utilizados. Por tanto tambien hay una extension denominada modo 1 que utiliza la interface completa de 8 bits. Actualmente Linux solo soporta el modo 0. A diferencia de versiones mas antiguas del codigo que maneja el PLIP, ahora se intenta hacerlo compatible con las implementaciones PLIP de Cynwr, y para el controlador PLIP en el NCSA telnet 10. Para conectar dos maquinas utilizando PLIP, se necesita un cable especial que se vende en algunas tiendas como cable de "Impresora Nula" ("Null Printer") o "Turbo Laplink". Es posible fabricarlo de forma casera, en el Apendice A se indica como. El controlador PLIP para Linux es el trabajo de un numero casi incontable de personas. Actualmente esta mantenido por Niibe Yutaka. Si se compila en el nucleo, configura una interface de red para cada posible puerto de impresora, con plip0 correspondiendo al puerto paralelo lp0, plip1 correspondiendo a lp1, etc. El mapeado del interface a los puertos es ahora mismo el siguiente: _____________________________________________10 El NCSA telnet es un programa bastante conocido para DOS que trabaja con TCP/IP en redes Ethernet o PLIP, y soporta telnet, FTP y algunas otras aplicaciones sencillas. _______________________________________________________________________________________________________________3.6. L* *os controladores SLIP y @ ________________________________________ | Interface | Puerto E/S | IRQ | |_____________|_____________|_________|_ | plip0 |0x3BC | 7 | | | | | | plip1 |0x378 | 7 | | | | | | plip2 |0x278 | 5 | |______________|_____________|__________| Si se tiene configurado el puerto de la impresora de forma diferente, hay que cambiar estos valores en el fichero drivers/net/Space.c del codigo fuente de Linux, y construir un nuevo nucleo. Este mapeado no implica que no se puedan utilizar los puertos paralelos de forma normal. Solo son accedidos por el controlador de PLIP cuando el interface correspondiente ha sido configurado como activo. 3.6 Los controladores SLIP y PPP SLIP (Serial Line IP, Protocolo Internet en Linea Serie), y PPP (Point-to-Point Protocol, Protocolo Punto-a-Punto) son protocolos muy utilizados para enviar paquetes IP a traves de enlaces serie. Varias instituciones ofrecen acceso telefonico SLIP y PPP a maquinas conectadas a Internet: esto proporciona conectividad IP a los particulares (algo que de otra forma seria dificil de conseguir debido al elevado coste de otros tipos de conexiones). Para trabajar con SLIP o PPP, no son necesarias modificaciones en el hardware; puede utilizarse cualquier puerto serie. Ya que es especifica la configuracion del puerto serie para interconexion TCP/IP, se le dedicara un capitulo aparte. Para mas informacion consultar el capitulo 4. Capitulo 4 Configuracion del Software Serie Casi todo el mundo dispone de un PC, pero no siempre hay dinero para gastarlo en un enlace Internet T1. Para conseguir su dosis diaria de noticias y mensajes, mucha gente depende de enlaces SLIP, redes UUCP y BBS, que usan las redes telefonicas publicas. Este capitulo pretende ayudar a todas aquellas personas que dependen del modem para mantener sus comunicaciones. Sin embargo, hay muchos detalles que no podemos abordar, como por ejemplo como configurar el modem para marcar. Todos esos te- mas estan contemplados en el "Serial HOWTO"1 de Greg Hankins2, que es enviado a comp.os.linux.announce regularmente. 4.1 Software de Comunicaciones con Modem Existen varios paquetes de comunicaciones disponibles para Linux. Muchos de ellos son emuladores de terminal, que permiten a un usuario conectarse a otro ordenador como si estuviera frente a uno de sus terminales. El emulador de terminal tradicional en sistemas un?x es kermit. Sin embargo resulta algo duro de usar. Hay programas disponibles mas comodos que soportan agenda telefonica y guiones para llamar y entrar en ordenadores remotos. Uno de estos es el minicom, muy parecido a los primitivos programas emuladores de terminal a los que tan acostumbrados estan los usuarios de DOS. Hoy tambien existen paquetes de comunicaciones bajo X-11 como por ejemplo seyon. Ademas, existe un buen numero de programas para instalar BBS bajo Linux disponibles para aquellos que quieran ofrecer dicho servicio. Varios de esos paquetes se encuentran en sunsite.unc.edu, en el directorio /pub/Linux/system/Network. _____________________________________________1 N. del T.: Disponible en castellano como SERIE-COMO, en http://lucas.ctv.es/ 2 disponible en gregh@cc.gatech.edu. 53 _______________________________________________________________________________________________________________4.2. * *Introduccion a los Dispos@ Aparte de los programas de terminal, hay tambien software que usa la linea serie de forma no interactiva para el transporte de datos hasta su ordenador. Normalmente se invierte bastante mas tiempo en visitar un BBS leyendo toda su informacion en la que podemos incluir las noticias y los mensajes, que el que se necesita empleando este tipo de software. La unica desventaja es que se requiere mas espacio de disco debido a la transferencia de cierta cantidad de informacion que al usuario le resulta inutil, y que de forma interactiva no se tranmitiria. El compendio de esta clase de software de comunicaciones es UUCP. Este es un conjunto de programas que copian ficheros de una maquina a otra, ejecutan programas en un ordena- dor remoto, etc. Se utiliza frecuentemente para transferir mensajes y noticias (news) entre redes privadas. El paquete UUCP de Ian Taylor, que funciona bajo Linux, sera descrito en el capitulo 12 de este libro. Otro tipo de software de comunicaciones no interactivo es el utilizado en Fidonet, para el que tambien podemos encontrar algunos paquetes de software, como ifmail. SLIP, el protocolo de Internet para linea serie, esta de algun modo a medio camino: per- mite tanto el uso interactivo como el no interactivo. Mucha gente usa SLIP para telefonear a la red de su campus o algun otro tipo de servidor publico y poder ejecutar sesiones FTP, etc. Sin embargo, SLIP tambien puede ser usado en conexiones permanentes o semiperma- nentes para uniones de LAN a LAN, aunque estoultimo solo resulta interesante utilizando RDSI u otros enlaces de ancho de banda mayor. 4.2 Introduccion a los Dispositivos Serie Los dispositivos proporcionados por un nucleo un?x para el acceso a dispositivos serie son llamados normalmente ttys. Esta es una abreviatura de TeletypeTM , quienes eran unos de los mayores productores de terminales en los primeros dias de Unix. El termino se usa actualmente para cualquier terminal de texto. En este capitulo, lo usaremos exclusivamente para referirnos a los dispositivos del nucleo. Linux distingue tres clases de ttys: consolas (virtuales), pseudo terminales (similares a las tuberias de doble via, usadas por aplicaciones tales como X11), y dispositivos serie. Estosultimos son considerados tambien como ttys, porque permiten sesiones interactivas sobre conexiones serie, ya seaeste un terminal conectado por cable o un ordenador remoto a traves de la linea telefonica. Los ttys tienen cierto numero de parametros configurables mediante la llamada al sistema ioctl(2). Muchos de estos parametros sirvenunicamente con dispositivos serie, ya que son estos los que necesitan una mayor flexibilidad para poder manejar la gran variedad de tipos de conexion que son capaces de controlar. _______________________________________________________________________________________________________________4.3. A* *cceso a los Dispositivos@ Entre los parametros mas destacados para la linea se encuentran la velocidad y la pa- ridad. Pero hay tambien elementos para la conversion de caracteres entre mayuscula y minuscula, de retorno de carro, de avance de linea, etc. El controlador de tty puede tam- bien soportar varias lineas dedicadas, las cuales hacen que el controlador de dispositivo se comporte de forma diferente. Por ejemplo, el controlador de SLIP para Linux esta imple- mentado como si fuera una linea dedicada. Existe algo de ambig"uedad sobre como medir la velocidad de la linea. El termino correcto es bit rate, el cual esta relacionado con la velocidad de transferencia de la linea medida en bits por segundo (bps para abreviar). Algunas veces se oye a la gente referirse a ella como velocidad en baudios, lo cual no es muy correcto, ya que estos dos terminos no son sinonimos. La velocidad en baudios se refiere a una caracteristica fisica de algunos dispositivos serie. En concreto, a la velocidad de reloj a la que se transmiten los impulsos. En cambio, el "bit rate", indica el estado actual de una conexion serie existente entre dos puntos, a saber, el numero medio de bits transferidos por segundo. Es importante saber que estos dos valores suelen ser diferentes, ya que la mayoria de los dispositivos codifican mas de un bit por cada impulso electrico. 4.3 Acceso a los Dispositivos Serie Como ocurre con todos los dispositivos de un sistema un?x, se accede a los puertos serie a traves de ficheros especiales de dispositivo, localizados en el directorio /dev. Cada puerto tiene su fichero de dispositivo. Hay dos tipos de ficheros de dispositivos relacionados con los controladores serie. Dependiendo del fichero por el que se acceda el dispositivo se comportara de forma diferente. El primer tipo se utiliza para las llamadas entrantes y tiene un numero principal de dispositivo3 igual a 4. Sus ficheros son nombrados ttyS0, ttyS1, etc. El segundo tipo se utiliza para llamadas de salida a traves de un puerto. Sus ficheros son llamados cua0, etc y tienen un numero principal de dispositivo igual a 5. Los numeros secundarios4 son los mismos para los dos tipos. Si tiene su modem en uno cualquiera de los puertos COM1 a COM4, su numero secundario sera el numero de puerto COM mas 63. Si su configuracion es diferente aesta, como sucede, por ejemplo, en placas que soportan multiples lineas serie, debe en tal caso buscar en el documento COMO-SERIE o SERIAL-HOWTO. Asumamos que su modem esta en el COM2. En este caso su numero secundario sera 65, y su numero principal sera 5 para realizar llamadas. Deberia existir por ello, un dispositivo _____________________________________________3 N. del T.: Del ingles major number 4 N. del T.: Del ingles minor number _______________________________________________________________________________________________________________4.4. H* *ardware Serie @ cua1 que tuviera dichos numeros de dispositivo. A continuacion vemos una lista de ttys serie del directorio /dev. Las columnas 5 y 6 muestran los numeros principal y secundario respectivamente. $ ls -l /dev/cua* crw-rw-rw- 1 root root 5, 64 Nov 30 19:31 /dev/cua0 crw-rw-rw- 1 root root 5, 65 Nov 30 22:08 /dev/cua1 crw-rw-rw- 1 root root 5, 66 Oct 28 11:56 /dev/cua2 crw-rw-rw- 1 root root 5, 67 Mar 19 1992 /dev/cua3 Si no existiesen tales dispositivos, entonces tendria que crearlos. Para ello, conviertase en superusuario y teclee comandos como el siguiente: # mknod -m 666 /dev/cua1 c 5 65 # chown root.root /dev/cua1 Hay quien propone la creacion de un enlace simbolico del puerto serie en donde tenga su modem, a un fichero /dev/modem. De esta forma no es necesario recordar el poco intuitivo cua1. Sin embargo, podemos encontrarnos con problemas si empleamos el nombre real del dispositivo en unos programas y el simbolico en otros. La explicacion es que las aplicaciones en Unix usan un convenio de ficheros cerrojo para indicar que cierto dispositivo esta siendo utilizado por un proceso y evitar asi que pueda ser utilizado por otro al mismo tiempo. Por convenio, el nombre del fichero de bloqueo para cua1, es LCK..cua1. El uso de distintos ficheros de dispositivo para el mismo puerto implica que se puede producir ausencia de exclusion mutua en el acceso al puerto si un programa usa un nombre de dispositivo y otro programa usa el otro nombre (el simbolico). Esto puede provocar un acceso simultaneo de ambos procesos al mismo puerto y que, por tanto, ninguna de ellas funcione correctamente. 4.4 Hardware Serie Linux soporta, hoy por hoy, una amplia variedad de placas serie que utilizan el estandar RS-232. RS-232 es, en la actualidad, el estandar mas comun para comunicaciones serie en el mundo del PC. Este usa un conjunto de circuitos tanto para transmitir simples bits asi como para establecer sincronizacion. Pueden utilizarse cables adicionales para se"nalar la presencia de una portadora y para el control de flujo. Aunque el control de flujo por hardware es opcional, resulta muyutil ya que permite a cada una de las dos estaciones se"nalar cuando esta lista para recibir mas datos, o si la otra estacion debe parar hasta que el receptor procese los datos de entrada. Las lineas usadas _______________________________________________________________________________________________________________4.4. * *Hardware Serie @ para esto son las llamadas Clear to Send, despejado para envios, (CTS) y Ready to Send, listo para enviar (RTS), respectivamente. En ordenadores PC, el interfaz RS-232 es controlado generalmente por un chip UART descendiente del chip 16450 de National Semiconductor, o bien de una nueva version de este: el NSC 16550A5. Algunas marcas (principalmente los modems internos equipados con un chip Rockwell) tambien usan chips completamente diferentes que han sido programados para comportarse como si fueran un 16550. La principal diferencia entre los 16450 y los 16550 estriba en que el primero tiene un buffer de 1 byte mientras que el segundo lo tiene de 16 bytes. Esto hace al 16450 valido para velocidades maximas de 9600 baudios, mientras que para velocidades superiores se requiere un chip compatible con el 16550. Ademas de estos chips, Linux tambien soporta el chip 8250, que era el chip UART original de los PC de IBM. En la configuracion por defecto, el nucleo comprueba los cuatro puertos serie estandar, es decir, del COM1 hasta el COM4, a los que les asignara los numeros secundarios desde el 64 hasta el 67, tal y como se ha descrito anteriormente. Si desea configurar su puerto serie adecuadamente, tendria que incluir la orden setserial de Ted Tso en el fichero de comandos rc.serial, el cual es invocado durante el arranque del sistema desde el fichero de comandos de inicializacion /etc/rc. Este primer fichero, usa setserial para configurar los dispositivos serie del nucleo. Un tipico fichero de comandos rc.serial tendra el siguiente aspecto: # /etc/rc.serial - guion de configuracion de la linea serie # # Deteccion de interrupciones libres /sbin/setserial -W /dev/cua* # Configurar dispositivos serie /sbin/setserial /dev/cua0 auto_irq skip_test autoconfig /sbin/setserial /dev/cua1 auto_irq skip_test autoconfig /sbin/setserial /dev/cua2 auto_irq skip_test autoconfig /sbin/setserial /dev/cua3 auto_irq skip_test autoconfig # Muestra la configuracion de dispositivos serie /sbin/setserial -bg /dev/cua* Si desea conocer mas sobre los parametros de setserial, por favor, consulte la documentacion que acompa"na al programa. _____________________________________________5 Habia tambien un NSC 16550, pero este chip FIFO nunca funciono realmente. _______________________________________________________________________________________________________________4.4. H* *ardware Serie @ Si su tarjeta serie no es detectada, o la orden setserial -bg muestra una configuracion incorrecta, tendra que forzar la configuracion suministrando explicitamente los valores co- rrectos. Esta comprobado que los modems internos equipados con los chips de Rockwell experimentan este tipo de problemas. Asi, por ejemplo, si se obtiene que el chip de una UART es el NSC 16450, siendo en cambio del tipo NSC 16550, se tendra que cambiar la configuracion del puerto implicado de la forma siguiente: /sbin/setserial /dev/cua1 auto_irq skip_test autoconfig uart 16550 Existen opciones similares para forzar los puertos COM, direcciones base, y configuracion de peticion de interrupcion (IRQ). Por favor consulte la pagina del manual de setserial(8) para mas informacion. Si su modem soporta control de flujo mediante hardware, asegurese de activarlo. Sor- prendentemente, la mayoria de los programas de comunicaciones no intentan activarlo por defecto. Por ello, lo mejor es realizarlo manualmente, y la mejor forma de lograrlo es incluirlo en el fichero de comandos rc.serial usando la orden stty: $ stty crtscts < /dev/cua1 Para comprobar si el control de flujo por hardware esta activo use: $ stty -a < /dev/cua1 Este comando le devolvera el estado de todos los parametros de dicho dispositivo. Un parametro precedido con un signo menos como en -crtscts significa que ha sido desacti- vado. Capitulo 5 Configuracion del Protocolo TCP/IP En este capitulo recorreremos todos los pasos necesarios para configurar el protocolo TCP/IP en su maquina. Empezando en la asignacion de direcciones IP, iremos describiendo la configuracion de las interfaces TCP/IP e introduciremos unas cuantas herramientas que resultan bastanteutiles a la hora de resolver problemas surgidos durante la instalacion de la red. La mayoria de las tareas descritas en este capitulo, generalmente, solo habra de ejecu- tarlas unaunica vez. Una vez hecho esto, solo tendra que tocar alguno de los ficheros de configuracion cuando a"nada un nuevo sistema a su red, o si decide reconfigurar el sistema completamente. Algunos de los comando usados para configurar el protocolo TCP/IP, sin embargo, deben ser ejecutados cada vez que se arranca el sistema. La forma usual de llevar esto a cabo es a traves de los scripts /etc/rc. Generalmente, las partes especificas de la red estan contenidas en una macro llamada rc.net o rc.inet. A veces tambien son llamadas rc.inet1 o rc.inet2, siendo la primera la encargada de inicializar la parte del nucleo que se ocupa de las comunicaciones, mientras que la segunda es la que se encarga de arrancar los servicios basicos y las aplicaciones. En todo lo que sigue, asumire que esesta la estructura presente en el sistema. Mas abajo describire las acciones llevadas a cabo por rc.inet1, mientras que las aplicacio- nes son cubiertas por los capitulos posteriores. Al finalizar este capitulo, deberia usted haber establecido la secuencia de comandos que configuran correctamente el protocolo TCP/IP en su ordenador. Substituya los comandos de ejemplo en rc.inet1 por los suyos propios; asegurese de que rc.inet1 es ejecutada en el arranque y rearranque su maquina. Los scripts rc que acompa"nen a su distribucion de Linux favorita deberian ser un buen ejemplo. 59 _______________________________________________________________________________________________________________5.1. C* *onfiguracion del Sistema@ 5.1 Configuracion del Sistema de Ficheros proc Algunas de las herramientas de configuracion de Net-2 utilizan el sistema de ficheros proc para comunicarse con el nucleo. Se trata de una interface que permite el acceso a la informacion del kernel en funcionamiento a traves de un sistema de ficheros. Una vez ha sido montado, se pueden listar los ficheros y ver su contenido como en cualquier otro sistema de ficheros. Normalmente aparecen ficheros como loadavg, que contiene la carga media del sistema, o meminfo, que contiene informacion sobre la memoria fisica y virtual. El codigo de redes a"nade a esto el directorio net. Este directorio contiene una serie de ficheros con informacion sobre las tablas ARP del nucleo, el estado de las conexiones TCP y las tablas de encaminamiento. La mayoria de las herramientas de administracion de redes utilizan estos ficheros para acceder a la informacion que precisan. El sistema de ficheros proc (tambien llamado procfs) es montado generalmente en /proc durante el arranque. El mejor metodo consiste en a"nadir la siguiente linea al fichero /etc/fstab: # Lugar de montaje de procfs: none /proc proc defaults y ejecutar "mount /proc" desde uno de los macros /etc/rc. El procfs viene configurado actualmente en la mayoria de los nucleos por defecto. Si no tiene el procfs en su nucleo, al intentar montarlo obtendra el mensaje "mount: fs type procfs not supported by kernel". De ser asi tiene que recompilar el nucleo asegurando- se de configurarlo incluyendo el soporte para procfs. 5.2 Instalacion de los Ejecutables Si esta utilizando alguna de las distribuciones de Linux, probablemente incluira las apli- caciones y utilidades de red fundamentales asi como un conjunto coherente de ficheros de configuracion de ejemplo. Elunico caso en el que tendria que conseguir e instalar las nuevas utilidades es en el caso de instalar una nueva version del nucleo. De forma ocasional, esto supone cambios en la capa de comunicaciones del nucleo. Eso significaria tener que actua- lizar tambien las herramientas de configuracion. Esto se traduce en, al menos, la necesidad de recompilar, aunque a veces es posible conseguir un conjunto de ejecutables actualizados en ficheros llamados net-XXX.tar.gz, donde XXX es la version de que se trate. En el caso de Linux 1.0 es la numero 0.32b, y la version del nucleo en el momento en que se escribio este libro (1.1.12 y posterior) requiere 0.32d. _______________________________________________________________________________________________________________5.3. O* *tro Ejemplo @ Si quiere compilar e instalar las aplicaciones estandar de comunicaciones TCP/IP, puede obtener los ficheros fuente de la mayoria de los servidores FTP de Linux. Se trata de versiones modificadas de las fuentes de Net-BSD y otros. Otras aplicaciones, como Xmosaic, xarchie, o Gopher y los clientes IRC deben obtenerse por separado. La mayoria compila sin necesidad de modificaciones si se siguen las instrucciones particulares. El servidor FTP oficial de Net-3 es sunacm.swan.ac.uk, que es replicado en sunsi- te.unc.edu bajo system/Network/sunacm. Elultimo parche y los ejecutables de Net-2e estan disponibles en ftp.aris.com. El codigo derivado de BSD, de Matthias Urlichs, se encuentra en ftp.ira.uka.de, en el directorio /pub/system/linux/netbsd. 5.3 Otro Ejemplo Para lo que queda de este libro, voy a utilizar un ejemplo menos complejo que el de la Uni- versidad Groucho Marx, y que puede acercarse mas a las tareas que realmente tendra que realizar. La Cervecera Virtual, es una peque"na compa"nia que produce, como su nombre in- dica, cerveza virtual. Para gestionar su negocio mas eficientemente, los cerveceros virtuales quieren conectar sus ordenadores, que casualmente son PCs bajo Linux 1.0, en red. En el mismo piso, justo al otro lado del edificio se, encuentra la Vinatera Virtual, que trabaja de cerca con la cervecera. La vinatera tiene una red Ethernet propia. Naturalmente, ambas compa"nias quieren unir sus redes una vez queestas se encuentren operacionales. Como un primer paso, quieren establecer una pasarela que pase los datagramas de una subred a otra. Para mas tarde, tienen planeado establecer un enlace UUCP con el exterior, a traves del cual intercambiaran noticias y correo electronico. A largo plazo, quieren establecer una conexion ocasional usando SLIP con la Internet. 5.4 Establecimiento del Nombre de la Maquina La mayoria de las aplicaciones de red, si no todas, asumen que el nombre dado a la maquina local tiene un valor razonable. Este proceso tiene lugar durante el arranque cuando se ejecuta el comando hostname. Para llamar nodo1 a un ordenador ejecutaria # hostname nodo1 Es una practica comun usar el nombre sin cualificarlo con el dominio de red. Asi pues, supongamos que las maquinas de la Cervecera Virtual se llamaran vale.vbrew.com, _______________________________________________________________________________________________________________5.5. A* *signacion de una direcci@ vlager.vbrew.com , etc. Estos son los nombres oficiales, los nombres completamente cua- lificados de dominio (FQDN1). Los nombres locales serian por tantounicamente el primer componente del nombre, como por ejemplo vale. Sin embargo, dado que el nombre local se usa frecuentemente para buscar la direccion IP correspondiente, debe asegurarse de que la tabla que contiene esa informacion sea capaz de encontrarla. Esto generalmente equivale a a"nadir el nombre local al fichero /etc/hosts (ver mas abajo). Algunas personas sugieren la utilizacion del comando domainname para fijar el valor del dominio para el nucleo. Asi, para obtener el FQDN combinariamos la salida de hostname y domainname. Sin embargo esto es, en el mejor de los casos, una verdad a medias. domain- name se usa por lo general para establecer el domino NIS al que pertenece la maquina que puede ser completamente diferente al del servidor de nombres (DNS). Hablaremos de NIS en el capitulo 10. 5.5 Asignacion de una direccion IP Si configura su software de red para operar su maquina de forma aislada (por ejemplo con el objeto de utilizar el software de noticias de red INN) puede saltarse esta seccion pues solo necesita la direccion de la interface de lazo. Las cosas son algo mas complicadas en redes reales como las Ethernets. Si quiere conectar su ordenador a una red, tiene que pedir a los administradores de la misma que le asignen una direccion IP para esa red. Cuando es usted mismo el que esta estableciendo la red, tendra que ser usted quien asigne las direcciones IP segun se describe a continuacion. Las maquinas de una red local deben generalmente compartir direcciones de una subred logica. Por ello lo primero es asignar una direccion IP para la red. Si tiene varias redes fisicas, debera asignar numeros de red completamente diferentes a cada una o dividir el rango de direcciones IP disponibles en varias subredes. Si su red no esta conectada con Internet, es libre de elegir cualquier direccion (valida). Solo tiene que asegurarse de elegir una de entre los tipos A, B, o C, o, de otro modo, no iran bien las cosas. Sin embargo, si planea conectarse a la Internet en un futuro cercano, tiene usted que obtener una direccion IP oficial ya. La mejor forma es pedir ayuda a su proveedor de servicios de Internet. Si quiere pedir una direccion oficial en prevision de que se conecte a la Internet algun dia, pida un formulario de solicitud de direccion de red a hostmaster@internic.net. Para operar varias redes Ethernet (o de otro tipo una vez que el controlador correspon- diente este disponible), debe dividir su red en subredes. Es importante notar que esto es _____________________________________________1 N. del T.: Del ingles fully qualified domain name _______________________________________________________________________________________________________________5.5. A* *signacion de una direcci@ 191 72 0 0 191 72 1 0 191 72 2 0 Subred Cervecera Pasarela Subred Vinatera Figura 5.1: Cervecera Virtual y Vinatera Virtual - las dos subredes. unicamente necesario si tiene mas de una direccion de "difusion"(broadcast ) en la red; las conexiones punto-a-punto no cuentan. Asi, por ejemplo, si tiene una red Ethernet y uno o mas enlaces SLIP con el exterior no hace falta que divida su red. La razon se explica en el capitulo 7. A modo de ejemplo, el administrador de la red de la cervecera solicita al NIC una direc- cion de red de tipo B, siendole asignada la numero 191.72.0.0. Para acomodar dos redes ethernet, decide usar ocho bits de la parte de la direccion correspondiente a los ordenadores como direccion de subred. Eso deja otros ocho bits para las maquinas lo que equivale a 254 por cada subred. La red de la cervecera se convierte asi en la subred 1 y la de la vinatera en la subred 2. Las direcciones de red seran por tanto 191.72.1.0 y 191.72.2.0. La mascara de red sera 255.255.255.0. A vlager, que actua de pasarela entre las redes, se le asigna el numero de maquina 1 en ambas redes, lo que significa que tiene las direcciones IP, 191.72.1.1 y 191.72.2.1, respectivamente. La figura 5.1 muestra las dos subredes y la maquina que actua de enlace. Es importante notar que en este ejemplo estamos usando una red de clase B para simplificar; una red de tipo C seria mas realista. Con el nuevo codigo de red, la division en subredes no esta limitada a nivel de byte, de forma que incluso una red de clase C puede dividirse en varias subredes. Por ejemplo, podria usar 2 bits del byte de los nodos para designar la subred lo que permite implementar cuatro subredes de 64 maquinas cada una.2 _____________________________________________2 La ultima direccion en realidad se reserva como direccion de difusion, aquella a la que se envian mensajes destinados a todas las maquinas de la red correspondiente, lo cual en realidad deja solo 63 por subred. _______________________________________________________________________________________________________________5.6. P* *reparacion de los ficher@ 5.6 Preparacion de los ficheros hosts y networks Una vez ha dividido su red en subredes, debe habilitar un mecanismo simple de resolucion de nombres usando el fichero /etc/hosts. Si no va a usar los sistemas DNS o NIS para la resolucion de nombres, debe poner todos los nombres de las diferentes maquinas en el fichero hosts. Incluso si planea utilizar los servicios DNS y NIS en condiciones normales de operacion, es conveniente tener un reducido numero de maquinas en /etc/hosts. Por un lado, hay situaciones en las que es necesario resolver algunos nombres incluso cuando no hay servicios de red ejecutandose. Este es el caso del arranque. Se trata, no solo de una cuestion de conveniencia, sino que permite el uso de nombres simbolicos para las maquinas citadas en las macros rc.inet. De esta forma, para cambiar las direcciones IP, solo tiene que copiar el fichero hosts modificado a todas las maquinas y rearrancar, en vez de tener que modificar un gran numero de macros rc por separado. Generalmente, tambien debe incluir los nombres y direcciones locales en hosts, a"nadiendo los de las maquinas que enlacen varias redes y los servidores NIS si existen.3 Tambien, en la fase inicial de pruebas, deberia asegurarse de que el subsistema de resolucion utiliza la informacion del fichero hosts unicamente. Su software DNS o NIS puede incluir ficheros de configuracion a modo de ejemplo que pueden producir resultados extra"nos si son usados. Para forzar a que todas las aplicaciones utilicen /etc/hosts de forma exclusiva cuando buscan una direccion IP, debe editar el fichero /etc/host.conf. Desactive con comentarios cualquier linea que comience por order a"nadiendo una almohadilla (#) e incluya la siguiente linea order hosts La configuracion de la libreria de resolucion se describe en detalle en el capitulo 6. El fichero hosts contiene un registro por linea, consistente en una direccion IP, un nombre de maquina y de forma opcional, una lista de alias para esa maquina. Los campos se separan por tabuladores o espacios y el campo con la direccion debe empezar en la primera columna. Cualquier cosa a continuacion de una almohadilla (#) es interpretado como un comentario y es consecuentemente ignorado. Los nombres de las maquinas pueden ser con cualificacion completa, o relativos al do- minio actual. Para la maquina vale, el registro generalmente incluiria el nombre con cua- _____________________________________________3 Solo necesita incluir las direcciones de los servidores NIS si utiliza el servidor NYS de Peter Eriksonn. Otras implementaciones de servidores NIS son capaces de localizar los servidores cuando estan siendo eje- cutados, utilizando ypbind. _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ lificacion completa, vale.vbrew.com, y vale en el fichero hosts, de forma que pueda ser referido usando el nombre oficial y el nombre local que es mas corto. Este es un ejemplo del aspecto que el fichero hosts de la Cervecera Virtual podria tener. Hay dos nombres especiales vlager-if1 y vlager-if2, correspondientes a las direcciones de ambas interfaces de la maquina existentes en vlager. # # Fichero Hosts de la Cervecera Virtual/Vinatera Virtual # # IP local fully qualified domain name # 127.0.0.1 localhost # 191.72.1.1 vlager vlager.vbrew.com 191.72.1.1 vlager-if1 191.72.1.2 vstout vstout.vbrew.com 191.72.1.3 vale vale.vbrew.com # 191.72.2.1 vlager-if2 191.72.2.2 vbeaujolais vbeaujolais.vbrew.com 191.72.2.3 vbardolino vbardolino.vbrew.com 191.72.2.4 vchianti vchianti.vbrew.com Del mismo modo que con las direcciones IP, a veces tambien puede interesarle usar nombres simbolicos para los numeros de red. Con este objeto, el fichero hosts tiene un com- pa"nero llamado /etc/networks, que asocia nombres de red con los numeros correspondientes y viceversa. En la Cervecera Virtual, podrimos instalar un fichero networks comoeste:4 # /etc/networks para la Cervecera Virtual brew-net 191.72.1.0 wine-net 191.72.2.0 5.7 Configuracion de la Interface para IP Una vez ha configurado su hardware segun se ha explicado en el capitulo anterior, debe asegurarse de que el software de red del nucleo conoce esos dispositivos. Hay una serie de comandos que se usan con objeto de configurar las interfaces de red e inicializar la tabla de encaminamiento. Esas tareas son ejecutadas generalmente por la macro rc.inet1 cada _____________________________________________4 Es importante notar que los nombres en networks no deben coincidir con nombres de maquinas en hosts, o algunos programas pueden producir resultados extra"nos. _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ vez que el sistema es arrancado. Las herramientas basicas son ifconfig (donde "if" significa interface), y route. ifconfig se usa para dar dar acceso al nucleo a una interface. Esto incluye la asignacion de una direccion IP y otros parametros, asi como la activacion de la interface. Por activacion nos referimos a permitir que el nucleo envia y recibe datagramas IP a traves de la interface. El modo mas sencillo de invocar esta herramienta es ifconfig interface direccion-ip que asigna direccion-ip a interface y la activa. Los otros parametros toman valores asignados por defecto. Por ejemplo, la mascara de subred toma el valor correspondiente al tipo de red al que pertenece la direccion IP. Asi, tendriamos 255.255.0.0 para una direccion de clase B. ifconfig es descrito en detalle al final del capitulo. route permite a"nadir o quitar rutas de la tabla de encaminamiento del nucleo. Se puede invocar como route [add|del] destino donde los argumentos add y del determinan, respectivamente si se debe a"nadir o borrar la ruta hacia destino . 5.7.1 La Interface de Bucle o Loopback La primera interface en ser activada es la interface de lazo o loopback: # ifconfig lo 127.0.0.1 Ocasionalmente, tambien vera que el nombre comodin localhost es usado en vez de la direccion de IP. ifconfig buscara el nombre en el fichero hosts que debe contener un registro declarando localhost como nombre valido para la direccion 127.0.0.1: # Registro ejemplo de localhost en /etc/hosts localhost 127.0.0.1 Para ver la configuracion de una interface, basta ejecutar el programa ifconfig usando el nombre de la interface como argumento: _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ $ ifconfig lo lo Link encap Local Loopback inet addr 127.0.0.1 Bcast [NONE SET] Mask 255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0 Como podra observar, la mascara asignada a la interface de lazo es 255.0.0.0, debido a que 127.0.0.1 es una direccion de clase A. La interface no tiene establecida ninguna direccion de difusion, ya queesta no suele ser demasiadoutil para lazos. Sin embargo, si va a ejecutar el demonio rwhod en su maquina, tendra seguramente que fijar la direccion de difuon del dispositivo de lazo para que rwho funcione correctamente. El modo de fijar dicha direccion se explica en la seccion "5.8", mas abajo. Ahora, ya casi puede empezar a jugar con su "mini-red". Solo resta a"nadir una entrada en la tabla de encaminamiento que comunique al IP que puede usar esa interface como ruta hacia 127.0.0.1. Para llevar esto a cabo, basta escribir: # route add 127.0.0.1 Tambien aqui puede usar localhost en lugar de la direccion IP. Lo siguiente es comprobar que todo funciona como es debido, por ejemplo usando ping. ping es el equivalente a un sonar en una red5 y se usa para verificar que una direccion dada es accesible y para medir el retraso entre el envio de un datagrama y su recepcion de vuelta. Este tiempo es conocido como tiempo de ida y vuelta. # ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=32 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=32 time=0 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=32 time=0 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0/0/1 ms Cuando se ejecuta ping segun se muestra aqui, la emision de paquetes continua a menos que sea interrumpida por el usuario. El ^C marca el momento en el que se apreto Ctrl-C. _____________________________________________5 >Alguno recuerda "Echoes" de Pink Floyd? _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ Este ejemplo muestra que los paquetes dirigidos a la maquina 127.0.0.1 estan siendo entregados correctamente y la respuesta a ping es recibida de forma casi instantanea. Esto significa que ha establecido conexito su primera interface de red. Si la salida de ping no se parece a la de mas arriba, tiene usted problemas. Compruebe la posibilidad de que algun fichero no haya sido instalado correctamente. Compruebe que los ejecutables ifconfig y route son compatibles con la version del nucleo que usa y sobre todo queeste ha sido compilado con la opcion de red activada (esto se puede ver comprobando que existe el directorio /proc/net ). Si el mensaje de error es "Network unreachable"(red inaccesible), seguramente ejecuto el comando route incorrectamente. Asegurese de que es la misma direccion que la que uso con ifconfig. Los pasos descritos arriba son suficientes para poder ejecutar aplicaciones de red en una maquina aislada. Una vez esas lineas son a"nadidas a rc.inet1 y despues de asegurarse de que las dos macros rc.inet son ejecutadas desde /etc/rc, puede proceder a rearrancar su maquina y probar las diferentes aplicaciones de red. Por ejemplo "telnet localhost " deberia establecer una conexion telnet con su maquina, pidiendole el nombre de usuario y la contrase"na. Sin embargo, la interface de lazo esutil, no solo como ejemplo en libros de redes, o como metodo de pruebas durante el desarrollo: tambien la utilizan algunas aplicaciones como modo normal de operacion.6 Por ello, debe usted configurarla siempre, independientemente de que su maquina este conectada a una red o no. 5.7.2 Interfaces Ethernet La configuracion de una interface Ethernet es mas o menos igual que la de la interface de lazo. Solo requiere algunos parametros mas cuando esta usando varias subredes. En la Cervecera Virtual, hemos dividido la red IP, originalmente de clase B, en subredes de clase C. Para que la interface reconozca esto, el comando usando ifconfig seria: # ifconfig eth0 vstout netmask 255.255.255.0 Esto asigna a la interface eth0 la direccion IP de la maquina vstout(191.72.1.2). Si hubiesemos omitido la mascara de red, ifconfig habria deducido la mascara de la clase de la red IP, tomando por tanto 255.255.0.0. Una comprobacion rapida nos da: # ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 _____________________________________________6 Por ejemplo, todas las aplicaciones basadas en RPC utilizan la interface de lazo para registrarse en el demonio portmapper(mapa de puertos) durante el arranque. _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0 Puede ver que ifconfig ha fijado la direccion de difusion automaticamente (el campo Bcast de arriba) a su valor usual, que es el de la red con todos los bits de la maquina activados. Ademas se fija la unidad de transferencia de mensajes (tama"no maximo que el nucleo va a generar para esa interface) a un maximo de 1500 bytes. Todos estos valores pueden ser especificados mediante opciones especiales que se explican mas tarde. De forma semejante al caso de la interface de lazo, debe tambien ahora establecer una entrada en la tabla de encaminamiento que informe al nucleo de que la red es accesible mediante eth0. Para la Cervecera Virtual, ejecutaria # route add -net 191.72.1.0 Inicialmente podria parecer algo magico, pues no esta claro como route detecta cual es la interface que debe usar. Sin embargo el truco es sencillo: el nucleo comprueba todas las interfaces que han sido configuradas hasta el momento y compara la direccion de destino (191.72.1.0 en este caso) con la parte de red de las direcciones de las interfaces (o, lo que es lo mismo, ejecuta un "Y" logico de la direccion de la interface y la mascara de red). La unica interface que cumple esto es eth0. Veamos, >que significa la opcion -net? Esta opcion es necesaria porque el programa route es capaz de trabajar con rutas a redes o a maquinas concretas (como vimos arriba en el caso de localhost). Cuando la direccion es dada en notacion de cuaterna, intenta adivinar si se trata de una red o una maquina fijandose en los bits de maquina de la direccion. Si esa parte es nula, route asume que se trata de una red, y de otro modo lo toma como direccion de una maquina. Por tanto, route supondria que 191.72.1.0 es la direccion de una maquina en vez de una red, debido a que no sabe que hemos dividido el espacio de direcciones en subredes. Por tanto hemos de decirselo de forma explicita utilizando el indicador -net. Por supuesto, escribir el comando route es tedioso y susceptible de muchos errores de escritura. Un metodo mas conveniente es usar los nombres definidos en /etc/networks como vimos mas arriba. Esto hace el comando mas inteligible; de este modo incluso podemos evitar escribir el indicador -net, porque route sabe que 191.72.1.0 representa una red. # route add brew-net _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ Una vez finalizados los pasos basicos de configuracion, debemos asegurarnos de que la interface Ethernet esta funcionando correctamente. Elija una maquina de su red, por ejemplo vlager, y escriba # ping vlager PING vlager: 64 byte packets 64 bytes from 191.72.1.1: icmp_seq=0. time=11. ms 64 bytes from 191.72.1.1: icmp_seq=1. time=7. ms 64 bytes from 191.72.1.1: icmp_seq=2. time=12. ms 64 bytes from 191.72.1.1: icmp_seq=3. time=3. ms ^C ----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 3/8/12 Si el resultado no es similar aeste, algo va mal, obviamente. Una tasa de perdida de paquetes7 inusualmente alta, sugiere un problema de hardware, como terminaciones en mal estado o incluso la ausencia de las mismas, etc. Si no recibe ningun paquete, debe comprobar la configuracion de la interface mediante netstat. Las estadisticas de paquetes producidas por ifconfig le indican si algun paquete ha sido enviado mediante esa interface. Si tiene acceso a una maquina remota, tambien deberia dirigirse a esa maquina y comprobar las estadisticas de la interface. De este modo puede determinar exactamente en que momento se han descartado los paquetes. Ademas, debe consultar la informacion de encaminamiento con route para ver si ambas maquinas han registradoesta correctamente en sus tablas. route imprime la tabla de encaminamiento del nucleo completa si se ejecuta sin argumentos (la opcion -n hace que utilice la notacion de cuaternas en vez de los nombres de las maquinas): # route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 191.72.1.0 * 255.255.255.0 U 1 0 10 eth0 El significado de cada uno de los campos se detalla mas adelante en la seccion "Compro- bacion mediante netstat ". La columna Flags contiene una lista de los indicadores activos en cada interface. U indica que la interface esta activa y H indica que la direccion de destino es una maquina. Si encuentra que el indicador H se ha activado para una ruta que pretendia usar para una red, entonces debe usar la opcion -net con el comando route. Para com- probar si alguna ruta esta siendo usada o no, debe mirar si el campo Use en la penultima columna se incrementa entre dos ejecuciones sucesivas de ping. _____________________________________________7 N. del T.: Del ingles packet loss rate _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ 5.7.3 Encaminamiento a traves de una Pasarela En la seccion anterior, cubri solo el caso en el que la maquina solo tiene unaunica Ethernet. Frecuentemente, es posible encontrar redes conectadas unas a otras a traves de pasarelas o maquinas de enlace. Estas pasarelas pueden simplemente unir dos o mas Ethernets, pero pueden tambien servir de enlace con el exterior, con la Internet. Para usar una pasarela, es necesario a"nadir informacion adicional a la capa de red. Por ejemplo, las Ethernets de la Cervecera Virtual y de la Vinatera Virtual estan unidas a traves de una pasarela, vlager. Suponiendo que la maquina vlager ha sido configurada ya, solo tenemos que a"nadir otro registro a la tabla de encaminamiento de la maquina vstout que le comunique al nucleo que puede acceder a todos las maquinas de la red de la Vinatera a traves de vlager. La orden apropiada usando route se muestra a continuacion; la palabra clave gw indica que el argumento siguiente es una pasarela: # route add wine-net gw vlager Por supuesto, cualquier host en la red de la Vinatera al que quiera dirigirse debe tener un registro analogo referido a la red de la Cervecera, o de otro modo solo podria enviar datos de vstout a vbardolino, pero la respuesta del segundo iria a parar al cubo de la basura. Este ejemplo describeunicamente una pasarela que conmuta paquetes entre dos redes Ethernet aisladas. Supongamos ahora que vlager tambien tiene una conexion a la Internet (digamos que a traves de un enlace SLIP). Nos gustaria que los datagramas destinados a cualquier direccion fuera de la red de la Cervecera fueran entregados a vlager. Esto se puede conseguir convirtiendolo en la pasarela por defecto para vstout: # route add default gw vlager El nombre de red default es una abreviatura que representa la red 0.0.0.0, o ruta por defecto. No es necesario a"nadir este nombre a /etc/networks, porque esta informacion esta contenida en el codigo de route. Una tasa alta de perdida de paquetes usando ping hacia una maquina situada detras de una o mas pasarelas, puede deberse a que la red esta muy congestionada. La perdida de paquetes no se debe tanto a deficiencias tecnicas como a exceso temporal de carga en las maquinas que actuan de enlace, provocando retrasos o incluso el descarte de datagramas entrantes. _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ 5.7.4 Configuracion de una Pasarela Configurar una maquina para conmutar paquetes entre dos Ethernets es bastante sencillo. Suponga que nos encontramos en vlager, que contiene dos tarjetas Ethernet, respectiva- mente conectadas a cada una de las dos redes. Todo lo que necesitara hacer es configurar ambas interfaces de forma separada, dandole a cada una su direccion IP correspondiente, y eso es todo. Es bastanteutil incluir la informacion de ambas interfaces en el fichero hosts del modo indicado a continuacion, de forma que tengamos nombres para referirnos a ellas tambien: 191.72.1.1 vlager vlager.vbrew.com 191.72.1.1 vlager-if1 191.72.2.1 vlager-if2 La secuencia de comandos necesaria para establecer ambas interfaces sera por tanto: # ifconfig eth0 vlager-if1 # ifconfig eth1 vlager-if2 # route add brew-net # route add wine-net 5.7.5 La Interface PLIP Si usa un enlace PLIP para conectar dos maquinas, las cosas son un poco diferentes de lo visto para una Ethernet. En caso de PLIP se trata de un enlace conocido como punto- a-punto, porque solo requiere dos maquinas ("puntos"), en contraposicion a las redes de difusion. A modo de ejemplo, consideremos un ordenador portatil de un empleado en la Cervecera Virtual que se conecta a vlager mediante PLIP. El portatil se llama vlite, y tiene ununico puerto paralelo. Durante el arranque, este puerto sera registrado como plip1. Para activar el enlace, ha de configurar la interface plip1 mediante los siguientes comandos: # ifconfig plip1 vlite pointopoint vlager # route add default gw vlager El primer comando configura la interface, diciendole al nucleo que se trata de un enlace punto-a-punto, donde la parte remota tiene la direccion vlager. El segundo instala la ruta por defecto que usa a vlager como pasarela. En vlager, se necesita ejecutar ifconfig con argumentos similares para activar el enlace (en este caso no es necesario usar route): _______________________________________________________________________________________________________________5.7. C* *onfiguracion de la Inter@ # ifconfig plip1 vlager pointopoint vlite Es interesante notar que la interface plip1 en vlager no necesita tener una direccion IP diferente, sino que puede usar la misma direccion 191.72.1.1.8 Una vez hemos configurado el encaminamiento desde el portatil a la red de la Cervecera, solo resta arbitrar un modo para que cualquier maquina en esa red pueda acceder a vlite. Un modo particularmente enrevesado seria a"nadir una ruta a las tablas de encaminamiento de cada una de las maquinas de la red para usar vlager como pasarela hacia vlite: # route add vlite gw vlager Una opcion mejor cuando tenemos que trabajar con rutas temporales es usar encami- namiento dinamico. Una forma de conseguirlo es usando gated, un demonio de encamina- miento, que debera instalar en cada una de las maquinas de la red de modo que distribuya la informacion de encaminamiento de forma dinamica. La forma mas sencilla, sin embargo, consiste en usar ARP sustituto ( proxy ARP ). Con ARP sustituto, vlager responde a cualquier pregunta ARP dirigida a vlite enviando su propia direccion Ethernet. El efecto conseguido es que todos los paquetes dirigidos a vlite terminan yendo a vlager, que se encarga de reenviarselos al portatil. Volveremos a hablar de ARP sustituto en la seccion "Comprobacion de las Tablas ARP", mas adelante. Las versiones futuras de Net-3 contendran una herramienta llamada plipconfig capaz de fijar el numero de IRQ del puerto de la impresora. Mas tarde se sustituira por un comando ifconfig mas general. 5.7.6 Las Interfaces SLIP y PPP A pesar de que los enlaces SLIP y PPP son simples enlaces punto-a-punto igual que las conexiones PLIP, hay mucho mas que decir de ellas. Generalmente, el establecimiento de un enlace SLIP incluye una llamada a un lugar de conexion remoto y el establecimiento del modo SLIP en la linea de comunicaciones serie. El uso de PPP es similar. Las herramientas necesarias para establecer un enlace SLIP o PPP se describen en los capitulos 7 y 8. 5.7.7 La Interface Comodin La interface comodin (dummy) parece un tanto exotica y sin embargo es bastante util. Resulta especialmente ventajosa para maquinas aisladas que se conectan a una red IP _____________________________________________8 Simplemente por precaucion, deberia configurar de todos modos sus enlaces PLIP o SLIP una vez que ha completado la configuracion de la tabla de encaminamiento de las Ethernets. Con algunos nucleos mas antiguos, la tabla de encaminamiento para la red puede acabar apuntando a su enlace punto-a-punto. _______________________________________________________________________________________________________________5.8. T* *odo sobre ifconfig @ mediante un enlace telefonico. Se trata en realidad de maquinas que trabajan de forma aislada la mayor parte del tiempo. El dilema con las maquinas aisladas es que el unico dispositivo activo es el de lazo, al que generalmente se le asigna la direccion 127.0.0.1. En ocasiones, sin embargo, le resultara necesario enviar datos a la direccion IP "oficial" de la maquina. Supongamos, por ejemplo, el caso del portatil vlite cuando no esta conectado a ninguna red. Una aplicacion en vlite que busque su direccion IP en el fichero /etc/hosts dara como resultado 191.72.1.65, y por tanto intentara enviar los datos a esa direccion. Como launica interface activa en ese momento es la de lazo, el nucleo no sabe que la direccion se refiere a la misma maquina. En consecuencia el nucleo descarta el datagrama y genera un error en la aplicacion. En esta situacion es cuando la interface comodin esutil, resolviendo el dilema actuando como alter ego de la interface de lazo. En el caso de vlite, simplemente debe asignarle la direccion 191.72.1.65 y a"nadir una ruta que apunte a ella. La forma correcta es pues: # ifconfig dummy vlite # route add vlite 5.8 Todo sobre ifconfig El programa ifconfig tiene muchos mas parametros que los descritos hasta ahora. General- mente se ejecuta en la forma: ifconfig interface [[-net|-host] direccion [parametros ]] interface es el nombre de la interface y direccion es la direccion IP que se asigna a dicha interface. La direccion puede estar en forma de cuaterna o usando un nombre que ifconfig buscara en /etc/hosts y /etc/networks. La opciones -net y -host fuerzan a ifconfig a tratar las direcciones dadas como direcciones de red o de maquina respectivamente. Si ifconfig es ejecutado a"nadiendounicamente el nombre de la interface, presentara la informacion de la configuracion de dicha interface. Si se ejecuta sin parametros, presenta todas las interfaces configuradas hasta el momento; usando la opcion -a fuerza a ifconfig a incluir la informacion de las interfaces inactivas. A modo de ejemplo, la consulta de la configuracion de la interface Ethernet eth0 seria: # ifconfig eth0 eth0 Link encap 10Mbps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0 _______________________________________________________________________________________________________________5.8. T* *odo sobre ifconfig @ UP BROADCAST RUNNING MTU 1500 Metric 0 RX packets 3136 errors 217 dropped 7 overrun 26 TX packets 1752 errors 25 dropped 0 overrun 0 Los campos MTU y Metric informan sobre los valores actuales de la MTU (Unidad Maxima de Transferencia) y de la metrica para una interface dada. El valor de la metrica es usado tradicionalmente por algunos sistemas operativos para calcular el coste de una ruta. Linux no usa este valor por el momento, pero lo define por razones de compatibilidad. Las lineas RX y TX dan idea de los paquetes recibidos o transmitidos sin errores, del numero de errores ocurridos, de cuantos paquetes han sido descartados, seguramente por memoria insuficiente, y cuantos han sido perdidos por desbordamiento, condicion que ocurre cuando la recepcion de paquetes es demasiado rapida y el nucleo es incapaz de dar servicio al paquete anterior antes de la llegada del nuevo paquete. Los nombres de los campos que genera ifconfig coinciden mas o menos con los parametros con los que se puede ejecutar; estos parametros son explicados mas abajo. A continuacion tenemos una lista de los parametros reconocidos por ifconfig. Los nom- bres de los indicadores correspondientes aparecen entre parentesis. Las opciones que sim- plemente activan alguna caracteristica pueden usarse para desactivarla precediendolas de un guion (-). up Marca la interface como "up" o activa, es decir, disponible para que sea usada por la capa IP. Esta opcion va implicita cuando lo que se da en la linea de comandos es una direccion . Tambien permite reactivar una interface que se ha desactivado temporalmente mediante la opcion "down". Esta opcion corresponde a los indicadores UP RUNNING. down Marca la interface como "down" o inactiva, es decir, inaccesible a la capa IP. Esto inhabilita cualquier trafico IP a traves de la interface. Es importante darse cuenta que esto no borra los registros de la tabla de encaminamiento correspondientes a esa interface de forma automatica. Si pretende desac- tivar una interface de forma permanente, deberia borrar estos registros de encaminamiento, aportando rutas alternativas si es posible. netmask mascara Esto asigna una mascara de subred a una interface. Se puede dar como un valor de 32 bits en hexadecimal precedido del prefijo 0x, o en notacion de cuaterna usando numeros decimales separados por puntos. pointopoint direccion Esta opcion se usa para enlaces IP punto-a-punto en los que intervienen _______________________________________________________________________________________________________________5.8. T* *odo sobre ifconfig @ unicamente dos maquinas. Esta opcion es necesaria para, por ejemplo, con- figurar las interfaces SLIP o PLIP. ifconfig confirma el establecimiento de una direccion punto-a-punto inclu- yendo el indicador POINTOPOINT. broadcast direccion La direccion de difusion se obtiene, generalmente, usando la parte de red de la direccion y activando todos los bits de la parte correspondiente a la maquina. Algunas implementaciones de los protocolos IP utilizan un es- quema diferente; esta opcion proporciona un metodo para adaptarse a esos entornos mas raros. (ifconfig confirma el establecimiento de una direccion de difusion incluyendo el indicador BROADCAST.) metric numero Esta opcion puede ser usada para asignar un valor de metrica a la tabla de encaminamiento creada para la interface. Esta metrica es usada por el Protocolo de Informacion de Encaminamiento (RIP, como ya hemos visto en capitulos anteriores) para construir las tablas de encaminamiento para la red. El valor usado por defecto por ifconfig es cero. Si no esta ejecutando un demonio RIP, no necesita usar esta opcion para nada; si por el contrario si lo usa, al menos solo tendra que modificar este valor en contadas ocasiones. mtu bytes Esto fija la unidad maxima de transferencia, o lo que es lo mismo, el maxi- mo numero de octetos que la interface es capaz de manejar en una unica transaccion. Para Ethernets, la MTU toma el valor 1500 por defecto; para interfaces tipo SLIP, el valor por defecto es 296. arp Esta opcion es especifica de redes de difusion como las Ethernets o las de radio-paquetes. Permite el uso de ARP, el Protocolo de Resolucion de Di- recciones, para detectar la direccion fisica de las maquinas conectadas a la red. Para redes de difusion, esta opcion es habilitada por defecto. ifconfig avisa que ARP ha sido inhabilitado mediante el indicador NOARP. -arp Inhabilita el uso de ARP para esta interface. promisc Pone la interface en modo promiscuo. En una red de difusion, esto hace que la interface reciba todos los paquetes, independientemente de si eran para ella o no. Esto permite el analisis del trafico de red utilizando utilidades como filtros de paquetes, tambien llamado fisgar 9. Se trata de una buena tecnica para localizar problemas de red que de otra forma resultan dificiles. _____________________________________________9 N. del T.: Del ingles snooping _______________________________________________________________________________________________________________5.9. C* *omprobacion mediante net@ Por otro lado, esto tambien posibilita ataques, permitiendo al atacante ana- lizar el trafico de la red en busca de claves u otras cosas peligrosas. Una proteccion posible contra este tipo de ataques es impedir que cualquiera pueda conectarse a la Ethernet. Otra es la utilizacion de protocolos de au- tentificacion seguros como Kerberos, o los programas SRA de ingreso en el sistema.10 Esta opcion corresponde al indicador PROMISC. -promisc Desactiva el modo promiscuo. allmulti Las direcciones de envio multiple son un tipo de difusion pero a un grupo de maquinas que no tienen necesariamente que pertenecer a la misma subred. El nucleo no soporta todavia direcciones de envio multiple o de multidifusion11 . Esta opcion corresponde al indicador ALLMULTI. -allmulti Desactiva las direcciones de envio multiple. 5.9 Comprobacion mediante netstat A continuacion describire una herramientautil para comprobar la configuracion y actividad de su red. Se llama netstat, aunque se trata en realidad de una coleccion de herramientas combinadas. Describiremos cada una de las funciones en las secciones siguientes. 5.9.1 Consulta de la Tabla de Encaminamiento Si ejecuta netstat usando el indicador -r, puede ver la informacion de la tabla de encami- namiento del nucleo igual que hemos venido haciendo hasta ahora con route. Para vstout, tendriamos: # netstat -nr Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 50 lo 191.72.1.0 * 255.255.255.0 U 1 0 478 eth0 191.72.2.0 191.72.1.1 255.255.255.0 UGN 1 0 250 eth0 La opcion -n hace que netstat imprima las direcciones IP en notacion de cuaterna en vez de usar los nombres simbolicos de las maquinas o las redes. Esto es especialmenteutil _____________________________________________10 SRA se puede obtener del servidor ftp.tamu.edu en el directorio /pub/sec/TAMU 11N.T.: Las versiones actuales del nucleo (2.X) si permiten el uso de direcciones de envio multiple. _______________________________________________________________________________________________________________5.9. C* *omprobacion mediante net@ si pretende evitar consultas para esos nombres a traves de la red (por ejemplo consultas a un servidor NFS o NIS). La segunda columna de la salida producida por netstat informa sobre las pasarelas a las que apunta la informacion de encaminamiento. Si una ruta no usa pasarela, el programa imprime un asterisco. La tercera columna imprime el nivel de generalizacion de una ruta. Dada una direccion IP, el nucleo recorre la tabla registro a registro haciendo un "Y" logico de la direccion y la mascara de nivel de generalizacion antes de compararla con el destino que muestra dicho registro. La cuarta columna muestra varios indicadores que describen la ruta: G La ruta utiliza una pasarela. U La interface esta activa. H Esta interface permite el acceso a una sola maquina. Este es el caso de la interface de lazo 127.0.0.1 en nuestro ejemplo. D Este indicador se activa cuando el registro es generado por un mensaje de redireccion ICMP (ver seccion 2.5). M Presente cuando este registro ha sido modificado por un mensaje de redirec- cion ICMP. La columna Ref de la salida de netstat muestra el numero de referencias a esta ruta, esto es, cuantas otras rutas dependen deesta (por ejemplo a traves de pasarelas). Las dos ultimas columnas muestran el numero de veces que cada ruta ha sido usada y la interface que procesa los datagramas para dicha ruta. 5.9.2 Consulta de las Estadisticas de una Interface Cuando se ejecuta con el indicador -i, netstat presenta las estadisticas de cada una de las interfaces de red configuradas en ese momento. Si se usa tambien la opcion -a, el resultado son todas las interfaces presentes en el nucleo, no solo aquellas que ya han sido configuradas. En vstout, netstat producira: $ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 0 0 3185 0 0 0 3185 0 0 0 BLRU eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU _______________________________________________________________________________________________________________5.9. C* *omprobacion mediante net@ Los campos MTU y Met informan de los valores de MTU y metrica configurados en la interface. Las columnas RX y TX muestran el total de paquetes recibidos y enviados respectivamente sin errores (RX-OK/TX-OK), da"nados (RX-ERR/TX-ERR), cuantos han sido descartados (RX-DRP/TX-DRP), y cuantos se han perdido por desbordamiento (RX- OVR/TX-OVR). La ultima columna muestra los indicadores activos para cada interface. Se trata de abreviaturas de una sola letra correspondientes a los nombres de los indicadores usados para configurar la interface mediante ifconfig. B Direccion de difusion activa. L Interface correspondiente a un dispositivo de lazo. M Recepcion de todos los paquetes (modo promiscuo). N No se usan pistas12 O ARP esta desactivado en esta interface. P Se trata de una conexion punto-a-punto. R Interface en uso. U Interface activa. 5.9.3 Mostrar Conexiones netstat soporta una serie de opciones que permiten mostrar los sockets13 activos y pasivos. Las opciones -t, -u, -w, y -x muestran conexiones con sockets TCP, UDP, RAW, o UNIX. Si, adicionalmente incluye el indicador -a, tambien se muestran sockets en espera de una conexion (a la escucha). Esto le permite listar todos los servidores que se ejecutan en su sistema. La ejecucion de netstat -ta en vlager produce lo siguiente: $ netstat -ta Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (State) _____________________________________________12 N.T.: Pistas aqui se refiere a un metodo de encapsulado de los datagramas IP en los que la informacion de la cabecera se coloca al final del paquete. Se usan en redes Ethernet para ayudar en el alineamiento de datos en los bordes de pagina. 13N. del T.: Literalmente significa enchufe en ingles, y se refiere a los descriptores de fichero abiertos para comunicaciones. _______________________________________________________________________________________________________________5.10. * *Comprobacion de las Tabl@ tcp 0 0 *:domain *:* LISTEN tcp 0 0 *:time *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED tcp 0 0 *:telnet *:* LISTEN tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED tcp 0 0 *:chargen *:* LISTEN tcp 0 0 *:daytime *:* LISTEN tcp 0 0 *:discard *:* LISTEN tcp 0 0 *:echo *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:login *:* LISTEN Vemos que la mayoria de los servidores estan simplemente esperando una conexion entrante. Sin embargo, la cuarta linea muestra una conexion entrante SMTP desde vstout, y la sexta informa que hay una conexion saliente tipo telnet hacia vbardolino.14 El uso del indicador -aunicamente genera informacion de los sockets de todas las clases. 5.10 Comprobacion de las Tablas ARP En ciertas ocasiones, resultautil poder ver o incluso alterar parte de las tablas ARP del nucleo, por ejemplo cuando sospecha que una direccion IP duplicada causa problemas in- termitentes en su red. La herramienta arp fue creada con este objeto. Sus opciones son: arp [-v] [-t tipohw ] -a [maquina ] arp [-v] [-t tipohw ] -s maquina direccionhw arp [-v] -d maquina [maquina ...] Todos los argumentos maquina pueden ser nombres simbolicos o direcciones IP en no- tacion de cuaterna. Si usamos el primer comando, obtendremos el registro de la tabla correspondiente a la direccion IP o maquina especificada o, en el caso de que no se especifique ninguna, se muestran todas. Asi, si ejecutaramos arp en vlager obtendriamos: # arp -a _____________________________________________14 Para saber si la conexion es entrante o saliente basta mirar los puertos. El puerto correspondiente a la maquina que llama es siempre un entero simple, mientras que la maquina receptora utiliza el puerto correspondiente al servicio en uso y que ademas es representado por netstat usando el nombre simbolico contenido en /etc/services. _______________________________________________________________________________________________________________5.10. * *Comprobacion de las Tabl@ IP address HW type HW address 191.72.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1 191.72.1.2 10Mbps Ethernet 00:00:C0:90:B3:42 191.72.2.4 10Mbps Ethernet 00:00:C0:04:69:AA que muestra las direcciones Ethernet de vlager, vstout y vale. Se puede usar la opcion -t para mostrar la informacion referente a un tipo especifico de hardware. Los valores posibles son ether, ax25, o pronet, y se refieren a Ethernet a 10Mbps, AMPR AX.25, y equipos token ring IEEE 802.5, respectivamente. La opcion -s se usa para a"nadir de forma permanente la direccion de hardware de maquina a las tablas ARP. direccionhw es la direccion de hardware y por defecto se supone que es Ethernet, especificada como una cadena de seis bytes en hexadecimal separados entre medias por dos puntos. Se puede tambien especificar la direccion de otro tipo de hardware usando la opcion -t. Un tipo de problema que puede requerir a"nadir una direccion IP manualmente a las tablas ARP es cuando, por alguna razon, una consulta ARP a una maquina remota falla, por ejemplo debido a que su controlador ARP no funciona correctamente o cuando alguna otra maquina en la red se identifica erroneamente como si ella misma tuviera esa direccion IP. Tambien es un modo, aunque algo drastico, de protejerse frente a maquinas que, conectadas a la misma Ethernet, tratan de hacerse pasar por otras. El uso de arp con el modificador -d borra todos los registros ARP que se refieran a la maquina dada. De este modo se puede forzar a una interface a que intente obtener de nuevo la direccion Ethernet que corresponda a la direccion IP en cuestion. Esto resulta util cuando un sistema mal configurado ha emitido una informacion ARP incorrecta (por supuesto, primero habra de asegurarse de que el error de configuracion ha sido subsanado). La opcion -s se puede usar tambien para implementar ARP sustituto o proxy ARP. Se trata de una tecnica especial en la que una maquina, digamos gate, actua como pasarela para otra diferente llamada fnord, haciendo como que ambas direcciones pertenecen a la misma maquina, en este caso gate. Esto se consigue haciendo publico un registro ARP para fnord que apunta a su propia interface Ethernet. De este modo, cuando cualquier maquina de la red realiza una consulta sobre fnord, gate responde con un registro que contiene su propia direccion Ethernet. La maquina que ha realizado la consulta enviara los datagramas a gate, quien se los pasa a fnord. Este tipo de cosas puede ser necesario si, por ejemplo, pretende acceder a fnord mediante una maquina DOS que tiene una implementacion de TCP incorrecta que no entiende el encaminamiento demasiado bien. Cuando usa ARP sustituto, a todos los efectos la maquina DOS ve a fnord en la subred local y, por tanto, no necesita preocuparse de como realizar _______________________________________________________________________________________________________________5.11. * *El Futuro @ el encaminamiento a traves de una pasarela. Otro aplicacion muyutil del ARP sustituto es cuando una de sus maquinas actua como pasarela para otra maquina aunque solo de forma temporal, por ejemplo, en el caso de un enlace telefonico. En un ejemplo anterior, ya nos encontramos con el portatil vlite que se conectaba a vlager mediante un enlace PLIP de vez en cuando. Por supuesto, esto solo funcionara si la direccion de la maquina para la que quiere actuar de sustituto ARP se encuentra en la misma subred IP que su pasarela. Asi, por ejemplo, vstout podria ser el sustituto ARP de cualquier maquina de la subred de la Cervecera (191.72.1.0), pero nunca para maquinas de la subred de la Vinatera (191.72.2.0). Abajo vemos el comando correcto para activar un ARP sustituto para fnord; por su- puesto, la direccion Ethernet dada debe ser la de gate. # arp -s fnord 00:00:c0:a1:42:e0 pub Para borrar el registro de ARP sustituto bastara: # arp -d fnord 5.11 El Futuro Las comunicaciones en red con Linux estan en continua evolucion. Cambios fundamentales en el nucleo permitiran un esquema de configuracion muy flexible que permitira que confi- gure los dispositivos de red en tiempo de ejecucion. Por ejemplo, ifconfig tendra argumentos que permitan fijar la linea IRQ y el canal DMA. Otro cambio que se espera pronto es el indicador adicional mtu en el comando route, que permita establecer la Unidad de Transferencia Maxima para una ruta en particular. Esta MTU especifica de una ruta invalida el valor especificado para la interface. El uso tipico de esta opcion es para rutas a traves de pasarelas, en las que el enlace entre la pasarela y la maquina destinataria requiere un MTU muy bajo. Por ejemplo, supongamos que la maquina wanderer este conectada a vlager a traves de un enlace SLIP. Entonces, al enviar datos de vstout a wanderer, la capa de red en wanderer enviaria paquetes de hasta 1500 bytes, porque los paquetes son transmitidos mediante una Ethernet. El enlace SLIP, sin embargo, opera con una MTU de 296, asi que la capa de red en vlager tendria que dividir los paquetes IP en fragmentos mas peque"nos que quepan en 296 bytes. Si en vez de eso, configura la interface en vstout para que use una MTU de 296 desde el principio, se puede evitar el proceso de division, que es relativamente costoso.: # route add wanderer gw vlager mtu 296 _______________________________________________________________________________________________________________5.11. * *El Futuro @ Debe notar que la opcion mtu tambien permite que, de forma selectiva, evite los efectos de la politica las `Subredes son locales' (SNARL15 ). Se trata de una opcion de configuracion del nucleo descrita en el capitulo 3. _____________________________________________15 Del ingles Subnets Are Local Policy Capitulo 6 Servicio de nombres. Configuracion Como se comento en el capitulo 2, la red TCP/IP puede utilizar diferentes metodos para convertir nombres en direcciones IP. El mecanismo mas simple consiste en almacenar los nombres en una tabla de maquinas en el fichero /etc/hosts. Esto esunicamente interesante en el caso de peque"nas redes de area local que solo requieran la administracion de una persona, y que no tengan trafico IP con el mundo exterior. Recordamos que el formato del fichero hosts fue descrito en el capitulo 5. Alternativamente, puede utilizarse BIND - el servicio de nombres Internet de Berkeley o "Berkeley Internet Name Domain" - para traducir nombres de maquinas a direcciones IP (cosa que tambien se conoce como resolucion). Configurar BIND puede ser una laboriosa tarea pero, una vez hecho, los cambios en la topologia de la red seran mucho mas faciles de hacer. En Linux, como en muchos otros sistemas Unix, el servicio de nombres se realiza mediante un programa llamado named. Al iniciarse, carga un conjunto de ficheros maestros en su cache y espera peticiones de procesos locales o remotos. Existen distintas maneras de preparar BIND, y no es necesario ejecutar un servidor de nombres en cada maquina: generalmente, uno para toda la red es suficiente. Este capitulo le dara ideas generales acerca de como configurar y ejecutar un servidor de nombres. Si pretende usar BIND en un entorno mas complejo que una peque"na red local -tal vez con conexion a Internet- deberia echar un vistazo a un buen libro sobre BIND, como "DNS y BIND" de Cricket Liu (vea [AlbitzLiu92 ]). Ademas, le interesara echar un vistazo a los comentarios adicionales que aparecen junto a las fuentes de su version de BIND. Tam- bien existe un grupo de news para cuestiones sobre DNS: el grupo comp.protocols.tcp- ip.domains. 84 _______________________________________________________________________________________________________________6.1. L* *a biblioteca de resoluci@ 6.1 La biblioteca de resolucion Cuando hablamos del "sistema de resolucion", no nos referiremos a una aplicacion en par- ticular, sino a la biblioteca de resolucion: un conjunto de funciones que pueden encontrarse en las bibliotecas estandar del lenguaje C. Las rutinas principales son gethostbyname(2) y gethostbyaddr(2), que buscan la direccion IP de una maquina a partir del nombre y vicever- sa. Es posible configurarlas para que simplemente miren en el fichero hosts local (o remoto, si se usa NIS). Otras aplicaciones, como smail, pueden incluir diferentes rutinas para esto y necesitan cierto cuidado. 6.1.1 El fichero host.conf El fichero host.conf es fundamental para controlar la configuracion del sistema de resolucion de nombres. Se encuentra en el directorio /etc e indica al sistema de resolucion que servicios debe usar y en que orden. Las opciones del fichero host.conf deben estar en lineas distintas. Los campos deben separarse por blancos (espacios o tabuladores). Un simbolo almohadillado (#) supone desde ese punto hasta el final de la linea un comentario del fichero. Las opciones disponibles son las siguientes: order Determina el orden en el que los servicios de resolucion se usan. Opciones validas son bind para usar el servidor de nombres, hosts para buscar en /etc/hosts y nis para buscar con NIS. Puede especificarse cualquiera de las anteriores, y el orden de aparicion determina que servicio se prueba en primer lugar para intentar resolver el nombre. multi Va con las opciones on u off. Determina si una maquina del fichero /etc/hosts puede tener distintas direcciones IP o no. Esta opcion no tiene efecto en peticiones via NIS o DNS. nospoof Como se explico en el capitulo anterior, DNS le permite encontrar un nom- bre de maquina perteneciente a una direccion IP dada utilizando el dominio in-addr.arpa. Los intentos de los servidores de nombres de proporcionar un nombre falso se conocen en Ingles como "spoofing"1. Para evitar esto, el sistema puede configurarse para comprobar si las direcciones IP originales estan de hecho asociadas con el nombre obtenido. Si no, el nombre sera re- chazado y se retornara un error. Esta opcion se activa poniendo nospoof on. _____________________________________________1 N. del T.: literalmente, burla _______________________________________________________________________________________________________________6.1. L* *a biblioteca de resoluci@ alert Esta opcion puede ir con las palabras on u off. Si se activa, cualquier intento de dar nombre falso sera anotado con un mensaje enviado al sistema de registros syslog. trim Esta opcion lleva un nombre de dominio como argumento, que se quitara a los nombres antes de buscar su direccion. Esutil para las entradas del fiche- ro hosts, que podran asi ir solos los nombres de maquinas, sin el dominio. Cuando se busque una maquina con el nombre de dominio localeste sera eli- minado, haciendo que la busqueda en el fichero /etc/hosts tengaexito. Esta opcion puede ir repetida con varios dominios, de modo que su maquina podria ser local a diversos dominios. Un ejemplo de este fichero para la maquina vlager seria: # /etc/host.conf # Tenemos servidor de nombres, pero no NIS (de momento) order bind hosts # Permitir multiples direcciones multi on # Contra los nombres falsos nospoof on # Dominio local por defecto (no necesario). trim vbrew.com. 6.1.2 Variables de entorno Existen algunas variables de entorno que establecen opciones que tienen mas prioridad sobre las puestas en el fichero host.conf. Estas son: RESOLV_HOST_CONF Especifica un fichero alternativo a /etc/host.conf. RESOLV_SERV_ORDER Establece la opcion equivalente a la orden order del fichero anterior. Los servicios pueden ser hosts, bind y/o nis, separados por comas, espacios, puntos o puntos y coma. RESOLV_SPOOF_CHECK Determina la politica seguida frente a los nombres falsos. Estara completa- mente desactivada con la opcion off. Con las opciones warn y warn off se realizaran comprobaciones contra los nombres falsos, pero en el primer caso se mandaran los avisos al registro. Un valor * activa las comprobaciones _______________________________________________________________________________________________________________6.1. L* *a biblioteca de resoluci@ contra nombres falsos, pero las anotaciones en el registro se dejan como diga el fichero host.conf. RESOLV_MULTI El valor on activa la opcion "multi", y el valor off la desactiva. RESOLV_OVERRIDE_TRIM_DOMAINS Esta variable lleva una lista de dominios por defecto, similar a la puesta en el fichero host.conf con la opcion trim. RESOLV_ADD_TRIM_DOMAINS Esta variable lleva una lista de dominios por defecto que se a"nade a las que se dan en el fichero host.conf. 6.1.3 Configuracion del fichero resolv.conf Cuando se configura la libreria de resolucion para utilizar los servicios de BIND, tiene que indicarse tambien que servidores utilizar. El fichero resolv.conf contiene una lista de servidores, que si esta vacia hara considerar al sistema que el servidor esta en su maquina. Si ejecuta un servidor de nombres en su maquina local, tendra que configurarlo por separado, como se explicara despues. Si se encuentra en una red local y puede usar un servidor de nombres existente, mejor. La opcion mas importante del fichero resolv.conf es nameserver, que tiene la direccion IP del servidor de nombres a usar. Si especifican varios servidores poniendo varias lineas nameserver, se intentaran usar en el orden dado; por lo que deberia poner en primer lugar el servidor de nombres mas rapido o cercano. Actualmente, puede ponerse un maximo de tres servidores distintos. Si no hay ninguna linea nameserver, se intentara buscar el servidor en la propia maquina local. Hay dos opciones mas: domain y search, indicando la primera dominios alternativos a probar si la busqueda inicial del nombre falla. Estos dominios iran separados por blancos o tabuladores. Si no se incluye una opcion search, se construira una lista de busqueda por defecto por el dominio local mas todos los dominios padre hasta el raiz. El dominio local puede darse con la opcion domain, y si no se da ninguno el sistema de resolucion lo obtendra mediante la llamada al sistema getdomainname(2). Como lo anterior puede resultar confuso, sea el siguiente ejemplo de fichero resolv.conf para la Cervecera Virtual: # /etc/resolv.conf _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ # Nuestro dominio domain vbrew.com # # Nuestro servidor principal va a ser vlager: nameserver 191.72.1.1 Cuando se trate de traducir el nombre vale, el sistema empezara por buscar directamente vale y si falla, probara con vale.vbrew.com y finalmente vale.com. 6.1.4 Robustez del sistema de resolucion Si tiene en funcionamiento una red local dentro de otra mas grande, debera usar servidores de nombres principales siempre que sea posible. La ventaja de hacerlo asi es que se consiguen generosas memorias cache, ya que todas las peticiones de nombres les llega a ellos. Este esquema, sin embargo, tiene un inconveniente: cuando un incendio inutilizo el cable de red dorsal de nuestro departamento en la Universidad, no pudimos trabajar, pues ninguno de los servidores de nombres estaban accesibles. No funcionaban ni los terminales X ni las impresoras... Aunque no es muy habitual que las redes dorsales de las universidades sean pasto de las llamas, deberian tomarse precauciones para casos comoeste. Una solucion es poner un servidor de nombres local que se ocupe de sus nombres locales, y reenvie todas las peticiones de otros nombres a los servidores principales. Por supuesto, esto solo es posible si usted tiene un dominio propio. Alternativamente, puede mantener una copia de la tabla de nombres para su dominio o red local en el fichero /etc/hosts. En el fichero /etc/host.conf debera incluir la opcion "order bind hosts" para obligar a usar el fichero local si el servidor principal de nombres falla. 6.2 Ejecucion de named El programa que proporciona servicio de nombres en las maquinas un?x suele ser named 2. Es un servidor desarrollado inicialmente para Unix tipo BSD, con el proposito de proporcio- nar servicio de nombres a maquinas clientes y posiblemente a otros servidores de nombres. La version actualmente utilizada en casi todos los sistemas Linux es BIND-4.8.3. La nueva version, BIND-4.9.3, esta en este momento en version Beta, y pronto estara disponible para Linux. _____________________________________________2 N. del T.: Pronunciese n eim-di: _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ Esta seccion requiere ideas acerca de como funciona el Sistema de Nombres y Dominios (DNS). Si lo que sigue a continuacion le suena a chino, puede releer el capitulo 2, que le dara informacion acerca de como funciona basicamente el DNS. El programa named suele iniciarse al arrancar la maquina, y ejecutarse hasta que se apaga. Obtiene la informacion que necesita de un fichero llamado /etc/named.boot, y di- versos ficheros que contienen datos acerca de nombres de dominio y direcciones, llamados ficheros de zona. Los formatos y semantica de estos ficheros seran explicados en la siguiente seccion. Para ejecutar named, solo tiene que teclear: # /usr/sbin/named El programa named se iniciara y leera el fichero named.boot y los ficheros de zona que se especifiquen en el. Su numero de proceso sera anotado en ASCII en el fichero /var/run/named.pid, recibira ficheros de zona de los servidores principales si es necesario y comenzara a escuchar las peticiones de DNS por el puerto 53.3 6.2.1 El fichero named.boot El fichero named.boot suele ser muy peque"no y contiene punteros a ficheros con informacion de zonas y a otros servidores de nombres. Los comentarios en este fichero comienzan con un punto y coma y se extienden hasta el siguiente fin de linea. Antes de que veamos con mas detalle el formato de este fichero, observaremos el ejemplo para la maquina vlager dado en la figura 6.1.4 Los comandos cache y primary sirven para cargar informacion en named. Esta infor- macion se obtiene de los ficheros espeficados en el segundo argumento. Contienen represen- taciones textuales de los registros DNS, que veremos a continuacion. En este ejemplo, se configura named como el servidor de nombres principal para tres dominios: los que se indican con el comando primary. La primera linea dice que named actue como servidor principal para vbrew.com, tomando la informacion de zona del fichero named.hosts. El comando directory dice que todos los ficheros de zona se encuentran en el directorio indicado. _____________________________________________3 Hay varios binarios de named disponibles en los servidores de FTP, cada uno configurado de forma diferente. Algunos anotan su fichero de numero de proceso en el directorio /etc/, otros en /tmp y otros en /var/tmp. 4 Observar que los nombres de dominio del ejemplo se dan sin el punto final. Versiones anteriores del programa named parece que traten los puntos al final como errores y sin avisar descartan la linea afectada. En la version BIND-4.9.3 se intenta arreglar este tema. _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ ; ; Fichero /etc/named.boot para vlager.vbrew.com ; directory /var/named ; ; dominio fichero ;--------------------------------------------------- cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 72.191.in-addr.arpa named.rev Figura 6.1: El fichero named.boot para vlager. La entrada iniciada con la palabra cache es muy especial y debe estar presente en casi todas las maquinas que ejecuten un servidor de nombres. Su funcion es doble: indica a named que active su cache, y tambien que cargue la informacion de los servidores raiz del fichero indicado (en este caso, named.ca). Regresaremos a este concepto mas tarde. A continuacion se presenta una lista de las opciones mas importantes que podemos poner en el fichero named.boot : directory Especifica un directorio donde esten los ficheros de zona. Pueden ponerse va- rios directorios repitiendo el comando directory. De acuerdo con el estandar de sistema de ficheros para Linux, el directorio deberia ser /var/named. primary Los argumentos que lleva son un nombre de dominio y un nombre de fichero , declarando el servidor local primario para el dominio de named. Como servidor primario, named carga la informacion de zona del fichero dado. Normalmente, siempre habra por lo menos un comando primary en cada fichero named.boot, para traduccion inversa del IP 127.0.0.1, que es el in- terface de bucle o "loopback", como ya sabemos. secondary Esta sentencia tiene como parametros un nombre de dominio , una lista de direcciones y un nombre de fichero . Declara el servidor local como servidor maestro secundario para el dominio indicado. Un servidor secundario mantiene tambien informacion "autorizada" como el primario, pero en lugar de obtenerla de un fichero, la intenta obtener de un servidor primario. Debe proporcionarse al menos una direccion IP de servidor primario en la lista de direcciones. El servidor local ira contactando con cada uno de ellos hasta que transfiera conexito la base datos de zona, que _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ sera almacenada en el fichero de respaldo -copia de seguridad o backup- dado en el tercer argumento del comando. Si ninguno de los servidores primarios responde, se obtendra la informacion de zona del fichero de respaldo. named intentara entonces refrescar los datos almacenados regularmente. Es- to se explica despues cuando se vean las entradas "SOA" de los ficheros. cache Tiene como argumentos un dominio y un nombre de fichero . Contiene la lista de servidores de nombres raiz. Solo se reconoceran registros NS y A. El argumento domain es normalmente el nombre del dominio raiz ("."). Esta informacion es fundamental: si el comando cache no existiera, named no haria una cache local. Esto degradaria de forma importante el rendi- miento e incrementaria la carga de la red si los nombres que se buscan no estan en la red local. Ademas, named tampoco sera capaz de contactar con cualquier servidor de nombres raiz, y por ello, no podra resolver ninguna di- reccion excepto aquellas para las que este autorizado. Una excepcion a esta regla, ocurre cuando se usan servidores redirigidos (con la opcion forwarders explicada a continuacion). forwarders Esta opcion lleva una lista de direcciones como argumento. Las direc- ciones IP en la lista especifican servidores de nombres a los que named puede preguntar si falla una traduccion de un nombre mediante su cache local. Se intenta preguntar a todos en orden hasta que uno de ellos responda. slave Esta opcion hace que el servidor sea esclavo. Esto significa que nunca reali- zara consultas recursivas, sino que las redirigira a los servidores especificados con forwarders. Hay dos opciones adicionales que no vamos a describir: sortlist y domain. Ademas, hay dos directivas que pueden aparecer en los ficheros de zona. Son $INCLUDE y $ORIGIN, que tampoco vamos a describir, ya que raramente se utilizan. 6.2.2 Ficheros de base de datos DNS Los ficheros incluidos con named, como named.hosts, siempre tienen un dominio asociado a ellos llamado origen. Este es el nombre de dominio especificado con los comandos cache y primary. En un fichero maestro, se pueden especificar nombres de maquinas y dominios relativos a este dominio. Un nombre dado en un fichero de configuracion se considera absoluto si termina con un punto. En caso contrario se considera relativo al origen. Al origen en si mismo nos podemos referir con "@ ". Todos los datos en un fichero principal se dividen en registros de recursos o RRs. Son _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ la unidad de informacion del DNS. Cada RR tiene un tipo. Los registros de tipo A, por ejemplo, asocian un nombre a una direccion IP. Los registros de tipo CNAME asocian un alias de una maquina con su nombre oficial. Como ejemplo, observese la figura 6.3 de la pagina 96, que muestra el fichero named.hosts para nuestro sistema. La representacion de los RRs en los ficheros utiliza el siguiente formato: [domain ] [ttl ] [class ] type rdata Los campos se separan por espacios o tabulaciones. Una entrada puede continuarse en varias lineas si se abre un parentesis antes del primer fin de linea y el ultimo campo es seguido de un cierre de parentesis. Cualquier cosa entre un punto y coma y el siguiente salto de linea sera un comentario. domain Aqui va el nombre del dominio que se aplica al RR actual. Si no se da nombre de dominio, se asume el mismo que se puso para el RR anterior. ttl Con el fin de forzar al sistema DNS a descartar informacion despues de cierto tiempo, cada RR lleva asociado un "tiempo de vida" o ttl 5. El campo ttl especifica, en segundos, el tiempo de validez de la informacion desde que se obtiene del servidor. Es un numero decimal de hasta ocho digitos. Si no se especifica ningun valor, tomara uno por defecto del campo minimum del registro SOA precedente. class Aqui se indica la clase de direccion: IN para direcciones IP, HS para objetos de la clase Hesiod. Trabajando con redes TCP/IP debe usarse siempre la clase IN. Si no se especifica ningun valor, se toma el valor del RR anterior. type Describe el tipo de RR. Los tipos habituales son A, SOA, PTR y NS. En las siguientes secciones comentaremos estos tipos de RRs. rdata Contiene los datos asociados al RR. El formato depende del tipo, y se des- cribiran mas adelante. A continuacion se presenta una lista incompleta de RRs que se utilizan en los ficheros de DNS. Hay algunos mas que no vamos a comentar. Son experimentales, y de escaso uso. _____________________________________________5 N. del T.: Time to Live _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ SOA Describe una zona de autoridad (SOA significa "Start of Authority", es decir, "Comienzo de Autoridad"). Se"nala que los registros siguientes contienen informacion "autorizada" para el dominio. Cada fichero incluido en la opcion primary debe tener un registro SOA para esta zona. Los datos asociados contienen los siguientes campos: origin Nombre canonico del servidor de nombres primario para este dominio. Se suele dar como nombre absoluto. contact Direccion de correo electronico de la persona responsable de mantener el dominio, reemplazando el caracter `@ ' por un punto. Por ejemplo, si el responsable de nuestra red fuese janet, este campo contendra: janet.vbrew.com. serial Este es el numero de version del fichero de zona, expresado con un numero decimal. Cuando se cambien datos del fichero, debera incrementarse este numero. El numero de version es utilizado por los servidores secunda- rios para saber cuando la informacion de una zona ha cam- biado. Para mantenerse actualizados, los servidores secunda- rios piden cada cierto tiempo el registro SOA del primario, y comparan el numero de version con el que tienen en la ca- che. Si ha cambiado, el servidor secundario pedira de nuevo la informacion de zona al primario. refresh Especifica el intervalo, en segundos, que esperan los servido- res secundarios entre peticiones de registros SOA a los pri- marios. De nuevo, se trata de un numero decimal de hasta ocho digitos. Normalmente, la topologia de la red no cambia mucho, con lo que este numero sera como poco de un dia para grandes redes, y de mucho mas tiempo para redes peque"nas. retry Este numero determina los intervalos de tiempo entre rein- tentos de comunicacion con servidores primarios cuando una peticion de una zona falla. No debe ser peque"no ya que un fallo temporal del servidor primario hara que el secundario cargue inutilmente la red. Buenas elecciones son una hora o como poco media hora. expire Especifica el tiempo, en segundos, que tardara el servidor en descartar los datos de zona si no ha podido contactar con _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ el servidor primario. Normalmente sera grande. Asi, Craig Hunt ([Hunt92 ]) recomienda 42 dias. minimum Valor por defecto para el valor del ttl en los registros de recursos que no lo especifiquen. Sirve para indicar a otros servidores de nombres que descarten el RR tras cierto tiempo. No tiene efecto, sin embargo, sobre el tiempo en el que un servidor secundario intenta actualizar la informacion de zona. El valor de minimum debe ser grande, en especial para redes locales con topologias poco cambiantes. Una buena eleccion puede ser de una semana o un mes. En el caso de que haya registros RR que cambien con frecuencia, siempre podra asig- narle valores particulares de ttl . A Asocia direcciones IP con nombres. El campo de datos contiene la direccion separando los octetos por puntos, como es habitual. Para cada maquina solo puede haber un registro A, que se considera nombre oficial o canonico. Cualquier otro nombre sera un alias y debe ser incluido con registros CNAME. NS Apunta a un servidor de nombres maestro de una zona subordinada. Vea la seccion 2.6 para obtener informacion de por que es necesario. El campo de datos contiene el nombre del servidor. Para traducir ese nombre debe proporcionarse un registro A adicional, que se conoce como glue record, al proporcionar la direccion IP del servidor. CNAME Asocia un alias con su nombre canonico. El nombre canonico se determina con un registro A. Los alias son indicados mediante registros CNAME. PTR Se usa para asociar nombres del dominio in-addr.arpa con sus nombres normales. Se usa para obtener nombres a partir de direcciones IP (traduccion inversa). El nombre de la maquina debe ser el canonico. MX Especifica el servidor de correo para un dominio. En la seccion "Encaminado de correo en la Internet" del capitulo 13 se explica por que son necesarios estos servidores. La sintaxis del registro MX es: [domain ] [ttl ] [class ] MX preference host host es el nombre del servidor de correo para el dominio domain . Cada servidor tiene un valor entero de preferencia (preference ) asociado. Un agente de transporte de correo que desee entregar mensajes al dominio indi- _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ cado en domain lo intentara con los servidores de estos registros hasta que uno responda. Se empieza probando con los de menor preferencia. HINFO Este registro da informacion sobre el hardware y el software de la maquina. Su sintaxis es: [domain ] [ttl ] [class ] HINFO hardware software El campo hardware identifica el hardware utilizado. Existe un conjunto de convenciones sobre esto, el cual puede verse en el RFC 1340. Si el campo contiene blancos, debe encerrarse entre comillas dobles. El campo software especifica el software utilizado, para el que tambien existen convenciones en el mismo documento RFC. 6.2.3 Escribiendo los ficheros Las figuras 6.2, 6.3, 6.4, y 6.5 son ejemplos de ficheros para un servidor de nombres en nuestra red ejemplo, localizado en la maquina vlager. El ejemplo es sencillo dada la simplicidad de nuestra red. Si tiene requisitos mas complejos, lease el libro "DNS and BIND" de Cricket Liu y Paul Albitz ([AlbitzLiu92 ]). El fichero named.ca mostrado en la figura 6.2 da ejemplos de registros de servidores raiz. Un fichero de cache tipico suele tener informacion sobre una docena de servidores. Puede obtener la lista de servidores del dominio raiz mediante el programa nslookup descrito mas adelante.6 ; ; /var/named/named.ca Fichero de cache. ; No estamos en Internet, luego no necesitamos ; servidores raiz. Elimine los puntos y coma ; si desea activarlos. ; ; . 99999999 IN NS NS.NIC.DDN.MIL ; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103 ; . 99999999 IN NS NS.NASA.GOV ; NS.NASA.GOV 99999999 IN A 128.102.16.10 Figura 6.2: Fichero named.ca. _____________________________________________6 Esto no podra hacerlo si no ha especificado algun servidor raiz. Puede en cambio ejecutar nslookup con un servidor diferente del suyo, o usar el fichero de ejemplo de la figura 6.2 y entonces obtener una lista de servidores validos. _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ ; ; /var/named/named.hosts Maquinas locales en nuestra red ; El origen es vbrew.com ; @ IN SOA vlager.vbrew.com. ( janet.vbrew.com. 16 ; serial 86400 ; refresco: una vez al dia 3600 ; reintentos: una hora 3600000 ; expiracion: 42 dias 604800 ; minimo: 1 semana ) IN NS vlager.vbrew.com. ; ; el correo local se distribuye en vlager IN MX 10 vlager ; ; direccion de loopback localhost. IN A 127.0.0.1 ; Nuestra ethernet vlager IN A 191.72.1.1 vlager-if1 IN CNAME vlager ; vlager es tambien un servidor de USENET news news IN CNAME vlager vstout IN A 191.72.1.2 vale IN A 191.72.1.3 ; Otra Ethernet vlager-if2 IN A 191.72.2.1 vbardolino IN A 191.72.2.2 vchianti IN A 191.72.2.3 vbeaujolais IN A 191.72.2.4 Figura 6.3: Fichero named.hosts. _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ ; ; /var/named/named.local Traduccion inversa para 127.0.0 ; El origen es 0.0.127.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. ( joe.vbrew.com. 1 ; serial 360000 ; refresco: 100 horas 3600 ; reintento: 1 hora 3600000 ; expiracion: 42 dias 360000 ; minimo: 100 horas ) IN NS vlager.vbrew.com. 1 IN PTR localhost. Figura 6.4: Fichero named.local. ; ; /var/named/named.rev Traduccion inversa de nuestros numeros IP ; El origen es 72.191.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. ( joe.vbrew.com. 16 ; serial 86400 ; refresco: una vez al dia 3600 ; reintento: una hora 3600000 ; expiracion: 42 dias 604800 ; minimo: 1 semana ) IN NS vlager.vbrew.com. ; nuestra red 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; la otra red 1.2 IN PTR vlager-if1.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com. Figura 6.5: Fichero named.rev. _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ 6.2.4 Comprobacion del funcionamiento del servidor de nombres Existe una utilidad que resulta interesante para comprobar el funcionamiento del servidor de nombres recien configurado. Se llama nslookup, y puede usarse tanto interactivamente como desde la linea de comandos. En elultimo caso, se invoca simplemente como: nslookup nombre y pedira el nombre indicado al servidor de nombres que aparezca en resolv.conf (si aparece mas de uno, nslookup cogera uno al azar). El modo interactivo, sin embargo, es mucho mas interesante. Ademas de buscar maqui- nas por su nombre, se puede tambien preguntar por cualquier registro DNS, y transferir la informacion de zona completa de un dominio. Cuando se invoca sin argumentos, nslookup mostrara el servidor de nombres en uso y entrara en modo interactivo. En el prompt `>' que se mostrara, puede teclear cualquier nombre de dominio por el que quiera preguntar. Por defecto, preguntara por registros de tipo A, es decir, aquellos que dan una direccion IP correspondiente al dominio introducido. Esto se puede cambiar tecleando "set type=tipo", donde tipo es un nombre de registro de recurso (RR) como los descritos antes (en la seccion 6.2) o bien la palabra ANY. Por ejemplo, esta puede ser una sesion con nslookup: $ nslookup Default Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 > sunsite.unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 Non-authoritative answer: Name: sunsite.unc.edu Address: 152.2.22.81 Si intenta preguntar por un nombre que no tiene direccion IP asociada, pero se encuen- tran otros registros relacionados en el DNS, el programa respondera con un error "No type A records found" (no se encontraron registros de tipo A). Sin embargo, puede hacer pre- guntas para otro tipo de registros sin mas que usar el comando "set type". Por ejemplo, para obtener el registro SOA de unc.edu, podria escribir lo siguiente: _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ > unc.edu *** No address (A) records available for unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 > set type=SOA > unc.edu Name Server: rs10.hrz.th-darmstadt.de Address: 130.83.56.60 Non-authoritative answer: unc.edu origin = ns.unc.edu mail addr = shava.ns.unc.edu serial = 930408 refresh = 28800 (8 hours) retry = 3600 (1 hour) expire = 1209600 (14 days) minimum ttl = 86400 (1 day) Authoritative answers can be found from: UNC.EDU nameserver = SAMBA.ACS.UNC.EDU SAMBA.ACS.UNC.EDU internet address = 128.109.157.30 De manera similar, se pueden pedir registros MX, etc. Y mediante la palabra ANY se obtendran todos los RR asociados al nombre escrito. > set type=MX > unc.edu Non-authoritative answer: unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu lambada.oit.unc.edu internet address = 152.2.22.80 Authoritative answers can be found from: UNC.EDU nameserver = SAMBA.ACS.UNC.EDU SAMBA.ACS.UNC.EDU internet address = 128.109.157.30 Una aplicacion practica de nslookup para la depuracion es obtener la lista de servidores raiz para el fichero named.ca. Esto puede hacerse pidiendo todos los registros NS asociados al dominio raiz: > set type=NS > . Name Server: fb0430.mathematik.th-darmstadt.de _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ Address: 130.83.2.30 Non-authoritative answer: (root) nameserver = NS.INTERNIC.NET (root) nameserver = AOS.ARL.ARMY.MIL (root) nameserver = C.NYSER.NET (root) nameserver = TERP.UMD.EDU (root) nameserver = NS.NASA.GOV (root) nameserver = NIC.NORDU.NET (root) nameserver = NS.NIC.DDN.MIL Authoritative answers can be found from: (root) nameserver = NS.INTERNIC.NET (root) nameserver = AOS.ARL.ARMY.MIL (root) nameserver = C.NYSER.NET (root) nameserver = TERP.UMD.EDU (root) nameserver = NS.NASA.GOV (root) nameserver = NIC.NORDU.NET (root) nameserver = NS.NIC.DDN.MIL NS.INTERNIC.NET internet address = 198.41.0.4 AOS.ARL.ARMY.MIL internet address = 128.63.4.82 AOS.ARL.ARMY.MIL internet address = 192.5.25.82 AOS.ARL.ARMY.MIL internet address = 26.3.0.29 C.NYSER.NET internet address = 192.33.4.12 TERP.UMD.EDU internet address = 128.8.10.90 NS.NASA.GOV internet address = 128.102.16.10 NS.NASA.GOV internet address = 192.52.195.10 NS.NASA.GOV internet address = 45.13.10.121 NIC.NORDU.NET internet address = 192.36.148.17 NS.NIC.DDN.MIL internet address = 192.112.36.4 El conjunto completo de comandos disponibles en nslookup puede obtenerse con la orden interna help. 6.2.5 Otras utilidades interesantes Hay algunas utilidades que pueden ayudarle en sus tareas de administrador de BIND. Des- cribiremos dos de ellas. Por favor, eche un vistazo a la documentacion que traen para saber como utilizarlas. La utilidad hostcvt sirve para obtener una configuracion inicial de BIND a partir del fichero /etc/hosts. Genera tanto los ficheros de traduccion directa (registros A) como los de traduccion inversa (registros PTR) teniendo cuidado con los nombres de alias y otros. Por supuesto, no hara todo el trabajo, pues aun puede que necesite ajustar los registros SOA o _______________________________________________________________________________________________________________6.2. E* *jecucion de named @ a"nadir registros MX. Suponemos que tambien le ayudara tener cerca algunas aspirinas. El programa hostcvt forma parte de las fuentes de BIND, pero puede obtenerse por separado en algunos servidores FTP dedicados a Linux. Despues de configurar el servidor de nombres, puede que desee comprobar el resultado. La aplicacion ideal para esto (al menos para mi) es el programa dnswalk, un paquete basado en perl que navega por la base de datos DNS, buscando errores habituales y verificando que la informacion es consistente. El programa dnswalk ha sido enviado recientemente al grupo comp.sources.misc de News, y deberia estar en los servidores FTP que archiven este grupo (un servidor que seguro que lo tiene es ftp.uu.net). Capitulo 7 SLIP: IP por ilnea serie Los protocolos de linea serie, SLIP y PPP, permiten a los "pobres" tener conexion a Inter- net. Solo se necesita un modem y un puerto serie con buffer FIFO. Utilizarlo no es mas complicado que usar un buzon, y cada vez existen mas proveedores que le ofrecen acceso telefonico IP a un coste asequible para todos. En Linux hay controladores tanto de SLIP como de PPP. SLIP es mas veterano y por tanto mas estable. PPP para Linux ha sido recientemente desarrollado por Michael Callahan y Al Longyear; y se describira en el proximo capitulo1. 7.1 Requisitos generales Para utilizar SLIP o PPP, hay que configurar algunas caracteristicas de red que ya se han descrito en capitulos anteriores, por supuesto. Por lo menos, debe tener el interfaz de bucle (loopback) y el sistema de traduccion de nombres. Cuando se conecte a Internet, querra usar, por supuesto, el DNS. Lo mas facil es poner la direccion de algun servidor de nombres en el fichero resolv.conf ; este servidor se usara tan pronto como SLIP conecte. Lo mejor es poner el servidor de nombres mas cercano. Sin embargo, esta solucion no es laoptima, ya que las busquedas de nombres seguiran yendo por la conexion SLIP o PPP. Si le interesa consumir menos ancho de banda, puede instalarse un servidor de nombres solo con cache. No requiere un dominio ya que solo actuara como relevo, es decir, pasara a otro servidor las peticiones que Vd. realice. La ventaja es que construira una cache de modo que al pedir un nombre varias veces seguidas, solo se contactara con el servidor externo la primera vez. Un fichero named.boot que sirva _____________________________________________1 N. del T.: Actualmente, podemos decir que PPP ya es suficientemente estable. De hecho, SLIP cada vez se utiliza menos 102 _______________________________________________________________________________________________________________7.2. U* *tilizacion de SLIP @ para esto puede ser el siguiente: ; fichero named.boot para un servidor solo con cache directory /var/named primary 0.0.127.in-addr.arpa db.127.0.0 ; interfaz "loopback" cache . db.cache ; servidores raiz Ademas debe tener un fichero db.cache con una lista de servidores raiz validos. Este fichero esta descrito al final del capitulo dedicado a la configuracion del servidor de nombres. 7.2 Utilizacion de SLIP Los servidores de IP por telefono suelen ofrecer servicios SLIP mediante cuentas de usuario especiales. Despues de entrar en una cuenta no se entra en un interprete de comandos normal, sino en un programa o shell script que se ejecuta para activar el manejador SLIP del servidor y configurar la interfaz con la red. En ese momento tiene que hacer lo mismo en su maquina. En algunos sistemas operativos, el manejador de SLIP es un programa de usuario, pero bajo Linux es parte del nucleo, cosa que lo hace mucho mas rapido. Requiere, sin embargo, que la linea serie sea explicitamente convertida a modo SLIP. Esto se hace mediante una disciplina de linea especial llamada SLIPDISC. Mientras que un terminal (tty) esta en modo normal (DISC0), intercambiara datos solo con procesos de usuario, mediante las llamadas read(2) y write(2) habituales, y el manejador de SLIP no podra escribir o leer del terminal. En el modo SLIPDISC se cambian los papeles: ahora los programas de usuario no podran acceder a la linea pero todos los datos que lleguen se pasaran al manejador SLIP. El manejador de SLIP entiende por si mismo varias versiones del protocolo, incluyendo CSLIP, que realiza la llamada compresion de cabeceras de Van Jacobson en los paquetes IP salientes.2 Esto aumenta el rendimiento de las sesiones interactivas. Ademas, hay versiones de seis bits de estos protocolos. Una forma facil de convertir una linea serie a modo SLIP es usar la utilidad slattach. Suponiendo que tenemos un modem en /dev/cua3 y que se ha entrado correctamente en el servidor de SLIP, se debera ejecutar: # slattach /dev/cua3 & _____________________________________________2 La compresion de cabeceras de Van Jacobson se describe en el RFC 1441. _______________________________________________________________________________________________________________7.2. U* *tilizacion de SLIP @ Esto cambiara el modo de linea de cua3 a SLIPDISC, y la enganchara a uno de los interfaces SLIP disponibles. Si es launica conexion SLIP se enganchara al interface sl1, si es la segunda, a sl2, etc. Los nucleos actuales soportan hasta ocho enlaces SLIP simultaneos. La encapsulacion por defecto que elige slattach es CSLIP. Puede elegirse otra con la opcion -p. Para usar SLIP sin compresion debera ponerse: # slattach -p slip /dev/cua3 & Otros modos son cslip, slip6, cslip6 (para la version de 6 bits) y adaptive para SLIP adaptativo, que deja al nucleo averiguar que encapsulacion de SLIP usa el otro extremo de la comunicacion. Observe que debe utilizarse el mismo sistema de encapsulacion que use el otro extremo. Por ejemplo, si cowslip usara CSLIP, tendra que usarlo Vd. tambien. El sintoma tipico de una seleccion incorrecta es que la orden ping a una maquina remota no tendra respuesta. Si la otra maquina le hace ping a Vd, recibira mensajes del tipo "Can't build ICMP header" (no se puede construir la cabecera ICMP) en la consola. Una forma de intentar evitar este tipo de problemas es usar SLIP adaptativo. De hecho, slattach no solo le permite activar SLIP, sino tambien otros protocolos serie como PPP o KISS (protocolo que se usa en packet-radio). Para mas detalle, vea el manual en linea de slattach(8). Despues de preparar la linea para SLIP, tendra que configurar el interfaz de red. De nuevo, se hara esto mediante los programas estandares ifconfig y route. Suponiendo que desde la maquina vlager hemos llamado al servidor cowslip, se deberia ejecutar: # ifconfig sl0 vlager pointopoint cowslip # route add cowslip # route add default gw cowslip El primer comando configura la interface como un enlace a cowslip punto a punto, mientras que el segundo y el tercero sirven para a"nadir la ruta correspondiente a cowslip como ruta por defecto y configurar esa maquina como pasarela de todos nuestros mensajes. Cuando se quiera terminar el enlace SLIP, debe empezarse por eliminar todas las rutas a traves de cowslip mediante el comando route con la opcion del, desactivar el interface y enviar al proceso slattach la se"nal SIGHUP. Despues de esto se debera colgar el modem usando un programa de terminal de nuevo: # route del default _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ # route del cowslip # ifconfig sl0 down # kill -HUP 516 7.3 Utilizacion de dip Lo visto hasta ahora no es dificil de hacer. Sin embargo, puede que desee automatizar los pasos de modo que solo tenga que invocar un comando. El programa dip hace esto.3 La version que existe en este momento es la 3.3.7. Ha sido parcheada por mucha gente, con lo que no podremos hablar simplemente de el programa dip. Las modificaciones seran incorporadas en futuras versiones. dip tiene un interprete de un lenguaje script sencillo que puede manejar automaticamente el modem, convertir la linea a modo SLIP y configurar las interfaces. Es bastante restrictivo por lo simple que es, pero suficiente para la mayoria de los casos. Una nueva version de este programa podra traer una version mas completa del lenguaje. Para ser capaces de configurar el interfaz SLIP, dip necesita tener permisos de superu- suario. Puede hacerse poniendo el programa con el bit setuid y de propiedad del usuario root, de modo que cualquier usuario sin privilegios podra poner en marcha el programa. Esto es, sin embargo, muy peligroso, ya que una configuracion incorrecta del encaminamien- to de dip puede estropear el encaminamiento de su red local. Ademas, dara a los usuarios la posibilidad de conectarse a cualquier servidor SLIP, y lanzar ataques peligrosos a la red. Si aun quiere permitir a los usuarios activar conexiones SLIP, escriba peque"nos programas para cada servidor de modo que cada uno invoque a dip con el script especifico. Estos programas pueden tener privilegios sin peligro.4 7.3.1 Un script de ejemplo Un script de ejemplo se encuentra en la figura 7.1. Puede utilizarse para conectarse a cowslip invocando a dip de esta forma: # dip cowslip.dip DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van Kempen, MicroWalt Corporation. conectado a cowslip.moo.com with addr 193.174.7.129 # _____________________________________________3 dip significa Dialup IP y fue escrito por Fred van Kempen. 4 diplogin puede (y debe) ser ejecutado como superusuario. Vea la seccion del final de este capitulo. _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ # Script de dip para conectarse al servidor cowslip # Preparar nombres local y remoto get $local vlager get $remote cowslip port cua3 # seleccion de puerto serie speed 38400 # poner velocidad maxima modem HAYES # poner tipo de modem reset # reiniciar modem y terminal (tty) flush # limpiar buffer de respuesta del modem # Prepararse para marcado. send ATQ0V1E1X1\r wait OK 2 if $errlvl != 0 goto error dial 41988 if $errlvl != 0 goto error wait CONNECT 60 if $errlvl != 0 goto error # Ahora ya estamos conectados sleep 3 send \r\n\r\n wait ogin: 10 if $errlvl != 0 goto error send Svlager\n wait ssword: 5 if $errlvl != 0 goto error send hey-jude\n wait running 30 if $errlvl != 0 goto error # Ahora ya estamos en la cuenta. Lancemos SLIP. print Conectado a $remote with address $rmtip default # Hacer que este enlace sea nuestra ruta por defecto mode SLIP # Pasemos a modo SLIP # en caso de error se ejecuta lo siguiente error: print Fallo de la conextion SLIP con $remote . Figura 7.1: Un script de ejemplo para dip _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ Despues de conectar a cowslip y activar SLIP, dip pasara a ejecutarse en segundo plano. Ahora puede conectarse a traves del enlace SLIP mediante los programas habituales de red. Para terminar la conexion, ejecute dip con la opcion -k. Esto enviara una se"nal de colgar al proceso dip, cuyo numero se encontrara almacenado en el fichero /etc/dip.pid.5 # dip -k En el lenguaje que interpreta dip las palabras precedidas con un signo de dolar se corresponden con nombres de variables. dip tiene un conjunto predefinido de variables que se listara a continuacion. $remote y $local, por ejemplo, contienen los nombres de maquina local y remoto, respectivamente, involucrados en el enlace SLIP. Las dos primeras sentencias del ejemplo son los comandos get, que sirven para establecer variables. Aqui, las maquinas local y remota han sido vlager y cowslip, respectivamente. Las cinco sentencias que siguen preparan la linea serie y el modem. La palabra reset envia una cadena de reinicio al modem; que sera el comando ATZ para modems compati- bles con Hayes. La siguiente sentencia limpia el buffer de salida del modem, para conseguir que el dialogo de entrada (login y password) funcione correctamente. Este dialogo es ex- tremadamente simple: llama al numero 41988, que es el numero de cowslip, entra en la cuenta Svlager mediante la clave de acceso hey-jude. El comando wait hace que se espere a la aparicion de la cadena que sigue a esta orden, mientras que su segundo argumento especifica el tiempo de espera en segundos. Los comandos if sirven para ir comprobando la correccion del procedimiento de entrada en la cuenta. Los comandos finales, ejecutados tras entrar en la cuenta, son default, que hace que el enlace SLIP sea la ruta por defecto para todos los destinos y mode, que pone la linea en modo SLIP y configura automaticamente el interface y la tabla de encaminamiento. 7.3.2 Guia de Referencia de dip Aunque se utiliza mucho, dip aun no esta muy documentado. En esta seccion, daremos una peque"na guia de referencia de los comandos de dip. Puede obtenerse un resumen de los comandos ejecutando dip en modo de prueba (opcion -t), e introduciendo el comando help. Para obtener ayuda sobre un comando se debe ejecutar sin argumentos; por supuesto esto no funcionara con comandos que no tengan argumentos. $ dip -t DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van Kempen, MicroWalt Corporation. _____________________________________________5 Vea el grupo alt.tla si desea conocer mas abreviaturas en Ingles que sean palindromas, como este caso. _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ DIP> help DIP knows about the following commands: databits default dial echo flush get goto help if init mode modem parity print port reset send sleep speed stopbits term wait DIP> echo Usage: echo on|off DIP> _ En los siguientes apartados, los ejemplos que muestran el prompt DIP> indican como se introduciria el comando en modo prueba, y que salida produciria. Los ejemplos que no muestren este prompt deben tomarse como trozos de scripts. Comandos del modem Existe un conjunto de comandos de dip pensados para configurar la linea serie y el modem. Algunos son de uso obvio, como port, que sirve para elegir el puerto serie, y speed, databits, stopbits, y parity, que establecen los parametros habituales de las lineas serie. El comando modem selecciona el tipo de modem. Actualmente solo esta soportado el tipo HAYES 6. Debe decirse el tipo, pues si no dip se negara a ejecutar los comandos dial y reset. Esteultimo comando envia la cadena de reinicio al modem, la cual depende del tipo de modem elegido. Para modems compatibles Hayes, esta cadena es ATZ. La orden flush puede utilizarse para vaciar las respuestas anteriores de la memoria del modem. De otro modo, un script de dialogo con el modem podria fallar, porque lea la respuesta OK que proceda deordenes anteriormente enviadas al modem. El comando init selecciona la cadena de inicializacion enviada al modem antes de marcar, que para modems Hayes es, por defecto, la cadena "ATE0 Q0 V1 X1 ", que activa el eco de los comandos, hace que el modem de los codigos de resultado en modo extendido (es decir, por palabras y no numeros de codigo) y selecciona marcado a ciegas, sin esperar tono de marcado. El comando dial envia la cadena de inicializacion al modem y llama al sistema remoto. El comando de marcado por defecto en los modems Hayes es ATD. _____________________________________________6 Deben respetarse las mayusculas _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ Comandos echo y term El comando echo on se usa con propositos de depuracion, ya que hace que dip copie en la consola todo lo que envie al puerto serie. Puede desactivarse despues con una orden echo off. dip tambien puede salirse temporalmente a un modo terminal, de modo que Vd. pueda dialogar manualmente_con_el modem. Para ello se usa el comando term, y para salir de este modo se pulsa ||Ctrl-]_||. Comando get La orden get sirve para poner valores a las variables internas. Puede usarse como se vio en ejemplos anteriores, o bien de forma interactiva, a"nadiendo la palabra ask : DIP> get $local ask Enter the value for $local: _ Un tercer uso de este comando es intentar obtener el valor de la maquina remota. Aunque extra"no pueda parecer, resultautil en muchos casos: muchas veces el servidor SLIP no permite que nosotros nos pongamos cualquier direccion IP, sino que nos la asignara de un conjunto predeterminado y nos informara de ello mediante una frase tal como "Your address: 193.174.7.202" (Su direccion: 193.174.7.202). De esta frase querremos que dip ajuste automaticamente nuestra direccion IP, para lo que haremos lo siguiente (observar que se usa el parametro remote): ... dialogo de entrada en la cuenta .... wait address: 10 get $locip remote Comando print Este es el comando para enviar textos a la consola. Cualquier variable puede enviarse a la consola mediante comandos de este tipo, por ejemplo: DIP> print Utilizando puerto $port con velocidad $speed Utilizando puerto cua3 con velocidad 38400 _______________________________________________________________________________________________________________7.3. U* *tilizacion de dip @ Nombres de las variables dip solo entiende un conjunto predefinido de variables. Un nombre de variable siempre empieza con un simbolo de dolar y debe escribirse en minusculas. Las variables $local y $locip contienen respectivamente el nombre de nuestra maquina y su direccion IP. Poniendo el nombre de la maquina, dip guardara dicho nombre en la variable $local, al tiempo que guardara la direccion IP en la variable $locip. Las variables $remote y $rmtip hacen lo mismo pero con la maquina remota. Por otro lado, $mtu contiene el valor del MTU para la conexion actual. Esas cinco variables son lasunicas que pueden actualizarse mediante un comando get. Otras deben actualizarse mediante comandos especificos, aunque siempre pueden sacarse por pantalla con el comando print. Esas variables son $modem, $port, y $speed. La variable $errlvl sirve para conocer el resultado delultimo comando ejecutado, siendo de valor 0 si fue bien, o distinto de 0 si hubo algun problema. Comandos if y goto El comando if es un salto condicional. Su sintaxis es if variable oper numero goto etiqueta donde la expresion puede ser una simple comparacion entre una de las variables siguientes: $errlvl, $locip, y $rmtip. El segundo operando debe ser un numero entero; el operador oper puede ser uno de los siguientes: ==, !=, <, >, <=, y >=. El comando goto lanza la ejecucion a partir de la situacion de la etiqueta, que debe ponerse al principio de una linea seguida de dos puntos. Comandos send, wait y sleep Estos comandos ayudan a implementar sencillos scripts de dialogo. send envia su argumento a la linea serie. No pueden ponerse variables, pero entiende secuencias de escape al estilo del lenguaje C, como \n y \b. El caracter de tilde (~ ) puede usarse como abreviatura del retorno de carro. El comando wait hace que dip espere a que por la linea serie se reciba la palabra pasada como primer argumento. El segundo argumento, que es opcional, fija un tiempo _______________________________________________________________________________________________________________7.4. F* *uncionamiento en Modo Se@ de espera maximo, en segundos. Si la palabra no se recibe en ese tiempo, el comando fallara actualizando la variable $errlvl con el valor 1. La orden sleep puede usarse para esperar cierto tiempo, por ejemplo para esperar pa- cientemente una invitacion a entrar en la cuenta. Una vez mas, el tiempo se especificara en segundos. Comandos mode y default Se utilizan para cambiar el puerto entre modo SLIP o normal, y configurar la interface. El comando mode es elultimo que ejecuta dip antes de pasar al segundo plano (daemon). A menos que suceda un error, de este comando no se retorna. Este comando tiene un argumento, que es el protocolo. Actualmente se reconocen los protocolos SLIP y CSLIP, es decir, la version actual de dip no soporta SLIP adaptativo. Despues de poner la linea en modo SLIP, dip ejecutara un comando ifconfig para con- figurar la interface como enlace punto a punto y otro route para cambiar las tablas de encaminamiento apuntando a la maquina remota. Si, ademas, se ejecuta default antes que mode, el programa hara que el camino por defecto de nuestros paquetes vaya al enlace SLIP. 7.4 Funcionamiento en Modo Servidor Curiosamente, configurar su maquina como servidor SLIP va a ser mucho mas sencillo que configurarla como cliente. Una forma de hacerlo es usar dip en modo servidor, que puede conseguirse si se eje- cuta como diplogin. Su configuracion principal se encontrara en /etc/diphosts, que asocia nombres de cuenta con direcciones de maquina asignadas. Alternativamente, puede usar sli- plogin, una utilidad procedente de BSD que proporciona un esquema de configuracion que le permite ejecutar shell scripts cuando las maquinas se conectan y desconectan. Actualmente, su desarrollo esta en fase beta. Ambos programas necesitan que se tenga una cuenta por cada cliente SLIP. Por ejemplo, si proporcionaramos un servicio SLIP a Arthur Dent en dent.beta.com, deberia crearse una cuenta dent a"nadiendo la siguiente linea al fichero /etc/passwd : dent:*:501:60:Cuenta SLIP de Arthur Dent:/tmp:/usr/sbin/diplogin _______________________________________________________________________________________________________________7.4. F* *uncionamiento en Modo Se@ Luego, se pondria la clave usando el programa passwd. Ahora, cuando dent entre, dip entrara en modo servidor. Para comprobar si esta auto- rizado para usar SLIP, buscara su nombre de usuario en /etc/diphosts. Este fichero detalla derechos de acceso y parametros de conexion para cada usuario. Una entrada de este fichero sera tal como: dent::dent.beta.com:Arthur Dent:SLIP,296 El primer campo de los separados por dos puntos, es el nombre de la cuenta. El segundo campo puede contener una clave adicional (vea mas adelante). El tercero es el nombre o direccion IP de la maquina llamante. El siguiente es un campo informativo acerca del usuario, por el momento sin utilidad. Por ultimo, se describen separados por comas los parametros de la conexion: el protocolo (SLIP o CSLIP ) seguido del valor de MTU. Cuando dent entra en su cuenta, diplogin extrae la informacion acerca deel y si hay clave de acceso en la linea correspondiente de /etc/diphosts, la pedira como "clave externa de seguridad", que se compara con la existente en el fichero (que no va encriptada). Si no coinciden, el intento de entrada sera rechazado. En otro caso, diplogin procedera a cambiar el modo a SLIP o CSLIP, y preparara la interfaz y el encaminamiento. Esta conexion permanecera hasta que el modem opuesto cuelgue, momento en que diplogin dejara la linea en modo normal y terminara. diplogin necesita privilegios de superusuario. Si no tiene puesto el bit setuid, debera co- piar el programa con el nombre diplogin y ponerle aeste los privilegios. A diplogin se le pueden dar sin miedo, sin afectar al estado de dip en si mismo. Capitulo 8 El Protocolo Punto ___a ___Punto (PPP) 8.1 Desenredando las Pes Al igual que el SLIP, el PPP es un protocolo utilizado para enviar datagramas a traves de una conexion serie, pero mejora algunas de las carencias del anterior. El PPP permite a las partes comunicantes negociar al principio de la conexion opciones como las direcciones IP y el tama"no maximo de los datagramas, y proporciona mecanismos de autentificacion de los clientes. Para cada una de estas capacidades, el PPP tiene un protocolo concreto. A continuacion, describiremos brevemente estos bloques basicos que constituyen el PPP. Esta descripcion esta muy lejos de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, asi como en la docena de RFCs que le acompa"nan.1 En la parte mas baja del PPP esta el protocolo de Control de Conexion de Datos de Alto-Nivel, abreviadamente HDLC2 3, que define los limites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurria con SLIP, una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como el IPX de Novell o el Appletalk. El PPP consigue esto a"nadiendo a la trama basica HDLC un campo de control que identifica el tipo de paquete contenido en la misma. El LCP, Protocolo de Control de Enlace4, es utilizado en la parte mas alta del HDLC para negociar las opciones concernientes a la conexion de datos, tales como la Unidad Maxima de Recepcion (MRU) que establece el tama"no maximo del datagrama que cada extremo de comunicacion acepta recibir. _____________________________________________1 Los RFCs mas relevantes estan listados en la Bibliografia al final de este libro. 2 N. del T.: Del ingles High-Level Data Link Control 3 En realidad, el HDLC es un protocolo mucho mas general publicado por la Organizacion Internacional de Estandares (ISO). 4 N. del T.: Del ingles Link Control Protocol 113 _______________________________________________________________________________________________________________8.2. P* *PP en Linux @ Un paso importante en la configuracion del enlace PPP corresponde a la autentificacion de los clientes. Aunque no es obligatorio, es casi un deber para las lineas telefonicas. Normalmente el servidor pide al cliente que se identifique probando que se sabe alguna clave secreta. Si el llamante se equivoca, la conexion se termina. Con el PPP, las autorizaciones se producen en los dos sentidos; es decir, el que llama tambien puede pedir al servidor que se autentifique. Estos procedimientos de autentificacion son totalmente independientes entre si. Hay dos protocolos distintos, segun el tipo de autentificacion, los cuales discutiremos mas adelante. Se llaman el Protocolo de Autentificacion por Contrase"na, o PAP, y el Protocolo de Autentificacion por Reto, o CHAP5. Cada protocolo de red que es encaminado a traves de la conexion de datos, como el IP, el Appletalk, etc; es configurado dinamicamente usando el correspondiente Protocolo de Control de Red (NCP). Por ejemplo, para enviar datagramas IP a traves del enlace, los dos nodos tienen que negociar en primer lugar que direcciones IP van a utilizar. El protocolo de control utilizado para esto es el IPCP6, el Protocolo de Control del IP. Aparte de enviar datagramas IP estandar a traves del enlace, el PPP tambien permite la compresion Van Jacobson de las cabeceras en los datagramas IP. Es una tecnica para meter las cabeceras de los paquetes TCP en un espacio de tan solo tres bytes. Tambien se utiliza en el CSLIP, y es conocida coloquialmente como compresion de cabeceras VJ. La utilizacion de la compresion puede negociarse tambien al comienzo de la conexion gracias al IPCP. 8.2 PPP en Linux En el Linux, la funcionalidad del PPP esta dividida en dos partes, un controlador de HDLC de bajo nivel situado en el kernel, y el demonio pppd del espacio del usuario que controla los diferentes protocolos de control. La version actual del PPP para Linux es la linux-ppp-1.0.0, y contiene el modulo PPP para el kernel, el pppd, y un programa llamado chat utilizado para llamar al sistema remoto. El controlador del PPP para el kernel fue escrito por Michael Callahan. El pppd fue escrito a partir de una implementacion gratuita del PPP para maquinas Sun y 386BSD que a su vez fue escrita por Drew Perkins y otros programadores, y mantenida por Paul Mackerras. Fue transportada a Linux por Al Longyear.7 El chat fue escrito por Karl Fox.8 _____________________________________________5 N. del T.: Del ingles Challenge Handshake Authentication Protocol 6 N. del T.: Del ingles IP Control Protocol 7 Los dos autores han dicho que van a estar muy ocupados por bastante tiempo. Asi que si tiene alguna pregunta sobre el PPP en general, mejor pregunte a la gente en el canal de la lista de correo de los "Linux activists" en la RED. 8 karl@morningstar.com. _______________________________________________________________________________________________________________8.3. C* *onexiones con pppd @ Al igual que el SLIP, el PPP esta implementado a traves de una disciplina especial para la utilizacion de las lineas. Para utilizar una linea de serie como enlace PPP, en primer lugar tendra que establecer la conexion con su modem, como es usual; y posteriormente pasar la linea al modo PPP. En este modo, todos los datos que nos llegan son pasados al controlador del PPP, que comprueba la validez de las tramas que llegan (cada trama HDLC trae un codigo de control de errores de 16 bit), las descompone y las despacha. Actualmente, es capaz de controlar datagramas IP, utilizando opcionalmente la compresion de cabeceras Van Jacobson. Tan pronto como Linux acepte IPX, el controlador PPP sera ampliado para poder controlar tambien los paquetes IPX. El controlador del kernel es ayudado por el pppd, el demonio del PPP, que realiza toda la fase de inicializacion y autentificacion necesaria antes de que el verdadero trafico de red pueda ser enviado a traves del enlace. El comportamiento del pppd puede ser ajustado utilizando varias opciones. Como el PPP es bastante complejo, es imposible explicar todas ellas en un solo capitulo. Por eso, este libro no puede cubrir todos los aspectos del pppd, sino solamente darle una introduccion. Para mas informacion, lea las paginas de manual y los ficheros README de la distribucion con las fuentes del pppd, que deberian ayudarle a comprender la mayor parte de las cuestiones que este capitulo no trata. Si su problema persiste incluso despues de leer toda la documentacion, deberia pasarse por el grupo de noticias comp.protocols.ppp para solicitar ayuda, que es el lugar donde encontrara a la mayor parte de la gente envuelta en el desarrollo del pppd. 8.3 Conexiones con pppd Cuando quiere conectarse a Internet a traves de un enlace PPP, tiene que configurar las capacidades basicas de red como el dispositivo de loopback y el sistema de resolucion de direcciones. Las dos han sido explicadas en los capitulos previos. Hay algunas cosas que es necesario decir sobre la utilizacion del DNS en un enlace serie; por favor, lea el capitulo del SLIP para mas informacion. Como ejemplo introductorio de como establecer una conexion PPP con el pppd, suponga que esta de nuevo en vlager. Ya ha llamado al servidor PPP, c3po, y entrado en la cuenta del usuario ppp. c3po ya ha lanzado su controlador PPP. Despues de salir del programa de comunicaciones que utilizo para llamar, se ejecuta el siguiente comando: # pppd /dev/cua3 38400 crtscts defaultroute Esto cambiara a la linea de serie cua3 al modo PPP y establecera un enlace IP con c3po. La velocidad de transferencia utilizada en el puerto de serie sera de 38400bps. La _______________________________________________________________________________________________________________8.4. L* *os Ficheros de Opciones @ opcion crtscts activa el control de flujo por hardware en el puerto, que es una obligacion para velocidades superiores a los 9600 bps. Lo primero que hace el pppd tras ejecutarse es negociar varias caracteristicas para el enlace con el extremo remoto utilizando el LCP. Normalmente, el conjunto de opciones que intenta negociar el pppd funcionara, asi que no nos meteremos mas con este asunto. Volveremos a tratar el LCP con mas detalle en alguna seccion posterior. Hasta ahora, tambien hemos asumido que c3po no necesita ninguna autentificacion de nosotros, asi que la fase configuracion habra sido completada conexito. El pppd negociara entonces los parametros IP con su compa"nero usando IPCP, el proto- colo de control IP. Al no especificar direccion IP alguna, el pppd intentara usar la direccion que se obtiene al resolver el nombre del ordenador local. Decididas las direcciones, cada pppd se lo comunicara al otro extremo. Normalmente no habra ningun problema con esta configuracion por defecto. Incluso si su maquina esta en una Ethernet, puede utilizar la misma direccion IP tanto para la Ethernet como para el interface PPP. No obstante, el pppd le permite utilizar direcciones diferentes, o incluso pedir a su compa"nero que utilice alguna direccion especifica. Estas opciones seran discutidas mas adelante. Tras pasar por la fase de configuracion IPCP, el pppd configurara la red de su ordenador para utilizar el enlace PPP. En primer lugar, configurara el interface de red PPP como un enlace punto-a-punto, utilizando el ppp0 para el primer enlace PPP que este activo, ppp1 para el segundo, y asi sucesivamente. A continuacion preparara una entrada de la tabla de encaminamiento que apunte al ordenador del otro extremo del enlace. En el ejemplo anterior, el pppd hara que el encaminamiento de red por defecto apunte a c3po, debido a que lo especificamos con la opcion defaultroute.9 Esto provoca que todos los datagramas dirigidos a ordenadores que no esten en su red sean enviados a c3po. Hay un variado numero de formas de encaminamiento que acepta el pppd, y las cubriremos en mayor detalle mas adelante. 8.4 Los Ficheros de Opciones Antes de que el pppd procese los argumentos de su linea de comandos, echa un vistazo a varios ficheros para establecer sus opciones por defecto. Estos ficheros pueden contener cualquier argumento de linea de comando valido, distribuido a traves de un cierto numero de lineas. Los comentarios se escriben tras el simbolo de almohadillado (#). El primer fichero de opciones es el /etc/ppp/options, que es leido cada vez que el pppd _____________________________________________9 El encaminamiento por defecto es instalado solamente si no hay ninguno establecido de antes. _______________________________________________________________________________________________________________8.5. R* *ealizacion de la Llamada@ arranca. El utilizarlo para establecer algunas opciones globales por defecto es una buena idea, pues le permite evitar que sus usuarios hagan ciertas cosas que podrian comprometer la seguridad del sistema. Por ejemplo, para hacer que el PPP necesite algun tipo de auten- tificacion del otro sistema, a"nadiria la opcion auth a este fichero. Esta opcion no puede ser evitada por el usuario, de forma que se hace totalmente imposible el establecer una conexion PPP con cualquier sistema que no este en nuestras bases de datos para la autentificacion. El otro fichero de opciones, que es leido despues del /etc/ppp/options, es el .ppprc situado en el directorio home del usuario. Permite que cada usuario especifique su propio conjunto de opciones por defecto. Un fichero /etc/ppp/options de ejemplo puede parecerse aeste: # Opciones globales para el pppd de vlager.vbrew.com auth # obligar a autentificacion usehostname # usar el nombre del ordenador local para el CHAP lock # usar el bloqueo de dispositivo tipo UUCP domain vbrew.com # nombre de nuestro dominio Las dos primeras opciones se utilizan para la autentificacion y seran explicadas a conti- nuacion. La expresion lock hace que el pppd utilice el metodo de bloqueo de dispositivos de UUCP. De esta manera, cada proceso que accede a un dispositivo serie, por ejemplo el /dev/cua3, crea un fichero de bloqueo llamado LCK..cua3 en el directorio de spool del UUCP para se"nalizar que ese dispositivo esta siendo usado. Esto es necesario para evitar que otros programas, como pueden ser el minicom o el uucico, abran el dispositivo de serie mientraseste es usado por el PPP. La razon de ponerestas opciones en el fichero de configuracion global es queestas no pueden ser pasadas por alto, de forma que proporcionan un razonable nivel de seguridad. Pero tenga en cuenta que, a pesar de todo, algunas opciones podran ser pasadas por alto mas tarde; un ejemplo de esto es la cadena connect. 8.5 Realizacion de la Llamada con chat Uno de los problemas que puede haberle dado el ejemplo anterior es que tenia que establecer la conexion manualmente antes de poder ejecutar el pppd. Al contrario que el dip, el pppd no tiene su propio lenguaje de scripts para llamar al sistema remoto y entrar enel, sino que confia en otro programa externo para que haga esto. El comando que tiene que ser ejecutado puede darsele al pppd con la opcion connect en la linea de comando. El pppd redirigira la entrada y salida estandar de comandos a la linea de serie. Un programautil _______________________________________________________________________________________________________________8.5. R* *ealizacion de la Llamada@ para esto es el expect, escrito por Don Libes. Tiene un lenguaje muy potente basado en el Tcl, y fue dise"nado exactamente para este tipo de aplicacion. El paquete pppd incluye un programa similar llamado chat que le permite especificar un script del estilo de los de UUCP. Basicamente, un script del chat consiste en una secuencia alterna de cadenas que esperamos recibir del sistema remoto y las respuestas que hemos de enviar. Las llamaremos respectivamente, cadenas esperadas y cadenas enviadas. Este es un extracto de un tipico script del chat: ogin: b1ff ssword: s3kr3t Esto le indica al chat que espere a que el sistema remoto le envie el mensaje de peticion de usuario y entonces le devuelve el nombre del usuario b1ff. Solo esperamos por ogin: para que no importe si el mensaje de login empiece por l mayuscula o minuscula, o si llega con basura. La siguiente cadena es una cadena esperada que hace que el chat espere al mensaje de peticion de contrase"na y la envie nuestra contrase"na como respuesta. Esto es basicamente lo que tienen los scripts del chat. Un script completo para llamar a un servidor PPP deberia, ademas, incluir los comandos apropiados para el modem. Suponga que su modem entiende los comandos Hayes, y que el numero de telefono del servidor es el 318714. En ese caso, la linea completa del chat para que pudiesemos establecer una conexion con c3po seria $ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN Por definicion, la primera cadena que damos al chat tiene que ser una cadena esperada, pero como el modem no dira nada hasta que hablemos conel, hacemos que el chat la ignore especificando una cadena vacia. Continuamos enviando ATZ, el comando de inicializaion para los modems compatibles Hayes, y esperamos a que nos responda con OK. La siguiente cadena envia al chat el comando de marcado junto con el numero de telefono, y espera a que aparezca el mensaje CONNECT como respuesta. Esto esta seguido de otra cadena vacia otra vez, porque ahora no queremos enviar nada, sino esperar a que aparezca el mensaje de peticion de login. El resto del script del chat funciona exactamente como antes. La opcion -v hace que el chat capture todas las actividades hacia la facilidad local2 del demonio syslog.10 El escribir el script de chat directamente en la linea de comando implica un cierto riesgo, pues los usuarios pueden ver la linea de comando de un proceso con el comando _____________________________________________10 Si edita el syslog.conf para redirigir estos mensajes a un fichero, asegurese de que este fichero no pueda ser leido por cualquiera, pues el chat tambien captura todo el script de entrada por defecto - incluyendo las contrase"nas. _______________________________________________________________________________________________________________8.5. R* *ealizacion de la Llamada@ ps. Puede evitar esto colocando el script del chat en un fichero, por ejemplo llamado dial- c3po. Entonces, podra hacer al chat leer el script del fichero en vez de la linea de comando utilizando la opcion -f, seguida por el nombre del fichero. Por lo tanto la invocacion completa al pppd tendra ahora un aspecto comoeste: # pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \ crtscts modem defaultroute Ademas de la opcion connect que se refiere al script de llamada, hemos a"nadido dos opciones mas a la linea de comando: -detach, que le indica al pppd que no se separe de la consola ni se vuelva proceso de segundo plano. La palabra modem activa algunas acciones especificas para modem sobre el dispositivo de serie, como colgar la linea antes y despues de la llamada. Si no utiliza esta opcion, el pppd no se preocupara de la linea DCD del puerto, y por lo tanto no podra detectar si el extremo remoto cuelga de forma imprevista. Los ejemplos anteriores eran bastante simples; el chat permite el uso de scripts mucho mas complejos. Una caracteristica muyutil es la capacidad de especificar cadenas frente a las cuales parar el chat con un error. Unas cadenas tipicas para parar pueden ser mensajes como BUSY o NO CARRIER, que son los que su modem produce cuando el numero al que llama comunica o no descuelga. Para hacer que el chat las reconozca inmediatamente en vez de esperar, puede introducirlas al principio del script utilizando la opcion ABORT: $ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ... De una forma parecida, puede variar el valor del tiempo de espera para algunas partes de los scripts de chat insertando opciones TIMEOUT. Para mas detalles, vea la pagina de manual del chat(8). Algunas veces, tambien querra disponer de algun tipo de ejecucion condicional de al- gunas partes del script de chat. Por ejemplo, cuando reciba el mensaje de peticion de login desde el extremo remoto, puede que quiera enviar un BREAK, o un retorno de carro. Puede conseguir esto a"nadiendo un sub-script a la parte esperada del script. Consiste en en una secuencia de de cadenas de envio y esperadas, de la misma forma que el script en su totalidad, pero separadas por guiones. El sub-script es ejecutado desde el momento en que la cadena esperada a la que estan ligados no es recibida a tiempo. Para este ejemplo, modificariamos el script del chat de la siguiente manera: ogin:-BREAK-ogin: ppp ssword: GaGariN Ahora, cuando el chat no recibe el mensaje de login del sistema remoto, se ejecuta el sub-script enviando un BREAK y esperando de nuevo por el mensaje de login. Si ahora ya aparece, el script continua como usualmente y si no, termina con un error. _______________________________________________________________________________________________________________8.6. D* *epuracion de la Configur@ 8.6 Depuracion de la Configuracion PPP Por defecto, el pppd registrara todos los avisos y mensajes de error gracias a las facilidades daemon del syslog. Tiene que a"nadir una entrada al syslog.conf que redirija esto a un fichero, o incluso a la consola, pues de otra forma el syslog simplemente desechara estos mensajes. La siguiente entrada envia todos los mensajes a /var/log/ppp-log: daemon.* /var/log/ppp-log Si la configuracion de su PPP no funciona, echar un vistazo a este fichero le deberia dar una primera pista de que es lo que va mal. Si esto no le ayuda, tambien puede activar la salida extra de depuracion utilizando la opcion debug. Esto hace que el pppd registre los contenidos de todos los paquetes de control enviados o recibidos a syslog. Todos los mensajes iran a la facilidad daemon. Finalmente, la opcion mas drastica es el activar la depuracion a nivel de kernel lla- mando al pppd con la opcion kdebug. Esto es seguido por un argumento numerico que es el O exclusivo (xor) de los siguientes valores: 1 para mensajes de depuracion generales, 2 para imprimir los contenidos de todas las tramas HDLC que nos llegan, y 4 para hacer al controlador imprimir todas las tramas HDLC salientes. Para capturar los mensajes de depuracion a nivel de kernel, tiene que, o bien ejecutar un demonio syslogd que lea el fichero /proc/kmsg, o si no el demonio klogd. Cualquiera de los dos dirige la depuracion del kernel a la facilidad kernel del syslogd. 8.7 Opciones de Configuracion IP El IPCP se utiliza para negociar un par de parametros IP a la hora de configurar la cone- xion. Normalmente, cada extremo de comunicacion puede enviar un Paquete de Peticion de Configuracion IPCP, indicando que valores quiere cambiar de los que vienen por defecto, y a que valor. Tras la recepcion, el extremo remoto inspecciona cada opcion sucesivamente, y, o responde que la acepta, o la rechaza. El pppd le da gran control sobre que opciones intentara negociar el IPCP. Puede ajustar esto a traves de varias opciones en la linea de comandos de las que hablamos a continuacion. 8.7.1 Eleccion de las Direcciones IP En el ejemplo anterior, haciamos que el pppd llamase a c3po y estableciera una conexion IP. No nos preocupabamos de elegir una direccion IP particular en ninguno de los extremos _______________________________________________________________________________________________________________8.7. O* *pciones de Configuracion@ de la conexion. En vez de ello, tomabamos la direccion de vlager como la direccion IP local, y dejabamos a c3po darse su propia direccion. Algunas veces, sin embargo, esutil el tener control sobre la direccion utilizada por alguno de los extremos de la conexion. El pppd soporta diferentes posibilidades sobre este aspecto. Para pedir direcciones particulares, normalmente de al pppd la siguiente opcion: dir_local :dir_remota donde dir_local y dir_remota pueden ser especificadas en notacion de cuadruplas numeri- cas o como nombres de ordenador. 11 Esto hace al pppd intentar usar la primera direccion como su propia direccion IP, y la segunda como la de su compa"nero. Si el compa"nero rechaza alguna de ellas durante la negociacion IPCP, no se establecera ninguna conexion IP.12 Si solo quiere establecer la direccion local, y aceptar cualquier direccion que utilice el compa"nero, simplemente deseche la parte de la dir_remota . Por ejemplo, para hacer a vlager usar la direccion IP 130.83.4.27 en vez de la suya propia, le escribiria 130.83.4.27: en la linea de comando. De forma similar, para establecer la direccion remotaunicamente, dejaria el campo de la dir_local en blanco. Por defecto, el pppd utilizara entonces la direccion asociada al nombre de su ordenador. Algunos servidores PPP que sirven a muchos clientes asignan direcciones dinamicamente: las direcciones son asignadas a los sistemas solo cuando llaman, y son reclamadas de nuevo una vez que se desconecta. Cuando llame a uno deestos servidores, debe asegurarse de que el pppd no solicita una direccion IP particular, sino que acepta la direccion que el servidor le pide que utilice. Esto quiere decir que no tiene que poner el argumento dir_local . Ademas, tendra que utilizar la opcion noipdefault, que hace que el pppd espere a que el compa"nero le proporcione la direccion IP en vez de utilizar la direccion IP del ordenador local. 8.7.2 Encaminamiento a traves de una Conexion PPP Tras configurar el interface de red, el pppd preparara un encaminamiento que solamente le sirve para comunicarse con el otro extremo. Si el ordenador remoto esta en una red dearea local, seguramente usted deseara conectar tambien con los ordenadores que estan "detras" deel; para eso, se ha de configurar un encaminamiento de red adecuado. _____________________________________________11 El utilizar nombres de ordenador en esta opcion tiene algunas consecuencias a la hora de la autentificacion utilizando CHAP. Puede echar un vistazo a la seccion sobre CHAP mas adelante. 12Puede permitir al otro PPP sobreescribir sus ideas de direcciones IP dando al pppd las opciones ipcp-accept-local e ipcp-accept-remote. Eche un vistazo a la pagina del manual para mas detalles. _______________________________________________________________________________________________________________8.7. O* *pciones de Configuracion@ Ya hemos visto antes que se puede pedir al pppd que configure el encaminamiento por defecto utilizando la opcion defaultroute. Esta opcion es muyutil si el servidor PPP al que llama va a actuar como su pasarela a Internet. El caso contrario, cuando su sistema actua como un gateway para un solo ordenador, es tambien relativamente facil de llevar a cabo. Por ejemplo, imagine a algun empleado de la Cervecera Virtual cuyo ordenador de casa se llama loner. Cuando este conectando a vlager a traves de PPP,el utiliza una direccion de la subred de la Cervecera. Podremos dar al pppd del ordenador vlager la opcion proxyarp, que instalara una entrada proxy-ARP para el ordenador loner. Esto hara que loner sea automaticamente accesible desde todos los ordenadores de la Cervecera y la Vinatera. De cualquier manera, las cosas no son siempre tan faciles como esto, por ejemplo cuando intentamos unir dos redes dearea local. Esto requiere normalmente el a"nadir una ruta de red especifica, porque estas redes tendran ya sus propios encaminamientos por defecto. Por otra parte, el tener a los dos extremos de comunicacion utilizando la conexion PPP como encaminamiento por defecto generaria un ciclo sin fin, donde los paquetes con destinos desconocidos rebotarian entre los dos ordenadores hasta que su tiempo de vida (TTL) expirase. Pongamos un ejemplo: suponga que la Cervecera Virtual abre una sucursal en alguna otra ciudad. La sucursal utiliza su propia red Ethernet utilizando el numero de red IP 191.72.3.0, que es la subred 3 de la red de clase B de la Cervecera. Quieren conectarse a la red Ethernet principal de la Cervecera a traves de PPP para actualizar las bases de datos de clientes, etc. De nuevo, vlager actuara como pasarela; la otra maquina se llama sub-etha y tiene una direccion IP de 191.72.3.1.. Cuando sub-etha conecta a vlager, hara que el punto de encaminamiento por defecto sea vlager, como es habitual. En vlager, de todas formas, tendremos que instalar un en- caminamiento de red para la subred 3 que vaya a traves de sub-etha. Para esto, utilizamos una caracteristica del pppd de la que no hemos hablado hasta ahora - el comando ip-up. Es un script de shell situado en /etc/ppp que se ejecuta despues de que el interface PPP ha sido configurado. Cuando esta presente, se le llama con los siguientes parametros: ip-up interface dispositivo velocidad dir_local dir_remota donde interface se refiere al interface de red usado, dispositivo es la ruta al dispositivo serie utilizado, (/dev/tty si se utiliza la salida y entrada estandar), y velocidad es la velocidad del dispositivo. dir_local y dir_remota nos dan las direcciones IP usadas en dos extremos de la conexion en notacion de cuarteto numerico. En nuestro caso, el script ip-up puede contener el siguiente fragmento de codigo: _______________________________________________________________________________________________________________8.8. O* *pciones de Control de En@ #!/bin/sh case $5 in 191.72.3.1) # este es sub-etha route add -net 191.72.3.0 gw 191.72.3.1;; ... esac exit 0 De una forma analoga, /etc/ppp/ip-down se utiliza para deshacer todas las acciones de ip-up despues de que la conexion PPP ha sido cortada. A pesar de todo, la tabla de encaminamiento aun no esta completa. Hemos configurado las entradas de la tabla de encaminamiento para las dos ordenadores con PPP, pero hasta ahora, todos los demas ordenadores de las dos redes no saben nada sobre la conexion PPP. Esto no es un gran problema si todos los ordenadores de la sucursal tienen su encamina- miento por defecto encaminado a sub-etha, y todos los ordenadores de la Cervecera enca- minan hacia vlager por defecto. Sieste no fuera el caso, suunica posibilidad normalmente sera usar un demonio de encaminamiento como el gated. Tras crear el encaminamiento de la red en vlager, el demonio de encaminamiento pasara el nuevo encaminamiento a todos los ordenadores de las redes dependientes deesta. 8.8 Opciones de Control de Enlace Anteriormente, ya hemos tratado sobre el LCP, el protocolo de control de enlace (Link Con- trol Protocol), que se utiliza para negociar las caracteristicas de la conexion y comprobarla. Las dos opciones mas importantes que pueden ser negociadas por el LCP son la unidad maxima de recepcion (MRU) y el mapa de caracteres de control asincronos. Tambien hay varias opciones de configuracion LCP mas, pero son demasiado especificas como para comentarlas aqui. Eche un vistazo a la RFC 1548 para ver una descripcion deestas. El mapa de caracteres de control asincronos, tambien conocido como el mapa asincrono, es usado en enlaces asincronos, como las lineas telefonicas, para identificar los caracteres de control que deben de ser reemplazados por una secuencia especifica de dos caracteres13 . Por ejemplo, puede que quiera evitar los caracteres XON y XOFF utilizados con el control de flujo hardware activado, pues algun modem mal configurado puede parar hasta que reciba un XOFF. Otro candidato puede ser Ctrl-] (el caracter de escape del telnet ). El PPP le permite rehuir de cualquiera de los caracteres con codigos ASCII comprendidos entre 0 y 31 especificandolos en el mapa asincrono. _____________________________________________13 N. del T.: Estos caracteres se conocen como rehuidos _______________________________________________________________________________________________________________8.8. O* *pciones de Control de En@ El mapa asincrono (async map) es un mapa de bits de 32 bits de ancho, y cuyo bit menos significativo corresponde al caracter ASCII NUL, y cuyo bit mas significativo corresponde al ASCII 31. Si un bit se pone a 1, indica que el caracter correspondiente debe de ser rehuido antes de ser enviado a traves de la conexion. Inicialmente, el mapa asincrono se establece como 0xffffffff, lo que significa que todos los caracteres de control seran rehuidos. Para decir al otro ordenador que no tiene que rehuir de todos los caracteres de control sino solo de algunos, puede establecer un nuevo mapa asincrono al pppd utilizando la opcion asyncmap. Por ejemplo, si solo ^S y ^Q (los codigos ASCII 17 y 19, normalmente utilizados para XON y XOFF) deben de ser rehuidos, utilice la siguiente opcion: asyncmap 0x000A0000 La unidad maxima de recepcion, o MRU, se"naliza al otro extremo el tama"no maximo de las tramas HDLC que queremos recibir. Aunqueesto puede que le recuerde al valor de la MTU (unidad maxima de transferencia), tienen poco en comun. El MTU es un parametro del dispositivo de red del kernel, y describe el tama"no maximo de la trama que el interface es capaz de soportar. El MRU es mas bien un consejo al ordenador remoto para que no genere ninguna trama mas grande que la MRU; no obstante, el interface ha de ser capaz de recibir tramas de hasta 1500 bytes. Por lo tanto, elegir un MRU no es tanto una cuestion de que es capaz de transmitir la conexion, sino de como conseguir el mejor rendimiento. Si va a usar la conexion para aplicaciones interactivas, el poner en el MRU valores tan bajos como 296 es una buena idea, de forma que un paquete ocasional mayor (digamos, de una sesion de FTP) no haga a su cursor "saltar". Para decir al pppd que pida un MRU de 296, pondria la opcion mru 296. Las MRUs peque"nas, de todas maneras, solo tienen sentido si no tiene la compresion de cabecera VJ desactivada (esta activada por defecto). El pppd tambien entiende un par de opciones LCP que configuran el comportamiento general del proceso de negociacion, como es el maximo numero de peticiones de configura- cion que pueden ser intercambiadas antes de que se corte la conexion. A menos que sepa exactamente lo que esta haciendo, debera dejar este valor fijo. Finalmente, hay dos opciones que se aplican a los mensajes de eco del LCP. El PPP define dos mensajes, "Peticion de Eco" y "Respuesta de Eco". El pppd usa esta caracteristica para comprobar si la conexion esta aun operativa. Puede habilitar esto utilizando la opcion lcp-echo-interval junto con el tiempo en segundos. Si no se reciben tramas del ordenador remoto en este intervalo, el pppd genera una Peticion de Eco, y espera a que el compa"nero devuelva una Respuesta de Eco. Si el compa"nero no produce una respuesta, la conexion es cortada despues de que se hayan enviado un cierto numero de peticiones. Este numero puede _______________________________________________________________________________________________________________8.9. C* *onsideraciones Generales@ ser establecido utilizando la opcion lcp-echo-failure. Por defecto, esta caracteristica tambien esta desactivada. 8.9 Consideraciones Generales sobre Seguridad Un demonio de PPP mal configurado puede ser un peligroso agujero en la seguridad. Es equivalente a dejar a cualquiera enganchar su maquina a su red Ethernet (y eso es muy malo). En esta seccion, discutiremos algunas medidas que deberian hacer su configuracion del PPP segura. Uno de los problemas del pppd es que el configurar el dispositivo de red y la tabla de encaminamiento requiere los privilegios de root. Normalmente resolvera esto ejecutandolo como setuid de root. A pesar de ello, el pppd permite a los usuarios establecer varias opciones de relevancia para la seguridad. Para protegerse contra cualquier ataque que pueda lanzar algun usuario manipulando estas opciones, se sugiere que establezca un par de valores por defecto en el fichero global /etc/ppp/options, tal como los mostrados en el fichero de ejemplo en la seccion "Utilizacion de los Ficheros de Opciones". Algunos de ellos, como los de las opciones de autentificacion, no pueden ser despues modificados por el usuario, asi que proporcionan una razonable proteccion contra las manipulaciones. Por supuesto, tambien tiene que protegerse de los sistemas con los que habla con PPP. Para evitar que otros ordenadores puedan hacerse pasar por quien no son, debe utilizar siempre algun tipo de autentificacion con el otro extremo de la comunicacion. Ademas, no deberia permitir a ordenadores desconocidos usar cualquier direccion IP que elijan, sino restringirlas a unas pocas. La siguiente seccion tratata sobre estos asuntos. 8.10 Autentificacion con PPP 8.10.1 CHAP frente a PAP Con el PPP, cada sistema puede obligar al otro ordenador a identificarse usando uno de los dos protocolos de autentificacion disponibles. Estos son el Protocolo de Autentificacion por Contrase"na (PAP), y el Protocolo de Autentificacion por Reto (CHAP). Cuando se establece una conexion, cada extremo puede pedir al otro que se autentifique, independientemente de que sea el llamante o el llamado. Mas adelante, utilizare relajadamente `cliente' y `servidor' cuando quiera distinguir entre el sistema autentificado y el autentificador. Un demonio PPP puede pedir a la otra maquina autentificacion enviando otra peticion mas de configuracion de LCP indicando el protocolo de autentificacion deseado. _______________________________________________________________________________________________________________8.10. * *Autentificacion con PPP @ El PAP trabaja basicamente de la misma forma que el procedimiento normal de lo- gin. El cliente se autentifica a si mismo enviando un nombre de usuario y una contrase"na (opcionalmente encriptada) al servidor, la cual es comparada por el servidor con su base de datos de claves. Esta tecnica es vulnerable a los intrusos que pueden intentar obtener la contrase"na escuchando en una linea de serie y a otros que hagan sucesivos intentos de ataque por el metodo de prueba y error. El CHAP no tiene estos defectos. Con el CHAP, el autentificador (i.e. el servidor) envia una cadena de "reto" generada aleatoriamente al cliente, junto a su nombre de ordenador. El cliente utiliza el nombre del ordenador para buscar la clave apropiada, la combina con el reto, y encripta la cadena utilizando una funcion de codificacion de un solo sentido. El resultado es devuelto al servidor junto con el nombre del ordenador cliente. El servidor realiza ahora la misma computacion, y advierte al cliente si llega al mismo resultado. Otra caracteristica del CHAP es que no solicita autentificacion al cliente solamente al comienzo de la sesion, sino que envia retos a intervalos regulares para asegurarse de que el cliente no ha sido reemplazado por un intruso, por ejemplo cambiando la linea telefonica. El pppd mantiene las claves secretas para el CHAP y el PAP en dos ficheros separados, llamados /etc/ppp/chap-secrets y pap-secrets respectivamente. Si introduce un ordenador remoto en alguno de los dos ficheros, tiene un buen control de cual de los protocolos CHAP o PAP se utilizara para autentificarnos conel y viceversa. Por defecto, el pppd no pide autentificacion al ordenador remoto, pero aceptara el au- tentificarse a si mismo cuando se lo pida el ordenador remoto. Como el CHAP es mucho mas fuerte que el PAP, el pppd intenta usar el anterior siempre que es posible. Si el otro ordenador no lo acepta, o el pppd no encuentra una clave CHAP para el sistema remoto es su fichero chap-secrets, cambia al PAP. Si tampoco tiene clave PAP para su compa"nero, renunciara a autentificarse. Como consecuencia de esto, se cerrara la conexion. Este comportamiento puede ser modificado de varias formas. Por ejemplo, cuando se a"nade la palabra auth, el pppd solicitara al otro ordenador que se autentifique. El pppd aceptara el uso del CHAP o el PAP para ello, siempre y cuando tenga una clave para su compa"nero en su base de datos CHAP o PAP respectivamente. Hay otras opciones para activar o no un determinado protocolo de autentificacion, pero no las describire aqui. Puede leer la pagina de manual del pppd(8) para mas detalles. Si todos los sistemas con los que conversa en PPP estan de acuerdo en autentificarse con usted, deberia poner la opcion auth en el fichero global /etc/ppp/options y definir contrase"nas para cada sistema en el fichero chap-secrets. Si un sistema no acepta el CHAP, a"nada una entrada parael al fichero pap-secrets. De esta forma, puede asegurarse de que ningun sistema sin autentificar se conecta a su ordenador. Las dos secciones siguientes hablan sobre los dos ficheros de claves del PPP, pap-secrets _______________________________________________________________________________________________________________8.10. * *Autentificacion con PPP @ y chap-secrets. Estan situados en /etc/ppp y contienen tripletas de clientes, servidores y contrase"nas, seguidas opcionalmente por una lista de direcciones IP. La interpretacion de los campos de servidor y cliente es distinta en el CHAP y el PAP, y tambien depende de si nos autentificamos nosotros con el otro ordenador, o si solicitamos al servidor que se autentifique con nosotros. 8.10.2 El fichero de claves CHAP Cuando tiene que autentificarse con algun servidor utilizando el CHAP, el pppd busca en el fichero chap-secrets una entrada cuyo campo de cliente sea igual al nombre del ordenador local, y cuyo campo de servidor sea igual al nombre del ordenador remoto enviado en el reto del CHAP. Cuando solicita a la otra maquina que se autentifique, los roles son simplemente al reves: el pppd entonces buscara una entrada que tenga el campo de cliente igual al nombre del ordenador remoto (enviado en la respuesta del CHAP del cliente), y el campo de servidor igual al nombre del ordenador local. El siguiente es un fichero de ejemplo del chap-secrets para vlager:14 # claves CHAP para vlager.vbrew.com # # cliente servidor clave direccion #---------------------------------------------------------------------- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com * vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com Cuando se intenta establecer una conexion PPP con c3po, c3po pide a vlager que se autentifique usando el CHAP mediante el envio de un reto del CHAP. El pppd enton- ces examina chap-secrets buscando una entrada cuyo campo de cliente sea igual a vla- ger.vbrew.com y el campo de servidor sea c3po.lucas.com,15 y encuentra la primera linea mostrada anteriormente. Entonces produce la respuesta del CHAP a partir de la cadena del reto y la clave (Use The Source Luke), y la envia de vuelta a c3po. Al mismo tiempo, el pppd produce un reto del CHAP para c3po, conteniendo unaunica cadena de reto y su nombre de ordenador completo vlager.vbrew.com. c3po construye una respuesta del CHAP de la manera que acabamos de decir, y se la devuelve a vlager. El pppd extrae ahora el nombre del cliente (c3po.vbrew.com) de la respuesta, y busca en el fichero chap-secrets una linea que tenga c3po como cliente y vlager como servidor. La _____________________________________________14 Las comillas no son parte de la contrase"na, simplemente sirven para proteger el espacio en blanco del interior de la contrase"na. 15Este nombre de ordenador se toma del reto del CHAP. _______________________________________________________________________________________________________________8.10. * *Autentificacion con PPP @ segunda linea se corresponde con esto, asi que el pppd combina el reto del CHAP y la clave riverrun, pasteve, las encripta, y compara el resultado con la respuesta del CHAP de c3po. El cuarto campo opcional lista las direcciones IP que son aceptables por los clientes nombrados en el primer campo. Las direcciones pueden ser dadas en notacion de cuarteto numerico o como nombres de ordenador que son resueltos posteriormente. Por ejemplo, si c3po solicita usar una direccion IP que no esta en esta lista durante la negociacion IPCP, la peticion sera rechazada, y IPCP se desconectara. En el fichero de ejemplo anterior, c3po esta limitado a poder usar solo su propia direccion. Si el campo de direccion esta vacio, se permitira cualquier direccion; un valor de "-" evita el uso de una cierta direccion IP con un cliente. La tercera linea del fichero chap-secrets de prueba, permite a cualquier ordenador esta- blecer un enlace PPP con vlager, pues si aparece la expresion "* " en los campos de cliente o servidor, sera valido cualquier nombre. Elunico requisito es que sepa la clave, y utiliza la direccion de pub.vbrew.com. Pueden aparecer perfectamente entradas con comodines en los nombres en cualquier lugar del fichero de claves, pues el pppd siempre utilizara la entrada mas especifica que pueda ser aplicada a un par cliente/servidor. Hay algunas cosas que decir sobre la manera en que el pppd encuentra los nombres de ordenadores que busca en el fichero de claves. Como se explico anteriormente, el nombre del ordenador remoto es siempre proporcionado por el otro ordenador en el paquete de reto o respuesta del CHAP. El nombre del ordenador local sera obtenido por defecto llamando a la funcion gethostname(2). Si ha configurado el nombre del sistema como el nombre del ordenador sin calificar, entonces tendra que dar al pppd el nombre del dominio a a"nadir usando la opcion domain: # pppd ...domain vbrew.com Esto a"nadira el nombre del dominio de la Cervecera a vlager para todas las actividades relacionadas con la autentificacion. Otras opciones que modifican la idea que tiene el pppd del nombre del ordenador local son usehostname y name. Cuando da la direccion IP local en la linea de comando usando "local :remoto ", y local es un nombre en vez de un cuarteto numerico, el pppd utilizaraeste como el nombre local. Para mas detalles, lea la pagina del manual del pppd(8). 8.10.3 El Fichero de Claves PAP El fichero de claves PAP es muy similar al utilizado por el CHAP. Los dos primeros campos siempre contienen un nombre de usuario y un nombre de servidor; el tercero alberga la clave _______________________________________________________________________________________________________________8.10. * *Autentificacion con PPP @ PAP. Cuando el sistema remoto envia una peticion de autentificacion, el pppd usa la entrada en la que el campo de servidor es igual al nombre del ordenador local, y el campo de usuario igual al nombre de usuario enviado en la peticion. Cuando se autentifica a si mismo al otro ordenador, el pppd toma la clave a enviar de la linea con el nombre de usuario igual al nombre del usuario local, y con el campo de servidor igual al nombre del ordenador remoto. Un fichero de claves PAP sencillo puede parecerse aeste: # /etc/ppp/pap-secrets # # usuario servidor clave direccion vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com La primera linea se usa para autentificarnos a nosotros mismos cuando hablemos con c3po. La segunda linea describe como un usuario llamado c3po tiene que autentificarse con nosotros. El nombre vlager-pap de la primera columna es el nombre de usuario que nosotros mandamos a c3po. Por defecto, el pppd tomara el nombre del ordenador local como el nombre de usuario, pero tambien se puede especificar un nombre diferente dando la opcion user, seguida por el nombre deseado. Para escoger una de las entradas del fichero pap-secrets para la autentificacion con el compa"nero, el pppd tiene que saber el nombre del ordenador remoto. Como no tiene manera de averiguarlo, tiene que especificarlo en la linea de comando usando la palabra remotename, seguida por el nombre del ordenador remoto. Por ejemplo, para usar la entrada comentada anteriormente para la autentificacion con c3po, tenemos que a"nadir la siguiente opcion a la linea de comando del pppd : # pppd ... remotename c3po user vlager-pap En el cuarto campo (y todos los siguientes), puede especificar que direcciones IP estan permitidas para ese ordenador particular, de la misma forma que en el fichero de claves del CHAP. El otro ordenador solo podra pedir direcciones de esa lista. En el fichero de ejemplo, obligamos a c3po a usar su direccion IP autentica. Dese cuenta de que el PAP es un metodo de autentificacion bastante debil, y se reco- mienda utilizar el CHAP siempre que sea posible. Por eso, no explicaremos el PAP en gran profundidad aqui; si esta interesado en utilizar el PAP, encontrara algunas caracteristicas mas deeste comentadas en la pagina del manual del pppd(8). _______________________________________________________________________________________________________________8.11. * *Configuracion de un Serv@ 8.11 Configuracion de un Servidor PPP Hacer funcionar el pppd como servidor es solo cuestion de a"nadir las opciones adecuadas en la linea de comando. Idealmente, crearia una cuenta especial, digamos ppp, y le adjudicaria un script o programa como shell de entrada que llame al pppd con estas opciones. Por ejemplo, podria a"nadir la siguiente linea a /etc/passwd : ppp:*:500:200:Cuenta PPP Publica:/tmp:/etc/ppp/ppplogin Por supuesto, puede usar uids y gids diferentes a los mostrados arriba. Tambien tendra que establecer la contrase"na para la cuenta de arriba usando el comando passwd. El script ppplogin tendra entonces este aspecto: #!/bin/sh # ppplogin - script para lanzar el pppd al entrar mesg n stty -echo exec pppd -detach silent modem crtscts El comando mesg deshabilita la opcion de que otros usuarios puedan escribir a la ter- minal (tty) usada utilizando, por ejemplo, el comando write. El comando stty desactiva el eco de caracteres. Esto es necesario, pues de otra forma todo lo que el otro ordenador envie le sera devuelto a modo de eco. La opcion del pppd mas importante de las incluidas en el script es -detach, porque evita que el pppd se separe de la terminal controlada. Si no especificasemos esta opcion, se iria a segundo plano, haciendo que el script del shell termi- nase. Esto provocaria que la linea serie colgase y se perdiera la conexion. La opcion silent hace que el pppd espere hasta recibir un paquete del sistema llamante antes de comenzar a enviar. Esto evita la aparicion de timeouts al transmitir cuando el sistema que nos llama es lento en lanzar su cliente PPP. La opcion modem hace al pppd vigilar la linea DTR para ver si el otro sistema ha colgado, y crtscts activa el control de flujo por hardware. Ademas de estas opciones, se puede forzar alguna clase de autentificacion, por ejemplo especificando auth en la linea de comando del pppd, o en el fichero de opciones globales. La pagina del manual tambien habla sobre opciones mas especificas para activar o desactivar los protocolos de autentificacion individuales. Capitulo 9 Algunas Aplicaciones de Red Despues de instalar correctamente el IP y el sistema de resolucion, tiene que dedicarse a los servicios que quiera proporcionar a traves de la red. Este capitulo trata la configuracion de algunas sencillas aplicaciones de red, incluyendo el servidor inetd, y los programas de la familia rlogin. El interface de Llamada a Procedimiento Remoto o RPC1, en el que estan basados servicios como el Sistema de Ficheros en Red o NFS2 y el Sistema de Informacion de Red o NIS3, tambien sera tratado brevemente aqui. Las configuraciones de NFS y de NIS, sin embargo, ocupan mas espacio y seran descritas en capitulos aparte. Lo mismo sucede con el correo electronico y el sistema de noticias. Por supuesto, no podemos cubrir todas las aplicaciones de red en este libro. Si desea instalar alguna no tratada aqui, como talk, gopher, o Xmosaic, por favor, refierase a su documentacion. 9.1 El Super-Servidor inetd Frecuentemente, los servicios son llevados a cabo por los llamados demonios. Un demonio es un programa que abre un determinado puerto, y espera a recibir peticiones de conexion. Si se recibe una peticion de conexion, lanza un proceso hijo que aceptara la conexion, mientras el padre continua escuchando a la espera de mas peticiones. Este concepto tiene el inconveniente de que por cada servicio ofrecido, se necesita ejecutar un demonio que escuche las conexiones a un puerto, lo que generalmente significa un desperdicio de recursos de sistema como, por ejemplo, de espacio de intercambio. Por ello, casi todas las instalaciones un?x corren un "super-servidor" que crea sockets _____________________________________________1 N. del T.: Del ingles Remote Procedure Call 2 N. del T.: Del ingles Network File System 3 N. del T.: Del ingles Network Information System. 131 _______________________________________________________________________________________________________________9.1. E* *l Super-Servidor inetd @ para varios servicios, y escucha en todos ellos simultaneamente usando la llamada al sistema select(2). Cuando un nodo remoto requiere uno de los servicios, el super-servidor lo recibe y llama al servidor especificado para ese puerto. El super-servidor mas usado es inetd, el demonio Internet. Es iniciado en tiempo de arranque del sistema, y toma la lista de servicios que debe tratar de un fichero de configura- cion denominado /etc/inetd.conf. Aparte de esos servidores invocados por inetd, hay varios servicios triviales que el propio inetd se encarga de llevar a cabo, denominados servicios internos. Entre ellos, el chargen que simplemente genera una cadena de caracteres, y el daytime que devuelve la fecha y hora del sistema. Una entrada de este fichero consiste en una unica linea compuesta por los siguientes campos: servicio tipo protocolo espera usuario servidor linea_de_comando El significado de cada campo es como sigue: servicio Proporciona el nombre del servicio. El nombre del servicio debe ser traducido a un numero de puerto consultando el fichero /etc/services. Este fichero sera descrito mas adelante en la seccion 9.3. tipo Especifica un tipo de socket, ya sea stream (para protocolos orientados a la conexion) o dgram (para protocolos no orientados a la conexion). Los Ser- vicios basados en TCP deberan, por lo tanto, usar siempre stream, mientras que los servicios basados en UDP deberan usar siempre dgram. protocolo Indica el protocolo de transporte usado por el servicio. Este debe ser un nombre de protocolo valido que se pueda encontrar en el fichero protocols, tambien descrito mas adelante. espera Esta opcion se aplica solo a sockets de tipo dgram. Puede tomar los valores wait o nowait. Si se especifica wait, inetd ejecutara solo un servidor cada vez para el puerto especificado. De otro modo, continuara escuchando por el puerto inmediatamente despues de ejecutar el servidor. Esto esutil para servidores "single-threaded" que leen todos los datagramas que entran hasta que no llegan mas, y despues acaban. La mayor parte de los servidores RPC son de este tipo y se debera por ello especificar wait. El otro tipo de servidores, los "multi-threaded", permiten un numero ili- mitado de instancias corriendo concurrentemente. Con estos servidores se debera especificar nowait. Para sockets de tipo stream se debera especificar siempre nowait. _______________________________________________________________________________________________________________9.2. L* *a herramienta de control@ usuario Este es el identificador del usuario bajo el que se ejecutara el proceso. Por lo general,este suele ser el usuario root, aunque algunos servicios pueden usar diferentes cuentas. Es una buena idea el aplicar aqui el principio del menor privilegio, que indica que uno no deberia ejecutar un comando bajo una cuenta privilegiada si el programa no lo requiere para funcionar co- rrectamente. Por ejemplo, el servidor de noticias NNTP se ejecutara como news, mientras que otros servicios que podrian significar un riesgo para la seguridad (como tftp o finger ) son normalmente ejecutados como nobody. servidor Proporciona el camino completo del programa servidor a ejecutar. Los ser- vicios internos se indican con la palabra internal. linea_de_comando Esta es la linea de comando a pasar al servidor. Esto incluye el argumento 0, es decir, el nombre del comando. Normalmente, este sera el nombre de programa del servidor, salvo que el programa se comporte de forma distinta cuando se le invoque con un nombre diferente. Este campo se deja vacio para los servicios internos. En la figura 9.1 se muestra un ejemplo de fichero /etc/inetd.conf. La linea del servicio finger esta comentada, de forma que no este disponible. Esto se suele hacer normalmente por razones de seguridad porque podria ser usado por atacantes para obtener nombres de usuarios del sistema. El tftp tambien se muestra deshabilitado. tftp implementa el Trivial File Transfer Pro- tocol que permite transferir cualquier fichero del sistema que tenga permiso de lectura global sin chequeo de passwords, etc. Esto es especialmente peligroso con el fichero /etc/passwd, sobre todo si no se usa shadow password. TFTP es usado comunmente por clientes y terminales X sin unidad de discos para obtener su software de un servidor de arranque. Si necesita ejecutar tftp poresta razon, asegurese de limitar su accion a los directorios de los que los clientes obtendran los ficheros a"nadiendo esos nombres de directorio a la linea de comando del tftpd. Esto se muestra en la segunda linea tftp del ejemplo. 9.2 La herramienta de control de acceso tcpd Ya que abrir un ordenador al acceso en red implica muchos riesgos de seguridad, las apli- caciones estan dise"nadas para protegerse ante varios tipos de ataques. Algunas deestas aplicaciones, sin embargo, pueden ser reventadas (lo que quedo bastante demostrado con el RTM Internet worm), o pueden no distinguir entre un nodo seguro cuyas peticiones de _______________________________________________________________________________________________________________9.2. L* *a herramienta de control@ # # servicios inetd ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless login stream tcp nowait root /usr/sbin/rlogind in.rlogind shell stream tcp nowait root /usr/sbin/rshd in.rshd exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # servicios internos inetd # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal Figura 9.1: Un ejemplo de fichero /etc/inetd.conf. _______________________________________________________________________________________________________________9.2. L* *a herramienta de control@ un servicio particular deberian ser aceptadas, y otro nodo que no lo es y cuyas peticiones deberian ser rechazadas. Ya hemos discutido brevemente los servicios finger y tftp mas arriba. Asi, uno podria querer limitar el acceso a esos servicios solamente a los "nodos de confianza", lo cual es imposible con la configuracion usual, donde inetd o proporciona un servicio a todos los clientes, o a ninguno. Una herramientautil para esto es tcpd,4 el denominado demonio envoltorio5. Para los servicios TCP que quiera monitorizar o proteger,este es invocado en lugar del programa servidor. tcpd informa de la peticion al demonio syslog, chequea si el nodo remoto esta au- torizado para usar ese servicio, y solo si la respuesta es satisfactoria, ejecutara el programa servidor real. Observe que esto no funciona con servicios basados en UDP. Por ejemplo, para proteger el demonio finger, debe cambiar la linea correspondiente en inetd.conf asi: # Proteger el demonio de finger finger stream tcp nowait root /usr/sbin/tcpd in.fingerd Asi, sin a"nadir ningun control de acceso, esto le hara parecer al cliente que es la tipica configuracion de finger, salvo que toda peticion sera registrada en la facilidad auth del syslog. El control de acceso esta implementado mediante dos ficheros llamados /etc/hosts.allow y /etc/hosts.deny. Estos ficheros contienen entradas permitiendo y denegando acceso, res- pectivamente, para ciertos servicios y nodos. Cuando tcpd trata una peticion de un servi- cio como finger de un nodo cliente denominado biff.foobar.com, busca en hosts.allow y hosts.deny (eneste orden) una entrada en la que el servicio y el nodo cliente coincidan. Si la entrada coincidente aparece en hosts.allow, se garantiza el acceso, sin importar lo que haya en hosts.deny. Si la coincidencia se encuentra en hosts.deny, la peticion se rechaza cerrando la conexion. Si no hay coincidencia en ninguno, la peticion es aceptada. Las entradas en los ficheros de acceso tienen la siguiente estructura: lista_servicios : lista_nodos [:cmd_shell ] lista_servicios es una lista de nombres de servicios de /etc/services, o la palabra clave ALL. Para especificar todos los servicios excepto finger y tftp, usa "ALL EXCEPT finger, tftp". lista_nodos es una lista de nombres de nodos o direcciones IP, o las palabras clave ALL, LOCAL, o UNKNOWN. ALL hace coincidir todos los nodos mientras que LOCAL _____________________________________________4 Escrita por Wietse Venema, wietse@wzv.win.tue.nl. 5 N. del T.: Del ingles Wrapper Daemon _______________________________________________________________________________________________________________9.3. L* *os ficheros services y @ hace coincidir todos los nombres de nodos que no contengan un punto6. UNKNOWN hace coincidir todos los nodos cuya busqueda de nombre o direccion fallo. Un nombre comenzado por un punto incluye a todos los nodos cuyo dominio es el mismo a ese nombre. Por ejemplo, .foobar.com encajara con biff.foobar.com. Tambien hay formas de especificar direcciones de red IP y numeros de subred. Por favor, refierase a la pagina del manual de hosts_access(5) para mas detalles. Para denegar acceso a los servicios finger y tftp a todos los nodos menos a los locales, ponga lo siguiente en /etc/hosts.deny, y deje /etc/hosts.allow vacio: in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .su.dominio El campo opcional cmd_shell puede contener un comando de shell para que sea invocado cuando una busqueda coincida con la entrada. Esto es util para establecer trampas que puedan delatar a atacantes potenciales: in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \ echo "peticion de %d@%h" >> /var/log/finger.log; \ if [ %h != "vlager.vbrew.com" ]; then \ finger -l @%h >> /var/log/finger.log \ fi Los argumentos %h y %d son expandidos por tcpd al nombre del nodo cliente y al nombre del servicio, respectivamente. Refierase a la pagina del manual de hosts_access(5) para mas detalles. 9.3 Los ficheros services y protocols Los numeros de puerto en los que se ofrecen ciertos servicios "estandar" estan definidos en el RFC de "Numeros Asignados"7. Para permitir a los programas cliente y servidor convertir nombres de servicios en estos numeros, se almacenan en un fichero llamado /etc/services. Una entrada se construye asi: servicio puerto /protocolo [aliases ] Aqui, servicio especifica el nombre del servicio, puerto define el puerto por el que se ofrece el servicio, y protocolo define que protocolo de transporte se usa. Comunmente, _____________________________________________6 Normalmente solo los nombres de nodos locales obtenidos de busquedas en /etc/hosts no contienen puntos. 7 N. del T.: A veces se conocen como Well Known Ports, es decir, Puertos Bien Conocidos _______________________________________________________________________________________________________________9.3. * *Los ficheros services y @ este es udp o tcp. Es posible que un servicio sea ofrecido a mas de un protocolo, lo mismo que es posible ofrecer distintos servicios por el mismo numero de puerto, siempre que el protocolo sea distinto. El campo aliases permite especificar nombres alternativos para el mismo servicio. Usualmente, no se necesita cambiar el fichero de servicios que viene con el software de red en su sistema Linux. De todas formas, presentaremos un peque"no extracto de ese fichero. # El fichero services: # # servicios conocidos (well-known) echo 7/tcp # Eco echo 7/udp # discard 9/tcp sink null # Descartar discard 9/udp sink null # daytime 13/tcp # Fecha del sistema daytime 13/udp # chargen 19/tcp ttytst source # Generador de caracteres chargen 19/udp ttytst source # ftp-data 20/tcp # Protocolo FTP de ficheros (Datos) ftp 21/tcp # Protocolo FTP de ficheros (Control) telnet 23/tcp # Protocolo de Terminal smtp 25/tcp # Protocolo de Correo nntp 119/tcp readnews # Protocolo de Noticias # # servicios UNIX exec 512/tcp # rexecd de BSD biff 512/udp comsat # Notificacion de correo login 513/tcp # login remoto who 513/udp whod # who y uptime remotos shell 514/tcp cmd # comando remoto, si contrase~na syslog 514/udp # registro remoto del sistema printer 515/tcp spooler # cola de impresion remota route 520/udp router routed # informacion de encaminamiento Observe que, por ejemplo, el servicio echo es ofrecido en el puerto 7 tanto para TCP como para UDP, y que el puerto 512 es usado para dos servicios diferentes; el demonio COMSAT (que notifica a los usuarios de correo recien llegado, vea xbiff(1x)), mediante UDP, y la ejecucion remota (rexec(1)), usando TCP. Ocurre algo similar con el fichero de protocolos: la libreria de red necesita una forma de convertir nombres de protocolo _ por ejemplo, los usados en el fichero services _ a numeros de protocolo entendibles por el nivel IP en otros nodos. Esto se hace buscando _______________________________________________________________________________________________________________9.4. L* *lamada a Procedimientos @ el nombre en el fichero /etc/protocols. Contiene una entrada por linea, cada una con un nombre de protocolo y el numero asociado. Necesitar modificareste fichero es todavia mas improbable que tener que hurgar en /etc/services. Le mostramos un fichero ejemplo: # # Internet (IP) protocols # ip 0 IP # protocolo internet, pseudo-protocolo icmp 1 ICMP # protocolo de mensajes de control igmp 2 IGMP # protocolo para mensajes multidestino tcp 6 TCP # protocolo de control de transmision udp 17 UDP # protocolo de datagramas de usuario raw 255 RAW # interfaz IP directa (modo "crudo") " 9.4 Llamada a Procedimientos Remotos Un mecanismo muy general para aplicaciones cliente-servidor lo proporciona RPC, el paque- te Remote Procedure Call. RPC fue desarrollado por Sun Microsystems, y es una coleccion de herramientas y funciones de libreria. Ejemplos de aplicaciones construidas sobre RPC son NFS, el sistema de ficheros en red, y NIS, el sistema de informacion de red, que seran presentados en proximos capitulos. Un servidor RPC consiste en una coleccion de procedimientos a los que el cliente puede llamar enviando una peticion RPC al servidor, junto con los parametros del procedimiento. El servidor invocara al procedimiento indicado en nombre del cliente, devolviendo el valor del resultado, si lo hay. Para que sea independiente de la plataforma, todos los datos intercambiados entre el cliente y el servidor son convertidos al formato denominado de Representacion Externa de Datos o XDR8 por el segundo, y convertidos otra vez a la representacion de la maquina local por el receptor. A veces, las mejoras en una aplicacion RPC introducen cambios incompatibles en el interface de llamada a procedimiento. Por supuesto, solo cambiando el servidor dejaria de funcionar cualquier aplicacion que todavia espere el comportamiento original. Por ello, los programas RPC tienen numeros de version asignados, normalmente empezando con 1, y con cada nueva version del interface RPCeste contador se incrementara. A menudo, un servidor puede ofrecer varias versiones a la vez; entonces los clientes indicaran en sus peticiones mediante el numero de version que implementacion del servicio desean usar. _____________________________________________8 N. del T.: del ingles eXternal Data Representation _______________________________________________________________________________________________________________9.4. L* *lamada a Procedimientos @ La comunicacion por red entre servidores y clientes RPC es un poco peculiar. Un servidor RPC ofrece una o mas colecciones de procedimientos; cada conjunto deestos es llamado programa, y es identificado univocamente por un numero de programa. En /etc/rpc se suele mantener una lista que mapea nombres de servicios con numeros de programa, reproducimos un extracto deeste en la figura 9.2. # # /etc/rpc - servicios variados basados en RPC # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate Figura 9.2: Un ejemplo de fichero /etc/rpc. En redes TCP/IP, los autores de RPC se encontraron con el problema de mapear nume- ros de programa a servicios de red genericos. Decidieron que cada servidor proporcionara ambos, un puerto TCP y otro UDP, para cada programa y para cada version. Generalmen- te, las aplicaciones RPC usaran UDP cuando envien datos, y solo recaeran en TCP cuando los datos a transferir no quepan en un datagrama UDP sencillo. Por supuesto, los programas clientes tienen que tener una forma de encontrar a que puer- to mapea un numero de programa. Usando un fichero de configuracion para esto seria muy inflexible: ya que las aplicaciones RPC no usan puertos reservados, no hay garantias de que un puerto originalmente pensado para ser usado por nuestra aplicacion de base de datos no haya sido cogido por algun otro proceso. Por lo tanto, las aplicaciones RPC escogen cual- quier puerto que puedan utilizar, y lo registran con el denominado demonio mapeador de puertos9 . Esteultimo actua como un distribuidor de servicios para todos los servidores que corren en su maquina: un cliente que desee contactar con un servicio que tiene un numero de programa dado, preguntara primero al mapeador de puertos del nodo del servidor quien devolvera los numeros de puerto TCP y UDP por los que el servicio puede ser accedido. Este metodo tiene como mayor inconveniente que introduce un punto de rupturaunico, muy parecido al que crea el demonio inetd en los servicios Berkeley estandar. De todas _____________________________________________9 N. del T.: Del ingles Portmapper daemon _______________________________________________________________________________________________________________9.5. C* *onfigurar los Comandos r@ formas,este caso es un poco mas grave, porque cuando el mapeador de puertos cae, toda la informacion de puertos RPC se pierde; esto normalmente implica que hay que rearrancar todos los servidores RPC manualmente, o rearrancar toda la maquina. En Linux, el mapeador de puertos se llama rpc.portmap y reside en /usr/sbin. Aparte de asegurarse de que es arrancado desde rc.inet2, el mapeador de puertos no necesita mas trabajo de configuracion. 9.5 Configurar los Comandos r Hay varios comandos para ejecutar programas en nodos remotos. Son rlogin, rsh, rcp y rcmd. Todos ellos lanzan un shell en el nodo remoto y permiten al usuario ejecutar comandos. Por supuesto, el cliente necesita tener una cuenta en el nodo en el que se van a ejecutar los comandos. Por ello todos estos comandos llevan a cabo un procedimiento de autorizacion. Normalmente, el cliente indicara el nombre de login del usuario al servidor, el cual requerira un password que sera validado de la forma habitual. A veces, sin embargo, es deseable el relajar estos chequeos de autorizacion para ciertos usuarios. Por ejemplo, si usted tiene que entrar frecuentemente en otras maquinas de su LAN, tal vez desee ser admitido sin tener que escribir su password cada vez. Deshabilitar autorizaciones solo es aconsejable en un numero reducido de nodos cuyas bases de datos de passwords esten sincronizadas, o para un numero reducido de usuarios pri- vilegiados que necesiten acceder a muchas maquinas por razones administrativas. Siempre que desee permitir a gente entrar en su nodo sin tener que especificar un login o password, debe asegurarse de que no permite acceso accidentalmente a nadie mas. Hay dos formas de deshabilitar chequeos de autorizacion para los comandos r. Una es que el super usuario permita a ciertos o a todos los usuarios el entrar, sin ser preguntados por un password, en ciertos o en todos los nodos (lo cual es ciertamente una mala idea). Este acceso es controlado por un fichero denominado /etc/hosts.equiv. Este contiene una lista de nodos y nombres de usuarios que son considerados equivalentes a usuarios en el nodo local. Una opcion alternativa es que un usuario permita acceso a otros usuarios de ciertos nodos a su cuenta. Estos serian listados en el fichero .rhosts en el directorio home del usuario. Por razones de seguridad, este fichero debe pertenecer al usuario o al super usuario, y no debe ser un enlace simbolico, de otro modo sera ignorado.10 Cuando un cliente pide un servicio r, su nodo y nombre de usuario son buscados en el fichero /etc/hosts.equiv, y despues en el fichero .rhosts del usuario con cuyo nombre se _____________________________________________10 En un entorno NFS, podria necesitar darle una proteccion de 444, porque el superusuario por lo general esta muy restringido en el acceso a ficheros en discos montados via NFS. _______________________________________________________________________________________________________________9.5. C* *onfigurar los Comandos r@ pretende entrar. Como ejemplo, asumamos que janet esta trabajando en gauss e intenta entrar en la cuenta de joe en euler. A partir de ahora, nos referiremos a Janet como el usuario cliente, y a Joe como el usuario local. Ahora, cuando Janet escriba $ rlogin -l joe euler en gauss, el servidor primero chequeara en hosts.equiv 11 si a Janet se le puede proporcionar acceso libre y, si esto falla, intentara localizarla en el fichero .rhosts del directorio home de joe. El fichero hosts.equiv en euler es algo asi: gauss euler -public quark.physics.groucho.edu andres Una entrada consiste en un nombre de nodo, seguido opcionalmente por un nombre de usuario. Si aparece un nombre de nodo y nada mas, todos los usuarios de ese nodo seran admitidos en sus cuentas locales sin ninguna comprobacion. En el ejemplo anterior, Janet hubiera sido autorizada a entrar en su cuenta janet si llamaba desde gauss, y lo mismo se aplicaria a cualquier otro usuario exceptuando a root. De todas formas, si Janet desea entrar como joe, se le pediria un password como siempre. Si un nombre de nodo va seguido de un nombre de usuario, como en la ultima linea del fichero ejemplo, a ese usuario se le permite acceso libre de password a todas las cuentas excepto a la cuenta root. El nombre de nodo tambien puede ir precedido de un signo menos, como en la entrada "-public". Esto requiere autorizacion para todas las cuentas en public, sin importar lo que permitan los usuarios individuales en sus ficheros .rhosts. El formato del fichero .rhosts es identico al del hosts.equiv, pero su significado es un poco diferente. Consideremos el siguiente fichero .rhosts de Joe en euler: chomp.cs.groucho.edu gauss janet La primera entrada permite a joe acceso libre cuando entra desde chomp.cs.groucho.edu, pero no afecta a los permisos de ninguna otra cuenta en _____________________________________________11 Observe que el fichero hosts.equiv no es examinado cuando alguien intenta entrar como root. _______________________________________________________________________________________________________________9.5. C* *onfigurar los Comandos r@ euler o chomp. La segunda entrada es una peque"na variacion de esto en que permite a janet acceso libre a la cuenta de Joe cuando entra desde gauss. Observe que el nombre de nodo del cliente se obtiene mediante la resolucion inversa de la direccion del que llama a un nombre, de forma que esta caracteristica fallara con nodos deconocidos para el sistema de resolucion. El nombre de nodo del cliente se considera que coincide con el nombre en los ficheros de nodos en uno de los siguientes casos: o El nombre canonico del cliente (no un alias) coincide literalmente con el nombre de nodo en el fichero. o Si el nombre de nodo del cliente es un nombre de dominio completamente cualificado (como el devuelto por el sistema de resolucion cuando se tiene DNS en marcha), y no coincide literalmente con el nombre de nodo en el fichero de nodos, se compara con el nombre de nodo que se forma al expandirlo con el nombre de dominio local. Capitulo 10 El Sistema de Informacion de Red (NIS) Cuando se usa una red dearea local, su objetivo fundamental es, normalmente, proporcionar a sus usuarios un entorno que haga a la red transparente. Para este fin una importante piedra de toque es mantener datos vitales, como la informacion de cuentas de usuario, sincronizadas entre todos los nodos. Vimos anteriormente que para resolver nombres de nodos existe un potente y sofisticado servicio denominado DNS. Para otras tareas, sin embargo, no existe un servicio especializado similar. Mas aun, si usted solo esta administrando una peque"na LAN sin conexion a Internet, puede que no le merezca la pena el esfuerzo de instalar un DNS. Esta es la razon por la que Sun desarrollo NIS, el Sistema de Informacion de Red. NIS proporciona facilidades de acceso generico a bases de datos que pueden ser usadas para distribuir informacion como la contenida en los ficheros passwd y groups entre todos los nodos de su red. Esto hace que la red aparezca como un sistemaunico, con las mismas cuentas en todos los nodos. De forma similar usted puede usar NIS para distribuir el fichero de informacion de nombres de nodos /etc/hosts entre todas las maquinas de la red. NIS esta basado en RPC, e incluye un servidor, una biblioteca para la parte del cliente, y varias herramientas de administracion. Originalmente NIS se llamaba Yellow Pages1 , o YP, que todavia son terminos ampliamente usados para referirse informalmente a este servicio. Por otra parte Yellow Pages es una marca registrada de la compa"nia British Telecom, la cual pidio que Sun dejara de utilizar ese nombre. Pero, como algunos nombres impactan mucho entre la gente, YP continua viviendo como prefijo en los nombres de la mayoria de los comandos relacionados con NIS como ypserv, ypbind, etc. _____________________________________________1 N. del T.: Paginas Amarillas 143 _______________________________________________________________________________________________________________10.1. * *Familiarizacion con NIS @ Hoy en dia NIS esta disponible en practicamente todos los sistemas un?x, y hay incluso implementaciones gratuitas deel. Una de ellas es de la edicion BSD Net-2, derivada de una implementacion de referencia de dominio publico donada por Sun. El codigo de la biblioteca cliente de esta version existe en la GNU libc desde hace mucho tiempo, mientras que los programas de administracion han sido recientemente portados a Linux por Swen Th"ummler.2 Falta, sin embargo, un servidor NIS en la implementacion de referencia. Tobias Reber ha escrito otro paquete NIS incluyendo todas las herramientas y un servidor; se llama yps.3 Actualmente, el codigo de NIS esta siendo reescrito por completo por Peter Eriksson4, se denominara NYS y soportara tanto el NIS normal como la revision ampliada de Sun, el NIS+. NYS no solo proporciona un conjunto de herramientas NIS y un servidor, sino que tambien a"nade un nuevo y completo conjunto de funciones de biblioteca que muy probablemente se incluiran con el tiempo en la libc estandar. Esto incluye un nuevo sistema de configuracion para resolver nombres de nodos que reemplace el sistema actual que usa el fichero host.conf. Las caracteristicas de estas funciones seran discutidas mas adelante. Este capitulo se centrara en NYS mas que en los otros dos paquetes, a los que nos referi- remos como el codigo NIS "tradicional". Si usted desea utilizar alguno de esos paquetes, las instrucciones de este capitulo podrian ser suficientes o tal vez no. Para obtener informacion adicional, por favor, consiga un libro estandar sobre NIS como el NFS y NIS de Hal Stern (vease [Stern92 ]). Por el momento NYS esta todavia en desarrollo y por lo tanto las utilidades estandar de Linux como los programas de red o el programa de login todavia no tienen en cuenta el sistema de configuracion de NYS. Por lo tanto, hasta que NYS no sea incluido en la libc principal tendra que compilar todos esos programas usted mismo si quiere conseguir que usen NYS. Para ello, en los Makefiles de cualquiera de esas aplicaciones debera especificar -lnsl como laultima opcion antes de libc al enlazador. Esto enlazara las funciones relevantes de libnsl, la biblioteca NYS, en lugar de la biblioteca C estandar. 10.1 Familiarizacion con NIS NIS mantiene informacion de la base de datos en los llamados mapas que contienen pares clave-valor. Los mapas se almacenan en un nodo central que esta ejecutando el servidor NIS y del que los clientes pueden obtener la informacion a traves de varias llamadas RPC. _____________________________________________2 Que puede ser localizado en swen@uni-paderborn.de. Los clientes NIS estan disponibles como yp-linux.tar.gz en metalab.unc.edu en el directorio system/Network. 3 La ultima version (en la fecha en que se escribio este documento) es yps-0.21 y puede obtenerse en ftp.lysator.liu.se, en el directorio /pub/NYS. 4 Localizable en pen@lysator.liu.se. _______________________________________________________________________________________________________________10.1. * *Familiarizacion con NIS @ Muy frecuentemente, los mapas se almacenan en ficheros DBM.5 Los mapas en si mismos suelen ser generados a partir de ficheros de texto maestros como /etc/hosts o /etc/passwd. Para algunos ficheros se crean varios mapas, uno por cada tipo de clave de busqueda. Por ejemplo, usted podria buscar en el fichero hosts tanto por un nombre de nodo como por su direccion IP. Asi pues, deel se derivan dos mapas NIS, llamados hosts.byname y hosts.byaddr respectivamente. La tabla 10.1 lista los mapas tipicos y los ficheros de los que son generados. __________________________________________________________________________ | Fichero Maestro | Mapa(s) | |___________________|_____________________________________________________|_ | /etc/hosts | hosts.byname hosts.byaddr | | | | | /etc/networks | networks.byname networks.byaddr | | | | | /etc/passwd | passwd.byname passwd.byuid | | | | | /etc/group | group.byname group.bygid | | | | | /etc/services | services.byname services.bynumber | | | | | /etc/rpc | rpc.byname rpc.bynumber | | | | | /etc/protocols | protocols.byname protocols.bynumber | | | | | /usr/lib/aliases | mail.aliases | |_____________________|___________________________________________________| Tabla 10.1: Algunos mapas NIS estandar y los ficheros correspodientes. Hay otros ficheros y mapas para los que puede encontrar soporte en uno u otro pa- quete NIS. Estos pueden contener informacion sobre aplicaciones no tratadas en este libro, como el mapa bootparams6 que puede ser usado por algunos servidores BOOTP, o mapas que actualmente no tienen ninguna funcion en Linux (como los mapas ethers.byname y ethers.byaddr ). La gente usa habitulamente apodos para algunos mapas, ya que son mas cortos y por lo tanto mas faciles de escribir. Para obtener una lista completa de los apodos7 reconocidos por sus herramientas NIS, ejecute el siguiente comando: $ ypcat -x NIS map nickname translation table: "passwd" -> "passwd.byname" "group" -> "group.byname" "networks" -> "networks.byaddr" "hosts" -> "hosts.byname" "protocols" -> "protocols.bynumber" _____________________________________________5 DBM es una biblioteca de manejo de bases de datos sencillas que usa tecnicas hashing para acelerar operaciones de busqueda. Existe una implementacion gratuita de DBM perteneciente al proyecto GNU llamada gdbm, que forma parte de la mayoria de las distribuciones de Linux. 6 N. del T.: relacionado con los parametros de arranque 7 N. del T.: del ingles nicknames _______________________________________________________________________________________________________________10.1. * *Familiarizacion con NIS @ "services" -> "services.byname" "aliases" -> "mail.aliases" "ethers" -> "ethers.byname" "rpc" -> "rpc.bynumber" "netmasks" -> "netmasks.byaddr" "publickey" -> "publickey.byname" "netid" -> "netid.byname" "passwd.adjunct" -> "passwd.adjunct.byname" "group.adjunct" -> "group.adjunct.byname" "timezone" -> "timezone.byname" El servidor NIS suele llamarse ypserv. Para una red de tipo medio ununico servidor suele ser suficiente; en redes mayores pueden elegir ejecutar varios en maquinas diferentes y en diferentes segmentos para aliviar la carga en los servidores y en los encaminadores. Estos servidores estan sincronizados haciendo que uno de ellos sea el servidor maestro y que los demas sean servidores esclavos. Los mapas se crearan solo en la maquina del servidor maestro. A partir de ahi son distribuidos a todos los esclavos. Habra notado usted que hemos estado hablando de "redes" todo el rato muy vagamente; por supuesto existe un concepto diferenciado en NIS sobre lo que es un dominio en la red: es el conjunto de todos los nodos que comparten parte de sus datos de configuracion del sistema mediante NIS. Desafortunadamente los dominios NIS no tienen absolutamente nada que ver con los dominios que podemos encontrar en DNS. Por ello, para evitar cualquier tipo de ambig"uedad a lo largo de este capitulo, especificaremos en todo momento el tipo de dominio al que nos estemos refiriendo. Los dominios NIS tienen solo una funcion puramente administrativa. Son ademas invi- sibles para los usuarios. Por ello el nombre dado a un dominio NIS es solo relevante para administradores. Por lo general cualquier nombre valdra con tal de que sea distinto de cualquier otro nombre de dominio NIS de su red local. Por ejemplo, el administrador de la Cervecera Virtual puede decidir crear dos dominios NIS, uno para la Cervecera en si, y otro para la Vinatera, a los que llama cervecera y vinatera respectivamente. Otra idea bas- tante utilizada es usar simplemente el nombre de dominio DNS tambien para el NIS. Para establecer y ver el nombre de dominio NIS de su nodo puede usar el comando domainname. Cuando se ejecuta sin ningun argumento, muestra el nombre de dominio NIS actual; para establecer el nombre de dominio, debe usted entrar como superusuario y escribir: # domainname cervecera Los dominios NIS determinan a que servidor NIS preguntaran las aplicaciones. Por ejemplo, el programa login de un nodo de la Vinatera deberia, por supuesto, pedir infor- macion de la contrase"na de un usuario solo al servidor NIS de la Vinatera (o a uno de _______________________________________________________________________________________________________________10.2. * *NIS frente a NIS+ @ ellos si es que hay varios), mientras que una aplicacion de un nodo de la Cervecera deberia arreglarselas con el servidor de la Cervecera. Queda un misterio por resolver: como sabe un cliente a que servidor conectarse. La solucion mas simple seria tener un fichero de configuracion que diga el nodo en el que encontrar el servidor. Sin embargo, esta solucion es bastante inflexible porque no permite a los clientes usar servidores diferentes (del mismo dominio, se entiende), dependiendo de su disponiblidad. Por ello las implementaciones tradicionales de NIS se apoyan en un demonio especial denominado ypbind para detectar un servidor NIS adecuado dentro de su dominio NIS. Cualquier aplicacion, antes de poder realizar cuaquier consulta NIS, debe averiguar primero, a traves de ypbind, que servidor usar. ypbind busca los servidores mandando un mensaje de difusion por toda la red IP local. El primero en responder se supone que sera el mas rapido potencialmente y sera el que se use en todas las consultas NIS subsiguientes. Despues de un cierto intervalo de tiempo, o si el servidor se vuelve inaccesible, ypbind volvera a buscar los servidores activos. Ahora bien, hay dos aspectos discutibles sobre el enlazado dinamico: uno es que ra- ramente es necesario y el otro es que introduce un problema de seguridad: ypbind cree a ciegas a cualquiera que conteste, que podria ser lo mismo un humilde servidor NIS que un intruso malicioso. No hace falta decir que esto es especialmente problematico si usted maneja sus bases de datos de contrase"nas a traves de NIS. Para protegerse contra esto, NYS no usa ypbind por defecto, sino que obtiene el nombre de nodo del servidor de un fichero de configuracion. 10.2 NIS frente a NIS+ NIS y NIS+ comparten poco mas que su nombre y un objetivo comun. NIS+ esta estruc- turado de una forma completamente diferente. En lugar de un simple espacio de nombres con dominios NIS inconexos, usa un espacio de nombres jerarquico similar al de DNS. En lugar de mapas, usa tablas que estan compuestas por filas y columnas, donde cada fila representa un objeto en la base de datos NIS+, mientras que las columnas cubren aquellas propiedades de los objetos que NIS+ conoce y que le interesan. Cada tabla de un dominio NIS+ dado incluye las de sus dominios padre. Ademas, una entrada en una tabla puede contener un enlace a otra tabla. Todas estas caracteristicas hacen posible la estructuracion de la informacion de muchas formas. El NIS tradicional tiene un numero de version RPC de 2, mientras que NIS+ tiene un numero de version RPC de 3. _______________________________________________________________________________________________________________10.3. * *El lado cliente de NIS @ NIS+ no parece ser ampliamente usado todavia 8 , y no conozco tanto sobreel realmente (bueno, practicamente nada). Por esta razon, no lo trataremos aqui. Si esta interesado en aprender mas sobreel, por favor, refierase al manual de administracion de NIS+ de Sun ([NISPlus ]). 10.3 El lado cliente de NIS Si esta usted familiarizado con la escritura o el portado de aplicaciones de red, notara que la mayoria de los mapas NIS listados arriba corresponden a funciones de la biblioteca C. Por ejemplo, para obtener informacion del fichero passwd, se suelen usar normalmente las funciones getpwnam(3) y getpwuid(3) que devuelven informacion de la cuenta asociada al nombre de usuario dado, o al identificador de usuario dado, respectivamente. En circuns- tancias normales, estas funciones realizaran la busqueda requerida en el fichero estandar /etc/passwd. Una implementacion de estas funciones que tenga en cuenta NIS, sin embargo, modifi- cara este comportamiento, y realizara una llamada RPC para que sea el servidor NIS el que realice la busqueda del nombre o identificador de usuario. Esto ocurre de forma completa- mente transparente a la aplicacion. La funcion podria "a"nadir" el mapa NIS o "sustituir" el fichero original conel. Por supuesto, esto no implica una modificacion real del fichero, solo significa que a la aplicacion le parece que el fichero ha sido sustituido o que le han a"nadido algo. En las implementaciones tradicionales de NIS solia haber ciertas convenciones sobre que mapas se sustituian y cuales eran a"nadidos a la informacion original. Alguno, como el mapa passwd, requeria modificaciones extra"nas del fichero passwd que, si se hacian mal, podrian abrir agujeros de seguridad. Para evitar estos obstaculos, NYS usa un modo general de configuracion que determina si un conjunto de funciones cliente en particular usa los ficheros originales, NIS o NIS+, y en que orden. Esto sera descrito en otra seccion mas adelante en este mismo capitulo. 10.4 Ejecucion de un servidor NIS Despues de todo este parloteo tecnico teorico, ya empieza a ser hora de que metamos mano al verdadero trabajo de configuracion. En esta seccion cubriremos la configuracion de un servidor NIS. Si ya hay un servidor NIS corriendo en su red, no necesita configurar su propio servidor; en este caso puede usted saltarse esta seccion. _____________________________________________8 N. del T.: En el momento de escribirse este manual esta afirmacion era cierta. Sin embargo, hoy en dia NIS+ es ampliamente usado por sus ventajas frente a NIS. _______________________________________________________________________________________________________________10.* *4. Ejecucion de un servidor@ 3 Observe que siunicamente va usted a experimentar con el servidor, tiene que asegurarse de que no lo configura con un nombre de dominio NIS que ya este en uso en su red. Ello podria desbaratar todo el servicio de red y hacer a mucha gente desdichada, y muy enfadada. Actualmente hay disponibles dos servidores NIS de forma gratuita para Linux, uno contenido en el paquete yps de Tobias Reber, y el otro en el paquete ypserv de Peter Eriksson. No deberia importar cual utilice usted, independientemente de que usted use NYS o el codigo de cliente NIS estandar que existe actualmente en libc. En el momento de escribir esto, el codigo para manejar servidores NIS esclavos parece ser mas completo en yps. Asi que si tiene que tratar con servidores esclavo, yps puede ser una opcion mejor. Tras instalar el programa servidor (ypserv ) en /usr/sbin, debera crear el directorio que va a contener los ficheros mapa que su servidor va a distribuir. Al establecer un dominio NIS para el dominio cervecera, los mapas irian al fichero /var/yp/cervecera. El servidor determina si esta sirviendo un dominio NIS en particular comprobando si el directorio mapa esta presente. Si va a deshabilitar el servicio para algun dominio NIS, asegurese de eliminar el directorio tambien. Los mapas normalmente se almacenan en ficheros DBM para acelerar las busquedas. Se crean a partir de los ficheros maestro usando un programa llamado makedbm (para el servidor de Tobias) o dbmload (para el servidor de Peter). Estos pueden no ser intercam- biables. Transformar un fichero maestro a una forma entendible por dbmload normalmente requiere un poco de magia awk o sed, lo que tiende a ser un poco tedioso de escribir y dificil de recordar. Por ello, el paquete ypserv de Peter Eriksson contiene un Makefile (llamado ypMakefile) que realiza todos esos trabajos por usted. Deberia instalarlo como Makefile en su directorio de mapas, y editarlo para que refleje los mapas que desee distribuir. Hacia el principio del fichero encontrara la etiqueta all que lista los servicios que ypserv ofrece. Por defecto, la linea es algo parecido a esto: all: ethers hosts networks protocols rpc services passwd group netid Si no desea producir los mapas ethers.byname y ethers.byaddr, por ejemplo, simplemente elimine la palabra ethers de la linea. Para probar su configuracion, puede ser suficiente con empezar con solo uno o dos mapas, como los mapas services.*. Tras editar el Makefile, y sin salir del directorio de mapas, teclee "make". Esto generara e instalara automaticamente los mapas. Debe asegurarse de actualizar los mapas cada vez que cambie los ficheros maestros, de otro modo los cambios seguiran siendo invisibles para la red. _______________________________________________________________________________________________________________10.5. * *Configurar un Cliente NI@ La siguiente seccion explica como configurar el codigo de cliente NIS. Si su configuracion no funciona, deberia comprobar si llega alguna peticion a su servidor o no. Si especifica el parametro -D al servidor NYS,este imprimira mensajes de depuracion en la consola sobre todas las peticiones NIS entrantes, y los resultados devueltos. Esto deberia darle una idea sobre donde puede estar el problema. El servidor de Tobias no tiene esa opcion. 10.5 Configurar un Cliente NIS con NYS A lo largo de lo que queda de este capitulo, cubriremos la configuracion de un cliente NIS. Su primer paso deberia ser indicarle a NYS que servidor usar para el servicio NIS, estableciendolo en el fichero de configuracion /etc/yp.conf. Un fichero de ejemplo muy sencillo para un nodo en la red de la Vinatera seria algo asi: # yp.conf - Configuracion YP para la biblioteca NYS. # domainname vinatera ypserver vbardolino La primera sentencia indica a los clientes NIS que pertenecen al dominio NIS vinatera. Si omite esta linea, NYS usara el nombre de dominio que usted asigno a su sistema con el comando domainname. La sentencia ypserver indica el servidor a usar. Por supuesto, la direccion IP correspondiente a vbardolino debe estar establecida en el fichero hosts; alternativamente, podria usar directamente la direccion IP en la sentencia ypserver. En el fichero mostrado arriba, el comando ypserver indica a NYS que use el servidor indicado sea cual sea el dominio NIS actual. Sin embargo, si mueve frecuentemente su maquina entre diferentes dominios NIS, tal vez le interesaria mantener la informacion de varios dominios en el fichero yp.conf. Puede tener informacion sobre los servidores para varios dominios NIS en yp.conf a"nadiendo el nombre de dominio NIS a la sentencia ypserver. Por ejemplo, podria cambiar el fichero del ejemplo anterior para que sea algo asi: # yp.conf - Configuracion YP para la biblioteca NYS. # ypserver vbardolino vinatera ypserver vstout cervecera Esto le permite mover su maquina a cualquiera de los dos dominios simplemente con establecer el dominio NIS deseado durante el arranque con el comando domainname. _______________________________________________________________________________________________________________10.6. * *Eleccion de los Mapas Co@ Una vez creado este fichero de configuracion basico y de asegurarse de que tiene permiso de lectura para todo el mundo, deberia realizar su primera prueba para comprobar si puede conectar con su servidor. Asegurese de elegir cualquier mapa que su servidor distribuya, como hosts.byname, e intente obtenerlo usando la utilidad ypcat. ypcat, como todas las demas herramientas NIS, debe encontrarse en /usr/sbin. # ypcat hosts.byname 191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org 191.72.2.3 vbardolino vbardolino.linus.lxnet.org 191.72.1.1 vlager vlager.linus.lxnet.org 191.72.2.1 vlager vlager.linus.lxnet.org 191.72.1.2 vstout vstout.linus.lxnet.org 191.72.1.3 vale vale.linus.lxnet.org 191.72.2.4 vchianti vchianti.linus.lxnet.org La salida que obtenga debe ser algo parecido a lo expuesto arriba. Si recibe un mensaje de error en su lugar que diga "Can't bind to server which serves domain" (no se pue- de conectar al servidor del dominio), o algo similar, entonces, o el nombre de dominio NIS que ha establecido no tiene definido su servidor correspondiente en yp.conf, o el servidor, por alguna razon, no esta disponible. En este ultimo caso, asegurese de que un ping a esa maquina da un resultado positivo, y de que esta en efecto ejecutando un servidor NIS. Puede verificar estoultimo usando rpcinfo, que deberia producir la siguiente salida: # rpcinfo -u servidor ypserv program 100004 version 2 ready and waiting 10.6 Eleccion de los Mapas Correctos Una vez que este seguro de que puede llegar al servidor NIS, debe decidir que ficheros de configuracion sustituir o aumentar con mapas NIS. Normalmente deseara usar mapas NIS para las funciones de busqueda de nodos y de claves de usuario. El primero es especialmente util si no utiliza DNS. El segundo permite a todos los usuarios entrar en su cuenta desde cualquier sistema dentro del dominio NIS; esto suele requerir compartir un directorio /home central entre todos los nodos mediante NFS. Todo esto se explica en detalle en la seccion 10.7 mas abajo. Otros mapas, como services.byname, no proporcionan una ganancia tan clara, pero ahorran algo de trabajo de edicion si instala alguna aplicacion de red que use un nombre de servicio que no este en el fichero services estandar. Por lo general, usted deseara tener alguna libertad de eleccion acerca de cuando una funcion de busqueda usara ficheros locales y cuando hara una peticion al servidor NIS. _______________________________________________________________________________________________________________10.6. * *Eleccion de los Mapas Co@ NYS le permite configurar el orden en que una funcion accede a estos servicios. Esto se controla mediante el fichero /etc/nsswitch.conf, que quiere decir Selector del Servicio de Nombrado9 pero por supuesto no esta limitado a los servicios de nombres. Para cualquiera de las funciones de busqueda de datos soportadas por NYS, contiene una linea citando los servicios a usar. El orden correcto de los servicios depende del tipo de datos. Es improbable que el mapa services.byname contenga entradas diferentes que las que se encuentran en el fichero services local;unicamente podria contener mas. Asi que una buena eleccion seria consultar los ficheros locales primero, y probar con NIS solo si el nombre del servicio no fue encontrado. Por otro lado, la informacion de nombres de nodos puede cambiar muy frecuentemente, de forma que el DNS o el servidor NIS tendrian siempre la informacion mas precisa, mientras que el fichero hosts local solo se mantiene como copia de respaldo por si el DNS y NIS fallasen. En este caso, habria que comprobar el fichero local enultimo lugar. El siguiente ejemplo muestra como configurar las funciones gethostbyname(2), gethostb- yaddr(2), y getservbyname(2) de la forma descrita anteriormente. Probaran los servicios listados por orden; si una busqueda es satisfactoria, se devuelve el resultado, si no, se intentara con el siguiente servicio. # /etc/nsswitch.conf de ejemplo # hosts: nis dns files services: files nis Mas abajo se muestra la lista completa de servicios que pueden ser usados en una entrada del fichero nsswitch.conf. Los mapas, ficheros, servidores y objetos que se pueden consultar dependen del nombre de la entrada. nisplus o nis+ Usa el servidor NIS+ para este dominio. La situacion del servidor se obtiene del fichero /etc/nis.conf. nis Usa el servidor NIS actual de este dominio. La situacion del servidor con- sultado esta configurada en el fichero yp.conf como se mostro en la sec- cion previa. Para la entrada hosts se consultan los mapas hosts.byname y hosts.byaddr. dns Usa el servidor de nombres DNS. Este tipo de servicio solo es util con la entrada hosts. Los servidores de nombres consultados siguen estando deter- minados por el fichero estandar resolv.conf. _____________________________________________9 N. del T.: del ingles Name Service Switch. _______________________________________________________________________________________________________________10.7. * *Uso de los mapas passwd @ files Usa el fichero local. Como el fichero /etc/hosts para la entrada hosts. dbm Busca la informacion en ficheros DBM localizados en /var/dbm. El nombre usado para el fichero es el del mapa NIS correspondiente. Actualmente NYS soporta las siguientes entradas en nsswitch.conf : hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc y ethers. Es probable que se a"nadan mas entradas. La figura 10.1 muestra un ejemplo mas completo que introduce otra caracteristica del fichero nsswitch.conf : la palabra clave [NOTFOUND=return] en la entrada hosts indica a NYS que retorne si el elemento deseado no pudo ser encontrado en la base de datos NIS o DNS. Esto es, NYS continuara y buscara en los ficheros locales solo si las llamadas a los servidores NIS y DNS fallaron por alguna otra razon. Los ficheros locales seran usados entonces solo durante el arranque y como copia de respaldo cuando el servidor NIS se haya caido. # /etc/nsswitch.conf # hosts: nis dns [NOTFOUND=return] files networks: nis [NOTFOUND=return] files services: files nis protocols: files nis rpc: files nis Figura 10.1: Fichero nsswitch.conf de ejemplo. 10.7 Uso de los mapas passwd y group Uno de las usos mas importantes de NIS es sincronizar usuarios e informacion de cuentas en todos los nodos de un dominio NIS. Para este fin, solo se suele mantener un peque"no fichero local /etc/passwd, al que se le a"nade informacion de todas las demas cuentas me- diante los mapas NIS. Sin embargo, solo con habilitar busquedas NIS para este servicio en nsswitch.conf no es suficiente. Cuando se base en la informacion de contrase"nas distribuida por NIS, debe primero cerciorarse de que los numeros identificadores de cualquier usuario que tenga en su fichero passwd local coincidan con la idea que tiene el servidor NIS de identificadores de usuarios. Usted tambien deseara esto para otros propositos, como montar volumenes NFS de otros nodos de su red. _______________________________________________________________________________________________________________10.7. * * Uso de los mapas passwd @ Si alguno de los numeros de usuario de /etc/passwd o de /etc/group son distintos de los que aparecen en los mapas, tiene que ajustar el propietario de todos los ficheros que pertenezcan a ese usuario. Primero deberia cambiar todos los numeros de uid y gid en passwd y group a los nuevos valores; despues, encontrar todos los ficheros que pertenezcan a los usuarios recien modificados, y finalmente cambiarles el propietario. Supongamos que news tenia un numero de usuario de 9, y que okir tenia un numero de usuario de 103, y que estos fueron cambiados a algun otro valor; entonces deberia teclear los siguientes comandos: # find / -uid 9 -print >/tmp/uid.9 # find / -uid 103 -print >/tmp/uid.103 # cat /tmp/uid.9 | xargs chown news # cat /tmp/uid.103 | xargs chown okir Es importante que ejecute estos comandos con el nuevo fichero passwd ya instalado, y que recoja todos los nombres de ficheros antes de cambiar el propietario de cualquiera de ellos. Para cambiar el grupo propietario de los ficheros, se usara un comando similar. Una vez hecho esto, los numeros de uid y gid de su sistema estaran de acuerdo con los de los demas nodos de su dominio NIS. El siguiente paso sera a"nadir las lineas de configuracion a nsswitch.conf que habiliten las busquedas NIS de informacion de usuario y grupo. # /etc/nsswitch.conf - tratamiento de contrase\~na y grupo passwd: nis files group: nis files Esto hace que el comando login y otros de esta familia consulten primero los mapas NIS cuando un usuario intenta entrar, y si esta busqueda falla, sigan con los ficheros locales. Normalmente usted borrara la mayor parte de los usuarios de sus ficheros locales y solo dejara en ellos entradas para root y para cuentas genericas como mail. Esto es porque algunas tareas vitales del sistema pueden requerir mapear uids a nombres de usuario o viceversa. Por ejemplo, las tareas cron administrativas pueden ejecutar el comando su para convertirse temporalmente en news, o el subsistema UUCP puede enviar un informe de estado en un mensaje. Si news y uucp no tienen entradas en el fichero passwd local, estas tareas fallaran miserablemente durante un apagon de NIS. Dos observaciones importantes: por un lado, la configuracion descrita hasta aqui solo funciona para sistemas de login que no usan contrase"na shadow, como los incluidos en el paquete util-linux. Los intrincados metodos para usar contrase"nas shadow con NIS seran cubiertos mas adelante. Por otro lado, los comandos login no son losunicos que acceden al fichero passwd - por ejemplo la orden ls que la mayor parte de la gente usa constantemente. Cada vez que se saca un listado con la opcion -l, ls mostrara los nombres simbolicos del _______________________________________________________________________________________________________________10.8. * *Uso de NIS con Soporte S@ propietario y del grupo; esto es, por cada uid y gid que encuentre, debera hacer una peticion al servidor NIS. Esto ralentizara mucho todo el sistema cuando su red local se atasque, o, aun peor, cuando el servidor NIS no este en la misma red fisica, de forma que los datagramas tengan que pasar a traves de un encaminador o puente. Y esto no es todo. Imagine lo que pasa si un usuario quiere cambiar su contrase"na. Normalmente invocara el comando passwd, que leera la nueva contrase"na y actualizara el fichero passwd local. Esto es imposible con NIS, puesto que ese fichero no esta disponible localmente, y tampoco es una opcion que los usuarios entren en el servidor NIS cada vez que quieran cambiar la clave. Por ello, NIS proporciona un sustituto para passwd llamado yppasswd, que realiza una tarea analoga en NIS. Para cambiar la contrase"na en la maquina servidora, contacta con el demonio yppasswdd en ese nodo mediante RPC, y le proporcio- na informacion de la contrase"na actualizada. Generalmente, yppasswd se instala sobre el programa normal haciendo algo asi: # cd /bin # mv passwd passwd.old # ln yppasswd passwd Al mismo tiempo tendra que instalar rpc.yppasswdd en el servidor y arrancarlo desde los guiones rc. Esto ocultara de forma efectiva todas las complicaciones de NIS a sus usuarios. 10.8 Uso de NIS con Soporte Shadow Todavia no existe soporte NIS para instalaciones que usan el conjunto de utilidades shadow password. John F. Haugh, el autor del conjunto shadow, publico recientemente una version de las funciones de biblioteca shadow en comp.sources.misc, cubiertas por la licencia LGPL de GNU. Ya tiene algun soporte para NIS, pero no esta completa, y los ficheros no han sido a"nadidos todavia a la biblioteca C estandar. Por otro lado, publicar la informacion de /etc/shadow via NIS rompe de alguna manera con el proposito del conjunto shadow. Aunque las funciones de busqueda de contrase"na en NYS no usan un mapa sha- dow.byname ni nada parecido, NYS soporta el uso de un fichero /etc/shadow local de forma transparente. Cuando la implementacion NYS de getpwnam es llamada para buscar informacion relacionada con un login dado, se consultan las facilidades especificadas por la entrada passwd en nsswitch.conf. El servicio nis seguira mirando en el mapa passwd.byname del servidor NIS. En cambio, el servicio files mirara si existe /etc/shadow y lo intentara abrir. Si no existe, o si el usuario no tiene privilegios de root, volvera al comportamiento tradi- cional de mirar la informacion del usuario solo en /etc/passwd. Sin embargo, si el fichero shadow existe y puede ser abierto, NYS extraera la contrase"na del usuario de shadow. La _______________________________________________________________________________________________________________10.9. * *Uso del Codigo NIS Tradi@ funcion getpwuid se implementa similarmente. De esta forma, los binarios compilados con NYS funcionaran de forma transparente con una instalacion shadow local. 10.9 Uso del Codigo NIS Tradicional Si esta usando el codigo de cliente existente en la libc estandar, la configuracion de un cliente NIS es un poco diferente. Por un lado, se usa un demonio ypbind para buscar por la red servidores activos en vez de obtener esta informacion de un fichero de configuracion. Usted tendra por ello que cerciorarse de que arranca ypbind durante la inicializacion del sistema. Debe ser invocado despues de que el dominio NIS haya sido establecido y de que el mapeador de puertos RPC haya sido arrancado. Despues podra invocar ypcat para comprobar el servidor como se mostro mas arriba. Recientemente ha habido numerosos informes de error indicando que NIS falla con un mensaje de error que dice: "clntudp_create: RPC: portmapper failure - RPC: unable to receive". Estos mensajes de error son debidos a un cambio incompatible en el modo en que ypbind comunica la informacion de enlazado a las funciones de biblioteca. Con obtener las fuentes mas recientes de las utilidades NIS y recompilarlas se deberia solucionar este problema.10 Del mismo modo, la forma en que el NIS tradicional decide si hay que mezclar infor- macion NIS, y como, con la de los ficheros locales es distinta que la usada por NYS. Por ejemplo, para usar los mapas de contrase"na NIS, debe incluir la siguiente linea en algun lugar de su mapa /etc/passwd : +:*:0:0::: Esto marca el lugar donde las funciones de busqueda de contrase"nas "insertan" los mapas NIS. Insertando una linea similar (menos los dosultimos dos puntos) en /etc/group obtenemos lo mismo para los mapas group.*. Para usar los mapas hosts.* distribuidos por NIS, cambie la linea order del fichero host.conf. Por ejemplo, si desea usar NIS, DNS, y el fichero /etc/hosts (por ese orden), necesita cambiar esa linea por: order yp bind hosts La implementacion NIS tradicional no soporta ningun otro mapa mas por el momento. _____________________________________________10 El codigo fuente de yp-linux puede obtenerse de ftp.uni-paderborn.de, en el directorio /pub/Linux/LOCAL. Capitulo 11 El Sistema Ficheros en Red (NFS) NFS, acronimo de Network File System, que nosotros llamaremos Sistema de Ficheros en Red, es probablemente el servicio mas complejo de los que se ofrecen usando RPC. Permite acceder a los ficheros remotos exactamente igual que si fueran locales. Esto se hace progra- mando parte de la funcionalidad a nivel del nucleo (en el lado del cliente) y la otra parte como un demonio servidor. El acceso a los ficheros es totalmente transparente al cliente, funcionando con muchas arquitecturas de servidores. NFS ofrece numerosas ventajas: o Los datos accedidos por todo tipo de usuarios pueden mantenerse en un nodo central, con clientes que montan los directorios en el momento de arrancar. Por ejemplo, puede mantener todas las cuentas de usuario en una maquina, y hacer que las demas monten dichas cuentas en su directorio /home por NFS. Si ademas se instala NIS, los usuarios podrian entrar y trabajar de forma transparente en cualquiera de las maquinas. o Los datos que consumen grandes cantidades de espacio de disco pueden mantenerse en un nodo. Por ejemplo, mantener una sola copia de LATEX en lugar de copiarlo en cada nodo. o Los datos de administracion pueden tambien mantenerse en un solo nodo. Ya no sera necesario usar rcp para instalar el mismo fichero en 20 maquinas distintas. El NFS de Linux es, principalmente, obra de Rick Sladkey,1, pues escribio el codigo que corresponde al nucleo y buena parte del codigo del servidor NFS. Esteultimo es una modificacion del servidor unfsd que corre en espacio de usuario, escrito originalmente por Mark Shand, y el servidor hnfs (Harris NFS) escrito por Donald Becker. _____________________________________________1 Puede contactar con Rick en la direccion jrs@world.std.com 157 _______________________________________________________________________________________________________________10.9. * *Uso del Codigo NIS Tradi@ Veamos ahora un poco como funciona NFS: un cliente puede solicitar montar un direc- torio desde un servidor remoto, de forma similar a como montaria un directorio local. Sin embargo, la sintaxis no es exactamente igual. Por ejemplo, para montar el directorio /home del nodo vlager en el directorio /users de vale, el administrador escribiria el siguiente comando en vale:2 # mount -t nfs vlager:/home /users mount intentara conectar con el demonio remoto mountd mediante RPC. El servidor comprobara si la maquina vale tiene permiso para montar el directorio pedido, y si es asi retornara un descriptor de fichero. Este descriptor se utilizara en todas las peticiones que sobre ficheros de /users se realicen posteriormente. Cuando alguien accede a un fichero remoto, el nucleo manda una llamada RPC al programa nfsd (demonio de NFS) del nodo remoto. Esta llamada incluye el descriptor de fichero, el nombre del fichero a acceder y los identificadores de usuario y de grupo del demandante. Estos identificadores se usan para chequear permisos de acceso en la maquina remota, con lo que los usuarios de ambas maquinas deberian ser los mismos. En varias implementaciones de un?x, las funcionalidades de cliente y servidor NFS se realizan como demonios de nivel de nucleo que se arrancan desde el espacio de usuario al arrancar la maquina. Se trata del programa nfsd en el servidor y del programa biod (Block I/O Daemon, o demonio de E/S3 por bloques) en el cliente. Para aumentar el rendimiento, biod realiza E/S asincrona, y a veces corren concurrentemente varios servidores de NFS. La implementacion de NFS en Linux es algo diferente: el codigo de cliente esta integrado en la capa de sistema de ficheros virtual (VFS) y no requiere control adicional mediante el programa biod. Por otro lado, el codigo de servidor corre totalmente en el espacio de usuario, por lo que ejecutar varias copias del nfsd resulta imposible debido a los problemas de sincronizacion que originaria. El mayor problema con el codigo NFS de Linux es que el nucleo 1.0 no puede manejar bloques de memoria de mas de 4Kb, por lo que el codigo de red no puede manejar datagra- mas de un tama"no mayor que 3500 octetos una vez eliminadas las cabeceras. Esto significa que las transferencias con servidores NFS que utilicen datagramas grandes por defecto (por ejemplo, los 8Kb de SunOS) necesitan ser reducidos artificialmente. Esto produce perdi- das de rendimiento en ciertas circunstancias.4 Esta limitacion desaparecio en los nucleos posteriores al 1.1, reescribiendose el codigo del cliente para aprovechar la nueva situacion. _____________________________________________2 Observar que puede omitirse la opcion -t nfs, ya que el programa mount sabe por la aparicion de los dos puntos (:) que se trata de un sistema NFS. 3 N. del T.: E/S es Entrada/Salida 4 Como me explico Alan Cox: La especificacion de NFS requiere que el servidor guarde cada escritura en disco antes de retornar un reconocimiento al cliente (ACK). Como los nucleos de BSD solo manejan _______________________________________________________________________________________________________________11.1. * *Preparacion de NFS @ 11.1 Preparacion de NFS Antes de usar NFS, sea en cliente o servidor, debe asegurarse de que el nucleo tiene el soporte incluido. Los nucleos modernos informan de ello a traves del sistema /proc, con un comando como el siguiente: $ cat /proc/filesystems minix ext2 msdos nodev proc nodev nfs Si no aparece la palabra nfs, tendra que recompilar el nucleo con el soporte NFS habi- litado. Sobre como configurar el nucleo hablamos en la seccion "Configuracion del Nucleo" del capitulo 3. Con versiones del nucleo anteriores a la 1.1, la forma de comprobarlo es intentar montar un sistema NFS de prueba, de la siguiente forma: # mkdir /tmp/test # mount localhost:/etc /tmp/test Si el comando mount falla con el mensaje "fs type nfs no supported by kernel" (sistema tipo NFS no soportado por el nucleo), debera recompilar el nucleo habilitando NFS. Otro tipo de errores no implican recompilar el nucleo, ya que se producen al no estar corriendo el programa nfsd. 11.2 Montaje de un volumen NFS Los volumenes NFS5 se montan como los sistemas de ficheros usuales. Se trata de llamar al comando mount con la sintaxis: # mount -t nfs volumen_nfs directorio_local opciones _____________________________________________ escrituras del tama"no de pagina (4 Kb), escribir en 4 veces 1Kb cada una en un servidor NFS basado en BSD tiene como consecuencia hacer cuatro operaciones de escritura de 4 Kb cada una. 5 Hablamos de volumenes, y no de sistemas de ficheros, porque no lo son realmente: pueden ser solo directorios de un sistema. _______________________________________________________________________________________________________________11.2. * *Montaje de un volumen NF@ La parte volumen_nfs se especifica con la sintaxis "nodo_remoto :directorio_remoto ". Dado que esta notacion es propia del NFS, la opcion -t nfs resulta redundante. Hay otras opciones que pueden incluirse en el programa mount, que van tras el modifi- cador -o en la linea de comando o en el campo de opciones de la entrada correspondiente en el fichero /etc/fstab. En ambos casos, las distintas opciones deben separarse por comas. Las opciones que se especifiquen en la linea de comandos tendran preferencia sobre otras que se indiquen en /etc/fstab. Una entrada de ejemplo del fichero /etc/fstab podria ser # volumen directorio tipo opciones news:/usr/spool/news /usr/spool/news nfs timeo=14,intr Ahora el volumen anterior puede montarse con la orden # mount news:/usr/spool/news Ante la ausencia de una entrada en fstab, las llamadas al programa mount se hacen mas incomodas. Por ejemplo, puede que tenga que teclear cosas comoesta, para especificar que se limite el tama"no del datagrama a 2 Kb: # mount moonshot:/home /home -o rsize=2048,wsize=2048 La lista de todas las opciones validas para mount se encuentra descrita en la pagina de ayuda nfs(5) que viene con la utilidad de montaje de Rick Sladkey, que forma parte del paquete util-linux de Rik Faith. Las opciones mas interesantes son las siguientes: rsize=n y wsize=n Especifican el tama"no de datagrama utilizado por el cliente NFS en las pe- ticiones de lectura y escritura, respectivamente. Por defecto, cada una de ellas vale 1024 octetos, dados los limites del tama"no de datagrama UDP ya comentados. timeo=n Esta opcion establece el tiempo maximo de espera de respuesta a una peti- cion del cliente NFS; en centesimas de segundo. Por defecto, este valor es de 0.7 segundos. hard Marca el montaje del volume como fisico. Es un valor por defecto. soft Hace que el montaje sea solo logico (opuesto al anterior). _______________________________________________________________________________________________________________11.3. * *Demonios de NFS @ intr Esta opcion habilita la posibilidad de que una se"nal interrumpa una espera por NFS. Esutil para poder abortarla cuando el servidor no responde. Cuando el cliente realiza una peticion al servidor NFS, esperara un tiempo maximo (el que se especifica en la opcion timeout ). Si no hay confirmacion tras ese tiempo (tiempo que se denomina "de expiracion" o timeout) tiene lugar otra espera, "de expiracion secundaria" o minor timeout, en el que la operacion se reintenta pero doblando el tiempo de expiracion inicial. Tras 60 segundos, se retorna a la expiracion principal o major timeout. Por defecto, la expiracion principal hara que el cliente envie un mensaje a la consola y empiece de nuevo, con una expiracion del doble de tiempo. Potencialmente, esto podria mantenerse eternamente. En este caso se habla de montaje fisico o hard-mount. La otra variedad, el montaje logico o soft-mount, genera un mensaje de error de E/S al proceso llamante cuando se produce la expiracion principal. El error no se propaga al proceso hasta que hace una nueva llamada a write(2), por lo que esto, junto con la politica de escritura desde la cache, hace que no se sepa realmente si una operacion de escritura ha tenidoexito o no, a menos que el volumen este montado de forma fisica. En general, se recomienda el montaje fisico salvo en caso de tratarse de informacion no critica, como la de servidores de FTP o particiones de noticias. En entornos criticos (por ejemplo, estaciones de trabajo X con dependencia de servidores de aplicaciones X Window) no debe usarse el montaje logico a riesgo de perder las conexiones si en un momento se satura o desactiva la red por algun motivo. Una solucion alternativa a usar montajes fisicos es aumentar el valor de la opcion timeo, o bien usar montajes fisicos pero permitiendo el envio de se"nales para interrumpir las esperas en caso de necesidad. Normalmente, el demonio mountd llevara de alguna forma un registro de que directorios estan montados desde que maquinas. El programa showmount, incluido en el paquete de aplicaciones NFS, permite consultar esta informacion. De todas formas, el mountd de Linux aun no lleva estos registros. 11.3 Demonios de NFS Si desea proporcionar un servicio NFS a otras maquinas, debera ejecutar en el servidor los programas nfsd y mountd. Son programas basados en RPC, por lo que no son arrancados desde el inetd, sino lanzados como demonios en tiempo de arranque, y registrados en el mapeador de puertos de RPC. Por lo tanto, debe asegurarse que previamente ha sido lanzado el programa rpc.portmap. Normalmente, esto implica las siguientes lineas en los scripts de arranque rc: if [ -x /usr/sbin/rpc.mountd ]; then _______________________________________________________________________________________________________________11.4. * *El fichero exports @ /usr/sbin/rpc.mountd; echo -n " mountd" fi if [ -x /usr/sbin/rpc.nfsd ]; then /usr/sbin/rpc.nfsd; echo -n " nfsd" fi La informacion de propiedad de los ficheros que un servidor NFS proporciona a sus clientes viene dada en valores numericos de identificador de usuario (uid) y de grupo (gid). Por lo tanto, esto resultarautil si clientes y servidores tienen el mismo mapa de usuarios y grupos, lo que sucede cuando dicho mapa se obtiene en todos los nodos desde un servidor NIS central. Sin embargo, hay veces que esto no sucede. En lugar de actualizar los uids y gids del cliente para ponerse de acuerdo con los del servidor, puede usarse el demonio ugidd para hacer este trabajo. Utilizando la opcion map_daemon explicada despues, se indicara a nfsd que establezca una correspondencia entre uid/gid del servidor y del cliente, con la ayuda, en el cliente, de ugidd. ugidd es un servidor basado en RPC, y se inicia tambien en los scripts rc, con una linea: if [ -x /usr/sbin/rpc.ugidd ]; then /usr/sbin/rpc.ugidd; echo -n " ugidd" fi 11.4 El fichero exports Mientras que las opciones anteriores se aplican a la configuracion del cliente NFS, hay otras opciones que se aplican al servidor, que afectan a su relacion con cada posible cliente. Estas opciones se incluyen en el fichero de sistemas exportados /etc/exports. Por defecto, mountd no permitira a nadie montar directorios de su maquina. Para permitir que algun nodo monte un directorio,este debe estar exportado, es decir, especificado en el fichero de exportacion. Un ejemplo de dicho fichero es el siguiente: # Fichero de exportacion para vlager (/etc/exports) /home vale(rw) vstout(rw) vlight(rw) /usr/X386 vale(ro) vstout(ro) vlight(ro) /usr/TeX vale(ro) vstout(ro) vlight(ro) / vale(rw,no_root_squash) /home/ftp (ro) _______________________________________________________________________________________________________________11.4. * *El fichero exports @ Cada linea define un directorio, y la lista de maquinas que pueden acceder ael por NFS. Un nombre de maquina puede especificarse con su nombre internet completo, aunque tambien se permite el uso de los comodines * y ?, que se interpretan como en el shell de Bourne. Por ejemplo, lab*.prueba.com encaja con cualquier nodo con nombre similar a laboratorio.prueba.com o lab12.prueba.com, etc. Cuando en una linea de /etc/exports no se indique el nombre del nodo, se asume que cualquier maquina podra montar el directorio (asi sucede en nuestro ejemplo con /home/ftp). mountd usa la llamada gethostbyaddr(2) para comprobar si el cliente demandante tiene un nombre de los que aparecen en /etc/exports. Con DNS, la llamada retorna el nombre canonico con lo que debe evitar usar nombres de alias en el fichero de exportacion6. Si no usa DNS, el nombre devuelto por la llamada anterior sera el primer nombre que coincida con el IP del demandante, en el fichero /etc/hosts. Tras el nombre del nodo autorizado, se puede encerrar entre parentesis un conjunto de opciones separadas por comas. Dichas opciones son: insecure Permitir acceso no autentificado desde ese nodo. unix-rpc Requerir autentificacion RPC del dominio Unix para este nodo. Se trata simplemente de que las peticiones se originen en un puerto reservado (es decir, inferior al 1024). Esta opcion esta activa por defecto. secure-rpc Requerir autentificacion RPC segura para este nodo. Aun no esta implemen- tado. Se sugiere ver la documentacion de Sun al respecto (vease, "Secure RPC"). kerberos Requerir autentificacion Kerberos. Tampoco se ha implementado aun. Se sugiere consultar la documentacion del MIT. root_squash Se trata de una opcion de seguridad que deniega acceso a nivel de superu- suario, traduciendo el identificador uid recibido (0) al del usuario nobody. Es decir, cualquier peticion NFS del usuario root sera tomada como si fuera del usuario nobody. no_root_squash Evita la restriccion anterior. Es una opcion por defecto. ro Monta la jerarquia de ficheros en modo de solo lectura. Es una opcion por defecto. rw Monta el directorio con permiso para leer y escribir enel. _____________________________________________6 Ver capitulo 6 _______________________________________________________________________________________________________________11.5. * *El sistema de automontad@ link_relative Convierte enlaces simbolicos absolutos (que empiezan con una barra de di- rectorio, "/") en enlaces relativos colocando los prefijos "../ " que sean ne- cesarios para hacer que apunten a la raiz del servidor. Esta opcion solo tiene sentido cuando se monta un sistema de ficheros completo y no solo un directorio. Asi, si montamos dicho sistema bajo /mnt y existe en /mnt/sub un enlace fichero ! /tmp/fichero se convertira a fichero ! ../tmp/fichero logrando asi que el enlace sirva para algo. Es una opcion activa por defecto. link_absolute Deja los enlaces absolutos como estaban (es la opcion habitual en servidores NFS de Sun). map_identity La opcion map_identity indica al servidor que asuma que el cliente utiliza el mismo mapa de uids y gids que el servidor. Es una opcion por defecto. map_daemon Esta opcion indica al servidor NFS que no comparte el mapa de usuarios con el del cliente. Con ello, las comparaciones de uids y gids se haran mediante una lista de mapeado entre ambos que se construira llamando al demonio ugidd del cliente. Cualquier error analizando el fichero de exportaciones durante el arranque del servidor nfsd o mountd sera enviado a nivel de notificacion (notice) al registro del sistema (syslogd ). Observese que los nombres de los nodos se obtienen a partir de las direcciones IP me- diante resolucion inversa, con lo que el sistema de resolucion debera tener una adecuada configuracion en este punto. Si utiliza BIND y la seguridad le preocupa especialmente, debera activar chequeo de nombres falsos (spoofing) en el fichero host.conf. 11.5 El sistema de automontado en Linux A veces es ineficiente mantener montados todos los volumenes NFS de uso potencial. Una al- ternativa es usar un demonio de automontado. Se trata de un demonio que automaticamente monta los volumenes cuando se necesitan y los desmonta tras un tiempo de inactividad. Ademas, sirve para poder montar los mismos ficheros de un lugar diferente. Por ejemplo, puede mantener varias copias de las utilidades de X Window y a la hora de ser necesitadas, intentar montar cada copia hasta conseguirlo. El programa de automontado para Linux se llama amd. Ha sido escrito inicialmente por Jan-Simon Pendry para luego encargarse Rick Sladkey de portarlo a Linux. La version actual es la 5.3. _______________________________________________________________________________________________________________11.5. * *El sistema de automontad@ Explicar el uso de amd excede los objetivos de este capitulo. El mejor manual se encuentra en las fuentes: un fichero texinfo con informacion muy detallada. Capitulo 12 Administracion de Taylor UUCP 12.1 Historia UUCP fue dise"nado a finales de los a"nos setenta por Mike Lesk en los laboratorios Bell de AT&T con el objetivo de crear una simple red sobre lineas de telefonos para conectarse mediante llamadas telefonicas. Dado que la mayoria de la gente que quiere tener correo electronico y noticias de Usenet en sus ordenadores personales todavia se comunican por modem, 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 "estandar" con el tiempo, no hay un UUCP que se pueda denominar el UUCP. Ha sufrido un continuo proceso de evolucion desde la primera version que fue implementada en 1976. En la actualidad hay dos especies principales que se diferencian principalmente en su soporte del hardware y en su configuracion. 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 implementacion de 1977 de Mike Lesk, David A. Novitz, y Greg Chesson. Aunque es bastante antigua, todavia se usa frecuentemente. Las implementaciones mas recientes de la Version 2 ofrecen muchas de las caracteristicas de los tipos mas nuevos de UUCP. La segunda clase de UUCP se desarrollo en 1983, y se conoce comunmente como BNU (Utilidades Basicas 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"nadieron _____________________________________________1 N. del T.: BNU son las siglas de Basic Network Utilities. 166 _______________________________________________________________________________________________________________12.1. * *Historia @ 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 mantega trafico de UUCP. La implementacion de UUCP que se distribuye con Linux es Taylor UUCP 1.04,2 que es la version en la que se basa este capitulo. La version 1.04 de Taylor UUCP esta disponible desde Febrero de 1993. Ademas de los tradicionales ficheros de configuracion, Taylor UUCP tambien se puede compilar para que use ficheros de configuracion de un nuevo estilo: el estilo "Taylor". La version 1.05 ha aparecido recientemente, y pronto se incluira en la mayoria de las distribuciones. Las diferencias entre estas versiones afectan en su mayor parte a aspectos que usted nunca usara, asi que con lo poco que contamos aqui le deberia bastar para configurar Taylor UUCP 1.05 en su sistema. Tal y como se incluye en la mayoria de las distribuciones de Linux, el Taylor UUCP viene compilado para ser compatible con BNU, con el estilo de configuracion de Taylor, o ambos. Dado que el segundo es mucho mas flexible, y probablemente mas facil de entender que los usualmente oscuros ficheros de configuracion de BNU, describire aqui el estilo Taylor. El proposito de este capitulo no es ofrecer una explicacion exhaustiva de las opciones de la linea de comando para los comandos de UUCP y lo que hacen, sino darle una intro- duccion sobre como poner en marcha un nodo de UUCP. La primera seccion presenta una introduccion de como UUCP implementa ejecucion remota y transmision de ficheros. Si usted tiene ya algunos conocimientos de UUCP, quiza desee saltarse esto y continuar con la seccion "Ficheros de configuracion de UUCP", que explica los distintos ficheros usados para configurar UUCP. Sin embargo, asumiremos que usted esta familiarizado con los programas de usuario del paquete UUCP. Estos son uucp y uux. Si no los conoce suficientemente, consulte las correspondientes paginas de manual. Aparte de los programas de usuario, uux y uucp, el paquete UUCP contiene algunos comandos mas, usados solamente para fines administrativos. Se usan para observar el trafico de UUCP en su nodo, deshacerse de viejos ficheros de registro, o crear estadisticas. No describiremos ninguna de estas utilidades, porque son perifericas a las tareas principales de UUCP. Dichas utilidades estan bien documentadas y son bastante faciles de entender. Sin embargo, hay una tercera categoria, 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. _______________________________________________________________________________________________________________12.2. * *Introduccion @ 12.1.1 Mas Informacion Sobre UUCP Aquellos que no encuentren todo lo que necesiten en este capitulo pueden leer la documen- tacion que viene con el paquete. Viene en un grupo de ficheros de texinfo que describen la configuracion usando el estilo de configuracion 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 configuracion de BNU o incluso de la Version 2 (!), existe un libro muy recomendable, "Managing UUCP and Usenet" ([OReilly89 ]). Es muyutil. Otra buena fuente de informacion sobre UUCP en Linux es el UUCP-HOWTO de Vince Skahan, que aparece regularmente en comp.os.linux.announce. Tambien 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. 12.2 Introduccion 12.2.1 Disposicion de Transferecias de UUCP y Ejecucion Remota 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 coleccion 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. $ uux -r pablo!lpr !netguide.ps Generalmente UUCP no llama al sistema remoto inmediatamente para ejecutar el tra- bajo (se puede hacer con kermit ). En lugar de esto, UUCP guarda la descripcion del trabajo temporalmente. Esto se denomina spooling.3 El arbol 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 descripcion del trabajo contendria informacion sobre el comando remoto que hay que ejecutar (lpr ), el usuario que ha iniciado la ejecucion, y otro par de _____________________________________________3 N. del T.: spooling puede traducirse por "poner en una cola". Spooling se refiere a la accion de poner varios trabajos en una cola para ser usados mas tarde. _______________________________________________________________________________________________________________12.* *2. Introduccion @ cosas. Ademas de la descripcion del trabajo, UUCP tiene que guardar el fichero de datos netguide.ps. La localizacion exacta y la nomenclatura de los ficheros de cola puede variar, dependien- do de las opciones de compilacion. 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 con- figuracion 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 conexion, 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 despues de que la conexion haya finalizado. Esto lo hace uuxqt, que tambien 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 digito, 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 opcion -q cuando se ejecuta uucp o uux. Tambien se puede prohibir la transferencia de trabajos bajo un cierto nivel a horas deter- minadas. Esto tambien se llama maximo nivel de cola permitido durante una conversacion y el valor por defecto es z. Percatese de la ambig"uedad de esta terminologia: un fichero se transfiere solo si es igual o mayor que el maximo nivel de cola. 12.2.2 El Funcionamiento Interno de uucico 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 linea de comandos, primero tiene que conectarse fisicamente. Las acciones a tomar dependen del tipo de conexion a usar - por ejemplo, cuando se usa una linea telefonica, tiene que encontrar un modem, y marcar un numero de telefono. Sobre TCP, tiene que llamar gethostbyname(3) para convertir el nombre a una direccion de red, averiguar que puerto abrir, y conectar la direccion al puerto correspondiente. Una vez que se ha establecido la conexion, hay que pasar un proceso de autorizacion. Normalmente consiste en que el sistema remoto pide un nombre de usuario y posiblemente una clave. Esto se llama el dialogo de entrada. El proceso de autorizacion se lleva a cabo mediante el usual getty/login, o - en conexiones TCP - por el propio uucico. Si la _______________________________________________________________________________________________________________12.2. * *Introduccion @ autorizacion es permitida, la parte remota de la conexion ejecuta uucico. La copia local de uucico que inicio la conexion se denomina maestro, y la copia remota se denomina esclavo. A continuacion viene la fase de negociacion4 : El maestro envia su nombre, ademas 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 maximo de ficheros de cola que hay que transferir. Si esta opcion esta activada, tiene lugar una cuenta de conversacion, o comprobacion de la secuencia de llamada. Con esta caracteristica, ambos ordenadores mantienen una cuenta de conexiones exitosas, que se comparan. Si las cuentas no son iguales, la negociacion de protocolos no tendra lugar. Esto esutil para protegerse de impostores. Finalmente los dos uucico tratan de ponerse de acuerdo en un protocolo de transferencia comun. 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 lineas de telefono precisan un protocolo "seguro" que es pesimista respecto a errores, mientras que una transmision de TCP es fiable y puede usar un protocolo mas eficiente que carece de la mayoria de las comprobaciones de errores. Una vez que las negociaciones se han completado, comienza la fase de la verdadera transmision. Ambos extremos ponen en funcionamiento el controlador del protocolo elegido. Los controladores posiblemente lleven a cabo alguna secuencia especifica del protocolo para la inicializacion. Primero el maestro envia 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 conversacion. Esto es un cambio de papeles: ahora el sistema remoto se convierte en maestro y el local en esclavo. El nuevo maestro envia ahora sus ficheros. Cuando ha terminado, ambos uucicos intercambian mensajes de terminacion, y cierran la comunicacion. No vamos a profundizar en mas detalle: para esto, dirijase a las fuentes o a cualquier buen libro sobre UUCP. Tambien existe un articulo muy antiguo en la red, escrito por David A. Novitz, que da una descripcion detallada del protocolo UUCP. La FAQ5 de Taylor UUCP tambien 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 "apreton de manos". En este contexto significa "negociacion de protocolos", fase en la que los programas uucico de cada extremo de comunicacion deciden que protocolo comun usar para enviar los ficheros. 5 N. del T.: Del ingles Frecuently Asked Questions o Lista de Preguntas Comunes. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ 12.2.3 Opciones de la linea de comandos de uucico En esta seccion de describen las opciones mas importantes de la linea de comandos del pro- grama uucico. Para obtener una lista completa, consulte la pagina del manual de uucico(1). -s sistema Llamar al mencionado sistema si no esta prohibido por restriccion de la hora de llamada. -S sistema Llamar al sistema incondicionalmente. -r1 Comenzar uucico en modo master. Este es el valor por defecto cuando se usa -s o -S. Por si sola, la opcion -r1 hace que uucico intente llamar todos los sistemas en sys, a no ser que este prohibido por la hora de llamada o el numero permitido de reintentos. -r0 Comenzar uucico en modo esclavo. Este es el valor por defecto cuando no se usan -s ni -S. En modo esclavo, las entrada y salida estandar se suponen conectadas a un puerto serie, o al puerto de TCP especificado por la opcion -p si se usaesta. -x tipo , -X tipo Activar la informacion para resolver problemas del tipo especificado. Se pue- den especificar varios tipos en una lista separada por comas. Los siguientes son tipos validos: abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming y outgoing. Usando all, todas las opciones se ac- tivan. Por razones de compatibilidad con otras implementaciones de UUCP, se puede especificar un numero en vez del tipo, lo cual activa las n primeras opciones de la anterior lista. Los mensajes generados se registran en el fichero Debug bajo /var/spool/uucp. 12.3 Ficheros de configuracion de UUCP Al contrario que programas de transferencia de ficheros mas simples, UUCP fue dise"nado para ser capaz de llevar a cabo todas las tranferencias automaticamente. Una vez que esta correctamente configurado, no es necesaria una constante participacion del administra- dor. La informacion necesaria para esto se guarda en un par de ficheros de configuracion que residen en el directorio /usr/lib/uucp. La mayoria de estos ficheros se usan solo para conectarse a otro ordenador. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ 12.3.1 Una Ligera Introduccion a Taylor UUCP Decir que la configuracion de UUCP es dificil seria una descripcion insuficiente. Es cierto que es un asunto peliagudo, y el formato a veces demasiado conciso de los ficheros de configuracion no hace las cosas mas faciles (aunque el formato de Taylor es casi facil de leer comparado con los formatos mas antiguos en HDB o Version 2). Para darle una idea de como se interactua con estos ficheros, le introduciremos los mas importantes, y echaremos un vistazo a algunos ejemplos. No explicaremos ahora todo en detalle; una explicacion mas precisa se describe en secciones posteriores. Si quiere confi- gurar su ordenador para UUCP, puede comenzar con los ficheros de ejemplo, y adaptarlos gradualmente. Puede elegir los que se muestran a continuacion, o los que se incluyen en su distribucion de Linux preferida. Todos los ficheros descritos en esta seccion se guardan en /usr/lib/uucp o un subdirecto- rio deeste. Algunas distribuciones de Linux contienen programas de UUCP que tienen so- porte para ambos ficheros de HDB y Taylor, y usan diferentes subdirectorios para cada grupo de ficheros de configuracion. 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 numeros de telefono, y por lo tanto deberian tener permisos de 600. 6 El fichero central de configuracion es /usr/lib/uucp/config, y se usa para establecer los parametros generales. El mas importante de ellos (y por ahora, elunico), es el nombre de su ordenador anfitrion de UUCP. En la Cervecera Virtual, se usa vstout como su ordenador de conexion a UUCP. # /usr/lib/uucp/config - Fichero principal de configuracion de UUCP hostname vstout El siguiente fichero de configuracion en importancia es el fichero sys. Este contiene toda la informacion especifica al sistema de los ordenadores con los que usted se conecta. Esto incluye el nombre del ordenador, e informacion sobre la propia conexion, tal como el numero de telefono cuando se usa una conexion por modem. Un ejemplo tipico para un ordenador llamado pablo que se conecta por modem seria: # /usr/lib/uucp/sys - Vecinos UUCP # system: pablo _____________________________________________6 Aunque la mayoria 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. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ system pablo time Any phone 123-456 port serial1 speed 38400 chat ogin: neruda ssword: lorca 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 dialogo 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 valida en port. El fichero port contiene informacion especifica a la propia conexion. Para conexiones por modem, describe el fichero de dispositivo a usar, el conjunto de velocidades soportadas, y el tipo de equipo de marcacion conectado al puerto. La entrada a continuacion describe /dev/cua1 (o sea, el puerto COM 2), en el cual hay un modem 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. # /usr/lib/uucp/port - puertos de UUCP # /dev/cua1 (COM2) port serial1 type modem device /dev/cua1 speed 38400 dialer nakwell La informacion que afecta al propio marcador se mantiene en otro fichero, llamado dial. Para cada tipo de marcador, contiene basicamente la secuencia de comandos necesarios para llamar a otro ordenador, dado el numero de telefono. Una vez mas, esto se especifica como una macro de dialogo. Por ejemplo, la entrada para el anterior NakWell puede parecerse a esta: # /usr/lib/uucp/dial - informacion por marcador. # NakWell modems dialer nakwell chat "" ATZ OK ATDT\T CONNECT La linea que empieza con chat especifica el dialogo del modem, que no es sino la secuencia de comandos enviados y recibidos del modem para inicializarlo, y para hacerle marcar el _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ Fichero sys Fichero port system pablo port serial1 speed 38400 port serial1 ... typespeed modem38400 device /dev/cua1 dialer nakwell ... dialer nakwell chat ATZ .. chat-fail BUSY ... Fichero dial Figura 12.1: Interacciones de los Ficheros de Configuracion de Taylor UUCP. numero deseado. La secuencia "\T " sera reemplazada con el numero de telefono por el programa uucico. Para darle una idea a grandes rasgos de como uucico utiliza estos ficheros de configura- cion, suponga que utiliza el comando $ uucico -s pablo en la linea 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 deberia usar el puerto serial1 para establecer la conexion. El fichero port le dice que ese puerto es un puerto de modem, y que tiene un modem NakWell conectado. uucico busca ahora en dial la entrada que describe el modem NakWell, y al encontrar una, abre el puerto serie /dev/cua1 y ejecuta el dialogo de marcacion. Esto es, envia "ATZ", espera a que el modem responda con "OK", etc. Cuando se encuentre los caracteres "\T ", sustituye el numero de telefono (123-456) obtenido del fichero sys. Cuando el modem devuelve CONNECT, la conexion se ha establecido, y el dialogo de marcacion se ha completado. uucico ahora vuelve al fichero sys y ejecuta el dialogo de entrada. En nuestro ejemplo, esperaria la pregunta "login:", enviaria su nombre de usuario _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ (neruda), esperaria la pregunta "password:", y enviaria la clave, "lorca". Tras completar la autorizacion, se suponde que el sistema remoto ejecuta su propio uucico. Los dos entraran entonces en la fase de negociacion de protocolos descrita en la seccion anterior. La relacion de dependencia de los ficheros de configuracion se puede ver en la figura 12.1. 12.3.2 Lo que UUCP necesita saber Antes de empezar a escribir los ficheros de configuracion, debe conseguir cierta informacion que UUCP necesita. Primero tiene que saber en que dispositivo serie esta su modem. Normalmente, los puertos (de DOS) COM1 hasta COM4 se corresponden con los ficheros de dispositivos /dev/cua0 hasta /dev/cua3. La mayoria de las distribuciones, como Slackware, crean un enlace simbolico /dev/modem al fichero de dispositivo donde esta el modem, y configuran kermit, seyon, etc, para que usen este fichero. En este caso, usted tambien deberia usar usar /dev/modem en la configuracion de UUCP. La razon para esto es que todos los programas, para llamar por telefono, usan unos ficheros cerrojo para indicar cuando un puerto serie esta en uso. Los nombres de estos fi- cheros cerrojo son una concatenacion del texto LCK.. y el nombre del fichero de dispositivo, por ejemplo, LCK..cua1. Si los programas usasen nombres diferentes para un mismo dispo- sitivo, no podrian reconocer los ficheros cerrojo de los otros programas. En consecuencia, perturbarian la sesion de conexion 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 capitulo 4. A continuacion tiene que averiguar a que velocidad se comunicaran su modem y Linux. Tendra que ajustar este valor a la velocidad de transferencia efectiva maxima que espere obtener. La velocidad efectiva puede ser mucho mayor que la velocidad fisica de tranferencia de su modem. Por ejemplo, muchos modems envian y reciben datos a 2400bps (bits por segundo). Usando protocolos de compresion como V.42bis, la velocidad real de transferencia puede alcanzar los 9600bps. Por supuesto, si quiere que UUCP sirva de algo, necesitara el numero de telefono al que llamar. Tambien necesitara un nombre de usuario valido y probablemente una clave en el sistema remoto.7 _____________________________________________7 Si solo quiere probar UUCP, obtenga el numero de un sistema cercano a usted. Apunte el nombre de usuario y la clave - son publicos para permitir posibles transferencias anonimas. En la mayoria de los casos, son algo como uucp/uucp o nuucp/uucp. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ Tambien 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 dialogo, que es un script que le dice a uucico como entrar. Si no lo sabe, o si la macro de dialogo normal no funciona, intente llamar al sistema con un programa como kermit o minicom, y apunte exactamente lo que tiene que hacer. 12.3.3 Nomenclatura de nodos 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 conexion a correo y noticias, se deberia pensar en registrar el nombre con el proyecto de Mapa de UUCP, que se describe en el capitulo 13. Incluso si usted participa en un dominio, podria 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 direccion de su dominio es swim.twobirds.com, entonces su nombre de UUCP podria ser swim. Piense en los nodos de UUCP como si se conociesen entre ellos por el nombre propio. Por supuesto, tambien puede usar un nombre de UUCP completamente desvinculado de su nombre de dominio, y por consiguiente, un nombre no cualificado. Sin embargo, asegurese 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 algun agujero negro digital. Si utiliza un nombre que alguien ya esta usando, este correo sera dirigido a ese sitio, y le causara al administrador del correo un sinfin 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 opcion hostname en el fichero config para indicar a uucico su nombre de UUCP. Esto se describe a continuacion. _____________________________________________8 La unica limitacion 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 unicos. Para registrar su nombre de UUCP, preguntele a los responsables del nodo que gestiona su correo; ellos podran ayudarle. _______________________________________________________________________________________________________________12.3. * * Ficheros de configuracio@ 12.3.4 Ficheros de configuracion Taylor Volvemos ahora a los ficheros de configuracion. Taylor UUCP obtiene su informacion de los siguientes ficheros: config Este es el fichero principal de configuracion. Aqui 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 numero marcar, que tipo de dispositivo usar, y como entrar. port Contiene entradas que describen cada puerto disponible, junto con la velo- cidad de linea soportada y las instrucciones de marcacion. dial Describe las instrucciones de marcacion usados para establecer una conexion telefonica. dialcode Contiene expansiones simbolicas para codigos de marcacion. 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 comprobacion de claves. Los ficheros de configuracion de Taylor se componen generalmente de lineas que contie- nen pares palabra - valor. Una almohadilla (#) indica un comentario que ocupa toda una linea. 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 configuracion. No podemos repasar todos los parametros, sino que cubriremos solo los mas importantes. Con estos usted podra configurar una conexion de UUCP por modem. Otras secciones descri- biran las modificaciones necesarias si quiere usar UUCP en TCP/IP o sobre una linea serie. Junto con el codigo 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 compro- barlo usando la utilidad uuchk (que se encuentra en /usr/lib/uucp). uuchk lee sus ficheros de configuracion, e imprime un informe detallado de los valores de configuracion usados para cada sistema. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ 12.3.5 Opciones Generales de Configuracion - el Fichero config 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 general- mente es una buena idea configurar el nombre de UUCP explicitamente. A continuacion mostramos un fichero de ejemplo: # /usr/lib/uucp/config - fichero principal de configuracion de UUCP hostname vstout Por supuesto, tambien existen otros parametros configurables aqui, como los referentes al nombre del directorio de colas, o los derechos de acceso para el UUCP anonimo. Esto ultimo se describira en una seccion posterior. 12.3.6 Como informar a UUCP sobre otros sistemas - el fichero sys El fichero sys describe los sistemas que su ordenador conoce. Una entrada comienza con la palabra system; las lineas siguientes hasta la siguiente system proporcionan detalles sobre los parametros especificos sobre ese sistema o nodo. Comunmente, una entrada de un sistema definira parametros tales como el numero de telefono y el dialogo de entrada. Los parametros antes de la primera linea con system determinan los valores por defecto usados para todos los sistemas. Lo normal es que los parametros de protocolos y similares se incluyan en la seccion por defecto. A continuacion se tratan los campos mas importantes con cierto detalle. Nombre del sistema El comando system especifica el nombre del sistema remoto. Tiene que especificar el nombre correcto del sistema remoto, no un alias que usted se invente, porque uucico lo verificara con la informacion que reciba del otro sistema una vez se conecte.10 Cada nombre de sistema puede aparecer una sola vez. Si quiere usar varias configuracio- nes para un mismo sistema (por ejemplo, numeros de telefono diferentes que uucico puede usar alternativamente), puede especificar alternavias, que se describen mas adelante. _____________________________________________10 Algunas de las versiones 2 de UUCP antiguas no envian su nombre cuando son llamadas; sin embargo, las implementaciones mas recientes si lo hacen, y Taylor UUCP tambien. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ Numero de telefono Si para conectar con el sistema remoto hace falta una linea de telefono, el campo phone especifica el numero que tiene que marcar el modem. Puede incluir varios separadores que son interpretados por el proceso de marcacion efectuado por uucico. Un signo igual (=) significa esperar un tono secundario, y un guion genera una pausa de un segundo. Por ejemplo, algunas instalaciones de telefono se atascan si no deja una pausa entre un prefijo de una compa"nia y el numero de telefono. Cualquier lista de caracteres se puede usar para esconder informacion que depende de cada nodo, como el prefijo de provincia. Estos caracteres se traducen en un codigo de marcacion usando el fichero dialcode. Suponga que tiene el siguiente fichero dialcode: # /usr/lib/uucp/dialcode - traduccion de codigos de marcacion Bogoham 024881 Coxton 035119 Con estas traducciones, se puede usar un numero de telefono como Bogoham7732 en el fichero sys, lo cual hace las cosas un poco mas legibles. Puerto y Velocidad Las opciones port y speed se usan para elegir el dispositivo usado para llamar al sistema remoto, y la velocidad maxima del dispositivo.11 Una entrada system puede usar cualquiera de las dos opciones solas, o ambas. Cuando se busca un dispositivo apropiado en el fichero port, solo se eligen aquellos puertos cuyo nombre y/o velocidad coinciden. Normalmente es suficiente con usar la opcion speed. Si solo tiene un dispositivo serie definido en port, uucico, de cualquier modo, siempre escogera el correcto, asi que solo tiene que especificar la velocidad deseada. Si tiene varios modems 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. El dialogo de entrada Antes ya nos encontramos con la macro del dialogo de entrada, que le dice a uucico como entrar en el sistema remoto. Consiste de una lista de palabras clave, que especifican el _____________________________________________11 La velocidad en baudios del terminal (tty) tiene que ser por lo menos igual o mayor que la velocidad maxima de transmision. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ texto que se espera y el que se envia por el proceso local de uucico. El objetivo es hacer que uucico espere hasta que la maquina remota envie una linea pidiendo el nombre de usuario, y entonces enviar el nombre de usuario, luego esperar a que pida la palabre clave, y enviar dicha clave. Los textos de espera y de envio se dan alternativamente. uucico automaticamente a"nade un avance de linea (\r ) a cualquier texto enviado. Por lo tanto, una macro de dialogo sencilla seria parecida a esta: ogin: vstout ssword: catch22 Dese cuenta de que los campos de texto de espera (ogin: y ssword:) no contienen el texto completo. Esto es asi para asegurarse de que el proceso de entrada se lleve a cabo aunque el sistema remoto nos envie Login: en vez de login:. uucico tambien 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 razon, usted puede a"nadir un sub-dialogo a un texto de espera, separado con un guion. El sub-dialogo se ejecuta solo si el primer texto de espera falla, ej. si expira un temporizador (timeout). Una manera de usar esta caracteristica es enviar un BREAK si el sistema remoto no envia una pregunta de nombre de usuario. El siguiente ejemplo muestra un ejemplo de una macro de dialogo que deberia funcionar tambien en el caso de que usted tenga que pulsar return antes de que aparezca la pregunta de entrada. "" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22 Hay un par de tiras de caracteres especiales y caracteres de escape que pueden aparecer en la macro de dialogo. Esta es una lista incompleta de caracteres legales en la pregunta de espera: "" La tira vacia. Le dice a uucico que no espere nada, sino que siga con la siguiente tira de enviado immediatamente. \t Un caracter de tabulador. \r Un caracter de retorno de linea. \s El caracter de espacio. Lo necesitamos para incluir espacios en un dialogo. \n Caracter de nueva linea. \\ Caracter de barra invertida. En tiras de caracteres de envio se pueden incluir, ademas de los mencionados anteriormente, los siguientes caracteres: _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ EOT Caracter de fin de la trasmision (^D). BREAK Caracter Break. \c Suprime el envio del caracter nueva linea al final de cada tira de caracteres. \d Retrasar el envio 1 segundo. \E Activar la comprobacion de eco. De esta forma, uucico esperara a leer el eco de todo lo que escribe en el dispositivo antes de que continue con el dialogo. Se usa principalmente en dialogos de modems (que veremos mas adelante). La comprobacion de eco esta desactivada por defecto. \e Desactivar la comprobacion de eco. \K Lo mismo que BREAK. \p Pausa de una fraccion de un segundo. Alternativas A veces es deseable tener multiples entradas para un mismo sistema, por ejemplo si se puede acceder al sistema en diferentes lineas de modem. Con Taylor UUCP se puede hacer esto definiendo una alternativa. Una entrada alternativa mantiene todas las caracteristicas de la entrada principal, y especifica solamente aquellos valores que tienen que ser cambiados, o a"nadidos. Una al- ternativa esta separada de la entrada principal por una linea que contiene la palabre clave alternate. Para usar dos numeros de telefono para pablo, habria que modificar su entrada sys de la siguiente manera: system pablo phone 123-456 ... lo mismo que antes ... alternate phone 123-455 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 informacion de la entrada de sistema principal, y altera solo el numero de telefono. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ Restringir horas de llamada Taylor UUCP proporciona varios metodos para restringir las horas a las que se pueden efectuar llamadas a un sistema remoto. Una razon 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 opcion -S o -f en el programa uucico. Por defecto, Taylor UUCP no permite conexiones a ninguna hora, asi que usted tiene que especificar algun horario en el fichero sys. Si no le importan las restricciones, puede especificar la opcion 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, dia y hora. El dia puede ser cualquiera de los siguientes: Mo, Tu, We, Th, Fr, Sa, Su (que corresponden a Lunes, Martes, Miercoles, Jueves, Viernes, Sabado y Domingo, respectivamente) combinados, Any (cualquiera), Never (nunca), o Wk para los dias laborables. La hora consiste en dos numeros de un reloj de 24 horas, separados por un guion. Especifican el grupo de horas durante las que se pueden efectuar llamadas. La combinacion de los simbolos se escribe sin ningun espacio en blanco entre ellos. Se pueden especificar varios grupos de dia-hora separados por comas. Por ejemplo, time MoWe0300-0730,Fr1805-2000 permite llamadas en Lunes y Miercoles, de 3 de la ma"nana 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"nana, 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 conexion falla, uucico no permitira otro intento de llamar al ordenador remoto hasta que transcurra un cierto tiempo. Por defecto, uucico usa un algoritmo de espera exponencial, segun 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 despues del ultimo intento fallido. El comando timegrade le permite a"nadir un rango maximo de cola a un calendario. Por ejemplo, asumiendo que usted tiene los siguientes comandos timegrade en una entrada system: _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ timegrade N Wk1900-0700,SaSu timegrade C Any Esto permite que los trabajos con rango de cola de C o mayor (normalmente el correo se pone en la cola con rango B o C) sean transferidos siempre que se establece una comuni- cacion, mientras que las noticias (news) (normalmente con rango N) seran 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 observacion: la opcion timegrade solo se aplica a lo que su sistema envia; el sistema remoto puede transferir todo lo que le plazca. Usted puede usar la opcion call-timegrade para forzar explicitamente que envie solamente trabajos sobre cierto rango de cola; pero no hay ninguna garantia de que obedecera esta peticion.12 Igualmente, el campo timegrade no se comprueba cuando un sistema remoto hace una llamada aeste, de manera que cualquier trabajo puesto en la cola para el sistema que llama al nuestro sera enviado. Sin embargo, el sistema remoto puede pedir explicitamente a nuestro uucico que se mantenga a si mismo en un cierto rango de cola. 12.3.7 Que dispositivos hay - el fichero port El fichero port indica a uucico que puertos tiene disponibles. Pueden ser puertos de modem, pero cualquier otro tipo, como lineas serie directas o sockets de TCP tambien 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 serunico; 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 modem, 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 sera modem. En esta seccion solo hablaremos de puertos de modem; los puertos de TCP y las lineas directas seran tratados en una seccion posterior. _____________________________________________12 Si el sistema remoto esta ejecutando Taylor UUCP, obedecera. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ Para puertos directos y de modem, 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 modem, la directiva port tambien determina que tipo de modem esta conectado al puerto. Cada tipo de modem tiene que configurarse de manera diferente. Incluso los modems 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 modem y como hacer que marque el numero deseado. Taylor UUCP mantiene las descripciones de todos los marcadores en un fichero llamado dial. Para usar cualquiera deestos, tiene que especificar el nombre del marcador usando el comando dialer. Es posible que usted quiera usar el modem de maneras diferentes, dependiendo del sistema al que esta llamando. Por ejemplo, algunos modems antiguos no entienden cuando un modem rapido trata de conectar a 14400bps; simplemente desconectan la linea en vez de negociar la conexion a 9600bps por ejemplo. Si sabe que el ordenador plasta usa un modem tan tonto, usted tiene que configurar su modem 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 situacion anterior pueden ser asi: # NakWell modem; conexion a velocidad alta. port serial1 # nombre del puerto type modem # puerto modem device /dev/cua1 # esto es COM2 speed 38400 # velocidad soportada dialer nakwell # marcador normal # NakWell modem; conexion lenta port serial1 # nombre del puerto type modem # puerto modem device /dev/cua1 # esto es COM2 speed 9600 # velocidad soportada dialer nakwell-slow # no intentar alta velocidad La entrada de sistema para el ordenador plasta usaria ahora serial1 como el nombre del puerto, pero pediria usar la velocidad de 9600bps solamente. uucico usara automaticamente _____________________________________________13 Hay quien usa los dispositivos ttyS*, que son solamente para aceptar llamadas. _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ la segunda entrada de port. Todos los otros ordenadores con velocidad de 38400bps en la entrada de sistema seran llamados usando la primera entrada de port. 12.3.8 Como marcar un numero - el fichero dial El fichero dial describe como se usan los distintos marcadores. Tradicionalmente, UUCP habla de "marcadores" en vez de modems, porque en los viejos tiempos era normal que un dispositivo de marcacion automatico (que era caro) sirviese un banco entero de modems. Hoy, la mayoria de los modems tienen soporte para marcar incluido, asi que la distincion tiende a desaparecer. De cualquier modo, cada marcador o modem puede necesitar una configuracion 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 deesta, es el dialogo del modem, especificado por el comando chat. Similar al dialogo de entrada (login), consta de una secuencia de caracteres que uucico envia al marcador y de la secuencia que espera recibir como respuesta. Se usa normalmente para reiniciar el modem a un estado conocido, y marcar el numero. El siguiente ejemplo de una entrada de un marcador muestra un dialogo tipico para un modem compatible con Hayes: # NakWell modem; conexion a alta velocidad dialer nakwell # nombre del marcador chat "" ATZ OK\r ATH1E0Q0 OK\r ATDT\T CONNECT chat-fail BUSY chat-fail ERROR chat-fail NO\sCARRIER dtr-toggle true El dialogo del modem comienza con "", es decir, que espera una cadena vacia. uucico entonces envia el primer comando (ATZ) de inmediato. ATZ es el comando de Hayes para reiniciar el modem. Entonces espera hasta que el modem envie OK, y a continuacion envia el siguiente comando que desactiva el eco local, y cosas parecidas. Despues de que el modem envie OK otra vez, uucico envia el comando de marcacion (ATDT). La secuencia de escape \T en esta cadena es reemplazada con el numero de telefono obtenido de la entrada de sistema en el fichero sys. uucico espera a que el modem devuelva la cadena CONNECT, que indica que se ha establecido una conexion exitosa con el modem remoto. A menudo el modem no puede conectarse con el sistema remoto, por ejemplo si el otro sistema esta conectado con otro ordenador y la linea esta ocupada. En este caso, el modem devuelve algun mensaje de error indicando la razon. Los dialogos de modem _______________________________________________________________________________________________________________12.3. * *Ficheros de configuracio@ no pueden detectar estos mensajes; uucico seguira esperando la cadena esperada hasta que un temporizador se agote. El fichero de recopilacion de informacion (log) de UUCP mostrara solamente el mensaje "timed out in chat script" (tiempo agotado en la macro de dialogo) en vez de la razon 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 dialogo mientras lo ejecuta, interrumpe la llamada y anota el error en el fichero log de UUCP. Elultimo comando en el ejemplo anterior indica a UUCP que cambie la linea DTR antes de empezar el dialogo de modem. La mayoria de los modems se pueden configurar para conectarse cuando detectan un cambio en la linea DTR, y entrar en modo de comando.14 12.3.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, segun el cual los articulos se piden y se transmiten individualmente, sin compresion ni ninguna otra optimizacion. Aunque es una tecnica adecuada para ordenadores grandes con varias fuentes de grupos de noticias simultaneas, esta tecnica no es favorable para peque"nos sistemas que reciben los grupos a traves de una conexion lenta, como RDSI. Estos ordenadores normalmente desean combinar las cualidades de TCP con las ventajas de enviar articulos en grandes lotes, que se pueden comprimir y por lo tanto transferir con muy poco gasto. Un metodo estandar 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: system gmu address news.groucho.edu time Any port tcp-conn chat ogin: vstout word: clouseau El comando address da la direccion de internet (IP) del ordenador, o su nombre de dominio completo (FQDN). La entrada correspondiente en el fichero port seria asi: _____________________________________________14 Tambien se pueden configurar algunos modems para que se reinicien a si mismos cuando detecten una transicion en DTR. Sin embargo, a algunos modems no parece gustarles esto y en ocasiones se bloquean. _______________________________________________________________________________________________________________12.4. * *Los sies y noes de UUCP @ port tcp-conn type tcp service 540 Esta entrada indica que hay que usar una conexion de TCP cuando una entrada en el fichero sys hace referencia a tcp-conn, y que el programa uucico debera tratar de conectarse al puerto TCP 540 en el sistema remoto. Este es el puerto por defecto del servicio UUCP. En vez del numero de puerto, tambien se puede especificar un nombre de puerto simbolico. El numero de puerto correspondiente sera buscado en el fichero /etc/services. 12.3.10 Uso de una conexion directa Supongamos que usted usa una linea directa que conecta su sistema vstout con el ordenador tiny. Al igual que en el caso del modem, tiene que escribir una entrada de sistema en el fichero sys. El comando port identifica el puerto serie en el que tiny esta conectado. 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 conexion directa. La entrada dialer no hace falta porque no hay que marcar ningun numero. port direct1 type direct speed 38400 12.4 Los sies y noes de UUCP - Ajuste de Permisos 12.4.1 Ejecucion de comandos La tarea de UUCP es copiar ficheros de un sistema a otro, y pedir la ejecucion de ciertos comandos en sistemas remotos. Por supuesto, usted como administrador querra 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 unicos comandos que Taylor UUCP permite a otros sistemas ejecutar en su or- denador son rmail y rnews, que se usan comunmente para intercambiar correo y noticias _______________________________________________________________________________________________________________12.4. * *Los sies y noes de UUCP @ de Usenet sobre UUCP. El directorio en el que uuxqt busca es una opcion 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 busqueda se puede cambiar con el comando command-path. Por ejemplo, usted puede querer dar acceso al sistema pablo para que ejecute el comando rsmtp ademas de mail y rnews:15 system pablo ... commands rmail rnews rsmtp 12.4.2 Transferencias de Ficheros Taylor UUCP tambien le permite ajustar, en gran medida, las tranferencias 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 sera 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. Ademas, 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 asi se permite a los usuarios locales que envien ficheros de sus directorios. Comunmente, 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 publicamente; muy parecido a un servidor de FTP en Internet. Normalmente se refiere a este directorio con el caracter tilde. Por lo tanto, Taylor UUCP provee cuatro comandos diferentes para configurar los direc- torios 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 envie 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: system pablo ... local-send /home ~ _____________________________________________15 El programa rsmtp se usa para manejar el correo con SMTP por lotes. Esto se explica en los capitulos sobre correo. _______________________________________________________________________________________________________________12.4. * *Los sies y noes de UUCP @ local-receive /home ~/recibir remote-send ~ !~/entrada !~/recibir remote-receive ~/entrada El comando local-send permite a los usuarios de su sistema que envien 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 exclamacion delante de los nombres de los directorios. Finalmente, laultima linea 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 desactivacion total de la transferencia de ficheros por UUCP. 12.4.3 Reenvio 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 envie a su sistema. El siguiente comando haria esto: $ uucp -r seci!uchile!~/find-ls.gz ~/uchile.files.gz Esta tecnica de pasar un trabajo a traves de varios sistemas se llama forwarding (reenvio). En el ejemplo anterior, la razon para usar el reenvio puede ser que seci tie- ne 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 reenvio a unos pocos sistemas en que usted confia, para que no se le acumule una factura telefonica horrenda cuando alguien use su sistema para obtener laultima version de X11R6. Por defecto, Taylor UUCP no permite el reenvio. 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 reenvie trabajos. Por ejemplo, el administrador de UUCP del sistema seci tendria que a"nadir las siguientes lineas al fichero sys para permitir que pablo obtenga ficheros de uchile: #################### _______________________________________________________________________________________________________________12.5. * * Configuracion de su sist@ # pablo system pablo ... forward uchile #################### # uchile system uchile ... forward-to pablo 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 desharia del fichero. Esta entrada usa una variacion del comando forward que permite que uchile solo envie ficheros a pablo a traves de seci, no al reves. Para permitir el reenvio a cualquier sistema, use el comando especial ANY (tiene que estar en mayusculas). 12.5 Configuracion de su sistema para ser llamado. Si quiere configurar su sistema para que otros se conecten aeste llamandole, 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 seccion. 12.5.1 Configuracion de getty Si quiere usar una linea serie como un puerto de entrada, tiene que activar un proceso getty en ese puerto. Sin embargo, algunas implementaciones de getty no son validas 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 linea con otros programas como uucico, o minicom. Un programa que se comporta asi es uugetty del paquete getty_ps. La mayoria de las distribuciones de Linux lo tienen; busque uugetty en el directorio /sbin. Otro programa que existe es mgetty, de Gert Doering, que ademas hace recepcion de facsimiles. Tambien puede obtener laultima version de estos programas en sunsite.unc.edu, tanto en binario como en codigo fuente. La explicacion de las diferencias de como uugetty y mgetty manejan la entrada al sistema esta mas alla del alcance de esta peque"na seccion; para mas informacion, vea el HOWTO Serial de Greg Hankins16 , asi como la documentacion que viene con getty_ps y mgetty. _____________________________________________16 Tambien disponible en Castellano (Serial-COMO), en LuCAS _______________________________________________________________________________________________________________12.5. * *Configuracion de su sist@ 12.5.2 Proveer Cuentas de UUCP A continuacion tiene que configurar las cuentas de usuarios que permiten a sistemas re- motos entrar en su sistema y establecer una conexion de UUCP. Generalmente tendra 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 traves del puerto serie, usualmente tiene que a"nadir 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 raiz 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 : # useradd -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucico Upablo Si no utiliza la aplicacion de claves ocultas, probablemente tendra que editar /etc/passwd a mano, a"nadiendo una linea como la siguiente, donde 5000 y 150 son el numero de iden- tificacion de usuario (uid) y el numero de grupo asignado al usuario Upablo y al grupo uuguest, respectivamente. Upablo:*:5000:150:Cuenta de UUCP:/var/spool/uucppublic:/usr/lib/uucp/uucico Una vez creada la cuenta, tiene que activarla asignandole 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"nadiendo la siguiente linea al fichero /etc/inetd.conf :17 uucp stream tcp nowait root /usr/sbin/tcpd /usr/lib/uucp/uucico -l La opcion -l hace que uucico haga su propia autorizacion de entrada. Pedira un nom- bre de usuario y una clave, igual que el programa estandar 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: _____________________________________________17 Normalmente, tcpd tiene modo 700, asi que tiene que invocarlo como usuario root, no como usuario uucp, como haria normalmente. _______________________________________________________________________________________________________________12.5. * *Configuracion de su sist@ Upablo IslaNegra Ulorca cordoba Por supuesto, este fichero tiene que pertenecer al usuario uucp y tener permiso 600. Si esta base de datos parece una idea tan buena que le gustaria usarla en verificacion normal de entrada (login) por serie tambien, 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 opcion -u.18 Luego tiene que enga"nar 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 opcion LOGIN en el fichero de configuracion. Sin embargo, esto desactiva los logins interactivos por completo. mgetty, por otro lado, tiene una caracteristica atractiva que le permite invocar diferentes comandos de entrada (login) segun el nombre de usuario suministrado. Por ejemplo, puede decirle a mgetty que use uucico para todos los usuarios cuyo nombre de usuario comienze con una U mayuscula, pero dejar que todos los demas usen el comando estandar 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"nadir comandos called-login a cada entrada de sistema en el fichero sys. Esto se describe en la seccion siguiente. 12.5.3 Proteccion contra estafadores 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 despues de entrar, pero el servidor no tiene manera de comprobarlo. Por consiguiente, un atacante podria 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 anonimo, 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 podria ser asi: system pablo ... opciones usuales ... called-login Upablo _____________________________________________18 La opcion -u tambien existe en 1.04, pero no hace nada. _______________________________________________________________________________________________________________12.5. * *Configuracion de su sist@ La ventaja de este metodo es que cuando un sistema entra y pretende ser pablo, el programa uucico comprobara que haya entrado como usuario Upablo. Si no es asi, el sistema que nos llama sera desconectado. Deberia acostumbrarse a incluir el comando called-login en todas las entradas de sistema que a"nada 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 mombre ficticio, como nuncallama. 12.5.4 Vuelvase Loco - Comprobacion de Secuencia de Llamadas Otra manera de defenderse de impostores es usando la comprobacion de secuencia de lla- madas. La comprobacion 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 comprobacion de secuencia de llamadas, ambas maquinas mantienen una cuenta del numero de conexiones establecidas hasta el momento. Se incrementa con cada conexion. Despues de entrar, el llamador envia su numero de secuencia de llamadas y el sistema llamado lo comprueba con su propio numero. Si no son iguales, el intento de conexion es rechazado. Si el numero inicial se elige aleatoriamente, los atacantes lo tendran mas dificil para adivinar el numero de secuencia de llamadas correcto. Pero la comprobacion de la secuencia de llamada sirve para mas que esto: aunque una persona muy inteligente descubriese su numero de secuencia de llamada asi como su clave, usted sabra 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 numero 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 numeros de secuencia ya no son iguales. Si usted activa la comprobacion de secuencia de llamadas, deberia comprobar los fiche- ros historicos regularmente para buscar mensajes de error que puedan significar posibles ataques. Si su sistema rechaza el numero de secuencia de llamada que el sistema remoto le ofrece, uucico pondra un mensaje en el fichero historico que dira algo como "Out of sequen- ce call rejected" ("Llamada fuera de secuencia rechazada"). Si su sistema es rechazado por el proveedor de correo porque los numero de secuencia no estan sincronizados, pondra un mensaje en el fichero historico que dice "Handshake failed (RBADSEQ)" ("Negociacion fallida (RBADSEQ)" ). Para activar la comprobacion del numero de secuencia, tiene que a"nadir el siguiente comando en la entrada de sistema: # activar comprobacion de numero de secuencia sequence true _______________________________________________________________________________________________________________12.5. * *Configuracion de su sist@ Aparte de esto, tiene que crear el fichero que contiene el numero de secuencia. Taylor UUCP mantiene el numero 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 podria apa"narselas para adivinar el numero probando todos los valores menores que, digamos, 60. # cd /var/spool/uucp/pablo # echo 94316 > .Sequence # chmod 600 .Sequence # chown uucp.uucp .Sequence Por supuesto, el sistema remoto tambien tiene que activar la comprobacion del numero de secuencia, y empezar usando el mismo numero que usted. 12.5.5 UUCP Anonimo Si quiere ofrecer aceso anonimo de UUCP a su sistema, primero tiene que establecer una cuenta especial como se describio anteriormente. Es practica comun darle a esta cuenta el nombre y la clave uucp. Ademas, tiene que especificar algunas opciones de seguridad para sistemas desconocidos. Por ejemplo, usted podria querer prohibirles que ejecuten comandos en su sistema. Sin embargo, estos parametros 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: unknown remote-receive ~/incoming unknown remote-send ~/pub unknown max-remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown commands rmail 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 linea ha- ce que uucico ignore cualquier peticion del sistema remoto de activar la comprobacion de errores (debugging) localmente. Las dosultimas lineas permiten que los sistemas descono- cidos ejecuten rmail ; pero el camino de busqueda de comandos especificado hace que uucico _______________________________________________________________________________________________________________12.6. * *Protocolos de bajo nivel@ busque el comando rmail solamente en un directorio privado llamado anon-bin. Esto le permite a usted suminitrar algun programa rmail especial que, por ejemplo, reenvie todo el correo al superusuario para examinarlo. Esto permite a los usuarios anonimos contactar con el administrador del sistema, pero al mismo tiempo evita que ellos manden correo a otros sistemas. Para activar UUCP anonimo, tiene que especificar por lo menos un comando unknown en el fichero config. Si no, uucico rechazara cualquier sistema desconocido. 12.6 Protocolos de bajo nivel de UUCP Para negociar el control de la sesion y las transferencias de ficheros con el sistema remoto, uucico usa un grupo de mensajes estandar. Esto es lo que se llama normalmente protocolo de alto nivel. Durante la fase de inicializacion y la fase de desconexionestos se envian simplemente como tiras de caracteres. Sin embargo, durante la fase de transferencia, se usa tambien un protocolo de bajo nivel, que resulta transparente para los niveles superiores. De esta manera es posible comprobar errores cuando se usan lineas poco fiables, por ejemplo. 12.6.1 Resumen del protocolo Dado que UUCP se usa sobre diferentes tipos de conexiones, como lineas serie, TCP, o incluso X.25, es preciso usar protocolos de bajo nivel especificos. Ademas, varias implemen- taciones de UUCP han introducido diferentes protocolos para hacer lo mismo. Los protocolos se pueden dividir en dos categorias: de corriente o flujo (streaming) y por paquetes. La primera clase de protocolos transfiere un fichero entero, posiblemente calculando una suma de comprobacion (checksum). Esto apenas supone un gasto extra de tiempo, pero precisa una conexion fiable, porque cualquier error causaria que todo el fichero tenga que volver a ser enviado. Estos protocolos se suelen usar sobre conexiones de TCP, pero no sobre lineas telefonicas. Aunque los modems modernos hacen un buen trabajo corrigiendo errores, no son perfectos, y tampoco lo es la deteccion de errores entre el ordenador y el modem. Por su lado, los protocolos por paquetes parten el fichero en varias partes de igual tama"no. Cada paquete se envia y recibe por separado, se realiza una suma de comprobacion, y se devuelve al origen un paquete de confirmacion. Para que sea mas eficiente, se inventaron protocolos de ventanas deslizantes, que permiten un numero limitado (una ventana) de paquetes sin esperar confirmacion en un momento dado. Esto reduce considerablemente la cantidad de tiempo que uucico tiene que esperar durante una transmision. Aun asi, todos los calculos extra necesarios en comparacion a un protocolo de flujo hace que los protocolos _______________________________________________________________________________________________________________12.6. * *Protocolos de bajo nivel@ de paquetes sean ineficientes sobre TCP. El ancho de los datos tambien supone una diferencia. A veces, el envio de caracteres de ocho bits sobre una conexion serie es imposible, por ejemplo si la conexion atraviesa un estupido servidor de terminales. En este caso, los caracteres con el octavo bit igual a uno tienen que ser especialmente tratados. Cuando se envian caracteres de ocho bits sobre una conexion de siete bits, tienen que estar bajo la suposicion del peor caso posible. Esto duplica la cantidad de datos a transmitir, aunque la compresion que se hace por hardware puede compensar esto. Las lineas que pueden transmitir caracteres de ocho bits se llaman preparadas para ocho bits. Este es el caso de todas las conexiones TCP, asi como la mayoria de los modems. Existen los siguientes protocolos con Taylor UUCP 1.04: g Este es el protocolo mas comun y deberia ser entendido por practicamente todos los uucico's. Hace comprobacion de errores en profundidad y es, por lo tanto, apropiado para las ruidosas conexiones telefonicas. g require una conexion preparada para ocho bits. Es un protocolo orientado a paquetes que usa una tecnica de ventana deslizante. i Este es un protocolo bidireccional de paquetes que puede enviar y recibir ficheros al mismo tiempo. Requiere una conexion que permita comunicacion bidireccional simultanea (full-duplex) y preparada para ocho bits. Actual- mente solo es usado por Taylor UUCP. t Este es un protocolo dise"nado para usarse sobre una conexion de TCP, u otras redes libres de errores. Usa paquetes de 1024 bytes y requiere una conexion de ocho bits. e Este protocolo basicamente 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 conexion de siete bits. Los caracteres de ocho bits son codificados, lo cual lo hace muy ineficiente. G Esta es la version del Unix SVR419 del protocolo g. Tambien se utiliza en algunas otras versiones de UUCP. a Este protocolo es similar a ZMODEM. Requiere una conexion de ocho bits, pero codifica ciertos caracteres como XON y XOFF. _____________________________________________19 N. del T.: Unix Sistema V Version 4 _______________________________________________________________________________________________________________12.6. * *Protocolos de bajo nivel@ 12.6.2 Ajuste del protocolo de transmision Todos los protocolos permiten alguna variacion en el tama"no de los paquetes, el cronometro y similares. Usualmente, los valores por defecto funcionan bien, pero puede no seroptimo para su configuracion. El protocolo g, por ejemplo, usa tama"nos de ventanas de 1 a 7, y tama"nos de paquetes en potencias de 2 desde 64 a 4096.20 Si su linea telefonica es tan ruidosa que ignora el 5 por ciento de los paquetes, probablemente deberia disminuir el tama"no de los paquetes y de la ventana. Sin embargo, en lineas de telefono muy buenas el hecho de enviar acuses de recibo por cada 128 bytes puede resultar un desperdicio, asi que podria incrementar el tama"no de los paquetes a 512 o incluso 1024. Taylor UUCP provee un mecanismo para satisfacer sus necesidades mediante el ajuste de estos parametros con el comando protocol-parameter en el fichero sys. Por ejemplo, para ajustar el tama"no de los paquetes del protocolo g a 512 cuando se conecte con el sistema pablo, tiene que a"nadir: system pablo ... protocol-parameter g packet-size 512 Los parametros ajustables y sus nombres varian entre protocolos. Para ver una lista completa deestos puede consultar la documentacion que acompa"na al codigo fuente de Taylor UUCP. 12.6.3 Seleccion de protocolos especificos No todas las implementaciones de uucico hablan y entienden cada protocolo, de modo que durante la fase de negociacion de protocolos, ambos procesos tienen que ponerse de acuerdo en uno comum. El uucico maestro ofrece al esclavo una lista de protocolos soportados enviando Pprotlist , de la cual el esclavo elige uno. Segun el tipo de puerto usado (modem, TCP o directo), uucico crea una lista por defecto de protocolos. Para modem 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 podria modificar la entrada del fichero port para su puerto de modem de esta manera: port serial1 _____________________________________________20 La mayoria de los programas incluidos en las distribuciones de Linux usan por defecto un tama"no de ventana de 7 y paquetes de 128 bytes. _______________________________________________________________________________________________________________12.7. * *Solucion de problemas @ ... protocols igG Esto requiere que cualquier conexion entrante o saliente en este puerto use i, g o G. Si el sistema remoto no soporta ninguno deestos, la negociacion fallara. 12.7 Solucion de problemas Esta seccion describe lo que puede ir mal con su conexion 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 aqui. En cualquier caso, active la opcion de encontrar errores con -xall, y observe el re- sultado en el fichero Debug del directorio de cola. Esto deberia ayudarle rapidamente a reconocer donde reside el problema. Siempre me ha servido de ayuda el activar el alta- voz del modem cuando no se conecta. Con un modem compatible Hayes, esto se consigue a"nadiendo "ATL1M1 OK" en el dialogo del modem en el fichero dial. La primera cosa a comprobar siempre deberia ser si todos los permisos de los ficheros estan ajustados correctamente. uucico debe tener identificacion de usuario uucp, y todos los ficheros en /usr/lib/uucp, /var/spool/uucp y /var/spool/uucppublic tienen que pertenecer a uucp. Tambien 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 de- tecto 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, tam- bien es posible que haya otro uucico ejecutandose en el sistema que este intentando llamar al sistema remoto y se atasco en una macro de dialogo, etc. Si este uucico no consigue conectarse al sistema remoto, matelo con una se"nal de colgar (SIGHUP), y borre cualquier fichero de bloqueo que haya dejado. Me puedo conectar al sistema remoto, pero la macro de dialogo falla: Mire el texto que recibe del sistema remoto. Si esta salteado, esto puede ser un problema relacionado _____________________________________________21 Es decir, ficheros cuyo nombre empieza con un punto. Estos ficheros normalmente no aparecen con un comando ls. _______________________________________________________________________________________________________________12.7. * *Solucion de problemas @ con la velocidad. Si no, confirme que realmente envia lo que su macro de dialogo espera recibir. Recuerde, la macro de dialogo empieza con una cadena de caracteres esperada. Si usted recibe la invitacion de entrada al sistema (login), despues envia 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 rapido para su modem. Mi modem no marca: Si su modem no indica que la linea DTR ha sido elevada cuando uucico hace una llamada, posiblemente no le ha dado el dispositivo correcto a uucico. Si su modem 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 dialogo del modem. Si esto no produce un eco de sus comandos durante el dialogo del modem, compruebe si la velocidad de la linea es demasiado alta o demasiado baja para su modem. Si si que ve el eco, compruebe si ha desactivado las respuestas del modem, o las ha configurado como codigos numericos. Verifique que la macro de dialogo en si misma es valida. Recuerde que tiene que poner dos barras invertidas para enviar una al modem. Mi modem intenta marcar, pero la llamada no sale: Inserte un retraso en el numero de telefono. Esto es especialmenteutil cuando se llama fuera de la red interna de una compa"nia. Para la gente en Europa, que normalmente marca con pulsos (pulse-tone), pruebe con tonos (touch-tone). En ciertos paises, los servicios telefonicos 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 cone- xion entre su ordenador y su modem 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. Tambien tiene que asegurarse de que la negociacion hardware esta incluida en la linea serie. Otra posible causa es que la negociacion hardware no este activada en el puerto. Tay- lor UUCP 1.04 no tiene mecanismos para activar la negociacion de RTS/CTS. Tiene que activarla explicitamente en el fichero rc.serial usando el siguiente comando: $ stty crtscts < /dev/cua3 Puedo entrar en el otro sistema, pero la negociacion falla: Bien, puede ser debido a muchas causas. Los mensajes en el fichero de registro deberian decirle un monton de cosas. Mire que protocolos ofrece el sistema remoto (envia un Pprotlist durante la negociacion). A lo mejor no tienen nada en comum (>seleciono algun protocolo en sys o port ?). _______________________________________________________________________________________________________________12.8. * *Archivos de registro his@ Si el sistema remoto envia 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 linea, pida que lo borren. Si envia RBADSEQ, el otro sistema tiene la comprobacion de la cuenta de conversacion activada para su sistema, pero los numeros no se corresponden. Si envia RLOGIN, no le fue permitido entrar con ese nombre de usuario. 12.8 Archivos de registro historico (Log Files) Cuando se compila el paquete de UUCP para usar ficheros de registro al estilo Taylor- UUCP, se tendran tres ficheros historicos globales, y todos residiran en el directorio de cola. El fichero principal se llama Log y contiene toda la informacion sobre las conexiones establecidas y los ficheros transferidos. Un extracto tipico podria ser como el siguiente (despues de formatearlo para que quepa en la pagina): uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3) uucico pablo - (1994-05-28 17:15:39.25 539) Login successful uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful (protocol 'g' packet size 1024 window 7) uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2 uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1 uucico pablo - (1994-05-28 17:15:59.05 539) Protocol 'g' packets: sent 15, resent 0, received 32 uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds) uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1 (rmail okir) El siguiente fichero importante es Stats, que lista las estadisticas de transferencias de ficheros. La seccion de Stats que corresponde a la transferencia anterior se muestra aqui: postmaster pablo (1994-05-28 17:15:44.78) received 1714 bytes in 1.802 seconds (951 bytes/sec) postmaster pablo (1994-05-28 17:15:46.66) _______________________________________________________________________________________________________________12.8. * *Archivos de registro his@ received 57 bytes in 0.634 seconds (89 bytes/sec) postmaster pablo (1994-05-28 17:15:49.91) received 1898 bytes in 1.599 seconds (1186 bytes/sec) postmaster pablo (1994-05-28 17:15:51.67) received 65 bytes in 0.555 seconds (117 bytes/sec) postmaster pablo (1994-05-28 17:15:55.71) received 3217 bytes in 2.254 seconds (1427 bytes/sec) postmaster pablo (1994-05-28 17:15:57.31) received 65 bytes in 0.590 seconds (110 bytes/sec) Como en el caso anterior, las lineas han sido partidas para que quepan en la pagina. El tercer fichero es Debug. Este es el sitio donde se incluye toda la informacion para buscar errores. Si usted usa deteccion de errores (debugging), tiene que asegurarse de que este fichero tenga modo de proteccion de 600. Dependiendo del modo de busqueda 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 historico de HDB. HDB UUCP usa mu- chos 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 informacion historica 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 escribira en .Log/uuxqt/pablo. Las lineas escritas a cada uno de estos ficheros son sin embargo iguales que en Taylor UUCP. Cuando active la opcion de busqueda de errores con el estilo HDB, la informacion sera escrita en el directorio .Admin bajo /var/spool/uucp. Durante llamadas salientes, la informacion se envia al fichero .Admin/audit.local, mientras que la salida de uucico cuando alguien nos llama se graba en .Admin/audit. Capitulo 13 Correo Electronico Uno de los usos mas comunes de las redes informaticas desde sus origenes ha sido el correo electronico. Empezo siendo un simple servicio que copiaba un fichero de una maquina a otra, y lo a"nadia al fichero mailbox (buzon de correo) del destinatario. Basicamente, en esto sigue consistiendo el e-mail (correo electronico), aunque el crecimiento continuo de la red y, consiguientemente, el aumento de la complejidad de encaminado, ha hecho necesario un esquema mas elaborado. Se han dise"nado varios estandares de intercambio de correo. Los nodos conectados a la Internet cumplen uno recogido en el RFC 822, complementado en algunos RFCs que describen un metodo independiente de la maquina para transferir caracteres especiales, y similares. Mucho se ha discutido recientemente sobre el "correo multi-media", que tiene que ver con incluir imagenes y sonido en los mensajes de correo. Otro estandar, X.400, ha sido definido por el CCITT. Hay ya una gran cantidad de programas de transporte de correo para sistemas un?x. Uno de los mas conocidos es el sendmail, de la Universidad de Berkeley, que se usa en diversas plataformas. El autor original fue Eric Allman, que esta trabajando activamente en el equipo sendmail de nuevo. Hay dos adaptaciones para Linux del sendmail-5.56c disponibles, una de las cuales se describira en el capitulo 15. La version de sendmail actualmente en desarrollo es la 8.6.5. El agente de correo de uso mas comun en Linux es el smail-3.1.28, escrito por Curt Landon Noll y Ronald S. Karr y con Copyright de los mismos autores. Este es el que se incluye en la mayoria de las distribuciones de Linux. En lo sucesivo nos referiremos ael simplemente como smail, aunque hay otras versiones del mismo programa que son totalmente diferentes, y que no describiremos aqui. Comparado con sendmail, smail es bastante joven aun. Si se ocupan del correo de un 202 _______________________________________________________________________________________________________________13.1. * *>Que es un mensaje de co@ nodo peque"no sin necesidades de direccionamiento complicadas, sus capacidades son muy parecidas. Para nodos grandes, sin embargo, sendmail siempre gana, porque su metodo de configuracion es mucho mas flexible. Ambos smail y sendmail admiten un conjunto de ficheros de configuracion que deben ser adaptados a cada caso particular. Aparte de la informacion que se necesita para hacer funcionar el subsistema de correo (como puede ser el nombre del ordenador local), hay muchos mas parametros que pueden ajustarse. El fichero principal de configuracion de sendmail es muy dificil de entender a la primera. Parece como si el gato se hubiese echado una siesta sobre el teclado con la tecla de mayusculas pulsada. Los ficheros de configuracion de smail estan mas estructurados y son mas faciles de entender que los del sendmail, pero no dan al usuario tanto poder a la hora de ajustar el comportamiento del gestor de correo. De todos modos, para nodos peque"nos de UUCP o Internet, el trabajo que se necesita para poner a punto cualquiera de ellos es practicamente el mismo. En este capitulo trataremos sobre que es el `e-mail' y que temas tendra que abordar usted como administrador del sistema. Los capitulos 14 y 15 daran instrucciones para poner a punto smail y sendmail por primera vez. La informacion que se suministra debe bastar para poner en marcha peque"nos nodos, pero hay muchas mas opciones y usted podra pasar muchas horas felices frente a su ordenador configurando las caracteristicas mas superficiales. Hacia el final de este capitulo nos ocuparemos brevemente de como poner a punto elm, un programa para usuario de correo muy comun en muchos sistemas un?x, incluyendo Linux. Para mas informacion sobre temas especificos de correo electronico sobre Linux, por favor, consulte el `Electronic Mail HOWTO' de Vince Skahan, que aparece en comp.os.linux.announce con regularidad. Las distribuciones fuente de elm, smail y send- mail contienen tambien una documentacion muy extensa que debe solucionar la mayoria de sus dudas sobre instalacion y puesta a punto. Si busca informacion sobre correo electronico en general, hay varios RFCs que tratan especificamente este tema. Una lista de ellos se encuentra en la bibliografia al final del libro. 13.1 >Que es un mensaje de correo? Un mensaje de correo consta de un contenido (body), que es el texto que ha escrito el remitente, y datos especiales que especifican el destinatario o destinatarios, el medio de transporte, etc., de manera similar a lo que aparece en el sobre de una carta ordinaria. Estos datos administrativos se clasifican en dos categorias; en la primera categoria estan los datos que son especificos del medio de transporte, como son las direcciones del remitente _______________________________________________________________________________________________________________13.1. * *>Que es un mensaje de co@ y del destinatario. A esto se le llama el sobre (envelope). Puede ser modificado por el software de transporte a medida que el mensaje es transmitido. La segunda variedad es cualquier dato necesario para la manipulacion del mensaje, que no es propio de ningun mecanismo de transporte, como es la linea del encabezado en la que indicamos el tema del mensaje (Subject), la lista de todos los destinatarios, y la fecha en la que se envio el mensaje. En muchas redes, se ha convertido en un estandar incluir estos datos al comienzo del mensaje, formando lo que se denomina encabezado del mensaje (mail header). Se separa del contenido del mensaje (mail body) por una linea en blanco. 1 La mayoria del software para transporte de correo que se usa en el mundo un?x usa un formato de encabezado definido en el RFC 822. Su proposito original era especificar un estandar para usar en la ARPANET, pero dado que fue dise"nado para ser independiente del entorno de uso, ha sido facilmente adaptado a otras redes, incluyendo muchas basadas en UUCP. Pero RFC 822 es solo el maximo denominador comun. Otros estandares mas recien- tes han sido concebidos para dar respuesta a las crecientes necesidades como pueden ser, por ejemplo, encriptacion de datos, soporte de conjuntos de caracteres internacionales, y extensiones de correo multimedia (multi-media mail extension, MIME). En todos esos estandares, el encabezado consiste en varias lineas, separadas por carac- teres de retorno de carro. Cada linea consiste en un nombre de campo, que comienza en la columna uno, y el campo en si, separados por dos puntos (:) o un espacio. El formato y la semantica de cada campo varia dependiendo del nombre del mismo. Un campo del encabezado se puede continuar mas alla de una linea, si la linea siguiente comienza con un caracter de tabulacion. Los campos pueden aparecer en cualquier orden. Un encabezado de correo tipico puede ser algo asi: From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994 Return-Path: Received: from brewhq.swb.de by monad.swb.de with uucp (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp (Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 21:47 MEST Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 -0400 Date: Tue, 12 Apr 1994 15:56:49 -0400 Message-Id: <199404121956.PAA07787@ruby> From: andyo@ora.com (Andy Oram) To: okir@monad.swb.de Subject: Re: Tu parte de RPC _____________________________________________1 Se suele a"nadir una firma (signature) o .sig a un mensaje, usualmente conteniendo informacion sobre el autor, junto con un chiste o cita celebre. Se separa del resto del mensaje con una linea conteniendo "-- ". _______________________________________________________________________________________________________________13.1. * *>Que es un mensaje de co@ Usualmente, todos los campos del encabezado necesarios son generados por la interface con el servidor de correo que usted use, como elm, pine, mush, o mailx. Algunos, sin embargo, son opcionales, y pueden ser a"nadidos por el usuario. elm, por ejemplo, permite editar parte del encabezado del mensaje. Otros campos son a"nadidos por el software de transporte de correo. Una lista de campos de encabezado comunes y su significado se da a continuacion: From: Contiene la direccion de correo electronico del remitente, y posiblemente el "nombre real". Un verdadero zoologico de formatos distintos se usa aqui. To: Esta es la direccion de e-mail del destinatario. Subject: Describe el contenido del mensaje en pocas palabras. Al menos eso es lo que debiera hacer. Date: La fecha en la que el mensaje fue enviado. Reply-To: Especifica la direccion a la que el remitente desea que el destinatario le conteste. Esto puede serutil si se tienen varias direcciones, pero se desea recibir la mayor parte del correo solo en aquella que se usa mas a menudo. Este campo es opcional. Organization: La organizacion que posee la maquina desde la que se ha enviado el mensaje. Si la maquina usada es la suya propia no incluya este campo, o bien indique "privado" o cualquier trivialidad sin sentido. Este campo es opcional. Message-ID: Una cadena generada por el transporte de correo en el sistema remitente. Esunica para cada mensaje. Received: Cada nodo que procesa su correo (incluyendo las maquinas del remitente y el destinatario) insertan este campo en el encabezado, dando el nombre del nodo, una identificacion de mensaje, hora y fecha a la que lo recibieron, de que nodo procede, y que software de transporte ha sido usado. Esto se hace asi para que usted pueda conocer la ruta que su mensaje ha seguido, y pueda protestar a la persona responsable si algo ha ido mal. X-cualquier-cosa: Ningun programa relacionado con el correo debe protestar sobre cualquier encabezado que comience con X-. Esto se usa para implementar caracteristi- cas adicionales que aun no han sido incluidas en un RFC, o que no lo seran nunca. Esto se usa, por ejemplo, en la lista de correo de los Activistas de Linux, donde el canal a usar se selecciona con el campo de encabezado X-Mn-Key:. _______________________________________________________________________________________________________________13.2. * *>Como se reparte el corr@ Launica excepcion a esta estructura es la primera linea. Comienza con la palabra clave From seguida de un espacio en blanco, en vez de dos puntos. Para distinguirlo del campo ordinario From: se suele denotar como From_. Contiene la ruta que ha seguido el mensaje, escrita al estilo ruta bang de UUCP (explicado mas adelante), la hora y la fecha en que fue recibido por laultima maquina que lo ha procesado, y una parte opcional que especifica desde que maquina ha sido recibido. Como este campo es regenerado por cada sistema que procesa el mensaje, alguna veces queda incluido en los datos del sobre. El campo From_ continua existiendo por compatibilidad con procesadores de correo antiguos, pero no se usa demasiado en la actualidad excepto por algunos interfaces de usuario de correo que se basan enel para marcar el comienzo de un mensaje en el buzon del usuario. Para evitar problemas potenciales con lineas del contenido del mensaje que comiencen tambien con "From ", se ha convertido en practica comun distinguir esteultimo caso precediendolo de un ">". 13.2 >Como se reparte el correo? Generalmente, usted escribira su correo usando un interface de correo como mail o mailx ; u otros mas sofisticados como elm, mush, o pine. Estos programas se denominan agentes de usuario de correo (mail user agents), o MUAs para abreviar. Si usted envia un mensaje de correo, el programa interface en la mayoria de los casos se lo pasara a otro programa para que lo transmita. Este programa se denomina el agente de transporte de correo (mail transport agent), o MTA. En algunos sistemas hay agentes de transporte de correo distintos para envios locales o lejanos; en otros hay solo un MTA. El comando para envios lejanos se denomina usualmente rmail, el otro se denomina lmail (si existe). Un envio local de correo es, por supuesto, algo mas que a"nadir el mensaje al buzon del destinatario. Usualmente el MTA local entendera como usar alias (definir direcciones locales de destinatarios que dirigen a otras direcciones) y como usar redirecciones2, es decir, dirigir el correo de un usuario a otra direccion). Tambien, los mensajes que no pudieron ser enviados deben ser normalmente devueltos (bounced) al remitente junto con algun mensaje de error. Para envios lejanos, el software de transporte usado depende del tipo de enlace. Si el correo debe enviarse a traves de una red que usa TCP/IP, se usara normalmente SMTP. SMTP son las siglas de Simple Mail Transfer Protocol, o Protocolo Simple de Trasferencia de Correo que se define en el RFC 788 y RFC 821. SMTP usualmente conecta con la maqui- na del destinatario directamente, negociando la transferencia del mensaje con el demonio SMTP del otro lado. _____________________________________________2 N. del T.: Del ingles forwarding _______________________________________________________________________________________________________________13.3. * *Direcciones de correo el@ En redes tipo UUCP, el correo no suele ser enviado directamente, sino que es redirigido hasta su destino a traves de un conjunto de maquinas intermedias. Para enviar un mensaje a traves de un enlace UUCP, el MTA remitente ejecutara usualmente rmail en la maquina intermedia usando uux, y suministrandole el mensaje en la entrada estandar. Dado que esto se hace para cada mensaje por separado, puede producir una carga con- siderable de trabajo en un nodo procesador de correo grande, ademas de inundar las colas UUCP con cientos de peque"nos mensajes que ocupan una cantidad de disco desproporcio- nada. 3 Por esto algunos MTAs permiten recopilar varios mensajes de un sistema remoto en un solo lote. El fichero de lotes contiene los comandos SMTP que el nodo local ejecutaria normalmente si usara una conexion SMTP directa. A esto se le llama BSMTP, o batched SMTP (SMTP por lotes). El lote es suministrado al programa rsmtp o bsmtp en el sistema remoto, que procesara la entrada como si una conexion SMTP normal hubiese ocurrido. 13.3 Direcciones de correo electronico Para el correo electronico, una direccion consiste en, al menos, el nombre de la maquina que maneja el correo del destinatario, y una identificacion de usuario reconocida por ese sistema. Puede ser el nombre de acceso del destinatario, pero puede ser tambien cualquier otra cosa. Otros esquemas de direcciones, como el X.400, usan un conjunto mas general de "atributos" que se utilizan para buscar la maquina del destinatario en un servidor de directorio X.500. La forma en que se interpreta un nombre de maquina, es decir, a que nodo va a llegar finalmente nuestro mensaje, y como combinar este nombre con el nombre de usuario del destinatario depende enormemente de la red en la que nos encontremos. Los nodos en la Internet siguen el estandar RFC 822, que requiere una notacion usua- rio@maquina.dominio, donde maquina.dominio es el nombre de dominio totalmente cualificado (Fully Qualified Domain Name, o FQDN) de la maquina. El signo de arroba que aparece entre medias se suele denominar signo "at"4. Dado que esta notacion no indica la ruta hasta la maquina de destino, sino que da el nombre (unico) de dicha maquina, a esto se le suele llamar una direccion absoluta. En el entorno UUCP original, la forma predominante era ruta!maquina!usuario, don- de ruta describia una secuencia de maquinas a traves de las cuales debia viajar el mensaje para llegar a maquina, su destino final. Esta notacion se llama la ruta bang, porque un sig- no de exclamacion se denomina coloquialmente "bang". Hoy en dia muchas redes basadas _____________________________________________3 Esto es asi porque el espacio de disco se asigna usualmente en bloques de 1024 Bytes. Incluso un mensaje de como mucho 400 Bytes ocupara 1 Kb completo. 4 N. del T. de la preposicion inglesa "at", que significa "en" _______________________________________________________________________________________________________________13.3. * *Direcciones de correo el@ en UUCP han adoptado el RFC 822, y entenderan ese tipo de direccion. Estos dos tipos de direcciones no se mezclan muy bien. Supongamos una direccion maquinaA!usuario@maquinaB. No queda claro si el signo `@' tiene precedencia sobre la ruta o viceversa: >Hemos de enviar el mensaje a maquinaB, que lo enviara a maqui- naA!usuario, o debe ser enviado maquinaA, que lo redirigira a usuario@maquinaB? Las direcciones que mezclan diferentes tipos de operadores de direccion se denominan direcciones hibridas. El mas notorio es el ejemplo anterior. Se resuelve usualmente dandole precedencia al signo `@' sobre la ruta. En el ejemplo anterior, esto significa enviar el mensaje a maquinaB primero. De todos modos, hay una forma de especificar rutas acorde con RFC 822: <@maqui- naA,@maquinaB:usuario@maquinaC> denota la direccion de usuario en maquinaC, indicando que se debe llegar a maquinaC a traves de maquinaA y maquinaB (en ese orden). Este tipo de direccion se suele llamar una direccion route-addr (de route, ruta y address, direccion). Y tambien existe el operador de direccion `%': usuario%maquinaB@maquinaA sera enviado primero a maquinaA, que sustituira el signo de tanto por ciento que se encuentre mas a la derecha en la expresion (en este caso elunico) por un signo `@'. La direccion quedara ahora usuario@maquinaB, y el gestor de correo redirigira alegremente el mensaje a la maquinaB que lo entregara a usuario. Este tipo de direccion se suele denominar a veces como "Ye Olde ARPANET Kludge" ("La Vieja Chapuza de ARPANET") y su uso esta desaconsejado. Aun asi muchos agentes de transporte de correo generan este tipo de direcciones. Otras redes tienen mas formas de expresar direcciones. Las redes basadas en el pro- tocolo DECnet, por ejemplo, usan dos signos de dos puntos como separador, dando lugar a direcciones como maquina ::usuario .5 Finalmente, el estandar X.400 usa un esquema totalmente distinto, describiendo a un destinatario por un conjunto de pares atributo-valor, como pais u organizacion. En FidoNet, cada usuario se identifica por un codigo como 2:320/204.9, que consiste en cuatro numeros que denotan la zona (2 es Europa), red (320 es Paris y Banlieve), nodo (el repetidor/BBS local), y punto (el PC del usuario). Las direcciones Fidonet se pueden tradu- cir a RFC 822: la anterior se escribiria Thomas.Quinot@p9.f204.n320.z2.fidonet.org. >No he dicho antes que los nombres de dominio son faciles de recordar? Hay algunas implicaciones al usar esos tipos diferentes de direcciones que seran descritas a lo largo de las proximas secciones. De todos modos, en un entorno RFC 822 raramente _____________________________________________5 Cuando se intente llegar a una direccion DECnet desde un entorno RFC 822 se puede usar maquina::usuario.@relevo, donde relevo es el nombre de una pasarela Internet-DECnet conocida. _______________________________________________________________________________________________________________13.4. * *>Como funciona el encami@ se usara otra cosa que direcciones absolutas como usuario@maquina.dominio. 13.4 >Como funciona el encaminado del correo? El proceso de dirigir un mensaje a la maquina del destinatario se denomina encaminado. Ademas de encontrar una ruta desde el nodo emisor al receptor, este proceso incluye tambien chequeo de errores asi como optimizacion de velocidad y coste. Hay mucha diferencia en la forma en la que un nodo UUCP maneja el encaminado y la forma en que lo hace un nodo Internet. En la Internet, el trabajo principal de dirigir datos al nodo del destinatario (una vez que se conoce por su direccion IP) se realiza por la capa IP de control de red, mientras que en UUCP, la ruta debe ser suministrada por el usuario, o generada por el agente de transporte de correo. 13.4.1 Encaminado de correo en la Internet En la Internet, depende enteramente del nodo de destino el que se realice algun encaminado especifico de correo. El comportamiento por defecto consiste en enviar el mensaje al nodo de destino buscando su direccion IP, y dejando el encaminado de los datos en si a la capa IP de transporte. Generalmente, la mayoria de los nodos querran que todo el correo entrante se dirija a un servidor de correo facilmente accesible que sea capaz de procesar todo ese trafico, y que distribuira ese correo localmente. Para anunciar ese servicio, el nodo publica el llamado campo MX para su dominio local en la base de datos DNS. MX significa Mail Exchanger (Intercambiador de correo) y basicamente quiere decir que el servidor va a actuar como un redistribuidor de correo para todas las maquinas de este dominio. Los campos MX tambien pueden usarse para manipular el trafico dirigido a maquinas que no estan ellas mismas conectadas a la Internet, como redes UUCP o redes corporativas que contienen informacion confidencial. Los campos MX tambien tienen una preferencia asociada. Es un entero positivo. Si existen varios intercambiadores de correo para una maquina, el agente de transporte de correo intentara enviar el mensaje al intercambiador con menor valor de preferencia, y solo sieste falla probara uno con mayor valor. Si el nodo local esel mismo un intercambiador de correo para la direccion de destino, no redirigira los mensajes a cualquier maquina MX que tenga un valor de preferencia mayor que el suyo propio: esta es una forma segura de evitar bucles de correo. Supongamos que una organizacion, digamos la Sociedad ACME, quiere que todo su _______________________________________________________________________________________________________________13.4. * *>Como funciona el encami@ correo sea manipulado por su maquina llamada mailhub. Entonces tendran un campo MX como el siguiente en su base de datos DNS: acme.com IN MX 5 mailhub.acme.com Esto anuncia que mailhub.acme.com es un intercambiador de correo para ac- me.com con un valor de preferencia de 5. Una maquina que desee enviar un mensaje a joe@greenhouse.acme.com buscara el registro DNS de acme.com, y encontrara el campo MX apuntando hacia mailhub. Si no hay ningun MX con un valor de preferencia menor que 5, el mensaje sera enviado a mailhub, que lo entregara a greenhouse. Lo anterior es solo un esbozo de como funcionan los campos MX. Para mas informacion sobre encaminado de correo en la Internet, por favor consulte el RFC 974. 13.4.2 Encaminado de correo en el mundo UUCP El encaminado de correo en redes UUCP es mucho mas complicado que en la Internet, porque el software de transporte no realiza ningun encaminado. Al principio, todo el correo tenia que ser dirigido usando rutas bang. Las rutas bang especifican, como hemos dicho ya, una lista de nodos a traves de los cuales enviar el mensaje, separados por signos de admiracion, y seguida del nombre del usuario. Para dirigir una carta a Juanita, usuaria de una maquina llamada moria, deberiamos usar la ruta eel!swim!moria!juanita. Esto enviaria el correo desde nuestro nodo a eek, desde alli a swim y finalmente a moria. El inconveniente obvio de esta tecnica es que obliga a que recordemos mucho sobre la topologia de la red, enlaces rapidos, etc. Aun peor, cualquier cambio en la topologia de la red _ como enlaces que se eliminan o nodos que se quitan _ puede causar que el mensaje no llegue al destino simplemente porque no se estaba al tanto del cambio. Y finalmente en caso de que nos mudemos a otro lugar, deberemos actualizar todas esas rutas. Sin embargo, un hecho que hizo que fuese necesario el uso del encaminado manual fue la presencia de nombres de nodo ambiguos: por ejemplo, supongamos que hay dos maquinas llamadas moria, una en los EE.UU., y otra en Francia. >A cual de ellas nos referimos con moria!juanita? Esto puede quedar claro especificando que ruta seguir para llegar a moria. El primer paso para eliminar ambig"uedades en nombres de nodos fue la fundacion del Proyecto de Cartografia UUCP (The UUCP Mapping Project). Se encuentra en la Universi- dad de Rutgers, y lleva el registro de todos los nombres de nodos oficiales UUCP, junto con informacion de sus vecinos UUCP y su localizacion geografica, asegurandose de que ningun nombre se repite. La informacion recogida por el Proyecto de Cartografia se publica como _______________________________________________________________________________________________________________13.4. * *>Como funciona el encami@ los Mapas de Usenet, que se distribuyen regularmente en Usenet.6 Una entrada tipica para un sistema en un mapa (despues de eliminar los comentarios) seria algo asi: moria bert(DAILY/2), swim(WEEKLY) Esta entrada dice que moria tiene un enlace con bert, al que llama dos veces al dia (DAILY=diariamente), y con swim, al que llama una vez a la semana (WEEKLY). Volve- remos de nuevo al formato del fichero mapa mas adelante. Usando la informacion sobre conectividad proporcionada en los mapas, se pueden gene- rar automaticamente las rutas completas de nuestra maquina a cualquier nodo de destino. Esta informacion se almacena usualmente en el fichero paths, tambien llamado base de da- tos de alias de rutas (pathalias database). Suponiendo que los mapas indican que se puede llegar a bert a traves de ernie, entonces una entrada de alias de ruta para moria generada a partir del fragmento de mapa anterior quedaria tal que asi: moria ernie!bert!moria!%s Si ahora damos una direccion de destino de juanita@moria.uucp, nuestro MTA esco- gera la ruta mostrada anteriormente, y enviara el mensaje a ernie con una direccion en el sobre de bert!moria!juanita. De todos modos, construir un fichero paths a partir de los mapas completos de Usenet no es una buena idea. La informacion proporcionada en ellos normalmente esta bastante distorsionada, y a veces es obsoleta. Asi, solo unos pocos nodos grandes usan los mapas mundiales completos de UUCP para construir su fichero paths. La mayoria de los nodos solo mantienen informacion de encaminado hacia los nodos en sus cercanias, y envian cualquier correo dirigido a nodos que no encuentran en sus bases de datos a un nodo mas inteligente, con una informacion de encaminado mas completa. Este esquema se denomina encaminado por nodo inteligente (smart-host routing). Las maquinas que tienen un solo enlace de correo UUCP (llamadas nodos hoja) no realizan ningun encaminado propio; confian enteramente en su nodo inteligente para esta tarea. 13.4.3 Mezcla de UUCP y RFC 822 La mejor cura contra los problemas vistos con el encaminado en redes UUCP es la adopcion del sistema de nombres de dominio en ellas. Por supuesto, no se pueden hacer peticiones _____________________________________________6 Los mapas de nodos registrados en el Proyecto de Cartografia UUCP se distribuyen en el grupo de noticias comp.mail.maps; otras organizaciones pueden publicar mapas separados para su red. _______________________________________________________________________________________________________________13.4. * *>Como funciona el encami@ a un servidor de nombres usando UUCP. Aun asi, muchos nodos UUCP han formado pe- que"nos dominios que coordinan su encaminado internamente. En los mapas, estos dominios publican uno o dos nodos como sus pasarelas de correo, de modo que no tenga que haber una entrada en el mapa para cada nodo en el dominio. Las pasarelas pueden distribuir todo el correo que fluye hacia dentro y hacia fuera del dominio. El esquema de encaminado dentro del dominio es completamente invisible para el resto del mundo. Esto funciona muy bien con el esquema de encaminado por nodo inteligente descrito anteriormente. La informacion de encaminado global se encuentra solo en las pasarelas; a los nodos menores dentro de un dominio les basta con un peque"no fichero paths escrito a mano que contiene la lista de las rutas dentro de su dominio, y la ruta al concentrador de correo. Incluso las pasarelas de correo no tienen por que incluir informacion de encaminado hacia cada una de las maquinas UUCP en el mundo. Aparte de la informacion completa de encaminado para el dominio al que sirven, ahora solo necesitan tener en sus bases de datos rutas a dominios completos. Por ejemplo, la siguiente entrada alias de ruta encaminara todo el correo para nodos del dominio sub.org a smurf : .sub.org swim!smurf!%s Cualquier correo dirigido a claire@jones.sub.org sera enviado a swim con una direc- cion en el sobre tal como smurf !jones!claire. La organizacion jerarquica del espacio de nombres de dominio permite a los servido- res de correo mezclar rutas mas especificas con otras menos especificas. Por ejemplo, un sistema en Francia puede tener rutas especificas hacia subdominios de fr, pero encaminar cualquier correo dirigido a maquinas del dominio us hacia algun sistema en los EE.UU. De esta forma, el encaminado basado en dominios (que es como se denomina esta tecnica) reduce enormemente el tama"no de las bases de datos de encaminado, asi como las tareas de administracion requeridas. El mayor beneficio de usar nombres de dominio en un entorno UUCP, de todos modos, es que al cumplir con RFC 822 se pueden facilmente usar pasarelas entre redes UUCP y la Internet. Hoy en dia, muchos dominios UUCP tienen un enlace con una pasarela a Internet que actua como su nodo inteligente. Enviar mensajes a traves de la Internet es mas rapido, y la informacion de encaminado es mucho mas fiable porque los nodos en la Internet pueden usar DNS en vez de mapas Usenet. Para poder ser alcanzables desde la Internet, los dominios basados en UUCP usualmente hacen que su pasarela a Internet anuncie una entrada MX para ellos (las entradas MX que fueron descritas anteriormente). Por ejemplo, supongamos que moria pertenece al dominio orcnet.org y que gcc2.groucho.edu actua como su pasarela a Internet. Entonces moria usaria gcc2 como su nodo inteligente, de modo que todo el correo hacia dominios remotos _______________________________________________________________________________________________________________13.5. * *Formatos de Fichero Mapa@ seria enviado a traves de la Internet. Por otro lado, gcc2 anunciaria una entrada MX para orcnet.org, y enviaria todo el correo entrante para nodos de orcnet a moria. Elunico problema que queda es que los programas de transporte UUCP no pueden ma- nejar nombres de dominio totalmente cualificados. La mayoria de los paquetes integrados de UUCP fueron dise"nados para tratar con nombres de nodos de ocho caracteres como maximo, algunos incluso menos, y usar caracteres no alfanumericos, como puntos, esta totalmente fuera de lugar para la mayoria. Asi, es imprescindible disponer de alguna forma de relacionar nombres RFC 822 y UUCP. La forma en que esto se hace es totalmente dependiente de la implementacion. Una manera comun de relacionar FQDNs con nombres UUCP es usar el fichero de alias de ruta para esto: moria.orcnet.org ernie!bert!moria!%s Esto producira una ruta bang al estilo UUCP puro a partir de una direccion que especifi- ca un nombre de dominio totalmente cualificado. Algunos programas de correo suministran un fichero especial para esto; sendmail, por ejemplo, usa el fichero uucpxtable. La transformacion inversa (llamada coloquialmente dominizar) se necesita a veces cuan- do se envia correo desde una red UUCP a la Internet. Mientras el remitente use el nombre de dominio totalmente cualificado en la direccion de destino, este problema se puede evitar no eliminando el nombre del dominio de la direccion del sobre cuando se redirige el men- saje al nodo inteligente. De todos modos, siguen existiendo algunos nodos UUCP que no son parte de ningun dominio. Estos se dominizan usualmente a"nadiendo el pseudo-dominio uucp. 13.5 Formatos de Fichero Mapa y Alias de Ruta La base de datos de alias de ruta ofrece la informacion de encaminado principal en redes basadas en UUCP. Una entrada tipica sera como sigue (nombre del nodo y ruta separadas por tabuladores): moria.orcnet.org ernie!bert!moria!%s moria ernie!bert!moria!%s Esto hace que cualquier mensaje a moria sea enviado via ernie y bert. Ambos nombres de moria (su nombre totalmente cualificado y su nombre UUCP) deben ser suministrados si el programa no tiene una forma separada de relacionar ambos. _______________________________________________________________________________________________________________13.5. * *Formatos de Fichero Mapa@ Si se quieren dirigir los mensajes destinados a maquinas dentro de algun dominio a su concentrador de correo, se debe tambien especificar un camino en la base de datos de alias de ruta, dando el nombre del dominio como objetivo, precedido de un punto. Por ejemplo, si todas las maquinas de sub.org pueden ser alcanzadas a traves de swim!smurf, la entrada de alias de ruta debe ser: .sub.org swim!smurf!%s Escribir un fichero de alias de ruta es aceptable solo cuando se esta manejando un nodo que no necesita hacer demasiados encaminados. Si se tienen que hacer encaminados hacia un gran numero de maquinas, una manera mejor es usar el comando pathalias para crear el fichero a partir de los ficheros de mapa. Los mapas se pueden mantener con mas facilidad, porque solo hay que a"nadir o quitar un sistema editando la entrada de dicho sistema en el mapa, y volver a crear el fichero de mapa. Aunque los mapas publicados por el Proyecto de Cartografia de Usenet ya no se usan demasiado para encaminar, las redes UUCP peque"nas pueden suministrar informacion de encaminado en su propio conjunto de mapas. Un fichero de mapa consiste principalmente en una lista de nodos, junto con los nodos que cada sistema registra o lo registran. El nombre del sistema comienza en la columna uno, y sigue una lista de enlaces separados por comas. La lista se puede continuar en varias lineas, comenzando cada nueva linea con un tabulador. Cada enlace consiste en el nombre del nodo enlazado, seguido del coste, entre corchetes. El coste es una expresion aritmetica, consistente en numeros y costes simbolicos. Las lineas que comienzan con un signo hash (#) se ignoran. Como ejemplo, consideremos moria, que registra a swim.twobirds.com dos veces al dia, y a bert.sesame.com una vez a la semana. Ademas el enlace con bert usa solo un modem lento de 2400bps. moria publicaria la siguiente entrada en los mapas: moria.orcnet.org swim.twobirds.com(DAILY/2), bert.sesame.com(WEEKLY+LOW) moria.orcnet.org = moria Laultima linea lo haria ser conocido bajo su nombre UUCP tambien. Observese que debe ser DAILY/2, porque llamar dos veces al dia reduce a la mitad el coste de ese enlace. Usando la informacion de dichos ficheros de mapa, pathalias puede calcular rutasoptimas para cualquier destino que aparezca en el fichero de rutas, y producir una base de datos de alias de ruta a partir deeste, que se puede usar para encaminar hacia esos nodos. _______________________________________________________________________________________________________________13.6. * *Configuracion de elm @ pathalias proporciona varias posibilidades mas, como esconder nodos (es decir, hacerlos accesibles solo a traves de una pasarela), etc. Vease la pagina del manual sobre pathalias para mas detalles, ademas de una lista completa de costes de enlace. Los comentarios en el fichero de mapa contienen generalmente informacion adicional sobre los nodos descritos enel. Existe un formato rigido para especificaresta, de manera que pueda ser recuperada de los mapas. Por ejemplo, un programa llamado uuwho usa una base de datos creada a partir de los ficheros de mapa para presentar esta informacion de una manera elegante. Cuando se registra un nodo con una organizacion que distribuye ficheros de mapa a sus miembros, generalmente se debe rellenar una de esas entradas de mapa. A continuacion hay una entrada de mapa de ejemplo (de hecho, es la del nodo del autor): #N monad, monad.swb.de, monad.swb.sub.org #S AT 486DX50; Linux 0.99 #O private #C Olaf Kirch #E okir@monad.swb.de #P Kattreinstr. 38, D-64295 Darmstadt, FRG #L 49 52 03 N / 08 38 40 E #U brewhq #W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993 # monad brewhq(DAILY/2) # Domains monad = monad.swb.de monad = monad.swb.sub.org El espacio en blanco detras de los primeros dos caracteres es un tabulador. El significado de la mayoria de los campos es bastante obvio; recibiremos una descripcion detallada del dominio con el que vayamos a registrarnos. El campo L es el mas divertido de averiguar: da nuestra posicion geografica en latitud/longitud y se usa para dibujar los mapas postscript que muestran todos los nodos de cada pais, asi como los del mundo entero. 7 13.6 Configuracion de elm elm significa "electronic mail" (correo electronico) y es una de las utilidades un?x mas razonablemente bautizadas. Proporciona una interface de pantalla completa con una buena _____________________________________________7 Aparecen regularmente en news.lists.ps-maps. Cuidado: son enormes. _______________________________________________________________________________________________________________13.6. * *Configuracion de elm @ utilidad de ayuda. No vamos a explicar aqui como se usa elm, solo nos detendremos en sus opciones de configuracion. Teoricamente, se puede usar elm sin configurar, y todo funciona bien _ con suerte. Pero hay algunas opciones que deben definirse, aunque solo se necesitan en contadas ocasiones. Cuando comienza, elm lee un conjunto de variables de configuracion desde el fichero elm.rc en /usr/lib/elm. Entonces, intentara leer el fichero .elm/elmrc en nuestro directorio personal. Normalmente este fichero no se genera a mano. Se crea cuando se escoge "save options" (grabar opciones) desde el menu de opciones de elm. El conjunto de opciones para el fichero privado elmrc tambien esta disponible en el fichero global elm.rc. La mayoria de las definiciones en el fichero privado elmrc sustituiran a las del fichero global. 13.6.1 Opciones Globales de elm En el fichero global elm.rc, se deben definir las opciones que pertenecen a nuestro nombre de maquina. Por ejemplo, en la Cervecera Virtual, el fichero para vlager contendra lo siguiente: # # El nombre del nodo local hostname = vlager # # Nombre del dominio hostdomain = .vbrew.com # # Nombre de dominio totalmente cualificado (FQDN) hostfullname = vlager.vbrew.com Estas opciones definen la idea que tiene elm sobre el nombre de la maquina local. Aunque esta informacion se usa raramente, debemos definir estas opciones. Observese que estas opciones solo tienen efecto cuando se dan en el fichero global de configuracion; cuando se encuentran en nuestro elmrc privado, seran ignoradas. 13.6.2 Conjuntos de Caracteres Nacionales Recientemente, han habido propuestas para corregir el estandar RFC 822 para soportar varios tipos de mensajes, como texto simple, datos binarios, ficheros Postscript, etc. El conjunto de estandares y RFCs que cubren estos aspectos se suelen conocer como MIME, _______________________________________________________________________________________________________________13.6. * *Configuracion de elm @ o Extensiones de Correo Internet Multiproposito (Multipurpose Internet Mail Extensions). Entre otras cosas, esto permite al destinatario saber si un conjunto de caracteres distinto del estandar ASCII ha sido usado al escribir el mensaje, por ejemplo usando los acentos o dieresis del castellano. Esto tiene soporte en elm hasta cierto punto. El conjunto de caracteres usado por Linux internamente para representar caracteres se suele denominar ISO-8859-1, que es el nombre del estandar que cumple. Tambien se conoce como Latin-1. Cualquier mensaje que use caracteres de ese conjunto debe llevar la siguiente linea en su encabezado: Content-Type: text/plain; charset=iso-8859-1 El sistema que recibe el mensaje debe reconocer este campo y tomar las medidas apro- piadas cuando muestra el mensaje. El valor por defecto para mensajes text/plain (texto simple) es un valor de charset (conjunto de caracteres) de us-ascii. Para poder mostrar mensajes con conjuntos de caracteres distintos al ASCII, elm debe saber como mostrar esos caracteres. Por defecto, cuando elm recibe un mensaje con un campo charset distinto de us-ascii (o un tipo de contenido distinto de text/plain, a todos los efectos), intenta mostrar el mensaje usando un comando llamado metamail. Los mensajes que requieren metamail para ser mostrados aparecen con una `M' en la primera columna en la pantalla de listado de mensajes (overview). Como el conjunto de caracteres nativo de Linux es ISO-8859-1, llamar a metamail no es necesario para mostrar mensajes que usen dicho conjunto. Si se le dice a elm que la pantalla entiende ISO-8859-1, no usara metamail sino que mostrara el mensaje directamente. Esto se puede hacer definiendo la siguiente opcion en el elm.rc global: displaycharset = iso-8859-1 Observese que se puede definir esta opcion incluso cuando nunca vayamos a enviar o recibir mensajes que realmente contengan caracteres distintos del ASCII. Esto es asi porque la gente que envia esos mensajes, usualmente configura su programa de correo para que incluya el campo Content-Type: (tipo de contenido) adecuado en el encabezado de correo por defecto, vayan o no a enviar mensajes solo ASCII. De todos modos, definir esta opcion en elm.rc no es suficiente. El problema es que cuando muestra los mensajes con el paginador incorporado, elm llama a una funcion de biblioteca por cada caracter para determinar si es mostrable o no. Por defecto, esta funcion solo reconoce caracteres ASCII como mostrables, y muestra todos los demas como "^?". Debemos solucionar esto definiendo la variable de entorno LC_CTYPE como ISO-8859-1, _______________________________________________________________________________________________________________13.6. * *Configuracion de elm @ que le indica a la biblioteca que acepte caracteres Latin-1 como mostrables. El soporte para esta y otras caracteristicas esta disponible a partir de la libc-4.5.8. Cuando enviamos mensajes que contienen caracteres especiales del ISO-8859-1, debemos asegurarnos de definir dos variables mas en el fichero elm.rc: charset = iso-8859-1 textencoding = 8bit Esto hace que elm defina el conjunto de caracteres como ISO-8859-1 en el encabezado de correo, y lo envie como valores de 8 bit (el comportamiento por defecto es recortar todos los caracteres a 7 bit). Por supuesto, cualquiera de estas opciones se puede definir tambien en el fichero elmrc privado en lugar de en el global. Capitulo 14 omCo configurar y poner en marcha smail Este capitulo es una breve introduccion a la forma de configurar smail y ademas dara una idea general de la funcionalidad que este programa provee. Aunque smail es muy similar en comportamiento a sendmail, sus archivos de configuracion son totalmente diferentes. El archivo de configuracion principal es /usr/lib/smail /config. Este archivo es el que se debe editar para ajustar los valores especificos al sistema que se esta configurando. Si unicamente es un ordenador terminal de UUCP, seran relativamente pocas las opciones a cambiar. Hay ademas otros archivos que configuran las opciones de encaminamiento y transporte que se pueden modificar; se hablara brevemente sobre la forma de hacerlo. La forma de operacion normal de smail hace que procese y entregue todo el correo de entrada inmediatamente. Si se tiene un trafico relativamente alto, se puede preferir que smail guarde todos los mensajes en una cola, y los procese a intervalos regulares. Cuando se trabaja con correo dentro de una red TCP/IP, es frecuente que smail funcione como demonio: en el momento de arrancar la maquina, se invoca desde el archivo rc.inet2, y se coloca en segundo plano, desde donde espera que haya una conexion TCP que entre por el puerto SMTP (el puerto 25 es lo normal). Este esquema es muy bueno cuando se espera una gran cantidad de trafico, pues smail no se lanza por separado para cada conexion que ingresa. La alternativa es usar a inetd como el administrador del puerto SMTP, y lanzar una copia de smail cada vez que haya una conexion en este puerto. El programa smail tiene muchas opciones que se usan para controlar su comportamiento; describirlas una por una en detalle no es de gran utilidad. Afortunadamente smail tiene varios modos estandar de operacion que se habilitan cuando es invocado con un nombre especifico tal como rmail o smtpd. Es comun que estos nombres especificos sean enlaces 219 _______________________________________________________________________________________________________________14.1. * *Configuracion de UUCP @ simbolicos al binario de smail. Se veran mas deestos cuando se discutan algunas otras caracteristicas de smail. Hay dos enlaces a smail que deben existir siempre: /usr/bin/rmail y /usr/sbin/sendmail.1 Cuando se crea y se envia un mensaje de correo con un agente de usuario tal como elm, el mensaje se pasara a rmail para su entrega, con la lista de destinatarios dada en la linea de comandos. Lo mismo sucede con el correo que entra via UUCP. Algunas versiones de rmail, sin embargo, invocan a /usr/sbin/sendmail en vez de a rmail, por lo que son necesarios ambos enlaces. Por ejemplo, si smail esta en /usr/local/bin, se debe escribir lo siguiente en la linea de comandos: # ln -s /usr/local/bin/smail /usr/bin/rmail # ln -s /usr/local/bin/smail /usr/sbin/sendmail Si se quiere investigar mas sobre los detalles de configuracion de smail, se debe buscar en las paginas del manual smail(1) y smail(5). Si no estuviesen incluidas en su distribucion preferida del Linux, se pueden obtener junto con el codigo fuente de smail. 14.1 Configuracion de UUCP Para usar smail en un entorno que solo tiene UUCP, la instalacion basica es muy sencilla. Primero se debe asegurar de que esten los dos enlaces simbolicos a rmail y sendmail men- cionados anteriormente. Si se espera recibir conexiones de SMTP de otros sitios, tambien se debe hacer un enlace de rsmtp a smail. En la distribucion de smail de Vince Skahan, se encuentra un archivo muestra de con- figuracion. Su nombre es config.sample y esta en /usr/lib/smail. Se debe copiar a config y editarlo para ajustar los valores especificos de su sistema. Suponiendo que su maquina se llama swim.twobirds.com, y esta registrado en los mapas UUCP como swim y su relevo UUCP es ulysses, entonces el archivo config podria ser como el siguiente: # # Los nombres de nuestros dominios visible_domain=two.birds:uucp # _____________________________________________ 1 Esta es la nueva ubicacion estandar de sendmail de acuerdo con el Estandar del Sistema de Archivos de Linux. Otra ubicacion comun es /usr/lib. _______________________________________________________________________________________________________________14.1. * *Configuracion de UUCP @ # Nuestro nombre en los mensajes que viajan al exterior visible_name=swim.twobirds.com # # Tambien se usa este nombre uucp uucp_name=swim.twobirds.com # # Nuestro relevo UUCP smart_host=ulysses La primera instruccion le indica a smail los dominios a los que su sistema pertenece. Se deben insertar sus nombres aqui, separados con signos de punto y coma. Si el nombre de su sistema esta registrado en los mapas de UUCP, sera necesario agregar ademas la palabra uucp. Cuando se manipula un mensaje de correo, smail determina el nombre de su nodo usando una llamada de sistema hostname(2) y revisa la direccion del destinatario con respecto al nombre del nodo, revisando cada uno de los nombres de la lista. Si la direccion coincide con cualquiera de estos nombres, o el nombre del sistema no esta calificado, el receptor se considera local y smail intenta entregar el mensaje a un usuario o alias dentro del sistema local. En cualquier otro caso, el receptor se considera remoto y se intenta entregar al nodo adecuado. La palabra clave visible_name debe contener un solo nombre de dominio totalmente calificado de la maquina que se desea utilizar para los mensajes que se envian hacia afuera. Este nombre se usa cuando se genera la direccion de quien envia el correo en todos los mensajes de salida. Es importante asegurarse de que el nombre que se use sea reconocido por smail como una referencia al sistema local (i.e. el nombre del ordenador con uno de los dominios listados en el atributo visible_domain). Si no se hiciese de esta forma, las respuestas a los mensajes enviados rebotaran hacia afuera del nodo local. Laultima instruccion pone la ruta utilizada para el encaminamiento del relevo UUCP (descrito en la seccion 13.4). Con este cambio mostrado, smail enviara cualquier correo dirigido hacia direcciones remotas al relevo. Como los mensajes seran entregados a traves de UUCP, el atributo debe especificar un sistema conocido para los programas UUCP que corran en su sistema. Consulte el capitulo 12 sobre el tema de como hacer que su nodo sea conocido por UUCP. Hay una opcion que se utiliza en el archivo anterior que aun no ha sido explicada;esta es uucp_name. La razon para utilizar esta opcion es la siguiente: normalmente smail utiliza el valor que devuelve hostname(2) para cosas que hace el UUCP tales como poner en el encabezado From_ el camino de regreso del correo. Si el nombre del nodo no esta registrado en el mapa de UUCP, es necesario indicar a smail que en vez deeste utilice el nombre de dominio completamente calificado.2 Esto se puede hacer agregando la opcion uucp_name al _____________________________________________2 La razon de esto es: Suponga que el nombre de su sistema es monad y que no esta registrado en los _______________________________________________________________________________________________________________14.2. * *Configuracion para una r@ archivo de configuracion config. Hay otro archivo en /usr/lib/smail, que se llama paths.sample. Este es un ejemplo de la forma que tiene un archivo de caminos, paths. Sin embargo, este archivo no es necesario a menos que se tengan enlaces de correo a mas de un lugar. Si fuese necesario hacerlo, se debe escribir uno nuevo o generar uno partiendo de los mapas de Usenet. El archivo paths se describira mas adelante, en este mismo capitulo. 14.2 Configuracion para una red local Si esta funcionando una instalacion con dos o mas nodos conectados por medio de una red local, es necesario designar a uno de ellos para que maneje la conexion UUCP con el mundo exterior. Entre las maquinas de la red local, es muy probable que se quiera intercambiar correo con SMTP sobre TCP/IP. Suponga que se tiene nuevamente el ejemplo de la Cervecera Virtual, y vstout se configura como una pasarela UUCP. En un entorno de red, es preferible mantener todos los archivos con el correo de los usuarios en un solo sistema de archivos, que puede ser montado con NFS desde todas las demas maquinas. Esto permite a los usuarios desplazarse de maquina en maquina sin tener que mover su correo por todos lados (o peor, revisar tres o cuatro ordenadores para ver su correo recien recibido cada ma"nana). Asi mismo, es deseable hacer que las direcciones de los usuarios sean independientes del ordenador en la cual el correo se almacena. Es una practica comun utilizar el nombre del dominio como la direccion de quien envia el correo en vez de utilizar el nombre de la maquina servidora del correo. El usuario Janet, por ejemplo, podria especificar su direccion como janet@vbrew.com en vez de janet@vale.vbrew.com. A continuacion se explicara como hacer que el servidor reconozca el nombre del dominio como un nombre valido para su instalacion. Otra forma de mantener todos los apartados postales en un anfitrion central es utilizar POP o IMAP. POP quiere decir, por sus siglas en ingles Post Office Protocol, es decir, Protocolo de Oficina Postal y permite a los usuarios tener acceso a sus archivos de correo a traves de una conexion TCP/IP. IMAP, o Protocolo de Acceso Interactivo al Correo por sus siglas en ingles de Interactive Mail Access Protocol, es similar a POP, excepto que es mas general. Ambos clientes y servidores para IMAP y POP han sido portados a Linux, y estan disponibles en sunsite.unc.edu bajo el directorio /pub/Linux/system/Network. _____________________________________________ mapas y ademas hay un lugar registrado en los mapas que se llama monad. Cada correo que se dirija a monad!root, aun cuando haya sido enviado desde un vecino directo UUCP, viajara hasta el otro monad. Esto es una molestia para todos. _______________________________________________________________________________________________________________14.2. * *Configuracion para una r@ 14.2.1 Como escribir los archivos de configuracion La configuracion para la Cervecera funciona de la siguiente forma: todos los nodos, con excepcion del servidor de correo vstout, encaminan todo el correo que va hacia el exterior hacia este servidor, utilizando la tecnica de encaminamiento al relevo de correo. vstout encamina todo el correo que va hacia el exterior al verdadero nodo de relevo que, a su vez, envia todo el correo de la Cervecera; esteultimo nodo se llama moria. El archivo estandar config para todas las maquinas con la excepcion de vstout es como sigue: # # Nuestro dominio: visible_domain=vbrew.com # # El nombre que usamos: visible_name=vbrew.com # # Encaminamiento al relevo: via SMTP hacia vstout smart_path=vstout smart_transport=smtp Esto es muy parecido a lo que se ha hecho para configurar un sistema que solo funciona con UUCP. La diferencia principal es que el medio de transporte utilizado para enviar el correo al nodo de relevo es SMTP. El atributo visible_domain hace que smail utilice el nombre del dominio en vez de utilizar el nombre del sistema local en todo el correo de salida. En la pasarela de correo UUCP vstout el archivo config es ligeramente distinto: # # Los nombres de nuestros sistemas: hostnames=vbrew.com:vstout.vbrew.com:vstout # # La forma en que nos llamamos a nosotros mismos: visible_name=vbrew.com # # En el mundo uucp, somos conocidos como vbrew.com uucp_name=vbrew.com # # Transporte inteligente: via uucp hacia moria smart_path=moria smart_transport=uux # _______________________________________________________________________________________________________________14.2. * *Configuracion para una r@ # somos la autoridad para nuestro dominio auth_domains=vbrew.com Este archivo de configuracion, config, utiliza un esquema diferente para indicar a smail como se llama el sistema local. En vez de dar una lista de dominios y permitir que busque el nombre del nodo con una llamada al sistema, se especifica una lista explicitamente. La lista de arriba contiene tanto el dominio completamente calificado como el del sistema no calificado, y el nombre del dominio completo en si mismo. Esto hace que smail reconozca a janet@vbrew.com como una direccion local, y entregue el mensaje a janet. La variable auth_domains indica el nombre de los dominios para los cuales vstout es considerado como autoridad. Esto es, si smail recibe cualquier correo con una direccion hacia host .vbrew.com en donde host no corresponde a ninguna maquina existente, se rechaza el mensaje y se devuelve al remitente del mismo. Si esta linea no esta, cualquier mensaje rechazado sera enviado nuevamente al relevo de correo, quien lo mandara a vstout, y asi sucesivamente hasta que se descarte por exceder la cuenta maxima de saltos. 14.2.2 Como ejecutar smail La primera cosa que se debe hacer es decidir si se ejecutara smail como un demonio inde- pendiente, o si se permitira que inetd administre el puerto SMTP e invoque a smail cuando un cliente solicite una conexion SMTP. Normalmente es preferible la operacion como un demonio independiente en el servidor de correo, debido a que esto carga la computadora menos que lanzar una copia nueva de smail cada vez que se solicite una conexion indivi- dual. Cuando un servidor de correo entrega casi todo el correo que recibe directamente a los usuarios, es preferible optar por la operacion con inetd. Independientemente del modo de operacion que se haya elegido para cada anfitrion in- dividual, es importante asegurarse que se tiene la siguiente linea en el archivo /etc/services: smtp 25/tcp # Simple Mail Transfer Protocol Esto define el numero del puerto TCP que smail utilizara para las conexiones SMTP. 25 es el puerto estandar definido por el RFC de Numeros de Puerto Asignados. Cuando se ejecuta como demonio, smail se coloca a si mismo en segundo plano, y esperara a que ocurra una conexion en el puerto SMTP. Cuando haya una conexion, lanza un proceso y conduce una conversacion SMTP en dicho puerto. El demonio smail se lanza normalmente invocandolo desde el script rc.inet2 con la siguiente instruccion: /usr/local/bin/smail -bd -q15m _______________________________________________________________________________________________________________14.3. * *Si no logra pasar. . . @ El modificador -bd indica que se funcionara como demonio, y -q15m hace que se procesen los mensajes acumulados en la cola cada 15 minutos. Si en cambio, se quiere utilizar inetd, el archivo /etc/inetd.conf debera contener una linea como la siguiente: smtp stream tcp nowait root /usr/sbin/smtpd smtpd smtpd debe ser un enlace simbolico al binario de smail. Recuerde que tiene que forzar a que inetd relea inetd.conf enviandole una se"nal HUP despues de hacer estos cambios. El modo demonio y el modo inetd son mutuamente excluyentes. Si se ejecuta smail como demonio, asegurese de que este comentada cualquier linea en inetd.conf para el servicio smtp. De manera similar, cuando se tenga a inetd como administrador de smail, asegurese de que rc.inet2 no lanza al demonio smail. 14.3 Si no logra pasar. . . Si algo va mal con la instalacion, hay algunas herramientas que pueden ayudar a encontrar cual es la raiz del problema. El primer lugar que se debe revisar es el conjundo de archivos de registro de smail. Estan en /var/spool/smail /log, y se llaman logfile y paniclog, respecti- vamente. El primero lista todas las transacciones, mientras que elultimo solo se usa cuando haya mensajes de error relacionados con errores en la configuracion y similares. Un ejemplo tipico de una linea en el logfile es el siguiente: 04/24/94 07:12:04: [m0puwU8-00023UB] received | from: root | program: sendmail | size: 1468 bytes 04/24/94 07:12:04: [m0puwU8-00023UB] delivered | via: vstout.vbrew.com | to: root@vstout.vbrew.com | orig-to: root@vstout.vbrew.com | router: smart_host | transport: smtp Esto muestra que un mensaje de root a root@vstout.vbrew.com ha sido correcta- mente entregado al sistema vstout a traves de SMTP. Los mensajes que smail no pudo entregar generan una linea similar en el archivo de registro, pero con el mensaje de error en vez de la parte que dice entregado (delivered): _______________________________________________________________________________________________________________14.3. * *Si no logra pasar. . . @ 04/24/94 07:12:04: [m0puwU8-00023UB] received | from: root | program: sendmail | size: 1468 bytes 04/24/94 07:12:04: [m0puwU8-00023UB] root@vstout.vbrew.com ... deferred (ERR_148) transport smtp: connect: Connection refused El error de arriba es tipico para una situacion en la cual smail reconoce correctamente que el mensaje deberia ser entregado a vstout pero que no fue posible establecer la co- nexion al servicio SMTP en vstout. Si esto sucede, es posible que tenga un problema de configuracion o bien que el soporte TCP este ausente de los binarios del smail. Este problema no es tan raro de encontrar. Hay varios binarios de smail que vienen con distribuciones de Linux y que no tienen soporte de red TCP/IP. Si este es su caso, debe recompilar el programa smail. Una vez instalado smail, se debe revisar si se tiene soporte de red TCP haciendo un telnet al puerto SMTP de su maquina. Una conexion exitosa al servidor SMTP se muestra a continuacion (la entrada por teclado se marca con este tipo de letra ): $ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 monad.swb.de Smail3.1.28.1 #6 ready at Sun, 23 Jan 94 19:26 MET QUIT 221 monad.swb.de closing connection Si esta prueba no produce el mensaje de SMTP (la linea que comienza con el codigo 220), debe asegurarse de que su configuracion es verdaderamente correcta antes de recompilar smail, como se describira a continuacion. Si hay algun problema con smail que no se pueda localizar con el mensaje de error que smail genera, se pueden activar los mensajes de depuracion. Para hacer esto, se debe utilizar el modificador -d, seguido de un numero opcional que especifique el nivel de detalle de la informacion (no se debe dejar ningun espacio entre el modificador y el argumento numerico). Entonces, smail mostrara un informe de su operacion en la pantalla que dara mas pistas acerca de lo que puede estar mal. 14.3.1 Como compilar smail Si esta seguro de que su smail carece de soporte de red TCP, es necesario obtener el codigo fuente. Es posible que ya este incluido en su distribucion si la obtuvo en CD-ROM, si no _______________________________________________________________________________________________________________14.4. * *Modos de entrega de corr@ fuese asi, se puede conseguir en la red via FTP.3 La mejor forma de compilar smail, es comenzar con el conjunto de archivos de confi- guracion de la distribucion de Vince Skahan. Para incluir el controlador de TCP dentro de la compilacion, se debe poner la macro DRIVER_CONFIGURATION en el archivo conf/EDITME con el parametro bsd-network o arpa-network. El primero se utiliza para las instalaciones de red local, pero cuando se esta en Internet es necesario usar arpa-network. La diferencia entre estas dos es que la segunda tiene un manejador especial para el servicio BIND que permite reconocer registros MX, lo cual la primera no puede hacer. 14.4 Modos de entrega de correo Como se menciono anteriormente, smail es capaz de entregar los mensajes inmediatamente o encolarlos para un proceso posterior. Si se decide encolar los mensajes, smail guardara todo el correo en el directorio messages debajo de /var/spool/smail. No se procesaran hasta que se le indique explicitamente que lo haga (a este proceso se le conoce como "ejecutar la cola"). Se puede selecionar uno de tres modos de entrega definiendo el atributo delivery_mode en el archivo config para que este como foreground, background, o queued. Es decir, pro- ceso normal, proceso en segundo plano, o proceso en cola. Estas opciones seleccionan la entrega normal (procesamiento inmediato de los mensajes de entrada), en segundo plano (los mensajes son entregados por medio de un hijo del proceso receptor: el proceso padre muere inmediatamente despues de la creacion del hijo), y el encolado. El correo de entrada siempre sera encolado independientemente de esta opcion si la variable booleana queue_only esta puesta en el archivo config. Si se activa el modo de cola, se debe asegurar de que las colas se revisen regularmente; probablemente cada 10 o 15 minutos. Si se ejecuta smail como demonio, se debe agregar la opcion -q10m en la linea de comandos para procesar la cola cada 10 minutos. De forma al- ternativa, se puede invocar runq desde el cron en esos intervalos de tiempo. runq debera ser un enlace a smail. Se puede revisar la cola del correo al invocar smail con la opcion -bp. De manera equivalente, se puede hacer que mailq sea un enlace a smail, e invocar mailq: $ mailq -v m0pvB1r-00023UB From: root (in /var/spool/smail/input) Date: Sun, 24 Apr 94 07:12 MET DST _____________________________________________3 Si compro una distribucion Linux a un proveedor comercial, se puede solicitar el codigo fuente con "un cargo de envio nominal" (que solo cubra los gastos), de acuerdo con las condiciones de copia de smail. _______________________________________________________________________________________________________________14.5. * *Otras opciones del fiche@ Args: -oem -oMP sendmail root@vstout.vbrew.com Log of transactions: Xdefer: reason: (ERR_148) transport smtp: connect: Connection refused Esto muestra un solo mensaje que esta esperando en la cola de mensajes. El registro de transacciones (que solo se mostrara si se da a mailq la opcion -v) puede dar una explicacion adicional de por que el mensaje esta esperando para su entrega. Si aun no se ha intentado entregar el mensaje, no se mostrara la informacion del registro. Aun cuando no se utilice el modo de cola, smail pondra de forma ocasional los mensajes en la cola cuando falle la entrega inmediata por una razon transitoria. Para las conexiones SMTP, esto puede ser debido a que el nodo siguiente sea un inalcanzable; pero los mensajes pueden tambien ser pospuestos cuando el sistema de archivos del receptor este lleno. En cualquier caso, debe poner una cola que se revise, por ejemplo, cada hora (utilizando runq), porque si no, cualquier mensaje pospuesto se quedara encolado indefinidamente. 14.5 Otras opciones del fichero config Hay otras muchas opciones en el archivo config, algunas poco usadas en sistemas sencillos. Sin embargo, mencionaremos algunas que si que seranutiles con frecuencia: error_copy_postmaster Si esta variable boleana se pone, cualquier error generara un mensaje al administrador de correo. Normalmente esto solo se hace para los errores que se deben a una configuracion incorrecta. La variable puede activarse poniendola en el archivo config, precedida por un signo de suma (+). max_hop_count Si la cuenta de saltos para un mensaje (i.e. el numero de nodos que se han atravesado) es igual o excede a este numero, los intentos de entrega produciran un mensaje de error que sera enviado a quien genero el mensaje. Esto se utiliza para prevenir que los mensajes entren en un ciclo infinito. La cuenta de saltos se calcula generalmente a partir del numero de campos Received: que se encuentran en el encabezado del correo. Ademas, esta cuenta tambien puede ser ajustada de forma manual utilizando la opcion -h en la linea de comandos. Esta variable tiene como valor por defecto 20. postmaster La direccion del administrador de correo. Si la direccion Postmaster no puede ser resuelta como direccion local valida, entoncesesta se utiliza como _______________________________________________________________________________________________________________14.6. * *Encaminamiento de mensaj@ ultimo recurso. El valor por defecto es root. 14.6 Encaminamiento de mensajes y entrega smail divide la entrega del correo en tres partes, la ruta, el modulo de entrega local y el modulo de transporte. El modulo de encaminamiento resuelve todas las direcciones remotas, determinando el nodo al que el mensaje sera enviado y el transporte que sera utilizado. Dependiendo de la naturaleza del enlace, se utilizaran transportes diferentes tales como UUCP o SMTP. Las direcciones locales se dan al modulo de entrega local que resuelve cualquier reenvio o alias. Por ejemplo, la direccion podria ser un alias o una lista de correo, o el usuario podria querer reenviar su correo a otra direccion. Si la direccion resultante es remota, se maneja de nuevo en el modulo de encaminamiento, de otra forma se asigna a un transporte para su entrega local. Normalmente, la accion a realizar sera entregar a un archivo de correo, pero los mensajes tambien pueden ser pasados a la entrada de un comando (por ejemplo, un filtro de correo que el usuario quiera establecer) o agregados a un archivo arbitrario cualquiera. El modulo de transporte, finalmente, es el responsable de la entrega, independientemente del metodo que se haya escogido. Intenta entregar el mensaje y en caso de problemas, puede devolver un mensaje al remitente o posponer la entrega para intentarlo de nuevo mas tarde. Con smail se tiene mucha flexibilidad para configurar estas tareas. Para cada una de ellas, hay varios controladores4 disponibles, de los cuales se puede elegir el mas adecuado. Se debe indicar a smail la eleccion a traves de los siguientes archivos: routers, directors y transports, que se encuentran en /usr/lib/smail. Si estos archivos no existiesen, se toman valores por defecto razonables que funcionan en la mayor parte de los sistemas que utili- zan SMTP o UUCP como transporte. Si se quiere cambiar la politica de encaminamiento de smail, o modificar un transporte, es conveniente obtener los archivos ejemplo que vie- nen con la distribucion de los programas fuente de smail 5, copiar los archivos ejemplo a /usr/lib/smail, y modificarlos de acuerdo con sus necesidades. Los archivos de ejemplos de configuracion estan tambien en el Apendice B. _____________________________________________4 Aqui, conocemos por controladores a los distintos modulos internos de smail capaces de utilizar un metodo de entrega de mensajes u otro. Asi, tenemos controladores para UUCP o para SMTP 5 Los archivos de configuracion por defecto se encuentran en samples/generic bajo el subdirectorio de los programas fuente. _______________________________________________________________________________________________________________14.7. * *Mensajes de encaminamien@ 14.7 Mensajes de encaminamiento Cuando se le da un mensaje, smail revisa primero si el destino esta en el sistema local o en un nodo remoto. Si la direccion del ordenador destino corresponde a uno de los nodos locales configurados en el archivo config, el mensaje es tratado por el modulo de entrega local. Si no fuese asi, smail transmite la direccion del destino a varios controladores de encaminado para encontrar a que maquina se debe transmitir el mensaje. Los controladores se pueden indicar en el archivo routers; si este archivo no existe, se utiliza un conjunto de encaminadores por defecto. El nodo destino se pasa a todos los encaminadores por turno, y aquel que encuentra la ruta mas especifica es seleccionado. Por ejemplo, suponga que hay un mensaje dirigido a joe@foo.bar.com y que un encaminador conoce una ruta para todos los nodos que perte- necen al dominio bar.com, mientras que otro tiene la informacion sobre el camino directo al sistema foo.bar.com. Como el segundo es mas especifico, es elegido sobre el primero. Si hubiese dos encaminadores que proveen una solucion correcta e igual de especifica, se elige al primero que este en el archivo routers. A continuacion, el encaminador elegido especifica que transporte utilizara, por ejemplo UUCP, y genera asi una nueva direccion destino. La nueva direccion se pasa al transporte junto con el nombre del sistema a quien se le debe pasar el mensaje. En el ejemplo anterior, smail podria encontrar que foo.bar.com se puede encontrar via UUCP utilizando la trayec- toria ernie!bert. Asi generara un nuevo destino bert!foo.bar.com!user, y utilizara esta direccion, a traves del transporte UUCP, como la que sera transmitida a ernie. Cuando se utilice la configuracion por defecto, los siguientes encaminadores estaran disponibles: o Si la direccion del nodo destino se puede resolver utilizando las llamadas de biblioteca gethostbyname(3) o gethostbyaddr(3), el mensaje sera entregado via SMTP. Launica excepcion es si la direccion que se encuentra se refiere al sistema local, en cuyo caso sera enviado al modulo de entrega local. smail tambien reconoce las direcciones IP escritas como cuarteto de puntos como nombre legal de maquina, siempre y cuando pueda ser resuelto a traves de una llamada a gethostbyaddr(3). Por ejemplo scrooge@[149.76.12.4] podria ser valida aunque muy rara como direccion para scrooge en quark.physics.groucho.edu. Si su maquina esta en el Internet, estos encaminadores no son lo que usted necesita, debido a que no soportan registros MX. Vea mas adelante lo que se debe hacer en este caso. o Si la base de datos de alias de trayectorias, /usr/lib/smail /paths existe, smail tra- tara de buscar en el archivo al nodo destino (restandole la extension .uucp si la _______________________________________________________________________________________________________________14.7. * *Mensajes de encaminamien@ hubiera). El correo a una direccion que coincida con este encaminador sera entregado utilizando UUCP, a traves de la trayectoria que se haya encontrado en la base de datos. o La direccion del nodo (restandole la extension .uucp si la hubiera) se compara con la salida de la instruccion uuname para revisar si el sistema destino es un vecino UUCP. Sieste es el caso, el mensaje sera entregado utilizando el transporte UUCP. o Si la direccion no coincide en ninguno de los encaminadores citados anteriormente, sera entregado utilizando un relevo de correo. La trayectoria al nodo de relevo asi como el medio de transporte que sera utilizado se ponen en el archivo config. Los valores por defecto funcionan para la mayor parte de las instalaciones sencillas, pero no sonutiles si las necesidades de encaminamiento son algo mas complejas. Si se enfrenta con uno de los problemas que se discutiran a continuacion, es necesario instalar su propio archivo routers para cambiar los valores por defecto. Un archivo ejemplo routers con el que se puede empezar esta en el apendice B. Algunas distribuciones de Linux traen ademas, un conjunto de archivos de configuracion hechos a la medida para solventar esas dificultades. Es probable que el peor de los problemas surja cuando su maquina viva en un universo dual con enlaces de marcado telefonico via IP y UUCP. Entonces se tendran nombres de nodos en el archivo hosts con los cuales solo se comunica ocasionalmente a traves de un enlace SLIP, y smail intentara entregar cualquier correo por medio de estos sistemas usando SMTP. Este comportamiento no es deseable normalmente debido a que, si el enlace SLIP se activa de forma regular, SMTP es mucho mas lento que mandar el correo con UUCP. Con los valores por defecto, no se puede evitar que smail se porte mal. Este problema se puede evitar revisando con smail el archivo paths antes de preguntar por el sistema de resolucion, y poner a todos los nodos a los que se quiera forzar la entrega via UUCP en el archivo paths. Si nunca se quiere enviar ningun mensaje sobre SMTP, se pueden eliminar poniendo como comentarios todos los encaminadores que estan basados en el sistema de resolucion. Otro problema es que las opciones por defecto no proporcionan encaminado de correo Internet verdadero, debido a que un encaminador basado en un DNS no evalua los registros MX. Para habilitar el soporte completo para el encaminamiento de correo Internet, es necesario eliminar al encaminador poniendolo como comentario, y quitar el comentario de aquel que utiliza BIND. Sin embargo, algunas distribuciones de Linux incluyen binarios de smail que no tienen el soporte para BIND incluido y, si se habilita BIND, se obtendra un mensaje en el archivo paniclog que dice "router inet_hosts: driver bind not found", es decir, "no se encuentra el controlador de bind", por lo que sera necesario obtener el codigo fuente y recompilar smail (vea la seccion 14.2 mas arriba). _______________________________________________________________________________________________________________14.8. * *Como entregar mensajes a@ Para concluir, generalmente no es buena idea utilizar el controlador uuname. Por una parte, generara un error de configuracion cuando no se tenga UUCP instalado, debido a que no encontrara al programa uuname. Por la otra, es que se tienen mas sistemas listados en su archivo Systems de UUCP que aquellos con los que se mantiene correo. Estos pueden ser nodos con los cualesunicamente se intercambian noticias, o sistemas de los cuales se bajan archivos ocasionalmente via UUCP anonimo, pero no se tiene mas trafico queeste. Para resolver el primer problema, se puede sustituir el programa uuname con un script que haga un simple exit 0. La solucion mas general es, sin embargo, editar el archivo routers y borrar todo el driver. 14.7.1 La base de datos de trayectorias paths El programa smail espera encontrar una base de datos de alias de trayectorias en el archivo paths en el subdirectorio /usr/lib/smail. Este archivo es opcional, por lo que si no se quiere hacer ningun encaminamiento por medio de alias de trayectorias, simplemente se borra el archivo paths. El archivo paths debe ser un archivo ASCII ordenado que contiene lineas que mapeen los nombres de los nodos destino a trayectorias UUCP con signos de admiracion. El archivo tiene que estar ordenado debido a que smail utiliza busqueda binaria para encontrar un sitio. No se permiten comentarios en este archivo, y el nombre del sitio debe estar separado de la trayectoria utilizando un caracter de tabulacion. Las bases de datos de alias de trayectorias se discuten con mas detalle en el capitulo 13. Si se genera este archivo a mano, es importante asegurarse de incluir todos los nombres validos para un sistema. Por ejemplo, si a una maquina se le conoce por un nombre simple UUCP y un nombre de dominio totalmente calificado, se debe a"nadir una linea para cada uno de ellos. El archivo debe estar ordenado (para ello, enviarlo al comando sort(1)). Si su nodo es simplemente terminal, no sera necesario tener un archivo paths: basta con ajustar los atributos de nodo de relevo en su archivo config, y dejarle todo el trabajo de encaminamiento que su correo genere. 14.8 Como entregar mensajes a las direcciones locales Es comun que una direccion local de correo sea solo el nombre del usuario, en cuyo caso el mensaje se entrega en su archivo de correo, /var/spool/mail /usuario. En otros casos se incluyen alias y nombres de la lista de correo, y correo redirigido por el usuario. En estos casos, la direccion local se expande a una nueva lista de direcciones que pueden ser locales o remotas. _______________________________________________________________________________________________________________14.8. * *Como entregar mensajes a@ Independientemente de estas direcciones "normales", smail puede manejar otros tipos de destino para los mensajes locales tales como nombres de archivos o comandos (que reciben el mensaje por su entrada estandar). Estas no son propiamente direcciones, de tal forma que no se puede mandar correo, por ejemplo a /etc/passwd@vbrew.com; solo son validas si se han tomado de un archivo alias o de redireccionamiento. Un nombre de archivo es cualquier cosa que comience con una diagonal (/ ) o un tilde (~ ). El segundo se refiere al directorio inicial del usuario, y es posible solo si el nombre del archivo ha sido tomado de .forward o una linea de redireccion del archivo de correo (ver mas abajo). Cuando smail manda el mensaje a un archivo, lo a"nade al final del archivo y, de ser necesario, lo puede tambien crear. Una instruccion por tuberia puede ser cualquier comando un?x precedido por el simbolo (|). Esto hace que smail envie el comando al shell junto con sus argumentos, pero sin el `|' que lo encabeza; pasando el mensaje a la entrada estandar del comando. Por ejemplo, para meter una lista de correo en un grupo de noticias local, se podria utilizar un script llamado gateit y configurar un alias local que entregue todos los mensajes de esta lista de correo al script, utilizando "_gateit ". Si la invocacion contiene un espacio en blanco, se debe encerrar entre comillas dobles. Debido a los problemas de seguridad que pueden ser ocasionados aqui, es importante cuidar que no se ejecute el comando si la direccion ha sido obtenida de alguna forma dudosa (por ejemplo, si el archivo de alias del cual la direccion se ha obtenido puede ser escrito por cualquiera). 14.8.1 Usuarios locales El caso mas comun para una direccion local es mostrar el archivo de correo del usuario. Este apartado postal esta en /var/spool/mail y tiene el nombre del usuario. Tambien es propiedad deeste, con grupo mail y tiene el modo 660. Si no existe, smail lo crea. Observe que aunque /var/spool/mail es el lugar estandar para poner los archivos de correo, algunas aplicaciones tienen diferentes trayectorias compiladas en ellos, por ejemplo /usr/spool/mail. Si la entrega a los usuarios en su sistema falla constantemente, se puede intentar hacer un enlace simbolico a /var/spool/mail para ver si esta situacion mejora. Hay dos direcciones que smail necesita para funcionar: MAILER-DAEMON y Post- master. Cuando se devuelve un mensaje de informe debido a un correo que no pudo ser entregado, se envia una copia a la cuenta del administrador postal (el postmaster) para su revision (en el caso de que este mensaje pudiera ser debido a un problema de configuracion). El usuario MAILER-DAEMON se utiliza como la direccion del remitente del mensaje devuelto. _______________________________________________________________________________________________________________14.8. * *Como entregar mensajes a@ Si estas direcciones no tienen nombres de cuentas validas en su sistema, smail mapea implicitamente MAILER-DAEMON a postmaster, y postmaster a root. Es conve- niente cambiar esto dandole un alias postmaster al responsable del mantenimiento de los programas de correo. 14.8.2 Reenvio Un usuario puede redirigir su correo a una direccion alternativa utilizando uno de los dos metodos que soporta smail. Una opcion es poner Forward to receptor ,... en la primera linea de su archivo de correo. Esto enviara todo el correo que se reciba a la lista de receptores especificada alli. La otra es crear un archivo .forward en el directorio principal del usuario, que contenga una lista de los receptores separados por comas. Con este sistema de redireccionamiento, todas las lineas del archivo son leidas e interpretadas. Observe que cualquier tipo de direccion puede ser utilizada. Asi, un ejemplo practico del archivo .forward para cuando se tome unas vacaciones puede ser janet, "|vacation" La primera direccion entrega el mensaje que llega al archivo de correo de janet, mientras que la instruccion vacation provoca la devolucion de un mensaje que informa al remitente que janet esta de vacaciones. 14.8.3 Archivos de alias El programa smail entiende los archivos de alias compatibles con los del sendmail de Ber- keley. Las lineas en el archivo de alias pueden ser de la forma alias: receptores receptores es una lista de direcciones separadas por comas que sera sustituida por el alias. La lista de receptores puede continuar a traves de varias lineas si la siguiente linea comienza con un caracter de tabulacion. _______________________________________________________________________________________________________________14.8. * *Como entregar mensajes a@ Hay una caracteristica especial que permite que smail maneje listas de correo desde un archivo de alias: si se especifica ":include:nombrearchivo " como receptor, smail leera el archivo especificado, y sustituira su contenido con una lista de receptores. El archivo de alias principal es /usr/lib/aliases. Si se decide hacerlo escribible por todo el mundo, smail no entregara ningun mensaje a los comandos de shell que pudiese contener el archivo. Un archivo de ejemplo se muestra a continuacion: # vbrew.com archivo /usr/lib/aliases hostmaster: janet postmaster: janet usenet: phil # La lista de correo de desarrollo de programas. development: joe, sue, mark, biff /var/mail/log/development owner-development: joe # Los anuncios de interes general seran enviados # a todo el personal (lista staff) announce: :include: /usr/lib/smail/staff, /var/mail/log/announce owner-announce: root # pasarela a la lista de correos foobar a un grupo de noticias local ppp-list: "|/usr/local/lib/gateit local.lists.ppp" Si hay un error cuando se entrega a una direccion generada por el archivo aliases, smail intentara enviar una copia del mensaje de error al "due"no del alias". Por ejemplo, si la entrega a biff no se logra cuando se envio un mensaje a la lista de correo development, se enviara una copia del mensaje de error al remitente, asi como tambien al postmaster y a owner-development. Si la direccion del due"no no existe, no se generara el mensaje de error adicional. Cuando se entrega a un archivo o cuando se invocan programas en el archivo aliases, smail se convierte en el usuario nobody para evitar problemas de seguridad6. En especial cuando se entrega a un archivo esto constituye una verdadera molestia. En el archivo de ejemplo que se dio anteriormente, los archivos de registro .log deben ser propiedad y ser escribibles por el usuario nobody, o la entrega hacia ellos fallara. _____________________________________________6 N. del T.: nobody significa nadie, y es un usuario que se utiliza cuando no se identifica al due"no de un proceso, y si bien se desea su ejecucion, tambien es cierto que no deseamos crear un agujero en nuestros mecanismos de seguridad, por lo cual nobody es un usuario con los privilegios reducidos al minimo. _______________________________________________________________________________________________________________14.9. * *Transportes basados en U@ 14.8.4 Listas de correo En vez de utilizar el archivo aliases, las listas de correo tambien pueden ser administradas por medio de archivos en el directorio /usr/lib/smail /lists. Una lista de correo llamada nag- bugs se debe describir en el archivo lists/nag-bugs, el cual debera contener las direcciones de los miembros separadas por comas. La lista puede estar en varias lineas, con lineas de comentarios que comienzan con el simbolo #. Para cada lista de correo, un usuario (o alias) llamado owner-nombredelista debe existir; cualquier error que ocurra cuando se resuelva una direccion sera enviado a este usuario. Esta direccion se usa tambien como la direccion del remitente en todos los mensajes de salida en el campo de encabezado Sender:. 14.9 Transportes basados en UUCP Hay varios transportes compilados en smail que utilizan el conjunto de programas UUCP. En un entorno UUCP, los mensajes se pasan normalmente al invocar rmail en el siguiente nodo, dandole el mensaje en la entrada estandar y la direccion a quien va dirigido en la linea de argumentos. En el sistema, rmail debera ser un enlace al programa smail. Cuando se maneja un mensaje con el transporte UUCP, smail convierte la direccion destino a una trayectoria UUCP con simbolos de admiracion. Por ejemplo, user@host se transformara en host!user. Cualquier ocurrencia del operador de direcciones `%' sera con- servada, de tal forma que user%host@gateway se convertira en gateway!user%host. Sin embargo, mail nunca generara esa direccion por si mismo. De manera alternativa, smail puede enviar y recibir lotes de BSMPT via UUCP. Con BSMTP, uno o mas mensajes son empaquetados en un solo lote que contiene las instruc- ciones para que el controlador del correo local funcione como si se hubiera establecido una conexion SMTP real. BSMTP se utiliza frecuentemente en redes de guardar-y-enviar (por ejemplo las basadas en UUCP) para ahorrar espacio en disco. El archivo de ejemplo transports del apendice B contiene un transporte doblado bsmtp que genera lotes parcia- les BSMTP en un directorio de colas. Luego, deben ser combinados en los lotes finales utilizando un script de shell que agrega las instrucciones apropiadas HELO y QUIT. Para habilitar el transporte bsmtp para enlaces UUCP especificos se deben utilizar los archivos llamados metodo (revise la pagina del manual smail(5) para mas detalles). Si se tieneunicamente un enlace UUCP, y se utiliza un encaminado a relevo, se puede habilitar el envio de lotes SMTP poniendo la variable de configuracion smart_transport a bsmtp en vez de uux. _______________________________________________________________________________________________________________14.10. * * Transportes basados en @ Para recibir lotes SMTP sobre UUCP, se debe asegurar que se tiene el mismo programa de decodificacion de lotes que el sistema remoto que envia los lotes. Si el nodo remoto utiliza smail tambien, es necesario hacer un enlace llamado rsmtp a smail. Si el sistema remoto corre sendmail, se debe ademas instalar un script llamado /usr/bin/bsmtp que haga un simple "exec rsmtp" (una enlace simbolico no funcionara). 14.10 Transportes basados en SMTP El smail soporta actualmente un controlador de SMTP para entregar el correo sobre cone- xiones TCP.7 Es capaz de entregar un mensaje a cualquier numero de direcciones de una maquina, con el nombre de la misma especificado como nombre de dominio totalmente cali- ficado que puede ser resuelto por el software de red, o con la notacion de cuarteto de puntos encerrados entre corchetes. En general, las direcciones se resuelven con los controladores de encaminamiento del BIND, gethostbyname(3), o gethostbyaddr(3) que lo entregaran al transporte SMTP. El manejador de SMTP intentara conectarse al sistema remoto inmediatamente a traves del puerto smtp como esta listado en /etc/services. Si no puede ser alcanzado, o expira el tiempo maximo de espera, la entrega del correo se reintentara posteriormente. La entrega en Internet requiere que las rutas al nodo destino esten especificadas en el formato route-addr descrito en el capitulo 13, en vez de utilizar una trayec- toria de signos de admiracion.8 smail transformara user%host@gateway, en don- de gateway se alcanza via host1!host2!host3, en la direccion de la ruta-fuente <@host2,@host3:user%host@gateway> la cual sera enviada como la direccion del remi- tente a host1. Para habilitar dicha transformacion (utilizando el controlador incluido de BIND), se debe editar la linea del controlador smtp en el archivo transports. Un archivo de muestra transports se da en el Apendice B. 14.11 Calificacion de nombre de anfitrion Algunas veces se desean capturar los nombres de sistema no calificados (i.e. aquellos que no tienen un nombre de dominio) escritos en la direccion del remitente o del receptor, por ejemplo cuando se pasa a traves de dos redes, en donde una requiere de nombres de dominio totalmente calificados. En un relevo Internet-UUCP, los nombres de nodo no calificados _____________________________________________7 Los autores llaman a este soporte "simple". Para una version futura de smail, han anunciado un mecanismo completo que menejara esto de manera mas eficiente. 8 Sin embargo, el uso de rutas en Internet se desaconseja totalmente. En cambio, se deben utilizar nombres de dominio totalmente calificados. _______________________________________________________________________________________________________________14.11. * * Calificacion de nombre @ deben ser mapeados al dominio uucp por defecto. Cualquier otro cambio de direccion distinto a los anteriores son cuestionables. El archivo /usr/lib/smail /qualify indica a smail que nombres de dominios debe cambiar a que nombres de nodo. Las lineas del archivo qualify consisten en el nombre del sistema comenzando en la columna uno, seguidos del nombre del dominio. Las lineas conteniendo un simbolo # como su primer caracter no blanco se consideran comentarios. Las lineas se buscan en el orden en el que aparecen. Si no existe el archivo qualify, no se hace ninguna calificacion de nombres de nodos. Un nombre de anfitrion especial (*) indica que todos son nombres de nodos. Asi, se puede habilitar un mapeo a todos los sistemas no mencionados antes en un dominio por defecto. Debe ser utilizado solo en laultima linea. En la Cervecera Virtual, todos los sistemas han sido configurados para utilizar nombres de dominio totalmente calificados en las direcciones de los remitentes. Las direcciones de los receptores no calificadas se considera que estan en el dominio uucp, de tal forma que solo una linea en el archivo qualify es necesaria. # /usr/lib/smail/qualify, cambiado por janet el 12 Feb 1994 # * uucp Capitulo 15 Sendmail+IDA 15.1 Acerca del autor Vince Skahan (vince@victrola.wa.com) ha estado administrando un gran numero de sistemas unix desde 1987, y actualmente hace funcionar sendmail+IDA en aproximadamente 300 estaciones de trabajo unix para unos 2000 usuarios. Admite haber perdido considerablemente el sue"no editando unos cuantos ficheros send- mail.cf "por la fuerza bruta" antes de descubrir sendmail+IDA en 1990. Admite asimismo que aguarda ansiosamente la llegada de la primera version en Perl de sendmail, para todavia mayor disfrute. 15.2 Reconocimientos Gracias a Neil Rickert y Paul Pomes por la gran cantidad de ayuda proporcionada a lo largo de los a"nos en lo que se refiere al cuidado y mantenimiento de sendmail+IDA y a Rich Braun por hacer el porte inicial a Linux. Las mayores gracias son de lejos para mi mujer Susan, por todo el apoyo en este y otros proyectos. 15.3 Introduccion a Sendmail+IDA Se dice que no se es un verdadero administrador de sistemas Unix hasta que se haya editado el archivo sendmail.cf. Se dice asimismo que se esta loco si se intenta hacer dos veces. Sendmail es un programa increiblemente potente. Y tambien, para la mayoria de la gente, increiblemente dificil de aprender y comprender. Un programa cuyo manual de refe- 239 _______________________________________________________________________________________________________________15.4. * *Archivos de configuracio@ rencia definitiva ocupa 792 paginas es suficiente para espantar justificadamente a cualquiera. (Sendmail, editado por O'Reilly and Associates) Con sendmail+IDA es distinto. Se elimina la necesidad de editar el siempre criptico archivo sendmail.cf, permitiendo al administrador definir la configuracion de las rutas y direcciones particulares de una maquina especifica, por medio de archivos de apoyo relati- vamente sencillos de entender, llamados tables. Cambiar a sendmail+IDA puede ahorrarle muchas horas de trabajo y estres. En comparacion con los demas agentes principales de transporte de correo, es probable que no haya nada que no se pueda hacer mas rapida y facilmente que con sendmail+IDA. Las actividades mas comunes, necesarias para hacer funcionar sistemas Internet o UUCP usuales, pasan a ser tareas faciles de llevar a cabo. Configuraciones que normalmente serian extremadamente dificiles, son ahora simples de crear y mantener. Cuando se escribio este manual, la version actual de sendmail5.67b+IDA1.5 estaba disponible por FTP anonimo en vixen.cso.uiuc.edu. Esta version compila sin parches ni modificaciones bajo Linux. Todos los archivos de configuracion necesarios para poder compilar, instalar y hacer funcionar los fuentes de sendmail+IDA bajo Linux se hallan en el archivo newspak-2.2.tar.gz, disponible por FTP anonimo en sunsite.unc.edu, en el directorio /pub/Linux/system/Mail. 15.4 Archivos de configuracion _ Preliminares El sendmail tradicional se configura a traves de un archivo de configuracion de sistema (tipicamente /etc/sendmail.cf o /usr/lib/sendmail.cf ), que no se asemeja ni de lejos a cualquier otro lenguaje que haya podido ver antes. Editar el archivo sendmail.cf para proporcionar un comportamiento personalizado puede ser una experiencia humillante. Sendmail+IDA hace que este suplicio sea algo del pasado, siendo todas las opciones de configuracion controladas por ficheros con formato de listados (tables), con una sintaxis bastante facil de comprender. Estas opciones son configuradas mediante el procesado de ciertos archivos de informacion, que son proporcionados con los fuentes, via "Makefiles" que invocan a m4 (analizador de macros) o dbm (procesador de bases de datos). El archivo sendmail.cf defineunicamente el comportamiento por omision del sistema. Virtualmente, todos los ajustes especiales se hacen a traves de un numero de tablas opcio- nales en vez de editar directamente el archivo sendmail.cf. La figura 15.1 muestra todas las _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ tablas que utiliza sendmail. mailertable define un comportamiento especial para nodos o dominios remo- tos. uucpxtable fuerza a UUCP a entregar el correo a los nodos que estan en formato DNS. pathtable define rutas de rebote UUCP a nodos o dominios remotos. uucprelays cortocircuita el camino pathalias a nodos remotos bien conocidos. genericfrom convierte direcciones internas a genericas visibles para el mundo exterior. xaliases convierte direcciones genericas de/a direcciones internas validas. decnetxtable convierte direcciones RFC-822 a direcciones de tipo DECnet. Figura 15.1: Archivos de apoyo de sendmail. 15.5 El archivo sendmail.cf El archivo sendmail.cf que utiliza sendmail+IDA no se edita directamente, sino que se genera desde un archivo de configuracion m4 proporcionado por el administrador del sistema local. De aqui en adelante, siempre nos referiremos ael simplemente como sendmail.m4. Este archivo contiene algunas definiciones y en otros casos simplemente apunta a las tablas en donde se lleva realmente a cabo el trabajo. En general, solo es necesario especificar: o las trayectorias y nombres de archivos utilizados en el sistema local. o el o los nombres de los sistemas conocidos para propositos e-mail. o cual sera el gestor de correo por defecto deseado (y quiza tambien algun nodo inteli- gente de reenvio 1 de correo) Hay una gran variedad de parametros que pueden ser definidos para establecer el com- portamiento del sistema local o para ir mas alla del comportamiento precompilado. Estas opciones de configuracion se identifican en el archivo ida/cf/OPTIONS del directorio fuente. _____________________________________________1 N. del T.: estos nodos se conocen tambien como relevos, del ingles relay _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ Un archivo sendmail.m4 para una configuracion minima (UUCP o SMTP confiando todo el correo externo a anfitriones inteligentes conectados directamente) puede ser tan escueto como 10 o 15 lineas de texto excluyendo los comentarios. 15.5.1 Un ejemplo del archivo sendmail.m4 A continuacion se muestra un ejemplo del archivo sendmail.m4 para vstout en la Cervecera Virtual. vstout utiliza SMTP para hablar con todos los anfitriones de la red local de la Cervecera, y envia todo el correo para otros destinos a moria, su nodo de reenvio de Internet, via UUCP. 15.5.2 Parametros de uso comun en sendmail.m4 Algunas partes del archivo sendmail.m4 son necesarias siempre; otras pueden ser ignoradas si se acepta la configuracion por defecto. Las siguientes secciones describiran cada una de las partes del archivo ejemplo sendmail.m4 con mas detalle. Partes que definen los directorios dnl #define(LIBDIR,/usr/local/lib/mail)dnl # el directorio en donde estan # los archivos de soporte LIBDIR define el directorio en donde sendmail+IDA espera encontrar los archivos de configuracion, las diversas tablas dbm, y definiciones especiales de indole local. En una tipica distribucion ejecutable, esto esta ya compilado en el ejecutable de sendmail y no es necesario ponerlo explicitamente en el archivo sendmail.m4. El ejemplo anterior tiene una linea inicial dnl que significa que esta linea es unica y esencialmente un comentario informativo. Para modificar la localizacion de los archivos de soporte a un lugar distinto, elimine el dnl inicial de la linea superior, y ajuste el directorio deseado, luego recompile y reinstale el archivo sendmail.cf. Como definir un sistema de correo local (mailer) define(LOCAL_MAILER_DEF, mailers.linux)dnl # gestor de correo para entrega local _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ dnl #------------------ EJEMPLO DE UN ARCHIVO SENDMAIL.M4 --------- dnl # (la cadena 'dnl' es la forma de escribir un comentario en m4) dnl # en general usted no debera ignorar LIBDIR de las trayectorias compiladas dnl #define(LIBDIR,/usr/local/lib/mail)dnl # lugar de los arch. de soporte define(LOCAL_MAILER_DEF, mailers.linux)dnl # gestor de correo para la # entrega local define(POSTMASTERBOUNCE)dnl # el gestor de correo obtiene los rebotes define(PSEUDODOMAINS, BITNET UUCP)dnl # no intente usar DNS # en estos casos dnl #------------------------------------------------------------- dnl # define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com) dnl # los nombres seran conocidos por define(DEFAULT_HOST, vstout.vbrew.com)dnl # nuestro nombre primario, # 'nombre' para el correo define(UUCPNAME, vstout)dnl # nuestro nombre uucp dnl # dnl #------------------------------------------------------------- dnl # define(UUCPNODES, |uuname|sort|uniq)dnl # nuestros vecinos uucp define(BANGIMPLIESUUCP)dnl # aseguran que el correo define(BANGONLYUUCP)dnl # uucp sea tratado correctamente define(RELAY_HOST, moria)dnl # nuestro sistema de # relevo inteligente define(RELAY_MAILER, UUCP-A)dnl # alcanzamos moria via uucp dnl # dnl #-------------------------------------------------------------------- dnl # dnl # varias tablas de busqueda dbm dnl # define(ALIASES, LIBDIR/aliases)dnl # alias del sistema define(DOMAINTABLE, LIBDIR/domaintable)dnl # distribucion de dominios # entre nodos define(PATHTABLE, LIBDIR/pathtable)dnl # base de datos de trayectorias define(GENERICFROM, LIBDIR/generics)dnl # directorio generico # de direcciones define(MAILERTABLE, LIBDIR/mailertable)dnl # gestores de correo por # nodo o dominio define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # trayectorias a los nodos # que alimentamos define(UUCPRELAYS, LIBDIR/uucprelays)dnl # trayectorias de cortocircuito dnl # dnl #-------------------------------------------------------------------- dnl # dnl # incluye el codigo 'real' que hace que todo funcione dnl # (provisto con el codigo fuente) dnl # include(Sendmail.mc)dnl # LINEA INDISPENSABLE !!! dnl # dnl #------------ FIN DEL ARCHIVO EJEMPLO DE SENDMAIL.M4 ------- Figura 15.2: Un archivo muestra de sendmail.m4 para vstout. _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ La mayor parte de los sistemas operativos tienen un programa encargado de la gestion de correo local. Los programas mas comunes para la mayor parte de las variantes de Unix estan ya compiladas en el ejecutable de sendmail. En Linux, es necesario definir explicitamente el gestor local de correo correspondiente, ya que, en algunas distribuciones, puede no estar incluido. Esto se lleva a cabo especificando LOCAL_MAILER_DEF en el fichero sendmail.m4 Por ejemplo, para que el popular programa deliver 2 gestione este servicio, se debe espe- cificar en LOCAL_MAILER_DEF mailers.linux. El siguiente archivo debera ser instalado como mailers.linux en el directorio al que apunta LIBDIR. Esto define explicitamente el programa deliver, como gestor de correo interno Mlocal ; por lo que con los parametros adecuados, sendmail se encargara de entregar correctamente el correo cuyo destino es el sistema local. A menos que se sea un experto de sendmail, es probable que no se desee modificar el siguiente ejemplo. # -- /usr/local/lib/mail/mailers.linux -- # (gestores de correo locales para su uso en Linux) Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=10, A=sh -c $u Hay tambien una opcion compilada por defecto para deliver en el archivo sendmail.mc incluida en el archivo sendmail.cf. Si se opta por ella, se debe evitar el uso del archivo mailers.linux y en cambio definir lo siguiente en el archivo sendmail.m4 : dnl --- (en sendmail.m4) --- define(LOCAL_MAILER_DEF, DELIVER)dnl # gestor de correo para entrega local Desafortunadamente, Sendmail.mc asume que el programa deliver esta instalado en /bin, lo cual no es el caso con Slackware 1.1.1 (que lo instala en /usr/bin). En este caso es necesario, ya sea enga"narlo con un enlace simbolico o recompilar deliver a partir del codigo fuente para que resida en /bin. Gestion de correo rechazado define(POSTMASTERBOUNCE)dnl # el correo rechazado ira dirigido # al postmaster o administrador de correo. _____________________________________________2 deliver fue escrito por Chip Salzenberg (chip%tct@ateng.com). Es parte de varias distribuciones de Linux y se puede encontrar en los sistemas de FTP anonimo mas comunes como ftp.uu.net. _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ Muchos sistemas consideran importante asegurar que el correo que se envia y se recibe tenga un 100% de fiabilidad. Aun cuando esutil que se examinen los ficheros de registro syslogd(8), en general, el administrador del correo necesitara ver las cabeceras del correo rechazado, de tal forma que pueda determinar si el correo no fue entregado debido a un error del usuario, o a un error de configuracion en alguno de los sistemas involucrados. La definicion de POSTMASTERBOUNCE hace que se envie una copia de cada mensaje rechazado a la persona que ha sido definida como Postmaster para el sistema. Desafortunadamente, al definir este parametro, tambien se incluira el texto en el mensaje enviado al Postmaster, lo cual en potencia, podria inquietar a los usuarios de correo del sistema en cuanto a su intimidad se refiere. Es conveniente que los postmasters de sistema se autodisciplinen (o lo hagan por la via de medios tecnicos a traves de programitas del shell que borren el texto de los mensajes rechazados que ellos reciben) a no leer el correo que no esta dirigido a ellos. Asuntos relacionados con el servidor de nombres o Domain Name Service define(PSEUDODOMAINS, BITNET UUCP)dnl # no intente usar DNS aqui Hay varias redes bien conocidas que son punto de referencia comun en las direcciones de correo por razones historicas, pero que no son validas a efectos DNS. El definir PSEU- DODOMAINS evita intentos de busqueda infructuosos por parte del DNS, que siempre resultaran fallidos. Como definir los nombres por los que se conoce al sistema local define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com) dnl # nombres por los cuales se nos conoce define(DEFAULT_HOST, vstout.vbrew.com)dnl # nuestro 'nombre' primario para el correo Frecuentemente, los sistemas quieren ocultar su verdadera identidad, o servir como pasarelas de correo, o recibir y procesar correo dirigido a los nombres anteriores por los cuales se les conocian. PSEUDONYMS especifica la lista de todos los nombres de sistema para los cuales el sistema local aceptara el correo. DEFAULT_HOST especifica la direccion de sistema que aparecera en los mensajes que se originan en el nodo local. Es importante que este parametro sea ajustado a un valor valido o todo el correo de retorno no podra ser entregado. _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ Temas relacionados con UUCP define(UUCPNAME, vstout)dnl # nuestro nombre uucp define(UUCPNODES, |uuname|sort|uniq)dnl # nuestros vecinos uucp define(BANGIMPLIESUUCP)dnl # asegurandonos que el correo define(BANGONLYUUCP)dnl # uucp sea tratado correctamente Con frecuencia, los sistemas son conocidos por un nombre a efectos DNS y otro para propositos de UUCP. UUCPNAME permite definir que aparezca un nombre de sistema distinto en los encabezados del correo enviado a traves de UUCP. UUCPNODES define las instrucciones que proporcionan como resultado una lista con las direcciones de sistemas con los cuales se esta conectado directamente a traves de conexiones UUCP. BANGIMPLIESUUCP y BANGONLYUUCP aseguran que el correo direccionado con la sintaxis "bang" de UUCP sea tratado de acuerdo con el comportamiento de UUCP en vez de utilizar el DNS, mas comun hoy en dia en Internet. Sistemas de relevo y de correo define(RELAY_HOST, moria)dnl # nuestro sistema de relevo inteligente define(RELAY_MAILER, UUCP-A)dnl # alcanzamos moria a traves de UUCP Muchos administradores de sistema no quieren molestarse en llevar a cabo todo el trabajo necesario para asegurar que su sistema sea capaz de encontrar todas las redes (y por supuesto otros sistemas) existentes en el mundo. En lugar de hacer esto, prefieren confiar todo el correo saliente a otro sistema reconocido como "inteligente". RELAY_HOST define el nombre UUCP del sistema vecino inteligente. RELAY_MAILER define el gestor de correo utilizado para enviar los mensajes hacia dicho sistema. Es importante hacer notar que el ajuste de esos parametros redunda en que todo el correo de salida sera redirigido a ese sistema remoto, lo cual afectara la carga de ese sistema. Es necesario asegurarse de obtener el consentimiento explicito del Administrador de correo del sistema remoto antes de configurar el nuestro para que utilice a otro como nodo de reenvio de correo a efectos generales. Tablas de configuracion variadas define(ALIASES, LIBDIR/aliases)dnl # alias del sistema _______________________________________________________________________________________________________________15.5. * *El archivo sendmail.cf @ define(DOMAINTABLE, LIBDIR/domaintable)dnl # maquinas bajo el dominio define(PATHTABLE, LIBDIR/pathtable)dnl # base de datos de los caminos define(GENERICFROM, LIBDIR/generics)dnl # direccion generica del remitente define(MAILERTABLE, LIBDIR/mailertable)dnl # gestores de correo por nodo o dominio define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # caminos a los maquinas que surtimos define(UUCPRELAYS, LIBDIR/uucprelays)dnl # caminos de cortocircuito Con estas macros, se puede cambiar la localizacion donde sendmail+IDA busca las diversas tablas dbm que definen el comportamiento "real" del sistema. Es aconsejable depositarlos en LIBDIR. El archivo maestro Sendmail.mc include(Sendmail.mc)dnl # LINEA INDISPENSABLE!!! Los autores de sendmail+IDA proporcionan el archivo Sendmail.mc que contiene las verdaderas "tripas", que seran convertidas al archivo sendmail.cf. Periodicamente, se sacan nuevas versiones que corrigen errores en el codigo, o agregan funcionalidad sin necesidad de una nueva version y la recompilacion general de sendmail. Es importante no editar este archivo. Bueno, >entonces cuales son las lineas indispensables? Cuando no se estan utilizando ninguna de las tablas dbm opcionales, sendmail+IDA entrega el correo via el gestor de correo por omision DEFAULT_MAILER (y posiblemente el sistema de reenvio RELAY_HOST y el gestor de correo de reenvio RELAY_MAILER) definidos en el archivo sendmail.m4 utilizado para generar sendmail.cf. Es posible modificar facilmente este comportamiento cambiando ciertas lineas en los archivos domaintable o uucpxtable. Un sistema generico que este en Internet y se comunique por DNS, o uno que sea solo UUCP y envie todo su correo via UUCP a traves de un RELAY_HOST inteligente, probablemente no necesite de ninguna modificacion en una "table" especifica. Virtualmente todos los sistemas deberian configurar el DEFAULT_HOST y las macros PSEUDONYMS, de tal modo que definan el nombre canonico de sistema, y alias, por los que es conocido, y su DEFAULT_MAILER. Si todo lo que se tiene es un nodo de reenvio y un gestor de correo de reenvio, no es necesario ajustar estos valores por defecto ya que trabajara automaticamente. Los nodos UUCP probablemente necesiten ajustar su UUCPNAME a su nombre oficial UUCP. Tambien es probable que ajusten su RELAY_MAILER y su RELAY_HOST los _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ cuales habilitaran el encaminado de nodo inteligente a traves de un reenvio de correo. El transporte del correo a emplear se define en RELAY_MAILER y normalmente es UUCP-A para sistemas UUCP. Si su sistema es solo SMTP y emplea `Domain Name Service' o DNS, se podria cambiar el DEFAULT_MAILER a TCP-A y probablemente borrar las lineas RELAY_MAILER y RELAY_HOST. 15.6 Un viaje por las tablas de Sendmail+IDA Sendmail+IDA proporciona varias tablas que permiten modificar el comportamiento por defecto de sendmail (especificado en el archivo sendmail.m4 ) y definir un comportamien- to especial para situaciones singulares, sistemas remotos y redes. Estas tablas son luego procesadas con dbm, utilizando un Makefile que es parte de la distribucion. Muchos sistemas necesitaran algunas de estas tablas, otros ninguna. Si su sistema no precisa estas tablas, lo mas sencillo es, probablemente, crearlas con longitud cero (con la instruccion touch) y utilizar el archivo Makefile por defecto localizado en LIBDIR en lugar de editar el Makefile en si mismo. 15.6.1 mailertable El archivo mailertable define un tratamiento especial para maquinas especificas o dominios que estan basados en el nodo o nombre de la red remota. Se utiliza de forma frecuente en los sistemas Internet para seleccionar un nodo de reenvio de correo intermedio, o una pasarela a traves de la cual alcanzar una red remota, y para especificar el protocolo en particular (UUCP o SMTP) que se utilizara. Los sistemas UUCP por lo general no necesitan este archivo. El orden es importante: sendmail lee el archivo desde el principio hacia el fin, y procesa el mensaje de acuerdo con la primera regla que encuentra. Por tanto, lo logico normalmente es poner las reglas mas explicitas al comienzo del archivo y las mas genericas al final. Supongamos que se quiere redirigir todo el correo para el departamento de Ciencias de la Computacion de la Universidad Groucho Marx via UUCP a un sistema de relevo, ada. Para hacer eso, se debe agregar una linea en mailertable como la siguiente: # (in mailertable) # # redirige todo el correo para el dominio .cs.groucho.edu via UUCP a ada UUCP-A,ada .cs.groucho.edu _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ Suponga que se quiere redirigir todo el correo al dominio mas grande groucho.edu para que vaya a otro sistema de relevo, bighub, para la resolucion de sus direcciones y posterior entrega. La expansion de las lineas que van en el archivo mailertable seria la siguiente: # (en mailertable) # # redirige todo el correo para el dominio cs.groucho.edu via UUCP a ada UUCP-A,ada .cs.groucho.edu # # redirige todo el correo para el dominio groucho.edu via UUCP a bighub UUCP-A,bighub .groucho.edu Como se menciono anteriormente, el orden es importante. Invertir el orden de las dos reglas mostradas anteriormente tendria como consecuencia que todo el correo dirigido a .cs.groucho.edu fuese a traves del camino mas generico bighub en vez de utilizar la trayectoria explicita ada que es la que se quiere. # (en mailertable) # # redirige todo el correo para el dominio .groucho.edu via UUCP a bighub UUCP-A,bighub .groucho.edu # # (es imposible alcanzar la siguiente linea porque # la norma que esta arriba sera cumplida primero) UUCP-A,ada .cs.groucho.edu # En los ejemplos de mailertable anteriores, el gestor de correo UUCP-A hace que sendmail utilice UUCP como medio de entrega con cabeceras "dominizadas". La coma entre el gestor de correo y el sistema remoto indica que el mensaje se debe redirigir a ada para la resolucion de su direccion y posterior entrega. Las lineas que van en mailertable tienen el siguiente formato: mailer delimitador sistema_de_relevo maquina_o_dominio Existen diferentes gestores de correo posibles. Las diferencias radican generalmente en como trataran las direcciones. Los gestores de correo tipicos son: TCP-A (TCP/IP con direcciones estilo Internet), TCP-U (TCP/IP con direcciones estilo UUCP), y UUCP-A (UUCP con direcciones estilo Internet). _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ El caracter que separa al gestor de correo de la porcion del nodo en la parte izquierda de la linea de mailertable define como sera modificada la direccion por la mailertable. Lo importante aqui es que unicamente se reescribe el "sobre" (para obtener el correo en el sistema remoto). Reescribir cualquier otra cosa mas que el sobre es desaconsejable debido a la alta probabilidad de arruinar la configuracion del correo. ! Un signo final de exclamacion elimina el nombre del nodo receptor antes de redirigirlo al gestor de correo. Esto se puede usar cuando lo que se desea, esencialmente, es forzar al correo a entrar en un sistema remoto mal configurado. , Una coma no cambia la direccion en modo alguno. El mensaje simplemente es redirigido via el gestor de correo especificado al nodo o sistema de reenvio especificado. : Dos puntos eliminan el nombre del sistema receptor si hay sistemas interme- dios entre usted y el destino. Asi, foo!bar!joe eliminara foo, mientras que xyzzy!janet permanecera sin cambios. 15.6.2 uucpxtable Es comun que el correo dirigido a sistemas con nombres de dominio plenamente cualifica- dos se entregue via formato Internet (SMTP) utilizando un servidor de DNS, o mediante un sistema de reenvio. El archivo uucpxtable fuerza la entrega mediante encaminamiento UUCP, al convertir el nombre de formato dominio a un nombre de nodo con estilo UUCP sin formato de dominio. Esto se utiliza frecuentemente cuando se es un "repetidor"3 de correo para un sistema o dominio, o cuando se desea enviar el correo a traves de un enlace UUCP directo y seguro en lugar de arriesgarse a pasar potencialmente por muchos "saltos"4 si hacemos uso del gestor de correo por omision y cualesquiera de los sistemas intermedios y redes. Los sistemas UUCP que se comunican con sus vecinos UUCP, que utilizan cabeceras de correo dominizadas, podrian utilizar este archivo para forzar la entrega del correo, a traves del enlace directo UUCP punto a punto entre los dos sistemas, en lugar de emplear la ruta menos directa a traves del RELAY_MAILER y el RELAY_HOST o a traves del DEFAULT_MAILER. Los sistemas Internet que no empleen UUCP probablemente no utilicen el archivo uucpx- table. _____________________________________________3 Un analogo de lo que se entiende por "repetidor" en telecomunicaciones. 4 N. del T. Como hop o salto se entiende cada vez que atravesamos un sistema intermedio. _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ Supongamos que usted proporciona servicio de reenvio de correo a un sistema llamado sesame.com en DNS y sesame en los mapas UUCP. Necesitaria la siguiente linea en uucpxtable para forzar el direccionamiento del correo para ellos a traves de nuestra conexion UUCP directa. #============== /usr/local/lib/mail/uucpxtable ============ # El correo enviado a joe@sesame.com se reescribe a # sesame!joe y luego se entrega via UUCP # sesame sesame.com # #---------------------------------------------------------- 15.6.3 pathtable El archivo pathtable se utiliza para definir el encaminamiento explicito a sistemas o redes remotas. El archivo pathtable debe escribirse en orden alfabetico con una sintaxis similar al estilo de pathalias. Los dos campos de cada linea deben estar separados por un TAB real; si no es asi dbm podria "protestar". La mayor parte de los sistemas no precisaran ninguna linea en pathtable. #=============== /usr/local/lib/mail/pathtable ================ # # Este archivo tiene el estilo de pathalias en cuanto a trayectorias, # y permite encauzar el correo dirigido a los vecinos UUCP a traves de un camino # directo, de tal forma que no se tenga que hacer un rodeo hasta el # nodo inteligente, que se encarga de otro trafico. # # Es deseable que se utilicen espacios de tabulacion reales en cada linea o # m4 podria quejarse. # # Se debe encaminar el correo a traves de uno o mas sistemas intermedios # a un sistema remoto utilizando el estilo de direcciones UUCP. # sesame!ernie!%s ernie # # reenviado a un sistema UUCP vecino de un sistema Internet # alcanzable. # swim!%s@gcc.groucho.edu swim # # Lo que sigue manda todo el correo para dos redes a traves de _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ # distintos gateways (observe el '.' que comienza la linea). # En este ejemplo, "uugate" y "byte" son sistemas especificos que son # utilizados como gateways de correo a los pseudo dominios .UUCP y # .BITNET respectivamente. # %s@uugate.groucho.edu .UUCP byte!%s@mail.shift.com .BITNET # #=================== fin de pathtable ======================= 15.6.4 domaintable El archivo domaintable se utiliza generalmente para forzar cierto comportamiento tras una busqueda DNS. Permite al administrador hacer disponible una lista de abreviaturas de los nombres disponibles para sistemas o dominios a los que hagamos referencia con asiduidad, reemplazando la abreviatura con el nombre apropiado automaticamente. Tambien puede ser utilizado para sustituir los nombres de un nodo o dominio incorrectos con la informacion correcta. La mayor parte de los sistemas no necesitan lineas en domaintable. El siguiente ejemplo muestra como reemplazar una direccion personal erronea, in- tentandose enviar con la correcta: #============= /usr/local/lib/mail/domaintable ================= # # maquina_mal_configurada.dominio.correcto maquina_mal_c.dominio.erroneo # # #=================== fin de domaintable ======================== 15.6.5 alias Los alias posibilitan lo siguiente: o Permiten que una abreviatura o termino facil de recordar actue como una direccion de correo, que remite lo recibido a una o varias personas. o Invocan a un programa que tomara como entrada el mensaje. o Envian correo a un archivo. _______________________________________________________________________________________________________________15.6. * *Un viaje por las tablas @ Todos los sistemas precisan alias para el Postmaster y el MAILER-DAEMON a fin de cumplir con el RFC. Se debe ser extremadamente cuidadoso con respecto a la seguridad cuando se definan alias que invoquen a programas o escriban a programas ya que el sendmail generalmente se ejecuta con los permisos setuid-root. Los cambios al archivo de aliases no tienen efecto hasta que el comando # /usr/lib/sendmail -bi se ejecuta para construir las tablas dbm necesarias. Esto tambien puede hacerse ejecutando el comando newaliases, normalmente mediante el comando cron. Para mas detalles concernientes a los alias de correo, se puede encontrar mas informacion en la pagina man aliases(5). #--------------------- /usr/local/lib/mail/aliases ------------------ # # muestra de tipos de alias comunes # usenet: janet # alias para una persona admin: joe,janet # alias para varias personas newspak-users: :include:/usr/lib/lists/newspak # lee los receptores de un archivo changefeed: | /usr/local/lib/gup # alias que invoca un programa complaints: /var/log/complaints # alias que escribe el # correo recibido a un archivo # # Los siguientes dos alias deben estar presentes para cumplir con el RFC. # Es importante tenerlos para asignar a una persona que lea el correo # rutinariamente. # postmaster: root # linea indispensable MAILER-DAEMON: postmaster # linea indispensable # #------------------------------------------------------------------- 15.6.6 Tablas utilizadas en raras ocasiones Las siguientes tablas estan disponibles, pero se utilizan muy rara vez. Consulte la docu- mentacion que viene con el codigo fuente de sendmail+IDA para mas detalles. _______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ uucprelays El archivo uucprelays se utiliza para "corto-circuitar" la trayectoria del UUCP a sistemas especialmente bien conocidos en vez de utilizar una tra- yectoria multi-salto o insegura generada por el procesamiento de los mapas UUCP con pathalias. genericfrom y xaliases El archivo genericfrom oculta los nombres y direcciones de los usuarios loca- les del mundo exterior convirtiendo automaticamente los nombres de usua- rios locales a direcciones genericas de envio no coincidentes con los nombres internos de usuarios. La utilidad asociada xalparse automatiza la generacion de genericfrom y el archivo aliases de tal forma que las traducciones de los nombres del usuario de entrada y salida tengan lugar desde el archivo maestro xaliases. decnetxtable El archivo decnetxtable reescribe las direcciones con formato dominio a di- recciones estilo DECnet muy similares al archivo domaintable, que se utiliza para reescribir direcciones sin dominizar a direcciones estilo SMTP con for- mato dominizado. 15.7 Instalacion de sendmail En esta seccion se vera como instalar una distribucion ejecutable tipica de sendmail+IDA y un recorrido por lo necesario para personalizarla y hacerla funcionar. La distribucion binaria actual de sendmail+IDA para Linux puede obtenerse de sunsi- te.unc.edu en /pub/Linux/system/Mail. Incluso si se tiene una version anterior de send- mail es muy recomendable utilizar la version sendmail5.67b+IDA1.5 ya que todos los par- ches especificos para Linux estan en fuentes poco revisados, y varios e importantes agujeros de seguridad han sido enmendados (algunos de ellos datan del primero de diciembre de 1993). Si se esta compilando sendmail desde el codigo fuente, se deben seguir las instrucciones que estan en los archivos README que estan incluidos en la distribucion de los fuentes. El codigo fuente actual de sendmail+IDA esta disponible en vixen.cso.uiuc.edu. Pa- ra construir sendmail+IDA en Linux, tambien se necesitan los archivos de configuracion especiales para Linux newspak-2.2.tar.gz que estan en sunsite.unc.edu en el directorio /pub/Linux/system/Mail. Si tenia instalado anteriormente smail u otro gestor de entrega de correo, probablemente quiera borrar o renombrar todos los ficheros pertenecientes a smail para mayor seguridad. _______________________________________________________________________________________________________________15.7. * * Instalacion de sendmail @ 15.7.1 Desempaquetado de la distribucion ejecutable Lo primero es desempaquetar el archivo comprimido en algun lugar seguro: $ gunzip -c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf - Si se tiene un tar "moderno", por ejemplo de una distribuicion de Slackware reciente, probablemente baste con un tar -zxvf fichero .tgz y se obtendran los mismos resultados. Al despempaquetar el archivo se genera un directorio llamado send- mail5.65b+IDA1.5+mailx5.3b. En este directorio encontrara la instalacion completa de sendmail+IDA mas un programa binario del agente para usuario mailx. Todos los directorios donde se encuentran los archivos reflejan la ubicacion donde deben ser instalados estos, asi que es mas seguro utilizar la aplicacion tar para moverlos a otra parte: # cd sendmail5.65b+IDA1.5+mailx5.3b # tar cf - . | (cd /; tar xvvpoof -) 15.7.2 Elaboracion del fichero sendmail.cf Para elaborar un fichero sendmail.cf personalizado para su sistema, se ha de escribir un fichero sendmail.m4, y procesarlo posteriormente con m4. En /usr/local/lib/mail/CF puede encontrar un archivo de ejemplo llamado sample.m4. Copielo a nombredesusistema .m4, y editelo a fin de que refleje la situacion de su sistema. El fichero de ejemplo esta configurado para un sistema solo UUCP con cabeceras domi- nizadas y que se comunica con un sistema inteligente. Los sistemas comoeste precisan de pocas variaciones. En esta seccion se se"nalaran las macros a cambiar. Si quiere tener una descripcion completa de lo que hacen, dirijase a la seccion anterior, "Discusion del fichero sendmail.m4 ". LOCAL_MAILER_DEF Define el fichero que especifica los agentes de correo para gestion local. Vea la seccion previa "Definicion del gestor local de correo" para saber de que va. PSEUDONYMS Especifica todos los nombres por los que es conocido su sistema. DEFAULT_HOST Escriba su nomenclatura de dominio plenamente cualificado. Este nombre aparecera como su nombre de sistema en todo el correo saliente. _______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ UUCPNAME Ponga su nombre de sistema sin cualificar. RELAY_HOST y RELAY_MAILER Si se comunica mediante UUCP con un sistema inteligente, defina RE- LAY_HOST como el nombre UUCP del "repetidor inteligente" de su vecino UUCP. Haga uso del gestor de correo UUCP-A si desea que las cabeceras de sus mensajes contengan su dominio. DEFAULT_MAILER Si esta conectado a Internet y se comunica mediante DNS, deberia definir esto como TCP-A. Esto le dice a sendmail que emplee TCP-A como ges- tor de correo, que entregara el correo via SMTP haciendo uso del estilo RFC normal en las direcciones de los receptores de correo. Los sistemas conectados permanentemente a Internet probablemente no precisen definir RELAY_HOST o RELAY_MAILER. Para crear el fichero sendmail.cf, ejecutar la orden # make nombredesusistema .cf Esto procesa el fichero nombredesusistema y crea el fichero nombredesusistema .cf a partir deel. Lo proximo sera comprobar si el fichero que acaba de crear hace lo que se espera deel o no. Esto se explica en las proximas dos secciones. Una vez se esta contento con su comportamiento, copielo en su sitio con el comando: # cp nombredesusistema .cf /etc/sendmail.cf Llegados a este punto, su sistema sendmail esta listo para funcionar. Escriba la siguiente linea en el fichero de arranque adecuado (generalmente /etc/rc.inet2 ). Puede ejecutarlo "a mano" para que empiece a funcionar en este momento. # /usr/lib/sendmail -bd -q1h 15.7.3 Comprobando el fichero sendmail.cf Para hacer que sendmail funcione en modo `test', ha de ejecutarlo con la opcion -bt. La configuracion por defecto es el fichero sendmail.cf que este instalado en el sistema. Puede probar un fichero de configuracion alternativo mediante la opcion -Cfichero_alternativo . _______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ En los siguientes ejemplos, probamos vstout.cf, el fichero de configuracion generado a partir del fichero vstout.m4 que puede ser examinado en la figura 15.2. # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > Las siguientes comprobaciones aseguran que sendmail es capaz de gestionar el correo de todos los usuarios del sistema. En todos los casos, el resultado de la comprobacion debera ser el mismo, y apuntar al nombre del sistema local como el gestor de correo en LOCAL. Comprobemos primero como se gestionaria el envio a un usuario local: # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 me rewrite: ruleset 3 input: me rewrite: ruleset 7 input: me rewrite: ruleset 9 input: me rewrite: ruleset 9 returns: < me > rewrite: ruleset 7 returns: < > , me rewrite: ruleset 3 returns: < > , me rewrite: ruleset 0 input: < > , me rewrite: ruleset 8 input: < > , me rewrite: ruleset 20 input: < > , me rewrite: ruleset 20 returns: < > , @ vstout . vbrew . com , me rewrite: ruleset 8 returns: < > , @ vstout . vbrew . com , me rewrite: ruleset 26 input: < > , @ vstout . vbrew . com , me rewrite: ruleset 26 returns: $# LOCAL $@ vstout . vbrew . com $: me rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me El resultado muestra como sendmail procesa las direcciones internamente. Esto es lleva- do a cabo por varias rulesets que las analizan, llaman a otras involucradas, y descomponen la direccion en sus componentes. En nuestro ejemplo, le pasamos la direccion me a las rulesets 3 y 0 (esto es lo que significa el termino 3,0 introducido antes de la direccion). _______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ Laultima linea muestra la direccion interpretada tal y como la devuelve la ruleset 0, que contiene el gestor de correo al que se le encomendaria el mensaje, y la maquina y usuario proporcionados al mismo. A continuacion, comprobaremos el envio de correo a un usuario de nuestro sistema con sintaxis UUCP. # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 vstout!me rewrite: ruleset 3 input: vstout ! me [...] rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me > A continuacion, comprobamos el correo dirigido a un usuario de nuestro sistema con sintaxis Internet, a nuestro nombre de sistema plenamente cualificado (FQDN) # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 me@vstout.vbrew.com rewrite: ruleset 3 input: me @ vstout . vbrew . com [...] rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me > Deberia repetir los anteriores dos pasos con cada uno de los nombres especificados como parametros PSEUDONYMS y DEFAULT_NAME del fichero sendmail.m4. Porultimo, comprobar que puede enviar correo a su nodo de reenvio. # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
_______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ [Note: No initial ruleset 3 call] > 3,0 fred@moria.com rewrite: ruleset 3 input: fred @ moria . com rewrite: ruleset 7 input: fred @ moria . com rewrite: ruleset 9 input: fred @ moria . com rewrite: ruleset 9 returns: < fred > @ moria . com rewrite: ruleset 7 returns: < @ moria . com > , fred rewrite: ruleset 3 returns: < @ moria . com > , fred rewrite: ruleset 0 input: < @ moria . com > , fred rewrite: ruleset 8 input: < @ moria . com > , fred rewrite: ruleset 8 returns: < @ moria . com > , fred rewrite: ruleset 29 input: < @ moria . com > , fred rewrite: ruleset 29 returns: < @ moria . com > , fred rewrite: ruleset 26 input: < @ moria . com > , fred rewrite: ruleset 25 input: < @ moria . com > , fred rewrite: ruleset 25 returns: < @ moria . com > , fred rewrite: ruleset 4 input: < @ moria . com > , fred rewrite: ruleset 4 returns: fred @ moria . com rewrite: ruleset 26 returns: < @ moria . com > , fred rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ moria . com > , fred > 15.7.4 Integracion global - Prueba de integracion del fichero sendmail.cf y las tablas. Llegados a este punto, ya ha verificado que el sistema de correo tendra el comportamiento por defecto deseado, y que sera capaz tanto de enviar como de recibir correo con direccion valida. Para terminar la instalacion, puede ser necesario crear las tablas dbm apropiadas para conseguir finalmente los resultados deseados. Tras crear las tablas necesarias para su sistema, debera procesarlas a traves de dbm mediante la ejecucion de la orden make en el directorio que contenga las tablas. Si su sistema es solo UUCP, no necesita crear ninguna de las tablas mencionadas en el fichero README.linux. Solo tendra que modificar los ficheros de tal modo que funcione el Makefile. Si su sistema es solo UUCP y "habla" con mas sistemas ademas de su nodo de reenvio inteligente, necesitara a"nadir entradas uucpxtable para cada uno (o el correo destinado a ellos se encaminara tambien a traves del nodo inteligente) y ejecutar dbm sobre el recien modificado fichero uucpxtable. Para empezar, necesita asegurarse de que el correo que ha de pasar por su RELAY_HOST _______________________________________________________________________________________________________________15.7. * *Instalacion de sendmail @ se envia mediante el RELAY_MAILER. # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 fred@sesame.com rewrite: ruleset 3 input: fred @ sesame . com rewrite: ruleset 7 input: fred @ sesame . com rewrite: ruleset 9 input: fred @ sesame . com rewrite: ruleset 9 returns: < fred > @ sesame . com rewrite: ruleset 7 returns: < @ sesame . com > , fred rewrite: ruleset 3 returns: < @ sesame . com > , fred rewrite: ruleset 0 input: < @ sesame . com > , fred rewrite: ruleset 8 input: < @ sesame . com > , fred rewrite: ruleset 8 returns: < @ sesame . com > , fred rewrite: ruleset 29 input: < @ sesame . com > , fred rewrite: ruleset 29 returns: < @ sesame . com > , fred rewrite: ruleset 26 input: < @ sesame . com > , fred rewrite: ruleset 25 input: < @ sesame . com > , fred rewrite: ruleset 25 returns: < @ sesame . com > , fred rewrite: ruleset 4 input: < @ sesame . com > , fred rewrite: ruleset 4 returns: fred @ sesame . com rewrite: ruleset 26 returns: < @ sesame . com > , fred rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ sesame . com > , fred > Si tiene mas vecinos UUCP, ademas de su RELAY_HOST, necesita asegurarse de que el correo para ellos experimenta un procesamiento adecuado. El correo con direcciones de sintaxis tipo UUCP dirigido a otro sistema con el que se comunique tambien mediante UUCP, ira a ellos directamente (a menos de que lo impida explicitamente mediante una entrada domaintable). Asumimos que el sistema swim es un vecino UUCP directo para nosotros. Pasar a sendmail un mensaje swim!fred debera producir el siguiente resultado: # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 swim!fred rewrite: ruleset 3 input: swim ! fred [...lines omitted...] rewrite: ruleset 0 returns: $# UUCP $@ swim $: < > , fred _______________________________________________________________________________________________________________15.8. * *Trucos y trivialidades s@ > Si tiene entradas uucpxtable para forzar la gestion de correo UUCP a ciertos vecinos UUCP que envian su correo con cabeceras dominizadas tipo Internet, tambien tiene que verificarlo. # /usr/lib/sendmail -bt -Cvstout.cf ADDRESS TEST MODE Enter
[Note: No initial ruleset 3 call] > 3,0 dude@swim.2birds.com rewrite: ruleset 3 input: dude @ swim . 2birds . com [...lines omitted...] rewrite: ruleset 0 returns: $# UUCP $@ swim . 2birds $: < > , dude > 15.8 Trucos y trivialidades sobre administracion de correo Ahora que ya se ha discutido la teoria sobre configuracion, instalacion y comprobacion de un sistema sendmail+IDA, dediquemos unos instantes al analisis de las cosas que suceden rutinariamente en la vida de un administrador de correo. Los sistemas remotos fallan a veces. Los modems o lineas telefonicas fallan o las defini- ciones DNS son elaboradas incorrectamente debido a un error humano. En estos casos, los administradores de correo han de saber como reaccionar de forma rapida, efectiva y segura para mantener el trafico del correo a traves de rutas alternativas hasta que los sistemas remotos o los proveedores de acceso puedan restablecer sus servicios habituales. El resto de este capitulo pretende proporcionarle soluciones para las "emergencias con el correo electronico" mas frecuentes. 15.8.1 Reenvio de correo a un sistema inteligente Para redirigir el correo para un sistema o dominio particular hacia el sistema de reenvio inteligente designado, se empleara normalmente el fichero mailertable. Por ejemplo, para redirigir el correo para backwood.org a su sistema de pasarela UUCP backdoor, tendra que poner la siguiente entrada en mailertable: _______________________________________________________________________________________________________________15.8. * *Trucos y trivialidades s@ UUCP-A,backdoor backwood.org 15.8.2 Envio de correo a Sistemas Remotos mal configurados Los sistemas Internet tendran frecuentemente problemas a la hora de hacer entrar el correo en sistemas mal configurados. Existen varios casos, pero el sintoma general es que el correo es devuelto por el sistema remoto o que nunca lo alcanza. Estos problemas pueden colocar al administrador local del sistema en una situacion critica, ya que sus usuarios generalmente no tienen en cuenta que usted no administra todos los sistemas a lo largo y ancho del mundo (o que usted no sepa como hacer que el administrador remoto solucione el problema). Ellos tan solo sabran que su correo no llego al destinatario deseado en el otro extremo, y usted sera la persona mas cercana a la que pedir responsabilidades. La configuracion de un sistema remoto es problema de sus administradores, no de us- ted. En cualquier caso, asegurese de no estropear la configuracion de su sistema a fin de comunicarse con un sistema remoto mal configurado. Si no puede ponerse en contacto con el administrador (Postmaster ) del sistema remoto a fin de que arreglen su configuracion lo antes posible, tiene dos opciones: o Generalmente es posible forzar el correo hacia el interior del sistema remoto conexito, aunque el sistema remoto este mal configurado; las respuestas provenientes del otro extremo posiblemente no funcionen. . . pero ese es problema del administrador remoto. Puede corregir las cabeceras erroneas de sus destinatarios de correo saliente simple- mente usando una entrada domaintable para su sistema/dominio, lo que redundara en que la informacion no valida sea corregida en el correo originado desde su sistema: descerebrado.dominio.correcto.com descerebrado.dominio.erroneo.com o Los sistemas mal configurados devuelven con frecuencia el correo al sistema que lo origino, argumentando que "este correo no es para este sistema" ya que no tienen debidamente configurado su PSEUDONYMNS o equivalente. Es posible quitar toda informacion relativa al nombre y dominio del sistema en los destinatarios de correo saliente de nuestro sistema hacia ellos. El ! de la siguiente mailertable gestiona el correo hacia su sistema remoto TCP!descerebrados.dominio.correcto.com descerebrados.dominio.erroneo.com No obstante, y aunque se consiga que el correo entre en su sistema, no hay garantias de que ellos puedan responder a nuestros mensajes (su sistema esta mal configurado, recuerde- _______________________________________________________________________________________________________________15.8. * *Trucos y trivialidades s@ lo. . . ) pero para entonces sus usuarios estaran quejandose a sus administradores, que es mejor que los suyos se enfaden con usted. 15.8.3 Envio Forzado de correo a traves de UUCP En un mundo ideal (desde la perspectiva Internet), todas las maquinas tendran registro en el Servicio de Nombres de Dominio (DNS) y envian su correo con nombres de dominio plenamente cualificados. Si se da la circunstancia de que se comunica via UUCP con un sistema de estas carac- teristicas, puede forzar el correo a ser enviado directamente a traves de la conexion punto- a-punto UUCP en lugar de hacerlo a traves de su gestor de correo habitual, esencialmente "desdominizando" su nombre de sistema mediante el fichero uucpxtable. Para forzar el envio de correo a la maquina sesame.com, debera poner lo siguiente en el fichero uucpxtable: # desdominizamos sesame.com para forzar el envio UUCP sesame sesame.com El resultado es que sendmail determinara entonces (a traves de UUCPNODES del fichero sendmail.m4 ) que se esta conectado directamente al sistema remoto, y encolara el correo saliente para ser enviado via UUCP. 15.8.4 Prevencion de que el correo sea enviado via UUCP La condicion contraria tambien se da. Con frecuencia, los sistemas tienen cierto numero de conexiones UUCP que rara vez se emplean o que no siempre son tan fiables, o que no estan tan disponibles como el gestor de correo por defecto o el sistema de reenvio. Por ejemplo, en elarea de Seattle hay varios sistemas que intercambian las distintas distribuciones Linux via UUCP anonimo conforme se van liberando las distribuciones. Estos sistemas se comunican mediante UUCP solo cuando es necesario, por lo que es generalmente mas rapido y fiable enviar el correo a traves de multiples saltos muy fiables y nodos de reenvio (que siempre estan disponibles). Se puede evitar facilmente el envio directo de correo a una maquina a la que se esta di- rectamente conectado. Si el sistema remoto posee un nombre de dominio plenamente cua- lificado, se puede a"nadir una entrada comoesta en el fichero domaintable: # Evitamos que se envie el correo via UUCP a un sistema vecino snorkel.com snorkel _______________________________________________________________________________________________________________15.8. * *Trucos y trivialidades s@ Esto reemplazara cualquier aparicion del nombre UUCP con el nombre FQDN, impidien- do por tanto cualquier concordancia con la linea UUCPNODES del fichero sendmail.m4. El resultado es, generalmente, que el correo se enviara via RELAY_MAILER y RELAY_HOST (o DEFAULT_MAILER). 15.8.5 Procesado de la cola de correo a voluntad Para procesar los mensajes de la cola de correo saliente inmediatamente, no hay mas que teclear '/usr/lib/runq'5. Esto llamara a sendmail con las opciones apropiadas para hacer que procese inmediatamente la cola de procesos pendientes en lugar de esperar al proximo procesamiento programado. 15.8.6 Informe sobre las estadisticas de correo Muchos administradores de sistema (y las personas para las que trabajan) estan interesados en el volumen de correo que es enviado, recibido o que pasa a traves de nuestro sistema. Hay varios metodos de cuantificar el trafico de correo. o El paquete sendmail incorpora una utilidad llamada mailstats que lee un fichero lla- mado /usr/local/lib/mail/sendmail.st 6e informa sobre el numero de mensajes y bytes transferidos por cada uno de los gestores de correo que se empleen y que aparezcan en el fichero sendmail.st. Este fichero debe ser creado manualmente por el administrador local para que el registro tenga lugar por parte de sendmail. Los totales se reiniciali- zan borrando y volviendo a crear el fichero sendmail.st. Un metodo para hacer esto es el siguiente; # cp /dev/null /usr/lib/local/mail/sendmail.st o Probablemente la mejor forma de obtener informes de calidad acerca de quien usa el correo y la cantidad de volumen que pasa hacia, por, y a traves del sistema local sea activar el depurado de correo (debugging) mediante el uso de syslogd(8). Esto generalmente conlleva el tener que arrancar el demonio syslogd desde su fichero de inicializacion del sistema (de todos modos lo deberia estar haciendo), y a"nadir una linea al fichero /etc/syslog.conf(5) que tiene el siguiente aspecto: mail.debug /var/log/syslog.mail _____________________________________________5 La llamada a sendmail con el parametro '-q' tiene identicos efectos ('sendmail -q') 6 N. del T.: En ciertas distribuciones actuales, como por ejemplo RedHat, la localizacion es /var/log/sendmail.st; esto dependera de la filosofia de la distribucion que emplee; el LFS (Linux Filesystem Standards, anterior FSSTND) al ser un fichero de log o de registro, recomienda el directorio /var/log _______________________________________________________________________________________________________________15.9. * *Integracion y puesta a p@ Si emplea mail.debug, y recibe un volumen de correo medio/alto, el resultado propor- cionado por syslog puede hacerse bastante grande. Los ficheros de registro generados por syslogd necesitan generalmente ser purgados rutinariamente por crond(8). Existen cierto numero de utilidades disponibles comunmente que pueden resumir el resultado del registro de correo procedente de syslogd. Una de las mas conocidas es syslog-stat.pl, un script en Perl que se distribuye con los fuentes de sendmail+IDA. 15.9 Integracion y puesta a punto de Distribuciones Ejecu- tables A pesar de que el Estandar de Sistema de Ficheros de Linux esta en desarrollo, todavia no esta ni terminado ni aceptado universalmente. Mi intencion aqui es mostrar que todavia no somos7 un estandar, y proporcionar una idea de cuales son los lugares donde aparecen problemas con mayor frecuencia No existe ninguna configuracion autenticamente estandar del transporte de correo electronico y sus agentes, asi como no hay una "unica estructura de directorios." De acuerdo con esto, es necesario asegurarse de que todas las distintas partes del sistema (USENET news, mail, TCP/IP) estan de acuerdo con la localizacion del gestor de correo local (lmail, deliver, etc.), el gestor de correo remoto (rmail ), y el programa de transporte de correo (sendmail o smail ). Estas suposiciones generalmente no estan documentadas; no obstante, el uso del comando strings puede ayudarnos a determinar que ficheros y directorios son los esperados. A continuacion vienen algunos problemas que hemos observado en el pasado con algunas de las distribuciones ejecutables y fuentes disponibles comunmente para Linux. o Algunas versiones de la distribucion de NET-2 de TCP/IP tienen servicios definidos para un programa llamado umail en lugar de para sendmail. o Existen varios portes de elm y mailx que buscan al gestor de correo (envio) /usr/bin/smail en lugar de a sendmail. o Sendmail+IDA tiene un gestor de correo local interno para deliver, pero espera que este en /bin en lugar de la localizacion mas tipica en Linux /usr/bin. En lugar de pasar por la trabajosa tarea de compilar todos los clientes de correo a partir de sus fuentes, generalmente los enga"naremos con los enlaces simbolicos apropiados. _____________________________________________7 N. del T.: Esto ha cambiado desde que esta guia fue escrita, el LFS (Linux Filesystem Standards) o anterior FSSTND esta en vias de ser aceptado, si es que no lo esta ya. _______________________________________________________________________________________________________________15.10. * * Donde obtener mas infor@ 15.10 Donde obtener mas informacion Existen muchos lugares donde buscar mas informacion sobre sendmail. Si se quiere un listado completo, vea el "Linux MAIL Howto", que se envia regularmente a comp.answers. Tambien esta disponible por FTP en rtfm.mit.edu. De todos modos, el lugar definitivo son los fuentes de sendmail+IDA. Busque en el directorio ida/cf que cuelga del directorio de los fuentes, los ficheros DBM-GUIDE, OPTIONS, y Sendmail.mc. Capitulo 16 Netnews 16.1 Historia de Usenet La idea de las noticias en red nacio en 1979, cuando dos estudiantes de graduado, Tom Truscott y Jim Ellis, pensaron en usar UUCP para conectar ordenadores con el proposito de intercambiar informacion entre usuarios de un?x. Instalaron una peque"na red de tres ordenadores en Carolina del Norte. Inicialmente el trafico de informacion era manejado por cierto numero de shell scripts (mas tarde reescritos en C), pero que nunca fueron hechos publicos. Fueron rapidamente reemplazados por "A" news, la primera edicion publica de programas para news. "A" news no estaba dise"nado para manejar mas que unos pocos articulos por grupo y dia. Cuando el volumen de informacion continuo creciendo, fue reescrito por Mark Horton y Matt Glickman, quienes lo denominaron la version "B" (tambien conocido como Bnews). El primer lanzamiento publico de Bnews fue la version 2.1, en 1982. Se fue expandiendo continuamente, conforme se le a"nadian nuevas prestaciones. La version actual es Bnews 2.11. Poco a poco se va quedando obsoleta, habiendose pasado a INN suultimo mantenedor oficial. Geoff Collyer y Henry Spencer reescribieron y lanzaron en 1987 otra nueva version, conocida como version "C" o Cnews . En el tiempo transcurrido desde entonces ha habido algunos parches para Cnews , siendo el mas notable de ellos la Cnews Performance Release. En sistemas que transportan un gran numero de grupos, el consumo de recursos producido al ejecutar frecuentemente relaynews (el programa encargado de procesar los articulos) es bastante significativo. La Performance Release a"nade una opcion que permite ejecutar relaynews en modo daemon, es decir, ejecutandose como tarea de fondo. La Performance Release es la version de Cnews que se incluye en la mayoria de las distribuciones de Linux actuales. 267 _______________________________________________________________________________________________________________16.2. * *>Que es, en definitiva, @ Todas las versiones hasta la "C" estan principalmente dise"nadas para utilizarse en redes UUCP, aunque igualmente pueden utilizarse en otros entornos. La transferencia eficiente de noticias sobre redes tipo TCP/IP, DECNet o similares, requiere otro planteamiento. Esta es la razon por la que en 1986 se introdujo el "Network News Transfer Protocol" (NNTP) o Protocolo de Transferencia de Noticias a traves de la Red. Este protocolo esta basado en conexiones de red, y especifica cierto numero de comandos para transferir los articulos de forma interactiva. Hay bastantes aplicaciones basadas en el NNTP disponibles en la Red. Una de ellas es el paquete nntpd, de Brian Barber y Phil Lapsley, que puede usarse, entre otras cosas, para proporcionar un servicio de lectura de noticias a distintos nodos de una red local. nntpd fue dise"nado para complementarse con Bnews o Cnews y darles prestaciones NNTP. Otra aplicacion NNTP diferente es INN, o Internet News. No es simplemente un interfaz, sino un sistema de noticias por derecho propio. Consta de un sofisticado demonio de noticias que es capaz de mantener varias conexiones NNTP simultaneas, y es por lo tanto, el software elegido por muchos servidores en Internet. 16.2 >Que es, en definitiva, Usenet? Una de las cosas mas asombrosas de Usenet es que no forma parte de ninguna organizacion, ni tiene ninguna clase de autoridad central. De hecho, parte del saber popular de Usenet consiste en que excepto por una descripcion tecnica, no se puede definir que es, tan solo que no es. Si tiene Vd. a mano el excelente "Zen and the Art of the Internet" (disponible en Internet o a traves de Prentice-Hall, ver [Kehoe92 ]), de Brendan Kehoe, encontrara una sorprendente lista de impropiedades de Usenet. A riesgo de sonar tonto, podria definirse Usenet como la colaboracion de servidores separados que intercambian noticias de Usenet. Para ser un servidor en Usenet, todo lo que hay que hacer es encontrar otro servidor Usenet y llegar a un acuerdo con sus propietarios y administradores para intercambiar noticias con ellos. Proporcionar articulos a otro servidor se denomina tambien alimentacion o feeding, de donde se origina otro axioma comun de Usenet: "Consigue alguien que te pase las noticias, y ya eres parte de Usenet". La unidad fundamental de las noticias de Usenet es el articulo. Es un mensaje que un usuario escribe y "publica" en la red. Para posibilitar que los sistemas de noticias lo manejen, esta precedido de informacion administrativa, conocida como cabecera del articulo. Es muy similar a la cabecera utilizada para el correo que se describe en el estandar RFC 822, y comoesta, consiste en varias lineas de texto, cada una de las cuales comienza con el nombre de un campo terminado en dos puntos, siguiendo despues el valor de dicho campo.1 _____________________________________________1 El formato de los mensajes de noticias de Usenet se especifica en la RFC 1036, "Standard for interchange _______________________________________________________________________________________________________________16.3. * *>Como maneja Usenet las @ Los articulos son enviados a uno o mas grupos de noticias. Podrian considerarse a los grupos como foros para articulos relativos a una misma tematica. Todos los grupos estan organizados en una jerarquia, en la cual el nombre de cada grupo indica su lugar en la misma. Esto a menudo hace mas facil ver sobre que versa un grupo de noticias. Por ejemplo, todo el mundo puede deducir por el nombre que comp.os.linux.announce se usa para anuncios relativos a un sistema operativo para computadoras llamado Linux. Estos articulos son intercambiados entre todos los servidores de Usenet a los que inte- rese tener noticias de este grupo. Cuando dos servidores acuerdan intercambiar noticias, son libres de intercambiar cualquier grupo que deseen, y pueden incluso a"nadir sus pro- pias jerarquias locales. Por ejemplo, groucho.edu puede tener un enlace de noticias con barnyard.edu, un gran servidor de noticias, y varios enlaces con servidores menores a los que alimenta con noticias. El Colegio Barnyard puede recibir todos los grupos de Usenet, mientras que la UGM solo quiere algunas jerarquias mayores como sci, comp, rec, etc. Algunos servidores situados mas abajo en esta cadena, digamos un servidor UUCP llama- do brewhq, querran incluso menos grupos, ya que no tendran los suficientes recursos de hardware o de red. Por otro lado, brewhq puede querer recibir grupos de la jerarquia fj que la UGM no tiene. Por lo tanto, mantiene otro enlace con gargleblaster.com, quien tiene todos los grupos fj y se los pasa a brewhq. El flujo de noticias se muestra en la figura 16.1. Las etiquetas en las flechas que parten de brewhq pueden requerir ciertas explicaciones. Por defecto, brewhq quiere que todas las noticias generadas localmente sean enviadas a groucho.edu. Sin embargo, ya que groucho.edu no lleva los grupos fj, no hay razon para enviar ningun articulo de estos grupos. Por tanto, la alimentacion de brewhq a la UGM esta etiquetada all,!fj, lo que significa que se envian todos los grupos excepto los fj. 16.3 >Como maneja Usenet las noticias? Hoy en dia, Usenet ha crecido hasta alcanzar dimensiones enormes. Los servidores que llevan la totalidad de los grupos suelen tener que transferir unos sesenta megabytes por dia.2 Por supuesto esto requiere mucho mas que enredar con unos cuantos ficheros. Veamos como se las apa"nan la mayoria de sistemas un?x para manejar las noticias. Las noticias se distribuyen por la red de varias formas. El medio historico solia ser UUCP, pero hoy en dia el caudal principal es llevado por servidores permanentemente conectados a Internet. El algoritmo para encaminar se denomina inundacion: cada servidor mantiene cierto numero de enlaces con otros servidores. Cualquier articulo generado o _____________________________________________ of USENET messages". 2 Un momento: 60 Mb a 9600 bps, o sea, 60 millones por 1200, eso es. . . murmullo, murmullo,. . . Como maneja Usenet las @ Usenet barnyard.edu gargleblaster.com comp,sci, fj all rec fj all,!fj groucho.edu brewhq comp.os, comp.periphs Figura 16.1: Flujo de noticias a traves de la Universidad Groucho Marx recibido por el sistema local de noticias es enviado a estos servidores, a no ser que ya haya pasado por ellos. Se puede saber por que servidores ha pasado un articulo mirando el campo Path: de la cabecera. Este campo contiene una lista con todos los sistemas por los que el articulo ha pasado, separados por un signo de admiracion. Para distinguir entre los articulos y reconocer los duplicados, los articulos de Usenet llevan un identificativo (especificado en el campo Message-Id: de la cabecera) que combina el nombre del servidor donde se publico y un numero de serie "". Cada vez que se procesa un articulo, el sistema de noticias registra su identificativo en un fichero (generalmente llamado history) con el que despues se coteja cualquier nuevo articulo. El flujo entre dos servidores puede ser limitado por dos criterios: por un lado, al articulo se le asigna una distribucion (campo Distribution: de la cabecera) que puede ser usada para confinarlo a cierto grupo de servidores. Por otro lado, los grupos de noticias inter- cambiados pueden limitarse tanto en el sistema emisor como en el receptor. El conjunto de grupos y distribuciones que se permite transmitir a un sistema se suelen especificar en el fichero sys. Debido al gran numero de articulos, habitualmente se necesita mejorar el esquema an- terior. En las redes UUCP, lo natural es recoger los articulos durante un cierto periodo de tiempo y combinarlos en un solo fichero, que posteriormente es comprimido y enviado a un _______________________________________________________________________________________________________________16.3. * *>Como maneja Usenet las @ sistema remoto. Esto se llama batching.3 Una tecnica alternativa es la del protocolo ihave/sendme (tengo/enviame) que evita que los duplicados sean enviados en primer lugar, ahorrando ancho de banda. En vez de empaquetar todos los articulos en ficheros y enviarlos, solo se envian los identificativos de los mensajes en un gigantesco mensaje "ihave". El sistema remoto lee el mensaje, lo compara con su fichero historico (history), y envia un mensaje "sendme" con la lista de articulos que quiere. De este modo, solo se enviaran estos articulos. Por supuesto, el protocolo ihave/sendme solo tiene sentido si ata"ne a dos grandes siste- mas que reciben noticias desde varios sitios independientes, y que se intercambian articulos entre si con la suficiente frecuencia como para mantener un flujo de noticias eficiente. Los sevidores conectados a Internet generalmente se basan en programas bajo TCP/IP que usan el protocolo NNTP4, mencionado anteriormente. Con este protocolo se transfie- ren articulos entre servidores y se da acceso a Usenet a usuarios individuales en sistemas remotos. NNTP contempla tres formas diferentes de transferir las noticias. Una es una version en tiempo real de ihave/sendme, tambien conocida como empujar las noticias. La segunda tecnica se denomina tirar de las noticias. El cliente solicita una lista de articulos de un grupo o jerarquia determinado que ha llegado al servidor despues de una fecha especificada, y elige los que no puede encontrar en su fichero historico. La tercera forma es para lectura interactiva, y permite al lector escoger articulos de grupos especificados, asi como publicar articulos con cabeceras incompletas. En cada sistema, las noticias se guardan en una estructura de directorios bajo /var/spool/news, cada articulo en un fichero separado, y cada grupo en un directorio sepa- rado. El nombre del directorio se crea a partir del nombre del grupo, donde los componentes del mismo son los componentes de la ruta. Asi pues, los articulos de comp.os.linux.misc se guardan en /var/spool/news/comp/os/linux/misc. A cada articulo se le asigna un numero segun su orden de llegada. Este numero sirve como nombre de fichero. El rango de articulos vigentes en un momento dado se guarda en un fichero llamado active, que al mismo tiempo sirve como lista de grupos disponibles en el sistema. Puesto que el espacio en disco es un recurso finito,5 uno tiene que empezar a desechar los articulos de cierta antig"uedad. Esto se denomina expiracion. Generalmente, los articulos de un determinado grupo o jerarquia expiran al transcurrir un numero determinado de dias desde de su llegada. El autor puede modificar este valor especificando una fecha de expiracion en el campo Expires: de la cabecera del articulo. _____________________________________________3 La regla de oro de las noticias de red, segun Geoff Collyer: "Empaquetaras tus articulos". 4 Descrito en la RFC 977. 5 Alguna gente afirma que Usenet es un conspiracion entre vendedores de modems y discos duros. Capitulo 17 C-News Uno de los paquetes de software mas populares para las NetNews es C-News. Fue dise"nado para servidores que llevan noticias sobre enlaces UUCP. Este capitulo discutira los conceptos centrales de C-News, y las tareas de instalacion basica y de mantenimiento. C-News almacena sus ficheros de configuracion en /usr/lib/news, y la mayoria de sus ficheros binarios en el directorio /usr/lib/news/bin. Los articulos se guardan en /var/spool/news. Ud. debe estar seguro de que todos los ficheros en estos directorios son propiedad del usuario news, grupo news. La mayoria de los problemas surgen de la inaccesibilidad de los ficheros por C-News. Ud. debe tener como regla general el ser usuario news usando su antes de tocar nada ahi. Launica excepcion es setnewsids, que se usa para establecer la identificacion real del usuario de algunos programas de noticias. Este debe ser propiedad del root y debe tener el bit setuid activado. A continuacion, describimos todos los ficheros de configuracion de C-News en detalle, y le mostraremos lo que tiene que hacer para mantener su servidor en funcionamiento. 17.1 Entrega de Noticias Los articulos deben ser suministrados a C-News de varias maneras. Cuando un usuario local envia un articulo, el lector de noticias usualmente lo entrega al comando inews, el cual completa la informacion de cabecera. Las noticias del servidor remoto, tanto si es ununico mensaje como un lote entero, son entregadas al comando rnews, el cual lo almacena en el directorio /var/spool/news/in.coming, de donde lo cogera newsrun mas tarde. Sin embar- go, con cualquiera de estas dos tecnicas el articulo sera finalmente entregado al comando relaynews. Para cada articulo, el comando relaynews consulta primero si el articulo ha sido visto 272 _______________________________________________________________________________________________________________17.1. * *Entrega de Noticias @ en el servidor local buscando el identificador del mensaje en el fichero history. Los articulos duplicados seran eliminados. Entonces, relaynews mira la linea de cabecera del Newsgroup: para averiguar si el servidor local solicita articulos de cualquiera de estos grupos. Si lo hace, y el grupo de noticias esta listado en el fichero active, relaynews intenta almacenar el articulo en el correspondiente directorio en el area de cola de noticias. Si no existe este directorio, se crea. El identificador del mensaje del articulo sera entonces registrado en el fichero history. De otra manera, relaynews elimina el mensaje. Si relaynews falla al almacenar un articulo entrante porque un grupo al que sido enviado no esta listado en su fichero activo, el articulo sera movido al grupo junk.1 relaynews tam- bien comprobara articulos caducados o mal fechados y los rechazara. Los lotes entrantes que fallan por cualquier razon son movidos a /var/spool/news/in.coming/bad, y es registrado un mensaje de error. Despues de esto, el articulo sera transmitido a todos los otros servidores que soliciten noticias de estos grupos, usando el transporte especificado para cada servidor determinado. Para estar seguro de que no es enviado a un servidor que ya lo ha visto, cada servidor de destino es comparado con el campo Path: de cabecera del articulo, el cual contiene la lista de servidores hasta los que el articulo ha llegado, escritos en notacion de camino UUCP con signos de admiracion. Solo si el nombre del servidor de destino no aparece en esta lista el articulo le sera enviado. C-News es usado comunmente para transmitir noticias entre servidores UUCP, aunque es tambien posible usarlo bajo un entorno NNTP. Para entregar noticias a un servidor remoto UUCP _ tanto un solo articulo como lotes enteros _ uux es usado para ejecutar el comando rnews en el servidor remoto, y entregarle el articulo o lote por su entrada estandar. Cuando el proceso por lotes esta permitido para un servidor dado, C-News no manda inmediatamente ningun articulo entrante, sino que anexiona su nombre de camino a un fichero, usualmente out.going/nodo/togo. Periodicamente, un programa por lotes es ejecu- tado desde la linea de una tabla de tareas planeadas , 2 3 lo que situa a los articulos en uno o mas ficheros, opcionalmente los comprime, y los manda a rnews en el servidor remoto. La figura 17.1 muestra las noticias fluyendo a traves de relaynews. Los articulos deben ser transmitidos al servidor local (denotado por ME ), a algun servidor llamado ponderosa via correo electronico, y a un servidor llamado moria, para el cual el proceso por lotes _____________________________________________1 Debe haber una diferencia entre los grupos que existen en su servidor, y aquellos que su servidor esta preparado para recibir. Por ejemplo, la lista de subscripcion debe especificar comp.all, lo que significa todos los grupos de noticias bajo la jerarquia comp, pero en su servidor, solo un numero de grupos comp son listados en activo. Los articulos enviados a esos grupos seran movidos a junk. 2 N. del T.: crontab 3 Note que esto deberia ser la tabla de tareas planeadas del usuario noticias, para no destrozar los permisos de los ficheros. _______________________________________________________________________________________________________________17.2. * *Instalacion @ esta permitido. articulo relaynews historia ME ponderosa moria correo activo dir. spooling out.going/ moria/togo Figura 17.1: Flujo de noticias mediante relaynews. 17.2 Instalacion Para instalar C-News, descomprima con tar los ficheros en el lugar apropiado, si no lo ha hecho todavia, y edite los ficheros de configuracion listados abajo. Todos estan situados en /usr/lib/news. Sus formatos seran descritos en las siguientes secciones. sys Probablemente Ud. tendra que modificar la linea ME que describe su sis- tema, aunque usar all/all es tambien una apuesta segura. Ud. tambien tendra que a"nadir una linea por cada servidor al que quiera mandar noti- cias. Si Ud. es un servidor hoja, solo necesita una linea que mande todos los articulos generados localmente a su fuente. Suponga que su fuente es moria, entonces su fichero sys deberia parecerse a: ME:all/all:: moria/moria.orcnet.org:all/all,!local:f: organization El nombre de su organizacion. Por ejemplo, "Cervecera Virtual, Inc.". En su maquina de casa, introduzca "sitio privado", o cualquier cosa que desee. La mayoria de la gente no dira que su servidor esta configurado correctamente hasta que no haya configurado este fichero. _______________________________________________________________________________________________________________17.2. * *Instalacion @ newsgroups mailname El nombre de su servidor de correo, por ejemplo vbrew.com. whoami El nombre de su servidor para propositos de noticias. Con frecuencia, se usa, por ejemplo, el nombre del servidor UUCP. vbrew. explist Probablemente Ud. deberia editar este fichero para reflejar sus tiempos de expiracion preferidos para algun grupo de noticias en especial. El espacio de disco debe jugar un importante papel en esto. Para crear una jerarquia inicial de grupos de noticias, obtenga un fichero active y un fichero newsgroups del servidor que le provee, e instalelos en /usr/lib/news, asegurandose de que son propiedad del usuarios news y tienen un modo de proteccion 664. Elimine todos los grupos to.* del fichero active, y a"nada to.mi servidor y to.sitio proveedor , al igual que junk y control. Los grupos to.* se usan normalmente para intercambiar mensajes ihave/sendme 4 , pero Ud. deberia crearlos tanto si planea usar ihave/sendme como si no. Despues, sustituya todos los numeros de los articulos en el segundo y tercer campo de active usando el siguiente comando: # cp active active.old # sed 's/ [0-9]* [0-9]* / 0000000000 00001 /' active.old > active # rm active.old El segundo comando es una invocacion de sed(1), uno de mis comandos un?x favoritos. Esta invocacion sustituye dos cadenas de digitos por una cadena de ceros y la cadena 000001, respectivamente. Finalmente, cree el directorio de cola de noticias y los directorios usados para noticias entrantes y salientes: # cd /var/spool # mkdir news news/in.coming news/out.going # chown -R news.news news # chmod -R 755 news Si Ud. esta usando una version de C-News mas reciente, debera crear el directorio out.master en el directorio de cola de noticias. Si esta usando lectores de noticias de una distribucion diferente de la de C-News, puede descubrir que algunos de ellos esperan encontrar la cola de noticias en /usr/spool/news en _____________________________________________4 N. del T.: Tengo/Enviame _______________________________________________________________________________________________________________17.3. * *El fichero sys @ vez de en /var/spool/news. Si su lector de noticias no parece encontrar ningun articulo, cree un enlace simbolico de /usr/spool/news a /var/spool/news. Ahora, Ud. esta preparado para recibir noticias. Note que no tiene que crear ningun otro directorio mas que los vistos arriba, porque cada vez que C-News recibe un articulo de un grupo para el que todavia no hay directorio de cola, lo crea. En particular, esto le ocurre a todos los grupos a los que se ha enviado un articulo cruzado. Asi que, despues de un cierto tiempo, encontrara su cola de noticias llena con directorios para grupos de noticias a los que Ud. nunca se ha subscrito, como alt.lang.teco. Puede evitar esto tanto borrando todos los grupos no deseados de active, como ejecutando regularmente un script del shell que borre todos los directorios vacios de /var/spool/news (excepto out.going y in.coming, por supuesto). C-News necesita un usuario a quien mandar los mensajes de error y los informes de estado. Por defecto, este es usenet. Si usa el valor por defecto, tiene que establecer un alias parael, el cual remite todo su correo a una o mas personas responsables. (Los capitulos 14 y 15 explican como hacerlo para smail y sendmail ). Tambien puede modificar este comportamiento estableciendo la variable de entorno NEWSMASTER con el nombre apropiado. Debe hacerlo en el fichero de la tabla de tareas planeadas de noticias, asi como cada vez que invoque manualmente una herramienta administrativa, por lo que instalar un alias es probablemente mas facil. Aprovechando que esta modificando /etc/passwd, asegurese de que cada usuario tiene su nombre real en el campo pw_gecos del fichero de contrase"na (este es el cuarto campo). Es una cuestion de normas de etiqueta de Usenet el que el nombre real del remitente aparezca en el campo From: del articulo. Por supuesto, Ud. querra hacerlo de cualquier manera cuando use el correo. 17.3 El fichero sys El fichero sys, situado en /usr/lib/news, controla que jerarquias recibe y remite a otros servidores. Aunque hay herramientas de mantenimiento llamadas addfeed y delfeed, creo que es mejor mantener este fichero a mano. El fichero sys contiene entradas para cada servidor al que Ud. reenvia noticias ademas de descripciones de los grupos de noticias que Ud. acepta. Una entrada se parece a: sitio [/exclusiones ]:listagrupos [/listadist ] [:flags [:cmds ]] Las entradas pueden continuar a lo largo de varias lineas usando una barra invertida (\). Una almohadilla (#) denota un comentario. _______________________________________________________________________________________________________________17.3. * *El fichero sys @ sitio Este es el nombre de los servidores a los que se aplica la entrada. Usualmente se elige el nombre del servidor UUCP para esto. Tiene que haber tambien una entrada para su servidor en el fichero sys, si no no recibira ningun articulo. El nombre especial de servidor ME indica su servidor. La entrada ME define todos los grupos de noticias que Ud. esta preparado para almacenar localmente. Los articulos que no concuerden con la linea ME iran al grupo junk. Puesto que C-News compara el servidor con los nombres de los servidores en la cabecera del campo Path:, hay que estar seguro de que realmente coinciden. Algunos servidores usan su nombre de dominio completamente cualificado en este campo, o un alias como news.sitio.dominio . Para prevenir que cualquier articulo regrese a estos servidores, tiene que a"nadir esto a la lista de exclusion, separada por comas. Por ejemplo, para la entrada aplicada al servidor moria, el campo del ser- vidor contendria moria/moria.orcnet.org. listagrupos Esta es una lista de subscripcion, separada por comas, de grupos y jerarquias para ese servidor en particular. Una jerarquia debe especificarse dando el prefijo de la jerarquia (como comp.os para todos los grupos cuyos nombres empiezan con este prefijo), seguido opcionalmente por la palabra clave all (por ejemplo, comp.os.all). Para excluir una jerarquia o grupo de reemision, debe ser precedido con una exclamacion. Si un grupo de noticias encaja con mas de una definicion de la lista, se aplica el emparejamiento mas larga. Por ejemplo, si la listagrupos contiene !comp,comp.os.linux,comp.folklore.computers ningun grupo de la jerarquia comp excepto comp.folklore.computers y todos los grupos bajo comp.os.linux seran administrados a ese servidor. Si el servidor requiere que se le reenvien todas las noticias que Ud. recibe, introduzca all como listagrupos . listadist esta separado de listagrupos por un barra inclinada, y contiene una lista de distribuciones para ser reenviada. Ud. puede de nuevo excluir ciertas distribuciones precediendolas con una exclamacion. Todas las distribuciones se denotan con all. El omitir listadist implica una lista de all. Por ejemplo, puede usar una lista de distribucion de all,!local para impedir que las noticias de uso solo local sean enviadas a servidores remotos. _______________________________________________________________________________________________________________17.3. * *El fichero sys @ Usualmente hay al menos dos distribuciones: world, que es a menudo la distribucion por defecto usada cuando el usuario no especifica nada, y lo- cal. Puede haber otras distribuciones que se empleen para una cierta re- gion, estado, pais, etc. Finalmente, hay dos distribuciones usadas solamente por C-News;estas son sendme y ihave, y son usadas para el protocolo iha- ve/sendme. El uso de distribuciones es materia de debate. Para unos, algunos lectores de noticias crean falsas distribuciones simplemente usando la jerarquia de al- to nivel, por ejemplo comp cuando se envia un mensaje a comp.os.linux. Las distribuciones que se emplean en regiones son a menudo tambien cues- tionables, porque las noticias deben viajar fuera de su region cuando son enviadas a traves de Internet.5 Sin embargo, las distribuciones empleadas para una organizacion, son muy significativas, por ejemplo para evitar la salida de informacion confidencial de la red de la compa"nia. No obstante, este proposito generalmente se consigue mejor creando un grupo de noticias o una jerarquia separados. flags este campo describe ciertos parametros para la fuente. Puede estar vacio, o ser una combinacion de lo siguiente: F Este flag permite el proceso por lotes. f Este es casi identico al flag F, pero permite a C-News calcular el tama"no de los lotes salientes con mas precision. I Este flag hace que C-News produzca una lista de articulos apta para ser usada por el protocolo ihave/sendme. Hay que hacer modificaciones adicionales al fichero sys y al fichero batchparms para habilitar ihave/sendme. n Este flag crea ficheros por lotes para clientes de transferencia NNTP activa como nntpxmit (ver capitulo 18). Los ficheros por lotes contienen el nombre de fichero del articulo junto con su identificador de mensaje. L Este flag indica a C-News que solo transmita los mensajes generados en su servidor. Este flag puede ir ser seguido por un numero decimal n , el cual hace que C-News solo transfiera articulos generados a n saltos desde su servidor. C-News determina el numero de saltos a partir del campo Path:. _____________________________________________5 No es infrecuente para un articulo enviado en, digamos Hamburgo, ir a Frankfurt via reston.ans.net en Holanda, o inclusive via algun servidor en E.E.U.U. _______________________________________________________________________________________________________________17.3. * *El fichero sys @ u Este flag indica a C-News que procese por lotes solo los articu- los de los grupos no moderados. m Este flag indica a C-News que procese por lotes solo los articu- los de los grupos moderados. Debe usar a lo sumo uno de F, f, I, o n. cmds Este campo contiene un comando a ser ejecutado para cada articulo, a menos que el proceso por lotes este habilitado. El articulo sera suministrado al comando a traves de la entrada estandar. Esto solo deberia usarse para fuentes muy peque"nas; de otra manera la carga en ambos sistemas seria demasiado alta. El comando por defecto es uux - -r -z system !rnews lo que invoca rnews en el sistema remoto, administrando el articulo mediante la entrada estandar. El camino de busqueda por defecto para los comandos indicados en este cam- po es /bin:/usr/bin:/usr/lib/news/bin/batch. Elultimo directorio contiene un un cierto numero de guiones del interprete de comandos cuyos nombres empiezan por via; se describen brevemente mas adelante en este mismo capitulo. Si el proceso por lotes esta habilitado usando bien los flags F o f, I o n, C-News espera encontrar un nombre de fichero en este campo en vez de un comando. Si el nombre de fichero no empieza con una barra inclinada (/ ), se supone que es relativo a /var/spool/news/out.going. Si el campo esta vacio, su valor por defecto es system /togo. Cuando configure C-News, probablemente tendra que escribir su propio fichero sys. Para ayudarle con ello, incluimos abajo un fichero de ejemplo para vbrew.com, del cual puede copiar lo que necesite. # Tomamos lo que nos dan. ME:all/all:: # Enviamos todo lo que recibimos a moria, excepto los articulos locales y # relacionados con cerveceras. Usamos proceso por lotes. moria/moria.orcnet.org:all,!to,to.moria/all,!local,!brewery:f: # Mandamos comp.risks a jack@ponderosa.uucp _______________________________________________________________________________________________________________17.4. * *El fichero active @ ponderosa:comp.risks/all::rmail jack@ponderosa.uucp # swim obtiene solo algunos grupos swim/swim.twobirds.com:comp.os.linux,rec.humor.oracle/all,!local:f: # Guardar los articulos de mapas de correo para procesarlos luego usenet-maps:comp.mail.maps/all:F:/var/spool/uumaps/work/batch 17.4 El fichero active El fichero active esta situado en /usr/lib/news y lista todos los grupos conocidos en su servidor, y los articulos disponibles actualmente. Rara vez tendra que tocarlo, pero, sin embargo, lo explicamos por completitud. Las entradas tiene la siguiente forma: gruponoticias alto bajo perm gruponoticias es, por supuesto, el nombre del grupo. bajo y alto son los numeros mas bajo y mas alto de los articulos actualmente disponibles. Si no hay ninguno disponible en ese momento, bajo es igual a alto +1. Al menos, eso es lo que el campo bajo pretende hacer. Sin embargo, por razones de eficiencia, C-News no actualiza este campo. Esto no seria una gran perdida si no hubiera algunos lectores de noticias que dependen deel. Por ejemplo, trn comprueba este campo para ver si puede purgar cualquier articulo de su base de datos de hilos. Para actualizar el campo bajo , tiene por lo tanto que ejecutar regularmente el comando updatemin (o, en una version mas antigua de C-News, la macro upact ). perm es un parametro que detalla el tipo de acceso que los usuarios tienen concedido en el grupo. Toma uno de los siguientes valores: y Se permite a los usuarios enviar articulos a este grupo. n No esta permitido a los usuarios enviar articulos a este grupo. Sin embargo, el grupo puede todavia ser leido. x Este grupo ha sido deshabilitado localmente. Esto ocurre algunas veces cuando los administradores de noticias (o sus superiores) se ofenden por articulos enviados a ciertos grupos. Los articulos recibidos para estos grupos no son almacenados localmente aunque son reenviados a los servidores que los piden. _______________________________________________________________________________________________________________17.5. * *Procesado de articulos p@ m Esto denota un grupo moderado. Cuando un usuario intenta enviar un articulo a este grupo, un lector de noticias inteligente lo notificara al usuario, y en su lugar enviara el articulo al moderador. La direccion del moderador se toma del fichero moderators de /usr/lib/news. =real-group Esto marca a newsgroup como un alias local para otro grupo, a saber real-group . Todos los articulos enviados a gruponoticias seran rediri- gidos ael. En C-News, generalmente no tendra que acceder directamente a este fichero. Los gru- pos deben ser a"nadidos o borrados localmente usando addgroup y delgroup (ver abajo en la seccion Herramientas y Tareas de Mantenimiento). Cuando se a"naden o borran gru- pos para la Usenet entera, esto se hace habitualmente por medio de un mensaje de con- trol newgroup o rmgroup, respectivamente. Alguna vez se ha preguntado como librarse del articulo "", a lo que el servidor responde con un codigo que indica si ya tiene el articulo o si lo quiere. En elultimo caso, el cliente envia el articulo, terminado en un solo punto en una linea separada. Empujar las noticias tiene la unica desventaja de que consume muchos recursos del servidor, ya queeste tiene que buscar en su archivo historico para cada articulo. La tecnica opuesta es tirar de las noticias, en la que el cliente solicita una lista de todos los articulos disponibles en un grupo que hayan llegado despues de una fecha especificada. La consulta es llevada a cabo por el comando NEWNEWS. De la lista de identificativos de mensaje obtenida, el cliente selecciona aquellos que aun no tenga, usando el comando ARTICLE para obtener cada uno de ellos. El problema de esta tecnica es que necesita un estricto control por parte del servidor, que debe tener en cuenta que grupos y distribuciones permite solicitar al cliente. Por ejemplo, debe asegurarse de que ningun material confidencial de sus grupos locales sea enviado a clientes no autorizados. Existe tambien cierto numero de comandos convenientes para los lectores de noticias que permiten obtener la cabecera del articulo y el cuerpo del mismo separadamente, o incluso solo ciertos campos de la cabecera de un rango de articulos. Esto permite mantener todas las noticias en un servidor central, con todos los usuarios de la red (presumiblemente local) utilizando programas clientes basados en el NNTP para leer y publicar. Esto es una alternativa a exportar los directorios mediante NFS tal como se describe en el capitulo 17. Un problema extendido en NNTP es que permite a gente con los conocimientos sufi- cientes insertar articulos con remitentes falsos en el flujo de noticias. Esto se conoce como falsificar las noticias.4 Una extension del NNTP permite requerir autentificacion del usuario para ciertos comandos. Hay cierto numero de paquetes NNTP disponibles. Uno de los mas conocidos es el demonio NNTP, tambien conocido como la implementacion de referencia. Fue escrito ori- ginalmente por Stan Barber y Phil Lapsley para ilustrar los detalles de la RFC 977. Su version mas reciente es nntpd-1.5.11, que se describira a continuacion. Usted puede obtener el codigo fuente y compilarlo por su cuenta, o usar el nntpd del paquete binario net-std de Fred van Kempen. No se proporcionan ejecutables del nntpd listos para funcionar, ya que varios valores especificos de cada sistema deben ser introducidos antes de la compilacion. _____________________________________________4 El mismo problema existe con el SMTP, el Simple Mail Transfer Protocol (Protocolo Simple para Trans- ferencia de Correo). _______________________________________________________________________________________________________________18.2. * *Instalacion del servidor@ El paquete nntpd consiste en un servidor y dos clientes para empujar y tirar de las noticias, respectivamente, asi como un sustituto para inews. Estan pensados para trabajar en el entorno de Bnews, pero trabajandoselo un poco lo haran con Cnews sin demasiada dificultad. Sin embargo, si planea Vd. usar el NNTP para algo mas que ofrecer acceso a su servidor a los lectores de noticias, la implementacion de referencia no es realmente una opcion. Por tanto, discutiremos solamente el demonio NNTP contenido en el paquete nntpd, dejando de lado los programas clientes. Tambien hay un paquete llamado "InterNet News", o INN para abreviar, escrito por Rich Salz. Este paquete proporciona tanto transporte NNTP como UUCP, y es el mas ade- cuado para grandes servidores. En lo que a transporte NNTP se refiere, es definitivamente mejor que nntpd. La version actual de INN es inn-1.4sec. Existe un paquete de Arjan de Vet para construir INN en una maquina Linux; esta disponible en sunsite.unc.edu en el directorio system/Mail. Si quiere configurar INN, por favor remitase a la documenta- cion que acompa"na al codigo fuente, asi como al FAQ de INN, publicado regularmente en news.software.b. 18.2 Instalacion del servidor NNTP El servidor NNTP se llama nntpd, y puede ser compilado de dos maneras, segun el trafico que se espera que soporte el sistema de noticias. No hay versiones compiladas disponibles, ya que algunos valores por defecto dependientes del sistema en que se vaya a instalar deben ser especificados antes de la compilacion. Toda la configuracion se hace a traves de macros #define en common/conf.h. nntpd puede ser configurado como un servidor independiente que se inicie desde rc.inet2 al arrancar, o como un demonio controlado por inetd. En el ultimo caso se tendra que a"nadir la siguiente entrada en /etc/inetd.conf : nntp stream tcp nowait news /usr/etc/in.nntpd nntpd Si configura Vd. nntpd como servidor independiente, asegurese de que la linea anterior esta comentada en inetd.conf. En cualquier caso, tendra Vd. que asegurarse de que existe la siguiente linea en /etc/services: nntp 119/tcp readnews untp # Network News Transfer Protocol Para almacenar temporalmente los articulos que llegan al sistema, etc, nntpd tambien necesita un subdirectorio .tmp en el directorio de almacenamiento de noticias. Puede Vd. crearlo usando _______________________________________________________________________________________________________________18.3. * *Restricciones de acceso @ # mkdir /var/spool/news /.tmp # chown news.news /var/spool/news /.tmp 18.3 Restricciones de acceso NNTP El acceso a los recursos NNTP se rige por el fichero nntp_access en /usr/lib/news. Las lineas del fichero describen los derechos de acceso para ordenadores ajenos. Cada linea tiene el siguiente formato: site read|xfer|both|no post|no [!exceptgroups] Si un cliente se conecta al puerto NNTP, nntpd intenta obtener su nombre completo en la red a partir de su direccion IP. El nombre del ordenador del cliente y su direccion IP son contrastados con el campo site de cada entrada, en el mismo orden en el que aparecen en el fichero. Las coincidencias pueden ser parciales o exactas. Si una entrada coincide exactamente, se aplica; si la coincidencia es parcial, solo se aplica si no hay otra entrada posterior igual o mejor. site puede especificarse de una de las siguientes formas: nombre del ordenador Este es el nombre completo del ordenador. Si coincide literalmente con el nombre canonico del cliente, se aplica directamente esta entrada ignorandose las siguientes. direccion IP Esta es la direccion IP representada por cuatro numeros separados por pun- tos. Si la direccion IP del cliente coincide con ella, se aplica la entrada ignorandose las siguientes. nombre del dominio Esto es un nombre de dominio, especificado como *.dominio . Si el dominio del cliente coincide conel, se aplica la entrada. nombre de la red Esto es el nombre de una red tal y como se especifica en /etc/networks. Si el numero de red de la direccion IP del cliente coincide con el numero de red asociado al nombre de la red, se aplica la entrada. default Es la entrada por omision; se aplica a cualquier cliente. Las entradas con especificaciones mas generales deberian ser introducidas al principio del fichero, ya que despues pueden ser descartadas al encontrarse mejores coincidencias en entradas posteriores. _______________________________________________________________________________________________________________18.4. * *Autorizacion NNTP @ Los campos segundo y tercero describen los derechos de acceso que se otorgan al cliente. El segundo detalla los permisos de lectura (read ) y transmision por empuje (xfer ) de noticias. El valor both habilita ambos, el valor no niega el acceso a los dos. El tercer campo detalla si el cliente puede publicar articulos, es decir, enviar articulos con informacion incompleta en la cabecera que sera completada por los programas de noticias. Si el segundo campo contiene no, el tercero es ignorado. El cuarto campo es opcional. Contiene una lista de grupos separados por comas a los que el cliente no puede acceder. A continuacion se muestra un fichero nntp_access de ejemplo: # # por defecto, cualquiera puede transferir noticias, pero no # leerlas o publicarlas default xfer no # # public.vbrew.com ofrece acceso publico via modem, asi que les # dejamos leer y publicar en cualquier grupo menos en los local.* public.vbrew.com read post !local # # el resto de ordenadores de vbrew.com puede leer y publicar *.vbrew.com read post 18.4 Autorizacion NNTP Al poner en mayusculas los elementos del fichero nntp_acces, tales como xfer o read, nntpd exige que el cliente este autorizado para realizar dichas operaciones. Por ejemplo, si se especifica el permiso Xfer o XFER, nntpd no dejara transmitir articulos al cliente a menos queeste acredite que esta autorizado. El proceso de autorizacion se lleva a cabo por un nuevo comando del NNTP llama- do AUTHINFO. Usando este comando, el cliente transmite un nombre de usuario y una contrase"na al servidor NNTP. nntpd los validara comprobando el fichero /etc/passwd, y verificando que el usuario pertenece al grupo nntp. Lo actual implementacion de la autorizacion NNTP es solo experimental, por lo que no se ha hecho muy portable. Por ello solo funcionara con ficheros /etc/passwd normales; el shadow password no esta soportado. _______________________________________________________________________________________________________________18.5. * *Interaccion de nntpd co@ 18.5 Interaccion de nntpd con Cnews Cuando recibe un articulo, nntpd debe pasarlo al sistema de noticias. Dependiendo de si lo recibio mediante el comando IHAVE o el POST, lo enviara a rnews o inews, respectivamen- te. En vez de llamar a rnews, nntpd tambien puede configurarse (antes de la compilacion) para empaquetar los articulos entrantes, y dejar los paquetes resultantes en el directorio /var/spool/news/in.coming, donde seran procesados por relaynews la proxima vez que se le invoque. Para llevar a cabo conexito el protocolo ihave/sendme, nntpd tiene que poder acceder al fichero historico history. Por tanto, antes de la compilacion hay que asegurarse de que la ruta a dicho fichero esta correctamente especificada. Tambien hay que asegurarse de que Cnews y nntpd usen el mismo formato de fichero historico. Cnews usa funciones dbm para acceder al fichero; sin embargo hay bastantes implementaciones ligeramente incompatibles de la libreria dbm. Si Cnews esta enlazado con una libreria dbm distinta a la de libc, tambien debera enlazarse nntpd con dicha libreria. Un sintoma tipico de que nntpd y Cnews discrepan en el formato del fichero historico son los mensajes de error de que nntpd no puede abrirlo, o la recepcion de articulos duplicados por NNTP. Una prueba conveniente es coger un articulo del sistema, hacer telnet por el puerto del nntpd, y ofrecerselo a nntpd tal como se muestra en el ejemplo de abajo. Por supuesto, debera reemplazarse con el identificativo del articulo que quiera ofrecerse a nntpd. $ telnet localhost nntp Trying 127.0.0.1... Connected to loalhost Escape characters is '^]'. 201 vstout NNTP[auth] server version 1.5.11t (16 November 1991) ready at Sun Feb 6 16:02:32 1194 (no posting) IHAVE 435 Got it. QUIT Este dialogo muestra la reaccion correcta de nntpd : el mensaje "Got it" indica que ya tiene dicho articulo. En cambio, si se obtuviese un mensaje como "335 Ok", significaria que nntpd no ha podido acceder adecuadamente al fichero historico. Cierre la sesion telnet con Ctrl-D. Puede comprobar que ha ido mal revisando el archivo de registro (log) del sistema; nntpd envia todo tipo de mensajes a syslog. El uso de una libreria dbm incompatible suele reflejarse en un mensaje que indica que dbminit ha fallado. Capitulo 19 Configuracion del lector de noticias Los lectores de noticias estan pensados para ofrecer al usuario un acceso facil a las funciones de un sistema de noticias, tales como publicar articulos, o purgar los contenidos de un grupo de una manera comoda. El mayor o menor acierto en cumplir este objetivo es objeto de interminables discusiones en los grupos de noticias. Algunos de los lectores disponibles que han sido portados a Linux. A continuacion se describira la instalacion basica para tres de los mas populares: tin, trn, y nn. Uno de los lectores mas efectivos es $ find /var/spool/news -name '[0-9]*' -exec cat {} \; | more Asi es como los unixeros a ultranza leen sus noticias. La mayoria de los lectores de noticias, sin embargo, son mucho mas sofisticados. Gene- ralmente ofrecen un interfaz a pantalla completa con niveles separados para mostrar todos los grupos a los que el usuario esta suscrito, para mostrar una lista de todos los articulos de un grupo, y para articulos individuales. En el nivel del grupo, la mayoria de los lectores muestran una lista de articulos en la que aparece el tema de los mismos y el autor. En los grupos grandes es imposible para el usuario caer en la cuenta de los articulos que se refieren unos a otros, aunque es posible identificar las respuestas a un articulo anterior. Una respuesta normalmente repite el titulo del articulo original precedido por "Re: ". Adicionalmente, el identificativo del mensaje al que se responde puede indicarse en el campo References:. Ordenar los articulos por esos dos criterios genera peque"nosarboles llamados hebras1. Una de las tareas al escribir un lector de noticias es dise"nar un algoritmo eficiente _____________________________________________1 N. del T.: Son los llamados popularmente threads 301 _______________________________________________________________________________________________________________19.1. * *Configuracion de tin @ para ordenar los articulos, ya que el tiempo requerido para ello es proporcional al cuadrado del numero de articulos. No discutiremos aqui como se construyen los interfaces de usuario. Todos los lectores actualmente disponibles para Linux tienen una buena funcion de ayuda, asi que el usuario puede apa"narselas solo. En lo sucesivo, solo trataremos cuestiones administrativas. La mayoria de ellas relacio- nadas con la creacion de bases de datos y contabilidad. 19.1 Configuracion de tin El lector mas versatil en lo que al tratamiento de las hebras se refiere es tin. Fue escrito por Iain Lea siguiendo el modelo de un lector anterior llamado tas.2 Ordena las hebras en el momento en el que el usuario accede al grupo, y es muy rapido haciendolo, salvo que se haga por NNTP. En un 486DX50 se tarda unos 30 segundos en ordenar mil articulos, leyendolos di- rectamente desde el disco. Mediante NNTP con un servidor ocupado, rondaria los cinco minutos.3 Se puede mejorar este tiempo actualizando regularmente los ficheros indice con la opcion -u, o llamando a tin con la opcion -U. Normalmente tin guarda la informacion sobre las hebras en el directorio del usuario, bajo .tin/index. Esto puede ser costoso en terminos de espacio en disco, asi que es posible que quiera Vd. mantener una sola copia para todos los usuarios. Esto se puede lograr haciendo a tin setuid news, por ejemplo, o algun otro usuario sin privilegios.4 tin guardara todos los ficheros indice bajo /var/spool/news/.index. Para los accesos a ficheros o salidas al shell, volvera a ser del usuario real que lo invoco.5 Una solucion mejor es instalar el demonio indexador tind, que se ejecuta como tarea de fondo y actualiza regularmente los ficheros indice. Sin embargo, este demonio no se incluye en ninguna distribucion para Linux, asi que tendra que compilarlo Vd. mismo. Si esta Vd. trabajando con una red local con un servidor central de noticias, puede ejecutar tind en el servidor, y hacer que los clientes reciban los indices por NNTP. Esto, por supuesto, requiere una extension del NNTP. Los parches necesarios para que nntpd soporte esta extension se incluyen en las fuentes de tin. _____________________________________________2 Escrito por Rich Skrenta. 3 El tiempo se reduce drasticamente si el servidor NNTP crea las hebras por si mismo y permite al cliente recibir estos datos. Un servidor que permite hacer esto es INN-1.4, por ejemplo. 4 Sin embargo, no utilice el usuario nobody. Como norma, ningun fichero o programa deberia ser asociado con este usuario. 5 Esta es la razon por la que se obtendran feos mensajes de error al invocar a tin como superusuario. De todas formas, no se deberia trabajar como root, es una cuenta para administracion. _______________________________________________________________________________________________________________19.2. * *Configuracion de trn @ La version de tin incluida en algunas distribuciones de Linux no tiene soporte NNTP, pero la mayoria si lo incorporan. Cuando se le invoca como rtin o con la opcion -r, tin trata de conectar con el servidor especificado en el fichero /etc/nntpserver o en la variable de entorno NNTPSERVER. El fichero nntpserver simplemente contiene el nombre del servidor en una sola linea. 19.2 Configuracion de trn trn es tambien el sucesor de un programa anterior, rn (siglas de read news6). La "t" en su nombre significa threaded7. Fue escrito por Wayne Davidson. Al contrario que tin, trn no tiene opcion para generar bases de datos sobre las hebras en el momento de ejecucion. En cambio, usa las bases de datos creadas por un programa llamado mthreads, el cual debe ser ejecutado regularmente desde cron para actualizar los ficheros indice. No ejecutar mthreads, sin embargo, no significa que no se pueda acceder a los articulos nuevos, solo significa que tendra Vd. todos esos articulos sobre "<. # Ejemplo de archivo /usr/lib/smail/transports # local - envia correo a los usuarios locales local: driver=appendfile, # agrega el mensaje al archivo return_path, # incluir un campo Return-Path: from, # proveer una linea de sobre con From_ unix_from_hack, # insertar > antes de From en el cuerpo local; # usar formatos locales para el envio file=/var/spool/mail/${lc:user}, # posicion del archivo buzon group=mail, # el grupo propietario del archivo # para System V mode=0660, # el grupo mail puede acceder _______________________________________________________________________________________________________________APENDICE* *S @ suffix="\n", # agregar un cambio de linea extra # pipe - enviar el correo a traves de comandos de shell pipe: driver=pipe, # encauzar el mensaje hacia otro programa return_path, # incluir un campo Return-Path: from, # proveer una linea de sobre con From_ unix_from_hack, # insertar > antes de From en el cuerpo local; # usar formatos locales para el envio cmd="/bin/sh -c $user", # enviar las direcciones al shell Bourne parent_env, # info de entorno a partir de la direccion # del padre pipe_as_user, # usar user-id asociado con la direccion ignore_status, # ignore un status de salida distinto de cero ignore_write_errors, # ignore errores de escritura, # por ejemplo: tuberia cortada umask=0022, # umask para el proceso hijo -log_output, # no registrar stdout/stderr en el # archivo de registro # file - enviar el correo a archivos file: driver=appendfile, return_path, # incluir un campo Return-Path: from, # proveer una linea de cabecera con From_ unix_from_hack, # insertar > antes de From en el cuerpo local; # usar formatos locales para el envio file=$user, # el nombre del archivo se toma de # la direccion append_as_user, # usar el user-id asociado con la direccion expand_user, # expandir ~ y $ dentro de la direccion suffix="\n", # agregar un cambio de linea extra mode=0600, # poner los permisos en 600 # uux - envios al programa rmail de una instalacion UUCP remota uux: driver=pipe, uucp, # usar formatos de direcciones estilo UUCP from, # proveer una linea de sobre con Form_ max_addrs=5, # maximo 5 direcciones por invocacion max_chars=200; # maximo 200 caracteres en direccion cmd="/usr/bin/uux - -r -a$sender -g$grade $host!rmail $(($user)$)", pipe_as_sender, # que los registros uucp registren al llamador log_output, # guardar las salidas de error para # los mensajes rebotados # defer_child_errors, # reintentar si uux retorna un error _______________________________________________________________________________________________________________APENDICE* *S @ # demand - envios al programa rmail remoto, el sondeo es inmediato demand: driver=pipe, uucp, # usar formatos de direcciones estilo UUCP from, # proveer una linea de sobre con Form_ max_addrs=5, # maximo 5 direcciones por invocacion max_chars=200; # maximo 200 caracteres en direccion cmd="/usr/bin/uux - -a$sender -g$grade $host!rmail $(($user)$)", pipe_as_sender, # que los registros uucp registren al llamador log_output, # guardar las salidas de error para # los mensajes rebotados # defer_child_errors, # reintentar si uux retorna un error # hbsmtp - half-baked BSMTP. Los archivos de salida deben procesarse # regularmente y enviarse via UUCP. hbsmtp: driver=appendfile, inet, # usar direccionamiento RFC 822 hbsmtp, # SMTP por lotes sin HELO ni QUIT -max_addrs, -max_chars; # no hay limite en el numero de direcciones file="/var/spool/smail/hbsmtp/$host", user=root, # el archivo es propiedad de root mode=0600, # solo legible-escribible por root. # smtp - envios utilizando SMTP sobre TCP/IP smtp: driver=tcpsmtp, inet, -max_addrs, -max_chars; # no hay limite en el numero de direcciones short_timeout=5m, # timeout para operaciones breves long_timeout=2h, # timeout para operaciones SMTP # de mayor duracion service=smtp, # conectar a este puerto de servicio # Para uso en internet: descomente las siguientes 4 lineas # use_bind, # resolver MX y registros A multiples # defnames, # usar busqueda de dominio estandar # defer_no_connect, # reintentar si el servidor de nombres # # no esta activo # -local_mx_okay, # no usar MX con el sistema local Apendice C The GNU General Public License Printed below is the GNU General Public License (the GPL or copyleft), under which Linux is licensed. It is reproduced here to clear up some of the confusion about Linux's copyright status_ Linux is not shareware, and it is not in the public domain. The bulk of the Linux kernel is copyright Oc 1993 by Linus Torvalds, and other software and parts of the kernel are copyrighted by their authors. Thus, Linux is copyrighted, however, you may redistribute it under the terms of the GPL printed below. GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. C.1 Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software-to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights 316 _______________________________________________________________________________________________________________C.2. T* *erms and Conditions @ or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. C.2 Terms and Conditions for Copying, Distribution, and Modification 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Pro- gram" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. _______________________________________________________________________________________________________________C.2. T* *erms and Conditions @ 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c. Accompany it with the information you received as to the offer to distribute correspon- ding source code. (This alternative is allowed only for noncommercial distribution and _______________________________________________________________________________________________________________C.2. T* *erms and Conditions @ only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control com- pilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of _______________________________________________________________________________________________________________C.2. T* *erms and Conditions @ protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WA- RRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOL- DERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WA- RRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PER- FORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRI- TING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MO- DIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIA- BLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO _______________________________________________________________________________________________________________C.3. H* *ow to Apply These Terms @ USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DA- TA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PRO- GRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS C.3 Appendix: How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright Oc19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FIT- NESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. _______________________________________________________________________________________________________________C.3. H* *ow to Apply These Terms @ The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items-whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary pro- grams. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. Glosario [Nota: Este glosario esta logicamente incompleto, asi que estoy abierto a cualquier sugerencia.] Una de las mayores dificultades del estudio de las redes de ordenadores, es recordar todas las abreviaturas y terminos que rodean la teleinformatica. Aqui se tratara de mostrar los terminos que se han usado en este libro, junto a una peque"na explicacion.1 ACU Automatic Call Unit, Unidad de Llamada Automatica. Un modem.2 ARP Address Resolution Protocol, Protocolo de Resolucion de Direcciones. Se utiliza para conocer la correspondencia entre direcciones IP y direcciones Ethernet. ARPA Advanced Research Project Agency, posteriormente DARPA. En Castellano seria algo asi como Instituto de Proyectos Avanzados de Investigacion. Es la creadora de Internet. ARPANET Antecesora de lo que hoy es Internet: era una red experimental norteamericana, fundada por el DARPA (Defense Advanced Research Project Agency) que es como el instituto ARPA pero con fines militares. Assigned Numbers Titulo del RFC publicado regularmente y que lista la correspondencia convenida entre numeros de puerto y similares, con respecto a su significado. Por ejemplo, incluye los numeros de servicios bien conocidos (well known) como el puerto de rlogin o SMTP. Laultima version de este RFC es la 1340. BBS Bulletin Board System, Sistema de Boletin electronico. Es un nodo de noticias y correo al que se accede por telefono. BGP Border Gateway Protocol, Protocolo para Pasarelas de Extremo. Es un protoco- lo que sirve para intercambiar informacion de encaminamiento entre los sistemas autonomos. _____________________________________________1 N. del T.: Algunos terminos han sido incluidos por el traductor, y otros actualizados a los tiempos que corren. Algunas traducciones de los nombres de protocolos pueden no ser correctas, asi que ruego nos hagan llegar cualquier sugerencia al respecto. 2 Tambien puede significar un adolescente con un telefono en sus manos. 323 _______________________________________________________________________________________________________________Glosario* * @ BIND Berkeley Internet Name Domain, servidor de Nombres de Dominios de Berkeley. Es una implementacion del servicio DNS. BNU Basic Networking Utilities, Utilidades Basicas de Red. Es el paquete de aplicacio- nes UUCP mas usual en este momento; que tambien se conoce como UUCP de HoneyDanBer. El nombre se deriva de sus autores: P. Honeyman, D.A. Novitz, y B.E. Redman. BSD Berkeley Software Distribution. Es una version de un?x producida en la Universi- dad de Berkeley. CCITT Comitee Consultatif International de Telegraphique et Telephonique, Comite Con- sultivo Internacional de Telefonia y Telegrafia3. Es una organizacion internacional que estudia los estandares para los servicios de telefonia, redes, etc. CSLIP Compressed Serial Line IP, IP por Linea Serie con Compresion. Protocolo para el intercambio de paquetes IP por una linea serie, a"nadiendo compresion de cabeceras a la mayor parte de los datagramas TCP/IP. demonio de encaminamiento La topologia de las redes grandes no es estatica y resulta dificil el mantenimiento de adaptacion de todos los nodos a esos cambios. Por ello se trata de automatizar mediante demonios de encaminamiento usando protocolos como RIP. DNS Domain Name System, Sistema de Nombres de Dominios. Es una base de datos distribuida que se utiliza en Internet para obtener las direcciones IP asociadas a los nombres. EGP External Gateway Protocol, Protocolo para Encaminadores Externo. Es un proto- colo con el mismo fin que el mencionado BGP, es decir, intercambiar informacion de encaminamiento entre sistemas autonomos. Ethernet En sentido coloquial, es el nombre que se le da a una instalacion de red (La ethernet de la Universidad, etc). En realidad, Ethernet es parte de un conjunto de estandares propuestos por el IEEE. Los dispositivos de conexion Ethernet utilizan un solo cable, normalmente coaxial, que permite transferencias de 10 Mbits/segundo. El protocolo utilizado determina como las maquinas tienen acceso al cable.4 FQDN Fully Qualified Domain Name, Nombre de Nodo Totalmente Calificado. Es un nom- bre de nodo completo, es decir, incluyendo el dominio al que pertenece: se encuentra en la base de datos del sistema DNS. FTP File Transfer Protocol, Protocolo de Transferencia de Ficheros. Es uno de los pro- tocolos de TCP/IP mas conocido, pues es el que se usa para enviar ficheros de un lugar a otro de la red. _____________________________________________3 Hoy conocido como ITU, International Telecommunication Union o Union Internacional de Telecomu- nicaciones. 4 Ademas, el protocolo de Ethernet usado normalmente con TCP/IP no es exactamente el que se definio en la norma IEEE 802.3, ya que donde este habla del campo longitud, el otro habla del campo tipo. _______________________________________________________________________________________________________________Glosario* * @ FYI "For Your Information", para su informacion. Documentos mas o menos informales que tratan sobre temas de Internet. GMU Groucho Marx University, la Universidad de Groucho Marx. Universidad que nos hemos inventado en este libro para los ejemplos que ilustran los conceptos que se dan a conocer en este. GNU GNU's not Unix, GNU No es Unix. Acronimo recursivo del proyecto de la Funda- cion del Software Libre (FSF) que pretende proporcionar un conjunto de utilidades tipo un?x, que pueden usarse y distribuirse libremente. Todo el software de GNU esta cubierto por la Licencia Publica General de GNU, o Copyleft. En el apendice C se reproduce dicha Licencia. HoneyDanBer Nombre de una variedad de UUCP. Vease BNU. host En general, un host es un nodo de red, es decir, algo que es capaz de recibir y enviar algun tipo de mensajes en la red. Normalmente sera un ordenador, pero puede ser tambien un terminal X o una impresora de red. ICMP Internet Control Message Protocol, Protocolo de Mensajes de Control de Internet. Es un protocolo utilizado por TCP/IP para devolver informacion de errores al nodo que envia el paquete, etc. IEEE Institute of Electrical and Electronics Engineers, Instituto de Ingenieros Electricos y Electronicos. Es otra organizacion que establece estandares. Desde el punto de vista del usuario de UNIX, lo que interesa es que establece los estandares POSIX que definen aspectos que van desde las llamadas al sistema hasta que comandos de administracion deben existir. Ademas, el IEEE desarrollo las especificaciones para las redes de difusion Ethernet, las de paso de testigo en bus (TokenBus) y en anillo (TokenRing). Finalmente, la representacion interna de coma flotante mas utilizada tambien es un estandar propuesto por el IEEE. IETF Internet Engineering Task Force, Grupo de Ingenieria en Internet. internet Red de redes: union de peque"nas redes de ordenadores. Internet El nombre que se le ha dado a la Internet distribuida por todo el mundo. IP Internet Protocol, protocolo de internet. ISO International Standards Organization, Organizacion Internacional de Estandariza- cion. ISDN Integrated Services Digital Network, Red Digital de Servicios Integrados. Nueva tecnologia para comunicaciones que utiliza circuitos digitales, y esta llamada a sus- tituir a la telefonia tradicional. HTML HiperText Markup Language, Lenguaje de Descripcion de Hipertexto. Es el lenguaje en el que se escriben los documentos que luego se van a transmitir en la WWW _______________________________________________________________________________________________________________Glosario* * @ (veanse, WWW y HTTP). HTTP HiperText Transfer Protocol, Protocolo para Transferencia de HiperTexto. Es el protocolo que se utiliza para transmitir documentos de la WWW a los programas de usuario conocidos como navegadores.5 LAN Local Area Network, red dearea local. MX Mail Exchanger, Intercambiador de Correo. Un tipo de registro DNS que se utiliza para indicar cual es el servidor de correo asociado a un dominio. NFS Network File System, Sistema de Ficheros en Red. Es un protocolo estandar junto con un conjunto de programas que permite acceder a los datos de discos remotos de manera transparente, como si fueran discos locales. NIS Network Information System, Sistema de Informacion de Red. Es una aplicacion basada en RPC que permite compartir ficheros de configuracion como el /etc/passwd entre distintas maquinas. Vease tambien YP. NNTP Network News Transfer Protocol, Protocolo de Transferencia de Noticias. Se utiliza para transmitir noticias a traves de conexiones TCP. nombre canonico de nodo En un sistema DNS, es el nombre principal de una maquina, es decir, establecido mediante un registro DNS tipo A, y es el que se devuelve cuando se hace una peticion de nombre a partir de la direccion IP. octeto En la Internet, este termino se refiere a la cantidad de ocho bits. Se usa en lugar de byte (palabra) debido a que en algunas se tienen palabras de mas de 8 bits. OSI Open Systems Interconnection, Interconexion de Sistemas Abiertos. Es un estandar del ISO acerca del software de red. path En UUCP es sinonimo a ruta (camino seguido por los mensajes). Es tambien lo que hemos llamado ruta de signos de admiracion. PLIP Parallel Line IP, IP por Linea Paralela. Es un protocolo que permite intercambiar paquetes IP usando el puerto de la impresora. puerto, TCP o UDP En TCP y UDP, un puerto es lo que en OSI se conoce como punto de acceso al servicio. Antes de que un proceso acceda o de un servicio de red, debe pedir un puerto (bind). Junto con la direccion IP, identifica totalmente los dos extremos de una conexion TCP. portmapper El portmapper o mapeador de puertos, es el programa que traduce entre numeros de programa RPC y los puertos TCP o UDP por los que escuchan dichos programas. PPP Point-to-point Protocol, Protocolo Punto-a-Punto. Es un protocolo rapido y flexi- _____________________________________________5 Algunas voces se han alzado ya, culpando a HTTP y a su descuidado dise"no, de la actual lentitud de la red. _______________________________________________________________________________________________________________Glosario* * @ ble, usado para intercambiar paquetes IP e IPX a traves de una linea serie (telefono) o incluso sobre un protocolo de nivel de enlace HDLC para su uso en la RDSI. RARP Reverse Address Resolution Protocol, Protocolo de Resolucion Inversa de Direccio- nes. Permite a las maquinas preguntar a la red por su direccion IP cuando se ponen en marcha. Red de almacenamiento-y-reenvio Opuesto al concepto de conmutacion de paquetes. Estas redes transfieren paquetes pero no tienen conexiones permanentes. En su lugar, las maquinas conectan de vez en cuando con el otro extremo y transmiten los datos de una vez. Esto requiere que el nodo tenga capacidad de almacenamiento. Red de Conmutacion de Paquetes Es un tipo de red formada por nodos que se limitan a intercambiarse paquetes entre si de forma segura, de tal forma que en ella se establecen circuitos virtuales permanentes o semipermanentes. red de difusion Es una red que permite a las estaciones enviar datagramas y que sean vistos por varias estaciones a la vez. registro de recurso, RR Es la unidad de informacion en la base de datos DNS. Cada registro es de un tipo, por ejemplo, contiene la direccion IP de una maquina (registro tipo A), o el servidor de correo de un dominio (registro tipo MX). resolutor, sistema de resolucion Es un conjunto de funciones de biblioteca que permiten a los programas obtener las direcciones IP de las maquinas por su nombre, y viceversa. resolucion inversa El acto de obtener un nombre dada la direccion IP. En DNS, dichas direcciones se devuelven como parte del dominio in-addr.arpa. RFC Request for Comments, Peticion de Sugerencias. Son documentos que describen los estandares de Internet. Su nombre procede de que inicialmente eran solo "propues- tas" de los autores, para ser discutidas. RIP Routing Information Protocol, Protocolo de Informacion de Encaminamiento. Es un protocolo de encaminamiento dinamico,utiles en redes no muy grandes. ruta Secuencia de maquinas por las que una unidad de informacion debe pasar para llegar al nodo destino. El proceso de encontrar una ruta apropiada se conoce como encaminamiento. ruta de signos de admiracion En las redes UUCP, la ruta de un sistema a otro se nota mediante nombres y signos de admiracion. Por ejemplo, nodo0!nodo1!nodo2!nodo3 denota que la ruta al sistema nodo3 pasa por nodo0, nodo1 y nodo2. RPC Remote Procedure Call, Llamada a Procedimiento Remoto. Es el mecanismo por el cual se pide la ejecucion de procedimientos en maquinas remotas. _______________________________________________________________________________________________________________Glosario* * @ RR Abreviatura de registro de recurso, en DNS. RS-232 Estandar habitual para enlaces serie. RTS/CTS Nombre coloquial que recibe el control de flujo por hardware, realizado entre dos maquinas que se comunican usando RS-232. El nombre procede de los dos circuitos utilizados, RTS ("Request To Send") y CTS ("Clear To Send"). RTM Internet Worm Un programa a modo de virus que utiliza ciertas caracteristicas de VMS y Unix BSD 4.3 para propagarse por la red. RTM son las siglas de su autor (Ro- bert T. Morris). sitio Conglomerado de nodos que desde fuera se ven como un nodo de la red. Por ejemplo, desde fuera vemos como nodo de Internet a la Universidad de Groucho Marx, cuando en realidad es una red de ordenadores bastante compleja6. SLIP Serial Line IP, IP por Linea Serie. Es un protocolo para intercambiar paquetes IP usando una linea serie. Vease tambien CSLIP. SMTP Simple Mail Transfer Protocol, Protocolo Simple para Transferencia de Correo. Es un protocolo usado para transportar correo mediante conexiones TCP, asi como correo por lotes en UUCP (BSMTP). SOA Start of Authority, Inicio de Autoridad. Es un tipo de registro que existe en la base de datos del DNS. System V Una version de un?x. TCP Transmission Control Protocol, Protocolo de Control de la Conexion. Es un proto- colo de red orientado a la conexion. TCP/IP Abreviatura usada para denotar los protocolos de Internet. UDP User Datagram Protocol, Protocolo de Datagramas de Usuario. Es un protocolo de red no orientado a la conexion. UUCP Unix to Unix Copy, Copiador de Unix a Unix. Es un conjunto de comandos para transporte en red, usado en redes de marcado telefonico. UUCP Version 2 Version evolucionada de UUCP. cerveza virtual Es la bebida preferida de todo Linuxero7. La primera vez que recuerdo verlo escrito fue en la nota sobre la version 0.98.X del nucleo de Linux, donde Linus incluia la "Oxford Beer Trolls" en los creditos como sitio desde donde enviaban cervezas virtuales a cualquiera. well-known services, servicios bien-conocidos El termino se usa para referirse a los servicios de red habituales como telnet o ftp. _____________________________________________6 N. del T: Actualmente, por sitio tambien se conocen a los servidores de WWW o FTP. 7 O casi cualquier Linuxero. El traductor, por ejemplo, prefiere la cerveza real. _______________________________________________________________________________________________________________Glosario* * @ Tecnicamente, son servicios que tienen un numero de puerto asignado en el RFC de Asignacion de Numeros. YP Yellow Pages, Paginas Amarillas. Es el antiguo nombre de lo que hoy se conoce como NIS, dado que el termino Yellow Pages es marca registrada de la British Telecom. Sin embargo, muchas utilidades de NIS se nombran empezando con yp, como los comandos ypcat o ypwhich. WWW World Wide Web, la Telara"na de Ambito Mundial. Es el servicio que ha catapultado a la Internet a la fama. El la WWW se distribuye documentacion de todo tipo, en formato de hipertexto (usando el lenguaje de descripcion HTML), con imagenes, sonido y acceso a ficheros. La WWW se esta convirtiendo en el escaparate con el que muchas empresas pueden dar a conocer sus productos al mundo cibernetico. Bibliografia Comentada Libros A continuacion se incluye una lista de libros a los que puede referirse si le interesa saber mas sobre alguno de los temas cubiertos por la Guia de Administracion de Redes con Linux. No se trata de una lista completa o sistematica, simplemente son libros que he leido y que encuentro bastanteutiles. Se agradece cualquier informacion o mejora de esta lista. Libros sobre Internet en general [Kehoe92] Brendan P. Kehoe: Zen and the Art of the Internet. . La "Zen" fue probablemente la primera guia sobre la Internet, o al menos una de las primeras. Es una introduccion para el usuario novato a las costumbres, los servicios y el folklore de la Internet. Se trata de un tomo de unas 100 paginas que cubre temas que van desde el correo electronico o las noticias Usenet al virus Worm de la Internet. Esta disponible via FTP anonimo en muchos servidores FTP y puede ser distribuido e impreso libremente. Tambien hay un tomo editado por Prentice-Hall. Temas de Administracion [Hunt92] Craig Hunt: TCP/IP Network Administration. O'Reilly and Associates, 1992. ISBN 0-937175-82-X. Si la Guia de Administracion de Redes con Linux no es suficiente, consigase este libro. Trata todo tipo de temas, desde como conseguir una direccion de IP o la solucion de problemas de la red o la seguridad. Se centra en establecer TCP/IP, configuracion de la interface, establecimiento de las tablas de encaminamiento y resolucion de nombres. Incluye una descrip- cion detallada de las opciones disponibles en los demonios routed y gated, que implementan encaminamiento dinamico. Tambien describe la configuracion de aplicaciones y demonios de red como inetd, 330 _______________________________________________________________________________________________________________Temas de* * Administracion @ los comandos r, NIS, y NFS. El apendice contiene una referencia detallada de gated, y named, y una descrip- cion del proceso de configuracion del sendmail de Berkeley. [Stern92] Hal Stern: Managing NIS and NFS. O'Reilly and Associates, 1992. ISBN 0- 937175-75-7. Se trata de un libro que complementa a "TCP/IP Network Administration" de Craig Hunt. Cubre con detalle el uso de NIS (Sistema de informacion de red) y NFS (sistema de ficheros de red), incluyendo la configuracion de automontado de sistemas de ficheros y PC/NFS. [OReilly89] Tim O'Reilly y Grace Todino: Managing UUCP and Usenet, 10th ed. O'Reilly and Associates, 1992. ISBN 0-93717593-5. Es el estandar para redes UUCP. Cubre la version 2 de UUCP y la de BNU. Le servira de ayuda desde el principio cuando establezca su nodo UUCP, dandole consejos practicos y soluciones a multiples problemas, como la verificacion de conexiones o como escribir buenas macros para conectar mediante chat. Tambien trata temas mas exoticos como el establecimiento de un nodo UUCP movil o las sutilezas presentes en los distintos tipos de UUCP. La segunda parte del libro trata del software de noticias de red y Usenet. Ex- plica la configuracion tanto de Bnews (version 2.11) como C-News, y sirve de introduccion a las tareas de mantenimiento de noticias de red. [Spaf93] Gene Spafford y Simson Garfinkel: Practical UNIX Security. O'Reilly and As- sociates, 1992. ISBN 0-937175-72-2. Se trata de un libro imprescindible para cualquiera que administre sistemas con acceso de red o de otra indole. El libro discute temas relevantes en seguridad de ordenadores, incluyendo las caracteristicas basicas de seguridad fisica que pro- porciona un?x. A pesar de que es necesario atender a la seguridad en todas las areas del sistema, la explicacion de redes y seguridad es la parte mas interesante del libro en nuestro contexto. Ademas de las tecnicas de seguridad que concier- nen a los servicios de Berkeley (telnet, rlogin, etc), NFS y NIS, tambien trata de sistemas mas sofisticados como Kerberos del MIT, RPC Seguro de Sun y el uso de los cortafuegos como proteccion frente a ataques desde la Internet. _______________________________________________________________________________________________________________Conocimi* *entos Basicos @ [AlbitzLiu92] Paul Albitz y Cricket Liu: DNS and BIND. O'Reilly and Associates, 1992. ISBN 1-56592-010-4. Este libro resultautil para todos aquellos que administren un servicio de nom- bres DNS. Explica con gran detalle las caracteristicas de DNS y da ejemplos que explican las opciones que a primera vista resultan extra"nas en BIND. Me divirtio mucho leerlo y aprendi muchisimo de el. [NISPlus] Rick Ramsey: All about Administering NIS+. Prentice-Hall, 1993. ISBN 0-13- 068800-2. Conocimientos Basicos A continuacion hay una lista de libros que pueden resultar de interes para aquellas personas que quieran saber mas sobre como funciona TCP/IP y sus aplicaciones pero no quieren leer los RFCs. [Stevens90] Richard W. Stevens: UNIX Network Programming. Prentice-Hall International, 1990. ISBN 0-13-949876-X. Se trata probablemente del libro mas usado sobre programacion en redes TCP/IP que, al mismo tiempo, explica las entra"nas de los protocolos de Internet.8 [Tanen89] Andrew S. Tanenbaum: Computer Networks. Prentice-Hall International, 1989. ISBN 0-13-166836-69. Este libro trata de temas sobre redes en general. A traves del Modelo de Re- ferencia OSI, explica los problemas de dise"no de cada una de las capas, y los algoritmos que pueden usarse para solucionarlos. Para cada capa, compara diferentes implementaciones incluyendo la de ARPAnet. Elunico problema de este libro es que el uso abundante de abreviaturas dificulta a veces la comprension de lo que quiere decir el autor10. Aunque seguramente esta es una caracteristica inherente a los libros de redes. _____________________________________________8 Stevens acaba de escribir otro libro sobre TCP/IP, titulado TCP/IP Illustrated, Volume 1, The Protocols y publicado por Addison Wesley aunque no he tenido tiempo de echarle un vistazo. 9 El numero de ISBN en otros paises puede ser diferente. 10N. del T.: De este libro existe una traduccion al castellano editada por la propia Prentice-Hall. Sin embargo, no se la recomendaria a nadie: se entiende peor que la original en Ingles. _______________________________________________________________________________________________________________HOWTOs * * @ [Comer88] Douglas R. Comer: Internetworking with TCP/IP: Principles, Protocols, and Architecture. Prentice-Hall International, 1988. HOWTOs A continuacion hay un extracto del indice HOWTO-INDEX, version 2.0 (17 de Marzo de 1994), escrito por Matt Welsh. >Cuales son los HOWTOs de Linux? Los HOWTOs de Linux son peque"nos documentos disponibles electronicamente que describen con detalle cietos aspectos de como configurar o usar el sistema Linux. Por ejemplo, existe una Insta- llation HOWTO, que cuenta como instalar Linux, una Mail HOWTO, que describe como establecer y configurar el servicio de correo electronico en Linux. Otros ejemplos incluyen el NET-2-HOWTO (lo que antes eran las NET-2-FAQ) y el Printing HOWTO. La informacion de los HOWTOs es generalmente mas detallada y profunda de lo que se pueda incluir en las FAQ de Linux. Por esta razon las FAQ estan siendo reescritas. Gran parte de la informacion contenida en ellas sera relegada a los diferentes documentos HOWTO. Las FAQ quedan como una lista mas breve de las preguntas mas habituales sobre Linux, cubriendo escuetamente temas especificos. La mayoria de la informacion mas "util" en las FAQ se incluira en los HOWTOs. Los HOWTOs son documentos extensos, parecidos a unas FAQ, aunque en general no responden a un formato de pregunta-respuesta. Sin embargo muchos HOWTOs incluyen una peque"na seccion de FAQ al final. Por ejemplo, las NET-2-FAQ simplemente cambiaron el nombre por NET-2-HOWTO, ya que nunca fueron escritas en este formato. Aunque se cite al NET-2-HOWTO como NET-2-FAQ en muchos sitios, se trata del mismo documento. >Donde se consiguen los HOWTOs de Linux? Los HOWTOs pueden obtenerse via FTP anonimo desde cualquiera de los siguientes servidores: o sunsite.unc.edu:/pub/Linux/docs/HOWTO o tsx-11.mit.edu:/pub/linux/docs/HOWTO asi como en cualquiera de los mirrors de estos servidores citados en las META-FAQ de Linux. El indice, impreso a continuacion, contiene los HOWTOs existentes en la actualidad. Los HOWTOs se publican regularmente en los grupos de noticias comp.os.linux y comp.os.linux.announce. Muchos son publicados tambien en news.answers. Por tanto se pue- den obtener los HOWTOs en el archivo del news.answers en el servidor rtfm.mit.edu. _______________________________________________________________________________________________________________Indice d* *e HOWTOs @ Indice de HOWTOs A continuacion hay una relacion de los HOWTOs disponibles actualmente11. o Linux Busmouse HOWTO, escrito por mike@starbug.apana.org.au (Mike Battersby). In- formacion sobre la compatibilidad del raton bus en Linux. o Linux CDROM HOWTO, escrito por tranter@software.mitel.com (Jeff Tranter). Infor- macion sobre la compatibilidad de los lectores de CD-ROM en Linux. o Linux DOSEMU HOWTO, escrito por deisher@enws125.EAS.ASU.EDU (Michael E. Deisher). HOWTO sobre el emulador de MS-DOS bajo Linux, DOSEMU. o Linux Distribution HOWTO, escrito por mdw@sunsite.unc.edu (Matt Welsh). Lista de distribuciones de venta por correo y otros servicios comerciales. o Linux Ethernet HOWTO, escrito por Paul Gortmaker gpg109@rsphysse.anu.edu.au. In- formacion sobre la compatibilidad del hardware Ethernet en Linux. o Linux Ftape HOWTO, escrito por ftape@mic.dth.dk (Linux ftape-HOWTO maintainer). Informacion sobre los grabadores de cinta y su compatibilidad con Linux. o Linux HOWTO Index, escrito por mdw@sunsite.unc.edu (Matt Welsh). Indice de los documentos HOWTO en Linux. o Linux Hardware Compatibility HOWTO, escrito por erc@apple.com (Ed Carp). Lista casi completa del hardware que funciona con Linux. o Linux Installation HOWTO, escrito por mdw@sunsite.unc.edu (Matt Welsh). Describe como obtener e instalar el Linux. o Linux JE-HOWTO, escrito por Yasuhiro Yamazaki hiro@rainbow.physics.utoronto.ca. Informacion sobre JE, un conjunto de extensiones de Linux en lengua japonesa. o Linux Keystroke HOWTO, escrito por Zenon Fortuna (zenon@netcom.com). Describe como asociar macros a las diferentes teclas en Linux. o Linux MGR HOWTO, escrito por broman@Np.nosc.mil (Vincent Broman). Informacion sobre la interface grafica MGR para Linux. o Linux Electronic Mail HOWTO, escrito por vince@victrola.wa.com (Vince Skahan). In- formacion sobre servidores y clientes de correo electronico disponibles en Linux. o Linux NET-2 HOWTO, escrito por terryd@extro.ucc.su.oz.au (Terry Dawson). Explica como configurar las comunicaciones via TCP/IP en Linux y en particular SLIP, PLIP y PPP. o Linux News HOWTO, escrito por vince@victrola.wa.com (Vince Skahan). Informacion sobre el software servidor y cliente de noticias USENET disponibles para Linux. o Linux PCI-HOWTO, escrito por Michael Will michaelw@desaster.student.uni- tuebingen.de. Informacion sobre la compatibilidad de la arquitectura PCI en Linux. _____________________________________________11 N. del T.: Actualmente hay muchos mas HOWTOs, que cubren nuevos e interesantes temas como el PCI, el uso de disquetes ZIP, etc. No deje de revisar las nuevas distribuciones de Linux por si acaso. _______________________________________________________________________________________________________________Asuntos * *varios y cuestiones lega@ o Linux Printing HOWTO, escrito por gtaylor@cs.tufts.edu (Grant Taylor). Trata del sof- ware de impresion en Linux. o Linux SCSI HOWTO, escrito por Drew Eckhardt drew@kinglear.cs.Colorado.EDU. In- formacion sobre la compatibilidad del manejador SCSI de Linux. o Linux Serial HOWTO, escrito por gregh@cc.gatech.edu (Greg Hankins). Informacion sobre el uso de dispositivos serie y sobre el software de comunicaciones. o Linux Sound HOWTO, escrito por tranter@software.mitel.com (Jeff Tranter). Software y hardware, relacionado con el sonido, disponible para el sistema operativo Linux. o Linux Term HOWTO, escrito por Bill Reynolds bill@goshawk.lanl.gov. Explica el uso del paquete de comunicaciones "term" con sistemas Linux. o Linux Tips HOWTO, escrito por Vince Reed reedv@rpi.edu. HOWTO con trucos y consejos varios sobre Linux. o Linux UUCP HOWTO, escrito por vince@victrola.wa.com (Vince Skahan). Informacion sobre software UUCP para Linux. o Linux XFree86 HOWTO, escrito por geyer@polyhymnia.iwr.uni-heidelberg.de (Helmut Geyer). Explica la instalacion del servidor XFree86 (X11R5) para Linux. Asuntos varios y cuestiones legales Si tiene usted alguna pregunta, por favor no dude en ponerse en contacto por correo electronico con mdw@sunsite.unc.edu. El proceso de reescritura de las FAQ de Linux esta siendo coordinado por Ian Jackson, ijackson@nyx.cs.du.edu, con ayuda de otras personas. Salvo mencion expresa en contra, los derechos de copyright de los documentos HOWTO de Linux pertenecen a sus respectivos autores. Los documentos HOWTO de Linux pueden ser reproducidos de forma completa o en parte, en cualquier medio fisico o electronico sin permiso del autor. Igualmente, cualquier traduccion o trabajo derivado esta permitido sin necesidad de un permiso expreso del autor. La redistribucion con fines comerciales esta permitida e incluso se anima a ello; sin embargo, el autor querria ser avisado si semejante distribucion tuviera lugar. En resumen, queremos promocionar la diseminacion de esta informacion a traves de tantos cana- les como sea posible. No obstante, queremos retener los derechos de copyright sobre los documentos HOWTO y nos gustaria ser notificados de cualquier plan de redistribuir los HOWTOs. Si tiene alguna pregunta, por favor pongase en contacto con Matt Welsh, el coordinador de los HOWTOs de Linux en mdw@sunsite.unc.edu. Los HOWTOs en Castellano Como contabamos en la introduccion, actualmente existe otro grupo que trabaja junto con LuCAS; y se ocupa de traducir los HOWTOs al Castellano; que se han venido a denominar COMOs. Son muchos los COMOs disponibles actualmente, con lo que creemos que le resultarautil a numerosos lectores. _______________________________________________________________________________________________________________RFCs * * @ Los COMOs traducidos se pueden encontrar en el mismo servidor principal de LuCAS (http://lucas.hispalinux.es/) aunque su servidor principal es el siguiente: o WWW: http://www.insflug.org/ o FTP: ftp.insflug.org La coordinacion de este grupo corre a cargo de Francisco Jose Montilla, pacopepe@insflug.org. RFCs A continuacion hay una lista de los RFCs mencionados a lo largo del libro. Todos los RFCs estan disponibles via FTP anonimo en los servidores nic.ddn.mil, ftp.uu.net. Para obtener un RFC via correo electronico, envie un mensaje a service@nic.ddn.mil, incluyendo la peticion send RFC-numero .TXT en el asunto12. 1340 Numeros Asignados, Postel, J., y Reynolds, J. El RFC de Numeros Asignados define el significado de los numeros empleados por los diferentes protocolos, tales como los numeros de puertos estandar atendidos por los servidores TCP y UDP, asi como los numeros de protocolo contenidos en la cabecera del datagrama IP. 1144 Compresion de cabeceras TCP/IP para enlaces tipo serie de baja velocidad, Jacob- son, V. Este documento describe el algoritmo usado para comprimir las cabeceras TCP/IP en CSLIP y PPP. Quien dice que los heroes de las redes no son poetas? _____________________________________________13 N. del T.: Al tratarse de un poema, hemos preferido no traducir su titulo Indice de Materias /proc/net, 60 proxy, 73, 81, 122 16450 UART, 57 sustituto, 73, 81 16550 UART, 57 ARPANET, 5 8250 UART, 57 assignacion de la direccion IP, 62 auto-IRQ, 50 A (registro DNS), 94 automontado, 164 acceso autorizacion concesion, 105, 112, 162 con NNTP, 299 NNTP, 298, 299 autorizacion PPP, 125 y comandos r, 140 restriccion, 163 autorizaciones restringiendo, 128 con PPP, 113, 125-129 restringir, 17, 133 autoverificacion, Ethernet, 49 UUCP, 187-194 AX.25, 8, 47 acceso a una maquina, 67 acceso telefonico IP, 102 busqueda de direcciones, 36 acessing Barber, Stan, 296 remote files, 159 batching Adaptador de bolsillo D-Link, 47 news, 270 address Baudios, 55 registro de recurso DNS, 94 BBS, 53 administrador del correo, 228 Becker, Donald, 47 algoritmo de Nagle, 45 BIND, 84, 88-101 alias Biro, Ross, 14 and C News, 277 Bits por segundo, 55 correo, 234 BNU, vease UUCP, HDB nombre, 34 BOOTP, 23 nombre de maquina, 94 BSMTP, 207 alias, 234 bulletin board, 53 aliases, 235 Allman, Eric, 202 C News, 267, 272-294 amd, 164 active file, 281 archivo de correo, 233 actualizar el fichero active, 290 archivos de correo archivando, 284 montaje via NFS, 222 archivos de registro, 288 ARP, 22-23 caducado, 284 consulta de las tablas, 80 caducando, 287 habilitacion, 76 compressing batches, 283 338 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ crear configuracion inicial, 275 chat, 118-119 directorio de cola, 272 checking envio de noticias, 281 sendmail, 261 excluyendo servidores, 277 chequear active file, 280 NIS, 149, 150 active file, 272, 275-276 clientes sin discos, 23 history file, 272, 287 CNAME (registro DNS), 94 sys file, 274, 276 colision, Ethernet, 8 togo file, 279 Collyer, Geoff, 267 grupos moderados, 287 COM puerto, 55 intercambiando noticias, 277, 279 Comienzo de Autoridad, 34 LAN, 292 compatibilidad PC/TCP, 44 limitar una fuente, 277, 288 Compresion de cabeceras de Van Jacobson, linea de flotacion, 303 103 lista de grupos actuales, 287 compresion de cabeceras Van Jacobson, 114 lista de los grupos actuales, 280 compresion de paquetes TCP/IP, 103, 114 mandando noticias, 279, 284 Compressed Serial Line IP, vease CSLIP NNTP support, 278 Comprobacion nombres de anfitriones con alias, 277 sendmail, 256 parametros del proceso por lotes, 282-284 comprobacion procesado por lotes, 281 nombre de maquinas, 98 procesando por lotes, 273, 278, 284 PPP, 120 proceso por lotes, 279 servidor de nombres, 98 receiving news, 274 Comprobacion recibiendo noticias, 272-277 interface Ethernet, 80 relaynews, 272 tablas ARP, 80 rnews, 279 comprobacion sending news, 282 accesibilidad, 67, 69 servidor maestro de noticias, 276 actividad del servidor TCP, 79 soporte NNTP, 300 conexiones de red, 79 sys file, 280 configuracion de red, 67, 69 usenet, 276 interface de red, 66, 78 UUCP, 273, 283 tabla de encaminamiento, 77 yotengo/enviame, 278, 283 tabla de encaminamiento de IP, 70 C-News comprobacion de la configuracion de red, 67, actualizar la marca baja de agua, 280 69 actualizar las marcas de agua bajas, 287 comprobaciones como encolar el correo, 227 NNTP, 300 cache (opcion BIND), 91 comprobar Cervecera Virtual, 61 UUCP, 177 Cervecera, Virtual, 61 conectando Redes de Area Local, 122 CHAP, vease Protocolo CHAP de Autentifi- Conector BNC, 47 cacion por Reto conexiones, consulta, 79 chargen, 132 configuracion chat correo en una red local, 222-225 PPP, 117 correo UUCP, 220 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ dip, 105 PLIP, 42, 51 DNS junto a SLIP/PPP, 102 PPP, 42, 130 dominio por defecto, 87 SLIP, 42 elm, 215 configurando el hardware de red, 39 PPP, 116 ), 52 configurar lector de noticias, 301 los comandos r, 140-142 NNTP, 295-300 NIS, 143-156 pasarela de correo, 223 servicios de red, 131 PPP, 113 UUCP, 166-201 sendmail, 239-266 conjuntos de caracteres en elm, 216 serie puerto, 57-58 conjuntos de caracteres nacionales en elm, 216 servidor de nombres, 88-101 connector BNC, 7 servidor de nombres solo con cache, 102 consulta servidor SLIP, 111 configuracion de interface, 74 SLIP, 102-112 estadisticas de una interface, 78 smail, vease smail IP - tabla de encaminamiento, 77 traduccion de nombres, 84-101 tabla de encaminamiento IP, 70 uso del servidor de nombres, 87 tablas ARP, 80 configuracion de red del nucleo, 42 consutla configuracion manual (Ethernet), 49 conexiones activas, 79 configuracion manual (PLIP), 51 passwd configuraciob nombres reales de usuario, 276 pasarela IP, 72 contrase"nas configuracion network-wide, 153-155 dominio, nombre de, 62 control de flujo, hardware, 56, 115 Ethernet, 68 control de flujo, por hardware, 58 hostname, 61 controlador interface de bucle, 66 D-Link, 47 interface de lazo, 66 Ethernet, 47 interfaces de red, 65 PLIP, 51 loopback, 66 PPP, 52 nombre de la maquina, 61 RDSI, 47 PLIP, 72 SLIP, 52 PPP, 73 correo, 202 resolucion del nombre de una maquina, 64 administrador, 228 SLIP, 73 administrador del correo, 228 configurando alias, 234-235 C News, 274-294 centralizado, 209, 211, 213 C News en una LAN, 292 cola, 219, 227-228 elm, 218 demonio, 219 Ethernet, 42, 47-51 devuelto, 206 IPX, 46 direcciones con ruta bang, 207, 210 nucleo, 42 direcciones route-addr, 208 NFS, 43 en una red local, 222 noticias Usenet, 274-294 encabezados, 203 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ encaminado basado en dominios, 209, 213 Dent, Arthur, 111 encaminado de, 209-213 depuracion basado en dominios, 211 base de datos DNS, 101 entre Internet y UUCP, 209 configuracion PPP, 120 Internet, 209 /dev/cua*, 55-56 nodo inteligente, 211 /dev/modem, 56 redes UUCP, 210 /dev/ttyS*, 55-56 Enviar correo a un archivo, 233 devolver correo, 206 escribiendo, 206 dialogo con modem fichero paths, 211, 213-215 SLIP, 107 formato de un mensaje, 203 dialin device, 55 formatos de direcciones, 207-209 dialout fichero, 55 mapas, 210, 214 dip, 105-112 mensaje rebotado, 228 diphosts, 112 multi-media, 202 diplogin, 111 ocultamiento de maquinas, 222 direccion pasar el correo a un comando, 233 broadcast, 22 pasarela de, 209 Ethernet, 7 postmaster, 228 Ethernet vs. direccion IP, 9 proceso por lotes, 207 IP, 9 rechazo, 244 IP vs. nombre de nodo, 9 reenvio, 234 negociacion con PPP, 116, 120, 128 reparto, 206-207 nombre de nodo UUCP, 176 ruta por defecto, 211 traduccion a nombre, 36 sobre UUCP, 206 direccion correo electronico, 202 broadcast, 68 correo multi-media, 202 difusion, 76 Cox, Alan, 14 eligiendo (IP), 62 creacion direccion de difusion, 76 subdominios, 32 direcciones subredes, 37 correo, 207-209 zonas DNS, 37 hibridas, 208 creacion route-addr, 208 subredes, 62 ruta bang, 207, 210 crear disciplina de linea, 103 mapas NIS, 149 disciplina de las lineas, 114 CSLIP, 11, 103, 104, 112, 114 dispositivo, serie, 53-58 DNS, 29-37 Davies, David C., 47 busqueda, 33 Dawson, Terry, xii base de datos, 34 daytime, 132 comprobacion, 98 DDI, 15 configuracion del servidor, 88-101 delegacion conversion de /etc/hosts, 100 subdominios DNS, 32, 37 creacion de zonas, 37 subredes IP, 25 depuracion de la base de datos, 101 demonio mapeador de puertos, 139 lookup, 33 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ peticion, 33 ARP , 81 registro de recursos, 91 datagramas IP, vease IP, encaminamiento registros, 34 demonio, 28 registros de recursos, 34 dinamico, 28, 29, 123 resolucion inversa, 36-37 dinamico, 73 RR, vease DNS, registros evitar ciclos, 228 servidores del dominio raiz, 95 IP, 44 servidores raiz, 99 metrica, 28 tiempo de vida, 33, 92 metrica, 76 ttl, vease DNS, tiempo de vida metrica, 75 utilidades, 100 pasarela IP, 71 zona, 32-34, 37, 92 protocolos, 28 dnswalk, 101 Redireccion ICMP, 29 domainname, 146 tabla, 26, 77 dominio encaminamiento dinamico, 28 por defecto, 87 encaminamiento IP por defecto, vease enca- dominio in-addr.arpa, 36 minamiento, defecto dominio, nombre de encaminamiento, defecto, 22 NIS vs. DNS, 62 encaminamiento, por defecto, 116 domainname, 62 enlace punto-a-punto, 72, 73, 113 dominios Ensamblador/Desensamblador de Paquetes, 8 encaminado de correo, 211 entrega primer nivel, 31 news, 270-271 ISO-3166, 32 entregando driver noticias, 272 PPP, 114 Enviar correo a un archivo, 233 envoltorio, TCP, 133 Ekwall, Bjorn, 47 Eriksson, Peter, 144 El Protocolo CHAP de Autentificacion por escribiendo correo, 206 Reto, 127 espacio de nombres (DNS), 30 eleccion Estandar de Sistema de Ficheros, xviii direccion IP, 62 establecer Elegir dominio NIS, 146, 150 mapas NIS, 151 estableciendo la conexion, 117 elegir establecimiento nombre de nodo UUCP, 176 hostname, 61 un dominio NIS, 146 nombre de la maquina, 61 elm, 215-218 eth0 (interface Ethernet), 68 conjuntos de caracteres nacinales, 216 Ethernet, 7-8 email, vease correo autoverificacion, 49-51 encaminado cableado, 47 correo, vease correo, encaminado de colision, 8 nodo inteligente, 211 configuracion, 68 encaminado por nodo inteligente, 211 controladores Becker, 47 encaminamiento direccion, 7, 22 a traves de PPP, 121 fino, 7, 47 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ instalacion, 47 hardware de acceso a la red, vease interfaz mediante un puerto paralelo, 47 HDB, vease UUCP, HDB modo promiscuo, 76 HDLC, 113 evitar ciclos en el encaminamiento, 228 HoneyDanBer, vease UUCP, HDB evitar spoofing, 85 host.conf, 85, 144, 156 evitar tinygrams, 45 hostcvt, 100 exchanging hostname news, 270 establecimiento, 61 exportar un volumen NFS, 162 hosts, 64 exports, 162 hosts.byaddr, 145 hosts.byname, 145, 152 Faith, Rik, ix hosts.equiv, 140 fallo del mapeador de puertos(mensaje de HOWTO, x error), 156 Ethernet, 48 fallo en la autoverificacion, 49 Networking, xii FDDI, 8 Redes, xii feed, news, 270 Serial, 53 fichero hosts, 64 UUCP, 168 fichero paths, 211, 213-215 ficheros de bloqueo ICMP, 29 y PPP, 117 Puerto inalcanzable, 29 FidoNet, 53 Redireccion, 29 file sharing, 157 IDA, vease sendmail, IDA File System Standard, xviii ifconfig, 65, 74 finger, 133 IMAP, 222 flooding algorithm, 270 ientd, 225 fstab, 60, 160 inetd, 131, 139 FTP, localizacion del codigo de Linux, 15 inetd.conf, 132-133 FTP, ubicacion de codigo de Linux, 61 inews, 272 inhabilitacion de ARP, 76 gated, 28, 73, 123 inicializando la red, 59 generar un fichero paths, 213 INN, 268, 297, 302 getty, 190 instalacion Gortmaker, Paul, 48 ejecutables de comunicaciones en red, 60 Groucho Marx University, 24 Interactive Mail Access Protocol, 222 group.bygid, 153 Intercambiador de Correo (campo de DNS), group.byname, 153 209 junk newsgroup, 273 intercambio habilitacion de ARP, 76 correo, 206-207 ham radio, 8 noticias, 268, 269 Hankins, Greg, 53 interface, 39, 41, 46 hardware comodin, 73 control de flujo, 56, 58, 115 configuracion, 65 interconexion, 39 D-Link DE-600, 46 ), 52 estadisticas, 78 serie, 53-58 Ethernet, 46, 68 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ loopback, 46, 66 MTU, vease Unidad de Transferencia mascara de red, 62, 68, 75 Maxima PLIP, 47, 72 pasarela, 9, 71, 72 PPP, 47, 73, 116 Protocolo de Control, 114, 120 SLIP, 47, 73 Protocolo NCP de Control de Red (PPP), interface comodin, 73 114 interface del controlador de dispositivo, vease protocolos de encaminamiento, 28 DDI red, 36 interfaz, 20 redes, 21, 24 mascara de red, 24 reenvio, 9 internacionalizacion para elm, 216 route, 26 Internet, 5 ruta por defecto, 71 conectando a, 115 sub-redes, vease IP, subred conexion a, 102, 113 subred, 24-25, 37, 45, 71, 72 encaminado de correo, 209 tabla de encaminamiento, 26, 70, 77 vs. internetworking, 9 tinygrams, 45 Internet Control Message Protocol, 29 IP en linea serie, vease SLIP InterNet News (INN), 268 IP en lineas serie, vease PPP Internet Protocol, vease IP IP en Linea Paralela, vease PLIP internetworking, 9, 25 IP por linea serie, comprimida, 103 IP, 9-11 IPCP, vease IP, Protocolo de Control acceso telefonico, 102 IPX, 46 configuracion de interface, 65 IRQ, 40, 50 direccion, 9, 21-22 ISO-3166 negociacion con PPP, 116 dominios de primer nivel, 32 negociacion en PPP, 120, 128 ISO-8859-1, 216 y nombre de maquina, 29 y nombre del nodo, 36 Johnson, Michael K., ix direccion Karr, Ronald S., 202 assignacion, 62 Kempen, Fred van, 5, 14 direccion de broadcast, 68 direccion de difusion, 68, 76 linea de serie direcciones de envio multiple, 77 protegiendo caracteres, 123 encaminamiento, 9, 24-29, 44, 45, 71, 72 linea dedicada, 54 encaminamiento dinamico, 28 LAN, 4 encaminamiento por defecto, 22 comandos r, 140 interface, 41 contrase"nas, 153, 156 linea de serie, 113 noticias, 292 linea paralela, vease PLIP passwords, 140 linea serie, 102 resolucion de nombres de nodos, 156 see SLIP, 52 Lapsley, Phil, 296 llamadas, 113 Latin-1, conjunto de caracteres, 216 mascara de red, 24 LCP, vease Protocolo LCP de Control de En- metrica, 28 lance (PPP) mascara de red, 62, 68, 75 LDP, vease Linux Documentation Project metrica, 76 libreria de sockets BSD, 13 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ lilo, 49 MRU, vease PPP, Unidad Maxima de Recep- Linux Documentation Project, ix, xvi cion lmail, 206 mthreads, 303 lo (interface de lazo), 66 MTU, vease Unidad de Transferencia Maxima loopback MX (campo de DNS), 209 direccion, 22 MX (registro DNS), 94 interface, 66 numeros de protocolo, 137 hosts named, 84, 88-101 conversion a ficheros BIND, 100 named.boot, 89-91 metrica, encaminamiento, vease encamina- NCP, vease Protocolos NCP de Control de miento, metrica Red modem, velocidad, 55 Net-1, 14 maquina Net-2d, 14 aislada, 73 Net-2Debugged, 14 maquina aislada, 73 Net-2e, 15, 61 localhost, 66 Net-3, 15, 61 rc macros, 59 Net-BSD, 15, 61 mail netstat, 77-80 Forzado rutado UUCP, 263 Network File System, vease NFS manipulacion centralizada del correo, 209, Network News Transfer Protocol, vease 211, 213 NNTP mantenimiento del sistema, 16 fichero networks, 64 mantenimiento, sistema, 16 news, 271 mapas, Usenet, 210, 214 alimentacion, 271 Marx, Groucho, 5 batching, 270 mensaje de control cancel, 289 borrado de articulos antiguos, 271 mensaje de control checkgroups, 290 C release, vease C News mensaje de control newgroup, 289 cola, 271 mensaje de control rmgroup, 289 distribucion, 270 mensaje de control checkgroups, 291 exchanging, 270 mensaje de control checkgroups, 291 expiracion de articulos, 271 mensaje de control checkgroups, 291 feeding, 270 "Network Unreachable" mensaje de error, 68 fichero active, 271 metamail, 217 flooding algorithm, 270 mgetty, 190, 192 history, 270 montaje ihave/sendme, 271 automatico, 164 intercambio, 271 solo lectura, 163 limitar alimentacion, 270 montando message id, 270 El sistema de ficheros proc, 60 NNTP, 271 mostrar por lotes, 270 configuracion de UUCP, 177 pulling, 271 mountd, 161, 162 pushing, 271 mounting spool, 271 an NFS volume, 159 NFS, 157-165 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ automountado, 164 y nombre de dominio, 30 comparacion de uids y gids, 164 nombre canonico, 34 comprobacion de uids y gids, 162 nombre completos de usuario, 276 expiracion, 161 nombre de dominio, 30-32 exportar un volumen, 162 establecer NIS, 146 exports, 162 nombre de la maquina limitaciones, 158 establecimiento, 61 montaje fisico vs. montaje logico, 161 nombre de maquina montar un directorio, 157 alias, 94 mounting a volume, 159 busqueda, 98 restricciones del tama"no del bloque, 160 canonico, 94 servidor, 158, 161 captura de los no calificados, 237 timeout, 161 nombre de maquina canonico, 94 volumen de solo lectura, 163 nombre de maquina nfsd, 158, 161 resolucion, 64 NIS, 143-156 nombre de nodo apodo, 145 ambiguo, 210 codigo tradicional, 156 canonico, 34 cliente, 148, 150-156 conversion a direccion IP, 29 crear mapas, 149 resolucion, 29 databases, 144 UUCP, 176 dominio, 146-147 nombre del host localizar servidor, 147 resolucion, 84 mapa, 144-146, 148 nombres de nodos mapas passwd, 155, 156 resolucion, 143, 156 passwd mapas, 153 nombres reales de usuario, 276 servidor, 146-150 notacion de puntos, 9 y contrase"nas shadow, 155 noticias, 267 y resolucion, 85 a"nadir un grupo nuevo, 289 NIS+, 147 actualizar el fichero active, 290 nn, 304 alimentacion, 268, 269 NNTP, 267, 295 archivando articulos, 284 acceso restringido, 298, 299 articulo, 268 authorization, 299 borrar un grupo antiguo, 289 y C News, 300 caducidad, 303, 304 nntp_access, 298 cancelar articulo, 289 nntpd, 296 distribuciones, 277 nodo, 1 empujar, 295 hoja, 211 falsificacion, 296 nodo hoja, 211 active file, 272 hosts, 145 grupos, 268 Noll, Curt Landon, 202 history, 272 nombre identificador de mensaje, 272 busqueda, 33 intercambio, 268, 269 obtencion desde la direccion IP, 36 lector, vease noticias, lector de totalmente cualificado, 30 mensajes de control, 289 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ nntpd, 295 POP, 222 procesando por lotes, 273, 281 portmap, 139 recibiendo, 277 Post Office Protocol, 222 respuestas, 301 PPP, 11, 73, 102, 113-130 servidor maestro de noticias, 276 asignacion dinamica de direcciones, 121 tirar, 295 autentificacion, 125-129 Usenet, 268 compresion, 114 noticias, lector de comprimiendo datos, 124 configuracion, 301 daemon, 114 creando bases de datos de hebras, 302- direcciones IP, 120-121 304 driver, 114 hebras, 301, 302 encaminamiento, 81, 121-123 nn, 304 encaminamiento por defecto, 116 tass, 302 ficheros de bloqueo, 117 tin, 302 ficheros de opciones, 116 trn, 303 informacion de depuracion, 120 nslookup, 98-100 mapa asincrono, 123 nsswitch.conf, 151-153 proxy ARP, 122 NYS, 144-156 rehuyendo caracteres de control, 123 script del chat, 117-119 obtencion de codigo fuente, 61 seguridad, 125 obteniendo el codigo fuente, 15 servidor, 130 orden de uso de servicios de resolucion, 85 Unidad Maxima de Recepcion, 124 PAD, 8 usando CHAP, 125, 127-128 PAP, vease Protocolo PAP de Autentificacion usando PAP, 125, 128-129 por Contrase"na y direcciones IP, 116 pasar el correo a un comando, 233 pppd, 114-130 pasarela, 9 .ppprc, 117 configuracion, 72 presentar de correo, 209 apodos mapas NIS, 145 IP, 71 primary (opcion de BIND), 90 pasarelas, 25-26 proc sistema de ficheros, 60 passwd, 145 procesado por lotes passwd.byname, 153 noticias, 281 passwd.byuid, 153 procesando por lotes passwords noticias, 284 y login remoto, 140 proceso por lotes pathalias, 211, 214-215 correo, 207 pequegramas, 45 protocolo, 2 ping, 67 AX.25, 8, 47 PLIP, 51, 72 CSLIP, 11 encaminamiento, 81 Ethernet, 7 plip1 (interface PLIP), 72 IP, vease IP point-to-point link, 75 IPX, 46, 47 Point-to-Point Protocol, vease PPP NNTP, 295 PPP, 11 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ SLIP, 11 RDSI, 47 TCP, 11 Reber, Tobias, 143 UDP, 12 recibiendo noticias, 277 UUCP, 195 red, 1 X.25, 8 arranque, 59 Protocolo CHAP de Autentificacion por Reto, conexiones, vease red, puerto 113, 125, 128 contrase"nas, 153, 156 Protocolo de Informacion de Encaminamiento, dispositivos, 39 28 inaccesible, 68 Protocolo de Informacion de Encaminamiento, interface de programacion, 13 73, 76 interfaz, vease interfaz Protocolo de Mensajes de Control de Internet, mostrar conexiones, 79 29 numeros de puerto, 13 Protocolo de resolucion de direcciones, vease nombres, 64 ARP opciones del nucleo, 42 Protocolo de resolucion inversa, vease RARP protocolos, 2 Protocolo LCP de Control de Enlace (PPP), puerto, 12-13 113, 123-125 resolucion de nombres de nodos, 156 Protocolo PAP de Autentificacion por Contra- servicios, vease puerto se"na, 113, 125 sincronizar contrase"nas, 143 Protocolo Punto-a-Punto, 113 TCP/IP, vease TCP/IP Protocolo Simple de Transferencia de Correo, UUCP, vease UUCP vease SMTP Red de Area Local protocols, 132, 136-138 conecando, 122 Protocolos NCP de Control de Red, 114 red local proxy ARP, 73, 81, 122 correo, 222 Proyecto de Documentacion de Linux, ix redes PTR (registro DNS), 94 intercambio de paquetes, 5 puerto, vease red, puerto interconexion, vease internetworking COM, 55 Internet, 5 numeros, 13 Redes de Area Local, vease LAN puerto paralelo reenvio Ethernet, 47 correo, 234 IP, 51 IP, 9 punto-a-punto, enlace, 81 UUCP, 3 Puntos divisorios, 21 registro de recursos, vease DNS, registros remote Quinlan, Dan, xviii file access, 157 radio paquetes, 23 file system, 159 radioaficionado, 8 Remote Procedure Call, 138-140 rail mapeando puertos a programas, 139 impidiendo el envio UUCP, 263 numeros de programa, 138 RARP, 23, 45 remoto rc.inet, 59, 65, 68, 161 acceso, 5, 12 rcp, 140 acceso a ficheros, 3 acceso de ficheros, 140 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ ejecucion, 3 ruta, por defecto, 71 ejecucucion de comandos, 140 login, 140 Salz, Rich, 297 sesion X11, 6 script de entrada remoto/a UUCP, 179 ejecucion, 206 script del chat, 118 reparto secondary (opcion BIND), 90 correo, 206-207 securidad Representacion Externa de Datos, 138 Ethernet, 76 resolucion seguridad, 112 configuracion, 85-88 comandos r, 140 libreria, 85 login de UUCP, 192-194 robustez, 88 login remoto, 140 uso de NIS, 85 nombres de maquina falsos, 85 uso de un servidor de nombres, 85 PPP, 118, 125-129 variables de entorno, 86 servidores TCP, 133 resolucion de problemas sistema, 17 configuracion de UUCP, 171 SLIP, 105 resolucion inversa, 36-37 spoofing, 85 resolv.conf, 87 UUCP, 187-194 restringir acceso, 133 seguridad del sistema, 17 restringir acceso al usuario root, 163 sendbatches, 282 revision sendmail, 202, 239-266 cola del correo, 227 alias, 252 smail configuracion, 226 alias de usuarios, 252, 254 .rhosts, 140 CF, 240-248, 255-256 RIP, vease Routing Information Protocol Comprobacion, 256 rlogin, 140 DECnet, 254 rmail, 187, 206 ejecutando, 256 rnews, 187, 272, 283 deliver, 244 route, 65, 82 escribiendo el correo a un archivo, 252 routed, 28 estadisticas, 264 routing forzado de correo, 262 dynamic, 81 Forzado de rutado UUCP, 263 Routing Information Protocol, 28 genesis de sendmail.cf, 255 RPC, vease Remote Procedure Call generacion del fichero sendmail.cf, 256 rpc, 138 gestor de correo, 248 rpcinfo, 151 gestores de correo, 242, 246, 250, 252, 263 RR, vease DNS, registro de recurso IDA, 240 RS-232, 56 impidiendo el envio UUCP, 263 rsh, 140 instalacion, 254 rsmtp, 207 local hostnames, 245, 246 RTS/CTS, 56 localizacion de ficheros, 265 control de flujo, 115 mailertable, 248 route, 70 manipulaciones de la cola de correo, 264 ruta de correo por defecto, 211 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ nombre de sistema no cualificado, 252, tcpd, 133-136 263 nfsd, 158 nomenclatura de dominio plenamente NIS, 146 cualificado, 250, 252 NNTP, 295 nomenclatura de sistema no cualificado, UUCP, 190-194 250, 263 ypserv, 146 postmaster, 253 servidor de nombres, 33-34 postmaster, 244 autorizado, 33, 34, 37 procesado de la cola de correo, 264 cache, 91 rutado, 251 comprobacion, 98 dominio, 261 configuracion, 88-101 Maquinas inteligentes, 246 primario, 34 UUCP, 250, 254, 263 primary, 90 sendmail.cf, 240 raiz, 95, 99 Sistemas de reenvio, 261 solo con cache, 102 Sistemas de relevo, 246 secondary, 90 sistemas remotos mal configurados, 262 secundario, 34 Sitio Internet, 247 sincronizacion, 34 Sitio ramal UUCP, 247 slave, 91 tablas, 246, 253, 259 solo-cache, 34 tables, 240 servidor de nombres autorizado, 33, 34, 37, 92 testing, 261 servidor de nombres solo con cache, 102 transporte, vease , gestor de correo242 servidor maestro de noticas, 276 UUCP, 246, 250, 263 setserial, 57 version, 254 sincronizacion de servidores de nombres, 34 sendmail.cf, vease sendmail, sendmail.cf Sistema de Informacion de Redes, vease NIS Sequencia de Arranque, 59 Sistema de nombres, vease DNS serie linea Sistema de nombres Internet de Berkeley, 84 control de flujo por handshake, 56 site, 1 control de flujo por hardware, 58 sl0 (interface PPP), 73 dispositivo fichero, 55 sl0 (interface SLIP), 73 serie serie slattach, 103 velocidad, 55 SLIP, 11, 52, 54, 73, 102-112 server encaminamiento, 81 sendmail, 256 iniciacion, 105 services.byname, 152 SLIPDISC, 103 servicios, 13 smail, 202, 219-238 configuracion, 131 administrador, 228 conocidos, 136 alias de usuario, 234 reconocidos, 13 archivo config, 222 restringir acceso, 133 archivo config, 219-228 restringir el acceso, 17 archivo de correo del usuario, 233 y numeros de puerto, 13 archivo paths, 230, 232 services, 132, 136-138 archivos de registro, 225 servidor arreglando problemas, 225 inetd, 131-136 BSMTP, 220, 236 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ como encolar el correo, 227 subred (IP), 25, 45 como revisar la cola del correo, 227 `Subredes son Locales', Politica, 83 compilacion, 226 sustituto, ARP, 73, 81 direcciones locales, 232-236 syslog, 120, 135, 164 ejecutando la cola, 228 en una red local, 222-225 T'so, Theodore, 57 routers, 229 tass, 302 encaminamiento, 229-232 Taylor, Ian, 167 evitar ciclos, 228 TCP, 11-12 Internet, 231 programa envoltorio, 133 UUCP, 232 UUCP, 186 UUCP vs. SLIP, 231 TCP/IP, 4-14, 20-29 enrutamiento tcpd, 133-136 anfitrion inteligente, 221 telefono, envio de datos a traves de, 113 UUCP, 230 telefono, envio de datos sobre, 11 Enviar el correo a un archivo, 233 telefono, transmitir datos por el, 102 listas de correo, 236 terminal programas, 53 manejo del correo dentro de un dominio, TFTP, vease Trivial File Transfer Protocol 223 tftp, 133 modos de entrega, 227 thinnet, 7, 47 nombres de maquina no calificados, 237 Th"ummler, Swen, 143 nombres locales de anfitriones, 221 Tiempo de ida y vuelta (IP), 67 pasar el correo a un comando, 233 tin, 302 directors, 229 tinygrams, 45 SMTP, 224-225, 237 Politica `Toda Subrede es Local', 45 transports, 229 Transmission Control Protocol, vease TCP usuario alias, 235 tripwire, 18 utilerias, 219 Trivial File Transfer Protocol, 133 UUCP, 220-222, 231, 232, 236-237 trn, 303 y SLIP/PPP, 231 tty, 54-58 progsmail disciplina de linea, 103 reenvio, 234 disciplina de las lineas, 114 SMTP, 206 linea dedicada, 54 lotes, 187 UART, 57 por lotes, 207 UDP, 12 servicio, 224 Unidad de Transferencia Maxima, 76, 82 SNARL, vease Politica `Toda Subred es Local' Unidad Maxima de Recepcion (PPP), 124 SOA (registro DNS), 34, 92 Unidad Maxima de Transferencia, 124 SOA (Start of Authority), 34 Unidad Maxima de Transferencia, 75 socket, 13 Universidad Groucho Marx, 5 Space.c, 49, 51 Urlichs, Matthias, 15 Spencer, Henry, 267 Usenet, 268 spoofing, 85 mapas, 210, 214 Storm, Kim F., 304 User Datagram Protocol, vease UDP subdominio (DNS), 32, 37 Utilidades Basicas de Red, vease UUCP, HDB subred (DNS), 62 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ uucico, 171 nivel de cola, 169 UUCP, 2-4, 53, 166-201 nombre de nodo, 176, 178 alternativas, 181 noticias, 273 anonimo, 194 prioridades, 169, 182-183 BNU, 166 protocolo, 170, 195-198 comprobacion, 198 ajuste, 197 comprobacion de la secuencia de llamada, seleccion, 197 170 Proyecto de Cartografia, 210 comprobacion de secuencia de llamadas, Proyecto de Mapa, 176 193-194 rango de cola, 182-183 comprobar, 177 reenvio, 3, 189 configurar como servidor, 190-195 registro de actividad y resolucion de pro- configurar entradas, 191 blemas, 171 configurar logins, 192 restricciones correo, 206, 210 ejecucion de commandos, 187 cuentas, 191 restringir dialogo de entrada, 179 hora de llamada, 182 directorio de cola, 168 reenvio, 189 dispositivo, 179, 183-185 transferencia de ficheros, 188 ejecucion de comandos, 187 scripts de entrada, 179-181 entrada, 179 seguridad de login, 192-194 entrada al sistema, 175 sistema remoto, 178-183 esclavo, 169 sobre TCP/IP, 186 estadisticas, 200 solucion de problemas, 198 fichero config, 178 Taylor, 167 dial fichero, 185 trabajo, 168, 169 port, fichero, 183 transferencia de ficheros, 188 fichero sys, 178 uso de smail, 220 fichero dialcode, 179 uucico, 169-171 fichero passwd, 191 Version 2, 166 ficheros de configuracion, 172-175 y getty, 190 handshake, 170 UUCP anonimo, 194 HDB, 166, 201 uugetty, 190 hora de llamada, 182 uux, 283 intervalo para reintentar, 182 lineas directas, 187 volumen NFS de solo lectura, 163 llamada, 190 Welsh, Matt, ix logging y debugging, 200-201 Wirzenius, Lars, ix modem, 183, 185-186 maestro, 169 X.25, 8 mail, 187 XDR, vease External Data Representation mapas, 214 marcacion de la llamada, 171 Ye Olde ARPANET kludge, 208 numero de telefono, 179 Yellow Pages, vease NIS negociacion, 170 YP, vease NIS news, 187 yp-linux, 143 _______________________________________________________________________________________________________________INDICE D* *E MATERIAS @ yp.conf, 150 ypbind, 147 ypcat, 145, 150 yps, 143 ypserv, 146 Yutaka, Niibe, 51 Zen, 268 zona, DNS, vease DNS, zona