Skip to Content
Building OsФункції збірки

Функції збірки

Feature , іменований build module. Запис у registry може оголошувати packages для однієї або кількох distribution families і також містити build hooks, aliases, capability metadata та guest assertions.

Додавання feature виражає intent. Само по собі воно не доводить, що кожен package був доступний, кожен hook виконався або результуюча поведінка працює на target image. Recipe validation, build completion і guest verification , окремі gates.

Знайдіть поточний feature set

Використовуйте feature selector або feature-catalog API у розгорнутому релізі OpenFactory. Цей вивід авторитетний для running version. Статичні списки швидко застарівають, а деякі registry entries приховані, бо підтримують internal fixtures або неповні інтеграції.

Перед вибором feature перевірте:

  • чи він visible і enabled для вашого облікового запису;
  • чи оголошує packages для distribution family рецепта;
  • чи external sources pinned і retrievable;
  • чи має assertions, що доводять потрібну поведінку; та
  • чи конфліктує з іншим запитаним module.

Представницькі категорії

Registry зараз включає modules у категоріях на кшталт:

CategoryExamplesEvidence to require
Desktopdesktop-kde, desktop-gnome-minimal, krita, kdenlivesession type, installed packages, launcher behavior і real desktop smoke test
Command line and developmentgit, curl, python, nodejs, rustpackage/version inventory і executable smoke tests
Infrastructurenginx, postgresql, redis, docker, ansibleservice configuration, enabled/running state, ports і application-level health
Securityfirewall, audit-logging, security-hardening, apparmorgenerated policy, active runtime state, negative tests і documented exceptions
Compliance-orientedcis-benchmarks, gxp, disa-stig, nist-800-53exact benchmark/control source, applicability, per-control results і human disposition
AI toolsollama, alpaca, aider, codex-clipinned source/package provenance, model-download boundary, launch test і resource requirements

Examples , не compatibility matrix. Feature name може існувати, поки distribution implementation залишається partial.

Feature, package і service , різне

  • os.features обирає registered build modules.
  • os.packages просить native package manager про конкретні packages.
  • os.services задає named enablement і configuration intent.

Наприклад:

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

Valid service config може містити key, який generator не споживає. Перегляньте normalized recipe і протестуйте generated guest.

Security and compliance labels

security-hardening встановлює і налаштовує general hardening baseline. Це не синонім CIS profile. hardening_level рецепта , configuration label, який інтерпретують target-specific generators; це не certification і не universal mapping до CIS Level 1 або Level 2.

Feature cis-benchmarks має конкретніший Ubuntu 24.04 Level 1 remediation path. Інші bases не отримують ту саму role. Див. CIS benchmark evidence для exact boundary.

Так само, увімкнення feature з іменем GxP, HIPAA, SOC 2, PCI DSS, NIST або DISA не встановлює organizational compliance. Воно може додати packages, configuration і tests, що дають evidence для окремо керованої assessment.

Безпечне поєднання features

  1. Почніть із найменшого набору, що виражає запитану поведінку.
  2. Валідуйте рецепт і перегляньте normalized output на dropped або inferred fields.
  3. Перегляньте expanded package і hook plan.
  4. Зберіть один раз і слідуйте за durable build ID.
  5. Запустіть feature-specific assertions у booted guest.
  6. Явно фіксуйте failures і intentional exceptions.
  7. Додавайте інший feature лише після розуміння поточного baseline.

Канонічна JSON shape: Recipe Schema.

Образи desktopСервіси