Дали стариот openfortivpn .deb е соодветен за вашиот Raspberry Pi?

Одговор на форум ви дава целосно име на датотека, а името изгледа како решението: еден .deb, една команда, готово. Она што таа низа всушност го кодира е верзија на пакет, архитектура на процесор и дистрибуцискиот сет против кој е изграден во денот кога некој ја напишал објавата. Ниту едно од тие три автоматски не ја опишува плочата на вашата маса. Старото преземање е снимка од состојбата на една машина, а не план за инсталација за вашата.

Што името на датотеката тивко фиксира

Читајте име како openfortivpn_1.17.0-1_armhf.deb од десно кон лево. Наставката е архитектурата за која е компајлирана бинарната датотека, средното поле е ревизијата на upstream и пакувањето, а имплицитното четврто поле е библиотечниот сет на сетот во кој е изградена.

На 64-битна инсталација на Raspberry Pi OS системската архитектура е arm64, па dpkg -i одбива пакет armhf поради несовпаѓање на архитектурата. Дури и каде multiarch овозможува инсталација, бинарната датотека очекува верзии на библиотеките од изданието против кое е изградена, а понов базен систем можеби повеќе не ги обезбедува. Резултатот е инсталиран пакет чија извршна датотека не може да се стартува, и тоа е дефектот што луѓето обично погрешно го припишуваат на самиот клиент.

Тоа што плочата е ARM уред не го прави ARM пакетот соодветен. Архитектурата е една оска; изданието и ABI се другите две, и тие не успеваат независно.

Прашајте ја дистрибуцијата пред да побарате линк за преземање

Секој одржуван канал може да ви каже што би инсталирал во моментов. Извршете го барањето на целната машина, со складиштата што таа навистина ги користи, пред да разгледате какво било пренесување на датотека.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

Ред со кандидат што содржи верзија и име на складиште значи дека дистрибуцијата веќе има изградба за овој систем. Отсуство на кандидат, или кандидат од сет што не сте имале намера да го користите, е информација за вашите извори, а не за тоа дали софтверот постои некаде.

Ако освежувањето на метаподатоците не успее, држете го тој неуспех одвоен од прашањето за пакетот. Резолуцијата на имиња, транспортот на складиштето, отсутниот Release потпис и сетот на крајот од животот сите го кршат apt update пред клиентот воопшто да биде вклучен. Поправањето на изворите е друга задача од изборот на VPN клиент, а мешањето на двете е начинот на кој луѓето насочуваат актуелен систем кон застарен издание.

Што проверува apt и што не добива преземена датотека

Нормалната инсталација следи синџир на потписи: архивата го потпишува својот индекс, индексот носи хешови за секој пакет, и пакетот мора да одговара. референца за автентикација на архивата го одвојува тој синџир од идејата да се проверува потпис прикачен на секоја поединечна датотека.

Датотека зачувана од стар HTTP линк нема ништо од тоа. Таа пристигнува без идентитет на складиште, не се ажурира кога дистрибуцијата го поправа клиентот, и ништо не запишува кој е одговорен да ја замени. Тоа и понатаму може да биде легитимен избор за администратор со фиксиран артефакт, но изборот мора да дојде со сопственик, некаде запишана контролна сума и план за следното безбедносно ажурирање.

Потиснувањето на грешките при потпис или исклучувањето на TLS проверката за да продолжи да работи стара инструкција го отстранува единствениот дел од процесот што проверуваше нешто. Наместо тоа вратете ја проверката што не успева.

Инсталирајте го клиентот, потоа одделно отстранувајте грешки во врската

Кога постои одржуван кандидат, инсталирајте го преку нормалната прегледана трансакција и оставете менаџерот на пакети да запише што направил.

Ако распоредувањето навистина бара изградба од upstream, следете ги тековните упатства за изградба на проектот и третирајте го како софтвер што сега го одржувате: пакетите за развој, pkg-config, заглавијата на TLS библиотеката и PPP демонот се вистински зависности, како и постапката за отстранување што ќе ви треба подоцна.

Инсталацијата е само локалната софтверска фаза. Порталната страница мора да го прифати протоколот и текот на автентикација на клиентот, клиентот мора да верува во сертификатот што го презентира порталот, а тунелот бара работен PPP слој плус рути и сопственик на resolver. Завршена трансакција на пакет не докажува ништо за тоа дали порталот ја прифаќа сметката или дали приватниот опсег е достапен. Тестирајте го секој слој таму каде што се крши, наместо повторно да го стартувате инсталаторот.

Планот што треба да го замени старото име на датотека

Прво запишете го идентитетот на платформата: издание на ОС, архитектура и списокот на извори што се користат. Потоа наведете го овластеното место од каде доаѓа пакетот, било да е тоа дистрибуциско складиште, складиште на добавувач со фиксиран клуч или изградба што самите ја компајлирате и пакувате.

На крајот наведете го одржувачот и патеката за ажурирање. Pi што извршува клиент што никој не го поседува ќе продолжи да работи до првото ажурирање на библиотека, а потоа истиот форумски тред повторно ќе го најде некој со истиот проблем.

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