Centro de Software en Debian necesita ayuda o será retirado.

Centro de Software de Canaima

En un correo reciente enviado a la Lista de Desarrolladores de Debian se ha solicitado ayuda (RFH, Request For Help) para continuar manteniendo el relativamente nuevo Centro de Software (software-center) importado desde Ubuntu, o en caso contrario para eliminarlo por completo.

En el mencionado correo, Julian Andres Klode, mantenedor del paquete “software-center” señala que no cuenta con los días (o quizás semanas) necesarios para hacer funcionar la última versión de esta aplicación.

Luego de recordar muy brevemente para qué sirve el Centro de Software, Julian explica que este paquete es horriblemente específico para Ubuntu y aunque necesita ser actualizado para Debian, el mismo se ha vuelto cada vez más específico para Ubuntu, esta situación hace que sea mucho más complicado adaptarlo a otras distribuciones.

La recién liberada versión 4.0 de Canaima integra este Centro de Software, y de hecho, por el requerimiento específico de que Canaima quepa en un CD de apenas 700MB de capacidad, otras herramientas como el Gestor de Paquetes “Synaptic” fueron descartadas en favor de dejar un instalador de software único y sencillo para los usuarios comunes. Es en este punto que esta noticia se hace importante para el desarrollo de las siguientes versiones de Canaima.

Si la solicitud de ayuda realizada por el mantenedor del Centro de Software no logra conseguir nuevos colaboradores, entonces dentro de Canaima deberemos debatir entre dos opciones:

  1. Continuar importando las nuevas versiones del Centro de Software directamente desde Ubuntu: Implica una carga de desarrollo adicional porque los paquetes que son mantenidos por la comunidad de Debian, llevan adelantadas muchas adaptaciones necesarias para que los mismos funcionen.
  2. Cambiar a otras herramientas de gestión de software: No es una idea descabellada, sin embargo, el Centro de Software brinda características de “usabilidad” que otras herramientas no tienen. En estos momentos en Debian, la herramienta que más se acerca es PackageKit.
Centro de Software en Debian necesita ayuda o será retirado.

Recuperar un Canaima GNU/Linux que se quedó Colgado

Tecla "Prt Scr/SysRq"

Hay ocasiones en que por alguna u otra razón el sistema operativo se nos queda colgado, es decir que no hace nada, no responde a las acciones que le pedimos que haga. En esos casos, gracias a la potente modularización del Kernel de Linux todavía podemos tomar acciones para hacer un reinicio seguro con el teclado.

Peticiones al Sistema (SysRq)

Las peticiones al sistema son comandos que podemos realizar con el teclado utilizando algunas combinaciones de teclas específicas. Las combinaciones son varias, pero en este caso sólo explicaré las necesarias para reiniciar de forma segura el sistema durante un cuelgue.

Tecla "Impr Pant/PetSis"La actríz principal en este cuento es la tecla “Impr Pant / PetSis” (Imprimir Pantalla / Petición al Sistema) que en inglés es conocida como “Prt Scr / SysRq” (Print Screen / System Request). Esta es la tecla que nos permitirá hacer los llamados al sistema.

Para hacer un reinicio de emergencia debemos presionar las siguientes combinaciones de teclas:

Ctrl + Alt + PetSis + r    unRaw        Toma el control del teclado
Ctrl + Alt + PetSis + e    tErminate*   Termina todos los procesos
Ctrl + Alt + PetSis + i    kIll*        Mata los procesos que no terminaron
Ctrl + Alt + PetSis + s    Sync         Sincroniza los datos en los discos
Ctrl + Alt + PetSis + u    Umount       Desmonta los discos
Ctrl + Alt + PetSis + b    reBoot       Reinicia el sistema

Esto lo puedes lograr también dejando presionadas las teclas Ctrl + Alt + PetSis mientras marcas en orden las demás teclas una a una (r, e, i , s, u, b).

Activar Terminate y Kill en Canaima (opcional)

En Canaima no están disponibles los comandos E (Terminate) ni I (Kill) de forma predeterminada. Estos hay que activarlos manualmente si queremos que al presionarlos funcionen. Esto es un paso opcional porque si utilizamos sólo la combinación de los comandos que sí funcionan (r, s, u, b) también nos servirá.

La utilidad de los comandos Terminate (e) y Kill (i) es que podremos cerrar de forma segura las aplicaciones que estén corriendo en ese momento, evitando aún más una posible perdida de datos.

Para activarlos sólo debemos ejecutar este comando como root:

echo 1 > /proc/sys/kernel/sysrq

De este modo nos aseguramos que en caso de emergencia, podremos ejecutar la combinación de teclas completa y evitaremos así en lo más posible una lamentable pérdida de datos.

Recuperar un Canaima GNU/Linux que se quedó Colgado

Configurar Teclas de Brillo en Canaimita (Magalhaes MG101A3)

Teclas de Brillo en Canaimita Magalhaes MG101A3

Cuando se hace una instalación clásica de Canaima en un equipo Magalhaes (Mejor conocido en Venezuela como Canaimita), sucede que las teclas de función que modifican el brillo de la pantalla (Fn+F7,  Fn+F8 y Fn+F10) no funcionan. Esto me ha pasado con las versiones de Canaima 3.0, 3.1, 4.0 y actualmente con Debian Jessie, lo cual quiere decir que esto sucede con los kernels 2.6.32, 3.2.0 y 3.11.

Observando que a pesar de que las versiones del Kernel han ido avanzando y este problema no se ha corregido, comencé a indagar si es que nadie lo había reportado o simplemente se trata de algún tipo de configuración o software que hace falta para que funcione. En ese punto me encontré con un reporte hecho a los propios desarrolladores del Kernel de Linux y hallé en él la solución al problema.

El problema se debe a que hace falta configurar el servidor X para que reconozca con cual Interfáz de Brillo de Pantalla (Backlight) debe intereactuar.

Para solucionarlo sólo debemos hacer lo siguiente:

  1. Crear el archivo /etc/X11/xorg.conf si es que hasta el momento no existe en nuestro sistema.
  2. Dentro de este archivo debemos escribir la siguiente configuracion:
    Section "Device"
            Option        "Backlight"  "cmpc_bl"
            Identifier    "Card0"
            Driver        "intel"
            BusID        "PCI:0:2:0"
    EndSection
  3. Una vez terminado, sólo nos queda guardar y reiniciar el sistema.

Al volver a inicar podremos comprobar que las teclas de función para modificar el brillo de pantalla están funcionando correctamete.

Notificación de Brillo en Gnome Shell

Haber llegado a esta solución me llena de mucha alegría ya que me había estado afectando desde hace bastante tiempo y sé que facilitará al equipo técnico de Canaima Educativo todo el proceso de generación del sistema, porque normalmente les lleva trabajo generar un Kernel personalizado para que (entre otras cosas) active esta funcionalidad.

NOTA: Si por alguna razón luego de crear el archivo /etc/X11/xorg.conf tenemos problemas con los gráficos del sistema simplemente con borrarlo debería quedar todo como antes.

Configurar Teclas de Brillo en Canaimita (Magalhaes MG101A3)

RecordMyDesktop en Gnome 3 Shell

En algunas versiones de Gnome Shell y RecordMyDesktop ocurre un problema singular al iniciar el proceso de grabación, en el cual el panel superior se desaparece y nos deja imposibilitado de hacer muchas cosas.

La solución la he encontrado en un video de Youtube donde explican que lo único que hay que hacer es desabilitar 2 opciones.

Para ello en primer lugar abrimos la aplicación RecordMyDesktop, luego hacemos click en el botón “Avanzado”. Se nos desplegará un cuadro de dialogo donde seleccionaremos la pestaña “Miscelánea”. En ese punto debemos DESACTIVAR las opciones:

  • Contorno en el área de captura de pantalla.
  • Inicializar el área de captura.

Una vez realizado este paso, ya podremos grabar sin problemas nuestro escritorio en Gnome Shell.

Configuración RecordMyDesktop en Gnome 3 Shell

RecordMyDesktop en Gnome 3 Shell

Cifrar Particiones Home y Swap

Cifrar
Recientemente recibimos una recomendación de proveer a los usuarios la posibilidad de instalar Canaima en particiones cifradas, es por ello que hicimos un pequeño recorrido por internet buscando algnos pasos sencillos que nos permitieran evaluar mejor el caso.

Gracias a esa investigación llegamos a un proceso que, debido a su relativa sencillez y la también relativa facilidad de integración con el instalador de Canaima, voy a describir acá de forma muy somera a modo de recordatorio y para que cualquiera que tenga algún tipo de recomendación sobre el proceso realizado pueda dar su opinión a través de los comentarios.

En este ejemplo supondremos que los dispositivos a utilizar son:

/dev/sda1 Como partición para el Home
/dev/sda5 Como partición Swap

Instalar paquetes necesarios:

# apt-get install cryptsetup

Desmontar el Home o el Swap dependiendo de que partición se vaya a cifrar:

# umount /dev/sda1 (Para el caso del /home)
# swapoff /dev/sda5 (Para el caso del swap)

Ciframos el dispositivo:

# cryptsetup --verbose --verify-passphrase luksFormat /dev/sda1
# cryptsetup --verbose --verify-passphrase luksFormat /dev/sda5

Abrimos el dispositivo cifrado y le asignamos un dispositivo virtual que puede llamarse como desees:

# cryptsetup luksOpen /dev/sda1 home-cifrado
# cryptsetup luksOpen /dev/sda5 swap-cifrado

Ahora pasaremos a darle formato a las nuevas particiones cifradas:

# mkfs.ext4 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/home-cifrado
# mkswap /dev/mapper/swap-cifrado swap

Cerramos las particiones cifradas:

# cryptsetup luksClose home-cifrado
# cryptsetup luksClose swap-cifrado

Configuramos las particiones para que se monten al inicio del sistema, como cualquier otra partición (con la diferencia que nos pedirá clave). Para ello, añadimos una entrada en /etc/crypttab:

# vim /etc/crypttab

home-cifrado /dev/sda1 none luks
swap-cifrado /dev/sda5 none luks,swap

Por ultimo es necesario agregar los datos del montaje en el archivo /etc/fstab:

# vim /etc/fstab

/dev/mapper/home-cifrado /home ext4 defaults 0 2
/dev/mapper/swap-cifrado none swap sw 0 0

Como se lo comenté arriba esto es un resumen, sin mayor detalles sobre los comandos utilizados. La intención es tenerlo en mente, tenerlo cerca también ya que este proceso pretendemos incorporarlo al instalador de Canaima.

Para dudas y recomendaciones deja en este artículo tus comentarios.

Cifrar Particiones Home y Swap

Funcionamiento de Jockey en Canaima

En este apartado explicaremos el funcionamiento de la aplicación Jockey de Canaima, por algunos conocida como el detector automático de Hardware. Este proceso de detección se refiere a poder determinar de forma automatizada cuales dispositivos existen en el sistema, determinar los controladores necesarios para que estos dispositivos funcionen en Canaima e instalarlos si el usuario lo solicita.

Kernel de Linux y Soporte a Hardware

Jockey actúa sobre los dispositivos no soportados de forma automática por el Kernel de Linux

Por lo general el kernel de Linux brinda soporte a la mayoría del Hardware que encontramos en un computador, y cuando hablamos de hardware hablamos de todo el hardware en general, no solo nos referimos a dispositivos especiales. Por ejemplo, cosas tan simples como el teclado y el ratón son dispositivos de hardware que los sistemas operativos deben reconocer y que normalmente no tomamos en cuenta que hay toda una cantidad de código fuente desarrollado para hacer funcionar estos dispositivos tan básicos que a veces ni los notamos.

Existe también otra cantidad de dispositivos soportados que para otros sistemas operativos es difícil darles soporte y es necesario que el usuario instale software de controladores para ellos, pero en cambio el Kernel de Linux los soporta sin ningún tipo de acción adicional del usuario más que conectarlo al computador. Un caso ejemplar de esto son las Tarjetas de Sonido, que en otros sistemas operativos es necesario activarlas instalando “Drivers”, en cambio en Linux ya vienen activadas sin hacer cambios al sistema.

De igual manera hay otro tipo de dispositivos los cuales vienen marcados por grandes restricciones legales de Copyright (Derechos de Autor) y el poco interés de los fabricantes de brindar soporte a Linux, por esta razón no tienen un soporte automático en Linux, sino que deben ser instalados controladores de software privativos adicionales, o simplemente no tienen soporte alguno.

Este último grupo de dispositivos de Hardware son los que Jockey detecta y determina automáticamente si requieren la instalación de software adicional.

Módulos y Firmware

Existen dos tipos de Software necesarios para que un dispositivo de hardware sea soportado por el Kernel de Linux, se trata de los Módulos del Kernel y el Firmware para el dispositivo. Para que el hardware funcione correctamente es necesario uno de ellos, en algunos casos y la combinación de ambos en otros.

Módulos

Se lee en la Wikipedia:

“En computación, un módulo cargable del núcleo es un archivo que contiene código objeto que puede extender el núcleo en ejecución (también llamado núcleo base) de un Sistema Operativo. La mayoría de los sistemas estilo Unix soportan módulos cargables en el núcleo (Kernel).

Los módulos cargables en el núcleo son generalmente utilizados para brindar soporte a nuevos dispositivos de Hardware y Sistema de archivos, así como para agregar llamadas al sistema. Cuando la funcionalidad provista por un módulo del núcleo deja de ser requerida, normalmente éste puede ser descargado, liberando su memoria.”

Firmware

Nuevamente consultando a la Wikipedia:

“El firmware es un bloque de instrucciones de máquina para propósitos específicos, grabado en una memoria, normalmente de lectura / escritura (ROM, EEPROM, flash, etc), que establece la lógica de más bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier tipo. Está fuertemente integrado con la electrónica del dispositivo siendo el software que tiene directa interacción con el hardware: es el encargado de controlarlo para ejecutar correctamente las instrucciones externas.

En resumen, un firmware es el software que maneja al hardware.

Funcionamiento de Jockey

En Canaima, el detector de hardware está compuesto por tres elementos principales:

  • El Backend
  • El Device Monitor
  • La interfaz de Usuario

Estos tres elementos actúan en dos capas, una capa de sistema (root) y otra capa de usuario.

Diagrama del comportamiento de Jockey. El kernel notifica al Device monitor a través de UDEV la presencia de un dispositivo. El Device Monitor dispara Backend para hacer el chequeo de controladores a través de DBus. Si faltan controladores se disparan las notificaciones y a través de estas se llama a la Interfaz gráfica de usuario quien interactuará luego con el Backend a través de DBus para hacer la instalación

Backend

El Backend de Jockey es la pieza central de todo el proceso de detección del hardware. Este interactúa a directamente con el kernel y los módulos del mismo, haciendo las consultas y procedimientos necesarios para determinar los dispositivos de hardware presentes en el sistema.

Igualmente es el Backend el que se encarga a través de los “Handlers” de activar o desactivar los controladores para dichos dispositivos detectados. Cabe destacar que cuando hablamos de dispositivos detectados en esta sección, hablamos únicamente de aquellos en que pudo determinarse la ausencia de controladores, todos los demás dispositivos a los cuales el Kernel da soporte automático son obviados.

Device Monitor

La función del Device monitor es, como su nombre lo indica, es monitorear en tiempo real la inserción de nuevos dispositivos de hardware en el sistema. Esto lo logra interactuando con UDEV quien le reporta cuando un dispositivo ha sido conectado o desconectado del sistema.

Interactúa en conjunto con el Backend a través de un canal de comunicación DBus, por medio del cual el Device Monitor informa al Backend que un nuevo dispositivo ha sido conectado, y por el cual el mismo Backend informa al Device Monitor si el dispositivo requiere controladores o no.

Si un dispositivo es detectado como “Sin controladores” entonces el Device Monitor se encarga de liberar las notificaciones al usuario a través de la librería libnotify y a por medio de estas notificaciones el usuario puede levantar la interfaz gráfica para decidir qué hacer con el dispositivo detectado.

Interfaz de Usuario

Interfaz Gráfica GTK de Jockey

La interfaz de usuario es la encargada de presentar al usuario la lista de dispositivos que Jockey a detectado, ya sea para activarlos o desactivarlos. Igualmente ofrece detalles del dispositivo y del controlador que será instalado y además ofrece la opción de ignorar las notificaciones referentes a un dispositivo en particular.

La activación y desactivación de los dispositivos la logra esta interfaz gráfica interactuando directamente con el Backend a través de un canal DBus por el cual se envían y se reciben las señales desde y hacia el Backend.

Activación de los Controladores

La activación de los controladores a través de Jockey se producen a través de dos herramientas provistas por esta aplicación, estas son los Handlers y las sobreescritura de Modaliases

Handlers (Manejadores)

Son piezas de código Python en forma de Clases, que vienen en varios tipos dependiendo de la forma de instalación de los controladores. Los Handlers contienen en su código los métodos necesarios para hacer la activación o desactivación del dispositivo en el sistema.

Ejemplo de un Handler

import logging
import os
import subprocess

from jockey.oslib import OSLib
from jockey.handlers import FirmwareHandler, KernelModuleHandler

class IntelCentrinoN1000FirmwareHandler(FirmwareHandler):
    def __init__(self, ui):
        self._free = False
        FirmwareHandler.__init__(
            self,
            ui,
            'iwlwifi',
            '/lib/firmware/iwlwifi-1000-5.ucode',
            name='Firmware for Intel Centrino-N 1000 wireless'
        )
        self.package = 'firmware-iwlwifi'
        self._auto_install = False
        self.needs_kernel_headers = False
        # The iwlwifi module needs to be unloaded then reloaded
        # to activate the device. Rebinding doesn't work
        self._do_rebind = False

    def enable(self):
        logging.debug('Going to reload module %s' % (self.module, ))
        subprocess.call([OSLib.inst.modprobe_path, '-r', self.module])
        r = KernelModuleHandler.enable(self)
        subprocess.call([OSLib.inst.modprobe_path, self.module])
        return r

    def disable(self):
        logging.debug('Removing module %s' % (self.module, ))
        subprocess.call([OSLib.inst.modprobe_path, '-r', self.module])
        return KernelModuleHandler.disable(self)

Sobreescritura de Modaliases

Son pequeños archivos de texto que asocian los identificadores de un dispositivos (IdVendor, IdProduct) con un módulo específico y con un paquete de software presente en el repositorio. Estos Modaliases sobreescritos, son procesados por Jockey y convertidos automáticamente en Handler, es decir, son convertidos a código Python entendible por el Backend quien luego se encargará de hacer los llamados a los métodos correspondientes.

Si un dispositivo es declarado en alguno de estos archivos de sobreescritura de Modaliases, entonces el Backend se encarga de determinar si el módulo indicado está presente en el sistema, y si no es así, entonces instala el paquete de software señalado por este archivo.

Ejemplo de un archivo Modaliases para Jockey

# Realtek
alias pci:v10ecd8192* rtl8192se firmware-realtek
alias pci:v10ecd8171* rtl8192se firmware-realtek
alias pci:v10ecd8172* rtl8192se firmware-realtek
alias pci:v10ecd8173* rtl8192se firmware-realtek
alias pci:v10ecd8174* rtl8192se firmware-realtek

Otro ejemplo de archivo Modaliases:

# Information from http://wireless.kernel.org/en/users/Drivers/ath9k_htc/devices
reset ath9k_htc
# Atheros
alias usb:v0CF3p7010d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0CF3p7015d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0CF3p9271d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Azureware
alias usb:v13D3p3327d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v13D3p3328d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# D-Link
alias usb:v07D1p3A10d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# LiteOn
alias usb:v04CAp4605d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Netgear
alias usb:v0846p9030d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0846p9018d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Panasonic
alias usb:v04DAp3904d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# SMC
alias usb:v083ApA704d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Sony
alias usb:v0411p017Fd*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# TP-LINK
alias usb:v0CF3p1006d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros

Referencias

Funcionamiento de Jockey en Canaima

Funcionamiento de Canaima Instalador

En este apartado se explicará la estructura y funcionamiento de Canaima Instalador. Esta aplicación está desarrollada en lenguaje Python y consiste en un asistente de instalación guiada de Canaima GNU/Linux, en pocos pasos y de fácil uso para los usuarios comunes.

Esta referencia está basada en la versión 2.x del instalador y pretende servir de introducción a todos aquellos desarrolladores y entusiastas que estén interesados en participar o tan solo conocer cómo funciona esta herramienta.

Estructura

A nivel de código fuente, el instalador se estructura en un formato similar al conocido Modelo Vista Controlador (MVC), aunque para ser sinceros, no totalmente. Hay partes del código que no están bien adaptadas a esta técnica.

A nivel de interfáz gráfica se puede describir como un Asistente que va guiando al usuario a través de cada uno de los Pasos para la instalación.

Representación gráfica de la estructura de Canaima Instalador

El Asistente: se puede describir como la interfaz gráfica general, es como el marco donde se van insertando los pasos a medida que el usuario avanza en el proceso. Está compuesto por la ventana en sí, el campo con los botones "Atrás y Adelante", y el contenedor que albergará de uno en uno los pasos que se van mostrando al usuario.

Los Pasos: Son cada una de las pantallas que el asistente va presentando al usuario, y que tienen una función específica, por ejemplo, la bienvenida, la selección de idioma y teclado, la selección de disco y método de particionado, etc. Cada una de ellas es insertada o removida del marco del Asistente a través del uso de los botones "Atrás" y "Adelante".

Funcionamiento

El funcionamiento del instalador se puede dividir en dos fases, la captura de datos y el proceso de instalación como tal. Ambas fases se pueden a su vez subdividir en otras fases específicas.

Fases de la Instalación, en la fase de captura de datos se puede ir de adelante hacia atás, en cambio el proceso de instalación no se puede detener de forma segura una vez iniciado, por eso no se ofrecen opciones para retroceder

Captura de datos

La fase de captura de datos es la encargada de determinar como y donde se va a instalar y configurar el sistema operativo. Este a su vez puede sub-dividirse en otras fases.

Selección de Idioma, Zona Horaria y Teclado

Selección de Idioma, Zona Horaria y Teclado
# Archivos resaltantes (Ver archivos)
./canaimainstalador/pasos/teclado.py
./canaimainstalador/clases/i18n.py
./canaimainstalador/clases/keyboard.py
./canaimainstalador/clases/timezone.py

Este es el segundo "paso" que presenta el instalador, el primero es la bienvenida. Aquí se muestra al usuario las opciones disponibles para la configuración del teclado, la zona horaria y el idioma del sistema que será instalado.

Para determinar los valores soportados por el sistema operativo con respecto a teclado, zona horaria e idioma, se hace una lectura de los siguientes archivos:

/usr/share/i18n/SUPPORTED    [Idiomas]
/usr/share/xml/iso-codes/iso_639_3.xml [Idiomas]
/usr/share/zoneinfo/zone.tab    [Zonas Horarias]
/usr/share/X11/xkb/rules/base.xml    [Distribuciones de Teclado]

Estos archivos son procesados internamente por el instalador para mostrar las opciones dentro de cajas de selección. También encontramos en este paso un recuadro que sirve para probar la distribución de teclado seleccionada.

Selección de disco y método de particionado

Selección de disco y método de particionado
# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/metodo.py
./canaimainstalador/clases/particiones.py
./canaimainstalador/clases/barra_particiones.py

En este paso el usuario puede seleccionar el disco donde hará la instalación y alguno de los métodos de particionado ofrecidos. Los métodos de instalación se calculan automáticamente según sea la configuración del disco seleccionado.

La información cargada en este paso se obtiene gracias a la librería python-parted quien nos reporta los detalles del disco y sus particiones, entre otras características.

Las posibles opciones de particionado que presenta el instalador, las enumeramos a continuación, recordemos que son mostradas al usuario dependiendo de la información obtenida del disco seleccionado.

  • Instalar usando el disco completo. Obvia las particiones existentes en el disco y lo usa en su tamaño total para la instalación.
  • Instalar redimensionando [partición] para liberar espacio. Si una partición tiene el tamaño suficiente la redimensionará y utilizará el espacio liberado para hacer la instalación.
  • Instalar utilizando el espacio libre disponible. Si el instalador detecta en el disco una espacio libre sin particionar con el tamaño suficiente, instalará Canaima dentro del mismo.
  • Instalar editando las particiones manualmente. Presenta en el siguiente paso el instalador manual para que el usuario puede modificar el disco a su conveniencia.

Cabe destacar que las opciones presentadas por el instalador en este punto también depende del numero de particiones primarias y de particiones extendidas que existan en el disco y las que deban ser creadas debido a las restricciones en los discos que limitan estas cantidades.

Seleccionar el esquema de particiones

Seleccionar el esquema de particiones
# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/particion_auto.py
./canaimainstalador/pasos/particion_todo.py
./canaimainstalador/clases/barra_auto.py
./canaimainstalador/clases/barra_todo.py

A excepción del particionado manual, todas las demás opciones ofrecen un método de particionado automatizado. Para estos casos el instalador ofrece un paso adicional donde el usuario selecciona de una lista, el esquema de particiones que más se adapte a su necesidad o preferencia.

En primer lugar encontramos en la parte superior dos botones que permiten seleccionar entre utilizar en Mínimo espacio posible de la particion o disco seleccionado, o el Máximo espacio disponible.

Luego encontramos la lista de las opciones disponibles, con cada uno de los esquemas de particionado predefinidos.

  • Instalar todo en una sola partición. Solo crea dos particiones, una para todo el sistema (/).
  • Separar la partición home. Separa en una partición el directorio de los usuarios (/home) de los demás datos del sistema (/).
  • Separar la partición home y boot. Crea particiones aparte para los directorios de usuarios y para el directorios del gestor de arranque.
  • Separar home, boot, var y usr. Es una configuración común en algunos servidores, pero escasamente utilizadas en computadores personales.

Particionado manual

Particionado manual
# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/particion_manual.py
./canaimainstalador/clases/particion_nueva.py
./canaimainstalador/clases/particion_editar.py
./canaimainstalador/clases/particion_redimensionar.py
./canaimainstalador/clases/particion_eliminar.py

Si no se selecciona ninguno de los métodos automáticos de particionado, tenemos también la posibilidad de utilizar el particionado manual, en este paso se presenta una tabla con las particiones disponibles en el disco seleccionado y al seleccionarlas tendremos las opciones de Crear nuevas particiones, editarlas, cambiarles el tamaño o eliminarlas para liberar espacio.

Configuración de las cuentas Usuarios

Configuración de la cuenta de usuarios
# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/usuario.py

En este paso se configuran los datos del usuario, como nombres y contraseñas, adicionalmente se determinan algunas características de accesibilidad, nombre del equipo (host), y el modo OEM.

Lo más resaltante en este punto es las validaciones que se hacen de los nombres de usuarios y sus contraseñas para que sean válidos cuando se creen dichas cuentas en el sistema.

Adicionalmente tenemos el modo OEM, que es una característica especialmente utilizada por los fabricantes de computadores como por ejemplo VIT y Siragon. Seleccionando esta característica, los datos del usuario y contraseñas no se crean durante el proceso de instalación sino que se solicitan al usuario durante el primer arranque del sistema.

La característica OEM se activa instalando en el sistema destino la aplicación canaima-primeros-pasos, que es la encargada de iniciarse y hacer la solicitud de los datos al usuario en el primer arranque.

Confirmación de los datos

Confirmación de los datos
# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/info.py

El último paso antes de iniciar el proceso de instalación es simplemente una pantalla de confirmación de los datos suministrados por usuario que determinan la forma en que se realizará la instalación y las configuraciones que se realizarán dentro del sistema destino.

Proceso de Instalación

Proceso de instalación

El proceso de instalación es realmente el encargado de hacer todas las modificaciones y configuraciones en el disco y el sistema destino, según los parámetros seleccionados por el usuario durante la fase previa de captura de datos.

Es de resaltar que antes del proceso de instalación no se hacen modificaciones en el sistema destino. El proceso de captura de datos simplemente va insertando los valores seleccionados por el usuario en una variable global presente en canaimainstalador.config.CFG, la cual almacena todos los detalles que después serán leídos durante el proceso de instalación que se describe en esta sección.

# Archivo resaltantes (Ver archivos)
./canaimainstalador/pasos/instalacion.py
./canaimainstalador/clases/common.py
./canaimainstalador/clases/particiones.py
./canaimainstalador/clases/config.py

Todo el proceso de instalación se concentra en el método presente en canaimainstalador.pasos.instalacion.install_process()

Particionado del Disco

Es la primera operación que se ejecuta durante el proceso de instalación, el formateo o no de particiones existentes depende de lo que se haya seleccionado durante la captura de datos, igualmente el tipo de sistema de archivos, etc.

Las acciones a realizar en el disco son leídas desde CFG['acciones'] de forma recursiva, determinando así cuando una partición debe ser formateada, redimensionada, creada, etc.

Montando particiones

Todas las particiones creadas en el proceso anterior son montadas dentro del directorio /mnt, ahí en esa ruta procederemos luego a copiar los archivos y a entrar en un sistema de archivos virtualizado con chroot para poder aplicar las configuraciones necesarias.

Copiado de archivos al disco

El proceso de copiado al disco de los archivos del sistema se hace utilizando la herramienta unsquashfs. Por lo tanto para entender este proceso es necesario conocer un poco más sobre que es el sistema de compresión squashfs.

Squashfs es una aplicación que nos permite comprimir en un archivo todo un sistema ya configurado. Es decir, por ejemplo, que tomáramos todos nuestro sistema actual y lo comprimiéramos en un solo archivo. Esta sistema de archivos comprimidos es utilizado por la herramienta live-build que permite que Canaima funcione como LiveCD, por esa razón todo el sistema cabe en un CD o DVD, e indica que ya contamos en el disco de Canaima con ese sistema comprimido.

Proceso de copiado de archivos al disco

Durante el proceso de copiado de archivos al disco, el instalador únicamente se encarga de descomprimir esos datos en el disco destino a través de la herramienta unsquashfs. La ruta desde donde se puede acceder a el archivo con este sistema de archivos comprimidos dentro del LiveCD es:

# En versiones nuevas
/lib/live/mount/medium/live/filesystem.squashfs
 
# O en versiones anteriores
/live/image/live/filesystem.squashfs

Recordemos que nuestro disco destino es montado por el instalador en /mnt, por lo tanto al finalizar el proceso podremos entrar e iniciar una sesión virtual en el utilizando la herramienta chroot.

Configuración de archivos del sistema

Una vez que los datos están copiados en el disco, comenzaremos a trabajar sobre el iniciando sesiones virtuales con chroot y ejecutando una serie de comando para configurar el sistema final.

En este punto de la configuración lo que procede el instalador es a crear los archivos del sistema necesarios para su correcto funcionamiento, específicamente se instalan estos archivos:

  • /etc/fstab
  • /etc/default/locale
  • /etc/locale.gen
  • /etc/timezone
  • /etc/default/keyboard
  • /etc/hostname
  • /etc/hosts
  • /etc/network/interfaces
  • /etc/apt/sources.list
  • /etc/adduser.conf
  • /etc/mtab

Reconfiguración de paquetes

Como el sistema comprimido en filesystem.squashfs no está configurado bajo los parámetros seleccionados por el usuario durante la captura de los datos, sino que por el contrario posee una configuración genérica, es necesario hacer el llamado al proceso de post-instalación (reconfiguración) del algunos paquetes puntuales para que cuando el usuario inicie su nuevo sistema, estén todos los valores correctamente configurados según su selección durante la instalación.

Los paquetes que se reconfiguran en este punto son:

  • locales
  • canaima-estilo-visual-gnome
  • canaima-escritorio-gnome
  • canaima-base
  • tzdata
  • software-center
  • console-data

Instalación de paquetes adicionales de idioma

Según la selección de idioma que haya realizado el usuario, el instalador buscará dentro del LiveCD si existen los paquetes adicionales para ese idioma con los cuales otras aplicaciones también estarán traducidas, por ejemplo el navegador, LibreOffice, etc, que distribuyen sus archivos de traducciones como paquetes apartes.

Para asociar el idioma seleccionado por el usuario con los paquetes adicionales necesarios, el instalador se vale del archivo

/usr/lib/canaima-l10n/l10n_pkgs.dict

Este archivo es instalado por el paquete canaima-l10n y asocia en un diccionario de Python los idiomas soportados por el sistema con los paquetes que deberían instalarse para darle un soporte más completo. Dicha lista de paquetes es leída recursivamente por el instalador para buscarlas dentro del disco y si está presente la instala en el sistema destino.

Configuración de los usuarios

En este punto se configuran los datos de usuario indicados durante la captura de datos.

Si el usuario seleccionó el modo OEM, entonces se configura un usuario genérico y un usuario root con una contraseña estándar para que los fabricantes puedan hacer configuraciones al sistema una vez instalado, de igual manera, se instala la aplicación canaima-primeros-pasos la cual se encargará de solicitar al usuario los datos correspondientes en el primer inicio del sistema.

Removiendo datos de Instalación

Como ya mencionamos, los datos contenidos dentro del filesystem.squashfs son los utilizados por el liveCD, por lo tanto en este punto procedemos a remover varios paquetes que no son necesarios para el sistema final, entre ellos se encuentra el instalador y las herramientas utilizadas por live-build.

Estos son los paquetes removidos durante este proceso.

  • canaima-instalador
  • live-config
  • live-boot
  • live-boot-initramfs-tools
  • live-initramfs
  • live-config-sysvinit
  • live-tools

Instalando el gestor de Arranque

Ya el sistema está casi listo en este punto, lo último que resta por hacer es asegurarnos que al iniciar la máquina, Canaima pueda arrancar. De tal modo que en este punto se procede a la instalación del Burg, el gestor de arranque de Canaima.

Durante este proceso, la propia instalación del Burg se encarga automáticamente de definir si hay otros sistemas operativos presente en la maquina, de ser así, los agrega a la lista de sistemas operativos disponibles, para que el usuario pueda seleccionar durante el arranque con cual de ellos desea iniciar su equipo.

Desmontando las particiones

Ya finalizado el proceso de instalación, se procede a desmontar todas las particiones que previamente habían sido montadas en el directorio /mnt y se le ofrece al usuario a través de la interfaz gráfica la opción de seguir probando el sistema o de reiniciar el equipo para comenzar a probar inmediatamente el nuevo Canaima recién instalado.

Otras Referencias

Funcionamiento de Canaima Instalador

Introducción a Jockey, el detector de hardware y controladores de Canaima

Jockey en Canaima 4.0

Jockey es una aplicación desarrollada originalmente para Ubuntu que ofrece una interfaz de usuario e integración con el escritorio para la instalación y actualización de controladores de hardware de terceros. Esta aplicación ha sido portada para funcionar en Canaima GNU/Linux, proveyendo a los usuarios de una herramienta fácil de usar que les permite instalar controladores para sus dispositivos de hardware como Tarjetas Inalámbricas, de Audio, de Video, Impresoras, etc.

Soporte de Hardware en Linux

En general, el manejo de controladores de Harware en las distibuciones GNU/Linux ha estado desde siempre lleno de casos en los cuales algunos dispositivos, en especial los que recien salen al mercado, no tienen soporte o poseen un soporte limitado, provocando así que los usuarios perciban la sensación de que las distribuciones Linux son de baja calidad porque no reconocen sus dispositivos de Hardware.

En la actualidad, esta percepción puede considerarse erronea debido a que el nucleo (kernel) de Linux, incluye soporte a una vasta variedad de dispositivos de hardware, y debido al exito acumulado a través de los años, la cantidad de desarrolladores para este sistema a aumentado y esto ha traido como consecuencia la rápida incorporación de soporte para los dispositivos de hardware más recientes en el mercado mundial.

De este modo, el principal problema de Linux con respecto al soporte de dispositivos se concentra en la privatización del conocimiento sobre el hardware y el software que lo hace funcionar, dejando las siguientes alternativas a los desarrolladores de Linux.

  • Esperar a que el fabricante del dispositivo desarrolle un controlador libre. Esto implica no poder dar soporte a miles de dispositivos mientras el fabricante no lo haga, además, normalmente, los fabricantes se concentran en sistemas operativos comerciales y dejan de lado el soporte a Linux.
  • Proveer controladores de código fuente cerrado. Cuando los fabricantes generan controladores para Linux de sus dispositivos, normalmente vienen marcados por restricciones de "Derechos de Autor".
  • Hacer ingenieria inversa del funcionamiento del hardware y su interacción con el sistema. El soporte de muchos de los dispositivos en Linux, se da a través de la ingeniería inversa, lo cual implica descubrir como funciona el dispositivo y que señales envía y/o recibe del sistema. En ocasiones esto implica que no se aprovecharán todas las características del dispositivo, que solo el fabricante conoce como activarlas o aprovecharlas.

Antecedentes en Canaima

El manejo de controladores en Canaima puede dividirse en 3 etapas hasta la fecha, cada etapa diferenciada por el método en que se daba soporte a dispositivos de hardware.

1ra Etapa: Todos Adentro

Durante las primeras versiones de Canaima se distribuían todos los paquetes de controladores que estaban provistos en el repositorio oficial. Esto tenía 2 implicaciones, en primer lugar se estaban distribuyendo paquetes de licencias privativas dentro del contenido base de Canaima, y en segundo lugar, la mayoría de estos controladores no era necesario en todas las maquinas, es decir se estaba ocupando espacio innecesario en el disco.

2da Etapa: Canaima Blobs

A partir de Canaima 3.0 se decidió por petición de la comunidad, quitar todos los controladores y cualuquier otro software de licencias privativas, estos deberían ser instalados manualmente por el usuario que los requiriera. De ese modo nace canaima-blobs, una aplicación que se encargaba de instalar TODOS los paquetes de licencias privativas.

Canaima Blobs también tuvo sus problemas, básicamente, si querías instalar el plugin de Flash para ver videos en el navegador, canaima-blobs lo descargaba conjuntamente con decenas de megabytes adicionales en controladores y otros paquetes que el usuario no requería. Esto se debía a que Canaima Blobs no sabía como determinar cuales controladores especificos necesitaba el sistema para instalarlos y obviar los innecesarios, además, se mezclo controladores de hardware con aplicaciones comunes como por ejemplo el plugin de Flash.

3ra Etapa: Jockey

En el año 2012, al inicio del desarrollo de la nueva versión 4.0 de Canaima, en Centro Nacional de Tecnologías de Información (CNTI) abre un concurso público solicitando a unidades productivas venezolanas la creación de una aplicación que permitiera la detección del hardware del sistema e identificara los controladores necesarios para dicho hardware.

Es así que la cooperativa ganadora ofreció la idea de portar desde Ubuntu la aplicación Jockey, añadiendole características adicionales para cumplir con los requerimientos solicitados. Es así que a partir de la versión 4.0 de Canaima viene incluida esta aplicación.

Características de Jockey en Canaima

La aplicación Jockey para la detección de Hardware sufrió algunas modificaciones para ser incluida en Canaima, a cntinuación se describen las características tradicionales (de Ubuntu) más las características adicionales añadidas para Canaima.

  • Identifica los dispositivos de Hardware presentes en el sistema y determina si poseen o no controladores activos.
  • Detección en Tiempo real de dispositivos conectados al sistema (Soporte para dispositivos USB). (Solo en Canaima)
  • Notificaciones al usuario de controladores disponibles.
  • Instalación y Configuración de los controladores para el hardware seleccionado.
  • Información detallada de los dispositivos detectados, para los casos en que no es posible determinar el controlador (Solo en Canaima).

Instalación

Aunque Jockey ya viene integrado en la instalación Base de Canaima 4.0, en caso de no estar presente puede ser instalado desde el Centro de Software haciendo una busqueda normal, o se puede instalar por la terminal a través del comando:

apt-get install jockey-gtk

¿Cómo contribuir?

Para contribuir a mejorar el Jockey para Canaima tienes 3 opciones:

  • Descargar y mejorar el código fuente.
  • Reportar errores.
  • Añadir soporte a nuevos dispositivos.

Descargar el código fuente

El código fuente de Jockey para Canaima lo encuentras en:

Reportar errores

En la plataforma colaborativa de Canaima GNU/Linux puedes reportar los errores o mejoras tanto para Jockey como para las demás aplicaciones del sistema.

Añadir soporte a nuevos dispositivos

TODO: Esto debe ser explcado con mas detalles en otra sección

Links Relacionados

https://launchpad.net/ubuntu/+source/jockey

http://wiki.canaima.softwarelibre.gob.ve/wiki/Jockey

Introducción a Jockey, el detector de hardware y controladores de Canaima

Introducción a Canaima Instalador

Haciendo los preparativos para la proxima Cayapa Canaima – Coro 2013, me he propuesto documentar un poco las aplicaciones de las cuales voy a hablar durante el evento. Les transcribo a continuación una breve introducción al Instalador de Canaima.

Este artículo describe las carácterísticas fundamentales del Instalador de Canaima, si por el contrario lo que estás buscando es cómo instalar Canaima GNU/Linux deberías empezar por aquí.

Canaima Instalador, Pantalla de Bienvenida

El instalador de Canaima es una de las principales aplicaciones en Canaima GNU/Linux, no solo porque es de las primeras con las que el usuario tiene contacto, sino por su labor dentro del sistema. Esta aplicación, como su nombre lo dice, cumple con el gran compromiso de instalar dentro del equipo el sistema operativo Canaima GNU/Linux para que éste pueda ser utilizado luego desde el disco duro.

Historia

La forma de instalar Canaima ha variado a veces poco a veces mucho en las distintas versiones liberadas de este sistema operativo.

De Canaima 1.0 a 2.0.4

Debian Installer (d-i)

Desde las primeras versiones hasta la versión 2.0.4 de Canaima GNU/Linux, ésta se distribuía sólo con el instalador de Debian, mejor conocido como Debian Installer (d-i), en esas versiones de Canaima no era posible probar el sistema sin necesidad de tener que instalarlo (característica que se conoce como LiveCD).

Otro punto resaltante en estas versiones es que Canaima sólo se distribuía en modo DVD lo cual lo hacía difícil de descargar para los usuarios con conexiones de Internet de baja tasa de transferencia.

De Canaima 2.1 a 3.0

Canaima Instalador Vivo

Para las siguientes versiones encontramos que se implementó el modo LiveCD, que permitía al usuario probar el sistema sin instalarlo en el disco duro del computador. Esto trajo consigo un problema de usabilidad que los desarrolladores debieron resolver.

El problema se trataba que al incorporar el modo de LiveCD, se hizo necesario contar con un instalador que permitiera al usuario instalar desde ese modo, ya que para poder utilizar el Debian Installer una vez iniciado el Modo Live habia que reiniciar el equipo.

Es así que Canaima incorporó dos metodos de Instalación, el primero era el ya conocido Debian Instaler, y el segundo fué un instalador para el modo Live llamado canaima-instalador-vivo basado en gdinstall y desarrollado en lenguaje Ruby.

De Canaima 3.1 en Adelante

Canaima Instalador, proceso de instalación.

A partir de la versión 3.1 Canaima se encontró en un aprieto, ya que desde un tiempo atrás debía ser distribuido en sólo 700 MB máximo (un CD) pero debido a las nuevas aplicaciones que se incorporaron, esta medida era difícil de cumplir (Aún hoy es muy difícil de cumplir, hay que hacer maromas para que Canaima quepa en un CD). Además, la aplicación canaima-instalador-vivo tenía fallas detectadas y reportadas por los usuarios, pero por estar desarrollada en Ruby se dificultó su mantenimiento.

Es así que nace la primera versión de Canaima-Instalador, con la intención de ser un instalador ligero, fácil de usar, fácil de entender por los usuarios más novatos y de fácil mantenimiento a nivel de desarrollo.

Este instalador es una de las nuevas aplicaciones que se incluyeron a partir de Canaima Popular 3.1 hasta la actualidad y es quizás una de las más importantes por la responsabilidad que sobre ella recae.

¿Por qué hacer este instalador?

Como se explica anteriormente, la incorporación de nuevas aplicaciones dentro del CD de Canaima 3.1, hizo necesario que se explorara la eliminación de otras aplicaciones menos relevantes. Se tomó entonces la decisión de hacer un instalador desde cero, en un lenguaje popular y ampliamente documentado (Python), más completo, robusto y amigable, pero sobre todo: liviano.

Esta decisión permitió a Canaima prescindir de los antiguos instaladores de Canaima 3.0 (debian-installer, canaima-instalador-vivo), que en total ocupaban (para la versión 3.1) alrededor de 100MB de los 700MB disponibles en un CD. Es decir, casi el 15% del disco estaba ocupado sólo por los instaladores, reduciendo así el espacio para incorporar aplicaciones necesarias. Sumado a eso, se facilitó el mantenimiento del instalador gracias a la utilización de un lenguaje como Python.

Características de Canaima Instalador

Canaima Instalador, asistente de selección de disco y método de particionado
  • Fácil de utilizar ya que incorpora un asistente de pasos sencillos, que permiten al usuario configurar lo que será su sistema operativo de uso diario.
  • Instalación en poco tiempo, porque implementa un descomprimido rápido del sistema durante proceso de copia de archivos.
  • Ofrece opciones de particionado automático según las características del disco destino, lo cual evita al usuario común hacer tareas avanzadas de configuración del disco.
  • Incorpora instalación OEM, para empresas manufactureras de computadores (Como VIT o Siragon por ejemplo).
  • Incluye un particionador manual para la personalización más detallada del disco destino.
  • Integra varias tecnologías, entre las que podemos mencionar: python-gtk2, python-cairo, python-parted, python-webkit, jquery, multihilos, entre otros.

Instalando el Instalador

Es importante indicar como paso previo, que para utilizar el instalador de Canaima debes hacerlo desde el LiveCD, preferiblemente desde la versión más actual de Canaima, ya sea que esté en fase de desarrollo o de pruebas. Si no deseas hacerlo desde un LiveCD sino desde un entorno permanente, deberas crear la carpeta:

 /lib/live/mount/medium/

o sino:

 /live/image/

Y en esa ruta descomprimir los datos contenidos dentro de la imagen ISO o CD de Canaima. Una vez realizado estos pasos, podrás obtener el instalador y probarlo.

Desde el repositorio

Si estás usando Canaima (>= 3.1) solo debes ejecutar el comando:

 apt-get install canaima-instalador

O buscando Canaima Instalador en el Centro de Software.

Desde el código fuente

Si quieres instalar desde el código fuente debes descargarlos desde el servidor de http://git.canaima.softwarelibre.gob.ve/ y luego ejecutar el script de instalación de la siguiente manera:

 # Descargar los archivos fuentes
 git clone git://git.canaima.softwarelibre.gob.ve/canaima-instalador.git
 
 # Entrar en la carpeta del proyecto
 cd canaima-instalador
 
 # Construir el proyecto
 make
 
 # Instalar (como root)
 make install

¿Cómo Contribuir?

Hay varias formas de contribuir con el desarrollo del instalador.

Descargar el código fuente

Puedes descargar el código fuente para hacer tus propias modificaciones y correcciones que luego puedes enviarnos para incorporarlas a la rama principal de desarrollo:

 git clone git://git.canaima.softwarelibre.gob.ve/canaima-instalador.git

Reportar Fallos

Si no sabes programar o no es lo que buscas, pero encontraste algo que no funciona o se puede mejorar, puedes abrir un ticket de soporte en la siguiente dirección:

 http://trac.canaima.softwarelibre.gob.ve/canaima

Enlaces Relacionados

Introducción a Canaima Instalador