Vai OpenVPN up skripts darbojās pārāk agri, vai arī tas nekad nebija gatavs?
up āķis darbojas, kad parādās tuneļa ierīce, pirms maršrutiem un lietojumprogrammas gatavības. Saskaņojiet skriptu ar notikumu, kas tam nepieciešams, tā vietā, lai pievienotu miegu.
up skripts darbojas, beidzas ar nulli, un tā iekšienē esošais uzdevums nevar sasniegt privāto pakalpojumu, kas no termināļa divas sekundes vēlāk darbojas nevainojami. Instinkts saka, ka vaina ir laikā, un ierastais remonts ir miegs, kas slēpj sacensību, to nesaprotot. Noderīgāks lasījums ir tāds, ka “up” nosauc āķi, nevis gatavības garantiju. Tas iedarbojas, kad tuneļa ierīce ir konfigurēta, un tas ir agrāk par maršrutiem, DNS un noteikti agrāk par jebkuru lietojumprogrammu aiz tuneļa.
Čaulas tests izdevās tāpēc, ka tas tika palaists pēc tam, kad viss bija noskaidrojies. Āķis darbojās vienā konkrētā mirklī.
Kur up atrodas palaišanas secībā
OpenVPN konfigurē tuneļa ierīci un pēc tam palaiž up āķi. Maršrutu instalēšana ir vēlāks posms, un tam ir savs āķis, tāpēc no maršrutiem atkarīgs uzdevums, kas ievietots up, var saskarties ar ierīci bez noderīga ceļa. Ievietojiet maršrutu darbu route-up, un laika problēma parasti pazūd.
Rokasgrāmata dokumentē šo secību un vidi, ko saņem katrs āķis. Šī secība ir visskaidrojums klasiskajam ziņojumam “darbojas no manas čaulas”, un tā arī izskaidro, kāpēc viens un tas pats skripts var izturēt vienā mašīnā un neizturēt citā ar lēnāku maršrutu posmu. Neviens no rezultātiem neko nepasaka par skripta kvalitāti.
DNS un lietojumprogrammas gatavība nāk vēl vēlāk. Pat instalēti maršruti nav pierādījums tam, ka attālais galapunkts klausās, ka vārds tiek atrisināts vai ka lietotājam piesaistītam uzdevumam eksistē darbvirsmas sesija.
Ko āķis patiesībā manto
Āķis darbojas OpenVPN procesa kontā un vidē, kas nav tas pats, kas jūsu interaktīvā čaula. Tam var trūkt lietotāja sesijas kopnes, darbvirsmas vides vai akreditācijas datu, kas tiek atslēgti tikai pieteikšanās laikā. Pierakstiet, kuri no tiem uzdevumam patiešām ir vajadzīgi.
Tas ir svarīgi uzdevumiem, kas izskatās kā tīklošana, bet ir atkarīgi no lietotāja konteksta: koplietojamās mapes montēšana ar lietotāja akreditācijas datiem, lietotāja līmeņa starpniekservera iestatīšana vai printera konfigurēšana. Priviliģēts tuneļa āķis tiem ir nepareizā vieta, un nekāda gaidīšana neizlabos trūkstošu sesiju.
Kad uzdevums āķī neizdodas, pierakstiet kontu, vidi un pirmo operāciju, kas neizdevās. Tas atdala pāragru laiku no atļauju vai konteksta problēmas, un abiem ir pilnīgi atšķirīgi remonti. Minēšana starp abiem ir ceļš, kā piecu minūšu labojums pārvēršas veselā pēcpusdienā.
Kāpēc miega pievienošana nav gatavības pārbaude
Miegs aizkavē skriptu un pārbīda sacensību logu. Ātrā dienā uzdevums izdodas; lēnā dienā tas atkal neizdodas, un kļūmi kļūst grūtāk reproducēt, jo aizkavēšanās šķiet darbojamies. Aizkavēšanās, kas darbojas tikai nelielas slodzes laikā, ir nejaušība, nevis remonts.
Ja atkarība ir maršruts, izmantojiet āķi, kas atbilst maršrutu instalēšanai. Ja atkarība ir pakalpojums aiz tuneļa, izmantojiet ierobežotu pārbaudi, kas gaida tieši šo nosacījumu un skaidri neizdodas, kad tas nekad neiestājas.
Turiet kļūmi skaidru. Āķis, kas beidzas ar nulli, kamēr tā faktiskais darbs ir neizdevies, ir sliktāks par āķi, kas neizdodas, jo pakalpojumu pārvaldnieks reģistrē panākumu un neviens vairs neskatās. Viena žurnāla rinda no paša skripta ir lētākais veids, kā to noturēt godīgu.
Tīrīšana un atkārtota savienošana ir pelnījušas tādu pašu rūpību
Skriptam, kas maina koplietoto stāvokli, vajadzīgs atbilstošs atcelšanas ceļš. Āķa pievienotie maršruti, risinātāja ieraksti un ugunsmūra atzīmes ir jābūt idempotentām un atgriezeniskām, citādi atkārtota savienošana uzliek otru kopiju virs pirmās.
Atkārtotas savienošanas var palaist āķus biežāk nekā pilna pakalpojuma palaišana. Pastāvīga saskarne, kas atjauno sesiju, var atkal izraisīt up un route-up ciklu, tāpēc skripts, kas pieņem vienu izpildi uz vienu palaišanu, agrāk vai vēlāk darbosies nepareizi. Saskaitiet izpildes žurnālā vienas dienas svārstību laikā, lai redzētu, cik bieži tas patiešām darbojas. Pēc tam padariet skriptu drošu šādam izpildes skaitam.
Pārbaudiet to dzīves ciklu, kas neizdevās, nevis vēlāku komandu. Reproducējiet palaišanu vai atkārtoto savienošanu, vērojiet, kā āķis darbojas, un apstipriniet, ka uzdevums izdevās tieši tajā mirklī, kad tas patiešām tiek palaists. Panākums no interaktīvas čaulas pēc tam ir pierādījums par atkarību, nevis pierādījums, ka palaišanas ceļš strādā.
Nosauciet notikumu, no kura atkarīgs katrs uzdevums, un piesaistiet to šim notikumam. Viss pārējais ir aizkavēšanās, kas izliekas par pārbaudi.