VPN xidməti EXEC mərhələsində uğursuz olur: unit, ikili fayl və sudoers-i müqayisə edin

Dünən tunel işləyirdi, bu səhər isə unit jurnalda Failed at step EXEC spawning /usr/local/bin/vpnclient ilə ölüdür. Etimad məlumatları, marşrutlar və hesab heç vaxt bu cümləyə daxil olmur. systemd ExecStart dəyərini bir yola çevirdi, kerneldən onu icra etməyi xahiş etdi və kernel imtina etdi; çox vaxt səbəb həmin yolda heç nəyin olmaması və ya onun icra oluna bilməməsidir. Təhlil edilmiş əmr əksini sübut edənə qədər nasazlığı fayl və argv problemi kimi qəbul edin.

Niyə EXEC autentifikasiya başlamazdan əvvəl uğursuz olur

systemd ExecStart-ı shell vasitəsilə işə salmır. O, prosesi fork edir, sətirdən arqument vektoru qurur və birinci element üzərində execve çağırır. Əgər bu çağırış uğursuz olarsa, xidmət heç vaxt VPN müştərisinin öz koduna çatmır, ona görə profil düzəlişi və ya etimad yoxlaması kömək etmir.

Status kodu bu ailəni adi qəzalardan ayırır. status=203/EXEC ilə çıxan unit heç vaxt proses başlatmamışdır; başlayıb sonra status=1 ilə çıxan unit isə autentifikasiya, DNS və ya marşrutlaşdırma mərhələsində uğursuz ola bilər. Kodu müştəri jurnalından əvvəl oxuyun, çünki birinci halda müştəri jurnalı boş olacaq.

Jurnaldakı yol systemd-nin istifadə etdiyi yoldur, sizin düzəltdiyiniz yol olmaya bilər. Drop-in faylları və generator çıxışı vendor faylını üstələyə bilər, köhnə daemon-reload isə köhnə sətri yaddaşda saxlayır. Ona görə ilk diaqnostika dəyişdiyinizi xatırladığınız faylı açmaq deyil, systemd-dən onun əmri nə saydığını soruşmaqdır.

İkili fayl yolunun yazıldığı üç yer

Distributiv paketindən, vendor skriptindən və reliz tarballından quraşdırılan VPN müştərisi üç fərqli prefiksə düşə bilər. Unit, imtiyaz qaydası və quraşdırıcı bu prefikslərdən birini qeyd etmişdi və nasazlıq üçündən ikisi uyğun gəlmədikdə ortaya çıxır.

Konkret uyğunsuzluq belə görünür: vendor skripti /usr/local/bin qovluğuna quraşdırır, tarball /opt altında açılmışdır, unit isə hələ də əvvəlki paketdən qalan köhnə /usr/bin yolunu göstərir. Bu fayllardan yalnız biri mövcuddur və bu, nadir hallarda ExecStart-da göstərilən fayl olur.

Hər iki faylı dəyişməzdən əvvəl hansı yolun kanonik olduğuna qərar verin. Əgər ikili fayl distributiv paketinə aiddirsə, paket yolu kanonikdir və unit ona uyğun olmalıdır. Əgər vendor skriptinə aiddirsə, eyni qayda vendor prefiksi üçün də keçərlidir. İkili faylı prefikslər arasında kopyalamaq, növbəti yeniləmədə bir-birindən ayrılan iki nüsxə yaradır.

Sitat içindəki əmr fayl adına çevrildikdə

İkinci nasazlıq rejimi eyni jurnal sətrinin arxasında gizlənir. Kimsə bunu unit-ə yazır və müştərinin yükləmə zamanı qoşulacağını gözləyir:

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

systemd dəyəri sözlərə bölür, buna görə də birinci söz — dırnaqlar qruplaşdırma sintaksisi kimi çıxarılmaqla — /usr/bin/vpnclient connect office olur. Sonra kernel adında boşluq olan fayl axtarır və belə fayl mövcud deyil. Xəta ikili fayl quraşdırılmış olsa da, itkin ikili fayl xətası ilə eynidir.

Dəstəklənən forma ayrı arqumentlərlə davam edən real icra olunan fayldır, məsələn ExecStart=/usr/bin/vpnclient connect office. Əgər iş axını həqiqətən boru xətti və ya zəncir tələb edirsə, onu skriptə qoyun və skripti çağırın, çünki ExecStart-da && yoxdur, boru yoxdur və glob genişlənməsi yoxdur.

Fayl sistemini deyil, unit-i düzəldin

Cazibədar təmir gözlənilən yoldan real ikili fayla simvolik link yaratmaqdır. Bu, paket yenilənənə və link silinmiş fayla işarə edənə qədər, ya da SELinux etiketi hədəfə uyğun gəlməyənə qədər işləyir. Vendor faylı toxunulmaz qalmaqla yeniləmələr proqnozlaşdırıla bilsin deyə, unit-i drop-in vasitəsilə düzəltmək daha yaxşıdır.

İmtiyaz qaydası eyni yol və eyni alt əmrlərlə uyğun olmalıdır. /usr/local/bin/vpnclient üçün sudoers sətri /usr/bin/vpnclient üçün icazə vermir, hər arqumentə icazə verən sətir isə istənilən lokal prosesə tuneli yenidən konfiqurasiya etmək və ya dayandırmaq imkanı verir. Unit-in ehtiyac duyduğu iki əmri verin və xidmətin dayandırılması interfeysi artıq bağlayırsa, sökülməni ondan kənarda saxlayın.

Müqayisə burada bəhrəsini verir: unit, paket verilənlər bazası və sudoers hamısı bir yolu göstərməlidir. Belə olduqda EXEC xətası yenidən başlatma olmadan və ikili faylın üçüncü yerdə nüsxəsi olmadan yox olur.

Yenidən başlatmadan əvvəl təhlil edilmiş əmri sübut edin

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 həlledici çıxışdır, çünki systemd-nin həqiqətən təhlil etdiyi argv-ni, o cümlədən istənilən drop-in-i çap edir. systemd-analyze verify yenidən başlatmadan əvvəl itkin və ya icra olunmayan yolu tutur, yenidən başlatmadan sonra status əmri isə prosesin artıq mövcud olub-olmadığını bildirir.

Əgər unit başlayıb sonra uğursuz olursa, siz EXEC ailəsindən çıxmısınız və müştərinin öz xəta idarəetməsinə daxil olmusunuz. Jurnalda növbəti execve uğursuzluğunu deyil, müştərinin mesajını yoxlayın. Unit diff-i ilə sudoers diff-ini dəyişiklik qeydində birlikdə saxlayın ki, növbəti yeniləmə bölünmüş yolu səssizcə geri gətirməsin.