Anteriormente, estábamos ejecutando una configuración multisitio de Discourse con alrededor de 22 foros diferentes. Recientemente, decidimos eliminar la configuración multisitio y mantener solo el sitio predeterminado:
Sitio predeterminado ahora:forum.mamapedia.com Dominio multisitio antiguo eliminado:forum.employ.com (y otros 21)
El Problema:
Incluso después de deshabilitar la configuración multisitio, los dominios multisitio antiguos todavía pueden servir el foro predeterminado (forum.mamapedia.com). Por ejemplo:
Visitar forum.mamapedia.com funciona como se esperaba.
Pero visitar forum.employ.com todavía carga el foro de Mamapedia.
Esperábamos que los dominios antiguos como forum.employ.com hicieran una de las siguientes cosas:
Mostraran un error (ya que ya no están configurados).
Redirigieran correctamente o estuvieran completamente inactivos.
Notas de Configuración:
Estamos utilizando certificados SSL de Cloudflare con la opción de proxy habilitada (el tráfico no va directamente a nuestro servidor).
Podemos eliminar los registros A para los dominios antiguos, pero realmente queremos identificar y solucionar la causa raíz en lugar de depender de una solución alternativa basada en DNS.
Pasos Realizados Hasta Ahora:
Eliminamos la configuración multisitio de discourse.conf y la base de datos.
Reiniciamos Discourse y verificamos la configuración de app.yml.
Limpiamos la caché y probamos en modo incógnito.
Comportamiento Esperado:
forum.mamapedia.com debería seguir funcionando.
forum.employ.com y otros dominios antiguos no deberían servir el foro de Mamapedia.
Preguntas:
¿Cómo podemos eliminar correctamente los dominios antiguos para que no sirvan el foro predeterminado?
¿Necesitamos ajustar la configuración de Nginx/Traefik, la configuración de Cloudflare, o hay alguna configuración específica de Discourse que hayamos pasado por alto?
Necesitas cambiar a una instalación estándar. Lo que has hecho para que sea multisite es para que el servidor pueda atender una serie de dominios.
Si creas un nuevo servidor y restauras la copia de seguridad, no podrás romper nada, ya que simplemente volverás al antiguo.
La única condición es que debes apuntar el DNS al nuevo servidor mientras reconstruyes, para que pueda obtener un certificado. Y haz que el DNS en Cloudflare sea solo DNS.
La razón por la que esto está sucediendo es simple. Multisite seleccionará un foro en función del nombre de host. Una instalación que no sea multisite aceptará felizmente cualquier nombre de host al que apunte. Así que mientras tengas todos los antiguos nombres de host dirigidos a esa instalación, servirá el resto del sitio en todos esos nombres de host.
[cita=“Abdelrahman MoHamed, post:1, topic:351365, username:Abdelrahman_MoHamed”]
Podemos eliminar los registros A de los dominios antiguos, pero realmente queremos identificar y solucionar la causa raíz en lugar de depender de una solución alternativa basada en DNS.
[/cita]
Tener los registros antiguos apuntando a tu sitio, es la causa raíz.
Limpiar tu configuración antigua no es solo una solución alternativa, es la solución.
OMG. No recuerdo la última vez que estuve en desacuerdo contigo en un hecho. Como regla general, cuando veo tu avatar en un tema en el que he comentado, ¡sé que voy a aprender algo!
Eso es cierto. Afirman, sin embargo, que cambiaron a una instalación estándar. No les creo.
Desde hace varios años (pero creo que desde que Let’s Encrypt estuvo disponible), en una instalación estándar, si accedes a ella a través de cualquier otro nombre de host, se redirigirá (puedes comprobarlo fácilmente usando el número IP y acabo de hacer otra prueba configurando forum.bigmouth.bass en /etc/hosts a una instalación estándar y se redirigió como se esperaba. Si accedes a través de https, que la mayoría de los navegadores hacen por defecto ahora, obtendrás un error de certificado.
Si todo lo que se requería para acceder a tu sitio a través de algún otro nombre de host era DNS, entonces cualquiera podría secuestrar tu sitio creando un registro DNS que apunte a tu sitio.
Creo que esta es la magia:
Mi suposición es que app.yml todavía tiene algo como esto:
Bueno, ¡HOY APRENDÍ que debería actualizar mis datos con más frecuencia! Ese código ha estado ahí desde 2014, así que supongo que he estado viviendo waaay en el pasado.
Hemos revisado app.yml, y no hay configuraciones personalizadas de redireccionamiento ni anulación. Sin embargo, nuestra instancia aún no está redireccionando los nombres de host desconocidos al dominio principal.
Configuración de Nginx: ¿Hay alguna forma de verificar si la lógica de redireccionamiento del archivo templates/web.ssl.template.yml se está aplicando realmente? ¿Deberíamos verificar manualmente la configuración generada de Nginx dentro del contenedor?
Depuración de Discourse: ¿Existen registros o comandos que podamos ejecutar dentro del contenedor para confirmar que Discourse está manejando correctamente los nombres de host?
Otras causas potenciales: Si app.yml está limpio, ¿qué más podría impedir el comportamiento de redireccionamiento esperado? ¿Podría Cloudflare u otra configuración estar interfiriendo?
¡Agradecería cualquier consejo para investigar más a fondo esto!
¿Todos los dominios antiguos tienen activada la nube naranja? ¿Desactivar la nube naranja soluciona el problema? Si es así, como siempre esperé, Richard tiene razón y necesitas limpiar tu configuración.
Pero si usar Cloudflare permite que un actor malintencionado (tú en este caso) sirva el sitio de otra persona en su dominio, eso parece un problema.
Ya eliminamos dominios antiguos, pero sí, tenían el botón naranja habilitado. El problema ahora es que si alguien obtiene la IP de nuestro servidor y un registro A allí con la opción de proxy habilitada, servirá nuestro sitio con su dominio.
Deberías ejecutar discourse-setup para asegurarte de que realmente tienes una instalación estándar. Si pegas tu antiguo app.yml, podrías tener algo ahí que no pertenece. Todavía no estoy del todo convencido de que tengas una configuración estándar.
Todavía no estoy convencido de que ese sea el caso, pero si lo es, no hay nada que puedas hacer al respecto.
Realmente quiero agradecerles @pfaffman@RGJ, ahora está limpio y casi bien
El problema que enfrentamos ahora es que todas las imágenes de marca han desaparecido y lo mismo ocurre con las imágenes de algunos usuarios.
Los datos de marca están bien, puedo descargarlos del servidor antiguo, pero ¿qué pasa con las imágenes de los usuarios y todas las imágenes del sitio también faltan?
Hmm. Bueno, si fuera el sitio principal, esperaría que esa ruta fuera https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, pero eso tampoco funciona.
Si todavía tienes el sitio antiguo, haría una copia de seguridad de este y la restauraría en el sitio nuevo.
Gracias @pfaffman, lo que he hecho hasta ahora parece estar funcionando.
Entré al servidor antiguo y moví los datos de /var/discourse/shared/standalone/uploads/default a la misma ruta en el servidor nuevo y todos los avatares y publicaciones de los usuarios volvieron.
El nuevo problema es que la marca del sitio no funciona, incluso si intento actualizarla.
Volviendo aquí para ver si alguien tiene alguna idea. Estamos muy cerca de cerrar esto por nuestra parte, solo necesitamos algo de ayuda para solucionar el problema de guardado ‘sin logo’. ¡Gracias de antemano por cualquier idea para resolverlo!
