diariolinux

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…

LibreOffice Writer: desactivar corrector ortográfico en referencias de Zotero

Como ya presentamos en su día, Zotero es un gestor open source de referencias bibliográficas. Se integra perfectamente en el procesador de textos LibreOffice Writer… Bueno, perfectamente no, tiene un fallo, que es el que quiero comentar (y arreglar). Al añadir las referencias bibliográficas las inserta en el documento Writer sin preocuparse de cambiar el idioma en el que estás escribiendo. Alguien dirá: ¿lógico, no? Si estás escribiendo en castellano, ¿por qué debería insertar la referencia en otro idioma?. La cuestión es que debería insertar las citas SIN especificar idioma. ¿Por qué? Porque si mantienes un idioma (cualquiera), al pasar el corrector ortográfico, cada vez que haya una referencia Zotero, el corrector se quejará, creyendo que es un error de ortografía. Para evitarlo, basta con que ejecutes esta macro una vez terminado tu documento. Cambiará el idioma de las referencias a «Sin idioma», lo que permitirá omitir su revisión en el corrector, ahorrándonos un precioso tiempo.

El bug original y la solución para MS Word en la que me he basado, así como esta misma macro que acabo de enviarles, puedes encontrarlos en los foros de Zotero.

Sub DeactivateProofingOfZoteroFields
Dim oReferenceMarks
Dim oReferenceMark
Dim oReferenceNames
Dim anchor
 
REM preparar locale vacío para evitar avisos del corrector ortográfico
REM Visto en "OpenOffice.org Macro Information" (Andrew Pitonyak)
Dim noLocale As New com.sun.star.lang.Locale
noLocale.Country = ""
noLocale.Language = "zxx"
 
REM recorrer las referencias bibliográficas
REM asegurándose de que han sido insertadas por Zotero
REM y asignarles el noLocale
 
oReferenceMarks = ThisComponent.getReferenceMarks()
oReferenceNames = oReferenceMarks.getElementNames()
For i = LBound(oReferenceNames) to UBound(oReferenceNames)
 
	sName = oReferenceNames(i)
 
	if (InStr(sName, "ZOTERO") = 1) then
		oReferenceMark = oReferenceMarks.getByName(sName)
		anchor = oReferenceMark.getAnchor()
		anchor.CharLocale = noLocale
	end if
 
Next i
 
End Sub