Ar OpenVPN „up“ scenarijus buvo paleistas per anksti, ar jis niekada nebuvo pasiruošęs?

„up“ scenarijus paleidžiamas, baigia su nuliu, o jo viduje esanti užduotis negali pasiekti privataus serviso, kuris iš terminalo po dviejų sekundžių veikia nepriekaištingai. Instinktas sako, kad tai laikas, o įprastas taisymas – miegas, kuris paslepia lenktynes jų nesupratus. Naudingesnis skaitymas – „up“ yra kabliuko pavadinimas, o ne pasirengimo garantija. Jis suveikia, kai sukonfigūruojamas tunelio įrenginys, o tai yra anksčiau už maršrutus, DNS ir tikrai anksčiau už bet kurią programą už tunelio.

Apvalkalo testas pavyko todėl, kad buvo paleistas po to, kai viskas nusistovėjo. Kabliukas buvo paleistas vienu konkrečiu momentu.

Kur up yra paleidimo tvarkoje

OpenVPN sukonfigūruoja tunelio įrenginį ir tada paleidžia „up“ kabliuką. Maršrutų diegimas yra vėlesnis etapas ir turi savo kabliuką, todėl nuo maršrutų priklausanti užduotis, įdėta į „up“, gali matyti įrenginį be naudingo kelio. Įdėkite maršrutų darbą į „route-up“, ir laiko problema paprastai išnyksta.

Vadove dokumentuojama ši tvarka ir aplinka, kurią gauna kiekvienas kabliukas. Ši tvarka yra visas paaiškinimas klasikinio pranešimo „veikia iš mano apvalkalo“, ir ji taip pat paaiškina, kodėl tas pats scenarijus gali praeiti viename kompiuteryje ir nepraeiti kitame su lėtesniu maršrutų etapu. Nė vienas rezultatas nieko nesako apie scenarijaus kokybę.

DNS ir programos pasirengimas ateina dar vėliau. Net įdiegti maršrutai nėra įrodymas, kad tolimasis taškas klausosi, kad vardas išsprendžiamas arba kad egzistuoja darbalaukio sesija su naudotoju susietai užduočiai.

Ką kabliukas iš tikrųjų paveldi

Kabliukas paleidžiamas OpenVPN proceso paskyroje ir aplinkoje, kuri nėra tokia pati kaip jūsų interaktyvus apvalkalas. Jam gali trūkti naudotojo sesijos magistralės, darbalaukio aplinkos arba kredencialo, kuris atrakinamas tik prisijungus. Užsirašykite, kurių iš jų užduočiai iš tikrųjų reikia.

Tai svarbu užduotims, kurios atrodo kaip tinklo, bet priklauso nuo naudotojo konteksto: prijungti bendrinamą aplanką su naudotojo kredencialu, nustatyti atskiro naudotojo tarpinį serverį arba sukonfigūruoti spausdintuvą. Privilegijuotas tunelio kabliukas jiems yra netinkama vieta, ir joks laukimas nepataisys trūkstamos sesijos.

Kai užduotis nepavyksta kabliuke, užrašykite paskyrą, aplinką ir pirmąją nepavykusią operaciją. Tai atskiria per ankstyvą laiką nuo leidimų ar konteksto problemos, o šių dviejų taisymai visiškai skiriasi. Spėliojimas tarp jų – tai kelias, kuriuo penkių minučių taisymas tampa visu popietė.

Kodėl miego pridėjimas nėra pasirengimo patikra

Miegas atitolina scenarijų ir perstumia lenktynių langą. Greitą dieną užduotis pavyksta; lėtą dieną ji vėl nepavyksta, o gedimą tampa sunkiau atkurti, nes atrodo, kad vėlinimas veikia. Vėlinimas, kuris veikia tik esant nedideliam krūviui, yra atsitiktinumas, o ne taisymas.

Jei priklausomybė yra maršrutas, naudokite kabliuką, atitinkantį maršrutų diegimą. Jei priklausomybė yra servisas už tunelio, naudokite apribotą patikrą, kuri laukia tos konkrečios sąlygos ir aiškiai nepavyksta, kai ji niekada neateina.

Išlaikykite gedimą aiškų. Kabliukas, kuris baigia su nuliu, nors jo tikrasis darbas nepavyko, yra blogesnis už kabliuką, kuris nepavyksta, nes paslaugų tvarkytuvė įrašo sėkmę ir niekas daugiau nebežiūri. Viena žurnalo eilutė iš paties scenarijaus yra pigiausias būdas išlaikyti tai sąžininga.

Valymas ir prisijungimas iš naujo nusipelno tokio pat rūpesčio

Scenarijus, kuris keičia bendrą būseną, turi turėti atitinkamą atšaukimo kelią. Kabliuko pridėti maršrutai, resolverio įrašai ir ugniasienės žymės turėtų būti idempotentiški ir atšaukiami, kitaip prisijungimas iš naujo uždės antrą kopiją ant pirmosios.

Prisijungimai iš naujo taip pat gali paleisti kabliukus dažniau nei visas paslaugos paleidimas. Nuolatinė sąsaja, kuri vėl nustato sesiją, gali dar kartą suaktyvinti „up“ ir „route-up“ ciklą, todėl scenarijus, kuris numato vieną vykdymą per įkrovimą, ilgainiui veiks netinkamai. Suskaičiuokite vykdymus žurnale per dieną svyravimų, kad pamatytumėte, kaip dažnai jis iš tikrųjų paleidžiamas. Tada padarykite scenarijų saugų paleisti tiek kartų.

Testuokite tą gyvavimo ciklą, kuris nepavyko, o ne vėlesnę komandą. Atkurkite įkrovimą arba prisijungimą iš naujo, stebėkite, kaip vykdomas kabliukas, ir patvirtinkite, kad užduotis pavyko tuo momentu, kai ji iš tikrųjų paleidžiama. Sėkmė iš interaktyvaus apvalkalo po to yra įrodymas apie priklausomybę, o ne įrodymas, kad paleidimo kelias veikia.

Pavadinkite įvykį, nuo kurio priklauso kiekviena užduotis, ir prijunkite ją prie to įvykio. Visa kita yra vėlinimas, apsimetantis patikra.