Je li OpenVPN up skripta pokrenuta prerano ili nikada nije bila spremna?

up skripta se izvršava, izlazi s nulom, a zadatak u njoj ne dolazi do privatne usluge koja s terminala savršeno radi dvije sekunde kasnije. Instinkt kaže da je riječ o vremenu, a uobičajeni popravak je pauza, koja skriva utrku bez razumijevanja. Korisnije čitanje je da “up” imenuje kuku, a ne jamstvo spremnosti. Aktivira se kada je tunelski uređaj konfiguriran, što je prije ruta, DNS-a i sigurno prije bilo koje aplikacije iza tunela.

Test u ljusci je uspio jer se izvršio nakon što se sve smirilo. Kuka se izvršila u jednom određenom trenutku.

Gdje se up nalazi u redoslijedu pokretanja

OpenVPN konfigurira tunelski uređaj i zatim izvršava up kuku. Instalacija ruta je kasnija faza i ima vlastitu kuku, zato zadatak ovisan o rutama smješten u up može vidjeti uređaj bez korisne staze. Stavite rad s rutama u route-up i problem s vremenom obično nestaje.

Priručnik dokumentira taj redoslijed i okruženje koje dobiva svaka kuka. Taj redoslijed je cijelo objašnjenje klasičnog izvještaja “radi iz moje ljuske”, a to je i razlog zašto ista skripta može proći na jednom stroju i pasti na drugom sa sporijom fazom ruta. Nijedan od rezultata ne govori ništa o kvaliteti skripte.

DNS i spremnost aplikacije dolaze još kasnije. Čak ni instalirane rute nisu dokaz da udaljena krajnja točka sluša, da se ime razrješava ili da postoji desktop sesija za zadatak u korisničkom opsegu.

Što kuka zapravo nasljeđuje

Kuka se izvršava pod računom i okruženjem OpenVPN procesa, što nije isto što i vaša interaktivna ljuska. Može joj nedostajati sabirnica sesije korisnika, desktop okruženje ili vjerodajnica koja se otključava samo pri prijavi. Zapišite što od toga zadatku stvarno treba.

To je važno za zadatke koji izgledaju mrežno, ali ovise o korisničkom kontekstu: montiranje dijeljenja s korisničkom vjerodajnicom, postavljanje proxyja po korisniku ili konfiguriranje pisača. Privilegirana tunelska kuka pogrešno je mjesto za njih, i nikakvo čekanje ne popravlja sesiju koja nedostaje.

Kada zadatak padne u kuki, zabilježite račun, okruženje i prvu operaciju koja je pala. To odvaja prerano vrijeme od problema s dopuštenjima ili kontekstom, a njih dvoje imaju potpuno različite popravke. Nagađanje između njih je način na koji popravak od pet minuta postaje cijelo poslijepodne.

Zašto dodavanje pauze nije provjera spremnosti

Pauza odgađa skriptu i pomiče prozor utrke. Brzog dana zadatak uspije; sporog dana ponovno padne, a kvar je teže reproducirati jer se čini da odgoda radi. Odgoda koja radi samo pod laganim opterećenjem je slučajnost, a ne popravak.

Ako je ovisnost ruta, upotrijebite kuku koja odgovara instalaciji ruta. Ako je ovisnost usluga iza tunela, upotrijebite ograničenu provjeru koja čeka taj konkretni uvjet i jasno pada kada nikad ne dođe.

Držite kvar eksplicitnim. Kuka koja izlazi s nulom dok je njezin stvarni posao pao gora je od kuke koja pada, jer upravitelj usluga bilježi uspjeh i nitko više ne gleda. Jedan redak zapisa iz same skripte najjeftiniji je način da to ostane pošteno.

Čišćenje i ponovno povezivanje zaslužuju istu pažnju

Skripta koja mijenja zajedničko stanje treba odgovarajući put za poništavanje. Rute, unosi razrješivača i oznake vatrozida koje doda kuka trebaju biti idempotentne i povratne, inače će ponovno povezivanje nasložiti drugu kopiju na prvu.

Ponovna povezivanja mogu izvršavati kuke češće od potpunog pokretanja usluge. Trajno sučelje koje ponovno uspostavlja sesiju može ponovno pokrenuti ciklus up i route-up, pa će skripta koja pretpostavlja jedno izvršavanje po podizanju sustava na kraju raditi pogrešno. Prebrojite izvršavanja u zapisu tijekom dana treperenja da vidite koliko se često doista pokreće. Zatim učinite skriptu sigurnom za toliko pokretanja.

Testirajte životni ciklus koji je pao, a ne kasniju naredbu. Reproducirajte podizanje sustava ili ponovno povezivanje, promatrajte kako se kuka izvršava i potvrdite da je zadatak uspio u trenutku kada se doista pokreće. Uspjeh iz interaktivne ljuske poslije je dokaz o ovisnosti, a ne dokaz da putanja pokretanja radi.

Imenujte događaj o kojem ovisi svaki zadatak, a zatim vežite zadatak za taj događaj. Sve ostalo je odgoda koja se pretvara da je provjera.