Skip to main content
The appliance is configured once, at its first boot. This page lists every setting it reads there, and the ways to supply them: the vCenter deploy wizard, keys set by automation, or a complete appliance.yaml. For a walk through the wizard, see Deploy the appliance.

​
Where the configuration comes from

Every way ends in one file, /etc/celum-appliance/appliance.yaml. At boot the appliance resolves its configuration in this order, and the first source that exists wins:
  1. /etc/celum-appliance/appliance.yaml, if the file exists. The first boot writes it from the sources below, so from then on the file is the configuration. Later changes to the wizard’s answers in vCenter are ignored, and an edit you make to the file is never overwritten by them.
  2. The OVF properties that vCenter hands to the VM at power-on (guestinfo.ovfEnv): the answers from the deploy wizard, or from a PropertyMapping in a scripted deploy. Two things are applied over them:
    • guestinfo.celum.<key> values in the VM’s advanced settings. A non-empty one wins over the wizard’s answer for the same key.
    • celum.appliance_yaml, if set, replaces everything else: the appliance reads that whole document and ignores every other key.
To re-read the OVF properties on purpose, after the first boot, run celum-appliance bootstrap --from-ovf. To see the configuration the appliance resolved, and any warnings about it, run celum-appliance config.
SSH access is applied first. The SSH keys and the root password are read and applied before anything else, so a configuration the appliance refuses still lets you in to fix it. Edit /etc/celum-appliance/appliance.yaml and run celum-appliance bootstrap again: it picks up where it stopped.

​
What is injected, and what is not

On vSphere the appliance receives only what is listed above: OVF properties and guestinfo.celum.<key> values. The deploy injects no cloud-init user-data, and no certificates or secret-store material beyond the keys in the table below. The image does carry cloud-init, which reads a NoCloud seed. That is the way to configure the appliance’s qcow2 disk on Proxmox or libvirt: a write_files entry that writes /etc/celum-appliance/appliance.yaml. The appliance generates its own secrets at the first boot:
  • OpenBao’s unseal key, root token and recovery key;
  • the CA, unless you supply a signing CA;
  • Authentik’s secret key, and every service’s passwords, tokens and OIDC client secrets;
  • Omni’s etcd encryption key.
They are kept in /etc/celum-appliance/secrets. With escrow recipients (or SSH keys) set, the ones a restore cannot do without are also encrypted to those recipients and copied to the backup bucket.
What you type into the deploy stays in vCenter. The OVF properties and guestinfo values, including passwords, keys and S3 secrets, remain in the VM’s settings after the first boot. Anyone who can read the VM’s configuration in vCenter, or run commands in the guest, can read them. Restrict who can read the VM’s configuration. If you typed passwords into the deploy rather than leaving them to be generated, change them after the first boot.

​
Settings

All keys are optional except the two marked *. A blank value means the default. In the wizard, sections appear in the order below.
Fields that carry a file take its base64: celum.tls_cert, celum.tls_key, celum.tls_ca_cert, celum.tls_ca_key and celum.appliance_yaml. A raw PEM or YAML is refused at first boot, because a one-line field loses its line breaks. Linux: base64 -w0 FILE. macOS: base64 -i FILE. PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes((Resolve-Path FILE))).Lists are comma-separated: SSH keys, DNS servers, search domains, extra DNS zones, escrow recipients, and ACME credentials (NAME=value,NAME=value).

​
Identity

​
Networking

​
TLS

​
Components

​
Updates

​
Advanced

​
Not in the wizard

These keys are not shown in the wizard, on purpose. You can set them through automation, as a guestinfo.celum.<key> value or inside celum.appliance_yaml.

​
Configure it from automation

​
govc

Export the spec, set a Value for each key you need under PropertyMapping, and import the OVA without powering it on:
A checkbox takes True or False. vCenter refuses true and fails the whole import over it. A file goes in as its base64:
vCenter drops a PropertyMapping value for a key the wizard hides, without an error. Set those as guestinfo values instead, before the first power-on, because the appliance reads its configuration only once:

​
A complete appliance.yaml

To keep the whole configuration in one versioned document, put it in celum.appliance_yaml as base64. Every other key is then ignored, so the document must carry everything, including domain and admin. A key the appliance does not know is a fatal error, not a no-op. The simplest way to get a valid document is to deploy one appliance from the wizard and run celum-appliance config on it.

​
Validation at first boot

The appliance checks its configuration before it starts anything. It stops with a message naming the key when:
  • domain or admin.email is missing or malformed;
  • a field that carries a file is not base64, or does not decode to a PEM file;
  • a byo certificate does not cover every name the appliance serves, or the signing CA and its key do not match;
  • an address is given without a gateway;
  • Authentik is off while IAM is on;
  • the Harbor project name is not one Harbor accepts, the Omni account ID is not a UUID, or the administrator group is Authentik’s own authentik Admins.
Some combinations are corrected and reported as a warning instead. acme-dns01 switches Omni off, because Omni serves its own certificate and ACME certificates stay inside the appliance’s web proxy. celum-appliance config lists every such warning.