التثبيتات غير المراقبة

يمكن لـ OmarOS ISO أن يثبّت نفسه مع عدم وجود أحد على لوحة المفاتيح. إذا وجد المثبّت محركًا ثانيًا مُسمّى cidata يحمل ملفات التكوين الخاصة به، فإنه ينسخها، ويتخطى معالج الإعداد بالكامل، ويعيد التشغيل إلى النظام النهائي من تلقاء نفسه. لا يوجد بناء ISO خاص، ولا إدخال قائمة إقلاع إضافي — من دون إرفاق مثل هذا المحرك، لا يتغير شيء وتحصل على المعالج العادي.

يجعل هذا OmarOS رائعًا كصورة أساسية لبيئات تطوير قابلة للتصرف: أنشئ VM في Proxmox أو باستخدام Packer، واقلعه، وابتعد، وادخل SSH. إن cidata هو تسمية cloud-init NoCloud، لذا فإن جميع أدوات الافتراضية الشائعة تعرف بالفعل كيفية إرفاق مثل هذا المحرك.

ملفات التكوين

الملفات هي بالضبط ما يكتبه معالج المثبّت الخاص به، لذا فإن أسهل طريقة للحصول على مجموعة بداية هي تشغيل تثبيت تفاعلي واحد (في VM، على سبيل المثال) ونسخ ما كتبه في /root:

الملف	مطلوب	الغرض
user_configuration.json	نعم	القرص، اسم المضيف، المنطقة الزمنية، لوحة المفاتيح
user_credentials.json	نعم	اسم المستخدم وتجزئة كلمة المرور
user_full_name.txt	لا	الاسم الكامل لـ Git
user_email_address.txt	لا	بريد Git
user_encrypt_installation.txt	لا	true عندما يحمل التكوين كتلة disk_encryption
authorized_keys	لا	مفاتيح SSH العامة، واحدة في كل سطر
tailscale_authkey	لا	مفتاح مصادقة Tailscale للانضمام إلى tailnet الخاص بك عند الإقلاع الأول

أنشئ تجزئة كلمة المرور لـ user_credentials.json باستخدام openssl passwd -6 "yourpassword".

يمكنك أيضًا إسقاط ملف فارغ اسمه defer-provisioning بدلًا من user_credentials.json. يشغّل ذلك نفس تثبيت الإعداد لمالك آخر الذي يمكنك تشغيله بشكل تفاعلي: يثبّت الجهاز من دون تفاصيل شخصية، ومن يقلعه أولًا يختار لوحة مفاتيحه ويُنشئ مستخدمه. هذا هو الوضع لأجهزة التصوير، حيث لا ينبغي أن يحمل محرك الأقراص بيانات اعتماد أي شخص على الإطلاق.

الوصول عبر SSH

عندما يكون authorized_keys موجودًا، يُعد التثبيت المفاتيح كـ ~/.ssh/authorized_keys للمستخدم، ويُفعّل sshd، ويفتح جدار الحماية له. (يأتي تثبيت OmarOS الجاهز مع openssh مع تعطيل الخدمة وإغلاق المنفذ، لذا سيكون الجهاز غير المراقب غير قابل للوصول بخلاف ذلك). يضيف التثبيت مفاتيحك فقط — ولا يخفف أيًا من إعدادات مصادقة خدمة SSH الأخرى.

عندما يكون tailscale_authkey موجودًا، ينضم الجهاز إلى tailnet الخاص بك عند الإقلاع الأول بدلًا من ذلك: يُثبّت Tailscale من الحزم المجمعة في ISO، ويسمح جدار الحماية بواجهة tailnet، ويشغّل عمل في الخلفية الانضمام بمجرد أن يكون الجهاز لديه شبكة فعلًا، ويعيد المحاولة حتى تنجح. استخدم مفتاحًا قابلًا لإعادة الاستخدام ومصرّحًا به مسبقًا حتى تتمكن صورة محرك واحدة من خدمة العديد من الأجهزة.

بناء محرك cidata

يعمل أي نظام ملفات بالتسمية الصحيحة. ISO صغير هو الطريقة السهلة:

mkdir cidata
cp user_configuration.json user_credentials.json authorized_keys cidata/
genisoimage -output cidata.iso -volid cidata -joliet -rock cidata/

ثم أرفقه بجهاز VM إلى جانب OmarOS ISO. إليك مثال Proxmox كامل:

qm create 101 --name my-omaros \
  --bios ovmf --machine q35 --cpu host --cores 4 --memory 8192 \
  --ostype l26 --scsihw virtio-scsi-single \
  --efidisk0 local-lvm:0,efitype=4m,pre-enrolled-keys=0 \
  --scsi0 local-lvm:40,discard=on,iothread=1 \
  --net0 virtio,bridge=vmbr0 --vga virtio --serial0 socket \
  --ide2 local:iso/omaros.iso,media=cdrom \
  --ide3 local:iso/cidata.iso,media=cdrom \
  --boot order='scsi0;ide2'

qm start 101

يسرد ترتيب الإقلاع القرص أولًا عن قصد: يسقط القرص الفارغ إلى ISO في الإقلاع الأول، ويقلع النظام المثبّت من القرص بعد ذلك دائمًا.

تحذيران

التثبيتات غير المراقبة المشفّرة ليست غير مراقبة بالكامل — لا يزال يتعين على شخص ما كتابة عبارة مرور LUKS في الإقلاع الأول. وتحمل كتلة disk_encryption في user_configuration.json عبارة المرور تلك بنص عادي، لذا تعامل مع محرك cidata المبني من تثبيت مشفّر كالسر الذي هو عليه.