Debian -->
[ document manifest ]
 

Manual Debian Live

Debian Live Project

Rights: Copyright ©  2006-2011 Debian Live Project;
License: Este programa es software libre: puede ser redistribuido y / o modificado bajo los términos de la GNU General Public License publicada por la Free Software Foundation, bien de la versión 3 de la Licencia, o (a su elección) cualquier versión posterior.

Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA, incluso sin la garantía implícita de COMERCIALIZACIÓN o IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Consulte la GNU General Public License para más detalles.

Debería haber recibido una copia de la General Public License GNU junto con este programa. Si no, vea http://www.gnu.org/licenses/.

El texto completo de la GNU Licencia Pública General se pueden encontrar en /usr/share/common-licenses/GPL-3


Manual Debian Live

Acerca de este manual

1. Acerca de este manual

1.1 Para el impaciente.
1.2 Términos
1.3 Autores
1.4 Cómo contribuir en este documento
1.4.1 Aplicación de parches
1.4.2 Traducciones

2. Acerca del Proyecto Debian Live

2.1 Motivación
2.1.1 Desventajas en los sistemas Live actuales
2.1.2 El porqué de crear un Sistema Live propio.
2.2 Filosofía
2.2.1 Solamente paquetes sin modificación alguna de Debian «main»
2.2.2 Sin configuración especial para el Sistema Live
2.3 Contacto

Usuario

3. Instalación

3.1 Requisitos
3.2 Instalación de live-build
3.2.1 Desde el repositorio Debian.
3.2.2 A partir del código fuente
3.2.3 A partir de «instantáneas»
3.3 live-boot y live-config
3.3.1 Desde el repositorio Debian.
3.3.2 A partir del código fuente
3.3.3 A partir de «instantáneas»

4. Conceptos básicos

4.1 ¿Qué es un sistema en vivo?
4.2 Primeros pasos: creación de una imagen ISO híbrida
4.3 Usar una imagen ISO híbrida
4.3.1 Grabar una imagen ISO en un medio físico.
4.3.2 Copiar una imagen ISO híbrida a un dispositivo USB
4.3.3 Arrancar los medios en vivo
4.4 Usar una máquina virtual para pruebas
4.4.1 Probar una imagen ISO con QEMU
4.4.2 Probar una imagen ISO con virtualbox-ose
4.5 Crear una imagen USB/HDD
4.6 Utilizar una imágen USB/HDD
4.6.1 Probar una imágen USB/HDD con Qemu
4.6.2 Usar el espacio libre en el dispositivo USB
4.7 Creación de una imagen de arranque en red
4.7.1 Servidor DHCP
4.7.2 Servidor TFTP
4.7.3 Servidor NFS
4.7.4 Cómo probar el arranque en red
4.7.5 Qemu
4.7.6 VMWare Player

5. Descripción general de las herramientas

5.1 live-build
5.1.1 El comando lb config
5.1.2 El comando lb build
5.1.3 El comando lb clean
5.2 El paquete live-boot
5.3 El paquete live-config

6. Gestionar una configuración

6.1 Utilización de auto para gestionar los cambios de la configuración
6.2 Un ejemplo de scripts auto.

7. Descripción general de la personalización.

7.1 Configuración en el momento de la creación vs en el momento del arranque
7.2 Etapas de la creación
7.3 Opciones para lb config en ficheros
7.4 Tareas de personalización

8. Personalización de la instalación de paquetes

8.1 Origen de los paquetes
8.1.1 Distribución, áreas de archivo y modo
8.1.2 Réplicas de Distribución Debian
8.1.3 Réplicas de Distribution utilizadas durante la creación
8.1.4 Réplicas de distribución Debian utilizadas en la ejecución.
8.1.5 Repositorios adicionales
8.2 Selección de los paquetes a instalar
8.2.1 Listas de paquetes
8.2.2 Listas de paquetes predefinidas
8.2.3 Listas de paquetes locales
8.2.4 Listas de paquetes locales para binary
8.2.5 Extensión de una lista de paquetes dada mediante «includes»
8.2.6 Utilización de condiciones dentro de las listas de paquetes
8.2.7 Tareas
8.2.8 Tareas de Escritorio e Idioma
8.3 Instalar paquetes de terceros o paquetes modificados
8.3.1 Método packages.chroot para instalar paquetes personalizados
8.3.2 Método de repositorio APT para instalar paquetes personalizados
8.3.3 Paquetes personalizados y APT
8.4 Configurar APT en la creación
8.4.1 Utilizar apt o aptitude
8.4.2 Utilización de un proxy con APT
8.4.3 Ajuste de APT para ahorrar espacio
8.4.4 Pasar opciones a apt o a aptitude
8.4.5 APT pinning

9. Personalización de contenidos

9.1 Includes
9.1.1 Includes locales en Live/chroot
9.1.2 Includes locales en Binary
9.1.3 Includes en Binary
9.2 Scripts gancho (Hooks)
9.2.1 Scripts gancho locales en Live/chroot
9.2.2 Scripts gancho en tiempo de arranque
9.2.3 Scripts gancho locales en Binary
9.3 Preconfiguración de las preguntas de Debconf

10. Personalización del comportamiento en tiempo de ejecución.

10.1 Personalización del usuario por defecto del sistema en vivo
10.2 Personalización de las variantes locales e idioma
10.3 Persistencia (Modo guardar cambios)
10.3.1 Persistencia total
10.3.2 Montar Home de forma automática
10.3.3 Instantáneas
10.3.4 SubText persistente
10.3.5 Remasterización parcial

11. Personalización de la imagen binaria

11.1 Gestor de arranque
11.2 Metadatos ISO

12. Personalización del Instalador de Debian

12.1 Tipos de imágenes según el instalador
12.2 Personalizando el Instalador de Debian mediante preconfiguración
12.3 Personalizar el contenido del Instalador de Debian

Proyecto

13. Informes de errores.

13.1 Problemas conocidos
13.2 Reconstruir desde cero
13.3 Utilizar paquetes actualizados
13.4 Recopilar información
13.5 Aislar el fallo si es posible
13.6 Utilizar el paquete correcto sobre el que informar del error
13.6.1 En la preinstalación (bootstrap) en tiempo de creación.
13.6.2 Mientras se instalan paquetes en tiempo de creación.
13.6.3 En tiempo de arranque
13.6.4 En tiempo de ejecución
13.7 Hacer la investigación
13.8 Dónde informar de los fallos

14. Estilo de código

14.1 Compatibilidad
14.2 Sangrado
14.3 Ajuste de líneas
14.4 Variables
14.5 Miscelánea

15. Procedimientos

15.1 Subir Udebs
15.2 Principales lanzamientos
15.3 Nuevas versiones
15.3.1 Plantilla para anunciar nuevas versiones.

Ejemplos

16. Ejemplos

16.1 Uso de los ejemplos
16.2 Tutorial 1: Una imagen estándar
16.3 Tutorial 2: Una utilidad de navegador web
16.4 Tutorial 3: Una imagen personalizada
16.4.1 Primera revisión
16.4.2 Segunda revisión
16.5 Un cliente VNC kiosk
16.6 Una imagen básica para un pendrive USB de 128M
16.7 Un escritorio KDE con variante local e instalador

Manual Debian Live

Acerca de este manual

1. Acerca de este manual

El objetivo principal de este manual es servir como único punto de acceso a toda la documentación referente al projecto Debian Live. Está principalmente enfocado a ayudar en la creación de un sistema en vivo y no está dirigido al usuario final de estos sistemas. Un usuario final puede encontrar información útil en las siguentes secciones: Conceptos básicos cubre la preparación de las imágenes para arrancar un sistema desde un medio de almacenamiento o desde red local. Personalización del comportamiento en tiempo de ejecución describe alguna de las opciones que pueden especificarse en el indicador de arranque, como pueden ser la selección de la distribución del teclado, las variantes locales o la persistencia.

Algunos de los comandos mencionados en el texto deben ser ejecutados con privilegios de superusuario, que pueden ser obtenidos accediendo a la cuenta de root mediante la orden su o mediante la orden sudo. Para distinguir las ordenes que deben ser ejecutadas como usuario no privilegiado de las que si requieren privilegios de superusuario se ha prefijado con $ las primeras y con # las segundas. Estos símbolos no son parte de la orden.

1.1 Para el impaciente.

Aunque se cree que todo lo descrito en este manual es importante para la mayoría de los usuarios, es cierto que hay mucho material a interiorizar y que los usuarios desean experimentar con las herramientas de forma rápida y satisfactoria antes de entrar en detalles. Ésta es la razón por la que se presentan tres tutoriales en la sección Ejemplos pensados para aprender a configurar y construir imágenes de sistemas en vivo de forma básica. Se deberá leer primero Uso de ejemplos, seguido de Tutorial 1: Una imagen estándar y Tutorial 2: Una utilidad de navegador web, para finalizar con Tutorial 3: Una imagen personalizada. Al final de estos tutoriales, el lector tendrá una visión de lo que se puede hacer con Debian Live. Se anima a profundizar en el estudio del manual con la lectura detenida del siguiente capítulo, Conceptos básicos, y de una manera más somera el capítulo La creación de una imagen netboot, para acabar con la lectura de Descripción general de la personalización y los capítulos que le siguen. Se espera que, en este punto, el lector esté lo suficientemente motivado con lo que se puede hacer con Debian Live para leer el resto del manual, de principio a fin.

1.2 Términos
  • Sistema en vivo: Se entiende por sistema en vivo aquel sistema operativo que se puede arrancar sin instalación previa en el disco duro. Un sistema en vivo no altera ningún sistema operativo previamente instalado ni ningún fichero existente en el disco duro de la máquina a menos que se le instruya para hacerlo. Los sistemas en vivo son arrancados típicamente desde medios extraíbles como CD, DVD o llaves USB. Algunos pueden también arrancar desde la red local.
  • Debian Live: Es un subproyecto de Debian que mantiene los paquetes Debian live-boot, live-build, live-config y live-manual.
  • Sistema Debian Live: Es un sistema en vivo que utiliza programas del sistema operativo Debian y que puede ser arrancado desde medios extraíbles como CD, DVD o llaves USB, desde red local (mediante imágenes netboot) o desde Internet (utilizando la opción de arranque fetch=URL).
  • Sistema huésped: Es el conjunto de herramientas y equipo utilizado para crear el sistema en vivo.
  • Sistema objetivo: Es el conjunto de herramientas y equipo donde se ejecutará el sistema en vivo.
  • live-boot: Es una colección de scripts que serán responsables de arrancar el sistema en vivo. live-boot fue anteriormente una parte del paquete live-initramfs.
  • live-build: Es una colección de scripts utilizados para construir sistemas Debian Live personalizados. live-build fue conocido anteriormente como live-helper, y en una versión anterior como live-package.
  • live-config: Es una colección de scripts utilizados para configurar un sistema en vivo durante el proceso de arranque. live-config fue anteriormente parte del paquete live-initramfs.
  • live-manual: Este documento forma parte de un paquete llamado live-manual.
  • Instalador de Debian (Debian Installer o d-i): Es el mecanismo oficial de instalación para la distribución Debian.
  • Parámetros de arranque: Parámetros que son entregados al gestor de arranque (bootloader) para modificar el comportamiento del kernel o del conjunto de scripts live-config. Son llamados también Parámetros de kernel u Opciones de arranque.
  • chroot: El programa chroot, chroot(8), permite ejecutar diferentes instancias de un entorno GNU/Linux en un solo sistema de manera simultánea sin necesidad de reiniciar el sistema.
  • Imagen binaria: Es un fichero binario que contiene el sistema en vivo. Su nombre puede ser binary.iso o binary.img dependiendo de su formato.
  • Distribución objetivo: Es la versión de la distribución Debian en la cual estará basado el sistema en vivo que puede diferir de la versión de la distribución en el sistema huésped.
  • Squeeze/Wheezy/Sid (stable/testing/unstable): Son los nombres clave de las diferentes versiones de distribución Debian. En el momento de escribir este documento, Squeeze es la actual versión stable o estable, Wheezy es la actual versión testing o en pruebas. Sid es y será siempre sinónimo de versión unstable o inestable. A lo largo de todo el manual se usan los nombres en clave de las versiones ya que las herramientas también los usan.
  • La distribución stable contiene la última distribución Debian oficialmente publicada. La distribución testing está en la rampa de salida para ser la próxima distribución stable. La principal ventaja de utilizar esta distribución es que tiene versiones de programas más recientes si se compara con la versión stable. La distribución unstable es dónde se realiza el desarrollo de Debian. Generalmente esta distribución es usada por los desarrolladores y aquellos que les gusta vivir al filo de lo imposible.

    1.3 Autores

    Lista de autores (en orden alfabético):

  • Ben Armstrong
  • Brendan Sleight
  • Chris Lamb
  • Daniel Baumann
  • Franklin Piat
  • Jonas Stein
  • Kai Hendry
  • Marco Amadori
  • Mathieu Geli
  • Matthias Kirschner
  • Richard Nelson
  • Trent W. Buck
  • 1.4 Cómo contribuir en este documento

    Este manual se ha creado como un proyecto comunitario y cualquier propuesta para su mejora u otras contribuciones son siempre bienvenidas. La mejor forma de hacer una contribución es enviarla a la lista de correo. Ver la sección Contacto para más información.

    Cuando se envía una contribución se debe identificar claramente su copyright e incluir la declaración de licencia. Se hace notar que para ser aceptada, una contribución debe ser licenciada bajo la misma licencia que el resto del documento, esto es, GPL versión 3 o posterior.

    Los originales de este manual se mantienen utilizando el sistema de control de versiones Git. Se puede obtener la copia más actualizada ejecutando la siguiente orden:

    $ git clone git://live.debian.net/git/live-manual.git

    Antes de enviar una contribución se debería realizar una visualización del trabajo realizado. Para ello asegurarse de tener instalados los paquetes necesarios para la construcción del live-manual ejecutando la siguiente orden:

    # apt-get install make po4a sisu-complete libnokogiri-ruby

    Se puede realizar la construcción del manual posicionándose en el directorio de nivel superior, o sea, en el directorio clonado mediante Git y ejecutando la siguiente orden:

    $ make build

    Ya que la construcción del manual para todos los idiomas soportados tarda un rato, puede ser mejor crear un solo idioma. Esto puede realizarse ejecutando la siguiente orden:

    $ make build LANGUAGES=en

    1.4.1 Aplicación de parches

    Cualquiera puede hacer una entrega en el repositorio. Sin embargo, a la hora de hacer grandes cambios, es conveniente enviarlos a la lista de correo para discutirlos primero. Para realizar una entrega al repositorio se debe seguir el siguiente procedimiento:

  • Obtener la clave pública de entrega:
  • $ mkdir -p ~/.ssh/identity.d
    $ wget http://live.debian.net/other/keys/git@live.debian.net \
         -O ~/.ssh/identity.d/git@live.debian.net
    $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
         -O ~/.ssh/identity.d/git@live.debian.net.pub
    $ chmod 0600 ~/.ssh/identity.d/git@live.debian.net*

  • Añadir la siguiente sección en el fichero de configuración de openssh-client:
  • $ cat >> ~/.ssh/config << EOF
    Host live.debian.net
         Hostname live.debian.net
         User git
         IdentityFile ~/.ssh/identity.d/git@live.debian.net
    EOF

  • Obtener un clon del manual mediante git utilizando ssh:
  • $ git clone git@live.debian.net:/live-manual.git
    $ cd live-manual && git checkout debian-next

  • Asegurarse de enviar los cambios a la rama debian-next y no a la rama Debian.
  • Después de editar los ficheros que se deseen en manual/en/, ejecutar «make commit» en el directorio superior para sanear los ficheros y actualizar los ficheros de traducciones:
  • $ make commit

  • Una vez se ha saneado, se deberán entregar los cambios. Se deberá escribir un mensaje de entrega que consistirá en una o varias frases en ingles, comenzando con una letra mayúscula y acabando con un punto final. Es habitual comenzar estas frases con la forma 'Fixing/Adding/Removing/Correcting/Translating', por ejemplo:
  • $ git commit -a -m "Adding a section on applying patches."

  • Para finalizar se realizará la entrega al servidor utilizando el siguiente comando:
  • $ git push

    1.4.2 Traducciones

    Para enviar una traducción para un nuevo idioma, se deben seguir los siguientes pasos:

  • Traducir los ficheros about_manual.ssi.pot, about_project.ssi.pot e index.html.in.pot al idioma deseado con cualquier editor (como puede ser poedit) y enviarlos a la lista de correos. Una vez hayan sido revisados, el idioma será añadido al manual, (añadiendo los ficheros .po) y se activará en el autobuild.
  • Una vez que el nuevo idioma haya sido añadido, se puede comenzar la traducción de todos los ficheros .po exisitentes en manual/po/ de manera aleatoria.
  • No se debe olvidar la ejecución del comando make commit para asegurar que los manuales traducidos son actualizados desde los ficheros .po, antes de realizar la entrega mediante git commit -a y git push.
  • 2. Acerca del Proyecto Debian Live

    2.1 Motivación
    2.1.1 Desventajas en los sistemas Live actuales

    Cuando se comenzó el trabajo en Debian Live, ya existían varios Sistemas Live disponibles basados en la distribución Debian y todos hacian un buen trabajo. Desde la persectiva de Debian, la mayoría de estos sistemas tenían alguna de estas desventajas:

  • No eran proyectos de Debian y por lo tanto no contaban con soporte desde dentro de Debian.
  • Mezclaban paquetes de diferentes versiones, por ejemplo testing y unstable.
  • Solamente soportaban la arquitectura i386.
  • Modificaban el comportamiento y/o la apariencia de los paquetes, eliminando contenido para reducirlos de tamaño.
  • Incluían paquetes de fuera del archivo de Debian.
  • Utilizaban kernels personalizados con parches que no eran parte de Debian.
  • Eran demasiado lentos, debido a su gran tamaño, para ser utilizados como sistemas de rescate.
  • No disponían de diferentes medios de instalación, como CDs, DVDs, llaves USB o imágenes de arranque por red netboot.
  • 2.1.2 El porqué de crear un Sistema Live propio.

    Debian es el Sistema Operativo Universal: Debian tiene un Sistema Live para mostrar y representar el auténtico y verdadero Debian con las siguientes ventajas fundamentales:

  • Debería ser un subproyecto de Debian.
  • Refleja el estado (actual) de una versión Debian.
  • Se ejecuta en tantas arquitecturas como es posible.
  • Consiste solamente de paquetes Debian sin modificar.
  • No contiene ningún paquete que no forma parte del archivo de Debian.
  • Utiliza kernels que provienen de Debian inalterados sin parches adicionales.
  • 2.2 Filosofía
    2.2.1 Solamente paquetes sin modificación alguna de Debian «main»

    Solamente se utilizarán paquetes del repositorio de Debian de la sección «main». La sección non-free no es parte de Debian y por lo tanto no puede ser utilizada de ninguna de las maneras para generar imágenes de sistema oficiales.

    No se modificará ningún paquete. Siempre que se necesite modificar algo, se hará en coordinación con el correspondiente mantenedor del paquete en Debian.

    Como una excepción, los paquetes del proyecto como son live-boot, live-build o live-config, pueden ser utilizados temporalmente desde el repositorio del proyecto, por razones de desarrollo (por ejemplo para crear instantaneas de pruebas). Estos paquetes serán actualizados en Debian de manera regular.

    2.2.2 Sin configuración especial para el Sistema Live

    En esta fase, no se creará o instalarán configuraciones alternativas o de ejemplo. Se utilizarán todos los paquetes con su configuración por defecto, tal y como quedan después de una instalación normal de Debian.

    Siempre que se necesite una configuración diferente a la de por defecto, se hará en coodinación con el mantenedor del paquete Debian correspondiente.

    En lb config se emplea un sistema para configurar paquetes que utiliza debconf (mediante el uso de la opción --preseed FICHERO), permitiendo la personalización de la configuración de los paquetes que van a ser instalados en la imagen Debian Live que se genere, pero las imágenes Live oficiales solamente utilizarán la configuración por defecto.

    Excepción: Es esencial realizar unos pocos cambios para que un sistema pueda funcionar en vivo (como por ejemplo configurar pam para permitir contraseñas vacias). Estos cambios esenciales se deben mantener tan pequeños como sea posible y deberán ser mezclados en el repositorio Debian siempre que exista la posibilidad.

    2.3 Contacto
  • Lista de correo: El sistema de contacto principal del proyecto es la lista de correo en ‹http://lists.debian.org/debian-live/›. Se puede enviar un correo a la lista directamente dirigiéndolo a ‹debian-live@lists.debian.org.› Los archivos históricos de la lista están disponibles en ‹http://lists.debian.org/debian-live/›.
  • IRC: Un número importante de usuarios y desarrolladores suele estar presente en el canal #debian-live de irc.debian.org (OFTC). Por favor, se debe ser paciente cuando se espera una respuesta en el IRC. Si la respuesta no llega, se puede enviar la pregunta a la lista de correos.
  • BTS : El sistema de gestión de errores de Debian (BTS) contiene detalles de problemas enviados por usuarios y desarrolladores. Los errores están numerados y se mantiene un registro hasta que son reparados. Si se desea más información ver Informes de errores.
  • Wiki: El wiki de Debian Live en ‹http://wiki.debian.org/DebianLive› es el lugar donde obtener información, discutir sobre la aplicación de tecnologías y de documentar herramientas para los sistemas Debian Live que vayan más allá del ámbito de este documento.
  • Usuario

    3. Instalación

    3.1 Requisitos

    Para crear las imágenes de Debian Live son necesarios los siguientes requisitos:

  • Acceso de superusuario (root)
  • Una versión actualizada de live-build
  • Un intérprete de comandos compatible con POSIX, como por ejemplo bash o dash.
  • debootstrap o cdebootstrap
  • Linux 2.6.x
  • Tener en cuenta que no es necesario el uso de Debian o una distribución derivada de Debian - live-build funcionará en casi cualquier distribución que cumpla con los requisitos anteriores.

    3.2 Instalación de live-build

    Se puede instalar live-build de varias maneras diferentes:

  • Desde el repositorio Debian
  • A partir del código fuente
  • Desde «instantáneas»
  • Si se usa Debian, el método recomendado es instalar live-build a través del repositorio de Debian.

    3.2.1 Desde el repositorio Debian.

    Simplemente instalar live-build como cualquier otro paquete:

    # apt-get install live-build

    o

    # aptitude install live-build

    3.2.2 A partir del código fuente

    live-build se desarrolla utilizando el sistema de control de versiones Git. En los sistemas basados en Debian se encuentra el paquete git. Para ver el último código, ejecutar:

    $ git clone git://live.debian.net/git/live-build.git

    Se puede crear e instalar el paquete Debian ejecutando:

    $ cd live-build
    $ dpkg-buildpackage -rfakeroot -b -uc -us
    $ cd ..

    Si se desea, se podrá instalar cualquiera de los paquetes .deb recien creados con el procedimiento anterior, p.ej.

    # dpkg -i live-build_2.0.8-1_all.deb

    También se puede instalar live-build directamente en el sistema ejecutando:

    # make install

    y desinstalarlo con:

    # make uninstall

    3.2.3 A partir de «instantáneas»

    Si no se desea crear o instalar live-build a partir del código fuente, se puede usar instantáneas. Estas se generan automáticamente a partir de la última versión de Git y están disponibles en ‹http://live.debian.net/debian/›.

    3.3 live-boot y live-config

    Nota: No es necesario instalar live-boot o live-config en el sistema para crear sistemas personalizados de Debian Live. Sin embargo, eso no causará ningún daño y es útil por motivos de referencia. Si únicamente se desea tener la documentación, es posible instalar los paquetes live-boot-doc y live-config-doc de forma independiente.

    3.3.1 Desde el repositorio Debian.

    Tanto live-boot como live-config están disponibles en el repositorio Debian siguiendo la Instalación de live-build.

    3.3.2 A partir del código fuente

    Para utilizar el último código fuente a partir de git, se puede seguir el proceso siguiente. Asegurarse de estar familiarizado con los términos mencionados en Términos.

  • Comprobar el código fuente de live-boot y live-config
  • $ git clone git://live.debian.net/git/live-boot.git
    $ git clone git://live.debian.net/git/live-config.git

    Si se desea generar estos paquetes a partir del código fuente, se puede consultar las páginas del manual para más detalles sobre la personalización de live-boot y live-config.

  • Creación de los paquetes .deb de live-boot y live-config
  • Se debe crear ya sea en la distribución de destino o en un entorno chroot que contenga la plataforma de destino: es decir, si el objetivo es Wheezy entonces se debe crear usando Wheezy.

    Utilizar un programa creador personal como pbuilder o sbuild si se necesita crear live-boot para una distribución de destino diferente del sistema de creación. Por ejemplo, para las imágenes en vivo de Wheezy, crear live-boot en un entorno chroot. Si la distribución de destino coincide con la distribución actual, se puede crear directamente sobre el sistema de creación con dpkg-buildpackage (proporcionada por el paquete dpkg-dev ):

    $ cd live-boot
    $ dpkg-buildpackage -b -uc -us
    $ cd ../live-config
    $ dpkg-buildpackage -b -uc -us

  • Utilizar todos los ficheros .deb generados
  • Como live-boot y live-config son instalados por el sistema live-build, la instalación de estos paquetes en el sistema anfitrión no es suficiente: Se deben tratar los archivos .deb generados exáctamente igual que cualquier otro paquete personalizado. Véase Personalización de la instalación de paquetes para más información. Se debe prestar especial atención a los Repositorios adicionales.

    3.3.3 A partir de «instantáneas»

    Se puede dejar que live-build utilice automáticamente las últimas instantáneas de live-boot y live-config mediante la configuración de repósitorios de terceros en el directorio de configuración de live-build. Suponiendo que ya se haya creado un árbol de configuración en el directorio actual con lb config:

    $ lb config --archives live.debian.net

    4. Conceptos básicos

    Este capítulo contiene una breve descripción del proceso de creación de las imágenes en vivo y las instrucciones para el uso de los tres tipos de imágenes más utilizadas. El tipo de imagen más versátil, iso-hybrid, se puede utilizar en una máquina virtual, en medios ópticos u otros dispositivo de almacenamiento USB. En ciertos casos especiales, como para el uso de la persistencia («persistence» N. del T.) las imágenes usb-hdd, pueden ser las más adecuadas para dispositivos USB. El capítulo termina con instrucciones para crear y usar una imagen de tipo red, que es un poco más complicado debido a la configuración necesaria en el servidor. Es un tema ligeramente avanzado para cualquier persona que no esté familiarizada con el arranque en red, pero se incluye aquí porque una vez que se realiza la instalación, es una forma muy conveniente para probar y desplegar imágenes de arranque en red local sin la molestia de tratar con los dispositivos de almacenamiento de la imagen.

    A lo largo de todo el capítulo se hace a menudo referencia al nombre de las imágenes producidas por defecto por live-build. Si se descarga una imagen ya creada, el nombre puede variar.

    4.1 ¿Qué es un sistema en vivo?

    Por lo general, un sistema en vivo se refiere a un sistema operativo que arranca en un equipo desde un medio extraíble, como un CD-ROM, dispositivo USB, o desde una red, listo para usar sin ningún tipo de instalación en la unidad de costumbre, con configuración automática en tiempo de ejecución (Ver Términos).

    Debian Live, es un sistema Debian GNU/Linux, creado para una de las arquitecturas soportadas (actualmente amd64, i386, powerpc y sparc). Se compone de las siguientes partes:

  • Imágen del kernel de Linux, normalmente llamada vmlinuz*
  • Imagen del Disco RAM inicial (initrd): Un Disco RAM configurado para el arranque de Linux, que incluya los módulos posiblemente necesarios para montar la imagen del sistema y algunos scripts para ponerlo en marcha.
  • Imagen del sistema: La imagen del sistema de ficheros raiz. Por lo general, se utiliza un sistema de ficheros comprimido SquashFS para reducir al mínimo el tamaño de la imagen de Debian Live. Hay que tener en cuenta que es de sólo lectura. Por lo tanto, durante el arranque del sistema Debian Live se utiliza un disco RAM y un mecanismo de «unión» que permite escribir ficheros en el sistema en funcionamiento. Sin embargo, todas las modificaciones se perderán al apagar el equipo a menos que se use de modo opcional la persistencia (ver Persistencia).
  • Gestor de arranque: Una pequeña pieza de código diseñada para arrancar desde el medio de almacenamiento escogido, posiblemente mostrando un menú o un indicador de arranque para permitir la selección de opciones/configuración. Carga el kernel de Linux y su initrd para funcionar con un sistema de ficheros asociado. Se pueden usar soluciones diferentes, dependiendo del medio de almacenamiento de destino y el formato del sistema de ficheros que contenga los componentes mencionados anteriormente: isolinux para arrancar desde un CD o DVD en formato ISO9660, syslinux para arrancar desde el disco duro o unidad USB desde una partición VFAT, extlinux para formatos ext2/3/4 y particiones btrfs, pxelinux para arranque de red PXE, GRUB para particiones ext2/3/4 , etc.
  • Se puede usar live-build para crear la imagen del sistema a partir de ciertas especificaciones, incluir un kernel de Linux, su initrd y un gestor de arranque para ponerlos en funcionamiento, todo ello en un formato que depende del medio de almacenamiento elegido (imagen ISO9660, imagen de disco, etc.)

    4.2 Primeros pasos: creación de una imagen ISO híbrida

    Independientemente del tipo de imagen, cada vez se tendrá que realizar los mismos pasos básicos para construir una imagen. Como primer ejemplo ejecutar la siguiente secuencia de comandos live-build para crear una imagen ISO híbrida básica que contiene sólo el sistema estándar de Debian sin X.org. Es adecuada para grabarla en un CD o DVD y también para copiarla en un dispositivo USB.

    En primer lugar, se ejecuta el comando lb config. Esto creará una jerarquía «config/» en el directorio actual que será usada por otros comandos:

    $ lb config

    Al no pasar ningún parámetro a lb config, se indica que se quiere utilizar todas las opciones por defecto. Ver El comando lb config para más detalles.

    Ahora que existe un jerarquía «config/», se puede crear la imagen con el comando lb build:

    # lb build

    Este proceso puede llevar un tiempo, dependiendo de la velocidad de la conexión de red. Cuando haya terminado, debería haber un fichero binary-hybrid.iso listo para ser usado en el directorio actual.

    4.3 Usar una imagen ISO híbrida

    Después de construir o descargar una imagen ISO híbrida, las cuales se pueden obtener en ‹http://www.debian.org/CD/live/›, el siguiente paso habitual es preparar los medios de almacenamieto, ya sean medios ópticos CD-R(W) o DVD-R(W) o llaves USB.

    4.3.1 Grabar una imagen ISO en un medio físico.

    Grabar una imagen ISO es fácil. Simplemente instalar wodim y usarlo desde el intérprete de comandos para grabar la imagen. Por ejemplo:

    # apt-get install wodim

    $ wodim binary-hybrid.iso

    4.3.2 Copiar una imagen ISO híbrida a un dispositivo USB

    Las imágenes ISO preparadas con el comando isohybrid igual que las imágenes del tipo iso-hybrid producidas por defecto, pueden sencillamente copiarse a una llave USB con dd o con un programa equivalente. Conectar una llave USB con un tamaño suficiente para la imagen y determinar qué dispositivo es, («device» N. del T.) al cual nos referiremos de ahora en adelante como ${USBSTICK}. Este nombre de «dispositivo» se refiere a la llave entera como por ejemplo /dev/sdb y ¡No a una partición como /dev/sdb1! Se puede encontrar el nombre del dispositivo correcto mirando la salida de dmesg después de conectar la llave, o mejor aún ejecutando ls -l /dev/disk/by-id.

    Cuando se esté seguro de tener el nombre del dispositivo correcto, usar el comando dd para copiar la imagen a la llave. ¡Esto borrará de forma definitiva cualquier contenido previo en la llave!

    $ dd if=binary-hybrid.iso of=${USBSTICK}

    4.3.3 Arrancar los medios en vivo

    La primera vez que se arranque desde los medios de almacenamiento en vivo, ya sea CD, DVD, llave USB, o de arranque en red PXE, primero puede ser necesario algún tipo de configuración en la BIOS de la máquina. Dado que las BIOS varían mucho en sus características y combinaciones de teclas, no se puede entrar en el tema en profundidad aquí. Algunas BIOS proporcionan una tecla para abrir un menú de dispositivos de arranque que es la manera más fácil de hacerlo si se encuentra disponible en el sistema.

    Una vez que se haya arrancado desde los medios de almacenamiento externos, se accede a un menú de arranque. Si se pulsa la tecla «enter», el sistema arrancará usando el modo por defecto Live y las opciones predeterminadas. Para obtener más información acerca de las opciones de arranque, ver la opción «help» del menú y también las páginas del manual de live-boot y live-config que se encuentran en el sistema en vivo.

    Suponiendo que se ha seleccionado Live y arrancado una imagen en vivo por defecto con escritorio gráfico, después de que los mensajes de arranque hayan pasado, se habrá iniciado automáticamente una sesión como usuario user y se verá el escritorio preparado para ser usado. Si se ha arrancado una imagen sólo con consola como por ejemplo las imágenes predeterminadas standard o rescue se habrá iniciado automáticamente una sesión como usuario user y se verá el cursor del intérprete de comandos preparado para ser usado.

    4.4 Usar una máquina virtual para pruebas

    Ejecutar las imágenes en vivo en una máquina virtual (VM) puede ser un gran ahorro de tiempo para su desarrollo. Esto no está exento de advertencias:

  • Para ejecutar una máquina virtual se requiere tener suficiente memoria RAM para el sistema operativo huésped y el anfitrión y se recomienda una CPU con soporte de hardware para la virtualización.
  • Existen algunas limitaciones inherentes a la ejecución en una máquina virtual, por ejemplo, rendimiento de video pobre, la limitada gama de hardware emulado.
  • Cuando se desarrolla para un hardware específico, no hay sustituto mejor que el propio hardware.
  • A veces hay errores que se refieren únicamente a la ejecución en una máquina virtual. En caso de duda, probar la imagen directamente en el hardware.
  • Siempre que se pueda trabajar dentro de estas limitaciones, mirar que software VM hay disponible y elegir uno que sea adecuado según las necesidades.

    4.4.1 Probar una imagen ISO con QEMU

    La máquina virtual más versátil en Debian es QEMU. Si el procesador tiene soporte de hardware para virtualización, utilizar el paquete qemu-kvm en la descripción del paquete qemu-kvm se enumera brevemente la lista de requisitos.

    En primer lugar, instalar qemu-kvm si el procesador lo soporta. Si no es así, instalar qemu, en cuyo caso el nombre del programa será qemu en vez de kvm en los siguientes ejemplos. El paquete qemu-utils también es útil para la creación de imágenes virtuales de disco con qemu-img.

    # apt-get install qemu-kvm qemu-utils

    Arrancar una imagen ISO es sencillo:

    $ kvm -cdrom binary-hybrid.iso

    Consultar las páginas del manual para más detalles.

    4.4.2 Probar una imagen ISO con virtualbox-ose

    Para probar una imagen ISO con virtualbox-ose:

    # apt-get install virtualbox-ose virtualbox-ose-dkms

    $ virtualbox

    Crear una nueva máquina virtual, cambiar la configuración de almacenamiento para utilizar binary-hybrid.iso como dispositivo CD/DVD y arrancar la máquina.

    Nota: Para probar los sistemas en vivo con soporte X.org en virtualbox-ose, se puede incluir el paquete del driver de VirtualBox X.org, virtualbox-ose-guest-x11, en la configuración de live-build. De lo contrario, la resolución se limita a 800x600

    $ echo virtualbox-ose-guest-x11 >> config/package-lists/my.list.chroot

    4.5 Crear una imagen USB/HDD

    La siguiente secuencia de comandos creará una imagen USB/HDD básica que contendrá sólo el sistema estándar de Debian sin X.org. Es adecuada para el arranque desde dispositivos USB, discos duros USB y otros dispositivos de almacenamiento portátil. Normalmente, se puede utilizar para este propósito una imagen ISO híbrida, pero es posible que la BIOS no maneje adecuadamente las imágenes híbridas. También es interesante una imagen USB/HDD si se desea utilizar el espacio restante en los medios de almacenamiento para una partición con persistencia.

    Nota: si se ha creado una imagen ISO híbrida con el ejemplo anterior, se tendrá que limpiar el directorio de trabajo con el comando lb clean (ver El comando lb clean):

    # lb clean --binary

    Ejecutar el comando lb config como antes pero esta vez especificando el tipo de imagen USB/HDD:

    $ lb config -b usb-hdd

    Crear ahora la imagen con el comando lb build:

    # lb build

    Cuando termine el proceso de creación, debe haber un fichero llamado binary.img en el directorio actual .

    4.6 Utilizar una imágen USB/HDD

    La imagen binaria generada contiene una partición VFAT y el gestor de arranque syslinux, lista para ser copiada directamente en un dispositivo USB. Dado que utilizar una imagen USB/HDD es igual a usar una imagen ISO híbrida en un USB, seguir las instrucciones de Usar una imagen ISO híbrida con la diferencia de usar el nombre binary.img en lugar de binary-hybrid.iso.

    4.6.1 Probar una imágen USB/HDD con Qemu

    En primer lugar, instalar QEMU como se describe más arriba en Probar una imágen ISO con QEMU A continuación, ejecutar kvm o qemu, según qué versión necesita el sistema anfitrión y especificando binary.img como primer disco duro.

    $ kvm -hda binary.img

    4.6.2 Usar el espacio libre en el dispositivo USB

    Si se desea usar el espacio libre después de haber instalado la imagen binary.img en una llave USB, se puede usar un programa de particionado como gparted o parted para crear una partición nueva en el dispositivo. La primera partición será usada por el sistema Debian en vivo.

    # gparted ${USBSTICK}

    Después de crear la partición, dónde ${PARTITION} es el nombre de la partición, por ejemplo /dev/sdb2 se tiene que crear un sistema de ficheros en él. Una opción posible sería ext4.

    # mkfs.ext4 ${PARTITION}

    Nota: Si se desea usar el espacio extra con Windows, segun parece, ese sistema operativo no puede acceder normalmente a otra partición más que a la primera. Se han comentado algunas soluciones a este problema en nuestra lista de correo pero según parece no hay una solución fácil.

    Recordar: Cada vez que se instale una nueva binary.img en el dispositivo, todos los datos del dispositivo se perderán debido a que la tabla de particiones se sobrescribe con el contenido de la imagen, así pues, realizar primero una copia de seguridad de la partición para poder restaurarla trás actualizar la imagen en vivo.

    4.7 Creación de una imagen de arranque en red

    La siguiente secuencia de comandos creará una imagen de arranque en red básica que contendrá el sistema estándar de Debian sin X.org. Se puede usar para el arranque en red.

    Nota: si se ha seguido algúno de los ejemplos anteriores, se tendrá que limpiar el directorio de trabajo con el comando lb clean:

    # lb clean --binary

    Ejecutar el comando lb config de la siguiente manera para configurar la imagen de arranque en red:

    $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"

    A diferencia de las imágenes ISO y USB/HDD, el sistema de arranque en red en sí mismo no envía la imagen del sistema de ficheros al cliente, por eso los ficheros se deben enviar mediante NFS. Las opciones --net-root-path y --net-root-server especifican la ubicación y el servidor, respectivamente, del servidor NFS en el que se encuentra la imagen del sistema de ficheros en el arranque. Se debe asegurar que estos se ajustan a los valores adecuados para la red y el servidor deseados.

    Crear ahora la imagen con el comando lb build:

    # lb build

    En un arranque en red, el cliente ejecuta una pequeña pieza de software que generalmente se encuentra en la EPROM de la tarjeta Ethernet. Este programa envía una solicitud de DHCP para obtener una dirección IP e información sobre qué hacer a continuación. Por lo general, el siguiente paso es conseguir un gestor de arranque de alto nivel a través del protocolo TFTP. Este gestor podría ser PXELINUX, GRUB, o incluso arrancar directamente un sistema operativo como Linux.

    Por ejemplo, si se descomprime el archivo generado binary-net.tar.gz en el directorio /srv/debian-live, se verá la imagen del sistema de ficheros en live/filesystem.squashfs y el kernel, initrd y el gestor de arranque pxelinux en tftpboot/debian-live/i386.

    Ahora se debe configurar tres servicios en el servidor para que arranque en red: el servidor DHCP, el servidor TFTP y el servidor NFS.

    4.7.1 Servidor DHCP

    Hay que configurar el servidor DHCP de red para asegurar que proporciona una dirección IP al cliente, y para anunciar la ubicación del gestor de arranque PXE.

    He aquí un ejemplo que puede servir de inspiración. Fue escrito para el servidor ISC DHCP isc-dhcp-server en su fichero de configuración /etc/dhcp/dhcpd.conf:

    # /etc/dhcp/dhcpd.conf - fichero de configuración para isc-dhcp-server

    ddns-update-style none;

    option domain-name "example.org";
    option domain-name-servers ns1.example.org, ns2.example.org;

    default-lease-time 600;
    max-lease-time 7200;

    log-facility local7;

    subnet 192.168.0.0 netmask 255.255.255.0 {
       range 192.168.0.1 192.168.0.254;
       next-server servername;
       filename "pxelinux.0";
    }

    4.7.2 Servidor TFTP

    Se encarga de suministrar el kernel y el Disco RAM inicial para el sistema.

    Se debe instalar el paquete tftpd-hpa. Este servidor podrá suministrar todos los ficheros contenidos de un directorio raíz, normalmente /srv/tftp. Para permitirle que pueda servir los ficheros de /srv/debian-live/tftpboot, se debe ejecutar el siguiente comando con privilegios de superusuario:

    # dpkg-reconfigure -plow tftpd-hpa

    y llenar el directorio del nuevo servidor tftp cuando sea requerido.

    4.7.3 Servidor NFS

    Una vez el equipo cliente ha descargado y arrancado el kernel de Linux junto a su initrd, intentará montar el sistema de archivos de la imagen en vivo a través de un servidor NFS.

    Se debe instalar el paquete nfs-kernel-server.

    Entonces, se debe hacer que la imagen del sistema de archivos esté disponible a través de NFS añadiendo una línea como la siguiente para /etc/exports:

    /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

    e informar al servidor NFS sobre esta nueva exportación con el siguiente comando:

    # exportfs -rv

    La configuración de estos tres servicios puede ser un poco difícil. Será necesario un poco de paciencia para conseguir que todos ellos funcionen juntos. Para obtener más información, ver el wiki de syslinux en ‹http://syslinux.zytor.com/wiki/index.php/PXELINUX› o la sección sobre TFTP Net Booting del Manual del Instalador de Debian en ‹http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html› Esto puede ser útil, ya que sus procesos son muy similares.

    4.7.4 Cómo probar el arranque en red

    La creación de una imagen de arranque en red es fácil usando la mágia de live-build, pero probar las imágenes en máquinas físicas puede ser un proceso mucho más lento.

    Para hacer nuestra vida más fácil, se puede utilizar la virtualización. Hay dos soluciones.

    4.7.5 Qemu
  • Install qemu, bridge-utils, sudo.
  • Se debe editar el fichero /etc/qemu-ifup:

    #!/bin/sh
    sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
    echo "Executing /etc/qemu-ifup"
    echo "Bringing up $1 for bridged mode..."
    sudo /sbin/ifconfig $1 0.0.0.0 promisc up
    echo "Adding $1 to br0..."
    sudo /usr/sbin/brctl addif br0 $1
    sleep 2

    Obtener o crear un grub-floppy-netboot (en el svn).

    Lanzar qemu con "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"

    4.7.6 VMWare Player
  • Instalar VMWare Player (Edición gratuita «free as in beer»)
  • Crear un directorio PXETester y crear un fichero de texto dentro llamado pxe.vwx
  • Copiar este texto dentro:
  • #!/usr/bin/vmware
    config.version = "8"
    virtualHW.version = "4"
    memsize = "512"
    MemAllowAutoScaleDown = "FALSE"

    ide0:0.present = "FALSE"
    ide1:0.present = "FALSE"
    floppy0.present = "FALSE"
    sound.present = "FALSE"
    tools.remindInstall = "FALSE"

    ethernet0.present = "TRUE"
    ethernet0.addressType = "generated"

    displayName = "Test Boot PXE"
    guestOS = "other"

    ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
    uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
    uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
    ethernet0.generatedAddressOffset = "0"

  • Se pueden realizar pruebas con este fichero de configuración (p.ej. cambiar el limite de memoria a 256)
  • Hacer doble clic en este fichero (o lanzar VMWare player y seleccionar este fichero).
  • Mientras esté en ejecución, si surge esa extraña pregunta, simplemente hay que pulsar «espacio» ...
  • 5. Descripción general de las herramientas

    Este capítulo contiene una descripción general de las tres herramientas principales utilizadas en la creación de sistemas Debian Live: live-build, live-boot y live-config.

    5.1 live-build

    live-build es una colección de scripts para generar los sistemas Debian Live. A estos scripts también se les conoce como «comandos».

    La idea detrás de live-build es ser un marco (framework) que utiliza un directorio de configuración para automatizar completamente y personalizar todos los aspectos de la creación de una imagen de un sistema en vivo.

    Muchos conceptos son similares a las del paquete de herramientas de Debian debhelper escrito por Joey Hess:

  • Los scripts tienen una ubicación central para la configuración de su funcionamiento. En debhelper, éste es el subdirectorio debian/ de un árbol de paquetes. Por ejemplo, dh_install buscará, entre otros, un fichero llamado debian/install para determinar qué ficheros deben existir en un paquete binario en particular. De la misma manera, live-build almacena toda su configuración bajo un subdirectorio config/.
  • Los scripts son independientes - es decir, siempre es seguro ejecutar cada comando.
  • A diferencia de debhelper, live-build contiene una herramienta para crear un directorio de configuración en esqueleto, lb config. Ésto podría ser considerado como similar a herramientas tales como dh-make. Para obtener más información sobre lb config, consultar El comando lb config

    El resto de esta sección describe los tres comandos más importantes:

  • lb config: Responsable de la creación de un directorio de configuración del sistema en vivo. Ver El comando lb config para más información.
  • lb build: Responsable de iniciar la creación de un sistema en vivo. Ver El comando lb build para más información.
  • lb clean: Responsable de la eliminación de partes de la creación de un sistema en vivo. Ver El comando lb clean para más información.
  • 5.1.1 El comando lb config

    Como se comentó en live-build, los scripts que componen live-build obtienen su configuración desde un único directorio llamado config/. Como la creación de este directorio a mano sería largo y propenso a errores, se puede utilizar el comando lb config para crear el esqueleto de directorios de configuración.

    Ejecutar lb config sin argumentos crea un subdirectorio config/ que se completa con algunas opciones por defecto y un árbol de subdirectorios en forma de esqueleto auto/:

    $ lb config
    P: Considering defaults defined in /etc/live/build.conf
    P: Creating config tree

    Usar lb config sin ningún argumento sería conveniente para los usuarios que necesitan una imagen muy básica, o que tienen intención de proporcionar más tarde una configuración más completa a través de auto/config (ver Gestionar una configuración para más detalles).

    Normalmente, se tendrá que especificar algunas opciones. Por ejemplo, para incluir la lista del paquete 'gnome' en la configuración:

    $ lb config -p gnome

    Es posible especificar muchas opciones, tales como:

    $ lb config --binary-images net --hostname live-machine --username live-user ...

    Una lista completa de opciones está disponible en la página del manual lb_config.

    5.1.2 El comando lb build

    El comando lb build lee la configuración del directorio config/. A continuación, ejecuta los comandos del nivel inferior más bajo necesarios para crear el sistema en vivo.

    5.1.3 El comando lb clean

    El comando lb clean es el encargado de eliminar varias partes de una creación de forma que las creaciones posteriores puedan comenzar de forma limpia. Por defecto se eliminan las etapas chroot, binary y source pero se deja el caché intacto. Además, se pueden limpiar etapas de forma individual. Por ejemplo, si se han realizado cambios que sólo afectan a la etapa binary, se debe usar lb clean --binary antes de crear una nueva binary. Ver el manual de lb_clean para una lista detallada de todas sus opciones

    5.2 El paquete live-boot

    live-boot es una colección de scripts que proporcionan scripts gancho (hooks) para initramfs-tools, que sirve para generar un initramfs capaz de arrancar los sistemas en vivo, tales como los creados por live-build. Ésto incluye las ISOs de Debian Live, archivos comprimidos en tar de netboot, e imágenes para llaves USB.

    En el momento del arranque, buscará en los medios de almacenamiento de sólo lectura un directorio /live/ donde se encuentra un sistema de ficheros raíz (a menudo una imagen del sistema de ficheros comprimidos como squashfs). Si lo encuentra, creará un entorno de escritura, utilizando aufs, para que arranquen los sistemas tipo Debian.

    Se puede encontrar más información sobre ramfs inicial en Debian en el Manual del kernel Debian Linux en ‹http://kernel-handbook.alioth.debian.org/› concretamente en el capítulo sobre initramfs.

    5.3 El paquete live-config

    live-config consiste en una serie de scripts que se ejecutan en el arranque después de live-boot para configurar el sistema en vivo de forma automática. Se ocupa de tareas como la creación del nombre del equipo (hostname), las variantes locales y la zona horaria, crear el usuario en vivo, la inhibición de trabajos de cron y el inicio de sesión automático del usuario en vivo.

    6. Gestionar una configuración

    Este capítulo explica como gestionar una configuración para crear un sistema en vivo desde el principio, pasando por sucesivas versiones tanto de la herramienta live-build como de la imagen del sistema en vivo propiamente dicha.

    6.1 Utilización de auto para gestionar los cambios de la configuración

    La configuración necesaria para crear un sistema en vivo rara vez es perfecta a la primera. Lo normal es que se necesite realizar una serie de revisiones hasta que se obtenga algo satisfactorio. Sin embargo, las inconsistencias pueden transmitirse de una revisión de la configuración a otra si no se es lo suficientemente cuidadoso. El principal problema es que, una vez que una variable de la configuración tiene un valor asignado, este valor no es recalculado en revisiones posteriores de la configuración. Esto hace que, si una variable depende del valor de otra y esta segunda cambia de valor, el valor actual de la primera no se ve alterado, debido a que ya tenía el valor asignado de antemano.

    Por ejemplo, la primera vez que se asigna la distribución a utilizar, se asigna a muchas variables un valor por defecto para adecuarse a la distribución seleccionada. Sin embargo, si posteriormente se decide modificar la distribución, estas variables dependientes continuan reteniendo los valores antiguos que, por supuesto, no son los adecuados para la nueva distribución.

    Otro problema es que la ejecución de la orden lb config no se reejecutará correctamente si se realiza una actualización a una nueva versión de las herramientas live-build que modifique el nombre de alguna variable de configuración. Además solamente podrá ser descubierto mediante una revisión manual de los ficheros del directorio config/* que se deberán modificar para asignar las variables de configuración a un nuevo valor apropiado.

    Todo esto sería un terrible embrollo si no fuese por los scripts auto/* simples envoltorios para los comandos lb config, lb build y lb clean que están diseñados para ayudar a la gestión de la configuración. Simplemente se debe crear un script llamado auto/config que contenga el comando lb config con todas las opciones que se deseen y otro script llamado auto/clean que elimine los ficheros que contienen los valores de las variables de configuración. Estos scripts se ejecutarán cada vez que se ejecuten los comandos lb config o lb clean de manera automática. Esto asegurará que la configuración se mantendrá consistente desde una versión a otra y desde una versión de las herramientas live-build a otra. (Aunque esto no elimina la necesidad de leer la documentación cuando se instale una nueva version de las herramientas live-build y quizás realizar algún ajuste manual en los ficheros de configuración).

    6.2 Un ejemplo de scripts auto.

    Se debe utilizar scripts auto similares a los ejemplos que se muestran a continuación como punto de partida para nueva configuración de las herramientas live-build. Hay que hacer notar que, cuando se ejecuta el comando lb dentro del script auto, se debe especificar la opción noauto para asegurar que el script auto no es vuelto a ejecutar repetitivamente. Tampoco se debe olvidar el asegurar que los scripts auto deben ser ejecutables (por ejemplo chmod 755 auto/*).

    auto/config

    #!/bin/sh
    lb config noauto \
         --package-lists "standard" \
         "${@}"

    auto/clean

    #!/bin/sh
    lb clean noauto "${@}"
    rm -f config/binary config/bootstrap \
         config/chroot config/common config/source
    rm -f binary.log

    auto/build

    #!/bin/sh
    lb build noauto "${@}" 2>&1 | tee binary.log

    Estos scripts auto vienen de serie con las herramientas live-build. Bastaría con copiar estos scripts como punto de partida.

    $ cp /usr/share/live/build/examples/auto/* auto/

    Se puede editar el script auto/config, modificándolo o añadiendo cualquier opción que se acomode a las necesidades requeridas. En el ejemplo anterior, se asignará la opción --package-lists standard como si fuese asignada por defecto. Se puede cambiar este valor a uno adecuado o simplemente eliminarlo si no es necesario añadiendo cualquier otra opción que se adecue a las necesidades requeridas por la imagen a crear, en líneas como las siguientes.

    7. Descripción general de la personalización.

    Este capítulo presenta un resumen de las diversas formas en que se puede personalizar un sistema Debian Live.

    7.1 Configuración en el momento de la creación vs en el momento del arranque

    Las opciones de configuración de un sistema Debian Live se pueden dividir en opciones que se aplican en el momento de la creación de la imágen del sistema en vivo y opciones que se tendrán en cuenta cuando el sistema en vivo arranque. Estas últimas se puenden dividir a su vez en opciones que se tienen en cuenta en una etapa inicial del arranque, utilizadas por el paquete live-boot, y otras que se aplicarán posteriormente y que son utilizadas por el paquete live-config. Cualquier opción en tiempo de arraque puede ser modificada por el usuario indicándola en los parámetros de arranque del kernel mediante el indicador de arranque (boot prompt). La imagen puede ser creada por defecto con los parámetros de arranque adecuados, de manera que los usuarios solamente tendrán que arrancar el sistema en vivo, directamente, sin necesidad de especificar ninguna opción adicional, ya que las opciones por defecto serán las adecuadas. En particular, la opcion lb --bootappend-live permite introducir cualquier parámetro del kernel para el sistema en vivo, como pueden ser la persistencia, distribución del teclado, zonas horarias, etc. Ver un ejemplo en Personalización de las variantes locales e idioma.

    Las opciones de configuración en tiempo de creación se describen en la página del manual del comando lb config. Las opciones en tiempo de arranque se describen en las páginas de manual de los paquetes live-boot y live-config. Aunque los paquetes live-boot y live-config se instalan en el sistema en vivo que se está creando, también se recomienda que sean instalados en el sistema huésped, que se utiliza para crear la imagen del sistema en vivo, con el fin de facilitar la referencia cuando se trabaja en una configuración. No hay ningún problema en hacerlo, ya que ninguno de los scripts que contiene el sistema huésped será ejecutado, a menos que se configure el sistema huésped como sistema en vivo, cosa que no tiene sentido.

    7.2 Etapas de la creación

    El proceso de creación de la imagen está dividido en etapas en las que se aplican diferentes personalizaciones en cada una de ellas. La primera etapa que se ejecuta es la etapa bootstrap. Esta fase inicial crea y rellena el directorio chroot con paquetes que constituyen un sistema Debian básico. A continuación la etapa chroot completa la creación del directorio chroot, rellenándolo con todos los paquetes que han sido listados en la configuración y material adicional. En esta etapa se utiliza la mayoría de las personalizaciones de contenido. La etapa binary es la etapa final en la que se prepara la imagen del sistema en vivo utilizando el contenido del directorio chroot para construir el sistema de ficheros raiz del futuro sistema en vivo, se incluye el instalador y cualquier otro material adicional de la imagen que no es parte el sistema de fichero raiz, como puede ser el gestor de arranque (bootloader) o ficheros de documentación. Posteriormente, en la etapa opcional source se creará el fichero comprimido (tarball) que contiene los ficheros de código fuente de los paquetes utilizados.

    En cada una de estas etapas hay una secuencia particular en la se aplican las acciones a realizar. Estas acciones son organizadas en forma de capas de tal manera que aseguran la personalización de una manera razonable. Por ejemplo, dentro de la etapa chroot, las preconfiguraciones (preseeds) se aplican antes que cualquier paquete sea instalado, los paquetes son instalados antes de incluir ningún fichero localmente o antes de aplicar cualquer parche y los scripts gancho (hooks) serán ejecutados al final de todo, una vez que todos los materiales están ubicados en su lugar.

    7.3 Opciones para lb config en ficheros

    Aunque la orden lb config crea un esqueleto de configuración en el directorio config/, quizás sea necesario escribir ficheros de configuración adicionales dentro de la jerarquía de subdirectorios de config/ con el fin de alcanzar los objetivos propuestos. En el proceso de creación de la imagen estos ficheros adicionales serán copiados o en el sistema de ficheros que se utilizará en el sistema en vivo, o en el sistema de ficheros de la propia imagen binaria o quizás podrán suministrar opciones de configuracion al sistema en vivo que sería incomodo pasar en la línea de parámetros del kernel. Esto dependerá de en qué parte de la jerarquía de subdirectorios de config/ se copian estos ficheros. Se puede incluir cosas como listas de paquetes personalizadas, imágenes gráficas personalizadas o scripts gancho (hook scripts) para ejecutar o en el momento de creación de la imagen o en el momento de arranque del sistema en vivo, aumentando la ya por otra parte considerable, flexibilidad de Debian Live con código creado ex profeso.

    7.4 Tareas de personalización

    Los siguientes capítulos se organizan por tareas de personalización que el usuario realiza típicamente: Los capítulos de Personalización de la instalación de paquetes, Personalización de contenidos y Personalización de las variantes locales e idioma cubre solamente unas pocas de las tareas que pueden realizarse.

    8. Personalización de la instalación de paquetes

    Quizás la tarea más básica de personalización en Debian Live es la selección de paquetes que serán incluidos en la imagen. Este capítulo orienta a través de las diferentes opciones de live-build que, en el momento de la creación de la imagen, personalizan la instalación de paquetes. Las opciones que seleccionan la distribucion base y las áreas del archivo Debian a utilizar son las que más influyen a la hora de conocer qué paquetes estarán disponibles para su instalación en la imagen. Para asegurar una buena velocidad de descarga de paquetes, se debería elegir el repositorio Debian más cercano. Se pueden añadir repositorios para paquetes backports, experimentales, paquetes personalizados o incluir ficheros de paquetes directamente. Se pueden definir listas de paquetes a incluir personalizadas, utilizar listas predefinidas en live-build, seleccionar tareas de tasksel o una combinación de los tres métodos. Por último existen varias opciones que dan algún control sobre cuando son instalados los paquetes por la herramienta apt o la herramienta aptitude, según sea la elegida. Estas opciones pueden ser útiles si se utiliza un proxy, se quiere desactivar la instalación de paquetes recomendados para ahorrar espacio o se necesita controlar las versiones de los paquetes a instalar mediante APT pinning, por nombrar algunas posibilidades.

    8.1 Origen de los paquetes
    8.1.1 Distribución, áreas de archivo y modo

    La distribución seleccionada tiene gran impacto en qué paquetes están disponibles para incluir en la imagen. Se debe indicar el nombre en clave de la distribución, que por defecto es wheezy para la versión Wheezy de live-build. Se puede especificar cualquier nombre de distribución disponible en los repositorios Debian indicando su nombre en clave. (Para más detalles ver Términos). La opción --distribution no solamente influencia la fuente de los paquetes dentro del archivo Debian, sino que instruye a live-build a comportarse tal y como se necesita para construir cada una de las distribuciones. Por ejemplo, para construir contra la versión *inestable*, Sid, se debe indicar:

    $ lb config --distribution sid

    Las áreas del archivo Debian son la principal división de paquetes dentro de una distribución dada. En Debian las áreas del archivo establecidas son main, contrib y non-free. Solamente los paquetes contenidos en main son parte de la distribución Debian. Ésta es el área definida por defecto en live-build. Se pueden indicar uno o más valores tal y como se muestra en el siguiente ejemplo:

    $ lb config --archive-areas "main contrib"

    Experimentalmente hay soporte para alguna distribución derivada de Debian mediante la opción --mode. Por defecto, esta opción toma el valor de debian incluso si live-build se está ejecutando en un sistema no Debian. Si se especifica --mode ubuntu o --mode emdebian se utilizará el nombre de la distribución y las áreas de archivos específicas de la distribución derivada en lugar de los propios de Debian y live-build modificará su comportamiento para adecuarlo al modo seleccionado.

    Nota: La ayuda a los usuarios de las distribuciones para las cuales se añadieron estos modos son responsabilidad de los desarrolladores de dichas distribuciones. El proyecto Debian Live proporciona ayuda al desarrollo de la mejor manera posible, basándose en la información recogida de dichas distribuciones derivadas a pesar de que no desarrolla ni da soporte a las mismas.

    8.1.2 Réplicas de Distribución Debian

    Los repositorios de Debian están replicados en una gran red alrededor del mundo, de manera que se puede seleccionar la réplica más cercana con el fin de obtener la mejor velocidad de descarga. Cada una de las opciones --parent-mirror-* gobierna qué réplica de repositorio Debian se utiliza en las diferentes etapas de creación. Si se recuerda de Etapas de la creación, en la etapa de *preinstalación (bootstrap)* es cuando se crea el directorio chroot y se rellena con un sistema mínimo mediante la herramienta debootstrap, y en la etapa *chroot* es cuando el directorio chroot es completado con los paquetes necesarios para crear el sistema de ficheros que será utilizado en el sistema en vivo. A cada una de estas etapas le corresponde su propia opción --parent-mirror-*. Posteriormente, en la etapa *binary* se utilizarán las réplicas Debian indicadas en los valores de las opciones --parent-mirror-binary y --parent-mirror-binary-security en lugar de utilizar los indicados para las etapas anteriores.

    8.1.3 Réplicas de Distribution utilizadas durante la creación

    Para indicar qué réplicas deben ser utilizadas en el momento de crear la imagen es suficiente con utilizar las opciones --parent-mirror-bootstrap , --parent-mirror-chroot-security y --parent-mirror-chroot-backports como se muestra a continuación.

    $ lb config --parent-mirror-bootstrap http://localhost/debian/ \
                 --parent-mirror-chroot-security http://localhost/debian-security/ \
          --parent-mirror-chroot-backports http://localhost/debian-backports/

    El valor indicado en --parent-mirror-chroot es utilizado como valor por defecto para la opción --parent-mirror-bootstrap si esta no es indicada.

    8.1.4 Réplicas de distribución Debian utilizadas en la ejecución.

    Las opciones --parent-mirror-binary* gobiernan las réplicas configuradas en la imagen binaria que serán utilizadas para instalar paquetes adicionales mientras se ejecuta el sistema en vivo. Por defecto se utiliza cdn.debian.net, que es un servicio que selecciona la réplica más cercana basándose en el número de IP. Es una elección bastante acertada siempre que no se pueda predecir que réplica será la mejor para todos los usuarios. También se puede especificar valores personalizados como se muestra en el siguiente ejemplo. Una imagen construida con esta configuración solamente sería accesible a los usuarios de una red donde "mirror" fuese alcanzable.

    $ lb config --parent-mirror-binary http://mirror/debian/ \
                 --parent-mirror-binary-security http://mirror/debian-security/

    8.1.5 Repositorios adicionales

    Se pueden añadir más repositorios, ampliando la lista de paquetes seleccionables más alla de aquellos disponibles para la distribución indicada, como pueden ser paquetes de backports, paquetes experimentales o personalizados. Para configurar repositorios adicionales se debe crear los ficheros config/archives/your-repository.list.chroot y/o config/archives/your-repository.list.binary. Al igual que en las opciones --parent-mirror-*, estos ficheros gobiernan los repositorios utilizados en las etapas *chroot* y *binary* respectivamente, esto es, los repositorios que serán utilizados cuando se ejecute el sistema en vivo.

    Por ejemplo, config/archives/live.list.chroot permite instalar paquetes de las instantáneas del repositorio Debian Live en el momento de crear la imagen.

    deb http://live.debian.net/ sid-snapshots main contrib non-free

    Si se añade la misma línea a config/archives/live.list.binary, el repositorio será añadido al directorio /etc/apt/sources.list.d/ del sistema en vivo.

    Estos ficheros serán seleccionados automáticamente si existen.

    Se debería también incluir en el fichero config/archives/your-repository.gpg.{binary,chroot} la clave GPG a utilizar para firmar dicho repositorio.

    Nota: Existen algunos repositorios de paquetes ya preconfigurados para facilitar la selección mediante la opción --archives. Por ejemplo, para utilizar las instantáneas del repositorio de Debian Live, sería suficiente con activarlo mediante:

    $ lb config --archives live.debian.net

    8.2 Selección de los paquetes a instalar

    Hay varias maneras de seleccionar qué paquetes serán instalados por live-build en la imagen que cubren una variedad de necesidades diversas. Se puede nombrar paquetes individuales para instalar en una lista de paquetes. También se puede seleccionar listas de paquetes predefinidos o incluso utilizar tareas de APT. Por último, también se pueden utilizar ficheros de paquetes de prueba o experimentales obtenidos antes de que aparezcan en los repositorios oficiales simplemente depositando estos ficheros directamente en el árbol de directorios config/.

    8.2.1 Listas de paquetes

    Las listas de paquetes proporcionan una potente forma de expresar qué paquetes deberían ser instalados. La sintaxis de la lista soporta la inclusión de ficheros y secciones condicionales, que facilitan la creación de listas a partir de otras listas, adaptando su utilización a diversas configuraciones. También pueden utilizarse listas de paquetes predefinidas, dando una manera modular a la selección de paquetes para cada uno de los diferentes entornos de escritorios y algunas listas de propósito especial basadas en otras listas de propósito general. Puede utilizarse listas propias o una combinación de listas propias y listas predefinidas.

    8.2.2 Listas de paquetes predefinidas

    La forma más simple de utilizar listas de paquetes es especificar una o más listas predefinidas mediante la opción --package-lists, por ejemplo:

    $ lb config --package-lists "gnome rescue"

    La ubicación por defecto de las listas de los ficheros en el sistema huésped es /usr/share/live/build/package-lists/. Para determinar qué paquetes componen una lista dada se debe leer el correspondiente fichero poniendo atención en los ficheros incluidos y en las secciones condicionales como se describen a continuación.

    8.2.3 Listas de paquetes locales

    Se pueden añadir o reemplazar completamente las listas predefinidas depositando listas de paquetes locales en el directorio config/package-lists/.

    Para que sean procesadas, las listas de paquetes que se depositen en este directorio deben tener la extensión .list además de la extensión de la etapa .chroot o .binary para indicar a qué etapa corresponde la lista.

    Nota: Si no se especifica el sufijo, la lista será usada en las dos etapas. En consecuencia, es conveniente especificar .list.chroot de modo que los paquetes se instalen únicamente en el sistema en vivo y no exista otra copia extra del paquete .deb

    8.2.4 Listas de paquetes locales para binary

    Para crear una lista para la etapa «binary» crear un fichero con el sufijo .list.binary en config/package-lists/. Estos paquetes no son instalados en el sistema en vivo, pero son incluidos en él en pool/. El uso típico de una de estas lista sería para una de las variantes de instalador normal («non-live» N.del T.). Tal y como se mencionaba anteriormente, si se desea usar la misma lista para la etapa «chroot» basta con solamente añadir el sufijo .list

    8.2.5 Extensión de una lista de paquetes dada mediante «includes»

    Las listas de paquetes predefinidas en live-build hacen un uso intensivo de las directivas «includes». Los ficheros existentes en el directorio /usr/share/live/build/package-lists/ pueden servir como buen ejemplo de como escribir listas de paquetes.

    Por ejemplo, para hacer una lista de paquetes que incluya la lista de paquetes predefinida gnome y añadir el paquete iceweasel se puede crear un fichero llamado config/package-lists/my.list.chroot con el siguiente contenido:

    #include <gnome>
    iceweasel

    8.2.6 Utilización de condiciones dentro de las listas de paquetes

    En las sentencias condicionales de las listas de paquetes pueden utilizarse cualquier variable disponible en config/* (excepto las que tienen el prefijo LB_). En general esto significa que puede utilizarse cualquier opción válida para lb config cambiando las letras minúsculas por mayúsculas y los guiones por subrayados. En la práctica solamente tiene sentido utilizar aquellas variables relacionadas con la selección de paquetes, como pueden ser DISTRIBUTION, ARCHITECTURE o ARCHIVE_AREAS.

    Por ejemplo, para instalar el paquete ia32-libs si se ha especificado la arquitectura amd64 (--architecture amd64) se puede utilizar:

    #if ARCHITECTURE amd64
    ia32-libs
    #endif

    En la expresión condicional pueden utilizarse varios valores. Por ejemplo para instalar el paquete memtest86+ si la arquitectura es i386 (--architecture i386) o es amd64 (--architecture amd64) se puede especificar:

    #if ARCHITECTURE i386 amd64
    memtest86+
    #endif

    En la expresión condicional también pueden utilizarse variables que pueden contener más de un valor. Por ejemplo para instalar vrms si se utilizan las áreas del archivo contrib o non-free mediante la opción --archive-areas se puede indicar:

    #if ARCHIVE_AREAS contrib non-free
    vrms
    #endif

    Es habitual que una condición incluya una directiva «include»:

    #if ARCHITECTURE amd64
    #include
    #endif

    No se permite el anidamiento de estructuras condicionales.

    8.2.7 Tareas

    El Instalador de Debian ofrece al usuario un conjunto de opciones con una lista de paquetes preseleccionada enfocadas a configurar un tipo de sistema o configurar el sistema para realizar una tarea como puede ser «Entorno de escritorio gráfico», «Servidor de correo», «Portátil», etc. Estas listas son llamadas «tareas» ("Tasks") y son soportadas por APT mediante el campo «Task:». Se puede especificar una o más tareas a live-build poniéndolas en una lista en config/task-lists/, como en el ejemplo siguiente.

    $ lb config
    $ echo "mail-server file-server" >> config/task-lists/my.list.chroot

    Una vez ha sido arrancado el sistema en vivo puede conocerse qué tareas primarias están disponibles en el Instalador de Debian mediante la orden tasksel --list-tasks. La lista de paquetes contenidos en cualquier tarea (incluidas aquellas que no aparecen en la lista de tareas primarias) puede obtenerse mediante la orden tasksel --task-packages.

    8.2.8 Tareas de Escritorio e Idioma

    Las tareas de escritorio y de idioma son casos especiales que necesitan un poco de planificación y configuración extra. Si el medio de instalación fue preparado para una clase particular de entorno de escritorio, el Instalador de Debian instalará automáticamente la tarea de entorno de escritorio correspondiente. Para ello existen las tareas internas gnome-desktop, kde-desktop, lxde-desktop y xfce-desktop pero ninguna de ellas son presentadas en el menú de tasksel. De igual forma, las tareas para idiomas tampoco son presentadas en el menú de tasksel, pero la selección del idioma, al inicio de la instalación repercute en la selección de las correspondientes tareas del idioma.

    Cuando se desarolla una imagen de escritorio, la imagen normalmente arranca directamente a un escritorio de trabajo, las opciones de escritorio y de idioma por defecto han sido elegidas en tiempo de creación, no en tiempo de ejecución como en el caso del instalador de Debian. Eso no quiere decir que una imagen en vivo no pueda ser creada para admitir múltiples escritorios o varios idiomas y ofrecer al usuario una elección, pero ese no es un comportamiento por defecto de live-build.

    Ya que no se ha previsto la instalación automática de tareas de idiomas, que incluyen cosas tales como tipos de letra específicos de cada lengua o paquetes de métodos de entrada, si se quiere incluirlos, es necesario especificarlo en la configuración. Por ejemplo, una imagen de escritorio GNOME que contenga soporte para el japonés podría incluir las siguientes tareas:

    $ lb config
    $ echo "gnome-desktop desktop standard laptop" >> config/task-lists/my.list.chroot
    $ echo "japanese japanese-desktop japanese-gnome-desktop" >> config/task-lists/my.list.chroot

    Ya que las tareas de escritorio son "internas", para cada tarea de sabor de escritorio incluido en la imagen, el valor correspondiente (si es diferente del predeterminado "gnome"), tiene que ser preconfigurado en la variable "tasksel/desktop" de lo contrario tasksel no lo va a reconocer e instalar. Por lo tanto:

    $ lb config
    $ echo 'tasksel tasksel/desktop multiselect kde' >> config/preseed/my.preseed.chroot

    Este parámetro puede tener varios valores, por ejemplo, "lxde xfce" en lugar de "kde".

    8.3 Instalar paquetes de terceros o paquetes modificados

    Si bien está en contra de la filosofía de Debian Live, en ocasiones es necesario crear un sistema en vivo con versiones de paquetes modificados a partir de los disponibles en el repositorio de Debian. Estos paquetes pueden modificar características existentes o dar soporte a características adicionales, idiomas y derivados (branding), o eliminar elementos existentes en los paquetes que no son de interes. De manera similar, se pueden incluir paquetes «de terceros» para añadir funcionalidades a medida o propietarias.

    En esta sección no se describe la creación o mantenimiento de paquetes personalizados. Puede ser interesante una lectura del método descrito por Joachim Breitner 'How to fork privately' en ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html›. La guía del nuevo desarrollador de Debian en ‹http://www.debian.org/doc/maint-guide/› describe la creación de paquetes a medida.

    Existen dos formas de instalar paquetes personalizados:

  • packages.chroot
  • Utilizando un repositorio APT personalizado
  • El método packages.chroot es el más simple para añadir paquetes personalizados. Es muy útil para personalizaciones «rápidas» (one-off) pero tiene unos cuantos inconvenientes mientras que la utilización de un repositorio APT personalizado es más lento de poner en marcha.

    8.3.1 Método packages.chroot para instalar paquetes personalizados

    Para instalar paquetes personalizados solamente hay que copiar el paquete en el directorio config/packages.chroot/. Los paquetes contenidos en este directorio serán automáticamente instalados en el sistema en vivo durante el proceso de creación. No es necesario especificar de dónde se deben obtener los paquetes.

    Los paquetes deben nombrarse de la forma prescrita. La forma más simple es usar dpkg-name.

    El método packages.chroot para la instalación de paquetes personalizados tiene desventajas:

  • No es posible utilizar APT seguro.
  • Se deben depositar todos los paquetes necesarios para cumplir dependencias en el directorio config/packages.chroot/.
  • No es adecuado para almacenar configuraciones de Debian Live en un control de versiones.
  • 8.3.2 Método de repositorio APT para instalar paquetes personalizados

    Al contrario del método packages.chroot, cuando se utiliza el método de repositorio APT personalizado se debe asegurar que se especifica dónde se deben buscar los paquetes a instalar. Para más información ver Selección de los paquetes a instalar.

    Aunque crear un repositorio APT para instalar paquetes personalizados puede parecer un esfuerzo innecesaro, la infraestructurar puede ser fácilmente reutilizada posteriormente para ofrecer nuevas versiones de los paquetes.

    8.3.3 Paquetes personalizados y APT

    live-build utiliza APT para instalar todos los paquetes en el sistema en vivo, así que hereda sus comportamientos. Un punto a resaltar es que (asumiendo una configuración de APT por defecto) dado un paquete en dos repositorios diferentes con diferentes números de versiones, APT seleccionará para instalar el paquete con número de versión superior.

    Esta sería una buena razón para incrementar el número de version en los ficheros debian/changelog de los paquetes personalizados y así asegurar que serán estos los paquetes instalados en lugar de los contenidos en los repositorios oficiales de Debian. Esto puede también lograrse alterando las preferencias de pinning de APT del sistema en vivo. Para más información ver APT pinning.

    8.4 Configurar APT en la creación

    Se puede configurar APT mediante varias opciones que se aplicarán en el momento de crear la imagen. (La configuración que APT utilizará cuando se ejecute el sistema en vivo puede ser configurada de la manera que habitualmente se utiliza para introducir contenidos del sistema en vivo, esto es, incluyendo las configuraciones apropiadas en el directorio config/includes.chroot/.) Se puede encontrar una lista completa de las opciones para configurar APT en la página de manual de lb_config. Son aquellas opciones que comienzan con apt.

    8.4.1 Utilizar apt o aptitude

    Se puede seleccionar qué herramienta se utilizará para instalar paquetes, apt o aptitude, en el momento de crear la imagen mediante la opción --apt de lb config. Esta selección definirá el comportamiento preferido en la instalación de paquetes, siendo la mayor diferencia la manera de tratar los paquetes no disponibles.

  • apt: Con este método, si se especifica un paquete no existente, la instalación fallará. Es el comportamiento por defecto.
  • aptitude: Con este método, si se especifica un paquete no existente, la instalación continuará sin error.
  • 8.4.2 Utilización de un proxy con APT

    Un problema habitual en la configuración de APT es tratar con la creación de una imagen desde detras de un proxy. Se puede especificar dicho proxy con las opciones --apt-ftp-proxy o --apt-http-proxy. Por ejemplo:

    $ lb config --apt-http-proxy http://proxy/

    8.4.3 Ajuste de APT para ahorrar espacio

    En ocasiones será necesario ahorrar algún espacio en el medio de instalación. Las dos opciones descritas a continuación pueden ser de interes.

    Si no se desea incluir los índices de APT en la imagen creada se puede utilizar la siguiente opción:

    $ lb config --apt-indices false

    Esto no modificará el comportamiento de las entradas definidas en /etc/apt/sources.list, sino que solo afecta a si exitirán o no ficheros de índice en el directorio /var/lib/apt. El compromiso viene de que APT necesita estos ficheros índices para funcionar en el sistema en vivo, así que, si no existen, el usuario deberá ejecutar la orden apt-get update para crear estos índices antes de poder ejecutar una orden del tipo apt-cache search o apt-get install.

    Si la instalación de los paquetes recomendados aumenta demasiado el tamaño de la imagen, se puede desactivar el valor por defecto de esta opción de APT con:

    $ lb config --apt-recommends false

    Lo que está en juego aqui es que, si no se instalan los paquetes recomendados para un paquete dado, esto es «los paquetes que supuestamente deberían encontrase intalados si un paquete ya lo está» (Debian Policy Manual, seccion 7.2), algún paquete que supuestamente debería estar instalado será omitido. Por otra parte, se sugiere que, si se desactiva esta opción, se revise las recomendaciones hechas a la lista de paquetes indicada (ver el fichero binary.packages generado por lb build) y que se incluya en la lista cualquier paquete que deba ser instalado. Si se encuentra que el número de paquetes descartado es pequeño, se recomienda que la opción se active y que se utilice una prioridad negativa para el pin de APT en dichos paquetes y así evitar que sean instalados tal y como se explica en APT pinning.

    8.4.4 Pasar opciones a apt o a aptitude

    Si no existe ninguna opción de lb config para alterar el comportamiento de APT tal y como se desea, se puede utilizar las opciones --apt-options o --aptitude-options para pasar cualquier opción que se desee a la herramienta APT. Para más información, ver las páginas de manual de apt y aptitude.

    8.4.5 APT pinning

    Como información básica, sería recomendable leer la página de manual apt_preferences(5). APT pinning puede ser configurado o en tiempo de creación de la imagen, creando el fichero config/chroot_apt/preferences o en tiempo de ejecución del sistema en vivo creando el fichero config/includes.chroot/etc/apt/preferences.

    Supongamos que se está creando un sistema en vivo basado en Wheezy pero se necesita instalar todos los paquetes "live" que terminan instalados en la imagen binaria final desde la versión inestable «Sid» en el momento de crear la imagen. Se deberá añadir Sid a los orígenes (sources) de APT y fijarlo (pin) de manera que solamente los paquetes fijados sean instalados desde Sid mientras que el resto será obtenido desde la distribución base, Wheezy. Esto se puede realizar de la siguiente forma:

    $ echo "deb http://mirror/debian sid main" > config/archives/sid.list.chroot
    $ cat >> config/chroot_apt/preferences < Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
    Pin: release n=sid
    Pin-Priority: 600

    Package: *
    Pin: release n=sid
    Pin-Priority: 1
    END

    Nota: Se pueden usar comodines en los nombres de los paquetes a fijar (p.ej. Package: live-*) si se usa una versión de apt igual o superior a 0.8.14. Esto significa que funciona con Wheezy usando:

    $ lb config --distribution wheezy

    Una prioridad pin negativa previene la instalación de un paquete, como puede ser el caso de que no se desee que un paquete recomendado por otro sea instalado al instalar el primero. Supongamos que se está creando una imagen LXDE mediante la opción --package-lists lxde, pero no se desea preguntar al usuario si desea almacenar las claves wifi en el almacen de claves. La lista lxde incluye gdm, la cual depende de gksu que a su vez recomienda gnome-keyring. Así que el objetivo es omitir la instalación del paquete gnome-keyring, que puede conseguirse añadiendo un fichero con el siguiente contenido a config/chroot_apt/preferences:

    Package: gnome-keyring
    Pin: version *
    Pin-Priority: -1

    9. Personalización de contenidos

    Este capítulo trata, no solamente de una mera descripción de cómo seleccionar los paquetes a incluir en el sistema en vivo, sino que además presenta cómo hacer el «ajuste fino» de la personalización de los contenidos del propio sistema. Los «añadidos» (includes) permiten adjuntar o reemplazar cualquier fichero en la imagen Debian Live a crear, los scripts gancho (hooks) permiten ejecutar cualquier orden en las diferentes etapas de creación y en el momento del arranque y por último, la preconfiguración permite configurar paquetes cuando son instalados, suministrando las respuestas a las preguntas de debconf.

    9.1 Includes

    Idealmente, un sistema Debain Live debería incluir solamente ficheros que son obtenidos de paquetes Debian no modificados. Sin embargo, algunas veces es conveniente incluir o modificar algún contenido mediante ficheros. La utilización de «añadidos» (includes) posibilita la inclusión, modificación o cambio de cualquier fichero en la imagen Debian Live a crear. live-build tiene tres mecanismos:

  • Includes locales en chroot : Estos includes permiten incluir o reemplazar ficheros del entorno chroot. Para más información ver Includes locales en Live/chroot
  • Includes locales en Binary: Estos includes permiten incluir o reemplazar ficheros en la propia imagen binaria generada. Para más información ver Includes locales en Binary
  • Includes en Binary: Estos includes permiten incluir o reemplazar ficheros específicos de Debian en la imagen binaria, como pueden ser plantillas o directorios de herramientas. Para más información ver Includes en Binary
  • Para más infomación acerca de la diferencia entre las imágenes "Live" y "binary" ver Términos

    9.1.1 Includes locales en Live/chroot

    Los includes locales en chroot se utilizan para incluir o reemplazar ficheros en el sistema de ficheros Live/chroot de manera que puedan ser utilizados en el sistema en vivo. Una utilización típica de estos Includes puede ser el rellenar el directorio (/etc/skel) del sistema en vivo para que sea utilizado en la creación del directorio home al dar de alta usuarios en el sistema en vivo. Otra utilización típica es suministrar ficheros de configuración que puedan ser incluidos o reemplazados en la imagen sin necesidad de realizar proceso alguno (Los ficheros son simplemente copiados sin realizar ningún proceso de los mismos para adecuarlos al sistema concreto. N. del T); Si se necesita realizar algún procesado de estos ficheros ver la sección Scripts gancho locales en Live/chroot

    Para incluir ficheros solamente hace falta añadirlos al directorio de configuración config/includes.chroot. Habrá una relación directa entre este directorio y el directorio raiz (/) del sistema en vivo. Por ejemplo, si se desea añadir un fichero para que sea el fichero /var/www/index.html del sistema en vivo se puede hacer lo siguiente:

    $ mkdir -p config/includes.chroot/var/www
    $ cp /path/to/my/index.html config/includes.chroot/var/www

    El directorio de configuración presentará la siguiente jerarquía:

    -- config
        [...]
         |-- includes.chroot
         |   `-- var
         |       `-- www
         |           `-- index.html
        [...]
         `-- templates

    Los includes locales en chroot serán instalados después de la instalación de los paquetes de manera que los includes sobreescribirán cualquier fichero que los paquetes puedan haber instalado.

    9.1.2 Includes locales en Binary

    Se puede incluir material como documentación, videos, etc en el sistema de ficheros del medio de instalación (USB, CDROM, etc) donde se grabará la imagen de manera que sea accesible nada más insertar el medio sin necesidad de arrancar el sistema en vivo. Para esto se utilizan los includes locales en Binary. Funciona de manera similar a los includes locales en chroot comentados anteriormente. Por ejemplo, supongamos que en el medio de instalación se desea añadir unos ficheros con videos de demostración ~/video_demo.* sobre el funcionamiento del sistema en vivo de manera que el usuario pueda acceder a ellos a través de la página de indice HTML. Simplemente se debe copiar el material en config/includes.binary/ de la siguiente manera:

    $ cp ~/video_demo.* config/includes.binary/

    Los ficheros aparecerán en el directorio raiz del medio desde el que se instalará el sistema en vivo.

    9.1.3 Includes en Binary

    live-build tiene algún fichero estandar, como puede ser la documentación, que se incluyen por defecto en el medio de instalación. Esto puede ser desactivado con:

    $ lb config --includes none

    Si no se utiliza esta opción, live-build instalará el material en el directorio /includes/ del sistema de ficheros del medio de instalación por defecto. En lugar de none, se puede especificar un directorio alternativo mediante la misma opción --includes.

    9.2 Scripts gancho (Hooks)

    Los scripts gancho permiten ejecutar órdenes para personalizar la imagen en las etapas chroot y binary.

    9.2.1 Scripts gancho locales en Live/chroot

    Para ejecutar órdenes en la etapa chroot se deben crear scripts gancho (hooks) con el sufijo .chroot que contengan dichas ordenes a ejecutar y depositarlos en el directorio config/hooks/. Estos scripts serán ejecutados en el entorno del chroot después de que el resto de las tareas de preparación del chroot han sido realizadas. Se debe asegurar que previamente se han instalado en el entorno chroot cualquier paquete, fichero u órden que necesiten los scripts gancho. El paquete live-build instala en el directorio /usr/share/live/build/examples/hooks del sistema huésped unos cuantos scripts gancho para realizar tareas habituales de personalización del entorno chroot que pueden ser copiados o referenciados mediante enlace simbólico en la propia configuración.

    9.2.2 Scripts gancho en tiempo de arranque

    Para ejecutar ordenes en el arranque del sistema en vivo, se puede suministrar scripts gancho a live-config depositándolos en el directorio config/includes.chroot/lib/live/config/, tal y como se explica en la sección de "Personalización" de la página de manual de live-config. Es interesante examinar los scripts gancho que trae de serie live-config que pueden verse en /lib/live/config/ y fijarse en la secuencia de números. Cuando se vaya a utilizar scripts propios deben ser prefijados con un número para indicar el orden de ejecución. Otra posibilidad es utilizar un paquete personalizado tal y como se describe en Instalar paquetes de terceros o paquetes modificados.

    9.2.3 Scripts gancho locales en Binary

    Para ejecutar comandos en la etapa Binary se deben crear scripts gancho con el sufijo .binary que contengan las ordenes y depositarlos en el directorio config/hooks/. Los scripts gancho se ejecutarán después de finalizar el resto de procesos de la etapa pero antes de crear los checksum con binary_checksum que es el último proceso que se ejecuta en esta etapa. Los scripts gancho no se ejecutan en el entorno del chroot, así que hay que tener cuidado de no modificar cualquier fichero fuera del árbol de creación, o se dañará el sistema de creación. En /usr/share/live/build/examples/hooks se pueden ver varios ejemplos de scripts gancho genéricos que permiten tareas de personalización para la etapa Binary. Estos scripts pueden ser utilizados en la propia configuración copiándolos o creando enlaces simbólicos.

    9.3 Preconfiguración de las preguntas de Debconf

    Los ficheros del directorio config/preseed/ con el sufijo .preseed seguido por la etapa (.chroot o .binary) son ficheros de preconfiguración para debconf. live-build instalará estos ficheros mediante debconf-set-selections durante la etapa correspondiente.

    Ver debconf(7) en el paquete debconf para obtener más información acerca de debconf.

    10. Personalización del comportamiento en tiempo de ejecución.

    Toda la configuración que se hace en tiempo de ejecución es realizada por live-config. Éstas son algunas de las opciones más comunes de live-config en las que los usuarios están más interesados. Se puede encontrar una lista completa de todas las posibilidades en la página del manual de live-config.

    10.1 Personalización del usuario por defecto del sistema en vivo

    Una consideración importante es que el usuario por defecto del sistema en vivo es creado por live-boot en el arranque y no live-build durante la creación de la imagen. Ésto no sólo influye dónde se introducen los materiales relacionados con este usuario durante la creación de la imagen tal y como se explica en Includes locales en Live/chroot sino también a cualquier grupo y a los permisos asociados con el usuario por defecto del sistema en vivo.

    Se puede especificar grupos adicionales a los que pertenecerá el usuario por defecto del sistema en vivo preconfigurando el valor debconf passwd/user-default-groups. Por ejemplo, para agregar el usuario al grupo fuse durante la etapa chroot, añadir el siguiente código en un fichero en el directorio config/preseed/.

    $ lb config
    $ echo user-setup passwd/user-default-groups string audio cdrom \
       dip floppy video plugdev netdev powerdev scanner bluetooth fuse \
       >> config/preseed/my.preseed.chroot

    Además, es posible cambiar el usuario por defecto "user" y la contraseña por defecto "live". Si se desea cambiarlos por cualquier motivo, se puede conseguir de forma sencilla tal y como se explica a continuación:

    Cambiar el nombre del usuario por defecto es tan sencillo como especificarlo en la configuración:

    $ lb config --bootappend-live "username=live-user"

    Una posible forma de cambiar la contraseña por defecto es usando un script gancho (hook) tal y como se describe en Scripts gancho en tiempo de arranque. Para conseguirlo se puede usar el script gancho «passwd» de /usr/share/doc/live-config/examples/hooks, ponerle un prefijo adecuado (p.ej. 200-passwd) y añadirlo a config/includes.chroot/lib/live/config/

    10.2 Personalización de las variantes locales e idioma

    Cuando el sistema en vivo arranca, el idioma está implicado en tres pasos:

  • Generar las variantes locales
  • Establecer la distribución del teclado para el consola
  • Establecer la distribución del teclado para el entorno gráfico X
  • La variante local predeterminada en la creación de un sistema en vivo es "locales=en_US.UTF-8". Para definir la variante local que se debe generar, se puede utilizar el parámetro locales en la opción --bootappend-live de lb config, p.ej.

    $ lb config --bootappend-live "locales=de_CH.UTF-8"

    Este parámetro también se puede utilizar en la línea de comandos del kernel. Se puede especificar una variante local usando una palabra completa language_country.encoding.

    Tanto la configuración del teclado de la consola y del entorno gráfico X dependen del parámetro keyboard-layouts de la opción --bootappend-live. Se pueden encontrar opciones válidas de la disposición del teclado en /usr/share/X11/xkb/rules/base.xml (bastante limitado a los códigos de país de dos letras). Para hallar el valor (los dos letras) que corresponde a un idioma se puede buscar el nombre en inglés de la nación donde se habla el idioma, por ejemplo:

    $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
    <name>se</name>

    Por ejemplo, para obtener los ficheros de la variante local de la disposición del teclado alemán y suizo-alemán en X usar:

    $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"

    Se puede ver una lista de los valores de teclados válidos para la consola con el siguiente comando:

    $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
         do basename $i | head -c -9; echo; done | sort | less

    Alternativamente, se puede usar el paquete console-setup una herramienta que permite configurar la disposición de la consola utilizando definiciones X (XKB), a continuación, se puede configurar el teclado con mayor precisión con las variables keyboard-layouts, keyboard-variant, keyboard-options y keyboard-model; live-boot también usará estos parámetros para la configuración de X. Por ejemplo, para establecer un sistema francés con una distribución de teclas francés-Dvorak (llamado Bepo) en un teclado TypeMatrix, tanto en consola X como X11, se puede utilizar:

    $ lb config --bootappend-live \
         "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"

    10.3 Persistencia (Modo guardar cambios)

    Un paradigma de un cd en vivo («live cd» N. del T.) es ser un sistema pre-instalado que funciona desde medios de almacenamiento de sólo lectura, como un CD-ROM, donde los cambios y las modificaciones no se guardan tras reiniciar el sistema en que se ejecuta.

    Un sistema Debian Live es una generalización de este paradigma pero que es compatible con otros medios de almacenamiento, no sólo en CDs. Aún así, en su comportamiento predeterminado, se debe considerar un sistema de sólo lectura y todos los cambios en tiempo de ejecución del sistema se pierden al apagar el equipo.

    La persistencia (o modo guardar cambios) es un nombre común que se dá a los diferentes tipos de soluciones para guardar algunos o todos los cambios realizados durante la ejecución tras reiniciar el sistema. Para entender cómo funciona es útil saber que incluso si el sistema se inicia y se ejecuta desde los medios de almacenamiento de sólo lectura, las modificaciones de los ficheros y directorios se escriben en medios de escritura, por lo general en la memoria ram (tmpfs) y los datos guardados en la ram no se guardan tras reiniciar.

    Los datos almacenados en esta memoria ram se pueden guardar en un soporte grabable como un disco duro, una memoria USB, un recurso compartido de red o incluso en una sesión de un CD/DVD regrabable en multisesión. Todos estos medios son compatibles con Debian Live de diferentes maneras, y todos menos el último requieren un parámetro de arranque especial que se especificará en el momento del arranque: persistent.

    10.3.1 Persistencia total

    Por «Persistencia total» se entiende la utilización de una partición de escritura en lugar de usar un tmpfs (sistema de ficheros temporal) para guardar los cambios realizados a los medios de sólo lectura (con el sistema copiar-al-escribir o COW «copy-on-write» N. del T.). Para utilizar esta función se debe crear una partición grabable vacía con la etiqueta «live-rw» formateada con un sistema de ficheros compatible en el medio usado para arracar el sistema en vivo. En el momento de arrancar se debe iniciar el sistema con el parámetro de arranque 'persistent'. Esta partición puede ser una partición ext2 en el disco duro o en una memoria USB creada con, por ejemplo:

    # mkfs.ext2 -L live-rw /dev/sdb1

    Ver Usar el espacio libre en el dispositivo USB.

    Si ya existe una partición en el dispositivo, sólo se tiene que cambiar la etiqueta con uno de los siguientes:

    # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems

    Pero ya que los usuarios de un sistema en vivo no siempre pueden utilizar una partición del disco duro, y teniendo en cuenta que la mayoría de memorias USB tienen velocidades de escritura lentas, la persistencia total también puede ser usada con ficheros imagen, de este modo se puede crear un fichero que represente una partición y poner ese fichero imagen incluso en una partición NTFS de un sistema operativo no nativo, con algo similar a esto:

    $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
    $ /sbin/mkfs.ext2 -F live-rw

    A continuación, copiar el fichero live-rw a un partición grabable y reiniciar el sistema con el parámetro de arranque «persistent».

    10.3.2 Montar Home de forma automática

    Si durante el arranque se encuentra una partición (sistema de ficheros) con un fichero imagen o una partición con la etiqueta home-rw el sistema de ficheros será montado de forma automática como /home, lo que permite la persistencia de los ficheros que pertenecen a, por ejemplo, el usuario por defecto. Se puede combinar con persistencia total.

    10.3.3 Instantáneas

    Las instantáneas son colecciones de ficheros y directorios que no se montan durante la ejecución, pero que se copian desde un dispositivo persistente al sistema (tmpfs) en el arranque y que se resincroniza en el reinicio/apagado del sistema. El contenido de una instantánea puede residir en una partición o en un fichero imagen (como los tipos mencionados anteriormente) con la etiqueta live-sn, pero el valor predeterminado es un archivo cpio simple denominado live-sn.cpio.gz. Como en el caso anterior, en el momento del arranque los dispositivos conectados al sistema se recorren buscando una partición o un fichero llamado así. Una interrupción de la alimentación en tiempo de ejecución podría conducir a la pérdida de datos, por lo tanto, se puede usar la herramienta live-snapshot --refresh para sincronizar cambios importantes. Este tipo de persistencia es la menos agresiva con dispositivos tipo flash y el más rápido de todos los sistemas de persistencia, ya que no escribe continuamente en los medios de almacenamiento.

    Existe también una versión de la instantánea /home y su etiqueta es home-sn.*; que funciona igual que la instantánea principal, pero sólo se aplica a /home.

    Las instantáneas actualmente no pueden manejar el borrado de ficheros pero la persistencia total y el montaje automático sí pueden.

    10.3.4 SubText persistente

    Si un usuario necesita un almacenamiento persistente múltiple del mismo tipo para diferentes lugares o pruebas, tales como live-rw-nonwork y live-rw-work, el parámetro de arranque persistent-subtext usado junto con el parámetro de arranque persistent permitirá medios de almacenamiento persistentes múltiples pero únicos. Un ejemplo sería si un usuario desea utilizar una partición persistente etiquetada live-sn-subText usaría los parámetros de arranque de: persistent persistent-subtext=subText.

    10.3.5 Remasterización parcial

    La modificación en tiempo de ejecución de la tmpfs podría ser guardada usando una instantánea en vivo en un squashfs y añadirla a un cd remasterizando la iso en el caso de un cd-r o añadiendo una sesión a un cd/dvd(rw) multisesión; live-boot monta todo el sistema de ficheros /live en orden o con el parámetro del módulo de arranque.

    11. Personalización de la imagen binaria

    11.1 Gestor de arranque

    live-build utiliza syslinux como gestor de arranque por defecto, el cual está configurado de forma predeterminada para hacer una pausa indefinida en su pantalla de bienvenida. Para modificar esto, se puede pasar --syslinux-timeout TIMEOUT a lb config. El valor se especifica en segundos. Un tiempo de espera de 0 (cero) desactiva el tiempo de espera por completo. Para obtener más información, consultar syslinux (1).

    11.2 Metadatos ISO

    Al crear una imagen binaria ISO9660 se pueden utilizar las siguientes opciones para añadir varios metadatos textuales a la imagen. Esto puede ayudar a identificar fácilmente la versión o la configuración de una imagen sin arrancarla.

  • LB_ISO_APPLICATION/--iso-application NAME: Esto debería especificar la aplicación que estará en la imagen. La longitud máxima para este campo es de 128 caracteres.
  • LB_ISO_PREPARER/--iso-preparer NAME: Esto debería identificar quién prepara la imagen, por lo general con algunos detalles de contacto. El valor predeterminado para esta opción es la versión de live-build que se está utilizando, lo que puede ayudar con la posterior depuración de errores. La longitud máxima para este campo es de 128 caracteres.
  • LB_ISO_PUBLISHER/--iso-publisher NAME: Esto debería identificar quién publica la imagen, por lo general con algunos detalles de contacto. La longitud máxima para este campo es de 128 caracteres.
  • LB_ISO_VOLUME/--iso-volume NAME: Esto debería especificar el volumen de identificación de la imagen. Esto se utiliza como etiqueta visible para el usuario en algunas plataformas como Windows y Apple Mac OS. La longitud máxima para este campo es de 32 caracteres.
  • 12. Personalización del Instalador de Debian

    Las imágenes de sistemas Debian Live pueden integrarse con el Instalador de Debian. Hay varios tipos de instalación que se diferencian en qué se incluye en la imágen y en cómo opera el instalador.

    En esta sección se debe estar atento a la utilización de las mayúsculas. Cuando se utiliza «Instalador de Debian», con mayúsculas, se hace referencia explícita al instalador oficial del sistema Debian, y a nada más ni a ningún otro instalador. A menudo se abrevia con «d-i».

    12.1 Tipos de imágenes según el instalador

    Principalmente existen tres tipos de imágenes según el instalador:

    Imágenes con Instalador Debian «official»: Esta imagen de Debian Live se puede considerar como la imagen habitual. Dispone de un kernel y un initrd diferenciados que, al ser seleccionados desde el gestor de arranque, ejecuta un Instalador de Debian estándar, de la misma manera que lo haría si se arrancase desde una imagen de CD descargada desde el sitio oficial de Debian. Las imágenes que contienen un sistema en vivo con otro instalador independiente se suelen llamar «imágenes combinadas».

    En estas imágenes, el sistema operativo Debian se instala mediante la herramienta debootstrap o cdebootstrap que descarga paquetes .deb, desde medios locales o por red local, y los instala de forma tradicional. El resultado final es un sistema Debian estándar instalado en el disco duro.

    El conjunto de este proceso puede ser preconfigurado (preseeded) y personalizado de muchas maneras; Para más información, ver las páginas relevantes en el manual del Instalador de Debian. Una vez que se ha generado el fichero de preconfiguración adecuado a las necesidades, live-build puede encargarse de depositarlo en la imagen y activarlo de forma automática.

    Imágenes con Instalador Debian «Live»: Estas imágenes de Debian Live también disponen de un kernel y un initrd diferenciados que, al ser seleccionados desde el gestor de arranque, ejecutan un Instalador de Debian algo diferente.

    El procedimiento de instalación es idéntico al realizado por las imagenes «Regulares» pero, en lugar de utilizar debootstrap para obtener e instalar paquetes .deb, lo que hace es copiar al disco duro la imagen del sistema de ficheros que se había preparado para lanzar el sistema en vivo. Esto se logra mediante un .udeb especial llamado live-installer.

    Una vez finalizada esta etapa, el Instalador de Debian continua normalmente, instalando y configurando los siguientes elementos como pueden ser gestor de arranque, creación de usuarios locales, etc.

    Nota: Para poder arrancar los dos tipos de imágenes, Regular y Live, en el mismo medio, el gestor de arranque debe poder deshabilitar live-installer. Esto se hace utilizando la variable de preconfiguración (preseed) live-installer/enable=false.

    Instalador Debian «del escritorio»: Una vez el sistema en vivo está ejecutandose, se puede lanzar el Instalador de Debian haciendo clic en el icono correspondiente, sin importar el tipo de Instalador Debian utilizado en el arranque. Esta manera de instalar Debian es más sencilla para el usuario y aconsejable en algunas situaciones. Para poder realizar esta acción se debe instalar el paquete debian-installer-launcher.

    Por defecto, live-build no incluye las imágenes que utilizan el Instalador de Debian. Esto debe ser habilitado de forma específica en lb config. También hay que hacer notar que, para que la instalación desde «el escritorio» funcione, el kernel del sistema en vivo debe ser el mismo que el kernel que utiliza d-i en la arquitectura especificada. Por ejemplo:

    $ lb config --architecture i386 --linux-flavours 486 \
         --debian-installer live
    $ echo debian-installer-launcher >> config/package-lists/my.list.chroot

    12.2 Personalizando el Instalador de Debian mediante preconfiguración

    Tal y como se describe en el apéndice B del manual del Instalador de Debian que puede consultarse en ‹http://www.debian.org/releases/stable/i386/apb.html›, «La preconfiguración permite asociar respuestas a preguntas que aparecen en el proceso de instalación, sin tener que responderlas manualmente en el momento se se ejecuta dicho proceso. Esto hace posible automatizar totalmente la mayoria de las instalaciones e incluso ofrece alguna característica que no está disponible durante una instalación normal.» Con live-build se puede llevar a cabo esta personalización depositando un fichero llamado preseed.cfg en el directorio de configuración config/binary_debian-installer/. Por ejemplo, para preconfigurar la variante local a es_ES se puede hacer:

    $ echo "d-i debian-installer/locale string es_ES" \
         >> config/binary_debian-installer/preseed.cfg

    12.3 Personalizar el contenido del Instalador de Debian

    Es posible que, con propósitos experimentales o para depuración de errores, se desee incluir paquetes udeb creados localmente para el d-i. Estos paquetes udeb son componentes del Instalador de Debian que definen su comportamiento. Para incluirlos en la imagen, basta con depositarlos en el directorio de configuración config/packages.binary/. También pueden incluirse o reemplazarse ficheros y directorios en el initrd del instalador de una manera similar a la que se describe en Includes locales en Live/chroot, depositando el material en el directorio config/binary_debian-installer-includes/.

    Proyecto

    13. Informes de errores.

    Debian Live está lejos de ser perfecto, pero queremos que sea lo más perfecto posible - con tu ayuda. No dudar en informar de un error: es mejor llenar un informe dos veces que no hacerlo nunca. Sin embargo, este capítulo incluye recomendaciones sobre cómo presentar buenos informes de errores.

    Para los impacientes:

  • Primero, siempre se debe comprobar el estado actualizado de la imagen en busca de problemas conocidos en la página web ‹http://live.debian.net/›.
  • Se debe intentar reproducir el error con las versiones más recientes de live-build, live-boot, y live-config antes de presentar un informe de errores.
  • Se debe intentar dar la información tan específica como sea posible acerca del error. Esto incluye (al menos) la versión de live-build, live-boot, y live-config utilizada y la distribución del sistema en vivo que está construyendo.
  • 13.1 Problemas conocidos

    Debido a que Debian testing y Debian unstable están cambiando continuamente, no siempre es posible crear un sistema con éxito cuando se especifica cualquiera de estas dos versiones.

    Si esto causa mucha dificultad, no se debe crear un sistema basado en testing o unstable, sino que debe utilizarse stable. Live-build siempre utiliza por defecto la versión stable .

    Los problemas detectados se especifican en la sección 'status' de la página web ‹http://live.debian.net/›.

    Está fuera del alcance de este manual enseñar cómo identificar y solucionar correctamente problemas de los paquetes de las distribuciones en desarrollo, sin embargo, hay dos cosas que siempre se puede intentar: Si se detecta un error de creación cuando la distribución de destino es testing, se debe intentar con unstable. Si unstable no funciona bien, se debe volver a testing haciendo un pin con la nueva versión del paquete de unstable (véase APT pinning para más detalles).

    13.2 Reconstruir desde cero

    Para asegurarse de que un error en particular no es causado por crear el sistema basándose en los datos de un sistema anterior, se debe reconstruir el sistema en vivo entero, desde el principio y comprobar si el error es reproducible.

    13.3 Utilizar paquetes actualizados

    Utilizar paquetes obsoletos puede causar problemas importantes al tratar de reproducir (y en última instancia, solucionar) el problema. Hay que asegurarse de que el sistema de construcción está actualizado y cualquier paquete que se incluya en la imagen esté también al día .

    13.4 Recopilar información

    Se debe proporcionar información suficiente con el informe. Como mínimo, la versión exacta de live-build donde se encuentra el error y los pasos para reproducirlo. Se debe utilizar el sentido común e incluir cualquier información pertinente si se cree que podría ayudar a resolver el problema.

    Para sacar el máximo provecho de un informe de errores, se requerirá al menos la siguiente información:

  • Arquitectura del sistema anfitrión
  • La versión de live-build del sistema anfitrión.
  • Versión de live-boot en el sistema en vivo.
  • Versión de live-config en el sistema en vivo.
  • Versión de debootstrap y/o cdebootstrap en el sistema anfitrión.
  • Arquitectura del sistema en vivo.
  • Distribución del sistema en vivo.
  • Versión del kernel en el sistema en vivo.
  • Se puede generar un log del proceso de creación mediante el comando tee. Se recomienda hacer esto de forma automática con un script auto/build; (ver Gestionar una configuración para más detalles).

    # lb build 2>&1 | tee build.log

    En el momento del arranque, live-boot guarda un log en /var/log/live.log (o /var/log/live-boot.log).

    Además, para descartar otros errores, siempre es una buena idea comprimir en un .tar el directorio config/ y subirlo a algún lugar, para que el equipo de Debian Live pueda reproducir el error (No se debe enviar como documento adjunto a la lista de correo). Si esto es difícil (por ejemplo, debido a su tamaño) se puede utilizar la salida del comando lb config --dump que produce un resumen del árbol de configuración (es decir, listas de archivos de los subdirectorios de config / pero no los incluye).

    Hay que recordar que los informes a enviar se deben hacer en ingles, por lo que para generar los logs en este idioma se debe utilizar la variante local English, p.ej. ejecutar los comandos de live-build o cualquier otro precedidos de LC_ALL=C o LC_ALL=en_US.

    13.5 Aislar el fallo si es posible

    Si es posible, aislar el caso del fallo al menor cambio posible que lo produzca. No siempre es fácil hacer esto, así que si no se consigue para su informe, no hay que preocuparse. Sin embargo, si se planea el ciclo de desarrollo bién, con conjuntos de cambios lo bastante pequeños por iteración, puede ser posible aislar el problema mediante la construcción de una simple «base» de configuración que se ajuste a la configuración actual deseada, más el conjunto del cambio que falla añadido. Si resulta difícil determinar que cambios produjeron el error, puede ser que se haya incluido demasiado en cada conjunto de cambios y se deba desarrollar en incrementos más pequeños.

    13.6 Utilizar el paquete correcto sobre el que informar del error

    ¿Dónde aparece el error?

    13.6.1 En la preinstalación (bootstrap) en tiempo de creación.

    live-build arranca primero un sistema Debian básico con debootstrap o cdebootstrap. Puede fallar dependiendo de la herramienta usada en la preinstalación y de la distribución Debian empleada. Si un error aparece en este momento, se debe comprobar si está relacionado con un paquete específico de Debian (es lo más probable), o si está relacionado con la herramienta de preinstalación en sí.

    En ambos casos, esto no es un error de Debian Live, sino de Debian en sí mismo, por lo cual el equipo de Debian Live no puede solucionarlo directamente. Informe del error sobre la herramienta de preinstalación o el paquete que falla.

    13.6.2 Mientras se instalan paquetes en tiempo de creación.

    live-build instala paquetes adicionales del archivo de Debian que pueden fallar en función de la distribución Debian utilizada y del estado diario del archivo Debian. Se debe comprobar si el error es reproducible en un sistema Debian normal, si el fallo aparece en esta etapa.

    Si este es el caso, esto no es un error de Debian Live, sino de Debian - se debe informar sobre el paquete que falla. Se puede obtener más información ejecutando debootstrap de forma separada del sistema de creación en vivo o ejecutando lb bootstrap --debug.

    Además, si se está utilizando una réplica local y/o cualquier tipo de proxy y se experimenta un problema, se debe intentar reproducir siempre preinstalando desde una réplica oficial.

    13.6.3 En tiempo de arranque

    Si la imagen no arranca, se debería informar la lista de correo, junto con la información solicitada en Recopilar información. No hay que olvidar mencionar, cómo y cuando la imagen falla, en Qemu, VirtualBox, VMWare o hardware real. Si se está utilizando una tecnología de virtualización de cualquier tipo, se debe probar la imagen en hardware real antes de informar de un error. Proporcionar una captura de pantalla del error también es muy útil.

    13.6.4 En tiempo de ejecución

    Si un paquete se ha instalado correctamente, pero falla cuando se ejecuta el sistema en vivo, esto es probablemente un error en Debian Live. Sin embargo,

    13.7 Hacer la investigación

    Antes de presentar el informe de errores, buscar en la web el mensaje de error en particular o el síntoma que se está percibiendo. Como es muy poco probable que sea la única persona que tiene ese problema en concreto, siempre existe la posibilidad de que se haya discutido en otras partes y exista una posible solución, parche o se haya propuesto una alternativa.

    Se debe prestar especial atención a la lista de correo de Debian Live, así como su página principal, ya que seguramente tienen la información más actualizada. Si esa información existe, se debe incluir la referencia a ella en su informe de errores.

    Además, se debe comprobar las listas de errores actuales de live-build, live-boot, y live-config y verificar si se ha informado ya de algo similar.

    13.8 Dónde informar de los fallos

    El proyecto Debian Live realiza un seguimiento de todos los errores en el sistema de seguimiento de fallos de Debian (BTS). Para obtener información sobre cómo utilizar el sistema, consultar ‹http://bugs.debian.org/›. También se puede enviar los errores mediante el comando reportbug del paquete con el mismo nombre.

    En general, se debe informar sobre los errores en tiempo de creación en el BTS contra el paquete live-build. De los fallos en el tiempo de arranque contra el paquete live-boot, y de los errores en tiempo de ejecución contra el paquete live-config. Si no se está seguro de qué paquete es el adecuado o se necesita más ayuda antes de presentar un informe de errores, lo mejor es enviar un mensaje a la lista de correo y el equipo de Debian Live le ayudará a resolverlo.

    Hay que tener en cuenta que los errores que se encuentran en las distribuciones derivadas de Debian (como Ubuntu y otros) NO deben enviarse al BTS de Debian a menos que también se puedan reproducir en un sistema Debian usando paquetes oficiales de Debian.

    14. Estilo de código

    En este capítulo se documenta el estilo de código utilizado en live-boot y otros.

    14.1 Compatibilidad
  • No utilizar sintaxis o semántica que sea única para el intérprete de comandos Bash. Por ejemplo, el uso de matrices.
  • Utilizar únicamente el subconjunto POSIX - por ejemplo, usar $(foo) en lugar de `foo`.
  • Se puede comprobar las secuencias de comandos con 'sh -n' y 'checkbashisms'.
  • 14.2 Sangrado
  • Utilizar siempre los tabuladores en lugar de espacios.
  • 14.3 Ajuste de líneas
  • En general, las líneas contienen 80 caracteres como máximo.
  • Utilizar los saltos de línea al «estilo Linux»:
  • Mal:

    if foo; then
             bar
    fi

    Bien:

    if foo
    then
             bar
    fi

  • Lo mismo vale para las funciones:
  • Mal:

    foo () {
             bar
    }

    Bien:

    foo ()
    {
             bar
    }

    14.4 Variables
  • Las variables deben escribirse siempre en letras mayúsculas.
  • Las variables que se utiliza en lb config siempre comienzan con el prefijo LB_
  • Las variables temporales internas del live-build deben comenzar con el prefijo _LB_
  • Las variables locales comienzan con el prefijo live-build __LB_
  • Las variables en relación a un parámetro de arranque en live-config comienzan con LIVE_.
  • Todas las demás variables de live-config comienzan con el prefijo _
  • Utilizar llaves para las variables, por ejemplo, escribir ${FOO} en lugar de $FOO.
  • Utilizar comillas dobles en las variables para evitar dejar espacios en blanco: Escribir "${FOO}" en lugar de ${FOO}.
  • Por motivos de coherencia, se debe utilizar siempre comillas en la asignación de valores a las variables:
  • Mal:

    FOO=bar

    Bien:

    FOO="bar"

  • Si se utilizan múltiples variables, incluir la expresión completa entre comillas dobles:
  • Mal:

    if [ -f "${FOO}"/foo/"${BAR}"/bar ]
    then
             foobar
    fi

    Bien:

    if [ -f "${FOO}/foo/${BAR}/bar" ]
    then
             foobar
    fi

    14.5 Miscelánea
  • Se debe utilizar "|" (sin comillas) como separador cuando se invoque a sed, p.ej. "sed -e 's|foo|bar|'" (Pero sin las comillas "")
  • No se debe utilizar el comando test para hacer comparaciones o pruebas, usar "[" "]" (sin ""); p.ej. "if [ -x /bin/foo ]; ..." en lugar de "if test -x /bin/foo; ...".
  • Se debe utilizar case siempre que sea posible en lugar de test, ya que es más fácil de leer y más rápido en la ejecución.
  • 15. Procedimientos

    Este capítulo documenta los procedimientos dentro del proyecto Debian Live para diversas tareas que requieren la cooperación con otros equipos de Debian.

    15.1 Subir Udebs

    Antes de enviar una nueva versión de un udeb al d-i svn, uno tiene que ejecutar:

    $ ../../scripts/l10n/output-l10n-changes . -d

    15.2 Principales lanzamientos

    El lanzamiento de una nueva versión estable de Debian involucra a una gran cantidad de equipos diferentes que trabajan juntos para conseguirlo. En un momento dado, el equipo Live aparece y desarrolla imágenes en vivo del sistema. Los requisitos para ello son:

  • Una réplica de las versiones publicadas de los archivos de debian, debian-security y debian-volatile a la que pueda acceder el programa creador de debian-live (live-build)
  • Es necesario conocer el nombre de la imagen (p.ej. debian-live-VERSION-ARCH-FLAVOUR.iso).
  • Es necesario haber actualizado la lista de paquetes.
  • Es necesario sincronizar los datos de debian-cd (lista de exclusión de udeb)
  • Es necesario sincronizar la lista de los paquetes de debian-cd incluidos (README.*, doc/*, etc.).
  • Las imágenes se crean y se almacenan en cdimage.debian.org.
  • 15.3 Nuevas versiones
  • Una vez más, se necesita una réplica actualizada de Debian, debian-security y debian-volatile.
  • Las imágenes se crean y se almacenan en cdimage.debian.org.
  • Correo para enviar anuncios.
  • 15.3.1 Plantilla para anunciar nuevas versiones.

    Se puede generar un anuncio de nuevas versiones usando la siguiente plantilla y el siguiente comando:

    $ sed \
         -e 's|%major%|5.0|g' \
         -e 's|%minor%|5.0.2|g' \
         -e 's|%codename%|lenny|g' \
         -e 's|%release_mail%|2009/msg00007.html|g'

    Revisar el mensaje de correo con cuidado antes de enviarlo a otras personas para su corrección.

    Imágenes de Debian en vivo para Debian GNU/Linux %major% actualizadas

    El proyecto Debian Live se complace en anunciar la disponibilidad de las imágenes en vivo actualizadas para su distribución estable de Debian GNU / Linux %major%
      (nombre en clave "%codename%").

    Las imágenes están disponibles para su descarga en:

         

    Esta actualización incorpora las modificaciones introducidas en la nueva versión, %minor%

    la cual añade correcciones para problemas de seguridad a la versión estable
    junto con algunos ajustes para problemas graves. Se puede consultar
    una lista completa de los cambios en:

         

    También incluye los siguientes cambios específicos del proyecto Live:

      * [INSERTAR CAMBIOS ESPECÍFICOS DEL PROYECTO LIVE AQUI]
      * [INSERTAR CAMBIOS ESPECÍFICOS DEL PROYECTO LIVE AQUI]
      * [LAS CUESTIONES MÁS IMPORTANTES PUEDEN MERECER SU PROPIA SECCIÓN]

    URLs
    ----

    Sitio de descarga de imágenes actualizadas:

       

    Página principal del proyecto Debian Live

       

    La distribución estable actual:

       

    Información acerca de la distribución estable (notas de publicación, errores, etc.):

       

    Anuncios de seguridad e información

       

    Acerca de Debian
    -------------

    El Proyecto Debian es una asociación de desarrolladores de Software Libre que
    ofrecen voluntariamente su tiempo y esfuerzo con el fin de producir el
    sistema operativo libre Debian GNU/Linux.

    Acerca de Debian Live
    -----------------

    Debian Live es un sub-proyecto oficial de Debian que produce sistemas
    Debian que no requieren una instalación clásica. Las imágenes están disponibles
    para CD/DVD, llaves USB y arranque en red PXE, así como
    imágenes de un sistema de ficheros básico para el arranque directamente desde Internet.

    Información de contacto
    -------------------

    Para más información, visitar las páginas web de Debian Live
    o bien enviar un correo a
    .

    Ejemplos

    16. Ejemplos

    Este capítulo ofrece ejemplos de creación de imágenes para casos de uso específicos de Debian Live. Si se es nuevo en la creación de una imagen propia de Debian Live, se recomienda mirar primero a los tres tutoriales en secuencia, ya que cada uno enseña nuevas técnicas que ayudan a utilizar y entender los ejemplos restantes.

    16.1 Uso de los ejemplos

    Para poder seguir estos ejemplos es necesario un sistema donde crearlos que cumpla con los requisitos enumerados en Requisitos y tener live-build instalado tal y como se describe en Instalación de live-build.

    Hay que tener en cuenta que, para abreviar, en estos ejemplos no se especifica una réplica local para la creación de la imagen. Es posible acelerar las descargas considerablemente si se utiliza una réplica local. Se puede especificar las opciones cuando se usa lb config, tal y como se describe en Réplicas de Distribution utilizadas durante la creación, o para más comodidad, establecer el valor por defecto para la creación del sistema en /etc/live/build.conf. Basta con crear este fichero y en el mismo, establecer las variables LB_PARENT_MIRROR_* correspondientes a la réplica preferida. Todas las demás réplicas usadas en el proceso de creación usarán estos valores por defecto. Por ejemplo:

    LB_PARENT_MIRROR_BOOTSTRAP="http://mirror/debian"
    LB_PARENT_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
    LB_PARENT_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates"

    16.2 Tutorial 1: Una imagen estándar

    Caso práctico: Crear una primera imagen sencilla, aprendiendo los fundamentos de live-build.

    En este tutorial, vamos a construir una imagen ISO hybrid por defecto de Debian Live que contenga únicamente los paquetes base (sin Xorg) y algunos paquetes de soporte Debian Live, como un primer ejercicio en el uso de live-build.

    No puede ser más fácil que esto:

    $ mkdir tutorial1 ; cd tutorial1 ; lb config

    Si se examina el contenido del directorio config/ se verá almacenada allí una configuración en esqueleto preparada para ser personalizada o en este caso para ser usada inmediatamente para construir una imagen por defecto.

    Ahora, como superusuario, crear la imagen, guardando un log con tee mientras se crea.

    # lb build 2>&1 | tee binary.log

    Suponiendo que todo va bien, después de un rato, el directorio actual contendrá binary-hybrid.iso. Esta imagen ISO híbrida se puede arrancar directamente en una máquina virtual como se describe en Probar una imagen ISO con Qemu y en Probar una imagen ISO con virtualbox-ose o bien ser copiada a un medio óptico como un dispositivo USB tal y como se describe en Grabar una imagen ISO en un medio físico y Copiar una imagen ISO híbrida en un dispositivo USB, respectivamente.

    16.3 Tutorial 2: Una utilidad de navegador web

    Caso práctico: Crear una utilidad de navegador web, aprendiendo a aplicar personalizaciones.

    En este tutorial, se creará una imagen adecuada para su uso como utilidad de navegador web, esto sirve como introducción a la personalización de las imágenes de Debian Live.

    $ mkdir tutorial2
    $ cd tutorial2
    $ lb config -p lxde
    $ echo iceweasel >> config/package-lists/my.list.chroot

    La elección de LXDE para este ejemplo refleja el deseo de ofrecer un entorno de escritorio mínimo, ya que el enfoque de la imagen es el uso individual que se tiene en mente, el navegador web. Se podría ir aún más lejos y ofrecer una configuración por defecto para el navegador web en config/includes.chroot/etc/iceweasel/profile/, o paquetes adicionales de soporte para la visualización de diversos tipos de contenido web, pero se deja esto como un ejercicio para el lector.

    Crear la imagen, de nuevo como superusuario, guardando un log como en el Tutorial 1:

    # lb build 2>&1 | tee binary.log

    De nuevo, verificar que la imagen está bien y probarla igual que en el Tutorial 1.

    16.4 Tutorial 3: Una imagen personalizada

    Caso práctico: Crear un proyecto para conseguir una imagen personalizada, que contenga el software favorito para llevárselo en una memoria USB donde quiera que se vaya, y hacerlo evolucionar en revisiones sucesivas, tal y como vayan cambiando las necesidades y preferencias.

    Como nuestra imagen personalizada irá cambiando durante un número de revisiones, si se quiere ir siguiendo esos cambios, probar nuevas cosas de forma experimental y posiblemente volver atrás si no salen bien, se guardará la configuración en el popular sistema de control de versiones git. También se utilizarán las mejores prácticas de configuración automática a través de scripts auto como se describe en Gestionar una configuración.

    16.4.1 Primera revisión

    $ mkdir -p tutorial3/auto
    $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
    $ cd tutorial3

    Editar auto/config del siguiente modo:

    #!/bin/sh

    lb config noauto \
         --architecture i386 \
         --linux-flavours 686-pae \
         --package-lists lxde \
         "${@}"

    Completar la lista de paquetes local:

    $ echo "iceweasel xchat" >> config/package-lists/my.list.chroot

    En primer lugar con --architecture i386 se asegura de que en nuestro sistema de creación amd64 se crea una versión de 32-bits adecuada para ser usada en la mayoría de máquinas. En segundo lugar, se usa --linux-flavours 686-pae porque no se espera usar esta imagen en sistemas mucho más viejos. En tercer lugar se elige la lista de paquetes lxde para proporcionar un escritorio mínimo. Y, por último, se añaden dos paquetes iniciales favoritos: iceweasel y xchat.

    Ahora, crear la imagen:

    # lb build

    Tener en cuenta que a diferencia de los dos primeros tutoriales, ya no se tiene que escribir 2>&1 | tee binary.log ya que esto se incluye ahora en auto/build.

    Una vez que se ha probado la imagen (como en el Tutorial 1) y se ha asegurado de que funciona, es el momento de iniciar el repositorio git, añadiendo sólo los scripts auto que se acaba de crear, y luego hacer el primer commit:

    $ git init
    $ git add auto
    $ git commit -a -m "Initial import."

    16.4.2 Segunda revisión

    En esta revisión, vamos a limpiar desde la primera creación, agregar el paquete vlc a nuestra configuración, crear de nuevo, probar y enviar los cambios al git.

    El comando lb clean limpiará todos los ficheros generados en las primeras creaciones a excepción del caché, lo cual ahorra tener que volver a descargar de nuevo los paquetes. Esto asegura que el siguiente lb build vuelva a ejecutar todas las fases para regenerar los ficheros de nuestra nueva configuración.

    # lb clean

    Añadir ahora el paquete vlc a nuestra lista de paquetes local en config/package-lists/my.list.chroot:

    $ echo vlc >> config/package-lists/my.list.chroot

    Crear de nuevo:

    # lb build

    Probar, y cuando se esté satisfecho, enviar la próxima revisión al git:

    $ git commit -a -m "Adding vlc media player."

    Por supuesto, es posible hacer cambios más complicados en la configuración, tal vez añadiendo ficheros en los subdirectorios de config/. Cuando se envian nuevas revisiones, hay que tener cuidado de no editar a mano o enviar los ficheros del nivel superior en config que contienen variables LB_* ya que estos son productos de creación también y son siempre limpiados por lb clean y recreados con lb config a través de sus respectivos scripts auto.

    Hemos llegado al final de nuestra serie de tutoriales. Si bien son posibles muchos más tipos de personalización, aunque sólo sea con las pocas características explicadas en estos sencillos ejemplos, se puede crear una variedad casi infinita de imágenes diferentes. Los ejemplos que quedan en esta sección abarcan varios casos de usos diferentes procedentes de las experiencias recogidas de los usuarios de Debian Live.

    16.5 Un cliente VNC kiosk

    Caso Práctico: Crear una imagen con live-build para arrancar directamente un servidor VNC.

    Hacer un directorio de creación y crear una configuración en esqueleto según la lista estándar-x11, incluyendo gdm3, metacity y xvnc4viewer, desactivando los paquetes recomendados para conseguir un sistema mínimo:

    $ mkdir vnc_kiosk_client
    $ cd vnc_kiosk_client
    $ lb config -a i386 -k 686-pae -p standard-x11 \
         --apt-recommends false
    $ echo "gdm3 metacity xvnc4viewer" >> config/package-lists/my.list.chroot

    Crear el directorio /etc/skel y poner un fichero .xsession personalizado para el usuario que por defecto ejecutará metacity e iniciará el xvncviewer, conectándo al puerto 5901 de un servidor en 192.168.1.2:

    $ mkdir -p config/includes.chroot/etc/skel
    $ cat > config/includes.chroot/etc/skel/.xsession < #!/bin/sh

    /usr/bin/metacity &
    /usr/bin/xvncviewer 192.168.1.2:1

    exit
    END

    Crear la imagen:

    # lb build

    Disfrutar.

    16.6 Una imagen básica para un pendrive USB de 128M

    Caso Práctico: Crear una imagen estándar quitando algunos componentes para que quepa en un pendrive USB de 128M dejándo espacio libre para poder usarlo.

    Al optimizar una imagen para adaptarla al tamaño de algunos medios de almacenamiento, es necesario comprender el equilibrio que se está haciendo entre tamaño y funcionalidad. En este ejemplo, se recorta tanto sólo para dar cabida a material adicional dentro de un tamaño de 128M, pero sin hacer nada para destruir la integridad de los paquetes que contiene, tales como la depuración de las variantes locales a través del paquete localepurge u otro tipo de optimizaciones «intrusivas». Cabe destacar que no se debe usar --bootstrap-flavour minimal a menos de que realmente se sepa lo que se está haciendo, ya que al omitir paquetes de prioridad importante lo más probable es que se produzca un sistema roto.

    $ lb config -k 486 -p minimal --apt-indices false \
         --memtest none --apt-recommends false --includes none

    Ahora, crear la imagen de forma habitual:

    # lb build 2>&1 | tee binary.log

    En el sistema del autor, en el momento de escribir esto, la configuración anterior produjo una imagen de 78Mbytes. Esto se compara favorablemente en tamaño con la imagen de 166Mbytes producida por la configuración por defecto en el Tutorial 1.

    El mayor ahorro de espacio aquí, en comparación con la creación de una imagen estándar en un sistema de arquitectura i386 es seleccionar sólo la versión del kernel 486 en lugar de la de por defecto -k "486 686-pae". Dejar fuera los índices de APT con --apt-indices false también ahorra una cantidad importante de espacio, la desventaja es que es necesario hacer un apt-get update antes de usar apt en el sistema en vivo. Elegir la lista del paquete minimal deja fuera el gran paquete de locales y sus utilidades asociadas. Dejando los paquetes recomendados con --apt-recommends false se ahorra un poco de espacio adicional a costa de omitir algunos paquetes que de otro modo podría esperarse que estuvieran alli, tal como firmware-linux-free que puede ser necesario para el soporte de cierto hardware. Las opciones restantes recortan pequeñas cantidades adicionales de espacio. Es necesario decidir si vale la pena la funcionalidad que se sacrifica con cada optimización.

    16.7 Un escritorio KDE con variante local e instalador

    Caso práctico: Crear una imagen del escritorio KDE, con la variante local Portugués de Brasil con instalador incluido.

    Se desea crear una imagen iso-hybrid para la arquitectura i386 con un escritorio preferido, en este caso el KDE, que contiene todos los mismos paquetes que serían instalados por el programa de instalación estándar de Debian para KDE.

    El primer problema es descubrir los nombres de las tareas adecuadas. En la actualidad, live-build no puede ayudar en esto. Aunque podríamos tener suerte y encontrarlos a base de pruebas, hay una herramienta, grep-dctrl, para extraerlos de las descripciones de tareas en tasksel-data, para proceder, asegurarse de tener ambas cosas:

    # apt-get install dctrl-tools tasksel-data

    Ahora podemos buscar las tareas apropiadas, primero con:

    $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese

    Con este comando, se descubre que la tarea se llama, sencillamente, brazilian-portuguese. Ahora para encontrar las tareas relacionas:

    $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese-desktop
    Task: brazilian-portuguese-kde-desktop

    En el momento del arranque se van a generar las variantes locales pt_BR.UTF-8 y seleccionar la distribución del teclado pt-latin1. También será necesario preconfigurar la opción de escritorio, "kde" para que tasksel instale la tarea de escritorio correcta, ya que difiere de la de por defecto (Ver Tareas de Escritorio e Idioma). Ahora vamos a poner las piezas juntas:

    $ mkdir live-pt_BR-kde
    $ cd live-pt_BR-kde
    $ lb config \
         -a i386 \
         -k 486 \
         --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
         --debian-installer live
    $ echo kde-desktop brazilian-portuguese brazilian-portuguese-desktop \
         brazilian-portuguese-kde-desktop >> config/task-lists/my.list.chroot
    $ echo debian-installer-launcher >> config/package-lists/my.list.chroot
    $ echo tasksel tasksel/desktop multiselect kde >> config/preseed/my.preseed.chroot

    Tener en cuenta que se ha incluido el paquete debian-installer-launcher para lanzar el instalador desde el escritorio en vivo, y que también se ha especificado el kernel 486, ya que actualmente es necesario que el instalador y el kernel del sistema en vivo coincidan para que el lanzador funcione correctamente.




    Debian -->
    [ document manifest ]