Byggfunksjoner

En feature er en navngitt byggmodul. Registry-posten kan deklarere pakker for én eller flere distribusjonsfamilier og kan også inneholde build hooks, aliaser, capability-metadata og guest assertions.

Å legge til en feature uttrykker intensjon. Det beviser ikke i seg selv at hver pakke var tilgjengelig, at hver hook kjørte, eller at resulterende oppførsel fungerer på målbildet. Oppskriftvalidering, fullført build og guest-verifisering er separate porter.

Finn gjeldende feature-sett

Bruk feature selector eller feature-catalog API i den utrullede OpenFactory-versjonen. Det utdataet er autoritativt for den kjørende versjonen. Statiske lister blir raskt utdaterte, og noen registry-poster er skjulte fordi de støtter interne fixtures eller ufullstendige integrasjoner.

Før du velger en feature, sjekk:

• om den er synlig og aktivert for kontoen din;
• om den deklarerer pakker for oppskriftens distribusjonsfamilie;
• om eksterne kilder er festet og kan hentes;
• om den har assertions som beviser oppførselen du trenger; og
• om den er i konflikt med en annen etterspurt modul.

Representative kategorier

Registry inneholder for tiden moduler i kategorier som:

Eksemplene er ikke en kompatibilitetsmatrise. Et feature-navn kan finnes mens en bestemt distribusjonsimplementering fortsatt er delvis.

Feature, pakke og tjeneste er forskjellige

• os.features velger registrerte byggmoduler.
• os.packages ber den native package manager om spesifikke pakker.
• os.services angir navngitt enablement- og konfigurasjonsintensjon.

For eksempel:

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

En gyldig tjenestekonfigurasjon kan fortsatt inneholde nøkler generatoren ikke bruker. Inspiser den normaliserte oppskriften og test den genererte guest.

Security- og compliance-etiketter

security-hardening installerer og konfigurerer en generell hardening-baseline. Det er ikke synonymt med en CIS-profil. hardening_level i oppskriften er en konfigurasjonsetikett som målspesifikke generatorer tolker; det er ikke sertifisering eller universell mapping til CIS Level 1 eller Level 2.

Feature cis-benchmarks har en mer spesifikk Ubuntu 24.04 Level 1-remedieringssti. Andre baser får ikke samme rolle. Se CIS benchmark evidence for den nøyaktige grensen.

På samme måte etablerer aktivering av en feature navngitt for GxP, HIPAA, SOC 2, PCI DSS, NIST eller DISA ikke organisatorisk compliance. Det kan legge til pakker, konfigurasjon og tester som bidrar med bevis til en separat styrt vurdering.

Kombiner features trygt

1. Start med det minste settet som uttrykker ønsket oppførsel.
2. Valider oppskriften og inspiser normalisert output for droppede eller utledede felt.
3. Gjennomgå den utvidede pakke- og hook-planen.
4. Bygg én gang og følg den varige build ID.
5. Kjør feature-spesifikke assertions i en bootet guest.
6. Registrer feil og bevisste unntak eksplisitt.
7. Legg til en feature til først når nåværende baseline er forstått.

For den kanoniske JSON-formen, se Recipe Schema.