Engine settings

Engine-wide settings, reached from the user menu. Everything here belongs to the engine rather than to an account, so only an administrator sees it, and each field saves itself as it is changed.

Engine name

What this engine is called — in the browser's title, in alerts it sends, and at the registry when it is linked. Changing it here tells the registry too.

Engine ID

The engine's own identifier, fixed when it was installed. The registry knows this engine by it, so it is worth having to hand when asking for help.

Linking an engine to the registry makes it one of your engines there: it shows up with its status and capacity, and can use the registry's stacks, accounts and DNS. An engine works without it, and one that cannot reach the registry for a while carries on with what it has.

To link it, give the account on the registry that should own the engine, and its password. If the account has two-factor sign-in, the engine asks for the code from its authenticator app as well. The password is used for this once and not kept: the registry hands the engine a key of its own, which only the engine can read, and the engine proves itself with that from then on. The engine's own ID goes along, so linking again later - after unlinking, or if the key is lost - is recognised as the same engine.

A linked engine reports how it stands every minute or two: whether it is ready, its version, and what it has - nodes, cores, memory and storage. Nothing about its accounts goes with it. Renaming the engine here renames it at the registry too, and a new name or owner given to it at the registry is taken here.

The registry can also set this engine's own settings - its default quotas, its address ranges, I/O limits and the like - which its administrators keep there. A linked engine takes them as they change, with its next report: into its configuration, and those meant for the compute nodes into the node images. A setting the registry sets is shown here but cannot be changed here, as it would be set back at the next report. The registry never sets the engine's identity or its database's credentials.

A linked engine also keeps its accounts in step with the registry, every minute or two: an account added or changed on either side reaches the other, the most recent change winning. What travels is the account itself - its name, password, full name, email, phone and role. An account's quotas come from the registry only, where its administrators set them: a limit the registry does not set is the engine's default, and the quotas are shown on the Users tab but not changed there. Two-factor sign-in and the accounts one may switch to stay with each engine. Accounts this engine adds are managed by its owner at the registry. An account deleted at the registry is disabled here rather than removed, since removing it would take its VMs with it.

For billing, a linked engine reports every hour what each of its accounts has used in the month so far - vCPUs, memory, storage, node storage, backups, external IPs and traffic, as monthly averages - and, for the first few days of a month, the month just ended too, so its final figures arrive. The registry prices the figures and makes the invoices, for the engines its administrators mark as billable.

Unlink removes the engine from the registry and forgets the key. The engine keeps everything it has. If the registry cannot be reached, it offers to forget the link here only - the registry then goes on listing the engine until it is removed there.

Backups

A linked engine can back itself up to the registry once a day. A backup is the engine's own state: its database - accounts, VMs, images, networks and stacks as the engine knows them - its configuration, the compute nodes' default configuration, and the secret that signs sign-ins. It is not the VMs' disks, which the image backups are for.

Backups are encrypted on the engine before they leave it, with a key of the engine's own. To turn backups on, choose how the registry keeps that key:

With a passphrase (the default). The engine locks its key with a passphrase you choose, and the registry keeps the locked key, which it cannot open. The passphrase is kept nowhere, here or at the registry, so keep it somewhere safe: every restore asks for it, and without it no backup can be restored. Choosing a new one locks the same key again, so older backups still open with it.
Without one. The registry keeps the key itself, sealed with a key of its own, and hands it back for a restore. There is nothing to type or forget, but whoever runs the registry could open the backups.

The choice can be changed later, either way. The key stays the same, so older backups still open; but a registry that once held the key could have kept a copy of it. The registry keeps the newest few backups, and the engine keeps the last three itself, in /var/lib/keal/backups.

Back up now makes one straight away. Turn off stops the daily backups and keeps the ones made.

To restore, choose Restore… by a backup and give the passphrase, if the backups were made with one. Check it opens only opens the backup and changes nothing. Restore replaces the engine's database and configuration with the backup's. The engine keeps its own identity, database credentials, network interfaces and storage settings, since those belong to the machine. Everyone signs in again afterwards. Before it changes anything, the engine saves a copy of what it had in /var/lib/keal/backups.

An engine that replaces another one first links to the registry under the same owner, then gives the old engine's ID under Restore from another engine. It lists that engine's backups and restores one, with that engine's passphrase if it had one. It then backs itself up with the same key, kept the same way, so the same passphrase keeps working.

Master images

Whether this engine downloads master images from the registry as it needs them. With every master it fetches the whole catalogue instead, which is worth doing on an engine that has to work without the registry later, and is a great deal of disk.

With neither, the engine downloads only what is asked for: a stack picked under From the registry in Install stack, with Download. Whichever way, an image a stack is built on comes with it when it is not here yet, and the stack can be installed once all of them are. Downloads happen in the background, one at a time; the Images tab shows how far each has got.

Mapped IP range

The addresses the engine hands out to networks that map a public IP. A mapped network gives its VM a private address and maps one of these onto it, so the range has to be addresses this engine may actually answer for.

Proxied IP range

The addresses used by the management proxy — the path a stack's own management interface is reached through. The gateway is the address those proxied networks route out by.

Disable SNAT

Whether traffic leaving a private network is rewritten to come from the engine. With source NAT on, a VM on a private network can reach the outside world; with it off, it cannot, which is sometimes exactly what a private network is for.

Storage

Which devices hold images and backups. The engine's images live on the first, and whatever the backup schedules produce on the second. Changing either is done on the engine itself rather than here.

Default I/O limits

How much disk throughput a VM gets unless its node says otherwise, in MB per second and in operations per second, for reads and writes separately. Limits only apply while Enforce these limits is on; zero means no limit. The figures are written to every node's configuration, and the nodes are reloaded as soon as they change.

Audit log

Where the audit log goes besides the Audit tab, and how long the engine keeps it.

Also send it to syslog sends each row on, as it is written: local for this engine's own syslog, or udp://host:port or tcp://host:port for a log server (port 514 when none is given). Each row is one line of JSON tagged keal-audit, with facility authpriv: severity info for a change that went through and warning for one that did not. A console or terminal session is sent twice, when it opens and when it closes. Empty sends nothing.

Keep it for is how many days the engine keeps rows itself, 400 unless set; older ones are dropped once a day. What went to syslog is the log server's to keep.

Let administrators clear the audit log gives the Audit tab a Clear button, and allows keal audit clear. It is off unless switched on: a log that can be emptied is a weaker record of who did what.

Password hashing

Passwords are kept as salted PBKDF2-SHA256 hashes, with 310,000 rounds unless PASSWORD_ITERATIONS in the engine's config.cfg says otherwise (at least 100,000); it is not offered here. More rounds make each sign-in check slower, and each guess at a password just as much slower. New passwords get the count at once, and an existing password gets it the next time its account signs in. Lowering the count leaves hashes that already have more as they are.