- This topic has 16 replies, 1 voice, and was last updated 2 months ago by hashtagframework.
- November 11, 2020 at 1:22 pm #2074notdedicatedParticipant
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:
Pin: release *
Pin: release *
Pin: release *
Pin: release *
This ensures we don’t install versions we don’t wantNovember 11, 2020 at 1:22 pm #2075secretvrdevGuest
Unattended updates on Sunday?November 11, 2020 at 1:22 pm #2076hurlingsearsethicGuest
that is scary, thanks for mentioning this. will watch our builds closely this upcoming weekNovember 11, 2020 at 1:22 pm #2077sleemanjGuestNovember 11, 2020 at 1:22 pm #2078DanackGuest
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.November 11, 2020 at 1:22 pm #2079derickrethansGuest
Did your application still work though?November 11, 2020 at 1:22 pm #2080m_i_h_a_iGuest
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`November 11, 2020 at 1:22 pm #2081dendeighGuest
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 packageNovember 11, 2020 at 1:22 pm #2082djvdorpGuest
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 🙂November 11, 2020 at 1:22 pm #2083[deleted]Guest
[deleted]November 11, 2020 at 1:22 pm #2084Jack_12221Guest
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.November 11, 2020 at 1:22 pm #2085hparadizGuest
Yea…. this is why I don’t do unattended updates.November 11, 2020 at 1:22 pm #2086palpablefuckeryGuest
ngl this shit fucked with me today. Thank you for posting about it. Still trying to sort it out.November 11, 2020 at 1:22 pm #2087ostap_3Guest
Haha, I had the same yesterday.
Installed all other modules with this command:
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
“`November 11, 2020 at 1:22 pm #2088MatthiasKuehneGuest
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?
- You must be logged in to reply to this topic.