ISPConfig panel freeze - not fixed by reboot or ispconfig_update.sh --force

I need help !

While creating new websites, my ISPConfig panel suddenly froze. Following a reboot, access to panel fails with PR_END_OF_FILE_ERROR.
Inspection reveals that apache2 service has not restarted.

ispconfig_update.sh --force runs without incident (ISPConfig SSL recreated) until the very end where it reports:

Code:

Updating Crontab
Restarting services ...
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.
Update finished.

The panel remains not accessible after that (same error, Apache not running - it resists another reboot).
I have no idea what triggered the incident.
I can't guess at the root cause or fix from "systemctl status apache2.service" output (att. 1) or apache error log (att. 2).
What should I do ?

 

Please start with
https://forum.howtoforge.com/threads/please-read-before-posting.58408/
My guess is the last website you added breaks Apache. You could try disabling that website and restart apache.

 

Thanks. I have run the indicated script. Other than apache2.service not loading, the output (attached) does not seem to report other anomalies that I can see.

As to disabling the 1 website and 2 subdomains that I was creating using the panel when Apache walked out on me, I can't very well do that using the panel since Apache is not running. That means tinkering manually with the Apache configuration files, that are normally managed by ISPConfig, correct ? I do not really know where to look, nor if it is safe to make any changes there. Please advise.

Note: since the system broke when I was using the panel and not doing (or having done) anything special otherwise, this probably means that there is a bug somewhere, right ?

 

Thx. It worked. I actually isolated the offending website and was able to keep the others. The panel works and can see them.
Can I recreate the website using the panel despite it still being present in the sites-available directory ? Or should I purge that, too ?

BTW, I didn't do any of those 2 things. Never. Just FYI

And I don't even know how to do this. Could I have done it inadvertently ?

 

Oh ! OK simple. Thx

 

This is not working.

After doing the disable-save-enable-save cycle, the panel gets inop : none of the menu items work (including logout) and the panel cannot show any website, I am basically stuck on the website page. Any attempt to get the panel to show a website, or clicking any menu item, results in a short wait (with the clock-like icon turning) and then you are back to the website menu, still inop

 

And after a reboot, Apache is dead again

 

Yes, config test is enabled.
And, yes, I also deleted the offending website. Apache is running again (and did not try to re-create the problem website, for now).
But the panel fails at enabling Let's Encrypt SSL, for any website. The ssl directory remains empty after a "save" with Let's Encrypt generation enabled. The panel initially reports it OK, then reverts to show SSL not enabled (true).
Something is seriously borken, I guess

 

You should read the "Read before posting" article, carefully, and examine all checks the script makes. Then you can fix all the issues in one go.
For example, the common issues script reports in Version Check, the PHP versions, which are not correct for Debian 12. See the Read before posting article.

 

Yes, sorry, I too quickly held the previous incident responsible for the SSL apparent change in behavior. My bad. I fixed it by making sure I had DNS straightened out for all domains/subdomains of the site and it worked.

Now another different problem is emerging. After having successfuly created The Let's Encrypt certificate for a website, call it website.domain.com which has an alias: alias.domain.com, I cannot access these websites because an incorrect certificate is being fed to my browser. I have checked that the ssl direcory in the website.domain.com root does contains the appropriate certificates .crt and .key : they are here, and they are valid for both website.domain.com and alias.domain.com. The panel also reports that the Let's Encrypt certificates are OK : both boxes are ticked.

Nevertheless accessing either website.domain.com or alias.domain.com, I am fed a bogus certificate, that contains neither of these addresses. What could be wrong ?

 

That's not it, till. All my websites have Let'sEncrypt certificates. Checked 2 ways : the panel 's Let's Encrypt boxes are checked, and the ssl directory in each website's root checks out, with certificates that show domains and subdomains included.

I checked the latter via openssl x509

Code:

for i in $*
do
    printf "%15s : " "$i "
    folder="/var/www/$i"
    if [[  -L "$folder" && -d "$folder/ssl" ]]; then
        aliases=`openssl x509 -in $folder/ssl/*.crt -text -noout -ext subjectAltName | tail -1 -`
        aliases=`echo $aliases | sed -e 's/DNS://g' -e 's/,//g'`
        for j in $aliases
        do
            printf "%s " $j
        done
        echo
    else
        echo ERROR, domain $i not found or broken
    fi
done

 

I read the chapter carefully and, as far as I can see, there are no possibilities mentioned (other than attempting to access to a website without certificate) that could explain receiving the wrong certificate. I may be wrong but I have not been able to find it.

The problem has resisted an ISPConfig update.

Attempting the browser connection (that results in receiving the wrong certificate) does not generate an error in any of the apache2 logs, nor in the target website's log.

For that matter, the certificate received doe not match any of the certificates present in web*/ssl directories: all of these have multiple domain aliases, and the certificate received only has a top-level one (admittedly one of my domains, but not the domain requested, hence the error)

I am attaching the htf report for what it's worth, but I could not detect any significant anomaly in there either

 

All my domains are listening on *, so I discarded that scenario out of hand. Sorry for not having reported it.

But, yes, good guess, I do have one site-available with a .err ending (along with one of the same site without the .err ending). Both files have the same timestamp, but the .err is longer. A difff shows that the .err file has the <VirtualHost *:443> section in it, when the regular file only has the <VirtualHost *:80>.

I am guessing this explains the problem. But how to fix ?