Automatické aktualizace PHP v Debianu

[Jan Vondráček]

V naší organizaci se snažíme o udržování aktuálních OS a tak máme všude zapnuté automatické aktualizace (unattended-upgrades). Ale v případě nového serveru pro Drupal 10 jsme narazili. Debian 11 obsahuje systémově jen PHP7.4, což je pro Drupal 10 málo. Použil jsem externí repozitář https://deb.sury.org/ abych na systém dostal PHP8.1. A ručně dokompiloval moduly na podporu Oracle (oci8 a pdo_oci).

Jenže se objevila aktualizace, která správně opatchovala PHP7.4 i PHP8.1. Ale zároveň doinstalovala nově vydané PHP8.2 a apache na něj přepla. Tím se objevily rozpory v composeru, zmizela podpora Oraclu atd. a musel jsem dělat ruční nápravu.

Můžete se prosím podělit o vaše zkušennosti jak aktualizujete servery pod vaší správou? Řešili jste někdy podobný problém?

Cesta by mohla být pomocí apt piningu, ale zatím se mi nedaří najít vyhovující nastavení.

[Reklama]

[to_je_jedno]

Docker.

[czechsys]

Taky se mi to stalo. Jako reseni jsem zvolil nepouzivat php-neco moduly, ale ciste phpVERZE-neco moduly. Pak nevzniknou zavislosti, ktere tahaji i dalsi verze php.

[madmucho]

Dobrý den,
pro výběr phpka které ma systém použivat jsou příkazy kterými vyberete verzi a ta pak zůstává.

Kód: [Vybrat]

update-alternatives --config php
update-alternatives --config php-cgi
update-alternatives --config php-fpm.sock
Běžně takové instlaace pro korporáty dělám v ispconfigu protože jsou tam i archeologické vykopávky na php 5.6 tak v ispconfigu každá sajta muže mít jiné php klidně i subverzi a běží na jednom serveru pro to určeném.

https://www.howtoforge.com/ispconfig-php-ubuntu/

[Jan Vondráček]

Děkuji za pomoc a postrčení. Nakonec pomohlo kombinace všeho. Pomocí piningu snížit prioritu surého repozitáře, nainstalovat php s číslem verze a v alternativách nastavit přesnou verzi. Uvidím co na to zítra řekne automatická aktualizace, ale myslím, že to už bude v pořádku.

[Reklama]

[_Tomáš_]

žádnou aplikační závislost neinstaluji přes systémové balíčky, pokud není možný docker (či systemd nspawn nebo jail), tak používám třeba něco na způsob conda-forge balíčků https://anaconda.org/conda-forge/php.

Dříve jsem tohle hodnotil jako nesmysl, prostě mělo vše být instalované z oficiálních udržovaných repositářů, ale dnes aplikační vývoj na projektech, kde dělám je hodně OS nezávislý a vývojáři jedou jiným životním cyklem než samotný OS, často OS potřebujeme aktualizovat a neohlížet se na vývojáře, být schopný aplikaci otestovat a sestavit.

Další důvod je schopnost konečné sestavení nějak rozumně testovat, doba, kdy člověk dal update a trnul co za skripty se na produkci spustí a co udělají za změny je pro mě pryč, nechci, aby se na produkci spouštělo cokoliv nedetermistického, hci produkci prostě atomicky přepnout a ne instalovat a čekat.

Dnes se mi velice osvědčuje používat nixos, generovat celý vm/docker/chroot dopředu vč. aplikace, testovat, analyzovat, kontrolovat a pak 1:1 nasadit. Máme pak přesný přehled o tom, která aplikace s jakými závislostmi kde přesně běží, máme možnost dělat emergency patche i do zdrojáků php a nečekat na maintenera.

Po letech s debianem začínám tu jejich filosofii deb balíčků, install scriptů a závislostí nemít rád.

[Jan Vondráček]

Děkuji za podnětné myšlenky.