v1.8.0

Added — Stable machine identity

• The agent now reports a stable host machine-id (Linux machine-id, via gopsutil's
  HostID). The panel uses it to detect when the same physical server has been registered
  twice within the same account and shows a "Duplicate" hint. The identifier is only ever
  compared within an account — never across accounts.

To apply on an existing install, re-run the installer (curl … | sudo bash) or restart the
service after updating the binary.

v1.7.0

Fixed — Disk and log metric accuracy

• Disk usage no longer counts pseudo filesystems. The agent previously reported every
  mount, including the read-only squashfs mounts of snaps (/snap/...), which always sit
  at 100%. That made the dashboard and the AI report a "disk full" while the real root
  filesystem was far below capacity. The collector now ignores virtual/pseudo filesystems
  (squashfs, tmpfs, devtmpfs, overlay, …) and system paths (/snap, /proc,
  /sys, /dev, /run), reporting only real storage.
• The agent no longer collects its own logs. Its systemd units (auranode-agent,
  auranode-agent-helper) emit self-referential noise (e.g. WebSocket reconnections) that
  polluted server diagnostics. They are now always excluded from journal collection.

To apply on an existing install, re-run the installer (curl … | sudo bash) or restart the
service after updating the binary.

v1.6.0

Added — System log collection (read-only)

• The agent now collects system logs and streams them to the panel. It follows the
  systemd journal (journalctl -f -o json), maps each entry to a service (unit) and a
  level (from syslog priority), batches them and sends them to the backend, where they
  appear under Logs in the dashboard (filterable by service and level). The backend
  can narrow collection to specific units via the log_services config; empty means all.
• Read-only journal access, no privilege escalation. The installer adds the
  unprivileged auranode user to the systemd-journal group and sets
  SupplementaryGroups=systemd-journal on the service. This grants read access to
  the journal only — the agent is still not root, keeps NoNewPrivileges,
  ProtectSystem=strict and an empty CapabilityBoundingSet. This is the standard
  approach for monitoring agents.
• Graceful when unavailable. On systems without journalctl (non-systemd) or
  without journal access, the collector simply produces nothing — it never fails the
  agent. To enable log collection on an existing install, re-run the installer
  (curl … | sudo bash) so the group membership and updated unit are applied.

v1.5.1

Added

• Automation webhook action implemented. When an automation rule with a
  webhook action fires, the agent now sends a POST (JSON, 10s timeout) to the
  configured URL with the trigger context: rule_id, metric, operator,
  threshold, value and fired_at (RFC3339). The result is reported back as the
  rule's exit status: 0 on a 2xx response, the HTTP status code otherwise (e.g.
  404, 500), or 1 on a transport error — so the panel's "Executions" tab shows
  a meaningful outcome. (Previously this action was a no-op.)

v1.5.0

Added — Bounded privileged mode (opt-in, OFF by default)

This release adds an optional way to run a small, fixed set of administrative
tasks (package updates, service restarts) from the panel. It is designed to be the
opposite of "give the panel root": every part is opt-in, bounded, validated, and
audited. If you do nothing, nothing changes — the agent keeps running exactly as
before.

The agent itself does not gain any privileges. It still runs as the unprivileged
auranode user with NoNewPrivileges, ProtectSystem=strict and an empty
CapabilityBoundingSet. Privileged tasks are handled by a separate helper:

• Separate root helper, separate unit. Privileged actions run in
  auranode-agent-helper.service (a distinct systemd unit running as root), not in
  the agent. The agent talks to it over a local Unix socket and only acts as a bridge.
  The helper is installed only if the server operator runs
  curl … | sudo bash -s -- --enable-privileged on the machine itself — it is never
  installed automatically.
• Two independent opt-ins. The helper must be installed on the box (local consent)
  and the account owner must enable privileged mode for that server in the
  panel (with an explicit confirmation). Neither step alone does anything.
• Not arbitrary sudo — a fixed whitelist. The only actions that exist are:
  apt/dnf update, upgrade, install, autoremove; and systemctl
  status/start/stop/reload/restart. There is no "run this command" path.
• No shell, no injection. Commands are executed with an explicit argv
  (no bash -c), so shell metacharacters are inert. Arguments are validated with
  strict allowlists (package names, unit names).
• Guards against foot-guns. The helper refuses to manage the agent itself
  (auranode-agent*) and refuses to stop critical units (ssh, dbus,
  networking, systemd-journald, systemd-logind, …) that would lock you out.
• Defense in depth. The helper re-validates every request against the same
  whitelist server-side, so a compromised agent still cannot run anything off-list.
• Locked-down socket. The socket lives at /run/auranode/helper.sock, owned by
  root and group-restricted to the auranode user (mode 0660); one action runs at a
  time; each action has a timeout and bounded output.
• Fully audited. Enabling/disabling the mode and every action (with its arguments
  and exit code) are written to the audit log.
• auranode-agent version subcommand advertises privileged-capable, so the
  installer refuses to enable the helper on an incompatible binary.

Backward compatible. Agents without the helper report it as unavailable and the
panel keeps the feature hidden/disabled; the new sys_action protocol messages are
ignored by older agents. To revert at any time: … | sudo bash -s -- --disable-privileged.

v1.4.0

Changelog

v1.3.0

Changelog

v1.2.1

Changelog

v1.2.0

Changelog

v1.1.0

Changelog