Pre-upgrade 3.1 > 3.2 & Ubuntu 18.04 > 20.04 Questions

I'm planning an upgrade of my server using this tutorial, but I think I need answers to the following questions before I can try:

1. Am I correct in thinking that I need to upgrade ISPConfig from 3.1 to 3.2 BEFORE I upgrade the OS from Ubuntu 18.04 LTS to 20.04 LTS?
2. Regarding my Let's Encrypt configuration, I previously followed this tutorial (to the letter I think). The upgrade tutorial has the following note:
   
   Question is, which option would be the safest option (lease chance of customer disruption) for me?
3. For this question:
   Is there any advantage in having ISPConfig replace the existing Let's encrypt certificate?

Thanks in advance.

 

1. Either or will be fine to me but I think the former should work best.
2. Kindly undo / remove all that settings before you proceed as that tutorial is mainly suitable for 3.1 but for 3.2, the use of default feature is preferred and will be easier to maintain.
3. Do the above first and only then let ISPConfig create new certs so that ISPConfig 3.2 will be able to maintain and do the certs renewal automatically in the future.

 

All understood sir. Many thanks for the fast reply.

 

Thanks ThOm.
So should ISPConfig 3.1 still run properly after upgrading to Ubuntu 20.04 or does the ISPConfig upgrade need to be done immediately afterwards in order to get back into production?

 

He just means after everything the last part should be running ISPConfig update again, which always is the way.

So if you update ISPConfig 3.1 to 3.2, then Ubuntu 18.04 to 20.04, run ISPConfig update again. Otherwise, if you update Ubuntu first, then you only need to run ISPConfig update once thereafter.

 

Update ISPConfig to the latest version, upgrade the OS to 20.04, update ISPConfig with reconfigure services and set the new paths for php under server-config/web

 

Okay, ISPConfig first then the OS seems to be the general consensus here. We'll do that.

Good that you mentioned that. We haven't seen anything about this so far in the update procedure. Is there any more information on this, so we can prepare please?

 

So, we went ahead tonight and performed an upgrade from 3.1 to 3.2 and from 18.04 to 20.04.
It failed on multiple counts, so we reverted to a saved snapshot from before we started. This is what happened:

Procedure Followed:

Error 1 (during ISPConfig upgrade)

Unfortunately, we failed to grab the two versions of status reports although we did see them and they didn't seem to give any information regarding why it failed.

Error 2 (during OS Upgrade)

It didn't get hung up over this, except it repeated this message about 8 times before moving on without intervention, but I include it here, since maybe it's related to the later errors?

Error 3 (while it's upgrading PHPMyAdmin)

We wondered if this might be some kind of password error, but we had kept perfect records of existing passwords (server root, mysql root and the phpmyadmin administrative password and username), that it just doesn't seem plausible, so we're wondering whether we should have chosen TCP socket type instead of Unix socket when it asked? We assumed that since it's all within the same server, no need for TCP?

Error 4
Roundcube needed a database upgrade and this also failed, due to not being able to connect to mysql. I don't know whether this was due to authentication errors or actual connection?

Edited Config Files, etc
We were frequently informed that our config files had been updated and were different to the package maintainers default copy. I think in all occasions, except one, we chose to go with our existing. The one were we chose otherwise was /etc/sysctl.conf (from memory). We compared those and found two extra lines in ours (probably from our hosting provider). One relating to "kernel panics" and the other seemingly enabling IPV6. We went with the maintainers after making a backup of ours.

Moving forwards...
We might have another go at it tomorrow night after checking our database passwords before we start and we'll try to gather more details on the Apache failure (assuming it reoccurs).

We're using HHVM as the PHP Handler and I'm wondering if perhaps that's uncommon and may causing the failure. Might switch this to Fast-CGI before we start next time.

Any thoughts or suggestions gratefully received! Thanks.

Expand: Current System Details

##### SERVER #####
IP-address (as per hostname): ***.***.***.***
[WARN] could not determine server's ip address by ifconfig
[INFO] OS version is Ubuntu 18.04.5 LTS

[INFO] uptime: 01:14:35 up 54 min, 1 user, load average: 0.07, 0.07, 0.10

[INFO] memory:
total used free shared buff/cache available
Mem: 7.8G 1.7G 5.1G 20M 1.0G 5.8G
Swap: 2.0G 0B 2.0G

[INFO] ISPConfig is installed.
[WARN] /usr/local/ispconfig/server/lib/config.inc.php is missing.

##### VERSION CHECK #####

[INFO] php (cli) version is 7.2.24-0ubuntu***.***.***.***
[INFO] php-cgi (used for cgi php in default vhost!) is version 7.2.24

##### PORT CHECK #####

##### MAIL SERVER CHECK #####

##### RUNNING SERVER PROCESSES #####
[WARN] I could not determine which web server is running.
[WARN] I could not determine which mail server is running.
[WARN] I could not determine which pop3 server is running.
[WARN] I could not determine which imap server is running.
[WARN] I could not determine which ftp server is running.

##### LISTENING PORTS #####
(only ()
Local (Address)
[anywhere]:465 (-)
[anywhere]:8081 (-)
[anywhere]:21 (-)
***.***.***.***:53 (-)
***.***.***.***:53 (-)
[localhost]:53 (-)
***.***.***.***:53 (-)
[anywhere]:22 (-)
[anywhere]:25 (-)
[localhost]:953 (-)
[anywhere]:443 (-)
[anywhere]:993 (-)
[anywhere]:995 (-)
[localhost]:10024 (-)
[localhost]:10025 (-)
[localhost]:10026 (-)
[localhost]:10027 (-)
[anywhere]:587 (-)
[localhost]:11211 (-)
[anywhere]:110 (-)
[anywhere]:110 (-)
[anywhere]:143 (-)
[anywhere]:8080 (-)
[anywhere]:80 (-)
*:*:*:*::*:465 (-)
*:*:*:*::*:4949 (-)
*:*:*:*::*:21 (-)
*:*:*:*::*:53 (-)
*:*:*:*::*:22 (-)
*:*:*:*::*:25 (-)
*:*:*:*::*:993 (-)
*:*:*:*::*:995 (-)
*:*:*:*::*:3306 (-)
*:*:*:*::*:587 (-)
[localhost]10 (-)
[localhost]43 (-)

##### IPTABLES #####

##### LET'S ENCRYPT #####
Certbot is installed in /usr/bin/letsencrypt

 

Thanks for the tip Jesse.

 

Really!? That is a shame, since our users reported noticeable improvements to their page load times and application responsiveness when using it. It will be interesting to see how quickly they notice the slow-down when we switch back to PHP-FPM.
Thanks for the information though Till. I wasn't aware of that. I think it's most likely the reason for the apache failure we experienced when we upgraded with it enabled. I'm excited to try again now with PHP-FPM instead.

 

That's encouraging. We've not experienced PHP 7.4 yet but will do after successful upgrade.

 

We've attempted another upgrade, this time using PHP-FPM as the default handler. We got the same error, but we were able to capture the error below concerning Apache. At the time or writing, we've not yet rolled back yet, as it's only 1am here.
Here is the error when restarting Apache:

Code:

[email protected]:~# systemctl status apache2.service
_ apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           __apache2-systemd.conf
   Active: failed (Result: exit-code) since Fri 2021-06-04 00:24:06 PST; 3min 0s ago
  Process: 30212 ExecStop=/usr/sbin/apachectl stop (code=exited, status=1/FAILURE)
  Process: 30206 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=1/FAILURE)
  Process: 32324 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
 Main PID: 575 (code=exited, status=0/SUCCESS)

Jun 04 00:24:06 s1.snowweb.info systemd[1]: Starting The Apache HTTP Server...
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: [Fri Jun 04 00:24:06.262172 2021] [alias:warn] [pid 32327] AH00671: The Alias directive in /etc/apache2/conf-enabled/roundcube.conf at line 4 will probably never match because it overlaps an earlier Alias.
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.vhost:7
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: AH00526: Syntax error on line 168 of /etc/apache2/sites-enabled/100-s1.snowweb.info.vhost:
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: SSLCertificateFile: file '/var/www/clients/client2/web2/ssl/s1.snowweb.info-le.crt' does not exist or is empty
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: Action 'start' failed.
Jun 04 00:24:06 s1.snowweb.info apachectl[32324]: The Apache error log may have more information.
Jun 04 00:24:06 s1.snowweb.info systemd[1]: apache2.service: Control process exited, code=exited status=1
Jun 04 00:24:06 s1.snowweb.info systemd[1]: apache2.service: Failed with result 'exit-code'.
Jun 04 00:24:06 s1.snowweb.info systemd[1]: Failed to start The Apache HTTP Server.

This is the snippet from the file it /etc/apache2/sites-enabled/100-s1.snowweb.info.vhost (with line numbers added):

Code:

160    <IfModule mod_ssl.c>
161     SSLEngine on
162     SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
163     # SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AE$
164     SSLHonorCipherOrder     on
165     # <IfModule mod_headers.c>
166     #    Header always add Strict-Transport-Security "max-age=15768000"
167     # </IfModule>
168     SSLCertificateFile /var/www/clients/client2/web2/ssl/s1.snowweb.info-le.crt
169     SSLCertificateKeyFile /var/www/clients/client2/web2/ssl/s1.snowweb.info-le.key
170     SSLUseStapling on
171     SSLStaplingResponderTimeout 5
172     SSLStaplingReturnResponderErrors off
173    </IfModule>

We didn't edit any httpd.conf files before we began. Hopefully we won't need to edit them all, but this one is for our panel, so maybe it's just a special case?
Any advise please?

 

I don't think so Till. I don't think we're doing anything special.