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 ഉപയോഗിക്കുക. അപ്സ്ട്രീം 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 എന്നിവയുടെ വ്യത്യാസം വിശദീകരിക്കുന്നു, പച്ച സംഗ്രഹത്തിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം ഒരിക്കൽ വായിക്കുന്നത് നല്ലതാണ്. ഈ മുഴുവൻ ചർച്ചയും ആ ഒരു വ്യത്യാസത്തിൽ നിന്നാണ്.