Nov 25 2012

Recuperar la hibernación en Ubuntu Linux

Gabolonte Blasfemus

La función de hibernación en los portátiles es una de esas cosas que cuando andan bien son una maravilla, pero cuando las llegamos a dar por sentadas nos encontramos con que tal versión del SO, que casualmente es la que usamos, o determinado cambio que hicimos, la rompió. Puede ser que al accionarla no funcione en absoluto, y lo notaremos cuando al encender nuevamente la máquina el sistema arranque desde cero sin retener en absoluto nuestra pasada sesión abierta; también puede ser que no aparezca la opción de hibernar en lo absoluto.

Pero para empezar, nunca está de más para quien aún se confunda marcar la diferencia entre las funciones de hibernar y suspender en una computadora.

Cuando un equipo entra en suspensión, este continúa encendido, solo que en su mínima expresión: Tanto el disco como la mayoría de los circuitos se encuentran apagados, o dicho de otra forma, en un estado de standby de mínimo consumo. Bajo esta modalidad toda la info de nuestra sesión abierta se retiene en la memoria RAM de la misma forma que si la máquina estuviese en funcionamiento normal. Este es el comportamiento por defecto de toda portátil cuando se le cierra la tapa (y más si no está conectada a su cargador) y es tremendamente útil por la velocidad con la que podemos despertarla de su letargo: Basta volver a abrirla y tocar cualquier tecla para que vuelva y todo estará ahí. Pero su gran desventaja es que, aunque mínimo, sigue existiendo un consumo de batería que a la larga la drenará completamente.

Continue reading


Oct 29 2012

Cómo ejecutar un proceso al inicio o como servicio en Ubuntu/Linux

Gabolonte Blasfemus

Hace algún tiempo en el post Reconexión automática a VPN en Ubuntu Linux un lector llamado Alejo me consultaba sobre la posibilidad de hacer que el script que se trataba corriese como un demonio o servicio, de manera tal de no tener que preocuparse de ejecutarlo manualmente cada vez. Vamos entonces a ver cuáles son nuestras opciones.

Opción 1: Ejecutar un proceso como demonio o servicio en Linux

Esto es lo que Alejo pedía exactamente, y posiblemente lo más difícil de conseguir. El equivalente de los servicios en Windows, conocidos como demonios en el mundo *nix,  se maneja tradicionalmente a través del proceso Init, heredado del viejo Unix. Pero este sistema con tantos años detrás tenía sus limitaciones, y entonces varias opciones nuevas y más funcionales surgieron. Una de ellas es Upstart, creada originalmente para Ubuntu, pero hoy en día presente en varias distros, ya sea como el reemplazo por defecto del viejo Init o como un opcional.

Continue reading


Oct 22 2012

VMware deja de andar luego de actualizar a Ubuntu 12.10

Gabolonte Blasfemus

No es extraño encontrarse frecuentemente con que los productos de VMware para escritorio, como Workstation y Player, sufran problemas de compatibilidad con los kernels Linux más recientes. Algunas veces se resuelve instalando la última versión e.x.p (que son betas de la próxima versión estable por venir), pero en esta ocasión no es posible solucionarlo de esta manera, y el problema se da al pasar al nuevo kernel 3.5.x que usa, por ejemplo, el nuevo Ubuntu 12.10 Quantal Quetzal; cuando abrimos VMware Workstation 9 ó VMware Player 5 (últimas versiones disponibles de ambos productos al momento de escribir esto) todo parece ir bien, pero al intentar encender una máquina virtual nos vamos a encontrar con el siguiente mensaje de error:

“Unable to change virtual machine power state: Failed to power on ‘ruta-de-máquina-virtual‘.Transport (VMDB) error -14: Pipe connection has been broken.”

Este problema se debe a cambios introducidos en la versión 3.5 del kernel Linux para los cuales estos productos aún no están preparados para funcionar. Afortunadamente existe una solución si no queremos quedarnos sin máquinas virtuales en nuestra distro Linux hasta que aparezcan nuevas versiones de estos productos, ya que uno de los miembros de su comunidad de usuarios identificado como An_tony es el autor de un parche, basado en otro creado por Artem S. Tashkinov, que restituye el normal funcionamiento de VMware Workstation 9 y VMware Player 5 bajo el kernel Linux 3.5.x. Para aplicarlo debemos bajar y descomprimir el archivo vmware9_kernel35_patch.tar.bz2 (click para descargar) en nuestro equipo. Al hacerlo nos encontraremos con dos archivos: vmware3.5.patchpatch-modules_3.5.0.sh. Este último es el que deberemos ejecutar, bajo derechos de superusuario por supuesto, para aplicar este parche de software a VMware. La forma más segura y a prueba de posibles errores que puedan salir es la siguiente:

Parándonos con la terminal en la ruta donde descomprimimos los dos archivos, primero nos aseguramos que el archivo patch-modules_3.5.0.sh posea derechos de ejecución en el sistema.

chmod +x patch-modules_3.5.0.sh

Antes de ejecutarlo, eliminamos todos los módulos de VMware presentes en el kernel actual, ya que pueden traer problemas a la hora de aplicar el parche.

sudo rm /lib/modules/$(uname -r)/misc/vm*

Luego reiniciamos el sistema, y finalmente ejecutamos el parche, siempre con derechos de superusuario:

sudo ./patch-modules_3.5.0.sh

Veremos unos cuantos mensajes en la consola y una vez finalizado leeremos el mensaje “All done, you can now run …” más el nombre del producto VMWare que encontró y parcheó en nuestra máquina. Luego de esto deberíamos poder correr nuestras máquinas virtuales sin problemas.

Por supuesto, en estos casos la famosa máxima your mileage may vary es más válida que nunca y puede que por algún motivo no funcione o incluso terminar con un kernel panic. Nunca está de más recordar que cada uno es responsable de lo que hace en su sistema.

El parche en sí, que se encuentra en el archivo vmware3.5.patch, está en código fuente, por lo que cualquiera con los conocimientos suficientes puede revisarlo para asegurarse que solo haga lo que dice hacer.


Oct 16 2012

Revoluciones desde abajo

Gabolonte Blasfemus

“…y ésta es la extensión de mi miembro viril…”

Los 70’s fueron indiscutidamente una época revolucionaria, no sólo en temas políticos y morales, sino también tecnológicos. En esos tiempos, las computadoras ya existían, pero costaban fortunas y sólo una compañía importante podía permitirse el poseer una. Esto comenzó a cambiar cuando unos cuantos jóvenes inquietos crearon, gracias a los recientes avances en microprocesadores de la época, sus propias microcomputadoras, el germen de lo que luego se llamó, genéricamente, la computadora personal.

Este fue el David que venció de una pedrada al Goliat de los mainframes, e incluso así se lo imaginaba el mismo Steve Jobs cuando comparaba a Apple con IBM (como se retrató en Pirates of Silicon Valley, película que si aún no viste te aconsejo encarecidamente que corras y lo hagas). Las PCs eran mucho más básicas y lentas que los poderosos sistemas de cómputo de IBM, pero no importaba: Eran mucho más asequibles y se rompía la regla de una computadora por empresa, ahora podía ser una computadora por persona.

Continue reading


Ago 10 2012

Reconexión automática a VPN en Ubuntu Linux

Gabolonte Blasfemus

Aquellos que osadamente urgan en este repositorio de pecaminosas incongruencias saben bien que la seguridad al conectarse en redes Wi-Fi es un tema que siempre me interesó, llegando a dejar algunos consejos para una navegación más segura.

Desde hace ya algunos años que mi método de seguridad rutinario a la hora de conectarme desde mi portátil, ya sea desde Windows o Ubuntu, es a través de una VPN. En particular uso OpenVPN, que me parece excelente por una larga serie de motivos, entre los que cuento:

  1. Open Source.
  2. Clientes para casi todas las plataformas, incluidas las móviles; aunque ahí el mayor problema es el soporte de los fabricantes ya que en Android o iOS no alcanza con instalar una aplicación.
  3. Servidor también multiplataforma, aunque lo más recomendable es hacerlo desde Linux.
  4. Y tal vez lo más importante, no usa ningún protocolo raro que vaya a dar problemas con routers hogareños y demás; va por UDP o por TCP, y hasta podemos configurarlo para elegir uno o el otro, incluso cambiar el puerto por defecto. Esto es especialmente útil para los access points de lugares como StarBucks donde tienen ortivamente bloqueados todos los puertos de salida con excepción de los necesarios para navegar, el 80 que corresponde a http, y el 443 para su contraparte segura el https, y sólo en TCP. En este caso podemos levantar nuestro servidor OpenVPN en cualquiera de estos dos puertos con TCP y hacerles pito catalán lo más panchos.

Sin embargo, dentro de toda esta maravilla tenía un pequeño problema. Es muy normal que a veces la conexión VPN se interrumpa, generalmente por microcortes en la red inalámbrica. En el caso de OpenVPN GUI, la interfaz gráfica para gestionar las conexiones del cliente para Windows, esto no es un gran problema, ya que automáticamente reintenta hasta que vuelve a establecer el túnel VPN. En Linux, al menos si utilizamos para conectarnos el Network Manager de Gnome que incorporan distros como Ubuntu, al ocurrir la interrupción la conexión no vuelve a resumirse, y nuestro único aviso es el pequeño y diminuto icono del candado que desaparece del icono del Network Manager y un temporal mensaje que nos avisa del evento. Si estábamos absortos en algo o no mirábamos a la pantalla es fácil obviarlo, y continuar con nuestra sesión ya sin contar con la protección necesaria para no encontrarse a merced de ojos ajenos. Y aunque los diálogos de configuración de Network Manager contemplan la posibilidad de marcar la conexión para que se realice automáticamente, esta opción sencillamente aún no funciona para las conexiones VPN.

Vi que existen otros métodos para resolver este problema, pero el que realmente me funcionó tiene que ver con la genial posibilidad que poseen las versiones más recientes del Network Manager de controlarlo desde la consola a través del comando nmcli. Esto abre las puertas a una solución simple y sucia de scripting como la que vi en este hilo de AskUbuntu.

#! /bin/bash

REQUIRED_CONNECTION_NAME="name-of-connection"
VPN_CONNECTION_NAME="name-of-vpn-connection"
activ_con=$(nmcli con status | grep "${REQUIRED_CONNECTION_NAME}")
activ_vpn=$(nmcli con status | grep "${VPN_CONNECTION_NAME}")
if [ "${activ_con}" -a ! "${activ_vpn}" ];
then
     nmcli con up id "${VPN_CONNECTION_NAME}"
fi

Este script básicamente conecta la VPN definida sólo cuando determinada conexión de red, que puede ser inalámbrica, por cable, o 3G, se vuelve activa. En este caso, name-of-connection es el nombre que lleva en Network Manager la conexión de red sobre la cual queremos establecer la conexión VPN, por ejemplo una conexión a una red Wi-Fi; name-of-vpn-connection es por otro lado el nombre que lleva la conexión VPN que deseamos usar, no importa si es por OpenVPN u otro estándar. Pero para mi menester necesito algo aún mucho más simple, yo sólo necesito que la conexión VPN a la que decidí conectarme vuelva a reconectarse automáticamente en caso de corte, por lo que mi script quedó, desde mi poco pulidos conocimientos, así:

#! /bin/bash

NUNCA=1
VPN_CONNECTION_NAME="name-of-vpn-connection"
while [ $NUNCA ]; do
     activ_vpn=$(nmcli con status | grep "${VPN_CONNECTION_NAME}")
     if [ ! "${activ_vpn}" ];
     then
          nmcli con up id "${VPN_CONNECTION_NAME}"
     fi
     sleep 5
done

El anterior es un script que podemos ejecutar desde cualquier ventana de terminal y dejarlo corriendo todo el tiempo que lo necesitemos de fondo. Al ejecutarlo lo único que hace es entrar en un loop interminable donde chequea si la conexión VPN definida está levantada, y si no lo está la activa; luego espera 5 segundos y vuelve a comenzar. Se puede refinar muchísimo más la idea pero si lo queremos hacer simple y rápido podemos tener una copia de este script para cada perfil VPN que usemos, y luego ya no hará falta conectarse desde el icono del Network Manager a la VPN, simplemente ejecutamos el script seleccionado y mientras no lo interrumpamos con un Ctrl+C o cerrando la ventana se va a encargar de mantener siempre arriba el enlace VPN.