@zeropage für deinen Fall (zwei Desktop-VMs, die du einzeln am Notebook nutzt) ist SPICE genau richtig. Der ganze Terminalserver-Kram (Guacamole/KASM/ThinLinc) ist für zwei VMs völlig overkill, das hast du ja selbst schon gemerkt. virt-viewer ist...
@zeropage für deinen Fall (zwei Desktop-VMs, die du einzeln am Notebook nutzt) ist SPICE genau richtig. Der ganze Terminalserver-Kram (Guacamole/KASM/ThinLinc) ist für zwei VMs völlig overkill, das hast du ja selbst schon gemerkt. virt-viewer ist...
Ja, aber in einem Homelab oder einem „One-Man-Show“-Supportbetrieb braucht man keinen hochverfügbaren DNS-Forwarder. Und schon gar nicht braucht man irgendwelche Skripte, die wahrscheinlich eher die Ursache als die Lösung sind.
Ich habe meinen...
Inwieweit ich das Rad neu erfinden möchte, statt fette, komplexe Lösungen mittels kurzen Scripten auf Diät zu setzen, mag jeder für sich selbst entscheiden.
Z.B. hier: https://forum.proxmox.com/threads/benachrichtigung-bei-vm-ausfall.169572/...
Für Hochverfügbarkeit bei DNS wäre es doch naheliegender auf carp ( bei BSD als Basis etwa OPNsense) oder keepalived ( bei Linux ) zu setzen? Gescheites Monitoring braucht es dann aber trotzdem. Mir scheint terxleben erfindet gerne das Rad neu...
Ich in Form von managed und unmanaged Switches ohne Layer3. :D Das reicht mir nämlich hier in meinem Heim-Netzwerk. :)
Wenn es dann eher um ein größeres Netzwerk und nicht um "Spielerei" zu Hause gehen sollte, dann könnte man auch sagen/fragen...
Have you tried using fancontrol? Most servers have integration with lm-sensors so that the system can control the fans just by echoing in a file in /proc.
Es ist mal wieder Zeit ein Proxmox VE Homeserver vorzustellen.
Als Basis dient ein
* ATX Mainboard ASRock B550 PG Riptide
Highlight:
- NIC 2.5 Gbit/s,
- 6x SATA3,
- 1 PCIe 4.0 x16 Slot, 2 PCIe 3.0 x16 Slots, 1 PCIe 3.0 x1 Slot
- PCIe 4.0/3.0 x4...
Hi @kbhupendra
as you can see from the Security Advisories thread [1] and specifically this post [2] proxmox-kernel-6.8.12-24-pve or later include the fix related to CVE-2026-46333.
Yours sincerely
Jonas
[1]...
Für Hochverfügbarkeit bei DNS wäre es doch naheliegender auf carp ( bei BSD als Basis etwa OPNsense) oder keepalived ( bei Linux ) zu setzen? Gescheites Monitoring braucht es dann aber trotzdem. Mir scheint terxleben erfindet gerne das Rad neu...
Oder man löst vielleicht besser das eigentliche Problem? Ich nutze auch Pi-hole, und bei mir ist das noch nie "abgestürzt". Und falls es tatsächlich einmal hängen oder nicht mehr erreichbar sein sollte, merke ich das ja ohnehin recht schnell...
Sorry, ich versteh's halt immer noch nicht so ganz, aber auch egal.
Aber ja, wenn DNS aussteigt, geht nicht mehr viel, u. U. auch die Fernwartung nach Istanbul nicht mehr. Du teilst uns hier ausserdem mit, dass du offenbar Skripte nutzt, um DNS...
Not trying to be a dick, but I would never run software maintained by a single person with mental health issues.
But back to topic. Let us not put the cart before the horse. Why should I even want to manage PVE with an AI agent? Proxmox is...
You brought it up, not me.
Just a friendly advice, based on my personal experience. Nothing more, nothing less. Feel free to ignore it.
But back to topic. Let us not put the cart before the horse. Why should I even want to manage PVE with an AI...
@broadway:
Let’s take a step back from the technical scaffolding you are proposing.
Hash-chains, dry-runs, and scoped RBAC tokens are standard practices for traditional API automation. They do not, however, mitigate the core issue we are...
If the token only needs read-only privileges, the agent cannot actually do anything harmful, that is correct. On the other hand - it cannot do anything at all.
You brought it up, not me.
Just a friendly advice, based on my personal experience. Nothing more, nothing less. Feel free to ignore it.
But back to topic. Let us not put the cart before the horse. Why should I even want to manage PVE with an AI...
Ok I removed that line, ran update-grub, and rebooted. Here's the updated grub file and IOMMU group output:
cat /etc/default/grub
# If you change this file or any /etc/default/grub.d/*.cfg file,
# run 'update-grub' afterwards to update...