Чи підходить старий .deb openfortivpn вашому Raspberry Pi?
Архівний .deb для armhf фіксує випуск, якому ваш 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 плюс маршрути і власник резолвера. Завершена транзакція пакета нічого не доводить про те, чи приймає шлюз обліковий запис або чи доступний приватний діапазон. Перевіряйте кожен шар там, де він ламається, замість повторного запуску інсталятора.
План, який має замінити старе ім'я файлу
Спочатку запишіть ідентичність платформи: випуск ОС, архітектуру і список використовуваних джерел. Потім назвіть дозволене місце, звідки надходить пакет — чи то репозиторій дистрибутива, репозиторій постачальника із закріпленим ключем або збірка, яку ви самі компілюєте й пакуєте.
Нарешті, назвіть супровідника і шлях оновлення. Pi, на якому працює клієнт, яким ніхто не володіє, працюватиме до першого оновлення бібліотеки, а потім ту саму тему на форумі знову знайде хтось із тією ж проблемою.
Виправлене переконання достатньо просте, щоб сформулювати одним рядком: старий пакет — це доказ, що клієнт колись збирався і працював, а не доказ, що він встановиться на вашій платі сьогодні ввечері. Перевірте три осі, потім виберіть канал, який ви можете продовжувати оновлювати.