المحتوى عن 'ترقية'.



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

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

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

نوع المُحتوى


التصنيفات

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

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • ASP.NET
    • ASP.NET Core
  • سير العمل
    • 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. Nginx خادم ويب قوي ووكيل عكسي (reverse proxy) يُستخدم لتقديم العديد من المواقع الأكثر شهرةً في العالم. سنوضّح في هذا الدليل كيفية ترقية Nginx الموجود القابل للتنفيذ، بدون قطع اتصالات العميل. المتطلبات الأساسية قبل البدء في هذا الدليل، يجب أن يكون لديك مستخدم غير جذر على خادمك، تمَّ إعداده مع صلاحيات sudo. ستحتاج أيضًا أن يكون لديك خادم Nginx مثبَّتًا. إذا كنت تستخدم أبنتو 14.04، يمكنك تعلّم كيفية ضبط مستخدم بصلاحيات sudo هنا. يمكنك تثبيت Nginx باتّباع هذا الدليل. إذا كنت تستخدم CentOS 7، يمكنك الحصول على ضبط المستخدم بصلاحيات sudo عبر هذا الدليل، متّبعًا هذا الدليل لتثبّت Nginx. كيف تعمل الترقية يعمل Nginx على إنشاء إجراء سيّد أو رئيسي (master process) عندما تبدأ الخدمة. ويشغّل الإجراء السيّد بدوره إجراء تابع (worker process) أو أكثر تتعامل مع اتصالات العميل الفعلية. تم تصميم Nginx لأداء إجراءات معينة عندما يتلقّى إشارات محددة من المدير. يمنحك الفرصة باستخدام هذه الإشارات لتقوم بترقيته أو ترقية إعداداته الموجودة بسهولة، بدون قطع اتصالات العميل. هناك سكربتات (scripts) معينة للخدمة مزوّدة من قِبل القائمين على صيانة حزمة التوزيع ستوفر القدرة على الاستخدام مع الترقيات التقليدية. لكن توفر الترقية يدويًا المزيد من المرونة في المنهجية وتسمح لك بمراجعة الترقية للتراجع بسرعة إذا كان هناك مشاكل. هذا أيضًا سيوفر خيارًا للترقية بأمان إذا قمت بتثبيت Nginx من المصدر أو باستخدام طريقة لا توفر هذه الإمكانية. ستُستخدم الإشارات التالية: USR2: تولّد هذه مجموعة جديدة من إجراءات السيد/التابع بدون التأثير على المجموعة القديمة. WINCH: تخبر هذه الإجراء السيد لـNginx أن يوقف أغراض التابع المرتبطة بأمان. HUP: تخبر هذه الإجراء السيد لـNginx أن يعيد قراءة ملفات إعداداته ويستبدل إجراءات التابع بتلك المرتبطة بالإعدادات الجديدة. إذا كان هناك سيد قديم وجديد قيد التشغيل، فإنَّ إرسال هذا إلى السيد القديم سيولّد توابعًا باستخدام إعداداتهم الأصليّة. QUIT: توقف هذه تشغيل السيّد وتوابعه بأمان. TERM: تهيئ هذه إيقاف تشغيل سريع للسيّد وتوابعه. KILL: توقف هذه السيّد وتوابعه بدون أيّ تنظيف. إيجاد معرّفات إجراء Nginx لإرسال إشارات إلى الإجراءات المختلفة، نحتاج إلى معرفة معرّف الإجراء (PID) المستهدف. هناك طريقتان سهلتان لإيجاد هذا. أولًا، يمكنك استخدام الأداة ps وثمّ grep لـNginx بين النتائج. هذا بسيط ويسمح لك برؤية إجراءات السيّد والتابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process user 10961 0.0 0.0 112640 964 pts/0 S+ 13:53 0:00 grep --color=auto nginx يحتوي العمود الثاني على معرّفات الإجراءات المُختارة. المميز هو معرّف الإجراء. يوضّح العمود الأخير أنَّ النتيجة الأولى هي الإجراء السيّد لـNginx. طريقة أخرى لإيجاد معرّف الإجراء السيّد لـNginx وهي طباعة محتويات ملف ‎/run/nginx.pid: $ cat /run/nginx.pid output 10846 إذا كان هناك إجراءين سيّد لـNginx قيد التشغيل، سينتقل الإجراء القديم إلى run/nginx.pid.oldbin/. توليد مجموعة سيّد/توابع جديدة الخطوة الأولى لتحديث ملفنا القابل للتنفيذ بأمان هي في الواقع تحديث ملفك الثنائي.قم بذلك باستخدام أيّ طريقة مناسبة لتثبيت Nginx لديك، سواء من خلال مدير الحزمة أو التثبيت المصدري. بعد وضع الملف الثنائي الجديد في مكانه، يمكنك توليد مجموعة ثانية من إجراءات السيّد/التابع التي تستخدم الملف الجديد القابل للتنفيذ. يمكنك القيام بذلك إمّا بإرسال إشارة USR2 مباشرةً إلى رقم المعرّف الذي استعلمت عنه (تأكّد هنا من استبدال معرّف الإجراء السيّد بمعرّف الإجراء السيّد الخاص بخادمك Nginx): $ sudo kill -s USR2 10846 او يمكنك قراءة واستبدال القيمة المخزّنة في ملف PID مباشرةً باستخدام أمر كهذا: $ sudo kill -s USR2 `cat /run/nginx.pid` إذا تفحّصت إجراءاتك الحاليّة، ستشاهد أنّ لديك الآن مجموعتان من إجراءات السيّد/التوابع لـNginx: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process user 11031 0.0 0.0 112640 960 pts/0 S+ 14:01 0:00 grep --color=auto nginx يمكنك أيضًا أن تشاهد أنَّ ملف run/nginx.pid/ الأصلي قد انتقل إلى run/nginx.pid.oldbin/ ومعرّف الإجراء السيّد الجديد كُتبَ في الملف run/nginx.pid/: $ tail -n +1 /run/nginx.pid* output ==> /run/nginx.pid <== 11003 ==> /run/nginx.pid.oldbin <== 10846 يمكنك الآن إرسال إشارات إلى أيّ من الإجراءين السيّدين مستخدمًا المعرّفات الموجودة في هذه الملفات. عند هذه النقطة، فإن مجموعتي السيّد/التابع شغّالتين وقادرتين على تلبية طلبات العميل. تستخدم المجموعة الأولى الملف الأصلي القابل للتنفيذ والإعدادات الأصلية لـNginx وتستخدم المجموعة الثانية الإصدارات الأحدث. يمكنهم الاستمرار في العمل جنبًا إلى جنب، لكن يجب أن نبدأ في الانتقال إلى المجموعة جديدة من أجل الاتساق. إيقاف تشغيل توابع السيّد الأول للبدء بالانتقال إلى المجموعة الجديدة، فإنَّ أول شيء يمكننا القيام به هو إيقاف الإجراءات توابع السيّد الأصلي. سينهي التوابع الأصليين معالجة كل اتصالاتهم الحالية ثمَّ يخرجون. أوقف توابع المجموعة الأصلية بإصدار إشارة WINCH إلى إجرائهم السيّد: $ sudo kill -s WINCH `cat /run/nginx.pid.oldbin` سيتيح ذلك لتوابع السيّد الجديد أن يتعاملوا مع اتصالات العميل الجديدة بمفردهم. سيظلّ الإجراء السيّد القديم قيد التشغيل، لكن بدون توابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process user 11089 0.0 0.0 112640 964 pts/0 R+ 14:13 0:00 grep --color=auto nginx يتيح هذا لك مراجعة التوابع الجدد لأنّهم يقبلون الاتصالات بشكلٍ منفصل مع الحفاظ على قابلية العودة إلى الملف القديم القابل للتنفيذ إذا كان هناك خطأٌ ما. تقييم النتيجة واتخاذ الخطوات التالية عند هذه النقطة يجب اختبار النظام ومراجعته للتأكّد من عدم وجود بوادر مشاكل. يمكنك ترك الإعدادات في هذه الحالة طالما ترغب بالتأكّد من أنّ الملف الجديد القابل للتنفيذ لـNginx خالٍ من الأخطاء وقادر على التعامل مع حركة المرور الخاصة بك. ستعتمد خطوتك التالية تمامًا على ما إذا كنت تواجه مشاكل. إذا كانت الترقية ناجحة، أكمل الانتقال إذا لم تواجه أيّ مشاكل مع توابع مجموعتك الجديدة، يمكنك إيقاف تشغيل الإجراء السيّد القديم بأمان. للقيام بذلك، فقط أرسل الإشارة QUIT إلى السيّد القديم: sudo kill -s QUIT `cat /run/nginx.pid.oldbin` سيُغلَق الإجراء السيّد القديم بأمان، تاركًا فقط مجموعتك الجديدة من السيّد/التوابع لـNginx. عند هذه النقطة، تكون قد حدّثت الملف الثنائي الموجود لـNginx بأمان بدون مقاطعة اتصالات العميل. إذا واجهت مشاكل في التوابع الجديدة، عُد إلى الملف الثنائي القديم إذا لاحظت وجود مشاكل في مجموعة التوابع الجديدة، يمكنك العودة إلى الملف الثنائي والإعدادات القديمة. وهذا ممكن خلال الجلسة نفسها. أفضل طريقة للقيام بذلك هي إعادة تشغيل توابع السيّد القديم بإرسال إشارة HUP له. عادةً، عندما ترسل إشارة HUP للسيّد في Nginx، يعيد قراءة ملفات إعداداته ويشغّل توابعًا جديدة. لكن عندما يكون الهدف سيّد أقدم، فقط يولّد توابعًا جديدة باستخدام إعدادات العمل الأصلية: $ sudo kill -s HUP `cat /run/nginx.pid.oldbin` يجب أن تعود الآن ليكون لديك مجموعتين من إجراءات السيّد/التابع: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process user 19920 0.0 0.0 112640 964 pts/0 R+ 14:48 0:00 grep --color=auto nginx ترتبط التوابع الجديدة بالتابع القديم. عند هذه النقطة فإنَّ توابع المجموعتين سيقبلون اتصالات العميل. أوقف الآن الإجراء السيّد الجديد الذي يحوي أخطاء وتوابعه بإرسال إشارة QUIT: $ sudo kill -s QUIT `cat /run/nginx.pid` يجب أن تعود للسيّد والتوابع القديمين: $ ps aux | grep nginx output root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process user 19935 0.0 0.0 112640 964 pts/0 R+ 14:50 0:00 grep --color=auto nginx سيستعيد السيّد الأصلي ملف run/nginx.pid/ لمعرّفه. إذا لم يعمل ما سبق لأي سبب من الأسباب، يمكنك أن تحاول فقط إرسال إشارة TERM للسيّد الجديد للخادم، وهذا يجب أن تتهيأ عملية إيقاف التشغيل. ويجب أن يوقف هذا السيّد الجديد وأي تابع من توابعه أثناء البحث التلقائي عن السيّد القديم لبدء إجراءات التابع الخاص به. إذا كان هناك مشاكل خطيرة والتوابع بهم أخطاء ولم يتم إنهاؤهم، يمكنك إرسال إشارة KILL لكلٍّ منهم للتنظيف. يجب أن يكون هذا كحل أخير لأنّه سيؤدي إلى قطع الاتصالات. بعد الانتقال مرة أخرى إلى الملف الثنائي القديم، تذكّر أنّه لا يزال لديك الإصدار الجديد مثبّتًا على نظامك. يجب أن تزيل الإصدار الذي يحوي مشاكل وتعود لإصدارك السابق حتى يعمل Nginx بدون أيّة مشاكل عند إعادة التشغيل. خاتمة يجب أن تكون الآن قادرًا على نقل أجهزتك بسلاسة من ملف ثنائي لـNginx إلى آخر. إنَّ قدرة Nginx على التعامل مع مجموعتي سيّد/توابع مع المحافظة على معلومات علاقاتهم تتيح لنا القدرة على ترقية برنامج الخادم بدون أن يصبح جهاز الخادم في وضع عدم الاتصال. ترجمة -وبتصرف- للمقال How To Upgrade Nginx In-Place Without Dropping Client Connections لصاحبه Justin Ellingwood
  2. تَعِد PHP 7، التي صدرت في 3 ديسمبر 2015، بتحسينات كبيرة في سرعتها على النُسخ السابقة من اللغة، مع مميزات جديدة مثل تلميح النوع العددي (scalar type hinting). سنشرح كيفية ترقية خادوم Apache أو Nginx يستخدم PHP 5.x (أي إصدار) إلى PHP 7. تحذير: كما هو الحال مع معظم النسخ الرئيسية لإصدارات اللغة، من الأفضل الانتظار لبعض الوقت قبل الانتقال إلى PHP 7 في بيئة الإنتاج. في غضون ذلك، يكون الوقت مناسب لاختبار توافقية تطبيقاتك مع الإصدار الجديد، إجراء مقاييس الأداء والتّعرف على الميزات الجديدة للغة. إذا كُنت تُشغل أي خدمات أو تطبيقات بمستخدمين نُشطاء، فالآمن اختبار PHP 7 في بيئة إدراج staging environment قبل تثبيتها في بيئة الإنتاج. ملحوظة: بيئة الإدراج (staging environment) هي بيئة تطوير تقع بين بيئة الاختبار وبيئة الإنتاج، تُستخدم في تجميع، اختبار واستعراض الإصدارات الجديدة من البرمجيات قبل نقلها إلى بيئة الإنتاج. المتطلبات الأساسية يُفتَرض أنك تستخدم PHP 5.x على أوبنتو 14.04، باستخدام إما mod_php بالتزامن مع Apache، أو PHP-FPM بالتزامن مع Nginx. ويُفتَرض أن لديك مُستخدم عادي غير المستخدم الجذر بصلاحيات sudo للمهام الإدارية. إضافة PPA لحزم PHP 7.0 أرشيف الحزم الشخصي، أو PPA، هو مُستودع Apt مُستضاف على Launchpad. وهذه الأرشيفات الشخصية تسمح لمطوري الطرف الثالث ببناء وتوزيع الحزم لأوبنتو خارج قنوات تطوير الحزم الرسمية. وهي مصادر مفيدة غالبًا من البرمجيات التجريبية، البنّى المُعدلة والمنقولات الخلفية backports لإصدارات النظام القديمة. ملحوظة: الحزم المنقولة خلفًا (package backports) هي حزم لبرمجيات حديثة أعيدت ترجمتها لتوزيعة قديمة (نُقلت إلى الخلف)، وعادة ما يكون النقل إلى التوزيعة المستقرة. يقوم Ondřej Surý على صيانة حزم PHP لدبيان، ويوفر أرشيف شخصي للنسخة PHP 7.0 على أوبنتو. قبل القيام بأي شيء، سجل دخولك إلى النظام، وأضف أرشيف Ondřej الشخصي إلى قائمة مصادر Apt بالنظام: $ sudo add-apt-repository ppa:ondrej/php-7.0 ستلاحظ وصف الأرشيف الشخصي، متبوعًا بمحث للاستمرار. اضغط Enter للمواصلة. ملحوظة: إذا كانت محليات نظامك مضبوطة لأي شيء غير UTF-8، فقد تفشل عملية إضافة الأرشيف الشخصي لوجود مشكلة برمجية في التعامل مع الحروف في اسم المؤلف. وكالتفاف حول المشكلة يمكنك تثبيت الحزمة language-pack-en-base لتتأكد من توليد المحليات المطلوبة، وتتجاوز إعدادات محليات النظام عند إضافة الأرشيف الشخصي: $ sudo apt-get install -y language-pack-en-base $ sudo LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php-7.0 بمجرد انتهاء تثبيت الأرشيف الشخصي، حدّث ذاكرة الحزم المُخبأة لكي يتم تضمين محتويات الأرشيف: $ sudo apt-get update الآن أصبح لدينا وصول لحزم PHP 7.0، ويمكننا استبدال نسخة PHP الحالية. ترقية mod_php مع Apache هذا القسم يوضح عملية ترقية نظام يستخدم Apache كخادوم و mod_php لتنفيذ شفرة PHP. إذا كُنت تستخدم Nginx و PHP-FPM انتقل للقسم التالي. تثبت الحزم الجديدة سوف يُرقي كل حزم PHP الهامة، باستثناء php5-mysql، التي سيتم حذفها. $ sudo apt-get install php7.0 ملحوظة: إذا قُمت بتعديلات هامة على أي ملف من ملفات الضبط في/etc/php5/، فهذه الملفات ستظل في مكانها، ويمكن الرجوع إليها. ملفات ضبط PHP 7.0 تجدها الآن في etc/php/7.0/. إذا كُنت تستخدم MySQL، تأكد من إعادة تثبيت جسر PHP MySQL المُحدّثة: $ sudo apt-get install php7.0-mysql ترقية PHP-FPM مع Nginx هذا القسم يوضح عملية ترقية نظام يستخدم Nginx كخادوم و PHP-FPM لتنفيذ شفرة PHP. تثبيت حزم PHP-FPM الجديدة واعتمادياتها: $ sudo apt-get install php7.0-fpm سيطلب منك الاستمرار، اضغط Enter لإكمال التثبيت. إذا كُنت تستخدم MySQL، تأكد من إعادة تثبيت جسر PHP MySQL المُحدّثة: $ sudo apt-get install php7.0-mysql ملحوظة: إذا قُمت بتعديلات هامة على أي ملف من ملفات الضبط في/etc/php5/، فهذه الملفات ستظل في مكانها، ويمكن الرجوع إليها. ملفات ضبط PHP 7.0 تجدها الآن في etc/php/7.0/. ترقية مواقع Nginx لتستخدم مسار المقبس الجديد يتواصل Nginx مع PHP-FPM باستخدام مقبس نطاق يونكس. ترسم المقابس خريطة لمسار على نظام الملفات، تستخدم PHP 7 مسار افتراضيًا جديدًا : PHP 5: /var/run/php5-fpm.sock PHP 7: /var/run.php7.0-fpm.sock افتح ملف ضبط الموقع الافتراضي بالمحرر nano (أو أي مُحرر من اختيارك): sudo nano /etc/nginx/sites-enabled/default قد يختلف ضبطك قليلا. ابحث عن كتلة تبدأ بـ }$location ~ \.php وسطر يبدو مثل ;fastcgi_pass unix:/var/run/php5-fpm.sock غيّر هذا ليستخدم unix:/var/run/php/php7.0-fpm.sock. مثال لملف etc/nginx/sites-enabled/default/ server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/html; index index.php index.html index.htm; server_name server_domain_name_or_IP; location / { try_files $uri $uri/ =404; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } اخرج واحفظ الملف. يمكنك القيام بهذا في nano بالضغط على Ctrl-x للخروج، y للتأكيد و Enter للتأكيد على اسم الملف الذي سيتم الكتابة فوقه. ينبغي تكرار هذه الخطوة لأي مواقع مُعرّفة في المُجلّد etc/nginx/sites-enabled/ والتي تحتاج أن تدعم PHP. الآن يمكننا إعادة تشغيل nginx: $ sudo service nginx restart اختبار PHP بعد ضبط الخادوم وتثبيت الحزم الجديدة، يمكننا التحقق من أن PHP تعمل. ابدأ بالتحقق من نسخة PHP المُثبتة بالأمر: $ php -v المخرجات PHP 7.0.0-5+deb.sury.org~trusty+1 (cli) ( NTS ) Copyright (c) 1997-2015 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies يمكننا كذلك إنشاء ملف اختبار في مُجلد جذر وثائق الخادوم (document root). مسار هذا المُجلد يعتمد على خادومك وضبطك، قد يكون واحدًا من: var/www/html/ /var/www/ usr/share/nginx/html/ افتح ملفًا جديدًا باستخدام nano يسمى info.php في جذر الوثائق. يكون على Apache، افتراضيًا بالمسار الأول: $ sudo nano /var/www/html/info.php على Nginx، قد تستخدم: $ sudo nano /usr/share/nginx/html/info.php وألصق الشيفرة التالية بالملف: <?php phpinfo(); ?> أغلق المُحرر، واحفظ info.php. الآن، حمل العنوان التالي في متصفحك: http://server_domain_name_or_IP/info.php استبدل server_domain_name_or_IP باسم نطاق أو عنوان ip الخادوم. ينبغي أن ترى رقم نُسخة PHP ومعلومات ضبط PHP 7. بمجرد أن تُراجع هذه المعلومات، فمن الأفضل (لزيادة أمان خادومك) حذف الملف info.php: $ sudo rm /var/www/html/info.php خاتمة الآن لديك PHP 7، مُثبت ويعمل. قد ترغب في إلقاء نظرة على دليل الهجرة الرسمي إلى PHP 7. ترجمة -وبتصرّف- للمقال How To Upgrade to PHP 7 on Ubuntu 14.04 لصاحبه Brennen Bearnes.