HTTPS con LetsEncrypt

Y algunos ajustes adicionales para sitios construidos con WordPress

LetsEncrypt

Cuando nació, allá por la década de los 60 del siglo pasado, Internet servía casi exclusivamente para el envío y recepción de mensajes, y el modelo se parecía mucho al del correo tradicional: el emisor envía algo a un receptor, pero siempre origen, destino y contenido eran conocidos previamente.
Este modelo del Internet primitivo cambió para siempre en 1989. Tim Berners-Lee ideó el lenguaje HTML con el objetivo de organizar los documentos del CERN.

Poco después, en 1991, este sistema se extendió para el envío de todo tipo de documentos a través de Internet, dando origen a la World Wide Web, que es lo mismo que decir Internet tal y como lo conocemos hoy día. Y todo estaba fundamentado en el protocolo de transferencia para hipertextos (HTTP). Exactamente igual que hoy.

HTTP es el protocolo que utiliza cualquier navegador para comunicarse con los servidores web, y que permiten que puedas ver, por ejemplo, esta página. Funciona bien, pero hay que tener en cuenta que con él todos los datos se transmite en texto plano, sin cifrar.

Cualquier persona dentro de tu red o que pueda interponerse entre tu computadora y el servidor será capaz de ver tus contraseñas, datos bancarios, etc. Por eso desde hace años prácticamente todas las webs transaccionales (aquellas en las que puedes realizar operaciones de cualquier índole, pero especialmente compras, transferencias, etc) utilizan HTTPS.

HTTPS

Hyper Text Transfer Protocol Secure (HTTPS) es la versión segura de HTTP. Todas las comunicaciones entre tu navegador y el servidor son encriptadas utilizando SSL/TLS (Secure Sockets Layer/Transmission Layer Security), que son dos protocolos para enviar paquetes cifrados a través de Internet. Su uso como dijimos, está ampliamente difundido entre comercios electrónicos y banca online, aunque desde hace unos años crece la presión para generalizar su uso en detrimento de HTTP. Google, por ejemplo, concede mayor relevancia en sus resultados a los sitios con HTTPS, lo que hace que cualquier experto en posicionamiento se decante por su uso.

El problema, hasta hace poco, es que los certificados que se usan para el cifrado HTTPS eran de pago. Pero todo eso cambió desde el finales del año pasado, cuando la Electronic Frontier Foundation se propuso la puesta en marcha de una “autoridad certificadora” con la intención de ayudar a cifrar el tráfico de toda la web.

LetsEncrypt

Con el nacimiento de LetsEncrypt, cualquiera puede asegurar su sitio web con HTTPS en cuestión de minutos y de forma absolutamente gratuita. Veamos cómo hacerlo en un servidor con Ubuntu Server y Apache:

  1. Comprobar que todos los paquetes del sistema están actualizados, e instalar git:
    apt-get update
    apt-get upgrade
    apt-get install git
  2. Instalar Let’s Encrypt:
    git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
  3. Generar los certificados de Let’s Encrypt:
    cd /opt/letsencrypt
    ./letsencrypt-auto --apache -d ejemplo.com

    También puedes utilizar un único certificado para múltiples dominios o subdominios, para lo que tienes que añadir algunos parámetros al comando:
    ./letsencrypt-auto --apache -d ejemplo.com -d www.ejemplo.com

Con esto ya tenemos el certificado para nuestro sitio web, podemos asegurar razonablemente (https no es invulnerable) que la comunicación entre nuestro servidor y los navegadores de los visitantes del mismo ha sido cifrada y es inviolable. Cuando visiten nuestro sitio, verán algo así:

Candado verde https

Un candado verde, seguido de “https”, que indica que la conexión es segura.

Aspectos adicionales

Ya casi todo el trabajo está hecho. Pero veamos algunos aspectos a revisar.

  1. Para evitar que se pueda acceder a tu sitio web por http, y obligar a que la conexión sea siempre segura, https y por el puerto 443, teclea lo siguiente en la terminal:
    cd /etc/apache2/sites-available
    gedit tusitio.com.conf
  2. Sustituye el contenido del fichero de configuración por lo siguiente:
    RewriteEngine on
    RewriteCond %{SERVER_NAME} =tusitio.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

    Guarda el fichero y reinicia apache
    sudo service apache2 reload

    Con esto, cualquier visitante a tu sitio web será redireccionado a la versión segura.
  3. Si tu sitio está construido con WordPress, tendrás que cambiar la configuración para evitar que el navegador te alerte de que estás ofreciendo contenido inseguro (el candado se verá tachado y/o de color naranja, según el navegador). Ve a la administración de WordPress y en “Ajustes”, cambia la URL del sitio añadiendo “https”.
  4. En función del “Theme” que estés utilizando, es posible que te salga el mismo mensaje de alerta. Revisa que todas las imágenes y URL’s introducidas en las opciones de personalización del Theme comienzan por “https”.
  5. Como apunta Manuti en su comentario, aún pueden quedar elementos que realicen llamadas hacia fuera sin usar https (puede ser el caso de algunos plugins). Estas llamadas se realizan o bien desde el código fuente del sitio web, bien desde su base de datos. Para solucionar los enlaces incorrectos en el código fuente hacemos lo siguiente:
    cd /var/www/tusitio.com
    grep -lir “http://tusitio.com”

    Este comando nos listará los ficheros que contengan un enlace con HTTP. Modificamos estos enlaces por HTTPS.
    Para corregir los enlaces incorrectos que puedan quedar en la base de datos, hacemos lo siguiente:
    mysql -u root -p nombre_de_tu_base_de_datos

    UPDATE wp_options SET option_value = replace(option_value, ‘http://tusitio.com’, ‘https://tusitio.com’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;

    UPDATE wp_posts SET guid = replace(guid, ‘http://tusitio.com’,’https://tusitio.com’);

    UPDATE wp_posts SET post_content = replace(post_content, ‘http://tusitio.com’, ‘https://tusitio.com’);

    UPDATE wp_postmeta SET meta_value = replace(meta_value,’http://tusitio.com’,’https://tusitio.com’);

Y esto es todo. Ya tienes tu sitio web securizado con HTTPS.

Cambiando la ubicación de los contenidos multimedia en Plex

Paso a paso para no perder la indexación de los contenidos multimedia

Migrar contenido multimedia en Plex
Cuando migré MartinServer a un Hp Proliant G8 mantuve temporalmente todos mis contenidos multimedia en las dos NAS  Western Digital de de 3 TB y  de 6 TB que venía utilizando hasta entonces. Pero las bibliotecas de Plex (películas, series, fotos y música) habían crecido exponencialmente desde la primera instalación del Servidor Plex, y por tanto había llegado la hora de migrarlos a los dos discos de 6TB que había añadido al servidor HP Proliant G8.

La forma fácil

El procedimiento viene bien explicado en las páginas de soporte de Plex. Si lo que necesitas es solamente cambiar el contenido a un nuevo disco, la forma más sencilla es ponerle exactamente el mismo nombre al nuevo disco, y conservar la misma ruta de acceso para todos los contenidos. El procedimiento en Ubuntu sería algo así:

  1. Tienes que detener el servidor Plex. Abre una terminal y teclea:
    sudo service plexmediaserver stop
  2. Cambiamos el nombre del disco actual. Por ejemplo, si se llama “Plex”, lo renombramos a “PlexAntiguo”. En el terminal:
    sudo mv /media/Plex /media/PlexAntiguo

    Suponiendo que la partición del disco sea /dev/sdb1, tecleamos:
    sudo mount /dev/sdb1 /media/PlexAntiguo
  3. Ahora montamos el nuevo disco y le ponemos el mismo nombre que al original (en este caso, “Plex”):
    sudo mkdir /media/Plex

    Suponiendo que la partición del nuevo disco sea /dev/sdb2 (esto lo comprobamos con el comando “fdisk -l”), tecleamos:
    sudo mount /dev/sdb2 /media/Plex

    Añadimos el nuevo disco a fstab para que se monte al inicio:
    sudo nano fstab

    Añadimos la siguiente línea a fstab:
    /dev/sdb2 /media/Plex ext4 defaults 0 2

    Si hay una entrada para el disco antiguo en fstab, la eliminamos. Guardamos fstab y actualizamos:
    sudo mount -a
  4. Ya estamos en condiciones de mover todo el contenido del viejo al nuevo disco:
    mv  -v /media/PlexAntiguo/* /media/Plex/

    Si son Terabytes de contenido… paciencia.
  5. Una vez que acabe de moverse todo el contenido, desmontamos el disco antiguo:
    sudo umount /media/PlexAntiguo

    Ya podemos desconectar el disco antiguo. Sólo queda iniciar el servidor Plex:
    sudo service plexmediaserver start

    Y eso sería todo. Debería funcionar con normalidad.

La vía del penitente

Pero en ocasiones esta forma simple no nos sirve. Por ejemplo en mi caso, yo había creado mis bibliotecas de Plex en el NAS de 3TB, y cuando se llenó añadí otro NAS de 6TB. Esto supuso duplicar la estructura de carpetas, solución que no me gustaba nada. Aprovechando el cambio a los dos nuevos discos de 6TB, quería aprovechar para dejar una estructura limpia, algo así:

/Plex/
    /Peliculas/
        /NombredePelicula (año)/
            NombredePelicula (año).ext
            SubtitulodePelicula (año).spa.srt
    /Series/
        /NombreSerie/
            /Temporada 01/
                NombreSerie - s01e01.ext
                SubtituloSerie - s01e01.spa.srt

En este caso, el procedimiento se complica un poco:

  1. Deshabilitar la opción “Vaciar la papelera automáticamente después de cada escaneado”. En la interfaz web de Plex hay que ir a “Ajustes/Biblioteca/” y desmarcar la opción que se reproduce en la imagen:
    deshabilitar-vaciar-papelera
  2. Detener el servidor Plex. Abre una terminal y teclea:
    sudo service plexmediaserver stop
  3. Copiar (no mover) el contenido del viejo al nuevo disco:
    cp -R /media/PlexAntiguo/ /media/PlexNuevo/

    Aquí no tenemos que conservar la misma estructura. Es el paso que podemos aprovechar para reestructurar nuestras bibliotecas.
  4. De nuevo en la interfaz web de Plex, nos vamos a “Librerías/Añadir Biblioteca”. Aquí vamos añadiendo las diferentes bibliotecas de películas, series, música o fotos con la ubicación del disco nuevo:
    añadir-a-la-biblioteca
  5. Una vez que se han añadido todas las nuevas bibliotecas, iniciamos Plex Media Server:
    sudo service plexmediaserver start
  6. Actualiza las bibliotecas desde la interfaz web. Si tienes mucho contenido multimedia, tardará bastante. Cuando termine el proceso, verás que todo el contenido aparece duplicado.
  7. Desde la interfaz web, buscamos las bibliotecas correspondientes al disco antiguo. Seleccionamos “editar” y borramos las carpetas correspondientes al disco antiguo una a una.
    borrar-biblioteca
  8. Volvemos a actualizar las bibliotecas. Ya sólo debe aparecer el contenido del nuevo disco. Para comprobar que no hay errores, utilizamos el filtro de contenidos “buscar duplicados”. Si hay algún duplicado, seguramente se debe a un error de indexación. Editamos manualmente los contenidos mal indexados.
  9. Finalmente, vaciamos la papelera de las bibliotecas.
  10. Y con esto ya está: migrado el contenido de Plex Media Server a un disco nuevo y con una estructura distinta.

Nunca olvides el factor humano

Cómo aprendí de primera mano que no siempre la solución a los problemas de un sistema está en los logs

Limpiando la computadora
Cuando hice la migración de MartinServer ya era consciente de que no había sido todo lo “limpia” que hubiera sido de desear, y me esperaba algunos problemas.
Efectivamente, en los días siguientes vi cómo se producían desconexiones intermitentes. Creí haberlo solucionado, primero, con un script para actualizar FreeDNS, y más tarde, ya de forma más definitiva, solucionando un problema con la interfaz de red.

Problemas menores

En verdad el sistema quedó mucho más estable, ya apenas se producían caídas. Pero persistían algunos problemillas que me traían de cabeza, y me puse a estudiar como loco los logs del sistema para ver de qué coño se trataba. En primer lugar, cada vez que reiniciaba el sistema, se demoraba una eternidad. No era normal. Yo estoy acostumbrado a trabajar con Ubuntu desde hace años y nunca me había pasado nada igual. Por mucho que un servidor HP ProLiant Gen8 sea diferente, no se justificaba.
El otro problema, poco importante pero desconcertante, es que todos los días se desconectaba unos minutos a las 7:00 AM. Yo monitorizo algunos de los sitios web que alojo en MartinServer con una funcionalidad del plugin JetPack para WordPress. Este plugin te avisa si se ha producido una caída en el servicio y durante bastantes días, como digo, puntualmente me llegaba un mensaje a las 7:00 AM. Sólo duraba unos minutos, pero jodía.

Swap

En cuanto al primer problema, lo que me llamó la atención fue este error:

The disk drive for /dev/mapper/ubuntu--vg-swap_1 is not ready yet or not present.

Esto quería decir que el espacio de intercambio o “swap” no era reconocido en el arranque. Con casi toda seguridad era esto lo que estaba enlenteciendo el arranque.
Me llamó la atención la ruta “/dev/mapper/”, es la que se suele utilizar para las particiones encriptadas. Y yo no recordaba haber encriptado mi partición swap. Así que, tecleando blkid en una terminal, comprobé la UUID de la partición swap, y efectivamente no era la que daba el error. Edité fstab:
sudo nano /etc/fstab

Cambié la ruta de la partición swap por la UUID que me había proporcionado el comando blkid. Guardé y reinicié. Problema resuelto, el arranque ya era normal. Y además (y esto ya no sé explicarme por qué), el segundo problema, el de las desconexiones todos los días a las 7:00AM, también desapareció.

Factor humano

Aún quedaba otro problema más pequeño aún, pero me obsesioné con resolverlo. Todos los miércoles por la mañana, el equipo se apagaba. No era una desconexión de red, sino apagado. Mis sitios webs, el accesso SSH y todos los servicios en general eran inaccesibles, pero sí podía acceder a través del interfaz HP iLO, donde veía que el equipo estaba apagado.

Tampoco podía deberse a un corte de electricidad, porque el equipo se reiniciaría solo. No. La única alternativa que me quedaba era, como digo, volver a encender el equipo a través del interfaz HP iLO. Y después todo volvía a funcionar con normalidad, hasta el siguiente miércoles, cuando volvía a pasar lo mismo.

Me quemé las cejas revisando los logs del servidor, para no encontrar finalmente nada. Estas misteriosas caídas del servidor hubieran quedado para siempre sin resolver si no hubiera recordado que lo único que diferencia los miércoles al resto de los días de la semana es que… ¡una chica viene a limpiar la casa por las mañanas!

La llamé. Le pregunté si había tocado el equipo, y me dijo que sí, que por supuesto, que había visto que yo me lo había dejado encendido y que ella lo apagaba. “Por favor, no lo vuelvas a apagar nunca más -le rogué-“. Misterio resuelto. Maldito factor humano 🙂 .