He cambiado de servidor. Realicé una copia de seguridad (completa, con la opción de incluir miniaturas activada) desde la instancia antigua (última versión de Discourse).
Cambié la dirección IP del dominio y luego instalé una nueva instancia de Discourse primero (instalación clásica con Docker).
Después, copié la copia de seguridad a /var/discourse/shared/standalone/backups/default y la restauré desde la nueva instancia.
Todo salió bien, excepto que los temas no tienen ningún mensaje.
El registro parece correcto. Puedo iniciar sesión, todo es normal, excepto que los temas están vacíos.
¿Alguna idea? ¿Dónde debería buscar si hay un problema? ¿Qué debo hacer ahora?
La configuración de CSP se forzó a estar habilitada tras la restauración. Algunos componentes del tema declaraban scripts utilizando una CDN. Esos scripts no estaban en la lista blanca y los mensajes del tema no aparecían debido a errores de JS.
Más seguridad siempre es bienvenida, aunque no esperaba que Discourse cambiara una configuración de copias de seguridad. Puedo entenderlo para instalaciones nuevas, pero no para una restauración de copia de seguridad. Como no se trataba solo de un problema de copia de seguridad/restauración, no se me ocurrió revisar la consola del navegador al principio. Debo confesar que estoy bastante frustrado por haber perdido tanto tiempo, energía y sueño por un problema tan trivial, y porque construir Discourse consume muchísimo tiempo.
Es bueno que hayas encontrado la causa del problema.
Lo consideraría un error si restauraste la copia de seguridad en exactamente la misma versión de Discourse. ¿Fue este el caso? Cuando restauras una copia de seguridad de una versión anterior de Discourse en una versión más reciente, debes esperar que el sistema se comporte de manera diferente.
¿Ya informaste sobre los problemas de CSP a los autores de los componentes del tema? Eso al menos podría evitar que otras personas experimenten el mismo problema.
Probablemente sea más reciente, ya que solo actualizamos cuando hay una nueva versión y al instalar una nueva instancia se obtiene la última versión aprobada en las pruebas.
Bueno, independientemente de si es más antiguo o más reciente, a menos que haya una circunstancia muy especial, en mi opinión, la configuración existente nunca debería modificarse de ninguna manera. Además, partiendo de la misma versión base, espero que mi copia de seguridad tenga el mismo comportamiento. Si acaso, al menos sería bienvenido mostrar una advertencia una vez que te conectes a Discourse (por ejemplo: “por razones de seguridad, la configuración de CSP se ha habilitado”, entiendes la idea) o cualquier otro tipo de cambio.
Piensa en las implicaciones de esto. Lo que deseas requeriría un cambio de dirección a nivel de toda la industria.
Actualmente, lo que se aplica para una actualización in situ también se aplicaría al restaurar una base de datos más antigua. Esto es un comportamiento consistente y predecible para las aplicaciones.
Si no deseas ningún cambio en la configuración, el método normal es utilizar exactamente la misma versión de la aplicación.
Con “última versión” me refería a la última release, no a los últimos commits de la rama test-passed en GitHub. Pero sí, es la misma versión base 2.4.0.beta9.
Solo estamos hablando de copias de seguridad y únicamente de valores de configuración, nada más. La versión de Discourse, los cambios en la base de datos, etc., son irrelevantes. No veo ninguna justificación válida para cambiar un valor de configuración procedente de una copia de seguridad sin notificar al administrador. Tú personalizas Discourse con esos ajustes específicos; no tiene sentido alterar arbitrariamente tusvalores de configuración solo porque estás restaurando una copia de seguridad en una versión más reciente de Discourse.
Como ya se dijo, si el valor de un ajuste específico necesita cambiarse, espero que Discourse informe al administrador de lo que está ocurriendo. Se trata simplemente de ser transparente y facilitar la vida al administrador. Mi punto es que nunca se deben alterar los ajustes del usuario a menos que haya una razón muy buena, y en ese caso, notificar al administrador es lo adecuado.
