Грешка в Python на OpenVPN 3: поправете инструмента, а не системния Python

Проследяване се появява, когато стартира команда за управление на VPN, и първият подтик е да се инсталира друг Python или системната настройка по подразбиране да се насочи другаде. Този подтик смесва две среди за изпълнение, които нямат нищо общо една с друга. Едната принадлежи на операционната система и нейните пакетирани инструменти; другата принадлежи на какъвто и проект да изграждате. Смяната на първата, за да се удовлетвори втората, е начинът, по който работещ настолен компютър губи мениджъра си на пакети.

Сравнението, което си струва, е между компонента, който действително се е провалил, и средата за изпълнение, която имате право да промените. Те почти никога не са един и същ обект.

Два въпроса за Python, които изглеждат като един

Първият въпрос е: кой интерпретатор е стартирал програмата, която отпечата проследяването? Вторият е: кой интерпретатор трябва да използва моят проект? В терминала те изглеждат идентични, защото и на двата се отговаря с писане на python3, и имат различни собственици, различни пътища за обновяване и различен радиус на действие.

Системният инструмент е вързан към интерпретатора, с който е доставена дистрибуцията му, заедно с компилираните модули, изградени срещу ABI на този интерпретатор. Проектът е вързан към каквато среда създадете за него. Преместването на системната настройка по подразбиране променя първото за всеки инструмент на машината наведнъж; създаването на среда променя второто за една папка.

Само едно от тези действия е обратимо за минута. И то не е първото.

Кой компонент е произвел грешката

Прочетете първия ред на проследяването и изпълнимия файл, който го е произвел, преди да четете каквото и да е друго. Фронтендът на командния ред, привилегированата услуга и обвързванията на API са отделни части и само някои от тях изобщо са Python.

command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager

Първият ред на скрипта назовава интерпретатора, който ще използва, и това е интерпретаторът, от който е дошло проследяването. Заявката към пакетите ви казва кой притежава файла, а това решава кой има право да го промени. Състоянието на услугата отговаря на съвсем друг въпрос: дали работи привилегированият бекенд, който действително установява сесии.

Грешка при импортиране на модул, отказ на активиране по D-Bus и отхвърлени идентификационни данни са три различни етапа. Грешката при импортиране възниква преди да съществува каквато и да е сесия, така че никаква настройка на VPN няма да я поправи и работеща услуга също няма да я поправи. Подреждането на съобщението в един от тези три етапа е истинската първа стъпка.

Какво може и какво не може да поправи проектна среда

Проектната среда решава проблем на проекта: точните версии на библиотеките, от които се нуждае едно приложение, изолирани от всичко останало. Това е наистина полезно и е правилният инструмент, когато провалилата се програма е скрипт, който притежавате.

uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'

Втората команда показва кое копие на обвързванията вижда даден интерпретатор, което е най-бързият начин да различите липсващ пакет от засенчен. Стартирайте я с интерпретатора, който използва провалилият се скрипт, а не с друг, който случайно работи.

Това, което проектната среда не може да направи, е да поправи фронтенд, пакетиран от дистрибуцията. Зависимостите на тази програма са изградени за интерпретатора, който мениджърът на пакети е избрал, и стартирането ѝ вътре в средата на вашия проект или се проваля, или произвежда смес, която никой не поддържа. Инжектирането на пътища в нея чрез променлива на средата е същата грешка с допълнителни стъпки: променили сте какво зарежда инструментът, без да промените срещу какво е тестван. Тази размяна изглежда като поправка точно толкова дълго, колкото е нужно, за да попаднете на следващия импорт.

Защо пренасочването на системния интерпретатор е капан

Промяната на интерпретатора по подразбиране е привлекателна, защото изглежда, че поправя проследяването с една команда. Тя също нарушава допускането, върху което е изграден всеки пакетиран инструмент на Python на хоста, а отказите се появяват по-късно и на несвързани места.

Механизмите за избор на алтернатива са създадени да превключват между равностойни реализации, а не да инсталират по-нов език под по-стари компилирани модули. Компилираните разширения се изграждат за конкретен ABI, така че модул, импортиран вчера, днес може да не се зареди, без да е премахнат нито един пакет.

Има и капан с името в съвета, който хората намират. Командата python без версия няма едно универсално значение в различните дистрибуции и среди и третирането ѝ като фиксиран синоним на определена основна версия дава поправки, които работят само на машината, където са написани. Четете политиката на системата пред вас, а не тази от публикацията в блога.

Отделни приемателни тестове

Накрая трябва да има два теста и преминаването на единия не казва нищо за другия. Първият е, че поддържаната клиентска команда работи с интерпретатора, за който е пакетирана. Вторият е, че привилегированата услуга установява сесия и тунелът пренася трафик.

openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0

Пазете независим път до машината, докато работите, особено ако VPN носи единствения ви административен достъп. Промяната на системен интерпретатор е точно онази редакция, която може да отнеме този достъп по средата.

Ако отказът е липсващ модул за системен инструмент, корекцията е операция с пакет през поддържания работен процес. Ако отказът е конфликт на версии във вашия собствен проект, корекцията е среда. Изборът между тези две е цялото решение и той се определя от това коя програма е отпечатала проследяването.