Buildfuncties

Een feature is een benoemde buildmodule. Het registry-item kan pakketten voor een of meer distributiefamilies declareren en kan ook build hooks, aliassen, capability-metadata en guest assertions bevatten.

Een feature toevoegen drukt intentie uit. Het bewijst op zichzelf niet dat elk pakket beschikbaar was, elke hook draaide of het resulterende gedrag op de doelimage werkt. Receptvalidatie, buildafronding en guest-verificatie zijn aparte poorten.

Het actuele feature-set vinden

Gebruik de feature selector of feature-catalog API in de uitgerolde OpenFactory-release. Die output is leidend voor de draaiende versie. Statische lijsten verouderen snel, en sommige registry-items zijn verborgen omdat ze interne fixtures of onvolledige integraties ondersteunen.

Controleer voordat u een feature kiest:

• of deze zichtbaar en ingeschakeld is voor uw account;
• of deze pakketten declareert voor de distributiefamilie van het recept;
• of externe bronnen zijn vastgezet en op te halen;
• of er assertions zijn die het gedrag bewijzen dat u nodig hebt; en
• of deze botst met een andere aangevraagde module.

Representatieve categorieën

De registry bevat momenteel modules in categorieën zoals:

De voorbeelden vormen geen compatibiliteitsmatrix. Een featurenaam kan bestaan terwijl een concrete distributie-implementatie nog gedeeltelijk is.

Feature, pakket en service zijn verschillend

• os.features selecteert geregistreerde buildmodules.
• os.packages vraagt de native package manager om specifieke pakketten.
• os.services levert benoemde enablement- en configuratie-intentie.

Bijvoorbeeld:

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

Een geldige serviceconfig kan nog steeds keys bevatten die de generator niet verwerkt. Inspecteer het genormaliseerde recept en test de gegenereerde guest.

Security- en compliance-labels

security-hardening installeert en configureert een algemene hardening-baseline. Het is niet synoniem met een CIS-profiel. hardening_level in het recept is een configuratielabel dat doelspecifieke generators interpreteren; het is geen certificering of universele mapping naar CIS Level 1 of Level 2.

De feature cis-benchmarks heeft een specifieker Ubuntu 24.04 Level 1-remediatiepad. Andere bases krijgen niet dezelfde rol. Zie CIS benchmark evidence voor de exacte grens.

Evenzo brengt het inschakelen van een feature met een naam voor GxP, HIPAA, SOC 2, PCI DSS, NIST of DISA geen organisatorische compliance tot stand. Het kan pakketten, configuratie en tests toevoegen die bewijs leveren voor een apart gereguleerde beoordeling.

Features veilig combineren

1. Begin met de kleinste set die het gevraagde gedrag uitdrukt.
2. Valideer het recept en inspecteer de genormaliseerde output op weggelaten of afgeleide velden.
3. Bekijk het uitgebreide pakket- en hook-plan.
4. Bouw eenmaal en volg de duurzame build-ID.
5. Voer feature-specifieke assertions uit in een opgestarte guest.
6. Leg fouten en bewuste uitzonderingen expliciet vast.
7. Voeg pas een andere feature toe nadat de huidige baseline duidelijk is.

Voor de canonieke JSON-vorm, zie Recipe Schema.