Shërbimi VPN dështon në EXEC: krahasoni unit, binarin dhe sudoers

Dje tuneli punonte, dhe këtë mëngjes unit është i vdekur me Failed at step EXEC spawning /usr/local/bin/vpnclient në journal. Kredencialet, rrugët dhe llogaria nuk hyjnë kurrë në atë fjali. systemd e zgjidhi ExecStart në një shteg, i kërkoi kernelit ta ekzekutojë, dhe kerneli refuzoi, më shpesh sepse në atë shteg nuk ekziston asgjë ose skedari nuk është i ekzekutueshëm. Trajtojeni defektin si problem skedari dhe argv derisa komanda e analizuar të provojë të kundërtën.

Pse EXEC dështon para se të fillojë vërtetimi

systemd nuk e ekzekuton ExecStart përmes një shell. Ai bën fork, ndërton një vektor argumentesh nga rreshti dhe thërret execve mbi elementin e parë. Nëse ai thirrje dështon, shërbimi nuk arrin kurrë në kodin e vetë klientit të VPN, prandaj as redaktimi i profilit as kontrolli i kredencialeve nuk ndihmon.

Kodi i statusit e ndan këtë familje nga dështimet e zakonshme. Një unit që del me status=203/EXEC nuk ka nisur kurrë një proces; një unit që nis dhe më pas del me status=1 mund të ketë dështuar në vërtetim, DNS ose rrugëzim. Lexoni kodin përpara regjistrit të klientit, sepse në rastin e parë regjistri i klientit do të jetë bosh.

Shtegu në journal është ai që përdori systemd, jo domosdoshmërisht ai që redaktuat ju. Skedarët drop-in dhe dalja e gjeneratorit mund të zëvendësojnë skedarin e furnizuesit, dhe një daemon-reload i vjetëruar e lë rreshtin e vjetër në memorie. Prandaj diagnoza e parë është t'i pyesni systemd çfarë mendon se është komanda, në vend që të hapni skedarin që mbani mend se e keni ndryshuar.

Tri vende ku shkruhet shtegu i binarit

Një klient VPN i instaluar nga një paketë shpërndarjeje, një skript furnizuesi dhe një tarball versioni mund të përfundojë në tre prefikse të ndryshëm. Unit, rregulli i privilegjeve dhe instaluesi regjistruan secili një prej këtyre prefikseve, dhe defekti shfaqet kur dy nga të tre nuk përputhen.

Një mospërputhje konkrete duket kështu: skripti i furnizuesit instalon në /usr/local/bin, tarball-i u zbërthye nën /opt, dhe unit vazhdon të përmendë shtegun e vjetër /usr/bin nga një paketë e mëparshme. Vetëm një prej atyre skedarëve ekziston, dhe rrallë është ai në ExecStart.

Vendosni cili shteg është kanonik para se të ndryshoni cilindo skedar. Nëse binari zotërohet nga paketa e shpërndarjes, shtegu i paketës është kanonik dhe unit duhet ta ndjekë. Nëse e zotëron skripti i furnizuesit, i njëjti rregull vlen për prefiksin e furnizuesit. Kopjimi i binarit midis prefikseve krijon dy kopje që ndahen në përditësimin tjetër.

Kur një komandë në thonjëza bëhet emër skedari

Një mënyrë e dytë dështimi fshihet pas të njëjtit rresht të journal. Dikush e shkruan këtë në unit dhe pret që klienti të lidhet gjatë nisjes:

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

systemd e ndan vlerën në fjalë, kështu që fjala e parë bëhet /usr/bin/vpnclient connect office, ndërsa thonjëzat hiqen si sintaksë grupimi. Pastaj kerneli kërkon një skedar emri i të cilit përmban hapësira, dhe nuk ekziston. Gabimi është identik me atë të një binari që mungon, megjithëse binari është i instaluar.

Forma e mbështetur është një ekzekutues i vërtetë i ndjekur nga argumente të veçanta, për shembull ExecStart=/usr/bin/vpnclient connect office. Nëse rrjedha e punës ka vërtet nevojë për një tub ose një zinxhir, vendoseni në një skript dhe thirrni skriptin, sepse ExecStart nuk ka &&, nuk ka tuba dhe nuk ka zgjerim glob.

Rregulloni unit, jo sistemin e skedarëve

Rregullimi joshës është një lidhje simbolike nga shtegu i pritur te binari i vërtetë. Funksionon derisa paketa të përditësohet dhe lidhja të tregojë një skedar të hequr, ose derisa një etiketë SELinux të mos përputhet më me objektivin. Preferoni të redaktoni unit përmes një drop-in, kështu që skedari i furnizuesit mbetet i paprekur dhe përditësimet mbeten të parashikueshme.

Rregulli i privilegjeve duhet të përputhet me të njëjtin shteg dhe të njëjtat nënkomanda. Një zë në sudoers për /usr/local/bin/vpnclient nuk autorizon /usr/bin/vpnclient, dhe një zë që lejon çdo argument i lejon çdo procesi lokal të rikonfigurojë ose të ndalojë tunelin. Jepni dy foljet që i nevojiten unit dhe mbajeni çmontimin jashtë tij nëse ndalimi i shërbimit e mbyll tashmë ndërfaqen.

Këtu krahasimi ia vlen: unit, baza e të dhënave e paketave dhe sudoers duhet të përmendin një shteg të vetëm. Kur e bëjnë, gabimi EXEC zhduket pa rinisje dhe pa një kopje të binarit në një vend të tretë.

Provoni komandën e analizuar para rinisjes

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 është dalja vendimtare sepse shtyp argv-në që systemd analizoi vërtet, duke përfshirë çdo drop-in. systemd-analyze verify kap një shteg që mungon ose nuk ekzekutohet para se të rinisni, dhe komanda status pas rinisjes ju thotë nëse procesi ekziston tani.

Nëse unit nis dhe më pas dështon, keni lënë familjen EXEC dhe keni hyrë në trajtimin e gabimeve të vetë klientit. Kërkoni në journal mesazhin e klientit, jo një dështim tjetër execve. Mbani diff-in e unit dhe diff-in e sudoers bashkë në regjistrin e ndryshimeve, që përditësimi tjetër të mos rikthejë në heshtje shtegun e ndarë.