تشرح هذه المقالة كيفية تكوين NGINX Plus أو NGINX Open Source كوكيل لخادم البريد أو خدمة بريد خارجية.

مقدمة

يمكن لـ NGINX إنشاء وكيل لبروتوكولات IMAP وPOP3 وSMTP لأحد خوادم البريد الأولية التي تستضيف حسابات البريد، وبالتالي يمكن استخدامها كنقطة نهاية واحدة لعملاء البريد الإلكتروني. وقد يحقق ذلك عددًا من الفوائد، مثل:

• سهولة قياس عدد خوادم البريد
• اختيار خادم بريد بناءً على قواعد مختلفة، على سبيل المثال، اختيار أقرب خادم بناءً على عنوان IP الخاص بالعميل
• توزيع الحمل بين خوادم البريد

المتطلبات الأساسية

قام NGINX Plus (يتضمن بالفعل وحدات البريد اللازمة لتوكيل حركة مرور البريد الإلكتروني) أو NGINX Open Source بتجميع وحدات البريد باستخدام المعلمة --with-mail لوظيفة وكيل البريد الإلكتروني والمعلمة --with-mail_ssl_module لدعم SSL/TLS:

$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1

خوادم بريد IMAP وPOP3 و/أو SMTP أو خدمة بريد خارجية

تكوين خوادم وكيل البريد SMTP/IMAP/POP3

في ملف التكوين NGINX:

بريد ( #... )

البريد (اسم_الخادم mail.example.com; #...)

البريد (اسم_الخادم mail.example.com; auth_http المضيف المحلي: 9000 /cgi-bin/nginxauth.cgi; #...)

وبدلاً من ذلك، حدد ما إذا كان سيتم إعلام المستخدم بالأخطاء من خادم المصادقة عن طريق تحديد التوجيه proxy_pass_error_message. قد يكون هذا مفيدًا عند نفاد ذاكرة صندوق البريد:

البريد ( اسم الخادم mail.example.com ; auth_http المضيف المحلي : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; #... )

قم بتكوين كل خادم SMTP أو IMAP أو POP3 باستخدام كتل الخادم. لكل خادم، حدد:

• ال رقم المنفذالتي تتوافق مع البروتوكول المحدد مع توجيه الاستماع
• ال بروتوكولباستخدام توجيه البروتوكول (إذا لم يتم تحديده، فسيتم اكتشافه تلقائيًا من المنفذ المحدد في توجيه الاستماع)
• مباح طرق المصادقةباستخدام توجيهات imap_auth وpop3_auth وsmtp_auth:

الخادم (استمع 25؛ بروتوكول smtp؛ smtp_auth تسجيل الدخول عادي cram-md5؛) الخادم (استمع 110؛ بروتوكول pop3؛ pop3_auth عادي apop cram-md5؛) الخادم (استمع 143؛ بروتوكول imap؛)

إعداد المصادقة لوكيل البريد

ستتم مصادقة كل طلب POP3/IMAP/SMTP من العميل أولاً على خادم مصادقة HTTP خارجي أو عن طريق برنامج نصي للمصادقة. يعد وجود خادم مصادقة أمرًا إلزاميًا لوكيل خادم بريد NGINX. يمكن إنشاء الخادم بنفسك وفقًا لبروتوكول مصادقة NGINX الذي يعتمد على بروتوكول HTTP.

إذا نجحت المصادقة، فسيختار خادم المصادقة خادمًا رئيسيًا ويعيد توجيه الطلب. في هذه الحالة، سيحتوي الرد من الخادم على الأسطر التالية:

HTTP/1.0 200 موافق حالة المصادقة: موافق خادم المصادقة: # اسم الخادم أو عنوان IP للخادم الرئيسي الذي سيتم استخدامه لمعالجة البريد منفذ المصادقة: # منفذ الخادم الرئيسي

إذا فشلت المصادقة، فسيقوم خادم المصادقة بإرجاع رسالة خطأ. في هذه الحالة، سيحتوي الرد من الخادم على الأسطر التالية:

HTTP/1.0 200 OK Auth-Status: # رسالة خطأ سيتم إرجاعها إلى العميل، على سبيل المثال "تسجيل الدخول أو كلمة المرور غير صالحة" Auth-Wait: # عدد محاولات المصادقة المتبقية حتى يتم إغلاق الاتصال

لاحظ أنه في كلتا الحالتين سيحتوي الرد HTTP/1.0200 موافقوالتي قد تكون مربكة.

لمزيد من الأمثلة على الطلبات والاستجابات من خادم المصادقة، راجع ngx_mail_auth_http_module في وثائق NGINX المرجعية.

إعداد SSL/TLS لوكيل البريد

باستخدام POP3/SMTP/IMAP عبر SSL/TLS، يمكنك التأكد من تأمين البيانات التي يتم تمريرها بين العميل وخادم البريد.

لتمكين SSL/TLS لوكيل البريد:

تأكد من تكوين NGINX الخاص بك بدعم SSL/TLS عن طريق كتابة الأمر nginx -V في سطر الأوامر ثم البحث عن السطر with --mail_ssl_module في الإخراج:

$ nginx -V تكوين الوسائط: ... مع --mail_ssl_module

تأكد من حصولك على شهادات الخادم والمفتاح الخاص ووضعهما على الخادم. يمكن الحصول على الشهادة من مرجع مصدق موثوق (CA) أو إنشاؤها باستخدام مكتبة SSL مثل OpenSSL.

على ;

يبدأ ؛

إضافة شهادات SSL: حدد المسار إلى الشهادات (التي يجب أن تكون بتنسيق PEM) باستخدام توجيه ssl_certificate، وحدد المسار إلى المفتاح الخاص في توجيه ssl_certificate_key:

البريد ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )

يمكنك فقط استخدام الإصدارات والأصفار القوية من SSL/TLS مع توجيهات ssl_protocols وssl_ciphers، أو يمكنك تعيين البروتوكولات والأصفار المفضلة لديك:

mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )

تحسين SSL/TLS لوكيل البريد

ستساعدك هذه التلميحات في جعل وكيل بريد NGINX الخاص بك أسرع وأكثر أمانًا:

قم بتعيين عدد العمليات المنفذة مساويًا لعدد المعالجات التي تم تعيين توجيه عامل_المعالجة لها على نفس مستوى سياق البريد:

عامل_العمليات تلقائي؛ بريد ( #... )

تمكين ذاكرة التخزين المؤقت للجلسة المشتركة وتعطيل ذاكرة التخزين المؤقت للجلسة المضمنة باستخدام تلقائي؛ البريد ( اسم الخادم mail.example.com ; auth_http المضيف المحلي : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. مفتاح ssl_protocols TLSv1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache Shared:SSL:10m ; ssl_session_timeout 10m ; 0 ؛ بروتوكول البوب3 خادم pop3_auth عادي apop cram-md5 (استمع 143 ؛ بروتوكول imap ؛))

في هذا المثال، هناك ثلاثة خوادم وكيل للبريد الإلكتروني: SMTP، وPOP3، وIMAP. تم تكوين كل خادم بدعم SSL وSTARTTLS. سيتم تخزين معلمات جلسة SSL مؤقتًا.

يستخدم الخادم الوكيل خادم مصادقة HTTP - وتكوينه خارج نطاق هذه المقالة. سيتم إرجاع كافة رسائل الخطأ من الخادم إلى العملاء.

iRedMail هو خادم بريد مفتوح المصدر جاهز. يعتمد التجميع على خادم Postfix SMTP (وكيل نقل البريد، والمختصر بـ MTA). يتضمن التجميع أيضًا: Dovecot، وSpamAssassin، وGraylist، وClamAV، وSOGo Roundcube، وNetData، وNGINX.

دوفيكوت - خادم IMAP/POP3.

Spamassassin هي أداة لتصفية البريد العشوائي.

Graylist هي أداة لمكافحة البريد العشوائي تعتمد على القائمة الرمادية.

كلاماف هو مضاد للفيروسات.

Roundcube وSOGo هما من عملاء الويب للعمل مع البريد الإلكتروني.

NetData هو برنامج لمراقبة الخادم في الوقت الحقيقي.

Nginx هو خادم ويب.

يدعم أنظمة التشغيل: CentOS 7 وDebian 9 وUbuntu 16.04/18.04 وFreeBSD 11/12 وOpenBSD 6.4.

يحتوي iRedMail على إصدارات مدفوعة ومجانية تختلف عن بعضها البعض في وظائف واجهة الويب الخاصة بها الخاصة بتجميع بريد iRedAdmin. في الإصدار المجاني، يمكنك فقط إنشاء المجالات وصناديق بريد المستخدم والمسؤول. إذا كنت بحاجة إلى إنشاء اسم مستعار، فلن تتمكن بعد الآن من القيام بذلك في الإصدار المجاني عبر iRedAdmin. لحسن الحظ، هناك حل مجاني يسمى PostfixAdmin يسمح لك بالقيام بذلك. يتم دمج PostfixAdmin بسهولة في iRedMail ويعمل بشكل رائع معه.

تثبيت

للتثبيت، سنحتاج إلى أحد أنظمة التشغيل المذكورة أعلاه. سأستخدم Ubuntu Server 18.04. يجب أن يكون لديك أيضًا اسم مجال تم شراؤه ومنطقة DNS مكونة. إذا كنت تستخدم خادم DNS الخاص بمسجل المجال الخاص بك، فستحتاج إلى إنشاء سجلين في قسم إدارة منطقة المجال: A وMX. يمكنك أيضًا استخدام DNS الخاص بك عن طريق إعداد التفويض في الحساب الشخصي لمسجل اسم النطاق الخاص بك.

إعداد منطقة المجال عند استخدام مسجل DNS

ملحوظة! يتراوح وقت تفعيل إعدادات DNS من عدة ساعات إلى أسبوع واحد. وإلى أن تدخل الإعدادات حيز التنفيذ، لن يعمل خادم البريد بشكل صحيح.

للتثبيت، قم بتنزيل الإصدار الحالي من موقع iRedMail الإلكتروني. حاليا هو 0.9.9.

# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2

ثم قم بفك ضغط الأرشيف الذي تم تنزيله.

# القطران xjf iRedMail-0.9.9.tar.bz2

تفريغ الأرشيف

وانتقل إلى المجلد الذي تم إنشاؤه.

# سي دي آيريد ميل-0.9.9

مجلد تثبيت iRedMail

التحقق من محتويات المجلد

محتويات المجلد

وقم بتشغيل البرنامج النصي لتثبيت iRedMail.

# باش iRedMail.sh

سيبدأ تثبيت نظام البريد. أثناء عملية التثبيت سوف تحتاج إلى الإجابة على عدد من الأسئلة. نحن نتفق على بدء التثبيت.

ابدأ التثبيت

اختيار دليل التثبيت

الآن أنت بحاجة إلى تحديد خادم الويب. ليس هناك الكثير من الخيارات، لذلك اخترنا NGINX.

اختيار خادم الويب

أنت الآن بحاجة إلى تحديد خادم قاعدة البيانات الذي سيتم تثبيته وتكوينه للعمل مع نظام البريد. حدد ماريا دي بي.

اختيار خادم قاعدة البيانات

قم بتعيين كلمة المرور الجذر لقاعدة البيانات.

إنشاء كلمة مرور جذر قاعدة البيانات

الآن نشير إلى مجال البريد الإلكتروني الخاص بنا.

إنشاء مجال البريد

ثم نقوم بإنشاء كلمة مرور لصندوق بريد المسؤول [email protected].

إنشاء كلمة مرور مسؤول البريد

اختيار مكونات الويب

قم بتأكيد الإعدادات المحددة.

تأكيد الإعدادات

بدأ التثبيت.

تثبيت

بمجرد اكتمال التثبيت، قم بتأكيد إنشاء قاعدة iptables لـ SSH وأعد تشغيل جدار الحماية. يعمل iRedMail مع iptables. في Ubuntu، الأداة المساعدة لإدارة جدار الحماية الأكثر استخدامًا هي UFW. إذا كانت لديك مثل هذه الحاجة لسبب أو لآخر، فقم بتثبيت UFW (apt install ufw) وأضف القواعد بحيث لا يمنع UFW (على سبيل المثال: ufw يسمح بـ "Nginx Full" أو ufw يسمح بـ Postfix) عمل خادم البريد. يمكنك عرض قائمة القواعد المتاحة عن طريق تشغيل الأمر: ufw app list . ثم قم بتمكين UFW: تمكين ufw.

إنشاء قاعدة iptables

إعادة تشغيل جدار الحماية

هذا يكمل تثبيت iRedMail. زودنا النظام بعناوين واجهة الويب وبيانات اعتماد تسجيل الدخول. لتمكين كافة مكونات نظام البريد، يجب عليك إعادة تشغيل الخادم.

إكمال التثبيت

دعونا إعادة التشغيل.

# اعادة التشغيل

إعدادات

تحتاج أولاً إلى التأكد من أن كل شيء يعمل. دعنا نحاول تسجيل الدخول إلى لوحة تحكم iReadAdmin على https://domain/iredadmin. تسجيل الدخول [email protected]، كلمة المرور التي تم إنشاؤها أثناء التثبيت. هناك واجهة باللغة الروسية.

كما ترون، كل شيء يعمل. عند تسجيل الدخول إلى iRedAdmin، من المرجح أنك تلقيت خطأ أمنيًا متعلقًا بالشهادة. يحدث هذا لأن iRedMail يحتوي على شهادة موقعة ذاتيًا، والتي يشكو منها المتصفح. لحل هذه المشكلة، يجب عليك تثبيت شهادة SSL صالحة. إذا قمت بشراء واحدة، فيمكنك تثبيتها. في المثال، سأقوم بتثبيت SSL مجاني من Let's Encrypt.

تثبيت شهادة Let's Encrypt SSL

سنقوم بتثبيت الشهادة باستخدام الأداة المساعدة certbot. أولاً، دعونا نضيف مستودعًا.

# add-apt-repository ppa:certbot/certbot

ثم سنقوم بتثبيت certboot نفسه بالمكونات الضرورية.

# apt install python-certbot-nginx

نحصل على شهادة.

# certbot --nginx -d domain.ru

بعد تشغيل الأمر، سيطلب منك النظام إدخال عنوان بريدك الإلكتروني، أدخل. بعد ذلك، ستتلقى على الأرجح خطأً مفاده أنه لا يمكن العثور على كتلة الخادم التي تم إنشاء الشهادة لها. في هذه الحالة، هذا أمر طبيعي، لأنه ليس لدينا أي كتلة للخادم. الشيء الرئيسي بالنسبة لنا هو الحصول على الشهادة.

الحصول على الشهادة

وكما نرى، تم استلام الشهادة بنجاح وأظهر لنا النظام المسارات المؤدية إلى الشهادة نفسها وإلى المفتاح. هم بالضبط ما نحتاجه. بشكل عام، تلقينا 4 ملفات سيتم تخزينها في المجلد "/etc/letsencrypt/live/domain". نحتاج الآن إلى إبلاغ خادم الويب بشهادتنا، أي استبدال الشهادة المضمنة بالشهادة التي تلقيناها للتو. للقيام بذلك، نحن بحاجة إلى تحرير ملف واحد فقط.

# نانو /etc/nginx/templates/ssl.tmpl

ونغير آخر سطرين فيه.

استبدال شهادة SSL

نقوم بتغيير المسارات الموجودة في الملف إلى المسارات التي أخبرنا بها النظام عند استلام الشهادة.

استبدال شهادة SSL

وأعد تشغيل NGINX.

# إعادة تشغيل خدمة nginx

الآن دعونا نحاول تسجيل الدخول إلى iRedAdmin مرة أخرى.

التحقق من شهادة SSL

لا يوجد المزيد من الأخطاء في الشهادة. الشهادة صالحة. يمكنك النقر على القفل ومعرفة خصائصه. عند انتهاء صلاحية الشهادة، يجب على certboot تجديدها تلقائيًا.

الآن سنقدم تقريرًا عن شهادة Dovecot وPostfix. للقيام بذلك، سنقوم بتحرير ملفين للتكوين. نحن نفعل:

# نانو /etc/dovecot/dovecot.conf

العثور على الكتلة:

#SSL: الإعدادات العامة.

ونقوم بتغيير الشهادة المسجلة هناك إلى شهادتنا.

شهادة استبدال Dovecot

انتبه أيضًا إلى السطر "ssl_protocols". يجب أن تكون قيمته "!SSLv3"، وإلا ستتلقى الخطأ "تحذير: SSLv2 غير مدعوم بواسطة OpenSSL. يرجى التفكير في إزالته من ssl_protocols" عند إعادة تشغيل Dovecot.

# نانو /etc/postfix/main.cf

العثور على الكتلة:

# مفتاح SSL، الشهادة، CA

ونقوم بتغيير المسارات فيه إلى ملفات شهادتنا.

استبدال شهادة لـ Postfix

وبهذا يكتمل تثبيت الشهادة. من الضروري إعادة تشغيل Dovecot وPostfix، لكن من الأفضل إعادة تشغيل الخادم.

# إعادة تشغيل الخدمة

# اعادة التشغيل

تثبيت PHPMyAdmin

هذه الخطوة اختيارية، لكني أوصي بتنفيذها وتثبيت PHPMyAdmin لسهولة العمل مع قواعد البيانات.

# تثبيت phpmyadmin

سيسألك المثبت عن خادم الويب الذي سيتم تكوين PHPMyAdmin للعمل معه، نظرًا لأن NGINX غير موجود في هذه القائمة، ما عليك سوى الضغط على TAB والمضي قدمًا.

تثبيت PHPMyAdmin

بعد اكتمال التثبيت، لكي يعمل phpmyadmin، تحتاج إلى إنشاء رابط رمزي للدليل الذي يعمل به NGINX افتراضيًا.

# ln -s /usr/share/phpmyadmin /var/www/html

ونحاول الانتقال إلى https://domain/phpmyadmin/

PHPMyAdmin قيد التشغيل. الاتصال محمي بشهادة، ولا توجد أخطاء. تفضل. لنقم بإنشاء مسؤول قاعدة بيانات MySQL (MariaDB).

# الخلية

ونصل إلى وحدة تحكم إدارة MariaDB. بعد ذلك نقوم بتنفيذ الأوامر واحدة تلو الأخرى:

MariaDB > إنشاء مستخدم "admin"@"localhost" تم تحديده بواسطة "كلمة المرور"؛
MariaDB > منح كافة الامتيازات على *.* إلى "admin"@"localhost" مع خيار المنحة؛
MariaDB > امتيازات التدفق؛

إنشاء مستخدم MySQL

كل شيء على ما يرام، اكتمل تسجيل الدخول. PHPMyAdmin جاهز للانطلاق.

تثبيت PostfixAdmin

من حيث المبدأ، PostfixAdmin، مثل PHPMyAdmin، لا يحتاج إلى التثبيت. سيعمل خادم البريد بشكل جيد بدون هذه المكونات. ولكن بعد ذلك لن تتمكن من إنشاء أسماء مستعارة للبريد. إذا لم تكن بحاجة إلى هذا، فيمكنك تخطي هذه الأقسام بأمان. إذا كنت لا تزال بحاجة إلى أسماء مستعارة، فلديك خياران: شراء الإصدار المدفوع من iReaAdmin أو تثبيت PostfixAdmin. بالطبع، يمكنك القيام بذلك بدون برامج إضافية، عن طريق تسجيل الأسماء المستعارة في قاعدة البيانات يدويًا، لكن هذا ليس مناسبًا دائمًا وغير مناسب للجميع. أوصي باستخدام PostfixAdmin، وسننظر في تثبيته وتكامله مع iRedMail الآن. لنبدأ التثبيت:

# ملائمة لتثبيت postfixadmin

نحن نتفق وننشئ كلمة مرور لقاعدة بيانات النظام الخاصة بالبرنامج.

تثبيت PostfixAdmin

تثبيت PostfixAdmin

نقوم بإنشاء رابط رمزي بنفس طريقة تثبيت PHPMyAdmin.

# ln -s /usr/share/postfixadmin /var/www/html

نحن نجعل المستخدم الذي يتم تشغيل خادم الويب نيابة عنه هو مالك الدليل. في حالتنا، يتم إطلاق NGINX كمستخدم بيانات www.

# chown -R www-data /usr/share/postfixadmin

نحتاج الآن إلى تحرير ملف تكوين PostfixAdmin وإضافة معلومات حول قاعدة البيانات التي يستخدمها iRedAdmin. بشكل افتراضي، تسمى قاعدة البيانات هذه vmail. إذا ذهبت إلى PHPMyAdmin يمكنك رؤيته هناك. وهكذا، لكي يتمكن PostfixAdmin من إجراء تغييرات على قاعدة البيانات، نقوم بتسجيله في تكوين PostfixAdmin.

# نانو /etc/postfixadmin/config.inc.php

نجد الخطوط:

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["database_name"] = $dbname;

ولنضعه في الاعتبار:

$CONF["database_type"] = "mysqli"; # نوع قاعدة البيانات
$CONF["database_host"] = "localhost"; # مضيف خادم قاعدة البيانات
$CONF["database_user"] = "admin"; # تسجيل الدخول مع حقوق الكتابة إلى قاعدة بيانات vmail. يمكنك استخدام المسؤول الذي تم إنشاؤه مسبقًا
$CONF["database_password"] = "كلمة المرور"; # كلمة المرور للمستخدم المحدد أعلاه
$CONF["database_name"] = "vmail"; # اسم قاعدة البيانات iRedMail

إدخال المعلومات حول قاعدة البيانات

إذا كنت تخطط لاستخدام عميل بريد الويب SOGo، فأنت بحاجة إلى القيام بخطوة إضافية أخرى، وهي تغيير تشفير PostfixAdmin في العنصر $CONF["encrypt"] من "md5crypt" إلى "dovecot:SHA512-CRYPT" . إذا لم تقم بذلك، فعند محاولة تسجيل الدخول إلى SOGo باستخدام مستخدم تم إنشاؤه في PostfixAdmin، ستتلقى خطأ: تسجيل الدخول أو كلمة المرور غير صحيحة.

تغيير نوع التشفير

الآن، لإكمال التثبيت بنجاح وعدم تلقي الأخطاء، يجب عليك تنفيذ استعلام إلى قاعدة البيانات. من الملائم القيام بذلك من خلال PHPMyAdmin. حدد قاعدة بيانات vmail وانتقل إلى علامة التبويب SQL. في النافذة ندخل:

DROP INDEX المجال على صندوق البريد؛
DROP INDEX المجال على الاسم المستعار؛
تغيير الاسم المستعار للجدول ADD COLUMN `goto` text NOT NULL؛

استعلام قاعدة البيانات

وانقر على "إلى الأمام". الآن نحن جميعًا جاهزون، يمكننا الانتقال إلى واجهة الويب PostfixAdmin وإكمال التثبيت. للقيام بذلك، تحتاج إلى كتابة المتصفح الخاص بك: https://domain/postfixadmin/setup.php.

يجب أن يظهر ما يلي:

تثبيت PostfixAdmin

إذا تم كل شيء وفقًا للتعليمات، فلا ينبغي أن تكون هناك أخطاء. إذا كان هناك أي منها، فيجب إزالتها، وإلا فلن يسمح لك النظام بالاستمرار. قم بتعيين كلمة مرور التثبيت وانقر فوق "إنشاء تجزئة كلمة المرور". سيقوم النظام بإنشاء تجزئة كلمة المرور، والتي يجب إدراجها في المعلمة $CONF["setup_password"].

إكمال تثبيت PostfixAdmin

تغيير إعدادات ملف التكوين

أدخل الآن كلمة المرور التي تم إنشاؤها حديثًا وقم بإنشاء مسؤول PostfixAdmin. من الأفضل عدم إنشاء مسؤول باستخدام تسجيل دخول مدير البريد، حيث قد تكون هناك مشكلات في تسجيل الدخول إلى لوحة إدارة iRedAdmin.

إنشاء مسؤول PostfixAdmin

هذا كل شيء، تم إنشاء المسؤول. يمكنك تسجيل الدخول.

يرجى ملاحظة أنه من الناحية الأمنية، من الأفضل إعادة تسمية أو حذف ملف setup.php الموجود في دليل postfixadmin.

انتقل إلى: https://domain/postfixadmin/ وأدخل بيانات الاعتماد التي تم إنشاؤها حديثًا. في PostfixAdmin، وكذلك في iRedAdmin، تتوفر اللغة الروسية. يمكنك تحديده أثناء الترخيص.

نحن نحاول إنشاء صندوق بريد المستخدم.

تمكين/تعطيل وحدات iRedMail

iRedAPD مسؤول عن إدارة وحدات iRedMail. يحتوي على ملف تكوين يتم فيه تسجيل وحدات العمل. إذا لم تكن بحاجة إلى وحدة معينة، فيمكنك إزالتها من ملف التكوين وسوف تتوقف عن العمل. نحن نفعل:

# نانو /opt/iredapd/settings.py

ابحث عن سطر "المكونات الإضافية" وقم بإزالة المكونات التي لا تحتاجها منه. سأقوم بإزالة مكون "القائمة الرمادية". وبطبيعة الحال، فهو يحمي من البريد العشوائي بشكل فعال، ولكن الرسائل الضرورية لا تصل في كثير من الأحيان.

Graylist هي تقنية حماية تلقائية من البريد العشوائي تعتمد على تحليل سلوك خادم مرسل البريد. عند تمكين "القائمة الرمادية"، يرفض الخادم قبول خطاب من عنوان غير معروف لأول مرة، ويبلغ عن خطأ مؤقت. في هذه الحالة، يجب على الخادم المرسل تكرار الإرسال لاحقًا. برامج مرسلي البريد العشوائي عادة لا تفعل هذا. إذا تم إرسال الرسالة مرة أخرى، يتم إضافتها إلى القائمة لمدة 30 يومًا ويتم تبادل البريد في المرة الأولى. قرر بنفسك ما إذا كنت ستستخدم هذه الوحدة أم لا.

تمكين/تعطيل وحدات البريد

بعد إجراء التغييرات، يجب عليك إعادة تشغيل iRedAPD.

# إعادة تشغيل خدمة iredapd

اختبار خادم البريد

يكمل هذا تكوين خادم بريد iRedMail. يمكنك المتابعة إلى المرحلة النهائية - الاختبار. لنقم بإنشاء صندوقي بريد. للتحقق من أحدهما من خلال iRedAdmin، والثاني من خلال PostfixAdmin وإرسال خطاب من صندوق بريد إلى آخر والعكس صحيح. في iRedAdmin سنقوم بإنشاء صندوق بريد [email protected]. في PostfixAdmin - [email protected]

إنشاء مستخدم في iRedAdmin

إنشاء مستخدم في PostfixAdmin

نحن نتحقق من إنشاء المستخدمين.

إذا انتبهت إلى العمود "إلى" في قائمة صناديق بريد PostfixAdmin، فستلاحظ الفرق بين صناديق البريد التي تم إنشاؤها في iRedAdmin وPostfixAdmin. يتم وضع علامة على صناديق البريد التي تم إنشاؤها في iRedAdmin على أنها "إعادة توجيه فقط"، ويتم وضع علامة على صناديق البريد التي تم إنشاؤها في PostfixAdmin على أنها "صندوق بريد". في البداية لم أتمكن من فهم سبب حدوث ذلك لفترة طويلة وما هو الفرق بينهما، وأخيراً لاحظت شيئًا واحدًا. يتم إنشاء صناديق البريد في iRedAdmin بدون أسماء مستعارة، ويتم إنشاء صناديق البريد في PostfixAdmin باسم مستعار لنفسها.

وإذا تم حذف هذه الأسماء المستعارة، فسيتم عرض صناديق البريد كتلك التي تم إنشاؤها في iRedAdmin "للأمام فقط".

إزالة الأسماء المستعارة

تمت إزالة الأسماء المستعارة. التحقق من PostfixAdmin.

كما ترون، أصبحت جميع المربعات "للأمام فقط". وبنفس الطريقة، إذا قمت بإنشاء اسم مستعار لنفسك في صندوق بريد تم إنشاؤه في iRedAdmin، فسيصبح "Mailbox". من حيث المبدأ، هذا لا يؤثر على أداء البريد بأي شكل من الأشكال. الشيء الوحيد هو أنك لن تتمكن من إنشاء اسم مستعار على صندوق بريد تم إنشاؤه في PostfixAdmin. بدلاً من إنشاء اسم مستعار، ستحتاج إلى تعديل اسم مستعار موجود. عند الحديث عن الأسماء المستعارة، في الإصدار الجديد من iRedMail، من الضروري إجراء تغيير على إحدى خرائط Postfix، المسؤولة عن الأسماء المستعارة. وإذا لم تقم بذلك، فلن تعمل الأسماء المستعارة التي تم إنشاؤها. للقيام بذلك، تحتاج إلى تصحيح ما يلي في الملف /etc/postfix/mysql/virtual_alias_maps.cf:

نحن نفعل:

# nano /etc/postfix/mysql/virtual_alias_maps.cf

ونحن إصلاحه.

إعداد الأسماء المستعارة

إعادة تشغيل بوستفيكس:

# إعادة تشغيل الخدمة اللاحقة

بعد هذا كل شيء يجب أن يعمل.

وهكذا، دعونا نبدأ في التحقق من البريد. سنقوم بتسجيل الدخول إلى صندوق بريد المستخدم 1 عبر Roundcube، وإلى صندوق بريد المستخدم 2 عبر SOGo وإرسال خطاب من صندوق بريد المستخدم 1 إلى المستخدم 2 والعودة.

إرسال بريد إلكتروني مع Roundcube

تلقي خطاب في SOGo

إرسال بريد إلكتروني إلى SOGo

تلقي رسالة في Roundcube

كل شيء يعمل دون أي مشاكل. يستغرق تسليم الرسالة من ثانيتين إلى خمس ثواني. بنفس الطريقة، يتم تسليم الرسائل بشكل مثالي إلى خوادم Yandex و mail.ru (تم اختبارها).

الآن دعونا نتحقق من الأسماء المستعارة. لنقم بإنشاء صندوق بريد user3 وإنشاء اسم مستعار من صندوق بريد user1 إلى صندوق بريد user2. وسنرسل رسالة من صندوق بريد المستخدم 3 إلى صندوق بريد المستخدم 1. في هذه الحالة، يجب أن تصل الرسالة إلى صندوق بريد المستخدم 2.

إنشاء اسم مستعار

إرسال خطاب من صندوق بريد المستخدم 3 إلى صندوق بريد المستخدم 1

تلقي رسالة على صندوق بريد المستخدم 2

عمل الأسماء المستعارة جيد أيضًا.

لنختبر تشغيل خادم البريد من خلال عميل بريد محلي. على سبيل المثال، خذ بعين الاعتبار موزيلا ثندربيرد. لنقم بإنشاء مستخدمين آخرين: Client1 وclient2. سنقوم بتوصيل صندوق بريد واحد عبر IMAP والآخر عبر POP3 وإرسال خطاب من صندوق بريد إلى الآخر.

اتصال IMAP

الاتصال عبر POP3

نرسل رسالة من العميل 1 إلى العميل 2.

الإرسال من العميل 1

الاستلام على العميل 2

وبترتيب عكسي.

الإرسال من العميل 2

الاستلام على العميل 1

كل شيء يعمل.

إذا ذهبت إلى العنوان: https://domain/netdata، يمكنك رؤية الرسوم البيانية لحالة النظام.

خاتمة

يكتمل هذا التثبيت والتكوين والاختبار لنظام بريد iRedMail. ونتيجة لذلك، حصلنا على خادم بريد مجاني تمامًا وكامل مع شهادة SSL صالحة، وعملاء بريد ويب مختلفين، ولوحتي تحكم، بالإضافة إلى مكافحة البريد العشوائي ومكافحة الفيروسات المضمنة في البريد. إذا كنت ترغب في ذلك، فبدلاً من برامج بريد الويب، يمكنك استخدام برامج البريد المحلية مثل Microsoft Outlook أو Mozilla Thunderbird. إذا كنت لا تخطط لاستخدام عملاء بريد الويب، فلا يمكنك تثبيتهم على الإطلاق، حتى لا تفرط في تحميل الخادم، أو تثبيت شيء واحد تفضله. أنا شخصيا أحب SOGo أكثر لأن واجهته محسنة للأجهزة المحمولة، مما يجعل من السهل جدًا عرض البريد الإلكتروني من الهاتف الذكي. الأمر نفسه ينطبق على NetData وiRedAdmin، إذا كنت لا تخطط لاستخدامه، فمن الأفضل عدم تثبيته. نظام البريد هذا لا يتطلب الكثير من الموارد. يتم تشغيل كل هذا على خادم VPS بذاكرة وصول عشوائي (RAM) تبلغ 1024 ميجابايت ومعالج افتراضي واحد. إذا كان لديك أي أسئلة حول نظام البريد هذا، فاكتب في التعليقات.

ملاحظة. عند اختبار هذا المنتج على أنظمة تشغيل مختلفة مع 1 غيغابايت من ذاكرة الوصول العشوائي (Ubuntu، Debian، CentOS)، اتضح أن 1 غيغابايت لا يكفي لتشغيل ClamAV. في جميع الحالات تقريبًا، عند استخدام 1 غيغابايت من الذاكرة، أشار برنامج مكافحة الفيروسات إلى خطأ يتعلق بقاعدة البيانات. في الوقت نفسه، في أنظمة التشغيل Debian و Ubuntu، لم يقوم برنامج مكافحة الفيروسات ببساطة بفحص البريد الذي يمر عبر الخادم، وإلا فإن كل شيء يعمل بشكل جيد. كان الوضع مختلفًا بعض الشيء على CentOS. أدت خدمة clamd إلى تعطل النظام بالكامل، مما يجعل التشغيل العادي للخادم مستحيلًا. عند محاولة تسجيل الدخول إلى واجهات الويب، أصدر NGINX بشكل دوري أخطاء 502 و504. تم إرسال البريد أيضًا في كل مرة. علاوة على ذلك، إذا أضفنا ما يصل إلى 2 غيغابايت من ذاكرة الوصول العشوائي، ففي جميع الحالات لم تكن هناك مشاكل في تشغيل برنامج مكافحة الفيروسات والخادم ككل. قام ClamAV بفحص البريد الذي يمر عبر خادم البريد، والذي كتب عنه في السجلات. عند محاولة إرسال فيروس كمرفق، تم حظر التسليم. كان استهلاك الذاكرة حوالي 1.2 - 1.7 جيجابايت.

يكتسب Nginx شعبية سريعة، حيث يتحول من مجرد مسرع تسليم ثابت لـ Apache إلى خادم ويب متطور يعمل بكامل طاقته، والذي يتم استخدامه بشكل متزايد بمعزل عن الآخرين. سنتحدث في هذه المقالة عن سيناريوهات مثيرة للاهتمام وغير قياسية لاستخدام nginx والتي ستتيح لك تحقيق أقصى استفادة من خادم الويب الخاص بك.

وكيل البريد

لنبدأ بالأمر الأكثر وضوحًا، وهو قدرة nginx على العمل كوكيل بريد. هذه الوظيفة موجودة في nginx في البداية، ولكن لسبب ما نادرًا ما يتم استخدامها في الإنتاج؛ بعض الأشخاص لا يدركون وجودها. مهما كان الأمر، يدعم nginx إنشاء بروتوكولات POP3 وIMAP وSMTP بطرق مصادقة متنوعة، بما في ذلك SSL وStartTLS، ويقوم بذلك بسرعة كبيرة.

لماذا هذا ضروري؟ هناك استخدامان على الأقل لهذه الوظيفة. أولاً: استخدم nginx كدرع ضد مرسلي البريد العشوائي المزعجين الذين يحاولون إرسال رسائل بريد إلكتروني غير هامة من خلال خادم SMTP الخاص بنا. عادة، لا يخلق مرسلي البريد العشوائي العديد من المشاكل، حيث يتم رفضهم بسرعة في مرحلة المصادقة، ومع ذلك، عندما يكون هناك الكثير منهم بالفعل، سيساعد nginx في توفير موارد المعالج. ثانيًا: استخدم nginx لإعادة توجيه المستخدمين إلى خوادم بريد POP3/IMAP متعددة. بالطبع، يمكن لوكيل بريد آخر التعامل مع هذا الأمر، ولكن لماذا يتم عزل الخوادم إذا كان nginx مثبتًا بالفعل على الواجهة الأمامية لخدمة محتوى ثابت عبر HTTP، على سبيل المثال؟

خادم وكيل البريد في nginx ليس قياسيًا تمامًا. ويستخدم طبقة إضافية من المصادقة التي يتم تنفيذها باستخدام HTTP، وفقط إذا تجاوز المستخدم هذا الحاجز يُسمح له بالمضي قدمًا. يتم توفير هذه الوظيفة عن طريق إنشاء صفحة/برنامج نصي يرسل إليه nginx بيانات المستخدم، ويقوم بإرجاع استجابة في شكل موافق قياسي أو سبب للرفض (مثل "تسجيل الدخول أو كلمة المرور غير صالحة"). يعمل البرنامج النصي مع الرؤوس التالية:

بيانات إدخال البرنامج النصي للمصادقة HTTP_AUTH_USER: المستخدم HTTP_AUTH_PASS: كلمة المرور HTTP_AUTH_PROTOCOL: بروتوكول البريد (IMAP أو POP3 أو SMTP)

ويقوم بإرجاع ما يلي:

إخراج البرنامج النصي للمصادقة HTTP_AUTH_STATUS: موافق أو سبب الفشل HTTP_AUTH_SERVER: خادم البريد الحقيقي لإعادة توجيه HTTP_AUTH_PORT: منفذ الخادم

من الميزات الرائعة لهذا النهج أنه يمكن استخدامه ليس على الإطلاق للمصادقة نفسها، ولكن لتوزيع المستخدمين عبر خوادم داخلية مختلفة، اعتمادًا على اسم المستخدم، أو بيانات التحميل الحالي على خوادم البريد، أو حتى عن طريق تنظيم موازنة تحميل بسيطة باستخدام جولة روبن. ومع ذلك، إذا كنت بحاجة فقط إلى نقل المستخدمين إلى خادم بريد داخلي، فيمكنك استخدام كعب روتين تم تنفيذه بواسطة nginx نفسه بدلاً من البرنامج النصي الحقيقي. على سبيل المثال، سيبدو أبسط وكيل SMTP وIMAP في تكوين nginx كما يلي:

# vi /etc/nginx/nginx.conf mail ( # عنوان البرنامج النصي للمصادقة auth_http localhost:8080/auth؛ # تعطيل أمر XCLIENT، بعض خوادم البريد لا تفهمه xclient off؛ # خادم خادم IMAP ( استمع 143؛ بروتوكول imap؛ الوكيل قيد التشغيل) # خادم خادم SMTP (استمع 25؛ بروتوكول smtp؛ الوكيل قيد التشغيل؛ ))

# vi /etc/nginx/nginx.conf http ( # التعيين إلى منفذ خادم البريد المطلوب اعتمادًا على المنفذ المرسل في خريطة رأس HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # تنفيذ المصادقة "script" - يُرجع دائمًا موافق وينقل المستخدم إلى خادم البريد الداخلي، ويضبط المنفذ المطلوب باستخدام خادم التعيين أعلاه (استمع 8080؛ الموقع /auth ( add_header "Auth-Status" "OK"؛ add_header "Auth-Server" "192.168.0.1" ؛ add_header "Auth-Port" $mailport return 200;

هذا كل شيء. يسمح لك هذا التكوين بإعادة توجيه المستخدمين بشفافية إلى خادم البريد الداخلي، دون إنشاء حمل في شكل برنامج نصي غير ضروري في هذه الحالة. باستخدام برنامج نصي، يمكن توسيع هذا التكوين بشكل كبير: تكوين موازنة التحميل، والتحقق من المستخدمين باستخدام قاعدة بيانات LDAP، وتنفيذ عمليات أخرى. إن كتابة البرنامج النصي خارج نطاق هذه المقالة، ولكن من السهل جدًا تنفيذه حتى مع وجود معرفة عابرة بـ PHP وPython.

بث الفيديو

من السهل إعداد استضافة فيديو عادية استنادًا إلى nginx. كل ما عليك فعله هو تحميل الفيديو المحول إلى دليل يمكن للخادم الوصول إليه، وتسجيله في التكوين وتهيئة مشغل Flash أو HTML5 بحيث يأخذ الفيديو من هذا الدليل. ومع ذلك، إذا كنت بحاجة إلى إعداد بث فيديو مستمر من مصدر خارجي أو كاميرا ويب، فلن يعمل هذا المخطط، وسيتعين عليك البحث عن بروتوكولات بث خاصة.

هناك العديد من البروتوكولات التي تحل هذه المشكلة، وأكثرها فعالية ودعمًا هو RTMP. المشكلة الوحيدة هي أن جميع تطبيقات خادم RTMP تقريبًا تعاني من مشكلات. يتم دفع خادم Adobe Flash Media Server الرسمي. تمت كتابة Red5 وWowza بلغة Java، وبالتالي لا يوفران الأداء المطلوب، كما تمت كتابة تطبيق آخر، Erlyvideo، بلغة Erlang، وهو أمر جيد في حالة إعداد المجموعة، ولكنه ليس فعالًا جدًا لخادم واحد.

أقترح طريقة مختلفة - استخدم وحدة RTMP لـ nginx. يتمتع بأداء ممتاز وسيسمح لك أيضًا باستخدام خادم واحد لخدمة واجهة الويب الخاصة بالموقع ودفق الفيديو. المشكلة الوحيدة هي أن هذه الوحدة غير رسمية، لذا سيتعين عليك إنشاء nginx بدعمها بنفسك. لحسن الحظ، يتم التجميع بطريقة قياسية:

$ Sudo apt-get Remove nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ unzip nginx-rtmp.zip $ wget http://nginx.org/download/nginx- 1.2.6.tar.gz $ tar -xzf nginx-1.2.6.tar.gz $ cd nginx-1.2.6 $ ./configure --add-module=/tmp/nginx-rtmp-module-master $ make $ سودو جعل التثبيت

الآن يجب تكوين الوحدة. ويتم ذلك، كالعادة، من خلال تكوين nginx:

Rtmp ( # تنشيط خادم البث على المنفذ 1935 في موقع العنوان/خادم rtmp ( استمع 1935؛ التطبيق rtmp ( مباشر ؛ ) ) )

لا يمكن لوحدة RTMP أن تعمل في تكوين متعدد الخيوط، لذلك يجب تقليل عدد العمليات المنفذة لـ nginx إلى عملية واحدة (سأخبرك لاحقًا بكيفية التغلب على هذه المشكلة):

Worker_processes 1;

يمكنك الآن حفظ الملف وإجبار nginx على إعادة قراءة التكوين. اكتمل إعداد nginx، لكن ليس لدينا تدفق الفيديو نفسه بعد، لذا نحتاج إلى الحصول عليه في مكان ما. على سبيل المثال، دع هذا يكون ملف video.avi من الدليل الحالي. لتحويله إلى دفق وتغليفه في مذيع RTMP الخاص بنا، سنستخدم FFmpeg القديم الجيد:

# ffmpeg -re -i ~/video.avi -c نسخة -f flv rtmp://localhost/rtmp/stream

إذا لم يكن ملف الفيديو بتنسيق H264، فيجب إعادة ترميزه. يمكن القيام بذلك بسرعة باستخدام نفس FFmpeg:

# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream

يمكن أيضًا التقاط البث مباشرة من كاميرا الويب:

# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream

لعرض البث على جانب العميل، يمكنك استخدام أي مشغل يدعم RTMP، على سبيل المثال mplayer:

$ mplayer rmtp://example.com/rtmp/stream

أو قم بتضمين المشغل مباشرة في صفحة ويب، والتي يتم تقديمها بواسطة نفس nginx (مثال من الوثائق الرسمية):

أبسط مشغل ويب RTMP

jwplayer("container").setup(( الأوضاع: [( النوع: "flash"، src: "/jwplayer/player.swf"، التكوين: ( buffer length: 1، file: "stream"، Streamer: "rtmp:/ /localhost/rtmp"، المزود: "rtmp"، ) )] ));

لا يوجد سوى سطرين مهمين هنا: "ملف: "دفق""، يشير إلى دفق RTMP، و"جهاز البث: "rtmp://localhost/rtmp""، الذي يشير إلى عنوان جهاز بث RTMP. بالنسبة لمعظم المهام، ستكون هذه الإعدادات كافية تماما. يمكنك إرسال عدة تدفقات مختلفة إلى عنوان واحد، وسيعمل nginx على مضاعفة إرسالها بشكل فعال بين العملاء. ولكن هذا ليس كل ما تستطيع وحدة RTMP القيام به. بمساعدتها، على سبيل المثال، يمكنك تنظيم ترحيل دفق الفيديو من خادم آخر. ليست هناك حاجة لخادم FFmpeg لهذا على الإطلاق، فقط أضف الأسطر التالية إلى التكوين:

# vi /etc/nginx/nginx.conf تطبيق rtmp (مباشر؛ اسحب rtmp://rtmp.example.com;)

إذا كنت بحاجة إلى إنشاء تدفقات متعددة بجودة مختلفة، فيمكنك استدعاء برنامج تحويل ترميز FFmpeg مباشرة من nginx:

# vi /etc/nginx/nginx.conf تطبيق rtmp (مباشر؛ exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name ) تطبيق rtmp-320x240 (مباشر ؛)

مع هذا التكوين، سنحصل على مذيعين في وقت واحد، أحدهما سيكون متاحًا على العنوان rtmp://site/rtmp، والثاني، يبث بجودة 320 × 240، على العنوان rtmp://site/rtmp -320x240. بعد ذلك، يمكنك إضافة مشغل فلاش وأزرار اختيار الجودة إلى الموقع، والتي ستمنح المشغل عنوان مذيع معين.

وأخيرًا، مثال على بث الموسيقى على الشبكة:

احيانا صحيح؛ قم بعمل ffmpeg -re -i "`find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; منتهي

وكيل جيت

نظام التحكم في إصدار Git قادر على توفير الوصول إلى المستودعات ليس فقط عبر بروتوكولات Git وSSH، ولكن أيضًا عبر HTTP. ذات مرة، كان تنفيذ الوصول إلى HTTP بدائيًا وغير قادر على توفير عمل كامل مع المستودع. مع الإصدار 1.6.6، تغير الوضع، واليوم يمكن استخدام هذا البروتوكول، على سبيل المثال، لتجاوز قيود جدار الحماية على جانبي الاتصال أو لإنشاء استضافة Git الخاصة بك مع واجهة ويب.

لسوء الحظ، تتحدث الوثائق الرسمية فقط عن تنظيم الوصول إلى Git باستخدام خادم الويب Apache، ولكن نظرًا لأن التنفيذ نفسه عبارة عن تطبيق خارجي بواجهة CGI قياسية، فيمكن توصيله بأي خادم آخر تقريبًا، بما في ذلك lighttpd، وبالطبع، nginx. هذا لا يتطلب أي شيء باستثناء الخادم نفسه، وتثبيت Git وخادم FastCGI الصغير fcgiwrap، وهو أمر ضروري لأن nginx لا يعرف كيفية العمل مع CGI مباشرة، ولكن يمكنه استدعاء البرامج النصية باستخدام بروتوكول FastCGI.

سيبدو مخطط العمل بأكمله هكذا. سيتم تعليق خادم fcgiwrap في الخلفية وينتظر طلبًا لتنفيذ تطبيق CGI. سيتم تكوين Nginx بدوره لطلب تنفيذ ثنائي CGI git-http-backend عبر واجهة FastCGI في كل مرة يتم فيها الوصول إلى العنوان الذي نحدده. عند تلقي طلب، يقوم fcgiwrap بتنفيذ git-http-backend باستخدام وسيطات CGI المحددة التي تم تمريرها بواسطة عميل GIT وإرجاع النتيجة.

لتنفيذ مثل هذا المخطط، قم أولاً بتثبيت fcgiwrap:

$ sudo apt-get install fcgiwrap

ليست هناك حاجة لتكوينه، حيث يتم إرسال جميع المعلمات عبر بروتوكول FastCGI. سيتم تشغيله تلقائيًا أيضًا. لذلك، كل ما تبقى هو تكوين nginx. للقيام بذلك، قم بإنشاء ملف /etc/nginx/sites-enabled/git (إذا لم يكن هناك مثل هذا الدليل، يمكنك الكتابة إلى التكوين الرئيسي) واكتب ما يلي فيه:

# vi /etc/nginx/sites-enabled/git server ( # نحن معلقون على المنفذ 8080 استمع 8080؛ # عنوان الخادم الخاص بنا (لا تنس إضافة إدخال في DNS) server_name git.example.ru; # Logs access_log /var/log/nginx /git-http-backend.access.log error_log /var/log/nginx/git-http-backend.error.log # العنوان الرئيسي لموقع الوصول المجهول / ( # عند محاولة التنزيل، أرسل المستخدم إلى عنوان خاص if ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params # عنوان git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # عنوان مستودع Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # عنوان الملف fastcgi_param PATH_INFO $uri; # عنوان الخادم fcgiwrap fastcgi_pass 127.0.0.1:9001 ) # كتابة عنوان الوصول location ~/private(/.* )$ ( # أذونات المستخدم auth_basic "git مجهول للقراءة فقط، كتابة موثقة"؛ # مصادقة HTTP تعتمد على htpasswd auth_basic_user_file /etc/nginx/htpasswd؛ # تتضمن إعدادات FastCGI /etc/nginx/fastcgi_params ; fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; fastcgi_param GIT_PROJECT_ROOT /srv/git; fastcgi_param PATH_INFO $1; fastcgi_pass 127.0.0.1:9001; ))

يفترض هذا التكوين ثلاثة أشياء مهمة:

سيكون عنوان المستودع هو /srv/git، لذلك قمنا بتعيين حقوق الوصول المناسبة: $ sudo chown -R www-data:www-data /srv/git

يجب أن يكون المستودع نفسه مفتوحًا للقراءة بواسطة مستخدمين مجهولين ويسمح بالتحميل عبر HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true

يتم إجراء المصادقة باستخدام ملف htpasswd، تحتاج إلى إنشائه وإضافة مستخدمين إليه: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

هذا كل شيء، أعد تشغيل nginx:

التخزين المؤقت الدقيق

دعونا نتخيل موقفًا مع موقع ويب ديناميكي يتم تحديثه بشكل متكرر، والذي يبدأ فجأة في تلقي أحمال ثقيلة جدًا (حسنًا، انتهى به الأمر على صفحة أحد أكبر المواقع الإخبارية) ويتوقف عن التعامل مع عودة المحتوى. سيستغرق التحسين الصحيح وتنفيذ نظام التخزين المؤقت الصحيح وقتًا طويلاً، ويجب حل المشكلات الآن. ماذا نستطيع ان نفعل؟

هناك عدة طرق للخروج من هذا الموقف بأقل الخسائر، ولكن الفكرة الأكثر إثارة للاهتمام اقترحها فين بيلي (fennb.com). تتمثل الفكرة ببساطة في وضع nginx أمام الخادم وإجباره على تخزين جميع المحتويات المنقولة مؤقتًا، ولكن ليس فقط ذاكرة التخزين المؤقت، ولكن لثانية واحدة فقط. التطور هنا هو أن المئات والآلاف من زوار الموقع في الثانية، في الواقع، سيولدون طلبًا واحدًا فقط إلى الواجهة الخلفية، ويتلقون صفحة مخبأة في الغالب. وفي الوقت نفسه، من غير المرجح أن يلاحظ أي شخص الفرق، لأنه حتى على الموقع الديناميكي، فإن ثانية واحدة عادة لا تعني شيئًا.

لن يبدو التكوين مع تنفيذ هذه الفكرة معقدًا للغاية:

# vi /etc/nginx/sites-enabled/cache-proxy # تكوين ذاكرة التخزين المؤقت proxy_cache_path /var/cache/nginxمستويات=1:2keys_zone=microcache:5m max_size=1000m; الخادم ( استمع 80؛ اسم الخادم example.com؛ # موقع العنوان المخبأ / ( # تم تمكين ذاكرة التخزين المؤقت افتراضيًا $no_cache ""؛ # تعطيل ذاكرة التخزين المؤقت لجميع الطرق باستثناء GET و HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # إذا قام العميل بتحميل محتوى إلى الموقع (no_cache = 1)، فإننا نتأكد من عدم تخزين البيانات المقدمة له لمدة ثانيتين ويمكنه رؤية نتيجة التنزيل إذا ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 ") # تمكين/تعطيل ذاكرة التخزين المؤقت حسب حالة المتغير no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # طلبات الوكيل إلى الخادم الحقيقي proxy_pass http://appserver.example.ru; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # الحماية من مشكلة تحديث القطيع proxy_cache_use_stale # إضافة الرؤوس القياسية proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # لا نقوم بتخزين ملفات أكبر من 1 ميجا بايت proxy_max_temp_file_size 1M; ))

يحتل السطر "proxy_cache_use_stale Update;" مكانًا خاصًا في هذا التكوين، والذي بدونه كنا سنتلقى دفعات دورية من التحميل على خادم الواجهة الخلفية بسبب الطلبات الواردة أثناء تحديث ذاكرة التخزين المؤقت. خلاف ذلك، كل شيء قياسي ويجب أن يكون واضحا دون تفسير غير ضروري.

تقريب الوكلاء من الجمهور المستهدف

على الرغم من الزيادة العالمية الواسعة النطاق في سرعات الإنترنت، إلا أن المسافة المادية بين الخادم والجمهور المستهدف لا تزال تلعب دورًا. وهذا يعني أنه إذا تم تشغيل موقع روسي على خادم موجود في مكان ما في أمريكا، فإن سرعة الوصول إليه ستكون أبطأ بشكل مسبق من خادم روسي بنفس عرض القناة (بالطبع، إذا أغمضتم أعينكم عن جميع العوامل الأخرى) ). شيء آخر هو أن وضع الخوادم في الخارج غالبًا ما يكون أكثر ربحية، بما في ذلك من حيث الصيانة. لذلك، للحصول على الربح، في شكل معدلات دفع أعلى، سيتعين عليك استخدام بعض الحيل.

أحد الخيارات الممكنة: وضع الخادم الإنتاجي الرئيسي في الغرب، ونشر واجهة أمامية لا تتطلب الكثير من الموارد وتنتج بيانات ثابتة في روسيا. سيسمح لك ذلك بالحصول على السرعة دون تكاليف باهظة. سيكون تكوين nginx للواجهة الأمامية في هذه الحالة عبارة عن تطبيق وكيل بسيط ومألوف لنا جميعًا:

# vi /etc/nginx/sites-enabled/proxy # قم بتخزين ذاكرة التخزين المؤقت لمدة 30 يومًا في مساحة تخزين 100 جيجابايت proxy_cache_path /var/cache/nginxمستويات=1:2keys_zone=static:32m inactive=30d max_size=100g; server (استماع 80; server_name example.com; # في الواقع، موقع الوكيل الخاص بنا ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # عنوان الواجهة الخلفية proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache static; proxy_cache_valid 30d; proxy_ignore_headers "التحكم في ذاكرة التخزين المؤقت" "انتهاء الصلاحية";

الاستنتاجات

اليوم، بمساعدة nginx، يمكنك حل العديد من المشكلات المختلفة، والعديد منها لا يتعلق بخادم الويب وبروتوكول HTTP على الإطلاق. يعد وكيل البريد وخادم البث وواجهة Git مجرد بعض من هذه المهام.

يمكن استخدام NGINX ليس فقط كخادم ويب أو وكيل http، ولكن أيضًا لتفويض البريد عبر بروتوكولات SMTP وIMAP وPOP3. سيسمح لك هذا بتكوين:

• نقطة دخول واحدة لنظام بريد إلكتروني قابل للتطوير.
• موازنة التحميل بين كافة خوادم البريد.

في هذه المقالة، يتم إجراء التثبيت على نظام التشغيل Linux. كخدمة بريد يتم إرسال الطلبات إليها، يمكنك استخدام postfix وexim وdovecot وexchange وiredmail Assembly والمزيد.

مبدأ التشغيل

يقبل NGINX الطلبات ويصادق على خادم الويب. اعتمادًا على نتيجة تسجيل الدخول والتحقق من كلمة المرور، سيُرجع الوكيل استجابة بعدة رؤوس.

في حالة النجاح:

وبالتالي، فإننا نحدد الخادم ومنفذ خادم البريد بناءً على المصادقة. وهذا يوفر العديد من الفرص مع المعرفة المناسبة بلغات البرمجة.

في حالة الفشل:

اعتمادا على نتيجة المصادقة والرأس، تتم إعادة توجيه العميل إلى خادم البريد الذي نحتاجه.

تحضير الخادم

لنجري بعض التغييرات على إعدادات أمان الخادم.

SELinux

نقوم بتعطيل SELinux إذا كنا نستخدم CentOS أو إذا كنا نستخدم نظام الأمان هذا على Ubuntu:

السادس /etc/selinux/config

SELINUX=معطل

جدار الحماية

إذا استخدمنا جدار الحماية (الافتراضي في CentOS):

جدار الحماية-cmd --دائم --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

جدار الحماية-cmd --إعادة التحميل

إذا استخدمنا iptables (الافتراضي في Ubuntu):

iptables -A INPUT -p tcp --dport 25 -j قبول

iptables -A INPUT -p tcp --dport 110 -j قبول

iptables -A INPUT -p tcp --dport 143 -j قبول

apt-get install iptables-persistent

iptables-save > /etc/iptables/rules.v4

* في هذا المثال سمحنا بـ SMTP (25)، POP3 (110)، IMAP (143).

تثبيت نجينكس

يختلف تثبيت NGINX قليلاً اعتمادًا على نظام التشغيل.

أو لينكس سينتوس:

يم تثبيت nginx

أو لينكس أوبونتو:

ملائمة تثبيت nginx

نحن نسمح بالتشغيل التلقائي للخدمة وتشغيلها:

سيستيمكتل تمكين nginx

سيستيمكتل بدء nginx

إذا كان NGINX مثبتًا بالفعل على النظام، فتحقق من الوحدات التي يعمل معها:

سنتلقى قائمة بالخيارات التي تم إنشاء خادم الويب بها - ومن بينها يجب أن نرى --with-mail . إذا لم تكن الوحدة المطلوبة موجودة، فستحتاج إلى تحديث nginx

إعداد إنجينكس

افتح ملف تكوين nginx وأضف خيار البريد:

السادس /etc/nginx/nginx.conf

بريد (

auth_http المضيف المحلي:80/auth.php;

الخادم (
استمع 25؛
بروتوكول SMTP؛
smtp_auth تسجيل الدخول عادي cram-md5؛
}

الخادم (
استمع 110؛
بروتوكول البوب3؛

}

الخادم (
استمع 143؛
صورة البروتوكول؛
}
}

* أين:

• server_name هو اسم خادم البريد الذي سيتم عرضه في تحية SMTP.
• auth_http - خادم الويب وعنوان URL لطلب المصادقة.
• proxy_pass_error_message - يسمح أو يرفض عرض رسالة عند فشل المصادقة.
• الاستماع - المنفذ الذي يتم الاستماع للطلبات عليه.
• البروتوكول - بروتوكول التطبيق الذي يستمع إليه المنفذ المقابل.
• smtp_auth - طرق المصادقة المتاحة لـ SMTP.
• pop3_auth - طرق المصادقة المتاحة لـ POP3.

في قسم http - الخادم أضف:

الخادم (
الاستماع 80 default_server؛
الاستماع [::]:80 default_server؛
...

الموقع ~ \.php$ (
تعيين $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index Index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
تشمل fastcgi_params؛
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

أعد تشغيل خادم nginx:

إعادة تشغيل Systemctl Nginx

تثبيت وتكوين PHP

لإجراء المصادقة باستخدام PHP، تحتاج إلى تثبيت الحزم التالية على نظامك.

إذا كان CentOS:

يم تثبيت PHP php-fpm

إذا أوبونتو:

الرابطة بين الحصول على تثبيت PHP php-fpm

إطلاق PHP-FPM:

سيستيمكتل تمكين php-fpm

يبدأ Systemctl بـ php-fpm

المصادقة

يتم إجراء التحقق من تسجيل الدخول وكلمة المرور بواسطة برنامج نصي، يتم تحديد المسار إليه بواسطة خيار auth_http. في مثالنا، هذا هو برنامج PHP النصي.

مثال على قالب رسمي لبرنامج نصي للتحقق من تسجيل الدخول وكلمة المرور:

السادس /usr/share/nginx/html/auth.php

* يقبل هذا البرنامج النصي أي تسجيل دخول وكلمة مرور ويعيد توجيه الطلبات إلى الخوادم 192.168.1.22 و192.168.1.33. لتعيين خوارزمية المصادقة، قم بتحرير الأسطر 61 - 64. الأسطر 73 - 77 مسؤولة عن إعادة الخوادم التي تم إعادة التوجيه إليها - في هذا المثال، إذا كان تسجيل الدخول يبدأ بالأحرف "a" و"c" و"f" "، "g"، فستكون إعادة التوجيه إلى خادم mailhost01، وإلا إلى mailhost02. يمكن تعيين تعيين أسماء الخادم إلى عناوين IP على السطرين 31 و32، وإلا فسيتم إجراء الاتصال باستخدام اسم المجال.

إعداد خادم البريد

يتم تبادل البيانات بين وكيل NGINX وخادم البريد بنص واضح. من الضروري إضافة إمكانية المصادقة باستخدام آلية PLAIN إلى الاستثناء. على سبيل المثال، لتكوين Dovecot، قم بما يلي:

السادس /etc/dovecot/conf.d/10-auth.conf

أضف الأسطر:

عن بعد 192.168.1.11 (
Disable_plaintext_auth = no
}

* في هذا المثال، سمحنا بطلبات المصادقة البسيطة من الخادم 192.168.1.11.

نتحقق أيضًا من:

* إذا تم ضبط SSL على "مطلوب"، فلن يعمل الفحص، حيث اتضح أنه من ناحية، يسمح الخادم بالطلبات بنص واضح، ولكنه يتطلب تشفير SSL.

إعادة تشغيل خدمة Dovecot:

إعادة تشغيل systemctl

إعداد العميل

يمكنك المتابعة للتحقق من إعدادات الوكيل لدينا. للقيام بذلك، في إعدادات العميل، حدد عنوان أو اسم خادم nginx كـ IMAP/POP2/SMTP، على سبيل المثال:

* في هذا المثال، تم تكوين عميل البريد للاتصال بالخادم 192.168.1.11 عبر المنافذ المفتوحة 143 (IMAP) و25 (SMTP).

التشفير

الآن لنقم بإعداد اتصال SSL. يجب إنشاء Nginx باستخدام الوحدة mail_ssl_module - تحقق من ذلك باستخدام الأمر:

إذا كانت الوحدة المطلوبة مفقودة، فإننا نعيد بناء nginx.

ثم نقوم بتحرير ملف التكوين الخاص بنا:

السادس /etc/nginx/nginx.conf

بريد (
اسم الخادم mail.domain.local;
auth_http localhost/auth.php;

Proxy_pass_error_message قيد التشغيل؛

تشغيل طبقة المقابس الآمنة؛
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
تمت مشاركة ssl_session_cache:SSL:10m;
ssl_session_timeout 10 م؛

الخادم (
استمع 110؛
بروتوكول البوب3؛
pop3_auth عادي apop cram-md5؛
}

الخادم (
استمع 143؛
صورة البروتوكول؛
}

السبب: تم ​​تشغيل نظام الأمان SELinux.

الحل: تعطيل أو تكوين SELinux.

Nginx هو خادم ويب صغير وسريع جدًا وفعال إلى حد ما وخادم وكيل بريد، تم تطويره بواسطة Igor Sysoev (rambler.ru). نظرًا للاستهلاك المنخفض جدًا لموارد النظام وسرعة التشغيل، فضلاً عن مرونة التكوين، فإن الويب خادم نجينكسغالبًا ما يتم استخدامه كواجهة أمامية للخوادم ذات الوزن الثقيل، مثل أباتشي، في المشاريع ذات الأحمال العالية. الخيار الكلاسيكي هو الجمع بين Nginx - Apache - FastCGI. العمل في مثل هذا المخطط خادم نجينكس، يقبل جميع الطلبات الواردة عبر HTTP، واعتمادًا على التكوين والطلب نفسه، يقرر ما إذا كان سيتم معالجة الطلب نفسه ومنح العميل استجابة جاهزة أو إرسال الطلب للمعالجة إلى أحد الواجهات الخلفية ( أباتشيأو FastCGI).

كما تعلم، يقوم خادم Apache بمعالجة كل طلب في عملية منفصلة (سلسلة)، والتي، يجب أن يقال، تستهلك قدرًا صغيرًا جدًا من موارد النظام، إذا كان هناك 10-20 من هذه العمليات، فهذا هراء، وإذا كان هناك 100-500 أو أكثر، يصبح النظام أي متعة.

دعونا نحاول أن نتخيل وضعا مماثلا. لنفترض على أباتشييأتي 300 طلب HTTP من العملاء، و150 عميلًا على خطوط مؤجرة سريعة، و150 عميلًا آخرين على قنوات إنترنت بطيئة نسبيًا، حتى لو لم تكن على أجهزة المودم. ماذا يحدث في هذه الحالة؟ ويحدث ما يلي: من أجل معالجة هذه الاتصالات الـ 300، يقوم خادم الويب Apache بإنشاء عملية (خيط) لكل منها، وسيقوم بإنشاء محتوى بسرعة، وسيأخذ 150 عميلًا سريعًا على الفور نتيجة طلباتهم، والعمليات التي تخدمهم سيتم قتلها وتحرير الموارد، و150 منها بطيئة، وستتلقى نتائج طلباتها ببطء، بسبب ضيق قناة الإنترنت، ونتيجة لذلك ستتعطل 150 عملية في النظام أباتشي، في انتظار قيام العملاء بالتقاط المحتوى الذي تم إنشاؤه بواسطة خادم الويب، مما يلتهم الكثير من موارد النظام. بطبيعة الحال، الوضع افتراضي، لكن أعتقد أن الجوهر واضح. تساعد الحزمة في تصحيح الوضع الموضح أعلاه. بعد قراءة الطلب بالكامل من العميل، يقوم بتقديمه للمعالجة أباتشي، والذي يقوم بدوره بإنشاء المحتوى وإرجاع الاستجابة النهائية إلى Nginx في أسرع وقت ممكن، وبعد ذلك يمكنه إنهاء العملية بضمير مرتاح وتحرير موارد النظام التي تشغلها. خادم الويب Nginx، يتلقى نتيجة الطلب من أباتشي، يكتبه إلى مخزن مؤقت أو حتى إلى ملف على القرص ويمكنه إعطاؤه للعملاء البطيئين للمدة المرغوبة، بينما تستهلك عمليات عمله القليل جدًا من الموارد لدرجة .. "إنه من المضحك التحدث عن ذلك" ©. :) هذا المخطط يوفر موارد النظام بشكل كبير، وأكرر، لكن عمليات Nginx العاملة تستهلك كمية صغيرة من الموارد، وهذا ينطبق بشكل خاص على المشاريع الكبيرة.

وهذا ليس سوى جزء صغير مما يمكن أن يفعله خادم Nginx؛ ولا تنس إمكانيات التخزين المؤقت للبيانات والعمل بها com.memcached. سأقدم قائمة بالوظائف الرئيسية لخادم الويب Nginx.

وظيفة خادم Nginx كخادم HTTP

• معالجة المحتوى الثابت، ملفات الفهرس، قائمة الدليل، فتح ذاكرة التخزين المؤقت لواصف الملف؛
• تسريع الوكيل مع التخزين المؤقت، وتوزيع التحميل والتسامح مع الخطأ؛
• الدعم المتسارع FastCGIخوادم مزودة بالتخزين المؤقت وتوزيع الأحمال والتسامح مع الأخطاء؛
• هيكل معياري، دعم لمرشحات مختلفة (SSI، XSLT، GZIP، استئناف، استجابات مقسمة)؛
• دعم امتدادات SSL وTLS SNI؛
• على أساس الملكية الفكريةأو على أساس الاسمالخوادم الافتراضية؛
• العمل مع KeepAlive والاتصالات عبر الأنابيب؛
• القدرة على تكوين أي مهلات وكذلك عدد وحجم المخازن المؤقتة، على المستوى خادم أباتشي;
• تنفيذ إجراءات مختلفة حسب عنوان العميل؛
• تغيير عناوين URI باستخدام التعبيرات العادية؛
• صفحات خطأ خاصة لـ 4xx و5xx؛
• تقييد الوصول بناءً على عنوان العميل أو كلمة المرور؛
• إعداد تنسيقات ملفات السجل، وتدوير السجلات؛
• الحد من سرعة الاستجابة للعميل؛
• الحد من عدد الاتصالات والطلبات المتزامنة؛
• يدعم أساليب PUT، DELETE، MKCOL، COPY وMOVE؛
• تغيير الإعدادات وتحديث الخادم دون توقف العمل؛
• مدمج بيرل;

وظيفة خادم Nginx كخادم وكيل للبريد

• إعادة التوجيه إلى الواجهة الخلفية IMAP/POP3 باستخدام خادم مصادقة HTTP خارجي؛
• التحقق من SMTP الخاص بالمستخدم على خادم مصادقة HTTP خارجي وإعادة التوجيه إلى خادم SMTP داخلي؛
• يدعم طرق المصادقة التالية:
  • POP3 - المستخدم/المرور، APOP، تسجيل الدخول المصادقة/PLAIN/CRAM-MD5؛
  • IMAP - تسجيل الدخول، تسجيل دخول AUTH/PLAIN/CRAM-MD5؛
  • SMTP - سجل المصادقة/ عادي/ CRAM-MD5؛
• دعم طبقة المقابس الآمنة؛
• دعم STARTTLS وSTLS؛

أنظمة التشغيل والأنظمة الأساسية التي يدعمها خادم الويب Nginx

• FreeBSD، من 3 إلى 8 - المنصات، i386 وamd64؛
• Linux، من 2.2 إلى 2.6 - منصة i386؛ لينكس 2.6 - AMD64؛
• سولاريس 9 - منصات i386 وsun4u؛ منصات سولاريس 10 - i386 وamd64 وsun4v؛
• منصات MacOS X PPC، i386؛
• ويندوز إكس بي، ويندوز سيرفر 2003؛ (حاليًا في الاختبار التجريبي)

بنية خادم Nginx وقابلية التوسع

• العملية الرئيسية (الرئيسية)، والعديد من العمليات المنفذة (التي تم تكوينها في ملف التكوين) التي تعمل تحت مستخدم لا يتمتع بالامتيازات؛
• دعم طرق معالجة الاتصال التالية:
  • التحديد هو الأسلوب القياسي. يتم إنشاء وحدة Nginx المقابلة تلقائيًا إذا لم يتم العثور على طريقة أكثر كفاءة على منصة معينة. يمكنك فرض تمكين أو تعطيل إنشاء وحدة معينة باستخدام خيارات التكوين --with-select_module أو --without-select_module.
  • الاستطلاع هو الطريقة القياسية. يتم إنشاء وحدة Nginx المقابلة تلقائيًا إذا لم يتم العثور على طريقة أكثر كفاءة على منصة معينة. يمكنك فرض تمكين أو تعطيل بناء وحدة معينة باستخدام خيارات التكوين --with-poll_module أو --without-poll_module.
  • kqueue هي طريقة فعالة تستخدم في أنظمة التشغيل FreeBSD 4.1+ وOpenBSD 2.9+ وNetBSD 2.0 وMacOS X. عند استخدامها على الأجهزة ذات المعالج المزدوج التي تعمل بنظام MacOS X، يمكن أن تسبب ذعرًا في kernel.
  • epoll هي طريقة فعالة مستخدمة في Linux 2.6+. تحتوي بعض التوزيعات، مثل SuSE 8.2، على تصحيحات لدعم epoll في الإصدار 2.4 من النواة.
  • rtsig - إشارات في الوقت الحقيقي، وهي طريقة فعالة مستخدمة في Linux 2.2.19+. افتراضيًا، لا يمكن أن يكون هناك أكثر من 1024 إشارة في قائمة الانتظار للنظام بأكمله. هذا لا يكفي للخوادم ذات التحميل العالي؛ يجب زيادة حجم قائمة الانتظار باستخدام معلمة kernel /proc/sys/kernel/rtsig-max. ومع ذلك، اعتبارًا من Linux 2.6.6-mm2، لم يعد هذا الخيار متاحًا، وبدلاً من ذلك، تحتوي كل عملية على قائمة انتظار إشارة منفصلة، ​​يتم تحديد حجمها باستخدام RLIMIT_SIGPENDING.
  • عندما تمتلئ قائمة الانتظار، خادم نجينكسيقوم بإعادة ضبطه ومعالجة الاتصالات باستخدام طريقة الاستقصاء حتى يعود الوضع إلى طبيعته.
  • يعد /dev/poll طريقة فعالة، مدعومة على أنظمة التشغيل Solaris 7 11/99+ وHP/UX 11.22+ (eventport) وIRIX 6.5.15+ وTru64 UNIX 5.1A+.
  • Eventport - منافذ الأحداث، وهي طريقة فعالة مستخدمة في Solaris 10. قبل الاستخدام، تحتاج إلى تثبيت تصحيح لتجنب الذعر في kernel.
• استخدام إمكانيات طريقة kqueue مثل EV_CLEAR، وEV_DISABLE (لتعطيل حدث مؤقتًا)، وNOT_LOWAT، وEV_EOF، وعدد البيانات المتاحة، ورموز الخطأ؛
• يعمل مع sendfile (FreeBSD 3.1+، Linux 2.2.+، Mac OS X 10.5+)، sendfile64 (Linux 2.4.21+) وsendfilev (Solaris 8 7/01+)؛
• دعم مرشحات القبول (FreeBSD 4.1+) وTCP_DEFER_ACCEPT (Linux 2.4+)؛
• 10000 اتصال HTTP غير نشط يستهلك حوالي 2.5 مليون من الذاكرة؛
• الحد الأدنى لعدد عمليات نسخ البيانات؛