Ansible ਕਹਿੰਦਾ ਹੈ ਸ਼ੁਰੂ ਹੋ ਗਿਆ, ਪਰ WireGuard ਹਾਲੇ ਵੀ ਪੁਰਾਣੀ ਕੌਂਫਿਗ ਉੱਤੇ ਚੱਲ ਰਿਹਾ ਹੈ

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 ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਸਮਝਾਉਂਦਾ ਹੈ, ਅਤੇ ਹਰੇ ਸਾਰਾਂਸ਼ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਇੱਕ ਵਾਰ ਪੜ੍ਹਨਾ ਬਿਹਤਰ ਹੈ। ਇਸ ਸਾਰੀ ਚਰਚਾ ਦੀ ਜੜ੍ਹ ਉਹੀ ਇੱਕ ਫ਼ਰਕ ਹੈ।