Outline na ARM: którą kompilację wybrać i kto ją utrzymuje?
Etykieta ARM64 odpowiada na jedno pytanie. Zdecyduj, kto zbudował klienta Outline, którą wersję źródła reprezentuje i kto dostarcza aktualizacje po pierwszym połączeniu.
Etykieta ARM64 rozstrzyga jedno pytanie o zgodność i pozostawia trzy trudniejsze otwarte. Nie mówi, kto wyprodukował plik wykonywalny, z której wersji źródła pochodzi ani kto dostarczy następną poprawkę bezpieczeństwa. Gdy stara odpowiedź na forum wskazuje kompilację społeczności, te pytania decydują, czy instalacja jest do obrony. Oddziel je, zanim cokolwiek pobierzesz.
Menedżer czy klient: najpierw wybierz właściwy artefakt
Outline dostarcza menedżer do administrowania serwerami i klienta do łączenia urządzeń, a są to osobne aplikacje. Repozytorium nadrzędne rozróżnia obie role i prowadzi do ich własnych kanałów instalacji. Zainstalowanie menedżera na Raspberry Pi nie daje klienta dla tego Pi. Oba kanały aktualizują się też według różnych harmonogramów. Istnieją obie role, więc pytanie brzmi, którą rolę ma odgrywać urządzenie.
Sprawdź bieżący kanał klienta dla systemu operacyjnego, którego używasz. Ogólny wpis Linux nie jest macierzą architektur i nie jest obietnicą dotyczącą każdej płytki. Czytaj stronę pobierania jako listę tego, co istnieje, a nie listę tego, co powinno istnieć.
Historyczne zgłoszenie z prośbą o obsługę ARM nic nie mówi o tym, co jest publikowane dziś. Traktuj je jako zapis dawnej luki, a nie oświadczenie o teraźniejszości. Kanał, z którego możesz pobierać, jest jedynym dowodem, który się liczy.
Jaką architekturę naprawdę uruchamia zainstalowany system?
Zapisz wydanie i badany artefakt, nie tylko nazwę płytki. Dopasuj plik wykonywalny i jego natywne komponenty do celu, ponieważ jądro 64-bitowe może uruchamiać 32-bitową przestrzeń użytkownika, a etykieta na pudełku nie powie ci która.
Źródła klienta zawierają wspólny kod interfejsu i komponenty specyficzne dla platformy. Przebudowa samego interfejsu nie jest portem platformy, choćby kompilowała się czysto. Natywne elementy to miejsce, w którym architektura naprawdę się ujawnia. Przebudowa dotykająca tylko interfejsu uruchomi się i nadal zawiedzie po stronie natywnej.
uname -m oraz architektura pakietu zainstalowanego systemu to dwa fakty, które tu mają znaczenie. Odczytaj je na urządzeniu, nie na maszynie, z której budujesz. Niezgodność na tym etapie unieważnia każde późniejsze porównanie.
Kompilacja społeczności dodaje właściciela wydania
Jeśli oficjalny kanał nie ma obsługiwanego artefaktu dla twojego celu, kompilacja społeczności staje się decyzją o wdrożeniu, a nie instalacją. Zidentyfikuj wydawcę, wersję źródła, zmiany względem repozytorium nadrzędnego i instrukcje budowania.
Następnie zapytaj, jak przyszłe poprawki docierają do instalacji. Aktualizacje mogą pochodzić z repozytorium nadrzędnego, z forka lub z ręcznej przebudowy, o której ktoś musi pamiętać. Trzecia opcja to ta, która po cichu przestaje się zdarzać.
Repozytorium wyglądające na aktualne nic nie mówi o tym, która wersja wytworzyła binarię, którą już masz. Porównaj instrukcje budowania z tym, co artefakt mówi o sobie. Jeśli oba się nie zgadzają, artefaktowi nie należy ufać.
Co suma kontrolna dowodzi, a czego nie
Suma kontrolna identyfikuje określone bajty. Suma kontrolna opublikowana przez tego samego nieoficjalnego budowniczego nie czyni go projektem nadrzędnym i nie mówi, co zawierają te bajty. Odpowiada na pytanie, czy pobranie dotarło nienaruszone, co jest pytaniem użytecznym, ale wąskim. To właściwość pliku, a nie osoby, która go opublikowała.
Zrzut ekranu z udanym uruchomieniem jest dowodem dotyczącym jednej maszyny. Nie jest przeglądem binarii ani jej kanału aktualizacji. Żaden z tych artefaktów nie zastępuje czytania źródła.
Trzymaj nieznaną kompilację z dala od sekretów produkcyjnych, dopóki pochodzenie i wymagane uprawnienia nie zostaną sprawdzone. Uruchom ją najpierw w środowisku jednorazowym, z własnym kontem. To jest tanie i zamienia opinię w test.
Zdecyduj, czy to eksperyment, czy urządzenie
Administrator może świadomie zbudować sprawdzone źródło dla obsługiwanego celu i wziąć odpowiedzialność za zależności, pakowanie i aktualizacje. To inny model wsparcia niż instalacja utrzymywanego artefaktu nadrzędnego. Dla urządzenia bez nadzoru wybierz model, który odpowiedzialny właściciel zdoła utrzymać.
Zapisz tożsamość artefaktu, platformę, wynik weryfikacji i właściciela aktualizacji obok wdrożenia. Decyzja jest kompletna, gdy te elementy się zgadzają, a nie gdy binaria ARM uruchomi się raz.