التثبيت التلقائي

شراء Self-Hosted Protection
Live
Demo

الطريقة التلقائية: سكربت واحد من الحساب الشخصي يجهّز السيرفر بالكامل (حزمة الويب Apache + PHP، قاعدة البيانات، أدوات الأمان، cron). بعد ذلك — نشر اللوحة، وإصدار SSL، وإدخال الترخيص. تعمل على Ubuntu/Debian: على VPS جديد تُعدّ كل شيء من الصفر، وعلى سيرفر مُعدّ مسبقًا — إضافةً فقط (ملف «سيرفر مُعدّ»، الخطوة 01). كل الأوامر أدناه مرتّبة، ما عليك سوى التمرير من الأعلى للأسفل. على VPS جديد تناسبك كل خطوة بالترتيب؛ أما إذا كان السيرفر مُعدًّا مسبقًا أو مثبَّتة عليه لوحة استضافة، فإن السكربت يترك لك جزءًا من العمل عن قصد — وهو يذكر ما هو بالضبط في نهاية تشغيله (شرح المخرجات — في الخطوة 01).

اختيار الطريقة التثبيت اليدوي دليل FAQ
القيم النائبة في الأوامر استبدلها بقيمك: monitor.example.com — نطاقك؛ 203.0.113.10 — عنوان IP الحقيقي للسيرفر؛ /var/www/monitor — جذر اللوحة (حيث توجد public/ وassets/ وconfig.php)؛ وابتكر كلمة مرور خاصة بك لقاعدة البيانات.
الحزمة الكاملة («الحماية الكاملة») مخصصة لـ VPS جديد. على Ubuntu/Debian نظيف تُعدّ نظام الأمان من الصفر — Fail2ban (jail.local)، وroot-crontab، وقواعد UFW، وإعداد Apache. إذا كان السيرفر مُعدًّا مسبقًا (لوحة تعمل، ومواقع، وبريد، وjail خاصة بك) — اختر ملف «سيرفر مُعدّ»: فهو يُدخل تغييرات إضافية فقط ولا يمسّ جدار الحماية، وFail2ban، والبريد، وSSH، وsysctl. عند اكتشاف لوحة استضافة يتحوّل السكربت إلى هذا الوضع تلقائيًا. قبل التشغيل الأول يمكنك تفعيل التشغيل التجريبي (بتحديد الخيار في الحساب) — سيعرض ما سيُنفَّذ دون تغيير أي شيء. وعلى سيرفر يعمل، خذ لقطة (snapshot) احتياطًا.

01. أمر الإعداد التلقائي من الحساب الشخصي

تحصل على الأمر من حسابك الشخصي my.arciveo.com ← قسم «إعداد السيرفر» (متاح بعد تفعيل Arcivéo Security Monitor). وهو مرتبط بحسابك ويحتوي على رمز شخصي.

يُجهّز السكربت السيرفر بالكامل: حزمة الويب (Apache + PHP)، وقاعدة البيانات، وأدوات SSL، والمجموعة الكاملة من وسائل الحماية ومهام cron (Lynis وSMART وdebsums وLogwatch والتقرير اليومي وتحديث ipsum).

1) اختر مستوى الحماية (في الحساب، قبل نسخ الأمر):

  • الحماية الكاملة (موصى بها) — UFW (جدار ناري)، Fail2ban، CrowdSec + bouncer، ipsum (قائمة حظر عناوين IP)، Suricata (IDS/IPS)، Falco، ModSecurity + OWASP CRS (WAF)، PSAD، mod_evasive (مضاد DoS)، AIDE (سلامة الملفات)، debsums، ClamAV + maldet (مضاد فيروسات)، Auditd، AppArmor، Monit، Lynis (تدقيق)، Logwatch، تحديثات الأمان التلقائية.
  • الخفيفة — للسيرفرات VPS ذات الذاكرة RAM المحدودة: مجموعة أساسية بدون المكوّنات الثقيلة.
  • سيرفر مُعَد مسبقًا (لوحة استضافة) — لسيرفر يعمل بالفعل مزوّد بلوحة (HestiaCP وما شابه) ومواقع وبريد: تغييرات إضافية فقط (تثبيت أدوات، cron، قواعد sudo)، بينما يبقى الجدار الناري وFail2ban والبريد وSSH وsysctl كما هي. على سيرفر مزوّد بلوحة يختار السكربت هذا الوضع تلقائيًا.
تشغيل تجريبي. في الحساب يمكن تفعيل خيار «تشغيل تجريبي» — عندها يعرض الأمر فقط ما سيثبّته السكربت ويغيّره، ثم ينتهي دون المساس بأي شيء. مفيد على سيرفر مُعَد مسبقًا: تشغيل تجريبي أولًا، ثم تشغيل فعلي بدون الخيار.

2) نفّذ على السيرفر بصلاحيات root الأمر من الحساب — يبدو هكذا:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN" | sudo bash
احتفظ بالأمر سرًّا — فهو مرتبط بحسابك. الرابط له مدة صلاحية محدودة؛ إذا انتهت، اضغط في الحساب «الحصول على رابط جديد».
بعد الإعداد التلقائي يكون سيرفر الويب Apache + PHP-FPM، وأدوات الأمان ومهام cron مثبّتة وتعمل «جاهزة للاستخدام».

3) اقرأ المخرجات في النهاية — فهي تبيّن ما تبقّى عليك. يُنهي السكربت عمله بكتلة فحوصات وقائمة «التالي — تثبيت اللوحة». وهناك خطوات لا ينفّذها عن قصد: وأيّها بالضبط يعتمد على الملف الذي اخترته وعلى ما وجده على السيرفر. راجع القائمة أدناه — نفّذ فقط البنود التي ظهرت أسطرها في مخرجاتك.

  • Control panel detected (…) — يُنشأ الموقع بأدوات لوحة الاستضافة نفسها، ولا ينشئ السكربت vhost. الخطوة 03، فرع «سيرفر بلوحة استضافة».
  • No vhost created (no domain given) — ملف «سيرفر مُعدّ» بدون نطاق: vhost بلا اسم كان سيصبح الموقع الافتراضي ويعترض مواقعك أنت، لذلك لم يُنشأ. الخطوة 03، فرع «إنشاء vhost يدويًا».
  • sudo rules NOT written — لم يتمكن السكربت من تحديد الحساب الذي تعمل به اللوحة. وهذا وضع معتاد: ملفات اللوحة تُرفع بعد الإعداد التلقائي، فلم يكن هناك ما يُستدلّ به بعد. وبدون هذه القواعد لن ترى الوحدات بيانات النظام. الخطوة 04، كتلة «sudo لسيرفر الويب».
  • ! Nginx does not read .htaccess — أمام Apache يوجد Nginx، ولم ينجح كتابة المنع في إعداده تلقائيًا. نفّذ ذلك إلزاميًا: وإلا فإن data/ وkeys/ وdatabase/ وconfig.php ستكون متاحة للخارج متجاوزةً .htaccess. الخطوة 03، كتلة «إذا كان أمام Apache يوجد Nginx».
  • UFW installed but inactive — جدار الحماية مثبّت لكنه معطّل: على سيرفر مُعدّ مسبقًا لا يفعّله السكربت بنفسه كي لا يقطع وصولك. فعّله بنفسك، مع السماح لمنفذ SSH الخاص بك إلزاميًا:
    sudo ufw allow OpenSSH # منفذ SSH غير قياسي: sudo ufw allow 2222/tcp sudo ufw allow 80,443/tcp sudo ufw enable
  • Fail2ban installed but not running — شغّله: sudo systemctl enable --now fail2ban.
  • Database server present … but not running — شغّل نظام قاعدة البيانات قبل الخطوة 04: sudo systemctl enable --now mariadb (أو mysql — حسب المثبَّت لديك).
  • Certbot skipped — issue SSL in … — تُصدَر الشهادة بمفتاح Let's Encrypt في لوحة الاستضافة؛ ولا تحتاج إلى الخطوة 06.
إذا كان كل شيء سليمًا في كتلة الفحوصات، فسيكون السطر الأخير All checks passed. البنود التي تحمل ! تتطلب انتباهك؛ والتفاصيل تُكتب في السجل، ويطبع السكربت مساره في النهاية تمامًا (Log: …).

02. النطاق وDNS

لفتح لوحة التحكم عبر عنوان مثل monitor.example.com والحصول على SSL مجاني، يجب أن يشير النطاق إلى السيرفر. في لوحة إدارة DNS (لدى المُسجِّل أو المستضيف) أنشئ سجل A:

النوع: A الاسم: monitor (نطاق فرعي → monitor.example.com) أو @ (جذر النطاق → example.com) القيمة: 203.0.113.10 ← عنوان IP الخاص بسيرفرك TTL: 3600

بعد بضع دقائق (وأحياناً حتى ساعة) تحقق من أن النطاق يشير إلى السيرفر:

dig +short monitor.example.com # يجب أن يُرجِع عنوان IP الخاص بك # أو، إن لم يتوفر dig: getent hosts monitor.example.com
يُصدَر شهادة SSL (الخطوة 06) للنطاق فقط — لذلك يجب أن يشير DNS إلى السيرفر قبل إصدار الشهادة.

03. رفع ملفات اللوحة

الحالة المعتادة (VPS جديد). الإعداد التلقائي أنشأ بالفعل مجلد اللوحة /var/www/monitor وضبط موقع Apache (DocumentRoot على جذر اللوحة، PHP-FPM، AllowOverride لملف .htaccess). في مخرجات السكربت يقابل ذلك السطر vhost … → DocumentRoot …. لا حاجة لإنشاء المجلد أو vhost على حدة — فقط ارفع الملفات واضبط الصلاحيات.
حالتان لا يُنشأ فيهما vhost — يذكر السكربت ذلك صراحةً في نهاية عمله. عندها نفّذ الفرع المناسب أدناه أولًا، ثم ارفع الملفات.

فرع «سيرفر بلوحة استضافة» (في المخرجات: Control panel detected (…)). المواقع على مثل هذا السيرفر تديرها اللوحة، ولا ينشئ السكربت vhost خاصًا به عن قصد — إذ كان سيُمحى عند أول إعادة بناء للإعدادات من قِبل اللوحة. والترتيب كالتالي:

  1. أنشئ نطاق ويب في لوحة الاستضافة (HestiaCP وما شابه) — ويبقى DocumentRoot الخاص بها كما هو.
  2. ارفع التوزيعة كاملةً إلى public_html لهذا النطاق: إلى جانب index.php وapi/ وassets/ يجب أن توجد أيضًا الملفات والمجلدات الخدمية config.php وincludes/ وdata/ وtmp/ وlogs/ وkeys/ وcron/ وdatabase/. ولا حاجة لنقل أي شيء فوق جذر الويب: فالمجلدات الخدمية محميّة بملف .htaccess من التوزيعة، وتحت Nginx — بالمنع الذي كتبه السكربت في إعداد النطاق.
  3. تُصدَر شهادة SSL بمفتاح Let's Encrypt في اللوحة نفسها — تجاوز الخطوة 06.
  4. ثم تأتي الصلاحيات (أدناه في هذه الخطوة)، وقاعدة البيانات (الخطوة 04)، وconfig.php (الخطوة 05). استبدل المسارات في الأوامر بـ/home/account/web/domain/public_html، والمالك — بمستخدم هذا النطاق بدل www-data.

فرع «إنشاء vhost يدويًا» (في المخرجات: No vhost created (no domain given)). يحدث ذلك على ملف «سيرفر مُعدّ» فقط، عندما لا يُمرَّر النطاق. وأسهل حل — إعادة تشغيل الأمر من الحساب مع تحديد النطاق:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo bash -s -- monitor.example.com

إعادة التشغيل آمنة: فما أُنجز سابقًا لا يتكرر. أما إذا لزم إنشاء vhost يدويًا — فهذا هو الإعداد نفسه الذي يكتبه المثبِّت:

sudo mkdir -p /var/www/monitor # نحدد مقبس PHP-FPM تلقائيًا — فإصدار PHP يختلف من سيرفر لآخر. PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) sudo tee /etc/apache2/sites-available/arciveo-monitor.conf > /dev/null <<'EOF' <VirtualHost *:80> ServerName monitor.example.com DocumentRoot /var/www/monitor <Directory /var/www/monitor> Options -Indexes +FollowSymLinks AllowOverride All Require all granted </Directory> <FilesMatch "\.php$"> SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost" </FilesMatch> ErrorLog ${APACHE_LOG_DIR}/arciveo-monitor_error.log CustomLog ${APACHE_LOG_DIR}/arciveo-monitor_requests.log combined </VirtualHost> EOF sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/arciveo-monitor.conf sudo a2ensite arciveo-monitor.conf sudo apache2ctl configtest sudo systemctl reload apache2
ServerName هنا إلزامي. فالـ vhost بلا اسم يصبح موقع Apache الافتراضي ويبدأ بالرد نيابةً عن نطاقات أخرى على السيرفر نفسه. وللسبب ذاته لا تعطّل 000-default.conf على سيرفر مُعدّ مسبقًا: فقد يكون هذا الموقع مُحوَّلًا إلى موقع عامل لشخص ما — أما على VPS جديد فيزيله المثبِّت بنفسه، ولا داعي لفعل ذلك هنا.
إذا كان أمام Apache يوجد Nginx (في المخرجات: ! Nginx does not read .htaccess). يقدّم Nginx الملفات الساكنة مباشرةً من القرص ولا يقرأ .htaccess — فتصبح المجلدات الخدمية مفتوحة للخارج، رغم أن Apache يغلقها بشكل صحيح. وقد جهّز السكربت مسبقًا ملفًا بالمنوعات؛ يجب تضمينه في كتلة server{} الخاصة بموقعك وإعادة تحميل Nginx:
include /etc/nginx/snippets/arciveo-deny.conf;
sudo nginx -t && sudo systemctl reload nginx # التحقق: يجب أن يُرجِع 403 وليس محتوى الملف curl -sI https://monitor.example.com/config.php | head -1
ملفات اللوحة (أرشيف التوزيعة) تُنزَّل بعد الشراء من الحساب الشخصي على my.arciveo.com ← «التنزيلات». فك ضغط الأرشيف قبل رفعه إلى السيرفر.

ارفع محتوى التوزيعة إلى /var/www/monitor (بحيث يظهر داخله public/ وassets/ وconfig.php إلخ) — عبر SFTP/SCP (FileZilla / WinSCP) أو بأمر scp من جهازك المحلي:

scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/
لكي يُكتب نطاقك مباشرةً في vhost (ServerName)، مرّره إلى أمر الإعداد التلقائي في الخطوة 01 نفسها: … | sudo bash -s -- monitor.example.com (أو حدّد النطاق في حقل «نطاق اللوحة» في الحساب الشخصي). إن لم يُمرَّر النطاق — تستجيب اللوحة لأي مضيف وعبر عنوان IP، وسيكتب certbot قيمة ServerName عند إصدار SSL (الخطوة 06)؛ ولا حاجة لإعادة أي تثبيت.
اضبط صلاحيات الملفات — هذه خطوة إلزامية. إن رفعت الملفات بحساب root أو عبر SFTP، فستكون مملوكة لـroot، ولن يستطيع سيرفر الويب (www-data) قراءتها — فتُفتح اللوحة فارغة أو بخطأ 403 (في السجل: .htaccess unreadable / directory not executable). الأمر التالي يصلح ذلك:
# نضبط صلاحيات جذر الويب بالكامل: المجلد الذي أنشأه root غير متاح # لسيرفر الويب (www-data) — بدون ذلك تعرض اللوحة صفحة فارغة أو خطأ 403. cd /var/www/monitor # ننشئ مجلدات العمل قبل chown — وإلا ستبقى المجلدات الجديدة root:root # ولن يستطيع سيرفر الويب (www-data) الكتابة فيها عند chmod 750. sudo mkdir -p data/lynis data/logwatch tmp logs sudo chown -R www-data:www-data /var/www/monitor sudo find /var/www/monitor -type d -exec chmod 755 {} \; sudo find /var/www/monitor -type f -exec chmod 644 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 750 data tmp logs

افتح لنفسك رفع الملفات عبر SFTP. بعد الأمر أعلاه تصبح كل الملفات مملوكة لـwww-data، بينما يتصل FileZilla / WinSCP بحسابك أنت — عندئذ يفشل الرفع بالخطأ SSH_FX_PERMISSION_DENIED (Permission denied). اختر أحد الخيارين.

الخيار A — قائمة ACL لحسابك وحده (موصى به). صلاحية الكتابة تكون لك وحدك، ويبقى سيرفر الويب غير قادر على استبدال كود اللوحة:

sudo apt install -y acl # صلاحية كتابة لحسابك على كامل مجلد اللوحة: sudo setfacl -R -m u:deploy:rwX /var/www/monitor # القاعدة نفسها كإعداد افتراضي — للملفات والمجلدات التي تُنشأ لاحقًا: sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor

الخيار B — عبر مجموعة www-data. أبسط، لكن صلاحية الكتابة على ملفات اللوحة يحصل عليها سيرفر الويب أيضًا: مع ثغرة في PHP يمكن استبدال الكود. ترتيب الأوامر مهم — config.php ومجلدات العمل تُغلق في النهاية:

sudo usermod -aG www-data deploy # كتابة للمجموعة + setgid (البِت 2): الملفات المرفوعة عبر SFTP تبقى # في مجموعة www-data، وإلا لن تستطيع اللوحة استبدالها. sudo find /var/www/monitor -type d -exec chmod 2775 {} \; sudo find /var/www/monitor -type f -exec chmod 664 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs
بعد الخيار B أعد الاتصال في FileZilla (الخادم ← قطع الاتصال، ثم الدخول من جديد) — المجموعة الجديدة لا تسري إلا عند تسجيل دخول جديد، وقبل ذلك تبقى بلا صلاحيات. التحقق: id deploy — يجب أن تظهر www-data في قائمة المجموعات؛ ls -ld /var/www/monitor — الصلاحيات drwxrwsr-x، وحرف s بدل x يعني أن setgid مفعَّل.

04. قاعدة البيانات

أنشئ قاعدة بيانات ومستخدمًا، ثم استورد المخطط. تُلصق كتلة قاعدة البيانات في الطرفية بالكامل (sudo mysql يدخل بحساب root عبر مقبس unix — لا حاجة لكلمة مرور root). monitor_db وmonitor_user اسمان للمثال، يمكنك اختيار أي اسمين؛ احفظ اسم قاعدة البيانات والمستخدم وكلمة المرور — ستُدخلها في config.php في الخطوة التالية:

# 1. قاعدة البيانات. يُحدَّد اسم القاعدة والمستخدم وكلمة المرور مرة واحدة أدناه وتُدرَج في كل الأسطر. # تُلصق الكتلة في الطرفية بالكامل؛ sudo mysql يدخل بحساب root عبر مقبس unix # (لا حاجة لكلمة مرور root). لا تستخدم `sudo mysql -u root -p` التفاعلي # مع اللصق — فعند اللصق ستذهب سطور SQL إلى مطالبة كلمة المرور وتُفقَد. DBNAME='monitor_db' # ← اسم القاعدة، يمكن إبقاؤه DBUSER='monitor_user' # ← مستخدم القاعدة، يمكن إبقاؤه DBPASS='CHOOSE_A_PASSWORD' # ← كلمة المرور، حدِّد كلمتك sudo mysql <<SQL CREATE DATABASE IF NOT EXISTS $DBNAME CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS '$DBUSER'@'localhost' IDENTIFIED BY '$DBPASS'; GRANT ALL ON $DBNAME.* TO '$DBUSER'@'localhost'; FLUSH PRIVILEGES; SQL # التحقق (يجب أن يُظهر $DBNAME): mysql -u "$DBUSER" -p"$DBPASS" -e "SHOW DATABASES;" # أدخل هذه القيم الثلاث نفسها في config.php → DB_NAME, DB_USER, DB_PASS.
عادةً لا حاجة لاستيراد المخطط — تنشئ اللوحة الجداول وحساب admin تلقائيًا عند أول دخول من المتصفح (من database/db.sql)، إذا كانت قاعدة البيانات فارغة.

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

# استيراد المخطط: cd /var/www/monitor && mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" < database/db.sql # التحقق — يجب أن تظهر قائمة الجداول: mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" -e "SHOW TABLES;"
إذا كانت المتغيرات $DBNAME / $DBUSER / $DBPASS قد «نُسيت» (جلسة طرفية جديدة) — ضع القيم في الأمر يدويًا أو حدّدها من جديد بالأسطر الثلاثة نفسها من الكتلة أعلاه.
sudo لسيرفر الويب. عادةً تكون القواعد مكتوبة بالفعل بواسطة الإعداد التلقائي، فترى الوحدات بيانات النظام فورًا. لكن إذا ظهر في مخرجات السكربت السطر sudo rules NOT written — فلم يكن هناك ما يُستدلّ به على حساب اللوحة (الملفات لم تُرفع بعد)، والقواعد لم تُنشأ. وبدونها ستبقى أقسام مثل جدار الحماية وFail2ban وCrowdSec فارغة. والآن، بعد أن أصبحت الملفات في مكانها، شغّل الأمر من الحساب مرة أخرى مع تسمية الحساب صراحةً:
curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo ARCIVEO_USER=www-data bash -s -- monitor.example.com
استبدل www-data بالمستخدم الذي يعمل به PHP على موقعك (وعلى لوحة الاستضافة يكون عادةً مالك النطاق). ويمكنك معرفته هكذا:
ps -o user= -C php-fpm8.3 | sort -u # ضع إصدارك أنت # أو: ps aux | grep -m3 '[p]hp-fpm'
التحقق بعد إعادة التشغيل: الملف /etc/sudoers.d/monitor موجود ويحتوي على أسطر بمستخدمك.

05. إعداد config.php

config.php في جذر لوحة التحكم (/var/www/monitor/config.php) — الملف الوحيد الذي يجب تعديله يدويًا. جميع إعدادات اللوحة معرّفة فيه كثوابت define(). افتحه في محرر:

sudo nano /var/www/monitor/config.php

ضع قيمك مكان التمييزات، واترك الباقي كما هو:

// --- قاعدة البيانات (من الخطوة 04) --- define('DB_HOST', 'localhost'); // اتركه define('DB_NAME', 'db_name'); // ما أنشأته في الخطوة 04 define('DB_USER', 'user'); // ما أنشأته في الخطوة 04 define('DB_PASS', 'db_password'); // ما حددته في الخطوة 04 define('DB_CHARSET', 'utf8mb4'); // اتركه // --- التطبيق --- define('APP_URL', 'https://monitor.example.com'); // عنوان اللوحة، دون شرطة مائلة في النهاية define('TIMEZONE', 'Asia/Riyadh'); // منطقتك الزمنية // --- مدة الجلسة --- define('SESSION_LIFETIME', 28800); // مدة الخمول قبل إعادة تسجيل الدخول، ثانية (28800 = 8 س)

ما الذي يجب تغييره:

  • DB_NAME وDB_USER وDB_PASS — نفس اسم قاعدة البيانات والمستخدم وكلمة المرور التي حددتها عند إنشاء القاعدة في الخطوة 04 (إن أبقيت الأمثلة — monitor_db / monitor_user). لا تلمس DB_HOST وDB_CHARSET.
  • APP_URL — العنوان الكامل للوحة مع https://، دون شرطة مائلة في النهاية ودون www. يجب أن يطابق النطاق الذي تُفعّل عليه الترخيص (الخطوة 07)، وإلا سيُرفض المفتاح.
  • TIMEZONE — منطقتك الزمنية (القائمة — timedatectl list-timezones). يؤثر فقط على كيفية عرض اللوحة للتواريخ؛ ولا يؤثر على وقت تشغيل مهام cron (هناك تعمل منطقة النظام).
  • SESSION_LIFETIME — بعد كم ثانية من الخمول تطلب اللوحة تسجيل الدخول من جديد (افتراضيًا 8 ساعات). مثلًا 3600 = ساعة، 86400 = يوم.
  • كتلة تسجيل الأخطاء (display_errors, log_errors, error_log) — اتركها على الوضع الافتراضي.

احفظ الملف (Ctrl+O، Enter، ثم Ctrl+X) وأعد تشغيل PHP-FPM — وإلا فلن تُطبَّق التغييرات بسبب OPcache:

sudo systemctl restart php*-fpm
config.php ملف سري (يحتوي على كلمة مرور قاعدة البيانات). يوجد في جذر اللوحة الذي هو جذر الويب نفسه، لكنه محمي: صلاحيات 640 (مضبوطة في الخطوة 03) ومنع صريح في .htaccess الجذر. لا تنشره في مستودعات عامة ولا ترسله للدعم مع كلمة المرور الحقيقية.
شرح مفصل لجميع المعاملات — في الأسئلة الشائعة: «ملف config.php — جميع إعدادات اللوحة».

06. إصدار SSL (HTTPS)

لوحة التحكم تعمل عبر HTTPS فقط. جلسة الدخول تستخدم كوكيز آمنة، وWebAuthn (2FA) وفق المعيار لا يعمل إلا عبر HTTPS. عبر http:// لن تتمكن من تسجيل الدخول.
على سيرفر بلوحة استضافة لا حاجة لهذه الخطوة (في مخرجات السكربت: Certbot skipped — issue SSL in …). تُصدَر الشهادة بمفتاح Let's Encrypt على نطاق الويب في اللوحة نفسها — وبذلك تتولى اللوحة تجديدها أيضًا.

تم بالفعل تثبيت certbot وإضافة Apache عبر الإعداد التلقائي. يجب أن يكون DNS النطاق مُوجَّهًا مسبقًا إلى السيرفر (الخطوة 02). الإصدار بأمر واحد:

sudo certbot --apache -d monitor.example.com

إذا كان يجب أن تُفتح اللوحة أيضًا عبر www. — اذكر الاسمين في أمر واحد، وإلا فسيعرض المتصفح تحذير شهادة على العنوان الثاني:

sudo certbot --apache -d monitor.example.com -d www.monitor.example.com
أضف الاسم الثاني فقط إذا كان له سجل A أيضًا يشير إلى هذا السيرفر (الخطوة 02). وإلا فلن يتمكن Let's Encrypt من التحقق منه ولن يُصدر الشهادة كلها — بما في ذلك النطاق الأساسي.
ما الذي سيسأل عنه certbot:
  1. Enter email address — بريدك الإلكتروني (إليه تصل إشعارات انتهاء الشهادة).
  2. Terms of Service … (Y)es/(N)o — Y.
  3. Share email with the EFF … (Y)es/(N)o — حسب اختيارك.
بعد ذلك يُصدِر certbot الشهادة تلقائيًا، ويكتب <VirtualHost *:443>، ويُعدّ إعادة التوجيه http→https والتجديد التلقائي. في النهاية — Successfully enabled HTTPS.
إذا فشل الإصدار — تحقق من أن dig +short monitor.example.com يُرجِع عنوان IP السيرفر وأن المنفذين 80/443 مفتوحان (sudo ufw allow 80,443/tcp).

بعد الإصدار: يُفتح https://monitor.example.com بقفل الأمان، ويُعيد http:// التوجيه إلى https://.

07. تسجيل الدخول والإعداد الأولي

افتح https://monitor.example.com، وسجّل الدخول بـ admin / useradmin ثم أكمل قائمة التحقق:

  1. تغيير كلمة مرور admin — قسم «المستخدمون» في القائمة.
  2. تفعيل WebAuthn (2FA) — «مفاتيح WebAuthn» ← سجّل مفتاحاً/passkey (يتطلب HTTPS). سجّل مفتاحين دفعة واحدة: عند فقدان المفتاح الوحيد يتعذّر تسجيل الدخول به. التفاصيل.
  3. تقييد الوصول حسب عنوان IP — «الإعدادات» ← «تقييد الوصول حسب عنوان IP» (أدخل عنوان IP الخاص بك قبل التفعيل، وإلا ستحجب وصولك عن نفسك).
  4. إدخال الترخيص — فعّل رمز التفعيل ARCIVEO-… من الحساب الشخصي على نطاقك ثم ألصق المفتاح في «الإعدادات» ← «الترخيص». التفاصيل.
  5. إعداد الإشعارات — Telegram و/أو البريد الإلكتروني في «الإعدادات». التفاصيل.
  6. حذف أداة التثبيت public/start_db.php إن بقيت: فهي تتيح إعادة إنشاء قاعدة البيانات دون مصادقة. وما دام الملف موجوداً في جذر اللوحة أو في public/، تنبّه اللوحة إليه ببانر أحمر.
  7. تشغيل الفحوصات الأولى يدويًا — وإلا ستبقى بعض الأقسام فارغة حتى الليل (انظر الكتلة أدناه).
لماذا يظهر «تدقيق Lynis» و«Logwatch» فارغين في البداية. ثبّت الإعداد التلقائي الأدوات وأنشأ مهام cron، لكنه لم يشغّل الفحوصات نفسها — فهي ستعمل وفق الجدول: Lynis في 03:00، وLogwatch في 06:00، وdebsums في 04:30، وClamAV في 01:30. وحتى تلك اللحظة تعرض الأقسام بصدق أنه لا توجد تقارير بعد. ولكي لا تنتظر يومًا كاملًا، شغّلها مرة واحدة يدويًا:
# تدقيق Lynis — التقرير الأول (بضع دقائق): sudo /usr/local/bin/lynis-scan.sh # تقرير Logwatch عن اليوم: sudo /usr/local/bin/logwatch_daily.sh # سلامة الحزم (debsums) — على سيرفر كبير يستغرق وقتًا طويلًا: sudo /usr/local/bin/debsums-scan.sh
يمكن تشغيل Lynis من اللوحة مباشرةً — زر «تشغيل التدقيق» في صفحة «تدقيق Lynis»: فهو ينفّذ السكربت نفسه في الخلفية ويحدّث التقرير تلقائيًا. وبعد ذلك يسير كل شيء وفق الجدول، ولا حاجة للتشغيل اليدوي بعد الآن.
الفحص الأول لمضاد الفيروسات (sudo /usr/local/bin/clamav-scan.sh) يُحمّل القرص والمعالج بشدة وقد يستغرق ساعة أو أكثر — وعلى سيرفر يعمل من الأفضل انتظار التشغيل الليلي في 01:30. أما أقسام «الأقراص (SMART)» و«الأداء» و«تحديثات الأمان» فتمتلئ تلقائيًا: كل 30 دقيقة، و5 دقائق، ومرة كل ساعة على الترتيب.
تم. دليل كل أداة موجود في FAQ.
إذا كنت بحاجة إلى موقع آخر بنطاق خاص به على هذا السيرفر — راجع الأسئلة الشائعة: «موقع ثانٍ على هذا السيرفر (نطاق إضافي)».
اختيار الطريقة دليل الأسئلة الشائعة