Instalar Ubuntu 13.04 en iMac 27″

Un apunte rápido, porque ha sido coser y cantar, a diferencia del martirio por el que tuvimos que pasar en 2010 y que dejamos documentado. Captura de pantalla 2013-09-06 a la(s) 16.13.39Realmente lo único que he necesitado ha sido la versión AMD64 de Ubuntu 13.04 (la vez anterior tuve que descargar explícitamente la versión «alternate», esta vez ha bastado con la versión desktop tradicional).

Sí ha sido necesario, al igual que la vez anterior, instalar el gestor de arranque rEFIt (no vale sólo con GRUB, o yo no he sido capaz). Parece que rEFIt está obsoleto y que ahora se recomienda rEFInd, aunque a mí no me ha dado ninguna guerra (al instalarlo, la primera vez no te saldrá el menú de rEFIt, tendrás que volver a arrancar para verlo).

El reparticionado del disco lo hice con el editor de disco de MacOSX. Sin problemas (reparticionando en caliente, sin desmontar la unidad… daba un poco de miedo, pero al no recibir ningún warning por intentarlo, supuse que era viable).

En la instalación, en modo gráfico, he seleccionado la opción de descarga de actualizaciones y la opción de activar drivers privativos. Nada más, Ubuntu 13.04 se ha instalado rápidamente en la partición que le corresponde y rEFIt me permite entrar sin problemas en MacOSX o Ubuntu (a través de GRUB).

Hay un fallo que queda por corregir: al apagar Ubuntu el iMac se queda colgado (no se llega a apagar). Para corregirlo:

sudo gedit /etc/default/grub

y sustituimos la línea GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” por GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash reboot=pci”

(tal y como explicamos en el anterior post relacionado)

Nota: que a mí me haya funcionado no quiere decir que en tu iMac también lo haga. Así que, ya sabes, antes de tocar particiones, recuerda que las copias de seguridad son tus amigas 😉

JuJu: el domador Ubuntu de servicios en la nube

Tercera ley de Clarke: «Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia». Eso es lo que me pasó por la cabeza la primera vez que ví éste vídeo sobre JuJu:

En 5 minutos y un puñado de comandos, JuJu permite ensamblar, desplegar y escalar un sistema MediaWiki de dos unidades, con la capa de persistencia en un cluster MySQL, dos instancias memcached para acelerar las peticiones y HAProxy como balanceador de carga. Y eso es sólo un ejemplo… Podríamos definir JuJu (antes conocido como Ensemble) como una mezcla entre gestor de paquetes para lanzar aplicaciones en la nube y un sistema de orquestación de servicios (una especie de domador con látigo que pone a cada servicio en su sitio y los junta/ensambla con otros animales/servicios 😉 Este software ha sido desarollado por Canonical bajo licencia AGPL y es un paso más en los movimientos de Canonical por situarse en el territorio cloud.

Para que JuJu funcione, hace uso de «encantamientos» o charms, que son simples recetas en un lenguaje de scripting que permiten instalar, configurar y enlazar servicios. Hay ya una bonita colección de charms disponibles, pero todavía quedan muchos por hacer. Usando estos charms, podemos lanzar un WordPress en la nube con MySQL como Base de Datos, con 4 comandos:

$ juju deploy –repository=. wordpress myblog
$ juju deploy –repository=. mysql mydb
$ juju add-relation mydb:db myblog
$ juju expose wordpress

Bonito, ¿eh? Pues ahora piensa que con el comando add-unit puedes lanzar otra unidad WordPress y comenzar el escalado horizontal a partir de comandos juju, como se muestra en el vídeo 🙂 ¿Magia?

Te recomiendo éste post en castellano con un ejemplo más elaborado del uso de JuJu, o si estás interesado, esta presentación en PDF para que revises el funcionamiento interno de esta tecnología.

Upstart: una introducción para los viejos rockeros de init

Upstart es el sistema que muchas distribuciones Linux utilizan para gestionar las tareas a realizar en el arranque. Para los más veteranos del lugar, Upstart tiene como objetivo reemplazar los daemons tradicionales de SystemV que gestionan las tareas a ejecutar en el arranque, la parada y puesta en marcha de servicios.

Upstart busca sustituir al daemon init, el primer proceso que se lanza en Linux tras cargar el kernel y que se encarga de arrancar el resto. init es el proceso padre de todos aquellos procesos que hayan perdido a su padre (es el padre de todos los daemons). El comando pstree permite ver esto gráficamente.

Por qué Upstart
init es un proceso síncrono que bloquea la ejecución de tareas hasta terminar con la actual. Las tareas que init debe ejecutar han de ser definidas con antelación y éstas sólo se ejecutan cuando init cambia su estado (generalmente porque la máquina se ha encendido, se está apagando o se está reiniciando). El daemon init decide qué tareas ejecutar al cambiar su estado (RUNLEVEL) mirando en el directorio /etc/rcX.d/, donde X indica el RUNLEVEL actual.
Este hecho impide que init gestione correctamente otras tareas que son necesarias ejecutar NO al cambiar de RUNLEVEL sino cuando se generan ciertos eventos, como por ejemplo, las siguientes:

* se quiere ejecutar un backup del servidor de la base de datos en cuanto se detecte que dicho servicio se ha parado
* se conecta en caliente un dispositivo USB o disco externo
* se quiere realizar un sondeo de los dispositivos de almacenamiento disponibles sin que se bloquee el sistema (especialmente cuando el disco a sondear está en estado stand-by y se enciende al detectar el sondeo)
* se quiere ejecutar un script cada hora pero sólo si la ejecución anterior ya ha terminado

Hay más ejemplos y casos de uso en la discusión para reemplazar init en Ubuntu.

El modelo basado en eventos de Upstart permite responder de forma asíncrona a eventos como los mencionados, en cuanto éstos ocurren. La asincronía permite poder ejecutar en paralelo distintas tareas con el objetivo de minimizar el tiempo de arranque.

Evolución de Upstart
Desde su introducción en Ubuntu 6.10 (2006) Upstart ha ido paulatinamente reemplazando a SystemV (la migración por pasos siempre fue un objetivo). Los scripts de arranque y parada de servicios han sido migrados, si no todos, si una buena parte. El fichero /etc/inittab que indicaba al proceso init qué RUNLEVEL arrancar por defecto y cuáles eran los scripts rc que había que arrancar en cada nivel, ha sido eliminado.

En las primeras versiones de Upstart, la definición de jobs (trabajos a realizar cuando se detecten ciertos eventos) se hacía en el directorio /etc/event.d. En Karmic Koala (9.10), Canonical decidió cambiar esa localización a /etc/init.

En Agosto de 2011, Red Hat decidió también adoptar Upstart, dejando de lado SystemV init.

Trabajos, eventos, tareas y servicios
Los trabajos (o jobs, en terminología Upstart) pueden ser tareas o servicios. Las tareas son simples scripts que se ejecutan y terminan su trabajo en un breve lapso de tiempo. Los servicios son procesos que se quedan en ejecución (daemons). Para que un job pueda ponerse en marcha o pararse, deben darse ciertas condiciones. Normalmente estas condiciones vienen dadas por la detección o no de ciertos eventos. Por poner un ejemplo gráfico, veamos el job /etc/init/mysql.conf que permite lanzar o parar mysql en función de la detección de ciertos eventos.

# MySQL Service
 
description     "MySQL Server"
author          "Mario Limonciello <superm1@ubuntu.com>"
 
start on (net-device-up
          and local-filesystems
	  and runlevel [2345])
stop on runlevel [016]
 
[...]
exec /usr/sbin/mysqld
[...]

En resumidas cuentas, el job mysql viene a decir que el daemon mysqld se pondrá en marcha cuando se detecte red (net-device-up), el sistema de ficheros haya sido montado (local-filesystems) y el nivel de ejecución sea uno entre 2 y 5 (Ubuntu en modo gráfico arranca por defecto en el nivel 2). Si se detecta un evento runlevel 0 ó 1 ó 6 entonces el daemon mysqld se parará.

En Ubuntu Natty, Upstart introdujo el comando initctl2dot, que permite ver gráficamente estas dependencias (además de ayudarnos a detectar quién emite cada evento en cuestión).
Por ejemplo, tecleando:

initctl2dot -r mysql -o - | dot -Tpng -o upstart.png

Obtenemos la siguiente imagen:

Los jobs se muestran en cajas grises. Las líneas azules apuntan a los eventos cuya emisión arrancarían el job. Las líneas rojas indican qué eventos provocarían la parada de mysql. Las líneas verdes unen un evento con el job que lo emite.

Si te preguntas quién emite net-device-up (en el diagrama no hay ningún job que lo emita), puedes realizar una búsqueda desde /etc así:

/etc/$  grep -irn "net-device-up" *

y verás que lo hace el script if-up cada vez que se activa una tarjeta de red.

Emitir manualmente un evento
Tal y como se aprecia en la imagen anterior, es posible forzar la emisión de un evento. Para ello, desde la línea de comandos, basta con ejecutar:

$  sudo  initctl emit nombre_del_evento

Curiosidades
El primer evento que Upstart genera es startup.
Upstart tiene como uno de sus objetivos ser compatible con SysV init. Por ello, simula eventos runlevel y establece un DEFAULT_RUNLEVEL a través del job /etc/init/rc-sysinit.conf.

Indicator bug: conoce al instante los bugs de tu aplicación

Mi amigo Oier Mees nos habla de su nueva creación:

Indicator-Bug es un indicador para Ubuntu 11.04 y 11.10 que muestra y actualiza regularmente una lista de bugs para un determinado proyecto de Launchpad. También avisa cuando haya nuevos bugs, cambiando el color del icono, que cumplan los criterios de búsqueda especificados. Además, haciendo click en la entrada un bug, se abre la página correspondiente de Launchpad en el navegador.
El usuario puede especificar qué tipo de bugs le interesan, por ejemplo, que aparezcan bugs que contengan ciertos tags, bugs marcados como críticos etc. Para evitar llenar la pantalla de listas interminables, sólo se muestran las primeras 8 entradas y por otro lado, también se acorta el titulo en caso de que sea demasiado largo.

La idea surgió porque buscaba una forma de estar informado en cuanto se dieran nuevos bugs en Ubuntu dentro de la categoría «bitesize», que significa que son relativamente fáciles resolver, y no quería estar haciendo búsquedas en la web de Launchpad cada x tiempo. Por otra parte, también me inspiré en Jono Bacon, que publicó un post en el que describía una aplicación parecida. Finalmente, era una buena oportunidad para conocer mejor el ciclo de desarrollo en Ubuntu y sus herramientas y poner en práctica lo aprendido sobre Python.

La aplicación está escrita en Python y usa GTK. Como sistema de control de versiones usa bzr, ya que es el que mejor integrado está con Launchpad. Mencionar también que actualmente la aplicación está traducida a media docena de idiomas, aunque por el momento falta el castellano 😉

Si tenéis ganas de probar Indicator-Bug tengo un PPA dónde se publican paquetes diarios con las últimas mejoras y ahora estoy intentando que lo acepten en el repositorio universe de Ubuntu para que los usuarios de Oneiric puedan instalarlo sin tener que añadir el PPA.

Para instalar Indicator-Bug:

$ sudo apt-add-repository ppa:oier/indicator-bug
$ sudo apt-get update & sudo apt-get install indicator-bug

Agradecería mucho que lo probéis y me mandéis sugerencias, mejoras o incluso un bug-report si descubrís errores. Para lo último, como hace uso de Apport, os debería de dar la opción de mandar un informe de fallos automáticamente si la aplicación deja de funcionar repentinamente.

ComFusion 3

PolloLinux nos escribe para que nos hagamos eco de la nueva versión 3 de la distribución ComFusion:

ComFusion 3 es una distribucion basada en Ubuntu Lucid Lynx, (versión estable y con soporte actual de Ubuntu), que tiene como objetivo simplificar Linux para el usuario nobel que proviene de otros sistemas operativos. Intentando que, mediante la combinación de programas, scripts y estilos visuales, (compiz , xcompmgr, cairo-composite, etc), utilizar Linux sea algo mas apetecible, simple, y divertido para los recien llegados…

Con ComFusion 3, podrá disponer de 3 escritorios distintos;

1- Gnome-ComFusion, un escritorio tradicional, pero con muchas

mejoras que ya irá descubriendo si sigue leyendo este documento, está orientado como siempre para ordenadores estandard que no tengan demasiados problemas de recursos.

2-Lxde-ComFusion,

un escritorio que sigue el mismo look que Gnome, pero reemplazando Nautilus por Pcmanfm, el panel de Gnome por Lxpanel, pero dejando a Metacity como gestor de ventanas, lo cual mejora muchisimo el rendimiento, funciona perfectamente con compiz lo que lo hace aparte de ser el primer escritorio LXDE con efectos compiz, ser perfecto para ordenadores más limitados de recursos.

Hemos fusionado Lxde con Gnome cambiando el gestor de ventanas por defecto Openbox por Metacity, haciendo que se pueda utilizar ComPiz con LxDE.

Con esto conseguimos un escritorio ligero que utiliza Pcmanfm como gestor de archivos, LxPanel como panel de Escritorio, y Metacity con composite por defecto como gestor de ventanas.

3-Openbox-ComFusion,

escritorio con el mismo look que sus hermanos mayores pero con Openbox como gestor, optimizado y modificado para ser el más liviano, utiliza como efecto visual por defecto Cairo-Composite, para que hasta los escritorios mas humildes puedan gozar de ser un poco mas vistosos.

Hemos remasterizado un Openbox para que sea mas “usable”, y “configurable”.  Además Dispone del mediacenter Xmbc, personalizado con un nuevo skin.

Todo esto siempre sin perder ni un ápice de potencia, agilidad y fiabilidad que proporciona un sistema Linux basado en Ubuntu.

Pagina Web:   http://comfusion.es/drupal/