Le DNS du site est propagé mais Discourse refuse la connexion ?

[Heliosurge (Dan DeMontmorency)]

J’ai migré d’Upcloud vers un VPS Contabo. J’ai utilisé Rsync et, en suivant les étapes, j’ai pu reconstruire et confirmer que l’application fonctionnait.

Sujet ici. Ce post a permis de reconstruire correctement le site.

Move a Discourse site to another VPS with rsync

This seems to have worked. And says app is running but not accessible from web. HTTPS://www.xrtropolis.one Could it be not connected yet from the domain server yet? Note:. Think I found it. May have to wait 24 to 72 hours for the IP address change to be fully in effect. [The screenshot explains how long it can take for Squarespace DNS changes to take effect and what to do if an error persists. (Captioned by AI)] This is the connection msg I get. Presume have to…

J’ai modifié les enregistrements DNS sur Squarespace (qui a racheté Google Domains) et j’ai modifié les enregistrements DNS A pour qu’ils pointent vers le serveur de Contabo.

Je peux me connecter en utilisant l’adresse IP, mais lorsque j’utilise le nom de domaine :

Xrtropolis.one

J’obtiens :

On m’a présenté cet outil de site web qui vérifie la propagation des DNS :

DNS Propagation Checker - Global DNS Checker Tool

Dois-je faire quelque chose du côté de Discourse pour qu’il accepte la connexion depuis le nom de domaine ?

Je ne suis pas sûr pour l’installation des tags ou peut-être les outils de migration ?

Je n’utilise pas Let’s Encrypt car Squarespace fournit un certificat SSL et cela fonctionnait bien sur Upcloud.

[Canapin (Coin-coin le Canapin)]

Je pense que si vous exécutez ./discourse-setup, il devrait essayer de se connecter au domaine après vous avoir demandé de le fournir.

Est-ce que cela réussit ?

[Heliosurge (Dan DeMontmorency)]

Non, ceci est une copie de la sortie. Il réussit à se connecter au domaine cependant.

discourse-setup
Le fichier de configuration containers/app.yml existe déjà !

. . . reconfiguraton . . .


Sauvegarde de l'ancien fichier sous app.yml.2025-01-06-030236.bak
Arrêt du conteneur existant dans 5 secondes ou appuyez sur Control-C pour annuler.
Architecture x86_64 détectée.
AVERTISSEMENT : Le fichier containers/app.yml est lisible par tous. Vous pouvez sécuriser ce fichier en exécutant : chmod o-rwx containers/app.yml
+ /usr/bin/docker stop -t 600 app
app

25 Go de mémoire et 8 cœurs de processeur physiques trouvés
définition de db_shared_buffers = 4096 Mo
définition de UNICORN_WORKERS = 8
paramètres de mémoire de containers/app.yml mis à jour.

Nom d'hôte pour votre Discourse ? [www.xrtropolis.one]:
Vérification de votre nom de domaine . . .
Connexion à www.xrtropolis.one réussie.
Adresse e-mail pour le(s) compte(s) administrateur(s) ? [demontmorency_dan@hotmail.com]:
Adresse du serveur SMTP ? [smtp-relay.brevo.com]:
Port SMTP ? [587]:
Nom d'utilisateur SMTP ? [redacted]:
Mot de passe SMTP ? [redacted]:
Adresse e-mail de notification ? [noreply@xrtropolis.one]:
Adresse e-mail facultative pour les avertissements Let's Encrypt ? (ENTRER pour ignorer) [me@example.com]:
ID de compte MaxMind facultatif (ENTRER pour continuer sans la base de données de géolocalisation GeoLite2 MAXMIND) [123456]:

Est-ce que cela vous semble correct ?

Nom d'hôte          : www.xrtropolis.one
E-mail             : demontmorency_dan@hotmail.com
Adresse SMTP      : smtp-relay.brevo.com
Port SMTP         : 587
Nom d'utilisateur SMTP : redacted
Mot de passe SMTP     : redacted
E-mail de notification: noreply@xrtropolis.one
ID de compte MaxMind: (non défini)
Clé de licence MaxMind: (non défini)

ENTRER pour continuer, 'n' pour réessayer, Ctrl+C pour quitter :
web.ssl.template.yml NON ACTIVÉ -- était-il déjà activé ?
letsencrypt.ssl.template.yml NON ACTIVÉ -- était-il déjà activé ?



Malheureusement, une erreur s'est produite lors de la modification de containers/app.yml

Cela peut se produire si vous avez apporté des modifications inattendues.

Cela dit, app.yml semble avoir été modifié même s’il indique une erreur lors de sa modification.

Cependant, je reçois toujours une erreur de connexion refusée, même si la configuration a indiqué qu’elle s’est connectée avec succès.

[Heliosurge (Dan DeMontmorency)]

notes sur les ajouts

Bienvenue sur Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-51-generic x86_64)

 * Documentation : https://help.ubuntu.com
 * Gestion : https://landscape.canonical.com
 * Support : https://ubuntu.com/pro

 Informations système en date du lun 6 jan 04:03:52 CET 2025

  Charge système : 2.52
  Utilisation de / : 4.5% sur 289.56Go
  Utilisation mémoire : 2%
  Utilisation swap : 0%
  Processus : 245
  Utilisateurs connectés : 0
  Adresse IPv4 pour eth0 : 154.53.35.16
  Adresse IPv6 pour eth0 : 2605:a142:2238:3164::1

 * Kubernetes strictement confiné rend l'edge et l'IoT sécurisés. Découvrez comment MicroK8s
   a relevé la barre pour un déploiement de cluster K8s facile, résilient et sécurisé.

   https://ubuntu.com/engage/secure-kubernetes-at-the-edge

La maintenance de sécurité étendue pour les applications n'est pas activée.

0 mises à jour peuvent être appliquées immédiatement.

Activez ESM Apps pour recevoir des mises à jour de sécurité supplémentaires à l'avenir.
Voir https://ubuntu.com/esm ou exécuter : sudo pro status

n’utilise pas kubernetes. copié et installé avec Docker et utilisé rsync.

je me suis dit que les informations d’ubuntu lts 24.04.1 pourraient aider.

[Heliosurge (Dan DeMontmorency)]

Résolu.

Le problème était que quelques modèles étaient commentés : le SSL web et let’s encrypt, même s’ils n’étaient pas utilisés.

Soit une erreur avec rsync, soit autre chose.

Comparaison de l’ancien fichier app.yml du serveur avec le nouveau serveur et correction des entrées.

Tout va bien maintenant.

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.