Rulu taskojn post la VPN el la dispeĉilo, ne el if-up

Skripto, kiu devas ruliĝi post kiam la VPN supreniĝas, bezonas eventon de la komponanto, kiu posedas la konekton. Dosiero metita en malnovan retan hokan dosierujon ne estas retroalvoko por ĉiu VPN, kiun NetworkManager, pppd aŭ memstara OpenVPN-procezo povas krei. Ĉiu el tiuj posedantoj raportas alian eventon kun alia medio, do la posedanto devas esti identigita antaŭ ol elekti la hokon. Alie la skripto estas ĝusta kaj simple neniam ruliĝas.

Por VPN administrata de NetworkManager, la dispeĉilo estas la ĝusta loko, kaj vpn-up estas la ĝusta ago.

Uzu vpn-up, ne la interfacan eventon

La dispeĉilo distingas up de vpn-up. La unua raportas aktivigitan interfacon; la dua raportas aktivigitan VPN-konekton. Supreniĝo de Wi-Fi signifas nur, ke la suba ligilo ekzistas; la tunelo eble ankoraŭ intertraktas, aŭ eble neniam aŭtentikiĝos.

La skripto ricevas la interfacon kaj la agon, dum detaloj de la konekto alvenas per la medio, inkluzive la UUID de la profilo kaj la IP-interfacon de la VPN. Legu tiujn variablojn anstataŭ dedukti identecon el aparataj nomoj.

Limigu la kongruon al unu konekto

Kongruigu laŭ la UUID de la konekto, aŭ laŭ alia identeco, kiun la dispeĉilo liveras, anstataŭ laŭ tun-prefikso aŭ ppp0. Interfacaj nomoj ne estas stabilaj, povas ekzisti pli ol unu tunelo samtempe, kaj du profiloj povas porti la saman vidigatan nomon. Kongruigi tun-prefikson signifas, ke la skripto fine ekfunkcios por konekto, kiun neniu intencis tuŝi. Ĝi ankaŭ povas ekfunkcii dufoje por unu profilo, kiam rekonekto rekonstruas la aparaton.

Faru la taskon idempotenta. Retroalvoko, kiu aldonas itineron ĉe ĉiu alvoko, fine plenigos la tabelon per duplikatoj, kaj la dua kopio estas tiu, kiu rompas la enkursigadon.

Sciu, kion aktivigo ne pruvas

vpn-pre-up ruliĝas antaŭ ol NetworkManager raportas la VPN plene aktivigita, kaj la administranto atendas tiujn skriptojn. Uzu blokantan stadion nur kiam la tasko vere apartenas tie, ĉar malrapida kontrolo prokrastas la aktivigon, kiun ĉiuj aliaj komponantoj atendas vidi.

Ĉeesto de itineraj rikordoj ne pruvas, ke aplikaĵo aŭskultas, ke privata nomo solviĝas, aŭ ke uzanta seanco ekzistas. Kontrolu tion aparte kun limigita tempolimo, kaj raportu, kiu tavolo malsukcesis, anstataŭ reprovi la tutan ĉenon.

Respektu la kuntekston, en kiu la skripto ruliĝas

Skriptoj de la dispeĉilo ruliĝas kiel root, ekster iu ajn uzanta seanco. Ne supozu, ke la medio de la ensalutinta uzanto, ties grafika seanco aŭ malŝlosita ŝlosilringo estas disponeblaj. Neniu respondu al mankanta labortabla kunteksto farante ĉiun akreditaĵon legebla por ĉiu procezo. Tenu laboron de la uzanta seanco en uzanta servo aŭ seanca helpilo, kiun la retroalvoko povas signali sen ŝajnigi la uzanton.

Posedo kaj permesoj pri la skripto ankaŭ gravas. Dosiero ruligata kiel root, kiun iu ajn uzanto povas anstataŭigi, estas vojo al privilegia plialtigo, kaj tio estas konkludo sendependa de tio, ĉu la VPN-logiko estas ĝusta.

Planu por la malkonekto, kiu neniam ekfunkcias

NetworkManager dokumentas, ke vpn-pre-down ne elsendiĝas por devigitaj malkonektoj kiel neatendita finiĝo aŭ perdita konektebleco. Do purigado konstruita nur ĉirkaŭ milda pre-down estas nekompleta laŭ konstruo. Ĉiu komuna stato, kiun la skripto ŝanĝas, bezonas alian posedanton, kiu povas restarigi ĝin post paneo, kaj tiu rekupera vojo devas esti testata, ne supozata.

Testu la hokon per normala konekto, rekonekto, intenca malkonekto kaj eltirita kablo. Registru la UUID-on, la agon kaj la interfacon, kiu ekfunkciis, sen registri sekretojn. Tiu registro estas la sola fidinda pruvo, ke la hoko ruliĝis por la konekto, kiun vi intencis, kaj ĝi estas tio, kio igas la sekvan ŝanĝon sekura.