Development workstation

This guide builds an Ubuntu 24.04 GNOME workstation with a conservative tool set and explicit smoke tests. Language and editor versions follow the selected package sources unless you pin and review another source.

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.

Review the recipe


{
  "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"
      }
    }
  }
}

Confirm that each feature expands on Ubuntu 24.04 as expected. docker group membership is commonly root-equivalent because it can control the Docker daemon; remove it if the user should not have that authority.

Versions and sources

Do not ask for “latest” in a controlled workstation. Record the versions actually available from the selected snapshot and test those versions. A vendor repository or bootstrap installer adds a separate trust root and update lifecycle; use it only after reviewing its key, repository metadata, terms, and rollback behavior.

Tools such as Rustup, language version managers, editor extensions, and container images can download moving code after the image is built. If they matter to the workstation baseline, pin them and include their provenance in the evidence packet.

Verification scenario


{
  "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"}
        }
      ]
    }
  ]
}

Add a GUI assertion for every graphical editor you actually install. A package check cannot detect a broken first launch, license dialog, missing display integration, or wrong default desktop.

Finally, test login with the approved enrollment or SSH-key path; the recipe intentionally contains no password.