VPN үйлчилгээ EXEC дээр бүтэлгүйтдэг: unit, binary файл, sudoers-ийг харьцуулна уу
EXEC шатанд бүтэлгүйтсэн нь systemd binary файлыг эхлүүлж чадаагүй гэсэн үг. Ямар нэг зүйлийг өөрчлөхөөс өмнө unit-ийн зам, суулгасан зам, sudoers-ийн зөвшөөрлийг харьцуулна уу.
Өчигдөр туннель ажиллаж байсан бол өнөө өглөө unit үхсэн, журналд Failed at step EXEC spawning /usr/local/bin/vpnclient байна. Бүртгэлийн мэдээлэл, маршрут, бүртгэл тэр өгүүлбэрт хэзээ ч ордоггүй. systemd ExecStart-ыг зам болгон шийдэж, цөмд түүнийг гүйцэтгэхийг хүссэн боловч цөм татгалзсан, ихэвчлэн тухайн замд юу ч байхгүй эсвэл файл гүйцэтгэгдэх боломжгүй байсан учраас. Шинжилсэн команд эсрэгээр нь нотлох хүртэл энэ алдааг файл ба argv-ийн асуудал гэж үзээрэй.
Баталгаажуулалт эхлэхээс өмнө EXEC яагаад бүтэлгүйтдэг вэ
systemd ExecStart-ыг shell-ээр дамжуулан ажиллуулдаггүй. Тэр fork хийж, мөрөөс аргументын векторыг байгуулж, эхний элемент дээр execve дууддаг. Хэрэв энэ дуудлага бүтэлгүйтвэл үйлчилгээ хэзээ ч VPN клиентийн өөрийн кодонд хүрэхгүй, тиймээс профайл засах эсвэл бүртгэлийн мэдээлэл шалгах нь тус болохгүй.
Төлөвийн код энэ бүлгийг энгийн уналтаас ялгадаг. status=203/EXEC-ээр гарсан unit хэзээ ч процесс эхлүүлээгүй; эхэлж, дараа нь status=1 -ээр гарсан unit баталгаажуулалт, DNS эсвэл маршрутчлалд бүтэлгүйтсэн байж болно. Клиентийн логийг уншихаас өмнө кодыг уншина уу, учир нь эхний тохиолдолд клиентийн лог хоосон байх болно.
Журнал дахь зам нь systemd-ийн ашигласан зам бөгөөд таны зассан зам байх албагүй. Drop-in файлууд болон генераторын гаралт нийлүүлэгчийн файлыг дарж болох бөгөөд хуучирсан daemon-reload хуучин мөрийг санах ойд үлдээдэг. Тиймээс эхний оношилгоо нь таны зассан гэж санаж буй файлыг нээх биш, systemd-ээс командыг юу гэж үзэж байгааг асуух явдал юм.
Binary файлын зам бичигддэг гурван газар
Түгээлтийн багц, нийлүүлэгчийн скрипт, хувилбарын tarball-аас суулгасан VPN клиент гурван өөр угтварт орж болно. unit, эрх мэдлийн дүрэм, суулгагч нь тэдгээрийн нэг нэг угтварыг тэмдэглэсэн бөгөөд гурвын хоёр нь таарахгүй үед алдаа илэрдэг.
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
Тодорхой зөрүү ийм харагдана: нийлүүлэгчийн скрипт /usr/local/bin руу суулгадаг, tarball /opt дор задалсан, unit одоо ч өмнөх багцын хуучин /usr/bin замыг дурддаг. Эдгээр файлуудын зөвхөн нэг нь байдаг бөгөөд энэ нь ExecStart дахь файл байх нь ховор.
Аль нэг файлыг өөрчлөхөөс өмнө аль зам каноник болохыг шийдээрэй. Хэрэв binary файл түгээлтийн багцад хамаарах бол багцын зам каноник бөгөөд unit түүнийг дагах ёстой. Хэрэв нийлүүлэгчийн скриптэд хамаарах бол мөн адил дүрэм нийлүүлэгчийн угтварт үйлчилнэ. Binary файлыг угтваруудын хооронд хуулах нь дараагийн шинэчлэлтэд салж эхлэх хоёр хуулбарыг үүсгэдэг.
Хашилт доторх команд файлын нэр болох үед
Хоёр дахь бүтэлгүйтлийн горим мөн тэр журналын мөрийн ард нуугддаг. Хэн нэгэн үүнийг unit-д бичиж, клиент ачаалах үед холбогдоно гэж хүлээдэг:
ExecStart=/usr/bin/"vpnclient connect office"systemd утгыг үгсэд хуваадаг тул эхний үг /usr/bin/vpnclient connect office болж, хашилтууд бүлэглэх синтакс болж арилдаг. Дараа нь цөм нэрэнд нь зай агуулсан файл хайдаг бөгөөд тийм файл байхгүй. Binary файл суусан ч алдаа нь байхгүй binary файлынхтай ижил.
Дэмжигддэг хэлбэр нь бодит гүйцэтгэгдэх файл, дараа нь тусдаа аргументууд, жишээ нь ExecStart=/usr/bin/vpnclient connect office. Хэрэв ажлын урсгал үнэхээр хоолой эсвэл гинжин хэлхээ шаарддаг бол түүнийг скриптэд хийж, скриптийг дуудна уу, учир нь ExecStart-д && байхгүй, хоолой байхгүй, glob өргөтгөл байхгүй.
Файлын системийг биш, unit-ийг засна уу
Уруу татдаг засвар нь хүлээгдэж буй замаас бодит binary файл руу чиглэсэн симбол холбоос юм. Багц шинэчлэгдэж, холбоос устгагдсан файл руу заах хүртэл, эсвэл SELinux шошго зорилготой таарахаа болих хүртэл ажиллана. unit-ийг drop-in-аар засах нь дээр, тэгвэл нийлүүлэгчийн файл хөндөгдөхгүй үлдэж, шинэчлэлтүүд урьдчилан таамаглагдана.
Эрх мэдлийн дүрэм ижил зам ба ижил дэд командуудад тохирох ёстой. /usr/local/bin/vpnclient-д зориулсан sudoers бичлэг /usr/bin/vpnclient-д зөвшөөрөл өгөхгүй, ямар ч аргументыг зөвшөөрдөг бичлэг нь аливаа локал процесс туннелийг дахин тохируулах эсвэл зогсоох боломжийг олгоно. unit-д хэрэгтэй хоёр үйлдлийг өгч, үйлчилгээг зогсоох нь интерфейсийг аль хэдийн хаадаг бол задлалтыг түүнээс гадуур байлгана уу.
Энд харьцуулалт үр өгөөжөө өгдөг: unit, багцын мэдээллийн сан, sudoers бүгд нэг замыг нэрлэх ёстой. Тийм болбол дахин ачаалахгүйгээр, гурав дахь газарт binary файлын хуулбаргүйгээр EXEC алдаа арилна.
Дахин ачаалахаас өмнө шинжилсэн командыг нотлоорой
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-pagersystemctl show нь шийдвэрлэх гаралт, учир нь systemd-ийн үнэхээр шинжилсэн argv-г, ямар ч drop-in хамт хэвлэдэг. systemd-analyze verify дахин ачаалахаас өмнө байхгүй эсвэл гүйцэтгэгдэхгүй замыг барьж, дахин ачаалсны дараах status команд процесс одоо байгаа эсэхийг хэлнэ.
Хэрэв unit эхэлж, дараа нь бүтэлгүйтвэл та EXEC бүлгийг орхиж, клиентийн өөрийн алдаа боловсруулалтад орсон байна. Журналаас клиентийн мессежийг хайгаарай, өөр нэг execve бүтэлгүйтлийг биш. unit-ийн diff болон sudoers-ийн diff-ийг өөрчлөлтийн бүртгэлд хамт хадгал, дараагийн шинэчлэлт хуваагдсан замыг чимээгүйгээр буцааж оруулахгүйн тулд.