path: root/es_ES.ISO8859-1/articles/fbsd-from-scratch/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
	"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
<!ENTITY scratch.ap "<application xmlns='http://docbook.org/ns/docbook'>FreeBSD From Scratch</application>">
]>
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="es">
  <info><title>FreeBSD From Scratch</title>
    

    <author><personname><firstname>Jens</firstname><surname>Schweikhardt</surname></personname><affiliation>
        <address><email>schweikh@FreeBSD.org</email></address>
      </affiliation></author>
    <copyright>
      <year>2002</year>
      <holder>Jens Schweikhardt</holder>
    </copyright>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>&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
        <quote>ports</quote> favoritos y configurado para coincidir con
        su idea del sistema perfecto.  Si cree que
        <command>make world</command> es un concepto fascinante
        &scratch.ap; lo amplía hasta ser
        <command>make evenmore</command>.  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, <command>make world</command>,
        que podría traducirse muy libremente como <quote>hacer, o más bien rehacer el
        mundo entero</quote> y <command>make evenmore</command>, osea, <quote>hacer más
        aún</quote>.  </para>
	&trans.es.carvay;
    </abstract>
  </info>

  <sect1 xml:id="introduction">
    <title>Introducción</title>

    <para>?Ha actualizado alguna vez su sistema mediante
      <command>make world</command>?.  Si solamente tiene un sistema
      en sus discos se encontrará con un problema.  Si
      <buildtarget>installworld</buildtarget> falla a la mitad
      su sistema quedará dañado e incluso
      puede ser incapaz de arrancar de nuevo.  O quizás
      <buildtarget>installworld</buildtarget> 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
       <quote>backups</quote> que hizo hace seis meses.</para>

    <para>Creo en el paradigma de <quote>al actualizar sistemas operativos
      instala desde cero</quote>.  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
      <quote>ports</quote> y <quote>packages</quote> 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.</para>
  </sect1>

  <sect1 xml:id="why">
    <title>?Por qué (no) debería interesarme
      &scratch.ap;?</title>

    <para>Esa es una pregunta muy razonable.  Tenemos
      <application>sysinstall</application>, una compilación
      del kernel que funciona sin sorpresas y tenemos también
      las herramientas de entorno de usuario.</para>

    <para>El problema que tiene <application>sysinstall</application>
      es que está extremadamente limitado cuando se trata de
      qué, dónde y cómo queremos que haga la
      instalación.</para>

    <itemizedlist>
      <listitem>
        <para>Normalmente se usa para instalar distribuciones precompiladas
          y <quote>packages</quote> desde diversas fuentes (CD, DVD,
          FTP).  No puede instalar el resultado de
          <literal>make buildworld</literal>.</para>
      </listitem>

      <listitem>
        <para>No puede instalar un segundo sistema en un directorio
          de un sistema en funcionamiento.</para>
      </listitem>

      <listitem>
        <para>No puede hacer una instalación en particiones
          <application>Vinum</application>.</para>
      </listitem>

      <listitem>
        <para>No puede compilar <quote>ports</quote>, sólo
          instala <quote>packages</quote> precompilados.</para>
      </listitem>

      <listitem>
        <para>Es difícil automatizar mediante
          <quote>scripts</quote> o incluso hacer de forma manual
          los cambios que considere
          necesarios después de la instalación</para>
      </listitem>

      <listitem>
        <para>Por si todo esto fuera poco
          <application>sysinstall</application>
          está semioficialmente al final de su
          <quote>Ciclo de Vida Útil</quote>.</para>
      </listitem>
    </itemizedlist>

    <para>El archiconocido proceso de <quote>construír/instalar
      el mundo</quote> (<quote>build/install world</quote>), explicado en
      <link xlink:href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html">el
      Handbook</link>, 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.</para>

    <para>&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
      <quote>chroot</quote>.  El proceso tiene tres fases,
      cada una de los cuales consiste en ejecutar un
      <quote>script de shell</quote> o invocar
      <command>make</command>:</para>

    <orderedlist>
      <listitem>
        <para><filename>fase_1.sh</filename>:
          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.</para>
      </listitem>

      <listitem>
        <para><filename>fase_2.sh</filename>:
          Instala los <quote>ports</quote> que hayamos elegido.</para>
      </listitem>

      <listitem>
        <para><filename>fase_3.mk</filename>:
          Remata la configuración del software instalado en la
          fase anterior.</para>
      </listitem>
    </orderedlist>

    <para>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.</para>

    <para>Puede que haya oído hablar o incluso haya usado ya
     <link xlink:href="http://www.linuxfromscratch.org/">Linux From Scratch</link>,
      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
      <command>make world</command>.  Si desea usted explorar &os; de
      modo tan profundo comience por leer
      <filename>/usr/src/Makefile</filename> y siga cuidadosamente lo
      que sucede al teclear
      <command>make buildworld</command>.</para>

    <para>Hay también algunos detalles delicados con los que
      me encontré durante el desarrollo de &scratch.ap; que
      debería tener muy en cuenta.</para>

      <!-- XXX: Sería una buena idea escribir el fase_2.sh usando un
           "jail" situada en el sistema nuevo instalado en la primera
           fase.  Si disponemos de una dirección de red bien configurada
           como IP primaria de esa "jail" podría ser posible incluso
           compilar "ports" en un "chroot" sin desinstalar nada del
           sistema anfitrión.  No obstante tenga en cuenta que incluso
           las "jail" están ejecutando el kernel anfitrión.-->

    <itemizedlist>
      <listitem>
        <para>El sistema no puede ser usado normalmente
          durante la compilación de los <quote>ports</quote>
          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
          <quote>ports</quote> compilados por
          <filename>fase_2.sh</filename> necesitan aproximadamente 4 horas
          para acabar en un sistema SCSI AMD1800+ con discos de 10.000 rpm
          y 1GB de RAM.</para>
      </listitem>
    </itemizedlist>

  </sect1>

  <sect1 xml:id="prerequisites">
    <title>Requisitos previos</title>

    <para>Para poder usar &scratch.ap;
      necesitará lo siguiente:</para>

    <itemizedlist>
      <listitem>
        <para>Un sistema &os; con el árbol de <quote>ports</quote> y
          los fuentes instalados.</para>
      </listitem>

      <listitem>
        <para>Al menos una partición vacía donde instalaremos
          el nuevo sistema.</para>
      </listitem>

      <listitem>
        <para>Experiencia en el uso de &man.mergemaster.8; o al menos no
          tener miedo de usarlo.</para>
      </listitem>

      <listitem>
        <para>Si su acceso a Internet es lento o si no dispone del mismo
          necesitará los <quote>distfiles</quote> de los ports que
          vaya a instalar.</para>
      </listitem>

      <listitem>
        <para>Conocimientos básicos de confección de
          <quote>scripts</quote> de shell con la shell Bourne,
          &man.sh.1;</para>
      </listitem>

      <listitem>
        <para>Finalmente, debería ser capaz de decirle a su
          <quote>boot loader</quote> (cargador de arranque) cómo arrancar el nuevo
          sistema, en modo interactivo o mediante un fichero de
          configuración.</para>
      </listitem>
    </itemizedlist>

  </sect1>

  <sect1 xml:id="stage1">
    <title>Primera Fase: Instalación del Sistema</title>

    <para>Lo que vamos a explicar más adelante es mi
      <filename>fase_1.sh</filename>.  Tendrá que modificarlo
      en varios sitios para que cuadre con su propia idea del
      <quote>sistema perfecto</quote>.  He intentado incluír
      todos los comentarios posibles en los sitios donde debería
      usted introducir sus cambios.  Los puntos a estudiar son:</para>

    <itemizedlist>
      <listitem>
        <para>Esquema de particiones.</para>

        <para>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
          <filename>/</filename>,
          <filename>/usr</filename> y
          <filename>/var</filename> con
          <filename>/tmp</filename> enlazado simbólicamente a
          <filename>/var/tmp</filename>.
          Además comparto los sistemas de ficheros en los que
          ubico
          <filename>/home</filename> (los directorios de los usuarios),
          <filename>/home/ncvs</filename> (réplica del repositorio
          de &os;,
          <filename>/usr/ports</filename> (el árbol de ports),
          <filename>/src</filename> (diversos árboles de fuentes de
          procedencias varias) y
          <filename>/share</filename> (otros datos compartidos que no
           necesitan ser guardados, por ejemplo mensajes de
           <quote>news</quote>.</para>
      </listitem>

      <listitem>
        <para><quote>Lujos</quote>.</para>

        <para>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 <package>shells/zsh</package> puesto
          que es la shell que aparece en mi cuenta de usuario en <filename>
          /etc/passwd</filename>.  De todos modos la tarea puede culminarse
          sin esos <quote>lujos</quote> (de ahí su nombre), todo lo
          que necesita es entrar en el sistema como root y pasar a la
          siguiente fase.</para>

        <para>?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 <quote>chroot</quote> 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 <quote>scripts</quote> de configuración
          podrían intentar usarla y en concuencia ver <quote>
          muertos</quote> sus procesos al tratar de ejecutarse en el viejo
          kernel.  He tenido problemas de otro tipo al intentar
          construír <package>lang/perl5</package>.</para>
      </listitem>
    </itemizedlist>

    <para>Antes de ejecutar <filename>fase_1.sh</filename> asegúrese
      de haber cumplido con las tareas previas a un
      <command>make installworld installkernel</command>, es decir:</para>

    <itemizedlist>
      <listitem>
        <para>haber adaptado el fichero de configuración de su
            kernel</para>
      </listitem>

      <listitem>
        <para>haber completado sin errores <command>
            make buildworld</command></para>
      </listitem>

      <listitem>
        <para>haber completado sin errores<command>
            KERNCONF=
            nombre_de_su_kernel</command></para>
      </listitem>
    </itemizedlist>


    <para>Cuando ejecute <filename>fase_1.sh</filename> 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
      <filename>/usr/src</filename>, así que <command>
      mergemaster</command> 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 <command>mergemaster</command> puede
      simplemente actualizar sus ficheros una vez en el sistema <emphasis>
      original</emphasis> (pero sólo si existe esa opció:
      por ejemplo, si uno de sus sistemas usa <literal>-STABLE</literal> y
      el otro <literal>-CURRENT</literal> los cambios tienen bastantes
      probabilidades de ser incompatibles).  En posteriores usos
      de <command>mergemaster</command> detectará que los ID de
      las versiones RCS de esos ficheros coinciden con los que están
      bajo <filename>/usr/src</filename> y no les prestará más
      atención.</para>

    <para>El <quote>script</quote> <filename>fase_1.sh</filename>
      detendrá su ejecución si falla alguno de los
      comandos que contiene (si alguno da una salida distinta de
      cero) por incluír <command>set -e</command>, 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
      <filename>fase_1.sh</filename>.</para>

    <para>En <filename>fase_1.sh</filename> invocamos
      <command>mergemaster</command>.  Tanto si alguno de los ficheros
      requiere ser combinado como si no, <command>mergemaster</command>
      emitirá el siguiente mensaje</para>

    <screen>*** Comparison complete

Do you wish to delete what is left of /var/tmp/temproot.fase1? [no] <userinput>no</userinput></screen>

    <para>es decir</para>

    <screen>*** Comparación completada

?Quiere borrar el contenido de /var/tmp/temproot.fase1? [no] <userinput>no</userinput></screen>

    <para>Por favor, responda <literal>no</literal> o simplemente pulse
      <keycap>Enter</keycap>.  Eso es debido a que <command>
      mergemaster</command> habrá dejado unos cuantos ficheros
      de longitud igual a cero en <filename>
      /var/tmp/temproot.fase1</filename> y los copiará al nuevo
      sistema (a menos que ya estén ahí).</para>

    <para>Después mostrará los ficheros que ha instalado
      mediante &man.more.1; o si lo prefiere mediante &man.less.1;):</para>

<screen>*** 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)</screen>

    <para>es decir</para>

 <screen>*** 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

       </screen>

    <para>Teclée <keycap>q</keycap> para salir del
      paginador.  Ahora se le informará sobre <filename>
      login.conf</filename>:</para>

    <screen>*** 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]</screen>

    <para>es decir</para>

    <screen>*** 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]</screen>

    <para>La respuesta no tiene importancia puesto que ejecutaremos
      &man.cap.mkdb.1; en todos los casos.</para>

    <para>Todo lo que hace <filename>fase_1.sh</filename> queda registrado
      en un fichero <quote>log</quote> para que pueda examinarse con
      detalle si es preciso.</para>

    <para>Éste es el <filename>fase_1.sh</filename> del autor,
      así que tendrá que modificarlo a conciencia,
      en especial los pasos 1, 2, 5 y 6.</para>

    <warning>
      <para>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 <quote>script</quote> 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
        <filename>/dev/da3s1a</filename>, <filename>/dev/vinum/var_a</filename>
        y <filename>/dev/vinum/usr_a</filename>.  Puede provocar un desastre,
        así que asegúrese de cambiar los nombres de los
        dispositivos como corresponda.</para>
    </warning>

<programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="fase_1.sh" parse="text" encoding="iso-8859-1"/></programlisting>

    <para>Descargue <link xlink:href="fase_1.sh"><filename>fase_1.sh</filename></link>.</para>

    <para>La ejecución de éste <quote>script</quote> instala
      un sistema equipado con lo siguiente:</para>
    <itemizedlist>
      <listitem>
        <para>Usuarios y grupos heredados del anterior sistema.</para>
      </listitem>
      <listitem>
        <para>Acceso a Internet mediante Ethernet y PPP protegido por
          un cortafuegos.</para>
      </listitem>
      <listitem>
        <para>NTP y zona horaria correctas.</para>
      </listitem>
      <listitem>
        <para>Algunos ficheros secundarios como
        <filename>/etc/ttys</filename> e
        <command>inetd</command>.</para>
      </listitem>
    </itemizedlist>

    <para>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.</para>
  </sect1>

  <sect1 xml:id="stage2">
    <title>Segunda Fase: Instalación de <quote>
      ports</quote></title>

    <note>
      <para>En ésta fase es posible instalar <quote>packages</quote>
        (que vienen precompilados) en lugar de compilar <quote>
        ports</quote>.  Para poder hacerlo convertiremos <filename>
        fase_2.sh</filename> en poco más que una lista de
        comandos <command>pkg_add</command>.  Confío en que
        será usted capaz de escribir un <quote>script</quote>
        como ese.  Ahora nos concentraremos en el sistema tradicional
        y mucho más flexible de funcionamiento de los
        <quote>ports</quote>.</para>
    </note>

    <para>El siguiente <quote>script</quote> <filename>
      fase_2.sh</filename> es el que yo uso para instalar mis <quote>
      ports</quote> favoritos.  Puede ejecutarse tantas veces como sea
      preciso y no prestará atención a los <quote>
      ports</quote> que ya estén instalados.  Incluye también
      soporte para la
      opción <option>-n</option> que hace un <emphasis>ensayo
      general con todo</emphasis>, es decir, muestra lo que hubiera sucedido
      si se hubiera ejecutado.  Seguro que tiene que editar la lista de
      <quote>ports</quote> y probablemente tenga que cambiar unas cuantas
      variables de entorno.</para>

    <para>La lista de <quote>ports</quote> consiste en líneas
      de dos o más palabras separadas por espacios: la categoría
      y el <quote>port</quote>. Es opcional situar detrás
      un comando de instalación que compilará e instalará
      el <quote>port</quote> (por defecto <command>make install</command>).
      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 <quote>port</quote> y la categoría a que pertenece pero
      existen unos pocos <quote>ports</quote> en cuya compilación
      podemos afinar mucho asignando valores a variables de <command>
      make</command>; veamos un ejemplo:</para>

    <programlisting>www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install
mail procmail make BATCH=yes install</programlisting>

    <para>De hecho puede usted usar comandos de <quote>shell</quote> a
      su criterio, así que no tiene que limitarse a simples
      invocaciones de <command>make</command>:</para>

    <programlisting>java linux-sun-jdk13 yes | make install
news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install</programlisting>

    <para>Observe que la línea de <package>news/inn-stable</package> es un ejemplo de una
      asignación de entrada a la variable del intérprete de
      mandatos <literal>CONFIGURE_ARGS</literal>.  El fichero <filename>Makefile</filename>
      del <quote>port</quote> la usará como valor inicial y la
      completará con otros argumentos esenciales.  La diferencia respecto a
      a especificar la variable para <filename>make</filename> en la línea de
      comandos mediante </para>

    <programlisting>news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install</programlisting>

    <para>está en que esto último sustituye directamente el valor
      en lugar de completarlo.  El método más adecuado depende de cada
      <quote>port</quote> en particular.</para>

    <para>Compruebe cuidadosamente que ninguno de sus <quote>ports</quote>
      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 <filename>fase_2.sh</filename> pasa por alto
      un <quote>port</quote> o cesa su ejecución sin razón
      aparente es muy posible que esa sea la razón.</para>

    <para>He aquí <filename>fase_2.sh</filename>.  Crea un fichero
      <quote>log</quote> por cada port que instala y les da nombres
      según el esquema <filename>
      DIRECTORIO_LOG/categoría+port</filename>.  Si no tiene una
      copia de su <filename>fase_2.sh</filename> en una partición
      compartida no olvide copiarlo al sistema nuevo antes de
      arrancarlo.</para>

<programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="fase_2.sh" parse="text" encoding="iso-8859-1"/></programlisting>

    <para>Descargue <link xlink:href="fase_2.sh"><filename>fase_2.sh</filename></link>.</para>
  </sect1>

  <sect1 xml:id="stage3">
    <title>Tercera Fase</title>

    <para>Ya hemos concluído la segunda fase y ya están
      instalados sus queridísimos <quote>ports</quote>, 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 <quote>script</quote> <filename>
      fase_2.sh</filename> pero creo que hay una diferencia conceptual
      entre instalar un <quote>port</quote> 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.</para>

    <para>He creído más conveniente implementar la
      tercera fase como un <filename>Makefile</filename> porque
      admiten la selección de lo que quiera configurar
      tecleando simplemente:</para>

    <informalexample>
      <screen>&prompt.root; <userinput>make -f fase_3.mk 
          nombre_del_port</userinput></screen>
    </informalexample>

    <para>Al igual que con <filename>fase_2.sh</filename> asegúrese
      de que dispone de una copia de su <filename>fase_3.mk</filename> 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.</para>

<programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="fase_3.mk" parse="text" encoding="iso-8859-1"/></programlisting>

    <para>Descargue <link xlink:href="fase_3.mk"><filename>fase_3.mk</filename></link>.</para>
  </sect1>

  <sect1 xml:id="limitations">
    <title>Restricciones</title>

    <para>La instalación automatizada de un <quote>port</quote>
      puede resultar difícil si es interactiva y no soporta
      <command>make BATCH=YES install</command>.  En algunos casos
      la interacción se reduce a teclear <literal>yes</literal>
      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 <command>make install</command>;
      ese es el modo en el que hemos procedido con <package>java/linux-sun-jdk13</package> en
      <filename>fase_2.sh</filename>).</para>

    <para>No obstante ésta estrategia no funciona con <package>editors/staroffice52</package>, 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
      <quote>ports</quote>.  Sin embargo el siguiente atajo workaround
      nos soluciona el problema: previamente he creado un <filename>
      staroffice</filename> en el sistema original con</para>

    <informalexample>
      <screen>&prompt.root; <userinput>cd /usr/ports/editors/staroffice52</userinput>
&prompt.root; <userinput>make package</userinput>
===&gt;  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'</screen>
    </informalexample>

    <para>y durante la segunda fase usamos:</para>

    <informalexample>
      <screen>&prompt.root; <userinput>pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz</userinput></screen>
    </informalexample>

    <para>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 <filename>
      /etc/group</filename>, o quizás <filename>/etc/passwd</filename>
      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 <command>mergemaster</command> 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
      <command>mergemaster</command> sólo es útil con ficheros
      del sistema base y no para aquellos relacionados con los <quote>
      ports</quote>.  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 <quote>news</quote>.
      Cualquier tipo de software cuyo mantenimiento sea muy activo es un firme
      candidato a que sus ficheros de configuración merezcan nuestro
      examen.</para>

    <para>He usado &scratch.ap; varias veces para actualizar un sistema
      <literal>5-CURRENT</literal> a <literal>5-CURRENT</literal>, esto es,
      nunca he intentado instalar <literal>5-CURRENT</literal> desde un
      sistema <literal>4-STABLE</literal> o viceversa, pero dada la
      cantidad de cambios existentes entre las diferentes <quote>
      RELEASE</quote> no sería insensato esperar que esa tarea
      sea un tanto compleja.  Usar &scratch.ap; para actualizaciones
      dentro del campo de <literal>4-STABLE</literal> debería
      ser mucho menos penoso (aunque yo aún no lo he
      intentado).  Si quiere hacerlo debería tener en cuenta
      lo siguiente:</para>

    <itemizedlist>
      <listitem>
        <para>Si no usa el sistema de ficheros de dispositivo
        (<literal>devfs</literal>) puede necesitar crear los
        dispositivos necesarios para su hardware con &man.MAKEDEV.8;
        en la primera fase, sexto paso.</para>
      </listitem>
    </itemizedlist>

  </sect1>
</article>