Warden automation and packaging

Public downloads for package managers

These HTTPS endpoints work without cookies, tokens, or a signed-in browser. The latest version is 0.1.21. Enrollment is a separate step after you install.

• Latest version as plain text: a version such as 0.1.21, followed by a newline.
• JSON release manifest: schema version 1, the latest version, and published releases with filenames, platforms, content types, download URLs, and SHA-256 checksums.

curl -fsS https://www.witenlabs.com/api/releases/warden/version
curl -fsS https://www.witenlabs.com/api/releases/warden
curl -fLO https://www.witenlabs.com/api/releases/warden/artifacts/witen-warden-0.1.21-linux-amd64-glibc.tar.gz

A versioned artifact URL keeps serving the same bytes after a newer release ships. The manifest lists the available formats for each release. Compare the downloaded file with its manifest checksum before installing it.

SRC_URI="https://www.witenlabs.com/api/releases/warden/artifacts/witen-warden-${PV}-linux-amd64-glibc.tar.gz"

Let an agent install Warden

Give your coding or operations agent SSH access to one host, a Warden artifact, its published SHA-256 checksum, and a fresh enrollment token. Do not paste a fleet recovery credential into an agent session.

Install and enroll Witen Warden on [SSH HOST] as [SSH USER].

Inputs:
- Local Warden artifact: [LOCAL PATH]
- Expected SHA-256: [SHA256]
- Asset name: [UNIQUE HOST NAME]
- Single-use enrollment token: [PROVIDE PRIVATELY]
- Management address/CIDR that must never be blocked: [IP OR CIDR]

Requirements:
1. Inspect the remote OS, architecture, libc, init system, firewall manager, and available SSH/web/Cockpit log sources before changing anything.
2. Select only the matching supported DEB, RPM, APK, glibc portable, musl portable, or legacy 386 build. Verify the artifact with sha256sum before installing it. Stop on any mismatch.
3. Do not print, log, commit, or leave the enrollment token in shell history. Do not expose any resulting sensor credential.
4. Preserve /var/lib/witen. Back up an existing /etc/witen/warden.toml before editing it, and do not alter unrelated services or firewall policy.
5. Configure server_name, the single-use enrollment token, credential_file = "/var/lib/witen/sensor-credential", detected log sources, and never_block for my management address. Warden defaults to https://collector.witenlabs.com; set collector_url only if I explicitly provide a different collector.
6. Run sudo warden validate --config /etc/witen/warden.toml before starting or restarting. On firewalld hosts, also run sudo firewall-cmd --check-config. Treat firewall_manager_compatibility as unresolved until a separately approved maintenance-window reload test proves Warden's objects are reconciled. Stop and ask before any change that could interrupt SSH, DNS, the active firewall manager, or another production service.
7. Enable and start the appropriate systemd or OpenRC service. Confirm its version, service health, source health, firewall backend, enrollment, and reporting in Witen. Remove the consumed enrollment token from the configuration after the sensor credential exists, then validate again.
8. Report the exact package version, checksum, files changed, tests performed, and rollback steps without revealing secrets. If a check fails, preserve evidence and restore the prior configuration rather than improvising a destructive fix.

• Use a short-lived enrollment token generated for this one asset.
• Keep your current management IP or network in never_block before enforcement starts.
• Require checksum, configuration validation, service, source, firewall, and website reporting checks.
• Keep /var/lib/witen during upgrades and rollback; it holds Warden’s state and the sensor credential.