لوحة المتصدرين

يُعتبر خادوما الويب Apache و Nginx الأكثر شهرةً من بين الخواديم المفتوحة المصدر في عالم الشبكة العنكبوتيّة، على اعتبار أنّهما مسؤولان عن خدمة وتأمين نصف تدفّق البيانات على الإنترنت، وعلى مَقدرة على تولّي مُختلف حجوم الأحمال، والعمل مع برمجيات أخرى في سبيل توفير حزمة من خدمات الويب الشاملة والكاملة لتلبية مُختلف الاحتياجات. بينما يَتشارك الخادومان Apache و Ngnix العديد من الميّزات والخاصيّات، فلا يُمكن اعتبارهما مُتشابهان، أو التفكير بأن أحدهما هو بديل عن الآخر، فكل منهما يتفّوق عن الآخر بشيءٍ ما، وعلى مُدير النظام فهم وإدراك لماذا يجب اختيار أحدهما دون الآخر، فهذا الدليل يَهدف إلى مُناقشة كيف أنّ كُل خادوم يَتميّز ويَبرز في شيء ويُخفق في آخر. مقدّمة عامّةسيتمّ أخذ نظرة سريعة عن تاريخ وبداية المشروعين وخواصّهم العامّة قبل التعمّق في الاختلاف بينهما. تاريخ خادوم الويب Apacheأَنْشَأَ “روبت ماك كول” (Robert McCool) “خادم الـ HTTP أباتشي” (Apache HTTP Server) في عام 1995، وتمّ مُتابعة تطويره تحت مظلّة “مُنشأةُ برمجيات أباتشي” (Apache Software Foundation) مُنذ العام 1999، وكان هذا الخادم هو المشروع الأساسي للمُنشأة والأكثر شهرةً عن باقي البرمجيات، فأصبح ببساطة يُشار إليه بالاسم “Apache”. يُعتبر خادم الويب أباتشي الخادم الأكثر استخدامًا على الإنترنت منذ العام 1996، وبسبب هذه الشهرة، استفاد أباتشي من توثيق ودعم باقي مشاريع البرمجيات الأُخرى. يَختار مُدراء الأنظمة الخادم أباتشي غالبًا بسبب مرونته، وقُدرته على التحمّل، وتوفّر دعمه العالي والمُنتشر، كما يُحسب له قابليته على التوسّع عبر نظام الوحدات (modules) الديناميكيّة، واستطاعته على مُعالجة عدد كبير من اللغات المُفسّرة (interpreted languages) من دون الحاجة إلى برمجيّة مٌستقلّة وسيطة. تاريخ خادوم الويب Nginxبَدأ “ايجور سيسيوﭫ” في عام 2002 العمل Nginx للإجابة وحلّ المُشكلة المعروفة بالاسم C10K، والّتي كانت تُشكّل تحدّيًا كبيرًا لخوادم الويب لتُصبح قادرة على تولّي عشرة آلاف اتصال مُتزامن (concurrent) وذلك في تلبية حاجة الويب الحديث، وأُنتجت الإصدارة الأوليّة والمُتاحة للعُموم في عام 2004 مُقدمةً حلًا لهذه المُشكلة، وذلك بالاعتماد على معماريّة مدفوعة بالحالة (event-driven) ولا مُتزامنة. انتشر Nginx كالنار في الهشيم مُنذ إصداره، بمُقتضى خفته واستخدامه الخفيف للمَوارد، وقدرته على التوسّع وتحمّل الضغط العالي وبأقل عتاد مُمكن، وتفوّق Nginx بتأمين المُحتوى الثّابت (static content) بسرعة، وبتصميمه لتمرير الطلبات الديناميكيّة (المُتغيّرة) إلى برمجيات أُخرى قادرة على مُعالجة هذا النوع من المُحتوى. يختار مُدراء الأنظمة الخادم Nginx غالبًا بسبب استهلاكه الأمثل للمَوارد، واستجابته العالية مع الضغط المتزايد. معماريّة مُعالجة الاتصال (Connection Handling Architecture)يَكمن الاختلاف الواضح بين أباتشي و Nginx في طريقة كلٍ منهما في مُعالجة الاتصالات وتدفّق البيانات (traffic)، وربّما هذا السبب وراء الاختلاف في طريقة كل من الخادمين في الاستجابة إلى حالة تدفّق البيانات المُختلفة. وحدات أباتشي (Apache Modules)يقدّم أباتشي تشكيلةً من وحدات المُعالجة المُتعدّدة (multi-processing)، والّتي يُطلق عليها بـ MPMs، والغرض منها تحديد آليّة مُعالجة طلبات العميل، ويَسمح ذلك مُدراء الأنظمة عامّةً بالتبديل بين معماريّة مُعالجة الاتصال بسهولة، والوحدات هي: mpm_prefork: تَستنسخ وتُوالد هذه الوحدة الخاصّة بالمُعالجة عمليّات (processes) باستخدام سلسلة وحيدة (single thread)، على أنّ تكون كل عمليّة لمُعالجة طلب، ويستطيع كل ابن مُعالجة اتصال واحد في نفس الوقت، وطالما أنّ عدد الطلبات أقل من عدد العمليّات، فستكون هذه الوحدة سريعةً جدًا، ولكن يَنخفض الأداء بسرعة بعد تخطّي الطلبات عدد العمليّات، ولذلك لا يُعتبر هذا النمط بالخيار الجيّد للعديد من السيناريوهات، فكل عمليّة لها تأثير بليغ على استهلاك الذاكرة (RAM)، ولهذا السبب تُصعّب هذه الوحدة من عمليّة التوسّع بطريقة مُلائمة، ومع هذا تبقى هذه الوحدة خيارًا جيّدًا إن تمّ استخدامها مقترنةً مع مُقوّمات (components) أُخرى لم تُبنى بالأساس آخذةً بعين الاعتبار السلاسل (threads)، فلغة PHP ليست سلسلة آمنة (thread-safe)، ولذلك يُنصح بهذه الوحدة باعتبارها الطريقة الوحيدة الآمنة للعمل مع mod_php والّتي هي وحدة من وحدات أباتشي لمُعالجة هذا النوع من الملفّات. mpm_worker: تستنسخ وتُوالد هذه الوحدة عمليّات (processes) كل منها ذات قُدرة على إدارة سلاسل مُتعدّدة (multiple threads)، تستطيع كل واحدة من هذه السلاسل مُعالجة اتصال وحيد، تُعتبر هذه السلاسل أكثر كفاءة من العمليّات، بسبب أنّ هذه الوحدة تتوسّع (scales)، وتتحمّل المزيد من الضغط أفضل من الوحدة prefork MPM، وباعتبار أنّه يوجد سلاسل أكثر من العمليّات، فهذا يعني أيضًا أنّ الاتصالات الجديدة تستطيع مُباشرةً استهلاك واستخدام سلسلةبدلًا من اضطرارها إلى الانتظار لتوفّر عمليّة مُتاحة. mpm_event: تَعمل هذه الوحدة بشكل مُشابه إلى الوحدة worker، ولكنها مُحسّنة لتتولّى اتصالات keep-alive، فعند استخدام الوحدة worker فإن الاتصال سيَحتفظ بالسلسلة (thread) بصرف النظر فيما إذا كان الطلب نشطًا فيما صُنع من أجله ما دام الاتصال محفوظًا نشطًا، فالوحدة mpm_event تتولّى الاتصالات keep-alive بالاحتفاظ جانبًا بسلاسل مكرّسة لمُعالجتها، وبتمرير الطلبات النشطة إلى سلاسل أُخرى، وهذا من شأنه أنّ يُبعد الوحدة من الغوص بطلبات keep-alive، الأمر الّذي يُجيز بتنفيذ الطلبات (execution) بشكل أسرع، وهذا الأسلوب أصبح يعمل بشكل مُستقر مع الإصدار Apache 2.4. أصبح الأمر أكثر وضوحًا، حيث تقدّم خوادم أباتشي بنية معماريّة مرنة للاختيار بين مُختلف الاتصالات وخوارزمية مُعيّنة في مُعالجة الطلبات، وبُنيت هذه الخيارات في الدرجة الأولى من تطوّر الخادم والحاجة المُتزايدة للاتصالات المُتزامنة لتواكب طبيعة الإنترنت بعد تغيرها وتطوّرها. آليّة مُعالجة الاتصال في خادوم Nginxقَدِم Nginx إلى عالم خوادم الويب بعد قدوم أباتشي، مَبنيًّا ومُعدًّا لمشاكل الاتصالات المُتزامنة (concurrency) الّتي تواجه المواقع عند التوسّع، مُحمّلًا بهذه المعرفة، صُمّمَ Nginx من جذوره ليستخدم خوارزميّة في مُعالجة اتصالات مدفوعة بالحالة (event-driven)، غير مُستوقفة (non-blocking)، ولا مُتزامِنة. يستنسخ ويُوالد Nginx من العمليّات العاملة (worker processes)، ويستطيع كلٍ مِنها مُعالجة آلاف الاتصالات، وتُنجذ العمليّات العاملة ذلك عن طريق تطبيق/تنفيذ آلية حلقيّة سريعة، والّتي تفحص بشكل مُستمر حالات العمليّات (processes events)، وإن فصل المُهمّة الفعليّة عن الاتصالات يسمح لكلعامل بالاهتمام بنفسه باتصال فقط عند بدء حالة جديدة. يتموضع كل اتصال مُعالج من قبل العامل ضمن حلقة الحالة (event loop) في مكان تواجد بقية الاتصالات، وتُعالج الأحداث بشكل لا مُتزامن ضمن الحلقة، ليتمّ إنجاز المُهمّة بطريقة غير مُستوقفة (non-blocking)، وعندما يُغلق الاتصال سيتمّ نزعه من الحلقة. يَسمح هذا الأسلوب من مُعالجة الاتصال Nginx بتحمّل الضغط العالي بشكل لا يُصدّق وبأقل المَوارد المُتاحة، وباعتبار أنّ الخادم ذو سلسلة وحيدة (single-threaded) ولا تتوالد العمليّات لتُعالج كل اتصال جديد، فإن استهلاك المُعالج (CPU)، والذّاكرة يبقى ثابتًا نسبيّا، حتّى في أوقات الذروة. كيف يُعالج أباتشي و Nginx المُحتوى الثّابت والمحتوى الديناميكي (المُتغيّر)إن أبرز ما يتمّ النظر إليه عند المُقارنة بين الخادمين هي طريقة كلٍ منهما في التعامل مع طلبات المُحتوى الثّابت (static)، والمُحتوى المُتغيّر (dynamic). كيف يتعامل أباتشي مع المُحتوى الثّابت والمُتغيّرتستطيع خوادم أباتشي التعامل مع المُحتوى الثّابت باستخدام الطريقة التقليديّة المُعتمدة على الملفّات، ويعود أداء هذه الإجراءات (operations) في الدرجة الأولى على دور ووظيفة أساليب الوحدات (MPM) المشروحة سابقًا. يستطيع أباتشي أيضًا مُعالجة المُحتوى الديناميكي (المُتغيّر) بدمج مُعالج اللغة المُراد مُعالجتها داخل كل من نماذجه العاملة (worker instances)، وهذا يَسمح له بتنفيذ المُحتوى الديناميكي داخل خادم الويب نفسه بدون الحاجة إلى الاعتماد على مُقوّمات خارجيّة، ومن المُمكن تفعيل هذه المُعالجات الديناميكيّة (المُتغيّرة) من خلال استخدام وحدات قابلة للتحميل بشكل ديناميكي. إن قدرة أباتشي على مُعالجة المُحتوى الديناميكي بشكل داخلي تعني أنّ الإعداد يُصبح أسهل لمُعالجة هذا النوع من المُحتوى، فليس من الضروري تنسيق عمليّة الربط مع برمجيات إضافيّة، وتستطيع الوحدات وبسهولة أنّ تقوم بالتبديل عندما تتغيّر مُتطلّبات المُحتوى. كيف يتعامل Nginx مع المُحتوى الثّابت والمُتغيّرلا يَملك Nginx بطبيعته أي قدرة على مُعالجة المُحتوى الديناميكي، ولمُعالجة شيفرة PHP وطلبات المُحتوى الديناميكي، فإن على Nginx تمرير الطلبات إلى مُعالج خارجي من أجل التنفيذ (execution) والانتظار ريثما يتم الانتهاء من مُعالجة هذا المُحتوى ليتمّ إعادة إعادته، ومن ثم عرض النتائج على العميل. يَنبغي على مُدراء الأنظمة الانتباه إلى أنّ الأسلوب الّذي ينتهجه Nginx يستوجب إعدادًا بينه وبين المُعالج وباستخدام واحدًا من البرتوكولات الّتي يفهمها Nginx أمثال: HTTP, FastCGI, SCGI,uWSGI, memcache، وهذا من شأنه أنّ يُعقّد الأمور بعض الشيء، خصوصًا عند مُحاولة توقّع عدد الاتصالات اللازم السماح بها، حيثُ أنّه سيتمّ استخدام اتصالًا إضافيًا لكل مُعالج يتمّ استدعاؤه. من ناحية أخرى، إن هذا الأسلوب يقدّم بعضًا من الأفضليّة، عندما نعلم أنّ مُفسّر المُحتوى الديناميكي غير مُدمج في عمليّة العامل، وتكلفة هذه الطريقة ستُدفع للمُحتوى الديناميكي فقط، وعلى أنّ يُقدّم المُحتوى الثّابت بطريقة مُباشرة، ولا يتمّ الاتصال بالمُفسر إلا عند الحاجة، والجدير بالذكر أنّ أباتشي يستطيع العمل بهذا الأسلوب، ولكن بعمله ذلك سيتخلّى عندها عن بعض ميزاته. الاختلاف بين الإعداد الموزّع (Distributed) والإعداد المركزي (Centralized)يَعتبر مُدراء الأنظمة الاختلاف الأكبر والبارز بين هذين الخادمين هو فيما إذا كان الإعداد والتخصيص على مُستوى المسار مسموحًا أو لا ضمن مسارات (directories)المُحتوى. فلسفة Apache في الإعداديُضمّن أباتشي خيارًا للسماح بالإعداد لكل مسار عن طريق تَفحُّص (inspecting) وتفسير (interpreting) التعليمات أو التوجيهات الموجودة في الملفات المخفيّة داخل مسارات المُحتوى نفسها، وهذه الملفّات معروفة بملفات .htaccess. باعتبار أنّ هذه الملفّات تَقطن داخل مسارات المُحتوى نفسها، فعند مُعالجة طلبٍ ما، فإن أباتشي يَفحص كل جزء من مسار الملفّ المطلوب باحثًا عن ملفّ .htaccess ليُطبّق التوجيهات الّتي بداخله، وهذا من شأنه أنّ يسمح للإعداد اللامركزي لخادم الويب، والذي غالبًا ما يُستخدم لإنجاز: إعادة كتابة عنوان الموقع (URL rewrites)تقييد الوصول (access restrictions)التفويض والمُصادقة (authorization and authentication)سياسات التخبئة (caching policies)بالطبع يُمكن للأمثلة السابقة إعدادها عن طريق ملفّ إعدادات أباتشي الرئيسي، ولكن استخدام ملفات.htaccess يَملك بعض الميزات: أوّلًا، باعتبار أنّها تُفسّر في كل مرّة توجد بها مع المسار المطلوب، فهي تُنفّذ مُباشرةً بدون إعادة تحميل الخادم.ثانيًا، تجعل من المُمكن السماح للمُستخدِمين غير المصرّح لهم بالتحكم بجانب معيّن من المُحتوى الخاصّة بهم بدون إعطائهم تحكم كامل لملفّ الإعدادات.يُقدّم هذا النمط من الإعداد طريقة سهلة ونموذجيّة، وخاصّة لبعض برمجيات الويب، مثل أنظمة إدارة المُحتوى (CMS)، لغرض إعداد بيئتها بدون مَنح إذن وصول إلى ملفّ إعدادات مركزيّ، وكما هو معروف يُستخدم هذا الأسلوب مع مزودات الاستضافة المُشتركة (shared hosting providers) لصون والحفاظ على الإعدادات الرئيسية مع إمكانيّة منح العُملاء أفضليّة التحكّم بمسارات مُعيّنة. فلسفة Nginx في الإعدادلا يُفسّر Nginx ملفّات .htaccess، ولا يُقدّم أي آليّة للتعامل مع كل مسار من دون استخدام ملفّ إعدادات رئيسي، قد يبدو هذا الأسلوب أقل مرونةً من أسلوب أباتشي، ولكن من ناحية أُخرى فلهذا الأسلوب أفضليته. إن عدم الاعتماد على نظام ملفّات .htaccess الخاصّ بالإعداد على مستوى المسارات يُقدّم سرعةً في الأداءً، فخادم أباتشي عليه القيام بتفحّص المسار الجذر لكل طلب يصله، وعند وجود ملفّ أو أكثر خلال عمليّة البحث، يتم قراءة محتوياته وتفسيرها، ولكن Nginx لا يفعل ذلك، فهو يخدم الطلبات بسرعة أكبر بالاعتماد على مكان وحيد للبحث عنه. أفضليّة أُخرى مُتعلّقة بالحماية، فإن توزيع ملفّات الإعدادات على مستوى المسارات يوزّع مسؤوليّة الحماية على كل المُستخدِمين، الّذين قد يكونوا في معظم الأحوال غير موثوقون لتولّي هذه المُهمّة بالشكل الأمثل، فعندما يقوم مُدير النظام بتولّي مُهمة التحكم بالخادم ككل، يمنع ذلك من حدوث أخطاء، والتي قد تحدث في حال منح صلاحيات وصول لأطراف أُخرى. يجدر الذكر أنّه من المُمكن تعطيل تفسير ملفّات .htaccess’ فيأباتشي`، في حال أنها تُشكل نوعًا من القلق لمُدير النّظام. الاختلاف بين تفسير الملفّات وتفسير URIلا يقتصر الاختلاف بين الخادومين على ما سبق فقط، فيظهر الاختلاف الآخر في كيفيّة تفسير كلٍ منهما للطلبات (requests) وربطها مع المَوارد المُتواجدة على النّظام. كيف يُفسر Apache الطلباتيقدّم أباتشي القدرة على تفسير الطلب إما كمَورد فيزيائي (حقيقي) على نظام الملفّات (filesystem) أو عنوان URI الّذي قد يحتاج أسلوب أكثر تجرّد، ويستخدم أباتشي بشكلٍ عام للأسلوب الأول كتل (blocks) وهي إما <Directory> أو <Files>، بينما يستخدم كتل <Location>للمَوارد الأكثر تجرّدًا. صُمّم أباتشي من الأساس كخادم ويب، لذلك في مُعظم الأحيان فإن السلوك الافتراضيّ هو تفسير الطلبات كمَوارد نظام ملفّات (filesystem)، حيثُ يبدأ بتتبّع جذر المُستند وإلحاقه بجزئية الطلب متبوعًا باسم المُضيف (host) ورقم المنفذ في مُحاولة لإيجاد الملفّ المطلوب، بمعنى آخر وببساطة، تتمثّل هرميّة نظام الملفّات على الويب كشجرة مُستند. يُقدّم أباتشي عددًا من البدائل عندما لا يتوافق الطلب مع نظام الملفّات المقصود، فمثلًا من المُمكن استخدام الموجّه Alias لربط عنوان البديل، مع العلم أنّ استخدام الكتل <Location> هو طريقة للتعامل مع URI نفسها بدلًا من نظام الملفّات، كما يُمكن استخدام التعابير النمطيّة (regular expression)، والّتي من المُمكن استخدامها لتطبيق الإعداد بسهولة أكبر في كامل نظام الملفّات. يُعوّل أباتشي على نظام الملفّات بشكل كبير، يظهر ذلك جليًا في اعتماده على ملفّات .htaccessلإعداد كل مسار، حتّى أنّ التوثيق الرسميّ الخاصّ به يحذر من استخدام كتل مُعتمدة على URI في تقييد الوصول عندما يكون الطلب يَعتمد بشكل أو بآخر على نظام الملفّات. كيف يُفسّر Nginx الطلباتأُنشِأ Nginx ليكون خادمًا للويب وخادمًا وكيلًا/وسيطًا (proxy server)، ونظرًا إلى المعماريّة المطلوبة للعمل بهذه الأدوار، فإنه يعمل بشكل رئيسي مع URIs، والتحويل إلى نظام الملفّات عند الضرورة. يُمكن رؤية ذلك في بعض جوانب بناء وتفسير ملفّات إعدادات Nginx، فلا يوفّر Nginx آليّة لتحديد إعدادًا لمسار نظام الملفّات، بل يَستعيض عنها بتحليل URI نفسه. يُمكن توضيح ذلك بالمثال، كتل الإعداد الأوليّ لـ Nginx هي: server و location، الكتلة serverتُفسّر المُضيف الجاري طلبه، بينما الكتل مسؤولة عن مُطابقة أجزاء من URI التي تأتي بعد المُضيف والمنفذ، في هذه المرحلة يتمّ تفسير الطلب كـ URI، وليس كعنوان على نظام الملفّات. يتوجّب في نهاية المطاف على جميع الطلبات أنّ تُربط مع عنوان على نظام الملفّات وذلك للملفّات الثّابتة، فأولًا، سيَختار Nginx كتل server و location الّتي سوف تتولّى الطلب، ومن ثم ضم جزر المُستند مع الـ URI. إن تحليل ومُعالجة الطلب قبل كل شيء على شكل URIs بدلًا من عناوين نظام الملفّات يَسمح لـ Nginxالعمل بسهولة وعلى حدٍّ سواء كخادم وسيط (بروكسي)، وكخادم بريد، وخادم ويب، فقد تمّ إعداده ليُلائم كيف له أنّ يستجيب لأنماط الطلبات المُختلفة، ولا يفحص Nginx نظام الملفّات حتّى يكون جاهزًا ليَخدم الطلب، وهذا يُفسّر لماذا هو لا يُطبّق نمط ملفّات .htaccess. الوحداتيتوسع كلا الخادومان عن طريق نظام الوحدات، ولكن طريقة عملهما تختلف عن الآخر بشكل كبير. كيف يستخدم أباتشي نظام الوحدات (Modules)؟يَسمح نظام وحدات أباتشي بطريقة آليّة وديناميكيّة بتركيب ونزع الوحدات ليتناسب مع مُتطلّبات مُدير النظام خلال عمليّة تشغيل الخادم، وتتواجد نواة أباتشي دائمًا بكل جاهزية، بينما يُمكن تشغيل أو تعطيل الوحدات، أو حتّى حذفها أو إضافة ما يلزم إلى الخادم. يستخدم أباتشي الوحدات في العديد من المهام، ونظرًا للباع الطويل لمنصة أباتشي، فيتوفّر عدد هائل من مكتبات الوحدات، والّتي من المُمكن استخدامها في تعديل بعض الوظائف الداخليّة في بنية خادم أباتشي، فمثلًا الوحدة mod_php تقوم بدمج مُفسّر PHP داخل كل عامل (worker). لا تنحصر الوحدات لمُعالجة المُحتوى الديناميكي (المُتغيّر) فقط، فيُمكن استخدامها في العديد من الوظائف، فيُمكن استخدامها في: rewriting URLs: إعادة كتابة العناوينauthenticating: المُصادقةlogging: التّتبّعcaching: التخبئةcompression: الضغطproxying: الوساطةencrypting: التشفيركيف يتعامل Nginx مع نظام الوحدات (Modules)يُطبّق ويتعامل Nginx مع نظام الوحدات، ولكن يختلف الأمر عما هو في نظام أباتشي، فلا تُحمّل الوحدات بشكل ديناميكي في نظام Nginx، لذلك يجب على هذه الوحدات أنّ تُختار وتُترجم (compiled) إلى النواة. قد يبدو الأمر صعبًا للعديد من المُستخدمين وخاصّة لهؤلاء الذين لا يُحبذون صيانة برمجياتهم المُترجمة (compiled) بدون الاستعانة بنظام حزم تقليدي، وعلى الرغم من أنّ حزم الموزّع تتضمّن الوحدات الأكثر استخدامًا، ولكن عند الحاجة إلى وحدة غير شائعة، سيتوجب على مُدير النظام بناء الخادم من المصدر بنفسه. تَبقى وحدات Nginx مع ذلك ذات فائدة، وتسمح لمُدير النّظام بتحديد ماذا يجب على الخادم أنّ يحتوي من وظائف، أيضًا بعض المُدراء ينظر إلى الأمر من منظور الحماية، حيثُ أنّ المُكوّنات الاعتباطيّة لا يُمكن أن تُدرج داخل الخادم. تُقدّم وحدات Nginx مقدرات مُماثلة للوحدات الّتي المُقدّمة من أباتشي، على سبيل المثال، توفّر وحدات Nginx: proxying support: الوساطةcompression: الضغطlogging: التّتبّعrewriting: إعادة كتابة العنوانauthentication: المُصادقةencryption: التشفيرالدعم والتوافُقيّة والتوثيقيجب دائمًا التأكد من آليّة بناء الخادم ومُتطلباتها، وما الّذي على مُدير النّظام عمله لبناء خادم يعمل بأبسط الإمكانيات، وما هو حجم الدعم والمُساعدة المتوفّر لهذه البرمجية. الدعم في أباتشييُعرف الخادم أباتشي بباعه الطويل في هذا المجال، ولذلك فإن الدعم الخاصّ به متواجد وبقوّة، حيثُ يتوفّر توثيق مُمتاز لمكتباته الخاصّة به ومكتبات الطرف الثالث (الخارجيّة)، وعلى كافّة المُستويات، سواء كان لنواة الخادم أو للجزئيات المُرتبطة ببرمجيات أُخرى. يتوفّر بجانب التوثيق، العديد من الأدوات ومشاريع الويب لتسريع بدء العمل مع بيئة الخادم، وهي موجودة ضمن المشاريع نفسها أو مُتوفّرة ضمن برمجيات الحزم المعروفة. يَملك أباتشي بشكلٍ عام دعمًا قويًا من قِبل مشاريع الطرف الثالث، وذلك بسبب حصته السوقيّة، وقِدَمه، كما يَملك مُعظم مُدراء الأنظمة بشكل أو بآخر معرفة جيّدة بخادم أباتشي، ليس فقط بسبب انتشاره، ولكن أيضًا بسبب أنّ معظمهم بشكل أو بآخر يستخدم الاستضافة المُشتركة (shared-hosting)، والّتي تعتمد على خادم أباتشي بشكل حصري، لمقدرته الإدارية الموزّعة باستخدام ملفّ .htaccess. الدعم في Nginxيكسب Nginx المزيد من الدعم مع ازدياد المُستخدِمين بسبب أدائه العالي، ولكن يبقى عليه التطوير من نفسه في بعض الجزئيات. قد كان من الصعب إيجاد توثيق مفهوم وواضح بالغة الإنكليزية للخادم Nginx في البداية، نظرًا إلى أنّ تطويره وتوثيقه تمّ بالغة الروسية، ومع ازدياد الاهتمام بالمشروع، أصبح هناك وفرة من المصادر على الموقع الرسميّ وغيره من الدعم الخارجي. أصبح الدعم متوفّرًا أكثر من ذي قبل فيما يخص تطبيقات الطرف الثالث، وبدأت بعض الحزم بتقدم خيارات الإعداد التلقائي سواءً لـ أباتشي أو Nginx، وعند عدم توفّر الدعم، فإن إعداد Nginx مع البرمجيات البديلة عادةً ما يكون واضحًا ومُيسرًا طالما أنّ برمجية الطرف الثالث تملك توثيقًا جيّدًا لمُتطلّباتها. استخدام Apache و Nginx معًاتمّ عرض فوائد وقصور كلا الخادومين، ويجب على مُدير النّظام في هذه المرحلة أنّ يُحدّد أيًا منهما يُناسب احتياجاته، ولكن يجد العديد من المُستخدِمين أنّه من المُمكن تقوية خادوم الويب عند استخدام كلٍ من أباتشي و Nginx جنبًا إلى جنب. إن إتمام هذه الشراكة يتمّ عن طريق تَمَوْضُع Nginx أمام أباتشي كوكيل/وسيط عكسي (reverse proxy)، وهذه يسمح لـ Nginx بمُعالجة جميع الطلبات من العُملاء، الأمر الّذي يَسمح بالاستفادة من سرعة Nginx وقدرته على تولّي عدد كبير من الاتصال في وقتٍ واحد. إن خدمة الملفّات الثّابتة بسرعة كبيرة ومباشرةً إلى العُملاء، هو الأمر الّذي يتفوّق به Nginx، ولكن وللمُحتوى الديناميكي، ملفات PHP مثلًا، سيُوكل Nginx الطلبات إلى أباتشي لمُعالجتها والعودة بصفحة بالنتيجة النهائيّة، ليستطيع Nginx عندها تمرير المُحتوى إلى العميل. يعمل هذا الإعداد بشكل جيّد للعديد من مُدراء الأنظمة، وذلك بسبب أنّه يسمح لـ Nginx ليعمل كآلة فرز وتصنيف، بمعنى أنّه سيتولّى مُعالجة جميع الطلبات طالما أنّه يستطيع ذلك، وتمرير ما لا يستطيع التعامل معه، وبتخفيض الطلبات المطلوب من خادم أباتشي تولّيها، سيُخفف بعضًا من الاستيقاف (blocking) الّذي قد يحدث عندما يستهلك أباتشي المزيد من المُعالج. يَسمح هذا الإعداد أيضًا لمُدراء الأنظمة بالتوسّع عن طريق إضافة خادم خلفي (backend) على حسب الحاجة والضرورة، ومن المُمكن إعداد Nginx لتمرير الطلبات إلى تجمّع (pool) من الخوادم بسهولة، الأمر الّذي يزيد من الأداء والفعاليّة. الختاميُقدّم كلًا من أباتشي و Nginx مُرونة في الاستخدام، وقوّةً في الأداء، والتفضيل بينهما هو لأمرٌ يَعتمد على تقدير مُتطلبات ووظائف الخادم، وعلى مُدير النّظام أنّ لا يسأل: هو أفضل خادم ويب؟، بل السؤال الّذي يجب سؤاله هو، ما هو أفضل خادم ويب لمشروعي الّذي يتطلّب كذا وكذا؟ يوجد بالفعل اختلافات بين المشروعين، هذه الاختلافات من شأنها أن تأثر على الأداء، والقدرات، والوقت المُستغرق في إتمام أي منهما للعمل بالجاهزيّة الكاملة، ولكي يتمّ اختيار الأفضل يُنصح بعمل تسوية أو مقايضة بين المحاسن والمساوئ، ففي نهاية المطاف لا يوجد خادم يُلبي كافة الاحتياجات، ويَكمن الحلّ في ترتيب الأولويات. ترجمة –وبتصرّف– للمقال Apache vs Nginx: Practical Considerations لصاحبه Justin Ellingwood.

مقدمةعندما تقوم بإعداد موقع أو تطبيق ويب تابع لنطاقك Domain فغالبًا ما سترغب بوجود خادوم بريد ليتلقى ويرسل الرسائل الإلكترونية الموجه منه وإليه، ومع أنه من الممكن تشغيل خادوم بريد خاص بك إلا أن هنالك العديد من الأسباب التي قد لا تجعل من ذلك الخيار الأفضل، تستعرض هذه المقالة العديد من الأسباب التي قد تجعلك غير راغبٍ بتشغيل خادوم بريد خاص بك، بالإضافة لاستعراض بعض البدائل. إن كنت لا ترغب بقراءة كامل المقال فإليك هذه الخلاصة: إنّ إعداد خادوم بريد وصيانته أمرٌ معقدٌ ويستهلك الوقت، وهنالك العديد من البدائل معقولة السعر، فالكثير من الناس سيكسبون أكثر إن وفّروا وقتهم مقابل استخدامهم خادوم بريد مأجور. على هذا الأساس أكمل قراءة المقال إن ترغب بالحصول على معلومات أكثر. خواديم البريد معقدةيتألف أي خادوم بريد من العديد من المكونات البرمجية التي تقوم بوظائف محدّدة، كل مكوّنٍ يجب أن يُهيئ ليعمل بشكل صحيح وبتناغم مع باقي المكوّنات ليقدّموا خادوم بريد يعمل بكامل مزاياه. ولأن خواديم البريد تملك العديد من الأجزاء المتحركة فإنها تكون معقّدة وصعبة الإعداد. فيما يلي قائمة بالمكونات المطلوبة في خادوم البريد الإلكتروني: وكيل نقل البريد Mail Transfer Agent واختصارًا MTA. وكيل تسليم البريد Mail Delivery Agent واختصارًا MDA. خادوم IMAP و/أو خادوم POP3 وبالإضافة للمكونات المطلوبة فغالبًا ما سترغب في إضافة المكونات التالية: مرشح للرسائل المزعجة Spam Filter مضاد فيروسات AntiVirus تطبيق ويب للوصول للبريد Webmail ومع أنّ بعض الحزم البرمجية تتضمّن وظائف عدّة مكونات فإن اختيار كل مكوّن يعود لك. بالإضافة للمكونات البرمجية فإن خادوم البريد يحتاج إلى نطاق وسجلات نظام أسماء النطاقات DNS بالإضافة لشهادة حماية SSL. سنستعرض فيما يلي معلومات أوفى عن كل مكوّن. وكيل نقل البريد MTAيعالج وكيل نقل البريد رسائل برتوكول إرسال البريد البسيط Simple Mail Transfer Protocol واختصارًا SMTP، ويُعنى بوظيفتين: إرسال البريد من مستخدمي خادوم البريد الخاص بك إلى وكيل نقل بريد خارجي، أي إلى خادوم بريد آخر. استقبال البريد من وكيل نقل بريد خارجي. أمثلة على البرمجيات التي تقوم بوظيفة وكيل نقل البريد: بوست فيكس Postfix، إكزم Exim، سيند ميل Sendmail. وكيل تسليم البريد MDAيدعى وكيل تسليم البريد أيضًا بوكيل التسليم المحلي Local Delivery Agent واختصارًا LDA ويقوم باستلام البريد من وكيل نقل البريد وتخزينه في صندوق بريد المستخدم المعني. هنالك عدّة تنسيقات لصندوق البريد الإلكتروني كتنسيقي ميل بوكس mbox وميل دايَر Maildir. يدعم وكيل تسليم البريد تنسيقات صندوق بريد محدّدة، حيث تحدّد طريقة تخزين الرسائل على خادوم البريد بحسب تنسيق صندوق البريد المستخدم، والذي ينعكس على المساحة المستخدمة من وحدة التخزين وعلى أداء الخادوم عند الوصول إلى صندوق البريد. أمثلة على البرمجيات التي تقوم بوظيفة وكيل تسليم البريد: بوست فيكس، دوف كوت Dovecot. خادوم IMAP و/أو POP3إنّ IMAP و POP3 برتوكولان يستخدمهما تطبيقات البريد Mail Client، وتطبيقات البريد هي أي برمجية تستخدم لقراءة الرسائل الإلكترونية وجلبها. ولكل من هذين البرتوكولين تعقيداته إلا أننا سنلقي الضوء فيما يلي على أهم الفوارق الأساسية: IMAP هو البرتوكول الأكثر تعقيدًا والذي يسمح بالعديد من الأمور بما فيها الوصول إلى صندوق بريد من قبل أكثر من تطبيق بشكل متزامن، بحيث تُرسل نسخ من الرسائل الإلكترونية إلى التطبيقات فيما تبقى الرسائل الأصلية مخزّنة على خادوم البريد. أما POP3 فهو برتوكول أبسط ينقل الرسائل الإلكترونية إلى الحاسب المشغل لتطبيق البريد، والذي يكون في العادة حاسب المستخدم. أمثلة على البرمجيات التي تقدم وظائف برتوكولي IMAP و POP3 على طرف الخادوم: كورير Courier، دوف كوت، زيمبرا Zimbra. مرشح الرسائل المزعجة (سبام) Spam Filterإنّ الهدف من مرشح سبام تقليل عدد رسائل سبام الواردة إلى صندوق بريد المستخدم، والتي تدعى أيضًا رسائل جنك Junk. تنجز مرشحات سبام هذا العمل عبر تطبيق قواعد كشف رسائل سبام على الرسائل الواردة، حيث تأخذ تلك القواعد العديد من العوامل بعين الاعتبار كالخادوم الذي أرسل الرسالة ومحتوى الرسالة وما إلى هنالك. فإن بلغ مستوى سبام “ Spam Level” الخاص بالرسالة مستوىً معين فستُعد الرسالة رسالة سبام وتعامل على ذلك الأساس. يمكن تطبيق مرشحات سبام على الرسائل الصادرة أيضًا، ويفيد ذلك إن كان حساب بريد أحد المستخدمين خطرًا فيقلل المرشح من عدد رسائل سبام التي قد ترسل من ذلك الحساب باستخدام خادوم البريد الخاص بك. SpamAssassin هو مرشح سبام مشهور ومفتوح المصدر. مضاد الفيروسات AntiVirusيستخدم مضاد الفيروسات لكشف الفيروسات Viruses والتروجانات Trojans والبرمجيات الخبيثة malware وأي تهديد في الرسائل الصادرة أو الواردة. ClamAV هو مضاد فيروسات مشهور ومفتوح المصدر. تطبيق ويب للوصول للبريد (ويب ميل) Webmailالعديد من المستخدمين يتوقعون أن توفّر خدمة البريد الإلكتروني الخاص بهم امكانية الوصول للبريد عبر تطبيق ويب. عند الحديث عن تشغيل خادوم بريد فإن الويب ميل هو تطبيق بريد يمكن للمستخدمين الوصول اليه عبر متصفح الويب، وقد يكون Gmail أكثر الأمثلة شهرةً عن الويب ميل. يتطلّب Webmail خادوم ويب مثل Nginx أو Apache يمكن تشغيله على نفس خادوم البريد الإلكتروني. أمثلة عن البرمجيات التي تقدم وظيفة ويب ميل: راوند كب Roundcube و كيتاديل Citadel. الصيانة تستهلك الوقتوالآن بعد أن اطّلعتَ على مكونات خادوم البريد التي عليك أن تثبتها وتهيئها، سنتعرف على السبب وراء كون الصيانة تستهلك الكثير من الوقت. هنالك مهام واضحة للصيانة كالإبقاء على مضاد الفيروسات وقواعد التصفية وكل مكونات خادوم البريد محدّثةً باستمرار ولكن يوجد أيضًا بعض المهام الأخرى التي قد لا تخطر على بالك. تجنّب القوائم السوداء Blocklistsيمثّل ابقاء خادوم البريد الخاص بك بعيدًا عن القوائم السوداء تحدٍ آخر لصيانة الخادوم، تُعرف تلك القوائم أيضًا بقوائم DNS السوداء DNSBL وأيضًا قوائم الثقب الأسود Blackhole Lists. تحوي تلك القوائم على عنوان الانترنت IP الخاص بخادوم البريد الذي أرسل رسالة سبام، أو الذي يملك سجلات DNS مهيّئة بشكل غير صحيح. العديد من خواديم البريد تشترك بواحدة أو أكثر من تلك القوائم وتصفي الرسائل الواردة اليها اعتمادًا على وجود الخادوم المرسل في تلك القوائم أو عدمه. إن أُدرج خادوم البريد الخاص بك ضمن القوائم السوداء فإن الرسائل الصادرة منه قد تصفى وتهمل قبل وصولها إلى مستلميها المقصودين. إن أُدرج خادوم البريد الخاص بك على القوائم السوداء فمن الممكن عادةً أن يزال من عليها. عليك أن تعرف سبب إدراجه وتحل المشكلة وبعد ذلك عليك البحث عن طريقة إزالة خادومك من على القائمة التي تحويه ومن ثم تطبيقها. استكشاف الأخطاء واصلاحها أمرٌ صعبعلى الرغم من أن معظم الناس يستخدمون البريد الإلكتروني كل يوم فمن السهل أن يغفلوا عن حقيقة أنه نظامٌ معقد قد يصعب استكشاف أخطائه وإصلاحها. فمثلًا إن لم تستقبل رسائلك المرسلة فمن أين تبدأ في حل المشكلة؟ قد تكون المشكلة في تهيئة أحد المكونات العديدة لخادوم البريد بشكل خاطئ كضبط مرشح سبام للرسائل الصادرة بشكل خاطئ أو قد تكون المشكلة خارجية كأن يُدرج خادومك على القوائم السوداء. بدائل أسهل - خدمات بريدالآن بعد أن تعرّفت على الأسباب التي قد تجعلك لا ترغب بشغيل خادوم بريد خاص بك اليك بعض البدائل. غالبًا ما ستلبي خواديم البريد التالية احتياجاتك وستتيح لك ولتطبيقاتك إرسال واستقبال الرسائل الإلكترونية من نطاقك: • Google Apps • Zoho • FastMail • Gandi (تتطلب تسجيل النطاق عن طريقهم) • Microsoft Office365 لا تتضمن القائمة السابقة كل خدمات البريد البديلة؛ فهنالك العديد من الخدمات الأخرى ولكل منها مزاياها وأسعارها. احرص على اختيار الخدمة التي توفّر الميزات التي تلبي حاجتك وبالسعر الذي ترغب به. بدائل أسهل - بوست فيكس للبريد الصادرإن كنت تحتاج فقط لإرسال البريد من تطبيقٍ ما على خادومك ولا ترغب في إعداد خادوم بريد كامل المزايا فبإمكانك إعداد وكيل نقل بريد بسيط مثل بوست فيكس. بعد ذلك عليك تهيئة التطبيق الذي تشغله على خادومك لاستخدام تطبيق sendmail كناقل للبريد Mail Transport للرسائل الصادرة. ترجمة - وبتصرّف - للمقال Why you Should Not Run Your Own Mail Server لصاحبه Mitchell Anicas

مقدّمةيعد بوست فيكس Postfix وكيل إرسال البريد MTA وهو تطبيق يُستخدم لإرسال واستقبال الرسائل الإلكترونية. سنتعرّف في هذه المقالة على خطوات تثبيت وتهيئة بوست فيكس حتى تتمكّن التطبيقات المحلية Local Applications من إرسال الرسائل من خلاله، والتطبيقات المحلية هي التطبيقات العاملة على نفس الخادوم Server الذي يشغّل بوست فيكس. لماذا قد ترغب بذلك؟إن كنت تستخدم خدمة بريد إلكتروني لإرسال واستقبال الرسائل فلن تحتاج بالتأكيد لتشغيل خادوم بريد إلكتروني خاص بك. أما إن كنت تدير خادومًا سحابيًا Cloud Server عليه تطبيقات ينبغي عليها إرسال إشعارات عبر البريد الإلكتروني فإن تشغيل خادم SMTP محلي للإرسال فقط يعد بديلًا جيدًا عن استخدام خدمة بريد من مزوّد يشغّل خادوم SMTP كامل المزايا. تطبيق OSSEC هو أحد الأمثلة عن التطبيقات التي ترسل إشعارات عبر البريد الإلكتروني، ترسل تلك التطبيقات رسائل التنبيه لأي عنوان بريد إلكتروني تمت تهيئته. ومع أنّه يمكن لتطبيق OSSEC، أو أي تطبيق من نوعه، أن يستخدم خادوم SMTP من أي مزود خدمة بريد إلكتروني إلا أنه بالإمكان أيضًا أن يستخدم خادوم SMTP محلي (للإرسال فقط). سنتعلم في هذه المقالة: كيفية تثبيت وتهيئة بوست فيكس كخادوم SMTP للإرسال فقط. ملاحظة: إن كنت ستستخدم الخادوم لاستقبال الإشعارات من خادومك على عنوان بريدي وحيد فإن اعتبار رسائلك كرسائل غير مرغوب بها (سبام) ليس بالمشكلة الكبيرة باعتبار أنه بإمكانك إزالتها من ذلك التصنيف Whitelist emails. أما إن كنت ستستخدم الخادوم لإرسال الرسائل لأي مستخدم مرتقب لموقعك، كرسائل تأكيد التسجيل في المنتديات، فعليك حتمًا تنفيذ الخطوة الخامسة حتى تزيد فرص الرسائل في اعتبارها رسائل صالحة legitimate. إن كنت لا تزال تعاني من مشكلة اعتبار رسائل خادوم البريد الخاص بك كرسائل سبام فعليك المضي باستكشاف الأخطاء وإصلاحها بنفسك. المتطلبات الأساسيةيجب توفر المتطلبات الآتية: خادوم Ubuntu. تنفيذ خطوات الإعداد الأساسي للخادوم. يعني ذلك أنه يجب أن يكون لديك حساب مستخدم عادي Standard مع صلاحيات sudo. أن تملك نطاقًا صالحًا Valid Domain مثل example.com مرتبطًا مع خادومك. يجب أن يماثل اسم المضيف Hostname اسم النطاق أو النطاق الفرعي Subdomian. بإمكانك التحقق من اسم المضيف الخاص بخادومك عبر تنفيذ الأمر hostname في الطّرفية. ينبغي أن يكون ناتج تنفيذ الأمر مماثلًا تمامًا للاسم الذي اخترته عند تنصيبك للنّظام مثل example.com. إن كانت كل المتطلبات متوفّرة فأنت جاهزٌ الآن لتنفيذ الخطوة الأولى من هذه المقالة. الخطوة الأولى - تثبيت بوست فيكسستتعلم في هذه الخطوة كيفية تثبيت بوست فيكس. إنّ أكثر الطرق فعاليّةً لتثبيت بوست فيكس والبرامج الأخرى اللازمة لاختبار البريد الإلكتروني هي تثبيت حزمة mailutils package عبر تنفيذ الأمر التالي: sudo apt-get install mailutils إن تثبيت حزمة mailutils سيؤدي إلى تثبيت بوست فيكس بالإضافة إلى بعض البرامج الأخرى اللازمة لبوست فيكس لكي يقوم بوظيفته. بعد كتابة ذلك الأمر سيظهر لك ما يشبه العبارات التالية: The following NEW packages will be installed: guile-2.0-libs libgsasl7 libkyotocabinet16 libltdl7 liblzo2-2 libmailutils4 libmysqlclient18 libntlm0 libunistring0 mailutils mailutils-common mysql-common postfix ssl-cert 0 upgraded, 14 newly installed, 0 to remove and 3 not upgraded. Need to get 5,481 kB of archives. After this operation, 26.9 MB of additional disk space will be used. Do you want to continue? [Y/n] اضغط على زر Enter لتثبيت الحزم. عندما تشارف عملية التثبيت على الانتهاء ستظهر لك نافذة تشبه تمامًا النافذة التي في الصورة أدناه. الخيار الافتراضي هو موقع انترنت Internet Site وهو الخيار الذي سنستخدمه في هذه المقالة لذلك اضغط على زر Tab ثم على زر Enter. بعد ذلك ستظهر لك نافذة أخرى تشبه تمامًا النافذة في الصورة التالية. ينبغي أن يكون اسم نظام البريد System Mail Name مماثلًا للاسم الذي اخترته للدروب ليت عند إنشائك له. إن كان يحوي على نطاق فرعي مثل mars.example.com فعليك تغييره إلى example.com، عندما تنتهي اضغط على زر Tab ثم على زر Enter. بعد اكتمال التثبيت بنجاح نفّذ الخطوة الثانية. الخطوة الثانية - تهيئة بوست فيكسسنشرح في هذه الخطوة كيفية تهيئة بوست فيكس ليعالج طلبات الإرسال الصادرة عن الخادوم الذي يشغله فقط؛ أي من الجهاز المضيف localhost. لتحقيق ذلك ينبغي أن يُهيئ بوست فيكس للتنصت المنفذ (لوب باك) loopback Interface، وهو منفذ شبكة وهمي يستخدمه الخادوم للاتصال الداخلي. لإجراء التغيير، افتح ملف التهيئة الأساسي لبوست فيكس باستخدام محرر النصوص (نانو) nano عبر تنفيذ الأمر التالي: sudo nano /etc/postfix/main.cf بعد فتح الملف مرّر إلى أسفله حتى ترى المتحولات الواردة في المقطع البرمجي (كود) Block Code التالي: mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all عدّل السطر الحاوي على: inet_interfaces = all إلى: inet_interfaces = loopback-only يجب أن يكون شكل المقطع السابق عندما تنتهي مشابهًا لما يلي: mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = loopback-onlyيمكنك أيضًا تعديل المقطع السابق بكتابة localhost عوضًا عن loopback-only وبالتالي سيكون شكل المقطع مشابهًا لما يلي: mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = localhostعندما تنتهي من تعديل الملف، احفظه وأغلقه (اضغط على CTRL + X ثم CTRL + Y ثم اضغط على زر Enter). بعد ذلك أعد تشغيل بوست فيكس عبر تنفيذ الأمر: sudo service postfix restart الخطوة الثالثة - اختبار امكانية إرسال الرسائل عبر خادوم SMTPستقرأ في هذه الخطوة كيف تختبر فيما إن كان بوست فيكس يرسل الرسائل لأي حساب بريدي خارجي. ستستخدم الأمر mail والذي يعد جزءًا من حزمة mailutails التي ثُبتت في الخطوة الأولى. لإرسال رسالة تجريبية أكتب: echo "This is the body of the email" | mail -s "This is the subject line" user@example.com يمكنك عند أداء الاختبار استخدام سطر العنوان وجسم الرسالة كما هو أو أن تغيّره كما تحب. ولكن عليك استخدام عنوان بريد إلكتروني Email صالح مكان user@example.com حيث يمكن أن يكون الجزء الممثّل للنطاق gmail.com أو fastmail.com أو yahoo.com أو أي مزوّد خدمة بريد إلكتروني آخر تستخدمه. تحقّق الآن من صندوق بريد العنوان الذي أرسلت اليه رسالة الاختبار حيث ينبغي أن تجد الرسالة فيه، إن لم تجدها تحقق من مجلد رسائل سبام. ملاحظة: وفق هذه التهيئة، سيكون العنوان في حقل المرسل (من) لرسالة الاختبار التي أرسلتها sammy@example.com حيث sammy هو اسم حساب مستخدم على لينكس والجزء الممثّل للنطاق هو اسم المضيف. إن عدّلت اسم حسابك سيتعدّل عنوان المرسل أيضًا. الخطوة الرابعة - نظام توجيه البريدآخر ما سنقوم بإعداده هو التوجيه، يمكّنك ذلك من تلقي البريد المرسل إلى حساب root على عنوان بريدك الخارجي. حتى نقوم بتهيئة بوست فيكس لإرسال الرسائل التي يولدها النظام إلى عنوان بريدك الإلكتروني، علينا التعديل على الملف: /etc/aliasesعبر تنفيذ الأمر: sudo nano /etc/aliasesيُظهر المقطع البرمجي التالي كامل محتوى الملف وفق الإعدادات الافتراضية لتثبيت أوبونتو 10.04: # See man 5 aliases for format postmaster: rootتُرسل الرسائل التي يولّدها النظام إلى المستخدم root وفق الإعدادات السابقة. إنّ ما عليك فعله هو تعديل ذلك الملف لتوجيه تلك الرسائل إلى عنوان بريدك ولفعل ذلك عدّل على الملف ليصبح كما يلي: # See man 5 aliases for format postmaster: root root: sammy@example.comاستبدل sammy@example.com بعنوان بريدك الإلكتروني وعندما تنتهي احفظ التغييرات ثم أغلق الملف. بعد ذلك نفّذ الأمر التالي حتى تأخذ التغييرات حيّز التنفيذ: sudo newaliasesبإمكانك الآن اختبار فما إن كانت الإعدادات الجديدة تعمل عبر إرسال رسالة إلى حساب root عبر تنفيذ الأمر التالي: echo "This is the body of the email" | mail -s "This is the subject line" rootينبغي أن تستقبل الرسالة على عنوان بريدك الإلكتروني. إن لم تجدها تحقّق من مجلد رسائل سبام. الخطوة الخامسة (اختيارية) - حماية نطاقك من مرسلي رسائل سبامسنستعرض في هذه الخطوة بعض العناوين التي قد ترغب بالبحث عنها وتطبيقها فقد يساعدك ذلك في حماية نطاقك من استخدامه لإرسال رسائل سبام. ومع أن هذه الخطوة اختيارية إلا أننا ننصح بشدّة بتنفيذها، لأنه إن تمّت التهيئة بشكل صحيح فسيكون من الصعب جدًا إرسال رسائل سبام تُظهر أن مصدرها هو نطاقك. إن قيامك بخطوات التهيئة الإضافية التالية سيزيد من فرص اعتبار الرسائل الصادرة عن خادومك كرسائل صالحة legitimate بدلًا من أن تعتبرها مزوّدات خدمة البريد الإلكتروني الشهيرة رسائل سبام: كيفية استخدام سجل SPF لمنع التحايل Spoofing ولتعزيز وثوقيّة البريد الإلكتروني. كيفية تثبيت وتهيئة DKIM مع بوست فيكس. احرص أيضًا على أن يقابل سجل PTR الخاص بخادومك اسم المضيف الذي يستخدمه خادوم البريد عندما يرسل الرسائل. ترجمة للمقال - وبتصرّف - How To Install and Configure Postfix as a Send-Only SMTP Server on Ubuntu 14.04 لصاحبه Finid