قلت لحالي في مشروع صغير لبلّش فيه على أساس:
“يلا منعمل Debian ISO مرتب للمؤسسات”… 😄
وبعدها اكتشفت إنو الجملة هي لحالها بتفتح وراها أبواب:
Linux،
live-build،
Installer،
systemd،
سياسات أمنية،
صلاحيات،
SSH،
USB،
Networking،
Git،
إدارة Secrets،
اختبارات… وكل باب وراه بابين. 🐧
المشروع اسمه:
EDBP — Enterprise Debian Build Platform
وبصراحة؟ من أكتر المشاريع يلي تعبت فيها… ومن أكتر المشاريع يلي تعلمت منها بنفس الوقت.
أكيد ما اخترعت Debian من جديد 😅
بس لأول مرة تقريباً جمعت كمية كبيرة من الأشياء يلي كنت بتعلمها متفرقة، وحاولت حطها ضمن
نظام واحد قابل للبناء والتنفيذ فعلياً.
وطبعاً بما إنو نحنا بعصر الـAI، خليني كون واضح من البداية:
إي، استعنت بالذكاء الاصطناعي خلال التطوير.
استخدمته بالبحث، المراجعة، شرح أشياء ما كنت فاهمها منيح، التفكير بالمشاكل، ومساعدتي بحل شغلات استعصت علي.
وفي أجزاء بالمشروع كنت فاهمها منيح من قبل، أجزاء تعلمتها وأنا عم طبق، وفي تفاصيل أعمق لسا لليوم عم عمّق فهمي فيها.
وبرأيي هون كانت أحلى نقطة بالتجربة:
بدل ما يكون الـAI زر:
“اعمللي مشروع وبس بدون ما تخربط ”… 😅😅
صار أداة تخليني أسأل:
ليش هيك؟
شو صار تحت؟
ليش فشل؟
وليش هالحل أحسن من التاني؟
والنتيجة كانت كمية تعلم عملي ما كنت رح آخدها بنفس السرعة لو ضليت عم اقرأ نظري بس.
طيب شو هو EDBP أصلاً؟ 🤔
الفكرة أبسط من الاسم الطويل:
تخيل مؤسسة عندها عشرات أو مئات الأجهزة.
بدل ما كل مرة يجي فني على جهاز ويبلش:
نزّل هاد البرنامج…
غير هالإعداد…
طبق هالسياسة…
سكر هالخدمة…
افتح هي…
ولا تنسى الجهاز رقم 37 صار غير عن الجهاز رقم 12 😅
EDBP بيحاول يقلب المعادلة.
بدل ما تكون
السياسة موجودة براس الفني،
بتصير موجودة بالمصدر نفسه.
يعني المؤسسة بتحدد مرة:
شو النظام؟
شو البرامج؟
شو سياسات المستخدمين؟
شو الصلاحيات؟
شو إعدادات الأمان؟
شو الخدمات المسموحة؟
وشو شكل البيئة يلي بدها ياها؟
وبعدين من هالمصدر بتطلع ISO معيارية قابلة لإعادة البناء والنشر.
وهون الفرق بين:
“عملت Debian معدل”
وبين:
“بنيت Platform لتوحيد طريقة تجهيز أجهزة المؤسسة”.
المشروع حالياً مبني على
Debian 13 Trixie + KDE Plasma 6، والـISO نفسها فيها وضعين:
Live Environment لتجرب النظام والعتاد بدون تثبيت،
وDebian Installer للتثبيت الحقيقي على الجهاز.
وعند أول تشغيل بعد التثبيت، في OOBE بيجهز هوية الجهاز والمستخدم اليومي بدل ما تكون كل التفاصيل Hardcoded داخل الصورة.
ومن الأشياء يلي ركزت عليها كتير بالمشروع كانت فكرة:
المستخدم اليومي مو لازم يكون هو مدير الجهاز.
في فصل بين حساب المستخدم العادي وحساب الإدارة، مع Least Privilege،
وSSH للإدارة بالمفتاح العام بدل الاعتماد على Password Login عالـSSH. 🔐
وفي طبقة Security-by-Design فيها:
nftables
USBGuard
تعطيل Bluetooth حسب الـbaseline الحالي
سياسات SSH
وضبط صلاحيات وإعدادات النظام من المصدر نفسه.
وحتى الـSecrets نفسها ما بتنحط بالـGit بشكل عشوائي.
المشروع بيفصل المدخلات الحساسة عن المصدر المتتبع، وبيعمل Validation قبل البناء حتى ما تمر شغلات المفروض ما تمر.
بس أكتر شغلة بحبها بالفكرة كلها هي هي 👇👇👇
لو بكرا قررت المؤسسة:
“بدنا نغير Policy”
أو:
“ضيف البرنامج الفلاني”
أو:
“غير إعداد معين على كل الأجهزة”
المفروض ما يكون الحل:
“جيب الشباب ولفوا عالمكاتب جهاز جهاز” 😅
بتغير القرار بالمصدر،
بتراجعه،
بتوثقه بـGit،
وبتبني إصدار جديد.
يعني بصير عندك
Source واحد للقرار بدل 100 جهاز كل واحد عايش بقصة مختلفة.
وهذا تقريباً جوهر المشروع كله:
من تجهيز يدوي…
إلى معيار قابل للتكرار.
من:
“مين عدل هالإعداد؟”
إلى:
“أي Commit غير هالإعداد وليش؟”
من جهاز مضبوط…
إلى قدرة إنك
تعيد إنتاج نفس المنهج مرة تانية.
وفي نقطة مهمة كمان:
التثبيت على الجهاز الهدف مصمم حتى يتم من محتوى الـISO نفسها بدون الاعتماد على مستودعات APT خارجية أثناء عملية التثبيت.
يعني ببيئات الشبكات المقيدة أو المعزولة، الجهاز مو مضطر يطلع عالإنترنت مشان يكمل Installation.
البناء نفسه طبعاً ممكن يحتاج اتصال لجلب الحزم، هاي قصة تانية.
والمشروع مو مربوط بمؤسسة معينة.
هو Baseline مفتوح المصدر، أي جهة ممكن تاخده، تغير سياساتها وبرامجها وإعداداتها، وتطلع الصورة الخاصة فيها.
وهون كمان بتبين قابلية التوسع:
الفكرة نفسها بتشتغل سواء عندك عدد صغير من الأجهزة أو Fleet أكبر، لأن عدد الأجهزة ما عاد هو المكان يلي عم تخزن فيه قراراتك… القرارات صارت بالمصدر.
حتى بمنطق ال
SMART Goals، الهدف الهندسي نفسه واضح بشكل منيح:
Specific: توحيد بناء ونشر Workstations مبنية على Debian.
Measurable: في Build/Verification/Installation gates واضحة بتعرف من خلالها إذا الإصدار نجح أو فشل.
Achievable: المشروع مبني بأدوات موجودة ومعروفة ضمن Debian ecosystem.
Relevant: بيحل مشكلة فعلية بأي بيئة فيها تجهيز أجهزة متكرر وسياسات لازم تضل موحدة.
أما Time-bound، فهي مو صفة بالكود نفسه؛ بتتحدد حسب خطة نشر واعتماد كل مؤسسة.
يعني ما بدي نعمل من كلمة SMART ملصق ونلزقه عالمشروع 😂
إذا بدنا نحكيها، نحكيها بمعناها الحقيقي.
بس بنفس الوقت في شغلة ضروري تنقال:
EDBP
مو ISO سحرية أي مؤسسة بتنزلها هلق وبتروح بتفرمت فيها 500 جهاز 😅
هو Platform / Baseline.
قبل أي نشر فعلي، لازم الجهة نفسها تراجع:
سياسة الشبكة
الأمان
الأجهزة والطابعات والماسحات
سياسة التشفير
إدارة كلمات المرور
التحديثات
والاختبارات الفعلية على Hardware حقيقي.
حتى بالمشروع نفسه، وجود الـConfig والكود مو معناته إن الإصدار صار Golden Master تلقائياً؛ في Verification واختبارات واعتماد قبل هي المرحلة.
وفي نقطة تقنية صغيرة للأمانة:
المشروع بيعطيك
Repeatability قوية بالمصدر والسياسات وطريقة البناء، بس إذا بدنا نحكي عن Reproducible Build حرفياً Byte-for-byte عبر الزمن، فالمستودعات الخارجية المتغيرة بتحتاج Snapshot أو Internal Mirror مضبوط.
يعني حتى هون… ما بدنا نبيع مصطلحات أكبر من الواقع 😄
بالنسبة إلي، قيمة المشروع مو بس بالـISO يلي بتطلع بالنهاية.
القيمة الحقيقية كانت بالطريق:
كم مشكلة وقعت فيها،
كم مرة خربت شغلة ورجعت فهمت ليش خربت،
وكم مفهوم كنت بعرف اسمه بس… واضطريت أفهمه فعلياً مشان المشروع يمشي.
ولسا في أشياء بدي أتعلمها وأطورها فيه.
المشروع Open Source وموجود كامل على GitHub للي حابب يفصفصه، يراجع الفكرة، يستفيد منها أو حتى يبني عليها:
EDBP HERE
إذا حابين، بالبوست الجاي بفصفصلكم
كيف EDBP مبني من جوا:
كيف بتتحول ملفات وسياسات وHooks إلى ISO Debian قابلة للإقلاع والتثبيت فعلياً. 🐧
#تيكات #EDBP #Debian #Linux #OpenSource #وعي_تقني