Development Workstation

Dieser Guide baut eine Ubuntu-24.04-GNOME-Workstation mit konservativem Tool-Set und expliziten Smoke-Tests. Sprach- und Editor-Versionen folgen den gewählten Paketquellen, sofern Sie keine andere Quelle pinnen und prüfen.

Prompt


Create an Ubuntu 24.04 GNOME development workstation with a dark color
scheme, SSH, Docker, Git, Python, Node.js, curl, jq, tmux, htop, and Neovim.
Create a locked-password user named dev with sudo and Docker group intent.
Do not add third-party repositories unless their HTTPS URL, signing key,
release support, and license are explicit. Add tests for the desktop session,
tool versions, Docker service, group membership, and one container smoke test.

Rezept prüfen


{
  "name": "ubuntu24-development-workstation",
  "base_image": "ubuntu-24.04",
  "os": {
    "features": ["desktop", "ssh", "docker", "git", "python", "nodejs"],
    "packages": ["curl", "jq", "tmux", "htop", "neovim"],
    "users": [
      {
        "username": "dev",
        "groups": ["sudo", "docker"],
        "shell": "/bin/bash"
      }
    ],
    "desktop_settings": {
      "color_scheme": "prefer-dark",
      "fonts": {
        "monospace_font": "Ubuntu Mono 13"
      },
      "power": {
        "idle_delay": 600,
        "sleep_inactive_ac_timeout": 0,
        "sleep_inactive_ac_type": "nothing"
      }
    }
  }
}

Bestätigen Sie, dass jedes Feature auf Ubuntu 24.04 wie erwartet expandiert. docker-Gruppenmitgliedschaft ist häufig root-äquivalent, weil sie den Docker-Daemon steuern kann; entfernen Sie sie, wenn der User diese Autorität nicht haben soll.

Versionen und Quellen

Fordern Sie in einer kontrollierten Workstation kein „latest“ an. Dokumentieren Sie die Versionen aus dem gewählten Snapshot und testen Sie diese. Ein Vendor-Repository oder Bootstrap-Installer fügt eine separate Trust Root und Update-Lebensdauer hinzu; nutzen Sie es erst nach Review von Key, Repository-Metadaten, Terms und Rollback-Verhalten.

Tools wie Rustup, Language Version Manager, Editor-Extensions und Container-Images können beweglichen Code nach dem Image-Build laden. Sind sie für die Workstation-Baseline relevant, pinnen Sie sie und nehmen Sie Provenienz ins Evidenzpaket auf.

Verifikations-Szenario


{
  "id": "development-smoke",
  "name": "Development workstation smoke test",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "custom_tests": [
    {
      "description": "Confirm core tools and Docker are usable.",
      "assertions": [
        {
          "type": "command_succeeds",
          "description": "Python reports a version.",
          "params": {"command": "python3 --version"}
        },
        {
          "type": "command_succeeds",
          "description": "Node.js reports a version.",
          "params": {"command": "node --version"}
        },
        {
          "type": "service_running",
          "description": "The Docker daemon is running.",
          "params": {"service": "docker"}
        },
        {
          "type": "user_in_group",
          "description": "The dev account has the reviewed Docker authority.",
          "params": {"username": "dev", "group": "docker"}
        }
      ]
    }
  ]
}

Fügen Sie eine GUI-Assertion für jeden grafischen Editor hinzu, den Sie wirklich installieren. Ein Paket-Check erkennt keinen kaputten Erststart, Lizenzdialog, fehlende Display-Integration oder falschen Default-Desktop.

Testen Sie abschließend Login mit genehmigtem Enrollment- oder SSH-Key-Pfad; das Rezept enthält absichtlich kein Passwort.