Ansible.posix: [mount] القدرة على تحميل نظام ملفات مؤقتًا دون تغيير / etc / fstab

ناقشت حالة استخدام إضافية في القضايا والمستفيدين الرئيسيين فتحت سابقا ( 2571 ، 19820 ، 48134 ) خلال 5 سنوات الماضية، واحدة وأنا التي تواجه في الوقت الراهن، هو الحاجة إلى جبل مؤقتا الملفات التي تم تكوينها بالفعل في fstab. تتطلب الحالة المثبتة حاليًا توفير 'src' ، وهو أمر معقول إذا كان تحديث fstab مطلوبًا ، ولكن يجب أن يكون اختياريًا إذا كان الإدخال الصحيح موجودًا بالفعل في fstab.

على سبيل المثال ، إذا كنت بحاجة إلى إضافة أنظمة ملفات إلى خادم وترحيل المحتوى الحالي دون تغيير تخطيط الدليل ، فقد يكون لدي كتاب تشغيل يقوم بإنشاء أنظمة الملفات ونقاط التثبيت في حالتها النهائية المطلوبة ولكن لم يقم بتركيبها بعد. ثم قد يكون لدي كتاب تشغيل لتركيبها في مكان مؤقت ، وترحيل المحتوى الحالي إلى أنظمة الملفات الجديدة ، ثم إلغاء تحميل المؤقتات وإعادة تحميلها في موقعها الجديد الدائم.

راجع https://github.com/ansible-collections/ansible.posix/issues/107.

سيكون من الواضح على الأرجح فصل التكوين وحالة التشغيل ، وتقسيمهما إلى معلمتين للوحدة ، بنفس الطريقة التي يتم بها للوحدات النمطية service أو systemd ، مع state إلى وصف حالة التشغيل المطلوبة للخدمة (بدء / إيقاف / إعادة تشغيل) ، و enabled لوصف الحالة المستمرة المطلوبة للخدمة: ممكّنة عند التمهيد أم لا.

يمكن إدارة عمليات التحميل بنفس الطريقة ، مع (مطلوب واحد على الأقل من هذه المعلمات):

    state: mounted/unmounted/remounted
    enabled: yes/no  # configured in fstab, or not

بالنسبة لي ، الخيارات الحالية للخيار state ليست واضحة: الاختلافات بين present و absent و mounted و unmounted أحتاج إلى قراءة المستندات كثيرًا. present ليس عكس absent ، و unmounted ليس عكس mounted . ومع هذه الحالات الأربع ، لا يمكننا حتى الحصول على تثبيت نشط دون تعديل fstab.

لذلك أوافق على أن الوحدة تحتاج إلى بعض المعلمات المنطقية للتعامل مع fstab ، لكنني أعتقد أن enabled سيكون أكثر اتساقًا من modify_fstab ، ويجب إعادة هيكلة الخيار state في نفس الوقت (لعدم عمل أشياء معقدة مثل " enabled يتم تجاهلها عند state=absent أو state=mounted (أو sate=present أيضًا ، ربما)").

لا ترى حقًا سبب إغلاق الإصدار السابق ، يبدو أنه كان هناك مناقشة جيدة. لا تبدو حجة الفريق الأساسي التي تقول أن هذا يعني أن الوحدة النمطية "mount" بها الكثير من الخيارات حجة مقنعة جدًا نظرًا لوحدات مثل ansible.builtin.file .

جزء من مشكلة الخيار state لهذه الوحدة هو أن اثنتين من قيمها تصف (أو تؤدي إلى) نفس الحالة ، لكنهما يعتمدان على الحالة الأولية.

• عند البدء من state=absent (وهو عكس state=mounted ) ، مع state=present ، يتم تكوين fstab ولكن لم يتم تثبيت الحامل بالفعل.
• عند البدء من state=mounted ، مع state=unmounted ، لا يتم تثبيت التحميل ولكن يتم ترك fstab مهيئًا ، وهذا قريب جدًا من النتيجة السابقة.

ولكن عند القيام بالشيء نفسه من state=absent إلى state=unmounted ، أو من state=mounted إلى state=present ، لا يحدث شيء ، هذا يعني في هذه الحالات state=unmounted ويؤدي state=present إلى نتائج معاكسة (نظرًا لأن absent هو عكس mounted ، ولم يتغير شيء).

يوضح هذا بالنسبة لي أن هناك شيئين يجب التحكم فيهما بشكل منفصل: حالة التحميل الحالية ، دون القلق بشأن محتويات fstab (كما يفعل state=unmounted )؛ ومحتويات fstab ، دون القلق بشأن حالة التحميل الحالية (كما هو الحال مع state=present ). ربما تكون قيم state ( state=active ؟) كافية لتغطية الحاجة إلى تركيب جهاز بدون تعديل fstab ، لكن قيم state مربكة بما فيه الكفاية في رأيي.

من ناحية أخرى ، قد يكون الانتقال إلى تقسيم خيار إلى خيارين عن طريق الاحتفاظ باسمه في المجموعة الجديدة أمرًا مربكًا أيضًا ، وربما يحتاج إلى مزيد من العمل (خطوة الإيقاف ، إلخ). على أي حال ، يبدو أنه هدف أفضل. هذا من شأنه أن يهاجر بهذه الطريقة:

• قديم state=present -> جديد enabled=yes + state=None
• قديم state=mounted -> جديد enabled=yes + state=mounted
• قديم state=unmounted -> جديد enabled=None + state=unmounted
• old state=absent -> new enabled=no + state=unmounted (أو احتفظ بـ state=absent لإزالة نقطة التثبيت؟)

أفكار أخرى ؟

سأكون على ما يرام مع اقتراح quidame إذا كان هذا هو الحل الأسهل غير

من أجل الاتساق مع الخدمة / systemd ، على أية حال ، أنا شخصياً أفضل أن يكون لدي هدف نهائي وهو:

• state=present تعني "_mounted_" ، state=absent تعني "_unmounted_"
• انخفض state=remounted لصالح خيار force (أو ربما force_mount )
• enabled=yes تعني "_present in fstab_" ، enabled=no تعني "_غير موجود في fstab_"

شيء من هذا القبيل:

• enabled: [ yes | no ] - يتطلب src ، path ، fstype . يضمن تكوين fstab بشكل مناسب للتركيب المطلوب.
• force: [ yes | no ] - يتطلب state .
  
  
  
  • إذا كان state=present ، يعادل السلوك الحالي state=remounted
  
  
  • إذا كان state=absent ، ما يعادل umount -f <path>
  
  
• state: [ present | absent ] - يتطلب path . لم يعد خيارًا مطلوبًا إذا تم تعريف enabled .
  
  
  
  • إذا لم يتم تعريف present و src و fstype ، ما يعادل mount <path> (والذي سينجح فقط إذا كان الإدخال موجودًا بالفعل في fstab) ، ما يعادله إلى mount [-o opts] -t <fstype> <src> <path> .
  
  
  • إذا كان absent ، ما يعادل umount <path> .
  
  
  • تجاهل mounted : الآن ما يعادل present - لكن استمر في السلوك الحالي لتحديث fstab أيضًا ما لم يكن enabled=no
  
  
  • تجاهل unmounted : الآن ما يعادل absent - لكن استمر في السلوك الحالي لتحديث fstab أيضًا ما لم يكن enabled=yes
  
  
  • تجاهل remounted : أوصي باستخدام force لهذا بدلاً من ذلك - لكن استمر في السلوك الحالي لمحاولة إعادة التجميع
  
  

أعترف أنني لم ألقي نظرة على الكود ولا أعرف ما إذا كان تنفيذ اقتراحاتي مرهقًا. ومع ذلك ، سيغطي هذا أيضًا حالة الاستخدام الإضافية الخاصة بي لضمان تثبيت نقطة تحميل تم تكوينها مسبقًا بالفعل ، دون الحاجة إلى معرفة جميع تفاصيلها (على سبيل المثال ، src و fstab ) إذا كانت موجودة بالفعل في fstab.

إذا أدت إضافة الخيار force الإضافي إلى الكثير من التعقيد ، فلا بأس من ترك الخيار state=remounted كخيار صالح (غير مهمل).

نظرًا لأن فريق Dev لم يتمكن من تحديث هذه الميزة ، فأنا أستخدم حلًا آخر

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: mounted
    fstab: /tmp/tmp.fstab

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: unmounted
    fstab: /tmp/tmp.fstab

استخدم ملف fstab مزيف / مؤقت.

هاه ، هذا أنيق. لذلك بمجرد الانتهاء من التثبيت ، هل من المقبول إلغاء التحميل وحذف tmp.fstab ؟

هاه ، هذا أنيق. لذلك بمجرد الانتهاء من التثبيت ، هل من المقبول إلغاء التحميل وحذف tmp.fstab ؟

نعم :)