Wie kann ich die Discourse-Datenbank direkt über eine GUI bearbeiten?

Ich suche nach einer benutzerfreundlichen Anwendung, mit der ich SQL-Abfragen ausführen kann, um meine aktuelle Datenbank mit aus zwei älteren Foren importierten Beiträgen und Nutzern global zu bereinigen – beispielsweise durch das Löschen von Themen, das Hinzufügen bestimmter Tags zu allen Beiträgen, die eine bestimmte Zeichenfolge im Titel enthalten, das Löschen von Nutzern oder das Ändern von Zugriffsrechten, wenn Benutzerprofile bestimmte Kriterien nicht erfüllen.

Gibt es etwas Ähnliches wie phpMyAdmin, das eine SQL-Sicherung eines Discourse-Administrators bearbeiten kann? Oder das sogar mit einer live laufenden Discourse-Instanz arbeiten kann?

Ich habe gesehen, dass es ein Plugin gibt, das Abfragen innerhalb von Discourse ermöglicht, aber dieses scheint keine Änderungen an den Daten zuzulassen.

Das Herunterladen eines Backups (ohne Uploads) und das Wiederherstellen auf einer lokalen PostgreSQL-Instanz, die Sie mit pgAdmin3 abfragen können, ist Ihre beste Option.

Ja, das Data Explorer-Plug-in erlaubt keine Änderungen. Ich würde jedoch trotzdem empfehlen, damit zu beginnen. Sie können Abfragen ausführen, um festzustellen, ob Sie Probleme haben, und dann weitere Abfragen durchführen, um die Datensätze auszuwählen, die geändert werden müssen. So sind Sie vor versehentlichen Schäden an Ihrer Datenbank geschützt.

Ich gehe davon aus, dass Sie bereits im Produktionsmodus laufen. Daher wäre ich sehr vorsichtig, die Datenbank ohne eine Art Genehmigung des Discourse-Teams zu ändern.

Sobald Sie mit der Discourse-Datenbank vertraut sind und das Ausmaß des Problems kennen, können Sie Ihre Optionen für die Änderungen prüfen. Vielleicht lässt sich alles direkt in Discourse erledigen. Oder es sind so wenige Änderungen nötig, dass die Kommandozeile ausreicht.

Danke, Falco!

Ich bin ein echter Anfänger, wenn es darum geht, etwas zu verwenden, das nicht auf Klicken und Zeigen basiert.

Ich habe es jedoch geschafft, eine lokale Instanz von Discourse (unter Windows 10) einzurichten, indem ich die offiziellen Anleitungen befolgt habe (ohne viel davon zu verstehen). Daher gehe ich davon aus, dass es irgendwo eine Anleitung gibt, wie man pgAdmin3 am selben Ort installiert.

Eine alberne Frage: Ist diese Offline-Discourse-Instanz das Ziel, in das ich die exportierte SQL-Datei wiederherstellen sollte (oder gibt es eine andere Möglichkeit, eine Discourse-Datenbanksicherung in PostgreSQL wiederherzustellen)?
Und wie kann ich sie nach der Wiederherstellung abfragen? Das heißt, wo und wie verweise ich pgAdmin3 auf die Datenbank in einer laufenden Discourse-Instanz? Wo befindet sich physisch die Datenbank einer laufenden Discourse-Instanz? Verhindert der Tatsache, dass die Discourse-Instanz läuft, dass die Datenbank auf irgendeine Weise gesperrt wird?
Ich kann keine Dateien finden, die offensichtlich einer Datenbank in meinem lokalen Server-Verzeichnis ~ /var/discourse entsprechen.

Danke, Remah.

Ich hoste Discourse selbst und habe daher keinen Zugang zum Discourse-Team. Ich richte ein Forum für eine kleine Gemeinschaft ein und betreibe es ausschließlich auf freiwilliger Basis (also ohne Budget). Dabei importiere ich Daten sowohl von MyBB als auch von Yahoo-Gruppen-Foren. Letztere haben beispielsweise eine Reihe alter, automatisch generierter administrativer E-Mail-Benachrichtigungen als Themen in Discourse eingeführt, die in diesem Kontext eher irrelevant sind.

Es ist wahrscheinlich, dass ich sporadisch und schrittweise Tests durchführen und globale Änderungen vornehmen muss, wenn ich neue Probleme entdecke – daher mein Wunsch, die Lernkurve zu minimieren und alles CLI-basierte zu vermeiden!

Ich habe deine Domain gesehen und mich zum ersten Mal über dich informiert, daher verstehe ich deine Situation einigermaßen. Übrigens bin ich in Wellington und richte derzeit ein paar private Foren für Wohltätigkeitsorganisationen ein, die ich aktiv nutze.

Angesichts deiner begrenzten Zeit und Erfahrung würde ich empfehlen, zunächst mit den einfachsten und am leichtesten zu bedienenden Tools zu beginnen und erst dann zur nächsten Stufe überzugehen, wenn du dazu gezwungen bist. Der Aufwand, etwas über die erste Stufe hinaus zu beherrschen – also die Nutzung von Discourse selbst –, ist sehr hoch. Wenn Discourse so genutzt wird, wie es konzipiert ist, kann es unglaublich mächtig sein.

  1. Die Discourse-Oberfläche mit den Funktionen, die du ohnehin beherrschen musst.

    • Verschaffe dir einen Überblick darüber, was du in Discourse nutzen musst. Es kann sein, dass du 99 % dessen, was du brauchst, erledigen kannst, ohne weiterzugehen. Vielleicht wirst du also gar nicht weitergehen.

    • Priorisiere tatsächlich sichtbare Probleme.
      Zum Beispiel sind deine alten E-Mail-Benachrichtigungen vielleicht kein großes Problem. Wenn sie irrelevant sind, werden sie, wie vorgesehen, in Discourse an Bedeutung verlieren, sobald relevantere Themen erstellt werden. Es ist wichtiger, dein Forum ordnungsgemäß in Betrieb zu nehmen, als jeden Datenfehler zu beheben.
      Wie viele dieser automatisierten E-Mail-Benachrichtigungen wurden bereits in Themen umgewandelt?

  2. Das Data Explorer-Plugin wird für dich nützlich sein und ist der nächste Schritt zu einem besseren Verständnis der Datenbank und zur Identifizierung dessen, was möglicherweise getan werden muss. Später wird es dir bei Berichten helfen, ist aber nicht zwingend erforderlich.

    • Die Unfähigkeit, Änderungen vorzunehmen, dient als Sicherheitsnetz, da es vor einigen Jahren viele Nutzer gab, die ihre Daten durch übereilte Updates zerstört haben.

    • Die Abfragen, die du erstellst, um problematische Datensätze zu identifizieren, liegen nur einen Schritt von SQL entfernt, um die Datenbank zu ändern.

  3. Die letzte Option ist wahrscheinlich die Verwendung der Befehlszeile und von Skripten zur Änderung deiner Datenbank.

    • Ich würde lieber das Risiko von fehlerhaften Daten in der Anzeige eingehen als das Risiko, die Datenbank durch manuelle Änderungen zu beschädigen. Das könnte eine Zeitbombe darstellen, da einige Datenkorruptionen möglicherweise nicht rechtzeitig erkannt werden.

    • Die Verwendung von Data Explorer liefert Abfrageergebnisse, die echte Datenbeispiele und quantifizierbare Anzahlen von Datensätzen enthalten. Du erhältst mit größerer Wahrscheinlichkeit eine korrekte Antwort vom Team und anderen Experten, wenn diese deine Daten und deine Ziele verstehen können. Sie können dich dann über den einfachsten und sichersten Weg beraten, die Datenbank zu aktualisieren.

    • Ein Großteil dessen, was du brauchst, befindet sich wahrscheinlich bereits in Themen, da andere Websites auf ähnliche Probleme stoßen. Du wirst also lediglich das hart erkämpfte Wissen anderer kopieren.

Genau. Ändere die Datenbank nicht direkt. Du wirst es eines Tages bereuen.

Danke, Remah,

alles klingt nach vernünftigen Ratschlägen.
Ich könnte eventuell eine teilweise Lösung durch Crowdsourcing finden, wenn es mir gelingt, einige Nutzer davon zu überzeugen, manuell nach Themen zu suchen und diese zur Löschung zu markieren.

Derzeit ist die Website unter der Domain im Wesentlichen ein leerer Platzhalter, während ein Freelancer den Importprozess von den alten Foren verfeinert (insbesondere das Import-Skript für MyBB angepasst, damit hoffentlich die benutzerdefinierten Profilfelder, die ich dort eingerichtet hatte, zusammen mit den Nutzern und ihren Beiträgen importiert werden. Außerdem soll hoffentlich der MyBB-Code in einigen MyBB-Beiträgen korrekt geparst werden – aktuell sind die Formatierungscodes noch sichtbar).

Ich habe eine Woche lang vergeblich versucht, diesen Import selbst durchzuführen, konnte aber weder eine Ubuntu-Instanz unter Windows 10 noch eine auf DigitalOcean basierende Instanz so einrichten, dass alle Voraussetzungen für die Nutzung des offiziellen MyBB-Import-Skripts erfüllt waren.

Nach schmerzhaftem Herumprobieren und der Lösung von Fehlermeldung nach Fehlermeldung stieß ich in beiden Fällen schließlich an eine absolute Sackgasse, als es darum ging, die SQL-Datenbank zugänglich zu machen, um den letzten Ruby-on-Rails-Befehl auszuführen, der den Import starten würde.

Linux und Ruby scheinen beide von Sadisten für Masochisten geschrieben worden zu sein; beide sind erstaunlich fragil und geheimnisvoll. In einer solchen Umgebung scheinen die Chancen auf katastrophale Probleme beim Manipulieren von Datenbanken tatsächlich hoch zu sein!

Das tut mir leid für Sie.

Bleiben Sie besser beim Foren-Administrator. :+1:

Die Benutzerfreundlichkeit hat in dieser Umgebung immer gefehlt. Ich finde, die Kommandozeile ist noch wichtiger als vor 20 Jahren.

Aber genau das ist der Grund, warum ich Discourse mag. Das Team bemüht sich, Discourse als Kernprodukt deutlich benutzerfreundlicher zu gestalten. Leider ist die Migration eine hochtechnische Option.

Es ist fast sicher besser, dies über die Rails-Konsole zu erledigen.

Ich vermute, das hängt von deinem Maßstab für „besser

Wenn Sie sich entscheiden, die Änderungen nicht direkt in der Datenbank vorzunehmen, könnten einige der in diesem Thema beschriebenen Befehle hilfreich sein: Administrative Bulk Operations. Beispielsweise werden dort Details dazu gegeben, wie man Themen über die Rails-Konsole taggt. Das Wichtigste ist, vor der Ausführung beliebiger Befehle ein Backup Ihrer Site-Datenbank zu erstellen.

Mein Maßstab für ‚besser’ ist ‚deutlich weniger wahrscheinlich, dass du deine Datenbank in einem defekten oder völlig zerstörten Zustand hinterlässt’. Da du ein ‚Einsteiger’ bist, weißt du nicht, welche Tabellen aktualisiert werden müssen, wenn du irgendetwas tust.

Egal wie du es machst, stelle sicher, dass du häufig Backups erstellst.

Ein gültiger Punkt – ich werde mich in erster Linie intensiv darum bemühen, andere Wege zu finden.
Meine Unwissenheit ist bei beiden Szenarien ein großes Risiko, aber ist es zutreffend zu sagen, dass Datenbankänderungen über Ruby sicherer sind als der Versuch, dieselben Änderungen mit pgAdmin4 vorzunehmen?

Das Risiko, nicht sofort bemerkte Schäden zu verursachen, wurde bereits angesprochen – gibt es etwas an der einen oder anderen Methode, das dieses Risiko beeinflussen kann?

Im Hinterkopf habe ich folgende Überlegung: Falls ich mich doch einmal dazu entschließen sollte, es zu riskieren (nachdem angemessene Backups erstellt wurden), stelle ich mir eine Kopie von pgAdmin4 auf meinem DigitalOcean-Droplet vor, auf die ich direkt über eine URL im Browser zugreifen könnte, statt über CLI-Fenster. Dadurch würden einige Komplexitätsebenen entfallen (ich gehe hier davon aus, dass dies überhaupt möglich ist).

Im Großen und Ganzen ja. Ruby führt eine Reihe von magischen Vorgängen aus, um sicherzustellen, dass das Richtige passiert. Wenn Sie beispielsweise etwas aus einem Modell zerstören (löschen), weiß es, wann und was anderes gelöscht werden sollte. Es gibt viele “sichere” Dinge, die Sie mit rohem SQL tun können, aber ich mache es fast immer in Rails, wenn es möglich ist.

Ah, das ist gut zu wissen – danke!

Das sieht potenziell ziemlich nützlich aus – danke!

Wie ich das Problem Wie kann ich die Discourse-Datenbank direkt über eine GUI bearbeiten? gelöst habe, da die bisherige Antwort nicht das enthielt, was ich suchte.

:warning: Führen Sie dies nicht auf einem Produktionsrechner durch.

Dabei wird das von PostgreSQL empfohlene Administrationswerkzeug pgAdmin 4 verwendet.

Dies wurde auf meinem lokalen Rechner durchgeführt, um mehr über Discourse zu lernen, z. B. Installation, Konfiguration, Optimierung, Entwicklung von Plugins, Nutzung der API und Webhooks usw.

Hinweis: Discourse wurde auf Ubuntu 18.04 unter WSL 2 auf Windows 10 installiert, entsprechend dem Leitfaden für Anfänger zur Installation von Discourse auf Windows 10 zur Entwicklung.

Hinweis: WSL 2 wird nicht mit systemd ausgeliefert. Issue 457

Als Vorlage wurde Installieren von pgAdmin 4 auf Ubuntu 20.04/18.04/16.04 verwendet.

Mit BASH

$ echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee  /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
$ sudo apt update
$ sudo apt install pgadmin4 pgadmin4-apache2

pgAdmin4-Benutzer-E-Mail: postgres@localhost
pgAdmin4-Passwort: <password 1>

$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I

Adresse <address> notieren

$ whoami

Benutzername <user name> notieren

Dieser nächste Schritt ist möglicherweise nicht erforderlich, da ich nicht wusste, wie ich das Passwort eines Postgres-Datenbankbenutzers erhalte, da ich kein PostgreSQL-Experte bin, oder ob es eine andere Möglichkeit gab, die benötigten Login-Daten für pgadmin4 einzurichten.

$ psql postgres

Mit PSQL

postgres=# ALTER ROLE <user name> '<password 2>';

Mit einem Internetbrowser

http://<address>/pgadmin4

Benutzer: postgres@localhost
Passwort: <password 1>

Sobald pgAdmin4 gestartet ist

Mit pgAdmin4

Eine Serververbindung erstellen

Tab: Allgemein
   Name: Discourse Entwicklung
   Servergruppe: Server
Tab: Verbindung
   Host: localhost
   Port: 5432
   Wartungsdatenbank: postgres
   Benutzername: <user name>
   Passwort: <password 2>

Dies ist nicht perfekt, funktioniert aber und ist besser als nichts. Feedback und Vorschläge sind willkommen.


Bonus-Runde

PostgreSQL
Softwarekatalog – Verwaltungs-/Entwicklungstools

Ich finde, dass es für die meisten Aktionen einfacher und etwas sicherer ist, auf die Rails-Konsole zuzugreifen, anstatt direkt mit der Datenbank zu interagieren.

Oder, wenn Sie das Passwort eines Benutzers ändern möchten (oh, das war nicht das, was Sie tun wollten, aber dies ist dennoch ein gutes Beispiel), führen Sie Folgendes aus:

cd /var/discourse
./launcher enter app
rake admin:create

Trotz seines Namens ermöglicht Ihnen dieser Rake-Auftrag Folgendes:

  • Einen Benutzer erstellen (aber es ist in Ordnung, wenn der Benutzer bereits existiert)
  • Das Passwort ändern (aber Sie müssen es nicht)
  • Den Benutzer zum Administrator machen (aber Sie müssen es nicht).

Schauen Sie sich Administrative Massenvorgänge für weitere Beispiele an.

Hier sind jedoch einige:

users = User.all
me = User.find_by_username('pfaffman')
me = User.find_by_email('jay@literatecomputing.com')
UserEmail.create!(user: me, email: 'myotheraddress@somewhereelse.com')
posts_with_uploads = Post.where("raw like '%upload%'")
Group.create(
  name: "mygreatgroup",
  automatic_membership_email_domains: 'literatecomputing.com',
  primary_group: true,
  title: "Literate Computing Staff",
  grant_trust_level: 4,
  flair_url: 'https://example.com/path.icon.png'
)

Danke für das Feedback. Das ist wieder etwas, das ich lernen kann.

Obwohl ich jahrzehntelange Entwicklungserfahrung habe, habe ich noch nie Ruby oder Rails verwendet. Ich habe das Programmieren tatsächlich mit Lochkarten im Studium begonnen und privat mit einem Atari 800.