المحتوى عن 'virtual host'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 2 نتائج

  1. مقدمة يُستخدم ميثاق (بروتوكول) الوِب TLS (اختصار لـ Transport Layer Security، أمان طبقة النقل) وسلفه SSL (اختصار لـ Secure Sockets Layer، طبقة المقابس الآمنة) لتغليف البيانات العاديّة ضمن إطار محميّ وآمن. يمكن للخواديم باستخدام هذه التقنية أن تؤمّن تبادل البيانات بينها وبين العملاء حتى ولو اعتُرِضت طريقُ الرسائل بين الخادوم والعميل. يساعد نظام الشهادات الأمنية Certificates المستخدِمين والزوار في التحقّق من أمان المواقع التي يتّصلون بها. سنقدّم في هذا الدليل الخطوات اللازمة لإعداد شهادة أمنيّة موقَّعة ذاتيًّا Self-signed certificate لاستخدامها مع خادوم الوِب Apache على أوبونتو 16.04. ملحوظة: تعمّي الشهادات الموقَّعة ذاتيًّا الاتصالات بين الخادوم والعملاء؛ لكن لن يمكنَ للعملاء استخدامُها للتحقّق من التحقّق من هويّة خادومك تلقائيًّا، إذ أنه لم تُوقّعها سلطة معترف بها. تتضمَّن المتصفّحات مثل فيرفكس وكروم قائمة بالسلطات المعترف بها والمخوَّلة إصدار شهادات TLS. يُناسب استخدام الشهادات الموقَّعة ذاتيًّا بيئات الاختبار، على الحاسوب الشخصي أو عندما لا يكون لديك نطاق Domain؛ مثلا في واجهات الوِب غير المتاحة للعموم. إن كان لديك نطاق فالأفضل أن تستخدم شهادة أمنية من سطلة معترف بها. يمكنك الحصول على شهادة مجانيّة من Let’s encrypt وإعدادها. المتطلبات ستحتاج قبل البدء بتنفيذ الخطوات الواردة في هذا الدرس إلى إعداد مستخدم إداري بامتيازات sudo غير المستخدم الجذر. راجع درس الإعداد الابتدائي لخادوم أوبونتو لمعرفة كيفية ذلك. ستحتاج أيضا لتثبيت خادوم الوِب Apache. إن رغبت في تثبيت كامل حزم LAMP (أي لينكس Linux، أباتش Apache، وMySQL وPHP) فالدرس كيف تثبت حزم MySQL ،Apache ،Linux :LAMP و PHP موجود لهذا الغرض؛ أما إن كنت ترغب في تثبيت Apache لوحده فيمكنك الاعتماد على الدرس المُشار إليه مع ترك الخطوات الخاصّة بكلّ من MySQL وPHP. تأكّد من توفّرك على المتطلّبات ثم نفّذ الخطوات المشروحة أدناه. الخطوة اﻷولى: إنشاء شهادة SSL يعمل بروتكول TLS (وسلفه SSL) باستخدام مفتاحيْن للتعميّة واحد عمومي Public وآخر خاصّ (أو سرّي) Private. يُخزَّن المفتاح السّري على الخادوم ولا يجوز أن يطّلع عليه أي عميل فهو خاصّ بالخادوم الذي يستخدمه لتعميّة المحتوى المُرسَل إلى العملاء. يُمكن لأيّ عميل الاطّلاع على شهادة TLS. تحوي هذه الشهادة المفتاح العموميّ الذي يُستخدَم لفكّ التعميّة عن المحتوى القادم من الخادوم. ملحوظة: رغم أن استخدام البروتكول SSL يقلّ يومًا بعد يوم إلا أن المصطلح “شهادة SSL” لا يزال يُستَخدَم كثيرًا، ويُقصَد به - في الغالب - TLS، الذي هو نسخة محسَّنة من SSL. تتيح مكتبة OpenSSL (مكتبة برمجيّة توفّر أدوات للتعامل مع شهادات SSL/TLS) إنشاء مفتاح تعميّة موقَّع ذاتيًّا بالأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt ستُطرَح عليك مجموعة من الأسئلة، ولكن قبل النظر في تلك الأسئلة سنشرح الخيارات المذكورة في الأمر السابق: openssl: هذا هو الأمر الأساسي لإنشاء الشهادات، المفاتيح وبقية الملفات وإدارتها في OpenSSL. req: يحدّد هذا الأمر الفرعي المعيار X.509 لاستخدامه في البنية التحتيّة التي نريد استخدامها لإدارة المفاتيح العموميّة. يعتمد الميثاقان SSL وTLS المعيار X.509 لإدارة المفاتيح العمومية. نستخدم هذا الأمر الفرعي لطلب إنشاء شهادة تتوافق مع هذا المعيار. x.509: يغيّر هذا الخيار طريقة عمل الأمر الفرعي السابق ليخبره أننا في طور إنشاء شهادة موّقَّعة ذاتيًّا بدلا من إرسال طلب لتوقيع شهادة الذي هو السلوك المبدئي للأمر الفرعي. nodes: يطلُب هذا الخيار من openssl تجاوز خيار تأمين الشهادة بعبارة سرّ Passphrase. نريد أن يكون Apache قادرا على قراءة الشهادة بدون تدخّل من المستخدم عند بدْء تشغيل الخادوم. يمنع وجود عبارة سرّ Apache من قراءة ملفّ الشهادة وسنحتاج عند وجودها لإدخالها في كلّ مرة نعيد فيها تشغيل الخادوم. days 365: يحدّد هذا الخيار مدّة صلاحيّة الشهادة. اخترنا سنة. newkey rsa:2048: يخبر هذا الخيار الأمر openssl أننا نريد توليد شهادة ومفتاح جديد في نفس الوقت. بما أننا لم نولّد المفتاح المطلوب لتوقيع الشهادة في خطوة منفصلة فإننا نحتاج لإنشائه مع الشهادة. يحدّد الجزء rsa:2048 نوعيّة المفتاح بـ RSA وطوله بـ 2048 بت. keyout: يحدّد المسار الذي نريد حفظ المفتاح الخاصّ فيه. out: يحدّد المسار الذي نريد حفظ الشهادة فيه. ستنشئ هذه الخيارات مفاتيح التعميّة والشهادة. يطلُب الأمر كما أسلفنا الإجابة على بضعة أسئلة كما في الصورة التالية. تتعلّق الأسئلة بمعلومات عامة من قبيل الدولة والمدينة والمؤسّسة والمنظَّمة المُصدِرة للشهادة إضافة إلى معلومات عن الخادوم. يتعلّق أهمّ الأسئلة المطروحة - السطر Common Name - بالخادوم. يجب أن تجيب باسم النطاق الذي يعمل عليه الخادوم أو - وهو الأكثر شيوعا - عنوان IP العمومي للخادوم. يبدو المحثّ Prompt على النحو التالي: Country Name (2 letter code) [AU]:حرفان يمثّلان الدولة State or Province Name (full name) [Some-State]:اسم المنطقة (المحافظة أو الولاية) Locality Name (eg, city) []:اسم المدينة Organization Name (eg, company) [Internet Widgits Pty Ltd]:اسم المنظَّمة أو الشركة Organizational Unit Name (eg, section) []:اسم الفرع Common Name (e.g. server FQDN or YOUR name) []:عنوان الخادوم Email Address []:بريد المسؤول سيوضع الملفان المنشآن في مجلّدات فرعيّة من المجلّد etc/ ssl/ حسب ماهو محدَّد في الأمر. سنحتاج أيضًا - ما دمنا نتحدَّث عن OpenSSL - إلى إنشاء مجموعة Diffie-Hellman قويّة لتُستخدَم عندما يُناقش الخادوم طريقة نقل البيانات مع العملاء (خطوة من خطوات عدّة ضمن تقنيّة SSL/TLS لتأمين نقل البيانات). ينشئ اﻷمر التالي المطلوب: sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 يمكن أن يستغرق الأمر بضعة دقائق، نحصُل بعدها على مجموعة Diffie-Hellman مناسبة (على المسار etc/ssl/certs/dhparam.pem/) لاستعمالها في إعداداتنا. الخطوة الثانية: إعداد Apache لاستخدام SSL أنشأنا في الخطوة السابقة ملفّيْ الشهادة والمفتاح الخاصّ. نحتاج الآن لضبط Apache للاستفادة من هذيْن الملفّيْن. سنعدّل بضعة إعدادات: سننشئ مقطعا جديدًا في إعدادات Apache لتحديد خيارات إعداد مبدئيّة آمنة لـ SSL. سنعدّل المضيف الافتراضي Virtual host الخاص بـ SSL للإشارة إلى شهادة SSL التي أنشأناها في الخطوة السابقة. سنعدّل المضيف الافتراضي غير المُعمَّى ليعيد توجيه جميع الطلبات إلى المضيف الافتراضي المُعمَّى (الخاص بـ SSL). يُنصَح بهذا الإجراء لجعل جميع الاتصالات القادمة إلى الموقع آمنة (تمرّ عبر شهادة SSL). يجدر بالإعدادات التي سنحصُل عليها بعد تنفيذ النقاط المُشار إليها أعلاه أن تكون آمنة. تحديد خيارات إعداد مبدئيّة آمنة في Apache سننشئ أولا ملفّ إعداد جديدًا في Apache نعرّف فيه بعض إعدادات SSL. سنضبُط Apache للعمل بخوارزميّات تعميّة فعّالة ونفعّل بعض الميزات المتقدّمة لمساعدتنا في إبقاء خادومنا آمنا. سيُمكن لأيّ مضيف افتراضي يفعّل SSL. أنشئ ملفّ إعداد جديد ضمن المجلَّد etc/apache2/conf-available/ (مجلَّد إعدادات Apache). سنسمّي هذا الملف بـssl-params.conf حتى يكون واضحًا أنه يتعلّق بمعطيات Parameters إعداد SSL. sudo nano /etc/apache2/conf-available/ssl-params.conf سنعتمد لضبط إعدادات Apache بطريقة آمنة على توصيّات Remy van Elst من موقع Cipherli.st. جُهِّز هذا الموقع لتوفير إعدادات تعميّة جاهزة للاستعمال في أكثر البرمجيّات شيوعًا على الخواديم. ملحوظة توفّر الإعدادات المُقترَحة مبدئيًّا في الموقع أعلاه درجة أمان عاليّة. يمكن أن تأتي هذه الدرجة من الأمان على حساب التوافق مع البرامج العميلة (المتصفّحات أو أنظمة التشغيل القديمة). إن أردت دعم إصدارات قديمة من هذه البرامج فإن الموقع يوفّر إعدادات بديلة للإعدادات المبدئيّة، يمكنك الحصول عليها بالنقر على الرابط “Yes, give me a ciphersuite that works with legacy / old software” وستلاحظ أن الإعدادات تبدّلت. يعتمد الخيار بين النسخة المبدئية من الإعدادات والنسخة البديلة على نوعيّة العملاء التي تريد دعمها. توفّر النسختان أمانًا جيّدًا. سننسخ - لأغراض هذا الدرس - الإعدادات المقترحة، مع إجراء تعديليْن عليها. سنعدّل التعليمة SSLOpenSSLConfCmd DHParameters لتشير إلى ملف Diffie-Hellman الذي أنشأناه في الخطوة الأولى. سنعدّل أيضًا تعليمات الترويسة لتغيير عمل الخاصيّة Strict-Transport-Security وذلك بحذف التعليمة preload. توفّر هذه الخاصيّة أمانًا عاليَّا جدًّا إلا أنها يمكن إن فُعِّلت بدون وعي أو بطريقة غير صحيحة - خصوصًا عند استخدام الميزة preload - أن تؤدّي إلى اختلالات كبيرة في عمل الخادوم. تأكّد عندما تفعِّل هذه الميزة أنك تدرك جيّدًا ما تفعله. # from https://cipherli.st/ # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLProtocol All -SSLv2 -SSLv3 SSLHonorCipherOrder On # تعطيل التعليمة preload في الخاصيّة Strict-Transport-Security # يمكنك إن أردت تفعيل هذه الخاصية وذلك بنزع علامة التعليق # من بداية السطر #Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # نفس التعليمة السابقة ولكن دون preload Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains" Header always set X-Frame-Options DENY Header always set X-Content-Type-Options nosniff # Requires Apache >= 2.4 SSLCompression off SSLSessionTickets Off SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)" # أضفنا هنا المسار إلى ملفّ Diffie-Hellman SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem" احفظ الملفّ ثم أغلقه عندما تكون جاهزا لذلك. تعديل ملف مضيف SSL الافتراضي المبدئي ننتقل الآن إلى الملف المبدئي Default لمضيف SSL الافتراضي الموجود على المسار etc/apache2/sites-available/default-ssl.conf/. إن كنت تستخدم مضيفا اقتراضيًّا آخر فأبدله بالمضيف الافتراضي المبدئي في الأمر أدناه. نأخذ أولًا نسخة احتياطية من الملف: sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak ثم نفتح ملف المضيف الافتراضي لتحريره: sudo nano /etc/apache2/sites-available/default-ssl.conf يبدو محتوى الملف، بعد نزع أغلب التعليقات، على النحو التالي: <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> سنعدّل قليلا على الملف بإعداد تعليمات بريد مدير الخادوم، عنوان، اسم الخادوم… إلخ. كما سنعدّل تعليمة SSL لتشير إلى مسار ملفّيْ الشهادة والمفاتيح. نختُم بنزع التعليق عن خيار يوفّر الدعم للمتصفّحات القديمة لتفعيله. يبدو الملف بعد التعديلات كالتالي: <IfModule mod_ssl.c> <VirtualHost _default_:443> # بريد مدير الخادوم ServerAdmin your_email@example.com # نطاق الخادوم أو عنوان IP الخاص به ServerName server_domain_or_IP DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # دعم المتصفحات القديمة BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> احفظ الملف ثم أغلقه. إعادة توجيه طلبات HTTP (غير المُعمَّاة) إلى HTTPS يجيب الخادوم بإعداداته الحاليّة على الطلبات الآمنة (HTTPS) وغير الآمنة (HTTP) على حدّ السواء. يُنصَح في أغلب الحالات من أجل أمان أعلى أن تُوجَّه طلبات HTTP تلقائيَّا إلى HTTPS. نفتح ملف المضيف الافتراضي - أو المضيف الذي تريده - لتحريره: sudo nano /etc/apache2/sites-available/000-default.conf كلّ ما نحتاجه هو إضافة تعليمة إعادة إعادة التوجيه Redirect داخل إعداد الوسم VirtualHost والإشارة إلى النسخة الآمنة من الموقع (https): <VirtualHost *:80> . . . Redirect "/" "https://your_domain_or_IP/" . . . </VirtualHost> احفظ الملف ثم أغلقه. الخطوة الثالثة: تعديل الجدار الناري إن كان جدار ufw الناري مفعّلًا، وهو ما توصي به الدروس المُشار إليها في المتطلّبات، فقد تحتاج لتعديل إعداداتِه من أجل السماح للبيانات المُؤَمَّنة (عبر SSL). يُسجّل Apache أثناء تثبيته مجموعات من المعلومات المختصرة Profiles لدى جدار ufw الناري. يمكننا عرض المجموعات المتوفّرة بالأمر التالي: sudo ufw app list تظهر مُخرجات الأمر : Available applications: Apache Apache Full Apache Secure OpenSSH يمكنك عرض الإعداد الحالي بالأمر sudo ufw status إن كان إعدادك الحالي يسمح لطلبات HTTP فقط فستبدو إعداداتك كالتالي” Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6) يمكننا تفعيل المجموعة Apache Full للسماح لطلبات HTTPS وHTTP معًا، ثم حذف المجموعة Apache لأننا لم نعد بحاجة إليها، فهي متَضَمَّنة في المجموعة Apache Full : sudo ufw allow 'Apache Full' sudo ufw delete allow 'Apache' ملحوظة: يمكنك استخدام الأمر sudo ufw app info PROFILE حيث PROFILE اسم مجموعة المعلومات لمعرفة المنافذ Ports والبروتوكولات التي تسمح المجموعة للطلبات بالمرور عبرها. يجب أن تبدو حالة الجدار الناري الآن على النحو التالي: sudo ufw status المخرجات: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6) الخطوة الرابعة: اعتماد التغييرات في Apache نحن جاهزون الآن، بعد أن عدّلنا الإعدادات، لتفعيل وحدات Modules الترويسات Headers وSSL في Apache، وتفعيل المضيف الافتراضي الجاهز لاستخدام SSL ثم إعادة تشغيل Apache. يفعّل الأمران التاليّان على التوالي mod_ssl (وحدة SSL في Apache) وmod_headers (وحدة الترويسات) اللتين تحتاجهما إعداداتنا للعمل: sudo a2enmod ssl sudo a2enmod headers ثم نفعّل المضيف الافتراضي (ضع اسم المضيف مكان default-ssl إن كنت تستخدم مضيفًا غير المضيف المبدئي): sudo a2ensite default-ssl نحتاج أيضًا لتفعيل ملفّ الإعداد ssl-params الذي أنشأناه سابقا: sudo a2enconf ssl-params يجدر بالوحدات المطلوبة أن تكون الآن مفعَّلة وجاهزة للعمل، بقي لنا فقط اعتماد التغييرات. لكن قبل ذلك سنتأكّد من أنه لا توجد أخطاء صياغة في الملفات التي أعددناها وذلك بتنفيذ الأمر التالي: sudo apache2ctl configtest إن جرى كلّ شيء على ما يُرام فستظهر رسالة تشبه ما يلي: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK السطر الأول ليس سوى رسالة تفيد بأنّ التعليمة ServerName غير مضبوطة لتعمل على كامل الخادوم (مثلا مضبوطة في المضيفات الافتراضية فقط). يمكنك التخلّص من هذه الرسالة - إن أردت - بضبط قيمة التعليمة ServerName على نطاق الخادوم أو عنوان IP الخاصّ به في ملف الإعدادات العام etc/apache2/apache2.conf/. هذا الإعداد اختياري، فالرسالة لا تتسبّب في أي خلل. تظهر في السطر الثاني نتيجة التحقّق من الصياغة Syntax OK وتفيد بأنه لا توجد مشكلة من هذه الناحيّة. يمكننا إذن إعادة تشغيل خادوم الوِب لاعتماد التعديلات: sudo systemctl restart apache2 الخطوة الخامسة: اختبار التعمية افتح متصفّح الوِب وأدخل العنوان //:https متبوعًا باسم نطاق الخادوم أو عنوان IP الخاصّ به: https://server_domain_or_IP بما أنّ الشهادة الأمنيّة التي أنشأناه لا تصدُر من سلطة شهادات يثق بها المتصفّح فستظهر صفحة مخيفة عند زيارة الموقع تحمل الرسالة التالية. هذا السلوك متوقَّع وطبيعي. نهتمّ في هذا الدرس بجانب التعميّة من الشهادات الأمنيّة دون جانب التحقّق من هويّة المضيف (الموقع) الذي توفّره سلطات الشهادات (وهو جانب مهمّ أيضًا لأمان التصفّح). انقر على زرّ ADVANCED ثم انقر على الرابط الذي ينقلك إلى موقعك (يوجد عادة أسفل الصفحة). ستُنقَل إلى صفحة الموقع. إن نظرت إلى شريط العناوين في المتصفّح فسترى صورة قفل عليه علامة x أمام عنوان الموقع. يعني هذا الرّمز أن المتصفّح لم يستطع التحقّق من هوية الشهادة، إلا أنه يعمّي الاتصال بينك والخادوم. إن أعددتَ إعادة توجيه طلبات HTTP إلى HTTPS فيمكنك التحقق من نجاح الأمر بالذهاب إلى العنوان http://server_domain_or_IP (بدون حرف s في http). إن ظهرت نفس الأيقونة السابقة في شريط العناوين فهذا يعني نجاح الإعداد. الخطوة السادسة: جعل إعادة التوجيه دائما إن كنت متأكّدًا من رغبتك في السماح للطلبات الآمنة فقط (القادمة عبر HTTPS)، وتحقّقت في الخطوة السابقة من عمل توجيه طلبات HTTP إلى HTTPS فيجب عليك جعل إعادة التوجيه دائمة. افتح ملف إعداد المضيف الافتراضي الذي نريد: sudo nano /etc/apache2/sites-available/000-default.conf نبحث عن سطر إعادة التوجيه الذي أضفناه في خطوة سابقة ثم نضيف إليه الكلمة المفتاحية permanent على النحو التالي: <VirtualHost *:80> . . . Redirect permanent "/" "https://your_domain_or_IP/" . . . </VirtualHost> احفظ الملف ثم أغلقه. ملحوظة: إعادة التوجيه التي أعددناها في الخطوة الثانية باستخدام التعليمة Redirect فقط هي من النوع 302. تصبح إعادة التوجيه هذه من النوع 301 (الفرق بين إعادة التوجيه 301و302) عند إضافة الكلمة المفتاحية permanent (دائم) إلى التعليمة. نتحقّق من خلو الإعدادات من أخطاء في الصياغة: sudo apache2ctl configtest ثم عندما يكون كلّ شيء على ما يرام نعيد تشغيل خادوم الوِب: sudo systemctl restart apache2 ترجمة - بتصرّف للمقال How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 16.04 لصاحبه Justin Ellingwood.
  2. يُعتبَر خادوم ويب Apache الوسيلة الأكثر شعبيةً لتقديم المحتوى على شبكة الإنترنت، حيثُ يستعمله أكثر من نصف مواقع الويب على الشبكة لقدرته الفائقة ومرونته العالية. يُقسِّم خادوم Apache وظائفَه والعناصر التي تُكوِّنه إلى عدة وحدات يُمكِن تخصيصها وإعدادُها بشكل مستقل. تُسمَّى الوحدة الأساسية - التي تُمثِّل نطاقًا Domain أو موقع ويب - مُستضيفًا افتراضيًا Virtual host. تُتيح المُستضيفات الافتراضية إمكانية استضافة عدة نطاقات أو مواقع ويب على نفس العنوان باستخدام آليةٍ للمطابقة بين مُستضيف افتراضي وموقع ويب. تُناسِب هذه الطّريقة أي شخص يُريد استضافة عدة مواقع على نفس الخادوم الافتراضي الخاص Virtual private server, VPS. يُوجِّه كل واحد من النطاقات المضبوطة الزائرَ إلى مجلَّد مُحدَّد توجد به معلومات الموقع المطلوب دون أن يُشيرَ أبدًا إلى أن مواقع أخرى تُدار على نفس الخادوم. يُمكِن بطريقة المستضيفات الافتراضية ضبط عدد غير محدود من المواقع على نفس الخادوم ما دام يتحمّل عبئ الحِمل Load الذي تُمثِّله هذه المواقع. سنعرِض في هذا المقال طريقة إعداد مستضيفات افتراضية على خادوم ويب Apache يعمل على خادوم افتراضي خاص مع توزيعة أوبنتو 14.04. ستتعلَّم كيف تُقدِّم محتوى مختلِفا لزوّار متعدِّدين حسب النطاق الذي يطلبونه. المتطلباتقبل البدء في هذا الدّرس يجب إنشاء مستخدم آخر غير المستخدِم الجذر Root user كما هو موضَّح في الخطوات من 1 إلى 4 من الدرس الإعداد الابتدائي لخادوم أوبنتو. ستحتاج أيضًا إلى تثبيت خادوم ويب Apache لمتابعة الخطوات المذكروة في هذا الدّرس. إن لم تكُن ثبَّت البرنامج حتى الآن يُمكنك ذلك باستخدام أداة apt-get كما يلي: sudo apt-get update sudo apt-get install apache2بعد استكمال هذه الخطوات يُمكننا البدء. سنُنشئ خلال هذا الدرس مستضيفَيْن افتراضييْن، واحد للنطاق example.com والآخر لـ test.com. أثناء إعداد مستضيفاتك الافتراضية استخدِم النطاقات الخاصّة بك مكان المثاليْن المذكوريْن هنا. سنُريك خلال هذا الدّرس كيف تُحرِّر ملف المستضيفات على جهازك الشخصي Local hosts file لاختبار إعداداتك إن كنتَ تستخدم نطاقات وهمية. ستتمكَّن بهذه الطريقة من تجربة الإعدادات من جهازك الشخصي رغم أن المحتوى لن يكون مُتاحا لزوّار آخرين عبر النطاق الوهمي. الخطوة الأولى - أنشئ بنية المجلد Directory structureأول خطوة نقوم بها هي إنشاء بنية المجلَّد الذي سيحوي بيانات الموقِع الذي ننوي تقديمه إلى الزّوّار. يُعرَّف مبدأ المستند Document root بأنه المجلّد الأعلى مستوًى Top-level directory الذي سيبحث فيه خادوم وب Apache عن محتوى الموقع. بالنسبة لمثالنا سننشئ مبدأ مستند (مجلَّد) داخل المسار var/www/ لكلٍّ من المستضيفين الافتراضيّين الذين نعدهما. داخل كل من المجلَّدين نُنشئ مجلَّدًا باسم public_html، وهو المجلَّد الذي سيحوي ملفات الموقع وهو ما يمنح بعض المرونة في الاستضافة. لتطبيق ما ورد في الفقرة أعلاه نُنفِّذ الأوامر التالية: sudo mkdir -p /var/www/example.com/public_html sudo mkdir -p /var/www/test.com/public_htmlفي الأمرين السابقين يظهر كل من النطاقين الذين نريد تقديمهما من خادومنا الافتراضي الخاص باللون الأحمر. الخطوة الثانية - امنح الأذونات Permissionsأنشأنا في الخطوة الأولى بنية المجلَّدات، لكن هذه المجلَّدات مملوكة من المستخدِم الجذر، نظرا لاستخدام sudo أمام أمر إنشاء المجلّد. إن أردنا إعطاء المستخدِم العادي القدرة على تحرير الملفات الموجودة في مجلَّد الوب فبإمكاننا تغيير مُلكية هذه المجلّدات عن طريق الأمر: sudo chown -R $USER:$USER /var/www/example.com/public_html sudo chown -R $USER:$USER /var/www/test.com/public_htmlعند تنفيذ الأمر - بالضغط على زر Enter - فإن المتغيّر USER$ سيُبدَل بقيمته وهي اسم المستخدِم الحالي. ينتج عن الأمر تغيير ملكية المجلَّد public_html الذي يتضمّن محتوى الموقِع فيُصبِح المستخدم الحالي هو المالك بدلا من المستخدِم الجذر. سيتوجّب علينا أيضًا تغيير الأذونات قليلًا للتأكد من أنّ إذن القراءة متاح من مجلّد الويب العام (var/www/) وكل الملفات الموجودة داخله أو داخل المجلّدات المتفرّعة منه حتى يُقدَّم المحتوى بشكل صحيح: sudo chmod -R 755 /var/wwwلدى خادوم الويب الآن الأذونات التي يحتاجها لتقديم المحتوى، ولدى المستخدم أيضا القدرة على إنشاء وتحرير المجلَّدات التي يحتاجها. الخطوة الثالثة - أنشئ صفحات تجريبية Demo pages لكل مستضيف افتراضيفي هذه الخطوة سننشئ محتوى لتقديمه. الهدف من إنشاء المحتوى في هذه الخطوة توضيحي، لذا ستكون الصفحات بسيطة جدا: index.html لكل موقع. سنبدأ بـ example.com. نستطيع إنشاء وتحرير ملف index.html عن طريق محرِّر nano عبر الأمر التالي: nano /var/www/example.com/public_html/index.htmlأضف مستنَد HTML بسيطًا يُبرز اسم الموقع. يظهر الملف بالشكل التالي: <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Example.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Example.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف (Ctrl+O ثم زر Enter) ثم أغلقه بعد الانتهاء من تحريره (Ctrl+x). ننسخ الملف ليكون أساس الموقع الثاني عبر الأمر : cp /var/www/example.com/public_html/index.html /var/www/test.com/public_html/index.htmlيُمكِن بعدها فتح الملف وتحرير المعلومات لتُناسب الموقع الثاني: nano /var/www/test.com/public_html/index.html<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title> Test.com أهلًا بك في موقع</title> </head> <body dir="rtl"> <h1>هنيئا لك! المُستضيف الافتراضي Test.com يعمل بشكل صحيح</h1> </body> </html>احفظ الملف ثم أغلقه. لدينا الآن الصفحات الضرورية لاختبار إعداد المستضيف الافتراضي. الخطوة الرابعة - أنشئ ملفات مستضيفات افتراضية جديدةتُحدِّد ملفات المستضيفات الافتراضية إعدادات هذه المستضيفات كما أنها تُملي على خادوم ويب Apache الكيفية التي سيُجيب بها على طلبات النطاقات المختلفة. يأتي خادوم Apache بملف ابتدائي اسمه 000-default.conf لإعداد المستضيفات الافتراضية. يُمكننا استخدام هذا الملف للبدء، لذا سننسخ هذا الملف لإعداد المستضيفات الافتراضية الخاصة بنطاقاتنا. سنبدأ بإعداد أحد النطاقات ثم ننسخه إلى النطاق الثاني مع القيام بالتعديلات اللازمة. يجب - في الإعداد المبدئي لأوبنتو - أن ينتهي ملف المستضيف الافتراضي بالامتداد conf. أنشئ ملف المستضيف الافتراضي الأول. ابدأ بنسخ ملف النطاق الأول: sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.confافتَح الملف الجديد في المحرِّر بامتيازات المستخدِم الجذر : sudo nano /etc/apache2/sites-available/example.com.confسيبدو الملف بالشكل التّالي (حُذِفت التعليقات لجعل الملف أسهل للقراءة): <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>احفظ الملف ثم أغلقه بعد الانتهاء من تحريره. الخطوة الخامسة - فعل ملفات المستضيفات الافتراضية الجديدةبعد إنشاء ملفات إعداد المستضيفات الافتراضية نأتي لخطوة التفعيل؛ يوفِّر خادوم Apache بعض الأدوات لهذا الغرض. لتفعيل الموقعيْن نستخدم أداة a2ensite كما يلي: sudo a2ensite example.com.conf sudo a2ensite test.com.confثم نعيد تشغيل Apache لأخذ التغييرات بالاعتبار: sudo service apache2 restartأثناء إعادة تشغيل خادوم الوب قد تظهر رسالة كالتالية: * Restarting web server apache2 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this messageلا يُمثِّل هذا التحذير أي خطر وليس له تأثير على موقعك. الخطوة السادسة - اضبط ملف المستضيفات المحلي (خطوة اختيارية)إن لم تتوفّر لديك أسماء نطاقات حقيقية لتجربة الخطوات المذكورة في هذا الدّرس يُمكنك اختيار نطاقات وهمية والتجربة بها على جهاز ك المحلي (الشخصي) عن طريق التعديل المؤقَّت على ملف المستضيفات المحلي. ستُوَجَّه كل طلبات النطاقات المضبوطة بهذه الطريقة إلى خادومك الافتراضي الخاص، تماما كما كان سيفعل نظام أسماء النِّطاقات Domain Name System, DNS لو استخدمتَ أسماء نطاقات مُسَجَّلة. ينبغي الانتباه أن هذه الطريقة ستعمل من جهازك الشخصي فقط وتقتصر على اختبار الإعدادات. تأكَّد من القيام بالخطوات التالية على جهازك المحلي وليس على خادومك الافتﻻاضي الخاص. ستحتاج لمعرفة كلمة سر اسم المستخدِم الجذر أو أن تكون ضمن مجموعة المديرين على نظام التشغيل. الأمر التالي يفتح ملف المستضيفات للتحرير على أنظمة Linux و Mac: sudo nano /etc/hostsبالنسبة لمستخدمي Windows توجد تعليمات التعديل على ملف المستضيفات هنا. ستحتاج لعنوان IP العمومي لخادومك الافتراضي الخاص والنطاق الذي تُريد استخدامه للوصول إلى الخادوم الافتراضي. يتكوَّن سطر ملف الإعداد من عنوان IP متبوعًا باسم النطاق. باعتبار أن 111.111.111.111 هو عنوان IP الخادوم نُضيف الأسطر التالية في أسفل ملف المستضيفات: 127.0.0.1 localhost 127.0.1.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.comبهذه الطّريقة ستُوجَّه كل استعلامات الجهاز المحلي التي تطلُب النِّطاقين example.com أو test.com إلى الخادوم على العنوان 111.111.111.111، وهو ما يُساعدنا على اختبار إعدادات خادوم الوب إن لم نكن مالِكي النطاقيْن المذكوريْن. احفَظ الملف ثم أغلِقه. الخطوة السابعة - اختبر النتائجيُمكنك بعد الانتهاء من ضبط المُستضيفات الافتراضية اختبار الإعدادت بالذهاب إلى النطاقات المضبوطة عبر متصفِّح الوب: http://example.comيجب أن تكون النتيجة كما في الصّورة: الشيء بالنسبة للموقع الآخر: http://test.comستظهر الصّفحة التي أنشأتَها في الملف الثاني: يدل ظهور الصفحتين بشكل صحيح أن إعداد مستضيفيْن افتراضيّيْن على نفس الخادوم جرى بطريقة جيّدة. لا تنسَ حذف الأسطر الإضافية من ملف المستضيفات المحلي بعد التأكد من إعداد المستضيفات الافتراضية على الخادوم. أُضيفت هذه الأسطُر للاختبار فقط ومن الأحسن حذفها بعد انتهائه. ستحتاج إلى شراء وإعداد نطاقات إن احتجتَ دائما إلى خادومك عن طريق أسماء نطاقات. خاتمةستحصُل بعد متابعة هذا الدّرس على خادوم ويب واحد يتعامل مع نطاقيْن منفصلين. يُمكنك زيادة عدد النطاقات باتّباع الخطوات المذكورة أعلاه لإنشاء مستضيفات افتراضية جديدة. لا توجد تقييد على عدد النطاقات التي يُمكِن لـApache التعامل معها، أضِف ما تُريد من النطاقات ما دام الخادوم يستطيع تحمّلَها. ترجمة -وبتصرّف- للمقال How To Set Up Apache Virtual Hosts on Ubuntu 14.04 LTS لصاحبه Justin Ellingwood.