Ich habe den Namen geändert, da ich den ursprünglichen Server nicht für Stunden herunterfahren kann, bis ich getestet habe, dass alles in Ordnung ist und die Server getauscht wurden.
Das ist nicht nötig. Wenn Sie ein Wildcard-Zertifikat haben, können Sie einfach lokale DNS-Einstellungen über die Hosts-Datei vornehmen, um alles zu konfigurieren und das Backup selbst wiederherzustellen.
Anschließend stellen Sie einfach den öffentlichen DNS-Eintrag um.
Ich verstehe nicht, was du meinst.
Ich muss a.domain.com weiterhin betreiben, während ich die Tests durchführe.
Und ich muss auf die Discourse-Oberfläche der Kopie zugreifen, die ich wiederherstelle, um zu prüfen, ob alles in Ordnung ist.
Daher brauche ich eine andere URL, um auf die Kopie auf dem anderen Server zuzugreifen.
Also ändere ich einfach den Hostnamen in Discourse und Nginx nach der Wiederherstellung.
Wenn alles in Ordnung ist, ändere ich den Namen auf dem neuen Server zu a.domain.com, fahre den alten Server herunter und leite den DNS-Eintrag a.domain.com auf den neuen Server um.
Das ist nicht korrekt. Sie können Ihren lokalen Computer dazu zwingen, über denselben DNS-Namen mit dem neuen Server zu verbinden, entweder indem Sie die HOSTS-Datei auf Ihrem lokalen Computer ändern oder einen Eintrag für Ihren lokalen DNS-Server hartkodieren.
Ich habe keinen lokalen Rechner.
Beide Server sind im Internet, also Cloud-Server.
Ich verwende SSH von einem Windows-Rechner.
Vielleicht könnte ich den lokalen Hostnamen nehmen, um die IP-Adresse des Rechners einzustellen, aber das ist komplizierter als den Namen auf den Servern zu ändern.
Glaubst du, dass eine Änderung des Hostnamens das Problem sein könnte?
Das sollte kein Problem sein…
Ja, wir haben dieses Problem mit benutzerdefinierten Avataren wieder bemerkt, lange nachdem der sidekiq-Prozess Zeit hatte, alle zugehörigen Avatar- und Profilbilder neu zu erstellen. Dies tritt jedoch nur bei der Konfiguration mit dem nginx Reverse Proxy für einen Unix-Domain-Socket auf.
Die kleinen Icon-Avatare funktionieren einwandfrei; sie werden jedoch in der Profil-Karte oder auf den Profilseiten nicht angezeigt (es sei denn, sie wurden bereits zwischengespeichert und der Cache ist noch nicht abgelaufen).
Sobald wir Folgendes ausführen:
nginx -s stop; ./launcher start web-only
verschwindet das Problem mit den benutzerdefinierten Avatarbildern (bei Bildern, die zuvor noch nicht im Browser angesehen oder zwischengespeichert wurden).
Und sobald wir danach Folgendes tun:
./launcher stop web-only; nginx
kehrt das Problem mit den benutzerdefinierten Avatarbildern für Bilder zurück, die noch nicht angesehen oder zwischengespeichert wurden.
Es gibt keine Fehler mit HTTPS, und dies liegt definitiv nicht an force_https (völlig unrelated):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Wir haben dieses Problem auf mobilen Geräten (iOS, neueste Version), auf dem Desktop, in Chrome (neueste Version), in Safari (neueste Version) usw. bestätigt.
Es gibt etwas Seltsames, das beim Einsatz von Nginx als Reverse Proxy für einen Unix-Socket auftritt und die benutzerdefinierten Avatarbilder beeinflusst.
Bislang müssen wir @ariznaf leider mitteilen, dass wir das Problem nicht isolieren konnten und keine Lösung haben.
Es „fühlt sich so an“, als würde in der Konfiguration mit nginx Reverse Proxy für einen Unix-Socket die Discourse-App (der Container) diese benutzerdefinierten Avatarbilder nicht neu erstellen, wie es in der Konfiguration ohne Nginx als Reverse Proxy für einen Unix-Domain-Socket der Fall ist.
Vielleicht mag sidekiq die Konfiguration mit nginx Reverse Proxy für einen Unix-Socket nicht und weigert sich, diesen Neukonstruktionsprozess zu planen oder auszuführen, LOL? @riking?
Seltsam.
Hier ist ein Follow-up:
In der Konfiguration des Reverse Proxys, bei der wir Unix-Sockets verwenden, geht es um Folgendes:
Wenn wir jedoch force_https prüfen:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
Und natürlich, wie erwartet, gibt es keinen Fehler im Browserzertifikat (Chrome ist zufrieden):
Meine unwissende Vermutung ist also, dass bei dieser Konfiguration die force_http-Einstellung bzw. -Methode diese Bilder nicht berücksichtigt; denn alles andere ist fehlerfrei, außer diesen benutzerdefinierten Avataren (und dem Bild auf der Profilseite).
Das ist meine über meinem Gehaltsniveau bei Discourse liegende Vermutung.
Update:
Nach weiterer Recherche stellt sich heraus, dass bei allen unseren nginx-Reverse-Proxy-Konfigurationen zu Unix-Sockets ein Großteil der Dateien unter /shared/uploads fehlte. Dieser Schritt wurde in den verschiedenen Tutorials und How-to-Dokumenten, die ich dazu gelesen habe, nicht erwähnt. Das nächste Mal, wenn ich ein Wiki zu diesem Thema auf Meta sehe, werde ich das Tutorial / Wiki / How-to entsprechend aktualisieren, um diesen Schritt einzufügen.
Das einzige verbleibende kleine Problem betrifft das Favicon:
Falls jemand eine empfohlene Lösung dafür hat, wäre das großartig. Vielen Dank!
Lade es erneut hoch. Das ist die schnellste Lösung.
Menschen vergessen oft, wenn sie einen Socket verwenden, dass sie die HTTPS-Vorlage deaktiviert haben. Daher weiß Discourse nicht, dass es hinter SSL läuft, es sei denn, force_https wird manuell aktiviert – weshalb ich das gestern vorgeschlagen habe.
Sobald force_https aktiviert ist, kannst du die Assets erneut hochladen, um ihre Pfade zu korrigieren.
[quote=“neounix, Beitrag: 27, Thema: 148223”]
Nach weiterer Recherche stellt sich heraus, dass bei allen unseren Konfigurationen für den „nginx Reverse Proxy zu Unix-Socket
Ja … wir haben diesen Leitfaden befolgt, um den Nginx-Reverse-Proxy einzurichten, aber das galt für eine Standalone-Installation und erwähnte nicht die Uploads, da diese im Standalone-Modus nicht übertragen werden mussten:
Und wir haben diesen Leitfaden für zwei Container befolgt, der ebenfalls keine Wiederherstellung der Datenbank oder Übertragung eines Upload-Verzeichnisses erwähnte:
Ich denke, wir können Dinge leicht verstehen. Hier ist der Hinweis, der dir fehlte, um das zu erklären, zur Referenz:
Die wichtigsten Tutorials zu dieser Konfiguration lassen außer Acht, dass man entweder eine Datenbankwiederherstellung durchführen oder die Uploads manuell in den neuen Container übertragen muss, weil wir das nicht enthalten haben.
Selbstverständlich ergibt das jetzt Sinn, nachdem wir das zu 100 % allein herausgefunden haben (wieder einmal!), weil es in den Tutorials nicht steht. LOL
Alles ist einfach, sobald man weiß, was das Problem ist.
PS: Zum Abschluss. Danke an alle, die verschiedene Tutorials geschrieben haben. Sie waren eine große Hilfe! Sehr geschätzt. Von unserer Seite aus ist diese Konfiguration abgeschlossen und wir werden in Zukunft keine Standalone-Konfigurationen mehr auf Discourse-Seiten verwenden. Unser normaler „Standard
Ich weiß nicht, ob das hilfreich ist oder nicht. Die Bildoptimierung schlägt jedoch häufig fehl, wenn der Job, der die Optimierung ausführt, Ihren Server über seinen Internetdomänennamen nicht erreichen kann.
Das könnte erklären, warum dies in einem komplexeren Reverse-Proxy-Setup nicht wie erwartet funktioniert.
Vielen Dank, Kane.
Wie du wahrscheinlich weißt, habe ich nach Alternativen zur Standard-Backup-Methode über die Benutzeroberfläche in Discourse gesucht. Der Grund dafür sind Probleme, die jedes Mal auftreten, wenn ich eine Wiederherstellung mit der Standard-Backup-Methode versucht habe, obwohl ich mich dabei stets an die Anweisungen in den offiziellen Tutorials auf dieser Seite gehalten habe.
Wie ich am Anfang bereits erwähnt habe, habe ich die Wiederherstellung aus einem Backup durchgeführt, das über die UI-Oberfläche und das Standard-Backup- sowie das empfohlene Wiederherstellungsverfahren erstellt wurde.
Der einzige Unterschied zu einer Standardinstallation von Discourse als eigenständiges System besteht darin, dass wir Nginx als Reverse-Proxy verwenden, der über einen Socket mit Discourse verbunden ist.
Das Hauptproblem, das wir festgestellt haben, betrifft Avatare, die anscheinend verloren gegangen und durch das Standardprofilbild ersetzt wurden.
Du hast mir gesagt, dass diese durch den Sidekiq-Job neu erstellt werden müssen. Dieser Job scheint jedoch sofort mit Erfolg (Status OK) abzuschließen, wenn man ihn startet, doch die Avatare bleiben unverändert.
Da Backups für uns sehr wichtig sind (wer könnte sie ignorieren?), werde ich weitere Tests durchführen, dabei besonders sorgfältig die Anweisungen befolgen und andere hier vorgeschlagene Ideen ausprobieren.
Wir sind mit Discourse sehr zufrieden und mögen es sehr. Wir möchten lediglich sicherstellen, dass wir über ein robustes Wiederherstellungsverfahren verfügen, falls es zu einem Angriff (wir haben kürzlich einen erlebt) oder einem Serverausfall kommt.
Wenn du möchtest, dass wir bestimmte Tests durchführen, um dieses Problem zu beheben oder weitere Informationen liefern, bin ich gerne bereit, mein Bestes zu geben und diese Informationen bereitzustellen.
Es scheint sicher, dass das System nicht auf die Avatar-Miniaturen zugreifen kann.
Der Rest des Forums wird jedoch korrekt ausgeliefert. Die Routen, SSL und alles andere sind, soweit ich sehen kann, korrekt konfiguriert. Wäre eine Fehlkonfiguration vorhanden, könnten Sie das Discourse-Forum nicht erreichen und den Rest des Inhalts anzeigen; stattdessen würden Sie Fehler wie 502 erhalten.
@neounix
Wir verwenden S3, da dies die einfachste Methode über die Benutzeroberfläche ist, um Backups an einem externen Standort zu speichern.
Vielleicht ist S3 nicht die beste Option, ich weiß es nicht. Andererseits hat der Ort, an dem die Backups gespeichert sind, nichts mit dem Problem zu tun, da es nicht darum geht, dass man sie nicht erreichen und die Wiederherstellung durchführen kann. Die Wiederherstellung wird korrekt durchgeführt.
@stephan
In der app.yml habe ich die SSL-Vorlage, die LetsEncrypt-Vorlage und den expose-Abschnitt mit den Ports auskommentiert. Der SSL-Teil wird von Nginx übernommen, daher muss der Socket nicht verschlüsselt sein, oder?
Ist das falsch? Sollte ich trotzdem die SSL-Vorlage verwenden?
Ich nehme an, wenn dies das Problem wäre, könnte ich nach der Wiederherstellung keinen Teil des Forums sehen, nicht nur die Avatare, aber wer weiß…
Ich werde weitere Tests durchführen. Vielen Dank an alle für Ihre Hilfe.
@ariznaf … hey!
Die Art und Weise, wie ich dieses Problem auf zwei verschiedenen Servern gelöst habe, bestand darin, das Verzeichnis /shared/uploads manuell vom ursprünglichen Setup auf die socket-only-Setups zu kopieren. Danach war das Problem verschwunden.
Die schnelle Möglichkeit, dies zu überprüfen, bestand darin, die Größe des uploads-Verzeichnisses zu vergleichen, einfach so (vorausgesetzt, du befindest dich in deinem gemeinsamen Verzeichnis):
du -sh uploads
Als ich sie verglichen habe, habe ich herausgefunden, was das Problem war
Vielleicht kannst du das auch überprüfen? Hoffentlich hilft dir das, dein Problem einzugrenzen.
PS: Ich bin nicht negativ gegenüber S3. Wie das Sprichwort sagt: Jeder nach seiner Fasson…
Lassen Sie mich prüfen, ob ich Sie richtig verstanden habe.
Wenn ich Backups erstelle, habe ich geprüft, dass auch die Uploads gesichert werden (nicht die Thumbnails, aber ich habe getestet, dass auch die Thumbnails gesichert werden. Jetzt sichere ich die Thumbnails, sodass Sie nicht auf ein erneutes Rendern warten müssen).
Nach der Wiederherstellung werden auch die Uploads wiederhergestellt.
Meinen Sie, dass die Wiederherstellung der Uploads nicht korrekt funktioniert und Sie dies manuell durchführen müssen?
Wie stellen Sie die Uploads manuell wieder her?
Haben Sie das Backup heruntergeladen und das Verzeichnis shared/standalone/uploads entpackt?
Wenn das der Fall ist (ich werde es versuchen), scheint es mir klar, dass es sich bei der Wiederherstellungsaufgabe um einen Fehler handelt.
Vielen Dank.
Ich suche nach Alternativen für Backups und deren Speicherung, aber die Leute von Discourse bestehen darauf, dass der einzige korrekte Weg die Verwendung des Standard-Backup-Systems ist.
Hallo @ariznaf,
Wir stellen nicht über die Admin-Oberfläche wieder her (wir führen nur über das Webinterface Backups durch, keine Wiederherstellungen). Wir sftp die Datei (inklusive der hochgeladenen Dateien) in den Container und stellen sie wie folgt wieder her:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Als ich jedoch vor Kurzem eine neue Konfiguration für einen nginx reverse proxy to unix socket erstellt habe, habe ich nicht aus der Datenbank wiederhergestellt, da sich die Datenbank bereits im data-Container befand (wie in den How-to-Themen erwähnt).
Deshalb musste ich die hochgeladenen Dateien manuell in den neuen Container kopieren.
Deine Situation scheint sich von unserer zu unterscheiden.
Ich hoffe, das hilft weiter.
Vielen Dank.
Es scheint, dass Sie über die Kommandozeile dasselbe Verfahren durchführen wie wir über die Benutzeroberfläche: Aktivieren der Wiederherstellung und Wiederherstellen aus den TGZ-Dateien, die Datenbank und Uploads enthalten.
Aber dann sagen Sie, dass Sie für die Funktionsfähigkeit der Avatare (unter Verwendung von Sockets und einem Nginx-Reverse-Proxy) eine zweite Wiederherstellung nur der Uploads benötigen. Habe ich das richtig verstanden?
Hey @ariznaf … nicht ganz…
Anfangs hatten wir eine eigenständige Anwendung. Ich habe diese App in zwei verschiedene Container aufgeteilt (Daten und nur Web) und anschließend eine Wiederherstellung aus der großen Sicherungsdatei mit den Uploads durchgeführt.
Das alles verlief gut…
Dann habe ich einen neuen Container namens socket-only erstellt und so konfiguriert, dass er einen Reverse-Proxy verwendet.
Ich habe im neuen Container socket-only KEINE Wiederherstellung durchgeführt (da der Datencontainer bereits die DB-Daten intakt enthielt), aber ich habe vergessen, die Uploads manuell zu kopieren (das war mein Fehler). Hätte ich einen normalen Wiederherstellungsprozess durchgeführt, wäre das nicht notwendig gewesen.
Es gibt jedoch keinen Grund, im neuen Container erneut eine manuelle DB-Wiederherstellung durchzuführen, denn genau dafür ist die Daten in seinem eigenen kleinen Container gespeichert. In dieser Situation müssen die Uploads also in den neuen Container kopiert werden. Das ist tatsächlich elegant gelöst.
Hilft dir das weiter?
Das habe ich nicht gesagt. Ich sagte, dass das Backend sich selbst über den vorderen Nginx nicht erreichen kann. Was du sagst, ist genau umgekehrt.
Um einen Upload zu optimieren, ruft der Sidekiq-Job diesen über HTTP(S) ab.
Nein, Sie können die SSL-Vorlage deaktivieren, müssen jedoch force_https manuell aktivieren.