721 lines
33 KiB
Text
721 lines
33 KiB
Text
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//ES">
|
||
%articles.ent;
|
||
<!ENTITY scratch.ap "<application>FreeBSD From Scratch</application>">
|
||
]>
|
||
|
||
<article>
|
||
<articleinfo>
|
||
<title>FreeBSD From Scratch</title>
|
||
|
||
<author>
|
||
<firstname>Jens</firstname>
|
||
<surname>Schweikhardt</surname>
|
||
<affiliation>
|
||
<address><email>schweikh@FreeBSD.org</email></address>
|
||
</affiliation>
|
||
</author>
|
||
<copyright>
|
||
<year>2002</year>
|
||
<holder>Jens Schweikhardt</holder>
|
||
</copyright>
|
||
|
||
<pubdate>$FreeBSD$</pubdate>
|
||
</articleinfo>
|
||
|
||
<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>
|
||
|
||
<sect1 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
|
||
<maketarget>installworld</maketarget> falla a la mitad
|
||
su sistema quedará dañado e incluso
|
||
puede ser incapaz de arrancar de nuevo. O quizás
|
||
<maketarget>installworld</maketarget> 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 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
|
||
<ulink url="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html">el
|
||
Handbook</ulink>, 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
|
||
<ulink
|
||
url="http://www.linuxfromscratch.org/">Linux From Scratch</ulink>,
|
||
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<65>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<63>n de red bien configurada
|
||
como IP primaria de esa "jail" podr<64>a ser posible incluso
|
||
compilar "ports" en un "chroot" sin desinstalar nada del
|
||
sistema anfitri<72>n. No obstante tenga en cuenta que incluso
|
||
las "jail" est<73>n ejecutando el kernel anfitri<72>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 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 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 <filename
|
||
role="package">shells/zsh</filename> 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 <filename
|
||
role="package">lang/perl5</filename>.</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=<replaceable>
|
||
nombre_de_su_kernel</replaceable></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><inlinegraphic fileref="fase_1.sh" format="linespecific"></programlisting>
|
||
|
||
<para>Descargue <ulink
|
||
url="fase_1.sh"><filename>fase_1.sh</filename></ulink>.</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 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 <filename
|
||
role="package">news/inn-stable</filename> 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><inlinegraphic fileref="fase_2.sh" format="linespecific"></programlisting>
|
||
|
||
<para>Descargue <ulink
|
||
url="fase_2.sh"><filename>fase_2.sh</filename></ulink>.</para>
|
||
</sect1>
|
||
|
||
<sect1 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:
|
||
|
||
<informalexample>
|
||
<screen>&prompt.root; <userinput>make -f fase_3.mk <replaceable>
|
||
nombre_del_port</replaceable></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><inlinegraphic fileref="fase_3.mk" format="linespecific"></programlisting>
|
||
|
||
<para>Descargue <ulink
|
||
url="fase_3.mk"><filename>fase_3.mk</filename></ulink>.</para>
|
||
</sect1>
|
||
|
||
<sect1 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 <filename
|
||
role="package">java/linux-sun-jdk13</filename> en
|
||
<filename>fase_2.sh</filename>).</para>
|
||
|
||
<para>No obstante ésta estrategia no funciona con <filename
|
||
role="package">editors/staroffice52</filename>, 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>
|
||
===> 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>
|