Ansible ప్రారంభమైంది అంటుంది, కానీ WireGuard ఇంకా పాత కాన్ఫిగ్‌తోనే నడుస్తోంది

playbook రన్ ఆకుపచ్చగా ముగుస్తుంది, WireGuard unit యాక్టివ్‌గా ఉంది, handshake పనిచేస్తుంది, కానీ కొత్త peer ఎక్కడికీ చేరుకోదు. సర్వర్ నిన్నటి కాన్ఫిగ్‌తో నడుస్తుండగా playbook విజయాన్ని నివేదించడం చూడటం ప్రత్యేక చిరాకు, ఎందుకంటే అవుట్‌పుట్‌లో ఏదీ తప్పు కాదు. Ansible అడిగినది సరిగ్గా చేసింది: 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 వాడండి. upstream 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 నిజంగా ఏ మార్పులను వర్తిస్తుందో తెలిస్తే అది సరైనదవుతుంది. upstream wg-quick unit లో peer మరియు కీ మార్పులకు అది సరిపోతుంది; చిరునామా, రూటింగ్, హుక్‌లకు సరిపోదు. ఒకసారి దీన్ని స్పష్టం చేసుకోవడం మార్పు విండోలో కనుగొనడం కంటే చవక.

systemd_service మాడ్యూల్ డాక్యుమెంటేషన్ started, restarted, reloaded మధ్య భేదాన్ని వివరిస్తుంది, ఆకుపచ్చ సారాంశం నుండి ఊహించడం కంటే ఒకసారి చదవడం మంచిది. ఈ మొత్తం చర్చ ఆ ఒకే భేదం నుండి వస్తుంది.