Scriptul up al OpenVPN a rulat prea devreme sau nu a fost niciodată pregătit?

Scriptul up rulează, iese cu zero, iar sarcina din el nu ajunge la un serviciu privat care, dintr-un terminal, funcționează perfect două secunde mai târziu. Instinctul spune că e vorba de sincronizare, iar reparația obișnuită este o pauză, care ascunde cursa fără să o înțeleagă. Citirea mai utilă este că “up” numește un cârlig, nu o garanție de pregătire. Se declanșează când dispozitivul tunelului este configurat, ceea ce este mai devreme decât rutele, DNS-ul și cu siguranță mai devreme decât orice aplicație din spatele tunelului.

Testul din shell a reușit pentru că a rulat după ce totul s-a așezat. Cârligul a rulat într-un singur moment anume.

Unde se află up în ordinea de pornire

OpenVPN configurează dispozitivul tunelului și apoi rulează cârligul up. Instalarea rutelor este o etapă ulterioară și are propriul cârlig, de aceea o sarcină dependentă de rute plasată în up poate vedea un dispozitiv fără o cale utilă. Pune munca de rutare în route-up și problema de sincronizare dispare de obicei.

Manualul documentează această ordine și mediul pe care îl primește fiecare cârlig. Acea ordine este întreaga explicație pentru raportul clasic “funcționează din shell-ul meu”, și tot ea este motivul pentru care același script poate trece pe o mașină și poate eșua pe alta cu o etapă de rute mai lentă. Niciunul dintre rezultate nu spune nimic despre calitatea scriptului.

DNS-ul și pregătirea aplicațiilor vin și mai târziu. Nici măcar rutele instalate nu sunt dovada că punctul final îndepărtat ascultă, că un nume se rezolvă sau că există o sesiune desktop pentru o sarcină la nivel de utilizator.

Ce moștenește de fapt cârligul

Un cârlig rulează sub contul și mediul procesului OpenVPN, ceea ce nu este același lucru cu shell-ul tău interactiv. Poate să îi lipsească magistrala de sesiune a utilizatorului, un mediu desktop sau o acreditare care se deblochează doar la autentificare. Notează care dintre acestea îi trebuie de fapt sarcinii.

Asta contează pentru sarcinile care par de rețea dar depind de un context de utilizator: montarea unei partajări cu o acreditare de utilizator, setarea unui proxy pe utilizator sau configurarea unei imprimante. Un cârlig de tunel privilegiat este locul greșit pentru ele, iar nicio așteptare nu repară o sesiune lipsă.

Când o sarcină eșuează într-un cârlig, notează contul, mediul și prima operație care a eșuat. Asta separă sincronizarea prematură de o problemă de permisiuni sau context, iar cele două au reparații complet diferite. Ghicitul între ele este felul în care o reparație de cinci minute devine o după-amiază întreagă.

De ce adăugarea unei pauze nu este o verificare de pregătire

O pauză întârzie scriptul și mută fereastra cursei. Într-o zi rapidă sarcina reușește; într-o zi lentă eșuează din nou, iar eșecul devine mai greu de reprodus pentru că întârzierea pare să funcționeze. O întârziere care funcționează doar sub încărcare ușoară este o coincidență, nu o reparație.

Dacă dependența este o rută, folosește cârligul care corespunde instalării rutelor. Dacă dependența este un serviciu din spatele tunelului, folosește o verificare limitată care așteaptă acea condiție specifică și eșuează clar când nu apare niciodată.

Păstrează eșecul explicit. Un cârlig care iese cu zero în timp ce munca lui reală a eșuat este mai rău decât un cârlig care eșuează, pentru că managerul de servicii înregistrează un succes și nimeni nu se mai uită. O linie de log din chiar scriptul este cel mai ieftin mod de a păstra asta onest.

Curățarea și reconectarea merită aceeași grijă

Un script care schimbă stare partajată are nevoie de o cale de anulare potrivită. Rutele, intrările resolverului și marcajele de firewall adăugate de un cârlig ar trebui să fie idempotente și reversibile, altfel o reconectare va stivui o a doua copie peste prima.

Reconectările pot rula cârligele mai des decât o pornire completă a serviciului. O interfață persistentă care restabilește o sesiune poate declanșa din nou ciclul up și route-up, așa că un script care presupune o singură execuție pe boot va funcționa în cele din urmă greșit. Numără execuțiile din log de-a lungul unei zile de oscilații ca să vezi cât de des rulează de fapt. Apoi fă scriptul sigur să ruleze de atâtea ori.

Testează ciclul de viață care a eșuat, nu o comandă ulterioară. Reproduce pornirea sau reconectarea, urmărește cârligul executându-se și confirmă că sarcina a reușit în momentul în care rulează de fapt. Un succes dintr-un shell interactiv după aceea este o dovadă despre dependență, nu dovada că calea de pornire funcționează.

Dă un nume evenimentului de care depinde fiecare sarcină, apoi leagă sarcina de acel eveniment. Orice altceva este o întârziere care pretinde că este o verificare.