Nom d'hôte fantôme après changement de nom d'hôte

Bonjour, nouvel utilisateur Discourse hébergé. :wave:

Énoncé du problème :

  1. Après l’installation et la configuration, j’ai changé le nom de domaine après avoir effectué toutes les modifications nécessaires. (Cloudflare DNS, app.yml, nom d’hôte du droplet, nouveaux certificats SSL, redémarrage de Docker, etc., etc., etc.)
  2. Tout fonctionnait bien
  3. Jusqu’à : L’activation des sauvegardes S3 génère une erreur 500 lors de la visite de /admin/backups
  4. /admin/logs signale certificate verify mismatch (Hostname mismatch)
  5. Le retour aux sauvegardes locales fonctionne parfaitement.

Question :

  • Où le nom d’hôte d’origine pourrait-il se cacher ? Je sais que vous ne pouvez pas me dire ce que j’ai oublié, alors peut-être pouvez-vous énumérer où se trouvent ces paramètres.

Pour information :

Seahorse::Client::NetworkingError (SSL_connect returned=1 errno=0 peeraddr=162.243.189.2:443 state=error: certificate verify failed (Hostname mismatch))
lib/s3_helper.rb:426:in `s3_bucket'
lib/s3_helper.rb:240:in `list'
lib/backup_restore/s3_backup_store.rb:122:in `unsorted_files'
lib/backup_restore/backup_store.rb:23:in `files'
app/controllers/admin/backups_controller.rb:24:in `block (2 levels) in index'
app/controllers/admin/backups_controller.rb:13:in `index'
app/controllers/application_controller.rb:412:in `block in with_resolved_locale'
app/controllers/application_controller.rb:412:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:71:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:368:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:23:in `call'
lib/middleware/request_tracker.rb:202:in `call'

Voir Changer le nom de domaine ou renommer votre Discourse. Assurez-vous que Cloudflare est en mode DNS uniquement.

1 « J'aime »

Merci Jay pour le lien. Je n’avais pas encore trouvé ce sujet. :slight_smile:

Sur la base de vos commentaires et de ce sujet lié, j’ai :

  1. Désactivé Cloudflare et confirmé via DNSChecker.org que mes enregistrements A pointent vers l’IP de mon droplet DO
  2. Revérifié mon app.yml (il était correct)
  3. Accédé au conteneur de l’application et exécuté discourse remap de l’ancien au nouveau nom de domaine et cela a apporté des modifications. Pour confirmer, je l’ai exécuté une deuxième fois et il s’est terminé sans modifications
  4. Utilisé grep récursif pour rechercher à l’intérieur et à l’extérieur du conteneur de l’application l’ancien nom de domaine et je n’ai rien trouvé
  5. Reconstruit l’application et étudié la commande docker run. Je n’ai trouvé aucun problème.
  6. Accédé à mon administration et changé la sauvegarde de locale à S3
  7. Continué à recevoir l’erreur 500 comme avant. :crying_cat_face:
  8. Remplacé la sauvegarde par locale et tout est redevenu normal.
  9. Activé Cloudflare et confirmé qu’il proxy à nouveau

Je me sens bloqué et je suis essentiellement :man_shrugging:

Rasoir d’Ockham

Résolu :

  • Sur /admin/site_settings/category/files
  • Le point de terminaison s3 ne doit pas inclure le nom du bucket :person_facepalming:

Assez évident rétrospectivement

2 « J'aime »

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