Køyrde OpenVPN up-skriptet for tidleg, eller var det aldri klart?
up-kroken køyrast når tunnel-eininga dukkar opp, før ruter og applikasjonsberedskap. Tilpass skriptet til hendinga det treng, i staden for å leggje til ein pause.
up-skriptet køyrast, avsluttar med null, og oppgåva inni det når ikkje ein privat teneste som fungerer perfekt to sekund seinare frå ein terminal. Instinktet er timing, og den vanlege reparasjonen er ein pause, som skjuler kappløpet utan å forstå det. Den meir nyttige lesinga er at “up” namngir ein krok, ikkje ein garanti for beredskap. Han utløysast når tunnel-eininga er konfigurert, som er tidlegare enn ruter, DNS og absolutt tidlegare enn kvar applikasjon bak tunnelen.
Skalltesten lukkast fordi han køyrde etter at alt hadde roa seg. Kroken køyrde på eitt bestemt tidspunkt.
Kvar up ligg i oppstartsrekkjefølgja
OpenVPN konfigurerer tunnel-eininga og køyrer deretter up-kroken. Ruteinstallasjon er eit seinare trinn, og det har sin eigen krok, og difor kan ei ruteavhengig oppgåve plassert i up sjå ei eining utan nyttig veg. Legg ruterarbeidet i route-up, og tidsproblemet forsvinn vanlegvis.
Handboka dokumenterer denne rekkjefølgja og miljøet kvar krok mottek. Den rekkjefølgja er heile forklaringa på den klassiske rapporten “fungerer frå skallet mitt”, og det er også grunnen til at det same skriptet kan bestå på éin maskin og feile på ein annan med eit tregare rute-trinn. Ingen av resultata seier noko om kvaliteten på skriptet.
DNS og applikasjonsberedskap kjem endå seinare. Sjølv installerte ruter er ikkje bevis for at det fjerne endepunktet lyttar, at eit namn vert løyst opp, eller at det finst ein skrivebordssesjon for ei brukarskopsoppgåve.
Kva kroken faktisk arvar
Ein krok køyrer under kontoen og miljøet til OpenVPN-prosessen, noko som ikkje er det same som det interaktive skallet ditt. Det kan mangla ein sesjonsbuss for brukaren, eit skrivebordsmiljø eller ein legitimasjon som berre vert låst opp ved innlogging. Skriv ned kva av desse oppgåva faktisk treng.
Det er viktig for oppgåver som ser ut som nettverk, men avheng av ein brukarkontekst: montering av ei deling med brukarlegitimasjon, innstilling av proxy per brukar eller konfigurering av ein skrivar. Ein privilegert tunnelkrok er feil stad for dei, og inga mengd venting rettar opp ein manglande sesjon.
Når ei oppgåve feilar i ein krok, registrer kontoen, miljøet og den første operasjonen som feila. Det skil for tidleg timing frå eit løyve- eller kontekstproblem, og dei to har heilt forskjellige reparasjonar. Å gjette mellom dei er korleis ein femminutts fiks vert ein heil ettermiddag.
Kvifor det å leggje til ein pause ikkje er ein beredskapssjekk
Ein pause forseinkar skriptet og forskyv kappløpsvindauget. På ein rask dag lukkast oppgåva; på ein treg dag feilar ho igjen, og feilen vert vanskelegare å reprodusere fordi forseinkinga ser ut til å verke. Ei forseinking som berre verkar under lett last er eit samantreff, ikkje ein reparasjon.
Viss avhengnaden er ei rute, bruk kroken som svarar til ruteinstallasjon. Viss avhengnaden er ei teneste bak tunnelen, bruk ein avgrensa sjekk som ventar på den spesifikke føresetnaden og feilar tydeleg når han aldri kjem.
Hald feilen eksplisitt. Ein krok som avsluttar med null medan det faktiske arbeidet feila, er verre enn ein krok som feilar, fordi tenestebehandlaren registrerer ein suksess og ingen ser igjen. Éi logglinje frå skriptet sjølv er den billegaste måten å halde det ærleg på.
Opprydding og gjenoppkopling fortener same omhu
Eit skript som endrar delt tilstand treng ein samsvarande angrepsveg. Ruter, resolveroppføringar og brannmurmerke lagt til av ein krok bør vere idempotente og reversible, elles vil ei gjenoppkopling stable ein andre kopi oppå den første.
Gjenoppkoplingar kan også køyre krokar oftare enn ein full tenestestart. Eit vedvarande grensesnitt som gjenopprettar ein sesjon kan utløyse up- og route-up-syklusen igjen, så eit skript som føreset éi køyring per oppstart vil til slutt oppføre seg feil. Tel køyringane i loggen gjennom ein dag med flapping for å sjå kor ofte det faktisk køyrer. Deretter gjer skriptet trygt å køyre så mange gonger.
Test livssyklusen som feila, ikkje ein seinare kommando. Reproduser oppstarten eller gjenoppkoplinga, sjå kroken køyre, og stadfest at oppgåva lukkast i det augneblunken ho faktisk køyrer. Ein suksess frå eit interaktivt skall etterpå er bevis om avhengnaden, ikkje bevis for at oppstartsvegen verkar.
Namngi hendinga kvar oppgåve avheng av, og fest ho til den hendinga. Alt anna er ei forseinking som latar som ho er ein sjekk.