Znikające ustawienia karty sieciowej

Cześć,
Zauważyłem występujący od pewnego czasu problem z ustawieniami sieciowymi. Po każdym restarcie serwera w Ustawienia > System > Sieć > Konfiguracja interfejsów sieciowych: IPv4 jest ustawiona na “Wyłączona”
Serwer stoi na Debianie z Dockerem, ma przypisane stałe IP, router prowadzi komunikację na niego bez problemu, więc HA jest dostępny zarówno z sieci lokalnej jak i z zewnątrz.
Problem pojawia się gdy chcę przeprowadzić aktualizację - np. dziś update Z2M HA twierdzi, że nie da się tego zrobić bo nie ma dostępu do internetu: “niepowodzenie wykonania akcji update/install. Error updating Zigbee2MQTT: ‘AddonManager.update’ blocked from execution, no host internet connection”

Po ręcznym wpisaniu IP, maski, bramy w Ustawienia > (…) > IPv4 aktualizacja działa. I tak do kolejnego restartu serwera.
Jak widać z problemem da się żyć, ale jest nieco upierdliwy, dlatego zastanawiam się jak to ogarnąć jakimś stałym rozwiązaniem. Ktoś poratuje jakimś pomysłem? :slight_smile:

Z tego co rozumiem nie masz HA os tylko sam sobie hostujesasz dockera i w nim masz HA. Jesli masz klopot zeby ustawic seiciowke z poziomu systemu to po prostu ustaw rezerwacje IP na routerze dla maca tej sieciowki jaka sie zglasza twoja instancja HA.

Z tego co rozumiem nie masz HA os tylko sam sobie hostujesasz dockera i w nim masz HA

Dokładnie tak

to po prostu ustaw rezerwacje IP na routerze

To nie jest problemem. Serwer ma ustawione w debianie stałe IP i się go trzyma, jak wspomniałem we wcześniejszym poście. Gdy HA ma “wyłączone” IPv4, zarówno HA jak i pozostałe usługi na serwerze działające w dockerze (jak np Calibre do ebooków, Omada Controller) jak i działające “bezpośrednio” (jak np SMB) funkcjonują bez przeszkód. Więc to tylko HA “myśli sobie” że IPv4 jest wyłączone, a nie jest :slight_smile:
Problem w tym by “przekonać go”, że wszystko działa i ma np. ściągać sobie aktualizacje bez szemrania.

hmmm a w konfigu kontenera dockera masz ustawiona siec jako host czy masz jakas konfiguracje sieciowa zrobiona osobna dla tego kontenerka?

Kontener główny - ‘homeassistant’ ma sieć ustawioną jako “host”, ale już “hassio_supervisor” ma następującą konfigurację:

Może to tutaj coś się namieszało?

Jakbyś tu namieszał to cały HA by się wyłożył.

A w konsoli ssh pingi ci chodzą?

Sprawdź co masz w sudo nano /etc/resolv.conf

Jeżeli masz pusto dopisz DNS

nameserver 8.8.8.8
nameserver 194.204.159.1
nameserver 194.204.152.34

I zrestartuj usługę

sudo systemctl restart systemd-resolved.service
1 polubienie

UWAGA dawne tepsiane DNSy nie są obecnie dostępne u każdego operatora, zdecydowanie lepiej wstawić DNSy swojego operatora (zaleta jest taka, żę zawsze są najbliżej) ewentualnie cloudflare (1.1.1.1 i 1.0.0.1), quadnine (9.9.9.9 i 9.9.9.10) czy jakiekolwiek inne naprawdę ogólnodostępne.

Pingi bez zarzutu:

michal@szrank:~$ ping google.pl
PING google.pl (142.250.203.195) 56(84) bytes of data.
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=1 ttl=113 time=13.5 ms
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=2 ttl=113 time=12.8 ms
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=3 ttl=113 time=10.8 ms
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=4 ttl=113 time=10.1 ms
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=5 ttl=113 time=10.3 ms
64 bytes from waw02s22-in-f3.1e100.net (142.250.203.195): icmp_seq=6 ttl=113 time=10.2 ms

W /etc/resolv.conf jest jedynie odwołanie do 127.0.0.53. Ręczne nadpisanie pliku nic nie daje, bo po zrestartowaniu systemd-resolved plik wraca do swojej domyślnej treści.
Ale znalazłem w sieci info, że to tak ma być: linux - Why does /etc/resolv.conf point at 127.0.0.53? - Unix & Linux Stack Exchange

‘resolvectl status’ wypluwa taki status:

Global
Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eno1)
    Current Scopes: DNS LLMNR/IPv4
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 208.67.220.222
       DNS Servers: 208.67.220.222 8.8.8.8 1.1.1.1

Link 3 (eno2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (hassio)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5...

Więc chyba tutaj wszystko jest ok

Tak wygląda moje.

Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 194.204.159.1
       DNS Servers: 194.204.159.1 194.204.152.34

Link 2 (enp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 194.204.152.34
       DNS Servers: 194.204.159.1 194.204.152.34

Link 7 (hassio)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported


Nowe spostrzeżenia: W serwerze są dwie karty sieciowe eno1 i eno2. Ręczne wpisanie IP w ustawieniach HA powoduje przypisanie tych ustawień do eno2

michal@szrank:~$ sudo ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: false
interfaces:
- connected: true
  enabled: true
  interface: eno2
  ipv4:
    address:
    - 192.168.0.200/24
    gateway: 192.168.0.1
    method: static
    nameservers:
    - 1.1.1.1
    ready: true
  ipv6:
    address:
    - fe80::4a74:110b:139a:b4a9/64
    gateway: null
    method: disabled
    nameservers: []
    ready: false
  mac: D4:AE:52:C4:EF:6F
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: true

I wtedy “internet dla HA” działa, aktualizacje przechodzą. Ale kabel sieciowy fizycznie jest wpięty do… eno1, co HA zdaje się w ogóle nie przeszkadzać :laughing:
W HA dostępna do zmiany ustawień jest jedna karta sieciowa z dwóch i to nie ta, która faktycznie działa. Ta która działa jest sterowana przez Open Media Vault (o którego istnieniu wcześniej nie wspomniałem, bo nie sądziłem, że może to być tu istotne - w końcu po to są kontenery). OMV nie dotyka karty eno2.

Dowiedziałem się z neta, że HA do zarządzania połączeniami sieciowymi używa pakietu network manager, a OMV netplan + systemd-networkd, więc te dwa softy będą sobie na wzajem robiły pod górkę.
Postanowiłem zabronić network managerowi mieszania w eno1, który zapewnia połączenie (i to z powodzeniem, bo wszystkie integracje chmurowe HA działają, apka w telefonie na sieci gsm też działa), ot tak na wszelki wypadek. To zrobiłem przez dodanie

;interface-name:eno1

w sekcji [keyfile] w pliku /etc/NetworkManager/NetworkManager.conf

[keyfile]
unmanaged-devices=type:bridge;type:tun;driver:veth;interface-name:eno1

I teraz planuję komendą
sudo nmcli connection up 061d3b6c-2e0c-4f3e-a166-50f200449fb1
uruchamiać połączenie przez Network Manager na karcie eno2.
Komenda ta powoduje zmianę w ustawieniach IPv4 w HA z wyłączone na takie jak przypisanie jak podczas tworzenia połączenia.
Niestety w tym momencie wystrzelałem się z aktualizacji home assistant i nie mam jak sprawdzić czy po restarcie serwera i ręcznym uruchomieniu połączenia wszystko będzie działać jak trzeba - jak coś się pojawi, to sprawdzę i podzielę się wnioskami :slight_smile:

Wątek poboczny:
061d3b6c-2e0c-4f3e-a166-50f200449fb1 to UUID połączenia utworzonego wcześniej ręcznie w ustawieniach HA. By zrobyć UUID trzeba użyć komendy nmcli connection
Umnie wygląda to tak:

michal@szrank:~$ nmcli connection
NAME             UUID                                  TYPE      DEVICE
Supervisor eno2  061d3b6c-2e0c-4f3e-a166-50f200449fb1  ethernet  eno2
lo               78c52f60-4a8b-42bf-bb52-b3503b4c6c23  loopback  lo
testtt           40a50f41-6296-4304-b8cc-f60f12b57a45  wifi      --