غيّر الإصدار التجريبي من ZimaOS 1.7 طريقة تحرير عنوان الويب الخاص ببلاطة التطبيق: إذ كان بإمكان المستخدمين تغيير البروتوكول والمنفذ والمسار، بينما كان اسم المضيف مرتبطًا بعنوان لوحة تحكم ZimaOS. ولم يمنع ذلك Nginx Proxy Manager أو نظام DNS المحلي من تقديم نطاق مخصص بشكل مستقل.
أكد رد من فريق IceWhale في ذلك الوقت أن تحرير اسم المضيف لم يكن متاحًا في المحرر المرئي، وذكر أن الفريق يخطط لإعادته. يحسّن ZimaOS 1.7.1 الحالي إعدادات منافذ عناوين الويب في Docker ومعالجة عناوين URL، لكن سجل التغييرات المنشور لا يذكر صراحةً استعادة إمكانية تحرير أي اسم مضيف في النموذج المرئي.
ما الذي غيّره الإصدار التجريبي 1.7 فعليًا؟
كان لدى المستخدم إعداد محلي لنظام DNS ووكيل عكسي، مثل https://app.example.net/. وفي المحرر التجريبي، لم يعد بالإمكان إعداد بلاطة التطبيق نفسها لفتح اسم المضيف المخصص.
أظهرت إعادة إنتاج المشكلة من المجتمع أن ضبط x-casaos.hostname يدويًا قد يظل موجودًا في YAML، بينما يستمر النموذج وبلاطة التطبيق في استخدام عنوان IP الخاص بلوحة التحكم. ثم أكد موظفو IceWhale أن حقل اسم المضيف المرئي كان غير متاح مؤقتًا.
لا يزال بإمكان وكيلك العكسي استخدام النطاق المخصص
كان القيد الموضح في الموضوع يتعلق بعنوان URL الذي تفتحه بلاطة تطبيق ZimaOS، وليس بقدرة Nginx Proxy Manager أو AdGuard Home أو أي مجموعة أخرى من DNS والوكيل العكسي على توجيه اسم مضيف مخصص إلى منفذ التطبيق المنشور.
إذا كان وكيلك يوجّه نطاقًا بالفعل إلى عنوان IP الصحيح لـ ZimaOS ومنفذ التطبيق، فأبقِ مسار الوكيل منفصلًا عن إعداد بلاطة لوحة التحكم. يشرح دليل الوكيل العكسي لـ HTTPS في ZimaOS هذه البنية.
ما الذي يؤكده ZimaOS 1.7.1؟
يسرد سجل تغييرات ZimaOS 1.7.1 الرسمي إعدادًا أكثر مرونة لمنافذ عناوين الويب وتحسينات في معالجة عناوين URL الخاصة بـ Docker. لكنه لا يوثّق تحديدًا استعادة محرر اسم المضيف القديم.
يوثّق مرجع بيانات تطبيقات ZimaOS الحالي الحقول port_map وscheme وindex لعناوين URL الخاصة بالدخول إلى التطبيقات. اختبر المحرر المستقر الحالي قبل إعادة بناء إعداد وكيل قائم حول سلوك أقدم من الإصدار التجريبي.
هل تحتاج إلى الرجوع من الإصدار التجريبي؟
بالنسبة إلى هذه المشكلة تحديدًا، كانت نصيحة المنتدى هي عدم التسرع في التراجع، لأن النطاقات المخصصة نفسها ظلت تعمل عبر الوكيل العكسي. أما اليوم، فالخطوة الأولى الأفضل هي الانتقال إلى إصدار ZimaOS المستقر الحالي، ونسخ إعدادات التطبيقات احتياطيًا، والتحقق من سلوك بلاطات التطبيقات هناك.
إذا استوردت ملف YAML لتطبيق أو أصلحته، فإن دليل Docker Compose المخصص مرجع أكثر أمانًا من نسخ حل بديل من حقبة الإصدار التجريبي دون تغيير.
