Kørte OpenVPN up-scriptet for tidligt, eller var det aldrig klar?

up-scriptet kører, afslutter med nul, og opgaven indeni når ikke en privat tjeneste, der to sekunder senere fungerer perfekt fra en terminal. Instinktet siger timing, og den sædvanlige løsning er en pause, som skjuler kapløbet uden at forstå det. Den mere nyttige læsning er, at “up” er navnet på en krog, ikke en garanti for parathed. Den udløses, når tunnel-enheden konfigureres, hvilket er tidligere end ruter, DNS og bestemt tidligere end enhver applikation bag tunnelen.

Shell-testen lykkedes, fordi den kørte, efter at alt havde sat sig. Krogen kørte på et bestemt øjeblik.

Hvor up ligger i opstartsrækkefølgen

OpenVPN konfigurerer tunnel-enheden og kører derefter up-krogen. Installation af ruter er et senere trin og har sin egen krog, og derfor kan en ruteafhængig opgave placeret i up se en enhed uden en brugbar vej. Læg rutearbejde i route-up, og timingproblemet forsvinder normalt.

Manualen dokumenterer denne rækkefølge og det miljø, hver krog modtager. Denne rækkefølge er hele forklaringen på den klassiske rapport “virker fra min shell”, og det er også derfor, det samme script kan bestå på én maskine og fejle på en anden med et langsommere rutetrin. Ingen af resultaterne siger noget om scriptets kvalitet.

DNS- og applikationsparathed kommer endnu senere. Selv installerede ruter er ikke bevis for, at den fjerne ende lytter, at et navn opløses, eller at der findes en skrivebordssession til en brugerbestemt opgave.

Hvad krogen faktisk arver

En krog kører under OpenVPN-processens konto og miljø, hvilket ikke er det samme som din interaktive shell. Den kan mangle en brugers sessionsbus, et skrivebordsmiljø eller en legitimationsoplysning, der først låses op ved login. Skriv ned, hvilke af disse opgaven faktisk har brug for.

Det betyder noget for opgaver, der ser ud som netværk, men afhænger af en brugerkontekst: montering af en delt ressource med en brugers legitimationsoplysning, opsætning af en proxy for hver bruger eller konfiguration af en printer. En privilegeret tunnelkrog er det forkerte sted til dem, og ingen mængde venten retter en manglende session.

Når en opgave fejler i en krog, skal du notere kontoen, miljøet og den første handling, der fejlede. Det adskiller for tidlig timing fra et tilladelses- eller kontekstproblem, og de to har helt forskellige løsninger. At gætte mellem dem er, hvordan en femminutters løsning bliver en hel eftermiddag.

Hvorfor en tilføjet pause ikke er en parathedskontrol

En pause forsinker scriptet og flytter kapløbsvinduet. På en hurtig dag lykkes opgaven; på en langsom dag fejler den igen, og fejlen bliver sværere at reproducere, fordi forsinkelsen ser ud til at virke. En forsinkelse, der kun virker under let belastning, er et tilfælde, ikke en løsning.

Hvis afhængigheden er en rute, brug den krog, der svarer til ruteinstallation. Hvis afhængigheden er en tjeneste bag tunnelen, brug en afgrænset kontrol, der venter på netop den betingelse og fejler tydeligt, når den aldrig indtræffer.

Hold fejlen eksplicit. En krog, der afslutter med nul, mens dens faktiske arbejde fejlede, er værre end en krog, der fejler, fordi serviceadministratoren registrerer en succes, og ingen kigger igen. En loglinje fra scriptet selv er den billigste måde at holde det ærligt.

Oprydning og genopkobling fortjener samme omhu

Et script, der ændrer delt tilstand, har brug for en tilsvarende fortrydelsesvej. Ruter, resolverposter og firewallmarkeringer, som en krog tilføjer, skal være idempotente og reversible, ellers vil en genopkobling stable en anden kopi oven på den første.

Genopkoblinger kan også køre kroge oftere end en fuld servicestart. En vedvarende grænseflade, der genopretter en session, kan udløse up- og route-up-cyklussen igen, så et script, der antager én kørsel per opstart, vil til sidst opføre sig forkert. Tæl kørslerne i loggen over en dag med flapping for at se, hvor ofte det faktisk kører. Gør derefter scriptet sikkert at køre så mange gange.

Test den livscyklus, der fejlede, ikke en senere kommando. Reproducer opstarten eller genopkoblingen, se krogen køre, og bekræft, at opgaven lykkedes i det øjeblik, den faktisk kører. En succes fra en interaktiv shell bagefter er evidens om afhængigheden, ikke bevis for, at opstartsvejen virker.

Navngiv den hændelse, som hver opgave afhænger af, og knyt den derefter til den hændelse. Alt andet er en forsinkelse, der foregiver at være en kontrol.