3 Punkte von GN⁺ 2024-11-14 | 1 Kommentare | Auf WhatsApp teilen
  • Proxmox-VE-Betreiber erledigen die Bereitstellung und Verwaltung von Containern und VMs oft als wiederkehrende Aufgaben; ein Community-Script-Hub mit Ein-Befehl-Ansatz reduziert den Aufwand für Homelab- und Virtualisierungsbetrieb
  • Die Website wirbt mit 604 Scripts, 4.497.254 Installationen und 26 Kategorien und macht Automatisierungs-Scripts für Proxmox-Umgebungen an einem Ort durchsuchbar
  • Die Liste der meistinstallierten Scripts der letzten 30 Tage umfasst im Homelab häufig genutzte Dienste wie Docker, Debian, Immich, Nginx Proxy Manager und Jellyfin Media Server
  • Neu hinzugefügte Scripts sind in die Typen LXC, ARM LXC und PVE unterteilt; zu sehen sind unter anderem Koffan, Etherpad, Flame, PVE Disk Health Tool, Pinchflat und SnapOtter
  • Da es sich um Scripts handelt, die direkt auf dem System ausgeführt werden, sind die Prüfung der offiziellen Website und die Durchsicht des Script-Quellcodes vor der Installation unerlässlich

Community-Script-Hub für Proxmox VE

  • Proxmox VE Helper-Scripts bündelt und stellt communitybasierte Automatisierungs-Scripts für Proxmox VE bereit
  • Nutzer können in Proxmox-Umgebungen Container und VMs per Einzeiler durchsuchen, installieren und verwalten
  • Die Plattform dient als zentraler Hub zur Vereinfachung von Homelab- und Virtualisierungs-Workflows
  • Der Umfang der Website sieht wie folgt aus
    • 604 Scripts

    • 4.497.254 Installationen

      • 26 Kategorien

Neue Homepage und Navigationsfluss

  • Mit dem Update vom 6. März 2026 wurde die neue Homepage des Projekts Proxmox VE Community Scripts veröffentlicht
  • Die neue Website ist darauf ausgelegt, Hunderte von Automatisierungs-Scripts für Proxmox-Umgebungen leichter entdecken, durchsuchen und bereitstellen zu können
  • Sie ist eine von der Community erstellte Plattform und wird als Hub zur Vereinfachung von Homelab- und Virtualisierungs-Workflows angeboten

Meistinstallierte Scripts der letzten 30 Tage

  • Die Beliebtheitsliste ist nach der Zahl der Installationen in den letzten 30 Tagen sortiert
  • Die Top-Einträge sind:
    • Docker: Open-Source-Projekt zur Automatisierung der Anwendungsbereitstellung, 30.594 Installationen
    • Debian: freies Betriebssystem mit mehr als 59.000 Paketen, 22.397 Installationen
    • Immich: selbstgehostete Lösung zur Verwaltung von Fotos und Videos, 18.234 Installationen
    • Nginx Proxy Manager: webbasierte Oberfläche zur Verwaltung von Nginx-Reverse-Proxys, 14.049 Installationen
    • Jellyfin Media Server: kostenloser Open-Source-Medienserver zum Organisieren, Verwalten und Teilen digitaler Mediendateien, 13.707 Installationen
    • Hermes Agent: selbstverbessernder KI-Agent von Nous Research, 13.233 Installationen
    • Frigate: Open-Source-NVR mit Echtzeit-KI-Objekterkennung für IP-Kameras, 12.663 Installationen
    • AdGuard Home: selbstgehosteter Werbeblocker für das gesamte Netzwerk, 12.532 Installationen
    • Ollama: Tool zum Ausführen großer Sprachmodelle auf dem lokalen Computer, 11.923 Installationen
    • Ubuntu: Debian-basierte Distribution, 10.689 Installationen

Neu hinzugefügte Scripts

  • Die Liste der zuletzt hinzugefügten Scripts zeigt Script-Name, Typ und Zeitpunkt der Aufnahme
  • Wichtige Einträge sind:
    • iVentoy: PXE-Server, der das Booten und Installieren von Betriebssystemen über das Netzwerk auf mehreren Maschinen gleichzeitig unterstützt, heute hinzugefügt
    • FMD-Server: dezentrales Tool zur Ortung und Fernsteuerung von Android-Geräten, vor 1 Tag hinzugefügt
    • Koffan: Web-App für Einkaufslisten mit Echtzeitsynchronisierung für Paare und Familien, vor 1 Tag hinzugefügt
    • Etherpad: kollaborativer Echtzeit-Dokumenteditor, in dem mehrere Personen gleichzeitig im Browser bearbeiten, vor 1 Tag hinzugefügt
    • Flame: selbstgehostete Startseite für Server, vor 1 Tag hinzugefügt
    • PVE Disk Health Tool: Tool zur Meldung des Zustands physischer Laufwerke auf Proxmox-VE-Hosts, vor 2 Tagen hinzugefügt
    • Pinchflat: selbstgehosteter YouTube-Medienmanager auf Basis von yt-dlp, vor 4 Tagen hinzugefügt
    • SnapOtter: Sammlung lokal ausgeführter Tools zur Bildverarbeitung, vor 6 Tagen hinzugefügt
    • Postiz: KI-gestütztes Tool zum Planen und Verwalten von Beiträgen auf mehreren Social-Plattformen, vor 9 Tagen hinzugefügt
    • Plane: Open-Source-Tool zum Planen und Nachverfolgen von Softwareprojekten mit Issues, Zyklen und Modulen, vor 11 Tagen hinzugefügt

Scripts in Entwicklung

  • Die Scripts im Entwicklungsbereich sind noch nicht offiziell veröffentlicht und befinden sich in aktiver Entwicklung
  • Angezeigte Einträge in Entwicklung sind:
    • Rackula: Drag-and-drop-Rack-Layout-Designer für Homelab-Nutzer
    • Umbraco CMS: Script zur automatischen Einrichtung eines Open-Source-.NET-CMS und FTP-Servers
    • Nexterm: Open-Source-Serververwaltungssoftware für SSH, VNC und RDP
    • Colanode: local-first Kollaborations-Workspace als selbstgehostete Alternative zu Slack und Notion
    • ExcaliDash: selbstgehostetes Dashboard und Organisationstool für Excalidraw

Kategorien

  • Die Scripts sind in mehrere Bereiche gegliedert, darunter Proxmox und Betriebssysteme, Netzwerk, Sicherheit, Backup, Datenbanken, Monitoring, Medien und IoT
  • Die wichtigsten Kategorien und Gesamtzahlen sind:
    • Proxmox & Virtualization: 40
    • Operating Systems: 27
    • Containers & Docker: 10
    • Network & Firewall: 40
    • Adblock & DNS: 8
    • Authentication & Security: 21
    • Backup & Recovery: 11
    • Databases: 24
    • Monitoring & Analytics: 50
    • Dashboards & Frontends: 17
    • Files & Downloads: 35
    • Documents & Notes: 59
    • Media & Streaming: 58
    • AI / Coding & Dev-Tools: 35

Script-Typen und Beispiele

  • Jedes Script wird mit Typ-Labels wie LXC, ARM LXC, PVE, Addon, VM, DEV, Privileged ausgeliefert
  • Beispiele aus der Kategorie Proxmox & Virtualization sind:
    • PVE Disk Health Tool: meldet den Zustand physischer Laufwerke und installiert bei Bedarf smartmontools und nvme-cli
    • PVE LXC Execute: führt benutzerdefinierte Befehle in einem oder mehreren LXC-Containern eines Proxmox-VE-Nodes aus
    • PVE Startup Dependency Check: prüft vor dem Start einer VM oder eines LXC erforderliche Abhängigkeiten und die Verfügbarkeit referenzierter Storage-Ressourcen
    • CronMaster: selbstgehosteter Scheduler für Cron-Jobs mit Web-UI, Echtzeit-Logs und Authentifizierung
    • All Templates: Script zum Erstellen einer von mehreren kostenlosen LXC-Vorlagen

Projekt und Sicherheitshinweise

  • Das Projekt ist über GitHub und Discord angebunden
  • Am Seitenende wird angegeben, dass das Projekt von der Community erstellt wurde und Open Source unter der MIT-Lizenz ist
  • Da es Klone oder ähnliche Websites geben kann, sollte immer geprüft werden, ob es sich um die offizielle Website handelt
  • Vor der Ausführung auf einem System sollte jeder Script-Quellcode gründlich geprüft werden

1 Kommentare

 
GN⁺ 2024-11-14
Meinungen auf Hacker News
  • Ich gehöre zusammen mit dem Einreicher zu dem Maintainer-Team, das sich freiwillig gemeldet hat, um die Pflege dieses Projekts zu unterstützen, nachdem tteck die traurige Nachricht bekannt gegeben hat, dass er in ein Hospiz kommt.
    Alle Teammitglieder sind fest entschlossen und motiviert, ttecks Vermächtnis fortzuführen.
    Wir arbeiten transparent und beantworten Fragen gern.
    (1) https://news.ycombinator.com/item?id=42016605

    • Das ist wirklich traurige Nachricht.
      Ich habe erst vor Kurzem mit Homelab/Self-Hosting angefangen und die meisten meiner Container mit den tteck-Skripten eingerichtet.
  • Ich nutze Proxmox VE seit einigen Jahren und habe die meisten Dienste als Docker-Container in einer einzigen VM laufen lassen.
    Ich fand es immer schade, dass ich einzelne Dienste und Backup-Jobs nicht über die Proxmox-Oberfläche steuern konnte. Als ich diese Skripte gesehen habe, habe ich Caddy und ein paar WireGuard-Instanzen in LXC-Container verschoben; das ging sehr einfach und hat mich beeindruckt.
    Dank all der Leute, die diese Skripte erstellt haben, war mein erster Eindruck sehr gut.

    • Vorsicht. Ich hatte denselben Gedanken, aber Docker-Container haben gegenüber LXC-Skripten Vorteile bei Updates zwischen Hauptversionen und automatischen Upgrades.
      Meist erstellt der Entwickler der Software auch den Container, sodass es eine unterstützte Umgebung ist; weil er die Anwendung und künftige Upgrades gut kennt, ist die Umgebung für jede Version korrekt konfiguriert.
      Um dein Ziel zu erreichen, würde ich pro App eine Kombination aus LXC mit deiner bevorzugten Linux-Distribution + Docker + App-Container empfehlen. So erzielst du denselben Effekt und behältst zugleich die genannten Vorteile.
  • Etwas am Rande: Ich habe versucht, libvirt und Unraid mit Terraform zu verwalten, bin aber ständig auf Probleme gestoßen und bin kurz davor aufzugeben und VMs manuell zu verwalten.
    Mich würde interessieren, welche Virtualisierungstechnologie Proxmox verwendet.
    Außerdem interessiert mich, welche Vorteile es hat, solche Tools statt Terraform, SaltStack oder Ansible zu verwenden.

    • Erwähnenswert ist auch, dass Proxmox ZFS nutzt, wodurch Snapshots schnell sind, und dass das Backup-System sehr gut ist.
      Wenn du Self-Hosting-Anwendungen wie eine „Herde“ behandeln willst, sind Terraform, Kubernetes usw. die bessere Wahl.
      Wenn es für dich aber in Ordnung ist, bei Problemen manuell aus Backups oder Snapshots wiederherzustellen, oder wenn du bei einem Cluster möchtest, dass LXC-Container automatisch auf andere Hardware verschoben werden, dann passt Proxmox. In einer realen Heimumgebung kostet es ungefähr genauso viel oder sogar weniger Zeit, „Haustiere“ zu pflegen, als eine „Farm“ zu betreiben.
      (1) Ein Wortspiel, wie man es in Neuseeland verwendet.
    • Proxmox legt den Schwerpunkt stärker auf die Verwaltung des Hosts und der Ressourcen darauf. Dazu gehören Live-Migration von VMs zwischen Hosts, etwas Hochverfügbarkeit und Failover-Unterstützung.
      Wenn du möchtest, kannst du zusammen mit Proxmox auch Tools wie Terraform verwenden, um die Konfiguration innerhalb der VMs zu verwalten.
    • Proxmox verwendet KVM für Virtualisierung und Linux Containers (LXC) für Container.
      Ich stimme zu, dass für Infrastructure-as-Code-Deployments Dinge wie Terraform oder Ansible mehr Sinn ergeben. Leute, die Proxmox im Homelab einsetzen, bevorzugen meist manuelle Verwaltung und kümmern sich eher nicht um eine Infrastructure-as-Code-Umsetzung.
      Beruflich glaube ich fest an reproduzierbare Umgebungen und Infrastructure as Code. Tatsächlich nutze ich Vagrant, libvirt und KVM, um lokale Cluster schnell für Tests und Entwicklung hochzufahren, und das funktioniert ziemlich gut. Mein Homelab ist allerdings nicht komplex genug, um Terraform/Ansible einzurichten. Wenn der Server kaputtgeht, denke ich vielleicht anders darüber.
    • Mit einem Proxmox-Provider für Terraform kann man einen Kompromiss finden[1].
      Der Ablauf wäre: VMs mit Terraform provisionieren und sie dann mit etwas wie Ansible konfigurieren und warten.
      Wenn du LXC als Ziel verwenden möchtest, kannst du mit diesem Provider auch LXC reservieren.
      [1]: https://github.com/Telmate/terraform-provider-proxmox
  • Aus der Perspektive von jemandem, der sich gerade informiert, um seinen ersten Proxmox-Rechner einzurichten, wollte ich eigentlich eine sehr grundlegende und übliche Konfiguration haben.
    Modem > Proxmox-Rechner > OPNsense-VM > physischer WLAN-Router über die onboard 10Gb-NIC + interne Netzwerk-VMs wie OMV. Ziel ist es, mit OPNsense einen Filter für das gesamte Netzwerk hinzuzufügen und im internen Netzwerk Zugriff auf Medienserver, Backups usw. zu haben.
    Allerdings sehe ich kein OPNsense-Skript, und das OMV-Skript müsste eine VM statt eines LXC-Containers sein, was praktisch nicht der empfohlenen Form entspricht. Auch ein Glue-Skript, das VMs miteinander kommunizieren lässt, sehe ich nicht. Da dieser Teil bei der Proxmox-Konfiguration wichtig ist, scheint es Raum zu geben, einfache Skripte für grundlegende Homeserver-Setups zu verbessern oder zu ergänzen.

    • Das ist keine grundlegende und übliche Konfiguration. Für mich schon, aber vermutlich nicht für dich, und für die meisten ganz sicher nicht.
      Einen Router und eine Firewall zu virtualisieren ist völlig okay. Ich habe etwa 200 pfSense-Firewalls/-Router als VMs und auf physischer Hardware ausgerollt, und OPNSense ist ähnlich, also kann ich vermutlich helfen.
      Du brauchst mindestens zwei physische Interfaces. Mit einem geht es zwar auch, aber dann musst du genau wissen, was du tust. Du brauchst „WAN“ und „LAN“. OPNSense basiert vermutlich immer noch auf FreeBSD, läuft also natürlich nicht in einem Linux-LXC-Container.
      Der letzte Absatz ist etwas verwirrend. Ich weiß nicht, was mit „Glue-Skript“ gemeint ist. VMs kommunizieren über das Netzwerk.
      Um Virtualisierung richtig zu verstehen, würde ich empfehlen, erst ein paar Experimente zu machen und dann weiterzugehen. Wenn du ein konkretes Problem hast, komm ins Proxmox-Forum, dort helfen wir dir, aber am Ende gilt: Entweder du springst richtig rein oder eben nicht.
    • Ich nutze Proxmox und habe auch VLAN eingerichtet.
      Der Port vom Router zum Proxmox-Rechner ist für getaggte Pakete konfiguriert, um ein- und ausgehenden Traffic zu trennen.
      Danach lassen sich VMs und Container einfach so konfigurieren, dass sie in einem oder mehreren Netzwerken „leben“.
      In meinem Fall bestimmen die Firewall-Regeln des Routers, welcher Traffic zwischen den VLANs weitergeleitet wird.
      Ich denke, wenn man OPNSense als Container oder VM startet, könnte man es genauso konfigurieren, dass es Traffic zwischen VLANs selektiv weiterleitet.
    • Dass es kein OPNSense-Skript gab, lag vermutlich daran, dass ein einziger Konfigurationsfehler dazu führen kann, dass die Proxmox-Instanz im Internet exponiert ist.
      Für fortgeschrittene Nutzer ist es einfach genug, per ISO eine VM zu starten. Kürzlich gab es auch eine Anfrage für ein OPNSense-Skript.
      Bei OMV stimme ich zu. Man kann es so verwenden, aber es ist nicht die Nutzungsweise, die normale Leute üblicherweise wollen. Vor ein paar Tagen wurde dem Skript ein Kommentar hinzugefügt.
      Du sagtest, es gebe kein Glue-Skript, um VMs miteinander kommunizieren zu lassen; technisch gesehen gibt es ein Tailscale-Skript, das ihnen hilft, über Tailscale miteinander zu kommunizieren :)
      Diese Skripte sind dafür gedacht, in sich geschlossene LXC-Container einzurichten. Wir versuchen zu vermeiden, unser eigenes Kubernetes zu bauen.
    • Ich nutze in Proxmox eine OPNSense-VM und habe auch mehrere NICs. Eine davon ist exklusiv für das Glasfaser-ONT.
      Außerdem nutze ich ein externes WLAN-Mesh.
      Es gibt auch ein paar andere VMs. Wegen Abwärtskompatibilität eine unRaid-VM, die per SATA-Karten-Passthrough Docker hostet, eine VM für Home Assistant OS und viele LXCs. Das funktioniert hervorragend.
    • Ich weiß nicht, was mit „Glue-Skript, das VMs miteinander kommunizieren lässt“ gemeint ist.
      Nutzt man nicht einfach das Netzwerk wie bei anderen Computern auch?
      Ich habe nie eine besondere Konfiguration vorgenommen, damit VMs miteinander kommunizieren können.
  • Docker-LXC und die Home-Assistant-VM werde ich mir auf jeden Fall ansehen.
    Bisher habe ich Docker erfolgreich in einer VM unter Proxmox genutzt, aber vielleicht lässt sich da noch mehr Effizienz herausholen.

    • HAOS als VM unter Proxmox läuft gut.
      Ich habe mit ein paar Helper-Skripten von tteck MQTT- und zigbee2mqtt-LXC-Container eingerichtet und ein USB-Zigbee-Gerät per Passthrough verwendet.
    • Die Skripte für diese beiden Projekte funktionieren sehr gut.
      Für Home Assistant wird eher eine HAOS-VM empfohlen als LXC oder Docker.
  • Ich habe mich entschieden, in meinem Homelab statt Kubernetes Proxmox zu betreiben, und bereue es inzwischen ein Stück weit
    LXC ist großartig, aber darauf beschränkt zu sein, nur LXC oder QEMU-VMs zu nutzen, passt nicht zu all meinen Anforderungen. Mit Kubernetes hätte ich über Projekte wie Kata Unterstützung für leichtgewichtige VMs wie den Firecracker-Hypervisor oder Unikernel hinzufügen können; Proxmox fehlt es hier an Erweiterbarkeit
    Außerdem eignet es sich nicht so gut für Automatisierung oder reproduzierbare Builds wie ein bewährter Pod-Manager à la Kubernetes. Soweit ich herausgefunden habe, gibt es auch keine Terraform-Unterstützung, sodass man sich auf vollständige Festplatten-Backups und Tools wie Chef/Ansible/Puppet verlassen muss – und ich möchte nicht erneut Zeit investieren, um das zu lernen
    Trotzdem sind Ressourcenverwaltung und Passthrough-Modell sehr gut, die Einrichtung und Wartung sind einfach, und das Control Panel ist auch ordentlich

    • Das Deployment-Modell ist definitiv anders. Es hat Nachteile, aber ich mag es
      Allerdings gibt es ein Community-Terraform-Modul: https://registry.terraform.io/providers/Telmate/proxmox/late...
      Ich habe es selbst nie benutzt und greife normalerweise zu Ansible
      Wegen des einfach installierbaren ZFS ist es außerdem schwer, mich dazu zu überreden, etwas anderes auszuprobieren. Wenn man mit Kubernetes herumspielen will, startet man einfach eine oder mehrere VMs
    • Ich bin ziemlich gründlich in NixOS versunken
      Eine Zeit lang habe ich Docker Swarm auf mehreren Single-Board-Computern betrieben, danach Kubernetes, einen großen Server mit Ubuntu + Cockpit, dann Proxmox, und schließlich bin ich bei NixOS gelandet
      NixOS hat bei Bedarf auch ordentliche Container-Unterstützung, aber durch seinen deklarativen Charakter nutze ich Container kaum noch. Etwas zu „entfernen“ heißt meist nur, es aus der Konfigurationsdatei zu nehmen und neu zu bauen. Auch cgroup-artige Dinge etwa für Speicherverwaltung sind nicht schwierig
      Die nginx-DSL von NixOS finde ich ebenfalls großartig. Statt eigene Skripte zu schreiben, ist es wirklich schön, dass die Konfigurationsumgebung Proxy-Setup und Let’s Encrypt direkt und korrekt verwaltet
      Ich weiß nicht, ob es Tools für verteiltes NixOS gibt, aber ich könnte mir vorstellen, dass auf Basis von Flakes etwas Schickes entstehen kann
      Mein Homelab ist aktuell so einfach und zufriedenstellend wie noch nie
    • Ich habe diesen Terraform-Provider[1] zusammen mit der Talos[2]-Distribution genutzt, um einen Kubernetes-Cluster bereitzustellen
      Ich stimme zu, dass die von Proxmox bereitgestellte API nicht vollständig ist, aber für meine Zwecke reicht sie aus
      Ich betreibe den Cluster auf vier SFF-Geräten kurz vor der Ausmusterung und sichere LVM-Snapshots auf einem selbst gebauten TrueNAS-Speicher; diese ganze Konfiguration gefällt mir
      [1] https://github.com/Telmate/terraform-provider-proxmox
      [2] https://factory.talos.dev/
    • Nur weil man Proxmox verwendet, heißt das nicht, dass man Kubernetes nicht nutzen kann
      Man erstellt in Proxmox VMs, installiert darauf Kubernetes und lässt die Anwendungs-Workloads in Kubernetes laufen
      Proxmox-VMs sind schwieriger zu automatisieren und sollten daher eher wie „Pets statt Cattle“ behandelt werden; dasselbe gilt aber auch für die Verwaltung von Kubernetes-Hosts auf Bare Metal. VMs auf Proxmox haben jedoch den Vorteil, dass vollständige VM-Backups und Migrationen über Proxmox möglich sind – so bekommt man die Vorteile von Proxmox und Kubernetes zugleich
    • Jede Technik hat den passenden Ansatz und Einsatzzweck
      In Proxmox ist es relativ einfach, mit dem Kommandozeilen-Utility pve VMs zu erstellen oder zu ändern
      Der Ausgangspunkt dieses Beitrags ist dennoch, dass es viele nützliche Skripte gibt, die Verwaltung einfacher und wartbarer machen, und dass man für diese Hilfe dankbar ist, während der Gründer sich zurückziehen muss
  • Welche Funktionen hat Proxmox, die einfaches KVM nicht hat? Nur ein Web-Interface?

    • Spontan fallen mir Clustering, Migration, Hochverfügbarkeit, Backups, Ceph-Integration, das neuere virtuelle Netzwerk sowie Unterstützung nicht nur für VMs, sondern auch für Container ein
      Das Web-Interface ist ebenfalls optional. Für mehr Details sollte man sich am besten die Proxmox-Webseite ansehen
    • KVM ist nur die Kernel-seitige Komponente und für sich genommen kein vollständiger Virtual-Machine-Manager. Man braucht immer eine User-Space-Anwendung
      Firecracker, QEMU und Cloud-Hypervisor sind Virtual-Machine-Manager, die auf KVM aufbauen
      QEMU ist die übliche Art, KVM zu verwenden, aber QEMU direkt auszuführen ist ziemlich umständlich. Deshalb nutzt man Werkzeuge wie libvirt oder Proxmox, die QEMU kapseln
  • Eine großartige Community. Ich habe schon ein paar Skripte ausprobiert und betreibe Pi-hole- und Paperless-LXC-Container
    Auf Appflowy freue ich mich auch

  • Leider verwendet Proxmox im ersten Absatz seiner Website das Wort „Enterprise“, unterstützt aber bis heute Full-Disk Encryption nicht von Haus aus
    Natürlich kann man es auf einem selbst verschlüsselten Debian installieren, aber dabei verpasst man wichtige Funktionen und muss sich selbst darum kümmern. Letztlich liegt das daran, dass ZFS Full-Disk Encryption nicht als First-Class-Funktion behandelt
    Eine sehr bedauerliche Situation