Buildfunktioner

En feature er et navngivet buildmodul. Registry-posten kan deklarere pakker til en eller flere distributionsfamilier og kan også indeholde build hooks, aliaser, capability-metadata og guest assertions.

At tilføje en feature udtrykker hensigt. Det beviser ikke i sig selv, at hvert pakke var tilgængeligt, at hver hook kørte, eller at den resulterende adfærd virker på målbilledet. Opskriftsvalidering, færdig build og guest-verifikation er separate porte.

Find det aktuelle feature-sæt

Brug feature selector eller feature-catalog API i den udrullede OpenFactory-version. Det output er autoritativt for den kørende version. Statiske lister bliver hurtigt forældede, og nogle registry-poster er skjulte, fordi de understøtter interne fixtures eller ufuldstændige integrationer.

Før du vælger en feature, tjek:

• om den er synlig og aktiveret for din konto;
• om den deklarerer pakker til opskriftens distributionsfamilie;
• om dens eksterne kilder er fastgjort og kan hentes;
• om den har assertions, der beviser den adfærd, du har brug for; og
• om den er i konflikt med et andet anmodet modul.

Repræsentative kategorier

Registry indeholder i øjeblikket moduler i kategorier som:

Eksemplerne er ikke en kompatibilitetsmatrix. Et feature-navn kan findes, mens en bestemt distributionsimplementering stadig er delvis.

Feature, pakke og tjeneste er forskellige

• os.features vælger registrerede buildmoduler.
• os.packages beder den native package manager om specifikke pakker.
• os.services angiver navngiven enablement- og konfigurationshensigt.

For eksempel:

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

En gyldig tjenestekonfiguration kan stadig indeholde nøgler, som generatoren ikke bruger. Inspicer den normaliserede opskrift og test den genererede guest.

Security- og compliance-etiketter

security-hardening installerer og konfigurerer en generel hardening-baseline. Det er ikke synonymt med en CIS-profil. hardening_level i opskriften er en konfigurationsetiket, som målspecifikke generatorer fortolker; det er ikke certificering eller universel mapping til CIS Level 1 eller Level 2.

Feature cis-benchmarks har en mere specifik Ubuntu 24.04 Level 1-remedieringssti. Andre baser får ikke samme rolle. Se CIS benchmark evidence for den præcise grænse.

Ligeledes etablerer aktivering af en feature navngivet efter GxP, HIPAA, SOC 2, PCI DSS, NIST eller DISA ikke organisatorisk compliance. Det kan tilføje pakker, konfiguration og tests, der bidrager med bevis til en separat styret vurdering.

Kombiner features sikkert

1. Start med det mindste sæt, der udtrykker den ønskede adfærd.
2. Valider opskriften og inspicer normaliseret output for droppede eller udledte felter.
3. Gennemgå den udvidede pakke- og hook-plan.
4. Byg én gang og følg det varige build ID.
5. Kør feature-specifikke assertions i en bootet guest.
6. Registrer fejl og bevidste undtagelser eksplicit.
7. Tilføj en feature til først, når den nuværende baseline er forstået.

For den kanoniske JSON-form, se Recipe Schema.