Ansible કહે છે કે શરૂ થઈ ગયું, પણ WireGuard હજી જૂની ગોઠવણી પર ચાલે છે

state: started ચાલતા એકમને અકબંધ રાખે છે, તેથી ફરી લખાયેલ wg0.conf ક્યારેય લાગુ થતું નથી. ફેરફાર માટે handler ઉમેરો અને પછી જીવંત ઉપકરણની ફાઇલ સાથે તુલના કરો.

playbook લીલા રંગે પૂરું થાય છે, WireGuard એકમ સક્રિય છે, handshake કામ કરે છે, અને નવું peer તોય ક્યાંય પહોંચતું નથી. સર્વર ગઈકાલની ગોઠવણી પર ચાલે અને playbook સફળતા જાહેર કરે તે જોવું ખાસ કરીને નિરાશાજનક છે, કારણ કે આઉટપુટમાં કંઈ ખોટું નથી. Ansible એ બરાબર એ જ કર્યું જે માંગ્યું હતું: તેણે એકમ શરૂ છે તે સુનિશ્ચિત કર્યું, અને એકમ પહેલેથી શરૂ હતું. ફરી લખાયેલ ગોઠવણી ફાઇલ લાગુ કરવી એ બીજું કામ છે, અને તે ત્યારે જ થાય છે જ્યારે કંઈક સેવાને તે ફરી વાંચવા કહે.

બીજી વાર ચલાવવાથી શું જાણ થાય છે તે જુઓ

બદલાયેલી ગોઠવણી સાથે playbook બે વાર ચલાવો અને સારાંશની તુલના કરો. બીજી વખતે એકમનું કાર્ય ok દેખાવું જોઈએ, changed નહીં, કારણ કે પહેલેથી ચાલતી સેવાને ડિઝાઇન પ્રમાણે અકબંધ રાખવામાં આવે છે. આ યોગ્ય રીતે કામ કરતું 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

ત્રણ સમયચિહ્નો એક પણ લોગ લાઇન વાંચ્યા પહેલાં વાર્તા કહી દે છે. જો ગોઠવણી ફાઇલ એકમ સક્રિય થયાની ક્ષણ કરતાં નવી હોય, તો ચાલતું ઇન્ટરફેસ જૂની ફાઇલમાંથી બન્યું છે, અને પછીના બધા લક્ષણો ત્યાંથી જ આવે છે.

આ Ansible ની ખામી નથી. આ જ વર્તન એવા કોઈપણ ગોઠવણી વ્યવસ્થાપન સાધનમાં દેખાય છે જે «ખાતરી કરો કે તે ચાલે છે» ને «ખાતરી કરો કે તે આ જ ચલાવે છે» થી અલગ કરે છે. આ ફરક ત્યાં સુધી કંટાળાજનક લાગે છે જ્યાં સુધી તે તમારો એક બપોર ન ખાઈ જાય.

શરૂ થવું એ સ્થિતિ છે, ફરી લોડ કરવું નહીં

state: started એકમ વિશે શરત જણાવે છે. તે વચન આપતું નથી કે સેવા તેના ઇનપુટ ફરી વાંચશે, અને જે ફાઇલ તેણે ક્યારેય ખોલી નથી તે બદલાઈ છે તે જાણી શકતું નથી. wg-quick જમાવટમાં ઇનપુટમાં ઇન્ટરફેસ ગોઠવણી, સરનામાં, રૂટ, DNS નોંધો અને કોઈપણ post-up હૂકનો સમાવેશ થાય છે.

તેથી અપડેટ થયેલી ફાઇલમાં નવું peer, બીજું સરનામું કે બદલાયેલ રૂટિંગ સૂચના હોઈ શકે, જ્યારે જીવંત ઇન્ટરફેસ જૂનો સમૂહ પરિચર્યા કરતું રહે. handshake હજી સફળ થાય છે, કારણ કે લોડ થયેલ કી અને એન્ડપોઇન્ટ હજી માન્ય છે. એ જ નિષ્ફળતાને દેખાવામાં અઘરી બનાવે છે, અને લોકો સમયચિહ્ન તપાસ્યા પહેલાં કલાક સુધી DNS પાછળ દોડે છે.

મોડ્યુલના બે બીજા વિકલ્પોને ઘણી વાર ઉકેલ માનવામાં આવે છે. daemon_reload systemd ને એકમ ફાઇલો ફરી વાંચવા દે છે, જે WireGuard ગોઠવણી ફાઇલ માટે અપ્રસ્તુત છે. state: reloaded એકમને તેની ફરી-લોડ ક્રિયા ચલાવવા કહે છે, અને તે તમને જોઈતું કરે છે કે નહીં તે સંપૂર્ણપણે એકમ પર આધાર રાખે છે. બંમાંથી કોઈ ચાલતી પ્રક્રિયાએ ખરેખર કયા ઇનપુટ વાંચ્યા તે જાણવાનું બદલી શકતું નથી.

ફાઇલ સ્થાપિત કરો, પછી 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 પ્લેના અંતે ચાલે છે, તેમને જાણ કરનારા કાર્યો પછી, તેથી એ જ પ્લેમાં પછીનું કાર્ય હજી જૂનું ઇન્ટરફેસ જોઈ શકે. જો ક્રમ મહત્ત્વનો હોય, તો નવી ગોઠવણી પર આધારિત કાર્ય પહેલાં meta: flush_handlers વડે handler ને સ્પષ્ટપણે ખાલી કરો.

restart વાપરો, reload નહીં, જ્યાં સુધી એકમની ફરી-લોડ ક્રિયા ચકાસી ન હોય. અપસ્ટ્રીમ wg-quick એકમ એકને સમર્થન આપે છે અને 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 એકમ પર peer અને કીના ફેરફાર માટે તે પૂરતું છે; સરનામાંકન, રૂટિંગ અને હૂક માટે નહીં. એક વાર આ સ્પષ્ટ કરવું ફેરફાર-વિન્ડો દરમિયાન શોધવા કરતાં સસ્તું છે.

systemd_service મોડ્યુલનું દસ્તાવેજીકરણ started, restarted અને reloaded વચ્ચેનો ફરક સ્પષ્ટ કરે છે, અને લીલા સારાંશ પરથી અનુમાન કરવાને બદલે એક વાર વાંચવું યોગ્ય છે. આ આખી ચર્ચા એ જ એક ફરકમાંથી આવે છે.

સંબંધિત લેખો