Reinstall and server identity

CloudStats identifies a live server by organization + Linux machine id, not by hostname alone.

The agent reads machine id from /etc/machine-id, then /var/lib/dbus/machine-id if needed. If both are empty it sends the hostname. Enrollment requires a machine id; an empty value is rejected.

Re-run the current installer#

The current install script always enrolls with the token it was served with. There is no “binary-only upgrade” mode.

curl -fsSL https://install.cloudstats.me/<ENROLLMENT_TOKEN> | sudo bash

<ENROLLMENT_TOKEN> is a placeholder. Copy a new command from the CloudStats UI. A token cannot be reused (enrollment token was already used).

After a successful enroll the current installer:

• Replaces the binary with the version the installer pins (currently v0.2.2)
• Writes new config to agent.json.new and, on success, replaces agent.json
• Clears /var/lib/cloudstats/wal only when the new `server_id` differs from the previous one
• Removes /var/lib/cloudstats/server-deleted and /var/lib/cloudstats/update-ready
• Enables the uninstall and update path units only after that successful enroll
• Restarts cloudstats-agent.service

If enroll fails, existing agent.json is left unchanged.

Same host, new token#

A live host whose machine id is unchanged reuses the existing server. You do not get a second server for that machine in the same account. The previous agent credential on that server is revoked and a new one is issued. Hostname and agent version on the server record are updated.

That is the normal reinstall / upgrade path.

Deleted server, same machine#

If you deleted the server in CloudStats and then install again with a new token on the same machine id, CloudStats creates a new server_id. Metric history for the old server is not attached to the new one in the website list. The installer clears the local WAL because server_id changed.

Same token twice#

The first enroll consumes the token. The second call with that token fails with enrollment token was already used. No second server is created.

v0.1.0 installer difference#

The v0.1.0 install script skipped enrollment when /etc/cloudstats/agent.json already existed. It only replaced the binary and restarted the unit.

The current installer does not do that. Upgrading a v0.1.0 host to v0.2.2 requires a fresh UI command (new token). If the machine id is unchanged, the server record is reused.

Clones and duplicated machine ids#

If you clone a VM and keep the same /etc/machine-id, a new install in the same CloudStats account can attach to the existing server instead of creating another one. Give clones a unique machine id before you enroll them if they should appear as separate servers.

Machine ids are not shared across different CloudStats accounts.

Do not send identity files#

Do not send /etc/cloudstats/agent.json, enrollment tokens, or credentials. If you need help, send systemctl status cloudstats-agent output and journalctl -u cloudstats-agent lines that include server_id / agent_id only.