التثبيت

يتم توفير Condensa كـ ملف تنفيذي مدمج مفرد: واجهة المستخدم عبر الويب مدمجة، وقاعدة البيانات هي SQLite، وتتم التهيئة من خلال متغيرات البيئة. نظام Kubernetes ليس مطلباً — بل يتم استخدامه فقط عندما يكون هدف الترحيل هو Awanio CEP.

المتطلبات

• خادم Linux x86_64 (يمكن استخدام جهاز افتراضي)
• وصول عبر الشبكة من خادم Condensa إلى:
  • VMware vCenter/ESXi (المنفذ 443)
  • هدف الترحيل — واجهة برمجية لـ Awanio Cockpit أو Vapor (انظر Integration)
• مساحة قرص للمراحل الانتقالية (تستخدم فقط للنسخ الاحتياطي المرحلي وتحميلات OVA/VHD): قم بضبط حجم دليل المراحل الانتقالية ليستوعب أكبر قرص تخطط لترحيله

اعتماديات مسار البيانات

ينقل Condensa بيانات الأقراص عبر أحد مسارين، ولكل منهما متطلب خاص به. يتم اختيار المحرك تلقائياً لكل عملية ترحيل، لذا من المفيد معرفة أي مسار ستستخدمه بيئتك قبل بدء عملية نقل كبيرة.

مسار البيانات	تدفق البيانات	الترحيل الساخن (Warm)	المتطلب
VDDK المباشر (المفضّل)	ESXi ← الخادم الهدف	مدعوم	على خادم Vapor الهدف: nbdkit مع إضافة VDDK، ومكتبة VDDK من VMware، بالإضافة إلى qemu-nbd و nbdfuse
المرحلي (Staged) (احتياطي، لأهداف Cockpit فقط)	ESXi ← Condensa ← الهدف	غير مدعوم	على خادم Condensa: qemu-img (الحزمة qemu-utils)

على الخادم الهدف (Vapor): VDDK

بدونه يتعذّر الترحيل الساخن، وتعود كل عمليات الترحيل إلى المسار المرحلي. قم بتثبيته من واجهة Vapor (System ← Third-party libraries) أو عبر دور Ansible، ثم تأكد من أن الشارة تعرض installed. يوضّح سجل الترحيل المحرك الذي تم اختياره:

Target host supports VDDK; using direct VDDK pull

أما إذا ظهرت الرسالة Target host has no VDDK (nbdkit not found) فهذا يعني أن المسار المرحلي هو المستخدم.

على خادم Condensa: qemu-img

يقوم المسار المرحلي بتحويل كل قرص مُصدَّر إلى صيغة qcow2 داخل Condensa نفسه، لذلك يجب توفّر qemu-img هناك:

sudo apt-get install -y qemu-utils     # Debian/Ubuntu
sudo dnf install -y qemu-img           # RHEL/Rocky

يرفض Condensa بدء ترحيل مرحلي بدونه بدلاً من الفشل في منتصف عملية التصدير. أما الجهاز الافتراضي (appliance) فيأتي به مثبتاً مسبقاً.

فضّل VDDK على الخادم الهدف

ينسخ المسار المرحلي كل بايت مرتين (المصدر ← Condensa ← الهدف) ويحتاج مساحة مرحلية بحجم أكبر قرص. تثبيت VDDK على الهدف يلغي هاتين التكلفتين ويتيح الترحيل الساخن — ويستحق القيام به قبل ترحيل أي أحمال كبيرة.

إمكانية الوصول للمسار المرحلي

عند استخدام المسار المرحلي، يقوم الهدف بتنزيل القرص المُجهَّز من Condensa عبر CONDENSA_PUBLIC_URL. يجب أن يكون هذا العنوان قابلاً للوصول من الخادم الهدف، لا من متصفحك فقط: أي عنوان على شبكة خاصة أو خلف NAT لا يستطيع الهدف توجيه الطلبات إليه سيفشل عند خطوة التنزيل.

1. تثبيت الملف التنفيذي

sudo install -m 0755 condensa-server /usr/local/bin/condensa-server
sudo mkdir -p /var/lib/condensa/staging /var/log/condensa /etc/condensa

2. إنشاء مفتاح التشفير

تخزن بيانات اعتماد المزود (كلمات مرور vCenter، رموز الواجهة البرمجية API) مشفرة بتشفير AES-256-GCM. يتم إنشاء المفتاح مرة واحدة وتحتفظ به — تسريب قاعدة البيانات لا يؤدي إلى تسريب بيانات اعتماد البنية التحتية.

condensa-server -generate-key

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

openssl rand -base64 48

احفظ كلاهما في /etc/condensa/condensa.env:

sudo tee /etc/condensa/condensa.env <<'EOF'
CONDENSA_ENCRYPTION_KEY=<generated-encryption-key>
JWT_SECRET=<generated-jwt-secret>
EOF
sudo chmod 600 /etc/condensa/condensa.env

الحفاظ على أمان المفتاح

فقدان CONDENSA_ENCRYPTION_KEY يعني ضرورة إعادة إدخال جميع بيانات اعتماد المزودين. قم بإعداد نسخة احتياطية للملف إلى جانب أسرارك الأخرى.

3. إنشاء وحدة systemd

/etc/systemd/system/condensa.service:

[Unit]
Description=Condensa VM migration server
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/condensa-server
Environment=PORT=8080
Environment=DB_PATH=/var/lib/condensa/condensa.db
Environment=CONDENSA_UPLOAD_DIR=/var/lib/condensa/staging
Environment=CONDENSA_LOG_FILE=/var/log/condensa/condensa.log
Environment=CONDENSA_PUBLIC_URL=http://condensa.example.com:8080
# condensa.env holds CONDENSA_ENCRYPTION_KEY and JWT_SECRET (chmod 600)
EnvironmentFile=/etc/condensa/condensa.env
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now condensa

متغيرات البيئة

المتغير	مطلوب	الغرض
CONDENSA_ENCRYPTION_KEY	نعم	مفتاح AES-256 لبيانات اعتماد المزود أثناء السكون (-generate-key)
JWT_SECRET	نعم	مفتاح التوقيع لرموز المصادقة (≥32 بايت، مثل openssl rand -base64 48)؛ يرفض الخادم البدء بدونه
PORT	لا (الافتراضي 8080)	منفذ الاستماع HTTP
DB_PATH	لا	مسار ملف قاعدة بيانات SQLite
CONDENSA_PUBLIC_URL	للنقل المرحلي / OVA	عنوان URL الذي تستخدمه الأهداف للوصول إلى نقطة نهاية تدفق الأقراص في Condensa
CONDENSA_UPLOAD_DIR	للنقل المرحلي / OVA	دليل التخزين المرحلي — اضبط حجمه لأكبر قرص مرحلي
CONDENSA_LOG_FILE	موصى به	يُمكّن صفحة السجلات (Logs) في واجهة المستخدم
CONDENSA_ADMIN_USERNAME / CONDENSA_ADMIN_PASSWORD	لا	تهيئة المسؤول الأول بشكل غير تفاعلي (للأتمتة)
CONDENSA_TLS	مُستحسن	off أو self-signed أو on — انظر HTTPS
CONDENSA_TLS_CERT / CONDENSA_TLS_KEY	مع CONDENSA_TLS=on	سلسلة شهادة PEM والمفتاح الخاص
CONDENSA_TLS_HOSTS	لا	أسماء/عناوين إضافية تغطيها الشهادة الموقّعة ذاتياً
CONDENSA_UPDATE_URL	للتحديث في المكان	خلاصة تحديثات موقّعة — انظر التحديث
CONDENSA_UPDATE_PUBLIC_KEY	مع CONDENSA_UPDATE_URL	مفتاح Ed25519 للتحقق من الخلاصة

HTTPS

يرسل نموذج تسجيل الدخول كلمة مرور، وكل طلب لاحق يحمل رمز جلسة، لذا قدّم لوحة التحكم عبر TLS. هناك ثلاثة أوضاع:

CONDENSA_TLS	السلوك
off (افتراضي)	HTTP عادي. استخدمه فقط عندما ينهي وكيل عكسي أمامه اتصال TLS.
self-signed	يُصدر Condensa شهادته الخاصة ويجدّدها تلقائياً.
on	يستخدم CONDENSA_TLS_CERT وCONDENSA_TLS_KEY.

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

الشهادات الموقّعة ذاتياً

معظم عمليات التثبيت يجري الوصول إليها عبر عنوان IP على شبكة خاصة، حيث لا توجد جهة إصدار شهادات يمكنها إصدار أي شيء:

CONDENSA_TLS=self-signed

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

لإضافة أسماء غير مشتقة من الواجهات:

CONDENSA_TLS_HOSTS=condensa.internal.example.com,10.20.0.5

شهادات توفّرها بنفسك

CONDENSA_TLS=on
CONDENSA_TLS_CERT=/etc/condensa/tls/fullchain.pem
CONDENSA_TLS_KEY=/etc/condensa/tls/privkey.pem

يجب أن يتمكن مستخدم الخدمة من قراءة الملفين.

عمليات النقل التي تسحب من Condensa

ثلاثة مسارات للترحيل تجعل الهدف يُنزّل بيانات الأقراص من Condensa عبر CONDENSA_PUBLIC_URL: المسار المرحلي لمصدر VMware بدون VDDK، ومسار الأنبوب لمصدر Proxmox الذي لا تستطيع عقدته الوصول إلى الهدف مباشرة، وAwanio CEP (CDI). هذه المُنزِّلات تتحقق من الشهادات، لذا تُرفض الشهادة الموقّعة ذاتياً — يفشل النقل على الهدف بعد دقائق من التصدير، مع ظهور x509: certificate signed by unknown authority في سجل مضيف الهدف.

غير المتأثرة: ترحيلات VDDK المباشرة (الافتراضية لأهداف Cockpit وVapor)، والتحويل على عقدة Proxmox، وجميع الترحيلات الدافئة — لا شيء منها يسحب من Condensa.

طريقتان لاجتياز التحقق:

• استخدم شهادة موقّعة من جهة إصدار (CONDENSA_TLS=on). هذه هي الطريقة المدعومة لأهداف CEP.

• وثّق الشهادة الموقّعة ذاتياً على كل مضيف هدف. يخزّنها Condensa بجوار قاعدة البيانات، في tls/server.crt داخل دليل البيانات. على مضيف Vapor أو Cockpit:

  sudo cp server.crt /usr/local/share/ca-certificates/condensa.crt
  sudo update-ca-certificates
  sudo systemctl restart vapor

  ثم تأكد من ذلك المضيف أن التحقق يمر — بدون -k:

  curl https://<condensa>:8080/condensa/api/v1/health

  كرّر ذلك عند إعادة إصدار الشهادة (تتجدد تلقائياً قرب انتهاء صلاحيتها، وعند حصول مضيف Condensa على عنوان جديد).

تذكّر ضبط CONDENSA_PUBLIC_URL على عنوان https:// عند تفعيل TLS.

4. التشغيل الأول

افتح http://<server>:8080. في قاعدة البيانات الجديدة، يعرض Condensa معالج الإعداد (setup wizard) الذي ينشئ حساب المسؤول الأول ويسجل دخولك. بالنسبة للنشر المؤتمت عبر النصوص البرمجية، اضبط CONDENSA_ADMIN_USERNAME و CONDENSA_ADMIN_PASSWORD بدلاً من ذلك — سيتم إنشاء المسؤول عند بدء التشغيل.

بعد الإعداد:

• أنشئ حسابات إضافية تحت Users (خاص بالمسؤولين فقط). دور member هو دور مشغل: يمكنه عرض المزودين وإنشاء عمليات الترحيل وبدئها وإلغائها، بينما تظل إدارة المزودين والحذف وإدارة المستخدمين وسجل التدقيق مقتصرة على المسؤولين فقط.
• يتم تسجيل كل إجراء متعلق بالأمان (تسجيلات الدخول والإخفاقات، تغييرات المستخدمين والمزودين، ودورة حياة الترحيل) في علامة تبويب Audit Log.

5. ربط المزودين

تابع مع Integration لتسجيل مصدر VMware وهدف Awanio Cockpit أو Vapor.

التحديث

لا يمسّ التحديث /var/lib/condensa ولا /etc/condensa، لذا تبقى مزوداتك وبيانات اعتمادها المشفّرة وسجل الترحيل والمستخدمون والمفتاحان السريان كما هي. لا تُعيد ضبط أي شيء.

من لوحة التحكم

عند نشر إصدار أحدث، يرى المسؤولون إشعاراً بزر Install update. يُنزّل Condensa الإصدار ويتحقق منه ويثبّته ثم يُعيد التشغيل — بضع ثوانٍ من التوقف. يرفض الزر العمل أثناء وجود ترحيل جارٍ، لأن إعادة التشغيل ستُلغيه.

عمليات التثبيت المُنشأة بإصدار Condensa 1.1.8 أو أحدث مضبوطة مسبقاً للتحقق من بوابة المؤسسة — بلا مفاتيح وبلا أي إعداد. المصدر سطر واحد في /etc/condensa/condensa.env، وإفراغه يُعطّل فحص التحديثات:

CONDENSA_UPDATE_URL=https://enterprise.awan.io/api/v1/products/condensa/releases/latest

عمليات التثبيت الأقدم من 1.1.8 تكتسب السلوك نفسه بعد ترقية يدوية واحدة؛ ويمكن أيضاً إضافة السطر أعلاه يدوياً.

من سطر الأوامر

sudo condensa update --check    # اعرض المتاح دون تغيير شيء
sudo condensa update            # ثبّت أحدث إصدار وأعد التشغيل
sudo condensa update --to 1.1.7 # ثبّت إصداراً محدداً

أضف --force للتحديث أثناء وجود ترحيل جارٍ — سيُقطع ذلك الترحيل ويفشل.

ما يتحقق منه المُحدِّث

قبل أن يحلّ أي شيء محل الملف التنفيذي العامل حالياً:

1. يجب أن يأتي الإصدار من مصدر موثوق — TLS إلى البوابة المضبوطة، أو، لخلاصات البيئات المعزولة، توقيع Ed25519 يتحقق بمفاتيحك المضبوطة؛
2. يجب أن يطابق SHA-256 للملف المُنزَّل ما تنشره الخلاصة؛
3. يجب أن يعمل الملف المُنزَّل ويُبلّغ عن الإصدار الموعود — وهذا يكشف تنزيلاً مبتوراً أو بمعمارية خاطئة كان سيترك الخدمة عاجزة عن الإقلاع؛
4. ألا يكون هناك ترحيل جارٍ، ما لم يُفرض ذلك.

يُحتفظ بالملف التنفيذي المُستبدَل باسم condensa.previous، فالتراجع نسخٌ وإعادة تشغيل.

استبدال الملف التنفيذي يدوياً

ما زال مدعوماً — تُنفَّذ ترقيات قاعدة البيانات عند الإقلاع:

sudo install -m 0755 condensa /usr/local/bin/condensa
sudo systemctl restart condensa

التثبيت في البيئات المعزولة (air-gapped)

المضيفون الذين لا يصلون إلى بوابة المؤسسة يظل بإمكانهم التحديث في المكان بطريقتين.

يدوياً (الأبسط): أدخل حزمة الإصدار عبر قناة النقل المضبوطة لديك، وطابق SHA-256 مع القيمة الظاهرة في صفحة الإصدار بالبوابة، ثم:

tar -xzf condensa-<version>-linux-amd64.tar.gz
sudo ./condensa install

تحافظ الترقية على قاعدة البيانات والمزودات وبيانات الاعتماد والإعدادات.

تلقائياً من مرآة داخلية: توفّر Awanio ضمن التسليم خلاصة موقّعة (updates.signed.json) والمفاتيح العامة للتحقق منها. استضف الخلاصة وحزم الإصدارات على خادم https داخلي، ثم اضبط كل تثبيت:

CONDENSA_UPDATE_URL=https://releases.internal.example.com/condensa/updates.signed.json
CONDENSA_UPDATE_PUBLIC_KEY=<المفتاح A>,<المفتاح B>

إذا كانت شهادة المرآة من جهة إصدار داخلية، أضِف تلك الجهة إلى مخزن الثقة في نظام كل مضيف Condensa. الخلاصة موقّعة بـ Ed25519، لذا لا يمكن لمرآة مخترقة تغيير ما تقبله عمليات التثبيت؛ وتبقى بقية فحوصات المُحدِّث سارية دون تغيير.