Túl korán futott az OpenVPN up-szkriptje, vagy soha nem volt készen?

Az up-szkript lefut, nullával lép ki, és a benne lévő feladat nem éri el azt a privát szolgáltatást, amely két másodperccel később tökéletesen működik egy terminálból. Az ösztön az időzítés, a szokásos javítás pedig egy alvás, amely elrejti a versenyt anélkül, hogy megértené. A hasznosabb olvasat az, hogy az „up” egy horgot nevez meg, nem a készség garanciáját. Akkor lép működésbe, amikor az alagút-eszköz konfigurálódik, ami korábbi az útvonalaknál, a DNS-nél és biztosan korábbi bármely alkalmazásnál az alagút mögött.

A héjteszt azért sikerült, mert minden leülepedése után futott. A horog egyetlen konkrét pillanatban futott.

Hol áll az up az indítási sorrendben

OpenVPN konfigurálja az alagút-eszközt, majd lefuttatja az up horgot. Az útvonalak telepítése későbbi szakasz, és saját horga van, ezért az up-ba helyezett útvonalfüggő feladat láthat olyan eszközt, amelynek nincs használható útja. Tegye az útvonal-munkát a route-up-ba, és az időzítési probléma általában eltűnik.

A kézikönyv dokumentálja ezt a sorrendet és azt a környezetet, amelyet minden horog kap. Ez a sorrend a klasszikus „a saját parancshéjamból működik” jelentés teljes magyarázata, és ez az oka annak is, hogy ugyanaz a szkript átmehet az egyik gépen, és elbukhat egy másikon lassabb útvonalszakasszal. Egyik eredmény sem mond semmit a szkript minőségéről.

A DNS és az alkalmazások készsége még később jön. Még a telepített útvonalak sem bizonyítják, hogy a távoli végpont figyel, hogy egy név feloldódik, vagy hogy létezik asztali munkamenet egy felhasználóhoz kötött feladathoz.

Mit örököl valójában a horog

A horog az OpenVPN-folyamat fiókja és környezete alatt fut, ami nem ugyanaz, mint a te interaktív parancshéjad. Hiányozhat neki a felhasználói munkamenet-busz, az asztali környezet vagy egy hitelesítő adat, amely csak bejelentkezéskor oldódik fel. Írja le, melyikre van a feladatnak valóban szüksége.

Ez olyan feladatoknál számít, amelyek hálózatinak tűnnek, de felhasználói környezettől függenek: megosztás csatolása felhasználói hitelesítő adattal, felhasználónkénti proxy beállítása vagy nyomtató konfigurálása. A kiemelt alagút-horog rossz hely ezeknek, és semmilyen mennyiségű várakozás nem javítja a hiányzó munkamenetet.

Amikor egy feladat elbukik egy horogban, jegyezze fel a fiókot, a környezetet és az első sikertelen műveletet. Ez elválasztja az idő előtti időzítést az engedély- vagy környezeti problémától, és a kettőnek teljesen más a javítása. A kettő közötti találgatás az, ahogy egy ötperces javítás egy egész délutánná válik.

Miért nem készség-ellenőrzés egy hozzáadott alvás

Az alvás késlelteti a szkriptet és eltolja a versenyablakot. Egy gyors napon a feladat sikerül; egy lassú napon újra elbukik, és a hiba nehezebben reprodukálható, mert a késleltetés működni látszik. Az a késleltetés, amely csak könnyű terhelés alatt működik, véletlen, nem javítás.

Ha a függőség útvonal, használja az útvonal-telepítésnek megfelelő horgot. Ha a függőség az alagút mögötti szolgáltatás, használjon korlátozott ellenőrzést, amely arra a konkrét feltételre vár, és egyértelműen elbukik, amikor az soha nem érkezik meg.

Tartsa a hibát explicitnek. Egy horog, amely nullával lép ki, miközben a tényleges munkája elbukott, rosszabb, mint egy elbukó horog, mert a szolgáltatáskezelő sikert rögzít, és senki sem néz oda újra. Egy naplósor magából a szkriptből a legolcsóbb módja annak, hogy ez őszinte maradjon.

A tisztítás és az újracsatlakozás ugyanazt a gondosságot érdemli

Egy szkript, amely megosztott állapotot változtat, megfelelő visszavonási útvonalat igényel. A horog által hozzáadott útvonalaknak, feloldó bejegyzéseknek és tűzfaljelöléseknek idempotensnek és visszafordíthatónak kell lenniük, különben egy újracsatlakozás egy második példányt halmoz az elsőre.

Az újracsatlakozások gyakrabban is futtathatják a horgokat, mint egy teljes szolgáltatásindítás. Egy állandó interfész, amely újra létrehoz egy munkamenetet, ismét kiválthatja az up és route-up ciklust, ezért egy szkript, amely indításonként egy futást feltételez, végül hibásan fog viselkedni. Számolja meg a futásokat a naplóban egy napnyi lengés alatt, hogy lássa, milyen gyakran fut valójában. Utána tegye a szkriptet biztonságossá ennyi futásra.

Tesztelje azt az életciklust, amely elbukott, ne egy későbbi parancsot. Reprodukálja az indítást vagy az újracsatlakozást, figyelje a horog futását, és erősítse meg, hogy a feladat abban a pillanatban sikerült, amikor valóban fut. Egy későbbi siker interaktív parancshéjból bizonyíték a függőségről, nem bizonyíték arra, hogy az indítási útvonal működik.

Nevezze meg azt az eseményt, amelytől minden feladat függ, majd kapcsolja ahhoz az eseményhez. Minden más késleltetés, amely ellenőrzésnek tetteti magát.