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 मधील फरक स्पष्ट करते, आणि हिरव्या सारांशावरून अंदाज लावण्यापेक्षा एकदा वाचणे योग्य आहे. या संपूर्ण चर्चेचा उगम त्या एकाच फरकात आहे.

संबंधित लेख