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

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

يفترض هذا الدّرس أنّك تمتلك خادوم تعمل عليه عناصر خادوم Bacula، كما هو موصوف في هذا الرّابط: كيف تثبت خادوم Bacula للنسخ الاحتياطي على Ubuntu 14.04.

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

سنقوم في بقيّة هذا الدّرس بالإشارة إلى خادوم Bacula بـ "BaculaServer"، "Bacula Server"، أو "Backup Server"، سنشير إلى المُضيف عن بُعد والذي يتم النسخ الاحتياطي له بـ "ClientHost"، "Client Host"، أو "Client".

فلنبدأ بالقيام ببعض التغييرات السريعة لإعدادات خادوم Bacula.

تنظيم إعدادات مدير Bacula Director (الخادوم)

نقوم على خادوم Bacula بتطبيق هذا القسم مرّة واحدة.

ربما قد لاحظت عند إعداد خادوم Bacula أنّ ملفّات الإعدادات طويلة بشكل زائد، سنحاول تنظيم إعدادات مدير Bacula قليلًا بحيث يستخدم ملفّات منفصلة لإضافة الإعدادات الجديدة مثل الوظائف jobs، مجموعات الملفّات file sets، والأحواض pools.

فلنقم بإنشاء دليل ليساعدنا على تنظيم ملفّات إعدادات Bacula:

sudo mkdir /etc/bacula/conf.d

نفتح بعدها ملف إعدادات مدير Bacula:

sudo vi /etc/bacula/bacula-dir.conf

نضيف هذا السطر في نهاية الملف:

@|"find /etc/bacula/conf.d -name '*.conf' -type f -exec echo @{} \;"

نقوم بحفظ الملف والخروج منه، يُخبِر هذا السطر المدير أن يبحث في الدليل /etc/bacula/conf.d عن ملفّات إضافيّة للإعدادات ليقوم بإلحاقها، وهذا يعني أنّ أي ملف .conf تتم إضافته هنا سيتم تحميله كجزء من الإعدادات.

إضافة حوض الملفات عن بعد RemoteFile Pool

نريد إضافة حوض Pool إضافي لإعدادات مدير Bacula لدينا، وسنستخدمه لإعداد وظائف النسخ الاحتياطي عن بُعد.

نفتح الملف conf.d/pools.conf:

sudo vi /etc/bacula/conf.d/pools.conf

نضيف موارد الحوض Pool التالية:

Pool {
  Name = RemoteFile
  Pool Type = Backup
  Label Format = Remote-
  Recycle = yes                       # Bacula can automatically recycle Volumes
  AutoPrune = yes                     # Prune expired volumes
  Volume Retention = 365 days         # one year
    Maximum Volume Bytes = 50G          # Limit Volume size to something reasonable
  Maximum Volumes = 100               # Limit number of Volumes in Pool
}

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

حتى الآن لا نحتاج إلى إعادة تشغيل مدير Bacula، ولكن فلنتحقّق أنّ إعداداته لا تحتوي على أيّة أخطاء فيها:

sudo bacula-dir -tc /etc/bacula/bacula-dir.conf

إن لم تكن هنالك أيّة أخطاء فنحن جاهزون للمتابعة في إعداد عميل Bacula Client.

تثبيت وإعداد عميل Bacula

نقوم بتنفيذ هذا القسم على أي مُضيف عميل Client Host نريد إضافته إلى إعداد Bacula.

في البداية نُحدِّث apt-get:

sudo apt-get update

نثبّت بعدها الحزمة bacula-client:

sudo apt-get install bacula-client

يقوم هذا بتثبيت عفريت (بالإنجليزية Daemon وهو برنامج يعمل في خلفيّة النظام) ملفّات Bacula FD أي (Bacula File Daemon)، والذي عادة تتم الإشارة إليه بعميل Bacula أي "Bacula client".

إعداد العميل

ينبغي قبل إعداد عفريت ملفّات العميل File Daemon إيجاد المعلومات التالية، والتي سيتم استخدامها خلال هذا الدّرس:

• اسم مضيف العميل Client hostname: سيستخدم مثالنا "ClientHost".
• FQDN الخاص للعميل Client Private FQDN: سنشير له بـ "clientprivateFQDN"، وهو يبدو مُشابِهًا لـ clienthost.private.example.com.
• اسم مضيف خادوم Bacula أي Bacula Server hostname: سيستخدم مثالنا "BackupServer".

ستختلف إعداداتك الفعلية عن هذه الأمثلة، لذا تأكّد من وضع معلوماتك في الأماكن المناسبة.
نفتح إعدادات عفريت الملفّات File Daemon:

sudo vi /etc/bacula/bacula-fd.conf

نحتاج لتغيير بعض العناصر وحفظ بعض المعلومات التي سنحتاجها لأجل إعدادات خادومنا.

نبدأ بإيجاد مورد المدير Director resource المُسمّى على اسم مضيف العميل لدينا (على سبيل المثال "ClientHost-dir")، وبما أنّ مدير Bacula الذي نريد التحكّم من خلاله بالعميل متواجد على خادوم Bacula فلنقم بتغيير مُعامِل الاسم "Name" إلى اسم المضيف لخادوم النسخ الاحتياطي لدينا متبوعًا بـ "-dir"، في مثالنا وباستخدام "BackupServer" كاسم مضيف خادوم Bacula يجب أن يبدو هذا مُشابِهًا لما يلي:

Director {
  Name = BackupServer-dir
  Password = "IrIK4BHRA2o5JUvw2C_YNmBX_70oqfaUi"
}

نحتاج أيضًا أن ننسخ المُعامِل Password ونحفظه من أجل العودة إليه لاحقًا، وهو عبارة عن كلمة السّر المُولَّدة تلقائيًّا والمستخدمة من أجل الاتصال إلى عفريت الملفّات File Daemon، سيتم استخدامها في إعدادات مدير خادوم النسخ الاحتياطي حيث سنقوم بتعيينها في خطوة قادمة من أجل الاتصال إلى عفريت الملفّات File Daemon الخاص بالعميل.

نحتاج بعدها إلى ضبط معامل واحد في مورد عفريت الملفّات FileDaemon، حيث سنقوم بتغيير المُعامِل FDAddress ليُطابِق FQDN الخاص لأجهزة عملائنا، يجب أن يكون مُسبقًا قد تم إعداد المُعامِل Name بشكل صحيح مع اسم عفريت الملفّات file daemon للعميل، ينبغي أن يبدو المورد مشابهًا لما يلي (قم بوضع FQDN الفعلية أو عنوان IP لديك):

FileDaemon {                          # this is me
  Name = ClientHost-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 20
  FDAddress = client_private_FQDN
}

نحتاج أيضًا لضبط هذا العفريت daemon ليقوم بتمرير رسائل سجلّاته إلى خادوم النسخ الاحتياطي، نقوم بالبحث عن مورد الرسائل Messages وتغيير المُعامِل director ليطابق اسم مضيف خادوم النسخ الاحتياطي لدينا مع اللاحقة "-dir"، ينبغي أن يبدو مشابهًا لما يلي:

Messages {
  Name = Standard
  director =  BackupServer-dir = all, !skipped, !restored
}

نقوم بحفظ الملف والخروج منه، تم الآن إعداد عفريت الملفّات File Daemon (عميل Bacula) ليستمع للاتصالات عبر الشبكة الخاصّة.

نتحقّق من أن ملف الإعدادات يمتلك الصياغة الصحيحة باستخدام الأمر التالي:

sudo bacula-fd -tc /etc/bacula/bacula-fd.conf

إن لم يُعد الأمر أي خَرْج output فهذا يعني أنّ ملف الإعدادات يمتلك صياغة صحيحة، نعيد تشغيل عفريت الملفّات File Daemon ليستخدم الإعدادات الجديدة:

sudo service bacula-fd restart

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

sudo mkdir -p /bacula/restore
sudo chown -R bacula:bacula /bacula
sudo chmod -R 700 /bacula

تمّ الآن إعداد جهاز العميل بشكل صحيح، سنقوم بعدها بضبط خادوم النسخ الاحتياطي ليكون قادرًا على الاتصال إلى عميل Bacula.

إضافة مجموعات الملفات FileSets (الخادوم)

تُعرِّف Bacula FileSet مجموعة من الملفّات أو الأدلة التي يتم تضمينها أو استثناؤها من اختيار النسخ الاحتياطي، ويتم استخدامها من قبل وظائف النسخ الاحتياطي على خادوم Bacula.

إن اتبعت الدّرس الموجود في المتطلّبات الأساسيّة والذي يقوم بإعداد عناصر خادوم Bacula فأنت تمتلك مسبقًا مجموعة ملفّات FileSet تُدعى "Full Set"، إن كنت تريد تشغيل وظائف نسخ احتياطي تتضمّن كل ملف على جهاز العميل لديك فتستطيع استخدام مجموعة الملفّات FileSet هذه في وظائفك، ومع ذلك ربّما تجد غالبًا أنّك لا تريد ولا تحتاج امتلاك نسخة احتياطية لكل شيء على الخادوم، وبهذا تكفيك مجموعة فرعيّة من البيانات.

عندما تكون أكثر انتقائيّة في اختيار الملفّات التي تريد تضمينها في مجموعة الملفّات FileSet ستوفّر من مساحة القرص لديك وتوفّر من الوقت الذي يحتاجه خادوم النسخ الاحتياطي للقيام بوظيفة نسخ احتياطي، وستجعل عمليّة استعادة الملفّات أبسط حيث لن يتوجب عليك البحث في مجموعة كاملة "Full Set" لإيجاد الملفّات التي تريد استعادتها.

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

على خادوم Bacula نفتح الملف الذي يُدعى filesets.conf الموجود في دليل إعدادات مدير Bacula الذي أنشأناه:

sudo vi /etc/bacula/conf.d/filesets.conf

نقوم بإنشاء مورد مجموعة ملفّات FileSet لكل مجموعة محدّدة من الملفّات التي نريد استخدامها في وظائف النسخ الاحتياطي، سننشئ في هذا المثال مجموعة ملفّات FileSet تشمل فقط الدليل الرئيسي home والدليل etc:

FileSet {
  Name = "Home and Etc"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /home
    File = /etc
  }
  Exclude {
    File = /home/bacula/not_important
  }
}

هنالك الكثير من الأشياء التي تحدث في هذا الملف ولكن هذه بعض التفاصيل التي يجب أن تبقى في ذهننا:

• يجب أن يكون اسم مجموعة الملفّات FileSet فريدًا
• تضمين أي ملفّات أو أقراص نريد الحصول على نسخ احتياطيّة لها
• استثناء أي ملفّات لا نريد النسخ الاحتياطي لها ولكن تمّ اختيارها نتيجة وجودها بداخل ملفّات مُضمَّنة

نستطيع إنشاء العديد من مجموعات الملفّات FileSets إن كنّا نرغب بذلك، نقوم بالحفظ والخروج بعد الانتهاء.
نحن الآن مستعدون لإنشاء وظيفة نسخ احتياطي تستخدم مجموعة ملفّاتنا الجديدة.

إضافة عميل Client ووظيفة نسخ احتياطي Backup Job إلى خادوم Bacula

نحن الآن جاهزون لإضافة عميلنا إلى خادوم Bacula، ولعمل هذا يجب علينا إعداد مدير Bacula مع موارد العميل والوظيفة الجديدة.

نفتح الملف conf.d/clients.conf:

sudo vi /etc/bacula/conf.d/clients.conf

1. إضافة مورد عميل Client Resource

يقوم مورد العميل بضبط المدير Director مع المعلومات التي يحتاجها للاتصال إلى مضيف العميل، يتضمّن هذا الاسم، العنوان، وكلمة السّر لعفريت ملفّات العميل Client File Daemon.

نقوم بلصق التعريف التالي لمورد العميل إلى ذلك الملف، تأكد من أن تضع اسم مضيف العميل لديك، FQDN الخاص، وكلمة السّر (من ملف العميل bacula-fd.conf):

Client {
  Name = ClientHost-fd
  Address = client_private_FQDN
  FDPort = 9102 
  Catalog = MyCatalog
  Password = "IrIK4BHRA2o5JUvw2C_YNmBX_70oqfaUi"          # password for Remote FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

نحتاج لعمل هذا مرّة واحدة فقط لكل عميل.

2. إنشاء وظيفة نسخ احتياطي backup job

تُعرِّف وظيفة النسخ الاحتياطي backup job تفاصيل حول العميل والبيانات التي يجب عمل نسخ احتياطي لها، ويجب أن يملك اسمًا فريدًا.

نلصق وظيفة النسخ الاحتياطي التالية إلى الملف، مع وضع اسم مضيف العميل لدينا بدلًا من كلمة ClientHost:

Job {
  Name = "BackupClientHost"
  JobDefs = "DefaultJob"
  Client = ClientHost-fd
  Pool = RemoteFile
  FileSet="Home and Etc"
}

يقوم هذا بإنشاء وظيفة نسخ احتياطي تُدعى "BackupClientHost" والتي تقوم بإنشاء نسخة احتياطيّة للدليلين home وetc من مضيف العميل، كما هو مُعرَّف في مجموعة الملفّات FileSet التي تُدعى "Home and Etc"، ستستخدم هذه الوظيفة الإعدادات المُحدّدة في تعريف الوظائف JobDefs الذي يُدعى "DefaultJob" وموارد الحوض Pool الذي يُدعى "RemoteFile"، وكلاهما مُعرَّف في الملف الرئيسي bacula-dir.conf، الوظائف التي تُحدِّد JobDefs = "DefaultJob" يتم تشغيلها أسبوعيًّا بشكل افتراضي.

عند الانتهاء نحفظ الملف ونخرج منه.

3. التحقق من إعدادات المدير Director

فلنتحقّق من عدم وجود أخطاء صياغة في ملف إعدادات المدير لدينا:

sudo bacula-dir -tc /etc/bacula/bacula-dir.conf

إن تمّت إعادتنا إلى مُحث الصدفة shell prompt فهذا يعني أنّه لا توجد أخطاء صياغة في ملفّات إعدادات مدير Bacula.

4. إعادة تشغيل مدير Bacula

ولتطبيق التغييرات التي قمنا بها نعيد تشغيل مدير Bacula:

sudo service bacula-director restart

يكون العميل أو المضيف عن بعد مُعدًّا الآن ليتم نسخه احتياطيًّا عن طريق خادوم Bacula.

اختبار اتصال العميل

ينبغي أن نتحقّق من قدرة مدير Bacula على الاتصال بعميل Bacula.

ندخل إلى Bacula Console على خادوم Bacula:

sudo bconsole

Select Client resource: ClientHost-fd
The defined Client resources are:
     1: BackupServer-fd
     2: ClientHost-fd
Select Client (File daemon) resource (1-2): 2

ينبغي أن تعود إلينا حالة عفريت ملفّات العميل Client File Daemon، وإن لم يحدث ذلك ووجد خطأ بالاتصال فهنالك مشكلة ما في إعدادات خادوم Bacula أو عفريت ملفّات العميل Client File Daemon.

اختبار وظيفة النسخ الاحتياطي

فلنقم بتشغيل وظيفة النسخ الاحتياطي للتأكد من أنّها تعمل.

نستخدم هذا الأمر على خادوم Bacula من خلال الـ Console:

run

سيتم حثّنا على اختيار الوظيفة التي نريد تشغيلها، نختار الوظيفة التي أنشأناها سابقًا (في مثالنا "4. BackupClientHost"):

Select Job resource: BackupClientHost
The defined Job resources are:
     1: BackupLocalFiles
     2: BackupCatalog
     3: RestoreLocalFiles
     4: BackupClientHost
Select Job resource (1-4): 4

وفي مُحث prompt التأكيد نختار "yes":

Confirmation prompt:
OK to run? (yes/mod/no): yes

التحقق من الرسائل والحالة

سيخبرنا Bacula بعد تشغيل الوظيفة أنّنا نمتلك رسائل، وهي عبارة عن خَرْج تمّ توليده من قبل الوظائف قيد التشغيل.

نتحقّق من الرسائل بكتابة:

messages

ينبغي أن تخبرنا الرسائل أنّه لم يتم إيجاد تسجيل لوظيفة نسخ احتياطي كامل سابقة "No prior Full backup Job record found" وأنّه بدأت وظيفة النسخ الاحتياطي لدينا، إن وُجِدَت أيّة أخطاء أخرى فهناك خطأ ما ويجب أن تعطيك هذه الأخطاء تلميحًا عن سبب عدم عمل الوظيفة.

ومن الطرق الأخرى لرؤية حالة الوظيفة هي التحقّق من حالة المدير Director، ولعمل هذا نكتب الأمر التالي في bacula console:

status director

إن كان كل شيء على ما يرام فينبغي أن نرى أنّ وظيفتنا قيد التشغيل أو تمّت مقاطعتها بحالة "OK".

القيام باستعادة ملفات Restore

يجب أن نختبر في المرّة الأولى لإعداد عميل Bacula جديد أنّ استعادة الملفّات تعمل بشكل صحيح.

إن أردنا القيام باستعادة ملفّات نستخدم الأمر restore في Bacula Console:

restore all

ستظهر قائمة للاختيار مع العديد من الخيارات المختلفة، والتي تُستخدم لتحديد مجموعة النسخ الاحتياطي التي نريد الاستعادة منها، وبما أنّنا نملك نسخة احتياطيّة واحدة فقط سنختار الخيار 5 وهو اختيار أحدث نسخة احتياطيّة "Select the most recent backup":

Select item (1-13):
5

يجب بعدها أن نحدّد العميل الذي نريد الاستعادة إليه، نريد الاستعادة للمضيف عن بعد الذي قمنا بإعداده للتو، وهو في مثالنا "ClientHost-fd":

Select the Client: ClientHost-fd
Defined Clients:
     1: BackupServer-fd
     2: ClientHost-fd
Select the Client (1-2): 2

ستُعرَض الآن لنا شجرة ملفّات افتراضية مع كامل بنية الدليل الذي قمنا بالنسخ الاحتياطي له، تسمح هذه الواجهة المشابهة لواجهة الصدفة shell للأوامر البسيطة بتحديد وإلغاء تحديد الملفّات التي نريد استعادتها.

ولأنّنا حدّدنا أنّنا نريد استعادة كافّة الملفّات "restore all"، فجميع الملفّات الموجودة في النسخة الاحتياطيّة مُحدّدة لاستعادتها، الملفّات المحدّدة مسبوقة بالحرف *.

ولتحسين اختيار الملفّات، نستطيع التصفّح وسرد الملفّات باستخدام الأمرين "ls" و"cd"، تحديد الملفّات باستخدام الأمر "mark"، وإلغاء تحديد الملفّات باستخدام الأمر "unmark"، وتوجد قائمة من الأوامر متاحة بكتابة "help" في الـ console.

عند الانتهاء من اختيار الملفّات التي نريد استعادتها نتابع بكتابة ما يلي:

done

نقوم بتأكيد أنّنا نرغب بتنفيذ وظيفة الاستعادة:

OK to run? (yes/mod/no):
yes

التحقق من الرسائل والحالة

يجب علينا التحقّق من الرسائل وحالة المدير بعد تشغيل وظيفة استعادة الملفّات، كما هو الحال مع وظيفة النسخ الاحتياطي.

نتحقّق من الرسائل بكتابة ما يلي:

messages

ينبغي أن نجد رسالة تخبرنا أنّ وظيفة استعادة الملفّات قد بدأت أو تمّت مقاطعتها بحالة "Restore OK"، إن وُجِدَت أيّة أخطاء أخرى فهناك خطأ ما ويجب أن تعطيك هذه الأخطاء تلميحًا عن سبب عدم عمل الوظيفة.

وكما وجدنا سابقَا فإنّ التحقّق من حالة المدير هو طريقة رائعة لنرى حالة وظيفة استعادة الملفّات:

status director

عند الانتهاء من استعادة الملفّات نكتب exit لمغادرة Bacula Console:

exit

إن سار كل شيء على ما يرام فسنجد الملفّات التي تمّت استعادتها على مضيف العميل في الدليل /bacula/restore، إن كنت فقط تختبر عمليّة استعادة الملفّات فاحذف محتويات هذا الدليل.

الخاتمة

تمتلك الآن خادوم Bacula يقوم بالنسخ الاحتياطي للملفّات من عميل Bacula عن بعد، تأكّد من أن تراجع إعداداتك حتى تصبح متأكدًا من أنّك تقوم بالنسخ الاحتياطي لمجموعة الملفّات FileSets الصحيحة، وبجدول ملائم لاحتياجاتك.

الخطوة القادمة التي يجب فعلها هي أن تعيد الخطوات السابقة من أجل خواديم Ubuntu الإضافية التي تريد عمل نسخ احتياطي لها.

ترجمة -وبتصرّف- لـ How To Back Up an Ubuntu 14.04 Server with Bacula لصاحبه Mitchell Anicas.

سنتعلّم في هذا الدّرس كيفيّة الحصول على شهادة SSL من سلطة شهادات تجاريّة (Commercial Certificate Authority (CA وكيفيّة تثبيتها، تسمح شهادات SSL لخواديم الويب بتشفير حركة مرور بياناتها traffic وتُوفِّر آليّة للتحقّق من هويّات الخواديم من أجل الزوّار، إنّ الميزة الأساسيّة لشراء شهادة SSL من سلطة شهادات تجاريّة (CA) موثوقة عن الشهادات المُوقَّعة ذاتيًّا self-signed أنّه لن يتم عرض تحذير مُخيف للزوّار حول عدم القدرة على التحقّق من هويّة موقعنا.

يغطّي هذا الدرس كيفيّة الحصول على شهادة SSL من سلطات الشهادات الموثوقة التالية:

• GoDaddy
• RapidSSL via Namecheap

بإمكانك أيضًا استخدام أي سلطة شهادات CA من اختيارك.

سنشرح بعد أن حصلنا على شهادة SSL كيفيّة تثبيتها على خواديم ويب Nginx و Apache HTTP.

سنشاهد في هذا الدّرس كيفيّة الحصول على شهادة SSL مُفردة النطاق أو wildcard من GoDaddy وRapidSSL، ولكنّ الحصول على الأنواع الأخرى من الشهادات مماثل تمامًا.

توليد CSR ومفتاح خاص Private Key

بعد أن تقوم بتجهيز المتطلبات الأساسيّة وتختار نوع الشهادة التي نريد الحصول عليها، تحتاج لتوليد طلب توقيع الشهادة (certificate signing request (CSR ومفتاح خاص private key.

إن كنت تخطّط لاستخدام Apache HTTP أو Nginx كخادوم ويب لديك فاستخدم openssl لتوليد CSR ومفتاحك الخاص على خادومك الويب، سنبقي في هذا الدّرس كافّة الملفات المرتبطة بهذا في الدليل الرئيسي home directory ولكن لا تتردد في تخزينها في أي موقع آمن على خادومك:

cd ~

نقوم بتنفيذ هذا الأمر لتوليد مفتاح خاص يُدعى example.com.key و CSR يُدعى example.com.csr (ضع اسم نطاقك بدلًا من example.com):

openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

عند هذه النقطة سيتم حثنا على إدخال عدّة أسطر من المعلومات تُضمَّن في طلب شهادتنا، إنّ الجزء الأهم منها هو حقل الاسم الشائع Common Name والذي يجب أن يُطابق الاسم الذي نرغب باستخدام الشهادة معه، على سبيل المثال example.com ،www.example.com، أو (بالنسبة لطلب شهادة wildcard) *.example.com، إن كنت تُخطّط للحصول على شهادة OV أو EV فتأكّد من أن تتوافق كافّة الحقول الأخرى بدقة مع بيانات منظمتك أو عملك.

على سبيل المثال:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:sammy@example.com

سيقوم هذا بتوليد ملفات key. و csr.، حيث يكون الملف key. هو مفتاحنا الخاص ويجب أن نبقيه في مكان آمن، والملف csr. هو الذي يجب أن نرسله إلى سلطة الشهادات لطلب شهادة SSL.

نحتاج إلى نسخ ولصق CSR الخاصّة بنا عند تقديم طلب الشهادة إلى سلطة الشهادات، نستخدم هذا الأمر لطباعة محتويات ملف CSR لدينا (ضع اسم ملفّك بدلًا من التالي):

cat example.com.csr

نحن الآن مستعدون لشراء شهادة من سلطة الشهادات، سنعرض هنا مثالين، GoDaddy و RapidSSL عبر Namecheap، ولكن لك الحرية بالحصول على الشهادة من أي بائع آخر.

مثال سلطة الشهادات الأول: RapidSSL via Namecheap

توفّر Namecheap طريقة لشراء شهادات SSL من مجموعة متنوعة من سلطات الشهادات، سنشرح عمليّة الحصول على شهادة نطاق مُفرَد من RapidSSL، ولكن إن أردت نوعًا مختلفًا من الشهادات فبإمكانك فعل ذلك.

ملاحظة: إن طلبنا شهادة نطاق مُفرَد من RapidSSL من أجل النطاق الفرعي www لنطاقنا (على سبيل المثال www.example.com) فسيقومون بإصدار الشهادة لنا مع SAN لنطاقنا الأساسي، فإن كان طلب شهادتنا على سبيل المثال من أجل www.example.com فستعمل الشهادة الصادرة من أجل www.example.com و example.com.

اختيار وشراء الشهادة

نذهب إلى صفحة Namecheap لشهادات SSL .

نستطيع هنا البدء في اختيار مستوى التحقّق، نوع الشهادة ("Domains Secured") أو ("CA Brand").

سنضغط في مثالنا على زر مقارنة المنتجات Compare Products في مربّع التحقّق من النطاق "Domain Validation"، بعدها نستطيع إيجاد "RapidSSL" والضغط على زر إضافة إلى السلّة Add to Cart.

عند هذه النقطة يجب علينا التسجيل في Namecheap أو تسجيل الدخول إليه، وإنهاء عمليّة الدفع.

طلب الشهادة

نذهب بعد أن دفعنا من أجل الشهادة التي اخترناها إلى الرابط Manage SSL Certificates الموجود تحت القسم "Hi Username".

سنشاهد هنا قائمة بكامل شهادات SSL التي اشتريناها عبر Namecheap، نضغط على رابط التفعيل الآن Activate Now من أجل الشهادة التي نريد استخدامها.

نختار الآن برمجيّة خادوم الويب لدينا والتي تُحدِّد تنسيق الشهادة التي سيسلمها Namecheap لنا، الخيارات التي نختارها بشكل شائع هي "Apache + MOD SSL"، "nginx"، أو "Tomcat".

نلصق CSR الخاصة بنا في المربّع ونضغط بعدها زر التالي Next.

يجب أن نكون الآن في خطوة اختيار المُصادِق "Select Approver" من العمليّة، والتي سترسل بريد إلكتروني لطلب التحقّق إلى عنوان في تسجيل WHOIS لنطاقنا أو إلى عنوان من نوع مدير administrator للنطاق الذي نريد أن نحصل على شهادة له، نختار العنوان الذي نريد أن نرسل إليه البريد الإلكتروني للتحقّق.

نقوم بتزويد معلومات التواصل الإداريّة "Administrative Contact Information" ونضغط على زر تقديم الطلب Submit order.

التحقق من النطاق

سيتم عند هذه النقطة إرسال بريد إلكتروني إلى عنوان المُصادِق "approver"، نفتح البريد الإلكتروني ونصادق على طلب الشهادة.

تنزيل الشهادات

بعد المُصادَقة على الشهادة سيتم إرسالها عبر البريد الإلكتروني إلى القسم التقني Technical Contact، ستكون الشهادة الصادرة لنطاقنا وشهادة سلطة الشهادات الوسيطة CA's intermediate certificate في أسفل رسالة البريد الإلكتروني.

ننسخها ونحفظها إلى خادومنا في نفس المكان الذي وضعنا فيه CSR ومفتاحنا الخاص.

نقوم بتسمية الشهادة باسم النطاق مُضافًا إليه اللاحقة crt.، مثل example.com.crt، وتسمية الشهادة الوسيطة intermediate.crt.

تكون الشهادة الآن جاهزة للتثبيت على خادوم الويب لدينا.

مثال سلطة الشهادات الثاني: GoDaddy

إنّ GoDaddy هي سلطة شهادات شائعة تملك كافّة أنواع الشهادات الأساسية، سنشرح عمليّة الحصول على شهادة نطاق مُفرَد، ولكن إن أردت نوعًا مختلفًا من الشهادات فبإمكانك فعل ذلك.

اختيار وشراء الشهادة

نذهب إلى صفحة GoDaddy لشهادات SSL.

ننزل للأسفل ونضغط على زر البدء Get Started.

نختار نوع شهادة SSL الذي نريده من القائمة المنسدلة:

• نطاق مُفرَد single domain
• نطاقات متعدّدة (multidomain (UCC
• wildcard

نختار بعدها نوع الخطّة plan:

• نطاق domain
• مُنظَّمة organization
• تحقّق مُوسَّع extended validation

ثم نختار المدى term (مُدّة الصلاحية).

نضغط بعدها على زر إضافة إلى السلّة Add to Cart.

نُراجع طلبنا الحالي ثم نضغط على المتابعة إلى الدفع Proceed to Checkout.

ومن ثمّ نكمل التسجيل وعمليّة الدفع.

طلب الشهادة

بعد إكمال طلبنا نضغط على زر SSL Certificates* (أو نضغط على My Account > Manage SSL Certificates الموجودة في الزاوية العلوية اليمنى).

نقوم بإيجاد شهادة SSL التي اشتريناها للتو ونضغط على زر الإعداد Set Up، إن لم تستخدم GoDaddy من قبل من أجل شهادات SSL فسيتم حثك على إعداد مُنتَج "SSL Certificates" وربط طلب شهادتك الأخيرة مع المُنتَج (نضغط على زر Set Up الأخضر وننتظر عدّة دقائق قبل تحديث متصفّحنا).

بعد أن تتم إضافة مُنتَج "SSL Certificates" إلى حسابنا في GoDaddy ينبغي أن نرى شهادتنا الجديدة "New Certificate" وزر التنفيذ "Launch"، نضغط على الزر Launch الموجود بجانب شهادتنا الجديدة.

نقوم بتقديم CSR الخاص بنا عن طريق لصقه في المربع، تُستخدَم خوارزميّة SHA-2 افتراضيًّا.

نضع علامة في خانة التأشير I agree ونضغط على زر طلب الشهادة Request Certificate.

التحقق من النطاق

يجب الآن أن نُثبِت أنّنا نمتلك تحكّمًا بنطاقنا ونزوّد GoDaddy ببعض المستندات، تقوم GoDaddy بإرسال رسالة بريد إلكتروني للتحقّق من ملكيّة النطاق إلى العنوان الموجود في تسجيل WHOIS لنطاقنا، نتبع الخطوات الموجودة في رسائل البريد الإلكتروني التي تصلنا ونُصرِّح بإصدار الشهادة.

تنزيل الشهادة

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

نضغط الآن على زر التنزيل Download.

نختار برمجيّة الخادوم التي نستخدمها من القائمة المنسدلة لنوع الخادوم Server type، إن كنّا نستخدم Apache HTTP أو Nginx نختار "Apache" ثم نضغط على زر تنزيل الملف المضغوط Download Zip File.

نستخرج الملف المضغوط، الذي ينبغي أن يحتوي على ملفين crt.، أحدهما شهادة SSL الخاصّة بنا (التي ينبغي أن تملك اسمًا عشوائيًّأ) وحزمة bundle شهادة GoDaddy الوسيطة (gd_bundle-g2-1.crt)، نقوم بنسخهما إلى خادوم الويب لدينا، ونعيد تسمية الشهادة إلى اسم نطاقنا مع إضافة اللاحقة crt.، على سبيل المثال example.com.crt، ونعيد تسمية حزمة الشهادة الوسيطة إلى intermediate.crt.

تكون الشهادة الآن جاهزة للتثبيت على خادوم الويب لدينا.

تثبيت الشهادة على خادوم الويب لدينا

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

سنغطي في هذا القسم الإعدادات الأساسيّة لخادوم Nginx و Apache HTTP على Ubuntu.

سنفترض الأمور التالية:

• يتوضّع المفتاح الخاص وشهادة SSL والشهادات الوسيطة لسلطة الشهادات-إن كان ذلك قابلًا للتطبيق- في الدليل الرئيسي على المسار home/sammy/
• يُدعى المفتاح الخاص باسم example.com.key
• تُدعى شهادة SSL باسم example.com.crt
• تُوجد الشهادة أو الشهادات الوسيطة لسلطة الشهادات في ملف يُدعى intermediate.crt
• إن كنت تملك جدار ناري مُمكَّنًا لديك فتأكّد من أنّه يسمح بالمنفذ 443 (منفذ HTTPS)

ملاحظة: يجب في البيئة الحقيقيّة تخزين هذه الملفّات في مكان يستطيع فقط المستخدم الذي يُشغِّل عملية خادوم الويب الرئيسيّة (عادة root) الوصول إليه، ينبغي الاحتفاظ بالمفتاح الخاص في مكان آمن.

خادوم Nginx

إن كنت ترغب باستخدام شهادتك مع خادوم Nginx على Ubuntu فاتبع هذا القسم.

ينبغي في Nginx إن كانت سلطة الشهادات قد أعطتنا شهادة وسيطة أن نقوم بإنشاء ملف شهادة مُفرَد محمي بالسلاسل chained يحتوي على شهادتنا والشهادات الوسيطة لسلطة الشهادات.

نذهب إلى الدليل الذي يحوي مفتاحنا الخاص، الشهادة، وشهادة سلطة البيانات الوسيطة (أي الملف intermediate.crt)، سنفترض أنّها في الدليل الرئيسي على سبيل المثال:

cd ~

بافتراض أنّ ملف الشهادة يُدعى example.com.crt نستخدم هذا الأمر لإنشاء ملف مُدمَج يُدعى example.com.chained.crt (نضع اسم نطاقنا بدلًا من example.com):

cat example.com.crt intermediate.crt > example.com.chained.crt

نذهب الآن إلى دليل إعدادات كتلة block خادوم Nginx، وبافتراض أنّه موجود في المسار etc/nginx/sites-enable/ نستخدم هذا الأمر للانتقال إليه:

cd /etc/nginx/sites-enabled

بافتراض أنّنا نريد إضافة SSL إلى ملف كتلة الخادوم الافتراضي default نفتح الملف من أجل تحريره:

sudo vi default

نبحث عن الأمر التوجيهي listen ونقوم بتعديله بحيث يبدو كما يلي:

listen 443 ssl;

نبحث بعدها عن الأمر التوجيهي server_name ونتأكد من أنّ قيمته مُطابِقة لاسم شهادتنا، نُضيف أيضًا الأوامر التوجيهيّة ssl_certificate و ssl_certificate_key لتحديد المسارات لشهادتنا وتحديد ملفّات المفاتيح الخاصّة (نضع الأسماء الموجودة لدينا بدلًا من example.com):

server_name example.com;
ssl_certificate /home/sammy/example.com.chained.crt;
ssl_certificate_key /home/sammy/example.com.key;

ولنسمح فقط بالشيفرات ciphers وميفاقات SSL protocols الأكثر أمانًا نُضيف الأسطر التالية إلى الملف:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;

إن أردنا إعادة توجيه المرور عبر HTTP إلى HTTPS نستطيع إضافة هذه الكتلة الإضافيّة للخادوم في أعلى الملف (نضع معلوماتنا بدلًا من example.com):

server {
  listen 80;
  server_name example.com;
  rewrite ^/(.*) https://example.com/$1 permanent;
}

نقوم بعدها بالحفظ والخروج.

نعيد تشغيل خادوم Nginx الآن لتحميل الإعدادات الجديدة وتمكين TLS/SSL عبر HTTPS:

sudo service nginx restart

نختبر ذلك بالوصول إلى موقعنا عبر HTTPS، على سبيل المثال https://example.com.

خادوم Apache

إن كنت ترغب باستخدام شهادتك مع خادوم Apache على Ubuntu فاتبع هذا القسم.

نقوم بعمل نسخة احتياطيّة لملف إعداداتنا عن طريق نسخه، وبافتراض أنّ خادومنا يعمل على ملف إعدادات المُضيف الوهمي virtual الافتراضي، etc/apache2/sites-available/000-default.conf/، نستخدم هذه الأوامر لعمل النسخة:

cd /etc/apache2/sites-available
cp 000-default.conf 000-default.conf.orig

نفتح بعدها الملف لتحريره:

sudo vi 000-default.conf

نبحث عن المُدخَل <VirtualHost *:80> ونقوم بتعديله بحيث يستمع خادوم الويب لدينا على المنفذ 443:

<VirtualHost *:443>

نقوم بعدها بإضافة الأمر التوجيهي ServerName إن لم يكن موجودًا مُسبقًا (نضع اسم نطاقنا هنا):

ServerName example.com

نضيف بعد ذلك الأسطر التالية لتحديد شهادتنا ومسارات المفاتيح (نضع مسارنا الفعلي هنا):

SSLEngine on
SSLCertificateFile /home/sammy/example.com.crt
SSLCertificateKeyFile /home/sammy/example.com.key

إن كُنّا نستخدم Apache 2.4.8 أو أكثر نُحدِّد حزمة الشهادة الوسيطة لسلطة الشهادات بإضافة هذا السطر (نضع المسار الفعلي لدينا):

SSLCACertificateFile /home/sammy/intermediate.crt

إن كُنّا نستخدم إصدار أقدم من Apache نُحدِّد حزمة الشهادة الوسيطة لسلطة الشهادات بإضافة هذا السطر (نضع المسار الفعلي لدينا):

SSLCertificateChainFile /home/sammy/intermediate.crt

عند هذه النقطة أصبح خادومنا مُعدًّا ليستمع إلى HTTPS فقط (المنفذ 443)، لذا لن يتم تخديم طلبات HTTP (المنفذ 80)، لإعادة توجيه طلبات HTTP إلى HTTPS نضيف ما يلي إلى أعلى الملف (نكتب اسم نطاقنا بدلًا من example.com):

<VirtualHost *:80>
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>

نقوم بالحفظ والخروج.

نقوم بتمكين وحدة Apache SSL بتنفيذ هذا الأمر:

sudo a2enmod ssl

نعيد تشغيل خادوم Apache الآن لتحميل الإعدادات الجديدة وتمكين TLS/SSL عبر HTTPS:

sudo service apache2 restart

نختبر ذلك بالوصول إلى موقعنا عبر HTTPS، على سبيل المثال https://example.com، نريد أيضًا اختبار الاتصال عبر HTTP، مثل http://example.com لنضمن أنّ إعادة التوجيه تعمل بشكل صحيح.

الخاتمة

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

ترجمة -وبتصرّف- لـ How To Install an SSL Certificate from a Commercial Certificate Authority لصاحبه Mitchell Anicas.

يتناول هذا الدرس تثبيت Nagios 4، وهو نظام مراقبة شائع ومفتوح المصدر، على Ubuntu 14.04. يغطي الدرس إعدادات أساسية لتتمكن من مراقبة موارد المضيفات Hosts في واجهة ويب. سنستخدم أيضا المشغل عن بعد لملحقات Nagios (يعرف بـ NRPE وهو اختصار لـNagios Remote Plugin Executor) الذي سيثبت ليكون وكيلا Agent على المضيفات البعيدة من أجل مراقبة مواردها المحلية.

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

المتطلبات

يتطلب اتباع الخطوات المشروحة في هذا الدرس امتلاك امتيازات المستخدم الأعلى (root) على خادوم Ubuntu 14.04 الذي سيشغل Nagios. من المستحسن استخدام حساب عادي بصلاحيات إدارية؛ لمعرفة كيفية إعداده راجع الخطوات من 1 إلى 3 في الدرس التالي: الإعداد الابتدائي لخادوم أوبنتو 14.04.

سنحتاج أيضا إلى حزمة برمجيات LAMP. يشرح الدرس التالي كيفية إعدادها: كيف تُثبِّت حِزم MySQL، Apache، Linux :LAMP وPHP على Ubuntu 14.04.

نفترض في المقال أن الخواديم توجد في شبكة محلية. أبدل جميع الإحالات إلى العناوين المحلية بعناوين IP عمومية إن كانت الخواديم التي تعدها لا توجد في نفس الشبكة المحلية.

نبدأ بالخطوة اﻷولى وهي تثبيت Nagios 4.

تثبيت Nagios 4

تغطي هذه الفقرة كيفية تثبيت Nagios 4 على خادوم المراقبة. لن تحتاج لإعادة تنفيذ الأوامر المذكورة هنا على خواديم أخرى.

إنشاء مستخدم Nagios ومجموعته

يجب أن ننشئ مستخدما ومجموعة تشغِّل عملية Nagios. أنشئ حساب مستخدم باسم nagios ومجموعة مستخدمين باسم nagcmd ثم أضف المستخدم للمجموعة:

sudo useradd nagios
sudo groupadd nagcmd
sudo usermod -a -G nagcmd nagios

تثبيت الارتباطات المطلوبة لبناء Nagios 4 من المصدر

يحتاج بناء Nagios 4 من المصدر، وهو ما سنفعله في هذا الدرس، إلى تثبيت بعض مكتبات التطوير التي تتيح بناء البرنامج. سنستغل الفرصة أيضا لتثبيت apache2-utils الذي سنستخدمه لإعداد واجهة الويب الخاصة بـNagios.

نبدأ بتحديث قائمة الحزم:

sudo apt-get update

ثم نثبت الحزم المطلوبة:

sudo apt-get install build-essential libgd2-xpm-dev openssl libssl-dev xinetd apache2-utils unzip

ننتقل لتثبيت Nagios.

تثبيت Nagios Core

نزل الشفرة المصدرية لآخر إصدار مستقر من Nagios Core. اذهب إلى صفحة تنزيلات Nagios وانقر على الرابط Skip to download (تجاوز إلى التنزيل) الموجود أسفل الاستمارة. انسخ رابط آخر إصدار مستقر لتتمكن من تنزيله على خادوم Nagios.

آخر إصدار وقت كتابة المقال هو 4.1.1؛ نزله إلى مجلدك الشخصي على خادوم المراقبة باستخدام curl:

cd ~
curl -L -O https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.1.1.tar.gz

استخرج الملف المضغوط:

tar xvf nagios-4.1.1.tar.gz

ثم انتقل إلى المجلد المستخرج:

cd nagios-4.1.1

يجب إعداد Nagios قبل بنائه. من أجل إعداد Nagios لاستخدام postfix (الذي يمكن تثبيته بapt-get) أضف with-mail=/usr/sbin/sendmail-- للأمر التالي:

./configure --with-nagios-group=nagios --with-command-group=nagcmd 

ثم نجمع Nagios بالأمر:

make all

يمكننا الآن استخدام اﻷوامر التالي لتثبيت Nagios، سكربتات بدء التشغيل وأمثلة لملفات الإعداد:

sudo make install
sudo make install-commandmode
sudo make install-init
sudo make install-config
sudo /usr/bin/install -c -m 644 sample-config/httpd.conf /etc/apache2/sites-available/nagios.conf

تجب إضافة حساب خادوم الويب www-data إلى المجموعة nagcmd لنتمكن من تنفيذ أوامر على Nagios من واجهة الويب:

sudo usermod -G nagcmd www-data

تثبيت ملحقات Nagios

تجد آخر الإصدارات من ملحقات Nagios على الرابط التالي: تنزيل ملحقات Nagios. انسخ عنوان رابط آخر إصدار حتى يمكنك تنزيله على خادوم Nagios.

آخر إصدار أثناء كتابة هذا المقال هو 2.1.1. نزله إلى مجلدك الشخصي على الخادوم باستخدام curl:

cd ~
curl -L -O http://nagios-plugins.org/download/nagios-plugins-2.1.1.tar.gz

استخر أرشيف ملحقات Nagios بالأمر التالي:

tar xvf nagios-plugins-2.1.1.tar.gz

ثم انتقل إلى المجلد المستخرَج:

cd nagios-plugins-2.1.1

يجب إعداد ملحقات Nagios قبل بنائها، نستخدم الأمر التالي لهذا الغرض:

./configure --with-nagios-user=nagios --with-nagios-group=nagios --with-openssl

نبني ملحقات Nagios:

make

ثم نثبتها بالأمر:

sudo make install

تثبيت NRPE (المشغل عن بعد لملحقات Nagios)

اعثر على الشفرة المصدرية لآخر إصدار مستقر من NRPE على صفحة تنزيلات NRPE. نزل آخر إصدار على خادوم Nagios.

آخر إصدار وقت كتابة هذا الدرس هو 2.15. نزله إلى مجلدك الشخصي على خادوم Nagios باستخدام أمر curl:

cd ~
curl -L -O http://downloads.sourceforge.net/project/nagios/nrpe-2.x/nrpe-2.15/nrpe-2.15.tar.gz

استخرج أرشيف NRPE بالأمر التالي:

tar xvf nrpe-2.15.tar.gz

ثم انتقل إلى المجلد المستخرج:

cd nrpe-2.15

نعدّ NRPE بالأوامر التالية:

./configure --enable-command-args --with-nagios-user=nagios --with-nagios-group=nagios --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/x86_64-linux-gnu

نأتي الآن لبناء NRPE وتثبيته إضافة لتثبيت سكربت بدء التشغيل xinetd:

make all
sudo make install
sudo make install-xinetd
sudo make install-daemon-config

افتح سكربت بدء التشغيل xinetd لتحريره:

sudo nano /etc/xinetd.d/nrpe

غيّر سطر only_from بإضافة عنوان IP المحلي الخاص بخادوم Nagios في آخر السطر، كما في المثال التالي:

only_from = 127.0.0.1 10.132.224.168

احفظ الملف ثم أغلقه. لن يُسمح، وفقا لهذا الإعداد، لغير خادوم Nagios بالتخاطب مع NRPE.

أعد تشغيل خدمة xinetd لبدء تشغيل NRPE:

sudo service xinetd restart

أكملنا الآن تثبيت Nagios 4، بقي إعداده.

إعداد Nagios

سنضبط في هذه الفقرة الإعداد الابتدائي لـNagios. ستحتاج لهذا الضبط مرة واحدة على خادوم Nagios.

تنظيم إعدادات Nagios

افتح ملف الإعداد الرئيس لـNagios لتحريره:

sudo nano /usr/local/nagios/etc/nagios.cfg

ابحث عن السطر التالي وأزل علامة التعليق (#):

#cfg_dir=/usr/local/nagios/etc/servers

احفظ الملف ثم أغلقه.

الخطوة التالية هي إنشاء المجلد الذي سيخزن ملفات إعداد الخواديم التي ستراقبها؛ ملف لكل خادوم:

sudo mkdir /usr/local/nagios/etc/servers

إعداد جهات الاتصال في Nagios

افتح ملف الإعداد الخاص بجهات اتصال Nagios لتحريره:

sudo nano /usr/local/nagios/etc/objects/contacts.cfg

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

email     nagios@localhost      ; <<***** أبدل هذا العنوان بعنوانك البريدي ******

احفظ الملف ثم أغلقه.

إعداد أمر check_nrpe

نضيف أمرا جديدا إلى ملف إعداد Nagios، لذا سنفتح لتحريره:

sudo nano /usr/local/nagios/etc/objects/commands.cfg

أضف الأسطر التالية:

define command{
  command_name check_nrpe
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

احفظ الملف ثم أغلقه. يتيح هذا الإعداد إمكانية استخدام الأمر check_nrpe في تعريف خدمات Nagios.

إعداد Apache

فعل وحدتيْ rewrite وcgi في Apache:

sudo a2enmod rewrite
sudo a2enmod cgi

استخدم أمر htpasswd لإنشاء حساب مدير باسم nagiosadmin يمكنه الوصول إلى واجهة ويب Nagios:

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

أدخل كلمة سر في المحث وتذكرها إذ ستحتاجها للوصول إلى واجهة ويب Nagios.

أنشئ وصلة رمزية Symbolic link لـnagios.conf في مجلد sites-enabled:

sudo ln -s /etc/apache2/sites-available/nagios.conf /etc/apache2/sites-enabled/

أصبح Nagios جاهزا للتشغيل. نشغل Nagios ونعيد تشغيل Apache:

sudo service nagios start
sudo service apache2 restart

نفذ الأمر التالي إن أردت تفعيل تشغيل Nagios مع بدء تشغيل الخادوم:

sudo ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

إعداد اختياري: تقييد الوصول بعنوان IP

إن أردت قصر عناوين IP التي يمكن منها الوصول إلى واجهة ويب Nagios فينبغي تحرير ملف إعداد Apache:

sudo nano /etc/apache2/sites-available/nagios.conf

اعثر على السطرين التاليين وأضف علامة # أمام كل واحد منهما لتعليقه:

Order allow,deny
Allow from all

ثم انزع التعليق عن الأسطر التالية بحذف علامة # وأضف عناوين IP (أو مجالات عناوين) التي تريد السماح لها بالوصول إلى الواجهة إلى سطر Allow from مع الفصل بينها بمسافة:

#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1

تظهر هذه الأسطر مرتين في ملف الإعداد لذا يجب عليك إعادة الخطوات أعلاه مرتين.

احفظ الملف ثم أغلقه.

نعيد تشغيل Nagios وApache لاعتماد التغييرات:

sudo service nagios restart
sudo service apache2 restart

يعمل Nagios الآن، فلنحاول الولوج إليه.

الوصول إلى واجهة ويب Nagios

أدخل عنوان خادوم Nagios في المتصفح (ضع عنوان IP أو اسم المضيف المناسب مكان nagios_server_public_ip):

http://nagios_server_public_ip/nagios

ستحتاج لإدخال بيانات الولوج نظرا لأننا استخدمنا htpasswd أثناء إعداد Apache (اسم المستخدم nagiosadmin وكلمة السر التي اخترتها):

تظهر الصفحة الرئيسية الافتراضية لـNagios بعد الولوج. انقر على رابط المضيفات في القائمة الجانبية على اليسار لمعرفة المضيفات التي يراقبها Nagios:

لا يراقب Nagios سوى مضيف واحد هو المضيف المحلي Localhost.

سنعد في ما يلي مضيفا آخر يراقبه Nagios.

مراقبة مضيف بـNRPE

سنرى في هذه الفقرة كيفية إضافة مضيف جديد إلى Nagios لتمكن بالتالي مراقبته. كرّر خطوات هذه الفقرة لكل خادوم تريد مراقبته.

نحدّث قائمة الحزم على الخادوم الذي نريد إضافته إلى Nagios:

sudo apt-get update

ثم نثبت ملحقات Nagios وNRPE:

sudo apt-get install nagios-plugins nagios-nrpe-server

إعداد المضيفات المسموح لها بالوصول

نفتح ملف إعداد NRPE:

sudo nano /etc/nagios/nrpe.cfg

اعثر على تعليمة allowed_hosts وأضف عنوان IP المحلي الخاص بخادوم Nagios إلى التعليمة كما في المثال التالي (انتبه للفاصلة):

allowed_hosts=127.0.0.1,10.132.224.168

احفظ الملف ثم أغلقه. يضبط الإعداد أعلاه NRPE لقبول الطلبات الواردة من خادوم Nagios عبر عنوانه المحلي.

إعداد أوامر NRPE المسموح بها

استخدم الأمر التالي لمعرفة اسم جذر نظام الملفات (واحد من العناصر التي نريد مراقبتها):

df -h /

سنستخدم اسم نظام الملفات في ملف إعداد NRPE من أجل مراقبة استخدام القرص الصلب. افترح ملف nrpe.cfg لتحريره:

sudo nano /etc/nagios/nrpe.cfg

يحوي ملف إعداد NRPE الكثير من التعليمات والأسطر، أغلبها معلَّق. توجد أسطر قليلة نحتاج للعثور عليها وتعديلها:

• server_address: تحدَّد قيمتها بعنوان IP المحلي للمضيف.
• allowed_hosts: تحدَّد قيمتها بعنوان IP المحلي لخادوم Nagios.
• [command[check_hda1: أبدل ` باسم نظام الملفات (نتيجة أمر df أعلاه، مثلا dev/vda/`).

يجب أن تبدو الأسطر المذكورة على النحو التالي (استخدم القيم المناسبة):

server_address=client_private_IP
allowed_hosts=nagios_server_private_IP
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/vda

توجد الكثير من الأوامر الأخرى المعرَّفة في هذا الملف. تعمل هذه الأوامر إذا أُعِدَّ Nagios لاستخدامها. انتبه إلى أن NRPE سينصت على المنفذ Port رقم 5666 لأن التعليمة server_port=5666 مفعَّلة. إن كان يوجد جدار ناري Firewall على خادوم Nagios فتأكد من السماح للاتصالات بالمرور عبر المنفذ 5666.

احفظ الملف ثم أغلقه.

إعادة تشغيل NRPE

أعد تشغيل NRPE لاعتماد التعديلات:

sudo service nagios-nrpe-server restart

تثبيت NRPE وإعداده على المضيف هو الخطوة الأولى لمراقبته. الخطوة الثانية هي إضافته إلى ملف إعداد Nagios لتبدأ المراقبة فعليا.

إدراج المضيف إلى إعداد Nagios

أنشئ ملف إعداد ضمن مسار /usr/local/nagios/etc/servers/ على خادوم Nagios لكل مضيف تريد مراقبته. أبدل yourhost باسم المضيف.

sudo nano /usr/local/nagios/etc/servers/yourhost.cfg

أضف تعريف المضيف التالي؛ مع إبدال قيمة host_name باسم المضيف البعيد (web-1 في المثال)، قيمة الكنية alias بوصف المضيف، وقيمة العنوان address بعنوان IP المحلي للمضيف البعيد:

define host {
use                             linux-server
host_name                       yourhost
alias                           My first Apache server
address                         10.132.234.52
max_check_attempts              5
check_period                    24x7
notification_interval           30
notification_period             24x7
}

يأمر الإعداد أعلاه Nagios بمراقبة ما إذا كان المضيف يعمل أم لا، لا غير. احفظ الملف ثم أغلقه وأعد تشغيل Nagios إن كان هذا كافيا بالنسبة لك؛ أما إذا كنت تريد مراقبة خدمات محدَّدة فواصل القراءة.

أضف تعريفات الخدمات التي تريد مراقبتها. في ما يلي أمثلة على مراقبة الخدمات؛ انتبه إلى أن قيمة check_command تحدد الخدمة المرادة مراقبتها والقيم التي تحدد حالة الخدمة:

• فحص الاتصال (أمر ping):

  define service {
    use generic-service
    host_name yourhost
    service_description PING
    check_command check_ping!100.0,20%!500.0,60%
  }
  

• خدمة SSH (إعطاء قيمة 0 لتعليمة notifications_enabled في تعريف الخدمة يعطل الإشعارات):

  define service {
    use generic-service
    host_name yourhost
    service_description SSH
    check_command check_ssh
    notifications_enabled 0
  }
  

تأخذ التعليمة use generic-service قيم قالب للخدمات معرَّف افتراضيا باسم generic-service.

احفظ الملف ثم أغلقه. أعد تحميل إعداد Nagios لاعتماد التعديلات:

sudo service nagios reload

تأكد بعد الانتهاء من إعداد جميع المضيفات من الوصول إلى واجهة ويب Nagios وافحص صفحة الخدمات لرؤية كل المضيفات والخدمات المراقبة.

خاتمة

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

ترجمة -وبتصرّف- لمقال How To Install Nagios 4 and Monitor Your Servers on Ubuntu 14.04 لصاحبه Mitchell Anicas.

سنتعلّم في هذا الدّرس المفاهيم الأساسيّة التي نحتاجها قبل الحصول على شهادة SSL من سلطة شهادات تجاريّة Commercial Certificate Authority CA، تسمح شهادات SSL لخواديم الويب بتشفير حركة مرور بياناتها traffic وتُوفِّر آليّة للتحقّق من هويّات الخواديم من أجل الزوّار، إنّ الميزة الأساسيّة لشراء شهادة SSL من سلطة شهادات تجاريّة (CA) موثوقة عن الشهادات المُوقَّعة ذاتيًّا self-signed أنّه لن يتم عرض تحذير مُخيف للزوّار حول عدم القدرة على التحقّق من هويّة موقعنا.

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

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

هنالك العديد من المتطلبات التي يجب التأكد منها قبل محاولة الحصول على شهادة SSL من سلطة شهادات تجاريّة، سيغطي هذا القسم الأمور التي نحتاجها ليتم إصدار شهادة SSL لنا من معظم سلطات الشهادات التجارية.

المال

يجب علينا شراء شهادات SSL الصادرة عن سلطات الشهادات التجاريّة، تتضمّن البدائل المجانيّة لها الشهادات المُوقَّعة ذاتيًّا self-signed أو شهادات StartSSL، ومع ذلك فإنّ الشهادات المُوقَّعة ذاتيًّا غير موثوقة من قبل أيّة برمجيات، ولا يُمكِن استخدام شهادات StartSSL لأغراض تجاريّة.

اسم نطاق Domain مسجل

ينبغي قبل الحصول على شهادة SSL أن نملك اسم نطاق مُسجَّل والذي نرغب باستخدام الشهادة معه، إن كُنّا لا نمتلك اسم نطاق مُسجَّل فبإمكاننا تسجيله باستخدام أحد مُسجِّلات اسم النطاق المتوفِّرة (مثل Namecheap، GoDaddy، إلخ..).

حقوق التحقق من النطاق

يجب من أجل العمليّة الأساسيّة للتحقّق من النطاق أن نملك نفاذًا إلى أحد عناوين البريد الإلكتروني على تسجيل WHOIS لنطاقنا أو إلى عنوان بريد إلكتروني من نمط مُدير admin على النطاق نفسه، تقوم سلطات الشهادات التي تُصدِر شهادات SSL نموذجيًّا بالتحقّق من التحكم بالنطاق عن طريق إرسال بريد إلكتروني للتحقّق إلى أحد عناوين البريد الإلكتروني على تسجيل WHOIS لنطاقنا، أو إلى عنوان بريد إلكتروني من نمط مدير عام على النطاق ذاته، توفّر بعض سلطات الشهادات طرق بديلة للتحقّق من النطاق، مثل DNS أو التحقّق المعتمد على HTTP والتي هي مواضيع خارج نطاق درسنا.

إن كنت ترغب في إصدار شهادة SSL مع تحقّق من المنظّمة (Organization Validation (OV أو تحقّق مُوسَّع (Extended Validation (EV فيجب عليك تزويد سلطات الشهادات بأوراقك لتأسيس هوية قانونيّة لمالك الموقع من بين الأشياء الأخرى.

خادوم الويب

سنحتاج بالإضافة للنقاط المذكورة سابقًا إلى خادوم ويب لتثبيت شهادة SSL عليه، وهو الخادوم القابل للوصول إليه عبر اسم النطاق الذي سنصدر شهادة SSL له، سيكون نموذجيًّا خادوم Apache HTTP، Nginx، HAProxy، أو Varnish، إن كنت تحتاج المساعدة في إعداد خادوم ويب قابل للوصول من خلال اسم النطاق المُسجَّل لديك فقم باتباع الخطوات التالية:

• إعداد خادوم ويب من اختيارك، على سبيل المثال خادوم (LEMP (Nginx أو (LAMP (Apache.
• إعداد النطاق ليستخدم أسماء الخواديم nameservers الملائمة.
• إضافة تسجيلات DNS records لخادوم الويب إلى أسماء الخواديم لديك.

اختيار سلطة الشهادات

إن لم تكن متأكّدًا من سلطة الشهادات التي تريد استخدامها فهنالك القليل من العوامل المهمّة التي يجب أن تأخذها بعين الاعتبار، وكنظرة عامّة فإنّ الشيء الأكثر أهمية أن تكون سلطة الشهادات التي تختارها تعطيك الميزات التي تريدها بالسعر الذي يناسبك، يُركّز هذا القسم بشكل أكبر على الميزات التي يجب أن يعلم بها مشترو شهادات SSL أكثر من الأسعار.

عضويات برنامج الشهادات الجذرية Root

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

إنّ أغلب سلطات الشهادات التي سنصادفها هي عضو من برامج الشهادات الجذريّة الشائعة، وستكون متوافقة مع 99% من المتصفحات، ولكن لن يضرّنا أن نتحقّق من ذلك قبل شراء الشهادة، تزوّدنا شركة Apple على سبيل المثال بلائحة من شهادات SSL الجذريّة الموثوقة لأجل IOS8 هنا.

أنواع الشهادات

يجب أن نتأكّد من اختيار سلطة شهادات تزوّدنا بنوع الشهادة الذي نريده، تُقدّم العديد من سلطات الشهادات أشكال مختلفة من أنواع الشهادات في إطار مجموعة من الأسماء والأسعار والتي كثيرًا ما تكون مربكة، وهذا وصف مختصر لكل نوع:

• نطاق مُفرَد Single Domain: يُستخدَم من أجل النطاق المُفرَد، مثل example.com، نلاحظ أنّه لا يتم تضمين النطاقات الفرعيّة subdomains مثل www.example.com
• Wildcard: تُستخدَم من أجل النطاق وأي نطاقات فرعيّة له، على سبيل المثال يُمكِن استخدام شهادة wildcard لِـ *.example.com أيضًا من أجل www.example.com وstore.example.com
• النطاقات المُتعدّدة Multiple Domain: وهي معروفة باسم شهادة SAN أو UC، ويمكن استخدامها مع النطاقات المُتعدّدة والنطاقات الفرعيّة التي تتم إضافتها إلى حقل الاسم البديل للموضوع Subject Alternative Name، فعلى سبيل المثال يُمكِن استخدام شهادة نطاقات متعدّدة مُفرَدة مع example.com، www.example.com، و example.net

وبالإضافة لأنواع الشهادات المذكورة آنفًا تُوجَد مستويات مختلفة من التحقّق التي توفّرها سلطات الشهادات، وسنتحدّث عنها هنا:

• التحقّق من النطاق (Domain Validation (DV: يتم إصدار شهادات DV بعد أن تتحقّق سلطة الشهادات أنّ طالب الشهادة يملك أو يتحكّم بالنطاق المطلوب.
• التحقّق من المُنظّمة (Organization Validation (OV: يُمكِن إصدار شهادات OV فقط بعد أن تتحقّق سلطة الشهادات من الهوية القانونية لطالب الشهادة.
• التحقّق المُوسَّع (Extended Validation (EV: يُمكِن إصدار شهادات EV فقط بعد أن تتحقّق سلطة الشهادات من الهوية القانونيّة لطالب الشهادة مع عدّة أشياء أخرى وفق مجموعة صارمة من الإرشادات، إنّ الغرض من هذا النوع من الشهادات هو توفير ضمان إضافي عن قانونيّة هوية مُنظّمتك بالنسبة لزوّار موقعك، يُمكِن أن تكون شهادات EV مُفردة أو متعدّدة النطاقات ولكن لا يمكن أن تكون wildcard.

ميزات إضافية

توفّر العديد من سلطات الشهادات مجموعة كبيرة ومتنوعة من الميزات الإضافيّة لتمييز نفسها عن بقيّة بائعي شهادات SSL، بعض هذه الميزات قد توفّر عليك المال، لذا من المهم أن تعرف احتياجاتك مقابل العروض قبل أن تقوم بالشراء، على سبيل المثال تشمل الميزات التي يجب البحث عنها إعادة إصدار شهادة مجانيّة أو شهادة بسعر شهادة نطاق مُفرَد وتعمل من أجل www. والاسم الأساسي للنطاق، مثل www.example.com مع شهادة SAN من example.com

الخاتمة

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

ترجمة -وبتصرّف- لـ How To Install an SSL Certificate from a Commercial Certificate Authority لصاحبه Mitchell Anicas.

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

سنشرح في هذا الدرس كيفية تثبيت عناصر الخادوم في Bacula على خادوم Ubuntu 14.04 وضبطها. سنعد Bacula لإنشاء شغل أسبوعي job ينشئ نسخة احتياطية محلية (أي على المضيف Host الذي يعمل عليه Bacula). لا يفرض Bacula نسخ البيانات محليَّا، إلا أننا بهذه الطريقة نوفر نقطة انطلاق جيدة لإنشاء نسخ احتياطية من خواديم أخرى يثبَّت عليها عميل Client لـ Bacula ويُضبط الاتصال بينه والخادوم.

المتطلبات

تتطلب خطوات المقال صلاحيات وصول المستخدم الأعلى (sudo) على خادوم Ubuntu 14.04. سيحتاج الخادوم أيضا لمساحة قرص صلب كافية لتخزين جميع النسخ الاحتياطية التي تخطط للإبقاء عليها ضمن حيز زمني محدَّد.

سنعد Bacula لاستخدام اسم نطاق معرَّف بالكامل Fully Qualified Domain Name, FQDN (راجع مقال مقدّمة إلى مُصطَلحات وعناصر ومفاهيم نظام أسماء النطاقات للمزيد عن اسم النطاق المعرَّف بالكامل)، على سبيل المثال bacula.private.example.com. استخدم عناوين IP المناسبة إن لم يكن لديك نظام لإدارة النطاقات. أبدل معلومات الاتصال بالشبكة الموجودة في هذا الدرس بعناوين شبكة يمكن لخواديمك الوصول إليها (عناوين IP أو أنفاق شبكات خاصة افتراضية)

نبدأ بعرض عام للعناصر المكوِّنة لـ Bacula.

نظرة عامة على عناصر Bacula

يتبع Bacula نموذج خادوم-عميل Server-client في النسخ الاحتياطي، ويتكون من عناصر برمجية مختلفة. سنركز في ما يلي على جزأيْ الخادوم والعميل بدلا من الحديث عن كل عنصر لوحده. إلا أنه يبقى من الأهمية بمكان أخذ معرفة سطحية بالعناصر المكونة للتطبيق.

يتكون خادوم Bacula (نشير إليه في بعض الأحيان بـ”خادوم النسخ الاحتياطي”) من العناصر التالية:

• مدير Bacula (يُشار إليه بـDIR): وهو البرنامج الذي يتحكم في عمليات النسخ الاحتياطي والإعادة التي تنفذها خدمتا File وStorage.
• خدمة التخزين Storage (يُشار إليها بـSD): برنامج يقرأ من أجهزة التخزين المستخدمة للنسخ الاحتياطي ويكتب فيها.
• برنامج الفهرس Catalog: خدمات تحتفظ بقاعدة بيانات للملفات المنسوخة احتياطا. تُستخدم قاعدة بيانات مثل MySQL أو PostgreSQL لهذا الغرض.
• وحدة تحكم Bacula: واجهة بسطر أوامر يتفاعل بواسطتها مسؤول النسخ الاحتياطي مع مدير Bacula ويتحكم فيه.

ملحوظة: ليس مفروضا تواجدُ جميع العناصر المكونة لخادوم Bacula على نفس الخادوم الحسي؛ إلا أنها جميعها تعمل معا لتوفير وظيفة خادوم النسخ الاحتياطي.

يشغِّل عميلُ Bacula (أي الخادوم الذي نريد أخذ نسخ احتياطية منه) خدمة File (يُشار إليها بـFD). هذا العنصر عبارة عن برنامج يتيح لخادوم Bacula (مدير Bacula تحديدا) الوصول إلى البيانات التي ستُنسَخ. نسمي الخواديم التي نريد أخذ نسخ منها “عملاء النسخ الاحتياطي” أو “العملاء”.

سنعدّ مثل ما أشرنا في المقدمة، خادوم النسخ الاحتياطي لإنشاء نسخة احتياطية من نظام ملفاته الخاص؛ وهو ما يعني أن خادوم النسخ الاحتياطي سيكون أيضا عميل نسخ احتياطي وبالتالي سيشغل خدمة File.

نبدأ بالتثبيت.

تثبيت MySQL

يستخدم Bacula قاعدة بيانات SQL مثل MySQL وPostgreSQL لإدارة الفهرس. سنستخدم MySQL في هذا الدرس.

نبدأ بتحديث الحزم:

$ sudo apt-get update

ثم نثبت خادوم MySQL:

$ sudo apt-get install mysql-server

سيُطلَب منك إدخال كلمة سر خاصة بالحساب الإداري root لـMySQL. أدخل كلمة سر ثم أكدها. ستحتاج لكلمة السر هذه أثناء تثبيت Bacula.

تثبيت Bacula

ننفذ الأمر التالي لتثبيت العناصر المكونة لخادوم Bacula وعميله:

$ sudo apt-get install bacula-server bacula-client

سيُطلب منك إدخال معلومات ستُستخدم لإعداد Postfix الذي يستخدمه Bacula:

• النوع العام لإعداد البريد General Type of Mail Configuration: اختر Internet Site.
• اسم نظام البريد: أدخل اسم النطاق الكامل لخادومك أو اسم المضيف.

في الخطوة الموالية تُطلب معلومات تستخدم لإعداد قاعدة بيانات Bacula:

• اختر Yes بالنسبة لخيار Configure database for bacula-director-mysql with dbconfig-common.
• أدخل كلمة سر الحساب الإداري لـMySQL ثم أكدها (خيار Password of the database's administrative user).
• أدخل كلمة سر جديدة وأكدها عند خيار MySQL application password for bacula-director-mysql أو اتركها فارغة لتوليد كلمة سر عشوائية.

الخطوة الأخيرة في عملية التثبيت هي تحديث أذون السكربت الذي يستخدمه Bacula أثناء شغل فهرس النسخ الاحتياطي:

$ sudo chmod 755 /etc/bacula/scripts/delete_catalog_backup

ننتقل الآن، بعد تثبيت الخادوم والعميل الخاصين بـBacula إلى إنشاء مجلدات النسخ الاحتياطي والإعادة.

إنشاء مجلدات النسخ الاحتياطي والإعادة

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

$ sudo mkdir -p /bacula/backup /bacula/restore

نعدّل أذون الملف لكي يقتصر إذن الوصول للمجلدات على عمليّة bacula (والمستخدم الأعلى):

$ sudo chown -R bacula:bacula /bacula
$ sudo chmod -R 700 /bacula

بهذا نكون جاهزين لإعداد مدير Bacula.

إعداد مدير Bacula

يتكون Bacula من عناصر عدة يجب إعداد كل واحد منها على حدة ليعمل بطريقة صحيحة. توجد جميع ملفات الإعداد في المجلَّد etc/bacula/.

نبدأ بمدير Bacula.

افتح ملف إعداد المدير لتحريره:

$ sudo nano /etc/bacula/bacula-dir.conf

إعداد الأشغال المحلية

يُستخدَم شغل Bacula لـتنفيذ إجراءات النسخ الاحتياطي والإعادة. تعرِّف موارد الشغل تفاصيل ما يفعله شغلٌ مّا. تتضمن تفاصيل الشغل اسم العميل، مجموعة الملفات FileSet المُراد نسخها أو إعادتها وأمورا أخرى.

سنعد هنا الأشغال التي سنستخدمها لنسخ نظام الملفات المحلي.

ابحث في ملف bacula-dir.conf عن مورد الشغل ذي الاسم BackupClient1. غير قيمة Name لتصبح BackupLocalFiles:

Job {
  Name = "BackupLocalFiles"
  JobDefs = "DefaultJob"
}

ابحث الآن عن مورد الشغل RestoreFiles. يجب أن تعدِّل قيمتين في هذا المورد: غير قيمة Name لتصبح RestoreLocalFiles وقيمة Where لتصبح bacula/restore/. يبدو الملف بعد التعديل على النحو التالي:

Job {
  Name = "RestoreLocalFiles"
  Type = Restore
  Client=BackupServer-fd
  FileSet="Full Set"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /bacula/restore
}

تعد هذه التعليمات شغل RestoreLocalFiles لإعادة الملفات إلى المجلَّد bacula/restore/ الذي أنشأناه سابقا.

إعداد مجموعة الملفات

تعيّن مجموعة ملفات Bacula - كما يشير الاسم - مجموعة ملفات أو مجلدات للتضمين أو الإبعاد من النسخ الاحتياطية.

ابحث عن مجموعة ملفات FileSet باسم Full Set (توجد تحت التعليق # List of files to be backed up أي قائمة جميع الملفات المراد نسخها). سنجري ثلاثة تعديلات:(1) إضافة خيار استخدام gzip لضغط النسخ الاحتياطية، (2) تغيير الملفات المضمّنة من usr/sbin/ إلى / و(3) تغيير الملفات المبعدة وإضافة المسار bacula/. يبدو المورد بعد نزع التعليقات على النحو التالي:

FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }    
    File = /
  }
  Exclude {
    File = /var/lib/bacula
    File = /bacula
    File = /proc
    File = /tmp
    File = /.journal
    File = /.fsck
 }
}

أولا، تفعِّل التعليمات استخدام gzip لضغط الملفات أثناء إنشاء النسخ الاحتياطية؛ ثم تضيف الجذر / إلى الملفات المُراد نسخها (أي جميع ملفات التجزئة). وأخيرا تبعد المجلّد bacula/ من النسخة الاحتياطية لكي لا نعيد نسخ النسخ الاحتياطية السابقة والملفات المُعادة.

ملحوظة: إن رغبت في إضافة تجزئات مركَّبة Mounted partitions في / إلى مجموعة الملفات فيجب إضافة تعليمة File لكل واحدة منها.

تذكر أن النسخ الاحتياطية ستحتاج، عند استخدام مجموعات ملفات كبيرة مثل Full Set في أشغال النسخ الاحتياطي، مساحة أكبر على القرص الصلب مما لو كان اختيار ملفات النسخ أكثر تحديدا. على سبيل المثال، إن كان لديك مخطّط إعادة Recovery plan يحدد الحزم البرمجية الواجب تثبيتها والأماكن التي يجب وضع الملفات المعادة فيها؛ فإن مجموعة ملفات لا تتضمن سوى ملفات الإعداد المخصَّص وقواعد البيانات تكفي لاحتياجاتك ولا تستخدم سوى جزء يسير من القرص الصلب لتخزين أرشيف النسخ الاحتياطية.

إعداد الاتصال الخاص بخدمة التخزين Storage

يعرّف مورد Storage في ملف إعداد المدير خدمة التخزين التي يجب على مدير Bacula الاتصال بها. سنضبُط خدمة التخزين في ما بعد.

اعثُر على مورد Storage وأبدل قيمة Address (أي localhost) باسم النطاق الكامل FQDN المحلي (أو عنوان IP المحلي) لخادوم النسخ الاحتياطي. يبدو الملف بعد التعديل كالتالي (أبدل :

Storage {
   Name = File
   # Do not use "localhost" here
   Address = backup_server_private_FQDN                # N.B. Use a fully qualified name here
   SDPort = 9103
   Password = "ITXAsuVLi1LZaSfihQ6Q6yUCYMUssdmu_"
   Device = FileStorage
   Media Type = File
}

سنعد خدمة التخزين للإنصات لواجهة الشبكة المحلية حتى يتسنى للعملاء الاتصال بها، لذا من المهم إعداد المورد لاستخدام العنوان المحلي لخادوم النسخ الاحتياطي.

إعداد مجمع تخزين Storage pool

يعرف مورد Pool وسائط التخزين التي سيخزن عليها Bacula النسخ الاحتياطية. سنتعامل مع ملفات كما لو كانت تجزئات للتخزين ثم نحدث اللصيقة Label لتوصيف النسخ الاحتياطية المحلية.

ابحث عن مورد Pool باسم File (توجد تحت التعليق # File Pool definition) وأضف سطرا لتحديد صيغة اللصيقة. يبدو المورد، بعد التعديل، على النحو التالي:

# File Pool definition
Pool {
   Name = File
   Pool Type = Backup
   Label Format = Local-
   Recycle = yes                       # Bacula can automatically recycle Volumes
   AutoPrune = yes                     # Prune expired volumes
   Volume Retention = 365 days         # one year
   Maximum Volume Bytes = 50G          # Limit Volume size to something reasonable
   Maximum Volumes = 100               # Limit number of Volumes in Pool
}

احفظ الملف ثم أغلقه. بهذا يكتمل إعداد مدير Bacula.

التحقق من إعدادات مدير Bacula

نتحقق من عدم وجود أخطاء صياغة في ملف إعداد المدير DIR:

$ sudo bacula-dir -tc /etc/bacula/bacula-dir.conf

إن لم تظهر رسائل خطأ فملف الإعداد نظيف من أخطاء الصياغة.

ننتقل لإعداد خدمة التخزين SD.

إعداد خدمة التخزين

نحتاج لإعداد خدمة التخزين حتى يعرف خادوم Bacula أين يخزّن النسخ الاحتياطية.

افتح ملف إعداد التخزين لتحريره:

$ sudo nano /etc/bacula/bacula-sd.conf

إعداد مورد Storage

اعثر على مورد Storage في ملف الإعداد الذي فتحته للتو. يعرّف هذا المورد العنوان الذي تنصت خدمة التخزين للاتصالات القادمة منه. أضف معطى SDAddress وحدد قيمته بالنطاق الكامل (أو عنوان IP) المحلي لخادوم النسخ الاحتياطي:

Storage {                             # definition of myself
  Name = BackupServer-sd
  SDPort = 9103                  # Director's port
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 20
  SDAddress = backup_server_private_FQDN
}

إعداد وسيط التخزين

اعثر على مورد Device باسم FileStorage وحدث قيمة Archive Device لتوافق مجلد النسخ الاحتياطي لديك:

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /bacula/backup 
  LabelMedia = yes;                   # lets Bacula label unlabeled media
  Random Access = Yes;
  AutomaticMount = yes;               # when device opened, read it
  RemovableMedia = no;
  AlwaysOpen = no;
}

احفظ الملف ثم أغلقه.

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

ننفذ الأمر التالي للتحقق من عدم وجود أخطاء صياغة في ملف الإعداد الخاص بخدمة التخزين:

$ sudo bacula-sd -tc /etc/bacula/bacula-sd.conf

إن لم تظهر رسائل خطأ فملف الإعداد نظيف من أخطاء الصياغة.

أكملنا إعداد Bacula وأصبحنا جاهزين لإعادة تشغيل عناصر خادوم Bacula.

إعادة تشغيل مدير Bacula وخدمة التخزين

نعيد تشغيل مدير Bacula وخدمة التخزين لاعتماد تعديلات الإعدادات:

$ sudo service bacula-director restart
$ sudo service bacula-sd restart

نجرب، بعد إعادة تشغيل الخدمتين، عمل خادوم Bacula بإنشاء شغل نسخ احتياطي.

اختبار شغل للنسخ الاحتياطي

نستخدم وحدة تحكم Bacula لتشغيل أول شغل للنسخ الاحتياطي؛ إن عمل دون مشاكل فسنتأكد أن Bacula مضبوط بطريقة صحيحة.

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

$ sudo bconsole

ستُنقَل إلى محثّ Prompt وحدة تحكم Bacula المُشار إليه ب*.

إنشاء لصيقة

ابدأ بتنفيذ أمر label:

* label

سيُطلب منك إدخال اسم للتجزئة:

Enter new Volume name:
MyVolume

ثم اختر مجمع التخزين الذي تريد أن يستخدم للنسخ الاحتياطية. سنختار File الذي أعددناه سابقا بإدخال الرقم 2:

Select the Pool (1-3):
2

التشغيل اليدوي لشغل نسخ احتياطي

أعطينا Bacula المعلومات الكافية ليعرف كيف يخزن بيانات النسخ الاحتياطية، ويمكن بالتالي تشغيل النسخ الاحتياطي لمعرفة ما إذا كان يعمل بطريقة صحيحة:

* run

سيطلب منك اختيار الشغل الذي تريد تشغيله. نريد تشغيل BackupLocalFiles لذا سنختار 1:

Select Job resource (1-3):
1

راجع التفاصيل في محث التأكيد Run Backup job ثم اختر Yes للتشغيل:

* yes

فحص الرسائل والحالة

سيخبرك Bacula بعد تشغيل شغل للنسخ الاحتياطي أن لديك رسائل، وهي مخرجات ولّدتها الأشغال الجارية. افحص الرسائل بتنفيذ الأمر:

* messages

يجب أن تظهر رسالة No prior Full backup Job record found (أي لم يُعثر على سجل لنسخة احتياطية كاملة سابقة) وأخرى تخبرك ببدء الشغل. ستظهر رسائل خطأ في حال وجود مشاكل مع تلميحات لأسبابها، لماذا لم ينفَّذ الشغل مثلا.

توجد طريقة أخرى لمعرفة حالة الشغل وهي فحص حالة المدير. لاستعمال هذه الطريقة أدخل اﻷمر التالي في محث وحدة التحكم bconsole:

* status director

إن كان كل شيء جرى على ما يرام فسترى أن الشغل يعمل. ستظهر مخرجات تشبه التالي:

Running Jobs:
Console connected at 09-Apr-15 12:16
JobId Level   Name                       Status
======================================================================
3 Full    BackupLocalFiles.2015-04-09_12.31.41_06 is running
====

ستنتقل وحدة التحكم إلى فقرة Terminated Jobs (أشغال مكتملة) من تقرير الحالة عند انتهاء تنفيذ الشغل. تظهر المخرجات بما يشبه التالي:

Terminated Jobs:
JobId  Level    Files      Bytes   Status   Finished        Name
====================================================================
3  Full    161,124    877.5 M  OK       09-Apr-15 12:34 BackupLocalFiles

تشير الحالة OK إلى أن شغل النسخ الاحتياطي عمل دون مشاكل.

الخطوة التالية هي اختبار شغل الإعادة.

اختبار شغل الإعادة

من المهم بعد إنشاء النسخ الاحتياطية اختبار إمكانية إعادتها على نحو سليم. يمكن أمر restore من إعادة الملفات التي نسخناها احتياطا.

تنفيذ الشغل Restore All

سنعيد جميع الملفات الموجودة في آخر نسخة احتياطية، لذا نستخدم الأمر:

* restore all

ستظهر قائمة بها خيارات متعددة تستخدم لتعريف أي مجموعة نسخ احتياطية نعيد الملفات منها. بما أنه لا توجد لدينا سوى نسخة واحدة فسنحدد الخيار 5 Select the most recent backup (اختر النسخة الاحتياطية الأحدث):

Select item (1-13):
5

بما أنه لا يوجد سوى عميل واحد وهو خادوم Bacula فسيُختار.

المحث التالي يسأل عن مجموعة الملفات التي تريد استخدامها. اختر Full Set أي الرقم 2:

Select FileSet resource (1-2):
2

سيُحيلك الخيار إلى شجرة افتراضية للملفات يوجد بها تخطيط كامل للمجلد الذي نسخته احتياطا. تسمح هذه الواجهة التي تشبه Shell بتحديد الملفات المرادة إعادتها أو نزع تحديدها.

بما أننا نفذنا أمر restore all (إعادة الجميع) فإن كل ملف في المخطّط الشجري محدَّد لإعادته. تسبق علامة * الملفات المحدّدة.

إن أردت تخصيص الاختيار فيمكن التنقل في قائمة الملفات باستخدام الأمرين ls وcd، تحديد الملفات بmark ونزع تحديدها بunmark. تحصل على قائمة بجميع الأوامر المتاحة عند تنفيذ الأمر help (مساعدة) في وحدة التحكم.

لبدء عملية الإعادة، بعد الانتهاء من تحديد الملفات، نفذ الأمر:

* done

أكد رغبتك في تنفيذ شغل الإعادة:

OK to run? (yes/mod/no):
yes

فحص الرسائل والحالة

ندقق، مثل ما فعلنا مع شغل النسخ الاحتياطي، في رسائل مدير Bacula وحالته بعد تنفيذ شغل الإعادة. افحص الرسائل بتنفيذ:

* messages

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

* status director

نفذ الأمر exit للخروج من وحدة تحكم Bacula بعد الانتهاء من إعادة الملفات:

* exit

التحقق من إعادة الملفات

يمكن بالنظر إلى المجلد bacula/restore/ (عرّفناه ضمن شغل RestoreLocalFiles في إعداد مدير Bacula) التحقق من أن شغل الإعادة أرجع فعلا الملفات المحدَّدة:

$ sudo ls -la /bacula/restore

يجب أن تظهر الملفات المُعادة في جذر نظام الملفات مع إبعاد الملفات والمجلدات الموجودة في فقرة Exclude من شغل RestoreLocalFiles. يجب أن تنسخ الملفات المعادة من النسخ الاحتياطية، عند إرجاع بيانات مفقودة، إلى أماكنها المناسبة (وضع ملفات الإعداد مثلا في المجلد المناسب حسب البرنامج أو التطبيق).

حذف الملفات المعادة

نفذ الأمر التالي إن أردت حذف الملفات المعادة، لإخلاء مساحة في القرص الصلب:

$ sudo -u root bash -c "rm -rf /bacula/restore/*"

يجب تنفيذ أمر rm بصلاحيات root إذ أن الكثير من الملفات المعادة يمتلكها المستخدم الأعلى.

خاتمة

يكون لديك باتباع الخطوات المشروحة في هذا المقال إعداد أساسي لـBacula يمكن من نسخ نظام الملفات المحلي وإعادته. الخطوة الموالية هي إضافة خواديم عميلة لتتمكن من إرجاع بياناتها في حال فقدان ملفات من النظام.

ترجمة -وبتصرف- للمقال How To Install Bacula Server on Ubuntu 14.04 لصاحبه Mitchell Anicas.

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

سنعد في هذا الدليل حزمة برامج ELK، ونعني بها Logstash، Elasticsearch وKibana؛ ثم نعد مختلف الخواديم المكونة لبيئة الإنتاج حتى ترسل السجلات المناسبة إلى خادوم السجلات. سنعد أيضا مُرشِحات Filters في Logstash من أجل تجزئة السجلات وهيكلتها وهو ما يسهِّل عملية البحث في السجلات وترشيحها ثم استخدام Kibana لمعاينتها.

المتطلبات

يجب، إن أردت الوصول إلى لوحة المراقبة عبر نطاق خاص مثل logging.example.com، إنشاء سجل من نوع A ضمن إعدادات النطاق يحيل إلى عنوان IP العمومي الخاص بخادوم السجلات. أو يمكنك بدلا من ذلك الوصول إلى لوحة التسجيلات باستخدام عنوان الخادوم العمومي. يُنصح بإعداد خادوم السجلات لاستخدام HTTPS وتقييد الوصول إليه بوضعه في شبكة خاصة افتراضية.

تثبيت حزمة ELK على خادوم السجلات

اضبط حزمة ELK على خادوم السجلات باتباع خطوات درس كيف تثبت Logstash، Elasticsearch وKibana 4 على خادوم Ubuntu 14.04. تأكد من اتباع الخيار رقم 2 في فقرة توليد شهادات SSL.

توقف عند الوصول إلى فقرة ضبط معيد توجيه Logstash.

إعداد معيدي توجيه Logstash على العملاء

اضبط معيد توجيه Logstash (مُرسِل للسجلات) على الخواديم العميلة (مثلا db1، app2، app1 وlb1) باتباع فقرة ضبط معيد توجيه Logstash في درس ELK.

سيمكنك بعد إكمال الإعداد الدخولُ إلى Kibana عبر العنوان العمومي لخادوم السجلات وعرض سجلات النظام الخاصة بخواديمك.

تحديد السجلات المراد جمعها

تتيح برامج ELK الكثير من السجلات لجمعها، حسب نوعية البرامج المثبتة على الخواديم وإعدادها. سنجمع، في مثالنا، السجلات التالية:

• سجل الاستعلامات Queries البطيئة في MySQL (الخادوم db1).
• سجلات الأخطاء والوصول في Apache (على الخادومين app1 وapp2).
• سجلات HAProxy (خادوم توزيع الحمل lb1).

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

إعداد سجلات MySQL

يحفظ MySQL الاستعلامات البطيئة في سجل على المسار var/log/mysql/mysql-slow/. يتضمن السجل الاستعلامات التي أخذت وقتا طويلا للتنفيذ؛ يمكن أن يساعد تحديد هذه الاستعلامات في تحسين التطبيق والبحث عن علله وإصلاحها.

تفعيل تسجيل الاستعلامات البطيئة في MySQL

تسجيل الاستعلامات البطيئة في MySQL غير مفعَّل في الإعدادات الافتراضية؛ لذا سنحتاج لتفعيله.

افتح ملف إعدادات MySQL لتحريره:

sudo nano /etc/mysql/my.cnf

ابحث عن التعليمة log_slow_queries وانزع علامة التعليق # الموجودة أمامها ليصبح السطر على النحو التالي:

log_slow_queries        = /var/log/mysql/mysql-slow.log

احفظ الملف ثم أغلقه. تجب إعادة تشغيل MySQL لاعتماد التغييرات:

sudo service mysql restart

سيبدأ MySQL الآن في تسجيل الاستعلامات التي تأخذ وقتا طويلا للتنفيذ. ملف السجل يوجد على المسار المحدّد في الإعداد.

إرسال ملفات سجلات MySQL

يجب إعداد معيد التوجيه في Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات. حرر ملف إعداد معيد التوجيه على خادوم قاعدة البيانات db1:

sudo nano /etc/logstash-forwarder.conf

أضف الأسطر التالية في آخر فقرة files لإرسال الاستعلامات البطيئة إلى خادوم السجلات وتحديد نوع السجل ب mysql-slow

,
{
  "paths": [
     "/var/log/mysql/mysql-slow.log"
  ],
  "fields": { "type": "mysql-slow" }
}

احفظ الملف ثم أغلقه. تعد التعليمات السابقة معيد توجيه Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات وتعليمها بmysql-slow. سنستخدم نوع السجل لاحقا في الترشيح.

أعد تشغيل معيد التوجيه للبدء في إرسال السجلات:

sudo service logstash-forwarder restart

مرماز Codec المدخلات متعددة الأسطر

سنحتاج لتفعيل مرماز تعدد الأسطر في Logstash لمعالجة سجلات الاستعلامات البطيئة في MySQL التي تأتي على أسطر متعددة. افتح ملف الإعدادات الذي يعرِّف مدخل Lumberjack على خادوم logging:

sudo nano /etc/logstash/conf.d/01-lumberjack-input.conf

أضف الأسطر التالية إلى تعريف lumberjack:

codec => multiline {
  pattern => "^# User@Host:"
  negate => true
  what => previous
}

احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لاستخدام معالج السجلات متعددة الأسطر عند العثور على سجلات تحتوي على النمط Pattern المُحدَّد (أي تلك التي تبدأ ب # User@Host: ).

في ما يلي سنضبط مرشح Logstash لسجلات MySQL.

مرشح سجلات MySQL

افتح ملفا جديدا على خادوم السجلات logging لإضافة مرشحات لسجل MySQL. سنسمي الملف 11-mysql.conf لكي يُقرأ بعد إعداد مدخلات Logstash (موجودة في ملف 01-lumberjack-input.conf):

sudo nano /etc/logstash/conf.d/11-mysql.conf

أضف تعريف المرشح التالي:

filter {
   # يسجل المستخدم واختياريا اسم المستضيف وعنوان IP
   if [type] == "mysql-slow" {
      grok {
        match => [ "message", "^# User@Host: %{USER:user}(?:\[[^\]]+\])?\s+@\s+%{HOST:host}?\s+\[%{IP:ip}?\]" ]
      }
   # يسجل مدة تنفيذ الاستعلام، مدة قفل السطر في قاعدة البيانات، الأسطر المُرجعة في النتيجة والأسطر المفحوصة. 

     grok {
       match => [ "message", "^# Query_time: %{NUMBER:duration:float}\s+Lock_time: %{NUMBER:lock_wait:float} Rows_sent: %{NUMBER:results:int} \s*Rows_examined: %{NUMBER:scanned:int}"]
     }
   # يسجل وقت حدوث الاستعلام
      grok {
         match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ]
      }
    # يستخرج الوقت اعتمادا على وقت الاستعلام بدلا من وقت إدراج العنصر في السجلات

      date {
         match => [ "timestamp", "UNIX" ]
      }
    # يحذف حقل الختم الزمني من السجل نظرا لتسجيل وقت الحدث (الاستعلام)
      mutate {
         remove_field => "timestamp"
      }
   }
}

احفظ الملف ثم أغلقه. تعد التعليمات Logstash لترشيح السجلات من نوع mysql-slow باستخدام أنماط Grok المحددة في تعليمات match. راجع التعليقا فوق كل تعليمة لأخذ نبذة عن عملها.

لكي تبدأ هذه المرشحات عملها يجب أن نعيد تشغيل Logstash:

sudo service logstash restart

يجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله.

يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات MySQL المرشحة.

سجلات Apache

توجد سجلات Apache عادة على المسار var/log/apache2/ باسم access.log و error.log. يتيح لك جمع هذه السجلات معرفة عناوين IP التي تتصل بخواديمك، طلبات هذه العناوين ونوعية المتصفحات ونظم التشغيل المستخدمة في الاتصال؛ بالإضافة إلى الأخطاء التي يبلغ عنها Apache.

إرسال سجلات Apache

نضبط معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم logging.

نفذ الأمر التالي على كل واحد من خادومي التطبيق، app1 وapp2 لفتح ملف إعاد الخاص بمعيد توجيه Logstash:

sudo nano /etc/logstash-forwarder.conf

أضف ما يلي ضمن فقؤة files تحت التعليمات الموجودة:

,
{
   "paths": [
       "/var/log/apache2/access.log"
    ],
   "fields": { "type": "apache-access" }
},
{
   "paths": [
      "/var/log/apache2/error.log"
    ],
    "fields": { "type": "apache-error" }
}

احفظ الملف ثم أغلقه. تعد هذه التعليمات معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم السجلات، ثم تعليم كل سجل بنوعه (أي apache-access بالنسبة للوصول وapache-error بالنسبة للأخطاء).

أعد تشغيل معيد التوجيه للبدء في إرسال السجلات:

sudo service logstash-forwarder restart

إذا تركنا الإعداد الحالي فستُظهر كل سجلات Apache عنوان IP الخاص لخادوم HAProxy بوصفه عنوان المصدر. يعود السبب في ذلك إلى أن الخادوم الوسيط lb1 هو الوسيلة الوحيدة للوصول إلى خواديم التطبيق من الإنترنت. يمكن تغيير هذا الأمر بإعداد الصيغة الافتراضية لسجل Apache بحيث يستخدم الرأسيات X-Forwarded-For التي يرسلها HAProxy.

افتح ملف إعداد Apache على كل واحد من خادومي التطبيقات:

sudo nano /etc/apache2/apache2.conf

ابحث عن سطر يظهر على النحو التالي:

[Label apache2.conf — Original "combined" LogFormat]
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

أبدل:

 h% ب%{X-Forwarded-For}i 

لكي تصبح هيئة السطر كالتالي:

[Label apache2.conf — Updated "combined" LogFormat]
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

احفظ الملف ثم أغلقه. بهذا نكون أعددنا سجلات Apache لتضمين عنوان IP المصدر الفعلي بدلا من عنوان IP الخاص لخادوم توزيع الحمل.

أعد تشغيل Apache لاعتماد التغييرات:

sudo service apache2 restart

نحن الآن جاهزون لإضافة مرشحات لسجلات Apache في Logstash.

مرشحات سجلات MySQL

ننشئ ملف إعداد جديدا على خادوم السجلات logging من أجل إضافة مرشحات لسجل Apache إلى Logstash. سنسميه 12-apache.conf لكي يقرأه Logstash بعد ملف إعداد المُدخلات (أي ملف 01-lumberjack-input.conf):

sudo nano /etc/logstash/conf.d/12-apache.conf

أضف تعريفات المرشحات التالية:

filter {
   if [type] == "apache-access" {
     grok {
       match => { "message" => "%{COMBINEDAPACHELOG}" }
     }
   }
}
filter {
   if [type] == "apache-error" {
     grok {
         match => { "message" => "\[(?<timestamp>%{DAY:day} %{MONTH:month} %{MONTHDAY} %{TIME} %{YEAR})\] \[%{DATA:severity}\] \[pid %{NUMBER:pid}\] \[client %{IPORHOST:clientip}:%{POSINT:clientport}] %{GREEDYDATA:error_message}" }
     }
  }
}

احفظ الملف ثم أغلقه. تعد هذه التعليمات Logstash لاستخدام مرشحات Grok لتحليل سجلات الوصول والأخطاء في Apache. يعرف كل مرشح صيغة السجلات التي يتعامل معها ضمن تعليمة match الموجودة في المرشح الموافق لنوع السجل في الاسم. يُستخدم مرشح Grok يوفره Logstash لتحليل سجلات الوصول إلى Apache اعتمادا على الصيغة الافتراضية لهذه السجلات؛ بينما كتبنا مرشح Grok خاص لتحليل الصيغة الافتراضية لسجل الأخطاء في Apache.

نعيد تشغيل Logstash لكي تبدأ المرشحات الجديدة عملها:

sudo service logstash restart

يجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات Apache المرشحة.

سجلات HAProxy

يسمح جمع سجلات موزع الحمل HAProxy (توجد عادة في الملف var/log/haproxy.log/) بمعرفة عناوين IP التي تتصل بخادوم توزيع الحمل، ماذا تطلب، خادوم التطبيق الذي يجيب على الطلب، ومعلومات مفصَّلة أخرى عن الاتصال.

إرسال ملفات السجلات الخاصة بHAProxy

نضبط معيد توجيه Logstash لإرسال سجلات HAProxy إلى خادوم السجلات بنفس طريقة الإعداد التي اتبعناها مع الخواديم السابقة. افتح الملف التالي على خادوم توزيع الحمل lb1:

sudo nano /etc/logstash-forwarder.conf

أضف الأسطر التالية إلى فقرة files تحت التعليمات الموجودة سلف. ترسل التعليمات الجديدة سجلات HAProxy إلى خادوم Logstash وتحدد نوعها بـ haproxy-log.

,
{
    "paths": [
       "/var/log/haproxy.log"
     ],
    "fields": { "type": "haproxy-log" }
}

احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لإرسال سجلات HAProxy مع تحديد نوعها بhaproxy-log. يستخدَم النوع في ما بعد لترشيح السجلات.

أعد تشغيل معيد توجيه في Logstash للبدء في إرسال السجلات:

sudo service logstash-forwarder restart

مرشح سجلات HAProxy

افتح ملفا جديدا على خادوم logging لإضافة مرشح سجلات HAProxy إلى Logstash. سنسمي الملف الجديد 13-haproxy.conf:

sudo nano /etc/logstash/conf.d/13-haproxy.conf

أضف تعريف المرشح التالي:

filter {
    if [type] == "haproxy-log" {
      grok {
         match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{SYSLOGPROG}: %{IPORHOST:clientip}:%{POSINT:clientport} \[%{MONTHDAY}[./-]%{MONTH}[./-]%{YEAR}:%{TIME}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} "(%{WORD:http_verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version})|<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://))"'}
    }
   }
}

احفظ الملف ثم أغلقه. تعد التعليمة Logstash لترشيح السجلات من نوع haproxy-log باستخدام نمط Grok المعيَّن، والذي يحلل السجلات لمطابقتها مع الصيغة الافتراضية لسجلات HAProxy.

أعد تشغيل Logstash لاعتماد المرشح:

sudo service logstash restart

يجب التأكد بعد تنفيذ الأمر أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله.

إعداد المعاينة باستخدام Kibana

يمكن البدء باستخدام Kibana لمعاينة السجلات التي جمعناها من مختلف الخواديم. يسعادك المقال التالي في البدء باستخدام Kibana: كيف تستخدم لوحات القيادة والمعاينة في Kibana

بعد التأقلم مع Kibana جرب درس كيف تظهر مواقع المستخدمين على خريطة باستخدام GeoIP وELK لمعاينة أكثر تقدما.

خاتمة

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

ترجمة - وبتصرف - لمقال Building for Production: Web Applications — Centralized Logging  لصاحبه Mitchell Anicas.

أكملنا في الأجزاء السابقة من هذه السّلسلة إعداد خواديم التطبيقات، خطط الاسترداد، وآليات النسخ الاحتياطي. سنضبط في هذا الدرس إعداد المراقبة Monitoring لكي نكون على اطّلاع في أية لحظة بحالة عمل الخواديم والخدمات. تتيح برامج المراقبة مثل Nagios، Icinga وZabbix إمكانية إنشاء لوحات قيادة Dashboards وإشعارات تريك عناصر الإعداد التي تحتاج لاهتمام خاص. الهدف هو اكتشاف المشاكل والبدء في إصلاحها قبل أن تؤثر على المستخدمين النهائيين للتطبيق.

سنعد في هذا الدرس المراقبة باستخدام Nagios 4 ونثبت عملاء NRPE (إضافة تتيح تنفيذ أوامر Nagios على أجهزة أخرى) على الخواديم التي تكون التطبيق.

سنعد المراقبة على كل واحد من الخواديم لمعرفة هل الخادوم نشط وما إذا كانت العملية الرئيسة عليه (على سبيل المثال MySQL، Apache أو HAProxy) تعمل أم لا. لا يشمل هذا الدرس كل جوانب المراقبة، لذا قد تحتاج لإجراء فحوص إضافية لا يتناولها هذا الدّرس؛ إلا أنه يبقى نقطة جيدة للبدء.

المتطلبات

أنشئ، إن أردت الوصول إلى لوحة المراقبة عبر نطاق خاص مثل monitoring.example.com، سجلا من نوع A يحيل إلى عنوان IP العمومي الخاص بخادوم المراقبة. أو يمكنك بدلا من ذلك الوصول إلى لوحة القيادة في خادوم المراقبة باستخدام عنوانه العمومي. يُنصح بإعداد خادوم المراقبة لاستخدام HTTPS وتقييد الوصول إليه بوضعه في شبكة خاصة افتراضية.

تثبيت Nagios على خادوم المراقبة

اضبط Nagios على خادوم المراقبة باتباع الدرس التالي: كيف تستخدم Nagios 4 لمراقبة خواديم Ubuntu 14.04. إن رغبت في استخدام Icinga الذي هو اشتقاق من Nagios فدرس كيف تستخدم Icinga لمراقبة خواديمك وخدماتك على Ubuntu 14.04 يشرح الطريقة.

توقف عند فقرة مراقبة مستضيف Ubuntu بواسطة عملاء NRPE.

إضافة الخواديم إلى Nagios

طبق خطوات فقرة مراقبة مستضيف Ubuntu بواسطة عملاء NRPE من درس Nagios السابق على كل واحد من الخواديم (app2،app1، db1 وlb1).

تأكد من إضافة عنوان IP الخادوم أو اسم مستضيفه الخاص إلى allowed_hosts في ملف إعداد NRPE.

يجب أن يكون لديك بعد الانتهاء من إضافة المستضيفات ملف منفصل لكل خادوم: app2.cfg،app1.cfg،db1.cfg، وlb1.cfg. يتضمن كل ملف تعريف المستضيف الذي يحيل إلى اسمه وعنوانه (قد يكون العنوان اسم المستضيف أو عنوان IP الخاص بالخادوم).

إعداد المستضيف ومراقبة الخدمة

نبدأ بإعداد لائحة لما نريد مراقبته على كل خادوم. نراقب، على كل خادوم، الخدمات التالية:

• Ping.
• SSH.
• الحمل الجاري Current Load.
• المستخدمون الحاليون Current users.
• المساحة المستخدمة من القرص الصلب Disk Utilization.

تعريف الخدمات المشتركة

أعددنا Nagios في الدرس المُشار إليه سابقا ليرقُب الملفات الموجودة في المجلد usr/local/nagios/etc/servers/. سننشئ ملف إعداد Nagios للخدمات المشتركة التي نريد مراقبته؛ نسمي الملف common.cfg.

افتح أولا ملف الإعداد لتحريره:

sudo nano /usr/local/nagios/etc/servers/common.cfg

أضف تعريفات الخدمات التالية، مع تحديد قيمة host_name (أسماء المستضيفات الخاصة بالخواديم، عُرِّفت سابقا ضمن ملفات app2.cfg،app1.cfg،db1.cfg، وlb1.cfg):

define service {
use                             generic-service
host_name                       db1,app1,app2,lb1
service_description             PING
check_command                   check_ping!100.0,20%!500.0,60%
}

define service {
use                             generic-service
host_name                       db1,app1,app2,lb1
service_description             SSH
check_command                   check_ssh
notifications_enabled           0
}

define service {
use                             generic-service
host_name                       db1,app1,app2,lb1
service_description             Current Load
check_command                   check_nrpe!check_load
}

define service {
use                             generic-service
host_name                       db1,app1,app2,lb1
service_description             Current Users
check_command                   check_nrpe!check_users
}

define service{
use                             generic-service
host_name                       db1,app1,app2,lb1
service_description             Disk Utilization
check_command                   check_nrpe!check_hda1
}

احفظ الملف ثم أغلقه.

بالإمكان الآن الانتقال لتعريف الخدمات الخاصة بكل خادوم. نبدأ بخادوم قاعدة البيانات.

تعريف عملية MySQL

إنشاء أمر NRPE (على العميل)

سنضبط أمر NRPE جديدا على خادوم قاعدة البيانات، db1. افتح ملف إعداد NRPE جديدا، commands.cfg:

sudo nano /etc/nagios/nrpe.d/commands.cfg

أضف تعريف الأمر التالي:

command[check_mysqld]=/usr/lib/nagios/plugins/check_procs -c 1: -C mysqld

احفظ الملف ثم أغلقه. يتيح الأمر لـNRPE فحص عملية Process باسم mysqld والإبلاغ عن حالة حرجة Critical status إن كان هناك أقل من عملية واحدة نشطة بهذا الاسم.

أعد تحميل إعداد NRPE:

sudo service nagios-nrpe-server reload

إنشاء تعريف الخدمة (على الخادوم)

نحتاج لتعريف خدمة جديدة على خادوم monitoring (خادوم المراقبة) لاستخدام NRPE لتشغيل أمر check_mysqld السابق. افتح الملف الذي يعرف مستضيف قاعدة البيانات، db1.cfg في مثالنا:

sudo nano /usr/local/nagios/etc/servers/db1.cfg

أضف تعريف الخدمة التالي في آخر الملف (تأكد من أن قيمة host_name تطابق اسم تعريف المستضيف):

define service {
use                             generic-service
host_name                       db1
service_description             Check MySQL Process
check_command                   check_nrpe!check_mysqld
}

احفظ الملف ثم أغلقه. يُعد تعريف الخدمة أعلاه Nagios لاستخدام NRPE لتنفيذ أمر check_mysqld على خادوم قاعدة البيانات.

تجب إعادة تحميل Nagios لاعتماد التغييرات. إلا أننا سننتقل أولا لمراقبة عملية Apache أولا.

تعريف عملية Apache

إنشاء أمر NRPE (على العميل)

نضبط أمر NRPE جديدا على كلٍّ من خادومي التطبيق:

sudo nano /etc/nagios/nrpe.d/commands.cfg

ثم نضيف تعريف الأمر التالي:

command[check_apache2]=/usr/lib/nagios/plugins/check_procs -c 1: -w 3: -C apache2

احفظ الملف ثم أغلقه. يسمح الأمر لNRPE بالتحقق من وجود عملية باسم apache2 والإبلاغ عن حالة حرجة إن لم توجد عملية بهذا الاسم وإصدار تحذير إن وجدت أقل من ثلاث عمليات.

نعيد تحميل إعداد NRPE:

sudo service nagios-nrpe-server reload

تأكد من تنفيذ الخطوات على جميع خواديم التطبيقات.

إنشاء تعريف الخدمة (على الخادوم)

نحتاج تعريف خدمة جديدة تستخدم أمر check_apache2 على خادوم المراقبة monitoring. افتح الملف الذي يعرف مستضيف التطبيق (يوجد في حالتنا اثنان: app1 وapp2):

sudo nano /usr/local/nagios/etc/servers/app1.cfg

أضف تعريف الخدمة التالي في آخر الملف (تأكد من أن قيمة host_name تطابق اسم تعريف المستضيف):

define service {
use                             generic-service
host_name                       app1
service_description             Check Apache2 Process
check_command                   check_nrpe!check_apache2
}

احفظ الملف ثم أغلقه. يعد تعريف الخدمة Nagios لاستخدام NRPE لتنفيذ أمر check_apache2 على خادوم التطبيق. تأكد من تكرار الخطوة على كل واحد من خواديم التطبيقات.

تعريف عملية HAProxy

إنشاء أمر NRPE (على العميل)

نعد أمر NRPE على خادوم توزيع الحمل lb1 بنفس طريقة إعداده في الخواديم السابقة:

sudo nano /etc/nagios/nrpe.d/commands.cfg

ونضيف تعريف الأمر التالي:

command[check_haproxy]=/usr/lib/nagios/plugins/check_procs -c 1: -C haproxy

احفظ الملف ثم أغلقه. يعد تعريف الخدمة السابق NRPE للتحقق من عملية باسم haproxy ثم الإبلاغ عن حالة حرجة إن كان عدد العمليات بهذا الاسم أصغر من 1.

نعيد تحميل إعداداتت NRPE:

sudo service nagios-nrpe-server reload

إنشاء تعريف الخدمة (على الخادوم)

نضيف تعريف خدمة جديدا على خادوم monitoring ليستخدم أمر check_haproxy؛ بنفس الطريقة المشروحة سابقا.

sudo nano /usr/local/nagios/etc/servers/lb1.cfg

نضيف التعريف التالي في نهاية الملف:

define service {
use                             generic-service
host_name                       lb1
service_description             Check HAProxy Process
check_command                   check_nrpe!check_haproxy
}

يعد التعريف Nagios لاستخدام NRPE في تنفيذ الأمر check_haproxy على خادوم توزيع الحمل.

تجب إعادة تحميل Nagios من أجل اعتماد التعديلات.

إعادة تحميل Nagios

نعيد تحميل Nagios عبر تنفيذ الأمر التالي من أجل اعتماد التعديلات السابقة:

sudo service nagios reload

إن لم توجد أخطاء في صياغة الأوامر والتعريفات فيُعاد تحميل Nagios دون مشاكل.

التحقق من خدمات Nagios

يجب أن نتأكد من أن Nagios يراقب جميع الخواديم والخدمات التي عرفناها. ادخل إلى خادوم Nagios باستخدام اسم المستضيف العمومي أو عنوان IP (مثلا http://monitoring.example.com/nagios؛ أدخِل بيانات الدخول التي أعددتها أثناء تثبيت Nagios. انقر رابط الخدمات Services في القائمة الجانبية؛ يجب أن تظهر لديك صفحة تشبه ما يلي:

الوضعية المثالية هي أن تكون كل المستضيفات والخدمات على حالة OK. يمكن أن نرى في لقطة الشاشة السابقة وجود مشكلة في خادوم التطبيق app2؛ ويرجع ذلك إلى أنه كان مطفأ في أغلب فحوص الحالة الأخيرة. إن وجدت خدمات بحالة مغايرة لOK فأصلحها؛ وإن كانت جميع الخدمات بحالة جيدة فراجع إعدادات Nagios بحثا عن أخطاء ربما تكون أدت لإبلاغ غير صحيح عن حالة الخدمات.

اعتبارات أخرى

قد ترغب في إنشاء خطة استرداد لخادوم المراقبة، ملفات الإعداد الواجب نسخها إن أردت ذلك توجد في المجلد usr/local/nagios/etc/. يمكن أيضا أن تعدّ Nagios لمراقبة خدمات أخرى مثل البريد الإلكتروني.

خاتمة

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

في الجزء الموالي من الدليل سنعرض لكيفية إعداد سجلات مركزية لتطبيقات الويب في بيئة الإنتاج.

ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Monitoring لصاحبه Mitchell Anicas.

تحتاج خطط الاسترداد التي أعددناها في الجزء السابق إلى نظام للنسخ الاحتياطي. سنركز في هذا المقال على نظام النسخ الاحتياطي Bacula. يتيح Bacula تحكّمًا تامًا في ما تريد نسخه أو استعادته على المستوى الفردي للملفات؛ كما يسمح بجدولة النسخ الاحتياطي والاستعادة وفقا لما تراه أفضل بالنسبة لك.

سنُعدّ Bacula في هذا الجزء لتخزين نسخ احتياطية يوميا. تحوي النسخُ الملفاتِ الضروريةَ من الخواديم التي تكون التطبيق (app2، app1، db1 وlb1). حددنا في الجزء السابق الملفات التي نريد نسخها احتياطيا. يُريك هذا المقال كيفية استخدام Bacula لإنشاء نسخ احتياطية من حزمة برمجيات LAMP (أي MySQL، Apache، Linux وPHP). سنستعمل أيضا Percona XtraBackup لإنشاء نسخ احتياطية ساخنة Hot backups من قاعدة بيانات MySQL. ثم - في الأخير - نستخدم rsync لنسخ الملفات التي أنشأها Bacula على خادوم يوجد في موقع جغرافي آخر؛ أي أنه ستكون لدينا نسختان احتياطيتان، واحدة موجودة في نفس مركز بيانات الذي توجد به بيئة الإنتاج والأخرى في موقع ناء. سنضيف خادومين إلى الخواديم الموجودة سلفا: backups وremotebackups؛ الأخير يوجد في مركز بيانات ناء.

ملحوظة: نعني بالنسخ الاحتياطي الساخن - أو الديناميكي - أخذ نسخة من قاعدة البيانات وهي في حالة نشاط؛ مما يعني أنه قد يحصل تعديل عليها أثناء عملية النسخ. يقابل النسخَ الساخن النسخُ البارد Cold backup والذي توقف فيه قاعدة البيانات عن العمل، ثم تؤخذ نسخة منها قبل أن يُعاد تشغيلها.

تثبيت Bacula على خادوم النسخ الاحتياطية

اضبط Bacula على خادوم backups باتباع خطوات الدرس التالي: كيف تثبت خادوم Bacula على Ubuntu 14.04.

ثم اتبع فقرة تنظيم إعداد مدير Bacula (الخادوم) في مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. ستحتاج لاسم المدير Director name عند إعداد عملاء Bacula على الخواديم التي تريد نسخها احتياطيا. توقف عند الوصول إلى فقرة تثبيت عميل Bacula وإعداده.

تثبيت عميل Bacula على كل خادوم

ثبت عميل Bacula على كل واحد من الخواديم التي تريد نسخها احتياطيا (app2، app1، db1 وlb1) باتباع فقرة تثبيت عميل Bacula وإعداده من درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula. توقف عند الوصول إلى فقرة إضافة مجموعة ملفات FileSets (الخادوم).

يرجى الانتباه إلى أنك ستحتاج اسم FileDaemon (جنيّ الملفات، يكون عادة اسم المستضيف مضافا إليه “fd-“) وكلمة سر المدير Director (كلمة السر التي سيستخدمها خادوم Bacula للاتصال بكل واحد من العملاء). توجد القيمتان ضمن ملف bacula-fd.conf الموجود على كل خادوم.

إضافة عملاء Bacula إلى خادوم النسخ الاحتياطي

أضف، إلى خادوم Bacula (أي backups)، موردَ عميل Client resource لكل واحد من الخواديم التي ثبت عليها عميل Bacula. يُضاف مورد العميل إلى الملف etc/bacula/conf.d/clients.conf/:

sudo nano /etc/bacula/conf.d/clients.conf

في ما يلي مثال على تعريف مورد العميل بالنسبة لخادوم قاعدة البيانات db1. يجب أن توافق قيمة Name اسم المورد FileDaemon الموجود على الخادوم العميل. نفس الشيء بالنسبة لPassword التي يجب أن توافق قيمة Password ضمن مورد Director على الخادوم العميل. توجد هذه القيم في ملف etc/bacula/bacula-fd.conf/ على كل واحد من عملء Bacula.

Client {
  Name = db1-fd
  Address = db1.nyc3.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "PDL47XPnjI0QzRpZVJKCDJ_xqlMOp4k46"          # كلمة سر العميل
  File Retention = 30 days            # 30 يوما
  Job Retention = 6 months            # 6 أشهر
  AutoPrune = yes                     # التخلص من الأشغال/الملفات منتهية الصلاحية
}

أنشئ بنفس الطريقة مورد عميل لكل واحد من الخواديم العميلة لخادوم Bacula. يجب بانتهاء الإعداد في المثال أن تكون لدينا أربعة موارد عملاء: app2-fd، app1-fd، db1-fd وlb1-fd. تضبط هذه الإعدادات الخادوم backups ليكون قادرا على الاتصال بعميل Bacula الموجود على كل خادوم.

احفظ الملف ثم أغلقه.

يمكن الحصول على تفاصيل أكثر بمراجعة فقرة تثبيت عميل Bacula وإعداده في درس كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula.

إنشاء نسخ احتياطية ساخنة من قاعدة البيانات

يجب إيلاء اهتمام خاص لنسخ قاعدة البيانات الاحتياطية، من أجل إنشاء نسخ احتياطية متناسقة وقابلة للاستخدام. توجد طريقة سهلة وفعالة لإنشاء نسخ احتياطية ساخنة لقاعدة بيانات MySQL وهي استخدام Percona XtraBackup.

تثبيت Percona XtraBackup

ثبت Percona XtraBackup واضبطه على خادوم قاعدة البيانات db1 باتباع خطوات الدرس كيف تستخدم Percona XtraBackup لإنشاء نسخ احتياطية فورية من قواعد بيانات MySQL على Ubuntu 14.04. توقف عند الوصول إلى فقرة إنشاء نسخة احتياطية كاملة فوريا.

إنشاء سكربت XtraBackup

Percona XtraBackup جاهز الآن لإنشاء نسخ احتياطية ساخنة من قاعدة بيانات MySQL. سيحتفظ Bacula بهذه النسخ؛ إلا أنه يجب أولا إيجاد طريقة لجدولة النسخ الساخنة.
نستخدم cron لهذه المهمة.

أنشئ سكربت Bash في usr/local/bin/ وسمه run_extra_backup.sh:

sudo nano /usr/local/bin/run_xtrabackup.sh

أضف السكربت التالي إلى الملف الذي أنشأته للتو (تأكد من إدراج اسم المستخدم وكلمة السر الذين استعملتهما عند تثبيت XtraBackup):

#!/bin/bash

# pre xtrabackup
chown -R mysql: /var/lib/mysql
find /var/lib/mysql -type d -exec chmod 770 "{}" \;

# delete existing full backup
rm -r /data/backups/full

# xtrabackup create backup
innobackupex --user=bkpuser  --password=bkppassword --no-timestamp /data/backups/full

# xtrabackup prepare backup
innobackupex --apply-log /data/backups/full

احفظ الملف ثم أغلقه. سيؤدي تنفيذ هذا الملف بصلاحيات الحساب الإداري إلى حذف نسخة XtraBackup الاحتياطية الموجودة ضمن مسار data/backups/full/ وإنشاء نسخة احتياطية كاملة جديدة.

توجد تفاصيل أكثر عن النسخ الاحتياطية باستخدام XtraBackup ضمن فقرة إنشاء نسخة احتياطية كاملة ساخنة في درس XtraBackup.

اجعل السكربت قابلا للتنفيذ:

sudo chmod +x /usr/local/bin/run_xtrabackup.sh

يجب تنفيذ سكربت XtraBackup وإكماله قبل أن يحاول Bacula أخذ نسخة احتياطية من خادوم قاعدة البيانات، وذلك من أجل نسخ قاعدة البيانات بطريقة صحيحة. يمكن إعداد شغل Job في Bacula للتعامل مع السكربت على أنه “سكربت لما قبل النسخ الاحتياطي”؛ إلا أننا سنختار هنا استخدام شغل cron توخيا للسهولة.

أنشئ ملف إعداد لcron (تُضاف الملفات الموجودة ضمن المجلد etc/cron.d/ إلى جدول cron الخاص بالمستخدم الجذر):

sudo nano /etc/cron.d/xtrabackup

أضف شغل cron التالي:

30 22    * * *   root    /usr/local/bin/run_xtrabackup.sh

يُجدول هذا الشغل السكربت ليعمل بصلاحيات الجذر كل يوم عند الساعة العاشرة والنصف مساء (22:30). اخترنا هذا الوقت لأن Bacula مُجدول حاليا ليأخذ نسخا احتياطية يوميا عند الساعة الحادية عشرة مساء وخمس دقائق (23:05). سنناقش هذا الخيار في ما بعد. يعطينا فارق الجدولة هذا 35 دقيقة ليكتمل عمل سكربت XtraBackup.

اكتمل الآن إعداد النسخ الاحتياطي الساخن لقاعدة البيانات. ننتقل لمجموعات ملفات FileSets النسخة الاحتياطية لBacula.

إعداد مجموعة ملفات FileSets في Bacula

سننشئ نسخا احتياطية من الملفات المحدَّدة ضمن مجموعة الملفات المربوطة بأشغال النسخ الاحتياطي التي ستُنفَّذ. ستغطي هذه الفقرة إنشاء مجموعة ملفات تحوي النسخ الاحتياطية الضرورية المحدّدة في خطط الاسترداد. يمكن إيجاد تفاصيل أكثر عن إضافة مجموعة ملفات إلى Bacula تحت فقرة إضافة مجموعة ملفات FileSets (الخادوم) في درس Bacula.

افتح ملف filesets.conf الموجود على خادوم النسخ الاحتياطي backups:

sudo nano /etc/bacula/conf.d/filesets.conf

مجموعة الملفات الخاصة بخادوم قاعدة البيانات

تتضمن النسخ الاحتياطية المطلوبة من خادوم قاعدة البيانات، وفقا لخطة استرداد قاعدة البيانات:

• قاعدة بيانات MySQL: ينشئ سكربت XtraBackup نسخة احتياطية من قاعدة البيانات يوميا عند الساعة 22:30 ويضعها في المجلد data/backups/full/.
• ملف إعداد MySQL الموجود في المجلد etc/mysql/.

سنضمِّن أيضا سكربت usr/local/bin/run_xtrabackup.sh/ وملف cron المتعلق به.

نضيف اعتمادا على ما سبق مجموعة ملفات باسم MySQL Database إلى إعداد Bacula:

FileSet {
  Name = "MySQL Database"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /data/backups
    File = /etc/mysql/my.cnf
    File = /usr/local/bin/run_xtrabackup.sh
    File = /etc/cron.d/xtrabackup
  }
  Exclude {
    File = /data/backups/exclude
  }
}

ننتقل الآن إلى مجموعة ملفات التطبيق.

مجموعة الملفات الخاصة بخادوم التطبيق

تتضمن النسخ الاحتياطية المطلوبة من خادوم التطبيق وفقا لخطة استرداد هذا الأخير:

• ملفات التطبيق الموجودة - في مثالنا - على المسار var/www/html/.

نضيف اعتمادا على هذه المعلومة مجموعة ملفات Apache DocumentRoot إلى ملف إعداد Bacula:

FileSet {
   Name = "Apache DocumentRoot"
   Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /var/www/html
  }
  Exclude {
    File = /var/www/html/exclude
  }
}

يمكن أيضا أن تضيف ملف الإعداد الخاص بمنافذ Apache، إلا أنه يمكن تغيير هذا الملف بسهولة عند الحاجة.

مجموعة الملفات الخاصة بخادوم توزيع الحمل

الطريقة المتَّبعة هي نفسها. نحدد الملفات المطلوب نسخها ثم ننشئ مجموعة ملفات في Bacula اعتمادا عليها.

الملفات المطلوبة:

• ملف PEM الخاص بشهادة SSL والملفات المتعلقة بها، توجد هذه الملفات على مسار root/certs/ في مثالنا.
• ملف إعداد HAProxy: يوجد في مجلد etc/haproxy.

سنضيف هذه الملفات إلى مجموعة Apache DocumentRoot:

FileSet {
  Name = "Apache DocumentRoot"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /var/www/html
    File = /root/certs
    File = /etc/haproxy
  }
  Exclude {
    File = /var/www/html/exclude
    File = /root/exclude
  }
}

احفظ الملف ثم أغلقه.

بهذا نكمل إعداد مجموعات الملفات. ننتقل لإعداد أشغال Bacula التي ستستخدم هذه المجموعات.

إنشاء أشغال النسخ الاحتياطي في Bacula

مهمة الأشغال في Bacula هي إنشاء نسخ احتياطية من الخواديم. أنشئ ملف jobs.conf في المسار etc/bacula/conf.d/:

>sudo nano /etc/bacula/conf.d/jobs.conf

شغل النسخ الاحتياطي لخادوم قاعدة البيانات

سننشئ شغل نسخ احتياطي جديدا لخادوم قاعدة البيانات باسم Backup db1. من المهم هنا تحديد الاسم الصحيح للعميل db1-fd واسم مجموعة الملفات MySQL Database:

Job {
  Name = "Backup db1"
  JobDefs = "DefaultJob"
  Client = db1-fd
  Pool = RemoteFile
  FileSet="MySQL Database"
}

أشغال النسخ الاحتياطي لخواديم التطبيقات

سننشئ شغل نسخ احتياطي لكل من خادومي التطبيق، Backup app1 للخادوم app1 وBackup app2 لapp2. من المهم، مثل ما فعلنا مع خادوم قاعدة البيانات، تحديد الأسماء الصحيحة للعملاء (app1-fd وapp2-fd) ومجموعة الملفات (Apache DocumentRoot).

بالنسبة للخادوم app1:

Job {
  Name = "Backup app1"
  JobDefs = "DefaultJob"
  Client = app1-fd
  Pool = RemoteFile
  FileSet="Apache DocumentRoot"
}

وبالنسبة للخادوم app2:

Job {
   Name = "Backup app2"
   JobDefs = "DefaultJob"
   Client = app2-fd
   Pool = RemoteFile
   FileSet="Apache DocumentRoot"
}

شغل النسخ الاحتياطي لخادوم توزيع الحمل

نتبع نفس مبدأ الخطوات السابقة لإنشاء شغل جديد ونسميه Backup lb1:

Job {
  Name = "Backup lb1"
  JobDefs = "DefaultJob"
  Client = lb1-fd
  Pool = RemoteFile
  FileSet="SSL Certs and HAProxy Config"
}

احفظ الملف ثم أغلقه.

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

أعد تشغيل Bacula على خادوم النسخ الاحتياطي لاعتماد التغييرات التي أجريناها في الفقرات السابقة:

sudo service bacula-director restart

يجب أن تختبر، بالوصول إلى هذه النقطة، اتصالات عملاء Bacula وأشغال النسخ الاحتياطي. يغطى مقال كيف تنسخ احتياطيا خادوم Ubuntu 14.04 باستخدام Bacula هذين الجانبين. يُرجى ملاحظة أنه لاستعادة قاعدة بيانات MySQL ستحتاج لاتباع خطوة الاستعادة من نسخة احتياطية ضمن درس Percona XtraBackup.

مراجعة جدول النسخ الاحتياطي

يمكن تنظيم جدول النسخ الاحتياطي في Bacula بالتعديل على إعداد مدير Bacula (الملف etc/bacula/bacula-dir.conf/). تستخدم جميع الأشغال التي أنشأناها تعريف الشغل DefaultJob الذي يستخدم جدولةً بدورة أسبوعية تعرَّف على النحو التالي:

• نسخة احتياطية كاملة Full backup في أول يوم أحد من الشهر عند الساعة 23:05.
• نسخ احتياطية تفاضلية Differential backups في أيام الأحد المتبقية عند الساعة 23:05.
• نسخ احتياطية تزايدية Incremental backups في باقي الأيام، من الإثنين إلى السبت عند الساعة 23:05.

يمكنك التأكد من طريقة الجدولة وفحص حالة المدير في وحدة تحكم Bacula. يجب أن يظهر جميع الأشغال المُجدولة:

Scheduled Jobs:
Level          Type     Pri  Scheduled          Name               Volume
===================================================================================
Incremental    Backup    10  20-May-15 23:05    BackupLocalFiles   MyVolume
Incremental    Backup    10  20-May-15 23:05    Backup lb1         Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup app2        Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup app1        Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup db1         Remote-0002

سيكون من الجيد ضبط جدولة النسخ في خواديم التطبيقات بحيث يحدُث في نفس الوقت الذي ينسَخ فيه سكربت XtraBackup قاعدة البيانات (22:30)؛ وهو ما سيحول دون أن تكون نسخ خواديم التطبيقات غير متجانسة مع نسخة قاعدة البيانات.

إعداد نسخ احتياطية نائية

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

سنشرح طريقة سهلة لإرسال النسخ الاحتياطية من خادوم backups إلى خادوم remotebackups باستخدام مفاتيح SSH، أداة rsync وcron.

أنشئ حسابا على خادوم remotebackups لاستخدامه في الولوج عبر rsync. ثم أنشئ باستخدام الحساب الجذر زوج مفاتيح SSH لا يحتاج لكلمة سر على خادوم backups. ثبت المفتاح العمومي على الحساب الذي أنشأته للتو على خادوم remotebackups؛ الطريقة مشروحة في مقال العمل مع خواديم SSH: العملاء والمفاتيح

اكتب، على خادوم backups أمر rsync ينسخ الملفات الموجودة على مسار bacula/backup/ إلى مكان يوجد على خادوم remotebackups. يغطي درس كيف تستخدِم Rsync لمزامنة مجلّدات بين الجهاز المحلّي والخادوم طريقة استخدام rsync. الشكل العام للأمر سيكون على النحو التالي (remoteuser الحساب على الخادوم البعيد، remotebackups_public_hostname_or_IP اسم المستضيف أو عنوان IP العمومي الخاص بالخادوم البعيد، وpath/to/remote/backup/ مسار مجلد النسخ الاحتياطي على الخادوم البعيد):

rsync -az /bacula/backup remoteuser@remotebackups_public_hostname_or_IP:/path/to/remote/backup

أضف الأمر لسكربت، مثلا: usr/local/bin/rsync_backups.sh/ واجعله قابلا للتنفيذ. وأخيرا، اضبط شغل cron ينفذ سكربت rsync_backups.sh بصلاحيات root بعد إكمال أشغال Bacula. تمكن مراجعة درس كيف تجدول مهامك الروتينية باستخدام أداتي Cron و Anacron في لينكس لمزيد من التفاصيل عن عمل cron.

تأكد بعد ضبط كل هذه الإعدادات من وجود نسخ احتياطية على خادوم remotebackups في اليوم الموالي.

اعتبارات أخرى

لم نتحدث في ما سبق عن متطلبات القرص الصلب من ناحية التخزين. يجب أن تراجع مساحة التخزين التي تستخدمها نسخك الاحتياطية ثم تعيد النظر في إعداد النسخ الاحتياطي وجدولته وفقا لاحتياجاتك والموارد المتوفرة لديك.

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

خاتمة

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

ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Backups لصاحبه Mitchell Anicas.

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

يمكن أن تتمثل خطة استرداد قاعدية من إخفاق بيئة العمل في لائحة بالخطوات الواجب اتباعها لإنجاز النشر الابتدائي للخادوم؛ إلى جانب عمليات إضافية لاستعادة بيانات التطبيق من النسخ الاحتياطية. للحصول على خطة استرداد أفضل يجب، إضافة للتوثيق الجيد، استغلال سكربتات النشر وأدوات إدارة الإعدادات مثل Chef، Ansible وPuppet؛ للمساعدة في أتممة وتسريع الاسترداد.

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

متطلبات خطة الاسترداد

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

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

• خادوم قاعدة البيانات.
• خواديم التطبيق.
• خادوم توزيع الحمل.

نبدأ بخادوم قاعدة البيانات.

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

بإعادة تتبع خطواتنا (وإعادة النظر في الدرس السابق) نجد أن خادوم قاعدة البيانات أنشئ وفقا للخطوات التالية:

• تثبيت MySQL.
• إعداد MySQL.
• إعادة تشغيل MySQL.
• إنشاء قاعدة البيانات والمستخدمين.

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

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

في ما يلي ملخَّص لخطة الاسترداد الخاصة بخادوم قاعدة البيانات:

النسخ الاحتياطية الضرورية:

• قاعدة بيانات MySQL.
• ملف إعداد MySQL.

خطوات الاسترداد:

• تثبيت MySQL.
• استعادة ملف إعداد MySQL وتحديث عنوان IP الإنصات في حال تغيّره.
• استعادة قاعدة البيانات.
• إعادة تشغيل MySQL.

يجب الآن التدرب على تنفيذ خطة الاستعادة هذه، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية.

خواديم التطبيق

نعرف بالنظر في طريقة إنشاء خواديم التطبيق (ومراجعة الدرس السابق)؛ أنّ الخطوات المتَّبعة كانت على النحو التالي:

• تثبيت كل من PHP وApache وإعدادهما.
• تنزيل التطبيق (ووردبريس) وإعداده.
• نسخ ملفات التطبيق إلى جذر المستند Document root.
• تكرار ملفات التطبيق على جميع خواديم التطبيق.

خطة الاسترداد لخادوم التطبيق

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

أعددنا الخواديم بحيث تُكرَّر الملفات على خواديم التطبيق؛ يعني هذا أننا لا نحتاج لاستعادة البيانات من النسخ الاحتياطية إلا إذا أخفقت خواديم التطبيق جميعها أو تلَفتْ البيانات بطريقة أو بأخرى. إن بقي خادوم تطبيق واحد على الأقل يعمل جيدا، مع ملفات التطبيق الصحيحة؛ فإن إعادة ضبط تكرار الملفات مرة أخرى سيعيد الملفات الصحيحة إلى خادوم التطبيق الجديد.

في ما يلي ملخَّص لخطة الاسترداد الخاصة بخواديم التطبيقات، اعتمادا على الجرد أعلاه:

النسخ الاحتياطية المطلوبة:

• ملفات التطبيق (/var/www/html/ في المثال).

خطوات الاسترداد:

• تثبيت PHP وApache وإعدادهما.
• تكرار ملفات التطبيق على الخادوم الجديد انطلاقا من الخواديم العاملة.
• إن لم يمكن تكرار الملفات (أي أن جميع خواديم التطبيق خارج الخدمة)؛ أعدها من النسخ الاحتياطية.

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

خادوم توزيع الحمل

المبدأ هو نفسه، ننظر إلى خطوات إنشاء موزع الحمل في الدرس السابق؛ فنخرج بالتالي:

• الحصول على شهادة SSL والملفات المتعلقة بها.
• تثبيت HAProxy.
• إعداد HAProxy.
• إعادة تشغيل HAProxy.

خطة الاسترداد لخادوم توزيع الحمل

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

نضع - مثل ما فعلنا مع العناصر السابقة، ملخصا لخطة الاسترداد الخاصة بخادوم توزيع الحمل:

النسخ الاحتياطية المطلوبة:

• شهادة SSL (ملف PEM) والملفات المتعلقة بها.
• ملف إعداد HAProxy.

خطوات الاسترداد

• استعادة ملفات شهادة SSL.
• تثبيت HAProxy.
• استعادة ملف إعداد HAProxy.
• إعادة تشغيل HAProxy.

اكتمل إعداد خطة الاسترداد لخادوم توزيع الحمل. يجب الآن التدرب على تنفيذ خطة الاسترداد، والتأكد من الاحتفاظ بالنسخ الاحتياطية الضرورية.

اعتبارات أخرى

إن تطلب استرداد أحد العناصر إعادة ضبط عنصر آخر (تغير عنوان IP الخاص بخادوم قاعدة البيانات مثلا)؛ فعليك التأكد من إدراج الخطوات الضرورية في خطط الاسترداد.

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

لم نتطرق لحد الساعة إلى كيفية إنشاء ثم استعادة النسخ الاحتياطية؛ لذا سنحتاج للنظر في هذه التفاصيل لاحقا. سيكون النسخ الاحتياطي موضوع الجزء الموالي من هذا الدليل.

خاتمة

يجب الاحتفاظ بخطط الاستعادة الخاصة بالخواديم المختلفة في مكان آمن يمكن لمن أراد تنفيذ الخطوات الموجودة فيها الوصولُ إليه. احتفظ بها في مكان منفصل تماما عن بيئة العمل.

ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Recovery Planning لصاحبه Mitchell Anicas.

حقوق الصورة البارزة: Designed by Freepik.

هذا الدّرس هو الجزء الثّاني من سلسلة من 6 دروس حول "نظرة عامة على إنشاء تطبيقات موجهة لبيئة الإنتاج". إذا لم تقرأ الدّرس الأول فألق نظرة عليه قبل أن تواصل القراءة.

سنعدّ في هذا الجزء من السّلسلة تطبيق PHP الذي اخترناه مثالا (ووردبريس) إضافة إلى خادوم أسماء نطاقات DNS خاص.

سيستعمل مستخدمو التطبيق اسمَ النطاق للوصول إليه؛ عبر العنوان https://www.example.com على سبيل المثال. يحيل العنوان إلى موزع الحِمل الذي سيعمل وسيطا عكسيا Reverse proxy لخواديم التطبيق التي تتصل بدورها بخادوم قاعدة البيانات. يمكِّننا استخدامُ نظام أسماء نطاقات خاصة Private DNS من الإشارة إلى عناوين الخواديم ضمن الشبكة الداخلية بأسماء المستضيفات الخاصة بها مما يسهل من عملية إعداد الخواديم.

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

1. نظام أسماء نطاقات خاصة (المستضيفان ns1 وns2).
2. خادوم قاعدة البيانات (db1).
3. خواديم التطبيق (app1 وapp2).
4. موزع حمل (lb1).

فلنبدأ بإعداد النطاقات.

خواديم النطاقات الداخلية

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

سنشير إلى كل عنوان في الشبكة الداخلية بمستضيف ضمن النطاق الفرعي nyc3.example.com. سيكون عنوان خادوم قاعدة البيانات ضمن الشبكة الداخلية - على سبيل المثال - db1.nyc3.example.com؛ وهو ما ستترجمه خواديم النطاقات إلى عنوان IP داخلي (خاص). تنبغي الإشارة إلى أن اختيار اسم النطاق الفرعي nyc3.example.com اعتباطي. في العادة يُستخدم اسم الموقع الجغرافي للنطاق الفرعي؛ في مثالنا، تشير nyc3 إلى أن الخواديم تتواجد في مركز البيانات NYC3، وexample.com إلى اسم النطاق الخاص بالتطبيق.

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

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

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

نريد - طبقا للخطة - توزيع الحمل بين خواديم التطبيقات؛ أي تلك التي تشغِّل PHP وApache، لذا سنفْصِل قاعدة البيانات عن خواديم التطبيق لجعلها على خادوم خاص بها. من المهم جدا فصل قاعدة البيانات عن التطبيق في حال أردنا إمكانية التوسع أفقيا Horizontally Scaling (إضافة خواديم جديدة لتعمل مع تلك الموجودة) في تطبيقات PHP.

تغطي هذه الفقرة كل الخطوات الضرورية لإعداد خادوم قاعدة البيانات، لكن يمكنك معرفة المزيد عن إعداد قاعدة بيانات MySQL بعيدة بقراءة مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL.

تثبيت MySQL

نفذ الأمرين التاليين على خادوم قاعدة البيانات (db1) لتثبيت خادوم MySQL:

sudo apt-get update
sudo apt-get -y install mysql-server

أدخل كلمة السر التي تريد استخدامها للحساب الإداري في MySQL عندما يُطلب منك ذلك.

نفذ:

sudo mysql_install_db
sudo mysql_secure_installation

ستحتاج لإدخال كلمة سر المستخدِم الإداري التي اخترتها عند تثبيت خادوم MySQL؛ بعدها سيسألك إن كنت تريد تغيير كلمة السر هذه، اضغط زر N إذا كنت لا تريد تغييرها. بالنسبة لبقية الأسئلة اضغط زر Enter لتأكيد الاختيارات الافتراضية.

إعداد MySQL لاستخدام واجهة الشبكة الداخلية

افتح ملف إعداد MySQL عبر الأمر التالي:

sudo nano /etc/mysql/my.cnf

ابحث عن bind-address وحدد قيمة المتغير بعنوان IP قاعدة البيانات ضمن الشبكة الداخلية:

bind-address            = db1.nyc3.example.com

احفظ الملف ثم أغلقه.

أعد تشغيل MySQL:

sudo service mysql restart

ضبط قاعدة البيانات ومستخدميها

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

mysql -u root -p

أدخل كلمة السر عندما تُطلب.

أنشئ قاعدة بيانات بتنفيذ الأمر التالي في سطر أوامر MySQL:

CREATE DATABASE app;

يرفق خادوم MySQL كل مستخدم بالخواديم التي يمكنه منها الاتصال بقاعدة بيانات. يوجد في مثالنا خادوما تطبيق يتصلان بقاعدة البيانات؛ لذا سننشئ مستخدما لكل واحد منهما. أنشئ مستخدما في قاعدة البيانات باسم appuser يمكنه الاتصال من العناوين الداخلية لخواديم التطبيقات (أي app1 وapp2). يجب استخدام نفس كلمة السر للمستخدمَيْن (اختر كلمة سر واكتبها مكان password في الأمرين أدناه):

CREATE USER 'appuser'@'app1.nyc3.example.com' IDENTIFIED BY 'password';
CREATE USER 'appuser'@'app2.nyc3.example.com' IDENTIFIED BY 'password';

سنضبط في ما بعد امتيازات المستخدم appuser، نكتفي الآن بإعطائه تحكما كاملا على قاعدة البيانات app:

GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app1.nyc3.example.com';
GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app2.nyc3.example.com';
FLUSH PRIVILEGES;

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

للخروج من سطر أوامر MySQL:

exit

اكتمل الآن إعداد خادوم قاعدة البيانات. ننتقل لإعداد خواديم التطبيقات.

إعداد خواديم التطبيقات

تتصل خواديم التطبيق بخادوم قاعدة البيانات. اخترنا ووردبريس للتمثيل في هذا الدليل، وهو تطبيق PHP يعمل على خادوم ويب مثل Apache أو Nginx. سنضبط خادومين متطابقين لتوزيع الحِمل بينهما. تغطّي هذه الفقرة الخطوات الضرورية لإعداد خواديم التطبيق، لكن الموضوع مشروح بتفاصيل أكثر في مقال كيفية إعداد قاعدة بيانات بعيدة لتحسين أداء موقع يستخدِم MySQL انطلاقا من فقرة إعداد خادوم الويب.

تثبيت Apache وPHP

نفذ الأوامر التالية على كل واحد من الخادومين app1وapp2 لتثبيت Apache وPHP:

sudo apt-get update
sudo apt-get -y install apache2 php5-mysql php5 libapache2-mod-php5 php5-mcrypt

إعداد Apache

سنستخدم HAProxy على خادوم موزع الحمل للتعامل مع الاتصال عبر SSL، مما يعني أننا لا نريد أن يتصل المستخدمون بخادوميْ التطبيقات مباشرة. سنربط Apache بعنوان الشبكة الداخلية الخاص بكل واحد من الخادومين.

نفّذ الأمر التالي على كل من الخادومين، app1 وapp2:

sudo nano /etc/apache2/ports.conf

ابحث عن السطر الذي توجد فيه العبارة Listen 80 وأضف عنوان خادوم التطبيق الخاص إليها، على النحو التالي (أبدل private_IP بعنوان IP الخاص بك):

Listen private_IP:80

احفظ الملف ثم أغلقه. يجعل هذا الإعداد خادوم Apache يُنصت لعناوين الشبكة الداخلية فقط؛ ممايعني أنه لا يمكن الوصول إليه عبر عنوان IP العمومي أو اسم المستضيف.

أعد تشغيل Apache لأخذ التغيير في الحسبان:

sudo service apache2 restart

لا يمكن - وفق الإعداد الحالي - الوصول مباشرة إلى خادوم Apache؛ إذ تقتصر الاتصالات التي يقبلها على تلك القادمة من الشبكة الداخلية. سنعدّ - بعد قليل - موزع الحمل لإرسال الطلبات إلى الخواديم.

تنزيل التطبيق وإعداده

اخترنا في هذه السّلسلة ووردبريس مثالا للتطبيق. إن كنت تستخدم تطبيق PHP مغايرا فيجب عليك تنزيله وعمل الإعدادات اللازمة (معلومات الاتصال بقاعدة البيانات على سبيل المثال)؛ ثم انتقل إلى الفقرة الموالية.

نزل أرشيف ووردبريس على خادوم التطبيق الأول، app1:

cd ~
wget http://wordpress.org/latest.tar.gz

فك ضغط الأرشيف واستخرج ملفات ووردبريس:

tar xvf latest.tar.gz

انتقل إلى مجلّد ووردبريس المُستخرَج:

cd wordpress

يحتاج ووردبريس إلى مجلّد لوضع الملفات التي يحملها فيه؛ فلننشئ هذا المجلّد (wp-content/uploads):

ode>mkdir wp-content/uploads

سنستخدم ملف إعداد ووردبريس النموذجي قالبا للإعداد:

cp wp-config-sample.php wp-config.php

افتح الملف الإعداد من أجل تحريره:

nano wp-config.php

اضبط اتصال ووردبريس بقاعدة البيانات بتحرير المعلومات الميَّزة في الأسطر التالية:

/** The name of the database for WordPress */
define('DB_NAME', 'app');

/** MySQL database username */
define('DB_USER', 'appuser');

/** MySQL database password */
define('DB_PASSWORD', 'password');

/** MySQL hostname */
define('DB_HOST', 'db1.nyc3.example..com');

نضيف الأسطر التالية إلى ملف إعداد ووردبريس لإخباره بأنه خلف وسيط عكسي يستخدم SSL (موزع الحمل يستخدم TLS/SSL للتعميّة):

define('FORCE_SSL_ADMIN', true);
  if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
     $_SERVER['HTTPS']='on';

احفظ الملف ثم أغلقه.

تبقّى الآن نقلُ ملفات ووردبريس إلى مجلد يمكن لخادوم الويب الوصول إليه من أجل خدمة الزوار.

نقل ملفات التطبيق إلى جذر المستند Document Root

نحتاج الآن، بعد إعداد التطبيق، لنقل ملفات ووردبريس إلى جذر المستند في Apache حيث يمكن لخادوم الويب الوصول إليها وتقديمها لزوار الموقع. جذر المستند الافتراضي في Apache هو المسار var/www/html/ وهو ما سنستخدمه في مثالنا.

احذف أولا ملف index.html الافتراضي:

sudo rm /var/www/html/index.html

استخدم أداة rsync لنسخ ملفات ووردبريس إلى المجلد var/www/html/ اجعل www-data (الحساب الذي يشتغل به خادوم ويب Apache) مالكَ هذا المجلّد:

sudo rsync -avP ~/wordpress/ /var/www/html
sudo chgrp -R www-data /var/www/html/*

أصبح خادوم التطبيق الأول app1 جاهزا؛ سنعد الآن خادوم التطبيق الآخر.

تكرار ملفات التطبيق على الخواديم الأخرى

يتوجب إعداد آلية لتكرار الملفات الموجودة في جذر المستند لخادوم الويب على مختلف الخواديم المكوِّنة للتطبيق؛ من أجل إبقاء ملفات التطبيق متجانسة عبر الخواديم. في حالة ووردبريس فإن استخدام واجهة الويب لتحميل الملفات وتثبيت الإضافات سيجعلها موجودة فقط على الخادوم الذي عالج الطلب. إن لم تكرَّر الملفات على جميع الخواديم فسيرى بعض زوار الموقع صفحات بصور ناقصة وإضافات مكسورة. إن كنت تستخدم تطبيقا آخر غير ووردبريس لا يحفظ بياناته (الملفات المحمَّلة والإضافات المنزّلة مثلا) على خادوم التطبيق فيمكنك الاكتفاء بنقل الملفات إلى الخادوم يدويا مرة واحدة. في هذه الحالة استخدم أداة rsync لنقل ملفات التطبيق من الخادوم app1 إلى الخادوم app2.

يمكن استخدام GlusterFS لإنشاء تجزئة قرص مكرَّرة من الملفات الضرورية. الطريقة مشروحة في فقرة مزامنة الملفات في تطبيقات الويب ضمن مقال كيف تستخدم HAProxy لتوزيع الحمل بين خواديم تطبيق ووردبريس. اتبع الخطوات (تجاوز فقرة إعداد ملفات المستضيف لأن خادوم النطاقات لدينا يتولى المهمة) ثم اضبُط تكرار الملفات بين app1 وapp2.

بعد الانتهاء من إعداد تكرار الملفات بين الخواديم نكون على استعداد لتجهيز موزِّع الحمل.

إعداد موزع الحمل

اخترنا HAProxy موزعا للحمل؛ وسيعمل وسيطا عكسيا لخواديم التطبيق. سيصل المستخدمون إلى التطبيق عبر عنوان شبيه بhttps://www.example.com بعد المرور بموزع الحمل. تشرح هذه الفقرة الخطوات الضرورية لإعداد خادوم موزِّع للحمل/

نسخ شهادة SSL

نفذ الخطوات التالية على خادوم موزع الحمل، lb1.

ضع شهادة SSL (أحد متطلبات الجزء الأول من السّلسلة) ومفتاح الشهادة، إضافة لأي شهادات من سلطة وسيطة ضمن ملف pem. واحد (نفترض أن شهادات SSL موجودة في المجلّد root/certs/):

cd /root/certs
cat www.example.com.crt CAintermediate.ca-bundle www.example.com.key > www.example.com.pem

ثم انسخ ملف pem إلى المجلّد etc/ssl/private/:

sudo cp www.example.com.pem /etc/ssl/private/

سيستخدم HAProxy هذا الملف لإنهاء SSL.

تثبيت HAProxy

نفذ الأوامر التالية على خادوم موزع الحمل، lb1:

sudo add-apt-repository ppa:vbernat/haproxy-1.5
sudo apt-get update
sudo apt-get -y install haproxy

إعداد HAProxy

نحتاج لضبط إعداداتٍ عامة في HAProxy إضافة لإنهاء SSL والنهايات الخلفية Backend والأمامية Frontend المناسبة لجعله يعمل مع خواديم التطبيق.

افتح ملف إعداد HAProxy لتحريره:

sudo nano /etc/haproxy/haproxy.cfg

خيارات عامة في إعداد HAProxy

أول ما يجب فعله هو تحديد قيمة معقولة للحد الأعلى لعدد الاتصالات maxconn. يحدد هذا المتغير عدد الاتصالات الأكبر التي يسمح بها HAProxy في نفس الوقت؛ وهو ما قد يؤثر على جودة الخدمة ويحول دون انهيار خادوم الويب عند محاولته الإجابة على الكثير من الطلبات. يجب أن تبحث وتجرب قيما عدة لإيجاد تلك المناسبة لبيئة عملك. أضف السطر التالي إلى ملف إعداد HAProxy (اخترنا القيمة 2048):

maxconn 2048

أضف السطر التالي لضبط الحجم الأكبر للذاكرة المؤقتة لتخزين مفاتيح التعمية:

tune.ssl.default-dh-param 2048

أضف السطرين التاليين ضمن مقطع defaults مباشرة بعد السطر الذي توجد به mode http:

option forwardfor
option http-server-close

تفعل الأسطر التالية إذا أضيفت ضمن مقطع defaults صفحة إحصاءات HAProxy (أبدل user وpassword بقيم آمنة):

stats enable
stats uri /stats
stats realm Haproxy\ Statistics
stats auth user:password

يمكن بعد التفعيل عرض إحصاءات HAProxy بالذهاب إلى الصفحة التالية https://www.example.com/stats.

لم ننته بعد من ملف إعدادات HAProxy، سنضبط في ما يلي إعدادات الوسيط.

إعداد الوسيط في HAProxy

نبدأ بإضافة نهاية أمامية للتعامل مع اتصالات HTTP الواردة. نضيف في نهاية ملف الإعداد نهاية أمامية باسم www-http عبر الأسطر التالية:

frontend www-http
  bind www.example.com:80
  reqadd X-Forwarded-Proto:\ http
  default_backend app-backend

الهدف من هذا الإعداد هو قبول اتصالات HTTP من أجل توجيهها عبر اتصال HTTPS.

ثم نضيف نهاية أمامية للتعامل مع اتصالات HTTPS، تأكد من تحديد ملف pem المناسب.

frontend www-https
  bind www.example.com:443 ssl crt /etc/ssl/private/www.example.com.pem
  reqadd X-Forwarded-Proto:\ https
  default_backend app-backend

نستكمل الإعداد بضبط النهاية الخلفية:

backend app-backend
  redirect scheme https if !{ ssl_fc }
  server app1 app1.nyc3.example.com:80 check
  server app2 app2.nyc3.example.com:80 check

تحدد النهاية الخلفية خواديم التطبيقات التي يوزَّع بينها الحمل. يطلب السطر:

redirect scheme https if !{ ssl_fc } 

توجيه اتصالات HTTP إلى HTTPS.

احفظ ملف haproxy.cfg ثم أغلقه. HAProxy جاهز الآن لبدء العمل؛ لكن سنفعل أولا السجلات Logs.

تفعيل سجلات HAProxy

افتح ملف rsyslog للتحرير:

sudo nano /etc/rsyslog.conf

ابحث عن الأسطر التالية وانزع علامة التعليق من أجل تفعيل بروتوكول UDP عند استقبال سجلات النظام Syslog. تبدو الأسطر كما يلي بعد نزع علامة التعليق:

$ModLoad imudp
$UDPServerRun 514
$UDPServerAddress 127.0.0.1

أعد تشغيل خدمة rsyslog لتفعيل الإعداد الجديد:

sudo service rsyslog restart

سجل HAProxy مفعَّل الآن وسيُنشأ ملف var/log/haproxy.log/ فور بدء عمل HAProxy.

إعادة تشغيل HAProxy

أعد تشغيل HAProxy لأخذ التعديلات في الحسبان.

sudo service haproxy restart

اكتمل الآن إعداد موزع الحِمل، ننتقل لتثبيت التطبيق (ووردبريس).

تثبيت ووردبريس

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

https://www.example.com/wp-admin/install.php

ستظهر شاشة تثبيت ووردبريس. املأء الحقول بما يناسب ثم انقر على زر التثبيت.

بعد انتهاء تثبيت ووردبريس يصبح التطبيق جاهزا للعمل.

خاتمة

اكتمل الآن إعداد الخواديم المكوِّنة للتطبيق، وهذا الأخير جاهز للاستخدام. يمكنك الدخول بحساب المدير كما يمكن لزوار موقعك الوصول إليه عبر HTTPS عند استخدام اسم النطاق المناسب.

تأكد قبل الانتقال إلى الجزء الموالي من الدليل أن التطبيق يعمل بطريقة صحيحة.

ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Deploying لصاحبه Mitchell Anicas.

حقوق الصورة البارزة: Designed by Freepik.

يعرض هذا الدّرس والذي يُعتبر الأول من سلسلة ذات ستة أجزاء كيفية إعداد بنية تحتية لتطبيق مكوَّن من خواديم عدة، انطلاقا من الصفر. سيحتوي الإعداد النهائي على آليات للنسخ الاحتياطي Backup، المراقبة Monitoring، نُظُم مركزية للسجلات Centralized logging مما يعزز من إمكانية تشخيص المشاكل واستعادة إعدادات التطبيق عند الحاجة. الهدف الأسمى هو إنشاء نظام إدارة قائم بذاته، والتعريف بأهم المفاهيم والاعتبارات العملية التي ينبغي التنبه لها عند إعداد خادوم موجَّه للإنتاج Production server.

ملحوظة: توجد -عادة- أثناء تطوير وإعداد البرامج بيئة إنتاج وبيئة اختبار (أو أكثر). في بيئة الاختبار يستخدم قليلون التطبيق، ويكون المستخدمون في هذه الحالة غالبا مطورين يبحثون عن علل لترقيعها. في الجانب الآخر فإن التطبيق في بيئة الإنتاج يستخدمه المستهدَفون الحقيقيون بالمنتَج (التطبيق)؛ لذا يجب أن يعمل بكفاءة وسلاسة.

قراءة الدّرس التالي وفهمه سيساعدك في المضي قدما مع هذا الدّرس:

• خمسة إعدادات شائعة لتطبيقات الوب.

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

الهدف

سنحصل بنهاية مجموعة المقالات هذه على خادوم إنتاج معدّ لتشغيل تطبيق PHP، ووردبريس على سبيل المثال، يمكن الوصول إليه عبر العنوان https://www.example.com/. سنعدّ أيضا خواديم إضافية لدعم خواديم التطبيق في بيئة الإنتاج. سيبدو الإعداد النهائي على النحو التالي (لا تظهر خواديم نظام إدارة النطاقات DNS الداخلية ولا النسخ الاحتياطية البعيدة في الصورة أدناه):

نعُدُّ الخواديم الموجودة في مربع التطبيق ضرورية ليعمل التطبيق على النحو المرجو. تعمل العناصر المتبقية - النسخ الاحتياطية، المراقبة، والسجلات - بجانب خطة الاستعادة وخادوم النسخ الاحتياطي البعيد؛ على دعم خادوم الإنتاج. سنثبت كل عنصر على خادوم Ubuntu 14.04 منفصل ضمن نفس الحيز الجغرافي مع تفعيل التشبيك الخاص Private networking. نستخدم أسماء المستضيفات Hostnames لتمييز الخواديم المكوِّنة للتطبيق:

• lb1: موزع الحمل HAProxy، يمكن الوصول إليه عبر العنوان https://www.example.com/.
• app1: خادوم تطبيقات Apache و PHP.
• app2: خادوم تطبيقات Apache و PHP.
• db1: خادوم لقاعدة بيانات MySQL.

من المهم التنبيه إلى أنه تم اختيار هذا النوع من الإعداد لتوضيح كيف يمكن لعناصر تطبيق أن تُنشأ على خواديم عدة؛ يجب أن يُخصَّص إعداد تطبيقك بناء على احتياجاتك. توجد نقطة إخفاق Point of failure وحيدة في هذا الإعداد، ويمكن التغلب عليها بتركيب موزع حمل إضافي (وخادوم DNS دوري) ومضاعفة قاعدة البيانات؛ وهو ما لن تطرق إليه في هذا الدرس.

نميز العناصر الداعمة للتطبيق بأسماء المستضيفات التالية:

• النسخ الاحتياطية backups: خادوم النسخ الاحتياطي Bacula.
• المراقبة monitoring: خادوم Nagios.
• السجلات logging: سجلات مركزية باستخدام حزمة برمجيات مكونة من Kibana (ELK)، Logstash و Elasticsearch.

توجد عناصر أخرى لا تظهر في الصورة، وهي:

• ns1: وهو خادومنا الرئيس لنظام أسماء النطاقات. نستخدم Bind لهذا الغرض.
• ns2: وهو الخادوم الثانوي لنظام أسماء النطاقات. نستخدم Bind.
• remotebackups: خادوم بعيد يوجد في منطقة جغرافية أخرى نحفظ عليه نسخ Bacula الاحتياطية احترازا من كارثة تحل بمركز البيانات الذي يوجد فيه التطبيق.

يمكنك أيضا استخدام عنوان IP عائم Floating IP؛ وهو عبارة عن عنوان IP ثابت يُتاح للعموم الوصول إليه ويمكن توجيهه إلى أحد خواديمك الافتراضية أو بنيتك التحتية المكرَّرة Redundant ثم إطلاق موقعك أو خدمتك باستخدام عنوان IP عمومي وحيد. يمكن بعدها إعادة توجيه العنوان العائم إلى خادوم جديد من أجل بيئة إنتاج أكثر مرونة وأسرع تجاوبا. سنضع أيضا خطط استعادة لكلٍّ من العناصر المكونة للتطبيق.

ستكون لدينا، عند بلوغ الهدف النهائي، عشرة خواديم. سننشئها كلَّها في نفس الوقت لتسهيل بعض الأمور مثل إعداد النطاقات؛ ولكن يمكنك إنشاؤها الواحد تلو الآخر حسب الحاجة.

شبكة خاصة افتراضية Virtual Private Network (اختياري)

إذا أردت تأمين اتصالات الشبكة بين خواديمك فيجب عليك إعداد شبكة خاصة افتراضية VPN. يصبح تأمين نقل البيانات عبر الشبكة بتعميتها Encryption أكثر أهمية إذا كانت البيانات تمر عبر الإنترنت. من منافع استخدام شبكة خاصة افتراضية التحقق من هوية المستضيفات بالاستيثاق منها؛ وهو ما يحمي من المصادر التي لا يُرخص لها الوصول للخدمات.

إذا كنت تبحث عن أداة مفتوحة المصدر فيمكنك استخدام OpenVPN واتباع خطوات درس دليلك لكيفية إعداد خادوم OpenVPN على Ubuntu لإعداده.

المتطلبات

يتوجب أن يكون لدى كل خادوم أوبنتو 14.04 حساب مستخدم بصلاحيات إدارية غير المستخدم الجذر؛ يمكن إعداد مستخدم لهذا الغرض باتّباع الخطوات المشروحة في مقال الإعداد الابتدائي لخادوم أوبنتو 14.04. سننفّذ كل الأوامر باستخدام هذا الحساب.

سنفترض أيضا أن لديك معرفة بالمفاهيم الأساسية للأمان في لينكس. إذا رغبت في درس تمهيدي حول الموضوع فيمكن الاطلاع على مقال 7 تدابير أمنيّة لحماية خواديمك.

اسم نطاق

نفترض في هذا المقال أن الوصول إلى التطبيق يكون عبر اسم نطاق، example.com مثلا. إنْ لم يكن لديك اسم نطاق فبالإمكان شراء واحد من أحد مسجلي أسماء النطاقات Domain name registrar.

نحتاج اسم النّطاق ليس فقط لتسهيل الوصول إلى الموقع (مقارنة بعنوان IP المكون من أرقام فقط) بل أيضا للحصول على فوائد التحقق من الهوية والنطاق؛ وهو ما يتيح إمكانية الاستفادة من شهادات SSL التي تعمّي البيانات المنقولة بين التطبيق ومستخدميه.

شهادة SSL

يعمل بروتوكول TLS/SSL على تعميّة البيانات والتحقق من نطاقها أثناء الاتصال بين التطبيق ومستخدميه؛ لذا سنستخدم شهادة SSL لإضافة هذا الإعداد. في المثال نريد أن يصل المستخدمون إلى الموقع عبر العنوان www.example.com وهي القيمة التي سنحددها في الاسم الشّائع للشهادة Common Name (أو ما يُعرف اختصارًا بـ CN). سنثبت الشهادة على خادومHAProxy (المُسمّى lb1) وهو ما يعني أنه من الأفضل توليد مفاتيح الشهادة وطلب توقيع الشهادة Certificate Signing Request CSR على هذا الخادوم.

إذا احتجت للتحقق من الهوية فستحتاج لشراء شهادة SSL. توجد الكثير من سلطات الشهادات Certificate Authorities التجارية التي يمكن شراء شهادة SSL منها. كما توجد إمكانية لاستخدام شهادة مجانية من StartSSL

يتوفر أيضا حل بديل يتمثل في التوقيع الذاتي لشهادة SSL بتنفيذ الأمر التالي:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crt

الخطوات المتبعة للوصول إلى الهدف

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

يحتاج التطبيق إلى أن تكون قاعدة بيانات مهيَّأة سلفا، كما يتطلب موزع الحِمل أن يكون التطبيق جاهزا. انطلاقا من هذه الاعتبارات فإن إعداد العناصر سيكون حسب الترتيب التالي:

1. خادوم قاعدة البيانات.
2. خواديم التطبيق.
3. موزع الحمل.

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

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

خاتمة

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

ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Overview لصاحبه Mitchell Anicas.

حقوق الصورة البارزة: Designed by Freepik.

HHVM هي آلة افتراضية مفتوحة المصدر لتنفيذ الشيفرة المكتوبة بلغتي PHP وHACK. تُطور HHVM وتدعمها فيس بوك، الأمر الذي لفت الانتباه إليها كثيرا في الآونة الأخيرة.

تختلف HHVM عن باقي محركات PHP لأنها تتبع منهج "الترجمة فقط في الوقت المناسب" JIT. HHVM تترجم الشيفرة PHP إلى شيفرة ثنائية وسيطة intermediate byte code ثم بعد ذلك إلى شيفرة بلغة الآلة x64 machine instructions قبيل وقت التنفيذ، هذا الأمر يسمح بكثير من التحسين وسرعة في الأداء مقارنة بالطرق التي تتبعها محركات PHP الأخرى.

HHVM قوية وسريعة ، ولكنها -مقارنة بمحركات PHP الأخرى- تتطلب موارد أكثر من ذاكرة الوصول العشوائي RAM والمعالج CPU، مثلها مثل الآلات الافتراضية الأخرى (JVM مثلا).

في هذه المقالة سوف نبين لك كيف تثبت HHVM وتدمجه مع Nginx.

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

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

من أجل إتمام هذا الدرس وتطبيقه لا بد لك من الأمور التالية:

1. نظام أوبنتو 14.04 مع ذاكرة وصول عشوائي RAM لا تقل عن 1 جيجا.
2. مستخدم عادي له صلاحيات sudo.
3. خادوم Nginx مثبت على النظام.

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

في حال استخدمت أوبنتو 14.04 فإن له مستودعا رسميا يدعم HHVM، ومن أجل إضافة هذا المستودع يجب عليك استيراد المفتاح العام GnuPG بالأمر التالي:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x5a16e7281be7a449

بعد هذا يمكنك تثبيت مستودع HHVM بكل أمان بالأمر التالي:

sudo add-apt-repository "deb http://dl.hhvm.com/ubuntu $(lsb_release -sc) main"

بعد إضافة المستودع يجب عليك تحديث قاعدة بيانات الحزم حتى تنضاف إليها حزم المستودع الجديد وذلك يكون بالأمر التالي:

sudo apt-get update

وأخيرا يمكنك تثبيت HHVM بالأمر التالي:

sudo apt-get install hhvm

الأمر السابق يقوم بتثبيت HHVM وتشغيلها في الوقت نفسه ، ولكي نجعل التشغيل تلقائيا مع تشغيل النظام فلابد لنا من تنفيذ الأمر:

sudo update-rc.d hhvm defaults

الإعدادات

يأتي مع HHVM سكريبت يجعل دمجها مع خادوم Nginx أسهل. ونحن نفترض أنك ثبتّ خادوم Nginx بالطريقة الافتراضية، وعليه يمكنك تنفيذ السكريبت من غير أي مدخلات بالأمر التالي:

sudo /usr/share/hhvm/install_fastcgi.sh

عند تنفيذ هذا السكريبت يقوم بإضافة ملف الإعدادات etc/nginx/hhvm.conf/ إلى الملف الافتراضي لإعدادات Nginx server block ألا وهو الملف etc/nginx/sites-enabled/default/، هذا السكربت يعمل فقط مع الإعدادت الإفتراضية لخادوم Nginx بدون أي تغييرات في FastCGI.

إذا كنت قد غير في إعدادات Nginx server block وإعدادات FastCGI كما هو الشأن في PHP-FPM فيجب عليك استبدال الإعدادات الجديدة بالقديمة يدويا وذلك بالتعديل على الملف etc/nginx/sites-enabled/default/:

location ~ \.(hh|php)$ {
    fastcgi_keep_conn on;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

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

sudo service nginx restart

وأيضا يفترض هذا السكريبت أنك لم تغير إعدادات HHVM التي تجعل الخدمة قابلة للوصول إليها عبر العنوان 127.0.0.1:9000، هذه الإعدادات تأتي افتراضيا في الملف etc/hhvm/server.ini/ الذي محتواه:

; php options

pid = /var/run/hhvm/pid

; hhvm specific

hhvm.server.port = 9000
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.use_log_file = true
hhvm.log.file = /var/log/hhvm/error.log
hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbc

ولعلك لاحظت في هذه الإعدادات لـ HHVM المتغير hhvm.server.port الذي يحدد أن هذه HHVM سوف تستمع على منفذ البروتوكول TCP 9000، وعلى الهوست المحلي localhost ما لم يتم تغيير ذلك.

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

لكي تغير تلك الإعدادات افتح الملف etc/hhvm/server.ini/ بأي محرر نصوص مفضل لديك مثل vim :

sudo vim /etc/hhvm/server.ini

ثم احذف السطر الذي يبدأ بـ hhvm.server.port، وضع في مكانه السطر التالي:

hhvm.server.file_socket=/var/run/hhvm/hhvm.sock

احفظ الإعدادات ثم أعد تشغيل HHVM بالأمر:

sudo service hhvm restart

بعد ذلك يجب عليك أن تجعل الخادوم Nginx يأخذ بعين الاعتبار التغييرات السابقة وذلك بتعديل الملف etc/nginx/hhvm.conf/:

sudo vim /etc/nginx/hhvm.conf

في هذا الملف تأكد أن الموجه fastcgi_pass يشير إلى مقبس HHVM وأنه يظهر بالشكل التالي:

fastcgi_pass unix:/var/run/hhvm/hhvm.sock;

ثم بعد ذلك يجب عليك أن تعيد تشغيل الخادوم Nginx حتى يتم تفعيل تلك التغييرات ، من أجل ذلك نفذ الأمر:

sudo service nginx restart

يمكن للسكريبت usr/share/hhvm/install_fastcgi.sh/ أن يوفر عليك بعض الوقت، ولكن هناك أشياء لابد عليك من فعلها بنفسك لا سيما فيما يخص Nginx server blocks ، مثال على ذلك أن الإعدادات الافتراضية لـ Nginx server blocks إذا طلب منه صفحة index فإنه يفتح فقط الملفين index.html و index.htm عندما يكون سرد المجلدات ممنوعا، هذا أحد الأشياء التي يجب عليك تغييرها لكي يضاف index.php إلى الملفات التي يفتحها الخادوم عند طلب index.

لفعل ذلك افتح ملفات إعدادات server block بمحررك المفضل:

sudo vim /etc/nginx/sites-enabled/default

ثم اذهب إلى الجزء المخصص للخادوم ثم أضف index.php حيث يوجد ملفات index ، سيظهر ذلك الجزء بالشكل التالي:

index index.html index.htm index.php;

مرة اخرى أعد تشغيل خادوم Nginx ليتم تفعيل هذه الإعدادات:

sudo service nginx restart

اختبار وتعديل HHVM

أول اختبار يمكنه أداؤه هو بواجهة أوامر PHP (cli) /usr/bin/php التي تشير إلى etc/alternatives/php/، والتي هي أيضا تشير إلى الملف التنفيذي usr/bin/hhvm/ الخاص بـ HHVM، نفذ الأمر:

/usr/bin/php --version

عندما تنفذ هذا الأمر فإنه ينبغي أن ترى رقم إصدار HHVM ومعلومات أخرى كهذا:

HipHop VM 3.8.1 (rel)
Compiler: tags/HHVM-3.8.1-0-g3006bc45691762b5409fc3a510a43093968e9660
Repo schema: 253b3802ce1bcd19e378634342fc9c245ac76c33

إذا كنت قد ثبتّ PHP من قبل فربما ظهر لك معلومات النسخة القديمة من PHP، من أجل تغيير ذلك وجعله يشير إلى HHVM نفذ هذا الأمر:

sudo /usr/bin/update-alternatives --install /usr/bin/php php /usr/bin/hhvm 60

بعد ذلك يمكنك استعمال الدالة ()phpinfo من أجل إظهار إعدادات وخواص الـ HHVM، لفعل ذلك أنشئ ملفا اسمه info.php في المجلد الافتراضي لخادوم الويب Nginx والذي هو usr/share/nginx/html/ باستخدام محررك المفضل:

sudo vim /usr/share/nginx/html/info.php

ثم أضف فيه الأسطر التالية:

<?php

phpinfo();

?>

إنه من المنصوح به لدى الخبراء أن تجعل كل ملفات الويب التي يشغلها الخادوم Nginx مملوكة للمستخدم الخاص به www-data.

قم بعمل ذلك بالأمر التالي:

sudo chown www-data: /usr/share/nginx/html/info.php

الآن جرب الدخول إلى هذا الملف الذي أنشأته عبر هذا الرابط: http://your_server_ip/info.php.

يجب عليك استبدال your_server_ip بـ IP خادومك، والنتيجة ستكون في متصفحك هكذا:

إذا لم يظهر لك مثل هذه الصورة فتأكد أنك اتبعت الخطوات السابقة بطريقة صحيحة ، ثم تفقد ملف أخطاء الخادوم Nginx الذي مساره var/log/nginx/error.log/ وملف HHVM الذي مساره var/log/hhvm/error.log/.

ارجع الآن إلى متصفحك وأعد النظر تر أن هذه البيانات التي أظهرتها الدالة ()phpinfo هي نفسها التي تظهر مع محركات PHP الأخرى غير أن كل المتغيرات كانت مسبوقة بـ hhvm.

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

كمثال عام، إذا كان نظامك يملك ذاكرة بسعة 2 جيغا فإنه ينبغي عليك تخفيض الحد الأقصى لـ HHVM إلى ما يقارب 1.2 جيغا. لفعل ذلك عدّل الملف etc/hhvm/php.ini/ بمحررك المفضل:

sudo vim /etc/hhvm/php.ini

ثم أضف المتغير الجديد بعد القسم ; php options

memory_limit = 1200M

بالطريقة نفسها يمكنك تغيير أي شيء تريده في إعدادات PHP ، فقط تأكد دائما أن تعيد تشغيل HHVM بعد انتهائك من التغييرات بالأمر:

sudo service hhvm restart

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

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

مع ذلك وفي بعض الحالات النادرة قد تحتاج لتثبيت وحدة إضافية لـ HHVM. على سبيل المثال إذا كنت تستخدم PostgreSQL بمثابة خادوم قاعدة البيانات فسوف تحتاج إلى وحدة pgsql. في مثل هذه الحالات راجع الوثائق الرسمية لـ HHVM.

الخلاصة

كما رأيت في هذا المقال فإن HHVM سهلٌ تثبيتها سهل إعدادها سهل دمجها مع خادوم الويب Nginx. فإن كان لديك ما يكفي من الموارد فينبغي أن تجربها ثم ترى كيف يعمل منهج JIT الذي تتبعه HHVM من حيث الأداء والاستقرار. لابد من سبب وجيه لموقع مثل فايس بوك بوظائفه المعقدة وحركة بيانات لا مثيل لها أن تثق به. وأما المواقع الصغيرة التي لها حركة بيانات أقل فأولى لها أن تختار حلولا أقل استهلاكا للذاكرة مثل PHP-FPM، فإنه بالتأكيد أفضل خيار.

مقال مترجم من How To Install HHVM with Nginx on Ubuntu 14.04 للكاتب Anatoliy Dimitrov.

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

سنقوم في هذا الدّرس بمناقشة بعض الطرق المختلفة لتوفير النسخ الاحتياطي ووفرة البيانات data redundancy، ولأنّ حالات الاستخدام المختلفة تتطلّب حلولًا مختلفة فلن نكون قادرين على إعطاء إجابة تناسب جميع الحالات، ولكن سنتعلّم ما هو الشيء المهم في حالات مختلفة وما هو التّنفيذ implementation (أو التّنفيذات implementations) الأكثر مُلاءَمة لهذه العمليّة.

سنناقش في هذا الدرس الحلول المختلفة التي يُمكننا استخدامها للنسخ الاحتياطي والمزايا النسبيّة لكلّ واحدة منها بحيث نستطيع اختيار الخطّة التي تناسب البيئة التي نعمل عليها.

ما الفرق بين وفرة البيانات Redundancy والنسخ الاحتياطي Backing Up؟

غالبًا ما نجد تداخل في معظم الحالات بين المصطلحين وفرة البيانات redundant والنسخ الاحتياطي backup، وهما مفهومان مميّزان مرتبطان ببعضهما ولكنّهما مختلفان، وبعض الحلول تُوفِّرهما معًا.

1. وفرة البيانات Redundancy

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

وبينما يبدو هذا وكأنّه حل رائع لتخديم النسخ الاحتياطي فإنّ هذا في الحقيقة فكرة خاطئة خطيرة، فلا تُزوِّدنا وفرة البيانات بحماية ضدّ الفشل الذي يؤثر على كامل الآلة أو النّظام، على سبيل المثال إن كُنّا نملك mirrored RAID مضبوط (مثل RAID1) فستكون بياناتنا متوافرة فيه وفي حال فشل أحد الأقراص سيبقى الآخر متوافرًا، ولكن إن فشلت الآلة نفسها فقد نفقد جميع البيانات الخاصّة بنا.

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

2. النسخ الاحتياطي Backup

كما أشرنا سابقًا فإنّه من المُحتّم علينا الحفاظ على نُسَخ احتياطيّة تعمل بشكل جيّد لبياناتنا الهامّة، واعتمادًا على الموقف فقد يعني هذا النسخ الاحتياطي للتطبيق أو لمعلومات المستخدمين أو حتى لكامل الموقع أو الآلة، والفكرة من وراء النُسَخ الاحتياطيّة أنّه في حال حدوث فقدان في النّظام أو الآلة أو البيانات فإنّنا نستطيع استعادة restore، إعادة نشر redeploy، أو الوصول إلى بياناتنا، قد تتطلّب الاستعادة من نسخة احتياطيّة زمن إيقاف تشغيل، ولكن يوجد فرق بين البدء من نقطة في اليوم السابق والبدء من الصفر، أي شيء لا نستطيع تحمل خسارته -بالتعريف- يجب علينا عمل نسخة احتياطية له.

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

النُّسَخ الاحتياطيّة بحد ذاتها لا تزوّدنا بتجاوز الفشل تلقائيًا، وهذا يعني أنّ الفشل لن يُكلّفنا خسارة أيّة معلومات (على اعتبار أنّ النُسَخ الاحتياطيّة التي نملكها حديثة 100%)، ولكن قد يُكلفنا زمن تشغيل Uptime، وهذا هو أحد الأسباب التي تجعلنا نستخدم وفرة البيانات والنَسخ الاحتياطي جنبًا إلى جنب بدلًا من أن تُلغي كلّ واحدة منهما الأخرى.

النسخ الاحتياطي على مستوى الملف File-Level Backup

إنّ النَسخ الاحتياطي على مستوى الملف هو واحد من أشيع أشكال النَسخ الاحتياطي، يستخدم هذا النّوع من النَّسخ الاحتياطي أدوات النسخ الاعتياديّة الموجودة مع النّظام لنقل الملفات إلى موقع أو جهاز آخر.

1. كيفية استخدام الأمر cp

أبسط أشكال النَّسخ الاحتياطي لآلة تعمل بنظام لينِكس مثل الـ VPS هي عن طريق الأمر cp، ينسخ هذا الأمر ببساطة الملفات من موقع محلّي local إلى موقع آخر، ونستطيع على حاسوب محلّي وصْل mount قُرص قابل للإزالة وبعدها نسخ الملفات إليه:

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

يقوم هذا المثال بوصْل قرص قابل للإزالة ومن ثُمّ ينسخ الدّليل etc/ إلى القرص، وبعدها يقوم بإلغاء وصْل unmount القرص، والذي يُمكننا تخزينه في مكان آخر.

2. كيفية استخدام الأمر Rsync

إنّ الأمر rsync هو بديل أفضل للأمر cp، حيث يُمكّننا من إجراء نُسَخ احتياطيّة محليّة مع قَدْر أكبر من المرونة، نستطيع تنفيذ نفس العمليّات السابقة باستخدام rsync عن طريق الأوامر التالية:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

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

يستطيع الأمر Rsync تنفيذ نُسخ احتياطيّة عن بُعد remote بنفس السهولة التي يستطيع القيام بها بنُسخ احتياطيّة محليّة، يجب علينا فقط استخدام صيغة بديلة، سيعمل هذا الأمر على أي مُضيف host نستطيع الدخول إليه عن طريق SSH طالما أنّ rsync مُثبّت لدى الطرفين:

rsync -azvP /etc/* username@remote_host:/backup/

سيقوم هذا الأمر بالنسخ الاحتياطي للدليل etc/ الموجود على الجّهاز المحلّي إلى دليل على remote_host موجود في backup/.
سينجح هذا الأمر إن كُنّا نملك صلاحيات للكتابة على هذا الدّليل وتوجد مساحة كافية.

للمزيد من المعلومات حول كيفيّة استخدام rsync للنّسخ الاحتياطي اضغط هنا.

3. كيفية استخدام أدوات أخرى للنسخ الاحتياطي

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

Bacula

إنّ أداة Bacula هي حل مُركّب ومرن يُعزّز نموذج خادوم عميل للنسخ الاحتياطي للمضيفين hosts، تفصل Bacula بين أفكار العملاء، أماكن النسخ الاحتياطي والإدارة directors (المُكوِّن الذي يُنسّق النسخ الاحتياطي الفعلي)، وتقوم أيضًا بضبط كل مهمّة نسخ احتياطي ضمن وحدة تدعى الوظيفة job.

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

لكي تتعلّم المزيد حول كيفيّة تضبيط خادوم Bacula للنسخ الاحتياطي وكيفيّة النسخ الاحتياطي للأنظمة عن بعد باستخدام Bacula، قم بزيارة هذه الروابط.

BackupPC

من الحلول الشائعة الأخرى هي أداة BackupPC، يُمكن استخدام هذه الأداة للنسخ الاحتياطي لأنظمة لينِكس وويندوز بسهولة، يتم تنصيبها على جهاز أو VPS والذي سيعمل كخادوم للنسخ الاحتياطي، وبعدها يسحب الخادوم البيانات من عملائه باستخدام طرق نقل الملفّات المُعتادة.

يُقدّم هذا الإعداد ميزة تنصيب جميع الحِزَم packages المتعلّقة بذلك على جهاز مركزي واحد، والتضبيط الوحيد الذي نحتاجه هو السماح لخادوم النسخ الاحتياطي بالوصول عبر SSH، يُمكن بسهولة إعداد هذا، وباستخدام DigitalOcean نستطيع تضمين مفاتيح SSH لخادوم BackupPC إلى العملاء بينما نقوم بالنشر، يسمح لنا هذا بضبط النسخ الاحتياطيّة من خادوم النسخ الاحتياطي بسهولة ونشر بيئات الإنتاج الخاصّة بنا بشكل نظيف بدون أيّة برمجيّات إضافيّة.

لكي تتعلّم كيفيّة تثبيت واستخدام BackupPC على خادوم، اضغط هنا.

Duplicity

Duplicity هي بديل رائع للأدوات التقليديّة، الميّزة الأساسيّة للتفاضل في Duplicity هي أنها تستخدم تعمية GPG encryption لنقل وتخزين البيانات، ولهذا بعض الفوائد الرائعة.
إنّ الفائدة الواضحة من استخدام تشفير GPG للنسخ الاحتياطي للملفّات هي أنّه لا يتم تخزين البيانات بشكل نص مُجرَّد plain text.

الشّخص الوحيد الذي يستطيع فكّ تعمية decrypt البيانات هو من يملك مفتاح GPG key، يُوفِّر هذا درجة من الحماية لتعويض تضخّم التدابير الأمنية اللازمة عندما يتم تخزين البيانات في مواقع مُتعدّدة.
الفائدة الأخرى التي قد لا تكون واضحة بشكل فوري للأشخاص الذين لا يستخدمون GPG عادةً هي أنّه يتمّ التّحقّق من كل عمليّة نقل لتكون دقيقة تمامًا، تفرض GPG فحص تلبيد Hash صارم للتأكّد من عدم وجود ضياع في البيانات أثناء النقل، ويعني هذا أنّه عندما يحين الوقت لاستعادة البيانات من النُسخة الاحتياطيّة سنكون أقل عُرضة للوقوع في مشاكل تَلَف الملفات.

لكي تتعلّم كيفيّة تمكين النُسخ المُشفّرة باستخدام GPG في Duplicity، اتبع هذا الرابط.

النسخ الاحتياطي على مستوى الكتلة Block-Level Backups

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

يسمح النسخ الاحتياطي على مستوى الكُتلة بالنسخ على مستوى أعمق من الملف، فبينما يقوم النسخ الاحتياطي على مستوى الملف بنسخ الملف1، الملف2، والملف3 إلى موقع نسخ احتياطي، يقوم النسخ الاحتياطي على مستوى الكُتلة بنسخ كامل الكُتلة Block التي تحتوي على هذه الملفات، ولتفسير المفهوم بطريقة أخرى يمُكننا القول أنّ النسخ الاحتياطي على مستوى الكتلة ينسخ المعلومات بِت bit تلو الآخر، فهو لا يهتم بالملفات المُجرّدة التي قد تُمثّلها هذه البتّات bits (ولكن سيتم نقل الملفّات بشكل كامل خلال هذه العمليّة).

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

استخدام الأداة dd لتنفيذ عمليات النسخ الاحتياطي على مستوى الكتلة

إنّ أبسط طريقة لتنفيذ عمليّات النسخ الاحتياطي على مستوى الكُتلة هي باستخدام الأداة dd، هذه البرمجيّة مرنة جدًا وتتيح لنا نسخ المعلومات بِت تلو الآخر إلى مكان جديد، ويعني هذا أنّنا نستطيع النسخ الاحتياطي لقسم partition أو قرص disk إلى ملف واحد أو إلى جهاز raw device بدون أي خطوات تمهيدية.

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

dd if=/path/of/original/device of=/path/to/place/backup

في هذه الحالة تُحدّد =if جهاز الدخل input أو موقع، تُشير =of إلى ملف الخرج output أو موقع، من الهام جدًا تذكّر هذا الفرق، لأنّه من البديهي مسح قرص كامل إن تمّ عكسهما.

إن كُنّا نرغب بالنسخ الاحتياطي لقسم يحتوي على مُستنداتنا الموجودة في dev/sda3/ نستطيع إنشاء ملف صورة كما يلي:

dd if=/dev/sda3 of=~/documents.img

تُوجد العديد من الحلول الأخرى للنسخ الاحتياطي على مستوى الكتلة متوفّرة على أجهزة لينِكس، ولكنّنا لن نناقشهم هنا.

إصدارات النسخ الاحتياطية

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

الطريقة اليدويّة لإنجاز هذا هي إنشاء ملف نسخة احتياطية قبل التعديل كما يلي:

cp file1 file1.bak
nano file1

نستطيع أيضًا أتمتة هذه العمليّة عن طريق إنشاء ملفّات مخفيّة ذات ختم زمني timestamped في كل مرّة نقوم فيها بتعديل ملف عن طريق المُحرّر، على سبيل المثال نستطيع وضع ما يلي في ملف bashrc./~ :

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

عندما نستدعي الآن الأمر nano سيقوم تلقائيًا بإنشاء نُسَخ احتياطيّة.

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

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

نستطيع إنشاء مستودع git repository في الدليل الرئيسي فورًا، ببساطة عن طريق كتابة ما يلي:

cd ~
git init

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

git add .
git commit -m "Initializing home directory"

نستطيع ببساطة الانتقال إلى موقع بعيد remote location نظام git المُضمَّن أيضًا:

git remote add backup_server git://backup_server/path/to/project
git push backup_server master

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

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

النسخ الاحتياطي على مستوى VPS، ومزود DigitalOcean كنموذج

في حين أنّه من المهم إدارة النُسخ الاحتياطيّة بأنفسنا، تُزوّدنا خدمة DigitalOcean مثلا ببعض الآليات لإكمال النسخ الاحتياطيّة الخاصّة بنا.
نمتلك دالّة للنسخ الاحتياطي تقوم بانتظام بعمل نُسَخ احتياطيّة تلقائيّة من أجل droplets (مصطلح مقابل لـ VPS على DigitalOcean) التي تُمكّن هذه الخدمة، نستطيع تشغيلها خلال إنشاء droplet عن طريق اختيار صندوق التأشير "تمكين النُسَخ الاحتياطيّة" "Enable Backups":

سيقوم هذا بأخذ نُسخة احتياطيّة لكامل صورة الـ VPS، وهذا يعني أنّنا نستطيع بسهولة إعادة النشر من النُسخة الاحتياطيّة أو استخدامها كأساس للـ droplets الجديدة.

ولأخذ صورة لمرّة واحدة عن النظام لدينا نستطيع إنشاء لقطات snapshots، والتي تعمل بصورة مشابهة للنُسَخ الاحتياطيّة ولكنّها غير مؤتمتة، نستطيع إنشاءَها عن طريق الذهاب إلى droplet لدينا واختيار "Snapshots" من القائمة العلويّة:

ترجمة -وبتصرّف- للمقال How To Choose an Effective Backup Strategy for your VPS لصاحبه Justin Ellingwood.

حقوق الصورة البارزة: Designed by Freepik.

في هذا الدرس، سنشرح طريقة تثبيت Icinga على Ubuntu 14.04. نظام المراقبة Icinga هو نظام مفتوح المصدر لمراقبة الخواديم والخدمات. سنغطّي بعض الإعدادات الأساسية التي ستجعلك قادرًا على مراقبة خدمات الشبكة وموارد الجهاز المستضيف عبر واجهة الويب. سنستخدم أيضًا مشغّل ملحق Nagios البعيد (NRPE - Nagios Remote Plugin Executor)، والذي سيتم تثبيته كعميل (agent) على أنظمة بعيدة (remote systems) لمراقبة مواردها المحلّية (استخدام الأقراص، عدد المستخدمين المسجّلين للدخول.. إلخ).

Icinga هو عبارة عن تطبيق مراقبة أنظمة شهير ومفتوح المصدر يعمل على مراقبة الأجهزة المستضيفة والخدمات، ويقوم أيضًا بتنبيهك دوريًا عن حالتها. Icinga هو عبارة عن اشتقاق (Fork) من Nagios، لذا فهما متوافقان مع بعضهما البعض ويتشاركان بالعديد من الأمور، وقد اكتسب Icinga شعبيةً بسبب عملية تطويره الأكثر سرعةً مقارنةً بـNagios.

المتطلبات

لإكمال هذا الدرس، ستحتاج إلى إمكانية استخدام صلاحيات الجذر على خادوم Ubuntu 14.04. يمكن العثور على إرشادات إعداد هذه الصلاحيات من هنا.

أيضًا، إذا كنتَ تريد إعداد ميّزة التنبيه عبر البريد الإلكتروني، فستحتاج إلى القيام بإعداد Postfix بطريقةٍ صحيحة. يمكن العثور على إرشادات القيام بذلك من هنا. يتم تثبيت Postfix مع حزم Icinga، ولكن يمكن إعداده لاحقًا بعد أن يتم تثبيت Icinga.

تثبيت Icinga

سينقوم بتثبيت Icinga باستخدام الحزم. أيضًا، سنقوم باستخدام MySQL كقاعدة بيانات.

قم بتطبيق الأمر التالي لإضافة مستودع Icinga إلى مدير الحزم الخاصّ بك:

sudo add-apt-repository ppa:formorer/icinga

ثمّ قم بتحديث قاعدة الحزم الخاصّة بك:

sudo apt update

والآن قم بتثبيت Icinga وMySQL عبر الأمر:

sudo apt install icinga icinga-doc icinga-idoutils mysql-server libdbd-mysql mysql-client

سيتم سؤالك عن أكثر من شيء أثناء عملية التثبيت. إليك قائمة بالأمور التي سيتم سؤالك عنها وكيف يجب أن تجاوب عليها:

• إعداد MySQL: قم بإدخال كلمة مستخدم جذر جديدة لـMySQL.
• إعداد Postfix: اختر "Internet Site".
• إعداد Postfix: قم بإدخال نطاقك المؤهّل الذي تستعمله (example.com مثلًا).
• إعداد icinga-cgi: قم بإدخال كلمة مرور للمستخدم "icingaadmin" (ستحتاجها لتسجيل الدخول إلى لوحة التحكّم لاحقًا).
• إعداد icinga-common: اختر "No" لتفعيل الأوامر الخارجية.
• إعداد icinga-idoutils: اختر "Yes" لإعداد قاعدة بيانات لـicinga-idoutils باستخدام dbconfig-common.
• إعداد icinga-idoutils: اختر "mysql" كنوع قاعدة البيانات.
• إعداد icinga-idoutils: أدخل كلمة مرور المستخدم الجذر (root) الخاصّ بقاعدة البيانات (التي قمتَ بإدخالها أولًا).
• إعداد icinga-idoutils: قم بإدخال كلمة مرور جديدة لمستخدم قاعدة البيانات الخاصّة بـicinga-idoutils.

هكذا يكون تثبيت Icinga مكتملًا، ولكننا مانزال بحاجة إلى إعداد بضع أمور قبل أن نتمكّن من تشغيله. لاحظ أنّ خادوم Apache وPostfix قد تمّ تثبيتهما تلقائيًا أثناء تثبيت Icinga كاعتماديات.

قم بإضافة المستخدم الرئيسي لخادوم Apache والذي يدعى www-data إلى مجموعة nagios:

sudo usermod -a -G nagios www-data

قم بتفعيل عفريت ido2db لكي يبدأ عند الإقلاع، والذي يقوم بتخزين أحداث وإعدادات Icinga في قاعدة البيانات. لتعديل إعدادات Icinga الافتراضية:

sudo vi /etc/default/icinga

قم بتغيير قيمة IDO2DB إلى yes لتبدو بالشكل التالي:

IDO2DB=yes

احفظ الملفّ واخرج، وقم بإعادة تشغيل خدمة ID02DB:

sudo service ido2db start

قم بتفغيل وحدة idomod عبر نسخ ملفّ عيّنة idoutils.cfg إلى مجلّد إعدادات Icinga الحالي:

sudo cp /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample /etc/icinga/modules/idoutils.cfg

والآن أصبح Icinga مضبوطًا وجاهزًا للبدء:

sudo service icinga restart

والآن فلنجرّب واجهة Icinga الرسومية.

الوصول إلى واجهة Icinga الرسومية

اذهب إلى http://yourhost/icinga ، وقم بتسجيل الدخول باستخدام مستخدم icingaadmin وكلمة المرور الخاصّة به اللذان قمت بإعدادهما مسبقًا.

يجب أن ترى أنّه Icinga يقوم حاليًا بمراقبة مستضيفٍ واحدٍ فقط هو localhost (خادومك الحالي) و7 خدمات كالتالي:

يعرض الصفّ الأوّل أنّ المستضيف الوحيد الذي يتم مراقبته حاليًا فعّال، ويظهر الصفّ السفلي أنّه هناك 7 خدمات يتم مراقبتها حاليًا وتعمل بشكلٍ جيّد.

إذا كانت حالة localhost هي "Down"، فحينها ربّما تحتاج إلى تغيير صلاحيات الأمر ping الخاصّ بك. شغّل الأمر التالي للسماح للمستخدم nagios باستخدام الأمر ping:

sudo chmod u+s `which ping`

طرق المراقبة بواسطة Icinga

هناك طريقتان رئيسيتان لمراقبة المستضيفين والخدمات بواسطة Icinga:

1. مراقبة "الخدمات العموميّة المتوفّرة".
2. المراقبة عبر عميل مثبّت على جهاز مستضيف (host) بعيد لجمع وإرسال البيانات إلى Icinga.

عند استخدام الطريقة الأولى، تشير الخدمات العمومية العامّة إلى الخدمات التي يمكن الوصول إليها عبر الشبكة المحلّية أو الإنترنت. الأمثلة الأكثر شيوعًا لذلك هي HTTP, البريد، SSH وICMP Ping. هذه الطريقة مفيدة لمراقبة الأنظمة التي لا يمكنك (أو لا تريد) تثبيت عميل (agent) عليها، وأيضًا لمراقبة واجهات الشبكة المقابلة للمستخدم.

لتضمين الطريقة الثانية، سنقوم بتثبيت NRPE كعميل خاصّ بنا على المستضيفين البعيدين (remote hosts) لمراقبة مواردهم المحلّية. سيسمح هذا لـIcinga بمراقبة أشياء مثل استخدام القرص، العمليات التي تعمل حاليًا وأمورٍ أخرى بالنظام لا يمكن للطريقة الأولى مراقبتها.

الطريقة 1: مراقبة الخدمات العمومية المتوفرة

بسبب أنّ الطريقة الأولى تقوم ببساطة بمراقبة الخدمات المُشغّلة حاليًا، فإنّ إعداد هذه الطريقة سيكون بأكمله على خادوم Icinga. يمكن مراقبة العديد من الأشياء باستخدام هذه الطريقة، لذا سنوضّح كيفية مراقبة واجهة عمومية (public interface) لخادوم ويب.

أنشئ ملفًّا باسم المستضيف الخاصّ بك، باستخدام هذا الأمر (استبدل yourhost باسم المستضيف عندك):

sudo vi /etc/icinga/objects/yourhost.cfg

الآن قم بإضافة السطور التالية، حيث ستستبدل host_name باسم المستضيف الخاصّ بك (في كلا المكانين)، alias بوصف للمستضيف و address بعنوان الـIP العمومي الخاصّ بالمستضيف:

define host {
        use                     generic-host
        host_name               web-1
        alias                   A Web Server
        address                 107.170.xxx.xxx
}

define service {
        use                     generic-service
        host_name               web-1
        service_description     HTTP
        check_command           check_http
}

احفظ الملفّ واخرج، وقم بإعادة تحميل إعدادات خدمة Icinga لكيّ تأخذ التغييرات مجراها:

sudo service icinga reload

الطريقة 2: المراقبة باستعمال عميل (Agent)

كما ذكرنا سابقًا، سنستخدم NRPE كعميلنا الافتراضي لجلب البيانات من مستضيفٍ بعيد إلى Icinga. هذا يعني أنّه يجب تثبيت NRPE على جميع الأجهزة والخواديم المستضيفة التي سيتم مراقبتها باستخدام هذه الطريقة، وسيجب أيضًا إعداد خادوم Icinga ليستقبل البيانات من كلّ الأجهزة المستضيفة (hosts).

فلنقم بتثبيت NRPE.

تثبيت NRPE على مستضيف بعيد

قم بتطبيق الأمر التالي على الخادوم الذي تريد أن يتم مراقبته لتحديث قاعدة بيانات الحزم:

sudo apt update

والآن قم بتثبيت NRPE وملحقات Nagios:

sudo apt install nagios-plugins nagios-nrpe-server

ابحث عن اسم نظام ملفّات الجذر الخاصّ بك (لأنّه واحدٌ من الأشياء التي نريد مراقبتها):

df -h /

سنستخدم اسم نظام الملفّات في إعدادات NRPE لمراقبة استخدام القرص الصلب (سيكون غالبًا /dev/vda/). الآن قم بفتح ملفّ nrpe.cfg للتعديل:

sudo vi /etc/nagios/nrpe.cfg

ملفّ إعدادات NRPE طويلٌ جدًا ومليء بالتعليقات. هناك القليل من السطور التي يجب عليك تعديلها فقط:

• server_address: قم بتغييره إلى عنوان الـIP الخاصّ لهذا المستضيف.
• allowed_hosts: قم بتعيين هذا إلى عنوان الـIP الخاصّ لخادوم Icinga الخاصّ بك.
• [command[check_hda1: غيّر dev/hda1/ إلى اسم نظام الملفّات الجذر الخاصّ بك الذي حصلت عليه من الخطوة السابقة.

يجب أن تبدو السطور الثلاثة كشيءٍ مشابه للتالي بعد التعديل:

server_address=client_private_IP
allowed_hosts=nagios_server_private_IP
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/vda

لاحظ أنّه هناك العديد من الأوامر الأخرى المعرّفة في هذا الملفّ التي سيتم تشغيلها في حال ما إذا تمّ ضبط Icinga ليستعملها. لاحظ كذلك أنّ NRPE سيعمل على المنفذ 5666 لأنّ الخيار server_port مضبوط على القيمة 5666. إذا كنتَ تمتلك أيّ جدارٍ ناري يمنع ذلك المنفذ، فيجب عليك فتحه لخادوم Icinga.

احفظ الملفّ واخرج، وقم بإعادة تشغيل NRPE ليتم تطبيق التغييرات:

sudo service nagios-nrpe-server restart

بمجرّد ما أن تنتهي من تثبيت وإعداد NRPE على أجهزة المستضيفين التي تريد مراقبتها، سيجب عليك إضافة هؤلاء المستضيفين (hosts) إلى إعدادات خادوم Icinga الخاصّ بك قبل أن يبدأ بمراقبتهم.

إضافة مستضيف بعيد إلى إعدادات خادوم Icinga

على خادوم Icinga الخاصّ بك، قم بإنشاء ملفّ إعداداتٍ جديد لكلّ واحدٍ من الأجهزة المستضيفة البعيدة التي تريد مراقبتها في etc/icinga/objects/ واستبدل yourhost باسم المستضيف الذي تريده:

sudo vi /etc/icinga/objects/yourhost.cfg

قم بإضافة تعريف المستضيف التالي إلى الملفّ، واستبدل قيمة host_name باسم المستضيف البعيد الخاصّ بك (استعملتُ wordpress-1 في مثالي)، قيمة alias بوصف للمستضيف وقيمة address بعنوان الـIP الخاصّ للمستضيف البعيد:

define host {
        use                     generic-host
        host_name               wordpress-1
        alias                   My first wordpress server
        address                 10.128.xxx.xxx
        }

ثمّ قم بإضافة أيّ واحدٍ من أقسام الخدمات التي تريد مراقبتها. لاحظ أنّ قيمة check_command تحدد مالذي سيتم مراقبته. إليك بعض الأمثلة على ما يمكنك إضافته إلى ملفّ الإعدادات الخاصّ بالمستضيف البعيد الخاصّ بك:

Ping:

define service {
        use                             generic-service
        host_name                       wordpress-1
        service_description             PING
        check_command                   check_ping!100.0,20%!500.0,60%
        }

SSH (عند تعيين notifications_enabled إلى 0 فإنّه يتم تعطيل التنبيهات للخدمة)

define service {
        use                             generic-service
        host_name                       wordpress-1
        service_description             SSH
        check_command                   check_ssh
        notifications_enabled           0
        }

الحمل(Load):

define service {
        use                             generic-service
        host_name                       wordpress-1
        service_description             Current Load
        check_command                   check_load!5.0!4.0!3.0!10.0!6.0!4.0
        }

المستخدمون الحاليون:

define service {
        use                             generic-service
        host_name                       wordpress-1
        service_description             Current Users
        check_command                   check_users!20!50
        }

مساحة القرص:

define service {
        use                             generic-service
        host_name                       wordpress-1
        service_description             Disk Space
        check_command                   check_all_disks!20%!10%
        }

إذا كنت تتسائل عن معنى use generic-service، فهي عبارة عن خيار يقوم ببساطة بجلب قِيَم قالب خدمة يدعى "generic-service" المعرّف افتراضيًا.

الآن احفظ الملفّ واخرج. وقم بإعادة تحميل إعدادات Icinga:

sudo service icinga reload

مثال على واجهة المستخدم

بعد ضبط إعدادات المراقبة على بعض أجهزة المستضيفين بواحدٍ من الطرق المتوفّرة، اذهب إلى واجهة الويب الخاصّة بـIcinga على http://youricingaserver.com/icinga وأدخل اسم المستخدم وكلمة المرور اللذين أدخلتهما أثناء التثبيت. واضغط على رابط "Service Link". يجب أن ترى قائمة بجميع الخدمات التي قمتَ بتجهيزها ليتم مراقبتها حاليًا.

كمثال، إليك مستضيفين اثنين يتم مراقبتهما باستخدام ملفّات الإعدادات التي وصفناها بالأعلى. يتم مراقبة خدمة web-1HTTP عبر منفذ HTTP العادي الخاصّ بها، وهي حاليًا تخبرنا أنّ كلّ شيءٍ يعمل بشكلٍ جيّد، وwordpress-1 يخبرنا أيضًا أنّ جميع خدماته التي نراقبها تعمل بشكلٍ جيّد حاليًا.

يمتلك Icinga الكثير من المزايا، يمكنك تصفّح واجهة الويب لاستكشاف المزيد عن المستضيفين والخدمات التي تراقبها.

الخاتمة

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

ترجمة -وبتصرف- للمقال: How To Use Icinga To Monitor Your Servers and Services On Ubuntu 14.04 لصاحبه: Mitchell Anicas.

حقوق الصورة البارزة: Designed by Freepik.

سنشرح اليوم فكرة التوفّر أو تكرار البيانات (redundancy). البيانات المُكررة ليست نسخةً احتياطية، بل هي بيانات يمكن أن تساعدك على تجاوز عمليات فشل الأقراص (disks fail) في حال ما إذا تعذّر عليك الوصول إلى بيانات الأقراص الصلبة عبر الطريقة الأساسية التي تستعملها.

تعتمد طريقة تشغيل النسخ المتماثل (replication) على نظامك على كيفية استعمالك لبياناتك، الأخطاء التي تريد تجنّبها وكيفيّة تفاعل زوّارك مع خادومك.

الوفرة العالية عبر RAID

ربّما يكون أشهر أنواع النسخ المتماثل (replication) هو تقنية RAID. ترمز RAID إلى "مصفوفة تكرار الأقراص المستقلة - Redundant Array of Independent Disks". يعني هذا أنّه وفي غالب الأحيان، تعمل الأقراص كمرايا (mirrors) لبعضها البعض.

التطبيق الأكثر شيوعًا لتقنية RAID هو مصفوفة RAID 1. يقوم هذا النوع من المصفوفات بتمرير (mirror) قرصٍ صلب ما على قرصٍ صلبٍ آخر. يعني أنّه وفي حال فشل القرص الصلب الأوّل، فسيبقى القرص الصلب الثاني موجودًا للخدمة وكتابة البيانات. يسرّع هذا النوع من المصفوفات عملية القراءة من الأقراص بسبب توفّر البيانات في أكثر من مكان وبالتالي يستطيع النظام قراءتها من أيّ موقعٍ يريد من الموقعين المتوفّرين.

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

يتم تطبيق تقنية RAID في المستوى المنخفض (low-level)، هذا يعني أنّك لن تستطيع التحكّم بتقنية RAID وخصائصها أو تضمينها على خادومك الافتراضي الخاصّ على شركة DigitalOcean مثلا، إن كان خادومك على مزود آخر، فراجع دليل المساعدة الخاص بالمزود.

تكرار البيانات على مستوى الكتل Block-Level

من الطرق الأخرى للقيام بعملية تكرار البيانات (Redundancy) هي عبر تمرير هيكلة الكُتَل (Blocks) بالكامل. DRBD أو "جهاز الكُتَل المكررة الموزّع - Distributed Replicated Block Device"، هو عبارة عن طريقة يمكن تطبيقها للقيام بعملية تكرار البيانات على امتداد أجهزة الكُتَل (Block Devices).

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

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

النسخ المتماثل في SQL

إذا كانت بياناتك المهمّة مخزّنة في قاعدة بيانات SQL (مثل MySQL ،MariaDB ،PostgreSQL، ..)، فيمكنك الاستفادة من بعض مزايا النسخ التكراري أو النسخ المتماثل المضمّنة بالفعل. يمكن لهذه المزايا أن توفّر لك نظام استرجاع في حال تعطّل نظامك الرئيسي.

النسخ المتماثل بـ Master-Slave

النوع الأساسي للنسخ التكراري أو المتماثل (replication) الخاصّ بـSQL هو إعداد Master-Slave. في هذا السيناريو، تمتلك خادوم قاعدة بيانات رئيسي، والذي يتم الإشارة إليه باسم السيّد أو "Master". هذا الخادوم هو المسؤول عن تنفيذ جميع مهام الكتابة والتحديثات. يتم نسخ البيانات من هذا الخادوم بشكلٍ مستمر إلى الخادوم الفرعي أو "slave". يمكن أيضًا القراءة من هذا الخادوم، ولكن لا يمكن الكتابة عليه.

يسمح لك هذا التثبيت بتوزيع البيانات على امتداد أجهزة متعددة، والذي يمكنه تحسين أداء تطبيقك بشكل ملحوظ.

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

نسخ Master-Slave المتماثل في الواقع هو مكان من الأماكن التي يمكننا أن نلاحظ فيها تكامل عمليتيّ النسخ الاحتياطي والنسخ المتماثل. في إعداد master-slave، يمكنك نسخ البيانات بشكلٍ متماثل من الخادوم السيّد أو الرئيسي إلى الخادوم الفرعي. يمكنك بعدها تعطيل النسخ المتماثل بشكلٍ مؤقّت لمعرفة حالة المعلومات وصيانتها على الخادوم الفرعي. من هنا، يمكنك عمل نسخة احتياطية من قاعدة البيانات باستخدام أيّ أداة نسخ احتياطي تريدها.

يمكنك قراءة المزيد عن: إعداد النسخ المتماثل بـMaster-Slave لـMySQL أو إعداد النسخ المتماثل بـMaster-Slave لـPostgreSQL.

النسخ المتماثل بـMaster-Master

النوع الثاني من النسخ المتماثل يدعى "Master-Master" أو من خادومٍ رئيسي إلى خادومٍ رئيسي آخر. يسمح هذا الإعداد لكلا الخادومين بامتلاك الميّزات "الرئيسية". يعني هذا أنّه يمكن لكلا الخادومين أن يقبلا الكتابة والتحديثات ونقل التغييرات إلى الخادوم الآخر. يرث هذا الإعداد مزايا إعداد master-slave، ولكنّه يستفيد أيضًا من التحسّن بأداء الكتابة على الأقراص إذا كانت طريقة الكتابة موزّعة بشكلٍ جيّدة عبر آلية موازنة حملٍ جيّدة.

هذا يعني أيضًا أنّه في حال تعطّل خادومٍ ما، سيبقى الآخر عامِلًا وقادرًا على استقبال الطلبات وخدمة الزوّار. صحيحٌ أنّ عملية الإعداد ستكون أكثر تعقيدًا هنا، ولكنّ عملية الاسترجاع في هذه الحالة هي أقل تعقيدًا من حالة الاسترجاع من الفشل في إعداد master-slave، لأنّه لا حاجة إلى نقل قاعدة البيانات من الخادوم الفرعي إلى الخادوم الرئيسي.

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

يمكنك قراءة المزيد عن: النسح المتماثل كـmaster-master.

التوزيع كبديل للنسخ لتكرار البيانات

تعرض الأنظمة الموزّعة العديد من المزايا مقارنةً بتضبيطات تكرار البيانات التقليدية.

شرحنا مراحل RAID الممررة عبر المرايا أعلاه (RAID 1). هناك مرحلة أخرى شائعة الاستخدام في RAID وهي RAID 5. تقوم هذه المرحلة بتوزيع البيانات على امتداد عددٍ من الأجهزة وتقوم أيضًا بكتابة بياناتٍ مساوية على امتداد كلّ جهاز. يعني هذا أنّه يمكن إعادة بناء أيّ نوع من الإجراءات (Transactions) عبر جمع المعلومات الموزّعة بشكلٍ متساوٍ من الأجهزة الأخرى في حال تعطّل جهازٍ ما.

يوفّر هذا طريقةً مختلفة لتوزيع البيانات عبر مختلف الأقراص، ويمكنه معالجة فشل واحدٍ من الأقراص كذلك.

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

من الأمثلة على هذا هو Riak، Riak هو عبارة عن قاعدة بيانات موزّعة. عُقَد Riak متطابقة جميعًا. لا يوجد أيّ علاقة master-slave بين الأجزاء المختلفة. تتم عملية النسخ المتماثل على الكائنات المخزّنة في قاعدة البيانات تلقائيًا، لذا فهناك عملية نسخ متماثل تلقيدية في هذا الجانب.

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

مثالٌ آخر قائم على هذا المبدأ المُضمّن في قاعدة بيانات هو Cassandra. وهو مبني على نفس المبادئ الموجود في Riak، ولكنّها مضمّنة بطريقة مختلفة.

خاتمة

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

يجب أيضًا أن تكون قادرًا على أن ترى الآن أن إعداد النسخ المتماثل ليس بديلًا عن النسخ الاحتياطي.

للتطبيقات التي يكون فيها توافق البيانات والوصول أمرًا أساسيًا، سيكون النسخ الاحتياطي والنسخ المتماثل تقنيتين لا تقدرّان بثمن. تضمينٌ صحيح لهاتين التقنيتين سيضمن لك أنّ منتجك سيكون دومًا متوفرًا للمستخدمين وأنّ البيانات لن تضيع منك.

ترجمة -وبتصرف- للمقال: How To Choose a Redundancy Plan To Ensure High Availability لصاحبه: Justin Ellingwood.

حقوق الصورة البارزة: Designed by Freepik.

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

يعمل نظام اكتشاف الاختراق على جهاز المستضيف (HIDS - host-based intrusion detection system) عبر جمع التفاصيل عن نظام ملفّات حاسوبك وإعداداته. ثمّ يقوم بتخزين هذه المعلومات لديه ليستخدمها في مطابقة حالة النظام الحالية مع البيانات التي قام بجمعها بالسابق. إذا حصل أيّ تغيير بين حالة النظام الحالية وبين حالة النظام المخزّنة لدى HIDS، فتلك قد تكون إشارة إلى أنّه قد تمّ اختراق خادومك.

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

في هذا الدرس، سنشرح كيفية تثبيت وإعداد tripwire على Ubuntu 12.04. بسبب طبيعة نظام اكتشاف الاختراقات، فمن المستحسن أن تقوم بتثبيت هذا النظام مباشرةً بعد إعداد خادومك، لكي يتمكّن النظام من الحصول على نسخةٍ نظيفة وآمنة بالأساس من خادومك.

تثبيت Tripwire

لحسن الحظّ، يتوفّر tripwire في المستودعات الافتراضية لتوزيعة Ubuntu، يمكن تثبيته عبر الأمر التالي:

sudo apt-get update
sudo apt-get install tripwire

أثناء عملية التثبيت، سيتم ضبط إعدادات العديد من الحزم الأخرى التي يعتمد عليها التطبيق في عمله.

أوّلًا، سيقوم بإعداد تطبيق البريد الذي يحتاجه كاعتمادية. إذا كنت تريد إعداد التنبيهات عبر البريد الإلكتروني، فاختر "internet site".

بعدها سيسألك عمّا إذا كنت تريد اختيار جمل المرور passphrases أثناء التثبيت، اختر Yes لكلا السؤالين. ثمّ سيسألك عمّا إذا كنت تريد إعادة بناء ملفّ الإعدادات، اختر yes. وأخيرًا، سيسألك سؤالًا مشابهًا عن ملفّ السياسة المتّبعة policy، اختر yes.

بعدها، سيطلب منك اختيار وتأكيد جُمَل مرور للموقع. يستخدم Tripwire مفتاحين اثنين لتأمين ملفّات إعداداته:

• مفتاح الموقع site key: يُستخدم هذا المفتاح لتأمين ملفّات الإعدادات. نحتاج إلى أن نضمن أنّ هذه الملفّات لن يتم تغييرها، وإلّا فلن نتمكّن من الوثوق بنظام اكتشاف الاختراقات بأكمله حينها. بما أنّ نفس ملفّات الغعدادات يمكن أن يتم استخدامها من قبل أكثر من خادوم، فإنّه بالإمكان استخدام هذا المفتاح على أكثر من خادوم.
• المفتاح المحلّي local key: يتم استخدام هذا المفتاح على كلّ آلة لتشغيل الملفّات الثنائية (binaries). وهو أمرٌ ضروري لضمان أنّ الملفّات الثنائية لن يتم تشغيلها دون موافقتنا.

ستقوم أوّلًا باختيار وتأكيد جُملة مرور لمفتاح الموقع، ثمّ للمفتاح المحلّي. تأكّد من إدخال جمل قوّية.

تحليل قاعدة البيانات

بعد التثبيت، يجب أن تقوم بتحليل وإعداد تثبيتك. كما في معظم برامج الحماية، يأتي tripwire مع إعدادت افتراضية عامّة مُقيّدة يمكن تعديلها لتناسب احتياجاتك.

أوّلًا، إذا لم تختر yes عندما سألك عن إنشاء ملفّ السياسة المتّبعة policy أثناء التثبيت، فإنّه يجب عليك فعل ذلك الآن عبر الأمر:

sudo twadmin --create-polfile /etc/tripwire/twpol.txt

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

يقوم هذا بإنشاء ملفّ سياسة مشفّر من الملفّ الموجود في المسار etc/tripwire/، هذا الملفّ المشفّر هو ما يقرأه tripwire حقا عند تنفيذ فحوصاته.

يمكننا الآن تحليل قاعدة البيانات التي سيستخدمها tripwire للتحقق من نظامنا لاحقًا. تستخدم قاعدة البيانات هذه الملف الذي قمنا بإنشاءه للتو كما أنّها تقوم بالتحقق من النقاط المحددة بداخله.

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

للقيام بتحليل قاعدة البيانات، طبّق:

sudo tripwire --init

يقوم هذا الأمر بإنشاء ملفّ قاعدة البيانات وطباعة الأشياء التي يجب علينا ضبطها في ملفّ إعداداتنا.

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

sudo sh -c 'tripwire --check | grep Filename > test_results'

إذا فتحنا هذا الملف، فيجب أن نرى شيئا مثل:

less /etc/tripwire/test_results

Filename: /etc/rc.boot
Filename: /root/mail
Filename: /root/Mail
Filename: /root/.xsession-errors
. . .

إعداد ملف السياسة المتبعة لمطابقة حالة نظامك

الآن وبعد أن صار لدينا قائمة بكل الملفّات التي تشكّل إعدادات tripwire، يمكننا تعديل ملفّ السياسة policy file للتخلص من تلك الرسائل المزعجة التي تظهر لنا.

افتح ملف السياسة الصرف بمحرر النصوص الخاص بك وبصلاحيات الجذر:

sudo nano /etc/tripwire/twpol.txt

ابحث عن عن جميع الملفّات الموجودة في ملف test_results. قم بتعليق كل السطور التي تجدها منها (ضع إشارة # قبلها فقط).

في قسم "Boot Scripts"، يجب أن تقوم بتعليق السطر etc/rc.boot/ لأنّه ليس موجودًا على نظام Ubuntu:

(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
         /etc/init.d             -> $(SEC_BIN) ;
         #/etc/rc.boot            -> $(SEC_BIN) ;
         /etc/rcS.d              -> $(SEC_BIN) ;
}

كان هناك العديد من الملفّات الموجودة بمسار root/ والتي كان يجب علي تعليقها على نظامي، قم بتعليق أي ملف غير متوفر على نظامك حاليًا:

(
  rulename = "Root config files",
  severity = 100
)
{
        /root                           -> $(SEC_CRIT) ; # Catch all additions to /root
        #/root/mail                     -> $(SEC_CONFIG) ;
        #/root/Mail                     -> $(SEC_CONFIG) ;
        #/root/.xsession-errors         -> $(SEC_CONFIG) ;
        #/root/.xauth                   -> $(SEC_CONFIG) ;
        #/root/.tcshrc                  -> $(SEC_CONFIG) ;
        #/root/.sawfish                 -> $(SEC_CONFIG) ;
        #/root/.pinerc                  -> $(SEC_CONFIG) ;
        #/root/.mc                      -> $(SEC_CONFIG) ;
        #/root/.gnome_private           -> $(SEC_CONFIG) ;
        #/root/.gnome-desktop           -> $(SEC_CONFIG) ;
        #/root/.gnome                   -> $(SEC_CONFIG) ;
        #/root/.esd_auth                        -> $(SEC_CONFIG) ;
        #/root/.elm                     -> $(SEC_CONFIG) ;
        #/root/.cshrc                   -> $(SEC_CONFIG) ;
        /root/.bashrc                   -> $(SEC_CONFIG) ;
        #/root/.bash_profile            -> $(SEC_CONFIG) ;
        #/root/.bash_logout             -> $(SEC_CONFIG) ;
        /root/.bash_history             -> $(SEC_CONFIG) ;
        #/root/.amandahosts             -> $(SEC_CONFIG) ;
        #/root/.addressbook.lu          -> $(SEC_CONFIG) ;
        #/root/.addressbook             -> $(SEC_CONFIG) ;
        #/root/.Xresources              -> $(SEC_CONFIG) ;
        #/root/.Xauthority              -> $(SEC_CONFIG) -i ; # Changes Inode number on login
        #/root/.ICEauthority                -> $(SEC_CONFIG) ;
}

آخر جزءٍ من عملية التحقق الخاصّة بي كان يتذمّر من الملفّات الوصفية بنظام الملفّات proc/. تتغير هذه الملفّات طوال الوقت، لذا فإنّها تقوم بإرجاع نتيجة موجبة طوال الوقت لنظام اكتشاف الاختراقات بعد أن تتغير.

في قسم "Devices & Kernel information"، يمكنك أن ترى أن نظام الملفّات proc/ مُعلّم ليتم التحقق منه:

(
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
)
{
        /dev            -> $(Device) ;
        /proc           -> $(Device) ;
}

ولكن هذا يقوم بالتحقق من كل الملفّات الموجودة ضمنه، ونحن لا نريد هذا. وعوضا عن ذلك، فسنقوم بحذف هذا الخيار، وإضافة الملفّات الفرعية الموجودة داخل نظام proc/ والتي نريد التحقق منها فقط:

{
        /dev                    -> $(Device) ;
        #/proc                  -> $(Device) ;
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/tty               -> $(Device) ;
        /proc/sys               -> $(Device) ;
        /proc/cpuinfo           -> $(Device) ;
        /proc/modules           -> $(Device) ;
        /proc/mounts            -> $(Device) ;
        /proc/dma               -> $(Device) ;
        /proc/filesystems       -> $(Device) ;
        /proc/interrupts        -> $(Device) ;
        /proc/ioports           -> $(Device) ;
        /proc/scsi              -> $(Device) ;
        /proc/kcore             -> $(Device) ;
        /proc/self              -> $(Device) ;
        /proc/kmsg              -> $(Device) ;
        /proc/stat              -> $(Device) ;
        /proc/loadavg           -> $(Device) ;
        /proc/uptime            -> $(Device) ;
        /proc/locks             -> $(Device) ;
        /proc/meminfo           -> $(Device) ;
        /proc/misc              -> $(Device) ;
}

وبما أننا في هذا القسم من الملف، فنريدُ أيضًا عمل شيءٍ مع نظام الملفّات dev/pts/. لن يتحقق Tripwire من نظام الملفّات ذاك افتراضيًا لأنّه مضبوط لأن يتحقق من dev/ فقط، بينما يعتبر dev/pts/ نظام ملفات منفصل، ولذلك لن يتم اعتباره في عملية التحقق. لجعل Tripwire يتحقق من هذا النظام كذلك، يمكنك إضافته كالشكل التالي:

{
        /dev                    -> $(Device) ;
        /dev/pts                -> $(Device) ;
        #/proc                  -> $(Device) ;
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/tty               -> $(Device) ;
        . . .

الشيء الأخير الذي سنقوم بوضع إشارة تعليق قبله هما السطران var/run/ و var/lock/ لكي لا يقوم نظامنا باعتبار التغييرات التي تجري على نظام الملفّات من طرف الخدمات:

(
  rulename = "System boot changes",
  severity = $(SIG_HI)
)
{
        #/var/lock              -> $(SEC_CONFIG) ;
        #/var/run               -> $(SEC_CONFIG) ; # daemon PIDs
        /var/log                -> $(SEC_CONFIG) ;
}

احفظ الملف وأغلقه عندما تنتهي.

الآن وبعد أن قمنا بضبط ملفّنا، نحتاج إلى استخدامه عبر إعادة إنشاء ملف السياسة المشفّر الذي يستخدمه tripwire في الواقع:

sudo twadmin -m P /etc/tripwire/twpol.txt

بعد أن يتم إنشاؤه، يجب أن نقوم بإعادة تحليل قاعدة البيانات لتطبيق السياسة الجديدة:

sudo tripwire --init

Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/tripit.twd
The database was successfully generated.

يجب أن تختفي الآن جميع رسائل التحذيرات والأخطاء المزعجة التي رأيتها في البداية، إذا كان لا يزال هناك رسائل تحذير مثلا، فيجب أن تتابع تحرير ملف etc/tripwire/twpol.txt/ إلى أن تختفي.

اختبار الإعدادات

إذا لم تشتكي عمليّة تحليل قاعدة البيانات من أي مشاكل أو أخطاء، فهذا يعني أن إعداداتك تطابق نظام الحالي في هذه النقطة. ولكننا سنقوم بعمل اختبار لرؤية ما يبدو عليه تقرير tripwire إذا لم يكن هناك حقًا أيّ أخطاء.

الأمر الرئيسي للاختبار هو:

sudo tripwire --check

يجب أن ترى تقريرًا يتم طباعته على شاشتك ليخبرك أنّه لا يوجد أيّ أخطاء أو تغييرات مُكتشفة على نظامك.

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

يمكننا حذف ملف test_results الذي قمنا بإنشائه:

sudo rm /etc/tripwire/test_results

شيء آخر يمكننا القيام به هو إزالة ملف الإعدادات الصرف الغير مشفّر. يمكننا الآن القيام بهذا بشكل آمن لأنّه يمكن إعادة إنشائه إن أردنا مجددا من الملف المشفّر باستخدام جملة المرور الخاصّة بنا لاحقا.

كل ما علينا فعله لإعادة إنشاء ملف الإعدادات الصرف هو تمرير الملف المشفّر إلى twadmin، بنفس الطريقة التي قمنا بإنشاء الإصدار المشفّر بداية. يجب علينا فقط تطبيق:

sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

اختر هذا الآن عبر نقل الإصدار النصّي إلى موقع النسخ الاحتياطي ثم حاول إعادة إنشائه:

sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

إذا عمل بشكل صحيح، فيمكنك حينها حذف الملفّات الصرفة بشكل آمن الآن:

sudo rm /etc/tripwire/twpol.txt
sudo rm /etc/tripwire/twpol.txt.bak

إعداد التنبيهات عبر البريد الإلكتروني

سنقوم بإعداد tripwire ليتم تشغيله كل يوم وليتم أتمتة التنبيهات عبر البريد الإلكتروني فيه. خلال العملية، يمكننا أن نختبر كيفيّة تحديث قاعدة البيانات عندما نقوم بعمل تغييرا على نظامنا.

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

لتثبيته:

sudo apt-get install mailutils

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

sudo tripwire --check | mail -s "Tripwire report for `uname -n`" your_email@domain.com

يجب أن تتلقى تقريرا بعد فترة قصيرة في بريدك الإلكتروني عن البرنامج الجديد "mail" الذي تمّ تثبيته على النظام. هذا أمر جيّد، إنّه يعني أن tripwire يقوم بمهمّته بمراقبة نظام ملفّاتنا وأنّ نظام التنبيهات عبر البريد الإلكتروني يعمل كذلك.

يجب علينا الآن تشغيل اختبار تحقق لتحديث قاعدة البيانات بعد أن قمنا بتثبيت برنامج جديد.

يمكننا فعل ذلك عبر:

sudo tripwire --check --interactive

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

يحتوي هذا التقرير على الكثير من التفاصيل عن الملفّات التي تمّ تغييرها. في الواقع، على جهازي، كان الملفّ المُنشَئ يتكوّن من أكثر من 2275 سطر. هذه الكمّية من المعلومات مفيدة جدًا في حال حصول مشكلة حقيقية تتعلق بالحماية.

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

Rule Name: Other binaries (/usr/sbin)
Severity Level: 66
-------------------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Added:
[x] "/usr/sbin/maidag"

Modified:
[x] "/usr/sbin"
. . .

تشير صناديق الاختيار هذه إلى أنّك تريد تحديث قاعدة البيانات للسماح بهذه التغييرات. يجب أن تبحث عن كل صندوق يحوي إشارة "x" بداخله وأن تتحقق من أن هذه التغييرات قد قمت بها أنت فعلا وأنّه لا بأس بها.

إذا لم تكن تريد لتغيير معيّن أن يبقى، يمكنك إزالة إشارة "x" من الصندوق ولن يتم تحديث ذلك الملفّ في قاعدة البيانات. سيسبب هذا أن يقوم tripwire باعتبار الملفّ كملف تمّ تعديله دون أن يكون متوقعًا ذلك.

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

إذا قبلنا جميع التغييرات، وإذا قمنا بتشغيل هذا الأمر بعدها، فيجب أن يكون التقرير أقصر بكثير الآن وألّا يسرد أيّ تغييرات.

أتمتة Tripwire مع Cron

الآن وبعد أن تحققنا من أن جميع وظائف النظام تعمل بشكل يدوي، يمكننا إعداد مهمّة cron لتقوم بتنفيذ اختبار تحقق بواسطة tripwire في كل صباح. يمكنك الإطلاع على كيفية عمل cron من هنا.

يمكننا استخدام crontab الخاص بالمستخدم الجذر، لأنّ التعديلات على الـcronjob الخاصّة بالنظام قد يتم محوها في حال توفّر تحديث لحزمة cron.

للتحقق ما إذا كان المستخدم الجذر يمتلك بالفعل crontab:

sudo crontab -l

إذا كان crontab موجودًا، فيجب عليك نقله عبر أنبوب (pipe) إلى ملف وأن تقوم بإرجاعه:

sudo sh -c 'crontab -l > crontab.bad'

بعدها، يمكننا تعديل الـcrontab عبر:

sudo crontab -e

إذا كانت هذه مرّتك الأولى في تشغيل crontab، فسيسألك عن اسم محرر النصوص الذي تود استخدامه. إذا كنت لا تفضّل واحدًا على آخر، فيمكنك استخدام المحرر nano.

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

الصيغة التي نحتاج استخدامها هي min hour * * * command والأمر الذي نريد استخدامه هو نفسه الذي استخدمناه في تقريرنا عبر البريد الإلكتروني سابقًا. لا نحتاج إلى استخدام sudo هذه المرّة بما أنّه سيتم تشغيل الأمر باسم المستخدم الجذر.

لتشغيل tripwire بالساعة 3:30 صباحًا كلّ يوم، يمكننا وضع السطر التالي بملفّنا:

30 3 * * * /usr/sbin/tripwire --check | mail -s "Tripwire report for `uname -n`" your_email@domain.com

يمكنك تعديله حسب احتياجك.

خاتمة

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

ترجمة -وبتصرف- للمقال How To Use Tripwire to Detect Server Intrusions on an Ubuntu VPS لصاحبه Justin Ellingwoo.

يُواجه كلّ شخص في وقتٍ ما مشاكل مع خادوم الوِيب Web Server، سيُساعدك تَعلّمك أين تبحث عندما تواجه مشكلة ما وأيّ العناصر هي التي من المحتمل تمّ تخريبها على إصلاح هذه المشاكل (troubleshoot) بسرعة وبإحباط أقل.

سنناقش في هذا الدرس كيف نقوم باستكشاف هذه المشاكل بحيث تستطيع الإبقاء على موقعك يعمل بشكل طبيعي.

ما هي أنواع المشاكل النموذجية التي من المحتمل أن تواجهها ؟

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

• هل تمّ تنصيب خادوم الوِيب لديك؟
• هل خادوم الوِيب قيد التشغيل الآن؟
• هل الصياغة في ملفات ضبط  خادوم الوِيب configuration files صحيحة؟
• هل المنافذ ports التي قمت بضبطها مفتوحة (لم يتم حجبها من الجدار الناري)؟
• هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟
• هل يشير جذر المستند document root إلى موقع ملفاتك؟
• هل يقوم خادوم الوِيب بتخديم ملفات الفهرس index files الصحيحة؟
• هل أذونات permissions وملكية الملف ownership وبُنى المجلد صحيحة؟
• هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟
• إن كنتَ تملك قاعدة بيانات database في الخلفيّة backend فهل هي تعمل؟
• هل يستطيع موقعك الاتصال مع قاعدة البيانات بنجاح؟

هذه هي بعض أشيع المشاكل التي يُصادفها مُدراء النُّظم عندما لا يعمل الموقع بشكلٍ صحيح، يُمكن عادةً تضييق المشكلة المحددة بإلقاء نظرة على ملفات السّجل Log Files للمكونات المختلفة وعن طريق الرجوع إلى صفحات الخطأ التي تظهر في متصفحك. سنقوم بالمرور في الأسفل على كل من هذه الحالات لكي تستطيع التحقق من أنّ الخدمات مضبوطة بشكلٍ صحيح.

التحقق من السّجلات Logs

قبل أن تقوم بتعقُّب مشكلة ما بشكلٍ عشوائي حاول أن تتحقق من سجلات خادوم الوِيب Logs لديك ومن أيّة عناصر مرتبطة بذلك، ستجد هذه السّجلات عادةً في المسار var/log/ في مجلّد فرعي مخصّص للخدمة التي تريدها.

فعلى سبيل المثال إن كنتَ تملك خادوم Apache يعمل على توزيعة Ubuntu فستجد بشكل افتراضي أنّ السّجلات يتمّ الاحتفاظ بها في المسار var/log/apache2/، قُم بالتحقق من الملفات في هذا المجلد لكي ترى ما نوع رسائل الخطأ التي تمّ توليدها، إن كنت تملك قاعدة بيانات تعمل في الخلفيّة وتسبب لك المشاكل فهي على الأغلب تحتفظ بسجلاتها في المسار var/log/ أيضًا.

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

استخدم محرّك بحث Search Engine لتحاول إيجاد معلومات متعلقة بالموضوع والتي من الممكن أن تقودك في الاتجاه الصحيح، تساعدك الخطوات القادمة في استكشاف الأخطاء أكثر.

هل تمّ تنصيب خادوم الوِيب لديك؟

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

إذا كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Apache تستطيع كتابة ما يلي:

sudo apt-get update
sudo apt-get install apache2

تُدعى عمليّة Apache على هذه الأنظمة بـ apache2.

إن كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Nginx تستطيع بدلًا من ذلك كتابة:

sudo apt-get update
sudo apt-get install nginx

تُدعى عمليّة Nginx على هذه الأنظمة بـ nginx.

إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Apache فقُم بكتابة التالي وبإمكانك إزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root:

sudo yum install httpd

تُدعى عمليّة Apache على هذه الأنظمة بـ httpd.

إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Nginx تستطيع كتابة الأمر التالي، ومرّة أخرى قم بإزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root:

sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
sudo yum install nginx

تُدعى عمليّة Nginx على هذه الأنظمة بـ nginx.

هل خادوم الوِيب قيد التشغيل الآن؟

بعد أن قمت بالتأكد من أنّ خادومك مُنَصّب بالفعل، فهل هو قيد التشغيل؟

تُوجَد العديد من الطّرق لكي تكتشف إذا ما كانت الخدمة قيد التشغيل أم لا، واحدة من هذه الطرق والتي تعمل على منصّات متعدّدة cross-platform هي استخدام الأمر netstat.

سيُخبِرك هذا الأمر عن جميع العمليّات التي تستخدم منافذ على الخادوم، بإمكاننا بعد ذلك كتابة الأمر grep لإيجاد اسم العملية التي نبحث عنها:

sudo netstat -plunt | grep apache2

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2

يجب عليك تغيير كلمة "apache2" إلى اسم عمليّة خادوم الوِيب الذي لديك، إن ظهر لك سطر كالموجود بالأعلى فهذا يعني أنّ العمليّة قيد التشغيل، أمّا إن لم تحصل على أيّة خَرج فهذا يعني إمّا أنّك قُمت بالاستعلام عن العمليّة الخطأ أو أنّ خادوم الوِيب لديك لا يعمل.

يُمكنك في هذه الحالة بدء تشغيله باستخدام الطريقة المفضّلة لتوزيعتك، فعلى سبيل المثال على Ubuntu تستطيع بدء تشغيل خدمة Apache2 بكتابة:

sudo service apache2 start

وعلى توزيعة CentOS نكتب هذا الأمر:

sudo /etc/init.d/httpd start

إذا تمّ بدء تشغيل خادومك فعندها تستطيع التحقق باستخدام الأمر netstat مرّة أخرى لكي تتأكد من انّ كل شيء يعمل بشكل صحيح.

هل الصّياغة Syntax في ملفات ضبط خادوم الوِيب صحيحة؟ إذا رفض خادوم الوِيب لديك أن يبدأ التشغيل فهذا يشير عادةً إلى أنّ ملفات الضبط تحتاج إلى بعض الانتباه، يتطلّب Apache و Nginx التزامًا صارمًا بتعليمات الصّياغة syntax لكي يتمّ قراءة الملفات بنجاح.

تتواجد ملفات إعدادات الضبط لهذه الخدمات عادةً في المسار etc/  في مجلّد فرعي مُسمّى على اسم العمليّة نفسها.

وبهذا نستطيع الوصول إلى المجلّد الرئيسي لإعدادات ضبط Apache على Ubuntu بكتابة:

cd /etc/apache2

ويمكننا الوصول بطريقة مشابهة إلى مجلّد إعدادات ضبط Apache على CentOS والمُسمّى على اسم تلك العمليّة:

cd /etc/httpd

تكون إعدادت الضبط مُوزّعة على عدّة ملفات، وعندما يفشل بدء الخدمة فإنها ستشير عادةً إلى ملف إعدادات الضبط وإلى السّطر الذي حدثت فيه المشكلة، قُم بالتحقق من هذا الملف بحثًا عن الأخطاء. يُزوّدك كل واحد من خواديم الوِيب هذه بالقدرة على التحقق من صياغة إعدادات الضبط في ملفاتك. إن كُنتَ تستخدم Apache فبإمكانك استخدام الأمر apache2ctl أو apachectl للتحقق من ملفات إعدادات الضبط بحثاً عن أخطاء الصياغة:

apache2ctl configtest
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
Syntax OK

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

وإن كنتَ تملك خادوم وِيب Nginx تستطيع البدء باختبار مماثل بكتابة:

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo nginx -t 

nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

يُوجد عدد خاطئ من المُعطيات arguments لأنّ Nginx يقوم بالبحث عن الفاصلة المنقوطة لإنهاء الجُمَل، فإن لم يجدها ينتقل للسطر التالي ويفسّر ذلك على أنها مُعطيات إضافية للسطر السابق.

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

هل المنافذ الذي قمت بضبطها مفتوحة؟

تعمل خواديم الوِيب بشكلٍ عام على المنفذ 80 لاتصالات الوِيب الطبيعية normal web traffic وتستخدم المنفذ 443 للاتصالات المشفّرة باستخدام TLS/SSL، ولكي تصل بشكل صحيح إلى الموقع يجب أن تكون هذه المنافذ قابلة للوصول. تستطيع اختبار إذا ما كان الخادوم لديك يملك منفذًا مفتوحًا باستخدام الأداة netcat على حاسوبك المحلّي Local Machine.

تحتاج فقط لاستخدام عنوان الـ IP لخادومك وتخبرها عن رقم المنفذ الذي تريد التحقق منه كما يلي:

sudo nc -z 111.111.111.111 80

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

إن لم تكن منافذ الوِيب قابلة للوصول لديك فيجب أن تبحث في إعدادات الجدار الناري لديك، حيث قد تحتاج أن تفتح المنفذ 80 أو المنفذ 443.

هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟

إن كان بإمكانك الوصول إلى موقعك باستخدام عنوان الـ IP ولا تستطيع ذلك عبر اسم المجال domain name فربّما يجب عليك إلقاء نظرة على إعدادت الـ DNS.

لكي يتمكّن زوّار موقعك من الوصول إليه عبر استخدام اسم المجال فيجب أن يكون لديك سِجِل "A"  أو "AAAA"  يشير إلى عنوان الـ IP الخاص بخادومك في إعدادات الـ DNS، تستطيع الاستعلام عن سِجِل “A” لمجالك باستخدام هذا الأمر:

host -t A example.com
example.com has address 93.184.216.119

يجب أن يتطابق السطر الذي يعود لك مع عنوان الـ IP لخادومك، إن كنتَ تريد التحقق من سِجِل "AAAA" (للاتصالات التي تستخدم IPv6) بإمكانك كتابة:

host -t AAAA example.com
example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

يجب أن تبقي في ذهنك أنّ أيّة تغييرات تقوم بها على سِجِل الـ DNS تأخذ وقتًا طويلًا ليتم تعميمها، ربّما تتلقى نتائج متضاربة بعد التغيير حيث أنّ طلبك يتمّ تلقيه من قبل خواديم مختلفة ليست جميعها مُحدّثة إلى آخر إصدار حتى الآن. إن كنتَ تستخدم موقع DigitalOcean فبإمكانك أن تتعلم أساسيات DNS وأسماء النطاقات.

قم بالتأكد من أن ملفات إعدادات الضبط تقوم بالتعامل مع مجالك بشكل صحيح. يبدو المقطع الخاص بملف المضيف الوهمي virtual host file لديك في Apache كما يلي:

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin admin@example.com
DocumentRoot /var/www/html
٠٠٠

يتم إعداد المضيف الوهمي virtual host لكي يستجيب مع أيّة طلبات على المنفذ 80 من أجل المجال example.com.

تبدو القطعة المشابهة لهذا في Nginx كما يلي:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
٠٠٠

يتم إعداد هذه الكتلة Block لكي تستجيب إلى النوع المماثل من الطلبات التي تحدثنا عنها في الأعلى.

هل يشير جذر المستند Document Root إلى موقع ملفاتك؟

من الاعتبارات الأخرى التي يجب أن نأخذ بها هي إذا ما كان خادوم الويب لديك يشير إلى الموقع الصحيح للملف. يتم إعداد كل خادوم وهمي في Apache أو كتلة خادوم Server Block في Nginx لكي تشير إلى مجلّد محدد، فإن كان مُعدًّا بشكل غير صحيح سيرمي الخادوم رسالة خطأ عندما تحاول الوصول إلى الصفحة.

يتم إعداد جذر المستند Document Root في Apache باستخدام التوجيه DocumentRoot :

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin admin@example.com
DocumentRoot /var/www/html
...

يُخبر هذا السطر Apache أنّه يجب عليه البحث عن الملفات لهذا المجال في المسار var/www/html/، فإن كنت تحتفظ بملفاتك في مكانٍ آخر يجب عليك تعديل هذا السطر لكي يشير إلى الموقع الصحيح.

يقوم التوجيه root في Nginx بإعداد نفس الشيء:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
... 

يبحث Nginx في إعداد الضبط هذا عن الملفات لهذا المجال في المسار usr/share/nginx/html/

هل يقوم خادوم الوِيب بتخديم ملفات الفهرس Index files الصحيحة؟

إذا كان جذر المستند لديك صحيحًا ولا يتم تخديم صفحات الفهرس Index Pages بشكلٍ صحيح عندما تذهب إلى موقعك أو إلى مكان المجلد على موقعك فربّما تم ضبط إعدادات الفهارس بشكل غير صحيح.

عندما يقوم زائر ما بطلب مجلد يقوم خادومك نموذجيًا بإعطائه ملف فهرسة، عادةً ما يكون هذا ملف index.html أو ملف index.php وذلك اعتمادًا على على إعدادات الضبط لديك.

ربّما تجد في Apache سطرًا في ملف المضيف الافتراضي الذي يقوم بضبط إعدادات ترتيب الفهرس التي سيتم استخدامها لمجلدات معيّنة بشكلٍ صريح كما يلي:

<Directory /var/www/html>
DirectoryIndex index.html index.php
</Directory>

هذا يعني أنّه عندما يتم تخديم مجلد فإنّ Apache سيقوم بالبحث أولًا عن ملف يدعى index.html، ويحاول تخديم ملف index.php كاحتياط في حال لم يتم إيجاد الملف الأول. بإمكانك تعيين الترتيب الذي سيتم استخدامه لتخديم ملفات الفهرس لكامل الخادوم عن طريق تعديل ملف mods-enabled/dir.conf والذي يقوم بتعيين الإعدادات الافتراضية للخادوم، إن كان الخادوم لديك لا يُخدّم ملف فهرس فقم بالتأكد أنّك تملك ملف فهرس في مجلّدك الذي يُوافق أحد الخيارات في ملفك.

يُدعى التوجيه الذي يقوم بذلك في Nginx بـ “index” ويتمّ استخدامه كما يلي:

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name example.com www.example.com;
...

هل تمّ تعيين الأذونات والملكية بشكل صحيح؟

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

على Ubuntu و Debian يعمل كلًّا من Apache و Nginx كالمستخدم www-data والذي هو عضو من المجموعة www-data.

على CentOS و Fedora يعمل Apache تحت مستخدم يُدعى apache والذي ينتمي لمجموعة apache، يعمل Nginx تحت مستخدم يُدعى nginx والذي هو جزء من مجموعة nginx.

تستطيع باستخدام هذه المعلومات النظر إلى المجلدات والملفات التي يتألف منها محتوى موقعك:

ls -l /path/to/web/root

يجب أن تكون المجلدات قابلة للقراءة والتنفيذ من قبل المستخدم web أو مجموعته، أمّا الملفات فيجب أن تكون قابلة للقراءة لكي يتم قراءة محتواها، وبالإضافة لذلك إن أردنا تحميل، كتابة أو التعديل على المحتوى يجب أن تكون المجلدات والملفات قابلة للكتابة، ولكن احذر عند تعيينك للمجلدات لكي تكون قابلة للكتابة لأنّ هذا يُمكن أن يكون أحد المخاطر الأمنية.

لتعديل ملكية ملف ما تستطيع فعل ما يلي:

sudo chown user_owner:group_owner /path/to/file

تستطيع فعل هذا أيضًا للمجلد، فبإمكانك تغيير ملكية المجلد وكل ما بداخله من ملفات عبر تمرير العَلَم –R:

sudo chown -R user_owner:group_owner /path/to/file

تستطيع التعلم أكثر عن أذونات لينِكس هنا.

هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟

من المحتمل أنّه تم تعيين إعدادات الضبط لديك لكي تمنع الوصول إلى الملفات التي تحاول تخديمها. يتم إعداد هذا الضبط في Apache في ملف المضيف الافتراضي لهذا الموقع أو عبر ملف htaccess. الموجود في المجلد نفسه.

من الممكن من خلال هذه الملفات أن تقوم بمنع الوصول بعدّة طرق ، يُمكن منع الوصول للمجلدات في إصدار Apache 2.4 بهذه الطريقة:

<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>

يقوم هذا السطر بإخبار خادوم الوِيب بألّا يسمح لأي شخص بالوصول لمحتويات هذا المجلد، أمّا في إصدار Apache 2.2 والإصدارات الأقدم منه يمكننا كتابة ذلك كما يلي:

<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>

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

location /usr/share {
deny all;
}

إن كنتَ تملك قاعدة بيانات database في الخلفية فهل هي تعمل؟

إذا كان موقعك يعتمد على قاعدة بيانات في الخلفية مثل MySQL, PostreSQL, MongoDB, etc فستحتاج أن تتأكد من أنّها قيد التشغيل.

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

sudo netstat -plunt | grep mysql

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

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

إن كنتَ تملك قاعدة بيانات في الخلفية، فهل يستطيع موقعك الاتصال بنجاح إليها؟

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

على سبيل المثال في موقع WordPress يتم تخزين إعدادات اتصال قاعدة البيانات في ملف يُدعى wp-config.php ، تحتاج للتحقق من أنّ DB_NAME ، DB_USER و DB_PASSWORD صحيحة لكي يتمكن موقعك من الاتصال بقاعدة البيانات. 

بإمكانك اختبار إذا ما كان الملف يملك المعلومات الصحيحة بمحاولة الاتصال إلى قاعدة البيانات يدويًّا باستخدام ما يلي:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

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

هل تمّ ضبط خادوم الوِيب لديك لكي يمرر محتوىً ديناميكيًا إلى معالج نصوص Script Processor؟

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

يعني هذا بشكل عام في Apache التأكد من تنصيب وتمكين mod_php5، بإمكانك فعل هذا على Ubuntu أو Debian بكتابة:

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

وفي أنظمة CentOS و Fedora يجب كتابة ما يلي:

sudo yum install php php-mysql
sudo service httpd restart

ولكنّ هذا معقّد أكثر قليلًا في Nginx، حيث أنّه لا يملك وحدة PHP ليتمّ تمكينها، لذلك نحتاج أن نتأكد من تنصيب وتمكين php-fpm في إعدادات الضبط.

على خادوم Ubuntu أو Debian تأكد أنّه تم تنزيل العناصر بكتابة:

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

تستطيع فعل هذا على CentOS أو Fedora بكتابة:

sudo yum install php-fpm php-mysql

بما أنّ معالج PHP ليس جزءًا من Nginx تحتاج أن تذكر له صراحةً أن يمرر ملفات PHP، اتبع الخطوات الأربعة من هذا الدليل لتتعلم كيف تضبط إعدادات Nginx لكي يمرر ملفات PHP إلى php-fpm، يجب عليك أيضًا أن تلقي نظرة على المقطع من الخطوة الثالثة الذي يتعامل مع إعداد معالج PHP، يجب أن يكون هذا مماثلًا إلى حدٍّ كبير بغض النظر عن توزيعتك.

إن فشل كل هذا تحقق من السّجلات مرّة أخرى

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

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

الخاتمة

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

ترجمة -وبتصرّف- للمقال  How To Troubleshoot Common Site Issues on a Linux Server  لصاحبه Justin Ellingwood.