Sync the self-hosting stack
This commit is contained in:
@@ -9,6 +9,40 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
|
|||||||
Every version published to a channel appears here. Nothing is written from memory afterwards: a build
|
Every version published to a channel appears here. Nothing is written from memory afterwards: a build
|
||||||
cannot be published without its entry.
|
cannot be published without its entry.
|
||||||
|
|
||||||
|
## 2026-10-22 — Cloned machines enroll as separate machines `api 2.1.0` `web 2.1.0` `agent 0.52.0`
|
||||||
|
|
||||||
|
**A cloned machine no longer replaces the machine it was cloned from.** Two machines cloned from one
|
||||||
|
VM or container template without regenerating `/etc/machine-id` (on Windows, without sysprep) looked
|
||||||
|
like one machine to Jarvis: installing the agent on the second took over the first one's agent — its
|
||||||
|
key, its asset and its open session. A machine's agent is now identified by its key. Running the
|
||||||
|
install command again on a machine still re-enrolls the same agent onto the same asset, and a
|
||||||
|
reinstall from scratch is still recognised when the agent it replaces is offline and has the same
|
||||||
|
hostname. Any other machine enrolls as a new one with its own asset, and the first is left exactly as
|
||||||
|
it was.
|
||||||
|
|
||||||
|
**What changes for you**
|
||||||
|
|
||||||
|
- **Machines that share a machine ID are marked.** The Agents page and an asset's agent section show
|
||||||
|
**Duplicate ID** on every agent whose machine ID another agent also has, and the tooltip names the
|
||||||
|
others. Give the clone its own machine ID — on Linux, `rm /etc/machine-id && systemd-machine-id-setup`
|
||||||
|
— and run the install command on it again: the mark goes away.
|
||||||
|
- **A single-machine install command run on a clone of that asset's machine is refused while the
|
||||||
|
machine is connected**, instead of taking its place. The command keeps its use: give the clone its
|
||||||
|
own machine ID, or stop the agent on the other machine, and run it again. On different hardware it
|
||||||
|
moves the asset as before.
|
||||||
|
- **The agent identifies a machine by its machine ID and its hardware UUID.** Agent 0.52.0 adds the
|
||||||
|
SMBIOS system UUID, which hypervisors regenerate when they clone a VM, so cloned VMs no longer share
|
||||||
|
an identity at all. A machine with no readable UUID — most containers — sends what it sent before.
|
||||||
|
Running the install command again after the update re-enrolls the same agent, as always. A
|
||||||
|
reinstall from scratch of a VM that has not re-enrolled since the update enrolls as a new machine:
|
||||||
|
delete the old, offline record on the Agents page.
|
||||||
|
- **The database migration is additive.** It turns the unique index on agent fingerprints into a
|
||||||
|
plain one; nothing is dropped, and the api applies it when it starts. Once a clone has enrolled,
|
||||||
|
do not go back to api 2.0.0: its enrollment fails on a fingerprint that two agents share.
|
||||||
|
|
||||||
|
Update the API and web images together. Updating the agent release image is recommended; enrolled
|
||||||
|
machines take the new build under their update policy.
|
||||||
|
|
||||||
## 2026-10-22 — A rebuilt database; 2.0 starts from an empty one `api 2.0.0` `web 2.0.0`
|
## 2026-10-22 — A rebuilt database; 2.0 starts from an empty one `api 2.0.0` `web 2.0.0`
|
||||||
|
|
||||||
**2.0 does not upgrade a 1.x instance.** Its database schema was rebuilt — table and column names,
|
**2.0 does not upgrade a 1.x instance.** Its database schema was rebuilt — table and column names,
|
||||||
|
|||||||
@@ -497,6 +497,16 @@ Four things worth knowing about it:
|
|||||||
whole of the trail. Linux and macOS are not supported yet, and a session opened against one is
|
whole of the trail. Linux and macOS are not supported yet, and a session opened against one is
|
||||||
refused rather than silently downgraded.
|
refused rather than silently downgraded.
|
||||||
|
|
||||||
|
**How Jarvis tells machines apart.** An agent is its key: running the install command again on a
|
||||||
|
machine reuses the key it has, and re-enrolls the same agent onto the same asset. A reinstall from
|
||||||
|
scratch, its key gone, is recognised by the machine's fingerprint — a hash of its machine ID
|
||||||
|
(`/etc/machine-id`, Windows' `MachineGuid`) and its hardware UUID, or the Mac's hardware UUID — when
|
||||||
|
the agent that sent it before is offline and has the same hostname. Anything else enrolls as a machine
|
||||||
|
of its own, so a clone of a VM or container template never replaces the machine it was cloned from.
|
||||||
|
When two agents do share a fingerprint, the Agents page marks both **Duplicate ID**: give the clone its
|
||||||
|
own machine ID (on Linux, `rm /etc/machine-id && systemd-machine-id-setup`) and run the install
|
||||||
|
command on it again.
|
||||||
|
|
||||||
**What an enrolled agent can do.** Inventory the machine, run commands, read, write and fetch files,
|
**What an enrolled agent can do.** Inventory the machine, run commands, read, write and fetch files,
|
||||||
list and control services, list processes, update itself, carry that shell, and — on Windows — show
|
list and control services, list processes, update itself, carry that shell, and — on Windows — show
|
||||||
its screen. It runs as root on Linux and macOS and as LocalSystem on Windows, deliberately: its
|
its screen. It runs as root on Linux and macOS and as LocalSystem on Windows, deliberately: its
|
||||||
|
|||||||
Reference in New Issue
Block a user