GNU social: monta tu nodo en la red federada

Lo tenemos que asumir: facebook, twitter, instagram… solo nos quieren por nuestros datos, ya que se han convertido en una fuente inagotable de pasta, además de almacén enorme de donde diversos organismos -no cito nada- pueden sacar información para tenerte catalogado y controlado.

¿Hay algo “malo” en tener perfiles ahí? No se. Yo no tengo ninguno. Lo que creo que es más importante esa saber a lo que te atienes y obrar en consecuencia. Para mi, es más divertido montar un nodo de una red social federada donde tu propia información está bajo tu control, o al menos donde puedas elegir el servidor con libertad y puedas hablar con la gente que tiene cuenta en otros servidores, ¡exactamente igual que pasa con el correo electrónico! Haced el ejercicio de imaginar el horror que sería si los usuarios de Gmail o cualquier otro, solo pudieran escribirse entre ellos.

GNU social (https://gnu.io/social/) es un software escrito en PHP que te permite echar a andar un nodo que se comunica con otros que ejecutan el mismo software. Para explicarlo sencillo: con twitter solo puedes seguir a gente de twitter, pero con una cuenta en un servidor que tiene una instancia de GNU social (por ejemplo https://quitter.se/) puedes perfectamente interaccionar con otra persona que tiene cuenta en otro servidor con instancia de GNU social (por ejemplo https://gnusocial.de/). Si eres tremendamente impaciente, ábrete una cuenta ya: https://gnu.io/social/try/

Y para rizar el rizo, si no te convence ninguno y cuentas con un servidor propio: un VPS, un servidor en tu casa, etc. puedes crear tu nodo. En él, puedes tener tu propia cuenta e incluso crearle una a tus amigos. Veamos como.

El software está escrito en PHP, así que asumiremos que tenemos un servidor web (Apache, nginx, lighttpd) que puede ejecutar PHP, correctamente configurado. Además, necesitamos un servidor MySQL. Aquí, asumiré que contamos con un servidor en el que tenemos control total. No se si se podrá instalar en un simple hosting, aunque en principio parece que sí. Si todavía no te has ido a tu propia nube, echa un vistazo a Me voy a mi nube I y Me voy a mi nube II. En esos artículos hablaba de Axarnet y EDIS, pero ahora estoy con Digital Ocean, que va de lujo por menos de 5 euros al mes.

Instalando

Vamos a un directorio cualquiera del servidor y nos bajamos la última versión del código:

git clone https://git.gnu.io/gnu/gnu-social.git

Esto nos creará el directorio gnu-social. Seguramente, tendremos los sitios web en /var/www/ así que lo copiamos allí y lo dejamos con los permisos adecuados para Apache:

mkdir /var/www/gnu-social
cp -R gnu-social/* /var/www/gnu-social/
chown -Rf www-data:www-data /var/www/gnu-social/

Ahora tenemos que habilitar el sitio en Apache. Os voy a poner un archivo de configuración de virtual host que he ido componiendo con el tiempo, sacando info de aquí y de allá, que me da la máxima seguridad posible. Utilizo libapache2-mod-gnutls para la comunicación cifrada y habilito solo los algoritmos más seguros. Después de ponerlo, lo comento en detalle.

<IfModule mod_gnutls.c>
<VirtualHost *:443>

GnuTLSEnable on
GnuTLSSessionTickets on
GnuTLSPriorities NONE:+AES-256-CBC:+RSA:+SHA1:+COMP-NULL:+VERS-TLS1.2:+VERS-TLS1.1

DocumentRoot /var/www/gnu-social
ServerName antisocial.midominio.nom.es:443

GnuTLSCertificateFile /etc/ssl/certs/social.pem
GnuTLSKeyFile /etc/ssl/private/social.key

Header set X-Frame-Options “sameorigin”
Header set X-Content-Type-Options “nosniff”
Header set X-XSS-Protection “1; mode=block”

Header set Cache-Control “private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0″
Header set Pragma “nocache”

<Directory /var/www/gnu-social>
Options -Indexes -FollowSymLinks -Includes +SymLinksIfOwnerMatch
AllowOverride all
Order Deny,Allow
</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel error
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

</VirtualHost>
</IfModule>

Parece que ha habido bastantes problemas con SSL últimamente, incluyendo los famosos Heartbleed y POODLE y el más reciente que afecta al algoritmo Diffie-Hellman de intercambio de claves, así que es recomendable pasarse a libapache2-mod-gnutls. Aquí tenemos un RFC de la IETF declarando muerto SSLv3 https://tools.ietf.org/html/rfc7568. Que quede claro: NO hay que usar SSLv3, lo que quiere decir que no hay que usar SSL y pasar a TLS, preferiblemente 1.2

La primera línea destacada es la que activa exclusivamente los algoritmos más fuertes. Comenzar por NONE sirve para desactivarlos todos y activar solo los que van a continuación, en un esquema de lista blanca. No activo SSL y pongo TLS 1.2 y 1.1. Si necesitáis acceso desde algunas versiones más antiguas de Android, podéis probar a añadir :+VERS-TLS1.0 al final de esa línea. La página que os ayudará a configurar bien vuestro servidor es https://www.ssllabs.com/, te permite ejecutar un test y dice qué puede ir mal con tu configuración y ofrece soluciones.

La siguiente línea destacada será el nombre que tendrá el servidor en internet, por ejemplo antisocial.midominio.nom.es. Ya sabéis que tenéis que gestionar el DNS aparte dando de alta el correspondiente CNAME apuntando a vuestra IP.

Luego hay algunas líneas con recomendaciones de configuración para evitar ataques típicos, que son las que van antes de la directiva Directory. Y finalmente, lo único que nos quedará por configurar es precisamente ese directorio, que será el mismo que el de DocumentRoot.

A continuación está el -importante- tema del certificado. Cuando estás montándote aplicaciones que solo vas a usar tú, puedes crearte tu propia autoridad de certificación, pero cuando lo vas a presentar al mundo, es muy conveniente conseguir un certificado de una autoridad de certificación que venga en los navegadores configurada por defecto, así cuando te visiten no tendrán que aceptar excepciones de seguridad. Mi certificado está emitido por http://www.startssl.com/ y es gratuito. Tal autoridad viene (al menos en firefox) cargada por defecto.

Luego vienen unas líneas de protección contra un buen número de ataques típicos contra servidores web. Es interesante tenerlo en este y otros sitios que estén muy expuestos.

El contenido que acabo de poner va a un archivo en /etc/apache2/sites-available que se puede llamar como queramos, por ejemplo gnusocial-tls. Cuando esté creado, activamos el sitio:

a2ensite gnusocial-tls && service apache2 reload

Antes de hacerle la primera visita, tenemos que instalar algunos paquetes. Lo más recomendable es seguir la guía que hay en el archivo INSTALL en el directorio principal de la aplicación. Ahí nos dice que las extensiones de PHP necesarias para que funcione el invento son:

  • openssl
  • php5-curl
  • php5-gd
  • php5-gmp
  • php5-intl
  • php5-json
  • php5-mysqlnd

Tenéis que ir averiguando, en vuestra distribución, como se llaman exactamente esos paquetes e irlos instalando. Si seguimos con la guía de instalación, vemos que recomienda configurar un sistema de caché de código PHP. Para ello, vamos a /etc/php5/apache2/php.ini y al final del archivo cascamos las siguientes líneas:

[opcache]
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 4000
opcache.revalidate_freq = 60

No me queda claro si viene incluido en Apache o funciona porque ya tengo instalado un optimizador. Por si acaso, yo tengo funcionando php-apc (y es muy recomendable) y otro que hace lo mismo php5-xcache. Hay que instalar uno u otro, ya que son incompatibles al tener la misma función.

Después, seguid con la preparación previa estableciendo los permisos del directorio del código si no lo habéis hecho ya (que el propietario y grupo sea www-data o aquél con el que se ejecute el servidor web) y creando una base de datos vacía para nuestra instancia GNU social. Añadiría que viene bien hacer un FLUSH PRIVILEGES después del GRANT ....

Después de esto ya debería estar listo para la primera visita. En el navegador, vamos a https://antisocial.midominio.nom.es/install.php, seguimos las instrucciones y en poco tiempo deberíamos tener nuestro flamante nodo, a falta de hacer algunas optimizaciones opcionales. Es buena práctica borrar o mover a otro sitio fuera del alcance del servidor este archivo install.php después de terminar.

Un poco más allá

Un nodo de GNU social tiene que estar continuamente haciendo tareas, siendo la más básica de ellas comprobar si hay nuevas noticias de la gente a la que sigues, que estará en otros nodos o en el tuyo propio. Por defecto, el gestor que está activado es “oportunista”, que significa que cada vez que se realice un acceso a tu nodo -sea por una visita tuya, una vista de otra persona o un acceso desde otro servidor- se hará todo lo que se pueda para procesar las tareas pendientes. Esto está bien para nodos de poco tráfico, pero si se espera tráfico elevado, será conveniente activar el demonio, que será un proceso que esté siempre ejecutándose comprobando las actualizaciones y realizando las tareas necesarias. La guía de configuración sigue siendo la misma (archivo INSTALL. Echad un vistazo a la preparación previa relativa a la configuración de PHP y de MySQL.

Ahora, vamos al archivo config.php y hacemos las siguientes modificaciones:

  • Descomentar la línea que empieza con $config['db']['schemacheck'], para mejorar la eficiencia.
  • Configurar el tema, a mi me gusta $config['site']['theme'] = 'neo-quitter';.
  • Añadir la línea $config['queue']['enabled'] = true;.
  • Añadir la línea $config['queue']['daemon'] = true;.

Las dos últimas son las que dejan preparada la instancia para hacer uso del demonio, ahora solo quedaría arrancarlo:

bash scripts/startdaemons.sh

Este script se encargará de iniciar todos los demonios que estén correctamente habilitados en la configuración. En nuestro caso, solo el de la cola de tareas, pero también hay uno muy interesante de XMPP y otro para el envío de correos y SMS.

Es muy interesante mirar el directorio plugins, ya que hay una gran variedad. Para activar uno de ellos, solo tienes que añadir la línea correspondiente al archivo de configuración. El primer parámetro coincide con el nombre del directorio que aloja el plugin a activar. Para activar plugins/Memcached hay que añadir:

addPlugin(‘Memcached’);

La función addPlugin admite un segundo parámetro, que será un array asociativo con opciones para el plugin.

Este es un plugin que me gustaría haber activado, ya que tenía previamente un servicio de memcached corriendo en mi servidor. Se trata de un servicio de caché de objetos (normalmente pares <clave, valor>) que evita, a los programas que lo usan, tener que ir a la base de datos a por datos de uso frecuente y que no van a cambiar fácilmente. Como los valores se almacenan en memoria, el acceso es muy rápido.

El tema es que tanto el plugin Memcached como Memcache me dan un error al activarlos y no hay suficiente documentación, así que si alguien averigua como echarlos a andar, agradeceré la información.

Problemillas y apaños

Los dos demonios que he probado dan problemas. No he comentado antes el plugin de XMPP, que es muy interesante.

Si cuentas con un servidor XMPP en la misma máquina -también vale uno cualquiera ya existente, pero así es más eficiente, Prosody va muy bien- puedes activar en GNU social el plugin XMPP. Te permite, por un lado, enviar tus publicaciones (timeline) a una cuenta XMPP que elijas y por otro, publicar utilizando cualquier cliente de XMPP, enviando un mensaje a la cuenta que configures en el plugin. Para activar este asunto:

addPlugin( ‘Xmpp’, array(
‘user’ => ‘usuario’,
‘server’ => ‘servidor.xmpp’,
‘password’ => ‘pass’,
‘resource’ => ‘gnusocial’,
‘public’ => array( ‘usuario@servidor.xmpp’, ‘usuario2@servidor.xmpp’ ))

Con el user podrás publicar en tu nodo y los que aparecen en public recibirán las actualizaciones de la línea de tiempo.

Funcionar, funciona. Cuando está configurado, el startdaemons.sh se encarga de iniciarlo. Pero tanto este como el otro fallan de alguna manera que todavía no he averiguado. El de XMPP se vuelve loco y empieza a sacar mensajes por la consola y al de la gestión de las colas le gusta tumbarme el servidor MySQL.

Finalmente, el de XMPP lo quité, para no cargar la máquina. Y con el de gestión de la cola de tareas -más importante- hice un pequeño apaño: ejecutarlo cada hora durante 10 minutos. Simplemente añadimos esto al cron:

05 * * * * /bin/su www-data -c “/bin/bash /var/www/gnusocial/scripts/startdaemons.sh”
10 * * * * /bin/su www-data -c “/bin/bash /var/www/gnusocial/scripts/stopdaemons.sh”

Y así por ahora parece que va bien, hace tiempo que no se cae la base de datos y el timeline se actualiza adecuadamente. Este truco no vale para XMPP porque éste debería estar ejecutándose siempre.

¡Y no te olvides de seguirme!

Mi nodo se encuentra en https://gs.dnlsd.nom.es/danielside

. Para seguir a alguien, la manera que no me da problemas es usar el botón Remote> que está justo al lado del título FOLLOWING. En la caja que aparecerá, pones https://gs.dnlsd.nom.es/danielside, confirmas, y ya me estás siguiendo.

Y si todavía no te ves con ganas, o no cuentas con un servidor propio, recuerdas que puedes abrir una cuenta en cualquiera de estos servidores (https://gnu.io/social/try/) y ver qué se te ofrece. ¡Nos leemos!

2 thoughts on “GNU social: monta tu nodo en la red federada

Responder

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *