دورة: إدارة الخدمات وتخطيط المهام في لينكس

أهداف التعلم

في نهاية هذه الدورة، ستكون قادرًا على:

فهم الفرق بين الشياطين والخدمات
إتقان systemd و systemctl
إنشاء وإدارة خدمات systemd الخاصة بك
تخطيط المهام باستخدام cron و at
إجراء النسخ الاحتياطي باستخدام rsync
إدارة تدوير السجلات باستخدام logrotate

الجزء 1 – مقدمة إلى الشياطين والخدمات

1.1 التعريف: ما هو الشيطان؟

الشيطان (أو daemon بالإنجليزية) هو برنامج يعمل في الخلفية، بدون واجهة رسومية، ويعمل بصمت لتقديم خدمات أساسية للنظام أو للمستخدمين.

أمثلة بسيطة:

sshd: يتيح الاتصالات عن بعد عبر SSH
httpd: خادم الويب Apache
crond: يخطط لتنفيذ المهام
systemd: ينظم جميع الخدمات الأخرى عند الإقلاع

1.2 التعريف الفني: طبيعة ووظيفة الشيطان

الشيطان هو عملية نظام مستقلة، يتم إطلاقها:

إما عند بدء تشغيل النظام
أو يدويًا بواسطة المسؤول
ولا تتوقف إلا إذا تم إيقافها صراحة.

إنه:

منفصل عن أي طرفية أو جلسة مستخدم (tty)
غالبًا ما يتم إنشاؤه بواسطة عملية init (PID 1)، الآن systemd في معظم التوزيعات الحديثة.

1.3 كيف يتم إنشاء الشياطين؟

3 خطوات:

الإطلاق الأولي عبر ملف تكوين أو سكربت
الانفصال عن الطرفية الحالية
التنفيذ المستمر، غالبًا في حلقة لا نهائية، حتى التوقف أو التعطل

في الأنظمة الحديثة، يتولى systemd هذه الإدارة تلقائيًا عبر وحدات .service.

1.4 أسماء الشياطين تنتهي بـ `d`

إنها قاعدة تسمية:

sshd → Secure Shell Daemon
ftpd → FTP Daemon
systemd → System Daemon
rsyslogd → Remote SYSLOG Daemon

1.5 قائمة الشياطين الشائعة في لينكس

الشيطان	الوظيفة الرئيسية
`sshd`	يتيح الاتصالات SSH
`crond`	يدير المهام المجدولة
`httpd`	يوفر خدمة الويب (Apache)
`systemd`	يتحكم في الخدمات وبدء تشغيل النظام
`rsyslogd`	يدير تسجيل النظام
`cupsd`	يدير الطباعة
`ntpd`	يزامن الوقت مع خوادم NTP

1.6 الشياطين مقابل الخدمات

الشيطان هو عملية، الخدمة هي تجريد منطقي.
يمكن أن تكون الخدمة شيطانًا، ولكن ليس دائمًا (مثل tmp.mount ليست عملية ولكن وحدة).

العنصر	الشيطان	الخدمة
الطبيعة	عملية في الخلفية	وحدة تدار بواسطة systemd
مرئي؟	لا، إلا عبر `ps`, `systemctl`	مرئي مع `systemctl`
مثال	`sshd`	`sshd.service`

الخدمة هي systemd ببساطة

المعيار	الشيطان	الخدمة (systemd)
التعريف	برنامج يعمل في الخلفية	وحدة تدار بواسطة `systemd` لتشغيل وإدارة برنامج
الإطلاق	تلقائي أو يدوي (غالبًا عند الإقلاع)	يدار مع `systemctl` (`start`, `stop`, `enable`, إلخ.)
يعمل في الخلفية؟	نعم	ليس دائمًا (مثل: سكربت قصير يمكن أن يكون خدمة)
يدار بواسطة `systemctl`؟	لا، إلا إذا تم دمجه كخدمة	نعم
يتطلب ملف `.service`؟	لا	نعم (مثل: `/etc/systemd/system/mon_service.service`)
يمكن أن يوجد بدون `systemd`	نعم (أنظمة قديمة، سكربتات يدوية)	لا (الخدمة = وحدة systemd)
أمثلة	`sshd`, `cron`, سكربت لا نهائي في الخلفية	`nginx.service`, `docker.service`, `mon_script.service`

للتذكر:

الشيطان هو برنامج.
الخدمة هي طريقة لإدارة هذا البرنامج مع systemd.

1.7 التحكم في الشياطين

تحت systemd، يتم التحكم في جميع الشياطين عبر systemctl، مع الأوامر التالية:

الإجراء	الأمر
بدء التشغيل	`sudo systemctl start sshd`
الإيقاف	`sudo systemctl stop sshd`
إعادة التشغيل	`sudo systemctl restart sshd`
عرض الحالة	`sudo systemctl status sshd`
التفعيل عند الإقلاع	`sudo systemctl enable sshd`
التعطيل عند الإقلاع	`sudo systemctl disable sshd`

1.8 ملخص – نقاط رئيسية للتذكر

الشيطان هو عملية بدون واجهة، تقدم خدمة.
غالبًا ما يتم تشغيله عند الإقلاع، يدار بواسطة systemd.
لرؤية، تفعيل، تعطيل أو إعادة تشغيل شيطان، نستخدم systemctl.
جميع الخدمات النظامية الحديثة هي الآن وحدات تدار بواسطة systemd.

الجزء 2 – مقدمة إلى systemd و systemctl

2.1 ما هو systemd؟

systemd هو نظام التهيئة الافتراضي لمعظم توزيعات لينكس الحديثة (أوبونتو، فيدورا، ديبيان، سنتوس، إلخ). يحل محل نظام SysVinit القديم ويخدم في:

تهيئة النظام عند الإقلاع (تركيب الأقراص، بدء تشغيل الخدمات، إلخ.)
إدارة جميع خدمات النظام بشكل مركزي
تقديم أدوات مدمجة مثل systemctl, journalctl, systemd-analyze, systemd-nspawn, إلخ.

مزايا systemd:

بدء تشغيل أسرع بفضل التهيئة المتوازية
إعادة تشغيل تلقائية للخدمات في حالة الفشل
إدارة متقدمة للتبعيات بين الخدمات
مركزية تسجيل الأحداث

2.2 دور `systemctl`

systemctl هو الأداة الرئيسية في سطر الأوامر للتفاعل مع systemd.

يسمح بـ:

بدء، إيقاف أو إعادة تشغيل خدمة
تفعيل أو تعطيل خدمة عند الإقلاع
الحصول على حالة خدمة
عرض جميع الخدمات النشطة أو غير النشطة

2.3 الأوامر الأساسية مع `systemctl`

الإجراء	الأمر
بدء خدمة	`sudo systemctl start nom_du_service`
إيقاف خدمة	`sudo systemctl stop nom_du_service`
إعادة تشغيل خدمة	`sudo systemctl restart nom_du_service`
إعادة تحميل التكوين	`sudo systemctl reload nom_du_service`
التحقق من الحالة	`systemctl status nom_du_service`
تفعيل خدمة عند الإقلاع	`sudo systemctl enable nom_du_service`
تعطيل خدمة عند الإقلاع	`sudo systemctl disable nom_du_service`

استبدل nom_du_service بالاسم الحقيقي للخدمة المعنية (مثل: sshd, nginx, apache2, إلخ.).

2.4 عرض الخدمات

عرض جميع الخدمات النشطة:

systemctl list-units --type=service --state=running

عرض جميع الخدمات (نشطة أو غير نشطة):

systemctl list-units --type=service

2.5 استخدام `journalctl` لعرض السجلات

systemd يدمج نظام سجلات مركزي: journald. يمكنك عرض السجلات باستخدام الأمر journalctl.

الهدف	الأمر
عرض جميع السجلات	`journalctl`
عرض سجلات خدمة معينة	`journalctl -u nom_du_service`
عرض السجلات منذ آخر إقلاع	`journalctl -b`
متابعة السجلات في الوقت الحقيقي	`journalctl -f`
عرض السجلات للساعة الأخيرة	`journalctl --since "1 hour ago"`

2.6 الوحدات في systemd

الوحدة هي كائن يمكن لـ systemd إدارته. كل وحدة تتوافق مع ملف بامتداد محدد.

نوع الوحدة	الامتداد	مثال
خدمة	`.service`	`nginx.service`
تركيب	`.mount`	`home.mount`
مقبس	`.socket`	`cups.socket`
هدف	`.target`	`multi-user.target`
مؤقت	`.timer`	`logrotate.timer`

2.7 الأهداف في systemd

الهدف يمثل حالة عامة للنظام، مكافئة لمستويات التشغيل القديمة.

اسم الهدف	الوصف
`rescue.target`	وضع الاسترداد (وصول الجذر فقط)
`multi-user.target`	وضع متعدد المستخدمين بدون واجهة رسومية
`graphical.target`	وضع مع واجهة رسومية
`default.target`	الهدف الافتراضي عند الإقلاع

تغيير الهدف الحالي:

sudo systemctl isolate multi-user.target

2.8 تحليل أداء الإقلاع

قياس الوقت الإجمالي للإقلاع:

systemd-analyze

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

systemd-analyze blame

عرض سلسلة التبعيات الحرجة:

systemd-analyze critical-chain

2.9 إدارة إعادة التشغيل التلقائي

لإجبار إعادة التشغيل التلقائي لخدمة بعد فشل، قم بتعديل أو إنشاء وحدة .service مع:

[Service]
ExecStart=/chemin/vers/script
Restart=always
RestartSec=5

هذا يعيد تشغيل الخدمة بعد 5 ثوانٍ من كل فشل.

2.10 ملخص

systemd هو مدير الوحدات الحديث لأنظمة لينكس
systemctl هو الواجهة في سطر الأوامر للتفاعل مع systemd
الخدمات، الأهداف، المقابس، والموارد الأخرى تسمى وحدات
journalctl يسمح بعرض السجلات النظامية
الأدوات مثل systemd-analyze تسمح بتحليل الأداء عند الإقلاع

الجزء 3 – إنشاء وإدارة خدماتك الخاصة مع systemd

3.1 هدف هذا الجزء

فهم كيفية:

إنشاء وحدة خدمة مخصصة
دمج سكربت نظام في systemd
اختبار، تفعيل، تعطيل وإعادة تشغيل هذه الخدمة

3.2 هيكل ملف `.service`

توجد ملفات الخدمة عادة في:

/etc/systemd/system/ (وحدات مخصصة ودائمة)
/lib/systemd/system/ (وحدات مثبتة بواسطة الحزم)

مثال على ملف `webapp.service`:

[Unit]
Description=Service personnalisé pour lancer une application web
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

شرح الأقسام:

[Unit]: تبعيات الخدمة، الوصف
[Service]: الأمر الذي سيتم تنفيذه، سياسة إعادة التشغيل
[Install]: هدف التفعيل (هنا، مستوى متعدد المستخدمين)

3.3 خطوات إنشاء خدمة systemd مخصصة

الخطوة 1 – كتابة أو تحديد السكربت للتنفيذ

مثال:

sudo nano /usr/local/bin/webapp

محتوى السكربت:

#!/bin/bash
while true; do
  echo "Application en cours d'exécution" >> /var/log/webapp.log
  sleep 30
done

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

sudo chmod +x /usr/local/bin/webapp

الخطوة 2 – إنشاء وحدة الخدمة

sudo nano /etc/systemd/system/webapp.service

انسخ المحتوى التالي:

[Unit]
Description=Web Application Custom Service
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

الخطوة 3 – تفعيل وبدء الخدمة

إعادة تحميل systemd لأخذ الملف الجديد في الاعتبار:

sudo systemctl daemon-reload

تفعيل الخدمة عند الإقلاع:

sudo systemctl enable webapp

بدء الخدمة:

sudo systemctl start webapp

الخطوة 4 – التحقق من حسن الأداء

عرض حالة الخدمة:

systemctl status webapp

التحقق من السجلات:

journalctl -u webapp

3.4 تعديل خدمة موجودة

إذا قمت بتعديل ملف .service:

احفظ
أعد تحميل التكوين:

sudo systemctl daemon-reload

أعد تشغيل الخدمة:

sudo systemctl restart webapp

3.5 حذف خدمة مخصصة

تعطيل الخدمة:

sudo systemctl disable webapp

إيقاف الخدمة:

sudo systemctl stop webapp

حذف ملف الوحدة:

sudo rm /etc/systemd/system/webapp.service

إعادة تحميل systemd:

sudo systemctl daemon-reload

3.6 حالة عملية: إعادة تشغيل تلقائي لسكربت معطل

في كتلة [Service]، استخدم:

Restart=always
RestartSec=5

هذا يسمح بـ:

إعادة تشغيل تلقائي بعد الفشل
انتظار 5 ثوانٍ بين كل إعادة تشغيل

3.7 حالة عملية: خدمة مؤقتة غير دائمة

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

sudo systemctl start /etc/systemd/system/webapp.service

بدون enable، لن يتم تشغيل الخدمة عند الإقلاع التالي.

3.8 ملخص

الخدمات المخصصة systemd تُعرّف في ملفات .service
تسمح بدمج أي سكربت في النظام
استخدام أوامر daemon-reload, enable, start, status ضروري
خدمة جيدة تتضمن سياسة إعادة تشغيل قوية
الهيكل [Unit], [Service], [Install] إلزامي

ملحق الجزء 3 – لا يمكن "قتل" خدمة باستخدام kill أو lsof

هذا الملحق يوضح أنه لا يمكن إيقاف خدمة تدار بواسطة systemd بشكل دائم باستخدام kill, kill -9 أو بمهاجمة العملية (مثل عبر lsof / ss). systemd يعيد تشغيلها طالما أن سياسة Restart=always سارية. الطريقة الوحيدة لإيقافها بشكل صحيح هي systemctl stop (وربما disable أو mask).

التحقق من أن الخدمة تعمل وتكتب في السجل

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l

رؤية PID الخدمة

sudo systemctl status webapp

سترى سطرًا مثل: Main PID: 1234 (webapp).

قتل العملية باستخدام kill (SIGTERM)

sudo kill 1234

ثم إعادة التحقق:

sudo systemctl status webapp

ستلاحظ أن الخدمة تعود إلى active (running) مع PID جديد: systemd أعاد تشغيلها.

أكثر عدوانية: kill -9 (SIGKILL)

sudo kill -9 <NOUVEAU_PID>
sudo systemctl status webapp

نفس النتيجة: systemd يعيد تشغيل العملية مرة أخرى، لأن Restart=always.

إثبات مباشر

في طرفية، تابع السجلات للخدمة:

sudo journalctl -u webapp -f

سترى عمليات إعادة التشغيل المتتالية بعد كل kill أو kill -9.

الحل: الإيقاف عبر systemd

sudo systemctl stop webapp
sudo systemctl status webapp

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

الخيار A (بسيط) – تعطيل عند الإقلاع

sudo systemctl disable webapp

الخيار B (قوي) – إخفاء الخدمة (غير ممكن تشغيلها)

sudo systemctl mask webapp

بعد mask, حتى systemctl start webapp لن يتمكن من تشغيلها حتى تقوم بـ sudo systemctl unmask webapp.

تذكير: الإشارات والأدوات

الإجراء	الأمر / الأداة
إنهاء "نظيف" (SIGTERM)	`kill -15 <PID>` أو `kill <PID>`
فرض الإيقاف (SIGKILL)	`kill -9 <PID>`
رؤية من يستخدم المنافذ / الملفات	`sudo lsof -i`, `sudo lsof -i :80`
رؤية المنافذ TCP/UDP في الاستماع	`sudo ss -ltnp`, `sudo ss -lunp`, `sudo ss -ltnp \| grep -i ...`

هذه الأدوات تستخدم لتشخيص (أي عملية تستمع على منفذ، إلخ.)؛ لإيقاف خدمة، يجب المرور عبر systemctl stop.

ملحق الجزء 3 (2) – نفس التمرين مع خدمة webapp (سيناريو نوع امتحان)

هذا الملحق يعيد نفس العرض التوضيحي كما في الملحق 1، ولكن باستخدام خدمة webapp فقط التي تم إنشاؤها في الخطوة 3 من هذا الفصل (سكربت يكتب في /var/log/webapp.log)، بدون nginx أو Wiki.js. يمكن أن يكون أساسًا لامتحان من نوع خدمات systemd وإدارة العمليات.

المتطلبات المسبقة: تم إنشاء خدمة webapp، تفعيلها وتشغيلها كما في الأقسام 3.2 و 3.3 (سكربت /usr/local/bin/webapp, وحدة /etc/systemd/system/webapp.service, Restart=always).

الخطوة 1 – التحقق من الخدمة والسجل

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

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l
sudo systemctl status webapp

في مخرجات systemctl status webapp, لاحظ السطر Main PID: XXXX (webapp).

الخطوة 2 – محاولة الإيقاف اليدوي (kill)

استبدل <PID> بـ Main PID المعروض:

sudo kill -15 <PID>
# أو ببساطة: sudo kill <PID>

ثم إعادة التحقق:

sudo systemctl status webapp

الملاحظة: تعود الخدمة إلى active (running) مع PID جديد؛ systemd أعاد تشغيلها بسبب Restart=always.

الخطوة 3 – محاولة أكثر عدوانية (kill -9)

استخدم PID الجديد المعروض بواسطة systemctl status webapp:

sudo kill -9 <NOUVEAU_PID>
sudo systemctl status webapp

الملاحظة: نفس النتيجة — systemd يعيد تشغيل العملية مرة أخرى.

الخطوة 4 – إثبات مباشر (journalctl)

في طرفية، تابع السجلات للخدمة لرؤية عمليات إعادة التشغيل بعد كل kill:

sudo journalctl -u webapp -f

الخطوة 5 – تحديد الخدمة (إذا بدأنا من العملية)

إذا كان لدينا فقط PID أو منفذ، يمكننا تحديد الخدمة هكذا:

systemctl list-units --type=service --state=running | grep -i webapp
ps aux | grep webapp
ls -l /etc/systemd/system/ | grep webapp

لخدمة تستمع على منفذ (مثل 3000)، يمكننا أيضًا استخدام:

sudo lsof -i -P -n | grep 3000
sudo ss -ltnp | grep 3000

هنا، webapp لا تستمع على منفذ؛ إنها تملأ فقط /var/log/webapp.log.

الخطوة 6 – الحل: الإيقاف والتعطيل عبر systemd

الإيقاف الفوري:

sudo systemctl stop webapp
sudo systemctl status webapp

التعطيل عند الإقلاع (لن تعود الخدمة للإقلاع التالي):

sudo systemctl disable webapp

الخيار الأقوى — إخفاء الخدمة (غير ممكن تشغيلها طالما أنها مخفية):

sudo systemctl mask webapp

لإلغاء الإخفاء لاحقًا: sudo systemctl unmask webapp.

أدوات مكملة (إضافية) – التحقيق والتشخيص

هذه الأوامر تسمح بتعميق التحقيق في الخدمات والمنافذ. إنها مفيدة في الامتحان أو في الإصلاح.

1. `systemd-cgls` — شجرة مجموعات التحكم (cgroups)

يعرض التسلسل الهرمي لـ cgroups التي يديرها systemd: كل خدمة (بما في ذلك webapp) تعيش في شجرة فرعية. مفيد لرؤية كيف يقوم systemd بتجميع العمليات.

systemd-cgls

لرؤية الجزء المتعلق بخدمتنا فقط:

systemd-cgls | grep -A 5 webapp

ما فائدته؟ فهم أن systemd يعزل ويتابع كل وحدة في cgroup؛ هذا يشرح لماذا لا يقوم kill البسيط للعملية "بإلغاء تسجيل" الخدمة — systemd يراقب الوحدة ويعيد تشغيلها وفقًا لـ Restart=always.

2. `ss -lptn` — المنافذ TCP في الاستماع والعمليات

يسرد المقابس TCP في الاستماع مع PID و البرنامج المرتبط (-l استماع، -p عملية، -t TCP، -n منافذ رقمية).

sudo ss -lptn

مثال على مخرجات (مقتطف):

LISTEN  0  128  *:80    *:*  users:(("nginx",pid=1234,fd=6))
LISTEN  0  128  *:3000  *:*  users:(("node",pid=5678,fd=21))

في سياقنا: خدمة webapp من الخطوة 3 لا تستمع على أي منفذ (إنها تكتب فقط في /var/log/webapp.log). إذا قمت بإنشاء خدمة لاحقًا تستمع على المنفذ 3000 (مثل API أو بروكسي)، ستراها هنا. إنه المكافئ الحديث لـ netstat -lptn, أسرع.

3. `fuser -k 3000/tcp` — قتل العمليات التي تستخدم منفذ

fuser يشير إلى أي العمليات تستخدم ملفًا أو منفذًا. الخيار -k يرسل SIGKILL لهذه العمليات.

مثال للمنفذ 3000 (لاستخدامه إذا كانت خدمة تستمع على هذا المنفذ):

sudo fuser -k 3000/tcp

السلوك التعليمي: إذا كانت خدمة systemd (مثل "webapp-api" المستقبلية) تستمع على المنفذ 3000 مع Restart=always, بعد fuser -k 3000/tcp سيتم قتل العملية، لكن systemd سيعيد تشغيلها وسيكون المنفذ مشغولًا مرة أخرى. لتحرير المنفذ بشكل دائم، يجب systemctl stop <service> (وربما disable).

بدون -k, نعرض فقط PID بدون قتل: sudo fuser -v 3000/tcp.

4. `journalctl -u webapp` — سجلات الخدمة (مكافئ لـ `journalctl -u wikijs.service`)

يعرض جميع الرسائل journald للوحدة webapp (بدء التشغيل، الإيقاف، إعادة التشغيل، الأخطاء).

journalctl -u webapp

تنويعات مفيدة:

الأمر	التأثير
`journalctl -u webapp`	جميع السجلات للخدمة
`journalctl -u webapp -f`	متابعة السجلات في الوقت الحقيقي (مثل `tail -f`)
`journalctl -u webapp -n 50`	آخر 50 سطرًا
`journalctl -u webapp --since "1 hour ago"`	سجلات الساعة الأخيرة

ما فائدته؟ رؤية الدليل على أن systemd يعيد تشغيل الخدمة بعد kill أو fuser -k, وتشخيص الأخطاء عند بدء التشغيل.

ملخص (نوع امتحان)

الإجراء	الأمر	فعال؟
إيقاف العملية بإشارة	`kill -15 <PID>` أو `kill -9 <PID>`	لا — systemd يعيد تشغيل الخدمة
إيقاف الخدمة بشكل صحيح	`sudo systemctl stop webapp`	نعم
تجنب إعادة التشغيل عند الإقلاع	`sudo systemctl disable webapp`	نعم
منع أي تشغيل (حتى يدوي)	`sudo systemctl mask webapp`	نعم

للتذكر: مع خدمة systemd مكونة في Restart=always, kill و kill -9 لا يكفيان؛ يجب استخدام systemctl stop, ثم disable (وربما mask) لتعطيل دائم.

الجزء 4 – تخطيط المهام باستخدام cron

4.1 مقدمة

cron هو أداة تسمح ببرمجة المهام المتكررة في لينكس. الشيطان crond يعمل في الخلفية ويقرأ ملفات crontab لتنفيذ الأوامر في تاريخ/وقت محدد.

4.2 هيكل مهمة cron

*     *     *     *     *   الأمر للتنفيذ
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- يوم الأسبوع (0 إلى 6، الأحد = 0)
|     |     |     +----------- الشهر (1 إلى 12)
|     |     +----------------- يوم الشهر (1 إلى 31)
|     +----------------------- الساعة (0 إلى 23)
+---------------------------- الدقيقة (0 إلى 59)

4.3 نصيحة للتدريب السريع

تعديل crontab للمستخدم الحالي:

crontab -e

عرض المهام cron الموجودة:

crontab -l

4.4 تمرين 1 – نسخ احتياطي لـ /etc كل يوم أحد الساعة 3 صباحًا

الهدف:

إنشاء سكربت يقوم بأرشفة /etc في /var/backups.

الخطوات:

إنشاء مجلد للتمرين:

mkdir ~/cron_tp && cd ~/cron_tp

إنشاء ملف backup.sh:

nano backup.sh

المحتوى:

#!/bin/bash
tar -czf /var/backups/etc-backup-$(date +%Y%m%d).tar.gz /etc

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

chmod +x backup.sh

إنشاء مجلد الوجهة إذا لزم الأمر:

sudo mkdir -p /var/backups

إضافة إلى crontab:

crontab -e

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

0 3 * * 0 /home/utilisateur/cron_tp/backup.sh

استبدل utilisateur باسم المستخدم الخاص بك في لينكس.

4.5 تمرين 2 – استمتع بالنص

الهدف:

كتابة "Bonjour ! Nous sommes le [date]" كل 5 دقائق في ملف.

الأمر في crontab:

*/5 * * * * echo "Bonjour ! Nous sommes le $(date)" >> /tmp/bonjour.txt

تحقق بعد ذلك:

tail /tmp/bonjour.txt

4.6 تمرين 3 – إنشاء صفحة ويب ديناميكية تتغير كل دقيقة

الهدف:

تحميل صفحات ويب مختلفة كل دقيقة وعرضها في مجلد الويب.

الخطوات:

إنشاء ملف mypage.sh:

nano ~/cron_tp/mypage.sh

المحتوى:

#!/bin/bash
urls=("www.yahoo.com" "www.cmaisonneuve.qc.ca" "www.crosemont.qc.ca" "www.netflix.com")

index_file="/home/$USER/index.txt"
backup_dir="/var/www/html"

index=0
if [[ -f "$index_file" ]]; then
  read -r index < "$index_file"
fi

url=${urls[$((index % ${#urls[@]}))]}
wget -qO "$backup_dir/index.html" --timeout=10 "$url"

next_index=$(( (index + 1) % ${#urls[@]} ))
echo "$next_index" > "$index_file"

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

chmod +x ~/cron_tp/mypage.sh

تشغيل المهمة كل دقيقة:

crontab -e

إضافة:

* * * * * /home/utilisateur/cron_tp/mypage.sh

اختبار بالوصول إلى:

http://localhost/index.html

كل دقيقة، ستتغير الصفحة تلقائيًا.

4.7 تمرين 4 – مراقبة العمليات والمستخدمين

الهدف:

مراقبة من هو متصل وما هي العمليات التي تعمل بين الساعة 9 صباحًا و 5 مساءً.

إضافة إلى crontab:

# كل ساعة بين 9 صباحًا و 5 مساءً: العمليات
0 9-17 * * 1-5 ps aux >> /var/log/processus.txt

# كل 5 دقائق بين 9 صباحًا و 5 مساءً: المستخدمون المتصلون
*/5 9-17 * * 1-5 who >> /var/log/qui.txt

عرض بعد ذلك:

tail /var/log/processus.txt
tail /var/log/qui.txt

4.8 نصيحة: اختبار مهام cron مباشرة

للتأكد من أن كل شيء يعمل:

وضع مهمة كل دقيقة:

* * * * * echo "Tâche test à $(date)" >> ~/cron.log

تشغيل:

tail -f ~/cron.log

انتظر دقيقة: سيظهر السطر تلقائيًا.

4.9 ملخص

cron يسمح بتنفيذ السكربتات في أوقات محددة، تلقائيًا.
يجب أن يكون السكربت cron قابلاً للتنفيذ ويحدد مسارًا مطلقًا.
يمكنك مراقبة النتائج باستخدام tail، أو إنشاء ملفات .log للتحقق من تجاربك.
هذا النظام يسمح بإجراء نسخ احتياطية، اختبارات تلقائية، أو تحديث خدمات ديناميكية.

الجزء 5 – المهام المؤقتة باستخدام `at`

5.1 ما هو `at`؟

برنامج at يسمح ببرمجة مهمة واحدة للتنفيذ لاحقًا، مرة واحدة فقط (على عكس cron، الذي يتكرر).

إنه مثالي لـ:

تخطيط إعادة تشغيل النظام
تشغيل سكربت معالجة مؤجل
أتمتة عملية حساسة في وقت محدد

5.2 التحقق وتثبيت خدمة `atd`

قبل كل شيء، تأكد من أن الشيطان atd نشط:

sudo systemctl start atd
sudo systemctl enable atd
sudo systemctl status atd

إذا لم يكن at مثبتًا:

sudo apt install at   # ديبيان/أوبونتو
sudo yum install at   # سنتوس/RHEL

5.3 الصياغة الأساسية

at <heure ou moment>

أمثلة:

at now + 1 minute
at 17:00
at 09:30 tomorrow
at now + 2 days

بمجرد الدخول إلى المحرر at>, اكتب الأمر للتنفيذ، ثم انتهي بـ Ctrl + D.

5.4 تمرين 1 – تخطيط رسالة مؤجلة

الهدف:

عرض رسالة على الطرفية الخاصة بك في دقيقة واحدة.

شغل الأمر:

at now + 1 minute

في الموجه at>, اكتب:

echo "Ceci est un message planifié avec at"

انتهي بـ:

Ctrl + D

انتظر دقيقة وتحقق من أن الرسالة تظهر.

5.5 تمرين 2 – سكربت مؤجل على طرفية أخرى

الهدف:

عرض رسالة على طرفية أخرى (مثل: /dev/pts/0).

إنشاء سكربت traitement.sh:

nano ~/cron_tp/traitement.sh

المحتوى:

#!/bin/bash
echo "Message différé sur le terminal /dev/pts/0" > /dev/pts/0

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

chmod +x ~/cron_tp/traitement.sh

تخطيط السكربت:

at now + 2 minutes -f ~/cron_tp/traitement.sh

افتح الطرفية pts/0 بالتوازي وراقب.

5.6 إدارة المهام `at`

الإجراء	الأمر
عرض المهام المخططة	`atq` أو `at -l`
حذف مهمة (ID = 5 مثلاً)	`atrm 5` أو `at -d 5`
عرض محتوى المهمة ID 5	`at -c 5`

5.7 التحكم في الوصول إلى `at`

الملف	الوظيفة
`/etc/at.allow`	فقط المستخدمون المدرجون هنا يمكنهم استخدام `at`
`/etc/at.deny`	جميع المستخدمين باستثناء المدرجين هنا يمكنهم استخدام `at`

الأولوية:

إذا كان at.allow موجودًا، فقط المستخدمون في هذا الملف لديهم الحق.
خلاف ذلك، يطبق at.deny.

مثال: منع `toto`

echo toto >> /etc/at.deny

5.8 تمرين 3 – تخطيط إعادة تشغيل الجمعة الساعة 17:00

الهدف:

أتمتة إعادة تشغيل في تاريخ محدد.

اكتب:

at 17:00 Fri

في الموجه at>, أدخل:

sudo /sbin/shutdown -r now

انتهي بـ Ctrl + D

ملاحظة: للاختبار بدون إعادة تشغيل، استخدم echo "Redémarrage prévu" بدلاً من ذلك.

5.9 تمرين 4 – سكربت تلقائي في غضون يومين

إنشاء سكربت بسيط:

echo "echo Traitement terminé dans 2 jours" > ~/cron_tp/futur.sh
chmod +x ~/cron_tp/futur.sh

خططه:

at now + 2 days -f ~/cron_tp/futur.sh

5.10 ملخص

at مفيد للمهام المؤقتة، الفريدة، المؤجلة.
إنه مكمل لـ cron, الذي هو دوري.
يمكنك رؤية التأثير فورًا مع echo, أو بناء سكربتات مؤجلة.

الجزء 6 – النسخ الاحتياطي المتقدم والمجدول مع `rsync`

6.1 لماذا استخدام `rsync`؟

rsync هو أداة تزامن قوية تسمح بنسخ الملفات:

محليًا أو بين جهازين
بطريقة محسنة (لا ينسخ إلا الملفات المعدلة)
مع ضغط، تصفية، نسخ احتياطي وتسجيل

إنه مثالي لـ:

نسخ احتياطية منتظمة
ترحيل الخوادم
نسخ تفاضلية سريعة

6.2 الصياغة الأساسية

rsync [options] source destination

مثال بسيط:

rsync -av /home/user/documents /mnt/backup/

خيارات شائعة:

-a: أرشيف (يحافظ على الأذونات، الروابط، التواريخ)
-v: مفصل (يعرض ما يتم نسخه)
--delete: يحذف الملفات الغائبة عن المصدر
--bwlimit=KBps: يحد من عرض النطاق الترددي المستخدم

6.3 تمرين 1 – نسخ احتياطي محلي مع تحديد عرض النطاق الترددي

الهدف:

نسخ احتياطي لمجلد /home في /mnt/backup كل ليلة الساعة 20:00، دون تشبع عرض النطاق الترددي.

الخطوات:

إنشاء السكربت:

mkdir -p ~/cron_tp
nano ~/cron_tp/sync_home.sh

المحتوى:

#!/bin/bash
rsync -av --delete --bwlimit=200 /home/ /mnt/backup/

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

chmod +x ~/cron_tp/sync_home.sh

إضافة في crontab:

crontab -e

إضافة:

0 20 * * * /home/utilisateur/cron_tp/sync_home.sh

(استبدل utilisateur باسمك الحقيقي)

6.4 تمرين 2 – تزامن عن بعد

الهدف:

تزامن /var/www إلى خادم آخر عبر SSH.

الأمر المباشر (للاختبار يدويًا قبل الأتمتة):

rsync -avz -e ssh /var/www user@remote_host:/backup/www

سكربت مؤتمت:

nano ~/cron_tp/rsync_remote.sh

المحتوى:

#!/bin/bash
rsync -az -e ssh /var/www user@192.168.0.100:/backup/www

Crontab (تنفيذ يومي الساعة 01:00):

0 1 * * * /home/utilisateur/cron_tp/rsync_remote.sh

المتطلبات المسبقة:

الوصول SSH بدون كلمة مرور (مفتاح عام/خاص مكون)
حقوق الكتابة على /backup/www على الجهاز البعيد

6.5 تمرين 3 – نسخ احتياطي ليلي فقط

الهدف:

تحديد تنفيذ rsync لساعات غير العمل (19:00 إلى 07:00). إيقاف أي عملية rsync خلال النهار.

الخطوات:

سكربت تشغيل rsync:

crontab -e

إضافة:

0 19 * * * /home/utilisateur/cron_tp/sync_home.sh

سكربت إيقاف الأمان:

0 7 * * * pkill rsync

هذا يضمن أن:

rsync يبدأ في 19:00
إذا كان لا يزال نشطًا في 07:00، يتم قتله

6.6 تمرين 4 – نسخ احتياطي مع تسجيل

سكربت:

nano ~/cron_tp/rsync_logged.sh

المحتوى:

#!/bin/bash
date >> /var/log/rsync_backup.log
rsync -av --delete /home /mnt/backup >> /var/log/rsync_backup.log 2>&1

تخطيط يومي:

0 22 * * * /home/utilisateur/cron_tp/rsync_logged.sh

قراءة السجل:

tail -n 20 /var/log/rsync_backup.log

6.7 ملخص

rsync هو أداة سريعة، ذكية، و قابلة للتحكم
يمكن تحديد عرض النطاق الترددي مع --bwlimit
يمكن أتمتته مع cron
يمكن تقييده لساعات معينة
يسمح بتسجيل كامل للمراجعة والمتابعة

الجزء 7 – إدارة السجلات وتدويرها مع `logrotate`

7.1 لماذا استخدام `logrotate`؟

السجلات النظامية (في /var/log/) تزداد باستمرار مع الوقت:

يمكن أن تشبع القرص
تصبح ثقيلة للعرض
يمكن أن تقلل الأداء إذا لم تُدار بشكل جيد

logrotate يسمح بـ:

تدوير تلقائي للسجلات
حذف أو ضغط الملفات القديمة
الحفاظ على تاريخ محدود في الوقت
تنفيذ أمر بعد التدوير (مثل إعادة تشغيل خدمة)

7.2 العمل العام

logrotate يتم تشغيله عادة يوميًا بواسطة cron, عبر:

/etc/cron.daily/logrotate

يقرأ التكوين العام:

/etc/logrotate.conf

و التكوينات الخاصة:

/etc/logrotate.d/

7.3 صياغة ملف التكوين

مثال:

/var/log/webapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

التفسيرات:

weekly: تدوير كل أسبوع
rotate 4: الاحتفاظ بـ 4 ملفات قديمة
compress: ضغط السجلات القديمة
missingok: عدم عرض خطأ إذا كان الملف مفقودًا
notifempty: عدم تدوير الملف إذا كان فارغًا
postrotate: تنفيذ أمر بعد التدوير

7.4 تمرين 1 – تدوير سجل مخصص

الهدف:

تدوير /var/log/rsync_backup.log كل أسبوع، الاحتفاظ بـ 4 نسخ مضغوطة.

إنشاء ملف /etc/logrotate.d/rsync_backup:

sudo nano /etc/logrotate.d/rsync_backup

المحتوى:

/var/log/rsync_backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

اختبار التكوين:

sudo logrotate /etc/logrotate.conf --debug

فرض التدوير للاختبار:

sudo logrotate /etc/logrotate.conf --force

التحقق:

ls -lh /var/log/rsync_backup*

7.5 تمرين 2 – تدوير مع إعادة تشغيل الخدمة

الهدف:

تدوير /var/log/webapp.log وإعادة تشغيل خدمة webapp.

إنشاء الملف:

sudo nano /etc/logrotate.d/webapp

المحتوى:

/var/log/webapp.log {
    weekly
    rotate 2
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

فرض التدوير للاختبار:

sudo logrotate -f /etc/logrotate.conf

7.6 تمرين 3 – تدوير وإرسال بالبريد الإلكتروني (محاكاة)

الهدف:

إرسال آخر 100 سطر من الملف /var/log/syslog كل ليلة عند منتصف الليل.

إضافة في crontab:

crontab -e

المحتوى:

0 0 * * * tail -n 100 /var/log/syslog | mail -s "Derniers logs système" votreadresse@email.com

لاختبار الإرسال محليًا:

mail

المتطلبات المسبقة: يجب أن يكون النظام يحتوي على وكيل بريد مثبت (mailutils, sendmail, postfix...).

7.7 تمرين 4 – تدوير مخصص لملف محاكى

إنشاء سجل وهمي:

echo "ligne test" >> /tmp/test.log

إنشاء ملف /etc/logrotate.d/testlog:

sudo nano /etc/logrotate.d/testlog

المحتوى:

/tmp/test.log {
    daily
    rotate 3
    compress
    missingok
    notifempty
}

فرض التدوير:

sudo logrotate -f /etc/logrotate.conf

ملاحظة الملفات:

ls -lh /tmp/test.log*

7.8 ملخص

logrotate يدير الحجم، التكرار، الاحتفاظ والضغط للسجلات
يندمج بشكل مثالي مع cron (عبر /etc/cron.daily/logrotate)
يمكنه إعادة تشغيل الخدمات أو إرسال البريد الإلكتروني
ملفات التكوين المخصصة تذهب إلى /etc/logrotate.d/

الجزء 8 – اختبار نهائي وتقييم عملي

8.1 الهدف التعليمي

التحقق من أن المتعلم يعرف:

إنشاء، تفعيل ومراقبة خدمة systemd مخصصة
تخطيط مهام متكررة ومؤقتة باستخدام cron و at
تزامن المجلدات باستخدام rsync وتحديد عرض النطاق الترددي
إدارة تدوير السجلات باستخدام logrotate
استخدام الأدوات المناسبة للمراقبة (systemctl, journalctl, logrotate, إلخ.)

8.2 الجزء A – قراءة وتحليل `crontab` (5 نقاط)

اشرح ما يفعله كل سطر التالي:

0 3 * * 0 /usr/local/bin/backup.sh
*/10 9-17 * * 1-5 who >> /var/log/connected.log
@reboot systemctl restart nginx
0 19 * * * /home/user/sync.sh
0 7 * * * pkill rsync

8.3 الجزء B – إنشاء خدمة systemd (15 نقطة)

يجب عليك إنشاء خدمة تسمى weather_logger التي:

تنفذ سكربت /usr/local/bin/weather.sh
تكتب درجة الحرارة في /var/log/weather.log كل 5 دقائق (عبر cron)
يجب أن تعيد الخدمة التشغيل تلقائيًا في حالة الفشل
توفير ملف weather_logger.service
تفعيل وبدء الخدمة
التحقق من حالتها وسجلاتها

8.4 الجزء C – تخطيط مؤجل باستخدام `at` (5 نقاط)

إنشاء سكربت /home/user/alert.sh الذي يرسل رسالة "Test de sécurité terminé" في ملف /tmp/alerte.log.
برمجة هذا السكربت ليتم تنفيذه في ساعتين بالضبط من الآن.

8.5 الجزء D – تزامن `rsync` (10 نقاط)

إنشاء سكربت sync_project.sh الذي:

يقوم بنسخ احتياطي لمجلد /home/user/projects/ إلى /mnt/sauvegardes/
يحذف الملفات القديمة (--delete)
يحدد عرض النطاق الترددي إلى 150 KB/s
يسجل الإجراءات في /var/log/sync.log

تخطيط هذا السكربت ليتم تنفيذه كل ليلة الساعة 22:00.

8.6 الجزء E – تدوير السجلات مع `logrotate` (10 نقاط)

إنشاء ملف تكوين /etc/logrotate.d/weather للملف /var/log/weather.log
المتطلبات:
- تدوير أسبوعي
- الاحتفاظ بـ 3 ملفات
- ضغط مفعل
- تدوير حتى لو كان فارغًا
- إعادة تشغيل خدمة weather_logger بعد التدوير

8.7 الجزء F – دراسة حالة نهائية: سيناريو كامل (15 نقطة)

السياق: تدير خادم لينكس يعمل عليه تطبيق مخصص (/usr/local/bin/monitor.py).

الأهداف:

إنشاء خدمة monitor.service التي تنفذ هذا السكربت عند بدء تشغيل النظام.
تخطيط نسخ احتياطي لدليل /opt/monitoring كل يوم الساعة 1:00 في /mnt/monitor_backup باستخدام rsync, محدد إلى 250 KB/s.
إنشاء ملف /etc/logrotate.d/monitoring.log للملف /var/log/monitoring.log, مع تدوير كل يومين، الاحتفاظ بـ 5 سجلات مضغوطة.
إرسال آخر 100 سطر من /var/log/syslog بالبريد الإلكتروني كل صباح الساعة 6:00 إلى admin@example.com.

8.8 المعيار (من 60 نقطة)

الجزء	النقاط
A – تحليل crontab	5
B – خدمة systemd	15
C – تخطيط باستخدام `at`	5
D – سكربت rsync	10
E – logrotate مخصص	10
F – حالة كاملة	15

8.9 التعليمات النهائية

يجب أن تكون جميع السكربتات قابلة للتنفيذ (chmod +x)
يجب أن تكون المسارات مطلقة
يجب أن تعرض مخرجات:
- systemctl status
- journalctl -u
- ls -lh في أدلة السجلات والنسخ الاحتياطية

الفصل تم إنشاؤه في: ديسمبر 2024

أهداف التعلم
1.1 التعريف: ما هو الشيطان؟
- أمثلة بسيطة:
1.2 التعريف الفني: طبيعة ووظيفة الشيطان
1.3 كيف يتم إنشاء الشياطين؟
- 3 خطوات:
1.4 أسماء الشياطين تنتهي بـ d
1.5 قائمة الشياطين الشائعة في لينكس
1.6 الشياطين مقابل الخدمات
- للتذكر:
1.7 التحكم في الشياطين
1.8 ملخص – نقاط رئيسية للتذكر
2.1 ما هو systemd؟
- مزايا systemd:
2.2 دور systemctl
2.3 الأوامر الأساسية مع systemctl
2.4 عرض الخدمات
2.5 استخدام journalctl لعرض السجلات
2.6 الوحدات في systemd
2.7 الأهداف في systemd
2.8 تحليل أداء الإقلاع
2.9 إدارة إعادة التشغيل التلقائي
2.10 ملخص
3.1 هدف هذا الجزء
3.2 هيكل ملف .service
- مثال على ملف webapp.service:
- شرح الأقسام:
3.3 خطوات إنشاء خدمة systemd مخصصة
- الخطوة 1 – كتابة أو تحديد السكربت للتنفيذ
- الخطوة 2 – إنشاء وحدة الخدمة
- الخطوة 3 – تفعيل وبدء الخدمة
- الخطوة 4 – التحقق من حسن الأداء
3.4 تعديل خدمة موجودة
3.5 حذف خدمة مخصصة
3.6 حالة عملية: إعادة تشغيل تلقائي لسكربت معطل
3.7 حالة عملية: خدمة مؤقتة غير دائمة
3.8 ملخص
- التحقق من أن الخدمة تعمل وتكتب في السجل
- رؤية PID الخدمة
- قتل العملية باستخدام kill (SIGTERM)
- أكثر عدوانية: kill -9 (SIGKILL)
- إثبات مباشر
- الحل: الإيقاف عبر systemd
- تذكير: الإشارات والأدوات
- الخطوة 1 – التحقق من الخدمة والسجل
- الخطوة 2 – محاولة الإيقاف اليدوي (kill)
- الخطوة 3 – محاولة أكثر عدوانية (kill -9)
- الخطوة 4 – إثبات مباشر (journalctl)
- الخطوة 5 – تحديد الخدمة (إذا بدأنا من العملية)
- الخطوة 6 – الحل: الإيقاف والتعطيل عبر systemd
- أدوات مكملة (إضافية) – التحقيق والتشخيص
- ملخص (نوع امتحان)
4.1 مقدمة
4.2 هيكل مهمة cron
4.3 نصيحة للتدريب السريع
4.4 تمرين 1 – نسخ احتياطي لـ /etc كل يوم أحد الساعة 3 صباحًا
- الهدف:
- الخطوات:
4.5 تمرين 2 – استمتع بالنص
- الهدف:
- الأمر في crontab:
4.6 تمرين 3 – إنشاء صفحة ويب ديناميكية تتغير كل دقيقة
- الهدف:
- الخطوات:
4.7 تمرين 4 – مراقبة العمليات والمستخدمين
- الهدف:
- إضافة إلى crontab:
4.8 نصيحة: اختبار مهام cron مباشرة
4.9 ملخص
5.1 ما هو at؟
5.2 التحقق وتثبيت خدمة atd
5.3 الصياغة الأساسية
5.4 تمرين 1 – تخطيط رسالة مؤجلة
- الهدف:
5.5 تمرين 2 – سكربت مؤجل على طرفية أخرى
- الهدف:
5.6 إدارة المهام at
5.7 التحكم في الوصول إلى at
- مثال: منع toto
5.8 تمرين 3 – تخطيط إعادة تشغيل الجمعة الساعة 17:00
- الهدف:
5.9 تمرين 4 – سكربت تلقائي في غضون يومين
5.10 ملخص
6.1 لماذا استخدام rsync؟
6.2 الصياغة الأساسية
6.3 تمرين 1 – نسخ احتياطي محلي مع تحديد عرض النطاق الترددي
- الهدف:
- الخطوات:
6.4 تمرين 2 – تزامن عن بعد
- الهدف:
6.5 تمرين 3 – نسخ احتياطي ليلي فقط
- الهدف:
- الخطوات:
6.6 تمرين 4 – نسخ احتياطي مع تسجيل
6.7 ملخص
7.1 لماذا استخدام logrotate؟
7.2 العمل العام
7.3 صياغة ملف التكوين
- مثال:
- التفسيرات:
7.4 تمرين 1 – تدوير سجل مخصص
- الهدف:
7.5 تمرين 2 – تدوير مع إعادة تشغيل الخدمة
- الهدف:
7.6 تمرين 3 – تدوير وإرسال بالبريد الإلكتروني (محاكاة)
- الهدف:
7.7 تمرين 4 – تدوير مخصص لملف محاكى
7.8 ملخص
8.1 الهدف التعليمي
8.2 الجزء A – قراءة وتحليل crontab (5 نقاط)
8.3 الجزء B – إنشاء خدمة systemd (15 نقطة)
8.4 الجزء C – تخطيط مؤجل باستخدام at (5 نقاط)
8.5 الجزء D – تزامن rsync (10 نقاط)
8.6 الجزء E – تدوير السجلات مع logrotate (10 نقاط)
8.7 الجزء F – دراسة حالة نهائية: سيناريو كامل (15 نقطة)
8.8 المعيار (من 60 نقطة)
8.9 التعليمات النهائية

أهداف التعلم​

الجزء 1 – مقدمة إلى الشياطين والخدمات

1.1 التعريف: ما هو الشيطان؟​

أمثلة بسيطة:​

1.2 التعريف الفني: طبيعة ووظيفة الشيطان​

1.3 كيف يتم إنشاء الشياطين؟​

3 خطوات:​

1.4 أسماء الشياطين تنتهي بـ d​

1.5 قائمة الشياطين الشائعة في لينكس​

1.6 الشياطين مقابل الخدمات​

الخدمة هي systemd ببساطة​

للتذكر:​

1.7 التحكم في الشياطين​

1.8 ملخص – نقاط رئيسية للتذكر​

الجزء 2 – مقدمة إلى systemd و systemctl

2.1 ما هو systemd؟​

مزايا systemd:​

2.2 دور systemctl​

2.3 الأوامر الأساسية مع systemctl​

2.4 عرض الخدمات​

2.5 استخدام journalctl لعرض السجلات​

2.6 الوحدات في systemd​

2.7 الأهداف في systemd​

2.8 تحليل أداء الإقلاع​

2.9 إدارة إعادة التشغيل التلقائي​

2.10 ملخص​

الجزء 3 – إنشاء وإدارة خدماتك الخاصة مع systemd

3.1 هدف هذا الجزء​

3.2 هيكل ملف .service​

مثال على ملف webapp.service:​

شرح الأقسام:​

3.3 خطوات إنشاء خدمة systemd مخصصة​

الخطوة 1 – كتابة أو تحديد السكربت للتنفيذ​

الخطوة 2 – إنشاء وحدة الخدمة​

الخطوة 3 – تفعيل وبدء الخدمة​

الخطوة 4 – التحقق من حسن الأداء​

3.4 تعديل خدمة موجودة​

3.5 حذف خدمة مخصصة​

3.6 حالة عملية: إعادة تشغيل تلقائي لسكربت معطل​

3.7 حالة عملية: خدمة مؤقتة غير دائمة​

3.8 ملخص​

التحقق من أن الخدمة تعمل وتكتب في السجل​

رؤية PID الخدمة​

قتل العملية باستخدام kill (SIGTERM)​

أكثر عدوانية: kill -9 (SIGKILL)​

إثبات مباشر​

الحل: الإيقاف عبر systemd​

تذكير: الإشارات والأدوات​

الخطوة 1 – التحقق من الخدمة والسجل​

الخطوة 2 – محاولة الإيقاف اليدوي (kill)​

الخطوة 3 – محاولة أكثر عدوانية (kill -9)​

الخطوة 4 – إثبات مباشر (journalctl)​

الخطوة 5 – تحديد الخدمة (إذا بدأنا من العملية)​

الخطوة 6 – الحل: الإيقاف والتعطيل عبر systemd​

أدوات مكملة (إضافية) – التحقيق والتشخيص​

1. systemd-cgls — شجرة مجموعات التحكم (cgroups)​

2. ss -lptn — المنافذ TCP في الاستماع والعمليات​

3. fuser -k 3000/tcp — قتل العمليات التي تستخدم منفذ​

4. journalctl -u webapp — سجلات الخدمة (مكافئ لـ journalctl -u wikijs.service)​

ملخص (نوع امتحان)​

الجزء 4 – تخطيط المهام باستخدام cron

4.1 مقدمة​

4.2 هيكل مهمة cron​

4.3 نصيحة للتدريب السريع​

4.4 تمرين 1 – نسخ احتياطي لـ /etc كل يوم أحد الساعة 3 صباحًا​

الهدف:​

الخطوات:​

4.5 تمرين 2 – استمتع بالنص​

الهدف:​

الأمر في crontab:​

4.6 تمرين 3 – إنشاء صفحة ويب ديناميكية تتغير كل دقيقة​

الهدف:​

الخطوات:​

4.7 تمرين 4 – مراقبة العمليات والمستخدمين​

الهدف:​

إضافة إلى crontab:​

4.8 نصيحة: اختبار مهام cron مباشرة​

4.9 ملخص​

الجزء 5 – المهام المؤقتة باستخدام at

5.1 ما هو at؟​

أهداف التعلم

1.1 التعريف: ما هو الشيطان؟

أمثلة بسيطة:

1.2 التعريف الفني: طبيعة ووظيفة الشيطان

1.3 كيف يتم إنشاء الشياطين؟

3 خطوات:

1.4 أسماء الشياطين تنتهي بـ `d`

1.5 قائمة الشياطين الشائعة في لينكس

1.6 الشياطين مقابل الخدمات

الخدمة هي systemd ببساطة

للتذكر:

1.7 التحكم في الشياطين

1.8 ملخص – نقاط رئيسية للتذكر

2.1 ما هو systemd؟

مزايا systemd:

2.2 دور `systemctl`

2.3 الأوامر الأساسية مع `systemctl`

2.4 عرض الخدمات

2.5 استخدام `journalctl` لعرض السجلات

2.6 الوحدات في systemd

2.7 الأهداف في systemd

2.8 تحليل أداء الإقلاع

2.9 إدارة إعادة التشغيل التلقائي

2.10 ملخص

3.1 هدف هذا الجزء

3.2 هيكل ملف `.service`

مثال على ملف `webapp.service`:

شرح الأقسام:

3.3 خطوات إنشاء خدمة systemd مخصصة

الخطوة 1 – كتابة أو تحديد السكربت للتنفيذ

الخطوة 2 – إنشاء وحدة الخدمة

الخطوة 3 – تفعيل وبدء الخدمة

الخطوة 4 – التحقق من حسن الأداء

3.4 تعديل خدمة موجودة

3.5 حذف خدمة مخصصة

3.6 حالة عملية: إعادة تشغيل تلقائي لسكربت معطل

3.7 حالة عملية: خدمة مؤقتة غير دائمة

3.8 ملخص

التحقق من أن الخدمة تعمل وتكتب في السجل

رؤية PID الخدمة

قتل العملية باستخدام kill (SIGTERM)

أكثر عدوانية: kill -9 (SIGKILL)

إثبات مباشر

الحل: الإيقاف عبر systemd

تذكير: الإشارات والأدوات

الخطوة 1 – التحقق من الخدمة والسجل

الخطوة 2 – محاولة الإيقاف اليدوي (kill)

الخطوة 3 – محاولة أكثر عدوانية (kill -9)

الخطوة 4 – إثبات مباشر (journalctl)

الخطوة 5 – تحديد الخدمة (إذا بدأنا من العملية)

الخطوة 6 – الحل: الإيقاف والتعطيل عبر systemd

أدوات مكملة (إضافية) – التحقيق والتشخيص

1. `systemd-cgls` — شجرة مجموعات التحكم (cgroups)

2. `ss -lptn` — المنافذ TCP في الاستماع والعمليات

3. `fuser -k 3000/tcp` — قتل العمليات التي تستخدم منفذ

4. `journalctl -u webapp` — سجلات الخدمة (مكافئ لـ `journalctl -u wikijs.service`)

ملخص (نوع امتحان)

4.1 مقدمة

4.2 هيكل مهمة cron

4.3 نصيحة للتدريب السريع

4.4 تمرين 1 – نسخ احتياطي لـ /etc كل يوم أحد الساعة 3 صباحًا

الهدف:

الخطوات:

4.5 تمرين 2 – استمتع بالنص

الهدف:

الأمر في crontab:

4.6 تمرين 3 – إنشاء صفحة ويب ديناميكية تتغير كل دقيقة

الهدف:

الخطوات:

4.7 تمرين 4 – مراقبة العمليات والمستخدمين

الهدف:

إضافة إلى crontab:

4.8 نصيحة: اختبار مهام cron مباشرة

4.9 ملخص

الجزء 5 – المهام المؤقتة باستخدام `at`

5.1 ما هو `at`؟

5.2 التحقق وتثبيت خدمة `atd`

5.3 الصياغة الأساسية

5.4 تمرين 1 – تخطيط رسالة مؤجلة

الهدف: