Ansible.posix: [माउंट] /etc/fstab को बदले बिना फाइल सिस्टम को अस्थायी रूप से माउंट करने की क्षमता

पिछले 5 वर्षों में पहले खोले गए मुद्दों और पीआर ( 2571 , 198220 , 48134 ) में चर्चा की गई एक अतिरिक्त उपयोग के मामले, और एक मैं वर्तमान में सामना कर रहा हूं, एक फाइल सिस्टम को जो पहले से ही 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 भी, हो सकता है) पर ध्यान नहीं दिया जाता है)।

वास्तव में यह नहीं देखा कि पिछला अंक क्यों बंद किया गया था, ऐसा लग रहा था कि वहाँ अच्छी चर्चा हुई थी। उत्तरदायी कोर टीम का तर्क है कि इसका मतलब है कि "माउंट" मॉड्यूल में बहुत सारे विकल्प हैं, 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
• पुराना state=absent -> नया enabled=no + state=unmounted (या माउंटपॉइंट हटाने के लिए state=absent ?)

अन्य विचार?

अगर यह सबसे आसान गैर-ब्रेकिंग समाधान है तो मैं क्विडेम के सुझाव के साथ ठीक

सेवा/प्रणाली के साथ निरंतरता के लिए, हालांकि, मैं व्यक्तिगत रूप से अंतिम लक्ष्य रखना पसंद करूंगा:

• state=present जिसका अर्थ है "_mounted_", state=absent जिसका अर्थ है "_unmounted_"
• state=remounted एक force (या शायद force_mount ) विकल्प के पक्ष में गिरा दिया गया
• enabled=yes जिसका अर्थ है "_वर्तमान में 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 को वैध (गैर-पदावनत) विकल्प के रूप में छोड़ना ठीक है।

चूंकि देव टीम इस सुविधा को अपडेट नहीं कर सकी, इसलिए मैं एक और समाधान का उपयोग करता हूं

- 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 को अनमाउंट करना और हटाना ठीक है?

हां :)