- A hozzászóláshoz be kell jelentkezni
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... :/
- A hozzászóláshoz be kell jelentkezni
RHEL 8.1-ről van szó, ami november körül jött ki.
- A hozzászóláshoz be kell jelentkezni
A CentOS 8.0 szeptemberben kijott, ez valojaban abbol is a 8.1.
- A hozzászóláshoz be kell jelentkezni
Ja mar latom. Kicsit megvezetett a cim.
- A hozzászóláshoz be kell jelentkezni
Még mindig az újratelepítés az egyetlen járható út CentOS-éknál, ha valaki verziót akar frissíteni?
READY.
▓
- A hozzászóláshoz be kell jelentkezni
Van in-place upgrade ha erre gondolsz. De vannak limitációk főleg a külső repok körül.
- A hozzászóláshoz be kell jelentkezni
Sok éve azért váltunk meg a CentOStól, mert egy 3rd party szoftver igényelte volna a g++-6-ot (?), de simán nem lehetett upgrade-elni. Hatalmas mókolások kellettek volna, annyit pedig nem akartunk időben rááldozni.
READY.
▓
- A hozzászóláshoz be kell jelentkezni
Sok éve nem volt még in-place upgrade.
- A hozzászóláshoz be kell jelentkezni
6-ról 7-re már elvi lehetőség megvolt, de egy next-next-finish frissen telepített "üres" RHEL-t nem lehetett in-place 7-re frissíteni; nem tudom, 7-8 között ez változott-e...
- A hozzászóláshoz be kell jelentkezni
Hivatalosan tudtommal most sincs, nem hivatalos leírások és scriptek vannak. Lásd pl. ezt az issuet.
- A hozzászóláshoz be kell jelentkezni
És működik? Nekem nem ment, "rpmlib(RichDependencies) <= 4.12.0-1 is needed by redhat-rpm-config-116-1.el8.0.1.noarch" hiba miatt.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
... /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.
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
monitoring nem szol hogy fogy a hely? vagy az auditd secperc alatt megeszi a helyet?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
az oke hogy az alkalmazas logot kulon rakod, de mi ertelme van a /, /usr, /var/, /var/log-ot is kulon venni?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A logkezelo szervereinken nalunk is kulon van minden esetben a /var/log.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"A / növelése még lvm-es esetben sem triviális..."
Ezt nem ertem. Mi a kulonbseg / vagy barmi mas kozott LVM eseten?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nalunk altalaban plusz diszket kap a VM, ami LVM-ben ossze van simogatva es kesz is, meg mindig csak egy "particio" van.
- A hozzászóláshoz be kell jelentkezni
hat valahogy en is ugy kepzelnem el, hogy a /boot-nak van egy fix 1G-s disk, a lvm meg kulon megkap egy masik disket particios szarakodas nelkul.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Ez egy jó ötlet :)
- A hozzászóláshoz be kell jelentkezni
Nalunk pont ez van.
- A hozzászóláshoz be kell jelentkezni
A zabbix a 2.0 verziója óta tudja teljesen automatikusan a partíciókat monitorozni.
- A hozzászóláshoz be kell jelentkezni
Es?! (Nem az a bajom, hogy nem tudom az osszes particiot monitorozni.)
- A hozzászóláshoz be kell jelentkezni
"N particiot kell monitorozni"
erre adtam egy tippet, le ne harapd már a fejem
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
ha ma nem is, de 2024-ig nincs már sok év, előbb utóbb szükséges a váltás. vállalati környezetben is van igény pl RHEL6-rol 7-re, ugyanez lesz 7-ről 8-ra.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Btw, miért is kellene a CentOS7-et upgradelni 8ra ?
Mert nem akarsz ezer eves cuccokat hasznalni.
- A hozzászóláshoz be kell jelentkezni
Ahol ilyenek az igények, ott nem CentOS/Red Hat-ot használnak.
- A hozzászóláshoz be kell jelentkezni
Valahol egy tokeletes vilagban ez mindig mindenhol igy megy.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nekem ne mond, minálunk is így van. Idén jönnek új HW-ek az új RH8-hoz :D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni