Ubuntu PPA installs PHP 8.0RC1 automatically???

  • This topic has 16 replies, 1 voice, and was last updated 2 months ago by hashtagframework.
Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #2074
    notdedicated
    Participant

    This morning several of the production / staging systems we use that run PHP7 and on an unattended upgrades all of a sudden installed PHP8.0 RC1 from the ondrej PPA. Anyone else have this happen? Not only is ondrej supposed to be a 5.x / 7.x release channel but promoting out a release candidate as part of the primary PPA and not a Dev/Staging? I mean I know there’s some onus on our team to ensure we’re version pinned and generally our tools do ensure we’re running the correct version but the unattended upgrade shouldn’t install an RC…

    Edit 2: *What really happened*

    It may have been our UAGs or it may have been chef ensuring our packages were up to date for the php7.2* set we wanted installed. We are version pinning in that sense. What happened as far as we can tell is, on the machines that were affected, SOME had, at one point, had one of the php-extension meta packages installed before being switched to the explicit php7.2-extension version. What didn’t happen was a purge of the meta before installing the version locked one. It appears that during an “upgrade” Ubuntu decided that it should update the meta version which caused, according to [https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706754897](https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706754897), ALL versions of PHP to be installed. In a comedy of errors. Ubuntu, at the PPA’s bequest, set the auto alternative to php8.0 which broke everything.

    IMO this is some serious bullshit that even using explicit package installations that a meta package can install complete sets of software without asking and FURTHER set the default to versions never asked for nor even ready for a production environment. It should be a system where we get what we ask for and nothing else. Not only do we now have to ensure that we never use a meta package, we have to add black lists like below, AND we have to ensure the alternatives are managed through whatever tool in use.

    This wouldn’t have been as much of a problem if the systems didn’t decide to UPDATE THE ALTERNATIVE automatically!! WTH??

    ​

    Edit: For now we’re adding the following lines to our servers to help keep this from happening:

    /etc/apt/preferences.d/php.pref
    Package: php8.0*
    Pin: release *
    Pin-Priority: -1

    Package: php5.6*
    Pin: release *
    Pin-Priority: -1

    Package: php7.3*
    Pin: release *
    Pin-Priority: 100

    Package: php7.*
    Pin: release *
    Pin-Priority: -1

    This ensures we don’t install versions we don’t want

    #2075
    secretvrdev
    Guest

    Unattended updates on Sunday?

    #2076
    hurlingsearsethic
    Guest

    that is scary, thanks for mentioning this. will watch our builds closely this upcoming week

    #2077
    sleemanj
    Guest
    #2078
    Danack
    Guest

    What’s the exact command you’re using to install PHP please?

    Asking as it might be a problem that needs to be fixed by the PPA urgently, or it might be something you’re doing that inadvertently asks for the latest version no matter stability.

    #2079
    derickrethans
    Guest

    Did your application still work though?

    #2080
    m_i_h_a_i
    Guest

    The same for me on Ubuntu 18.04 LTS, running php7.2. The only thing changed it was the CLI version for PHP – it went to php8, but the fix was quite simple on this case: `update-alternatives –set php /usr/bin/php7.2`

    #2081
    dendeigh
    Guest

    seems like the main issue has been resolved, see [https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706889681](https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706889681)

    > I think I found a way how to circumvent the problem other way. The individual packages don’t depend on matching phpapi-<ver> now, so they don’t pull any of the SAPIs. That way when you do apt install php7.4-apcu it won’t pull php7.4-cli which leaves your system just with the binary extension and nothing to use it with, but that way installing php-apcu will just install the PHP extensions and not all the PHP releases available.

    I justed tested this on a dev system and a `apt update` + `apt upgrade` only installs 8.0 extensions (for the meta packages like memcached etc.) but no php8.0-cli package

    #2082
    djvdorp
    Guest

    Thanks, had the same issue! Updating the alternative back to the version it should work was working as a quick way to restore things, and we’re adding your prefs.d as we speak now 🙂

    #2083
    [deleted]
    Guest

    [deleted]

    #2084
    Jack_12221
    Guest

    Same here… It also installed swaths of 5.6, 7.2 and 7.3. Took me a while to cleanup, thankfully nothing tried to use 8.0.

    #2085
    hparadiz
    Guest

    Yea…. this is why I don’t do unattended updates.

    #2086
    palpablefuckery
    Guest

    ngl this shit fucked with me today. Thank you for posting about it. Still trying to sort it out.

    #2087
    ostap_3
    Guest

    Haha, I had the same yesterday.

    Installed all other modules with this command:

    “`bash
    sudo apt-get install -y php8.0 php8.0-imagick php8.0-bcmath php8.0-pgsql php8.0-sqlite php8.0-dom php8.0-apcu php8.0-mbstring php8.0-intl php8.0-gd php8.0-mysql php8.0-zip php8.0-fpm php8.0-curl

    “`

    #2088
    MatthiasKuehne
    Guest

    We have unattended installs activated too and actively using ondrejs Deb repo. No automatic upgrading of PHP though … seems like your unattended-upgrades isnt setup properly, no?

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.