Build-Features

Ein Feature ist ein benanntes Build-Modul. Sein Registry-Eintrag kann Pakete für eine oder mehrere Distributionsfamilien deklarieren und kann Build-Hooks, Aliase, Capability-Metadaten und Gast-Assertions enthalten.

Ein Feature hinzuzufügen drückt Absicht aus. Es beweist allein nicht, dass jedes Paket verfügbar war, jeder Hook lief oder das resultierende Verhalten auf dem Ziel-Image funktioniert. Rezeptvalidierung, Build-Abschluss und Gast-Verifikation sind getrennte Gates.

Aktuelles Feature-Set finden

Nutzen Sie Feature-Selector oder Feature-Catalog-API in der ausgerollten OpenFactory-Version. Diese Ausgabe ist maßgeblich für die laufende Version. Statische Listen veralten schnell, und manche Registry-Einträge sind verborgen, weil sie interne Fixtures oder unvollständige Integrationen unterstützen.

Vor der Feature-Wahl prüfen:

• ob es für Ihr Konto sichtbar und aktiviert ist;
• ob es Pakete für die Distributionsfamilie des Rezepts deklariert;
• ob externe Quellen gepinnt und abrufbar sind;
• ob Assertions das benötigte Verhalten beweisen; und
• ob es mit einem anderen angeforderten Modul kollidiert.

Repräsentative Kategorien

Die Registry enthält derzeit Module in Kategorien wie:

Die Beispiele sind keine Kompatibilitätsmatrix. Ein Feature-Name kann existieren, während eine konkrete Distributions-Implementierung noch partiell ist.

Feature, Paket und Service sind verschieden

• os.features wählt registrierte Build-Module.
• os.packages fragt den nativen Package Manager nach konkreten Paketen.
• os.services liefert benannte Enablement- und Konfigurationsabsicht.

Beispiel:

{
  "os": {
    "features": ["ssh", "firewall"],
    "packages": ["curl", "jq"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 22,
          "disable_password_auth": true
        }
      }
    ]
  }
}

Eine gültige Service-Config kann trotzdem Keys enthalten, die der Generator nicht verarbeitet. Normalisiertes Rezept und getesteten Gast prüfen.

Sicherheits- und Compliance-Labels

security-hardening installiert und konfiguriert eine allgemeine Hardening-Baseline. Es ist nicht synonym mit einem CIS-Profil. hardening_level im Rezept ist ein Konfigurationslabel, das zielspezifische Generatoren interpretieren; es ist keine Zertifizierung oder universelle Zuordnung zu CIS Level 1 oder Level 2.

Das Feature cis-benchmarks hat einen spezifischeren Ubuntu-24.04-Level-1-Remediation-Pfad. Andere Bases erhalten nicht dieselbe Rolle. Siehe CIS-Benchmark-Nachweis für die exakte Grenze.

Ebenso begründet das Aktivieren eines Features für GxP, HIPAA, SOC 2, PCI DSS, NIST oder DISA keine organisatorische Compliance. Es kann Pakete, Konfiguration und Tests liefern, die Nachweis für eine separat geführte Bewertung liefern.

Features sicher kombinieren

1. Mit der kleinsten Menge starten, die das angeforderte Verhalten ausdrückt.
2. Rezept validieren und normalisierte Ausgabe auf verworfene oder abgeleitete Felder prüfen.
3. Erweiterten Paket- und Hook-Plan prüfen.
4. Einmal bauen und dauerhafte Build-ID verfolgen.
5. Feature-spezifische Assertions im gebooteten Gast ausführen.
6. Fehler und beabsichtigte Ausnahmen explizit dokumentieren.
7. Weiteres Feature erst hinzufügen, wenn die aktuelle Baseline verstanden ist.

Für die kanonische JSON-Form siehe Rezept-Schema.