A u ekzekutua script-i up i OpenVPN shumë herët, apo nuk ishte kurrë gati?

Script-i up ekzekutohet, del me zero, dhe detyra brenda tij nuk arrin një shërbim privat që nga terminali funksionon në mënyrë të përsosur dy sekonda më vonë. Instinkti është kohëzgjatja, dhe riparimi i zakonshëm është një gjumë, i cili e fsheh garën pa e kuptuar atë. Leximi më i dobishëm është se “up” emërton një hook, jo një garanci gatishmërie. Ai aktivizohet kur pajisja e tunelit konfigurohet, që është më herët se rrugët, DNS dhe sigurisht më herët se çdo aplikacion pas tunelit.

Testi në shell pati sukses sepse u ekzekutua pasi gjithçka u qetësua. Hook-u u ekzekutua në një moment të caktuar.

Ku qëndron up në rendin e nisjes

OpenVPN konfiguron pajisjen e tunelit dhe më pas ekzekuton hook-un up. Instalimi i rrugëve është një fazë më e vonë dhe ka hook-un e vet, prandaj një detyrë e varur nga rrugët e vendosur në up mund të shohë një pajisje pa rrugë të dobishme. Vendosni punën me rrugët në route-up dhe problemi i kohës zakonisht zhduket.

Manuali dokumenton këtë rend dhe mjedisin që merr çdo hook. Ky rend është i gjithë shpjegimi për raportin klasik “funksionon nga shell-i im”, dhe është gjithashtu arsyeja pse i njëjti script mund të kalojë në një makinë dhe të dështojë në një tjetër me një fazë rrugësh më të ngadaltë. Asnjëri prej rezultateve nuk thotë gjë për cilësinë e script-it.

DNS dhe gatishmëria e aplikacionit vijnë edhe më vonë. Edhe rrugët e instaluara nuk janë provë që pika e largët po dëgjon, që një emër zgjidhet, ose që ekziston një sesion desktop për një detyrë në fushën e përdoruesit.

Çfarë trashëgon në të vërtetë hook-u

Një hook ekzekutohet nën llogarinë dhe mjedisin e procesit OpenVPN, që nuk është e njëjta gjë si shell-i juaj interaktiv. Mund t'i mungojë autobusi i sesionit të përdoruesit, një mjedis desktop, ose një kredencial që zhbllokohet vetëm në hyrje. Shkruani cilat prej tyre i nevojiten vërtet detyrës.

Kjo ka rëndësi për detyrat që duken si rrjetore por varen nga një kontekst përdoruesi: montimi i një ndarjeje me kredencial përdoruesi, vendosja e një proxy për përdorues, ose konfigurimi i një printeri. Një hook tuneli i privilegjuar është vendi i gabuar për ato, dhe asnjë pritje nuk rregullon një sesion që mungon.

Kur një detyrë dështon në një hook, regjistroni llogarinë, mjedisin dhe operacionin e parë që dështoi. Kjo ndan kohën e parakohshme nga një problem leje ose konteksti, dhe të dy kanë riparime krejt të ndryshme. Hamendja midis tyre është mënyra se si një rregullim pesëminutësh bëhet një pasdite e tërë.

Pse shtimi i një gjumë nuk është kontroll gatishmërie

Një gjumë e vonon script-in dhe e zhvendos dritaren e garës. Në një ditë të shpejtë detyra ka sukses; në një ditë të ngadaltë dështon përsëri, dhe dështimi bëhet më i vështirë për t'u riprodhuar sepse vonesa duket se funksionon. Një vonesë që funksionon vetëm nën ngarkesë të lehtë është rastësi, jo rregullim.

Nëse varësia është një rrugë, përdorni hook-un që korrespondon me instalimin e rrugëve. Nëse varësia është një shërbim pas tunelit, përdorni një kontroll të kufizuar që pret atë kusht specifik dhe dështon qartë kur ai nuk vjen kurrë.

Mbajeni dështimin eksplicit. Një hook që del me zero ndërsa puna e tij e vërtetë dështoi është më keq se një hook që dështon, sepse menaxheri i shërbimeve regjistron një sukses dhe askush nuk shikon më. Një rresht log nga vetë script-i është mënyra më e lirë për ta mbajtur atë të ndershëm.

Pastrimi dhe rilidhja meritojnë të njëjtin kujdes

Një script që ndryshon gjendje të përbashkët ka nevojë për një rrugë të përshtatshme zhbërjeje. Rrugët, hyrjet e resolver-it dhe shenjat e firewall-it të shtuara nga një hook duhet të jenë idempotente dhe të kthyeshme, përndryshe një rilidhje do të vendosë një kopje të dytë mbi të parën.

Rilidhjet gjithashtu mund t'i ekzekutojnë hook-ët më shpesh sesa një nisje e plotë e shërbimit. Një ndërfaqe e vazhdueshme që rivendos një sesion mund të shkaktojë përsëri ciklin up dhe route-up, prandaj një script që supozon një ekzekutim për nisje do të sillet gabimisht përfundimisht. Numëroni ekzekutimet në log gjatë një dite dridhjeje për të parë sa shpesh ekzekutohet vërtet. Pastaj bëni script-in të sigurt për t'u ekzekutuar kaq herë.

Testoni ciklin e jetës që dështoi, jo një komandë të mëvonshme. Rikrijoni nisjen ose rilidhjen, vëzhgoni hook-un duke u ekzekutuar dhe konfirmoni që detyra pati sukses në momentin kur ai ekzekutohet vërtet. Një sukses nga një shell interaktiv më pas është provë për varësinë, jo provë se rruga e nisjes funksionon.

Emërtoni ngjarjen nga e cila varet çdo detyrë, pastaj lidhni detyrën me atë ngjarje. Gjithçka tjetër është një vonesë që shtiret si kontroll.