CentOS-6.0 Continuous Release tároló

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A CentOS projekt bejelentette a "CentOS-6.0 Continuous Release" ( CR ) tárolót, amely elérhető a mirror.centos.org-on. Ebben a tárolóban azok az rpm-ek érhetők el, amelyek majd elérhetők lesznek a CentOS 6.1-ben. Mire jó ez? Az LWN szerint arra, hogy azok a CentOS 6.0-t futtató emberek, akik július óta biztonsági frissítések nélkül vannak, most végre hozzájuthatnak a "frissítések legtöbbjéhez" anélkül, hogy meg kellene várniuk a 6.1 kiadását. Mivel ez a repó fontos biztonsági- és hibajavításokat tartalmaz, a CentOS projekt minden 6.0 felhasználónak erősen javasolja a használatát. A CR repository-ról bővebb információk érhetők el itt. Még több részlet itt.

( bogolyandras | 2011. 09. 27., k – 22:30 )

Most akkor a CentOS 6.0 -hoz (körülbelül) a kiadás óta nem érkezett biztonsági frissítés, vagy én értek valamit félre?

( kisg v | 2011. 09. 28., sze – 08:20 )

Lefordítom magyarra: Akinek egy ici-picit is fontos, hogy ne törjék meg a gépét, vagy bármi fontosat akar csinálni vele, az ne használjon CentOS-t.

Ezek után milyen opciók maradnak:
- RHEL6 self-service licenc: nem is olyan sok az a 350 USD/év, ha csak egy db. szerverről van szó. Persze ha többről, akkor nagyon drága is lehet.
- Scientific Linux: A CentOS után bízunk abban, hogy (sarkítva) pár kutató majd minőségi disztrót fog gyártani?
- Fedora, nem LTS Ubuntu: túl gyorsan megszűnik a támogatása, "perpetual béta" mód
- Ubuntu LTS: Azután, hogy a 10.04 LTS karbantartási ciklusban eddig már 2 óriási hibát elkövettek, csak azokban a feature-ökben, amiket mi használunk (olyan "ritkán használt" komponensekben, mint az LVM, GRUB vagy az LXC), maximum VM-ben vagyok hajlandó szerveren futtatni.
- SLES, OpenSUSE: eddig sokat nem foglalkoztam vele, de ha fizetős irányba megyünk, akkor az RH-val már van tapasztalat, nincs értelme váltanunk. OpenSUSE-val meg ott vagyunk mint a Fedora-val.
- Debian: bár elévülhetetlen érdemei vannak (rengeteg támogatott arch, a stable verziók relatíve stabilak), a tervezhetetlen release folyamat és az emiatt gyorsan elavuló stabil release-ek miatt nem szívesen váltanék vissza Ubuntu-ról.
- Nem mainstream disztrókat (Arch, Frugalware, Gentoo ... stb.) nem akarunk használni.

Ha az Ubuntu megbízható minőséget szállítana az LTS release-ben, akkor az lenne a preferált, mivel desktopon úgyis azt használjuk (igen, LTS-t, nem a félévente érkező béta release-t). 10.04-ben ez nem sikerült, reméljük sikerül nekik 12.04-ben végre.

Ki milyen disztrót használ ezek után (belépő szintű) szervereken?

Üdv,
Gergely

> Ubuntu LTS: Azután, hogy a 10.04 LTS karbantartási ciklusban eddig már 2 óriási hibát elkövettek, csak azokban a feature-ökben, amiket mi használunk (olyan "ritkán használt" komponensekben, mint az LVM, GRUB vagy az LXC)

Mikre gondolsz konkretan?

Nem ertem egyebkent, ha volt 2 hiba, amit kijavitottak, akkor most mar jo, nem? Az LTS-hez amugyis ugy all az ember, h ha teheti, var vele min. fel evet, amig felrakja, annyi ido kell neki, mig relativ stabilra hozzak.
Nem ertem egyebkent, mi a garancia, h a 12.04-ben nem jon elo vmi, csak mert mondjuk 1 evig nincsen.

Szoval olyan a dolog, mintha a lo masik oldalarol tekintenel ra egy kicsit.

En az Ubuntu LTS + PPA + nem LTS kiadasokkal elvagyok, de egyebkent van minden, mint a bucsuban:)
A hujesege mindegyiknek megvan, jobb hihan egyutt kell vele elni.

tompos

Konkrét hibák:
- Rendszer nem bootol, ha LVM-ben van egy snapshot (elvileg Grub hiba). Javítás tudtommal nincs.
- A 2.6.32-33-as kernelben egyszer csak az LXC containerek nem működnek. Javítás tudtommal nincs, workaround hogy backportolt maverick kernelt használsz = NVIDIA driverek nem működnek, csak ha kézzel rápatkolod + az nem hosszú karbantartású fa mint a 2.6.32, tehát effektíve buktad az LTS-t.

Launchpad ticketek vannak természetesen, nem is én jelentettem, hanem elég sokaknál előjöttek.

Ezek szerintem egy szerver OS-nél kritikus hibák, amiket nem megfelelően kezelnek.

Üdv,
Gergely

Ezt az LVM-es dolgot nem ertem, plane nem fogom kiprobalni:)
Ha van a root (/boot particiojarol) particiodrol egy snapshot, akkor nem bootol a rendszer? Eleg ratyi:)

LXC: Igen, kerleltek a maintenereket, h ne igy legyen, ki9kapcsoltak asszem a network namespace-t, ki tudja miert. Azert ezt visszakapcsolhatja maganak az ember. Persze eleg gaz ettol meg, foleg, h menet kozben valtoztattak a felallason. Vagy legalabb csinalhattak volna egy lxc agat vagy akarmi. Mindenesetre ezzel en ugy vagyok, hogy ahol LXC van, ott igy is ugyis ujabb kernelt hasznalok lehetoseg szerint...:)

Az nvidia driverek nekem mukodnek (kopp-kopp), legalabbis a userek nem panaszkodtak emiatt meg szerencsere, apt-get upgrade segitsegevl szoktam frissiteni es annyi. Errol bovebb informacio?

Szoval ezek szerintem egy szerver OS-nel kevesbe kritikus, de annal cikibb hibak, amik leginkabb akkor tudnak galibat okozni, amikor pl. rebootolsz, tehat egyszeri, nem a folyamatos mukodest befolyasoljak. Akkor persze nagyot es megakasztjak rendesen a mukodest.

tompos

Még a CentOS is, aki egyébként a legkisebb HDD-re is (10GB) LVM-mel akar vacakolni, a boot partíciót külön teszi.
Majd ezután kreálja az LVM-et amire a root kerül.
Eszembe nem jutna lvm-re rakni a legérzékenyebb pontját a rendszernek. RAID-1 raid-autodetecttel untig elég. Majd ha a kernel megtalálta magát meg a rendszert, jöhetnek a nyalánkságok :)

Értem a kérdést, és el is tudom fogadni, de én más oldalról közelítem meg a kérdést:
Mi szól /boot esetén az LVM mellett? A növelhetőség? 3. alkalom után már kb mindenki meg tudja saccolni mekkorát érdemes /boot -nak választani.
Tehát _szerintem_ nincs szükség /boot esetén ilyen extrára, hogy +1 réteg legyen a vinyón (LVM->FS).

Ha nem használjuk azt amire nincs szükség, csökken a hibalehetőségek száma. - Szerintem.

A / RAID1-en volt mindig is. Korábban mindkét vinyó elejéből lecsíptem, grubot felraktam külön és ha frissült a kernel, átmásoltam a másikra is, ha nem felejtettem el.
A /boot RAID1 miatt ezt sem kell, elég egy grub-install /dev/sdb beállításkor.
Ha kiesik az első vinyó (volt rá példa), gond nélkül bootol a másikról és feláll a rendszer.

Nem írtam, igaz, ezt szervernél szoktam. Otthon nincs raid, csak backup vinyó:)

Az Ubuntu viszont a default telepítésben nem rakja külön a /boot-ot, akkor sem, ha RAID1-be teszed a hdd-t. Tehát ez egy default telepítésben levő bug az LTS release-ben, amire a megoldás, hogy maverickben már javítva van...

A hiba kritikusságát nem befolyásolja szerintem, hogy _nálam_ éppen nem kritikus rendszeren, hanem egy fejlesztői szerveren jött elő, így "csak" néhány órányi állásidőbe került, ami persze továbbra is pénzben kifejezhető veszteség...

Nem beszélve arról, hogy ezentúl nem bízom az Ubuntu tesztelési és release folyamatában.

Ubuntueknal ket dologban nem szabad megbizni: a kernelben, es minden masban. Az Ubuntu Server egy vicc, semmi kulonbseg nincs az Ubuntu Desktophoz kepest, es ezt tessek betu szerint erteni: igen, a minoseg is pont ugyanolyan. Ganyolasok zsakszamra, kernelpanikok es dogledezo szerveralkalmazasok szegelyezik az utat, amerre jar. Ja, es mindez LTS-en, a tobbibe ugy igazabol nem szoktam merni belegondolni.

Lehet, hogy csak en vagyok peches, de szerverre biztos nem raknek Ubuntut. Desktopra eddig azt mondtam, hogy igen, de a Gnome/Unity lepes ota megint kerdojeles lett a rendszer.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hat valtozatos, sokszor reprodukalhatatlan problemakrol van szo. A kernellel mindig van valami nyug, itt-ott kernelpanik, itt-ott oops-okkal hanyja tele a kmesg-et, de volt mar parszor nem mukodo hardver is, ami mas disztro alatt hasonlo verzioju kernellel ment.

Ami upstart-ba kerult be, abbol nehez kinyerni, hogy eppen mit hajt vegre, ha egy upstartos cucc nem indul, nagyon nehez megmondani, hogy milyen parameterezessel indult be. Ez mondjuk a systemd-s disztrokon is igaz, ha lehet, kerulom mindkettot messzire.

Grub2-nel folyamatosan valtoztatjak a grub.cfg formatumat, xen alapu virtualizacional folyamatos gond volt (es ma is az), hogy a pygrub sokszor keptelen megbootolni a gepet, egyszeruen azert, mert az ubuntu fejlesztoi menet kozbeni update-kent ugy dontenek, hogy megse jo az a formatum, ami mindenki masnak amugy igen. Eleinte ez csak maverick-kel volt baj, de kesobb jott elo ilyen lucidos gepnel is, szerencse, hogy az update-grub -ot nem surun futtatom, es akkor amugy is ott vagyok a gep mellett, mert akkor kernel frissul.

MySQL es Apache eseteben is voltak rejtelyes halalesetek, amire semmi erdemi infot nem sikerult a rendszerbol kinyerni. Szerencse, hogy ezek csak egy teszt virtualis gepen jottek ki, de a mai napig nem tudom, hogy miert voltak.

Meg ilyen kedvessegek. Ezek onmagukban, egy-egy problemakent kicsik, de ha sok ilyen apro pici van, akkor az ember meggodnolja, hogy mennyire jo is a QA a Canonical berkeiben.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Debian, mert az oldstable is supportalt a stable megjelenese utan meg egy evig (avagy lenny 2012 junius vegeig). Ami azt jelenti, hogy kb 3 ev support van egy stable releasere, ami szerintem nem rossz. Es van az embernek egy eve atallni a kovetkezo stablere, ami ketevente azert megoldhato, szerintem.

Raadasul mostansag time based freeze iranyaba mennek, ami ha nem is sokat, azert valamit megis javit a release tervezhetosegen.

--
|8]

... bármi fontosat akar csinálni vele, az ne használjon CentOS-t.
Léteznek programok amik RHEL-t kívánnak, mondjuk RHEL 6-ot és tesco gazdaságos módban elfutnak a CentOS és SL rendszereken, másra viszont rágörbíteni kellene.

- Scientific Linux: A CentOS után bízunk abban, hogy (sarkítva) pár kutató majd minőségi disztrót fog gyártani?
Az alap mindkét esetben a RHEL, tehát a disztro minősége függ az alapanyagtól is. Viszont a CentOS és az SL között annyi különbség van, hogy a CentOS mondjuk hobbi projekt, az SL mögött viszont állnak ezzel munka szinten foglalkozó emberek és hozzá van egy konkrét felhasználói tábor, meg esetleg valamifajta ellenőrzés mögötte. Gondolom ennek is köszönhető, hogy az SL 6.1 jóval korábban megjelent a CentOS-nél és valószínű a frissítések is követik a RHEL frissítéseket.

Az is érdekelne, hogy Te milyen disztot használsz vagy ajánlasz, bár gondolom Ubuntu ("nem szívesen váltanék vissza Ubuntu-ról") lesz a megoldás.

- RedHat és SLES (OES) abban a percben kapja kia tárolókat amint lejár, az áruk rendkívül magas, helyette inkább mást használunk, ahol lehet.

- Opensuse, jó kérdés, sokan nagyon szeretik.

- Ubuntu LTS verziók minőségével egyetlen gondom sem volt.

- Centos esetében ez így igen kellemetlen, az SL-t még nem próbáltam, érdekelne valakinek a tapasztalata.

"- RedHat és SLES (OES) abban a percben kapja kia tárolókat amint lejár, az áruk rendkívül magas, helyette inkább mást használunk, ahol lehet."

Mivel ezekért fizetni kell, teljesen jogos, hogy aztmondja holnapig, akkor holnapután már nem lesz elérhető. Általában előre szoktak szólni, hogy hahó, le fog járni a támogatás. Ha határidőig nem tudtál váltani, tebajod...

"- Opensuse, jó kérdés, sokan nagyon szeretik."

Desktopra jó, szerveren messzire elkerülöm...

Többivel egyetértek...

( blasius1 | 2011. 09. 28., sze – 14:11 )

Engem is érdekelnének a Scientific Linux tapasztalatok; én is CentOS-t használok, de az utóbbi időben egyre jobban fontolgatom a váltást.

Nekem jo tapasztalataim vannaka a CentOS-sel, ha az ember nem akar feltetlenul mindenbol ujat. Mert ha igen, az necces. A Ruby regi benne, a PHP ugyszint, a MySQL-rol es az Apache-rol nem is akarnek megemlekezni e helyutt. Viszont ami benne van, az atomstabil, en CentOS-t dogleni nagyon ritkan lattam, es akkor is valami hw nyug volt a hatterben.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal