Betas werden nach dem Testen schließlich als stabile Version veröffentlicht. Je nachdem, wie groß die Änderungen am Kern sind, sind möglicherweise spezielle Schritte über die Befehlszeile erforderlich.
Ein VPS (Virtual Private Server) ist das, wofür Sie bezahlt haben, damit Ihre Discourse-Installation läuft. Es sei denn, Sie betreiben sie auf Ihrem Heim-PC, was typischerweise eine nicht unterstützte Installation sein wird.
Ich habe Upcloud als meinen VPS-Anbieter genutzt. Jetzt nutze ich Cuttob.
Alle Betas werden nach ausreichendem Testen zu dem, was die Leute stabile Versionen nennen.
In dem von Moin bereitgestellten Link haben Sie:
Beta noch nicht weit fortgeschritten (nicht für die Produktion empfohlen)
Tests Bestanden (zahlreiche Tests bestanden und für die Produktion bereit erachtet) Vom Team empfohlener Branch für Sicherheit.
Stabil, wenn Sie Ihre eigenen benutzerdefinierten Plugins und Themes/Theme-Komponenten ausführen. Großartig, da sich Änderungen nur sehr langsam ändern. Aber Sie sind mehr Sicherheitsrisiken ausgesetzt, da Updates langsam sind.
Gehostete Discourse-Pläne verwenden typischerweise den Tests-Bestanden-Branch, um die beste Sicherheit und gute Stabilität zu gewährleisten.
Nehmen Sie das nicht falsch auf. Aber da Sie mit Begriffen wie VPS nicht vertraut sind, deutet dies darauf hin, dass Sie hier noch sehr neu sind. Haben Sie Discourse selbst installiert oder vielleicht ein Discourse-Forum geerbt? Wir alle waren einmal neu in der Einrichtung/Wartung von Discourse.
Keine Meinung. Es ist eine Tatsache, wenn die Software, die Sie verwenden. Was mit den meisten Open-Source- und sogar Closed-Source-Software, die Sie verwenden, auf einer Stufe steht. Ich habe vps geschrieben. Android hat das V und P großgeschrieben.
Fairerweise stelle ich mir vor, dass Sie die Dinge selbst herausfinden müssen, wenn Sie nicht wirklich Hilfe beim Lernen wollen.
Ich stelle fest, dass @anon55243134 fast alle seine Beiträge gelöscht hat. Ich glaube wirklich, dass es hier Lektionen für das Team und für die Wartung der Update-Skripte und die Kommunikation rund um das Update zu lernen gibt.
@anon55243134 ist jemand, der seit Jahren ein selbst gehostetes Discourse betreibt und nun eine beschädigte und nicht funktionierende Installation hat – nur indem er den Anweisungen zum Upgrade gefolgt ist.
Wenn mir das passieren würde, wäre ich sehr verärgert und bestürzt über den potenziellen Verlust meiner Foreninhalte. Da ich mich für Self-Hosting entschieden habe, bin ich möglicherweise nicht bereit oder in der Lage, viel Geld für die Reparatur zu bezahlen, falls dies überhaupt möglich ist.
Ich denke, es gibt unzureichende Warnungen und Prüfungen:
Hat der Benutzer ein aktuelles Backup erstellt (kein Snapshot eines Hosting-Dienstes!)?
Hat der Benutzer es heruntergeladen?
Wird dem Benutzer mitgeteilt, dass das webbasierte Update fehlschlagen und ein Kommandozeilen-Update erforderlich sein könnte?
Wird der Benutzer gefragt, ob sein Betriebssystem sehr alt ist?
Wird dem Benutzer mitgeteilt, dass die Migration auf einen neuen, aktuellen Server möglicherweise der beste Ansatz ist?
Wird der Benutzer davor gewarnt, dass größere Updates (wie ein Datenbank-Update) gefährlich sein können und es ratsam sein könnte, eine Woche zu warten, wenn man unerfahren ist, damit Probleme gefunden und behoben werden können?
Noch besorgniserregender ist, dass ich in einem der gelöschten Beiträge einige ziemlich dramatische Fehler sehe, die nicht abgefangen wurden und das Skript fortgesetzt wurde:
cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting
Ich habe die Skripte nicht überprüft, aber ich würde erwarten, dass das Nichtvorhandensein von Dingen ein Hinweis darauf ist, dass Schwierigkeiten bevorstehen und es Zeit ist, aufzuhören.
Entschuldigung, dass ich ein bereits geöffnetes Wespennest wieder aufwerfe! In meinem Fall habe ich Ubuntu und Postgres aktualisiert und dann den Befehl sudo ./luancher rebuild app im Verzeichnis /var/discourse erneut ausgeführt. Alles scheint korrekt neu aufgebaut worden zu sein und die Seite ist wieder online.
Vielen Dank an alle, die mir bei diesem Vorhaben geholfen haben. Ich schätze die Unterstützung sehr und weiß nicht, wo ich ohne diese Community stehen würde.
Es gibt definitiv Möglichkeiten, Discourse zu verbessern. Da eine stabile Instanz seit 7 bis 8 Jahren läuft, gab es immer wieder Zeiten, in denen ein Upgrade über die Server-Kommandozeile notwendig war. Dies ist sogar in der Dokumentation mit einer empfohlenen Frequenz abgedeckt.
Allerdings ist die Dokumentation nicht so leicht zugänglich, wie sie sein könnte. Das Dokumentenkategorien-Plugin ist definitiv eine Verbesserung. Aber im meiner Meinung nach noch nicht ideal.
Meine Empfehlungen zur Verbesserung wären direkte Links im Admin-Webinterface, vielleicht mit einem (?)-Link, um ein Popup mit einigen Infos und einem Link zu einem Thema hier in Meta mit detaillierteren Informationen anzuzeigen.
Mit dem Update-Panel wäre es praktisch, zusätzliche Infos in ähnlicher Weise anzuzeigen, beispielsweise bei Core & Docker die Schaltfläche ausgrauen und eine erforderliche Nachricht anzeigen, dass das Update über die Server-Kommandozeile erfolgen muss, mit einem Link zu den jeweiligen Versionshinweisen, wobei der erste Abschnitt die Anforderungen beschreibt, z.B. Docker Version X und Ubuntu LTS Version X (oder eine andere offiziell unterstützte Linux-Distribution). Das verlinkte Thema sollte meiner Meinung nach auch einige Kopier- und Einfüge-Elemente für die Server-Kommandozeile enthalten.
Was die Skripte betrifft, bin ich mir nicht sicher, wie einfach es ist, das umzusetzen. Das initiale Skript sollte jedoch eine Überprüfung der Grundanforderungen durchführen. Falls eine erforderliche Abhängigkeit fehlt, sollte es mit einer Nachricht und vielleicht einem Link zu den benötigten Basisinfos zum Nachlesen abbrechen.
Die Fehlermeldung bei einem gescheiterten Upgrade sollte intuitiver sein. Während sie sagt, nach früheren Fehlern zu scrollen, habe ich festgestellt, dass einige Fehler häufig auftreten und die Wiederherstellung nicht beeinträchtigen. Es wäre viel besser, die wichtigsten Fehler in eine Log-Datei zu exportieren, die die Ursache für den Fehlzustand dokumentiert. Diese vorgeschlagenen Änderungen werden wahrscheinlich viel Arbeit und Zeit in Anspruch nehmen.
Mit Documentation > Self-Hosting benötigt man wirklich eine umfassendere Anleitung für den Einstieg, inklusive einer Einführung, was man vor dem Selbst-Hosting wissen sollte, z.B. grundlegende Kenntnisse des Betriebssystems wie Ubuntu LTS, sowie Informationen zur Wartung und zum Upgrade der Distribution. Best Practices für Backups und konkrete Anleitungen könnten ebenfalls hinzugefügt werden. Diese könnten sogar in einem Thema mit Tags in der Mitarbeitenden-Kategorie verlinkt werden, mit Referenzen zu Meta.
Bloomberg hat, soweit ich mich erinnere, ein gutes Thema über die Ereignisse in diesem Bereich gemacht. Ich entschuldige mich bei @anon55243134, aber diese Person muss auch ihre eigene Rolle übernehmen. Wenn man Support sucht, sollte man bereit sein, zuzuhören und die angeforderten Infos bereitzustellen, damit alle, die helfen können, sie zu möglichen Lösungen führen können.
Wir mögen alle Ideen oder Meinungen darüber haben, wie das Design usw. verbessert werden könnte. Aber solange sich keine Änderungen ergeben, müssen wir akzeptieren, wie es momentan ist.Ich weiß, wie belastend es ist, wenn es zu schädlichen Ausfallzeiten kommt. Vor einiger Zeit hatte ich ein Problem mit dem Kunden, für den ich ehrenamtlich Admin bin. Ich habe über einen Monat lang bei ihnen petitioniert, weil ich die App nicht wiederherstellen konnte, weil der Server zu klein war und die hier verfügbaren Anleitungen zum Freimachen des Speicherplatzes das Problem nicht lösen konnten. Sie haben meinen Rat ignoriert und letztendlich, wie ich gewarnt hatte, einen schweren Serverabsturz erlitten. Sie haben schließlich einem Mitglied hier bezahlt, um das Problem zu beheben, was den Einsatz eines neuen Servers mit ausreichend Platz erforderlich machte. Die Seite war wegen ihrer Fahrlässigkeit über mehr als 2 Wochen ausgefallen. Später haben sie den Mailserver nicht gewartet, und obwohl die Seite nicht ausgefallen war, haben fehlende Benachrichtigungs-E-Mails erheblichen Schaden verursacht. Ich könnte noch mehr erzählen. Aber das ist keine Discourse-Frage. Das ist eine Self-Hosting-Frage.
Ich hatte schon vor langer Zeit ein Wiederherstellungsproblem, das durch eine Template-Datei verursacht wurde. Das Log gab mir genügend Hinweise, um eine Vermutung anzustellen, indem ich die Template-Datei auskommentierte. Das hat mein Problem gelöst. Als ich das hier erwähnt habe, habe ich erklärt, was ich gemacht habe, was dem Team geholfen hat, das Problem zu identifizieren.
Auf allen Seiten sollten wir uns bemühen, uns zu verbessern. Nehmt euch die Zeit, die Erfahrungsberichte und das Wissen derjenigen zu lesen und zuzuhören, die bei der Lösung von Problemen helfen können. So habe ich mein Bewusstsein für die Dinge gewonnen, die ich tun kann. Für Dinge, mit denen ich insbesondere bei der Komplexität von Discourse keine Erfahrung habe, recherchiere ich so gut ich kann, bitte um Hilfe und höre auf den Rat aller hier, die in diesem großartigen Software mehr Erfahrung haben.
@anon55243134, wenn du bereit bist, Dingen eine Chance zu geben, können wir alle vielleicht dabei helfen, dich wieder online zu bekommen. Wir müssen während dieses Prozesses nur vermeiden, uns auf “wie wir denken, dass es sein sollte” zu versteifen, und für den Moment akzeptieren, “wie es ist”. Sobald alles repariert ist, können wir unsere Lektionen daraus ziehen und eine gute Diskussion mit Empfehlungen beginnen, wie man die Dinge möglicherweise verbessern kann, und wenn das Team empfänglich ist (was es in der Regel ist), akzeptieren, dass dies eine geraume Zeit in Anspruch nehmen wird, während andere Projekte laufen. Wir können an Ideen arbeiten und diejenigen, die echtes Fachwissen haben, können, wenn sie Zeit haben, an einigen der benötigten Informationen für Anleitungen, Best Practices usw. arbeiten.
Gemeinsam erreicht jeder mehr. Ich habe beschlossen, dass wir sehr wenig oder gar nichts erreichen.
