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.


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.


Jul 18 2012

Consola de root con derechos de escritura desde el menú de recuperación de Ubuntu

Gabolonte Blasfemus

Es sabido que en Ubuntu, por una cuestión de políticas acordes a su concepción de la seguridad, no se permite el ingreso bajo ninguna forma desde la cuenta de superusuario, normalmente conocida como root. A todos los efectos, todo usuario que tenga que realizar cualquier tarea administrativa en el sistema operativo deberá utilizar el comando sudo precediendo al comando original en la consola y luego validarlo ingresando su contraseña, o escribir esta cuando el sistema se lo pida ante determinadas acciones que requieren elevación de privilegios.

Sin embargo, existe un único caso en el que la distro de Canonical permite ingresar como root, aunque solo a una línea de comandos; y esto es cuando se elige desde el menú de inicio de GRUB2 la opción de arranque en modo de recuperación. Cuando la elegimos, en vez de cargar la interfaz gráfica como es habitual se acaba en un menú en modo texto con diversas opciones útiles a la hora de reparar un Ubuntu roto. Una de ellas, por razones obvias la más avanzada, es la de cargar una línea de comandos bajo la cuenta del superusuario. El problema es, al menos en la versión 12.04 de Ubuntu (Precise Pangolin), que esta opción monta al raíz del sistema como solo lectura; por tanto, tenemos todos los derechos para hacer lo que haga falta, pero como no podemos escribir nada al disco, no podemos hacer casi nada.

Desconozco si esto es una omisión o error o simplemente la aplicación de otra política más de seguridad para evitar que usuarios novatos metan mano y rompan algo, pero la realidad es que cuando se aterriza en el menú de recuperación y en particular en la opción de la consola de root es porque uno ya está medio desesperado porque su Ubuntu no levanta y está dispuesto a probar algunas cosas, al menos en mi caso con extremo cuidado y siguiendo instrucciones de antemano cuando no sé qué hacer, para ver si se resuelve. En estas situaciones, llegar hasta ahí y encontrarse con la impotencia de no poder hacer nada para reparar el sistema es bastante frustrante.

Pero como decía antes, tal vez se trata solamente de una pruebita más puesta por Canonical para evaluar si sabemos lo que hacemos cuando nos dirigimos a la todopoderosa opción de la línea de comandos de root. No hay que olvidar que como le repitieron hasta el hartazgo a Peter Parker, con grandes poderes llegan grandes responsabilidades. Para resolver este root con acceso de solo lectura al disco, todo lo que tenemos que hacer es utilizar el comando mount para remontarlo con acceso de lectura/escritura, de la siguiente manera:

mount -o remount,rw /

Y listo, solo con introducir este comando ahora sí tenemos acceso a hacer, solucionar (o romper aún más) nuestra Ubuntu box.

Como dije, bien puede ser una feature by design. ¿Alguna vez la tuvieron que usar?