Buildfunktioner

En feature är en namngiven buildmodul. Registry-posten kan deklarera paket för en eller flera distributionsfamiljer och kan också innehålla build hooks, alias, capability-metadata och guest assertions.

Att lägga till en feature uttrycker avsikt. Det bevisar inte i sig att varje paket fanns tillgängligt, att varje hook kördes eller att det resulterande beteendet fungerar på målbilden. Receptvalidering, färdig build och guest-verifiering är separata grindar.

Hitta aktuell feature-uppsättning

Använd feature selector eller feature-catalog API i den utrullade OpenFactory-versionen. Den utdata är auktoritativ för den körande versionen. Statiska listor blir snabbt inaktuella, och vissa registry-poster är dolda eftersom de stödjer interna fixtures eller ofullständiga integrationer.

Innan du väljer en feature, kontrollera:

• om den är synlig och aktiverad för ditt konto;
• om den deklarerar paket för receptets distributionsfamilj;
• om externa källor är pinnade och kan hämtas;
• om den har assertions som bevisar beteendet du behöver; och
• om den kolliderar med en annan begärd modul.

Representativa kategorier

Registry innehåller för närvarande moduler i kategorier som:

Exemplen är inte en kompatibilitetsmatris. Ett feature-namn kan finnas medan en viss distributionsimplementering fortfarande är ofullständig.

Feature, paket och tjänst skiljer sig åt

• os.features väljer registrerade buildmoduler.
• os.packages ber den inbyggda package manager om specifika paket.
• os.services anger namngiven enablement- och konfigurationsavsikt.

Till exempel:

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

En giltig tjänstconfig kan fortfarande innehålla nycklar som generatorn inte konsumerar. Inspektera det normaliserade receptet och testa den genererade guest.

Security- och compliance-etiketter

security-hardening installerar och konfigurerar en allmän hardening-baseline. Det är inte synonymt med en CIS-profil. hardening_level i receptet är en konfigurationsetikett som målspecifika generatorer tolkar; det är inte certifiering eller universell mappning till CIS Level 1 eller Level 2.

Feature cis-benchmarks har en mer specifik Ubuntu 24.04 Level 1-remedieringsväg. Andra baser får inte samma roll. Se CIS benchmark evidence för den exakta gränsen.

På samma sätt innebär aktivering av en feature namngiven för GxP, HIPAA, SOC 2, PCI DSS, NIST eller DISA inte organisatorisk compliance. Det kan lägga till paket, konfiguration och tester som bidrar med bevis till en separat styrd bedömning.

Kombinera features säkert

1. Börja med den minsta uppsättning som uttrycker det begärda beteendet.
2. Validera receptet och inspektera normaliserad utdata efter borttagna eller härledda fält.
3. Granska den utökade paket- och hook-planen.
4. Bygg en gång och följ det beständiga build ID.
5. Kör feature-specifika assertions i en bootad guest.
6. Dokumentera fel och avsiktliga undantag uttryckligen.
7. Lägg till en feature till först när nuvarande baseline är förstådd.

För den kanoniska JSON-formen, se Recipe Schema.