PHP frissítés szerveren: mikor érdemes?

Internet: PHP, CGI, stb.

Sziasztok.

Elemi ösztöneim azt súgják, hogy mindig ragaszkodni vakon a legújabb dolgokhoz olyan, mint amikor önként tolom oda magam kísérleti patkánynak egy gyógyszegyárnak.

Szerintem PHP-t frissíteni egy üzemelő webszerveren akkor érdemes, amikor már a főbb Linux distribek is ráálltak arra, hogy tárolóikban ne a régit használják.

A CMS-ek (pl. joomla) állandóan reklamírozzák magukat, hogy az újat is képesek használni, csakhogy az meg a linux-distribeken túlmutatva még bétább verziók, még nagyobb eséllyel vannak tele hézagokkal.

Kérdésem az, ki mikor tartja tényleg időszerűnek a szeveroldali frissítéseket PHP, mysql és egyéb téren.

  • 2804 megtekintés

( janoszen v | 2016. 05. 02., h – 17:52 )

Nekem hosszu evek ota az a tapasztalatom, hogy major verziot .3 elott nem szabad ugrani, azutan viszont mihamarabb fel kell tenni a biztonsagi frissiteseket. A PHP7 kivetel, eleg ronda (potencialis) secholeok kerultek ki meg a legutobbi releaseben is, en kivarok legalabb 6 honapot mielott productionben kezdem el hasznalni. Magyarul jelenleg PHP 5.6 fut mindenhol.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ennek tudatában mit szólnál ahhoz, ha mondjuk lenne a cégnél egy window$on szocializálódott rendszergazdád, aki ragaszkodna mindig az újhoz, miközben gőze sincs majorverziók mibenlétéről, mi több linuxos webszerveren a Linuxról sincs semmi fogalma?

------
localhoston:
~$ php --version
PHP 5.6.11-1ubuntu3.1 (cli)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Felhívnám a figyelmét, hogy az éles rendszeren az új verzió telepítési engedélykérelméhez mindig csatolnia kell az új verzióval a tesztrendszeren elvégzett sikeres regressziós tesztek jegyzőkönyvét. ;) :D

(láttam már olyan helyet, ahol kb. tényleg így működnek az igazán fontos rendszerek)

Természetesen normális ügyfél normális rendszere volt, _tehát_ nem PHP-s. Amúgy a tesztelés egyáltalán nem kell hosszadalmas legyen, normálisan kidolgozott és megtámogatott tesztek mellett azért egy napnak elégnek kéne lennie ilyesmikre. A gond ott van, hogy a nagyon sok helyen egész egyszerűen nincsenek tesztek semmire, és pont az ilyen helyeken lenne szükség rájuk :)

Rendszer(ek) mennyisége,bonyolultsága és integráltsága kapcsán azért bátor dolog ilyet kijelenteni: "normálisan kidolgozott és megtámogatott tesztek mellett azért egy napnak elégnek kéne lennie ilyesmikre"..
---
Referrall https://goo.gl/7S2vlp (koding) | https://goo.gl/muWzKz (digitalocean)

Mint azt tudjuk, ami 1 embernek 24 órás munka, az 24 embernek 1 órás. :) Szóval semmi sem lehetetlen. Abban van szerintem igazság, hogy csak a tesztre, tehát ha már minden össze van rakva előre, akkor a funkcionális teszthez elég lehet egy nap. Sőt automatizálni is lehet valamennyire és elsőre lehet nézni a logokat, hogy mennyire vannak teli. :)

( Frantique v | 2016. 05. 02., h – 18:48 )

Egy saját fordításból származó patchelt 5.3.x sokszor nyugisabb, mint egy aktuális current stable. Egyáltalán mit tudunk, miért ragaszkodik az újhoz? Az új miatt, vagy a fejlesztés során a legújabb komponenseket használjátok? Ha nem indokolt, akkor ne cseréljetek le egy régebbi, de minden lehetséges irányból rendbe rakott ökoszisztémát csak azért, mert van újabb. Erre/ilyenekre már rácsesztünk páran a múltban, szerintem...
--
Aláírás szünetel...

Olyan sarkított esetre gondoltam, ahol egy régi (például 5.3-ra írt) rendszer olyan erős függőséggel bír, hogy az újabb verziókra való átállás lehetetlen (a fejlesztés befejezett, nincs upgrade, és a policy nem engedi meg a házi frissítést, esetleg phc-t használtak) bizonyos megszűnt függvények miatt. Ilyenkor könnyebb az adott verziót védeni. (Létező esetről beszélek.)
--
Aláírás szünetel...

Sima webszerver esetén mindenképpen stabil verziót, ha az repóból jön, és folyamatosan monitorozni a secreportokat főleg underground körökben, ha van hozzáférésed, persze. Nyitott szemmel és füllel kell mozogni az ellenséges vonalak mögött, akkor nem lesz nagy baj vagy meglepetés.

--
Aláírás szünetel...

Ezzel azt akarod mondani, hogy a security frissítéseket backportolod 5.3-ba? Nem sok meló az kicsit?

Egyébként az 5.3.3-tól az 5.6-ig viszonylag fájdalommentes az upgrade, csak néhány nagyon elvetemült funkciót sikerült eltörniük. A 7-nél majd megint jönnek a furcsaságok.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A folyamatos és rendszeres frissítés miatt mindig egészen pontosan tudni fogod, hogy mi változott, mert emberi léptékű a change log; pontosan tudni fogod, hogy az eddigi működést érintő változtatás mennyire befolyásolja a rendszer egészének működését és pontosan tudni fogod, hogy adott esetben ennek az egy komponensnek a minor frissítése okozta a problémát.

Ha ezt nem végzed el rendszeresen, akkor a távoli jövőbe tolod az összes ilyen apró változtatást és napról-napra nagyobb szargalacsinként hajtod magad előtt, majd amikor évek múlva frissítened kell mindent egyszerre, egyszerre kell ezt a szargalacsint feldolgoznod, akkor fogalmad se lesz arról, hogy mi okozza a problémákat...

...a réges-régi verzióban lévő biztonsági problémákról nem is beszélve.

( dotnetlinux | 2016. 05. 03., k – 07:04 )

Mindenki a php-hez szólt hozzá, mysql-hez tenném hozzá:
- Rendszeresen, jól tervezhetően jön ki frissítés.
- Percona fork-ot használunk (nem cluster, sima xtradb)
- Percona 3-4 hét késéssel adja ki a saját forkját
- 3-4 hét próbaidő a világnak = elég nekünk, hogy a mi szintünkön megbízható legyen

Szóval Percona dsitro-ból eddig megbízhatóan tudtunk telepíteni. De mindig egy kevésbé fontos szerveren teszteljük (saját DEMO szerver pl.), mert megállhat, ahogy most is: sima update (5.6->5.7) után nem tudtunk belépni, mert az user táblák struktúrája változott. Szóval teszt kell...

A MySQL és forkjai többnyire stabilak, nagyon elvetemült feature-t kell használnia az adott programnak ahhoz, hogy egyszer csak ne működjön. Viszont egy 5.6-5.7 ugrásnál mindenképpen érdemes legalább végig nyomkodni. A security frissítéseket nyugodtan tedd fel szerintem, jobb mint ha nem teszed fel.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Pont ezért írtam és jellemeztem "furcsaként" hogy egy 5.6 -> 5.7 átállás néha fájóbb tud lenni már az alapoknál is, mint egy 4.0->5.0, major release váltás.

Ami még nálunk sokat segít: szinten tartjuk a projekteket. Mindegyik mysqli-re épülő, közös kódbázisú cucc, amelyek alatt egyforma verziójú rendszerek futnak. Igen, könnyű dolgunk van, mert gyártjuk és szolgáltatjuk a rendszereket, de az elv a fontosabb itt.

Van egy jól behatárolt LIB halmaz, amit minden projekt használ (include, projektbe másolva, de közös fájlban). Ezt csak a vezető fejlesztő módosíthatja. Neki meg pont az a feladata, hogy ez menjen. Natív SQL-eket nem hívunk direktben az ad-hoc létrehozott DB kapcsolaton. Helyette van DB::Select(), ami futtat, naplóz, sőt az utolsó verzió óta méri is a végrehajtás idejét. És ez minden projektben hirtelen megjelent, mert egy a kód.

Persze a cégünknek/cégünkben biztos vannak más "bajok", másvalaki másképp csinálná. De az architektúra fontos a cégtulajdonosnak, ezt nem engedi "elkurvítani".

( sj | 2016. 05. 04., sze – 20:24 )

ez eleg masszivan fugg attol, hogy milyen webszerverrol beszelunk.

Ha egy szolgaltato vagy, aminek a webszerveren csillio egymastol fuggetlen ugyfel website van, akkor ott erdemes konzervativnak lenni, es ragaszkodni az OS szallitotta php es mysql verziokhoz. Erdemes valamilyen LTS verziot valasztani, de amikor csomagkezelo szol, hogy jo lenne frissiteni, akkor azt asap feltenni. Es mindezt az ASZF-be beleirni, esetleg azt is, hogy a szolgaltato max. 3 evig tart meg egy adott LTS verziot, aztan dist-upgrade-elhet, amivel major verziok is valtozhatnak.

Ha egy adott ugyfel webszerveret kalapalod, akkor nyilatkozzon a kedves ugyfel fejlesztoje, hogy milyen php, mysql, stb. verzio kell neki. Ha kell neki pl. a 7.0.0 valamelyik uj feature-je, akkor hadd kapja meg. Erdemes esetleg egy kontenerben adni neki egy homokozot, hadd kostolgassa az atallas elott*. Aztan ha bebukta, akkor igy jaras volt. Esetleg a visszaallitas munkaorait jol raverni a vastagon fogo ceruzaval.

*: Legalabbis ha arra a maflara gondolok, aki kitalalta, hogy de jo lenne a php 5.100. Megkapta. Nyilvan szetesett az uberfontos, 7x24-ben mukodo site. Aztan jott a telefon, hogy tegyetek vissza a regit. Miutan a dependenciak miatt lecserelte a fel OS-t a cucc (OK, kisse sarkitok).

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)