Liep het up-script van OpenVPN te vroeg, of was het nooit klaar?

Het up-script wordt uitgevoerd, eindigt met nul, en de taak erin bereikt geen privédienst die twee seconden later vanaf een terminal perfect werkt. Het instinct zegt timing, en de gebruikelijke reparatie is een slaap, die de race verbergt zonder hem te begrijpen. De nuttiger lezing is dat “up” een hook aanduidt, geen gereedheidsgarantie. Hij wordt geactiveerd wanneer het tunnelapparaat is geconfigureerd, wat eerder is dan routes, DNS en zeker eerder dan welke applicatie dan ook achter de tunnel.

De shelltest slaagde omdat hij liep nadat alles tot rust was gekomen. De hook liep op één specifiek moment.

Waar up staat in de opstartvolgorde

OpenVPN configureert het tunnelapparaat en voert daarna de up-hook uit. Route-installatie is een latere fase, en die heeft zijn eigen hook, daarom kan een routeafhankelijke taak in up een apparaat zien zonder bruikbaar pad. Zet routewerk in route-up en het timingprobleem verdwijnt meestal.

De handleiding documenteert deze volgorde en de omgeving die elke hook ontvangt. Die volgorde is de volledige verklaring voor het klassieke rapport “werkt vanuit mijn shell”, en het is ook de reden waarom hetzelfde script op de ene machine slaagt en op een andere met een tragere routefase faalt. Geen van beide resultaten zegt iets over de kwaliteit van het script.

DNS en applicatiegereedheid komen nog later. Zelfs geïnstalleerde routes zijn geen bewijs dat het verre eindpunt luistert, dat een naam wordt opgelost, of dat er een desktopsessie bestaat voor een taak met gebruikersbereik.

Wat de hook werkelijk erft

Een hook draait onder het account en de omgeving van het OpenVPN-proces, wat niet hetzelfde is als je interactieve shell. Het kan een sessiebus van een gebruiker, een desktopomgeving of een referentie ontbreken die alleen bij het inloggen wordt ontgrendeld. Schrijf op welke daarvan de taak echt nodig heeft.

Dat is belangrijk voor taken die op netwerken lijken maar van een gebruikerscontext afhangen: een share koppelen met een gebruikersreferentie, een proxy per gebruiker instellen of een printer configureren. Een geprivilegieerde tunnelhook is daar de verkeerde plek voor, en geen enkele hoeveelheid wachten lost een ontbrekende sessie op.

Wanneer een taak in een hook mislukt, noteer dan het account, de omgeving en de eerste bewerking die mislukte. Dat scheidt voortijdige timing van een rechten- of contextprobleem, en de twee hebben volledig verschillende reparaties. Gissen tussen beide is hoe een reparatie van vijf minuten een hele middag wordt.

Waarom een slaap toevoegen geen gereedheidscontrole is

Een slaap vertraagt het script en verschuift het racevenster. Op een snelle dag slaagt de taak; op een trage dag faalt hij weer, en de fout wordt moeilijker te reproduceren omdat de vertraging lijkt te werken. Een vertraging die alleen onder lichte belasting werkt, is toeval, geen reparatie.

Als de afhankelijkheid een route is, gebruik dan de hook die bij route-installatie hoort. Als de afhankelijkheid een dienst achter de tunnel is, gebruik dan een begrensde controle die op die specifieke voorwaarde wacht en duidelijk faalt wanneer die nooit komt.

Houd de fout expliciet. Een hook die met nul eindigt terwijl het echte werk faalde, is erger dan een hook die faalt, omdat de servicemanager een succes registreert en niemand meer kijkt. Eén logregel uit het script zelf is de goedkoopste manier om dat eerlijk te houden.

Opruimen en opnieuw verbinden verdienen dezelfde zorg

Een script dat gedeelde status wijzigt, heeft een bijpassend ongedaanmakingspad nodig. Routes, resolver-items en firewallmarkeringen die een hook toevoegt, moeten idempotent en omkeerbaar zijn, anders stapelt een herverbinding een tweede kopie op de eerste.

Herverbindingen kunnen hooks ook vaker uitvoeren dan een volledige servicestart. Een persistent interface dat een sessie opnieuw tot stand brengt, kan de up- en route-up-cyclus opnieuw activeren, dus een script dat één uitvoering per boot aanneemt, gaat zich uiteindelijk misdragen. Tel de uitvoeringen in het logboek gedurende een dag van flapperen om te zien hoe vaak het echt draait. Maak het script daarna veilig om zo vaak te draaien.

Test de levenscyclus die faalde, niet een latere opdracht. Reproduceer de boot of de herverbinding, kijk hoe de hook wordt uitgevoerd, en bevestig dat de taak slaagde op het moment dat hij echt draait. Een succes uit een interactieve shell daarna is bewijs over de afhankelijkheid, niet het bewijs dat het opstartpad werkt.

Noem de gebeurtenis waarvan elke taak afhangt, en koppel de taak aan die gebeurtenis. Al het andere is een vertraging die zich voordoet als een controle.