Paralajmërimi i OpenVPN për disa skripte --up: ekzekutohet vetëm një

Paralajmërimi për disa skripte tingëllon si ankesë për planifikimin, prandaj zgjidhja e dukshme është të rirregullosh rreshtat derisa të zhduket. Por nuk është ankesë për planifikimin. Një përkufizim i mëvonshëm --up zëvendëson komandën e ruajtur tashmë për atë fazë, dhe analizatori e thotë këtë, që do të thotë se nga dy skriptet e tua ka ekzekutuar ndonjëherë saktësisht njëri. Tjetri nuk pret në radhë pas tij; ai është zhdukur.

Prandaj paralajmërimi meriton vëmendje edhe pse nuk është fatal: ai parashikon një përditësim DNS ose një ndryshim rruge që ka pushuar së ndodhuri në heshtje.

Paralajmërimi nuk ka të bëjë me rendin

OpenVPN ruan një komandë të vetme skripti përdoruesi për fazën up. Kur analizatori has një përkufizim tjetër, nga profili, nga një skedar i përfshirë ose nga rreshti i komandës, ai zëvendëson atë që mbante tashmë dhe lëshon paralajmërimin. Asgjë nuk bashkohet, asgjë nuk ekzekutohet dy herë dhe nuk ekziston asnjë pyetje për rendin. Mbijeton komanda që analizatori pa i fundit, prandaj lëvizja e një rreshti mund të ndryshojë fituesin ndërsa skripti tjetër mbetet i vdekur.

I njëjti model vlen për fazat e tjera të skripteve: një komandë secila. Nëse dy punë duhet të ndodhin të dyja, atyre u duhet një pikë e vetme hyrjeje, jo dy direktiva që duken si listë.

Gjeni të dyja përkufizimet në nisjen reale

Filloni nga ajo që daemoni ka marrë vërtet, jo nga profili që keni redaktuar. ps -ef dhe ExecStart i njësisë tregojnë rreshtin e komandës, të cilit mund t’i shtohet --up nga një pikë hyrjeje kontejneri ose nga një mbështjellës; skedari init i një shpërndarjeje mund të bëjë të njëjtën gjë. systemctl cat openvpn-server@server zbulon çfarë shton vetë shërbimi, dhe një grep rekurziv në drejtorinë e konfigurimit gjen përkufizimet në nivel skedari. Dublikatat zakonisht vijnë nga shtresa të ndryshme, dhe pikërisht për këtë redaktimi i një skedari nuk ndryshon asgjë.

Kopjimi i një skripti në një drejtori tjetër ose riemërtimi i tij gjithashtu nuk heq një direktivë. Analizatori numëron përkufizime, jo skedarë.

Lëreni një hook të vetëm ta zotërojë punën

Zgjidhja e qëndrueshme është një dërgues i vetëm që ekzekuton të dyja veprimet në një rend të menduar. Një skript i shkurtër shell me set -eu që thërret integrimin e nevojshëm dhe pastaj veprimin lokal, duke përcjellë "$@" që kufijtë e argumenteve të mbijetojnë, e mban sjelljen në një vend të vetëm të audituar. Përcjellja e argumenteve vetëm i ruan ato; nuk vërteton se dy ndihmësit presin të njëjtin ndërfaqe, prandaj lexoni kontratën e secilit. Vendosni çfarë duhet të bëjë një dështim dhe nëse ndryshimet e pjesshme duhet të kthehen.

Nëse nisësi ofron një hook zgjerimi të mbështetur, preferojeni atë ndaj zinxhirit të ndërtuar me dorë. Një imazh kontejneri ose një paketë e furnizuesit shpesh ka një vend të dokumentuar për punë shtesë, dhe përdorimi i tij pengon një përditësim të mbishkruajë dërguesin tënd.

Pastrimi i takon fazës down përkatëse. Një veprim up që rishkruan DNS-në ose shton rrugë kërkon një kthim të dokumentuar, dhe një dërgues që merret vetëm me nisjen është gjysmë dizajni.

Konfirmoni integrimin, jo vetëm heshtjen

Heqja e paralajmërimit të dublikatës është pjesa e lehtë; integrimi duhet të punojë ende. Kontrolloni gjendjen e zgjidhësit pas lidhjes me resolvectl status ose duke lexuar /etc/resolv.conf, dhe konfirmoni rrugët me ip route. Pastaj shkëputuni dhe rilidhuni, sepse një hook i zinxhiruar me nxitim zakonisht lë diçka nga sesioni i mëparshëm. journalctl -u openvpn-server@server -b tregon nëse dërguesi yt ka ekzekutuar dhe çfarë ka shtypur.

Mbajini privilegjet e hook-ut aty ku i takojnë. Ngritja e script-security ose ekzekutimi i daemon-it me më shumë të drejta nuk është rregullim për një hook të zëvendësuar; zgjeron atë që mund të bëjë çdo skript i ardhshëm, përfshirë një që një sulmues do të emërojë.

Shenja se rregullimi është i vërtetë nuk është heshtja në regjistër. Janë përgjigjja DNS, zëri i rrugës dhe pastrimi që punojnë të gjitha pas dy rilidhjeve.