Ĉu la up-skripto de OpenVPN ruliĝis tro frue, aŭ ĉu ĝi neniam estis preta?

La up-skripto ruliĝas, eliras kun nulo, kaj la tasko ene ĝi malsukcesas atingi privatan servon, kiu du sekundojn poste perfekte funkcias el terminalo. La instinkto estas tempigo, kaj la kutima riparo estas paŭzo, kiu kaŝas la konkurson sen kompreni ĝin. La pli utila legado estas, ke “up” nomas hokon, ne garantion de pretigo. Ĝi ekfunkcias kiam la tunela aparato estas agordita, kio estas pli frue ol vojoj, DNS kaj certe pli frue ol ajna aplikaĵo malantaŭ la tunelo.

La ŝela testo sukcesis ĉar ĝi ruliĝis post kiam ĉio stabiliĝis. La hoko ruliĝis en unu specifa momento.

Kie up situas en la ekstarta ordo

OpenVPN agordas la tunelan aparaton kaj poste rulas la up-hokon. Instalo de vojoj estas pli malfrua etapo, kaj ĝi havas sian propran hokon, kio klarigas, kial vojdependa tasko metita en up povas vidi aparaton sen utila vojo. Metu vojajn laborojn en route-up kaj la tempiga problemo kutime malaperas.

La manlibro dokumentas ĉi tiun ordon kaj la medion, kiun ĉiu hoko ricevas. Tiu ordo estas la tuta klarigo de la klasika raporto “ĝi funkcias el mia ŝelo”, kaj ĝi ankaŭ estas kial la sama skripto povas sukcesi sur unu maŝino kaj malsukcesi sur alia kun pli malrapida voja etapo. Neniu el la du rezultoj diras ion pri la kvalito de la skripto.

Pretigo de DNS kaj aplikaĵoj venas eĉ pli malfrue. Eĉ instalitaj vojoj ne estas pruvo, ke la malproksima finpunkto aŭskultas, ke nomo solviĝas, aŭ ke ekzistas labortabla seanco por tasko limigita al uzanto.

Kion la hoko fakte heredas

Hoko ruliĝas sub la konto kaj medio de la OpenVPN-procezo, kio ne estas la sama kiel via interaga ŝelo. Ĝi povas manki al ĝi uzanta seanco-buso, labortabla medio aŭ legitimilo, kiu malŝlosiĝas nur ĉe ensaluto. Notu, kiujn el tiuj la tasko fakte bezonas.

Tio gravas por taskoj, kiuj aspektas retaj sed dependas de uzanta kunteksto: munti kunigitan rimedon per uzanta legitimilo, agordi prokurilon por ĉiu uzanto aŭ agordi printilon. Privilegia tunela hoko estas la malĝusta loko por ili, kaj neniu kvanto da atendo riparas mankan seancon.

Kiam tasko malsukcesas en hoko, notu la konton, la medion kaj la unuan operacion, kiu malsukcesis. Tio apartigas antaŭtempan tempigon de permesa aŭ kunteksta problemo, kaj la du havas tute malsamajn riparojn. Diveni inter ili estas kiel kvinminuta riparo fariĝas tuta posttagmezo.

Kial aldoni paŭzon ne estas pretiga kontrolo

Paŭzo prokrastas la skripton kaj movas la konkursan fenestron. En rapida tago la tasko sukcesas; en malrapida tago ĝi denove malsukcesas, kaj la malsukceso fariĝas pli malfacile ripetebla ĉar la prokrasto ŝajne funkcias. Prokrasto, kiu funkcias nur sub malpeza ŝarĝo, estas hazardo, ne riparo.

Se la dependaĵo estas vojo, uzu la hokon, kiu respondas al voja instalo. Se la dependaĵo estas servo malantaŭ la tunelo, uzu limigitan kontrolon, kiu atendas tiun specifan kondiĉon kaj klare malsukcesas kiam ĝi neniam alvenas.

Tenu la malsukceson eksplicita. Hoko, kiu eliras kun nulo dum ĝia fakta laboro malsukcesis, estas pli malbona ol hoko, kiu malsukcesas, ĉar la servadministranto registras sukceson kaj neniu plu rigardas. Protokola linio el la skripto mem estas la plej malmultekosta maniero teni tion honesta.

Purigado kaj rekonekto meritas la saman zorgon

Skripto, kiu ŝanĝas kunhavatan staton, bezonas respondan malfaran vojon. Vojoj, solvilo-ensurĵetoj kaj fajroŝirmaj markoj aldonitaj de hoko devus esti idempotentaj kaj reigeblaj, alie rekonekto stakigos duan kopion sur la unuan.

Rekonektoj ankaŭ povas ruli hokojn pli ofte ol plena serva ekstarto. Daŭra interfaco, kiu reestablas seancon, povas denove ekigi la ciklon up kaj route-up, do skripto, kiu supozas unu plenumon por ekstarto, iam miskondutos. Kalkulu la plenumojn en la protokolo dum tago de flirtado por vidi, kiel ofte ĝi vere ruliĝas. Poste faru la skripton sekura por ruliĝi tiom da fojoj.

Testu la vivciklon, kiu malsukcesis, ne pli malfruan komandon. Riproduktu la ekstarton aŭ la rekonekton, observu la hokon plenumiĝi, kaj konfirmu, ke la tasko sukcesis en la momento, kiam ĝi vere ruliĝas. Sukceso el interaga ŝelo poste estas pruvo pri la dependaĵo, ne pruvo, ke la ekstarta vojo funkcias.

Nomu la eventon, de kiu ĉiu tasko dependas, poste alligu ĝin al tiu evento. Ĉio alia estas prokrasto, kiu ŝajnigas esti kontrolo.