Installing and activating a licence
Licences are bound to a machine
Antelao licences are node-locked. A licence file is issued for one server, identified by that server's hardware challenge, and will not grant its edition anywhere else.
The 14-day activation window
A licence that has never been activated carries no hardware id yet. Rather than refusing it, the server grants its edition for 14 days so you can get running while activation is arranged.
| Length | 14 days |
| Anchored | On first sight of the file, written once |
| Renewable | No. Nothing but activation moves the anchor |
| After it runs out | The licence stops granting its tier. The Licence page says why |
The anchor is deliberately separate from the check-in grace window. If the two were folded together, a signed receipt would keep renewing the activation window, and one unactivated file dropped onto any number of servers would licence all of them for ever.
The window is for a licence that has never been activated anywhere. One that was activated before, on another server, is refused on the spot: it has had its window.
If the licence directory is read-only the anchor is held in memory instead. The window still ends, but a restart moves it, and both the log and the Licence page say so.
The hardware challenge
Your server derives a challenge from the strongest machine identity it can find, tried in order:
| Class | Source |
|---|---|
| S | The TPM endorsement key |
| A | The SMBIOS system UUID |
| B | Firmware serial numbers |
| C | The host's /etc/machine-id |
The class is part of the challenge string, so a challenge looks like A2-....
The ordering is by where the identity lives, not by how it looks. A virtual machine cloned from a
template carries the template's disk, and therefore its /etc/machine-id, while the
platform-held identities differ per clone. Putting the class in the string closes the obvious
downgrade: a machine that stops producing its class A identity produces a class C challenge, which
no longer matches the licence.
Moving the installation to different hardware, or a virtualisation change that alters the SMBIOS UUID or TPM, produces a different challenge. The licence stops matching and the server drops to unregistered until it is reactivated.
Plan a migration as a reactivation, not as a file copy.
Activating
Online, in one step
The console's Licence page can activate directly: it trades your licence key and email plus this server's own challenge for the signed file and the first check-in receipt in one round trip.
That has a useful side effect on day one: it proves the machine can actually reach the licence server it will be checking in with.
Through the portal
The manual flow still exists. Copy the server's hardware challenge from the Licence page, paste it
into the activation portal with your licence key, and download the resulting .lic.
Then install it by uploading it on the Licence page, or by dropping it into the licence directory:
/root/.local/share/odoocli/license/
Files there are loaded at startup, and re-scanned hourly, so a renewal takes effect without a restart. Invalid or expired files are reported as warnings rather than silently ignored.
# odoocli license agreementYour e-mail address is proof, not a lookup key
The address used at activation proves ownership of the licence. It is not how a licence is found or identified, and changing it is not how you move a licence to another server.
The recurring check-in
A node-locked licence on a build that knows its licence server is kept honest by a recurring check-in. A scheduled job reports to the licence server and receives a signed receipt.
| Cadence | Daily by default. The licence server may ask for anything from 1 to 168 hours |
| Grace window | 14 days, unless the licence carries its own |
| On failure | The server keeps working on the last receipt until the window ends, then drops to unregistered |
| On recovery | Full edition returns the moment one check-in succeeds |
The window is carried by the receipt, not by a local timestamp. A server that cannot renew its receipt for a full window of consecutive days drops to unregistered.
Disabling the check-in schedule disables the asked cadence with it, so the daily schedule is both the floor and the operator's off switch.
What the check-in reports
This is customer business data and you should know what leaves your server:
- The licence key and this installation's randomly generated install id
- The hardware challenge and the product version
- The number of running instances, not the number configured
- The host names your instances answer on
The instance count is the running one because that is the number the limit is about on both sides. The host names are what make duplication visible when hardware identity cannot: a challenge and an install id are both copyable, a customer's domain is not. Two servers reporting a name in common under one licence are the same deployment twice.
Clock changes
The receipt carries the licence server's own clock, and the highest value ever seen is kept.
A local clock reading earlier than that is surfaced as a clock-rollback warning. A regression beyond five minutes that stays uncorrected for an hour of running time is enforced, and the server runs unregistered until the clock is corrected. A rewound clock is otherwise the one way to stretch a stored receipt forever.
A small regression never enforces, because a snapshot restore looks identical to one.
Files in the licence directory
| File | Contents |
|---|---|
*.lic | The licence files themselves |
install-id | This installation's random id, generated once |
checkin.receipt | The latest signed receipt |
checkin-state.json | Last attempt, last success, last error, grace anchor, server-time mark |
Before the first receipt arrives, the grace window counts from an anchor written into
checkin-state.json. If that file cannot be written, typically because the licence directory is
mounted read-only, the anchor is held in memory instead: the window still ends, and both the log and
the Licence page say so. A restart moves the in-memory anchor.
The instance limit
A licence may carry its own maximum instance count, separate from the edition quota. It is enforced at instance start and restart, never on what is already running: the start that would exceed the limit is refused, running instances are untouched, and other starts inside the limit proceed.
If check-ins are failing but the receipt is still valid, the receipt's limit applies, since that is the licence server's latest signed word. With no usable receipt, the licence's own limit applies. Note that the fallback is the licence, never "unlimited": tampering with the clock cannot lift the limit.
A maximum concurrent user count, if the licence carries one, is displayed only. Neither this product nor the licence server enforces it.
The version ceiling
A licence may cover product versions up to a given major.minor and nothing newer. It is a ceiling,
not a pin: a licence covering 3.4 keeps running 3.0, 3.1 and 3.4, and refuses 3.5 and 4.0.
A licence that does not cover the build is not applied at all. The server falls to unregistered and the Licence page names both numbers rather than showing a generic refusal.
Licences issued before the ceiling existed carry none, which is no ceiling at all.
Offline licences
A licence issued for a machine with no route to the licence server never checks in, and never degrades for lack of a receipt.
In exchange it is only valid on attested hardware: the machine must present a class S identity whose TPM endorsement key is vouched for by a recognised hardware TPM manufacturer. Virtual TPMs are deliberately not on that list and are named as virtual in the refusal.
Removing a licence
Removing a licence from the Licence page deletes the files. Nothing in the API or the console can select a removed licence back, so keeping the files would only have looked like a safety net. Keep your own copy.
Related
- Editions
- Mail, for the expiry warning
- Troubleshooting