Mac-VPN ĉe ekstarto: launchd kontrolas la taskon, ne la tunelon

La tasko ekfunkcias ĉe saluto, la protokolo montras la klienton ekfunkciiĝi, kaj la tunelo neniam altiĝas. Aŭ ĝi altiĝas kaj malaperas kelkajn sekundojn poste. En ambaŭ kazoj la trajto-listo probable estis en ordo. launchd faris du promesojn kiam ĝi akceptis la taskon: ĝi observos procezon, kaj tiu procezo daŭre funkcios. La VPN bezonas ambaŭ, kaj ĝusta XML-dosiero havigas neniun.

Valida trajto-listo ne estas funkcianta servo

plutil -lint kontrolas la strukturon. Ĝi ne povas diri ĉu la duuma dosiero ekzistas, ĉu la argumentoj estas subtenataj de ĉi tiu klientversio, aŭ ĉu la tasko ekas en kunteksto kie la akreditaĵoj disponeblas. Tiuj estas signifaj demandoj, kaj ili klarigas plej multajn malsukcesojn kiuj aspektas kiel problemoj de launchd.

plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn

Legu la eligon de la dua komando anstataŭ supozi ke la tasko ŝargiĝis. Ĝi raportas la lastan elirstaton kaj ĉu la servo funkcias, kio distingas “neniam ekis” de “ekis kaj mortis” antaŭ ol vi tuŝu la profilon.

Agentoj heredas uzantosesion, demonoj ne

La dokumentaro de Apple pri launchd apartigas agentojn laŭ uzanto de sistemaj demonoj. Agento funkcias en la kunteksto de la salutinta uzanto, kun ties ŝlosilujo kaj medio. Demono funkcias sen tiu sesio, kaj movi taskon en sisteman dosierujon ne rekreas la interagajn akreditaĵojn de la uzanto.

Tiu distingo decidas la dezajnon. Se la konekto postulas, ke homo salutu aŭ aprobu MFA-peton, la subtenata aranĝo estas tasko en la uzantosesio, kiu funkcias post saluto. Se ĝi devas funkcii sen iu ajn salutinta, la kliento bezonas aprobitan senhoman identecon kun propra renoviga kaj revoka procezo. Elekti la malĝustan vicon kreas taskon, kiu ekas pure kaj malsukcesas ĉe la unua aŭtentikiga paŝo.

Ne kaŝu la diferencon per pasvorto en la argumenta tabelo aŭ per malŝalto de atestilaj kontroloj. Ambaŭ faras el aŭtentikiga postulo permanentan sekreton en legebla dosiero, kaj la dua signifas, ke la tunelo aŭtentikigas ĉion, kio respondas.

Observado funkcias nur se la procezo restas antaŭe

Kliento, kiu mem demoniĝas, redonas la kontrolon al launchd tuj, kaj la observanto poste rigardas procezon, kiu jam eliris. La tunelo povas esti supre, sed launchd opinias ke la tasko malsukcesis, kaj ĝia restartiga politiko faros ion, kion vi ne intencis.

Uzu la dokumentitan antaŭplanan aŭ servan reĝimon de la kliento. Se la produkto havas propran subtenatan startan funkcion, ĝi jam scias kiel resti antaŭe kaj kiel transdoni al la reta stako; propra tasko estas aparta dezajno, ne plibonigo de ĝi.

Donu al la tasko unikan etikedon, la celatan plenumeblon kaj intencan argumentan tabelon. Tabelo ne estas ŝela komandlinio, do pipoj kaj alidirektado tie ne funkcias, kaj citiloj kondutas alie. Komando, kiu sukcesas en terminalo de administranto, estas plej bone antaŭkontrolo.

Akreditaĵoj devas funkcii sen prompto

Senhoma funkciado movas la akreditan problemon anstataŭ forigi ĝin. Iu devas posedi la identecon, decidi kiom longe ĝi vivos, kaj dokumenti kiel ĝi anstataŭiĝas. Atestilo sen monitorado de eksvalidiĝo fariĝas interrompo kun dato en la kalendaro.

Tenu sekretojn ekster argumentoj kaj ekster la norma eligo de la tasko. Se la kliento subtenas legi akreditaĵon el protektita konservejo, uzu tiun vojon, kaj kontrolu ke la plenumkunteksto de la tasko povas atingi la konservejon. Demono funkcianta kiel root kutime ne povas legi eron de saluta ŝlosilujo, kaj tio estas la speco de detalo, kiu aperas nur en la sistema kunteksto.

Difinu, kion signifas preteco, kaj testu ĝin tie

Sukcesa lanĉo pruvas, ke la procezo ekis. Ĝi ne pruvas, ke la reto estas supre, ke la kluzo akceptis la identecon, aŭ ke la privata aplikaĵo estas atingebla. Se io alia dependas de la tunelo, ĝi bezonas pretecan signalon, kiu spegulas la konekton, ne la ektempon de la tasko.

Ripetoj devas esti limigitaj kaj distingi mankantan reton de rifuzita akreditaĵo. Relanĉo ĉe ĉiu malsukceso ne povas ripari eksvalidiĝintan atestilon kaj produktas protokolon plenan de identaj provoj, kiu kaŝas la veran.

Akceptu la taskon en la kunteksto, en kiu ĝi vere funkcios: neniu reto ĉe ekstarto, normala saluto, vekiĝo el dormo kaj kontrolita halto. Poste registru kune la taskan etikedon, la klientversion kaj la profilrevizion, por ke la sekva persono heredu atribueblan servon anstataŭ dosieron, kiu iam funkciis.