السحابة والاستضافة — انشر موقعك على سيرفر حقيقي

1. لماذا السحابة؟ — من جهازك إلى الإنترنت

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

حين تفتح ملف index.html على حاسوبك يظهر الموقع أمامك وحدك، لأن المتصفح يقرأ الملف من قرصك مباشرة دون أن يمر بالشبكة. لكي يصبح الموقع «حياً» يجب أن تعيش ملفاته على خادم (Server) متصل بالإنترنت طوال الوقت، له عنوان رقمي (IP Address)، ويعمل عليه برنامج اسمه خادم الويب (Web Server) ينتظر الطلبات ويرد عليها. هذا كل ما تعنيه كلمة الاستضافة (Hosting): أن تستأجر مكاناً لملفاتك وبرامجك على جهاز لا ينطفئ.

رحلة طلب واحد في خمس محطات:
1) يكتب الزائر example.com، فيسأل المتصفح نظام أسماء النطاقات (DNS) عن عنوان IP المقابل لهذا الاسم.
2) يفتح المتصفح اتصالاً بذلك العنوان على المنفذ 443 للاتصال المشفّر HTTPS، أو على المنفذ 80 لاتصال HTTP العادي.
3) يستقبل خادم الويب، مثل OpenLiteSpeed أو Nginx أو Apache، الطلب ويقرأ المسار المطلوب.
4) يعيد ملفاً جاهزاً، أو يمرر الطلب إلى لغة مثل PHP لتبني الصفحة من قاعدة البيانات ثم يعيد الناتج.
5) يكرر المتصفح الرحلة نفسها لكل ملف CSS وصورة وخط تحتاجه الصفحة.

قيمة هذه الخريطة عملية: كل عطل ستقابله في هذا المسار يقع في محطة واحدة منها. رسالة «لا يمكن العثور على الخادم» مشكلة في المحطة الأولى، وانتهاء المهلة غالباً في الثانية، وصفحة خطأ 500 في الرابعة. حين تعرف المحطة يضيق البحث كثيراً.

خذ حالة منى التي تدير مخبزاً صغيراً في المنصورة، وتريد موقعاً يعرض القائمة وساعات العمل ونموذجاً لطلبات التورتات. أمامها أربعة أنواع من الاستضافة. الاستضافة الثابتة (Static Hosting) تخدم ملفات HTML وCSS وJavaScript فقط بلا كود يعمل على الخادم، وتقدمها منصات مستودعات الكود وشبكات توزيع المحتوى غالباً مجاناً أو بتكلفة منخفضة. الاستضافة المشتركة (Shared Hosting) حساب على خادم يتقاسمه عشرات أو مئات المواقع، مع لوحة جاهزة وPHP وقاعدة بيانات، والمزود يتولى نظام التشغيل؛ لكن موارد الجيران تؤثر عليك ولا تستطيع تثبيت برامج خاصة. الخادم الافتراضي الخاص (VPS) آلة افتراضية معزولة بموارد محجوزة وصلاحية root كاملة، تثبت عليها ما تشاء، وتتحمل وحدك التحديث والأمان والنسخ. وأخيراً السحابة المرنة (Cloud) لدى مزودي البنية الكبيرة: آلات وقواعد بيانات وتخزين تُنشأ وتُحذف في دقائق وتُفوتر حسب الاستخدام، وهي قوية لمشروع سريع النمو لكنها تتطلب فهماً للفوترة والصلاحيات.

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

الصلاحية الكاملة على VPS تعني أن أحداً لن يحدّث النظام أو يراقب محاولات الاختراق نيابة عنك. لهذا سنستخدم لوحة تحكم (CyberPanel) تختصر الأعمال المتكررة، مع فهم ما يجري تحتها بالأوامر، حتى لا تقف عاجزاً حين تتعطل اللوحة نفسها.

وعند المقارنة بين الخطط لا تنظر إلى السعر الشهري وحده. التكلفة الفعلية تتكون من الخادم، وتجديد النطاق سنوياً، وخدمة النسخ أو اللقطات إن كانت مدفوعة منفصلة، وعنوان IPv4 الذي يحتسبه بعض المزودين بنداً مستقلاً، وحركة البيانات الخارجة إن تجاوزت الحصة، ثم وقتك أنت في الصيانة. وفي أي سحابة تُفوتر بالاستخدام فعّل تنبيه الميزانية (Billing Alert) من اليوم الأول، واحذف كل خادم تجريبي انتهيت منه؛ فالخادم المتوقف قد يستمر في احتساب القرص وعنوان IP.

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

للاستزادة: MDN: ما هو خادم الويب؟ · MDN: كيف يعمل الإنترنت؟ · MDN: نظرة عامة على HTTP

2. النطاق و DNS — العنوان الذي يجدك العالم

الهدف: تقرأ وتكتب سجلات A وAAAA وCNAME وMX وTXT، وتفهم خوادم الأسماء وTTL، وتشخّص عطل ربط النطاق بالأمر dig.

النطاق (Domain Name) اسم يتذكره البشر، أما الأجهزة فتتواصل بعناوين رقمية. نظام أسماء النطاقات (DNS) قاعدة بيانات موزعة على آلاف الخوادم حول العالم، تترجم الاسم إلى عنوان، وتحمل معلومات أخرى مثل خادم البريد. حين تشتري نطاقاً من مسجّل (Registrar) معتمد لدى منظمة ICANN فأنت تستأجر الاسم لمدة تجددها، وتحدد له خوادم الأسماء (Nameservers)، وهي الخوادم التي تحمل سجلاته وتجيب عن الأسئلة عنه.

هذه سجلات نطاق تجريبي كما تظهر في أي لوحة DNS. العناوين مأخوذة من نطاقات خصصتها المعايير للتوثيق، فلا تحاول الاتصال بها:

@      A      203.0.113.10
@      AAAA   2001:db8::10
www    CNAME  example.com.
@      MX 10  mail.example.com.
mail   A      203.0.113.20
@      TXT    "v=spf1 mx -all"

اقرأ السجلات سطراً سطراً:
• الرمز @ يعني النطاق نفسه example.com بلا بادئة. سجل A يربطه بعنوان IPv4، وسجل AAAA يربطه بعنوان IPv6، وكثير من الخوادم اليوم لها الاثنان.
• سجل CNAME يجعل www اسماً مستعاراً للنطاق، فإذا تغير عنوان الخادم عدّلت سجل A وحده وتبعه www تلقائياً.
• سجل MX يحدد خادم البريد، والرقم 10 أولوية: إن وُجد أكثر من سجل يُجرَّب الرقم الأصغر أولاً. قيمة MX اسم مضيف وليست عنوان IP، ولهذا أضفنا لـ mail سجل A مستقلاً.
• سجل TXT نص حر يُستخدم لإثبات ملكية النطاق أمام خدمات خارجية، ولسياسات البريد. السطر هنا سياسة SPF تقول إن الخوادم المذكورة في MX وحدها مسموح لها بإرسال بريد باسم النطاق. وسياسة DMARC توضع في سجل TXT على الاسم _dmarc.

قاعدة يتعثر بها المبتدئون: لا يجوز وضع CNAME على @. السبب أن CNAME لا يتعايش مع أي سجل آخر على الاسم نفسه، والنطاق الجذر يحمل دائماً سجلي SOA وNS. لذلك يكون @ سجل A أو AAAA، ويكون www سجل A أو CNAME. بعض مزودي DNS يقدمون حلاً خاصاً مثل «تسطيح CNAME» (CNAME Flattening)، وهو ميزة لدى المزود وليس جزءاً من المعيار.

كل سجل يحمل قيمة TTL بالثواني، وهي المدة التي يُسمح فيها للخوادم الوسيطة ولجهازك بحفظ الإجابة. سجل TTL له 3600 قد يرى بعض الزوار قيمته القديمة حتى ساعة بعد تعديله. قبل نقل موقع إلى خادم جديد خفّض TTL إلى بضع دقائق قبل يوم من النقل، ثم أعده إلى قيمته بعد الاستقرار.

سجل استكشاف عطل حقيقي الشكل: اشترت سارة نطاقاً لمتجر إكسسوارات، وأضافت سجل A، وبعد ساعتين ما زال المتصفح يعرض DNS_PROBE_FINISHED_NXDOMAIN، أي أن الاسم غير موجود في DNS. هذه الأوامر التي شخّصت بها المشكلة على Ubuntu:

dig +short NS example.com
dig +short example.com A
dig @1.1.1.1 +short example.com A

أعاد الأمر الأول خوادم أسماء تابعة لـ Cloudflare، لأنها نقلت النطاق إليها قبل أسبوع ونسيت. أما السجل فقد أضافته في لوحة المسجّل القديمة، وهي لوحة لم يعد أحد يسألها. أضافت السجل في Cloudflare، فأعاد الأمر الثالث العنوان الصحيح خلال دقيقة لأنه يسأل خادماً عاماً محدداً مباشرة، بينما بقي حاسوبها على Windows يعرض الخطأ حتى نفذت ipconfig /flushdns لمسح الذاكرة المؤقتة المحلية.

الدرس من سجل سارة قاعدة واحدة: السجلات تُقرأ من حيث تشير خوادم الأسماء، فابدأ دائماً بسؤال NS قبل أي تعديل. وإن لم يكن dig موجوداً فهو في حزمة dnsutils على Ubuntu، وعلى Windows يؤدي nslookup المهمة نفسها بصيغة أبسط.

سجلان آخران يسببان أعطالاً محيّرة إن نُسيا. الأول سجل AAAA قديم يشير إلى خادم سابق: الزوار الذين يملكون IPv6 يذهبون إليه بينما يذهب الباقون إلى الخادم الجديد، فيبدو العطل عشوائياً، فاسأل دائماً عن A وAAAA معاً. والثاني سجل CAA الاختياري، وهو يحدد جهات الإصدار المسموح لها بإصدار شهادات لنطاقك؛ إن أضفته يسمح بجهة واحدة ثم طلبت شهادة من جهة أخرى فسيُرفض الطلب.

• A وAAAA يربطان الاسم بعنوان IPv4 وIPv6، وCNAME يجعل الاسم مستعاراً لاسم آخر.
• قيمة MX اسم مضيف وليست IP، والرقم الأصغر أولوية أعلى.
• لا يوضع CNAME على النطاق الجذر @ لأنه يحمل SOA وNS دائماً.
• ابدأ التشخيص بالأمر dig NS لتعرف أين تُدار السجلات فعلاً.
• خفّض TTL قبل نقل الموقع بيوم لتقصير مدة ظهور العنوان القديم.

 example.com
     |
 [Nameservers] ← dig NS
     |
  A    → 203.0.113.10
  AAAA → 2001:db8::10
  www  → CNAME example.com.
  MX   → mail.example.com.

للاستزادة: Cloudflare Learning: ما سجلات DNS؟ · Cloudflare Docs: أنواع سجلات DNS · RFC 5737: عناوين IPv4 المخصصة للتوثيق · RFC 8659: سجل CAA · ICANN: دليل المبتدئين

3. اختيار VPS — مواصفات، منطقة، وتكلفة

الهدف: تختار مواصفات VPS ونظام تشغيله ومنطقته بناءً على ما ستشغّله فعلاً، وتعرف متى تكبّر الخطة.

صفحات خطط الخوادم الافتراضية متشابهة: أربعة أرقام وسعر. لكن الاختيار الصحيح يبدأ من سؤال آخر: ما البرامج التي ستعمل على هذا الخادم في وقت واحد؟ لوحة تحكم، وخادم ويب، وقاعدة بيانات، وربما خدمة بريد؛ ولكل منها نصيب من الذاكرة لا تتنازل عنه.

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

مقارنة تخيّلية لكنها شائعة: كريم وليلى طالبان في عمّان بدأ كل منهما مشروعاً على CyberPanel. اختار كريم أصغر خطة بذاكرة 1 GB لأنها توافق الحد الأدنى المكتوب في متطلبات CyberPanel، ثم ثبّت معها كامل الخدمات بما فيها البريد، وأضاف موقع WordPress. بعد أسبوع صار الموقع يتوقف عصراً عند ذروة الزيارات، وكشف الأمر free -h أن الذاكرة المتاحة شبه منعدمة. اختارت ليلى خطة بذاكرة 2 GB للمشروع نفسه، ولم تواجه المشكلة. الحد الأدنى في صفحة المتطلبات هو ما يلزم لإكمال التثبيت، وليس ما يكفي لتشغيل موقع حقيقي مع قاعدة بيانات تحت ضغط.

قائمة الاختيار قبل الضغط على زر الإنشاء:
1) النظام: إصدار Ubuntu LTS (دعم طويل الأمد) تدعمه لوحتك صراحة. إصدارات LTS تحصل على خمس سنوات من التحديثات الأمنية القياسية، وتجد لها حلولاً منشورة لأغلب المشكلات. راجع قائمة الأنظمة المدعومة في توثيق CyberPanel قبل اختيار الإصدار، لأن دعم الإصدارات الأحدث قد يتأخر عن صدورها.
2) المنطقة: مركز بيانات قريب من جمهورك. كل طلب يقطع المسافة ذهاباً وإياباً، والصفحة الواحدة تحتاج عشرات الطلبات.
3) مفتاح SSH: أضف مفتاحك العام في شاشة الإنشاء إن أتاحها المزود، فتدخل من أول مرة دون كلمة مرور قابلة للتخمين.
4) جدار الحماية السحابي (Cloud Firewall): كثير من المزودين يقدمون جداراً في لوحتهم يعمل قبل وصول الحزم إلى خادمك. افتح فيه فقط 22 لـ SSH، و80 و443 للموقع، و8090 للوحة CyberPanel.
5) بطاقة الخادم: سجّل عنوان IP والمنطقة وتاريخ الإنشاء والتجديد في ملف ملاحظاتك.

عن جدار الحماية تحديداً: إن فعّلت الجدار السحابي وجدار النظام معاً فالمنفذ يجب أن يُفتح في الاثنين. أكثر سؤال يتكرر في المنتديات هو «فتحت المنفذ ولا يعمل»، وجوابه غالباً أن الجدار الآخر ما زال مغلقاً.

أما بنود التكلفة فاقرأها قبل الاشتراك: هل الفوترة بالساعة أم بالشهر؟ هل عنوان IPv4 مشمول أم بند مستقل؟ هل النسخ التلقائي واللقطات (Snapshots) مدفوعة؟ ماذا يحدث عند تجاوز حصة النقل؟ هذه الأسئلة تغيّر التكلفة الفعلية أكثر من الفرق الظاهر في السعر الأساسي.

متى تكبّر الخطة؟ راقب أسبوعاً بهذه الأوامر:

free -h        # الذاكرة: انظر إلى عمود available
df -h /        # مساحة القرص الرئيسي
uptime         # متوسط الحمل خلال 1 و5 و15 دقيقة

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

• ابدأ من البرامج التي ستعمل معاً، ثم اختر الذاكرة قبل أي رقم آخر.
• الحد الأدنى في صفحة المتطلبات يكفي للتثبيت وليس لموقع تحت ضغط.
• اختر إصدار Ubuntu LTS تدعمه لوحتك صراحة، ومنطقة قريبة من جمهورك.
• المنفذ يجب أن يُفتح في الجدار السحابي وجدار النظام إن كانا مفعّلين معاً.

للاستزادة: CyberPanel: متطلبات التثبيت · Ubuntu: دورة الإصدارات ومدة دعم LTS · Ubuntu Manpages: الأمر df

4. SSH — بوابة الأوامر لسيرفرك

الهدف: تنشئ مفتاح SSH على حاسوبك، وتتصل به بالخادم، وتنشئ مستخدماً بصلاحية sudo، وتقرأ رسائل الاتصال الفاشل.

الصدفة الآمنة (SSH) اتصال مشفّر يعطيك سطر أوامر على الخادم كأنك جالس أمامه. على Windows 10 و11 يأتي عميل OpenSSH مدمجاً وتستخدمه من PowerShell مباشرة، وعلى macOS وLinux تفتح الطرفية. سنمشي في هذا الدرس خطوة بخطوة من حاسوب منى إلى خادمها، ونلاحظ ما يظهر في كل خطوة.

الخطوة 1: إنشاء زوج مفاتيح على حاسوبك. في PowerShell:

ssh-keygen -t ed25519 -C "mona-laptop"

يسألك عن مكان الحفظ (اضغط Enter لقبول الافتراضي)، ثم عن عبارة مرور تحمي المفتاح إن سُرق حاسوبك. الناتج ملفان في مجلد .ssh داخل مجلد المستخدم: id_ed25519 وهو المفتاح الخاص الذي لا يغادر جهازك أبداً، وid_ed25519.pub وهو المفتاح العام الذي تضعه على أي خادم تريد دخوله. نوع ed25519 حديث وقصير ومدعوم في كل إصدارات OpenSSH الحالية.

الخطوة 2: وضع المفتاح العام على الخادم. إن لم تضفه في شاشة إنشاء الخادم، وكان لديك كلمة مرور root مؤقتة، فنفّذ من PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

على macOS وLinux يختصر الأمر ssh-copy-id root@203.0.113.10 الخطوة نفسها. في أول اتصال يعرض ssh بصمة الخادم ويسأل هل تثق به؛ قارنها إن أتاح المزود عرضها في الكونسول، ثم اكتب yes فتُحفظ في ملف known_hosts. إن تغيرت البصمة لاحقاً دون أن تعيد تثبيت الخادم فتوقف واسأل عن السبب.

الخطوة 3: مستخدم يومي بدل root. العمل الدائم بحساب root يجعل أي خطأ كتابي قادراً على تدمير النظام. بعد الدخول كـ root:

adduser mona
usermod -aG sudo mona
rsync --archive --chown=mona:mona ~/.ssh /home/mona

الأمر الأول ينشئ المستخدم ويسأل عن كلمة مرور ستحتاجها مع sudo، والثاني يضيفه إلى مجموعة sudo، والثالث ينسخ مجلد المفاتيح إليه مع نقل الملكية، فيدخل بالمفتاح نفسه. افتح الآن نافذة PowerShell ثانية دون إغلاق الأولى، ونفّذ ssh mona@203.0.113.10 ثم sudo whoami. الناتج المتوقع كلمة root بعد إدخال كلمة مرور mona، وهذا يعني أن الصلاحية تعمل. لا تغلق نافذة root الأولى قبل نجاح هذا الاختبار.

الخطوة 4: التنقل الأساسي.

pwd              # المجلد الحالي، مثلاً /home/mona
ls -la           # المحتويات مع الملفات المخفية والصلاحيات
cd /var/log      # الانتقال إلى مجلد
nano notes.txt   # محرر بسيط: Ctrl+O للحفظ وCtrl+X للخروج
exit             # إنهاء الجلسة

رسائل الفشل الثلاث التي ستراها، وما تعنيه كل منها:
• Connection timed out: لا رد إطلاقاً. العنوان خاطئ، أو جدار حماية يُسقط الحزم بصمت، أو الخادم متوقف. ابدأ بالجدار السحابي وعنوان IP.
• Connection refused: وصلت إلى الجهاز، لكن لا برنامج يستمع على المنفذ. خدمة SSH متوقفة أو تعمل على منفذ آخر. افتح كونسول المزود ونفّذ sudo systemctl status ssh.
• Permission denied (publickey): الشبكة سليمة والمصادقة فشلت. اسم المستخدم خاطئ، أو المفتاح العام غير موجود في authorized_keys لهذا المستخدم، أو صلاحيات مجلد .ssh واسعة أكثر من اللازم. الخيار -v في ssh -v mona@203.0.113.10 يطبع تفاصيل المحاولة ويكشف أي مفتاح جُرّب.

اختصار يوفر الكتابة: بدل كتابة العنوان واسم المستخدم كل مرة، أنشئ على حاسوبك ملفاً اسمه config داخل مجلد .ssh يحتوي:

Host bakery
    HostName 203.0.113.10
    User mona
    IdentityFile ~/.ssh/id_ed25519

بعدها يكفي أن تكتب ssh bakery، ويعمل الاسم المختصر نفسه مع scp وrsync. هذا مفيد حين تدير أكثر من خادم، لأنه يمنع الخلط بين العناوين، ويجعل الأوامر في ملاحظاتك أوضح لمن يقرؤها بعدك.

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

• المفتاح الخاص لا يغادر جهازك، والمفتاح العام يوضع في authorized_keys على الخادم.
• أنشئ مستخدماً بصلاحية sudo واختبر دخوله من نافذة ثانية قبل إغلاق جلسة root.
• timed out تعني شبكة أو جداراً، وrefused تعني خدمة لا تستمع، وpublickey تعني مصادقة.
• الخيار ssh -v يكشف تفاصيل المحاولة الفاشلة وأي مفتاح جُرّب.

 [حاسوبك]
  id_ed25519 (خاص، لا يغادر)
  id_ed25519.pub ──┐
                   v
 [الخادم] ~/.ssh/authorized_keys
      |
   SSH :22 مشفّر
      |
  root ← للإعداد فقط
  mona + sudo ← للعمل اليومي

للاستزادة: Ubuntu Server: خادم OpenSSH · Microsoft Learn: استخدام OpenSSH على Windows · Ubuntu Server: إدارة المستخدمين وsudo

5. CyberPanel و OpenLiteSpeed — لوحة مجانية لمواقعك

الهدف: تفهم علاقة CyberPanel بخادم OpenLiteSpeed، وتثبت اللوحة بأمان، وتنشئ أول موقع، وتعرف أين تبحث حين يتعطل شيء.

CyberPanel لوحة ويب مفتوحة المصدر لإدارة المواقع على VPS، تعمل فوق خادم الويب OpenLiteSpeed في نسختها المجانية. من المتصفح تنشئ المواقع وقواعد البيانات وحسابات FTP والبريد، وتصدر الشهادات، وتأخذ النسخ. وتحت الواجهة يثبّت المعالج برامج حقيقية: OpenLiteSpeed لخدمة الصفحات، وMariaDB لقواعد البيانات، وإصدارات من PHP، واختيارياً خدمات بريد وDNS وFTP. فهم هذه الطبقات يفيدك حين تتعطل اللوحة ويبقى الموقع، أو العكس.

OpenLiteSpeed نفسه خادم ويب مفتوح المصدر يعتمد معمارية قائمة على الأحداث (Event-driven)، أي أن عدداً قليلاً من العمليات يخدم آلاف الاتصالات بدل عملية لكل اتصال. يفهم قواعد إعادة الكتابة (Rewrite Rules) المكتوبة لـ Apache في ملفات .htaccess، لكنه لا يطبق كل توجيهات Apache الأخرى، فلا تفترض أن كل سطر في .htaccess سيعمل كما هو. وله لوحة إدارة خاصة اسمها WebAdmin على المنفذ 7080، ويكفي المبتدئ أن يعرف وجودها، لأن CyberPanel يكتب إعدادات المواقع نيابة عنه.

قبل التثبيت: خادم Ubuntu نظيف بإصدار مدعوم في توثيق CyberPanel، ودخول كمستخدم root. يطلب التوثيق تحديث النظام أولاً، ثم تشغيل المثبّت داخل جلسة tmux حتى لا يتوقف إن انقطع اتصال SSH:

sudo apt update && sudo apt upgrade -y
sudo -i
tmux new -s cp
sh <(curl https://cyberpanel.net/install.sh || wget -O - https://cyberpanel.net/install.sh)

السطر الأخير ينزّل سكربت التثبيت من موقع CyberPanel، ويمرره إلى sh لينفّذه بصلاحيات root. هذا يعني ثقة كاملة بالمصدر، فانسخ العنوان من التوثيق الرسمي وحده. وإن انقطع الاتصال فعد إلى الجلسة بالأمر tmux attach -t cp لتجد التثبيت مستمراً.

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

بعد التثبيت: افتح https://203.0.113.10:8090 في المتصفح. سيظهر تحذير بأن الاتصال غير خاص، وهذا متوقع لأن اللوحة تبدأ بشهادة موقّعة ذاتياً (Self-signed) لا تعرفها المتصفحات. تابع وأنت متأكد من عنوان خادمك، وادخل بالمستخدم admin. ثم أنشئ الموقع الأول:
1) Websites ثم Create Website.
2) اختر الباقة والمالك، واكتب النطاق وبريد المسؤول، واختر إصدار PHP.
3) تنشئ اللوحة للموقع مستخدماً في النظام ومجلداً جذرياً بالشكل /home/example.com/public_html، وفيه صفحة افتراضية.
افتح النطاق بعد ضبط سجل A، وإن ظهرت الصفحة الافتراضية فالسلسلة كلها تعمل: DNS والجدار وOpenLiteSpeed وإعداد الموقع.

عن إصدارات PHP: تثبّت اللوحة نسخاً من PHP مهيأة لـ LiteSpeed باسم lsphp، وتختار لكل موقع إصداره من إعداداته، فيمكن أن يعمل موقع قديم على إصدار وموقع جديد على آخر في الخادم نفسه. لكن الإصدار الذي انتهى دعمه الرسمي لا يحصل على إصلاحات أمنية، فاجعل ترقية المواقع القديمة بنداً في خطتك بدل تركها سنوات.

حين لا يفتح شيء: افحص الخدمة نفسها قبل أن تشك في اللوحة.

sudo systemctl status lsws
sudo tail -n 30 /usr/local/lsws/logs/error.log
sudo ss -tlnp | grep -E ":(80|443|8090) "

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

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

• CyberPanel واجهة فوق OpenLiteSpeed وMariaDB وPHP، وفهم الطبقات يسهّل التشخيص.
• شغّل المثبّت داخل tmux كمستخدم root، وغيّر كلمة مرور admin الافتراضية.
• تحذير الشهادة على المنفذ 8090 متوقع في البداية لأنها موقّعة ذاتياً.
• عند العطل افحص systemctl status lsws وسجل الأخطاء وss قبل لوم اللوحة.

للاستزادة: CyberPanel: دليل التثبيت · OpenLiteSpeed: التوثيق الرسمي · CyberPanel على GitHub (الكود المصدري)

6. نشر الموقع — من ملفاتك إلى public_html

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

ملفات موقعك تذهب إلى جذر الموقع (Document Root)، وفي CyberPanel هو /home/example.com/public_html. خادم الويب يعرض ما في هذا المجلد وما تحته، وكل ملف خارجه لا يصل إليه الزائر. لهذا تضع ملفات الإعداد التي تحمل كلمات مرور خارج public_html كلما سمح التطبيق بذلك.

أربع طرق للرفع، وكل منها يناسب حالة:
• مدير الملفات (File Manager) في اللوحة: لملفات قليلة أو تعديل سريع. يمكنك رفع ملف ZIP ثم فكّه من داخل المدير.
• FTP عبر حساب تنشئه من قسم FTP في اللوحة وبرنامج مثل FileZilla: اختر الاتصال المشفّر (FTP over TLS)، لأن FTP العادي يرسل كلمة المرور نصاً مكشوفاً.
• SFTP أو scp فوق SSH: لا يحتاج خدمة إضافية، ويستخدم مفتاحك نفسه.
• git clone على الخادم: أنظف طريقة إن كان مشروعك في مستودع، والتحديث بعدها git pull داخل المجلد.

قبل وبعد: يوسف طالب في الإسكندرية رفع ملف أعماله لأول مرة. ضغط مجلد المشروع portfolio كما هو، ورفعه وفكّه، فصار المسار public_html/portfolio/index.html. النتيجة: الصفحة الرئيسية تعرض الصفحة الافتراضية، والموقع يظهر فقط على example.com/portfolio. ثم رفع صورة باسم Logo.PNG بينما الكود يطلبها باسم logo.png، فظهرت على حاسوبه واختفت على الخادم، لأن Windows لا يميّز حالة الأحرف في أسماء الملفات بينما Linux يميّزها. هكذا أعاد النشر بطريقة صحيحة من PowerShell:

Compress-Archive -Path .\portfolio\* -DestinationPath site.zip -Force
scp site.zip mona@203.0.113.10:/tmp/

لاحظ النجمة بعد اسم المجلد: هي التي تجعل الأرشيف يحوي ما داخل المجلد مباشرة، فيقع index.html في جذر الأرشيف. ثم على الخادم:

sudo apt install -y unzip
sudo unzip -o /tmp/site.zip -d /home/example.com/public_html/
ls -l /home/example.com/public_html

أظهر الأمر الأخير مشكلة ثالثة: الملفات الجديدة مملوكة لـ root لأن unzip نُفّذ بـ sudo، بينما الملفات التي أنشأتها اللوحة مملوكة لمستخدم الموقع. ملفات بمالك خاطئ قد تعمل في القراءة، لكنها تفشل حين يحاول التطبيق الكتابة أو حين ترفع تعديلاً من حساب FTP للموقع. الحل أن تقرأ المالك والمجموعة من ملف أنشأته اللوحة، ثم توحّدهما بالأمر sudo chown -R USER:GROUP مع وضع ما ظهر لك مكان USER وGROUP. وأبسط من ذلك كله أن ترفع من الأصل بحساب FTP الخاص بالموقع أو من مدير ملفات اللوحة، فتأخذ الملفات المالك الصحيح تلقائياً.

الصلاحيات المعتادة: 644 للملفات و755 للمجلدات الفرعية. لتطبيقها دفعة واحدة دون المساس بمجلد public_html نفسه:

find /home/example.com/public_html -mindepth 1 -type d -exec chmod 755 {} +
find /home/example.com/public_html -type f -exec chmod 644 {} +

ولا تستخدم 777 أبداً لحل مشكلة صلاحيات؛ فهي تسمح لأي عملية على الخادم بتعديل ملفاتك.

وإن نشرت بالأمر git clone داخل public_html مباشرة فسيصبح مجلد .git جزءاً من جذر الموقع، وقد يستطيع زائر فضولي تنزيل تاريخ المشروع كاملاً، بما فيه كلمات مرور حُذفت من الكود لاحقاً لكنها بقيت في التاريخ. الأسلم أن تستنسخ المستودع خارج public_html وتنسخ منه الملفات المطلوبة فقط، أو أن تمنع من إعدادات الخادم الوصول إلى المسارات التي تبدأ بنقطة.

بعد النشر اختبر بالأمر curl -I https://example.com/ واقرأ سطر الحالة:
• 200: الملف وُجد وأُرسل.
• 403 Forbidden: المسار موجود والخادم يرفض عرضه، غالباً لصلاحيات أو مالك خاطئ، أو مجلد بلا ملف index.
• 404 Not Found: لا ملف بهذا المسار؛ راجع الاسم وحالة الأحرف ومكان الرفع.
• 500 Internal Server Error: كود PHP تعطل أو إعداد خاطئ؛ السبب الحقيقي في سجل أخطاء الموقع في اللوحة.
• 503 Service Unavailable: الخادم أو معالج PHP غير متاح مؤقتاً، كأن يكون تحت ضغط أو أعيد تشغيله للتو.

وإن عدّلت ملفاً ولم يظهر التغيير فالأرجح أنك ترى نسخة مخزّنة: افتح نافذة خاصة أو اضغط Ctrl+F5، وتذكر أن إضافة التخزين المؤقت في LiteSpeed أو أي شبكة توزيع محتوى أمام الموقع قد تحفظ الصفحة أيضاً حتى تُفرغ ذاكرتها.

• ارفع محتويات مجلد المشروع مباشرة إلى public_html حتى يقع index.html في الجذر.
• Linux يميّز حالة الأحرف، فـ Logo.PNG وlogo.png ملفان مختلفان.
• الرفع بـ sudo يجعل الملفات مملوكة لـ root؛ وحّد المالك مع ملفات اللوحة.
• 644 للملفات و755 للمجلدات، ولا تستخدم 777 لحل أي مشكلة.
• رمز الحالة في curl -I يحدد اتجاه البحث: 403 صلاحيات، 404 مسار، 500 كود.

 portfolio\*  (المحتويات)
      |  Compress-Archive + scp
      v
 /tmp/site.zip
      |  unzip -d
      v
 public_html/index.html   ✓
 public_html/portfolio/   ✗ (خطأ شائع)
      |
 curl -I → 200 / 403 / 404 / 500

للاستزادة: MDN: رموز حالة HTTP · Git: الأمر git clone · FileZilla: التوثيق

7. SSL و HTTPS — شهادة صالحة وثقة الزائر

الهدف: تفهم كيف تثبت الشهادة هوية الموقع، وتصدر شهادة Let's Encrypt من اللوحة أو بأداة Certbot، وتفحص صلاحيتها وتعالج أخطاءها.

بروتوكول HTTP يرسل البيانات نصاً مكشوفاً، فيستطيع أي طرف في الطريق، كمالك شبكة Wi-Fi عامة، أن يقرأ ما يُرسل أو يعدّله. HTTPS هو HTTP فوق طبقة تشفير اسمها أمن طبقة النقل (TLS)، وما زال الناس يسمونها SSL باسم سلفها القديم. التشفير وحده لا يكفي؛ يجب أن يعرف المتصفح أنه يتحدث إلى الخادم الصحيح. هنا دور الشهادة: وثيقة رقمية توقعها جهة إصدار موثوقة (Certificate Authority) يعرفها المتصفح مسبقاً، تقول إن هذا المفتاح العام يخص هذا النطاق.

جهة Let's Encrypt غير ربحية تصدر شهادات مجانية بطريقة آلية عبر بروتوكول ACME. قبل الإصدار تتحقق من أنك تتحكم في النطاق. أشهر طرق التحقق HTTP-01: يضع برنامجك ملفاً مؤقتاً في المسار /.well-known/acme-challenge/ على موقعك، ثم تطلبه خوادم Let's Encrypt عبر HTTP على المنفذ 80 تحديداً، ومن أكثر من موقع في العالم. وهناك طريقة DNS-01 التي تضع فيها قيمة في سجل TXT، وهي الوحيدة التي تتيح شهادة شاملة لكل النطاقات الفرعية (Wildcard).

من هذا الشرح تخرج شروط النجاح قبل الضغط على أي زر:
1) سجل A للنطاق، ولـ www إن أردته، يشير إلى خادمك فعلاً، وتتحقق بالأمر dig +short.
2) المنفذ 80 مفتوح في الجدار السحابي وجدار النظام، حتى لو كان الموقع سيعمل على 443 وحده لاحقاً.
3) الموقع يجيب على http دون خطأ.
4) إن كان للنطاق سجل AAAA فيجب أن يصل إلى الخادم نفسه عبر IPv6، لأن خوادم التحقق قد تستخدمه.

الطريق الأول، من CyberPanel: القائمة SSL ثم Manage SSL، اختر الموقع واضغط Issue SSL. اللوحة تتولى التحقق والتجديد.
الطريق الثاني، على خادم Nginx بلا لوحة: أداة Certbot من مؤسسة EFF. على Ubuntu:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

الأمر الثاني يصدر شهادة تغطي الاسمين ويعدّل إعداد Nginx، والثالث يحاكي التجديد ليتأكد أنه سيعمل آلياً. وتوصي Certbot في موقعها بتثبيتها عبر snap للحصول على أحدث إصدار، والطريقتان صالحتان.

شهادات Let's Encrypt الافتراضية صالحة 90 يوماً، والجهة توصي بتجديدها كل 60 يوماً تقريباً، ولذلك يجب أن يكون التجديد آلياً. وقد أوقفت Let's Encrypt رسائل التذكير بانتهاء الصلاحية في يونيو 2025، فلا تنتظر بريداً ينبهك؛ راقب التاريخ بنفسك أو بخدمة مراقبة خارجية.

لفحص الشهادة من أي طرفية Linux:

curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates

الأول يجب أن يعيد سطر حالة مثل HTTP/2 200 دون أي خطأ شهادة. والثاني يطبع اسم صاحب الشهادة وسطرين notBefore وnotAfter، والأخير هو تاريخ الانتهاء الذي تراقبه.

إن فشل الإصدار فاقرأ الرسالة قبل الإعادة، فلدى Let's Encrypt حدود لعدد محاولات التحقق الفاشلة لكل اسم خلال الساعة، ولعدد الشهادات المكررة خلال الأسبوع. وعند التجربة المتكررة استخدم بيئة الاختبار (Staging) ذات الحدود الأعلى. أشهر الأخطاء بعد الإصدار:
• NET::ERR_CERT_COMMON_NAME_INVALID: الشهادة لا تغطي الاسم المفتوح، كأن تشمل example.com دون www.
• المحتوى المختلط (Mixed Content): الصفحة على https وتحمّل سكربتاً أو صورة عبر http، فيحجب المتصفح السكربت ويختفي القفل. غيّر الروابط إلى https أو إلى مسارات نسبية.

بعد نجاح الشهادة فعّل إعادة توجيه دائمة من http إلى https. وإن أردت لاحقاً ترويسة HSTS التي تلزم المتصفح باستخدام https وحده، فابدأ بمدة صغيرة، لأن المتصفح سيرفض http لنطاقك طوال المدة المحددة حتى لو احتجت التراجع.

• الشهادة تثبت أن المفتاح العام يخص النطاق، والتشفير وحده لا يكفي.
• تحقق HTTP-01 يتم على المنفذ 80 فقط، فلا تغلقه قبل الإصدار والتجديد.
• شهادات Let's Encrypt الافتراضية 90 يوماً، والتجديد يجب أن يكون آلياً ومراقباً.
• استخدم بيئة Staging عند التجربة المتكررة حتى لا تصطدم بحدود الطلبات.

 Let's Encrypt
      |  GET http://example.com/.well-known/acme-challenge/...  (:80)
      v
 [خادمك يرد بالملف] → تحقق ناجح
      |
      v
 شهادة 90 يوماً → تجديد آلي (~60 يوماً)
      |
 http :80 ──301──> https :443 🔒

للاستزادة: Let's Encrypt: أنواع التحقق · Let's Encrypt: حدود الطلبات · Let's Encrypt: الأسئلة الشائعة وعمر الشهادات · Certbot: دليل الاستخدام · MDN: المحتوى المختلط

8. النسخ الاحتياطي — خطتك عندما يحدث خطأ

الهدف: تكتب سكربت نسخ لقاعدة البيانات والملفات، وتجدوله، وتنقل النسخ خارج الخادم، وتجري تمرين استعادة كاملاً.

الخادم يتعطل لأسباب عادية جداً: حذف بالخطأ، أو تحديث إضافة كسر الموقع، أو اختراق، أو مشكلة في حساب المزود. النسخة الاحتياطية هي ما يحوّل كل ذلك من كارثة إلى ساعة إزعاج. والقاعدة المعتمدة في التخطيط هي 3-2-1: ثلاث نسخ من البيانات، على وسيطين مختلفين، واحدة منها على الأقل خارج المكان الأصلي.

وقبل كتابة أي سكربت أجب عن سؤال واحد: كم من العمل تحتمل أن تخسر؟ يسمي المختصون الجواب نقطة الاستعادة المستهدفة (RPO). متجر يتلقى طلبات طوال اليوم لا يحتمل خسارة يوم كامل، فيحتاج نسخة يومية على الأقل لقاعدة البيانات، وربما أكثر. ومدونة تُحدَّث مرة في الأسبوع تكفيها نسخة أسبوعية. والسؤال المكمل: كم من الوقت تحتمل أن يبقى الموقع متوقفاً حتى تنتهي الاستعادة؟ الجواب يحدد هل تكفي نسخة على جهازك أم تحتاج خادماً احتياطياً جاهزاً.

ماذا تنسخ؟ ملفات الموقع في public_html، وقاعدة البيانات إن وُجدت، وملفات الإعداد المهمة، وملف ملاحظات التشغيل. والنقطة التي يخطئ فيها كثيرون أن قاعدة البيانات لا تُنسخ بنسخ ملفاتها وهي تعمل، لأن الكتابة قد تحدث في منتصف النسخ فتنتج نسخة تالفة. الصحيح تفريغها (Dump) إلى ملف SQL بأداة mariadb-dump، واسمها القديم mysqldump ما زال يعمل.

هذا سكربت نسخ يومي تحفظه في /root/backup.sh. المثال لموقع اسمه example.com وقاعدة بيانات اسمها shopdb:

#!/bin/bash
set -euo pipefail
D=$(date +%F)
B=/root/backups
mkdir -p "$B"
mariadb-dump --single-transaction shopdb | gzip > "$B/db-$D.sql.gz"
tar -czf "$B/site-$D.tar.gz" -C /home/example.com public_html
find "$B" -type f -mtime +14 -delete

شرح السطور التي تحمل فكرة:
• set -euo pipefail يوقف السكربت عند أول خطأ. الجزء pipefail مهم تحديداً: بدونه لو فشل mariadb-dump لنجح gzip وأنتج ملفاً مضغوطاً شبه فارغ، وظننت أن النسخة سليمة.
• date +%F تعطي التاريخ بصيغة مثل 2026-10-03، فتُرتَّب النسخ زمنياً بالاسم.
• الخيار --single-transaction يأخذ لقطة متسقة لجداول InnoDB دون إيقاف الموقع.
• tar -C يجعل المسارات داخل الأرشيف تبدأ من public_html بدل المسار الكامل، فتسهل الاستعادة في أي مكان.
• السطر الأخير يحذف النسخ الأقدم من 14 يوماً، حتى لا تملأ النسخ القرص وتوقف الموقع الذي تحميه.
ولكي يدخل mariadb-dump دون كتابة كلمة المرور في السكربت، ضعها في الملف /root/.my.cnf تحت قسم [client] واجعل صلاحيته 600 بالأمر chmod 600.

اجعل السكربت قابلاً للتنفيذ وجدوله بأداة cron:

sudo chmod 700 /root/backup.sh
sudo crontab -e
30 3 * * * /root/backup.sh >> /var/log/site-backup.log 2>&1

السطر الأخير يُكتب داخل محرر crontab، ومعناه: الدقيقة 30 من الساعة الثالثة فجراً كل يوم. الحقول الخمسة بالترتيب: الدقيقة، الساعة، يوم الشهر، الشهر، يوم الأسبوع.

نسخة تعيش على الخادم نفسه تضيع معه. اسحبها من جهازك أو من خادم آخر بأداة rsync (على Linux أو macOS أو WSL):

rsync -avz root@203.0.113.10:/root/backups/ ./server-backups/

الشرطة المائلة في آخر المصدر تعني «انسخ محتويات المجلد»، وبدونها ينشئ rsync مجلد backups داخل الهدف. ولقطات المزود (Snapshots) طبقة إضافية مفيدة، لكنها تعيش في الحساب نفسه؛ إن أُغلق الحساب أو اختُرق ضاعت معه. وإن احتوت النسخة بيانات عملاء فشفّرها قبل رفعها إلى أي تخزين سحابي.

تمرين الاستعادة، كما أجراه فريق متجر صغير في جدة: نسخة لم تُجرَّب استعادتها مجرد أمل. أنشأ الفريق نطاقاً فرعياً تجريبياً في اللوحة مع قاعدة بيانات فارغة اسمها shoptest، ثم:

gunzip -c db-2026-10-03.sql.gz | mariadb shoptest
tar -xzf site-2026-10-03.tar.gz -C /tmp/restore
mariadb -e "SELECT COUNT(*) FROM orders" shoptest

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

• قاعدة 3-2-1: ثلاث نسخ، على وسيطين، واحدة خارج الخادم على الأقل.
• قاعدة البيانات تُفرَّغ بـ mariadb-dump --single-transaction ولا تُنسخ ملفاتها وهي تعمل.
• pipefail يمنع نسخة فارغة تبدو ناجحة، وحذف النسخ القديمة يحمي القرص.
• تمرين استعادة كامل على موقع تجريبي هو الدليل الوحيد على أن النسخة صالحة.

للاستزادة: MariaDB: أداة mariadb-dump · Ubuntu Server: النسخ الاحتياطي · Ubuntu Manpages: الأداة rsync · Ubuntu Manpages: الخدمة cron

9. مراقبة وأمان — سيرفر حي يحتاج عناية

الهدف: تبني روتين صيانة أسبوعياً: تحديثات، وجدار حماية، وتقوية SSH، وFail2ban، وقراءة السجلات والموارد، ومراقبة خارجية.

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

أولاً: التحديثات.

sudo apt update && sudo apt upgrade
systemctl status unattended-upgrades
cat /var/run/reboot-required

الأمر الأول يحدّث قائمة الحزم ثم يثبت الإصدارات الأحدث. والثاني يتحقق من خدمة التحديثات الأمنية التلقائية المفعّلة افتراضياً في Ubuntu Server. والثالث إن وُجد الملف طبع * System restart required *، أي أن تحديثاً للنواة أو مكتبة أساسية ينتظر إعادة تشغيل؛ اختر لها وقتاً هادئاً بدل تأجيلها أسابيع.

ثانياً، جدار حماية واحد: إن كان الخادم يعمل بـ CyberPanel فهو يدير الجدار بأداة firewalld، فافتح المنافذ وأغلقها من صفحة Firewall في اللوحة. أما على خادم بلا لوحة فأداة ufw هي الأسهل، والترتيب فيها حاسم:

sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

السماح بـ SSH يأتي قبل enable، وإلا حجب الجدار أي دخول SSH جديد وقد يقطع جلستك الحالية (ufw نفسه يحذّر من ذلك)، فلا يبقى لك إلا كونسول المزود. ولا تشغّل ufw وfirewalld معاً، فكل منهما يكتب قواعده ويربك الآخر.

ثالثاً، SSH بالمفاتيح وحدها: بعد التأكد من أن الدخول بالمفتاح يعمل، عدّل الملف /etc/ssh/sshd_config ليحتوي:

PasswordAuthentication no
PermitRootLogin prohibit-password

ثم نفّذ sudo sshd -t للتحقق من صحة الصياغة، وsudo systemctl restart ssh، وجرّب الدخول من نافذة جديدة قبل إغلاق القديمة. فخ حقيقي: بعض صور الخوادم السحابية تضع ملفاً داخل /etc/ssh/sshd_config.d/ يعيد تفعيل كلمات المرور ويتغلب على تعديلك. تأكد من القيمة الفعلية بالأمر sudo sshd -T | grep -i passwordauthentication، والناتج المطلوب passwordauthentication no.

رابعاً، Fail2ban يقرأ السجلات ويحظر مؤقتاً العناوين التي تكرر الدخول الفاشل. على Ubuntu تأتي حزمته مع حماية SSH مفعلة:

sudo apt install fail2ban
sudo fail2ban-client status sshd

الأمر الثاني يعرض عدد المحاولات الفاشلة والعناوين المحظورة حالياً.

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

df -h /
free -h
sudo journalctl -u ssh --since "7 days ago" | grep -ciE "invalid user|failed"
sudo du -sh /var/log /root/backups
sudo journalctl --disk-usage

يدوّن الأرقام في جدول بسيط ويقارنها بالأسبوع الماضي. في أحد الأسابيع قفز استخدام القرص من 40٪ إلى 71٪، وكشف الأمر du أن سجلات تطبيق في وضع التصحيح (Debug) نسيه زميل كبرت بسرعة. أوقف التصحيح، وقلّص سجلات النظام بالأمر sudo journalctl --vacuum-size=200M، قبل أن يصل القرص إلى الامتلاء. امتلاء القرص من أخطر الأعطال الصامتة: قاعدة البيانات تتوقف عن الكتابة والموقع يعرض أخطاء لا تشير إلى السبب.

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

sudo journalctl -u ssh --since "7 days ago" | grep Accepted

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

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

• تحقق من التحديثات التلقائية ومن ملف reboot-required، ولا تؤجل إعادة التشغيل طويلاً.
• جدار واحد فقط: firewalld عبر CyberPanel أو ufw على خادم بلا لوحة، وSSH يُسمح به قبل التفعيل.
• تحقق من إعداد SSH الفعلي بالأمر sshd -T لأن ملفات sshd_config.d قد تتغلب على تعديلك.
• روتين أسبوعي يقارن القرص والذاكرة والمحاولات الفاشلة يكشف المشكلة قبل أن تصبح عطلاً.

للاستزادة: Ubuntu Server: التحديثات التلقائية · Ubuntu Server: جدار الحماية ufw · Ubuntu Manpages: إعدادات sshd_config · Fail2ban: المستودع والتوثيق

10. المشروع النهائي — موقعك حي خلف شبكة توزيع محتوى

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

المشروع النهائي يجمع حلقات المسار في موقع حي تستطيع إدارته واستعادته وحدك، ثم يضيف طبقة أخيرة شائعة في المواقع الحقيقية: شبكة توزيع المحتوى (CDN). المطلوب منك: خادم موثق ببطاقة، ونطاق أو نطاق فرعي يشير إليه، وموقع منشور عبر CyberPanel، وشهادة صالحة مع توجيه من http، ونسخة خارج الخادم مع تمرين استعادة ناجح، وملف RUNBOOK.md.

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

خطوات الربط ونقاط الانتباه في كل منها:
1) تضيف النطاق إلى Cloudflare وتغيّر خوادم الأسماء عند المسجّل إلى التي تعطيك إياها؛ من الآن تُدار السجلات هناك، كما رأيت في درس DNS.
2) لكل سجل حالة وكيل (Proxy Status): السحابة البرتقالية تعني أن الطلبات تمر عبر Cloudflare، والرمادية (DNS only) تعني أن الاسم يشير إلى خادمك مباشرة. اجعل @ وwww بالوكيل، واترك بالرمادي كل اسم لخدمة غير الويب، كخادم البريد الذي يشير إليه MX، والاسم الذي تستخدمه لـ SSH. والأبسط أن تدخل SSH بعنوان IP مباشرة.
3) اضبط وضع التشفير على Full (strict). في هذا الوضع يتصل Cloudflare بخادمك عبر https ويتحقق من صحة شهادته، فيبقى الطريق مشفّراً وموثقاً من طرفيه. شهادة Let's Encrypt على الخادم تكفي، أو شهادة Origin CA التي تصدرها Cloudflare ولا تثق بها إلا خوادمها.

سجل عطل شائع: فعّل طالب الوكيل وترك وضع التشفير على Flexible، بينما خادمه يعيد توجيه كل طلب http إلى https. وضع Flexible يجعل Cloudflare يتصل بالخادم عبر http، فيرد الخادم بتوجيه إلى https، فيعيد Cloudflare الطلب عبر http، وهكذا بلا نهاية حتى يعرض المتصفح ERR_TOO_MANY_REDIRECTS. الحل: تغيير الوضع إلى Full (strict) بعد التأكد من وجود شهادة صالحة على الخادم. للتحقق:

curl -sI https://example.com | grep -iE "^(HTTP|server|cf-cache-status|location)"
curl -sI https://example.com/css/style.css | grep -i cf-cache-status

الأول يجب أن يعرض HTTP/2 200 مع server: cloudflare دون سطر location متكرر. والثاني يعرض HIT بعد الطلب الثاني لملف CSS إن خُزّن في الحافة.

لاحظ أن صفحات HTML نفسها لا تُخزَّن في Cloudflare افتراضياً؛ ما يُخزّن هو الملفات الثابتة بحسب امتدادها، مثل CSS وJS والصور والخطوط. وبعد تفعيل الوكيل ستظهر في سجلات خادمك عناوين Cloudflare بدل عناوين الزوار، فيُقرأ العنوان الحقيقي من ترويسة CF-Connecting-IP، وهذا يهمك لإحصاءاتك ولقواعد Fail2ban.

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

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

معيار النجاح أربعة اختبارات: الرابط يفتح من هاتف على بيانات الجوال خارج شبكة منزلك، وبلا أي تحذير شهادة، وطلب http يعيد 301 مع location يشير إلى https، وشخص آخر يستطيع باتباع RUNBOOK وحده نشر تعديل بسيط. هذا المشروع صالح لملف أعمالك: رابط حي، ودليل تشغيل منظم، وخطة نسخ مجربة.

• شبكة توزيع المحتوى تخدم الملفات الثابتة من خادم قريب وتخفي عنوان خادمك الأصلي.
• اجعل سجلات الويب بالوكيل، واترك البريد وSSH بحالة DNS only.
• وضع Flexible مع توجيه https على الخادم يسبب ERR_TOO_MANY_REDIRECTS؛ استخدم Full (strict).
• RUNBOOK بلا كلمات مرور، مع تواريخ التجديد وبنود التكلفة وخطوات الاستعادة.

للاستزادة: Cloudflare Docs: أوضاع التشفير · Cloudflare Docs: خطأ ERR_TOO_MANY_REDIRECTS · Cloudflare Docs: حالة الوكيل للسجلات · Cloudflare Docs: سلوك التخزين الافتراضي · Cloudflare Docs: استعادة عناوين الزوار الحقيقية