Kjørte OpenVPN up-skriptet for tidlig, eller var det aldri klart?

up-skriptet kjøres, avslutter med null, og oppgaven inni det når ikke en privat tjeneste som fungerer perfekt to sekunder senere fra en terminal. Instinktet er timing, og den vanlige reparasjonen er en pause, som skjuler kappløpet uten å forstå det. Den mer nyttige lesningen er at “up” navngir en krok, ikke en garanti for beredskap. Den utløses når tunnel-enheten er konfigurert, som er tidligere enn ruter, DNS og absolutt tidligere enn enhver applikasjon bak tunnelen.

Skalltesten lyktes fordi den kjørte etter at alt hadde roet seg. Kroken kjørte på ett bestemt tidspunkt.

Hvor up ligger i oppstartsrekkefølgen

OpenVPN konfigurerer tunnel-enheten og kjører deretter up-kroken. Ruteinstallasjon er et senere trinn, og det har sin egen krok, og derfor kan en ruteavhengig oppgave plassert i up se en enhet uten nyttig vei. Legg ruterbeidet i route-up, og tidsproblemet forsvinner vanligvis.

Håndboken dokumenterer denne rekkefølgen og miljøet hver krok mottar. Den rekkefølgen er hele forklaringen på den klassiske rapporten “fungerer fra skallet mitt”, og det er også grunnen til at det samme skriptet kan bestå på én maskin og feile på en annen med et tregere rute-trinn. Ingen av resultatene sier noe om kvaliteten på skriptet.

DNS og applikasjonsberedskap kommer enda senere. Selv installerte ruter er ikke bevis for at det fjerne endepunktet lytter, at et navn løses opp, eller at det finnes en skrivebordssesjon for en brukerscoped oppgave.

Hva kroken faktisk arver

En krok kjører under kontoen og miljøet til OpenVPN-prosessen, noe som ikke er det samme som det interaktive skallet ditt. Den kan mangle en brukers sesjonsbuss, et skrivebordsmiljø eller en legitimasjon som bare låses opp ved innlogging. Skriv ned hvilke av disse oppgaven faktisk trenger.

Det er viktig for oppgaver som ser ut som nettverk, men avhenger av en brukerkontekst: montering av en deling med brukerlegitimasjon, angivelse av proxy per bruker eller konfigurering av en skriver. En privilegert tunnelkrok er feil sted for dem, og ingen mengde venting retter opp en manglende sesjon.

Når en oppgave feiler i en krok, registrer kontoen, miljøet og den første operasjonen som feilet. Det skiller for tidlig timing fra et tillatelses- eller kontekstproblem, og de to har helt forskjellige reparasjoner. Å gjette mellom dem er hvordan en femminutters fiks blir en hel ettermiddag.

Hvorfor det å legge til en pause ikke er en beredskapssjekk

En pause forsinker skriptet og forskyver kappløpsvinduet. På en rask dag lykkes oppgaven; på en treg dag feiler den igjen, og feilen blir vanskeligere å reprodusere fordi forsinkelsen ser ut til å virke. En forsinkelse som bare virker under lett belastning er en tilfeldighet, ikke en reparasjon.

Hvis avhengigheten er en rute, bruk kroken som tilsvarer ruteinstallasjon. Hvis avhengigheten er en tjeneste bak tunnelen, bruk en avgrenset sjekk som venter på den spesifikke betingelsen og feiler tydelig når den aldri kommer.

Hold feilen eksplisitt. En krok som avslutter med null mens det faktiske arbeidet feilet, er verre enn en krok som feiler, fordi tjenestebehandleren registrerer en suksess og ingen ser igjen. Én logglinje fra skriptet selv er den billigste måten å holde det ærlig på.

Opprydding og gjentilkobling fortjener samme omhu

Et skript som endrer delt tilstand trenger en samsvarende angrepsvei. Ruter, resolveroppføringer og brannmurmarkeringer lagt til av en krok bør være idempotente og reversible, ellers vil en gjentilkobling stable en andre kopi oppå den første.

Gjentilkoblinger kan også kjøre kroker oftere enn en full tjenestestart. Et vedvarende grensesnitt som gjenoppretter en sesjon kan utløse up- og route-up-syklusen igjen, så et skript som antar én kjøring per oppstart vil til slutt oppføre seg feil. Tell kjøringene i loggen gjennom en dag med flapping for å se hvor ofte det faktisk kjører. Deretter gjør skriptet trygt å kjøre så mange ganger.

Test livssyklusen som feilet, ikke en senere kommando. Reproduser oppstarten eller gjentilkoblingen, se kroken kjøre, og bekreft at oppgaven lyktes i det øyeblikket den faktisk kjører. En suksess fra et interaktivt skall etterpå er bevis om avhengigheten, ikke bevis for at oppstartsstien virker.

Navngi hendelsen hver oppgave avhenger av, og fest den til den hendelsen. Alt annet er en forsinkelse som later som den er en sjekk.