Les anciens domaines Multisite servent toujours le forum par défaut après avoir désactivé Multisite

[Abdelrahman_MoHamed]

Nous exécutons précédemment une configuration multisite Discourse avec environ 22 forums différents. Récemment, nous avons décidé de supprimer la configuration multisite et de ne conserver que le site par défaut :

Site par défaut maintenant : forum.mamapedia.com
Ancien domaine multisite supprimé : forum.employ.com (et 21 autres)

Le Problème :

Même après avoir désactivé la configuration multisite, les anciens domaines multisite peuvent toujours servir le forum par défaut (forum.mamapedia.com). Par exemple :

• Visiter forum.mamapedia.com fonctionne comme prévu
• Mais visiter forum.employ.com charge toujours le forum Mamapedia

Nous nous attendions à ce que les anciens domaines comme forum.employ.com :

1. Affichent une erreur (puisqu’ils ne sont plus configurés)
2. Redirigent correctement ou soient complètement inactifs

Notes de Configuration :

• Nous utilisons les certificats SSL de Cloudflare avec l’option proxy activée (le trafic ne passe pas directement par notre serveur).
• Nous pouvons supprimer les enregistrements A pour les anciens domaines, mais nous voulons vraiment identifier et corriger la cause profonde au lieu de nous fier à une solution de contournement basée sur le DNS.

Étapes Suivies Jusqu’à Présent :

1. Suppression des paramètres multisite de discourse.conf et de la base de données
2. Redémarrage de Discourse et vérification des paramètres app.yml
3. Vidage du cache et test en mode incognito

Comportement Attendu :

• forum.mamapedia.com devrait continuer à fonctionner
• forum.employ.com et les autres anciens domaines ne devraient pas servir le forum Mamapedia

Questions :

1. Comment pouvons-nous supprimer correctement les anciens domaines afin qu’ils ne servent plus le forum par défaut ?
2. Devons-nous ajuster les paramètres Nginx/Traefik, les paramètres Cloudflare, ou y a-t-il une configuration spécifique à Discourse que nous avons manquée ?

Configuration Nginx

[pfaffman (Jay Pfaffman)]

Vous devez passer à une installation standard. Ce que vous avez fait pour rendre cela multisite, c’est pour permettre au serveur de servir plusieurs domaines.

Si vous créez un nouveau serveur et restaurez la sauvegarde, vous ne pouvez rien casser puisque vous reviendrez simplement à l’ancien.

Le seul problème, c’est que vous devez diriger le DNS vers le nouveau serveur pendant que vous le reconstruisez afin qu’il puisse obtenir un certificat. Et configurez Cloudflare DNS en mode uniquement.

[Abdelrahman_MoHamed]

Merci @pfaffman , Nous avons tenté de passer d’une configuration multisite à une installation standard, mais le problème persiste.

Ce que nous avons fait :

1. Suppression de l’installation Discourse :
   • Suppression complète du répertoire /var/discourse.
2. Réinstallation de Discourse :
   • Clonage à nouveau du dépôt Discourse.
   • Recréation de app.yml avec les configurations nécessaires.
3. Reconstruction de l’application :
   • Exécution de ./launcher rebuild app.
4. Mise à jour du DNS :
   • Pointage du domaine vers le nouveau serveur.
   • Mise de Cloudflare en mode DNS-only pour permettre l’émission du certificat SSL.

Problème supplémentaire avec le SSL :

• Lorsque nous avons activé le SSL dans app.yml et désactivé le proxy Cloudflare, nous avons rencontré le problème suivant, même après avoir activé le SSL.

Questions :

1. Le problème pourrait-il être lié à la non-restauration d’une sauvegarde de base de données ?
2. Y a-t-il des étapes supplémentaires nécessaires pour nettoyer les anciennes configurations multisite ?
3. Quelle est la bonne façon d’activer le SSL dans cette configuration sans rencontrer de problèmes ?

Toute aide de ceux qui l’ont déjà fait serait appréciée !

[pfaffman (Jay Pfaffman)]

@Abdelrahman_MoHamed

app.yml recréé avec les configurations nécessaires.

Avez-vous exécuté discourse setup ou l’avez-vous fait manuellement ?

Avez-vous les modèles ssl et let’s encrypt ?

Si vous avez exécuté des rebuilds un grand nombre de fois avec le nuage orange, vous pourriez être limité par le débit.

[RGJ (Richard - Communiteq)]

La raison pour laquelle cela se produit est simple. Multisite sélectionnera un forum en fonction du nom d’hôte. Une installation non multisite acceptera volontiers le nom d’hôte auquel vous la pointez. Ainsi, tant que vous aurez tous les anciens noms d’hôte dirigés vers cette installation, elle servira le site restant sur tous ces noms d’hôte.

@Abdelrahman_MoHamed

Nous pouvons supprimer les enregistrements A des anciens domaines, mais nous voulons vraiment identifier et corriger la cause profonde au lieu de nous fier à une solution de contournement basée sur le DNS.

Avoir les anciens enregistrements pointant vers votre site est la cause profonde.
Nettoyer votre ancienne configuration n’est pas une solution de contournement, c’est la solution.

[pfaffman (Jay Pfaffman)]

OMG. Je ne me souviens pas de la dernière fois que j’ai été en désaccord avec vous sur un fait. En règle générale, lorsque je vois votre avatar dans un sujet sur lequel j’ai commenté, je sais que je vais apprendre quelque chose !

@RGJ

La raison pour laquelle cela se produit est simple. Multisite sélectionnera un forum en fonction du nom d’hôte

C’est vrai. Ils prétendent cependant être passés à une installation standard. Je ne les crois pas.

@RGJ

Une installation non-multisite acceptera volontiers le nom d’hôte auquel vous la pointez.

Depuis plusieurs années maintenant (mais je pense depuis que Let’s Encrypt est disponible), sur une installation standard, si vous y accédez via un autre nom d’hôte, elle effectuera une redirection (vous pouvez facilement vérifier en utilisant le numéro IP et je viens d’en faire une autre en configurant forum.bigmouth.bass dans /etc/hosts vers une installation standard et elle a redirigé comme prévu. Si vous y accédez via https, ce que la plupart des navigateurs font par défaut maintenant, vous obtiendrez une erreur de certificat.

Si tout ce qui était nécessaire pour accéder à votre site via un autre nom d’hôte était le DNS, alors n’importe qui pourrait détourner votre site en créant un enregistrement DNS pointant vers votre site.

Je pense que c’est la magie :

templates/web.ssl.template.yml

Je suppose que le app.yml contient encore quelque chose comme ceci :

@pfaffman

   # ne pas rediriger tous les hôtes vers le nom de domaine principal
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /if \\(\\$http_host[^\\}]*\\}/m
        to: ""
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301.*$/
        to: "return 301 https://$host$request_uri;"

[RGJ (Richard - Communiteq)]

@pfaffman

Je sais que je vais apprendre quelque chose !

Eh bien, j’apprends aujourd’hui que je devrais mettre à jour mes faits plus souvent ! Ce code est là depuis 2014, donc je suppose que je vivais dans le passé.

Vous avez tout à fait raison, cela redirigera.

[Abdelrahman_MoHamed]

Merci @RGJ , @pfaffman ,

Nous avons vérifié app.yml, et il n’y a pas de configurations de redirection personnalisées ni de overrides. Cependant, notre instance ne redirige toujours pas les noms d’hôtes inconnus vers le domaine principal.

1. Configuration Nginx : Existe-t-il un moyen de vérifier si la logique de redirection du fichier templates/web.ssl.template.yml est réellement appliquée ? Faut-il vérifier manuellement la configuration Nginx générée à l’intérieur du conteneur ?

2. Débogage de Discourse : Y a-t-il des logs ou des commandes que nous pouvons exécuter à l’intérieur du conteneur pour confirmer que Discourse gère correctement les noms d’hôtes ?

3. Autres causes potentielles : Si app.yml est propre, qu’est-ce qui pourrait empêcher le comportement de redirection attendu ? Est-ce que Cloudflare ou un autre paramètre pourrait interférer ?

Nous apprécierions toute indication pour approfondir cette investigation !

[RGJ (Richard - Communiteq)]

@RGJ

Nettoyer votre ancienne configuration n’est pas une solution de contournement, c’est la solution.

Voici une piste.

[pfaffman (Jay Pfaffman)]

Les anciens domaines ont-ils tous le nuage orange activé ? Le fait de ne pas utiliser le nuage orange résout-il le problème ? Si c’est le cas, comme je l’ai toujours pensé, Richard a raison et vous devez nettoyer votre configuration.

Mais si l’utilisation de Cloudflare permet à un acteur malveillant (vous dans ce cas) de servir le site de quelqu’un d’autre sur son domaine, cela semble être un problème.

[Abdelrahman_MoHamed]

OK, dois-je exécuter

./discourse-setup

après avoir téléchargé Discourse ou dois-je coller mon ancien app.yml après le téléchargement, puis exécuter

./launcher rebuild app

Quelle voie dois-je suivre ?

[Abdelrahman_MoHamed]

Nous avons déjà supprimé les anciens domaines, mais oui, ils avaient le bouton orange activé. Le problème maintenant est que si quelqu’un obtient notre adresse IP de serveur et un enregistrement là-bas avec l’option proxy activée, il servira notre site avec son domaine.

[pfaffman (Jay Pfaffman)]

Vous devriez exécuter discourse-setup pour vous assurer que vous avez bien une installation standard. Si vous collez votre ancien app.yml, il se peut que vous ayez quelque chose dedans qui n’a pas sa place. Je ne suis toujours pas tout à fait convaincu que vous ayez une configuration standard.

@Abdelrahman_MoHamed

le problème maintenant est que si quelqu’un obtient notre adresse IP de serveur et un enregistrement là-bas avec l’option proxy activée, il servira notre site avec leur domaine

Je ne suis toujours pas convaincu que ce soit le cas, mais si c’est le cas, vous ne pouvez rien y faire.

[Jagster (Jakke Lehtonen)]

@Abdelrahman_MoHamed

si quelqu’un a obtenu l’adresse IP de notre serveur

La plupart des adresses IP de serveurs mondiaux sont publiques. C’est un peu le but du système d’adresses IP.

[Abdelrahman_MoHamed]

Je tiens vraiment à vous remercier @pfaffman @RGJ, maintenant c’est propre et presque bon

Le problème que nous rencontrons maintenant est que toutes les images de marque ont disparu, ainsi que certaines images d’utilisateurs.

Les données de marque sont correctes, je peux les télécharger depuis l’ancien serveur, mais qu’en est-il des images des utilisateurs et de toutes les images du site qui manquent également

Nouveau serveur

Ancien serveur

NOTES :

• nous avons suivi les étapes de migration en exécutant discourse remap sur le même domaine et rake posts:rebake
• Cela pourrait-il être lié à l’historique multisite, auquel cas nous aurions besoin d’un remap spécifique conformément à ce lien
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

Si ce n’était pas le site principal pour le multisite, alors le chemin des téléchargements est le nom et le site et non par défaut.

[Jacob_Peebles]

En regardant les images manquantes, elles semblent avoir une URL « imbriquée », en voici une :

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

Et @pfaffman, c’était en fait le site principal dans la configuration multisite.

CC : @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob_Peebles

/user_avatar/forum.mamapedia.com/

Hmm. Eh bien, si c’était le site principal, je m’attendrais à ce que ce chemin soit https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, mais cela ne fonctionne pas non plus.

Si vous avez encore l’ancien site, je ferais une sauvegarde de celui-ci et la restaurerais sur le nouveau site.

[Abdelrahman_MoHamed]

Merci @pfaffman, ce que j’ai fait jusqu’à présent semble fonctionner.

Je suis allé sur l’ancien serveur et j’ai déplacé les données de /var/discourse/shared/standalone/uploads/default vers le même chemin sur le nouveau serveur, et tous les avatars et messages des utilisateurs sont revenus.

Le nouveau problème est que la personnalisation du site ne fonctionne pas, même si j’essaie de la mettre à jour.

Voici un enregistrement d’écran d’une minute

Screen Recording - Feb 13, 2025

[Jacob_Peebles]

Je reviens ici pour voir si quelqu’un a des idées. Nous sommes très proches de clore ce dossier de notre côté, nous avons juste besoin d’aide pour résoudre le problème de la sauvegarde sans logo. Merci d’avance pour toutes les idées de résolution !