Updates

Elpan is a set of RPM packages from one repository. dnf upgrade moves the whole platform in one transaction, and the panel finishes its own upgrade afterwards: it migrates the database, restarts its workers and runs the one-time deploy tasks of the release, without you.

The repository

The installer adds /etc/yum.repos.d/elpan.repo, which points at https://repo.rekalogika.com/e10/, refreshes its metadata every hour and takes priority over the distribution's repositories. install.sh --repo-url <url> installs from a mirror instead and writes that URL into the file. See Install a server.

Upgrade

dnf upgrade

The elpan metapackage requires every component at least at the release that goes with it, so a plain dnf upgrade brings the whole set over together. Upgrade that way, not package by package. A component the metapackage only recommends is upgraded when it is installed and stays absent when it is not (Sizing profiles).

What a panel upgrade does

Step	What happens
Before any file is replaced	The package creates /run/elpan-panel-upgrading. While it exists, the panel answers every request, on every site, with 503 and Retry-After: 5, so nobody is served by the old process over the new files.
Right after the panel's files land	The web side (elpan-panel-web.service) restarts. Its start migrates the database and removes the flag before the new process takes the connections queued on the socket; the scheduler and the workers restart with it.
After every package in the transaction	elpan-panel-upgrade.service starts: it migrates again (a no-op by then), restarts the scheduler and every running worker, and runs deploy:run. The transaction never waits for it.

The package's own messages are in journalctl -t elpan-panel-rpm. If the transaction dies before the web side restarts, a transient timer removes the flag 15 minutes after the upgrade began and says so in its journal; a reboot clears it too (/run is a tmpfs).

systemctl status elpan-panel-upgrade.service
journalctl -u elpan-panel-upgrade.service

The unit ends inactive on success and failed when a migration or a task failed; the journal says which. Fix the cause and start it again: starting it is always safe, and every step is a no-op when there is nothing to do.

Units are replaced on upgrade

The panel's units ship in /usr/lib/systemd/system/ and every upgrade replaces them. Put a change in a drop-in under /etc/systemd/system/<unit>.d/ (systemctl edit <unit> creates one), which upgrades leave alone.

Deploy tasks

A release often needs work done on an existing server after its code is in place: refresh every forwarder, re-render a fragment for every website, republish DNS, backfill a value. A migration cannot do it (a migration changes the database only), and a runbook step is forgotten. So the panel has deploy tasks: classes in the code, run once per server by deploy:run, each recorded in a ledger.

State	Meaning	On the next run
pending	The task has never run here.	Runs.
done	Ran and succeeded.	Skipped.
baselined	The server was installed after the task existed, so there is nothing for it to repair.	Skipped.
marked	You recorded it as done by hand.	Skipped.
failed	Threw.	Runs again.
waiting	A precondition is not met, typically a system package the task needs is not installed yet. The tasks after it wait too.	Checked again.

A fresh install baselines every task that exists at the time, so it never runs old repairs. A waiting task is not a failure: deploy:run exits 0 and the upgrade unit ends inactive.

elpanctl deploy:status
elpanctl deploy:run
elpanctl deploy:run --dry-run
elpanctl deploy:run --task=<id>
elpanctl deploy:mark <id>
elpanctl deploy:mark <id> --pending

deploy:run refuses while a migration is pending, and while a worker or the scheduler started before the code on disk last changed: a stale worker drops the tasks' work silently. The upgrade unit restarts them at the right moment; by hand, restart every elpan-panel-worker@* and elpan-panel-async@* instance (systemctl restart elpan-panel-worker.service restarts the whole pool) and elpan-panel-scheduler.service first. --task runs one task whatever its state; every task is written to be safe to run again. deploy:mark records a task you did by hand, and --pending forgets its row so it runs again.

Supported upgrade paths

Any release upgrades to any later release of the same major version. A new major version is reached only from the last release of the previous one, which has run every task of its major; the first release of a major deletes the tasks of the previous one.

One-time migration commands

A server installed before a feature existed may lack a service the installer now creates. These commands create it once and skip when it is already there, so they are safe to run again.

Command	Creates
service:adminpanel:init [--prefix=admin]	The admin app at its own host under the server hostname (admin.<server hostname>). Needs the server's own DNS zone service.
service:adminer:init [--prefix=adminer]	Adminer at adminer.<server hostname>.
service:phpmyadmin:init [--prefix=phpmyadmin]	phpMyAdmin at phpmyadmin.<server hostname>.

server:refresh re-runs the server-wide sync (configuration fragments, the panel's services, keys); elpanctl says when it is needed.

The operating system

dnf upgrade also brings the distribution's updates. The telemetry agent reports the updates pending, the security updates among them, and whether a newer kernel is installed than the one running, so a central system can tell which servers wait for a reboot (Telemetry).