Red Hat Enterprise Linux 7

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

RHEL 7

[ bejelentés | fejlesztői blogbejegyzés | Red Hat vállalati blogbejegyzés | dokumentáció | kiadási megjegyzések ]

Meglepődnék, ha nem a CentOS érkezne előbb. Nálam 1 hónappal ezelőtt esedékes lett a vascsere nem lehetett tovább húzni, azóta az RC fut. Sajnos kb. még a kutya sem készít csomagokat hozzá, atrpms meg epel is egyelőre korlátozott kínálattal rendelkezik. MP3 egyelőre felejtős, VLC még nincs, stb. De ezeken kívül minden más rendben van. Szokni kellett az új GNOME-ot a hatos után, ez az értesítési terület dolog nem a kedvencem, a bal felső sarkot szerencsére sikerült gyorsan letiltanom, attól azonnal kezdett hullani a hajam. Meg hogy semmi nincs ami korábban volt, még egy vacak system monitort sem lehet a felső sávba tenni anélkül, hogy ne kéne 3rd kiterjesztésekkel gányolni. Hagytam is a fenébe. Persze még mindig a freetype újrafordításával kell nyitni, meg mire nagyjából belőttem a fontokat... A régi konfig nem jó. De FF-ben az indexen az Open Sans még mindig ragyás. Ha valakinek lesz majd normális konfigja megoszthatná. :)

szerk: Na szép. Egyúttal meg is szűnt az RC repo a redhat ftp-n... akkor egyelőre nincs több yum install a CentOS-ig... :)

Jó kérdés, én CentOS-t tippelek, az SL a build rendszerével, szerintem, le van maradva. Azt azért látom, hogy az SL is dolgozik, a git-ben van pár SL-es arc (Pat Riehecky, hughesjr) commit-ja.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Késve, de SL is megérkezett, jelenleg még alpha verzióban:

Pat Riehecky:
Users interested in Scientific Linux 7 ALPHA can review:

http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-d…

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( zeller | 2014. 06. 10., k – 21:09 )

Az ls parancs talán még a régi benne... :-P A többit meg lehet újratanulni...

( Dacr (nem ellenőrzött) | 2014. 06. 10., k – 21:14 )

Ú de vártuk már! :)

( bviktor | 2014. 06. 10., k – 21:44 )

Juhu, akkor lehet frissiteniujratelepiteni a szervereinket!

Egyrészt megteheted, hivatalosan is támogatott a dolog.

Subscriber content preview.
For full access to the Red Hat Knowledgebase, please log in.

Cool story, bro. OTOH https://access.redhat.com/site/solutions/21964

Resolution

Red Hat Enterprise Linux 4, 5, 6: Red Hat does not support in-place upgrades between any major versions of Red Hat Enterprise Linux.
Red Hat currently supports upgrades from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7 for specific/targeted use cases only.

Erted? Enterprise! De megnyugtato, hogy igy 2014-ben mar kezdik kapizsgalni, hogy vannak, akik nem feltetlen akarnak szervereket ujratelepiteni 3-4 evente, es legalabb mar a szandek megvan.

Másrészt meg minek? A RHEL5-re 2017-ig, a RHEL6-ra meg 2020-ig van support

Kitorolhetem vele a seggem, ha mar a megjelenese napjan elavult volt rajta minden.

Hasznalj olyan disztrot ami a megjelenese napjan pont annyira friss, mint amennyire Neked szukseged van ra es a verziok kozott fajdalommentes a frissites. En is ezt teszem ott, ahol erre van szukseg. Ahol rolling release kell ott olyan rendszert hasznalok. Ahol meg jo a Red Hat altal elkepzelt megoldas, ott CentOS-t. Ennyi. Megfelelo eszkozt a megfelelo feladatra es nem sir a szam.

Honnan vetted a "3-4 évente újratelepíteni"-t? A RHEL5 2007.03.15-én jelent meg, 2017.03.31-ig támogatott, úgyhogy az OS-oldali támogatás okán nem kell újratelepíteni, maximum azért, mert a hardver elavul/kihullik/garija lejár.
Az, hogy nem a legfrissebb prerelease/beta/testing verziókból buildelik azt az OS-t, amit majd minimum tíz évig támogatni fognak az valóban így van, de ez érthető önvédelem - production rendszert nem építünk testing/unstable szoftverből. Legalább is akkor, ha nyugodtan szeretnénk aludni. Ha neked folyamatosan a legutolsó verziókra van szükséged (mert az alkalmazás, ami használja a gépet olyan, vagy mert egyszerűen csak verziószám-fétised van), akkor neked nem való a RHEL, mert ott a stabilitás a cél, az, hogy 6-10 éves távlatban (ami hardverben legalább két generáció) tervezhető legyen a szoftverkörnyezet.

Mondjuk viktor védelmében azért azt el kell mondani, hogy amennyire én értem, ő főleg ilyen webes izék környékén mozog, ott meg tényleg van egy csomó mozgó célpont jelenleg, ahol az ilyen 6-10 éves cseszés valóban nem nagyon tartható, azért abban van ráció, hogy sok helyen azért a három évenente kb mi is megugorjuk a tech frissítést.

Spec azon én is mindig pislogtam debian felől érkezve, hogy nincs distupgrade? (Annak ellenére, hogy értem, miért nem csinálták eddig) Mire meg most megugorják, már egyre kisebb a jelentőssége, a minden virtuális korában sokkal egyszerűbb tesztelni újratelepítéssel.

Én RH-val kezdtem szerver szinten (Suse grafikus környezetben), de miután a Debiant is elkezdtem használni mindig csodálkoztam azon, hogy Anaconda-n kívül nem volt más upgrade-lehetősé, még az RHEl előtt Fedora 7 és 8 idején. Fedora bevezetése után sem volt támogatott a yummal való rendszerfrissítés, és most amikor hivatalosan támogatott, még mindig bonyolultabb, mint egy apt-get update, apt-get upgrade, apt-get dist-upgrade.

https://www.digitalocean.com/?refcode=7504fb2af065

Kroozo volt az egyetlen, akinek sikerult megugrania az igen alacsony lecet. Nezhettek hulyenek, ahogy jolesik, de az OS (akar szerver, akar nem) nem azert van, hogy magat futtassa, hanem hogy a rajta levo alkalmazasokat futtassa. Ezer eves alappal nem fogok varat epiteni. Akar 2017-ig tamogatott, akar 2117-ig.

Persze ezt megint olyan, hogy kinek mi? Nekünk van olyan rendszerünk, amit annó (kb 3-4 éve), épp ötös centoson raktunk össze, azóta is elvan azon, és igazából firssítésnél leszarom (illetve leszarnám, ha nem lenne így jó várhatóan még 5 évig), hogy kb az egyetlen lényeges radius configot újratelepítés után kell visszamásolni, vagy yum distupgrade van.

Van egy csomó olyan dolog, amiből bőven jó a régebbi, nem kell a nice and shiny belőle, arra tök jó alap az RH, a fejlesztéstől jövő jól körülhatárolható dolgokat meg max majd forgatjuk meg karbantartjuk in-house. Bizonyos méret fölött ez nem gond, és egy jól működő felállás. Hogy a tied nem ilyen, nem jelenti azt, hogy ez így nem jó.

" Ezer eves alappal nem fogok varat epiteni" Az a baj, hogy nem a gombhoz vesszük a kabátot. Ha van egy feladat Pl. lamp szerver akkor valószínüleg senki se fog RHEL5 re építkezni, viszont ha olyan az softwer ami pl RHEL5 re van validálva, akkor nem árt RHEL5 alá tenni. És tuti vannak cégeknél olyan sw-k amiknek az rhel5 is új.

Fedora 20, Thinkpad x220

Jelen!

Egész sok problémánk volt bizonyos rendszerek RHEL5-re migrálásával, azért, mert túl új volt. Egy igazán régi rendszerben számos olyan függőség van/lehet, ami pl. az ls parancs kimenetének formátumára épít, vagy éppen csak olyan környezetben működik, ahol nem a hálózati kártya, hanem a CPU számolja a kimenő IP csomagokra a checksumot. Az ilyen jellegű dolgok hosszú évek távlatában változni szoktak - kivéve pl. RHEL-en a támogatás időtartama alatt...

Csinálhatsz régebbi RHEL-en dist-upgrade-et, csak nem lesz rá support. Ez debianon is így van, ott sincs rá support. Ellenben RHEL7-re már supportált módon is lehet dist-upgrade-et csinálni, úgyhogy ez előrébb tart :-)

(Egyébként a dist-upgrade elég nehéz dolog. Gondolj bele egy apache 2.2 --> 2.4 váltásba - más egy kicsit a konfigformátum, és emlékeim szerint debianéknál sincs konvertáló tool.)

A réri szoftverek kapcsán meg egyszerűen más területeken mások az igények. Eszembe se jutna egy csillivilli ruby on rails alkalmazás alá RHEL5-öt tenni, mert túl régi, és az is marad benne a ruby. Ellenben egy 20 éve fejlesztett számlavezető rendszer alá még a RHEL5-ben lévő ls parancs is túl új... :-)

Működni működik (és amennyire az Upstart-on ismerem, valszeg egy SysV init - Systemd váltás egyszerűbb lenne, mint a SysV - Upstart), de a kernel utáni legfontosabb eszközt cserélgetni nem feltétlenül szerencsés; valszeg nem ok nélkül nincs rá support :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A RHEL5 --> RHEL6 váltás az upstart --> systemd lesz. Majd kipróbálom egyszer, hogy hogy megy.

Egyébként ha már váltani kell, akkor a legtöbb esetben számomra egyszerűbb új gépet telepíteni és az alkalmazást átmigrálni rá. Ehhez persze erősen hozzájárul, hogy csaknem minden gépem virtuális gép, és viszonylag olcsó és gyors akár tonnaszámra gyártani az új gépeket, ha eltekintünk a körbevevő sallangoktól és politikától, akkor negyed óra alatt megvan egy gép bőven.

Semmi köze hozzá, leszámítva, hogy 1) van ahol ezek a kiegészítő termékeket az oprendszerrel együtt szállítják (Exchange) és 2) hogy ez csak egy példa volt arra, hogy van olyan Windows server konfiguráció csak a gyári telepítő DVD-n levő komponensekkel, amit nem lehet in-place (értsd: újratelepítés [ugyebár, fúj] nélkül) upgradelni. Microsoft rulez!

A létező módok, amik szükségessé teszik plusz CAL-ok és infrastruktúra beépítését? Egy "szervízpakk" telepítése miatt?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Pont ezt mondom, hogy VAN ahol a kiegészítő terméket (ami nem pont az Exchange, de több groupware is van AFAIK az RH repókban) együtt szállítják a rendszerrel. És amint azokat a funkciókat, amiket egy RHEL-lel a gyári repóból megoldasz elkezdesz Win alapon is megoldani, azonnal nem lesz annyira egyértelmű az az inplace upgrade.

*(de mintha a kisvállalati Win serverekben (SBS) benne is lenne)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Más pályán focizol. A RHEL nem arról szól, hogy verziót cserélj röptében az alkalmazásaid alatt. Az arról szól, hogy fogod valamelyik aktuálisan támogatott RHEL verziót, megnézed, hogy alkalmas-e arra, amire neked kell, van-e támogatás a rendszer (hardver valamint alkalmazás) tervezett élettartamának a végéig, és ha megfelel használod azt a főverziót, amit kiválasztottál. A RHEl esetében az OS életciklusa hosszabb, mint a legtöbb alkalmazás, illetve azt futtató hardveré, ergo vagy a vasat, vagy az alkalmazást fogod hamarabb cserélni, mint az OS-t.

hm..
vas csere nálunk:
1. út.) Új vasra mentés visszatölt --- pár eszköz drive automatikusan cserélődik ennyi
2. út.) Virtulizáció felrak az új vasra -- virtuális gépek átköltöztetése csit-csat
3. út.) san -on lévő rendszer felbootolása az új vason többi lsd.: 1. út

És itt szó sincs a dist upgrade-ről... pedig jó lenne...

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

( log69 | 2014. 06. 13., p – 08:25 )

Kíváncsi vagyok hogy mi lesz a megoldása ennek a problémának?

Vagyis ugye megszűntetni RH az FTP-n keresztüli forrás átadást SRPM formában (amely speciel digitálisan is alá volt írva), és ez helyett git tárolón keresztül lesznek elérhetők a kódok, de ott problémásnak látják a jelenlegi SL fejlesztők, hogy hogyan lehet majd megkülönböztetni, hogy melyik állapot volt az eredeti RH által kiadott, és mely patchek jöttek CentOS-től.

http://listserv.fnal.gov/scripts/wa.exe?A2=ind1406&L=scientific-linux-u…

Annó mikor jöttek a gittel, ez bennem is felmerült, de aztán elintéztem annyival, hogy csak van annyi eszük, hogy megtaggelik, 1x1. Furi, hogy nem volt :(

szerk:
ill igazából imho az kicsit ejnyebejnye, hogy nem az van, hogy a van egy 'vanilla RH source' git, amit a centos úgy klónoz meg követ a sajátjában, ahogy akar...

Érdekes. A centos-os csákón érezni, hogy birtokon belülre került.

De ügyes a RH, adja a forrásokat, licenc kipipálva, de egyszerűvé nem teszi a felhasználásukat. Mint a népmesében.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Bent van licenc, itthon mást használok, de csípi azok szemét akik eddig kialakított rendszerükhöz feldolgozhatóan megkaptak valamit, most meg dolgozhatják át a build rendszerük. Ez érthető az ő oldalukról. Ettől még ilyen az élet, az RH nem Teréz anya.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Amikor azon megy a nyavajgás, hogy parsolja a git.centos webpaget, az vicces, viszont a gpg signo hiánya valóban háthmm...

Illetve a RH is "ingyen" kapja ugye a sok cuccot, amit csomagol, és értem én, hogy lic. szerint jók úgy, hogy csak az ügyfél kap srpm-et, eleve nem kellene nekik semmi publikusat biztosítani, de kevésbé illik azért a "mi értjük az opensourceot és jófiuk vagyunk" irányvonalba. Azzal együtt, hogy láthatólag amit a centossal csináltak, az viszont imho jó.

Illetve a RH is "ingyen" kapja ugye a sok cuccot, amit csomagol, és értem én, hogy lic. szerint jók úgy, hogy csak az ügyfél kap srpm-et, eleve nem kellene nekik semmi publikusat biztosítani, de kevésbé illik azért a "mi értjük az opensourceot és jófiuk vagyunk" irányvonalba.

Igazából tökéletesen illik a "mi értjük az opensourceot és jófiúk vagyunk" irányvonalba, mert egyrészt marha sok "ingyen" kapott cuccot ők fejlesztenek a leginkább, másrészt ez szerintem továbbra is leginkább az Oracle-nek szól, akik direkt versenytársként az ő munkájukból élnek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tudom, hogy egy csomó dolgot ők csinálnak, meg azt is tudom, hogy az oracle büdös nekik... Ezzel együtt ez kommunkiációs szempontból kissé collateral damagenek tűnik, amivel azért lehetne ezt-azt kezdeni (pl srpmek eddig voltak, kernel patchek nem voltak szétszedve ugye, ami tekintve, hogy az RH nem csak securityt backportol, hanem brutális mennyiségű featuret is, azért komoly érvágás volt az orákulumnak, a centos/sl/stb jellegű projekteket viszont kb nem érintette).

A másik oldalról meg pl a signo hiánya, az esetleges hülye taggelés (ami a ticketből azért erősen úgy tűnik, hogy inkább csak sírás) pusztán technikai probléma, kár nem megugrani...

Követem a levlistát és még mindig nem született értelmes megoldás vagy tényeken alapuló kinyilatkoztatás, mely igazolná hogy a RH által kiadott forrást el fogják tudni különíteni a git fában az SL dev-ek a CentOS által módosítottaktól.

Felvetették, hogy a fizetős ügyfelek által megkapott és digitálisan aláírt SRPM-eket nem lehet tovább terjeszteni. Ez nekem sántít, mert ezzel azt mondanánk, hogy simán megváltoztathatják a GPL feltételeit. Én úgy tudtam, hogy a GPL biztosítja, hogy a forrás kódot tovább lehet módosítani és terjeszteni mindaddig, míg a GPL feltételeinek eleget teszünk.

Vélemény?

( log69 | 2014. 06. 25., sze – 09:40 )

Elég érdekesen körvonalazódik a dolog. A lenti linken olvasható véleményt nem tudom hogy meg tudják-e cáfolni érvvel, de ha nem, számomra elég logikus elképzelés, hogy RH ezzel a lépéssel a közösséget rombolja szét, mivel a fizetős csatornán vásárolt SRPM-ek nem terjeszthetők legálisan, a CentOS git-en keresztül hozzáférhető kódnál meg nem ellenőrizhető, hogy az eredeti RH forráshoz képest mi módosult, így megbízhatatlan lesz más disztribútorok számára a CentOS. Tehát sikerült Oracle-t gáncsolnia, de ezzel sajnos a közösséget is.

http://listserv.fnal.gov/scripts/wa.exe?A2=ind1406&L=scientific-linux-u…

"My understanding is that Red Hat has changed the rules for use of the
official RHEL SRPMs, but still using
the finest JDs and laws that money can be buy (as have many other
for-profit corporations) and thus stay in compliance with letter of the
the GPL, linux, etc., licenses, if not the spirit."

ennek én nem látom semmi megalapozottságát a threadben. Ami reális az kb az, hogy eddig esetleg csak a tényleg GPL (etc) linceszes srpmek voltak kint public, most meg lejön az is, aminek nem ilyen a licensze, de hogy ezt annyira gáz lenne automatizálni, azt nem látom...