Nabibigo ang serbisyo ng VPN sa EXEC: ihambing ang unit, binary at sudoers

Kahapon gumagana ang tunnel, at ngayong umaga patay ang unit na may Failed at step EXEC spawning /usr/local/bin/vpnclient sa journal. Ang mga kredensyal, ruta at account ay hindi kailanman pumapasok sa pangungusap na iyon. Inayos ng systemd ang ExecStart tungo sa isang landas, hiniling sa kernel na isagawa ito, at tumanggi ang kernel, kadalasan dahil walang umiiral sa landas na iyon o hindi naisakatuparan ang file. Ituring ang depektong ito na problema ng file at argv hanggang patunayan ng sinuring utos ang kabaligtaran.

Bakit nabibigo ang EXEC bago magsimula ang pagpapatotoo

Hindi pinapatakbo ng systemd ang ExecStart sa pamamagitan ng shell. Gumagawa ito ng fork, bumubuo ng vector ng mga argumento mula sa linya at tumatawag ng execve sa unang elemento. Kung mabigo ang tawag na iyon, hindi kailanman naaabot ng serbisyo ang sariling code ng kliyente ng VPN, kaya wala mang pag-edit ng profile o pagsusuri ng kredensyal ang makakatulong.

Ang status code ang naghihiwalay sa pamilyang ito mula sa mga ordinaryong pag-crash. Ang unit na lumalabas na may status=203/EXEC ay hindi kailanman nagsimula ng proseso; ang unit na nagsisimula at pagkatapos ay lumalabas na may status=1 ay maaaring nabigo sa pagpapatotoo, DNS o pagruruta. Basahin ang code bago ang log ng kliyente, dahil sa unang kaso magiging walang laman ang log ng kliyente.

Ang landas sa journal ay ang ginamit ng systemd, hindi kinakailangan ang in-edit mo. Maaaring palitan ng mga drop-in na file at output ng generator ang file ng vendor, at ang lumang daemon-reload ay nag-iiwan ng lumang linya sa memorya. Kaya ang unang diyagnosis ay tanungin ang systemd kung ano ang itinuturing nitong utos, sa halip na buksan ang file na natatandaan mong binago.

Tatlong lugar kung saan nakasulat ang landas ng binary

Ang kliyenteng VPN na naka-install mula sa pakete ng distribusyon, script ng vendor at tarball ng release ay maaaring mapunta sa tatlong magkakaibang prefix. Ang unit, ang tuntunin ng pribilehiyo at ang installer ay nagtala ng tig-iisang prefix, at lumilitaw ang depekto kapag hindi tugma ang dalawa sa tatlo.

Ang konkretong pagkakaiba ay ganito ang hitsura: nag-i-install ang script ng vendor sa /usr/local/bin, na-extract ang tarball sa ilalim ng /opt, at pinapangalanan pa rin ng unit ang lumang landas /usr/bin mula sa naunang pakete. Isa lamang sa mga file na iyon ang umiiral, at bihirang ito ang nasa ExecStart.

Magpasya kung aling landas ang kanonikal bago baguhin ang alinman sa mga file. Kung pag-aari ng pakete ng distribusyon ang binary, ang landas ng pakete ang kanonikal at dapat itong sundan ng unit. Kung pag-aari ito ng script ng vendor, ganoon din ang tuntunin para sa prefix ng vendor. Ang pagkopya ng binary sa pagitan ng mga prefix ay lumilikha ng dalawang kopya na maghihiwalay sa susunod na pag-upgrade.

Kapag ang utos sa loob ng sipi ay naging pangalan ng file

May ikalawang paraan ng pagpalya na nagtatago sa likod ng parehong linya sa journal. May nagsusulat nito sa unit at inaasahang kokonekta ang kliyente habang nagbo-boot:

ExecStart=/usr/bin/"vpnclient connect office"

Hinahati ng systemd ang halaga sa mga salita, kaya ang unang salita ay nagiging /usr/bin/vpnclient connect office, at tinatanggal ang mga sipi bilang sintaks ng pagpapangkat. Pagkatapos ay naghahanap ang kernel ng file na may espasyo sa pangalan, at wala. Ang error ay kapareho ng nawawalang binary kahit naka-install ang binary.

Ang sinusuportahang anyo ay tunay na naisagawang file na sinusundan ng hiwalay na mga argumento, halimbawa ExecStart=/usr/bin/vpnclient connect office. Kung ang daloy ng trabaho ay talagang nangangailangan ng pipeline o kadena, ilagay ito sa script at tawagin ang script, dahil ang ExecStart ay walang &&, walang pipe at walang pagpapalawak ng glob.

Ayusin ang unit, hindi ang file system

Ang nakatutuksong pag-aayos ay isang simbolikong link mula sa inaasahang landas hanggang sa tunay na binary. Gumagana ito hanggang ma-update ang pakete at tumuro ang link sa tinanggal na file, o hanggang hindi na tumugma ang label ng SELinux sa target. Mas mainam na i-edit ang unit sa pamamagitan ng drop-in, upang manatiling buo ang file ng vendor at manatiling mahulaan ang mga pag-upgrade.

Dapat tumugma ang tuntunin ng pribilehiyo sa parehong landas at parehong subcommand. Ang entry sa sudoers para sa /usr/local/bin/vpnclient ay hindi nagbibigay ng awtoridad sa /usr/bin/vpnclient, at ang entry na nagpapahintulot sa anumang argumento ay nagbibigay-daan sa anumang lokal na proseso na muling i-configure o ihinto ang tunnel. Ibigay ang dalawang pandiwa na kailangan ng unit at ilagay ang pagtanggal sa labas nito kung isinasara na ng paghinto ng serbisyo ang interface.

Dito nagbabayad ang paghahambing: ang unit, database ng pakete at sudoers ay dapat magpangalan ng isang landas. Kapag ginawa nila ito, mawawala ang error sa EXEC nang walang reboot at walang kopya ng binary sa ikatlong lugar.

Patunayan ang sinuring utos bago mag-reboot

sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pager

systemctl show ang mapagpasyang output dahil ipinapakita nito ang argv na tunay na sinuri ng systemd, kasama ang anumang drop-in. Hinuhuli ng systemd-analyze verify ang nawawala o hindi naisagawang landas bago ka mag-restart, at ang status command pagkatapos ng restart ay nagsasabi kung umiiral na ngayon ang proseso.

Kung nagsimula ang unit at pagkatapos ay nabigo, umalis ka sa pamilyang EXEC at pumasok sa sariling paghawak ng error ng kliyente. Hanapin sa journal ang mensahe ng kliyente, hindi ang isa pang pagpalya ng execve. Itago ang diff ng unit at ang diff ng sudoers nang magkasama sa talaan ng pagbabago, upang ang susunod na pag-upgrade ay hindi tahimik na muling ipasok ang nahating landas.