diff --git a/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index 936b8a99fd..f9cd47af0e 100755 --- a/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,9129 +1,9138 @@ - Networking Avanzado + Networking avanzado - Networking Avanzado + Networking avanzado Resumen Este capítulo cubre algunos de los servicios de red que se usan con más frecuencia en sistemas &unix;. Para ser más concretos este capítulo explica cómo definir, ejecutar, probar y mantener todos los servicios de red que utiliza &os;. Se muestran además ejemplos de ficheros de configuración que podrá utilizar para sus propios quehaceres. Después de leer este capítulo habremos aprendido: Los conceptos básicos de pasarelas y - encaminadores (gateways y routers). + routers. Cómo poner en funcionamiento dispositivos IEEE 802.11 y &bluetooth;. Cómo configurar &os; para que actúe como un bridge. Cómo poner en funcionamiento un sistema de ficheros en red con NFS. Cómo realizar un arranque del sistema por red en máquinas sin disco duro. Cómo ejecutar un servidor de información en red para compartir cuentas de usuario mediante NIS. Cómo especificar parámetros de configuración automática de red utilizando DHCP. Cómo ejecutar un servidor de nombres de dominio. Cómo sincronizar la hora y la fecha y ejecutar un servidor horario utilizando el protocolo NTP. Cómo ejecutar un servicio de traducción de direcciones de red. Cómo gestionar el dæmon inetd. Cómo conectar dos computadoras a través de PLIP. Cómo habilitar IPv6 en una máquina FreeBSD. Cómo configurar ATM sobre &os; 5.X. Antes de leer este capítulo debería usted: Intentar comprender los conceptos básicos de los scripts de /etc/rc. Familiarizarse con la terminología básica de redes. Coranth Gryphon Escrito por - Pasarelas y Encaminadores + Pasarelas y <quote>routers</quote> routing gateway subnet Para que una máquina sea capaz de encontrar otra máquina remota a través de la red debe existir mecanismo que describa cómo llegar del origen al destino. Este mecanismo se demonina routing o encaminamiento. Una ruta es un par definido de direcciones: una dirección de destino y una dirección de pasarela. Éste par indica que para llegar a dicho destino debe efectuarse una comunicación previa con dicha pasarela. Exiten tres tipos distintos de destinos: máquinas individuales, subredes y por defecto. La ruta por defecto se utiliza sólamente cuando no se puede aplicar ninguna de las otras rutas existentes. El tema de las rutas por defecto se tratará más adelante con más detalle. También existen tres tipos de pasarelas distintas: máquinas individuales, interfaces (también llamados enlaces) y direcciones hardware de ethernet (direcciones MAC). Ejemplo Para ilustrar diferentes aspectos del sistema de - encaminamiento veamos el siguiente ejemplo obtenido mediante el - comando netstat. + encaminamiento veamos el siguiente ejemplo obtenido mediante + netstat. &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 ejemplo.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.ejemplo.com link#1 UC 0 0 224 link#1 UC 0 0 default route Las primeras dos líneas especifican la ruta por defecto (la cual se comenta en la siguiente sección) y la ruta de máquina local. loopback device La interfaz (columna Netif) que especifica esta tabla de rutas para el destino localhost se denomina lo0, y también se conoce como el dispositivo de loopback a de bucle de retorno. Esto viene a decir que el tráfico no debe entregarse a la red puesto que dicho tráfico va destinado a la misma máquina que lo originó. Ethernet MAC address Lo siguiente que podemos observar son las direcciones que comienzan por 0:e0:. Son direcciones hardware de Ethernet, llamadas también se direcciones MAC. FreeBSD identifica automáticamente cualquier máquina (test0 en el ejemplo anterior) que se encuentre en la red local y crea una ruta del estilo que estamos comentando, para entregar el tráfico directamente a través del correspondiente interfaz Ethernet, en este caso ed0. Existe también un contador (Expire) asociado con este tipo de rutas que se usa para borrarlas cuando dicho contador expira. Las rutas para las máquinas de nuestra propia red de de área local se crean dinámicamente utilizando el protocolo ARP (Address Resolution Protocol o Protocolo de Resolución de Direcciones), que se encarga de averiguar la dirección MAC que se corresponde con la dirección IP de la máquina destino. subnet FreeBSD tambíen utiliza rutas de subred para direccionar la subred local (10.20.30.255 es la dirección de broadcast para la subred 10.20.30, y ejemplo.com es el nombre de dominio asociado con dicha subred.) La notación link#1 se refiere a la primera tarjeta Ethernet de la máquina. En este tipo de redes no se especifica ningún interfaz en el campo de Netif. Las rutas de subredes aparecen cuando se asigna una dirección IP a una interfaz, utilizando una máscara de red. También se pueden aprender dinámicamente utilizando demonios de encaminamiento, como routed. Por último estas rutas pueden crearse manualmente de forma explícita; es lo que se conoce con el nombre de rutas estáticas. La línea de host1 se refiere a nuestra máquina, que el sistema identifica por la correspondiente dirección Ethernet de la tarjeta de red. FreeBSD sabe que debe utilizar la interfaz de loopback (lo0) en vez de enviar los paquetes a a través de red. Las dos líneas que comienzan por host2 son ejemplos del uso de alias de &man.ifconfig.8; alias (consultar la sección sobre Ethernet para averiguar por qué nos podría interesar hacer esto.) El símbolo => después de la interfaz lo0 especifica que no sólo estamos utilizando la interfaz de loopback, si no que además especifica que se trata de un alias. Estas rutas sólo aparecen en las máquinas que implementan el alias, el resto de las máquinas de la subred local solamente poseerán una línea link#1 para dichas rutas. La última línea (destino de subred 224) trata sobre encaminamiento multicast, que cubriremos en otra sección. Finalmente, se pueden observar varios atributos relacionados con las rutas en la columna de Flags. A continuación se muestra una pequeña tabla con el significado de algunos de esos de los atributos o flags. U Up: La ruta está activa. H Host: El destino de la ruta es una única máquina. G Gateway: Envía cualquier cosa para éste destino a través de la pasarela especificada, la cual decidirá cómo encaminar el paquete hasta que eventualmente se alcance el destino. S Static: Esta ruta se configuró manualmente, y no se ha generado de forma automática por el sistema. C Clone: Genera una nueva ruta para la máquina a la que nos queremos conectar basándose en la ruta actual. Este tipo de ruta se utiliza normalmente en redes locales. W WasCloned: Indica una ruta que se auto-configuró basándose en una ruta de red de área local con etiqueta Clone. L Link: Esta ruta posée referencias a hardware de Ethernet. - Rutas por Defecto + Rutas por defecto default route Cuando el sistema local necesita realizar una conexión con una máquina remota se examina la tabla de rutas para determinar si se conoce algún camino para llegar al destino. Si la máquina remota pertenece a una subred que sabemos cómo alcanzar (rutas clonadas) entonces el sistema comprueba si se puede conectar utilizando dicho camino. Si todos los caminos conocidos fallan al sistema le queda una única opción: la ruta por defecto. Esta ruta está constituída por un tipo especial de - pasarela (normalmente el único encaminador presente en la red + pasarela (normalmente el único router + presente en la red área local) y siempre posée el flag c en el campo de flags. En una LAN, la pasarela es la máquina que posée conectividad con el resto de las redes (sea a través de un enlace PPP, DSL, cable modem, T1 u otra interfaz de red.) Si se configura la ruta por defecto en una máquina que está actuando como pasarela hacia el mundo exterior - la ruta por defecto será el encaminador que se encuentre en + la ruta por defecto será el router + que se encuentre en posesión del proveedor de servicios de internet (ISP). Vamos a examinar un ejemplo que utiliza rutas por defecto. A continuación se muestra una configuración bastante común: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] Las máquinas Local1 y Local2 se encuentran en nuestro sitio u organización. Local1 se conecta con un ISP a través de una conexión de modem PPP. El servidor PPP del ISP se conecta a través de una red de área local a otra pasarela utilizando una interfaz externa. Las rutas por defecto para cada una de las máquinas son las siguientes: Host Default Gateway Interface Local2 Local1 Ethernet Local1 T1-GW PPP Una pregunta bastante frecuente es ¿Por qué (o cómo) hacer que la máquina - T1-GW sea el encaminador por defecto para + T1-GW sea el router por defecto para Local1 en vez de que sea el servidor del ISP al cual se está conectando?. Recordemos que, como la interfaz PPP está utilizando una dirección de la red local del ISP en nuestro lado de la las rutas para cualquier otra máquina en la red local del proveedor se generarán de forma automática. De este ya sabemos el modo de alcanzar la máquina T1-GW, de tal forma que no se necesita un paso intermedio para enviar tráfico al servidor del ISP. Es frecuente utilizar la dirección X.X.X.1 como la dirección de la pasarela en la red local. Siguiendo con el ejemplo anterior, si nuestro espacio de direccionamiento local fuera la clase C 10.20.30 y nuestro ISP estuviera utilizando 10.9.9 las rutas por defecto serían: Host Default Route Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) Se puede especificar fácilmente la entrada de la ruta por defecto utilizando el fichero /etc/rc.conf. En nuestro ejemplo en la máquina Local2, se añadió la siguiente línea en dicho fichero: defaultrouter="10.20.30.1" También se puede hacer directamente desde la línea - de comandos mediante &man.route.8;: + de órdenes mediante &man.route.8;: &prompt.root; route add default 10.20.30.1 Para obtener más información sobre la manipulación de tablas de rutas se ruega consultar la página de manual &man.route.8;. - Máquinas con Doble Pertenencia (Dual Homed Hosts) + Máquinas con doble pertenencia (Dual Homed Hosts) dual homed hosts Existe otro tipo de configuración que debemos describir y que se produce cuando una máquina se sitúa en dos redes distintas al mismo tiempo. Técnicamente hablando cualquier máquina que actúa como pasarela (en el caso anterior utilizando un enlace de PPP) pertenece al tipo de máquinas con doble pertenencia, pero normalmente el término sólo se aplica para describir máquinas que se encuentran directamente conectadas con dos redes de área local. En un caso la máquina posée dos tarjetas de red Ethernet, cada una de ellas con una dirección de red independiente. En otro caso la máquina puede tener sólo una tarjeta de red, pero utilizar aliasing (&man.ifconfig.8;). El primer caso se utiliza cuando se necesita usar dos redes Ethernet al mismo tiempo mientras que el segundo caso se utiliza cuando se dispone de un único segmento de red físico pero se han definido dos redes lógicas distintas En cualquier caso la tabla de rutas se construye de tal forma que cada subred sepa que la máquina es la pasarela definida definida (inbound route) para la otra subred. Ésta configuración en la que la máquina - actúa como encaminador entre las dos subredes se usa a menudo + actúa como router entre las dos subredes se + usa a menudo cuando queremos implementar filtrado de paquetes o cortafuegos seguridad en un sentido o en ambos. Si queremos que dicha máquina encamine paquetes entre las dos interfaces es necesario decirle a FreeBSD que active dicha funcionalidad. En la siguiente sección se explica cómo hacerlo. - Construcción de un Encaminador + Construcción de un <quote>route</quote> router - Un encaminador de red, también llamado pasarela o - router, es simplemente un sistema que reenvía + Un router de red, también llamado pasarela o + route, es simplemente un sistema que reenvía paquetes desde un interfaz hacia otro interfaz. Los estándares Internet y el sentido común aplicado a la ingeniería de redes impiden que FreeBSD incluya por defecto ésta característica. Se puede activar cambiando a YES el valor de la siguiente variable en el fichero &man.rc.conf.5;: gateway_enable=YES # Set to YES if this host will be a gateway Esta opción modificará la variable de &man.sysctl.8; net.inet.ip.forwarding al valor 1. Si en algún momento se necesita - detener el encaminador de forma temporal basta con asignar a dicha + detener el router de forma temporal basta con + asignar a dicha variable el valor 0. Consulte &man.sysctl.8; para más detalles. - Nuestro recién activado encaminador necesita rutas para + Nuestro recién activado router + necesita rutas para saber a dónde debe enviar el tráfico recibido. Si nuestra red es ña se pueden definir rutas estáticas. FreeBSD incluye por defecto el dæmon de encaminamiento BSD, &man.routed.8;, que admite RIP (versión 1 y versión 2) e IRDP. El paquete net/zebra le permitirá usar otros protocolos de encaminamiento dinámico como BGP v4, OSPF v2 y muchos otros. En caso de necesitar características avanzadas de gestión puede usted recurrir a productos comerciales como &gated;. BGP RIP OSPF Incluso cuando FreeBSD se configura del modo descrito no se cumple completamente con los estándares de Internet - respecto a los encaminadores de red. Bastará no obstante + respecto a los routers. Bastará no obstante para poder usarse. Al Hoang Escrito por - Configuración de Rutas Estáticas + Configuración de rutas estáticas - Configuración Manual + Configuración manual Vamos a suponer que tenemos la siguiente topología de red: INTERNET | (10.0.0.1/24) Router por defecto para Internet | |Interfaz xl0 |10.0.0.10/24 +------+ | | RouterA | | (pasarela FreeBSD) +------+ | Interfaz xl1 | 192.168.1.1/24 | +--------------------------------+ Red Interna 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Red Interna 2 En este escenario RouterA es nuestra máquina &os; que actúa como pasarela para acceder al resto de internet. Tiene una ruta por defecto que apunta a 10.0.0.1 que le permite conectarse con el mundo exterior. Vamos a suponer también que RouterB se encuentra configurado de forma adecuada que sabe cómo llegar a cualquier sitio que necesite. Esto es sencillo viendo nuestra topología de red, basta con añadir una ruta por defecto en la máquina RouterB utilizando - 192.168.1.1 como encaminador. + 192.168.1.1 como + router. Si observamos la tabla de rutas de RouterA veremos algo como lo siguiente: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 Con la tabla de rutas actual RouterA no es capaz de alcanzar la red interna 2. Esto es así porque no posee ninguna ruta para la red 192.168.2.0/24. Una forma de - mitigar esto es añadir de forma manual la ruta que falta. El - siguiente comando añade la red interna 2 a la tabla de rutas + mitigar esto es añadir de forma manual la ruta que falta. La + siguiente orden añade la red interna 2 a la tabla de rutas de la máquina RouterA utilizando 192.168.1.2 como siguiente salto: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Ahora RouterA puede alcanzar cualquier máquina en la red 192.168.2.0/24. - Cómo Hacer la Configuración Persistente + Cómo hacer la configuración persistente El ejemplo anterior es perfecto en tanto que resuelve el problema de encaminamiento entre redes pero existe un problema. La información de encaminamiento desaparecerá si se reinicia la máquina. La forma de evitarlo es añadir las rutas estáticas a /etc/rc.conf: # Añade la red interna 2 como una ruta estática static_routes="redinterna2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" La variable de configuración static_routes es una lista de cadenas separadas por espacios. Cada cadena identifica un nombre para la ruta que se desea definir. En el ejemplo anterior sólamente se dispone de una cadena dentro de la variable static_routes. Esta cadena es redinterna2. A continuación se añade otra variable de configuración denominada route_redinterna2 donde se escriben todos los parámetros de configuración que normalmente utilizaríamos normalmente utilizaríamos con &man.route.8;. - En el ejemplo que estamos comentando se utilizaría el - siguiente comando: + En el ejemplo que estamos comentando se utilizaría la + siguiente orden: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 De tal forma que la variable debería contener "-net 192.168.2.0/24 192.168.1.2". Como ya se ha comentado anteriormente podemos especificar más de una cadena en la variable static_routes. Esto nos permite crear varias rutas estáticas. Las siguientes línas muestran un ejemplo donde se añaden rutas estáticas para las redes 192.168.0.0/24 y 192.168.1.0/24 en un routerimaginario: static_routes="red1 red2" route_red1="-net 192.168.0.0/24 192.168.0.1" route_red2="-net 192.168.1.0/24 192.168.1.1" - Propagación del Encaminamiento + Propagación de rutas routing propagation Ya hemos comentado cómo se definen las rutas para el mundo exterior pero no hemos comentado nada sobre cómo haremos que el mundo exterior nos encuentre a nosotros. También hemos aprendido que las tablas de rutas se pueden construír de tal forma que un grupo de tráfico (perteneciente a un espacio de direcciones determinado) se reenvíe a una máquina específica de la red, que se encargará de reenviar los paquetes hacia adentro. Cuando se obtiene un espacio de direcciones para la organización el proveedor de servicios modifica sus tablas de rutas para que todo el tráfico para nuestra subred se encamine a través del enlace PPP hasta alcanzarnos. Pero ¿cómo conocen las organizaciones dispersas a través del país que deben enviar los paquetes dirigidos a nosotros hacia nuestro ISP? Existe un sistema (muy similar al sistema de nombres de dominio, DNS) que se encarga de controlar todos los espacios de direcciones que se encuentran actualmente repartidos y que además define sus puntos de conexión con el backbone de internet. El backbone está formado por las principales líneas de de comunicacion que se encargan de transportar el tráfico de internet a través del país y del mundo entero. Cada máquina del backbone dispone de una copia de un conjunto maestro de tablas de rutas gracias a las cuales pueden dirigir el tráfico para una red particular hacia una determinada red de transporte de dicho backbone. Una vez en la red de transporte adecuada el tráfico se encamina a través de un número indeterminado de redes de proveedores de servicio hasta que se alcanza la red de destino final. Una de las tareas que debe realizar el proveedor de servicio servicio consiste en anunciarse a las organizaciones del consiste en anunciarse a las organizaciones del backbone como el punto de conexión principal (y por tanto como el camino de entrada) para alcanzar las redes de sus clientes. Este proceso se denomina propagación de rutas. - Depuración de Problemas + Solución de problemas traceroute En algunas ocasiones surgen problemas con la propagación de las rutas y algunas organizaciones son incapaces de conectarse con - nuestra subred. Quizá el comando más útil para + nuestra subred. Quizá la orden más útil para averiguar dónde se está interrumpiendo el sistema de encaminamiento sea &man.traceroute.8;. Se puede usar también cuando somos nosotros los que no podemos alcanzar alguna red externa (por ejemplo cuando &man.ping.8; falla). &man.traceroute.8; se ejecuta pasandole como parámetro el nombre de la máquina remota a la que nos queremos - conectar. El comando muestra por pantalla lás máquinas + conectar. Esta orden muestra por pantalla lás máquinas que actúan de pasarela a lo largo del camino. El proceso termina bien porque se alcanza el destino o bien porque algún router intermedio no puede conectarse con el siguiente salto, o lo desconoce. Si quiere saber más sobre esto consulte la página man de &man.traceroute.8;. - Encaminamiento Multicast + Rutas multicast multicast options MROUTING FreeBSD soporta tanto aplicaciones multicast como encaminamiento multicast de forma nativa. Las aplicaciones multicast no necesitan ninguna configuración especial en FreeBSD; estas aplicaciones se ejecutan tal cual. El encaminamiento multicast necesita para ser usado que se compile dicho soporte en el núcleo de FreeBSD: options MROUTING Se debe configurar además el dæmon de encaminamiento multicast, &man.mrouted.8;, para establecer túneles y ejecutar DVMRP utilizando /etc/mrouted.conf. Se pueden encontrar más detalles sobre cómo realizar una configuración de multicast en &man.mrouted.8;. Eric Anderson Escrito por Redes sin cables (<quote>wireless</quote>) wireless networking 802.11 Redes sin cables Introducción Puede resultar muy útil el ser capaz de utilizar una computadora sin la molestia de tener un cable de red colgando de la máquina en todo momento. FreeBSD puede utilizarse como un cliente de wireless e incluso como un punto de acceso. - Modos de Operación Wireless + Modos de operación Wireless Existen dos formas diferentes de configurar dispositivos wireless 802.11: BSS e IBSS. Modo BSS El modo BSS es el que se utiliza normalmente. Este modo también se denomina modo infraestructura. En esta configuración se conectan un determinado número de puntos de acceso a una red cableada. Cada red Cada red wireless posée su propio nombre. Este nombre es el SSID de la red. Los clientes wireless se conectan a estos puntos de acceso. El estándar IEEE 802.11 define el protocolo que se utiliza para realizar esta conexión. Un cliente wireless puede asociarse con una determinada red wireless especificando el SSID. Un cliente wireless también puede asociarse a cualquier red que se encuentre disponible; basta con no especificar ningún SSID. Modo IBSS El modo IBSS, también conocido como modo ad-hoc, se ha diseñado para facilitar las conexiones punto a punto. En realidad existen dos tipos distintos de modos ad-hoc. Uno es el modo IBSS, también conocido como modo ad-hoc o modo ad-hoc del IEEE. Este modo se encuentra especificado en el estándar IEEE 802.11. El segundo tipo se denomina modo ad-hoc de demostración o modo ad-hoc de Lucent (y algunas veces, también se le llama simplemente modo ad-hoc, lo cual es bastante confuso). Este es el modo de funcionamiento antíguo, anterior al estándar 802.11, del modo ad-hoc debería utilizarse sólo en instalaciones propietarias. No profundizaremos más sobre estos modos de funcionamiento. - Modo Infraestructura + Modo infraestructura - Puntos de Acceso + Puntos de acceso Los puntos de acceso son dispositivos de red wireless que funcionan de forma equivalente a los hubs o concentradores, permitiendo que varios clientes wireless se comuniquen entre sí. A menudo se utilizan varios puntos de acceso para cubrir un área determinada como una casa, una oficina u otro tipo de localización delimitada. Los puntos de acceso poseen típicamente varias conexiones de red: la tarjeta wireless y una o más tarjetas Ethernet que se utilizan para comunicarse con el resto de la red. Los puntos de acceso se pueden comprar como tales pero también se puede configurar un sistema FreeBSD para crear nuestro propio punto de acceso wireless utilizando un determinado tipo de tarjetas wireless que poseen tales capacidades de configuración. Existe una gran cantidad de fabricantes de hardware que distribuyen puntos de acceso y tarjetas de red wireless, aunque las capacidades de unos y otras varín. - Construcción de un Punto de Acceso basado en - FreeBSD + Construcción de un punto de acceso basado en + &os; wireless networking - Punto de Acceso + Punto de acceso Requisitos Para crear nuestro propio punto de acceso con FreeBSD debemos utilizar un determinado tipo de tarjeta wireless. Por el momento, sólo las tarjetas con el chip Prism nos permiten hacer un punto de acceso. También vamos a necesitar una tarjeta para red cableada que sea soportada por el sistema (esto no es muy complicado dada la ingente cantidad de dispositivos de este tipo que funcionan en FreeBSD). Para este ejemplo vamos a suponer que queremos puentear (&man.bridge.4;) todo el tráfico entre la red cableada y la red inalámbrica. El uso como punto de acceso wireless (también denominado hostap) funciona mejor con determinadas versiones del firmware. Las tarjetas con chip Prism2 deben disponer de la versión 1.3.4 (o superior) del firmware. Los chips Prism2.5 y Prism3 deben disponer de la versión 1.4.9 o superior del firmware. Las versiones más antíguas de estos firmwares pueden no funcionar correctamente. A día de hoy la única forma de actualizar el firmware de las tarjetas es usando las herramientas que proporciona el fabricante para &windows;. - Puesta en Marcha del Sistema + Puesta en marcha del sistema Primero debemos asegurarnos de que el sistema reconoce la tarjeta wireless: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "nodo Wireless FreeBSD" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 No se preocupe si no entiende algo de la configuración anterior, lo importante es asegurarse de que el sistema muestra algo parecido, lo cual nosindicará que la tarjeta wireless ha sido correctamente reconocida por FreeBSD. Si el interfaz inalámbrico no es reconocido correctamente y se está utilizando una tarjeta PC Card consulte &man.pccardc.8; y &man.pccardd.8;, en las que tiene mucha información al respecto. A continuación, para que podamos disponer de un bridge deberá cargar el módulo del kernel &man.bridge.4; por el sencillo procedimiento de - ejecutar el siguiente comando: + ejecutar la siguiente orden: &prompt.root; kldload bridge No debería aparecer mensaje de error alguno al ejecutar - dicho comando. Si apareciera alguno quizás deba compilar + dicha orden. Si apareciera alguno quizás deba compilar el kernel del sistema con &man.bridge.4; incluído. La sección Bridging de éste manual incluye información abundante para llevar a buen puerto esa tarea. Una vez que tenemos el soporte de bridging cargado debemos indicar a FreeBSD qué interfaces se desean puentear. Para ello emplearemos &man.sysctl.8;: &prompt.root; sysctl net.link.ether.bridge=1 &prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 En &os; 5.2-RELEASE y posteriores se deben emplear las siguientes opciones en lugar de las anteriormente expuestas: &prompt.root; sysctl net.link.ether.bridge.enable=1 &prompt.root; sysctl net.link.ether.bridge.config="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Ahora es el momento de configurar la tarjeta de red - inalámbrica. El siguiente comando convierte la tarjeta en + inalámbrica. La siguiente orden convierte la tarjeta en un punto de acceso: &prompt.root; ifconfig wi0 ssid mi_red channel 11 media DS/11Mbps mediaopt hostap up stationname "PA FreeBSD" La línea de &man.ifconfig.8; levanta el interfaz wi0, configura el SSID con el valor de mi_red y también el nombre de la estación como FreeBSD. La opción configura la tarjeta a 11Mbps. Ésto es necesario para que cualquier valor que se necesite asignar a surta efecto. La opción sitúa el interfaz en modo punto de acceso. La opción configura la tarjeta para que use el canal de radio número 11. En &man.wicontrol.8; encontraráa rangos de canales válidos para varios dominios regulatorios. Por favor, tenga en cuenta que no todos los canales son legales en todos los países. Despues de esto deberíamos disponer de un punto de acceso completamente funcional y en ejecución. Le animamos a consultar &man.wicontrol.8;, &man.ifconfig.8; y &man.wi.4; para máss información. También le recomemdamos leer la sección sobre cifrado que econtrará más adelante. - Información de Estado + Información de estado Una vez que el punto de acceso estáconfigurado resulta interesante poder obtener información acerca de los clientes que estén asociados. La persona encargada de la administración del punto de acceso puede ejecutar cuando estime oportuno lo siguiente: &prompt.root; wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 Lo que aquí se muestra indica que hay una única estación asociada y nos suministra sus parámetros. Los valores de señal que se muestran se deben tomar sólo como indicaciones aproximadas de la fuerza de dicha señal. Su traducción a dBm u otras unidades varía según la versión del firmware de la tarjeta que se use. Clientes Un cliente wireless es un sistema que se comunica con un punto de acceso o directamente con otro cliente wireless. Generalmente los clientes wireless sólo poseen un dispositivo de red: la tarjeta de red inalámbrica. Existen varias formas de configurar un cliente wireless basadas en los distintos modos inalámbricos, normalmente reducidos a BSS (o modo infraestructura, que requiere de un punto de acceso) y el modo IBSS (modo ad-hoc, o modo punto a punto). En nuestro ejemplo usaremos el más famoso de ambos, el BSS, para comunicarnos con un punto de acceso. Requisitos Sólamente existe un requisito real para configurar un sistema FreeBSD como cliente inalámbrico: usar una tarjeta de red inalámbrica soportada por el sistema. - Ejecución de un cliente inalámbrico FreeBSD + Ejecución de un cliente inalámbrico &os; Para utilizar una red inalámbrica se necesitan conocer algunos conceptos básicos de redes de redes wireless. En nuestro ejemplo queremos conectarnos a la red inalámbrica mi_red y queremos hacerlo con el soporte de cifrado desactivado. En este ejemplo no se utiliza cifrado, lo cual resulta ser bastante peligroso. En la próxima sección aprenderemos cómo activar el sistema de cifrado común el los dispositivos inalámbricos, por qué resulta importante hacerlo y por qué algunas tecnologías de cifrado no son suficientes para protegernos completamente. Asegúrese de que FreeBSD reconoce su tarjeta de red inalámbrica: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 A continuación debemos especificar los parámetros correctos para nuestra red: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid mi_red Sustituya 192.168.0.20 y 255.255.255.0 con una dirección IP y máscara de red que se adecúen con el espacio de direccionamiento de la red cableada. Recordemos que nuestro punto de acceso está puenteando la red inalámbrica y la red de cable, de modo que para el resto de dispositivos de la red el cliente inalábrico se muestra como un elemento más de la red cableada. Llegados a este punto deberíamos poder hacer ping a las máquinas de la red cableada como si estuviéramos compartiendo el mismo enlace físico cableado. Si se presentan problemas con la conexión inalámbrica se puede comprobar si la tarjeta wireless se encuentra correctamente asociada (conectada) con el punto de acceso: &prompt.root; ifconfig wi0 ebería devolver algún tipo de información entre la que deberíamos observar la siguiente línea: status: associated Si no aparece la palabra associated puede ser que nos encontremos fuera de la cobertura proporcionada por el punto de acceso o puede ser que necesitemos activar el cifrado, aunque éstos no son los únicos problemas con los que nos podemos encontrar. Cifrado wireless networking encryption El cifrado, también llamado codificación, de una red inalámbrica es un proceso importante porque, a diferencia de lo que ocurre con las redes cableadas convencionales, las redes inalámbricas no se pueden restringir a un espacio físico determinado. Los datos que viajan a través de ondas de radio se difunden a través de las paredes y alcanzan a los vecinos más cercanos. Aquí es donde entra en en juego el sistema de cifrado. El cifrado se emplea para evitar que cualquiera pueda examinar los datos enviados a través del aire. Los dos métodos más comunes para realizar el cifrado de datos entre el cliente y el punto de acceso son WEP e &man.ipsec.4;. WEP WEP WEP son las siglas de Wired Equivalency Protocol. WEP es un un intento de crear redes inalámbricas al menos tan seguras omo las redes cableadas o al menos de seguridad equivalente a dichas redes. Por desgracia el sistema WEP es débil y resulta bastante sencillo de romper. Esto significa que cuando se transmite información de carácter crítico no se debe confiar únicamente en este sistema de cifrado. No obstante es mejor que no utilizar nada; puede activar WEP en el sistema que hace de punto de acceso mediante: &prompt.root; ifconfig wi0 inet up ssid mi_red wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap - y en un cliente inalámbrico mediante el siguiente - comando: + y en un cliente inalámbrico mediante la siguiente + orden: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid mi_red wepmode on wepkey 0x1234567890 Por favor, tenga un poco de sentido común y reemplace la clave 0x1234567890 por otra clave menos obvia. IPsec &man.ipsec.4; es una herramienta más robusta y potente para cifrar datos que se mueven a través de una red. Es el mecanismo más conveniente para asegurar los datos de una red inalámbrica. Tiene más información sobre el protocolo &man.ipsec.4; y cómo utilizarlo en la sección IPsec de este manual. Herramientas No hay muchas herramientas disponibles si se quiere depurar y monitorizar redes inalámbricas pero en el siguiente apartado mostraremos cómo utilizar algunas de ellas. El paquete <application>bsd-airtools</application> El paquete bsd-airtools es un conjunto muy completo de herramientas wireless que se pueden utilizar para multitud de tareas, entre las cuales podemos citar citar el desciframiento de claves WEP, detección de puntos de de acceso, monitorización de la señal de radio, etc. El paquete bsd-airtools se puede instalar como port desde net/bsd-airtools. La información relacionada con los ports puede encontrarse en la sección de este manual. El programa dstumbler es una herramienta que permite descubrir puntos de acceso y entre otras cosas muestra de forma gráfica la relación señal / ruido del enlace. Si se experimentan problemas para acceder a un determinado punto de acceso dstumbler puede ser muy útil. Para probar la seguridad de la red inalámbrica se puede usar - dweputils, concretamente los comandos + dweputils, concretamente las órdenes dwepcrack, dwepdump y - dwepkeygen. Estos comandos permiten determinar hasta + dwepkeygen. Estas órdenes permiten determinar hasta qué punto la seguridad que ofrece WEP es suficiente para nuestras necesidades. Las utilidades <command>wicontrol</command>, <command>ancontrol</command> y <command>raycontrol</command> Mediante estas herramientas se puede controlar el comportamiento de la tarjeta de red inalámbrica. En los ejemplos anteriores se ha utilizado &man.wicontrol.8; debido a que la tarjeta de red del ejemplo utiliza el interfaz wi0. Si se posée una tarjeta wireless de Cisco dicha tarjeta se mostrará en el sistema mediante el interfaz - an0 y por lo tanto el comando equivalente que se debe usar + an0 y por lo tanto la orden equivalente que se debe usar será &man.ancontrol.8;. <command>ifconfig</command> ifconfig Con &man.ifconfig.8; se puede utilizar unas cuantas de las opciones que se pueden usar con &man.wicontrol.8;, pero no obstante no posée todas las funcionalidades que proporciona &man.wicontrol.8;. Se recomienda leer &man.ifconfig.8; para conocer los detalles de los parámetros y opciones que admite. - Tarjetas de Red Inalámbricas Soportadas + Tarjetas de Red inalámbricas soportadas - Puntos de Acceso + Puntos de acceso Las únicas tarjetas que soportan el modo de funcionamiento funcionamiento BSS (pueden funcionar como puntos de acceso) son los dispositivos basados en el chip Prism 2, 2.5 ó 3. Consulte &man.wi.4; para ver una lista completa de ellos. Clientes FreeBSD soporta casi todas las tarjetas inalámbricas 802.11b 802.11b que se encuentran actualmente en el mercado. La mayoría de las tarjetas basadas en los chips Prism, Spectrum24, Spectrum24, Hermes, Aironet y Raylink tambíen funcionan en modo IBSS (modos ad-hoc, punto a punto y BSS). Pav Lucistnik Escrito por
pav@oook.cz
 Bluetooth Bluetooth Introducción Bluetooth es una tecnología inalámbrica que opera en banda de 2.4 GHz (donde no se necesita licencia). Se trata de una tecnología pensada para la creación de redes de ámbito personal (de cobertura reducida, normalmente de unos 10 metros). Las redes se suelen construir en modo ad-hoc utilizando dispositivos heterogéneos como teléfonos móviles, dispositivos manuales (handhelds) y computadoras portátiles. A diferencia de otras tecnologías inalámbricas como Wi-Fi, Bluetooth ofrece perfiles de servicio más detallados; por ejemplo un perfil para actuar como un servidor de ficheros basado en FTP, para la difusión de ficheros (file pushing), para el transporte de voz, para la emulación de línea serie y muchos más. La pila de Bluetooth en &os; se implementa utilizando el entorno de Netgraph (véase &man.netgraph.4;). La mayoría de los dispositivos USB Bluetooth se pueden utilizar mediante el controlador &man.ng.ubt.4;. Los dispositivos Bluetooth basados en el chip Broadcom BCM2033 están soportados mediante los controladores &man.ubtbcmfw.4; y &man.ng.bt3c.4;. Los dispositivos Bluetooth basados en la interfaz serie o de Rayos Infrarrojos (UART) se controlan mediante &man.sio.4;, &man.ng.h4.4; y &man.hcseriald.8;. Este capítulo describe el uso de dispositivos Bluetooth USB. El soporte para Bluetooth se encuentra en las versiones de &os; 5.0 y posteriores. - Instalación del Dispositivo + Instalación del dispositivo Por defecto los controladores de los dispositivos Bluetooth se encuentran disponibles como módulos del kernel. Antes de enchufar el dispositivo Bluetooth se debe cargar el módulo correspondiente dentro del núcleo. &prompt.root; kldload ng_ubt Si el dispositivo Bluetooth se encuentra conectado cuando el sistema arranca se debe cargar el módulo modificando a tal efecto el fichero /boot/loader.conf. ng_ubt_load="YES" Al conectar el dispositivo Bluetooth aparecerá en la consola (o en syslog) la siguiente información: ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Se debe copiar /usr/share/examples/netgraph/bluetooth/rc.bluetooth a algún lugar más conveniente, por ejemplo /etc/rc.bluetooth. Este script se usa para ejecutar y detener la pila Bluetooth del sistema. Se suele recomendar quitar la pila antes de desenchufar el dispositivo pero si no se hace no debería producirse ningún desastre. Cuando se arranca la pila aparece un mensaje similar a este: &prompt.root; /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI - Interfaz de la Controladora de la Máquina (HCI) + Interfaz de la controladora de la máquina (HCI) La interfaz de la Controladora de la Máquina (Host - Controller Interface) proporciona una interfaz de comandos + Controller Interface) proporciona una interfaz de órdenes para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control. Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base. La capa HCI de la máquina intercambia - comandos y datos con el firmware del HCI presente en el + órdenes y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas. Se crea un nodo Netgraph de tipo HCI para cada dispositivo Bluetooth. El nodo Netgraph HCI se conecta normalmente con el nodo que representa el controlador del dispositivo Bluetooth de la máquina (sentido de bajada) y con el nodo Netgraph L2CAP en el sentido de subida. Todas las operaciones HCI se realizan sobre el nodo Netgraph HCI y no sobre el el nodo que representa al dispositivo. El nombre por defecto para el nodo HCI es devicehci. Para obtener más detalles, por favor consulte la página del manual de &man.ng.hci.4;. Una de las tareas más importantes que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Esta operación o otras operaciones HCI relacionadas se realizan mediante la utilidad &man.hccontrol.8;. El siguiente ejemplo muestra cómo descubrir dispositivos en pocos segundos. Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo descubrimiento (discoverable mode). &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos. Se puede asignar un nombre más significativo para los humanos en la variable BD_ADDR. El fichero /etc/bluetooth/hosts contiene información relativa a los dispositivos Bluetooth conocidos. El siguiente ejemplo muestra cómo obtener un nombre significativo para los humanos que fué asignado a un dispositivo remoto: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como nombre.de.su.sistema (ubt0). El nombre asignado al dispositivo local se puede modificar en cualquier momento. El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth. El siguiente ejemplo muestra como obtener una lista de las conexiones de banda base activas en el dispositivo local: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN Resulta útil disponer de un manejador de la conexión cuando se necesita terminar la conexión de banda base. Es importante recalcar que normalmente no es necesario realizar esta terminación de forma manual. La pila Bluetooth puede concluír automáticamente las conexiones de banda base que se encuentren inactivas. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] - Se ruega consultar la salida del comando + Se ruega consultar la salida de la orden hccontrol help para obtener un listado completo de - los comandos HCI que se encuentran disponibles. La mayoría de - éstos comandos no requiren privilegios de superusuario. + las órdenes HCI disponibles. La mayoría de + estas órdenes no requiren privilegios de superusuario. L2CAP - Protocolo de Adaptación y de Control de Enlace a - nivel Lógico (L2CAP) + Protocolo de adaptación y de control de enlace a + nivel lógico (L2CAP) El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje. L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud. L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel. Para cada dispositivo Bluetooth se cre un único nodo Netgraph de tipo l2cap. El nodo L2CAP se conecta normalmente conectado al nodo Netgraph HCI (hacia abajo) y con nodos Bluetooth tipo sockets hacia arriba. El nombre por defecto para el nodo Netgraph L2CAP es devicel2cap. Para obtener más detalles se ruega consultar la página del manual &man.ng.l2cap.4;. - Un comando muy útil es el &man.l2ping.8;, el cual se puede - utilizar para hacer ping a otros dispositivos. Algunas + &man.l2ping.8; le será muy útil para + hacer ping a otros dispositivos. Algunas implementaciones de Bluetooth no devuelven todos los datos que se envían, de tal forma que el valor 0 bytes que se observa a continuación es normal: &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 La herramienta &man.l2control.8; se utiliza para realizar varias operaciones sobre los nodos L2CAP. Este ejemplo muestra cómo obtener la lista de conexiones lógicas (canales) y la lista de conexiones de banda base (física) que mantiene el dispositivo local: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Otra herramienta de diagnóstico interesante es - &man.btsockstat.1;. Realiza un trabajo similar al comando + &man.btsockstat.1;. Realiza un trabajo similar a la orden &man.netstat.1;, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Protocolo RFCOMM El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protoclo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultaneas (canales RFCOMM) entre dos dispositivos Bluetooth. Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa). RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro. En &os; el protocolo RFCOMM se implementa utilizando la capa de sockets de Bluetooth. pairing - Enparejamiento de Dispositivos + Enparejamiento de dispositivos Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem). La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos. Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave. El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento. El dæmon &man.hcsecd.8; se encarga de gestionar todas las peticiones de autenticación Bluetooth. El archivo de configuración predeterminado se denomina /etc/bluetooth/hcsecd.conf. A continuación se muestra una sección de ejemplo de un teléfono celular con el código PIN arbitrariamente fijado al valor 1234: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN. La opción fuerza al dæmon &man.hcsecd.8; a permanecer ejecutádose en primer plano, de tal forma que se puede observar fácilmente lo que ocurre. Si se configura el dispositivo Bluetooth remoto para aceptar el procedimiento de emparejamiento y se inicia la conexión con dicho dispositivo, el dispositivo remoto debería decir que el procedimiento de emparejamiento se ha aceptado y debería solicitar el código PIN. Si se introduce el mismo código PIN que se escribió en su momento en el fichero hcsecd.conf el procedimiento de emparejamiento y de generación de la clave de enlace debería terminar satisfactoriamente. Por otra parte el procedimiento de emparejamiento se puede iniciar en el dispositivo remoto. A continuación se muestra un ejemplo de la salida del dæmon hcsecd. hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP - Protocolo de Descubrimiento de Servicios (SDP) + Protocolo de descubrimiento de servicios (SDP) + El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen. Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios. SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP. El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios. Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing. El servidor Bluetooth SDP denominado &man.sdpd.8; y el cliente de - línea de comando denominado &man.sdpcontrol.8; se incluyen en + línea de órdenes &man.sdpcontrol.8; se incluyen en la instalación estándar de &os;. El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 ... y así sucesivamente. Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. El ejemplo siguiente muestra cómo buscar el servicio OBEX Object Push (OPUSH): &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH En &os; los servicios a clientes Bluetooth se suministran mediante el servidor &man.sdpd.8;. &prompt.root; sdpd La aplicación local servidora que quiere proporcionar servicio Bluetooth a los clientes remotos puede registrar su servicio con el dæmon SDP local. Un ejemplo de dicha aplicación Un ejemplo de dicha aplicación lo constituye el dæmon &man.rfcomm.pppd.8;. Una vez ejecutado el dæmon registra un servicio LAN de Bluetooth en el dæmon SDP local. Se puede obtener la lista de servicios registrados con el servidor SDP local lanzando una consulta de navegación SDP utilizando el canal de control local. &prompt.root; sdpcontrol -l browse - Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante + <title>Acceso telefónico a redes (DUN) y acceso a redes mediante perfiles PPP (LAN) El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación: Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados; Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos. El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones: Acceso LAN para un único dispositivo Bluetooth; Acceso LAN para múltiples dispositivos Bluetooth; Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie). - En &os; ambos perfiles se implementan bajo los comandos + En &os; ambos perfiles se implementan bajo las órdenes &man.ppp.8; y &man.rfcomm.pppd.8;, un encapsulador que convierte la conexión RFCOMM de Bluetooth en algo que puede ser utilizado por PPP. Antes de que se puedan utilizar los perfiles se debe definir una nueva etiqueta PPP en el fichero de configuración /etc/ppp/ppp.conf. Consulte &man.rfcomm.pppd.8; para ver algunos ejemplos. En el siguiente ejemplo se va a utilizar &man.rfcomm.pppd.8; para abrir una conexión RFCOMM con un dispositivo remoto con BD_ADDR 00:80:37:29:19:a4 sobre un canal RFCOMM basado en DUN (Dial-Up Networking). El número de canal RFCOMM se obtiene a partir del dispositivo remoto a través de SDP. Es posible especificar el canal RFCOMM a mano, en cuyo caso &man.rfcomm.pppd.8; no - realizará ninguna consulta SDP. Se puede utilizar el comando + realizará ninguna consulta SDP. Se puede utilizar la orden &man.sdpcontrol.8; para descubrir el canal RFCOMM utilizado en el dispositivo remoto. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup Para proporcionar el servicio de Acceso a Redes a través de PPP (LAN) se debe ejecutar el servidor &man.sdpd.8;. Se debe crear una nueva entrada en /etc/ppp/ppp.conf. Le rogamos que consulte &man.rfcomm.pppd.8; y observe los ejemplos que se facilitan. Por último se debe ejecutar el servidor PPP RFCOMM sobre un número de canal RFCOMM adecuado. El servidor PPP RFCOMM registrará automáticamente el servicio LAN de Bluetooth con el servidor SDP local. El ejemplo que se muestra a continuación describe cómo ejecutar el servidor PPP RFCOMM. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX Perfil OBEX Object Push (OPUSH) OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM. El cliente y el servidor de OBEX se implementan como un paquete denominado obexapp disponible como port en comms/obexapp. El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número. A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Para proporcionar servicio de OBEX el servidor &man.sdpd.8; debe estar en funcionamiento. Además se debe crear un directorio raíz donde todos los objetos van a ser almacenados. La ruta por defecto para el directorio raíz es /var/spool/obex. Por último se debe ejecutar el servidor OBEX en un número de canal RFCOMM válido. El servidor OBEX registra automáticamente el servicio de Object Push con el dæmon SDP local. El ejemplo que se muestra a local. El ejemplo que se muestra a continuación continuación describe cómo ejecutar el servidor OBEX. &prompt.root; obexapp -s -C 10 - Perfil de Puerto Serie (SP) + Perfil de puerto serie (SP) El perfil de puerto serie (Serial Port o SP) permite que dispositivos Bluetooth realicen emulación de RS232 (o similar). El escenario cubierto por este perfil trata con con aplicaciones comerciales que utilizan Bluetooth como un sustituto sustituto del cable, utilizando una capa de abstracción que representa un puerto serie virtual. La aplicación &man.rfcomm.sppd.1; implementa el perfil Puerto Serie. Usa una pseudo tty como abstracción de puerto serie virtual. El ejemplo de más abajo muestra cómo conectarse a un servicio de dispositivo remoto de Puerto Serie. Observe que no necesita especificarse el canal RFCOMM: &man.rfcomm.sppd.1; puede obtenerlo del dispotivo remoto via SDP. Si necesita especificarlo por alguna razón - hágalo en la propia línea de comandos. + hágalo en la propia línea de órdenes. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Una vez conectado el pseudo tty se puede utilizar como un puerto serie. &prompt.root; cu -l ttyp6 - Depuración de Problemas + Solución de problemas Un dispositivo remoto no puede conectarse + Algunos dispositivos Bluetooh antiguos no soportan el cambio de cambio de roles. Por defecto, roles. Cuando &os; acepta una nueva conexión por defecto intenta realizar un cambio de rol y convertirse en maestro. Dispositivos que no son capaces de realizar este cambio no pueden conectarse. Es interesante resaltar que el cambio de roles se realiza cuando se está estableciendo una nueva conexión de tal forma que no es posible preguntar al dispositivo si soporta intercambio de roles. Existe una opción HCI para desactivar el intercambio de roles en la parte local. &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Algo va mal ¿puedo ver exactamente qué está ocurriendo? Sí, se puede. Utilice el paquete hcidump-1.5, que se puede descargar de aquí. La herramienta hcidump es similar a la herramienta &man.tcpdump.1;. Se puede utilizar para mostrar el contenido de los paquetes Bluetooth sobre el terminal y para volcar los paquetes Bluetooth a un fichero. Steve Peterson Escrito por Puenteado Introducción IP subnet bridge Algunas veces resulta útil dividir una red física (como por ejemplo un segmento Ethernet) en dos segmentos de red separados, sin tener que crear subredes IP y sin utilizar una pasarela para comunicar ambos segmentos. El dispositivo que realiza esta función se denomina bridge. Un sistema FreeBSD con dos interfaces de red puede actuar como un bridge o puente entre ambas. El bridge funciona de tal forma que aprende las direcciones de la capa MAC (direcciones Ethernet) de los nodos que se encuentran conectados a cada interfaz de red de tal forma que sólo se reenvía tráfico entre los segmentos de red cuando las direcciones fuente y destino se encuentran separadas en segmentos distintos. En varios aspectos se puede comparar un bridge con un switch de pocos puertos. - Situaciones donde el Puenteado resulta adecuado + Situaciones donde el puenteado resulta adecuado Existen al menos dos situaciones típicas donde se puede utilizar la funcionalidad proporcionada por los bridges. Tráfico de gran volumen en un segmentos de red La primera situación surge cuando nos encontramos con un segmento de red congestionado pero por las razones que sean no queremos subdividir la red e interconectar las nuevas subredes - mediante un encaminador. + mediante un route. Vamos a considerar un ejemplo de un periódico donde los departamentos editoriales y de producción utilizan la misma subred. Los usuarios de la editorial utilizan el servidor A como servidor de ficheros y los de producción utilizan el servidor B. Se Se utiliza una red Ethernet para conectar ambos departamentos y se ha detectado que la alta utilización del enlace está ralentizando el funcionamiento de la red. Si los usuarios de la editorial pudieran agregarse en un segmento de red mientras que los usuarios de producción se localizaran en otro se podrían conectar ambos segmentos mediante un bridge. Sólo se utilizará el bridge para encaminar tráfico de red destinado a interfaces que se encuentren en el otro lado del bridge, reduciendo de esta forma la congestión en cada nuevo segmento. - Cortafuegos de Filtrado/Conformación de Tráfico + <title>Cortafuegos de filtrado/conformación de tráfico firewall network address translation La segunda situación típica se produce cuando se necesita un cortafuegos pero no la Traducción de Direcciones de Red (NAT). A continuación se muestra un ejemplo. Una pequeña compañía se comunica con su ISP utilizando DSL o ISDN. Dicha compañía posee 13 13 direcciones IP globalmente accesibles delegadas por su ISP y tiene 10 ordenadores en funcionamiento. En esta situación un un cortafuegos basado en un router resulta difícil debido a la distribución del espacio de direccionamiento disponible (subnetting). router DSL ISDN Un cortafuegos implementado sobre un bridge se puede utilizar en el camino de bajado desde el ISP hasta las oficinas de la compañía sin necesidad de tener en cuenta ningún aspecto relacionado con la distribución de las direcciones IP. - Configuración de un <quote>Bridge</quote> + Configuración de un <quote>bridge</quote> Selección de la interfaz de red Un bridge necesita al menos dos tarjetas de red situadas en dos segmentos de red para su funcionamiento. Por desgracia no todas las interfaces de red pueden usarse para el puenteo. Consulte &man.bridge.4;, ahín encontrará más información sobre qué tarjetas puede usar. Por favor, instale y pruebe las dos tarjetas de red antes de continuar. - Cambios en la Configuración del Núcleo + Cambios en la configuración del núcleo kernel options options BRIDGE Para activar el soporte de bridging en el núcleo añada options BRIDGE al fichero de configuración del núcleo y recompile el kernel. - Soporte de Cortafuegos + Soporte de cortafuegos firewall Si se desea utilizar el bridge como un cortafuegos, se debe añadir además la opción IPFIREWALL. Lea el capílo de firewalls para obtener información general sobre cómo configurar el bridge para que actúe además como cortafuegos. Si además queremos que los paquetes que no sean IP (por ejemplo paquetes ARP) puedan atravesar el bridge deberemos añadir la opción IPFIREWALL_DEFAULT_TO_ACCEPT. Tenga en cuenta opción modifica el comportamiento del cortafuegos de tal forma que por defecto aceptará cualquier paquete. Hay que tener cuidado para asegurarse de que el comportamiento esperado del cortafuegos, que reside en el conjunto de reglas que se hayan definido, no se vea afectado por este cambio. - Soporte de Conformado de Tráfico + Soporte de conformado de tráfico Si se quiere utilizar el bridge como un conformador de tráfico, es decir, como un elemento capaz de adaptar los distintos flujos según determinados patrones, se debe añadir la opción DUMMYNET a la configuración del núcleo. Se ruega consultar &man.dummynet.4; para obtener más información al respecto. - Cómo Activar el <quote>Bridge</quote> + Cómo activar el <quote>bridge</quote> Añadir la línea: net.link.ether.bridge=1 en /etc/sysctl.conf para habilitar el soporte de bridging en tiempo de ejecución y la línea: net.link.ether.bridge_cfg=if1,if2 Para activar el bridging en las interfaces especificadas (sustituya if1 y if2 con los nombres de sus interfaces de red). Si deseamos filtrar los paquetes puenteados utilizando &man.ipfw.8;, debemos añadir también: net.link.ether.bridge_ipfw=1 En &os; 5.2-RELEASE y posteriores, se debe utilizar las siguientes líneas en lugar de las anteriores: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=if1,if2 net.link.ether.bridge.ipfw=1 - Información Adicional + Información adicional Si queremos ser capaces de conectarnos al bridge mediante &man.telnet.1; se puede asignar una dirección IP a una de las tarjetas de red del bridge. Por amplio consenso se considera una mala idea asignar más de una dirección IP al bridge. Si poseemos varios bridges en nuestra red sólamente puede existir un único camino entre cualesquiera dos máquinas de nuestra red. Técnicamente hablando esto significa que no existe soporte para gestión de enlace mediante mecanismos basados en árboles de recubrimiento mínimos (spanning tree). Un bridge puede añadir latencia a los tiempos - de respuesta del comando &man.ping.8;, especialmente cuando + de respuesta de la orden &man.ping.8;, especialmente cuando el tráfico tiene que viajar de un segmento de red al otro. Tom Rhodes Reorganizado y ampliado por Bill Swingle Escrito por NFS NFS FreeBSD soporta diversos sistemas de ficheros, uno de los cuales es el Sistema de Ficheros en Red, tambíen conocido por su acrónimo en inglés NFS. NFS permite compartir directorios y ficheros a través de la red. Los usuarios del sistema NFS pueden acceder a ficheros que se encuentran físicamente en máquinas remotas de una forma transparente, como si se tratara de ficheros locales. He aquí algunos los beneficios más destacados que NFS proporciona: Las estaciones de trabajo locales utilizan menos espacio de disco debido a que los datos se encuentran centralizados en un único lugar pero pueden ser accedidos y modificados por varios usuarios, de tal forma que no es necesario replicar la información. Los usuarios no necesitan disponer de un directorio home en cada una de las máquinas de la organización. Los directorios home pueden crearse en el servidor de NFS para posteriormente poder acceder a ellos desde cualquier máquina a través de la infraestrutura de red. También se pueden compartir a través de la red dispositivos de almacenamiento como disqueteras, CDROM y unidades ZIP. Esto puede reducir la inversión en dichos dispositivos y mejorar el aprovechamiento del hardware existente en la organización. - Cómo Funciona <acronym>NFS</acronym> + Cómo funciona <acronym>NFS</acronym> El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor. Para que el sistema funcione correctamente se deben configurar y ejecutar unos cuantos procesos. En &os; 5.X se ha reemplazado portmap por rpcbind. de esta forma para los ejemplos que vamos a comentar a continuación se recuerda que en &os; 5.X se debe reemplazar cualquier instancia de portmap por rpcbind. El servidor de NFS debe ejecutar los siguientes dæmones: NFS server portmap mountd nfsd Dæmon Descripción nfsd El dæmonNFS, que atiende peticiones de clientes NFS. mountd El dæmon de montaje de NFS, que transporta las peticiones que &man.nfsd.8; realiza. portmap El dæmon portmapper permite que los clientes NFS puedan descubrir qué puerto está utilizando el servidor de NFS. El cliente también puede ejecutar un dæmon conocido , como nfsiod. El dæmon nfsiod atiende las peticiones provinientes del servidor NFS. Este dæmon es opcional y sirve para mejorar el rendimiento pero no es necesario para el funcionamiento correcto del sistema. Se recomienda consultar &man.nfsiod.8; para obtener más información. - Configuración de <acronym>NFS</acronym> + Configuración de <acronym>NFS</acronym> NFS configuration La configuración de NFS es un proceso relativamente sencillo. Para que los procesos anteriormente descritos se ejecuten en tiempo de arranque del sistema, basta con realizar paqueñas modificaciones en /etc/rc.conf. En /etc/rc.conf del servidor de NFS se deben configurar las siguientes opciones: portmap_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd se ejecuta automáticamente cuando se activa el servidor NFS. En el cliente debemos asegurarnos de que se encuentra activada la activada la siguiente opción dentro de /etc/rc.conf: nfs_client_enable="YES" El archivo /etc/exports especifica los directorios o sistemas de ficheros que NFS exporta al exterior. Cada línea dentro de /etc/exports/ especifia un sistema de ficheros y qué máquinas tienen derechos de acceso sobre dicho sistema. Además de los derechos de acceso se pueden definir otras opciones de acceso, tales como solo lectura o lectura y escritura. Existen multitud de opciones que pueden definirse sobre un directorio exportable pero en este manual sólo se van a comentar unas pocas. Consulte &man.exports.5; para obtener una descripción más detallada. Aquí se muestran algunos ejemplos de entradas para /etc/exports: NFS export examples El siguiente ejemplo proporciona una idea de cómo exportar sistemas de ficheros, aunque los parámetros pueden diferir dependiendo de su entorno y su configuración de red. En dicho ejemplo, se exporta el directorio /cdromm a tres máquinas que se encuentran en el mismo dominio que el servidor (de ahí que no se especifique ningún nombre de dominio para cada máquina) o que pueden estar dadas de alta en /etc/hosts. En cualquier caso la opción configura el sistema de ficheros de red como sólo lectura (read-only). Con esta opción los sistemas remotos no serán capaces de realizar cambios sobre el sistema de ficheros exportados. /cdrom -ro host1 host2 host3 La siguiente línea exporta el directorio /home a tres máquinas utilizando direcciones IP. Esto resulta útil cuando disponemos de una red privada pero no disponemos de ningún servidor de DNS configurado. También se podría configurar /etc/hosts para que resolviera nombres de máquinas internos; consulte &man.hosts.5; para obtener más información al respecto. La opción permite que los subdirectorios del directorio /home tambíen se puedan utilizar como puntos de montaje. En otras palabras, esto permite que los clientes puedan trabajar sobre los subdirectorios en los que estén realmente interesados. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 La siguiente línea exporta el directorio /a de tal forma que puedan acceder a dicho directorio dos máquinas situadas en distintos dominios. La opción permite que el usuario root de la máquina cliente modifique los datos del sistema de ficheros en red como si fuera el usuario root del servidor. Si no se especifica la opción el usuario root del cliente puede no poseer los permisos necesarios para realizar modificaciones en el sistema de ficheros. /a -maproot=root host.example.com box.example.org Para que un cliente pueda acceder al sistema de ficheros exportado debe poseer permisos para ello. Debemos asegurarnos de que el cliente se encuentra listado en /etc/exports. Dentro de /etc/exports cada línea representa información de exportación de un sistema de ficheros para un determinado conjunto de máquinas. Una máquina sólo puede aparecer una vez dentro de un sistema de ficheros exportable y el archivo sólo puede tener una única entrada por defecto. Por ejemplo, si suponemos que /usr es un único sistema de ficheros la siguiente configuración de /etc/exports sería incorrecta: /usr/src client /usr/ports client Existe un sistema de ficheros, concretamente /usr, que posee dos líneas con reglas de exportación para la misma máquina, client. El formato correcto para esta situación sería el siguiente: /usr/src /usr/ports client Las propiedades de un sistemas de ficheros que se exporta al exterior deben aparecer agrupadas bajo la misma línea. Líneas que no poseen ningún cliente se tratan como si tuvieran una única máquina. Esto limita la forma en que pueden configurarse la exportaciones de sistemas de ficheros pero para la mayoría de la gente no suele ser un problema. El ejemplo que se muestra a continuación es una muestra de una lista de exportación correcta, donde /usr y /exports son sistemas de ficheros locales: # Exportar src y ports a cliente01 y cliente02, pero # solo el cliente01 tiene acceso root /usr/src /usr/ports -maproot=root cliente01 /usr/src /usr/ports cliente02 # Las maquinas cliente tienen acceso root y pueden montar todo lo que aparezca # en /exports. Cualquier sistema puede montar /exports/obj en modo # solo lectura /exports -alldirs -maproot=root cliente01 cliente02 /exports/obj -ro Se debe reiniciar el dæmon mountd siempre que se modifique el contenido del archivo /etc/exports para que los cambios surtan efecto. Esto se realiza enviando la señal HUP al proceso mountd: &prompt.root; kill -HUP `cat /var/run/mountd.pid` También se puede reiniciar FreeBSD para que se cargue la nueva configuración pero este mecanismo no resulta necesario - si se ejecutan los siguientes comandos como - root, los cuales ponen el servidor de + si se ejecutan las órdenes como + root, que ponen el servidor de NFS de nuevo en funcionamiento. En el servidor de NFS: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r En el cliente de NFS: &prompt.root; nfsiod -n 4 En este punto todo debería estar preparado para poder anclar el sistema de ficheros remoto en la máquina cliente. En los siguientes ejemplos el nombre del servidor es server y el punto de montaje temporal utilizado por el cliente es client. Si se desea montar el sistema de ficheros de forma temporal o simplemente comprobar que la - configuración funciona sin problemas se puede ejecutar un - comando como el que se muestra a continuación con permisos + configuración funciona sin problemas se puede ejecutar una + orden como la que se muestra a continuación con permisos de root en la máquina cliente: NFS mounting &prompt.root; mount server:/home /mnt - Este comando ancla el directorio + Esta orden ancla el directorio /home del servidor en el directorio /mnt del cliente. Si todo funciona correctamente debería poder entrar en el directorio /mnt del cliente y ver todos los ficheros que se encuentran en el directorio /home del servidor. Si queremos anclar automáticamente un sistema de ficheros remoto cuando la máquina está arrancando se puede añadir una línea como la siguiente dentro de /etc/fstab: servidor:/home /mnt nfs rw 0 0 &man.fstab.5; comenta todas las opciones disponibles. - Usos Prácticos + Usos prácticos El protocolo NFS tiene múltiples usos prácticos. Los más típicos se enumeran a continuación: NFS uses Compartición de la unidad de CDROM entre varias máquinas. Esto resulta ser más barato y una forma más conveniente para instalar software en varias máquinas. En grandes redes puede ser más adecuado configurar un servidor central de NFS en el cual se almacenen todos los homes de los distintos usuarios. Estos directorios se pueden exportar a través de la red de tal forma que los usuarios pueden trabajar con el mismo directorio independientemente de la máquina que utilicen. Varias máquinas pueden poseer el directorio /usr/ports/distfiles compartido. De este modo cuando necesitemos instalar un port en varias máquinas, se puede acceder rápidamente a las fuentes sin necesidad de bajarlas una vez para cada máquina. Wylie Stilwell Escrito por Chern Lee Reescrito por - Anclajes Automáticos usando <application>amd</application> + Anclajes automáticos usando <application>amd</application> amd automatic mounter daemon El dæmon &man.amd.8; (the automatic mounter daemon, o dæmon de montaje automático) automáticamente ancla un sistema de ficheros remoto cuando se tiene que acceder a un fichero perteneciente a dicho sistema. Los sistemas de ficheros que permanecen inactivos durante un determinado periodo de tiempo son automáticamente desmontados por el mismo dæmon. Este dæmon proporciona una alternativa sencilla a la utilización de los montajes permanentes que normalmente se especifican a través del fichero /etc/fstab. amd trabaja actuando como un servidor servidor de NFS para los directorios /host y /net. Cuando se accede a algún fichero ubicado bajo estos directorios amd busca el punto de montaje remoto y automáticamente lo monta. El directorio /net se utiliza para anclar sistemas de ficheros remotos especificados mediante direcciones IP, mientras que el directorio /host almacena aquellos sistemas de ficheros remotos que han sido especificados mediante un nombre de máquina. amd detecta cualquier intento de acceder a un fichero dentro del directorio /host/foobar/usr y se encarga de montar el sistema de ficheros remoto (/usr) en la máquina, en caso de que no estuviera ya anclado. - Anclaje de una Exportación utilizando + <title>Anclaje de una exportación utilizando <application>amd</application> - El comando showmount muestra los + showmount muestra los puntos de montaje que posee una máquina remota. Por ejemplo para conocer los montajes de un máquina llamada foobar, se puede utilizar: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr - Como se observa en el ejemplo, el comando + Como se observa en el ejemplo, showmount muestra el directorio /usr como una exportación. Cuando se cambia el directorio actual al directorio /host/foobar/usr el dæmon amd intenta resolver el nombre foobar y automáticamente ancla el sistema de ficheros remoto. El dæmon amd se puede ejecutar a partir de los scripts de inicio, utilizando la siguiente línea del archivo de configuración /etc/rc.conf: amd_enable="YES" Además, amd soporta opciones adicionales que pueden definirse mediante la variable amd_flags. Por defecto, la variable amd_flags posee las siguientes opciones: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" El archivo /etc/amd.map define las opciones por defecto con las cuales se anclan los sistemas de ficheros remotos. El archivo /etc/amd.conf define algunas características avanzadas para el dæmon amd. Se ruega consultar las páginas del manual de &man.amd.8; y de &man.amd.conf.5; para obtener más información. John Lind Escrito por - Problemas de Integración con Otras Plataformas + Problemas de integración con otras plataformas Determinados adaptadores Ethernet para sistemas basados en el bus ISA poseen restricciones que pueden producir serios problemas de red, en particular con el protocolo NFS. Estos problemas no son específicos de FreeBSD, pero los sistemas &os; se ven afectados por ellos. El problema surge casi siempre cuando el sistema (&os;) está empotrado dentro de una red compuesta por estaciones de trabajo de alto rendimiento, como por ejemplo estaciones de Silicon Graphics y de Sun Microsystems. El montaje del sistema de ficheros remoto suele funcionar perfectamente y algunas operaciones sobre el el sistema de ficheros pueden tener é,xito pero de repente el el servidor que no responde a las peticiones del cliente, aunque peticiones y respuestas de otros clientes funcionan con normalidad y se continúan procesando. Esto sucede en los sistemas clientes, tanto en sistemas FreeBSD como en otras estaciones de trabajo. En muchos sistemas, lo único que se puede hacer es resetear la máquina de forma abrupta, ya que el bloqueo producido por el protocolo NFS no se puede solucionar. Aunque la solución correcta consiste en obtener un adaptador Ethernet con mayor rendimiento y capacidad, todavía se puede aplicar un parche sencillo que puede llegar a permitir un funcionamiento sin problemas. Si el sistema FreeBSD actúa como servidor de NFS se puede incluír la opción cuando el ejecute una petición de montaje sobre dicho servidor. Si &os; dicho servidor. Si &os; actúa como cliente de NFS, se puede ejecutar &man.mount.8; con el parámetro . Estas opciones se pueden especificar en el /etc/fstab del cliente para que entren en funcionamiento cuando se realicen montajes automáticos y también se puede utilizar el parámetro de &man.mount.8; cuando se realicen montajes manuales. Resulta apropiado resaltar que existe un problema totalmente distinto que algunas veces se confunde con el que acabamos de describir, que aparece cuando el servidor y los clientes se encuentran en redes diferentes. Si nos encontramos en esta situación debemos asegurarnos de que nuestros routers están encaminando correctamente los paquetes UDP que genera el protocolo NFS pues en caso contrario el sistema no funcionará, independientemente de los ajustes que se realicen en el cliente o en el servidor. En los siguientes ejemplos fastws es el nombre de una estación de trabajo de altas prestaciones y freebox es el nombre de un sistema &os; con un adaptador Ethernet de bajas prestaciones. Se pretende además exportar el directorio /sfcompartido (ver &man.exports.5;) y el directorio /projecto. Tenga en cuenta que en cualquier caso puede resultar útil definir opciones adicionales a las que que se muestran en el siguiente ejemplo, como pueden ser , o . Esto dependerá de la aplicación que utilice el sistema de ficheros remoto. Ejemplos de configuración para el sistema &os; (freebox) que actúa como cliente. Configuración del archivo /etc/fstab de freebox: fastws:/sfcompartido /projecto nfs rw,-r=1024 0 0 - Comando de ejecución manual para + Orden de ejecución manual para freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sfcompartido /projecto Ejemplos de configuración para el sistema &os; que actúa como servidor. Configuración de /etc/fstab de fastws: freebox:/sfcompartido /projecto nfs rw,-w=1024 0 0 - Comando de ejecución manual para + Orden de ejecución manual para fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sfcompartido /projecto Casi cualquier adaptador Ethernet de 16 bits permite operar sin operar sin las restricciones anteriores sobre el tamaño de lectura o escritura especificado por defecto. Por si alguien estuviera interesado a continuación se muestra el error que aparece en estos casos, lo cual explica por qué decimos que el error resulta irrecuperable. NFS trabaja típicamente con un tamaño de bloque de 8 K (aunque se pueden producir fragmentos de menor tamaño). Debido a que el máximo tamaño de los paquetes Ethernet se encuentra alrededor de los 1500 bytes el bloque de NFS se trocea en varios paquetes Ethernet aunque desde el punto de vista del protocolo NFS se trata como si fuese un único paquete. Los trozos deben reensamblarse en el destino y se debe enviar una confirmación para el bloque recibido. Las estaciones de trabajo de altas prestaciones pueden soltar paquetes NFS de forma contínua uno después de otro, lo más juntos posible. Por otro lado en las tarjetas de red más pequeñas y de menor capacidad puede ocurrir que un paquete recien llegado a la tarjeta sobreescriba información perteneciente a un paquete anterior antes de que llegue a ser transmitido completamente, de tal forma que al recibirse el bloque NFS no puede ser ni reconstruido ni ni reconocido. Como resultado de este proceso la máquina tratará de enviar el mismo paquete transcurridos unos instantes de espera, pero se tratarán de enviar de nuevo los 8 K que constituyen un bloque NFS, y de esta forma se repetirá el el proceso, así hasta el infinito. Si se mantiene el tamaño del bloque por debajo del tamaño de paquete máximo de Ethernet, podemos asegurar que cualquier paquete Ethernet transporta un bloque NFS, el cual puede asentirse individualmente, evitando así la explosión de paquetes y el eventual bloqueo del sistema. Desbordamientos circulares del buffer ( overruns) pueden producirse si nos encontramos con una estación de trabajo de altas prestaciones que envía contínuamente mucho tráfico a un sistema convencional, pero con tarjetas Ethernet de buena calidad, estos desbordamientos resultan altamente improbables para el caso de los tamaños de bloque por defecto generados por el sistema NFS. Cuando se produce un desbordamiento, las unidades afectadas se retransmiten, y existe una gran probabilidad de que se reciban, se reensamblen y se confirmen. Jean-François Dockès Actualizado por Alex Dupre Reorganizado y ampliado por - Ejecución sin Disco Duro + Ejecución sin disco duro diskless workstation diskless operation Una máquina &os; se puede arrancar a través de la red y operar sin que necesite poseer ningún disco, utilizando sistemas de ficheros de un servidor de NFS. No se necesita realizar ninguna modificación al sistema, salvo configurar determinados ficheros. Este tipo de sistemas se pueden configurar fácilmente puesto que &os; dispone de todos los elementos necesarios: Existen al menos dos formas de cargar el núcleo del sistema operativo a través de la red: PXE: El sistema de &intel; conocido como Preboot Execution Environment. Se trata de una especie de arranque inteligente a partir de una memoria de sólo lectura (ROM) que se encuentra en algunas placas bases y tarjetas de red. Se puede obtener más información en &man.pxeboot.8;. El port etherboot (net/etherboot) genera código de sólo lectura (código ROM) que se puede utilizar para arrancar máquinas a través de la red. Dicho código se puede instalar en una memoria de arranque tipo PROM en algunas tarjetas de red o se puede cargar en una disquetera (o disco duro), y también en un sistema de ficheros &ms-dos; que esté en ejecución. Varias tarjetas de red soportan este mecanismo. Existe un script de ejemplo (/usr/share/examples/diskless/clone_root) que facilita la creación y el mantenimiento del sistema de ficheros raíz de la estación de trabajo en el servidor. La configuración de este script se debe retocar ligeramente pero sirve como punto de partida para comenzar rápidamente. Existen ficheros estándar de arranque bajo /etc que dan soporte al arranque de máquinas sin disco. El swapping, en caso de ser necesario, se puede realizar usando NFS y tambíen usando un disco duro local. Existen varias formas de ejecutar una estación de trabajo sin discos. En el proceso se involucran distintos elementos y la mayoría se pueden adaptar a las necesidades del usuario. A continuación se describen variaciones sobre la configuración de un sistema sin discos, haciendo incapié en la simplicidad y compatibilidad con los scripts de arranque de &os;. El sistema que vamos a describir tiene las siguientes características. Las estaciones de trabajo sin disco utilizan un sistema de ficheros raíz de sólo lectura y un sistema de ficheros compartido, también de sólo lectura, bajo /usr. El sistema de ficheros raíz es una copia del sistema raíz estandar de &os; (normalmente del sistema raíz del servidor), donde se sobreescriben algunos archivos de configuración necesarios para la ejecución sin discos y para la configuración local específica de la máquina objetivo. Las partes del sistema de ficheros raíz que tiene que tener permisos de lectura y escritura se superponen con los sistemas de ficheros &man.mfs.8; (&os; 4.X) o &man.md.4;. Cualquier cambio que se produzca en dichas partes se perderá cuando se reinicie el sistema. El núcleo se transmite y se carga utilizando etherboot o bien PXE, dependiendo del hardware y los mecanismos que se soporten. Como se ha comentado con anterioridad estos sistemas son inseguros. Se debe confinar dentro de una red protegida y el resto de las máquinas por defecto no deben confiar en estos métodos. Toda la información que se presenta en esta sección se ha probado utilizando &os; 4.9-RELEASE y 5.2.1-RELEASE. El texto se encuentra estructurado principalmente para utilización en sistemas 4.X. Se insertan notas para indicar cambios producidos en las versiones 5.X. - Conocimientos Previos + Conocimientos previos Configurar estaciones de trabajo sin discos es una operación relativamente sencilla pero en la que pueden cometerse errores. Estos errores resultan algunas veces difíciles de diagnosticar debido a razones que vamos a exponer a continuación. Por ejemplo: Diferentes opciones de tiempo de compilación pueden determinar comportamientos distintos en tiempo de ejecución. Los mensajes de error a menudo resultan crípticos o incluso no existen. Se se quieren resolver los posibles problemas que puedan surgir resulta muy útil conocer el funcionamiento conceptual del mecanismo. Para que el arranque se produzca exitosamente se deben realizar varias operaciones: La máquina necesita obtener algunos parámetros iniciales, tales como su dirección IP, el fichero ejecutable, el nombre del servidor y la ruta raíz. Esto se realiza utilizando los protocolos DHCP o BOOTP. DHCP es una extensión compatible del protocolo BOOTP y utiliza los mismos números de puertos y los mismos formatos de paquete básicos. Es posible configurar un sistema de tal forma que utilice sólamente BOOTP. En el sistema base de &os; se incluye el programa servidor &man.bootpd.8;. No obstante DHCP posee varias ventajas sobre BOOTP (archivos de configuración más limpios, posibilidad de ejecutar PXE, junto con otras características que no se relacionan directamente con el tema que estamos tratando tratando) por lo que principalmente se va a describir la configuración de DHCP, proporcionando ejemplos equivalentes en &man.bootpd.8; siempre que sea posible. La configuración de ejemplo se basa en el paquete software de ISC DHCP (en el servidor de prueba se instaló la versión 3.0.1.r12). La máquina sin disco necesita transferir uno o varios programas a la memoria local. Para ello se usa TFTP o bien NFS. La elección entre ambos se produce mediante la configuración de la compilación que se produce en varios lugares. Una fuente de error típica aparece cuando se especifican ficheros con el protocolo incorrecto: TFTP normalmente transfiere todos los ficheros desde un único directorio del servidor, de modo que espera nombres de ficheros relativos a dicho directorio. Por otro lado NFS necesita recibir rutas de fichero absolutas. El kernel y los programas de arranque intermedios deben ser inicializados y ejecutados. Existen diferencias importantes en este área: PXE carga &man.pxeboot.8;, una versión modificada de la tercera fase del cargador de arranque de &os;. &man.loader.8; obtiene la mayoría de los parámetros necesarios para arrancar el sistema y los deposita en variables de entorno del kernel antes de tranferir el control. En este caso es posible utilizar un un núcleo GENERIC . etherboot carga directamente el directamente el núcleo con menos trabajo previo que el método anterior. Para ello se debe compilar un núcleo con ciertas opciones. PXE y etherboot funcionan muy bien en los sistemas 4.X. Dado que los núcleos de los sistemas 5.X permiten que el &man.loader.8; realice más tareas, se prefiere usar PXE. Si su BIOS y su tarjeta de red soportan PXE lo normal es utilizarlo. No obstante se puede arrancar un sistema 5.X utilizando etherboot. Para acabar la tarea la máquina necesita acceder al sistema de ficheros. En todos los casos se utiliza NFS. No olvide consultar &man.diskless.8;. - Instrucciones de Configuración + Instrucciones de configuración - Configuración Utilizando <application>ISC + <title>Configuración utilizando <application>ISC DHCP</application> DHCP diskless operation El servidor ISC DHCP puede responder tanto a peticiones de BOOTP como a peticiones de DHCP. ISC DHCP no forma parte de la versión 4.9 de &os; por lo que se debe instalar el port net/isc-dhcp3-server o el paquete correspondiente. Por favor, consulte para obtener más información sobre los ports y los paquetes. Una vez que ISC DHCP se encuentra instalado necesita un fichero de configuración para poder ejecutarse /usr/local/etc/dhcpd.conf). A continuación se muestra un ejemplo comentado, donde la máquina margaux utiliza etherboot y la máquina corbieres utiliza PXE: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Esta opción indica a dhcpd que envíe el valor que se encuentra en las declaraciones de host como el nombre de máquina para la máquina sin disco. Otra forma de hacer esto sería añadiendo una opción option host-name margaux dentro de las declaraciones de máquina. La directiva next-server selecciona el servidor de TFTP o de NFS que se debe utilizar para cargar el núcleo o el fichero cargador del núcleo (por defecto se utiliza la misma máquina que actúa como servidor de DHCP). La directiva filename define el archivo que etherboot o PXE cargará en el siguiente paso de ejecución. Debe especificarse de acuerdo con el método de transferencia seleccionado. Etherboot se puede compilar para que use NFS o TFTP. El sistema &os; se configura por defecto para NFS. PXE utiliza TFTP por lo que se utiliza una ruta relativa para especificar el nombre del fichero (esto puede depender de la configuración del servidor de TFTP pero suele ser lo normal). Además PXE no carga el núcleo, lo hace pxeboot. Existen otras posibilidades interesantes, como cargar pxeboot desde el directorio /boot de una unidad de CD-ROM de &os; (ya que &man.pxeboot.8; puede cargar un núcleo GENERIC surge la posibilidad de utilizar PXE para arrancar desde una unidad de CD-ROM remota). La opción root-path define la ruta para el sistema de ficheros raíz utilizando la notación típica de NFS. Cuando se utiliza PXE, es posible dejar la dirección IP siempre y cuando no se active la opción del núcleo de BOOTP. El servidor NFS será en este caso el mismo que el servidor de TFTP. Configuración utilizando BOOTP BOOTP diskless operation A continuación se muestra la configuración equivalente utilizando bootpd (reducida a un único cliente). Esta configuración se debe situar en /etc/bootptab. Por favor, recuerde que etherboot se debe compilar con la opción específica de NO_DHCP_SUPPORT para que pueda utilizar BOOTP y que PXE requiere DHCP. La única ventaja obvia de bootpd es que se encuentra disponible en el sistema base. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 - Preparación de un Programa de Arranque con + <title>Preparación de un programa de arranque con <application>Etherboot</application> Etherboot La página web de Etherboot contiene una amplia documentación enfocada principalmente a los sistemas Linux pero en cualquier caso contiene información que puede resultar útil. En los siguientes párrafos se describe brevemente como se puede utilizar etherboot en un sistema &os;. Lo primero es instalar el port o paquete net/etherboot. El port de etherboot está en /usr/ports/net/etherboot. Si el árbol de ports está instalado en el sistema basta con ejecutar make en dicho directorio. Por favor, lea para saber más sobre los ports y los paquetes. Se puede modificar la configuración de etherboot (por ejemplo, para que use TFTP en lugar de NFS) editando el fichero Config que se encuentra en el directorio fuente de etherboot. Para nuestros propósitos se utilizará un disquete de arranque. Para utilizar otros métodos (PROM o un programa &ms-dos;) por favor consulte la documentación de etherboot. Para crear un disco de arranque se debe insertar un disco en la unidad de disquetes de la máquina donde se ha instalado etherboot, cambiar al directorio src dentro del árbol de directorios de etherboot y teclear: &prompt.root; gmake bin32/tipo_de_dispositivo.fd0 tipo_de_dispositivo depende del tipo de tarjeta Ethernet que se encuentre instalada en la estación de trabajo sin disco. Consulte el fichero NIC en el mismo directorio para determinar cúal es el tipo_de_dispositivo que debe usted usar. - Arrancar con <acronym>PXE</acronym> + Arranque con <acronym>PXE</acronym> Por defecto el cargador &man.pxeboot.8; carga, valga la redundancia, el kernel vía NFS. El El cargador se puede compilar para que utilice TFTP en lugar de NFS especificando la opción LOADER_TFTP_SUPPORT dentro de /etc/make.conf. Observe los comentarios de /etc/defaults/make.conf (o de /usr/share/examples/etc/make.conf para sistemas 5.X) para saber más detalles. Existen otras dos opciones de make.conf no documentadas que pueden ser útiles para arrancar una máquina sin disco a través del puerto serie: BOOT_PXELDR_PROBE_KEYBOARD y BOOT_PXELDR_ALWAYS_SERIAL (esta última sólo existe en &os; 5.X). Para utilizar PXE cuando arranca la máquina normalmente el usuario tiene que seleccionar la opción Boot from network dentro del menú de opciones de la BIOS o pulsar un tecla de función cuando la máquina se está inicializando. - Configuración de Servidores de + <title>Configuración de servidores de <acronym>TFTP</acronym> y de <acronym>NFS</acronym> TFTP diskless operation NFS diskless operation Si PXE o etherboot se encuentran configurados para utilizar TFTP se necesita activar tftpd en el servidor de ficheros: Crear un directorio desde el cual el dæmon tftpd servirá los ficheros, por ejemplo /tftpboot. Añadir la siguiente línea a /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot Parece que al menos algunas versiones de PXE utilizan la versión TCP de TFTP. En este caso se puede añadir una segunda línea, donde se reemplace dgram udp por stream tcp. Indicar a inetd que vuelva a leer su fichero de configuración: &prompt.root; kill -HUP `cat /var/run/inetd.pid` Se puede situar el directorio tftpboot en cualquier parte del servidor. Debe asegurarse de que la localización se encuentra correctamente configurada tanto en inetd.conf como en dhcpd.conf. En todos los casos también resulta necesario activar el sistema de NFS y exportar los sistemas de ficheros adecuados, todo ello en el servidor de NFS. Añadir lo siguiente a /etc/rc.conf: nfs_server_enable="YES" Exportar el sistema de ficheros donde el directorio raíz sin disco se encuentra localizado añadiendo lo siguiente a /etc/exports (ajuste el punto de montaje de la unidad y sustituya margaux corbieres por el nombre de las estaciones de trabajo sin disco, según corresponda): /data/misc -alldirs -ro margaux corbieres Indicar a mountd que vuelva a leer su archivo de configuración. Si en un primer paso se ha configurado la activación automática del sistema de NFS en /etc/rc.conf lo mejor es reiniciar para que los cambios surtan efecto. &prompt.root; kill -HUP `cat /var/run/mountd.pid` - Construcción de un Núcleo Sin - Disco + Construcción de un kernel sin + disco diskless operation kernel configuration Si se utiliza etherboot, se necesita crear un archivo de configuración para el kernel de la máquina sin disco que posea las siguientes opciones (además de las opciones del núcleo habituales): options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info Puede resultar interesante utilizar además BOOTP_NFSV3, BOOT_COMPAT y BOOTP_WIRED_TO (consultar LINT en 4.X o NOTES en sistemas 5.X). Los nombres de estas opciones son nombres históricos y ligeramente confusos ya que permiten un uso indistinto tanto de DHCP como de BOOTP dentro del núcleo (también resulta posible forzar la utilización única de o bien BOOTP o bien de DHCP). Contruir el núcleo (vea ) y copiarlo al lugar especificado en el archivo dhcpd.conf. Cuando se utiliza PXE, la construcción del núcleo con las opciones anteriores no resulta ser algo estrictamente necesario (aunque se recomienda). Activar dichas opciones provoca un mayor tráfico de peticiones de DHCP durante el arranque del núcleo, lo que puede dar lugar a pequeñas inconsistencias entre los nuevos valores y los los valores recuperados por &man.pxeboot.8; en casos muy específicos. La ventaja de utilizarlas consiste en que como un efecto colateral se configurará el nombre de la máquina. De otro modo tendríamos que configurar dicho nombre mediante otro método por ejemplo mediante la configuración específica de la máquina cliente a través del archivo rc.conf. Para que el núcleo se pueda cargar sin problemas con etherboot en sistemas 5.X dicho núcleo tiene que tener compilado el soporte para device hints. Para ello normalmente se especifica la siguiente opción dentro del fichero de configuración del núcleo (consulte los comentarios del fichero NOTES): hints "GENERIC.hints" - Preparación del Sistema de Ficheros - Raíz + Preparación del sistema de ficheros + raíz root file system diskless operation Se debe crear un sistema de ficheros raíz en las estaciones de trabajo sin disco, concretamente en la localización especificada por root-path dentro de dhcpd.conf. Las siguientes secciones describen dos formas de hacer esto. Utilización del <quote>script</quote> <filename>clone_root</filename> Este es el modo más rápido de crear un sistema de ficheros raíz, pero actulamente sólo se encuentra soportado en &os; 4.X. El script de shell se encuentra en /usr/share/examples/diskless/clone_root y debe ser configurado al menos para ajustar el lugar donde se construirá el sistema de ficheros (concretamente la variable DEST). Consulte los comentarios que se encuentran al comienzo del script para conocer cuales son las instrucciones que debe seguir. Allí se explica cómo se construye el sistema de ficheros base y como determinados ficheros se pueden sobreescribir de manera selectiva por versiones específicas para funcionar sin discos, para toda una subred o para una máquina individual. También allí se muestran ejemplos de los ficheros /etc/fstab y /etc/rc.conf para máquinas sin disco. Los archivos README que se encuentran dentro de /usr/share/examples/diskless contienen mucha información de base, que junto con el resto de ejemplos dentro del directorio diskless sirven para documentar un método de configuración distinto del que se utiliza en clone_root y en los scripts del sistema de /etc, que resultan ser un tanto confusos. No obstante se pueden utilizar a modo de referencia, excepto si se prefiere utilizar el método que se describe en ellos, en cuyo caso se necesitará modificar y adaptar los scripts de forma adecuada. - Utilización del Procedimiento Estándar de + <title>Utilización del procedimiento estándar de <command>make world</command> Este método se puede utilizar tanto en &os; 4.X o 5.X y se instalará un sistema completamente nuevo (no sólo el sistema de ficheros raíz) dentro de DESTDIR. Basta con ejecutar el siguiente script: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make world && make kernel cd /usr/src/etc; make distribution Una vez ejecutado puede ser necesario ajustar los ficheros /etc/rc.conf y /etc/fstab que se encuentran en DESTDIR de acuerdo con nuestras necesidades. - Configuración de la Partición de - Intercambio + Configuración de la partición de + intercambio En caso de ser necesario se puede acceder a un fichero de intercambio (swap) a través del sistema NFS. Uno de los métodos típicamente utilizados para realizar esta tarea ha sido retirado de la distribución 5.X. - <acronym>NFS</acronym> Swap en sistemas &os; 4.X + <acronym>NFS</acronym> swap en sistemas &os; 4.X La ubicación del fichero de intercambio y su tamaño se puede especificar con las opciones &os;-specific 128 y 129 de BOOTP/DHCP. A continuación se muestran varios ejemplos de ficheros de de configuración para ISC DHCP 3.0 o bootpd: Añadir las siguientes líneas al fichero dhcpd.conf: # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } swap-path es la ruta al directorio donde se instalarán los archivos de intercambio. Cada Cada fichero se denomina swap.direccion-ip-del-cliente. Versiones más antiguas de dhcpd usaban una sintáxis del estilo de option option-128 "..., lo cual ya no está soportado. /etc/bootptab normalmente utiliza la siguiente sintaxis: T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00 El tamaño del fichero dedicado a intercambio se debe expresar en /etc/bootptab en formato hexadecimal. En el servidor de ficheros NFS donde va a residir el fichero de swap se debe(n) crear dicho(s) fichero(s) &prompt.root; mkdir /volumenintercambiored/intercambiored &prompt.root; cd /volumenintercambiored/intercambiored &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 &prompt.root; chmod 0600 swap.192.168.4.6 192.168.4.6 es la dirección IP del cliente sin disco. En el servidor NFS añadir a /etc/exports la siguiente línea: /volumenintercambiored -maproot=0:10 -alldirs margaux corbieres A continuación indicar a mountd que vuelva a leer el fichero /etc/exports como se ha indicado anteriormente. - <acronym>NFS</acronym> Swap en &os 5.X + <acronym>NFS</acronym> swap en &os 5.X El núcleo no soporta la activación del intercambio a través de NFS en tiempo de arranque. De esta forma la swap se debe activar mediante los scripts montando un sistema de ficheros de lectura-escritura y creando y activando el fichero de intercambio. Para crear un fichero de intercambio de un determinado tamaño se puede ejecutar lo siguiente: &prompt.root; dd if=/dev/zero of=/ruta/al/fichero/de/intercambio bs=1k count=1 oseek=100000 Para activar el intercambio se tiene que añadir la siguiente línea al fichero de configuración rc.conf: swapfile=/ruta/al/fichero/de/intercambio - Cuestiones Variadas + Varios Ejecución con un <filename>/usr</filename> de sólo lectura diskless operation /usr read-only Si la estación de trabajo sin disco se configura para utilizar el sistema X-Window se tiene que ajustar el fichero de configuración de xdm debido a que dicho fichero sitúa por defecto el fichero de logs de errores en el directorio /usr. - Utilización de un Servidor No-&os; + Uso de un servidor no-&os; Cuando el servidor del sistema de ficheros raíz no ejecuta &os; se tiene que crear un sistema de ficheros raíz sobre una máquina &os; para después - copiarlo al servidor original mediante los comandos + copiarlo al servidor original mediante las órdenes tar o cpio. En esta situación algunas veces surgen varios problemas relacionados con los dispositivos especiales que se encuentran en el directorio /dev debido a los diferentes tamaños de los enteros mayor/menor. Una solución para este problema consiste en exportar un directorio del servidor no-&os;, montar este directorio en la máquina &os; anterior y ejecutar MAKEDEV en dicha máquina para crear las entradas de dispositivo correctas (&os; 5.0 y posteriores utilizan &man.devfs.5; para ubicar nodos de dispositivos de forma transparente para el usuario de tal modo que la ejecución de MAKEDEV en estos sistemas no sirve para nada). RDSI RDSI la página de RDSI de Dan Kegel constituye un recurso de información bastante bueno sobre la tecnología RDSI (ISDN en inglés) y sobre el hardware relacionado. A continuación se comenta un esquema rápido sobre RDSI: Si usted vive en Europa le puede resultar útil leer la sección sobre tarjetas RDSI. Si se prevee utilizar RDSI principalmente para conectarse a Internet a través de un Proveedor de Servicios utilizando un mecanismo de marcación automática no dedicado (dial-up), se puede echar un vistazo a los Adaptadores de Terminal. Dichos adaptadores proporciona la mayor flexibilidad y garantiza los mínimos problemas en caso de cambio de cambio de proveedor. Si estamos conectados a dos LAN o conectando a Internet con una conexión RDSI dedicada puede ser interesante considerar la opción de usar un router/bridge único. El coste es un factor importante a la hora de determinar qué solución se debe escoger. Las siguientes opciones se encuentran ordenadas desde las más baratas hasta las más caras. Hellmuth Michaelis Escrito por Tarjetas RDSI ISDN cards La implementación de RDSI que posee &os; soporta sólamente el estandar DSS1/Q.931 (también conocido como Euro-RDSI) utilizando tarjetas pasivas. A partir de &os; 4.4 se soportan también algunas tarjetas activas usando firmware que además soporta otros protocolos de señalización; esto también sucede con la primera tarjeta RDSI de acceso primario (PRI) soportada. El software isdn4bsd permite conectar con otras pasarelas RDSI utilizando IP sobre HDLC o bien PPP PPP síncrono: ambos mediante el uso del PPP del núcleo con isppp, una versión modificada del controlador &man.sppp.4; o mediante la utilización del PPP de entorno de usuario, &man.ppp.8;. Si se utiliza &man.ppp.8; de entorno de usuario se pueden agrupar dos o mas canales B de RDSI (channel bonding). Existe también software que permite a una máquina responder a llamadas de teléfono y algunas cosas más como un modem de 300 baudios. Cada vez se soportan más tarjetas RDSI bajo &os; y los informes existentes muestra que &os; se utiliza con dichas tarjetas de forma satisfactoria en toda Europa y también en otras partes del mundo. Las tarjetas RDSI pasivas soportadas en &os; son principalmente las que poseen el chip Infineon (antiguamente Siemens) ISAC/HSCX/IPAC. También las tarjetas RDSI con los chips de Cologne (en bus ISA exclusivamente), tarjetas PCI con el chip Winbond W6692, algunas tarjetas con combinaciones de los chips Tiger 300/320/ISAC y también algunas tarjetas basadas en chips propietarios como las AVM Fritz! PCI V.1.0 y AVM Fritz! PnP. Actualmente las tarjetas RDSI activas soportadas son las AVM B1 (ISA y PCI) BRI, y las AVM T1 PCI PRI. Se puede consultar /usr/share/examples/isdn/ para obtener documentación sobre isdn4bsd y también en la página principal de isdn4bsd, donde hay enlaces de ayuda, erratas y mucha más información útil, como por ejemplo el manual de isdn4bsd. Si se quiere añadir soporte para un protoclo RDSI distinto para una tarjeta RDSI que no se encuentra soportada o para mejorar isdn4bsd en algún aspecto por favor póngase en contacto con &a.hm;. Para realizar consultas referentes a la instalación, configuración y depuración de problemas relacionados con isdn4bsd le recomendamos recurrir a la lista de correo &a.isdn.name;. - Adaptadores de Terminal RDSI + Adaptadores de terminal RDSI Los Adaptadores de Terminal (TA), son para RDSI lo que los modems son para las líneas de teléfono convencionales. modem La mayor parte de los TAs utilizan el conjunto de instrucciones AT de los modem Hayes y se pueden utilizar en lugar del modem. Un TA opera básicamente de igual forma que un modem, diferenciándose en que las velocidades de conexión y throughput son mucho más grandes. La configuración de PPP se realiza exactamente igual que para una configuración de modem convencional. PPP La ventaja principal de utilizar un TA para conectarse a un proveedor de servicios de internet consiste en que se puede usar PPP dinámico. Ya que el espacio de direcciones de IP se está direcciones de IP se está convirtiendo cada vez convirtiendo en un recurso cada dí más limitado y escaso los proveedores ya no desean proporcionar direcciones IP estáticas a sus clientes. No obstante la mayoría de los routers standalone no son capaces de adquirir direcciones IP dinámicas. Los TAs confían completamente en el dæmon de PPP que se está ejecutando para proporcionar fiabilidad y estabilidad en la conexión. De esta forma si se tiene configurado PPP se puede migrar fácilmente de la utilización de modems analógicos al uso de RDSI. No obstante si existía algún problema con PPP antes de efectuar la migración dichos problemas persistirán en RDSI. Si se desea máxima estabilidad se puede utilizar la opción PPP, no el PPP a nivel de usuario. Se sabe que los siguientes TAs funcionan con &os;: Motorola BitSurfer y Bitsurfer Pro Adtran La mayoría de los demás TAs probablemente también funcionen puesto que los fabricantes siempre tratan de - que sus productos puedan aceptar la mayoría de los comandos - AT. + que sus productos puedan aceptar la mayoría de las + órdenes AT. El problema que existe con los TAs es que, como sucede con los modems, se necesita tener una buena tarjeta serie instalada en el sistema. Se recomienda consultar el tutorial FreeBSD Serial Hardware para obtener una comprensión detallada del funcionamiento de los dispositivos serie en &os; y para comprender las diferencias entre puertos serie síncronos y asíncronos. Un TA que se ejecuta a través de un puerto serie (asíncrono) está limitado a 115.2 Kbs, aunque la conexión RDSI sea de 128 Kbs. Para utilizar completamente el ancho de banda que RDSI proporciona, se debe conectar el TA a una tarjeta serie síncrona. No se engañe creyendo que comprando un TA interno hará desaparecer los problemas síncronos/asíncronos. Los TA internos simplemente disponen de un chip de puerto serie instalado de fábrica. Lo único que se consigue con estos dispositivos es no tener que enchufarlos a la red elétrica ahorrando así un enchufe y no tener que comprar un cable serie, pero los problemas dichos anteriormente permanecen. Una tarjeta asíncrona con un TA resulta ser al menos tan rápida como un router standalone y si &os; controla dicha tarjeta se puede adaptar más fácilmente. La elección de una tarjeta síncrona/TA versus un router standalone se trata en la mayoría de los casos de una cuestión cuasi-religiosa. Han existido diversas discusiones sobre este tema en varias listas de correo. Nosotros recomendamos que busque información en los históricos para para poder sopesar los pros y los contras que se han esgrimido en tales discusiones. - <quote>Bridges/Routers</quote> RDSI <quote>Stand-alone</quote> + <quote>bridges/routers</quote> RDSI <quote>Stand-alone</quote> ISDN stand-alone bridges/routers Los bridges o routers RDSI no son específicos de &os; o de cualquier otro sistema operativo. Para una descripción completa de la tecnología de bridge y de pasarela de red por favor consulte cualquier libro sobre redes. En el contexto de esta sección los términos router, pasarela y bridge se utilizarán indistintamente. Según va bajando el coste de los routers/bridges RDSI su utilización entre el público en general va en aumento. Un router RDSI es una pequeña caja que se conecta directamente a la red Ethernet local y que gestiona sus propias conexiones con el bridge/router remoto. Posee un software preconfigurado para comunicarse vía PPP y tambíen utilizando otros protocolos de uso común. Un router sopota una mayor tasa de paquetes (throughput) que un standalone TA, ya que utiliza una conexión RDSI síncrona de forma completa. El problema principal que surge con los routers y los bridges RDSI es que la interoperatibilidad entre fabricantes muchas veces causa problemas. Si se está planificando conectarse a un proveedor de servicios resulta conveniente discutir previamente con ellos las necesidades y requisitos. Si se tiene en mente conectar dos segmentos LAN tales como su LAN de casa y la LAN de su oficina RDSI proporciona la solución más simple y menos costosa de gestionar. Esto es así porque al comprar usted mismo el equipamiento necesario para ambos extremos de la conexión tiene usted el control sobre el enlace y puede asegurar su correcto funcionamiento. Por ejemplo, si queremos conecar una computadora casera o una sucursal de la red de oficinas con la oficinal central, se puede utilizar una configuración como la que se muestra a continuación. - Sucursal o Red Hogar + Sucursal o red doméstica 10 base 2 La red utiliza una topología basada en bus con Ethernet tipo 10 base 2 (thinnet). Se conecta, en caso de ser necesario, el router a la red cableada mediante un transceiver AUI/10BT. ---Estacion Sun | ---Sistema FreeBSD | ---Windows 95 | Router Stand-alone | ISDN BRI line 10 Base 2 Ethernet Si nuestra sucursal o red hogar está compuesta únicamente por una computadora se puede utilizar un cable cruzado de par trenzado para conectar con el router standalone de forma directa. - Oficina Central u Otra LAN + Oficina central u otra LAN 10 base T La red utiliza una topología en estrella basada en Ethernet de 10 base T (Par Trenzado). -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Stand-alone router | ISDN BRI line ISDN Network Diagram Una gran ventaja que poseen la mayoría de los routers/bridges es que pueden gestionar al mismo tiempo dos conexiones PPP independientes destinadas a dos organizaciones distintas. Esta funcionalidad no se proporciona en la mayoría de los TAs, excepto para determinados modelos (normalmente más caros) que se fabrican con dos puertos serie. No confunda esto con la agrupación de canales, MPP, etc. Esta característica puede resultar muy útil si, por ejemplo, se dispone de una conexión RDSI dedicada con la oficina y queremos introducirnos en ella pero no queremos utilizar otra línea RDSI en el trabajo. Un router situado en las instalaciones de la oficina puede gestionar una conexión de canal B dedicada (64 Kpbs) hacia internet y utilizar el otro canal B como una conexión de datos independiente. El segundo canal B se puede utilizar para marcación remota (dial-in y dial-out) o para agrupación dinámica de canales (MPP, etc) en conjunción con el primer canal B con el objetivo de obtener un mayor ancho de banda. IPX/SPX Un bridge Ethernet permite transmitir más tráfico aparte del tráfico IP. Se puede transmitir IPX/SPX o cualquier otro protocolo que se esté utilizando. Bill Swingle Escrito por Eric Ogren Ampliado por Udo Erdelhoff NIS/YP ¿Qué es esto? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, siglas de Network Information Services (Servicios de Información de Red), fué un servicio desarrollado por Sun Microsystems para centralizar la administración de sistemas &unix; (originalmente &sunos;). Actualmente se considera como un estándar de la industria; los principales sistemas tipo &unix; (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os;, etc) implementan NIS. yellow pagesNIS NIS también se conocía como el servicio de páginas amarillas pero debido a problemas legales debidos a la propiedad de marcas comerciales, Sun tuvo que cambiar el nombre. El antíguo término (Yellow Pages o yp) todavía se ve y se utiliza con frecuencia. NIS domains Se trata de un sistema cliente servidor basado en llamadas RPC que permite a un grupo de máquinas que se encuentran definidas dentro de un dominio administrativo NIS compartir un conjunto de ficheros de configuración. Esto permite al administrador de sistemas por un lado configurar clientes NIS de forma minimalista y por otro lado centralizar la gestión de los ficheros de configuración en una única ubicación (una sola máquina). Windows NT Se trata de algo similar al sistema de dominio de &windowsnt; aunque la implementación interna no se puede comparar, la funcionalidad y el servicio obtenido son similares. - Términos/Procesos que Usted Debe Conocer + Términos/procesos que debe usted conocer Existen varios conceptos y varios procesos de usuario que el usuario no versado en estos temas suele encontrarse la primera vez que se intenta implantar un servicio de NIS en &os;, tanto si se intenta configurar un servidor como si se intenta configurar un cliente: portmap Term Description NIS domainname Un servidor maestro de NIS y todos sus clientes (incluyendo a sus servidores esclavos) poseen el mismo nombre dominio NIS. Al igual que ocurre con el nombre de dominio de &windowsnt;, el nombre de dominio de NIS no tiene nada que ver con el nombre de dominio de DNS. portmap Debe ejecutarse para que se activen las llamadas a procedimientos remotos (Remote Procedure Call o RPC) que son utilizadas por NIS. Si portmap no se está ejecutando no se podrá ejecutar ni clientes ni servidores de NIS. ypbind Asocia un cliente con un servidor NIS. Primeramente se lee el nombre de dominio NIS del sistema y utilizando RPC se conecta con el servidor. ypbind es la parte central de la comunicación cliente servidor del sistema NIS; si ypbind muere en una máquina cliente, dicha máquina no podrá acceder al servidor NIS. ypserv Debe ejecutarse sólamente en los servidores NIS; se trata del proceso servidor de NIS. Si &man.ypserv.8; muere, el servidor no será capaz de responder a peticiones NIS (no obstante, si se definen servidores NIS esclavos la situación puede recuperarse). Existen algunas implementaciones de NIS (no es el caso de &os;) que no intentan conectarse con otro servidor si el servidor con otro servidor si el servidor que se estaba que se estaba utilizando muere. A menudo lo único que se puede hacer en estos casos es reiniciar el servidor (el proceso o la propia máquina) o el proceso ypbind del cliente. rpc.yppasswdd Otro proceso que sólo debe ejecutarse en el servidor maestro de NIS; se trata de un dæmon que permite a los clientes de NIS modificar las contraseñas de los usuarios. Si no se ejecuta este dæmon los usuarios tendrán que entrar en el servidor maestro de NIS para cambiar sus contraseñas allí. - ¿Cómo Funciona? + ¿Cómo funciona? Existen tres tipos de máquinas dentro del entorno NIS: los servidores maestros, los servidores esclavos y los clientes de NIS. Los servidores actúan como repositorios centrales para almacenamiento de información de configuración. Los servidores maestros mantienen una copia maestra de dicha información, mientras que los servidores esclavos mantienen copias de la información maestra por motivos de redundancia. Los servidores se encargan de transmitir la información necesaria a los clientes a petición de estos últimos. De esta forma se pueden compatir mucha información contenida en varios archivos. Los ficheros master.passwd, group y hosts normalmente se comparten a través de NIS. Siempre que un proceso en un cliente necesita información que, en caso de no utilizar NIS, se podría recuperar de ficheros locales, en este caso se envía una solicitud al servidor NIS con el que nos encontramos asociados. - Clases de Máquinas + Clases de máquinas NIS master server Servidor de NIS maestro. Este servidor, semejante a un controlador de dominio primario de &windowsnt; mantiene todos los archivos que utilizan los clientes. Los ficheros passwd, group y algunos otros se encuentran ubicados en el servidor maestro. Resulta posible configurar una máquina para que actúe como servidor NIS maestro para más de un dominio NIS. No obstante esta configuración no se va a tratar en esta introducción, en la cual asumimos un entorno NIS de tamaño relativamente pequeño. NIS slave server Servidores de NIS esclavos. Semejantes a los controladores de backup de &windowsnt;, los servidores NIS esclavos se utilizan para proporcionar redundancia en entornos de trabajo donde la disponibilidad del servicio resulta muy importante. Además se utilizan para distribuir la carga que normalmente soporta un servidor maestro: los clientes de NIS siempre se asocian con el servidor de NIS que posee mejor tiempo de respuesta, y esto y esto también incluye a los servidores de NIS esclavos. NIS client Clientes NIS. Los clientes NIS, de forma semejante a las estaciones de trabajo de &windowsnt;, se validan contra un servidor NIS (en el caso de &windowsnt; se validan contra un controlador de dominio) para acceder al sistema. - Utilización de NIS/YP + Uso de NIS/YP Esta sección trata sobre cómo configurar y poner en funcionamiento un entorno de NIS sencillo. Esta sección supone que se está utilizando utilizando &os; 3.3 o posteriores. Las instrucciones dadas aquí probablemente funcionen también en cualquier versión de &os; superior a la 3.0 pero no podemos garantizar que esto sea así. Planificación Vamos a suponer que somos el administrador de un pequeño laboratorio de una universidad. En este laboratorio, compuesto por 15 máquinas &os;, actualmente no existe ningún punto de administración centralizada; cada máquina posee sus sus propios /etc/passwd y /etc/master.passwd. Estos ficheros se encuentran sincronizados el uno con el otro mediante intervención manual; por tanto, cuando queramos añadir un usuario a nuestro laboratorio tendremos que ejecutar adduser en todas las máquinas. Claramente esta situación tiene que cambiar, de tal forma que hemos decidido crear un dominio NIS en el laboratorio usando dos máquinas como servidores NIS. La configuración de nuestro laboratorio debería ser algo parecido a lo siguiente: Nombre de máquina Dirección IP Papel ellington 10.0.0.2 servidor NIS maestro coltrane 10.0.0.3 Servidor NIS esclavo basie 10.0.0.4 Estación de trabajo del profesorado bird 10.0.0.5 máquina cliente cli[1-11] 10.0.0.[6-17] Resto de máquinas clientes Si se está configurando un esquema de NIS por primera vez es una buena idea detenerse a pensar cómo queremos implantar el sistema. Existen varias decisiones que se deben tomar independientemente del tamaño de nuestra red. Elección del nombre de dominio NIS NIS domainname Este nombre puede no ser el nombre de dominio al que estamos acostumbrados. Resulta más preciso llamarlo nombre de dominio NIS. Cuando un cliente genera peticiones de NIS que llegan a todas las máquinas (broadcast) solicitando información se incluye el nombre de dominio NIS que tiene configurado. De esta forma, varios servidores de dominios distintos situados en la misma red pueden discriminar las peticiones recibidas. Se puede pensar en el nombre de dominio NIS como un identificador de grupos de máquinas que se encuentran relacionados administrativamente de alguna forma. Algunas organizaciones eligen utilizar su nombre de dominio de Internet como nombre de dominio NIS. Esto no se recomienda ya que puede causar confusión cuando se intentan depurar problemas de red. El nombre de dominio NIS debería ser un nombre único dentro de nuestra red y resulta más útil aún si el nombre elegido puede describir de alguna forma al conjunto de máquinas que representa. Por ejemplo el departamento de arte de la empresa Acme puede utilizar como nombre de dominio acme-art. En nuestro ejemplo hemos utilizado el nombre test-domain. SunOS No obstante algunos sistemas operativos (de forma notable &sunos;) utilizan como nombres de dominio nombres de Internet. Si se poseen máquinas con esta restricción no queda más remedio que utilizar los nombres de dominio de Internet como nombres de dominio NIS. - Requisitos Físicos de los Servidores + Requisitos físicos de los servidores Existen varias cosas que debemos tener en cuenta cuando se selecciona una máquina para actuar como servidor NIS. Una de las características desafortunadas del servicio de páginas amarillas es el alto nivel de dependencia que llegan a tener los clientes respecto del servidor de NIS. Si el cliente no puede contactar con el servidor NIS normalmente la máquina se queda en un estado totalmente inutilizable. La carencia de información de usuarios y grupos provoca que las máquinas se bloqueen. Con esto en mente debemos debemos asegurarnos de escoger un servidor de NIS que no se reinicie de forma habitual o uno que no se utilice para para desarrollar. Si se dispone de una red con poca carga puede resultar aceptable colocar el servidor de NIS en una máquina donde se ejecuten otros servicios pero en todo momento se debe tener presente que si por cualquier motivo el servidor de NIS quedara inutilizable afectaría a todas las máquinas de forma negativa. Servidores NIS Las copias canónicas de toda la información que mantiene el sistema de páginas amarillas se almacenan en una única máquina denominada servidor maestro de NIS. Las bases de datos utilizadas para almacenar la información se denominan mapeos NIS. En &os; estas asociaciones o mapeos se almacenan en el directorio /var/yp/[nombrededominio] donde [nombrededominio] es el nombre del dominio de NIS que el servidor gestiona. Un único servidor NIS puede gestionar varios dominios al mismo tiempo de forma que resulta posible tener varios directorios como el anterior, uno por cada dominio soportado. Cada dominio posee su conjunto de mapeos independiente y propio. Los servidores maestro y esclavos manejan todas las peticiones de a través del dæmon ypserv. - El comando ypserv se responsabiliza de recibir + ypserv se responsabiliza de recibir peticiones de los clientes NIS. Estas peticiones se traducen a una ruta dentro del servidor. Esta ruta localiza un fichero de base de datos determinado del servidor de NIS, y finalmente ypserv se encarga de transmitir la información de dicha base de datos de vuelta al cliente que la solicitó. - Configuración de un Servidor de NIS Maestro + Configuración de un servidor de NIS maestro NIS server configuration La configuración de un servidor de NIS maestro puede resultar relativamente sencilla dependiendo de las necesidades que se tengan. &os; viene preconfigurado por defecto con un servicio NIS. Todo lo que necesitamos es añadir la siguiente línea en /etc/rc.conf y &os; se encarga del resto. nisdomainname="test-domain" Esta línea establece el nombre de dominio NIS como test-domain, cuando se realiza la configuración de la red (por ejemplo, después de un reinicio). nis_server_enable="YES" Esta variable indica a &os; que ejecute los procesos necesarios para actuar como un servidor de NIS la próxima vez que se configure el subsistema de red. nis_yppasswdd_enable="YES" Esto permite activar el dæmon rpc.yppasswdd el cual, como se ha mencionado anteriormente, permite a los usuarios realizar cambios de contraseña desde las máquinas clientes de NIS. Dependiendo de la configuración de NIS podemos necesitar añadir algunas entradas más. Consulte la sección sobre servidores NIS que también actúan como clientes, más adelante en el texto, para saber más sobre esto. - Una vez hecho esto todo lo que tenemos que hacer es ejecutar el - comando /etc/netstart como superusuario. Este - comando realiza los pasos de configuración necesarios + Una vez hecho esto todo lo que tenemos que hacer es ejecutar + /etc/netstart como superusuario. Esta + orden realiza los pasos de configuración necesarios utilizando los valores de las variables definidas en /etc/rc.conf. Inicialización de los mapeos de NIS NIS maps Las asociaciones o mapeos de NIS no son más que ficheros de base de datos. Estos ficheros se generan a partir de los ficheros de configuración contenidos en el directorio etc/ excepto para el caso del fichero etc/master.passwd. Esto es así por una buena razón ya que no suele ser buena idea propagar las contraseñas de root y de otras cuentas de administración a todos los servidores NIS del dominio. servidores NIS del dominio. Así, antes de inicializar los mapeos se debe ejecutar: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Se deben borrar todas las entradas que hagan referencia a cuentas del sistema (bin, tty, kmem, games, etc), junto con cualquier cuenta que no deseemos que se transmita a los clientes NIS (por ejemplo la cuenta de root y cualquier otra cuenta con UID 0 (el del superusuario)). Asegúrese de que /var/yp/master.passwd no se puede leer ni por - grupos ni por el resto de usuarios (modo 600). Utilice el - comando chmod en caso de necesidad. + grupos ni por el resto de usuarios (modo 600). Utilice + chmod en caso de necesidad. Tru64 UNIX Una vez hecho esto es hora de inicializar las asociaciones de NIS. &os; incluye un script denominado ypinit para realizar esta tarea (consulte su página del manual para obtener más información). Recuerde que este script se encuentra disponible en la mayoría de los sistemas &unix;, pero no en todos. En sistemas Digital UNIX/Compaq Tru64 UNIX se denomina ypsetup. Debido a que se pretende generar asociaciones para un servidor NIS maestro vamos a ejecutar ypinit con la opción . A modo de ejemplo, suponiendo que todos los pasos comentados anteriormente se han realizado con éxito, ejecute: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..salida de la generacion de mapeos..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit debería haber creado el fichero /var/yp/Makefile a partir de /var/yp/Makefile.dist. Una vez creado este archivo presupone que se está usando un entorno NIS con un único servidor utilizando sólamente máquinas &os;. Debido a que test-domain posee también un servidor NIS esclavo se debe editar el fichero var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile Se debe comentar la línea que dice: NOPUSH = "True" (si es que no se encuentra ya comentada). - Configuración de un Servidor NIS - Esclavo + Configuración de un servidor NIS + esclavo NIS slave server La configuración de un servidor NIS esclavo resulta ser incluso más sencilla que la del maestro. Basta con entrar en el servidor esclavo y editar /etc/rc.conf de foma semejante a como se realizó en el apartado anterior. La única diferencia consiste en que ahora debemos utilizar la opción cuando ejecutemos ejecutemos ypinit. A continuación del parámetro se debe especificar el nombre - del servidor maestro de modo que el comando tendría que ser + del servidor maestro de modo que la orden tendría que ser algo parecido a esto: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. En estos momentos debemos tener un nuevo directorio llamado /var/yp/test-domain. Las copias de los mapeos del servidor maestro se almacenan en dicho directorio. Es nuestra responsabilidad como administradores asegurar que dichas copias permanecen actualizadas en todo momento. La siguiente entrada en el archivo /etc/crontab del servidor esclavo se encarga de realizar esta tarea: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Estas dos líneas obligan al servidor esclavo a sincronizar los mapeos con el servidor maestro. Estas entradas no son obligatorias ya que el servidor maestro siempre intenta comunicar cualquier cambio que se produzca en sus asociaciones a todos los servidores esclavos ya que la información de, esclavos, ya que la información de, por ejemplo, contraseñas es de vital importancia para el funcionamiento de los sistemas que dependen del servidor. No obstante es una buena idea obligar a que se realicen estos cambios mediante las entradas anteriores. Esto resulta ser incluso más importante en redes de sobrecargadas donde las actualizaciones de asociaciones pueden algunas veces no llegar a realizarse de forma completa. - A continuación se ejecuta el comando + A continuación se ejecuta /etc/netstart en el servidor esclavo de igual de igual forma que se hizo con el servidor maestro; esto relanza de nuevo el servidor de NIS. Clientes NIS Un cliente de NIS establece lo que se conoce con el nombre de asociación (bind en inglés) con un servidor NIS NIS determinado utilizando el dæmon ypbind. ypbind comprueba el dominio - por defecto del sistema (especificado mediante el comando + por defecto del sistema (especificado mediante domainname) y comienza a enviar peticiones RPC a todos los elementos de la red local (broadcast). Estas peticiones especifican el nombre del dominio con el que se quiere establecer la asociación. Si esta petición alcanza una petición alcanza un servidor NIS configurado para servir dicho dominio el servidor responde a la petición e ypbind almacenará la dirección de dicho servidor. Si existen varios servidores disponibles (un maestro y varios esclavos, por ejemplo), ypbind utilizará la dirección del primero en responder. A partir de este punto el cliente dirigirá el resto de sus peticiones NIS directamente a la dirección IP almacenada. Ocasionalmente ypbind envía un ping sobre el servidor para comprobar que en efecto se encuentra funcionando. Si no se recibe contestación al ping dentro de un espacio de tiempo determinado ypbind marca el dominio como sin asociar y comienza de nuevo a inundar la red con la esperanza de localizar algún otro servidor NIS. Configuración de un cliente NIS NIS client configuration La configuración de un cliente &os; de NIS resulta ser una operación extremadamente sencilla. Editar el fichero /etc/rc.conf y añadir las siguientes líneas para establecer el nombre de dominio NIS y para que se ejecute ypbind al arranque de la red: nisdomainname="test-domain" nis_client_enable="YES" Para importar todas las entradas de contraseñas del servidor de NIS hay que eliminar todas las cuentas de usuario de /etc/master.passwd y utilizar vipw para añadir la siguiente línea al final de dicho fichero: +::::::::: Esta línea permite que cualquiera abra una cuenta en local, siempre que dicha cuenta se encuentre definida en las asociaciones de cuentas y contraseñas del servidor NIS. Existen varias formas de configurar los clientes NIS modificando esta línea. Consulte la sección sobre netgroups que se encuentra más adelante en este mismo texto. Si quiere saber más puede consultar el libro de O'Reilly Managing NFS and NIS. Se debe mantener al menos una cuenta local (por ejemplo, una cuenta que no se importe a través de NIS) en el fichero /etc/master.passwd y además dicha cuenta debería ser miembro del grupo wheel. Si algo va mal con el procedimiento descrito esta cuenta se puede utilizar para entrar en la máquina cliente de forma remota para posteriormente convertirse en superusuario e intentar solucionar el problema. Para importar todas las entradas de grupo posibles del servidor NIS se debe añadir la siguiente línea al fichero /etc/group: +:*:: Después de completar estos pasos deberímos ser capaces de ejecutar ypcat passwd y ver la asociación de contraseñas que se encuentra en el servidor de NIS Seguridad en NIS En general cualquier usuario remoto puede realizar peticiones de RPC a &man.ypserv.8; y recuperar los contenidos de las asociaciones de NIS siempre y cuando el usuario remoto conozca el nombre de dominio de NIS. Para evitar este tipo de transacciones no autorizadas, &man.ypserv.8; soporta una característica denominada securenets la cual se puede utilizar para limitar el acceso a un determinado conjunto de máquinas. En el arranque &man.ypserv.8; intenta cargar la información de securenets a partir de un fichero denominado /var/yp/securenets. Esta ruta de fichero varía dependiendo del camino especificado con la opción . Dicho fichero contiene entradas compuestas de, por un lado, un rango de red y por otro una máscara de red, separados por espacios en blanco. Las líneas que comienzan por # se consideran comentarios. A continuación se muestra un ejemplo de un fichero securenet: # admitir conexiones desde localhost -- obligatorio 127.0.0.1 255.255.255.255 # admitir conexiones desde cualquier host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # admitir conexiones desde cualquier host # between 10.0.0.0 to 10.0.15.255 # esto incluye las maquinas en el 'testlab' 10.0.0.0 255.255.240.0 Si &man.ypserv.8; recibe una petición de una dirección que coincide con alguna de las reglas especificadas en el fichero se procesa la petición. Si no existe ninguna coincidencia la petición se rechaza y se graba un mensaje de aviso. Si el archivo /var/yp/securnets no existe ypserv acepta conexiones de cualquier máquina. El programa ypserv también posee soporte para el paquete de Wietse Venema denominado tcpwrapper. Este paquete permite utilizar los ficheros de configuración de tcpwrapper para realizar control de acceso en lugar de utilizar var/yp/securenets. Aunque ambos mecanismos de control de acceso proporcionan un grado de seguridad mayor que no utilizar nada resultan vulnerables a ataques de falsificación de IPs. El cortafuegos de la red donde se implanta el servicio de NIS debería encargarse de bloquear el tráfico específico de dicho servicio. Los servidores que utilizan /var/yp/securenets pueden no prestar servicio a clientes NIS legítimos cuando se trabaja con implementaciones arcaicas de TCP/IP. Algunas de estas implementaciones ponen a cero todos los bits de máquina cuando se realizan broadcast y/o pueden fallar al especificar la máscara de red en el mismo caso, por citar algunos ejemplos. Mientras que algunos de estos problemas se pueden solucionar variando la configuración del cliente en otros casos podemos vernos obligados a prescindir del cliente en cuestión o a prescindir del fichero var/yp/securenets. Se desaconseja la utilización de var/yp/securenets en un sistema con una implementación arcaica de TCP/IP y puede suponer una pérdida de funcionalidad para grandes zonas de la red. tcpwrapper La utilización del paquete tcpwrapper incrementa la latencia del servidor NIS. El retardo adicional introducido puede ser lo suficientemente grande como para causar la expiración de ciertos temporizadores de los programas clientes, especialmente en redes muy cargadas o con servidores de NIS lentos. Si se experimentan estos síntomas en varias máquinas clientes, puede ser conveniente convertir dichas máquinas en servidores NIS esclavos y obligarlas a asociarse con ellas mismas. - Prohibir el Acceso a Determinados Usuarios + Prohibir el acceso a determinados usuarios En nuestro laboratorio de ejemplo existe una máquina denominada basie que actúa sólo como una estación de trabajo para el profesorado. No queremos sacar a esta máquina del dominio NIS pero nos damos cuenta de que el fichero passwd que se encuentra en el servidor de NIS posee cuentas tanto para profesores como para alumnos. ¿Qué podemos hacer?. Existe una forma de prohibir el acceso a determinados usuarios sobre una determinada máquina incluso aunque se encuentren dados de alta en la base de datos de NIS. Para realizar esto todo lo que debemos hacer es añadir -nombredeusuario al final del fichero /etc/master.passwd en la máquina cliente donde nombredeusuario es el nombre de usuario del usuario al que queremos prohibirle el acceso. - Esto se debe realizar a poder ser mediante el comando + Esto se debe realizar a poder ser mediante vipw ya que vipw realiza comprobaciones de seguridad sobre los cambios realizados y además se encarga de reconstruir la base de datos de contraseñas cuando se termina la edición. Por ejemplo, si quisiéramos prohibir el acceso al usuario bill a la máquina basie haríamos: basie&prompt.root; vipw [añadimos -bill al final y salimos] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Escrito por - Utilización de Netgroups + Uso de Netgroups netgroups El método descrito en la sección anterior funciona razonablemente bien si las reglas especiales se definen para un conjunto pequeño de usuarios y/o máquinas. En dominios admnistrativos grandes puede que se nos olvide prohibir el acceso a algún usuario en determinadas máquinas perdiendo de esta forma el principal beneficio de utilizar el servicio de páginas amarillas: administración centralizada. La solución creada por los desarrolladores de NIS se denomina netgroups. Su propósito se asemeja al concepto de grupos utilizado por los sistemas &unix;. La diferencia principal es la carencia de un identificador numérico y la habilidad para definir un netgroup que incluye tanto a cuentas de usuario como a otros netgroups. Los netgroups se desarrollaron para gestionar redes grandes y y complejas con cientos de usuarios y máquinas. Por un lado esto es una Cosa Buena si nos encontramos en tal situación pero por otro lado esta complejidad añadida hace que sea casi imposible de explicar a través de ejemplos sencillos. El ejemplo que va a utilizar en lo que queda de sección ilustrará este hecho. Vamos a suponer que la exitosa introducción del servicio de páginas amarillas en nuestro laboratorio ha llamado la atención de nuestros jefes. Nuestra siguiente tarea consiste en extender el dominio de NIS para que cubra otras máquinas del campus. Las tablas que se muestran a continuación contienen los nombres de los nuevos usuarios y máquinas junto con una breve descripción de ellas. Nombre del Usuario/usuarios Descripción alpha, beta Empleados normales del departamento de IT charlie, delta Los nuevos aprendices del departamento de IT echo, foxtrott, golf, ... Empleados normales able, baker, ... Los actuales internos Nombre de la Máquina(s) Descripción guerra, muerte, hambre, peste Los servidores más importantes. Sólo los empleados de IT pueden entrar en estas máquinas orgullo, avaricia, envidia, ira, lujuria, pereza Servidores de menor importancia. Todos los miembros del departamento de IT pueden entrar en ellos. uno, dos, tres, cuatro, ... Estaciones de trabajo ordinarias. Sólo los empleados actuales pueden utilizar estas máquinas. trashcan Una máquina muy vieja sin ningún dato dato crítico. Incluso los internos pueden utilizar esta máquina. Si se trata de implementar estas restricciones a nivel de usuario particular tendríamos que añadir una línea -usuario a cada fichero passwd del sistema para cada usuario que tuviera prohibido el acceso a dicho sistema. Si nos olvidamos de una sola entrada podrímos tener serios problemas. Puede ser factible realizar esta configuración cuando se instala el servicio pero no obstante el riesgo que corremos al mantener este sistema de restricciones en el día día es muy alto. Después de todo Murphy era un optimista. La gestión de esta situación mediante netgroups ofrece varias ventajas. Cada usuario no tiene que tratarse de una forma individualizada; basta con añadir un usuario a uno o más netgroups y posteriormente permitir o prohibir el acceso para todos los usuarios del netgroup. Si se añade una nueva máquina al servicio de NIS simplemente tendremos que definir restricciones de acceso para los netgroups definidos en la red. Si se añade un nuevo usuario bastará con añadir dicho usuario a un netgroup existente. Estos cambios son independientes unos de otros: se acabó la necesidad de aplicar la frase por cada combinación de usuario y máquina haga esto y esto. Si hemos planificado nuestro servicio de NIS cuidadosamente, sólo tendremos que modificar un fichero de configuración en un determinado servidor para permitir o denegar estos accesos. El primer paso consiste en la inicialización de la - asociación o mapeo del netgroup. El comando de &os; + asociación o mapeo del netgroup. La orden de &os; &man.ypinit.8; no crea este mapeo por defecto pero una vez creado será tenido en cuenta por la implementación de NIS. Para crear una asociación vacía simplemente escriba: ellington&prompt.root; vi /var/yp/netgroup y comienze a añadir contenido. En nuestro ejemplo necesitamos al menos cuatro netgroups: empleados de IT, aprendices de IT, empleados normales e internos. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. son los nombres de los netgroups. Cada conjunto delimitado por paréntesis define una o más cuentas como pertenecientes al netgroup. Existen tres campos definidos dentro de dichos de dichos grupos: El nombre de las máquinas donde los siguientes items son aplicables. Si no se especifica un nombre de máquina la entrada se aplica a todas las máquinas existentes. Si se especifica una máquina determinada entraremos en un mundo lleno de horrores y confusiones así que mejor no hacerlo. El nombre de la cuenta que pertenece al netgroup que estamos definiendo. El dominio NIS donde reside la cuenta. Se pueden importar cuentas de otros dominios NIS (en caso de que usted pertenezca al extraño grupo de personas que gestionan más de un dominio NIS. Cada uno de estos campos puede contener comodines. Consulte &man.netgroup.5; para obtener más detalles. netgroups No se deben utilizar nombres de los netgroups superiores a ocho caracteres, especialmente si las máquinas de nuestro dominio utilizan sistemas operativos variados. Los nombres son sensibles a las mayúsculas/minúsculas: se recomienda utilizar nombres en mayúsculas para distinguirlos de los usuarios o máquinas. Algunos clientes de NIS (distintos de los clientes &os;) no pueden gestionar netgroups con un gran número de entradas. Por ejemplo algunas versiones antiguas de &sunos; comienzan a presentar problemas si un netgroup contiene más de quince entradas. Se puede solventar este problema creando varios sub-netgroups de como mucho quince usuarios y finalmente creando el verdadero netgroup compuesto por los sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Se puede repetir este proceso si se tienen que definir más de 225 usuarios dentro de un único netgroup. La activación y distribución de nuestro nuevo mapeo NIS resulta sencillo: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Esto genera las tres asociaciones NIS netgroup, netgroup.byhost y netgroup.byuser. Utilice &man.ypcat.1; para comprobar si el nuevo mapeo NIS se encuentra disponible: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser - La salida del primer comando debería parecerse a los + La salida de la primera orden debería parecerse a los contenidos del fichero - /var/yp/netgroup. El segundo comando no + /var/yp/netgroup. La segunda orden no mostrará ninguna salida salvo que se hayan especificado - netgroups específicos para máquinas. El tercer comando + netgroups específicos para máquinas. La tercera orden se puede utilizar para obtener la lista de los netgroups a los que petenece un determinado usuario. La configuración del cliente es bastante simple. Para configurar el servidor guerra se debe ejecutar &man.vipw.8; y sustituír la línea +::::::::: por +@IT_EMP::::::::: Ahora sólo se importan los datos para los usuarios que se encuentren definidos en el netgroup IT_EMP; dichos datos se importan en la base de datos de contraseñas de guerra y sólo se permite el acceso a estos usuarios. Por desgraciaesta información también se aplica a la función ~ del shell y a todas las rutinas que traducen nombres de usuarios con los correspondientes identificadores - númericos de usuario (uid). En otras palabras, el comando + númericos de usuario (uid). En otras palabras, la orden cd - ~ no va a funcionar, el comando ls + ~ no va a funcionar, ls -l muestra el identificador numérico en lugar del - nombre de usuario y el comando find . -user joe + nombre de usuario y find . -user joe -print produce un error de No such user (Usuario desconocido). Para solucionar esto debemos importar todas las entradas de usuario en la máquina cliente NIS pero sin permitirles el acceso. Esto se puede realizar añadiendo otra línea al fichero /etc/master.passwd. Esta línea debería contener lo siguiente: +:::::::::/sbin/nologin, lo que significa que se importen todas las entradas pero que se reemplace el shell por /sbin/nologin. Se puede sustituir cualquier campo de la entrada de contraseñas especificando un valor concreto para dicho campo en el fichero local local /etc/master.passwd. Asegúrese de que la línea +:::::::::/sbin/nologin se sitúa después de +@IT_EMP:::::::::. Si esto no se cumple todas las cuentas de usuario importadas del servidor NIS poseerán /sbin/nologin como shell de acceso. Después de este cambio si se introduce un nuevo empleado en el departamento de IT basta con cambiar una asociación de NIS. Se podría aplicar una aproximación similar para los servidores menos importantes sustituyendo la cadena +::::::::: en las versiones locales del fichero /etc/master.passwd por algo parecido a esto: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Las líneas correspondientes para las estaciones de trabajo normales podrían ser: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin Y parece que todos nuestros problemas de gestión han desaparecido; hasta que unas semanas más tarde se produce un cambio en la política de gestión: el depatamento de IT comienza a alquilar interinos. Los interinos de IT pueden utilizar las estaciones de trabajo normales y los servidores menos importantes y los aprendices de IT pueden acceder a los servidores principales. No nos queda más remedio que añadir un nuevo netgroup denominado IT_INTERN y añadir los nuevos interinos de IT a este nuevo grupo y comenzar a cambiar la la configuración de cada máquina, una por una... Como dice el antiguo proverbio: Errores en la planificación centralizada conllevan grandes quebraderos de de cabeza globales. La habilidad que posee NIS para crear netgroups a partir de otros netgroups se puede utilizar para evitar la situación anterior. Una posibilidad consiste en la creación de netgroups basados en roles. Por ejemplo, se podría crear un netgroup denominado BIGSRV para definir las restricciones de acceso para los servidores importantes, otro grupo denominado USERBOX para las estaciones de trabajo... Cada uno de estos netgroups podría contener los netgroups que pueden acceder a dichas máquinas. Las nuevas entradas para nuestro mapeo NIS de netgroups sería algo así: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Este método de definir restricciones de acceso funciona razonablemente bien si podemos definir grupos de máquinas que posean restricciones semejantes. Por desgracia lo normal es que este caso resulta ser una excepción más que una regla. En la mayor parte de las ocasiones necesitaremos definir restricciones de acceso en función de máquinas individuales. Las definiciones de netgroups específicos para determinadas máquinas constituyen el segundo método que se puede utilizar para gestionar el cambio de política del ejemplo que estamos explicando. En nuestro caso el fichero /etc/master.passwd de cada máquina contiene dos líneas que comienzan por +. La primera de ellas añade un netgroup con las cuentas que pueden acceder a esa máquina, mientras que la segunda añade el resto de cuentas con shell el resto de cuentas con shell /sbin/nologin. Es una buena idea utilizar la versión todo en mayúsculas del nombre de máquina como el nombre del netgroup. En otras palabras, las líneas deberían ser como la siguiente: +@BOXNAME::::::::: +:::::::::/sbin/nologin Una vez que hemos completado esta tarea para todas las máquinas nunca más resultará necesario modificar las versiones locales de /etc/master.passwd. Los futuros cambios se pueden gestionar simplemente modificando el mapeo o asociación de NIS. A continuación se muestra un mapeo de netgroups para el escenario que se está explicando junto con algunas buenas ideas: # Definimos antes que nada los grupos de usuarios IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Ahora definimos unos pocos grupos basados en roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Y un grupo para tareas especiales # Permitimos a echo y golf acceso a nuestra maquina-anti-virus SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # netgroups basados en maquinas # Nuestros servidores principales GUERRA BIGSRV HAMBRE BIGSRV # El usuario india necesita acceso a este servidor PESTE BIGSRV (,india,test-domain) # # Este es realmente importante y necesita mas restricciones de # acceso MUERTE IT_EMP # # La maquina-anti-virus que mencionabamos mas arriba ONE SECURITY # # Restringimos una maquina a un solo usuario TWO (,hotel,test-domain) # [...otros grupos] Si estamos utilizando algun tipo de base de datos para gestionar cuentas de usuario debemos ser capaces de crear la primera parte del mapeo utilizando las herramientas proporcionadas por dicho sistema de base de datos. De este modo los nuevos usuarios tendrán automáticamente derechos de acceso sobre las máquinas. Una última, por precaución: puede no ser siempre aconsejable utilizar netgroups basados en máquinas. Si se están desplegando, por ejemplo, un par de docenas o incluso cientos de máquinas idénticas en laboratorios de estudiantes, es mejor utilizar netgroups basados en roles en lugar de netgroups basados en máquinas individuales para mantener el tamaño de la asociación NIS dentro de unos límites razonables. - Cosas Importantes para Recordar + Conceptos importantes a tener muy en cuenta Todavía quedan un par de cosas que tendremos que hacer de forma distinta a lo comentado hasta ahora en caso de encontrarnos dentro de un entorno de NIS. Cada vez que deseemos añadir un usuario a nuestro laboratorio debemos añadirlo al servidor NIS maestro únicamente y es tarea fundamental del administrador acordarse de reconstruir los mapeos NIS. Si nos olvidamos de esto el nuevo usuario será incapaz de acceder a ninguna máquina excepto al servidor NIS. Por ejemplo, si necesitáramos añadir el nuevo usuario jsmith al laboratorio tendríamos que ejecutar lo siguiente: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Se puede ejecutar también adduser jsmith en lugar de pw useradd jsmith. No introduzca las cuentas de administración dentro de los mapeos de NIS. No es buena idea propagar cuentas y contraseñas de administración a máquinas donde residen usuarios que normalmente no deberían poder acceder a dichas cuentas. Mantenga el servidor maestro y esclavo de NIS seguros y minimize el tiempo de interrupción del servicio. Si alguien fuera capaz de comprometer la integridad de estas máquinas o de apagarlas los usuarios del dominio no podrían acceder a sus cuentas en ningún sistema. Esto es la debilidad principal de cualquier sistema de administración centralizada. Si no se protegen los servidores NIS tendremos frente a nosotros a una horda de usuarios bastante enfadados. Compatibilidad con NIS v1 El servicio ypserv de &os; puede servir también a clientes NIS v1. La implementación de NIS de &os; sólo utiliza el protocolo NIS v2 aunque otras implementaciones incluyen soporte para el protocolo v1 por razones de compatibilidad con sistemas antiguos. Los dæmones ypbind suministrados con estos sistemas tratan de establecer una asociación con un servidor NIS versión 1 aunque puede que nunca la lleguen a utilizar (y pueden continuar realizando búsquedas mediante broadcast incluso cuando reciben una respuesta de un servidor versión 2). Tenga muy presente que mientras se soportan las llamadas normales de clientes v1, la versión de ypserv actualmente suministrada no gestiona peticiones de transferencia de mapeos a través de la versión 1; en consecuencia no se puede utilizar como maestro o esclavo junto con servidores de NIS antiguos que sólo soporten el protocolo v1. Por suerte quedan muy pocos servidores de este estilo en funcionamiento hoy en día. - Servidores NIS que Actúan También Como Clientes + <title>Servidores NIS que actúan también como clientes NIS Se debe tener cuidado cuando se ejecuta ypserv en un entorno multi-servidor donde las máquinas servidoras actúan también como máquinas clientes de NIS. Normalmente es una buena idea obligar a los servidores a que se asocien con ellos mismos mejor que permitirles emitir peticiones de asociación en broadcast, lo que posiblemente terminará con los servidores asociados entre sí. Se pueden producir extraños fallos si un servidor del que dependen otros deja de funcionar. Puede darse que los contadores de todos los clientes expiren e intenten asociarse a otro servidor, pero el retardo puede ser considerable y los fallos todavía podrín persistir debido a que los servidores se asocian contínuamente los unos a los otros. Se puede obligar a una máquina a asociarse con un servidor en particular ejecutando ypbind con la opción . Si no se quiere ejecutar esto manualmente cada vez que se reinice el servidor NIS se puede puede añadir la siguiente línea al fichero /etc/rc.conf: nis_client_enable="YES" # ejecuta tambien el soft cliente nis_client_flags="-S NIS domain,server" Consulte &man.ypbind.8; para obtener más información. - Formatos de Contraseñas + Formatos de contraseñas NIS password formats Uno de los problemas más comunes que se encuentra la gente a la hora de implantar un servicio de NIS es la compatibilidad del formato de las contraseñas. Si nuestro servidor de NIS utiliza contraseñas cifradas mediante DES sólo podrá aceptar clientes que utilicen DES. Por ejemplo, si poseemos clientes de NIS &solaris; en nuestra red casi seguro que necesitaremos utilizar contraseñas cifradas mediante DES. Para comprobar qué formato utilizan los servidores y los clientes, se puede mirar en /etc/login.conf. Si la máquina se configura para utilizar cifrado de contraseñas mediante DES, entonces la clase por defecto debe poseer una entrada como la siguiente: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Se han omitido otras entradas] Otros posibles valores para característica de passwd_format pueden ser blf y md5 (para utilizar los algoritmos Blowfish y MD5 respectivamente). Se debe reconstruir la base de datos de acceso siempre que se modifique el fichero /etc/login.conf mediante la ejecución - del siguiente comando como root: + de la siguiente orden como root: &prompt.root; cap_mkdb /etc/login.conf El formato de las contraseñas que ya se encuentran definidas en /etc/master.passwd no se actualizará hasta que el usuario cambie su contraseña, después de que se haya reconstruido la base de datos de tipos de acceso. A continuación para asegurarse de que las contraseñas se cifran con el formato seleccionado también debemos comprobar que la variable crypt_default dentro del fichero /etc/auth.conf da preferencia al formato de contraseña elegido. Por ejemplo cuando se utilizan contraseñas cifradas con DES la entrada debe ser: crypt_default = des blf md5 Si se realizan los pasos anteriores en cada una de las máquinas clientes y servidoras de nuestro entorno NIS podemos asegurar que todas utilizan el mismo formato de contraseña dentro de nuestra red. Si se presentan problemas de validación con determinados usuarios en una determinada máquina cliente se puede empezar a investigar sobre el asunto. Recuerde: si se quiere desplegar un servicio de páginas amarillas sobre un entorno de red heterogéneo probablemente se deba utilizar DES en todos los sistemas puesto que DES es el mínimo común denominador. Greg Sutter Escrito por DHCP ¿Qué es DHCP? Dynamic Host Configuration Protocol DHCP Internet Software Consortium (ISC) DHCP, el Protocolo de Configuración Dinamica de Máquinas (Dynamic Host Configuration Protocol), especifica un método para configurar dinámicamente los parámetros de red necesarios para que un sistema pueda comunicarse efectivamente. &os; utiliza la implementación de DHCP proporcionada por el Internet Software Consortium (ISC) de tal forma que toda la información relativa a la configuración de DHCP se basa en la distribución proporcionada por el ISC. - Qué Temas Trata Esta Seccións + Contenido de esta seccións Esta sección describe tanto los componentes de la parte servidora como los componentes de la parte cliente del sistema DHCP del ISC. El programa cliente, denominado forma parte por defecto de los sistemas &os; y el programa servidor se puede instalar a partir del port net/isc-dhcp3-server. Las principales fuentes de información son las páginas de manual &man.dhclient.8;, &man.dhcp-options.5; y &man.dhclient.conf.5; junto con las referencias que se muestran a continuación en esta misma sección. - Cómo Funciona + Cómo funciona UDP Cuando el cliente de DHCP, dhclient, se ejecuta en una máquina cliente, valga la redundancia, comienza a enviar peticiones broadcast solicitando información de configuración. Por defecto estas peticiones se realizan contra el puerto UDP 68. El servidor responde a través del puerto UDP 67 proporcionando al cliente una dirección IP junto con otros parámetros relevantes para el correcto funcionamiento del sistema en la red, tales como la máscara de red, el router por defecto y los servidores de DNS. Toda esta información se presta y es válida sólo durante un determinado período de tiempo (configurado por el administrador del servidor de DHCP). De esta forma direcciones IP asignadas a clientes que ya no se encuentran conectados a la red pueden ser reutilizadas al pasar determinado periodo de tiempo. Los clientes de DHCP pueden obtener una gran cantidad de información del servidor. Se puede encontrar una lista completa en &man.dhcp-options.5;. - Integración dentro de los Sistemas &os; + Integración dentro de los sistemas &os; &os; se integra totalmente con el cliente DHCP del ISC, dhclient. Este soporte se proporciona tanto en el proceso de instalación como en la instalación por defecto del sistema base obviando la necesidad de poseer un conocimiento detallado de aspectos relacionados con la configuración de redes siempre y - cuando se disponga de servicio de DHCP en la red dada. El comando + cuando se disponga de servicio de DHCP en la red dada. dhclient se incluye en todas las distribuciones de &os; desde la versión 3.2. sysinstall sysinstall soporta DHCP. Cuando se configura la interfaz de red la primera pregunta es: ¿Quiere intentar configurar el interfaz mediante DHCP?. Si se responde afirmativamente se ejecutará - el comando dhclient y si tiene éxito se + dhclient y si tiene éxito se procede con los siguientes pasos de configuración rellenandose automáticamente las variables de arranque necesarias para completar la configuración de la red. Existen dos cosas que se deben realizar de tal forma que nuestro sistema utilice la configuración de red mediante DHCP al arrancar: DHCP requirements Asegurarse de que el dispositivo bpf se encuentra compilado en el kernel. Para ello basta añadir device bpf (pseudo-device bpf en los sistemas &os; 4.X) al fichero de configuración del kernel y recompilarlo e instalarlo. Para más información sobre la construcción de núcleos consulte . El dispositivo bpf se encuentra activado por defecto dentro del fichero de configuración del núcleo (GENERIC que encontrará en su sistema &os; de forma que si no se está utilizando un fichero de configuración del núcleo específico (hecho a medida y/o por usted) no es necesario crear uno nuevo y se puede utilizar directamente GENERIC. Para aquellas personas especialmente preocupadas por la seguridad debemos advertir de que el dispositivo bpf es el dispositivo que las aplicaciones de captura de paquetes utilizan para acceder a los mismos (aunque dichas aplicaciones deben ser ejecutadas como root). DHCP requiere la presencia de bpf pero si la seguridad del sistema es más importante que la configuración automática de la red no se recomienda instalar bpf en el núcleo. Editar el fichero /etc/rc.conf para para incluir lo siguiente: ifconfig_fxp0="DHCP" Asegúrese de sustituir fxp0 con el nombre de interfaz que desea que se configure dinámicamente, como se describe en . - Si se utiliza una ubicación distinta para el comando + Si se utiliza una ubicación distinta para dhclient o si se desea añadir opciones - adicionales al comando dhclient se puede + adicionales a dhclient se puede incluir, adaptándolo a las condiciones particulares de cada usuario, lo siguiente: dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP server El servidor de DHCP (dhcpd) forma parte del port net/isc-dhcp3-server. Este port también contiene la documentación de ISC DHCP. Ficheros DHCP configuration files /etc/dhclient.conf dhclient necesita un fichero de configuración denominado /etc/dhclient.conf. Normalmente este fichero sólo contiene comentarios de forma que las opciones que se definen por defecto son razonablemente inocuas. Este fichero de configuración se describe en la página de manual de &man.dhclient.conf.5;. /sbin/dhclient dhclient se encuentra enlazado de forma estática y reside en /sbin. La página de manual de &man.dhclient.8; proporciona - más información sobre el comando + más información sobre la orden dhclient. /sbin/dhclient-script dhclient-script es el script de configuración del cliente de DHCP específico de &os;. Tiene todos los detalles en &man.dhclient-script.8; pero no necesita hacer ninguna modificación en él para que todo funcione correctamente. /var/db/dhclient.leases El cliente de DHCP mantiene una base de datos de préstamos en este fichero que se escribe de forma semejante a un log. En &man.dhclient.leases.5; puede consultar una explicación ligeramente más detallada. - Lecturas Recomendadas + Lecturas recomendadas El protocolo DHCP se describe completamente en RFC 2131. También tiene más información en dhcp.org. - Instalación y Configuración de un Servidor de + <title>Instalación y configuración de un servidor de DHCP - Qué Temas se Tratan en Esta Sección + Qué temas se tratan en esta sección Esta sección proporciona información sobre cómo configurar un sistema &os; de forma que actúe como un servidor de DHCP utilizando la implementación proporcionada por el Internet Software Consortium (ISC). La parte servidora del paquete proporcionado por el ISC no se instala por defecto en los sistemas &os; pero se puede intalar como port desde net/isc-dhcp3-server. Consulte si necesita saber más sobre la Colección de ports. - Instalación del Servidor DHCP + Instalación del servidor DHCP DHCP installation Para configurar un sistema &os; como servidor de DHCP debe asegurarse de que el dispositivo &man.bpf.4; está compilado dentro del núcleo. Para ello basta añadir device bpf ( pseudo-device bpf en &os; 4.X) al fichero de configuración del núcleo y reconstruir el mismo. Si necesita saber más sobre el proceso de compilar e instalar el núcleo consulte . El dispositivo bpf ya se encuentra activado en el fichero de configuración GENERIC del núcleo que se facilita con &os; de tal forma que no resulta imprescindible crear un núcleo a medida para ejecutar DHCP. Para aquellas personas especialmente preocupadas por la seguridad debemos advertir de que el dispositivo bpf es el dispositivo que las aplicaciones de captura de paquetes utilizan para acceder a los mismos (aunque dichas aplicaciones deben ser ejecutadas como root). DHCP requiere la presencia de bpf pero si la seguridad del sistema es más importante que la configuración automática de la red no se recomienda instalar bpf en el núcleo. El siguiente paso consiste en editar el fichero de ejemplo dhcpd.conf que se crea al instalar el port net/isc-dhcp3-server. Por defecto el fichero se llama /usr/local/etc/dhcpd.conf.sample, así que se debe copiar este fichero a /usr/local/etc/dhcpd.conf y a continuación realizar todos los cambios sobre este último. - Configuración del Servidor de DHCP + Configuración del servidor de DHCP DHCP dhcpd.conf El fichero dhcpd.conf se compone de un conjunto de declaraciones que hacen referencia a máquinas y a subredes. Esto se entenderá mejor mediante el siguiente ejemplo: option domain-name "ejemplo.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.ejemplo.com; } Esta opción especifica el dominio que se proporciona a los clientes y que dichos clientes utilizan como dominio de búsqueda por defecto. Consulte &man.resolv.conf.5; si necesita más información sobre qué significa el dominio de búsqueda. Esta opción especifica la lista de servidores de DNS (seperados por comas) que deben utilizar los clientes. La máscara de red que se proporciona a los clientes. Un cliente puede solicitar un determinado tiempo de vida para el préstamo. En caso contrario el servidor asigna un tiempo de vida por defecto mediante este valor (expresado en segundos). Este es el máximo tiempo que el servidor puede utilizar para realizar préstamos a los clientes. Si un cliente solicita un tiempo mayor como máximo se responderá con el valor aquí configurado, ignorándose la petición de tiempo del cliente. Esta opción especifica si el servidor de DHCP debe intentar actualizar el servidor de DNS cuando se acepta o se libera un préstamo. En la implementación proporcionada por el ISC esta opción es obligatoria. Esto indica qué direcciones IP se pueden utilizar para ser prestadas a los clientes que las soliciten. Las direcciones IP pertenecientes a este rango, incluyendo los extremos, se pueden entregar a los clientes. Declara cúal es la pasarela por defecto que se proporcionará a los clientes. Especifica la dirección MAC de una máquina, de tal forma que el servidor de DHCP pueda identificar a la máquina cuando realice una petición. Especifica que la máquina cliente debería obtener siempre la misma dirección IP. Recuerde que se puede utilizar un nombre de máquina para esto ya que el servidor de DHCP resolverá el nombre por sí mismo antes de devolver la información al cliente. Una vez que se ha acabado de configurar el fichero dhcpd.conf se puede proceder con la - ejecución del servidor mediante el siguiente - comando: + ejecución del servidor mediante la siguiente + orden: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Si posteriormente se necesitan realizar cambios en la configuración anterior tenga en cuenta que el envío de la señál SIGHUP a la aplicación dhcpd no provoca que se lea de nuevo la configuración como suele ocurrir en la mayoría de los dæmones. Tendrá que enviar la señal SIGTERM para parar el proceso y - posteriormente relanzar el dæmon utilizando el comando + posteriormente relanzar el dæmon utilizando la orden anterior. Ficheros DHCP configuration files /usr/local/sbin/dhcpd dhcpd se encuentra enlazado de forma estática y reside en el directorio /usr/local/sbin. La página de manual &man.dhcpd.8; que se instala con el port le proporcionará más información sobre dhcpd. /usr/local/etc/dhcpd.conf dhcpd necesita un fichero de configuración, /usr/local/etc/dhcpd.conf. Este fichero contiene toda la información relevante que se quiere proporcionar a los clientes que la soliciten, junto con información relacionada con el funcionamiento del servidor. Este fichero de configuración se describe en la página del manual &man.dhcpd.conf.5; que instala el port. /var/db/dhcpd.leases El servidor de DHCP mantiene una base de datos de préstamos o alquileres dentro de este fichero, que presenta un formato de fichero de log. La página del manual &man.dhcpd.leases.5; que se instala con el port proporciona una descripción ligeramente más larga. /usr/local/sbin/dhcrelay dhcrelay se utiliza en entornos de red avanzados donde un servidor de DHCP reenvía una petición de un cliente hacia otro servidor de DHCP que se encuentra localizado en otra subred. Si se necesita esta funcionalidad se debe instalar el port net/isc-dhcp3-server. La página del manual &man.dhcrelay.8; proporcionada por el port contiene más detalles sobre esto. Chern Lee Enviado por DNS Resumen BIND FreeBSD utiliza por defecto una versión de BIND (Berkeley Internet Name Domain) que proporciona la implementación más común del protocolo de DNS. DNS es el protocolo a través del cual los nombres de máquinas se asocian con direcciones IP y viceversa. Por ejemplo una consulta preguntando por www.FreeBSD.org recibe una respuesta con la dirección IP del servidor web del Proyecto FreeBSD, mientras que una pregunta sobre ftp.FreeBSD.org recibe como respuesta la dirección IP correspondiente al servidor de FTP. El proceso inverso sucede de una forma similar. Una pregunta relativa a una determinada dirección IP se resuelve al nombre de la máquina que la posee. No se necesita ejecutar un servidor de DNS para poder realizar consultas y búsquedas de DNS. DNS El DNS se coordina de forma distribuida a través de Internet utilizando un sistema en cierta forma complejo de servidores de nombres raíz autorizados y mediante otros servidores de nombres de menor escala que se encargan de replicar la información de dominios individuales con el objetivo de mejorar los tiempos de respuesta de búsquedas reiteradas de la misma información. Este documento hace referencia a la versión estable BIND 8.X. BIND 9.X se puede instalar a través del port net/bind9. El protocolo de DNS se encuentra definido en la RFC1034 y la RFC1035. El Internet Software Consortium (www.isc.org) se encarga de de mantener el software de BIND. Terminología Para comprender este documento se deben definir los siguientes términos: Término Definición DNS directo (Forward DNS) Asociación de nombres de máquinas con direcciones IP Origen Se refiere al dominio cubierto por un determinado fichero de zona named, BIND, servidor de nombres (name server) Nombres típicos que hacen referencia al paquete servidor de nombres de BIND de &os; resolver Resolver Un proceso del sistema que utilizan las aplicaciones para hacer preguntas al servidor de nombres. reverse DNS DNS inverso (Reverse DNS) Lo contrario de lo que realiza el DNS directo; asocia direcciones IP con nombres de máquinas root zone Zona Raíz El comienzo de la jerarquía de zonas de Internet. Todas las zonas surgen a partir de una zona raíz de forma similar a como todos los directorios de un sistema de ficheros se encuentran a partir de un directorio raíz inicial. Zona Un dominio individual, subdominio o porción del DNS que se encuentra administrado por la misma autoridad. zones examples Ejemplos de zonas: . es la zona raíz org. es una zona localizada bajo la zona raíz ejemplo.org es una zona localizada bajo la zona org. foo.ejemplo.org. es un subdominio o una zona ubicada bajo la zona ejemplo.org. 1.2.3.in-addr.arpa es una zona que referencia a a todas las direcciones IP que se encuentran dentro del espacio de direcciones de 3.2.1.*. Como se puede observar la parte más específica de una máquina aparece más a la izquierda. Por ejemplo ejemplo.org es más específico que org. y del mismo modo org. es más específico que la zona raíz. El formato de cada parte del nombre de la máquina es muy similar al formato de un sistema de ficheros: el directorio /dev se encuentra dentro del directorio raíz, y así sucesivamente. - Razones para Ejecutar un Servidor de Nombres + Razones para ejecutar un servidor de nombres Los servidores de nombres normalmente son de dos tipos: autoritarios y de cache. Se necesita un servidor de nombres autoritario cuando: uno quiere proporcionar información de DNS al resto del mundo respondiendo con información autoritaria a las consultas recibidas. un dominio, por ejemplo ejemplo.org, está registrado y se necesita añadir nombres de máquinas bajo dicho dominio. un bloque de direcciones IP necesita entradas de DNS inversas (de IP a nombre de máquina). un servidor de nombres de backup, llamado esclavo, debe responder a consultas cuando el servidor primario se encuentre caído o inaccesible. Se necesita un servidor caché cuando: un servidor de DNS local puede responder más rápidamente de lo que se haría si se tuviera que preguntar al servidor de nombres externo. se desea reducir el tráfico global de red (se ha llegado a comprobar que el tráfico de DNS supone un 5% o más del total del tráfico que circula por Internet). Cuando se pregunta por www.FreeBSD.org el resolver normalmente pregunta al servidor de nombres del ISP de nivel superior y se encarga de recibir la respuesta. Si se utiliza un servidor de DNS caché local la pregunta sólo se dirige una única vez hacia el exterior. Dicha pregunta la realiza el servidor caché. Posteriores consultas sobre el mismo nombres son respondidas directamente por este servidor. - Cómo Funciona + Cómo funciona En &os; el dæmon de BIND se denomina named por razones obvias. Fichero Descripción named El dæmon de BIND ndc El programa de control del dæmon /etc/namedb El directorio donde se almacena la información de las zonas de BIND /etc/namedb/named.conf El archivo de configuración del dæmon Los ficheros de zonas se encuentran normalmente bajo el directorio /etc/namedb y contienen la información que proporciona el servidor de nombres al resto de máquinas de Internet. Ejecución de BIND BIND starting Debido a que BIND se instala por defecto la configuración resulta ser bastante sencilla. Para asegurarnos de que el dæmon se ejecuta al inicio del sistema se deben añadir las siguientes modificaciones en /etc/rc.conf: named_enable="YES" Para arrancar el dæmon de forma manual (una vez configurado) &prompt.root; ndc start - Ficheros de Configuración + Ficheros de configuración BIND configuration files Uso de <command>make-localhost</command> Asegúrese de hacer los siguiente &prompt.root; cd /etc/namedb &prompt.root; sh make-localhost para que se cree el archivo de zona inversa /etc/namedb/localhost.rev de forma apropiada. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Consulte la página man de named(8) para más detalles. tiene // alguna vez la necesidad de configurar un servidor primario // asegúree de que entiende a la perfección los detalles peliagudos // del funcionamiento del DNS. Si hay errores, incluso triviales, // puede sufrir pérdidas de conectividad ogenerar cantidades ingentes // de tráfico inútil hacia o desde Interne options { directory "/etc/namedb"; // Además de con la láusula "forwarders" puedeobligar a su servidor // de nombres a que nunca lance búsquedas por su cuenta sino que // se las pida a sus "forwarders". Esto se hace del siguiente modo: // // forward only; // Si su proveedor de acceso tiene a su alcance un servidor DNS // escriba aquí su dirección IP y descomente la líneaPodrá usar // su caché y por lo tanto reducir el tráfico DNS de Internet. // /* forwarders { 127.0.0.1; }; */ Tal y como se dice en los comentarios del ejemplo para beneficiarnos de la caché se puede activar forwarders. En circunstancias normales un servidor de nombres busca de forma recursiva a través de Internet tratando de localizar un servidor de nombres que sea capaz de responder una determinada pregunta. Si se activa esta opción por defecto se pasa a preguntar primero al servidor de nombres especificado (servidor o servidores) pudiendo aprovecharse de la información de caché que dicho servidor tuviera disponible. Si el servidor de nivel superior al nuestro se encuentra congestionado puede merecer la pena la activación de esta característica de redirección ya que se puede disminuir la carga de tráfico que dicho servidor tiene que soportar. La dirección IP 127.0.0.1 no funciona aí. Se debe cambiar esta dirección IP por un servidor de nombres válido. /* * Si hay un cortafuegos entre usted y los servidores de * nombres que quiere consultar tendrá que descoentar la * siguiente directiva, "query-source". Las versiones * anteriores de BIND siempre hacían sus consultas a través * del puerto 53 pero BIND 8.1 utiliza por defecto un puerto no * privilegiado. */ // query-source address * port 53; /* * Si lo va a ejecutar en un "cajón de arena" (o "sandbox") * tendrá que declarar una uicación diferente para el * fichero de volcado de named. */ // dump-file "s/named_dump.db"; }; // Nota: lo siguiente será incluído en futuras versiones. /* host { any; } { topology { 127.0.0.0/8; }; }; */ // La configuración de secundarios se explica de modo secillo a // partir de aquí. // // Si activa un servidor de nombres local no olvide incluír // 127.0.0.1 en su /etc/resolv.conf para que sea ese servidor el // primero al que se consulte. // Asegúrese también de activarlo en /etc/rc.con zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { type master; file "localhost.rev"; }; // Nota: No use las direcciones IP que se muestran aquí, son falsas // y sólo se usancomo demostración y para una mejor comprensión. // // Ejemplo de entradas en la configuración de secundarios. Puede ser // conveniente convertirse en secundario al menos del dominio en cuya // zona está su dominio. Cnsulte con su administrador de red para // que le facilite la dirección IP del servidor primario. // // No olvide incluír la zona del bucle inverso (IN-ADDR.ARPA). (Son // los primeros bytes de la dirección IP correspondiente, en orden // inverso, con ".IN-ADDR.ARPA" al final.) // // Antes de configurar una zona primara asegúresede haber comprendido // completamente cómo funcionan DNS y BIND. Hay errores que no son // visibles fácilmente. La configuración de un secundario es, por // el contrario, muchísimo más sencilla. // // Nota: No se limite a copiar los ejemplos de más arriba. :-) // Utilice nombres y direcciones reales. // // ADVERTENCIA: FreeBSD ejecuta bind en un sandbok (observe los // parámeros de named (named_flags) en rc.conf). El directorio que // contiene las zonas secundarias debe tener permisos de escritura -// para bind. Le sugerimos la siguiente secuencia de comandos: +// para bind. Le sugerimos la siguiente secuencia de órdenes: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s Si quiere más información sobre cómo ejecutar BIND en un sandbox consulte Ejecución de named en un sandbox. /* zone "ejemplo.com" { type slave; file "s/ejemplo.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ Dentro del fichero named.conf se muestran ejemplos de entradas de esclavo tanto para las zonas directas como para las inversas. Para cada nueva zona administrada se debe crear una entrada de zona dentro del fichero named.conf Por ejemplo la entrada de zona más simple para el dominio ejemplo.org puede ser algo como esto: zone "ejemplo.org" { type master; file "ejemplo.org"; }; Esta zona es una zona maestra ( observe la línea de , y mantiene la información de la zona en /etc/namedb/ejemplo.org tal como se indica en la línea de . zone "ejemplo.org" { type slave; file "ejemplo.org"; }; En el caso del esclavo la información de la zona se transmite desde el servidor de nombres maestro y se almacena en el fichero especificado. Cuando el servidor maestro muere o no puede ser alcanzado el servidor de nombres esclavo puede responder a las peticiones debido a que posee la información de la zona. - Ficheros de Zona + Ficheros de zona A continuación se muestra un fichero de una zona maestra para el dominio ejemplo.org, que se encuentra ubicado en /etc/namedb/ejemplo.org: $TTL 3600 example.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.ejemplo.org. @ IN NS ns2.ejemplo.org. ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Aliases www IN CNAME @ ; MX Record @ IN MX 10 mail.ejemplo.org. Tenga muy en cuenta que todo nombre de máquina que termina en . es tratado como si fuera un nombre de máquina completo mientras que cualquier otro nombre sin el . final se trata como una referencia relativa al dominio de origen de la zona. Por ejemplo www se traduce a www + origen. En nuestro fichero de zona ficticio nuestro origen es ejemplo.org de forma que www se convierte en www.ejemplo.org El formato de un fichero de zona es el siguiente: nombrederegistro IN tipodeentrada valor DNS records Los registros de DNS que más se utilizan son: SOA Comienzo de Zona con Autoridad (Start Of zone Authority) NS Un servidor de nombres con autoridad para una una determinada zona A Una dirección IP de una máquina CNAME El nombre canónico de una máquina para definir un alias MX mail exchanger PTR Un puntero a un nombre de dominio (utilizados para definir el DNS inverso) ejemplo.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day ejemplo.org. el nomre de dominio, también el origen para el fichero de zona ns1.ejemplo.org. el servidor de nombres primario/autoritario para esta zona admin.ejemplo.org. la persona responsable de esta zona; observe que la dirección de correo electrónico aparece con la @ sustituida por un punto. (admin@ejemplo.org se escribe admin.ejemplo.org) 5 el número de serie del fichero. Este número se debe incrementar cada vez que se modifique el fichero de zona. Muchos administradores prefieren un formato expresado del siguiente modo aaaammddss. 2001041002 significa (según dicho formato) que el fichero se modificó por última vez el 04/10/2001 y se indica con los dos últimos dígitos (02) que es la segunda vez en el día que se ha modificado el fichero. El número de serie es importante ya que para avisar a los servidores de nombres esclavos de que se ha actualizado la zona. @ IN NS ns1.ejemplo.org. Esta es una entrada de tipo NS. Cada servidor de nombres que contesta de forma autoritaria a las consultas de un determinado dominio debe tener una de estas entradas. El caracter @ se sustituye por ejemplo.org., es decir, se sustituye por el origen. localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 El registro de tipo A hace referencia a nombres de máquinas . Como puede verse más arriba ns1.ejemplo.org se resuelve a 3.2.1.2. Vemos que se utiliza otra vez el origen @, que significa que ejemplo.org se resuelve a 3.2.1.30. www IN CNAME @ Los registros de nombres canónicos se utilizan normalmente como alias de máquinas. En el ejemplo www es un alias de ejemplo.org (3.2.1.30). CNAMEs se puede utilizar para proporcionar alias de nombres de máquinas, o también para proporcionar un mecanismo de vuelta cíclica (round robin) de un nombre de máquina mapeado a un determinado conjunto de máquinas intercambiables. MX record @ IN MX 10 mail.ejemplo.org. El registro MX indica qué servidores de correo se encargan de recibir correos para esta zona. mail.example.org es el nombre del servidor de correo y 10 significa la prioridad de dicho servidor. Se pueden especificar varios servidores de correo con prioridades de, por ejemplo,3, 2 y 1. Un servidor de correo que intenta entregar correo para el dominio ejemplo.org primero intentará contactar con el servidor especificado en el registro MX de mayor prioridad, después con el siguiente y así sucesivamente hasta que lo logre entregar. Para los ficheros de zona de in-addr.arpa (DNS inverso) se utiliza el mismo formato excepto que se especifican registros PTR en lugar de registros A o CNAME. $TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.ejemplo.org. admin.ejemplo.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.ejemplo.org. @ IN NS ns2.ejemplo.org. 2 IN PTR ns1.ejemplo.org. 3 IN PTR ns2.ejemplo.org. 10 IN PTR mail.ejemplo.org. 30 IN PTR ejemplo.org. Este fichero proporciona las asociaciones de direcciones IP con nombres de máquinas adecuadas para nuestro dominio ficticio. - Servidor de Nombres de Cache + Servidor de nombres de cache BIND caching name server Un servidor de nombres de tipo caché es un servidor de nombres que no es autoritario para ninguna zona. Simplemente realiza consultas por sí mismo y recuerda las respuestas para futuros usos. Para configura uno de estos servidores se configura el servidor de la forma habitual pero se omite la inclusión de zonas. - Ejecución de <application>named</application> en un <quote> + <title>Ejecución de <application>named</application> en una <quote> Sandbox</quote> BIND running in a sandbox chroot Para obtener una mayor seguridad se puede ejecutar &man.named.8; como un usuario sin privilegios y configurarlo mediante &man.chroot.8; dentro del directorio especificado como el directorio del sandbox. Esto hace que cualquier cosa que se encuentre fuera de dicho directorio resulte inaccesible para el dæmon named. En caso de que se comprometiera la seguridad de named esta restricción puede ayudar a limitar el daño sufrido. &os; dispone por defecto de un usuario y un grupo destinado a este uso: bind. Hay quien recomienda que en lugar de configurar named con chroot es mejor configurarlo dentro de &man.jail.8;. En esta sección no se va a explicar esa alternativa. Debido a que named no va a poder acceder a nada que se encuentre fuera del directorio sandbox (y esto incluye cosas tales como bibliotecas compartidas, sockets de log, etc) se debe efectuar una serie de cambios para que named pueda funcionar con normalidad. En la siguiente lista se supone que la ruta del sandbox es /etc/namedb y que no se ha modificado anteriormente dicho directorio. Por favor, ejecute los pasos que se muestran a continuación: Cree todos los directorios que named espera tener a su disposición: &prompt.root; cd /etc/namedb &prompt.root; mkdir -p bin dev etc var/tmp var/run master slave &prompt.root; chown bind:bind slave var/* named sólamente necesita escribir en estos directorios así que eso es todo lo que debemos crear. Reorganizar y crear los archivos de configuración de zona básicos: &prompt.root; cp /etc/localtime etc &prompt.root; mv named.conf etc && ln -sf etc/named.conf &prompt.root; mv named.root master &prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master &prompt.root; cat > master/named.localhost $ORIGIN localhost. $TTL 6h @ IN SOA localhost. postmaster.localhost. ( 1 ; serial 3600 ; refresh 1800 ; retry 604800 ; expiration 3600 ) ; minimum IN NS localhost. IN A 127.0.0.1 ^D Esto permite que named pueda escribir al archivo de log la hora correcta a través del &man.syslogd.8; Si está usando una versión de &os; anterior a 4.9-RELEASE se debe construir una copia estáticamente enlazada de named-xfer y copiarla dentro del directorio del sandbox: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all &prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer Despueés de instalar la versión estática de named-xfer se deben realizar algunas tareas de limpieza para evitar dejar copias de bibliotecas o de programas en nuestros ficheros de fuentes: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir En algunas ocasiones este paso puede fallar. Si es su caso ejecute lo siguiente: &prompt.root; cd /usr/src && make cleandir && make cleandir y borre su directorio /usr/obj: &prompt.root; rm -fr /usr/obj && mkdir /usr/obj Esto limpia cualquier impureza del árbol de fuentes y si se repiten los pasos anteriores todo debería funcionar. Si se está usando &os; version 4.9-RELEASE o posterior el ejecutable de named-xfer del directorio /usr/libexec ya se encuentra enlazado estáticamente y se puede utilizar &man.cp.1; para copiarlo directamente en nuestro sandbox. Cree el fichero dev/null de tal forma que named pueda verlo y pueda escribir sobre él: &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 &prompt.root; chmod 666 null Enlace simbólicamente /var/run/ndc con /etc/namedb/var/run/ndc: &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc Esto simplemente evita el tener que especificar la opción de &man.ndc.8; cada vez que se ejecute. Dado que los contenidos de /var/run se borran al inicio del sistema, si se piensa que esto puede resultar - útil, se puede añadir este comando al + útil, se puede añadir esta orden al crontab del usuario root utilizando la opción . Consulte &man.crontab.5; para saber más información sobre esto. Configure &man.syslogd.8; para que cree un socket de log adicional de tal forma que named pueda escribir sobre él. Añada -l /etc/namedb/dev/log a la variable syslogd_flags dentro del fichero /etc/rc.conf. Reorganice la ejecución de las aplicaciones named y chroot para que se ejecuten dentro del sandbox añadiendo lo siguiente al fichero/etc/rc.conf: named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" Recuerde que el fichero de configuración /etc/named.conf tiene una ruta completa que comienza en el directorio del sandbox; por ejemplo, en la línea superior el fichero que aparece es en realidad /etc/namedb/etc/named.conf. El siguiente paso consiste en editar el fichero /etc/namedb/etc/named.conf de tal forma que named pueda conocer qué zonas cargar y donde encontrarlas en disco. A continuación se muestra un ejemplo comentado (cualquier cosa que no se comenta en el ejemplo es porque resulta igual que la configuración del servidor de DNS del caso normal): options { directory "/"; named-xfer "/bin/named-xfer"; version ""; // No muestra la versiÃn de BIND query-source address * port 53; }; // ndc control socket controls { unix "/var/run/ndc" perm 0600 owner 0 group 0; }; // A partir de aquívan las zonas: zone "localhost" IN { type master; file "master/named.localhost"; allow-transfer { localhost; }; notify no; }; zone "0.0.127.in-addr.arpa" IN { type master; file "master/localhost.rev"; allow-transfer { localhost; }; notify no; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "master/localhost-v6.rev"; allow-transfer { localhost; }; notify no; }; zone "." IN { type hint; file "master/named.root"; }; zone "private.example.net" in { type master; file "master/private.example.net.db"; allow-transfer { 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" in { type slave; masters { 192.168.10.2; }; file "slave/192.168.10.db"; }; La línea que contiene directory se especifica como /, ya que todos los ficheros que named necesita se encuentran dentro de este directorio (recuerde que esto es equivalente al fichero /etc/namedb de un usuario normal. Especifica la ruta completa para el binario named-xfer binary (desde el marco de referencia de named). Esto resulta necesario ya que por defecto named se compila de tal - forma que trata de localizar el comando + forma que trata de localizar named-xfer dentro de /usr/libexec. Especifica el nombre del fichero (relativo a la línea (relativo a la línea ) directory anterior) donde named puede encontrar el fichero de zona para esta zona. Especifica el nombre del fichero (relativo a la líena directory anterior) donde named debería escribir una copia del archivo de zona para esta zona después de recuperarla exitosamente desde el servidor maestro. Este es el motivo por el que en las etapas de configuración anteriores necesitábamos cambiar la propiedad del directorio slave al grupo bind. Después de completar los pasos anteriores reinicie el servidor o reinicie &man.syslogd.8; y ejecute &man.named.8; asegurándose de que se utilicen las nuevas opciones especificadas en syslogd_flags y named_flags. En estos momentos deberíamos estar ejecutando una copia de named dentro de un sandbox. Seguridad Aunque BIND es la implementación de DNS más utilizada existe siempre el asunto relacionado con la seguridad. De vez en cuando se encuentran agujeros de seguridad y vulnerabilidades. Es una buena idea suscribirse a CERT y a freebsd-security-notifications para estar al día de los problemas de seguridad relacionados con named. Si surge un problema nunca está de más actualizar los fuentes y recompilar los ejecutables desde dichas fuentes. - Lecturas Recomendadas + Lecturas recomendadas Las páginas del manual de BIND/named: &man.ndc.8; &man.named.8; &man.named.conf.5; Página oficial de ISC Bind Preguntas más frecuentes sobre BIND Libro de O'Reilly "DNS and BIND", cuarta edición RFC1034 - Nombre de Dominio - Conceptos y Características RFC1035 - Nombres de Domninio - Implementación y Especificación Tom Hukins Escrito por NTP NTP Resumen Según pasa el tiempo el reloj de un computador está expuesto a ligeros desplazamientos. NTP (Protocolo de Hora en Red, en inglés Network Time Protocol) es un protocolo que permite asegurar la exactitud de nuestro reloj. Existen varios servicios de internet que confían y se pueden beneficiar de relojes de computadores precisos. Por ejemplo un servidor web puede recibir peticiones de un determinado fichero si ha sido modificado posteriormente a una determinada fecha u hora. - Servicios como &man.cron.8; ejecutan comandos en determinados - instantes. Si el reloj no se encuentra ajustado estos comandos pueden - ejecutarse fuera de la hora prevista. + Servicios como &man.cron.8; ejecutan órdenes en determinados + instantes. Si el reloj no se encuentra ajustado estas órdenes + pueden ejecutarse fuera de la hora prevista. NTP ntpd &os; viene con el servidor NTP &man.ntpd.8; que se puede utilizar para preguntar a otros servidores NTP, de tal forma que podemos ajustar nuestro reloj según la hora de otros servidores e incluso proporcionar servicio de hora nosotros mismos. - Elección de los Servidores de Hora Adecuados + Elección de los servidores de hora adecuados NTP choosing servers Para sincronizar nuestro reloj necesitamos comunicarnos con uno o más servidores NTP. El administrador de nuestra red o nuestro proveedor de servicios de Internet muy posiblemente hayan configurado algún servidor NTP para estos propósitos. Consulte la documentación de que disponga. Existe una lista de servidores NTP públicamente accesibles que se pueden utilizar para buscar un servidor NTP que se encuentre geográficamente próximo. Asegúrese de que conoce la política de uso de estos servidores públicos ya que en algunos casos es necesario pedir permiso al administrador antes de de poder utilizarlos, principalmente por motivos estadísticos. Le recomendamos seleccionar servidores NTP que no se encuentren conectados entre sí por si alguno de los servidores que use sea inaccesible o su reloj se averíe. &man.ntpd.8; utiliza las respuestas que recibe de otros servidores de una forma inteligente. servidores de una forma inteligente (Tiene a hacer más caso a los más fiables. - Configuración de la Máquina + Configuración de la máquina NTP configuration - Configuración Básica + Configuración básica ntpdate Si sólamente deseamos sincronizar nuestro reloj cuando se arranca la máquina se puede utilizar &man.ntpdate.8;. Esto puede ser adecuado en algunas máquinas de escritorio que se reinician frecuentemente y donde la sincronización no suele ser un objetivo prioritario pero normalmente la mayoría de las máquinas deberían ejecutar &man.ntpd.8;. La utilización de &man.ntpdate.8; en tiempo de arranque es también una buena idea incluso para las máquinas que ejecutan &man.ntpd.8;. El programa &man.ntpd.8; modifica el reloj de forma gradual, mientras que &man.ntpdate.8; ajusta directamente el reloj sin importar que tamaño tenga la diferencia de tiempo existente entre la máquina y el servidor de tiempo de referencia. Para activar &man.ntpdate.8; en tiempo de arranque, añada ntpdate_enable="YES" al fichero /etc/rc.conf. También es necesario especificar todos los servidores que deseamos utilizar para realizar el proceso de sincronización y cualquier - parámetro que deseemos pasar al comando &man.ntpdate.8; + parámetro que deseemos pasar a &man.ntpdate.8; utilizando la variable ntpdate_flags. NTP ntp.conf - Configuración General + Configuración general NTP se configura mediante el archivo /etc/ntp.conf utilizando el formato descrito en &man.ntp.conf.5;. A continuación se muestra un sencillo ejemplo: server ntplocal.ejemplo.com prefer server timeserver.ejemplo.org server ntp2a.ejemplo.net driftfile /var/db/ntp.drift La opción server especifica qué servidores se van a utilizar, especificando un servidor por línea. Si se especifica un servidor con el argumento prefer, como en ntplocal.ejemplo.com dicho servidor se prefiere sobre los demás. No obstante la respuesta de su servidor preferido se descartará si difiere sustancialmente de la respuesta recibida por parte del resto de los servidores especificados; en caso contrario sólo se tendrá en cuenta la respuesta del servidor preferido sin importar la información suministrada por el resto. El argumento prefer se utiliza normalmente en servidores NTP altamente precisos, como aquellos que poseen hardware de tiempo específico. La opción driftfile especifica qué fichero se utiliza para almacenar el desplazamiento de la fracuencia de reloj de la máquina. El programa &man.ntpd.8; utiliza este valor para automáticamente compensar el desvío que experimenta de forma natural el reloj de la máquina, permitiendo mantener una precisión acotada incluso cuando se pierde la comunicación con el resto de referencias externas. La opción driftfile especifica qué fichero se utiliza para almacenar la información sobre espuestas anteriores de servidores NTP. Este fichero contiene información útil para la implementación de NTP. No debería ser modificada por ningún otro proceso. - Control de Acceso al Servidor NTP + Control de acceso al servidor NTP Por defecto nuestro servidor de NTP puede ser accedido por cualquier máquina de Internet. La opción restrict se puede utilizar para controlar controlar qué máquinas pueden acceder al servicio. Si queremos denegar el acceso a todas las máquinas existentes basta con añadir la siguiente línea a /etc/ntp.conf: restrict default ignore Si sólo queremos permitir el acceso al servicio de hora a las máquinas de nuestra red y al menos tiempo nos queremos asegurar de que dichos clientes no pueden a su vez configurar la hora del servidor o utilizarse ellos mismos como nuevos servidores de hora basta con añadir lo siguiente en lugar de lo anterior: restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap donde 192.168.1.0 es la dirección IP de nuestra red y 255.255.255.0 es la máscara de red. /etc/ntp.conf puede contener varias opciones de tipo restrict. Para más detalles consulte la sección Soporte de Control de Acceso de &man.ntp.conf.5;. - Ejecución del Servidor de NTP + Ejecución del servidor de NTP Para asegurarnos de que el servidor de NTP se ejecuta en tiempo de arranque se debe añadir la línea xntpd_enable="YES" al fichero /etc/rc.conf. Si deseamos pasar opciones adicionales a &man.ntpd.8; se puede modificar la variable xntpd_flags del fichero /etc/rc.conf. Para ejecutar el servidor sin reiniciar la máquina ejecute ntpd junto con todos aquellos parámetros que haya especificado en la variable de arranque xntpd_flags del fichero /etc/rc.conf. Por ejemplo: &prompt.root; ntpd -p /var/run/ntpd.pid Bajo &os; 5.X se han renombrado algunas opciones del fichero /etc/rc.conf. Se debe reemplazar cualquier aparición xntpd por por ntpd. - Utilización de ntpd junto con una Conexión Temporal + <title>Utilización de ntpd junto con una conexión temporal a Internet El programa &man.ntpd.8; no necesita una conexión permanente a Internet para poder funcionar correctamente. No obstante si la conexión a Internet se encuentra configurada con marcación bajo demanda es una buena idea impedir que el tráfico de NTP lance una marcación automática o que mantenga la conexión viva. Si se utiliza el PPP de entorno de usuario se pueden utilizar las directivas filter dentro del fichero /etc/ppp/ppp.conf para evitar esto. Por ejemplo: set filter dial 0 deny udp src eq 123 # Evita que el tráfico NTP inice una llamada saliente set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 Evita que el tráficoNTP entrante mantenga abierta la conexión set filter alive 1 deny udp dst eq 123 Evita que el tráfico NTP saliente mantenga abierta la conexión set filter alive 2 permit 0/0 0/0 Para ás detalles consulte la sección PACKET FILTERING de &man.ppp.8; y los ejemplos que se encuentran en /usr/share/examples/ppp/. Algunos proveedores de acceso a Internet bloquean paquetes que utilizan números de puertos bajos impidiendo que los paquetes de vuelta alcancen nuestra máquina. - Información Adicional + Información adicional Hay documentación sobre el servidor NTP en formato HTML en /usr/share/doc/ntp/. Chern Lee Escrito por - Traducción de Direcciones de Red + Traducción de direcciones de red Overview natd El dæmon de &os; que se encarga de traducir direcciones de red, más conocido como &man.natd.8;, es un dæmon que acepta paquetes IP, modifica la dirección IP fuente de dichos paquetes y los reinyecta en el flujo de paquetes IP de salida. &man.natd.8; ejecuta este proceso modificando la dirección de origen y el puerto de tal forma que cuando se reciben paquetes de contestación &man.natd.8; es capaz de determinar el destino real y reenviar el paquete a dicho destino. Internet connection sharing IP masquerading El uso más común de NAT es para Compartir la Conexión a Internet. Configuración Debido al pequeño espacio de direccionamiento que se encuentra actualmente disponible en IPv4 y debido también al gran aumento que se está produciendo en cuanto a número de usuarios de líneas de conexión a Internet de alta velocidad como cable o DSL la gente necesita utilizar cada vez más la salida de Compartición de Conexión a Internet. La característica de poder conectar varios computadores a través de una única conexión y una única dirección IP hacen de &man.natd.8; una elección razonable. Cada vez con más frecuencia un usuario típico dispone de una máquina conectada mediante cable o DSL pero desearía utilizar dicha máquina como un router de acceso para el resto de los ordenadores de su red de área local. Para poder hacerlo la máquina (&os; por supuesto) debe configurarse para actuar como pasarela. Debe tener al menos dos tarjetas de red, una para conectarse a la red de área local y la otra para conectarse con el router de acceso a Internet. Todas las máquinas de la LAN se conectan entre sí mediante un hub o un switch. _______ __________ ________ | | | | | | | Hub |-----| Client B |-----| Router |----- Internet |_______| |__________| |________| | ____|______ | | | Cliente A | |___________| Topología de la Red Una configuración como esta se utiliza frecuentemente para compartir el acceso a Internet. Una de las máquinas de la LAN está realmente conectada a Internet. El resto de las máquinas acceden a Internet utilizando como pasarela la máquina inicial. kernel configuration Configuración Se deben añadir las siguientes opciones al fichero de configuración del núcleo: options IPFIREWALL options IPDIVERT Además, según se prefiera, se pueden añadir también las siguientes: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE Lo que viene a continuación se tiene que definir en /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" gateway_enable="YES" Configura la máquina para que actúe como router o pasarela de red. Se puede conseguir lo mismo ejecutando sysctl net.inet.ip.forwarding=1. firewall_enable="YES" Activa las reglas de cortafuegos que se encuentran definidas por defecto en /etc/rc.firewall y que entran en funcionamiento en el arranque del sistema. firewall_type="OPEN" Especifica un conjunto de reglas de cortafuegos que permite el acceso a todos los paquetes que se reciban. Consulte /etc/rc.firewall para obtener información sobre el resto de tipos de reglas que se pueden configurar. natd_interface="fxp0" Indica qué interfaz se utiliza para reenviar paquetes (la interfaz que se conecta a Internet). natd_flags="" Define cualesquiera otras opciones que se deseen proporcionar a &man.natd.8; en tiempo de arranque. Si se definen las opciones anteriores, en el arranque del sistema el fichero /etc/rc.conf configurará las - variables de tal forma que se ejecutaría el comando - natd -interface fxp0. Evidentemente este comando + variables de tal forma que se ejecutaría + natd -interface fxp0. Evidentemente esta orden también se puede ejecutar de forma manual. También es posible utilizar un fichero de configuración para &man.natd.8; en caso de que deseemos especificar muchos parámetros de arranque. Tendremos que declarar la ubicación del fichero de configuración mediante la inclusión de lo siguiente en /etc/rc.conf: natd_flags="-f /etc/natd.conf" El fichero /etc/natd.conf debe contener una lista de opciones de configuración una opción por línea. Por ejemplo, en el caso que se comenta en la siguiente sección se utilizaría un fichero de configuración con la siguiente información: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 Para obtener más información sobre el fichero de configuración se puede consultar la opción que se describe en la página del manual de &man.natd.8;. Cada máquina (y cada interfaz) que se encuentra conectada a la LAN debe poseer una dirección IP perteneciente al espacio de direcciones IP privado tal y como se define en RFC 1918 y debe poseer como pasarela por defecto la dirección IP de la interfaz interna (la interfaz que se conecta a la LAN) de la máquina que ejecuta natd. Por ejemplo los clientes A y B se encuentran en la LAN utilizando las direcciones IP Â192.168.0.2 y 192.168.0.3, respectivamente. La máquina que ejecuta natd posee la dirección IP 192.168.0.1 en la interfaz que se conecta a la LAN. El router por defecto tanto de A omo de B se establece al valor 192.168.0.1. La interfaz externa de la máquina que ejecuta natd, la interfaz que se conecta con Internet, no necesita de ninguna especial en relación con el tema que estamos tratando en esta sección. - Redirección de Puertos + Redirección de puertos El incoveniente que se presenta con la utilización de &man.natd.8; es que los clientes de la LAN no son accesibles desde Internet. Dichos clientes pueden establecer conexiones con el exterior pero no pueden recibir intentos de conexión desde pueden recibir intentos de conexion desde Internet. Esto supone un gran problema cuando se quieren ejecutar servicios de acceso global en una o varias máquinas de la red LAN. Una forma sencilla de solucionar parcialmente este problemma consiste en redirigir determinados puertos en el servidor natd hacia determinadas máquinas de la LAN. Supongamos por ejemplo que en A se ejecuta un servidor de IRC y que en B se ejecuta un servidor web. Para que funcione lo que hemos comentado anteriormente se tienen que redirigir las conexiones recibidas en los puertos 6667 (IRC) y 80 (web) a dichas máquinas, respectivamente. Se debe pasar la opción a &man.natd.8; con los valores apropiados. La sintaxis es como sigue: -redirect_port proto IPdestino:PUERTOdestino[-PUERTOdestino] [aliasIP:]aliasPUERTO[-aliasPUERTO] [IPremota[:PUERTOremoto[-PUERTOremoto]]] Continuando con el ejemplo anterior los valores serían: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 Esto redirigirá los puertos tcp adecuados a las máquinas situadas en la LAN. La opción se puede utilizar para indicar rangos de puertos en vez de puertos individuales. Por ejemplo, tcp 192.168.0.2:2000-3000 2000-3000 redirige todas las conexiones recibidas desde los puertos 2000 al 3000 a los puertos puertos 2000 a 3000 de la máquina A. Estas opciones se pueden utilizar cuando se ejecute - directamente el comando &man.natd.8; se pueden situar en la variable + directamente &man.natd.8; se pueden situar en la variable natd_flags="" en /etc/rc.conf y también se pueden pasar mediante un archivo de configuración. Para obtener más información sobre opciones de configuración por favor consulte &man.natd.8; - Redirección de Direcciones + Redirección de direcciones address redirection La redirección de direcciones es una característica útil si se dispone de varias direcciones IP pero todas ellas se ubican en una única máquina. Gracias a esto &man.natd.8; puede asignar a cada cliente de la red LAN su propia dirección IP externa. &man.natd.8; reescribe los paquetes que salen de la red LAN con la dirección IP externa adecuada y redirige todo el tráfico recibido de vuelta al cliente en función de la dirección IP de destino: esto se conoce como NAT estático. Por ejemplo las direcciones IP 128.1.1.1, 128.1.1.2 y 128.1.1.3 pertenecen al router natd. 128.1.1.1 se puede utilizar como la dirección IP externa del natd, mientras que 128.1.1.2 y 128.1.1.3 se redirigen a los clientes A y B, respectivamente. La sintaxis de la opción es la siguiente: -redirect_address IPlocal IPpública IPlocal La dirección IP interna del cliente de la LAN. IPpública La dirección IP externa que se corresponde con un determinado cliente de la LAN. En nuestro ejemplo esta opción se especificaría de la siguiente forma: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 De forma semejante a la opción estos argumentos se pueden especificar directamente sobre la variable natd_flags="" del fichero /etc/rc.conf o también se pueden pasar vía archivo de configuración de natd. Si se utiliza redirección de direcciones ya no es necesario utilizar redirección de puertos ya que todos los paquetes que se reciben en una determinada dirección IP son redirigidos a la máquina especificada. Las direcciones IP externas de la máquina que ejecuta natd se deben activar y deben formar parte de un alias configurado sobre la interfaz externa que se conecta a Internet. Consulte &man.rc.conf.5; para aprender a hacerlo. Chern Lee Escrito por - El <quote>Super Servidor</quote> <application> + <title>El <quote>Superservidor</quote> <application> inetd</application> Resumen &man.inetd.8; se conoce como el Super Servidor de Internet debido a que gestiona las conexiones de varios dæmones. Los dæmones son programas que proporcionan servicios de red. inetd actúa como un servidor de servidor de gestión de otros dæmones. Cuando &man.inetd.8; recibe una conexión se determina qué dæmon debería responder a dicha conexión, se lanza un proceso que ejecuta dicho dæmon y se le entrega el socket. La ejecución de una única instancia de inetd reduce la carga del sistema en comparación con lo que significaría ejecutar cada uno de los dæmones que gestiona de forma individual. inetd se utiliza principalmente para lanzar procesos que albergan a otros dæmones pero inetd también se utiliza para gestionar determinados protocolos triviales como chargen, auth y daytime. Esta sección trata la configuración básica de inetd a través de sus opciones de - línea de comandos y utilizando su fichero de + línea de órdenes y utilizando su fichero de configuración, denominado /etc/inetd.conf. Configuraciones inetd se inicializa a través del fichero /etc/rc.conf en tiempo de arranque. La opción inetd_enable posee el valor NO por defecto, pero a menudo la aplicación sysinstall la activa cuando se utiliza la configuración de perfil de seguridad medio. Estableciendo inetd_enable="YES" o inetd_enable="NO" dentro de /etc/rc.conf se puede activar o desactivar la la ejecución de inetd en el arranque del sistema. Se pueden además aplicar distintas opciones de - línea de comandos mediante la opción + línea de órdenes mediante la opción inetd_flags. - Opciones de Línea de Comandos + Opciones de línea de órdenes sinopsis de inetd: -d Activa la depuración. -l Activa el logging de las conexiones efectuadas con écute. -w Activa el recubrimiento de TCP para servicios externos (activado por defecto). -W Activa el recubrimiento de TCP para los servicios internos, ejecutados directamente por el dæmon inetd (activado por defecto). -c máximo Especifica el máximo número de invocaciones simultáneas de cada servicio; el valor por defecto es ilimitado. Se puede sobreescribir para cada servicio utilizando la opción . -C tasa Especifica el máximo número de veces que se puede llamar a un servicio desde un dirección IP determinada por minuto; el valor por defecto es ilimitado. Se puede redefinir para cada servicio utilizando la opción . -R tasa Especifica el máximo número de veces que se puede invocar un servicio en un minuto; el valor por defecto es 256. Un valor de 0 permite un número ilimitado de llamadas. -a Especifica una dirección IP a la cual se asocia y sobre la cual se queda esperando recibir conexiones. Puede declararse también un nombre de máquina, en cuyo caso se utilizará la dirección (o direcciones si hay más de una) IPv4 o IPv6 que estén tras dicho nombre. Normalmente se usa un nombre de máquina cuando inetd se ejecuta dentro de un &man.jail.8;, en cuyo caso el nombre de máquina se corresponde con el entorno &man.jail.8;. Cuando se desea asociarse tanto a direcciones IPv4 como a direcciones IPv6 y se utiliza un nombre de máquina se necesita una entrada para cada protocolo (IPv4 o IPv6) para cada servicio que se active a través de /etc/inetd.conf. Por ejemplo un servicio basado en TCP necesitaría dos entradas, una utilizando tcp4 para el protocolo IPv4 y otra con tcp6 para las conexiones a través del procolo de red IPv6. -p Especifica un fichero alternativo en el cual se guarda el ID del proceso. Estas opciones se pueden declarar dentro de las variables inetd_flags del fichero /etc/rc.conf. Por defecto inetd_flags tiene el valor -wW, lo que activa el recubrimiento de TCP para los servicios internos y externos de inetd. Los usuarios inexpertos no suelen introducir estos parámetros y por ello ni siquiera necesitan especificarse dentro de /etc/rc.conf. Un servicio externo es un dæmon que se ejecuta fuera de inetd y que se lanza cuando se recibe un intento de conexión. Un servicio interno es un servicio que inetd puede servir directamente sin necesidad de lanzar nuevos procesos. <filename>inetd.conf</filename> La configuración de inetd se realiza a través del ficherode configuración /etc/inetd.conf. Cuando se realiza una modificación en el fichero /etc/inetd.conf se debe obligar a inetd a releer dicho fichero de configuración, lo cual se realiza enviando una señal HANGUP al proceso inetd como se muestra a continuación: - Envío de una señal de tipo HANGUP a <application>inetd</application> + Envío de una señal HANGUP a + <application>inetd</application> &prompt.root; kill -HUP `cat /var/run/inetd.pid` Cada línea del fichero de configuración especifica un dæmon individual. Los comentarios se preceden por el caracter #. El formato del fichero de configuración /etc/inetd.conf es el siguiente: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] user[:group][/login-class] server-program server-program-arguments A continuación se muestra una entrada de ejemplo para el dæmon ftpd para IPv4: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Este es el nombre del servicio que proporciona un determinado dæmon. Se debe corresponder con el nombre del nombre de servicio que se declara en el fichero /etc/services. Este fichero determina sobre qué puerto debe ponerse a escuchar inetd. Si se crea un nuevo servicio se debe especificar primero en /etc/services. socket-type Puede ser stream, dgram, raw o seqpacket. stream se debe utilizar obligatoriamente para dæmones orientados a conexión (dæmones TCP) mientras que dgram se utiliza en dæmones basados en el protocolo de transporte UDP. protocol Uno de los siguientes: Protocolo Explicación tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 e IPv6 al mismo tiempo udp46 UDP IPv4 e IPv6 al mismo tiempo {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] indica si el dæmon puede gestionar su propio socket o no. Los sockets de tipo deben utilizar obigatoriamente la opción mientras que los dæmones basados en sockets de tipo stream, los cuales se implementan normalmente mediante hilos, debería utilizar la opción . La opción normalmente entrega varios sockets a un único dæmon, mientras que la opción lanza un dæmon hijo por cada nuevo socket. El número máximo de dæmones hijo que puede lanzar inetd se puede especificar mediante la opción . Si se necesita por ejemplo un límite de diez instancias para un dæmon en particular se puede especificar el valor 10 justo después de la opción . Además de se puede activar otra opción para limitar en número máximo de conexiones que se aceptan desde un determinado lugar mediante la opción . Esta opción hace justo lo que su nombre indica. Un valor de, por ejemplo, diez en esta opción limitaría cualquier máquina remota a un máximo de diez intentos de conexión por minuto. Esto resulta útil para prevenir un consumo incontrolado de recursos y ataques de Denegación de Servicio (Denial of Service o DoS) sobre nuestra máquina. Cuando se especifica este campo las opciones o son obligatorias y son opcionales. Un dæmon de tipo stream sin la opción y sin la opción simplemente especificaría la opción nowait. El mismo dæmon con el límite máximo de diez dæmones hijos sería: nowait/10. La misma configuración con un límite de veinte conexiones por dirección IP por minuto y un máximo total de diez dæmones hijos sería: nowait/10/20. Todas estas opciones son utilizadas por el dæmon fingerd que se muestra a continuación a modo de ejemplo: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s user Este es el nombre de usuario con el que debería ejecutarse un determinado dæmon. Normalmente los dæmones se suelen ejectar con permisos de root. Por motivos de seguridad, resulta bastante común encontrarse con algunos servidores que se ejecutan bajo el usuario daemon o incluso por el usuario menos privilegiado de todos que es el usuario nobody. server-program La ruta completa de la localización del dæmon que se quiere ejecutar cuando se recibe un intento de conexión. Si el dæmon es un servicio proporcionado por el propio inetd se debe utilizar la opcion en su lugar. server-program-arguments Esto funciona en conjunción con , ya que especifica los argumentos, comenzando por argv[0], que se pasan al dæmon - cuando se le invoca. Si la línea de comandos es + cuando se le invoca. Si la línea de órdenes es mydaemon -d, midæmon -d debería ser el valor de la opción . Si el dæmon es un servicio interno se debe utilizar la utilizar la opción en lugar de la que estamos comentando. - Security + Seguridad Dependiendo del perfil de seguridad establecido cuando se instaló el sistema &os; varios dæmones de inetd pueden estar desactivados o activados. Si no se necesita un dæmon determinado, no lo active. Especifique un # al comienzo de la línea del dæmon que quiere desactivar y envíe una señal hangup a inetd. No se aconseja ejecutar algunos dæmones determinados (un caso típico es fingerd) porque pueden proporcionar información valiosa para un atacante. Algunos dæmones no presentan ninguna característica de seguridad y poseen grandes o incluso no poseen tiempos de expiración para los intentos de conexión. Esto permite que un atacante sature los recursos de nuestra máquina realizando intentos de conexión a una tasa relativamente baja contra uno de estos ingenuos dæmones. Pueder ser una buena idea protegerse de esto utilizando las opciones y para este tipo de dæmones. El recubrimiento de TCP está activado por defecto tal y como ya se ha comentado anteriormente. Consulte la página del manual de &man.hosts.access.5; para obtener más información sobre cómo aplicar restricciones relacionadas con TCP a los dæmones invocados por inetd. Varios daytime, time, echo, discard, chargen y auth son servicios que inetd proporciona de forma interna y propia. El servicio auth proporciona servicios de identificación a través de la red (ident, identd) y se puede configurar hasta en cierto grado. Consulte la página del manual de &man.inetd.8; si quiere conocer todos los detalles. - Línea IP Paralela (PLIP) + Línea IP paralela (PLIP) PLIP Parallel Line IP PLIP nos permite configurar TCP/IP a través del puerto paralelo. Es útil para conectar máquinas que no poseen tarjetas de red, o para instalar &os; en ciertos viejos modelos de portátiles. En esta sección se explica lo siguiente: Construcción de un cable paralelo (laplink). Conexión de dos computadores utilizando PLIP. - Construcción de un Cable Paralelo + Construcción de un cable paralelo Se puede comprar un cable paralelo en cualquier tienda de componentes informáticos. No obstante si no es posible comprarlo o simplemente queremos saber cómo hacerlo nosotros mismos, en la siguiente tabla mostramos como hacer un cable de impresora paralelo. - Cableado de una Conexión de Cable Paralelo para Redes + Cableado de una conexión de cable paralelo para redes Nombre-A Extremo-A Extremo-B Descr. Post/Bit DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
Configuración de PLIP En primer lugar debemos tener en nuesras manos un cable laplink. A continuación se debe comprobar que ambos sistemas poseen núcleos con soporte para el controlador &man.lpt.4;: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port El puerto paralelo debe ser un puerto controlado por alguna irq. En &os; 4.X se debería tener un línea como la siguiente en el fichero de configuración del kernel: device ppc0 at isa? irq 7 En &os; 5.X el fichero /boot/device.hints debe contener las siguientes líneas: hint.ppc.0.at="isa" hint.ppc.0.irq="7" A continuación se debe comprobar que el fichero de configuración del núcleo posee una línea con device plip o también puede comprobar si se ha cargado el módulo del núcleo plip.ko. Tanto en un caso como en el otro, cuando se ejecute &man.ifconfig.8; debería aparecer el interfaz de red paralelo. En &os; 4.X se muestra algo parecido a lo siguiente: &prompt.root; ifconfig lp0 lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 y en &os; 5.X: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 El nombre del dispositivo utilizado para la interfaz paralela es distinto en &os; 4.X (lpX) y en &os; 5.X (plipX). Enchufe el cable laplink en los interfaces de ambos computadores. Configure los parámetros de la interfaz de red en ambas máquinas como root. Por ejemplo, si queremos conectar la máquina host1 ejecutando &os; 4.X con la máquina host2 que ejecuta &os; 5.X: host1 <-----> host2 Dirección IP 10.0.0.1 10.0.0.2 Configure la interfaz de host1 así: &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 Configure la interfaz de host2 por medio de: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 Tras esto debería disponerse de una conexión totalmente funcional. Por favor, consulte &man.lp.4; y &man.lpt.4; si quiere saber más. Además se debe añadir ambas máquinas al fichero /etc/hosts: 127.0.0.1 localhost.mi.dominio localhost 10.0.0.1 host1.mi.dominio host1 10.0.0.2 host2.mi.dominio Para comprobar que efectivamente la conexión funciona se puede probar a hacer un ping desde cada máquina. Por ejemplo en la máquina host1: &prompt.root; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 lp0 &prompt.root; ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Texto original de Tom Rhodes Reestructurado y ampliado por IPv6 IPv6 (también conocido como IPng o IP de nueva generación) es la nueva versión del conocido protocolo de red IP, tambíen llamado IPv4. Como sucede con el resto de los sistemas *BSD &os; proporciona una implementación de referencia que desarrolla el proyecto japonés KAME. &os; dispone de todo lo necesario para experimentar con el nuevo protocolo de red. Esta sección se centra en conseguir configurar y ejecutar correctamente el protocolo IPv6. Al comienzo de los años 90 la gente comenzó a preocuparse por el rápido consumo del espacio de direcciones de IPv4. Dada la expansión actual de Internet existen dos preocupaciones principales: Agotamiento de las direcciones disponibles. Actualmente no se trata del principal problema debido al uso generalizado del del espacio de direccionamiento privado (10.0.0.0/8, 192.168.0.0/24, etc.) junto con NAT. El número de entradas de las tablas de rutas comenzaba a ser imposible de manejar. Esto todavia es un problema prioritario. IPv6 trata de resolver estos problemas y algunos más de la siguiente forma: IPv6 posee un espacio de direccionamiento de 128 bits. En otras palabras, en teoría existen 340,282,366,920,938,463,463,374,607,431,768,211,456 direcciones disponibles. Esto significa que existen aproximadamente 6.67 * 10^27 direcciones IPv6 por metro cuadrado disponibles para todo el planeta Tierra. Los routers sólo almacenan direcciones de red agregadas así que se reduce el número de entradas para cada tabla de rutas a un promedio de 8192. Existen además muchas otras caracterísiticas interesantes que IPv6 proporciona, como: Autoconfiguración de direcciones (RFC2462) Direcciones anycast (una-de-varias) Soporte de direcciones multicast predefinido IPsec (Seguridad en IP) Estructura de la cabecera simplificada IP móvil Mecanismos de traducción de IPv6 a IPv4 (y viceversa) Si quiere saber más sobre IPv6 le recomendamos que consulte: Resumen de IPv6 en playground.sun.com KAME.net 6bone.net - Conceptos Básicos sobre las Direcciones IPv6 + Conceptos básicos sobre las direcciones IPv6 Existen varios tipos distintos de direcciones IPv6: Unicast, Anycast y Multicast. Las direcciones unicast son direcciones bien conocidas. Un paquete que se envía a una dirección unicast deberín llega a la interfaz identificada por dicha dirección. Las direcciones anycast son sintácticamente indistinguibles de las direcciones unicast pero sirven para identificar a un conjunto de interfaces. Un paquete destinado a una dirección anycast llega a la interfaz más cercana (en términos de métrica de routers). Las direcciones anycast sólo se pueden utilizar en routers. Las direcciones multicast identifican un grupo de interfaces. Un paquete destinado a una dirección multicast llega a todos los los interfaces que se encuentran agrupados bajo dicha dirección. Las direcciones IPv4 de tipo broadcast (normalmente xxx.xxx.xxx.255) se expresan en IPv6 mediante direcciones multicast. - Direcciones IPv6 Reservadas + Direcciones IPv6 reservadas Dirección IPv6 Longitud del Prefijo (Bits) Descripción Notas :: 128 bits sin especificar como 0.0.0.0 en Pv4 ::1 128 bits dirección de bucle local (loopback) como las 127.0.0.1 en IPv4 ::00:xx:xx:xx:xx 96 bits direcciónes IPv6 compatibles con IPv4 Los 32 bits más bajos contienen una dirección IPv4. También se denominan direcciones empotradas. ::ff:xx:xx:xx:xx 96 bits direcciones IPv6 mapeadas a IPv4 Los 32 bits más bajos contienen una dirección IPv4. Se usan para representar direcciones IPv4 mediante direcciones IPv6. fe80:: - feb:: 10 bits direcciones link-local equivalentes a la dirección de loopback de IPv4 fec0:: - fef:: 10 bits direcciones site-local Equivalentes al direccionamiento privado de IPv4 ff:: 8 bits multicast   001 (base 2) 3 bits direcciones unicast globales Todas las direcciones IPv6 globales se asignan a partir de este espacio. Los primeros tres bits siempre son 001.
- Lectura de las Direcciones IPv6 + Lectura de las direcciones IPv6 La forma canónica que se utiliza para representar direcciones IPv6 es: x:x:x:x:x:x:x:x, donde cada x se considera un valor hexadecimal de 16 Bit. Por ejemplo FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 A menudo una dirección posee alguna subcadena de varios ceros consecutivos de forma que se puede abreviar dicha cadena (sólo una vez, para evitar ambigúedades) mediante ::. También se pueden omitir los ceros a la ceros a la izquierda dentro de un valor x. Por ejemplo fe80::1 se corresponde con la forma canónica fe80:0000:0000:0000:0000:0000:0000:0001. Una tercera forma de escribir direciones IPv6 es utilizando la ya tradicional notación decimal de IPv4 pero sólamente para los 32 bits más bajos de la dirección IPv6. Por ejemplo 2002::10.0.0.1 se correspondería con la representation hexadecimal canónica 2002:0000:0000:0000:0000:0000:0a00:0001 la cual es equivalente también a escribir 2002::a00:1. A estas alturas el lector debería ser capaz de comprender lo siguiente: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 es una dirección link-local autoconfigurada. Se construye a partir de la dirección MAC de la tarjeta de red. Si quiere saber más sobre la estructura de las direcciones IPv6 puede consultar RFC3513. - Establecimiento de Conectividad + Establecimiento de conectividad Actualmente existen cuatro formas distintas de conectarse con otras máquinas y redes IPv6: Unirse a la red experimental denominada 6bone Obtener una red IPv6 a través de nuestro proveedor de acceso a Internet. Consulte a su proveedor de servicios para para más información. Encapsulación de IPv6 sobre IPv4 (RFC3068) Utilización del port net/freenet6 si se dispone de una de una conexión de marcación por modem. Vamos a explicar cómo conectarse al 6bone ya que parece ser la forma más utilizada en la actualidad. En primer lugar se recomienda consultar el sitio web de 6bone para saber cuál es la conexión del 6bone (físicamente) más próxima. Se debe escribir a la persona responsable de ese nodo y con un poco de suerte dicha persona responderá con con un conjunto de instrucciones y pasos a seguir para establecer la la conexión con ellos y a través de ellos con el resto de los nodos IPv6 que forman parte del 6bone. Normalmente esta conexión se establece usando túneles GRE (gif). Veamos un ejemplo típico de configuración de un de un túnel &man.gif.4;: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 &prompt.root; ifconfig gif0 tunnel MI_DIRECCIÓn_IPV4 SU_DIRECCIÓn_IPV4 &prompt.root; ifconfig gif0 inet6 alias DIRECCIÓn_DE-SALIDA_IPv6_DEL_TÚNEL_ASIGNADO Sustituya las palabras en mayúsculas por la información recibida del nodo 6bone al que nos queremos conectar. - El comando anterior establece el túnel. Compruebe que el + La orden anterior establece el túnel. Compruebe que el túnel funciona correctamente mediante &man.ping.8;. Haga un &man.ping6.8; a ff02::1%gif0. Deberíamos recibir recibir dos respuestas. Para que el lector no se quede pensando en el significado significado de la dirección ff02:1%gif0 le podemos decir que se trata de de una dirección IPv6 multicast de tipo link-local. %gif0 no forma parte del protocolo IPv6 como tal sino que se trata de un detalle de implementación relacionado con las direcciones link-local y se añade para especificar la interfaz de salida que se debe utilizar para enviar los paquetes de &man.ping6.8;. Como estamos haciendo ping a una dirección multicast a la que se unen todos los interfaces pertenecientes al mismo enlace debería responder al ping tanto nuestro propio interfaz como el interfaz remoto. A continuación se configura la ruta por defecto hacia nuestro enlace 6bone; observe que es muy semejante a lo que hay que hacer en IPv4: &prompt.root; route add -inet6 default -interface gif0 &prompt.root; ping6 -n MI_UPLINK &prompt.root; traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms Esta captura de pantalla variará dependiendo de la localización de la máquina. Tras seguir estos pasos deberíamos poder alcanzar el sitio IPv6 de www.kame.net y ver la tortuga bailarina, que es una imagen animada que sólo se muestra cuando se accede al servidor web utilizando el protocolo IPv6 (para ellos se encesita utilizar un navegador web que soporte IPv6, IPv6, por ejemplo www/mozilla o Konqueror, que forma parte de x11/kdebase3, o también con www/epiphany. - DNS en el Mundo IPv6 + DNS en el mundo IPv6 Existen dos tipos de registros de DNS para IPv6. No obstante el IETF ha declarado los registros A6 y CNAME como registros para uso experimental. Los registros de tipo AAAA son los únicos estandar a día de hoy. La utilización de registros de tipo AAAA es muy sencilla. Se asocia el nombre de la máquina con la dirección IPv6 de la siguiente forma: NOMBREDEMIMÁQUINA AAAA MIDIRECCIÓNIPv6 De igual forma que en IPv4 se utilizan los registros de tipo A. En caso de no poder administrar su propia zona de DNS se puede pedir esta configuración a su proveedor de servicios. Las versiones actuales de bind (versiones 8.3 y 9) y el port dns/djbdns (con el parche de IPv6 correspondiente) soportan los registros de tipo AAAA. Harti Brandt Escrito por ATM en &os; 5.X Configuración de IP clásico sobre ATM (PVCs) IP clásico sobre ATM (CLIP) es el método más sencillo de utilizar ATM con IP. Se puede utilizar con conexiones conmutadas (SVC) y con conexiones permanentes (PVCs). En esta sección se describe cómo configurar una red basada en PVCs. - Configuraciones en Red Mallada Completa + Configuraciones en red mallada completa El primer método para configurar CLIP con PVCs consiste en conectar unas máquinas con otras mediante circuitos PVC dedicados. Aunque la configuración parece sencilla llega a resultar imposible de manejar cuando se posee un número grande de máquinas. El ejemplo que se muestra a continuación supone que nuestra red posee cuatro máquinas y que cada una se conecta a la red ATM mediante una tarjeta de red ATM. El primer paso consiste en planificar las direcciones IP y las conexiones ATM que se van a configurar en las máquinas. Máquina Dirección IP hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 Para construir una red completamente mallada necesitamos una conexión ATM entre cada par de máquinas: Máquinas Pareja VPI.VCI hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 Los valores VPI y VCI en cada extremo de la conexión pueden ser diferentes pero por simplicidad suponemos que son iguales. A continuación necesitamos configurar las interfaces ATM en cada máquina: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up Suponiendo que la interfaz ATM es hatm0 en todas las máquinas. Ahora necesitamos configurar los PVCs en las máquinas (suponemos que ya se han configurado de forma correcta en el switch ATM, para lo cual puede ser necesario consultar el manual del switch). hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Por supuesto que se pueden utilizar otras especificaciones de tráfico siempre y cuando las tarjetas de red las soporten. En este caso la especificación del tipo de tráfico se completa con los parámetros del tráfico. Puede acceder a la ayuda de &man.atmconfig.8; así: &prompt.root; atmconfig help natm add y por supuesto en la página de manual de &man.atmconfig.8;. Se puede crear la misma configuración utilizando el fichero /etc/rc.conf. Para la máquina hostA sería algo así: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" El estado de todas las rutas CLIP se puede obtener en todo momento con: hostA&prompt.root; atmconfig natm show diff --git a/es_ES.ISO8859-1/books/handbook/bibliography/chapter.sgml b/es_ES.ISO8859-1/books/handbook/bibliography/chapter.sgml index cbc36ce31f..3d95e1cd35 100755 --- a/es_ES.ISO8859-1/books/handbook/bibliography/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/bibliography/chapter.sgml @@ -1,488 +1,488 @@ Bibliografía - Mientras que las páginas del manual proveen la referencia definitiva - para partes individuales del sistema operativo FreeBSD, son notorias por - no ilustrar como poner todas las piezas juntas para hacer que todo el - sistema operativo funcione fácilmente. Debido a esto, no hay - substituto para un buen libro de administración de sistemas UNIX y un - buen manual del usuario. + Aunque las páginas del manual proveen la referencia definitiva + para partes individuales del sistema operativo &os;, son notorias por + no ilustrar como poner todas las piezas juntas para hacer que todo el + sistema operativo funcione fácilmente. Debido a esto, no hay + sustituto para un buen libro de administración de sistemas UNIX y un + buen manual de usuario. - Libros y revistas específicas sobre FreeBSD + Libros y revistas específicas sobre &os; Libros y revistas internacionales: Usando FreeBSD (en Chino). FreeBSD for PC 98'ers (en japonés), publicado por SHUWA System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E. FreeBSD (en japonés), publicado por CUTT. ISBN 4-906391-22-2 C3055 P2400E. Introducción completa a FreeBSD (en japonés), publicado por Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E. Kit personal del principiante UNIX FreeBSD (en japonés), publicado por ASCII. ISBN 4-7561-1733-3 P3000E. Manual FreeBSD (traducción del japonés), publicado por ASCII. ISBN 4-7561-1580-2 P3800E. FreeBSD mit Methode (en alemán), publicado por Computer und Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0. Manual de instalación y utilización de FreeBSD (en japonés), publicado por Mainichi Communications Inc.. Libros y revistas en inglés: The Complete FreeBSD, publicado por Walnut Creek CDROM. Guías de usuario Computer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-075-9 Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-076-7 UNIX in a Nutshell. O'Reilly & Associates, Inc., 1990. ISBN 093717520X Mui, Linda. What You Need To Know When You Can't Find Your UNIX System Administrator. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-104-6 La Ohio State University ha escrito un Curso de introducción a UNIX disponible en línea en formato HTML y postscript. Jpman Project, Japan FreeBSD Users Group. FreeBSD User's Reference Manual (traducción japonesa). Mainichi Communications Inc., 1998. ISBN4-8399-0088-4 P3800E. Guías de administrador Albitz, Paul and Liu, Cricket. DNS and BIND, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-236-0 Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-080-5 Costales, Brian, et al. Sendmail, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-222-0 Frisch, Æleen. Essential System Administration, 2nd Ed. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-127-5 Hunt, Craig. TCP/IP Network Administration. O'Reilly & Associates, Inc., 1992. ISBN 0-937175-82-X Nemeth, Evi. UNIX System Administration Handbook. 2nd Ed. Prentice Hall, 1995. ISBN 0131510517 Stern, Hal Managing NFS and NIS O'Reilly & Associates, Inc., 1991. ISBN 0-937175-75-7 Jpman Project, Japan FreeBSD Users Group. FreeBSD System Administrator's Manual (traducción japonesa). Mainichi Communications Inc., 1998. ISBN4-8399-0109-0 P3300E. Guías de programadores Asente, Paul. X Window System Toolkit. Digital Press. ISBN 1-55558-051-3 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 Lehey, Greg. Porting UNIX Software. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992 ISBN 0-201-56317-7 Stevens, W. Richard. UNIX Network Programming. 2nd Ed, PTR Prentice Hall, 1998. ISBN 0-13-490012-X Wells, Bill. “Writing Serial Drivers for UNIX”. Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. El sistema operativo por dentro Andleigh, Prabhat K. UNIX System Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 Jolitz, William. “Porting UNIX to the 386”. Dr. Dobb's Journal. January 1991-July 1992. Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman The Design and Implementation of the 4.3BSD UNIX Operating System. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 Leffler, Samuel J., Marshall Kirk McKusick, The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 Schimmel, Curt. Unix Systems for Modern Architectures. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 Stevens, W. Richard. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 Vahalia, Uresh. UNIX Internals -- The New Frontiers. Prentice Hall, 1996. ISBN 0-13-101908-2 Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X Referencia de seguridad Cheswick, William R. and Steven M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 Garfinkel, Simson and Gene Spafford. Practical UNIX Security. 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN 1-56592-148-8 Garfinkel, Simson. PGP Pretty Good Privacy O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 Referencia de hardware Anderson, Don and Tom Shanley. Pentium Processor System Architecture. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 Ferraro, Richard F. Programmer's Guide to the EGA, VGA, and Super VGA Cards. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 La corporación Intel publica documentación sobre sus CPUs, chipsets y estándares en su web para desarrolladores, normalmente en archivos con formato PDF. Shanley, Tom. 80486 System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 Shanley, Tom. ISA System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 Shanley, Tom. PCI System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40993-3 Van Gilluwe, Frank. The Undocumented PC. Reading, Mass: Addison-Wesley Pub. Co., 1994. ISBN 0-201-62277-7 Historia de UNIX Lion, John Lion's Commentary on UNIX, 6th Ed. With Source Code. ITP Media Group, 1996. ISBN 1573980137 Raymond, Eric S. The New Hacker's Dictionary, 3rd edition. MIT Press, 1996. ISBN 0-262-68092-0. Also known as the Jargon File Salus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 Simon Garfinkel, Daniel Weise, Steven Strassmann. The UNIX-HATERS Handbook. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1 Don Libes, Sandy Ressler Life with UNIX — special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 The BSD family tree. 1997. ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree o local on a FreeBSD-current machine. The BSD Release Announcements collection. 1997. http://www.de.FreeBSD.org/de/ftp/releases/ Networked Computer Science Technical Reports Library. http://www.ncstrl.org/ Antiguas releases BSD procedentes del Computer Systems Research Group (CSRG). http://www.mckusick.com/csrg/: El paquete de 4 CDs cubre todas las versiones de BSD desde la 1BSD hasta la 4.4BSD y 4.4BSD-Lite2 (pero no la 2.11BSD, desafortunadamente). El último disco contiene el código fuente final y los archivos SCCS. Diarios y revistas The C/C++ Users Journal. R&D Publications Inc. ISSN 1075-2838 Sys Admin — The Journal for UNIX System Administrators Miller Freeman, Inc., ISSN 1061-2688 diff --git a/es_ES.ISO8859-1/books/handbook/boot/chapter.sgml b/es_ES.ISO8859-1/books/handbook/boot/chapter.sgml index 9a887d6096..a2e6ce939f 100644 --- a/es_ES.ISO8859-1/books/handbook/boot/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/boot/chapter.sgml @@ -1,775 +1,775 @@ - El Proceso de Arranque en FreeBSD + El proceso de arranque en &os; Sinópsis - iniciando + inicio mecanismo de arranque (bootstrap) Al proceso de inicio del sistema y carga del sistema operativo se le conoce como mecanismo de arranque (bootstrap), o simplemente arranque (booting). El proceso de arranque de FreeBSD provee de gran flexibilidad al configurar lo que ocurre cuando se inicia el sistema, permitiendole seleccionar de diferentes sistemas operativos instalados en el mismo ordenador, o inclusive diferentes versiones del mismo sistema oprativo o kernels instalados. Este capítulo detalla las opciones de configuración que puede manejar y como personalizar el proceso de arranque de FreeBSD. Esto incluye todo lo que sucede hasta que el kernel de FreeBSD comienza con la comprobación de dispositivos y se inicializa &man.init.8;. En caso de que usted desconozca cuando ocurre todo esto, esto sucede cuando el color del texto que aparece al iniciar el sistema, cambia de blanco a gris. Una vez que concluya con la lectura de este capítulo, usted sabrá: Cuales son los componentes del mecanismo de arranque de FreeBSD, y como es que interactuan entre sí. Las opciones que puede manejar con los componentes del mecanismo de arranque de FreeBSD, para controlar el proceso de inicio del sistema. - Só x86 + Sólo x86 El presente capítulo describe únicamente el proceso de inicio, para sistemas FreeBSD que corren en plataformas Intel x86. - El Problema que representa Arrancar el Sistema + El problema que representa arrancar el sistema El encender una computadora e iniciar el sistema operativo, trae consigo un dilema interesante. Por definición, la computadora no sabe hacer nada, hasta que el sistema operativo ha sido cargado. Esto incluye la ejecución de programas desde el disco duro. Así que este es el dilema; si la computadora no sabe hacer nada hasta que se cargue el sistema operativo, y el sistema operativo es un conjunto de programas que residen en el disco duro, ¿Cómo es que arranca el sistema operativo? Este problema se asemeja a un problema del libro Las Aventuras del Barón Munchausen. Donde un personaje ha caido parcialmente en un hoyo, y ha podido salir al tomarse de las cintas de sus botas y jalarse hacia fuera. En los años mozos de la computación, el término utilizado para hablar sobre el proceso de carga del sistema operativo era mecanismo de arranque (bootstrap), que por efectos de simplificación ahora conocemos como arranque (booting). En equipos con arquitectura x86, el Sistema Básico de Entrada/Salida (BIOS) es el responsable de cargar el sistema operativo. Para hacer esto, el BIOS busca en el disco duro el Registro Maestro de Arranque (RMA) (N de T. Conocido como MBR—Master Boot Record), el cual debe localizarse en un lugar específico del disco. El BIOS cuenta con suficiente información, para cargar y ejecutar el RMA, y asumir que el RMA puede encargarse del resto de las tareas necesarias en la carga del sistema operativo. BIOS Sistema Básico de Entrada/Salida Si usted sólo cuenta con un sistema operativo instalado en su disco duro, el RMA estándar será suficiente. Este RMA buscará la primer partición del disco que pueda arrancar, y posteriormente ejecutará el código restante de dicha partición, para efecto de completar la carga del sistema operativo. Si usted cuenta con varios sistemas operativos instalados en su disco, entonces puede hacer uso de un RMA diferente, uno que despliegue una lista de los diferentes sistemas operativos, y le permita escoger cual de ellos desea que se cargue. FreeBSD cuenta con un RMA de este tipo que puede ser instalado, así como otros distribuidores de sistemas operativos cuentan con RMAs alternativos. En el caso de FreeBSD, el resto del mecanismo de arranque, está dividido en tres etapas. La primer etapa es ejecutada por al RMA, que sabe lo suficiente como para poner a la computadora en un estado específico y ejecutar la segunda etapa. La segunda etapa puede hacer un poco más que esto, antes de ejecutar la tercer etapa. La tercer etapa finaliza el trabajo de carga del sistema operativo. El trabajo es dividido en tres etapas, debido a las limitantes que tiene una PC, en cuanto al tamaño de los programas a ejecutar, durante las etapas uno y dos. El encadenar estas tareas, le permiten a FreeBSD contar con un arrancador más flexible. kernel init Posteriormente el kernel es inicializado y comienza con la comprobación de dispositivos, y prepararlos para su uso. Una vez que el proceso de arranque del kernel ha finalizado, el kernel transfiere el control al proceso de usuario &man.init.8;, quien se asegura de que los discos se encuentren en buen estado para su uso. Posteriormente &man.init.8; inicia la configuración fuente a nivel de usuario, que monta los sistemas de ficheros, configura las tarjetas de red para que pueden comunicarse en la red, y comunmente inicia todos los procesos que normalmente son ejecutados en un sistema FreeBSD al arrancar el mismo. - El RMA, y las Etapas de Arranque Uno, Dos y Tres + El RMA y las etapas de arranque uno, dos y tres RMA, <filename>/boot/boot0</filename> Registro Maestro de Arranque (RMA) El RMA de FreeBSD, se localiza en /boot/boot0. Este es una copia del RMA, ya que el RMA real debe localizarse en una parte especial del disco duro, fuera de la área de FreeBSD. El fichero boot0 es muy simple, dado que el programa en el RMA sólo puede ser de 512 bytes. Si usted ha instalado el RMA de FreeBSD y ha instalado varios sistemas operativos en sus discos duros, entonces al momento de arrancar el sistema, visualizará una pantalla similar a la siguiente. Pantalla <filename>boot0</filename> F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 Es sabido que otros sistemas, en particular Windows 95, sobreescriben - el RMA con el suyo. Si esto le sucede, o bien desea reemplazar su RMA - actual con el RMA de FreeBSD, entonces puede utilizar los siguientes - comandos. + el RMA con el suyo. Si esto le sucede, o bien desea reemplazar su RMA + actual con el RMA de FreeBSD, entonces puede utilizar las siguientes + órdenes. &prompt.root; fdisk -B -b /boot/boot0 dispositivo Donde dispositivo es aquel, desde el cual usted pretende arrancar el sistema, tal como ad0 para el disco conectado al primer IDE, ad2 para el disco maestro conectado al IDE secundario, da0 para el primer disco SCSI, y así sucesivamente. Por otro lado, si usted es un usuario de Linux, y prefiere que la aplicación LILO controle el proceso de arranque, puede editar el fichero /etc/lilo.conf para incluir a FreeBSD, o bien seleccionar la opción durante el proceso de instalación. Si ha instalado el gestor de arranque de FreeBSD, puede arrancar Linux y modificar el fichero de configuración de LILO, /etc/lilo.conf, añadiendo la siguiente opción: other=/dev/hdXY table=/dev/hdb loader=/boot/chain.b label=FreeBSD lo que permitirá el arranque de FreeBSD y Linux, por medio de LILO. En nuestro ejemplo hemos utilizado XY para especificar el disco utilizado y su partición. Si usted utiliza un sistema SCSI, deberá cambiar /dev/hdXY por algo similar a /dev/sdXY, que nuevamente utiliza la sintáxis XY. La opción puede omitirse si usted cuenta con ambos sistemas operativos en el mismo disco. Una vez que esto se ha completado, puede ejecutar /sbin/lilo -v para que se actualicen los cambios en el sistema, lo cual deberá verificarse con los mensajes que aparezcan en pantalla. N de T: La opción mencionada como; , se mostrará tal cual aparece en este documento, una vez que ha terminado la fase de partición del disco duro. - Etapa Uno, <filename>/boot/boot1</filename>, y Etapa Dos, + <title>Etapa uno, <filename>/boot/boot1</filename>, y etapa dos, <filename>/boot/boot2</filename> Conceptualmente las estapas uno y dos, son parte del mismo programa, en la misma área del disco. Por cuestiones de espacio se han dividido en dos, pero estas siempre se instalaran de manera conjunta. Estas son localizadas en el sector de arranque, de la partición de arranque, que es donde boot0, o cualquier otro programa del RMA espera encontrar el programa que dará continuación al proceso de arranque. Los ficheros localizados bajo el directorio /boot son copias de los ficheros reales, que se localizan fuera del sistema de ficheros de FreeBSD. El fichero boot1 es muy simple, en virtud de que sólo puede tener un tamaño de 512 bytes, y conocer simplemente del etiquetador de discos de FreeBSD (disklabel), el cual almacena la información de las particiones, para efecto de localizar y ejecutar boot2. El fichero boot2 es un poco más sofisticado, y comprende lo suficiente del sistema de ficheros de FreeBSD como para localizar ficheros en el, y puede proveer una interfaz simple, para seleccionar el kernel o cargador que deberá ejecutarse. En virtud de que el cargador (loader) es mucho más sofisticado, y provee una configuración de arranque más sencilla de utilizar, boot2 la ejecuta normalmente, una vez que ha terminado de solicitar el arranque del kernel directamente. Pantalla de <filename>boot2</filename> >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/kernel boot: Si alguna vez requiere reemplazar los ficheros boot1 y boot2 instalados, utilice &man.disklabel.8;. &prompt.root; disklabel -B partición Donde partición es el disco y partición del cual pretende arrancar el sistema, tal como ad0s1 para la primer partición del disco Mastro—Primario. - Modo Peligrosamente Dedicado + Modo peligrosamente dedicado Si sólo utiliza el nombre del disco, tal como - ad0, al usar el comando &man.disklabel.8; + ad0, al usar &man.disklabel.8; creará un disco peligrosamente dedicado, sin partición alguna. Seguramente esto no es lo que desea hacer, así que asegurese dos veces antes de presionar la tecla Return cuando utilice &man.disklabel.8;. - Etapa Tres, <filename>/boot/loader</filename> (cargador de arranque) + Etapa tres, <filename>/boot/loader</filename> (cargador de arranque) cargador-de-arranque (boot-loader) El cargador es la etapa final de las tres etapas del mecanismo de arranque, y esta localizado en el sistema de ficheros, normalmente como /boot/loader. - El cargador pretende ser un metodo amistoso de - configuración, utilizando una serie de comandos integrados + El cargador pretende ser un metodo amistoso de + configuración, utilizando una serie de órdenes integradas de fácil uso, respaldado por un intérprete más - poderoso, con una serie de comandos de mayor complejidad. + poderoso, con una serie de órdenes de mayor complejidad. - Flujo del Programa Cargador + Flujo del programa cargador Durante la inicialización del sistema, el cargador hará una comprobación en busca de una consola y discos, y sabra de que disco se encuentra arrancando. Establecerá las variables necesarias, y posteriormente es iniciado el intérprete donde se - pueden ingresar comandos desde un fichero script o de manera - interactiva. + pueden introducir órdenes desde un script o de + manera interactiva. cargador configuración del cargador Posteriormente el cargador leerá el fichero /boot/loader.rc, que por default lee la información del fichero /boot/defaults/loader.conf que a su vez, establece las variables correspondientes y verifica en el fichero /boot/loader.conf los cambios locales que se hayan hecho, para establecer valores de las variables modificadas. Una vez llevado a cabo esto, loader.rc actua sobre estas variables, cargando cualquier módulo y kernel seleccionado. Finalmente, y por default, el cargador hace una pausa contando 10 segundos y en espera de que al presionar una tecla se interrumpa el proceso, de no ser así, procederá a arrancar el kernel. En el caso de que al hacer esta pausa, se haya presionado una tecla (diferente de Return), el proceso será interrumpido y se nos mostrará un - interprete de comandos (prompt), que entiende el conjunto de - comandos de fácil-uso, y donde el usuario puede ajustar - ciertas variables, cargar y descargar todos los modulos, y finalmente - arrancar o reiniciar el sistema. + prompt, que entiende el conjunto de órdenes + de fácil-uso, y donde el usuario puede ajustar + ciertas variables, cargar y descargar todos los módulos, y + también arrancar o reiniciar el sistema. - Comandos Internos del Cargador + Órdenes internas del cargador - A continuación se presentan los comandos más + A continuación se presentan las órdenes más comunes del cargador. Para ver una descripción detallada - de los mismos, por favor consulte la página de ayuda + de los mismos, por favor consulte la página de manual de &man.loader.8; autoboot segundos Procede a iniciar el arranque del sistema, si es que no es interrumpido el periodo dado, en segundos. Despliega una cuenta regresiva, y el tiempo dado es de 10 segundos. boot -opciones nombre_del_kernel Procede a iniciar el kernel de manera inmediata, con las opciones dadas, si es que fuera el caso y el kernel especificado, si es que se especifica alguno. boot-conf Rehace la configuración automática de modulos en función a las variables definidas, como sucede al arrancar. Esta opción sólo tiene - sentido utilizarla, si en primer lugar hemos usado el - comando unload, y hemos modificado alguna + sentido utilizarla, si en primer lugar hemos usado + unload, y hemos modificado alguna variable, siendo lo más común el kernel. help tema Muestra la ayuda de un tema específico, que lee del fichero /boot/loader.help. Si el tema que se indica es index, entonces se mostrará una lista de todos los temas disponibles. include fichero … Procesa el fichero que se ha especificado. - El fichero es - leido e interpretado línea por línea. Cualquier - error detendrá inmediatamente al comando include. + El fichero se lee e interpreta + línea por línea. Cualquier + error detendrá inmediatamente a include. load tipo fichero Carga el kernel, modulo del kernel, o el fichero del tipo dado, en base al fichero especificado. Cualquier argumento que se añada, será pasado al fichero. ls ruta Despliega un listado de todos los ficheros que se localizan en la ruta especificada, o en el directorio raíz, si es que no se le especifica ruta alguna. Si se utiliza la opción , también se mostrara el tamaño de los ficheros. lsdev Nos muestra una lista de todos los dispositivos desde los cuales puede ser posible cargar modulos. Si se incluye la opción , el listado que se obtiene cuenta con más detalle. lsmod Despliega los módulos cargados. Si se utiliza la opción , se mostraran más detalles. more fichero Despliega el contenido del fichero especificado, haciendo una pausa a cada numero determinado de LINEAS mostradas. reboot Reinicia el sistema de forma inmediata. set variable set variable=valor Especifica los valores de las variables de entorno del cargador. unload Remueve todos los módulos cargados. - Ejemplos de Uso del Cargador + Ejemplos de uso del cargador - He aqui unos ejemplos prácticos sobre el uso + He aqui unos ejemplos prácticos sobre el uso correcto del cargador. modo de arranque mono-usuario Para arrancar simplemente su kernel usual, pero en modo mono-usuario, deberá hacer lo siguiente: boot -s Para descargar su kernel usual y sus módulos correspondientes, y posteriormente cargar su kernel anterior (o cualquier otro): kernel.old unload load kernel.old Puede utilizar kernel.GENERIC para referirse al kernel generico actual que viene con la instalación, o bien puede utilizar kernel.old para hacer referencia al kernel anterior (por ejemplo, cuando ha actualizado su sistema o ha recompilado su propio kernel). Utilice lo siguiente para cargar sus módulos actuales con otro kernel: unload set kernel="kernel.old" boot-conf Para cargar un escrito de configuración (script que de forma automática hará todo lo que normalmente hace usted de forma manual al momento de ejecutarse el configurador de arranque): load -t escrito_de_configuración /boot/kernel.conf - Interacción con el Kernel Durante el Arranque + Interacción con el kernel durante el arranque kernel interacción de arranque Una vez que el kernel ha sido iniciado, ya sea por el cargador (que es lo común) o bien por boot2 (sobrepasando el cargador), examinará las opciones de arranque, en busca de cambios, y ajustar su comportamiento en caso de ser necesario. kernel opciones de arranque - Opciones de Arranque del Kernel + Opciones de arranque del kernel He aqui las opciones de arranque más comunes: durante la inicialización del kernel, pregunta por los dispositivos a utilizar, para montar el sistema de ficheros raíz. arranque desde una unidad de CDROM. ejecuta UserConfig, la utilidad de configuración de arranque del kernel. arranca el sistem en modo mono-usuario. imprime mensajes informativos durante el arranque del kernel Existen otras opciones de arranque, por favor vea la página de ayuda &man.boot.8; para más información al respecto. Tom Rhodes Escrito por device.hints Device Hints Pendiente de Traducción init - Init: Inicialización del Proceso de Control + Init: inicialización del proceso de control Ya que el kernel ha finalizado de arrancar, pasará el control a un proceso de usuario llamado init, el cual se localiza en /sbin/init, o bien en la ruta especificada por la variable de entorno init_path del cargador. - Secuencia Automática de Reinicio + Secuencia automática de reinicio La secuencia automática de reinicio se asegura de que los sistemas de ficheros disponibles en el sistema sean consistentes. Si no lo son, y el programa fsck no puede arreglar estas inconsistencias, init envia el sistema a modo monousuario, de tal forma que el administrador pueda ingresar en él y arreglar los problemas directamente. - Modo Mono-Usuario + Modo monousuario modo mono-usuario consola A este modo se puede llegar por medio de la secuencia automática de reinicio, o por medio de la opción en el arranque de usuario o al establecer la variable boot_single en el cargador. También desde el modo multi-usuario se puede acceder, - al utilizar el comando shutdown sin la + al utilizar shutdown sin la opción de reinicio () o la de apagado () del sistema. Si la consola del sistema esta configurada de modo inseguro en el fichero /etc/ttys, entonces el sistema solicitará la contraseña del superusuario (root), antes de ingresar al sistema en modo mono-usuario. - Una Consola Insegura en /etc/ttys + Una consola insegura en /etc/ttys # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off insecure Una consola insegura significa que usted considera como insegura físicamente su consola, por lo que desea asegurarse de que sólo quien conoce la contraseña del superusuario puede ingresar al sistema en modo mono-usuario, y no que desea ejecutar la consola inseguramente. Esto es, si desea contar con seguridad escoja la opción insecure, y no secure. - Modo Multi-Usuario + Modo multiusuario modo multi-usuario En el caso de que init encuentre en buen estado al sistema de ficheros, o una vez que el usuario ha terminado del modo mono-usuario, el sistema entrará al modo multi-usuario, en donde comienzan los ficheros de configuración-fuente del sistema. ficheros rc Configuración-Fuente(rc) La configuración fuente lee la configuración por default del fichero /etc/defaults/rc.conf, y detalles específicos del sistema desde el fichero /etc/rc.conf, y posteriormente procede a montar los sistemas de ficheros del sistema, descritos en /etc/fstab, iniciar servicios de red, así como varios demonios del sistema, para finalmente ejecutar los escritos (scripts) de configuración instalados por paquetes, localmente. La página de ayuda &man.rc.8; es una buena referencia para conocer más de este tipo de ficheros, así como examinar los mismos ficheros. - Secuencia de Apagado + Secuencia de apagado apagado - Una vez que el apagado sea controlado, por medio del - comando shutdown, init + Una vez que el apagado sea controlado, por medio de + shutdown, init ejecutará el escrito /etc/rc.shutdown, para posteriormente enviar a todos los procesos la señal TERM, y subsecuentemente la señal KILL a cualquiera que no haya terminado en tiempo. diff --git a/es_ES.ISO8859-1/books/handbook/desktop/chapter.sgml b/es_ES.ISO8859-1/books/handbook/desktop/chapter.sgml index 0b89f5374e..5d589a1e46 100644 --- a/es_ES.ISO8859-1/books/handbook/desktop/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/desktop/chapter.sgml @@ -1,1294 +1,1294 @@ Christophe Juniet Contributed by Aplicaciones de escritorio Sinopsis - FreeBSD puede correr un gran número de aplicaciones de - escritorio, como navegadores y procesadores de texto. La - mayoría de ellas están disponibles como paquetes o + &os; puede ejecutar gran número de aplicaciones de + escritorio, como navegadores y procesadores de texto. La + mayoría de ellas están disponibles como paquetes o se pueden construir automáticamente desde la colección de ports. Muchos usuarios nuevos esperan encontrar este tipo de aplicaciones en su escritorio. Este capítulo mostrará como instalar sin esfuerzo algunas aplicaciones populares, bien desde paquetes o desde la colección de ports. Tenga en cuenta que cuando se instalan programas desde los ports, estos se compilan desde el código fuente. Esto puede tardar muchísimo tiempo, dependiendo de que este compilando y la potencia de de proceso de su máquina. Si construir desde el código requiere un periodo de tiempo prohibitivo, puede instalar la mayoría de programas de la colección de ports desde paquetes preconstruidos. - Como FreeBSD tiene compatibilidad binaria con Linux, muchas + Como &os; tiene compatibilidad binaria con Linux, muchas aplicaciones originalmente desarrolladas para Linux están disponibles para su escritorio. Se recomienda encarecidamente que lea antes de instalar alguna de las aplicaciones Linux. Muchos de los ports que usan la compatibilidad binaria de Linux empiezan con linux-. Recuerde esto cuando busque un port en particular, por ejemplo con &man.whereis.1;. En el siguiente texto, se asume que usted ha habilitado la compatibilidad binaria de linux antes de instalar alguna de las aplicaciones de Linux. Estas son las categorías cubiertas por este capítulo: Navegadores (como Mozilla, &netscape;, Opera, Firefox, Konqueror) Productividad (como KOffice, AbiWord, The GIMP, OpenOffice.org) Visores de documentos (como &acrobat.reader;, gv, Xpdf, GQview) Finanzas (como GnuCash, Gnumeric, Abacus) Antes de leer este capítulo, usted debería: Saber como instalar software de terceros (). Saber como instalar software de Linux (). Para obtener información de como conseguir un entorno multimedia, lea el capítulo dedicado a multimedia. Si quiere configurar y usar correo electronico, por favor mire . Navegadores - FreeBSD no trae ningún navegador preinstalado. En su lugar, + &os; no trae ningún navegador preinstalado. En su lugar, el directorio www de la colección de ports tiene muchos navegadores listos para instalar. Si no tiene tiempo para compilarlo todo (esto puede requerir muchísimo tiempo en algunos casos) muchos de ellos estan disponibles como paquetes. KDE y GNOME ya proporcionan navegadores HTML. Por favor mire para más información sobre como configurar estos escritorios. Si busca navegadores ligeros, debería mirar en la colección de ports www/dillo, www/links, o www/w3m. Esta sección cubre estas aplicaciones: Nombre de aplicación Recursos necesarios Instalación desde los Ports Dependencias importantes Mozilla pesado pesado Gtk+ &netscape; pesado ligero Compatibilidad binaria con Linux Opera ligero ligero - Versiones para FreeBSD y Linux disponibles. La + Versiones para &os; y Linux disponibles. La versión de Linux depende de la compatibiliad binaria de Linux y de linux-openmotif. Firefox medio pesado Gtk+ Konqueror medio pesado KDE Librerias Mozilla Mozilla Mozilla es quizá el navegador más conveniente para su escritorio - FreeBSD. Es moderno, estable, y esta totalmente portado a - FreeBSD. Tiene un motor que cumple con el standard + &os;. Es moderno, estable, y esta totalmente portado a + &os;. Tiene un motor que cumple con el standard HTML. También tiene un cliente de mail y un lector de noticias. Incluso tiene un compositor de páginas HTML por si quiere hacer páginas web. Los usuarios de &netscape encontraran semejanzas con la suite Communicator, dado que ambos navegadores comparten la misma base. En máquinas lentas, con una CPU de velocidad inferior a 233MHz o con menos de 64MB de ram, Mozilla puede consumir demasiados recursos para ser totalmente usable. En su lugar podría interesarle el navegador Opera, descrito despues en este capítulo. Si no puede o no quiere compilar Mozilla por algún motivo, el equipo - de FreeBSD GNOME ya lo ha hecho por usted. Solo instale el + de &os; GNOME ya lo ha hecho por usted. Solo instale el paquete desde la red con: &prompt.root; pkg_add -r mozilla Si el paquete no esta disponible, y tiene suficiente tiempo y espacio en el disco, puede obtener el código de Mozilla, compilarlo e instalarlo en su sistema. Esto se hace con: &prompt.root; cd /usr/ports/www/mozilla &prompt.root; make install clean El port de Mozilla se asegura de que se inicialice adecuadamente corriendo la configuración del registro chrome con privilegios de root. Aunque si quiere instalar algún añadido como mouse gestures (gestos del ratón), tiene que correr Mozilla como root para que se instale correctamente. Una vez que haya completado la instalación de Mozilla, no necesita ser root durante mas tiempo. Puede arrancar Mozilla como navegador escribiendo: &prompt.user; mozilla Puede arrancarlo directamente como lector de mail y noticias como se muestra debajo: &prompt.user; mozilla -mail Tom Rhodes Contributed by Mozilla, &java;, y ¯omedia; &flash; Instalar Mozilla es facil, pero desafortunadamente instalar Mozilla con añadidos como &java; y ¯omedia; &flash; requiere tiempo y espacio en el disco. Lo primero es bajar los ficheros que se usarán con Mozilla. Vaya con su navegador a y cree una cuenta en la página web. Recuerde guardar el usuario y la contraseña desde ahora porque sera necesaria en el futuro. Baje una copia del fichero j2sdk-1_3_1-src.tar.gz y pongala en /usr/ports/distfiles/ porque el port no lo bajará automáticamente. Esto es debido a las restricciones de la licencia. Mientras estamos aquí, baje el entorno java de . El fichero es j2sdk-1_3_1_08-linux-i586.bin y es grande (ocupa unos 25 megabytes!). Como antes, este fichero se tiene que colocar en /usr/ports/distfiles/. Finalmente baje una copia del java patchkit desde y coloquela en /usr/ports/distfiles/. Instale el port java/jdk13 con make install clean estándard y despues instale el port www/flashpluginwrapper. Este port requiere emulators/linux_base que es un port grande. Es cierto que existen otros plugins de &flash;, aunque no me han funcionado. Instale el port de www/mozilla, si Mozilla aun no esta instalado. Ahora copie los ficheros del plug-in de &flash; con: &prompt.root; cp /usr/local/lib/flash/libflashplayer.so \ /usr/X11R6/lib/browser_plugins/libflashplayer_linux.so &prompt.root; cp /usr/local/lib/flash/ShockwaveFlash.class \ /usr/X11R6/lib/browser_plugins/ Ahora añada las siguientes líneas en la parte superior (pero debajo de #!/bin/sh) del script de arranque de Mozilla: /usr/X11R6/bin/mozilla. LD_PRELOAD=/usr/local/lib/libflashplayer.so.1 export LD_PRELOAD Esto activará el plug-in de &flash;. Ahora arranque Mozilla con: &prompt.user; mozilla & Y vaya a la opción About Plug-ins del menú Help. Debiera aparecer una lista con todos los plugins disponibles. Deberian aparecer &java; y &shockwave; &flash;. &netscape; Netscape La colección de ports tiene varias versiones del - navegador &netscape;. Como la versión nativa de FreeBSD + navegador &netscape;. Como la versión nativa de &os; tiene un grave fallo de seguridad, no se recomienda instalarla. En su lugar, use una versión más reciente para Linux o DIGITAL UNIX. La última versión estable del navegador &netscape; es &netscape; 7. Se puede instalar desde la colección de ports: &prompt.root; cd /usr/ports/www/netscape7 &prompt.root; make install clean Hay versiones traducidas en las categorias de Frances, Aleman, y Japones. No se recomiendan las versiones de &netscape; 4.x porque no cumplen con los estándards actuales. Aunque &netscape; 7.x y las nuevas versiones estan solo disponibles para la plataforma &i386;. Opera Opera Opera es un navegador muy rapido, completo y cumple con los estándards. Hay dos - versiones: la versión nativa de FreeBSD + versiones: la versión nativa de &os; y la versión que corre bajo la emulación de Linux. Para cada sistema operativo, hay una versión sin coste que muestra propaganda y otra sin propaganda que se puede comprar en la página web de Opera. - Para navegar por la Web con la versión para FreeBSD + Para navegar por la Web con la versión para &os; de Opera, instale el paquete: &prompt.root; pkg_add -r opera Algunos sitios FTP no tienen todos los paquetes, pero se puede obtener el mismo resultado desde la colección de ports escribiendo: &prompt.root; cd /usr/ports/www/opera &prompt.root; make install clean Para instalar la versión de Linux de Opera, ponga linux-opera en lugar de opera en los atnteriores ejemplos. La versión de Linux es util en situaciones donde se necesitan plugins que estan solo disponibles para Linux, como Adobe &acrobat.reader;. En el - resto las versiones de FreeBSD y Linux son iguales. + resto las versiones de &os; y Linux son iguales. Firefox Firefox Firefox es el navegador de la siguiente generación basado en el código de Mozilla. Mozilla es una suite de aplicaciones completa, como un navegador, un cliente de email, un cliente de chat y mucho mas. Firefox es solo un navegador, lo que hace que sea más pequeño y rapido. Instale el paquete escribiendo: &prompt.root; pkg_add -r firefox También puede usar la colección de ports si prefiere compilarlo desde el código fuente: &prompt.root; cd /usr/ports/www/firefox &prompt.root; make install clean Konqueror Konqueror Konqueror es parte de KDE pero también se puede usar fuera de KDE instalando x11/kdebase3. Konqueror es mucho más que un navegador, también es un gestor de ficheros y visor multimedia. Konqueror también trae un conjunto de plugins, disponibles en misc/konq-plugins. Konqueror también soporta &flash;, hay un como (how to) disponible en . Productividad Cuando se trata de productividad, normalmente los nuevos usuarios buscan una buena suite ofimática o un procesador de textos amigable. Mientras que algunos entornos de escritorio como KDE ya proveen una suite ofimática, no hay una aplicación por - defecto. FreeBSD provee todo lo que se necesita, sin importar + defecto. &os; provee todo lo que se necesita, sin importar que entorno de escritorio use. Esta sección cubre estas aplicaciones: Nombre de la aplicación Recursos requeridos Instalación desde los ports Dependencias importantes KOffice ligero pesado KDE AbiWord ligero ligero Gtk+ o GNOME The Gimp ligero pesado Gtk+ OpenOffice.org pesado enorme GCC 3.1, &jdk; 1.3, Mozilla KOffice KOffice office suite KOffice La comunidad de KDE ha equipado su entorno de escritorio con una suite ofimática que se puede usar fuera de KDE. Incluye los 4 componentes estándard que se pueden encontrar en otras suites ofimáticas. KWord es el procesador de textos, KSpread es la hoja de cálculo, KPresenter se encarga de las presentaciones, y Kontour le permite dibujar documentos gráficos. Antes de instalar el último KOffice, asegurese de que tiene una versión actualizada de KDE. Para instalar KOffice como un - paquete, ejecute el siguiente comando: + paquete, ejecute la siguiente orden: &prompt.root; pkg_add -r koffice Si el paquete no esta disponible, puede usar la colección de ports. Por ejemplo, para instalar KOffice para KDE3, haga: &prompt.root; cd /usr/ports/editors/koffice-kde3 &prompt.root; make install clean AbiWord AbiWord AbiWord es un procesador de textos libre con un aspecto parecido a µsoft; Word. Es útil para escribir documentos, cartas, informes, notas, etc. Es muy rapido, tiene muchas opciones, y es muy amigable. AbiWord puede importar o exportar muchos formatos de fichero, incluyendo algunos propietarios como Microsoft .doc. AbiWord esta disponible como un paquete. Puede instalarlo con: &prompt.root; pkg_add -r AbiWord2 Si el paquete no esta disponible, se puede compilar desde la colección de ports. La colección de ports debería estar más actualizada. Se puede hacer asi: &prompt.root; cd /usr/ports/editors/AbiWord2 &prompt.root; make install clean The GIMP The GIMP Para crear imágenes o retocarlas, The GIMP es un programa muy sofisticado para manipular imágenes. Se puede usar como un simple programa de dibujo o como una sofisticada herramienta de retoque fotográfico. Soporta un gran número de plug-ins y opciones como una interfaz para scripts. The GIMP puede leer y escribir un gran número de formatos de fichero. Soporta escáners y tabletas gráficas;. - Puede instalar el paquete ejecutando el siguiente comando: + Puede instalar el paquete ejecutando la siguiente orden: &prompt.root; pkg_add -r gimp Si su servidor FTP no tiene este paquete, puede usar la colección de ports. El directorio graphics de la colección de ports también contiene The Gimp Manual. Puede instalarlo asi: &prompt.root; cd /usr/ports/graphics/gimp &prompt.root; make install clean &prompt.root; cd /usr/ports/graphics/gimp-manual-pdf &prompt.root; make install clean El directorio graphics de la colección de ports tiene la versión de desarrollo de The GIMP en graphics/gimp-devel. La versión en HTML de The Gimp Manual esta disponible en graphics/gimp-manual-html. OpenOffice.org OpenOffice.org office suite OpenOffice.org OpenOffice.org incluye todas las aplicaciónes esenciales en una completa suite ofimática: un procesador de textos, una hoja de cálculo, un gestor de presentaciones, y un programa de dibujo. Su interfaz de usuario es muy parecida a otras suites ofimáticas, y puede importar y exportar en varios formatos de archivo populares. Esta disponible en diferentes idiomas, incluyendo interfaces, correctores ortográficos, y diccionarios. El procesador de textos de OpenOffice.org usa un fichero XML nativo para aumentar la portabilidad y la eficiencia. El programa de hojas de cálculo tiene un lenguaje de macros y puede usarse desde bases de datos externas. OpenOffice.org es actualmente estable y corre de forma nativa en &windows;, - &solaris;, Linux, FreeBSD, y &macos; X. Puede + &solaris;, Linux, &os;, y &macos; X. Puede encontrar más información sobre OpenOffice.org en la página web de OpenOffice. Para obtener información especifica - relacionada con FreeBSD, y para bajar directamente los + relacionada con &os;, y para bajar directamente los paquetes use la página web de FreeBSD OpenOffice + url="http://porting.openoffice.org/freebsd/">&os; OpenOffice Porting Team. Para instalar OpenOffice.org, ejecute: &prompt.root; pkg_add -r openoffice Una vez que el paquete este instalado, debe correr el programa de configuración y elegir . Ejecute - este comando con el usuario que vaya a usar + esta orden con el usuario que vaya a usar OpenOffice.org: &prompt.user; openoffice-setup Si los paquetes de OpenOffice.org no estan disponibles, sigue teniendo la opción de compilar el port. Aunque debe tener en cuenta que es necesario muchisimo espacio y tardará bastante en compilar. &prompt.root; cd /usr/ports/editors/openoffice-1.1 &prompt.root; make install clean Una vez que haya terminado esto, corra el programa de configuración con el usuario que vaya a usar OpenOffice.org y elija ejecutando: &prompt.user; cd /usr/ports/editors/openoffice-1.1 &prompt.user; make install-user Si quiere usar una versión localizada, aqui estan disponibles los diferentes ports: Idioma Port Catalan editors/openoffice-1.1-ca Checo editors/openoffice-1.1-cs Danés editors/openoffice-1.1-dk Griego editors/openoffice-1.1-el Español editors/openoffice-1.1-es Estonio editors/openoffice-1.1-et Finlandés editors/openoffice-1.1-fi Italiano editors/openoffice-1.1-it Holandés editors/openoffice-1.1-nl Sueco editors/openoffice-1.1-se Eslovaco editors/openoffice-1.1-sk Esloveno editors/openoffice-1.1-sl_SI Turco editors/openoffice-1.1-tr Arabe editors/openoffice-1.1 Frances french/openoffice-1.1 Alemán german/openoffice-1.1 Hungaro german/openoffice-1.1 Japones japanese/openoffice-1.1 Koreano korean/openoffice-1.1 Polaco polish/openoffice-1.1 Portugues (Brasil) portuguese/openoffice-1.1-pr_BR Portugues portuguese/openoffice-1.1-pr_PT Ruso russian/openoffice-1.1 Visores de documentos Algunos formatos de documento nuevos han ganado popularidad. Los visores de documentos que requieren pueden no estar disponibles en el sistema base. Veremos como instalarlos en esta sección. Esta sección cubre las siguientes aplicaciones: Nombre de la aplicación Recursos necesarios Instalación desde los ports Dependencias importantes &acrobat.reader; ligero ligero Compatibilidad binaria con Linux gv ligero ligero Xaw3d Xpdf ligero ligero FreeType GQview ligero ligero Gtk+ o GNOME &acrobat.reader; Acrobat Reader PDF viewing Muchos documentos se distribuyen ahora como ficheros PDF. Que significa Portable Document Format. Uno de los visores recomendados para este tipo de ficheros es &acrobat.reader;, lanzado por Adobe - para Linux. Como FreeBSD puede correr binarios de Linux, - también esta disponible para FreeBSD. + para Linux. Como &os; puede correr binarios de Linux, + también esta disponible para &os;. Para instalar el paquete de &acrobat.reader; 5, ejecute: &prompt.root; pkg_add -r acroread Como de costumbre, si el paquete no esta disponible o desea la última versión, también puede usar la colección de ports: &prompt.root; cd /usr/ports/print/acroread5 &prompt.root; make install clean gv gv PDF viewing PostScript viewing gv es un visor &postscript; y PDF. Esta basado en ghostview pero tiene un aspecto mejor gracias a la libreria Xaw3d. Es rapido y tiene una interfaz limpia. gv tiene muchas opciónes como orientación, tamaño del papel, escalado, o antialias. Casi todas las operaciones se pueden realizar desde el teclado o desde el ratón. Para instalar gv como paquete, ejecute: &prompt.root; pkg_add -r gv Si no puede obtener el paquete, puede usar la colección de ports: &prompt.root; cd /usr/ports/print/gv &prompt.root; make install clean Xpdf Xpdf PDF viewing Si quiere un visor de PDF pequeño, Xpdf es un visor ligero y eficiente. Requiere muy pocos recursos y es muy estable. Usa las fonts estándard de X y no requiere &motif; ni ningún otro toolkit de X. Para instalar el paquete de - Xpdf, use el siguiente comando: + Xpdf, use la siguiente orden: &prompt.root; pkg_add -r xpdf Si el paquete no esta disponible o prefiere usar la colección de ports, ejecute: &prompt.root; cd /usr/ports/graphics/xpdf &prompt.root; make install clean Una vez que la instalación se haya completado, puede lanzar Xpdf y usar el botón derecho del ratón para activar el menú. GQview GQview GQview es un visor de imagenes. Puede ver un fichero con un click, lanzar un editor externo, obtener imagenes de previsualización, y mucho mas. También tiene un modo de presentación y soporta algunas opciones basicas de manipulación de ficheros. Puede manejar colecciones de imagenes y encontrar duplicados con facilidad. GQview puede mostrar las imágenes a pantalla completa y soporta internacionalización. Si quiere instalar el paquete de GQview, ejecute: &prompt.root; pkg_add -r gqview Si el paquete no esta disponible o prefiere usar la colección de ports, ejecute: &prompt.root; cd /usr/ports/graphics/gqview &prompt.root; make install clean Finanzas Si, por algun motivo, quisiera manejar sus finanzas - personales en su escritorio FreeBSD, hay algunas aplicaciones + personales en su escritorio &os;, hay algunas aplicaciones potentes y sencillas de utilizar listas para instalar. Algunas de ellas son compatibles con formatos muy extendidos como documentos de Quicken o Excel. Esta sección cubre estas aplicaciones: Nombre de aplicación Recursos necesarios Instalación desde los ports Dependencias importantes GnuCash ligero pesado GNOME Gnumeric ligero pesado GNOME Abacus ligero pesado Tcl/Tk GnuCash GnuCash GnuCash es parte del esfuerzo de GNOME para proveer aplicaciones de uso sencillo pero a la vez potentes a los usuarios. Con GnuCash, puede gestionar sus ingresos y sus gastos, sus cuentas bancarias, o sus acciones. Tiene una interfaz intuitiva pero muy profesional. GnuCash provee un registro elegante, un sistema jerárquico de cuentas, muchos aceleradores de teclado y auto-completado de metodos. Puede dividir una transacción en varios pedazos más detallados. GnuCash puede importar y juntar ficheros QIF de Quicken. También maneja muchos formatos internacionales de fecha y moneda. Para instalar GnuCash en su sistema, ejecute: &prompt.root; pkg_add -r gnucash Si el paquete no esta disponible, puede usar la colección de ports: &prompt.root; cd /usr/ports/finance/gnucash &prompt.root; make install clean Gnumeric Gnumeric spreadsheet Gnumeric Gnumeric Es una hoja de cálculo, parte del entorno de escritorio GNOME. Implementa una predicción automática de la entrada del usuario de acuerdo con el formato de celda y un sistema de completado automático para multiples secuencias. Puede importar ficheros de un gran número de formatos populares como Excel, Lotus 1-2-3, o Quattro Pro. Gnumeric soporta gráficas a traves de del programa de gráficas math/guppi. Tiene un gran n´mero de funciones internas y permite todos los formatos normales de celda como número, moneda, fecha, hora, y mucho mas. Para instalar Gnumeric como paquete, ejecute: &prompt.root; pkg_add -r gnumeric Si el paquete no esta disponible, puede usar la colección de ports haciendo: &prompt.root; cd /usr/ports/math/gnumeric &prompt.root; make install clean Abacus Abacus spreadsheet Abacus Abacus es una hoja de calculo pequeña y facil de usar. Tiene muchas funciones utiles en varios ámbitos como la estadistica, las finanzas, y las matemáticas. Puede importar y exportar ficheros con formato Excel. Abacus puede generar ficheros &postscript;. Para instalar Abacus desde su paquete, ejecute: &prompt.root; pkg_add -r abacus Si el paquete no esta disponible, puede usar la colección de ports haciendo:&prompt.root; cd /usr/ports/deskutils/abacus &prompt.root; make install clean Resumen - Mientras que FreeBSD es popular entre los ISPs por su + Mientras que &os; es popular entre los ISPs por su rendimiento y estabilidad, también se puede usar a diario como escritorio. Con miles de aplicaciones disponibles como paquetes o ports, puede crear un escritorio que cubra todas sus necesidades. Una vez que haya instalado su escritorio, puede querer ir mas alla con misc/instant-workstation. este meta-port le permite construir un conjunto típico de ports para una estación de trabajo. Puede personalizarlo editando /usr/ports/misc/instant-workstation/Makefile. Siga la sintaxis empleada en las aplicaciones por defecto para añadir o quitar ports, y construyalo con el procedimiento habitual. ¡También puede crear un gran paquete que se corresponda con su propio escritorio e instalarlo en otras estaciones de trabajo! Aqui hay un resumen de todas las aplicaciones cubiertas en este cápitulo: Nombre De La Aplicación Nombre Del Paquete Nombre Del Port Mozilla mozilla www/mozilla &netscape; linux-netscape7 www/netscape7 Opera opera www/opera Firefox firefox www/firefox KOffice koffice-kde3 editors/koffice-kde3 AbiWord AbiWord2 editors/AbiWord2 The GIMP gimp graphics/gimp OpenOffice.org openoffice editors/openoffice-1.1 &acrobat.reader; acroread print/acroread5 gv gv print/gv Xpdf xpdf graphics/xpdf GQview gqview graphics/gqview GnuCash gnucash finance/gnucash Gnumeric gnumeric math/gnumeric Abacus abacus deskutils/abacus diff --git a/es_ES.ISO8859-1/books/handbook/eresources/chapter.sgml b/es_ES.ISO8859-1/books/handbook/eresources/chapter.sgml index d86225dfd2..2e5f5fb6ef 100755 --- a/es_ES.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,1792 +1,1794 @@ Recursos en Internet - La velocidad del desarrollo de FreeBSD hace imposible el uso de - medios impresos como forma de seguir los últimos desarrollos. Los recursos - electrónicos son la mejor, y con frecuencia la única, manera de estar - informados de los últimos avances. Dado que FreeBSD es sacado adelante + La velocidad del desarrollo de &os; hace imposible el uso de + medios impresos como forma de seguir los últimos desarrollos. + Los recursos + electrónicos son la mejor, y con frecuencia la única, + manera de estar + informados de los últimos avances. Dado que &os; es sacado adelante mediante el trabajo de voluntarios la propia comunidad de usuarios suele ejercer las funciones de lo que sería un departamento de soporte técnico, siendo el correo electrónico y USENET la manera más efectiva de contactar con esa comunidad. - Las formas de contacto con la comunidad de usuarios de FreeBSD están + Las formas de contacto con la comunidad de usuarios de &os; están detalladas a continuación. Si usted sabe de algún otro medio que no figure aquí envíelo por favor a &a.doc;para que pueda ser incluída. - Listas de Correo + Listas de correo - Aunque la práctica totalidad de los desarrolladores de FreeBSD + Aunque la práctica totalidad de los desarrolladores de &os; léen USENET no podemos garantizar de modo rotundo que recibiremos sus dudas rápidamente (o siquiera que las recibamos) si usted las envía a uno de los grupos de comp.unix.bsd.freebsd.*. Enviando sus dudas a la lista de correo apropiada cumplirá dos objetivos, llegar a los desarrolladores y a una audiencia específica, lo que le asegurará la mejor (o al menos la más rápida) respuesta. Las normas de las diversas listas están al principio de éste documento. Por favor, léa las normas antes de suscribirse o enviar correo a ninguna lista. Muchos suscriptores de nuestras listas reciben varios cientos de mensajes relacionados con - FreeBSD cada día y estableciendo las normas de uso de las listas + &os; cada día y estableciendo las normas de uso de las listas intentamos mantener alto el interés de los mensajes que en ella circulan. Bajarlo haría fallar a las listas de correo como un medio de comunicación efectivo para el proyecto. Todas las listas de correo son archivadas y se pueden hacer búsquedas - en ellas desde el servidor WWW de FreeBSD usando + en ellas desde el servidor WWW de &os; usando éste enlace. El archivo ofrece la posibilidad de usar palabras clave, lo que lo convierte en una excelente manera de buscar respuestas a preguntas frecuentes y debería ser consultado antes de enviar ninguna duda. - Índice de Listas + Índice de listas - Listas Generales:Las siguientes son listas + Listas generales:Las siguientes son listas generales de suscripción libre (y muy recomendable): Lista Propósito cvs-all Cambios realizados en el árbol de código de FreeBSD freebsd-advocacy Proselitismo de FreeBSD freebsd-announce Sucesos importantes e hitos del proyecto freebsd-arch Debates de arquitectura y diseños freebsd-bugs Informes de errores freebsd-chat Temas no técnicos relacionados con la comunidad FreeBSD. freebsd-config Desarrollo de herramientas de instalación y configuración de FreeBSD freebsd-current Debates acerca del uso de FreeBSD-current freebsd-isp Consultas de Proveedores de Servicios de Internet que usan FreeBSD freebsd-jobs Oportunidades de trabajo y consultoría bajo FreeBSD freebsd-newbies Actividades y discusiones de nuevos usuarios de FreeBSD freebsd-policy Decisiones estratégicas del Core Team de FreeBSD. Bajo volumen y sólo lectura freebsd-questions Preguntas de usuarios y soporte técnico freebsd-stable Debates acerca del uso de FreeBSD-stable freebsd-test Un sitio al que mandar sus mensajes de prueba en lugar de a una de las demás listas Listas Técnicas: Las siguientes listas son para debates técnicos. Debería leer cuidadosamente las normas de cada lista antes de suscribirse o enviar correos, dado que hay normas estrictas en cuanto a su uso y contenidos. Lista Propósito freebsd-afs Porte de AFS a FreeBSD freebsd-alpha Porte FreeBSD a Alpha freebsd-arm Porte de FreeBSD para procesadores ARM freebsd-atm Uso de redes ATM con FreeBSD freebsd-audit Proyecto de auditoría del código fuente freebsd-binup Diseño y desarrollo del sistema de actualización binaria freebsd-cluster Uso de FreeBSD en entornos cluster freebsd-database Debates sobre uso de bases de datos y su desarrollo bajo FreeBSD freebsd-doc Creación de documentación sobre FreeBSD freebsd-emulation Emulación de otros sistemas como Linux/DOS/Windows freebsd-firewire Debates técnicos sobre Firewire (iLink, IEEE 1394) freebsd-fs Sistemas de ficheros freebsd-hackers Debates técnicos generales freebsd-hardware Debates generales sobre harware y su uso en FreeBSD freebsd-i18n Internacionalización de FreeBSD freebsd-ia64 Porte de FreeBSD a los próximos sistemas IA64 de Intel freebsd-ipfw Debates técnicos sobre el rediseño del código del cortafuegos IP freebsd-isdn Desarrolladores de RDSI freebsd-java Desarrolladores de Java y personas portando los JDK a FreeBSD freebsd-libh La segunda generación del sistema de instalación y paquetes freebsd-mobile Debates sobre equipos portátiles freebsd-mozilla Porte de mozilla a FreeBSD freebsd-multimedia Aplicaciones multimedia freebsd-new-bus Debates técnicos sobre la arquitectura de bus freebsd-net Debates sobre el código fuente de Redes y TCP/IP freebsd-platforms Específica sobre plataformas de arquitectura no Intel freebsd-ports Debates sobre la colección de ports freebsd-ppc Porte de FreeBSD a PowerPC freebsd-qa Debates sobre Control de Calidad, generalmente al salir una nueva release freebsd-realtime Desarrollo de extensiones en tiempo real en FreeBSD freebsd-scsi El subsistema SCSI freebsd-security Temas de seguridad freebsd-security-notifications Avisos de seguridad freebsd-small Uso de FreeBSD en aplicaciones embebidas freebsd-smp Debates sobre diseño de Multiproceso [A]Simétrico freebsd-sparc Porte de FreeBSD a sistemas Sparc freebsd-standards Cumplimiento de las normas C99 y POSIX en FreeBSD freebsd-tokenring Soporte de Token Ring en FreeBSD Listas limitadas:Las siguientes listas son para una audiencia más especializada (e interesada)y probablemente no son de interés para el público en general. Es una buena idea tener una presencia estable en las listas técnicas antes de suscribirse a alguna de las limitadas, de modo que se pueda entender la etiqueta de la comunicación que en ellas se usa. Lista Propósito freebsd-core FreeBSD Core Team freebsd-hubs Mantenimiento de mirrors (mantenimiento de infraestructuras) freebsd-install Desarrollo de la Instalación freebsd-user-groups Coordinación de grupos de usuarios freebsd-www Mantenimiento de www.FreeBSD.org Listas Compendio:La mayoría de las listas citadas son accesibles como compendio. Los nuevos mensajes enviados a la lista son guardados y enviados como un único correo cuando el archivo llega a un tamaño cercano a los 100 Kb. Las listas accesibles como compendio son: Lista freebsd-afs-digest freebsd-alpha-digest freebsd-chat-digest freebsd-current-digest freebsd-cvs-all-digest freebsd-database-digest freebsd-hackers-digest freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest Listas CVS:Las siguientes listas son para gente interesada en llevar un seguimiento de los mensajes en el registro para conocer los cambios hechos en las diferentes áreas del árbol de código fuente. Son listas de sólo lectura y no se debe enviar correo a ellas. Lista Área de código Descripción de área de código (código fuente) cvs-all /usr/src Todos los cambios al árbol de código (superconjunto) Cómo suscribirse Todas las listas de correo están en FreeBSD.org, de manera que para enviar correo a la lista nombredelista simplemente hay que escribir a <nombredelista@FreeBSD.org>. Desde ahí será redistribuído a los miembros de la lista de correo a lo largo y ancho del mundo. Para suscribirse a una lista envíe un correo a &a.majordomo; incluyendo subscribe <listname> [<optional address>] en el cuerpo del mensaje. Por ejemplo, para suscribirse a freebsd-announce usted haría esto: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D Si quisiera suscribirse bajo otro nombre o enviar una petición de suscripción para una lista de correo local (un sistema muy eficiente si dispone de varias personas interesadas que tengan cuentas de correo en un mismo servidor ¡esto nos facilita mucho el trabajo!) ésto es lo que debe hacer: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@ejemplo.com ^D Por último, también es posible desuscribirse de una lista, obtener una lista de los suscriptores de una lista u obtener una lista de las listas de correo disponibles enviando otro tipo de mensajes de control a majordomo. Para obtener una lista - completa de los comandos disponibles haga esto: + completa de las órdenes disponibles haga esto: &prompt.user; mail majordomo@FreeBSD.org help ^D De nuevo quisiéramos pedirle que procure mantener los debates de las listas técnicas dentro de temas técnicos. Si lo único que usted quiere es recibir avisos importantes le sugerimos que se suscriba a freebsd-announce, que está pensada para tener un tráfico muy bajo. Normas de las listas Todas las listas de correo de FreeBSD tienen ciertas normas elementales que han de ser respetadas por cualquiera que las use. Quien no se atenga a ellas recibirá hasta dos (2) advertencias escritas del Postmaster de FreeBSD postmaster@FreeBSD.org, después de las cuales, a la tercera falta, el suscriptor será borrado de todas las listas de correo de FreeBSD y filtrado para evitar futuros envíos. Lamentamos que esas normas y medidas sean necesarias, pero la Internet de hoy es, según parece, un entorno bastante conflictivo, y mucha gente no se da cuenta de cuán frágiles son algunos de sus mecanismos. Normas a respetar: El tema de cualquier envío debe atenerse al fin básico de la lista a la que se escribe, esto es, si la lista es sobre temas de debate técnico sus envíos deberían versar sobre temas técnicos. Enviar mensajes irrelevantes o insultos sólo sirve para deteriorar el valor de la lista de correo para sus miembros y no será tolerado. Para discusiones libres sin un tema en particular está la lista de correo freebsd-chat freebsd-chat@FreeBSD.org, que es libremente accesible y hecha para éste propósito. No se debería enviar el mismo mensaje a más de dos listas, y sólamente a 2 cuando exista una necesidad manifiesta de escribir a ambas listas. Hay una gran cantidad de personas suscritas a más de una lista y excepto para las mezclas más esotéricas (digamos "-stable & -scsi") no hay razón para enviar un mensaje a más de una lista al mismo tiempo. Si le envían un mensaje en el que aparecen múltiples listas de correo en la línea "Cc" de la cabecera, dicha línea debe ser recortada antes de que envíe una respuesta. Usted es el responsable de sus propios envíos cruzados, independientemente de quién fuese el remitente original. No están admitidos los ataques personales ni la blasfemia (dentro del contexto o como argumento) y eso incluye tanto a usuarios como a desarrolladores. Violaciones graves de la netiqueta, como reenviar o extractar mensajes privados sin permiso ni visos de tenerlo, está mal visto, aunque no prohibido específicamente. Sin embargo, hay pocos casos en los que algo así encaje en la temática de una lista, por lo cual lo más probable es recibir una advertencia (o ser expulsado) tan sólo a causa de ello. El anuncio de productos o servicios no relacionados con FreeBSD están estrictamente prohibidas y conllevarán la inmediata expulsión de la lista si queda demostrado que el autor está practicando el spam o envío de correo no solicitado. Normas de las listas individuales: FREEBSD-AFS Sistema de Ficheros Andrew Ésta lista es para debates sobre el porte y uso de AFS, de CMU/Transarc FREEBSD-ANNOUNCE Sucesos importantes / hitos Ésta es la lista de correo para gente interesada en recibir exclusivamente avisos de sucesos importantes dentro de FreeBSD. Ésto incluye anuncios sobre SNAPSHOTS y otras versiones. Puede incluír también peticiones de voluntarios, etc. Es una lista de bajo volumen y estrictamente moderada. FREEBSD-ARCH Debates sobre arquitectura y diseño Ésta lista es para debates sobre la arquitectura de FreeBSD. Los mensajes deberían mantenerse dentro del ámbito técnico para el que fué creada la lista. Serían ejemplos de temas aptos para ésta lista: Como reorganizar el sistema de construcción ("build") para poder tener varios procesos de construcción personalizados funcionando simultáneamente. Qué se necesita arreglar en el VFS para que funcionen las capas de Heidemann. Cómo cambiar el dispositivo de control de interfaces para que sea posible utilizar los mismos controladores directamente en la mayoría de los buses y arquitecturas. Cómo escribir un controlador de red. FREEBSD-AUDIT Proyecto de auditoría del código fuente Ésta es la lista de correo del proyecto de auditoría del código fuente de FreeBSD. Aunque en principio fué puesta en marcha para cambios motivados por la seguridad su ámbito fué ampliado a la revisión de cualquier cambio en el código. En ésta lista circula una gran cantidad de parches y probablemente no sea de interés para el típico usuario de FreeBSD. Las discusiones de seguridad que no estén relacionadas con una parte específica del código deben tener lugar en freebsd-security. Por otra parte se ruega a todos los desarrolladores que envíen sus parches a ésta lista para su revisión, especialmente si atañen a una parte del sistema donde un error pudiera afectar seriamente a la integridad del sistema. FREEBSD-BINUP Proyecto de Actualización Binaria de FreeBSD Ésta lista existe para facilitar el debate sobre el sistema de actualizacion binaria o binup. Características de diseño, detalles de implementación, parches, informes de error, informes de estado, peticiones de características, commit logs y en general todo lo relacionado con binup es bienvenido. FREEBSD-BUGS Informe de errores Ésta es la lista de correo para informar de errores en FreeBSD. Siempre que sea posible los - errores deberían ser enviados usando el comando + errores deberían ser enviados mediante &man.send-pr.1; o el interfaz WEB FREEBSD-CHAT Temas no técnicos relacionados con la comunidad FreeBSD Ésta lista contiene todos los mensajes sobre información no técnica y social, contenidos que no tienen cabida en las demás listas. Eso incluye discusiones sobre si Julio Iglesias parece una gárgola, sobre si escribir o no en mayúsculas, quién está bebiendo demasiado café, dónde se elabora la mejor cerveza, quién está fabricando cerveza en su sótano y así sucesivamente. Pueden hacerse anuncios sobre actos importantes (como próximas fiestas, congresos, bodas, nacimientos, nuevos trabajos, etc.), pero las respuestas deben ser dirigidas a ésta misma lista. FREEBSD-CORE FreeBSD Core Team Ésta es la lista de correo interna para uso de los miembros del Core Team. Los mensajes pueden ser enviados a ésta lista cuando un problema serio relacionado con FreeBSD necesite un estudio o arbitraje de alto nivel. FREEBSD-CURRENT Debates sobre el uso de FreeBSD-current Ésta es la lista de correo para usuarios de freebsd-current. Esto incluye advertencias sobre nuevas características a ser incluídas en -current que afecten a todos los usuarios e instrucciones paso por paso que deben ser seguidas para mantener una instalación -current. Cualquier usuario de current debería suscribirse a ésta lista. Ésta es una lista de correo técnica en la que se esperan contenidos estrictamente técnicos. FREEBSD-CURRENT-DIGEST Debates sobre el uso de FreeBSD-current Éste es el compendio de la lista freebsd-current. Consiste en que todos los mensajes enviados a freebsd-current son empaquetados y enviados periódicamente como un solo mensaje. Ésta lista es de Sólo-Lectura y no debería recibir correo. FREEBSD-DOC Proyecto de Documentación Ésta lista de correo está destinada a discusiones relacionadas con cuestiones y proyectos relacionados con la creación de documentación de FreeBSD. Los miembros de ésta lista son llamados El Proyecto de Documentación de FreeBSD. La lista es abierta; ¡suscríbase y contribuya!. FREEBSD-FIREWIRE Firewire (iLink, IEEE 1394) Ésta lista de correo es para debates sobre diseño e implementación del subsistema Firewire(también conocido como IEEE o iLink) en FreeBSD. Los temas incluyen de modo específico los standards, dispositivos de bus y sus protocolos, adaptación de placas base, tarjetas y chips y la arquitectura e implementación de código para soporte nativo. FREEBSD-FS Sistemas de ficheros Debates acerca del sistema de ficheros de FreeBSD. Ésta es una lista de correo técnica en la que se espera un contenido estríctamente técnico. FREEBSD-GNOME GNOME Debates acerca del Entorno de Escritorio GNOME para sistemas de ficheros FreeBSD. Ésta es una lista de correo técnica en la que se espera un contenido estrictamente técnico. FREEBSD-IPFW Cortafuegos IP Éste es el foro de discusión técnica dedicado al rediseño del código del cortafuegos IP de FreeBSD. Ésta es una lista de correo técnica en la que se espera un contenido exclusivamente técnico. FREEBSD-IA64 Porte de FreeBSD a IA64 Ésta es una lista de correo técnica para personas que están trabajando en el porte de FreeBSD a la plataforma IA-64 de Intel, para intercambiar problemas y soluciones alternativas. Cualquier persona interesada en seguir las discusiones técnicas es bienvenida. FREEBSD-ISDN Comunicaciones RDSI Ésta es la lista de correo para quienes participan en el desarrollo del soporte RDSI para FreeBSD. FREEBSD-JAVA Desarrollo Java Ésta es la lista de correo sobre el desarrollo de aplicaciones Java importantes para FreeBSD y el porte y mantenimiento de los JDK. FREEBSD-HACKERS Debates técnicos Éste es un foro de debate técnico relacionado con FreeBSD. Ésta es la lista de correo técnica primaria. Es para personas que están trabajando en FreeBSD, solucionando problemas o para discutir soluciones alternativas. Las personas interesadas en seguir las discusiones técnicas también son bienvenidas. Ésta es una lista de correo técnica en la cual se espera un contenido estrictamente técnico. FREEBSD-HACKERS-DIGEST Technical discussions Éste es el compendio de la lista de correo freebsd-hackers. Consiste en que todo el correo enviado a freebsd-hackers es empaquetado y enviado en un sólo mensaje. Ésta lista es de Sólo Lectura y no se debería enviar correo a ella. FREEBSD-HARDWARE Discusiones generales sobre hardware y FreeBSD Discusiones generales sobre tipos de hardware que funciona en FreeBSD, diferentes problemas y sugerencias sobre qué comprar y qué no. FREEBSD-HUBS Réplicas Avisos y discusiones para personas que administran sitios réplica. FREEBSD-INSTALL Discusiones sobre la instalación Ésta lista de correo es para discusiones sobre el desarrollo de la instalación de FreeBSD en próximas versiones. FREEBSD-ISP Cuestiones de Proveedores de Servicios de Internet Ésta lista de correo es para debates sobre temas relevantes para Proveedores de Servicios de Internet (ISP) que usan FreeBSD. Es una lista de correo técnica y en ella se esperan contenidos estríctamente técnicos. FREEBSD-NEWBIES Debates sobre actividades de los novatos Cubrimos todas las actividades de los novatos que no quedan cubiertas por ninguna de las otras, incluyendo: aprendizaje autodidacta y técnicas de resolución de problemas, búsqueda y uso de recursos y peticiones de ayuda, cómo usar las listas de correo y qué lista usar, charla en general, meter la pata, jactarse, compartir ideas, historias, soporte moral (pero no técnico) e implicación en la comunidad FreeBSD. Usamos freebsd-questions para enviar nuestros problemas y peticiones de soporte y usamos freebsd-newbies para conocer a gente que está haciendo lo mismo que nosotros cuando éramos novatos. FREEBSD-PLATFORMS Porte a plataformas no Intel Cuestiones sobre plataformas diversas, debates generales, y propuestas para portes de FreeBSD para plataformas no Intel. Es una lista de correo técnica y en ella se esperan contenidos estríctamente técnicos. FREEBSD-POLICY Decisiones de funcionamiento interno del Core Team Es una lista de sólo lectura y bajo volumen destinada a la toma de decisiones de funcionamento interno del Core Team de FreeBSD. FREEBSD-PORTS Debates sobre ports Debates acerca de la colección de ports (/usr/ports)de FreeBSD, propuestas de aplicaciones a portar, modificaciones a la infraestructura de ports y coordinación general de esfuerzos. Ésta es una lista de correo técnica en la cual se esperan contenidos exclusivamente técnicos. FREEBSD-QUESTIONS Preguntas de los usuarios Ésta es la lista de correo para preguntas sobre FreeBSD. No debería enviar preguntas del estilo de cómo hacer a las listas técnicas salvo que el contenido sea claramente técnico. FREEBSD-QUESTIONS-DIGEST Preguntas de los usuarios Éste es el compendio de la lista de correo freebsd-questions. Consiste en que todos los mensajes enviados a freebsd-questions son empaquetados y enviados en un único mensaje. FREEBSD-SCSI Subsistema SCSI Ésta es la lista de correo para la gente que está trabajando en el subsistema SCSI de FREEBSD. Ésta es una lista de correo técnica en la cual se esperan contenidos puramente técnicos. FREEBSD-SECURITY Cuestiones de seguridad Cuestiones de seguridad informática (DES, Kerberos, problemas de seguridad conocidos y sus soluciones, etc.) Ésta es una lista de correo técnica en la que se esperan contenidos puramente técnicos. FREEBSD-SECURITY-NOTIFICATIONS Avisos de seguridad Avisos de problemas de seguridad en FreeBSD y sus soluciones. Ésta no es una lista de discusión. La lista de discusión es freebsd-security. FREEBSD-SMALL Uso de FreeBSD en aplicaciones embebidas En ésta lista se debaten temas relacionados con instalaciones de FreeBSD inusualmente pequeñas y embebidas. Ésta es una lista de correo técnica en la cual se esperan contenidos estrictamente técnicos. FREEBSD-STABLE Debates sobre el uso de FreeBSD-stable Ésta es la lista de correo para los usuarios de freebsd-stable. Incluye avisos sobre nuevas características a incluír en -stable que afectan a los usuarios e instrucciones paso por paso para permanecer usando la versión -stable. Cualquiera que utilice FreeBSD stable debería suscribirse a ésta lista. Ésta es una lista técnica en la que se esperan contenidos puramente técnicos. FREEBSD-STANDARDS Cumplimiento de C99 & POSIX Éste es el foro para debates técnicos relacionadas con el Cumplimiento de las normas C99 y POSIX en FreeBSD. FREEBSD-USER-GROUPS Lista de coordinación de de grupos de usuarios Ésta es la lista de correo de los coordinadores de los grupos locales de usuarios para discutir cuestiones entre ellos o con personas elegidas del Core Team. Ésta lista de correo debería estar limitada a resúmenes de reuniones y coordinación de proyectos que atañen a los Grupos de Usuarios. FREEBSD-VENDORS VENDORS Debates para la coordinación entre el Proyecto FreeBSD y Distribuidores de software y hardware para FreeBSD. - Grupos de Noticias de Usenet + Grupos de noticias de Usenet Además de los dos grupos de noticias específicos de FreeBSD hay muchos otros en los cuales se habla sobre FreeBSD o son de algún modo interesantes para usuarios de FreeBSD.Hay un archivo donde hacer búsquedas donde pueden encontrarse algunos de esos grupos de noticias por cortesía de Warren Toomey wkt@cs.adfa.edu.au. - Grupos de Noticias Específicos sobre BSD + Grupos de noticias específicos sobre BSD comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc - Otros Grupos de Noticias Interesantes sobre Unix + Otros grupos de noticias interesantes sobre Unix comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd Sistema X Window comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Servidores WWW http://www.FreeBSD.org/ — Servidor Central. http://www.au.FreeBSD.org/ — Australia/1. http://www2.au.FreeBSD.org/ — Australia/2. http://www3.au.FreeBSD.org/ — Australia/3. http://freebsd.itworks.com.au/ — Australia/4. http://www.br.FreeBSD.org/www.freebsd.org/ — Brasil/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — Brasil/2. http://www3.br.FreeBSD.org/ — Brasil/3. http://www.bg.FreeBSD.org/ — Bulgaria. http://www.ca.FreeBSD.org/ — Canadá/1. http://www2.ca.FreeBSD.org/ — Canadá/2. http://www3.ca.FreeBSD.org/ — Canadá/3. http://www.cn.FreeBSD.org/ — China. http://www.cz.FreeBSD.org/ — República Checa. http://www.dk.FreeBSD.org/ — Dinamarca. http://www.ee.FreeBSD.org/ — Estonia. http://www.fi.FreeBSD.org/ — Finlandia. http://www.fr.FreeBSD.org/ — Francia. http://www.de.FreeBSD.org/ — Alemania/1. http://www1.de.FreeBSD.org/ — Alemania/2. http://www2.de.FreeBSD.org/ — Alemania/3. http://www.gr.FreeBSD.org/ — Grecia. http://www.hu.FreeBSD.org/ — Hungría. http://www.is.FreeBSD.org/ — Islandia. http://www.ie.FreeBSD.org/ — Irlanda. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japón. http://www.kr.FreeBSD.org/ — Corea/1. http://www2.kr.FreeBSD.org/ — Corea/2. http://www.lv.FreeBSD.org/ — Letonia. http://rama.asiapac.net/freebsd/ — Malasia. http://www.nl.FreeBSD.org/ — Holanda/1. http://www2.nl.FreeBSD.org/ — Holanda/2. http://www.no.FreeBSD.org/ — Noruega. http://www.nz.FreeBSD.org/ — Nueva Zelanda. http://www.pl.FreeBSD.org/ — Polonia/1. http://www2.pl.FreeBSD.org/ — Polonia/2. http://www.pt.FreeBSD.org/ — Portugal/1. http://www2.pt.FreeBSD.org/ — Portugal/2. http://www3.pt.FreeBSD.org/ — Portugal/3. http://www.ro.FreeBSD.org/ — Rumanía. http://www.ru.FreeBSD.org/ — Rusia/1. http://www2.ru.FreeBSD.org/ — Rusia/2. http://www3.ru.FreeBSD.org/ — Rusia/3. http://www4.ru.FreeBSD.org/ — Rusia/4. http://freebsd.s1web.com/ — Singapur. http://www.sk.FreeBSD.org/ — República Eslovaca. http://www.si.FreeBSD.org/ — Eslovenia. http://www.es.FreeBSD.org/ — España. http://www.za.FreeBSD.org/ — Sudáfrica/1. http://www2.za.FreeBSD.org/ — Sudáfrica/2. http://www.se.FreeBSD.org/ — Suecia. http://www.ch.FreeBSD.org/ — Suiza. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — Taiwan. http://www.tr.FreeBSD.org/ — Turquía. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ucrania/1. http://www2.ua.FreeBSD.org/ — Ucrania/2. http://www4.ua.FreeBSD.org/ — Ucrania/Crimea. http://www.uk.FreeBSD.org/ — Reino Unido/1. http://www2.uk.FreeBSD.org/ — Reino Unido/2. http://www3.uk.FreeBSD.org/ — Reino Unido/3. http://www6.FreeBSD.org/ — USA/Oregón. http://www2.FreeBSD.org/ — USA/Tejas. - Direcciones de Correo Electrónico + Direcciones de correo electrónico Los siguientes grupos de usuarios de FreeBSD provéen a sus miembros de direcciones de correo. Dichos administradores se reservan el derecho de retirar el uso de la dirección si se abusa de ella de cualquier manera. Dominio Recursos que se suministran Grupo de Usuarios Administrador ukug.uk.FreeBSD.org Sólo redirección freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org - Cuentas Shell + Cuentas shell Los siguientes grupos de usuarios facilitan cuentas shell a gente que apoya activamente el proyecto FreeBSD. Sus respectivos administradores se reservan el derecho de cancelar la cuenta y si se abusa de ella de algún modo. Servidor Tipo de acceso Servicios que se ofrecen Administrador storm.uk.FreeBSD.org SSH only CVS de sólo lectura, espacio web personal, correo electrónico &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH Correo electrónico, espacio web, FTP Anónimo Lee Johnston lee@uk.FreeBSD.org diff --git a/es_ES.ISO8859-1/books/handbook/introduction/chapter.sgml b/es_ES.ISO8859-1/books/handbook/introduction/chapter.sgml index 95e4f40bf3..14d2d217ed 100755 --- a/es_ES.ISO8859-1/books/handbook/introduction/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/introduction/chapter.sgml @@ -1,969 +1,997 @@ Jim Mock Restructured, reorganized, and parts rewritten by Introducción Sinopsis - ¡Gracias por tu interés en FreeBSD! El siguiente - capítulo trata varios temas relativos al Proyecto FreeBSD, como + ¡Gracias por su interés en FreeBSD! El siguiente + capítulo trata varios temas relativos al Proyecto &os;, como su historia, objetivos, modelo de desarrollo, etc. - Después de leer este capítulo sabrás: + Después de leer este capítulo sabrá: - Qué relación guarda FreeBSD con otros sistemas + Qué relación guarda &os; con otros sistemas operativos. - La historia del Proyecto FreeBSD. + La historia del Proyecto &os;. - Los objetivos del Proyecto FreeBSD. + Los objetivos del Proyecto &os;. Los fundamentos del modelo de desarrollo de código - abierto de FreeBSD. + abierto de &os;. Y por supuesto: de dónde procede el nombre FreeBSD. ¡Bienvenido a FreeBSD! 4.4BSD-Lite - FreeBSD es un sistema operativo basado en 4.4BSD-Lite para + &os; es un sistema operativo basado en 4.4BSD-Lite para ordenadores Intel (x86 e &itanium;), AMD64, Alpha y Sun &ultrasparc;. Se está - trabajando también en versiones para otras arquitecturas. + trabajando también en versiones para otras arquitecturas. También puede leer sobre la historia de FreeBSD, o sobre la distribución actual. Si está interesado en contribuir de algún modo al proyecto (código, hardware, billetes sin marcar), mire el artículo Contribuír a FreeBSD. ¿Qué puede hacer FreeBSD? FreeBSD tiene muchas características notables. Algunas de ellas son: preemptive multitasking Multitarea expropiativa con prioridades dinámicamente ajustadas para asegurar que distintas aplicaciones y usuarios compartan el ordenador de un modo equitativo, incluso bajo la mayor de las cargas. multi-user facilities Servicios multiusuario que permiten a mucha gente usar un sistema FreeBSD simultáneamente para distintas cosas. Ésto significa, por ejemplo, que los periféricos del sistema como impresoras y dispositivos de cinta son compartidos adecuadamente por varios usuarios del sistema o la red, y que pueden establecerse límites sobre recursos concretos para usuarios o grupos de usuarios, protegiendo los recursos críticos del sistema de un uso abusivo. TCP/IP networking Conexión de redes TCP/IP muy robusta, con soporte para estándares industriales como SLIP, PPP, NFS, DHCP, y NIS. Esto quiere decir que su máquina FreeBSD puede interoperar fácilmente con otros sistemas y hacer de servidor en una empresa, proporcionando importantes funciones como NFS (acceso a ficheros remotos) y servicios de correo electrónico, o poniendo a tu organización en Internet con WWW, FTP, servicios de enrutado y cortafuegos. memory protection La protección de memoria garantiza que las aplicaciones (o los usuarios) no pueden interferirse. Un error fatal en una aplicación no afecta al resto. FreeBSD es un sistema operativo de 32-bits (de 64-bits - en Alpha, &itanium, AMD64, y &ultrasparc;) y fue dise�ado + en Alpha, &itanium;, AMD64, y &ultrasparc;) y fue diseñado como tal desde el comienzo. X Window System XFree86 X Window System (X11R6), estándar de la industria, provee a los usuarios una interfaz gráfica (GUI) por el coste de una tarjeta VGA y un monitor comunes, y viene con los fuentes completos. binary compatibility Linux binary compatibility SCO binary compatibility SVR4 binary compatibility BSD/OS binary compatibility NetBSD Compatibilidad binaria con muchos programas nativos de Linux, SCO, SVR4, BSDI y NetBSD. Miles de aplicaciones listas para usarse estan disponibles en Internet. FreeBSD es compatible a nivel de código fuente con la mayoria de sistemas &unix; comerciales por tanto la mayoría de aplicaciones requieren muy pocos o ningún cambio para compilar. Miles de aplicaciones fáciles de portar se encuentran disponibles en Internet. FreeBSD tiene un código fuente compatible con el de los más populares sistemas Unix comerciales y por ello la mayoría de las aplicaciones tan sólo necesitan unos pocos cambios, si es que necesitan alguno, para compilar. virtual memory - El dise�o de la memoria virtual con + El diseño de la memoria virtual con paginación bajo demanda y de la caché unificada de VM/buffer satisface a aplicaciones que requieren grandes cantidades de memoria de forma eficiente aun dando respuestas interactivas a otros usuarios. Symmetric Multi-Processing (SMP) Soporte para SMP en máquinas con múltiples CPUs. compilers C compilers C++ compilers Fortran Una colección completa de herramientas de desarrollo en C, C++, Fortran, y Perl. Muchos más lenguajes adicionales para investigación y desarrollo avanzados se encuentran también disponibles en la colección de ports y paquetes. source code Disponer del código fuente del sistema entero significa contar con el mayor nivel de - control posible sobre su entorno. �Para qué ligarte a - una solución propietaria a la merced de un fabricante + control posible sobre su entorno. ¿Para qué atarse a + una solución propietaria a la merced de un fabricante cuando puede tener un verdadero sistema abierto? Extensa documentación en línea. - �Y mucho más! + ¡Y mucho más! 4.4BSD-Lite Computer Systems Research Group (CSRG) U.C. Berkeley FreeBSD está basado en la versión 4.4BSD-Lite del Computer Systems Research Group (CSRG) de la Universidad de California en Berkeley, y continúa la distinguida tradición de desarrollo de sistemas BSD. Además del excelente trabajo del CSRG, el Proyecto FreeBSD ha invertido miles de horas en ajustar el sistema para conseguir un rendimiento y una fiabilidad máximas en situaciones de carga reales. Mientras que muchos de los gigantes comerciales se esfuerzan en dotar a los sistemas operativos para PCs de esas características, rendimiento y fiabilidad, FreeBSD puede ofrecerlas ¡ya! Las posibles aplicaciones en las que puede usarse FreeBSD están limitadas tan sólo por tu imaginación. Desde desarrollo de programas hasta automatización de fábricas, desde control de inventarios hasta corrección de azimut de antenas de satélites remotos; ¡si puede realizarse con un &unix; comercial lo más seguro es que también pueda llevarse a cabo con FreeBSD!. FreeBSD también se beneficia de las literalmente miles de aplicaciones de alta calidad desarrolladas en centros de investigación y universidades de todo el mundo, frecuentemente - disponibles por poco o ningún coste. También se - dispone de aplicaciones comerciales, cuyo número aumenta - cada día. + disponibles por poco o ningún coste. También + existen aplicaciones comerciales, cuyo número aumenta + cada dia. Dado que el código fuente de FreeBSD está disponible, el sistema puede ser también personalizado en un grado nunca visto para aplicaciones o proyectos especiales, y de maneras generalmente imposibles con los sistemas operativos de la mayoría de los fabricantes comerciales. Aquí damos tan sólo una muestra de aplicaciones en las que se está actualmente usando FreeBSD: Servicios de Internet: La robusta conectividad TCP/IP integrada en FreeBSD hace de este sistema una plataforma ideal para servicios Internet como: FTP servers Servidores FTP web servers Servidores web (estándares o seguros [SSL]) firewall IP masquerading Cortafuegos y pasarelas NAT (enmascaramiento IP). electronic mail email Servidores de correo electrónico USENET USENET y BBSs Y más... Con FreeBSD puede empezar fácilmente con un pequeño y económico PC de tipo 386 e ir actualizando su equipo hasta un tetraprocesador Xeon con - almacenamiento RAID a medida que tu proyecto crezca. + almacenamiento RAID a medida que su proyecto crezca. Educación: ¿Es estudiante de informática o de algún campo relacionado con la ingeniería? No hay mejor modo de estudiar sistemas operativos, arquitectura de computadores y redes que la experiencia a bajo nivel que FreeBSD puede aportar. Para aquéllos cuyo principal interés en los ordenadores no es otro que el de poder realizar su trabajo existe una serie de paquetes gratuitos de CAD, - matemáticas y dise�o gráfico que hacen de FreeBSD un + matemáticas y diseño gráfico que hacen de &os; un sistema verdaderamente útil. Investigación: Encontrándose disponible el código fuente del sistema entero, FreeBSD es una excelente plataforma para la investigación en sistemas operativos y otras ramas de la informática. El hecho de que FreeBSD esté disponible gratuítamente hace posible que grupos remotos puedan colaborar con ideas o compartan desarrollos sin tener que preocuparse de acuerdos en licencias especiales o de limitaciones acerca de lo que puede discutirse en foros públicos. router DNS Server - Redes: ¿Necesitas un nuevo - enrutador? ¿Un servidor de nombres (DNS)? ¿Un - cortafuegos para mantener a la gente fuera de tu red - interna? FreeBSD puede convertir aquel PC 386 o 486 - arrinconado en un enrutador avanzado con - sofisticadas capacidades de filtrado de paquetes - fácilmente. + Redes: ¿Necesita un nuevo + router? + ¿Un servidor de nombres (DNS)? ¿Un + cortafuegos para mantener a la gente fuera de su red + interna? FreeBSD puede convertir su PC 386 o 486 + arrinconado en un router avanzado con + sofisticadas capacidades de filtrado de paquetes. X Window System XFree86 X Window System Accelerated-X Estación de trabajo X: FreeBSD es una magnífica elección como terminal X de bajo coste, ya sea usando el servidor libremente disponible XFree86 o uno de los excelentes servidores comerciales de Xi Graphics. A diferencia de las terminales X, FreeBSD permite ejecutar muchas aplicaciones localmente, si así se quiere, aligerando de este modo la carga soportada por un servidor central. FreeBSD puede incluso arrancar sin disco, permitiendo que las estaciones sean aún más económicas y fáciles de administrar. GNU Compiler Collection Desarrollo de software: El sistema base de FreeBSD viene con una completa colección de herramientas de desarrollo que incluyen el famoso compilador y depurador de C/C++ de GNU. Los fuentes y binarios de FreeBSD están disponibles en CDROM y por FTP anónimo. Por favor, consulte para más información sobre cómo conseguir FreeBSD. ¿Quién usa FreeBSD? users large sites running FreeBSD Algunos de los mayores sitios web de Internet utilizan FreeBSD; he aquí algunos de ellos: Yahoo! Yahoo! Apache Apache Blue Mountain Arts Blue Mountain Arts Pair Networks Pair Networks Sony Japan Sony Japón Netcraft Netcraft Weathernews Weathernews Supervalu Supervalu TELEHOUSE America TELEHOUSE America Sophos Anti-Virus Sophos Anti-Virus JMA Wired JMA Wired y muchos más. Acerca del proyecto FreeBSD En la siguiente sección se explican ciertos aspectos del proyecto, una breve historia, objetivos, y modelo de desarrollo del proyecto. Jordan Hubbard Contributed by Breve historia de FreeBSD 386BSD Patchkit Hubbard, Jordan Williams, Nate Grimes, Rod FreeBSD Project history La génesis del proyecto FreeBSD se remonta a comienzos de 1993, en parte como una extensión del Unofficial 386BSD Patchkit debida a los tres últimos coordinadores del patchkit: Nate Williams, Rod Grimes y yo mismo. 386BSD Nuestro objetivo original era producir una instantánea de 386BSD intermedia para arreglar una serie de problemas que no se - podían solventar vía patchkits. Algunos quizá recuerden que el + podían solventar vía patchkits. + Algunos quizá recuerden que el primer nombre del proyecto fue 386BSD 0.5 o 386BSD Interim en referencia a ese hecho. Jolitz, Bill 386BSD era el sistema operativo de Bill Jolitz, que hasta ese punto había estado sufriendo severamente las consecuencias - de prácticamente un a�o que más vale olvidar. A medida que el - patchkit se iba haciendo más incómodo día a día, nosotros - estuvimos unánimente de acuerdo en que algo se tenía que hacer y + de prácticamente un año que más valdría + olvidar. A medida que el + patchkit se iba haciendo más incómodo día + a día, + estuvimos unánimente de acuerdo en que había + que hacer algo, así que decidimos ayudar a Bill ofreciendo esta instantánea - limpia como ínterin. Aquellos planes fueron - bruscamente interrumpidos cuando Bill Jolitz de repente decidió - retirar su aprobación al proyecto sin ninguna indicación clara - de lo que en su lugar debería hacerse. + limpia como ínterin. Aquellos planes fueron + bruscamente interrumpidos cuando Bill Jolitz de repente decidió + retirar su aprobación al proyecto sin ninguna indicación + clara de lo que debería hacerse. Greenman, David Walnut Creek CDROM No tardamos mucho en decidir que el objetivo seguía valiendo la pena, aun sin el soporte de Bill, y fue así que adoptamos el - nombre FreeBSD, debido a David Greenman. + nombre FreeBSD, debido a David Greenman. Nuestros objetivos iniciales se fijaron una vez consultamos a los usuarios del sistema, y cuando quedó claro que el proyecto - estaba en marcha y que podía llegar a ser una realidad contacté + estaba en marcha y que podía llegar a ser una + realidad contacté con Walnut Creek CDROM con la idea de mejorar los canales de - distribución de FreeBSD para aquellos desafortunados - que no tenian un acceso a Internet. Walnut Creek CDROM no solo - nos ayudo con la idea de distribuir FreeBSD en CD, - también dio al proyecto una máquina en la que - trabajar y una rápida conexión a Internet. + distribución de FreeBSD y así hacer más + fácil el llegar a aquellas personas que no tenían + la suerte de tener acceso a Internet. Walnut Creek CDROM no solo + nos ayudó con la idea de distribuir FreeBSD en CD, + también dio al proyecto una máquina en la que + trabajar y una conexión rápida a Internet. Sin la fe casi sin precedentes que tuvo Walnut Creek CDROM en lo que era por aquel tiempo un proyecto completamente desconocido, es bastante improbable que FreeBSD hubiera logrado - tanto y tan rápido como ha logrado hoy por hoy. + tanto y tan rápido como ha logrado hasta el dia de hoy. 4.3BSD-Lite Net/2 U.C. Berkeley 386BSD Free Software Foundation La primera distribución en CDROM (y disponible por la red) fue FreeBSD 1.0, publicado en diciembre de 1993. Estaba basado en la cinta de U.C. Berkeley del 4.3BSD-Lite (Net/2), con bastantes componentes de 386BSD y la Free Software Foundation. Fue un logro bastante razonable para - una primera versión, y le siguió FreeBSD 1.1 en mayo de 1994, - que tuvo un gran éxito. + una primera versión, y le siguió FreeBSD 1.1 en mayo de + 1994, que tuvo un gran éxito. Novell U.C. Berkeley Net/2 AT&T Por entonces se formaron unos inesperados nubarrones en el - horizonte ya que Novell y U.C. Berkeley resolvieron el largo - juicio acerca del estatus legal de la cinta de Berkeley Net/2. + horizonte ya que Novell y la Universidad de Berkeley resolvieron el + largo juicio acerca del estatus legal de la cinta de Berkeley Net/2. Una condición del acuerdo fue la concesión por parte de - U.C. Berkeley de que una gran parte de Net/2 era código - gravado y propiedad de Novell, quien a su vez lo + Berkeley de que una gran parte de Net/2 era código + gravado y propiedad de Novell, quien a su vez lo había adquirido de AT&T anteriormente. Berkeley obtuvo a cambio de Novell el beneplácito para que 4.4BSD-Lite, cuando saliera, fuera declarado como no-gravado y se instara a los usuarios de Net/2 a cambiar. Esto incluía a FreeBSD, y se dio hasta julio de 1994 para dejar de sacar su propio producto basado en Net/2. Bajo los términos de aquel - acuerdo se le permitía al proyecto sacar una última versión + acuerdo se le permitía al proyecto sacar una última + versión antes de la fecha límite: esa versión fue FreeBSD 1.1.5.1. FreeBSD tuvo entonces que acometer la árdua tarea de literalmente reinventarse a sí mismo a partir de trozos nuevos y bastante incompletos de 4.4BSD-Lite. Las versiones Lite eran ligeras en parte porque el CSRG de Berkeley quitó grandes partes del código necesario para construir un sistema que pudiera arrancar (debido a diversos requisitos legales) y porque la versión del 4.4 para Intel era muy incompleta. No fue hasta noviembre de 1994 que el proyecto - realizó esa transición, en ese punto sacó FreeBSD 2.0 en la red - y en CDROM (a finales de diciembre). A pesar de no estar + realizó esa transición; apareció &os; 2.0 en la red + y en CDROM (a finales de diciembre). A pesar de no estar suficientemente pulida, esta distribución fue un éxito - significativo y le siguió el más robusto y fácil de instalar - FreeBSD 2.0.5 en junio de 1995. + significativo y le siguió el más robusto y fácil + de instalar FreeBSD 2.0.5 en junio de 1995. Sacamos FreeBSD 2.1.5 en Agosto de 1996, y pareció ser suficientemente popular entre ISPs y otras comunidades comerciales como para que mereciera otra versión de la rama - 2.1-STABLE. �sa fue FreeBSD 2.1.7.1, publicada en febrero de - 1997, que marcó el final de la línea principal de desarrollo en + 2.1-STABLE. Fue FreeBSD 2.1.7.1, publicada en febrero de + 1997, que marcó el final de la línea principal de + desarrollo en 2.1-STABLE. Una vez en modo mantenimiento, en esa rama (RELENG_2_1_0) sólo se harían ya mejoras en seguridad y correcciones de errores críticos. - FreeBSD se ramificó desde la línea principal de desarrollo - (-CURRENT) en Noviembre de 1996 como la rama - RELENG_2_2, y la primera versión completa (2.2.1) salió en Abril + FreeBSD se ramificó desde la línea principal de + desarrollo + (-CURRENT) en noviembre de 1996 como la rama + RELENG_2_2, y la primera versión completa (2.2.1) + salió en abril de 1997. Se hicieron más versiones de la rama 2.2 en verano y - Otoño de 1997, la última de las cuales (2.2.8) apareció en - Noviembre de 1998. La primera versión 3.0 oficial salió en - Octubre de 1998 y marcó el inicio del fin de la rama 2.2. - - El árbol se ramificó de nuevo el 20 de Enero de 1999, dando - lugar a las ramas 4.0-CURRENT y 3.X-STABLE. De la 3.X-STABLE, - 3.1 salió el 15 de Febrero de 1999, 3.2 el 15 de Mayo de 1999, - 3.3 el 16 de Septiembre de 1999, 3.4 el 20 de Diciembre de 1999, - y 3.5 el 24 de Junio de 2000, a la que siguió pocos días después + otoño de 1997, la última de las cuales (2.2.8) + apareció en + noviembre de 1998. La primera versión 3.0 oficial salió + en octubre de 1998 y marcó el inicio del fin de la rama 2.2. + + El árbol se ramificó de nuevo el 20 de Enero de 1999, + dando lugar a las ramas 4.0-CURRENT y 3.X-STABLE. De la 3.X-STABLE, + 3.1 salió el 15 de febrero de 1999, 3.2 el 15 de mayo de 1999, + 3.3 el 16 de septiembre de 1999, 3.4 el 20 de diciembre de 1999, + y 3.5 el 24 de Junio de 2000, a la que siguió pocos días + después una actualización menor, la 3.5.1, que incorporaba mejoras de - seguridad de última hora para Kerberos. �sa fue la última + seguridad de última hora para Kerberos. Esa fue la última versión de la rama 3.X. - Hubo otra ramificación el 13 de Marzo de 2000, que dió lugar - a la rama 4.X-STABLE. Han habido varias versiones de la misma desde + Hubo otra ramificación el 13 de Marzo de 2000, que + dió lugar + a la rama 4.X-STABLE. Ha habido varias versiones de la misma desde entonces: 4.0-RELEASE salió en Marzo de 2000, y la má reciente &rel2.current;-RELEASE salió en &rel2.current.date;. Habrá más versiones de la rama 4.X-STABLE (RELENG_4). La largamente esperada 5.0-RELEASE se anunció el 19 - de Enero de 2003. Culminó con casi tres años de - trabajo, esta versión colocó a FreeBSD en el - avanzado camino de multiprocesadores y soporte de hilos para + de enero de 2003, culminando casi tres años de + trabajo; esta versión colocó a FreeBSD en el + avanzado camino del multiproceso y el soporte de hilos para las aplicaciones e introdujo soporte para las plataformas - &ultrasparc; y ia64. Siguio a esta la + &ultrasparc; y ia64. Siguió a esta la versión 5.1 lanzada en Junio de 2003. La última versión de 5.X como la rama -CURRENT fué - 5.2.1-RELEASE, que salió en Febrero de 2004. + 5.2.1-RELEASE, que salió en febrero de 2004. Jordan Hubbard - Contributed by + Texto original de Objetivos del Proyecto FreeBSD FreeBSD Project goals - Los objetivos del Proyecto FreeBSD son proveer software que + Los objetivos del Proyecto FreeBSD son producir software que pueda usarse con cualquier propósito y sin compromiso alguno. Muchos de nosotros participamos significativamente en el código (y en el proyecto) y ciertamente no nos importaría recibir una - peque�a compensación económica de vez en cuando, pero - decididamente no estamos dispuestos a insitir en ello. Creemos - que nuestra más importante y primordial misión es + pequeña compensación económica de vez en cuando, + pero decididamente no estamos dispuestos a insitir en ello. Creemos + que nuestra más importante y primordial + misión es dar código a todo el que venga, y para lo que quiera, de manera que el código sea tan usado y dé tanto provecho como sea posible. Creo que éste es uno de los objetivos más - fundamentales del software libre y uno que nosotros apoyamos con + fundamentales del software libre y algo que nosotros apoyamos con entusiasmo. GNU General Public License (GPL) GNU Lesser General Public License (LGPL) BSD Copyright El código fuente de nuestro árbol que se halla bajo la GNU General Public License (GPL) o la Library General Public License (LGPL) viene con algunas restricciones más, si bien de cara a - garantizar acceso al mismo, no al contrario que es lo habitual. + garantizar acceso al mismo, y no al contrario como es lo habitual. Debido a las complicaciones adicionales que pueden surgir en el uso comercial de software con licencia GPL, preferimos que el - software contribuído lo sea bajo la licencia BSD, menos - estricta, cuando ésa sea una opción razonable. + software contribuído lo sea bajo la licencia BSD, menos + estricta, siempre y cuando sea una opción razonable. Satoshi Asami - Contributed by + Texto de El modelo de desarrollo de FreeBSD FreeBSD Project development model El desarrollo de FreeBSD es un proceso muy abierto y flexible, estando FreeBSD construído literalmente a partir de las contribuciones de centenares de personas de todo el mundo, como puede verse en nuestra lista de contribuidores. La - infreaestructura de desarrollo del proyecto FreeBSD permite a estos - cientos de desarrolladores trabajar a través de Internet. - Estamos constantemente a la búsqueda de nuevos desarrolladores + infraestructura de desarrollo del proyecto FreeBSD permite a estos + cientos de desarrolladores trabajar a través de Internet. + Estamos constantemente a la búsqueda de nuevos desarrolladores e ideas, y aquéllos interesados en vincularse más al proyecto tan sólo tienen que ponerse en contacto con nosotros en &a.hackers;. La lista &a.announce; también se halla disponible para quienes deseen dar a conocer a otros usuarios de FreeBSD grandes áreas de trabajo. Cosas útiles de saber sobre el Proyecto FreeBSD y su - proceso de desarrollo, ya sea trabajando de forma independiente on en + proceso de desarrollo, ya sea trabajando de forma independiente o en estrecha cooperación: El repositorio CVS CVS repository Concurrent Versions System CVS El árbol de código fuente central de FreeBSD se mantiene con CVS (Concurrent Versions System), una herramienta de control de versiones de código fuente que se halla libremente disponible y viene con FreeBSD. El repositorio CVS principal reside en una máquina en Santa Clara - California (EEUU), desde la que es replicado a numerosos mirrors - distribuidos por todo el mundo. El árbol del - CVS, que contiene los árboles mirrors) repartidas por todo el mundo. + El árbol del + CVS que contiene los árboles -CURRENT y - -STABLE, pueden ser - replicados fácilmente en tu máquina - también. Por favor, consulta la sección Sincronización del árbol de código + -STABLE, pueden replicarse + fácilmente también en su máquina + Por favor, consulte la sección Sincronización del + árbol de código fuente para más información sobre cómo hacerlo. La lista de committers committers Los committers son gente que tienen permisos de escritura en el - árbol del CVS, y están por tanto autorizados a realizar + árbol del CVS, y están por tanto autorizados a + realizar modificaciones en los fuentes de FreeBSD (el término - committer viene del comando + committer viene de la orden commit de &man.cvs.1;, que sirve para subir nuevos cambios al repositorio del CVS). La mejor manera de enviar aportaciones para que sean revisadas por - los committers es usar el comando &man.send-pr.1;, aunque - si pareciera que algo va mal en el sistema también puedes + los committers es usar &man.send-pr.1;, aunque + si pareciera que algo va mal en el sistema también puede enviar correo electrónico a &a.committers;. - El core team de FreeBSD + El Core Team de FreeBSD core team - El core team de FreeBSD sería + El Core Team de FreeBSD sería lo equivalente a una junta directiva si el Proyecto - FreeBSD fuese una compa�ía. La principal tarea de este + FreeBSD fuese una compañía. + La principal tarea de este equipo es la de garantizar que el proyecto, como un todo, - tiene salud y sigue las direcciones correctas. Invitar a + tenga salud y sigue las direcciones correctas. Invitar a desarrolladores comprometidos y responsables a unirse a - nuestro grupo de committers es una de las funciones del - core team, así como el reclutamiento de nuevos miembros - del equipo cuando otros se van. El core team fue - elegido de un conjunto de committers candidatos en Julio - de 2004. Se celebran elecciones cada 2 a�os. - - Algunos miembros del core team tienen también áreas + nuestro grupo de committers es otra de las funciones del + Core Team, así como el reclutamiento de nuevos miembros + del equipo cuando otros se van. El Core Team fue + elegido de un conjunto de committers candidatos en julio + de 2004. Se celebran elecciones cada 2 años. + + Algunos miembros del Core Team tienen también + áreas de responsabilidad específicas, en cuanto a que se encargan de garantizar que cierta parte extensa del - sistema funciona según lo previsto. Hay una lista + sistema funcione según lo previsto. Hay una lista completa de desarrolladores de FreeBSD con sus áreas de - responsabilidad respectivas, consulta la Lista de + responsabilidad respectivas en la Lista de contribuidores. - La mayoría de los miembros del core team son + La mayoría de los miembros del Core Team son voluntarios a la hora de desarrollar FreeBSD y no se benefician económicamente del proyecto, por ello compromiso no debería confundirse con soporte garantizado. La anterior analogía de la junta directiva en realidad no es del todo exacta, quizá fuera más acertado decir que ésa es la gente que dedica su vida a FreeBSD ¡en contra de lo que les aconseja su propio - juicio! + sentido común! Contribuidores externos contribuidores - Por último, y no por ello menos importante, el mayor + Por último y no por ello menos importante, el mayor grupo de desarrolladores está formado por los mismos usuarios, quienes constantemente aportan comentarios y - corrección de errores. La principal manera de estar en - contacto con el más descentralizado desarrollo de FreeBSD - es suscribirse a &a.hackers; que es donde se discuten - ese tipo de cosas. Mire para + corrección de errores. La mejor manera de estar en + contacto con el desarrollo de FreeBSD + es suscribirse a &a.hackers;, que es donde se discuten + ese tipo de cosas. Consulte para mas información sobre las diferentes listas de correo de FreeBSD.. La lista de contribuidores es larga y no cesa de crecer, así que ¿por qué no apuntarse y contribuir algo a FreeBSD hoy mismo? Aportar código no es la única manera de - contribuir al proyecto; tienes un lista más completa de - cosas que hay que hacer en el + contribuir al proyecto; hay un lista más completa de + tareas pendientes en el sitio web del Proyecto FreeBSD. En resumen, nuestro modelo de desarrollo está organizado como un conjunto de círculos concéntricos. El modelo - centralizado está dise�ado para conveniencia de los - usuarios de FreeBSD, que así tienen un modo + centralizado está diseñado pensando el la comodidad + de los usuarios de FreeBSD, que así tienen un modo sencillo de estar al día con una base de código central, ¡no para excluir a contribuidores potenciales!. Nuestro deseo es presentar un sistema operativo estable con un gran conjunto de aplicaciones coherentes que los - usuarios puedan instalar y usar fácilmente — este modelo - funciona bien para lograrlo. + usuarios puedan instalar y usar fácilmente (y este modelo + da buenos resultados en este sentido) Lo único que pedimos a quienes quisieran unirse a nosotros como desarrolladores de FreeBSD es la misma dedicación que los integrantes actuales tienen para mantener su éxito. La actual distribución FreeBSD NetBSD OpenBSD 386BSD Free Software Foundation U.C. Berkeley Computer Systems Research Group (CSRG) FreeBSD está libremente disponible, todo el código fuente de la distribución basada en 4.4BSD-Lite para sistemas bajo Intel &i386;, &i486;, &pentium;, &pentium; Pro, &celeron;, &pentium; II, &pentium; III, &pentium; III, &pentium;4 (o compatible), &xeon;, DEC Alpha y sistemas basados en SUN &ultrasparc;. Está principalmente basado en software - del grupo CSRG de U.C. Berkeley, con algunas mejoras + del grupo CSRG de la universidad de Berkeley (California), + con algunas mejoras provenientes de NetBSD, OpenBSD, 386BSD, y la Free Software Foundation. Desde la versión 2.0 de FreeBSD de finales del 94, el rendimiento, conjunto de funcionalidades, y estabilidad del sistema han mejorado drásticamente. El último cambio consiste - en un redise�o del sistema de memoria virtual con una caché - unificada de VM/buffer que no sólo aumenta el rendimiento, sino - que también reduce el consumo de memoria de FreeBSD, haciendo + en un rediseño del sistema de memoria virtual con una + caché + unificada de VM/buffer que no solo aumenta el rendimiento, sino + que reduce el consumo de memoria de FreeBSD, haciendo que una configuración de 5 MB sea un mínimo más aceptable. Otras mejoras incluyen soporte completo para clientes y servidores NIS, soporte para transacciones TCP, llamada bajo demanda PPP, soporte para DHCP integrado, un subsistema SCSI mejorado, soporte para ISDN (RDSI), soporte para ATM, FDDI, adaptadores Fast y Gigabit Ethernet (1000 Mbit), soporte mejorado para los últimos controladores Adaptec, y cientos de correcciones de errores. Además de las distribuciones base, FreeBSD ofrece una colección de software con miles de programas comúnmente solicitados. ¡En el momento de escribir esto hay unos &os.numports; ports! La lista de ports comprende desde servidores HTTP (WWW), juegos, lenguajes, editores, y - prácticamente cualquier cosa intermedia. La colección de ports + prácticamente cualquier cosa intermedia. + La colección de ports completa requiere un espacio de aproximadamente &ports.size;, todos ellos expresados como deltas de sus fuentes - originales. Esto hace que nos sea mucho más fácil actualizar - ports, y reduce de un modo importante el espacio en disco que + originales. Esto hace que nos sea mucho más + fácil actualizar + ports, y reduce notablemente el espacio en disco que necesitaba la anterior colección de ports 1.0. Para compilar un port uno simplemente se sitúa bajo el directorio del programa que desea instalar, escribe make install, y deja que el sistema se encargue del resto. La distribución - original completa de cada port que construye se recupera + original completa de cada port que compile se recupera dinámicamente de un CDROM o un sitio FTP, de modo que sólo - necesita el espacio usado para construir los ports que - quiera. La mayoría de los ports también están disponibles + necesita el espacio usado para compilar los ports que + quiera. La mayoría de los ports también + están precompilados en paquetes, que pueden instalarse - con un simple comando (pkg_add) para aquéllos + con una simple orden (pkg_add) para aquéllos que no quieran compilar sus propios ports a partir de los - fuentes. Puede encontrar más información sobre + fuentes. Puede encontrar más información sobre los paquetes y los ports en . Algunos documentos que pueden ser de ayuda en el proceso de - instalación y al utilizar FreeBSD pueden también encontrarse en + instalación y al utilizar FreeBSD pueden también + encontrarse en el directorio /usr/share/doc de cualquier - máquina con una versión reciente de FreeBSD. Puede ver los manuales - que están instalados en local con cualquier navegador que pueda + máquina con una versión reciente de FreeBSD. + Puede consultar los manuales + que están instalados su sistema con cualquier navegador que pueda mostrar HTML vía las siguientes URLs: El manual de FreeBSD /usr/share/doc/handbook/index.html Las FAQ de FreeBSD /usr/share/doc/faq/index.html - También puede ver la copia original (y más frecuentemente + También puede ver la copia original (y más + frecuentemente actualizada) en http://www.FreeBSD.org/.