admin

Instalando mod_wsgi en OSX El Capitan

Receta rápida:

$ git clone https://github.com/GrahamDumpleton/mod_wsgi.git
$ cd mod_wsgi
$ ./configure
$ make
$ sudo make install
$ sudo vim /etc/apache2/httpd.conf

Añadir las siguientes dos líneas:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so
WSGIScriptAlias / /Library/WebServer/Documents/

Reiniciar Apache y comprobar:

$ sudo apachectl restart
$ apachectl -M | grep wsgi
 wsgi_module (shared)

Podemos probar con este Hello World (hello.py). Copiarlo en /Library/WebServer/Documents y abrirlo desde el navegador con http://localhost/hello.py :

import os, sys
sys.path.append('.')
def application(environ, start_response):
    status = '200 OK'
    output = 'Hello world!!\n'
    response_headers = [('Content-type', 'text/plain'),
        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Done.

Transmission, torrents, OSX y malware KeRanger

Cuando necesito descargar torrents, uso Transmission en Linux y uTorrent en OSX. No es que uTorrent esté libre de pecado (Spigot -PUP-, EpicScale -mining de bitcoin no deseado, y demás basura), pero la semana pasada (4 de marzo) Transmission para OSX llevaba de regalo KeRanger, ransomware. Sí, malware que cifra el contenido de tu disco duro y te pide un rescate – pagado en bitcoin, por supuesto- para obtener la clave que lo descifra. Parece ser el primer caso de ransomware dirigido específicamente a usuarios de OSX. Fue la gente de Palo Alto Networks fueron los primeros en dar el aviso, indicando que la web de Transmission había sido comprometida, dejando un fichero de instalación .dmg(la versión 2.90 de Transmission) infectado con KeRanger. Lo «bonito» del asunto es que esta versión de KeRanger había sido firmada con un certificado válido de desarrollador de aplicaciones para OSX, saltándose el control básico de Apple Gatekeeper que impide a un usuario básico instalar una aplicación que no venga firmada (se salta abriendo el binario con el menú contextual mientras pulsas Control, pero es una primera barrera de seguridad). Si el usuario instaló la versión infectada de Transmission, esta ejecutará una versión incrustada de KeRanger, esperará 3 días (suele ser habitual esperar a ejecutar el castigo, para ocultar al usuario el origen de la infección) y se comunicará con un servidor C&C (Command & Control) sobre la red Tor. A partir de ahí, cifrado del disco y petición de rescate (400 dólares).

Apple ha actuado rápido. Lo primero, invalidar el certificado con el que se firmó la aplicación en cuestión. Lo segundo, añadir una regla a XProtect, el sistema de lista negra que usa OSX por defecto. Puedes consultar los bichos que pululan por Internet en este fichero de tu OSX: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist. ¿El primero de la lista? Nuestro amigo KeRanger:

El análisis técnico del bicho en la página de Palo Alto Networks merece mucho la pena. Verás que el desarrollador está preparando funciones específicas para buscar y cifrar backups de Time Machine (qué angelito…). Verás también que usa tanto cifrado asimétrico (RSA) para cifrar un número elegido al azar junto a un IV dependiente del contenido del fichero, con lo que formará la clave que usará para cifrar el contenido del fichero usando cifrado simétrico (AES).

El 5 de marzo la gente de Transmission eliminó el ejecutable infectado de su web. Apple también ha hecho su trabajo. Pero el secuestro de webs para implantar malware parece que está de moda. Hace un par de semanas fue el turno de Linux Mint. Esta semana ha caído Transmission. ¿Quién será el siguiente?

Formateo y validación de objetos JSON

En esta ocasión, aprovechando que esta semana se estudia el formato JSON en una de mis clases, os quería recomendar un par de utilidades que utilizo a menudo: la herramienta jq y el plugin JSONView.

jq es una utilidad de la línea de comandos disponible para Linux, OS X y Windows que permite validar y visualizar de forma muy agradable objetos JSON. La mejor forma de apreciar el uso de jq es por medio de un ejemplo. En la siguiente figura, muestro un objeto JSON en la terminal sin usar jq. A continuación lo vuelvo a mostrar, esta vez filtrándolo con jq. Mucho mejor, ¿no?

jq también detecta objetos JSON inválidos, marcando dónde se encuentra el error:

JSONView es similar a jq, pero funciona como plugin o extensión, tanto de Google Chrome como de Mozilla Firefox. Veamos un ejemplo con el resultado de una llamada al API de OpenWeatherMap.

Sin usar JSONView:

Con la extensión JSONView instalada:

Sí, representan exactamente el mismo resultado. Pero uno es legible por humanos y el otro no 🙂

¿Conocíais estas utilidades? ¿Qué extensiones usáis en vuestros desarrollos? (HTML5, JS, PHP, whatever…)

Demasiadas conexiones a MySQL desde R

Estoy desarrollando una nueva aplicación en R+Shiny. Entre otras cosas, el servidor Shiny necesita acceder a los datos de una BBDD en MySQL. Tengo código en R que accede a MySQL sin problemas, abre y cierra las conexiones bien, sin leaks por dejar conexiones abiertas. Bueno, eso es lo que creía… cuando por alguna razón la aplicación fallaba, podían darse casos en los que alguna conexión se quedaba abierta. Por una o dos, no pasaba «nada». Pero probando y probando, llegué a este error:

«cannot allocate a new connection — maximum of 16 connections already opened»

Vaya… el primer problema es: ¿cómo desconecto las conexiones abiertas? La respuesta a esto en la lista de distribución de R:

 cons <- dbListConnections(MySQL()) 
 for(con in cons) 
  dbDisconnect(con)

Y ahora, ¿cómo evitar el error? Lo ideal sería establecer una especie de conexión singleton que se reutilizara desde todo el código. La respuesta a esto, en StackOverflow (cómo no ;-))

library(RMySQL)
getConnection <- function(group) {
  if (!exists('.connection', where=.GlobalEnv)) {
    .connection <<- dbConnect(MySQL(), group=group)
  } else if (class(try(dbGetQuery(.connection, "SELECT 1"))) == "try-error") {
    dbDisconnect(.connection)
    .connection <<- dbConnect(MySQL(), group=group)
  }
  return(.connection)
}

Este código comprueba si existe una conexión en el entorno global. Si no existe, la crea y la devuelve.
Si existe, comprueba que se pueda usar. Si no se puede usar, desconecta y vuelve a crear la conexión, para devolverla.
Es decir, funciona como una caché (o puede verse también como un objeto singleton de tipo connection).
Podríamos ignorar el parámetro group de la función getConnection y en su lugar, usar:

 dbConnect(MySQL(), user=login, password=pass, db=database, host=host)

allí donde fuera necesario.

De DiarioLinux.com a Ikasten.io

Llevo mucho tiempo intentando escribir este post. Incluso creo que lo llegué a hacer, pero perdí el fichero donde lo guardaba. No recuerdo si lo hice en un documento de Google Drive, en Keep, en un fichero de texto plano, en un borrador de post, en un mensaje de correo a mí mismo… o si lo soñé, que también puede ser. El mero hecho de perderlo o de no saber a ciencia cierta si lo llegué a crear, me da que pensar. Vivimos una época en la que las conversaciones se llevan a cabo en redes sociales (Facebook, Twitter) y programas de mensajería instantánea (WhatsApp, Telegram). Todo es rápido, al momento, todo se consume de manera inmediata. No queda tiempo para sentarse a reflexionar y menos para escribir posts largos.

Antes no era así. Recuerdo una época en la que escribía largos mensajes varias veces a la semana. Eran posts con enjundia, donde compartía conocimiento práctico que había probado con calma. Eran posts sobre temas relacionados con Linux y el software libre. Era lo que me movía. Era un bonito «trabajo», que me llevó de 2001 a 2014. En los últimos dos años (2014-2015) dejé de escribir en el blog. Sucumbí a las redes sociales. En especial, a Twitter. Sucumbí al software privativo, en especial al sistema OSX.

Abandoné DiarioLinux, pero no abandoné Linux. Sigo usándolo, pero no en el escritorio. Me cansé de pelear con drivers, configuraciones, aplicaciones y entornos. Quería seguir trabajando con un sistema Unix. Pero también quería las últimas aplicaciones. Y sucumbí a la manzana. Es curioso, esa historia de la manzana ya ocurrió hace miles de años 😉

La cuestión es que tengo ganas de tomarme las cosas con más calma. Y de escribir de forma más pausada y pensada de lo que escribo en Twitter. ¿Quiere esto decir que dejaré de tuitear? No, seguiré haciéndolo, aunque probablemente bajando la frecuencia. Sigo creyendo que Twitter aporta mucha información de calidad (aparte de montañas de ruido). Gran parte de esta información la tengo marcada con un «favorito» (ahora, con un corazón, cursi, rojo). Hasta ahora, marcaba así los tuits en los que me interesaba profundizar. «Cuando tenga tiempo». «Este enlace quiero leerlo con calma». Autoengaños. Ahí siguen, marcados pero sin leer. Como los cientos de libros técnicos en formato digital que acumulo (casi 300, y subiendo) para leer algún día (será imposible hacerlo).

Así que toca simplificar. No preocuparse tanto por acumular, sino por soltar lastre. No preocuparse tanto por las novedades, sino por profundizar en alguna de ellas o en alguna de las que, en su día, fue novedad marcada como «favorita» e interesante, pero de la que nunca más supe. Eso es lo que pretendo hacer, pararme a inspeccionar con más detalle aquellos temas que piquen mi curiosidad. Temas técnicos en su mayor parte, pero también sobre docencia, idiomas, running, series, cine o libros. Como veis, temas que no estarán ceñidos sólo a Linux o al Software Libre. Temas, en general, sobre los que querría aprender más. De ahí el cierre de DiarioLinux y el comienzo de este nuevo blog, Ikasten.io /Aprendiendo/.

Espero que estas reflexiones no se queden sólo en eso o que, al menos, pasen a formar parte de una buena colección de posts al respecto 🙂

PD: DiarioLinux.com cerrará, pero no se perderá el contenido. Todos los posts, comentarios e imágenes adjuntas han sido copiadas a ikasten.io dentro del subdominio diariolinux.ikasten.io. Por el momento, diariolinux.com estará unos meses redirigiendo el tráfico (con cabeceras 301 Redirect). En 2017 cerrará definitivamente.