Ikasten.IO

perl: warning: Setting locale failed

Conectamos por ssh contra nuestro servidor, lanzamos un comando erróneo y aparte del mensaje de error el intérprete de comandos nos suelta el siguiente sermón:

# comando erróneo
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "es_ES.UTF-8",
	LC_ADDRESS = "es_ES.UTF-8",
	LC_MONETARY = "es_ES.UTF-8",
	LC_NUMERIC = "es_ES.UTF-8",
	LC_TELEPHONE = "es_ES.UTF-8",
	LC_IDENTIFICATION = "es_ES.UTF-8",
	LC_MEASUREMENT = "es_ES.UTF-8",
	LC_TIME = "es_ES.UTF-8",
	LC_NAME = "es_ES.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
ERROR: (algo relacionado con el comando erróneo)

Mmmh… ¿por qué? Pues porque en el fichero /etc/ssh/sshd_config tenemos una linea como la siguiente:

AcceptEnv LANG LC_*

Que viene a decir: las variables de entorno relacionadas con el idioma del usuario deben ser exportadas al intérprete de comandos destino de una conexión ssh. En mi caso, el soporte es_ES. El problema es que los paquetes de ese idioma en el servidor destino no están instalados… de ahí que Linux se queje amargamente.
Bueno, para evitarlo hay varias formas. La más sencilla: basta con comentar la línea en cuestión de /etc/ssh/sshd_config (añadiéndole un # por delante) y ¡listo!

Parchear Ubuntu para evitar el bug OpenSSL Heartbleed

Ayer a la tarde se levantó una buena polvareda con el bug Heartbleed de OpenSSL. Básicamente, cualquier usuario podría acceder a una zona de 64Kb de memoria del servidor, cercana a la zona donde se gestionan las operaciones con SSLv3. Esto podría llegar a permitir acceder a información privilegiada, como por ejemplo la clave privada usada para el cifrado. Aunque hay dudas técnicas sobre este aspecto específico (acceso a las claves privadas), los investigadores que descubrieron el bug así lo afirman (como indica el primer link). Conclusión: estás tardando en actualizar OpenSSL en tu servidor 🙂

sudo apt-get update
sudo apt-get install -y libssl1.0.0 openssl
openssl version -a # y confirma que es la nueva versión ("built on" >= 2014-04-07)
sudo lsof -n | grep ssl | grep DEL  # reload de todos los servicios que usen versión vieja

Repite el último paso hasta que no queden servicios usando la versión vieja de openssl.

Gracias a coderanger por los tip.

Update (11/04/2014): como dije, hay serias dudas de que el acceso a las claves privadas sea viable. De hecho, uno de las primeras webs donde se expuso el bug lanza ahora un reto: han puesto un servidor HTTPS vulnerable en marcha y retan a la comunidad a extraer la clave privada usando el bug Heartbleed.

Update (13/04/2014): pues han tardado unas pocas horas en extraer la clave privada. Vaya, vaya…

Resize de volúmenes en LVM

Tenemos un sistema de discos LVM con las siguientes «particiones»:

[juanan@S000161 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_s000161-lv_root
                       50G   39G  8.6G  82% /
tmpfs                 5.8G  316K  5.8G   1% /dev/shm
/dev/mapper/ddf1_4c5349202020202080862925000000004711471100001450p1
                      485M   58M  402M  13% /boot
/dev/mapper/vg_s000161-lv_home
                      395G   87G  288G  24% /home

Si nos fijamos, el volumen lógico (lv) asignado a / está al 82% y sólo tiene 8.6GB libres. Por otro lado, el LV /home tiene GB de sobra (288GB libres, con sólo un 24% de utilización).

Vamos a recortar un poco (100GB) de /home para «estirar» / .

Siempre como root, desmontar el volumen, revisar posibles errores, y reducir tanto el sistema de archivos (ext4) como el propio volumen. Estas dos últimas operaciones se pueden hacer de un plumazo con la opción -r de lvreduce.

umount /dev/mapper/vg_s000161-lv_home
e2fsck -f /dev/mapper/vg_s000161-lv_home
lvreduce -r /dev/mapper/vg_s000161-lv_home --size -100G
(ojo, -100, con el menos por delante. Si pones 100G, sin el menos, recortas hasta ese tamaño!!!!)

Ahora que tenemos 100GB disponibles, los usaremos para aumentar la «partición» /.

Asegurarse de que está montado el volumen (sí, ¡montado!) y le damos caña:

lvextend /dev/mapper/vg_s000161-lv_root -r --size +100G

Depurar, editar y guardar ficheros JS en Google Chrome

Receta rápida para los desarrolladores JavaScript interesados, y para retomar el blog tras un parón de unos cuantos meses (he estado ocupado 🙂

La cuestión es: las DevTools de Google Chrome permiten editar y depurar código JavaScript desde el propio navegador. Pero cuando editas un fichero .js y lo intentas guardar, salta el siguiente error:

«Changes to this file were not saved to file system». Vaya… pues qué bien… mmmmhh…. ¿y qué dice StackOverflow al respecto? Que existe una solución 🙂 Vamos allá…

Lo primero: pulsa en el botón de configuración.

Lo segundo, elige la opción Workspaces y añade las carpetas con las que trabajas (las que contienen tu código JS):

Puedes añadir más de una carpeta. Fíjate también que puedes editar mapeos URL –> Carpeta local, pero ahí no me meto (por ahora!)

Ojo, cuando añadas carpetas tendrás que aceptar dar permiso, para cada una, para que DevTools pueda acceder a esos datos en modo lectura/escritura. Esta ventana de solicitud de permisos aparece por debajo, en la ventana de Chrome, así que atento, porque hasta que no la pulses, la carpeta no se añadirá correctamente.

Ya casi está. Si estás usando el protocolo file:// para trabajar con tus ficheros en lugar de http://, ojo, porque en ese caso, deberás abrir tus archivos JS desde la carpeta que acabas de añadir al workspace (no vale abrir el fichero haciendo doble click sobre él desde el escritorio o tecleando la ruta en la barra de direcciones del navegador).

Sino que tendrás que ir a la pestaña «Sources» y hacer doble click sobre los ficheros de las carpetas importadas (ojo, no desde file://)

Y a partir de ahora, cualquier cambio realizado en el panel DevTools podrás guardarlo «automágicamente» en el sistema de archivos local con un simple Ctrl+S.

¿Quién lanzó esta ventana?

Problema: una aplicación ha lanzado una ventana en tu escritorio, pero no sabes exactamente qué aplicación es «la culpable».

Solución: desde una terminal, lanzamos el comando

$  xwininfo

Nos dará un ID de ventana. Por ejemplo, en mi caso, el 0x3e00004.

Pedimos ahora las propiedades de ese ID y, más en concreto, el identificador del proceso al que pertenece:

$ xprop -id 0x3e00004 _NET_WM_PID
_NET_WM_PID(CARDINAL) = 3189

Bien, sólo nos queda pedir una lista de procesos y filtrar por el PID que acabamos de obtener:

$ ps auxww| grep 3189
juanan 3189 0.0 0.4 494700 16396 ? Sl 12:52 0:00 update-notifier

Ajá! update-notifier es el culpable…