Käynnistyikö OpenVPN:n up-skripti liian aikaisin, vai eikö se ollut koskaan valmis?
up-koukku käynnistyy, kun tunnelilaite ilmestyy, ennen reittejä ja sovellusten valmiutta. Sovita skripti tapahtumaan, jonka se tarvitsee, sen sijaan että lisäät odotuksen.
up-skripti käynnistyy, poistuu nollalla, ja sen sisällä oleva tehtävä ei tavoita yksityistä palvelua, joka kaksi sekuntia myöhemmin toimii täydellisesti päätteestä. Vaisto sanoo ajoitus, ja tavallinen korjaus on odotus, joka piilottaa kilpailun ymmärtämättä sitä. Hyödyllisempi tulkinta on, että “up” nimeää koukun, ei valmiuden takeen. Se laukeaa, kun tunnelilaite konfiguroidaan, mikä on aikaisemmin kuin reitit, DNS ja varmasti aikaisemmin kuin mikään sovellus tunnelin takana.
Kuoren testi onnistui, koska se ajettiin sen jälkeen, kun kaikki oli asettunut. Koukku ajettiin yhtenä tiettynä hetkenä.
Missä up on käynnistysjärjestyksessä
OpenVPN konfiguroi tunnelilaitteen ja ajaa sitten up-koukun. Reittien asennus on myöhempi vaihe, ja sillä on oma koukkunsa, minkä vuoksi up-vaiheeseen sijoitettu reitistä riippuva tehtävä voi nähdä laitteen ilman käyttökelpoista polkua. Sijoita reittityö route-up-vaiheeseen, ja ajoitusongelma yleensä katoaa.
Käsikirja dokumentoi tämän järjestyksen ja ympäristön, jonka kukin koukku saa. Tämä järjestys on koko selitys klassiselle raportille “toimii minun kuorestani”, ja se on myös syy, miksi sama skripti voi mennä läpi yhdellä koneella ja epäonnistua toisella hitaamman reittivaiheen kanssa. Kumpikaan tulos ei kerro mitään skriptin laadusta.
DNS:n ja sovellusten valmius tulee vielä myöhemmin. Edes asennetut reitit eivät ole todiste siitä, että kaukopää kuuntelee, että nimi ratkeaa tai että käyttäjään sidotulle tehtävälle on olemassa työpöytäistunto.
Mitä koukku todella perii
Koukku ajetaan OpenVPN-prosessin tilin ja ympäristön alla, mikä ei ole sama kuin interaktiivinen kuoresi. Siltä voi puuttua käyttäjän istuntoväylä, työpöytäympäristö tai kirjautumistieto, joka avataan vasta kirjautumisen yhteydessä. Kirjoita muistiin, mitä näistä tehtävä todella tarvitsee.
Tällä on väliä tehtäville, jotka näyttävät verkkotehtäviltä mutta riippuvat käyttäjäkontekstista: jaetun resurssin liittäminen käyttäjän kirjautumistiedolla, käyttäjäkohtaisen välityspalvelimen asettaminen tai tulostimen konfiguroiminen. Etuoikeutettu tunnelikoukku on niille väärä paikka, eikä mikään määrä odottamista korjaa puuttuvaa istuntoa.
Kun tehtävä epäonnistuu koukussa, kirjaa tili, ympäristö ja ensimmäinen epäonnistunut toiminto. Tämä erottaa ennenaikaisen ajoituksen käyttöoikeus- tai kontekstiongelmasta, ja kahdella on täysin erilaiset korjaukset. Niiden välillä arvaaminen on se, miten viiden minuutin korjauksesta tulee koko iltapäivä.
Miksi odotuksen lisääminen ei ole valmiustarkistus
Odotus viivästyttää skriptiä ja siirtää kilpailun ikkunaa. Nopeana päivänä tehtävä onnistuu; hitaana päivänä se epäonnistuu taas, ja vika on vaikeampi toistaa, koska viive näyttää toimivan. Viive, joka toimii vain kevyellä kuormituksella, on sattuma, ei korjaus.
Jos riippuvuus on reitti, käytä koukkua, joka vastaa reitin asennusta. Jos riippuvuus on palvelu tunnelin takana, käytä rajattua tarkistusta, joka odottaa juuri sitä ehtoa ja epäonnistuu selvästi, kun se ei koskaan saavu.
Pidä vika eksplisiittisenä. Koukku, joka poistuu nollalla, vaikka sen varsinainen työ epäonnistui, on pahempi kuin epäonnistuva koukku, koska palvelunhallinta kirjaa onnistumisen eikä kukaan katso uudelleen. Lokirivi skriptistä itsestään on halvin tapa pitää se rehellisenä.
Siivous ja uudelleenyhdistäminen ansaitsevat saman huolen
Skripti, joka muuttaa jaettua tilaa, tarvitsee vastaavan peruutuspolun. Koukun lisäämien reittien, ratkaisijan merkintöjen ja palomuurimerkintöjen tulisi olla idempotentteja ja peruttavissa, muuten uudelleenyhdistäminen kasaa toisen kopion ensimmäisen päälle.
Uudelleenyhdistämiset voivat myös ajaa koukkuja useammin kuin täysi palvelun käynnistys. Pysyvä käyttöliittymä, joka palauttaa istunnon, voi laukaista up- ja route-up-syklin uudelleen, joten skripti, joka olettaa yhden suorituksen käynnistystä kohden, alkaa lopulta käyttäytyä väärin. Laske suoritukset lokista yhden lepatuspäivän ajalta nähdäksesi, kuinka usein se todella ajetaan. Tee skriptistä sitten turvallinen niin moneen suoritukseen.
Testaa epäonnistunutta elinkaarta, älä myöhempää komentoa. Toista käynnistys tai uudelleenyhdistäminen, seuraa koukun suoritusta ja varmista, että tehtävä onnistui hetkellä, jolloin se todella ajetaan. Myöhempi menestys interaktiivisesta kuoresta on todiste riippuvuudesta, ei todiste siitä, että käynnistyspolku toimii.
Nimeä tapahtuma, josta kukin tehtävä riippuu, ja kiinnitä se sitten siihen tapahtumaan. Kaikki muu on viive, joka teeskentelee olevansa tarkistus.