Ansible diras startigita, sed WireGuard plu rulas la malnovan agordon

state: started lasas rulantan unuon netuŝita, do reskribita wg0.conf neniam aplikiĝas. Aldonu ŝanĝo-traktilon kaj poste komparu la vivan aparaton kun la dosiero.

La playbook finiĝas verda, la WireGuard-unuo estas aktiva, la manpremo funkcias, kaj la nova peer tamen atingas nenion. Vidi playbook-on raporti sukceson dum la servilo rulas la hieraŭan agordon estas aparte frustra, ĉar nenio en la eligo malĝustas. Ansible faris ĝuste tion, kion oni petis: ĝi certigis, ke la unuo estu startigita, kaj ĝi jam estis startigita. Apliki reskribitan agordan dosieron estas alia tasko, kaj ĝi okazas nur se io diras al la servo relegi ĝin.

Rigardu, kion dua rulo efektive raportas

Rulu la playbook-on dufoje kun la ŝanĝita agordo en loko kaj komparu la resumon. La dua rulo devus montri la unu-taskon kiel ok, ne changed, ĉar jam rulanta servo estas intence lasata trankvila. Tio estas idempotenteco funkcianta ĝuste, kaj ankaŭ la kialo, kial la nova dosiero neniam atingas la kernon.

Aldonu kontrolrulon kun diff-eligo por vidi, kiuj taskoj entute tuŝus ion.

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

La tri tempindikoj rakontas la historion antaŭ ol vi legas eĉ unu logan linion. Se la agorda dosiero estas pli nova ol la momento, kiam la unuo aktiviĝis, la rulanta interfaco estis konstruita el pli malnova dosiero, kaj ĉiu posta simptomo sekvas el tio.

Tio ne estas difekto de Ansible. La sama konduto aperas ĉe ĉiu agorda administrilo, kiu apartigas «certiĝu, ke ĝi rulas» de «certiĝu, ke ĝi rulas ĉi tion». La distingo ŝajnas pedanta ĝis ĝi kostas al vi posttagmezon.

Startigita estas stato, ne reŝargo

state: started asertas kondiĉon pri la unuo. Ĝi ne promesas, ke la servo relegos siajn enigojn, kaj ĝi ne povas scii, ke dosiero, kiun ĝi neniam malfermis, ŝanĝiĝis. Ĉe wg-quick-agordado la enigoj inkludas la interfacan agordon, la adresojn, la vojojn, la DNS-rikordojn kaj eventualajn post-up-hokojn.

Tial ĝisdatigita dosiero povas enhavi novan peer, alian adreson aŭ ŝanĝitan vojigan direktivon, dum la viva interfaco plu servas la malnovan aron. La manpremo ankoraŭ sukcesas, ĉar la ŝargitaj ŝlosiloj kaj finpunktoj ankoraŭ validas. Ĝuste tio malfaciligas vidi la difekton, kaj kial homoj ĉasas DNS dum horo antaŭ ol kontroli tempindikon.

Du pliaj modulaj opcioj ofte estas prenataj kiel solvo. daemon_reload igas systemd relegi unuajn dosierojn, kio estas nerelevanta por WireGuard-agorda dosiero. state: reloaded petas al la unuo plenumi sian reŝargan agon, kaj ĉu tio faras tion, kion vi bezonas, tute dependas de la unuo. Neniu el ili anstataŭas scii, kiujn enigojn la rulanta procezo efektive legis.

Instalu la dosieron, poste sciigu traktilon

La ŝablono, kiu konservas idempotentecon kaj tamen aplikas ŝanĝojn, estas la ordinara: la tasko, kiu skribas la dosieron, sciigas traktilon, kaj la traktilo rulas nur kiam la dosiero efektive ŝanĝiĝis. Dua rulo sen redaktoj faras nenion, kaj tion vi volas.

- 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

Traktiloj rulas ĉe la fino de la teatraĵo, post la taskoj, kiuj sciigis ilin, do tasko pli poste en la sama teatraĵo povas ankoraŭ vidi la malnovan interfacon. Se la ordo gravas, malplenigu la traktilojn eksplicite per meta: flush_handlers antaŭ la tasko, kiu dependas de la nova agordo.

Uzu restart anstataŭ reload, krom se vi kontrolis la reŝargan agon de la unuo. La upstream wg-quick-unuo subtenas unu, kaj ĝi sinkronigas la WireGuard-agordon, sed ĝi ne re-plenumas agordon de adresoj, vojoj, DNS aŭ hokoj. Reload post aldono de voja direktivo do ŝajnas sukcesi kaj ŝanĝas nenion.

Komparu la vivan aparaton kun la dosiero

La kontrolo, kiu fermas tiun ĉi klason de cimoj, estas komparo inter tio, kion tenas la kerno, kaj tio, kion diras la dosiero. Du komandoj produktas kompareblan eligon, kaj la diferenco estas la deflankiĝo.

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

wg showconf presas la vivan aparaton, inkluzive de la privata ŝlosilo, do traktu tiun eligon kiel sekreton kaj ne algluu ĝin en bileton. wg-quick strip presas la dosieron sen la ŝlosiloj propraj al wg-quick, kaj tial la du estas entute kompareblaj.

Diferenco en la peer-listo signifas, ke la dosiero neniam estis aplikita. Diferenco limigita al ŝlosiloj aŭ finpunktoj, kiujn vi atendis ŝanĝiĝi, signifas, ke io aplikis ĝin parte. Neniu diferenco signifas, ke la agordo estas aktuala kaj la difekto estas aliloke, kio mem estas utila rezulto.

Pagu la koston de restarto konscie

Restarti la interfacon faligas la tunelon, kaj se tiu tunelo portas vian administran sesion, la restarto finas la sesion, kiu petis ĝin. Metu la traktilon malantaŭ ŝanĝofenestro, aŭ rulu la playbook-on el administra vojo, kiu ne dependas de restartado de la interfaco.

La kosto estas la kialo, kial homoj kaptas reload. Tio estas racia instinkto, kaj ĝi fariĝas ĝusta, kiam vi scias, kiujn ŝanĝojn reload efektive aplikas. Por peer- kaj ŝlosilŝanĝoj en la upstream wg-quick-unuo ĝi sufiĉas; por adresado, vojigado kaj hokoj ne. Klarigi tion unufoje malpli kostas ol malkovri ĝin dum ŝanĝofenestro.

La dokumentaro de la modulo systemd_service klarigas la diferencon inter started, restarted kaj reloaded, kaj indas legi ĝin unufoje anstataŭ diveni el verda resumo. Ĉio en ĉi tiu trairo sekvas el tiu unu distingo.

Rilataj artikoloj