Hi, I'm using ISPConfig on the Debian Stretch perfect server and so far so good As you know Strech only provides php7.0, and the need for alternative version of php may occurs. For that matter I found the tutorial to install php5.6, php7.1 and php 7.2. That's awesome but I have a couple of questions. First how am I suppose to deal with the php extentions ? I had to add few of them for php7.0. Do I have to add them for php7.1/2 ? and how ? Are some extention shared by different version of php ? how do I know that ? Fially is there any way to "automate" the install of the "same" extention on all my php7.x versions ? Second By the time the tutorial was written, the lates php version was php7.2.2. Today the latest version is 7.2.14. To install this later version, I only have to download it and change folder name in the command accordingly ? right ? Ok great, no in some time php 7.2 will be upgraded from 7.2.14 to 7.2.15, and so forth. How do I update php7.2, and all the modules ? It won't be upgrade by apt-get update/upgrade. So what's the proper way to proceed ? Thank's is advance for you ilumination All best
ok excellent suggestion. One question thow : how do I uninstall php7.x that I've already install folowing the other tutorial ? thank's
not in /usr/local/src/php7.2-build/php.7.2.2/ Code: root@vpsXXXXXX:/usr/local/src/php7.2-build/php-7.2.2# make uninstall make: *** No rule to make target 'uninstall'. Stop.
Everything is installed in /opt/... excpet of the systemd unit. So just stop the service, remove the systemd unit file and then delete the folder for that PHP version in /opt/
ok awesome one question on long term thinking, what is best, go with @Taleman proposition or the tutorial first mentined in this topic ? I mean conflict wise, etc. ? I feel the second solution more brutal ? if the first one of the tutorial is preferable, then, how are we suppose to proceed to upgrade php from 7.2.a to 7.2.b ? Thank's
Update happens by following the tutorial again but this time with newer PHP. I don't know if you are supposed to remove the old version first.
Both methods have their pros and cons. But I have the feeling that the current third-party PHP repo is quite good so there will be hopefully no big issues with Debian Updates in the future. I use the precompiled packages myself on several servers at the moment.
My opinion: definitely go with the precompiled packages unless you have some requirement that prohibits it (eg. you need custom compile time options). I've had no conflicts with them. No, it's quicker and easier, both initially and for ongoing updates. That is exactly the problem with it. When I had self-compiled php executables, I almost never got around to updating the minor versions unless there was security vulnerability, and honestly didn't even catch all those. With the repos, you simply "apt-get update; apt-get upgrade -y" and you're done. But as you asked, if you do want to go with self compiled I would recommend naming your additional php versions something like 'PHP 7.2' and have the settings point to whatever current version you have (/opt/php-7.2.a/....). When you compile and install 7.2.b, following what @till described above, stop 7.2.a service, change the Additional PHP Version settings to point to /opt/php-7.2.b/... paths, then resync all websites, and make sure 7.2.b is running (I think it'll get started in the resync, but double-check). Once 7.2.b is working right, you can remove 7.2.a as @till described. Another alternative would be to add additional php version as 'PHP 7.2.a', and then add a second 'PHP 7.2.b', but then you have to go through all your websites and find/change the php version they are set to in order to update. You could automate that with an sql query followed by resyncing websites. The advantage would be you could change one site at a time and test them. (Personally I only test one or two, so just doing all at once and rolling back if needed is easier .. though I've never had to roll back to a previous version.)' Be sure to document your compile time settings and install commands well so you repeat them in future versions, and don't find yourself suddenly missing some module you used to have. @SergiX44 wrote a script to automate building and installing php versions in ISPConfig, that might well be worth looking in to.
@Jesse Norell thank's foy your long reply, totally confirm what I had in mind and the route @Taleman & @till were putting me on.
Hi guys, Let me quickly revive this topic. I installed php 7.2 from the sury repo as advised above, and so far so good. I recently updated the server, and so far so good as well, but today apt-get update returns Code: Get:9 https://packages.sury.org/php stretch InRelease [6,760 B] Err:9 https://packages.sury.org/php stretch InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 I can solve this by re-adding the key as I did folowing the tutorial : wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg But is it normal ? Also I know have after apt-get upgrade Code: The following packages have been kept back: certbot icu-devtools libapache2-mod-php libicu-dev php-bz2 php-gmp php-ldap php-mysql php-xml python-acme why, what, how, what have to be understood, and done ? Thank's
https://www.patreon.com/posts/dpa-n...ial&utm_source=twitter&utm_campaign=postshare I suspect Sury changed the signature key in the repo. I just checked I too get that Code: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 The timestamp on that file is 18. March 2019. There is news about this in Sury's twitter feed:https://twitter.com/debsuryorg . So it looks legit. https://www.patreon.com/posts/dpa-n...ial&utm_source=twitter&utm_campaign=postshare
I updated signature key on my host. Before: Code: root@web:~# gpg --keyid-format 0xlong < /etc/apt/trusted.gpg.d/php.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xAC0E47584A7A714D 2014-09-09 [SC] DF3D585DB8F0EB658690A554AC0E47584A7A714D uid CZ.NIC Labs Archive Automatic Signing Key <[email protected]> sub rsa4096/0xC8206E73FE9AA2B3 2014-09-09 [E] root@web:~# Running Code: wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg After: Code: root@web:~# gpg --keyid-format 0xlong < /etc/apt/trusted.gpg.d/php.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa3072/0xB188E2B695BD4743 2019-03-18 [SC] [expires: 2021-03-17] 15058500A0235D97F5D10063B188E2B695BD4743 uid DEB.SURY.ORG Automatic Signing Key <[email protected]> sub rsa3072/0xB214EAC28059B8AC 2019-03-18 [E] [expires: 2021-03-17] root@web:~# No more complaints about signatures not being verified.
Thank's Awesome, so basically their key was just renewed ? I'm ok with that just wonder if this is someting to be expected, and how often
Well I did quickly, do not realise what all the details means, and I meant to ask here as a broad question about change/renewal of keys, to me the answer could be - no, you should not expect that too often, this is abnormal, not routine, it happens very rarely, - well there are many factors leading to change a key like this one despite it's not a schulded task, so it it may happends every now and then in both case jush check on the repo maintenaire website/twitter/whatsoever to see what's going on ;-) Thank's for your reply, it was supportive and thoughfull
Thats the proper way to handle the situation. Just blindly changing the signature key or installing packages when the key does not match is very risky. Better to find out why key has changed. This case was security breach, and Ondrej changed the signature key just to be sure. This is not likely to happen often.
