diff --git a/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml b/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml index a059fa2be1..c220de90da 100644 --- a/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml +++ b/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml @@ -1,416 +1,396 @@ - - - - -%man; - %freebsd; - %newsgroups; - -%authors; - -%trademarks; - -%translators; - %mailing-lists; - -]> -
Argentina.com : Un estudio de caso Carlos Horowicz
ch@argentina.com
$FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.xfree86; &tm-attrib.general;
Introducción Argentina.Com es un ISP argentino con una pequeña infraestructura de menos de 15 empleados y cuya fuente principal de ingresos proviene del negocio del acceso telefónico a redes gratuito. Comenzó a operar en el año 2000 con sólo un servidor para correo y chat. Desde entonces ha crecido su presencia en un mercado argentino de acceso telefónico a redes que genera unos 45.000 millones de minutos anualmente. Su producto más famoso proporciona a cerca de medio millón de usuarios correo gratuito con webmail, POP3 y acceso SMPT, junto con 300M de espacio de disco. Hacia el final de 2002 había alrededor de 50.000 usuarios de correo. Después de dos años y medio de reingeniería y de sólidas mejoras técnicas este ISP ha crecido en un factor de 3 en términos de facturación, y en un factor de 10 en cuanto a la base de usuarios de correo. Nuestros competidores en el mercado argentino de acceso telefónico incluyen a Fullzero (filial perteneciente a Clarin Media Group), Alternativa Gratis y Tutopia, este último fundado por IFX y promocionado por Hotmail. Algunos de estos grandes competidores comenzaron sus respectivos negocios de acceso telefónico con inversiones multimillonarias y con campañas de publicidad agresivas en televisión e Internet. Argentina.Com no utiliza este tipo de publicidad. Ha alcanzado la cuarta posición con un 8% de cuota de mercado durante los dos últimos años gracias a un calidad de servicio superior. En Argentina y en Latinoamérica en general las personas que no poseen ordenador personal van a los llamados locutorios (centros de Internet), donde por unos pocos pesos pueden utilizar un ordenador conectado a Internet y donde normalmente leen y escriben correos electrónicos a través de portales populares como Hotmail, Yahoo! o Argentina.Com. Debido a los limitados recursos financieros disponibles, Argentina.Com decidió invertir en un nuevo sistema de correo en vez de darse publicidad a través de los medios. Esta decisión estratégica abre las puertas a un futuro negocio en el campo del correo corporativo y de pago. El desafío El desafío principal para Argentina.Com es alcanzar un tiempo de vida para el servicio de acceso telefónico a redes de al menos 99.95%, o menos de 5 horas de caídas al año. Debido a la alta rotación y volatilidad que existe en este negocio, las cosas deben funcionar correctamente para que el usuario no cambie -voluntariamente o no- de proveedor de acceso a internet o de número de teléfono utilizado para conectarse. El negocio del dialup, como se le conoce en su denominación inglesa, requiere una estructura de soporte para tratar con las grandes operadoras de telecomunicaciones problemas telefónicos y de calidad de servicio, junto con una infraestructura técnica donde la latencia y la pérdida de paquetes deben minimizarse debido a la naturaleza UDP de los servicio de Radius y DNS, y donde el DNS recursivo debería estar siempre disponible. Esto tambíen implica tener un tiempo de vida alto en los servicio de POP3 y SMTP, junto con el servicio de webmail. Para POP3 y SMTP se estimó la necesidad de uptime igual que para el servicio de dialup, mientras que para el servicio de webmail se pensó en un porcentaje de 99.5%, lo que significa alrededor de dos dias por año sin servicio o de caída. Decidimos migrar el correo a una solución propietaria de código abierto que debería ser horizontalmente escalable y cuyos sistemas antivirus y antispam pudieran soportar más de un único tipo de backend o de almacenamiento de correos. La feroz competencia en el mercado del correo electrónico gratuito, principalmente iniciada por las recientes mejoras introducidas por Hotmail, Yahoo! y Gmail, hacían necesario diseñar el nuevo sistema con al menos 300M de espacio de usuario en disco para cada usuario, pero a un coste inferior a 3 dólares americanos por GB incluyendo cierto grado de redundancia. Hay que tener en cuenta que el hardware que puede disponerse en rack es difícil de encontrar en Argentina y que resulta ser entre un 30 y un 40% más caro que en los EEUU. Nuestro líquido financiero para adquisición de equipos en dos años fue de 75.000 dólares americanos, lo cual es una fracción muy pequeña de las inversiones acometidas por nuestros competidores directos. Respecto al servicio antispam, era necesario desarrollar un producto que pudiera competir con los sistemas ofrecidos por los grandes. Dadas las hostiles condiciones que impone la existencia del spam (ataques de diccionario, spams con alto grado de ofuscación y refinamiento, phishing, troyanos, correos-bomba, etc.) resulta muy complicado alcanzar tiempos de uptime excelentes y al mismo tiempo repeler dichos ataques. Uno debe también ser cuidadoso para que el usuario no pierda correos debido a falsos positivos en la estrategia de clasificación, para que no se le inunde con spam o notificaciones de spam y para que el correo peligroso no alcance la carpeta de entrada de los usuarios. Por último, el sistema de correo debe protegerse para que los spammers no lo utilicen en su provecho para enviar spam. El paradigma del código abierto normalmente requiere la adquisición de grandes equipos de administradores de sistemas, operadores y programadores que se encarguen de aplicar parches, corregir bugs e integrar plataformas. El paradigma opuesto es también costoso debido a las caras licencias de software, la necesidad de hardware cada vez más caro y debido al elevado número de empleados encargados de proporcionar soporte. Así que el desafío era encontrar la mezcla correcta entre recursos monetarios y humanos escasos, alta estabilidad y grado de predicción, y un desarrollo rápido y fiable. En Buenos Aires resulta difícil encontrar profesionales de las ciencias de la computación bien entrenados, la mayoría de los cuales viven y trabajan en el extranjero, mientras que los restantes poseen trabajos estables dentro de las instituciones del gobierno o en grades compañías. La solución FreeBSD Introducción A comienzos de 2003 teníamos un sistema de correo CriticalPath bajo Solaris x86 y una máquina Redhat para SMTP, Radius y DNS. Los servicios de DNS y Radius se caían constantemente y estábamos luchando con colas enormes de correo electrónico. Hubo un intento de instalar CriticalPath para Linux en Redhat en una máquina Intel con una tarjeta Megaraid, pero la latencia del disco era enorme y la aplicación de correo no llegó a funcionar. El primer paso realizado hacia la solución &os; consitió en migrar este hardware y software comercial a &os; 4.8 con la ayuda de la emulación Linux. La elección de &os; El sistema operativo &os; goza de una merecida fama de por su gran estabilidad, junto con su pragmatismo y sentido común a la hora de poner aplicaciones on-line gracias a su excelente colección de Ports. Nosotros consideramos su proceso de generación de releases muy sencillo de entender, además de que la comunidad de usuarios de las listas oficiales de correo electrónico mantiene un estilo educado y civilizado cuando ayudan o leen los problemas de otros usuarios y sus soluciones. Otra característica importante es su rápida implantación. Afortunadamente pudimos establecer nuestra política de instalación de SO alrededor de las capacidades predefinidas de &os;. En una compañía pequeña algunas veces necesitas ir corriendo a un centro de datos y rápidamente levantar un servidor para proporcionar algún servicio. En los dos últimos años, Argentina.Com adquirió alrededor de cuarenta servidores, la mayoría Pentium IV pero también varios Xeon duales y unos cuantos Opteron duales para ubicarlos en los centros de datos donde tenemos los contratos de operaciones de hosting y de acceso telefónico a redes. Todos ellos ejecutan &os;, desde 4.8 (un par de ellos con dos años de uptime y cero problemas) hasta 6.0-BETA2. La política general que tenemos para con el sistema operativo consiste en intentar llevar a todos los servidores a la rama de código estable de una forma periódica utilizando RELENG_4, RELENG_5 y ahora RELENG_6. Estas operaciones nos permiten estar más preparados ante posibles amenazas de seguridad a nivel del sistema operativo o del software base del mismo, especialmente en los servidores web. Reingeniería básica El prime paso de reingeniería fue poner en funcionamiento dos máquinas &os; 4.8 cuya única tarea iba a consistir en ser DNS autorizados para todos nuestros dominios. El software elegido resultó ser BIND9. Estas máquinas se ubicaron en diferentes centros de datos, cuidándonos de asegurar una buena latencia entre ellos para evitar problemas en transferencias de zonas, haciendo posible tratar con TTLs entre 60 y 600 segundos para así poseer unos mejores márgenes de reacción en caso de problemas. El segundo paso consistió en desplegar dos máquinas más del mismo tipo, también en distintos centros de datos, para sólo servir Radius y DNS recursivo. Los servidores de acceso de red (Network Access Servers o NAS) de los operadores de telecomunicaciones se configuraron para enviar las peticiones de autorizació y accounting de Radius hacia los nuestros, y también para asignar dichos DNS recursivos a nuestros usuarios de acceso telefónico. La tercera regla de oro consiste en no poner jamás en la misma máquina el servicio de entrada y salida de correo SMTP. Desplegamos máquinas &os; distintas utilizando Postfix tanto para la entrada como para la salida. Migración del correo La migración del correo requería una planificación cuidadosa debido al hecho de que íbamos a a migrar tanto los frontales como los backends. El primer paso fue construir un sistema perimetral antispam y antivirus con &os; 4.x y 5.x basado en postfix, amavisd-new, clamav y SpamAssassin. Estos sistemas iban a entregar correos tanto a los antiguos sistemas como a los nuevos hasta que el nuevo backend estuviera en funcionamiento. Entre tanto añadimos pequeñas máquinas &os; para incrementar el spool de correo de CriticalPath sin ningún problema. En la primera línea de la entrada de correo pusimos varios MX del dominio Argentina.com para filtrar ataques de diccionario (intentos de reenviar correo a usuarios no existentes) además de una lista negra derivada de SURBL que resultó no dar casi ningún falso positivo. Los correos eran multiplexados hacia un cluster de Xeon duales y Opteron duales donde ejecutábamos amavisd-new junto con un filtrado basado en listas blancas y negras basado en MySQL. Descartamos el uso de Bayes y Autowhitelisting en un nivel global debido a las grandes cantidades de falsos positivos y de falsos negativos que proporcionaban. En su lugar definimos unos cuantos niveles de spam de menos a más tolerante, cada uno con niveles de corte y de descarte. A cada correo electrónico recibido el sistema le asigna una determinada puntuación. Los correos con una puntuación por debajo de la puntuación asociada con el nivel de corte establecido por el nivel de spam pueden continuar hasta la bandeja de entrada del usuario. Los correos entre el nivel de corte y el nivel de descarte se envían a una carpeta del usuario denominada Spam, y por último aquellos correos por encima del nivel de corte se descartan porque se considera una situación muy evidente de spam. En aras de la simplicidad, se asocian de forma transparente los correos almacenados en la libreta de direcciones con el sistema antispam, colocándolos en las listas blancas de forma automática. Con la introducción de Spamassassin 3.x, el tráfico de DNS utilizado para preguntar a las listas negras de correo creció considerablemente, de tal forma que firmamos acuerdos con SpamCop, Spamhaus y SURBL para instalar réplicas públicas de sus bases de datos en nuestro equipo &os;. Gracias a estas réplicas, que nos costaron entre 1 y 2Mbps de tráfico, fuimos capaces de reducir drásticamente la latencia de Spamassassin. En un tercer nivel nos encontramos con la entrega a los buzones de correo de los usuarios. Tan pronto como nos pusimos a contruir el nuevo backend Cyrus-Imap con autentificación MySQL, nos dimos cuenta de que necesitábamos multiplexar el correo de entrada a los usuarios en los formatos de los buzones nuevos y antiguos. Finalmente, conseguimos migrar cientos de miles de correos hacia la nueva arquitectura Cyrus utilizando una fenomenal herramienta denominada imapsync, que se puede instalar directamente desde los ports. También instalamos perdition (un proxy de POP3 y de IMAP) entre medias para asegurar una migraci´n transparente y permitir la distribución entre distintos servidores de los buzones. En resumen, toda la información de localización de un buzón de usuario está en MySQL, y dicha información se encuentra disponible para todo el software que forma parte de la cadena. Respecto al hardware para el espacio de disco, actualmente utilizamos siete máquinas &os; con Cyrus-Imap de distinto hardware. El mayor es un Pentium IV con 4G de RAM y tarjetas 3ware con 12 bahías extraíbles en caliente, organizadas en 3 unidades RAID-5 de 1 Terabyte cada una. El software 3ware envía un correo electrónico al administrador cuando el RAID se degrada (en la mayoría de los casos se trata de errores de disco) y es posible reconstruir el RAID con el sistema a pleno rendimiento. Utilizamos smartmontools en los casos en los que hay menor redundancia, para disponer inmediatamente de alertas de discos con problemas de temperatura o de fallos de selftests. Como software de correo web elegimos un producto comercial denominado Atmail, disponible con sus fuentes en perl y que utiliza mod_perl. Bajo &os; resulta extremadamente sencillo gestionar los módulos de perl y no es necesario usar la shell de CPAN; únicamente hay que seleccionar el port correcto y ejecutar make install. Tras varios meses de trabajo de integración pudimos integrar la parte cliente de Atmail que habla IMAP con nuestros backends. Tuvimos que modificar algunas partes del código para adaptar el producto a nuestro entorno libre y para hacerlo compatible con nuestro perímetro antispam antivirus, además de aplicar nuestras personalizaciones y traducciones. Migración web Con la adopción de &os; no hubo que realizar ningún esfuerzo adicional para tener en ejecució en cuestion de minutos los entornos de Apache, PHP y MySQL. Incluso las actualizaciones de PHP4 a PHP5 se efectuaron sin problemas. El sistema de ports nos resultó una vez más extremadamente útil y nos permitió hacer cosas como comprimir los contenidos de texto y de html de Apache utilizando unas pocas líneas de documentación. Además, hemos experimentado un rendimiento excelente y una estabilidad y uptimes extraordinarios. Resultados Conseguimos implantar una arquitectura de correo electrónico basada en &os; que es escalable horizontalmente, utilizando 3 Terabytes de almacenamiento basado en servidores Intel incurriendo en un coste de 3 dólares por Gigabyte con redundancia. La gran estabilidad alcanzada permitió a Argentina.com explorar otros campos como el hosting para terceros y el housing con presencia en los centros de datos argentinos. Ahora ofrecemos también acceso telefónico a redes corporativas para usuarios de roaming y Perú gracias a nuestra presencia y a los acuerdos suscritos con la mayoría de los operadores de telecomunicaciones. Entre nuestros clientes indirectos se encuentran las principales compañías americanas como Ford, Exxon y Reuters. También estamos en el negocio del acceso telefónico a redes en Brasil, Chile, Colombia y Panamá.
diff --git a/es_ES.ISO8859-1/articles/contributing/article.sgml b/es_ES.ISO8859-1/articles/contributing/article.sgml index aea4413270..6362b648e2 100644 --- a/es_ES.ISO8859-1/articles/contributing/article.sgml +++ b/es_ES.ISO8859-1/articles/contributing/article.sgml @@ -1,627 +1,618 @@ -%man; - %freebsd; - %newsgroups; - -%authors; - %mailing-lists; - -%translators; - + +%articles.ent; ]>
Contribuir a FreeBSD $FreeBSD$ En éste artículo se describen las diferentes maneras en las que una persona o entidad pueden ayudar al Proyecto FreeBSD. &trans.es.bazcar; Jordan Hubbard Enviado por contributing ¿Quiere ayudar a mejorar FreeBSD? ¡Eso es genial! FreeBSD depende del esfuerzo de base de usuarios y usuarias para sobrevivir. Su ayuda no sólamente muy apreciada sino que es vital para el contínuo crecimiento de FreeBSD. Contrariamente a lo que pudiera usted creer, no hace falta ser un brujo de la programación o un amigo íntimo del core team de FreeBSD para su trabajo sea aceptado. El desarrollo de FreeBSD está al cargo de un gran grupo internacional de voluntarios y voluntarias en contínuo crecimiento, de muy diversas edades y expertos en distintos campos del conocimiento. Siempre hay más trabajo por hacer que gente disponible para hacerlo y una mano más siempre es bienvenida. El proyecto FreeBSD tiene el compromiso de mantener un sistema operativo completo, no simplemente un kernel o unas cuantas aplicaciones sueltas. Por lo tanto nuestra lista de TAREAS PENDIENTES (TODO) incluye una vasta lista de tareas: desde documentación, prueba de versiones preliminares hasta el desarrollo del sistema de instalación y el desarrollo del kernel en aspectos altamente especializados. Casi con total seguridad puede usted ayudar al proyecto sea cual sea su preparación y el área en la que disponga de experiencia o interés. Invitamos a las empresas que tienen proyectos relacionados con FreeBSD a que se pongan en contacto con nosotros. ¿Necesitan una extensión concreta para hacer que su producto funcione? Estaremos encantados de escuchar sus peticiones (suponiendo que no sean demasiado esotéricas). ¿Su proyecto es interesante y/o beneficioso para su empresa y para FreeBSD? ¡Háganoslo saber! Podemos trabajar conjuntamente en algunos aspectos del mismo. El mundo del software libre está cambiando muchas de las normas establecidas sobre cómo el software debería ser desarrollado, vendido y mantenido así que le rogamos encarecidamente que al menos le dé un segundo vistazo. Qué es lo que hace falta La siguiente lista de tareas y subproyectos representa de algún modo la amalgama de listas de TAREAS PENDIENTES y peticiones de usuarios. Tareas en Curso para No Programadores Una gran parte de quienes trabajan en FreeBSD no son programadores. El Proyecto incluye escritores de documentación, diseñadores y técnicos de soporte. Los únicos requisitos necesarios son poner algo de su tiempo y ganas de aprender. Lea cuidadosamente las FAQ y el Handbook cada cierto tiempo. Si algo está mal explicado, desfasado o sencillamente completamente equivocado háganoslo saber. Aún mejor, envíenos la corrección (no es difícil aprender SGML pero no hay problema si lo envía en ASCII). Ayude a traducir la documentación de FreeBSD a su lengua materna. Si ya existe documentación en su idioma puede ayudar a traducir otros documentos o a mantener al día los que ya existan. Antes de nada consulte Translations FAQ en el FreeBSD Documentation Project Primer. El hecho de traducir algo no implica la obligación de traducir todo: al ser una tarea voluntaria puede usted traducir tanto o tan poco como prefiera. Cuando alguien empieza a traducir casi siempre hay alguien que se une. Si sólo tiene tiempo o ganas para traducir una parte de la documentación por favor, traduzca las instrucciones de instalación. Lea la &a.questions; y el &ng.misc; de vez en cuando (o incluso regularmente). Compartir sus conocimientos mientras ayuda a la gente a resolver sus problemas puede ser muy gratificante. ¡Puede ser que incluso aprenda usted también algo nuevo! Esos foros pueden ser también un importante foco de ideas para nuevas cosas en las que trabajar. Tareas en Curso para Programadores La mayoría de las tareas aquí expuestas requieren una considerable cantidad de tiempo o un conocimiento profundo del kernel de FreeBSD o ambas cosas. Existen, sin embargo, multitud de tareas muy útiles que son ideales para hackers de fin de semana. Si utiliza FreeBSD-CURRENT y tiene una buena conexión con Internet existe una máquina llamada current.FreeBSD.org que genera diariamente (en teoría, la frecuencia puede variar) una distribución completa. Intente instalar la última versión desde ella e informe de cualquier anomalía en el proceso. Lea la &a.bugs;. Puede encontrar algún problema sobre el que hacer un comentario constructivo o sobre el que probar parches. Puede incluso intentar arreglarlo usted. Si sabe de alguna corrección que ha sido aplicada con éxito a -CURRENT pero que aún no haya sido incluída en -STABLE tras un período de tiempo razonable (por lo general un par de semanas) envíe al committer responsable un (educado) mensaje recordándoselo. Mueva software de terceras partes a src/contrib en el árbol de fuentes. Asegúrese de que el código de src/contrib está actualizado. Compile el árbol de fuentes (o sólo una parte del mismo) con una cantidad extra de warnings activadas y depúrelas. Corrija warnings en los ports en los que aparecen cosas en desuso como gets() o que incluyen malloc.h. Si ha enviado algún port envíe sus parches a los autores originales: le hará la vida más fácil cuando liberen la siguiente versión. Consiga copias de estándares formales como POSIX. Hay enlaces relacionados con esos estándares en el sitio web del FreeBSD C99 & Posix Standards Conformance Project. Compare el funcionamiento interno de FreeBSD con el que exije el estándar. Si hay diferencias, en especial en algún rincón sutil y oscuro de la especificación, envíe un PR (Problem Report). Si es capaz de aventurar una solución incluya un parche en el PR. Si cree que el estándar es incorrecto póngase en contacto con los responsables del mismo para que tengan en cuenta su propuesta. ¡Sugiera nuevas tareas para ésta lista! Trabajo en la <quote>PR Database</quote> base de datos de informes de problemas (PR) La lista de PR de FreBSD muestra los informes de problemas activos así como las peticiones de mejoras que han enviado los usuarios de FreeBSD. La PR database incluye tanto problemas que han de ser corregidos por programadores como por no programadores. Busque entre los PR que están abiertos, puede haber alguno que le interese. Algunos pueden ser tareas muy sencillas que sólo necesiten una mirada adicional para confirmar que la solución adjunta es la adecuada. Otras, por el contrario, pueden llegar a ser muchísimo más complejas o incluso no incluír una solución. Comience con un PR no haya sido aún asignado. Si el PR ya ha sido asignado a alguien pero cree que puede ayudar envíe un correo electrónico a la persona responsable del PR y pregúntele si puede colaborar (tal vez ya exista un parche listo para ser probado o puedan contrastar ideas). Cómo Colaborar Las colaboraciones al sistema generalmente pueden catalogarse en las siguientes 5 categorías: Informes de Errores y Comentarios Generales Las ideas o sugerencias de interés técnico general deben enviarse a &a.hackers;. En consecuencia, si le interesan ese tipo de cuestiones (¡y no le importa recibir un gran volumen de correo!) debería suscribirse a la &a.hackers; enviando un correo electrónico a &a.majordomo;. Consulte el FreeBSD Handbook para más información sobre ésta y otras listas de correo. Si encuentra un error o quiere enviar un cambio concreto por favor utilice el programa &man.send-pr.1; o su equivalente en la web (N. del T.: El interfaz web de send-pr fué desactivado a causa del spam). Trate de rellenar todos los campos del informe de errores. A menos que exceda de 65KB puede incluír los parches directamente en el informe. Si es posible aplicar el parche al árbol de fuentes no olvide incluír [PATCH] en la sinópsis del informe. Cuando incluya parches no copie y pegue ya que las tabulaciones son transformadas en espacios, haciendo el parche inútil. Considere la posibilidad de comprimir los parches mediante &man.uuencode.1; si sobrepasan los 20KB. Tras rellenar el informe debería recibir un mensaje de confirmación junto con un número de seguimiento. Conserve ese número por si en algún momento pudiera añadir nueva información sobre el problema enviando correo a FreeBSD-gnats-submit@FreeBSD.org. Utilice el número como asunto del mensaje (por ejemplo, "Re: kern/3377". Así debería enviarse la información adicional sobre cualquier PR. Si no recibe confirmación en un período de tiempo razonable (entre 3 días y una semana, dependiendo de su tipo de conexión) o si por alguna razón no puede utilizar el comando &man.send-pr.1;, puede solicitar que alguien lo haga por usted enviando un correo a &a.bugs;. No olvide consultar éste article sobre cómo escribir buenos informes de problemas. Cambios en la Documentación envíos de documentación Los cambios en la documentación son revisados por la &a.doc;. Por favor, consulte FreeBSD Documentation Project Primer para recibir instrucciones detalladas. Envíe nuevos contenidos o cambios sobre los ya existentes (¡incluso los pequeños son bienvenidos!) mediante &man.send-pr.1; tal y como se detalla en Informes de Error y Comentarios Generales. Cambios al Código Fuente ya Existente FreeBSD-CURRENT Añadir cambios o modificar el código fuente existente es un tema delicado y depende mucho de hasta qué punto esté usted al día sobre el estado actual del desarrollo de FreeBSD. Hay una versión en desarrollo permanente de FreeBSD conocida como FreeBSD-CURRENT, disponible de muy diversas formas para mayor comodidad de los desarrolladores que están trabajando activamente en el sistema. Consulte el FreeBSD Handbook, donde se explica cómo obtener y utilizar FreeBSD-CURRENT. Si trabaja con versiones anticuadas de los fuentes desafortunadamente significará que sus cambios podrían con frecuencia resultar demasiado obsoletos o demasiado divergentes para una fácil reintegración dentro de FreeBSD. Ésta posibilidad puede minimizarse suscribiéndose a la &a.announce; y a la &a.current;, donde tienen lugar los debates sobre el estado actual del sistema. Asumiendo que puede manejarse con seguridad con unos fuentes totalmente actualizados sobre los que aplicar sus cambios, el siguiente paso es generar los diffs que enviará al equipo de FreeBSD. Hágalo con el comando &man.diff.1;. El formato &man.diff.1; que preferimos para el envío de parches es la salida unificada generada por diff -u. Sin embargo, para parches que implican cambios sustanciales en una región de código una salida contextual de diff generada por diff -c resultará más legible y en consecuencia preferible. diff Por ejemplo: &prompt.user; diff -c ficheroantíguo ficheronuevo o &prompt.user; diff -c -r directorioantíguo directorionuevo generarían un conjunto de diffs contextuales de fichero fuente o la jerarquía de directorios. Del mismo modo &prompt.user; diff -u ficheroantíguo ficheronuevo o &prompt.user; diff -u -r directorioantíguo directorionuevo nos darían el mismo resultado excepción hecha del formato unificado de los diffs resultantes. Consulte la página man de &man.diff.1; para más detalles. Una vez que disponga de un conjunto de diffs (que debería probar con el comando &man.patch.1;) puede enviarlos para que sean incluídos en FreeBSD. Utilice el programa &man.send-pr.1; tal y como se muestra Informes de Errores y Comentarios Generales. ¡No se limite simplemente a enviar sus diffs a la &a.hackers; o se perderán! Agradecemos inmensamente su colaboración (¡éste es un proyecto que funciona gracias al trabajo desinteresado de mucha gente!). Estamos muy ocupados, así que no podemos atender inmediatamente todos y cada uno de los envíos recibidos, pero permanecerán en la PR database hasta que lo hagamos. Etiquete sus envíos incluyendo [PATCH] en la sinópsis del informe. uuencode Si lo considera oportuno (ésto es, si ha añadido borrado o renombrado ficheros) empaquete sus cambios en un fichero tar y ejecute el programa &man.uuencode.1; sobre él. Puede usar también ficheros creados con &man.shar.1; Si su cambio puede tener un cariz potencialmente delicado ésto es, no está seguro de bajo qué tipo de licencia sería su distribución ulterior o simplemente no está listo para liberarlo sin una revisión exhaustiva, debería enviarlo directamente a &a.core; en lugar de usar &man.send-pr.1;. El &a.core; incluye un grupo de gente mucho más pequeño que lleva a cabo la mayor parte del trabajo diario en FreeBSD. Tenga en cuenta que el &a.core; está muy ocupado y por lo tanto sólo debería enviársele correo cuando sea estrictamente necesario. Consulte la páginas man de &man.intro.9; y &man.style.9; para saber más acerca del estilo de codificación requerido. Le agradeceríamos mucho que al menos tuviera en cuenta esa información antes de enviar código. New Code or Major Value-Added Packages En el caso de una contribución significativa o de gran impacto, o si se trata de añadir una nueva característica importante a FreeBSD, enviar ficheros tar tratados con uuencode o por el contrario ponerlos a disposición de otras personas en un sitio web o FTP se convierte en algo prácticamente imprescindible. Si no dispone de acceso a un sitio web o FTP pregunte en la lista apropiada de FreeBSD para que alguien se lo facilite. Cuando se trabaja con un gran volumen de código el espinoso tema de la licencia invariablemente sale a la palestra. Las licencias admitidas para la inclusión de código en FreeBSD son: La Licencia BSD La licencia BSD. Ésta licencia es la preferida a causa de su naturaleza carente de requerimientos añadidos y su atractivo general para la empresa. Lejos de buscar evitar el uso comercial, el Proyecto FreeBSD recomienda vivamente la participación de entidades comerciales que pudieran en casos determinados dedicar parte de sus recursos a FreeBSD. GPLGNU General Public License GNU General Public License La GNU General Public License, o GPL. Ésta licencia no es tan popular debido al esfuerzo añadido que requiere de cualquiera que usara el código con fines comerciales, pero dada la ingente cantidad de código GPL que usamos habitualmente (el compilador, el ensamblador, el procesador de texto, etc) sería estúpido rechazar contribuciones bajo ésta licencia. El código bajo licencia GPL también se incluye bajo una parte diferenciada del árbol, pudiendo ser /sys/gnu o /usr/src/gnu, y es por tanto fácilmente identificable para quienes la licencia GPL suponga un problema. Todo lo que vaya bajo cualquier otro tipo de licencia requiere que ésta deba ser cuidadosamente revisada antes de que su inclusión en FreeBSD sea llevada a consideración. Las aportaciones bajo licencias comerciales particularmente restrictivas en vigor por lo general son rechazadas aunque siempre se recomienda a los autores que hagan públicamente accesible su trabajo usando sus propios medios. Para poner su trabajo bajo la licencia BSD inserte el siguiente texto al principio de todos y cada uno de los ficheros de código que quiera amparar bajo la misma, reemplazando el texto entre %% con la información apropiada: Copyright (c) %%años_exactos%% %%su_nombre%%, %%su_estado/país%% %%su_código_postal%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%su_nombre%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%su_nombre%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ Para su comodidad existe una copia de éste texto en /usr/share/examples/etc/bsd-style-copyright. Dinero, Hardware o Acceso a Internet Estamos encantados de aceptar donaciones económicas para ayudar a impulsar el Proyecto FreeBSD y, como en cualquier proyecto mantenido por voluntarios, un poco puede hacer mucho. También son muy importantes las donaciones de hardware para ampliar nuestra lista de hardware soportado, dado que normalmente andamos cortos de fondos con los que comprar ese tipo de material. <anchor id="donations">Donación de Fondos La Fundación FreeBSD es una fundación sin ánimo de lucro y exenta de impuestos creada para impulsar los objetivos del Proyecto FreeBSD. Como una entidad 501(c)3, la Fundación está prácticamente exenta del pago del impuesto federal de la renta de los EEUU así como del del Estado de Colorado. Las donaciones a una entidad libre de impuestos suelen ser deducibles en la declaración federal de impuestos. Las donaciones pueden enviarse mediante cheque a:
The FreeBSD Foundation 7321 Brockway Dr. Boulder, CO 80303 USA
La Fundación FreeBSD puede también aceptar donaciones via web mediante PayPal. Para hacer una donación visite la página web de la Fundación. Puede encontrar más información sobre la Fundación en The FreeBSD Foundation -- an Introduction. Puede enviar correo electrónico a la Fundación a bod@FreeBSDFoundation.org.
Donación de Hardware donaciones El Proyecto FreeBSD acepta encantado donaciones de hardware que le resulte útil. Si desea donar hardware por favor póngase en contacto con la Donations Liaison Office. Donación de Acceso a Internet Nunca viene mal una nueva réplica para sitios FTP, WWW o cvsup. Si desea ofrecer alguno de esos servicios por favor consulte el siguiente artículo Mirroring FreeBSD para más información.
diff --git a/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml b/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml index ed29072a25..b3f25c641b 100644 --- a/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml +++ b/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml @@ -1,841 +1,821 @@ - - -%man; - %freebsd; - %newsgroups; - -%authors; - -%trademarks; - -%translators; - %mailing-lists; - -]> - - -
Configurar un repositorio CVS - a la manera de FreeBSD Stijn Hoop
stijn@win.tue.nl
2001 2002 2003 Stijn Hoop $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; Este artículo describe los pasos que dí para configurar un repositorio CVS con los mismos scripts usados por el proyecto &os; en su configuración. Tienen algunas ventajas frente a las demás configuraciones de CVS, por ejemplo una gestión más eficaz de los accesos a los árboles de código y la creación de mensajes de correo electrónico por cada commit. &trans.es.jcamou;
Introducción Muchos de los proyectos de software de código abierto usan CVS como su sistema de gestión de código. Aunque CVS es bastante bueno para esto tiene sus inconvenientes y sus flaquezas. Un ejemplo de esto es el compartir un árbol de código con otros desarrolladores, lo cual puede convertirse rápidamente en una pesadilla para la administración del sistema, especialmente si se desea proteger del acceso indiscriminado ciertas partes del árbol. &os; es uno de los proyectos que usan CVS. También cuenta con una gran cantidad de desarrolladores alrededor del mundo. Ellos mismos desarrollaron algunos scripts para hacer del manejo del repositorio una tarea más fácil. Recientemente estos scripts fueron revisados por &a.joe; para facilitar su uso en otros proyectos. Este artículo muestra uno de los métodos para usar estos nuevos scripts. Si quiere sacar verdadero partido de la información que se le brinda en este artículo debe tener familiaridad con métodos básicos para realizar operaciones CVS. Comienzo de la configuración Es preferible que realice estos procedimientos en un repositorio de prueba vacío y podamos asi asegurarnos de que entiende todas las consecuencias. Como siempre, asegúrese de tener respaldos recientes. Inicio del repositorio Lo primero a hacer al configurar un nuevo repositorio es decirle a CVS que lo inicie: &prompt.user; cvs -d ruta-al-repositorio init Esto le indica a CVS que cree el directorio administrativo CVSROOT, donde se albergarán todas las configuraciones. El grupo del repositorio Ahora vamos a crear al grupo dueño del repositorio. Todos los committers necesitan estar en este grupo, para de esta manera poder escribir en el repositorio. Asumiremos el grupo ncvs por defecto de &os;. &prompt.root; pw groupadd ncvs A continuación, es necesario usar &man.chown.8; en el directorio para ajustar los permisos al grupo reción agregado: &prompt.root; chown -R :ncvs path-a-su-repositorio Esto asegura que nadie podrá escribir en el repositorio sin los permisos de grupo adecuados. Obtención del código Ahora es necesario obtener el directorio CVSROOT del repositorio de &os;. Puede hacerse muy fácilmente desde una réplica del CVS anónimo de &os;. Para más información consulte el capítulo correspondiente del Handbook. Asumiremos que el código está en CVSROOT-freebsd en el directorio actual. Copia de los <quote>scripts</quote> de &os; El siguiente paso consiste en copiar el código de &os; sito en CVSROOT a nuestro repositorio. Si está familiarizado con CVS , puede pensar que se puede realizar importando los scripts, lo que debería permitirle sincronizar posteriores versiones muy fácilmente. No es así, CVS tiene una deficiencia en este aspecto: al intentar importar código al directorio CVSROOT no se actualizarán los ficheros administrativos necesarios. Para hacer que esto suceda es necesario ejecutar checkin en cada uno de ellos después de importarlos, perdiendo asi el valor de cvs import. En consecuencia el método recomendado para este cometido es sencillamente copiar los scripts. No importa en realidad si no encuentra demasiado sentido al párrafo anterior, el resultado será el mismo. Simplemente haga check out de su CVSROOT y copie los ficheros de &os; a su copia local: &prompt.user; cvs -d ruta-a-su-repositorio checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * Tenga en cuenta que probablemente recibirá advertencias acerca de directorios no copiados; es normal que suceda pero no debe usted preocuparse porque éstos no son necesarios. Los <quote>scripts</quote> Ahora ya cuenta con una copia exacta en su directorio de trabajo de los scripts que &os; usa en la gestión de su repositorio. He aquí una descripción del cometido de cada uno de ellos. access - este fichero no se usa en la configuración por defecto. Se usa en la configuración del proyecto &os;, el cual controla el acceso al repositorio. Puede borrar este fichero si no quiere usarlo en su configuración. avail - este fichero controla el acceso al repositorio. Dentro del mismo es posible especificar grupos de personas autorizadas para el acceso al repositorio, asi como commits no autorizados en uno o más directorios dados. Deberá editarlo para que contenga los grupos y directorios que se usarán en su repositorio. cfg.pm - este fichero se encarga de analizar su configuración y provee la configuración por defecto. No deberá usted cambiar nada en este fichero. Si va a hacer cambios su configuración deberán ir en cfg_local.pm. cfg_local.pm - contiene todos los parámetros configurables del sistema. Deberá configurar todo tipo de cosas en este fichero, tales como el envío por correo electrónico de los mensajes de commit, desde qué hosts pueden hacer commits los usuarios, etc. Más información más adelante en el texto. checkoutlist - este fichero lista todos los ficheros bajo control de CVS en este directorio, aparte de aquellos estándar creados por cvs init. Deberá editar éste para borrar algunos ficheros específicos del proyecto &os;. commit_prep.pl - este script se encarga de realizar algunas comprobaciones previas a cada commit según las modificaciones hechas o o no en su versión de cfg_local.pm. No debería modificar este script. commitcheck - este script es invocado directamente por CVS. En primer lugar comprueba que la committer tenga acceso a una parte específica del árbol usando cvs_acls.pl, para después ejecutar commit_prep.pl, mediante el que efectuará las comprobaciones de rigor previas a cada commit. Si todo ha ido bien CVS permitirá que el commit tenga lugar. No debería tocar este fichero. commitinfo - este fichero es usado por CVS para determinar qué script se deberá ejecutar antes de hacer el commit, en este caso commitcheck. Tampoco debería tener que modificar este fichero. config - el fichero de configuración del repositorio. Debería editarlo si es necesario aunque la mayoría de los administradores lo dejan tal y como viene por defecto. Dispone de más información sobre las opciones que pueden declararse en él en el manual de CVS. cvs_acls.pl - este script determina la identidad de los committers, así como si tiene permitido acceder al árbol. Está basado en el fichero avail. No debería tener que modificar este fichero. cvsignore - este fichero especifica los ficheros que CVS no debe incluir en el repositorio. Puede editarlo a su gusto. Para más información sobre fichero consulte el manual de CVS. cvswrappers - CVS usa este fichero para activar o desactivar la expansión de la expansión de palabras clave o si el fichero debe ser considerado binario. Este fichero puede editarse según necesidades. Para más información sobre este fichero consulte el manual de CVS. Tenga en cuenta que las opciones -t y -f no funcionan correctamente con CVS cliente/servidor. edithook - este fichero ya no se usa, aunque se mantenga por razones históricas. Este fichero puede borrarse con total tranquilidad sin miedo de perjudicar la configuración. editinfo - CVS usa este fichero en las sobreescrituras de edición. &os; no usa esta función ya que el análisis de mensajes de log se hace mediante verifymsg y logcheck. Esto se debe a que editinfo no funciona correctamente con commits remotos ni con aquellos que usan las opciones -m o -F. No debería tener que modificar este fichero. exclude - este fichero lista expresiones regulares usadas por commit_prep.pl para determinar ficheros que no puedan contener cabeceras de revisión. En la configuración que se usa en &os; todos los ficheros bajo control de revisión necesitan tener lo que se llama una cabecera de revisión ($FreeBSD$). Todos los ficheros que aparezcan en alguna de las líneas de exclude no pasan por dicha revisión. Incluya en este fichero entradas para aquellos ficheros que no puedan tener una cabecera de revisión. Si va a instalar los scripts CVSROOT/ es un firme candidato para figurar en este fichero. log_accum.pl - este es el script encargado de obtener el mensaje de log que genera logcheck y añadirlo a un fichero de log en el repositorio para que pueda disponerse de respaldos en caso de necesidad. También gestiona el envío de un correo electrónico a la dirección que el administrador declare (en cfg_local.pm). loginfo se encarga de conectar log_accum.pl con CVS. No debería tener que modificar este fichero. logcheck - este fichero revisa el mensaje de commit proporcionado por el committer e intenta esterilizarlo, valga la expresión. Este fichero conecta con CVS via verifymsg . Tampoco debería tener que modificar este fichero. Este script depende de un hack de CVS propio de &os;: esta versión lee el mensaje de log después de que este script lo haya modificado. La versión estándar de CVS no hace esto, lo que hace a logcheck incapaz de limpiar los mensajes de log, aunque es capaz de comprobar que esté sintácticamente correcto. CVS 1.11.2 puede configurarse para tener el mismo comportamiento que la versión de &os; activando RereadLogAfterVerify=always en el fichero config. loginfo - este fichero es usado por CVS para controlar dónde se envía la información de log; aquí es donde log_accum.pl entra en escena. No debería tener que modificar este fichero. modules - este fichero mantiene su significado tradicional en CVS. Deberá borrar los módulos propios de &os; de la versión que vaya a usar. Puede editarlo a su gusto. Tiene más información acerca de este fichero en el manual de CVS. notify - CVS usa este fichero en caso de que alguien ponga un fichero en modo watch. No se usa en el repositorio de &os; y puede editarse cuanto se desee. Tiene más información acerca de este fichero en el manual de CVS. options - este fichero se usa específicamente en la versión de CVS de &os;, así como en la versión de Debian. Contiene una palabra clave para expander cabeceras de revisión. Tendrá que modificar este fichero y escribir la misma palabra que haya declarado en cfg_local.pm (si es que quiere usar esa característica, claro está; el valor por defecto es FreeBSD) rcsinfo - este fichero mapea directorios en el repositorio para aplicar una plantilla como rcstemplate. Por defecto &os; usa una plantilla para el repositorio. Es posible añadir otras plantillas si se estima conveniente. tagcheck - este fichero controla el acceso a marcar tags (etiquetas) en el repositorio. La versión por defecto en &os; no admite etiquetas con nombre RELENG* debido al proceso de ingeniería de releases. Puede editar este fichero según sus necesidades. taginfo - este fichero mapea operaciones de etiquetado en los directorios del repositorio, cosa necesaria en el funcionamiento habitual de scripts de control como tagcheck. No debería tener que modificar este fichero. unwrap - este script puede ser usado para alterar el estado de ficheros binarios en una forma opuesta a como lo hace cvswrappers, descrito al principio de esta lista. No se usa en la configuración que funciona hoy día en &os; porque no funciona correctamente con commits remotos. No debería tener que modificar este fichero. verifymsg - este fichero mapea directorios del repositorio con scripts encargados del proceso posterior de mensajes de commit en ficheros de log, por ejemplo logcheck. No debería verse en la necesidad de modificar este fichero. wrap - este script puede usarse para poner ficheros binarios bajo el efecto de cvswrappers (descrito al principio de esta lista) en cada checkin. No se usa en la configuración que mantiene el proyecto &os; porque no funciona correctamente con commits remotos. No debería tener que modificar este fichero. Modificación de los <quote>scripts</quote> El siguiente paso es configurar los scripts para que se adapten a sus necesidades. Tendrá que revisar todos y cada uno de los ficheros en el directorio y hacer sus propios cambios y configuraciones. Seguramente tendrá que editar los siguientes ficheros: Si no desea usar los scripts de la configuración específica de &os; puede borrar tranquilamente el fichero access: &prompt.user; cvs rm -f access Editar avail para que contenga los diferentes directorios del repositorio en los cuales quiera controlar el acceso. Asegúrese de mantener la línea avail||CVSROOT, si no lo hace no podrí realizar el siguiente paso. Otra de las opciones que puede añadir a este fichero es el grupo de committers. Por defecto &os; usa el fichero access para listar todos sus committers pero se puede usar cualquier fichero que se desee. También es posible agregar grupos si se desea (la sintaxis está declarada en la primera parte de cvs_acls.pl ). Edite cfg_local.pm para que contenga las opciones deseadas. Seguramente le serán de gran interés las siguientes configuraciones: %TEMPLATE_HEADERS - éstos son procesados por los scripts de log y se insertan bajo el correo de commit si es que existen. Puede que quiera borrar las entradas PR y MFC after; y claro, puede agregar las suyas. $MAIL_BRANCH_HDR - puede añadir una cabecera en cada correo de commit en la que se detalle la rama (branch) en la que se ha hecho el commit. Defina la cabecera según su configuración y necesidades o déjelo vacío si no desea usar dicha cabecera. @COMMIT_HOSTS - defina éste valor si desea listar los hosts desde los que será posible hacer commits. $MAILADDRS - defina éste como la dirección del administrador o de alguna lista donde reciban los correos de commit. @LOG_FILE_MAP - cambie este valor como desee. Cada expresión regular (regexp) se compara en el directorio del commit, y el mensaje de log del commit se guarda en el subdirectorio commitlogs en el nombre de fichero mencionado. $COMMITCHECK_EXTRA - si no desea usar las comprobaciones de acceso específicas de &os; debería borrar la definición de $COMMITCHECK_EXTRA de este fichero. Cambiar el parámetro $IDHEADER es algo que sólo puede asegurarse que funcionará en &os;; depende de las modificaciones específicas de CVS hechas por &os;. Revise cfg.pm y compruebe si alguna de las opciones puede modificarse, aunque los cambios propuestos en los párrafos anteriores son bastante razonables. Seguramente quiera borrar las líneas del principio de exclude (las que contienen ^ports/, entre otras), puesto que son específicas de &os;. Además de esto comente las líneas que empiecen con ^CVSROOT/ y agregue una línea sólo con ^CVSROOT/. Después de que wrapper sea instalado puede añadir su cabecera a los ficheros en el directorio CVSROOT y restaurar estas líneas; por lo pronto sólo estarán estorbarán en el momento que quiera hacer un commit. Edite modules y borre todo lo relacionado con &os;. Añada sus propios módulos si lo cree necesario. Este paso es sólo necesario si usted ha declarado un valor a $IDHEADER en cfg_local.pm (que sólo funciona usando la versión de CVS modificada por &os;). Edite options y asegúrese de que la etiqueta declarada sea la misma que en cfg_local.pm. Simplemente cambie la etiqueta FreeBSD por la suya. Edite rcstemplate para que contenga las mismas palabras clave (o keywords) declaradas en cfg_local.pm. Puede borrar (este paso es opcional) las comprobaciones realizadas por tagcheck. Puede simplemente añadir exit 0 al principio del fichero para deshabilitar todas las comprobaciones que hace sobre las etiquetas. El último paso antes de terminar es asegurarse de que sea posible guardar de modo seguro los mensajes de commit. Por defecto se guardan en el propio repositorio, en el subdirectorio commitlogs del directorio CVSROOT. Este directorio debe crearse del siguiente modo: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs Después de una revisión cuidadosa debe hacer los commits necesarios con sus cambios. Asegúrese de haber activado su acceso al directorio CVSROOT en su avail antes de intentarlo. Una vez haya comprobado que todo es correcto puede hacer lo siguiente: &prompt.user; cvs commit -m '- Commit para iniciar los scripts de FreeBSD' Prueba de la configuración Ahora ya está listo para la primera prueba: un commit forzado al fichero avail para asegurarnos de que todo funciona como se espera. &prompt.user; cvs commit -f -m'Commit forzado para probar los nuevos scripts en CVSROOT' avail Si todo ha funcionado ¡felicidades! Dispone de una configuración de los scripts de &os; en su repositorio. Si CVS le da algún tipo de error en algo revise todo de nuevo y asegúrese de que todos los pasos se hayan hecho correctamente. Configuración específica de &os; El proyecto &os; utliza una configuración ligeramente diferente de la descrita; se usan los ficheros de configuración del subdirectorio freebsd en CVSROOT. El proyecto lo hace de esta manera debido al gran número de committers y a que todos y todas han de estar en el mismo grupo. Un wrapper simple fué escrito para poder asegurar que los usuarios tengan permisos correctos para poder hacer hacer commits; este wrapper establece el id del grupo al que el repositorio tiene. Si su repositorio lo necesita también los pasos para hacerlo están documentados más adelante. Pero antes de nada veamos una descripción de los ficheros involucrados. Ficheros usados en la configuración de &os; access - este fichero controla la información de acceso. Se debe editar este fichero e incluir a todos los miembros del proyecto. freebsd/cvswrap.c - este es el código de CVS wrapper que va a ser necesario instalar para hacer que todos los chequeos de acceso funcionen. Mas información sobre él más adelante en el texto. Debería editar las rutas de las macros ACCESS y REALCVS para que se correspondan con su configuración. freebsd/mailsend.c - este fichero es necesario para la configuración de la lista de correo de &os;. No deberá tocar este fichero. El procedimiento Edite el fichero access para que sólo contenga su nombre de usuario. Edite el fichero cvswrap.c para que contenga la ruta correcta de su configuración. Se define con una macro llamada ACCESS. Deberá cambiar también el lugar del binario de cvs si no coincide con el de su sistema. cvswrap.c está pensado para sustituir al comando cvs del sistema, que pasará a ser /usr/bin/ncvs . Mi copia de cvswrap.c tiene lo siguiente: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" Instalaremos después wrapper para asegurarnos de que se haya convertido en el grupo correcto al hacer el commit. Tiene el código fuente en cvswrap.c en su CVSROOT. Tendrá que compilar el código una vez haya incluido en el las rutas correctas: &prompt.user; cc -o cvs cvswrap.c E instálelos (necesitará ejecutar este paso como root): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rw /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs Esto instala wrapper como el comando cvs por defecto; así nos aseguramos de que cualquiera que quiera usar el repositorio necesita tener los niveles de acceso correctos. Ahora ya puede eliminar a todos los usuarios del grupo del repositorio. Todo control de acceso lo hará a partir de ahora wrapper y este wrapper establecerá el grupo de acceso correcto. Prueba de la configuración Su wrapper debería estar listo. Debería probarlo, claro está, haciendo un commit forzado al fichero access: &prompt.user; cvs commit -f -m 'Commit forzado para probar los nuevos scripts en CVSROOT' access Si algo falla asegúrese de que todos los pasos arriba descritos se han realizado correctamente.
diff --git a/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml b/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml index 16627b1167..8af71481ab 100644 --- a/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml +++ b/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml @@ -1,433 +1,430 @@ -%man; - -%translators; - + +%articles.ent; ]>
Cortafuegos con Dialup en FreeBSD Marc Silver
marcs@draenor.org
$FreeBSD$ En éste artículo se describe cómo configurar un cortafuegos que utiliza conexión PPP con FreeBSD e IPFW y más concretamente el uso de un cortafuegos en una conexión telefónica a la que se le asigna una IP dinámica. Éste documento no se ocupa de la configuración de la conexión PPP necesaria. &trans.es.carvay;
Prefacio Uso de un Cortafuegos en una Conexión Telefónica en FreeBSD En éste documento se expone el proceso necesario para configurar un cortafuegos en FreeBSD cuando la dirección IP es asignada dinámicamente por el ISP. Aunque se ha hecho todo lo posible por hacer éste documento tan informativo y correcto como sea posible puede enviar comentarios y/o sugerencias al autor a marcs@draenor.org, que serán bien recibidas. Configuración del Kernel Lo primero que tendrá que hacer es recompilar su kernel. Si necesita más información sobre cómo hacerlo el mejor recurso es la sección de Handbook acerca de la configuración del kernel. Necesitará añadir a su fichero de configuración del kernel las siguientes opciones: options IPFIREWALL Activa el código necesario para el cortafuegos en el kernel. options IPFW2 Activa la nueva versión de IPFW. Esto solo debe hacerse en FreeBSD 4.X puesto que en las versiones más recientes vienen incluído por defecto. options IPFIREWALL_VERBOSE Envia los paquetes que se ha decidido sean incluídos en un log a la aplicación encargada de gestionar los logs del sistema. options IPFIREWALL_VERBOSE_LIMIT=100 Limita el número de veces que una entrada que cumple las reglas puede ser incluída en los logs del sistema. Esto previene que sus logs se vean inundados por entradas repetidas. 100 es un número razonable, pero puede ajustarlo a sus necesidades. options IPDIVERT Activa los sockets divert, que serán descritos más tarde. Hay otras entradas opcionales que pueden compilarse en el kernel para incrementar la seguridad. No hacen falta para el funcionamiento del cortafuegos pero algunos usuarios especialmente paranoicos pueden querer usarlos. options TCP_DROP_SYNFIN Ignorar paquetes TCP con SYN y FIN. Esto evita ser vulnerable al uso de herramientas como security/nmap, que permiten identificar la pila TCP/IP de la máquina, pero incumple el soporte a las extensiones incluídas en el RFC1644. No se recomienda hacer tal cosa si la máquina va a ejecutar un servidor web. No reinicie tras recompilar el kernel. Si todo sale bien sólo necesitaremos reiniciar una vez en todo el proceso de instalación del cortafuegos. Modificación de <filename>/etc/rc.conf</filename> para cargar el cortafuegos Necesitamos hacer algunos cambios en /etc/rc.conf para darle ciertos detalles del cortafuegos. Es tan simple como añadir las siguientes líneas: firewall_enable="YES" firewall_script="/etc/firewall/fwrules" natd_enable="YES" natd_interface="tun0" natd_flags="-dynamic" Para más información sobre éstas entradas consulte /etc/defaults/rc.conf y lea &man.rc.conf.5; Desactivación de la Traducción de Direcciones de Red (NAT) de PPP Es posible que ya esté usando la NAT que incluye PPP. Si es su caso tendrá que desactivarla puesto que los casos que vamos a usar emplean &man.natd.8; para hacerlo. Si ya dispone de un grupo de entradas para arrancar automáticamente PPP probablemente se parezca a ésto: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" ppp_profile="profile" Si es su caso, tendrá que desactivar específicamente ppp_nat asegurándose de que ppp_nat="NO" existe en su in /etc/rc.conf. Tendrá tambié que borrar todas las entradas como nat enable yes o alias enable yes en /etc/ppp/ppp.conf. Las Reglas del Cortafuegos Casi hemos acabado. Lo único que nos falta es definir las reglas del cortafuegos, reiniciar y deberíamos tener nuestro cortafuegos funcionando perfectamente. Soy consciente de que cada cual tendrá necesidades distintas como reglas básicas. He intentado escribir unas reglas básicas que puedan cubrir las necesidades de un usuario de conexión telefónica normal. Vamos a comenzar por lo básico de un cortafuegos cerrado. Lo que se busca es rechazar todo por defecto y dejar pasar solamente lo que necesitemos. Las reglas deberían ir en la forma al principio permitir, luego rechazar. La premisa es que vamos a an˜adir reglas para lo que vamos a aceptar y luego rechazamos todo lo demás. :) Ahora vamos a crear el directorio /etc/firewall. Sitúese en el directorio y edite el fichero fwrules tal y como hemos escrito dentro de rc.conf. Por favor, no olvide que puede cambiar el nombre del fichero por cualquier otro que prefiera. Éste documento solamente facilita un ejemplo del nombre del fichero. Vamos a echar un vistazo a un ejemplo de fichero de configuración del cortafuegos que hemos comentado cuidadosamente. # Definimos el comando con el que invocamos al cortafuegos # (tal y como hemos incluído en /etc/rc.firewall) para # facilitarnos la lectura. fwcmd="/sbin/ipfw" # Fuerza el borrado de todas las reglas existentes en nuestro # cortafuegos antes de cargar el contenido de éste fichero. $fwcmd -f flush # Desvía todos los paquetes a través del interfaz tunnel. $fwcmd add divert natd all from any to any via tun0 # Permite todas las conexiones incluídas en reglas # dinámicas pero rechaza todas aquellas conexiones # establecidas que no estén incluídas en alguna # regla dinámica. $fwcmd add check-state $fwcmd add deny tcp from any to any established # Aceptar todas las conexiones de localhost. $fwcmd add allow tcp from me to any out via lo0 setup keep-state $fwcmd add deny tcp from me to any out via lo0 $fwcmd add allow ip from me to any out via lo0 keep-state # Aceptar todas las conexiones desde mi tarjeta de red que yo inicie. $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state # Todo el mundo a lo largo y ancho de Internet puede conectarse # a los siguientes servicios de la máquina. Éste # ejemplo permite específicamente las conexiones a sshd # y al servidor web. $fwcmd add allow tcp from any to me dst-port 22,80 in recv any setup keep-state # Ésto envía un RESET a todos los paquetes ident. $fwcmd add reset log tcp from any to me 113 in recv any # Activa ICMP: borre el tipo 8 si no quiere que su máquina # responda al ping. $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Rechazamos todo lo demás. $fwcmd add deny log ip from any to any Ya tiene usted un cortafuegos totalmente funcional que acepta todas las conexiones a los puertos 22 y 80 y registrará cualquier otro tipo de intento de conexión en un fichero log. Ahora podemos reiniciar tranquilamente y su cortafuegos debería empezar a trabajar tal y como le hemos dicho. Si le parece que hay algún dato incorrecto o tiene alguna sugerencia para mejorar éste documento por favor envíeme un correo electrónico. Preguntas ¿Por qué utiliza &man.natd.8; y &man.ipfw.8; cuando podría usar los filtros incluídos en &man.ppp.8;? Seré honesto y diré que no hay una razón clara por la que use ipfw y natd en lugar de los filtros que incorpora ppp. Tras hablarlo con mucha gente el consenso parece ser que ipfw es mucho más potente y configurable que el filtrado de ppp pero lo que se gana en funcionalidad lo pierde en facilidad de personalización. Una de las razones por las que prefiero usar esas aplicaciones es que creo má conveniente ejecutar un cortafuegos desde el kernel que desde una aplicación de entorno de usuario. Me aparecen mensajes como limit 100 reached on entry 2800 y después de eso ya no me aparecen más entradas indicando tráfico rechazado en mis logs. ¿Funciona mi cortafuegos? Esto significa simplemente que se ha alcanzado el máximo de entradas que pueden incluírse en el log cuando una determinada regla se ha cumplido. Esa regla sigue funcionando pero no enviaría más entradas al log hasta que el contador vuelva a cero. Puede poner a cero ese contador mediante ipfw resetlog. Además es posible elevar el límite de entradas a introducir en el log incluyendo la option en el fichero de de configuración del kernel. Por otra parte puede modificar ese valor (sin modificar su kernel y en consecuencia sin reiniciar la máquina) mediante el valor de &man.sysctl.8; net.inet.ip.fw.verbose_limit. Supongamos que estoy usando direcciones privadas internas, por ejemplo el rango 192.168.0.0. ¿Puedo añadir una regla al cortafuegos mediante un comando como $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via tun0 para prevenir intentos de acceso desde el exterior para conectar con máquinas de mi red?. La respuesta corta es no. La razón es que natd efectúa la traducción de direcciones para cualquier cosa que sea redirigida a través del dispositivo tun0. Eso significa que todos los paquetes entrantes hablarán exclusivamente con la IP asignada dinámicamente y no con la red interna. Hay que tener en cuenta sin embargo que es posible añadir una regla como $fwcmd add deny all from 192.168.0.4:255.255.0.0 to any via tun0, que evitaría que una de las máquinas de esa red enviara tráfico al exterior a través del cortafuegos. Debo de haber hecho algo mal. He seguido las instrucciones al pie de la letra y no tengo acceso a Internet. Estamos asumiendo que está usando userland-ppp, en consecuencia el conjunto de reglas que aquí se proponen operan en el interfaz tun0, que corresponde a la primera conexión efectuada mediante &man.ppp.8; (más conocido como user-ppp). Las conexiones efectuadas más tarde recibirán nombres como tun1, tun2 y así sucesivamente. Hay que tener también presente que &man.pppd.8; en cambio utiliza el interfaz ppp0, de modo que si se inicia la conexión con &man.pppd.8; hay que sustituír tun0 por ppp0. A continuación se muestra una forma muy limpia de modificar las reglas del cortafuegos. Conservaremos un fichero con las reglas originales con el nombre de fwrules_tun0. &prompt.user; cd /etc/firewall /etc/firewall&prompt.user; su Password: /etc/firewall&prompt.root; mv fwrules fwrules_tun0 /etc/firewall&prompt.root; cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules Para saber exactamente si está usando &man.ppp.8; o &man.pppd.8; examine la salida de &man.ifconfig.8; una vez que establezca la conexión. V.g., en una conexión hecha mediante &man.pppd.8; debería encontrarse con algo muy similar a lo siguiente (se muestran sólo las líneas relevantes): &prompt.user; ifconfig (eliminado...) ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xff000000 (eliminado...) Si por el contrario la conexión fué establecida mediante &man.ppp.8; (user-ppp) ésto es más o menos lo que se encontraría: &prompt.user; ifconfig (eliminado...) ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 (skipped...) tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 (IPv6 stuff skipped...) inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xffffff00 Opened by PID xxxxx (eliminado...)
diff --git a/es_ES.ISO8859-1/articles/euro/article.sgml b/es_ES.ISO8859-1/articles/euro/article.sgml index a85fab8ed9..21db75015d 100644 --- a/es_ES.ISO8859-1/articles/euro/article.sgml +++ b/es_ES.ISO8859-1/articles/euro/article.sgml @@ -1,406 +1,395 @@ -%man; - - -%freebsd; - - -%authors; - - -%mailing-lists; - -%translators; + +%articles.ent; ]>
El símbolo del Euro en <systemitem class="osname">FreeBSD</systemitem> Aaron Kaplan
aaron@lo-res.org
2002 2003 The FreeBSD Documentation Project $FreeBSD$ Este documento intentará ayudarle a empezar a usar el nuevo símbolo del Euro en su nuevo teclado, adquirido a principios del 2002 debido al cambio de la nueva moneda común. Primero trataremos los aspectos más importantes, como mostrar correctamente el símbolo en la consola. Las secciones posteriores tratarán sobre la configuración de programas en concreto, como X11. Se recibió ayuda muy provechosa de Oliver Fromme, Tom Rhodes y de muchos otros. ¡Gracias! ¡Sin su ayuda, este artículo no habría sido posible! &trans.es.jcamou;
El Euro hecho fácil Si ya se siente cómodo con la localización descrita en el Handbook de FreeBSD puede que sólo esté interesado en los siguientes pasos, que pueden ayudarle a empezar rápidamente: ISO8859-15 Ésta es una ligera modificación del mapa de caracteres ISO8859-1. Incluye ademá el símbolo del Euro, usado por las variables LANG y LC_CTYPE. iso15-8x16.fnt La fuente &man.vidcontrol.1; para consola /usr/share/syscons/keymaps/*.iso.kbd Un mapa de caracteres apropiado depende de su idioma. Defina su entrada de keymap en rc.conf usando alguno de éstos. LC_CTYPE Usado para especificar el tipo correcto de caracteres correcto. XkbLayout "idioma(euro)" Opción de configuración de XFree86. /usr/X11R6/lib/X11/fonts/*/fonts.alias Asegúrese de adaptar sus fuentes X11 a -*-..-*-iso8859-15 Observación general En las siguientes secciones a menudo nos referiremos a ISO8859-15. Esta es la notación estándar a partir de FreeBSD 4.5. En versiones anteriores la notación estándar era ISO_8859-15 o DIS_8859-15. Si está usando una versión anterior de FreeBSD asegúrese de revisar /usr/share/locale/ para averiguar la notación que está usando. La consola Cómo establecer la fuente de la consola Dependiendo de la resolución y tamaño de su consola necesesitará una de las siguientes líneas en rc.conf: font8x16="iso15-8x16.fnt" # from /usr/share/syscons/fonts/* font8x14="iso15-8x14.fnt" font8x8="iso15-8x8.fnt" Esto seleccionará ISO8859-15, también conocida como la fuente Latin-9. ISO8859-15 es una variación de ISO8859-1. Es posible encontrar la diferencia entre las dos al ver el símbolo del Euro: su valor decimal es 164. En ISO8859-1 notará un círculo con cuatro pequeños brazos en las esquinas. A menudo recibe el nombre de símbolo de la moneda universal. En ISO8859-15 en lugar del pequeño círculo se tiene el símbolo del Euro. Aparte de eso, las fuentes son idénticas. Cuando se redacta este artículo la única fuente que es posible usar es, al parecer, iso15-8x16.fnt. Las otras aparentemente sólo muestran ISO8859-1 aunque el nombre sugiera lo contrario. Al especificar esta fuente algunos programas de consola podrán ver muy alterado su comportamiento. Esto es debido a que se asume que se está usando una fuente o caracter diferente, por ejemplo ANSI 850. Un ejemplo notable de ello es sysinstall. En muchas ocasiones esto carece de mayor importancia. El siguiente paso es reiniciar el sistema para que los cambios tengan efecto o hacer los pasos que hubiese hecho el sistema al ser reiniciado (manualmente): &prompt.user; vidcontrol -f iso15-8x16.fnt Para asegurarse de que la fuente haya sido correctamente seleccionada ejecute el siguiente script de awk: #!/usr/bin/awk -f BEGIN { for(i=160;i<180;i++) printf~%3d %c\n",i,i } El resultado debe mostrar el símbolo del Euro en la posición 164. Configuración del teclado para el símbolo del Euro La mayoría de los teclados ya están configurados correctamente. Por ejemplo: si se tiene un teclado en alemán y sus teclas Umlaut funcionan puede saltarse esta sección ya que su teclado ya tiene la combinación necesaria (e.g.: Alt Gre ) al valor decimal 164. Si se experimentan problemas la mejor manera de revisarlo es echándole un ojo a /usr/share/syscons/keymaps/*.kbd. El formato de los ficheros de mapeo de teclas se describe en &man.keyboard.4;. &man.kbdcontrol.1; puede usarse para cargar un mapa en particular. Una vez seleccionado el mapa de teclas correcto debe añadirse a /etc/rc.conf con la línea: keymap="german.iso" # u otro mapa Como ya se mencionó este paso probablemente ya haya sido realizado por usted durante la instalación (con la ayuda de sysinstall). Si no fue así puede reiniciar o cargar el nuevo mapa de teclado mediante &man.kbdcontrol.1;. Para verificar el mapeo de las teclas es posible cambiar de consola y cuando pida nombre de usuario, en lugar de teclearlo, intente teclear el Euro. De no funcionar esto puede mandar un informe de error mediante &man.send-pr.1; o asegurarse de que haya escogido el mapa correcto para el teclado. En este momento la tecla del Euro no funcionará en bash o tcsh. Modificar las variables de ambiente Las shells (bash, tcsh) recurren a la biblioteca &man.readline.3;, que respeta la variable LC_CTYPE. LC_CTYPE debe ser establecida antes de que la shell se ejecute. Afortunadamente es suficiente añadir la siguiente línea: exoprt LC_CTYPE=de_DE.ISO8859-15 a su .bash_profile (bash), o: setenv LC_CTYPE de_DE.ISO8859-15 a su .login (tcsh). Por supuesto, de_DE debe ser remplazado con su idioma. A continuación finalice la sesión, inicie sesión nuevamente y verifique si su símbolo del Euro funciona. A partir de ahora la gran mayoríia de los programas de consola deben responder al Euro. Es probable que sean necesarios algunos pasos adicionales de configuración para programas especiales como pine. Una alternativa para modificar .login y .bash_profile es establecer las variables a partir del mecanismo de &man.login.conf.5;. Este método tiene la ventaja de asignar tipos de login a ciertos usuarios (por ejemplo usuarios que desean tener su entorno en francés, italiano, etc) mediante modificaciones de configuración en un solo lugar. Modificar X11 Modifique /etc/XF86Config de la siguiente manera: Option "XkbLayout" "de(euro)" Recuerde que tendrá que reemplazar de con el código de idioma que haya elegido. Su teclado debería estar configurado correctamente. De igual modo que en la sección de consola, debe seleccionarse la fuente correcta. En KDE vaya a su KDE control center -> Personalization -> Country & Language -> Charset y cámbielo a ISO8859-15. En kmail y otros programas tendrá que proceder de forma muy similar. Otra buena idea es modificar su ficheros en fonts.alias. Existe un caso especial: la fuente fixed debe cambiarse al mapa de caracteres correcto: El /usr/X11R6/lib/x11/fonts/misc/fonts.alias del autor; este es: ! $Xorg: fonts.alias,v 1.3 2000/08/21 16:42:31 coskrey Exp $ fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 ariable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-15 (...) Así como en las secciones de consola, ciertos programas aún tienen las fuentes ISO8859-1 configuradas en su respectiva base de datos de &man.xrdb.1;. Un ejemplo de esto es xterm. Como regla general es suficiente con cambiar la configuración correspondiente en /usr/X11R6/lib/X11/app-defaults y añadir la fuente correcta. Veamos un ejemplo con xterm. &prompt.root; cd /usr/X11R6/lib/X11/app-defaults/ &prompt.root; vi XTerm Añada la siguiente línea al principio del fichero: *font: -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-15 Para finalizar reinicie X y asegúrese de que las fuentes puedan mostrarse al ejecutar el script de awk anterior. La mayoría de los programas deben respetar el mapa de caracteres y las configuraciones de fuente. Problemas Por supuesto que el autor agradecería que le enviara sus comentarios. Además, al menos me gustaría saber si tiene usted solución para alguno de los siguientes problemas: Alguna manera alternativa de configurar XFree86: x11/xkeycaps Configuraciones para GNOME Configuraciones para KDE Configuraciones para XFCE Configuraciones para (X)Emacs Configuración para UTF-8 Una configuración que incluya libiconv como una manera efectiva de convertir entre ISO8859-15 y UTF-{8, 16} dentro de los programas
diff --git a/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml b/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml index 790083692a..2fc249b023 100644 --- a/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml +++ b/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml @@ -1,658 +1,653 @@ -%man; - -%freebsd; - -%translators; - + +%articles.ent; ]>
Qué es BSD Greg Lehey
grog@FreeBSD.org
En el mundo del código abierto la palabra Linux suele ser utilizada como sinónimo de Sistema Operativo pero no es el único sistema operativo libre &unix;. En Abril de 1.999 el Internet Operating System Counter reflejaba que el 31'3% de los sistemas que ofrecían algún servicio en Internet usaban Linux y el 14'6% usaban BSD &unix;. Alguna de las empresas más grandes de Internet, como por ejemplo Yahoo!, usan BSD. El servidor de FTP con más carga en 1999 (ahora desaparecido) , ftp.cdrom.com, transfería 1'4TB diariamente usando BSD. Es fácil suponer que no se trata de un nicho de mercado: BSD es un secreto bien guardado. ¿Así que cuál es el secreto? ¿Por qué BSD no es más conocido? Éste artículo trata sobre esa y otras cuestiones. A lo largo de éste artículo serán destacadas de éste modo. &trans.es.bazcar;
¿Qué es BSD? BSD son las siglas de Berkeley Software Distribution. Así se llamó a las distribuciones de código fuente que se hicieron en la Universidad de Berkeley en California y que en origen eran extensiones del sistema operativo &unix; de AT&T Research. Varios proyectos de sistemas operativos de código abierto tienen su origen en una distribución de éste código conocida como 4.4BSD-Lite. Añaden además un buen número de paquetes de otros proyectos de Código Abierto, incluyendo de forma destacada al proyecto GNU. El sistema operativo completo incluye: El kernel BSD, que se encarga de la programación del tiempo de ejecución de los procesos, la gestión de memoria, el multiproceso simétrico (SMP), los controladores de dispositivos, etc. A diferecia del kernel Linux existen varios kernel BSD con diversas funciones. La biblioteca C, la API base del sistema. La biblioteca C de BSD está basada en código procedente de Berkeley no del proyecto GNU. Aplicaciones como las distintas shells, aplicaciones de gestión de ficheros, compiladores y enlazadores. Algunas de las aplicaciones derivan del proyecto GNU, otras no. El sistema X Window, que gestiona el entorno gráfico. El sistema X Window que se usa en la mayoría de versiones de BSD es producto de un proyecto aparte, el Proyecto XFree86. Se usa el mismo código que en Linux. BSD por lo general no predetermina un gestor de ventanas como KDE o GNOME, aunque éstos y otros muchos esten disponibles. Muchos otros programas y utilidades. Entonces ¿es un UNIX verdadero? Los sistemas operativos BSD no son clones sino derivados de código abierto del sistema operativo de AT&T Research, el cual es a su vez ancestro del moderno UNIX System V. Ésto puede sorprenderle. ¿Cómo puede haber sucedido esto si AT&T jamás ha liberado su código? Cierto es que AT&T UNIX no es código abierto y que en un sentido estricto de copyright BSD no es en absoluto UNIX, pero por otra parte AT&T ha incluído fuentes de otros proyectos, teniendo como caso notable el Computer Sciences Research Group de la Universidad de Berkeley, California. En 1.976 el CSRG comienza a distribuir su software en cintas, dándoles la denominación Berkeley Software Distribution, o BSD. Las primeras distribuciones BSD consistían principalmente en aplicaciones de entorno de usuario (userland) pero la situación cambió de modo drástico cuando el CSRG firmó un contrato con la Agencia de Investigación de Proyectos Avanzados (DARPA) para mejorar los protocolos de comunicación en su red ARPANET. A los nuevos protocolos se les dió el nombre de Internet Protocols, y más adelante TCP/IP, que más tarde se habrían de covertir en los protocolos más importantes. La primera implementación ampliamente distribuída lo fué como parte de 4.2BSD, en 1.982. Durante la década de los 80 comienzan a surgir compañías que ofrecían estaciones de trabajo. La mayoría optó por adquirir licencias de UNIX en lugar de desarrollar sistemas operativos ellos mismos. En particular Sun Microsystems adquirió una licencia de UNIX e implementó una versión de 4.2BSD, a la que llamaron SunOS. Cuando la propia AT&T fué autorizada para vender UNIX iniciaron una implementación un tanto rudimentaria llamada System III, seguida rápidamente por System V. El código base de System V no incluía capacidad de trabajo en redes, de manera que todas sus implementaciones habían de usar software de BSD, incluyendo TCP/IP, así como aplicaciones como la shell csh y el editor vi. En conjunto esas inclusiones fueron conocidas como las Berkeley Extensions. Las cintas BSD contenían código fuente de AT&T y en consecuencia requerían una licencia de código UNIX. Hacia 1.990 al CSRG se le retiran los fondos y se enfrenta al cierre. Algunos de los miembros del grupo deciden distribuír el código BSD, que era Código Abierto, sin el código propiedad de AT&T. Finalmente ésto sucede con la Networking Tape 2, más conocida como Net/2. Net/2 no era un sistema operativo completo: faltaba aproximadamente un 20% del código del kernel. Uno de los miembros del CSRG, William F. Jolitz, escribió el código restante y lo distribuyó a comienzos de 1.992 como 386BSD. Al mismo tiempo otro grupo de antíguos miembros del CSRG fundaron una empresa llamada Berkeley Software Design Inc. y distribuyó una versión beta de un sistema operativo llamado BSD/386, que se basa en las mismas fuentes. El sistema operativo pasó a denominarse BSD/OS. 386BSD jamás llegó a ser un sistema operativo estable. En lugar de ello dos proyectos surgen de él en 1.993: NetBSD y FreeBSD. Ambos proyectos se forman gracias a la falta de paciencia que origina la espera de mejoras en 386BSD: el proyecto NetBSD comenzó a primeros de año y la primera versión de FreeBSD no estuvo lista hasta finales del mismo. En ese proceso el código base tomó caminos diferentes hasta tal punto que se hizo difícil de mezclar. Además los proyectos tienen objetivos diferentes, como veremos más adelante. En 1.996 otro proyecto, OpenBSD, se separa de NetBSD. ¿Por qué BSD no se conoce mejor? Existen diversas razones por las que BSD es relativamente desconocido: Los desarrolladores de BSD con frecuencia están más interesados en depurar su código que en promocionarlo. La mayor parte de la popularidad de Linux se debe a factores externos a los proyectos Linux, como la prensa y las compañías que ofrecen servicios relacionados con Linux. Hasta hace poco los BSD de fuente abierta carecían de tales abogados. Los desarrolladores de BSD suelen estar más experimentados que los de Linux y ponen menos de su parte a la hora de hacer el sistema fácil de usar. Los recién llegados suelen sentirse más cómodos con Linux. En 1.992 AT&T denunció a BSDI, el distribuidor de BSD/386, alegando que el producto contenía código propiedad de AT&T. El caso fué sobreseído en 1.994 pero la huella del litigio perdura. Aún en Marzo de 2.000 en un artículo publicado en la web se aseguraba que el caso había sido resuelto hace poco. Un detalle que el proceso judicial aclaró fue el de la nomenclatura: en los 80 BSD era conocido como BSD UNIX . Tras la eliminación del último vestigio de código de AT&T, BSD perdió el derecho a llamarse UNIX. Es por esto que es posible encontrar títulos de libros referentes a the 4.3BSD UNIX operating system y the 4.4BSD operating system y the 4.4BSD operating system. Existe la creencia de que los proyectos BSD están fragmentados y enfrentados entre sí. El Wall Street Journal habló de la balcanización de los proyectos BSD. Como en el caso del pleito, esa creencia se fundamenta en historia antígua. Comparemos BSD y Linux De manera que, ¿cuál es la diferencia entre, digamos, Debian Linux y FreeBSD? Para el usuario avanzado la diferencia es sorprendentemente pequeña: ambos son sistemas operativos tipo UNIX. Ambos son desarrollados por proyectos no comerciales (ésto, por supuesto, no es aplicable a la mayoría del resto de distribuciones de Linux). En el siguiente apartado tomaremos BSD como punto de partida y lo compararemos con Linux. La descripción se ajusta más a FreeBSD, que posée aproximadamente el 80% de los sistemas BSD instalados, pero las diferencias con NetBSD y OpenBSD son pequeñas. ¿Quién posée BSD? Ninguna persona o empresa posée BSD. Su creación y distribución es obra de una comunidad de voluntarios altamente cualificados y comprometidos a lo largo y ancho del mundo. Algunos de los componentes de BSD son proyectos de Código Abierto que cuentan con responsables ajenos al proyecto BSD. ¿Cómo se desarrolla y actualiza BSD? Los kernel BSD son desarrollados y actualizados siguiendo el modelo de desarrollo de Código Abierto. Cada proyecto mantiene un árbol de fuentes accesible públicamente mediante un Sistema Concurrente de Versiones (Concurrency Versions System, CVS), que contiene todos los ficheros fuente del proyecto, incluídos los de la documentación y otros ficheros relacionados. CVS permite a los usuarios hacer un check out (en otras palabras, extraer una copia) de los ficheros que componen la versión elegida del sistema. Un gran número de desarrolladores de muy diversas partes del mundo contribuye con mejoras a BSD. Estan divididos en tres categorías: Contributors son aquellos que escriben código o documentación. No se les permite hacer commit (es decir, añadir código) directamente al árbol de fuentes. Para que su código sea incluído en el sistema debe ser revisado y probado por un desarrollador registrado. Un/a committer. Committers son desarrolladores que disponen de acceso de escritura en el árbol de fuentes. Para convertirse en committer es necesario demostrar habilidad en el área en la cual él o ella trabaja. Depende del criterio individual de cada committer cuándo pedir autorización antes de hacer cambios en el árbol de fuentes. En general un committer experimentado puede incluír cambios que son obviamente correctos sin necesidad de consenso. Por ejemplo, un/a committer que trabaje en un proyecto de documentación puede corregir errores tipográficos o gramaticales sin necesidad de revisión. Por otra parte, se espera de desarrolladores que pretendan realizar cambios de gran calado o complicados que envíen sus cambios para que sean revisados antes de ser incluídos. En casos extremos un miembro del core team con una función como la del Principal Architect puede pedir que los cambios sean retirados del árbol; es lo que llamamos backing out. Todos los/las committers reciben un correo electrónico acerca de cada cambio concreto en el árbol de fuentes así que no es posible hacerlo en secreto. El Core team. Tanto FreeBSD como NetBSD disponen de un core team que coordina el proyecto. Los core team dirigen el rumbo de los proyectos pero sus funciones no siempre están claras. No es necesario ser desarrollador para ser un miembro de un core team pero suele ser lo habitual. Las normas de un core team varían de un proyecto a otro pero en general tienen más influencia sobre la dirección del proyecto. Éte sistema difiere del de Linux en algunos aspectos: Nadie posée el principio de autoridad. En la práctica eso es muy relativo, puesto que el Chief Architect puede solicitar que cierta entrada del árbol de fuentes sea eliminada e incluso en el proyecto Linux a ciertas personas les está permitido hacer cambios. Por otra parte hay un repositorio central, un único lugar donde encontrar las fuentes del sistema operativo íntegro, incluyendo todas las versiones anteriores. Los BSD mantienen el Sistema Operativo completo, no únicamente el kernel. Ésta distinción es válida únicamente como definición puesto que ni BSD ni Linux son útiles sin aplicacionesr: las aplicaciones que se usan en BSD suelen ser las mismas que las que se usan en Linux. Como resultado del mantenimiento estructurado de un único árbol de fuentes mediante CVS el desarrollo de BSD es limpio y es posible acceder a cualquier versión del sistema por su número de versión o por la fecha. Del mismo modo CVS permite actualizaciones incrementales del sistema: por ejemplo el repositorio de FreeBSD es actualizado en torno a 100 veces al día, aunque la mayoría de esos cambios son pequeños. Versiones de BSD Cada proyecto BSD pone a disposición pública tres releases (versiones) distintas. Igual que en Linux, las releases tienen asignado un número como por ejemplo 1.4.1 ó 3.5. Además el número de versión tiene un sufijo que indica su propósito: La versión de desarrollo del sistema recibe el nombre de CURRENT. FreeBSD asigna un número a CURRENT, por ejemplo FreeBSD 5.0-CURRENT. NetBSD utiliza un sistema ligeramente diferente y añade un sufijo compuesto por una única letra que indica cambios en las interfaces internas, por ejemplo NetBSD 1.4.3G. OpenBSD no asigna ningún número ("OpenBSD-current"). Ésta rama es la que incluye todo el desarrollo. A intervalos regulares, entre dos y cuatro veces al año, los proyectos liberan una versión RELEASE del sistema, que está disponible en CD-ROM y mediante FTP para su descarga gratuíta, por ejemplo OpenBSD 2.6-RELEASE o NetBSD 1.4-RELEASE. La versión RELEASE está dirigida al usuario final y es la versión estándar del sistema. NetBSD también dispone de patch releases que incluyen un tercer dígito, como por ejemplo NetBSD 1.4.2. A medida que se van encontrando errores en la versión RELEASE son corregidos y las soluciones son incluídas en el árbol CVS. En FreeBSD la versión resultante se denomina versión STABLE, mientras que en NetBSD y OpenBSD continúa siendo la versión RELEASE. Nuevas características más pequeñas pueden ser añadidas en ésta rama tras un período de pruebas en la rama CURRENT. Linux, en cambio, mantiene dos árboles de código separados: la versión estable y la versión de desarrollo. Las versiones estables añaden un número par de versión, como 2.0, 2.2 ó 2.4. Las versiones de desarrollo añaden un número impar, como en 2.1, 2.3 ó 2.5. En ambos casos a ese número se le añade otro más que indica la versión exacta. Por si fuera poco cada distribuidor añade sus propios programas y aplicaciones de entorno de usuario, así que el número de versión es importante. Cada distribuidor además asigna números de versión a la distribución, así pues la descripción completa podría ser algo como TurboLinux 6.0 with kernel 2.2.14 ¿Cuántas versiones de BSD existen? A diferencia de las numerosas distribuciones de Linux tan sólo hay tres BSD libres. Cada proyecto BSD mantiene su propio árbol de fuentes y su propio kernel. En la práctica, sin embargo, las diferencias en el entorno de usuario (userland) entre los distintos BSD son menores que las que hay en Linux. Es difícil enumerar los objetivos de cada proyecto puesto que las diferencias son muy subjetivas. En general, FreeBSD tiene como meta ofrecer alto rendimiento y facilidad de uso al usuario final y es uno de los favoritos entre proveedores de contenidos web. Funciona en PC y en procesadores Alpha de Compaq. El proyecto FreeBSD cuenta con un número de usuarios significativamente mayor que los otros proyectos. NetBSD tiene como meta la Portabilidad: No en vano su lema es of course it runs NetBSD (que podría traducirse como claro que funciona con NetBSD). Funciona en máquinas que abarcan desde PDAs a grandes servidores e incluso ha sido usado por la NASA en misiones espaciales. Es una excelente elección para utilizar viejo hardware no Intel. OpenBSD tiene como meta la seguridad y la integridad del código: combina del concepto de código abierto y una revisión rigurosa del código que dan como fruto un sistema muy correcto, elegido por instituciones preocupadas por la seguridad como bancos, entidades de cambio y departamentos gubernamentales de los EEUU. Al igual que NetBSD funciona en gran variedad de plataformas. Existen dos sistemas operativos BSD más que no son de código abierto, BSD/OS y el MacOS X de Apple: BSD/OS es el derivado más antíguo de 4.4BSD. No es código abierto pero es posible conseguir licencias de su código fuente a un precio relativamente bajo. Se parece a FreeBSD en muchos aspectos. Mac OS X es la última versión del sistema operativo para la gama Macintosh de Apple Computer Inc. El núcleo BSD Unix de éste sistema operativo, Darwin, está libremente disponible como sistema operativo de fuente abierto totalmente funcional para arquitecturas x86 y PPC. El sistema gráfico Aqua/Quartz y la mayoría de las demás aspectos característicos de Mac OS X son código cerrado. Varios desarrolladores de Darwin son también committers de FreeBSD y viceversa. ¿Qué diferencias hay entre la licencia BSD y la licencia pública GNU? Linux está disponible bajo la GNU General Public License (GPL), que fué diseñada para evitar el software cerrado. Más concretamente, cualquier trabajo derivado de un producto con licencia GPL debe suministrar el código fuente si es requerido. En contraste, la licencia BSD es menos restrictiva: permite la distribución en forma exclusivamente binaria. Éste aspecto es especialmente atractivo para aplicaciones empotradas. ¿Qué más debería saber? Dado que existen menos aplicaciones para BSD que para Linux los desarrolladores de BSD han creado un paquete de compatibilidad con Linux que permite hacer funcionar programas de Linux bajo BSD. El paquete contiene tanto modificaciones del kernel, con el fín de gestionar correctamente las llamadas al sistema de Linux, como ficheros necesarios para la compatibilidad con Linux como la Biblioteca C. No hay diferencias notables en velocidad de ejecución entre una aplicación de Linux ejecutándose en un sistema Linux y una aplicación Linux ejecutándose en un sistema BSD de la misma velocidad. El modelo todo del mismo proveedor de BSD implica que las actualizaciones son mucho más sencillas de gestionar de lo que con frecuencia son en Linux. BSD maneja las actualizaciones de versiones de bibliotecas suministrando módulos de compatibilidad para versiones anteriores, de modo que es posible ejecutar binarios con varios años de antiguedad sin problemas. Entonces ¿Qué debería usar, BSD o Linux? ¿Qué significa realmente esa pregunta? ¿Quién debería utilizar BSD y quién Linux?. Ésta es una pregunta muy difícil de responder. He aquí varias pautas: Si no está roto no lo arregles: Si ya usa un sistema operativo de código abierto y está satisfecho con él, probablemente no hay ninguna buena razón para cambiar. Los sistemas BSD, especialmente FreeBSD, pueden proporcionar un rendimiento notablemente superior que Linux, pero ésto no es una ley inmutable. En muchos casos no hay diferencia de rendimiento o ésta es muy pequeña. En algunos casos Linux podría tener un rendimiento mejor que FreeBSD. En general los sistemas BSD gozan de una mejor reputación en cuanto a disponibilidad, principalmente por la mayor madurez de su código base. La licencia BSD puede resultar más atractiva que la GPL. BSD puede ejecutar código de Linux, mientras que Linux no puede hacer lo propio con código de BSD. Como resultado de ésto hay una mayor cantidad de software disponible para BSD que para Linux. ¿Quién ofrece soporte, servicios y formación orientada a BSD? BSDi siempre ha ofrecido soporte para BSD/OS y en fechas recientes anunció contratos de soporte para FreeBSD. Además cada uno de los proyectos tiene una lista de consultores: FreeBSD, NetBSD, y OpenBSD.
diff --git a/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml b/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml index b58fa74aa0..73a2f8e7d1 100644 --- a/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml +++ b/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml @@ -1,725 +1,721 @@ -%man; - -%freebsd; + +%articles.ent; FreeBSD From Scratch"> - -%translators; ]>
FreeBSD From Scratch Jens Schweikhardt
schweikh@FreeBSD.org
2002 Jens Schweikhardt $FreeBSD$
&scratch.ap; explica la instalación totalmente automatizada de un sistema &os; hecho a medida y compilado desde las fuentes, proceso que incluye además la compilación de sus ports favoritos y configurado para coincidir con su idea del sistema perfecto. Si cree que make world es un concepto fascinante &scratch.ap; lo amplía hasta ser make evenmore. N. del T. : Juego de palabras intraducible basado en el nombre que en &os; se da al proceso de recompilar todo el sistema desde los fuentes, make world, que podría traducirse muy libremente como hacer, o más bien rehacer el mundo entero y make evenmore, osea, hacer más aún. &trans.es.carvay; Introducción ¿Ha actualizado alguna vez su sistema mediante make world?. Si solamente tiene un sistema en sus discos se encontrará con un problema. Si installworld falla a la mitad su sistema quedará dañado e incluso puede ser incapaz de arrancar de nuevo. O quizás installworld se ha ejecutado sin problemas pero el nuevo kernel no arranca. Se impone buscar el CD de Rescate y tratar de encontrar algo útil en aquellos backups que hizo hace seis meses. Creo en el paradigma de al actualizar sistemas operativos instala desde cero. Haciéndolo así, esto es, al borrar sobreescribiendo en los discos o mejor dicho las particiones, nos aseguraremos de no dejar datos antiguos en ellos, un aspecto éste del que la mayoría de los procesos de actualización no se preocupan en absoluto. Por otra parte borrar las particiones significa que tendrá que recompilar/reinstalar todos sus ports y packages y después de eso rehacer todas y cada una de las configuraciones que con muchos esfuerzos atesoraba. Si usted también piensa que ésta tarea debería automatizarse siga leyendo. ¿Por qué (no) debería interesarme &scratch.ap;? Esa es una pregunta muy razonable. Tenemos sysinstall, una compilación del kernel que funciona sin sorpresas y tenemos también las herramientas de entorno de usuario. El problema que tiene sysinstall es que está extremadamente limitado cuando se trata de qué, dónde y cómo queremos que haga la instalación. Normalmente se usa para instalar distribuciones precompiladas y packages desde diversas fuentes (CD, DVD, FTP). No puede instalar el resultado de make buildworld. No puede instalar un segundo sistema en un directorio de un sistema en funcionamiento. No puede hacer una instalación en particiones Vinum. No puede compilar ports, sólo instala packages precompilados. Es difícil automatizar mediante scripts o incluso hacer de forma manual los cambios que considere necesarios después de la instalación Por si todo esto fuera poco sysinstall está semioficialmente al final de su Ciclo de Vida Útil. El archiconocido proceso de construír/instalar el mundo (build/install world), explicado en el Handbook, por defecto realiza la tarea de sustituír el sistema existente. Sólo respeta el kernel y los módulos. Los binarios del sistema, los ficheros de cabecera y muchos otros ficheros son sobreescritos; hay ficheros obsoletos que se quedan donde estaban y pueden causar sorpresas. Si el proceso de actualización falla por alguna razón puede ser difícil o incluso imposible volver a dejar el sistema en el estado inicial. &scratch.ap; resuelve todos esos problemas. La estrategia es simple: utiliza un sistema en funcionamiento para instalar un nuevo sistema en un árbol de directorios y montar nuevas particiones limpiamente en ese árbol. Muchos ficheros de configuración pueden copiarse al sitio que les corresponda y &man.mergemaster.8; se encargará de aquellos a los que no. Pueden hacerse cambios discrecionales tras la instalación del nuevo sistema desde el viejo, como si el nuevo sistema estuviera dentro de un chroot. El proceso tiene tres fases, cada una de los cuales consiste en ejecutar un script de shell o invocar make: fase_1.sh: Crea un sistema nuevo y capaz de arrancar en un directorio vacío y combina o copia tantos ficheros como sea necesario. Una vez acabado esto arranca el nuevo sistema. fase_2.sh: Instala los ports que hayamos elegido. fase_3.mk: Remata la configuración del software instalado en la fase anterior. Una vez que ha usado &scratch.ap; para construír un segundo sistema y ha comprobado que funciona satisfactoriamente durante unas cuantas semanas puede usarlo de nuevo para reinstalar el sistema original. Desde ese momento cada vez que crea que debe actualizar un sistema simplemente elija las particiones que hay que borrar y reinstalar. Puede que haya oído hablar o incluso haya usado ya Linux From Scratch, LFS para ser más breve. LFS abarca también cómo construír e instalar un sistema desde cero en particiones vacías partiendo de un sistema en funcionamiento. El objetivo de LFS parece ser mostrar la razón de ser y de estar de todas y cada una de las partes del sistema (como el kernel, el compilador, los dispositivos, la shell, la base de datos de terminales, etc.) y los detalles de la instalación de cada parte. &scratch.ap; no entra en detalles tan exahustivos. Mi intención es facilitar una instalación automatizada y completa, no explicar cada detalle escabroso del ciclópeo proceso que arrancamos cuando hacemos un make world. Si desea usted explorar &os; de modo tan profundo comience por leer /usr/src/Makefile y siga cuidadosamente lo que sucede al teclear make buildworld. Hay también algunos detalles delicados con los que me encontré durante el desarrollo de &scratch.ap; que debería tener muy en cuenta. El sistema no puede ser usado normalmente durante la compilación de los ports que tiene lugar en la segunda fase. Si va a ejecutar el proceso en un servidor en producción tenga en cuenta el tiempo de parada provocado por la fase dos. Los ports compilados por fase_2.sh necesitan aproximadamente 4 horas para acabar en un sistema SCSI AMD1800+ con discos de 10.000 rpm y 1GB de RAM. Requisitos previos Para poder usar &scratch.ap; necesitará lo siguiente: Un sistema &os; con el árbol de ports y los fuentes instalados. Al menos una partición vacía donde instalaremos el nuevo sistema. Experiencia en el uso de &man.mergemaster.8; o al menos no tener miedo de usarlo. Si su acceso a Internet es lento o si no dispone del mismo necesitará los distfiles de los ports que vaya a instalar. Conocimientos básicos de confección de scripts de shell con la shell Bourne, &man.sh.1; Finalmente, debería ser capaz de decirle a su boot loader (cargador de arranque) cómo arrancar el nuevo sistema, en modo interactivo o mediante un fichero de configuración. Primera Fase: Instalación del Sistema Lo que vamos a explicar más adelante es mi fase_1.sh. Tendrá que modificarlo en varios sitios para que cuadre con su propia idea del sistema perfecto. He intentado incluír todos los comentarios posibles en los sitios donde debería usted introducir sus cambios. Los puntos a estudiar son: Esquema de particiones. No estoy de acuerdo con la idea de una sola partición inmensa en la que instalar todo el sistema. Mis sistemas tienen generalmente al menos una partición para /, /usr y /var con /tmp enlazado simbólicamente a /var/tmp. Además comparto los sistemas de ficheros en los que ubico /home (los directorios de los usuarios), /home/ncvs (réplica del repositorio de &os;, /usr/ports (el árbol de ports), /src (diversos árboles de fuentes de procedencias varias) y /share (otros datos compartidos que no necesitan ser guardados, por ejemplo mensajes de news. Lujos. Me refiero a lo que usaremos inmediatamente tras el arranque del nuevo sistema e incluso antes de la segunda fase. En mi caso se trata de shells/zsh puesto que es la shell que aparece en mi cuenta de usuario en /etc/passwd. De todos modos la tarea puede culminarse sin esos lujos (de ahí su nombre), todo lo que necesita es entrar en el sistema como root y pasar a la siguiente fase. ¿Por qué no instalar entonces todos mis ports en la primera fase?: en teoría y en la práctica nos encontraremos con problemas de arranque y de consistencia: durante la primera fase tendrá funcionando su viejo kernel mientras el entorno chroot dispone de sus propios binarios y ficheros de cabecera todos nuevos. Si por ejemplo el sistema nuevo integra una nueva llamada al sistema (conforme a sus cabeceras) algunos scripts de configuración podrían intentar usarla y en concuencia ver muertos sus procesos al tratar de ejecutarse en el viejo kernel. He tenido problemas de otro tipo al intentar construír lang/perl5. Antes de ejecutar fase_1.sh asegúrese de haber cumplido con las tareas previas a un make installworld installkernel, es decir: haber adaptado el fichero de configuración de su kernel haber completado sin errores make buildworld haber completado sin errores KERNCONF= nombre_de_su_kernel Cuando ejecute fase_1.sh por primera vez y copie sus ficheros de configuración de su sistema en funcionamiento a su nuevo sistema no están al día con respecto a lo que hay bajo /usr/src, así que mergemaster le preguntará por lo que quiere hacer. Le recomiendo combinar los cambios. (Nota del traductor: merge (to): unir, fusionar, mezclar). Si se cansa de pelear con los diálogos de mergemaster puede simplemente actualizar sus ficheros una vez en el sistema original (pero sólo si existe esa opció: por ejemplo, si uno de sus sistemas usa -STABLE y el otro -CURRENT los cambios tienen bastantes probabilidades de ser incompatibles). En posteriores usos de mergemaster detectará que los ID de las versiones RCS de esos ficheros coinciden con los que están bajo /usr/src y no les prestará más atención. El script fase_1.sh detendrá su ejecución si falla alguno de los comandos que contiene (si alguno da una salida distinta de cero) por incluír set -e, así que es imposible que pase por alto algún error. Antes de seguir adelante debería asegurarse de que no hay errores en su versión de fase_1.sh. En fase_1.sh invocamos mergemaster. Tanto si alguno de los ficheros requiere ser combinado como si no, mergemaster emitirá el siguiente mensaje *** Comparison complete Do you wish to delete what is left of /var/tmp/temproot.fase1? [no] no es decir *** Comparación completada ¿Quiere borrar el contenido de /var/tmp/temproot.fase1? [no] no Por favor, responda no o simplemente pulse Enter. Eso es debido a que mergemaster habrá dejado unos cuantos ficheros de longitud igual a cero en /var/tmp/temproot.fase1 y los copiará al nuevo sistema (a menos que ya estén ahí). Después mostrará los ficheros que ha instalado mediante &man.more.1; o si lo prefiere mediante &man.less.1;): *** You chose the automatic install option for files that did not exist on your system. The following were installed for you: /rootnuevo/etc/defaults/rc.conf ... /rootnuevo/COPYRIGHT (END) es decir *** Ha elegido la opción de instalar automáticamente los ficheros que no existen en su sistema. Han sido instalados los siguientes: /rootnuevo/etc/defaults/rc.conf ... /rootnuevo/COPYRIGHT Teclée q para salir del paginador. Ahora se le informará sobre login.conf: *** You installed a login.conf file, so make sure that you run '/usr/bin/cap_mkdb /newroot/etc/login.conf' to rebuild your login.conf database Would you like to run it now? y or n [n] es decir *** Ha instalado un fichero login.conf así que asegúrese de ejecutar '/usr/bin/cap_mkdb /rootnuevo/etc/login.conf' para reconstruír la base de datos de login.conf ¿Quiere ejecutarlo ahora mismo? (s)i o (n)o [n] La respuesta no tiene importancia puesto que ejecutaremos &man.cap.mkdb.1; en todos los casos. Todo lo que hace fase_1.sh queda registrado en un fichero log para que pueda examinarse con detalle si es preciso. Éste es el fase_1.sh del autor, así que tendrá que modificarlo a conciencia, en especial los pasos 1, 2, 5 y 6. Por favor, ponga una atención esmerada a las entradas en las que aparece &man.newfs.8;. Si bien es cierto que es imposible crear nuevos sistemas de archivos en particiones montadas nuestro script no tendrá ningún inconveniente en borrar cualquier partición que no esté montada y con los nombres que aparezcan en él, en nuestro caso /dev/da3s1a, /dev/vinum/var_a y /dev/vinum/usr_a. Puede provocar un desastre, así que asegúrese de cambiar los nombres de los dispositivos como corresponda. Descargue fase_1.sh. La ejecución de éste script instala un sistema equipado con lo siguiente: Usuarios y grupos heredados del anterior sistema. Acceso a Internet mediante Ethernet y PPP protegido por un cortafuegos. NTP y zona horaria correctas. Algunos ficheros secundarios como /etc/ttys e inetd. Hay otras áreas listas para ser configuradas pero no las tocaremos hasta concluír la segunda fase. Por ejemplo, hemos copiado unos cuantos ficheros para configurar la impresión y X11. Sin embargo la impresión suele necesitar de aplicaciones que no se encuentran en el sistema base, por ejemplo PostScript. X11 no funcionará hasta que no compilemos el servidor, las bibliotecas y los programas. Segunda Fase: Instalación de <quote> ports</quote> En ésta fase es posible instalar packages (que vienen precompilados) en lugar de compilar ports. Para poder hacerlo convertiremos fase_2.sh en poco más que una lista de comandos pkg_add. Confío en que será usted capaz de escribir un script como ese. Ahora nos concentraremos en el sistema tradicional y mucho más flexible de funcionamiento de los ports. El siguiente script fase_2.sh es el que yo uso para instalar mis ports favoritos. Puede ejecutarse tantas veces como sea preciso y no prestará atención a los ports que ya estén instalados. Incluye también soporte para la opción que hace un ensayo general con todo, es decir, muestra lo que hubiera sucedido si se hubiera ejecutado. Seguro que tiene que editar la lista de ports y probablemente tenga que cambiar unas cuantas variables de entorno. La lista de ports consiste en líneas de dos o más palabras separadas por espacios: la categoría y el port. Es opcional situar detrás un comando de instalación que compilará e instalará el port (por defecto make install). Se ignoran las líneas vacís y las que comienzan por #. La mayoría de las veces es suficiente incluír el nombre del port y la categoría a que pertenece pero existen unos pocos ports en cuya compilación podemos afinar mucho asignando valores a variables de make; veamos un ejemplo: www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install mail procmail make BATCH=yes install De hecho puede usted usar comandos de shell a su criterio, así que no tiene que limitarse a simples invocaciones de make: java linux-sun-jdk13 yes | make install news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install Observe que la línea de news/inn-stable es un ejemplo de una asignación de entrada a la variable del intérprete de mandatos CONFIGURE_ARGS. El fichero Makefile del port la usará como valor inicial y la completará con otros argumentos esenciales. La diferencia respecto a a especificar la variable para make en la línea de comandos mediante news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install está en que esto último sustituye directamente el valor en lugar de completarlo. El método más adecuado depende de cada port en particular. Compruebe cuidadosamente que ninguno de sus ports tenga una instalación interactiva, es decir, que ninguno deberí intentar recibir de stdin nada que no le dé usted en stdin. Si alguno lo hace leerá la siguiente o siguientes líneas de éste documento y no entenderá nada de nada. Si fase_2.sh pasa por alto un port o cesa su ejecución sin razón aparente es muy posible que esa sea la razón. He aquí fase_2.sh. Crea un fichero log por cada port que instala y les da nombres según el esquema DIRECTORIO_LOG/categoría+port. Si no tiene una copia de su fase_2.sh en una partición compartida no olvide copiarlo al sistema nuevo antes de arrancarlo. Descargue fase_2.sh. Tercera Fase Ya hemos concluído la segunda fase y ya están instalados sus queridísimos ports, pero algunos de ellos requieren un poco de configuración. En eso consistirá la tercera fase, añadir los detalles específicos de las configuraciones. Podría haberlos integrado en el script fase_2.sh pero creo que hay una diferencia conceptual entre instalar un port y en modificar la configuración con la que viene por defecto para adaptarla a nuestros gustos o necesidades y creo por lo tanto que esa diferencia justifica una separación en una fase propia. He creído más conveniente implementar la tercera fase como un Makefile porque admiten la selección de lo que quiera configurar tecleando simplemente: &prompt.root; make -f fase_3.mk nombre_del_port Al igual que con fase_2.sh asegúrese de que dispone de una copia de su fase_3.mk una vez que arranca el sistema nuevo, bien situándolo en una partición compartida bien copiándolo en algún lugar dentro del nuevo sistema. Descargue fase_3.mk. Restricciones La instalación automatizada de un port puede resultar difícil si es interactiva y no soporta make BATCH=YES install. En algunos casos la interacción se reduce a teclear yes cuando se le pregunta si acepta alguna licencia. Si esa entrada de datos ha de llegar por la entrada estándar simplemente redirigiremos las respuestas pertinentes a la orden de instalación (que suele ser make install; ese es el modo en el que hemos procedido con java/linux-sun-jdk13 en fase_2.sh). No obstante ésta estrategia no funciona con editors/staroffice52, que exige que X11 esté funcionando. El proceso de instalación comprende un buen número de pulsaciones de ratón y de tecleo, con lo que es imposible automatizarlo tal y como se hace con otros ports. Sin embargo el siguiente atajo workaround nos soluciona el problema: previamente he creado un staroffice en el sistema original con &prompt.root; cd /usr/ports/editors/staroffice52 &prompt.root; make package ===> Building package for staroffice-5.2_1 Creating package /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz Registering depends:. Creating bzip'd tar ball in '/usr/ports/editors/staroffice52/staroffice-5.2_1.tbz' y durante la segunda fase usamos: &prompt.root; pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz Debe usted también tener muy en cuenta posibles problemas con los ficheros de configuración a la hora de actualizar. En general no sabemos cuándo van a hacerse cambios en el formato o el contenido de un fichero de configuración. Es posible que haya que añadir un nuevo grupo a /etc/group, o quizás /etc/passwd necesite un nuevo campo en sus entradas. Éstas cosas han sucedido en alguna ocasión anteriormente. Si simplemente copiamos un fichero de configuración del sistema viejo al nuevo será suficiente la mayoría de la veces pero ya hemos visto dos casos en los que no lo era. Si actualiza su sistema siguiendo el sistema ortodoxo (sobreescribiendo los ficheros antíguos) tendrá que usar mergemaster para proceder con los cambios que quiera incluír en la configuración de su nuevo sistema, teniendo en cuenta que entre esos cambios hay o puede haber nuevos ficheros. Por desgracia mergemaster sólo es útil con ficheros del sistema base y no para aquellos relacionados con los ports. Además, ciertas aplicaciones parecen especialmente diseñadas para sacarme de mis casillas por el procedimiento de cambiar el fichero de configuración cada quince días. Lo único que puede hacerse es estar alerta, sobre todo cuando cambia el número de versión. En ocasiones anteriores he tenido que modificar o reescribir ficheros para servidores web, servidores y clientes de news. Cualquier tipo de software cuyo mantenimiento sea muy activo es un firme candidato a que sus ficheros de configuración merezcan nuestro examen. He usado &scratch.ap; varias veces para actualizar un sistema 5-CURRENT a 5-CURRENT, esto es, nunca he intentado instalar 5-CURRENT desde un sistema 4-STABLE o viceversa, pero dada la cantidad de cambios existentes entre las diferentes RELEASE no sería insensato esperar que esa tarea sea un tanto compleja. Usar &scratch.ap; para actualizaciones dentro del campo de 4-STABLE debería ser mucho menos penoso (aunque yo aún no lo he intentado). Si quiere hacerlo debería tener en cuenta lo siguiente: Si no usa el sistema de ficheros de dispositivo (devfs) puede necesitar crear los dispositivos necesarios para su hardware con &man.MAKEDEV.8; en la primera fase, sexto paso.
diff --git a/es_ES.ISO8859-1/articles/fdp-es/article.sgml b/es_ES.ISO8859-1/articles/fdp-es/article.sgml index 3855cb94aa..97c91f3475 100644 --- a/es_ES.ISO8859-1/articles/fdp-es/article.sgml +++ b/es_ES.ISO8859-1/articles/fdp-es/article.sgml @@ -1,634 +1,624 @@ -%man; - -%freebsd; - -%mailing-lists; - -%es-mailing-lists; - -%authors; - -%translators; + +%articles.ent; ]>
Introducción al FDP-es J. Vicente Carrasco Vayá
carvay@FreeBSD.org
Este documento ha sido escrito para que sirva de guía somera a quienes quieren colaborar con &os; traduciendo documentación o alguna sección de la web de &os; al castellano. &os; es un proyecto que crece diariamente gracias al trabajo voluntario de miles de personas de todo el mundo. La traducción de documentación y de la web supone una enorme ayuda para quienes se acercan a &os; y no saben inglés (o alguna de las lenguas a las que ya esá traducido todo o parte de dicho material). Casi cualquier persona puede ayudar en alguna tarea. Si quiere colaborar reciba nuestra más calurosa bienvenida y siga leyendo. Este documento no pretende ser exhaustivo. Casi toda la información necesaria para trabajar en el FDP está en el libro fdp-primer (que esperamos poder tener traducido algún dia) y en cuya sección de estilo está basada gran parte de este texto. Si quiere ampliar los conocimientos que aquí se esbozan (y si va a trabajar con la documentación de &os; seguramente querrá hacerlo) le rogamos que lo lea cuidadosamente. Recuerde que cualquier duda que pudiera salirle al paso mientras trabaja en la documentación de &os; puede enviarla a la &a.es.doc; Si tiene alguna sugerencia, crítica o duda relacionada con este artículo no dude en escribir al autor.
El FDP-es El &os; Spanish Documentation Project (en adelante FDP-es) tiene las siguientes funciones: Mantener al día la documentación existente en castellano e ir traduciendo más siempre que los recursos lo permitan. Traducir y mantener la web http://www.freebsd.org/es/. Desarrollar documentos propios como éste. Tareas pendientes Glosario: Confección y Mantenimiento de un Glosario de términos frecuentes en la Documentación para ayuda y referencia del traductor. Páginas man: El Proyecto de Documentación de &os; también se encarga de desarrollar, mantener y corregir las páginas man del sistema pero debido a la escasez de voluntarios es una tarea que (siendo muy optimistas) preferimos pensar que podremos acometer a medio o largo plazo. Scripts accent2xml y xml2accent. Existen dos scripts que traducen los caracteres que no existen en inglés a código sgml; por ejemplo a á, a ¿, etcétera. Sería muy útil disponer de sus homólogos xml para facilitar el trabajo de aquellas personas que traducen secciones de la web y (cosa poco sorprendente) no conozcan de memoria todos los secretos de xml. Cómo formar parte del FPD-es Casi cualquier persona puede formar parte del FDP-es. Igual que sucede en el FDP no hay cuota mensual que haya que pagar ni una cantidad mensual o anual de material que haya que traducir de forma obligatoria. Basta con suscribirse a la &a.es.doc;. Puede aportar sus conocimientos de inglés para ayudar con las dudas de quienes están traduciendo o quizás pueda dedicar un poco de su tiempo a traducir. Asignación de trabajos Al depender del esfuerzo voluntario es lógico que cada cual pueda elegir qué parte de la web o de la documentación desea traducir. Dentro de poco esperamos disponer de una página web pública en la que poder consultar qué textos están asignados y desde cuando. De momento el procedimiento es el siguiente: la persona interesada en traducir elige un texto que desea traducir y dos alternativas por si su primera elección ya está asignada el coordinador de traducciones le asigna el texto el texto traducido es revisado e incluído en el repositorio del FDP-es primero y en el del FDP después. Si puede dedicar un poco de tiempo Puede traducir una sección de la web, un capítulo del handbook o un artículo y entregarlo en formato ASCII (texto plano). Tenga en cuenta que alguien tendrá que darle formato (DocBook o xml en el caso de la web). Será de grandísima ayuda si entrega su trabajo con los acentos, eñes y demás signos característicos de nuestro idioma corregidos al formato adecuado. Consulte la tabla que encontrará en http://www.theorem.ca/~mvcorks/code/charsets/latin1.html o utilice el script perl accent2sgml.pl ubicado en doc/share/examples/vim/. La parte más difícil del trabajo es sin duda alguna la traducción pero si pudiera avanzar trabajo adaptando en lo posible la sintaxis del texto a sgml o xml (o maquetándolo usted, pruébelo: no es difícil) aligerará notablemente la carga de trabajo de unos cuantos (y mortales) voluntarios y voluntarias. Tenga en cuenta que no sobra precisamente el personal para estas tareas y enfrentarse a convertir un texto ASCII de 5.000 líneas a DocBook puede hacer flaquear al voluntario más comprometido. Con un poco más de tiempo La forma ideal de entrega de trabajos al FDP-es es enviarlos listos para incluir en el árbol cvs de &os;. Si tiene un especial interés en un texto en concreto puede encargarse de su mantenimiento (es lo que llamamos apadrinar ese texto). En poco tiempo se convertirá en su mejor conocedor y no le resultará difícil ir añadiendo los cambios a medida que se vayan produciendo en el original. De este modo al menos una fracción de la documentación tendrá más posibilidades de estar al dia;-) Colaboración esporádica En la &a.es.doc; hay personas que colaboran resolviendo dudas que surgen a los traductores. Si por el motivo que fuera no quiere o no puede traducir textos no debería subestimar la importancia de la ayuda que puede prestarse de este modo. Gracias a estas personas los traductores encuentran más argumentos a favor o en contra de traducir ciertos términos, con lo que la documentación resulta más útil; y nuestro trabajo consiste en hacer algo útil. ¿Todo el mundo puede traducir? En principio sí, pero no necesariamente. Le recomendamos que si quiere traducir documentación se familiarice con otros textos ya traducidos y comience por colaborar con las dudas de los traductores en la &a.es.doc;. La documentación de &os; goza de una merecida fama de calidad, lo que hace que el trabajo de un proyecto de traducción como el nuestro implique una gran responsabilidad. Es imposible mantener una fidelidad absoluta al original, pero dentro de lo posible lo intentamos. Al tratarse de textos técnicos hay que tener muy presente al traducirlos que sin duda alguna van a ser utilizados como guía. Se suele exigir a los recién llegados a &os; que lean la documentación relacionada con sus dudas antes de preguntar dudas, así que, al menos en teoría, lo que usted traduzca tendrá ávidos lectores. Tenga esto muy presente al traducir: mejor preguntar una duda de más en la &a.es.doc; que incluir información errónea en un texto. Se estará preguntando ¿cuál es el perfil necesario para traducir? La verdad es que no hay un acuerdo sobre esto. Es obvio que necesita comprender el inglés técnico (americano) en el que está escrita la documentación de &os;, También puede traducir desde alguno de los idiomas en los que hay documentación de &os;. Puede echar un vistazo a los textos traducidos a distintas lenguas en http://www.es.FreeBSD.org/doc/. y por supuesto sólidos conocimientos de castellano. Dicho de otro modo, no es imprescindible hablar inglés, basta con comprenderlo lo mejor posible, pero es imprescindible la expresión escrita en castellano. La calidad de una traducción es algo totalmente subjetivo, pero suele haber acuerdo entre los miembros de la lista entre lo que es asumible es decir, lo que podemos subir al cvs para que cualquiera pueda verlo repartido por los sitios web de &os; del mundo entero y lo que no lo es. El trabajo de arreglar una mala traducción puede ser igual de largo que traducir desde cero un texto y es varios órdenes de magnitud más penoso. Encontrar un buen traductor de textos técnicos es tanto o más difícil que encontrar un buen programador, como sabe cualquiera que haya abierto más de una docena de libros técnicos traducidos a nuestro idioma Si es su caso, ya sabe a ciencia cierta que tener una o más carreras, técnicas o no, no evita que alguien sea capaz de perpetrar traducciones abominables y además cobrar por ello. Nosotros no pagamos, pero somos mucho más estrictos. Cuando envíe un texto traducido para su revisión es posible que, aunque ponga mucho cuidado para evitarlo, aparezcan errores en el código SGML o en el propio texto. El trabajo de revisión consiste precisamente en eso así que no se preocupe, dentro de la ayuda esporádica que algunas personas ofrecen al FDP-es está la de revisar textos de otros. Un voluntario depurará el texto en caso de que haga falta y lo dejará listo para subir al cvs es posible que el revisor le devuelva el texto si las modificaciones que hay que hacer son muchas y usted mismo puede hacerlas) . Guía de estilo Esta sección están basada en la sección writing style del libro fdp-primer que puede consultarse en (). Es necesario intentar mantener la consistencia entre la multitud de autores que trabajan en la Documentación de &os;, razón por la cual se han creado unas líneas generales. A esta búsqueda de la consistencia se opone también la variedad de orígenes de los traductores de la Documentación, por lo que se listan aquí unas cuantas normas que pueden ser de ayuda. Dado que la Documentación que va a traducir ya ha pasado por más de una mano experta puede usarla como plantilla para su traducción. Idioma El idioma oficial del FDP-es es el castellano (o español de España), es_ES; la decisión de tener lengua oficial no es una idea exclusiva nuestra puesto que en el el Proyecto de Documentación de &os; el idioma oficial es el inglés de los Estados Unidos de América (en_US). Se intenta evitar el uso de palabras agresivas con otros castellanoparlantes como ordenador (computador, computadora, sistema, máquina o incluso host) pero al iniciar los trabajos necesitaban una norma y lógicamente usaron la que la que más cerca tenían. Evite frases redundantes Intente evitar usar frases redundantes. Por ejemplo el comando, el fichero y man comando probablemente son redundantes. He aquí dos ejemplos en el caso de los comandos. El segundo ejemplo mostrado es el recomendable. Utilice el comando cvsup para actualizar sus fuentes Utilice cvsup para actualizar sus fuentes Veamos dos ejemplos para nombres de ficheros. Recomendamos el uso del segundo ejemplo. … en el fichero llamado /etc/rc.local … en /etc/rc.local Veamos un ejemplo sobre páginas man. Recomendamos el uso del segundo caso, que usa citerefentry. Para más información consulte man csh. Consulte &man.csh.1; Dos espacios al final de cada frase Deje siempre dos espacios al final de cada frase. El texto será más legible y se facilita el uso de herramientas como Emacs. Puede pensarse que una mayúscula tras un punto indica nueva frase pero no siempre es así, sobre todo si se trata del nombre de algunas personas. Jordan K. Hubbard es un buen ejemplo de ello. Tiene una H mayúscula tras un punto y un espacio y es evidente que no es una nueva frase. Guía de sintaxis Por favor, siga éstas sencillas reglas para facilitar el trabajo de toda la gente que mantiene el código fuente de la documentación. Minúsculas Las etiquetas van siempre en minúsculas: <para>, no <PARA>. El texto SGML normalmente se escribe en mayúsculas: <!ENTITY…> y <!DOCTYPE…>, no <!entity…> o <!doctype…>. Sangrado Cada fichero comienza con un sangrado nulo, es decir, en la columna 0, sin tener en cuenta el nivel de sangrado del fichero que pueda contenerlo. La apertura de etiquetas incrementa el nivel de sangrado en 2 espacios. Reemplace los bloques de 8 espacios al inicio de una línea con una tabulación. No use espacios antes de una tabulación y no añada espacios al final de una línea. El contenido que esté entre elementos debe sangrarse en dos espacios si el contenido ocupa más de una línea. Por ejemplo, el código fuente de esta sección es algo parecido a esto: ... Sangrado Cada fichero comienza con un sangrado nulo, es decir, en la columna 0, sin tener en cuenta el nivel de sangrado del fichero que pueda contenerlo. ... ]]> Si usa Emacs o XEmacs para editar ficheros que forman parte de la Documentación se cargará automáticamente el sgml-mode y las variables locales que Emacs encontrará al principio de cada fichero podrán utilizarse. Si usa Vim puede serle muy útil incluir lo siguiente en la configuración de su editor: augroup sgmledit autocmd FileType sgml set formatoptions=cq2l " Opciones especiales de formato autocmd FileType sgml set textwidth=70 " Corta las lìneas a 70 espacios autocmd FileType sgml set shiftwidth=2 " Sangra automáticamente autocmd FileType sgml set softtabstop=2 " Tabulación = 2 espacios autocmd FileType sgml set tabstop=8 " Reemplaza 8 espacios con Tab autocmd FileType sgml set autoindent " Sangrado automático augroup END Etiquetas Espacios en las etiquetas Las etiquetas que comienzan en el mismo nivel de sangrado que la etiqueta anterior deben separarse con una línea en blanco, y las que no están al mismo nivel de sangrado que la anterior no: NIS Octubre 1999 ... ... ... ... ... ... ...
]]> Trato al lector o lectora Cuando hay que dirigirse al lector o lectora siempre usamos el usted, habitual en muchos países en cualquier ámbito y respetuoso en cualquiera de los demás. Como puede verse en el título existe también el problema del género de quien lee el texto; casi siempre hay una manera de evitar usarlo (buscando bien) pero puede alternarse el uso del género. Evitamos el uso de la forma lector/a, programador/a, etcétera, que a costa de una pretendida corrección política convierte a los textos en algo bastante más difícil de leer. Léxico Es muy importante intentar evitar argot, giros, dichos o bromas exclusivos de un sólo país, región, ciudad o grupo social. La Documentación será leída por gentes muy diversas en cualquier lugar del mundo y puede ser muy frustrante que lo que uno quiere hacer esté documentado pero no lo podamos entender por no haber viajado suficiente. Ayuda Lista doc@es.FreeBSD.org La &a.es.doc; es el lugar ideal para enviar: dudas de traducción ideas, sugerencias, críticas sobre la documentación (en castellano o relacionadas con la Documentación en inglés) errores en la generación de documentación Diccionarios en Internet Existen muchos diccionarios en Internet y en bastantes de ellos podemos consultar términos gratuitamente. Las palabras más técnicas y muchas exclusivas de &os; no aparecerán en ninguno de estos diccionarios y en pocos de los editados en papel, por lo que tendrá que recurrir a otros documentos ya traducidos o a la &a.es.doc;. Envío de traducciones Por correo electrónico al coordinador, o bien si lo considera conveniente, enviarlo a la &a.es.doc; para su revisión. &man.send-pr.1; Voluntarios del FDP-es Estos son los colaboradores habituales del FDP-es. Si cree que su nombre debe (o no debe) aparecer en esta lista puede escribir al autor. (en orden alfabético por apellido): &a.es.baz; &a.es.carvay; &a.es.cronopio; &a.es.jcamou; &a.jesusr; &a.es.jrh; &a.es.quique; Agradecimientos A la &a.es.doc; por su infinita paciencia durante las revisiones de este documento (y desde mucho antes) y a &a.jesusr; por lo mismo y además por animarme. Que tiene delito. diff --git a/es_ES.ISO8859-1/articles/laptop/article.sgml b/es_ES.ISO8859-1/articles/laptop/article.sgml index 93d0e2eb30..083deecb3f 100644 --- a/es_ES.ISO8859-1/articles/laptop/article.sgml +++ b/es_ES.ISO8859-1/articles/laptop/article.sgml @@ -1,372 +1,361 @@ -%man; - - -%freebsd; - - -%authors; - - -%mailing-lists; - -%translators; + +%articles.ent; ]>
FreeBSD en ordenadores portátiles $FreeBSD$ FreeBSD funciona perfectamente en la mayoría de portátiles aunque siempre haya excepciones. En éste artículo trataremos de las diferencias existentes en el hardware de portátiles y sistemas de escritorio y de cómo afecta esto al uso de FreeBSD. &trans.es.bazcar; Es frecuente que se piense en FreeBSD como un sistema operativo para servidores pero funciona muy bien como sistema de escritorio y si quiere usarlo en su portátil dispondrá de todo su potencial: facilidad de administración y actualización, el sistema de ports y packages para añadir software, etc. Otras de sus características más interesantes, como la estabilidad, el rendimiento en red y bajo grandes cargas de trabajo pueden, por razones obvias, no ser tan evidentes en un sistema portátil. La instalación en portátiles puede, sin embargo, acarrear problemas que no encontraríamos en sistemas de escritorio y cuyas soluciones no podemos encontrar por doquier a lo largo y ancho de Internet; los equipos portátiles suelen estar diseñados para Microsoft Windows, aún con más frecuencia que en sistemas de escritorio. Éste artículo tratará de aclarar alguno de estos problemas. Hay quien ha documentado sus experiencias con &os; en modelos concretos de portátiles y las ha incluído en páginas web que no forman parte de la documentación oficial de &os;. Es muy posible que encuentre información si introduce la marca y modelo de su portátil y la palabra &os; en un buscador. XFree86 Las versiones recientes de XFree86 funcionarán con la mayoría de tarjetas gráficas disponibles actualmente en portátiles. La aceleración gráfica tal vez no esté soportada pero una configuración SVGA genérica debería funcionar. Consulte la documentación de su portátil. Ahí deberí encontrar todos los detalles de su tarjeta, tras lo cual debería recurrir a la documentación de XFree86 (o el programa de configuración) para saber si está soportada o no. Si no lo está utilice un dispositivo genérico pero NO use uno cuyo nombre simplemente le resulte parecido. En la versión 4 de XFree86 puede probar suerte tecleando XFree86 -configure, que ejecuta un proceso de autodetección y le puede facilitar una gran cantidad de información muy útil. Con frecuencia el problema es la configuración del monitor. La información sobre XFree86 se centra en monitores CRT, por lo que disponer de una configuración para una pantalla LCD puede ser peliagudo. Quizás esté de suerte y no tenga que especificar rangos de HorizSync y VertRefresh. Si esto no funciona la mejor opción es recurrir a la web en busca de páginas dedicadas a la configuración de X en portátiles; suelen estar orientadas a Linux pero no importa dado que ambos sistemas operativos usan XFree86, por lo que puede usar la configuración que alguien haya usado sobre un hardware similar. La mayoría de portátiles incluyen dos botones para las funciones de botón primario y secundario del ratón (mouse), lo que puede resultar problemático en X ya que el botón central se usa para pegar texto; puede mapear una pulsación simultánea de ambos botones en la configuración de X que realice la función del botón central con la línea Option "Emulate3Buttons" en el fichero XF86Config en la sección InputDevice de XFree86 versión 4; para la versión 3 simplemente añada la línea Emulate3Buttons, sin comillas, en la sección Pointer . Modems Los equipos portátiles suelen incluír modems internos. Desgraciadamente eso casi siempre significa que son winmodems cuyo funcionamiento depende de software y para los cuales sólo hay disponibles controladores para windows. A pesar de ello están empezando a aparecer controladores para otros sistemas operativos; por ejemplo, si su modem tiene un chipset Lucent LT es muy posible que esté soportado por el port comms/ltmdm. Si ese no es su caso tendrá que buscar un modem externo: la solución más compacta probablemente sea un modem PC Card (PCMCIA), de los que hablaremos más adelante, pero los modem serie o USB serán seguramente más baratos. Normalmente los modems normales (es decir, los que no son winmodems), deberían funcionar sin problemas. Dispositivos PCMCIA (PC Card) Muchos portátiles incluyen bahías PCMCIA, también conocidas como PC Card, que suelen estar soportadas perfectamente por FreeBSD. Consulte el mensaje de arranque de su sistema (mediante &man.dmesg.8;) para saber si fueron detectadas correctamente; deberían figurar como pccard0, pccard1 etc. en dispositivos como pcic0). &os; 4.X soporta tarjetas PCMCIA de 16 bits y &os; 5.X soporta tanto éstas tarjetas de 16 bits como tarjetas de 32 bits CardBus. Hay una lista de tarjetas soportadas en el fichero /etc/defaults/pccard.conf. Léalo cuidadosamente y siempre que sea posible compre tarjetas que aparezcan en ese fichero. Las que no aparecen es posible que funcionen como dispositivos genéricos; en concreto la mayoría de los modem de 16 bits deberían funcionar correctamente siempre y cuando no sean winmodems (existen también como PC Cards, así que tenga cuidado). Si su sistema reconoce su tarjeta como un modem genérico tenga en cuenta que el fichero pccard.conf especifica por defecto un retardo de 10 segundos para evitar bloqueos en algunos modelos; eso puede ser una precaución excesiva para su modem así que es posible que quiera cambiar ese valor, reducirlo o incluso eliminarlo. Algunas partes de pccard.conf pueden necesitar un poco de edición. Busque la línea donde figura la irq y asegúrese de eliminar cualquier número que esté en uso; si tiene una tarjeta de sonido integrada borre irq 5, si no puede sufrir bloqueos del sistema al insertar la tarjeta. Consulte también la memoria disponible para las bahías; si su tarjeta sigue sin ser detectada pruebe a cambiar alguno de los valores posibles que aparecen en la página man de &man.pccardc.8;. Si aún no funciona puede lanzar el daemon &man.pccardd.8;. Para activarlo en el arranque añada pccard_enable="YES" en el fichero /etc/rc.conf. Tras ese paso sus tarjetas deberían ser detectadas cuando las inserte y cuando las extraiga; deberían asímismo aparecer entradas en ficheros log reflejando el momento en el que los nuevos dispositivos son activados. Ha habido cambios de gran calado en el código de pccard, como la inclusión de enrutado de interrupciones ISA, muy útil en máquinas en las que hasta la irrupción de FreeBSD 4.4 no era posible usar la BIOS PCI. Si tiene problemas con esto pruebe a actualizar su sistema. Administración de energía Desgraciadamente no existe un soporte demasiado bueno en FreeBSD. Si tiene suerte algunas características pueden ser funcionales mientras que otras no lo serán en absoluto. Para complicar un poco más las cosas hay dos estándares de administración de energía, APM y ACPI. El segundo se hizo para sustituír el primero e incluye nuevas características pero también más problemas. Algunos portátiles soportan tanto APM como ACPI (hasta cierto punto) mientras que otros sólo soportan uno de ellos así que no tendrá más remedio que experimentar con ambos para saber si dispone de administración de energía y hasta qué punto. No puede tener APM y ACPI activados simultáneamente, aunque su portátil soporte ambos. APM Una BIOS con APM (Advanced Power Management, Administración Avanzada de Energía) provée de soporte para diversas características de administración de energía tales como standby, suspensión, hibernación, reducción de la velocidad del reloj de la CPU, etc. y existe tanto en &os; 4.X como en &os; 5.X. Para activar el soporte de APM deberá compilar su kernel: añada device apm0 en &os; 4.X y device apm en &os; 5.X. El soporte APM como módulo existe en &os; 5.X; para cargarlo en el arranque añada la línea apm_load="YES" al fichero /boot/loader.conf. En &os; 5.X tendrá que asignar hint.apm.0.disabled="0" en el fichero /boot/device.hints. APM puede activarse en el arranque añadiendo apm_enable="YES" en el fichero /etc/rc.conf. El daemon &man.apmd.8; se puede lanzar añadiendo apmd_enable="YES" al fichero /etc/rc.conf, que se encarga de transmitir ciertos eventos a la BIOS, de manera que sea posible suspender/reanudar presionando alguna tecla concreta o al abrir y al cerrar la pantalla. Los comandos APM figuran en la página man de &man.apm.8;. Por ejemplo apm -b suministra el estado de la batería (o 255 si no está soportado), apm -Z pone el portátil en standby, apm -z (o zzz) lo suspende. Para apagar el sistema use shutdown -p. Le recordamos una vez más que alguna o incluso todas éstas funciones pueden no funcionar del todo bien o incluso no hacerlo en absoluto. Es posible que la suspensión o el modo standby funcione en consola pero no en X (esto es, la pantalla no se recupera). Si usa &os; 5.X una posible solución es añadir options SC_NO_SUSPEND_VTYSWITCH al fichero de configuración de su kernel y que lo recompile. Otra forma de solucionarlo es cambiar a otra consola virtual (mediante CtrlAltF1 u otra tecla de función) y ejecutar &man.apm.8;. Si está usando &man.apmd.8; puede automatizar esto con &man.vidcontrol.1;: edite /etc/apmd.conf y cámbielo del siguiente modo: apm_event SUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "/etc/rc.suspend"; } apm_event USERSUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "sync && sync && sync"; exec "sleep 1"; exec "apm -z"; } apm_event NORMRESUME, STANDBYRESUME { exec "/etc/rc.resume"; exec "vidcontrol -s 9 < /dev/console"; } ACPI ACPI (Advanced Configuration and Power Management Interface, Interfaz para la Administración de Energía y Configuración Avanzada) facilita no solo la administración de energía sino también la detección de hardware (sustituyendo la detección PnP y PCI). ACPI sólo está disponible en &os; 5.X y está activado por defecto, así que no tiene que hacer nada especial para que funcione. Puede controlar el comportamiento de ACPI con &man.acpiconf.8;. Desgraciadamente los fabricantes ponen a la venta sus portátiles con implementaciones ACPI defectuosas, haciendo que habilitar ACPI algunas veces genere más problemas que ventajas, hasta el punto de no poder siquiera arrancar &os; en algunas máquinas con ACPI habilitado. Si ACPI le está causando problemas debería comprobar si el fabricante de su portátil ha liberado una nueva versión de la BIOS que solucione alguno de esos problemas. Dado que la implementación de ACPI en &os; está en constante evolución debería también actualizar su sistema; tal vez así sus problemas se solucionen. Si desea deshabilitar ACPI añada hint.acpi.0.disabled="1" al fichero /boot/device.hints. ACPI puede deshabilitarse temporalmente en el prompt del arranque tecleando unset acpi_load en caso de tener problemas para arrancar una máquina con ACPI habilitado. &os; 5.1-RELEASE y posteriores disponen de un menú en el arranque que controla cómo &os; arranca. Una de las opciones que se suministran es la de dehabilitar ACPI. Para hacerlo simplemente seleccione 2. Boot &os; with ACPI disabled (Arrancar &os; con ACPI deshabilitado) en el menú. Administración de Energía de la Pantalla El sistema X window (XFree86) incluye administración de energía de la pantalla (consulte la página man de &man.xset.1; y busque en ella dpms). Tendrá que investigar. Sin embargo tenga en cuenta que también esto funciona de manera muy poco fiable en portátiles: con frecuencia apaga la pantalla pero no apaga la retroiluminación.
diff --git a/es_ES.ISO8859-1/articles/mailing-list-faq/article.sgml b/es_ES.ISO8859-1/articles/mailing-list-faq/article.sgml index 5f56d17823..707dd3f460 100644 --- a/es_ES.ISO8859-1/articles/mailing-list-faq/article.sgml +++ b/es_ES.ISO8859-1/articles/mailing-list-faq/article.sgml @@ -1,653 +1,637 @@ -%man; - -%freebsd; - -%newsgroups; - -%authors; - -%mailing-lists; - -%translators; - -%trademarks; - - - + +%articles.ent; ]>
Preguntas más frecuentes sobre las listas de correo de &os; El Proyecto de Documentación de &os; 2004 El Proyecto de Documentación de &os; Estas son las FAQ de las listas de correo de &os;. Si está interesado en colaborar con este proyecto envíe un correo eletrónico a &a.doc;. La versión más reciente de este documento siempre puede obtenerse en servidor web mundial de &os;. También se puede descargar como un único archivo HTML en HTML o como texto plano, PostScript, PDF, etc. desde el Servidor FTP de &os; . Puede usted hacer búsquedas en las FAQ. &trans.es.jrh; Introducción Como suele ocurrir en las FAQs este documento intenta abarcar las preguntas más frecuentes sobre las listas de correo de &os; (y por supuesto también pretendemos dar respuestas a dichas preguntas). Aunque originalmente el objetivo de esta lista de preguntas era reducir el ancho de banda y evitar que se preguntaran una y otra vez las mismas cuestiones, las FAQ han evolucionado hasta convertirse en recursos de información muy valiosos. Este documento intenta representar el consenso actual de la comunidad y como tal no se puede considerar la opinión oficial del proyecto como tal. No obstante, si el lector encontrara errores ténicos dentro del presente artículo, o si se deseara realizar sugerencias sobre puntos que debieran tratarse en este documento, por favor o bien rellene un informe de problemas o envíe un correo eletrónico a &a.doc;. Gracias. ¿Cúal es el propósito de las listas de correo de &os;? Las listas de correo de &os; constituyen el canal de principal de comunicación de la comunidad &os; y cubren varias áreas y comunidades de interés diferentes. ¿Cuál es la audiencia de las listas de correo de &os;? Esto depende del cometido oficial de cada lista en particular. Algunas listas se encuentran más orientadas a los desarrolladores; otras están más orientadas hacia la comunidad de usuarios de &os; en general. Por favor, consulte esta lista si quiere consultar una lista actualizada de los cometidos de las listas. ¿Las listas de &os; son abiertas, es decir, el público en general puede participar en ellas? Una vez más esto depende del cometido oficial de cada lista en particular. Por favor, consulte el charter (la declaración del cometido de las listas de correo) antes de enviar correo a la lista y siga la filosofía de dicha lista en los envíos que haga a dicha lista. Esto ayudará al resto de usuarios a sacar más provecho de la lista. Si depués de leer las listas anteriores todavía no ha podido discernir a qué lista debe enviar su pregunta probablemente pueda enviar la consulta a la lista freebsd-questions (pero por favor lea más abajo antes de hacerlo) Tenga en cuenta también que las listas de correo tradicionalmente han estado abiertas a la recepción de correo por parte de subscriptores y no subscriptores. Esto ha sido algo común y deliberado durante años, para hacer más simple el proceso de entrada en la comunidad &os; y para animar y fomentar la puesta en común de ideas. No obstante, debido a los abusos de envío masivo de correos por parte de algunos individuos, ciertas listas aplican una política según la cual los correos enviados por personas no subscritas deben ser procesados manualmente para asegurarse de que cumplen con el objetivo enunciado en el programa oficial de la lista. ¿Cómo me puedo subscribir? Use el interfaz web Mailman para subscribirse a cualquiera de las listas públicas. ¿Cómo me puedo dar de baja? Se puede utilizar exactamente el mismo interfaz que en el caso anterior, o se pueden seguir las instrucciones que se añaden automáticamente al final de cualquier mensaje publicado en la lista. Por favor, no envíe mensajes de baja directamente a la lista de correo. En primer lugar, no se conseguirá el objetivo (que es darse de baja) y en segundo lugar, indudablemente se molesta a los subscriptores y es posible que sea usted increpado por ello. Se trata de un error bastante común cuando se comienza a utilizar listas de correo; por favor, intente evitarlo. ¿Hay archivos históricos de las listas en algún sitio? Sí. aquí puede consultar los correos enviados a las listas agrupados por hilos. ¿Las listas de correo soportan mensajes en formato resumen (digest)? Si. Consulte el interfaz web de Mailman. Normas de protocolo de las listas de correo La participación en listas de correo, como la colaboración en cualquier otra comunidad, se fundamenta en unas bases o estructuras comunes sobre las cuales el proceso comunicativo tiene lugar. Por favor, recuerde enviar solamente preguntas o respuestas adecuadas y siga las siguientes reglas de protocolo. ¿Qué debo hacer antes de enviar un correo? Usted ha completado el paso más importante al comenzar a leer este documento. No obstante, si es principiante en &os;, puede que deba familiarizarse usted mismo con el software y la historia que lo envuelve y lo ha hecho evolucionar, leyendo los numerosos libros y artículos que el proyecto mantiene. Son puntos de particular interés el documento de Las Preguntas Más Frecuentes en &os;, el El Handbook de &os; , y los artículos Cómo obtener los mejores resultados de la lista de correo Freebsd-questions, Quí es BSD (existen una versión en castellano de este texto en ) y Primeros pasos en &os;. Enviar una consulta sobre algo que ya está explicado profusamente en uno o más de los anteriores documentos se considera malas formas. Esto ocurre no porque los voluntarios que colaboran en las listas sean personas especialmente susceptibles, sino porque después de un cierto tiempo respondiendo una y otra vez las mismas preguntas las personas comienzan a sentirse frustradas. Esto es particularmente cierto si dicha documentación contiene la respuesta. Recuerde siempre que casi todo el trabajo que implica el desarrollo y mantenimiento de &os; es llevado a cabo por personal voluntario, es decir, humanos, que por lo tanto se comportan como tales y tienen los problemas que suelen tener los humanos. ¿Qué se puede considerar como un mensaje adecuado? Los envíos de mensajes deben adecuarse al programa oficial de la lista o charter. Por favor, evite los ataques personales. Como buenos cuidadanos de internet debemos intentar mantener un gran respeto a nuestros estándares de conducta. No se permite el spam, en ningún caso. Las listas de correo se procesan constantemente para asegurarse del cumplimiento de esta regla. ¿Qué se considera como una norma de etiqueta apropiada cuando se envía correos a las listas? Por favor ajuste todas las líneas a 75 caracteres, ya que no todo el mundo utiliza programas de correo con interfaces gráficas avanzados. Por favor, tenga presente el hecho de que el ancho de banda no es un recurso infinito. No todo el mundo lee el correo electrónico a través de conexiones de alta velocidad, de forma que si sus mensajes contienen adjuntos tales como el contenido del fichero config.log (por poner un ejemplo) o una amplia traza de la pila del sistema, por favor, piense en la posibilidad de colocar dicha información en un sitio web y proporcione simplemente un enlace a dicho sitio en su mensaje. Recuerde también que dichos mensajes se archivarán durante largo tiempo, así que envíos enormes sólamente sirven para inflar el tamaño de los archivos una vez que se ha solucionado el problema que se preguntaba. Formatee su mensaje de forma que sea legible y ¡ POR FAVOR NO GRITE !. No sobreestime el efecto de un mensaje de correo mal formateado y no sólo en las listas de correo de &os;. Su mensaje de correo es todo lo que la gente conoce de usted y si se encuentra mal estructurado, mal escrito, lleno de errores y/o posee muchas exclamaciones o interjecciones la impresión de la gente respecto a usted será pobre y negativa. Por favor utilice el idioma (y el léxico) apropiado para cada lista de correo. Existen muchas listas de habla no inglesa, consulte el siguiente enlace. Tenemos muy en cuenta a aquellas personas que hablan lenguas distintas del inglés y la dificultad que puede entrañar el comunicarse en una lengua que no es la materna. Criticar a hablantes de inglés no nativos por su pobre gramática o los errores de su escritura se consideran (muy) malos modos. &os; posee un excelente bagaje en este tema; por favor ayúdenos a mantener esta tradición. Por favor utilice agentes de correo (Mail User Agent (MUA) en inglés) que cumplan los estándares de correo eletrónico. Muchos mensajes de correo mal estructurados tienen su origen en malos clientes o clientes mal configurados. Los siguientes agentes son tristemente conocidos por lo mal que estructuran y formatean los mensajes de correo sin que usted se de cuenta de ello: cc:Mail &eudora; (versiones antiguas) exmh µsoft; Exchange µsoft; Internet Mail µsoft; &outlook; &netscape; (versiones antiguas) Como puede verse los agentes de correo relacionados con el mundo Microsoft son los que más frecuentemente inclumplen los estándares. Si es posible utilice un agente de correo &unix;. Si no le queda más remedio que utilizar un cliente de correo bajo entornos Microsoft asegúrese de que lo ha configurado apropiadamente. Intente no utilizar MIME: muchos usuarios todavía utilizan lectores de correo que no digieren bien dichos tipos. Asegúrese de que su tiempo y zona horaria están correctamente configurados. Esto puede parecer un poco estúpido a primera vista, pero tenga en cuenta que no es extraño recibir cientos de mensajes durante las 24 horas del día. Normalmente dichos mensajes se clasifican por asunto o por fecha y si su mensaje no se localiza antes de la primera respuesta, los subscriptores de la lista pueden llegar a pensar que no recibieron la consulta y no consultar el resto de mensajes relacionados. La gran mayoría de las veces se verá en la tesitura de adjuntar salidas de programas en sus mensajes, tales como &man.dmesg.8; o mensajes de consola, como los que normalmente aparecen en /var/log/messages. No intente copiar estas informaciones tecleandolas manualmente; no sólo es un trabajo penoso si no que es muy probable que se cometan errores. Para enviar contenidos de ficheros de log o bien haga una copia del fichero para que sea adjuntado al mensaje previa eliminación de la información no relevante, o bien utilice el método de copiar y pegar. Para la salida de programas tales como dmesg, redireccione la salida a un fichero y utilice alguno de los procedimientos anteriores. Por ejemplo, &prompt.user; dmesg > /tmp/dmesg.out Esto redirige la información a /tmp/dmesg.out. Cuando se utilice el método copiar y pegar, por favor tenga en consideración que algunas veces dichas operaciones desordenan el resultado y el formateo de su mensaje de correo. Este hecho es de particular importancia cuando se trata de enviar el contenido de ficheros Makefile, donde el tabulador es un carácter separador muy importante. Este es uno de los problemas más comunes de los envíos a la base de datos de Informes de Problemas GNATS. Los Makefile con tabuladores transformados en espacios, o transformados en la secuencia de escape ASCII =38, crean una especial exasperación entre los commiters. ¿Cuáles son las consideraciones especiales de etiqueta cuando se responde a un mensaje en las listas de correo? Por favor incluya el texto del mensaje original que considere relevante. Cualquier otra persona que no leyó el mensaje original debería ser capaz de entender de qué se está hablando. Esto es particularmente importante en el caso de envíos del estilo de "si, yo también veo esto", donde el mensaje original formado por cientos de líneas no aparece. Utilice alguna técnica para discernir entre el texto del mensaje original y el texto que usted añada. Un estándar de facto consiste en prefijar el mensaje original con > . Dejar espacios en blanco después de > y dejar líneas en blanco entre nuestro texto y el texto original. Todos estos consejos dan como resultado una respuesta al mensaje más legible. Por favor, asegúrese de que las atribuciones de texto que se cita son correctas, es decir, de que realmente pertenecen a la persona que usted dice. La gente puede llegar a ofenderse si se atribuyen palabras a personas que no las dijeron. Por favor no responda al principio (top post en inglés). Es decir, añada sus comentarios al final del texto que copia en su mensaje. R: Es porque se invierte el flujo lógico de la conversación. P:¿Por qué el top posting no está bien visto? (Gracias a Randy Bush por la broma.) Asuntos recurrentes en las listas de correo La participación en las listas de correo, así como la participación en cualquier otra comunidad, se basa en una serie de normas básicas para posibilitar el hecho comunicativo. La participación en algunas listas de correo implican el el conocimiento de la historia del Proyecto &os;. Existen ciertos temas que suelen aparecer en las mentes de los nuevos una y otra vez. Es responsabilidad de cada participante el comprobar que sus mensajes no caen en alguna de las siguientes categorías. Asegurando esto, se ayuda a mantener a la lista en su asunto o tema más actual, y también se evitan las acusaciones que la gente puede verter hacia usted por no seguir esta regla. El mejor método para evitar esto consiste en familiarizarse con los archivos de las listas; así sabrá qué temas que se han tratado con anterioridad. En este aspecto resulta de gran valor el interfaz de búsqueda de la lista de correo. (Si este método no proporciona resultados útiles, por favor compleméntelo con una búsqueda en su motor de búsquedas favorito). Si se familiariza con los archivos históricos no solo conocerá los temas que se han tratado anteriormente, también aprenderá cómo se produce la discusión en la lista, quiénes son los participales y cuál es la audiencia que que se espera. Estos puntos conviene conocerlos antes de preguntar en cualquier lista de correo, no sólo en las de &os;. No hay lugar a discusión alguna si afirmamos que los archivos son bastante extensos y también si reconocemos que algunas preguntas son más recurrentes que otras, algunas veces camufladas dentro de hilos donde la línea de asunto no refleja precisamiente el nuevo contenido del mensaje. En cualquier caso, la pesada carga está en su territorio, el del poster o persona que envía mensajes a la lista, debiendo realizar su trabajo para poder evitar estos temas recursivos y en particular los muy temidos bikesheds. ¿Que es un "bikeshed"? Literalmente, un bikeshed es un cobertizo exterior donde se puede almacenar un vehículo de dos ruedas. No obstante en la jerga de &os; la palabra se considera como un término disuasorio que se refiere a cualquier discusión frecuentemente recurrente sobre un determinado tema, en particular, se utiliza a menudo para identificar un tema sobre el que no se ha podido llegar a ningún acuerdo dentro de la comunidad &os; y que permanece como algo controvertido. (La génesis de este significado se explica con más detalle en este texto). Simplemente se trata de conocer previamente a qué se refiere este término antes de empezar a enviar mensajes a cualquier lista de correo de &os;. De una forma más general un bikeshed es un asunto que tiende a generar inmediatamente meta-discusiones y pasiones ardientes si no se han leído pasadas discusiones. Por favor, colabore en el mantenimiento de las listas de correo evitando los bikesheds siempre que pueda. Gracias. Agradecimientos &a.grog; Autor original de la mayor parte del material que cubre las normas de etiqueta de las listas, tomadas del artículo Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions . &a.linimon; Por la creación del borrador inicial de esta FAQ.
diff --git a/es_ES.ISO8859-1/articles/p4-primer/article.sgml b/es_ES.ISO8859-1/articles/p4-primer/article.sgml index d1cf3112a2..174357b51c 100644 --- a/es_ES.ISO8859-1/articles/p4-primer/article.sgml +++ b/es_ES.ISO8859-1/articles/p4-primer/article.sgml @@ -1,1004 +1,986 @@ - - - -%man; - %freebsd; - %newsgroups; - -%authors; - -%trademarks; - -%translators; - %mailing-lists; - -]>
<application>Perforce</application> en el contexto del desarrollo de &os; Scott Long
scottl@FreeBSD.org
$FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general;
Introducción El proyecto &os; utiliza el sistema de control de versiones Perforce para gestionar proyectos experimentales que todavía no están listos para ser incluidos en el repositorio principal de CVS. Disponibilidad, documentación y recursos Aunque que el producto Perforce es un producto comercial, el software cliente que se encarga de interactuar con el servidor se distribuye libremente. Pueden descargarse versiones binarias del mismo desde el sitio web de Perforce: . Existe un cliente gráfico, pero la mayoría de la gente utiliza la aplicación de línea de órdenes, p4. Este documento trata sobre el uso de dicha herramienta para la línea de órdenes. En encontrará documentación online detallada. Se recomienda encarecidamente leer la guía de usuario y el manual de Perforce. La aplicación p4 dispone de una extensa ayuda online a la que puede accederse mediante la orden p4 help. El servidor &os; Perforce se encuentra en perforce.freebsd.org, puerto 1666. Puede navegar por el repositorio desde . Ciertas partes del repositorio se exportan automáticamente hacia diversos servidores CVSup. Los comienzos El primer paso para utilizar Perforce consiste en obtener una cuenta en el servidor. Si ya dispone de una cuenta en FreeBSD.org entre en freefall y ejecute el siguiente comando utilizando una contraseña distinta del acceso de su &os; o de cualquier otro mecanismo de autenticación SSH: &prompt.user; /usr/local/bin/p4newuser Por supuesto si no tiene una cuenta en FreeBSD.org necesitará coordinarse con su mentor. El siguiente paso consiste en establecer las variables de entorno que necesita p4 y en verificar que puede conectarse al servidor. Es necesario especificar la variable P4PORT para realizar cualquier operación. Dicha variable indica el servidor Perforce con el que se va a trabajar. En el caso del Proyecto &os;, créela con el siguiente valor: &prompt.user; export P4PORT=perforce.freebsd.org:1666 Los usuarios con acceso shell al cluster FreeBSD.org pueden querer encapsular el protocolo cliente-servidor de Perforce a través de un túnel SSH, en cuyo caso la variable de arriba debería establecerse al valor localhost. El servidor &os; también necesita que se establezcan las variables P4PASSWD y P4USER. Utilice el nombre de usuario y la contraseña anteriores del siguiente modo: &prompt.user; export P4USER=nombre_de_usuario &prompt.user; export P4PASSWD=contraseña Compruebe que todo funciona mediante la siguiente orden: &prompt.user; p4 info A resultas de esta orden debería ver información referente al servidor. Si no es así compruebe que la variable P4PORT tiene el valor correcto. Clientes El sistema Perforce proporciona acceso al repositorio y mantiene el estado del cliente de forma individualizada. En términos de Perforce, un cliente es una especificación que asocia Este término, que también puede traducirse como asociar o asignar, suele aparecer en la jerga de la administración de sistemas como mapear. ficheros y directorios desde el repositorio hasta la máquina local. Cada usuario puede poseer varios clientes, y cada cliente puede acceder a distintas partes del repositorio (incluso a varias partes que se solapan entre sí). El cliente también especifica el directorio raíz del árbol de directorios sobre el que se realiza la asociación y la máquina donde efectivamente está dicho árbol. Es por esto que si pretende trabajar en varias máquinas tendrá que usar varios clientes. Puede acceder a los clientes mediante p4 client. Si se ejecuta esta orden sin argumentos aparece una plantilla del cliente dentro de un editor, permitiendo de esta forma crear un nuevo cliente. Los campos importantes de esta plantilla se explican a continuación: Client: Este es el nombre de la especificación del cliente. Puede ser cualquier cosa, pero debe ser una cadena única dentro del servidor Perforce. Suelen usarse nombres como nombre_de_usuario_nombre_de_máquina, que permite identificar fácilmente a los clientes cuando se navega por ellos. Por defecto hay ya un nombre, que se corresponde con el nombre de la máquina. Description: Este campo suele consistir en un breve texto descriptivo que ayude a identificar al cliente. Root: Se trata del directorio local que actuará como directorio raíz para todos los ficheros dentro de la asociación en el cliente. Debe ser una localización única dentro del sistema de ficheros que no se solape con otros ficheros o clientes Perforce. Options: La mayoría de las opciones por defecto son correctas y válidas para todo el mundo, aunque suele ser recomendable comprobar que estén activadas las opciones y y que no tienen el prefijo no. Los detalles de cada una de estas opciones están en la documentación de Perforce. LineEnd: Este parámetro gestiona las conversiones CR-LF y debe dejarse tal cual salvo que sus necesidades específicas requieran cambiarlo. View: Aquí es donde están las asociaciones de ficheros servidor-a-local. El valor por defecto es: //depot/... //cliente/... Esto asociará por completo el repositorio Perforce al directorio Root del cliente. NO USE ESTE VALOR POR DEFECTO. El repositorio de &os; es enorme e intentar asociarlo y sincronizarse con dicho repositorio tardará muchísimo y consumirá enormes recursos. Asocie sólamente la sección del repositorio en la que va a trabajar. Por ejemplo, hay un árbol para el proyecto smpng en //depot/projects/smpng. Una asociación en ese caso sería algo así: //depot/projects/smpng/... //cliente/... Los ... deben tomarse literalmente tal cual están. Es un dialecto de Perforce para decir este directorio y todos los ficheros y directorios por debajo de él.. Una vista (View) puede contener múltiples asociaciones. Vamos a suponer que quiere asociar los árboles de SMPng y de NFS. Su View sería algo así: //depot/projects/smpng/... //cliente/smpng/... //depot/projects/nfs/... //cliente/nfs/... Recuerde que cliente es el nombre del cliente que se especificó en la sección Client, pero en la sección View además se utiliza para resolver al directorio especificado en la sección Root. También tenga en cuenta que el mismo fichero o directorio no puede asociarse más de una vez dentro de una única vista. La orden del siguiente ejemplo no es correcta y producirá resultados imprevistos: //depot/projects/smpng/... //cliente/smpng-esto/... //depot/projects/smpng/... //cliente/smpng-lo_otro/... Las vistas son la parte compleja del proceso de aprendizaje de Perforce, así que no tenga miedo de hacer tantas preguntas como estime oportunas. Puede listar los clientes existentes mediante p4 clients. Puede listarlos sin que sufran modificaciones mediante p4 client -o nombre_cliente. Siempre que se interactue con ficheros en Perforce la variable de entorno P4CLIENT debe contener al nombre del cliente que se está utilizando, es decir: &prompt.user; export P4CLIENT=nombredemicliente Fíjese en que las asociaciones del cliente en el repositorio no son exclusivos; varios clientes pueden estar asociados en la misma zona del respositorio. Esto permite el trabajo en equipo sobre el mismo código, permitiendo que distintas personas accedan y modifiquen la misma parte del respositorio. Sincronizaciones Una vez definida la especificación del cliente y una vez establecida la variable de entorno P4CLIENT, el siguiente paso consiste en recuperar los ficheros para el cliente en cuestión desde el servidor hasta la máquina local. Esto se realiza con p4 sync, el cual indica a Perforce que sincronice los ficheros locales con los del repositorio. La primera vez que se ejecuta descargará todos los ficheros. Las siguientes ejecuciones sólo descargarán aquellos ficheros que hayan cambiado desde la última ejecución de la orden. Gracias a esto es posible sincronizar sus fuentes con las de otras personas con las que esté trabajando. Las operaciones de sincronización sólo atañen a aquellos ficheros cuyas modificaciones han sido transmitidas a Perforce. Si se modifica o borra un fichero en local sin informar de ello al servidor la ejecución de un sync no reflejará dichos cambios. No obstante, la ejecución de p4 sync -f sincrozará incondicionalmente todos los ficheros, sin que importe su estado. Esto resulta útil para solucionar problemas cuando se cree que el árbol pueda haber sufrido algún tipo de corrupción. Puede sincronizarse parte del árbol o del cliente especificando una ruta relativa a la orden sync. Por ejemplo, para sincronizar sólo el directorio ufs del proyecto smpng ejecute lo siguiente: &prompt.user; cd raizdelproyecto/smpng &prompt.user; p4 sync src/sys/ufs/... El uso de rutas locales relativas funciona en muchas otras órdenes p4. Ramas Una de las características más interesantes de Perforce es la posibilidad de crear ramas. Las ramas son muy sencillas de crear y también resulta muy fácil mover cambios entre distintas ramas (como se verá más adelante). Las ramas también nos permiten realizar trabajos muy experimentales dentro de un entorno de sandbox, sin necesidad de tener que preocuparnos por las colisiones con otros usuarios o por desestabilizar el árbol principal. Además, las ramas proporcionan el aislamiento necesario frente a los errores que se cometen cuando se aprende a manejar el sistema Perforce. Vistas estas ventajas es lógico que cada proyecto disponga de su propia rama y en &os; recomendamos encarecidamente este esquema. También se recomienda la aplicación frecuente de los cambios realizados. El repositorio Perforce (conocido como el depósito, o depot en la jerga de Perforce) es un único árbol plano. Se accede a cada fichero a través de una sencilla ruta bajo el directorio //depot, tanto si se trata de un fichero de nueva creación como si proviene de una ramificación. Esto supone una gran diferencia con respecto a sistemas como CVS, donde cada rama se encuentra en la misma ruta que su rama padre. En Perforce el servidor mantiene las relaciones entre los ficheros padre e hijo, pero los ficheros en sí están bajo sus propias rutas. El primer para para crear una rama consiste en crear una especificación de rama. Es similar a la especificación de un cliente, pero se crea mediante la orden p4 branch nombre_de_rama. Veamos los campos más importantes: Branch El nombre de la rama. Puede ser cualquier nombre, pero debe ser único en el repositorio. La convención que se usa en &os; es nombre_de_usuario_nombre_del_proyecto. Description Puede poner aquí un texto simple que describa la rama. View Esto es la asociación de la rama. En lugar de asociar desde el depósito hacia la máquina local como una asociación de cliente, se crea una asociación entre la rama padre y la rama hija dentro del depósito. Por ejemplo, puede querer crear una rama del proyecto smpng. La asociación resultaría en algo parecido a esto: //depot/projects/smpng/... //depot/projects/mi-super-smpng/... O puede crear una rama totalmente nueva a partir de las fuentes de &os;: //depot/vendor/freebsd/... //depot/projects/mi-nuevo-proyecto/... Esto asociará el HEAD del árbol de &os; a su nueva rama. La creación de la especificación de rama únicamente graba la especificación en sí misma dentro del servidor. No modifica el depósito ni cambia ningún fichero. El directorio que se declara en la rama permanece vacío en el servidor hasta que se comience a llenar. Para rellenar la rama primero debemos editar el cliente con la orden p4 client y asegurarnos de que el directorio de rama está asociado en el cliente. Puede ser necesario añadir una línea View como esta: //depot/projects/mi-nuevo-proyecto/... //micliente/mi-nuevo-proyecto/... El siguiente paso consiste en ejecutar p4 integrate, como se describe en la siguiente sección. Integraciones Integración es el término que se utiliza en Perforce para describir la acción de mover cambios desde una parte del depósito a otra. Se suele realizar junto con las órdenes creación y mantenimiento de ramas. Una integración es necesaria cuando se quiere rellenar inicialmente una rama y cuando se quieren mover cambios realizados en la rama padre hacia la rama hija, o de la la rama hija a la padre. Un caso muy común es la integración periódica desde el árbol original de &os; hacia la rama hija propia del usuario. El servidor Perforce mantiene el estado de los cambios en cada rama y sabe cuándo hay cambios que pueden integrarse de una rama a otra. La forma más común de hacer una integración se muestra en la siguiente orden: &prompt.user; p4 integrate -b nombrederama nombrederama es el nombre que se ha dado a la especificación de rama, tal y como se explicó en la sección anterior. Esta orden indica a Perforce que busque cambios en la rama padre que todavía no se hayan aplicado a la rama hija. En base a los cambios encontrados se prepara un listado de diferencias a aplicar. Si la integración se realiza por primera vez sobre una rama (por ejemplo cuando se realiza una operación de rellenado inicial) los ficheros de la rama padre simplemente se copiarán en la ubicación en la rama hija de la máquina local. Una vez que la operación de integración ha finalizado se debe ejecutar p4 resolve, que aplicará los cambios y resolverá posibles conflictos. Los conflictos puede surgir debido a cambios que se solapan al encontrarse tanto en fichero de la rama padre como en la copia del fichero de la rama hija. Normalmente no suelen aparecer conflictos y Perforce puede calcular rápidamente cómo unir los cambios. Para ejecutar una operación de resolución (resolve) utilice las siguientes órdenes: &prompt.user; p4 resolve -as &prompt.user; p4 resolve La primera invocación indica a Perforce que una automáticamente los cambios y que acepte aquellos ficheros que no den conflictos. La segunda invocación permite inspeccionar cada fichero con conflictos y resolver de forma manual dichas incompatiblidades. Una vez hecha la integración de los ficheros llega el momento de aplicar los cambios al repositorio. Para ello se emplearemos la orden p4 submit, cuyo uso se explica en la siguiente sección. Aplicación de cambios en el repositorio Los cambios que se han realizado en local se deben aplicar en el contenido del servidor Perforce para mayor seguridad frente a pérdidas y para que otras personas puedan acceder a dichos cambios; esto se hace con la orden p4 submit. Cuando se ejecuta esta orden se abre una plantilla (submit template) en el editor. &os; dispone de una platilla personalizada, de la que a continuación se explican los campos más importantes: Description: <enter description here> PR: Submitted by: Reviewed by: Approved by: Obtained from: MFP4 after: es decir Descripción: <Introduzca una descripción> PR: Enviado por: Revisado por: Aprobado por: Obtenido de: MFP4 tras: Se considera una buena práctica proporcionar al menos dos o tres frases que describan los cambios entregados. Debería declarar aquí qué hacen dichos cambios, por qué se han hecho de esa forma o qué problemas intenta resolver con ellos. También conviene explicar qué APIs cambian y qué otros efectos secundarios pueden tener. Este texto debe sustituir a la línea <enter description here> que aparece en la plantilla. Debe recubrir las líneas y comenzar cada línea con una tabulación. Las etiquetas de más abajo son específicas de &os; y puede eliminarlas si no resultan útiles o apropiadas en su contexto. Files: Este campo se rellena automáticamente con todos los ficheros que el cliente etiquetó en el servidor con estados de adición, borrado, integración o edición. Le aconsejamos que revise esta lista y elimine de ella los ficheros que todavía no esten listos. Una vez guardada la sesión de su editor tiene lugar la entrega de los datos al servidor. Esto significa que las copias locales de los ficheros entregados se enviarán al servidor. Si algo va mal durante este proceso se cancelará la entrega y se avisará al usuario de que la entrega se ha convertido en una lista de cambios que deben corregirse y reenviarse. Las entregas son atómicas, es decir, si un fichero falla la entrega se cancela en su totalidad. Los cambios efectuados en el servidor no pueden cancelarse una vez hechos, pero sí que pueden cancelarse si, dentro aún del editor, se sale de él sin cambiar el texto del campo Description. Perforce se quejará la primera vez que intente salir y le devolverá al editor. Si sale por segunda vez el editor cancelará la operación. Devolver el repositorio al estado anterior a un cambio ya efectuado es un proceso muy complicado y no hay un procedimiento estándar, por lo que depende del caso concreto. Edición En el servidor se almacena y mantiene el estado de cada fichero del cliente. Para evitar colisiones entre distintas personas trabajando al mismo tiempo en el mismo fichero Perforce presta atención a qué ficheros están abiertos en modo de edición, y utiliza esa información para poder gestionar posteriormente las operaciones de entrega, las sincronizaciones y las integraciones. Para abrir un fichero para editarlo utilice p4 edit de la siguiente forma: &prompt.user; p4 edit nombredefichero Esto marca el fichero en el servidor con el estado de edición, lo que permite entregar el fichero posteriormente una vez realizados los cambios oportunos, o lo etiqueta como de tratamiento especial cuando se está efectuando una operación de integración o sincronización. Tenga en cuenta que la edición no es exclusiva en Perforce. Varias personas pueden tener el mismo fichero en estado de edición (será informado de ello si es necesario cuando ejecute edit), pero podrá entregar sus cambios incluso cuando haya otras personas que tengan ese fichero en estado de edición. Cuando alguien entregue un cambio de un fichero que usted esté editando necesitará cotejar sus modificaciones con las de la otra u otras personas para poder aplicar correctamente sus modifaciones al repositorio. La forma más sencilla de hacerlo es ejecutar p4 sync o p4 submit y dejar que el programa encuentre algún conflicto, y a continuación ejecutar p4 resolve para resolver manualmente los conflictos y aceptar los cambios de la otra persona en su copia del fichero. Hecho esto, utilice p4 submit para aplicar sus cambios en el repositorio. Si posee un fichero abierto para su edición y quiere descartar los cambios y devolverlo a su estado original ejecute p4 revert de la siguiente forma: &prompt.user; p4 revert nombredefichero Esto resincroniza el fichero con el contenido del servidor y elimina en el servidor el atributo de edición para ese fichero. Se perderá cualquier cambio que haya hecho en local. Esto resulta muy útil cuando se han efectuado una serie de cambios en un determinado fichero y se decide posteriormente que no se desean aplicar dichos cambios en el servidor. Cuando se sincroniza un fichero se marca como sólo lectura en el sistema de ficheros. Aunque se pueden sobreescribir fácilmente dichos permisos se aplican para recordar al usuario de una forma educada que para ello se debe utilizar p4 edit. Los ficheros modificados en local pero que no están en estado de edición pueden sobreescribirse al ejecutar p4 sync. Cambios, descripciones e historial Puede ver el historial de cambios realizados al depósito de Perforce puede consultarse mediante p4 changes. Esta orden proporciona una breve descripción de cada cambio, quién la realizó y cúal es el número de modificación. Si lo que se quiere son los detalles de un cambio en concreto utilice p4 describe numero_de_cambio. Esta orden proporciona el log y los diffs de dicho cambio. Normalmente se utilizan las opciones o para generar diffs unificados o contextuales, respectivamente, en lugar del formato del diff nativo. p4 filelog nombre_de_fichero muestra el historial de un fichero, incluyendo todas sus modificaciones, integraciones y ramas que contenga. <quote>diffs</quote> Existen dos formas de generar diffs de ficheros en Perforce, bien entre cambios locales que todavía no se han entregado o bien entre dos árboles (o dentro de una misma rama) del depósito. Estos diffs se generan mediante órdenes distintas, y : p4 diff Ese comando genera un diff entre los cambios locales y los cambios de ficheros en estado de edición. Los parámetros y permiten crear diffs unificados o contextuales, respectivamente. También se puede establecer la variable P4DIFF para que apunte a un diff local. Le recomendamos encarecidamente usar esta orden para revisar sus cambios antes de aplicarlos en el servidor. p4 diff2 Esta orden crea un diffs entre ficheros dados en el depósito, o entre ficheros especificados en una especificación de rama. La operación tiene lugar en el servidor, así que la variable P4DIFF no surte ningún efecto, aunque las opciones y sí pueden usarse. Las dos formas de esta orden son: &prompt.user; p4 diff2 -b nombrederama y &prompt.user; p4 diff2 //depot/ruta1 //depot/ruta2 En todos los casos los diffs se muestran en la salida estándar. Por desgracia Perforce usa un formato de diffs que resulta ser ligeramente incompatible con las herramientas Unix estándar diff y patch. La utilización de la variable P4DIFF para que apunte al verdadero &man.diff.1; puede paliar este problema, o al menos en ciertos casos, puesto sólo funciona con la orden p4 diff. La salida de debe procesarse para que sea de alguna utilidad (la opción de producirá diffs unificados que serán más o menos compatibles, pero no esto no incluye ficheros nuevos o borrados. Este script puede serle de utilidad para este proceso necesario: . Añadir o eliminar ficheros La integración de una rama hará que se añadan ficheros existentes en el servidor en su árbol, pero quizás sea necesario añadir nuevos ficheros o eliminar alguno de los ya existentes. Para añadir ficheros no tiene más que crear el fichero y ejecutar p4 add de la siguiente forma: &prompt.user; p4 add nombredefichero Si quiere añadir un árbol completo de ficheros ejecute: &prompt.user; find . -type f |xargs p4 add Al ejecutar p4 submit se copiarán los ficheros al depósito del servidor. Es muy importante añadir sólo ficheros y no directorios. Si se añade explícitamente un directorio, Perforce lo tratará como fichero, lo cual seguramente no es lo que usted tenía previsto. Borrar un fichero es igualmente sencillo mediante p4 delete: &prompt.user; p4 delete nombredefichero Esta orden marcará el fichero para que sea borrado del depósito la siguiente vez que se ejecute una entrega. También borrará la copia local del fichero, así que sea cauteloso cuando la use. Por supuesto que borrar un fichero no significa que se borre realmente del repositorio. Los ficheros borrados se pueden resucitar mediante la sincronización con una versión previa. La única forma de borrar de forma permanente un fichero es mediante la orden p4 obliterat. Dicha orden es irreversible y costosa, así que sólo está al alcance del personal que administra el repositorio. El trabajo con <quote>diffs</quote> Algunas veces puede ser necesario aplicar un diff al árbol de Perfoce que provenga de otra aplicación. Si se trata de un diff de gran tamaño y que afecta a muchos ficheros, puede resultar tedioso ejecutar manualmente p4 edit sobre cada fichero. Hay un truco para hacerlo de una forma más sencilla. En primer lugar, asegúrese de que no hay ficheros abiertos en su cliente y de que su árbol está sincronizado y actualizado a la última versión. A continuación aplique sus cambios mediante las herramientas habituales, y forzando los permisos de los ficheros en caso de ser necesario. Después ejecute lo siguiente: &prompt.user; p4 diff -se ... |xargs p4 edit &prompt.user; p4 diff -sd ... |xargs p4 delete &prompt.user; find . -type f |xargs p4 add La primera orden le dice a Perforce que busque los ficheros que han cambiado, incluso si no están abiertos. La segunda orden le dice a Perforce que busque los ficheros que no existen en la máquina local pero que sí están en el servidor. La tercera orden intenta añadir todos los ficheros que están en local. Es un método de fuerza bruta, pero funciona bien porque Perforce sólo añadirá los ficheros que le resulten desconocidos. El resultado de estas órdenes es un conjunto de ficheros abiertos para edición, borrado o para ser añadidos, según el caso. Hecho esto solo nos queda ejecutar p4 submit para entregar los cambios. Cambiar nombres de ficheros Perforce no dispone de una forma predefinida de cambiar nombres a ficheros o de moverlos a otra parte del árbol. Si se copia el fichero en cuestión a una nueva ubicación mediante p4 add, y posteriormente p4 delete en la versión anterior, se obtiene algo muy parecido a lo que se quería, pero tiene el inconveniente de que no se preserva el historial de cambios de ese fichero. Esto puede perjudicar futuras integraciones entre padres e hijos. Hay otro método más recomendable, que consiste en efectuar una integración dentro del mismo árbol y de una sola vez. Veamos un ejemplo: &prompt.user; p4 integrate -i ficheroprevio ficheronuevo &prompt.user; p4 resolve &prompt.user; p4 delete ficheroprevio &prompt.user; p4 submit La integración fuerza a Perforce a mantener un registro de las relaciones entre los nombres antiguos y los nuevos, lo cual será muy útil en futuras integraciones. La opción indica que se trata de una integración sin base, es decir, que no existe un historial de ramas al que recurrir en la integración. Este parámetro tiene sentido en el presente ejemplo, pero no debería utilizarse en integraciones basadas en ramas. Interacciones entre el CVS de &os; y Perforce Los repositorios de Perforce y de CVS de &os; están completamente separados. No obstante, los cambios que se producen en CVS se reflejan casi en tiempo real en Perforce. Cada 2 minutos se pregunta al servidor de CVS sobre cambios realizados en la rama HEAD, y dichos cambios se entregan a Perforce dentro del árbol //depot/vendor/freebsd/.... De este modo este árbol permite la ramificación y la integración de proyectos derivados. Cualquier proyecto que implique la modificación del código fuente de &os; debería tener este árbol como su rama padre (o rama abuela, dependiendo de las necesidades concretas de cada proyecto), y deberían tener lugar integraciones periódicas y sincronizaciones para que el árbol esté en consonancia con el desarrollo de &os; y evitar conflictos en la medida de lo posible. El puente entre CVS y Perforce es de un sólo sentido; los cambios del CVS se reflejarán en Perforce, pero los cambios en Perforce no se reflejarán en el CVS. Si es necesario, se pueden exportar partes del repositorio de Perforce al CVSup y que así se puedan distribuir. Por favor, contacte con los administradores de Perforce de &os; si ese es su caso. Funcionamiento sin conexión de red Uno de los inconvenientes de Perforce es que supone que siempre es posible acceder al servidor a través de la red. La mayoría de los estados, el historial y los metadatos se almacenan en el servidor y no existe mecanismo alguno para replicar el servidor como los hay en CVS/CVSup. Es posible ejecutar un servidor proxy, pero solamente ayuda un poco si se quiere trabajar sin conexión al servidor. La mejor forma de trabajar sin conexión de red es comprobando que el cliente no tiene ningún fichero abierto y que está totalmente sincronizado antes de dejar de estar conectado. Cuando se edite un fichero se deberán cambiar manualmente los permisos a lectura-escritura. Cuando vuelva a estar conectado ejecute la orden que se mostraba en la para identificar automáticamente los ficheros que se han editado, añadido o eliminado. Es bastante común encontrarse con la sorpresa de que Perforce ha sobreescrito un fichero modificado en local que no se abrió en modo edición, así que tenga especial cuidado con esto. Consideraciones finales para el <quote>Google Summer of Code</quote> La mayoría de los proyectos de &os; dentro del programa Google Summer of Code están en //depot/projects/soc2005/nombre_del_proyecto/... en el servidor &os; de Perforce. Entre las responsabilidades del mentor del proyecto está seleccionar un nombre adecuado para dicho proyecto y hacer que el estudiante sea capaz de trabajar con Perforce. El acceso al servidor &os; de Perforce no implica pasar a ser miembro de la comunidad de committers del CVS de &os;, aunque animamos de todo corazón a todos los estudiantes que consideren la posibilidad de unirse al proyecto cuando estén listos para ello.
diff --git a/es_ES.ISO8859-1/articles/problem-reports/article.sgml b/es_ES.ISO8859-1/articles/problem-reports/article.sgml index bc26bc6325..bacd48fe66 100644 --- a/es_ES.ISO8859-1/articles/problem-reports/article.sgml +++ b/es_ES.ISO8859-1/articles/problem-reports/article.sgml @@ -1,1028 +1,1016 @@ -%man; - %freebsd; - %newsgroups; - -%authors; - -%mailing-lists; - -%translators; - -%trademarks; - + +%articles.ent; ]>
Cómo enviar informes de problemas de &os; $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.general; Este artículo describe cómo realizar y enviar informes de errores para el proyecto &os; de la mejor forma posible. &trans.es.jrh; Dag-Erling Smørgrav Escrito por problem reports
Introducción Una de las experiencias más fustrantes que se pueden experimentar como usuario de software es aquella en la cual el usuario se toma la molestia de rellenar un informe de problemas detallado para observar tras un determinado espacio de tiempo que dicho informe se cierra con una explicación corta y abrupta como no es un error o PR erroneo. De forma semejante, una de las experiencias más fustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de errores que en realidad vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cúal es el problema y como se puede reproducir. Este documento intenta describir cómo escribir informes de problemas de calidad. Usted se preguntará cómo se pueden escribir informes de problemas de calidad. Bien, para ir directos al grano, un informe de problemas de calidad es aquél que se puede analizar y tratar rápidamente, para mútua satisfacción del usuario y del desarrollador. Aunque el objetivo principal de este artículo se centra en los informes de problemas de &os; la mayoría de los conceptos se pueden aplicar bastante bien en otros proyectos de software. Dése cuenta de que este artículo se organiza de forma temática, no cronológicamente, de tal forma que se debe leer el documento íntegro antes de enviar informes de problemas. No debe tratarse como un tutorial del estilo paso a paso.
Cuándo enviar informes de problemas Existen varios tipos de problemas y no todos ellos se merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y existirán ocasiones en las que estaremos convencidos de haber encontrado un bug en un programa cuando realmente hemos malinterpretado la sintaxis o el funcionamiento de dicho programa, o simplemente hemos cometido un error tipográfico en un fichero de configuración (aunque en este último caso podría tratarse de un indicador de documentación escasa o que la aplicación peca de una gestión de errores defectuosa. Incluso teniendo estos aspectos en cuenta existen varios casos en los cuales el envío de un informe de problemas resulta claramente no ser la mejor forma de proceder, ya que dicho envío puede servir para frustrar tanto a quien envía el informe como a quien desarrolló la aplicación. Por el contrario, también existen casos en los que puede resultar apropiado enviar un informe de problemas sobre algo más aparte de bugs: una mejora o una solucitud nuevas características, por citar un par de ejemplos. Así que ¿cómo podemos determinar qué constituye un bug y qué no? Como regla para principiantes podemos decir que su problema no es un bug si se puede expresar como una pregunta (normalmente del estilo de ¿cómo hago X? o ¿donde puedo encontrar Y?). No siempre las cosas son blancas o negras, pero la regla de las preguntas suele cubrir una gran mayoría de casos. Si lo que se quiere es una respuesta a una consulta, se pueden enviar dichas preguntas a la &a.questions;. A continuación se muestran algunos casos en los que resulta apropiado enviar un informe de problemas sobre algo que no se considera un bug: Solucitudes para mejora de características. Normalmente es una buena idea airear estas propuestas en las listas de distribución antes de enviar un informe de problemas. Notificación de actualizaciones de software que se mantiene externamente (principalmente ports, pero también componentes del sistema base al cargo de proyectos independientes de &os;, como BIND o diversas utilidades GNU) Otro tema es que si el sistema donde se experimentó el bug no está medianamente actualizado se debe considerar muy seriamente su actualización e intentar reproducir el problema en un sistema actualizado antes de emitir el informe. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un problema que ya ha resuelto. Por último, un bug que no se puede reproducir difícilmente puede arreglarse. Si el bug sólo ocurrió una vez y no somos capaces de reproducirlo, y parece que no le ocurre a nadie más, es muy probable que ni siquiera los desarrolladores puedan reproducirlo y por lo tanto ni siquiera puedan imaginarse qué es lo que falla. Esto no significa que el bug no haya ocurrido, sino que las probabilidades de que nuestro informe de errores sirva para corregir un defecto son muy pequeñas. Para complicar más las cosas, a menudo estas clases de errores se producen debido a fallos en los discos duros o al sobrecalentamiento del procesador: debe intentar siempre descubrir estos fallos, siempre que sea posible, antes de enviar un PR.
Preparativos Una buena regla que se puede seguir consiste en realizar siempre una búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de distribución o fue discutido hace poco; incluso es posible que se haya arreglado en versiones más recientes del software. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. En &os; esto significa: Las Preguntas Más Frecuentes (FAQ) de &os;. Las FAQ intentan proporcionar respuestas para un amplio rango de dudas, tales como aquellas relacionadas con las compatibilidades hardware, las aplicaciones de usuario y la configuración del kernel. Las listas de correo. Si no está subscrito utilice la búsqueda en los archivos del sitio web de &os;. Si el problema no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en relación con el problema. Opcionalmente, la web entera—utilice su motor de búsqueda favorito para localizar cualquier referencia a su problema. Incluso pueden aparecer listas de correo o grupos de noticias de los cuales ni siquiera tuviera conocimiento de su existencia o quizá no consideró apropiado consultarlas al principio. A continuación, la búsqueda a través de la base de datos &os; PR (GNATS). A menos que nuestro problema sea muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado. Lo más importante, se debería intentar comprobar si la documentación existente en el código fuente del programa puede resolver el problema. En el caso de las fuentes del sistema &os; debe estudiarse cuidadosamente el contenido del fichero /usr/src/UPDATING del sistema o su última versión, que se encuentra en . (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si la actualización se realiza de la versión estable a la versión &os.current;). No obstante, si el problema se encuentra en algo que se instaló como parte de la collección de ports de &os;, se debe consultar el archivo /usr/ports/UPDATING (para ports individuales) o el archivo /usr/ports/CHANGES (para cambios que afectan a la colección de ports completa). y también se encuentran disponibles a través de CVSweb. A continuación debemos asegurarnos de que el informe de errores llega a las personas adecuadas. La primera consideración llegados a este punto consiste en: Si el problema resulta ser un bug en un software de terceras partes (un port o un paquete que se ha instalado) se debe informar sobre el bug al autor original del software, no al proyecto &os;. Existen dos excepciones a esta regla: la primera ocurre cuando el bug no se produce en otras plataformas, en cuyo caso el problema puede residir en cómo fue migrado el software a &os;; la segunda excepción ocurre cuando el autor original ya ha corregido el problema y distribuido un parche o una nueva versión de su software, pero el port de &os; todavía no se ha actualizado. La segunda consideración es que el sistema de seguimiento de bugs de &os; ordena los informes de problemas de acuerdo con la categoría que ha seleccionado el informador. De este modo, si se selecciona una categoría incorrecta cuando se envía el informe de problemas, existe una gran probabilidad de que nadie se de cuenta de su existencia durante un período de tiempo indefinido, hasta que alguien se encarge de re-categorizarlo.
Escribir el informe de problemas Ahora que hemos determinado que el problema que estamos experimentando se merece la redacción de un informe de problemas y que se trata de un problema de &os;, es la hora de comenzar a escribir dicho informe. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar los informes PR, vamos a describir una serie de trucos y consejos que nos asegurarán la mayor efectividad posible de nuestro informe.
Consejos y trucos para escribir un buen informe de problemas No deje la línea de Synopsis vacía. Los PRs se dirigen tanto a una lista de correo mundial (donde se utiliza el campo Synopsis para rellenar la línea Subject: del correo) como a una base de datos (GNATS). Cualquier persona que consulte la base de datos por el campo sinopsis y encuentre un PR con una línea de Asunto vacía tiende simplemente a pasar por alto el informe. Recuerde que un PR permanece en la base de datos hasta que alguien se encarga de cerrar el informe; un informe anónimo normalmente se perderá para siempre entre el ruido y tardará mucho en cerrarse. Evite utilizar una línea de Synopsis débil.. No debe suponerse que quien lea el PR conoce el contexto adecuado en el que su mensaje tiene sentido, así que cuanta más información se proporcione, mejor que mejor. Por ejemplo, ¿qué parte del sistema se ve afectado por el informe?, ¿el problema aparece cuando se está instalando o cuando se está ejecutando?. Para ejemplificar, en lugar de Synopsis: portupgrade is broken, se pueden ver las ventajas que proporciona una línea como la siguiente: Synopsis: port sysutils/portupgrade produce un coredump en -current. (En el caso concreto de los ports, resulta especialmente útil poseer tanto la categoría como el nombre del port en la línea Synopsis.) Si se dispone de un parche, dígalo. Un PR con un parche incluido tiene muchas más posibilidades de ser tratado que uno que no lo tiene. Si se include dicho parche, escriba la cadena [patch] al comienzo de la línea Synopsis. (Aunque no es obligatorio utilizar dicha cadena, se trata de un estándar de facto que se utiliza de forma mayoritaria.) Si es mantenedor del port, dígalo. Si se está manteniendo el código fuente de una aplicación (por ejemplo, de un port), se puede considerar la adición de la cadena [maintainer update] al comienzo de la línea de sinopsis, y además se debería asignar el campo Class del PR a la cadena maintainer-update. De esta forma cualquier committer que maneje el PR no tendrá que realizar comprobaciones. Sea concreto. Cuanta más información se proporcione sobre el problema que se tiene, más posiblidades de obtener una respuesta. Incluya la versión del &os; que se está ejecutando (existe un lugar donde escribir esta esta información, vea más abajo) y en qué arquitectura. Se debe incluir si se está ejecutando desde una release (e.g. desde un CDROM o descarga), o si es desde un sistema mantenido mediante &man.cvsup.1; (y, si esto último se cumple, con qué frecuencia se realiza la actualización). Si se está siguiendo la rama &os.current;, se trata de la primera pregunta que nos harán, debido a que los parches (sobre todo para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera de los usuarios de &os.current; un seguimiento cercano de las actualizaciones aplicadas. Incluya qué opciones globales se han especificado en el archivo make.conf. Aviso: Es bien conocido por todos que especificar -O2 y valores superiores para &man.gcc.1; produce fallos y resulta ser proclive a errores en muchas situaciones. Aunque los desarrolladores de &os; normalmente dan por buenos y aceptan los parches proporcionados por el creador del informe de problemas, normalmente no desean investigar dichas condiciones extrañas debido simplemente a la falta de tiempo y de voluntarios, y puede que respondan diciendo simplemente que dicha opción de compilación no se encuentra soportada. Si se trata de un problema del kernel, prepárese para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos GNATS, pero sí puede merecer la pena incluir resúmenes que usted considere importantes): La configuración del kernel (incluyendo los dispositivos hardware que se tienen instalados) Si se tienen opciones de depuración activadas (tales como WITNESS), y en tal caso, si el problema persiste cuando se cambia el valor de dichas opciones Una traza de depuración, si se pudo generar. El hecho de que se ha leido detenidamente el archivo src/UPDATING para constatar que el problema no se ha identificado allí (se garantiza que alguién le preguntará sobre este punto) Si se puede o no se puede ejecutar otro kernel sin problemas (se trata de identificar problemas relacionados con el hardware como discos con errores o CPUs sobrecalentadas, que pueden confundirse fácilmente con problemas del kernel) Si se trata de un problema relacionado con los ports, prepárese para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información por defecto, ya que sólo produce un crecimiento indeseado de la base de datos, pero sí se pueden incluir resúmenes de aquellos datos que usted considere relevantes): Los ports que se tiene instalados Cualesquiera variables de entorno que sobreescriban los valores por defecto del archivo bsd.port.mk, tales como PORTSDIR El hecho de que se ha leido ports/UPDATING y que nuestro problema no se encuentra identificado en dicho archivo (se garantiza que alguien puede preguntar este hecho). Evitar peticiones de características vagas. Los PRs del estilo de alguien debería implementar algo que haga esto y aquello y lo de más allá son informes con pocas probabilidades de obtener resultados positivos. Las características deben ser muy concretas y específicas. Recuerde que el código fuente se encuentra disponible para todo el mundo, de tal forma que si usted necesita una característica, la mejor forma de verla incluida en futuras versiones de la herramienta consiste en ponerse usted mismo a trabajar sobre ella, manos a la obra. También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista freebsd-questions, como ya se ha comentado anteriormente. Asegúrese que nadie más ha enviado un PR similar. Aunque esto ya se ha mencionado anteriormente, merece la pena que se repita en este punto. Sólamente lleva uno o dos minutos realizar una búsqueda basada en un motor web en . (Por supuesto, a todo el mundo se le puede olvidar realizar esto de vez en cuando, pero por esa misma razón merece la pena hacer incapié en ello) Evite peticiones controvertidas. Si nuestro PR se dirige hacia un área o tema controvertido en el pasado, debemos prepararnos no sólo a ofrecer parches, si no también a justificar por qué motivo los parches proporcionados son la Forma Correcta de Hacerlo. Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo en los archivos históricos sitos en resulta siempre una buena idea y sirve para preparar nuestro razonamiento y aprender de la experiencia y de las decisiones tomadas en el pasado. Sea educado. Casi cualquier persona que se encarge de tratar nuestro informe de problemas trabajará en el como un voluntario. A nadie le gusta que le digan cómo hacer las cosas cuando ya se están haciendo de una forma determinada, especialmente cuando la motivación para realizarlas no es monetaria. Este hecho es bueno tenerlo en mente y aplicarlo para cualquier proyecto de Software Libre.
Antes de comenzar. Antes de ejecutar el programa &man.send-pr.1;, asegúrese de que la variable de entorno VISUAL (o EDITOR si la variable VISUAL no se encuentra definida) se encuentra apuntando a algo con sentido. Es importante comprobar que la entrega de correo funciona correctamente. &man.send-pr.1; utiliza mensajes de correo para enviar y realizar un seguimiento de los informes de problemas. Si no se puede generar correo electrónico desde la máquina en la que se ejecuta &man.send-pr.1;, el informe jamás llegará a la base de datos GNATS. Si quiere saber más sobre la configuración del correo en &os; consulte el capítulo de Correo Electrónico del manual de &os; en .
Adjuntar parches o archivos El programa &man.send-pr.1; posee la capacidad de adjuntar archivos al informe de problemas. Se pueden adjuntar tantos archivos como se quiera siempre y cuando se utilice un nombre distinto para cada archivo (e.g. el nombre del archivo después de eliminar el path). Simplemente basta con utilizar la opción de línea de comandos para especificar los nombres de todos los archivos que se desean adjuntar: &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors No se preocupe por los archivos binarios, dichos archivos se codifican automáticamente para no interferir con el agente de correo. Si se adjunta un parche, asegúrese que se utiliza la opción o la opción de &man.diff.1; para crear un contexto unificado (el contexto suele ser el preferido por quienes lo han de recibir) y además asegúrese de especificar los números de revisión de CVS de los archivos que se modifican para que los desarrolladores que lean el informe puedan aplicar dichos parches fácilmente. Para problemas relacionados con el kernel o con las utilidades del sistema base, se prefiere un parche contra &os.current; (la rama HEAD del árbol CVS) ya que cualquier código nuevo debe probar se primeramente en dicha rama. Después de comprobar su correcto funcionamiento de una forma sustancial y extensa, eventualmente dicho código pasará a formar parte de &os.stable;, mediante unión o migración. Si se envía un parte en línea, en vez de como adjunto, tenga en cuenta que el principal problema de esta forma de enviar los parches es que, dependiendo del lector de correo utilizado, algunos lectores muestran los tabuladores como espacios, lo cual arruina completamente el formato y la indentación del parche, e invalida totalmente un parche que forme parte de un Makefile. También tenga en cuenta que mientras que la inclusión de parches en un PR se considera como algo positivo—particularmente cuando se soluciona el problema que describe el informe—partes grandes y especialmente código nuevo que puede requerir una sustancial revisión antes de ser aplicado debería hacerse accesible a través de otros medios, como páginas web o servidores de ftp, y en vez de incluir el parche en el informe se puede incluir la URL. Los parches de gran tamaño en los correos electrónicos tienden a mezclarse o partirse, especialmente cuando GNATS los trata, y cuanto más grande es el parche más difícil resulta recuperar el original. También existe una ventaja añadida a la inclusión del parche a través de una URL, ya que de este modo se puede modificar el parche sin tener que reenviar el informe como una respuesta al informe inicial. Se debe prestar atención también al hecho de que, a menos que se especifique explícitamente lo contrario en el PR o en el propio parche, cualquier parche enviado se supone licenciado bajo los mismos términos y condiciones que el archivo original que modifica.
Rellenar la plantilla Cuando se ejecuta &man.send-pr.1; se nos presenta en pantalla una plantilla. Esta plantilla consiste en una lista de campos, algunos de los cuales se encuentran ya rellenados, mientras que otros poseen comentarios donde se explica su propósito o se comentan los valores aceptables. No se preocupe por los comentarios, puesto que se borran automáticamente antes de generar el informe. Al comienzo de la plantilla, justo debajo de las líneas de SEND-PR:, se encuentran las cabeceras de correo electrónico. Dichas cabeceras normalmente no se tienen que modificar, a menos que se esté rellenando el informe desde una máquina que puede enviar correo pero no puede recibirlo directamente, en cuyo caso usted tendrá que editar los campos From: y Reply-To: para escribir la dirección de correo válida. También puede enviarse una copia a usted mismo o a cualquier otra persona rellenando el campo Cc:. A continuación aparecen una serie de campos de una sola línea: Submitter-Id: No cambie este campo. El valor por defecto current-users es correcto, incluso si se está ejecutando &os.stable;. Originator: Se rellena automáticamente con el campo gecos del usuario que está actualmente dentro del sistema. Por favor, especifique su nombre real, opcionalmente acompañado por su dirección de correo electrónico entre < >. Organization: Escriba lo que usted quiera. Este campo no se utiliza para nada significativo. Confidential: Esto se rellena automáticamente con el literal no. Cambiar este valor carece de sentido ya que no existe ningún informe de problemas de &os; confidencial—la base de datos de PR se distribuye a todo el mundo de forma pública mediante CVSup. Synopsis: Rellene este campo con una descripción corta y precisa del problema. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes de informes de la base de datos; informes de problemas con obscuras sinopsis tienden a ser completamente ignorados. Como se avisó anteriormente, si su informe de problemas incluye un parche, por favor incluya en la sinopsis la etiqueta [patch] al comienzo; si usted es un mantenedor de software, también puede añadir la cadena [maintainer update] y asignar el campo Class del informe al valor maintainer-update. Severity: Los valores aceptados son non-critical, serious o critical. No sea exagerado; evite etiquetar el problema como critital a menos que sea realmente algo crítico (e.g. escalada de permisos hacia root, kernel panic fácilmente reproducible). Incluso debe pensarse detenidamente etiquetar algo como serious a menos que se trate de algo que afecte a muchos usuarios (problemas con drivers de dispositivos particulares o con utilidades del sistema). Los desarrolladores de &os; no van a resolver el problema más rápido por el hecho de variar esta etiqueta, debido a que existe mucha gente que infla este campo inadecuadamente. De hecho, los desarrolladores prestan muy poca atención al valor de este campo y del siguiente precisamente por esto último. Priority: Los valores aceptados son low, medium o high. high debe reservarse para problemas que afecten a la mayoría de los usuarios de &os; y medium para aquellos problemas que afecten a varios usuarios. Category: Seleccione uno de los siguientes valores (extraídos de /usr/gnats/gnats-adm/categories): advocacy: para problemas relacionados con la imagen pública de &os;. Raras veces utilizado. alpha: para problemas específicos de la plataforma Alpha. amd64: para problemas específicos de la plataforma AMD64. bin: para problemas con aplicaciones de la zona de usuario del sistema base. conf: para problemas de archivos de configuración, valores por defecto, etc. docs: para problemas con las páginas de manual o la documentación online. gnu: para problemas realacionados con aplicaciones gnu de &os; tales como &man.gcc.1; o &man.grep.1;. i386: para problemas específicos de la plataforma &i386;. ia64: para problemas específicos de la plataforma ia64. java: para problemas relacionados con &java;. kern: para problemas relacionados con el kernel o con (no especifícos de ninguna plataforma) controladores de dispositivos. misc: para cualquier cosa que no encaja en ninguna de las anteriores categorías. (Tenga en cuenta que es muy fácil que los problemas bajo esta categoría se pierdan en el olvido). ports: para problemas relacionados con el árbol de ports. powerpc: para problemas específicos de la plataforma &powerpc;. sparc64: para problemas específicos de la plataforma &sparc64;. standards: para problemas relativos a la adecuación con estándares. threads: para problemas relacionados con la implementación de threads de &os; (especialmente en &os.current;). www: para cambios o mejoras del sitio web de &os;. Class: Se puede seleccionar uno entre los siguientes: sw-bug: bugs de software. doc-bug: errores en la documentación. change-request: peticiones de características adicionales o de cambios en las características existentes. update: actualizaciones de ports o de software contribuido por terceros. maintainer-update: actualizaciones de ports de los cuales usted es mantenedor. Release: La versión de &os; que se está ejecutando. El programa &man.send-pr.1; rellena automáticamente este campo, por lo que sólamente resulta necesaria su modificación cuando estemos rellenando un informe de problemas desde un sistema distinto al sistema donde se ha producido dicho problema. Por último, existen una serie de campos multilínea: Environment: Este campo debe describir, tan preciso como sea posible, el entorno en el cual se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa que contiene el problema y cualquier otro asunto relevante tales como la configuración del sistema o cualquier otro software instalado que pueda influir en la ejecución del primero, etc. Resumiendo todo lo anterior, se debe especificar todo lo que un desarrollador necesita conocer para poder reconstruir el entorno en el cual se ha producido el problema. Description: Una descripción completa y precisa del problema que se está sufriendo. Intente evitar especular sobre las posibles causas del problema a menos que se tenga la seguridad de que el camino descrito es el correcto, puesto que puede inducir al desarrollador a realizar falsas presunciones. How-To-Repeat: Un resumen de las acciones que deben llevarse a cabo para reproducir el problema. Fix: Preferentemente un parche, o al menos una solución temporal (la cual no sólo ayuda a otras personas que experimenten el mismo problema, sino que puede ayudar también al desarrollador para que investigue sobre las verdaderas causas del problema). No obstante, si no se dispone de ninguna de estas opciones, lo mas sabio es dejar vacío este campo y sobre todo no hacer especulaciones.
Envío del informe de problemas Una vez que hemos terminado de rellenar la plantilla, hemos salvado y hemos salido del editor, &man.send-pr.1; nos dará a conocer las siguientes opciones: s)end, e)dit or a)bort?. Es en estos momentos cuando podemos teclear s para continuar y enviar el informe de problemas, e para relanzar el editor y realizar más modificaciones a la plantilla o a para abortar el programa. Si se selecciona esta última alternativa, el informe de problemas no será destruido, sino que permanecerá en disco (&man.send-pr.1; nos indicará el nombre del fichero antes de finalizar), de tal forma que se puede editar de forma individual (sin &man.send-pr.1;) en cualquier momento, o también se puede transferir a otro sistema con mejor conectividad para finalmente enviarlo utilizando la opción de línea de comandos de &man.send-pr.1;: &prompt.user; send-pr -f ~/my-problem-report Esto leerá el archivo especificado, validando sus contenidos, y eliminará los comentarios para finalmente enviarlo.
Follow-up Una vez enviado el informe de problemas, se recibe una confirmación por correo electrónico en la que se incluye el número asignado al informe y la URL que puede utilizarse para consultar su estado. Con un poquito de suerte, alguien mostrará interés en el problema y tratará de solucionarlo, o de explicar por qué razón no se considera un problema, como ha ocurrido en muchas ocasiones. Recibiremos automáticamente una notificación relativa a cualquier cambio de estado, además de recibir copias de cualquier comentario o de los parches que se generen relacionados con nuestro informe. Si alguien solicita información adicional sobre el problema, o de repente descubre o recuerda algo que no tuvo ocasión de mencionar en el informe inicial, puede utilizar una de las siguientes opciones para enviar una continuación (followup) a dicho informe: La forma más sencilla consiste en utilizar el enlace followup que aparece en la página web asociada a nuestro informe de problemas, la cual se puede alcanzar a partir de la página de búsquedas de PRs en . Al pinchar en dicho enlace se mostrará una pantalla con las líneas de To: y Subject correctamente rellenadas (siempre y cuando el navegador soporte esta característica de autorelleno). Alternativamente, se puede enviar un correo eletrónico directamente a bug-followup@FreeBSD.org, asegurando que el número de seguimiento se incluye en el asunto para que el sistema de seguimiento de informes pueda adjuntar la respuesta al informe apropiado. Si no se incluye el número de seguimiento, GNATS no reconocerá el informe inicial y creará un PR totalmente nuevo, que quedará asignado al administrador de GNATS, de tal forma que el followup quedará en el vacío hasta que alguien resuelva el entuerto, lo cual puede tardar dias o semanas. Forma incorrecta:Subject: ese PR que envié en su día Forma correcta:Subject: Re: ports/12345: problema de compilación en foo/bar Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, simplemente envíe un followup (de la forma descrita anteriormente) diciendo que el informe de problemas se puede cerrar y, a ser posible, también conviene explicar la forma en que el problema se resolvió.
Lecturas recomendadas A continuación se muestra una lista de recursos relacionados con la escritura adecuada de informes y con el procesamiento de dichos informes. No pretende ser una completa enumeración. How row to Report Bugs Effectively—un excelente ensayo por Simon G. Tatham sobre la redacción de informes de problemas (el texto no es específico sobre &os;) Problem Report Handling Guidelines—resumen de valor sobre cómo los desarrolladores de &os; manejan y gestionan los informes de problemas.
diff --git a/es_ES.ISO8859-1/articles/releng/article.sgml b/es_ES.ISO8859-1/articles/releng/article.sgml index b62e57e921..773331a953 100644 --- a/es_ES.ISO8859-1/articles/releng/article.sgml +++ b/es_ES.ISO8859-1/articles/releng/article.sgml @@ -1,1149 +1,1135 @@ -%man; - %freebsd; - %newsgroups; - -%authors; - -%mailing-lists; - -%translators; - -%trademarks; - -%teams; - + +%articles.ent; ]>
Proceso de generación de releases en FreeBSD November 2001 BSDCon Europe Murray Stokely He estado colaborando con el desarrollo de productos basados en FreeBSD desde 1997 en Walnut Creek CDROM, BSDi, y actualmente en Wind River Systems. FreeBSD 4.4 ha sido la primera release en la que he tenido el placer de participar.
murray@FreeBSD.org
$FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.xfree86; &tm-attrib.general; Este artículo describe la aproximación utilizada por el equipo de ingeniería de productos de FreeBSD para generar releases de calidad y listas para utilizar en entornos de producción. Se detalla la metodología utilizada para generar la release oficial de FreeBSD y se describen las herramientas disponibles para aquellas personas interesadas en generar sus propias releases a medida de sus necesidades, en particular para demostraciones de empresa o para comercializar el producto. &trans.es.jrh;
Introducción El desarrollo de &os; es un proceso realmente abierto al público. FreeBSD se alimenta de contribuciones de miles de personas del mundo entero. El Proyecto &os; proporciona acceso público a través de CVS[1] de tal forma que cualquiera puede acceder a los mensajes de log y a los archivos de diferencias (también conocidos como diffs o parches) aplicados a distintas ramas de desarrollo, junto con el resto de funcionalidad que el gestor de código fuente pone a nuestra disposición. Este hecho, aunque muchas veces pasa inadvertido, ha constituido uno de los más importantes recursos de la comunidad y ha servido para captar y motivar a muchos desarrolladores con talento. No obstante, y creo que todo el mundo está de acuerdo con lo que voy a decir, sería un completo caos proporcionar acceso de escritura a todo el que pueda conectarse a Internet. Es por esto que existe sólo un selecto grupo de en torno a 300 personas que poseen dicho acceso de escritura en el repositorio de CVS. Estos committers[6] se responsabilizan del desarrollo del corazón de &os;. Un core-team[7] compuesto por desarrolladores muy experimentados proporciona ciertas directrices a la dirección que va a tomar el proyecto. El rápido ritmo de desarrollo de FreeBSD deja poco tiempo para pulir el sistema y proporcionar una release de calidad equivalente a las releases de sistemas comerciales. Para resolver este problema, se continúa el desarrollo en dos caminos paralelos. La rama de desarrollo principal se denomina HEAD o trunk (tronco) y constituye el punto de desarrollo más avanzado del árbol CVS. Esta rama consituye lo que llamamos FreeBSD-CURRENT o simplemente -CURRENT para abreviar. También se mantiene una rama más estable, conocida como FreeBSD-STABLE o -STABLE. Ambas ramas conviven en el repositorio maestro de CVS localizado en California y dicho repositorio se replica vía CVSup[2] creandose una serie de réplicas (también llamadas espejos o mirrors) por todo el mundo. FreeBSD-CURRENT[8] consituye el límite tecnológico (o bleeding-edge en inglés) del desarrollo del sistema &os; y es donde se aplican en primer lugar cualquier cambio realizado al sistema. FreeBSD-STABLE constituye la rama de desarrollo de la cual se generan las releases principales. Los cambios en el sistema se producen a un ritmo variable asumiendose que dichos cambios generalmente se aplican primero a la rama -CURRENT, quedando a disposición de la comunidad de usuarios para que comprueben el correcto funcionamiento global del sistema de una forma exhaustiva antes de aplicarlos a -STABLE, en caso de que fuera necesaria su aplicación. En el periodo entre releases, se construyen copias del sistema tomadas a determinadas horas de la noche y se ponen a disposición del público en ftp://stable.FreeBSD.org/. La amplia disponibilidad de releases de copias binarias actualizadas del sistema (snapshosts) y la tendencia de nuestra comunidad de usuarios a mantenerse a la última del desarrollo en la rama -STABLE mediante la utilización de CVSup y make world[8] ayuda a mantener la rama FreeBSD-STABLE en unas condiciones de fiabilidad excelentes que incluso llegan a ralentizar las peticiones de nuevas releases basadas en actividades de depuración de la calidad del software. Los informes de problemas y las solicitudes de nuevas características no paran de producirse durante el ciclo de vida de una release. Los informes de problemas se almacenan en la base de datos GNATS[9] utilizando el correo eletrónico, la aplicación &man.send-pr.1; o vía la interfaz web proporcionada en . Además de la multitud de listas de correo de carácter técnico que &os; pone a nuestra disposición, el &a.qa; proporciona un foro de discusión sobre aspectos a pulir del sistema antes de su salida. Para dar servicio a nuestro usuarios más conservadores, con la aparición de FreeBSDD 4.3 se introdujeron ramas individuales dentro del árbol CVS. Estas ramas de releases se crean poco tiempo después de la generación de una release final. Una vez generada la última release (la más actual o más reciente), sólo se aplican a esta release las modificaciones más críticas o necesarias, normalmente aquellas que provienen de fallos de seguridad. Además de las actualizaciones del código fuente a través de CVS, existen paquetes de parches binarios para mantener las releases RELENG_X_Y actualizadas. La describe las distintas fases del proceso de ingeniería de releases que se utiliza para construir el sistema real mientras que describe el proceso de contrucción en sí mismo. describe cómo la release base puede ser ampliada por terceras partes y detalla algunas de las lecciones aprendidas durante la generación de la release FreeBSD 4.4. Por último, presenta caminos futuros de desarrollo. Proceso de ingeniería de releases Las nuevas release de FreeBSD se generan a partir de la rama -STABLE en intervalos de aproximadamente cuatro meses. El proceso comienza a ejecutarse 45 días antes de la fecha de salida, cuando el ingeniero de releases envía un correo eletrónico a las listas de desarrollo de FreeBSD para recordar a los desarrolladores que disponen de tan solo 15 días para integrar nuevos cambios antes de la fase de congelación de código fuente. Durante este periodo de tiempo, muchos desarrolladores realizan lo que se ha dado en llamar barrido MFC. MFC significa en inglés Merge From CURRENT (Integración desde CURRENT) y describe el proceso de unificación de los cambios aplicados en la rama de desarrollo -CURRENT a nuestra rama -STABLE. Revisión de Código Treinta días antes del lanzamiento de una release dada el repositorio de código fuente entra en una fase de code slush (código aguanieve, en el sentido de no estar aún congelado y ser por tanto ligeramente moldeable). Durante este período todos los commits de la rama -STABLE deben ser aprobados por el &a.re;. Los cambios permitidos en esta fase de 15 días de duración son los siguientes: Arreglo de bugs o errores. Actualizaciones de la documentación. Parches relacionados con cualquier tipo de fallo en la seguridad. Cambios pequeños en controladores de dispositivos, tales como la adición de identificadores de dispositivo. Cualquier cambio adicional que el equipo de ingeniería de releases considere justificado, teniendo siempre en cuenta el riesgo potencial que puede conllevar. Después de los primeros 15 días de código slush, se genera una release candidate (candidata a release) o RC para su testeo exhaustivo por parte de la comunidad de usuarios y el código fuente entra en la fase de code freeze o congelamiento. En este punto resulta mucho más difícil aceptar cambios a menos que se descubran serios fallos de seguridad o bugs importantes. Durante esta fase, se genera al menos una RC cada semana, hasta que la release final ve la luz. Durante el periodo de tiempo comprendido desde el congelamiento del código hasta la generación de la release final, el equipo de ingeniería de releases se comunica constantemente con el equipo del security officer, los equipos encargados de mantener la documentación y los mantenedores de ports, para asegurarse de que los distintos componentes necesarios para obtener una release existosa se encuentran disponibles y listos para ser construidos. Lista de tareas para la release final. Cuando todos los problemas encontrados en las releases candidatas se han corregido, se puede comenzar con el procedimiento de pulimiento o enbellecimiento de la release final. Creación de una Rama Release Como se describe en la introducción, la rama RELENG_X_Y es una característica relativamente nueva de nuestra metodología de generación de releases. El primer paso para crear esta rama consiste en asegurar que el código fuente utilizado proviene de la versión más reciente de RELENG_X. /usr/src&prompt.root; cvs update -rRELENG_4 -P -d El siguiente paso consiste en crear una etiqueta de rama, (tag), de esta forma se pueden generar diferencias entre el código actual y la rama de inicio fácilmente, utilizando CVS: /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src Y a continuación se crea la etiqueta de la rama: /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src Las etiquetas RELENG_* sólo pueden ser utilizadas por los CVS-meisters y los ingenieros de releases. Una etiqueta o tag es una característica de CVS que sirve para identificar el código fuente en un determinado instante del tiempo. Mediante el etiquetado del árbol, nos aseguramos de que las futuras releases puedan generar diferencias con respecto al mismo código fuente que se utilizó para generar las releases oficiales anteriores. Rama FreeBSD Development (Rama de Desarrollo) Rama FreeBSD 3.x STABLE Rama FreeBSD 4.x STABLE Elevación del número de versión Antes de que la release final se puede etiquetar, construir y antes de que vea la luz, se deben modificar los siguientes ficheros de tal forma que reflejen el número de versión correcto: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml doc/en_US.ISO8859-1/books/porters-handbook/book.sgml doc/share/sgml/freebsd.ent src/Makefile.inc1 src/UPDATING src/gnu/usr.bin/groff/tmac/mdoc.local src/release/Makefile src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl src/release/doc/share/examples/Makefile.relnotesng src/release/doc/share/sgml/release.ent src/share/examples/cvsup/standard-supfile src/sys/conf/newvers.sh src/sys/sys/param.h src/usr.sbin/pkg_install/add/main.c www/en/docs.sgml www/en/cgi/ports.cgi ports/Tools/scripts/release/config El fichero release notes y el fichero errata también deben ajustarse de acuerdo con la nueva release (en la rama de la release) y deben cortarse adecuadamente en las ramas stable/currrent): src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml src/release/doc/en_US.ISO8859-1/errata/article.sgml Sysinstall debe actualizarse para que proporcione el número actual de ports disponibles y la cantidad de espacio de disco requerida para instalar dicha colección de ports. Esta información se encuentra almacenada actualmente en el fichero src/release/sysinstall/dist.c. Después de construir la release se debe actualizar el número almacenado en los siguientes ficheros para anunciar la release al resto del mundo: www/share/sgml/includes.release.sgml www/share/sgml/includes.release.xsl www/en/releases/* www/en/releng/index.sgml www/en/news/news.xml www/en/search/web.atoz src/share/misc/bsd-family-tree Creación de las etiquetas de release Cuando la release final se encuentra preparada se utiliza el siguiente comando para crear la etiqueta (a modo de ejemplo) RELENG_4_8_0_RELEASE. /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src Los gestores de los proyectos de Documentación y de los Ports se responsabilizan del correcto etiquetado de sus respectivos árboles utilizando RELEASE_4_8_0. Ocasionalmente se puede presentar un apaño o arreglo de última hora justo después de la creación de las etiquetas finales. En la práctica esto no constituye un problema ya que CVS permite cierta manipulación de etiquetados mediante cvs tag -d nombredeetiqueta nombredefichero . Es muy importante que dichos cambios de última hora se etiqueten adecuadamente para que pasen a formar parte de la nueva release. Las releases de &os; deben ser siempre reproducibles. Los hacks locales dentro del entorno de ingeniería de releases no están permitidos salvo que se efectúen mediante una correcta manipulación y notificación. Construcción de la Release Cualquier persona dueña de una potente máquina y con acceso de lectura al repositorio de código fuente puede construir las releases de &os;. En la práctica esto significa que cualquiera puede generar el proceso de construcción de releases, ya que, como se comentó con anterioridad, &os; ofrece acceso CVS anónimo a todo el mundo (consulte el Handbook para más detalles). El único requisito imprescindible para realizar este proceso es la existencia del dispositivo &man.vn.4;. (En -CURRENT, este dispositivo ha sido reemplazado por el nuevo driver de discos en memoria denominado &man.md.4;.) Si el dispositivo no se encuentra cargado en el kernel, debería cargarse automáticamente al ejecutar el comando &man.vnconfig.8; como parte de la fase de creación del medio de arranque. Todas las herramientas necesarias para construir la release se encuentran disponibles en el repositorio de CVS dentro del directorio src/release. Estas herramientas proporcionan una forma consistente y robusta de construir releases de &os;. Una release completa se puede construir utilizando un único comando, incluyendo la creación de las imágenes ISO necesarias para realizar copias en CDROM, junto con disquetes de instalación y un directorio para la instalación por FTP. Este comando fue adecuadamente bautizado como make release. <command>make release</command> Para poder construir la releases de una forma exitosa se debe rellenar primero el directorio /usr/obj ejecutando el comando make world o simplemente make buildworld. El target release que utiliza el comando make necesita varias variables, tal como se muestra a continuación: CHROOTDIR - El directorio que se utiliza para el entorno de chroot durante la construcción de la release entera. BUILDNAME - El nombre de la release que se va a construir. CVSROOT - La ubicación del repositorio de CVS. RELEASETAG - La etiqueta CVS correspondiente con la release que se quiere construir. Si no se dispone de acceso a un repositorio de CVS local, se puede realizar una copia espejo (un mirror) con CVSup. El fichero /usr/share/examples/cvsup/cvs-supfile, sirve como buen punto de partida para realizar un mirror del repositorio de CVS. Si se omite RELEASETAG, la release se construirá a partir de la rama HEAD (también conocida como -CURRENT). Las releases que se construyen desde el principio se conocen normalmente con el nombre de -CURRENT snapshots. Existen otras variables que se pueden editar para adaptar el proceso de construcción de la release. La mayoría de estas variables se encuentran documentadas al comienzo de src/release/Makefile. El comando exacto para contruir la release oficial de FreeBSD 4.7 (x86) fue: make release CHROOTDIR=/local3/release \ BUILDNAME=4.7-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs \ RELEASETAG=RELENG_4_7_0_RELEASE El Makefile de la release se puede dividir en varios pasos distintos. Creación de un entorno de sistema limpio en una jerarquía de directorios separada utilizando make installworld. Comprobación de la correcta versión de los ficheros fuentes almacenados en la jerarquía de directorios recién creada, junto con el chequeo de la documentación y de los ports utilizando, todo ello a través de CVS. Relleno de los directorios /etc y /dev dentro del entorno chroot. Creación de un chroot dentro de la jerarquía de directorios creada, para que resulte más dificil que el entorno de la máquina se vea contaminado por la construcción de la release. make world dentro del entorno de chroot. Contrucción de los binarios relacionados con Kerberos. Construcción del kernel GENERIC. Creación de un esqueleto del árbol de directorios donde se construirán y empaquetarán las distribuciones binarias. Construcción e instalación del conjunto de herramientas de documentación necesarias para convertir los fuentes de la documentación (SGML) en los documentos HTML y de texto que pasarán a formar parte de la release. Construcción e instalación de la documentación real (manuales de usuario, tutoriales, release notes, listas de compatibilidad de hardware, etc.) Construcción de los decisivos binarios utilizados en los disquetes de instalación. Colocación adecuada de los de los paquetes de distribución de binarios y de fuentes. Creación del medio de arranque y del disquete fixit o salvamento. Creación de la jerarquía de directorios de instalación por FTP. Creación de imágenes ISO para CDROM/DVD(opcional). Para más información sobre la infraestructura involucrada en el proceso de construcción de la release, el lector puede consultar &man.release.7;. Construcción de<application>&xfree86;</application> &xfree86; es un componente importante para muchos usuarios de entornos gráficos. Antes de la release &os; 4.6 las se usaba &xfree86;3.X por defecto. La forma más sencilla de construir estas versiones consiste en utilizar el script src/release/scripts/X11/build_x.sh. Este script requiere que &xfree86; y Tcl/Tk se encuentren instalados previamente en la máquina donde se realiza la construcción. Después de compilar los servidores X necesarios, el script empaqueta todos los ficheros en tarballs que &man.sysinstall.8; sabe cómo localizar utilizando el directorio XF86336 del medio de instalación. A partir de FreeBSD 4.6, &man.sysinstall.8; instala &xfree86; 4.X por defecto, como cualquier otro conjunto de paquetes. Estos paquetes se pueden construir a partir del package-building cluster o a partir de las etiquetas del árbol de ports adecuadas. Es importante borrar cualquier configuración particular almacenada en /etc/make.conf. Por ejemplo, no sería una idea muy inteligente distribuir binarios que se construyeron en un sistema con la variable CPUTYPE asignada a un determinado procesador. Software Contribuido (<quote>ports</quote>) La colección de FreeBSD Ports está compuesta por más de &os.numports; paquetes de software de terceras partes que se encuentran disponibles para &os;. El &a.portmgr; se responsabiliza de mantener un árbol de ports consistente que se pueda utilizar para crear paquetes binarios, los cuales se añaden a las releases oficiales de FreeBSD. Las actividades de ingeniería de releases para nuestra colección de paquetes software de terceras partes se encuentra más allá del objetivo de este documento. Otro artículo, , cubre este tema en profundidad. ISOs de la release A partir de FreeBSD 4.4, el Proyecto FreeBSD decidió lanzar gratuitamente al público las cuatro imágenes ISO que anteriormente se vendían en BSDi/Wind River Systems/FreeBSD Mall como distribuciones en CDROM oficiales. Cada uno de los cuatro discos debe contener un README.TXT que explica el contenido de cada disco, un CDROM.INF que proporciona metadatos para que &man.sysinstall.8; pueda validar la información en él contenida y un filename.txt que proporciona un manifiesto. Este manifiesto se puede crear utilizando un simple comando: /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt Los requisitos concretos de cada CD se resumen a continuación. Disco 1 El primer disco se crea casi en su totalidad a partir del comando make release. Los únicos cambios que se deben realizar dentro del directorio disc1 son la adición de un directorio tools, de &xfree86; y de los paquetes de terceras partes más populares que quepan dentro del espacio remanente de dicho primer disco. El directorio tools contiene el software que permite a los usuarios crear disquetes de instalación desde otros sistemas operativos. Este disco debe crearse como autoarrancable para que los usuarios de PCs modernos no necesiten crear disquetes de arranque y puedan utilizar la característica de autoarranque desde CD. Si se proporciona una versión alternativa de &xfree86;, &man.sysinstall.8; debe actualizarse para reflejar la nueva localización y las instrucciones de instalación. El código relevante se encuentra en src/release/sysinstall en -STABLE o en src/usr.sbin/sysinstall en -CURRENT. Específicamente, se deben actualizar dist.c, menus.c y config.c. Disco 2 El segundo disco se crea en su mayor parte a partir del comando make release. Este disco contiene un sistema de ficheros vivo, que se puede utilizar a partir de &man.sysinstall.8; para resolver problemas durante el proceso de instalación de &os;. Este disco se debe construir como autoarrancable y debe contener una copia comprimida del repositorio de CVS dentro del directorio CVSROOT, junto con demostraciones de software comercial localizadas dentro del directorio commerce. Discos 3 and 4 Los dos discos que quedan contienen paquetes de software para &os;. Estos paquetes deben agruparse de tal forma que un paquete y todas sus dependencias quepan en el mismo disco. Se puede obtener más información sobre la creación de estos discos en el artículo . Distribución Servidores de FTP Cuando se ha probado exhaustivamente la release y se ha empaquetado debidamente para proceder a su distribución, se debe actualizar el sitio maestro de FTP. Los sitios FTP oficiales de FreeBSD son mirrors del sitio FTP maestro, también llamado ftp-master. Cuando la release está lista, se deben modificar los siguientes ficheros en el servidor ftp-master: /pub/FreeBSD/releases/arch/X.Y-RELEASE/ El directorio de instalación dde FTP que se crea con la salida del comando make release. /pub/FreeBSD/ports/arch/packages-X.Y-release/ La construcción del paquete completo de la release. /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools Un enlace simbólico a ../../../tools. /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages Un enlace simbólico a ../../../ports/arch/packages-X.Y-release. /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso Las imágenes ISO. El * se sustituye por disc1, disc2, etc. Solo si existe disc1 junto con un CD de primera instalación alternativo (por ejemplo una instalación recortada o reducida sin sistema de ventanas) puede existir también un mini. Para obtener más información sobre la arquitectura de mirrors para la distribución del sistema FreeBSD, se ruega al lector que consulte el artículo Mirroring FreeBSD. Puede que transcurran desde varias horas hasta varios días hasta que la mayoría de los sitios FTP Tier-1 se actualicen con respecto al ftp-master, esto depende de si un determinado paquete se cargó o no se cargó en determinado instante. Es imperativo que los ingenieros de releases se coordinen con &a.mirror-announce; antes de anunciar la disponibilidad general del nuevo software en los sitios FTP. Para que todo fuera bien el paquete de la release se debería cargar al menos cuatro días antes del día oficial de lanzamiento de la release. Los permisos para el grupo other deben desactivarse completamente para que los sitios espejos puedan descargar la release pero no así los usuarios finales, hasta que llegue el día oficial del lanzamiento. Se debe enviar un correo a &a.mirror-announce; cuando se publican la release con los permisos modificados, diciendo que la release ha sido puesta en escena y proporcionando la fecha a partir de la cual los mirrors deben comenzar a dar permisos de acceso para el público en general. Se debe comprobar que se incluye información relativa a zonas horarias, por ejemplo información relativa a GMT. Replicación de CD-ROMs Dentro de poco tiempo: Consejos para enviar ISOs de FreeBSD a un replicador e información sobre las medidas de aseguramiento de la calidad que se deben tomar. Extensibilidad Aunque &os; consitituye un sistema operativo completo, no existe nada que nos obligue a utilizarlo exactamente igual que como se ha empaquetado para crear la distribución. Es decir, el sistema &os; se ha diseñado para ser tan extensible como sea posible de tal forma que se puede utilizar como la base sobre la que se pueden construir productos comerciales. La única regla sobre este tema es que si se piensa distribuir &os; con una serie de cambios profundos en él , se anima a que se documenten adecuadamente dichos mejoras. La comunidad &os; sólo puede ayudar a los usuarios que utilizan el software que dicha comunidad distribuye. Se anima encarecidamente hacia la innovación tanto en el proceso de instalación como en las herramientas de administración, pero no se puede esperar un respuesta a todas las preguntas que surgan sobre dichos temas. Creación de disquetes de arranque a medida Muchas organizaciones poseen complejos requisitos que pueden consistir en módulos del kernel adicionales o herramientas de entorno de usuario que deben añadirse en los discos de instalación. La forma rápida y sucia de añadir estas cosas consiste en modificar el directorio temporal que contiene la estructura de un make release: Aplicar parches o añadir archivos adicionales dentro del directorio chroot de construcción de la release. rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] Reconstruir &man.sysinstall.8;, el kernel o cualquier otra parte del sistema que se vea afectada por los cambios. chroot ${CHROOTDIR} ./mk floppies Los nuevos disquetes de instalación estarán en ${CHROOTDIR}/R/stage/floppies. También se puede llamar el objetivo de make boot.flp o directamente al script de creación del sistema de ficheros src/release/scripts/doFS.sh. Los parches locales también se pueden proporcionar al proceso de construcción de la release mediante la definición de la variable LOCAL_PATCH dentro de make release. <quote>Scripts</quote> para <command>sysinstall</command> La instalación y configuración del sistema &os; a través de &man.sysinstall.8; se puede modificar mediante scripts para que proporcione instalaciones automáticas a grandes organizaciones. Esta funcionalidad se puede utilizar conjuntamente con &intel; PXE[13] para arrancar sistemas a través de la red, o a través de disquetes de arranque a medida utilizando un script de sysinstall. Un ejemplo de guión sysinstall se encuentra disponible en src/release/sysinstall/install.cfg. Lecciones aprendidas a partir de FreeBSD 4.4 El proceso de ingeniería de releases de FreeBSD 4.4 comenzó formalmente el 1 de Agosto de 2001. Después de esa fecha todos los commits o modificaciones sobre la rama RELENG_4 de FreeBSD tuvieron que ser aprobados explícitamente por el &a.re;. La primera release candidate para la arquitectura x86 apareció el 16 de Agosto, seguida por otras cuatro releases candidatas hasta que vió la luz la release final el 18 de Septiembre. El security officer estuvo muy involucrado en la última semana del proceso ya que se descubrieron varios problemas de seguridad en las release candidates iniciales. Más de 500 correos electrónicos fueron enviados al &a.re; en poco más de un mes. Nuestra comunidad de usuarios ha dejado muy claro que la seguridad y estabilidad de las releases de FreeBSD no pueden sacrificarse por culpa de plazos autoimpuestos o fechas de lanzamiento. El Proyecto &os; ha crecido tremendamente durante su tiempo de vida y se ha visto claramente la necesidad de estandarizar los procedimientos de ingeniería de releases. Este hecho será incluso más importante a medida que &os; vaya estando disponible para más plataformas. Directrices para el futuro Es de vital importancia para nuestras actividades de ingeniería de releases el ser capaces de crecer al mismo ritmo que nuestra base de usuarios. Junto con estas líneas estamos trabajando duramente en los procedimientos involucrados en la producción de releases de FreeBSD. Paralelismo - Algunas partes de la construcción de la release son vergonzosamente paralelas. La mayoría de las tareas que se realizan son intensivas en entrada-salida, de tal forma que resulta más importante poseer varios discos duros de alta velocidad que utilizar varios procesadores a la hora de acelerar el proceso del comando make release. Si se utilizan varios discos para las distintas jerarquías de directorios dentro del entorno &man.chroot.2;, entonces el checkout de los árboles de ports y de los doc se puede producir al mismo tiempo que la ejecución en otro disco del comando make world. Mediante la utilización de un sistema RAID (hardware o software) se puede reducir significativamente el tiempo total de construcción de la release. Releases construidas para otros sistemas finales (cross building) : ¿Se puede construir una release para IA-64 o Alpha en un hardware x86? make TARGET=ia64 release. Tests de Regresión - Se necesitan mejores herramientas automatizadas para comprobar la corrección del sistema &os;. Herramientas de Instalación - Nuestro programa de instalación ha sobrepasado su tiempo de vida previsto. Se encuentran en desarrollo varios proyectos para proporcionar un mecanismo de instalación más avanzado. Uno de los más prometedores es el proyecto libh[5] cuyo objetivo consiste en proporcionar un entorno de paquetes nuevo e inteligente junto con un programa de instalación gráfico. Agradecimientos Me gustaría agradecer a Jordan Hubbard por darme la oportunidad de colaborar en algunas de las responsabilidades del equipo de ingeniería de releases en FreeBSD 4.4 y también me gustaría agradecer públicamente su trabajo y dedicación durante todos estos años para poder situar a &os; en el sitio de honor que le corresponde hoy día. Por supuesto que la release 4.4 no hubiera visto la luz sin el trabajo de &a.asami;, &a.steve;, &a.bmah;, &a.nik;, &a.obrien;, &a.kris;, &a.jhb; y del resto de la comunidad &os;. También me gustaría agradecer especialmente a &a.rgrimes;, &a.phk; y muchos otros que trabajaron en las herramientas de ingeniería de releases en los comienzos del sistema &os;. Este artículo está basado en documentos de ingeniería de releases del CSRG[14], el NetBSD Project[11] y en las notas del proceso de ingeniería de releases propuestas por John Baldwin[12]. Lecturas recomendadas [1] CVS - Concurrent Versions System [2] CVSup - The CVS-Optimized General Purpose Network File Distribution System [3] [4] FreeBSD Ports Collection [5] The libh Project [6] FreeBSD Committers [7] FreeBSD Core-Team [8] FreeBSD Handbook [9] GNATS: The GNU Bug Tracking System [10] FreeBSD PR Statistics [11] NetBSD Developer Documentation: Release Engineering [12] John Baldwin's FreeBSD Release Engineering Proposal [13] PXE Jumpstart Guide [14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD
diff --git a/es_ES.ISO8859-1/articles/zip-drive/article.sgml b/es_ES.ISO8859-1/articles/zip-drive/article.sgml index 648b2693ae..5033206ff1 100644 --- a/es_ES.ISO8859-1/articles/zip-drive/article.sgml +++ b/es_ES.ISO8859-1/articles/zip-drive/article.sgml @@ -1,327 +1,321 @@ -%man; - -%freebsd; - - -%translators; - + +%articles.ent; ]>
Unidades ZIP Jason Bacon
acadix@execpc.com
&trans.es.bazcar;
Introducción a las Unidades ZIP Los discos ZIP son dispositivos magnéticos, extraíbles y de alta capacidad que pueden leerse y escribirse mediante unidades ZIP de IOMEGA. Los discos ZIP son similares a los disquetes (floppy) pero son mucho más rápidos y ofrecen una capacidad de almacenamiento mucho mayor. Así como los disquetes suelen ser de 1'44 MB los discos ZIP existen en dos tamaños, de 100 y 250 MB. Los discos ZIP no deben ser confundidos con el formato super-floppy, un dispositivo que usa disquetes de 120 MB pero que admite los discos tradicionales de 1'44 MB. IOMEGA distribuye asímismo unidades de rendimiento más alto y mucha mayor capacidad llamadas JAZZ. Las unidades JAZZ usan discos de 1 y 2 GB. Las unidades ZIP están disponibles como dispositivos internos y externos y emplean una de los siguientes interfaces: El interfaz SCSI es el más rápido, sofisticado, expandible y caro. El interfaz SCSI se usa en todo tipo de plataformas, desde PC y estaciones RISC a miniordenadores para conectar todo tipo de periféricos como discos duros, unidades de cinta, scanners, etc. Los dispositivos ZIP SCSI pueden ser internos o externos, que requieren que la controladora SCSI disponga de un conector externo. Si usa una unidad SCSI externa es importante que nunca la conecte o desconecte del bus SCSI mientras el ordenador está funcionando. Si lo hace puede causar daños en el sistema de ficheros del resto de los discos del sistema. Si lo que busca es el máximo rendimiento y una sencilla configuración el interfaz SCSI es la mejor elección. Probablemente tendrá que añadir una controladora SCSI dado que la mayoría de los PC (salvo los servidores de alto rendimiento) no ofrecen soporte SCSI integrado. Cada controladora SCSI puede admitir entre 7 y 15 dispositivos SCSI dependiendo del modelo. Cada unidad SCSI tiene su propio controlador y esos controladores son razonablemente inteligentes y están bien estandarizados (la segunda S de SCSI viene de Standard), de manera que desde el punto de vista del sistema operativo, todos los dispositivos SCSI parecen ser el mismo, como sucede con las unidades de cinta SCSI, etc. Para poder utilizar dispositivos SCSI el sistema operativo necesita únicamente un driver específico para la controladora que se desea usar y un driver genérico para cada tipo de dispositivo, ésto es, un disco SCSI, una unidad de cinta SCSI, etc. Algunos dispositivos SCSI pueden ser mejor aprovechados mediante drivers especializados (v.g. unidades de cinta DAT) pero tienden a funcionar perfectamente con los drivers genéricos, que sencillamente puede que no incluyan alguna de las características especiales. El usar una unidad ZIP SCSI es algo tan simple como determinar cuál es el fichero de dispositivo en el directorio /dev que representa la unidad ZIP. Esto puede saberse examinando el mensaje de arranque de FreeBSD (o en /var/log/messages tras el arranque), donde debería encontrar algo parecido a: da1: <IOMEGA ZIP 100 D.13> Removable Direct Access SCSI-2 Device Esto significa que la unidad ZIP está representada por el fichero /dev/da1. El interfaz IDE es un interfaz de acceso a discos duros de bajo coste que se usa en la mayoría de los PC de escritorio. La mayoría de los dispositivos IDE son exclusivamente internos. El rendimiento de los dispositivos ZIP IDE es comparable al de los ZIP SCSI. (El interfaz IDE no es tan rápido como el SCSI pero el rendimiento de los dispositivos ZIP está condicionado principalmente por la parte mecánica del dispositivo, no por el interfaz del bus). El inconveniente del interfaz IDE son las limitaciones que conlleva. La mayoría de adaptadores IDE sólo permiten utilizar dos dispositivos y generalmente los interfaces IDE no están diseñados para perpetuarse en el tiempo. Por ejemplo, el interfaz IDE original no admite discos duros con más de 1.024 cilindros, lo que obligó a mucha gente a actualizar su hardware antes de lo esperado. Si prevé añadir nuevo hardware a su PC (otro disco duro, una unidad de cinta, un scanner, etc.) no estaría de más que considerara la idea de adquirir una controladora y un ZIP SCSI para evitar problemas en el futuro. En FreeBSD los dispositivos IDE llevan el prefijo a. Por ejemplo, un disco duro IDE podría ser /dev/ad0, y un CDROM IDE (ATAPI) podría ser /dev/acd1, y así sucesivamente. El interfaz de puerto paralelo es muy común en dispositivos externos portátiles como dispositivos ZIP externos y scanners debido a que virtualmente todos los ordenadores disponen de un puerto paralelo estándar (que generalmente se usa con impresoras). De éste modo se le facilitan las cosas a mucha gente a la hora de transferir datos entre distintos equipos. Generalmente el rendimiento es menor que el de dispositivos ZIP IDE o SCSI dadas las limitaciones de velocidad del puerto paralelo. Ésta puede variar según el caso concreto y con frecuencia puede configurarse en la BIOS del sistema. En algunos casos es imprescindible configurar en la BIOS el puerto paralelo para que admita el modo bidireccional puesto que los puertos paralelos fueron originalmente concebidos para verter su salida hacia las impresoras. ZIP de Puerto Paralelo: El <quote>driver</quote> <devicename>vpo </devicename> Para usar en FreeBSD un dispositivo ZIP de puerto paralelo debe incluírse en el kernel el driver vpo . Los dispositivos ZIP de puerto paralelo disponen de un controlador SCSI integrado. El driver vpo permite al kernel de FreeBSD comunicarse con el controlador SCSI del dispositivo ZIP a través del puerto paralelo. Dado que el driver vpo no forma parte del kernel GENERIC (el kernel que se instala con FreeBSD) a partir de FreeBSD 3.2 necesita recompilar su kernel para activar éste dispositivo. Una de las maneras de recompilar el kernel se detalla más adelante en éste mismo texto. Los pasos a seguir para activar el driver vpo podrían ser los siguientes: Ejecute /stand/sysinstall e instale los fuentes del kernel en su sistema. Crearemos un fichero de configuración del kernel que incluya el driver vpo: &prompt.root; cd /sys/i386/conf &prompt.root; cp GENERIC MIKERNEL Editamos MIKERNEL para sustituír la entrada ident por MIKERNEL y descomentamos la línea en la que aparece el driver vpo. Si dispone de un segundo puerto paralelo deberá copiar la sección ppc0 para crear el dispositivo ppc1. El segundo puerto paralelo suele usar la IRQ 5 y la dirección 378. Solamente es imprescindible asignar la IRQ en el fichero de configuración. Si su disco duro principal es SCSI puede tener problemas durante la prueba de dispositivos SCSI que FreeBSD efectúa en el arranque, dado que el sistema puede intentar utilizar el dispositivo ZIP como disco de inicio. Esto produciría un fallo en el arranque salvo, claro está, que disponga de un sistema de ficheros raíz en su disco ZIP. Si ese es su caso debe forzar al kernel a enlazar un dispositivo concreto (en éste caso su disco duro raíz) con /dev/da0/. El kernel asignará al disco ZIP el siguiente nombre SCSI disponible, es decir, /dev/da1. Para fijar su disco duro SCSI como da0 cambie la línea device da0 a disk da0 at scbus0 target 0 unit 0 Quizás necesite modificar la línea anterior para que concuerde con los datos de su dispositivo SCSI. Del mismo modo tendría que asociar la entrada scbus0 con su controladora. Por ejemplo, si tiene una controladora Adaptec 15xx debería cambiar controller scbus0 por controller scbus0 at aha0 Para concluír, dado que está creando un kernel personalizado debería aprovechar la ocasión para eliminar todos los drivers que no necesita. Esto debe hacerse con precaución y solamente cuando tenga la seguridad de que sabe lo que está haciendo con su fichero de configuración. Si borra los drivers que no necesita reducirá el tamaño de su kernel y por lo tanto dispondrá de más memoria que ofrecer a sus aplicaciones. Para saber qué drivers puede borrar vaya al final del fichero /var/log/messages y busque líneas que incluyan not found (no encontrado). Comente las líneas de esos drivers en su fichero de configuración. Puede cambiar otras opciones más para reducir el tamaño e incrementar la velocidad de su kernel. Lea la sección del Handbook correspondiente a la recompilación del kernel para conocer todos los detalles. Ha llegado el momento de compilar nuestro kernel: &prompt.root; /usr/sbin/config MIKERNEL &prompt.root; cd ../../compile/MIKERNEL &prompt.root; make clean depend && make all install Una vez finalizado el proceso necesitará reiniciar. Asegúrese de que la unidad ZIP esté conectada al puerto paralelo antes del arranque. Verá aparecer el dispositivo ZIP en los mensajes del arranque como vpo0 o vpo1, dependiendo del puerto paralelo al que esté conectado. Debería aparecer también a qué nombre de dispositivo ha sido enlazado. Por ejemplo sería /dev/da0 si no hay en el sistema discos SCSI o /dev/da1 si tiene como dispositivo principal un disco SCSI. Cómo montar discos ZIP Para acceder a un disco ZIP simplemente hay que montarlo como cualquier otro dispositivo de disco. El sistema de ficheros estará representado como slice 4 dentro del dispositivo, tanto para discos SCSI o paralelos. Por ejemplo: &prompt.root; mount_msdos /dev/da1s4 /mnt Para unidades ZIP IDE, utilice: &prompt.root; mount_msdos /dev/ad1s4 /mnt Puede serle útil modificar /etc/fstab para montar los discos más fácilmente. Añada una línea como la siguiente (con las modificaciones necesarias para sus necesidades): /dev/da1s4 /zip msdos rw,noauto 0 0 y crée el directorio /zip. Hecho esto, puede montar su disco ZIP escribiendo: &prompt.root; mount /zip y para desmontarlo escriba &prompt.root; umount /zip Tiene todos los detalles del formato en el que incluír o modificar entradas en /etc/fstab en &man.fstab.5;. Si quiere puede crear un sistema de ficheros de FreeBSD en un disco ZIP empleando &man.newfs.8;. Sin embargo eso convertiría a ese disco en legible solamente en un sistema FreeBSD y y quizás en unos pocos sistemas clónicos de &unix; que reconocen el sistema de ficheros de FreeBSD. En cualquier caso DOS y Windows no están entre ellos.
diff --git a/es_ES.ISO8859-1/books/faq/book.sgml b/es_ES.ISO8859-1/books/faq/book.sgml index af1173eb4a..1bea25cd47 100644 --- a/es_ES.ISO8859-1/books/faq/book.sgml +++ b/es_ES.ISO8859-1/books/faq/book.sgml @@ -1,9493 +1,9488 @@ -%freebsd; - -%teams; -%bookinfo; - -%mailing-lists; + +%books.ent; ]> Preguntas más frecuentes de FreeBSD 4.X, 5.X y 6.X Proyecto de documentación de FreeBSD $FreeBSD$ 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 The FreeBSD Documentation Project &bookinfo.legalnotice; Ésta es la FAQ de FreeBSD versión 4.X, 5.X y 6.X. Todas las secciones están dirigidas a FreeBSD 4.0 y superiores. Los capítulos con <XXX> están bajo construcción. Si estás interesado en colaborar en este proyecto, envía un e-mail a la lista de distribución del proyecto de documentación de FreeBSD (en inglés) &a.doc; o a la dirección doc@es.FreeBSD.org en castellano. La última versión de este documento está siempre disponible en el Mirror en español de FreeBSD. Puede obtenerse como un único archivo en formato HTML vía HTTP o en formato texto, PostScript o PDF desde el servidor FTP de FreeBSD. También se pueden hacer búsquedas en las FAQ. Introducción ¡Bienvenido a la FAQ de FreeBSD 4.X-6.X! Como es habitual con las FAQ de los grupos de noticias (USENET), este documento pretende abarcar las preguntas más frecuentes referentes al sistema operativo FreeBSD (¡y por supuesto contestarlas!). Pensadas en un principio para reducir el tráfico y evitar que se hagan las mismas preguntas una y otra vez, las FAQ se han convertido en un valorado recurso de obtención de información. Todo el esfuerzo se ha hecho en intentar que esta FAQ sea lo más informativa posible; si tienes cualquier comentario o sugerencia, por favor, envía un correo a &a.doc;. ¿Qué es FreeBSD? De manera resumida, FreeBSD es un sistema operativo tipo &unix; para plataformas Alpha/AXP, AMD64 e Intel EM64T, i386 IA-64, PC-98 y UltraSPARC basado en 4.4BSD-Lite de la Universidad de Berkeley en California. También está indirectamente basado en el port de Net/2 para i386 de Berkeley, conocido como 386BSD, realizado por William Jolitz's. Una descripción más detallada de FreeBSD y de cómo puede trabajar, se encuentra en FreeBSD home page. FreeBSD es usado por compañías, proveedores de Internet, profesionales de la informática, estudiantes y usuarios particulares de todo el mundo en su trabajo, educación y ocio. Puedes ver a algunos de ellos en FreeBSD Gallery. Para información más detallada sobre FreeBSD, por favor mira en FreeBSD Handbook. ¿Cuál es el objetivo del Proyecto FreeBSD? El objetivo del Proyecto FreeBSD es proveer software que pueda ser usado en todos los ámbitos sin ningún tipo de atadura. Muchos de nosotros estamos significativamente involucrados en el desarrollo del código (y del proyecto) y no sería cierto decir que no esperábamos o esperamos algún tipo de financiación, pero definitivamente no estamos preparados para insistir en ello. Creemos que nuestra primera y principal misión es proporcionar el código libremente, y en cualquier ámbito, para que el código se difunda lo más posible y genere los mayores beneficios. Esto es, creemos en uno de los objetivos fundamentales del Software Libre y lo apoyamos de manera incondicional. El código fuente de los programas registrados bajo la GNU General Public License (GPL) o la GNU Library General Public License (LGPL), se proporciona bajo las condiciones fijadas por esas licencias. Debido a complicaciones adicionales en el uso comercial de Software GPL, intentamos reemplazar ese software por otros registrados bajo la licencia FreeBSD,menos estricta y más permisiva. ¿Tiene la licencia FreeBSD alguna restricción? Si. Las restricciones no controlan el uso del código. Cualquier duda puede ser contestada leyendo la licencia. Esta misma puede ser resumida de la siguiente manera: No establecerse asi mismo como autor. No culpar al proyecto en caso de no funcionar. ¿Puede FreeBSD remplazar mi sistema operativo actual? Para la mayor parte de la gente, si. Aunqué esta pregunta no se contesta tan fácilmente. La mayoría de las personas no usa realmente un sistema operativo. Usan aplicaciones. Las aplicaciones son las que en realidad usan el sistema operativo. FreeBSD esta diseñado para proveer un ambiente robusto y listo para aplicaciones. Soporta una gran variedad de exploradores de web, suites de oficina, lectores de correo electrónico, programas de gráficos, ambientes de programación, servidores y casi todo lo que se desee. La mayor parte de estas aplicaciones pueden ser encontrádas en la Colección de Ports. Si se requiere de una aplicación solamente disponible para un sistema operativo, simplemente no puede cambiar ese sistema operativo. Aunqué muy probablemente encuentre una aplicación muy parecida en FreeBSD. Si lo que se desea es una sólida oficina o un servidor de Internet, una estación de trabajo confiable, o solamente la habilidad de trabajar sin interrupciones, FreeBSD seguramente hará lo que usted necesita. Una gran cantidad de usuarios alrededor del mundo, incluyendo novatos y usuarios de &unix; experimentados usan FreeBSD como su sistema operativo. Si se desea migrar a FreeBSD desde algún otro ambiente &unix;, usted ya sabe mas de lo que se necesita. Si su constumbre es un sistema operativo gráfico como Windows o viejas versiones de Mac OS, usted tendrá que invertir mas tiempo aprendiendo la forma en la que &unix; hace las cosas. Este FAQ y el FreeBSD Handbook son excelentes lugares donde empezar. ¿Por qué se llama FreeBSD? Este sistema debe ser usado libremente, sin coste alguno incluso para fines comerciales. El código fuente completo del sistema operativo es de libre distribución, y se han establecido el menor número posible de restricciones para su uso, distribución e incorporación a otras aplicaciones (comerciales o no). Cualquier persona que tenga alguna sugerencia de mejora y/o parche de algún bug, es libre de enviar el código y que éste sea añadido al código fuente de la distribución original (sujeto a una o dos condiciones obvias). Para todos nuestros lectores cuyo primer lenguaje no sea el inglés, aclaremos que la palabra free es usada en dos sentidos, uno significando sin coste y el otro puedes hacer lo que quieras. Aparte de una o dos cosas que no puedes hacer con el código de FreeBSD, por ejemplo decir que lo has escrito, realmente puedes hacer lo que quieras con él. ¿Cuales son las diferencias entre FreeBSD y NetBSD, OpenBSD y otros sistemas operativos BSD libres? James Howard escribió una buena explicación para DaemonNews, acerca de la historia y las diferencias entre los diferentes proyectos, llamada The BSD Family Tree, la cual puede contestar esta pregunta. ¿Cuál es la última versión de FreeBSD? La versión 4.9R es la última -STABLE; fue declarada definitiva (a partir de ahora release) en Diciembre de 2003. Brevemente explicado, está dirigido a proveedores de Internet y otros usuarios corporativos que quieren estabilidad y una sucesión tranquila en los cambios y actualizaciones a las nuevas versiones y sus mejoras. Sólo debes usar la rama -CURRENT si estás seguro de estar preparado para su mayor volatilidad (relativa a -STABLE). Las versiones Release se hacen cada varios meses. Aunque mucha gente mantiene más al día los fuentes de FreeBSD (lee las preguntas en FreeBSD-CURRENT y FreeBSD-STABLE, ello está pensado para gente que se considere preparada para seguir el desarrollo continuo del código fuente. ¿Qué es FreeBSD-CURRENT? FreeBSD-CURRENT es la versión de desarrollo del sistema operativo, la cual acabará siendo la versión &os.stable;. Como es de suponer, esta versión es de interés sólo para los desarrolladores que trabajan en el sistema y masoquistas de la programación. Mira la sección correspondiente en el handbook para saber cómo funciona esta opción. Si no estás familiarizado con el sistema operativo o no eres capaz de identificar la diferencia entre un problema real y un problema temporal, no deberías usar FreeBSD-CURRENT. Esta rama a veces avanza muy rápidamente y puede no ser compilable durante unos días. La gente que usa FreeBSD-CURRENT es capaz de analizar los problemas y sólo comunicarlos si son motivo de errores. Preguntas como al ejecutar make world obtengo un error referente a grupos en la lista de distribución -CURRENT pueden quedar fuera de lugar. Una release snapshot corresponde al desarrollo de la rama -CURRENT; distribuciones en CDROM de esta versión están disponibles. Los objetivos de cada release snapshot son: Comprobar la última versión del software de instalación. Dar a la gente que le gustaría usar la versión -CURRENT, pero que no tiene el tiempo suficiente para seguir el ritmo diario de actualizaciones, una manera fácil de poder instalarla en su sistema. Preservar un punto de referencia fijado en el código en cuestión, sólo en caso de que ``rompamos'' algo realmente importante. (De todas maneras, el CVS normalmente previene de que cosas tan horribles como éstas puedean suceder :) Asegurar que las nuevas características desarrolladas puedan ser comprobadas suficientemente por el mayor número de gente. No se garantiza que ningún snapshot pueda ser considerado calidad de producción. Para conseguir estabilidad y un sistema garantizado, tendrás que usar las versiones release. Las release snapshot están directamente disponibles en ftp://current.FreeBSD.org/pub/FreeBSD/ y son generadas un promedio de una vez por día para las ramas 4.0-CURRENT y 3.0-STABLE. ¿Qué significa FreeBSD-STABLE? Cuando la versión de FreeBSD 2.0.5 fue declarada release, decidimos dividir el desarrollo de FreeBSD en dos ramas. Una rama fue llamada -STABLE, otra -CURRENT. FreeBSD-STABLE está previsto para provedores de Internet y otras empresas para las que no resultan deseables cambios repentinos o experimentales. FreeBSD-CURRENT, por otra parte, ha sido la línea común desde la release 2.0, llegando hasta 5.2.1-RELEASE (y más allá). Se espera que 5-STABLE sea creado a la salida de 5.3-RELEASE y es entoncés cuando &os.current; pasará a ser 6-CURRENT. Aquí hay un pequeño gráfico ASCII para ayudar a entender este sistema de desarrollo: 2.0 | | | [2.1-STABLE] *BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-STABLE termina] | (Mar 1997) | | | [2.2-STABLE] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [termina] | (Mar 1997) (Oct 97) (Abr 98) (Jul 98) (Dic 98) | | 3.0-SNAPs (comenzado Q1 1997) | | 3.0-RELEASE (Oct 1998) | | [3.0-STABLE] *BRANCH* 3.1-RELEASE (Feb 1999) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1 | (May 1999) (Sep 1999) (Dic 1999) (Junio 2000) (Julio 2000) | | [4.0-STABLE] *BRANCH* 4.0 (Mar 2000) -> 4.1 -> 4.1.1 -> 4.2 -> 4.3 -> 4.4 -> ... later 4.X releases ... | | (Julio 2000) (Sep 2000) (Nov 2000) 5.0-RELEASE (Enero 2003) | | 5.1-RELEASE (Junio 2003) | | 5.2-RELEASE | | 5.2.1-RELEASE (Febrero 2004) \|/ + [5-CURRENT continua] La version 2.2-STABLE fue retirada con el release 2.2.8. La rama 3-STABLE fue terminada con la release 3.5.1, la última release de 3.X. Los únicos cambios que se le podrían hacer son arreglos en la seguridad. 4-STABLE es actualmente el branch -STABLE en desarrollo. El ultimo release en branch 4-STABLE es &rel2.current;-RELEASE, el cual fue hecho en &rel2.current.date;. La rama 5-CURRENT progresa lentamente hacia la creación de la rama 5-STABLE. Ver ¿Qué es FreeBSD-CURRENT? para mas información sobre esta rama. ¿Cuando se realizan las releases de FreeBSD? El &a.re; publica una nueva versión de FreeBSD cada 4 meses aproximadamente. Las fechas de las nuevas versiones se anuncian por adelantado, con la finalidad de que los desarrolladores trabajando en el sistema sepan cuando deben terminar sus proyectos para ser probados e integrados en el sistema. Hay un periodo de prueba para cada release, para asegurar que los nuevos cambios introducidos en el sistema no comprometan la estabilidad de la versión. Algunos usuarios califican esta precaución como una de las mejores características de FreeBSD, aunque esperar el alcance de -STABLE puede ser un poco frustrante. Mas información en el proceso de las releases (incluyendo fechas y releases futuras) puede ser encontrada en la página de release engineering. Para personas que quieran o necesiten más emoción, diariamente se crean snapshots binarios de la misma manera. ¿Quién es responsable de FreeBSD? Las decisiones clave concernientes al proyecto FreeBSD como la dirección a seguir y quién está autorizado a añadir código a la distribución original, se hace a través de un grupo de unas 17 personas llamado core team. Existe también un grupo de unas 150 personas o committers que también están autorizadas a realizar cambios directamente sobre la distribución original. De todas maneras, la cambios importantes son discutidos en las listas de distribución en las que no existen restricciones sobre quién participa en las discusiones. ¿Dónde puedo conseguir FreeBSD? Todas las versiones release de FreeBSD están disponibles via ftp anónimo en el servidor FTP de FreeBSD: Para la actual 3.X-STABLE release, 3.5.1-RELEASE mira en 3.5.1-RELEASE. La ultima 5.X release, &rel.current;-RELEASE puedes encontrarla en el directorio &rel.current;-RELEASE. Para la actual 4-STABLE release, &rel.current;-RELEASE, mira en directorio &rel2.current;-RELEASE. 4.X snapshots son construidos diariamente. 5.0 Snapshot releases son hechas una vez al día a partir de la rama -CURRENT, siendo éste un servicio puramente para desarrolladores. Más información acerca de como obtener FreeBSD en CD, DVD, y otros medios en el Handbook . ¿Cómo puedo instalar un mirror de FreeBSD? Puedes encontrar información acerca de como instalar un mirror de FreeBSD en el artículo Mirroring FreeBSD. ¿Dónde encuentro información sobre las listas de distribución de FreeBSD? Puedes encontrar toda la información en la sección de listas del Handbook. ¿Dónde encuentro información sobre el año 2000 (Y2K) en FreeBSD? Tienes toda la información disponible en la página Y2K de FreeBSD ¿Qué grupos de noticias están disponibles sobre FreeBSD? Puedes encontrar toda la información en la sección de news del Handbook. ¿Hay algun canal IRC (Internet Relay Chat) sobre FreeBSD? Sí, muchas de las grandes redes de IRC tienen canales de chat de FreeBSD. El canal #FreeBSD en EFNet es un fórum de FreeBSD, pero no acudas allí para obtener soporte técnico o contar tus penas sobre como leer las páginas man ;). Es un canal de chat, de principio a fín, y los temas que se tratan suelen ser cosas como sexo, deportes o armas nucleares. ¡Estás avisado!. Disponible en el servidor irc.chat.org. El canal #FreeBSD en DALNET está disponible en el servidor irc.dal.net en USA y irc.eu.dal.net en Europa. El canal #FreeBSD en UNDERNET está disponible en us.undernet.org en USA y eu.undernet.org en Europa. Igual que en EFNET, no hagas preguntas técnicas. Es un canal de chat, no de soporte. El canal #FreeBSD en HybNet. Este canal es un canal de ayuda. Puedes encontrar la lista de servidores en el website de HybNet. Cada uno de estos canales es diferente y no están conectados entre ellos. Sus estilos de chat difieren, por lo que podrís probarlos todos para ver cuál te gusta más. Libros sobre FreeBSD El libro de Greg Lehey's ``Installing and Running FreeBSD'' está disponible en Walnut Creek y se vende con el CDROM 2.2.5. Hay también un libro más completo titulado ``The Complete FreeBSD'', el cual tiene manuales adicionales e incluye el CDROM 2.2.6. Debería estar disponible en las mejores librerías. Hay un proyecto de documentación de FreeBSD con el que puedes contactar (o mejor, participar), en la lista de distribución doc: <doc@FreeBSD.org>. En esta lista se tratan todos los temas referentes a la documentación de FreeBSD. Para verdaderas preguntas sobre FreeBSD, existe la lista question: <questions@FreeBSD.org>. Está disponible un ``manual'' (handbook a patir de ahora) de FreeBSD, y se puede encontrar en: El Handbook de FreeBSD. Ten en cuenta que éste es un trabajo en constante desarrollo y actualización, por lo que algunas secciones podrían estar incompletas. Teniendo en cuenta que FreeBSD 2.2.x está basado en la versión Berkeley 4.4BSD-Lite2, la mayoría de manuales de 4.4BSD con aplicables a FreeBSD 2.2.x. O'Reilly y Asociados publican estos manuales: 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages ISBN: 1-56592-080-5 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages ISBN: 1-56592-075-9 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages ISBN: 1-56592-076-7 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages ISBN: 1-56592-078-3 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages ISBN: 1-56592-079-1 Una descripción de éstos puede ser encontrada vía WWW en: Descripción de libros sobre 4.4BSD Para profundizar más en la organizacion del kernel de 4.4BSD, no puedes ir mal con los siguientes: 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 Un buen libro en administración de sistemas es: Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 ISBN: 0-13-151051-7 NOTA Asegurate de conseguir la segunda edición, con cubierta roja y no la primera. Este libro cubre las necesidades básicas, así como TCP/IP, DNS, NFS,SLIP/PPP, sendmail, INN/NNTP, impresión, etc,. Es caro, (aproximadamente unos US$45-$55), pero vale la pena. También incluye un CD-ROM con los fuentes de varias herramientas, muchas de las cuales están incluidas, también, en la versión 2.2.6R (CDROM) de FreeBSD, incluso incluyendo versiones más modernas. ¿Cómo accedo a la base de datos de Problem Report? La base de datos de Problem Report puede ser consultada vía web a traves de la dirección query. También pueden ser enviados vía web a través de la dirección envio. El comando send-pr(1) también puede ser usado para el envío de reporte de problemas. ¿Dónde puedo obtener versiones ASCII/PostScript de la FAQ? La FAQ actualizada está disponible en el servidor Web de FreeBSD o en cualquiera de los mirrors en formato PostScript y texto (7 bits ASCII y 8 bits Latin-1). Formato PostScript (unos 370KB): http://www.FreeBSD.org/FAQ/FAQ.ps Formato ASCII (unos 220KB): http://www.FreeBSD.org/FAQ/FAQ.ascii Formato texto ISO 8859-1 (unos 220KB): http://www.FreeBSD.org/FAQ/FAQ.latin1 ¿Dónde puedo obtener versiones ASCII/PostScript del Handbook? El Hansbook actualizado está disponible en el servidor Web de FreeBSD o en cualquiera de los mirrors en formato PostScript y texto (7 bits ASCII y 8 bits Latin-1). Formato PostScript (unos 1.7MB): http://www.FreeBSD.org/handbook/handbook.ps Formato ASCII (unos 1080KB): http://www.FreeBSD.org/handbook/handbook.ascii Formato texto ISO 8859-1 (unos 1080KB): http://www.FreeBSD.org/handbook/handbook.latin1 El Handbook en ASCII no está en texto plano! Cierto, las versiones ASCII y Latin1 del Handbook no están estrictamente en formato de texto plano; contienen carácteres de control de impresión asumiendo que el documento será enviado a una impresora. Si necesitas tenerlos en un formato leible, pasa el archivo por el programa col: $ col -b < inputfile > outputfile Me gustaría ser Mirror del web de FreeBSD! Hay múltiples maneras de hacer mirror de las páginas web. Usando CVSUP: Puedes obtener todo el contenido del web usando el programa CVSUP desde el servidor cvsup.FreeBSD.org. Añade esta línea a tu archivo de configuración de cvsup: www release=current hostname=/home base=/usr/local/etc/cvsup prefix=/usr/local/www/data/www.FreeBSD.org delete old use-rel-suffix Usando rsync: Mira en la página de mirrors para más información. Usando mirror de FTP: Puedes bajarte la copia de los contenidos del web usando tu herramienta favorita de mirror de FTP. Simplemente empieza en ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/www. Me gustaría traducir la documentación. Bueno, no podemos pagar, pero quizás te enviemos un CD-ROM o una camiseta y añadiremos tu nombre en la sección ``Contributors'' del Handbook si nos envías una traducción de la documentación. Otras fuentes de información. Los siguientes grupos de news contienen temas relacionados con FreeBSD y sus usuarios: comp.unix.bsd.FreeBSD.announce (moderada) comp.unix.bsd.FreeBSD.misc comp.unix.bsd.misc Recursos Web: The FreeBSD Home Page. Si tienes un portátil asegurate de pasar por Tatsumi Hosokawa's Mobile Computing page. Información sobre SMP (Symmetric MultiProcessing), soporte de SMP. Información sobre aplicaciones multimedia. Si estás interesado específicamente en el chip Bt848 de vídeo captura, entonces sigue este link. El handbook de FreeBSD tiene una completa bibliografía en la sección bibliografía la cual recomendamos leer si estás interesado en comprar libros actuales relacionados con estos temas. Instalación ¿Qué archivo necesito para instalar FreeBSD? Generalmente sólo es necesario un disco de 1,44Mb con una imgen del archivo floppies/boot.flp. Arranca con este disco para comenzar con el programa de instalación, el cual se encargará de realizar todas las operaciones necesarias (gestión de TCP/IP, cintas, CDROMs, floppies, particiones DOS y cualquier cosa necesaria para realizar la instalación). Si necesitas bajarte las distribuciones (para una instalación desde una partición DOS por ejemplo), estas son las distribuciones mínimas que necesitarás: bin/ manpages/ compat*/ doc/ src/ssys.* Todas las instrucciones sobre este procedimiento y una ampliación de la documentación se puede encontrar en Instalación de FreeBSD. ¡Ayuda!, La imagen del disco de arranque no cabe en un floppy Un floppy de 1.44MB puede contener hasta 1474560 bytes de datos. La imagen de arranque es exactamente de 1474560 bytes. Los errores más comunes en la preparación de disco de arranque son: No bajarse la imagen en modo binario cuando se usa FTP. Algunos clientes FTP intentan bajar por defecto los archivos en modo ASCII e intentan cambiar los caracteres de final de línea recibidos por el que utilice el sistema cliente. Esto corromperá inevitablemente la imagen de arranque. Revisa el tamaño de la imagen: si no es exactamente el mismo tamaño del archivo existente en el servidor, la imagen no servirá. Solución: teclea binary en la línea de comandos del FTP después de conectar y antes de empezar a bajar la imágen. Usando el comando copy de DOS (o cualquier herramienta GUI equivalente) para transferir la imagen a un disquete. Programas como copy no funcionarán para la transferencia de la imagen a un disco. La imagen tiene el contenido completo del disco, pista por pista, y no está pensada para ser trasladada a un disquete como un archivo normal. Tienes que hacer una transferencia ``raw'' usando herramientas de bajo nivel como fdimage o rawrite, descritas en la guía de instalación de FreeBSD. ¿Dónde puedo encontrar las instrucciones de instalación de FreeBSD? Las instrucciones de instalación están en Instalación de FreeBSD. ¿Qué necesito para poder ejecutar FreeBSD? Necesitarás un PC con 386 o superior, 5 Mb o más de memoria RAM y al menos 60 Mb de espacio en disco duro. Puede funcionar con tarjetas gráficas de bajo nivel (Hercules), pero para poder ejecutar X11R6 es necesario una tarjeta VGA o superior. Sólo tengo 4Mb de RAM. ¿Puedo instalar FreeBSD? FreeBSD 2.1.7 fue la última version de FreeBSD que podía ser instalada en un sistema de 4Mb. Las nuevas versiones de FreeBSD, como la 2.2, necesitan al menos 5Mb para poder ser instaladas. Todas las versiones de FreeBSD, incluyendo la 3.0, funcionarán en sistemas con 4Mb de RAM, lo que no puedes ejecutar es la instalación en sistemas con 4Mb. Puedes añadir memoria extra para el proceso de instalación, y una vez instalado, volver a los 4Mb. Tambien puedes instalar tu disco en una máquina con más de 4Mb, realizar la instalación y reponer el disco en su máquina con 4Mb. Hay algunas situaciones en las que FreeBSD 2.1.7 no se instalará en sistemas con 4Mb. Para ser exactos: no se instalará con 640Kb de memoria base + 3Mb de memoria extendida. Si tu placa base puede remapear algo de la memoria ``perdida'' fuera de los 640Kb a la región de 1Mb, entonces aun podrás instalar FreeBSD 2.1.7. Intenta entrar en el setup de tu BIOS y busca la opción ``remap''. Actívala. Quizás tendrás que desactivar la opción de ROM shadowing. Es más fácil añadir en la máquina 4Mb de memoria para la instalación. Crea un kernel unicamente con las opciones que necesites y vuelve a quitar los 4Mb añadidos. También puedes instalar la versión 2.0.5 y a continuación actualizar tu sistema a la 2.1.7 con la opción ``upgrade'' del programa de instalación de la versión 2.1.7. Después de la instalación, si te creas un kernel personalizado, funcionará en 4Mb. Algunos fueron capaces de arrancar con 2Mb (aunque después el sistema era incapaz de hacer nada más :-)) ¿Cómo puedo hacer mi propio disco de instalación? Realmente, no hay una manera para sólo hacer un disco de instalación personalizado. Hay algún código en /usr/src/release/floppies/Makefile que supuestamente es para hacer sólo un disco de instalación personalizado, pero no está realmente testeado todavía. ¿Puedo tener más de un sistema operativo en mi PC? Echa un vistazo en La página multi-OS. ¿Puede Windows 95 coexistir con FreeBSD? Instala primero Windows 95 y después FreeBSD. El boot manager de FreeBSD se encargará de darte la opción de arrancar con cualquiera de los dos sistemas. Si lo haces al revés, Windows 95 borrará el boot manager sin hacer ninguna pregunta previa. Si ocurre esto, pasa a la siguiente sección. Windows 95 desinstaló mi boot manager! ¿Cómo lo recupero? Puedes reinstalar el boot manager que viene con FreeBSD de dos maneras: Ejecutando el DOS, entra en el directorio tools/ de tu distribución de FreeBSD y busca el archivo bootinst.exe. Ejecútalo de la siguiente manera: bootinst.exe boot.bin Y el boot manager estará reinstalado. Arranca con el disco de instalación de FreeBSD y entra en la sección ``Custom Installation''. Selecciona ``Partition''. Escoge el disco en el cual debe estar instalado el boot manager, y cuando entres en el editor de particiones, sin hacer ningún cambio, selecciona (W)rite. Serás preguntado para confirmar la acción, responde ``sí'', y cuando estés en la ventana de ``Boot manager selection'' asegúrate de seleccionar ``Boot Manager''. Esto reescribirá el boot manager en el disco. Ahora, sal del programa de instalación y rearranca el computador de la manera habitual. ¿Puedo instalar FreeBSD en un disco con sectores erróneos? La gestión de sectores erróneos por parte de FreeBSD no está desarrollada todavía al 100% y desgraciadamente debemos decirte que si tienes discos IDE o ESDI con gran cantidad de sectores erróneos, FreeBSD no es para tí. De todas maneras, te aconsejamos que antes de descartar la instalación, hagas un intento. Ocurren cosas extrañas cuando arranco con el disco de instalación Si observas cosas como que la maquina se ``cuelga'' o se reinicializa espontáneamente cuando intentas arrancar con el disco de instalación, aquí tienes tres preguntas que debes responder tu mismo: ¿Estás usando un disco nuevo, recién formateado y libre de errores, o estás usando el disco de publicidad que venía con la revista que lleva guardada varios meses debajo de la cama? ¿Descargaste por ftp la imagen del disco en modo binario?... (no te preocupes ya que hasta el mejor de nosotros, por lo menos una vez, ha descargado un archivo en modo ASCII). Si estás usando uno de esos nuevos sistemas operativos como Windows 95 o Windows NT, debes arrancar la máquina en modo DOS puro, ya que parece ser que los Windows no se llevan bien con los programas que escriben directamente sobre los dispositivos hardware, como hace el programa de creación de discos de instalación de FreeBSD. Han habido informaciones referentes a problemas al bajar el disco de instalación con Netscape, por lo que te recomendamos que uses un programa diferente como cliente de ftp. ¡Ayuda! ¡No puedo instalar desde una cinta! Si estás instalando la versión 2.1.7R desde una cinta, debes crear esa cinta con un tamaño de bloque de tar de 10 (5120 bytes). El tamaño por defecto de los bloques tar es de 20 (10240 bytes), y las cintas creadas con este tamaño por defecto no pueden ser usadas para instalar FreeBSD 2.1.7R; con estas cintas tendrás un error referente a un tamaño de registro demasiado grande. Conexión de dos máquinas FreeBSD vía puerto paralelo (PLIP) Coge un cable de laplink y asegurate que ambos computadores tienen un kernel que soporta el puerto paralelo. $ dmesg | grep lp lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface Conecta el cable en los dos puertos paralelos. Configura los parámetros de red para el interfaz lp0 (como root) en ambas máquinas. Por ejemplo, si quieres conectar la máquina max y moritz: max <-----> moritz Direccion IP 10.0.0.1 10.0.0.2 En el arranque de max # ifconfig lp0 10.0.0.1 10.0.0.2 En el arranque de moritz # ifconfig lp0 10.0.0.2 10.0.0.1 Esto es todo!!. Por favor, lee los man de lp(4) y lpt(4). También deberías añadir las máquinas en el archivo /etc/hosts: 127.0.0.1 localhost.my.domain localhost 10.0.0.1 max.my.domain max 10.0.0.2 moritz.my.domain moritz Para asegurarte que funciona haz: en max: $ ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire moritz max UH 4 127592 lp0 $ ping -c 4 moritz PING moritz (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 --- moritz 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 ¿Puedo instalar FreeBSD en mi portátil sobre PLIP (Parallel Line IP)? Conecta los dos computadores usando Laplink mediante el puerto paralelo y usa las siguientes características: +----------------------------------------+ |A-name A-End B-End Descr. Port/Bit | +----------------------------------------+ |DATA0 2 15 Data 0/0x01 | |-ERROR 15 2 1/0x08 | +----------------------------------------+ |DATA1 3 13 Data 0/0x02 | |+SLCT 13 3 1/0x10 | +----------------------------------------+ |DATA2 4 12 Data 0/0x04 | |+PE 12 4 1/0x20 | +----------------------------------------+ |DATA3 5 10 Strobe 0/0x08 | |-ACK 10 5 1/0x40 | +----------------------------------------+ |DATA4 6 11 Data 0/0x10 | |BUSY 11 6 1/0x80 | +----------------------------------------+ |GND 18-25 18-25 GND - | +----------------------------------------+ Mira también esta nota en la página de informática móvil. ¿Que geometría debo usar para mis discos? (Por geometría de un disco, entendemos el número de cilindros, cabezales y sectores por pista en el disco - de ahora en adelante nos referiremos por conveniencia a estos parámetros como C/H/S. Así es como trabaja el BIOS de los PC's para gestionar la lectura/escritura. Por alguna razón, esto parece crear mucha confusión. Ante todo, la geometría física de un disco SCSI es totalmente irrelevante ya que FreeBSD trabaja en términos de bloques de disco. Con discos IDE, FreeBSD trabaja en términos de C/H/S, pero todos los discos modernos convierten estos datos en referencias internas de bloques. Para discos SCSI, la geometría a usar depende de si tenemos activado en la controladora el soporte de translación (comunmente conocido como "soporte para discos mayores de 1GB" o algo similar). Si esta opción está desactivada, entonces usa N cilindros, 64 cabezales y 32 sectores por pista, donde N es la capacidad del disco en MB. Por ejemplo, para un disco de 2GB, los parámetros correctos serían 2048 cilindros, 64 cabezales y 32 sectores. Si el soporte de translación está activado y la capacidad del disco es mayor de 1GB, usa M cilindros, 63 cabezales (*no* 64), y 255 sectores, donde M es la capacidad del disco en MB dividida por 7.844238. Para nuestro ejemplo de un disco de 2GB, los parámetros serían 261 cilindros, 62 cabezales y 255 sectores. Si no estás seguro sobre los parámetros a usar, o FreeBSD falla al detectar la geometría correcta del disco durante la instalación, el método más simple para solucionar este problema es crear una pequeña partición DOS en el disco. Entonces, la geometría debería ser detectada correctamente (y siempre puedes borrar esa partición desde el ``editor de particiones'' si no quieres mantenerla). Alternativamente, existe una utilidad de libre distribución incluida en FreeBSD llamada pfdisk.exe (situada en el directorio tools del CD-ROM de distribución o en cualquiera de los servidores ftp) que nos dice la geometría del disco usada por el sistema operativo DOS. Lo único que tenemos que hacer es introducir los datos obtenidos en el editor de particiones de FreeBSD. ¿Existe alguna restricción en cómo dividir el disco? Sí. Debes asegurarte de que la partición raiz esta por debajo del cilindro 1024, para que el BIOS pueda arrancar el kernel desde ella. (Ésta es una limitación del BIOS de los PCs, no de FreeBSD). Para discos SCSI, esto implica que la partición raíz debe estar instalada en los primeros 1024MB (o en los primeros 4096MB si la translación extendida esta activada). Para discos IDE, la partición raíz debe estar en los primeros 504MB. ¿Qué hay sobre los ``disk managers''? FreeBSD reconoce el disk manager Ontrack. Otros disk managers no están soportados. Si quieres usar el disco solo con FreeBSD no necesitas el disk manager. Solo configura el disco para el espacio máximo que pueda manejar el BIOS (usualmente 504MB), y FreeBSD se encargará de averiguar cuánto espacio tienes realmente. Si estás usando un disco antiguo con controladora MFM, necesitarás decirle explícitamente a FreeBSD cuántos cilindros puede usar. Si quieres usar el disco con FreeBSD y otro sistema operativo, todavía puedes hacerlo sin necesitar un disk manager; sólo asegúrate de que la partición raíz de FreeBSD y la partición de arranque del otro sistema operativo están en los primeros 1024 cilindros. Si eres cuidadoso, una partición raiz de 20MB debería ser suficiente. Cuando arranco FreeBSD obtengo ``Missing Operating System'' Esto es un clásico conflicto entre FreeBSD y DOS u otro sistema operativo sobre sus ideas de geometría.. Tendrás que reinstalar FreeBSD, pero teniendo en cuenta la información que te damos más arriba sobre este asunto. No puedo pasar del prompt `F?'. Éste es otro problema descrito en el párrafo anterior. La geometría de tu BIOS y los datos de configuración de FreeBSD no coinciden. Si tu controladora o BIOS soporta la translación de cilindros (también conocido como "soporte para discos de más de 1GB"), intenta activar/desactivar esta opción y reinstala FreeBSD. Tengo >16MB de RAM. ¿Puede causar esto problemas? Aparte del rendimiento, no. FreeBSD 2.X tiene buffers que permiten al ``bus mastering controller'' acceder a más de 16MB. (Esto sólo es aplicable si estás usando dispositivos ISA). También mira la sección máquinas con >64M si tienes esta cantidad de memoria o si usas máquinas Compaq u otro BIOS que no da correctamente la cantidad de memoria disponible. ¿Necesito instalar todo el código fuente? En general, no. De todas maneras, te recomendamos que instales, por lo menos, el kit de código fuente base, el cual incluye muchos de los archivos aquí mencionados, y el kit sys, que incluye el código fuente del kernel. No hay nada en el sistema que requiera el código fuente para funcionar, a excepción del programa de configuración de kernel config. Con la excepción de las fuentes del kernel, nuestra estructura esta diseñada para que puedas montar una unidad en solo lectura via NFS en la que exista el código fuente, y aun así, ser capaz de compilar los nuevos binarios. (Debido a las restriciones de los fuentes del kernel, recomendamos que no montes estos en /usr/src directamente, sino en cualquier otra parte del disco con los links simbólicos apropiados para duplicar la estructura principal del árbol de directorios original), Teniendo los fuentes on-line y sabiendo como crear un sistema con ellas (compilar), te haremos mucho mas fácil la actualización a futuras versiones de FreeBSD. Para seleccionar auténticamente un subconjunto del código fuente, usa la opción Custom del menú desde el menú Distributions de la herramienta de instalación. El script src/install.sh instalará sólo partes de la distribución del código fuente dependiendo de los parámetros (argumentos) que se le pasen. ¿Necesito crear un nuevo kernel? La creación de un nuevo kernel era, originariamente, un paso requerido en la instalación de FreeBSD, pero en las versiones más recientes nos hemos beneficiado de la introducción de una herramienta de configuración de kernel mucho más amigable. Cuando en el prompt de arranque de FreeBSD (boot:), usamos el parámetro "-c", llegamos a una pantalla de configuración visual la cual permite configurar las opciones del kernel para la mayoría de tarjetas ISA. Todavía es recomendable la creación de un nuevo kernel conteniendo sólo los drivers que nos sean necesarios para ahorrar un poco de RAM, pero no es estrictamente necesario para la mayoría de sistemas. Vivo fuera de USA. ¿Puedo usar la encriptación DES? Si no es absolutamente necesario que uses la encriptación DES, puedes usar la encriptación por defecto de FreeBSD para una mejor seguridad, y sin restricciones de importación. La encriptación por defecto de los passwords en FreeBSD está basada en MD5, y es necesario un mayor uso intensivo de CPU con programas de descubrimiento de passwords que en DES. La única razón para no usar hoy en día la encriptación MD5 sería usar un sistema de passwords compartidos entre sistemas FreeBSD y no FreeBSD. Puesto que el algoritmo de encriptación DES no puede ser legalmente exportado fuera de USA, los usuarios externos a USA NO deberían descargar este software desde los servidores FTP situados en USA. Existe una alternativa para la biblioteca de encriptación, basada en el código escrito en Australia por David Burren. Este código está disponible en algunos mirrors de FreeBSD fuera de USA. El código fuente de la biblioteca de encriptación, y los binarios de los programas que la usan pueden encontrarse en los siguientes servidores FTP: South Africa ftp://ftp.internat.FreeBSD.org/pub/FreeBSD ftp://storm.sea.uct.ac.za/pub/FreeBSD Brazil ftp://ftp.iqm.unicamp.br/pub/FreeBSD Finland ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Los usuarios de fuera de USA no deben descargar ningún software de encriptación de servidores situados en USA, ya que de no seguir esta norma los responsables de esos servidores podrían verse envueltos en importantes problemas legales. Se está desarrollando una distribución no estadounidense de Kerberos, cuyas versiones actuales pueden obtenerse vía ftp anónimo en braae.ru.ac.za. Existe también una lista de distribución para la discusión de software de encriptación externo a USA. Para más información envía un e-mail con una simple línea diciendo "help en el cuerpo del mensaje a: majordomo@braae.ru.ac.za. El ``boot disc'' arranca pero se cuelga en la pantalla ``Probing Devices...'' Si tienes instalado un ZIP o un Jaz IDE, desconéctalo e inténtalo de nuevo. El disco de arranque puede haberse confundido con los discos. Una vez el sistema esté instalado, puedes volver a conectar los dispositivos. Esperamos que esto sea arreglado en las próximas releases. Aparece el siguiente error ``panic: can't mount root'' al reiniciar el computador después de la instalación Este error proviene de la confusión entre los bloques de arranque y lo que ve el kernel en los discos. El error se suele manifestar en sistemas con dos discos IDE, con los discos duros dispuestos como máster o ''single'' en controladoras diferentes, estando FreeBSD instalado en la controladora IDE secundaria. Los bloques de arranque piensan que el sistema está instalado en wd1 (el segundo disco en el BIOS) mientras el kernel asigna el primer disco de la controladora secundaria wd2. Después de la detección de dispositivos, el kernel intenta montar lo que los bloques de arranque piensan que es el disco de arranque, wd1, cuando realmente es el wd2, y falla. Para solucionar el problema, haz una de las siguientes cosas: En el prompt de arranque (boot:), pon 1:wd(2,a)kernel y presiona Enter. Si el sistema arranca, ejecuta el comando: echo "1:wd(2,a)kernel" > /boot.config para actualizar la cadena de arranque por defecto. Mueve el disco de FreeBSD a la controladora IDE primaria para que los discos sean consecutivos. Crea un nuevo kernel, modifica las líneas de configuración de wd de la siguiente manera: controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # comment out this line controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd1 at wdc1 drive 0 # change from wd2 to wd1 disk wd2 at wdc1 drive 1 # change from wd3 to wd2 Instala el nuevo kernel: Si moviste los discos y quieres recuperar la configuración previa, reemplaza los discos en la configuración deseada y rearranca el sistema. Tu sistema debería arrancar sin problemas. ¿Cuál es el límite de memoria?. Para memoria, el límite (teórico) es de 4 gigabytes. Un gigabyte ha sido comprobado y funciona sin problemas: generalmente no se pueden comprar equipos i386 que soporten más cantidad de memoria. ¿Cuál es el límite del sistema de archivos FFS? Para sistemas de archivos FFS, el máximo teórico está en 8 terabytes (bloques de 2G), o 16TB para el tamaño de bloque por defecto de 8K. En la práctica hay un límite ``blando'' de 1 terabyte, pero con pequeáas modificaciones son posibles (y existen) sistemas de archivos de 4 terabytes. El tamaño máximo de un único archivo FFS es aproximadamente de 1 Gbloque (4TB) si el tamaño del bloque es de 4K. maxfilesize ---------------------------------- 2.2.7 3.0 fs block size -stable -current works should-work ------------- ------- -------- ----- ----------- 4K 4T-1 4T-1 4T-1 4+T 8K 32+G 8T-1 32+G 16T-1 16K 128+G 16T-1 128+G 32T-1 32K 512+G 32T-1 512+G 64T-1 64K 2048+G 64T-1 2048+G 128T-1 Cuando el tamaño del bloque del sistema de archivos es de 4K, los bloques triple-indirectos funcionan y el límite total debería venir determinado por el número máximo de bloques que puede ser representado usando los bloques triple-indirectos (aproximadamente 1K^3 + 1K^2 + 1K), pero el límite total lo establece un límite (incorrecto) de 1G-1 en el número de bloques. El límite en el número de bloques debería ser de 2G-1, pero estos números de bloque son inalcanzables cuando los bloques del sistema de archivos son de 4K. ¿Cómo puedo poner archivos de 1TB en un disquete? El tamaño máximo de un archivo no depende directamente del tamaño máximo del disco. El tamaño máximo del disco es de 1TB. Es una ventaja que el tamaño del archivo pueda ser mayor que el tamaño del disco. El siguiente ejemplo crea un archivo con un tamaño de 1TB usando 32K de espacio de disco (3 bloques indirectos y 1 bloque de datos) en una pequeña partición raíz. ttyv0:bde@alphplex:/tmp/q> cat foo df . dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1 ls -l z du z df . ttyv0:bde@alphplex:/tmp/q> sh foo Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 64479 27702 31619 47% / 1+0 records in 1+0 records out 1 bytes transferred in 0.000187 secs (5346 bytes/sec) -rw-r--r-- 1 bde bin 8796093022207 Sep 7 16:04 z 32 z Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 64479 27734 31587 47% / ttyv0:bde@alphplex:/tmp/q> exit Bruce Evans, septiembre de 1998 He compilado un nuevo kernel y al arrancar aparece el error "archsw.readin.failed". Puedes arrancar especificando el kernel directamente en la segunda fase del boot, pulsando cualquier tecla cuando veas el símbolo | justo antes de que se arranque el cargador (loader). Más específicamente, has actualizado los fuentes para tu kernel, y lo has creado y actualizado a partir de ellos sín hacer un ``make world''. Así no funciona. Haz un ``make world''. Compatibilidad hardware ¿Qué tipo de discos duros soporta FreeBSD? FreeBSD soporta discos duros EIDE y SCSI (con controladoras compatibles; mira en la siguiente sección), y todos los discos que usen el interface original ``Western Digital'' (MFM, RLL, ESDI y por supuesto IDE). Algunas controladoras ESDI que usan interfaces propietarios quizá no funcionen correctamente. ¿Qué controladoras SCSI están soportadas? FreeBSD soporta las siguientes controladoras SCSI: Adaptec AH-1505 <ISA> AH-152x Series <ISA> AH-154x Series <ISA> AH-174x Series <EISA> Sound Blaster SCSI (AH-152x compat) <ISA> AH-2742/2842 Series <ISA/EISA> AH-2820/2822/2825 Series (Narrow/Twin/Wide) <VLB> AH-294x and aic7870 MB controllers (Narrow/Twin/Wide) <PCI> AH-394x (Narrow/Twin/Wide) Buslogic BT-445 Series <VLB> BT-545 Series <ISA> BT-742 Series <EISA> BT-747 Series <EISA> BT-946 Series <PCI> BT-956 Series <PCI> Future Domain TMC-950 Series <ISA> PCI Generic NCR 53C81x based controllers <PCI> NCR 53C82x based controllers <PCI> NCR 53C860/75 based controllers <PCI> ProAudioSpectrum Zilog 5380 based controllers <ISA> Trantor 130 based controllers <ISA> DTC DTC 3290 EISA SCSI in AHA-154x emulation. Seagate ST-01/02 Series <ISA> UltraStor UH-14f Series <ISA> UH-24f Series <EISA> UH-34f Series <VLB> Western Digital WD7000 <ISA> <No scatter/gather> ¿Qué lectores CD-ROM soporta FreeBSD? Está soportado cualquier disco SCSI conectado a una controladora soportada Los siguientes interfaces de CD-ROM propietarios también están soportados: Mitsumi LU002 (8bit), LU005 (16bit) and FX001D (16bit 2x Speed). Sony CDU 31/33A Sound Blaster Non-SCSI CD-ROM Matsushita/Panasonic CD-ROM ATAPI compatible IDE CD-ROMs Todas las tarjetas no SCSI son conocidas por ser extremadamente lentas comparadas con los discos SCSI, y algunos CDROM ATAPI quizá no funcionen correctamente. A partir de la versión 2.2 de FreeBSD en CDROM de Walnut Creek se soporta el arranque directo (boot) desde el propio CD. ¿Soporta FreeBSD discos ZIP? FreeBSD soporta los ZIP SCSI externos. Las unidades ZIP sólo pueden funcionar en los ID's SCSI 5 y 6, pero si el BIOS de tu controladora lo soporta, puedes arrancar desde él. No sabemos qué controladoras dejan arrancar desde ID's diferentes de la 0 o 1... mira en tu documentación y házmelo saber si te funciona. Los discos Zip ATAPI (IDE) están soportados en FreeBSD 2.2.6 y releases posteriores. FreeBSD ha incluido el soporte de discos ZIP por puerto paralelo desde la versión 3.0. Si estás usando una versión actualizada, debes asegurarte de que tu configuración del kernel incluye los drivers scbus0, da0, ppbus0 y vp0 (el kernel GENERIC los contiene todos excepto vp0). Con todos estos drivers presentes, el disco por puerto paralelo debería estar disponible como /dev/da0s4. Los discos se pueden montar usando mount /dev/da0s4 /mnt o (para discos dos) mount_msdos /dev/da0s4 /mnt. También mira en discos removibles, y esta nota en 'formatting'. ¿Soporta FreeBSD JAZ, EZ y otros discos removibles? Aparte de la versión IDE de EZ, todos estos son dispositivos SCSI, por lo que deberían funcionar sin problemas ya que FreeBSD los toma como discos SCSI y el IDE EZ también debería funcionar sin problemas ya que se toma como un disco IDE estándar. No estoy seguro de cómo soporta FreeBSD el cambio de soporte mientras está funcionando. Deberás, desde luego, desmontar la unidad antes de poder cambiar el soporte, y estar seguro de que todas las unidades externas están encendidas antes de arrancar el computador con FreeBSD para que éste pueda reconocerlas. Mira esta nota en 'formatting'. ¿Qué tarjetas serie multipuerto están soportadas por FreeBSD? Hay una lista de ellas en la sección dispositivos varios del manual (handbook). Algunas tarjetas ``sin nombre'' también han funcionado, especialmente las que dicen ser compatibles AST. Mira la página sio para obtener más información sobre la configuración de estas tarjetas. Tengo un tipo de ratón no habitual. ¿Cómo lo configuro? FreeBSD soporta el ``bus mouse'' y el ``InPort bus mouse'' de fabricantes como Microsoft, Logitech y ATI. El driver de mouse estiá compilado en el kernel GENERIC (kernel por defecto que carga el sistema). Si estás haciéndote un kernel a medida que incluya el driver de ratón, asegúrate de añadir la siguiente línea en el archivo de configuración del kernel: device mse0 at isa? port 0x23c tty irq5 vector mseintr ¿Cómo uso mi ratón PS/2 (``mouse port'' o ``teclado'')? Si estás usando una versión reciente de FreeBSD, el driver necesario, psm, está incluido y activado en el kernel. El propio kernel debería detectar tu ratón PS/2 en el momento de arrancar. Si estás usando una versión antigua, sólo tienes que activarlo en la configuración del kernel en el momento de la instalación del sistema. Si éste ya está instalado, escribe -c en el prompt boot: y actívalo. Por defecto, este driver está desactivado. Si estás usando alguna de las versiones más antiguas, tendras que añadir la siguiente línea en el archivo de configuración del kernel y compilar uno nuevo: device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr Mira la sección configuración del kernel si no tienes experiencia en la creación de nuevos kernel. Una vez que el kernel detecta correctamente el dispositivo psm0 al arrancar, asegúrate de que existe una entrada en /dev para este dispositivo. Puedes hacerlo tecleando: cd /dev; sh MAKEDEV psm0 ¿Es posible hacer uso del ratón fuera de X Windows? Si estás usando el driver por defecto de la consola, syscons, puedes usar el ratón en las consolas de texto para realizar ``cut & paste''. Ejecuta el demonio (daemon) de ratón moused y arranca el ratón en la consola virtual: moused -p /dev/xxxx -t yyyy vidcontrol -m on donde xxxx es el nombre del dispositivo del ratón e yyyy es un tipo de protocolo para el ratón. Mira en moused para saber los tipos de protocolo soportados. Si quieres ejecutar el demonio moused automáticamente al arrancar el sistema, activa las siguientes variables en /etc/sysconfig (para versión 2.2.1). mousedtype="yyyy" mousedport="xxxx" mousedflags="" En versiones 2.2.2 o superiores, activa las siguientes variables en /etc/rc.conf. moused_type="yyyy" moused_port="xxxx" moused_flags="" A partir de la versión 2.2.6, el demonio del ratón es capaz de determinar automáticamente el protocolo correcto a utilizar. Sólo tienes que especificar auto como el protocolo a usar. Cuando el demonio de ratón está funcionando, el acceso al ratón necesita coordinarse con otros programas como X Window. Mira en esta sección para más información. ¿Cómo hago un cut & paste con el ratón en una consola de texto? Una vez que tengas el demonio del ratón funcionando (mira la sección anterior, pulsa el botón 1 (izquierdo) y mueve el ratón para seleccionar la región de texto. A continuación, pulsa el botón 2 (medio) o 3 (derecho) para hacer un paste (pegar) de la región seleccionada en el lugar en el que tengamos situado el cursor. En versiones 2.2.6 o superiores, pulsando el botón 2 hara un paste del texto seleccionado. Pulsando el botón 3 extenderemos la región seleccionada de texto. Si tu ratón no tiene el botón medio, puedes emularlo o ``remapear'' (reconfigurar) los botones de tu ratón con las opciones del demonio moused. Mira en moused para más información. Mi ratón tiene una rueda de desplazamiento y botones. ¿Puedo usarlo? La respuesta es, desafortunadamente, ``depende''. Estos ratones con características adicionales requieren en muchos casos drivers propios y especializados. A no ser que el driver de dispositivo o el programa de usuario tenga soporte específico, el ratón se comportará como un ratón normal y corriente. ¿Cómo uso el mouse/trackball/touchpad en mi portátil? Por favor, mira en la respuesta anterior. Mira también esta nota en la sección de computadores portátiles. ¿Qué tipo de dispositivos de cinta están soportados? FreeBSD soporta unidades SCSI, QIC-36 (con interfaz QIC-02) y QIC-40/80 (interfaz floppy). Esto inclye dispositivos de 8mm (conocidos como Exabyte) y dispositivos DAT. Los QIC-40/80 son conocidos por su lentitud. Algunos de los dispositivos de 8mm primitivos no son totalmente compatibles con SCSI2 por lo que puede que no funcionen correctamente en FreeBSD. ¿Soporta FreeBSD ``tape changers''? FreeBSD 2.2 soporta SCSI changers usando el dispositivo ch y el comando chio. Los detalles acerca de cómo controlar realmente el changer se encuentran en chio. ¿Qué tarjetas de sonido están soportadas por FreeBSD? FreeBSD soporta las tarjetas SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib y Gravis Ultrasound. Hay también soporte limitado para la tarjeta MPU-401 y compatibles midi. Las tarjetas SoundBlaster 16 ASP todavía no son soportadas. El Microsoft Sound System sí está soportado. NOTA: ¡Esto es solo para sonido! Este driver no soporta CD-ROMs, SCSI o joysticks en estas tarjetas, a excepción de la SoundBlaster. El interface SCSI de SoundBlaster y algunos CD-ROMs no SCSI están soportados, pero no podrás arrancar el sistema desde ellos. No obtengo sonido de la tarjeta es1370 con driver pcm Puedes ejecutar el siguiente mandato cada vez que arranques el sistema: mixer pcm 100 vol 100 cd 100 ¿Qué tarjetas de red soporta FreeBSD? Mira la sección de tarjetas Ethernet en el manual para una lista más completa. de driver DEC DC21x40 and compatible PCI controllers (including 21140 100bT cards) ed driver NE2000 and 1000 WD/SMC 8003, 8013 and Elite Ultra (8216) 3Com 3c503 HP 27247B and 27252A And clones of the above le driver DEC EtherWORKS II and EtherWORKS III controllers ie driver AT&T EN100/StarLAN 10 3COM 3c507 Etherlink 16/TP NI5210 Intel EtherExpress is driver Isolan AT 4141-0 Isolink 4110 el driver 3com 3c501 (does not support Multicast or DMA) eg driver 3com 3c505 Etherlink/+ ze driver IBM PCMCIA credit card adapter lnc drive Lance/PCnet cards (Isolan, Novell NE2100, NE32-VL)(*) ep driver 3com 3c509 (Must disable PNP support on card) cx driver Cronyx/Sigma multiport Sync/Async (Cisco and PPP framing) zp driver 3Com PCMCIA Etherlink III (aka 3c589)(A-C only) fea driver DEC DEFEA EISA FDDI controller fpa driver DEC DEFPA PCI FDDI controller fe driver Fujitsu MB86960A/MB86965A Ethernet cards NOTA Los drivers marcados con (*) pueden tener problemas. NOTA: 3C598D NO está soportada todavía. NOTA: FreeBSD también soporta TCP/IP sobre líneas paralelo. En estos momentos, no somos compatibles con otras versiones, pero esperamos corregirlo en un futuro cercano. Encontrarás más información sobre este tema en la página man de lp(4). NOTA: Algunas de estas tarjetas requieren una partición DOS en el disco duro para ejecutar el programa de configuración. No tengo coprocesador matemático - ¿es malo? NOTA: Esto sólo afectará a los computadores 386/486SX/486SLC. El resto de los microprocesadores tienen un coprocesador integrado. En general, esto no causará problemas, pero hay circunstancias en las que pudieras echarlo de menos, especialmente si trabajas en entorno X Window. Si puedes, te recomendamos que compres uno y lo instales en tu computador. ¿Qué otros dispositivos soporta FreeBSD 2.X? Aquí hay una lista de drivers que no se han podido catalogar en las categorías anteriores. b004.c Driver for B004 compatible Transputer boards ``ctx'' driver Driver for CORTEX-I Frame grabber ``gp'' driver Driver for National Instruments AT-GPIB and AT-GPIB/TNT boards ``pca'' driver Driver for PC speakers to allow the playing of audio files ``spigot'' driver Driver for the Creative Labs Video Spigot gsc driver Driver for the Genuis GS-4500 Hand scanner joy driver Driver for a joystick labpc driver Driver for National Instrument's Lab-PC and Lab-PC+ ``uart'' driver Stand-alone 6850 UART for MIDI psm driver PS/2 mouse port tw.c Driver for the X-10 POWERHOUSE ¿Soporta FreeBSD la administración de energía en mi portátil? FreeBSD soporta APM en algunas máquinas. Por favor, mira en el archivo de configuración del kernel LINT y busca la parabra APM Los sistemas Micron se bloquean al arrancar Algunas placas base Micron tienen una implementación de PCI en el BIOS que no es estándar, lo que provoca que FreeBSD no pueda encontrar los dispositivos PCI en las direcciones en las que deberían estar. Desactiva la opción ``Plug and Play Operating System'' en el BIOS para solucionar el problema. Puedes encontrar más información en: http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron Tengo una de las controladoras Adaptec más modernas y FreeBSD no puede encontrarla Las nuevas controladoras Adaptec con chipset de la serie AIC789x están soportados bajo la nueva CAM SCSI que hace su debut en la version 3.0 de FreeBSD. Los parches para las versiones 3.0-CURRENT y 2.2-STABLE están en: ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/. Un disco de arranque con soporte CAM está disponible en: http://www.FreeBSD.org/~abial/cam-boot/. En ambos casos lee el archivo README antes de empezar. Tengo un módem interno Plug & Play y FreeBSD no lo encuentra Necesitarás añadir el ID del modem PnP a la lista de ID PnP en el driver serie. Para activar el soporte PnP, compila un nuevo kernel con controller pnp0 en el archivo de configuración y rearranca el sistema. El kernel mostrará en pantalla los IDs de todos los dispositivos PnP que encuentre. Copia el ID del módem en la tabla del archivo /sys/i386/isa/sio.c, sobre la línea 2777. Busca la cadena "SUP1310" en la estructura "siopnp_ids[]" para encontrar la tabla. Genera un nuevo kernel, instálalo y rearranca. Tu módem debería ser encontrado. Quizá tengas que configurar manualmente los dispositivos PnP usando el comando ``pnp'' en la configuración de arranque usandolo de la siguiente manera: pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 ¿Cómo obtengo el prompt ``boot:'' en una consola serie? Crea un nuevo kernel con options COMCONSOLE. Crea el archivo /boot.config y pon como único texto en el archivo. Desconecta el teclado del computador. Mira el archivo /usr/src/sys/i386/boot/biosboot/README.serial para más información. ¿Por qué no funciona mi tarjeta de red PCI 3Com con mi computador Micron? Algunas placas base Micron tienen una implementación de PCI en el BIOS que no es estándar, lo que provoca que FreeBSD no pueda encontrar los dispositivos PCI en las direcciones en las que debieran estar. Para solucionar el problema, desactiva la opción ``Plug and Play Operating System'' en el BIOS. Puedes encontrar más información sobre este problema en http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron ¿Soporta FreeBSD el multiprocesamiento simétrico (SMP)? SMP sólo está soportado a partir de la versión 3.0-STABLE Problemas Tengo bloques erróneos en mi disco duro! Los discos SCSI deberían ser capaces de marcar estos bloques erróneos automaticamente para que no presenten problemas. Algunos discos, por alguna razón desconocida, se venden con esta característica desactivada. Para activar esta opción, tendrás que editar una de las opciones del dispositivo, lo que puede ser hecho con FreeBSD tecleando el siguiente comando (como root): scsi -f /dev/rsd0c -m 1 -e -P 3 y cambiando los valores de AWRE y ARRE de 0 a 1:- AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 Para otros tipos de discos, dependes de las características de los sistemas operativos. Desafortunadamente, el comando "bad144" que se incluye en FreeBSD, necesita ser desarrollado más en profundidad. Se supone que los discos IDE incluyen de serie la posibilidad de "remapear" los bloques dañados; si tienes documentación de tu disco, podrás ver si esta opción está activada o desactivada. FreeBSD no reconoce mi Bustek 742a EISA SCSI! Esta información es específica para la tarjeta 742a, pero puede ser aplicable a otras tarjetas Buslogic. (Bustek = Buslogic) Existen dos versiones de la tarjeta 742a. Son revisiones de hardware A-G y H. La letra de revisión está situada después del número de ensamblaje. La 742a tiene 2 ROMs, una es el BIOS y la otra es el Firmware. FreeBSD no se fija en la versión de BIOS de la tarjeta, pero si en la de Firmware. Buslogic te enviará una actualización de de las ROMs si te pones en contacto con su departamento técnico. La BIOS y el Firmware son distribuidas de manera inseparable. Deberías tener la versión de Firmware más actualizada para la revisión de hardware de tu tarjeta. Las tarjetas con revisión A-G solo pueden aceptar BIOS/Firmware 2.41/2.21. La revisión H y superiores pueden aceptar las versiones más actuales 4.70/3.37. La diferencia entre las versiones de Firmware es que la 3.38 soporta "round robin". Las tarjetas Buslogic tienen un número de serie serigrafiado en ellas. Si tienes una revisión de hardware antigua, puedes llamar al departamento de RMA de Buslogic y darles el número de serie de la tarjeta para intentar cambiarla por una revisión superior del hardware. FreeBSD 2.1 solo soporta revisiones de Firmware 2.21 o superiores. Si tienes una versión inferior, tu tarjeta no será reconocida como Buslogic. Quizás sea reconocida como una Adaptec 1540. Las primeras versiones de Firmware de Buslogic contienen una modo de emulación de la AHA1540. Si tienes una revisión de hardware antigua y consigues una más actual (2.21), necesitarás chequear la posición del jumper W1 y asegurarte que está en la posición B-C (por defecto esta en B-C). Mi controladora SCSI HP Netserver's no es detectada! Este es un problema ya conocido. Las controladoras SCSI EISA integradas en la placa base en las máquinas HP Netserver, ocupan el slot numero 11. El espacio de direcciones para los slots EISA >=10 colisionan con los espacios de direcciones asignados para los dispositivos PCI, y la autoconfiguración de FreeBSD no maneja esta situación demasiado bien. Lo mejor que puedes hacer es pretender que no existan clases de rangos de direcciones :), cambiando el valor de la opción del kernel EISA_SLOTS a un valor de 12. Configura y compila un nuevo kernel como se describe en la entrada correspondiente del manual. Por supuesto, esto presenta un pequeño problema. Para poder solucionarlo, es necesario un truco en la utilidad de configuración. No uses el interface "visual", simplemente teclea lo siguiente en la línea de comando de la utilidad eisa 12 quit Esperamos que en las próximas versiones tengamos solucionados estos temas. ¿Qué ocurre con la controladora IDE CMD640? No funciona. No puede manejar comandos en los dos canales simultáneamente. Hay una solución posible y se activa automáticamente si tu sistema usa este chip. Para más detalles, referirse al man del driver de discos (man 4 wd). Si todavía estás usando FreeBSD 2.2.1 o 2.2.2 con una controladora IDE CMD640 y quieres usar el segundo canal, crea un nuevo kernel con options "CMD640" activada. Esta es la opción por defecto en la versión 2.2.5 y superiores. Tengo mensajes como ``ed1: timeout''. Esto, normalmente es causado por conflictos de interrupciones (por ejemplo, dos tarjetas usando la misma IRQ). Las versiones anteriores a la 2.0.5R eran tolerantes con los problemas de conflictos de IRQ. A partir de esa versión, los conflictos de IRQ ya no son tolerados. Arranca con la opción -c y cambia la entrada correspondiente a tu tarjeta. Si estás usando conectores BCN en tu tarjeta de red, el mensaje de error puede ser debido a una mala terminación de la red. Para chequear esto, conecta un terminador directamente a la salida BNC de la tarjeta (sin cable) y mira si el mensaje desaparece. Cuando monto el CDROM, obtengo ``Incorrect super block''. Tienes que indicar el tipo de dispositivo que quieres montar. Por defecto mount asumirá que el dispositivo que quieres montar es ``ufs''. Si quieres montar un CDROM, tienes que especificar . Esto hace que el sistema asuma que tiene que montar un sistema de archivos con formato ISO 9660 que es lo que los CDROM deben tener. Como ejemplo, si quieres montar una unidad CDROM, /dev/cd0c, bajo /mnt, tienes que ejecutar mount -t cd9660 /dev/cd0c /mnt Ten en cuenta que el nombre de tu dispositivo (/dev/cd0c en este ejemplo) puede ser diferente dependiendo del interface que estés usando. El comando anterior puede ser acortado tecleando: mount_cd9660 /dev/cd0c /mnt Cuando monto un CDROM, obtengo ``Device not configured''. Esto, generalmente, significa que no hay ningún disco en el lector de CDROM. También puede significar que el lector no es visible para el bus. Chequea que está bién configurado en lo referente a master/slave si es IDE (ATAPI). Algunas veces un CDROM SCSI puede "desaparecer" por que no ha tenido tiempo suficiente para responder a un reset del bus. Si tienes un CDROM SCSI, añade la siguiente línea en el archivo de configuración del kernel y recompílalo. options "SCSI_DELAY=15" Mi impresora es ridiculamente lenta. ¿Qué puedo hacer? Si es paralelo, y el único problema es la lentitud, intenta configurar el puero de impresora en modo "polled": lptcontrol -p Algunas impresoras nuevas de HP son conocidas por no trabajar correctamente en modo de interrupción, aparentemente debido (y todavía no exactamente entendido), a un problema de "timing". Mis programas ocasionalmente mueren con errores ``Signal 11''. Esto puede ser por hardware erróneo (memoria, placa base, etc). Intenta ejecutar algún programa de test de memoria. Ten en cuenta que es posible que tu memoria pase el test del programa que uses, pero que falle en algunas condiciones de uso, como en compilación de kernel. La FAQ SIG11 (listada más abajo) apunta a problemas de lentitud de memoria. Incrementa el número de "wait states" en tu BIOS o instala una memoria más rápida. También puedes intentar desactivar el caché de placa base en el BIOS y comprueba si se resuelve el problema. Hay una extensa FAQ en the SIG11 problem FAQ Cuando arranco, la pantalla queda negra! Este es un problema conocido con las tarjetas de vídeo ATI Mach 64. El problema es que esta tarjeta usa la dirección 2e8, también usada por el puerto serie 4. Debido a un bug (feature?) en el driver sio.c , éste "tocará" este puerto aunque no esté instalado o esté desactivado. Hasta que el problema sea fijado, puedes hacer esto: Teclea en el prompt de arranque. Esto te llevará a la sección de configuración del kernel. Desactiva sio0, sio1, sio2 y sio3 (todos ellos). De esta manera, el driver sio no se activa. Teclea exit para seguir arrancando. Si quieres ser capaz de usar tus puertos serie, tendrás que compilar un nuevo kernel con la siguiente modificación: /usr/src/sys/i386/isa/sio.c. Busca la cadena 0x2e8 y borra esta cadena y la coma anterior (mantén la coma siguiente). Ahora, compila un nuevo kernel de la manera habitual. Después de realizar estos cambios, puedes encontrarte aun que las X Window no funcionan correctamente. Algunas tarjetas de vídeo modernas ATI Mach 64 (especialmente la ATI Mach Xpression) no funcionan con la versión actual de XFree86; la pantalla se queda negra cuando arrancas las X o ocurren cosas extrañas en su funcionamiento. Puedes instalar una versión beta del nuevo servidor X que trabaja mejor, situada en el servidor XFree86 y seguir los links hasta el download. Coge los siguientes archivos: AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz Reemplaza los viejos archivos por las nuevas versiones y asegúrate de ejecutar de nuevo xf86config. Tengo 128MB de RAM pero el sistema solo usa 64MB. Debido a la forma que tiene FreeBSD de "ver" el tamaño de memoria en el BIOS, solo puede detectar 16 bits (65535 Kbytes = 64MB) (o menos... algunas BIOS fijan el tamaño de la memoria a 16MB). Para solucionar este problema, tienes que usar la opción del kernel indicada más adelante. Hay una manera de ver la información completa sobre memoria en el BIOS, pero no tenemos espacio en los bloques de arranque (bootblocks) para hacerlo. Por ahora, tenemos que trabajar con la opción del kernel. options "MAXMEM=<n>" Donde n es tu memoria en Kilobytes. Para 128MB, tendrías que usar 131072. FreeBSD 2.0 aborta con ``kmem_map too small!'' Nota El mensaje debería ser ``mb_map too small!'' La parada indica que el sistema no tiene memoria virtual suficiente para los buffers de red (específicamente, clusters mbuf). Puedes incrementar la cantidad de memoria virtual disponible para los clusters mbuf añadiendo: options "NMBCLUSTERS=<n>" al archivo de configuración del kernel, donde <n> es un número en el rango 512-4096, dependiendo del número de conexiones tcp simultáneas que necesites soportar. Te recomendamos intentar con 2048. Puedes monitorizar el número de clusters mbuf en uso con la orden netstat -m. ``CMAP busy panic'' al arrancar con un nuevo kernel. El programa que intenta detectar archivos /var/db/kvm_*.db puede fallar y provocar el "panic" en el arranque. Si esto ocurre, arranca en mono-usuario y haz: rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 Esto significa un conflicto con una controladora Ultrastor SCSI. Durante el proceso de arranque, entra en el menú de configuración del kernel y desactiva el dispositivo uha0. Sendmail dice ``mail loops back to myself'' Esto está contestado en la FAQ de sendmail de la siguiente manera: * Tengo el error "Local configuration error" : 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error Cómo puedo solventar el problema? Has intentado enviar un mail al dominio domain.net y que sea reenviado a un host específico (en este caso relay.domain.net) usando un registro MX, pero la máquina que tiene que aceptar ese mail, no reconoce el domimio como propio. Añade domain.net al archivo /etc/sendmail.cw (si estás usando FEATURE(use_cw_file) o añade "Cw domain.net" al archivo sendmail.cf La versión actual de la FAQ de sendmail puede ser encontrada en comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, y news.answers. Tambien puedes recibir una copia enviando un mail a mail-server@rtfm.mit.edu con el comando "send usenet/news.answers/mail/sendmail-faq" en el cuerpo del mensaje. No funcionan correctamente las aplicaciones a pantalla completa en máquinas remotas Quizás la máquina remota tiene el tipo de terminal diferente de cons25 que es el usado por la consola de FreeBSD. Hay diferentes maneras de solucionar este problema: Después de hacer el login en la máquina remota, configura la variable SHELL como ANSI o sco. Usa el emulador VT100 como screen local. screen te permite la posibilidad de ejecutar múltiples y concurrentes sesiones desde un terminal. Instala la base de datos del terminal cons25 en la máquina remota. Lanza las X y haz el login en la máquina remota desde xterm. Aparece el mensaje de error "calcru: negative time..." Esto puede ser causado por varios problemas de hardware o software relacionados con las interrupciones. Utilizar TCP/IP sobre el puerto paralelo con un MTU muy grande es una buena manera de provocar este error. Las tarjetas gráficas aceleradoras también lo pueden provocar, teniendo que revisar la interrupción utilizada por la tarjeta. El efecto de este error es que los procesos mueren con el mensaje "SIGXCPU exceeded cpu time limit". Para FreeBSD 3.0 y posteriores desde el 29 de Noviembre de 1998: si el problema no puede fijarse de otra manera, la solución es poner la variable sysctl a: sysctl -w kern.timecounter.method=1 Esto puede significar un impacto en el rendimiento del sistema, pero considerando la causa del problema, probablemente no lo notarás. Si el problema persiste, mantén la variable sysctl a uno y añade la opción "NTIMECOUNTER" en tu kernel para aumentar su valor. Si finalmente llegas a un valor de "NTIMECOUNTER=20" el problema no está resuelto, y las interrupciones están demasiado saturadas para ofrecer un buén rendimiento. Aplicaciones Comerciales NOTA Esta sección está todavía poco desarrollada, por lo que esperamos que las compañías nos ayuden a completarla :) . El grupo de FreeBSD no tiene ningún interés financiero en ninguna de las empresas aquí listadas, simplemente están como servicio público (y creemos que el interés comercial por FreeBSD puede tener efectos muy positivos en la viabilidad a largo término). Animamos a las empresas desarrolladoras de software que nos envíen su información para ser incluidas en esta lista. ¿Dónde puedo obtener Motif para FreeBSD? Contacta con Apps2go para una distribución de Motif ELF 2.1 para FreeBSD. Esta distribución incluye: OSF/Motif manager, xmbind, panner, wsm. Kit de desarrollo con uil, mrm, xm, xmcxx, includes y archivos Imake. Librerías ELF estáticas y dinámicas (para usar con FreeBSD 3.0 y posteriores). Applets demostrativos. Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para NetBSD y OpenBSD por Apps2go. La distribución sólo está disponible por FTP. Más información Página web de Apps2go o Ventas o Soporte o teléfono (817) 431 8775 o +1 817 431-8775 Contacta con Metro Link para obtener una distribución de Motif 2.1 ELF o a.out para FreeBSD. Esta distribución incluye: OSF/Motif manager, xmbind, panner, wsm. Kit de desarrollo con uil, mrm, xm, xmcxx, includes y archivos Imake. Librerías estáticas y dinámicas (especifica ELF para FreeBSD 3.0 y superior o a.out para FreeBSD 2.2.8 o anterior). Applets demostrativos. Páginas man preformateadas. Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para Linux por Metro Link. La distribución está disponible en CDROM o vía FTP. Contacta con Xi Graphics para una distribución de Motif a.out 2.0 para FreeBSD. Esta distribución incluye: OSF/Motif manager, xmbind, panner, wsm. Kit de desarrollo con uil, mrm, xm, xmcxx, includes y archivos Imake. Librerías estáticas y dinámicas (para usar con FreeBSD 2.2.8 y anteriores). Applets demostrativos. Páginas man preformateadas. Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para BSDI y Linux por Xi Graphics. La distribución se hace en cuatro disquetes... en el futuro esto se cambiará por una versión en CDROM unificada. ¿Dónde puedo conseguir CDE para FreeBSD? Contacta con Xi Graphics para la distribucion CDE 1.0.10 para FreeBSD. Incluye Motif 1.2.5, y puede ser usada con Motif 2.0. Este es un CDROM unificado para FreeBSD y Linux. Xi Graphics ya no vende el CDE para FreeBSD. KDE es un entorno gráfico "open source" similar a CDE en muchos aspectos. ¿Hay algún servidor X comercial de altas prestaciones? Sí, Xi Graphics y Metro Link venden el producto Accelerated-X para FreeBSD y otros sistemas basados en Intel. La oferta de Metro Link es un servidor X de altas prestaciones que ofrece una fácil configuración usando el conjunto de herramientas "FreeBSD Package", soporte de múltiples tarjetas de vídeo concurrentes y sólo se distribuye en formato binario desde su FTP. Mencionar que la oferta de Metro Link está disponible por el razonable precio de $39. Metro Link también vende el Motif ELF y a.out para FreeBSD. Más información Web de Metro Link o Ventas o Soporte. o Teléfono (954) 938-0283 o +1 954 938-0283 La oferta de Xi Graphics es un servidor X de altas prestaciones que ofrece una fácil configuración, soporte para múltiples tarjetas de vídeo concurrentes, y sólo se distribuye en formato binario, en una distribución en disquetes unificada para FreeBSD y Linux. Xi Graphics también ofrece un servidor X de altas prestaciones para computadores portátiles. Hay una distribución demo para testear (versión 5.0). Xi Graphics también vende el Motif y CDE para FreeBSD. Máss información Web de Xi Graphics WWW o ventas o Soporte o Teléfono (800) 946 7433 o +1 303 298-7478. ¿Hay algún sistema de base de datos para FreeBSD? Sí!. Mira en la sección Productos Comerciales del web de FreeBSD. También te recomendamos que mires en la sección Bases de Datos de la colección de Ports. ¿Puedo usar Oracle en FreeBSD? Sí. Las siguientes páginas te explican como configurar el Oracle de Linux en FreeBSD: http://www.scc.nl/~marcel/howto-oracle.html http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-FreeBSD Aplicaciones de usuario ¿Dónde están las aplicaciones? Por favor, mira en la sección de ports para obtener información sobre programas y aplicaciones que han sido portados a FreeBSD. En estos momentos la lista llega a los 1800 creciendo día a día, por lo que te recomendamos que la visites habitualmente o te subscribas a la lista de distribución FreeBSD-announce para las actualizaciones periódicas de nuevas aportaciones. La mayoría de programas están disponibles tanto para la rama 2.2 como para la 3.x y 4.0, y muchos de ellos deberían funcionar en sistemas 2.1.x. Cada vez que se realiza una release de FreeBSD, se incluye un snapshot del arbol de aplicaciones en el directorio ports/. También trabajamos con el concepto de "package", que es, esencialmente una distribución binaria "zipada" con una pequeña información extra que realiza la instalación del programa automaticamente. Un package puede ser instalado y desinstalado fácilmente sin tener que saber los detalles de archivos o configuraciones que esto conlleva. Usa el menú de instalación de "packages" en /stand/sysinstall (bajo la opción post-configuration del menú principal) o ejecuta el comando pkg_add(1) con el package que estás interesado en instalar. Los package pueden ser identificados por su extensión .tgz. En la distribución de CDROM existe un directorio packages/All en la que se encuentran todos los packages disponibles. También pueden conseguirse en la red en los siguientes servidores: para 2.2.8-RELEASE/2.2-stable ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/ para 3.4-release/3.4-stable ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-3-stable/ para 4.0-current ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4-current/ o en tu mirror más cercano. Ten en cuenta que no todos los ports están disponibles como packages. Es siempre buena idea visitar periodicamente la dirección ftp.FreeBSD.org. ¿Dónde encuentro la librería libc.so.3.0? Estás intentando ejecutar un package para versión 2.2/3.x/4.0 en un sistema de versión 2.1.x. Por favor, mira en la sección anterior y usa el package adecuado para tu sistema. Ghostscript tiene muchos errores con mi 386/486SX. No tienes coprocesador matemático, verdad? Necesitarás añadir el emulador matemático en tu kernel; puedes hacerlo añadiendo lo siguiente en el archivo de configuración del kernel: options GPL_MATH_EMULATE NOTA Necesitarás eliminar la opción MATH_EMULATE. Cuando ejecuto una aplicación SCO/iBCS2, falla en socksys. Primero necesitas editar el archivo /etc/sysconfig (o /etc/rc.conf) y en la última sección cambiar la siguiente variable a YES: # Set to YES if you want ibcs2 (SCO) emulation loaded at startup ibcs2=NO El kernel caragará el módulo ibcs2 al arrancar. A continuación necesitarás configurar /compat/ibcs2/dev de la siguiente manera lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx Solo necesitas el socksys para ir a /dev/null e imitar la apertura y cierre de archivos. El código en -current gestionará el resto. Esto es mucho más limpio que la manera en la que se hacía antes. Si quieres el driver spx para un conexión, define SPX_HACK cuando compiles el kernel. ¿Cómo configuro INN (Internet News) para mi máquina? Después de la instalación del package o port de inn, un excelente lugar para empezar es Dave Barr's INN Page donde encontrarás las FAQ de INN. ¿Qué versión de Microsoft FrontPage debo usar? Usa el Port. Una versión pre-parcheada para Apache está disponible en la colección de ports. ¿FreeBSD soporta Java? Sí. Por favor, mira en http://www.FreeBSD.org/java/. ¿Porqué no puedo compilar este port en mi máquina 3.x-stable? Si utilizas una versión de FreeBSD que ha quedado ligeramente anticuada con respecto a -stable o -current necesitarás el kit de actualización de ports disponible en http://www.FreeBSD.org/ports/. Si tienes una versión actualizada, es posible que alguien haya modificado el port de manera que éste compile en -current pero no en -stable. Por favor, envía un informe de error con el comando send-pr(1) ya que la colección de ports está pensada para que funcione tanto en las ramas -stable como -current. ¿Dónde encuentro ld.so? Si quieres ejecutar aplicaciones a.out como Netscape en sistemas con formato de ejecución ELF como FreeBSD 3.1-RELEASE o posteriores, necesitarás la librería /usr/libexec/ld.so y algunas otras en formato a.out. Estas librerías están incluidas en la distribución compat22. Usa /stand/sysinstall o el script install.sh en el subdirectorio compat22 e instalala. También deberían consultarse los archivos ERRATA de FreeBSD 3.1-R y 3.2-R. Configuración del Kernel Me gustaría personalizar mi kernel. ¿Es difícil? No!, primero, necesitas la distribución completa de fuentes o, por lo menos, la distribución de fuentes del kernel. De esta manera tienes los fuentes necesarios para crearte un nuevo kernel. Al contrario que muchos Unix comerciales, nosotros tenemos la política de NO vender nuestro kernel en formato binario. La instalación de los fuentes ocupa un poco más de espacio, pero te permite consultar los fuentes del kernel en caso de dificultad o entender que está ocurriendo realmente en la ejecución del sistema. Una vez tienes instalada la distribución completa de fuentes, o por lo menos la del kernel, haz lo siguiente como root: cd /usr/src/sys/i386/conf cp GENERIC MYKERNEL vi MYKERNEL config MYKERNEL cd ../../compile/MYKERNEL make depend make all make install reboot El paso 2 no es necesario si todavía tienes un archivo de configuración del kernel de una release anterior de FreeBSD 2.X. - simplemente, copia el archivo antiguo y examínalo cuidadosamente para asegurar que no haya cambiado la sintaxis da algún driver, o haya alguno anticuado. Un buen archivo de configuración para consultar es LINT, el cual contiene ejemplos documentados para todas las posibles opciones del kernel. El archivo de configuración GENERIC se usa para crear el kernel "por defacto" que es el que estarás usando si no has creado ninguno nuevo. Si no necesitas hacer ningún cambio al archivo GENERIC, puedes saltar al paso 3, donde personalizas el kernel para tu sistema. El paso 8 solo debe ejecutarse si los pasos 6 y 7 se han realizado de manera satisfactoria. Esto copiará una imágen del nuevo kernel a /kernel y realizará una copia del antiguo kernel en /kernel.old. Es muy importante recordar esto por si el nuevo kernel falla en algun momento - puedes seleccionar kernel.old en el prompt de arranque. Al hacer un reboot, por defecto se cargará el nuevo kernel. Si la compilación en el paso 7 falla por alguna razón, es recomendable que empieces desde el paso 4 substituyendo GENERIC por MYKERNEL. Si puedes generar el kernel GENERIC, significa que algo en tu archivo de configuración es incorrecto (o has decubierto un bug). Si la compilación del kernel GENERIC falla, posiblemente tengas los fuentes corruptos. Finalmente, si necesitas ver los mensajes originales de arranque del sistema para compilar un nuevo kernel, ejecuta el comando dmesg. Este comando debe imprimir en pantalla todos los mensajes producidos por el kernel al arrancar, los cuales te pueden servir en la configuración de tu nuevo kernel. NOTA Recomendamos hacer un historial fechado de los kernel que vayas creando, de la manera kernel.YYMMDD una vez estén funcionando correctamente. De esta manera, si la próxima vez que juegues con el kernel algo no funciona, puedes arrancar desde el último kernel correcto. Esto es especialmente importante si ahora estás arrancando desde una controladora no soportada por el kernel GENERIC (si, experiencia personal). La compilación del kernel falla por "_hw_float is missing." Dejame adivinar. Has borrado npx0 de tu archivo de configuración porque no tienes coprocesador matemático, no? Mal hecho :-) El dispositivo npx0 es OBLIGATORIO. Aunque no tengas coprocesador, debes incluir el dispositivo npx0 Conflicto de interrupciones con tarjeta serie multi-port. Cuando compilo el kernel con drivers para tarjetas serie multipuerto, el sistema me dice que sólo el primer puerto es testeado y el resto son obviados debido a conflictos de interrupción. Cómo soluciono esto? El problema en este caso es que FreeBSD tiene código interno que evita caidas del sistema por conflictos de hardware o software. La manera de solucionar esto es dejar en blanco la entrada correspondiente a la irq en todos los puertos excepto en uno. Aquí tienes un ejemplo: # # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr ¿Cómo activo el soporte para discos QIC-40/80? Necesitas "descomentar" la siguiente línea en el archivo genérico de configuración (o añadirla en tu propio archivo), añade un flags 0x1 en la línea fdc y recompila. controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 flags 0x1 vector fdintr disk fd0 at fdc0 drive 0 ^^^^^^^^^ disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A continuación, crea un nuevo dispositivo llamado /dev/ft0 entrando en el directorio /dev y ejecutando el comando: sh ./MAKEDEV ft0 Para el primer dispositivo. ft1 para el segundo y así para todos los dispositivos de este tipo que tengas. Tendrás un dispositivo llamado /dev/ft0, al cual puedes escribir a través de un programa especial de manejo llamado ft - mira el man en ft para más detalles. Versiones anteriores a la tenían algunos problemas al encontrase con cintas en mal estado; si tienes problemas en los que parece que la cinta se rebovina siempre al llegar al mismo lugar, intenta utilizar la última versión del programa ft que encontrarás en /usr/src/sbin/ft en . Administración de sistema ¿Dónde están los archivos de configuración de arranque del sistema? De la versión 2.0.5R a la 2.2.1R, el archivo principal de configuración es /etc/sysconfig. Todas las opciones son especificadas en este archivo y otros como /etc/rc y /etc/netstart. Mira en el archivo /etc/sysconfig y cambia los valores para tu sistema. Este archivo está comentado para ayudar en la configuración En versiones posteriores a la 2.2.1 y 3.0 el archivo /etc/sysconfig fue renombrado como rc.conf. La sintaxis también fue retocada para ser más descriptiva. El archivo /etc/netstart también fue renombrado como /etc/rc.network para que todos los archivos de configuración puedan ser copiados con el comando cp /usr/src/etc/rc* /etc. /etc/rc.local existe como siempre y debería ser usado para arrancar servicios locales adicionales como INN o programas propios. El archivo /etc/rc.serial es para la inicialización de puertos serie. El archivo /etc/rc.i386 es para especificaciones propias de Intel, como la emulación iBCS2 o la configuración de la consola del sistema. A partir de la versión 2.1.0R, también puedes tener un directorio en el que instalar archivos de arranque locales especificado en /etc/sysconfig (o /etc/rc.conf): # Localización de los archivos de arranque locales. local_startup=/usr/local/etc/rc.local.d Cada archivo acabado en .sh será ejecutado en orden alfabético. Si quieres asegurarte de un cierto orden en la ejecución sin tener que cambiar todos los nombres de los archivos, puedes usar un esquema similar al siguiente con dígitos al principio del nombre de cada archivo: 10news.sh 15httpd.sh 20ssh.sh Puede ser visto como "malo" (o SysV :-)) pero nos provee de un esquema regular para programas añadidos localmente sin tener que hacer ediciones complicadas del archivo /etc/rc.local. Muchos de los ports/packages asumen que /usr/local/etc/rc.d es un directorio de arranque local. ¿Cómo añado un usuario facilmente? Usa el comando adduser. Para opciones más avanzadas, usa el comando pw Para borrar a un usuario, usa el comando rmuser. ¿Cómo puedo añadir mi nuevo disco a FreeBSD? Consultar el Tutorial de Formateo de Discos en www.FreeBSD.org. Tengo un nuevo disco removible, ¿como lo uso? Se trate de un disco removible como un ZIP o EA (o un floppy, si quieres usarlo de esta manera), o un nuevo disco duro, una vez instalado y reconocido por el sistema, y tengas tu cartridge/floppy/etc en su interior, las cosas son como para la mayoría de dispositivos. (esta sección esta basada en Mark Mayo's ZIP FAQ) Si es un disco ZIP o floppy, y está formateado en DOS, puedes usar el comando: mount -t msdos /dev/fd0c /floppy Si es un floppy, o este: mount -t msdos /dev/da2s4 /zip para un disco ZIP con la configuración de fábrica. Para otros discos, mira como configurarlos usando fdisk o /stand/sysinstall. El resto de ejemplos serán para un disco ZIP en da2, el tercer disco SCSI. A no ser que se trate de un floppy o disco removible, lo que planeas compartir con otros usuarios, es aconsejable convertir el formato de archivos a BSD. Obtendrás nombre de archivos largos, como mínimo doblarás la velocidad de acceso del disco, y mucha más estabilidad. Antes, necesitas rehacer las particiones. Puedes usar el comando fdisk o la utilidad /stand/sysinstall. Si es un disco pequeño que quieres dedicar enteramente a FreeBSD, solo tienes que eliminar la FAT y tabla de particiones, y usar el sistema de particiones de FreeBSD: dd if=/dev/zero of=/dev/rda2 count=2 disklabel -Brw da2 auto Puedes usar el comando disklabel o /stand/sysinstall para crear múltiples particiones BSD. Finalmente, crea un nuevo sistema de archivos: newfs /dev/rda2c y montalo: mount /dev/da2c /zip Sería una buena idea añadir una línea como esta en el archivo /etc/fstab para que solo tengas que teclear "mount /zip" las siguientes veces. /dev/da2c /zip ffs rw,noauto 0 0 ¿Cómo monto una partición secundaria DOS? Las particiones DOS secundarias se encuentran después de TODAS las particiones primarias. Por ejemplo, si tienes una partición "E" como la segunda partición DOS en el segundo disco SCSI, necesitas crear los archivos especiales para el dispositivo 5 en /dev, y después montar /dev/da1s5: # cd /dev # ./MAKEDEV da1s5 # mount -t msdos /dev/da1s5 /dos/e ¿Puedo montar otros sistemas de archivos bajo FreeBSD? Digital UNIX UFS CDROMs pueden ser montados directamente en FreeBSD. Montar particiones de disco de Digital UNIX y otros sistemas que soportan UFS puede ser más complejo, dependiendo de los detalles de la partición de disco del sistema operativo en cuestión. Linux: 2.2 y posteriores soportan particiones ext2fs. Mira mount_ext2fs para más información. NT: Existe un driver de solo lectura de NTFS para FreeBSD. Para más información, mira este tutorial de Mark Ovens en http://www.users.globalnet.co.uk/~markov/ntfs_install.html. ¿Cómo puedo usar el "NT loader" para arrancar FreeBSD? La idea general es que copies el primer sector de la partición root nativa de FreeBSD en un archivo en la partición DOS/NT. Asumiento que nombras a ese archivo como c:\bootsect.bsd puedes editar el archivo c:\boot.ini para conseguir algo como esto: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="FreeBSD" C:\="DOS" Este proceso asume que DOS, NT, FreeBSD o cualquier otro sistema ha sido instalado en sus respectivas particiones en el mismo disco. En nuestro caso, DOS y NT están en la primera partición y FreeBSD en la segunda. Instalamos FreeBSD para arrancarlo desde su partición nativa y no desde el disco MBR. Monta un floppy formateado en DOS bajo la partición /mnt. dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1 Rearranca en DOS o NT. Copia el archivo bootsect.bsd y/o el archivo bootsect.lnx del floppy a C:\. Modifica los atributos a boot.ini con: attrib -s -r c:\boot.ini Edita y añade las líneas apropiadas del boot.ini mostrado enteriormente de ejemplo, y vuelve a poner los atributos originales: attrib +s +r c:\boot.ini Si FreeBSD está arrancando desde el MBR, restauralo desde el comando fdisk después de reconfigurarlos para arrancar desde sus particiones nativas. ¿Cómo arranco FreeBSD y Linux desde LILO? Si tienes FreeBSD y Linux en el mismo disco, solo tienes que seguir las instrucciones de instalación de LILO para arrancar un sistema operativo no Linux. Brevemente, son estas: Arranca Linux, y añade las siguientes líneas en el archivo /etc/lilo.conf: other=/dev/hda2 table=/dev/hda label=FreeBSD (Asumiendo que tu partición FreeBSD es conocida por Linux como /dev/hda2). A continuación, ejecuta lilo como root y ya debería estar. Si FreeBSD está en otro disco, necesitas añadir ``loader=/boot/chain.b'' al archivo lilo.conf. Por ejemplo: other=/dev/sdb4 table=/dev/sdb loader=/boot/chain.b label=FreeBSD En algunos casos necesitarás especificar el número de disco en BIOS para que el cargador del boot funcione correctamente desde el segundo disco. Por ejemplo, si tu disco SCSI con FreeBSD es visto por el BIOS como disco 1, en el prompt del cargador de arranque necesitarás especificar: Boot: 1:da(0,a)/kernel En FreeBSD 2.2.5 y posteriores, puedes configurar boot(8) para que haga esto automaticamente. El Linux+FreeBSD mini-HOWTO es una buena referencia para las opciones de interoperabilidad entre FreeBSD y Linux. ¿Cómo arranco FreeBSD y Linux usando BootEasy? Instala el LILO al inicio de la partición de arranque del Linux en lugar de hacerlo en el "Master Boot Record". Así podrás arrancar el LILO desde BootEasy. Si estas usando Windows-95 y Linux, también es recomendable hacer esto para simplificar el arranque de Linux en caso de que sea necesaria una reinstalación del Windows-95 (ya que no quiere convivir con otros sistemas operativos en el mismo Master Boot Record). ¿Puede un disco "dedicado" provocar problemas? El proceso de instalación nos permite elegir dos métodos diferentes de particionar un disco. El sistema por defecto hace que el disco sea compatible con otros sistemas operativos en la misma máquina, usando las tablas de entrada de fdisk (llamadas "slices" en FreeBSD). Opcionalmente, podemos instalar un boot-selector que nos permite seleccionar el sistema operativo con el que queremos arrancar. Mientras este es el caso más com&ún para gente proveniente del mundo de PC, para la gente proveniente del mundo Unix y quienes quieren instalar una máquina para funcionar con FreeBSD y solo FreeBSD, es más habitual usar el sistema de reservar todo el espacio del disco para un solo sistema operativo. Si seleccionas "A)ll FreeBSD" en el editor de fdisk de la utilidad sysinstall, y respondes la siguiente pregunta con "No", usarás este último sistema. Ten en cuenta que usando este sistema no te permitirá la instalación de ningún otro sistema operativo o selector de arranque (boot manager). Entonces, ¿por qué se llama "peligroso"?. Un disco en este modo no contiene lo que las utilidades normales de un PC considerarían una tabla de partición de archivos válida. Dependiendo del diseño de estas aplicaciones, puede que dañen el sector de arranque una vez entren en contacto con el disco. Por lo menos una BIOS Award usada por máquinas HP Netservers (pero no sólo por ellos) es concocida por ignorar los disco duros que no contengan lo que el BIOS entiende por una tabla de archivos válida. Para volver un disco "peligrosamente dedicado" a formato estándar de PC, hay básicamente dos opciones. La primera es, escribes suficientes bytes NULL sobre el MBR para hacer que las siguientes instalaciones crean que están en un disco sín usar. Puedes hacer esto así: dd if=/dev/zero of=/dev/rda0 count=15 Alternativamente, puedes hacer: fdisk /mbr que instalará un nuevo master boot record. ¿Cómo puedo añadir más espacio de swap? La mejor manera es incrementar el tamaño de tu partición de swap, o usar esta excusa para añadir un otro disco nuevo. Añadir swap en discos separados hace las cosas más rápidas que simplemente añadir swap en el mismo disco. Como ejemplo, si estás compilando código fuente en un disco, y el swap está en otro disco, es mucho más rápido que si el swap y la compilación se realizaran en el mismo disco. Esto es cierto específicamente para discos SCSI. Los discos IDE no son capaces de permitir el acceso a ambos discos en el mismo canal al mismo tiempo (FreeBSD no soporta el modo 4, ya que todas las I/O de discos IDE son "programadas"). Es realmente muy mala idea instalar el swap sobre NFS a no ser que trabajes en una red muy rápida con un muy buen servidor. Aquí hay un ejemplo para un archivo de swap de 64Mb /usr/swap0, piensa que puedes usar el nombre que quieras). Asegurate que el kernel está compilado con la línea pseudo-device vn 1 #Vnode driver (turns a file into a device) en tu archivo de configuración. El kernel GENERIC la contiene. crea un vn-device cd /dev sh ./MAKEDEV vn0 crea un swapfile (/usr/swap0) dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 activa el archivo de swap en /etc/rc.conf swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. rearranca la máquina. Para activar el archivo de swap inmediatamente teclea vnconfig -ce /dev/vn0c /usr/swap0 swap Tengo problemas para poner en marcha mi impresora. Por favor, revisa la sección de impresoras del manual. Cubre la mayoría de posibles problemas. Pásate por esta sección. Mi teclado no coincide con los carácteres de pantalla. El programa de control de teclado tiene una opción para cargar el mapa de teclado. En el directorio /usr/share/syscons/keymaps hay diferentes archivos de mapas de teclado. Selecciona el que corresponde a tu sistema y cárgalo. kbdcontrol -l uk.iso Tanto el directorio /usr/share/syscons/keymaps como la extensión .kbd son asumidas por la orden kbdcontrol. Esto puede ser configurado en /etc/sysconfig (o rc.conf). Mira los comentarios correspondientes en el propio archivo. En la versión 2.0.5R y posteriores, todo lo referente a fuentes, teclado, etc está en /usr/share/examples/syscons. Actualmente se soportan los siguientes mapas de teclado: Belgian ISO-8859-1 Brazilian 275 keyboard Codepage 850 Brazilian 275 keyboard ISO-8859-1 Danish Codepage 865 Danish ISO-8859-1 French ISO-8859-1 German Codepage 850 German ISO-8859-1 Italian ISO-8859-1 Japanese 106 Japanese 106x Latin American Norwegian ISO-8859-1 Polish ISO-8859-2 (programmer's) Russian Codepage 866 (alternative) Russian koi8-r (shift) Russian koi8-r Spanish ISO-8859-1 Swedish Codepage 850 Swedish ISO-8859-1 Swiss-German ISO-8859-1 United Kingdom Codepage 850 United Kingdom ISO-8859-1 United States of America ISO-8859-1 United States of America dvorak United States of America dvorakx Las cuotas de usuario no funcionan correctamente. No actives las cuotas en '/', Pon el archivo de cuotas en el sistema de archivos en el que se vayan a forzar las cuotas de usuario: FS QUOTA FILE /usr /usr/admin/quotas /home /home/admin/quotas ... Mi ccd no funciona correctamente El síntoma es: # ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format # Esto actualmente ocurre cuando estás intentando concatenar las particiones c'. El driver ccd requiere que la partición sea del tipo FS_BSDFFS. Edita la etiqueta del disco (disklabel) que estás intentando concatenar y cambia el tipo de partición a '4.2BSD'. ¿Porqué no puedo editar el disklabel en mi ccd? El síntoma es: # disklabel ccd0 (it prints something sensible here, so let's try to edit it) # disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label # Esto es porque el disklabel retornado por el ccd es actualmente uno que no corresponde con el real. Puedes resolver este problema escribiendo explícitamente: # disklabel ccd0 > /tmp/disklabel.tmp # disklabel -Rr ccd0 /tmp/disklabel.tmp # disklabel -e ccd0 (ahora funcionara) ¿Soporta FreeBSD primitivas IPC System V? Sí, FreeBSD las soporta. Estas incluyen memoria compartida, mensajes y semáforos. Necesitas añadir las siguientes líneas en la configuración de tu kernel para activarlas. options SYSVSHM options "SHMMAXPGS=64" # 256Kb of sharable memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging Recompila e instala. NOTA: Quizás necesites incrementar SHMMAXPGS a un número como 4096 (16M) si quieres usar GIMP. 256K es suficiente para la memoria compartida en X11R6. ¿Cómo uso sendmail para envio de mail UUCP? La configuración de sendmail incluida en FreeBSD está preparada para sistemas que conectan directamente con Internet. Los sistemas que quieran usar UUCP para el envío de mail deben utilizar otro archivo de configuración. Retocar /etc/sendmail.cf manualmente está considerado algo para puristas. La versión 8 de sendmail incluye un nuevo sistema de configuración llamado m4, en el cual la configuración se realiza en un nivel más alto. Deberías usar los archivos de configuración situados en /usr/src/usr.sbin/sendmail/cf Si no instalaste tu sistema con el código fuente completo, el paquete de configuración de sendmail está en una distribución aparte. Asumiendo que tienes tu CD-ROM montado, haz: cd /usr/src tar -xvzf /cdrom/dists/src/ssmailcf.aa No te preocupes, solo son unos cientos de kilobytes de tamaño. El archivo README en el directorio cf puede servir como introducción a la configuración del m4. Para envío y recepción va UUCP, te aconsejamos usar la opción mailertable. Se basa en una base de datos que sendmail puede usar como base para tomar las decisiones de enrutado del mail. Primero tienes que crear tu archivo .mc. Estos archivos se encuentran en el directorio /usr/src/usr.sbin/sendmail/cf/cf. Si miras, encontrarás algunos ejemplos. Asumiendo que tu archivo se llama foo.com, todo lo que necesitas hacer para convertirlo en un archivo sendmail.cf válido es: cd /usr/src/usr.sbin/sendmail/cf/cf make foo.cf cp foo.cf /etc/sendmail.cf Un archivo típico .mc sería algo como: include(`../m4/cf.m4') VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP Las opciones nodns y nocanonify previenen del uso del DNS durante el tráfico de correo. La cláusula UUCP_RELAY se necesita por razones imperiosas, no preguntes :). Simplemente pon un nombre de máquina de Internet que sea capaz de gestionar pseudo-dominios .UUCP; más sencillo, entrarás el mail relay de tu ISP. Una vez hayas hecho esto, necesitas el archivo llamado /etc/mailtertable. Un ejemplo típico sería: # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom:sax Como puedes ver, esto es parte de un archivo real. Las tres primeras líneas manejan casos especiales donde el correo dirigido a un dominio no debe ser enviado a través de la ruta por defecto, si no a través de un UUCP vecino para acortar el path de envío. La siguiente línea gestiona el mail del dominio local para que sea enviado vía SMTP. Finalmente, los vecinos UUCP son anotados en la parte .UUCP pseudo-domains, para poder sobreescribir las reglas por defecto. La última línea es siempre un punto, que indica el mail gateway hacia el resto del mundo. Todos los nombres de nodos detrás de uucp-dom: deben ser vecinos válidos UUCP. Como recordatorio de que este archivo debe ser convertido a una base de datos DBM antes de ser usada, la línea de comandos para realizar esta operación esta puesta como un comentario al inicio del archivo. Siempre tienes que ejecutar este comando cada vez que realices algún cambio en tu mailtertable. Si no tienes la seguridad de que una ruta de correo vaya a funcionar correctamente, recuerda la opción de sendmail. Esta opción arranca el sendmail en modo test; simplemente entra 0, seguido por la dirección de mail sobre la que quieres testear la ruta. La última línea te indica el agente interno, el host de destino y la dirección (posiblemente traducido). Sal de este modo tecleando Control-D. j@uriah 191% sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D j@uriah 192% ¿Cómo configuro el correo para conexiones NO permanentes a Internet? Si tienes una dirección IP fija en la conexión, no necesitarás ajustar nada de lo que ya viene por defecto. Configura tu hostname como el nombre asignado a tu IP de Internet y sendmail hará el resto. Si tienes direcciones IP asignadas dinamicamente y usas una conexión ppp a Internet, probablemente tendrás un buzón en el servidor de correo de tu proveedor. Supongamos que el dominio de tu proveedor es myisp.com, y tu nombre de usuario es user. Supongamos también que has llamado a tu máquina bsd.home y que tu proveedor te ha indicado que uses la máaquina relay.myISP.com como mail realy (gateway). Para poder recoger el correo de tu buzón necesitarás instalar un agente de recogida de correo. Fetchmail es una buena opción ya que soporta diferentes protocolos. Normalmente se usa POP3. Puedes recoger automaticamente tu correo al realizar la conexión añadiendo la siguiente línea en el archivo /etc+ppp/ppp.linkup: MYADDR: !bg su user -c fetchmail Asumimos que tienes una cuenta para user en bsd.home. En el home directory de user en bsd.home, crea el archivo .fetchmailrc: poll myISP.com protocol pop3 fetchall pass MySecret; No hace falta decir que este archivo no debe ser "leible" por nadie excepto user ya que contiene el password MySecret. Para enviar el correo con la cabecera from: correcta, debes decirle al sendmail que use user@myISP.com en lugar de user@bsd.home. También deberías decirle al sendmail que envie todo el correo saliente a traves de relay.myISP.com, para una transmisión mucho más rápida. El siguiente archivo .mc debe ser suficiente: VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home CwmyISP.com MASQUERADE_AS(`myISP.com')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(SMART_HOST, `relay.myISP.com') DmmyISP.com define(`confDOMAIN_NAME',`myISP.com')dnl define(`confDELIVERY_MODE',`deferred')dnl Mira en la sección anterior para los detalles de como convertir este archivo .mc en un sendmail.cf. No te olvides de rearrancar sendmail después de cada actualización del archivo sendmail.cf. Olvidé el password de Root!! Tranquilo!!!. Simplemenre rearranca tu sistema, teclea -s en el prompt de arranque para entrar en modo monousuario. En la pregunta sobre el shell a usar, pulsa ENTER. Aparecerá un prompt #. Teclea mount -u / para remontar tu sistema de archivos en modo de lectura/escritura y a continuación teclea mount -a para montar todos los sistemas de archivos. Ejecura passwd root para cambiar el password de root. Teclea exit para continuar normalmente con el arranque. ¿Cómo mantengo el control sobre Control-Alt-Delete? Edita el mapa de teclado que estás usando para la consola y reemplaza las palabras boot por nop. El mapa de teclado por defecto es /usr/share/syscons/keymaps/us.iso.kbd. Por supuesto si usas otro mapa de teclado adecuado a tu país, tendrías que editarlo. ¿Cómo reformateo archivos de texto DOS a UNIX? Simplemente usando este comando de perl: perl -i.bak -npe 's/\r\n/\n/g' file ... file es el archivo a procesar. La modificación se hace en el propio archivo dejando el original grabado con extensión .bak. Alternativamente puedes usar el comando tr(1) tr -d '\r' < dos-text-file > unix-file dos-text-file es el archivo que contiene el texto DOS mientras que unix-file contendrá la salida convertida. Este sistema puede ser más rápido que usar perl. ¿Cómo puedo hace "kill" de procesos por nombre? Usa killall(1). ¿Porque el su no me dejar ser root al no estar en el ACL? El error proviene de sistema del autentificación distribuida Kerberos. El problema no es fatal pero si molesto. Puedes ejecutar el comando su con la opcion -K, o desinstalar Kerberos como se describe en la siguiente sección. ¿Cómo desinstalo Kerberos? Para eliminar Kerberos del sistema, reinstala la distribución bin de la release que estés usando. Si tienes el CDROM, puedes montar el cd (asumiremos que esta en /cdrom) y ejecutar: cd /cdrom/bin ./install.sh ¿Cómo añado pseudoterminales a mi sistema? Si tienes muchos usuarios de telnet, ssh, X, o de consola, probablemente terminarás desbordando el número de pseudoterminales del sistema. Aquí tienes como añadir más: Compila e instala un nuevo kernel com la línea pseudo-device pty 256 en el archivo de configuración. Ejecuta el comando # cd /dev # ./MAKEDEV pty{1,2,3,4,5,6,7} para crear 256 nodos de dispositivo para los nuevos terminales. Edita el archivo /etc/ttys y añade una línea para cada uno de los 256 terminales. Estas líneas deben seguir la estructura de las entradas existentes, algo como esto: ttyqc none network El órden de la designación de letras es tty[pqrsPQRS][0-9a-v], usando una expresión regular. Rearranca el sistema con el nuevo kernel, y lo tendrás listo para funcionar. ¿Cómo puedo releer el archivo /etc/rc.conf y relanzar /etc/rc sin tener que hacer un reboot? Entra en modo monousuario y a continuación vuelve a modo multiusuario. En la consola haz: # shutdown now (Nota: sin -r o -h) # return # exit ¿Qué es un sandbox? Sandbox es un término de seguridad. Puede significar dos cosas: Un proceso que es situado en el interior de una serie de muros virtuales diseñados como prevención e imposibilitar el acceso al sistema principal en caso de que alguien comprometa la seguridad de ese proceso. Se dice que el proceso es capaz de "jugar" entre los muros. Esto significa que se supone que nada de lo que haga el proceso referente a la ejecución de código, puede ser capaz de romper los muros, así no es necesario hacer auditorías detalladas de su código para poder conocer todo lo referente a los riesgos de seguridad del proceso. Los muros pueden, por ejemplo, un userid. Esta es la definición usada en las páginas man de seguridad y del programa named. Veamos como ejemplo el servicio 'ntalk' (consultar /etc/inetd.conf). Este servicio solía ejecutarse con el userid de root. Ahora se ejecuta con el userid tty. El usuario tty esta diseñado para ser usado como usuario sandbox, dificultando así la tarea de un intruso que haya conseguido penetrar en el sistema a través del servicio ntalk. De esta manera, el intruso solo puede afectar a los servicios, programas o procesos propiedad del usuario tty. Un proceso que se ha situado en el interior de una simulación de la máquina. Esto es más hard-core. Básicamente, significa que alguien que sea capaz de penetrar en el proceso, creerá que ha penetrado en el sistema principal, pero de hecho, ha penetrado en una simulación de esa máquina y no puede modificar ningún dato real. El sistema más común de conseguir esto es crear un entorno simulado en un subdirectorio y ejecutar los procesos en ese subdirectorio mediante chroot (la raiz "/" para ese proceso es este directorio, no la raiz "/" real del sistema). Otro sistema habitual es montar un sistema de archivos de solo lectura y a continuació,n crear un nivel de sistema de archivos por encima del anterior que dé al proceso la sensación de encontrarse en un sistema de archivos de lectura/escritura. El proceso creerá que es capaz de escribir esos archivos, pero sólo el proceso ve los efectos; otros procesos del sistema no ven absolutamente nada. Se intenta crear este tipo de sandbox totalmente transparentes para que el usuario (o intruso) no se de cuenta que está en él. UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos, y el otro es a nivel de usuarios (userid). Cada proceso UNIX es totalmente independiente de cualquier otro proceso UNIX. Un proceso no puede modificar el espacio de direcciones de otro. Es diferente a los sistemas Windows en los que un proceso puede sobreescribir facilmente el espacio de direcciones de otro proceso, probocando una caida de la máquina. Un proceso UNIX es propiedad de un userid determinado. Si el userid no es el usuario root, éste solo podrá acceder a los procesos de su propiedad, evitando la intrusión en procesos ajenos. El userid también se usa como sistema de protección para datos grabados en disco. El sistema X Windows y las consolas virtuales Quiero ejecutar las X, ¿cómo lo hago? La manera más fácil es, simplemente, especificar que quieres usar las X durante el proceso de instalación. Entonces, lee y sigue la documentación de la herramienta xf86config, la cual te ayuda a configurar el sistema XFree86 sobre las características propias de tu sistema (tarjeta de vídeo , ratón, etc). Quizás te interesaría investigar y probar el servidor Xaccel, disponible a un precio muy razonable. Mira en la sección Xi Graphics o Metro Link para más detalles. ¿Porqué no funciona mi ratón con las X? Si estás usando syscons (el driver de consola por defecto), puedes configurar FreeBSD para soportar un ratón en cada consola virtual. Para evitar conflictos con las X, syscons soporta un dispositivo virtual llamado /dev/sysmouse. Todos los eventos recibidos desde el mouse real son escritos en el dispositivo sysmouse, usando el protocolo MouseSystems. Si quieres usar el ratón en una o más consolas virtuales y usar las X, te recomendamos la siguiente configuración: /etc/rc.conf: moused_type=ps/2 # or whatever your actual type is moused_port=/dev/psm0 # or whatever your real port is moused_flags= /etc/XF86Config Section Pointer Protocol "MouseSystems" Device "/dev/sysmouse" ..... Hay gente que prefiere usar /dev/mouse bajo X. Para que esto funcione, /dev/mouse debe estar lincado a /dev/sysmouse: # cd /dev # rm -f mouse # ln -s sysmouse mouse Los menus de X Window y cajas de diálogo no funcionan bien. Intenta desactivar la tecla Num Lock. Si tu tecla Num Lock está activada por defecto al arrancar el sistema, deberías añadir la siguiente línea en la sección Keyboard del archivo XF86Config. # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients ServerNumLock ¿Qué es una consola virtual y como creo más? Las consolas virtuales te permiten tener sesiones simultáneas en la misma máquina sin necesidad de tener montajes complicados como una red o ejecución de X. Cuando el sistema arranca, mostrará el prompt de login en el monitor una vez finalizado el mismo. Puedes entonces teclear tu login y password y empezar a trabajar (o jugar), en la primera consola virtual. En algun momento, es probablemente querras iniciar otra sesion , por ejemplo, para mirar la documentación de un programa que estás ejecutando, o para leer el correo mientras esperas que termine una sesión ftp que tienes establecida. Solo haz Alt-F2 y encontrarás un prompt un prompt de login esperandote en la segunda "consola virtual". Cuando quieras volver a la sesión original, sólo tienes que pulsar Alt-F1. La instalación por defecto de FreeBSD tiene tres consolas virtuales activadas, y Alt-F1, Alt-F2 y Alt-F3 cambian entre ellas. Para activar más consolas virtuales, edita /etc/ttys y añade tantas entradas como consolas virtuales quieras a partir de ttyv4, después del comentario "Virtual Terminals": # Edit the existing entry for ttyv3 in /etc/ttys and change # "off" to "on". ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure Utiliza tantas consolas como quieras o necesites. Cuantas más consolas tengas, más recursos utilizas; esto puede ser importante si tienes 8MB de RAM o menos. También te puede interesar cambiar el modo secure a insecure. NOTA IMPORTANTE si quieres usar un servidor X DEBES dejar, al menos, un terminal virtual sin usar (o desactivado). La manera más fácil de desactivar una consola es "apagarla". Por ejemplo, para desactivar el terminal 12, cambia esto: ttyvb "/usr/libexec/getty Pc" cons25 on secure por esto: ttyvb "/usr/libexec/getty Pc" cons25 off secure Si tu teclado solo tiene 10 teclas de función, tendras que acabar con: ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (También puedes, simplemente, borrar estas líneas.) Una vez has editado el archivo /etc/ttys, el siguiente paso es asegurarte de que tienes suficientes dispositivos de terminales virtuales. La manera más fácil de hacerlo es: # cd /dev # ./MAKEDEV vty12 # For 12 devices A continuación, la manera más fácil de activar las consolas virtuales es rearrancar el sistema. Si, realmente no quieres rearrancarlo, puedes para el servidor de X Window y ejecutar (como root): kill -HUP 1 Es imperativo que pares el servidor de X Window si está funcionando, antes de ejecutar este comando. Si no lo haces, parecerá que tu sistema está parado/colgado después de ejecutar el comando kill. ¿Cómo accedo a las consolas virtuales desde X? Si la consola está actualmente mostrando X Window, puedes usar Ctrl-Alt-F1, etc, para cambiar entre las consolas virtuales. Ten en cuenta que una vez pases de una consola X Window a un terminal virtual, solo tienes que usar la tecla Alf- para volver a conmutar entre terminales virtuales o volver a las X. No necesitas pulsar la tecla Ctrl. Si usas la tecla Ctrl para volver a las X en alguna de las releases antiguas, puedes encontrarte que la consola de texto está bloqueada. Pulsa la tecla Ctrl de nuevo para desbloquearla. ¿Cómo arranco XDM desde el archivo /etc/ttys? Existen dos escuelas sobre como arrancar el xdm . Una escuela arranca el xdm desde el archivo /etc/ttys usando el ejemplo dado, mientras que la otra simplemente arranca el xdm desde el archivo rc.local o desde un script X.sh en /usr/local/etc/rc.d. Ambos métodos son igualmente válidos, y uno puede funcionar en situaciones que el otro no. En ambos casos el resultado es el mismo: el sistema X Window lanzará un prompt de login gráfico. El método ttys tiene la ventaja de documentar en que vty se lanzarán las X pasando la responsabilidad de rearrancar el servidor X al hacer el logout al proceso init. El método rc.local hace más fácil terminar con el proceso xdm en caso de problemas con el servidor X. Si arrancamos desde rc.local, xdm debe ser arrancado sin argumentos (como un daemon). xdm debe arrancar DESPUES del proceso getty, o ambos entrarán en conflicto bloqueando la consola. La mejor manera de evitar este problema es tener un script que retrase el arranque de xdm durante 10 segundos. Una versión previa de esta FAQ decía que debías añadir el terminal virtual usado por las X al archivo /usr/X11R6/lib/X11/xdm/Xservers. Esto no es necesario: las X usarán el primer terminal virtual que encuentre libre. Cuando arranco xconsole obtengo "Couldn't open console". Si arrancas las X con startx, los permisos en /dev/console no serán cambiados, resultando en cosas como que xterm -C y xconsole no funcionen. Esto se debe a la manera en que son fijados los permisos de la consola. En un sistema multiusuario, podemos no querer que cualquier usuario pueda escribir en la consola de sistema. Para usuarios que realizan logins directamente desde una máquina con un VTY, existe el archivo fbtab para resolver estos problemas. Asegúrate de que existe al menos una línea como esta sin comentar: /dev/ttyv0 0600 /dev/console Está en /etc/fbtab y asegurará que cualquiera que realice un login en /dev/ttyv0 será el propietario de la consola. Mi ratón PS/2 no funciona bien en X. Tu ratón y el driver de ratón quizás estén fuera de sincronización. En versiones 2.2.5 y anteriores, conmutando entre sesiones X y sesiones de terminales virtuales, podía provocar una desincronización. Si el problema ocurre muy amenudo, deberías añadir la siguiente opción en el archivo de configuración de tu kernel y recompilarlo. options PSM_CHECKSYNC Mira la sección creando un kernel si no tienes experiencia en compilar nuevos kernels. En versiones 2.2.6 y posteriores, el chequeo de sincronización es realizado de otra manera, y es estándar en el driver de ratón PS/2. Aun así, en casos extraños puedes llegar a ver mensajes de error de sincronización como este: psmintr: out of sync (xxxx != yyyy) y parecer que tu ratón no funciona adecuadamente. Si esto ocurre, desactiva el código de chequeo de sincronización poniendo los flags del driver PS/2 a 0x100. Entra en UserConfig poniendo la opción en el prompt de arranque: boot: -c Entonces, en la línea de comando de UserConfig, teclea: UserConfig> flags psm0 0x100 UserConfig> quit Mi ratón PS/2 de MouseSystems no funciona. Hemos recibido reportes de que algunos modelos de ratones PS/2 de MouseSystems solo trabajan si están configurados en modo "alta resolución". Desafortunadamente no hay solución para versiones 2.0.x y 2.1.x. En versiones 2.2.x, aplica el siguiente parche en /sys/i386/isa/psm.c y compila un nuevo kernel. diff -u psm.c.orig psm.c @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + #if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ En versiones 2.2.6 o posteriores, especifica el flag 0x04 al driver PS/2 para poner el ratón en modo de alta resolución. Entra en UserConfig: boot: -c y en la línea de comandos teclea: UserConfig> flags psm0 0x04 UserConfig> quit Mira en la sección anterior para posibles causas de problemas con los ratones. Cuando compilo una aplicación X. imake no puede encontrar el archivo imake.tmpl. ¿Dónde está? Imake.tmpl es parte del package Imake, una aplicación estándar de compilación de X. Tanto Imake como headers y otros archivos necesarios para compilar aplicaciones X están en la distribución de programación X. Puedes instalarla desde el sysinstall o manualmente desde los archivos de la distribución X. ¿Cómo invierto los botones del ratón? Ejecuta el comando xmodmap -e "pointer = 3 2 1" desde el archivo .xinitrc o .xsession. ¿Cómo instalo un "splash screen" y donde los consigo? Justo antes de la publicación de FreeBSD 3.1 se añadió una nueva característica que permite mostrar "splash screens" durante los mensajes de arranque del sistema. Los "splash screen" deben ser un bitmap de 256 colores (*.BMP) o ZSoft PCX (*.PCX). Además, deben tener una resolución de 320x200 o inferior para poder trabajar en controladoras VGA estándares. Si se compila el soporte VESA en el kernel, se pueden usar bitmaps de hasta 1024x768. Recordar que el soporte de VESA requiere que la opción VM86 sea compilada en el kernel. El soporte actual de VESA puede ser compilado directamente en el kernel con la opción de configuración VESA o cargando el módulo kld VESA durante el arranque. Para usar un "splash screen" necesitas modificar los archivos de inicio que controlan el proceso de arranque de FreeBSD. Estos archivos cambiaron con FreeBSD 3.2, así que ahora existen dos maneras de cargar un "splash screen": FreeBSD 3.1 El primer paso es encontrar una versión bitmap de tu "splash screen". La release 3.1 sólo soporta bitmaps de Windows. Una vez hayas elegido tu "splash screen" copiala en /boot/splash.bmp. A continuación necesitas tener un archivo /boot/loader.rc que contenga las siguientes líneas: load kernel load -t splash_image_data /boot/splash.bmp load splash_bmp autoboot FreeBSD 3.2+ Además de soportar los "splash screens" en formato PCX, FreeBSD 3.2 incluye un mejor sistema de configuración del proceso de arranque. Si quieres, puedes usar el método señalado para FreeBSD 3.1. Si lo haces, y quieres usar PCX, reemplaza splash_bmp con splash_pcx. Si por el contrario quieres usar la nueva configuración de arranque, necesitas crear un archivo /boot/loader.rc que contenga las siguientes líneas: include /boot/loader.4th start y otro archivo /boot/loader.conf que contenga lo siguiente: splash_bmp_load="YES" bitmap_load="YES" Esto asume que estás usando /boot/splash.bmp como tu "splash screen". Si quieres usar un archivo PCX, copialo a /boot/splash.pcx, crea un archivo /boot/loader.rc como se ha indicado anteriormente, y crea un /boot/loader.conf que contenga: splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" Ahora todo lo que necesitas es un "splash screen". Puedes navegar por una inmejorable galería en http://www.cslab.vt.edu/~jobaldwi/splash/. Networking ¿Dónde puedo encontrar información sobre "diskless booting"? "Diskless booting" significa que una máquina FreeBSD sea arrancada sobre una red, y lea los archivos necesarios de un servidor y no desde su disco duro. Para más detalles, por favor, lee la sección diskless booting del manual ¿Puede una máquina FreeBSD ser usada como router dedicado? Los estándares de Internet y las buenas prácticas de ingeniería nos prohiben proveer el forward de paquetes en la distribución estándar. Aun así, puedes activar esta opción cambiando la siguiente variable a YES en el archivo rc.conf: gateway_enable=YES # Set to YES if this host will be a gateway Esta opción pondrá la variable sysctl net.inet.ip.forwarding a 1. En muchos casos también necesitarás ejecutar un proceso de rutado para indicar la existencia en la red de tu router; FreeBSD incluye el daemon estándar de rutado BSD routed, aunque en situaciones más complejas quizás quieras usar GaTeD disponible en http://www.gated.org/ Es nuestro deber advertirte que estando FreeBSD configurado de esta manera, no cumple completamente con todos los estandares de routers de Internet, pero es suficiente para uso ordinario. ¿Puedo conectar mi Win95 con Internet a través de FreeBSD? Típicamente, la gente que pregunta esto tiene dos pc's en casa, uno con FreeBSD y otro con Win95; la idea es usar FreeBSD para conectar a Internet y luego ser capaz de acceder a Internet desde el computador con Windows 95. Este es realmente un caso especial de la pregunta anterior. Hay un útil documento disponible que explica como configurar FreeBSD como un Router PPP NOTA: Esto requiere, al menos, tener dos direcciones IP fijas disponibles, y posiblemente tres o más, dependiendo del número de máquinas que quieras conectar. Como alternativa, si no tienes una dirección IP fija, puedes usar una de las subredes privadas e instalar un proxy como SQUID y The TIS firewall toolkit en tu FreeBSD. Mira también la sección natd. ¿Por que falla la compilación del último BIND del ISC? Hay un conflicto entre el archivo cdefs.h incluido en la distribución de BIND y el distribuido con FreeBSD. Solo tienes que borrar compat/include/sys/cdefs.h. ¿Soporta FreeBSD SLIP y PPP? Sí. Mira las paginas man de slattach, sliplogin, pppd y ppp. pppd y ppp soportan conexiones entrantes y salientes. Sliplogin trabaja exclusivamente con conexiones entrantes y slattach con conexiones salientes. Estos programas son descritos en las siguientes secciones del manual: Handbook entry on SLIP (server side) Handbook entry on SLIP (client side) Handbook entry on PPP (kernel version) Handbook entry on PPP (user-mode version) Si solo tienes acceso a Internet a traves de un "shell account", quizás quieras mirar el package slirp. Puede darte un (limitado) acceso a servicios como ftp y http. ¿Soporta FreeBSD NAT o Masquerading? Si tienes una red local (una o más máquinas), pero solo se te ha asignado una única dirección IP desde tu proveedor de Internet (o si recibes las direcciones de manera dinámica), te interesa mirar el programa natd. Natd te permite conectar una red entera a Internet usando solamente una dirección IP. El programa ppp tiene una funcionalidad similar incluida, a través del parámetro -alias. La librería alias es usada en ambos casos. No puedo crear el dispositivo /dev/ed0! En el sistema de trabajo de red de Berkeley, los interfaces de red solo son directamente accesibles por el código del kernel. Por favor, mira el archivo /etc/rc.network y los man de los programas de red allí mencionados. Si esto te deja totalmente confundido, entonces tendrías que conseguir algun libro de administración de red de cualquier sistema operativo basado en BSD; con algunas excepciones significativas, administrar el sistema de red en FreeBSD es básicamente igual que en SunOS 4.0 o Ultrix. ¿Cómo puedo configurar alias de ethernets? Añade ``netmask 0xffffffff'' en el comando ifconfig como el siguiente: ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff ¿Cómo hago para usar el otro puerto de una 3C503? Si quieres usar los otros puertos, tendrás que especificar parámetros adicionales en el comando ifconfig. El puerto por defecto es link0. Para usar el puerto AUI en lugar del BSN, usa link2. Estos flags tendrían que ser especificados usando las variable ifconfig_* en el archivo /etc/rc.conf. Tengo problemas con NFS desde/hacia FreeBSD. Algunas tarjetas de red son mejores que otras y algunas veces pueden causar problemas con aplicaciones de uso intensivo de red como NFS Mira la entrada en el manual de NFS para más información sobre este tema. ¿Porqué no puedo hacer NFS-mount desde Linux? Algunas versiones de NFS para Linux solo aceptan peticiones para montar unidades hechas desde un puerto privilegiado; intenta: mount -o -P linuxbox:/blah /mnt ¿Porqué no puedo hacer NFS-mount desde una Sun? Las estaciones de trabajo Sun con SunOS 4.x solo aceptan peticiones de montar unidades hechas desde puertos privilegiados; intenta mount -o -P sunbox:/blah /mnt Tengo problemas usando ppp contra máquinas NeXTStep. Intenta desactivar las extensiones TCP en url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> cambiando la siguiente variable a NO: tcp_extensions=NO Las máquinas Xylogic's Annex también tienen este problema, por lo que tienes que hacer el mismo cambio para conectar con ellas. ¿Cómo activo soporte de IP multicast? Las operaciones multicast están totalmente soportadas en FreeBSD 2.0 y superiores. Si quieres usar tu máquina como router multicast, necesitarás cargar el módulo de kernel ip_mrouted_mod y ejecutar el programa mrouted. Para más información: Producto Descripcion Donde --------------- ----------------------- --------------------------------------- faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt imm/immserv IMage Multicast ftp.hawaii.edu:/paccom/imm.src.tar.Z for jpg/gif images. nv Network Video. ftp.parc.xerox.com: /pub/net-reseach/exp/nv3.3alpha.tar.Z vat LBL Visual Audio Tool. ftp.ee.lbl.gov: /conferencing/vat/i386-vat.tar.Z wb LBL White Board. ftp.ee.lbl.gov: /conferencing/wb/i386-wb.tar.Z mmcc MultiMedia Conference ftp.isi.edu: Control program /confctrl/mmcc/mmcc-intel.tar.Z rtpqual Tools for testing the ftp.psc.edu:/pub/net_tools/rtpqual.c quality of RTP packets. vat_nv_record Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z and nv. ¿Qué tarjetas de red están basadas en el chipset DEC PCI? Aquí tienes una lista hecha por Glen Foster: Fabricante Modelo ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Zynx ZX342 ¿Porqué tengo que usar el FQDN para hosts en mi servidor? Probablemente el host estará en un dominio diferente; por ejemplo, si estás en el dominio foo.bar.edu y quieres encontrar un host llamado "mumble" en el dominio bar.edu, tendrás que llamarlo por su nombre de dominio, "mumble.bar.edu", en vez de solo "mumble". Tradicionalmente, esto era permitido por los resolvers BIND BSD. La versión actual de bind que se incluye en FreeBSD no resuelve abreviaciones de nombres para hosts fuera de nuestro dominio. ``Permission denied'' para todas las operaciones de red. Si tienes el kernel compilado con la opción IPFIREWALL . debes tener en cuenta que la política por defecto es denegar explícitamente todos los paquetes que no están explícitamente permitidos. Si involuntariamente has desconfigurado el firewall de tu sistema, puedes restaurar la operatibilidad de la red tecleando el siguiente comando como usuario root: ipfw add 65534 allow all from any to any Para más información en la configuración del firewall de FreeBSD, mira la sección del manual. ¿Cuanto tiempo retrasa IPFW el tráfico? Esta respuesta depende mucho en las reglas definidas y en la versión del procesador. Para la mayoría de aplicaciones que tienen que ver con la ethernet y pequeñas reglas, la respuesta es, prácticamente nada. Aquí tienes una lista de cosas a tener en cuenta para crear reglas de filtrado eficientes: Poner una regla "established" al inicio para manejar la mayoría de trafico TCP. No pongas ninguna regla allow tcp antes de esta. Pon las reglas más usadas antes de las menos usadas (sin modificar la permisividad del firewall). Puedes ver cuales son las reglas más usadas examinando los contadores de paquetes con la orden ipfw -a l. ¿Cómo puedo redirigir peticiones de una máquina a otra? Puedes redirigir peticiones FTP (y otros servicios) con el package "socket", disponible en la colección de ports categoría "sysutils". Simplemente tienes que reemplazar la línea del servicio correspondiente en el archivo /etc/services de la siguiente manera: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp donde "ftp.foo.com" y "ftp" son la máquina y puerto de destino. ¿Dónde puedo conseguir una herramienta de control de ancho de banda?. Existen dos herramientas de control de ancho de banda para FreeBSD. ALTQ es gratis; Bandwidth Manager de Emerging Technologies es un producto comercial. ¿Porqué aparece "/dev/bpf0: device not configured"? El driver Berkeley Packet Filter (bpf) necesita ser activado para ejecutar programas que lo utilizan. Añade esto al archivo de configuración de tu kernel y crea uno nuevo: pseudo-device bpfilter # Berkeley Packet Filter A continuación, después de rearrancar tendrás el dispositivo. Esto puede hacerse entrando en el directorio /dev y ejecutando el siguiente comando: # sh MAKEDEV bpf0 Por favor, mira la entrada correspondiente en el handbook para más información sobre la creación de dispositivos. PPP El ppp no funciona. ¿Qué estoy haciendo mal? Primero deberías leer el man de ppp y la sección de PPP del handbook. Activa los logs con el comando set log Phase Chat Connect Carrier lcp ipcp ccp command Este comando debería ser tecleado en el prompt del ppp o incluirse en el archivo de configuración /etc/ppp/ppp.conf (al inicio de la sección default es el mejor lugar). Asegurate que el archivo url="http://www.FreeBSD.org/cgi/man.cgi?syslog.conf" name="/etc/syslog.conf"> contiene las siguientes líneas: !ppp *.* /var/log/ppp.log y que el archivo /var/log/ppp.log existe. Puedes encontrar mucha información sobre lo que está pasando en las conexiones con el archivo de log. Si tu versión de ppp no entiende el comando "set log" deberías bajarte la última versión. Esta compilará sin problemas en FreeBSD 2.1.5 y superiores. Ppp se bloquea al ejecutarlo Esto ocurre normalmente por que no se puede resolver el nombre de la máquina. La mejor manera de solucionar este problema es asegurarse que el sistema use en primer lugar el archivo /etc/hosts para hacer la resolución de nombres. Para ello, basta con editar el archivo /etc/host.conf y poner la línea hosts en primer lugar. A continuación, simplemente hay que añadir una línea para la máquina local en el archivo /etc/hosts. Si no existe una red local, modificar la línea localhost: 127.0.0.1 foo.bar.com foo localhost Añadir otra línea para la máquina local. Consultar las páginas man relevantes para más detalles. Ahora se debería poder ejecutar el siguiente mandato de forma satisfactoria ping -c1 `hostname`. PPP no quiere marcar en modo -auto Primero, asegúrate de tener una ruta por defecto. Ejecutando el comando url="http://www.FreeBSD.org/cgi/man.cgi?netstat"> name="netstat -rn"> deberías ver dos entradas como estas: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 Esto es asumiendo que hayas usado las direcciones del manual, la página man o del archivo de ejemplo ppp.conf.sample. Si no tienes una ruta por defecto, puede ser por que estés usando una versión antigua de ppp que no entiende la palabra HISADDR en el archivo ppp.conf. Si tu versión de ppp es de antes de FreeBSD 2.2.5, cambia la línea add 0 0 HISADDR por otra diciendo add 0 0 10.0.0.2 Otra razón para la inexistencia de la ruta por defecto es que sin darte cuenta hayas creado un default router en el archivo /etc/rc.conf (anteriormente llamado /etc/sysconfig) y hayas omitido la línea delete ALL en el archivo ppp.conf. Si es este el caso vuelve a la sección configuración final del sistema en el handbook. ¿Qué significa "No route to host"? Este error se debe normalmente a la falta de la sección MYADDR: delete ALL add 0 0 HISADDR en el archivo /etc/ppp/ppp.linkup. Esto es solo necesario si tienes una direccion IP dinámica o no sabes la dirección de tu gateway. Si estás usando el modo interactivo, puedes teclear lo siguiente despues de entrar en packet mode: delete ALL add 0 0 HISADDR Pásate por la sección PPP y direcciones IP dinámicas del handbook para más información. Mi conexión se corta pasados 3 minutos El timeout de ppp por defecto es de 3 minutos. Se puede ajustar con la línea: set timeout NNN Donde NNN es el número de segundos de inactividad antes de cerrar la conexión. Si NNN es 0, la conexión no se cerrará nunca por timeout. Es posible poner este comando en el archivo ppp.conf, o teclearla en el prompt del modo interactivo. También es posible ajustarla en cualquier momento mientras la conexión esté activa conectando al socket del servidor ppp usando telnet o pppctl. Leete el man de ppp para más detalles. Mi conexión se corta en situaciones de carga Si tienes la opción Link Quality Reporting (LQR) configurada es posible que demasiados paquetes LQR se pierdan entre tu máquina y el remoto. PPP deduce que la línea es mala y corta la conexión. En versiones anteriores a la 2.2.5 de FreeBSD, LQR estaba activado por defecto. Ahora está desactivado por defecto. LQR puede ser activado con la línea disable lqr Mi conexión se corta en periodos aleatorios Algunas veces, en líneas telefónicas de baja calidad o con mucho ruido, o líneas con la opción de llamada en espera activada, el módem corta la conexión por que piensa (erróneamente) que ha perdido la portadora. Hay una opción en muchos modems para determiar la tolerancia a pérdidas temporales de portadora. En un USR Sportster por ejemplo, esta es medida por el registro S10 en décimas de segundo. Para hacer que tu módem sea más resistente, puedes añadir la siguiente secuencia "send-expect" a la cadena de llamada: set dial "...... ATS10=10 OK ......" Mira en el manual de tu módem para más detalles. No ocurre nada después del mensaje Login OK En versiones anteriores a FreeBSD 2.2.5, una vez estaba la conexión establecida, ppp espera a que el remoto inicie la negociación LCP (Line Control Protocol). Muchos proveedores de Internet no iniciarán la negociación esperando que sea el cliente el que lo haga. Para forzar al ppp a iniciar el LCP, usa la siguiente línea: set openmode active Nota: Normalmente no hay problemas si las dos partes inician la negocioacion LCP, ya que el modo abierto (open mode) está activo por defecto. De todas maneras, la siguiente sección explica cuando pueden haber problemas. Sigo teniendo errores sobre el parámetro magic Ocasionalmente, justo después de la conexión, puedes ver mensajes en el log referentes a "magic number is the same". Algunas veces, estos mensajes son inofensivos, y otras veces uno de los dos extremos finaliza la conexión. Algunas implementaciones de ppp no pueden solucionar este problema, y, aunque parezca que la conexión está establecida, verás repetidas peticiones y aceptaciones de configuración en el archivo de log hasta que una de las dos partes cierra la conexión. Esto ocurre normalmente en servidores con disco lentos que tienen problemas para gestionar eficientemente los puertos serie. También existen informes de problemas en conexiones mediante slip. La razón es que en el tiempo que tarda el servidor en salir del getty y ejecutar el ppp, el cliente manda los paquetes de inicio LCP. Al estar el ECHO todavía activo en el puerto del servidor, el cliente ppp lo único que ve son sus propios paquetes "reflejados" por el servidor. Una parte de la negociación LCP es establecer un número mágico para cada una de los dos extremos de las conexiones para que los "reflejos" puedan ser detectados. El protocolo dice que cuando el remoto intenta negociar el mismo "magic number", se debe enviar un NAK para seleccionar un nuevo "magic number". Durante el periodo de tiempo que el servidor tiene el ECHO activado en el puerto, el cliente ppp envía paquetes LCP, ve que el mismo "magic" vuelve en el paquete reflejado y lo da como no válido (envia NAK). Este todavía ve el paquete reflajado con NAK (lo que significa que el ppp debe cambiar su "magic"). Esto produce un enorme número de cambios de "magic number" que son introducidos en el buffer tty del servidor. Tan pronto como el ppp arranca en el servidor, es bombardeado con cambios de "magic numbers" e inmediatamente decide que ya ha realizado el número suficiente de negociaciones LCP y corta la conexión. Mientras tanto, el cliente, que ya no ve los paquetes reflejados, recibe sin problemas la desconexión del servidor y también cierra la conexión. Esto puede ser resuelto permitiendo que el remoto inicie la negociación, poniendo la siguiente línea en el archivo ppp.conf: set openmode passive Esto indica al ppp que espere a que el servidor comience la negociación LCP. Es posible que algunos servidores nunca inicien la negociación. Si este es el caso, puedes hacer algo como: set openmode active 3 Esto le indica al ppp que sea pasivo durante 3 segundos, y despues comience a enviar peticiones LCP. Si el remoto envía peticiones durante este periodo, ppp responderá inmediatamente sin esperar los 3 segundos establecidos. Las negociaciones LCP continuan hasta que se cierra la conexión Existe actualmente un problema de implementación en ppp en la que no asocia las respuestas LCP, CCP & IPCP con sus peticiones originales. Como resultado, si una implementación ppp es más lenta durante 6 segundos que la remota, la remota enviará dos peticiones de configuración LCP adicionales. Esto es fatal. Considera dos implementaciones, A y B. A empieza a enviar peticiones LCP inmediatamente después de conectar y B tarda 7 segundos en arrancar. Cuando B arranca, A ha enviado 3 peticiones LCP. Estamos asumiendo que la línea tiene el ECHO desactivado, si no, veriamos los problemas de "magic number" descritos en el apartado anterior. B envía un REQ, y a continuación envía un ACK al primer REQ de A. Esto resulta en que A entra en modo OPENED y envía un ACK (el primero) a B. Mientras, B devuelve dos ACKs más en respuesta a los dos REQs adicionales enviados por A antes de que B arrancase .B recibe el primer ACK de A y entra en modo OPENED. A recibe el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro (el cuarto) REQ. Entonces recibe el tercer ACK y entra en modo OPENED. Mientras, B recibe el cuarto REQ de A, produciendo que vuelva de nuevo al estado ACK-SENT y enviando otro (el segundo) REQ y (cuarto) ACK. A recibe el REQ, entra en modo REQ-SENT y envía otro REQ. Inmediatamente recibe el siguiente ACK y entra en OPENED. Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión. La mejor manera de evitar esto es configurar una de las partes de manera pasiva - que es, hacer que una de las partes espere a que la otra comience la negociación. Esto puede realizarse con el comando: set openmode passive Se debe tener cuidado con esta opción. También se puede usar: set stopped N para limitar el número de veces que ppp espera a que el remoto comience la negociación. Alternativamente, puedes user el comando: set openmode active N donde N es el número de segundos que espera antes de empezar la negociación. Mira en el manual para más detalles. Ppp se bloquea al conectar Antes de la versión 2.2.5 era posible que la conexión se corte nada más iniciarse debido a un problema en la negociación de compresión Predictor1. Esto solo pasa si las dos partes intentan negociar con diferentes protocolos de control de compresión (CCP). Este problema ya está corregido, pero si estás usando una versión antigua de ppp, el problema puede solucionarse con la línea disable pred1 Ppp se bloqua al abrir un shell de test Cuando ejecutas el comando shell o !, ppp ejecuta un shell (o si has pasado argumentos, ppp ejecutará esos argumentos). Ppp esperará a que se complete el comando antes de continuar. Si intentas usar la conexión ppp mientras se ejecuta el comando, parecerá que la conexión se ha colgado. Esto es por que ppp está esperando a que se complete la ejecución del comando. Si quieres ejecutar comandos como este, usa el comando !bg en su lugar. Esto ejecutará el comando en background, y ppp continúa sin problemas con la conexión. Ppp sobre un cable null-modem no funciona No hay manera que ppp detecte automáticamente que una conexión directa se ha cortado. Es debido a las líneas que se usan en un cable serie null-modem. Cuando usamos este tipo de conexión, LQR debería estar siempre activada con el comando enable lqr LQR es aceptado por defecto si es negociado por el remoto. ¿Por que llama sin motivo el ppp en modo -auto? Si ppp llama inesperadamente, debes determinar la causa, y poner filtros (dfilters) para prevenir esas llamadas. Para determinar la causa, usa la siguiente línea: set log +tcp/ip Esto guardara todo el tráfico que pase a través de la conexión. La próxima vez que se realice una llamada no deseada, podrás ver la causa convenientemente guardada. Ahora puedes desactivar las llamadas producidas por esa causa. Usualmente, este tipo de problemas se debe a consultas de DNS. Para prevenir que las consultas de DNS puedan establecer conexiones usa la siguiente línea (esto no hará que los paquetes de DNS queden parados cuando la conexión está establecida): set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 Esto no siempre es aconsejable, ya que puede afectar a la capacidad de realizar conexiones bajo demanda - muchos programas necesitan hacer una consulta al DNS antes de poder realizar cualquier operación. En el caso del DNS, deberías determinar que es lo que está intentando realizar esas consultas de DNS. Muchas veces, sendmail es el culpable. Debes asegurarte configurar el sendmail de manera que no realice ninguna consulta al DNS. Mira la sección Configuracion de correo para tener más detalles acerca de como crear una archivo propio de configuración de sendmail. También deberías añadir la siguiente línea en tu archivo .mc: define(`confDELIVERY_MODE', `d')dnl Esto hara que sendmail encole todo el correo hasta que no se procese la cola (usualmente, sendmail es invocado con "-bd -q30m", indicandole que procese la cola cada 30 minutos) o hasta que se ejecuta el comando "sendmail -q" (por ejemplo, desde el archivo ppp.linup). ¿Qué significan estos errores CCP? Sigo viendo los siguientes errores en el archivo de log: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) Esto es porque ppp está intentando negociar compresión Predictor1, y el remoto no quiere negociar ningún tipo de compresión. Estos mensajes son sin importancia, pero si quieres eliminarlos, puedes desactivar la compresión Predictor1 localmente: disable pred1 PPP se cuelga durante transferencia de archivos con errores I/OP En la versión FreeBSD 2.2.2 y anteriores, había un problema en el driver tun que no permitía paquetes entrantes con un tamaño mayor que el MTU del interface. La recepción de un paquete mayor que el MTU resulta en un error IO que es logueado vía syslogd. La especificación PPP dice que un MRU de 1500 siempre debería ser aceptada como mínimo, a pesar de lo que se negocie mediante LCP, de todas maneras, es posible que hayas disminuido el MTU por debajo de 1500 y tu proveedor te esté enviando paquetes de 1500, haciendo que tu conexión se bloquee. El problema puede solucionarse haciendo que el tamaño del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores. ¿Por que ppp no loguea la velocidad de la conexión? Para loguear todas las líneas de "conversación" de tu módem, debes activar la siguiente opción: set log +connect Esto hará que ppp loguee todo hasta la última cadena "expect" pedida. Si quieres ver la velocidad de tu conexión y usas PAP o CHAP (y por lo tanto no tienes nada que "chatear" después del CONNECT en el script de marcado), debes estar seguro de indicarle al ppp que espera la línea "CONNECT con algo como esto: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de línea, forzando al ppp que lea la respuesta del CONNECT. Ppp ignora el carácter `\' en mi chat script PPP lee cada línea de los archivos de configuración para poder interpretar cadenas como set phone "123 456 789" correctamente. Para especificar un carácter ``"'', debes usar la contrabarra (``\''). Cuando el intérprete lee cada argumento, reinterpreta el argumento para buscar alguna secuencia especial de escape como ``\P'' o ``\T''. Como resultado de esta doble lectura, recuerda que has de usar el número correcto de escapes (contrabarras). Si quieres enviar un caracter ``\'' a tu módem, necesitas hacer algo como: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" resultando en la siguiente secuencia: ATZ OK AT\X OK o set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" resultando en la siguiente secuencia: ATZ OK ATDT1234567 Ppp produce un seg-fault, pero no veo el archivo ppp.core Ppp (o cualquier otro programa de este tipo), nunca deberían hacer un core dump. Por que ppp funciona con un id de usuario 0, el sistema operativo no escribirá la imagen del core en disco. Si ppp termina con errores de "segmentation violation" o cualquier otra señal que normalmente causa un core dumped, y quieres poder hacer un debug de ese core, asegúrate de usar la última versión de ppp, y haz lo siguiente: $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su # make install # chmod 555 /usr/sbin/ppp Ahora tendrás instalada una versión "debuggable" de ppp. Tendrás que ser root para poder ejecutar ppp ya que todos sus privilegios han sido revocados. Cuando arranques ppp, acuerdate del directorio en el que te encuentras. Ahora, cuando ppp recibe una violación de segmentación , creará un archivo core llamado ppp.core. A continuación , deberías hacer lo siguiente: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l ..... Toda esta información puede hacer posible diagnosticar el problema. Si estás familiarizado con gdb, puedes encontrar otras pistas como que causó el dump y las direcciones y valores de las variables más relevantes. El proceso que fuerza una llamada en modo auto nunca funciona Este es un problema conocido cuando ppp está configurado para negociar una IP dinámica local con el remoto. Este problema ha sido solucionado en la última versión - busca en el man la palabra iface. El problema era que cuando el programa inicial llama a connect(2), el IP del interface tun es asignado al punto final del socket. El kernel crea el primer paquete saliente y establece la conexión. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado. Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible :-) La versión actual de ppp hace esto, pero otras muchas implementaciones no. El método más sencillo desde nuestra parte, sería no cambiar nunca la IP del interface tun, pero por el contrario, cambiar todos los paquetes salientes de manera que la ip de origen es cambiada del IP del interface a la IP negociada, instantaneamente. Esto es, esencialmente, lo que hacen libalias(3) y el parámetro de ppp. Otra alternativa (y probablemente la más eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. Ppp debería usar esta llamada para modificar los sockets de todos los programas existentes cuando una nueva dirección IP es negociada. La misma llamada de sistema podría ser usada para clientes dhcp cuando son forzados a rehacer sus sockets. Una tercera opción es permitir que un interface se active sin IP. Los paquetes salientes tendrían un IP de 255.255.255.255 hasta que el primer SIOCAIFADDR ioctl este hecho. Esto permitiría que ppp cambiase el IP de origen, pero solo si el socket es 255.255.255.255 y solo el IP y el checksum necesitan cambiar. Esto, de todas maneras, requiere tocar el kernel para que puede enviar paquetes incorrectos a un interface mal configurado. ¿Porqué muchos juegos no funcionan con el parámetro -alias? La razón por la que muchos de los juegos no funcionan es por que la máquina externa intentará abrir una conexión o enviar paquetes UDP (no solicitados) a la máquina interna. El software "alias" no sabe que esos paquetes debrín enviarse a la máquina interna. Para que las cosas funcionen, asegúrate que la única cosa que está funcionando es el software con el que tienes problemas, entonces ejecuta tcpdump en el interface tun del gateway o ejecuta el log tcp/ip del ppp ("set log +tcp/ip" en el gateway. Cuando arrancas el software que no funciona, deberís ver paquetes que pasan a través del gateway. Cuando algo vuelve del exterior, será rechazado (ese es el problema). Apunta el número de puerto de esos paquetes y cierra el software que no funciona. Haz esto varias veces para comprobar si el número de puerto se repite. Si es así, la siguiente línea en el archivo de configuración del ppp /etc/ppp/ppp.conf hará que las cosas funcionen: alias port proto internalmachine:port port donde "proto" puede ser "tcp" o "udp", "internalmachine" es la máquina a la que quieres que los paquetes sean enviados y "port" es el número de puerto de destino de los paquetes. No podrás usar ese software en otras máquinas sin modificar el comando anterior, y ejecutar el software simultaneamente en dos máquinas internas no será posible - después de todo, el mundo exterior está viendo a toda tu red como una sola máquina. Si los números de puertos no se repiten, hay tres opciones más: 1) Desarrollar el soporte en libalias. Ejemplos de estos "casos especiales" los puedes encontrar en /usr/src/lib/libalias/alias_*.c (alias_ftp.c es un buén prototipo). Esto usualmente supone leer ciertos paquetes salientes conocidos, identificando la instrucción que le indica a la máquina exterior que inicie una conexión con la máquina interna en un puerto específico (aleatorio) y configurar un "ruta" en la tabla de alias para que los paquetes siguientes sepan donde ir. Esta es la solución más difícil, pero es la mejor y hará que el software funcione con múltiples máquinas. 2) Usar un proxy. La aplicación debe soportar socks5 por ejemplo, o (como en el caso del "cvsup") debería tener una opción "pasiva" que evita que el remoto intente abrir conexiones con la maquina local. 3) Redireccionar todo el tráfico a la máquina interna usando "alias addr". Esta es la solución más sencilla. ¿Ha hecho alguien una lista de puertos útiles? Todavía no, pero se podría hacer, si hay interés. En cada ejemplo, internal debe ser reemplazado por la dirección IP de la máquina que va a estar jugando. Quake alias port udp internal:6112 6112 Alternativamente, quizás estés interesado en mirar en el www.battle.netsoporte de Quake a través de proxy">. Quake 2 alias port udp internal:27901 27910 Red Alert alias port udp internal:8675 8675 alias port udp internal:5009 5009 Half Life alias port udp internal:27005 27015 PCAnywhere 8.0 alias port udp internal:5632 5632 alias port tcp internal:5631 5631 ¿Qué son los errores FCS? FCS significa Frame Check Sequence. Cada paquete ppp tiene un checksum añadido para asegurar que los datos que se reciben son los datos que han sido enviados. Si el FCS de un paquete entrante es incorrecto, el paquete es rechazado y se incremente el contador HDLC FCS. Los valores de error HDLC se pueden visualizar usando el comando show hdlc. Si tu conexión es mala (o si tu driver serie está rechazando paquetes), verás errores FCS ocasionales. En general no tienes porque preocuparte de ellos. Si tienes un módem externo, asegúrate que el cable está correctamente aislado de interferencias - esto debería erradicar el problema. Si tu conexión se corta tan pronto como has conectado y ves gran cantidad de errores FCS, puede ser por que ti conexión no es de 8 bits. Asegúrate de que tu módem no está usando control de flujo (XON/XOFF) por software. Si tu conexión de datos debe usar control de flujo por software, usa el comando set accmap 0x000a0000 para indicar al ppp que "escape" los carácteres ^Q y ^S. Otra razón para ver muchos errores FCS puede ser que el remoto haya dejado de "hablar" PPP. Deberís activar el log asíncrono para determinar si los datos entrantes son de un login o un prompt de shell. Si tienes un prompt de shell en el extremo de la conexión, es posible terminar el ppp sin cortar la conexión usando el comando close clp (usando el comando term podrás conectar de nuevo con el shell de la máquina remota. Si no hay nada en el log que indique por que se ha terminado la conexión, deberís preguntar al administrador del sistema remoto porqué ha terminado la sesión. Nada de esto me ayuda - Estoy desesperado ! Si todo falla, envía toda la información que puedas, incluyendo los archivos de configuración, como arrancas el ppp, las partes relevantes del archivo de log y la salida del comando netstat -rn (antes y despues de la conexión) a la lista de distribución FreeBSD-questions@FreeBSD.org, a la lista de FreeBSD en castellano o al grupo de news comp.unix.bsd.FreeBSD.misc y alguien te ayudará a solucionar los problemas. Comunicaciones serie Esta sección responde las preguntas más frecuentes sobre las comunicaciones serie con FreeBSD. PPP y SLIP se tratan en la sección Networking. ¿Cómo se si FreeBSD ha encontrado mis puertos serie? Cuando el kernel de FreeBSD arranca, testeará los puertos serie del sistema que estén configurados en el kernel. Puedes estar atento a los mensajes de la consola o ejecutar el comando: dmesg | grep sio una vez el sistema esté en funcionamiento. Aquí tienes un ejemplo del resultado de la ejecución del comando: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A Esto muestra dos puertos serie. El primero en la irq 4 usando la dirección 0x3f8, y tiene una UART 16550A. El segundo usa el mismo tipo de chip pero está en la irq 3 y usa la dirección 0x2f8. Los módems internos son tratados como puertos serie, exceptuando que siempre tienen un módem adjuntado al puerto. El kernel GENERIC incluye soporte para dos puertos serie usando la misma irq y dirección que en el ejemplo anterior. Si estas opciones no son correctar para tu sistema, o si has añadido módems internos o tienes más puertos serie de los que están configurados en el kernel, solo tienes que reconfigurar el kernel. Mira en la sección about building a kernel para más detalles. ¿Cómo se si FreeBSD ha encontrado mi módem interno? Respondido en la sección anterior. He actualizado a 2.0.5 y mi tty0X no existen! No te preocupes, han sido integrados en los dispositivos ttydX. Tendrás que modificar algunos archivos antiguos de configuración. ¿Cómo accedo a los puertos serie en FreeBSD? El tercer puerto serie, sio2 (conocido como COM3 en DOS), está en /dev/cuaa2 para dispositivos de salida (dial-out) y en /dev/ttyd2 para dispositivos de entrada (dial-in). Cuál es la diferencia entre estas dos clases de dispositivos?. Usas los ttydX para los entrantes. Al abrir /dev/ttydX en "blocking mode", un proceso esperará para que el dispositivo cuaaX correspondiente se vuelva inactivo. Cuando abres un dispositivo cuaaX, se asegura de que el puerto serie no está en uso por un dispositivo ttydX. Si el puerto está disponible, se lo "roba" al dispositivo ttydX. Al mismo tiempo, el dispositivo cuaaXX no se preocupa de la detección de portadora. Con este esquema, y un módem en respuesta automática, puedes recibir usuarios remotos y puedes hacer conexiones externas con el mismo módem, mientras el sistema se preocupa de evitar los posible conflictos. ¿Cómo activo el soporte de tarjetas serie multipuerto? Otra vez, en la sección de configuración del kernel tienes la información. Para una tarjeta multipuerto, pon una línea sio para cada puerto serie de la tarjeta en el archivo de configuración del kernel. Especifica la irq y vector solo en una de las líneas. Todos los puertos de la tarjeta compartirán la misma irq. Por consistencia, usa el último puerto serie para especificar la irq. De la misma manera, especifica la opción COM_MULTIPORT. El siguiente ejemplo es para una tarjeta AST 4-port en la irq 7: options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr Los flags indican que el puerto master tiene un número menor de 7 (0x700), los diagnósticos están activados durante el testeo (0x080), y los puertos comparten una irq (0x001). ¿Puede manejar FreeBSD tarjetas multipuerto compartiendo irq? Todavía no. Tendrás que usar una irq diferente para cada tarjeta. ¿Puedo cambiar los parámetros serie por defecto para un puerto? El dispositivo ttydX (o cuaaX) es el que querrás abrir para tus aplicaciones. Cuando un proceso abre el dispositivo, tendrá una serie de configuraciones I/O por defecto. Puedes ver estas configuraciones con el comando: stty -a -f /dev/ttyd1 Cuando le cambias la configuración a este dispositivo, este cambio se mantiene hasta que el dispositivo se cierra. Cuando se reabre, vuelve a la configuración por defecto. Para hacer cambios sobre la configuración por defecto, puedes abrir y ajustar las opciones del "estado inicial" del dispositivo. Por ejemplo, para poner el dispositivo tty5 en modo CLOCAL, 8 bits, y contro del flujo XON/XOFF, haz stty -f /dev/ttyid5 clocal cs8 ixon ixoff Un buen lugar para hacer esto es en /etc/rc.serial. Ahora, una aplicación tendrá esta configuración por defecto cuando abra el puerto ttyd5. También puedes prevenir o limitar ciertos cambios que pretenda hacer una aplicación. Para ello, ajusta el "lock state" del dispostivo. Por ejemplo, para bloquear la velocidad del puerto ttyd5 a 57600 bps, haz: stty -f /dev/ttyld5 57600 Ahora, una aplicación que abre ttyd5 e intenta cambiar la velocidad del puerto no podrá hacerlo. Naturalmente, deberías hacer que el estado inicial y el estado de bloqueo sean solo de escritura para el usuario root. El script MAKEDEV NO hace esto cuando crea el dispositivo. ¿Cómo puedo activar logins de entrada en mi módem? Quieres hacerte proveedor de Internet, eh?. Primero, necesitarás uno o más módems que puedan responder automáticamente. Tu módem necesitará activar el carrier-detect sólo cuando detecte una portadora y no tenerla activada continuamente. Necesitará cortar la comunicación y resetearse él mismo cuando la línea DTR pase de on a off. Probablemente usaría RTS/CTS para el control de flujo. Finalmente, debe usar una velocidad constante entre el computador y él mismo, pero debería negociar la velocidad entre él mismo y el módem remoto. Para muchos módems compatibles Hayes, este comando creará estas configuraciones y las grabará en la memoria no volátil: AT &C1 &D3 &K3 &Q6 S0=1 &W Mira la sección enviar comandos AT para saber como enviar estas configuraciones al módem sin necesidad de un programa terminal de DOS. A continuación, añade una línea en el archivo /etc/ttys para el módem. Este archivo lista todos los puertos en los que el sistema operativo esperará los logins. La línea sería como esta: ttyd1 "/usr/libexec/getty std.57600" dialup on insecure Esta línea indica que el segundo puerto serie /dev/ttyd1 tiene un módem conectado, la velocidad es de 57600 bps y sin paridad (std.57600. El tipo de terminal para este puerto es "dialup". El puerto está "on" y es inseguro (lo que significa que los logins como root no son permitidos). Muchos usuarios, ponen un sus archivos .profile o .login un prompt para el tipo de terminal. El ejemplo muestra el puerto como inseguro. Para ser root en ese puerto, hacer el login como un usuario normal, y ejecutar el comando su. Si en lugar de inseguro, el terminal es seguro (secure), puedes hacer login como root directamente. Despues de modificar el archivo /etc/ttys, necesitas lanzar una señal HUP al proceso init: kill -HUP 1 Esto fuerza al proceso init a releer el archivo /etc/ttys. El proceso init arrancará los procesos getty en todos los puertos configurados como "on". Puedes ver si los logins están disponibles en los puertos tecleando: ps -ax | grep '[t]tyd1' deberías ver algo como: 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 ¿Cómo puedo conectar un dumb terminal a un FreeBSD? Si estás usando otro computador como terminal en tu sistema FreeBSD, usa un cable null módem entre los dos puertos serie. Si ya estás usando un terminal, mira en las instrucciones del mismo. A continuación, modifica el archivo /etc/ttys Por ejemplo, si estás instalando un terminal WYSE-50 en el quinto puerto serie, usa una línea como esta: ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure Este ejemplo muestra que el puerto /dev/ttyd4 tiene un terminal Wyse50 conectado a 38400 bps sin paridad y los logins de root son permitidos. ¿Porqué no puedo ejecutar tip o cu? En tu sistema, los programas tip y cu son probablemente ejecutables solo por uucp y el grupo dialer. Puedes usar el grupo dialer para controlar quien tiene acceso al módem o sistemas remotos. Sólo tienes que añadirte tu mismo al grupo dialer. Alternativamente, puedes dejar que todos los usuarios de tu sistema ejecuten tip y cu tecleando: # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip Mi módem hayes no está soportado. ¿Que puedo hacer? Actualmente, el man de tip está anticuado. Hay un dialer Hayes genérico. Solo usa ``at=hayes'' en tu archivo /etc/remote. El driver Hayes no es tan desarrollado como para reconocer algunas de las características avanzadas de los módems modernos, mensajes como BUSY, NO DIALTONE o CONNECT 115200 lo pueden confundir. Deberías anular estos mensajes cuando uses tip (utilizando la cadena ATX0&W). También, el timeout de llamada para tip está en 60 segundos. Tu módem debería usar algo menor, o tip puede pensar que hay un problema de comunicación. Intenta con ATS7=45&W. ¿Cómo puedo introducir estos comandos AT? Haz lo que se llama una entrada directa en el archivo /etc/remote. Por ejemplo, si tu módem está conectado al primer puerto serie, /dev/cuaa0, escribe la siguiente línea: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Usa la velocidad más alta que soporte tu módem en la sección br. A continuación teclea tip cuaa0 y estarás conectado al módem. Si no existe el dispositivo /dev/cuaa0 en tu sistema , teclea lo siguiente: # cd /dev # ./MAKEDEV cuaa0 O usa el comando cu como root con los siguientes parámetros: # cu -l``line'' -s``speed'' con line siendo el puerto serie (por ejemplo /dev/cuaa0>) y speed siendo la velocidad (por ejemplo 57600. Cuando termines de entrar los comandos AT, pulsa la tecla . para salir. El símbolo @ no funciona correctamente! El símbolo @ en la opción de números de teléfono indica a tip que busque en el archivo phone(5) un número de teléfono determinado. Pero el símbolo @ es también un carácter especial en otros archivos y opciones como /etc/remote. Pon una contrabarra junto al carácter: pn=\@ ¿Cómo puedo llamar desde la línea de comandos? Pon lo que se llama una entrada genérica en el archivo /etc/remote. Por ejemplo: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: Entonces puedes hacer cosas como tip -115200 5551234. Si prefieres usar cu antes que tip, usa una entrada genérica de cu: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: y teclea ``cu 5551234 -s 115200''. ¿Tengo que teclear la velocidad cada vez que hago esto? Pon una entrada para tip1200 o cu1200, pero puedes usar la velocidad que mejor se amolde a tus necesidades. tip piensa que una buena velocidad por defecto es 1200 bps ya que busca una entrada tip1200. No tienes por que usar 1200 bps. Accedo a diferentes hosts a través de un servidor de terminales. En lugar de esperar a que estés conectado y teclear CONNECT <host> cada vez, usa la opción cm de tip. Por ejemplo, estas entradas en el archivo /etc/remote: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: Esto hará que puedas teclear tip pain o tip muffin para conectarte a las máquinas pain o muffin. ¿Puede tip intentar más de una línea para cada lugar? Este es un problema habitual en universidades con diferentes líneas de módem y unos cientos de usuarios intentado usarlas... Haz una entrada para tu universidad en el archivo /etc/remote y usa <\@> para la opción pn: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Entonces, lista los números de teléfono de la universidad en el archivo /etc/phones: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip intentará cada uno de estos números en el orden en el que estén listados. Si quieres que se realicen reintentos, ejecuta tip en una bucle while. ¿Porqué tengo que teclea CTRL+P dos veces para enviar CTRL+P una vez? CTRL+P es el carácter por defecto de "forzar", usado para indicarle al programa tip que el próximo carácter es un dato literal. Puedes configurar el carácter "forzar" a cualquier otro carácter con el escape ~s, el cual significa "poner una variable". Teclea ~sforce=<single-char> seguido de una nueva línea. <single-char> es cualquier carácter simple. Si dejas libre <single-char> entonces el carácter de forzar es el caracter nul, al cual puedes acceder tecleando CTRL+2 o CTRL+SPACE. Un valor más adecuado para <single-char> es SHIFT+CTRL+6, el cual solo es usado en algunos servidores de terminales. Puedes tener el carácter de forzar donde quieras, especificando lo siguiente en tu archivo $HOME/.tiprc force=<single-char> De repente, todo lo que tecleo es en mayúsculas Has debido pulsar CTRL+A, tip tiene este carácter especial para gente que tenga la tecla caps-lock estropeada. Usa ~s como en la sección anterior y pon la variable "raisechar" a un valor razonable. De hecho, puedes ponerla al mismo valor que que el carácter de forzar, si no esperas usar estas características. Aqui hay un ejemplo del archivo .tiprc perfecto para usuarios de Emacs que necesiten teclear CTRL+2 y CTRL+A muchas veces: force=^^ raisechar=^^ El simbolo ^^ es SHIFT+CTRL+6. ¿Cómo puedo hacer transferecia de archivos con tip? Si estás conectado con otro sistema UNIX, puedes enviar y recibir archivos con ~p (put) y ~t (take). Estos comandos ejecutan cat y echo en el sistema remoto para aceptar y enviar archivos. La sintaxis es: ~p <local-file> [<remote-file>] ~t <remote-file> [<local-file>] No hay chequeo de errores, por lo que es mejor usar otro protocolo como zmodem. ¿Cómo puedo usar zmodem con tip? Primero, instala uno de los programas zmodem de la colección de ports (por ejemplo lrzsz y rzsz). Para recibir archivos, inicia el programa de envío en la parte remota. A continuación, pulsa enter y teclea ~C rz'' (or ``~C lrz'' si instalaste lrzsz) para empezar a recibir localmente. Para enviar archivos, inicia el programa de recepción en la parte remota. A continuación pulsa enter y teclea ~C sz <files>'' (o ~C lsz <files>) para enviarlos al sistema remoto. FreeBSD parece que no puede encontrar mis puertos series aún cuando la configuración es correcta. Las placas bases y tarjetas con UARTs de Acer no son detectadas correctamente por FreeBSD durante la fase de detección serie. Obten un parche de www.lemis.com para solucionar el problema. Preguntas varias FreeBSD usa más espacio de swap que Linux. Porqué? No lo hace. Deberías pensar "Porque mi swap parece lleno?". Si esto es lo que realmente querías decir, es por que poniendo los datos en swap en luar de descartarlos, hace que sea más rápido recuperarlos que si el paginador tuviese que ir a través del sistema de archivos y usar bloques sin modificar desde un ejecutable. La cantidad actual de páginas que puedes tener en el core en una sola vez no es reducida; las páginas sin usar son desplazadas como sea necesario. ¿Porqué usar (que son) a.out y ELF como formatos ejecutables? Para entender por que FreeBSD usa el formato a.out, debes saber primero un poco sobre los tres formatos dominantes actualmente en UNIX: a.out El antiguo y clásico formato de objeto. Usa una corta y compacta cabecera con un número mágico en el inicio que es usado para caracterizar el formato (mira en a.out(5) para más detalles). Contiene tres segmentos cargados: .text, .data y .bss más una tabla de símbolos y una tabla de cadenas de carácteres. COFF El formato de objeto SVR3. La cabecera comprime una sección de tablas, de manera que puedas tener más de una sola sección .test, .data y .bss ELF El sucesor de COFF, ofreciendo múltiples secciones y valores posibles de 32 o 64 bits. Un problema importante: ELF fue diseñado con la presunción de que solo existiría un único ABI por arquitectura de sistema. Esta presunción actualmente es incorrecta, incluso en el mundo comercial (el cual tiene al menos tres ABIs: SVR4, Solaris y SCO). FreeBSD intenta solucionar este problema de manera que provee de una utilidad para marcar un ejecutable ELF con información sobre el ABI con el que es compatible. Para más información, mira el man de brandelf. FreeBSD viene del sistema clásico y tradicionalmente ha utilizado el formato a.out, una tecnología probada y testeada a través de muchas generaciones de releases de BSD. También es posible construir y ejecutar binarios nativos ELF (y kernels) en sistemas FreeBSD. FreeBSD inicialmente se resistió al salto de cambiar a ELF como su formato por defecto. Porqué?, bien, cuando el mundo Linux hizo su transición a ELF no era nada fácil abandonar el formato ejecutable a.out debido a su inflexible mecanismo de tablas basadas en librerías compartidas. Esto hizo muy difícil para los fabricantes y desarrolladores la creación de librerías compartidas. A partir del momento en el que se ofrecieron una serie de herramientas que ofrecían la solución al problema de las librerías compartidas, el coste de la migración fue aceptado como necesario y la transición se hizo. En el caso de FreeBSD, el mecanismo de librerías compartidas esta más basado en el estilo de SunOS, mucho más sencillo de usar. De todas maneras, empezando con la version 3.0, FreeBSD soportará oficialmente binarios ELF como el formato por defecto. Aunque pensamos que el formato ejecutable a.out nos ha servidor muy bién, la gente de GNU, que hacen las herramientas de compilación que usamos, ha dejado de dar soporte para el formato a.out. Esto nos ha forzado a mantener dos versiones divergentes del compilador y lincador. ¿Porqué chmod no puede cambiar los permisos de los links? Tienes que usar o junto con la opción para que funcione. Para más información, mira la página de chmod y de symlink. CUIDADO la opción hace un chmod RECURSIVO. Ten cuidado aal especificar directorios o symlinks con chmod. Si quieres cambiar los permisos de un directorio referenciado por un symlink, usa chmod sin ninguna opción y sigue el symlink con una barra /. Por ejemplo, si foo es un symlink al directorio bar, y quieres cambiar los permisos de foo /actualmente bar), deberías hacer algo como esto: chmod 555 foo/ Con la barra, chmod seguira el symlink, foo, para cambiar los permisos del directorio bar. ¿Porqué están los nombres de usuario restringidos a 8 caracteres? Pensarás que es fácil y suficiente con cambiar UT_NAMESIZE y reconstruir el kernel, y todo volverá a funcionar. Desafortunadamente hay aplicaciones y programas (incluyendo herramientas de sistema) que tienen en el propio código (no siempre 8 o 9, pero si 15 o 20) en estructuras, buffers... y rompería los clientes de NIS de Sun y sin duda existirían otros problemas interactuando con otros sistemas UNIX. En FreeBSD 3.0 y superiores, se ha incrementado el número máxmimo de carácteres a 16 y todas esas utilidades con longitud de carácteres prefijada han sido encontradas y arregladas. El hecho de que este cambio afectase a muchas áreas del sistema es el motivo por el que el cambio no se ha hecho hasta la versión 3.0. Si eres absolutamente cuidadoso y quieres arreglas tu mismo este problema en versiones anteriores, edita el archivo /usr/include/utmp.h y cambia el parámetro UT_NAMESIZE a la longitud que desees. También debes editar el archivo /usr/include/sys/param.h y poner el valor de MAXLOGNAME al mismo que UT_NAMESIZE. Finalmente, recompila los fuentes, no te olvides que el contenido de /usr/include es actualizado cada vez!. En su lugar, cambia los archivos apropiados en /usr/src/.. ¿Puedo ejecutar binarios DOS bajo FreeBSD? Sí, empezando en la versión 3.0 puedes usar la emulación DOS rundos de BSDI, la cual ha sido integrada y mejorada. Envía un mail a la Lista de discusión de emulación en FreeBSD si estás interesado en participar en la evolución de esta característica. Para sistemas pre-3.0 hay una pequeña utilidad llamada pcemu en la colección de puertos que emula un 8088 y suficientes servicios de BIOS para ejecutar aplicaciones de modo texto. Requiere el sistema de X Window. ¿Qué es sup, y como lo uso? SUP significa Software Update Protocol, y fue desarrollado por CMU para mantener sus árboles de desarrollo sincronizados. Nosotros lo usabamos para manterner el servidor central sincronizado con otros servidores remotos. SUP no es amigo del ancho de banda, y ha sido retirado. El método actual recomendado para mantener tus fuentes actualizados es CVSup ¿Existen herramientas de ahorro de energía en FreeBSD? FreeBSD usa la instrucción HLT (halt) cuando el sistema está (idle) para reducir el consumo de energía. Si tienes la opción APM (Automatic Power Management) configurado, FreeBSD puede poner la cpu en modo de baja energía. ¿Qué significa "MFC"? MFC es un acrónimo para "Merges From -CURRENT". Es usado en los logs de CVS para indicar que un cambio se ha migrado de la rama CURRENT a la rama STABLE. ¿Qué significa "BSD"? Pertenece a un lenguaje secreto que solo sus miembros conoces. No tiene traducción literal, pero basta con decir que su traducción está entre, "Equipo de Fórmula-1", "Los Pinguinos son un buén aperitivo", y "Tenermos mejor sentido del humor que Linux" :-) Seriamente, BSD es un acrónimo de "Berkeley Software Distribution", el cual es el nombre que el CSRG de Berkeley (Computer Systems Research Group) escogió para sus distribuciones de Unix. Sólo para hackers serios de FreeBSD ¿Qué son SNAPs y RELEASEs? Hay actualmente tres ramas activas/semi-activas en el desarrollo de FreeBSD y en su CVS Repository: RELENG_2_2 AKA 2.2-stable AKA "2.2 branch" RELENG_3 AKA 3.x-stable AKA "3.0 branch" HEAD AKA AKA 4.0-current HEAD no es una rama actual, como las otras dos, es simplemente una constante simbólica para la versión de desarrollo actual a la cual nos referimos simplemente como . Actualmente, es el desarrollo de la versión 4.0 y la rama 3.0-stable es RELENG_3, separada de -current en Enero de 1999. ¿Cómo puedo hacerme mi propia release personalizada? Para hacer una release necesitas hacer tres cosas: primero, necesitas usar un kernel con el driver vn configurado. Añade esto a tu archivo de configuración del kernel y crea un nuevo kernel: pseudo-device vn #Vnode driver (turns a file into a device) Segundo, debes tener las herramientas del CVS a mano. Para hacer esto, puedes usar CVSUP pero en tu supfile pon el nombre de la release a cvs y borra cualquier tag campo de fecha: *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all A continuación ejecuta cvsup -g supfile para tener todos los bits correctos en tu computador. Finalmente, necesitas una buena cantidad de espacio vacío para crear en el la release. Digamos que está en /algun/disco/grande y en el ejemplo anterior has dejado los archivos del CVS en /home/ncvs: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/algun/disco/grande/release Una release completa será creada en /algun/disco/grande/ y tendrás una instalación completa de tipo FTP en /algun/disco/grande/R/ftp cuando acabes. Si quieres crear tu SNAP usando otra rama de desarrollo diferente de -current, puedes añadir RELEASETAG=SOMETAG a la línea de comando anterior de creación de la release. Por ejemplo, RELEASETAG=RELENG_2_2 crearía un snapshot 2.2 GAMMA. ¿Cómo creo discos de instalación personalizados? El proceso completo de creacación de discos de instalación y archivos fuentes y binarios esta automatizado por varios targets en /usr/src/release/Makefile. La información alli contenida debería ser suficiente para que puedas empezar. Falta decir que este proceso necesita la ejecución del comando "make world" y quizás te use mucho tiempo y espacio en disco. ``make world'' destruye mis binarios instalados. Sí, esta es la idea general; como su nombre sugiere, "make world" rehace todos los binarios del sistema, de manera que puedas estar seguro de tener un entorno limpio y consistente al final (que es por lo que tarda tanto). Si la variable de entorno DESTDIR está definida mientras se ejecuta make world o make install, los binarios creados nuevamente seran depositados en un árbol de directorios idéntico al instalado, y a partir de ${DESTDIR}. Algunas combinaciones aleatorias de modificaciones de librerías compartidas y programas pueden causar que falle el make world. Cuando mi sistema arranca, dice (bus speed defaulted). Las controladoras SCSI Adaptec 1542 permiten al usuario configurar su velocidad de acceso al bus en software. Versiones anteriores del driver de la 1542 intentaban determinar la velocidad más alta factible y configurar la Adaptec a esta. Nos hemos encontrado con que esto hace fallar el sistema de algunos usuarios, por lo que tienes que definir la opción de configuración del kernel TUNE_1542 para que esto ocurra. En algunos sistemas puede que puede hacer que los discos vayan más rápidos, pero en otros puede que los datos queden corrompidos. ¿Puedo seguir la rama current con acceso limitado a Internet? Sí, puedes hacerlo sin bajarte todo el código fuente usando la utilidad CTM. ¿Cómo partir la distribución en archivos de 240k? Los sistemas BSD más modernos tienen una opción para partir que les permite partir los archivos en tamaños arbitrarios. Aqui hay un ejemplo de /usr/src/Makefile. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) ¿He escrito una extensión del kernel, a quien la envío? Por favor, mira en como enviar código. Y gracias por pensar en nosotros! ¿Cómo se detectan e inicializan las tarjetas ISA y PnP? Brevemente, hay unos cuantos puertos de entrada/salida a los que todas las tarjetas PnP responden cuando el computador pregunta si hay alguien ahí. Así, cuando comienza la rutina de prueba de PnP, pregunta si hay alguna tarjeta PnP presente y todas las tarjetas responden con su número de modelo a una lectura I/O del mismo puerto. Así el código de prueba puede conocer el ID de cada tarjeta (asignado por Microsoft/Intel). Los ID's son dos campos de 32 bits (2ˆ64) + 8 bits de checksum. Los primeros 32 bits son el identificador del fabricante. No se ha dicho publicamente, pero parece estar asumido que diferentes tipos de tarjeta del mismo fabricante pueden tener diferentes id's de fabricante. La idea de necesitar 32 bits sólo para los fabricantes parece un poco excesiva. La parte baja de 32 bits son un número de serie, dirección ethernet, algo que haga a la tarjeta única. El fabricante no debe producir nunca una segunda tarjeta que tenga los mismos 32 bits de la parte baja, aunque los 32 bits de la parte alta sean diferentes. Así puedes tener múltiples tarjetas del mismo tipo en la misma máquina y los 64 bits serán únicos para cada tarjeta. Los grupos de 32 bits nunca pueden ser todos cero. Esto permite mostrar todos los bits no-cero durante la búsqueda binaria inicial. Una vez el sistema ha identificado todos los ID's de las tarjetas presentes, reactivaráa cada tarjeta, una tras otra (a través de los mismos puertos I/O), y encontrará los recursos que cada tarjeta necesita, que opciones de interrupción están disponibles, etc. Se realiza un escaneo sobre todas y cada una de las tarjetas presentes para conocer esta información. Esta información se combina con la información de los archivos ECU del disco y con las BIOS MLB. El soporte PnP de ECU y las BIOS para hardware en el MLB usualmente es sintético, y los periféricos no hacen PnP genuino. De todas maneras, examinando la información del BIOS más la información ECU, la rutina de prueba puede causar que los dispositivos que no son PnP puedan evitar a esos dispositivos que el código de prueba no puede volver a posicionar. Así, los dispositivos PnP son visitados una vez más y se les asigna su I/O, DMA, IRQ, direcciones del mapa de memoria. Los dispositivos aparecerán en esas direcciones y permanecerán en ellas hasta que se vuelva a reinicializar la máquina. Todo el proceso se ha simplificado mucho, pero espero que hayas podido hacerte una idea del proceso. ¿Soporta FreeBSD arquitecturas diferentes a x86? Diferentes grupos de personas han expresado su interés en trabajar en un port multi-arquitectura de FreeBSD y FreeBSD/AXP (ALPHA) es un ejemplo de ese esfuerzo realizado, ahora disponible en forma de 3.0 SNAPshot release en ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha. El port de ALPHA funciona actualmente en diferentes tipos de máquinas ALPHA, entre ellas, AlphaStation, AXPpci, PC164, Miata y Multia. Este port todavía no se considera una release completa y no lo será hasta que exista una colección completa de herramientas de instalación y una distribución completa en cdrom para instalació, incluyendo un número razonable de ports y packages funcionales. FreeBSD/AXP debe considerarse software de calidad BETA en estos momentos. Para más información del proyecto, subscríbete a la FreeBSD-alpha@FreeBSD.org lista de correo. También se ha expresado interés en un port de FreeBSD para arquitectura SPARC. Subscríbete a FreeBSD-sparc@FreeBSD.org la lista si estás interesado en participar en el proyecto. Para discusiones generales en nuevas arquitecturas, participa en la lista FreeBSD-platforms@FreeBSD.org. Necesito un numero de dispositivo para un driver propio Esto depende de si quieres hacer que el driver esté públicamente disponible. Si la respuesta es afirmativa, por favor, envianos una copia del código fuente del driver y las modificaciones apropiadas del archivo files.i386, un ejemplo de configuración y el código apropiado de MAKEDEV para crear cualquier archivo especial que use tu dispositivo. Puedes enviar todo lo necesario a FreeBSD-hackers@FreeBSD.org. Alternativas a la política de directorios En respuesta a esta pregunta de políticas alternativas para los directorios, el esquema que está actualmente en uso no ha cambiado desde que lo escribí en 1983. Escribí esa política para el sistema de archivos rápido original, y nunca se ha revisado. Trabaja bién manteniendo los grupos de cilindros. Como muchos de vosotros habreis notado, el rendimiento es muy pobre con "find". Muchos sistemas de archivos son creados desde archivos que fueron creados por una primera búsqueda en profundidad (también conocido como ftw). Estos directorios terminan esparcidos a través de los grupos de cilindros. Si conociesemos el número total de directorios a crear, la solución sería crear (total / fs_ncg) por grupo de cilindros antes de moverlos. Obviamente, tendriamos que crear algún tipo de heurística para adivinar este número. Usando un número pequeño fijo (como puede ser 10) haría de orden de magnitud. Para diferencial restores de operaciones normales (cuando el algoritmo actual es probablemente más sensible), podrís usar el clustering hasta 10 si fueran todos hechos dentro de una ventana de diez segundos. De cualquier manera, mi conclusión es que este es un área para la experimentación. Kirk McKusick, Septiembre 1998 Obtener todo lo posible de un "kernel panic" [Esta sección fue extraida de un mensaje escrito por Bill Paul en la lista FreeBSD-current por Dag-Erling Coïdan Smørgrav, quién a fijado algunos errores y añadido algunos comentarios entre corchetes] From: Bill Paul <wpaul@skynet.ctr.columbia.edu> Subject: Re: the fs fun never stops To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.org [<ben@rosengart.com> envió el siguiente panic] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf014a7e5 ^^^^^^^^^^ > stack pointer = 0x10:0xf4ed6f24 > frame pointer = 0x10:0xf4ed6f28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 80 (mount) > interrupt mask = > trap number = 12 > panic: page fault [Cuando] ves un mensaje como este, no es suficiente con solo reproducirlo y enviarlo. El valor del puntero de instrucciones que he marcado arriba es importante; desafortunadamente, depende de la configuración. En otras palabras, el valor varía dependiendo de la imáden de kernel exacta que se use. Si estás usando el kernel GENERIC de uno de los snapshots, entonces es posible que alguien pueda seguir la función problemática, pero si estás usando un kernel personalizado, entonces solo puedes decirnos donde ha ocurrido el fallo. Tendrías que hacer lo siguiente: Anotar el valor del puntero de la instrucción. Ten en cuenta la parte 0x8: al inicio no es significante en este caso: es la parte 0xf0xxxxxx la que queremos. Cuando el sistema rearranca, haz lo siguiente: % nm /kernel.that.caused.the.panic | grep f0xxxxxx donde f0xxxxxx es el valor del puntero de la instrucción. El problema es que no obtendrás una búsqueda exacta ya que los símbolos en la tabla de símbolos del kernel son para los puntos de entrada de las funciones y la dirección del puntero de la instrucción estará en algún lugar dentro de una función, no al principio. Si no obtienes un resultado exacto, omite el último dígito del valor del puntero de la instrucción e intentalo otra vez, por ejemplo: % nm /kernel.that.caused.the.panic | grep f0xxxxx Si esto no da ningún resultado, elimina otro dígito. Repite la operación hasta que obtengas algún tipo de salida. El resultado será una lista de posibles funciones que causan el panic. Este no es un sistema muy exacto de búsqueda de errores, pero es mejor que nada. Veo gente que constantemente envía mensajes de panics como este, pero raramente veo que alguien se tome el tiempo de buscar la coincidencia entre el puntero de instrucción y una función en la tabla de símbolos del kernel. La mejor manera de hacer el seguimiento de la causa de un panic es capturar un "crash dump", usando gdb(1) para hacer una traza del "crash dump". Por supuesto, esto depende de que gdb(1) funcione correctamente en -current, lo que no puedo garantizar (recuerdo que alguien ha comentado que el nuevo gdb(1) en formato ELF no manejaba bién los "dumps" de un crash del kernel; alguién debería mirar esto antes de que la 3.0 salga del estado beta). En cualquier caso, el método que normalmente uso es este: Crear un archivo de configuración de kernel, opcionalmente añadiendo 'options DDB' si piensas que necesitas el debugger del kernel por algún motivo. (Uso esto principalmente para configurar puntos de salida si sospecho que existe alguna condición que crea un loop infinito). Usar config -g KERNELCONFIG para crear el directorio de configuración del kernel. cd /sys/compile/KERNELCONFIG; make Esperar a que el kernel termine de compilar. cp kernel kernel.debug strip -d kernel mv kernel /kernel.orig/ cp kernel / reboot [Nota: ahora que los kernels de FreeBSD 3.x son ELF por defecto debes usar strip -g en lugar de strip -d. Si por algún motivo tu kernel es aún a.out, usa strip -aout -d.] Ten en cuenta que TU NO QUIERES ARRANCAR CON UN KERNEL QUE TIENE TODOS LOS SIMBOLOS DE DEBUG EN EL. Un kernel compilado con puede llegar facilmente a los 10MB de tamaño. No tienes que arrancar esta imán masiva, solo lo necesitas para poder usar después gdb(1) (gdb(1) quiere la tabla de símbolos). Al contrario, quieres mantener una copia de la imágen completa y crear una segunda imágen con los símbolos de debug desactivados usando strip -d. Es esta segunda imágen la que quieres arrancar. Para asegurarte de capturar un "crash dump", necesitas editar el archivo /etc/rc.conf y apuntar dumpdev a tu partición de swap. Esto hará que el script rc(8) use el comando dumpon(8) para activar los "crash dumps". También puedes ejecutar manualmente dumpon(8). Después de un panic, el "crash dump" puede ser recuperado usando savecore(8); si dumpdev está en /etc/rc.conf, el script rc(8) ejecutará savecore(8) automaticamente y pondrá el "crash dump" en /var/crash. NOTA: los "crash dumps" de FreeBSD suelen tener el mismo tamaño que la cantidad total de memoria física del sistema. Esto significa que si tienes 64MB de RAM, obtendrás un "crash dump" de 64MB. Debido a esto, tienes que asegurarte de tener suficiente espacio libre en /var/crash. Alternativamente puedes ejecutar savecore(8) manualmente y hacer la recuparación en otro directorio donde tengas más espacio libre. Es posible limitar el tamaño del "crash dump" usando options MAXMEM=(foo) para indicar la cantidad de memoria que el kernel puede ocupar. Por ejemplo, si tienes 128MB de RAM, puedes limitar el uso de memoria del kernel a 16MB para que el "crash dump" sea de 16MB y no de 128MB. Una vez hayas recuperado el "crash dump", puedes obtener una traza del stack con gdb(1) de la manera siguiente: % gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where Es posible que aparezcan muchas líneas de información: es una buena idea usar el comando script(1) para capturarlas todas. Usando la imágen del kernel con todos los símbolos de debug deberí mostrar la línea exacta de código fuente del kernel donde ha ocurrido el panic. Normalmente, tienes que leer la traza del stack de abajo hacia arriba para poder conocer la secuencia exacta de eventos que han provocado el crash. También puedes usar gdb(1) para mostrar los contenidos de las diferentes variables o estructuras para examinar el estado del sistema en el momento del crash. Ahora, si eres realmente curioso y tienes un segundo computador, puedes configurar gdb(1) para hacer un debug remoto de manera que puedes usar gdb(1) en un sistema para revisar el kernel de otro sistema, de la misma manera que lo harías en la máquina local. [Bill añade: "Olvidé mencionar una cosa: si tienes DDB activado, puedes forzar un panic (y un crash dump) tecleando "panic" en el prompt del ddb. Es posible que el debugger se pare durante la fase del panic. Si esto ocurre, teclea "continue" y el crash dump finalizará"] dlsym() no funciona con ejecutables ELF! Las herramientas ELF no hacen por defecto que los símbolos definidos en un ejecutable sean visibles por el linker dinámico. Consecuentemente, dlsym() buscará en datos obtenidos desde llamadas a dlopen(NULL, flags), lo que provoca que no se encuentren esos símbolos. Si quieres buscar, usando dlsym() símbolos presentes en el ejecutable principal de un proceso, necesitas linkar el ejecutable usando la opción en el linkador ELF. Incrementando o reduciendo el espacio de direcciones del kernel Por defecto, el espacio de direcciones del kernel es de 256MB en FreeBSD 3.x y 1GB en FreeBSD 4.x. Si gestionas un servidor de red muy cargado (por ejemplo, servidores FTP o HTTP con mucho tráfico), es posible que notes que 256MB no es suficiente. Así que... como incremento el espacio de direcciones?. Hay dos aspectos a tener en cuenta. Primero, necesitas indicarle al kernel que reserve una mayor parte del espacio de direcciones para él mismo. Segundo, ya que el kernel se carga al inicio del espacio de direcciones, necesitas disminuir la dirección de carga. El primer aspecto lo solucionamos incrementando el valor de NKPDE en src/sys/i386/include/pmap.h. Esta es una entrada de ejemplo para 1GB de espacio de direcciones: #ifndef NKPDE #ifdef SMP #define NKPDE 254 /* addressable number of page tables/pde's */ #else #define NKPDE 255 /* addressable number of page tables/pde's */ #endif /* SMP */ #endif Para encontrar el valor correcto de NKPDE, divide el espacio de direcciones deseado (en megabytes) por cuatro, después resta uno por UP y dos por SMP. Para solucionar el segundo aspecto, necesitas calcular la dirección correcta de carga: simplemente resta el tamaño del espacio de direcciones (en bytes) de 0x100100000; el resultado es 0xc0100000 para 1GB de espacio de direcciones. Ajusta LOAD_ADDRESS en src/sys/i386/conf/Makefile.i386 a ese valor; a continuación pon el contador al inicio de la sección listado en src/sys/i386/conf/kernel.script al mismo valor, como sigue: OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(btext) SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-FreeBSDelf/lib); SECTIONS { /* Read-only sections, merged into text segment: */ . = 0xc0100000 + SIZEOF_HEADERS; .interp : { *(.interp) } Reconfigura y compila el kernel. Probablemente tengas problemas con top(1), ps(1) y programas así haciendo un make world deberín solucionarse esos problemas (o una recompilación manual de libkvm, ps y top después de copiar el pmap.h parcheado a /usr/include/vm/. NOTA: el tamaño del espacio de direcciones debe ser un múltiplo de cuatro megabytes. [David Greenman añade: Pienso que el espacio de direcciones del kernel necesita ser una potencia de 2, pero no estoy totalmente seguro.] AGRADECIMIENTOS Si ves algún problema o error en esta FAQ, o quieres enviar información para que sea añadida, por favor, envía un mail a la dirección faq-es@es.FreeBSD.org. Apreciamos tu información e interés, y no podemos hacer una FAQ mejor sin tu ayuda. FreeBSD Spanish Documentation Project. Cristobal Talavera (cristobal@es.FreeBSD.org) Por haber obtenido la libertad :) David Casademunt (david@es.FreeBSD.org) No hay hardware que se le resista. Nik Clayton (nik@FreeBSD.org) Gracias a su ayuda todo esto ha sido posible. Nexus Comunicacaciones (www.ncsa.es) Por mantener el mirror y darme las facilidades para hacer todo esto. Oscar Colet (oscarc@abaforum.es) Por aguantar lo que tiene que aguantar. Jordan Hubbard Actualizaciones y entradas ocasionales. Doug White Recopilaciones y respuestas en FreeBSD-questions. Joerg Wunsch Recopilaciones y respuestas en las news. Garrett Wollman Redes. Jim Lowe Información sobre multicast. Peter da Silva "Machaca de las teclas" de FreeBSD FAQ The FreeBSD Team De todo. y para todos los que hemos olvidado, disculpas y muchas gracias por todo!. Jesús Rodríguez jesusr@FreeBSD.org diff --git a/es_ES.ISO8859-1/books/handbook/book.sgml b/es_ES.ISO8859-1/books/handbook/book.sgml index 99750aadaf..522e414608 100755 --- a/es_ES.ISO8859-1/books/handbook/book.sgml +++ b/es_ES.ISO8859-1/books/handbook/book.sgml @@ -1,358 +1,343 @@ -%man; - - -%bookinfo; - - -%freebsd; - - -%translators; - - %chapters; - -%authors; - -%teams; - %mailing-lists; - %newsgroups; - %trademarks; + +%books.ent; + + +%chapters; %txtfiles; %pgpkeys; ]> Manual de FreeBSD Proyecto de Documentación de FreeBSD Febrero 1999 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 The FreeBSD Documentation Project &bookinfo.legalnotice; &tm-attrib.freebsd; &tm-attrib.3com; &tm-attrib.3ware; &tm-attrib.arm; &tm-attrib.adaptec; &tm-attrib.adobe; &tm-attrib.apple; &tm-attrib.corel; &tm-attrib.creative; &tm-attrib.cvsup; &tm-attrib.heidelberger; &tm-attrib.ibm; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.intuit; &tm-attrib.linux; &tm-attrib.lsilogic; &tm-attrib.m-systems; &tm-attrib.macromedia; &tm-attrib.microsoft; &tm-attrib.netscape; &tm-attrib.nexthop; &tm-attrib.opengroup; &tm-attrib.oracle; &tm-attrib.powerquest; &tm-attrib.realnetworks; &tm-attrib.redhat; &tm-attrib.sap; &tm-attrib.sun; &tm-attrib.symantec; &tm-attrib.themathworks; &tm-attrib.thomson; &tm-attrib.usrobotics; &tm-attrib.vmware; &tm-attrib.waterloomaple; &tm-attrib.wolframresearch; &tm-attrib.xfree86; &tm-attrib.xiph; &tm-attrib.general; ¡Bienvenido a FreeBSD!. Este manual cubre la instalación y uso diario de FreeBSD &rel.current;-RELEASE y FreeBSD &rel2.current;-RELEASE. Este manual está en constante evolución y es el resultado del trabajo de muchas personas. Algunas secciones no están completas y otras necesitan ser actualizadas. Si estás interesado en colaborar en este proyecto, envía un mensaje de correo electrónico a &a.doc;. La última versión de este documento está siempre disponible en el servidor World Wide Web de FreeBSD. También está disponible en diferentes formatos y opciones de compresión en el servidor FTP de FreeBSD o en los numerosos mirrors. Si se prefiere disponer de una copia en papel de este manual, se puede adquirir en FreeBSD Mall. También es posible realizar búsquedas en este manual. Primeros pasos Esta parte del manual de FreeBSD es para usuarios y administradores nuevos en FreeBSD. Estos capítulos: Realizan una introducción a FreeBSD. Guían a través de una instalación de FreeBSD. Explican información básica sobre Unix. Explican como instalar la gran cantidad de software de terceros disponible para FreeBSD. Introducen en el manejo de X Window, el sistema de ventanas de &unix; y detallan como configurar un entorno de escritorio más productivo. Se ha intentado minimizar el número de referencias a otras secciones de este documento para evitar el salto entre páginas y facilitar la lectura continuada. Tareas comunes Ahora que se han cubierto los esquemas básicos, parte del Handbook de FreeBSD cubre algunas de las características más usadas de FreeBSD: Introducción a algunas de las aplicaciones de escritorio: navegadores, herramientas de productividad, visores de documentos, etc. Introducción a algunas de las herramientas multimedia de FreeBSD. Explicación de cómo crear un kernel de FreeBSD personalizado para obtener nuevas funcionalidades en el sistema. Descripción en detalle del sistema de impresión tanto en entornos de escritorio como en impresoras conectadas en red. Cómo ejecutar aplicaciones de Linux en FreeBSD. Algunos de los capítulos recomiendan lecturas de capítulos anteriores, lo que se indica al inicio de cada capítulo. Administración del sistema. Los restantes capítulos de este Manual de FreeBSD cubren todos los aspectos de administración de un sistema FreeBSD. Cada capítulo comienza describiendo lo que será aprendido una vez finalizada la lectura, explicando también los conocimientos mínimos necesarios para un entendimiento satisfactorio. Estos capítulos están diseñados para ser leídos cuando se necesita la información. No es necesario leerlos en un determinado orden ni tampoco es necesario leerlos todos antes de comenzar con el uso de FreeBSD. Comunicaciones en red FreeBSD es uno de los sistemas operativos más usados como servidores en red de alto rendimiento. Los siguientes capítulos cubren: Comunicaciones serie PPP y PPP sobre Ethernet Correo electrónico Servidores de red Otros aspectos avanzados de red Estos capítulos están diseñados para ser leidos cuando sea necesario. No tienen porque leerse en un determinado orden o leerlos todos antes de poder usar FreeBSD en un entorno de red. Apéndices &chap.colophon; diff --git a/es_ES.ISO8859-1/share/sgml/articles.ent b/es_ES.ISO8859-1/share/sgml/articles.ent new file mode 100644 index 0000000000..1d8bdf86b5 --- /dev/null +++ b/es_ES.ISO8859-1/share/sgml/articles.ent @@ -0,0 +1,28 @@ + + + +%man; + +%freebsd; + +%authors; + +%teams; + +%mailing-lists; + +%es-mailing-lists; + +%newsgroups; + +%trademarks; + +%translators; + +%l10n; + +%l10n-common; + +%urls; diff --git a/es_ES.ISO8859-1/share/sgml/authors.ent b/es_ES.ISO8859-1/share/sgml/authors.ent deleted file mode 100644 index 1cdfffacf5..0000000000 --- a/es_ES.ISO8859-1/share/sgml/authors.ent +++ /dev/null @@ -1,885 +0,0 @@ - - -abial@FreeBSD.org"> - -ache@FreeBSD.org"> - -adam@FreeBSD.org"> - -adamw@FreeBSD.org"> - -ade@FreeBSD.org"> - -adrian@FreeBSD.org"> - -akiyama@FreeBSD.org"> - -alane@FreeBSD.org"> - -alc@FreeBSD.org"> - -ale@FreeBSD.org"> - -alex@FreeBSD.org"> - -alfred@FreeBSD.org"> - -ambrisko@FreeBSD.org"> - -amorita@FreeBSD.org"> - -amurai@FreeBSD.org"> - -anders@FreeBSD.org"> - -andre@FreeBSD.org"> - -andreas@FreeBSD.org"> - -andy@FreeBSD.org"> - -anholt@FreeBSD.org"> - -archie@FreeBSD.org"> - -arr@FreeBSD.org"> - -arun@FreeBSD.org"> - -arved@FreeBSD.org"> - -asami@FreeBSD.org"> - -asmodai@FreeBSD.org"> - -assar@FreeBSD.org"> - -awebster@pubnix.net"> - -babkin@FreeBSD.org"> - -bbraun@FreeBSD.org"> - -bde@FreeBSD.org"> - -bean@FreeBSD.org"> - -ben@FreeBSD.org"> - -benno@FreeBSD.org"> - -billf@FreeBSD.org"> - -blackend@FreeBSD.org"> - -bland@FreeBSD.org"> - -bmah@FreeBSD.org"> - -bmilekic@FreeBSD.org"> - -bms@FreeBSD.org"> - -bp@FreeBSD.org"> - -brandon@FreeBSD.org"> - -brian@FreeBSD.org"> - -brooks@FreeBSD.org"> - -brueffer@FreeBSD.org"> - -bsd@FreeBSD.org"> - -bz@FreeBSD.org"> - -cawimm@FreeBSD.org"> - -ceri@FreeBSD.org"> - -cg@FreeBSD.org"> - -charnier@FreeBSD.org"> - -chern@FreeBSD.org"> - -chm@FreeBSD.org"> - -chris@FreeBSD.org"> - -chuckr@FreeBSD.org"> - -cjc@FreeBSD.org"> - -cjh@FreeBSD.org"> - -clement@FreeBSD.org"> - -clive@FreeBSD.org"> - -clsung@FreeBSD.org"> - -cognet@FreeBSD.org"> - -cokane@FreeBSD.org"> - -cp@FreeBSD.org"> - -cperciva@FreeBSD.org"> - -cpiazza@FreeBSD.org"> - -cracauer@FreeBSD.org"> - -csgr@FreeBSD.org"> - -cshumway@FreeBSD.org"> - -csjp@FreeBSD.org"> - -cwt@FreeBSD.org"> - -cy@FreeBSD.org"> - -daichi@FreeBSD.org"> - -dan@FreeBSD.org"> - -danfe@FreeBSD.org"> - -danny@FreeBSD.org"> - -dannyboy@FreeBSD.org"> - -darrenr@FreeBSD.org"> - -das@FreeBSD.org"> - -davidc@FreeBSD.org"> - -davidn@FreeBSD.org"> - -davidxu@FreeBSD.org"> - -dbaker@FreeBSD.org"> - -dburr@FreeBSD.org"> - -dcs@FreeBSD.org"> - -dd@FreeBSD.org"> - -dds@FreeBSD.org"> - -dec@FreeBSD.org"> - -deischen@FreeBSD.org"> - -delphij@FreeBSD.org"> - -demon@FreeBSD.org"> - -den@FreeBSD.org"> - -des@FreeBSD.org"> - -dfr@FreeBSD.org"> - -dg@FreeBSD.org"> - -dhartmei@FreeBSD.org"> - -dhw@FreeBSD.org"> - -dick@FreeBSD.org"> - -dillon@FreeBSD.org"> - -dima@FreeBSD.org"> - -dinoex@FreeBSD.org"> - -dirk@FreeBSD.org"> - -dmlb@FreeBSD.org"> - -DougB@FreeBSD.org"> - -dt@FreeBSD.org"> - -dufault@FreeBSD.org"> - -dwcjr@FreeBSD.org"> - -dwhite@FreeBSD.org"> - -dwmalone@FreeBSD.org"> - -edwin@FreeBSD.org"> - -eik@FreeBSD.org"> - -eivind@FreeBSD.org"> - -ejc@FreeBSD.org"> - -emax@FreeBSD.org"> - -emoore@FreeBSD.org"> - -eric@FreeBSD.org"> - -erich@FreeBSD.org"> - -erwin@FreeBSD.org"> - -fanf@FreeBSD.org"> - -fenner@FreeBSD.org"> - -fjoe@FreeBSD.org"> - -flathill@FreeBSD.org"> - -foxfair@FreeBSD.org"> - -fsmp@FreeBSD.org"> - -furuta@FreeBSD.org"> - -gad@FreeBSD.org"> - -gallatin@FreeBSD.org"> - -gerald@FreeBSD.org"> - -ghelmer@FreeBSD.org"> - -gibbs@FreeBSD.org"> - -gioria@FreeBSD.org"> - -gj@FreeBSD.org"> - -glebius@FreeBSD.org"> - -glewis@FreeBSD.org"> - -gordon@FreeBSD.org"> - -gpalmer@FreeBSD.org"> - -graichen@FreeBSD.org"> - -green@FreeBSD.org"> - -grehan@FreeBSD.org"> - -greid@FreeBSD.org"> - -grog@FreeBSD.org"> - -groudier@FreeBSD.org"> - -gryphon@FreeBSD.org"> - -gshapiro@FreeBSD.org"> - -gsutter@FreeBSD.org"> - -guido@FreeBSD.org"> - -hanai@FreeBSD.org"> - -harti@FreeBSD.org"> - -helbig@FreeBSD.org"> - -hm@FreeBSD.org"> - -hmp@FreeBSD.org"> - -hoek@FreeBSD.org"> - -horikawa@FreeBSD.org"> - -hosokawa@FreeBSD.org"> - -hq@FreeBSD.org"> - -hrs@FreeBSD.org"> - -hsu@FreeBSD.org"> - -iedowse@FreeBSD.org"> - -ijliao@FreeBSD.org"> - -ikob@FreeBSD.org"> - -imp@FreeBSD.org"> - -imura@FreeBSD.org"> - -issei@FreeBSD.org"> - -itojun@itojun.org"> - -iwasaki@FreeBSD.org"> - -jake@FreeBSD.org"> - -jasone@FreeBSD.org"> - -jayanth@FreeBSD.org"> - -jb@FreeBSD.org"> - -jdp@FreeBSD.org"> - -jedgar@FreeBSD.org"> - -jeff@FreeBSD.org"> - -jeh@FreeBSD.org"> - -jehamby@FreeBSD.org"> - -jennifer@FreeBSD.org"> - -jesper@FreeBSD.org"> - -jesusr@FreeBSD.org"> - -jfieber@FreeBSD.org"> - -jfitz@FreeBSD.org"> - -jgreco@FreeBSD.org"> - -jhay@FreeBSD.org"> - -jhb@FreeBSD.org"> - -jhs@FreeBSD.org"> - -jim@FreeBSD.org"> - -jkh@FreeBSD.org"> - -jkoshy@FreeBSD.org"> - -jlemon@FreeBSD.org"> - -jlrobin@FreeBSD.org"> - -jmacd@FreeBSD.org"> - -jmallett@FreeBSD.org"> - -jmas@FreeBSD.org"> - -jmb@FreeBSD.org"> - -jmg@FreeBSD.org"> - -jmz@FreeBSD.org"> - -joe@FreeBSD.org"> - -joerg@FreeBSD.org"> - -johan@FreeBSD.org"> - -john@FreeBSD.org"> - -jon@FreeBSD.org"> - -josef@FreeBSD.org"> - -jseger@FreeBSD.org"> - -julian@FreeBSD.org"> - -jvh@FreeBSD.org"> - -jwd@FreeBSD.org"> - -kan@FreeBSD.org"> - -karl@FreeBSD.org"> - -kato@FreeBSD.org"> - -kbyanc@FreeBSD.org"> - -keichii@FreeBSD.org"> - -keith@FreeBSD.org"> - -ken@FreeBSD.org"> - -kensmith@FreeBSD.org"> - -keramida@FreeBSD.org"> - -kevlo@FreeBSD.org"> - -kientzle@FreeBSD.org"> - -kiri@FreeBSD.org"> - -kjc@FreeBSD.org"> - -knu@FreeBSD.org"> - -krion@FreeBSD.org"> - -kris@FreeBSD.org"> - -kuriyama@FreeBSD.org"> - -kwm@FreeBSD.org"> - -lars@FreeBSD.org"> - -le@FreeBSD.org"> - -leeym@FreeBSD.org"> - -lesi@FreeBSD.org"> - -lev@FreeBSD.org"> - -lile@FreeBSD.org"> - -linimon@FreeBSD.org"> - -lioux@FreeBSD.org"> - -ljo@FreeBSD.org"> - -lkoeller@FreeBSD.org"> - -lofi@FreeBSD.org"> - -logo@FreeBSD.org"> - -lth@FreeBSD.org"> - -luigi@FreeBSD.org"> - -luoqi@FreeBSD.org"> - -maho@FreeBSD.org"> - -marcel@FreeBSD.org"> - -marck@FreeBSD.org"> - -marcus@FreeBSD.org"> - -marius@FreeBSD.org"> - -markm@FreeBSD.org"> - -marko@FreeBSD.org"> - -markp@FreeBSD.org"> - -marks@FreeBSD.org"> - -markus@FreeBSD.org"> - -martin@FreeBSD.org"> - -mat@FreeBSD.org"> - -matk@FreeBSD.org"> - -matusita@FreeBSD.org"> - -max@FreeBSD.org"> - -maxim@FreeBSD.org"> - -mb@FreeBSD.org"> - -mbarkah@FreeBSD.org"> - -mbr@FreeBSD.org"> - -mckay@FreeBSD.org"> - -mckusick@FreeBSD.org"> - -mdodd@FreeBSD.org"> - -metal@FreeBSD.org"> - -mezz@FreeBSD.org"> - -mharo@FreeBSD.org"> - -mheinen@FreeBSD.org"> - -mi@FreeBSD.org"> - -mich@FreeBSD.org"> - -mike@FreeBSD.org"> - -mikeh@FreeBSD.org"> - -mini@FreeBSD.org"> - -mita@FreeBSD.org"> - -mjacob@FreeBSD.org"> - -mks@FreeBSD.org"> - -mlaier@FreeBSD.org"> - -motoyuki@FreeBSD.org"> - -mp@FreeBSD.org"> - -mph@FreeBSD.org"> - -mpp@FreeBSD.org"> - -mr@FreeBSD.org"> - -msmith@FreeBSD.org"> - -mtaylor@FreeBSD.org"> - -mtm@FreeBSD.org"> - -murray@FreeBSD.org"> - -mux@FreeBSD.org"> - -mwlucas@FreeBSD.org"> - -naddy@FreeBSD.org"> - -nakai@FreeBSD.org"> - -nate@FreeBSD.org"> - -nbm@FreeBSD.org"> - -nectar@FreeBSD.org"> - -netchild@FreeBSD.org"> - -newton@FreeBSD.org"> - -n_hibma@FreeBSD.org"> - -nik@FreeBSD.org"> - -niklas@FreeBSD.org"> - -njl@FreeBSD.org"> - -nobutaka@FreeBSD.org"> - -non@FreeBSD.org"> - -nork@FreeBSD.org"> - -nsayer@FreeBSD.org"> - -nsouch@FreeBSD.org"> - -nyan@FreeBSD.org"> - -obraun@FreeBSD.org"> - -obrien@FreeBSD.org"> - -okazaki@FreeBSD.org"> - -olgeni@FreeBSD.org"> - -oliver@FreeBSD.org"> - -onoe@FreeBSD.org"> - -orion@FreeBSD.org"> - -osa@FreeBSD.org"> - -pat@FreeBSD.org"> - -patrick@FreeBSD.org"> - -paul@FreeBSD.org"> - -pav@FreeBSD.org"> - -pb@FreeBSD.org"> - -pdeuskar@FreeBSD.org"> - -pds@FreeBSD.org"> - -peadar@FreeBSD.org"> - -perky@FreeBSD.org"> - -petef@FreeBSD.org"> - -peter@FreeBSD.org"> - -phantom@FreeBSD.org"> - -philip@FreeBSD.org"> - -phk@FreeBSD.org"> - -pho@FreeBSD.org"> - -piero@FreeBSD.org"> - -pirzyk@FreeBSD.org"> - -pjd@FreeBSD.org"> - -proven@FreeBSD.org"> - -ps@FreeBSD.org"> - -pst@FreeBSD.org"> - -rees@FreeBSD.org"> - -reg@FreeBSD.org"> - -rgrimes@FreeBSD.org"> - -ricardag@FreeBSD.org"> - -rich@FreeBSD.org"> - -rik@FreeBSD.org"> - -rnordier@FreeBSD.org"> - -roam@FreeBSD.org"> - -robert@FreeBSD.org"> - -roberto@FreeBSD.org"> - -roger@FreeBSD.org"> - -rpratt@FreeBSD.org"> - -rse@FreeBSD.org"> - -rsm@FreeBSD.org"> - -ru@FreeBSD.org"> - -rushani@FreeBSD.org"> - -rv@FreeBSD.org"> - -rvb@FreeBSD.org"> - -rwatson@FreeBSD.org"> - -sada@FreeBSD.org"> - -sam@FreeBSD.org"> - -sanpei@FreeBSD.org"> - -schweikh@FreeBSD.org"> - -scop@FreeBSD.org"> - -scottl@FreeBSD.org"> - -scrappy@FreeBSD.org"> - -se@FreeBSD.org"> - -seanc@FreeBSD.org"> - -sef@FreeBSD.org"> - -sem@FreeBSD.org"> - -semenu@FreeBSD.org"> - -sergei@FreeBSD.org"> - -sf@FreeBSD.org"> - -shafeeq@FreeBSD.org"> - -sheldonh@FreeBSD.org"> - -shiba@FreeBSD.org"> - -shige@FreeBSD.org"> - -shin@FreeBSD.org"> - -silby@FreeBSD.org"> - -simokawa@FreeBSD.org"> - -simon@FreeBSD.org"> - -skv@FreeBSD.org"> - -smace@FreeBSD.org"> - -smkelly@FreeBSD.org"> - -smpatel@FreeBSD.org"> - -sobomax@FreeBSD.org"> - -sos@FreeBSD.org"> - -ssouhlal@FreeBSD.org"> - -adam@redprince.net"> - -stark@FreeBSD.org"> - -stb@FreeBSD.org"> - -stefanf@FreeBSD.org"> - -stephane@FreeBSD.org"> - -steve@FreeBSD.org"> - -sumikawa@FreeBSD.org"> - -suz@FreeBSD.org"> - -swallace@FreeBSD.org"> - -tackerman@FreeBSD.org"> - -takawata@FreeBSD.org"> - -tanimura@FreeBSD.org"> - -taoka@FreeBSD.org"> - -tedm@FreeBSD.org"> - -tegge@FreeBSD.org"> - -tg@FreeBSD.org"> - -thepish@FreeBSD.org"> - -thierry@FreeBSD.org"> - -thomas@FreeBSD.org"> - -ticso@FreeBSD.org"> - -tjr@FreeBSD.org"> - -tmm@FreeBSD.org"> - -tobez@FreeBSD.org"> - -tom@FreeBSD.org"> - -tomsoft@FreeBSD.org"> - -torstenb@FreeBSD.org"> - -toshi@FreeBSD.org"> - -trevor@FreeBSD.org"> - -trhodes@FreeBSD.org"> - -truckman@FreeBSD.org"> - -tshiozak@FreeBSD.org"> - -uch@FreeBSD.org"> - -ue@FreeBSD.org"> - -ugen@FreeBSD.org"> - -uhclem@FreeBSD.org"> - -ulf@FreeBSD.org"> - -ume@FreeBSD.org"> - -unfurl@FreeBSD.org"> - -vanilla@FreeBSD.org"> - -viny@FreeBSD.org"> - -vkashyap@FreeBSD.org"> - -vs@FreeBSD.org"> - -wes@FreeBSD.org"> - -whiteside@acm.org"> - -wilko@FreeBSD.org"> - -will@FreeBSD.org"> - -wjv@FreeBSD.org"> - -wollman@FreeBSD.org"> - -wosch@FreeBSD.org"> - -wpaul@FreeBSD.org"> - -wsanchez@FreeBSD.org"> - -wylie@magnesium.net"> - -yar@FreeBSD.org"> - -yoichi@FreeBSD.org"> - -yokota@FreeBSD.org"> - -zarzycki@FreeBSD.org"> - -znerd@FreeBSD.org"> - diff --git a/es_ES.ISO8859-1/share/sgml/bookinfo.ent b/es_ES.ISO8859-1/share/sgml/bookinfo.ent index 1992bc7d43..0c3bb325d7 100644 --- a/es_ES.ISO8859-1/share/sgml/bookinfo.ent +++ b/es_ES.ISO8859-1/share/sgml/bookinfo.ent @@ -1,14 +1,19 @@ + + + + diff --git a/es_ES.ISO8859-1/share/sgml/books.ent b/es_ES.ISO8859-1/share/sgml/books.ent new file mode 100644 index 0000000000..b48f726958 --- /dev/null +++ b/es_ES.ISO8859-1/share/sgml/books.ent @@ -0,0 +1,28 @@ + + + +%l10n; + +%l10n-common; + +%man; + +%bookinfo; + +%freebsd; + +%authors; + +%teams; + +%mailing-lists; + +%newsgroups; + +%trademarks; + +%translators; + +%urls; diff --git a/es_ES.ISO8859-1/share/sgml/catalog b/es_ES.ISO8859-1/share/sgml/catalog index 209aa611ff..9095ad7b4d 100644 --- a/es_ES.ISO8859-1/share/sgml/catalog +++ b/es_ES.ISO8859-1/share/sgml/catalog @@ -1,36 +1,45 @@ -- ...................................................................... -- -- FreeBSD SGML Public Identifiers ...................................... -- -- ...................................................................... -- -- Spanish specific ..................................................... -- -- $FreeBSD$ -- $FreeBSDes: doc/es_ES.ISO8859-1/share/sgml/catalog,v 1.5 2004/08/05 17:11:47 carvay Exp $ +PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//ES" + "articles.ent" + +PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Books Entity Set//ES" + "books.ent" + PUBLIC "-//FreeBSD//DOCUMENT DocBook Stylesheet//EN" "freebsd.dsl" PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//ES" "mailing-lists.ent" PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//ES" "bookinfo.ent" PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//ES" "mailing-lists.ent" PUBLIC "-//FreeBSD//DOCUMENT DocBook Stylesheet//ES" "freebsd.dsl" PUBLIC "-//FreeBSD//ENTITIES DocBook Newsgroup Entities//ES" "newsgroups.ent" -PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN" +PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//ES" + "teams.ent" + +PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//ES" "trademarks.ent" PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//ES" "translators.ent" PUBLIC "-//FreeBSD//ENTITIES DocBook Spanish Mailing List Entities//ES" "es-mailing-lists.ent" diff --git a/es_ES.ISO8859-1/share/sgml/mailing-lists.ent b/es_ES.ISO8859-1/share/sgml/mailing-lists.ent index 7f3df87712..80e5c0f03f 100755 --- a/es_ES.ISO8859-1/share/sgml/mailing-lists.ent +++ b/es_ES.ISO8859-1/share/sgml/mailing-lists.ent @@ -1,387 +1,439 @@ + + servidor de listas de FreeBSD"> &a.mailman.listinfo;"> lista de correo sobre ACPI en FreeBSD"> freebsd-acpi"> lista de promoción de FreeBSD"> freebsd-advocacy"> -lista del porte de AFS a FreeBSD"> +lista del port de AFS a FreeBSD"> freebsd-afs"> -lista de discusiones relacionadas con Adaptec AIC7xxx en FreeBSD"> +lista sobre Adaptec AIC7xxx en FreeBSD"> freebsd-aic7xxx"> lista de correo del port de FreeBSD para Alpha"> freebsd-alpha"> -lista del porte de FreeBSD a sistemas AMD64"> +lista del port de FreeBSD a sistemas AMD64"> freebsd-amd64"> -lista de avisos importantes del Proyecto FreeBSD"> +lista de anuncios importantes del Proyecto FreeBSD"> freebsd-announce"> -lista de Apache en FreeBSD"> +lista sobre Apache en FreeBSD"> freebsd-apache"> -lista de arquitectura y diseño de FreeBSD"> +lista sobre arquitectura y diseño de FreeBSD"> freebsd-arch"> -lista del porte de ARM a FreeBSD"> +lista del port de FreeBSD para ARM"> freebsd-arm"> lista de networking ATM en FreeBSD"> freebsd-atm"> lista para la auditoría de código fuente de FreeBSD"> freebsd-audit"> lista del sistema de actualización binaria de FreeBSD"> freebsd-binup"> + +lista de correo sobre Bluetooth en FreeBSD"> +freebsd-bluetooth"> + lista de correo de los bugbusters de FreeBSD"> freebsd-bugbusters"> lista de 'problem reports' de FreeBSD"> freebsd-bugs"> lista de charla de FreeBSD"> freebsd-chat"> lista de 'clustering' en FreeBSD"> freebsd-cluster"> - -lista de correo de herramientas de instalación y configuración de FreeBSD"> -freebsd-config"> - &os.current; lista de correo"> freebsd-current"> avisos CTM"> ctm-announce"> distribución CTM de ficheros CVS"> ctm-cvs-cur"> lista de correo para la distribución CTM de src de la rama 4-STABLE"> ctm-src-4"> lista de correo para la distribución CTM de src de la rama -CURRENT"> ctm-src-cur"> lista de correo para usuarios de CTM"> ctm-users"> -lista de correo de mensajes de committs CVS de FreeBSD"> +lista de correo de mensajes de committs del CVS de FreeBSD"> cvs-all"> -lista de correo de mensajes de committs CVS en la documentación de FreeBSD"> +lista de correo de mensajes de committs del CVS de la documentación de FreeBSD"> cvs-doc"> -lista de correo de mensajes de committs CVS en los ports de FreeBSD"> +lista de correo de mensajes de committs del CVS de los ports de FreeBSD"> cvs-ports"> -lista de correo de committs CVS en el árbol projects de FreeBSD"> +lista de correo de committs del árbol de proyectos del CVS de FreeBSD"> cvs-projects"> -lista de correo de mensajes de committs CVS en el árbol src de FreeBSD"> +lista de correo de mensajes de committs del árbol src del CVS de FreeBSD"> cvs-src"> lista de correo de gestión del CVSweb de FreeBSD"> freebsd-cvsweb"> -lista de correo de bases de datos basadas en FreeBSD"> +lista de correo sobre el uso de desarrollo de bases de datos en FreeBSD"> freebsd-database"> lista de correo del proyecto de documentación de FreeBSD"> freebsd-doc"> - + - + + +lista de correo sobre controladores para FreeBSD"> +freebsd-drivers"> + + +lista de correo para usuarios de Eclipse en FreeBSD"> +freebsd-eclipse"> + + +lista de correo sobre sistemas empotrados y FreeBSD"> +freebsd-embedded"> + lista de correo sobre emulación en FreeBSD"> freebsd-emulation"> + +lista de correo de fechas de fin de soporte"> +freebsd-eol"> + -lista de correo de FireWire (IEEE 1394) en FreeBSD"> +lista de correo sobre FireWire (IEEE 1394) en FreeBSD"> freebsd-firewire"> lista de correo sobre sistemas de ficheros en FreeBSD"> freebsd-fs"> -lista de correo de GEOM en FreeBSD"> +lista de correo sobre GEOM en FreeBSD"> freebsd-geom"> lista de correo sobre GNOME y aplicaciones GNOME en FreeBSD"> freebsd-gnome"> -lista de discusiones técnicas en FreeBSD"> +lista de correo de discusiones técnicas en FreeBSD"> freebsd-hackers"> -lista sobre hardware en FreeBSD"> +lista de correo sobre hardware en FreeBSD"> freebsd-hardware"> -lista de correo de coordinación de las réplicas de FreeBSD "> +lista de correo de correo de las réplicas de FreeBSD "> freebsd-hubs"> lista de correo sobre internacionalización de FreeBSD"> freebsd-i18n"> lista de correo específica sobre i386 y FreeBSD"> freebsd-i386"> -lista de correo del porte de IA32 a FreeBSD"> +lista de correo del port de IA32 para FreeBSD"> freebsd-ia32"> -lista de correo de IA64 a FreeBSD"> +lista de correo del port de IA64 para FreeBSD"> freebsd-ia64"> lista de correo sobre el código de IPFW de FreeBSD"> freebsd-ipfw"> lista de correo sobre RDSI/ISDN en FreeBSD"> freebsd-isdn"> lista de correo de Proveedores de Servicios de Internet en FreeBSD"> freebsd-isp"> lista de correo sobre el Lenguaje Java en FreeBSD"> freebsd-java"> lista de correo sobre empleos relacionados con FreeBSD"> freebsd-jobs"> lista de correo sobre KDE/Qt y aplicaciones KDE en FreeBSD"> freebsd-kde"> -lista de correo sobre el porte de LFS a FreeBSD"> +lista de correo sobre el port de LFS a FreeBSD"> freebsd-lfs"> lista de correo sobre el sistema de instalación y empaquetado libh en FreeBSD"> freebsd-libh"> -lista de correo del porte de FreeBSD para MIPS"> +lista de correo del port de FreeBSD para MIPS"> freebsd-mips"> -lista de coordinación de administradores de réplicas de FreeBSD"> +lista de correo de avisos para administradores de réplicas de FreeBSD"> mirror-announce"> -lista de correo sobre FreeBSD y computadoras portátiles"> +lista de correo sobre FreeBSD y portátiles"> freebsd-mobile"> -lista de correo del porte del navegador Mozilla a FreeBSD"> +lista de correo del port del navegador Mozilla a FreeBSD"> freebsd-mozilla"> lista de correo sobre multimedia en FreeBSD"> freebsd-multimedia"> lista de correo sobre networking en FreeBSD"> freebsd-net"> lista de correo para recién llegados a FreeBSD"> freebsd-newbies"> lista de correo sobre new-bus en FreeBSD"> freebsd-new-bus"> lista de correo sobre OpenOffice.org en FreeBSD"> freebsd-openoffice"> lista de correo sobre rendimiento de FreeBSD"> freebsd-performance"> lista de correo sobre Perl en FreeBSD"> freebsd-perl"> + +lista de correo sobre pf en FreeBSD"> +freebsd-pf"> + lista de correo sobre FreeBSD en plataformas no Intel"> freebsd-platforms"> lista de correo del Core Team para las discusiones sobre líneas maestras de FreeBSD"> freebsd-policy"> -lista de correo de los ports de FreeBSD"> +lista de correo sobre los ports de FreeBSD"> freebsd-ports"> lista de correo sobre errores en los ports de FreeBSD"> freebsd-ports-bugs"> - + - + -lista de correo del porte de FreeBSD a PowerPC"> +lista de correo del port de FreeBSD a PowerPC"> freebsd-ppc"> + +lista de correo de FreeBSD en servidores HP ProLiant"> +freebsd-proliant"> + + +lista de correo sobre Python en FreeBSD"> +freebsd-python"> + lista de correo sobre 'Quality Assurance' en FreeBSD"> freebsd-qa"> lista de correo para preguntas generales sobre FreeBSD"> freebsd-questions"> + +lista de correo sobre los scripts de arranque de FreeBSD"> +freebsd-rc"> + lista de correo sobre extensiones en tiempo real en FreeBSD"> freebsd-realtime"> lista de correo sobre el subsistema SCSI de FreeBSD"> freebsd-scsi"> lista de correo sobre seguridad en FreeBSD"> freebsd-security"> -lista de correo para avisos de seguridad que afectan a FreeBSD"> +lista de correo para anuncios de seguridad que afectan a FreeBSD"> freebsd-security-notifications"> -lista de correo sobre FreeBSD embebido"> +lista de correo sobre sistemas empotrados y FreeBSD"> freebsd-small"> lista de correo sobre multiproceso simétrico en FreeBSD"> freebsd-smp"> -lista de correo del porte de FreeBSD a SPARC"> +lista de correo del port de FreeBSD a SPARC"> freebsd-sparc64"> lista de correo sobre &os.stable;"> freebsd-stable"> -lista de correo sobre la conformidad de FreeBSD a los estándares C99 y POSIX"> +lista de correo sobre la conformidad de FreeBSD con los estándares C99 y POSIX"> freebsd-standards"> + +lista de correo del port de FreeBSD a sun4v"> +freebsd-sun4v"> + lista de correo de pruebas del servidor de listas de FreeBSD"> freebsd-test"> lista de correo sobre pruebas de rendimiento y estabilidad de FreeBSD"> freebsd-testing"> -lista de correo sobre hilos en FreeBSD"> +lista de correo sobre hilos -'threads'- en FreeBSD"> freebsd-threads"> lista de correo sobre tokenring en FreeBSD"> freebsd-tokenring"> + +lista de correo sobre USB en FreeBSD"> +freebsd-usb"> + lista de correo para la coordinación de grupos de usuarios de FreeBSD"> freebsd-user-groups"> lista de correo para la coordinación de pre-releases de los distribuidores de FreeBSD"> freebsd-vendors"> + +lista de correo sobre VuXML en FreeBSD"> +freebsd-vuxml"> + lista de correo de los Webmasters de FreeBSD"> freebsd-www"> lista de correo sobre X11 en FreeBSD"> freebsd-x11"> + + +bug-followup@FreeBSD.org"> + + majordomo@FreeBSD.org"> diff --git a/es_ES.ISO8859-1/share/sgml/teams.ent b/es_ES.ISO8859-1/share/sgml/teams.ent index 29a7ed6228..fd833edc82 100644 --- a/es_ES.ISO8859-1/share/sgml/teams.ent +++ b/es_ES.ISO8859-1/share/sgml/teams.ent @@ -1,42 +1,53 @@ -admins@FreeBSD.org"> + -core-secretary@FreeBSD.org"> +admins@FreeBSD.org"> -cvs@FreeBSD.org"> +core-secretary@FreeBSD.org"> -cvsup-master@FreeBSD.org"> +cvsadm@FreeBSD.org"> -doceng@FreeBSD.org"> +cvsup-master@FreeBSD.org"> -donations@FreeBSD.org"> +dcvs@FreeBSD.org"> -faq@FreeBSD.org"> +doceng@FreeBSD.org"> -ftp-master@FreeBSD.org"> +donations@FreeBSD.org"> -mirror-admin@FreeBSD.org"> +faq@FreeBSD.org"> -portmgr@FreeBSD.org"> +ftp-master@FreeBSD.org"> -re@FreeBSD.org"> +mirror-admin@FreeBSD.org"> -security-officer@FreeBSD.org"> +ncvs@FreeBSD.org"> -www@FreeBSD.org"> +perforce-admin@FreeBSD.org"> + +portmgr@FreeBSD.org"> + +portmgr-secretary@FreeBSD.org"> + +projcvs@FreeBSD.org"> + +re@FreeBSD.org"> + +security-officer@FreeBSD.org"> diff --git a/es_ES.ISO8859-1/share/sgml/trademarks.ent b/es_ES.ISO8859-1/share/sgml/trademarks.ent index e7bace5275..d413d12326 100644 --- a/es_ES.ISO8859-1/share/sgml/trademarks.ent +++ b/es_ES.ISO8859-1/share/sgml/trademarks.ent @@ -1,356 +1,410 @@ 3Com and HomeConnect are registered trademarks of 3Com Corporation."> 3Com"> 3ware and Escalade are registered trademarks of 3ware Inc."> 3ware"> Escalade"> Adaptec is a registered trademark of Adaptec, Inc."> Adaptec"> Adobe, Acrobat, Acrobat Reader, and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries."> Acrobat"> Acrobat Reader"> Adobe"> PostScript"> AMD, Am486, Am5X86, AMD Athlon, AMD - Duron, AMD Opteron, AMD-K6, Élan, and PCnet are + Duron, AMD Opteron, AMD-K6, Athlon, Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc."> Am486"> Am5x86"> AMD Athlon"> AMD Duron"> AMD-K6"> -AMD Operon"> +AMD Opteron"> +AMD Sempron"> +AMD Turion"> +Athlon"> Élan"> +Opteron"> -Apple, FireWire, Mac, Macintosh, Mac OS, + +Apple, AirPort, FireWire, Mac, Macintosh, Mac OS, Quicktime, and TrueType are trademarks of Apple Computer, Inc., registered in the United States and other countries."> +AirPort"> +Apple"> FireWire"> +iMac"> Mac"> Macintosh"> Mac OS"> Quicktime"> TrueType"> ARM is a registered trademark of ARM Limited."> ARM"> The Bluetooth word mark is owned by the Bluetooth SIG, Inc."> Bluetooth"> Broadcom is a registered trademark of Broadcom Corporation and/or its subsidiaries."> Broadcom"> Check Point, Firewall-1, and VPN-1 are trademarks of Check Point Software Technologies - Ltd.."> + Ltd."> Cisco, Catalyst, and IOS are registered trademarks of Cisco Systems, Inc. and/or its affiliates - in the United States and certain other countries."> + in the United States and certain other countries."> Catalyst"> IOS"> Corel and WordPerfect are trademarks or registered trademarks of Corel Corporation and/or its subsidiaries in Canada, the United States and/or other countries."> +WordPerfect"> + + +Coverity is a registered trademark; +Coverity Extend, Coverity Prevent and Coverity Prevent SQS are trademarks of +Coverity, Inc."> +Coverity"> +Coverity Prevent"> Sound Blaster is a trademark of Creative Technology Ltd. in the United States and/or other countries."> SoundBlaster"> CVSup is a registered trademark of John D. Polstra."> Dell, Dell Precision, Latitude, Optiplex, PowerEdge are trademarks or registered trademarks of Dell Computer Corporation"> Dell"> PowerEdge"> + +EPSON, EPSON Perfection are registered + trademarks of Seiko Epson Corporation."> +EPSON"> +EPSON + Perfection"> + FreeBSD is a registered trademark of - Wind River Systems, Inc. This is expected to change soon."> + the FreeBSD Foundation."> Heidelberg, Helvetica, Palatino, and Times Roman are either registered trademarks or trademarks of Heidelberger Druckmaschinen AG in the U.S. and other countries."> -IBM, AIX, EtherJet, Netfinity, OS/2, PowerPC, PS/2, S/390, and ThinkPad are +IBM, AIX, EtherJet, Netfinity, OS/2, + PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business Machines Corporation in the United States, other countries, or both."> AIX"> EtherJet"> Netfinity"> OS/2"> PowerPC"> PS/2"> S/390"> ThinkPad"> IEEE, POSIX, and 802 are registered trademarks of Institute of Electrical and Electronics Engineers, Inc. in the United States."> POSIX"> + Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries."> Celeron"> EtherExpress"> i386"> i486"> Intel"> Itanium"> Pentium"> Xeon"> +Core"> Intuit and Quicken are registered trademarks and/or registered service marks of Intuit Inc., or one of its subsidiaries, in the United States and other countries."> Iomega, Zip, and Jaz are either registered trademarks or trademarks of Iomega Corporation in the United States and/or other countries."> Zip"> Jaz"> Lantronix and EasyIO are trademarks of Lantronix Corporation."> EasyIO"> + Linux is a registered trademark of - Linus Torvalds in the United States."> + Linus Torvalds."> +Linux"> LSI Logic, AcceleRAID, eXtremeRAID, MegaRAID and Mylex are trademarks or registered trademarks of LSI Logic Corp."> AcceleRAID"> MegaRAID"> Mylex"> Macromedia, Flash, and Shockwave are trademarks or registered trademarks of Macromedia, Inc. in the United States and/or other countries."> Flash"> Macromedia"> Shockwave"> -Microsoft, FrontPage, MS-DOS, - Outlook, Windows, Windows Media, and Windows NT are either +Microsoft, IntelliMouse, MS-DOS, + Outlook, Windows, Windows Media and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries."> +IntelliMouse"> Microsoft"> MS-DOS"> Outlook"> Windows"> Windows Media"> + Windows NT"> + MIPS and R4000 are registered trademarks of MIPS Technologies, Inc. in the United States and other countries."> MIPS"> MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries."> MySQL"> M-Systems and DiskOnChip are trademarks or registered trademarks of M-Systems Flash Disk Pioneers, Ltd."> DiskOnChip"> + +NetBSD is a registered trademark of + the NetBSD Foundation."> + Netscape and the Netscape Navigator are registered trademarks of Netscape Communications Corporation in the U.S. and other countries."> Netscape"> Netscape Navigator"> GateD and NextHop are registered and unregistered trademarks of NextHop in the U.S. and other countries."> GateD"> NetWare, NetWare Loadable Module, and NLM are either registered trademarks or trademarks of Novell, Inc. in the United States and other countries."> Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries."> +UNIX is a registered trademarks of The + Open Group in the United States and other countries."> Motif"> UNIX"> Oracle is a registered trademark of Oracle Corporation."> Oracle"> +Parallels is a trademark of + Parallels Software International Inc."> + PowerQuest and PartitionMagic are registered trademarks of PowerQuest Corporation in the United States and/or other countries."> PartitionMagic"> QUALCOMM and Eudora are registered trademarks of QUALCOMM Incorporated."> Eudora"> RealNetworks, RealPlayer, and RealAudio are the registered trademarks of RealNetworks, Inc."> +RealPlayer"> Red Hat, RPM, are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries."> SAP, R/3, and mySAP are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world."> R/3"> SAP"> Silicon Graphics, SGI, and OpenGL are registered trademarks of Silicon Graphics, Inc., in the United States and/or other countries worldwide."> OpenGL"> + +Slackware is a registered trademark + of Patrick Volkerding and Slackware Linux, Inc."> + Sparc, Sparc64, SPARCEngine, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. Products bearing SPARC trademarks are based upon architecture developed by Sun Microsystems, Inc."> Sparc"> Sparc64"> SPARCEngine"> UltraSPARC"> -Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK, JSP, JVM, Netra, Solaris, StarOffice, - Sun Blade, Sun Enterprise, Sun Fire, SunOS, and Ultra are trademarks or registered trademarks of - Sun Microsystems, Inc. in the United States and other - countries."> + + +Sun, Sun Microsystems, Java, Java + Virtual Machine, JavaServer Pages, JDK, JRE, JSP, JVM, Netra, + Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire, SunOS, and + Ultra are trademarks or registered trademarks of Sun Microsystems, + Inc. in the United States and other countries."> Java"> Java Virtual Machine"> JavaServer Pages"> JDK"> +JRE"> JSP"> JVM"> Netra"> Solaris"> StarOffice"> Sun"> Sun Blade"> Sun Enterprise"> Sun Fire"> Ultra"> SunOS"> Symantec and Ghost are registered trademarks of Symantec Corporation in the United States and other countries."> MATLAB is a registered trademark of The MathWorks, Inc."> MATLAB"> SpeedTouch is a trademark of - Thomson"> + Thomson."> SpeedTouch"> Transmeta and Crusoe are either trademarks or registered trademarks of Transmeta Corporation in the United States and/or other countries."> Crusoe"> Transmeta"> U.S. Robotics and Sportster are registered trademarks of U.S. Robotics Corporation."> Sportster"> U.S. Robotics"> Waterloo Maple and Maple are trademarks or registered trademarks of Waterloo Maple Inc."> Maple"> Mathematica is a registered trademark of Wolfram Research, Inc."> Mathematica"> VMware is a trademark of VMware, Inc."> + +Xen is a trademark of XenSource, Inc. in + the United States and other countries."> +Xen"> + XFree86 is a trademark of The XFree86 Project, Inc."> XFree86"> Ogg Vorbis and Xiph.Org are trademarks of Xiph.Org."> Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the or the ® symbol.">