add and update php 7.1 and 7.2 on Stretch perfect server

Discussion in 'Installation/Configuration' started by jbonlinea, Jan 23, 2019.

  1. jbonlinea

    jbonlinea Member

    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
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

  3. jbonlinea

    jbonlinea Member

  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Does the Makefile have an uninstall target? Try
    Code:
    make uninstall
     
  5. jbonlinea

    jbonlinea Member

    not in /usr/local/src/php7.2-build/php.7.2.2/

    Code:
    [email protected]:/usr/local/src/php7.2-build/php-7.2.2# make uninstall
    make: *** No rule to make target 'uninstall'.  Stop.
    
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    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/
     
  7. jbonlinea

    jbonlinea Member

    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
     
  8. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  10. jbonlinea

    jbonlinea Member

    ok excellent, i'll give it a try then

    Thank's again for your great support
     
  11. Jesse Norell

    Jesse Norell Well-Known Member

    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.
     
  12. jbonlinea

    jbonlinea Member

    @Jesse Norell thank's foy your long reply, totally confirm what I had in mind and the route @Taleman & @till were putting me on.
     
  13. jbonlinea

    jbonlinea Member

    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
     
  14. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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
     
    Last edited: Mar 26, 2019
  15. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    I updated signature key on my host.
    Before:
    Code:
    [email protected]:~# 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]
    [email protected]:~# 
    Running
    Code:
    wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
    After:
    Code:
    [email protected]:~# 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]
    [email protected]:~# 
    No more complaints about signatures not being verified.
     
  16. jbonlinea

    jbonlinea Member

    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
     
  17. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    You did not read the posts by Ondrej Sury I linked to in #14.
     
  18. jbonlinea

    jbonlinea Member

    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 ;)
     
  19. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     

Share This Page