أوصل إلى لينكس بالذكاء الاصطناعي: سلسلة من 4 أجزاء
الجزء الأول: اختيار التوزيعة → الجزء الثاني: التخزين والتشفير → الجزء الثالث: التثبيت اليدوي → الجزء الرابع: الخدمات ووحدة المعالجة الرسومية
إن سبق لك أن امتلأ قسم الجذر في الساعة الثالثة صباحاً وشاهدت نظامك يتوقف تماماً، فأنت تعرف بالفعل: التقسيم الافتراضي فخ. لكن تصميم تخطيط LVM مشفر مناسب لستة أحمال عمل مختلفة عبر ثلاثة أقراص فعلية؟ ذلك يستغرق يوماً كاملاً من التخطيط المنفرد، ومراجعة الوثائق، وحساب الأحجام، والتشكيك في نفسك طوال الوقت.
إليك كيفية الاستعانة بالذكاء الاصطناعي للقيام بالعمل الشاق في تصميم التخزين حتى لا تغرق في صفحات الدليل ليوم كامل. ستزوده بمتطلبات أحمال العمل، وستحصل في المقابل على بنية كاملة مع مبررات يمكنك فهمها فعلاً، وستنتهي وأنت تفهم كل طبقة مما تبنيه.
في الجزء الأول، اخترت توزيعتك ورسمت خريطة الأجهزة. الآن يأتي الجزء الذي يقبل فيه معظم الناس الإعدادات الافتراضية السيئة أو يستسلمون كلياً: تصميم التخزين.
ابدأ بأحمال العمل، لا بأحجام الأقسام
لديك خريطة أجهزتك من الجزء الأول: لنقل جهاز ThinkPad قديم مزود بمحرك NVMe وقرص SSD وقرص HDD. المواصفات تخبرك بما هو ممكن. لكن أحمال العمل تخبرك بما هو ضروري.
إليك الخطوة. لا تطلب من الذكاء الاصطناعي جدول أقسام. لا تحدد الأحجام. لا تقل "ضع /home في قسم منفصل." بدلاً من ذلك، صف السلوكيات والمتطلبات ودعه يستنتج البنية. شيء كهذا:
"سيُشغّل هذا الجهاز حاويات Docker وقاعدة بيانات PostgreSQL مع TimescaleDB وRedis وOllama للنماذج الذكية المحلية، وسيخزن مخرجات الهجمات من شبكة مصائد الاصطياد. كما يحتاج إلى مساحة عمل تحليلية مشفرة منفصلة عن نظام التشغيل، وتخزين أرشيف مشفر للأدلة طويلة الأمد. صمم أفضل استراتيجية للأقسام والتشفير للأقراص الثلاثة التي وجدناها."
لاحظ الفرق؟ أنت تسلّم القيود والأهداف، لا تتدخل في التفاصيل. إن كانت المبررات سليمة، كان التصميم كذلك. وإن لم يكن أحد الخيارات منطقياً، ستلاحظه لأنك تفهم ما يحتاج جهازك فعلاً أن يؤديه.
تصنيف أحمال العمل حسب سلوك القرص
أول ما يجب تحديده هو فصل أحمال العمل حسب نمط الإدخال والإخراج. ليس حسب الحجم، ولا حسب الأهمية، بل حسب كيفية تعامل كل حمل عمل مع القرص فعلياً.
المسارات الثلاثة
- عمليات IOPS عالية وزمن استجابة منخفض = NVMe. هنا يعيش نظام التشغيل وDocker وقواعد البيانات ونماذج الذكاء الاصطناعي. هذه الأحمال تُجري الكثير من القراءات والكتابات العشوائية الصغيرة. تحتاج إلى أسرع تخزين متاح.
- مساحة عمل سريعة ومعزولة = SSD. مساحة العمل التحليلية تذهب هنا. تحتاج إلى سرعة معقولة لمعالجة التقاطات وتشغيل الأدوات، لكن الأهم أن تكون منفصلة عن قرص نظام التشغيل. إن أفسد عمل التحليل نظام ملفات أو ملأ قرصاً، يستمر نظام التشغيل في العمل.
- سعة ضخمة وكتابة تسلسلية = HDD. تخزين أرشيف طويل الأمد لملفات pcap وصادرات الأدلة والنسخ الاحتياطية. أداء الكتابة التسلسلية كافٍ. السعة أهم من السرعة.
هذا الفصل وحده يمنع أكثر أنماط الفشل شيوعاً: حمل عمل واحد يجوّع الآخر من حيث الإدخال والإخراج أو المساحة.
لماذا تحصل كل خدمة على مجلدها المنطقي الخاص
لا تتوقف عند ثلاثة أقراص. على محرك NVMe، قسّم المساحة إلى ستة مجلدات منطقية منفصلة، كل منها لغرض محدد:
- /var/lib/docker يحصل على العزل لأن Docker يستهلك القرص بشكل غير متوقع. بناء حاوية جامح أو ذاكرة تخزين مؤقت للصور المنسية لا ينبغي أن تملأ قسم الجذر.
- /var/lib/postgresql يحصل على العزل لتحديد الحجم بشكل مستقل، وأخذ لقطات النسخ الاحتياطي، وضبط الأداء مستقبلاً. لقواعد البيانات أنماط إدخال وإخراج فريدة تستفيد من مساحة مخصصة.
- /var/lib/ollama يحصل على العزل لأن نماذج الذكاء الاصطناعي ضخمة وتنمو بشكل مستقل. نموذج LLM واحد قد يبلغ 8 جيجابايت أو أكثر. لا تريد أن تتنافس تنزيلات النماذج مع نظام التشغيل على المساحة.
- /home يحصل على العزل حتى تبقى بيانات المستخدم وملفات الإعداد والتكوينات الشخصية بعد إعادة بناء نظام التشغيل.
- swap كمجلد منطقي مستقل، بحجم يدعم الإسبات عند الحاجة.
- الجذر (/) محدود بحجم ثابت حتى لا يتمكن شيء خارج المسارات المخصصة من ملئه. إن امتلأ الجذر، يتوقف النظام عن العمل. تحديده بسقف هو تصميم دفاعي.
التشفير ليس اختيارياً
التشفير ليس اختيارياً هنا، والمبرر واضح. هذا جهاز محمول يعمل كـمحطة عمل أمنية وتخزن بيانات حساسة في حالة السكون: التقاطات مصائد الاصطياد، ومخرجات الهجمات، ونتائج تحليل الشبكة. إن سُرق الجهاز أو ضاع أو تم إيقافه عن الخدمة، يجب أن يكون كل قرص غير قابل للقراءة بدون عبارة المرور.
التشفير الكامل للقرص باستخدام LUKS هو الحد الأدنى لهذه الحالة. نقطة.
اترك مساحة احتياطية في مجموعة المجلدات
هذه التفصيلة تفرق بين تصميم LVM الجيد والعمل الهاوي. اترك نحو 5 إلى 10% من مجموعة المجلدات غير مخصصة. ليست مهدرة. محجوزة. إليك السبب:
مع LVM، يمكنك توسيع المجلدات المنطقية أثناء التشغيل دون إعادة تشغيل. إن احتاج Docker مساحة أكبر بعد ستة أشهر، تمدد المجلد المنطقي وتغيير حجم نظام الملفات في ثوانٍ. لو خصصت كل شيء مسبقاً، ستحتاج إلى تقليص مجلد لتوسيع آخر، والتقليص بطيء ومحفوف بالمخاطر وأحياناً مستحيل مع بعض أنظمة الملفات.
المساحة الاحتياطية المقصودة ميزة، لا هدر.
النموذج الذهني لطبقة التخزين
هذا النموذج الذهني هو أقيم شيء يمكن أخذه من هذا الفصل بأكمله. ليس أحجام الأقسام. ليس نقاط التوصيل. هذا المكدس المكون من 8 طبقات الذي يشرح كيف يعمل تخزين لينكس فعلياً، من الأعلى إلى الأسفل.
مكدس التخزين المكون من 8 طبقات
كل جزء من تخزينك يمر عبر هذه الط��قات، من الأعلى إلى الأسفل:
- القسم الخام: ما يُنشئه
fdiskأوgdiskعلى القرص الفعلي - التشفير (LUKS): يُغلف القسم الخام في حاوية مشفرة
- جهاز المعيّن: ما يظهر بعد فتح القفل:
/dev/mapper/cryptnvme - مجلد LVM الفعلي (PV): جهاز المعيّن المسجل كتخزين لـ LVM
- مجموعة المجلدات (VG): مجلد فعلي واحد أو أكثر مجمعة في مخزن واحد
- المجلد المنطقي (LV): شريحة من مجموعة المجلدات، بحجم محدد لغرض معين
- نظام الملفات: ext4 أو swap، مُهيأ على المجلد المنطقي
- نقطة التوصيل: حيث يظهر نظام الملفات في شجرة الدليل
حين يحدث عطل، يكون الحل دائماً تقريباً في طبقة واحدة محددة. إن لم تستطع تحديد الطبقة، ستضيع ساعات في استكشاف الأخطاء في المكان الخطأ.
معظم الأعطال التي ستواجهها أثناء التثبيت الفعلي، خاصة مع fstab وcryptab في الجزء الثالث، تنشأ من الخلط بين هذه الطبقات. كتابة UUID من الطبقة الثانية حيث كانت الطبقة السادسة مطلوبة. الإشارة إلى مسار جهاز من الطبقة الثالثة في إعداد يحتاج الطبقة الأولى. كل خطأ تخزين يعود إلى عدم تطابق الطبقات.
احفظ هذا المكدس. استوعبه جيداً. حين تستوعب هذه الطبقات الثماني، يتوقف تخزين لينكس عن كونه غامضاً. إنه مجرد ثمانية أشياء، كل منها يؤدي مهمة واحدة، متصلة بالترتيب.
التخطيط النهائي لمحرك NVMe
إليك التصميم الكامل لمحرك NVMe الأساسي:
محرك NVMe الأساسي (nvme0n1)
| القسم | الحجم | النوع | الغرض |
|---|---|---|---|
| nvme0n1p1 | 1 جيجابايت | نظام EFI (FAT32) | البرنامج الثابت للإقلاع |
| nvme0n1p2 | 2 جيجابايت | /boot (ext4) | النواة وinitramfs |
| nvme0n1p3 | المتبقي | مشفر بـ LUKS2 | كل شيء آخر |
داخل حاوية LUKS على nvme0n1p3:
nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (مجموعة المجلدات)
| المجلد المنطقي | الحجم | نظام الملفات | نقطة التوصيل |
|---|---|---|---|
| root | 120 جيجابايت | ext4 | / |
| swap | 24 جيجابايت | swap | [swap] |
| docker | 220 جيجابايت | ext4 | /var/lib/docker |
| ollama | 180 جيجابايت | ext4 | /var/lib/ollama |
| postgres | 120 جيجابايت | ext4 | /var/lib/postgresql |
| home | 200 جيجابايت | ext4 | /home |
| (حر) | ~65 جيجابايت | لا ينطبق | لا ينطبق |
الأقراص الثانوية
قرص SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis
قرص HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive
ثلاثة أقراص مشفرة. ستة مجلدات منطقية على القرص الأساسي. كل حمل عمل في مساره الخاص. لا شيء يشارك مساحة مع ما لا ينبغي له.
تحويل التصميم إلى سكريبت بناء
بمجرد الانتهاء من التصميم، تصبح الرسالة التالية بسيطة:
"أعطني الأوامر الدقيقة لبناء هذا التخطيط التخزيني بالكامل من بيئة Kali الحية. افترض أن الأقراص الثلاثة يمكن مسحها."
اطلب سكريبت شل كاملاً: مسح التوقيعات الموجودة، وإنشاء جداول أقسام GPT، وتقسيم الأقراص باستخدام sgdisk، وإنشاء حاويات LUKS2 بإعدادات افتراضية قوية، وفتحها، وتهيئة وحدات LVM المادية، وإنشاء مجموعة الأحجام، وتخصيص جميع الأحجام المنطقية الستة، وتهيئة كل شيء، ثم تكرار إعداد LUKS للـ SSD والـ HDD.
توقع ما يقارب 80 سطراً. يجب أن يكون كل أمر قابلاً للمراجعة. إذا لم يكن أي شيء في السكريبت منطقياً بالنسبة لك، اطلب من الذكاء الاصطناعي شرح ذلك السطر تحديداً قبل تشغيله.
ما الذي سيسوء (ولن يكون التصميم هو السبب)
تحذير عادل: سيكون التصميم متيناً. أما التنفيذ فسيقاومك. إليك الفخاخ التي يجب الانتباه إليها:
نهايات أسطر Windows. إذا كتبت السكريبت على جهاز Windows ونقلته إلى البيئة الحية عبر USB، فإن كل سطر ينتهي بـ \r\n بدلاً من \n. يتعثر Bash على كل أمر، وتكون رسائل الخطأ غامضة. أصلح ذلك ب�� sed -i 's/\r$//' script.sh قبل تشغيل أي شيء.
تلف السطر الأول. مرتبط بمشكلة نهايات الأسطر. يحصل السطر #!/bin/bash على إرجاع سطر غير مرئي، فلا يستطيع النواة إيجاد المفسر. يبدو الخطأ كأن السكريبت غير موجود رغم أنه موجود بوضوح.
الارتباك في المسارات. يُركَّب USB في مسار معين، لكنك تشير إلى السكريبت من دليل عمل مختلف. الإكمال التلقائي بالضغط على Tab والمسارات النسبية في بيئة حية غير موثوقة حين تتعامل مع نقاط تركيب متعددة. استخدم المسارات المطلقة.
صياغة التنفيذ الخاطئة. نسيان ./ قبل اسم السكريبت، أو عدم ضبط صلاحيات التنفيذ أولاً. أخطاء كلاسيكية لا علاقة لها بتصميم التخزين وكل العلاقة بذاكرة العضلات.
"يستطيع الذكاء الاصطناعي كتابة السكريبت، لكنك لا تزال بحاجة إلى فهم ما تلصقه. إذا لم يكن أمر ما منطقياً بالنسبة لك، توقف واسأل."
بمجرد حل مشكلات نهايات الأسطر والتنفيذ، يكتمل بناء التخزين في أقل من دقيقتين. تُفتح كل حاوية LUKS. تُنشأ كل بنية LVM بشكل نظيف. تُهيأ كل نظام ملفات. يصمد التصميم.
تحقق من كل شيء بنمط اللصق والفحص
لا تفترض النجاح. بعد انتهاء السكريبت، الصق مخرجات طرفيتك إلى الذكاء الاصطناعي واطلب منه مراجعة النتيجة:
"هذا مخرج
lsblkوlvsلديّ. هل بُني كل شيء بشكل صحيح؟"
الصق مخرجات الطرفية الخام واطلب من الذكاء الاصطناعي المرور عليها سطراً بسطر. يجب أن يؤكد: cryptnvme نشط، vgkali موجود مع ستة أحجام منطقية بالأحجام الصحيحة، وأنظمة الملفات الصحيحة على كل منها، والأقراص الثانوية مشفرة ومهيأة.
يُعد نمط اللصق والتحقق هذا من أكثر التقنيات فائدة لإدارة الأنظمة مع الذكاء الاصطناعي. تشغّل أمراً، تلصق المخرجات، وتسأل إذا كان الواقع يطابق الخطة. يكتشف مشكلات كنت ستفوتها لأنك قريب جداً من العمل:
- حجم منطقي هُيئ عن طريق الخطأ بنوع نظام ملفات خاطئ
- حجم قُدِّر بالميغابايت بينما كنت تقصد الغيغابايت
- قسم مفقود تخطاه السكريبت بصمت
- حاوية LUKS لم تُفتح فعلياً
يمكنك فعل ذلك مع أي حالة نظام تقريباً: lsblk، lvs، pvs، vgs، blkid، fdisk -l، cryptsetup status. الصقها. اطلب من الذكاء الاصطناعي مراجعتها. إنه أسرع وأكثر شمولاً من فحص كل شيء بنفسك.
الخلاصة: صمم انطلاقاً من أعباء العمل لا من الإعدادات الافتراضية
لم يُختر تخطيط التخزين هنا من قالب جاهز أو نُسخ من منشور في منتدى. بل اشتُق من متطلبات أعباء العمل الفعلية. يحتاج Docker إلى عزل المساحة. تحتاج قواعد البيانات إلى إدخال/إخراج مخصص. تحتاج نماذج الذكاء الاصطناعي إلى مساحة للنمو. تحتاج الأدوات الأمنية إلى تشفير في حالة السكون. تحتاج الأرشيفات إلى سعة تفوق السرعة.
كل قرار يعود إلى متطلب حقيقي. هذا هو الفرق بين تخطيط تخزيني يصمد ستة أشهر وآخر ينهار عند أول حدث غير متوقع.
يعمل هذا النهج مع أي بناء، ليس فقط محطات العمل الأمنية. أخبر الذكاء الاصطناعي بما سيـفعله الجهاز. صف الخدمات، وأنماط البيانات، وتوقعات النمو، وسيناريوهات الفشل التي تريد النجاة منها. ثم دعه يكتشف كيفية تنظيم الأقراص. المنطق الذي يعرضه عليك أكثر قيمة من جدول الأقسام النهائي، لأنك ستفهم لماذا اتُّخذ كل قرار ومتى قد يحتاج إلى التغيير.
أقراصك مقسمة ومشفرة ومنحوتة في أحجام منطقية. البنية المعمارية جاهزة. الآن يأتي الجزء الذي يُربك الناس فعلاً: تثبيت نظام تشغيل فوق كل هذا دون مثبت رسومي يمسك بيدك.
في الجزء الثالث: التثبيت اليدوي، ستركّب الأحجام المشفرة، وتُحمّل Kali من الصفر، وتربط fstab وcrypttab لكي يُفتح كل شيء عند الإقلاع، وتبني إعداد محمّل إقلاع يعمل. هنا يُختبر النموذج ذو الثماني طبقات بجدية، وحيث يمكن لـ UUID واحد خاطئ أن يتركك تحدق في موجه إنقاذ GRUB. أحضر قهوتك.
