Hi folks,
i’m almost done now
I did a standard sudo apt-get update && sudo apt-get dist-upgrade and since then mysqli extension is not available anymore.
i did:
$ sudo apt-get update && sudo apt-get dist-upgrade
Holen:1 Index of /ubuntu bionic-security InRelease [88,7 kB]
OK:2 Index of /ubuntu bionic InRelease
Holen:3 Index of /ubuntu bionic-updates InRelease [88,7 kB]
Holen:4 Index of /ubuntu bionic-backports InRelease [74,6 kB]
Holen:5 Index of /ubuntu bionic-security/universe Sources [34,6 kB]
Holen:6 Index of /ubuntu bionic-security/universe i386 Packages [123 kB]
Holen:7 Index of /ubuntu bionic-updates/universe Sources [129 kB]
Holen:8 Index of /ubuntu bionic-security/universe amd64 Packages [126 kB]
Ign:9 Index of /debian/ bionic InRelease
Holen:10 Index of /ubuntu bionic-updates/main i386 Packages [450 kB]
Holen:11 Index of /ubuntu bionic-security/universe Translation-en [70,6 kB]
OK:12 Index of /debian/ bionic Release
Holen:14 Index of /ubuntu bionic-updates/main amd64 Packages [523 kB]
Holen:15 Index of /ubuntu bionic-updates/universe amd64 Packages [730 kB]
Holen:16 Index of /ubuntu bionic-updates/universe i386 Packages [721 kB]
Holen:17 Index of /ubuntu bionic-updates/universe Translation-en [185 kB]
Es wurden 3.344 kB in 2 s geholt (1.419 kB/s).
Paketlisten werden gelesen… Fertig
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
openlitespeed php7.2-cli php7.2-common php7.2-json php7.2-opcache
php7.2-readline php7.2-xml
7 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 8.498 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 17,4 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 Index of /ubuntu bionic-updates/main amd64 php7.2-xml amd64 7.2.15-0ubuntu0.18.04.1 [107 kB]
Holen:2 Index of /ubuntu bionic-updates/main amd64 php7.2-opcache amd64 7.2.15-0ubuntu0.18.04.1 [165 kB]
Holen:3 Index of /ubuntu bionic-updates/main amd64 php7.2-json amd64 7.2.15-0ubuntu0.18.04.1 [18,8 kB]
Holen:4 Index of /ubuntu bionic-updates/main amd64 php7.2-readline amd64 7.2.15-0ubuntu0.18.04.1 [12,1 kB]
Holen:5 Index of /ubuntu bionic-updates/main amd64 php7.2-cli amd64 7.2.15-0ubuntu0.18.04.1 [1.409 kB]
Holen:6 Index of /ubuntu bionic-updates/main amd64 php7.2-common amd64 7.2.15-0ubuntu0.18.04.1 [882 kB]
Holen:7 Index of /debian/ bionic/main amd64 openlitespeed amd64 1.4.44-1+bionic [5.903 kB]
Es wurden 8.498 kB in 2 s geholt (3.433 kB/s).
(Lese Datenbank … 122010 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von …/0-openlitespeed_1.4.44-1+bionic_amd64.deb …
Entpacken von openlitespeed (1.4.44-1+bionic) über (1.4.43-1+bionic) …
Vorbereitung zum Entpacken von …/1-php7.2-xml_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-xml (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
Vorbereitung zum Entpacken von …/2-php7.2-opcache_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-opcache (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
Vorbereitung zum Entpacken von …/3-php7.2-json_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-json (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
Vorbereitung zum Entpacken von …/4-php7.2-readline_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-readline (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
Vorbereitung zum Entpacken von …/5-php7.2-cli_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-cli (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
Vorbereitung zum Entpacken von …/6-php7.2-common_7.2.15-0ubuntu0.18.04.1_amd64.deb …
Entpacken von php7.2-common (7.2.15-0ubuntu0.18.04.1) über (7.2.10-0ubuntu0.18.04.1) …
php7.2-common (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
php7.2-readline (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
Trigger für man-db (2.8.3-2ubuntu0.1) werden verarbeitet …
php7.2-json (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
openlitespeed (1.4.44-1+bionic) wird eingerichtet …
php7.2-opcache (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
php7.2-xml (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
php7.2-cli (7.2.15-0ubuntu0.18.04.1) wird eingerichtet …
Replacing config file /etc/php/7.2/cli/php.ini with new version
Since then i’m not able anymore to alter anything in advanced php configuration within Cyberpanel and a phpinfo() shows that my previously on php7.2 running domain is now running on PHP Version 5.6.36
Is there any rescue? Looks like phplsapi got replaced with standard php?
Would it be better to switch to CentOs instead of Ubuntu. I’m looking forward to use Cyberpanel and OLS in production at 4 VPS. No hosting service, only own projects.
I’m well aware that maintaining a system and keep it secure takes a few hours worktime per month. But hmm…
Thanks for your opinion. I’m thinking the same and others are saying that as well.
Next time i’ll sure make a snapshot of the system before tinkering with updates any sort.
Mistake made, lesson learned
Nope. Plain install of netcup Ubuntu 18.04 minimal version, after that install of Cyberpanel the regular way.
I’ve done off course several security updates this way before and never had a problem. And off course, just for completing this answer, i never installed php5.6.36 intentionally. I really don’t have a clou what went wrong with that update. Kinda scaring me a bit
Server is also pretty secure with root disabled, different ssh port, disabled port 22, ultra secure passwords and the like.
But, yes, somehow it seems there was a plain php7.2 installed before, otherwise the update process would not have noticed that there’s a update needed. I’ll have a look at the netcup distro.
I’ll start from scratch since i can’t figure out what happened there. Going the CentOs route.
Just before i wanted to reinstall i had another look and discovered that the vHost maindomain is running on PHP Version 7.3.1-2+bionic like i expected it, but any childdomain under that maindomain is running on PHP Version 5.6.36.
The change of php version in cyberpanel for the childdomain to Php 7.3.1-2+bionic did have no effect. Neither the change initiated on the “list childdomains page” works, nor the change of php at the childdomains details listing page works. Remains on PHP Version 5.6.36.
Changing php version of the vHosts maindomain works flawless and there are version 7.0 til 7.3 available (phplsapi) with Configuration File (php.ini) Path /usr/local/lsws/lsphp73/etc/php/7.3/litespeed/
And another observation: removed childdomain through Cyberpanel, restarted OLS and added the childdomain new at Cyberpanel. After installation the childdomain inherits the php version from the maindomain, in my case 7.3.1-2+bionic.
1.) the childdomain is running as expected until you try to change php version of that childdomain. Once you do that, PHP falls back to 5.6.36 and Cyberpanel does not react anymore to further attempts to change the PHP version back to 7.3 or any other, from the dropdown available PHP version.
So, this seems to be more a error of either Cyberpanel or OLS, than a error resulting from the apt-get upgrade.
I remember that right after the upgrade i looked into Cyberpanel and changed the PHP version of that childdomain to php 7.2 just to look if it is working.
That may have triggered the error described above (1.)).
I’m doing a fresh install on Ubuntu again and report back.
Yep, was able to reproduce that error. Must be at Cyberpanel.
Steps to reproduce:
1.) Clean install of Ubuntu 18.04 minimal version
2.) install Cyberpanel with OLS
3.) Set up a virtual Host with php 7.0 as preference
4.) Under that vHost add another Domain (Childdomain)
5.) verify both are working with phpinfo
6.) Change the childdomains php version to 7.2 and verify again it’s still working.
From here on i did the following steps:
1.) changed the childdomains php version to 7.0 and altered the php.ini in advanced mode. Removed a semikolon in front of mysqli.dll to get rid of the error message “Fatal error: Call to undefined function mysqli_connect() in”
2.) did that for the other php versions as well just to be sure if i want to switch in the future that i’ll not forget that.
3.) altered vHost Conf and changed the lines:
scripthandler {
add lsapi:vultras1219 php
}
to:
scripthandler {
add lsapi:vultras1219 php, html
}
in order to parse html files with php.
Any one of these 3 steps or all together made that the childdomain does fall back to php 5.6.36 and from that time on one can not change the childdomains php version anymore
