Linux Systems And Infrastructure

يحاول الإنهاء العادي منح البرنامج فرصة لإغلاق الملفات وحفظ البيانات، أما الإنهاء القسري فيوقفه فورًا وقد يترك بيانات غير مكتملة.

systemd هو مدير الخدمات والتهيئة في معظم توزيعات لينكس الحديثة. تتحكم في خدمة باستخدام systemctl:

bash systemctl status nginx systemctl restart nginx systemctl enable --now nginx

يعرض status الحالة وآخر الرسائل، ويعيد restart تشغيل الخدمة، بينما يفعّل enable --now التشغيل التلقائي مع تشغيل الخدمة فورًا. اقرأ السجل بدل الاكتفاء برسالة “فشل التشغيل”:

bash journalctl -u nginx -b --no-pager

يعرض الخيار -u سجل الوحدة، ويقصر -b النتائج على الإقلاع الحالي. ابحث عن مسار ملف خاطئ، منفذ مستخدم، أو إذن مرفوض.

لإنشاء خدمة مخصصة، اكتب وحدة في /etc/systemd/system/backup-local.service:

`ini [Unit] Description=نسخ إعدادات محلية After=local-fs.target

[Service] Type=oneshot ExecStart=/usr/local/sbin/backup-local.sh

[Install] WantedBy=multi-user.target `

بعد حفظها، نفّذ:

bash systemctl daemon-reload systemctl start backup-local.service systemctl status backup-local.service

يقرأ daemon-reload تعريف الوحدة الجديد. استخدم Type=oneshot عندما تنفذ الخدمة مهمة وتنتهي، ولا تستخدمه لخدمة طويلة الأمد.

الصلاحيات تكمل الطبقات السابقة. يتكون إذن الملف من قراءة وكتابة وتنفيذ للمالك والمجموعة والآخرين. افحصها عبر:

bash ls -l /etc/ssh/sshd_config

يغيّر chown المالك والمجموعة، ويغيّر chmod الأذونات:

bash chown root:root /etc/ssh/sshd_config chmod 600 /etc/ssh/sshd_config

يمنح 600 المالك القراءة والكتابة فقط. استخدم قوائم التحكم بالوصول (Access Control Lists) عندما تحتاج إلى منح مستخدم إضافي وصولًا محددًا دون تغيير مالك الملف:

bash setfacl -m u:deploy:r /srv/app/config.yml getfacl /srv/app/config.yml

تمنح القاعدة السابقة المستخدم deploy صلاحية القراءة فقط. راجع أيضًا البتات الخاصة: يمنح SUID البرنامج هوية مالكه أثناء التنفيذ، ويجعل SGID الملفات الجديدة ترث المجموعة، بينما يمنع Sticky Bit المستخدم من حذف ملفات لا يملكها داخل دليل مشترك مثل /tmp. افحصها بعناية قبل تغييرها، لأن الخطأ فيها قد يوسع الوصول إلى ملفات حساسة.

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

تطبيق عملي: تشخيص خدمة متوقفة

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

1. تحقق من حالة الخدمة bash systemctl status nginx --no-pager إذا ظهرت حالة failed، لا تعِد تشغيل الخادم. انتقل إلى السجل لمعرفة السبب.

2. اقرأ السجل الخاص بالإقلاع الحالي bash journalctl -u nginx -b -n 50 --no-pager إذا ظهر أن المنفذ 80 مستخدم، اكتشف العملية المنافسة: bash ss -ltnp | grep ':80' يجب أن ترى اسم البرنامج ورقم العملية التي تستمع على المنفذ.

3. اختبر إعداد الخدمة قبل تشغيلها bash nginx -t النتيجة الناجحة يجب أن تتضمن أن الصياغة صحيحة وأن الاختبار اكتمل بنجاح. إذا ذكر الملف رقم سطر، أصلح ذلك السطر بدل تعديل ملفات أخرى.

4. راجع صلاحيات ملف الإعداد bash ls -l /etc/nginx/nginx.conf namei -l /etc/nginx/nginx.conf يوضح namei صلاحيات كل دليل في المسار. قد يملك الملف أذونات صحيحة، لكن يمنع أحد الأدلة الوسيطة الوصول إليه.

5. افحص الذاكرة والعمليات bash free -h ps aux --sort=-%mem | head إذا اقتربت الذاكرة من الامتلاء، عالج العملية الأعلى استهلاكًا بعد فهم وظيفتها. لا تقتل عملية عشوائيًا، خصوصًا إذا كانت قاعدة بيانات أو خدمة تخزين.

6. أعد التشغيل وتحقق من النتيجة bash systemctl restart nginx systemctl is-active nginx يجب أن تعيد is-active القيمة active. اختبر المنفذ محليًا: bash curl -I http://127.0.0.1 ظهور استجابة HTTP يثبت أن الخدمة تستجيب محليًا، لكنه لا يثبت بعد سلامة الشبكة الخارجية.

قائمة فحص سريعة:

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

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

أخطاء شائعة تحتاج إلى انتباه

إعادة تشغيل الخادم بدل تحديد الخدمة المتوقفة

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

افعل هذا: افحص systemctl status وjournalctl، ثم أعد تشغيل الوحدة المتأثرة فقط.

لا تفعل هذا: لا تستخدم reboot كأول حل لمجرد أن الموقع لا يستجيب.

استخدام الإنهاء القسري لكل عملية عالقة

قد يؤدي kill -9 إلى فقدان بيانات لم تُكتب على القرص، خصوصًا مع الخدمات التي تستخدم قواعد بيانات أو ملفات سجلات.

افعل هذا: استخدم kill العادي، انتظر، ثم افحص السجل والموارد قبل التصعيد.

لا تفعل هذا: لا تقتل العملية الأعلى استهلاكًا للمعالج دون معرفة اسمها ووظيفتها.

منح صلاحيات واسعة لإصلاح خطأ وصول

قد يحل chmod -R 777 المشكلة لحظيًا، لكنه يسمح لكل مستخدم بالقراءة والكتابة والتنفيذ داخل المسار، وقد يفتح بابًا لتعديل ملفات الخدمة.

افعل هذا: حدّد المستخدم أو المجموعة المطلوبة، ثم استخدم chown أو قائمة تحكم بالوصول مثل setfacl بصلاحية دقيقة.

لا تفعل هذا: لا توسّع الصلاحيات على دليل كامل قبل معرفة الملف الذي يرفض الوصول وسبب الرفض.

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

End of chapter one. 4 more chapters and about 6,213 words in the full book.