diff --git a/es_ES.ISO8859-1/articles/Makefile b/es_ES.ISO8859-1/articles/Makefile index 7d4a5d1c13..4060e1daab 100644 --- a/es_ES.ISO8859-1/articles/Makefile +++ b/es_ES.ISO8859-1/articles/Makefile @@ -1,15 +1,18 @@ # $FreeBSD$ # $FreeBSDes: doc/es_ES.ISO8859-1/articles/Makefile,v 1.3 2004/10/09 02:01:17 jesusr Exp $ SUBDIR = SUBDIR+= contributing SUBDIR+= cvs-freebsd SUBDIR+= dialup-firewall SUBDIR+= explaining-bsd SUBDIR+= fbsd-from-scratch SUBDIR+= laptop +SUBDIR+= mailing-list-faq SUBDIR+= problem-reports +SUBDIR+= releng SUBDIR+= zip-drive DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" + diff --git a/es_ES.ISO8859-1/articles/cvs-freebsd/Makefile b/es_ES.ISO8859-1/articles/cvs-freebsd/Makefile new file mode 100644 index 0000000000..2c30891dff --- /dev/null +++ b/es_ES.ISO8859-1/articles/cvs-freebsd/Makefile @@ -0,0 +1,25 @@ +# $FreeBSD$ +# $FreeBSDes$ +# Copiado de la version 1.5 +# +# Article: Setting up a CVS repository - the FreeBSD way + +#MAINTAINER= stijn@win.tue.nl + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + + +WITH_ARTICLE_TOC?=YES + + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml b/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml new file mode 100644 index 0000000000..a44c860395 --- /dev/null +++ b/es_ES.ISO8859-1/articles/cvs-freebsd/article.sgml @@ -0,0 +1,840 @@ + + + + +%man; + %freebsd; + %newsgroups; + +%authors; + +%trademarks; + +%translators; + %mailing-lists; + +]> + + + + +
+ + Configurar un repositorio CVS - a la manera de FreeBSD + + + Stijn + Hoop + +
stijn@win.tue.nl
+ + + + + 2001 + 2002 + 2003 + Stijn Hoop + + + $FreeBSD$ + + + &tm-attrib.freebsd; + &tm-attrib.general; + + + + Este artículo describe los pasos que dí para + configurar un repositorio CVS con los mismos scripts + usados por el proyecto &os; en su configuración. + Tienen algunas ventajas frente a las demás + configuraciones de CVS, por ejemplo una gestión más + eficaz de los accesos a los árboles de código + la creación de mensajes de correo electrónico por + cada commit. + &trans.es.jcamou; + + + + + Introducción + + Muchos de los proyectos de software de código + abierto usan CVS como su sistema + de gestión de código. Aunque + CVS es bastante bueno para esto tiene sus + inconvenientes y sus flaquezas. Un ejemplo de esto es el compartir + un árbol de código con otros desarrolladores, lo cual + puede convertirse rápidamente en una pesadilla para la + administración del sistema, especialmente si se desea + proteger del acceso indiscriminado ciertas partes del + árbol. + + &os; es uno de los proyectos que usan + CVS. También cuenta con una gran + cantidad de desarrolladores alrededor del mundo. Ellos + mismos desarrollaron algunos scripts para hacer + del manejo del repositorio una tarea más fácil. + Recientemente estos scripts fueron revisados por + &a.joe; para facilitar su uso en otros proyectos. Este + artículo muestra uno de los métodos para usar estos + nuevos scripts. + + Si quiere sacar verdadero partido de la información que + se le brinda en este artílo debe tener familiaridad con + métodos básicos para realizar operaciones + CVS. + + + + Comienzo de la configuración + + + Es preferible que realice estos procedimientos + en un repositorio de prueba vacío y podamos asi asegurarnos + de que entiende todas las consecuencias. Como siempre, asegúrese + de tener respaldos recientes. + + + + Inicio del repositorio + + Lo primero a hacer al configurar un nuevo repositorio + es decirle a CVS que lo inicie: + + &prompt.user; cvs -d ruta-al-repositorio + init + + Esto le indica a CVS que cree + el directorio administrativo CVSROOT, + donde se albergarán todas las configuraciones. + + + + El grupo del repositorio + + Ahora vamos a crear al grupo dueño del repositorio. + Todos los committers necesitan estar en este + grupo, para de esta manera poder escribir en el repositorio. + Asumiremos el grupo ncvs por defecto + de &os;. + + &prompt.root; pw groupadd ncvs + + + A continuación, es necesario usar &man.chown.8; en el directorio + para ajustar los permisos al grupo reción agregado: + + &prompt.root; chown -R :ncvs + + path-a-su-repositorio + + Esto asegura que nadie podrá escribir en el repositorio + sin los permisos de grupo adecuados. + + + + Obtención del código + + Ahora es necesario obtener el directorio + CVSROOT del repositorio de &os;. Puede hacerse muy + fácilmente desde una réplica de CVS + anónimo de &os;. Para más información + + consulte el + capítulo correspondiente del Handbook. + Asumiremos que el código está en + CVSROOT-freebsd en el directorio + actual. + + + + Copia de los <quote>scripts</quote> de &os; + + El siguiente paso consiste en copiar el código de &os; + sito en CVSROOT a nuestro + repositorio. Si está familiarizado con CVS + , deberá estar pensando que esto se puede + realizar importando los scripts, lo que debería + permitirle sincronizar posteriores versiones muy fácilmente. + No es así, CVS tiene una + deficiencia en este aspecto: al intentar importar + código al directorio + CVSROOT no se actualizarán los + ficheros administrativos necesarios. Para hacer que esto + suceda es necesario ejecutar checkin + en cada uno de ellos después de importarlos, + perdiendo asi el valor de cvs import. + En consecuencia el método recomendado para este + cometido es sencillamente copiar los + scripts. + + No importa en realidad si no encuentra demasiado sentido al + párrafo anterior, el resultado será el mismo. + Simplemente haga check out de su CVSROOT + y copie los ficheros de &os; sobre su copia local: + + &prompt.user; cvs -d + ruta-a-su-repositorio checkout CVSROOT + &prompt.user; cd CVSROOT + &prompt.user; cp ../CVSROOT-freebsd/* . + &prompt.user; cvs add * + + Tenga en cuenta que probablemente recibirá advertencias + acerca de directorios no copiados; esto es normal, + porque éstos no son necesarios. + + + + Los <quote>scripts</quote> + + Ahora ya cuenta con una copia exacta en su directorio de + trabajo de los scripts que &os; usa en la + gestión de su repositorio. + He aquí una descripción del cometido de cada uno de + ellos. + + + + access - este fichero + no se usa en la configuración por defecto. + Se usa en la + configuración del proyecto &os;, + el cual controla el acceso al repositorio. Puede + borrar este fichero si no quiere usarlo en su + configuración. + + + + avail - este fichero + controla el acceso al repositorio. Dentro del mismo + es posible especificar grupos de personas + autorizadas para el acceso al repositorio, + asi como commits no autorizados en uno o más + directorios dados. Deberá + editarlo para que contenga los grupos + y directorios que se usarán en su + repositorio. + + + + cfg.pm - este fichero + se encarga de analizar su configuración + y provee la configuración por defecto. + No deberá usted + cambiar nada en este fichero. Si va a hacer cambios + su configuración deberán ir en + cfg_local.pm. + + + + + cfg_local.pm - + contiene todos los parámetros configurables del + sistema. Deberá configurar todo tipo de + cosas en este fichero, tales como el envío + por correo electrónico de los mensajes + de commit, desde qué hosts pueden + hacer commits los usuarios, etc. Más + información más adelante en el texto. + + + + checkoutlist - este fichero + lista todos los ficheros bajo control de + CVS en este directorio, aparte de aquellos + estándar creados por cvs init. + Deberá editar éste para borrar algunos + ficheros específicos del proyecto &os;. + + + + commit_prep.pl - este + script se encarga de realizar algunas comprobaciones + previas a cada commit según las modificaciones hechas o + o no en su versión de + cfg_local.pm. + No debería modificar este script. + + + + commitcheck - este script + es invocado directamente por CVS. + En primer lugar comprueba que la committer tenga + acceso a una parte específica del árbol usando + cvs_acls.pl, para después + ejecutar commit_prep.pl, mediante el que + efectuará las comprobaciones de rigor previas a cada + commit. Si todo ha ido bien CVS + permitirá que el commit tenga lugar. No debería + tocar este fichero. + + + + commitinfo - este fichero es + usado por CVS para determinar + qué script se deberá ejecutar + antes de hacer el commit, en este caso + commitcheck. + Tampoco debería tener que modificar este fichero. + + + + config - el fichero de + configuración del repositorio. Debería + editarlo si es necesario aunque la mayoría de + los administradores lo dejan tal y como viene por defecto. + Dispone de más información sobre las opciones + que pueden declararse en él en el manual de + CVS. + + + + cvs_acls.pl - este script + determina la identidad de los committers, así + como si tiene permitido acceder al árbol. + Está basado en el fichero avail. + No debería tener que modificar este fichero. + + + + cvsignore - este fichero especifica + los ficheros que CVS no debe + incluir en el repositorio. Puede editarlo a su gusto. + Para más información sobre fichero consulte + el manual de CVS. + + + + + cvswrappers - + CVS usa este fichero para activar + o desactivar la expansión de + la expansión de palabras clave o si el + fichero debe ser considerado binario. Este fichero puede + editarse según necesidades. Para más + información sobre este fichero consulte el manual de + CVS. + Tenga en cuenta que las opciones -t y + -f no funcionan correctamente con + CVS cliente/servidor. + + + + edithook - este fichero ya no + se usa, aunque se mantenga por razones históricas. + Este fichero puede borrarse con total tranquilidad sin miedo de + perjudicar la configuración. + + + + editinfo - CVS + usa este fichero en las sobreescrituras de + edición. &os; no usa esta función ya que el + análisis de mensajes de log se hace + mediante verifymsg y + logcheck. Esto se debe a que + editinfo no funciona correctamente con + commits remotos ni con aquellos que usan las opciones + -m o -F. + No debería tener que modificar este fichero. + + + + exclude - este fichero lista + expresiones regulares usadas por + commit_prep.pl para determinar ficheros + que no puedan contener cabeceras de revisión. En la + configuración que se usa en &os; todos los ficheros + bajo control de revisión necesitan tener lo que se + llama una cabecera de revisión + ($FreeBSD$). Todos los ficheros que aparezcan + en alguna de las líneas de + exclude no pasan por dicha revisión. + Incluya en este fichero entradas para aquellos ficheros que no + puedan tener una cabecera de revisión. Si va a instalar + los scripts CVSROOT/ es un + firme candidato para figurar en este fichero. + + + + log_accum.pl - este es el + script encargado de obtener el mensaje de + log que genera logcheck y + añadirlo a un fichero de log en el repositorio + para que pueda disponerse de respaldos en caso de necesidad. + También gestiona el envío de un correo electrónico + a la dirección que el administrador declare (en + cfg_local.pm). loginfo + se encarga de conectar log_accum.pl + con CVS. No + debería tener que modificar este este fichero. + + + + logcheck - este fichero revisa el + mensaje de commit proporcionado por el + committer e intenta esterilizarlo, valga la + expresión. Este fichero conecta con + CVS via verifymsg + . Tampoco debería tener que modificar este + fichero. + + Este script depende de un hack de + CVS propio de &os;: esta versión lee el + mensaje de log después de que este + script lo haya modificado. La versión + estándar de CVS + no hace esto, lo que hace a + logcheck incapaz de limpiar los mensajes de + log, aunque es capaz de comprobar que + esté sintácticamente correcto. + CVS 1.11.2 puede configurarse + para tener el mismo comportamiento que la + versión de &os; activando + RereadLogAfterVerify=always en el fichero + config. + + + + loginfo - este fichero es usado por + CVS para controlar dónde se + enví la información de log; + aquí es donde log_accum.pl + entra en escena. No debería tener que modificar + este fichero. + + + + + modules - este fichero mantiene su + significado tradicional en CVS. + Deberá borrar los módulos propios de &os; de la + versión que vaya a usar. Puede editarlo a su + gusto. Tiene más información acerca de este fichero + en el manual de CVS. + + + + notify - + CVS usa este fichero en caso de que + alguien ponga un fichero en modo watch. No se usa en el + repositorio de &os; y puede editarse cuanto se desee. + Tiene más información acerca de este fichero + en el manual de CVS. + + + + options - este fichero se usa + específicamente en la versión de CVS + + de &os;, así como en la versión de Debian. + Contiene una palabra clave para expander cabeceras de + revisión. Tendrá que modificar este fichero + y escribir la misma palabra que haya declarado en + cfg_local.pm (si es que quiere usar esa + característica, claro está; el valor por defecto + es FreeBSD) + + + + rcsinfo - este fichero mapea + directorios en el repositorio para aplicar una plantilla + como rcstemplate. Por defecto &os; + usa una plantilla para el repositorio. Es posible + añadir otras plantillas si se estima conveniente. + + + + tagcheck - este fichero controla + el acceso a marcar tags (etiquetas) en el + repositorio. La versión por defecto en &os; no admite + etiquetas con nombre RELENG* debido al proceso de ingeniería + de releases. Puede editar este fichero según sus + necesidades. + + + + taginfo - este fichero mapea operaciones + de etiquetado en los directorios del repositorio, cosa necesaria en + el funcionamiento habitual de scripts de control como + tagcheck. No debería tener que modificar + este fichero. + + + + unwrap - este script puede ser + usado para alterar el estado de ficheros binarios en una forma opuesta a + como lo hace cvswrappers, descrito al principio de esta + lista. No se usa en la configuración que funciona hoy día + en &os; porque no funciona correctamente con commits remotos. No + No debería tener que modificar este fichero. + + + + verifymsg - este fichero mapea + directorios del repositorio con scripts encargados del proceso + posterior de mensajes de commit en ficheros de log, por + ejemplo logcheck. + No debería verse en la necesidad de modificar este fichero. + + + + wrap - este script puede usarse + para poner ficheros binarios bajo el efecto de + cvswrappers (descrito al principio de esta + lista) en cada checkin. No se usa en la + configuración que mantiene el proyecto &os; porque no + funciona correctamente con commits remotos. No debería tener + que modificar este fichero. + + + + + + + Modificación de los <quote>scripts</quote> + + El siguiente paso es configurar los scripts para que + se adapten a sus necesidades. Tendrá que revisar todos y + cada uno de los ficheros en el directorio y hacer sus propios + cambios y configuraciones. Seguramente tendrá que editar los + siguientes ficheros: + + + + Si no desea usar los scripts de la + + configuración específica de &os; + puede borrar tranquilamente el fichero + access: + + &prompt.user; cvs rm -f access + + + + + Editar avail para que contenga los + diferentes directorios del repositorio en los cuales quiera + controlar el acceso. Asegúrese de mantener la línea + avail||CVSROOT, si no lo hace no podrí + realizar el siguiente paso. + + Otra de las opciones que puede añadir a este fichero + es el grupo de committers. Por defecto + &os; usa el fichero access para + listar todos sus committers pero se puede + usar cualquier fichero que se desee. También es + posible agregar grupos si se desea (la sintaxis está + declarada en la primera parte de cvs_acls.pl + ). + + + + Edite cfg_local.pm para que contenga + las opciones deseadas. Seguramente le serán de gran + interés las siguientes configuraciones: + + + + %TEMPLATE_HEADERS - éstos son + procesados por los scripts de log + y se insertan bajo el correo de commit si es que existen. + Puede que quiera borrar las entradas PR + y MFC after; y claro, puede agregar + las suyas. + + + + $MAIL_BRANCH_HDR - puede añadir + una cabecera en cada correo de commit en la que se detalle la + rama (branch) en la que se ha hecho el commit. + Defina la cabecera según su configuración y + necesidades o déjelo vacío si no desea usar dicha + cabecera. + + + + @COMMIT_HOSTS - defina éste valor + si desea listar los hosts desde los que será + posible hacer commits. + + + + + $MAILADDRS - defina éste como + la dirección del administrador o de alguna lista donde + reciban los correos de commit. + + + + @LOG_FILE_MAP - cambie este + valor como desee. Cada expresión regular + (regexp) se compara en el directorio del commit, y el + mensaje de log del commit se guarda en el subdirectorio + commitlogs en el nombre de fichero + mencionado. + + + + $COMMITCHECK_EXTRA - si no + desea usar las comprobaciones + de acceso específicas de &os; debería + borrar la definición de + $COMMITCHECK_EXTRA de este fichero. + + + + Cambiar el parámetro $IDHEADER + es algo que sólo puede asegurarse que funcionará en + &os;; depende de las modificaciones + específicas de CVS hechas por + &os;. + + Revise cfg.pm y compruebe si alguna de las + opciones puede modificarse, aunque los cambios propuestos en los + párrafos anteriores son bastante razonables. + + + + Seguramente quiera borrar las líneas del principio de + exclude (las que contienen + ^ports/, entre otras), puesto que son + específicas de &os;. Además de esto + comente las líneas que empiecen con + ^CVSROOT/ y agregue una línea sólo + con ^CVSROOT/. Después de que + wrapper sea instalado puede añadir + su cabecera a los ficheros en el directorio + CVSROOT y restaurar estas líneas; por lo + pronto sólo estarán estorbarán en el momento + que quiera hacer un commit. + + + + Edite modules y borre todo lo + relacionado con &os;. Añada sus propios módulos + si lo cree necesario. + + + + Este paso es sólo necesario si usted ha + declarado un valor a $IDHEADER + en cfg_local.pm (que sólo + funciona usando la versión de CVS + modificada por &os;). + + Edite options y asegúrese + de que la etiqueta declarada sea la misma que en + cfg_local.pm. Simplemente cambie la etiqueta + FreeBSD por la suya. + + + + Edite rcstemplate para que + contenga las mismas palabras clave + (o keywords) declaradas en + cfg_local.pm. + + + + Puede borrar (este paso es opcional) las comprobaciones + realizadas por tagcheck. Puede + simplemente añadir exit 0 al principio + del fichero para deshabilitar todas las comprobaciones que + hace sobre las etiquetas. + + + + El último paso antes de terminar es + asegurarse de que sea posible guardar de modo seguro los + mensajes de commit. Por defecto se guardan en el propio + repositorio, en el subdirectorio commitlogs + del directorio CVSROOT. Este + directorio debe crearse del siguiente modo: + + &prompt.user; mkdir commitlogs + &prompt.user; cvs add commitlogs + + + + + + Después de una revisión cuidadosa + debe hacer los commits necesarios con sus cambios. Asegúrese + de haber activado su acceso al directorio + CVSROOT en su avail antes + de intentarlo. Una vez haya comprobado que todo es correcto puede + hacer lo siguiente: + + &prompt.user; cvs commit -m '- Commit + para iniciar los scripts de FreeBSD' + + + + + Prueba de la configuración + + Ahora ya está listo para la primera prueba: un commit + forzado al fichero avail para asegurarnos + de que todo funciona como se espera. + + &prompt.user; cvs commit -f -m'Commit + forzado para probar los nuevos scripts en CVSROOT' + avail + + Si todo ha funcionado ¡felicidades! Dispone de una + configuración de los scripts de &os; en su repositorio. + Si CVS le da algún tipo de error + en algo revise todo de nuevo y asegúrese de que todos + los pasos se hayan hecho correctamente. + + + + + Configuración específica de &os; + + El proyecto &os; utliza una configuración + ligeramente diferente de la descrita; se usan los ficheros de + configuración del subdirectorio + freebsd en CVSROOT. + El proyecto lo hace de esta manera debido al gran número de + committers y a que todos y todas han de estar en el mismo grupo. + Un wrapper simple fué escrito para poder + asegurar que los usuarios tengan permisos correctos para poder hacer + hacer commits; este wrapper establece el id del grupo al + que el respositorio tiene. + + Si su repositorio lo necesita también los + pasos para hacerlo están documentados más adelante. Pero + antes de nada veamos una descripción de los ficheros involucrados. + + + Ficheros usados en la configuración de &os; + + + + + access - este fichero controla + la información de acceso. Se debe editar este + fichero e incluir a todos los miembros del proyecto. + + + + freebsd/cvswrap.c - este es el + código de CVS wrapper que va a ser necesario + instalar para hacer que todos los chequeos de acceso + funcionen. Mas información sobre él más + adelante en el texto. Debería editar las rutas de las + macros ACCESS y REALCVS + para que se correspondan con su configuración. + + + + + freebsd/mailsend.c - este fichero + es necesario para la configuración de la lista + de correo de &os;. No deber´ tocar este + fichero. + + + + + + + El procedimiento + + + + Edite el fichero access para que + sólo contenga su nombre de usuario. + + + + Edite el fichero cvswrap.c para que + contenga la ruta correcta de su configuración. Se + define con una macro llamada ACCESS. + Deberá cambiar también el lugar del binario de + cvs si no coincide con el de su + sistema. cvswrap.c está pensado + para sustituir al comando cvs del sistema, que pasará a + ser /usr/bin/ncvs + . + + Mi copia de cvswrap.c tiene lo + siguiente: + + #define ACCESS "/local/cvsroot/CVSROOT/access" +#define REALCVS "/usr/bin/ncvs" + + + + Instalaremos después wrapper para asegurarnos de que + se haya convertido en el grupo correcto al hacer el commit. + Tiene el código fuente en + cvswrap.c en su + CVSROOT. + + Tendrá que compilar el código una vez haya + incluido en el las rutas correctas: + + &prompt.user; cc -o cvs cvswrap.c + + E instálelos (necesitará ejecutar este paso como root): + + &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs + + &prompt.root; mv cvs /usr/bin/cvs + &prompt.root; chown root:ncvs + /usr/bin/cvs /usr/bin/ncvs + &prompt.root; chmod o-rw /usr/bin/ncvs + &prompt.root; chmod u-w,g+s /usr/bin/cvs + + + Esto instala wrapper como el comando cvs + por defecto; así nos aseguramos de que cualquiera que + quiera usar el repositorio necesita tener los niveles de acceso + correctos. + + + + Ahora ya puede eliminar a todos los usuarios del grupo del repositorio. + Todo control de acceso lo hará a partir de ahora wrapper y este wrapper + establecerá el grupo de acceso correcto. + + + + + + Prueba de la configuración + + Su wrapper debería estar listo. Deberí probarlo, + claro está, haciendo un commit forzado al fichero + access: + + &prompt.user; cvs commit -f -m 'Commit + forzado para probar los nuevos scripts en CVSROOT' + access + + Si algo falla asegúrese de que todos los pasos arriba + descritos se han realizado correctamente. + + +
+ diff --git a/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml b/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml index 733c9175bd..16627b1167 100644 --- a/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml +++ b/es_ES.ISO8859-1/articles/dialup-firewall/article.sgml @@ -1,429 +1,433 @@ %man; + +%translators; + ]>
Cortafuegos con Dialup en FreeBSD Marc Silver
marcs@draenor.org
 $FreeBSD$ En éste artículo se describe cómo configurar un cortafuegos que utiliza conexión PPP con FreeBSD e IPFW y más concretamente el uso de un cortafuegos en una conexión telefónica a la que se le asigna una IP dinámica. Éste documento no se ocupa de la configuración de la conexión PPP necesaria. + &trans.es.carvay; Prefacio Uso de un Cortafuegos en una Conexión Telefónica en FreeBSD En éste documento se expone el proceso necesario para configurar un cortafuegos en FreeBSD cuando la dirección IP es asignada dinámicamente por el ISP. Aunque se ha hecho todo lo posible por hacer éste documento tan informativo y correcto como sea posible puede enviar comentarios y/o sugerencias al autor a marcs@draenor.org, que serán bien recibidas. Configuración del Kernel Lo primero que tendrá que hacer es recompilar su kernel. Si necesita más información sobre cómo hacerlo el mejor recurso es la sección de Handbook acerca de la configuración del kernel. Necesitará añadir a su fichero de configuración del kernel las siguientes opciones: options IPFIREWALL Activa el código necesario para el cortafuegos en el kernel. options IPFW2 Activa la nueva versión de IPFW. Esto solo debe hacerse en FreeBSD 4.X puesto que en las versiones más recientes vienen incluído por defecto. options IPFIREWALL_VERBOSE Envia los paquetes que se ha decidido sean incluídos en un log a la aplicación encargada de gestionar los logs del sistema. options IPFIREWALL_VERBOSE_LIMIT=100 Limita el número de veces que una entrada que cumple las reglas puede ser incluída en los logs del sistema. Esto previene que sus logs se vean inundados por entradas repetidas. 100 es un número razonable, pero puede ajustarlo a sus necesidades. options IPDIVERT Activa los sockets divert, que serán descritos más tarde. Hay otras entradas opcionales que pueden compilarse en el kernel para incrementar la seguridad. No hacen falta para el funcionamiento del cortafuegos pero algunos usuarios especialmente paranoicos pueden querer usarlos. options TCP_DROP_SYNFIN Ignorar paquetes TCP con SYN y FIN. Esto evita ser vulnerable al uso de herramientas como security/nmap, que permiten identificar la pila TCP/IP de la máquina, pero incumple el soporte a las extensiones incluídas en el RFC1644. No se recomienda hacer tal cosa si la máquina va a ejecutar un servidor web. No reinicie tras recompilar el kernel. Si todo sale bien sólo necesitaremos reiniciar una vez en todo el proceso de instalación del cortafuegos. Modificación de <filename>/etc/rc.conf</filename> para cargar el cortafuegos Necesitamos hacer algunos cambios en /etc/rc.conf para darle ciertos detalles del cortafuegos. Es tan simple como añadir las siguientes líneas: firewall_enable="YES" firewall_script="/etc/firewall/fwrules" natd_enable="YES" natd_interface="tun0" natd_flags="-dynamic" Para más información sobre éstas entradas consulte /etc/defaults/rc.conf y lea &man.rc.conf.5; Desactivación de la Traducción de Direcciones de Red (NAT) de PPP Es posible que ya esté usando la NAT que incluye PPP. Si es su caso tendrá que desactivarla puesto que los casos que vamos a usar emplean &man.natd.8; para hacerlo. Si ya dispone de un grupo de entradas para arrancar automáticamente PPP probablemente se parezca a ésto: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" ppp_profile="profile" Si es su caso, tendrá que desactivar específicamente ppp_nat asegurándose de que ppp_nat="NO" existe en su in /etc/rc.conf. Tendrá tambié que borrar todas las entradas como nat enable yes o alias enable yes en /etc/ppp/ppp.conf. Las Reglas del Cortafuegos Casi hemos acabado. Lo único que nos falta es definir las reglas del cortafuegos, reiniciar y deberíamos tener nuestro cortafuegos funcionando perfectamente. Soy consciente de que cada cual tendrá necesidades distintas como reglas básicas. He intentado escribir unas reglas básicas que puedan cubrir las necesidades de un usuario de conexión telefónica normal. Vamos a comenzar por lo básico de un cortafuegos cerrado. Lo que se busca es rechazar todo por defecto y dejar pasar solamente lo que necesitemos. Las reglas deberían ir en la forma al principio permitir, luego rechazar. La premisa es que vamos a an˜adir reglas para lo que vamos a aceptar y luego rechazamos todo lo demás. :) Ahora vamos a crear el directorio /etc/firewall. Sitúese en el directorio y edite el fichero fwrules tal y como hemos escrito dentro de rc.conf. Por favor, no olvide que puede cambiar el nombre del fichero por cualquier otro que prefiera. Éste documento solamente facilita un ejemplo del nombre del fichero. Vamos a echar un vistazo a un ejemplo de fichero de configuración del cortafuegos que hemos comentado cuidadosamente. # Definimos el comando con el que invocamos al cortafuegos # (tal y como hemos incluído en /etc/rc.firewall) para # facilitarnos la lectura. fwcmd="/sbin/ipfw" # Fuerza el borrado de todas las reglas existentes en nuestro # cortafuegos antes de cargar el contenido de éste fichero. $fwcmd -f flush # Desvía todos los paquetes a través del interfaz tunnel. $fwcmd add divert natd all from any to any via tun0 # Permite todas las conexiones incluídas en reglas # dinámicas pero rechaza todas aquellas conexiones # establecidas que no estén incluídas en alguna # regla dinámica. $fwcmd add check-state $fwcmd add deny tcp from any to any established # Aceptar todas las conexiones de localhost. $fwcmd add allow tcp from me to any out via lo0 setup keep-state $fwcmd add deny tcp from me to any out via lo0 $fwcmd add allow ip from me to any out via lo0 keep-state # Aceptar todas las conexiones desde mi tarjeta de red que yo inicie. $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state # Todo el mundo a lo largo y ancho de Internet puede conectarse # a los siguientes servicios de la máquina. Éste # ejemplo permite específicamente las conexiones a sshd # y al servidor web. $fwcmd add allow tcp from any to me dst-port 22,80 in recv any setup keep-state # Ésto envía un RESET a todos los paquetes ident. $fwcmd add reset log tcp from any to me 113 in recv any # Activa ICMP: borre el tipo 8 si no quiere que su máquina # responda al ping. $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Rechazamos todo lo demás. $fwcmd add deny log ip from any to any Ya tiene usted un cortafuegos totalmente funcional que acepta todas las conexiones a los puertos 22 y 80 y registrará cualquier otro tipo de intento de conexión en un fichero log. Ahora podemos reiniciar tranquilamente y su cortafuegos debería empezar a trabajar tal y como le hemos dicho. Si le parece que hay algún dato incorrecto o tiene alguna sugerencia para mejorar éste documento por favor envíeme un correo electrónico. Preguntas ¿Por qué utiliza &man.natd.8; y &man.ipfw.8; cuando podría usar los filtros incluídos en &man.ppp.8;? Seré honesto y diré que no hay una razón clara por la que use ipfw y natd en lugar de los filtros que incorpora ppp. Tras hablarlo con mucha gente el consenso parece ser que ipfw es mucho más potente y configurable que el filtrado de ppp pero lo que se gana en funcionalidad lo pierde en facilidad de personalización. Una de las razones por las que prefiero usar esas aplicaciones es que creo má conveniente ejecutar un cortafuegos desde el kernel que desde una aplicación de entorno de usuario. Me aparecen mensajes como limit 100 reached on entry 2800 y después de eso ya no me aparecen más entradas indicando tráfico rechazado en mis logs. ¿Funciona mi cortafuegos? Esto significa simplemente que se ha alcanzado el máximo de entradas que pueden incluírse en el log cuando una determinada regla se ha cumplido. Esa regla sigue funcionando pero no enviaría más entradas al log hasta que el contador vuelva a cero. Puede poner a cero ese contador mediante ipfw resetlog. Además es posible elevar el límite de entradas a introducir en el log incluyendo la option en el fichero de de configuración del kernel. Por otra parte puede modificar ese valor (sin modificar su kernel y en consecuencia sin reiniciar la máquina) mediante el valor de &man.sysctl.8; net.inet.ip.fw.verbose_limit. Supongamos que estoy usando direcciones privadas internas, por ejemplo el rango 192.168.0.0. ¿Puedo añadir una regla al cortafuegos mediante un comando como $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via tun0 para prevenir intentos de acceso desde el exterior para conectar con máquinas de mi red?. La respuesta corta es no. La razón es que natd efectúa la traducción de direcciones para cualquier cosa que sea redirigida a través del dispositivo tun0. Eso significa que todos los paquetes entrantes hablarán exclusivamente con la IP asignada dinámicamente y no con la red interna. Hay que tener en cuenta sin embargo que es posible añadir una regla como $fwcmd add deny all from 192.168.0.4:255.255.0.0 to any via tun0, que evitaría que una de las máquinas de esa red enviara tráfico al exterior a través del cortafuegos. Debo de haber hecho algo mal. He seguido las instrucciones al pie de la letra y no tengo acceso a Internet. Estamos asumiendo que está usando userland-ppp, en consecuencia el conjunto de reglas que aquí se proponen operan en el interfaz tun0, que corresponde a la primera conexión efectuada mediante &man.ppp.8; (más conocido como user-ppp). Las conexiones efectuadas más tarde recibirán nombres como tun1, tun2 y así sucesivamente. Hay que tener también presente que &man.pppd.8; en cambio utiliza el interfaz ppp0, de modo que si se inicia la conexión con &man.pppd.8; hay que sustituír tun0 por ppp0. A continuación se muestra una forma muy limpia de modificar las reglas del cortafuegos. Conservaremos un fichero con las reglas originales con el nombre de fwrules_tun0. &prompt.user; cd /etc/firewall /etc/firewall&prompt.user; su Password: /etc/firewall&prompt.root; mv fwrules fwrules_tun0 /etc/firewall&prompt.root; cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules Para saber exactamente si está usando &man.ppp.8; o &man.pppd.8; examine la salida de &man.ifconfig.8; una vez que establezca la conexión. V.g., en una conexión hecha mediante &man.pppd.8; debería encontrarse con algo muy similar a lo siguiente (se muestran sólo las líneas relevantes): &prompt.user; ifconfig (eliminado...) ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xff000000 (eliminado...) Si por el contrario la conexión fué establecida mediante &man.ppp.8; (user-ppp) ésto es más o menos lo que se encontraría: &prompt.user; ifconfig (eliminado...) ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 (skipped...) tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 (IPv6 stuff skipped...) inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xffffff00 Opened by PID xxxxx (eliminado...)
diff --git a/es_ES.ISO8859-1/articles/explaining-bsd/Makefile b/es_ES.ISO8859-1/articles/explaining-bsd/Makefile index 43893528df..b4865b996d 100644 --- a/es_ES.ISO8859-1/articles/explaining-bsd/Makefile +++ b/es_ES.ISO8859-1/articles/explaining-bsd/Makefile @@ -1,23 +1,25 @@ # # $FreeBSD$ # MAINTAINER=grog@FreeBSD.org DOC?= article FORMATS?= html +WITH_ARTICLE_TOC?=YES + INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= # SRCS incluye todos y cada uno de los ficheros SGML que conforman el # documento. Cualquier cambio en cualquiera de ellos implica volver a # generar el documento. # # SGML content SRCS= article.sgml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml b/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml index 25ecbe2b39..790083692a 100644 --- a/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml +++ b/es_ES.ISO8859-1/articles/explaining-bsd/article.sgml @@ -1,654 +1,658 @@ %man; %freebsd; + +%translators; + ]>
Qué es BSD Greg Lehey
grog@FreeBSD.org
 En el mundo del código abierto la palabra Linux suele ser utilizada como sinónimo de Sistema Operativo pero no es el único sistema operativo libre &unix;. En Abril de 1.999 el Internet Operating System Counter reflejaba que el 31'3% de los sistemas que ofrecían algún servicio en Internet usaban Linux y el 14'6% usaban BSD &unix;. Alguna de las empresas más grandes de Internet, como por ejemplo Yahoo!, usan BSD. El servidor - de FTP que más tráfico soporta del mundo, ftp.cdrom.com, transfiere 1'4 TB - diariamente usando BSD. Es fácil suponer que no se trata de un - nicho de mercado: BSD es un secreto bien guardado. + de FTP con más carga en 1999 (ahora desaparecido) , ftp.cdrom.com, transfería + 1'4TB diariamente usando BSD. Es fácil suponer que no se trata + de un nicho de mercado: BSD es un secreto bien guardado. ¿Así que cuál es el secreto? ¿Por qué BSD no es más conocido? Éste artículo trata sobre esa y otras cuestiones. A lo largo de éste artículo serán destacadas de éste modo. + &trans.es.bazcar; ¿Qué es BSD? BSD son las siglas de Berkeley Software Distribution. Así se llamó a las distribuciones de código fuente que se hicieron en la Universidad de Berkeley en California y que en origen eran extensiones del sistema operativo &unix; de AT&T Research. Varios proyectos de sistemas operativos de código abierto tienen su origen en una distribución de éste código conocida como 4.4BSD-Lite. Añaden además un buen número de paquetes de otros proyectos de Código Abierto, incluyendo de forma destacada al proyecto GNU. El sistema operativo completo incluye: El kernel BSD, que se encarga de la programación del tiempo de ejecución de los procesos, la gestión de memoria, el multiproceso simétrico (SMP), los controladores de dispositivos, etc. A diferecia del kernel Linux existen varios kernel BSD con diversas funciones. La biblioteca C, la API base del sistema. La biblioteca C de BSD está basada en código procedente de Berkeley no del proyecto GNU. Aplicaciones como las distintas shells, aplicaciones de gestión de ficheros, compiladores y enlazadores. Algunas de las aplicaciones derivan del proyecto GNU, otras no. El sistema X Window, que gestiona el entorno gráfico. El sistema X Window que se usa en la mayoría de versiones de BSD es producto de un proyecto aparte, el Proyecto XFree86. Se usa el mismo código que en Linux. BSD por lo general no predetermina un gestor de ventanas como KDE o GNOME, aunque éstos y otros muchos esten disponibles. Muchos otros programas y utilidades. Entonces ¿es un UNIX verdadero? Los sistemas operativos BSD no son clones sino derivados de código abierto del sistema operativo de AT&T Research, el cual es a su vez ancestro del moderno UNIX System V. Ésto puede sorprenderle. ¿Cómo puede haber sucedido esto si AT&T jamás ha liberado su código? Cierto es que AT&T UNIX no es código abierto y que en un sentido estricto de copyright BSD no es en absoluto UNIX, pero por otra parte AT&T ha incluído fuentes de otros proyectos, teniendo como caso notable el Computer Sciences Research Group de la Universidad de Berkeley, California. En 1.976 el CSRG comienza a distribuir su software en cintas, dándoles la denominación Berkeley Software Distribution, o BSD. Las primeras distribuciones BSD consistían principalmente en aplicaciones de entorno de usuario (userland) pero la situación cambió de modo drástico cuando el CSRG firmó un contrato con la Agencia de Investigación de Proyectos Avanzados (DARPA) para mejorar los protocolos de comunicación en su red ARPANET. A los nuevos protocolos se les dió el nombre de Internet Protocols, y más adelante TCP/IP, que más tarde se habrían de covertir en los protocolos más importantes. La primera implementación ampliamente distribuída lo fué como parte de 4.2BSD, en 1.982. Durante la década de los 80 comienzan a surgir compañías que ofrecían estaciones de trabajo. La mayoría optó por adquirir licencias de UNIX en lugar de desarrollar sistemas operativos ellos mismos. En particular Sun Microsystems adquirió una licencia de UNIX e implementó una versión de 4.2BSD, a la que llamaron SunOS. Cuando la propia AT&T fué autorizada para vender UNIX iniciaron una implementación un tanto rudimentaria llamada System III, seguida rápidamente por System V. El código base de System V no incluía capacidad de trabajo en redes, de manera que todas sus implementaciones habían de usar software de BSD, incluyendo TCP/IP, así como aplicaciones como la shell csh y el editor vi. En conjunto esas inclusiones fueron conocidas como las Berkeley Extensions. Las cintas BSD contenían código fuente de AT&T y en consecuencia requerían una licencia de código UNIX. Hacia 1.990 al CSRG se le retiran los fondos y se enfrenta al cierre. Algunos de los miembros del grupo deciden distribuír el código BSD, que era Código Abierto, sin el código propiedad de AT&T. Finalmente ésto sucede con la Networking Tape 2, más conocida como Net/2. Net/2 no era un sistema operativo completo: faltaba aproximadamente un 20% del código del kernel. Uno de los miembros del CSRG, William F. Jolitz, escribió el código restante y lo distribuyó a comienzos de 1.992 como 386BSD. Al mismo tiempo otro grupo de antíguos miembros del CSRG fundaron una empresa llamada Berkeley Software Design Inc. y distribuyó una versión beta de un sistema operativo llamado BSD/386, que se basa en las mismas fuentes. El sistema operativo pasó a denominarse BSD/OS. 386BSD jamás llegó a ser un sistema operativo estable. En lugar de ello dos proyectos surgen de él en 1.993: NetBSD y FreeBSD. Ambos proyectos se forman gracias a la falta de paciencia que origina la espera de mejoras en 386BSD: el proyecto NetBSD comenzó a primeros de año y la primera versión de FreeBSD no estuvo lista hasta finales del mismo. En ese proceso el código base tomó caminos diferentes hasta tal punto que se hizo difícil de mezclar. Además los proyectos tienen objetivos diferentes, como veremos más adelante. En 1.996 otro proyecto, OpenBSD, se separa de NetBSD. ¿Por qué BSD no se conoce mejor? Existen diversas razones por las que BSD es relativamente desconocido: Los desarrolladores de BSD con frecuencia están más interesados en depurar su código que en promocionarlo. La mayor parte de la popularidad de Linux se debe a factores externos a los proyectos Linux, como la prensa y las compañías que ofrecen servicios relacionados con Linux. Hasta hace poco los BSD de fuente abierta carecían de tales abogados. Los desarrolladores de BSD suelen estar más experimentados que los de Linux y ponen menos de su parte a la hora de hacer el sistema fácil de usar. Los recién llegados suelen sentirse más cómodos con Linux. En 1.992 AT&T denunció a BSDI, el distribuidor de BSD/386, alegando que el producto contenía código propiedad de AT&T. El caso fué sobreseído en 1.994 pero la huella del litigio perdura. Aún en Marzo de 2.000 en un artículo publicado en la web se aseguraba que el caso había sido resuelto hace poco. Un detalle que el proceso judicial aclaró fue el de la nomenclatura: en los 80 BSD era conocido como BSD UNIX . Tras la eliminación del último vestigio de código de AT&T, BSD perdió el derecho a llamarse UNIX. Es por esto que es posible encontrar títulos de libros referentes a the 4.3BSD UNIX operating system y the 4.4BSD operating system y the 4.4BSD operating system. Existe la creencia de que los proyectos BSD están fragmentados y enfrentados entre sí. El Wall Street Journal habló de la balcanización de los proyectos BSD. Como en el caso del pleito, esa creencia se fundamenta en historia antígua. Comparemos BSD y Linux De manera que, ¿cuál es la diferencia entre, digamos, Debian Linux y FreeBSD? Para el usuario avanzado la diferencia es sorprendentemente pequeña: ambos son sistemas operativos tipo UNIX. Ambos son desarrollados por proyectos no comerciales (ésto, por supuesto, no es aplicable a la mayoría del resto de distribuciones de Linux). En el siguiente apartado tomaremos BSD como punto de partida y lo compararemos con Linux. La descripción se ajusta más a FreeBSD, que posée aproximadamente el 80% de los sistemas BSD instalados, pero las diferencias con NetBSD y OpenBSD son pequeñas. ¿Quién posée BSD? Ninguna persona o empresa posée BSD. Su creación y distribución es obra de una comunidad de voluntarios altamente cualificados y comprometidos a lo largo y ancho del mundo. Algunos de los componentes de BSD son proyectos de Código Abierto que cuentan con responsables ajenos al proyecto BSD. ¿Cómo se desarrolla y actualiza BSD? Los kernel BSD son desarrollados y actualizados siguiendo el modelo de desarrollo de Código Abierto. Cada proyecto mantiene un árbol de fuentes accesible públicamente mediante un Sistema Concurrente de Versiones (Concurrency Versions System, CVS), que contiene todos los ficheros fuente del proyecto, incluídos los de la documentación y otros ficheros relacionados. CVS permite a los usuarios hacer un check out (en otras palabras, extraer una copia) de los ficheros que componen la versión elegida del sistema. Un gran número de desarrolladores de muy diversas partes del mundo contribuye con mejoras a BSD. Estan divididos en tres categorías: Contributors son aquellos que escriben código o documentación. No se les permite hacer commit (es decir, añadir código) directamente al árbol de fuentes. Para que su código sea incluído en el sistema debe ser revisado y probado por un desarrollador registrado. Un/a committer. Committers son desarrolladores que disponen de acceso de escritura en el árbol de fuentes. Para convertirse en committer es necesario demostrar habilidad en el área en la cual él o ella trabaja. Depende del criterio individual de cada committer cuándo pedir autorización antes de hacer cambios en el árbol de fuentes. En general un committer experimentado puede incluír cambios que son obviamente correctos sin necesidad de consenso. Por ejemplo, un/a committer que trabaje en un proyecto de documentación puede corregir errores tipográficos o gramaticales sin necesidad de revisión. Por otra parte, se espera de desarrolladores que pretendan realizar cambios de gran calado o complicados que envíen sus cambios para que sean revisados antes de ser incluídos. En casos extremos un miembro del core team con una función como la del Principal Architect puede pedir que los cambios sean retirados del árbol; es lo que llamamos backing out. Todos los/las committers reciben un correo electrónico acerca de cada cambio concreto en el árbol de fuentes así que no es posible hacerlo en secreto. El Core team. Tanto FreeBSD como NetBSD disponen de un core team que coordina el proyecto. Los core team dirigen el rumbo de los proyectos pero sus funciones no siempre están claras. No es necesario ser desarrollador para ser un miembro de un core team pero suele ser lo habitual. Las normas de un core team varían de un proyecto a otro pero en general tienen más influencia sobre la dirección del proyecto. Éte sistema difiere del de Linux en algunos aspectos: Nadie posée el principio de autoridad. En la práctica eso es muy relativo, puesto que el Chief Architect puede solicitar que cierta entrada del árbol de fuentes sea eliminada e incluso en el proyecto Linux a ciertas personas les está permitido hacer cambios. Por otra parte hay un repositorio central, un único lugar donde encontrar las fuentes del sistema operativo íntegro, incluyendo todas las versiones anteriores. Los BSD mantienen el Sistema Operativo completo, no únicamente el kernel. Ésta distinción es válida únicamente como definición puesto que ni BSD ni Linux son útiles sin aplicacionesr: las aplicaciones que se usan en BSD suelen ser las mismas que las que se usan en Linux. Como resultado del mantenimiento estructurado de un único árbol de fuentes mediante CVS el desarrollo de BSD es limpio y es posible acceder a cualquier versión del sistema por su número de versión o por la fecha. Del mismo modo CVS permite actualizaciones incrementales del sistema: por ejemplo el repositorio de FreeBSD es actualizado en torno a 100 veces al día, aunque la mayoría de esos cambios son pequeños. Versiones de BSD Cada proyecto BSD pone a disposición pública tres releases (versiones) distintas. Igual que en Linux, las releases tienen asignado un número como por ejemplo 1.4.1 ó 3.5. Además el número de versión tiene un sufijo que indica su propósito: La versión de desarrollo del sistema recibe el nombre de CURRENT. FreeBSD asigna un número a CURRENT, por ejemplo FreeBSD 5.0-CURRENT. NetBSD utiliza un sistema ligeramente diferente y añade un sufijo compuesto por una única letra que indica cambios en las interfaces internas, por ejemplo NetBSD 1.4.3G. OpenBSD no asigna ningún número ("OpenBSD-current"). Ésta rama es la que incluye todo el desarrollo. A intervalos regulares, entre dos y cuatro veces al año, los proyectos liberan una versión RELEASE del sistema, que está disponible en CD-ROM y mediante FTP para su descarga gratuíta, por ejemplo OpenBSD 2.6-RELEASE o NetBSD 1.4-RELEASE. La versión RELEASE está dirigida al usuario final y es la versión estándar del sistema. NetBSD también dispone de patch releases que incluyen un tercer dígito, como por ejemplo NetBSD 1.4.2. A medida que se van encontrando errores en la versión RELEASE son corregidos y las soluciones son incluídas en el árbol CVS. En FreeBSD la versión resultante se denomina versión STABLE, mientras que en NetBSD y OpenBSD continúa siendo la versión RELEASE. Nuevas características más pequeñas pueden ser añadidas en ésta rama tras un período de pruebas en la rama CURRENT. Linux, en cambio, mantiene dos árboles de código separados: la versión estable y la versión de desarrollo. Las versiones estables añaden un número par de versión, como 2.0, 2.2 ó 2.4. Las versiones de desarrollo añaden un número impar, como en 2.1, 2.3 ó 2.5. En ambos casos a ese número se le añade otro más que indica la versión exacta. Por si fuera poco cada distribuidor añade sus propios programas y aplicaciones de entorno de usuario, así que el número de versión es importante. Cada distribuidor además asigna números de versión a la distribución, así pues la descripción completa podría ser algo como TurboLinux 6.0 with kernel 2.2.14 ¿Cuántas versiones de BSD existen? A diferencia de las numerosas distribuciones de Linux tan sólo hay tres BSD libres. Cada proyecto BSD mantiene su propio árbol de fuentes y su propio kernel. En la práctica, sin embargo, las diferencias en el entorno de usuario (userland) entre los distintos BSD son menores que las que hay en Linux. Es difícil enumerar los objetivos de cada proyecto puesto que las diferencias son muy subjetivas. En general, FreeBSD tiene como meta ofrecer alto rendimiento y facilidad de uso al usuario final y es uno de los favoritos entre proveedores de contenidos web. Funciona en PC y en procesadores Alpha de Compaq. El proyecto FreeBSD cuenta con un número de usuarios significativamente mayor que los otros proyectos. NetBSD tiene como meta la Portabilidad: No en vano su lema es of course it runs NetBSD (que podría traducirse como claro que funciona con NetBSD). Funciona en máquinas que abarcan desde PDAs a grandes servidores e incluso ha sido usado por la NASA en misiones espaciales. Es una excelente elección para utilizar viejo hardware no Intel. OpenBSD tiene como meta la seguridad y la integridad del código: combina del concepto de código abierto y una revisión rigurosa del código que dan como fruto un sistema muy correcto, elegido por instituciones preocupadas por la seguridad como bancos, entidades de cambio y departamentos gubernamentales de los EEUU. Al igual que NetBSD funciona en gran variedad de plataformas. Existen dos sistemas operativos BSD más que no son de código abierto, BSD/OS y el MacOS X de Apple: BSD/OS es el derivado más antíguo de 4.4BSD. No es código abierto pero es posible conseguir licencias de su código fuente a un precio relativamente bajo. Se parece a FreeBSD en muchos aspectos. Mac OS X es la última versión del sistema operativo para la gama Macintosh de Apple Computer Inc. El núcleo BSD Unix de éste sistema operativo, Darwin, está libremente disponible como sistema operativo de fuente abierto totalmente funcional para arquitecturas x86 y PPC. El sistema gráfico Aqua/Quartz y la mayoría de las demás aspectos característicos de Mac OS X son código cerrado. Varios desarrolladores de Darwin son también committers de FreeBSD y viceversa. ¿Qué diferencias hay entre la licencia BSD y la licencia pública GNU? Linux está disponible bajo la GNU General Public License (GPL), que fué diseñada para evitar el software cerrado. Más concretamente, cualquier trabajo derivado de un producto con licencia GPL debe suministrar el código fuente si es requerido. En contraste, la licencia BSD es menos restrictiva: permite la distribución en forma exclusivamente binaria. Éste aspecto es especialmente atractivo para aplicaciones empotradas. ¿Qué más debería saber? Dado que existen menos aplicaciones para BSD que para Linux los desarrolladores de BSD han creado un paquete de compatibilidad con Linux que permite hacer funcionar programas de Linux bajo BSD. El paquete contiene tanto modificaciones del kernel, con el fín de gestionar correctamente las llamadas al sistema de Linux, como ficheros necesarios para la compatibilidad con Linux como la Biblioteca C. No hay diferencias notables en velocidad de ejecución entre una aplicación de Linux ejecutándose en un sistema Linux y una aplicación Linux ejecutándose en un sistema BSD de la misma velocidad. El modelo todo del mismo proveedor de BSD implica que las actualizaciones son mucho más sencillas de gestionar de lo que con frecuencia son en Linux. BSD maneja las actualizaciones de versiones de bibliotecas suministrando módulos de compatibilidad para versiones anteriores, de modo que es posible ejecutar binarios con varios años de antiguedad sin problemas. Entonces ¿Qué debería usar, BSD - o Linux + o Linux? ¿Qué significa realmente esa pregunta? ¿Quién debería utilizar BSD y quién Linux?. Ésta es una pregunta muy difícil de responder. He aquí varias pautas: Si no está roto no lo arregles: Si ya usa un sistema operativo de código abierto y está satisfecho con él, probablemente no hay ninguna buena razón para cambiar. Los sistemas BSD, especialmente FreeBSD, pueden proporcionar un rendimiento notablemente superior que Linux, pero ésto no es una ley inmutable. En muchos casos no hay diferencia de rendimiento o ésta es muy pequeña. En algunos casos Linux podría tener un rendimiento mejor que FreeBSD. En general los sistemas BSD gozan de una mejor reputación en cuanto a disponibilidad, principalmente por la mayor madurez de su código base. La licencia BSD puede resultar más atractiva que la GPL. BSD puede ejecutar código de Linux, mientras que Linux no puede hacer lo propio con código de BSD. Como resultado de ésto hay una mayor cantidad de software disponible para BSD que para Linux. ¿Quién ofrece soporte, servicios y formación orientada a BSD? BSDi siempre ha ofrecido soporte para BSD/OS y en fechas recientes anunció contratos de soporte para FreeBSD. Además cada uno de los proyectos tiene una lista de consultores: FreeBSD, NetBSD, y OpenBSD.
diff --git a/es_ES.ISO8859-1/articles/fbsd-from-scratch/Makefile b/es_ES.ISO8859-1/articles/fbsd-from-scratch/Makefile index a7b6990bad..2a65ea202e 100644 --- a/es_ES.ISO8859-1/articles/fbsd-from-scratch/Makefile +++ b/es_ES.ISO8859-1/articles/fbsd-from-scratch/Makefile @@ -1,27 +1,27 @@ # # $FreeBSD$ # # Article: FreeBSD From Scratch DOC?= article FORMATS?= html MAINTAINER= schweikh@FreeBSD.org INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= # -#WITH_ARTICLE_TOC?=YES +WITH_ARTICLE_TOC?=YES # SGML content SRCS= article.sgml fase_1.sh fase_2.sh fase_3.mk DOC_PREFIX?= ${.CURDIR}/../../.. afterinstall: ${INSTALL_DOCS} ${.CURDIR}/fase_1.sh ${.CURDIR}/fase_2.sh \ ${.CURDIR}/fase_3.mk ${DESTDIR} .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml b/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml index 68ee29ec1f..b58fa74aa0 100644 --- a/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml +++ b/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.sgml @@ -1,722 +1,725 @@ %man; %freebsd; FreeBSD From Scratch"> + +%translators; ]>
FreeBSD From Scratch Jens Schweikhardt
schweikh@FreeBSD.org
 2002 Jens Schweikhardt $FreeBSD$ &scratch.ap; explica la instalación totalmente automatizada de un sistema &os; hecho a medida y compilado desde las fuentes, proceso que incluye además la compilación de sus ports favoritos y configurado para coincidir con su idea del sistema perfecto. Si cree que make world es un concepto fascinante &scratch.ap; lo amplía hasta ser make evenmore. N. del T. : Juego de palabras intraducible basado en el nombre que en &os; se da al proceso de recompilar todo el sistema desde los fuentes, make world, que podría traducirse muy libremente como hacer, o más bien rehacer el mundo entero y make evenmore, osea, hacer más aún. + &trans.es.carvay; Introducción ¿Ha actualizado alguna vez su sistema mediante make world?. Si solamente tiene un sistema en sus discos se encontrará con un problema. Si installworld falla a la mitad su sistema quedará dañado e incluso puede ser incapaz de arrancar de nuevo. O quizás installworld se ha ejecutado sin problemas pero el nuevo kernel no arranca. Se impone buscar el CD de Rescate y tratar de encontrar algo útil en aquellos backups que hizo hace seis meses. Creo en el paradigma de al actualizar sistemas operativos instala desde cero. Haciéndolo así, esto es, al borrar sobreescribiendo en los discos o mejor dicho las particiones, nos aseguraremos de no dejar datos antiguos en ellos, un aspecto éste del que la mayoría de los procesos de actualización no se preocupan en absoluto. Por otra parte borrar las particiones significa que tendrá que recompilar/reinstalar todos sus ports y packages y después de eso rehacer todas y cada una de las configuraciones que con muchos esfuerzos atesoraba. Si usted también piensa que ésta tarea debería automatizarse siga leyendo. ¿Por qué (no) debería interesarme &scratch.ap;? Esa es una pregunta muy razonable. Tenemos sysinstall, una compilación del kernel que funciona sin sorpresas y tenemos también las herramientas de entorno de usuario. El problema que tiene sysinstall es que está extremadamente limitado cuando se trata de qué, dónde y cómo queremos que haga la instalación. Normalmente se usa para instalar distribuciones precompiladas y packages desde diversas fuentes (CD, DVD, FTP). No puede instalar el resultado de make buildworld. No puede instalar un segundo sistema en un directorio de un sistema en funcionamiento. No puede hacer una instalación en particiones Vinum. No puede compilar ports, sólo instala packages precompilados. Es difícil automatizar mediante scripts o incluso hacer de forma manual los cambios que considere necesarios después de la instalación Por si todo esto fuera poco sysinstall está semioficialmente al final de su Ciclo de Vida Útil. El archiconocido proceso de construír/instalar el mundo (build/install world), explicado en el Handbook, por defecto realiza la tarea de sustituír el sistema existente. Sólo respeta el kernel y los módulos. Los binarios del sistema, los ficheros de cabecera y muchos otros ficheros son sobreescritos; hay ficheros obsoletos que se quedan donde estaban y pueden causar sorpresas. Si el proceso de actualización falla por alguna razón puede ser difícil o incluso imposible volver a dejar el sistema en el estado inicial. &scratch.ap; resuelve todos esos problemas. La estrategia es simple: utiliza un sistema en funcionamiento para instalar un nuevo sistema en un árbol de directorios y montar nuevas particiones limpiamente en ese árbol. Muchos ficheros de configuración pueden copiarse al sitio que les corresponda y &man.mergemaster.8; se encargará de aquellos a los que no. Pueden hacerse cambios discrecionales tras la instalación del nuevo sistema desde el viejo, como si el nuevo sistema estuviera dentro de un chroot. El proceso tiene tres fases, cada una de los cuales consiste en ejecutar un script de shell o invocar make: fase_1.sh: Crea un sistema nuevo y capaz de arrancar en un directorio vacío y combina o copia tantos ficheros como sea necesario. Una vez acabado esto arranca el nuevo sistema. fase_2.sh: Instala los ports que hayamos elegido. fase_3.mk: Remata la configuración del software instalado en la fase anterior. Una vez que ha usado &scratch.ap; para construír un segundo sistema y ha comprobado que funciona satisfactoriamente durante unas cuantas semanas puede usarlo de nuevo para reinstalar el sistema original. Desde ese momento cada vez que crea que debe actualizar un sistema simplemente elija las particiones que hay que borrar y reinstalar. Puede que haya oído hablar o incluso haya usado ya Linux From Scratch, LFS para ser más breve. LFS abarca también cómo construír e instalar un sistema desde cero en particiones vacías partiendo de un sistema en funcionamiento. El objetivo de LFS parece ser mostrar la razón de ser y de estar de todas y cada una de las partes del sistema (como el kernel, el compilador, los dispositivos, la shell, la base de datos de terminales, etc.) y los detalles de la instalación de cada parte. &scratch.ap; no entra en detalles tan exahustivos. Mi intención es facilitar una instalación automatizada y completa, no explicar cada detalle escabroso del ciclópeo proceso que arrancamos cuando hacemos un make world. Si desea usted explorar &os; de modo tan profundo comience por leer /usr/src/Makefile y siga cuidadosamente lo que sucede al teclear make buildworld. Hay también algunos detalles delicados con los que me encontré durante el desarrollo de &scratch.ap; que debería tener muy en cuenta. El sistema no puede ser usado normalmente durante la compilación de los ports que tiene lugar en la segunda fase. Si va a ejecutar el proceso en un servidor en producción tenga en cuenta el tiempo de parada provocado por la fase dos. Los ports compilados por fase_2.sh necesitan aproximadamente 4 horas para acabar en un sistema SCSI AMD1800+ con discos de 10.000 rpm y 1GB de RAM. Requisitos previos Para poder usar &scratch.ap; necesitará lo siguiente: Un sistema &os; con el árbol de ports y los fuentes instalados. Al menos una partición vacía donde instalaremos el nuevo sistema. Experiencia en el uso de &man.mergemaster.8; o al menos no tener miedo de usarlo. Si su acceso a Internet es lento o si no dispone del mismo necesitará los distfiles de los ports que vaya a instalar. Conocimientos básicos de confección de scripts de shell con la shell Bourne, &man.sh.1; Finalmente, debería ser capaz de decirle a su boot loader (cargador de arranque) cómo arrancar el nuevo sistema, en modo interactivo o mediante un fichero de configuración. Primera Fase: Instalación del Sistema Lo que vamos a explicar más adelante es mi fase_1.sh. Tendrá que modificarlo en varios sitios para que cuadre con su propia idea del sistema perfecto. He intentado incluír todos los comentarios posibles en los sitios donde debería usted introducir sus cambios. Los puntos a estudiar son: Esquema de particiones. No estoy de acuerdo con la idea de una sola partición inmensa en la que instalar todo el sistema. Mis sistemas tienen generalmente al menos una partición para /, /usr y /var con /tmp enlazado simbólicamente a /var/tmp. Además comparto los sistemas de ficheros en los que ubico /home (los directorios de los usuarios), /home/ncvs (réplica del repositorio de &os;, /usr/ports (el árbol de ports), /src (diversos árboles de fuentes de procedencias varias) y /share (otros datos compartidos que no necesitan ser guardados, por ejemplo mensajes de news. Lujos. Me refiero a lo que usaremos inmediatamente tras el arranque del nuevo sistema e incluso antes de la segunda fase. En mi caso se trata de shells/zsh puesto que es la shell que aparece en mi cuenta de usuario en /etc/passwd. De todos modos la tarea puede culminarse sin esos lujos (de ahí su nombre), todo lo que necesita es entrar en el sistema como root y pasar a la siguiente fase. ¿Por qué no instalar entonces todos mis ports en la primera fase?: en teoría y en la práctica nos encontraremos con problemas de arranque y de consistencia: durante la primera fase tendrá funcionando su viejo kernel mientras el entorno chroot dispone de sus propios binarios y ficheros de cabecera todos nuevos. Si por ejemplo el sistema nuevo integra una nueva llamada al sistema (conforme a sus cabeceras) algunos scripts de configuración podrían intentar usarla y en concuencia ver muertos sus procesos al tratar de ejecutarse en el viejo kernel. He tenido problemas de otro tipo al intentar construír lang/perl5. Antes de ejecutar fase_1.sh asegúrese de haber cumplido con las tareas previas a un make installworld installkernel, es decir: haber adaptado el fichero de configuración de su kernel haber completado sin errores make buildworld haber completado sin errores KERNCONF= nombre_de_su_kernel Cuando ejecute fase_1.sh por primera vez y copie sus ficheros de configuración de su sistema en funcionamiento a su nuevo sistema no están al día con respecto a lo que hay bajo /usr/src, así que mergemaster le preguntará por lo que quiere hacer. Le recomiendo combinar los cambios. (Nota del traductor: merge (to): unir, fusionar, mezclar). Si se cansa de pelear con los diálogos de mergemaster puede simplemente actualizar sus ficheros una vez en el sistema original (pero sólo si existe esa opció: por ejemplo, si uno de sus sistemas usa -STABLE y el otro -CURRENT los cambios tienen bastantes probabilidades de ser incompatibles). En posteriores usos de mergemaster detectará que los ID de las versiones RCS de esos ficheros coinciden con los que están bajo /usr/src y no les prestará más atención. El script fase_1.sh detendrá su ejecución si falla alguno de los comandos que contiene (si alguno da una salida distinta de cero) por incluír set -e, así que es imposible que pase por alto algún error. Antes de seguir adelante debería asegurarse de que no hay errores en su versión de fase_1.sh. En fase_1.sh invocamos mergemaster. Tanto si alguno de los ficheros requiere ser combinado como si no, mergemaster emitirá el siguiente mensaje *** Comparison complete Do you wish to delete what is left of /var/tmp/temproot.fase1? [no] no es decir *** Comparación completada ¿Quiere borrar el contenido de /var/tmp/temproot.fase1? [no] no Por favor, responda no o simplemente pulse Enter. Eso es debido a que mergemaster habrá dejado unos cuantos ficheros de longitud igual a cero en /var/tmp/temproot.fase1 y los copiará al nuevo sistema (a menos que ya estén ahí). Después mostrará los ficheros que ha instalado mediante &man.more.1; o si lo prefiere mediante &man.less.1;): *** You chose the automatic install option for files that did not exist on your system. The following were installed for you: /rootnuevo/etc/defaults/rc.conf ... /rootnuevo/COPYRIGHT (END) es decir *** Ha elegido la opción de instalar automáticamente los ficheros que no existen en su sistema. Han sido instalados los siguientes: /rootnuevo/etc/defaults/rc.conf ... /rootnuevo/COPYRIGHT Teclée q para salir del paginador. Ahora se le informará sobre login.conf: *** You installed a login.conf file, so make sure that you run '/usr/bin/cap_mkdb /newroot/etc/login.conf' to rebuild your login.conf database Would you like to run it now? y or n [n] es decir *** Ha instalado un fichero login.conf así que asegúrese de ejecutar '/usr/bin/cap_mkdb /rootnuevo/etc/login.conf' para reconstruír la base de datos de login.conf ¿Quiere ejecutarlo ahora mismo? (s)i o (n)o [n] La respuesta no tiene importancia puesto que ejecutaremos &man.cap.mkdb.1; en todos los casos. Todo lo que hace fase_1.sh queda registrado en un fichero log para que pueda examinarse con detalle si es preciso. Éste es el fase_1.sh del autor, así que tendrá que modificarlo a conciencia, en especial los pasos 1, 2, 5 y 6. Por favor, ponga una atención esmerada a las entradas en las que aparece &man.newfs.8;. Si bien es cierto que es imposible crear nuevos sistemas de archivos en particiones montadas nuestro script no tendrá ningún inconveniente en borrar cualquier partición que no esté montada y con los nombres que aparezcan en él, en nuestro caso /dev/da3s1a, /dev/vinum/var_a y /dev/vinum/usr_a. Puede provocar un desastre, así que asegúrese de cambiar los nombres de los dispositivos como corresponda. Descargue fase_1.sh. La ejecución de éste script instala un sistema equipado con lo siguiente: Usuarios y grupos heredados del anterior sistema. Acceso a Internet mediante Ethernet y PPP protegido por un cortafuegos. NTP y zona horaria correctas. Algunos ficheros secundarios como /etc/ttys e inetd. Hay otras áreas listas para ser configuradas pero no las tocaremos hasta concluír la segunda fase. Por ejemplo, hemos copiado unos cuantos ficheros para configurar la impresión y X11. Sin embargo la impresión suele necesitar de aplicaciones que no se encuentran en el sistema base, por ejemplo PostScript. X11 no funcionará hasta que no compilemos el servidor, las bibliotecas y los programas. Segunda Fase: Instalación de <quote> ports</quote> En ésta fase es posible instalar packages (que vienen precompilados) en lugar de compilar ports. Para poder hacerlo convertiremos fase_2.sh en poco más que una lista de comandos pkg_add. Confío en que será usted capaz de escribir un script como ese. Ahora nos concentraremos en el sistema tradicional y mucho más flexible de funcionamiento de los ports. El siguiente script fase_2.sh es el que yo uso para instalar mis ports favoritos. Puede ejecutarse tantas veces como sea preciso y no prestará atención a los ports que ya estén instalados. Incluye también soporte para la opción que hace un ensayo general con todo, es decir, muestra lo que hubiera sucedido si se hubiera ejecutado. Seguro que tiene que editar la lista de ports y probablemente tenga que cambiar unas cuantas variables de entorno. La lista de ports consiste en líneas de dos o más palabras separadas por espacios: la categoría y el port. Es opcional situar detrás un comando de instalación que compilará e instalará el port (por defecto make install). Se ignoran las líneas vacís y las que comienzan por #. La mayoría de las veces es suficiente incluír el nombre del port y la categoría a que pertenece pero existen unos pocos ports en cuya compilación podemos afinar mucho asignando valores a variables de make; veamos un ejemplo: www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install mail procmail make BATCH=yes install De hecho puede usted usar comandos de shell a su criterio, así que no tiene que limitarse a simples invocaciones de make: java linux-sun-jdk13 yes | make install news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install Observe que la línea de news/inn-stable es un ejemplo de una asignación de entrada a la variable del intérprete de mandatos CONFIGURE_ARGS. El fichero Makefile del port la usará como valor inicial y la completará con otros argumentos esenciales. La diferencia respecto a a especificar la variable para make en la línea de comandos mediante news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install está en que esto último sustituye directamente el valor en lugar de completarlo. El método más adecuado depende de cada port en particular. Compruebe cuidadosamente que ninguno de sus ports tenga una instalación interactiva, es decir, que ninguno deberí intentar recibir de stdin nada que no le dé usted en stdin. Si alguno lo hace leerá la siguiente o siguientes líneas de éste documento y no entenderá nada de nada. Si fase_2.sh pasa por alto un port o cesa su ejecución sin razón aparente es muy posible que esa sea la razón. He aquí fase_2.sh. Crea un fichero log por cada port que instala y les da nombres según el esquema DIRECTORIO_LOG/categoría+port. Si no tiene una copia de su fase_2.sh en una partición compartida no olvide copiarlo al sistema nuevo antes de arrancarlo. Descargue fase_2.sh. Tercera Fase Ya hemos concluído la segunda fase y ya están instalados sus queridísimos ports, pero algunos de ellos requieren un poco de configuración. En eso consistirá la tercera fase, añadir los detalles específicos de las configuraciones. Podría haberlos integrado en el script fase_2.sh pero creo que hay una diferencia conceptual entre instalar un port y en modificar la configuración con la que viene por defecto para adaptarla a nuestros gustos o necesidades y creo por lo tanto que esa diferencia justifica una separación en una fase propia. He creído más conveniente implementar la tercera fase como un Makefile porque admiten la selección de lo que quiera configurar tecleando simplemente: &prompt.root; make -f fase_3.mk nombre_del_port Al igual que con fase_2.sh asegúrese de que dispone de una copia de su fase_3.mk una vez que arranca el sistema nuevo, bien situándolo en una partición compartida bien copiándolo en algún lugar dentro del nuevo sistema. Descargue fase_3.mk. Restricciones La instalación automatizada de un port puede resultar difícil si es interactiva y no soporta make BATCH=YES install. En algunos casos la interacción se reduce a teclear yes cuando se le pregunta si acepta alguna licencia. Si esa entrada de datos ha de llegar por la entrada estándar simplemente redirigiremos las respuestas pertinentes a la orden de instalación (que suele ser make install; ese es el modo en el que hemos procedido con java/linux-sun-jdk13 en fase_2.sh). No obstante ésta estrategia no funciona con editors/staroffice52, que exige que X11 esté funcionando. El proceso de instalación comprende un buen número de pulsaciones de ratón y de tecleo, con lo que es imposible automatizarlo tal y como se hace con otros ports. Sin embargo el siguiente atajo workaround nos soluciona el problema: previamente he creado un staroffice en el sistema original con &prompt.root; cd /usr/ports/editors/staroffice52 &prompt.root; make package ===> Building package for staroffice-5.2_1 Creating package /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz Registering depends:. Creating bzip'd tar ball in '/usr/ports/editors/staroffice52/staroffice-5.2_1.tbz' y durante la segunda fase usamos: &prompt.root; pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz Debe usted también tener muy en cuenta posibles problemas con los ficheros de configuración a la hora de actualizar. En general no sabemos cuándo van a hacerse cambios en el formato o el contenido de un fichero de configuración. Es posible que haya que añadir un nuevo grupo a /etc/group, o quizás /etc/passwd necesite un nuevo campo en sus entradas. Éstas cosas han sucedido en alguna ocasión anteriormente. Si simplemente copiamos un fichero de configuración del sistema viejo al nuevo será suficiente la mayoría de la veces pero ya hemos visto dos casos en los que no lo era. Si actualiza su sistema siguiendo el sistema ortodoxo (sobreescribiendo los ficheros antíguos) tendrá que usar mergemaster para proceder con los cambios que quiera incluír en la configuración de su nuevo sistema, teniendo en cuenta que entre esos cambios hay o puede haber nuevos ficheros. Por desgracia mergemaster sólo es útil con ficheros del sistema base y no para aquellos relacionados con los ports. Además, ciertas aplicaciones parecen especialmente diseñadas para sacarme de mis casillas por el procedimiento de cambiar el fichero de configuración cada quince días. Lo único que puede hacerse es estar alerta, sobre todo cuando cambia el número de versión. En ocasiones anteriores he tenido que modificar o reescribir ficheros para servidores web, servidores y clientes de news. Cualquier tipo de software cuyo mantenimiento sea muy activo es un firme candidato a que sus ficheros de configuración merezcan nuestro examen. He usado &scratch.ap; varias veces para actualizar un sistema 5-CURRENT a 5-CURRENT, esto es, nunca he intentado instalar 5-CURRENT desde un sistema 4-STABLE o viceversa, pero dada la cantidad de cambios existentes entre las diferentes RELEASE no sería insensato esperar que esa tarea sea un tanto compleja. Usar &scratch.ap; para actualizaciones dentro del campo de 4-STABLE debería ser mucho menos penoso (aunque yo aún no lo he intentado). Si quiere hacerlo debería tener en cuenta lo siguiente: Si no usa el sistema de ficheros de dispositivo (devfs) puede necesitar crear los dispositivos necesarios para su hardware con &man.MAKEDEV.8; en la primera fase, sexto paso.
diff --git a/es_ES.ISO8859-1/articles/laptop/Makefile b/es_ES.ISO8859-1/articles/laptop/Makefile index 75956fd2f8..9fa0dd9c5f 100644 --- a/es_ES.ISO8859-1/articles/laptop/Makefile +++ b/es_ES.ISO8859-1/articles/laptop/Makefile @@ -1,18 +1,22 @@ # # $FreeBSD$ # # Article about using FreeBSD on laptops # "Article" sobre FreeBSD en computadoras portátiles. DOC?= article FORMATS?= html INSTALL_COMPRESSED?=gz INSTALL_ONLY_COMPRESSED?= +# +WITH_ARTICLE_TOC?=YES + + SRCS= article.sgml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/laptop/article.sgml b/es_ES.ISO8859-1/articles/laptop/article.sgml index 2095f1c67b..93d0e2eb30 100644 --- a/es_ES.ISO8859-1/articles/laptop/article.sgml +++ b/es_ES.ISO8859-1/articles/laptop/article.sgml @@ -1,369 +1,372 @@ %man; %freebsd; %authors; %mailing-lists; + +%translators; ]>
FreeBSD en ordenadores portátiles $FreeBSD$ FreeBSD funciona perfectamente en la mayoría de portátiles aunque siempre haya excepciones. En éste artículo trataremos de las diferencias existentes en el hardware de portátiles y sistemas de escritorio y de cómo afecta esto al uso de FreeBSD. + &trans.es.bazcar; Es frecuente que se piense en FreeBSD como un sistema operativo para servidores pero funciona muy bien como sistema de escritorio y si quiere usarlo en su portátil dispondrá de todo su potencial: facilidad de administración y actualización, el sistema de ports y packages para añadir software, etc. Otras de sus características más interesantes, como la estabilidad, el rendimiento en red y bajo grandes cargas de trabajo pueden, por razones obvias, no ser tan evidentes en un sistema portátil. La instalación en portátiles puede, sin embargo, acarrear problemas que no encontraríamos en sistemas de escritorio y cuyas soluciones no podemos encontrar por doquier a lo largo y ancho de Internet; los equipos portátiles suelen estar diseñados para Microsoft Windows, aún con más frecuencia que en sistemas de escritorio. Éste artículo tratará de aclarar alguno de estos problemas. Hay quien ha documentado sus experiencias con &os; en modelos concretos de portátiles y las ha incluído en páginas web que no forman parte de la documentación oficial de &os;. Es muy posible que encuentre información si introduce la marca y modelo de su portátil y la palabra &os; en un buscador. XFree86 Las versiones recientes de XFree86 funcionarán con la mayoría de tarjetas gráficas disponibles actualmente en portátiles. La aceleración gráfica tal vez no esté soportada pero una configuración SVGA genérica debería funcionar. Consulte la documentación de su portátil. Ahí deberí encontrar todos los detalles de su tarjeta, tras lo cual debería recurrir a la documentación de XFree86 (o el programa de configuración) para saber si está soportada o no. Si no lo está utilice un dispositivo genérico pero NO use uno cuyo nombre simplemente le resulte parecido. En la versión 4 de XFree86 puede probar suerte tecleando XFree86 -configure, que ejecuta un proceso de autodetección y le puede facilitar una gran cantidad de información muy útil. Con frecuencia el problema es la configuración del monitor. La información sobre XFree86 se centra en monitores CRT, por lo que disponer de una configuración para una pantalla LCD puede ser peliagudo. Quizás esté de suerte y no tenga que especificar rangos de HorizSync y VertRefresh. Si esto no funciona la mejor opción es recurrir a la web en busca de páginas dedicadas a la configuración de X en portátiles; suelen estar orientadas a Linux pero no importa dado que ambos sistemas operativos usan XFree86, por lo que puede usar la configuración que alguien haya usado sobre un hardware similar. La mayoría de portátiles incluyen dos botones para las funciones de botón primario y secundario del ratón (mouse), lo que puede resultar problemático en X ya que el botón central se usa para pegar texto; puede mapear una pulsación simultánea de ambos botones en la configuración de X que realice la función del botón central con la línea Option "Emulate3Buttons" en el fichero XF86Config en la sección InputDevice de XFree86 versión 4; para la versión 3 simplemente añada la línea Emulate3Buttons, sin comillas, en la sección Pointer . Modems Los equipos portátiles suelen incluír modems internos. Desgraciadamente eso casi siempre significa que son winmodems cuyo funcionamiento depende de software y para los cuales sólo hay disponibles controladores para windows. A pesar de ello están empezando a aparecer controladores para otros sistemas operativos; por ejemplo, si su modem tiene un chipset Lucent LT es muy posible que esté soportado por el port comms/ltmdm. Si ese no es su caso tendrá que buscar un modem externo: la solución más compacta probablemente sea un modem PC Card (PCMCIA), de los que hablaremos más adelante, pero los modem serie o USB serán seguramente más baratos. Normalmente los modems normales (es decir, los que no son winmodems), deberían funcionar sin problemas. Dispositivos PCMCIA (PC Card) Muchos portátiles incluyen bahías PCMCIA, también conocidas como PC Card, que suelen estar soportadas perfectamente por FreeBSD. Consulte el mensaje de arranque de su sistema (mediante &man.dmesg.8;) para saber si fueron detectadas correctamente; deberían figurar como pccard0, pccard1 etc. en dispositivos como pcic0). &os; 4.X soporta tarjetas PCMCIA de 16 bits y &os; 5.X soporta tanto éstas tarjetas de 16 bits como tarjetas de 32 bits CardBus. Hay una lista de tarjetas soportadas en el fichero /etc/defaults/pccard.conf. Léalo cuidadosamente y siempre que sea posible compre tarjetas que aparezcan en ese fichero. Las que no aparecen es posible que funcionen como dispositivos genéricos; en concreto la mayoría de los modem de 16 bits deberían funcionar correctamente siempre y cuando no sean winmodems (existen también como PC Cards, así que tenga cuidado). Si su sistema reconoce su tarjeta como un modem genérico tenga en cuenta que el fichero pccard.conf especifica por defecto un retardo de 10 segundos para evitar bloqueos en algunos modelos; eso puede ser una precaución excesiva para su modem así que es posible que quiera cambiar ese valor, reducirlo o incluso eliminarlo. Algunas partes de pccard.conf pueden necesitar un poco de edición. Busque la línea donde figura la irq y asegúrese de eliminar cualquier número que esté en uso; si tiene una tarjeta de sonido integrada borre irq 5, si no puede sufrir bloqueos del sistema al insertar la tarjeta. Consulte también la memoria disponible para las bahías; si su tarjeta sigue sin ser detectada pruebe a cambiar alguno de los valores posibles que aparecen en la página man de &man.pccardc.8;. Si aún no funciona puede lanzar el daemon &man.pccardd.8;. Para activarlo en el arranque añada pccard_enable="YES" en el fichero /etc/rc.conf. Tras ese paso sus tarjetas deberían ser detectadas cuando las inserte y cuando las extraiga; deberían asímismo aparecer entradas en ficheros log reflejando el momento en el que los nuevos dispositivos son activados. Ha habido cambios de gran calado en el código de pccard, como la inclusión de enrutado de interrupciones ISA, muy útil en máquinas en las que hasta la irrupción de FreeBSD 4.4 no era posible usar la BIOS PCI. Si tiene problemas con esto pruebe a actualizar su sistema. Administración de energía Desgraciadamente no existe un soporte demasiado bueno en FreeBSD. Si tiene suerte algunas características pueden ser funcionales mientras que otras no lo serán en absoluto. Para complicar un poco más las cosas hay dos estándares de administración de energía, APM y ACPI. El segundo se hizo para sustituír el primero e incluye nuevas características pero también más problemas. Algunos portátiles soportan tanto APM como ACPI (hasta cierto punto) mientras que otros sólo soportan uno de ellos así que no tendrá más remedio que experimentar con ambos para saber si dispone de administración de energía y hasta qué punto. No puede tener APM y ACPI activados simultáneamente, aunque su portátil soporte ambos. APM Una BIOS con APM (Advanced Power Management, Administración Avanzada de Energía) provée de soporte para diversas características de administración de energía tales como standby, suspensión, hibernación, reducción de la velocidad del reloj de la CPU, etc. y existe tanto en &os; 4.X como en &os; 5.X. Para activar el soporte de APM deberá compilar su kernel: añada device apm0 en &os; 4.X y device apm en &os; 5.X. El soporte APM como módulo existe en &os; 5.X; para cargarlo en el arranque añada la línea apm_load="YES" al fichero /boot/loader.conf. En &os; 5.X tendrá que asignar hint.apm.0.disabled="0" en el fichero /boot/device.hints. APM puede activarse en el arranque añadiendo apm_enable="YES" en el fichero /etc/rc.conf. El daemon &man.apmd.8; se puede lanzar añadiendo apmd_enable="YES" al fichero /etc/rc.conf, que se encarga de transmitir ciertos eventos a la BIOS, de manera que sea posible suspender/reanudar presionando alguna tecla concreta o al abrir y al cerrar la pantalla. Los comandos APM figuran en la página man de &man.apm.8;. Por ejemplo apm -b suministra el estado de la batería (o 255 si no está soportado), apm -Z pone el portátil en standby, apm -z (o zzz) lo suspende. Para apagar el sistema use shutdown -p. Le recordamos una vez más que alguna o incluso todas éstas funciones pueden no funcionar del todo bien o incluso no hacerlo en absoluto. Es posible que la suspensión o el modo standby funcione en consola pero no en X (esto es, la pantalla no se recupera). Si usa &os; 5.X una posible solución es añadir options SC_NO_SUSPEND_VTYSWITCH al fichero de configuración de su kernel y que lo recompile. Otra forma de solucionarlo es cambiar a otra consola virtual (mediante CtrlAltF1 u otra tecla de función) y ejecutar &man.apm.8;. Si está usando &man.apmd.8; puede automatizar esto con &man.vidcontrol.1;: edite /etc/apmd.conf y cámbielo del siguiente modo: apm_event SUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "/etc/rc.suspend"; } apm_event USERSUSPENDREQ { exec "vidcontrol -s 1 < /dev/console"; exec "sync && sync && sync"; exec "sleep 1"; exec "apm -z"; } apm_event NORMRESUME, STANDBYRESUME { exec "/etc/rc.resume"; exec "vidcontrol -s 9 < /dev/console"; } ACPI ACPI (Advanced Configuration and Power Management Interface, Interfaz para la Administración de Energía y Configuración Avanzada) facilita no solo la administración de energía sino también la detección de hardware (sustituyendo la detección PnP y PCI). ACPI sólo está disponible en &os; 5.X y está activado por defecto, así que no tiene que hacer nada especial para que funcione. Puede controlar el comportamiento de ACPI con &man.acpiconf.8;. Desgraciadamente los fabricantes ponen a la venta sus portátiles con implementaciones ACPI defectuosas, haciendo que habilitar ACPI algunas veces genere más problemas que ventajas, hasta el punto de no poder siquiera arrancar &os; en algunas máquinas con ACPI habilitado. Si ACPI le está causando problemas debería comprobar si el fabricante de su portátil ha liberado una nueva versión de la BIOS que solucione alguno de esos problemas. Dado que la implementación de ACPI en &os; está en constante evolución debería también actualizar su sistema; tal vez así sus problemas se solucionen. Si desea deshabilitar ACPI añada hint.acpi.0.disabled="1" al fichero /boot/device.hints. ACPI puede deshabilitarse temporalmente en el prompt del arranque tecleando unset acpi_load en caso de tener problemas para arrancar una máquina con ACPI habilitado. &os; 5.1-RELEASE y posteriores disponen de un menú en el arranque que controla cómo &os; arranca. Una de las opciones que se suministran es la de dehabilitar ACPI. Para hacerlo simplemente seleccione 2. Boot &os; with ACPI disabled (Arrancar &os; con ACPI deshabilitado) en el menú. Administración de Energía de la Pantalla El sistema X window (XFree86) incluye administración de energía de la pantalla (consulte la página man de &man.xset.1; y busque en ella dpms). Tendrá que investigar. Sin embargo tenga en cuenta que también esto funciona de manera muy poco fiable en portátiles: con frecuencia apaga la pantalla pero no apaga la retroiluminación.
diff --git a/es_ES.ISO8859-1/articles/problem-reports/article.sgml b/es_ES.ISO8859-1/articles/problem-reports/article.sgml index 8bb4113dfd..bc26bc6325 100644 --- a/es_ES.ISO8859-1/articles/problem-reports/article.sgml +++ b/es_ES.ISO8859-1/articles/problem-reports/article.sgml @@ -1,1026 +1,1028 @@ %man; %freebsd; %newsgroups; %authors; %mailing-lists; %translators; %trademarks; ]>
Cómo enviar informes de problemas de &os; $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.general; Este artículo describe cómo realizar y enviar informes de errores para el proyecto &os; de la mejor forma posible. &trans.es.jrh; Dag-Erling Smørgrav Escrito por problem reports
Introducción Una de las experiencias más fustrantes que se pueden experimentar como usuario de software es aquella en la cual el usuario se toma la molestia de rellenar un informe de problemas detallado para observar tras un determinado espacio de tiempo que dicho informe se cierra con una explicación corta y abrupta como no es un error o PR erroneo. De forma semejante, una de las experiencias más fustrantes que puede experimentar un desarrollador de aplicaciones consiste en verse inundado por una cantidad ingente de informes de errores - que en realidad vienen a ser solicitudes donde se requiere + que en realidad vienen a ser solicitudes de soporte o ayuda, o que contienen poca o ninguna información sobre cúal es el problema y como se puede reproducir. Este documento intenta describir cómo escribir informes de problemas de calidad. Usted se preguntará cómo se pueden escribir informes de problemas de calidad. Bien, para ir directos al grano, un informe de problemas de calidad es aquél - que se puede analizar y tratar rápidamente, para mutua + que se puede analizar y tratar rápidamente, para mútua satisfacción del usuario y del desarrollador. Aunque el objetivo principal de este artículo se centra en - los informes de problemas, la mayoría de los conceptos se pueden - aplicar bastante bien en otros proyectos de software. + los informes de problemas de &os; la mayoría de los conceptos se + pueden aplicar bastante bien en otros proyectos de software. Dése cuenta de que este artículo se organiza de forma temática, no cronológicamente, de tal forma que se debe - leer el documento íntegro antes de proceder a enviar informes - de problemas. No debe tratarse como un tutorial del estilo paso + leer el documento íntegro antes de enviar informes + de problemas. No debe tratarse como un tutorial del estilo paso a paso.
- Cuando enviar informes de problemas + Cuándo enviar informes de problemas Existen varios tipos de problemas y no todos ellos se merecen la creación de un informe de problemas. Por supuesto, - nadie es perfecto, y existirán ocasiones donde estaremos - convencidos de haber encontrado un bug en un programa cuando - realmente hemos malentendido la sintaxis o el funcionamiento de + nadie es perfecto, y existirán ocasiones en las que estaremos + convencidos de haber encontrado un bug en un programa + cuando realmente hemos malinterpretado la sintaxis o el funcionamiento de dicho programa, o simplemente hemos cometido un error - tipográfico en un archivo de configuración (aunque en este + tipográfico en un fichero de configuración (aunque en este último caso podría tratarse de un indicador de - documentación pobre o de manejo de errores inadecuado por parte - de la aplicación). 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 actuar, ya que dicho envío puede servir para - fustrar tanto al creador del informe como al desarrollador de - la aplicación. Por el contrario, también existen casos + documentación escasa o que la aplicación peca de una + gestión de errores defectuosa. Incluso + teniendo estos aspectos en cuenta existen varios casos en los cuales + el envío de un informe de problemas resulta claramente + no ser la mejor forma de proceder, ya que dicho + envío puede servir para frustrar tanto a quien envía el + informe como a quien desarrolló la aplicación. + Por el contrario, también existen casos en los que puede resultar apropiado enviar un informe de problemas sobre - algo más aparte de bugs; una mejora o una solucitud de - nueva característica, por citar un par de ejemplos. + algo más aparte de bugs: una mejora o una solucitud + nuevas características, por citar un par de ejemplos. Así que ¿cómo podemos determinar qué - constituye un bug y qué no? Como regla para principiantes - podemos decir que su problema no es un bug si + constituye un bug y qué no? Como regla para + principiantes podemos decir que su problema + no es un bug si se puede expresar como una pregunta (normalmente del estilo de ¿cómo hago X? o ¿donde puedo encontrar Y?). No siempre las cosas son blancas o negras, pero la regla de las preguntas suele cubrir una gran mayoría de casos. Si lo que se quiere es una respuesta a una consulta, se pueden enviar dichas preguntas a la &a.questions;. A continuación se muestran algunos casos en los que resulta apropiado enviar un informe de problemas sobre algo que no se - considera un bug: + considera un bug: Solucitudes para mejora de características. Normalmente es una buena idea airear estas propuestas en las listas de distribución antes de enviar un informe de problemas. Notificación de actualizaciones de software que se mantiene externamente (principalmente ports, pero también componentes del sistema base al cargo de proyectos independientes de &os;, como BIND o diversas utilidades GNU) - Otro tema es que si el sistema donde se experimentó el bug - no se encuentra medianamente actualizado, se debe considerar muy - seriamente su actualización e intentar reproducir el problema en - un sistema actualizado antes de emitir el informe de problemas. + Otro tema es que si el sistema donde se experimentó el + bug no está medianamente actualizado se debe + considerar muy seriamente su actualización e intentar reproducir + el problema en un sistema actualizado antes de emitir el informe. Existen pocas cosas que molesten más a un desarrollador que recibir un informe de problemas sobre un problema que ya ha resuelto. - Por último, un bug que no se puede reproducir - difícilmente puede arreglarse. Si el bug - sólo corrió una vez y no somos capaces de - reproducirlo, y parece que no le ocurre a nadie más, + Por último, un bug que no se puede + reproducir difícilmente puede arreglarse. Si el + bug sólo ocurrió una vez y no somos capaces + de reproducirlo, y parece que no le ocurre a nadie más, es muy probable que ni siquiera los desarrolladores puedan - reproducirlo y por lo tanto ni siquiera puedan imaginarse que es - lo que falla. Esto no significa que el bug no haya ocurrido, - sino que las probabilidades de que nuestro informe de errores + reproducirlo y por lo tanto ni siquiera puedan imaginarse qué es + lo que falla. Esto no significa que el bug no haya + ocurrido, sino que las probabilidades de que nuestro informe de errores sirva para corregir un defecto son muy pequeñas. Para complicar más las cosas, a menudo estas clases de errores se producen - debido a fallos en los discos duros o sobrecalentamiento del - procesador — usted debe siempre intentar descubrir estos + debido a fallos en los discos duros o al sobrecalentamiento del + procesador: debe intentar siempre descubrir estos fallos, siempre que sea posible, antes de enviar un PR.
Preparativos Una buena regla que se puede seguir consiste en realizar - siempre una búsqueda en segundo plano antes de enviar un informe + siempre una búsqueda antes de enviar un informe de problemas. Quizá nuestro problema ya ha sido reportado; quizá se está discutiendo en las listas de distribución o fue discutido hace poco; incluso es posible que se haya arreglado en versiones más recientes del software. Por lo tanto, se deben consultar los sitios y fuentes más obvias antes de proceder con el envío del informe de errores. - En &os;, esto significa: + En &os; esto significa: - El &os; + Las Preguntas Más - Frecuentes (FAQ). - La lista de FAQ intenta proporcionar respuestas para un - amplio rango de preguntas, tales como aquellas relacionadas + Frecuentes (FAQ) de &os;. + Las FAQ intentan proporcionar respuestas para un + amplio rango de dudas, tales como aquellas relacionadas con las compatibilidades hardware, las aplicaciones de usuario y la configuración del kernel. Las listas - de correo—si no está subscrito, utilice + de correo. Si no está subscrito utilice la búsqueda en los archivos del sitio web de &os;. Si el problema no se ha discutido con anterioridad en las listas, se puede intentar enviar un mensaje y esperar unos pocos días para ver si alguien puede aconsejarle adecuadamente sobre algún punto que quizá haya pasado por alto en relación con el problema. Opcionalmente, la web entera—utilice su motor de búsqueda favorito para localizar cualquier referencia a su problema. Incluso pueden aparecer listas de correo o grupos de noticias de los cuales ni siquiera tuviera conocimiento de su existencia o quizá no consideró apropiado consultarlas al principio. A continuación, la búsqueda a través de la base de datos &os; PR (GNATS). A menos que nuestro problema sea muy reciente o rebuscado, existe un gran número de posibilidades de que ya haya sido informado o reportado. Lo más importante, se debería intentar comprobar - si la documentaicón existente en el código fuente del + si la documentación existente en el código fuente del programa puede resolver el problema. En el caso de las fuentes del sistema &os; debe estudiarse cuidadosamente el contenido del fichero /usr/src/UPDATING del sistema o su última versión, que se encuentra en . (Esta información se considera de vital importancia si se está actualizando de una versión a otra, especialmente si la actualización se realiza de la versión estable a la versión &os.current;). No obstante, si el problema se encuentra en algo que se instaló como parte de la collección de ports de &os;, se debe consultar el archivo /usr/ports/UPDATING (para ports individuales) o el archivo /usr/ports/CHANGES (para cambios que afectan a la colección de ports completa). y también se encuentran disponibles a través de CVSweb. A continuación debemos asegurarnos de que el informe de errores llega a las personas adecuadas. La primera consideración llegados a este punto consiste en: Si el problema resulta ser un bug en un software de terceras partes (un port o un paquete que se ha instalado) se debe informar sobre el bug al autor original del software, no al proyecto &os;. Existen dos excepciones a esta regla: la primera ocurre cuando el bug no se produce en otras plataformas, en cuyo caso el problema puede residir en cómo fue migrado el software a &os;; la segunda excepción ocurre cuando el autor original ya ha corregido el problema y distribuido un parche o una nueva versión de su software, pero el port de &os; todavía no se ha actualizado. La segunda consideración es que el sistema de seguimiento de bugs de &os; ordena los informes de problemas de acuerdo con la categoría que ha seleccionado el informador. De este modo, si se selecciona una categoría incorrecta cuando se envía el informe de problemas, existe una gran probabilidad de que nadie se de cuenta de su existencia durante un período de tiempo indefinido, hasta que alguien se encarge de re-categorizarlo.
Escribir el informe de problemas Ahora que hemos determinado que el problema que estamos experimentando se merece la redacción de un informe de problemas y que se trata de un problema de &os;, es la hora de comenzar a escribir dicho informe. Antes de pasar a describir los mecanismos utilizados por el programa encargado de generar los informes PR, vamos a describir una serie de trucos y consejos que nos asegurarán la mayor efectividad posible de nuestro informe.
Consejos y trucos para escribir un buen informe de problemas No deje la línea de Synopsis vacía. Los PRs se dirigen tanto a una lista de correo mundial (donde se utiliza el campo Synopsis para rellenar la línea Subject: del correo) como a una base de datos (GNATS). Cualquier persona que consulte la base de datos por el campo sinopsis y encuentre un PR con una línea de Asunto vacía tiende simplemente a pasar por alto el informe. Recuerde que un PR permanece en la base de datos hasta que alguien se encarga de cerrar el informe; un informe anónimo normalmente se perderá para siempre entre el ruido y tardará mucho en cerrarse. Evite utilizar una línea de Synopsis débil.. No debe suponerse que quien lea el PR conoce el contexto adecuado en el que su mensaje tiene sentido, así que cuanta más información se proporcione, mejor que mejor. Por ejemplo, ¿qué parte del sistema se ve afectado por el informe?, ¿el problema aparece cuando se está instalando o cuando se está ejecutando?. Para ejemplificar, en lugar de Synopsis: portupgrade is broken, se pueden ver las ventajas que proporciona una línea como la siguiente: Synopsis: port sysutils/portupgrade produce un coredump en -current. (En el caso concreto de los ports, resulta especialmente útil poseer tanto la categoría como el nombre del port en la línea Synopsis.) Si se dispone de un parche, dígalo. Un PR con un parche incluido tiene muchas más posibilidades de ser tratado que uno que no lo tiene. Si se include dicho parche, escriba la cadena [patch] al comienzo de la línea Synopsis. (Aunque no es obligatorio utilizar dicha cadena, se trata de un estándar de facto que se utiliza de forma mayoritaria.) Si es mantenedor del port, dígalo. Si se está manteniendo el código fuente de una aplicación (por ejemplo, de un port), se puede considerar la adición de la cadena [maintainer update] al comienzo de la línea de sinopsis, y además se debería asignar el campo Class del PR a la cadena maintainer-update. De esta forma cualquier committer que maneje el PR no tendrá que realizar comprobaciones. Sea concreto. Cuanta más información se proporcione sobre el problema que se tiene, más posiblidades de obtener una respuesta. Incluya la versión del &os; que se está ejecutando (existe un lugar donde escribir esta esta información, vea más abajo) y en qué arquitectura. Se debe incluir si se está ejecutando desde una release (e.g. desde un CDROM o descarga), o si es desde un sistema mantenido mediante &man.cvsup.1; (y, si esto último se cumple, con qué frecuencia se realiza la actualización). Si se está siguiendo la rama &os.current;, se trata de la primera pregunta que nos harán, debido a que los parches (sobre todo para problemas de alto nivel) tienden a aplicarse muy rápidamente, y se espera de los usuarios de &os.current; un seguimiento cercano de las actualizaciones aplicadas. Incluya qué opciones globales se han especificado en el archivo make.conf. Aviso: Es bien conocido por todos que especificar -O2 y valores superiores para &man.gcc.1; produce fallos y resulta ser proclive a errores en muchas situaciones. Aunque los desarrolladores de &os; normalmente dan por buenos y aceptan los parches proporcionados por el creador del informe de problemas, normalmente no desean investigar dichas condiciones extrañas debido simplemente a la falta de tiempo y de voluntarios, y puede que respondan diciendo simplemente que dicha opción de compilación no se encuentra soportada. Si se trata de un problema del kernel, prepárese para proporcionar la siguiente información. (No es necesario incluir esta información por defecto, puesto que lo único que produce es un crecimiento desmesurado de la base de datos GNATS, pero sí puede merecer la pena incluir resúmenes que usted considere importantes): La configuración del kernel (incluyendo los dispositivos hardware que se tienen instalados) Si se tienen opciones de depuración activadas (tales como WITNESS), y en tal caso, si el problema persiste cuando se cambia el valor de dichas opciones Una traza de depuración, si se pudo generar. El hecho de que se ha leido detenidamente el archivo src/UPDATING para constatar que el problema no se ha identificado allí (se garantiza que alguién le preguntará sobre este punto) Si se puede o no se puede ejecutar otro kernel sin problemas (se trata de identificar problemas relacionados con el hardware como discos con errores o CPUs sobrecalentadas, que pueden confundirse fácilmente con problemas del kernel) Si se trata de un problema relacionado con los ports, prepárese para poder proporcionar la información que se muestra a continuación. (No es necesario incluir esta información por defecto, ya que sólo produce un crecimiento indeseado de la base de datos, pero sí se pueden incluir resúmenes de aquellos datos que usted considere relevantes): Los ports que se tiene instalados Cualesquiera variables de entorno que sobreescriban los valores por defecto del archivo bsd.port.mk, tales como PORTSDIR El hecho de que se ha leido ports/UPDATING y que nuestro problema no se encuentra identificado en dicho archivo (se garantiza que alguien puede preguntar este hecho). Evitar peticiones de características vagas. Los PRs del estilo de alguien debería implementar algo que haga esto y aquello y lo de más allá son informes con pocas probabilidades de obtener resultados positivos. Las características deben ser muy concretas y específicas. Recuerde que el código fuente se encuentra disponible para todo el mundo, de tal forma que si usted necesita una característica, la mejor forma de verla incluida en futuras versiones de la herramienta consiste en ponerse usted mismo a trabajar sobre ella, manos a la obra. También tenga en cuenta que para discutir este tipo de problemas resulta más adecuado utilizar la lista freebsd-questions, como ya se ha comentado anteriormente. Asegúrese que nadie más ha enviado un PR similar. Aunque esto ya se ha mencionado anteriormente, merece la pena que se repita en este punto. Sólamente lleva uno o dos minutos realizar una búsqueda basada en un motor web en . (Por supuesto, a todo el mundo se le puede olvidar realizar esto de vez en cuando, pero por esa misma razón merece la pena hacer incapié en ello) Evite peticiones controvertidas. Si nuestro PR se dirige hacia un área o tema controvertido en el pasado, debemos prepararnos no sólo a ofrecer parches, si no también a justificar por qué motivo los parches proporcionados son la Forma Correcta de Hacerlo. Como se avisó anteriormente, una búsqueda meticulosa en las listas de correo en los archivos históricos sitos en resulta siempre una buena idea y sirve para preparar nuestro razonamiento y aprender de la experiencia y de las decisiones tomadas en el pasado. Sea educado. Casi cualquier persona que se encarge de tratar nuestro informe de problemas trabajará en el como un voluntario. A nadie le gusta que le digan cómo hacer las cosas cuando ya se están haciendo de una forma determinada, especialmente cuando la motivación para realizarlas no es monetaria. Este hecho es bueno tenerlo en mente y aplicarlo para cualquier proyecto de Software Libre.
Antes de comenzar. Antes de ejecutar el programa &man.send-pr.1;, asegúrese de que la variable de entorno VISUAL (o EDITOR si la variable VISUAL no se encuentra definida) se encuentra apuntando a algo con sentido. Es importante comprobar que la entrega de correo funciona correctamente. &man.send-pr.1; utiliza mensajes de correo para enviar y realizar un seguimiento de los informes de problemas. Si no se puede generar correo electrónico desde la máquina en la que se ejecuta &man.send-pr.1;, el informe jamás llegará a la base de datos GNATS. Si quiere saber más sobre la configuración del correo en &os; consulte el capítulo de Correo Electrónico del manual de &os; en .
Adjuntar parches o archivos El programa &man.send-pr.1; posee la capacidad de adjuntar archivos al informe de problemas. Se pueden adjuntar tantos archivos como se quiera siempre y cuando se utilice un nombre distinto para cada archivo (e.g. el nombre del archivo después de eliminar el path). Simplemente basta con utilizar la opción de línea de comandos para especificar los nombres de todos los archivos que se desean adjuntar: &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors No se preocupe por los archivos binarios, dichos archivos se codifican automáticamente para no interferir con el agente de correo. Si se adjunta un parche, asegúrese que se utiliza la opción o la opción de &man.diff.1; para crear un contexto unificado (el contexto suele ser el preferido por quienes lo han de recibir) y además asegúrese de especificar los números de revisión de CVS de los archivos que se modifican para que los desarrolladores que lean el informe puedan aplicar dichos parches fácilmente. Para problemas relacionados con el kernel o con las utilidades del sistema base, se prefiere un parche contra &os.current; (la rama HEAD del árbol CVS) ya que cualquier código nuevo debe probar se primeramente en dicha rama. Después de comprobar su correcto funcionamiento de una forma sustancial y extensa, eventualmente dicho código pasará a formar parte de &os.stable;, mediante unión o migración. Si se envía un parte en línea, en vez de como adjunto, tenga en cuenta que el principal problema de esta forma de enviar los parches es que, dependiendo del lector de correo utilizado, algunos lectores muestran los tabuladores como espacios, lo cual arruina completamente el formato y la indentación del parche, e invalida totalmente un parche que forme parte de un Makefile. También tenga en cuenta que mientras que la inclusión de parches en un PR se considera como algo positivo—particularmente cuando se soluciona el problema que describe el informe—partes grandes y especialmente código nuevo que puede requerir una sustancial revisión antes de ser aplicado debería hacerse accesible a través de otros medios, como páginas web o servidores de ftp, y en vez de incluir el parche en el informe se puede incluir la URL. Los parches de gran tamaño en los correos electrónicos tienden a mezclarse o partirse, especialmente cuando GNATS los trata, y cuanto más grande es el parche más difícil resulta recuperar el original. También existe una ventaja añadida a la inclusión del parche a través de una URL, ya que de este modo se puede modificar el parche sin tener que reenviar el informe como una respuesta al informe inicial. Se debe prestar atención también al hecho de que, a menos que se especifique explícitamente lo contrario en el PR o en el propio parche, cualquier parche enviado se supone licenciado bajo los mismos términos y condiciones que el archivo original que modifica.
Rellenar la plantilla Cuando se ejecuta &man.send-pr.1; se nos presenta en pantalla una plantilla. Esta plantilla consiste en una lista de campos, algunos de los cuales se encuentran ya rellenados, mientras que otros poseen comentarios donde se explica su propósito o se comentan los valores aceptables. No se preocupe por los comentarios, puesto que se borran automáticamente antes de generar el informe. Al comienzo de la plantilla, justo debajo de las líneas de SEND-PR:, se encuentran las cabeceras de correo electrónico. Dichas cabeceras normalmente no se tienen que modificar, a menos que se esté rellenando el informe desde una máquina que puede enviar correo pero no puede recibirlo directamente, en cuyo caso usted tendrá que editar los campos From: y Reply-To: para escribir la dirección de correo válida. También puede enviarse una copia a usted mismo o a cualquier otra persona rellenando el campo Cc:. A continuación aparecen una serie de campos de una sola línea: Submitter-Id: No cambie este campo. El valor por defecto current-users es correcto, incluso si se está ejecutando &os.stable;. Originator: Se rellena automáticamente con el campo gecos del usuario que está actualmente dentro del sistema. Por favor, especifique su nombre real, opcionalmente acompañado por su dirección de correo electrónico entre < >. Organization: Escriba lo que usted quiera. Este campo no se utiliza para nada significativo. Confidential: Esto se rellena automáticamente con el literal no. Cambiar este valor carece de sentido ya que no existe ningún informe de problemas de &os; confidencial—la base de datos de PR se distribuye a todo el mundo de forma pública mediante CVSup. Synopsis: Rellene este campo con una descripción corta y precisa del problema. La sinopsis se utiliza como subject del correo electrónico del informe de problemas, y también se utiliza en los listados y resúmenes de informes de la base de datos; informes de problemas con obscuras sinopsis tienden a ser completamente ignorados. Como se avisó anteriormente, si su informe de problemas incluye un parche, por favor incluya en la sinopsis la etiqueta [patch] al comienzo; si usted es un mantenedor de software, también puede añadir la cadena [maintainer update] y asignar el campo Class del informe al valor maintainer-update. Severity: Los valores aceptados son non-critical, serious o critical. No sea exagerado; evite etiquetar el problema como critital a menos que sea realmente algo crítico (e.g. escalada de permisos hacia root, kernel panic fácilmente reproducible). Incluso debe pensarse detenidamente etiquetar algo como serious a menos que se trate de algo que afecte a muchos usuarios (problemas con drivers de dispositivos particulares o con utilidades del sistema). Los desarrolladores de &os; no van a resolver el problema más rápido por el hecho de variar esta etiqueta, debido a que existe mucha gente que infla este campo inadecuadamente. De hecho, los desarrolladores prestan muy poca atención al valor de este campo y del siguiente precisamente por esto último. Priority: Los valores aceptados son low, medium o high. high debe reservarse para problemas que afecten a la mayoría de los usuarios de &os; y medium para aquellos problemas que afecten a varios usuarios. Category: Seleccione uno de los siguientes valores (extraídos de /usr/gnats/gnats-adm/categories): advocacy: para problemas relacionados con la imagen pública de &os;. Raras veces utilizado. alpha: para problemas específicos de la plataforma Alpha. amd64: para problemas específicos de la plataforma AMD64. bin: para problemas con aplicaciones de la zona de usuario del sistema base. conf: para problemas de archivos de configuración, valores por defecto, etc. docs: para problemas con las páginas de manual o la documentación online. gnu: para problemas realacionados con aplicaciones gnu de &os; tales como &man.gcc.1; o &man.grep.1;. i386: para problemas específicos de la plataforma &i386;. ia64: para problemas específicos de la plataforma ia64. java: para problemas relacionados con &java;. kern: para problemas relacionados con el kernel o con (no especifícos de ninguna plataforma) controladores de dispositivos. misc: para cualquier cosa que no encaja en ninguna de las anteriores categorías. (Tenga en cuenta que es muy fácil que los problemas bajo esta categoría se pierdan en el olvido). ports: para problemas relacionados con el árbol de ports. powerpc: para problemas específicos de la plataforma &powerpc;. sparc64: para problemas específicos de la plataforma &sparc64;. standards: para problemas relativos a la adecuación con estándares. threads: para problemas relacionados con la implementación de threads de &os; (especialmente en &os.current;). www: para cambios o mejoras del sitio web de &os;. Class: Se puede seleccionar uno entre los siguientes: sw-bug: bugs de software. doc-bug: errores en la documentación. change-request: peticiones de características adicionales o de cambios en las características existentes. update: actualizaciones de ports o de software contribuido por terceros. maintainer-update: actualizaciones de ports de los cuales usted es mantenedor. Release: La versión de &os; que se está ejecutando. El programa &man.send-pr.1; rellena automáticamente este campo, por lo que sólamente resulta necesaria su modificación cuando estemos rellenando un informe de problemas desde un sistema distinto al sistema donde se ha producido dicho problema. Por último, existen una serie de campos multilínea: Environment: Este campo debe describir, tan preciso como sea posible, el entorno en el cual se ha observado el problema. Esto incluye la versión del sistema operativo, la versión del programa que contiene el problema y cualquier otro asunto relevante tales como la configuración del sistema o cualquier otro software instalado que pueda influir en la ejecución del primero, etc. Resumiendo todo lo anterior, se debe especificar todo lo que un desarrollador necesita conocer para poder reconstruir el entorno en el cual se ha producido el problema. Description: Una descripción completa y precisa del problema que se está sufriendo. Intente evitar especular sobre las posibles causas del problema a menos que se tenga la seguridad de que el camino descrito es el correcto, puesto que puede inducir al desarrollador a realizar falsas presunciones. How-To-Repeat: Un resumen de las acciones que deben llevarse a cabo para reproducir el problema. Fix: Preferentemente un parche, o al menos una solución temporal (la cual no sólo ayuda a otras personas que experimenten el mismo problema, sino que puede ayudar también al desarrollador para que investigue sobre las verdaderas causas del problema). No obstante, si no se dispone de ninguna de estas opciones, lo mas sabio es dejar vacío este campo y sobre todo no hacer especulaciones.
Envío del informe de problemas Una vez que hemos terminado de rellenar la plantilla, hemos salvado y hemos salido del editor, &man.send-pr.1; nos dará a conocer las siguientes opciones: s)end, e)dit or a)bort?. Es en estos momentos cuando podemos teclear s para continuar y enviar el informe de problemas, e para relanzar el editor y realizar más modificaciones a la plantilla o a para abortar el programa. Si se selecciona esta última alternativa, el informe de problemas no será destruido, sino que permanecerá en disco (&man.send-pr.1; nos indicará el nombre del fichero antes de finalizar), de tal forma que se puede editar de forma individual (sin &man.send-pr.1;) en cualquier momento, o también se puede transferir a otro sistema con mejor conectividad para finalmente enviarlo utilizando la opción de línea de comandos de &man.send-pr.1;: &prompt.user; send-pr -f ~/my-problem-report Esto leerá el archivo especificado, validando sus contenidos, y eliminará los comentarios para finalmente enviarlo.
Follow-up Una vez enviado el informe de problemas, se recibe una - confirmación por correo eletrónico en la que se incluye el + confirmación por correo electrónico en la que se incluye el número asignado al informe y la URL que puede utilizarse para consultar su estado. Con un poquito de suerte, alguien mostrará interés en el problema y tratará de solucionarlo, o de explicar por qué razón no se considera un problema, - cómo ha ocurrido en muchas ocasiones. Recibiremos + como ha ocurrido en muchas ocasiones. Recibiremos automáticamente una notificación relativa a cualquier cambio de estado, además de recibir copias de cualquier comentario o de los parches que se generen relacionados con nuestro informe. Si alguien solicita información adicional sobre el problema, o de repente descubre o recuerda algo que no tuvo ocasión de mencionar en el informe inicial, puede utilizar una de las siguientes opciones para enviar una continuación (followup) a dicho informe: La forma más sencilla consiste en utilizar el enlace followup que aparece en la página web asociada a nuestro informe de problemas, la cual se puede alcanzar a partir de la página de búsquedas de PRs en . Al pinchar en dicho enlace se mostrará una pantalla con las líneas de To: y Subject correctamente rellenadas (siempre y cuando el navegador soporte esta característica de autorelleno). Alternativamente, se puede enviar un correo eletrónico directamente a bug-followup@FreeBSD.org, asegurando que el número de seguimiento se incluye en el asunto para que el sistema de seguimiento de informes pueda adjuntar la respuesta al informe apropiado. Si no se incluye el número de seguimiento, GNATS no reconocerá el informe inicial y creará un PR totalmente nuevo, que quedará asignado al administrador de GNATS, de tal forma que el followup quedará en el vacío hasta que alguien resuelva el entuerto, lo cual puede tardar dias o semanas. Forma incorrecta:Subject: ese PR que envié en su día Forma correcta:Subject: Re: ports/12345: problema de compilación en foo/bar Si el informe de problemas permanece abierto una vez que dicho problema ha desaparecido, simplemente envíe un followup (de la forma descrita anteriormente) diciendo que el informe de problemas se puede cerrar y, a ser posible, también conviene explicar la forma en que el problema se resolvió.
Lecturas recomendadas A continuación se muestra una lista de recursos relacionados con la escritura adecuada de informes y con el procesamiento de dichos informes. No pretende ser una completa enumeración. How row to Report Bugs Effectively—un excelente ensayo por Simon G. Tatham sobre la redacción de informes de problemas (el texto no es específico sobre &os;) Problem Report Handling Guidelines—resumen de valor sobre cómo los desarrolladores de &os; manejan y gestionan los informes de problemas.
diff --git a/es_ES.ISO8859-1/articles/zip-drive/article.sgml b/es_ES.ISO8859-1/articles/zip-drive/article.sgml index 97c2416541..648b2693ae 100644 --- a/es_ES.ISO8859-1/articles/zip-drive/article.sgml +++ b/es_ES.ISO8859-1/articles/zip-drive/article.sgml @@ -1,321 +1,327 @@ %man; %freebsd; + +%translators; + ]>
Unidades ZIP Jason Bacon
acadix@execpc.com
 + + &trans.es.bazcar; + Introducción a las Unidades ZIP Los discos ZIP son dispositivos magnéticos, extraíbles y de alta capacidad que pueden leerse y escribirse mediante unidades ZIP de IOMEGA. Los discos ZIP son similares a los disquetes (floppy) pero son mucho más rápidos y ofrecen una capacidad de almacenamiento mucho mayor. Así como los disquetes suelen ser de 1'44 MB los discos ZIP existen en dos tamaños, de 100 y 250 MB. Los discos ZIP no deben ser confundidos con el formato super-floppy, un dispositivo que usa disquetes de 120 MB pero que admite los discos tradicionales de 1'44 MB. IOMEGA distribuye asímismo unidades de rendimiento más alto y mucha mayor capacidad llamadas JAZZ. Las unidades JAZZ usan discos de 1 y 2 GB. Las unidades ZIP están disponibles como dispositivos internos y externos y emplean una de los siguientes interfaces: El interfaz SCSI es el más rápido, sofisticado, expandible y caro. El interfaz SCSI se usa en todo tipo de plataformas, desde PC y estaciones RISC a miniordenadores para conectar todo tipo de periféricos como discos duros, unidades de cinta, scanners, etc. Los dispositivos ZIP SCSI pueden ser internos o externos, que requieren que la controladora SCSI disponga de un conector externo. Si usa una unidad SCSI externa es importante que nunca la conecte o desconecte del bus SCSI mientras el ordenador está funcionando. Si lo hace puede causar daños en el sistema de ficheros del resto de los discos del sistema. Si lo que busca es el máximo rendimiento y una sencilla configuración el interfaz SCSI es la mejor elección. Probablemente tendrá que añadir una controladora SCSI dado que la mayoría de los PC (salvo los servidores de alto rendimiento) no ofrecen soporte SCSI integrado. Cada controladora SCSI puede admitir entre 7 y 15 dispositivos SCSI dependiendo del modelo. Cada unidad SCSI tiene su propio controlador y esos controladores son razonablemente inteligentes y están bien estandarizados (la segunda S de SCSI viene de Standard), de manera que desde el punto de vista del sistema operativo, todos los dispositivos SCSI parecen ser el mismo, como sucede con las unidades de cinta SCSI, etc. Para poder utilizar dispositivos SCSI el sistema operativo necesita únicamente un driver específico para la controladora que se desea usar y un driver genérico para cada tipo de dispositivo, ésto es, un disco SCSI, una unidad de cinta SCSI, etc. Algunos dispositivos SCSI pueden ser mejor aprovechados mediante drivers especializados (v.g. unidades de cinta DAT) pero tienden a funcionar perfectamente con los drivers genéricos, que sencillamente puede que no incluyan alguna de las características especiales. El usar una unidad ZIP SCSI es algo tan simple como determinar cuál es el fichero de dispositivo en el directorio /dev que representa la unidad ZIP. Esto puede saberse examinando el mensaje de arranque de FreeBSD (o en /var/log/messages tras el arranque), donde debería encontrar algo parecido a: da1: <IOMEGA ZIP 100 D.13> Removable Direct Access SCSI-2 Device Esto significa que la unidad ZIP está representada por el fichero /dev/da1. El interfaz IDE es un interfaz de acceso a discos duros de bajo coste que se usa en la mayoría de los PC de escritorio. La mayoría de los dispositivos IDE son exclusivamente internos. El rendimiento de los dispositivos ZIP IDE es comparable al de los ZIP SCSI. (El interfaz IDE no es tan rápido como el SCSI pero el rendimiento de los dispositivos ZIP está condicionado principalmente por la parte mecánica del dispositivo, no por el interfaz del bus). El inconveniente del interfaz IDE son las limitaciones que conlleva. La mayoría de adaptadores IDE sólo permiten utilizar dos dispositivos y generalmente los interfaces IDE no están diseñados para perpetuarse en el tiempo. Por ejemplo, el interfaz IDE original no admite discos duros con más de 1.024 cilindros, lo que obligó a mucha gente a actualizar su hardware antes de lo esperado. Si prevé añadir nuevo hardware a su PC (otro disco duro, una unidad de cinta, un scanner, etc.) no estaría de más que considerara la idea de adquirir una controladora y un ZIP SCSI para evitar problemas en el futuro. En FreeBSD los dispositivos IDE llevan el prefijo a. Por ejemplo, un disco duro IDE podría ser /dev/ad0, y un CDROM IDE (ATAPI) podría ser /dev/acd1, y así sucesivamente. El interfaz de puerto paralelo es muy común en dispositivos externos portátiles como dispositivos ZIP externos y scanners debido a que virtualmente todos los ordenadores disponen de un puerto paralelo estándar (que generalmente se usa con impresoras). De éste modo se le facilitan las cosas a mucha gente a la hora de transferir datos entre distintos equipos. Generalmente el rendimiento es menor que el de dispositivos ZIP IDE o SCSI dadas las limitaciones de velocidad del puerto paralelo. Ésta puede variar según el caso concreto y con frecuencia puede configurarse en la BIOS del sistema. En algunos casos es imprescindible configurar en la BIOS el puerto paralelo para que admita el modo bidireccional puesto que los puertos paralelos fueron originalmente concebidos para verter su salida hacia las impresoras. ZIP de Puerto Paralelo: El <quote>driver</quote> <devicename>vpo </devicename> Para usar en FreeBSD un dispositivo ZIP de puerto paralelo debe incluírse en el kernel el driver vpo . Los dispositivos ZIP de puerto paralelo disponen de un controlador SCSI integrado. El driver vpo permite al kernel de FreeBSD comunicarse con el controlador SCSI del dispositivo ZIP a través del puerto paralelo. Dado que el driver vpo no forma parte del kernel GENERIC (el kernel que se instala con FreeBSD) a partir de FreeBSD 3.2 necesita recompilar su kernel para activar éste dispositivo. Una de las maneras de recompilar el kernel se detalla más adelante en éste mismo texto. Los pasos a seguir para activar el driver vpo podrían ser los siguientes: Ejecute /stand/sysinstall e instale los fuentes del kernel en su sistema. Crearemos un fichero de configuración del kernel que incluya el driver vpo: &prompt.root; cd /sys/i386/conf &prompt.root; cp GENERIC MIKERNEL Editamos MIKERNEL para sustituír la entrada ident por MIKERNEL y descomentamos la línea en la que aparece el driver vpo. Si dispone de un segundo puerto paralelo deberá copiar la sección ppc0 para crear el dispositivo ppc1. El segundo puerto paralelo suele usar la IRQ 5 y la dirección 378. Solamente es imprescindible asignar la IRQ en el fichero de configuración. Si su disco duro principal es SCSI puede tener problemas durante la prueba de dispositivos SCSI que FreeBSD efectúa en el arranque, dado que el sistema puede intentar utilizar el dispositivo ZIP como disco de inicio. Esto produciría un fallo en el arranque salvo, claro está, que disponga de un sistema de ficheros raíz en su disco ZIP. Si ese es su caso debe forzar al kernel a enlazar un dispositivo concreto (en éste caso su disco duro raíz) con /dev/da0/. El kernel asignará al disco ZIP el siguiente nombre SCSI disponible, es decir, /dev/da1. Para fijar su disco duro SCSI como da0 cambie la línea device da0 a disk da0 at scbus0 target 0 unit 0 Quizás necesite modificar la línea anterior para que concuerde con los datos de su dispositivo SCSI. Del mismo modo tendría que asociar la entrada scbus0 con su controladora. Por ejemplo, si tiene una controladora Adaptec 15xx debería cambiar controller scbus0 por controller scbus0 at aha0 Para concluír, dado que está creando un kernel personalizado debería aprovechar la ocasión para eliminar todos los drivers que no necesita. Esto debe hacerse con precaución y solamente cuando tenga la seguridad de que sabe lo que está haciendo con su fichero de configuración. Si borra los drivers que no necesita reducirá el tamaño de su kernel y por lo tanto dispondrá de más memoria que ofrecer a sus aplicaciones. Para saber qué drivers puede borrar vaya al final del fichero /var/log/messages y busque líneas que incluyan not found (no encontrado). Comente las líneas de esos drivers en su fichero de configuración. Puede cambiar otras opciones más para reducir el tamaño e incrementar la velocidad de su kernel. Lea la sección del Handbook correspondiente a la recompilación del kernel para conocer todos los detalles. Ha llegado el momento de compilar nuestro kernel: &prompt.root; /usr/sbin/config MIKERNEL &prompt.root; cd ../../compile/MIKERNEL &prompt.root; make clean depend && make all install Una vez finalizado el proceso necesitará reiniciar. Asegúrese de que la unidad ZIP esté conectada al puerto paralelo antes del arranque. Verá aparecer el dispositivo ZIP en los mensajes del arranque como vpo0 o vpo1, dependiendo del puerto paralelo al que esté conectado. Debería aparecer también a qué nombre de dispositivo ha sido enlazado. Por ejemplo sería /dev/da0 si no hay en el sistema discos SCSI o /dev/da1 si tiene como dispositivo principal un disco SCSI. Cómo montar discos ZIP Para acceder a un disco ZIP simplemente hay que montarlo como cualquier otro dispositivo de disco. El sistema de ficheros estará representado como slice 4 dentro del dispositivo, tanto para discos SCSI o paralelos. Por ejemplo: &prompt.root; mount_msdos /dev/da1s4 /mnt Para unidades ZIP IDE, utilice: &prompt.root; mount_msdos /dev/ad1s4 /mnt Puede serle útil modificar /etc/fstab para montar los discos más fácilmente. Añada una línea como la siguiente (con las modificaciones necesarias para sus necesidades): /dev/da1s4 /zip msdos rw,noauto 0 0 y crée el directorio /zip. Hecho esto, puede montar su disco ZIP escribiendo: &prompt.root; mount /zip y para desmontarlo escriba &prompt.root; umount /zip Tiene todos los detalles del formato en el que incluír o modificar entradas en /etc/fstab en &man.fstab.5;. Si quiere puede crear un sistema de ficheros de FreeBSD en un disco ZIP empleando &man.newfs.8;. Sin embargo eso convertiría a ese disco en legible solamente en un sistema FreeBSD y y quizás en unos pocos sistemas clónicos de &unix; que reconocen el sistema de ficheros de FreeBSD. En cualquier caso DOS y Windows no están entre ellos.