Operator reference

Source-checked guidance for the current console and native appliance, including operational limits.

1. Platform and resources

Cenovel keeps inventory, topology, device observations, work records, and
E-Rate records on the customer's own appliance or VM. The console is intended
for desktop browsers. The responsive marketing website is not the console.

The native installer checks for Debian 13 amd64. Its supplied configuration
uses /var/lib/mysql for the database, /var/lib/cenovel for application data,
and /var/backups/cenovel for local backup staging. With the supplied native
configuration, first boot requires separate mounts for the database and
application data. Releases are stored under /opt/cenovel.

Plan compute, storage, and retention around the actual workload. No measured
production device-capacity guarantee is published here. The recorded vSphere
acceptance programme has not been executed against real hardware.

Staff reach the console over HTTPS. Device reads use SSH with Device CLI
profiles, or SNMPv3 authPriv where configured. Permit the ports configured for
those devices and the optional external services the district chooses to use.

2. Native installation and first checks

Confirm release media, the trusted release public key, VM resources, data
mounts, DNS, and TLS with the deployment owner. The native installer accepts
a signed .cenovel release bundle; it verifies the bundle before staging the
release. These instructions do not promise downloadable OVA media.

Native first boot provisions protected credentials and the local recovery
passphrase. Save the passphrase in the district password manager before
acknowledging it:

    cenovelctl recovery show
    cenovelctl recovery acknowledge

Acknowledge removes the display copy. Native console deployment settings,
including its hostname and public URL, are in /etc/cenovel/appliance.conf.
Validate changes and restart the affected services:

    cenovelctl config check
    systemctl restart caddy cenovel-api cenovel-worker

The supplied Caddy configuration uses an internal CA. Establish trust on
staff workstations or provision the district's certificate. Then check:

    cenovelctl status
    cenovelctl health
    cenovelctl diagnose

3. Analytics and access scope

Analytics uses one query engine across Answers, Explore, and Saved. Answers
presents defined questions; Explore lets users filter, group, and inspect
records; Saved keeps view definitions. The older Analytics routes have
successors and should not be used as navigation instructions.

Only Administrator EX can share or schedule views. The server checks page
permissions and scope when answering a query. Users without cross-department
rights cannot request another department's scope. For department-scoped
datasets, current code includes their department and unassigned records;
registers without an owning department follow their page permissions.

4. Configuration, device access, and sign-in

Application settings are managed in the console's Settings. File-based
secrets are provisioned separately: the repository setup uses secrets/;
the native appliance uses protected files under /etc/cenovel/credentials.
Native deployment settings are validated in /etc/cenovel/appliance.conf.
Some settings, including the listener port, take effect after a restart.

As Administrator EX, open Governance > Monitoring > Configuration > Access
for device credentials and site collectors. The Schedule section controls
how often devices are read. Monitoring > Networks holds the configured
networks, and Found devices holds discovery results for review.

Cenovel reads switches over SSH with Device CLI profiles. SNMPv3 authPriv
is also available where configured; profiles require SHA-2 authentication
and AES privacy. SSH polling does not require SNMP to be enabled. Device
reads depend on configured credentials, allowed networks, and trust checks.
A site collector provides a path to configured management networks; use the
enrollment and configuration procedure for the installed collector release.

Microsoft Entra ID sign-in uses authorization code with PKCE. Configure the
tenant, client, secret, redirect URI, and group mappings. Review individual
role assignments as well as defaults; an existing assignment can affect the
resolved tier. The local recovery account provides a separate sign-in path.

5. Observations, health, and diagnostics

A device that cannot be reached by a read is described as "not answering
Cenovel". A rejected sign-in or untrusted key is distinguished from no answer.

When attempted reads fail together and nothing has answered recently,
Cenovel raises "Cenovel can't reach the management network". While that
condition holds, device reachability outages are held: no new one opens,
existing ones are neither confirmed nor cleared, and their clocks stop.

Native appliance checks:

    cenovelctl status
    cenovelctl diagnose
    cenovelctl health
    cenovelctl logs api --lines 200
    cenovelctl logs worker --follow
    cenovelctl support-bundle --json

Status and diagnose support --json. Diagnose exits non-zero when its health
checks fail. The support bundle contains redacted diagnostics; review it
before sharing. The console also sends performance measurements to its own
local API. These measurements support local diagnostics.

/livez answers when the process responds. /readyz checks lifecycle readiness
and a database query; when daily application backups are enabled, the backup
subsystem must be available. Failures return 503. /healthz is an alias.
Readiness does not prove an off-box backup or a successful restore.

/metrics returns Prometheus-format metrics to a loopback request or a request
with the configured bearer token. Other requests receive 404.

6. Native backup and restore

Native backup artifacts are encrypted and authenticated. The set includes the
database, supported application stores, configuration, and release identity.
A COMPLETE marker is written after finalization. Keep the backup keyring and
required credentials separately; local staging alone is not an off-box copy.

    cenovelctl backup create
    cenovelctl backup list
    cenovelctl backup verify NAME

Replace NAME with a set returned by the list command. The native timer is
scheduled for 01:30 with up to 20 minutes of randomized delay. Retention and
rsync-over-SSH or SFTP delivery are configured in
/etc/cenovel/cenovel-native.conf. Off-box copies are verified against file digests; SFTP copies are read back for that check.

    cenovelctl restore preflight NAME
    cenovelctl restore drill

The drill restores to scratch resources, starts a scratch console, and checks
readiness. Review its result. A production recovery still needs to be
exercised in the district's deployment environment.

    cenovelctl restore apply NAME

Native restore requires the matching installed release and schema epoch.
It stops application services, takes a safety snapshot, and replaces the live
database and stores. A failure after the safety snapshot can leave services
stopped. Review the receipt and resolve the failure before retrying; do not
start services by hand in the middle of recovery.

7. Native upgrade and rollback

Plan a maintenance window. Candidate checks run before the native updater
stops the API and worker for migration and release switching. This is not a
zero-downtime upgrade.

    cenovelctl backup create
    cenovelctl release verify <bundle>
    cenovelctl upgrade preflight <bundle>
    cenovelctl upgrade apply <bundle>
    cenovelctl upgrade status

Replace <bundle> with the signed release bundle. Apply runs candidate checks,
stops services, migrates, starts the API and worker, and checks readiness.
Inspect status and resolve any failed stage before declaring completion.

    cenovelctl rollback decide

A previous release is kept as a rollback target. Compatibility checks can
refuse rollback when it cannot read the current schema. Use the compatible
pre-upgrade backup and restore procedure when required.

8. API reference

The API supports /api/v1/... and the /api/... alias. /api/docs renders the
installed API reference; /api/openapi.json returns its OpenAPI schema.
Protected routes require a session or API token and their applicable
permissions. Authentication endpoints and health probes have their own rules.

    Authorization: Bearer <your-api-token>

Routes with declared contracts are marked x-cenovel-contract: documented;
other routes are marked undocumented. Consult the installed schema for
parameters, response fields, and permissions. Unsupported path versions or
Accept-Version headers return 406 with the supported versions.

9. Personal-data erasure limits

The person-erasure API requires two different Administrator EX identities.
It replaces supported identity references, clears supported profile fields,
and ends matching sessions in a transaction. It does not erase every copy.
The plan reports records it cannot change, including protected audit entries,
sealed audit files, and columns that cannot hold the replacement reference.
Free-text notes are not searched. Earlier backups can still contain the data;
restoring one can bring that data back.

Review the plan and its limitations before approval. The routes are:

    GET  /api/identity/erasures
    POST /api/identity/erasures
    POST /api/identity/erasures/<id>/approve
    POST /api/identity/erasures/<id>/withdraw

The create request identifies the person's principal_id and gives a reason.
Approval requires another Administrator EX. Withdrawing a request also
requires a different decision-maker from its requester.

10. Deployment boundaries

Cenovel runs on customer-managed infrastructure. This website does not offer
a SaaS or cloud-hosted version. The console is intended for desktop browsers.
Capacity, installation media, and production acceptance must be confirmed for
the deployment. Optional identity and notification services need connectivity
to their configured destinations.