Author Topic: cwpsrv 1.24.0-2 overwrites cwpsrv.conf — service fails to start (missing hostnam  (Read 120 times)

0 Members and 2 Guests are viewing this topic.

Offline
*
Hi,

After the cwpsrv 1.24.0-2 package was installed on 28 July 2026, the cwpsrv
service failed to start on two of my servers, making the panel completely
unreachable (ports 2030/2031/2082/2083 down, "Service Unavailable" on
cpanel.<domain>).

Environment:
- AlmaLinux 8.10 (kernel 4.18.0-553.146.1.el8_10.x86_64)
- cwpsrv-1.24.0-2.x86_64 (installed 2026-07-28 03:42)
- Two independent servers, different hostnames and different domains

Error:

  # systemctl status cwpsrv
  Active: activating (auto-restart) (Result: exit-code)
  Process: ExecStartPre=/usr/local/cwpsrv/bin/cwpsrv -t (code=exited, status=1/FAILURE)

  # /usr/local/cwpsrv/bin/cwpsrv -t
  cwpsrv: [emerg] cannot load certificate "/etc/pki/tls/certs/hostname.crt":
  BIO_new_file() failed (SSL: ... No such file or directory ...)
  cwpsrv: configuration file /usr/local/cwpsrv/conf/cwpsrv.conf test failed

On the second server the certificate files issued by AutoSSL were present and
valid:

  /etc/pki/tls/certs/hostname.cert     (2026-07-21 12:20)
  /etc/pki/tls/certs/hostname.bundle   (2026-07-21 12:20)
  /etc/pki/tls/private/hostname.key    (2026-07-21 12:20)

but /usr/local/cwpsrv/conf/cwpsrv.conf was rewritten by the update
(timestamp 2026-07-28 03:42:20) and points to hostname.crt, which does not
exist on the system.

Main issue: no .rpmsave or .rpmnew file was created, so the previous
configuration was overwritten with no backup. It looks like the conf files
are not marked %config(noreplace) in the spec file. Any local customisation
in /usr/local/cwpsrv/conf/ is silently lost on update, and the service then
refuses to start.

Workaround that restored the service:

  cat /etc/pki/tls/certs/hostname.cert /etc/pki/tls/certs/hostname.bundle \
      > /etc/pki/tls/certs/hostname.crt
  chmod 644 /etc/pki/tls/certs/hostname.crt
  /usr/local/cwpsrv/bin/cwpsrv -t && systemctl start cwpsrv

Questions:
1. Could the conf files be marked %config(noreplace), or at least backed up
   as .rpmsave before being replaced?
2. Is hostname.cert vs hostname.crt an intentional naming change? If so,
   could the update create the missing file or a symlink instead of leaving
   a broken configuration?

Has anyone else hit this after 1.24.0-2? Thanks.


Offline
*****
Yes, the latest CWP update overwrites /usr/local/cwpsrv/conf/cwpsrv.conf. Thus it borked my custom port assignment. A quick SSH session in restored admin panel access on the front end.

Offline
*
Confirming this on another server: AlmaLinux 8.10, cwpsrv-1.24.0-2 installed
2026-07-28 03:37. Same failure, but it stayed latent until a reboot the next
morning — worth adding, because others may only hit this weeks from now.

Two findings:

1) hostname.crt is a dead artifact — hostname.bundle is canonical.

The only script that writes hostname.crt is /scripts/generate_hostname_ssl
(line 137), and that runs only on install or hostname change. The renewal
chain is:

  /etc/cron.daily/cwp_acme.sh -> acme.sh -> /scripts/hostname_ssl_restart_services

and that works exclusively with hostname.bundle (deriving hostname.pem from it
for postfix/dovecot/pure-ftpd). So after any AutoSSL renewal, .key/.cert/.bundle
are fresh while .crt is stale — key/cert mismatch at the next cwpsrv start.

Note that CWP's own generate_hostname_ssl (lines 171-184) sets all four cwpsrv
confs to hostname.bundle, and conf.d/api.conf already ships that way. The RPM
templates contradict CWP's own script.

2) The failure is silent until reboot.

hostname_ssl_restart_services runs "service cwpsrv reload". With a broken config
the reload fails, the exit code is ignored, and the running master keeps serving
the old certificate from memory. On my server the cert renewed on 11 July and
the panel kept working until a kernel update rebooted the box on 29 July —
then ERR_CONNECTION_REFUSED, restart counter at 602.

On the workarounds circulating in the other thread: symlinking or copying
hostname.cert gives you the leaf only, without the intermediate chain. Browsers
often mask this by caching intermediates, but API clients and curl will fail.
Use the bundle instead:

  cp -a /etc/pki/tls/certs/hostname.bundle /etc/pki/tls/certs/hostname.crt

Or point the confs at hostname.bundle directly:

  sed -i 's#/etc/pki/tls/certs/hostname\.crt#/etc/pki/tls/certs/hostname.bundle#g' \
    /usr/local/cwpsrv/conf/cwpsrv.conf \
    /usr/local/cwpsrv/conf.d/{user-api,users,webmail}.conf
  /usr/local/cwpsrv/bin/cwpsrv -t && systemctl reload cwpsrv

Always verify before starting:

  openssl rsa  -noout -modulus -in /etc/pki/tls/private/hostname.key  | openssl md5
  openssl x509 -noout -modulus -in /etc/pki/tls/certs/hostname.bundle | openssl md5

And a warning: do NOT run generate_hostname_ssl as a fix. It replaces a valid
Let's Encrypt hostname certificate with a CWP self-signed one and restarts
postfix, dovecot, cwpsrv, httpd, nginx and pure-ftpd in sequence.

Requests for CWP:
- Ship the cwpsrv conf templates pointing to hostname.bundle, matching
  generate_hostname_ssl.
- Mark the conf files %config(noreplace), or at minimum write .rpmsave.
- Have hostname_ssl_restart_services check the exit code of "cwpsrv -t" and
  log a failure, instead of leaving a reload that silently did nothing.