OpenVPN 3 Python xətası: aləti düzəldin, sistem Python-unu yox
Traceback frontend-i işə salan interpretatoru göstərir, tunelə sahib olan xidməti yox. Sistemdə bir şeyi dəyişməzdən əvvəl ikisini müqayisə edin.
VPN idarəetmə əmri başlayanda traceback görünür və ilk instinkt başqa bir Python quraşdırmaq və ya sistemin standart interpretatorunu başqa yerə yönəltmək olur. Bu instinkt bir-biri ilə heç bir əlaqəsi olmayan iki runtime-ı qarışdırır. Biri əməliyyat sisteminə və onun paketlənmiş alətlərinə aiddir; digəri qurduğunuz hansısa layihəyə aiddir. İkincini təmin etmək üçün birincini dəyişmək işlək masaüstünün paket menecerini itirməsinin yoludur.
Müqayisə etməyə dəyər olan şey faktiki uğursuz olan komponentlə dəyişməyə haqqınız olan runtime arasındadır. Onlar demək olar ki, heç vaxt eyni obyekt deyil.
Bir kimi görünən iki Python sualı
Birinci sual budur: traceback-i çap edən proqramı hansı interpretator işə saldı? İkincisi: layihəm hansı interpretatordan istifadə etməlidir? Terminalda onlar eyni görünür, çünki hər ikisinə python3 yazmaqla cavab verilir və onların sahibləri, yeniləmə yolları və təsir radiusları fərqlidir.
Sistem aləti öz distributivinin təqdim etdiyi interpretatora, həmçinin həmin interpretatorun ABI-nə qarşı qurulmuş kompilyasiya olunmuş modullara bağlıdır. Layihə isə onun üçün yaratdığınız mühitə bağlıdır. Sistem standartını köçürmək birincini maşındakı bütün alətlər üçün eyni anda dəyişir; mühit yaratmaq ikincini bir qovluq üçün dəyişir.
Bu əməliyyatlardan yalnız biri bir dəqiqə ərzində geri qaytarıla bilər. O, birinci deyil.
Xətanı hansı komponent yaratdı
Başqa heç nə oxumazdan əvvəl traceback-in ilk sətrini və onu yaradan icra olunan faylı oxuyun. Əmr sətri frontend-i, imtiyazlı xidmət və API bağlantıları ayrı hissələrdir və onlardan yalnız bəziləri ümumiyyətlə Python-dur.
command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager
Skriptin ilk sətri istifadə edəcəyi interpretatoru adlandırır və traceback məhz həmin interpretatordan gəlir. Paket sorğusu faylın kimə aid olduğunu bildirir, bu da onu kimin dəyişə biləcəyini müəyyən edir. Xidmət statusu tamamilə başqa suala cavab verir: sessiyaları həqiqətən quran imtiyazlı backend işləyirmi.
Modul idxal xətası, D-Bus aktivləşdirməsinin rədd edilməsi və rədd edilmiş etimadnamə üç fərqli mərhələdir. İdxal xətası hələ heç bir sessiya yoxkən baş verir, ona görə heç bir VPN konfiqurasiyası onu düzəltməyəcək və işlək xidmət də onu düzəltməyəcək. Mesajı bu üç mərhələdən birinə aid etmək əsl ilk addımdır.
Layihə mühiti nəyi düzəldə bilər, nəyi bilməz
Layihə mühiti layihə problemini həll edir: bir tətbiqin ehtiyac duyduğu dəqiq kitabxana versiyalarını hər şeydən təcrid edilmiş şəkildə. Bu, həqiqətən faydalıdır və uğursuz proqram sizin sahib olduğunuz skript olduqda düzgün alətdir.
uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'
İkinci əmr verilmiş interpretatorun bağlantıların hansı nüsxəsini görə bildiyini göstərir, bu da itkin paketi kölgələnmiş paketdən ayırmağın ən sürətli yoludur. Onu uğursuz skriptin istifadə etdiyi interpretatorla işə salın, təsadüfən işləyən başqa biri ilə yox.
Layihə mühitinin edə bilmədiyi şey distributiv tərəfindən paketlənmiş frontend-i təmir etməkdir. Həmin proqramın asılılıqları paket menecerinin seçdiyi interpretator üçün qurulub və onu layihənizin mühiti daxilində işə salmaq ya uğursuz olur, ya da heç kimin dəstəkləmədiyi qarışıq yaradır. Mühit dəyişəni ilə ona yollar yeritmək əlavə addımlarla eyni səhvdir: alətin nəyi yüklədiyini dəyişdiniz, lakin nəyə qarşı sınaqdan keçirildiyini dəyişmədiniz. Bu mübadilə elə bir düzəliş kimi görünür ki, növbəti idxala qədər davam edir.
Sistem interpretatorunu yenidən yönəltmək niyə tələdir
Standart interpretatoru dəyişmək cəlbedicidir, çünki traceback-i bir əmrlə düzəldirmiş kimi görünür. O, həm də hostdakı hər paketlənmiş Python alətinin üzərində qurulduğu fərziyyəni pozur və nasazlıqlar sonra, əlaqəsiz yerlərdə üzə çıxır.
Alternativ seçmə mexanizmləri ekvivalent tətbiqlər arasında keçid etmək üçün nəzərdə tutulmuşdu, köhnə kompilyasiya olunmuş modullar altına daha yeni dil quraşdırmaq üçün yox. Kompilyasiya olunmuş genişləndirmələr müəyyən ABI üçün qurulur, ona görə dünən idxal olunan modul bu gün heç bir paket silinmədən yüklənə bilməz.
İnsanların tapdığı məsləhətdə həm də ad tələsi var. Versiyasız python əmri distributivlər və mühitlər üzrə vahid məna daşımır və onu müəyyən əsas versiya üçün sabit sinonim kimi qəbul etmək yalnız yazıldığı maşında işləyən düzəlişlər yaradır. Bloq yazısındakını deyil, qarşınızdakı sistemin siyasətini oxuyun.
Ayrı qəbul testləri
Sonda iki test olmalıdır və birinin keçməsi digəri haqqında heç nə demir. Birincisi odur ki, dəstəklənən müştəri əmri paketləndiyi interpretatorla işləyir. İkincisi odur ki, imtiyazlı xidmət sessiya qurur və tunel trafik daşıyır.
openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0
İşləyərkən maşına müstəqil giriş yolunu saxlayın, xüsusən VPN sizin yeganə inzibati girişinizi daşıyırsa. Sistem interpretatoruna edilən dəyişiklik həmin girişi yolda aradan qaldıra bilən düzəliş növüdür.
Nasazlıq sistem aləti üçün itkin moduldursa, düzəliş dəstəklənən iş axını vasitəsilə paket əməliyyatıdır. Nasazlıq öz layihənizdə versiya konfliktidirsə, düzəliş mühitdir. Bu ikisi arasında seçim bütün qərardır və onu traceback-i hansı proqramın çap etdiyi müəyyən edir.