Het die OpenVPN-up-skrip te vroeg geloop, of was dit nooit gereed nie?
Die up-haak loop wanneer die tonneltoestel verskyn, voor roetes en toepassingsgereedheid. Pas die skrip by die gebeurtenis wat dit nodig het in plaas daarvan om ’n slaap by te voeg.
Die up-skrip loop, keer met nul terug, en die taak daarin slaag nie daarin om ’n private diens te bereik wat twee sekondes later perfek vanuit ’n terminaal werk nie. Die instink is tydsberekening, en die gewone herstelling is ’n slaap, wat die wedloop verberg sonder om dit te verstaan. Die nuttiger lesing is dat “up” ’n haak naam, nie ’n waarborg van gereedheid nie. Dit vuur wanneer die tonneltoestel gekonfigureer word, wat vroeër is as roetes, DNS, en beslis vroeër as enige toepassing agter die tonnel.
Die skeltoets het geslaag omdat dit geloop het nadat alles tot rus gekom het. Die haak het op een spesifieke oomblik geloop.
Waar up in die opstartorde staan
OpenVPN konfigureer die tonneltoestel en loop dan die up-haak. Roete-installasie is ’n latere stadium, en dit het sy eie haak, daarom kan ’n roete-afhanklike taak wat in up geplaas is, ’n toestel sien sonder ’n bruikbare pad. Plaas roetewerk in route-up en die tydsberekeningprobleem verdwyn gewoonlik.
Die handleiding dokumenteer hierdie orde en die omgewing wat elke haak ontvang. Daardie orde is die hele verklaring vir die klassieke verslag “dit werk van my skel af”, en dit is ook waarom dieselfde skrip op een masjien kan slaag en op ’n ander met ’n stadiger roetestadium kan misluk. Nie een van die twee resultate sê iets oor die kwaliteit van die skrip nie.
DNS en toepassingsgereedheid kom nog later. Selfs geïnstalleerde roetes is nie ’n bewys dat die verre eindpunt luister, dat ’n naam oplos, of dat ’n lessenaarsessie bestaan vir ’n taak wat aan ’n gebruiker gekoppel is nie.
Wat die haak eintlik oorneem
’n Haak loop onder die rekening en omgewing van die OpenVPN-proses, wat nie dieselfde is as jou interaktiewe skel nie. Dit kan ’n gebruiker se sessiebus, ’n lessenaaromgewing of ’n geloofsbrief mis wat slegs by aanmelding ontsluit word. Skryf neer watter van dié dinge die taak werklik nodig het.
Dit maak saak vir take wat soos netwerkwerk lyk maar van ’n gebruikerskonteks afhanklik is: ’n deel te monteer met ’n gebruiker se geloofsbrief, ’n per-gebruiker-volmag in te stel, of ’n drukker te konfigureer. ’n Bevoorregte tonnelhaak is die verkeerde plek daarvoor, en geen hoeveelheid wag maak ’n ontbrekende sessie reg nie.
Wanneer ’n taak in ’n haak misluk, teken die rekening, die omgewing en die eerste bewerking wat misluk het aan. Dit skei voortydige tydsberekening van ’n toestemmings- of konteksprobleem, en die twee het heeltemal verskillende herstellings. Om tussen hulle te raai is hoe ’n vyfminuut-herstel ’n middag word.
Waarom ’n slaap byvoeg nie ’n gereedheidstoets is nie
’n Slaap vertraag die skrip en verskuif die wedloopvenster. Op ’n vinnige dag slaag die taak; op ’n stadige dag misluk dit weer, en die mislukking word moeiliker om te reproduseer omdat die vertraging skynbaar werk. ’n Vertraging wat net onder ligte las werk, is ’n toeval, nie ’n herstelling nie.
As die afhanklikheid ’n roete is, gebruik die haak wat met roete-installasie ooreenstem. As die afhanklikheid ’n diens agter die tonnel is, gebruik ’n begrensde toets wat vir daardie spesifieke toestand wag en duidelik misluk wanneer dit nooit arriveer nie.
Hou die mislukking eksplisiet. ’n Haak wat met nul terugkeer terwyl sy werklike werk misluk het, is erger as ’n haak wat misluk, want die diensbestuurder teken ’n sukses aan en niemand kyk weer nie. ’n Logreël uit die skrip self is die goedkoopste manier om dit eerlik te hou.
Opruiming en herverbinding verdien dieselfde sorg
’n Skrip wat gedeelde toestand verander, het ’n passende ontdopad nodig. Roetes, oplosser-inskrywings en brandmuurmerke wat deur ’n haak bygevoeg word, moet idempotent en omkeerbaar wees, of ’n herverbinding sal ’n tweede kopie bo-op die eerste stapel.
Herverbindings kan ook hakies meer dikwels as ’n volle diensbegin laat loop. ’n Permanente koppelvlak wat ’n sessie weer vestig, kan die up- en route-up-siklus weer aktiveer, so ’n skrip wat een uitvoering per opstart aanvaar, sal uiteindelik verkeerd optree. Tel die uitvoerings in die log oor ’n dag van fladder om te sien hoe dikwels dit werklik loop. Maak die skrip dan veilig om so dikwels te loop.
Toets die lewensiklus wat misluk het, nie ’n latere opdrag nie. Reproduceer die opstart of die herverbinding, kyk hoe die haak uitvoer, en bevestig dat die taak geslaag het op die oomblik dat dit werklik loop. ’n Sukses uit ’n interaktiewe skel daarna is bewyse oor die afhanklikheid, nie ’n bewys dat die opstartpad werk nie.
Noem die gebeurtenis waarvan elke taak afhanklik is, en heg dit dan aan daardie gebeurtenis. Alles anders is ’n vertraging wat voorgee om ’n toets te wees.