أنا في بنية ARM ويُظهر الأمر أعلاه أخطاءً. هل هذا المكون الإضافي غير مناسب لـ arm؟
هل هناك أي مكون إضافي آخر لاستقبال رسائل البريد الإلكتروني لبنية arm؟
أخشى أنني لست على دراية بـ arm، لذلك لا يمكنني تقديم المشورة بشأن ما إذا كان غير مناسب، ولكني أردت فقط أن أشير إلى أن هذا ليس مكونًا إضافيًا. على الرغم من أنني آمل أن يكون مجرد ارتباك في المصطلحات وأنك لا تحاول تثبيته كمكون إضافي لأن ذلك لن ينجح. 
إعجاب واحد (1)
شكرا على الرد. آه، خطئي، اعتقدت أنه يعمل كإضافة. إذا كان له مصطلح مختلف، فيرجى إخباري. يعمل خادمي على arm64، وهي الشرائح الجديدة على ما أعتقد في أمازون ec2.
لقد قمت بتثبيته للتو كما هو موضح في المنشور. لكنه يرمي أخطاء. يبدو أنه لا يعمل على arm64.
إعجاب واحد (1)
للتوضيح فقط، هل تقول إنك نجحت في المرور عبر التثبيت القياسي ولديك نسخة عاملة من Discourse على arm، ولكن إعداد mail-receiver على وجه التحديد يفشل؟
ما هي الأخطاء التي تراها؟ إذا كان بإمكانك تقديم رسائل الخطأ، فقد يساعد ذلك في تحديد السبب. كن حذرًا للتحقق من أي شيء حساس يحتاج إلى إخفاء.
من الصعب بعض الشيء (بالنسبة لي) إعطاؤه مصطلحًا معينًا فيما يتعلق بـ Discourse. في الخلفية، هو مجرد تطبيق حاوية منفصل تمامًا لخادم بريد إلكتروني يستقبل فقط، والذي تم إعداده (عن قصد) لتسليم تلك رسائل البريد الإلكتروني إلى Discourse عبر واجهة برمجة التطبيقات الخاصة به.
إعجابَين (2)
نعم، هذا هو إجراء التثبيت القياسي لتثبيت discourse. ويعمل discourse بشكل جيد على ما أعتقد على arm64.
الأخطاء هي كما يلي:
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.
لقد بدأت في استخدام aws WorkMail في الوقت الحالي، ولكن إذا كان بإمكان discourse توفير ميزة بسيطة لاستقبال البريد الإلكتروني وإنشائه، فمن المؤكد أنه يستحق استخدامه كصندوق بريد رسمي.
لا يوجد شيء اسمه خادم بريد إلكتروني بسيط. يوجد خادم بريد إلكتروني أو لا يوجد. وخوادم البريد الإلكتروني صعبة للغاية، وعرضة بشكل كبير للتحول إلى مراكز بريد مزعج (سبام) ومحظورة في معظم خدمات السحابة/الخوادم الافتراضية الخاصة (VPS).
لهذا السبب سيقوم Discourse بالاستطلاع على خادم بريد إلكتروني حقيقي، والتقاط البريد الإلكتروني وإرساله إلى الوجهة المحددة. إذا قام المسؤول بإعداد ذلك.
إعجاب واحد (1)
أعتقد أنك أسأت فهمي.
أنا لا أشير إلى “إنشاء خادم بريد”. بل إلى وجود واجهة بسيطة ولكنها لطيفة (تجربة مستخدم) لإنشاء (لإرسال رسائل البريد الإلكتروني) وقراءة (رسائل البريد الإلكتروني الواردة)، حتى نتمكن من استخدامها للرد على رسائل البريد الإلكتروني الرسمية التي نتلقاها.
أليس AWS “خدمة البريد الإلكتروني البسيطة (SES)” تتحكم بالفعل في البريد العشوائي وما إلى ذلك؟ كل ما علينا فعله هو توفير تجربة المستخدم في ديسكورس حتى يكون لدينا صندوق بريد بريد لطيف وبسيط، وواجهة إنشاء رسائل.
أنا لست متأكدًا تمامًا مما إذا كان توفير تجربة مستخدم من صفحة واحدة في ديسكورس أمرًا معقدًا (حيث لدينا بالفعل الخادم المدمج فيه ويمكننا استخدام AWS SES عبر ديسكورس أيضًا).
بالنسبة لصورة Discourse الأساسية، فإن أداة launcher تكتشف عند التشغيل على arm64 وتتحول إلى صورة arm64 مع تحذير بأنها تجريبية. الشيء نفسه لا يحدث لـ mail-receiver وبالنظر إلى الصور على Docker Hub، يبدو أن إصدار arm64 غير موجود.
هناك خياران واضحان يتبادران إلى الذهن:
- التبديل إلى مثيل EC2 amd64، مما يمنحك تثبيت Discourse غير تجريبي ويسمح لك بتثبيت
mail-receiverبجانبه. - إضافة مثيل EC2 ثانٍ، أصغر خيار مع amd64 (t3a.nano، أعتقد)، وتثبيت
mail-receiverعليه.
لا يهم أين يوجد mail-receiver، يجب أن يشير سجل DNS MX لعنوان الرد عبر البريد الإلكتروني الخاص بك إليه بشكل موثوق ويجب أن يكون قادرًا على الاتصال بمثيل Discourse الخاص بك.
إذا كان هذا يشير إلى التعامل مع رسائل البريد الإلكتروني إلى عناوين مثل info@yourcompany.com أو sales@yourcompany.com أو support@yourcompany.com وما إلى ذلك، فأعتقد أن المراسلة الجماعية ستمنحك ما تبحث عنه.
هذا يعني، بعد أن نجحت في تشغيل mail-receiver، يمكنك إنشاء مجموعات مناسبة في Discourse ومنح المجموعات عنوان بريد إلكتروني وارد مخصص واحد أو أكثر. عند النظر إلى رسائل المستخدم الخاص بك، سترى صناديق واردة/وغيرها للمجموعات التي تنتمي إليها.
إذا كنت تستخدم هذا النطاق لبريد الموظفين، على سبيل المثال prettygirl@yourcompany.com، فستحتاج إلى إعداد شيء ما مع مزود البريد الإلكتروني الخاص بك للحصول على عناوين معينة (على سبيل المثال، info@) إلى Discourse. اعتمادًا على ما يقدمه مزود البريد الإلكتروني الخاص بك، قد يكون من الصعب إدخال رسائل البريد الإلكتروني في Discourse بعناوين مرسل صحيحة - لا يمكنك ببساطة إعادة توجيهها لأن Discourse سيرى كل شيء على أنه قادم من عنوانك الخاص بدلاً من المرسل الأصلي.
في Microsoft 365 / Exchange، يمكن أن يعمل مزيج من الموصل لتوجيه البريد إلى mail-receiver وقواعد النقل لجعل رسائل بريد إلكتروني معينة تستخدم هذا الموصل.
البريد الإلكتروني صعب، تم تصميم mail-receiver لتبسيط الرد على إشعارات البريد الإلكتروني وإنشاء مواضيع (رسائل جديدة للمجموعات المضمنة في ذلك) حيث لا يتداخل النطاق المستخدم مع خدمات البريد الإلكتروني الحالية. بخلاف ذلك، فإنك تدخل في منطقة متقدمة غير مدعومة، وربما “لم يتم تصميمه للاستخدام بهذه الطريقة”.
إعجابَين (2)
الإجابة على السؤال المطروح في العنوان هي “لا”.
الخيار 1 هو ما فكرت فيه منذ البداية. هذا هو الحل الموصى به والمدعوم في هذه المرحلة.
لقد رأيت مؤخرًا إجراءات على discourse_docker لزيادة الدعم لمعمارية ARM، على ما أعتقد، ولكن يبدو من غير المرجح أن يتم قريبًا إضافة دعم لمستقبل البريد الإلكتروني (mail receiver) على معمارية ARM. ولكن هذا مجرد تخمين. ليس لدي أي سيطرة على الأمر، وهناك الكثير مما لا أعرفه.
الخيار الآخر سيكون معرفة كيفية جعل معمارية ARM تدعم مستقبل البريد الإلكتروني (mail-receiver) وتقديم طلب سحب (PR).
إذا كنت تحب، تحب، تحب معمارية ARM، فيمكنك العثور على مستقبل بريد إلكتروني كامل مع صناديق بريد وكل ذلك وإدارة مجموعة من صناديق البريد.
إعجابَين (2)
بالتأكيد سيكون من الممكن دعم mail-receiver على أنظمة ARM. لا يوجد شيء خاص بـ amd64 هناك (أو على الأقل، لم يكن هناك عندما صنعته، ولا يمكنني تخيل إجراء أي تغييرات كبيرة من شأنها إبطال هذا الافتراض). سيكون الأمر مجرد مسألة قيام القائمين على صيانة صور docker بإنشاء صورة لـ arm64، كما يفعلون بالفعل لـ amd64.
يمكن لشخص ما أيضًا إجراء بناء غير رسمي ووضعه في مكان ما، مع تعليمات حول التغيير المطلوب في سطر واحد لقالب pups، أو يمكنك إجراء بناء محلي خاص بك من المستودع على نظام arm64 الذي تعمل عليه.
5 إعجابات
هناك socketee الذي يتم تنزيله إلى /usr/local/bin من GitHub كجزء من Dockerfile. هذا ثنائي x86_64 لذلك لن يعمل، ومع ذلك يبدو أنه لا يتم استخدامه إلا إذا تم تكوينه بشكل صريح.
على وجه التحديد، ستفشل هذه الميزة أعلاه على arm64 لأن socketee سيفشل في التنفيذ. لا يمكنني رؤية أي شيء آخر لن يعمل ببساطة عن طريق البناء لـ arm64.
أنا لست متأكدًا بنسبة 100٪، ولكن من الملاحظة العابرة، يبدو أن مجرد إضافة هذه الأسطر إلى ملف build قد يفعل ذلك:
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
نعم، لقد استبعدت ذلك من تحليلي لأنه من غير المحتمل للغاية أن يستخدم أي شخص خارج CDCK ذلك، حيث تم تضمينه لغرض متخصص للغاية وهو مركزة سجلات Postfix - وهو شيء من شبه المؤكد أن مستهلك mail-receiver العادي لن يقوم به.
إعجابَين (2)
إذا كان mail-receiver لا يعمل على ARM و IMAP يعمل فقط مع GMail، فهذا محدود للغاية.
هذه هي المرة الأولى التي أرى فيها 
يعمل في الظل الخاص بي، وهذا يحزنني كثيرًا.
إذا كان أي شخص مهتمًا، فقد قمت ببناء صورة arm64 ودفعتها إلى womble/discourse-mail-receiver:arm64، لمساعدة الأشخاص حتى يتمكن الفريق الأساسي من إنشاء بناء صورة رسمي. راجع ملف README الخاص بفرعي لمزيد من التفاصيل حول القيود (لا يوجد socketee في الوقت الحالي؛ سأضيفه إذا قال أي شخص إنه يحتاجه)، وكيفية استخدامه، وكيفية الإبلاغ عن المشكلات (أي “أخبرني، وليس الفريق الأساسي”).
6 إعجابات
لقد قمت بتقديم طلب سحب (PR) لإزالة socketee Remove socketee support by Firefishy · Pull Request #28 · discourse/mail-receiver · GitHub
ويسعدني أيضًا تقديم طلب سحب (PR) للتغييرات اللازمة لمواءمة mail-receiver مع عملية بناء ARM64 المستخدمة بواسطة discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub
إعجاب واحد (1)