Archivo del Autor: ziggys

¿De qué hablamos cuando hablamos de contraseñas seguras? Un enfoque estadístico

En teoría de la información, un mensaje es equivalente a un texto codificado como una ordenación de símbolos (letras, espacios, signos de puntuación), lo que comúnmente llamamos una cadena de caracteres. Si deseáramos calcular qué tan segura es una contraseña, esto es, qué tan capaces somos de predecir el contenido del mensaje que la conforma, buscaríamos conocer qué tan aleatoria es la cadena de caracteres que la componen. Esta medida del desorden o incertidumbre es lo que conocemos como Entropía de la información (H).

Si consideramos una contraseña como un texto codificado y quisiéramos que la entropía de esta clave sea la máxima (tan aleatoria como sea posible) deberíamos asegurarnos que la entrada de caracteres sea poco probable de pronosticar, que cada caracter se repita o esté ordenado de una manera impredecible. Ahora bien, ¿cómo calculamos la Entropía de una contraseña? Habrá que entrar en el terreno duro de las matemáticas y la estadística.

Las matemáticas detrás de una contraseña

En estadística, llamamos Espacio Muestral (Ω) a todos los estados posibles de un experimento. Por ejemplo, al lanzar un dado, nuestro espacio muestral son los seis números correspondientes a cada una de las caras del dado, Ω={1,2,3,4,5,6}. En el caso de una contraseña, nuestro espacio muestral estará conformado por todas las permutaciones posibles en el universo de caracteres para cada combinación de los mismos. Esto es:

Ω (N,K) = {k1,k2,…,ki}

Dónde ki es cada uno de los estados (subconjunto de caracteres) posibles de los N caracteres del conjunto y K es la cantidad de caracteres del subconjunto o longitud de la contraseña.

Ahora bien, las claves las construimos a partir de un subconjunto de letras mínusculas y mayúsculas, números y símbolos escogidos de manera aleatoria. Por lo tanto, inicialmente el grado de indeterminación de un mensaje equivale a ki: existen ki estados posibles, cada uno de logitud K. Entonces, la probabilidad de aparición de cada una de las combinaciones que formen nuestra contraseña será:

P = 1 / ki

Y por lo tanto, la entropía del mensaje (H(x)) alcanzará el valor medio ponderado de la suma de probabilidades de los diversos estados del mismo expresado en binario (queremos medir “bits”). Es decir:

H(x) = — P(xi) log2[P(xi)]

; para todo i desde 1 hasta ki

Como habíamos mencionado, cada caracter de la cadena es escogido de manera aleatoria y por lo tanto, todos los estados (permutaciones) son equiprobables. Sintetizando: entre un total de N caracteres aleatorios formando una contraseña de longitud K, podemos expresar que:

H(x) = K log2[N]

Algunos ejemplos:

Supongamos que nuestra contraseña tiene 4 caracteres y es una combinación de números del 0-9. Entonces:

K = 4; N = 10

H(x1) = 4 log2[10] = 4 x 3,32192809489

H(x1) = 13,2877123796

Supongamos ahora que a la contraseña anterior le añadimos letras minúsculas y mayúsculas sin modificar su longitud. Ahora:

K = 4; N = 62 (26 min + 26 may + 10 núm)

H(x2) = 4 log2[62] = 4 x 5,95419631039

H(x2) = 23,8167852415

Para un último ejemplo, esta vez nuestra contraseña tendrá 8 caracteres:

K = 8; N = 62

H(x3) = 8 log2[62] = 8 x 5,95419631039

H(x3) = 47,6335704831

¿Qué representan estos resultados?

Hemos visto cómo aumentando tanto el tamaño de nuestro universo de caracteres como la longitud del subconjunto, la entropía aumenta. Pero, ¿qué representa este resultado en términos de seguridad de la información? Pues bien, como mencionaba, el valor está expresado en binario (bits) y por lo tanto 2^H(x) equivale a calcular el tamaño de nuestro espacio muestral, es decir: ¿de cuántas maneras se pueden permutar y combinar los caracteres para obtener una contraseña de una determinada longitud?

Entonces, para cada uno de los ejemplos anteriores:

2^H(x1) = 2^13,2877123796 = 10.000

2^H(x2) = 2^23,8167852415 = 14.776.335,9995

2^H(x3) = 2^47,6335704831 = 2,18340105586e+14

Es decir, para una contraseña de ±47 bits contamos con ±2e+14 (un 2 seguido de 14 ceros) permutaciones posibles. Esto significa que si tuviésemos un programa automatizado capaz de calcular 1.000.000 de permutaciones por segundo, para dar con nuestra clave (desde el punto de vista probabilístico), necesitaría aproximadamente 7 años de continuo procesamiento.

Finalmente, es fácil demostrar que 2^H(x) = N^K y por lo tanto:

2^H(x1) = 10^4 = 10.000

2^H(x2) = 62^4 = 14.776.335,9995

2^H(x3) = 62^8 = 2,18340105586e+14

Sintetizando, esta fórmula se puede expresar como:

complejidad^longitud

ó en bits:

H(x) = log2[complejidad^longitud]

Consideraciones finales

Para terminar, quisiera añadir tres puntos de chequeo que considero importantes al momento de construir una contraseña segura.

La aletoriedad es imporante

Como vimos, la entropía se maximiza en base a la probabilidad de un evento. Si los diversos estados de un mensaje no son equiprobables, la entropía disminuye. Por ejemplo, si en lugar de usar combinaciones aleatorias usamos palabras comunes (casa, cerveza, operando) la probabilidad de que los caracteres más usados del alfabeto (a, e, c, m) caigan en la contraseña es mayor que la de los menos usados (k, w, x) y por lo tanto este cambio en el valor de la suma ponderada de las probabilidades hará que nuestra clave sea menos segura, independientemente de la complejidad y longitud.

Usar contraseñas distintas para cada cuenta

Esto puede ser agotador y hasta aburrido. Además, requiere que llevemos algún tipo de sistema de administración de claves, pues todos tenemos nuestras limitaciones al momento de memorizar cadenas de caracteres aleatorios. Esto, puede jugar en contra si no somos cuidadosos con nuestro sistema (por ejemplo, tener todas las claves en un cuaderno que llevamos con nosotros a todas partes).

Sin embargo, es altamente aconsejable que cada cuenta tenga su contraseña y que cada contraseña tenga una complejidad y longitud diferentes. Por ejemplo, si usamos una clave para todo y un atacante da con esa clave, tendrá acceso a todas nuestras cuentas. Por otro lado, si las claves son distintas, pero todas tienen la misma longitud, cuando un atacante sepa una de las claves, tendrá información suficiente para buscar las demás.

Cambiar las contraseñas cuando sospechamos que pudo ser vulnerada

Muchos consideran innecesario estar cambiando una clave cada cierto tiempo: si la contraseña es lo suficientemente segura, no es necesario modificarla; si la entropía de la vieja clave es igual a la de la nueva, cambiarla no modificará la probabilidad de que un atacante la descifre. Entonces, ¿por qué tantos recomiendan cambiar las contraseñas periódicamente?

Desde mi punto de vista, debemos estar atentos a las operaciones que realizamos en nuestra informática diaria. Si por algún despiste (que ocurren seguido) hemos dejado vulnerable nuestra clave, lo natural sería cambiarla. Lo mismo si nuestros equipos se traspasan a otros usuarios: regalamos nuestro teléfono móvil, vendemos una laptop para comprar una nueva, etcétera.


Fuentes:
Entropía (información) – Wikipedia, la enciclopedia libre


Conectarse a un servidor ssh inaccesible atravesando otro servidor ssh intermedio

Estoy en casa cuando repentinamente recuerdo que dejé una tarea pendiente en la oficina para la cuál necesito acceder a mi equipo. Es viernes por la tarde y la inminente llegada del fin de semana representa un problema: en la oficina ya todos se fueron y nadie en su sano juicio regresaría para terminar el trabajo. Por suerte, estoy consciente de que la computadora está encendida y el servidor ssh está corriendo. Pero claro, cómo acceder remotamente cuando la máquina no es accesible desde Internet. La buena noticia es que hay un servidor en la red al que sí puedo conectarme por ssh desde casa y desde allí ingresar al equipo.

Este tipo de escenarios, que a mi me gusta llamar SSH Multi-Huésped, es algo común entre los administradores de sistemas y existen muchos métodos para resolver la conexión: desde un rudimentario, inseguro e ineficiente direccionamiento de puertos hasta una conexión ssh en escalas, algo así:

usuario@casa$ ssh usuarioservidor@servidor
Password for usuarioservidor@servidor:
Last login: Fri Dec  2 17:01:43 2016 from 'ip_casa'

usuarioservidor@servidor$ ssh usuariooficina@oficina
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:02:15 2016 from 'ip_servidor'

usuariooficina@oficina $

Está claro que no es la manera que una administrador de sistemas usaría. La alternativa es habilitar el direccionamiento del agente a través de los equipos y pasarle la opción -t para forzar la asignación de una pseudo-tty para contar con una shell interactiva.
 

usuario@casa $ ssh -A -t usuarioservidor@servidor ssh -A usuariooficina@oficina
Password for usuarioservidor@servidor:
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:05:39 2016 from 'ip_casa'

usuariooficina@oficina $

Bonito ¿no? No, es horrible. Basta imaginar que el camino entre el equipo de mi casa y el de la oficina tuviera tres o cuatro máquinas intermedias. Ni hablar si lo que buscamos es copiar un archivo desde un extremo al otro con scp. Sin duda, estos métodos carecen de toda elegancia. Lo que yo necesito es realizar esta operación de una manera simple, transparente y eficiente.

Para esto contamos con dos herramientas: por una lado, tenemos netcat (Netcat – Wikipedia, la enciclopedia libre), que debe estar instalado en las máquinas intermedias; por otro, la opción ProxyCommand habilitada en nuestro cliente ssh. Para configuralo, hay que añadir algunas líneas al final del archivo de configuración /etc/ssh/ssh_config en el equipo desde el cual iniciamos la conexión.
 

usuario@casa $ sudo nano /etc/ssh/ssh_config

/etc/ssh/ssh_config

[…]
Host oficina
User usuariooficina
HostName oficina
Port 22
ProxyCommand ssh -q usuarioservidor@servidor nc %h %p

Para explicar un poco el contenido agregado al archivo:
Host es un nombre arbitrario que nos servirá para identificar fácilmente el huésped al que buscamos conectarnos
User, Hostname y Port representan las variables que netcat usará para conectar los húespedes
ProxyCommand: aquí se ejecuta el comando requerido para iniciar la conexión. La opción -q (quiet mode) suprime los mensajes de advertencia y diagnóstico; nc ejecuta netcat propiamente dicho y los valores %h y %p se obtienen de User-HostName y Port respectivamente

 

usuario@casa $ ssh oficina
Password for usuarioservidor@servidor:
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:10:05 2016 from 'ip_casa'

usuariooficina@oficina $

El procedimiento es simple y transparente. Como es natural, la cadena de equipos intermedios puede poseer más de un huésped y por supuesto, es posible configurar un sin número de conexiones diferentes. Además, con este método es posible la copia de manera sencilla de archivos desde y hacia el equipo remoto con scp, el uso del protocolo sftp, la conexión a través del gestor de archivos y como si esto fuera poco, podemos dirigir aplicaciones gráficas a través de X-forwarding. Aquí algunos ejemplos:

usuario@casa $ scp oficina:/ruta/archivo_remoto /ruta/archivo_local
Copia del archivo_remoto desde el equipo en la oficina hacia la máquina en casa.

 

usuario@casa $ ssh -X oficina pcmanfm
Ejecutando el gestor de archivos pcmanfm del equipo en la oficina en la máquina en casa a través de X-forwarding.

 

De esta manera me ocupo de terminar el trabajo pendiente y me dispongo a disfrutar de una tarde de viernes como es debido.
 

Tor+Privoxy en GNU/Linux con OpenRC

Quienes usamos OpenRC sabemos que al momento de instalar un paquete debemos tener en cuenta que por lo general existe una versión específica para este init. Además, en muchos casos no alcanza simplemente con instalar el paquete correspondiente, sino que también los archivos de configuración suelen requerir diferentes parámetros.

Este es el caso del sistema de enrutamiento por capas TOR, el que habitualmente instalo junto a Privoxy para integrarlo como una cadena de proxys.

Dado que actualmente uso Manjaro OpenRC, los comandos están enfocados en esta distribución.
$ sudo pacman -S tor-openrc privoxy-openrc proxychains torsocks lynx
Instalo los paquetes necesarios en su versión para OpenRC y además añado proxychains y torsocks para integrar los proxys al uso en consola de comandos.

Posteriormente, se edita el archivo de configuración de Privoxy, indicándole la dirección ip de escucha y añadiendo al final del archivo la línea de encadenamiento al proxy socks.

$ sudo nano /etc/privoxy/conf

/etc/privoxy/conf

[…]
listen-address 127.0.0.1:8118
[…]
forward-socks5 / 127.0.0.1:9050 .

Luego, hay que trabajar sobre la configuración de TOR. Para esto, se hace una copia de seguridad del archivo original y se crea un nuevo archivo que contenga las líneas requeridas para que OpenRC gestione el daemon.

$ sudo mv /etc/tor/torrc.bck

$ sudo nano /etc/tor/torrc

/etc/tor/torrc

User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
DataDirectory /var/lib/tor/data

Sólo resta añadir los servicios al inicio y arrancarlos.

$ sudo rc-update add tor default

$ sudo rc-update add privoxy default

$ sudo sudo service tor start

$ sudo service privoxy start

Por último, comprobamos que todo funciona correctamente.

$ proxychains lynx check.torproject.org 
Congratulations. This browser is configured to use Tor.
This page is also available in the following languages: [English____________________] Go

Congratulations. This browser is configured to use Tor.

Your IP address appears to be: xxx.xxx.xxx.xxx

Instalando i3wm en FreeBSD

Para muchos el entorno de escritorio es una pieza fundamental y quizá imprescindible en su maquinaria. Para otros, todo lo contrario, amantes del minimalismo, buscan vivir lo más posible dentro de la consola. En la amplia gama intermedia de estos dos extremos estamos quienes al mismo tiempo que nos sentimos plenamente cómodos trabajando en la consola, no sólo para tareas administrativas, sino que también acostumbramos tener algún reproductor de música, gestor de archivos, lector de correo y hasta navegadores web en una interfaz de línea de comandos (CLI), también tenemos una amplísima batería de aplicaciones gráficas (GUI), ya sea por gusto, comodidad, facilidad de interacción, versatilidad.

Habiendo terminado la instalación de FreeBSD en mi equipo, empecé a preguntarme qué entorno le daría vida en formas y colores a mi reciente sistema aún en temprana fase TTY. Y así me voy dando cuenta de que puedo andar sin un entorno de escritorio del tipo “robusto y completo”. Un entorno gráfico minimalista parece ser la mejor opción esta vez.

Para disfrutar de una interfaz gráfica en FreeBSD es necesario instalar el servidor Xorg y decirle al sistema, mediante el archivo /etc/rc.conf que inicie los servicios dbus y hal al arranque.

$ pkg install xorg hal dbus

$ Xorg -configure

$ echo "hald_enable="YES"" >> /etc/rc.conf

$ echo "dbus_enable="YES"" >> /etc/rc.conf

$ reboot

Al iniciar nuevamente, podré arrancar las Xs simplemente con:

$ startx

Todo funciona a la perfección. Pero las Xs así de fábrica son feas, poco intuitivas y con una practicidad casi nula. Insatisfecho pues con esto, me viene a la mente aquel gestor de ventanas en mosaico, ligero, ampliamente configurable y tan amado por los usuarios con corazón de hacker y entrañas de geek. Por si fuera poco, funciona de manera autónoma, lo que me resulta muy conveniente. Hablo ni más ni menos que de i3wm.

$ pkg install i3 i3lock i3status dmenu

$ echo "/usr/local/bin/i3" >> /usr/home/usuario/.xinitrc

$ chown usuario /usr/home/usuario/.xinitrc

$ reboot

Una última cuestión a considerar es que parece haber un problema al momento de crear el archivo de configuración. Por esto, lo recomendable es copiar el archivo que viene por defecto (/usr/local/etc/i3/config) y luego editarlo a nuestro gusto.

$ cp /usr/local/etc/i3/config ~/.i3/

Ahora, al iniciar sesión en modo TTY, sólo debo escribir startx para iniciar una sesión gráfica con i3wm.

Crónicas de un arranque dual o de cómo FreeBSD convive pacíficamente junto a Manjaro en mi disco duro

Todos los que hemos recorrido los caminos del software libre hemos desarrollado un fuerte interés por FreeBSD en más de una ocasión. En mi experiencia, he tenido oportunidad de echarle mano en el ámbito laboral, pero para uso personal siempre me sentí más cómodo con las distribuciones GNU/Linux.

Sin embargo, me doy cuenta que esta tendencia está cambiando. Por un lado, systemd ya no es una opción para mí y ciertamente veo más complicado cada día andar por el mundillo “linuxero” evitando el contacto con el daemonio del sistema, a pesar de las múltiples y excelentes opciones que hay en la vía (tema que da lugar quizá a otra entrada).

Por otra parte, la mayoría de nosotros cuenta con abundante espacio en disco duro y a menudo andamos buscando alternativas para llenar esas particiones con sistemas que llamen nuestra curiosidad por conocer y analizar, prácticamente de laboratorio por decirlo de alguna manera. Por mi parte, no me considero un distrohopper y tampoco soy de virtualizar mis instalaciones, pero soy de los que gusta tener una o varias particiones del disco listas para recibir un nuevo huésped con quien divertirme o aprender un rato.

Actualmente mi máquina de escritorio juega con Manjaro OpenRC y KDE Plasma como entorno de escritorio (versión 5.8.1 al momento de escribir la entrada) y mi intención es que siga siendo el sistema operativo principal por un tiempo más. El planteo entonces es poder instalar FreeBSD en una de las particiones disponibles y correr un arranque dual utilizando el actual Grub de Manjaro para escoger entre sistemas operativos.

Lo que sigue no es un tutorial de cómo instalar FreeBSD, el proceso en sí es bastante intuitivo y comprensible, además está amplia y perfectamente descrito en la Documentación oficial del Proyecto. Lo que sigue es más bien la crónica de mi experiencia instalando FreeBSD junto a mi actual distribución GNU/Linux.

Preparando la instalación

Es algo obvio, pero por si alguien se pregunta, lo primero fue preparar un dispositivo de arranque con la imagen de FreeBSD que descargué desde aquí y que luego pasé a un pendrive así:

$ sudo dd if=/ruta_de_descarga/FreeBSD-11.0-RELEASE-xxx-memstick.img of=/dev/sdc
1433746+0 registros leídos
1433746+0 registros escritos
734077952 bytes (734 MB, 700 MiB) copied, 268,342 s, 2,7 MB/s

Algo verdaderamente notorio es la multiplicidad de opciones que ofrece FreeBSD en cuanto a arquitecturas, imágenes listas para importar a máquinas virtuales y tarjetas SD para dispositivos embebidos.

Ahora bien, antes de iniciar desde el pendrive, hay que echar un ojo a las particiones en el disco (/dev/sda) para tenerlas bien identificadas.

$ lsblk /dev/sda -o NAME,SIZE,MOUNTPOINT
NAME       SIZE       MOUNTPOINT
sda        465,8G
├─sda4     1,9G       [SWAP]
├─sda2     19,1G
├─sda3     425,8G     /home
└─sda1     19,1G      /

Como puede verse, tengo un disco con una disposición bastante estándar, es decir, una tabla MBR con 4 particiones primarias: el directorio raíz (/) un directorio de usuario por separado (/home) una partición de intercambio (swap) y una partición libre (/dev/sda2). No cabe duda que FreeBSD irá a parar a /dev/sda2 y obviamente no quiero tocar los preciados datos en /home ni mucho menos dañar la actual instalación de Manjaro (/), así que voy tomando nota.

Para facilitar todavía más las cosas, lo que personalmente prefiero es eliminar la partición /dev/sda2 para que quede como espacio sin asignar o sin utilizar. De esta manera, la tarea de configurar esa partición la haré desde el instalador de FreeBSD.

Ahora sí está todo listo para iniciar desde el dispositivo USB. Una vez que arranca dará a escoger entre iniciar el instalador , ejecutar una consola de comandos o una sesión en vivo del sistema . Más por capricho que por experiencia, me inclino a ejecutar la shell  para preparar la partición manualmente y posteriormente ejecutar el instalador.

When finished type 'exit' to return the installer.

#

Creando y configurando las particiones

Para gestionar las particiones en FreeBSD contamos con una gran herramienta: gpart. Algo a tener en cuenta al momento de trabajar con el disco es la notación que usa FreeBSD para nombrar los dispositivos: donde en GNU/Linux teníamos /dev/sda, aquí se llama ada0; la partición /dev/sda1 ahora es ada0s1 y así con el resto.

# gpart show -p ada0
ada0        MBR            (468.8G)
ada0s1      linux-data     (19.1G)
- free -                   (20G)
ada0s3      linux-data     (428.8G)
ada0s4      linux-swap     (1.9G)

El primer paso a partir de aquí es crear la partición ada0s2 utilizando el espacio libre que dejó la ya eliminada /dev/sda2.

# gpart add -t freebsd -i 2 ada0
ada0s2 added
Antes de continuar, una pequeña reseña del comando:
gpart add: agrega una nueva partición a la tabla ya existente
-t freebsd: el tipo de partición (freebsd en este caso)
-i 2 ada0: indicarle a gpart que la partición se creará con el índice número 2 en el dispositivo ada0. Si no especificamos un tamaño, lo asignará automáticamente

Al mirar nuevamente la tabla, la cosa va tomando forma.

# gpart show -p ada0
ada0        MBR            (468.8G)
ada0s1      linux-data     (19.1G)
ada0s1      freebsd        (20G)
ada0s3      linux-data     (428.8G)
ada0s4      linux-swap     (1.9G)

A continuación, debe crearse el sistema de archivos en la partición (freebsd-ufs) con el siguiente comando:

# newfs ada0s2
/dev/ada0s2: 20000.0MB (40960000 sectors) block size 32768, fragment size 4096
using 32 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
...
Un detalle a tener en cuenta es que BSD discrimina entre particiones primarias y lógicas llamando a estas segundas slices. Por ejemplo, la partición primaria /dev/ada0s2 (del tipo BSD) tendrá el slice /dev/ada0s2a (freebsd-ufs o simplemente ufs).

Teniendo ya lista la partición, regreso al instalador escribiendo # exit y realizo los primeros pasos de configuración del sistema: distribución del teclado, hostname, componentes opcionales) hasta llegar al editor de particiones.

A partir de este punto me encuentro ante dos alternativas: seleccionar Manual y configurar los puntos de montaje desde allí o continuar ensuciándome las manos desde la Shell. Como me gusta complicarme la vida a fuerza de comandos, lo que hago es irme de nuevo a la consola.

Primero voy a generar el archivo /tmp/bsdinstall_etc/fstab.

# echo "/dev/ada0s2a / ufs rw 1 1" > /tmp/bsdinstall_etc/fstab

Luego, montar el nuevo sistema de archivos y salir.

# mount -t ufs /dev/ada0s2a /mnt

# exit

El instalador comenzará la copia de archivos, pedirá configurar la red, el usuario root, la zona horaria, el reloj y demás. Bastará aquí con seguir los pasos. Al terminar, salgo y reinicio.

Agregando FreeBSD al Grub de GNU/Linux

Como es natural, al reiniciar el Grub no mostrará FreeBSD entre las opciones de arranque. Normalmente, en Manjaro bastaría con ejecutar $ sudo update-grub, pero en este caso lo que debe hacerse es crear la entrada de forma manual y regenerar el Grub.

$ sudo nano /etc/grub.d/40_custom

/etc/grub.d/40_custom

!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "FreeBSD" {
set root=(hd0,2)
chainloader +1
}
Añadimos la entrada manual indicando que el directorio raíz se encuentra en /dev/sda2 (hd0,2).
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Generando un fichero de configuración de grub...
...
Encontrado unknown Linux distribution en /dev/sda2
...
hecho

¡Y listo! Reinicio y veo a FreeBSD flamante entre las opciones del Grub, lista para convivir pacíficamente junto a Manjaro en mi disco. Restará instalar y configurar un entorno gráfico y las aplicaciones que uso a diario, pero esa es toda una historia aparte.

Migrando a OpenRC desde Manjaro

En el artículo anterior escribí acerca de cómo abandoné systemd a favor de openrc. En aquel momento les comentaba que una de las distribuciones elegidas fue Manjaro OpenRC. En mi caso, y debido a que no estaba dispuesto a continuar con Archlinux, decidí recomenzar haciendo una instalación mínima (o netinstall) para luego ir instalando y configurando individualmente los demás componentes del sistema. Pero este no tiene por qué ser el caso de todos. De hecho, si actualmente sos un usuario de Manjaro y estás pensando en quitar systemd probablemente no esté en tus planes comenzar desde cero reinstalando el sistema. En tu caso, lo que buscás es lo que habitualmente se denomina migración.

Normalmente este tipo de acciones sobre el sistema son un dolor de cabeza, en especial cuando se trata de quitar systemd y arriesgarse a romper el sistema (pensemos en las dependencias y librerías). Sin embargo, cuando se trata de Manjaro ocurre todo lo contrario. En primer lugar porque todos los paquetes y sus dependencias se encuentran en los repositorios oficiales (en Archlinux necesitamos de AUR o del repositorio eudev-openrc). En segundo lugar, esta distribución GNU/Linux, que cada día va ganando más interés entre los usuarios, está bien cuidada por sus desarrolladores y la comunidad que los acompaña, dicho de otra manera, esta hecha para simplificarle las cosas al usuario y al mismo tiempo funcionar bien. Además el proceso está bien documentado.

Pues bien, dicho esto vamos a proceder con la migración. Para hacerlo nos apoyaremos en el artículo que la gente de Manjaro nos facilita en su Wiki y voy a seguir lo más cerca posible sus lineamientos y su formato.

 

Instalando OpenRC

$ sudo pacman -S openrc-base
Con este comando se instalarán los paquetes necesarios. Por supuesto, pacman nos consultará sobre los paquetes que presenten conflictos (systemd-sysvcompat), a lo que debemos responder “sí” para que proceda a la instalación.

La salida de este comando será algo como esto:

:: Hay 12 miembros en el grupo openrc-base:
:: Repositorio community
1) cronie-openrc  2) cronjobs  3) cryptsetup-openrc  4) dbus-openrc
5) device-mapper-openrc  6) dhcpcd-openrc  7) glibc-openrc
8) inetutils-openrc  9) lvm2-openrc  10) mdadm-openrc  11) netifrc
12) udev-openrc

Introduzca una selección (por omisión=todos):
resolviendo dependencias…
buscando conflictos entre paquetes…
:: cronie-openrc y systemd-sysvcompat están en conflicto. ¿Quitar systemd-sysvcompat? [s/N] s

Paquetes (15) openrc-0.21-1  systemd-sysvcompat-229-3 [quitando]
sysvinit-2.88-16  cronie-openrc-20160528-1  cronjobs-20160402-1
cryptsetup-openrc-20160528-1  dbus-openrc-20160528-1
device-mapper-openrc-20160528-1  dhcpcd-openrc-20160528-1
glibc-openrc-20160528-1  inetutils-openrc-20160528-1
lvm2-openrc-20160528-1  mdadm-openrc-20160528-1  netifrc-0.3.1-7
udev-openrc-31-1

Tamaño total de la descarga:    0,39 MiB
Tamaño total de la instalación:  2,49 MiB
Tamaño neto tras actualizar:    2,48 MiB

:: ¿Continuar con la instalación? [S/n]

Acto seguido, agregaremos algunos servicios básicos al arranque.

$ sudo rc-update add dbus default
...

$ sudo rc-update add cronie default

Posteriormente instalaremos un display-manager, para que al reiniciar el equipo arranque en la interfaz gráfica en lugar de una simple línea de comandos.

$ sudo pacman -S displaymanager-openrc

Para configurarlo vamos a modificar la línea "DISPLAYMANAGER=xdm" en /etc/conf.d/xdm por la que corresponda a nuestro DM favorito (sddm, lightdm, etcétera):

$ sudo nano /etc/conf.d/xdm

/etc/conf.d/xdm

# We always try and start X on a static VT. The various DMs normally default
# to using VT7. If you wish to use the xdm init script, then you should ensure
# that the VT checked is the same VT your DM wants to use. We do this check to
# ensure that you haven't accidentally configured something to run on the VT
# in your /etc/inittab file so that you don't get a dead keyboard.
CHECKVT=7
# What display manager do you use ?  [ xdm | gdm | kdm | gpe | entrance ]
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
DISPLAYMANAGER="<displaymanager>"
Recuerden cambiar <displaymanager> por el de su elección.

Añadimos el servicio para que arranque por defecto.

$ sudo rc-update add xdm default

En este punto aún no es recomendable reiniciar, ya que aún falta un buen grupo de paquetes que harán operar el sistema adecuadamente.

 

Utilidades básicas del sistema

A continuación vamos a instalar varias utilidades: audio (alsa), red (networkmanager), eventos acpi (acpid), multiusuario (consolekit), suspensión/hibernación (pm-utils) y servicios de registro (syslog-ng), entre otros.

$ sudo pacman -S networkmanager-openrc syslog-ng-openrc pm-utils acpid-openrc alsa-utils-openrc avahi-openrc consolekit-openrc gpm-openrc polkit-consolekit cgmanager-opernc
resolviendo dependencias…
buscando conflictos entre paquetes…
:: networkmanager-openrc y systemd-sysvcompat están en conflicto. ¿Quitar systemd-sysvcompat? [s/N] s
:: networkmanager-consolekit y networkmanager están en conflicto. ¿Quitar networkmanager? [s/N] s
:: polkit-consolekit y polkit están en conflicto. ¿Quitar polkit? [s/N] s
:: pm-utils y tlp están en conflicto. ¿Quitar tlp? [s/N] s

Paquetes (25) cgmanager-0.39-2 consolekit-1.1.0-7 eventlog-0.2.12-4
libdbi-0.9.0-2 libnih-1.0.3-2 networkmanager-1.2.2-1 [quitando]
networkmanager-consolekit-1.2.2-2 openrc-0.21-1
pm-quirks-0.20100619-4 polkit-0.113-4 [quitando]
syslog-ng-3.6.3-2 systemd-sysvcompat-229-3 [quitando]
sysvinit-2.88-16 tlp-0.8-1 [quitando] udev-openrc-31-1
acpid-openrc-20160528-1 alsa-utils-openrc-20160528-1
avahi-openrc-20160528-1 cgmanager-openrc-20160528-1
consolekit-openrc-20160528-1 gpm-openrc-20160528-1
networkmanager-openrc-20160528-1 pm-utils-1.4.1-6
polkit-consolekit-0.113-5 syslog-ng-openrc-20160528-1

Tamaño total de la descarga: 5,20 MiB
Tamaño total de la instalación: 33,60 MiB
Tamaño neto tras actualizar: 9,25 MiB

:: ¿Continuar con la instalación? [S/n]

Una vez que finalice, procedemos a habilitar los servicios con:

$ sudo rc-update add <servicio> default
Reemplazando <servicio> según sea el caso.

 

Problemas con Plymouth

La Wiki nos advierte de los problemas que puede causar Plymouth con OpenRC. Para evitarnos complicaciones editaremos el archivo /etc/mkinitcpio.conf

$ sudo nano /etc/mkinitcpio.conf

Primero debemos quitar plymouth de la línea HOOKS=... para que quede así

/etc/mkinitcpio.conf

...
HOOKS="base udev autodetect modconf block resume filesystems keyboard keymap fsck"
...

Y regeneramos initrd

$ sudo mkinitcpio -p linux<versión>
Dónde <versión> es el número de versión del kernel que estás corriendo (el comando uname -r te dirá cuál es si no lo sabés).

 

Quitando definitivamente a systemd del sistema

Con OpenRC instalado y funcionando, la existencia de systemd en el sistema queda completamente injustificada. Para deshacernos definitivamente de él, vamos a instalar los siguientes paquetes.

$ sudo eudev eudev-systemdcompat
eudev es un reemplazo para udev provisto por la gente de Gentoo y que nos asegura una mejor compatibilidad con OpenRC
resolviendo dependencias…
buscando conflictos entre paquetes…
:: eudev y libsystemd están en conflicto (libudev.so). ¿Quitar libsystemd? [s/N] s
:: eudev-systemdcompat y systemd están en conflicto. ¿Quitar systemd? [s/N] s
advertencia: bucle de dependencias detectado:
advertencia: eudev-systemdcompat será instalado antes que su dependencia eudev

Paquetes (4) libsystemd-229-3 [quitando] systemd-229-3 [quitando] eudev-3.2-1
eudev-systemdcompat-230-1

Tamaño total de la descarga: 1,16 MiB
Tamaño total de la instalación: 7,47 MiB
Tamaño neto tras actualizar: -21,62 MiB

:: ¿Continuar con la instalación? [S/n]

Bastará un reinicio para finalizar la tarea.

 

Algunas consideraciones extra

Para que tengan en cuenta, los usuarios de Plasma 5 pueden encontrarse con que Pulseaudio no inicie en el arranque. Para resolverlo, basta con dirigirse a

Preferencias del Sistema -> Arranque y Apagado -> Autoarranque

Crear un script similar al siguiente:

$ sudo nano /usr/local/bin/pulse.sh
#!/bin/sh
pulseaudio --start

Y agregarlo al inicio del sistema junto con sus scripts personalizados.

Por mi parte, prefiero prescindir de Pulse (los desarrolladores son los mismos de systemd) y tomarme el trabajo de configurar ALSA o JACK a secas, lo que es tema para otra entrada.

 

Otro asunto es montar automáticamente particiones en discos adicionales a través de /etc/fstab. El punto de montaje habitual en Archlinux y derivadas es /run/media/nombre_de_particion, pero con OpenRC lo conveniente es cambiar el punto de montaje a /media/nombre_de_particion (al mejor estilo Debian y derivadas). Por ejemplo, digamos que tenemos un disco duro adicional en nuestro equipo donde alojamos datos, música, documentos, películas y demás y queremos que sea montado automáticamente al inicio. Entonces ejecutaremos:

$ sudo blkid /dev/sdX
/dev/sdX: LABEL="datos" UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="ext4"

Buscamos el UUID de la partición /dev/sdX correspondiente al disco duro en cuestión. Ahora, editamos /etc/fstab añadiendo al final el punto de montaje.

$ sudo nano /etc/fstab

/etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump>  <pass>

UUID=xxxxxxxx-...  /media/datos ext4    defaults,noatime 0       0
Al reiniciar, nuestra partición de datos estará montada automáticamente como /media/datos.

 

Por último, no quiero dejar de recomendarles visitar la Wiki OpenRC de Gentoo y por supuesto la Wiki OpenRC de Manjaro (de donde salió este artículo) para que conozcan a fondo su funcionamiento, opciones, configuraciones y el modo de operarlo, así como los posibles problemas que puedan hallar.

Adiós cruel daemonio de sistema o de cómo vencí mi hartazgo hacia systemd

Systemd es un monstruo de caminar lento, torpe y caprichoso que con el tiempo se ha ido comiendo cada ser viviente del entorno en su afán por controlarlo todo. El asunto es que por mucho tiempo intenté mantener una convivencia pacífica con el gigante bicho que dominaba mi distribución GNU/Linux favorita. Hasta que un buen día me harté.

Para un usuario desatendido, digamos, aquel que sólo utiliza el equipo para navegar, escuchar música o editar documentos, el funcionamiento de systemd pasa desapercibido la mayor parte del tiempo. Ahora, si ese usuario quisiera disfrutar de los beneficios de poner su equipo en hibernación la cuestión se pone más difícil en la mayoría de los casos. Y ya cuando empezamos a tratar con servicios más o menos avanzados y necesitamos que estos servicios se ejecuten de una manera especifica con una configuración particular y además requerimos mayor control sobre los mismos, la cosa cambia. Y en este sentido, systemd viene a complicarlo todo.

Pero en fin, esta entrada está lejos de ser una lista exhaustiva de las maldades del monstruo ya por todos conocidas. Tampoco quiero entrar (por ahora) en el tema de la filosofía Unix y toda la discusión al respecto. Simplemente quiero contarles cómo, luego de alcanzar altos niveles de molestia con systemd y su mal comportamiento, atravesé victorioso el proceso de abandonar al daemonio de sistema.

¿Cómo quitarse systemd sin morir en el intento?

La primera cosa que me vino a la mente cuando me planteé esta pregunta fue: ¿por qué no migrar directamente desde Archlinux? Esta idea fue descartada por varias razones. En primer lugar, toda una distro pensada para funcionar con systemd implica la minuciosa tarea de ponerse a trabajar varios días hasta que todo quede funcionando correctamente, eso si andamos con suerte, y la pereza me gana en ese sentido. Por otra parte, el simple hecho de que OpenRC no esté soportado de manera oficial (requiere AUR o el repositorio openrc-eudev) indica claramente que la gente de Arch no está interesada en que se use nada más que systemd en su distro.

De manera que con Arch fuera del tablero, los nombres empezaron a salir a la superficie: FreeBSD, Devuan y Gentoo. FreeBSD resultaría lo más sencillo dado que la conozco bastante habiéndola usado en el ámbito de servidores. Devuan era una opción fuerte, pero la idea de abandonar el rolling-release me pesaba (lo mismo ocurre con FreeBSD). Gentoo sonaba fuerte, pero ya estoy viejo para andar compilando.Sin embargo, pensé en darle la oportunidad.

Así fue que, mientras probaba Gentoo, busqué opciones y di con una versión de Manjaro con OpenRC, lo que me resultó especialmente interesante: inspirada en Arch (aunque con repositorios propios), con pacman como gestor de paquetes y rolling-release. Además, en este caso OpenRC está soportado oficialmente por la distro. Dado que me estaba sobrando una partición, me decidí a instalarla en su formato mínimo para ir analizando cómo se comportan los servicios en esta distro para luego, instalar un entorno de escritorio.

Actualmente mi equipo está completamente libre de systemd con dos distribuciones en paralelo: Gentoo+Gnome y Manjaro-OpenRC+Plasma5. Ambas serán expuestas a muchas pruebas antes de definirme por una (o por quitarlas y buscar otra). A su vez, ambas han mostrado un desempeño excelente, así que es probable que se queden un buen rato por aquí.

Para finalizar  quisiera comentarles los beneficios que he obtenido en el corto plazo. Por un lado, ha mejorado notablemente el tiempo de arranque del sistema (obvio, pero tengo que decirlo), los procesos se mantienen más estables y los servicios configurados de acuerdo a mis necesidades funcionan sin ningún problema. Por el otro lado, he recuperado la sensación de control sobre el sistema y sus procesos de fondo (daemons).

P.D.: quienes estén pensando mudarse a un mundo sin systemd, les recomiendo darse una vuelta por aquí: http://without-systemd.org/wiki/index.php/Main_Page