Install the agent

systemd, container, LXC, OpenWrt – every path, every architecture.

The NODE64 agent is a single, statically linked program with no dependencies. No runtime, no libraries, no packages – one file of around six megabytes.

The currently published build is 1.16.0. To see which one you are running: node64-agent --version.

Architectures #

The install script detects the architecture itself.

Path 1: Linux with systemd #

curl -sSL https://get.node64.de/install.sh | NODE64_TOKEN=your-token sh

The script verifies the SHA-256 sum of the binary, installs /usr/local/bin/node64-agent, writes /etc/node64/agent.conf, sets up node64-agent.service and starts it. If the checksum does not match, it aborts – better no agent than a substituted one.

Without a token the script only installs; you can connect later:

node64-agent enroll --token=your-token

Path 2: Container #

docker run -d --name node64-agent \
  --network host \
  -e NODE64_TOKEN=your-token \
  -e NODE64_HOST_ROOT=/host \
  -v /:/host:ro \
  -v node64-state:/var/lib/node64 \
  node64/agent:latest

Two things matter:

• NODE64_HOST_ROOT=/host together with -v /:/host:ro. Without it the agent only sees the container – no host packages, no services, no configuration, and none of its logs either. With the mounted filesystem it reports the host; for the log signals it then reads the journal under /host/var/log/journal.
• A persistent volume for /var/lib/node64. That is where the device identity lives. Without a volume the agent is a new device after every restart.

The image is a FROM scratch image: no operating system, no shell, nothing but the binary.

Path 3: LXC container (Proxmox) #

An LXC is just a normal Linux to the agent. Installation works as in path 1 – inside the container, not on the host. If you want to monitor the Proxmox host itself, install the agent there as well; the Proxmox checks only apply on the host.

Path 4: OpenWrt and others without systemd #

curl -sSL https://get.node64.de/install.sh | NODE64_TOKEN=your-token sh

If the script finds no systemd, it installs an init script (/etc/init.d/node64-agent). On very small devices storage can get tight – the binary can also live on a USB stick and be started from there.

Configuration #

The agent reads in this order: command line → environment variable → configuration file → default.

# /etc/node64/agent.conf
NODE64_SERVER=https://app.node64.de
NODE64_INTERVAL=15m
NODE64_SONAR=false

Recommended extra packages #

The agent ships without third-party libraries and needs nothing else for basic operation. For two areas it does fall back on system tools that are not present everywhere:

apt install smartmontools     # Debian, Ubuntu, Proxmox
dnf install smartmontools     # Fedora, RHEL, Rocky
apk add smartmontools         # Alpine

While you are at it: systemctl enable --now smartd watches the drive continuously rather than only on each NODE64 run. Hours pass between runs, and a drive can go from healthy to failed in that time.

Inside a container the agent additionally needs access to the host's devices to read SMART. Without that access it reports the area as limited – that is intended, not a fault.

Commands #

Updating #

curl -sSL https://get.node64.de/install.sh | sh

Without a token the script only installs the new version; the identity in /var/lib/node64/state.json stays. The agent does not update itself – a program that pulls new binaries unattended is the wrong signal on a monitored system.

Stopping without removing #

Sometimes the agent should just be quiet for a while – for maintenance, a migration, a test.

systemctl stop node64-agent        # stop
systemctl start node64-agent       # let it run again
systemctl disable node64-agent     # also off after a reboot

On OpenWrt and other systems without systemd:

/etc/init.d/node64-agent stop
/etc/init.d/node64-agent start
/etc/init.d/node64-agent disable

What happens then: the device stays in the dashboard and after a while is listed as overdue and then offline. That is deliberate – a stopped agent should not look like a healthy system.

If you want to pause the security check without the device counting as failed, do it in the dashboard under Device › Settings › Security check. The agent then collects nothing at all – but it keeps reporting in, and the device stays visible.

Which commands apply on your system, the agent tells you itself:

node64-agent stop

Removing completely #

In one step – the same script that installed it also cleans up:

curl -sSL https://get.node64.de/install.sh | sh -s -- --uninstall

Or by hand. The agent prints the commands for your exact machine, with the actual paths and the init system that is actually present:

node64-agent uninstall

Written out for Linux with systemd:

systemctl stop node64-agent
systemctl disable node64-agent
rm -f /etc/systemd/system/node64-agent.service
systemctl daemon-reload
rm -f /usr/local/bin/node64-agent
rm -rf /etc/node64 /var/lib/node64

The line with the unit file is easily forgotten. systemctl disable only unregisters the service; the file stays behind and shows up in every systemctl list-unit-files later. And without daemon-reload, systemd does not notice it is gone.

For OpenWrt:

/etc/init.d/node64-agent stop
/etc/init.d/node64-agent disable
rm -f /etc/init.d/node64-agent
rm -f /usr/local/bin/node64-agent
rm -rf /etc/node64 /var/lib/node64

Verifying #

command -v node64-agent          # prints nothing
ls /etc/node64 /var/lib/node64   # not present
systemctl list-unit-files | grep node64   # no line

What deliberately stays #

The device in the dashboard. It does not disappear by itself – otherwise a crashed server could not be told apart from a removed one, and that is exactly the difference you want to see.

Delete it under Devices › the device › Delete. That also removes its findings, measurements and history; the device key becomes invalid. An agent installed later needs a new token.

The service logs (journalctl -u node64-agent) belong to the system, not to us. They are rotated normally – we do not touch them.

The agent does not remove itself. It changes nothing on the system as a matter of principle, and there is no exception – not even for itself. That is why it prints the commands instead of running them. If you want it in one step, use the install script: that one may delete, because it also created.

The agent needs no open port. It opens the connection, not the server. That holds for the measurement network too: tasks are fetched, never pushed.

When something does not work #

See Troubleshooting.