diff --git a/documentation/content/es/articles/freebsd-questions/_index.adoc b/documentation/content/es/articles/freebsd-questions/_index.adoc index 8e28bff54e..91c56ddbb4 100644 --- a/documentation/content/es/articles/freebsd-questions/_index.adoc +++ b/documentation/content/es/articles/freebsd-questions/_index.adoc @@ -1,239 +1,249 @@ --- title: Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions authors: - author: Greg Lehey email: grog@FreeBSD.org releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "microsoft", "opengroup", "qualcomm", "general"] --- = Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Este documento proporciona información útil para las personas que buscan preparar un correo electrónico para la lista de correo FreeBSD-questions. Se dan consejos y sugerencias que maximizarán la posibilidad de que el lector reciba respuestas útiles. Este documento se publica regularmente en la lista de correo FreeBSD-questions. ''' toc::[] == Introducción `FreeBSD-questions` es una lista de correo mantenida por el proyecto FreeBSD para ayudar a las personas que tienen preguntas sobre el uso cotidiano de FreeBSD. Otro grupo, `FreeBSD-hackers`, discute preguntas más avanzadas, como el trabajo a desarrollar en el futuro. [NOTE] ==== El término "hacker" no tiene nada que ver con irrumpir en los ordenadores de otras personas. El término correcto para esta actividad es "cracker", pero la prensa popular todavía no es conocedora. Los hackers de FreeBSD desaprueban enérgicamente las actividades de craqueo y no se involucran en este tipo de actividades. Para obtener una descripción más amplia de los hackers, consulte http://www.catb.org/~esr/faqs/hacker-howto.html[Cómo convertirse en un hacker] de Eric Raymond ==== Esta es una publicación regular destinada a ayudar tanto a aquellos que buscan consejos en la lista FreeBSD-questions (los "recién llegados"), como a aquellos que responden a las preguntas (los "hackers"). Inevitablemente hay cierta fricción, que se deriva de los diferentes puntos de vista de los dos grupos. Los recién llegados acusan a los hackers de ser arrogantes, malhumorados y de poca ayuda, mientras que los hackers acusan a los recién llegados de ser estúpidos, incapaces de leer textos sencillos en español y esperar que todo les sea entregado en bandeja de plata. Por supuesto, hay cierta verdad en ambas afirmaciones, pero en su mayor parte estos puntos de vista provienen de un sentimiento de frustración. En este documento, me gustaría hacer algo para aliviar esta frustración y ayudar a todos a obtener mejores resultados de FreeBSD-questions. En la siguiente sección, recomendaré cómo enviar una pregunta; después, veremos cómo responderla. == Cómo suscribirse a FreeBSD-questions FreeBSD-questions es una lista de correo, por lo que necesita una cuenta de correo electrónico. Acceda con su navegador web a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[página de información de la lista FreeBSD-questions]. En la sección titulada "Suscribirse a freebsd-questions" rellena el campo "Su dirección de correo electrónico"; los demás campos son opcionales. [NOTE] ==== El campo contraseña en el formulario de suscripción solo proporciona una seguridad moderada, pero debería evitar que otros accedan con su suscripción. _No use una contraseña valiosa_ ya que de manera ocasional se le enviará por correo electrónico en texto plano. ==== Recibirá un mensaje de confirmación de mailman; siga las instrucciones incluidas en el mensaje para completar su suscripción. Finalmente, cuando reciba el mensaje de "Bienvenida" de mailman informando los detalles de la lista y la contraseña para acceder al área restringida, __por favor guárdelo__. Si algún día desea salir de la lista, necesitará la información contenida en este mensaje. Vea la siguiente sección para más detalles. == Cómo darse de baja de FreeBSD-questions Cuando se subscribió a FreeBSD-Questions, recibió un mensaje de bienvenida de mailman. En este mensaje, entre otras cosas, le indicaba cómo darse de baja. Un mensaje típico: .... ¡Bienvenido a la lista de correo de freebsd-questions@freebsd.org! Para mandar un mensaje a esta lista, envíelo a: freebsd-questions@freebsd.org Puede obtener información general sobre la lista en: https://lists.freebsd.org/mailman/listinfo/freebsd-questions Si alguna vez desea anular su subscripción o cambiar las opciones de la misma (p.ej.: cambiarse a modo resumido o no, cambiar su clave, etc.), consulte la página de su subscripción en: https://lists.freebsd.org/mailman/options/freebsd-questions/grog%40lemsi.de También puede realizar estos cambios por medio de correo electrónico, enviando un mensaje a: freebsd-questions-request@freebsd.org indicando la palabra "help" en el asunto (no ponga las comillas) o en el cuerpo del mensaje. Se le devolverá un mensaje con instrucciones. Tiene que saber su clave para poder cambiar sus opciones (incluido el cambio de la propia clave) o para anular su subscripción. Su clave es: 12345 Normalmente, Mailman le recordará mensualmente las claves que tenga en las listas de distribución de freebsd.org, aunque si lo prefiere, puede inhabilitar este comportamiento. El recordatorio también incluirá instrucciones sobre cómo anular su subscripción o cómo cambiar los parámetros de subscripción. En la página de opciones hay un botón que le enviará un mensaje de correo electrónico con su clave. .... Desde la dirección URL que aparece en el mensaje de "Bienvenida", puede visitar la "Página de administración de su cuenta" y hacer una solicitud para "Darse de baja" de la lista FreeBSD-questions. Se le enviará un mensaje de confirmación de mailman; siga las instrucciones incluidas para terminar de darse de baja. Si ya lo ha hecho, y aún no ha podido entender lo que está ocurriendo, envíe un mensaje a mailto:freebsd-questions-request@FreeBSD.org[freebsd-questions-request@FreeBSD.org], y lo resolverán por usted. _No envíe_ un mensaje a FreeBSD-questions: no pueden ayudarle. == ¿Debo preguntar en `-questions` o en `-hackers`? Dos listas de correo manejan las preguntas generales sobre FreeBSD, `FreeBSD-questions` y `FreeBSD-hackers`. En algunos casos, no está realmente claro a qué grupo debe preguntar. Sin embargo, los siguientes criterios deberían ayudar en el 99% de los casos: . Si la pregunta es de carácter general, pregunte en `FreeBSD-questions`. Como ejemplos podrían ser preguntas sobre la instalación de FreeBSD o el uso de una utilidad particular de UNIX(R). . Si usted cree que la pregunta está relacionada con un error, pero no está seguro de ello, o no sabe cómo buscarlo, envíe el mensaje a `FreeBSD-questions`. . Si la pregunta está relacionada con un error, y está _seguro_ de que se trata de un error (por ejemplo, puede ubicar el lugar en el código donde ocurre, y quizás tenga una solución), envíe el mensaje a `FreeBSD-hackers`. . Si la pregunta está relacionada con mejoras en FreeBSD, y puede sugerir cómo implementarlas, envíe el mensaje a `FreeBSD-hackers`. También hay una serie de link:{handbook}#eresources-mail[listas de correo especializadas], que atienden a intereses más específicos. Los criterios anteriores se aplican, y es de su interés atenerse a ellos, ya que es más probable que obtenga buenos resultados de esa manera. == Antes de enviar una pregunta Usted puede (y debe) hacer algunas cosas antes de realizar una pregunta en una de las listas de correo: * Intente resolver el problema por su cuenta. Si publica una pregunta que demuestra que ha intentado resolver el problema, generalmente atraerá una atención más positiva de las personas que la lean. Tratar de resolver el problema por sí mismo también mejorará su comprensión de FreeBSD y, eventualmente, le permitirá utilizar su conocimiento para ayudar a otros respondiendo las preguntas publicadas en las listas de correo. * Lea las páginas del manual y la documentación de FreeBSD (ya sea la instalada en [.filename]#/usr/doc# o accesible a través de WWW en link:{handbook}[http://www.FreeBSD.org]), especialmente el manual y las link:{faq}[FAQ]. * Navegue y/o busque en los archivos de la lista de correo, para ver si su pregunta o una similar ya ha sido preguntada (y posiblemente contestada) en la lista. Puede navegar y/o buscar en los archivos de las listas de correo en https://www.FreeBSD.org/mail[https://www.FreeBSD.org/mail] y https://www.FreeBSD.org/search#mailinglists[https://www.FreeBSD.org/search/#mailinglists] respectivamente. También se puede hacer en otros sitios Web, por ejemplo en http://marc.theaimsgroup.com[http://marc.theaimsgroup.com]. * Use un motor de búsqueda como http://www.google.com[Google] o http://www.yahoo.com[Yahoo] para encontrar respuestas a su pregunta. == Cómo enviar una pregunta Al enviar una pregunta a FreeBSD-questions, tenga en cuenta los siguientes puntos: * Recuerde que a nadie le pagan por responder una pregunta de FreeBSD. Lo hacen por su propia voluntad. Puede influir positivamente enviando una pregunta bien formulada y con la mayor cantidad de información relevante posible. Puede influir negativamente si envía una pregunta incompleta, ilegible o grosera. Es posible enviar un mensaje a FreeBSD-questions y no obtener una respuesta incluso siguiendo estas reglas. Y es muy posible no obtener respuesta si no las sigue. En el resto de este documento, veremos cómo sacar el máximo provecho de una pregunta a FreeBSD-questions. * No todos los que responden a las preguntas de FreeBSD leen todos los mensajes: miran la línea del asunto y deciden si les interesa. Obviamente, le interesa especificar un asunto. "Problema en FreeBSD" o "Ayuda" no son suficientes. Si no proporciona ningún asunto, muchas personas no se molestarán ni en leerlo. Si su asunto no es lo suficientemente específico, las personas que puedan responderlo podrían no leerlo. * ¡Formatee su mensaje para que sea legible y, POR FAVOR, NO GRITE!!!!!. Somos conscientes de que muchas personas no hablan inglés como primer idioma, y damos un margen, pero es realmente doloroso tratar de leer un mensaje lleno de errores tipográficos o sin saltos de línea. + No subestime el efecto que un mensaje de correo mal formateado tiene, no sólo en la lista de correo FreeBSD-questions. Su mensaje de correo electrónico es lo que todas las personas ven de usted, y si está mal formateado, una línea por párrafo, mal escrito o lleno de errores, esto dará a la gente una mala impresión de usted. + Muchos mensajes mal formateados provienen de http://www.lemis.com/email.html[servicios de correo incorrectos o mal configurados]. Se sabe que los siguientes servicios de correo envían mensajes mal formateados sin que usted se entere de ello: ** Eudora(R) ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) + Trate de no usar MIME: muchas personas usan correos que no se llevan muy bien con MIME. * Asegúrese de que su hora y zona horaria están configuradas correctamente. Esto puede parecer un poco tonto, ya que su mensaje sigue llegando, pero muchas de las personas a las que envía el mensaje reciben varios cientos de mensajes al día. Con frecuencia ordenan los mensajes entrantes por asunto y por fecha, y si su mensaje no llega antes de la primera respuesta, pueden asumir que lo perdieron y no se molestarán en mirar. * No incluya preguntas que no están relacionadas en el mismo mensaje. En primer lugar, un mensaje largo tiende a asustar a la gente y, en segundo lugar, es más difícil conseguir que todas las personas que puedan responder a la pregunta lean el mensaje. * Especifique la mayor cantidad de información posible. Es un área difícil, y necesitamos ampliar la información que necesita enviar, pero aquí un comienzo: ** En casi todos los casos, es importante conocer la versión de FreeBSD que se está ejecutando. En el caso particular de FreeBSD-CURRENT, también debe especificar la fecha del código fuente, aunque, obviamente, usted no debe enviar preguntas sobre -CURRENT a FreeBSD-questions. ** Con cualquier problema que _pueda_ estar relacionado con el hardware, infórmenos sobre su hardware. En caso de duda, supongamos que es posible que sea el hardware. ¿Qué tipo de CPU está utilizando? ¿Cómo de rápida? ¿Qué placa base? ¿Cuánta memoria? ¿Qué periféricos? + Se trata de una opinión personal, desde luego, pero la salida del comando man:dmesg[8] con frecuencia puede ser muy útil, ya que no solo indica qué hardware está ejecutando, sino también qué versión de FreeBSD. ** Si recibe mensajes de error, no diga "Recibo mensajes de error", diga (por ejemplo) "Me aparece el mensaje de error 'No route to host'". ** Si su sistema entra en "panic", no diga "Mi sistema entró en panic", diga (por ejemplo) "Mi sistema entró en panic con el mensaje 'free vnode isn't'". ** Si tiene dificultades para instalar FreeBSD, díganos qué hardware tiene. En particular, es importante conocer las IRQ y las direcciones de I/O de las tarjetas instaladas en su máquina. ** Si tiene dificultades para ejecutar PPP, describa la configuración. ¿Qué versión de PPP usa? ¿Qué tipo de autenticación tiene? ¿Tiene una dirección IP estática o dinámica? ¿Qué tipo de mensajes recibe en el archivo de log? * Mucha de la información que debe proporcionar es la salida de programas, como man:dmesg[8] o mensajes de consola, que generalmente aparecen en [.filename]#/var/log/messages#. No intente copiar esa información escribiéndola de nuevo; es un suplicio, y cometerá un error. Para enviar el contenido del log, haga una copia del archivo y use un editor para recortar la información que sea relevante, o corte y pegue en su mensaje. Para la salida de programas como man:dmesg[8], redirija la salida a un archivo e inclúyalo. Por ejemplo, + [source,shell] .... % dmesg > /tmp/dmesg.out .... + Esto redirige la información al archivo [.filename]#/tmp/dmesg.out#. * Si hace todo esto y no obtiene una respuesta, puede haber otras razones. Por ejemplo, el problema es tan complicado que nadie sabe la respuesta, o la persona que sabía la respuesta estaba offline. Si no obtiene respuesta después de, por ejemplo, una semana, puede ser útil reenviar el mensaje. Sin embargo, si no recibe respuesta a su segundo mensaje, es probable que no reciba respuesta de este foro. Reenviar el mismo mensaje una y otra vez solo le hará impopular. Para resumir, supongamos que conoce la respuesta a la siguiente pregunta (sí, es la misma en cada caso). Usted elija cuál de estas dos preguntas estaría más preparado para responder: .Mensaje 1 [example] ==== .... Asunto: ¿¿¡¿¡¡AYUDA!!?!?? No puedo conseguir que el maldito sistema FereBSD funcioned y soi realmente bueno en sto, pero nunca he visto nada tan dificil de instlar, simplmente no funciona intente lo que intente, así que, por qué no me dicen que estoy haciendo mal .... ==== .Mensaje 2 [example] ==== .... Asunto: Problemas al instalar FreeBSD Acabo de recibir el CDROM FreeBSD 2.1.5 de Walnut Creek y tengo muchas dificultades para instalarlo. Tengo un 486 con 66 MHz, 16 MB de memoria y una placa SCSI 1540A Adaptec, un disco Quantum Fireball de 1.2GB y una unidad de CDROM Toshiba 3501XA. La instalación funciona bien, pero cuando intento reiniciar el sistema, aparece el mensaje Missing Operating System. .... ==== == Cómo dar seguimiento a una pregunta A menudo, deseará enviar información adicional a una pregunta que ya haya enviado. La mejor manera de hacerlo es responder a su mensaje original. Esto tiene tres ventajas: . Incluye el texto del mensaje original, para que la gente sepa de qué está hablando. Sin embargo, no olvide recortar el texto innecesario. . El texto en el asunto sigue siendo el mismo (recordó poner uno, ¿no es así?). Muchos servicios de correo ordenarán los mensajes por asunto. Esto ayuda a agrupar los mensajes. . Los números de referencia del mensaje en el encabezado se refieren al mensaje anterior. Algunos gestores de correo, como http://www.mutt.org/[mutt], pueden agrupar los mensajes en __hilos__, mostrando las relaciones exactas entre los mensajes. == Cómo responder a una pregunta Antes de responder una pregunta en FreeBSD-questions, considere: . Muchas de las directrices utilizadas cuando se está escribiendo una pregunta también son válidas para responderlas. Léalas. . ¿Alguien ha respondido ya la pregunta? La forma más fácil de verificar esto es ordenar su correo entrante por asunto: luego (con suerte) verá la pregunta seguida de las respuestas, todas juntas. + Si alguien ha respondido, esto no significa que automáticamente usted no deba enviar otra respuesta. Pero tiene sentido leer las otras respuestas primero. . ¿Tiene algo que aportar más allá de lo que ya se ha dicho? En general, las respuestas del tipo "Sí, yo también" no ayudan mucho, aunque hay excepciones, como cuando alguien está describiendo un problema que está teniendo, y no sabe si es culpa suya o si hay algo mal con el hardware o software. Si va a enviar una respuesta de tipo "yo también", debe incluir otra información relevante. . ¿Seguro que entiende la pregunta? Con mucha frecuencia, la persona que hace la pregunta está confundida o no se expresa muy bien. Incluso con la mejor comprensión del sistema, es fácil enviar una respuesta que no responde la pregunta. Esto no ayuda: dejará a la persona que formuló la pregunta más frustrada o confundida que nunca. Si nadie más responde y usted tampoco está seguro, siempre puede pedir más información. . ¿Está seguro de que su respuesta es correcta? Si no, espere un día o así. Si a nadie más se le ocurre una respuesta mejor, aún puede responder y decir, por ejemplo, "No sé si esto es correcto, pero como nadie más ha respondido, ¿por qué no intenta reemplazar su CDROM ATAPI con una rana?". . A menos que haya una buena razón para hacer lo contrario, responda al remitente y a FreeBSD-questions. Muchas personas en FreeBSD-questions son "lurkers": aprenden leyendo mensajes enviados y respondidos por otras personas. Si quita de la lista un mensaje que es de interés general, está privando a estas personas de su información. Tenga cuidado con las respuestas grupales; mucha gente envía mensajes con cientos de CC. Si es así, asegúrese de reducir las líneas Cc: apropiadamente. . Incluya texto relevante del mensaje original. Reduzca al mínimo, pero no exagere. El contenido original restante todavía debería permitir a alguien que no leyó el mensaje original entender de lo que usted está hablando. . Use alguna técnica para identificar qué texto proviene del mensaje original y qué texto agrega. Personalmente encuentro que anteponer "`>`" al mensaje original funciona mejor. Dejando espacios en blanco después de "`>`" y deje líneas vacías entre el texto y el texto original para que el resultado sea más legible. . Coloque su respuesta en el lugar correcto (después del texto al que responde). Es muy difícil leer un hilo de respuestas donde cada respuesta aparece antes del texto al que responde. . La mayoría de los programas de correo electrónico cambian la línea del asunto en una respuesta, agregando al principio de este un texto del tipo "Re: ". Si su programa no lo hace automáticamente, debe hacerlo manualmente. . Si el remitente no cumplió con las convenciones de formato (líneas demasiado largas, asunto inapropiado), __por favor__, corríjalo. En caso de un asunto incorrecto (como "¿¿¡¡AYUDA!!??"), cambie el asunto a (por ejemplo) "Re: Dificultades con la sincronización de PPP (was: ¿¿¡¡AYUDA!!??)". De esa manera, otras personas que intenten seguir el hilo tendrán menos dificultad para seguirlo. + En tales casos, es apropiado decir lo que hizo y por qué lo hizo, pero trate de no ser grosero. Si no puede responder sin ser grosero, no conteste. + Si solo desea responder a un mensaje debido a su formato incorrecto, solo responda al remitente, no a la lista. Puede simplemente enviarle este mensaje como respuesta, si lo desea. diff --git a/documentation/content/es/articles/ipsec-must/_index.adoc b/documentation/content/es/articles/ipsec-must/_index.adoc index 1f83f41d1b..eaed91e109 100644 --- a/documentation/content/es/articles/ipsec-must/_index.adoc +++ b/documentation/content/es/articles/ipsec-must/_index.adoc @@ -1,266 +1,276 @@ --- title: Verificación independiente de la funcionalidad de IPsec en FreeBSD authors: - author: David Honig email: honig@sprynet.com releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "opengroup", "general"] --- = Verificación independiente de la funcionalidad de IPsec en FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Instaló IPsec y parece estar funcionando. ¿Cómo lo sabe? Describo un método para verificar de forma experimental que IPsec está funcionando. ''' toc::[] [[problem]] == El problema Primero, asumamos que ha <>. ¿Cómo sabe que está <>? Claro, su conexión no funcionará si está mal configurada, y funcionará cuando finalmente lo haga bien. man:netstat[1] la listará. ¿Pero puede confirmarlo de forma independiente? [[solution]] == La solución Primero, alguna información teórica relevante sobre criptografía: . Los datos cifrados se distribuyen uniformemente, es decir, tienen una entropía máxima por símbolo; . Los datos sin procesar y sin comprimir suelen ser redundantes, es decir, tienen una entropía submáxima. Suponga que usted pudiera medir la entropía de los datos que van hacia -y desde- su interfaz de red. Entonces podría ver la diferencia entre los datos no cifrados y los cifrados. Esto sería verdad incluso si algunos de los datos en "modo cifrado" no lo estuvieran---ya que el encabezado IP más externo debe estarlo para que el paquete sea enrutable. [[MUST]] === MUST El "Universal Statistical Test for Random Bit Generators" (https://web.archive.org/web/20011115002319/http://www.geocities.com/SiliconValley/Code/4704/universal.pdf[MUST]) de Ueli Maurer mide rápidamente la entropía de una muestra. Utiliza un algoritmo de compresión. <> para una variante que mide partes sucesivas (~cuarto de megabyte) de un archivo [[tcpdump]] === Tcpdump También necesitamos una forma de capturar los datos de red sin procesar. Un programa llamado man:tcpdump[1] le permite hacerlo, si tiene habilitada la interfaz de _Berkeley Packet Filter_ en el <>. El comando: [source,shell] .... tcpdump -c 4000 -s 10000 -w dumpfile.bin .... capturará 4000 paquetes sin procesar en el fichero _dumpfile.bin_. En este ejemplo se capturarán hasta 10.000 bytes por paquete. [[experiment]] == El experimento Aquí está el experimento: [.procedure] ==== . Abra una ventana a un host IPsec y otra ventana a un host inseguro. . Ahora empiece a <>. . En la ventana "segura", ejecute el comando UNIX(R) man:yes[1], que transmitirá el carácter `y`. Después de un rato, detenga el comando. Cambie a la ventana insegura, y repita. Espere un poco, detenga el comando. . Ahora ejecute <> en los paquetes capturados. Debería ver algo como lo siguiente. Lo importante a tener en cuenta es que la conexión segura tiene un 93% (6,7) del valor esperado (7,18), y la conexión "normal" tiene un 29% (2,1) del valor esperado. + [source,shell] .... % tcpdump -c 4000 -s 10000 -w ipsecdemo.bin % uliscan ipsecdemo.bin Uliscan 21 Dec 98 L=8 256 258560 Measuring file ipsecdemo.bin Init done Expected value for L=8 is 7.1836656 6.9396 -------------------------------------------------------- 6.6177 ----------------------------------------------------- 6.4100 --------------------------------------------------- 2.1101 ----------------- 2.0838 ----------------- 2.0983 ----------------- .... ==== [[caveat]] == Advertencia Este experimento muestra que IPsec _parece_ estar distribuyendo los datos de la carga útil __uniformemente__, como debe hacerlo el cifrado. Sin embargo, el experimento aquí descrito _puede no_ detectar muchas de las posibles fallas del sistema (para las cuales no tengo evidencias). Esto incluye la generación o intercambio de claves deficientes, datos o claves visibles para otros, uso de algoritmos débiles, subversión del kernel, etc. Estudie el código; conozca el código. [[IPsec]] == IPsec---Definición Extensiones de seguridad del Protocolo de Internet para IPv4; requerido para IPv6. Un protocolo para negociar el cifrado y la autenticación a nivel de IP (host a host). SSL solo protege un socket de aplicación. SSH protege solo el login. PGP protege un archivo o mensaje específico. IPsec encripta todo entre dos hosts. [[ipsec-install]] == Instalando IPsec La mayoría de las versiones modernas de FreeBSD soportan IPsec en su código base. Por lo tanto, deberá incluir la opción `IPSEC` en la configuración de su kernel y, después de recompilar y reinstalar el kernel, configure las conexiones de IPsec usando el comando man:setkey[8]. En el link:{handbook}#ipsec[Manual de FreeBSD] se proporciona una guía completa sobre cómo ejecutar IPsec en FreeBSD. [[kernel]] == src/sys/i386/conf/KERNELNAME Esto debe estar presente en el archivo de configuración del kernel para capturar datos de red con man:tcpdump[1]. Asegúrese de ejecutar man:config[8] después de agregar esto, recompilar y reinstalar. [.programlisting] .... device bpf .... [[code]] == Maurer's Universal Statistical Test (tamaño de bloque=8 bits) Puede encontrar el mismo código fuente en https://web.archive.org/web/20031204230654/http://www.geocities.com:80/SiliconValley/Code/4704/uliscanc.txt[este enlace]. [.programlisting] .... /* ULISCAN.c ---blocksize of 8 1 Oct 98 1 Dec 98 21 Dec 98 uliscan.c derived from ueli8.c This version has // comments removed for Sun cc This implements Ueli M Maurer's "Universal Statistical Test for Random Bit Generators" using L=8 Accepts a filename on the command line; writes its results, with other info, to stdout. Handles input file exhaustion gracefully. Ref: J. Cryptology v 5 no 2, 1992 pp 89-105 also on the web somewhere, which is where I found it. -David Honig honig@sprynet.com Usage: ULISCAN filename outputs to stdout */ #define L 8 #define V (1< #include int main(argc, argv) int argc; char **argv; { FILE *fptr; int i,j; int b, c; int table[V]; double sum = 0.0; int iproduct = 1; int run; extern double log(/* double x */); printf("Uliscan 21 Dec 98 \nL=%d %d %d \n", L, V, MAXSAMP); if (argc < 2) { printf("Usage: Uliscan filename\n"); exit(-1); } else { printf("Measuring file %s\n", argv[1]); } fptr = fopen(argv[1],"rb"); if (fptr == NULL) { printf("Can't find %s\n", argv[1]); exit(-1); } for (i = 0; i < V; i++) { table[i] = 0; } for (i = 0; i < Q; i++) { b = fgetc(fptr); table[b] = i; } printf("Init done\n"); printf("Expected value for L=8 is 7.1836656\n"); run = 1; while (run) { sum = 0.0; iproduct = 1; if (run) for (i = Q; run && i < Q + K; i++) { j = i; b = fgetc(fptr); if (b < 0) run = 0; if (run) { if (table[b] > j) j += K; sum += log((double)(j-table[b])); table[b] = i; } } if (!run) printf("Premature end of file; read %d blocks.\n", i - Q); sum = (sum/((double)(i - Q))) / log(2.0); printf("%4.4f ", sum); for (i = 0; i < (int)(sum*8.0 + 0.50); i++) printf("-"); printf("\n"); /* refill initial table */ if (0) { for (i = 0; i < Q; i++) { b = fgetc(fptr); if (b < 0) { run = 0; } else { table[b] = i; } } } } } .... diff --git a/documentation/content/es/articles/leap-seconds/_index.adoc b/documentation/content/es/articles/leap-seconds/_index.adoc index 9b84394e84..63cefd7dc0 100644 --- a/documentation/content/es/articles/leap-seconds/_index.adoc +++ b/documentation/content/es/articles/leap-seconds/_index.adoc @@ -1,80 +1,90 @@ --- title: Soporte para segundos intercalares en FreeBSD releaseinfo: "$FreeBSD$" --- = Soporte para segundos intercalares en FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] ''' toc::[] [[leapseconds-definition]] == Introducción Un _segundo intercalar_ es un ajuste de un segundo realizado en momentos específicos del año a UTC para sincronizar escalas de tiempo atómicas con variaciones en la rotación de la Tierra. Este artículo describe cómo FreeBSD interactúa con segundos intercalares. En el momento de escribir estas líneas, el próximo segundo intercalar ocurrirá el 30 de junio del 2015 a las 23:59:60 UTC. Este segundo intercalar ocurrirá durante un dí­a laboral para América del Norte y del Sur y la región Asia/Pací­fico. Los segundos intercalares son anunciados por el http://datacenter.iers.org/[IERS] en el http://datacenter.iers.org/web/guest/bulletins/-/somos/5Rgv/product/16[Boletín C]. El comportamiento estándar de los segundos intercalares se describe en https://tools.ietf.org/html/rfclink7164#section-3[RFC 7164]. Véase también man:time2posix[3]. [[leapseconds-posix]] == Manejo por defecto de los segundos intercalares en FreeBSD La manera más fácil de manejar segundos intercalares es con las reglas de tiempo de POSIX que FreeBSD utiliza por defecto, combinadas con link:{handbook}#network-ntp[NTP]. Cuando man:ntpd[8] se esté ejecutando y el tiempo esté sincronizado con servidores remotos de NTP que manejen segundos intercalares correctamente, dicho segundo intercalar hará que el tiempo del sistema automáticamente repita el último segundo del dí­a. Ningún otro ajuste es necesario. Si los servidores remotos de NTP no manejan los segundos intercalares correctamente, man:ntpd[8] aumentará el tiempo en un segundo, después de que el servidor errático lo haya notado y haya saltado él mismo ese segundo. Si no se usa NTP, se requerirá el ajuste manual del reloj del sistema una vez que el segundo intercalar haya pasado. [[leapseconds-cautions]] == Precauciones Los segundos intercalares se insertan en el mismo instante en todo el mundo: a medianoche según UTC. En Japón esto ocurre a media mañana, en el Pacífico al mediodía, en América es por la tarde-noche y en Europa por la noche. Creemos y esperamos que FreeBSD, si se proporciona un servicio NTP correcto y estable, funcionará como se diseñó durante este segundo, como lo hizo durante los anteriores. De todas formas, asumimos que prácticamente ninguna aplicación ha requerido información del kernel acerca del segundo intercalar. Nuestra experiencia es que, tal como está diseñado, el segundo intercalar es esencialmente una repetición del segundo antes del segundo intercalar, esto es una sorpresa para la mayoría de los programadores. Otros sistemas operativos y computadoras pueden o no manejar el segundo intercalar de la misma forma que FreeBSD, y los sistemas sin un servicio NTP correcto y estable no sabrán nada sobre el segundo intercalar. No es extraño que las computadoras fallen a causa del segundo intercalar, y la experiencia ha demostrado que una gran parte de los servidores públicos de NTP pueden manejar y anunciar incorrectamente el segundo intercalar. Por favor, intente asegurarse de que nada horrible suceda debido al segundo intercalar. [[leapseconds-testing]] == Pruebas Es posible probar si un segundo intercalar será usado. Debido a la naturaleza de NTP, la prueba puede funcionar hasta 24 horas antes del segundo intercalar. Algunas fuentes importantes de referencia de tiempo solo anuncian el segundo intercalar una hora antes del acontecimiento. Realice una consulta al demonio de NTP: [source,shell] .... % ntpq -c 'rv 0 leap' .... Una salida que incluya `leap_add_sec` indica el soporte para el segundo intercalar. Cuando falten más de 24 horas para el segundo intercalar, o cuando este haya pasado, `leap_none` será mostrado por pantalla. [[leapseconds-conclusion]] == Conclusión En la práctica, los segundos intercalares no suelen ser un problema en FreeBSD. Esperamos que esta breve reseña ayude a clarificar qué esperar y cómo hacer que el segundo intercalar pase sin contratiempos. diff --git a/documentation/content/es/articles/linux-users/_index.adoc b/documentation/content/es/articles/linux-users/_index.adoc index 84aa72587f..fa4e7f8451 100644 --- a/documentation/content/es/articles/linux-users/_index.adoc +++ b/documentation/content/es/articles/linux-users/_index.adoc @@ -1,324 +1,334 @@ --- title: Guía de inicio rápido en FreeBSD para usuarios de Linux authors: - author: John Ferrell copyright: 2008 El Proyecto de Documentación de FreeBSD releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "intel", "redhat", "linux", "unix", "general"] --- = Guía de inicio rápido en FreeBSD para usuarios de Linux :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen El objetivo de este documento es familiarizar rápidamente a los usuarios intermedios y avanzados de Linux(R) con los conceptos básicos de FreeBSD. ''' toc::[] [[intro]] == Introducción Este documento destaca algunas de las diferencias técnicas entre FreeBSD y Linux(R) para que los usuarios intermedios y avanzados de Linux(R) puedan familiarizarse rápidamente con los conceptos básicos de FreeBSD. This document assumes that FreeBSD is already installed. Refer to the link:{handbook}#bsdinstall[Installing FreeBSD] chapter of the FreeBSD Handbook for help with the installation process. [[shells]] == Shell por defecto Los usuarios de Linux(R) a menudo se sorprenden al descubrir que Bash no es la shell por defecto en FreeBSD. De hecho, Bash no está incluido en la instalación predeterminada. En su lugar, FreeBSD utiliza man:tcsh[1]como shell predeterminada para el usuario root y man:sh[1] como shell compatible con Bourne shell por defecto. man:sh[1] es muy similar a Bash pero con un conjunto de características mucho más pequeño. Generalmente, los scripts escritos para man:sh[1] se ejecutarán en Bash, pero al contrario no siempre es así. Sin embargo, Bash y otras shells están disponibles para la instalación utilizando los link:{handbook}#ports[paquetes de FreeBSD y la Colección de Ports]. Después de instalar otra shell, use man:chsh[1] para cambiar la shell predeterminada de un usuario. Se recomienda mantener la shell del usuario `root`, ya que las shells que no están incluidas en el sistema base se instalan en [.filename]#/usr/local/bin#. Si hay un problema, el sistema de archivos donde se encuentra [.filename]#/usr/local/bin# podría no estar montado. En este caso, el usuario `root` podría no tener acceso a su shell por defecto, impidiendo que el usuario `root` inicie sesión y solucione el problema. [[software]] == Paquetes y Ports: Instalar software en FreeBSD FreeBSD proporciona dos métodos para instalar aplicaciones: paquetes binarios y ports compilados. Cada método tiene sus propias ventajas: .Paquetes binarios * Instalación más rápida comparado con la compilación de aplicaciones de gran tamaño. * No es necesario saber cómo compilar software. * No es necesario instalar un compilador. .Ports * Posibilidad de personalizar las opciones de instalación. * Se pueden aplicar parches personalizados. Si la instalación de una aplicación no requiere de ninguna personalización, con la instalación del paquete es suficiente. Compile el port siempre que una aplicación requiera la personalización de las opciones predeterminadas. Si fuera necesario, se puede compilar un paquete personalizado desde los ports usando make`package`. Una lista completa de todos los ports y paquetes disponibles se puede encontrar https://www.freebsd.org/ports/[aquí]. [[packages]] === Paquetes Packages are pre-compiled applications, the FreeBSD equivalents of [.filename]#.deb# files on Debian/Ubuntu based systems and [.filename]#.rpm# files on Red Hat/Fedora based systems. Packages are installed using `pkg`. For example, the following command installs Apache 2.4: [source,shell] .... # pkg install apache24 .... Para obtener más información sobre los paquetes, consulte la sección 5.4 del Manual de FreeBSD: link:{handbook}#pkgng-intro[Uso de pkgng para la administración de paquetes binarios]. [[ports]] === Ports La Colección de Ports de FreeBSD es un framework de [.filename]#Makefiles# y parches específicamente personalizados para instalar aplicaciones con su código fuente en FreeBSD. Al instalar un port, el sistema buscará el códifo fuente, aplicará los parches necesarios, compilará el código e instalará la aplicación y las dependencias necesarias. La Colección de Ports, a veces llamada el árbol de ports, se puede instalar en [.filename]#/usr/ports# utilizando man:portsnap[8]. Se pueden encontrar instrucciones detalladas para instalar la Colección de Ports en la link:{handbook}#ports-using[sección 5.5] del Manual de FreeBSD. Para compilar un port, acceda al directorio del port e inicie el proceso de build. El siguiente ejemplo instala Apache 2.4 de la colección de ports: [source,shell] .... # cd /usr/ports/www/apache24 # make install clean .... El beneficio de usar ports para instalar software es la capacidad de personalizar las opciones de instalación. Este ejemplo especifica que el módulo mod_ldap también debe ser instalado: [source,shell] .... # cd /usr/ports/www/apache24 # make WITH_LDAP="YES" install clean .... Consulte link:{handbook}#ports-using[Usando la Colección de Ports] para obtener más información. [[startup]] == Inicio del sistema Muchas distribuciones de Linux(R) usan el sistema de inicio SysV, mientras que FreeBSD usa el tradicional BSD-style man:init[8]. Con el BSD-style man:init[8], no hay run-levels y [.filename]#/etc/inittab# no existe. En su lugar, el inicio está controlado por scripts man:rc[8]. En el arranque del sistema, [.filename]#/etc/rc# lee [.filename]#/etc/rc.conf# y [.filename]#/etc/defaults/rc.conf# para determinar qué servicios deben iniciarse. Los servicios especificados son iniciados ejecutando su correspondiente script de inicialización del servicio ubicado en [.filename]#/etc/rc.d/# y [.filename]#/usr/local/etc/rc.d/#. Estos scripts son similares a los scripts ubicados en [.filename]#/etc/init.d/# en los sistemas Linux(R). Los scripts ubicados en [.filename]#/etc/rc.d/# son para las aplicaciones que forman parte del sistema "base", como man:cron[8], man:sshd[8], y man:syslog[3]. Los scripts ubicados en [.filename]#/usr/local/etc/rc.d/# son para aplicaciones instaladas por el usuario como Apache y Squid. Dado que FreeBSD se desarrolla como un sistema operativo completo, las aplicaciones instaladas por el usuario no se consideran parte del sistema "base". Las aplicaciones instaladas por el usuario generalmente se instalan utilizando link:{handbook}#ports-using[Paquetes o Ports]. Para mantenerlas separadas del sistema base, las aplicaciones instaladas por el usuario se instalan en [.filename]#/usr/local/#. Por lo tanto, los binarios instalados por el usuario están ubicados en [.filename]#/usr/local/bin/#, los archivos de configuración están en [.filename]#/usr/local/etc/#, y así sucesivamente. Los servicios se habilitan añadiendo una entrada para el servicio en [.filename]#/etc/rc.conf#. Los valores predeterminados del sistema se encuentran en [.filename]#/etc/defaults/rc.conf# y las configuraciones por defecto se sobreescriben con [.filename]#/etc/rc.conf#. Consulte man:rc.conf[5] para obtener más información sobre las entradas disponibles. Al instalar aplicaciones adicionales, revise el mensaje de instalación para determinar cómo habilitar los servicios asociados. Las siguientes entradas en [.filename]#/etc/rc.conf# activan man:sshd[8], activan Apache 2.4 y especifican que Apache debe iniciarse con SSL. [.programlisting] .... # activa SSHD sshd_enable="YES" # activa Apache con SSL apache24_enable="YES" apache24_flags="-DSSL" .... Una vez que un servicio ha sido activado en [.filename]#/etc/rc.conf#, puede iniciarse sin reiniciar el sistema: [source,shell] .... # service sshd start # service apache24 start .... Si un servicio no ha sido activado, puede iniciarse desde la línea de comandos usando `onestart`: [source,shell] .... # service sshd onestart .... [[network]] == Configuración de la red Instead of a generic _ethX_ identifier that Linux(R) uses to identify a network interface, FreeBSD uses the driver name followed by a number. The following output from man:ifconfig[8] shows two Intel(R) Pro 1000 network interfaces ([.filename]#em0# and [.filename]#em1#): [source,shell] .... % ifconfig em0: flags=8843 mtu 1500 options=b inet 10.10.10.100 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:50:56:a7:70:b2 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b inet 192.168.10.222 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:50:56:a7:03:2b media: Ethernet autoselect (1000baseTX ) status: active .... Una dirección IP puede ser asignada a una interfaz usando man:ifconfig[8]. Para que permanezca entre reinicios, la configuración IP debe ser incluida en [.filename]#/etc/rc.conf#. Las siguientes entradas en [.filename]#/etc/rc.conf# especifican el hostname, la dirección IP, y el gateway por defecto: [.programlisting] .... hostname="server1.example.com" ifconfig_em0="inet 10.10.10.100 netmask 255.255.255.0" defaultrouter="10.10.10.1" .... En su lugar, utilice las siguientes entradas para configurar una interfaz de red con DHCP: [.programlisting] .... hostname="server1.example.com" ifconfig_em0="DHCP" .... [[firewall]] == Firewall FreeBSD no usa las IPTABLES de Linux(R) para su firewall. En su lugar, FreeBSD ofrece tres firewalls a nivel del kernel: * link:{handbook}#firewalls-pf[PF] * link:{handbook}#firewalls-ipf[IPFILTER] * link:{handbook}#firewalls-ipfw[IPFW] PF está desarrollado por el proyecto OpenBSD y portado a FreeBSD. PF fue creado como un reemplazo para IPFILTER y su sintaxis es similar. PF se puede combinar con man:altq[4] para proporcionar QoS. Este ejemplo de PF permite la entrada de tráfico SSH: [.programlisting] .... pass in on $ext_if inet proto tcp from any to ($ext_if) port 22 .... IPFILTER es el firewall desarrollado por Darren Reed. No es específico de FreeBSD y se ha portado a varios sistemas operativos, incluidos NetBSD, OpenBSD, SunOS, HP/UX y Solaris. La sintaxis de IPFILTER para permitir la entrada de tráfico SSH es: [.programlisting] .... pass in on $ext_if proto tcp from any to any port = 22 .... IPFW es el cortafuegos desarrollado y mantenido por FreeBSD. Se puede combinar con man:dummynet[4] para proporcionar traffic shaping y simular diferentes tipos de conexiones. La sintaxis de IPFW para permitir la entrada de tráfico SSH sería: [.programlisting] .... ipfw add allow tcp from any to me 22 in via $ext_if .... [[updates]] == Actualizando FreeBSD Hay dos métodos para actualizar un sistema FreeBSD: desde el código fuente o desde la actualización de los binarios. Actualizar desde código fuente es el método más complejo pero el que ofrece mayor flexibilidad. El proceso implica la sincronización de una copia local del código fuente de FreeBSD con los servidores Subversion de FreeBSD. Una vez actualizado el código fuente, puede compilar nuevas versiones del kernel y utilidades. Las actualizaciones de los binarios son similares a usar `yum` o `apt-get` para actualizar un sistema Linux(R). En FreeBSD, man:freebsd-update[8] puede usarse para obtener las nuevas actualizaciones de los binarios e instalarlas. Estas actualizaciones pueden ser programadas usando man:cron[8]. [NOTE] ==== Cuando use man:cron[8] para programar actualizaciones, use `freebsd-update cron` en man:crontab[1] para reducir la posibilidad de que una gran cantidad de máquinas se actualicen al mismo tiempo: [.programlisting] .... 0 3 * * * root /usr/sbin/freebsd-update cron .... ==== Para obtener más información de las actualizaciones de código y binarias, consulte el link:{handbook}#updating-upgrading[capítulo sobre la actualización] en el Manual de FreeBSD. [[procfs]] == procfs: Desaparecido pero no olvidado En algunas distribuciones de Linux(R), puede consultar [.filename]#/proc/sys/net/ipv4/ip_forward# para determinar si IP forwarding está habilitado. En FreeBSD, man:sysctl[8] se usa para ver esta y otras configuraciones del sistema. Por ejemplo, utilice el siguiente comando para comprobar si IP forwarding está habilitado en FreeBSD: [source,shell] .... % sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 .... Use `-a` para listar todos los ajustes del sistema: [source,shell] .... % sysctl -a | more .... Si una aplicación necesita procfs, añada la siguiente línea a [.filename]#/etc/fstab#: [source,shell] .... proc /proc procfs rw,noauto 0 0 .... Incluir `noauto` evitará que [.filename]#/proc# se monte automáticamente en el arranque. Para montar el sistema de archivos sin reiniciar: [source,shell] .... # mount /proc .... [[commands]] == Comandos comunes Algunos equivalentes de los comandos comunes son los siguientes: [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Linux command (Red Hat/Debian) | Equivalente en FreeBSD | Objetivo |`yum install _package_` / `apt-get install _package_` |`pkg install _package_` |Instalar el paquete desde el repositorio remoto |`rpm -ivh _package_` / `dpkg -i _package_` |`pkg add _package_` |Instalar un paquete local |`rpm -qa` / `dpkg -l` |`pkg info` |Listar los paquetes instalados |`lspci` |`pciconf` |Listar los dispositivos PCI |`lsmod` |`kldstat` |Listar los módulos cargados en el kernel |`modprobe` |`kldload` / `kldunload` |Cargar/Descargar módulos del kernel |`strace` |`truss` |Rastrear llamadas al sistema |=== [[conclusion]] == Conclusión This document has provided an overview of FreeBSD. Refer to the link:{handbook}[FreeBSD Handbook] for more in-depth coverage of these topics as well as the many topics not covered by this document. diff --git a/documentation/content/es/articles/mailing-list-faq/_index.adoc b/documentation/content/es/articles/mailing-list-faq/_index.adoc index 4e157b5578..0f480e5049 100644 --- a/documentation/content/es/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/es/articles/mailing-list-faq/_index.adoc @@ -1,164 +1,174 @@ --- title: Preguntas más frecuentes sobre las listas de correo de FreeBSD authors: - author: The FreeBSD Documentation Project copyright: 2004-2005 The FreeBSD Documentation Project releaseinfo: "$FreeBSD$" --- = Preguntas más frecuentes sobre las listas de correo de FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Estas son las FAQ de las listas de correo de FreeBSD. Si está interesado en ayudar con este proyecto, envíe un correo electrónico a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de correo del proyecto de documentación de FreeBSD]. La última versión de este documento está siempre disponible en el link:{mailing-list-faq}[servidor de FreeBSD]. También se puede descargar como un único archivo link:.[HTML] con HTTP o como texto plano, PostScript, PDF, etc. desde el https://download.freebsd.org/ftp/doc/[servidor FTP de FreeBSD]. También es posible que desee https://www.FreeBSD.org/search/[Buscar en las FAQ]. ''' toc::[] [[introduction]] == Introducción Como es habitual en las FAQ, este documento pretende cubrir las preguntas más frecuentes relacionadas con las listas de correo de FreeBSD (¡y por supuesto, responderlas!). Aunque originalmente tenía la intención de reducir el ancho de banda y evitar que se hicieran las mismas preguntas una y otra vez, las FAQ han sido reconocidas como un recurso de información valioso. Este documento intenta representar el consenso de la comunidad y, como tal, jamás debería ser __autoritario__. Sin embargo, si encuentra errores técnicos en este documento o tiene sugerencias sobre elementos que deban añadirse, por favor envíe un PR o un correo electrónico a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de correo del proyecto de documentación de FreeBSD]. Gracias. === ¿Cuál es el propósito de las listas de correo de FreeBSD? Las listas de correo de FreeBSD constituyen el canal principal de comunicación de la comunidad de FreeBSD, cubriendo varias áreas y comunidades de intereses diferentes. === ¿Quién es el público de las listas de correo de FreeBSD? Esto depende del cometido oficial de cada lista en particular. Algunas listas están más orientadas a los desarrolladores; otras están más orientadas hacia la comunidad de usuarios de FreeBSD en general. Por favor, vea http://lists.FreeBSD.org/mailman/listinfo[esta lista] para un resumen actual. === ¿Las listas de correo de FreeBSD están abiertas para que cualquiera pueda participar? 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 un correo a la lista y siga la filosofía de dicha lista en los envíos que haga. Esto ayudará al resto de usuarios a sacar más provecho de la lista. Si despué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 no subscriptores. Esta ha sido una elección deliberada, para ayudar a que unirse a la comunidad de FreeBSD sea un proceso más fácil y para fomentar el intercambio abierto de ideas. No obstante, debido a los abusos de envío masivo de correos por parte de algunos individuos, ciertas listas ahora tienen una política según la cual las publicaciones de no suscriptores deben seleccionarse manualmente para asegurarse de que sean apropiadas. === ¿Cómo puedo suscribirme? Puede utilizar la http://lists.FreeBSD.org/mailman/listinfo[interfaz web de Mailman] para suscribirse a cualquiera de las listas públicas. === ¿Cómo puedo darme de baja? Puede utilizar exactamente la misma interfaz que en el caso anterior; o puede 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. Primero, con esto no obtendrá su objetivo, y en segundo lugar, irritará a los subscriptores y probablemente será increpado por ello. Se trata de un error bastante común cuando se comienza a utilizar listas de correo; por favor, intente evitarlo. === ¿Están los archivos históricos disponibles? Sí. Los archivos agrupados por hilo están disponibles http://docs.FreeBSD.org/mail/[aquí]. === ¿Las listas de correo están disponibles en un formato resumen (digest)? Sí. Consulte http://lists.FreeBSD.org/mailman/listinfo[la interfaz web de Mailman]. [[etiquette]] == 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 únicamente 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. Sin embargo, si es nuevo en FreeBSD, es posible que primero deba familiarizarse con el software y toda la historia social que lo rodea, leyendo los numerosos https://www.FreeBSD.org/docs/books/[libros y artículos disponibles]. Son puntos de particular interés el documento link:{faq}[Las preguntas más frecuentes en FreeBSD (FAQ)], el link:{handbook}[Manual de FreeBSD] y los artículos link:{freebsd-questions-article}[Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions], link:{explaining-bsd}[Explicando BSD], y link:{new-users}[Primeros pasos en FreeBSD]. Enviar una consulta sobre algo que ya está respondido en los documentos anteriores se considera malas formas. Esto no ocurre 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. Tenga siempre en cuenta que casi todo el trabajo realizado en FreeBSD lo realizan voluntarios, y que solo somos humanos. === ¿Qué se considera un mensaje inapropiado? * Las publicaciones deben seguir el charter de la lista de correo. * Por favor, evite los ataques personales. Como buenos ciudadanos de la red, debemos tratar de mantenernos en unos altos estándares de comportamiento. * 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ían 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 avanzadas. * 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 [.filename]#config.log# o un amplio seguimiento de la pila, considere colocar esa información en un sitio web y proporcione solo la URL. Recuerde, también, que estas publicaciones se archivarán indefinidamente, por lo que las publicaciones enormes aumentarán el tamaño de los archivos mucho después de que su propósito haya expirado. * Formatee su mensaje de forma que sea legible, y, ¡¡¡¡¡POR FAVOR NO GRITE!!!!! No subestime el efecto que tiene un mensaje de correo mal formateado, y no solo en las listas de correo de FreeBSD. Su mensaje de correo es todo lo que la gente ve de usted, y si está mal formateado, mal escrito, lleno de errores y/o tiene muchos signos de exclamación, dará a la gente una mala impresión de usted. * 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 https://www.FreeBSD.org/community/mailinglists/[enlace]. + Para los que no lo son, sabemos que muchas personas no hablan inglés como primer idioma, y tratamos de hacer concesiones. Criticar a hablantes de inglés no nativos por una gramática pobre o errores en su escritura se consideran (muy) malos modos. FreeBSD posee un excelente bagaje en este tema; por favor ayúdenos a mantener esta tradición. * Por favor utilice un Mail User Agent (MUA) que cumpla los estándares de correo electrónico. Muchos mensajes mal formateados provienen de http://www.lemis.com/grog/email/email.php[correos incorrectos o 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: ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) + Trate de no usar MIME: muchas personas usan correos que no se llevan muy bien con MIME. * Asegúrese de que su hora y zona horaria están configuradas correctamente. Esto puede parecer un poco estúpido a primera vista, ya que su mensaje será recibido, pero muchas de las personas en estas listas de correo reciben varios cientos de mensajes al día. Frecuentemente, ordenan los mensajes entrantes por asunto y por fecha, y si su mensaje no aparece antes de la primera respuesta, pueden asumir que lo pasaron por alto y no molestarse en mirar. * Mucha de la información que deberá proporcionar es la salida de programas, como man:dmesg[8] o mensajes de consola, que generalmente aparecen en [.filename]#/var/log/messages#. No intente copiar esta información escribiéndola nuevamente; no solo es un trabajo penoso sino 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, + [source,shell] .... % dmesg > /tmp/dmesg.out .... + Esto redirige la información al fichero [.filename]#/tmp/dmesg.out# * Cuando utilice cortar y pegar, tenga en cuenta que algunas de estas operaciones estropean sus mensajes. Este hecho es de particular importancia cuando se trata de enviar el contenido de ficheros [.filename]#Makefiles#, donde el `tabulador` es un carácter separador muy importante. Este es uno de los problemas más comunes de los envíos https://www.FreeBSD.org/support/[a la base de datos de informes de problemas]. Los [.filename]#Makefiles# con tabuladores transformados en espacios, o transformados en la secuencia de escape `=3B`, crean 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. Recórtelo al mínimo, pero no exagere. 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 "sí, yo también veo esto", donde el mensaje original formado por cientos de líneas no aparece. * Utilice alguna técnica para identificar entre el texto original del mensaje y el texto que usted añada. Una convención común es anteponer "`>`" al mensaje original. Dejar espacios en blanco después de "`>`" y dejar líneas en blanco entre nuestro texto y el texto original. * Asegúrese de que las atribuciones del texto que está citando son correctas. Las personas pueden ofenderse si les atribuye palabras que ellos mismos no escribieron. * Por favor, no haga `top post`. Con esto, queremos decir que si está respondiendo a un mensaje, ponga sus respuestas después del texto. + ** R: Porque invierte el flujo lógico de la conversación. ** P: ¿Por qué el top posting está mal visto? + (Gracias a Randy Bush por la broma.) [[recurring]] == Temas 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 la comunicación. Muchas de las listas de correo presuponen un conocimiento de la historia del proyecto. En particular, existen ciertos temas que suelen aparecer regularmente a los recién llegados a la comunidad. Es responsabilidad de cada participante comprobar que sus mensajes no caen en alguna de estas categorías. Al hacerlo, ayudará a mantener a la lista en el tema, y probablemente se salve de ser atacado en el proceso. El mejor método para evitar esto consiste en familiarizarse con los http://docs.FreeBSD.org/mail/[archivos de las listas], así sabrá qué temas se han tratado con anterioridad. En este aspecto resulta de gran valor https://www.FreeBSD.org/search/#mailinglists[la interfaz de búsqueda] de la lista de correo. (Si ese método no produce resultados útiles, complételo con una búsqueda en su motor de búsqueda principal favorito). Si se familiariza con los archivos históricos, no solo aprenderá sobre los temas que se han tratado anteriormente, también aprenderá cómo se produce la discusión en la lista, quiénes son los participantes y quién es el público objetivo. Estos puntos conviene conocerlos antes de preguntar en cualquier lista de correo, no solo en las de FreeBSD. No hay duda de que los archivos son bastante extensos, y algunas preguntas se repiten con más frecuencia que otras, algunas veces camufladas dentro de hilos donde la línea del asunto no refleja precisamente el nuevo contenido del mensaje. Sin embargo, es trabajo suyo, quien envía el mensaje, evitar que se produzcan temas recurrentes. [[bikeshed]] == ¿Qué 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 FreeBSD, el término se refiere a temas que son tan simples que (casi) cualquiera puede ofrecer una opinión y, a menudo (casi), todos lo hacen. El origen de este término se explica con más detalle en link:{faq}#bikeshed-painting[este documento]. Simplemente debe tener un conocimiento práctico de este concepto antes de publicar en cualquier lista de correo de FreeBSD. De una forma más general, un bikeshed es un asunto que tiende a generar meta-discusiones y ataques si no se han leído las discusiones anteriores. Por favor, colabore en el mantenimiento de las listas de correo evitando los bikesheds siempre que pueda. Gracias. [[acknowledgments]] == Agradecimientos Greg Lehey mailto:grog@FreeBSD.org[grog@FreeBSD.org]:: Autor original de la mayor parte del material que cubre las normas de etiqueta de las listas, tomadas del artículo link:{freebsd-questions-article}[Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions]. Mark Linimon mailto:linimon@FreeBSD.org[linimon@FreeBSD.org]:: Por la creación del borrador inicial de estas FAQ. diff --git a/documentation/content/es/articles/port-mentor-guidelines/_index.adoc b/documentation/content/es/articles/port-mentor-guidelines/_index.adoc index 070759c23e..28265201a6 100644 --- a/documentation/content/es/articles/port-mentor-guidelines/_index.adoc +++ b/documentation/content/es/articles/port-mentor-guidelines/_index.adoc @@ -1,106 +1,116 @@ --- title: Instrucciones para los mentores de ports organizations: - organization: The FreeBSD Ports Management Team copyright: 2011 Thomas Abthorpe, Chris Rees releaseinfo: "$FreeBSD$" trademarks: [] --- = Instrucciones para los mentores de ports :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] ''' toc::[] [[port-mentor-guidelines]] == Guía para las relaciones mentor/aprendiz Esta sección está destinada a ayudar a desmitificar el proceso de orientación (mentoría), así como a promover abiertamente una discusión constructiva para adaptar y desarrollar las directrices. En nuestras vidas tenemos demasiadas reglas; no somos una organización gubernamental que impone una regulación, sino un colectivo de personas afines que trabajan para lograr un objetivo común, manteniendo la garantía de calidad del producto que llamamos árbol de ports. [[why-mentor]] === ¿Por qué hacer de mentor? * La mayoría de nosotros, fuimos guiados en el proyecto, así que devolvamos el favor ofreciendo guía a alguien más. * Tiene un impulso irresistible de traspasar conocimiento a otros. * ¡Es un castigo habitual y está cansado de hacer los commits del buen trabajo de otra persona! [[mentor-comentor]] === Mentor/Comentor Razones para una coorientación: * Diferencia significativa de zona horaria. ¡Los mentores accesibles y disponibles a través de IM son extremadamente útiles! * Barrera de idioma potencial. Sí, FreeBSD está muy orientado al inglés, al igual que ocurre en el resto del área del desarrollo de software, sin embargo, tener un mentor que hable un idioma nativo puede ser muy útil. * ¡ENOTIME! Hasta que haya un día de 30 horas y una semana de 8 días, algunos de nosotros no tenemos mucho tiempo para dedicar. Compartir la carga con otra persona hará que sea más fácil. * Un mentor novato puede beneficiarse de la experiencia de un committer/mentor senior. * Dos cabezas piensan más que una. Razones para la mentoría en solitario: * No trabaja bien con otras personas. * Prefiere tener una relación de uno a uno. * Las razones para la cotutoría no le interesan. [[mentor-expectations]] === Expectativas Esperamos que los mentores revisen y prueben todos los parches propuestos, al menos durante un período inicial con una duración mayor a una o dos semanas. Esperamos que los mentores se responsabilicen de las acciones de su aprendiz. Un mentor debe hacer un seguimiento con todos los commits que el aprendiz hace, tanto los aprobados como los implícitos. Esperamos que los mentores se aseguren de que sus aprendices lean el link:{porters-handbook}[Manual del Porter], la link:{pr-guidelines}[Guía para el manejo de informes de problemas], y la link:{committers-guide}[Guía del Committer]. Si bien no es necesario memorizar todos los detalles, cada persona debe tener una visión general de estas cosas para ser parte efectiva de la comunidad (y evitar tantos errores de novato como sea posible). [[mentees]] === Selección de un aprendiz No hay una regla definida sobre qué hace que un candidato esté listo; puede ser una combinación de la cantidad de PR que ha enviado, la cantidad de ports mantenidos, la frecuencia de las actualizaciones de los ports y/o el nivel de participación en un área específica de interés como GNOME, KDE, Gecko u otros. Un candidato no debería de tener timeouts, responder a las solicitudes y, en general, ser útil en el soporte de sus ports. Debe haber un historial de compromiso, ya que es ampliamente entendido que la capacitación de un committer requiere tiempo y esfuerzo. Si alguien ha estado más tiempo, y ha observado cómo se hacen las cosas, hay un cierto conocimiento acumulado previamente. Con demasiada frecuencia, hemos visto a un maintaner enviar algunos PRs, aparecer en el IRC y preguntar cuándo recibirán derechos de commit. Estar suscrito y seguir las listas de correo es muy beneficioso. No hay una expectativa real de que el envío de publicaciones a las listas convierta a alguien en un committer, pero demuestra compromiso. Algunos correos electrónicos ofrecen información sobre el conocimiento de un candidato y también cómo interactúan con otras personas. Del mismo modo, participar en el IRC puede darle a alguien un perfil superior. Pregunte a seis committers diferentes cuántos PRs debe enviar un maintainer antes de ser nominado, y obtendrá seis respuestas diferentes. Pregunte a las mismas personas cuánto tiempo debería estar participando, el mismo dilema. ¿Cuántos ports deberían tener como mínimo? ¡Ahora tenemos un bikeshed! Algunas cosas son difíciles de cuantificar, el mentor tendrá que usar su mejor juicio y esperar que Portmgr esté de acuerdo. [[mentorship-duration]] === Duración de la tutoría A medida que el nivel de confianza crece y evoluciona, el aprendiz puede recibir derechos de commit "implícitos". Esto puede incluir cambios triviales en un [.filename]#Makefile#, [.filename]#pkg-descr#, etc. De manera similar, puede incluir actualizaciones de `PORTVERSION` que no incluyan cambios de `plist`. Otras circunstancias pueden ser formuladas a criterio del mentor. Sin embargo, durante el período de orientación, un mentor debe verificar un aumento en la versión de un port que afecte a los ports que dependan de él. Cada persona es diferente, cada aprendiz tiene una curva de aprendizaje diferente, el tiempo de dedicación y otros factores influyen en el tiempo requerido antes de que puedan "volar en solitario". Empíricamente, un aprendiz debe ser observado por al menos 3 meses. 90-100 commits es otro objetivo que un mentor podría usar antes de finalizar con un aprendiz. Otros factores a considerar antes de finalizar con un aprendiz son el número de errores que pueden haber cometido, QATs recibidos, etc. Si todavía están cometiendo errores de novato, todavía requieren la guía de un mentor. [[mentor-comentor-debate]] === Debate mentor/comentor Cuando una solicitud llega a Portmgr, generalmente viene como, "yo propongo a 'foo' para que obtenga derechos de commit en los ports, yo seré el comentor con 'bar'". Propuesta recibida, votada y ejecutada. El mentor es el principal punto de contacto o el "primero entre los iguales", el comentor es el respaldo. Algunas personas, cuyo nombre será omitido, hicieron el https://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html[primer commit aprobado por un comentor registrado]. Commits similares, aprobados por un comentor fueron vistos en el árbol src. ¿Es correcto? ¿Es incorrecto? Parece parte de la evolución de cómo se hacen las cosas. [[mentee-expectations]] === Expectativas Esperamos que los aprendices estén preparados para las críticas constructivas de la comunidad. Todavía hay mucha "sabiduría popular" que no está escrita. Responder bien a una crítica constructiva es lo que esperamos al analizar sus contribuciones existentes en el IRC y en las listas de correo. Les advertimos a los aprendices que algunas de las críticas que reciben pueden ser menos "constructivas" que otras, (ya sea por problemas de comunicación lingüística o por ser muy quisquillosos) y lidiar con gracia es solo parte de estar en una gran comunidad. En caso de problemas específicos con personas específicas, o cualquier duda, esperamos que se acerquen a un miembro de portmgr en el IRC o por correo electrónico. diff --git a/documentation/content/es/articles/pr-guidelines/_index.adoc b/documentation/content/es/articles/pr-guidelines/_index.adoc index cf2a79f983..ae1f519715 100644 --- a/documentation/content/es/articles/pr-guidelines/_index.adoc +++ b/documentation/content/es/articles/pr-guidelines/_index.adoc @@ -1,479 +1,489 @@ --- title: Guía para el manejo de informes de problemas authors: - author: Dag-Erling Smørgrav - author: Hiten Pandya releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "general"] --- = Guía para el manejo de informes de problemas :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Esta guía describe las prácticas recomendadas para manejar los informes de problemas (PRs) de FreeBSD. Aunque se desarrolló para el FreeBSD PR database maintenance team mailto:freebsd-bugbusters@FreeBSD.org[freebsd-bugbusters@FreeBSD.org], cualquiera que trabaje con PRs de FreeBSD debe seguir estas pautas. ''' toc::[] [[intro]] == Introducción Bugzilla es un sistema de gestión de errores que utiliza el proyecto FreeBSD. El seguimiento preciso de los defectos de software pendientes es importante para la calidad de FreeBSD. Del mismo modo, el uso correcto del software es esencial para el progreso del proyecto. El acceso a Bugzilla está abierto a toda la comunidad de FreeBSD. Se han establecido ciertas pautas para cubrir aspectos comunes de la gestión de errores como la presentación del seguimiento, la gestión de solicitudes de cierre, etc con el fin de mantener la coherencia dentro de la base de datos y proporcionar una experiencia de usuario consistente. [[pr-lifecycle]] == Ciclo de vida de un informe de problemas * El usuario envía un informe de error al sitio web. El error está en el estado `Needs Triage`. * Jane Random BugBuster confirma que el error reportado contiene la suficiente información para ser reproducido. Si no, se interactuará repetidamente con el usuario hasta obtener la información necesaria. En este punto el error se establece en el estado `Open`. * Joe Random Committer se interesa por el PR y se lo asigna a si mismo, o Jane Random BugBuster decide que Joe es la persona más adecuada para resolver el problema y le asigna el error. El error se debe poner en el estado `In Discussion`. * Joe tiene una breve conversación con el usuario que ha enviado el informe del problema (asegurándose de que todo queda registrado) y determina la causa. * Joe está toda la noche trabajando y elabora un parche que cree que soluciona el problema y lo envía en un follow-up, pidiéndole al usuario que lo ha reportado que lo pruebe. A continuación fija el estado del PR en `Patch Ready`. * Un par de interaciones más tarde tanto Joe como el usuario que lo ha creado están satisfechos con el parche y Joe realiza el commit a `-CURRENT` (o directamente a `-STABLE` si el problema no existe en `-CURRENT`), asegurándose de hacer referencia al informe de problemas en su log del commit (y dando el crédito al usuario si envió todo o parte del parche) y, si corresponde, iniciará una cuenta atrás de MFC. El error se fija en el estado `Needs MFC`. * Si el parche no necesita pasar por un MFC Joe cierra el PR con el estado `Issue Resolved`. [NOTE] ==== Muchos PRs se envían con muy poca información sobre el problema y algunos son muy complejos de resolver, o simplemente arañan la superficie de un problema mayor; en estos casos es muy importante conseguir toda la información necesaria para resolver el problema. Si el problema no se puede resolver o si el problema se repite, es necesario volver a abrir el PR. ==== [[pr-states]] == Estados de los informes de problemas Es importante actualizar el estado de un PR cuando se llevan a cabo ciertas acciones. .Un ejemplo simple de cuándo cambiar el estado de un PR. [example] ==== Cuando un PR se haya gestionado y el/los desarrollador/es estén satisfechos con la solución se envia un follow-up al PR y su estado cambiará a "feedback". En este punto el usuario que lo ha creado debe evaluar la solución en su contexto y responder indicando si el defecto ha sido solucionado. ==== Un informe de problemas puede estar en uno de los siguientes estados: [.glosslist] open:: Estado inicial: el problema ha sido reportado y necesita ser revisado. analyzed:: El problema consta como revisado y se está buscando una solución. feedback:: Hay que realizar trabajos adicionales que requieren más información del usuario o de la comunidad; es posible que haga falta también más información sobre la solución propuesta. patched:: Se ha realizado un commit con el parche, pero aún hay algo pendiente (MFC o tal vez confirmación del usuario que lo creó). suspended:: No se está trabajando en el problema debido a la falta de información o recursos. Este es un candidato excelente para alguien que esté buscando un proyecto. Si el problema no se puede resolver se cerrará en lugar de suspenderse. El proyecto de documentación utiliza suspended para los elementos de la wish-list que implican una cantidad significativa de trabajo para el cual nadie dispone de tiempo. closed:: Un informe de problemas se cierra cuando se han integrado, documentado y probado los cambios o cuando se abandona la solución del problema. [NOTE] ==== El estado "patched" está directamente relacionado con el feedback, por lo que puede ir directamente al estado "closed" si el usuario que lo creó no puede probar el parche y funciona en sus propias pruebas. ==== [[pr-types]] == Tipos de informes de problemas Al tratar con informes de problemas, ya sea como desarrollador que tiene acceso directo a la base de datos de informes de problemas o como colaborador que navega por la base de datos y envía follow-ups con parches, comentarios, sugerencias o solicitudes de cambio, va a encontrarse usted con distintos tipos de PRs. * <> * <> * <> * <> * <> Las siguientes secciones describen para qué se usa cada tipo de PRs, cuándo un PR pertenece a uno de estos tipos y qué tratamiento recibe cada tipo. [[pr-unassigned]] == PRs sin asignar Cuando los PRs llegan se asignan en primer lugar a un responsable genérico (placeholder). Estos siempre tienen el prefijo `freebsd-`. El valor exacto para este patrón depende de la categoría. En la mayoría de los casos corresponde a una lista de correo específica de FreeBSD. Esta es una lista actualizada con los más comunes en primer lugar: [[default-assignees-common]] .Asignaciones predeterminadas -- más comunes [cols="1,1,1", options="header"] |=== | Tipo | Categorías | Asignación predeterminada |sistema base |bin, conf, gnu, kern, misc |freebsd-bugs |arquitectura específica |alpha, amd64, arm, i386, ia64, powerpc, sparc64 |freebsd-_arch_ |colección de ports |ports |freebsd-ports-bugs |documentación enviada junto con el sistema |docs |freebsd-doc |páginas web de FreeBSD (sin incluir docs) |sitio web |freebsd-www |=== [[default-assignees-other]] .Asignaciones predeterminadas -- otros [cols="1,1,1", options="header"] |=== | Tipo | Categorías | Asignación predeterminada |labores de promoción |promoción |freebsd-advocacy |problemas con la Java Virtual Machine(TM) |java |freebsd-java |cumplimiento de estándares |estándares |freebsd-standards |bibliotecas de threading |threads |freebsd-threads |subsistema man:usb[4] |usb |freebsd-usb |=== Es bastante habitual que el usuario responsable del PR lo asigne a la categoría incorrecta. Si usted corrige la categoría recuerde por favor que hay que corregir también la asignación. Nuestros usuarios parecen tener dificultades en particular con el hecho de que aunque su problema ocurra en un sistema i386 podría afectar a todas las plataformas de FreeBSD y por lo tanto ser más adecuado para `kern`. Lo contrario también sucede, por supuesto. Cualquiera puede reasignar estos PR de sus responsables genéricos a otra persona en grupo. Hay varios tipos de responsables: listas de correo especializadas, alias de correo (utilizados para asuntos muy específicos) de interés limitado) e individuos. Para los responsables que son listas de correo utilice la designación larga al realizar la asignación: por ejemplo, `freebsd-foo` en lugar de `foo`. Así evitará los correos electrónicos duplicados enviados a las listas de distribución. [NOTE] ==== Como la lista de personas que se han ofrecido voluntarias para ser los responsables predeterminados para ciertos tipos de PRs cambia con bastante frecuencia es mucho más adecuado recurrir a la https://wiki.freebsd.org/AssigningPRs[wiki de FreeBSD]. ==== A continuación hay un listado con ejemplos de dichas entidades. Es probable que el listado no sea exhaustivo. [[common-assignees-base]] .Responsables comunes -- sistema base [cols="1,1,1,1", options="header"] |=== | Tipo | Categoría sugerida | Responsable sugerido | Tipo de responsable |problema específico de la arquitectura ARM(R). |arm |freebsd-arm |lista de correo |problema específico de la arquitectura MIPS(R) |kern |freebsd-mips |lista de correo |problema específico de la arquitectura PowerPC(R) |kern |freebsd-ppc |lista de correo |problema con la interfaz avanzada de configuración y energía (man:acpi[4]) |kern |freebsd-acpi |lista de correo |problema con los controladores del modo de transferencia asíncrono (ATM) |kern |freebsd-atm |lista de correo |problemas con sistemas FreeBSD embebidos o de small-footprint (por ejemplo, NanoBSD/PicoBSD/FreeBSD-arm) |kern |freebsd-embedded |lista de correo |problema con los controladores de FireWire(R) |kern |freebsd-firewire |lista de correo |problema con el código fuente del sistema de archivos |kern |freebsd-fs |lista de correo |problema con el subsistema man:geom[4] |kern |freebsd-geom |lista de correo |problema con el subsistema man:ipfw[4] |kern |freebsd-ipfw |lista de correo |problema con los controladores de la red digital de servicios integrados (ISDN) |kern |freebsd-isdn |lista de correo |subsistema man:jail[8] |kern |freebsd-jail |lista de correo |problema con la emulación Linux(R) o SVR4 |kern |freebsd-emulation |lista de correo |problema con el stack de red |kern |freebsd-net |lista de correo |problema con el subsistema man:pf[4] |kern |freebsd-pf |lista de correo |problema con el subsistema man:scsi[4] |kern |freebsd-scsi |lista de correo |problema con el subsistema man:sound[4] |kern |freebsd-multimedia |lista de correo |problema con el subsistema y controladores wireless man:wlan[4] |kern |freebsd-wireless |lista de correo |problema con man:sysinstall[8] o man:bsdinstall[8] |bin |freebsd-sysinstall |lista de correo |problema con los scripts de inicio del sistema (man:rc[8]) |kern |freebsd-rc |lista de correo |problema con la funcionalidad VIMAGE o VNET y el código relacionado |kern |freebsd-virtualization |lista de correo |problema con la emulación de Xen |kern |freebsd-xen |lista de correo |=== [[common-assignees-ports]] .Responsables comunes -- coleción de ports [cols="1,1,1,1", options="header"] |=== | Tipo | Categoría sugerida | Responsable sugerido | Tipo de responsable |problema con el framework de ports (¡__no__ con un port en concreto!) |ports |portmgr |alias |port mantenido por apache@FreeBSD.org |ports |apache |lista de correo |port mantenido por autotools@FreeBSD.org |ports |autotools |alias |port mantenido por doceng@FreeBSD.org |ports |doceng |alias |port mantenido por eclipse@FreeBSD.org |ports |freebsd-eclipse |lista de correo |port mantenido por gecko@FreeBSD.org |ports |gecko |lista de correo |port mantenido por gnome@FreeBSD.org |ports |gnome |lista de correo |port mantenido por hamradio@FreeBSD.org |ports |hamradio |alias |port mantenido por haskell@FreeBSD.org |ports |haskell |alias |port mantenido por java@FreeBSD.org |ports |freebsd-java |lista de correo |port mantenido por kde@FreeBSD.org |ports |kde |lista de correo |port mantenido por mono@FreeBSD.org |ports |mono |lista de correo |port mantenido por office@FreeBSD.org |ports |freebsd-office |lista de correo |port mantenido por perl@FreeBSD.org |ports |perl |lista de correo |port mantenido por python@FreeBSD.org |ports |freebsd-python |lista de correo |port mantenido por ruby@FreeBSD.org |ports |freebsd-ruby |lista de correo |port mantenido por secteam@FreeBSD.org |ports |secteam |alias |port mantenido por vbox@FreeBSD.org |ports |vbox |alias |port mantenido por x11@FreeBSD.org |ports |freebsd-x11 |lista de correo |=== Los PRs relacionados con los ports que tienen un maintainer que es a la vez un committer de ports pueden ser reasignados por cualquiera, pero es importante recordar que no todos los committers de FreeBSD tienen un commit bit de ports, por lo que no puede guiarse únicamente por la dirección de correo electrónico. En el caso de otros PRs por favor no los reasigne a otros individuos (que no sean usted) a menos que esté seguro de que el responsable realmente quiere estar al tanto del PR. Esto ayudará a evitar situaciones en las que nadie se dedica a solucionar un problema en particular porque todo el mundo implicado asume que el responsable ya está en ello. [[common-assignees-other]] .Responsables comunes -- otros [cols="1,1,1,1", options="header"] |=== | Tipo | Categoría sugerida | Responsable sugerido | Tipo de responsable |problema con la base de datos de PR |bin |bugmeister |alias |problema con el https://bugs.freebsd.org/submit/[formulario web] de Bugzilla. |doc |bugmeister |alias |=== [[pr-assigned]] == PRs asignados Si un PR tiene el campo `responsible` establecido con el nombre de usuario de un desarrollador de FreeBSD significa que el PR se ha entregado a esa persona en particular para que desarrolle sobre él trabajo adicional. Los PRs asignados no deben ser modificados por nadie más que el responsable o el bugmeister. Si tiene algún comentario que hacer al respecto envíe un follow-up. Si por algún motivo cree que el PR debe cambiar de estado o reasignarse envíe un mensaje al responsable. Si el responsable no responde en dos semanas anule la asignación del PR y haga lo que estime conveniente. [[pr-dups]] == PRs duplicados Si encuentra más de un PR que describe el mismo problema elija el que contiene la mayor cantidad de información útil y cierre los demás indicando claramente el número de PR sustituidos. Si varios PRs contienen información útil que no está repetida envíe toda la información restante en un follow-up, incluidas las referencias a los demás. Cierre después los otros PRs una vez hayan sido completamente reemplazados. [[pr-stale]] == PRs obsoletos Un PR se considera obsoleto si no ha sido modificado en más de seis meses. Siga el siguiente procedimiento para gestionar PRs obsoletos: * Si el PR contiene suficientes detalles intente reproducir el problema en `-CURRENT` y en `-STABLE`. Si logra reproducir el problema envíe un follow-up detallando sus hallazgos e intente encontrar a alguien a quien asignárselo. Establezca el estado en "analyzed" si ese es el caso. * Si el PR describe un problema que sabe que es el resultado de un error de uso (configuración incorrecta o de otro tipo) envíe un follow-up que explique qué hizo mal el usuario. Más tarde cierre el PR con el motivo "User error" o "Configuration error". * Si el PR describe un error que sabe que ha sido corregido tanto en `-CURRENT` como en `-STABLE` ciérrelo con un mensaje que indique cuándo se solucionó en cada rama. * Si el PR trata de un error que sabe que ha sido corregido en `-CURRENT` pero no en `-STABLE` intente averiguar cuándo espera la persona que lo corrigió ejecutar el MFC, o intente encontrar a alguien más (quizás usted mismo) que pueda hacerlo. Establezca el estado en "patched" y asígnelo a quien quiera que se haya encargado de hacer el MFC. * En cualquier otro caso solicite al usuario que confirme si el problema persiste en las versiones más recientes. Si el usuario no responde en un mes cierre el PR con la anotación "Feedback timeout". [[pr-misfiled-notpr]] == PRs sin errores Los desarrolladores que encuentren PRs que han aparecido ya en http://lists.FreeBSD.org/mailman/listinfo/freebsd-bugs[freebsd-bugs] o alguna otra lista deberían cerrar el PR informando al usuario en un comentario por qué el problema reportado no es realmente un PR y dónde debe publicarse el mensaje. Las direcciones de correo electrónico que utiliza Bugzilla para recibir los PR se publican en la documentación de FreeBSD y se anuncian y publican en el sitio web. Esto significa que los spammers ya las tienen. Cuando cierre uno de estos PRs, haga lo siguiente: * Establezca el componente en `junk` (en `Supporting Services`). * Establezca como responsable a `nobody@FreeBSD.org`. * Establezca el estado en `Issue Resolved`. Establecer la categoría en `junk` indica que no hay contenido útil dentro del PR y ayuda a reducir el desorden en las categorías principales. [[references]] == Lecturas adicionales Esta es una lista de recursos relevantes para la correcta escritura y procesamiento de informes de problemas. De ninguna manera debe considerarse completa. * link:{problem-reports}[Cómo escribir informes de problemas para FreeBSD] -- directrices para los usuarios que envían un PR. diff --git a/documentation/content/es/articles/problem-reports/_index.adoc b/documentation/content/es/articles/problem-reports/_index.adoc index d14d6f9ec4..9b7242043d 100644 --- a/documentation/content/es/articles/problem-reports/_index.adoc +++ b/documentation/content/es/articles/problem-reports/_index.adoc @@ -1,237 +1,247 @@ --- title: Escribiendo informes de problemas de FreeBSD authors: - author: Dag-Erling Smørgrav - author: Mark Linimon releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "ibm", "intel", "sun", "general"] --- = Escribiendo informes de problemas de FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Este artículo describe cómo realizar y enviar informes de problemas para el proyecto FreeBSD de la mejor forma posible. ''' toc::[] [[pr-intro]] == Introducción Una de las experiencias más frustrantes que uno puede tener como usuario de software es enviar un informe de problemas solo para que se cierre sumariamente con una explicación breve e inútil como "no es un error" o "PR erróneo". De manera similar, una de las experiencias más frustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de problemas 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 cómo reproducirlo. Este documento intenta describir cómo escribir buenos informes de problemas. ¿Qué, se preguntará, es un buen informe de problemas? Bien, para ir directos al grano, un buen informe de problemas es aquél que se puede analizar y tratar rápidamente, para mutua satisfacción del usuario y del desarrollador. Aunque el objetivo principal de este artículo se centra en los informes de problemas de FreeBSD, la mayoría de los conceptos se pueden aplicar bastante bien en otros proyectos de software. Tenga en cuenta que este artículo está organizado temáticamente, no cronológicamente. Lea todo el documento antes de enviar un informe de problemas, en lugar de tratarlo como un tutorial paso a paso. [[pr-when]] == Cuándo enviar informes de problemas Hay muchos tipos de problemas y no todos ellos merecen la creación de un informe de problemas. Por supuesto, nadie es perfecto, y habrá ocasiones en que lo que parece ser un error en un programa es, de hecho, un malentendido de la sintaxis de un comando o un error tipográfico en un archivo 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, y solo servirá para frustrar tanto al remitente como a los desarrolladores. Por el contrario, hay casos en los que podría ser apropiado enviar un informe de problemas sobre algo más que un error: una mejora o una nueva característica, por ejemplo. Entonces, ¿cómo se determina qué es un error y qué no? Como regla general, el problema _no_ es un error si puede expresarse como una pregunta (normalmente del estilo de "¿Cómo hago X?" o "¿Dónde puedo encontrar Y?"). Las cosas no son siempre blancas o negras, pero la regla de la pregunta cubre la gran mayoría de los casos. Al buscar una respuesta, considere plantear la pregunta a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[lista de correo de preguntas generales de FreeBSD]. Tenga en cuenta estos factores al enviar PRs sobre ports u otro software que no sea parte de FreeBSD: * Por favor, no envíe informes de problemas que simplemente indiquen la disponibilidad de una nueva versión de una aplicación. Los maintainers de ports son notificados automáticamente por portscout cuando una nueva versión de una aplicación esta disponible. Los parches para actualizar un port a la última versión son bien recibidos. * Para los ports que no están mantenidos (el `MAINTAINER` es `ports@FreeBSD.org`), es poco probable que un PR sin un parche adjunto sea cogido por un committer. Para convertirse en el maintainer de un port que no este mantenido, envíe un PR con la petición (sería ideal si viene con un parche adjunto, pero no es necesario). * En cualquier caso, seguir el proceso descrito en el link:{porters-handbook}#port-upgrading[Manual del Porter] dará los mejores resultados. (Es posible que también desee leer link:{contributing}#ports-contributing[Cómo contribuir a la colección de ports de FreeBSD]). Un error que no se puede reproducir rara vez se podrá arreglar. Si el error solo ocurrió una vez y no puede reproducirlo, y no parece que le ocurra a nadie más, es probable que ninguno de los desarrolladores pueda reproducirlo o descubrir qué es lo que está mal. Eso no significa que no haya ocurrido, significa que las posibilidades de que su informe de problemas lleve a la corrección del error son muy escasas. Para empeorar las cosas, a menudo, este tipo de errores son en realidad causados por fallos en los discos duros o procesadores con sobrecalentamiento, siempre debe intentar descartar estas causas, siempre que sea posible, antes de enviar un PR. A continuación, para decidir a quién debe presentar su informe de problemas, debe comprender que el software que compone FreeBSD está compuesto de varios elementos diferentes: * El código en el sistema base que escriben y mantienen los colaboradores de FreeBSD, como el kernel, la biblioteca de C y los controladores de dispositivos (categorizados como `kern`); las utilidades binarias (`bin`); las páginas del manual y documentación (`docs`); y las páginas web (`www`). Todos los errores en estas áreas deben informarse a los desarrolladores de FreeBSD. * El código en el sistema base escrito y mantenido por otros, e importado y adaptado a FreeBSD. Los ejemplos incluyen man:clang[1] y man:sendmail[8]. La mayoría de los errores en estas áreas deben informarse a los desarrolladores de FreeBSD; pero en algunos casos es posible que deban informarse a los autores originales si los problemas no son específicos de FreeBSD. * Las aplicaciones individuales que no están en el sistema base, sino que forman parte de la colección de ports de FreeBSD (categoría `ports`). La mayoría de estas aplicaciones no están escritas por los desarrolladores de FreeBSD; lo que proporciona FreeBSD es simplemente un framework para instalar la aplicación. Por lo tanto, solo informe de un problema a los desarrolladores de FreeBSD cuando crea que el problema es específico de FreeBSD; de lo contrario, repórtelo a los autores del software. Después, averigüe si es un problema puntual. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un error que ya ha solucionado. Si el problema está en el sistema base, primero lea la sección de preguntas frecuentes sobre las link:{faq}#LATEST-VERSION[versiones de FreeBSD], si aún no está familiarizado con el tema. FreeBSD no puede solucionar problemas en otras ramas que no sean las más recientes del sistema base, por lo que presentar un informe de error sobre una versión anterior probablemente hará que un desarrollador le aconseje que se actualice a una versión soportada para comprobar si el problema todavía sucede. El equipo Security Officer mantiene https://www.FreeBSD.org/security/[la lista de versiones soportadas]. Si el problema está en un port, considere enviar el error al upstream. El proyecto FreeBSD no puede corregir todos los errores en todo el software. [[pr-prep]] == 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 correo o fue discutido hace poco; incluso puede que ya esté arreglado en una versión más nueva que la que está ejecutando. 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 FreeBSD, esto significa: * La lista de link:{faq}[preguntas más frecuentes] (FAQ) de FreeBSD. Las preguntas frecuentes intentan proporcionar respuestas a una amplia gama de preguntas, como las relacionadas con la link:{faq}#hardware[compatibilidad del hardware], las link:{faq}#applications[aplicaciones de usuario] y la link:{faq}#kernelconfig[configuración del kernel]. * Las link:{handbook}#eresources-mail[listas de correo], si no está suscrito, utilice la https://www.FreeBSD.org/search/#mailinglists[búsqueda en los archivos] del sitio web de FreeBSD. 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, toda la web: utilice su motor de búsqueda favorito para localizar cualquier referencia al problema. Incluso puede obtener listas de correo archivadas o grupos de noticias que no conocía o en los que no había pensado buscar. * A continuación, la búsqueda a través de la https://bugs.freebsd.org/bugzilla/query.cgi[base de datos de PR de FreeBSD] (Bugzilla). A menos que el 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. + Para el código base de FreeBSD, debe estudiar cuidadosamente el contenido del fichero [.filename]#/usr/src/UPDATING# del sistema o la versión más reciente en https://svnweb.freebsd.org/base/head/UPDATING?view=log[https://svnweb.freebsd.org/base/head/UPDATING?view=log]. (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si está actualizando a la rama de FreeBSD-CURRENT). + No obstante, si el problema se encuentra en algo que se instaló como parte de la colección de ports de FreeBSD, se debe consultar el archivo [.filename]#/usr/ports/UPDATING# (para ports individuales) o el archivo [.filename]#/usr/ports/CHANGES# (para cambios que afectan a la colección de ports completa). https://svnweb.freebsd.org/ports/head/UPDATING?view=log[https://svnweb.freebsd.org/port/head/UPDATING?view=log] y https://svnweb.freebsd.org/ports/head/CHANGES?view=log[https://svnweb.freebsd.org/ports/head/CHANGES?view=log] también están disponibles a través de svnweb. [[pr-writing]] == Escribiendo el informe de problemas Ahora que ha decidido que su problema merece un informe de problemas y que es un problema de FreeBSD, es el momento de escribir el informe de problemas propiamente dicho. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar y enviar los PRs, aquí hay algunos consejos y trucos para ayudarle a asegurarse de que su PR sea más efectivo. [[pr-writing-tips]] == Consejos y trucos para escribir un buen informe de problemas * _No deje el campo "Summary" vacío._ Los PRs se envían a una lista de correo global (donde se utiliza el campo "Summary" para la línea `Subject:`), y se almacenan en una base de datos. Cualquiera que haga una búsqueda por el campo synopsis (sinopsis) en la base de datos y encuentre un PR con la línea del subject (asunto) en blanco tiende a omitirlo. Recuerde que los PR permanecen en esta base de datos hasta que alguien los cierra; un PR que no esté debidamente cumplimentado pasará desapercibido. * _Rellene el campo "Summary" correctamente, no use descripciones vagas._ No asuma que aquella persona que lea su PR entienda el contexto que motivó su envío, por lo tanto, cuanta más información proporcione, mejor. Por ejemplo, ¿en qué parte del sistema se produce el problema? ¿El problema sucede solo durante la instalación o durante la ejecución del sistema? Por ejemplo, en lugar de, `Summary: portupgrade is broken`, podría utilizar este otro, el cual, tiene mucha más información: `Summary: port ports-mgmt/portupgrade coredumps on -current`. (En el caso de los ports, es especialmente útil tener el nombre de la categoría y el nombre del port en el campo "Summary"). * _Si tiene un parche, dígalo._ Es más probable que se analice un PR con un parche incluido que uno sin él. Incluya la palabra clave `patch` en Bugzilla. * __Si es un maintainer, dígalo__. Si mantiene una parte del código fuente (por ejemplo, un port que ya exista), debe establecer el campo "Class" de su PR a `maintainer-update`. De esta forma, cualquier committer que se ocupe de su PR no tendrá que verificarlo. * _Sea concreto._ Cuanta más información se proporcione sobre el problema que tiene, más posibilidades de obtener una respuesta. ** Incluya la versión de FreeBSD que está ejecutando (existe un lugar donde escribir esta información, vea a continuación) y en qué arquitectura. Debe incluir si se está ejecutando desde una release (por ejemplo, desde un CD-ROM o descarga), o si es desde un sistema mantenido por Subversion (y, si es así, en qué número de revisión se encuentra). Si está usando la rama FreeBSD-CURRENT, esa es la primera pregunta que le harán, porque las correcciones (especialmente para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera que los usuarios de FreeBSD-CURRENT se mantengan al día. ** Incluya qué opciones globales ha especificado en sus ficheros [.filename]#make.conf#, [.filename]#src.conf# y [.filename]#src-env.conf#. Dado el número infinito de opciones, no todas las combinaciones pueden ser totalmente compatibles. ** Si el problema se puede reproducir fácilmente, incluya información que ayude al desarrollador a reproducirlo por sí mismo. Si se puede hacer una demostración con una entrada específica, incluya un ejemplo con esa entrada, si es posible, e incluya la salida real y la esperada. Si la información es grande o no se puede hacer pública, intente crear un archivo con lo mínimo que muestre el mismo problema y que pueda incluirse en el PR. ** 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, pero sí puede merecer la pena incluir extractos que usted considere importantes): *** la configuración del kernel (incluidos los dispositivos de hardware que ha instalado) *** si tiene o no opciones de depuración activadas (como `WITNESS`), y si es así, si el problema persiste cuando se cambia el valor de dichas opciones *** el texto completo de cualquier backtrace, panic u otra salida por consola, o entradas en [.filename]#/var/log/messages#, si se generó alguna *** la salida de `pciconf -l` y partes relevantes de su salida `dmesg` si su problema se relaciona con una pieza específica de hardware *** el hecho de que haya leído [.filename]#src/UPDATING# y que su problema no esté listado (seguro que alguien le preguntará sobre este punto) *** si puede o no ejecutar otro kernel de respaldo sin problemas (se trata de descartar problemas relacionados con el hardware, como discos con errores o CPUs con sobrecalentamiento, 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 esto solo produce un crecimiento indeseado de la base de datos, pero debe incluir extractos que considere que pueden ser relevantes): *** Qué ports ha instalado *** Cualquier variable de entorno que sobrescriba los valores por defecto del archivo [.filename]#bsd.port.mk#, como `PORTSDIR` *** El hecho de que ha leído el archivo [.filename]#ports/UPDATING# y que su problema no se encuentra en la lista (puede preguntar a alguien) * _Evitar peticiones de características vagas._ Los PRs del estilo "alguien debería implementar algo que haga esto, aquello y lo de más allá" son informes con pocas probabilidades de obtener resultados positivos. Recuerde, el código fuente se encuentra disponible para todo el mundo, por lo tanto, si desea una característica, ¡la mejor manera de asegurarse de que se incluya es ponerse a trabajar en ella! También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista `freebsd-questions`, que una entrada en la base de datos de PR, como ya se ha comentado anteriormente. * _Asegúrese que nadie más ha enviado un PR similar._ Aunque esto ya se ha mencionado anteriormente, vale la pena repetirlo aquí. Solamente lleva uno o dos minutos utilizar el motor de búsqueda web en https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Por supuesto, todo el mundo es culpable de olvidarse de hacerlo de vez en cuando). * _Informe un solo problema por informe._ Evite incluir dos o más problemas dentro del mismo informe, a menos que estén relacionados. Al enviar parches, evite agregar múltiples funciones o corregir varios errores en el mismo PR, a menos que estén estrechamente relacionados -- ya que los PR suelen tardar más en resolverse. * _Evite peticiones controvertidas._ Si su PR se dirige a un área que ha sido controvertida en el pasado, probablemente debería estar preparado para no solo ofrecer parches, sino también una justificación de por qué los parches son la "forma correcta de hacerlo". Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo utilizando los archivos históricos en https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] es siempre una buena opción. * _Sea educado._ Practicamente cualquier persona que se encargue de tratar su PR es un voluntario. A nadie le gusta que le digan que tiene que hacer algo cuando ya lo están haciendo por alguna otra motivación que no sea la económica. Es bueno tenerlo en cuenta en todo momento en los proyectos de código abierto. [[pr-writing-before-beginning]] == Antes de comenzar Se aplican consideraciones similares al uso del formulario de envío de PR https://bugs.freebsd.org/bugzilla/enter_bug.cgi[por la aplicación web]. Tenga cuidado con las operaciones de cortar y pegar que puedan cambiar los espacios en blanco u otro formato de texto. Finalmente, si el envío es largo, prepare el trabajo sin conexión, de forma que no se pierda nada si hay un problema al enviarlo. [[pr-writing-attaching-patches]] == Adjuntar parches o archivos Al adjuntar un parche, asegúrese de usar `svn diff` o man:diff[1] con el argumento `-u` para crear un diff unificado, y asegúrese de especificar el número de revisión SVN del repositorio contra el que modificó los archivos, para que los desarrolladores que lean su informe puedan aplicarlos fácilmente. Para problemas relacionados con el kernel o utilidades del sistema base, se prefiere un parche contra FreeBSD-CURRENT (la rama HEAD de Subversion), ya que todo el código nuevo debe aplicarse y probarse allí primero. Después de que se hayan realizado las pruebas adecuadas o importantes, se hará el merge/migración a la rama FreeBSD-STABLE. Si adjunta un parche como parte del mensaje, en lugar de como adjunto, tenga en cuenta que uno de los problemas más comunes es la tendencia de algunos programas de correo electrónico de mostrar las tabulaciones como espacios, lo cual estropeará por completo todo lo que pretenda que forme parte de un Makefile. No envíe parches como archivos adjuntos usando `Content-Transfer-Encoding: quoted-printable`. Esto escapará el carácter (character escaping) y todo el parche será inútil. También tenga en cuenta que, incluir pequeños parches en un PR, en general, está bien, especialmente cuando soluciona el problema descrito en el PR, los parches grandes y especialmente el nuevo código que pueda requerir una revisión sustancial antes de realizar el commit deben colocarse en un servidor web o ftp, y la URL debe incluirse en el PR en lugar del parche. Los parches en el correo electrónico tienden a ser destrozados, y cuanto más grande sea el parche, más difícil será para las partes interesadas desenmarañarlo. Además, la publicación de un parche en la web le permite modificarlo sin tener que volver a enviar el parche completo en un follow-up al PR original. Finalmente, los parches grandes simplemente aumentan el tamaño de la base de datos, ya que los PR cerrados no se eliminan, sino que se guardan y simplemente se marcan como completos. También debe tener en cuenta que, a menos que se especifique explícitamente lo contrario en su PR o en el propio parche, se asumirá que los parches que envíe se licenciarán en los mismos términos que el archivo original que modificó. [[pr-writing-filling-template]] == Rellenar el formulario [NOTE] ==== La dirección de correo electrónico que utilice pasará a ser pública y podrá estar disponible para los spammers. Debe tener implementados procedimientos de manejo de spam o usar una cuenta de correo electrónico temporal. Sin embargo, tenga en cuenta que si no utiliza una cuenta de correo electrónico válida, no podremos hacerle preguntas sobre su PR. ==== Cuando presente un error, encontrará los siguientes campos: * _Synopsis:_ Rellene este campo con una descripción corta y precisa del problema. El campo debe ser rellenado en inglés, pues es el idioma de comunicación en el proyecto FreeBSD. 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 vagas sinopsis tienden a ser completamente ignorados. * _Severity:_ Escoga una de las opciones, `Affects only me (Solo me afecta a mi)`, `Affects some people (Afecta a algunas personas)` o `Affects many people (Afecta a muchas personas)`. No sea exagerado; absténgase de etiquetar su problema `Affects many people (Afecta a muchas personas)` a menos que realmente lo haga. Los desarrolladores de FreeBSD no trabajarán en su problema más rápido si infla su importancia, ya que muchas otras personas han hecho exactamente lo mismo. * _Category:_ Elija una categoría apropiada. + Lo primero que debe hacer es decidir en qué parte del sistema se encuentra su problema. Recuerde, FreeBSD es un sistema operativo completo, instala un kernel, la biblioteca estándar, muchos controladores de periféricos y un gran número de utilidades (el "sistema base"). Sin embargo, hay miles de aplicaciones adicionales en la colección de ports. Primero deberá decidir si el problema está en el sistema base o en algo instalado a través de la colección de ports. + Aquí una descripción de las principales categorías: ** Si hay un problema con el kernel, las bibliotecas (como la biblioteca estándar de C `libc`) o en un controlador de un periférico en el sistema base, en general, utilizará la categoría `kern`. (Hay algunas excepciones; vea más abajo). En general, estas son las cosas que se describen en la sección 2, 3 ó 4 de las páginas del manual. ** Si el problema es con un binario como man:sh[1] o man:mount[8], primero deberá determinar si estos programas se encuentran en el sistema base o se añadieron a través de la colección de ports. Si no está seguro, puede hacer `whereis _programname_`. La convención de FreeBSD para la colección de ports es instalar todo por debajo de [.filename]#/usr/local#, aunque un administrador del sistema puede sobreescribirlo. Para estos, utilizará la categoría de `ports` (sí, incluso si la categoría del port es `www`; vea más abajo). Si la ubicación es [.filename]#/bin#, [.filename]#/usr/bin#, [.filename]#/sbin#, o [.filename]#/usr/sbin#, es parte del sistema base, y debe usar la categoría `bin`. Estas son todas las cosas que se describen en las secciones 1 u 8 de las páginas del manual. ** Si cree que el error está en los scripts de inicio `(rc)`, o en algún otro tipo de archivo de configuración no ejecutable, entonces la categoría correcta es `conf` (configuración). Estas son las cosas que se describen en la sección 5 de las páginas del manual. ** Si ha encontrado un problema en el conjunto de la documentación (artículos, libros, man pages) o en el sitio web, la elección correcta es `docs`. + [NOTE] ==== Si tiene un problema con un port llamado `www/_algunnombredeport_`, esto entra en la categoría de `ports`. ==== + Hay algunas categorías más especializadas. ** Si el problema se catalogará en `kern` pero estuviera relacionado con el subsistema USB, la elección correcta es `usb`. ** Si el problema se catalogará en `kern` pero estuviera relacionado con las bibliotecas de threading, la elección correcta es `threads`. ** Si el problema se catalogará en el sistema base, pero estuviera relacionado con nuestra interpretación de estándares, como POSIX(R), la elección correcta es `standards`. ** Si está convencido de que el problema solo ocurrirá con la arquitectura del procesador que está utilizando, seleccione una de las categories específicas de la arquitectura: normalmente, `i386` para ordenadores compatibles con Intel en modo 32 bits; `amd64` para máquinas AMD que se ejecutan en modo 64 bits (esto también incluye ordenadores compatibles con Intel que se ejecutan en modo EMT64); y las menos comunes, `arm` o `powerpc`. + [NOTE] ==== Estas categorías se utilizan con frecuencia para los problemas "No lo sé". En lugar de suponer, utilice `misc`. ==== + .Uso correcto de la categoría de arquitectura específica [example] ==== Tiene un ordenador común (PC-based machine), y cree que ha encontrado un problema específico para un conjunto de chips o una placa base en particular: `i386` es la categoría correcta. ==== + .Uso incorrecto de la categoría de arquitectura específica [example] ==== Está teniendo un problema con una tarjeta periférica adicional en un bus común, o un problema con un tipo particular de unidad de disco duro: en este caso, probablemente afecte a más de una arquitectura, y `kern` es la categoría correcta. ==== ** Si realmente no sabe dónde está el problema (o la explicación no parece encajar en los anteriores), use la categoría `misc`. Antes de hacerlo, es posible que primero desee solicitar ayuda en la http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[lista de correo de preguntas generales de FreeBSD]. Es posible que le indiquen que una de las categorías ya existentes es mejor opción. * _Environment:_ Esto debe describir, con la mayor precisión posible, el entorno en el que se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa o archivo específico que contiene el problema y cualquier otro elemento relevante como la configuración del sistema, otro software instalado que influya en el problema, etc. -- simplemente todo lo que un desarrollador necesita saber para reconstruir el entorno en el que se produce el problema. * _Description:_ Una descripción completa y precisa del problema que está experimentando. Intente evitar especular sobre las posibles causas del problema a menos que se tenga la seguridad de que el camino descrito es el correcto, ya que puede inducir a un desarrollador a hacer suposiciones incorrectas sobre el problema. Debe incluir las acciones que hay que realizar para reproducir el problema. Si conoce alguna solución, inclúyala. No solo ayuda a otras personas con el mismo problema a solucionarlo, sino que también puede ayudar a un desarrollador a entender la causa del problema. [[pr-followup]] == Follow-up Una vez que se haya enviado el informe de problemas, recibirá una confirmación por correo electrónico que incluirá el número de seguimiento que se asignó a su informe de problemas y una URL que puede usar para verificar su estado. Con un poco de suerte, alguien se interesará en su problema e intentará solucionarlo o, según sea el caso, explicará por qué no es un problema. Se le notificará automáticamente de cualquier cambio de estado y recibirá copias de los comentarios o parches que alguien pueda adjuntar al registro de auditoría de su informe de problemas. Si alguien le solicita información adicional, o si recuerda o descubre algo que no mencionó en el informe inicial, por favor, envíe un follow-up. La razón número uno para que un error no se arregle es la falta de comunicación con el usario que creó el error. La forma más fácil es usar la opción de comentarios en la página web de cada PR, a la que puede acceder desde la https://bugs.freebsd.org/bugzilla/query.cgi[página de búsqueda de PR]. Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, solo agregue un comentario que indique que el informe de problemas se puede cerrar y, a ser posible, explique cómo o cuándo se solucionó el problema. A veces hay un retraso de una o dos semanas en las cuales el informe del problema está sin cambios, sin asignar, ni comentado por nadie. Esto puede suceder cuando hay una acumulación de informes de problemas o durante la temporada de vacaciones. Cuando un informe de problemas no ha recibido atención después de varias semanas, vale la pena encontrar a un committer que esté interesado en trabajar en él. Hay varias formas de hacerlo, lo ideal es el orden siguiente, con algunos días entre cada intento: * Encuentre la lista de correo de FreeBSD que sea relevante para el informe de problemas en link:{handbook}#eresources-mail[la lista del manual] y envíe un mensaje a esa lista preguntando por asistencia o comentarios sobre el informe de problemas. * Únase a los canales de IRC relevantes. Aquí un listado parcial: https://wiki.freebsd.org/IrcChannels[]. Informe a las personas en ese canal sobre el informe del problema y solicite asistencia. Sea paciente y permanezca en el canal después de la publicación, para que las personas de diferentes zonas horarias de todo el mundo tengan la oportunidad de ponerse al día. * Encuentre a committers interesados en el problema que reportó. Si el problema estaba en una herramienta, binario, port, documento o un fichero de código fuente en particular, verifique el http://svnweb.FreeBSD.org[repositorio SVN]. Localice a los últimos committers que realizaron cambios sustanciales en el archivo e intente acceder a ellos a través de IRC o correo electrónico. Puede encontrar una lista de los committers y sus correos electrónicos en el artículo link:{contributors}[Colaboradores de FreeBSD]. Recuerde que estas personas son voluntarios, al igual que los maintainers y usuarios, por lo que es posible que no estén disponibles de inmediato para ayudar con el informe del problema. La paciencia y la constancia en los seguimientos son altamente recomendadas y apreciadas. Con el suficiente cuidado y esfuerzo dedicado al proceso de seguimiento, encontrar un committer para encargarse del informe del problema es solo cuestión de tiempo. [[pr-problems]] == Si hay problemas Si ha encontrado un problema con el sistema de errores, ¡presente un error! Hay una categoría exacta para este propósito. Si no puede hacerlo, póngase en contacto con los encargados de los errores en mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]. [[pr-further]] == Lecturas adicionales 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. * https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[Cómo informar errores de forma efectiva]--un excelente ensayo por Simon G. Tatham sobre la redacción de informes de problemas (el texto no es específico sobre FreeBSD). * link:{pr-guidelines}[Guía para el manejo de informes de problemas]--contiene una información valiosa sobre cómo los informes de problemas son manejados por los desarrolladores de FreeBSD. diff --git a/documentation/content/es/articles/releng/_index.adoc b/documentation/content/es/articles/releng/_index.adoc index 5d27b3bd8b..d995f7636f 100644 --- a/documentation/content/es/articles/releng/_index.adoc +++ b/documentation/content/es/articles/releng/_index.adoc @@ -1,381 +1,391 @@ --- title: Proceso de generación de releases en FreeBSD authors: - author: Murray Stokely email: murray@FreeBSD.org webpage: https://people.FreeBSD.org/~murray/ releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "cvsup", "intel", "xfree86", "general"] --- = Proceso de generación de releases en FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :xrefstyle: full :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo + +ifeval::["{backend}" == "html5"] include::shared/releases.adoc[] include::shared/authors.adoc[] include::shared/es/teams.adoc[] include::shared/es/mailing-lists.adoc[] include::shared/es/urls.adoc[] - -ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/releng/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/releases.adoc[] +include::../../../../shared/authors.adoc[] +include::../../../../shared/es/teams.adoc[] +include::../../../../shared/es/mailing-lists.adoc[] +include::../../../../shared/es/urls.adoc[] :imagesdir: ../../../../static/images/articles/releng/ endif::[] ifeval::["{backend}" == "epub3"] +include::../../../../shared/releases.adoc[] +include::../../../../shared/authors.adoc[] +include::../../../../shared/es/teams.adoc[] +include::../../../../shared/es/mailing-lists.adoc[] +include::../../../../shared/es/urls.adoc[] :imagesdir: ../../../../static/images/articles/releng/ endif::[] [.abstract-title] Resumen 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. ''' toc::[] [[introduction]] == Introducción El desarrollo de FreeBSD es un proceso realmente abierto al público. FreeBSD se alimenta de contribuciones de miles de personas del mundo entero. El Proyecto FreeBSD 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 FreeBSD. 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 FreeBSD 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 http://www.FreeBSD.org/send-pr/[http://www.FreeBSD.org/send-pr/]. Además de la multitud de listas de correo de carácter técnico que FreeBSD pone a nuestra disposición, el {freebsd-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. [[release-proc]] == 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 `{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`. [source,shell] .... /usr/src# 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: [source,shell] .... /usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src .... Y a continuación se crea la etiqueta de la rama: [source,shell] .... /usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src .... [NOTE] ==== 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. image::branches-head.png[Rama FreeBSD Development (Rama de Desarrollo)] image::branches-releng3.png[Rama FreeBSD 3.x STABLE] image::branches-releng4.png[Rama FreeBSD 4.x STABLE] [[versionbump]] ==== 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: * [.filename]#doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml# * [.filename]#doc/en_US.ISO8859-1/books/porters-handbook/book.xml# * [.filename]#doc/shared/xml/freebsd.ent# * [.filename]#src/Makefile.inc1# * [.filename]#src/UPDATING# * [.filename]#src/gnu/usr.bin/groff/tmac/mdoc.local# * [.filename]#src/release/Makefile# * [.filename]#src/release/doc/en_US.ISO8859-1/shared/xml/release.dsl# * [.filename]#src/release/doc/shared/examples/Makefile.relnotesng# * [.filename]#src/release/doc/shared/xml/release.ent# * [.filename]#src/shared/examples/cvsup/standard-supfile# * [.filename]#src/sys/conf/newvers.sh# * [.filename]#src/sys/sys/param.h# * [.filename]#src/usr.sbin/pkg_install/add/main.c# * [.filename]#www/en/docs.xml# * [.filename]#www/en/cgi/ports.cgi# * [.filename]#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): * [.filename]#src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml# * [.filename]#src/release/doc/en_US.ISO8859-1/errata/article.xml# 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 [.filename]#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: * [.filename]#www/shared/xml/includes.release.xml# * [.filename]#www/shared/xml/includes.release.xsl# * [.filename]#www/en/releases/*# * [.filename]#www/en/releng/index.xml# * [.filename]#www/en/news/news.xml# * [.filename]#www/en/search/web.atoz# * [.filename]#src/shared/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`. [source,shell] .... /usr/src# 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 FreeBSD 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. [[release-build]] == 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 FreeBSD. En la práctica esto significa que cualquiera puede generar el proceso de construcción de releases, ya que, como se comentó con anterioridad, FreeBSD 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 [.filename]#src/release#. Estas herramientas proporcionan una forma consistente y robusta de construir releases de FreeBSD. 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`. === `make release` Para poder construir la releases de una forma exitosa se debe rellenar primero el directorio [.filename]#/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 link:{handbook}#synching[CVSup]. El fichero [.filename]#/usr/shared/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 [.filename]#src/release/Makefile#. El comando exacto para contruir la release oficial de FreeBSD 4.7 (x86) fue: [source,shell] .... make release CHROOTDIR=/local3/release \ BUILDNAME=4.7-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs \ RELEASETAG=RELENG_4_7_0_RELEASE .... El [.filename]#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 [.filename]#/etc# y [.filename]#/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 [.filename]#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 XFree86(TM) XFree86(TM) es un componente importante para muchos usuarios de entornos gráficos. Antes de la release FreeBSD 4.6 las se usaba XFree86(TM)3._X_ por defecto. La forma más sencilla de construir estas versiones consiste en utilizar el script [.filename]#src/release/scripts/X11/build_x.sh#. Este script requiere que XFree86(TM) 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 [.filename]#XF86336# del medio de instalación. A partir de FreeBSD 4.6, man:sysinstall[8] instala XFree86(TM) 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. [NOTE] ==== Es importante borrar cualquier configuración particular almacenada en [.filename]#/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 ("ports") La colección de http://www.FreeBSD.org/ports[FreeBSD Ports] está compuesta por más de {numports} paquetes de software de terceras partes que se encuentran disponibles para FreeBSD. El `{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, link:{releng-packages}[releng-packages], 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 [.filename]#README.TXT# que explica el contenido de cada disco, un [.filename]#CDROM.INF# que proporciona metadatos para que man:sysinstall[8] pueda validar la información en él contenida y un [.filename]#filename.txt# que proporciona un "manifiesto". Este _manifiesto_ se puede crear utilizando un simple comando: [source,shell] .... /stage/cdrom# 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 [.filename]#disc1# son la adición de un directorio [.filename]#tools#, de XFree86(TM) y de los paquetes de terceras partes más populares que quepan dentro del espacio remanente de dicho primer disco. El directorio [.filename]#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(TM), man:sysinstall[8] debe actualizarse para reflejar la nueva localización y las instrucciones de instalación. El código relevante se encuentra en [.filename]#src/release/sysinstall# en -STABLE o en [.filename]#src/usr.sbin/sysinstall# en -CURRENT. Específicamente, se deben actualizar [.filename]#dist.c#, [.filename]#menus.c# y [.filename]#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 FreeBSD. Este disco se debe construir como autoarrancable y debe contener una copia comprimida del repositorio de CVS dentro del directorio [.filename]#CVSROOT#, junto con demostraciones de software comercial localizadas dentro del directorio [.filename]#commerce#. ==== Discos 3 and 4 Los dos discos que quedan contienen paquetes de software para FreeBSD. 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 link:{releng-packages}[releng-packages]. [[distribution]] == Distribución [[dist-ftp]] === 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`: [.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/#:: El directorio de instalación dde FTP que se crea con la salida del comando `make release`. [.filename]#/pub/FreeBSD/ports/arch/packages-X.Y-release/#:: La construcción del paquete completo de la release. [.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools#:: Un enlace simbólico a [.filename]#../../../tools#. [.filename]#/pub/FreeBSD/releases/arch/X.Y-RELEASE/packages#:: Un enlace simbólico a [.filename]#../../../ports/arch/packages-X.Y-release#. [.filename]#/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso#:: Las imágenes ISO. El "*" se sustituye por [.filename]#disc1#, [.filename]#disc2#, etc. Solo si existe [.filename]#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 [.filename]#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 link:{hubs}[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 {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 {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. [[dist-cdrom]] === 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. [[extensibility]] == Extensibilidad Aunque FreeBSD 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 FreeBSD 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 FreeBSD con una serie de cambios profundos en él , se anima a que se __documenten adecuadamente dichos mejoras__. La comunidad FreeBSD 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 [.filename]#${CHROOTDIR}/R/stage/floppies#. También se puede llamar el objetivo de make [.filename]#boot.flp# o directamente al "script" de creación del sistema de ficheros [.filename]#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`. === "Scripts" para `sysinstall` La instalación y configuración del sistema FreeBSD 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(R) 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 [.filename]#src/release/sysinstall/install.cfg#. [[lessons-learned]] == 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 `{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 `{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 FreeBSD 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 FreeBSD vaya estando disponible para más plataformas. [[future]] == 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 [.filename]#ports# y de los [.filename]#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 FreeBSD. * _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. [[ackno]] == 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 FreeBSD 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 `{asami}`, `{steve}`, `{bmah}`, `{nik}`, `{obrien}`, `{kris}`, `{jhb}` y del resto de la comunidad FreeBSD. También me gustaría agradecer especialmente a `{rgrimes}`, `{phk}` y muchos otros que trabajaron en las herramientas de ingeniería de releases en los comienzos del sistema FreeBSD. 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]. [[biblio]] == Lecturas recomendadas (1) CVS - Concurrent Versions System http://www.cvshome.org[http://www.cvshome.org] (2) CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup[http://www.polstra.com/projects/freeware/CVSup] (3) http://bento.FreeBSD.org[http://bento.FreeBSD.org] (4) FreeBSD Ports Collection http://www.FreeBSD.org/ports[http://www.FreeBSD.org/ports] (5) The libh Project http://www.FreeBSD.org/projects/libh/[http://www.FreeBSD.org/projects/libh/] (6) link:{contributors}#staff-committers[FreeBSD Committers] (7) link:{contributors}#staff-core[FreeBSD Core-Team] (8) link:{handbook}[FreeBSD Handbook] (9) GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats[http://www.gnu.org/software/gnats] (10) FreeBSD PR Statistics http://www.FreeBSD.org/prstats/[http://www.FreeBSD.org/prstats/] (11) NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html[http://www.NetBSD.org/developers/releng/index.html] (12) John Baldwin's FreeBSD Release Engineering Proposal http://people.FreeBSD.org/\~jhb/docs/releng.txt[http://people.FreeBSD.org/~jhb/docs/releng.txt] (13) PXE Jumpstart Guide link:{pxe}[pxe] (14) Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: http://docs.FreeBSD.org/44doc/papers/releng.html[The Release Engineering of 4.3BSD] diff --git a/documentation/content/es/articles/remote-install/_index.adoc b/documentation/content/es/articles/remote-install/_index.adoc index 46ffcfb347..f125a99c75 100644 --- a/documentation/content/es/articles/remote-install/_index.adoc +++ b/documentation/content/es/articles/remote-install/_index.adoc @@ -1,334 +1,344 @@ --- title: Instalación remota del sistema operativo FreeBSD sin una consola remota authors: - author: Daniel Gerzo email: danger@FreeBSD.org copyright: 2008 The FreeBSD Documentation Project releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "general"] --- = Instalación remota del sistema operativo FreeBSD sin una consola remota :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :lang: es :toc-title: Tabla de contenidos :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apéndice :table-caption: Tabla :figure-caption: Figura :example-caption: Ejemplo +ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/es/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/es/urls.adoc[] +endif::[] [.abstract-title] Resumen Este artículo documenta la instalación remota del sistema operativo FreeBSD cuando la consola del sistema remoto no está disponible. La idea principal detrás de este artículo es el resultado de la colaboración con Martin Matuska mailto:mm@FreeBSD.org[mm@FreeBSD.org] y con información valiosa proporcionada por Paweł Jakub Dawidek mailto:pjd@FreeBSD.org[pjd@FreeBSD.org]. ''' toc::[] [[background]] == Antecedentes Hay muchos proveedores de hosting en el mundo, pero muy pocos soportan oficialmente FreeBSD. Por lo general, dan soporte para instalar una distribución de Linux(R) en los servidores que ofrecen. En algunos casos, estas compañías instalarán su distribución favorita de Linux(R) si lo solicita. Utilizando esta opción, intentaremos instalar FreeBSD. En otros casos, pueden ofrecer un sistema de rescate que se podría usar en caso de emergencia. También es posible usar esta opción para nuestros propósitos. Este artículo cubre los pasos básicos de instalación y configuración necesarios para iniciar una instalación remota de FreeBSD con RAID-1 y ZFS. [[intro]] == Introducción Esta sección resumirá el propósito del artículo y explicará mejor lo que se trata en este documento. Las instrucciones incluidas beneficiarán a quienes utilicen los servicios proporcionados por las instalaciones de colocación de servidores que no admiten FreeBSD. [.procedure] ==== . Como hemos mencionado en la sección de <>, muchas de las empresas más respetadas de hosting ofrecen algún tipo de sistema de rescate, que se inicia desde su LAN y es accesible por SSH. Por lo general, dan este soporte para ayudar a sus clientes a reparar sistemas operativos dañados. Como se explicará en este artículo, es posible instalar FreeBSD con la ayuda de estos sistemas de rescate. + . La siguiente sección del artículo describirá cómo configurar y compilar una versión minimalista de FreeBSD en la máquina local. Esa versión finalmente se ejecutará en la máquina remota desde ramdisk, lo que nos permitirá instalar un sistema operativo FreeBSD completo desde un mirror FTP usando la utilidad Sysinstall. . El resto del artículo describirá el proceso de instalación, así como la configuración del sistema de archivos ZFS. ==== [[requirements]] === Requisitos Para continuar con éxito, debe: * Tener un sistema operativo accesible por la red con acceso SSH * Entender el proceso de instalación de FreeBSD * Estar familiarizado con la utilidad man:sysinstall[8] * Tener a mano la imagen ISO o el CD de instalación de FreeBSD [[preparation]] == Preparación - mfsBSD Antes de poder instalar FreeBSD en el sistema de destino, es necesario crear la imagen mínima de FreeBSD que se iniciará desde el disco duro. De esta manera, se puede acceder al nuevo sistema desde la red, y el resto de la instalación se puede hacer sin acceso remoto a la consola del sistema. El conjunto de herramientas mfsBSD se puede usar para construir una imagen pequeña de FreeBSD. Como sugiere el nombre de mfsBSD ("mfs" significa "sistema de archivos en memoria"), la imagen resultante se ejecuta completamente desde ramdisk. Gracias a esta característica, la manipulación de los discos duros no estará limitada, por lo que será posible instalar un sistema operativo completo FreeBSD. La http://mfsbsd.vx.sk/[página web] de mfsBSD incluye indicaciones a la última versión del conjunto de herramientas. Tenga en cuenta que los aspectos internos de mfsBSD están fuera del alcance de este artículo. El lector interesado debe consultar la documentación oficial de mfsBSD para obtener más detalles. Descargue y extraiga la última versión de mfsBSD y cambie su directorio de trabajo al directorio donde se encuentren los scripts de mfsBSD: [source,shell] .... # fetch http://mfsbsd.vx.sk/release/mfsbsd-2.1.tar.gz # tar xvzf mfsbsd-2.1.tar.gz # cd mfsbsd-2.1/ .... [[mfsbsd-config]] === Configuración de mfsBSD Antes de iniciar mfsBSD, deben establecerse algunas opciones de configuración importantes. Lo más importante que tenemos que configurar bien es, naturalmente, la configuración de red. El método más adecuado para configurar las opciones de red dependerá de si conocemos previamente el tipo de interfaz de red que usaremos, y el controlador de red que se cargará para nuestro hardware. Veremos cómo se puede configurar mfsBSD en cualquier caso. Otra cosa importante es establecer la contraseña del usuario `root`. Esto se puede hacer editando [.filename]#conf/loader.conf#. Por favor lea los comentarios incluidos. ==== El método [.filename]#conf/interfaces.conf# Cuando se desconoce la tarjeta de red instalada, es posible utilizar las funciones de detección automática de mfsBSD. Los scripts de inicio de mfsBSD pueden detectar el controlador correcto, según la dirección MAC de la interfaz, si configuramos las siguientes opciones en [.filename]#conf/interfaces.conf#: [.programlisting] .... mac_interfaces="ext1" ifconfig_ext1_mac="00:00:00:00:00:00" ifconfig_ext1="inet 192.168.0.2/24" .... No olvide agregar `defaultrouter` a [.filename]#conf/rc.conf#: [.programlisting] .... defaultrouter="192.168.0.1" .... ==== El método [.filename]#conf/rc.conf# Cuando se conoce el controlador de la interfaz de red, es más conveniente utilizar [.filename]#conf/rc.conf# para las opciones de red. La sintaxis de este fichero es la misma que la utilizada en el fichero man:rc.conf[5] de FreeBSD. Por ejemplo, si sabe que una interfaz de red man:re[4] estará disponible, puede configurar las siguientes opciones en [.filename]#conf/rc.conf#: [.programlisting] .... defaultrouter="192.168.0.1" ifconfig_re0="inet 192.168.0.2/24" .... [[mfsbsd-build]] === Creando una imagen de mfsBSD El proceso de creación de una imagen de mfsBSD es bastante sencillo. El primer paso es montar el CD de instalación de FreeBSD, o la imagen ISO de instalación en [.filename]#/cdrom#. Por ejemplo, en este artículo asumiremos que ha descargado la ISO FreeBSD 10.1-RELEASE. Montar esta imagen ISO en el directorio [.filename]#/cdrom# es fácil con la utilidad man:mdconfig[8]: [source,shell] .... # mdconfig -a -t vnode -u 10 -f FreeBSD-10.1-RELEASE-amd64-disc1.iso # mount_cd9660 /dev/md10 /cdrom .... Como las versiones recientes de FreeBSD no contienen los sets regulares de la distribución, es necesario extraerlos de la imagen ISO: [source,shell] .... # mkdir DIST # tar -xvf /cdrom/usr/freebsd-dist/base.txz -C DIST # tar -xvf /cdrom/usr/freebsd-dist/kernel.txz -C DIST .... A continuación, genere la imagen mfsBSD de arranque: [source,shell] .... # make BASE=DIST .... [NOTE] ==== El comando make anterior debe ejecutarse desde el nivel superior del árbol de directorios de mfsBSD, por ejemplo [.filename]#~/mfsbsd-2.1/#. ==== === Iniciando mfsBSD Ahora que la imagen mfsBSD está lista, se debe cargar en el sistema remoto ejecutando el sistema de recuperación o una distribución de Linux(R) preinstalada. La herramienta más adecuada para esta tarea es scp: [source,shell] .... # scp disk.img root@192.168.0.2:. .... Para iniciar correctamente la imagen mfsBSD, debe colocarse en el primer dispositivo (bootable) de la máquina en cuestión. Se puede hacer utilizando este ejemplo, siempre que [.filename]#sda# sea el primer dispositivo de arranque: [source,shell] .... # dd if=/root/disk.img of=/dev/sda bs=1m .... Si todo ha ido bien, la imagen debe estar en el MBR del primer dispositivo y la máquina se puede reiniciar. Observe que la máquina se inicializa correctamente con la herramienta man:ping[8]. Una vez que esté en línea, debería ser posible acceder a ella con man:ssh[1] como usuario `root` con la contraseña configurada. [[installation]] == Instalación del sistema operativo FreeBSD mfsBSD se ha iniciado correctamente y debería ser posible iniciar sesión a través de man:ssh[1]. En esta sección se describe cómo crear y etiquetar slices, configurar gmirror para RAID-1 y cómo utilizar Sysinstall para instalar una distribución mínima de FreeBSD. === Preparación de los discos duros La primera tarea es asignar espacio en disco para FreeBSD, es decir: crear slices y particiones. Obviamente, el sistema que está actualmente en ejecución se encuentra completamente cargado en la memoria del sistema y, por lo tanto, no habrá problemas al manipular los discos duros. Para completar esta tarea, es posible usar Sysinstall o man:fdisk[8] en conjunto con man:bsdlabel[8]. Al principio, marque todos los discos del sistema como vacíos. Repita el siguiente comando para cada disco duro: [source,shell] .... # dd if=/dev/zero of=/dev/ad0 count=2 .... A continuación, cree las slices y etiquételas con su herramienta preferida. A pesar de que se considera más fácil usar Sysinstall, un método potente y probablemente menos defectuoso será usar herramientas estándar de UNIX(R) basadas en texto, como man:fdisk[8] y man:bsdlabel[8], también tratadas en esta sección. La primera opción está bien documentada en el capítulo de link:{handbook}#install-steps[Instalación de FreeBSD] del Manual de FreeBSD. Como se mencionó en la introducción, este artículo explicará cómo configurar un sistema con RAID-1 y ZFS. Nuestra configuración consistirá en una pequeña partición [.filename]#/# (raíz), con un conjunto de datos compuesto por [.filename]#/usr# y [.filename]#/var#, todos en mirror con man:gmirror[8] y el resto del espacio en disco asignado a un sistema de archivos ZFS en mirror con man:zpool[8]. Por favor, tenga en cuenta que el sistema de archivos ZFS se configurará después de que el sistema operativo FreeBSD se instale y se inicie correctamente. El siguiente ejemplo describirá cómo crear slices y etiquetas, inicializar man:gmirror[8] en cada partición y cómo crear un sistema de archivos UFS2 en cada partición en mirror: [source,shell] .... # fdisk -BI /dev/ad0 <.> # fdisk -BI /dev/ad1 # bsdlabel -wB /dev/ad0s1 <.> # bsdlabel -wB /dev/ad1s1 # bsdlabel -e /dev/ad0s1 <.> # bsdlabel /dev/ad0s1 > /tmp/bsdlabel.txt && bsdlabel -R /dev/ad1s1 /tmp/bsdlabel.txt <.> # gmirror label root /dev/ad[01]s1a <.> # gmirror label var /dev/ad[01]s1d # gmirror label usr /dev/ad[01]s1e # gmirror label -F swap /dev/ad[01]s1b <.> # newfs /dev/mirror/root <.> # newfs /dev/mirror/var # newfs /dev/mirror/usr .... <.> Cree una slice que use todo el disco e inicialice el boot code del sector 0 del disco seleccionado. Repita este comando para todos los discos duros en el sistema. <.> Escriba una etiqueta estándar para cada disco, incluido el código de arranque. <.> Ahora, manualmente edite la etiqueta del disco. Consulte la página de manual man:bsdlabel[8] para saber cómo crear particiones. Cree las particiones siguientes: `a` para el sistema de archivos [.filename]#/# (raíz), `b` para swap, `d` para [.filename]#/var#, `e` para [.filename]#/usr# y finalmente `f`, que luego será utilizada para ZFS. <.> Importe la etiqueta creada recientemente para el segundo disco duro, de modo que ambos discos estén etiquetados de la misma manera. <.> Inicialice man:gmirror[8] en cada partición. <.> Tenga en cuenta que `-F` se utiliza para la partición swap. Esto le indica a man:gmirror[8] que asuma que el dispositivo está consistente después de un fallo de alimentación/sistema. <.> Cree un sistema de archivos UFS2 en cada partición duplicada. === Instalación del sistema Esta es la parte más importante. Esta sección describirá cómo instalar la distribución mínima de FreeBSD en los discos duros que hemos preparado en la sección anterior. Para lograr este objetivo, todos los sistemas de archivos deben montarse, para que Sysinstall pueda escribir el contenido de FreeBSD en los discos duros: [source,shell] .... # mount /dev/mirror/root /mnt # mkdir /mnt/var /mnt/usr # mount /dev/mirror/var /mnt/var # mount /dev/mirror/usr /mnt/usr .... Cuando haya terminado, inicie man:sysinstall[8]. Seleccione la instalación [.guimenuitem]#Custom# en el menú principal. Seleccione [.guimenuitem]#Options# y presione kbd:[Enter]. Con la ayuda de las teclas de dirección, mueva el cursor sobre el elemento `Install Root`, presione kbd:[Space] y cámbielo a [.filename]#/mnt#. Presione kbd:[Enter] para aceptar sus cambios y salga del menú [.guimenuitem]#Options# presionando kbd:[q]. [WARNING] ==== Tenga en cuenta que este paso es muy importante y, si se omite, Sysinstall no podrá instalar FreeBSD. ==== Vaya al menú [.guimenuitem]#Distributions#, mueva el cursor con las teclas de dirección a `Minimal` y compruébelo presionando la tecla kbd:[Espacio]. Este artículo utiliza la distribución mínima para ahorrar tráfico de red, ya que el sistema se instalará por ftp. Salga de este menú seleccionando `Exit`. [NOTE] ==== Los menús [.guimenuitem]#Partition# y [.guimenuitem]#Label# se omitirán, ya que son inútiles ahora. ==== En el menú [.guimenuitem]#Media#, seleccione `FTP`. Seleccione el mirror más cercano y deje que Sysinstall asuma que la red ya está configurada. Volverá al menú [.guimenuitem]#Custom#. Finalmente, realice la instalación del sistema seleccionando la última opción, [.guimenuitem]#Commit#. Salga de Sysinstall cuando finalice la instalación. === Pasos posteriores a la instalación El sistema operativo FreBSD ya debería estar instalado; sin embargo, el proceso aún no ha terminado. Es necesario realizar algunos pasos posteriores a la instalación para permitir que FreeBSD se inicie en el futuro y pueda iniciar sesión en el sistema. Ahora debe usar el comando man:chroot[8] en el sistema recién instalado. Use el siguiente comando: [source,shell] .... # chroot /mnt .... Para completar nuestro objetivo, siga estos pasos: * Copie el kernel `GENERIC` al directorio [.filename]#/boot/kernel#: + [source,shell] .... # cp -Rp /boot/GENERIC/* /boot/kernel .... * Cree los ficheros [.filename]#/etc/rc.conf#, [.filename]#/etc/resolv.conf# y [.filename]#/etc/fstab#. No olvide configurar correctamente la información de red y habilitar sshd en [.filename]#/etc/rc.conf#. El contenido de [.filename]#/etc/fstab# será similar al siguiente: + [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/mirror/swap none swap sw 0 0 /dev/mirror/root / ufs rw 1 1 /dev/mirror/usr /usr ufs rw 2 2 /dev/mirror/var /var ufs rw 2 2 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 .... * Cree [.filename]#/boot/loader.conf# con el siguiente contenido: + [.programlisting] .... geom_mirror_load="YES" zfs_load="YES" .... * Ejecute el siguiente comando, hará que ZFS se encuentre disponible en el siguiente arranque: + [source,shell] .... # echo 'zfs_enable="YES"' >> /etc/rc.conf .... * Agregue usuarios adicionales al sistema usando la herramienta man:adduser[8]. No olvide agregar un usuario al grupo `wheel` para que pueda obtener acceso al usuario root después del reinicio. * Vuelva a comprobar todas sus configuraciones. El sistema debería estar listo para el siguiente arranque. Use el comando man:reboot[8] para reiniciar su sistema. [[zfs]] == ZFS Si su sistema sobrevivió al reinicio, ahora debería poder iniciar sesión. ¡Bienvenido a la nueva instalación de FreeBSD, realizada de forma remota sin el uso de una consola remota! El único paso que queda es configurar man:zpool[8] y crear algunos sistemas de archivos man:zfs[8]. Crear y administrar ZFS es muy sencillo. Primero, cree un pool reflejado: [source,shell] .... # zpool create tank mirror /dev/ad[01]s1f .... A continuación, cree algunos sistemas de archivos: [source,shell] .... # zfs create tank/ports # zfs create tank/src # zfs set compression=gzip tank/ports # zfs set compression=on tank/src # zfs set mountpoint=/usr/ports tank/ports # zfs set mountpoint=/usr/src tank/src .... Eso es todo. Si está interesado en obtener más información sobre ZFS en FreeBSD, consulte la sección https://wiki.freebsd.org/ZFS[ZFS] de la wiki de FreeBSD.