To nie jest żaden log, to po prostu podsumowanie zawartości instalacji i to wcale nie wszystkiego, lecz głównie tego co jest poza samym HA. Chociaż oczywiście cześć danych stanowi jakąś-tam diagnostykę…
Jeśli się przywróciło wszystko i działa poprawnie, to można używać, dysk masz za mały i trafi go szlag, ale przecież masz pozostałe egzemplarze o lepszych flakach.
W obecnej chwili tylko jedną instalację trzymam na wydaniu lutowym i to z powodu breaking change o której wiem i celowo nie aktualizowałem, bo nie mam weny żeby się tym zająć.
4 inne HAOS (2x HAOS-generic, 2x HAOS-SBC-RPi4) działają cały czas poprawnie, na wszystkich kolejnych wersjach core od 2024.3.0 po dzisiaj aktualną 2024.3.3
W wątku ze ścieżką aktualizacji zmienię treść ostrzeżenia, bo wygląda na to, że problemy mają tylko właściciele instalacji Supervised, czyli źródło problemów leży raczej w OSie hosta bądź innych składnikach niż w samym HA; oraz ewentualnie Ci, którzy przegapili czytanie notatek do wydań i dotknęły ich jakieś breaking changes.
Jeżeli będzie przez weekend latało wszystko na testowym HA 3 bez zastzreżeń po wszystkich aktualizacjach to w poniedziałek będzie akcja z HA 2 w docelowej lokalizacji a następnie z HA 1 i to w obu przypadkach już bez debiana na golasie.
Nauka nie idzie w las, będzie się trzeba odzwyczaić logowania do debka po putty no i rozgryść teraz jeszcze cloudflare do golasa zamiast do debiana… ehhh i znowu czytanko i kombinowanko
Podczas instalacji debiana na tutorialach kombinowali z ustawianiem partycji i ich wielkości w jakiś (nieznany dla mnie) sposób, że partycje były trzy… czy mając do dyspozycji dyski 250 i 500 GB lecimy z golasem na całym dysku bez partycjonowania na mniejsze czy coś byście radzili wydzielać?
Dziękuję wszystkim za uwagi, spostrzeżenia i dobre rady! Spokojnego łikendasa i pozdrówki
Można się logować po ssh tylko nie ma za bardzo po co, bo w systemie na instalacjach HAOS się nie grzebie (można w sumie w trybie deweloperskim, ale HAOS jest dla wygody używania, więc zwykły user nie ma potrzeby grzebania).
Zamiast rozgryzać możesz póki co użyć gotowca (host w domenie paczka.pro) ais-cloudflared dla zdalnego dostępu.
Swoją drogą jakieś wątki o cloudflared też tu są. Jakkolwiek w przypadku maszyny bez fizycznego dostępu dorzuciłbym jakiś backup w postaci tailscale czy zerotier (widzę, że i tak używasz).
Na początku miałem stałe IP w dwóch lokalizacjach, które miałem spięte tunelem za pomocą ubuquiti (UDM PRO + USG PRO). Nadszedł czas, że T-mobile już mnie tak wku**** (długa historia firmowego "nielimitowanego" dostępu, który ograniczali mi do 1MB/s... bo się ch*jom nie podobałem - za dużo dzieci oglądały Netflixa i byłem uciążliwy dla lokalnego społeczeństwa), że ich karty spłukałem w kiblu i ogarnąłem Starlinka oraz “darmowe” ale jakoś śmigające aero, w związku z czym zrobił się problem ze stałym IP.
Na ten ból z pomocą przychodził mi Zerotier (o ile po aktualizacji wstanie dodatek ). Za pomocą Zerotier właziłem sobie po znanych adresach ip tylko do debianka robić zdalnie update’y. W chwili obecnej nie będzie takiej potrzeby więc nie wiem czy Zerotier będzie mi nadal niezbędny (zakłądam, że przy HAOS wszystkie aktualizacje robimy z poziomu [ustawienia-system-aktualizacje].
Cloudflare natomiast ogarnia mi temat wystawienia na zewnątrz po przyjaznej domenie [znanej powiedzmy tylko mi] usług takich jak zewnętrzny adres na HA1, HA2, Qnap, bitwarden… - tak to miałem sobie wymyślone - przypominam, że jestem inżynierem sanitarnym
Znalazłem dosyć świeży wątek https://www.youtube.com/watch?v=rdQ-9Eoi6KU i zaraz go przetestuję na HA 3.
Co do nowego (jak dla mnie) sposobu instalacji HAOS poza środowiskiem debiana rodzi się pytanie w jaki sposób zadbać o bieżące aktualizacje czasu, który potrzebny jest do bitwardena aby dogadać się z tokenami 2fa? Na debianie co jakiś czas zapuszczałem w tym celu komendę ntpdate -u pool.ntp.org dla aktualizacji czasu serwera. Gdy tego nie zrobiłem miałem nieaktualne tokeny podczas autoryzacji.
HA 3 od wczoraj jest “zdrowe”. Jutro zacznę robić przeszczepy…
Skomentujecie jeszcze to zanim zacznę naprawę HA1 i HA2?
Coś czuję, że będę miał podobne odczucia co MariuszAK…
W tej kwestii nie umiem doradzić, przy instalacji HAOS masz 1 IP, a dodatkowe serwery instalowane jako Dodatki (w kontenerach którymi zarządza Supervisor) masz na różnych portach na tym samym adresie, więc pewnie dla zdalnego dostępu będziesz potrzebował ich interfejsów w sesjach ingress (to standardowy sposób umieszczenia GUI dodatków wewnątrz HA).
No cóż przez ostatnie kilka lat tylko raz był problem z aktualizacją Dodatku Zerotier, ale jest na to rada - backup w postaci Tailscale. Oczywiście w obu wypadkach trzeba pilnować by tokeny się nie przedawniły.
Jeśli masz łącze o mocno ograniczonym wolumenie danych, to trzeba pamiętać, że utrzymanie każdego tunelu kosztuje dodatkowy transfer na podtrzymanie tego tunelu.
Nie mam pojęcia.
Dobrze zakładasz - aktualizacje są w jednym miejscu w GUI i przynajmniej jeśli chodzi o OS i Supervisora to obsługa sprowadza się do kliknięcia (wręcz Supervisor się sam aktualizuje).
Oczywiście jest też możliwość ogarnięcia tych kwestii z command line w terminalu ssh (bez praw roota - jest uruchomiony wewnątrz kontenera), lub tylko lokalnie z CLI (lokalnej konsoli), no jest też tryb deweloperski - ssh na porcie 22222 (wymaga aktywacji, grzebanie w systemie nie jest wskazane).
Nie zauważyłem problemu braku synchronizacji czasu, HAOS sam to ogrania, ale nie wiem jak często, bo nie miałem nigdy takiego problemu.
Nie wiem na ile ta dokumentacja jest aktualna, więc proponuję najpierw przetestować, a dopiero w przypadku problemów grzebać, w razie czego masz ssh w trybie deweloperskim (jest nawet specjalizowany Dodatek do łatwego uruchamiania tego trybu, ale jeśli nie musisz to nie grzeb)
W przypadku “golasa” nie rządzisz partycjami (no umówmy się jeśli wiesz co robisz to można kombinować, ale 1. bez przesady, 2. odradzam). Obraz dysku zawiera właściwy układ docelowy, przepisując obraz robisz to w trybie surowego nośnika raw (nie ma mowy o partycjonowaniu, po prostu urządzenie blokowe zostaje nadpisane od samego początku adresowania, czyli w obszarze tablicy partycji, bootloadera itd. - otrzymujesz od razu spartycjonowany układ).
Standardowy układ partycji to
7 partycji systemowych - tego nie można ruszać, bo dzięki temu działają 2 sloty bootowania A/B i autonaprawa uszkodzonego systemu przez uruchomienie zapasowego systemu z nieaktywnego slotu (de facto to 1 partycja EFI i po 3 partycje na każdy system)
1 partycja danych (robocza, tam jest też instalowane wszystko co nie jest składnikiem OSa), i tą partycję skrypt pierwszego uruchomienia rozszerza na cały wolny obszar dysku (więc każda instalacja zawsze zajmie cały dysk fizyczny), ponadto ten skrypt jest uruchamiany przy każdym starcie (więc nawet jeśli sklonujesz całość 1:1 na większy nośnik to partycja sama urośnie, ale migrację sugeruję robić za pomocą backupu, a nie klonowania) i odpowiada też za inne rzeczy (jak np. partycja danych na osobnym nośniku niż system - dzięki temu można mieć HAOS na jakimś małym eMMC czy jedynym bootującym ssd, a dane na nośniku, z którego nie można boootować ze względu na ograniczenia spotykane w niektórych konstrukcjach sprzętu).
Po przepisaniu obrazu na nośnik masz standardowy układ partycji pustej instalacji (jest już 8 partycji w tym “za mała” partycja danych przed automatycznym rozszerzeniem), a tablica partycji nie pasuje do nośnika, nie należy tego naprawiać!, to załatwia skrypt startowy HAOS.
Z poziomu CF można ustawić subdomeny i łączyć się z dowolnym urządzeniem w naszej sieci za pomocą naszego tunelu i skonfigurowanego public hostname dla każdego urządzenia, które posiada dostęp webowy np. bitwarden.twoja_domena (CF → Zero Trust → Networks → Tunells → config tunelu → public hostnames).
Tak mam to właśnie wymyślone! Za pomocą CF wystawione mam na zewnątrz subdomeny do: HA, bitwardena HA1 i zapas na HA2 (sam nie wiem teraz po co, bo zazwyczaj nie mam potrzeby korzystać z niego z zewnątrz), i dla kumy (dla podpatrywania statusu HA2 na HA1 oraz HA1 na HA2 - lustrzanie się wzajemnie pingują na różnych “usługach”). Więcej “usług” dostępnych z zewnątrz jeszcze nie wymyśłiłem…
W CF fajne jest to, że wystarczy posiadanie jednej domeny w ich usłudze po czym dla wielu różnych urządzeń postawionych w różnych lokalizacjach można wykorzystać wiele subdomen tej samej (jednej) domeny głównej. Np qnap’a mam na subdomenie głównej HA2 pomimo, iż jest to kompletnie inne urządzenie w zupełnie innej (trzeciej) lokalizacji.
Z radością informuję odnosząc się do posta sympatycznego kolegi:
że, aktualnie po 4h przeszczepu, z sukcesem powiódł się przeszczep instancji HA 2. Dx0D D90D7 przyjął grzecznie na czystym HAOS backup, dodatki wszystkie wstały po drugim restarcie (należy o tym pamiętać, i było to wspominane powyżej) oraz faktycznie uważam, że chyba potrzebują czasu na “odbudowę” cokolwiek to nie oznacza, ponieważ ruszyły u mnie wszystkie po drugim strzale za wyjątkiem Zigbee2MQTT, który potrzebował chyba z godzinę aby się reaktywować i obudzić do życia.
Wstało także Zerotier - aczkolwiek nie wiem do czego ono teraz prowadzi… ? Adres klasy lokalnej w Zerotier widoczny jako zalogowany, ale putty odrzuca próbę wejścia pod ten adres. ?
Nie wstała usługa CF z oczywistych przyczyn (zalokowania pod debianem). Zgodnie z przytoczonym powyżej tutorialem wszystko wstało w 5 minut aczkolwiek grzebiąc teraz z ZeroTrust w nowym tunelu zarządzanym lokalnie w HA nie widzę tak na szybko opcji dołożenia kolejnych subdomen na tej samej maszynie (tak jak to wyglądało pod debianem). Będę musiał znowu pogrzebać aby to jakoś podokładać… Edit: znalezione w instrukcji CF w dodatku - ręcznie należy zdefiniować pożądane “additional_hosts” w konfiguracji CF w HA.
Tymczasem czas na kolejnego grzdyla i pod prysznic
1.) Znalazłem chwilę po wysłaniu posta - który już wyedytowałem, ale byłeś bardziej czujny i precyzyjny w swojej odpowiedzi. Sposób przetestowany z poziomu dodatku w HA - wszystko działą jak ta lala. Bardzo prosty, łatwy i przyjemny sposób.
2.) Przetestuję migrację CF z zarządzanego w HA do zarządzanego w CF podczas przeszczepu HA1.
Zostaje mi tu tylko dołożenie 2FA do pełni szczęścia.
Jak na chwilę obecną, nie myślałem, że to wszystko odbędzie się w tak przystępny i łatwy, mało problemowy sposób. Dużo pierdół robi się raz i dawno temu, nie wracając do nich powtórnie zbyt często, a właściwie póki się coś nie rozkrzaczy. Jak mi się te dyski posypały widziałem już mękę stawiania wszystkiego od nowa a tu taki piękny zaskocz! Jestem pod wrażeniem…
A dokąd prowadziło wcześniej?
Jeśli to był Dodatek to backup przechowuje (a przynajmniej powinien) jego konfigurację, więc m.in. klucze i tokeny, więc nie możesz równocześnie odpalić oryginalnej maszyny i odtworzonej z backupu.
Backup nie zawiera zawartości kontenerów (o ile Dodatki są odpowiednio przygotowane, a miażdżąca większość jest) tylko ich konfigurację, więc odtworzenie backupu na instalacji nie zawierającej kontenera powoduje najpierw jego zbudowanie - to tak jakbyś miał samą konfigurację jakiegoś programu, ale bez samego programu - do wykorzystania danych z backupu musisz go najpierw zainstalować, a tu to się dzieje automatycznie i to jest ta odbudowa - zawartość kontenerów jest budowana z danych które są gdzieś w repozytoriach w internecie (np. na Docker Hub).
Prowadziło raczej do środowiska debiana, po zalogowaniu leciała komenda su - a potem te słynne apt update && apt upgrade && apt autoremove -y i wszystko hulało jak ta lala. A teraz… hmmm ?
…no OK, to by się zgadzało, ponieważ podczas przywracania backupu terminal żarł internet jak pies kota Najwidoczniej odbudowuje się to także po wstaniu systemu, zalogowaniu i nazwijmy to pracy na odtworzonym (odtwarzającym się jeszcze) systemie.
Nie wiem jaką konkretnie masz konfigurację, ale tunel w najbardziej typowej prowadzi do IP w podsieci tego VPN, więc spodziewam się, że na porcie 8123 będziesz miał tam zwykłe GUI HA, na 4357 obserwatora Supervisora (też do otwarcia w przeglądarce), a na innych portach te usługi które są wystawiane przez jakieś inne serwery.
). Za pomocą Zerotier właziłem sobie po znanych adresach ip tylko do debianka robić zdalnie update’y. W chwili obecnej nie będzie takiej potrzeby więc nie wiem czy Zerotier będzie mi nadal niezbędny (zakłądam, że przy HAOS wszystkie aktualizacje robimy z poziomu [ustawienia-system-aktualizacje].
Za pomocą CF wystawione mam na zewnątrz subdomeny do: HA, bitwardena HA1 i zapas na HA2 (sam nie wiem teraz po co, bo zazwyczaj nie mam potrzeby korzystać z niego z zewnątrz), i dla kumy (dla podpatrywania statusu HA2 na HA1 oraz HA1 na HA2 - lustrzanie się wzajemnie pingują na różnych “usługach”). Więcej “usług” dostępnych z zewnątrz jeszcze nie wymyśłiłem… 
