Je suis sur une architecture ARM et cette commande génère des erreurs. Je suppose que ce plugin n’est pas adapté pour arm ?
Existe-t-il un autre plugin pour recevoir des e-mails pour les architectures arm ?
Je crains de ne pas connaître arm, donc je ne peux pas vous dire si c’est inadapté, mais je voulais juste noter que ce n’est pas un plugin. J’espère que c’est juste une confusion de terminologie et que vous n’essayez pas de l’installer en tant que plugin, car cela ne fonctionnera pas. 
1 « J'aime »
Merci pour votre réponse. Ah, c’est ma faute, je pensais que cela fonctionnait comme un plugin. S’il a un terme différent, veuillez me le faire savoir. Mon serveur fonctionne sur arm64, les nouvelles puces, je suppose, sur amazon ec2.
Je viens de l’installer comme expliqué dans le post. Mais il génère des erreurs. Il semble qu’il ne fonctionne pas sur arm64.
1 « J'aime »
Juste pour clarifier, dites-vous que vous avez réussi l’installation standard et que vous avez une instance Discourse fonctionnelle sur arm, mais que la configuration spécifique de mail-receiver échoue ?
Quelles sont les erreurs que vous rencontrez ? Si vous pouvez fournir les messages d’erreur, cela pourrait aider à identifier une cause. Veillez à vérifier qu’il n’y a rien de sensible à masquer.
C’est un peu difficile (pour moi) de lui donner un terme particulier par rapport à Discourse. Sous le capot, il s’agit simplement d’une application conteneurisée totalement distincte pour un serveur de messagerie en réception seule, qui est d’ailleurs (est délibérément) configurée pour livrer ces e-mails à Discourse via son API.
2 « J'aime »
Oui, c’est la procédure d’installation standard pour installer Discourse. Et Discourse fonctionne bien, je suppose, sur arm64.
Les erreurs sont les suivantes :
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.
J’ai commencé à utiliser AWS WorkMail pour le moment, mais si Discourse peut avoir une fonctionnalité simple de réception et de composition d’e-mails, cela vaut vraiment la peine de l’utiliser comme boîte de réception officielle.
Il n’existe pas de serveur de messagerie simple. Il y a un serveur de messagerie ou il n’y en a pas. Et les serveurs de messagerie sont extrêmement difficiles, très vulnérables à devenir des centres de spam et interdits dans la plupart des services cloud/VPS.
C’est pourquoi Discourse interrogera un vrai serveur de messagerie, récupérera les e-mails et les déplacera vers celui qui a été envoyé. Si un administrateur l’a configuré.
1 « J'aime »
Je pense que vous m’avez mal compris.
Je ne fais pas référence à la « création d’un serveur de messagerie ». Plutôt à une interface simple mais agréable (UX) pour composer (envoyer des e-mails) et lire (e-mails entrants), afin que nous puissions l’utiliser pour répondre aux e-mails officiels que nous recevons.
Le « service d’e-mails simple (SES) » d’AWS ne contrôle-t-il pas déjà le spam, etc. ? Il nous suffit de fournir l’UX dans Discourse afin d’avoir une boîte de réception et un compositeur de messagerie avec une UX agréable et simple.
Je ne suis pas tout à fait sûr si la fourniture d’une UX d’une seule page dans Discourse est si complexe (car nous avons déjà le serveur intégré et nous pouvons également utiliser AWS SES via Discourse).
Pour l’image de base Discourse, l’outil launcher détecte lorsqu’il s’exécute sur arm64 et passe à une image arm64 avec un avertissement indiquant qu’elle est expérimentale. La même chose ne se produit pas pour mail-receiver et en regardant les images sur Docker Hub, il semble qu’une version arm64 n’existe pas.
Deux options évidentes viennent à l’esprit :
- Passer à une instance EC2 amd64, ce qui vous donnera une installation Discourse non expérimentale et vous permettra d’installer
mail-receiverà côté. - Ajouter une deuxième instance EC2, la plus petite option avec amd64 (t3a.nano, je pense), et y installer
mail-receiver.
Peu importe où se trouve mail-receiver, l’enregistrement MX DNS pour votre adresse e-mail de réponse par e-mail doit simplement y pointer de manière fiable et il doit pouvoir se connecter à votre instance Discourse.
Si cela concerne la gestion des e-mails adressés à des adresses telles que info@votreentreprise.com, ventes@votreentreprise.com, support@votreentreprise.com, etc., alors je pense que la messagerie de groupe vous donnera ce que vous recherchez.
C’est-à-dire, une fois que vous aurez fait fonctionner mail-receiver, vous pourrez créer des groupes appropriés dans Discourse et attribuer aux groupes une ou plusieurs adresses e-mail entrantes personnalisées. Lorsque vous regarderez les messages de votre propre utilisateur, vous verrez des boîtes de réception/etc. pour tous les groupes auxquels vous appartenez.
Si vous utilisez ce domaine pour les e-mails du personnel, par exemple prettygirl@votreentreprise.com, vous devrez alors configurer quelque chose avec votre fournisseur de messagerie pour acheminer des adresses spécifiques (par exemple, info@) vers Discourse. Selon ce que votre fournisseur de messagerie propose, il peut être difficile de faire parvenir les e-mails à Discourse avec les bonnes adresses d’expéditeur - vous ne pouvez pas simplement les transférer car Discourse verra tout comme venant de votre propre adresse au lieu de l’expéditeur d’origine.
Dans Microsoft 365 / Exchange, une combinaison d’un connecteur pour acheminer vers mail-receiver et de règles de transport pour que des e-mails spécifiques utilisent ce connecteur fonctionnerait.
La gestion des e-mails est difficile, mail-receiver est conçu pour simplifier la réponse aux notifications par e-mail et la création de sujets (nouveaux messages aux groupes inclus dans ceux-ci) où le domaine utilisé ne chevauche pas les services de messagerie existants. Au-delà de cela, vous entrez dans un territoire avancé non pris en charge, potentiellement “il n’a pas été conçu pour être utilisé de cette façon”.
2 « J'aime »
La réponse à la question posée dans le titre est « non ».
La 1 est ce à quoi j’ai pensé depuis le début. C’est la solution recommandée et prise en charge à ce stade.
J’ai vu récemment des actions sur discourse_docker concernant l’augmentation du support pour ARM, je pense, mais il semble improbable que le support du récepteur de courrier sur ARM soit ajouté de sitôt. Mais ce n’est qu’une supposition. Je n’ai aucun contrôle sur la question, et il y a beaucoup de choses que j’ignore.
L’autre option serait de trouver comment faire en sorte qu’ARM prenne en charge le récepteur de courrier et de soumettre une PR.
Si vous aimez, aimez, aimez ARM, alors vous pourriez trouver un récepteur de courrier complet avec des boîtes aux lettres et tout le reste, et gérer un tas de boîtes aux lettres.
2 « J'aime »
Il serait tout à fait possible de prendre en charge mail-receiver sur les systèmes ARM. Il n’y a rien de spécifique à amd64 là-dedans (ou du moins, il n’y en avait pas quand je l’ai créé, et je ne peux pas imaginer que des changements majeurs aient été apportés pour invalider cette hypothèse). Il suffirait que les mainteneurs de l’image Docker créent une version de l’image pour arm64, comme ils le font déjà pour amd64.
Quelqu’un pourrait également faire une version non officielle et la mettre quelque part, avec des instructions sur le changement d’une seule ligne nécessaire au modèle pups, ou vous pourriez faire votre propre version locale à partir de du dépôt sur le système arm64 sur lequel vous exécutez.
5 « J'aime »
Il y a socketee qui est téléchargé dans /usr/local/bin depuis GitHub dans le cadre du Dockerfile. C’est un binaire x86_64 donc ça ne fonctionnera pas, cependant il semble que cela ne soit utilisé que si explicitement configuré.
Spécifiquement, la fonctionnalité ci-dessus échouerait sur arm64 car socketee ne pourrait pas s’exécuter. Je ne vois rien d’autre qui ne fonctionnerait pas simplement en compilant pour arm64.
Je ne suis pas sûr à 100%, mais d’après une observation rapide, il semble qu’il suffirait d’ajouter ces lignes au fichier build pour y parvenir :
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
Oui, je l’ai exclu de mon analyse car il est extrêmement peu probable que quelqu’un en dehors de CDCK l’utilise, puisqu’il a été inclus dans le but très spécifique de centraliser les logs Postfix – quelque chose que le consommateur moyen de mail-receiver ne fera presque certainement pas.
2 « J'aime »
Si mail-receiver ne fonctionne pas sur ARM et que IMAP ne fonctionne qu’avec GMail, c’est très limitant.
C’est la première fois que je vois 
fonctionner dans mon ombre, et cela me rend très triste.
Si cela intéresse quelqu’un, j’ai créé une image arm64 et l’ai poussée vers womble/discourse-mail-receiver:arm64, pour dépanner les gens en attendant que l’équipe principale puisse créer une image officielle. Consultez le README de ma branche pour plus de détails sur les limitations (pas de socketee pour l’instant ; je l’ajouterai si quelqu’un dit en avoir besoin), comment l’utiliser et comment signaler les problèmes (c’est-à-dire « dites-le-moi, pas à l’équipe principale »).
6 « J'aime »
J’ai créé une PR supprimant socketee Remove socketee support by Firefishy · Pull Request #28 · discourse/mail-receiver · GitHub
Je serais également heureux de créer une PR pour aligner mail-receiver avec le processus de build ARM64 utilisé par discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub
1 « J'aime »