Google Chrome 23 con “Do Not Track” y control mejorado de Permisos

Chrome, el navegador web de Google, acaba de llegar a su versión estable número 23 (anuncio oficial). Hay algunas novedades que vale la pena mencionar.

La primera, exclusiva sólo para los usuarios de Microsoft Windows (¬_¬), es la activación de manera predeterminada de la aceleración de video por GPU para la decodificación de video (por ejemplo, cuando se ven videos en YouTube), con el positivo efecto colateral de un menor consumo de energía, o sea, una mayor duración de la batería en dispositivos móviles (en teoría, hasta un 25% más).

Pero bueno, lo anterior es algo que no puedo probar (¡no voy a instalar Windows sólo por eso!), así que vamos a creerle a los chicos de Google. Lo que si pude probar, son dos nuevas e interesantes características en Chrome 23.

Ahora es mucho más sencillo controlar diversos permisos por sitio web, directamente cuando los estemos visitando, dando clic en el icono a la izquierda del URL actual, tal y como podemos apreciar en la siguiente imagen.

[ Google Chrome 23 - Control mejorado de Permisos ]

En el ejemplo anterior, podemos observar cómo están bloquedas las ventanas emergentes (pop-ups), pero dando clic ahí mismo podemos habilitarlas para sólo ese sitio web. Sin duda, una muy buena idea.

La otra novedad… perdón, no es novedad (los chicos de Mozilla la incluyeron desde Firefox 4 Beta 11 y Firefox 5 estable), pero si es una nueva característica en Google Chrome, es el uso de la cabecera HTTP denominada “Do Not Track“, cuyo objetivo es detener el seguimiento de nuestras preferencias de navegación por herramientas conductuales de publicidad de terceros, aunque su efectividad dependerá si los sitios web que visitemos ya ofrecen soporte para dicha cabecera.

Cabe mencionar que el “Do Not Track” no viene habilitado de manera predeterminada. Para hacerlo, debemos ir a la página de configuración de Google Chrome, y dar clic en el vínculo “Mostrar configuración avanzada…“, para poder ver lo siguiente.

[ Google Chrome 23 - Do Not Track 01]

Al dar clic en la casilla de verificación correspondiente, asomará un mensaje descriptivo de esta nueva característica.

[ Google Chrome 23 - Do Not Track 02]

Hasta aquí las novedades… si, yo también esperaba más.

Descargar Google Chrome 23 en Español

Enlaces a los instaladores completos de Google Chrome 23 Estable, según tu sistema:

No hay que perder de vista que los instaladores binarios de Linux agregarán de manera automática el repositorio oficial de Google que corresponda a la distro utilizada.

Actualizando a Google Chrome 23 Estable en Linux

Si ya tienes Google Chrome instalado, no hay necesidad de una instalación nueva, basta con realizar una actualización. Si en tu distro aún no han sido actualizados los repositorios, no desesperes, es cuestión de algunas horas para que ocurra.

En Ubuntu y Debian:

$ sudo apt-get update && sudo apt-get upgrade

En Fedora:

$ sudo yum check-update && sudo yum update

En OpenSUSE:

$ sudo zypper refresh && sudo zypper update

Instalar Chromium y Google Chrome 23 en ArchLinux

En el caso particular de ArchLinux, en el repositorio [extra] podemos encontrar el paquete chromium.

$ sudo pacman -Sy chromium

Si prefieres no usar Chromium, en AUR puedes encontrar el paquete google-chrome.

$ yaourt -Sy google-chrome

ConsoleKit es reemplazado por systemd-logind en ArchLinux

¡Más cambios en ArchLinux! Hoy amanecimos con la tremenda noticia de que ConsoleKit ha sido eliminado de los repositorios oficiales, y que toda su funcionalidad ahora es responsabilidad de systemd-logind.

¡El pánico se apodera de todos los archeros del mundo! ¡Es el apocalipsis que los mayas predijeron! … Jajaja, nada más alejado de la realidad. Sin embargo, el anuncio es demasiado escueto y no proporciona mayores detalles sobre las implicaciones de este cambio, así que me puse a investigar de inmediato y a hacer varias pruebas. Aquí el resultado.

¿Qué rayos es eso de ConsoleKit y systemd-logind?

Por si no lo sabías, ConsoleKit era utilizado para dos cosas principalmente: Permitir a usuarios normales (no root) montar dispositivos removibles (como pendrives o memorias USB), así como permitir suspender, reiniciar y apagar el sistema. Incluso, es muy probable que en tu archivo ~/.xinitrc tengas algo como ésto:

exec ck-launch-session openbox-session

El “ck-launch-session” era lo que permitía que tu usuario pudiera hacer lo que mencioné previamente. Ahora el encargado de hacerlo es systemd-logind, y aunque este detalle no se menciona en el anuncio oficial, si podemos encontrarlo en una reciente modificación en la wiki de Arch, y cito textualmente:

All PolicyKit actions like suspending the system or mounting external drives will work out of the box.

¡Así que no hay nada que temer! Sólo hay un “pequeño” requisito… ¡ya estar usando systemd!

Como observación adicional, con logind las X (el entorno gráfico) se ejecutan en el mismo tty donde se inició sesión, mientras que con ck-launch-session se creaba una nueva sesión.

¿Qué implica que ConsoleKit ya no esté en los repositorios?

En instalaciones existentes, al actualizar el sistema no se eliminará ConsoleKit, o sea, que aún puede seguirse usando, aunque ya no tiene sentido.

En instalaciones nuevas, ya no podrá instalarse ConsoleKit (aunque parece que pronto estará disponible desde AUR, pero repito, no tiene sentido), lo cual implícitamente nos estará obligando a realizar una instalación basada en systemd.

¿Qué cambios debo hacer en mi sistema?

No mucho. Primero, ¡actualiza!

sudo pacman -Syu

Es muy importante actualizar, para que los últimos cambios se apliquen, pues incluyen paquetes a los cuales se les ha eliminado su respectiva dependencia con ConsoleKit.

Ahora, ya puedes eliminar ConsoleKit, no debes tener problemas de dependencias.

sudo pacman -R consolekit

En caso de ser necesario, no olvides eliminar “ck-launch-session” de tu archivo ~/.xinitrc.

Eso es todo, ya puedes reiniciar y verificar que todo funcione bien.

Adicionalmente, les recomiendo usar el siguiente comando para ver información sobre la sesión actual.

loginctl

Para información más detallada, pueden usar lo siguiente.

loginctl show-session $XDG_SESSION_ID

¿Eso es todo?

¡Si! Bye bye ConsoleKit :-)

Conoce los nuevos Nexus 4, 7 y 10 de Google

Google anunció apenas hace unas horas la nueva línea Nexus (fabricados por LG) con tres dispositivos, cada uno de un tamaño diferente, donde con sólo ingresar a nuestra cuenta de Google podemos acceder a nuestras fotos, correos, contactos, marcadores y todo el entretenimiento de Google Play para Android (ahora con más contenido y con soporte para más países, España incluido).

Los nuevos Nexus

Todos ellos vienen con Android 4.2 Jelly Bean, con todas las novedades de esta nueva versión.

Los modelos son:

  • Nexus 4, con una pantalla de 4.7″ de resolución 1280×768 pixeles a 320 ppi. Características técnicas: Procesador quad-core Snapdragon S4, 2GB de RAM, almacanamiento interno de 8GB o 16GB, puertos micro USBy SlimPort HDMI, carga wireless, cámara frontal de 8MP y cámara trasera de 1.3MP.

  • Nexus 7, el ya conocido por todos, ahora con modelos de 16 y 32 GB de almacenamiento interno, con un procesador quad-core.

  • Nexus 10, con una asombrosa pantalla de 10.055″ con una resolución de 2560×1600 pixeles a 300ppi, ¡más de 4 millones de pixeles en tus manos! (Como punto comparativo, el dichoso Retina Display de Apple tiene una resolución de 2048×1536 a 264ppi). La duración de su batería es algo que vale la pena mencionar, ¡hasta 9 horas de reproducción contínua de video!. Más características técnicas: Procesador dual-core A15, Mali T604 GPU, 2GB de RAM, cámara trasera de 5MP, cámara delatera de 1.9MP, puertos micro USB y micro HDMI.

Para más información, pueden consultar el anuncio oficial.

Creo que ya se que le pediré a Santa Claus esta Navidad :-)

¿AUR caído? ¡Usa el respaldo AUR3! [ArchLinux]

Desde ayer viernes está no disponible (error 503) el repositorio comunitario AUR de nuestra querida distro ArchLinux. ¿Te urge mucho instalar o actualizar algo desde AUR? ¡No te preocupes! Existe un respaldo completo de AUR, llamado AUR3, el cual se actualiza diariamente (gracias a mi tocayo @yoyo308 por el aviso).

Veamos las instrucciones paso a paso para instalar un paquete desde AUR3:

  1. Descargamos el bash script (empaquetado y comprimido) de AUR3.

    wget http://aur3.org/mirror/aur3/aur3.tar.gz
  2. Descomprimimos y nos cambiamos a la carpeta correspondiente.

    tar xzf aur3.tar.gz && cd aur3
  3. Le damos permisos de ejecución al script.

    chmod u+x aur3.sh
  4. El script utiliza curl, jshon y gnupg, así que verifica si los tienes instalados.

    sudo pacman -S curl jshon gnupg
  5. Para buscar algún paquete usamos:

    ./aur3.sh -n <paquete_a_buscar>
  6. Para más información de un paquete específico:

    ./aur3.sh -i <paquete>
  7. Para descargar las especificaciones de un paquete:

    ./aur3.sh -g <paquete>
  8. Ya descargado, descomprimimos y nos cambiamos a la carpeta correspondiente:

    tar xzf <paquete>.tar.gz && cd <paquete>
  9. Creamos el paquete a instalar:

    makepkg
  10. Instalamos el paquete resultante:

    sudo pacman -U <paquete>-<version>.pkg.tar.xz

¡Eso es todo! :-)

¿Tu navegador predeterminado es Firefox en Linux, pero tus enlaces se abren en Chrome / Chromium?

Firefox VS ChromeHace unos días me topé con algo raro. A pesar de tener a Firefox como navegador web predeterminado en Linux, al dar clic en enlaces en diversas aplicaciones (Pidgin y Hotot, entre otras), éstos se abrían en Chromium / Chrome. ¿Cómo solucionar este raro comportamiento? ¡Muy sencillo!

Varias aplicaciones (como las que acabo de mencionar), utilizan a XdgUtils como API para comunicarse con el escritorio. Por lo tanto, sólo tenemos que informarle sobre qué navegador web es el que deseamos se vincule con el protocolo HTTP (y HTTPS), y eso lo hacemos ejecutando los siguientes comando en la terminal:

xdg-mime default firefox.desktop x-scheme-handler/http
xdg-mime default firefox.desktop x-scheme-handler/https

¡Eso es todo!

Visto en StackExchange.

Instalación y configuración del entorno LAMP (Apache + PHP + MySQL) en ArchLinux con systemd

ArchLinux systemd LAMP

Ahora que las nuevas instalaciones de ArchLinux usan systemd de manera predeterminada, algunas cosas han cambiado, entre ellas, ciertos detalles en la instalación y configuración del entorno LAMP (Linux + Apache + MySQL + PHP).

Aprovechando que hace unos días realicé una instalación limpia en mi equipo de producción, también lo hice con dicha instalación y configuración, misma que comparto con ustedes en el presente tutorial.

[Actualización 2014-03-10] ¡Ha llegado Apache 2.4 a ArchLinux! Es un cambio importante y requiere nuestra intervención manual para hacer que nuestro servidor LAMP vuelva a funcionar sin problemas.

Paso 1. Instalación de los paquetes necesarios

Antes que nada, instalemos los paquetes básicos que necesitaremos.

sudo pacman -S apache php php-apache mysql

Paso 2. Ejecutando Apache

Ejecutemos (vía systemd) nuestro servidor web Apache con las configuraciones predeterminadas:

sudo systemctl start httpd.service

Adicionalmente, para que Apache se ejecute de manera automática en los siguientes booteos, usa:

sudo systemctl enable httpd.service

Ahora bien, ¿cómo se llama tu servidor? Eso lo tienes establecido en dos archivos: /etc/hostname y /etc/hosts. Lo más común es que en ambos tengas localhost. Si no es así, reemplaza “localhost” por tu nombre de servidor en el resto del tutorial.

En tu navegador web favorito, entra a http://localhost/ o http://127.0.0.1/ donde veremos algo similar a la siguiente captura de pantalla.

Apache corriendo en ArchLinux con systemd

¡Muy feo! ¿verdad? Es porque localhost no tiene ningún contenido, ¡así que vamos a solucionarlo!.

Paso 3. Creando nuestro index.html

Antes de crear nuestro index.html, debemos tener en cuenta dos detalles que se encuentran establecidos en /etc/httpd/conf/httpd.conf (el archivo de configuración principal de Apache en ArchLinux):

  • Durante el booteo del sistema, el encargado de ejecutar Apache es root, pero por motivos de seguridad, de inmediato se cambia al usuario http (que a su vez pertenece al grupo http).

  • La carpeta predeterminada para el contenido de localhost es /srv/http, cuyo propietario es root de manera predeterminada.

Debido a lo anterior, debemos realizar algunas acciones para poder empezar a crear contenido en nuestro servidor web local.

  1. Primero, debemos agregar nuestro usuario al grupo http.

    sudo gpasswd -a miusuario http

    Debemos cerrar nuestra sesión actual y volver a loguearnos para que el cambio sea aplicado.

  2. Ahora, debemos ceder la propiedad de root a http (tanto para el usuario como para el grupo) de manera recursiva para /srv/http.

    sudo chown -R http:http /srv/http
  3. Debemos establecer permisos de escritura para el grupo http (al cual nos hemos agregado) para la misma carpeta (y todo su contenido).

    sudo chmod -R g+w /srv/http

Ahora si, ya podemos crear nuestro index.html, el cual puede ser desde una simple línea de texto …

echo 'Hola Mundo!' > /srv/http/index.html

… hasta algo más elaborado (usa tu editor preferido y guardalo como index.html en /srv/http/).

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="utf-8">
    <title>¡Bienvenidos a ArchLinux!</title>
    <style>
        body { margin: 0; font-family: Helvetica, Arial, sans-serif; }
        h1 { background: #ccc; margin: 0; padding: 10px; }
        #contenido { margin: 10px auto; padding: 10px; width: 500px; }
    </style>
</head>
<body>
<div id="contenido">
    <h1>¡Bienvenido!</h1>
    <p><strong>Apache</strong> corriendo bajo <strong>ArchLinux</strong> con <strong>systemd</strong>.</p>
</div>
</body>
</html>

index.html en funcionamiento

Paso 4. Configurando PHP

Este paso es el típico de siempre. Vamos a configurar Apache para que reconozca a PHP.

Primero, como root, abre el archivo /etc/httpd/conf/httpd.conf con tu editor favorito. Por ejemplo:

sudo vim /etc/httpd/conf/httpd.conf

Ahí, realiza los siguientes cambios:

  1. En la lista que tiene todos los “LoadModule“, y después de LoadModule dir_module modules/mod_dir.so, agrega la línea:

    LoadModule php5_module modules/libphp5.so
  2. Al final de la lista de todos los “Include“, agrega la línea:

    Include conf/extra/php5_module.conf
  3. Asegúrate que la siguiente línea no esté comentada (que no tenga “#” al inicio) en la sección :

    TypesConfig conf/mime.types
  4. Descomenta (elimina el “#” del inicio) la siguiente línea:

    MIMEMagicFile conf/magic

Ahora, como root, abre el archivo /etc/httpd/conf/mime.types con tu editor preferido (¡seguro que es vim!). Por ejemplo:

sudo vim /etc/httpd/conf/mime.types

Al final de dicho archivo agrega la línea:

application/x-httpd-php5            php php5

¡Listo! Reiniciemos Apache para aplicar los cambios:

sudo systemctl restart httpd.service

Para probar que Apache ya reconoce a PHP, vamos a crear el típico archivo de ejemplo:

echo '<?php phpinfo(); ?>' > /srv/http/info.php

Y finalmente, para verlo entra a tu navegador web, y entra a http://localhost/info.php

PHP reconocido por Apache

Paso 5. Configurando MySQL

Primero, vamos a ejecutar de inmediato el servidor de base de datos MySQL con:

sudo systemctl start mysqld.service

Para que se ejecute en cada booteo, usamos:

sudo systemctl enable mysqld.service

Y antes de que hagamos cualquier otra cosa, debemos establecer la contraseña del usuario “root” de MySQL (no es el mismo que el root del sistema). La forma más sencilla de hacerlo, es ejecutar la siguiente utilería:

mysql_secure_installation

Lo anterior nos preguntará primero la contraseña actual de root, la cual no existe, así que debemos dar [Enter], y entonces escribir (y confirmar) la nueva contraseña. Adicionalmente, la utilería nos preguntará algunos detalles adicionales, a los cuales se sugiere responder las opciones predeterminadas.

Ahora, tenemos que decirle a PHP de la existencia de MySQL. Vamos a abrir el archivo /etc/php/php.ini con tu editor favorito …

sudo vim /etc/php/php.ini

… y descomentar (eliminar el “;” al inicio) las siguientes líneas:

 extension=mysqli.so
 extension=mysql.so

Si deseas realizar alguna modificación en los parámetros de MySQL debes hacerlo editando el archivo /etc/mysql/my.cnf.

Finalmente, reiniciemos Apache y MySQL para aplicar los cambios realizados.

sudo systemctl restart httpd.service
sudo systemctl restart mysqld.service

Comentarios Adicionales

Aunque ya los mencioné, no olviden que los archivos de configuración son:

  • Apache: /etc/httpd/conf/httpd.conf
  • PHP: /etc/php/php.ini
  • MySQL: /etc/mysql/my.cnf

Tampoco olviden que bajo systemd, se utilizan los comandos:

  • Habilitar para cada booteo: sudo systemctl enable <servicio>
  • Ejecutar de inmediato: sudo systemctl start <servicio>
  • Detener de inmediato: sudo systemctl stop <servicio>
  • Reiniciar de inmediato: sudo systemctl restart <servicio>
  • Ver el estado del servicio: sudo systemctl status <servicio>

Donde <servicio> puede ser alguno de los siguientes:

  • Apache: httpd.service
  • MySQL: mysqld.service

Por último, no olviden consultar la documentación oficial para más información:

Firefox 16 con Mozilla Apps, CSS3 sin prefijos, Recolector Incremental de Basura y Soporte Opus

Firefox 16 - Acerca de

Aún sin anuncio oficial por parte de los chicos de Mozilla (aquí el anuncio oficial) Ya podemos descargar y disfrutar la nueva versión estable de su navegador web: Firefox 16.

Novedades de Firefox 16 para Usuarios

La primera de ellas (de la cual ya hemos platicado), es el soporte para Web Apps, más especificamente, para las Mozilla Apps (todas ellas aún en estado demo). ¿Eres desarrollador y te gustaría crear tus apps para Firefox? Te recomiendo visites estos dos sitios.

Firefox 16 - Mozilla Apps

Originalmente se pensaba que Firefox 15 introduciría el soporte nativo al formato PDF, pero no estaba habilitado de manera predeterminada. Sinceramente pensé que en Firefox 16 ya lo estaría, pero me equivoqué. Para utilizarlo todavía tenemos que habilitarlo entrando a about:config y cambiar el valor de la propiedad pdfjs.disabled a false y deshabilitar el plugin de Adobe Reader (o algún otro similar que tengan instalado).

Firefox 16 - Visor PDF mejorado

Otra novedad, que también sigue deshabilitada de manera predeterminada, es la nueva interfaz para el gestor de descargas. Para habilitarlo entramos de nuevo a about:config y cambiamos el valor de la propiedad browser.download.useToolkitUI a false.

Firefox 16 - Descargas

También hay un par de novedades que no son visibles para los usuarios, pero que sin dudarlo mejorarán su experiencia de navegación y disfrute multimedia: Soporte para recolección incremental de basura (incremental garbage collection) y soporte (ahora habilitado de manera predeterminada) para el nuevo codec de audio Opus.

Novedades de Firefox 16 para Desarrolladores

Ahora, veamos las novedades para desarrolladores, ¡qué son muchas! :-)

La relativamente nueva Developer Bar (introducida en Firefox 16 nightly e incluso disponible, pero oculta, en Firefox 15 Estable), ha sufrido interesantes mejoras en esta versión, se ve mejor (ya tiene unos bonitos iconos) y ya está traducida al español.

Firefox 16 - Developer Bar

Además, el Scratchpad ya incluye la opción para abrir archivos recientes.

Firefox 16 - Archivos recientes en Scratchpad

Algo también muy esperado es que las animaciones, transiciones, transformaciones y gradientes de CSS3 ya no requieren del prefijo -moz. Igualmente, ya no se usará mozIndexedDB, si no IndexedDB. Firefox poniendo el ejemplo, ojalá el resto de los navegadores hagan lo propio. Les recomiendo ampliamente leer el post respectivo en Mozilla Hacks, para más información sobre lo anterior y muchos más detalles que todo desarrollador web debe conocer.

Descargas Directas de Firefox 16 en Español

[Actualización 11-Octubre-2012] Enlaces de descarga actualizados a Firefox 16.0.1, debido a problemas de seguridad con Firefox 16.0. Aquí más información

Firefox 16.0.1 en Español para Windows:

Firefox 16.0.1 en Español para MacOS X:

Firefox 16.0.1 en Español para Linux (32 bits):

Firefox 16.0.1 en Español para Linux (64 bits):

Cuando ya se haga el anuncio oficial, también podrán visitar la página oficial de descargas.

¡A disfrutar de Firefox 16!

Google Chrome 22 con Pointer Lock JavaScript API

Google Chrome LogoNueva versión estable de Google Chrome, y prácticamente ninguna novedad que valga la pena mencionar (incluso dudé mucho en publicar este post). ¿Qué sucede chicos de Google? ¿Ya se les acabaron las ideas, la creatividad?

En el anuncio oficial se menciona la implementación del Pointer Lock JavaScript API (con lo cual las aplicaciones 3D, como los juegos de primera persona, puedan controlar la perspectiva de manera natural con el mouse), así como mejoras en el soporte para Windows 8 y retina displays.

Eso es todo ¬¬

Descargar Google Chrome 22 en Español

Enlaces a los instaladores completos de Google Chrome 22 Estable, según tu sistema:

No hay que perder de vista que los instaladores binarios de Linux agregarán de manera automática el repositorio oficial de Google que corresponda a la distro utilizada.

Actualizando a Google Chrome 22 Estable en Linux

Si ya tienes Google Chrome instalado, no hay necesidad de una instalación nueva, basta con realizar una actualización. Si en tu distro aún no han sido actualizados los repositorios, no desesperes, es cuestión de algunas horas para que ocurra.

En Ubuntu y Debian:

$ sudo apt-get update && sudo apt-get upgrade

En Fedora:

$ sudo yum check-update && sudo yum update

En OpenSUSE:

$ sudo zypper refresh && sudo zypper update

Avisos de ArchLinux en nuestro Escritorio

Avisos de ArchLinux en nuestro Escritorio

Algo he notado los últimos meses: Muchos usuarios de ArchLinux presentan problemas luego de alguna actualización. Algunos ejemplos: La vez que el directorio /lib se convirtió en symlink y su contenido fue movido a /usr/lib, cambios en el archivo /etc/rc.conf debido a la migración a systemd y recientemente una actualización de fontconfig que requería eliminar previamente de manera manual algunos symlinks.

¿Por qué los usuarios tuvieron esos problemas? ¡Porque jamás se enteraron que dichas actualizaciones requerían de nuestra especial atención!

Como usuarios de ArchLinux somos responsables de lo que sucede en nuestro sistema, y siempre (déjenme repetirlo, ¡SIEMPRE!) debemos estar pendientes de los avisos oficiales de los desarrolladores de nuestra querida distro, precisamente para evitar contratiempos y dolores de cabeza.

Ahora bien, como yo sé que muchos no son afectos a diariamente leer feeds (como un servidor, que lo primero que hace por las mañanas es abrir Google Reader para enterarme de las principales noticias oficiales), aquí les dejo mi sugerencia: ¡Mostrar los avisos de ArchLinux en nuestro Escritorio!, así podemos enterarnos de cualquier cosa al momento de entrar a nuestro entorno gráfico. ¿Cómo hacerlo? Lo más sencillo es usando el muy conocido Conky (ver imagen al inicio de este post).

Gracias a que Conky soporta feeds nativamente, es muy fácil incorporar el RSS de ArchLinux:

${rss http://www.archlinux.org/feeds/news/ 1 item_titles 1 }

Lo anterior debe ser incluido en la sección TEXT del archivo ~/.conkyrc.

¡Tip! El último número indica la cantidad de anuncios a mostrar, 1 = sólo el último aviso.

¿Qué hacer entonces si vemos un aviso nuevo? ¡Ir de inmediato a leerlo a archlinux.org/news antes de realizar cualquier actualización con sudo pacman -Syu!

¡Extra! Y antes de que me pidan mi ~/.conkyrc completo, aquí lo tienen.

Migrando a systemd en ArchLinux

Aunque ya son meses de planes y avisos, hace apenas un par de semanas se dió a conocer que ArchLinux reemplazará sysvinit (así como initscripts) por systemd, lo cual ha causado mucha polémica. El cambio ha sido gradual: Hace tres meses, udev fue reemplazado por (fusionado en) el paquete systemd-tools, y hace apenas unas horas este último, al igual que libsystemd, acaban de ser reemplazados por el mismísimo paquete systemd. La migración definitiva está muy próxima, ¡debes estar preparado!

Si eres usuario de ArchLinux seguro te estás preguntando: ¿Debemos migrar en este momento?, ¿qué implica usar systemd?, ¿qué ventajas me ofrece con respecto a sysvinit?, o peor aún, ¿qué rayos es eso de systemd y sysvinit?

Luego de haber leído bastante documentación (referencias al final de este post) y de haber realizado varias pruebas (primero en una máquina virtual y luego en mi sistema principal), trataré de responder a cada una de esas preguntas.

Un poco de historia

En los sistemas operativos basados en UNIX (Linux, FreeBSD, MacOS X, etc) existe un proceso especial, el primero generado por el kernel y en ejecutarse durante el booteo, conocido como init (el cual obviamente tiene el PID número 1), el cual se encarga de ejecutar el resto de los procesos del sistema, e incluso sigue activo como daemon (comunicándose constantemente con el kernel) hasta que el usuario apaga o reinicia el equipo, momento en que dicho proceso ejecuta todo lo necesario para cerrar el sistema.

Desde sus inicios, y hasta la fecha, la mayoría de las distros de Linux utilizan sysvinit. A primera vista podemos darnos cuenta que su nombre proviene de SysV init, o UNIX System V init system, con lo cual nos damos una idea de lo veterano que es este proceso de inicialización (por no decir viejo y obsoleto).

¿Qué alternativas modernas existen?

  • Existe launchd, pero es exclusivo del sistema MacOS X.

  • En 2006 fue liberado Upstart, desarrollado por Scott James Remnant (ex empleado de Canonical, ahora trabaja en Google). Este proceso es usado principalmente por Ubuntu y Chrome OS. Algunas otras distros, como Fedora, lo implementaron en algunas de sus versiones, pero han optado por una mejor opción (sigue leyendo).

  • ¡Y llegó systemd!, liberado apenas en 2010. Su desarrollador principal es Lennart Poettering, creador del conocido PulseAudio (actualmente labora para RedHat). Debido a sus fantásticas características, hoy día es usado de manera predeterminada en distros populares como Fedora y OpenSUSE, por lo que podemos inferir que, a pesar de su corta vida, systemd ya está listo para nivel producción.

Beneficios de systemd

Los principales beneficios de systemd comparado con sysvinit / initscripts son:

  • Tiene capacidades “hotplug”, o sea, systemd asume que todos los recursos del sistema pueden aparecer o desaparecer en cualquier momento. Si conectamos un disco duro externo después de que systemd ha iniciado, se encargará de aplicarle fsck y montarlo correctamente, a diferencia de initscripts que necesita que todos los discos se encuentren enumerados y listos cuando ejecuta fsck para luego montarlos.

  • Podemos saber el estado del sistema en cualquier momento, ya que systemd lleva un registro (journal) mediante cgroups (ya no más PIDs) de todos los daemons y procesos que ha iniciado, quién es el dueño, cuál ha fallado, etc.

  • Es modular. Todo el contenido ejecutado por initscripts en /etc/rc.sysinit ahora es dividido en varios servicios independientes, cada uno de ellos bien documentado y de fácil comprensión. ¡Puedes crear tus propios servicios!

  • Actualmente udev (que incluso ha sido fusionado en systemd) y dbus son usados (inapropiadamente) para iniciar daemons y servicios sobre demanda. Con systemd todo ese trabajo está cubierto, pues es una de sus funciones principales.

  • Actualmente debemos especificar y tener mucho cuidado en el orden de los daemons en la sección DAEMONS del archivo /etc/rc.config. Con systemd se utiliza la activación de daemons por medio de sockets, aportando capacidades de paralelización.

  • Actualmente es bastante complicado implementar seguridad vía sandboxing a cada script rc (/etc/rc.sysinit,/etc/rc.single,/etc/rc.multi, etc). Con systemd sólo necesitamos agregar unas simples opciones de configuración a los archivos de cada unit (de las cuales hablaré más adelante) para aislarlas del sistema de diversas maneras.

  • Los archivos de servicio de systemd pueden ser escritos y distribuidos por cualquier usuario, en vez de los scripts rc escritos específicamente para cada distro. De esta manera, la colaboración entre usuarios y desarrolladores de systemd puede lograr la creación de servicios “perfectos”, que deberían funcionar en cualquier distro.

  • Por origen, systemd es un proyecto “cross-distro“, donde colaboran desarrolladores de todas las grandes y muchas pequeñas distros.

  • Y como ya se lo pueden imaginar, ¡systemd es muy rápido!. Es notable la reducción del tiempo al momento del booteo, incluso al cerrar el sistema es mucho, ¡pero mucho más rápido! (comparado con sysvinit/initscripts, por supuesto). Toda esta velocidad es básicamente un “efecto secundario” de todas las bondades descritas en los puntos anteriores.

La lista anterior no es exhaustiva, ¡hay más beneficios al usar systemd!

Preparando nuestro ArchLinux para systemd

Seguro que después de haber leído la lista anterior quieres salir corriendo para instalar systemd… ¡no lo hagas! Antes necesitas preparar tu sistema antes de la migración.

Lo primero que debemos hacer, es revisar nuestro querido y viejo archivo /etc/rc.conf (el cual es usado por initscripts), pues prácticamente ya no será utilizado con systemd, por lo que debemos migrar toda las configuraciones ahí contenidas por el nuevo esquema de configuración:

  • El valor de HOSTNAME ahora se establece en el archivo /etc/hostname (el nombre de nuestro hostname, por ejemplo localhost, es lo único que debe tener dicho archivo). También hay que ajustar el archivo /etc/hosts para que coincidan.

  • El valor de TIMEZONE ahora se establece por medio de un symlink de /etc/localtime a /usr/share/zoneinfo/<ZONA>/<SUBZONA> (reemplaza <ZONA> y <SUBZONA> según tu ubicación geográfica). Por ejemplo, para México:

    ln -s /usr/share/zoneinfo/America/Mexico_City /etc/localtime
  • Los valores de KEYMAP, CONSOLEFONT y CONSOLEMAP ahora se establecen en el archivo /etc/vconsole.conf (el cual debes crear).

    • KEYMAP especifica la distribución del teclado. Las opciones disponibles se encuentran en /usr/share/kbd/keymaps.

    • CONSOLEFONT especifica la fuente (tipo de letra) a usar en la consola (el programa setfont toma este valor durante el booteo). Las opciones disponibles se encuentran en /usr/share/kbd/consolefonts. También puede usarse FONT. Esta configuración es opcional.

    • CONSOLEMAP especifica el mapa de consola correspondiente, que también es leído por setfont. Las opciones disponibles se encuentran en /usr/share/kbd/consoletrans. También puede usarse FONT_MAP. Esta configuración es opcional.

    Por ejemplo:

    KEYMAP=es
    CONSOLEFONT=lat9w-16
    CONSOLEMAP=8859-1_to_uni
  • El valor de LOCALE (el cual especifica el idioma del sistema y de la mayoría de las aplicaciones) ahora se establece en el archivo /etc/locale.gen, donde debemos descomentar (eliminar el “#” al inicio de la línea) la localización deseada. Por ejemplo, para soporte UTF-8 en Español para México:

    ...
    #es_HN ISO-8859-1
    es_MX.UTF-8 UTF-8
    #es_MX ISO-8859-1
    ...

    Para aplicar los cambios realizados, debemos ejecutar el comando locale-gen.

    También es buena idea establecer dicho valor con la variable LANG en el archivo /etc/locale.conf, donde también podemos establecer otros valores interesantes, como LC_COLLATE, que especifica cómo se ordenan los archivos al ejecutar el comando ls. Ejemplo:

    LANG="es_MX.UTF-8"
    LC_COLLATE="C"
  • Los valores (lista separada por espacios) de MODULES ahora deben establecerse en uno o más archivos del tipo <MODULO>.conf: En el directorio /etc/modules-load.d/ los módulos para ser cargados incondicionalmente durante el booteo, y en /etc/modprobe.d/ (normalmente usado por udev para cargar módulos sobre demanda) los módulos que no se auto ejecutarán (anteponiendo la palabra blacklist). Ejemplos:

    # /etc/modules-load.d/virtualbox.conf
    vboxdrv
    # /etc/modprobe.d/nobeep.conf
    blacklist pcspkr

Puedes poner varios módulos en un sólo archivo .conf, pero cada uno en una línea aparte.

¿Y los valores de DAEMONS? Esos no los cambiaremos por el momento (es lo único que debemos dejar habilitado en /etc/rc.conf). Lo que si haremos es tener muy presente qué daemons son los que ahí se encuentran. Posteriormente (luego de instalar systemd), migraremos cada daemon a su respectiva unidad de servicio (no se desesperen, ya llegaremos a este punto).

Instalación de systemd en ArchLinux

¡Por fin! Luego de tanta introducción y preparación, hemos llegado al punto clave, ¡instalemos systemd en nuestro querido ArchLinux!

  1. Antes que nada, ¡actualiza tu sistema!

    sudo pacman -Syu
  2. Ya debes tener instalado el paquete systemd (vuelve a leer el primer párrafo de este post). De todas formas, lo puedes instalar con el comando:

    sudo pacman -S systemd
  3. A pesar de que ya instalamos systemd, si reiniciamos nuestro equipo, de nuevo sysvinit e initscripts se ejecutarán, ya que aún estamos en un “esquema mixto” (para ver que todo funciona bien). Lo que haremos entonces, es agregar init=/bin/systemd a los parámetros del kernel del bootloader que utilices.

    • Si usas Grub Legacy, edita el archivo /boot/grub/menu.lst y modifica la línea que inicia con kernel.

      title Arch Linux
      root (hd0,0)
      kernel /vmlinuz-linux root=/dev/sda3 ro quiet init=/bin/systemd
      initrd /initramfs-linux.img
    • Si usas Grub2, edita el archivo /etc/default/grub y modifica la línea que inicia con GRUB_CMDLINE_LINUX_DEFAULT.

      GRUB_DISTRIBUTOR="Arch Linux"
      GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"
      GRUB_CMDLINE_LINUX=""

      Es necesario actualizar Grub2 con el comando

      sudo grub-mkconfig -o /boot/grub/grub.cfg
    • Si usas syslinux, edita el archivo /boot/syslinux/syslinux.cfg y modifica la línea que inicia con APPEND.

      LABEL arch
      MENU LABEL Arch Linux
      LINUX ../vmlinuz-linux
      APPEND root=/dev/sda3 ro quiet init=/bin/systemd
      INITRD ../initramfs-linux.img

    ¡Nota! A pesar de que en los ejemplos incluí el parámetro quiet, es recomendable no incluirlo las primeras veces que iniciamos el sistema con systemd, para poder verificar que todo esté funcionando adecuadamente.

  4. ¡Reinicia el sistema! Ahora el proceso de booteo estará a cargo de systemd. ¿Algún problema? Ya que seguimos en un esquema mixto, puedes eliminar init=/bin/systemd de los parámetros del kernel para bootear nuevamente con sysvinit e initscripts, y así puedas corregir algún error.

    ¿Todo bien? ¡Sigue leyendo!

  5. ¿Recuerdas que mencioné que no olvidaras qué daemons teníamos en /etc/rc.conf? ¡Ahora es momento de migrarlos a systemd! Cada daemon debe tener su correspondiente unidad de servicio (las que explicaré a fondo en la siguiente sección), y cada una de ellas debemos habilitarlas (para que se ejecuten automáticamente al momento del booteo) por medio del comando:

    sudo systemctl enable <NOMBRE_DEL_SERVICIO>.service

    Algunos ejemplos (daemons con sus respectivas unidades de servicio):

    • network (Conexión ethernet por DHCP)

      sudo systemctl enable dhcpcd@eth0.service
    • networkmanager (Reemplazo de network)

      sudo systemctl enable NetworkManager.service
    • wicd (Reemplazo de network, más ligero que networkmanager)

      sudo systemctl enable wicd.service
    • crond (Programación de eventos)

      sudo systemctl enable cronie.service
    • cupsd (Common UNIX Printing System)

      sudo systemctl enable cupsd.service
    • ntpd (Cliente y servidor del Network Time Protocol)

      sudo systemctl enable ntpd.service
    • samba (Servicios de archivos e impresión para clientes de Microsoft Windows)

      sudo systemctl enable smbd.service
    • nginx (Servidor Web Nginx)

      sudo systemctl enable nginx.service
    • mysqld (Servidor de Base de Datos MySQL)

      sudo systemctl enable mysqld.service
    • postgresql (Servidor de Base de Datos PostgreSQL)

      sudo systemctl enable postgresql.service
    • gdm (Gnome Display Manager)

      sudo systemctl enable gdm.service
    • kdm (KDE Display Manager)

      sudo systemctl enable kdm.service
    • slim (Simple Login Manager, ¡mi preferido!)

      sudo systemctl enable slim.service

    Algunas observaciones muy importantes:

    • Algunos daemons no tenemos que habilitarlos explícitamente, como es el caso de dbus y netfs.

    • Algunos daemons desgraciadamente aún no tienen unidades de servicio (como dropboxd y httpd). Si no puedes prescindir de ellos, te recomiendo continúes con el esquema mixto (para que sigan siendo llamados desde la línea DAEMONS del archivo /etc/rc.conf), hasta que hayan sido implementados, lo cual no debe demorar mucho tiempo… ¡hay que ser pacientes!

    • El daemon syslog-ng (que normalmente es el primero en la línea DAEMONS del archivo /etc/rc.conf), causa conflictos con el nuevo syslog.socket, por lo que es necesario eliminarlo de la lista si planeamos seguir con el esquema mixto.

    Cuando estés seguro que ya no ejecutas ningún daemon especificado en el archivo /etc/rc.conf, entonces éste deja de tener utilidad. Te recomiendo hacerle un respaldo para recordar a nuestro viejo amigo, que tantos años nos acompañó.

  6. ¿Tienes personalizados los archivos /etc/rc.local y/o /etc/rc.local.shutdown? ¡Debes convertirlos a unidades de servicio! Pero ya que aún no sabemos cómo hacer eso, podemos darles soporte usando unas unidades de servicio especiales que llaman a ambos archivos.

    cp /usr/lib/systemd/system/rc-local{,-shutdown}.service /etc/systemd/system/
  7. Reinicia el sistema nuevamente. Si hay algún error, verifica de nuevo los pasos previos. ¿Todo bien? ¡Sigue leyendo!

  8. Cuando ya todo funcione perfectamente, ya podemos dar el paso definitivo del esquema mixto a un sistema systemd puro, y eso lo logramos instalando el paquete systemd-sysvcompat, el cual al mismo tiempo eliminará sysvinit e initscripts (éste último es probable que previamente tengas que eliminarlo manualmente con pacman -R), y le aplicará un pacsave a rc.conf, rc.local and rc.local.shutdown.

    sudo pacman -S systemd-sysvcompat
  9. Ya podemos eliminar init=/bin/systemd de nuestro parámetro del kernel (lo que hicimos en el paso 4), ya que ahora /sbin/init es un symlink a systemd.

¡Eso es todo! Si gustas puedes reiniciar nuevamente, para disfrutar al 100% de systemd en tu ArchLinux.

¡Ya tengo systemd! ¿Y ahora qué?

¡Ahora muchas cosas han cambiado! Acciones como ejecutar daemons, cambiar de runlevel, revisar el log del sistema o usar pm-utils para suspender o hibernar, ahora tienen un enfoque diferente, básicamente nos estamos enfrentando a un nuevo paradigma. En la presente sección les mencionaré los conceptos básicos para que empiecen a familiarizarse con systemd.

Previamente he mencionado el término “unidades de servicio“, pero no había explicado de qué se trataban exactamente. Una unidad o unit, no es más que un archivo de configuración que contiene información no sólo de servicios (.service, los más comunes, nuestros conocidos daemons), si no también de sockets (.socket), dispositivos (.device), puntos de montaje (.mount), puntos de auto-montaje (.automount), e incluso grupos de otras unidades (.target).

Como dato adicional, es interesante saber que la sintaxis de la información contenida en los archivos de las unidades está inspirada en los archivos .desktop de la especificación XDG Desktop Entry, que a su vez estuvo inspirada por… wait for it… ¡los archivos .ini de Microsoft Windows!, ironías de la vida.

Los archivos de unidades disponibles en nuestro sistema podemos encontrarlos en /usr/lib/systemd/system/ y /etc/systemd/system/ (éste último directorio toma precedencia en caso de duplicados).

Básicamente estaremos trabajando con el comando systemctl para interactuar con las diversas unidades de systemd. Algunos comandos de uso común son:

  • Listar las unidades que se estén ejecutando actualmente.

    systemctl

    o bien,

    systemctl list-units
  • Listar las unidades con errores.

    systemctl --failed
  • Listar las unidades instaladas.

    systemctl list-unit-files
  • Activar una unidad inmediatamente.

    systemctl start <unit>
  • Desactivar una unidad inmediatamente.

    systemctl stop <unit>
  • Reiniciar una unidad.

    systemctl restart <unit>
  • Recargar la configuración de una unidad.

    systemctl reload <unit>
  • Mostrar el estado de una unidad, esté o no en ejecución.

    systemctl status <unit>
  • Verificar si una unidad está habilitada.

    systemctl is-enabled <unit>
  • Habilitar una unidad para ejecutarse en cada booteo.

    systemctl enable <unit>
  • Deshabilitar una unidad para que no se ejecute en cada booteo.

    systemctl disable <unit>
  • Mostrar la ayuda asociada a una unidad (si se encuentra disponible).

    systemctl help <unit>

En el caso de la administración de energía del sistema, también debemos usar el comando systemctl. Si nos encontramos en una sesión de usuario de ConsoleKit, podemos ejecutar los siguientes comandos sin necesidad de privilegios de root (a no ser que haya otra sesión activa):

  • Cerrar y reiniciar el sistema.

    systemctl reboot
  • Cerrar y apagar el sistema.

    systemctl poweroff
  • Cerrar y detener el sistema.

    systemctl halt
  • Suspender el sistema.

    systemctl suspend
  • Hibernar el sistema.

    systemctl hibernate

Ahora bien, los clásicos runlevels son un concepto de sysvinit, quien examinaba el archivo /etc/inittab (ahora obsoleto) para saber el valor de :initdefault:. El paradigma correspondiente en systemd son las unidades .target, que básicamente tienen el mismo propósito, pero con algunas diferencias, por ejemplo, cada target tiene un nombre, en vez de la clásica numeración de los runlevels:

  • Runlevel 0 = poweroff.target

  • Runlevel 1 = rescue.target

  • Runlevels 2, 3 y 4 = multi-user.target

  • Runlevel 5 = graphical.target

  • Runlevel 6 = reboot.target

Ejemplos de uso:

  • Para cambiarnos a otro target en la sesión actual (no afecta al siguiente booteo).

    systemctl isolate graphical.target
  • Para establecer un nuevo target predeterminado (el usado en cada booteo).

    systemctl enable multi-user.target

Por último, quisiera mencionarles un poco acerca del nuevo log del sistema, conocido como journal. Para revisarlo, basta usar el comando:

journalctl

El journal escribe en los archivos contenidos en el directorio /run/systemd/journal/, y por lo mismo, se pierden al reiniciar el sistema. Si deseamos logs persistentes, sólo debemos crear el directorio /var/log/journal/:

mkdir /var/log/journal/

¡Aclaración! En todos los comandos de esta sección omití el uso de sudo para facilitar la lectura de los comandos; no olviden incluirlo al inicio de ellos cuando sea necesario.

Referencias

Es importante que tomes en cuenta que todo lo expuesto en el presente post es meramente un resumen (si, ¡por largo que se vea!), y sólo describe los pasos generales al instalar y usar systemd en ArchLinux. Siempre habrán excepciones o casos especiales, por lo que les recomiendo leer, investigar y documentarse a fondo sobre el tema. Aquí les dejo una lista de referencias, que son las que usé para elaborar este tutorial.