La averto de OpenVPN pri pluraj --up-skriptoj: nur unu ruliĝas

La averto pri pluraj skriptoj sonas kiel plendo pri planado, do la evidenta solvo estas reordigi la liniojn ĝis ĝi malaperos. Ĝi ne estas plendo pri planado. Pli posta difino --up anstataŭigas la komandon jam konservitan por tiu stadio, kaj la analizilo tion diras, kio signifas, ke el viaj du skriptoj iam ruliĝis precize unu. La alia ne staras en vico malantaŭ ĝi; ĝi estas for.

Tial la averto meritas atenton, kvankam ĝi ne estas fatala: ĝi antaŭdiras DNS-ĝisdatigon aŭ itineran ŝanĝon, kiuj silente ĉesis okazi.

La averto ne temas pri ordo

OpenVPN konservas unu solan komandon de uzanta skripto por la stadio up. Kiam la analizilo renkontas alian difinon, el la profilo, inkluzivita dosiero aŭ la komandlinio, ĝi anstataŭigas tion, kion ĝi jam tenis, kaj eligas la averton. Nenio estas kunmetata, nenio ruliĝas dufoje, kaj orda demando ne ekzistas. Postvivas la komando, kiun la analizilo vidis laste, tial movi linion povas ŝanĝi la venkanton, dum la alia skripto restas morta.

La sama ŝablono validas por la aliaj skriptaj stadioj: unu komando por ĉiu. Se du laboroj ambaŭ devas okazi, ili bezonas unu enirpunkton, ne du direktivojn similajn al listo.

Trovu ambaŭ difinojn en la reala lanĉo

Komencu de tio, kion la demono efektive ricevis, ne de la profilo, kiun vi redaktis. ps -ef kaj la ExecStart de la unuo montras la komandlinion, kiu povas aldoni --up el enirpunkto de ujo aŭ el ĉirkaŭilo; init-dosiero de distribuo povas fari la samon. systemctl cat openvpn-server@server malkaŝas, kion la servo mem kontribuas, kaj rekursiva grep tra la agorda dosierujo trovas la difinojn ĉe dosiera nivelo. Duoblaĵoj kutime venas el malsamaj tavoloj, kaj ĝuste tial redakti unu dosieron ŝanĝas nenion.

Kopii skripton al alia dosierujo aŭ renomi ĝin ankaŭ ne forigas direktivon. La analizilo kalkulas difinojn, ne dosierojn.

Lasu unu hokon posedi la laboron

La daŭra solvo estas unu dispeĉero, kiu plenumas ambaŭ agojn en intenca ordo. Mallonga ŝel-skripto kun set -eu, kiu vokas la bezonatan integriĝon kaj poste la lokan agon, transdonante "$@" por ke argumentaj limoj postvivas, tenas la konduton en unu aŭdebla loko. Transdoni argumentojn nur konservas ilin; ĝi ne pruvas, ke la du helpiloj atendas la saman interfacon, do legu la kontrakton de ĉiu. Decidu, kion fiasko devas fari, kaj ĉu partaj ŝanĝoj bezonas malfaron.

Se la lanĉilo proponas subtenatan etendan hokon, preferu ĝin al permane konstruita ĉeno. Uja bildo aŭ vendista pako ofte havas dokumentitan lokon por kroma laboro, kaj uzi ĝin malhelpas al ĝisdatigo anstataŭigi vian dispeĉeron.

Purigado apartenas al la responda stadio down. Ago up, kiu reverkas DNS aŭ aldonas itinerojn, bezonas dokumentitan malfaron, kaj dispeĉero, kiu traktas nur la starton, estas duona dezajno.

Konfirmu la integriĝon, ne nur la silenton

Forigi la duoblan averton estas la facila parto; la integriĝo ankoraŭ devas funkcii. Kontrolu la staton de la solvilo post konekto per resolvectl status aŭ legante /etc/resolv.conf, kaj konfirmu la itinerojn per ip route. Poste malkonektu kaj rekonektu, ĉar haste ĉenita hoko emas lasi ion de la antaŭa seanco. journalctl -u openvpn-server@server -b montras, ĉu via dispeĉero ruliĝis kaj kion ĝi presis.

Tenu la privilegiojn de la hoko tie, kie ili apartenas. Altigi script-security aŭ ruli la demonon kun pli da rajtoj ne estas ripari anstataŭigitan hokon; ĝi larĝigas, kion povas fari ĉiu estonta skripto, inkluzive de tiu, kiun atakanto rajtas nomi.

La signo, ke la ripeto estas reala, ne estas silento en la protokolo. Ĝi estas la DNS-respondo, la itinera registro kaj la purigado, ĉiuj funkciantaj post du rekonektoj.