Skip to main content

Install the Wakora agent on Debian and Ubuntu

Tested on Debian 12 and 13 and on Ubuntu 20.04, 22.04 and 24.04, on amd64 and arm64. Devuan (Debian without systemd) works too and is covered in the init note below.

Install​

curl -fsSL https://get.wakora.io | bash -s -- --key <YOUR_TEAM_KEY>

curl and openssl are the only prerequisites, and both are present on every standard image. If you run the line as a normal user, the installer re-runs itself through sudo.

On systemd hosts the installer writes /etc/systemd/system/wakora-agent.service, enables it and starts it. The unit runs the agent as root with ProtectSystem=full (the system tree is read-only to it, except /etc/wakora, /var/lib/wakora, /var/log/wakora and /usr/local/bin for self-updates), a 30% CPU quota, a lowered scheduling priority and an OOM score that makes the kernel kill the agent before any of your services.

Ubuntu 20.04 and Debian 10​

Their OpenSSL 1.1 cannot verify an ed25519 signature. The installer notices and verifies the ECDSA co-signature of the same binary instead, so the check still happens and still refuses an unsigned file. Nothing to do on your side.

Devuan and other sysvinit systems​

The installer installs and registers the binary, then prints that it found no systemd. Copy the init script from the public repository (packaging/wakora-agent.initd) to /etc/init.d/wakora-agent, make it executable and enable it:

sudo cp wakora-agent.initd /etc/init.d/wakora-agent
sudo chmod +x /etc/init.d/wakora-agent
sudo update-rc.d wakora-agent defaults
sudo service wakora-agent start

The agent knows it runs under sysvinit and relaunches itself correctly after a self-update (there is no supervisor to do it for it).

What the agent finds on a Debian-family host​

Within the first minute the host page shows:

  • the package inventory from dpkg, and the pending updates count from a simulated apt-get upgrade, split into security and other updates, plus whether /var/run/reboot-required exists;
  • systemd units and their state, failed units, and OOM kills from the kernel log;
  • SSH activity from the journal (sshd), with brute-force sources when they appear;
  • every recognised service: nginx or Apache with their sites, MySQL or MariaDB over the local socket with no credentials on a stock install, PHP-FPM pools, Postfix, Docker and the rest of the catalog;
  • host metrics: CPU, memory, swap, disk per mount, load per core, network throughput, and the top processes by CPU, memory and I/O.

Logs from the journal ship at notice level and above by default. Nothing is read from the access logs of your web server until you switch that service to full depth.

Verify​

wakora doctor
systemctl status wakora-agent
tail -f /var/log/wakora/agent.log

Notes​

  • Inside an unprivileged LXC container the agent works, but the kernel refuses eBPF and process profiling there: APM falls back to request rates from the access log and the per-transaction layers still work. See Containers and LXC.
  • The agent never runs apt-get upgrade for real; the update probe is a simulation and the package database is read, not written.
  • A host that also runs Proxmox VE or a mail stack gets those services recognised the same way; nothing is distribution-specific beyond the package manager.

Next: First start explains registration and what the host page shows; Fleet deployment covers cloud-init, Ansible and golden images.