3.0.2
Two faults found by watching a server that would not update, and one certificate that should never have been in the repository.
The update that ran forever​
A panel reported 2.1.17 while running a 3.0.1 binary, and every update it was told to run ended in the same place: the log stopped mid-sentence after the last migration that existed, and nothing else ever happened.
The version file is written at the very last step of an update, deliberately — it is the only record of what a server runs, so writing it before the work is what turns a failed update into a server that believes it is current. Anything that stops the run before that line leaves new binaries, migrations that have run, and a version number from months ago. The panel then offers the same update again, and it stops in the same place, forever.
The panel capped a full update at ten minutes. Less than the work beneath it: each version-specific migration is allowed 300 seconds of its own, and a release that rebuilds the webmail spends several minutes on that before the first migration starts. Nothing read the exit status either, so a truncated run left no trace anywhere.
An update that begins under an older updater runs that older updater to the
end. Even after it has refreshed the panel's own CLI. bash reads a script
incrementally from the inode it opened, and replacing the file unlinks that
inode rather than changing it, so the refresh cannot affect the run performing
it — a fix shipped in the CLI applies from the next update, never the one that
installs it. That is how the server was found four minutes into a fetch of
releases/2.1.797/UPDATE.sh: 3.0.1's predecessor walking every version number
between the installed version and the target, 998,970 of them, with 3.0.1's
replacement for it sitting on disk unread.
The updater no longer runs out of a directory it is about to replace.
Security​
-
One private key was shipped to every server. The fallback certificate the vhost templates named came from a pair committed to the configuration repository: self-signed,
CN=openpanel.com, expired February 2026, and with its private key in the repository. It was not a secret in any useful sense — every clone had it, and every server that presented it presented a certificate whose key was shared with every other server and with anyone who had ever pulled the repo.Ten templates now name the per-host certificate the installer generates, with the machine's own name in the subject and the SAN,
0600on the key, and regeneration a month before expiry. The update creates it if it is missing, repoints any vhost still naming the old path, and deletes the shared pair wherever it landed.
Notes​
A server already stuck between two versions arrives here still mismatched. The update says so, and says which command finishes it, rather than stamping over the gap — the gap is exactly the set of migrations that may not have run, and recording it as done would skip them for good.