Planeta GNOME Hispano
La actividad Hispana de GNOME 24 x 7

21 de marzo de 2017

Cómo hacer un backup de tus mensajes de Telegram

Supongamos que quieres hacer un backup de los mensajes de un grupo (canal, supergrupo, conversaciones privadas, usuarios, whatever…) de Telegram.  Puede haber distintas razones para ello: simple copia de seguridad para estar tranquilo, porque vas a irte de un grupo, porque van a cerrar el mismo… o, como en mi caso, con fines estadísticos.

Hasta donde yo sé, Telegram no ofrece herramientas directas para esta labor, pero al usar un protocolo abierto y bien documentado, hay gente que se ha pegado el curro de implementar aplicaciones cliente desde cero. Una de esas aplicaciones es tg, escrita en C, software libre y ejecutable desde la línea de comandos. tg es “simplemente” un cliente de Telegram, pero ofrece -entre muchas otras funcionalidades interesantes- la opción de ser ejecutado en modo servidor. De esta forma, mediante scripting, nos será posible obtener toda la información que tengamos almacenada en esta plataforma de mensajería instantánea. Pero no adelantemos acontecimientos 🙂 Lo primero será compilar esta bestia, cosa nada fácil (al menos en OSX, donde estoy ahora mismo).

Descargamos tg y seguimos los pasos de compilación e instalación. En resumen:

git clone --recursive https://github.com/vysheng/tg.git
cd tg

En OSX necesitarás instalar dependencias usando brew como sistema de gestor de paquetes:
brew install libconfig readline lua python libevent jansson
Verás multitud de warnings relacionados con posibles conflictos de versiones (sqlite, readline, SSL…). Brew nos avisa de que OSX ya viene con algunas de esas librerías instaladas y que si queremos usar o compilar las de brew tendremos que cambiar las variables de entorno (PATH, LDFLAGS , CFLAGS, PKG_CONFIG_PATH). Bueno, por ahora haremos caso omiso a esos warnings. Y pasamos al siguiente paso:

./configure

Idealmente te debería mostrar un mensaje de que todo va bien.

Y llegamos al make, donde seguramente obtengas un error indicando algo similar a:

lua-tg.c:664:27: error: unused function 'get_peer' [-Werror,-Wunused-function]

Un error en la línea get_peer. Si es el caso, tendrás que aplicar este parche, así:

patch < lua.patch
Patching file lua-tg.c

y volver a ejecutar el make. Si todo va bien, obtendrás un mensaje como el siguiente y de premio, el ejecutable telegram-cli en la carpeta bin.

La primera vez que ejecutes tg tendrás que asociarlo con tu número de teléfono. No olvides indicar el prefijo +34 si estás en España. Te llegará un PIN de verificación al teléfono (a través de un mensaje Telegram). Es el PIN que deberás indicar en la línea CALL correspondiente.
u026627:bin juanan$ ./telegram-cli
Telegram-cli version 1.4.1, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type show_license'.
This is free software, and you are welcome to redistribute it
under certain conditions; type
show_license' for details.
Telegram-cli uses libtgl version 2.1.0
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
I: config dir=[/Users/juanan/.telegram-cli]
[/Users/juanan/.telegram-cli] created
[/Users/juanan/.telegram-cli/downloads] created
phone number: +34XXXXXXXXX
code ('CALL' for phone code): XXXXX
User Juanan Pereira updated flags
User Juanan Pereira online (was online [2017/03/20 14:15:45])

Ahora dispondrás de multitud de comandos (teclea help para ver la lista completa). Puedes probar que todo ha ido bien tecleando comandos como get_self, para obtener información sobre tu cuenta en Telegram, contact_list para ver un listado con el nombre de tus contactos o channel_list para ver el nombre de los canales y grupos a los que estás suscrito.

Es interesante remarcar que tg dispone de autocompletamiento en la línea de comandos (soporte readline), por lo que basta con teclear las primeras letras del comando y pulsar TAB para que rellene el resto. Para salir, teclear quit.

Para poder cumplir con el objetivo marcado al comienzo de este post (backup de los mensajes de un grupo) necesitaremos instalar un script que maneje tg de forma automática. Se trata de telegram-history-dump, escrito en Ruby:

git clone https://github.com/tvdstaaij/telegram-history-dump

Debemos asegurar que disponemos de una versión reciente de Ruby (>= 2.0).

ruby --version
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

Ahora podemos decidir hacer backup de todo o sólo de algunos grupos en concreto. Yo sólo necesito backup de un super-grupo, así que edito el fichero de configuración del script config.yaml e indico en la sección [backup_supergroups] que quiero sólo el grupo “MI_GRUPO”. En el resto de secciones, indico null.

Para finalizar, lanzamos tg en modo servidor:

./telegram-cli --json -P 9009

(escuchando en el puerto 9009 e intercambiando mensajes en formato JSON)

y ¡por fin! lanzamos el script de backup:

u026627:telegram-history-dump juanan$ ruby telegram-history-dump.rb
I, [2017-03-20T14:27:23.381792 #24590]  INFO -- : Attaching to telegram-cli control socket at localhost:9009
I, [2017-03-20T14:27:23.849295 #24590]  INFO -- : Skipping XXX dialogs: .....
I, [2017-03-20T14:27:23.849485 #24590]  INFO -- : Backing up 1 dialogs: "MI_GRUPO"
I, [2017-03-20T14:27:23.849783 #24590]  INFO -- : Dumping "MI_GRUPO" (range 1-100)
I, [2017-03-20T14:27:24.854833 #24590]  INFO -- : Dumping "MI_GRUPO" (range 101-200)
I, [2017-03-20T14:27:25.860089 #24590]  INFO -- : Dumping "MI_GRUPO" (range 201-300)
I, [2017-03-20T14:27:26.864448 #24590]  INFO -- : Dumping "MI_GRUPO" (range 301-400)
I, [2017-03-20T14:27:27.869046 #24590]  INFO -- : Dumping "MI_GRUPO" (range 401-500)
I, [2017-03-20T14:27:28.872592 #24590]  INFO -- : Dumping "MI_GRUPO" (range 501-600)
I, [2017-03-20T14:27:28.977374 #24590]  INFO -- : Finished

Tras unos segundos (veremos el progreso en la terminal donde tengamos lanzado telegram-cli) obtendremos el resultado en la carpeta output/ . Si disponemos del comando jq (si no, lo instalamos con brew install jq) podremos visualizar el JSON resultante cómodamente así:

cat output/json/MI_GRUPO.jsonl | jq

Espero que os haya sido de interés 🙂

 

20 de marzo de 2017

WebKitGTK+ 2.16

The Igalia WebKit team is happy to announce WebKitGTK+ 2.16. This new release drastically improves the memory consumption, adds new API as required by applications, includes new debugging tools, and of course fixes a lot of bugs.

Memory consumption

After WebKitGTK+ 2.14 was released, several Epiphany users started to complain about high memory usage of WebKitGTK+ when Epiphany had a lot of tabs open. As we already explained in a previous post, this was because of the switch to the threaded compositor, that made hardware acceleration always enabled. To fix this, we decided to make hardware acceleration optional again, enabled only when websites require it, but still using the threaded compositor. This is by far the major improvement in the memory consumption, but not the only one. Even when in accelerated compositing mode, we managed to reduce the memory required by GL contexts when using GLX, by using OpenGL version 3.2 (core profile) if available. In mesa based drivers that means that software rasterizer fallback is never required, so the context doesn’t need to create the software rasterization part. And finally, an important bug was fixed in the JavaScript garbage collector timers that prevented the garbage collection to happen in some cases.

CSS Grid Layout

Yes, the future here and now available by default in all WebKitGTK+ based browsers and web applications. This is the result of several years of great work by the Igalia web platform team in collaboration with bloomberg. If you are interested, you have all the details in Manuel’s blog.

New API

The WebKitGTK+ API is quite complete now, but there’s always new things required by our users.

Hardware acceleration policy

Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16.

Network proxy settings

Since the switch to WebKit2, where the SoupSession is no longer available from the API, it hasn’t been possible to change the network proxy settings from the API. WebKitGTK+ has always used the default proxy resolver when creating the soup context, and that just works for most of our users. But there are some corner cases in which applications that don’t run under a GNOME environment want to provide their own proxy settings instead of using the proxy environment variables. For those cases WebKitGTK+ 2.16 includes a new UI process API to configure all proxy settings available in GProxyResolver API.

Private browsing

WebKitGTK+ has always had a WebKitSetting to enable or disable the private browsing mode, but it has never worked really well. For that reason, applications like Epiphany has always implemented their own private browsing mode just by using a different profile directory in tmp to write all persistent data. This approach has several issues, for example if the UI process crashes, the profile directory is leaked in tmp with all the personal data there. WebKitGTK+ 2.16 adds a new API that allows to create ephemeral web views which never write any persistent data to disk. It’s possible to create ephemeral web views individually, or create ephemeral web contexts where all web views associated to it will be ephemeral automatically.

Website data

WebKitWebsiteDataManager was added in 2.10 to configure the default paths on which website data should be stored for a web context. In WebKitGTK+ 2.16 the API has been expanded to include methods to retrieve and remove the website data stored on the client side. Not only persistent data like HTTP disk cache, cookies or databases, but also non-persistent data like the memory cache and session cookies. This API is already used by Epiphany to implement the new personal data dialog.

Dynamically added forms

Web browsers normally implement the remember passwords functionality by searching in the DOM tree for authentication form fields when the document loaded signal is emitted. However, some websites add the authentication form fields dynamically after the document has been loaded. In those cases web browsers couldn’t find any form fields to autocomplete. In WebKitGTk+ 2.16 the web extensions API includes a new signal to notify when new forms are added to the DOM. Applications can connect to it, instead of document-loaded to start searching for authentication form fields.

Custom print settings

The GTK+ print dialog allows the user to add a new tab embedding a custom widget, so that applications can include their own print settings UI. Evolution used to do this, but the functionality was lost with the switch to WebKit2. In WebKitGTK+ 2.16 a similar API to the GTK+ one has been added to recover that functionality in evolution.

Notification improvements

Applications can now set the initial notification permissions on the web context to avoid having to ask the user everytime. It’s also possible to get the tag identifier of a WebKitNotification.

Debugging tools

Two new debugged tools are now available in WebKitGTk+ 2.16. The memory sampler and the resource usage overlay.

Memory sampler

This tool allows to monitor the memory consumption of the WebKit processes. It can be enabled by defining the environment variable WEBKIT_SMAPLE_MEMORY. When enabled, the UI process and all web process will automatically take samples of memory usage every second. For every sample a detailed report of the memory used by the process is generated and written to a file in the temp directory.

$ WEBKIT_SAMPLE_MEMORY=1 MiniBrowser 
Started memory sampler for process MiniBrowser 32499; Sampler log file stored at: /tmp/MiniBrowser7ff2246e-406e-4798-bc83-6e525987aace
Started memory sampler for process WebKitWebProces 32512; Sampler log file stored at: /tmp/WebKitWebProces93a10a0f-84bb-4e3c-b257-44528eb8f036

The files contain a list of sample reports like this one:

Timestamp                          1490004807
Total Program Bytes                1960214528
Resident Set Bytes                 84127744
Resident Shared Bytes              68661248
Text Bytes                         4096
Library Bytes                      0
Data + Stack Bytes                 87068672
Dirty Bytes                        0
Fast Malloc In Use                 86466560
Fast Malloc Committed Memory       86466560
JavaScript Heap In Use             0
JavaScript Heap Committed Memory   49152
JavaScript Stack Bytes             2472
JavaScript JIT Bytes               8192
Total Memory In Use                86477224
Total Committed Memory             86526376
System Total Bytes                 16729788416
Available Bytes                    5788946432
Shared Bytes                       1037447168
Buffer Bytes                       844214272
Total Swap Bytes                   1996484608
Available Swap Bytes               1991532544

Resource usage overlay

The resource usage overlay is only available in Linux systems when WebKitGTK+ is built with ENABLE_DEVELOPER_MODE. It allows to show an overlay with information about resources currently in use by the web process like CPU usage, total memory consumption, JavaScript memory and JavaScript garbage collector timers information. The overlay can be shown/hidden by pressing CTRL+Shit+G.

We plan to add more information to the overlay in the future like memory cache status.

21 de febrero de 2017

Compilando phantomjs para ARM

Solución: Crear un fichero de SWAP https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/

y seguir compilando siguiendo la guía de la propia web de Phantomjs.

Done! Puedes descargar el binario desde este repositorio GitHub.

10 de febrero de 2017

Accelerated compositing in WebKitGTK+ 2.14.4

WebKitGTK+ 2.14 release was very exciting for us, it finally introduced the threaded compositor to drastically improve the accelerated compositing performance. However, the threaded compositor imposed the accelerated compositing to be always enabled, even for non-accelerated contents. Unfortunately, this caused different kind of problems to several people, and proved that we are not ready to render everything with OpenGL yet. The most relevant problems reported were:

  • Memory usage increase: OpenGL contexts use a lot of memory, and we have the compositor in the web process, so we have at least one OpenGL context in every web process. The threaded compositor uses the coordinated graphics model, that also requires more memory than the simple mode we previously use. People who use a lot of tabs in epiphany quickly noticed that the amount of memory required was a lot more.
  • Startup and resize slowness: The threaded compositor makes everything smooth and performs quite well, except at startup or when the view is resized. At startup we need to create the OpenGL context, which is also quite slow by itself, but also need to create the compositing thread, so things are expected to be slower. Resizing the viewport is the only threaded compositor task that needs to be done synchronously, to ensure that everything is in sync, the web view in the UI process, the OpenGL viewport and the backing store surface. This means we need to wait until the threaded compositor has updated to the new size.
  • Rendering issues: some people reported rendering artifacts or even nothing rendered at all. In most of the cases they were not issues in WebKit itself, but in the graphic driver or library. It’s quite diffilcult for a general purpose web engine to support and deal with all possible GPUs, drivers and libraries. Chromium has a huge list of hardware exceptions to disable some OpenGL extensions or even hardware acceleration entirely.

Because of these issues people started to use different workarounds. Some people, and even applications like evolution, started to use WEBKIT_DISABLE_COMPOSITING_MODE environment variable, that was never meant for users, but for developers. Other people just started to build their own WebKitGTK+ with the threaded compositor disabled. We didn’t remove the build option because we anticipated some people using old hardware might have problems. However, it’s a code path that is not tested at all and will be removed for sure for 2.18.

All these issues are not really specific to the threaded compositor, but to the fact that it forced the accelerated compositing mode to be always enabled, using OpenGL unconditionally. It looked like a good idea, entering/leaving accelerated compositing mode was a source of bugs in the past, and all other WebKit ports have accelerated compositing mode forced too. Other ports use UI side compositing though, or target a very specific hardware, so the memory problems and the driver issues are not a problem for them. The imposition to force the accelerated compositing mode came from the switch to using coordinated graphics, because as I said other ports using coordinated graphics have accelerated compositing mode always enabled, so they didn’t care about the case of it being disabled.

There are a lot of long-term things we can to to improve all the issues, like moving the compositor to the UI (or a dedicated GPU) process to have a single GL context, implement tab suspension, etc. but we really wanted to fix or at least improve the situation for 2.14 users. Switching back to use accelerated compositing mode on demand is something that we could do in the stable branch and it would improve the things, at least comparable to what we had before 2.14, but with the threaded compositor. Making it happen was a matter of fixing a lot bugs, and the result is this 2.14.4 release. Of course, this will be the default in 2.16 too, where we have also added API to set a hardware acceleration policy.

We recommend all 2.14 users to upgrade to 2.14.4 and stop using the WEBKIT_DISABLE_COMPOSITING_MODE environment variable or building with the threaded compositor disabled. The new API in 2.16 will allow to set a policy for every web view, so if you still need to disable or force hardware acceleration, please use the API instead of WEBKIT_DISABLE_COMPOSITING_MODE and WEBKIT_FORCE_COMPOSITING_MODE.

We really hope this new release and the upcoming 2.16 will work much better for everybody.

02 de febrero de 2017

Going to FOSDEM!

It’s been two years since the last time I went to FOSDEM, but it seems that this year I’m going to be there again and, after having traveled to Brussels a few times already by plane and train, this year I’m going by car!: from Staines to the Euro tunnel and then all the way up to Brussels. Let’s see how it goes.

FOSDEM 2017

As for the conference, I don’t have any particular plan other than going to some keynotes and probably spending most of my time in the Distributions and the Desktops devrooms. Well, and of course joining other GNOME people at A La Bécasse, on Saturday night.

As you might expect, I will have my Endless laptop with me while in the conference, so feel free to come and say “hi” in case you’re curious or want to talk about that if you see me around.

At the moment, I’m mainly focused on developing and improving our flatpak story, how we deliver apps to our users via this wonderful piece of technology and how the overall user experience ends up being, so I’d be more than happy to chat/hack around this topic and/or about how we integrate flatpak in EndlessOS, the challenges we found, the solutions we implemented… and so forth.

That said, flatpak is one of my many development hats in Endless, so be sure I’m open to talk about many other things, including not work-related ones, of course.

Now, if you excuse me, I have a bag to prepare, an English car to “adapt” for the journey ahead and, more importantly, quite some hours to sleep. Tomorrow it will be a long day, but it will be worth it.

See you at FOSDEM!

30 de enero de 2017

@firma ahora es AutoFirma

Esta nota es sólo de interés para españoles interesados (necesitados) en relacionarse con la administración pública española. En realidad apenas es un recordatorio de que, hasta donde he comprobado, la anteriormente conocida como cliente @Firma (o Afirma) en sus últimas versiones se denomina AutoFirma.

La respuesta a la consulta al Observatorio eAdmon tampoco me ha sido clara.

No queda nada claro en ninguna de las referencias que he encontrado, pero lo que me ha dado luz en el asunto es repasar el código fuente de AutoFirma.

Repaso de mi búsqueda:

Conclusión: vamos, que casi seguro que sí, que lo que antes se llamaba @Firma (o afirma según el caso) ahora se llamaría oficialmente AutoFirma aunque el repositorio de desarrollo sigue siendo el mismo.

Dicho todo esto por si a alguien le es útil esta info cuando esté dando tumbos desde los buscadores. Que ojalá les sirva.

PS: Finalmente el Observatorio eAdmon me ha dado un poco más de luz, confirmando mi suposición:

25 de enero de 2017

«¡Brindis por Ceres!»

Parece que fue ayer cuando la FMNT-RCM solicitó la inclusión de su certificado raiz en el sistema de distribución de certificados raiz de CA CA/Browser Forum de su oficial autoridad de certificación (CA en inglés) en España CERES. Bueno, en realidad no fue ayer, fue el 26 de mayo de 2008:

pero lo que sí fue ayer 25 de enero de 2017, es la resolución exitosa del procedimiento:

Sólo ha tomado 3167 días para una de las instuciones más importantes de España y uno de los proyectos de migración a la economía digital más importantes del país que ha sido la obligada, y convengo que necesaria, adopción de las prácticas de comunicaciones digitales seguras al menos en la relación con las administraciones del estado. Pero para el usuario la experencia ha sido con frecuencia frustrante y el que más y el que menos hemos padecido problemas: desde la no inclusión de serie en el software que usamos del certificado raiz a las endiabladas configuraciones de los servicios de cada administración que con frecuencia hacían incompatible una configuración de tu navegador entre ellas. Y todo ello sin contar con la peor experiencia aún que ha sido la de la adopción del DNIe. Personalmente hace tiempo que renuncié a usar el DNIe.

¿Tan difícil era hacerlo antes? Estoy convencido de que se trata de un proceso muy riguroso pero, diablos, estamos hablando de la Real Casa de la Moneda, no de cualquier departamento escondido. Estamos hablando del certificado raiz que, en teoría, debería usar la Agencia Tributaria, que podemos concluir que como recaudador tiene las más imperiosas necesidades en mantener el mejor, más accesible y económico portal electrónico con el ciudadano aunque sólo sea para el mayor beneficio de las arcas del estado. Tanto es así que para ser más operativo la Agencia Tributaria a partir de cierto momento adoptó los certificados emitidos por Camerfirma, que si bien son reconocidos por el estado son gestionados por el Consejo Superior de Cámaras de Comercio que entiendo es una entidad semi privada.

Por muy prestigiosa y loable entiendo que Camerfirma no es una organización completamente estatal y en mi opinión, aparte de la apreciación estética por la incongruencia, es el epítome de los problemas del desarrollo e implantación de la administración electrónica en España, a pesar de los recursos aportados y el esfuerzo bienintencionado de los funcionarios que han puesto todo su corazón en un avance tan importante.

Aunque tampoco todo el monte es orégano, como puede apreciarse en el certifcado usado en la Aplicación Web Prestadores de Servicios de Certificación:

En fin, bueno es si bien acaba, que 3167 días no son nada.

Las comparaciones son odiosas

Y bueno, sí yo también, como diría República Gorila sí que estoy un poquito lleno de odio y sí, podemos intentar comparar la duración de diferentes procedimientos de admisión a través del servicio Bugzilla de Mozilla:

Y por brevedad sólo elegiremos algunas firmas reconocidas oficialmente en España:

Camerfirma

  • Entrada 562395
  • registro: 2010-04-28
  • resolución: 2010-12-02
  • duración: 219 días

Agencia de Tecnología y Certificación Electrónica

  • Entrada 653761
  • registro: 2011-04-29
  • resolución: 2011-07-31
  • duración: 94 días

Consorci AOC (CAtCert)

  • Entrada 707995
  • registro: 2011-12-06
  • resolución: 2012-01-17
  • duración: 43 días

EDICOM

  • Entrada 550521
  • registro: 2010-03-05
  • resolución: 2010-03-29
  • duración: 130 días

En fin. La lista no es exhaustiva aunque me ha parecido comprobar que hay varias AC reconocidas que o no han pasado por el proceso o sencillamente siquiera lo han solicitado. En cualquier caso felicitamos al campeón de nuestra somera investigación, el equipo de CATCert que ha sido capaz de resolver en 43 días lo que a nuestra referente FNMT ha tomado, insistimos, 3167 días.

Otros asuntos en el tintero

Me quedo sin más tiempo para extenderme como quisiera verificando el estado de las siguientes cuestiones pendientes:

  • ¿Está reconfigurado por fin el servicio de renovación de los certificados FNMT para que pueda usar, por ejemplo, las versiones recientes de navegadores (observemos que la primera versión de Firefox que incorpora de serie el certificado es la 53.0a). Personalmente hace unos meses me encontré con la imposibilidad de poder renovar mi certificado usando una configuración que desactive cosas como el inseguro protocolo SSL3, práctica habitual en cualquier navegador moderno.
  • El servicio OCSP de Ceres, ¿está por fin públicamente accesible sin pagos?

Convocatoria

Pero alegremos los corazones. Desde mi modesta tribuna convoco a todos los españoles a celebrar este pequeño paso para la humanidad pero un paso de gigante para Ceres-FMNT brindando por tan feliz suceso:

¡Brindis por Ceres!

PS: Sergio de los Santos parece que profundizó mucho más en los progresos técnicos del proceso de aprobación en la increíble historia de Firefox y el certificado raíz de la FNMT.

24 de enero de 2017

SSH-Vault: Cifrar y descifrar un fichero usando la clave ssh

Suelo pedir a mis alumnos que generen un par de claves SSH para darles de alta en alguno de los servidores que usamos en la asignatura (añadiendo la parte pública en el fichero de claves autorizadas, authorized_keys). Lo siguiente suele ser crearles una base de datos y un usuario con acceso a la misma. Aquí, el usuario necesita una contraseña. Para pasarles esta contraseña y otros datos privados, solía pedirles a su vez que me enviaran su clave pública GPG. Realmente, este último paso no es necesario… si disponemos ya de una clave pública SSH podemos usarla para cifrar y descifrar ficheros, muy fácilmente. Una de las formas más sencillas es mediante una aplicación de la línea de comandos, ssh-vault.com.

Para cifrar, usaremos el siguiente comando:

echo -n "mensaje a cifrar" | ./ssh-vault -k /ruta/a/clave/publica/id_rsa.pub create vault

Para descifrar, el receptor usará este otro comando:

./ssh-vault -k /ruta/a/tu/fichero/.ssh/id_rsa view vault

También podríamos haber evitado el uso de una aplicación extra, usando los comando ssh-keygen y openssl que seguramente ya tengamos (la “pega” es que un usuario Windows no las tendrá…):

Convertimos la clave pública ssh a formato PEM:

ssh-keygen -f ~/.ssh/id_rsa.pub -e -m PKCS8 &gt; id_rsa.pem.pub

A continuación, ciframos el mensaje:

openssl rsautl -encrypt -pubin -inkey id_rsa.pem.pub -ssl -in myMessage.txt -out myEncryptedMessage.txt

El receptor usará también openssl para descifrar:

openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in myEncryptedMessage.txt -out myDecryptedMessage.txt

Fuente, cómo no, un hilo de discusión en SuperUser, una de las webs de la red StackExchange, la misma que alberga a StackOverflow.com

10 de enero de 2017

ngrok, o cómo resolver problemas a distancia

Llevaba unos cuantos días intentando resolver un problema de configuración de Apache a otra persona, por email. Me enviaba detalles del problema, pantallazos en algún caso y yo le respondía con posibles soluciones, comandos que debería ejecutar y ficheros de configuración que debería editar. Se trataba de una máquina local, detrás de un NAT. Tras muchas idas y venidas, no conseguíamos resolver y pensando en cómo solucionarlo, me encontré con una herramienta que me ha permitido hacerlo en 2 minutos, ngrok 🙂 Permite exponer puertos tras el NAT de forma muy sencilla, de tal forma que si expone por ejemplo el puerto 22, yo pueda conectarme de forma remota a administrar su máquina. Lógicamente debe haber confianza entre ambas partes, para evitar sustos de seguridad.

Para ello, la persona con el problema de configuración ha tenido que realizar los siguientes pasos:
Instalar openssh (si no lo tiene ya instalado):
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install openssh-server

Poner en marcha openssh:
$ sudo service ssh start

Instalar ngrok (la aplicación que expone puertos tras el NAT)
Tras instalar, debe darse de alta: https://ngrok.com/signup
Una vez realizado ese paso,  ngrok le devolverá el comando a ejecutar para identificarse en ngrok. Algo como:
./ngrok authtoken XXXXXXX

Abrir el puerto 22 (ssh) al exterior: (magia!)
$ ./ngrok tcp 22
(Este comando te dará como resultado una dirección ngrok, que es la que tiene que enviar a la persona que le ayuda. Algo como:  tcp://0.tcp.ngrok.io:13011 )
La persona que le ayuda, en este caso yo 🙂  podrá conectarse así:
$ ssh -l usuario 0.tcp.ngrok.io -p13011

Lógicamente, la persona con el problema antes debe haberle enviado al ayudante un nombre de usuario y contraseña para conectar por ssh.

Una vez conectado, el ayudante puede abrir otras sesiones para tunelizar más puertos. Por ejemplo:

$ ssh -l usuario 0.tcp.ngrok.io -p13011 -L 8080:localhost:80

Ese comando permite tunelizar el puerto 80 de la máquina remota para dejarlo accesible a través del puerto 8080 de la máquina local. Es decir, si el ayudante en su navegador teclea ahora: http://localhost:8080 en realidad se estará conectando a través del túnel ssh al puerto 80 de la máquina remota (tras el NAT). Muy, muy interesante para permitir la administración remota de equipos. Lo dicho, en dos minutos he podido resolver así un problema que se estaba estirando ya unos cuantos días por la incomodidad de analizar el problema vía email…

09 de enero de 2017

How to Re-enable One-Finger Tap and Drag, and Menu Buttons Selection by Keyboard In OS X

These tips were written for OSX Yosemite but they also work for macOS Sierra so I won’t rewrite them 🙂

08 de enero de 2017

What’s the default password of root user in mariadb?

If you have just installed mariadb, you should run this command in order to set a password for the root user and secure your installation:

$ sudo mysql_secure_installation

Besides asking you to provide the new root password, this utility will help you to remove anonymous user (created by default, intended for testing), disallow root login remotely (root should only be allowed to connect from ‘localhost’), remove test database and privileges ad reloading the privilege table. All of it just pressing the Enter key a couple of times 🙂 Not bad!

If that process doesn’t work, try this other one:

(using sudo, don’t specify any password)

$ sudo mysql -u root

Create a new database:

CREATE DATABASE yourdb;

Grant privileges to a new user:

GRANT ALL ON yourdb.* TO yournewuser@localhost IDENTIFIED BY 'yourpassword';
FLUSH privileges;

 

07 de enero de 2017

How to download snapshots from DigitalOcean into local machines

There isn’t any direct option to download a snapshot from DigitalOcean to your local machine, but there certainly is a workaround:

If your intent is to backup a remote computer’s HDD A via SSH to a single file that’s on your local computer’s HDD, run this from your local computer:

$ ssh user@remote "dd if=/dev/vda1 | gzip -1 -" | dd of=image.gz

Source: https://www.digitalocean.com/community/questions/downloading-snapshots-into-local-machines

You should double check that your disk /dev name is /dev/vda1 (like the one in my example) using the df -h command first.

21 de diciembre de 2016

Creando un servicio personal de OpenVPN

He decidido, por fin, crear mi propio servicio VPN. Los motivos principales son poder asegurar navegación privada y cercionarme que uso un servicio de confianza 100% auditado… por mi.

Requisitos

  • servicio OpenVPN
  • usando docker
  • servidor Centos 7
  • reutilizando alguna configuración existente
  • pero sin reutilizar imágenes publicadas en el Docker Hub, por celo en la seguridad
  • poder conectar desde máquinas Linux y teléfonos Android

La configuración elegida es una creada por Kyle Manna: https://github.com/kylemanna/docker-openvpn/ ¡Gracias Kyle!

Procedimiento de instalación y configuración del servidor

En este caso usamos CentOS 7, pero como no está disponible docker-compose he tenido que retro-portarlo y lo tenéis disponible en un repositorio específico.

Preparación:

cd /etc/yum.repos.d ; wget https://copr.fedorainfracloud.org/coprs/olea/docker-compose/repo/epel-7/olea-docker-compose-epel-7.repo
yum install -y docker docker-compose
yum install -y docker-lvm-plugin.x86_64 docker-latest.x86_64
yum upgrade -y
groupadd docker
usermod -G docker -a USUARIO
echo "VG=sys" > /etc/sysconfig/docker-storage-setup
docker-storage-setup
systemctl enable docker
systemctl start docker

Si docker ha podido arrancar entonces probablemente está listo para empezar a trabajar.

Obviamente también hay que configurar el DNS del servicio VPN.MISERVIDOR.COM en el servidor correspondiente.

Entrando en materia:

mkdir servicio-VPN.MISERVIDOR.COM
cd servicio-VPN.MISERVIDOR.COM
git clone https://github.com/kylemanna/docker-openvpn
cat <<EOF > docker-compose.yml
version: '2'
services:
    openvpn:
        build:
            context: docker-openvpn/
        cap_add:
            - NET_ADMIN
        image: Mi-ID/openvpn
        ports:
            - "1194:1194/udp"
        restart: always
        volumes:
            - ./openvpn/conf:/etc/openvpn
EOF

Y continuando con las instrucciones indicadas:

  • construimos localmente la imagen docker desde cero de una sola vez:
docker-compose run --rm openvpn ovpn_genconfig -u udp://VPN.MISERVIDOR.COM
  • iniciamos la AC local propia (se nos pedirá la contraseña de la clave privada):
docker-compose run --rm openvpn ovpn_initpki
  • finalmente lanzamos el contenedor:
docker-compose up -d openvpn

Procedimiento de altas de usuarios

  • Alta del usuario:
docker-compose run --rm openvpn easyrsa build-client-full USUARIO nopass
  • generación de la configuración local de OpenVPN para el mismo usuario:
docker-compose run --rm openvpn ovpn_getclient USUARIO > USUARIO.ovpn
  • Este fichero lo copiaremos a nuestra máquina porque es el que nos habilitará el acceso VPN.

Problema importando configuraciones de OpenVPN y NetworkManager

Personalmente me he encontrado el problema varias veces de que el GUI de configuración de NetworkManager no es capaz de importar los certificados criptográficos al configurar una conexión VPN importando ficheros ovpn. Tras investigarlo varias veces he concluido que se debe a un bug documentado que en mi caso no está resuelto en NetworkManager-openvpn-gnome-1.0.8-2.fc23 pero sí en NetworkManager-openvpn-gnome-1.2.4-2.fc24.

Si aún os encontráis con ese problema habría dos alternativas: o actualizar a una versión reciente de NM o conectarse manualmente desde el CLI:

sudo /usr/sbin/openvpn --config USUARIO.ovpn

Acabemos con los intersticiales

¡Interstitials!

Vaya palabro. “Interstitials”. Intersticiales en español. Anuncios intersticiales; que para la RAE serían aquellos que ocupan los intersticios, pero que, realmente, son anuncios que ocupan toda la pantalla y son especialmente molestos porque,

  • Impiden visualizar la página que queremos ver. Vamos, que molestan, y mucho más, que los pop-ups de toda la vida.
  • Incitan al click fraudulento: La mayor parte de las veces que pulsamos sobre el anuncio, no es para acceder al producto anunciado sino para cerrar el mismo. El botón para cancelarlo suele requerir de una especial destreza (o puntería) del usuario sobre su pantalla multitáctil… a menos que tengas los dedos del tamaño de la cabeza de un alfiler.

Anuncio Intersticial, imagen de Google

Pues bien, hace ahora más de 4 meses, Google anunció que iba a penalizar el uso de anuncios intersticiales en las búsquedas desde móvil a partir de enero de 2017, algo que ya está a la vuelta de la esquina.

Es bueno recordarlo porque, a día de hoy, la mayor parte de las páginas de actualidad en Internet siguen incorporando este tipo de anuncios como si nada, haciendo muy incómoda la lectura, sobre todo en móviles, donde deshacerse del anuncio resulta complicado y por lo que, muchas veces, un servidor decide abandonar el medio de comunicación elegido para irme a uno alternativo que me informe más y me moleste menos.

Aún me queda la esperanza de que esta penalización del buscador realmente consiga su efecto. Mientras tanto, seguiremos haciendo uso extensivo y abusivo de los bloqueadores de anuncios, pese a los avisos de determinados medios de que eso les hace daño.

06 de diciembre de 2016

Segurtasunarekin lotutako berriak (Abenduko bigarren astea)

Azken egun hauetan mugimendua egon da, betiko legez, segurtasun informatikoko munduan.

DailyMotion hackeatuta (85 miloi kontuen datuak agerian)
dailymotionhackeatutaDailyMotion bideoak online partekatzeko plataforma bat da, YouTube edo Vimeo bezalakoa. Astelehenean bertan jakinarazi zutenez urriaren 20an eraso bat jaso ostean DailyMotion-eko erabiltzaileen 85 miloi kontuen kredentzialak agerian utzi zituzten (hacker batek informazio hori lortu eta enpresatik atera zuen). Dirudienez datuen artean email helbidea, erabiltzailearen izena eta kasu batzuetan (18 miloi kontuetan) pasahitzen hashak (bcrypt hash funtzioaz lortutakoak, nahiko sendoak beraz, eta krakeatzeko latzak).

Erasoaren berri LeakedSource-k eman zuen. Webgune horretan zure email helbidea eta erabiltzailea sartu eta berehala jakin ahalko duzu ea hackeatutako datubaseren batean agertzen den edo ez. Horrelako beste webgune famatu bat (ospetsuena) Troy Hunt  ikerlariaren “Have I been pwned?” zerbitzua da. Oso gomendagarriak biak.

Visa txartelen datuak 6 segundo baino gutxiagotan hackeatu daitezke
captura-de-pantalla-2016-12-06-a-las-11-31-38New Castle Unibertsitateko ikerlari talde batek demostratu du VISA txartelen datuak lortzeko 6 segundu baino gehiago ez dituztela behar. Horretarako tresna berezi bat prestatu dute. Tresna horrek hainbat webgune ezberdinetan probatzen ditu txartel baten zenbakien konbinazioak eta txarto (edo ondo) daudenak apuntatzen ditu. Probak webgune ezberdinetan egiten dituenez, VISA enpresak ez du ezer arrarorik somatzen (normalean txartelearen datuak sartzerakoan akats batzuk jarraian egiten badituzu webgune bakar batean bankuetxeak alertak jasotzen ditu). Diruenez MASTERCAD-eko txartelak eraso mota honi aurre egiteko prestatuta daude (erasoak ez du eraginik bertan). Bideo bat ere argitaratu dute, tresna nola erabiltzen den erakutsiz.

Hacker-ek Errusiako Banku Zentrala erasotu eta 31 miloi dolar lapurtu dituzte

Ez dago informazio handirik baina Errusiako Banku Zentralak berak egiaztatu du pasa den ostiralean hackerrek 31 miloi dolar lapurtu zituztela bertan. Dirudienez hackerrek banku pribatuak ere erasotu zituztela baina bertan lapurtu zutenaren berri ez dago. Symantec enpresako ikerlarien arabera munduko bankuen sistemak eraso bortitzak jasaten ari da egun hauetan oso trebea den hacker talde baten eraginez (“Lazarus” izenarekin ezaguna omen da, batzuen ustez Ipar Korearekin lotutakoa). Baina oraingo honetan ez dago garbi zein dagoen erasoaren atzean.

01 de diciembre de 2016

Azken aste hauetan izandako segurtasun auziak

Twitter-eko @segurtasuna kontuan idazten dut askotan. Edo hobeto esanda, erabiltzaile horri aipuak egiten dizkiot. Batzuetan, informazio teknikoa banatzeko erabiltzen dut: tresna berri bat sortu dela, CTF baten berri, exploit berri bat… Beste batzuetan, ordea, segurtasun informatikoko erasoen berri emateko erabiltzen dut kontua. Azken hauek dira gehien kezkatzen nautena, gure eguneroko bizitzan duten edo izan dezaketen eragina sekulakoa baita.

Eta gauza da, eraso horiek gero eta gehiago eta gero eta larriagoak direla. Azter dezagun horietako batzuk.

Azpiegituren kontrako erasoak

Orain dela aste batzuk, La9deAnon taldeko kideek Nafarroako ubidearen kontrol sisteman sartzea lortu zuten. Gaizki inplementatutako segurtasun politikaz baliatuz (edo okerrago, segurtasun politika sendo baten gabezia aprobetxatuz). Nork daki… agian defektuzko eta aldatu gabeko  pasahitz baten bidez lortu zuten bertan sartzea. Tontakeri bat dirudi baina hori da azken finean Mirai botnetak erabili duen teknika erraza: Internet of Things (IoT) delako gailu-en sarean milloika bideo-zainketa kamarak (ikusteko -CCTV- eta grabatzeko -DVR-) kutsatu ditu defektuzko 60 inguruko erabiltzaile eta pasahitz bikoteak probatuz.

Deutsche Telekom-eko erabiltzaileen router-ak

DEUTSCHE TELEKOM -speedport-w-724v
CCTV eta DVR-en segurtasun arazoa ezaguna zen baina hara non eta router-ak ere Mirai botnet-aren biktimak bilakatu dira. Kasu honetan ez defekutzko pasahitzak dituztelako baizik eta Interneteko hornitzaileek router hauen urruneko konfigurazioa lortzeko erabiltzen duten protokoloaren segurtasun ahulezi bateaz baliatuz. Ez edozein router… batez ere Alemanian oso ezagunak diren Zyxel konpainiak sortutakoak (batez ere Deutsche Telekom honitzaileak erabiltzen dituen router-ak) . 900.000 router inguru kutsatu ditu jada soilik Alemanian baina dirudienez, kutsadura zabaltzen ari da Brasilen eta Erresuma Batuan.

DynDNS interneko DNS azpisistema

Arazo latza, larria eta sakona. Batez ere jakinda Mirai botnet-aren iturburu kodea orain dela gutxi ireki eta GitHub-en kaleratu zutela. Mirai botnet-ak Brian Krebs segurtasun informatikoan aditua den ikerlariaren webgunea botatzea lortu zuen (DDoS baten bidez, azken finean). 665gbps-eko traifikoko jario erraldoia sortu ondoren, Interneten inoiz ikusi ez den jarioa hain zuzen ere.

Horrelako ahalmena suntsitzailea duen jario batek OVH bezalako hornitzaileen kontra egin dezake. Eta irabazi. Edo soilik beraien babes-neurriak probatu. Hori da hain zuzen ere Bruce Schnneier adituak dioena, arerioaren ahalmenaren proba batzuk besterik ez direla. Jakin nahi baitute norainoko neurriak dituzten. Eta oraindik beldurra gorputzean ez bazaizu sartu, entzun hau: Mirai botnet-a alokatu daiteke. Bai, zuk-zeuk, edo beste edozeinek. Ez gara oso argiak izan behar asmatu ahal izateko zeinek eta zertarako erabili dezaketen botnet hau. Adibidez, DNS sistemaren parte den Dyn DNS enpresaren kontra egiteko. Enpresa horrek, halaber, hainbat enpresen DNS erregistroak kudeatzen ditu. DNS-a bertan behera uztea lortuz gero, erabiltzaileek ezingo dituzte enpresa webgune horiek atzitu (IP helbidea jakinez gero bai, baina orduan ez zara erabiltzaile arrunt bat izango 😉

Mirai-k DNS-ak erasotzeko erabiltzen dituen teknikak, aurreratuak dira. Ez dira etor-berri batzuk. Etorkizunean (hori da Mirai hitzaren esanahia, japonieraz) Mirai kode kaltegarriaren aldaerak sortuko dira eta erasotzen jarraituko dute, dudarik gabe.

San Francisco-ko trena (Muni-hack)

muni-hackDemagun Mugi/Lurraldebus online sistema norbaitek hackeatzen duela. Demagun ransomware baten bidez, sistema kutsatu egiten duela. Eta erreskatea ordaindu arte (edo babes-kopiak berreskuratu arte) sistema bertan behera geratzen dela. Zer gertatuko litzateke? Ba, ziur asko, San Francisco tren sisteman ( San Francisco Municipal Transportation Agency, SFMTA edo Muni izenarekin ezagutzen dena) gertatu zena: txartelak saltzeko makinetan “You Hacked, ALL data encrypted” mezua agertuko zela. Eta 73.000$ ordaindu arte, erasotzaileek ez zutela sistema berreskuratzeko gakoa bidaliko esan zuten. Egun horretan dohain bidaiatu zuten tren erabiltzaile guztiek (babes-kopietatik sistema berreskuratu arte).

Nolakoak diren gauzak… SFMTA hackeatu zuena, halaber, hackeatua izan zen egun gutxitara. Eta bere mail mezuetan agertu diren aztarnak aztertu ondoren, dirutza lortu zuen erreskateen bidez, beste enpresa handi batzuk kutsatu ondoren. Negozioa.

Bizpahiru adibide dira gaur honera ekarri ditudanak. Ez dira lehenengoak… tamalez, ezta azkenengoak izango ere.

23 de noviembre de 2016

Conferencia: HackLab Almería, un modelo de dinamización tecnológica hiperlocal

El 24 de noviembre he sido invitado a charlar para hablar de la experiencia de HackLab Almería en un evento en Antequera organizado por IBM. He aprovechado para seguir trabajando en el material retrospectiva del HackLab Almería que preparé para el GDG Spain Summit y lo he adaptado a formato de transparencias con mi agradecido Slidy.

Las transparencias están disponibles en https://olea.org/conferencias/doc-conf-20161124-Encuentro-IBM/

captura de pantalla de las transpas

Además voy a tener la oportunidad de volver a impartir la conferencia en un par más de ocasiones así que creo que refinaré más aún este material, que también me sirve para profundizar la retrospectiva de los dos años largos que he dedicado a «la movida HackLab Almería».

Gracias a Haroldo Díaz Armas por la invitación, a Elisa Martín Garijo por sugerir mi persona y a Javier Bentabol por su entusiasmo con nosotros.

10 de noviembre de 2016

Web Engines Hackfest 2016

From September 26th to 28th we celebrated at the Igalia HQ the 2016 edition of the Web Engines Hackfest. This year we broke all records and got participants from the three main companies behind the three biggest open source web engines, say Mozilla, Google and Apple. Or course, it was not only them, we had some other companies and ourselves. I was active part of the organization and I think we not only did not get any complain but people were comfortable and happy around.

We had several talks (I included the slides and YouTube links):

We had lots and lots of interesting hacking and we also had several breakout sessions:

  • WebKitGTK+ / Epiphany
  • Servo
  • WPE / WebKit for Wayland
  • Layout Models (Grid, Flexbox)
  • WebRTC
  • JavaScript Engines
  • MathML
  • Graphics in WebKit

What I did during the hackfest was working with Enrique and Žan to advance on reviewing our downstream implementation of Media Source Extensions (MSE) in order to land it as soon as possible and I can proudly say that we did already (we didn’t finish at the hackfest but managed to do it after it). We broke the bots and pissed off Michael and Carlos but we managed to deactivate it by default and continue working on it upstream.

So summing up, from my point of view and it is not only because I was part of the organization at Igalia, based also in other people’s opinions, I think the hackfest was a success and I think we will continue as we were or maybe growing a bit (no spoilers!).

Finally I would like to thank our gold sponsors Collabora and Igalia and our silver sponsor Mozilla.

05 de octubre de 2016

Frogr 1.2 released

Of course, just a few hours after releasing frogr 1.1, I’ve noticed that there was actually no good reason to depend on gettext 0.19.8 for the purposes of removing the intltool dependency only, since 0.19.7 would be enough.

So, as raising that requirement up to 0.19.8 was causing trouble to package frogr for some distros still in 0.19.7 (e.g. Ubuntu 16.04 LTS), I’ve decided to do a quick new release and frogr 1.2 is now out with that only change.

One direct consequence is that you can now install the packages for Ubuntu from my PPA if you have Ubuntu Xenial 16.04 LTS or newer, instead of having to wait for Ubuntu Yakkety Yak (yet to be released). Other than that 1.2 is exactly the same than 1.1, so you probably don’t want to package it for your distro if you already did it for 1.1 without trouble. Sorry for the noise.

 

Frogr 1.1 released

After almost one year, I’ve finally released another small iteration of frogr with a few updates and improvements.

Screenshot of frogr 1.1

Not many things, to be honest, bust just a few as I said:

  • Added support for flatpak: it’s now possible to authenticate frogr from inside the sandbox, as well as open pictures/videos in the appropriate viewer, thanks to the OpenURI portal.
  • Updated translations: as it was noted in the past when I released 1.0, several translations were left out incomplete back then. Hopefully the new version will be much better in that regard.
  • Dropped the build dependency on intltool (requires gettext >= 0.19.8).
  • A few bugfixes too and other maintenance tasks, as usual.

Besides, another significant difference compared to previous releases is related to the way I’m distributing it: in the past, if you used Ubuntu, you could configure my PPA and install it from there even in fairly old versions of the distro. However, this time that’s only possible if you have Ubuntu 16.10 “Yakkety Yak”, as that’s the one that ships gettext >= 0.19.8, which is required now that I removed all trace of intltool (more info in this post).

However, this is also the first time I’m using flatpak to distribute frogr so, regardless of which distribution you have, you can now install and run it as long as you have the org.gnome.Platform/x86_64/3.22 stable runtime installed locally. Not too bad! :-). See more detailed instructions in its web site.

That said, it’s interesting that you also have the portal frontend service and a backend implementation, so that you can authorize your flickr account using the browser outside the sandbox, via the OpenURI portal. If you don’t have that at hand, you can still used the sandboxed version of frogr, but you’d need to copy your configuration files from a non-sandboxed frogr (under ~/.config/frogr) first, right into ~/.var/app/org.gnome.Frogr/config, and then it should be usable again (opening files in external viewers would not work yet, though!).

So this is all, hope it works well and it’s helpful to you. I’ve just finished uploading a few hundreds of pictures a couple of days ago and it seemed to work fine, but you never know… devil is in the detail!

 

30 de septiembre de 2016

Cross-compiling WebKit2GTK+ for ARM

I haven’t blogged in a while -mostly due to lack of time, as usual- but I thought I’d write something today to let the world know about one of the things I’ve worked on a bit during this week, while remotely attending the Web Engines Hackfest from home:

Setting up an environment for cross-compiling WebKit2GTK+ for ARM

I know this is not new, nor ground-breaking news, but the truth is that I could not find any up-to-date documentation on the topic in a any public forum (the only one I found was this pretty old post from the time WebKitGTK+ used autotools), so I thought I would devote some time to it now, so that I could save more in the future.

Of course, I know for a fact that many people use local recipes to cross-compile WebKit2GTK+ for ARM (or simply build in the target machine, which usually takes a looong time), but those are usually ad-hoc things and hard to reproduce environments locally (or at least hard for me) and, even worse, often bound to downstream projects, so I thought it would be nice to try to have something tested with upstream WebKit2GTK+ and publish it on trac.webkit.org,

So I spent some time working on this with the idea of producing some step-by-step instructions including how to create a reproducible environment from scratch and, after some inefficient flirting with a VM-based approach (which turned out to be insanely slow), I finally settled on creating a chroot + provisioning it with a simple bootstrap script + using a simple CMake Toolchain file, and that worked quite well for me.

In my fast desktop machine I can now get a full build of WebKit2GTK+ 2.14 (or trunk) in less than 1 hour, which is pretty much a productivity bump if you compare it to the approximately 18h that takes if I build it natively in the target ARM device I have 🙂

Of course, I’ve referenced this documentation in trac.webkit.org, but if you want to skip that and go directly to it, I’m hosting it in a git repository here: github.com/mariospr/webkit2gtk-ARM.

Note that I’m not a CMake expert (nor even close) so the toolchain file is far from perfect, but it definitely does the job with both the 2.12.x and 2.14.x releases as well as with the trunk, so hopefully it will be useful as well for someone else out there.

Last, I want to thanks the organizers of this event for making it possible once again (and congrats to Igalia, which just turned 15 years old!) as well as to my employer for supporting me attending the hackfest, even if I could not make it in person this time.

Endless Logo

25 de septiembre de 2016

Retrospectiva HackLab Almería 2012-2015 y pico

Este fin de semana tuve el privilegio de ser invitado por GDG Spain y en particular por ALMO para presentar en el Spanish GDG Summit 2016 la experiencia de la actividad en el HackLab Almería:

Aunque llegué muy inseguro porque soy muy crítico con los que considero fracasos míos, al conocer las vicisitudes de los grupos locales del GDG comprobé que a nosotros no nos va tan mal y que tenemos experiencias muy interesantes para terceros.

De paso me ha servido para reconsiderar parte del trabajo hecho y para documentar más claramente nuestras cosas para nuestra propia gente: creo que es buena idea que todos le demos un repaso.

Es posible que haya algún error y alguna carencia. Todas las opiniones son absolutamente personales y no todo el mundo ha de compartirlas. No tengo tanto interés en discutir las afirmaciones como de corregir errores o inconsistencias. Tened presente de que no es una memoria completa de actividades porque eso sería enooorme, sólo una retrospectiva esquemática.

Está escrita en formato de mapa-mental usando Freemind 1.0.1. El formato tal vez os parezca engorroso, pero las restricciones de tiempo y de presentación de la información no me han permitido nada mejor. Lamento las molestias. Podéis descargar el fichero que incluye el mapa desde aquí: 201609-GDG-Experiencia_HackLabAl.zip

PS: esta misma entrada ha sido publicada en el foro del HackLab Almería.

20 de septiembre de 2016

WebKitGTK+ 2.14

These six months has gone so fast and here we are again excited about the new WebKitGTK+ stable release. This is a release with almost no new API, but with major internal changes that we hope will improve all the applications using WebKitGTK+.

The threaded compositor

This is the most important change introduced in WebKitGTK+ 2.14 and what kept us busy for most of this release cycle. The idea is simple, we still render everything in the web process, but the accelerated compositing (all the OpenGL calls) has been moved to a secondary thread, leaving the main thread free to run all other heavy tasks like layout, JavaScript, etc. The result is a smoother experience in general, since the main thread is no longer busy rendering frames, it can process the JavaScript faster improving the responsiveness significantly. For all the details about the threaded compositor, read Yoon’s post here.

So, the idea is indeed simple, but the implementation required a lot of important changes in the whole graphics stack of WebKitGTK+.

  • Accelerated compositing always enabled: first of all, with the threaded compositor the accelerated mode is always enabled, so we no longer enter/exit the accelerating compositing mode when visiting pages depending on whether the contents require acceleration or not. This was the first challenge because there were several bugs related to accelerating compositing being always enabled, and even missing features like the web view background colors that didn’t work in accelerated mode.
  • Coordinated Graphics: it was introduced in WebKit when other ports switched to do the compositing in the UI process. We are still doing the compositing in the web process, but being in a different thread also needs coordination between the main thread and the compositing thread. We switched to use coordinated graphics too, but with some modifications for the threaded compositor case. This is the major change in the graphics stack compared to the previous one.
  • Adaptation to the new model: finally we had to adapt to the threaded model, mainly due to the fact that some tasks that were expected to be synchronous before became asyncrhonous, like resizing the web view.

This is a big change that we expect will drastically improve the performance of WebKitGTK+, especially in embedded systems with limited resources, but like all big changes it can also introduce new bugs or issues. Please, file a bug report if you notice any regression in your application. If you have any problem running WebKitGTK+ in your system or with your GPU drivers, please let us know. It’s still possible to disable the threaded compositor in two different ways. You can use the environment variable WEBKIT_DISABLE_COMPOSITING_MODE at runtime, but this will disable accelerated compositing support, so websites requiring acceleration might not work. To disable the threaded compositor and bring back the previous model you have to recompile WebKitGTK+ with the option ENABLE_THREADED_COMPOSITOR=OFF.

Wayland

WebKitGTK+ 2.14 is the first release that we can consider feature complete in Wayland. While previous versions worked in Wayland there were two important features missing that made it quite annoying to use: accelerated compositing and clipboard support.

Accelerated compositing

More and more websites require acceleration to properly work and it’s now a requirement of the threaded compositor too. WebKitGTK+ has supported accelerated compositing for a long time, but the implementation was specific to X11. The main challenge is compositing in the web process and sending the results to the UI process to be rendered on the actual screen. In X11 we use an offscreen redirected XComposite window to render in the web process, sending the XPixmap ID to the UI process that renders the window offscreen contents in the web view and uses XDamage extension to track the repaints happening in the XWindow. In Wayland we use a nested compositor in the UI process that implements the Wayland surface interface and a private WebKitGTK+ protocol interface to associate surfaces in the UI process to the web pages in the web process. The web process connects to the nested Wayland compositor and creates a new surface for the web page that is used to render accelerated contents. On every swap buffers operation in the web process, the nested compositor in the UI process is automatically notified through the Wayland surface protocol, and  new contents are rendered in the web view. The main difference compared to the X11 model, is that Wayland uses EGL in both the web and UI processes, so what we have in the UI process in the end is not a bitmap but a GL texture that can be used to render the contents to the screen using the GPU directly. We use gdk_cairo_draw_from_gl() when available to do that, falling back to using glReadPixels() and a cairo image surface for older versions of GTK+. This can make a huge difference, especially on embedded devices, so we are considering to use the nested Wayland compositor even on X11 in the future if possible.

Clipboard

The WebKitGTK+ clipboard implementation relies on GTK+, and there’s nothing X11 specific in there, however clipboard was read/written directly by the web processes. That doesn’t work in Wayland, even though we use GtkClipboard, because Wayland only allows clipboard operations between compositor clients, and web processes are not Wayland clients. This required to move the clipboard handling from the web process to the UI process. Clipboard handling is now centralized in the UI process and clipboard contents to be read/written are sent to the different WebKit processes using the internal IPC.

Memory pressure handler

The WebKit memory pressure handler is a monitor that watches the system memory (not only the memory used by the web engine processes) and tries to release memory under low memory conditions. This is quite important feature in embedded devices with memory limitations. This has been supported in WebKitGTK+ for some time, but the implementation is based on cgroups and systemd, that is not available in all systems, and requires user configuration. So, in practice nobody was actually using the memory pressure handler. Watching system memory in Linux is a challenge, mainly because /proc/meminfo is not pollable, so you need manual polling. In WebKit, there’s a memory pressure handler on every secondary process (Web, Plugin and Network), so waking up every second to read /proc/meminfo from every web process would not be acceptable. This is not a problem when using cgroups, because the kernel interface provides a way to poll an EventFD to be notified when memory usage is critical.

WebKitGTK+ 2.14 has a new memory monitor, used only when cgroups/systemd is not available or configured, based on polling /proc/meminfo to ensure the memory pressure handler is always available. The monitor lives in the UI process, to ensure there’s only one process doing the polling, and uses a dynamic poll interval based on the last system memory usage to read and parse /proc/meminfo in a secondary thread. Once memory usage is critical all the secondary processes are notified using an EventFD. Using EventFD for this monitor too, not only is more efficient than using a pipe or sending an IPC message, but also allows us to keep almost the same implementation in the secondary processes that either monitor the cgroups EventFD or the UI process one.

Other improvements and bug fixes

Like in all other major releases there are a lot of other improvements, features and bug fixes. The most relevant ones in WebKitGTK+ 2.14 are:

  • The HTTP disk cache implements speculative revalidation of resources.
  • The media backend now supports video orientation.
  • Several bugs have been fixed in the media backend to prevent deadlocks when playing HLS videos.
  • The amount of file descriptors that are kept open has been drastically reduced.
  • Fix the poor performance with the modesetting intel driver and DRI3 enabled.

15 de septiembre de 2016

Acceso VPN a la red de CICA usando Fedora

Esta es una entrada de servicio público. Si eres usuario de la VPN de CICA y usas un linux moderno como Fedora (23 en este caso) puede serte de utilidad esta entrada.

CICA usa OpenVPN. Lo ideal sería poder configurar el acceso con NetworkManager, que dispone de la funcionalidad de openvpn, pero en ninguna de mis pruebas he conseguido una configuración operativa, creo que porque NM espera que el certificado de usuario sea emitido por la misma CA que la configuración de la red en cuestión, que no es el caso. El caso es que tras varias pruebas he conseguido conectar desde la CLI contando con la ayuda del CAU de Sistemas de CICA.

Básicamente necesitas:

client
dev tun
proto udp
remote vpn.cica.es 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /home/usuario/cica-vpn/TERENASSL2_PATH.pem
pkcs12 /home/usuario/.X509/FNMTClase2CA.p12
auth-user-pass
verify-x509-name vpn.cica.es name
cipher AES-128-CBC
comp-lzo
verb 3

Para poder conectar basta lanzar algo parecido a:

sudo /usr/sbin/openvpn --config /home/usuario/cica-vpn/cica-config.ovpn

Entonces openvpn te solicitará tres datos:

  • usuario de la red CICA
  • contraseña asociada
  • contraseña de acceso a tu certificado X509 emitido por FNMT.

Por dejarlo completamente claro

  • /home/usuario/cica-vpn/TERENASSL2_PATH.pem es el certificado que descargas de http://www.rediris.es/scs/cacrt/TERENASSL_PATH.pem
  • /home/usuario/.X509/FNMTClase2CA.p12 es tu certificado de la FNMT-RCM exportado probablemente desde tu navegador y protegido por una contraseña.

Que ojalá os sirva.

Publicada la vieja web de TLDP-ES/LuCAS en Github

Desde hace unos buenos años CICA ha tenido la gentileza de alojar el servidor principal del viejo TLDP-ES que los linuxeros más fogueados recordarán como LuCAS.hispalinux.es. Fue imperativo migrar el servicio desde el momento en el que mantenimiento de los sistemas de Hispalinux empezó a colapsar y tuve suerte de que CICA nos ofreciera una VM pequeñita donde alojar lo que se pudo salvar de la web. Claro que ya no era una web importante, pero me dolía mucho dejar que desapareciera el testigo de toda una época y el fruto del trabajo de muchas personas durante muchísimas horas. Tampoco me gusta ir dejando enlaces rotos en la web si puedo evitarlo.

En este mismo proceso de «arqueología» hace ya tiempo que pensé en publicar otro repositorio que usábamos para el mantenimiento de TLDP-ES, el control de versiones con el que queríamos facilitar el trabajo de los voluntarios. Así creé este repo en Github: https://github.com/olea/LuCAS-cvs. Ahora, de la misma manera me he propuesto publicar igualmente el contenido de la web que ahora está disponible también en Github: https://github.com/olea/LuCAS-web.

Prácticamente no es más que un pequeño ejercicio de nostalgia, pero en fin, ahí queda.

Gracias a todos los que hicisteis posible ese gran servicio que fue TLDP-ES/LuCAS. Definitivamente creo que fue algo grande.

05 de septiembre de 2016

Probando el Subsistema Windows 10 para Linux (Beta)

El 30 de marzo saltaba la noticia: las llamadas al sistema de Linux  se podrán ejecutar en Windows 10 de forma “nativa” (se podrán traducir en tiempo real a llamadas al sistema de Windows, algo así como un WINE a la inversa):

Intenté probarlo en su día, pero no encontraba tiempo. Tampoco creo que estuviera disponible para todos los usuarios… Hoy he recordado la noticia y le he dedicado un rato porque necesito ejecutar algunas funcionalidades de Linux en una máquina Windows (y la opción de Cygwin me parece demasiado “heavy”… y problemática, la he sufrido en alguno de mis cursos, donde he recibido numerosas peticiones de auxilio 😉

Para probar el subsistema Windows para Linux (Windows Subsystem for Linux o WSL) hay que tener la actualización Windows 10 Anniversary Update (se publicó en Agosto de este año). La forma más sencilla es a través de este enlace oficial a la web de Microsoft. Tras la instalación/upgrade, hay que activar el modo programador entrando en Configuración / Para programadores

bash_win_0

A continuación, entramos en Panel de Control / Programas / Activar o desactivar las características de Windows . Activamos el Subsistema de Windows para Linux (beta) y reiniciamos las veces que haga falta 😛

subsistema_Linux

Ahora viene lo bueno. Ejecutamos bash desde el menú de inicio (tecleamos bash y pulsamos intro) y al ser la primera vez se lanzará la instalación:

bash_win_1

Le costará un rato descargar WSL (al final está descargando una especie de versión de Ubuntu Server) y activarlo. Cuando lo haga, nos pedirá crear un usuario (que por defecto estará en la lista de sudoers)bash2

Le asignamos un pass al nuevo user y tachán, ya estamos en Bash 🙂

bash3

Se hace raro poder ejecutar ls, id, pwd, cat, vi ! , apt (sí apt-get!) en Windows sin recibir mensajes de error…bash4

Realmente estamos en Bash dentro de un Ubuntu 14.04 ejecutándose sobre Windows 10. Buf… si me lo llegan a decir hace un tiempo hubiera puesto cara de incrédulo.bash5

Los archivos están donde deben (en un sistema que siga el LSB) y tienen el contenido esperado.

bash6

El sistema de archivos del anfitrión Windows está montado en /mnt . Tenemos los repos apt de Ubuntu a nuestra disposición para instalar las aplicaciones que necesitemos.

bash8

Otro puntazo a favor es que tenemos un intérprete python y un intéprete perl instalados de serie (los mismos que instala Ubuntu 14.04, claro)

bash9

También he visto que hay un servicio ssh lanzado en el puerto 22, pero por lo que he probado NO es openssh (se puede ver el fingerprint del servidor mediante un simple telnet – sí, telnet, para ver el banner del server – al puerto 22), sino un servidor SSH de Windows (yo diría que en alfa, porque aún no he conseguido autenticarme y creedme que he probado de todo). ¿Tal vez sea una implementación en desarrollo del port openssh de Microsoft ?

bash7

Leyendo algunos foros comentaban que openssh se puede configurar para que escuche en un puerto distinto al 22 (el 60022, por ejemplo), abrir una regla en el firewall de Windows para ese nuevo puerto y listo. Si no lo tenemos instalado por defecto (en mi caso sí lo estaba) siempre podremos instalarlo con sudo apt-get update && sudo apt-get install openssh 🙂

A continuación, modificamos /etc/ssh/sshd_config y lo dejamos así:

Port 60022
ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation no
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Si openssh ya estaba instalado, antes de reiniciar el server openssh lo reconfiguramos (si no lo hacemos, arrancará, pero no conseguiremos conectar porque no habrá generado los ficheros necesarios):

$ sudo dpkg-reconfigure openssh-server

Ahora sí, reiniciamos el server openssh:

sudo service ssh restart

Y conectamos desde localhost para probar:

bash_win_10

¡Funciona! 🙂

UPDATE (5/09/2016): si en algún momento la liamos parda con la configuración del WSL, siempre podremos desinstalar y volver a instalar con dos sencillos comandos:

C:\> lxrun.exe /uninstall /full
C:\> lxrun.exe /install

UPDATE (6/09/2016): es posible iniciar el servidor openssh de WSL al arrancar el equipo. Para ello, basta con parar el Server SSH de Microsoft (el que viene por defecto) y lanzar OpenSSH con la configuración indicada, salvo que ahora podremos lanzarlo en su puerto natural, el 22. Además, si queremos lanzar el servidor cada vez que iniciemos el equipo, podremos crear un script de arranque.

02 de septiembre de 2016

Cerber edo kode kaltegarriaren negozioa

malwaretech

Ransomware delako kode kaltegarri motakoa da Cerber. Horrelako beste hainbat izen ezagunak etortzen zaizkigu burura: Locky, CryptoWall, Crypt0L0cker, TeslaCrypt… Dakigun bezala, malware mota honek gure disko gogorraren edukia zifratu egingo du eta berreskuratzea ezinezkoa izango da ez badugu erreskate bat ordaintzen. Zifratzeko gako publikoko kriptografia + kriptografia simetrikoa erabiltzen omen dute (RSA+AES). Beste mezu batean hau nola egiten duten azalduko dut, baina Bromium enpresak argitaratutako txosten honetan informazio lagungarria aurkituko duzu gehiago sakondu nahi izanez gero.

Orain interesatzen zaidana da kontu azkar batzuk egitea hemen. Eta soilik ransomware bakar baten inguruan: Cerber. @malwaretechblog ikertzailearen arabera, egunero Cerber-ek 6000 biktima berri kutsatzen ditu. Ez da ausaz asmatutako zenbaki bat, baizik eta bere tracker-sareak egunero antzematen dituena.

Orain kalkulu azkar bat. Demagun 6000 infekzio horietatik soilik %3-ak ordaintzen duela erreskatea. Zenbateko erreskatea da hori? Nola ordaintzen da? Ba 500$ gutxi gorabehera… eta BitCoin-etan ordaintzen da. Lehenengo Tor sarea erabiltzeko nabigatzailea instalatu beharko duzu, gero BitCoin-ak erosi, ordaindu eta zifratzeko erabili zen gakoa berreskuratzearen zain pazientziarekin itxaron. Hainbat gauza daude hemen zehazteko… adibidez, zergatik esan dut gutxi gorabehera? Honegatik:

enc_cerber_website-1

Azkar ordainduz gero (7 egun baino gutxiagotan), 1.24 bitcoin (521$ gutxi gora behera) izango dira. Erreskatea beranduago ordainduz gero, bikoiztu egingo da isuna: 2.48 BTC = 1043$

Ordaindu ezean, nola berreskuratu? Ez dago modurik. Hasierako bertsioa gaizki programatuta bazegoen ere (beraz, ordaindu gabe bazegoen berreskuratzeko modu bat), gaur egun asko “hobetu” dute Cerber-en kodea eta ez dago ordaindu gabe berreskuratzeko  modurik. Hemen babes-kopien politikaren beharraz arituko nintzen, baina ez da une egokia 😉 Ordaindu edo ez, hori bakoitzaren eskuetan uzten dut.

Baina gatozen harira.  6.000 kutsadura * 0.03 ordainketa * 500$ = 90000$ , EGUNERO.

Nola banatzen da Cerber bezalako kode kaltegarria? Zein dago horren atzetik? Nola kutsatzen gara? Ezin da ezer egin honen aurka? Aztertzeko hainbat galdera interesgarri…

01 de septiembre de 2016

Migration to https

I’ve postponed this for eons but it has been the time to migrate the olea.org website to https

Concerned about the privacy, in 2009 the EFF launched the campaign Encrypt the Web aiming all the Web users to migrate to encrypted communications, concerning sysadmins, software programmers and users. Now I did the needed step for my main web server and since there are lots of better documentation on this I’ll just comment briefly some practical details.

First, the tools that helped me with the process:

You should try both if you didn’t yet. And thanks a lot to the Mozilla Foundation for creating them.

Second, the migration issues, because the auditing results are pretty bad: 🙈

results of scan summary

  • I’m not sure if my server changes would have some collateral effects in the other hosted webs. I’m not the best sysadmin. Let’s see.
  • One of the biggest problem of this migration is how old this server is: a CentOS 5 server which should have been migrated years ago. Still in my ToDo. I think the most negative points of the auditing are consequence of this.
  • The other one is the CA of my X509 certificates. For some years I’ve been a promoter of CACert and I’m using this certificates for other services in my server but at this moment the CACert hasn’t been able to get accepted their root certificate with the WebTrust Principles and Criteria for Certification Authorities and the internal crisis of the organization breaks all my hopes for a community driven certification authority X509 compatible. In practice this mean my current X509 certificate is not trustable for everybody who has not added the CACert root certificate by hand. Not a fun thing.

If you are reading these lines then is very probable you know about Letscencrypt which I really love too. This time I have two concerns with Letscrypt: the first this server is too old that should be migrated soon, the second is Letsencrypt is not designed to verify identities. The alternative seems to be to find a free (as beer) or paid CA providing hte verification service.

Well, I know this entry is not very useful for the most of the users, but I’m trying now to write more regularly and to document my routine technical progresses. And as the song says, «que ojalá os sirva».

PD: Finally I deactivated the apache redirection from http to https because using a CACert certificate broke my RPM repository and complicated the access to my web for some users. This is sad.

30 de agosto de 2016

Guía de Linux para el usuario en epub

Hoy mi amigo Eduardo me ha pedido bibliografía elemental en formato digitla para empezar en serio con Linux. Mi primera idea ha sido ir a revisar o que teníamos publicado en TLDP-ES/LuCAS y lo primero que he pensado es en hacerle llegar una copia de la vieja G.L.U.P. - Guía de Linux Para el Usuario que debería atender la mayor parte de las dudas básicas del recién llegado. Como la mejor forma de leer un documento, sea en tableta, teléfono o en un lector de ebook es ePub he pensado cómo apañarlo. He aprovechado para refrescar sobre las herramientas disponibles a partir de los formatos que publicamos en su momento que son básicamente PDF y HTML. Aunque El odioso PDF es manejable por estos dispositivos, no es tan acomodable a la pantalla como puedan serlo HTML y ePub.

Hoy mi amigo Eduardo me ha pedido bibliografía elemental para empezar en serio con Linux y he decidido hacerle llegar una copia manejable de la vieja G.L.U.P. - Guía de Linux Para el Usuario en formato ePub. Así he descargado una copia en HTML de la misma, y he cambiado el archivado tar.gz por uno zip y he creado el ebook con el conversor de Calibre:

ebook-convert glup_0.6-1.1-html-1.1.zip glup_0.6-1.1-html-1.1.epub

y listo: pantallazo de GLUP en ebook-viewer.

Después he aprovechado para hacer un poquito de control de calidad con otra utilidad de Calibre: ebook-edit.

Podéis descargar esta versión del libro desde este enlace glup_0.6-1.1-html-1.1.epub. Y como dice la canción: «que ojalá os sirva».

19 de agosto de 2016

Cambios en mi web

Después de postergarlo por mucho tiempo y tras haber adquirido algo de experiencia al crear con Jekyll las web de HackLab Almería y Club de Cacharreo me he animado a descartar al viejo Lameblog y ponerme manos a la obra. Si se nota alguna inconsistencia en mi web tened la seguridad de que es culpa mía. Y no me refiero al diseño, que es algo que ya doy por perdido.

Algo fantástico de Jekyll es que puedes migrar un blog al menos a través del fichero RSS del antiguo. Y por ahora parece funcionar divinamente.

Una inconsistencia a la que tristemente renuncio a corregir son las URI/permalinks originales, que además son las que usa Disqus para recuperar los comentarios. Como Lameblog se hacía algo de lío al generar las URIs con la localización ES pues se ha quedado todo un poco guarro y ahora me parece un lío arreglarlo. Por otro lado voy a procurar a no eliminar contenido de las URIs antiguas por los (pocos) enlaces externos que pudiera haber. Perderé los comentarios, sí, en las versiones nuevas de las entradas pero realmente no son demasiados y deberían seguir accesibles en las antiguas.

PD: Finalmente me he puesto a migrar los comentarios del blog alojados en Disqus. Afortunadamente parece que el proceso está bastante bien implementado Migration console y en mi caso, ya que no me he atrevido a especificar unas reglas que indiquen la transformación de las URIs antiguas a las modernas he seguido el procedimiento manual en el que descargas un fichero CSV con las entradas (URIs) que Disqus ha registrado en la columna A para añadir en la B la nueva. En mi caso han sido más de 500 pero, OjO, 500 URIs no significan 500 comentarios ni por asomo. De hecho una de las cosas que he verificado es el poco interés que despierta mi blog por los pocos comentarios o recomendaciones recibidos :_( En fin.

El caso es que he querido verificar cada una de las URIs si eran dignas de ser migradas y sólo se me ha ocurrido un procedimiento manual que básicamente he gestionado con esta línea de bash:

 for a in `cat olea-2016-08-21T20-27-31.368505-links.csv ` ; do chrome "$a" && read -p  "pulsa Enter" ;done

Donde olea-2016-08-21T20-27-31.368505-links.csv es el fichero CSV descargado. El porqué del read es para evitar que se abran 500 solapas en el navegador.

En la práctica han sido muy pocas las URIs que he indicado migrar (20 o 30 máximo) porque no había más comentarios ni recomendaciones. A continuación, siguiendo las instrucciones de Disqus he subido el fichero CSV revisado y he esperado a que fuera procesado. Y listo.

En realidad me ha costado un poquito más porque ha cambiado el código que Disqus proporciona para integración y al final he encontrado este precioso código jekyll de Joshua Cox que ha terminado por resolver toda esta parte.

Ale, a disfrutarlo con salud.

PS: Igual hasta hacemos otro tallercín en el HackLab Almería para compartir la experiencia con los compis.

PD: He implementado el servicio 404 de Archive.org en mi blog. Basta con incluir estas líneas en tu página 404:

<div id="wb404"/>
<script src="https://archive.org/web/wb404.js"> </script>

y añadir la configuración correspondiente en, mi caso, Apache dentro de la correspondiente sección Virtualhost:

ErrorDocument 404 /404/

Y funcionando es una gozada: http://www.olea.org/pipermail/gentecilla/.

Adoro http://Archive.org.

(Editado el 20161124)

11 de agosto de 2016

Going to GUADEC 2016

I am at the airport getting ready to board beginning my trip to Karlsruhe for GUADEC 2016. I’ll be there with my colleague Michael Catanzaro.Please talk to us if you are interested in browsers or Igalia.

22 de julio de 2016

Padding con Vim

Tenemos la siguiente imagen ASCII:

Captura de pantalla 2016-07-22 a las 20.06.50

Si nos fijamos, hay líneas de distintas longitudes (las más largas son de 80 caracteres). Queremos hacer padding (rellenar) con el carácter ‘#’ para que todas las líneas sean de la misma longitud (80). Podemos hacerlo con un pequeño script en cualquier lenguaje de programación, pero la idea es: ¿se puede hacer con una única línea que use inteligentemente expresiones regulares y funciones en Vim? Sí 🙂

:%s/\v^.*$/\= submatch(0) . repeat("#", 80 - len(submatch(0)))

\v : magia, literal (ver la ayuda). Todos los caracteres que aparezcan tras este patrón se tomarán como caracteres especiales (no es necesario escaparlos). Efectivamente, olvídate de poner \(.*\) para hacer agrupaciones, basta con \v(.*)

^.*$ : desde el comienzo hasta el final de línea

\=  : comienzo de función

submatch(0) : primer match de la expresión regular (es la línea completa)

.  : concatenar con lo siguiente

repeat(“#”, 80 – len(submatch(0)))  : repetir el carácter #  x veces, donde x = 80 – longitud de línea

Éste es el resultado:

Captura de pantalla 2016-07-22 a las 20.19.27

16 de julio de 2016

14 de julio de 2016

Advanced Natural Language Processing Tools for Bot Makers – LUIS, Wit.ai, Api.ai

12 de julio de 2016

Novedades en la equivalencia internacional de títulos superiores españoles

Para empezar reconoceré que no tengo bien estudiada la regulación de las titulaciones universitarias en España. El caso es que he recibido el aviso de que se han publicado por fin las equivalencias internacionales de los títulos españoles. Por algún motivo tradicional, la estructura de las titulaciones superiores en España ha tenido poco que ver con las del resto del mundo. Se supone que ya todos sabemos cuáles han sido las transformaciones obligadas por «el plan Bolonia», que entre otras cosas pretende la movilidad de estudiantes y trabajadores y la interoperabilidad automática de los títulos superiores entre los paises comunitarios (creo que estrictamente va más allá de la UE pero hoy no es mi objetivo ser exhaustivo). Al parecer esa transformación de los títulos no era suficiente para saber cómo equivalen en el extranjero nuestros títulos. Y peor aún, cuáles son las equivalencias de los títulos superiores pre-Bolonia, que con frecuencia siguen siendo un lío al cambiar de universidad sin salir del país. La novedad es que parece que esa información ya ha quedado resuelta.

Siendo muy esquemático: el sistema de interoperabilidad de las titulaciones superiores en España se establece en el Marco Español de Cualificaciones para la Educación Superior (MECES), que, si yo no lo entiendo mal, sirve para establecer las equivalencias con el Marco Europeo de Cualificaciones para el Aprendizaje Permanente (EQF en inglés), que es la piedra de Rosetta para todo este sistema.

Pues bien, desde el 1 de junio de 2016 ya están publicadas oficialmente las equivalencias, como indican en el original: «correspondence between the Spanish Qualifications Framework for Higher Education and the European Qualifications Framework».

Cuadro MECES / EQF de equivalencias de títulos superiores españoles

¿Cuáles son las consecuencias? Probablemente algunas más, pero entiendo que al menos a partir de ahora, por ejemplo, puedes matricularte en cualquier universidad que implemente el EQF sin tener que pasar por el desesperante proceso de convalidación de tus títulos.

Dejo esta entrada a modo de recordatorio personal y con la esperanza de que sea de utilidad. Si alguien detecta algún error que por favor lo indique en los comentarios.

Referencias:

11 de mayo de 2016

Algunos recursos de investigación sobre calidad del software aplicada a proyectos de software libre

Con la excusa de responder a una solicitud de información sobre este tema he preparado un repaso, informal e incompleto, OjO, de recursos relacionados que tenía en mente. Y ya puestos lo cuelgo en el blog. Aquí está.

04 de mayo de 2016

Plataformas MOOC comparadas (III)

Progreso del alumno

En MiríadaX no han dejado de lado esta característica fundamental, pero creo que puede mejorarse significativamente. Para ello, compararemos la zona de progreso de edX con la de MiríadaX.

En edX, el alumno puede ver de un sólo vistazo, sin necesidad de hacer scroll cuántas tareas ha completado hasta el momento, cuántas le quedan por completar, cuál es la nota de corte para dar por aprobado el curso y el porcentaje actual de completamiento del curso:

progreso_edx

De forma sucinta, se indica el resultado de cada prueba y la fecha en la que se realizó.

Para ver el progreso de un alumno en MiríadaX, debemos pulsar en “Notas”. ¿Notas? Inicialmente entendí que era una zona para anotaciones relacionadas con el curso. ¿Por qué no “Progreso”? O de forma alternativa, “Calificaciones”. En fin, esto puede ser un detalle sin importancia. Lo importante es otra cosa:

Captura de pantalla 2016-04-26 a las 22.52.18

Lo primero es la falta de claridad. Ya hablamos de este “pecado” en otras entradas de esta serie. Pero en este caso se hace otra vez evidente. ¿Cuántos puntos (porcentaje) llevo en total? ¿Cuántos debo alcanzar para “aprobar” (nota de corte)? ¿Cuál es la calificación (o nota, siguiendo con la nomenclatura de MiríadaX) del módulo 1? Este curso tiene 10 módulos… Para ver el resultado de cada módulo debo desplazarme hasta el infinito en vertical…

Más aún, en la última entrega obligatoria del módulo 3, vemos un “No aprobado”.

miriadax_no_aprobado

Sin embargo, estoy totalmente seguro de que entregué la tarea y la tengo bien calificada por mis compañeros/as del curso. ¿Qué ocurre? No es evidente, pero el problema es que yo aún no he evaluado el trabajo de 3 de mis colegas. El estado no debería ser “No aprobada”, sino “En progreso”. De hecho, tengo hasta el 30 de mayo para hacer esas evaluaciones. Por cierto, no puedo acceder directamente a esa tarea para ver la razón de ese “No aprobada”. De hecho, si pulso en “Detalle”, se abre una ventana modal:

Captura de pantalla 2016-04-26 a las 23.00.20

Pero no hay enlaces para ver el enunciado de la tarea o las tareas de mis compañeros que me quedan por evaluar.

Tengo que pulsar en “Inicio”, desplazarme al “Módulo 3”, pulsar en “Acceder”, buscar la entrega obligatoria, pulsar en ella y ahí, por fin, ver la causa de mis males:

corregir_edx

Evalúo los dos trabajos que me quedan y ¡premio! ¿Era intuitivo? Yo creo que no.

edx_aprobado

03 de mayo de 2016

Plataformas MOOC comparadas (II)

Enunciado de los ejercicios 

Lo primero que podemos decir es que el interfaz gráfico, diseño y presentación de la sección de presentación de los ejercicios es muy mejorable. Me limitaré a mostrar una captura de pantalla:

Captura de pantalla 2016-04-25 a las 22.55.36

Desde luego, es de todo menos atractiva. Enormes cantidades de texto, sin gráficos ni separaciones evidentes. Ojo, no creo que sea un error del creador (creadores) del curso. Creo que es un error de diseño de la plataforma. Definitivamente no está preparada para impartir cursos MOOC. Veamos algo similar para el caso de Coursera:

maxresdefault

En la parte superior hay 3 cajas que dividen claramente las fases de un Ejercicio evaluado entre pares. En la parte central hay espacio para el enunciado del ejercicio y para aceptar el código de conducta. En la parte inferior hay una caja de texto para editar la respuesta o indicar mediante un enlace dónde encontrar la solución detallada. También permite guardar borradores (Save Draft), aspecto éste que brilla por su ausencia en MiriadaX.

En Coursera, también se especifica mediante colores (gris, verde, rojo) en que estado nos encontramos dentro de cada fase:

coursera_p2p_colores

En MiriadaX no existe este tipo de indicadores. Tampoco podemos auto-evaluarnos:

Captura de pantalla 2016-04-25 a las 23.23.16

Rúbricas (o la ausencia de ellas)

En MiriadaX, el interfaz para evaluar el trabajo de un compañero/a no dispone de una rúbrica de ayuda. No hay criterios, se limita a mostrar una caja de texto y una única puntuación, de 0 a 100:

sin_rubrica_miriadax

Esto es tremendamente incómodo. Al final, lo que hacen los alumnos es limitarse a escribir “Muy bien” o “Sigue así”. Dos o tres palabras y una nota de 100. Algo rápido y sin críticas constructivas de ningún tipo. En Coursera, sin embargo, el interfaz es más rico, se dispone de rúbricas de evaluación y cada criterio puede ser evaluado de forma independiente. Además, existe también una caja de texto donde, en algún curso, se pide cumplimentar al menos 20 palabras:

rubric_webform

Además, el alumno siempre tiene disponibles los criterios de evaluación de la rúbrica cuando está respondiendo a las preguntas/trabajos, lo que facilita la labor de respuesta:

coursera-fail-2-1

02 de mayo de 2016

Plataformas MOOC comparadas (I)

Introducción

A lo largo de esta semana iré publicando mis impresiones sobre las plataformas MOOC que he ido probando como alumno. Compararé aspectos relacionados con la docencia: herramientas para la presentación de contenidos, para el seguimiento del alumno, para la evaluación (autoevaluación, co-evaluación, hetero-evaluación), usabilidad, gestión de certificados, interacción entre usuarios (foros, chats) y también aspectos relacionados con el propio software que sustenta las plataformas (cómo están desarrolladas internamente, qué subsistemas usan, política de licencias).

Las plataformas que traeré a colación son edX, Coursera y MiríadaX,  porque son en éstas donde he trabajado como alumno, y edX y Moodle como plataformas en las que puedo decir algo sobre los aspectos de software, gracias a su licencia abierta.

Antes de nada, quería presentarme, haciendo especial hincapié en los aspectos relacionados con la enseñanza online que he trabajado, bien como alumno o bien como profesor.

También quiero dejar claro que todas las plataformas MOOC que tienen como objetivo expandir el conocimiento y lo hacen de forma gratuita y con materiales de calidad me merecen el mayor de los respetos. Me quito el sombrero ante el trabajo que han realizado (y siguen realizando) edX, Coursera, MiríadaX, Udacity, FutureLearn, P2P University y demás entidades. Lo que viene a continuación son una serie de posts sobre mi experiencia como usuario, como alumno o como desarrollador en todas estas plataformas, indicando los puntos buenos y malos y sugiriendo mejoras mediante análisis comparados.

Empezaremos comparando el sistema de MiríadaX con los de edX y Coursera, dado que son las plataformas sobre la que he estado trabajando más recientemente. MiríadaX usa internamente el CMS Liferay. No es una plataforma preparada ad-hoc para impartir MOOCs  (como podría ser Open-edX o la plataforma de Coursera) y eso se nota en multitud de detalles.  Veamos algunos de ellos, aspectos que no se han cuidado lo suficiente, no se han tenido en cuenta o son mejorables.

Variables sin valores asignados

Si nos fijamos en el mensaje de entrega de una tarea, veremos lo siguiente:entrega1

“La asignación de tareas para evaluar se realizará a las {4} del día {5}, fecha de la zona horaria {6}, que es la establecida en tu perfil.” No es algo que ocurra una vez en una pantalla, ni siquiera algo que ocurrió una vez o dos. Ocurre siempre, desde hace meses.

Incoherencia en la forma de dirigirse al alumno

¿Cómo nos dirigimos al alumno? ¿Debemos usar el tratamiento de usted o el de tú? Entiendo el trato de usted y me parece correcto. Pero en mi caso, me resulta muy artificial. Agradecería una opción que permitiera elegir entre una forma u otra de dirigirse al alumno. No obstante, eso no sería un error: basta con elegir el tratamiento. Sin embargo, lo que sí es un error es “bailar” en el uso de usted y tú.  Si nos fijamos en la ventana anterior, veremos un tratamiento de tú: “Próximamente recibirás…”, “Recuerda realizar…”. Sin embargo, en otras pantallas, vemos el tratamiento de usted, como en la siguiente: “Piensen bien su evaluación…”, “El objetivo de este curso es sacar el máximo provecho al trabajo que están realizando…”

tu_usted

Imposibilidad de reintentar la entrega antes de que finalice el plazo

Una de las aportaciones interesantes de un MOOC es que el alumno puede trabajar por su cuenta, a su ritmo, e ir mejorando sus conocimientos mediante iteraciones: construye una solución y la guarda como posible envío. Esta primera solución seguramente no sea óptima. El alumno puede darse cuenta estudiando algo más, o comentando los problemas encontrados con sus compañeros en el foro. Esta retroalimentación le permitirá mejorar su solución y grabarla como una entrega mejorada. En cualquier caso, es muy conveniente que el sistema que da soporte al MOOC permita la grabación de soluciones. No digo que mantenga un histórico, bastaría con que nos deje guardar un único trabajo, pero que éste se pueda subir tantas veces como se quiera, siempre dentro del plazo de entrega. Cada vez que el alumno envíe, la nueva entrega sustituirá a la anterior (lo ideal, como digo, sería un histórico, pero esta solución parcial de “nos quedamos con la última”, valdría). Lo que no es de recibo es limitar a un único envío, tal y como hace MiríadaX. Avisan por activa y por pasiva que el envío, único, es final. No importa que aún queden días para el “deadline”. No podrás cambiar ni reenviar mejoras a tu trabajo, está prohibido mejorar 🙁 Este es un aspecto que ninguna plataforma MOOC (edX, Coursera, Udacity, FutureLearn, Google CourseBuilder) ha descuidado. Es un error de libro, sin embargo, ahí está.

entrega3

No entiendo esta restricción. Es muy probable que una vez entregada la tarea, y el alumno esté más relajado, se le ocurran mejoras a la entrega realizada. O simplemente, quiere enviar una versión preliminar – digna, pero no excelente – por si acaso no le da tiempo a completar la versión final, de mayor calidad. Tal cuál está planteada la entrega, esto no puede hacerse. Una entrega evaluada entre pares no es razón para este comportamiento. Puede alegarse que se hace para que los alumnos dispongan rápidamente de ejercicios para evaluar, pero no hay razón para hacerlo así. Se puede dejar un período de evaluación de una semana a partir del momento de la entrega. Por ejemplo,en edX y en Coursera, el alumno puede enviar tantas versiones de su tarea mientras no haya terminado el plazo de entrega.

Por otro lado, se recomienda adjuntar una versión del archivo html con la solución, pero si ya está online… no le veo mucho sentido. Entiendo que pueda ser una medida de seguridad (por si la versión online cae), pero implica nuevos problemas: si la versión online y el archivo (versión offline) varían, ¿cuál evaluar? si la versión offline no incluye referencias a gráficos o vídeos porque están enlazados, ¿qué hacer? y si las incluyen (¿un vídeo?), ¿para qué ofrecer dos versiones?.

13 de abril de 2016

Chromium Browser on xdg-app

Last week I had the chance to attend for 3 days the GNOME Software Hackfest, organized by Richard Hughes and hosted at the brand new Red Hat’s London office.

And besides meeting new people and some old friends (which I admit to be one of my favourite aspects about attending these kind of events), and discovering what it’s now my new favourite place for fast-food near London bridge, I happened to learn quite a few new things while working on my particular personal quest: getting Chromium browser to run as an xdg-app.

While this might not seem to be an immediate need for Endless right now (we currently ship a Chromium-based browser as part of our OSTree based system), this was definitely something worth exploring as we are now implementing the next version of our App Center (which will be based on GNOME Software and xdg-app). Chromium updates very frequently with fixes and new features, and so being able to update it separately and more quickly than the OS is very valuable.

Endless OS App Center
Screenshot of Endless OS’s current App Center

So, while Joaquim and Rob were working on the GNOME Software related bits and discussing aspects related to Continuous Integration with the rest of the crowd, I spent some time learning about xdg-app and trying to get Chromium to build that way which, unsurprisingly, was not an easy task.

Fortunately, the base documentation about xdg-app together with Alex Larsson’s blog post series about this topic (which I wholeheartedly recommend reading) and some experimentation from my side was enough to get started with the whole thing, and I was quickly on my way to fixing build issues, adding missing deps and the like.

Note that my goal at this time was not to get a fully featured Chromium browser running, but to get something running based on the version that we use use in Endless (Chromium 48.0.2564.82), with a couple of things disabled for now (e.g. chromium’s own sandbox, udev integration…) and putting, of course, some holes in the xdg-app configuration so that Chromium can access the system’s parts that are needed for it to function (e.g. network, X11, shared memory, pulseaudio…).

Of course, the long term goal is to close as many of those holes as possible using Portals instead, as well as not giving up on Chromium’s own sandbox right away (some work will be needed here, since `setuid` binaries are a no-go in xdg-app’s world), but for the time being I’m pretty satisfied (and kind of surprised, even) that I managed to get the whole beast built and running after 4 days of work since I started :-).

But, as Alberto usually says… “screencast or it didn’t happen!”, so I recorded a video yesterday to properly share my excitement with the world. Here you have it:


[VIDEO: Chromium Browser running as an xdg-app]

As mentioned above, this is work-in-progress stuff, so please hold your horses and manage your expectations wisely. It’s not quite there yet in terms of what I’d like to see, but definitely a step forward in the right direction, and something I hope will be useful not only for us, but for the entire Linux community as a whole. Should you were curious about the current status of the whole thing, feel free to check the relevant files at its git repository here.

Last, I would like to finish this blog post saying thanks specially to Richard Hughes for organizing this event, as well as the GNOME Foundation and Red Hat for their support in the development of GNOME Software and xdg-app. Finally, I’d also like to thank my employer Endless for supporting me to attend this hackfest. It’s been a terrific week indeed… thank you all!

Credit to Georges Stavracas

Credit to Georges Stavracas

04 de abril de 2016

Mala semana para la seguridad de las extensiones en Firefox y Chrome

Investigadores de seguridad presentaron la semana pasada, en la Black Hat Asia 2016, bajo la ponencia “Automated Detection of Firefox Extension-Reuse Vulnerabilities” una extensión que reutiliza código de otras ya instaladas con fines maliciosos. Es una técnica nueva (extension-reuse) interesante.

En febrero presentaron un artículo sobre la misma vulnerabilidad (CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabilities) en el simposium “The Network and Distributed System Security Symposium 2016” organizado por la Internet Society.

Y siguiendo con los ataques de seguridad a las extensiones, hoy se publica una noticia sobre una empresa que en febrero compró una extensión bastante popular (Better History) para inyectarle código malicioso que hace que los navegadores de sus usuarios sean redirigidos, a través de un enlace lnkr.us, a páginas con banners -al parecer a la página que más pague a la empresa- cada vez que pinchan en un enlace (realmente el 50% de la veces y no es una redirección simple, sino que la página original a la que el usuario se dirigía también se abre). El comportamiento no es maligno únicamente por esto, sino porque la empresa de esta extensión está recogiendo datos privados sobre las URL que los usuarios visitan. Para más inri, el código fuente de Better History en GitHub no refleja los añadidos maliciosos que la compañía ha introducido.

Google ha eliminado la extensión de la Chrome Store, pero los usuarios han advertido de que este comportamiento se repite en otras extensiones populares como Chrome Currency Converter, Web Timer, User-Agent Switcher, Better History, 4chan Plus, and Hide My Adblocker.

Google ha eliminado también User-Agent Switcher, pero el resto sigue online.

25 de marzo de 2016

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.

22 de marzo de 2016

WebKitGTK+ 2.12

We did it again, the Igalia WebKit team is pleased to announce a new stable release of WebKitGTK+, with a bunch of bugs fixed, some new API bits and many other improvements. I’m going to talk here about some of the most important changes, but as usual you have more information in the NEWS file.

FTL

FTL JIT is a JavaScriptCore optimizing compiler that was developed using LLVM to do low-level optimizations. It’s been used by the Mac port since 2014 but we hadn’t been able to use it because it required some patches for LLVM to work on x86-64 that were not included in any official LLVM release, and there were also some crashes that only happened in Linux. At the beginning of this release cycle we already had LLVM 3.7 with all the required patches and the crashes had been fixed as well, so we finally enabled FTL for the GTK+ port. But in the middle of the release cycle Apple surprised us announcing that they had the new FTL B3 backend ready. B3 replaces LLVM and it’s entirely developed inside WebKit, so it doesn’t require any external dependency. JavaScriptCore developers quickly managed to make B3 work on Linux based ports and we decided to switch to B3 as soon as possible to avoid making a new release with LLVM to remove it in the next one. I’m not going to enter into the technical details of FTL and B3, because they are very well documented and it’s probably too boring for most of the people, the key point is that it improves the overall JavaScript performance in terms of speed.

Persistent GLib main loop sources

Another performance improvement introduced in WebKitGTK+ 2.12 has to do with main loop sources. WebKitGTK+ makes an extensive use the GLib main loop, it has its own RunLoop abstraction on top of GLib main loop that is used by all secondary processes and most of the secondary threads as well, scheduling main loop sources to send tasks between threads. JavaScript timers, animations, multimedia, the garbage collector, and many other features are based on scheduling main loop sources. In most of the cases we are actually scheduling the same callback all the time, but creating and destroying the GSource each time. We realized that creating and destroying main loop sources caused an overhead with an important impact in the performance. In WebKitGTK+ 2.12 all main loop sources were replaced by persistent sources, which are normal GSources that are never destroyed (unless they are not going to be scheduled anymore). We simply use the GSource ready time to make them active/inactive when we want to schedule/stop them.

Overlay scrollbars

GNOME designers have requested us to implement overlay scrollbars since they were introduced in GTK+, because WebKitGTK+ based applications didn’t look consistent with all other GTK+ applications. Since WebKit2, the web view is no longer a GtkScrollable, but it’s scrollable by itself using native scrollbars appearance or the one defined in the CSS. This means we have our own scrollbars implementation that we try to render as close as possible to the native ones, and that’s why it took us so long to find the time to implement overlay scrollbars. But WebKitGTK+ 2.12 finally implements them and are, of course, enabled by default. There’s no API to disable them, but we honor the GTK_OVERLAY_SCROLLING environment variable, so they can be disabled at runtime.

But the appearance was not the only thing that made our scrollbars inconsistent with the rest of the GTK+ applications, we also had a different behavior regarding the actions performed for mouse buttons, and some other bugs that are all fixed in 2.12.

The NetworkProcess is now mandatory

The network process was introduced in WebKitGTK+ since version 2.4 to be able to use multiple web processes. We had two different paths for loading resources depending on the process model being used. When using the shared secondary process model, resources were loaded by the web process directly, while when using the multiple web process model, the web processes sent the requests to the network process for being loaded. The maintenance of this two different paths was not easy, with some bugs happening only when using one model or the other, and also the network process gained features like the disk cache that were not available in the web process. In WebKitGTK+ 2.12 the non network process path has been removed, and the shared single process model has become the multiple web process model with a limit of 1. In practice it means that a single web process is still used, but the network happens in the network process.

NPAPI plugins in Wayland

I read it in many bug reports and mailing lists that NPAPI plugins will not be supported in wayland, so things like http://extensions.gnome.org will not work. That’s not entirely true. NPAPI plugins can be windowed or windowless. Windowed plugins are those that use their own native window for rendering and handling events, implemented in X11 based systems using XEmbed protocol. Since Wayland doesn’t support XEmbed and doesn’t provide an alternative either, it’s true that windowed plugins will not be supported in Wayland. Windowless plugins don’t require any native window, they use the browser window for rendering and events are handled by the browser as well, using X11 drawable and X events in X11 based systems. So, it’s also true that windowless plugins having a UI will not be supported by Wayland either. However, not all windowless plugins have a UI, and there’s nothing X11 specific in the rest of the NPAPI plugins API, so there’s no reason why those can’t work in Wayland. And that’s exactly the case of http://extensions.gnome.org, for example. In WebKitGTK+ 2.12 the X11 implementation of NPAPI plugins has been factored out, leaving the rest of the API implementation common and available to any window system used. That made it possible to support windowless NPAPI plugins with no UI in Wayland, and any other non X11 system, of course.

New API

And as usual we have completed our API with some new additions:

 

19 de marzo de 2016

¡Cifremos la web!

Qué es Let’s Encrypt

Es bien sabido que conviene cifrar siempre que podamos, y la web no lo es menos. De hecho, hace tiempo que Google fomenta el uso de web cifrada amenazando con penalizar aquellas que no lo estén.

El caso es que, para tener una web cifrada, tenemos dos problemas: por un lado, comprar un certificado a una entidad certificadora reconocida, y por otro, renovarlo periódicamente (lo que suele tener un coste también). Desde hace tiempo, iniciativas como CaCert, intentaron crear una autoridad certificadora libre de costes para sus usuarios y gestionada por la comunidad, de la que, pese a ser yo mismo uno de sus notarios, tengo que decir que su éxito ha sido siempre escaso, entre otras razones porque lleva ya bastantes años con nosotros y aún no es reconocida por la mayoría de los navegadores.

Por otro lado, la renovación tiene otro problema: hay que estar pendiente de ello. Para resolver ambos problemas, ha surgido una iniciativa, llamada Let’s Encrypt.

Let's Encrypt

Lo primero que vemos es que la reconocen todos los navegadores. El coste de conseguir esto debe estar cubierto por la multitud de sponsors que tiene el proyecto.

En segundo lugar, utiliza un desafío, llamado ACME, para verificar que la web que queremos cifrar es la dueña del dominio a usar (por ejemplo, https://dramor.net/). Con esta verificación, se pueden emitir sin problemas, certificados sin coste (al ser generados automáticamente), siempre que no necesitemos otras características como la validación de identidad.

Veremos que con este proyecto, se pueden conseguir certificados de sitio web de forma bastante sencilla. Por ejemplo, veamos cómo se resuelve para Nginx.

Implementación en los sitios de DrAmor.net

Antes de nada, decir que no voy a dar la configuración completa de nginx, entendiendo que el lector sabrá de lo que hablo, o podrá ayudarse de los tutoriales mencionados en este artículo.

En general, lo que veremos nos vale en cualquier Linux o Unix que pueda ejecutar git, python y nginx. Lo primero que haremos es bajarnos el repositorio de Let’s Encrypt:

$ git clone https://github.com/letsencrypt/letsencrypt

Este repositorio trae plugins para varios servidores web, pero como Nginx no está aun bien soportado, debemos usar el plugin webroot.

Hemos seguido la documentación oficial y el tutorial de Digital Ocean para hacernos una idea, aunque los pasos seguidos fueron, en primer lugar crear un fichero de configuración llamado /etc/letsencrypt/letsencrypt-dramor.net.ini:

rsa-key-size = 4096

email = Direccion-email-valida@gmail.com

webroot-map = {"dramor.net,www.dramor.net":"/var/www/dramor.net", "blog.dramor.net,www.blog.dramor.net":"/var/www/dramor_blog", "home.dramor.net":"/var/www/dramor_home"}

Por supuesto, el e-mail debe ser correcto. Lo oculto con el ánimo de evitar un poco el spam, claro. Y el webroot-map no es más que un formato json donde especifica los dominios a firmar, junto con la carpeta raíz de cada sitio, que debe incluir una subcarpeta publicada por nginx, para poder ejecutar el desafío ACME.

La carpeta a publicar en nginx se debe llamar .well-known. Por ejemplo, la podemos publicar en los sitios virtuales nginx con:

location ~ /.well-known {
    allow all;
}

Una vez configurado nginx, ya podemos generar los certificados:

$ cd letsencrypt

$ sudo ./letsencrypt-auto certonly -a webroot --renew-by-default --config /etc/letsencrypt/letsencrypt-dramor.net.ini
Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/jjamor/.local/share/letsencrypt/bin/letsencrypt certonly -a webroot --renew-by-default --config /etc/letsencrypt/letsencrypt-dramor.net.ini

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/dramor.net/fullchain.pem. Your cert will
   expire on 2016-06-16. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

La primera vez creará un virtualenv de la versión de Python requerida, y actualizará algunos paquetes. Una vez generados los certificados, se instalan en: /etc/letsencrypt/live/dramor.net. Si dio algún error, debemos revisar que esté accesible .well-known en los sitios virtuales de nginx, y que los DNS del dominio deseado apunten correctamente al servidor web, entre otras cosas. Los mensajes de error siempre son lo suficientemente descriptivos como para no requerir más explicación. Por ejemplo, nos puede avisar de que algún nombre DNS del dominio a asegurar no resuelve correctamente el registro A o CNAME, o no apunta a nuestro servidor.

Usar los certificados en Nginx ya es cosa de usar las líneas de configuración de nginx similares a:

ssl_certificate /etc/letsencrypt/live/dramor.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/dramor.net/privkey.pem;

Renovación automática

Los certificados así generados tienen una vigencia de solo tres meses. Pero renovarlos consiste simplemente en volver a ejecutar el desafío ACME.

Para ello, solo hay que llamar a letsencrypt-auto con otro parámetro:

$ ./letsencrypt-auto renew

Podemos hacer un script a ejecutar periódicamente (por ejemplo, un cron semanal), que realice esta acción y a continuación ejecute un reload de nginx. De este modo, podemos olvidarnos de las renovaciones: tendrán lugar cuando hagan falta.

Conviene probar todos los scripts antes de automatizarlo con el cron. Por ejemplo, si nada más generar los certificados intentamos renovarlos:

$ ./letsencrypt-auto renew
Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/jjamor/.local/share/letsencrypt/bin/letsencrypt renew
Processing /etc/letsencrypt/renewal/dramor.net.conf

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/dramor.net/fullchain.pem (skipped)
No renewals were attempted.

Podemos forzar la renovación para verificar que funciona, con:

$ ./letsencrypt-auto renew --force-renewal

Por último, indicar que si vamos a hacer muchas pruebas, mejor generemos los certificados con la opción staging, para que que se generen certificados no válidos. Si hacemos muchas pruebas seguidas, alcanzaremos fácilmente el límite diario y no podremos generar más hasta el día siguiente.

Si hemos hecho todo correctamente, podremos navegar por el sitio web con cifrado; y si queremos, podemos comprobar la calidad del mismo aquí: SSLLabs. Conseguir una buena puntuación ya es cosa de seguir determinadas buenas prácticas con el servidor web, que no cubriré aquí.

07 de marzo de 2016

Transmission, torrents, OSX y malware KeRanger

Captura de pantalla 2016-03-07 a las 22.49.09 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:

Captura de pantalla 2016-03-07 a las 23.21.41

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?

Captura de pantalla 2016-03-07 a las 21.29.34

 

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

Captura de pantalla 2016-03-07 a las 22.00.40

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:

Captura de pantalla 2016-03-07 a las 21.44.06

Con la extensión JSONView instalada:

Captura de pantalla 2016-03-07 a las 21.43.51

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…)

05 de marzo de 2016

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.

Configuración de WordPress

Después de varios días por fin saco tiempo para continuar la entrada del otro día donde os comentaba las bondades de WordPress. Hoy voy a daros algunos consejos sobre como configurarlo:

1. Estructura Permalink

Lo primero que debes cambiar es la estructura de enlaces permanentes. Se encuentran en Configuración → Enlaces permanentes. El enlace permanente por defecto es <postid>, pero yo prefiero utilizar el nombre de la entrada:

/%postname%/

Permalinks

2. ¿SSL o no SSL?

En 2014 Google anunció que las webs corriendo bajo https tendrían mejor valoración de cara al posicionamiento por este motivo muchas web han cambiado a SSL. Todo depende de nuestro presupuesto, los SSL cuestan $$$.

3. ¿WWW vs no-WWW?

Aquí es cuestión de gustos, si quieres que tu blog aparezca en el navegador como como www.example.com o simplemente example.com. Asegúrate de que en Configuración → General, la versión que deseas aparece correctamente.

4. Optimiza las descripciones

Los webmaster suelen centrarse en los títulos pero nunca hay que dejar de lado las descripciones. La descripción muestra una parte de información muy importante en los resultados de búsqueda y podemos incluir en ella las palabras clave (keywords) que queremos resaltar.

5. Limpiar el código

Reduce al mínimo posible los Javascript y CSS que pueda tener tu plantilla. Google valora la rapidez de carga de tu web, de hecho hay un test específico para ello que mide tanto la versión normal como la móvil (responsive):

Test de velocidad de carga de Google

6. SEO y contenido duplicado

Debes huir siempre del contenido duplicado ya que es una de las cosas que más penalizan a la hora de posicionar tu blog. Google tiene avanzados algoritmos que analizan el texto (densidad keywords, frases, párrafos, incluso el conjunto!) para ver si son copiados de otros existentes.

7. Encabezamientos (headers)

Aunque cada vez tienen menor peso en el SEO aún sigue siendo una buena idea poner algunos textos con encabezamientos, por ejemplo el de mayor tamaño <h1> para el nombre de la entrada. Puedes poner también algún <h2> y <h3> para slogan o títulos secundarios.

 

02 de marzo de 2016

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.

26 de febrero de 2016

Über latest Media Source Extensions improvements in WebKit with GStreamer

In this post I am going to talk about the implementation of the Media Source Extensions (known as MSE) in the WebKit ports that use GStreamer. These ports are WebKitGTK+, WebKitEFL and WebKitForWayland, though only the latter has the latest work-in-progress implementation. Of course we hope to upstream WebKitForWayland soon and with it, this backend for MSE and the one for EME.

My colleague Enrique at Igalia wrote a post about this about a week ago. I recommend you read it before continuing with mine to understand the general picture and the some of the issues that I managed to fix on that implementation. Come on, go and read it, I’ll wait.

One of the challenges here is something a bit unnatural in the GStreamer world. We have to process the stream information and then make some metadata available to the JavaScript app before playing instead of just pushing everything to a playing pipeline and being happy. For this we created the AppendPipeline, which processes the data and extracts that information and keeps it under control for the playback later.

The idea of the our AppendPipeline is to put a data stream into it and get it processed at the other side. It has an appsrc, a demuxer (qtdemux currently

) and an appsink to pick up the processed data. Something tricky of the spec is that when you append data into the SourceBuffer, that operation has to block it and prevent with errors any other append operation while the current is ongoing, and when it finishes, signal it. Our main issue with this is that the the appends can contain any amount of data from headers and buffers to only headers or just partial headers. Basically, the information can be partial.

First I’ll present again Enrique’s AppendPipeline internal state diagram:

First let me explain the easiest case, which is headers and buffers being appended. As soon as the process is triggered, we move from Not started to Ongoing, then as the headers are processed we get the pads at the demuxer and begin to receive buffers, which makes us move to Sampling. Then we have to detect that the operation has ended and move to Last sample and then again to Not started. If we have received only headers we will not move to Sampling cause we will not receive any buffers but we still have to detect this situation and be able to move to Data starve and then again to Not started.

Our first approach was using two different timeouts, one to detect that we should move from Ongoing to Data starve if we did not receive any buffer and another to move from Sampling to Last sample if we stopped receiving buffers. This solution worked but it was a bit racy and we tried to find a less error prone solution.

We tried then to use custom downstream events injected from the source and at the moment they were received at the sink we could move from Sampling to Last sample or if only headers were injected, the pads were created and we could move from Ongoing to Data starve. It took some time and several iterations to fine tune this but we managed to solve almost all cases but one, which was receiving only partial headers and no buffers.

If the demuxer received partial headers and no buffers it stalled and we were not receiving any pads or any event at the output so we could not tell when the append operation had ended. Tim-Philipp gave me the idea of using the need-data signal on the source that would be fired when the demuxer ran out of useful data. I realized then that the events were not needed anymore and that we could handle all with that signal.

The need-signal is fired sometimes when the pipeline is linked and also when the the demuxer finishes processing data, regardless the stream contains partial headers, complete headers or headers and buffers. It works perfectly once we are able to disregard that first signal we receive sometimes. To solve that we just ensure that at least one buffer left the appsrc with a pad probe so if we receive the signal before any buffer was detected at the probe, it shall be disregarded to consider that the append has finished. Otherwise, if we have seen already a buffer at the probe we can consider already than any need-data signal means that the processing has ended and we can tell the JavaScript app that the append process has ended.

Both need-data signal and probe information come in GStreamer internal threads so we could use mutexes to overcome any race conditions. We thought though that deferring the operations to the main thread through the pipeline bus was a better idea that would create less issues with race conditions or deadlocks.

To finish I prefer to give some good news about performance. We use mainly the YouTube conformance tests to ensure our implementation works and I can proudly say that these changes reduced the time of execution in half!

That’s all folks!

08 de febrero de 2016

WordPress SEO

Con la invención de Internet y el marketing digital el alcance de la optimización de motores de búsqueda (SEO) se ha convertido en uno de los métodos preferidos de promoción web. Por este motivo en la entrada de hoy quiero hablaros de como utilizar el software de blogs más conocido del mundo (WordPress) para mejorar el SEO de vuestras webs.

SEO, en términos generales se denomina como la optimización de motores de búsqueda. A diario millones de personas utilizan los buscadores para acceder a la información que necesitan. Aparecer en las primeras posiciones de las palabras clave (keywords) es imprescindible para el éxito de nuestro proyecto en Internet. Por este motivo la mayoría de los webmasters han optado por la promoción basada en SEO para poder llegar a su público objetivo.

Con el paso de los años (incluso meses) las técnicas de optimización en buscadores se actualizan por lo que hay que estar atentos y en constante evolución ante los cambios del algoritmo de Google.

Recientemente la empresa donde alojo ACS (podeis ver su banner al pie del blog) ha lanzado un VPS específico para el SEO basado en WordPress.

¿Y por qué han elegido WordPress?

WordPress es uno de los mejores sistemas de gestión de contenido cuando se trata de SEO, teniendo en cuenta que casi una cuarta parte de las webs de internet están hechas con este CMS tantos webmasters no han podido equivocarse!.

Ahora al grano, lo que proponen con este VPS SEO es poder levantar en pocos minutos hasta 4 hosting WordPress cada uno con una dirección IP clase C propia (IPs españolas).

WordPress es un software muy bien optimizado y permite que cada página sea indexada rapidamente por los buscadores, por este motivo es muy sencillo crear un blog, añadir buen contenido y enlazar a nuestras webs para mejorar sus rankings.

04 de febrero de 2016

Puente Johnson de noche

Puente Johnson Puente Johnson de noche. Victoria, British Columbia, Canadá.

01 de febrero de 2016

Web Engines Hackfest according to me

And once again, in December we celebrated the hackfest. This year happened between Dec 7-9 at the Igalia premises and the scope was much broader than WebKitGTK+, that’s why it was renamed as Web Engines Hackfest. We wanted to gather people working on all open source web engines and we succeeded as we had people working on WebKit, Chromium/Blink and Servo.

The edition before this I was working with Youenn Fablet (from Canon) on the Streams API implementation in WebKit and we spent our time on the same thing again. We have to say that things are much more mature now. During the hackfest we spent our time in fixing the JavaScriptCore built-ins inside WebCore and we advanced on the automatic importation of the specification web platform tests, which are based on our prior test implementation. Since now they are managed there, it does not make sense to maintain them inside WebKit too, we just import them. I must say that our implementation is fairly complete since we support the current version of the spec and have almost all tests passing, including ReadableStream, WritableStream and the built-in strategy classes. What is missing now is making Streams work together with other APIs, such as Media Source Extensions, Fetch or XMLHttpRequest.

There were some talks during the hackfest and we did not want to be less, so we had our own about Streams. You can enjoy it here:

You can see all hackfest talks in this YouTube playlist. The ones I liked most were the ones by Michael Catanzaro about HTTP security, which is always interesting given the current clumsy political movements against cryptography and the one by Dominik Röttsches about font rendering. It is really amazing what a browser has to do just to get some letters painted on the screen (and look good).

As usual, the environment was amazing and we had a great time, including the traditional Street Fighter‘s match, where Gustavo found a worthy challenger in Changseok 🙂

Of course, I would like to thank Collabora and Igalia for sponsoring the event!

And by the way, quite shortly after that, I became a WebKit reviewer!

19 de enero de 2016

Ruby On Rails

Según me han comentado Ruby es una especie de Perl simplificado con una buena orientación a objetos, algo como Python pero con una sintaxis más similar a la de Perl.

Supongo que lo primero será instalar en mi servidor Ruby On Rails que supongo que consistirá en el lenguaje de programación Ruby junto con un entorno de ejecución (librerías, ficheros de configuración, componentes …).

En Debian tenemos el paquete rails que diría tiene todo lo necesario: «Rails is a full-stack, open-source web framework in Ruby for writing real-world applications.». El paquete no parece estar disponible en Debian Sarge así que haremos un paquete desde la versión inestable de Debian (backport). Ha sido realmente sencillo: ruby y las librerías de Debian Sarge valen para rails. Sólo he tenido que instalar una versión más moderna de rake con respecto a la que viene en Debian Sarge (haciendo un backport) y tras ello, he podido hacer el paquete de rails para Debian Sarge.

Como me ocurre siempre, el vídeo en Totem no se ve. Utilicemos mplayer. El vídeo es un poco grande y ha sido grabado en un escritorio MacOS X. Para poderlo ver de forma cómoda voy a reproducirlo a pantalla completa en 1024×768.

acs@delito:~$ mplayer -fs rails_take2_with_sound.mov

Será esencial la tecla de pausa para irlo siguiendo paso a paso. Las primeras impresiones es que al crearte una aplicación rails por defecto, se crean un montón de ficheros que serán la infraestrutura de la aplicación y que son los que nos ahorrarán el escribir mucho código. De momento no nos ha tocado tener que escribir Ruby, pero seguro que algo nos tocará ;-)

Para crear el esqueleto básico de una aplicación rails:

acs@macito:~/devel/rails$ rails testRails
      create
      create  app/controllers
      create  app/helpers
...
acs@macito:~/devel/rails$ sloccount testRails/
...
WARNING! File /home/acs/devel/rails/testRails/script/plugin has unknown start: #!/usr/bin/env ruby
...
SLOC    Directory       SLOC-by-Language (Sorted)
36      config          ruby=36
7       test            ruby=7
4       app             ruby=4
4       public          ruby=4
...
Totals grouped by language (dominant language first):
ruby:            51 (100.00%)

Vemos que tampoco se generá mucho código Ruby de forma automática, algo que sin duda es bueno (aunque sloccount ha fallado al contar en varios directorios, pero tras mirar a mano, parecen sólo unas 30 líneas de Ruby).

Por defecto dentro de cada aplicación Rails existe el fichero “README” que cuenta lo básico sobre como poner en marcha la aplicación y una descripción de los contenidos. Y también se incluye un servidor de web que ejecuta la aplicación rails. Para iniciarlo basta con:

acs@macito:~/devel/rails$ testRails/script/server
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2006-02-20 05:41:51] INFO  WEBrick 1.3.1
...

En el puerto 3000 de la máquina donde estamos ejecutando el servidor tenemos ya el servidor de rails funcionando. Pero aún no hemos hecho nada así que no hay gran cosa aún en él, salvo documentación de más pasos en el camino. En general da la impresión de que está todo rails muy trabajado para llevar de la mano al desarrollador durante todo el proceso.

Los siguientes pasos siguiendo la página web por defecto son los de crear la base de datos, configurarla en nuestra aplicación rails y utilizar el programa “script/generate” para generar los modelos y controladores de los datos en la base de datos, justo el proceso que se sigue durante el vídeo.

17 de enero de 2016

¿Usas código de StackOverflow? Debes citar la fuente

Leí la noticia en Slashdot hace unos días.  La gente de StackExchange (SE, madre nodriza de otras tantas, donde destaca StackOverflow.com) quería discutir con la comunidad un cambio en la licencia de uso de los trozos de código de esta web.  La cuestión es que la nueva licencia, que entraría en vigor el 1 de marzo de 2016, proponía que:

* Las aportaciones que no fueran de código y estuvieran disponibles en alguna de las webs de la red StackExchange seguirían gobernadas por los términos de la licencia CC-BY-SA

* Las aportaciones de código estarían gobernadas por los términos de la licencia MIT (sin necesidad de tener que incluir todos los términos de la licencia en tu proyecto, basta con atribuir el origen.

Realmente esto sólo cambia con respecto a la licencia anterior de la red SE en que antes la atribución era bajo petición del usuario creador de dicho código (poseedor del copyright de dicho código) o de SE en representación o en nombre de dicho usuario.

Se lió una buena discusión con estos términos. Hay cientos de comentarios al respecto, muchos de ellos en contra de esta decisión.

Llevo tiempo usando StackOverflow, tanto de forma profesional como programador, analista de datos, para mis clases de docencia e incluso como elemento de investigación. En mi faceta de programador, siempre que recojo algún trozo de código de SO intento incluir una referencia al post original a través de un comentario en el código. No sólo por cortesía, que también, sino sobre todo porque me interesa documentar las fuentes en las que me baso a la hora de programar. Si he tenido que acudir a SO a buscar esta solución, seguro que en el futuro alguien que lea mi código (yo mismo, probablemente) tendrá la misma duda y querrá saber más al respecto, o simplemente, ese trozo de código le puede parecer interesante y puede querer seguir profundizando en el tema. El enlace al post original en SO seguro que le/nos ayuda.

Con respecto a la docencia, atribuir el origen del código es lo mínimo que deberíamos hacer los profesores. Y predicar al alumnado con el ejemplo: al César lo que es del César, give credit where credit is due. Aprender a citar correctamente cuesta, y pequeños gestos como éste no cuestan nada y van formando al alumno.

En definitiva, yo estoy a favor de tener que citar la fuente de los trozos de código que obtengamos de la red SE. De hecho, como he indicado, es algo que nos beneficia a todos.

Sin embargo, la gran discusión suscitada ha hecho que la gente de SE haya decidido, a fecha de 15 de enero de 2016, aplazar la decisión.

30 de diciembre de 2015

Frogr 1.0 released

I’ve just released frogr 1.0. I can’t believe it took me 6 years to move from the 0.x series to the 1.0 release, but here it is finally. For good or bad.

Screenshot of frogr 1.0This release is again a small increment on top of the previous one that fixes a few bugs, should make the UI look a bit more consistent and “modern”, and includes some cleanups at the code level that I’ve been wanting to do for some time, like using G_DECLARE_FINAL_TYPE, which helped me get rid of ~1.7K LoC.

Last, I’ve created a few packages for Ubuntu in my PPA that you can use now already if you’re in Vivid or later while it does not get packaged by the distro itself, although I’d expect it to be eventually available via the usual means in different distros, hopefully soon. For extra information, just take a look to frogr’s website at live.gnome.org.

Now remember to take lots of pictures so that you can upload them with frogr 🙂

Happy new year!

28 de diciembre de 2015

Sonic Pi packaged for Fedora

Maybe you know about Sonic Pi, the system to learn programming playing with music. Now I want to give it a try in my system (Fedora 23) and my sysadmin-TOC syndrome obligues me first to package it into RPM. Now I have good and bad news. The good news are I have a testing release of Sonic Pi for Fedora 23. It includes a desktop file too. The bad news are... it doesn't work yet. Sonic Pi uses jackd while a common Fedora Workstation uses pulseaudio and both try to manage the sound device by themselves.

After a quick googling seems possible to get a procedure for using some working configuration for puleaudio+jackd but I didn't have the time to find and check them. Meanwhile, if the RPM package is useful for someone here it is.

This package depends of Supercollider as provided by Planet CCRMA package repository. To use this Sonic Pi maybe you'll want to add the repository to your system.

Please feedback here if you know how to make sound to work.

PD: Post edited to add references to Planet CCRMA repositorie.

27 de diciembre de 2015

Running EPF (Eclipse Process Framework) in Linux

For many time I wanted to learn to use EPF but technical reasons always stoped me. Blame me because I'm not an Eclipse guy and I'm not into its eclipse-isms but until today I have not been able to launch it. Now, wirth this really simple recipe you'll be able to run it.

Initial technical scenario:

Then unzip the file and execute:

$ unzip epf-composer-1.5.1.7-linux.zip
$ cd epf-composer
[epf-composer]$ ./epf
Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library /home/olea/epf-composer/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.2.R36x_v20101019_1345/eclipse_1310.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
(Epf:27092): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(Epf:27092): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
Gtk-Message: Failed to load module "pk-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"

If you, like me, don't know nothing about Eclipse maybe you are doomed because the real problem is everything but clear. What you are having is the EPF application asking for a 32 bits java VM runtime. Nothing more, nothing less. But now is very easy to fix:
  1. just get a 32 bits java VM
  2. adjust epf-composer/epf.ini to use it
In my case I've installed a Java 1.7 (in my case from the same Russian Fedora repo):

$ sudo dnf install http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/updates/23/x86_64/java-1.7.0-oracle-1.7.0.79-1.fc23.R.i586.rpm
and then change ~/epf-composer/epf.ini from this:

-data
@user.home/EPF/workspace.151
-vmargs
-Xms64m
-Xmx512m

to this:

-vm
/usr/lib/jvm/java-1.7.0-oracle-1.7.0.79/jre/bin/java
-data
@user.home/EPF/workspace.151
-vmargs
-Xms64m
-Xmx512m

Please note the precise path may be different in your system but in any case it should point to a 32 bit java binary.

Then you just need to launch EPF and you are ready:

$ epf-composer/epf
Enjoy.

24 de diciembre de 2015

OpenJDK

Ahora mismo queda ya bastante claro de la FAQ de OpenJDK, la comunidad formada por SUN para desarrollar las versiones libre de Java, que casi todo JDK 6 es ya software libre aunque quedan algunas partes que aún están pendientes.

Presentación del estado de OpenJDK en Fosdem 2008 que muestra las partes que aún no son libres de JDK y que coinciden con las que se mencionan en la FAQ:

Graphics rasterizer
Font rasterizer
Imaging APIs
Sound engine
Crypto providers
Some SNMP code

 Fully buildable != fully free
     25,169 source files
894 (4%) binary only (“plugs”)

 

Las partes que aún no son software libre quedan claras en la FAQ:

Q:
What are the encumbered components in the JDK (Java SE)?
A:
The larger encumbered components requiring binary files for a full build include the font rasterizer, the graphics rasterizer, and the sound engine. Smaller components include some cryptographic algorithms, some SNMP code, and some of the imaging APIs.

 

y las presentaron el equipo de SUN dentro del FOSDEM en la sala de Free Java. Son las partes de JDK que están calificadas como “encumbered” y que tienen problemas para ser publicadas con licencia GPLv2.

Imaging APIs van a dejar de ser problema en breve (Marzo 2008).

Módulos que ya son software libre

Las partes de JDK (Java SM) que ya son software libre son:

In November 2006, Sun open sourced the Java programming language compiler ("javac"), and the Java HotSpot virtual machine. In addition, Sun open sourced the JavaHelp 2.0 extensible help system, Sun's reference implementation of JSR 97.


The following components are newly open sourced under GPL version 2 plus the Classpath Exception:

    * Core libraries
    * Networking libraries
    * Security libraries
    * Serviceability libraries
    * Internationalization libraries
    * 2D graphics subsystem
    * AWT, the Abstract Windowing Toolkit
    * Swing GUI toolkit
    * Sound subsystem
    * Various tools, including JConsole and javadoc

the exception of a few encumbered components that we hope, with the community's help, can be re-implemented so that 100% of the OpenJDK code commons is available as free software.

 

Guía del Desarrollador de OpenJDK

Guía para el que quiere ser desarrollador de OpenJDK

Comunidad OpenJDK 6 (objetivo similar a Iced Tea, OpenJDK 6 totalmente libre)

Construyendo OpenJDK desde las fuentes

Una de las actividades que quiero llevar a cabo es construir todo JDK desde las fuentes. Para ello lo mejor parece ser comenzar con NetBeans aunque intentaré hacerlo todo desde un terminal a la vieja usanza.

El IDE para Java

De momento tengo idea de seguir con mis terminales y vi/emacs para editar en Java. Pero quizá en el medio plazo acabe utilizando Eclipse, NetBeans o quien sabe, Monodevelop y su extensión para Java. El IDE comercial mejor considerado en Liferay es IntelliJ IDEA pero haré lo posible por huir de tecnologías privativas.

El proyecto Iced Tea

En Red Hat han lanzado el proyecto Iced Tea para «que el software OpenJDK publicado por Sun Microsystems como software libre en 2007 sea usable sin que sea necesario ningún otro software que no sea software libre». En SUN tiene un objetivo similar en OpenJDK así que no sé cuanto de sentido tiene este proyecto. Aunque siempre está bien que haya diversas comunidades con diversos intereses cuidando de la libertad de las cosas. En Iced Tea se puede ver bien las partes no libres que quedan en JDK (Java SE), como un 4%.

«IcedTea is not a fork, and is not meant to be a permanent project – just a stopgap measure to create a fully FOSS OpenJDK. »

Utilizando Javascript en Java

Con el motor de Javascript Rhino se pude integrar en desarrollos Java partes hechas en Javascript fácilmente. Javascript está en auge con la llegada de la Web 2.0 y futuras evoluciones, así que podría ser un lenguaje de scripting muy adecuado para los programas en Java.

Tecnologías Java

Dentro de las tecnologías Java que hay que manejar en Liferay tenemos Spring, Struts, Hibernate, Java Faces, jQeury o Velocity. A parte de profundizar en todas ellas me interesa a día de hoy explorar en profundidad el uso de genéricos en Java, un diseño que también se utiliza en C#.

Generics

Generics está disponible desde la versión Java SE 5.0. En C++ se conocen como “Templates” y la idea básica es definir tipos de datos, clases, que reciben como variables los tipos de datos con los que trabajan. En vez de tener contenedores genéricos de objetos (Object) en los que se puede meter cualquier tipo de clase pero que obliga a hacer un “casting” luego de sacar el objeto genérico a la clase que metismo, los genéricos permiten especificar que estamos creando una lista para guardar un determinado tipo de datos.

List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3

pasa a ser

List<Integer> myIntList = new LinkedList<Integer>(); // 1’
myIntList.add(new Integer(0)); //2’
Integer x = myIntList.iterator().next(); // 3’

 

Máquinas virtuales en el servidor

Introducción

Mi principal motivación a la hora de montar máquinas virtuales en mi servidor de casa es la de aprender a trabajar con los nuevos entornos virtuales, que aportan mayor seguridad (puedes dar por ejemplo clave de root en una máquina virtual de pruebas sin problemas), son más flexibles (puedes tener diferentes sistemas corriendo en el mismo hardware) y diría que hasta más sostenibles (menos hardware necesario). Además, es un campo de avance de la tecnología que abre posibilidades muy interesantes en sistemas distribuidos (migración de máquinas virtuales entre máquinas físicas, balanceo de carga, recuperación rápida ante fallos …).

En resumen, que son múltiples las ventajas de usar máquinas virtuales y merece la pena invertir un poco de esfuerzo en terminar de aprenderlas bien.

Nos referimos a máquinas virtuales a nivel de sistema que emulan por completo el hardware y permiten ejecutar sobre ellas sistemas operativos completos sin modificar, y no las máquinas virtuales de aplicaciones como por ejemplo Java.

Tecnologías de virtualización

No voy de momento a realizar un estudio de las diferentes alternativas que hay para la virtualización. De momento voy a tirar por Xen que es lo que ya conozco y una de las tecnologías libres más pujantes. A día de hoy ya hay otras opciones, tanto privativas como libres. Una de las que se oye hablar bastante últimamente es Virtual Box que en su versión básica es GPL.

Instalación de Xen en micro con soporte VT

Tras leer con detenimiento la información sobre máquinas virtuales en la Wikipedia, el objetivo es lograr explotar las capacidades que tienen los micros de Intel a nivel de hardware con la Virtualization Technology. Esta se puede explotar a partir de Xen 3.0 y permite correr diferentes sistemas operativos sobre el mismo hardware con un soporte más completo. Anterior a esto Xen era tecnología de paravirtualización, en la que se corrían diferentes sistemas operativos sobre el mismo hardware, pero con limitaciones. Con Xen 3.0 e Intel VT ya se puede correr por ejemplo Windows en Xen como sistema invitado. Como sistema hypervisor (virtual machine monitor) en nuestro caso usaremos una versión modificada de Linux, que será el domain0 en terminología Xen. Los sistemas invitados que corren sobre el hypervisor (dom0) se conocen como domain U (domU).

Por lo tanto, en mi portátil con soporte VT y Xen 3.0, podré tener como dom0 a Ubuntu y como uno de los domU a Windows, u otros Linux. En este sentido gracias a VT, Xen pasa a estar al nivel de emulación que VMWare. Anteriormente los domU sólo podían ser sistemas Linux y no sé si algún que otro Unix.

Nada mejor que utilizar la información de Xen del Wiki de Ubuntu. Aunque como suele pasar, está un poco anticuada (información para 8.04) y por ejemplo, no hace referencia a VT para nada. Pero sigamos lo que dice para tener nuestro sistema base corriendo como dom0 de Xen.

apt-get install ubuntu-xen-server
...
Se instalarán los siguientes paquetes NUEVOS:
  bridge-utils debootstrap libc6-xen libconfig-inifiles-perl libtext-template-perl libxen3 linux-image-2.6.24-19-xen linux-image-xen linux-restricted-modules-2.6.24-19-xen
  linux-restricted-modules-xen linux-ubuntu-modules-2.6.24-19-xen linux-xen python-dev python-xen-3.2 python2.5-dev ubuntu-xen-server xen-docs-3.2 xen-hypervisor-3.2 xen-tools
  xen-utils-3.2

Con esto nos instala un nuevo núcleo (linux-image-2.6.24-19-xen) que incluye el hypervisor y que pasará a ser el dom0 de Xen. Se instala la versión Xen 3.2. Lo instalamos … y reiniciamos el sistema con este nuevo núcleo de Linux. Ya estamos dentro del dom0 de Xen. En realidad el dom0 debería de ser un sistema mínimo sobre el que correr los sistemas invitados, pero en mi caso de momento es todo el sistema completo com el escritorio GNOME y demás. Si veo que todo va muy bien, quizá piense en una reinstalación.

Después de reinicar el núcleo no funciona en el arranque dando un error que por suerte ya está estudiado en launchpad. El problema diría que es hald ya que lo da con el proceso hald-runner, que interactúa a bajo nivel con el hardware (hardware abstraction layer). He puesto un comentario y de momento no hay solución al bug. Y lleva ya varios meses. Diría que es la combinación con SMP, Xen y VT. De momento dejo un poco parado todo aquí :(

Montando todo sobre un Mac Mini

La idea de montar virtualización sobre un mac mini para utilizarlo como servidor ya ha ha sido cubierta en la red utilizando Xen. Vamos a partir de ella.

Como hacerlo bien

  • Instalar como dom0 un sistema mínimo con sólo ssh para poder acceder a él.

Puntos de trabajo

  • Virtualización software o completa con soporte del hardware (Xen 3.0 y extensiones del micro)