Centos 7 - naprakész csomag tároló.

Linux-haladó

Sziasztok!

CentOS 7-hez keresek olyan csomagtárolót amit valamennyire hivatalosnak vagy megbízhatónak lehet tekinteni.

A következő helyzet állt elő:

A gyárilag engedélyezett tárolóban (plus epel) PHP 5.4.X található ami nem támogatott ág a PHP részéről.

SCL-ben ami hivatalosnak tekinthető, rh-php56-php pontosan PHP 5.6.5 ami egy támogatott ág csak régi verzió, az aktuális 5.6.25.

Picit félek a harmadik személyek által karbantartott tárolókat használni, még azt is amire Ők maguk hivatkoznak:

https://wiki.centos.org/AdditionalResources/Repositories

Vagyis Ti hogy tartjátok frissen a saját rendszereiteket?

Köszi a válaszokat!
Oli

  • 1785 megtekintés

Köszönöm a válaszokat. Elszomorító a helyzet.

Egy LAMP összerakása két nagyságrenddel nagyobb mókolás mint Ubuntun.

Tudom. Ezért is hanyagoltam régebben és csak Ubuntut használtam, de sajnos most kénytelen vagyok. Viszont azért évekkel ezelőtti csomagokkal nem tölteném fel a rendszert csak azért hogy menjen és amiket majd éles környezetben kell purgálni.

Arról nem is beszélek, hogy dist upgrade nincs CentOS 6-ról 7-re.

Nem tudok olyan élethelyzetet amikor a CentOS indokolt lehet egy Red Hat kompatibilitáson kívül.

nézd, az rh arról szól, hogy nem kell kétévente mindent nagyprojektben minden szart migrálni, mert major OS upgrade van, hanem a karbantartott ágon hosszan megy nagyjából ugyanaz (van, amiből csúszik be frissebb, mert olyan az upstream, de a nagy szopásokat azért el lehet kerülni). Ez azzal jár, hogy meglátod a verziószámot, és rosszul leszel, meg hogy a csudifriss mindenféle időnként nincs. Ilyen szempontból elég debian stable ez is egyébként, kb 3.5 éves release ciklus, a vége fele nyilván nem a legjobb, bár ők azért a pointreleaseekkel tolnak bele új dolgokat.

Friss phpre nem feltétlen ez való, őszintén szólva az alapján, amit lent írtál (gyak minden amit használsz más tárolóból) nem centosra kell összerakni, jobban jársz valami normális disztróval, amiben alapból benne van, ami neked kell.

Ha meg kifejezetten ezt kérték, akkor érdemes kérdezősködni az ilyen külsős tárolókról, nehogy meglepetések érjenek átadáskor, mikor közlik, hogy arról biza szó se lehet.

Köszönöm. Végre inden a helyére került.

Utánanéztem a Red Hat backport policy-nek és megnyugtató. Nem tudtam róla, azért vert le a víz. Vagyis ha nincs funkcionális oka a frissebbnek akkor nincs ok frissíteni. A külső tárolókat elvetettem. Nagyon nem bízom benne mert azokra nincs semmilyen jogköre sem a Rad Hat-nek sem a CentOS-nak vagyis gyakorlatilag warez ami attól még lehet minőségi mint az ncore, de akkor is egy ismeretlen forrás, hiába van aláírás a csomagokon.

Egyedül a szoftver fejlesztőjének tárolóját tekintem hivatalosnak a disztribúció tárolóján kívül. Így lett friss mysql ami tökéletesen működik és integrálódik a rendszerbe.

"Vagyis ha nincs funkcionális oka a frissebbnek akkor nincs ok frissíteni."
Igen, gyak így van.

" gyakorlatilag warez"
Ez hülyeség nagyon szerencsétlen hasonlat. A külső tárolóval az a baj, hogy fogalmad sincs, mi van benne, hogy mennyire értelmesen kezelik a secu patcheket....

"Egyedül a szoftver fejlesztőjének tárolóját tekintem hivatalosnak a disztribúció tárolóján kívül. Így lett friss mysql ami tökéletesen működik és integrálódik a rendszerbe."
... és hogy mennyire fostalicska, amit egyébként integráció jelleggel csinálnak. Itt ráadásul az ilyen gyártói izék (nem kifejezetten a mysqlről beszélek, hanem úgy általában) veszélyesebbek, mint valami extra repo, mert míg az utóbbit ált valaki olyan csinálja, aki centost használna, csak hiányoznak a normálisan hozzácsomagolt cuccok, az utóbbit a gyártó, akinek nem feltétlen van fogalma az összes disztró ügyesbajos hülyeségeiről, vagy akar vele foglalkozni, aztán jön a jó lesz ugyanaz a fostalicska initscript mindenhova.

Igaz, de inkább úgy fogalmaznék, hogy valami van ami balról jobbra csíkokat húz.

CentOS esetén csak összedőlt rendszerek képződtek ez után, egyetlen egyszer sem sikerült és alapvetően fapad rendszerek voltak. Valahogy semmi se volt a helyén, így maradtam a tool készítőinek ajánlásánál, miszerint - clean install.

Kinek mi az elszomorító :D
Én pont amiatt tértem át mert hosszú a támogatás. Kb 2 hetet tudtam csak leállítani debian 3.1 es LAMP szervert. Amiben 4.3.x es php volt. Azt is csak miután már erőszakkal lekapcsoltuk és kész, mert az életbe nem frissítette volna az oldalát :D

Szóval tapasztalatom szerint nem olyan nagy hátrány hogy nem a legújabb php forog fent :D

Persze megint más ha fejlesztői LAMP szerver ott jól jöhet. Hostingnál a legtöbb user 1x megcsináltatja a honlapot
és utána szarik rá, aztán X év után bottal se piszkálja már senki, nemhogy akkor kicserélni alattuk mondjuk a php-t, mert mondjuk jönne egy dist upgrade.

Fedora 23, Thinkpad x220

( freeoli v | 2016. 09. 14., sze – 14:55 )

Köszönöm mindenkinek.

Első körben még korábban httpd24 rh-php56 rh-php56-php rh-mysql56-mysql csomagokkal kezdtem ténykedni és rosszul lettem amikor megláttam a verziókat, ekkor kezdtem itt kérdezősködni.

MySQL a MySQL tárolójából.
HTTPD-t a base/updates tárolból.
Ehhez php56-ot a REMI tárolójából szereztem be.

Szerencsére az rh csomagoktól eltérőn nem az /opt alá települnek és a mod_php és megfelelően működik az alapértelmezett 2.4.6-40-es httpd-vel.

( csardij v | 2016. 09. 14., sze – 15:02 )

Helló,

Red Hat (és így centosban is) még vagy 10 évig támogatott a PHP 5.4, amit kell ők backportolnak.

MikroVPS | 50% kedvezmény VPS-re HUP50 kuponnal

( hokuszpk | 2016. 09. 14., sze – 16:54 )

a php56 -ot az ius repobol hasznalom, eddig nem volt vele problema, most az 5.6.25 kaphato naluk ha jolemlexem.

Az EPEL az egyetlen olyan tároló, amit a Red Hat megtűr olyan szinten, hogy ha látja, hogy vannak fent a gépen EPEL-ből csomagok, akkor sem dobják el két felemelt kézzel a support ticket-et, mondván, hogy "not supported system", ami más egyéb tárolónál azért simán bejátszik. De ez csak a RHEL-nél volt érdekes, mert régen a CentOS-hoz nem volt kereskedelmi support. Mondjuk ha CentOS-hoz veszel egy kereskedelmi support-ot, és egy hiba kapcsán meglátnak egy REMI vagy más egyéb repo-t nem tudom, hogy mit szólnak hozzá. Ilyenhez nem volt még szerencsém.

( opt | 2016. 09. 17., szo – 11:41 )

A Docker nem lehet jó megoldás a PHP problémára?
Azaz lenne egy konténer olyan verziójú Apache, php kombóval, amire szükség van?