Korrektül karbantartott PHP csomagok CentOS 7 alá?

Internet: PHP, CGI, stb.

Sziasztok!

Egy ügyfelünk (bér)szerverén jelenleg 5.4-es, a kvázi hivatalos Software Collections repóból telepített PHP fut CentOS 6 alatt. Mint pár napja megtudtuk (ez az infó eddig sajnos elkerülte a figyelmünket), 2016 októbere óta EOL státuszba került a "sclo-php54" csomag, így semmilyen frissítés nem jön már ki hozzá (ez egyébként a fájlok last modify dátumából is gyönyörűen látszik a repóban). Ezt az áldatlan állapotot szeretnénk minél előbb megszüntetni.A szerver egyébként is megérett a cserére, az új szerverre terveink szerint CentOS 7-et fogunk majd telepíteni, tehát legyen ez a kiindulási alap.

A kérdésem: milyen forrásból érdemes friss, lehetőleg upstream által is támogatott PHP verziót telepíteni úgy, hogy minimális legyen annak a veszélye, hogy a csomagkezelő egyszer csak úgy dönt, nem tartja karban a csomagokat a továbbiakban?

A verzióigény kapcsán nincs még biztos infó, mi értelemszerűen a legújabb stabil, 7.2-es verziót szeretnénk, és igen valószínű, hogy az alkalmazás gond nélkül el fog futni alatta, tekintve, hogy nem túl régi fejlesztésről beszélünk, és a mai napig rajta van a projekten egy 2-3 fős fejlesztői csapat az ügyfél oldaláról. Mindenképp olyan repóra lenne szükség, amit nem egy db fejlesztő tart karban, és számíthatunk rá, hogy legalább 2-3 évig fognak kijönni hozzá rendszeres security frissítések. Értelemszerűen nem szeretnénk újra abba a kellemetlen helyzetbe kerülni, amibe most kerültünk.

A forrásból fordítgatás (akár kézzel, akár szkriptelve) kizárt, pláne, hogy így bukhatunk olyan security fixeket, amiket a RedHat backportolt egy újabb verzióból (vagy esetleg ő maga implementálta), mivel ezek az upstream forráscsomagokban nem biztos, hogy benne vannak.

Biztos vagyok benne, hogy sok sysadmin-t érint ez a probléma, mi most egy kicsit elakadtunk ezzel, nem tudjuk, mi lenne a jó megoldás.

Ha nem találunk megoldást, akkor valószínűleg CentOS helyett Debiant fogunk telepíteni a szerverre, amiben alapból vannak a main repóból elérhető, rendszeresen karbantartott, 7.0-s PHP csomagok, melyek a Debian support policy-ja alapján az OS teljes életciklusa alatt (vagyis, Stretch esetén 2022-ig) támogatottak lesznek.

Ezeket kilőttük már:

* Main repóban lévő PHP csomagok: túl régi verzió (5.4), a fejlesztők mindenképp díjaznák, ha végre nem 5.4-es PHP-ra kellene fejleszteniük, illetve mi is jobban örülnénk, ha egy upstream által is karbantartott verziót használhatnánk, arról nem is beszélve, hogy egy csomó 3rd party alkalmazás, pl. a szerveren napi szinten használt phpmyadmin is legalább 5.6-os PHP-t igényel már évek óta.
* Remi's Repo: nem jó, egyetlen fejlesztő tartja karban (Remi Collet), igaz, egyelőre úgy tűnik, becsületesen adja ki a frissítéseket minden támogatott verzióhoz
* Webtatic: elég noname (a napokban hallottam róla először), ha minden igaz, egy Andy Thompson nevű úriember áll mögötte, vagyis esélyes, hogy itt is egy db fejlesztő tartja karban a csomagot, ergó kilőve...
* IUS: ha jól sejtem, szintén egy db fejlesztő áll mögötte (Carl George), igaz, a Rackspace szponzorálja a projektet... hogy ez jó vagy rossz, azt per pillanat nem tudom megítélni. :)

Előre is köszi az ötleteket!

( gergelykiss | 2018. 09. 28., p – 10:04 )

Kimaradt a posztból, de egyelőre az tűnik az egyetlen valid opciónak, ha az SCLo repóból telepítjük az rh-php70 csomagot. Talán itt a legkisebb az esélye, hogy váratlanul magára hagyják a csomagot, tekintve, hogy ezt a komplett SCLo SIG csapat felelőssége karbantartani. Bár nem annyira szimpatikus, amit a Policy részben írnak: "The software is cared for, but the developers make no commitments to update the repositories in a timely manner." :(

( _ventura_ v | 2018. 09. 28., p – 10:02 )

Itt ha csak 1 php verzio kell és újabb mint 5.4 akkor webtatic. Itt jönnek szépen az új verziók.

Viszont ahol sok ügyfél van sok domainnel, ott az SCL tárolók mennek. Így van 3-4 féle php verzió a szerveren. Van remi repo, mivel az alap SCL php repok nem teljesek sok csomag hianyzik, de szerencsére a remi repobol kiegészíthető az SCL cuccai :>.

Fedora 27, Thinkpad x220

Ez korrekt, de ha végigolvasod a posztot, ezekről már én is megemlékeztem. Sajnos egyik sem jó igazán, mivel egyiknél sem tudunk építeni arra, hogy korrektül támogatott lesz még legalább 2-3 évig. Egy dedikált szerverről beszélünk amúgy, egyetlen éles, nagy látogatottságú site-tal, szóval elég csak egy PHP verzió.

No, azért deb csomagokban is sikerült ordas baromságokat csinálni, egyik-másik karbantartónak hála... Ha félsz, akkor nézd össze az upstream meg a remi-s forráskódot, és utána buildelj magadnak csomagot ez utóbbiból. Vagy akár lehet az upstream forrásból is sk. csinálni csomagot magadnak :-P

Köszi, ez tetszik, de kizárt, hogy fizet annyit az ügyfél, hogy ez megérje nekünk, tekintve, hogy ez az egyetlen éles, ügyfeles CentOS szerverünk. :(

"HardenedPHP comes with CloudLinux OS, but it can also be purchased as a stand-alone offering if you have more than 100 CentOS servers"

Az egész CloudLinux OS 3000 Ft / hó körül van, nem ér meg annyit az, hogy itt support van mögötte és nem 1db fejlesztő? Meg a HardenedPHP mellett persze jár vele egy csomó más jóság.

Disclaimer: CloudLinux partner hosting cégnél dolgozom. Mi úgy lettünk partnerek, hogy azonos problémakörre kerestük a megoldást, néztük mi is a Remi-t, IUS-t és aztán végül ügy döntöttünk, jó lesz a CloudLinux, a havidíjért cserébe jó terméket kapunk és így jó szolgáltatást tudunk adni az ügyfeleinknek.

( zeller | 2018. 09. 28., p – 17:47 )

"a szerveren napi szinten használt phpmyadmin is legalább 5.6-os PHP-t igényel már évek óta." - gondolom targiziből felpattintott verzió, mert rpm-ben 4.4.15.10-van (EPEL), az meg vígan elvan php(language) >= 5.3.7 függőség okán azzal, ami standard repóban megtalálható (jelenleg valami php-common.x86_64 5.4.16-45.el7).
Nálam Moodle miatt jött elő a probléma, én bevállaltam a remi-t, igaz, nem publikus szolgáltatás alá kell, úgyhogy kevésbé problémás, ha esetleg akadozik a hibajavított verziók kiadása.

( Sixday v | 2018. 10. 19., p – 16:10 )

van barmi indokod arra hogy miert nem tudod behajitani az egeszet egy kontenerbe?

Volt szerencsém szívni konténer és perzisztens adattárolsá témával, meg olyan konténerrel, ami elvileg hivatalos forrásból érkezett, de aztán a fejlesztő (LOL, inkább gányoló iparos) totál agyonvágta egy rakat inenn-onnan behúzandó, az eredtinél régebbi/egyedi buildes komponenssel. Az, hogy a fejelsztő nem hajlandó csak adott verziójú sw-stacket hasnzálni, az már bocs, de egyéni szoc. problem: a megrendelő megmondja, hogy mit és milyen környezetben szeretne csinálni, és arra adjon a fejlesztő megoldást. A következő az lesz, hogy ugyan Linuxod van, és LAMP stackre kéred a fejlesztést, de a feljesztő igényei alapján egy SQL-szerver+IIS kombóra készül el a motyó?

Nem teljesen értem, hogy az miben oldaná meg a problémát. Egy dedikált bérszerverről beszélünk, egy db ügyfél egy db (komplex, nagy terheltségű) weboldala fut rajta. Ha konténerben fut, ha nem, a PHP-t szerintem mindenképp "illik" patchelgetni. Van persze több védelmi vonal is a szerveren, amik jó eséllyel már azelőtt megfognának egy esetleges támadást, mielőtt az eljuthatna a PHP feldolgozóig, de nem hinném, hogy ez felmentést adna a csomagok frissen tartása alól.

Pont az az egész konténeresdinek a lényege, hogy tök mindegy, hogy CentOS7 fut, lehet a base systemed egy Ubuntu, amihez mondjuk van friss PHP csomag.
Letöltöd a hivatalos PHP image-t (például Docker konténerezés esetén: https://hub.docker.com/_/php/), futtatod és kész, van egy totál friss, hivatalos PHP-t futtató konténered. Tök mindegy, hogy te most CentOS 7-et, Ubuntu Servert, Fedora Atomic Hostot, vagy mit használsz a hoston.
Így akkor is lesz friss PHP-d, ha éppen az adott disztribúciód PHP csomag maintainere nem készítette még el a csomagot, ez a konténerezés egyik előnye.
Ha pedig módosítani akarsz magán a konténer tartalmán, azt is megteheted, ott vannak a Dockerfile-ok, hogy miként épül fel az image. Módosíthatod, ha szeretnéd, meg ki is egészítheted, ha szeretnéd.

Ácsi. Ha letöltöd a frisset, és abból épül a konténer. Azaz egy újabb kupac frissítését kell kézben tartania valakinek - és konténerben szállított motyó esetén ez a fejlesztő szokott lenni, aki általában ellenérdekelt a működő komponensek frissebbre cserélésében, ergo simán behúzza a számára megfelelő, akár lukas verziót is a konténerbe, és annyi - üzemeltetőként, az adatok biztonságáért felelős rendszergazdaként nincs sem rálátásod, sem ráhatásod arra, hogy mi kerül oda.
Plusz kapsz még egy réteget, amit tutujgatni kell, csak azért, hogy a fejlesztú uraknak kényelmesebb legyen, és saját, általában disznó mód perverz ízlésüknek és kényüknek-kedvüknek megfelelő szoftverkuapcon tudjanak "fejleszteni".

Vannak "OFFICIAL REPOSITORY" kategoriaba tartozo Docker image-k, amely azt jelenti, hogy
In many cases, the images in this program are not only supported but also maintained directly by the relevant upstream projects.
For some, they're developed in collaboration with the upstream project (or with the explicit blessing of the upstream project)
In all cases, we strive to create images that are true to the upstream project's vision for how their project is intended to be consumed, occasionally adding additional behavior to make them more friendly to use within Docker / containerization in general..

Miben masabb ez, mint az Ubuntu, Debian, Red Hat, Fedora, CentOS, Slackware, stb. altal szallitott csomagok?

Sic Transit Gloria Mundi

A konténerbe a fejlesztő azt rámol bele, amit akar, meg amit nem szégyell (vagy még azt is, abban bízva, hogy senki sem nézi meg...), és jó kérdés, hogy ez mi, illetve hogy milyen módon jönnek a frissítésekről, sérülékenységekről infók, illetve hogyan, milyen módon lesz a sérülékenység javítva, netán backportolva a javítás, ha épp olyan adódik.
Egy statikusra fordított binárisban bőven elfér egy lukas lib, amit csak akkor veszel észre, ha megnézed, miből és hogyan készült - javítani a fejlesztő nélékül nem tudod.

Valami kovacsbela fejleszto altal feltoltott image-t en sem hasznalnek. A kerdesem inkabb arra vonatkozott, hogy az Official image-k mennyire tekinthetoek ugyanolyan kategorianak, mint a kulonbozo disztribuciok altal szallitott csomagok. Termeszetesen a fizetos tamogatassal rendelkezo disztribuciok mas kategoria, de egy CentOS-hez kepest miben megbizhatatlanabb ez? CentOS eseteben is az adott csomag karbantartoja olyan utemben frissiti a csomagot, ahogy jonak latja, es ha meg frissiti is, nincs garancia, hogy a hozza tartozo fuggesegek naprakeszek, es nincs koztuk lukas lib. Azt backportolnak, amit jonak latnak, es ugy patchel-ik, ahogy jol esik nekik, mert maskent nem mukodik egyutt jol a renszerrel.

Teves az a parhuzam, hogy az Official image-k a disztribuciok altal szallitott csomagoknak felelnek meg, mig a kovacsbela image-k pedig a kulso repoknak?

Sic Transit Gloria Mundi

1. ne hasznalj xy kutyafule-tol szarmazo kontenert, hanem csak hivatalosakat
2. ha meg a hivatalosban sem bizol akkor a hivatalosaknal mindig elerheto githubrol a Dockerfile, olvasd el, tolsd le es buildeld magadnak az image-t.
3. frissites meg annyi hogy ha kijon az uj verzio akkor destroy-olod a regit es inditod az uj baseimage-n alapulot, ez kb. 2 parancs es 10 masodperc (mivel termeszetesen az adat mappakat bind mountoltad a hoston igy magaban a kontenerben nincs olyan adat amiert nem kar).

ejj a regi jo begyoposodott rendszergazda mentalitas, nem erti igazan hogy mukodik az egesz (csak azt hiszi) de a kurva nenikejet a fejleszoknek! Epic :)
Mentsegedre legyen mondva hogy 5 eve en is pont ilyen voltam, nem egyszeru a mentalitasbeli valtas, meg nagyon sok uj dolgot kell tanulni, de hidd el megeri.

Elég sok sz@r buildet láttam már ahhoz, hogy kimondhassam, a fejlesztő jellemzően csak addig szereti a legújabb verziót" hasnzálni, amíg nem kell frissíteni azt, akkor kiderül, hogy n+1 dolog miatt maradjon inkább a régi. És tök mindegy, hogy OS-hez tartozó gyári, vagy más, 3rd party repó, vagy épp dockerhub. Konténer esetén vagy van esélye az üzemeltetőnek belelátni/beleszólni, hogy milyen szemét fut a gépen, vagy sem. Általában ez utóbbi. Innentől kezdve szoktam mondani, hogy akkor tessék, ott a nyers vm, üzemeltesse a fejlesztő, ha a lovon fordítva ülést műveljük, azaz a szállító diktál, hogy milyen szoftverkörnyezetet szeretne a megrendelőnél látni, nem pedig fordítva.

pont az egesznek konteneresdinek ez a lenyege!
kijon az uj php verzioval szerelt hivatalos kontener, onnantol neked kb. 10 masodperc mire lecsereld a meglevot az ujra, es kesz a frissites.
OS fuggetlen a teljes futtatokornyezeted, igy nagy ivben tojhatsz ra hogy az altalad futtatott OS milyen csomagokat ad/tamogat.

"onnantol neked kb. 10 masodperc mire lecsereld " - a teljes alkalmazás beletolásával együtt? Akkor is, ha a fejlesztő explicit kijelenti, hogy neki az x.y.z verzió kell, az újabb nem jó/nem tesztelt? Miközben az OS-hez adott x.y.z-be meg legrosszabb esetben backportolják a javítást, ha szükséges.
"nagy ivben tojhatsz ra hogy az altalad futtatott" - fejlesztőként nagy ívben le lehet tojni, hogy a megrendelőnél milyen sw-környezet van. Majdnem úgy, mint amikor Windows-only környezetre úgy adnak egy alkalmazást el, hogy "tégy alá egy komplett cygwin-környeztetet, majd CPAN-ból húzz le csillió+1 Perl modult". Egyik sem menedzselhető jól a fejlesztő nélkül, aki meg az esetek 9x%-ában ellenérdekelt abban, hogy akár az OS-általa dott, akár a konténerbe rakható csomagokból frissebb/más verzió kerüljön felhasználásra, mint amit ő szeretne.