Ansible भन्छ सुरु भयो, तर WireGuard अझै पुरानो कन्फिगमै चलिरहेको छ

state: started पहिले नै चलिरहेको unit लाई छुँदैन, त्यसैले फेरि लेखिएको wg0.conf कहिल्यै लागू हुँदैन। परिवर्तनका लागि handler थप्नुहोस् र त्यसपछि जीवित उपकरणको फाइलसँग तुलना गर्नुहोस्।

playbook को रन हरियो भएर सकिन्छ, WireGuard unit सक्रिय छ, handshake काम गर्छ, तर नयाँ peer कतै पुग्दैन। सर्भर हिजोको कन्फिगमा चलिरहेको बेला playbook ले सफलता रिपोर्ट गरेको देख्नु विशेष रिस उठ्ने कुरा हो, किनकि आउटपुटमा केही पनि गलत छैन। Ansible ले ठ्याक्कै भनिएको काम गर्यो: unit सुरु भएको सुनिश्चित गर्यो, र unit पहिले नै सुरु थियो। फेरि लेखिएको कन्फिग फाइल लागू गर्नु अर्को काम हो, र केहीले सेवालाई त्यो फेरि पढ्न भनेपछि मात्र हुन्छ।

दोस्रो रनले वास्तवमा के रिपोर्ट गर्छ हेर्नुहोस्

परिवर्तित कन्फिगसहित playbook दुई पटक चलाउनुहोस् र सारांश तुलना गर्नुहोस्। दोस्रो रनले unit कार्य changed होइन, ok देखाउनुपर्छ, किनकि पहिले नै चलिरहेको सेवालाई डिजाइनअनुसार शान्त छोडिन्छ। यो सही रूपमा काम गर्ने idempotence हो, र नयाँ फाइल कहिल्यै kernel सम्म नपुग्नुको कारण पनि यही हो।

diff आउटपुटसहित परीक्षण रन थप्नुहोस्, कुन कार्यले केही छुन्छन् हेर्न।

ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.conf

तीन टाइमस्ट्याम्पले एक लाइन लग पढ्नुअघि नै कथा भन्छन्। यदि कन्फिग फाइल unit सक्रिय भएको क्षणभन्दा नयाँ छ भने, चलिरहेको इन्टरफेस पुरानो फाइलबाट बनेको हो, र पछिका सबै लक्षण त्यहीँबाट आउँछन्।

यो Ansible को त्रुटि होइन। «यो चलिरहेको छ भनी सुनिश्चित गर» र «यसले यही चलाइरहेको छ भनी सुनिश्चित गर» भनेर छुट्याउने कुनै पनि कन्फिगरेसन व्यवस्थापन उपकरणमा यही व्यवहार देखिन्छ। यो भिन्नता दिउँसो बर्बाद नगरेसम्म निकै सूक्ष्म लाग्छ।

सुरु भएको अवस्था हो, पुनःलोड होइन

state: started unit बारे सर्त बताउँछ। सेवाले आफ्ना इनपुट फेरि पढ्छ भनी यसले वाचा गर्दैन, र कहिल्यै नखोलेको फाइल बदलियो भनी जान्न सक्दैन। wg-quick तैनाथीमा इनपुटमा इन्टरफेस कन्फिग, ठेगानाहरू, रुटहरू, DNS प्रविष्टिहरू र कुनै पनि post-up हुक पर्छन्।

त्यसैले अद्यावधिक फाइलमा नयाँ peer, फरक ठेगाना वा बदलिएको राउटिङ निर्देशन हुन सक्छ, जबकि चलिरहेको इन्टरफेस पुरानै सेट दिइरहन्छ। handshake अझै सफल हुन्छ, किनकि लोड गरिएका कुञ्जी र इन्डपोइन्ट अझै मान्य छन्। यही कारणले विफलता देख्न गाह्रो हुन्छ, र मानिसहरू टाइमस्ट्याम्प जाँच्नुअघि एक घण्टा DNS पछि दौडन्छन्।

मोड्युलका अरू दुई विकल्पलाई प्रायः समाधान ठानिन्छ। daemon_reload ले systemd लाई unit फाइलहरू फेरि पढ्न लगाउँछ, जुन WireGuard कन्फिग फाइलसँग सम्बन्धित छैन। state: reloaded ले unit लाई यसको पुनःलोड क्रिया चलाउन भन्छ, र त्यसले तपाईंलाई चाहिएको काम गर्छ वा गर्दैन भन्ने पूर्ण रूपमा unit मा निर्भर छ। कुनैले पनि चलिरहेको प्रक्रियाले वास्तवमा कुन इनपुट पढ्यो भनी जान्ने कुराको ठाउँ लिँदैन।

फाइल स्थापना गर्नुहोस्, त्यसपछि handler लाई जानकारी दिनुहोस्

idempotence जोगाउँदै परिवर्तन लागू गर्ने ढाँचा सामान्य हो: फाइल लेख्ने कार्यले handler लाई जानकारी दिन्छ, र फाइल साँच्चै बदलिएमा मात्र handler चल्छ। सम्पादन नगरी दोस्रो रनले केही गर्दैन, र तपाईंलाई त्यही चाहिएको हो।

- name: write the interface configuration
  ansible.builtin.template:
    src: wg0.conf.j2
    dest: /etc/wireguard/wg0.conf
    owner: root
    mode: "0600"
  notify: apply wg0

- name: ensure the interface unit is enabled
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    enabled: true
    state: started

- name: apply wg0
  listen: apply wg0
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    state: restarted

handler हरू play को अन्त्यमा, आफूलाई जानकारी दिने कार्यहरूपछि चल्छन्, त्यसैले त्यही play को पछिको कार्यले अझै पुरानो इन्टरफेस देख्न सक्छ। क्रम महत्त्वपूर्ण भएमा, नयाँ कन्फिगमा निर्भर कार्यअघि meta: flush_handlers ले handler हरू स्पष्ट रूपमा खाली गर्नुहोस्।

unit को पुनःलोड क्रिया जाँचेको छैन भने reload को सट्टा restart प्रयोग गर्नुहोस्। अपस्ट्रिम wg-quick unit ले एउटालाई समर्थन गर्छ र WireGuard कन्फिग सिङ्क गर्छ, तर ठेगाना, रुट, DNS वा हुकको सेटअप फेरि चलाउँदैन। त्यसैले रुट निर्देशन थपेपछिको reload सफल देखिन्छ र केही बदल्दैन।

जीवित उपकरणको फाइलसँग तुलना गर्नुहोस्

यस वर्गका बग बन्द गर्ने जाँच kernel सँग भएको र फाइलले भनेको कुराबीचको तुलना हो। दुई आदेशले तुलनायोग्य आउटपुट दिन्छन्, र भिन्नता नै विचलन हो।

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

wg showconf निजी कुञ्जीसहित जीवित उपकरण छाप्छ, त्यसैले त्यो आउटपुटलाई गोप्य ठान्नुहोस् र टिकटमा टाँस्नु हुँदैन। wg-quick strip wg-quick-विशेष कुञ्जीहरू हटाएर फाइल छाप्छ, र त्यसैले दुवै तुलनायोग्य छन्।

peer सूचीमा भिन्नता भन्नाले फाइल कहिल्यै लागू भएन। बदलिने अपेक्षा गरिएका कुञ्जी वा इन्डपोइन्टमा मात्र भिन्नता भन्नाले कसैले यसलाई आंशिक रूपमा लागू गर्यो। कुनै भिन्नता नहुनु भन्नाले कन्फिग हालको छ र त्रुटि अन्यत्र छ, जुन आफैंमा उपयोगी परिणाम हो।

पुनःसुरुको लागत जानाजान तिर्नुहोस्

इन्टरफेस पुनःसुरु गर्दा सुरुङ भाँचिन्छ, र त्यो सुरुङले तपाईंको प्रशासनिक सत्र बोकेको छ भने, पुनःसुरुले त्यो माग्ने सत्र अन्त्य गर्छ। handler लाई परिवर्तन-विन्डोको पछाडि राख्नुहोस्, वा इन्टरफेस पुनःसुरुमा निर्भर नहुने व्यवस्थापन मार्गबाट playbook चलाउनुहोस्।

यही लागतले मानिसहरूलाई reload तिर तान्छ। यो उचित प्रवृत्ति हो, र reload ले वास्तवमा कुन परिवर्तन लागू गर्छ भन्ने थाहा भएपछि सही हुन्छ। अपस्ट्रिम wg-quick unit मा peer र कुञ्जी परिवर्तनका लागि यो पर्याप्त छ; ठेगाना, राउटिङ र हुकका लागि होइन। एक पटक यो स्पष्ट पार्नु परिवर्तन-विन्डोमा पत्ता लगाउनुभन्दा सस्तो हुन्छ।

systemd_service मोड्युलको कागजात ले started, restarted र reloaded बीचको भिन्नता बताउँछ, र हरियो सारांशबाट अनुमान गर्नुभन्दा एक पटक पढ्नु राम्रो हो। यो सम्पूर्ण चर्चाको जड त्यही एउटा भिन्नता हो।

सम्बन्धित लेखहरू