Edomi in Proxmox LXC container.

[saegefisch]

Hi Marcel, natürlich - in manchen IT-Dingen bin ich nicht immer so scharfkantig, wie ich gerne immer wäre... Daher kein Ping-Thema, sondern natürlich DNS, was ich auch meint, aber halt nicht schrieb... <schäm>.
In /etc/resolv.conf habe ich meine MikroTik stehen. Der hat als primären DNS mein PI-Hole, als sekundären Quad9. Auf dem Weg fragen auch alle anderen Geräte DNS bei mir an. Daher für mich auch so unerklärlich...

domain int
search int
nameserver 192.168.xx.1

Die beiden ersten Zeilen hat Proxmox selber eingetragen - derlei habe ich auf keinem meiner Server.

root@HAL-proxmox:~# [B]dig ftp.de.debian.org[/B]

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> ftp.de.debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.de.debian.org. IN A

;; ANSWER SECTION:
ftp.de.debian.org. 3441 IN A 141.76.2.4

;; Query time: 1 msec
;; SERVER: 192.168.xx.1#53(192.168.xx.1)
;; WHEN: Sat Mar 07 12:29:08 CET 2020
;; MSG SIZE rcvd: 51

root@HAL-proxmox:~#

und unmittelbar danach mal wieder Misserfolg und Erfolg nah beieinander...

root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
ping: ftp.de.debian.org: Temporary failure in name resolution
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
PING ftp.de.debian.org (141.76.2.4) 56(84) bytes of data.
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=1 ttl=50 time=24.5 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=2 ttl=50 time=23.9 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=3 ttl=50 time=24.1 ms
^C
--- ftp.de.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 23.919/24.191/24.512/0.275 ms
root@HAL-proxmox:~# ^C

NACHTRAG: Zwei SSH-Terminals nebeinander - 1x mein bestehender Server, 1x Proxmox. Während bei Proxmox es mal geht und meist lange dauert und dann ohne Ergebnis, kann ich im 1. Terminal parallel/gleichzeitig erfolgreich beliebig oft und 100% erfolgreich ausführen:

carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 847 bytes from 192.33.4.12#53(c.root-servers.net) in 7 ms
;; Received 362 bytes from 199.19.57.1#53(d0.org.afilias-nst.org) in 22 ms
;; Received 635 bytes from 194.58.198.32#53(nsp.dnsnode.net) in 24 ms
carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 819 bytes from 192.58.128.30#53(j.root-servers.net) in 20 ms
;; Received 362 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 6 ms
;; Received 296 bytes from 64.68.197.10#53(dns4.easydns.info) in 93 ms
carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 819 bytes from 199.7.83.42#53(l.root-servers.net) in 91 ms
;; Received 362 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 20 ms
;; Received 296 bytes from 192.174.68.100#53(sec1.rcode0.net) in 7 ms
carsten@HAL:~$

2. NACHTRAG: Ich ändere die DNS-Einstellungen des Proxmox-Knotens im Web-Frontend und sehe die Änderung danach prüfbar auch in /ect/resolv.conf. Sie wirken offenbar auch, wenn ich im SSH-Terminal ping/dig teste.

ABER: Nach ein paar Minuten ändert Proxmox meine DNS-Einstellung automatisch zurück auf den Stand vorher. Wirkt da irgend ein Selbstheilungs-Prozess in Proxmox und könnte das ein Indikator für das eigentliche Problem sein?

[Lonie]

Du hast kein Problem mit ICMP Ping sondern mit DNS welche Server hast du denn in /etc/resolv.conf eingetragen?

[saegefisch]

HI Yves,
ein wunderbarer Tipp, danke! Das sieht schon besser aus. Nun scheine ich aber ein Thema mit der DNS-Auflösung zu haben. Erstaunlicherweise funktioniert der ping vom ssh auf dem Proxmox auf die selbe Adresse völlig problemlos. In der Proxmox-Shell habe ich mal ein Problem beim ping, mal nicht, aber beim Ugrade schlägt es fehl. Vorhin aber nicht... ARGH! Ich hasse IT-Fehler die fuzzy sind...

root@HAL-proxmox:~# [B]apt-get update[/B]
Err:1 http://ftp.de.debian.org/debian buster InRelease
Temporary failure resolving 'ftp.de.debian.org'
Get:2 http://security-cdn.debian.org buster/updates InRelease [65.4 kB]
Hit:3 http://ftp.de.debian.org/debian buster-updates InRelease
Fetched 22.3 kB in 1min 20s (277 B/s)
Reading package lists... Done
W: Failed to fetch http://ftp.de.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'ftp.de.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
ping: ftp.de.debian.org: Temporary failure in name resolution
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
PING ftp.de.debian.org (141.76.2.4) 56(84) bytes of data.
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=1 ttl=52 time=25.2 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=2 ttl=52 time=22.6 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=3 ttl=52 time=22.2 ms
^C
--- ftp.de.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 22.239/23.372/25.242/1.337 ms
root@HAL-proxmox:~# [B]apt-get update[/B]
Err:1 http://ftp.de.debian.org/debian buster InRelease
Temporary failure resolving 'ftp.de.debian.org'
Hit:2 http://ftp.de.debian.org/debian buster-updates InRelease
Err:3 http://security.debian.org buster/updates InRelease
Temporary failure resolving 'prod.debian.map.fastly.net' Temporary failure resolving 'security.debian.org'
Reading package lists... Done
W: Failed to fetch http://ftp.de.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'ftp.de.debian.org'
W: Failed to fetch http://security.debian.org/dists/buster/updates/InRelease Temporary failure resolving 'prod.debian.map.fastly.net' Temporary failure resolving 'security.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@HAL-proxmox:~#

Nachtrag: Doch gleiches Verhalten per SSH (Alles andere wäre ja auch sehr erstaunlich): Mal geht der ping, mal nicht...

2. Nachtrag: beim 3 Versuch ging es nach Sekunden...

root@HAL-proxmox:~# apt-get update
Hit:1 http://ftp.de.debian.org/debian buster InRelease
Hit:2 http://ftp.de.debian.org/debian buster-updates InRelease
Hit:3 http://security.debian.org buster/updates InRelease
Reading package lists... Done
root@HAL-proxmox:~#

Fazit:

• Ich habe ein (sporadisches) PING-Problem vom Proxmox aus. Erstaunlicherweise von keinem anderen Server aus; von anderen funktioniert der selbe ping zum selben Server verlässlich. Da das der einzige getrunkete ist: Kann ping und trunk manchmal Probleme bereiten?
• Weiterhin scheint schon zeitlich keine Kausalität zwischen diesem Thema und dem eigentlichen Problem des Einfrierens zu geben

[starwarsfan]

Hi

Quelle enterprise schlägt erwartet fehl, da keine Subscription, sondern kostenlose Version, richtig?

Das bekommst Du aber einfach in Griff, indem Du /etc/apt/sources.list.d/pve-enterprise.list löschst oder woanders hin verschiebst. Dann gibts keine Update-Probleme mehr.

Ich sehe keinen Ansatzpunkt...bin ratlos...

Ich im Moment auch. Hm, weiter überlegen...

[saegefisch]

Produktiver Ausgangspunkt sind in relevanten VLAN einzelne dedizierte Ubuntu-Server mit Docker-Diensten und bisher keine eodmi-VM neben dem dedizierten edomi-1.64-Server

Ziel des Proxmox war ein neuer Server zu sein, der am Router trunked angebunden ist und damit in allen VLAN agieren kann. Ich fahre in dem 1 Knoten eine edomi-VM für PHP-Development und für meine edomi-2.xx-Projekt, in dem ich zur Ablösung meines produktiven 1.64 auf der grünen Wiese neu angefangen habe - es wächst und gedeiht prima - so ohne Altlasten und lesson-lerned von 4 Jahren... Das Projekt wird irgendwann in meinen dedizierten edomi-Server übertragen, wenn ich fertig bin.

Darüber hinaus die Docker-VM, die ich aber noch nicht umgezogen habe vom alten Server - daher dort aktuell nur watchtower und Portainer. Ziel sind 2-3 Docker-VM für die relevanten 2-3 VLAN in Proxmox. Dann kann ich die dedizierten ablösen/abschalten. Ziel: OWFS, NUT, Nextcloud, Webtrees, mehrere Dokuwiki, influxDB, grafana, Mosquitto, TVheadend, pi-hole,...

Fazit: 1x Docker mit watchtower+ Portainer...das hört sich nicht gefährlich an... Liegt hinter 2 FW im "inneren Zirkel", kein Zugang von außen (später per dediziertem RevProxy aus der DMZ wie die anderen Serverdienste auch)

Log ist bis zum Ausfall für meine Augen total unauffällig über Stunden (hat auch niemand drauf gearbeitet) bis 7:21 (rot markiert).

Auszug aus /var/log/syslog

[SIZE=10px]...
Mar 6 07:15:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:15:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:15:43 HAL-proxmox dhclient[648]: DHCPREQUEST for 192.168.xxx.yyy on vmbr0 to 192.168.xxx.1 port 67
Mar 6 07:15:43 HAL-proxmox dhclient[648]: DHCPACK of 192.168.xxx.yyy from 192.168.xxx.1
Mar 6 07:15:43 HAL-proxmox dhclient[648]: bound to 192.168.xxx.yyy -- renewal in 234 seconds.
Mar 6 07:16:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:16:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:16:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:17:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:17:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:17:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:17:01 HAL-proxmox CRON[28835]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 6 07:18:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:18:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:18:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:19:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:19:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:19:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:19:38 HAL-proxmox dhclient[648]: DHCPREQUEST for 192.168.xxx.yyy on vmbr0 to 192.168.xxx.1 port 67
Mar 6 07:19:38 HAL-proxmox dhclient[648]: DHCPACK of 192.168.xxx.yyy from 192.168.xxx.1
Mar 6 07:19:38 HAL-proxmox dhclient[648]: bound to 192.168.xxx.yyy -- renewal in 263 seconds.
Mar 6 07:20:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:20:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:20:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:21:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:21:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
[COLOR=#c0392b][B]Mar 6 07:21:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.[/B][/COLOR]
Mar 6 10:19:58 HAL-proxmox systemd-modules-load[415]: Inserted module 'iscsi_tcp'
Mar 6 10:19:58 HAL-proxmox iscsid: iSCSI logger with pid=428 started![/SIZE]
...

Zum apt-get upgrade: Der ist auch in der kostenlosen Version enthalten oder. Wenn ich den manuell anstoße, kommt meist unauffällig

Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Your System is up-to-date

starting shell
root@HAL-proxmox:/#

In den Wochen hatte ich aber auch schon Pakete zum aktualisieren. Allerdings ist das "nur" das dist-upgrade, nicht das update... In der Shell manuell funktioniert das aber auch unauffällig (Quelle enterprise schlägt erwartet fehl, da keine Subscription, sondern kostenlose Version, richtig?).

root@HAL-proxmox:~# apt-get update
Err:1 https://enterprise.proxmox.com/debian/pve buster InRelease
401 Unauthorized [IP: 212.224.123.70 443]
Hit:2 http://ftp.de.debian.org/debian buster InRelease
Get:3 http://ftp.de.debian.org/debian buster-updates InRelease [49.3 kB]
Get:4 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:4 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:4 http://security-cdn.debian.org buster/updates InRelease [65.4 kB]
Err:4 http://security-cdn.debian.org buster/updates InRelease
Connection failed [IP: 151.101.112.204 80]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/buster/InRelease 401 Unauthorized [IP: 212.224.123.70 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@HAL-proxmox:~#

Es dauert allerdings erstaunlich lange im Vergleich zu meinen Ubuntu-Maschinen. In den Tasks sieht man, dass das tägliche upgrade oft funktioniert ("OK" ~ 50% der Versuche), aber auch regelmäßig (die anderen ~50%) den oben genannten Fehler ("TASK ERROR: command 'apt-get update' failed: exit code 100") wirft. Könnte das ein Indikator für etwas sein? Allerdings liegt der letzte upgrade-Fehler in den Tasks ~4h vor dem "Einfrieren" um 7:21. Das sieht nicht nach direkter Kausalität aus.

Ich sehe keinen Ansatzpunkt für die Analyse dieses sporadischen Verhaltens...bin ratlos...

[Lonie]

apt-get return code 100 heißt es gab einen Fehler. Leider wird hier nicht genauer unterschieden.

Du könntest in der Konsole auf dem Hosts mal nachsehen was in den apt-logs steht, zu finden unter /var/log/apt/history*
Syslog solltest du über die Shell ebenso unter /var/log/syslog* finden.

[starwarsfan]

Hi,

was macht denn Docker auf der Maschine? Wäre jetzt so aus dem Stehgreif das Einzige, was dort irgendwie nicht so recht dazu passt. "Sicher" ist die Kiste auch nehme ich an? Also so in Richtung Erreichbarkeit, Zugangsdaten etc.?

Mein Cluster läuft seit Monaten resp. seit dem Setup ohne jegliche Probleme 24/7 und auch Work sind mir keine derartigen Probleme bekannt.

[saegefisch]

Ein sporadisches Problem mir Proxmox...

• Proxmox läuft auf dedizierter HW (NUC8i3BEK2, 32GB RAM, 500GB NVMe) seit ein paar Wochen, aufgebaut mit der ISO von Proxmox (6.1-3), also keine Spielereien, keine Experimente. Update-Funktion von Proxmox regelmäßig.
• Derzeit 4 Container (2x edomi, 2x Ubuntu + Docker) auf 1 Knoten
• Auslastung: CPU ~2%, RAM ~ 5%, SSD ~3% | Jeder Container für sich auch problemlos in den definierten Ressourcen, z.B. edomi CPU ~3%, RAM ~12%, SSD~12%

Heute Nacht nun das 3x in diesen Betriebswochen: Proxmox ist nicht mehr sauber erreichbar - ohne einen ersichtliches Ereignis oder Last, weil in den frühen Morgenstunden):

• Web-Oberfläche nicht mehr erreichbar
• Ping geht
• DHCP-Server sagt "declined"
• SSH geht technisch, aber in der Shell geht das meiste nicht: reboot, halt, df, top,...
• Laufwerks-LED zeigt keinerlei Aktivitäten
• Soft-reboot (Power-taste kurz) geht nicht

Nach hartem Reboot (Power-Taste 4s) fährt Proxmox sauber wieder hoch, alles geht wieder.

• Tasks: Das letzte vor dem Reboot ist "Paket-Datenbank aktualisieren: TASK ERROR: command 'apt-get update' failed: exit code 100" - muss aber ~3h vor dem "Problem" gewesen sein, weil ich so lange noch Lebenszeichen von der edomi-VM hatte
• Das Syslog des Knotens beginnt offenbar erst mit dem Reboot - zumindest finde ich keine älteren in der Weboberfläche.

Wenn es läuft, läuft Proxmox wirklich sehr geschmeidig; Einrichtung und Betrieb sind wirklich einfach und angenehm und damit sehr empfehlenswert, Aber eine IT, die sporadisch nicht verlässlich ist, ist... doof...

Hat jemand eine Idee, was die Ursache dieser sporadischen, vermeintlich anlass-losen "Probleme" sein könnte oder hat diese selber schon erlebt?
Wie kann man der Ursache (mit Bordmitteln?) auf den Grund gehen?

[saegefisch]

Und für alle, die es dennoch auch mal selber installieren wollen...

Bugfix/Update in der Anleitung, weil mir heute bei Diagrammen auffiel, dass sie in der VM alle 1h Zeitverschiebung hatten. Ursache war, dass edomi zwar in der richtigen Zeitzone CET lief, aber CentOS darunter in UTC. Daher ergänzt: timedatectl set-timezone Europe/Berlin

Achtung: Kein Update im laufenden Betrieb! Wenn man es wie ich nachträglich machen muss: Edomi anhalten, Kommando ausführen per ssh und edomi wieder starten. Danach ist die Zeitverschiebung weg.

[starwarsfan]

Hallo miteinander,

es ist soweit, das ProxMox-Template ist fertig. Siehe hier!

Happy testing.

[saegefisch]

entweder ich habe das Problem mit systemd mangels tiferem Wissen und Erfahrung nicht verstanden oder ich habe es nicht: Ich habe bisher ausschließlich unprivilegierte Container erstellt und die starten ganz wunderbar mit Proxmox (6.1-3). Mehrere Ubuntu (18.04 LTS) und mehrere CentOS7 für edomi. Das tty-force habe ich ebenfalls nicht aus dem ersten Post übernommen, bei edomi lediglich auf console umgestellt.

[malokas]

Wenn du einen priveligierten Container erstellst reicht es sogar vollkommen aus file aufzunehmen. Bei unpriveligierten habe ich aktuell das Problem dass sie sich nicht über systemd starten lassen. Fehlermeldung "Failed at step STDIN spawning /bin/sh: Operation not permitted". Jetzt werd ich aber erstmal ins Wochenende gehen. Prinzipiell ist der Grund ja gefunden und die meisten sind happy

Ich hatte genau den gleichen Fehler und habe es mit einem priviliegerten Container probiert, damit ging es dann. Ich habe den Tipp mit tty-force nicht ausprobiert, ggf. ein ander mal.

[Marha]

Ja, war OT. Danke Dir für die Anleitung. Damit soll’s das nun gewesen sein.

[saegefisch]

gerne (auch wenn's natürlich OT ist)...setze tatsächlich gerade die Avahi-VM auf. Die Geräte können sich schon sehen, trotz unterschiedlicher VLAN (TV in IOT, iphone in INT) komme ich schon bis zur Eingabe des Airplay2-Validierungs-Keys. Damit hat meines Erachtens AVAHI/Bonjour seine Arbeit bereits erledigt. Alles weitere ist vermutlich ein Firewall-Thema im Router, an dem ich heute noch knobeln muss (IOT-Whitlist-Regelsatz).

Anleitung für AVAHI-VM in Proxmox anbei. Die manuell gesetzten MAC-Adressen sind optional, kann man machen, muss man nicht. Für VM find' ich's bei DHCP recht hilfreich.

lxc-container_avahi.pdf

[Marha]

AVAHI:.... der ja genau diese Grenzen für Airplay überwinden soll...

Habe mich daran unter CentOs 6.5 (nicht als VM) aus denselben Gründen versucht. Hab’s nicht zum Laufen bekommen. Kannst Du vielleicht eine „Anleitung“ oder Link nennen?