Hacer que la información perdure

Llevo ya años estudiando y escribiendo sobre la historia de mi familia y sobre la mia propia, sobre Margudgued, sobre algunos objetos antiguos recuperados pero sobre todo de la genealogía de mis apellidos.

Cuando me muera, para lo cual aun falta mucho, no quiero que se pierda todo este esfuerzo e ilusión que he puesto durante todo este tiempo así que he preparado un plan para que la información perdure para siempre. Hoy en día toda esta información la tengo distribuída en cuatro soportes separados: Google (para fotografías, fuentes, documentos y escaneados), AWS (para albertsampietro.com), Tribalpages (para mi árbol genealógico y algunas fotografías más) y papel (documentos físicos, fotografías y la revista que escribía cuando era pequeño «Exper»).

El problema es que los tres primeros soportes (Google, AWS y Tribalpages) son servicios son de pago y en el momento en que la suscripción deje de abonarse, los datos serían borrados así que este es el plan que he ideado:

1. Libro físico. Tengo pensado transcribir todos los posts de mi blog a un documento Word, convertirlo en un libro y editarlo. También añadiré buena parte de los artículos que escribí antes de que existieran los blogs en mi revista personal que se llamaba «Exper-87» y posteriormente solamente «Exper» y que mantuve en activo desde 1987 hasta 1995 aproximadamente. En dicho libro también me gustaría añadir el árbol geneálogico de mi familia.

La idea seria regalar una copia del libro a varias personas de la familia y amigos para que hubiera copias redundantes. Probablemente, un libro bien editado sea el soporte que asegura una mejor conservabilidad más allá de soportes digitales que podrían quedar obsoletos en 40 o 50 años.

2. Memoria USB. Ahora mismo, en total, tengo generados unos 300 GB de información ordenada y clasificada y me gustaría símplemente grabar varias memorias USB para regalar a miembros de mi familia y amigos. Utilizando este soporte puedo poner mucha más información que en un libro aunque existe el problema de que se pierda o que deje de funcionar en unas cuantas décadas.

En todo caso me gustaría hacer algo bonito como crear una funda con forma de libro dentro del cual estuviera la memoria con algunos datos escritos a modo de ayuda o algo similar. Tengo claro que si voy repartiendo memorias USB, con lo pequeñas que son, en tres días se habrán perdido todas.

Además de toda la información, documentos y fotografías que tengo en Google, también volcaría una copia de seguridad de mi árbol genealogico en el formato estándar GEDCOM.

3. Información en objetos. Muchos de los objetos que me rodean y algunos de los libros que he leído, los tengo etiquetados actualmente con un código QR que al ser escaneado con un teléfono te lleva a la página con su historia o comentario dentro de albertsampietro.com. El problema es que cuando deje de pagar a AWS y mi dominio, toda esta información dejará de estar disponible y los códigos QR se volverán inútiles y de nada servirá que los haya impreso en etiquetas de larga duración y resistentes a productos químicos varios, altas temperaturas y a los impactos físicos. He utilizado para ello una impresora de transferencia térmica Brother P-Touch P-750W y etiquetas TZ Tape (actualmente las TZe-241).

La idea no era mala pero a no ser que pueda poner toda la información en el propio objeto de nada servirá. Podría hacerlo utilizando códigos datamatrix, pero la verdad es que ocupan casi más que imprimiendo el texto directamente así que esto es lo que haré.

El tema es pues decidir que impresora tengo que comprarme para comenzar a pegar etiquetas, de al menos 10 cms de ancho y alta durabilidad a algunos objetos antiguos recuperados de mis padres y abuelos, para que generaciones posteriores sepan de donde salieron y a quien pertenecieron.

Actualizar PHP en Lightsail para WP

Si hace ya tiempo que instalaste tu instancia de AWS Lightsail para WordPress, es muy posible que tengas un mensaje que te taladra la cabeza cada vez que accedes al escritorio de WordPress…

Obviamente no puedes irte a dormir tranquilo con este mensaje cuando te ha salido 60 veces. Así que una noche de sábado de esas en las que has hecho una buena siesta por la tarde y los niños ya están durmiendo es ideal para realizar la actualización de PHP en mi instancia de Lightsail en AWS.

Lo primero que hay que saber es que no hay un botón de «Actualiza PHP a la versión X» en Lightsail, WordPress o Bitnami ni ningún script que te permita ejecutar la actualización desde línea de comandos.

Puestos a buscar por la web, di con una de las pocas páginas donde explican como actualizar PHP sin migrar la instancia, Upgrade PHP on Bitnami WordPress without Migration, y francamente vi claro que quizás no era el mejor camino porque tenías que lanzar un montón de scripts directamente a producción.

La solución que decidí finalmente fue bastante sencilla y consistió en hacer una copia de seguridad de la instancia actual en Lightsail, crear una nueva instancia (donde Bitnami ya instala la versión 8.2 de PHP junto con la 6.5 de WordPress), instalar el certificado SSL, cambiar la IP en el gestor de dominios e importar los datos de la copia de seguridad que habíamos creado. Por último, borré la vieja instancia después de comprobar que todo funcionaba correctamente. Al final fue una hora y poco lo que tardé en todo el proceso.

Si necesitas algo más de información con los pasos intermedios, puedes utilizar esta pequeña guía que es sencilla pero detallada: Updating PHP version on Bitnami WordPress.

Como renovar un certificado de Let’s Encrypt de Bitnami en una instancia de Lightsail

La verdad es que no se si lo he hecho bien o no, pero como mínimo se ha renovado el certificado SSL en mi instancia de Lightsail en AWS en la que tenía previamente instalado un certificado utilizando bncert-tool.

Los pasos a seguir son bastante sencillos y basta con conectarse a la cónsola de la instancia y ejecutar desde la línea de comandos de linux las siguientes tres instrucciones:

sudo /opt/bitnami/ctlscript.sh stop

sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/opt/bitnami/letsencrypt" renew --days 90

sudo /opt/bitnami/ctlscript.sh start

Se debe sustituir EMAIL-ADDRESS con el email de notificación que se quiere utilizar y DOMAIN con el dominio a securizar. En mi caso solamente poniendo «dominio.com» me ha actualizado también «www.dominio.com».

Activar eMail en WordPress para AWS Lightsail

Cuando instalamos WordPress en AWS Lightsail no disponemos de un servidor de correo electrónico que se active con un click y por tanto tendremos que instalar o conectar uno de forma manual.

En mi caso me he decantado por la instalación del plugin WP Mail SMTP que permite enviar emails con diferentes tipos de mailers, siendo uno de los más rápidos y baratos el de Google. Estos son los pasos que hay que realizar para activarlo:

    • Una vez que estamos conectados a la cuenta de Gmail que queremos utilizar, entraremos en la cónsola de Google Cloud Platform.
    • Creamos un nuevo proyecto desde Select a Project > New Project.
    • Cuando se haya creado, lo seleccionamos.
    • En el buscador de la cónsola de Google Cloud Platform buscamos «gmail» y seleccionamos «Gmail API».
    • Pulsamos sobre «ENABLE».
    • Una vez dentro pulsamos sobre «CREATE CREDENTIALS» en la parte superior derecha de la pantalla.
    • A partir de aquí podemos seguir las instrucciones de WP Mail SMTP.

Al finalizar todas las configuraciones podemos enviar un email de prueba desde el menú de configuración de WP Mail SMTP en WordPress para verificar que todo funciona correctamente.

Forzar redirección a https en WordPress Multisite desde AWS LightSail

En general, añadir un certificado a un WordPress y forzar la redirección de hhtp a https es bastante fácil ya que basta con ejecutar el script de Bitnami «sudo /opt/bitnami/bncert-tool«. Una de las opciones que ofrece dicho script es la de redireccionar a https pero en el caso de WordPress Multisite, no se soporta por lo que hay que buscar otra solución.

Esta solución es realizar la redirección a través de Apache modificando el archivo de configuración de hosts virtuales y seguir las instrucciones de Force HTTPS Redirection With Apache.

En mi caso, y después de asegurarme que tenía que aplicar la opción A (Approach A: Bitnami Installations Using System Packages») modifiqué los siguientes cuatro archivos:

/opt/bitnami/apache2/conf/bitnami/bitnami.conf
/opt/bitnami/apache2/conf/bitnami/bitnami-ssl.conf
/opt/bitnami/apache2/conf/vhosts/wordpress-https-vhost.conf
/opt/bitnami/apache2/conf/vhosts/wordpress-vhost.conf

La edición de los archivos la hice con VIM desde línea de comandos y antes de los cambios realicé backups de los cuatro archivos.

Finalmente reinicié la instancia de LighSail donde tengo instalado WP Multisite. Para verificar su funcionamiento, desde el browser tecleé el dominio y automáticamente se cambió a https. Hice lo mismo desde el teléfono para asegurarme.

Cambiar la URL en WordPress con SSH y VIM

Dejando de lado todo el proceso de creación de la URL, configuración de las Hosted Zones y cambios de DNS que es bastante trivial, especialmente si sabes hacerlo, uno de los puntos donde podemos quedar parados es en la página de configuración de WordPress a la hora de cambiar las direcciones. El problema suele ser que no es posible hacerlo desde la propia página y tenemos que ir a cambiar los parámetros al archivo wp-config.php.

Este paso es especialmente crítico cuando añadimos un certificado SSL para securizar nuestra página porque aunque parezca que funciona bien y que aparece el candado junto a la URL en nuestro navegador, el cambio no estará perfectamente finalizado hasta que tengamos las URLs actualizadas en wp-config.php mostrando https en vez de http.

Si disponemos de una conexión SSH, como en mi caso donde utilizo Lightsail de AWS en una instancia de Linux, podemos hacer el cambio usando el editor VIM y realizando los siguientes pasos:

      • Conectar a la cónsola de Linux con SSH
      • Ir al directorio apps/wordpress/htdocs/
      • Abrir el archivo con vim wp-config.php
      • Localizar las líneas define(‘WP_SITEURL’, ‘http://’ . $SERVER[‘HTTPHOST’] . ‘/‘); y define(‘WP_HOME’, ‘http://’ . $SERVER[‘HTTPHOST’] . ‘/‘);
      • Cambiar el texto en rojo con las nuevas URLs o símplemente añadir S al http si hemos instalado un certificado SSL
      • No olvidarse de añadir / al final de la URL.
      • Una vez realizado el cambio, tenemos que pulsar la tecla ESC y después teclear :wq para grabar y salir.
      • Finalmente cerramos la sesión SSH y ya debería estar hecho el cambio.

Si no queremos utilizar VIM, otra opción es hacerlo a través de FTP, accediendo al archivo y modificándo el archivo.

Scripts Básicos en Bitnami

El título, para ser preciso, debería ser algo así como «Comandos y scripts básicos para Bitnami si utilizas Lightsail en Amazon Web Services cuando instalas blueprints , por ejemplo, de WordPress o Magento» pero obviamente era muy largo. Sin embargo, y en términos generales, estos scripts también funcionarán fuera de AWS para otros proveedores de hosting que utilicen Bitnami.

Yo diría que los 3 comandos que tenemos que tener más a mano cuando realizamos la instalación de una de sus más de 130 aplicaciones que tienen en catálogo son los siguientes:

Recuperar usuario y contraseña después de la primera instalación cat ./bitnami_credentials
Instalar certificado SSLsudo /opt/bitnami/bncert-tool
Eliminar el banner inferior derecho de Bitnami de nuestras instalacionessudo /opt/bitnami/apps/APPNAME/bnconfig.disabled –disable_banner 1

Donde APPNAME se tiene que sustituir por el directorio donde está instalada nuestra aplicación. Generalmente será WordPress, Magento, etc…

En algunas instalaciones puede ser «bnconfig» en vez de «bnconfig.disabled».

Cada uno de ellos puede requerir algunos pasos o preguntas pero en general su ejecución es bastante sencilla.

Hosted Zones en Route 53

Cuando registras dominios con AWS y quieres vincularlos a instancias de EC2 o Lightsail, tienes que crear «Hosted Zones» utilizando Route 53. Una Hosted Zone tiene diferentes «Record Sets» y hay que ser cuidadoso para crearlos bien, especialmente en lo referente a los prefijos «www.» u otros.

En mi caso, estos son los Record Sets que tengo creados:

Una mala configuración puede hacer que nuestra web funcione mal e incluso que deje de funcionar si instalamos un certificado SSL y redirigimos tráfico de «www.» al dominio simple.

No hace falta decir que la IP, en mi caso la 3.127.33.7, tiene que ser fija.