Update Check schlägt fehl

[chaosad]

Steh hier glaube ich auf der Leitung oder wieso schlägt hier der check genau fehl?
Proxmox ist hier als single node eingerichtet.

INFO: Checking if the local node's hostname 'srv' is resolvable..
INFO: Checking if resolved IP is configured on local node..
FAIL: Resolved node IP 'xx.xx.xx.xxx' not configured or active for 'srv'

In der /etc/hosts steht folgendes:

xx.xx.xx.xxx srv.xxx.de srv

Die IP ist hier identisch mit der Meldung aus dem pve5to6 check.

Der Hostname des Systems srv.xxx.de als auch srv lassen sich auf der Console via ping erreichen.
Für den Hostname liegen auch entsprechende DNS Einträge vor.
Der Knoten Name ist srv

 

[t.lamprecht]

Bitte mal beim "srv" Host mit folgendem Befehl nachschauen ob die IP eh auch am lokalen Node aktiv ist:

ip -c address

("-c" macht Farben an, machts einfacher zu lesen)

Den verwenden wir nämlich auch für den Check. Es könnte nämlich sein dass die auf einen anderen Host aktiv ist, und daher der ping Check durchläuft.

 

[chaosad]

Bitte mal beim "srv" Host mit folgendem Befehl nachschauen ob die IP eh auch am lokalen Node aktiv ist:

ip -c address

("-c" macht Farben an, machts einfacher zu lesen)

Den verwenden wir nämlich auch für den Check. Es könnte nämlich sein dass die auf einen anderen Host aktiv ist, und daher der ping Check durchläuft.

Das sieht wie folgt aus, also auftauchen tut sie hier unter vmbr0 auf jeden Fall, aber das sollte doch so in Ordnung sein oder nicht?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
link/ether 50:46:5d:9e:20:86 brd ff:ff:ff:ff:ff:ff
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 50:46:5d:9e:20:86 brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xxx peer xx.xx.xx.193/32 brd xx.xx.xx.xxx scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::5246:xxxx:xxxx:2086/64 scope link
valid_lft forever preferred_lft forever
5: veth100i0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether fe:cc:85:aa:xx:xx brd ff:ff:ff:ff:ff:ff link-netnsid 0
11: veth101i0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether fe:65:dc:fb:xx:xx brd ff:ff:ff:ff:ff:ff link-netnsid 1

 

[chaosad]

Es könnte nämlich sein dass die auf einen anderen Host aktiv ist, und daher der ping Check durchläuft.

Was genau meinst du eigentlich damit?
Die IP ist sonst nirgends aktiv und wird nur für den Host als vmbr0 verwendet.
Ansonsten läuft alles ja eigentlich wunderbar und ich habe keine Probleme, lediglich das Skript bemängelt hier das es srv nicht auflösen kann.

Trau mich jetzt natürlich auch nicht das Update trotz Fehlerhinweis einfach durchzuziehen ;-)

 

[t.lamprecht]

3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 50:46:5d:9e:20:86 brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xxx peer xx.xx.xx.193/32 brd xx.xx.xx.xxx scope global vmbr0

So, also eine peer to peer Verbindung (Hetzner?). Hab kurz vermutet das wir bei solchen setups was falsch erkennen, aber ich konnte es dann nicht nachstellen...

Also, dieser Test besteht grundsätzlich aus den folgenden zwei teilen:

getent hosts $(hostname)
# was oben als IP rauskommt unten bei "<IP>" setzen - wenn IPv6 dann /128 statt /32 verwenden
ip addr show to <IP>/32 up

Wenn da auf diesen host beim IP Befehl was korrektes und kein Fehler rauskommt bin ich selbst etwas verwundert.

Was genau meinst du eigentlich damit?
Die IP ist sonst nirgends aktiv und wird nur für den Host als vmbr0 verwendet.

Naja eben dass ein anderer Host im selben LAN diese IP hat und /etc/hosts bei "problematischen" hobel auf die falsche Adresse zeigt, daher ping wunderbar funktioniert (und auch kurze Latenz zeigt), war aber nur ein geratener Erklärungsversuch..

 

[chaosad]

Das klappt soweit ohne Probleme:

root@srv /etc/network # getent hosts
127.0.0.1 localhost.localdomain localhost
78.47.15.208 srv.xxx.de srv

root@srv /etc/network # ip addr show to xx.xx.xx.xxx/32
12: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet xx.xx.xx.xxx peer gw-ip/32 brd xx.xx.xx.xxx scope global vmbr0
valid_lft forever preferred_lft forever

xx.xx.xx.xxx = IP des Hosts
Ist halt wirklich komisch, da ich so mit dem Netz eigentlich keine Probleme hab.
Mit deiner Vermutung was Hetzner angeht, liegst du aber richtig.
Beim Hostsetups hab ich mich hier an der config für bridged vom wiki gehalten:
https://community.hetzner.com/tutor...xmox_ve/de?title=Proxmox_VE#Netzkonfiguration

 

[thomiczeck]

Hast du das Problem "gelöst" oder einfach nicht weiter beachtet?

 

[chaosad]

Aus zeitlichen Gründen, falls doch was schief gehen sollte hab ich das Update noch nicht durchgezogen.
Da aber scheinbar so auch nichts mehr weiter kommt, wird es wohl auf einen Versuch ankommen müssen :-(

 

[fabian]

ist in git schon gefixed, aber noch nicht in den paket repositories. sofern der hostname auf eine IP addresse resolved, die lokal konfiguriert ist ("ip -c a"), handelt es sich um einen fehler in der erkennung und dieses eine testergebnis kann ignoriert werden.