CentOS 8

A CentOS projekt bejelentette a CentOS 8 elérhetőségét, ami a Red Hat Enterprise Linux 8.1 forráskódjából áll elő. Részletek a bejelentésben. Kiadási megjegyzések itt.

Hozzászólások

En azt remeltem, hogy a RedHat-tel valo osszebutorozas gyorsabba teszi a RHEL koveteset, de ez igy most kb 3/4 evig tartott a RHEL 8 release-hez kepest... :/

Még mindig az újratelepítés az egyetlen járható út CentOS-éknál, ha valaki verziót akar frissíteni?

digitális kintszülött

7-ről 8-ra? Részemről a jelentős változások okán inkább /etc mentés és adatok (/home, /srv, /opt ilyesmi)  nem piszkálása (ugye ezek illendően külön logikai köteten csücsülnek) és újratelepítés a bevett szokás - elvileg több meló, gyakorlatilag kevesebb szívás. Természetesen a kritikus alkalmazásokat tesztkörnyezetben meg kell "nyomkodni", hogy működni fognak-e a nyolcason is.

A hosszú support/életciklus okán nagyon sok főverziót is ugrik 7-8 között egy rakat komponens, amit nem biztos, hogy a régi konfig öröklésével biztonságosan meg lehet frissíteni.

... /home, /srv, /opt ilyesmi)  nem piszkálása (ugye ezek illendően külön logikai köteten csücsülnek)

 

Ez ma mar egy kicsit meghaladott szeritnem. En egyre tobbszor kerem, hogy a gepeinken egyetlen particion legyen minden. Tipikusan ma mar egy gep egy szolgaltatasra van, ugyhogy nincs olyan, hogy az egyik szolgaltatas/user betolti a lemezt es emiatt a masik nem megy. Viszont a tobb particioval/volume-mal csak tobb macarea van, raadasul barmelyik betelik ugyis megall az egesz gep(en futo egyetlen szolgaltatas).

Persze bizonyos kornyezetekben meg mindig kellhet a tobb particio, de egyre tobb helyen ma mar jobb anelkul. Ez a konzervativ gondolkodas amugy nalunk is jelen van/volt, kellett gyozkodnom embereket, hogy jobb lesz ez igy, mert ok is az "illendo" utat akartak valasztani.

Majd ha beáll a géped, minta faszög, mert az auditd sem tud logolni már, annyira telefosta a rendszert egy rosszul megírt alkalmazás, akkor másképp fogod gondolni - ez az egyik. A másik, hogy frissítés esetén nyugodtan letakarítható az OS, mert az adatok tőle független területen vannak. A harmadik, ami virtualizált környezetben szokott jól jönni, az az, hogy a data diszket oda tudom pattintani, ahova épp kell, ott tudom a helyet növelni, ahol szükséges.
Sok előnye van a szétválasztásnak - az egybeömlesztésnek maximum annyi, hogy a lustaságot támogatja. Nálam van /, /var, /var/log, /var/audit, /opt, /home, /boot, illetve ha DB, akkor annak az adatterülete is külön van, a dump/backup dettó.

Nem az auditd szokta felzabálni a helyet, hanem mondjuk egy maga alá rottyantó Java-s "alkalmazás", ami olyan mennyiségű logot képes kiokádni magából, ha nincs minden rendben, hogy az ember csak néz ki a fejéből... És hiába szól a monitoring, hogy fogy a hely, attól még nagyon nem jó, ha az xyz alkalmazás ilyen szinten meg tudja borítani a rendszert. Ezért nem tartok pl. alkalmazáslogot (jellemzően Java...) a /var/log alatt. Az a rootvg része, azt tessen nem bactatni - a datavg-ben lévő mondjuk optlv (/opt) alatt a /kot/alkalmazas/log könyvtárban tökéletes helye lesz - ha telerottyantja, hát így járt...

A /usr nincs külön. A /home van külön (külön VG is akár), a /var van külön, a /var/log van külön, illetve a /var/log/audit van külön.
A /-től különválasztott home: A /home adat, nem a rootvg-ben a helye - ha telemegy, akkor ne a rootvg-t, vagy oldschool lvm.gyűlölőknek ne a / alatti partíciót kelljen bactatni.
A /var és az alatta lévő területeket a /-ról logikailag leválasztani azért célszerű, hogy a / ne menjen tele se egy alkalmazás elszabadulásakor (/var alatti könyvtárát írja tele), se egy frissítéskor (Letöltés a /var alá, telepítés a / alá), és ha kell, akkor a mérete menet közben növelhető, míg ha a / része lenne, akkor az picit nyűgösebb dolog ugye...
A /var/log az, ami gond/hiba esetén tele tud menni - leválasztva nem a rendszer többi részétől fogja elvinni a helyet ilyen esetben (ha logolás nem megy, az kisebb baj, mintha a DB nem bírja kiírni a dolgait, mert nincs hely).
A /var/log/audit elkülönítése ott fontos, ahol az auditd beállításaiban az auditd logját tartalmazó terület elfogyására single vagy halt action van beállítva - de máshol is hasznos, ha az auditd "nyugodtan" tudja akkor is írni a logját, amikor a /var/log például már megette a diszket.

Ahogy mondtam, ezeken a gepeken egy szolgaltatas van, ha valami megall minden megall ugy is. VM-ek vannak persze es LVM-et hasznalunk, ugyhogy ha kell oda tudok "pattintani" egy kis disk space-t ha kell (az egybe particio miatt az meg oda megy ahova kell).

A szetvalasztas hatranya, hogy 1 (2, a /boot-tal egyutt) helyett N particiot kell monitorozni, N particio telhet be, vagyis paradox modon a nagy ovatossag hatasara megno az eselye annak, hogy megall a szolgaltatas. Aztan meg N particiot kell tulmeretezni, hogy azert beleferjen akkor is ha... vagyis a VM is nagyobb lesz.

De ne erts felre, nem azt mondaom, hogy hulyeseg a sok particio, hanem azt mondom, hogy van olyan helyzet amikor nem kell (es az en kornyezetemben pont egyre tobb ilyen van).

A hány partíciót kell monitorozni érdekes kérdés - egyet, vagy többet - sokszor szükséges forecastolni adott könyvtár méretének a várható növekményét, ott egyszerűbb külön kötetként kezelni. És megint csak nem mindegy, hogymitől megy tele a diszk, mitől áll meg a szolgáltatás: Saját magától (alkalmazáslog), vagy OS-log (hardverhiba, hálózati toszkolódás, egyéb syslog-hizlalda), satöbbi. A / növelése még lvm-es esetben sem triviális, van olyan állapot, amikor egy megállás khm. jelentős gondot okozhat.

Nem fogalmaztam egyértelműen, bocs. Ha egy diszked van, amiben mondjuk a 2. partíció van pv-ként a /-t tartalmazó VG alá PV-ként berakva, és a teljes terület ki van osztva (mert "fogyott a hely"), akkor első körben vagy partíciót növelsz a diszk vmware-ben történt növelése után, ami gyakorlatilag a partíciós tábla matatását jelenti (a módosított partíciós táblát vagy felszedi röptében akernel, vagy sem - ha nem, akkor reboot), vagy plusz diszket kap a vm.

Szerkesztve: 2020. 01. 16., cs - 21:48

Btw, miért is kellene a CentOS7-et upgradelni 8ra ?

https://wiki.centos.org/About/Product

June 30th, 2024 -ig még tuti támogatott lesz a 7-es is...

Amúgy nem csodálom hogy a Redhat (és nem a CentOS) nem erőltette eddig az in-place upgrade-et... nem véletlen... (jó jó bubuntu megoldotta.. valahogy valamilyen formában, talán működik talán nem)

RHEL / CentOS vállalati környezetre lett kitalálva, úgyhogy ott inkább a stabilitás jön előtérbe, mint az hogy most a 5.423 kernel verzióval fut-e a rendszer, vagy az 5.546 -al ...

És még mindig nem értem miért kellene valakinek aki üzemeltet CentOS-t frissíteni  (mmint 7-ről 8-ra..) ? (vagy RHEL-t)

A RHEL életciklusa alatt az alatta lévő hardver is nullára íródik/elvesti a támogatást/extended garit a legtöbb esetben, a hardver cseréjével meg egyértelmű, hogy új telepítés jár együtt :-) Meg egyébként is célszerű az új OS-t tesztelni a szükséges alkalmazásokkal, a tesztelést tiszta lappal (új hw, új OS) indítva - a tesztbőlmeg szépenlehet élest klónozni, ha úgy alakul/rendesen ki lett reszelve minden,hogyműködjön.

Ahol meg igen, ott mire az OS "EOL"-ba megy, a vas is, tehát irreleváns az in-place release csere. Az, hogy x évig garantált, hogy nincs főverzióban váltás, de van backportolt hibajavítás, az nagyon jó dolog - nagyon nem mindegy, hogy főverzió cserével járó szívást évente-kétévente kell végigjátszani, vagy sokkal ritkábban.

Ezennel megszünt az AGP-s videokártyák támogatása, csak mint egy érdekesség. Valószínüleg már nem érint sokakat.

robyboy