community.general: Die Sammel-Collection ohne Windows-Ziele und mit zwei Wartungslinien
ansible-collections/community.general bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Die Ansible-Collection community.general bündelt Module und Plugins der Gemeinschaft, die in keine spezialisiertere Sammlung passen, und wird mit dem Ansible-Paket ausgeliefert. Das README zieht zwei harte Grenzen: keine Windows-Ziele und kein Support für ansible-core vor 2.18.0.
- Für wen ist es gedacht?
- Geeignet ist community.general für Automatisierung auf Linux- und Unix-artigen Zielen, die Module und Plugins jenseits der spezialisierten Sammlungen braucht und mit einer der getesteten ansible-core-Linien 2.18 bis 2.21 arbeitet. Weniger geeignet ist sie für Windows-Ziele, weil das README diese ausdrücklich ausschließt und nur Verbindungs-Plugins eine Ausnahme bilden können, und für Umgebungen, die auf ansible-base 2.10 oder Ansible 2.9 festgelegt sind.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Wofür community.general im Ansible-Paket steht
Die Beschreibung im Repository ist denkbar kurz: Ansible Community General Collection. Das README führt sie aus und ordnet die Sammlung ein: Sie enthält die community.general-Collection, gehört zum Ansible-Paket und versammelt viele Module und Plugins, die von der Gemeinschaft getragen werden und in keiner spezialisierteren Sammlung untergekommen sind.
Diese negative Definition ist genauer, als sie klingt. Die Sammlung ist kein Themenpaket mit einem festen Gegenstand, sondern der Auffangraum für alles, was anderswo keinen Platz hat. Wer ein Modul sucht, das sich keinem klar abgegrenzten Bereich wie Datenbanken, Cloud oder Netzwerk zuordnen lässt, wird hier eher fündig als in einer Fachsammlung.
Zu den Kennzahlen gehören 1.065 Sterne, 1.825 Forks und 637 offene Issues. Als Hauptsprache ist Python angegeben, der Standardzweig heißt main. Die enthaltenen Inhalte listet das README nicht selbst auf, sondern verweist auf die Seite der Sammlung bei Ansible Galaxy sowie auf die Dokumentation im Ansible-Dokumentationsbereich.
Keine Windows-Ziele: Die Ausschlussregel im README
Eine Einschränkung steht im README besonders deutlich, und sie betrifft eine häufige Fehlannahme. Die Sammlung unterstützt keine Windows-Ziele. Als einzige Ausnahme nennt das README Verbindungs-Plugins aus dieser Sammlung, und auch nur dann, wenn sie eine Windows-Unterstützung in ihrer Dokumentation ausdrücklich erwähnen.
Wer also ein Modul aus community.general gegen einen Windows-Host richten will, hat keine Grundlage im README. Die Formulierung ist eindeutig und erspart die Fehlersuche am Zielsystem. Für gemischte Umgebungen bedeutet das, dass Windows-Aufgaben in anderen Sammlungen oder mit anderen Werkzeugen gelöst werden müssen, während community.general den übrigen Bestand abdeckt.
Diese Trennung passt zur Aufgabe der Sammlung. Sie sammelt Inhalte, die von der Gemeinschaft getragen werden, und die Prüflasten liegen dort, wo die Beitragenden sie leisten können. Eine Aussage über Windows-Unterstützung wäre eine Zusage, die niemand abgesichert hat, und genau deshalb fehlt sie.
ansible-core 2.18 bis 2.21 und ansible-base 2.10 als Unterstützungsgrenze
Zur Kompatibilität macht das README präzise Angaben. Getestet wird mit den aktuellen Ausgaben von ansible-core 2.18, ansible-core 2.19, ansible-core 2.20 und ansible-core 2.21 sowie mit der jeweils aktuellen Entwicklungsversion von ansible-core. Was darunter liegt, fällt heraus: Versionen vor ansible-core 2.18.0 werden nicht unterstützt, und das schließt ausdrücklich alle Ausgaben von ansible-base 2.10 und Ansible 2.9 ein.
Für die eigene Planung ist das eine klare Kante. Vier getestete Linien plus die Entwicklungsversion ergeben ein breites Fenster, aber wer auf einer älteren Basis steht, bekommt keine Zusage. Gerade bei Sammlungen, die mit dem Paket ausgeliefert werden, ist diese Angabe hilfreich, weil sich die Version der Sammlung und die Version von ansible-core unabhängig voneinander bewegen können.
Einen Hinweis gibt das README zu Abhängigkeiten: Manche Module und Plugins verlangen externe Bibliotheken. Eine Gesamtliste gibt es nicht, stattdessen soll die Dokumentation des jeweiligen Moduls oder Plugins geprüft werden. Diese Regel verlagert die Arbeit auf den Einzelfall, was bei einer Sammlung ohne gemeinsamen Gegenstand folgerichtig ist, aber bei jedem neuen Modul einen zusätzlichen Blick erfordert.
ansible-galaxy collection install community.general und requirements.yml
Der bequemste Weg ist keiner: Die Sammlung wird mit dem Ansible-Paket ausgeliefert. Wer dieses Paket installiert hat, muss laut README nichts weiter tun.
Anders sieht es bei einer Minimalinstallation aus, also wenn nur Ansible Core vorliegt, oder wenn die neueste Ausgabe der Sammlung neben dem vollständigen Paket gewünscht ist. Dann führt der Weg über Ansible Galaxy und das Werkzeug auf der Kommandozeile:
ansible-galaxy collection install community.general
Für wiederholbare Aufbauten empfiehlt sich eine Datei requirements.yml mit diesem Inhalt:
collections: - name: community.general
Installiert wird sie anschließend mit ansible-galaxy collection install -r requirements.yml. Diese Form hat einen praktischen Vorteil, weil die Sammlung zusammen mit weiteren Einträgen in einer Datei steht und der Aufbau auf einem anderen Rechner denselben Stand erzeugt.
Eine Folge sollte man kennen: Eine von Hand installierte Sammlung wird beim Aktualisieren des Ansible-Pakets nicht automatisch mitgezogen. Wer auf dem neuesten Stand bleiben will, führt den Installationsbefehl mit --upgrade aus.
community.general:==X.Y.Z als Ausweg, wenn die letzte Ausgabe bricht
Für den Fall, dass eine neue Ausgabe nicht tut, was sie soll, hält das README einen Ausweg bereit. Es lässt sich eine bestimmte Version festlegen:
ansible-galaxy collection install community.general:==X.Y.Z
Als Begründung nennt das README genau den Fall des Herabstufens, wenn in der neuesten Ausgabe etwas nicht funktioniert, verbunden mit der Bitte, einen Eintrag im Repository zu eröffnen. Diese Bitte ist mehr als eine Floskel, weil Sammlungen mit mehreren hundert Modulen von Rückmeldungen aus der Praxis leben.
Der Vergleich mit der mitgelieferten Variante ergibt eine klare Empfehlung. Wer community.general aus dem Ansible-Paket nutzt, erhält eine geprüfte Kombination, die mit dem Paket wandert, und hat keine Arbeit mit der Pflege. Wer die Sammlung von Hand installiert, bekommt schneller neue Module, trägt aber die Verantwortung für Aktualisierung und Rückschritte selbst und muss bei Problemen die Version festschreiben.
Welche Wahl passt, hängt vom Umgang mit Änderungen ab. In einer Umgebung mit festen Freigaben ist die mitgelieferte Version die ruhigere Grundlage. In einem Projekt, das ein neu aufgenommenes Modul braucht, führt kein Weg an der Installation aus Ansible Galaxy vorbei.
Externe Bibliotheken pro Modul statt einer zentralen Liste
Ein Punkt verdient eigene Aufmerksamkeit, weil er im Betrieb regelmäßig unterschätzt wird. Das README weist darauf hin, dass manche Module und Plugins externe Bibliotheken benötigen, verzichtet aber auf eine Aufzählung. Stattdessen wird auf die Dokumentation des jeweils eingesetzten Moduls oder Plugins verwiesen.
Daraus folgt eine einfache Arbeitsweise: Vor der Aufnahme eines Moduls in ein Playbook gehört der Blick in dessen Dokumentation, um die Voraussetzungen zu kennen. In der Praxis betrifft das häufig Python-Bibliotheken auf dem Steuerrechner oder Pakete auf dem Zielsystem, die nicht mit der Sammlung geliefert werden.
Für die Sammlung als Ganzes ist das eine nachvollziehbare Entscheidung, weil eine zentrale Liste bei dieser Zahl an Modulen ständig veralten würde. Für Anwendende bedeutet es, dass ein funktionierendes Playbook nicht automatisch auf ein anderes System übertragbar ist, wenn dort die Zusatzbibliotheken fehlen. Wer Automatisierung zwischen Umgebungen verschiebt, sollte die Voraussetzungen deshalb dokumentieren, statt sich auf die Sammlung zu verlassen.
commit-rights.md, die Watch-Einstellung und die Releases 12.6.4 bis 13.3.0
Für die Mitarbeit verweist das README auf eine Datei CONTRIBUTING.md im Repository und nennt die aktuell Verantwortlichen in der Datei commit-rights.md. Wer Fragen hat, kann sie laut README in Vorschlägen ansprechen. Ergänzend werden der Entwicklerleitfaden für Sammlungen und der Gemeinschaftsleitfaden genannt; für Tests zeigt das README auf die entsprechenden Abschnitte im Entwicklerleitfaden.
Die Pflege der Sammlung ist ebenfalls geregelt. Für die Rolle der Betreuenden verweist das README auf zwei Dokumente, zum einen die Committer-Richtlinien in commit-rights.md, zum anderen die Betreuungsrichtlinien in der Datei maintaining.rst. Von Betreuenden wird erwartet, dass sie zwei Dinge abonniert haben: die Sammlung selbst über die Watch-Einstellung auf All Activity sowie ein eigenes Thema mit dem Titel Changes Impacting Collection Contributors and Maintainers.
Wie viele Linien parallel gepflegt werden, zeigen die jüngsten Ausgaben. 13.2.0 erschien am 13. Juli 2026, danach folgten am 10. August 2026 innerhalb von etwa 35 Minuten 12.6.4 und 13.3.0. Zwei Hauptlinien werden also gleichzeitig mit Korrekturen versorgt. Wer eine Version festschreibt, sollte deshalb angeben, in welcher Linie der eigene Stand liegt, statt nur ein Datum zu nennen.
Redaktionelles Fazit
Geeignet ist community.general für Automatisierung auf Linux- und Unix-artigen Zielen, die Module und Plugins jenseits der spezialisierten Sammlungen braucht und mit einer der getesteten ansible-core-Linien 2.18 bis 2.21 arbeitet. Weniger geeignet ist sie für Windows-Ziele, weil das README diese ausdrücklich ausschließt und nur Verbindungs-Plugins eine Ausnahme bilden können, und für Umgebungen, die auf ansible-base 2.10 oder Ansible 2.9 festgelegt sind. Vor dem Einsatz sollte geprüft werden, welche Version bereits im Ansible-Paket steckt, ob ansible-galaxy collection install community.general eine neuere Ausgabe nachzieht und welche externen Bibliotheken die konkret genutzten Module verlangen.
Community-Notizen