Ich bin auf der ARM-Architektur und der obige Befehl wirft Fehler. Ich vermute, dieses Plugin ist nicht für arm geeignet?
Gibt es ein anderes Plugin, um E-Mails für ARM zu empfangen?
Ich bin mit arm nicht vertraut und kann daher nicht sagen, ob es ungeeignet ist, aber ich wollte nur anmerken, dass dies kein Plugin ist. Hoffentlich ist es nur eine Verwechslung der Terminologie und Sie versuchen nicht, es als Plugin zu installieren, da dies nicht funktionieren wird. 
1 „Gefällt mir“
Vielen Dank für die Antwort. Ah, mein Fehler, ich dachte, es funktioniert wie ein Plugin. Wenn es einen anderen Begriff dafür gibt, lassen Sie es mich bitte wissen. Mein Server läuft auf arm64, den neuen Chips, die ich bei Amazon EC2 vermute.
Ich habe es gerade wie in dem Beitrag erklärt installiert. Aber es wirft Fehler. Es scheint, als ob es nicht auf arm64 funktioniert.
1 „Gefällt mir“
Nur zur Klärung: Sagen Sie, dass Sie die Standardinstallation erfolgreich durchlaufen haben und eine funktionierende Discourse-Instanz auf arm haben, aber die Einrichtung von mail-receiver speziell fehlschlägt?
Welche Fehler sehen Sie? Wenn Sie die Fehlermeldungen bereitstellen können, kann dies helfen, eine Ursache zu identifizieren. Achten Sie darauf, nach sensiblen Informationen zu suchen, die geschwärzt werden müssen.
Es ist (für mich) etwas schwierig, ihm einen bestimmten Begriff in Bezug auf Discourse zu geben. Im Grunde ist es nur eine völlig separate Containeranwendung für einen nur empfangenden E-Mail-Server, der absichtlich so eingerichtet ist, dass er diese E-Mails über seine API an Discourse liefert.
2 „Gefällt mir“
Ja, das ist das Standardinstallationsverfahren für Discourse. Und Discourse funktioniert auf arm64 soweit ich weiß einwandfrei.
Die Fehler sind wie folgt:
Status: Downloaded newer image for discourse/mail-receiver:release
docker.io/discourse/mail-receiver:release
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/bin/gem: exec format error
cd /pups && /pups/bin/pups --stdin
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Ich habe vorerst AWS WorkMail verwendet, aber wenn Discourse eine einfache E-Mail-Empfangs- und Kompositionsfunktion haben kann, dann ist es sicherlich wert, als offizieller E-Mail-Posteingang verwendet zu werden.
Es gibt keinen einfachen Mailserver. Es gibt einen Mailserver oder es gibt keinen. Und Mailserver sind extrem schwierig, sehr anfällig dafür, zu Spamzentren zu werden, und in den meisten Cloud-/VPS-Diensten verboten.
Deshalb wird Discourse einen echten Mailserver abfragen, E-Mails abholen und an diesen weiterleiten. Wenn ein Administrator dies eingerichtet hat.
1 „Gefällt mir“
Ich glaube, Sie haben mich missverstanden.
Ich beziehe mich nicht auf die „Erstellung eines Mailservers“. Vielmehr geht es um eine einfache, aber ansprechende Benutzeroberfläche (UX), um E-Mails zu verfassen (zum Senden von E-Mails) und zu lesen (eingehende E-Mails), damit wir sie zum Beantworten offizieller E-Mails verwenden können, die wir erhalten.
Kontrolliert der „Simple Email Service (SES)“ von AWS nicht bereits Spam usw.? Wir müssen nur die UX in Discourse bereitstellen, damit wir eine ansprechende und dennoch einfache Mail-Inbox und einen Composer haben.
Ich bin mir nicht ganz sicher, ob die Bereitstellung einer Single-Page-UX in Discourse so komplex ist (da wir den Server bereits darin integriert haben und AWS SES auch über Discourse nutzen können).
Für das Discourse-Basisimage erkennt das launcher-Tool bei der Ausführung auf arm64 dies und wechselt zu einem arm64-Image mit einer Warnung, dass es sich um eine experimentelle Version handelt. Dasselbe geschieht nicht für mail-receiver, und wenn man sich die Images auf Docker Hub ansieht, scheint es keine arm64-Version zu geben.
Es gibt zwei naheliegende Optionen:
- Wechseln Sie zu einer amd64 EC2-Instanz, was Ihnen eine nicht-experimentelle Discourse-Installation ermöglicht und die Installation von
mail-receiverdaneben erlaubt. - Fügen Sie eine zweite EC2-Instanz hinzu, die kleinste Option mit amd64 (ich glaube, t3a.nano), und installieren Sie
mail-receiverdarauf.
Es spielt keine Rolle, wo sich mail-receiver befindet. Der DNS-MX-Eintrag für Ihre E-Mail-Adresse für Antworten muss zuverlässig darauf verweisen und er muss eine Verbindung zu Ihrer Discourse-Instanz herstellen können.
Wenn es sich dabei um die Verarbeitung von E-Mails an Adressen wie info@ihrefirma.com, sales@ihrefirma.com, support@ihrefirma.com usw. handelt, dann denke ich, dass Gruppen-Messaging Ihnen das geben wird, wonach Sie suchen.
Das heißt, nachdem Sie mail-receiver zum Laufen gebracht haben, können Sie entsprechende Gruppen in Discourse erstellen und den Gruppen eine oder mehrere benutzerdefinierte eingehende E-Mail-Adressen geben. Wenn Sie sich die Nachrichten Ihres eigenen Benutzers ansehen, sehen Sie Posteingänge/usw. für alle Gruppen, denen Sie angehören.
Wenn Sie diese Domain für E-Mails an Mitarbeiter verwenden, z. B. prettygirl@ihrefirma.com, müssen Sie mit Ihrem E-Mail-Anbieter etwas einrichten, um bestimmte Adressen (z. B. info@) in Discourse zu erhalten. Abhängig davon, was Ihr E-Mail-Anbieter anbietet, kann es schwierig sein, die E-Mails mit den richtigen Absenderadressen in Discourse zu erhalten - Sie können sie nicht einfach weiterleiten, da Discourse alles als von Ihrer eigenen Adresse kommend wahrnimmt und nicht vom ursprünglichen Absender.
In Microsoft 365 / Exchange würde eine Kombination aus einem Connector, der an mail-receiver weiterleitet, und Transportregeln, die bestimmte E-Mails dazu veranlassen, diesen Connector zu verwenden, funktionieren.
E-Mail ist schwierig, mail-receiver wurde entwickelt, um das Beantworten von E-Mail-Benachrichtigungen und das Erstellen von Themen (neue Nachrichten an Gruppen eingeschlossen) zu vereinfachen, bei denen die verwendete Domain nicht mit bestehenden E-Mail-Diensten überlappt. Darüber hinaus bewegen Sie sich in nicht unterstützte, fortgeschrittene Bereiche, möglicherweise in Bereiche, für die es nicht so konzipiert wurde.
2 „Gefällt mir“
Die Antwort auf die Frage im Titel lautet „nein“.
1 ist das, was ich von Anfang an gedacht habe. Das ist die empfohlene und unterstützte Lösung zu diesem Zeitpunkt.
Ich habe kürzlich Aktionen bei discourse_docker gesehen, um die Unterstützung für ARM zu erhöhen, glaube ich, aber es scheint unwahrscheinlich, dass die Unterstützung des Mail-Receivers in ARM etwas ist, das in naher Zukunft hinzugefügt wird. Aber das ist nur eine Vermutung. Ich habe keine Kontrolle über die Angelegenheit und es gibt vieles, was ich nicht weiß.
Das andere wäre, herauszufinden, wie man ARM dazu bringt, den Mail-Receiver zu unterstützen und einen PR einzureichen.
Wenn Sie ARM lieben, lieben, lieben, dann könnten Sie einen vollwertigen Mail-Receiver mit Postfächern und allem Drum und Dran finden und eine Reihe von Postfächern verwalten.
2 „Gefällt mir“
Es wäre durchaus möglich, mail-receiver auf ARM-Systemen zu unterstützen. Es gibt nichts amd64-spezifisches darin (oder zumindest gab es das nicht, als ich es erstellt habe, und ich kann mir nicht vorstellen, dass wesentliche Änderungen vorgenommen wurden, die diese Annahme ungültig machen würden). Es wäre lediglich eine Frage der Docker-Image-Maintainer, einen Build des Images für arm64 zu erstellen, wie sie es bereits für amd64 tun.
Jemand könnte auch einen inoffiziellen Build erstellen und ihn irgendwo ablegen, zusammen mit Anweisungen für die einzeilige Änderung, die am pups-Template vorgenommen werden muss, oder Sie könnten Ihren eigenen lokalen Build aus dem Repository auf dem ARM64-System, auf dem Sie es ausführen, vornehmen.
5 „Gefällt mir“
Es gibt socketee, das im Rahmen des Dockerfiles von GitHub nach /usr/local/bin heruntergeladen wird. Das ist eine x86_64-Binärdatei, die also nicht funktioniert. Es sieht jedoch so aus, als ob diese nur verwendet wird, wenn sie explizit konfiguriert ist.
Speziell diese Funktion oben würde auf arm64 fehlschlagen, da socketee nicht ausgeführt werden könnte. Ich kann nichts anderes sehen, das nicht einfach durch Erstellung für arm64 funktionieren würde.
Ich bin mir nicht zu 100 % sicher, aber nach oberflächlicher Beobachtung scheint es, als ob das Hinzufügen dieser Zeilen zur build-Datei ausreichen könnte:
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
Ja, ich habe das von meiner Analyse ausgeschlossen, da es extrem unwahrscheinlich ist, dass jemand außerhalb von CDCK dies verwendet, da es für den sehr speziellen Zweck der Zentralisierung von Postfix-Protokollen enthalten war – etwas, das ein durchschnittlicher mail-receiver-Konsument mit ziemlicher Sicherheit nicht tun wird.
2 „Gefällt mir“
wenn mail-receiver auf ARM nicht funktioniert und IMAP nur mit GMail funktioniert, ist das sehr einschränkend.
Das ist das erste Mal, dass ich 
in meinem Schatten laufen sehe, und das macht mich sehr traurig.
Falls es jemanden interessiert, habe ich einen arm64-Image-Build durchgeführt und ihn nach womble/discourse-mail-receiver:arm64 gepusht, um die Leute zu überbrücken, bis das Kernteam einen offiziellen Image-Build erstellen kann. Weitere Details zu Einschränkungen (vorerst kein socketee; ich werde es hinzufügen, wenn jemand sagt, dass er es braucht), zur Verwendung und zur Meldung von Problemen (d. h. „sagen Sie es mir, nicht dem Kernteam“) finden Sie in der README meiner Branch.
6 „Gefällt mir“
Ich habe einen PR zum Entfernen von socketee erstellt Remove socketee support by Firefishy · Pull Request #28 · discourse/mail-receiver · GitHub
Ich würde auch gerne die Änderungen per PR vornehmen, um mail-receiver an den ARM64-Build-Prozess anzupassen, der von discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub verwendet wird.
1 „Gefällt mir“