Server Maintenance and Updates

CorePanel has no update daemon, no nightly job and no agent phoning home. The mechanism that keeps a server current is the one already on the box:

dnf update

That is not a simplification for the docs — it is the design. Everything CorePanel needs to correct on a running server travels in its packages, so the moment you update them the host converges. This page says exactly what that covers, so you know what an update will and will not do before you run one.

What an update converges

Area	What arrives with the packages
PHP stack	The set of PHP versions and extensions CorePanel supports, declared by the corepanel-php package
SELinux policy	The corepanel_app_t, corepanel_cron_t and corepanel_phpfpm modules, shipped compiled and reloaded on every upgrade
PHP-FPM pools	The inert placeholder pool that replaces the stock Remi www pool, plus the SELinux booleans and labels PHP needs to serve from /home
Runtime directories	The tmpfiles.d entries that recreate /run/php-fpm on every boot

The important consequence is for servers that have been running a while. Earlier CorePanel releases configured some of this from the installer, which runs once when the server is built and never again — so a correction made later reached only newly built servers. That is no longer true of anything in the table above.

What an update will never do

These are guarantees, not current behaviour that might change:

• It never removes a PHP version. Accounts are pinned to a version and the webmail runs on PHP 8.4. Versions are only ever added.
• It never rewrites configuration you edited. main.cf, dovecot.conf, your firewall rules and your DNS zones are yours. CorePanel only rewrites files it owns and marks as its own.
• It never touches a PHP version CorePanel does not ship. If you install a Remi PHP of your own, its pool and its service are left exactly as you set them. CorePanel manages only the versions listed by rpm -q --requires corepanel-php.
• It never reboots, never prompts and never asks for a password. Anything needing a decision — enabling disk quotas, for instance — stays a deliberate action you take.
• It never restarts a service that did not need it. PHP-FPM runs every account’s pool in one process per version, so a needless restart would drop live requests. A version is restarted only when its own configuration actually changed.

The PHP stack is its own package

The PHP versions live in a package called corepanel-php. You can see exactly what it pulls in:

rpm -q --requires corepanel-php

CorePanel recommends this package rather than requiring it. That is deliberate: the PHP packages come from the Remi repository, and if Remi has not yet published a newly added version for your EL release, that must not stop the panel itself from updating. The trade-off is visible rather than silent — you see a package transaction fail, instead of a PHP version quietly arriving unconfigured.

The webmail is the one exception: corepanel-roundcube requires PHP 8.4 outright, because it will not run without it.

Extensions outside that set — the ionCube Loader, for instance, which encoded software like WHMCS needs — are installed separately and are not touched by updates. See PHP Extensions and ionCube.

Removing it behaves differently on EL8

On AlmaLinux/Rocky 9 and 10, if you remove corepanel-php it stays removed, and dnf install corepanel-php brings it back. On EL8, dnf re-adds it the next time it updates the corepanel package. This is dnf’s own handling of weak dependencies, not something CorePanel controls.

Repairing a host by hand

There is no special repair command to learn. Because all of this lives in package scriptlets, reinstalling the package re-runs them:

# Re-apply the PHP stack configuration: pools, SELinux booleans and labels
dnf reinstall corepanel-php

# Re-load the SELinux policy modules and relabel the application trees
dnf reinstall corepanel corepanel-sys

Both are safe to run on a live server. They re-apply what is already correct without touching it, and restart only what genuinely changed.

To see what a package’s scriptlet did, read the transaction output, or afterwards:

dnf history          # find the transaction
dnf history info <id>

Checking the SELinux policy is loaded

CorePanel confines account applications, account cron jobs and PHP-FPM’s access to MariaDB with its own SELinux modules. A missing module is silent — nothing fails, the confinement simply is not there — so it is worth knowing how to check:

semodule -l | grep corepanel

You should see corepanel_app, corepanel_cron and corepanel_phpfpm. If one is missing, dnf reinstall corepanel corepanel-sys loads it.

Upgrading the whole server

CorePanel does not restrict dnf update, and there is nothing to stop first. Standard practice applies: update at a quiet hour, and expect PHP-FPM to restart for any version whose configuration changed in that release.