Gairebé per casualitat he vist que en consultar algunes entrades s’entrava a un bucle de redireccions (errors 301 del servidor).

Primer he pensat que era un problema de la configuració del nginx, atès que hi tinc algunes redireccions definides (del domini antic al nou). Després de fer unes quantes proves m’he convençut que això estava bé i el problema havia de ser a les entrades mateix.

En efecte, WordPress té un mecanisme per si fas canvis en la URL d’una entrada: desa la part final de la URL antiga en una metadada (meta_key de tipus _wp_old_slug), i la fa servir per trobar les entrades si hom les consulta amb la URL antiga. Les entrades que donaven errors tenien el mateix a aquesta meta_key que a la URL vigent.

He esborrat les _wp_old_slug d’aquestes entrades, i ja funciona correctament.

No sé quan s’ha introduït aquest mecanisme, o si l’han canviat en versions recents i hi han incorporat un error de funcionament.

Des d’avui el web té també adreça i nom (registre AAAA) ipv6. Em temo que només fan servir v6 els grans serveis (cercadors, etc).

A casa, tot i tenir una connexió de fibra nova i que el router sembla preparat, només tinc ipv4.

13/2/2016: He canviat el servidor a un VPS d’un altre proveïdor i el web respon només a algunes peticions ipv6. Sospito d’un problema amb la xarxa de comunicacions/encaminador del proveïdor del servidor, però em cal investigar-ho una mica més a fons. De moment hi he perdut un matí fins que he vist que era un problema intermitent.

Des de fa vuit dies tinc connexió per fibra òptica a casa, amb Movistar. Un gran pas endavant de velocitat de baixada i, sobretot, de pujada: ara puc fer servir determinats recursos del núvol a una velocitat molt còmoda.

Amb l’ADSL d’Orange tenia IP variable, però amb un temps de vida prou llarg perquè a la pràctica fos fixa. Amb la fibra la IP del router canvia a cada reinici de l’aparell (o apagada de llum). He mirat el preu de la IP fixa: uns 18 €/mes, un veritable abús.

Seguiré amb la IP volàtil i, si cal, m’espavilaré amb un dels serveis que permeten associar un nom de màquina a la IP de forma dinàmica (dynDNS, no-ip, zoneedit, etc.) suportats pel router.

El 28 de setembre el blog m’ha començat a donar error 500 (error intern del servidor), i he vist que és cosa de la memòria cau del servidor (faig servir WP Super Caché): les pàgines de la memòria cau estan gravades amb l’error 500 al disc.

Després de diverses comprovacions (inspecció dels logs, consultes als cercadors) no trobo la causa del problema i les proves típiques (reiniciar servidor web, desinstal·lar i tornar a instal·lar WP Super Caché) opto per canviar-lo i fer servir el sistema de memòria cau que té nginx.

Per la configuració m’he basat en el que diuen en aquestes dues pàgines:

• rtCamp: fastcgi_cache with conditional purging
• DigitalOcean: How to Setup FastCGI Caching with Nginx on your VPS

5/10/2015: Les cerques no funcionen. 21:30: Arreglat, era un detall de la configuració de Nginx (un canvi de darrera hora de diumenge).

Els usuaris que tinguin llicència d’Office 365 ja poden instal·lar-se Office 2016. També està disponible la interfície d’usuari en català, si bé requereix la instal·lació d’un segon fitxer.

Pel que he llegit han potenciat força les funcionalitats col·laboratives.

També he vist que les paraules del primer nivell del menús (per exemple, Fitxer, Inici, etc. en el Word) tornen a tenir en majúscula només la primera lletra. A la versió 2013 hi havia un FITXER, INICI, etc., tot en majúscules, molt lleig.

Tinc una base de dades (MySQL) en un servidor en què em connecto a través d’un túnel SSH, per xarxa local o a través d’internet. Les màquines fan servir FreeBSD.

He buscat informació sobre quins algorismes de xifratge es recomanaven, i si era avantatjós comprimir les comunicacions. Com s’esdevé sovint en temes semblants no hi ha solucions úniques, així que he decidit fer les meves proves.

Metodologia

Defineixo dues proves:

• Prova 1: select a base de dades que retorna uns 558 registres, i recuperació de tots els registres amb un cursor.
• Prova 2: Recuperació dels 80 primers registres, però amb 80 select independents que retornen 1 registre cada una.

Executo les dues proves amb 6 algorismes de xifratge, primer sense compressió i després amb compressió. I repeteixo tot el cicle 10 vegades. Al final tinc 10 temps amb compressió i 10 sense per cada algorisme i per cada prova.

Codifico totes les proves amb Python.

Resultats

Amb accés a través d’internet (t1=prova 1, t2=prova 2, temps mínim, mitjana de les 10 proves i temps màxim; False i True fan referència a la compressió).

Amb accés a través de xarxa local:

Amb això trio:

• Per internet: blowfish-cbc amb compressió. Era previsible que la compressió ajudaria.
• Per xarxa local: chacha20-poly1305@openssh.com sense compressió.

Les conclusions són vàlides per la prova descrita, orientada a l’ús que faig d’aquesta connexió. Per un sistema que hagués de transmetre grans volums de text, per exemple, la compressió en xarxa local podria ser útil.

En tot cas, sempre que sigui possible, és recomanable provar diferents alternatives abans de decidir.

Un dels avantatges de la virtualització de maquinari és la flexibilitat per a fer proves i canvis: només cal fer una còpia de la màquina abans d’aplicar el canvi, amb la seguretat que, si alguna cosa falla, es pot tornar enrere d’una manera fàcil.

Aquesta tarda ho he fet per canviar aquest servidor a FreeBSD 10.2, que es va publicar ahir:

• snapshot inicial (és a dir, fer una còpia de tota la màquina). Uns 5 minuts d’aturada.
• Així que s’arrenca el servidor inicio el procés d’actualització del sistema operatiu (freebsd-update -r nom-de-la-versió upgrade). Això analitza l’ordinador, recull el programari de la xarxa i informa de quins canvis es faran.
• Cal invocar freebsd-update install per actualitzar el kernel, i tot seguit s’ha de reiniciar el servidor. Un minut més d’aturada.
• Cal tornar a invocar freebsd-update install per aplicar tots els altres canvis.

Total, uns vint minuts de feina. A ximple vista tot funciona,