Oracle Linux 5.8

 ( trey | 2012. március 4., vasárnap - 11:27 )

Az Oracle bejelentette vállalati Linux disztribúciója, az Oracle Linux 5.8-as kiadását 32 bites (x86) és 64 bites (x86_64) architektúrák számára. A disztró három kernelkészlettel érkezik:

  • Unbreakable Enterprise Kernel [kernel-uek-2.6.32-300.10.1.el5uek]
    • ez az alapértelmezetten telepített és bootolt kernel
  • Red Hat compatible Kernel [kernel-2.6.18-308.el5].
    • alapértelmezetten telepített kernel
  • Red Hat compatible Kernel with bug fixes added by Oracle [kernel-2.6.18-308.0.0.0.1.el5]
    • elérhető x86-ra és x86-64-re, alapértelmezetten nem települ, kézzel kell telepíteni

A frissített kiadásban az upstream vendor frissítései mellett megtalálhatók az Oracle által szállított hibajavítások is.

Részletek a bejelentésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

xenes kernel hogy kerül alá?

Redhat/Centos 5.x-be van XEN tamogatas.
--
1 leszel vagy 0 élő vagy hulla!

Azért az kemény, hogy belerakják a 2.6.32-őt, amig a RHEL nem. Értem, hogy külön distro, és ez itt a hozzáadott érték, de akkor is a nem túl etikus általános Oracle hozzáállást érzem.

Nem értem az összefüggést. Ha nem rakná bele a 2.6.32-t, akkor etikus lenne a hozzáállása?

Lentebb már kitárgyalták.

Nem olyan regen volt nalunk eloadni az Oraculum, hogy miert dobjunk ki mindent amink van es hasznaljunk csak Oracle termeket. En mondom nektek az Oracle maga az ordog :)

Ezen a meetingen volt par erdekes parbeszedem a fo sales-es sraccal. :)
(itt bevallom, hogy egy ceget sem utalok jobban mint az Oracle-t)

Miutan valtig allitotta, hogy az Oracle linux binary compatible a Red Hat-al es csak annyit kell csinalni, hogy a Red Hat-on beallitjuk az Oracle repokat es nyomunk egy update-et es minden mukodik tovabb ezt volt a parbeszed:
En: Ha jol tudom az Oracle nem supportalja a KVM-et az Oracle linux-on
O: Igen jol tudja, mi xen-t hasznalunk
En: Mivel nekunk a sok xenes gep mellett van kb. 30 VM-unk ami par RH6.2-on fut KVM-es virtualizacioval hogyan mukodne ez a repo cseres update?
O: Haaat, mi nem supportaljuk a KVM-et mert a xen jobb. (hogy megvalaszolta a kerdesemet mi? :) )

Kovetkezo szitunal az volt, hogy a fonokom megkerdezte, hogy milyen a support-ja az Oracle linuxnak a Red Hat-hoz kepest illetve hogyan mukodik:
O: Termeszetesen lehet Oracle premium support Oracle linux-ra. Es a support az, ahol ok sokkal jobbak vagyunk a Red Hat-nal.
En: Hogyan mukodik a support. Ugy ertem, van egy BUG egy csomagban. Lejelentem a BUG-ot az Oracle supportnal. Mi fog tortenni?
O: Az Oracle mernokei kijavitjak a hibat es kapsz egy BUG-fixet.
En: Ha jol tudom az Oracle Linux az egy rebuild-je a Red Hat-nak igy a BUG abban is benne van. Hogyan lehet binary compatible az OL ha sajat BUG-fixeket csinalnak?
O: Ezeket a BUG-fixeket lejelentjuk a Red Hat-nal es ok is kijavitjak kesobb.
En: Tehat van olyan idoszak amikor nem binary compatible a ket OS?
O: Igen van

Mar az a teny, hogy ugy hivjak a kerneluket, hogy Unbreakable Enterprise Kernel kicsapja nalam a biztositekot.

A tisztánlátás végett a kérdéseidre, problémáidra a válaszok:
1. A KVM, mint hypervisor supportált az Oracle Linux-ban, tehát a repocsere sem jelentene problémát.

2. A bináris kompatibilitás nem egyenlő azzal, hogy a két szoftver binárisan megegyezik. Előbbi csak annyit takar, hogy egy alkalmazás mindkét rendszeren futtatható külön certifikáció és tesztelés nélkül. Csak abba gondolj bele, hogy az alkalmazásokat sem egy adott RHEL patch levelhez certifikálják, hanem verzióhoz (néhány nagyon extrém esetet eltekintve).

Sok mindenért lehet szidni az Oracle-t, de az Oracle Linux miatt a világ nem lett rosszabb, maximum egy kicsit szinesebb.

1., Mindig is erdekelt, hogy hogyan van a KVM-el az OL6 csak lusta voltam utananezni ezert gondoltam, hogy ez egy remek alkalom megkerdezni. Ezek szerint a Sales-es nem volt a toppon (be kell vallani, hogy nem az OL miatt jott eloadni)

2., Itt felreertettel egy picit. Nem mindig probléma ha a binaris nem egyezik meg (ha visszaolvasol latod, hogy ilyet en nem irtam, hogy az volna). Amire utaltam, hogyha mas a binaris, akkor nem minden esetben lesz meg a binaris kompatibilitas!
Ha van egy ilyen patch, akkor ket dolgot csinalhatnak:
- kiadjak maguk a bugfixet -> innentol vegyek le azt a binary compatible jelzőt a "termékükről"
- megkerik a RH-et hogy javitsa ki -> miert mondjak, hogy jobb a supportjuk ha a RH-ra varnak hibajavitasnal?

"hogyha mas a binaris, akkor nem minden esetben lesz meg a binaris kompatibilitas!"

De megmarad, ha a külső API-k ettől nem változnak meg, és erre minden patch kiadásakor figyelnie kell még a Red Hat-nak is. Két RH 5.8 installiáció között is van különbség pont a patch level miatt, mégis binárisan kompatibilis. Az előző hozzászólásomban szerepel, hogy mit jelent a bináris kompatibilitás, nem ismétlem önmagam.

Eleg nehez veled, de azert megprobalom megegyszer es utoljara:
"De megmarad, ha a külső API-k ettől nem változnak meg"

Amire probalok ravilagitani, hogy ott az a "ha". Az Oracle nem tud mit csinalni egy olyen BUG-al aminek a javitasanal valtozna az API. Ha meg akarjak tartani a binaris kompatibilitast a Red Hat-al akkor nem adhatjak ki a bugfixet. Amit csinalhatnak az az, hogy nyitnak egy BUG-reportot a RedHat-nal (esetleg csatolva egy patch-et), aki majd a kovetkezo release-be belerakja.

"Az előző hozzászólásomban szerepel, hogy mit jelent a bináris kompatibilitás, nem ismétlem önmagam."
Mar az elozo hozzaszolasodban sem kellett volna szerepelnie, mivel ugy latszik mindketten tisztaban vagyunk a jelentesevel...

Így van, de ebben az esetben a Red Hat ügyfél sincs előrébb, mert a RH sem tud patchet kiadni ahhoz a verzióhoz, mert ebben az a esetben RH sem lenne kompatibilis önmagával.

Pontosan. Ezek a patchek a RH-ban MINDIG elobb benne lesznek mint az OL-ben mert az Oracle-nek meg kell varni oket...

A következő minor verzióban, ami már binárisan nem kompatibilis az előzővel.:)

:)

Tehat levezettuk elmeletben, hogy az Oracle kijelentese miszerint "binarisan kompatibilisek vagyunk de gyorsabb/jobb a supportunk" az nem minden esetben igaz ;)

Gyakorlatban nem tudok hasonlitas csinalni mivel nem volt szerencsem meg az Oracle support-hoz.
A Red Hat-es TAM service-el jok a tapasztalataink.

Örülök, hogy egyet értünk.:) Sajnos a salesek szeretnek néha elrugaszkodni a valóságtól, műszaki kérdéseket ezért sem érdemes nekik feltenni.

Szerencses vagy. Nekem az oracle supporttal leginkabb az a tapasztalatom, hogy nincs support. Rendkivul lassan reagalnak, az esetek 99%-ban egy indiaihoz kerul a case aki fel sem fogja a problemat. A legtobb termekuk brozasztoan bugos, koztuk a csodalatos uek kernel.
Az oracle salsesnek nyilvan az a dolga, hogy azt mondja, hogy franko a suportjuk, de valosagban koszonoviszonyban sincs a redhat supporttal.

Nem értem a problémád a support gyorsaságával nekem legkésőbb 1 napon belül ír valamit, viszont amiben teljesen igazad van, hogy mindig egy indiaihoz kerülsz aki megkér, hogy az alap dolgokat csináld végig (persze te ezt már előtte végig csináltad), ha ez megvan és nem jó átdob egy másikhoz, aki megint azzal kezd, hogy csináld végig az alap dolgokat, ha te leírod, hogy végig csináltad az nem jó, neki egy frissebb kell :) és így tovább még valaki megoldja a problémád. Úgyhogy én már az alap dolgokról step by step screencastokat szoktál feltölteni, hogy ne kelljen minden egyes szintnél ezt megcsinálni. Viszont másnak a supportjánál se jobb a helyzet. Red Hat-es SR-t még nem csináltam, de amit tudok róla, hogy ott volt egy olyan esetünk aminél az IBM-re mutogatott, hogy náluk jelentsük be a problémát, az IBM meg visszamutogatott a Red Hat-re. A mai programokban mi nem bugos? :)

1 nap? :) Es az akkor is annyi ha legmagasabb prioritason nyitod a ticketet, ha a Red Hat supporthoz hasonlitgatjuk, akkor ott a legalacsonyabb prioritasi tickethez is 1 oran belul hozzanyulnak. Ugye mindkettonel permuim supportrol beszelunk.

Ez a legalacsonyabb priós SR volt, nagyobbnál ez jóval rövidebb. (2-es SR-re 1 órán beül válaszoltak). Ha a Red Hat-nél a legalacsonyabb ticketre is ilyen gyorsak az nagyon jó, de ez nálam nem elvárt.

Nade mi van akkor ha a bug pont az API kompatibilitasban van?
Pl. egy hivas nem megfelelo erteket ad vissza egy specialis esetben.

Lecserelitek a repokat, es?
Azt nem kerdezted meg a repo menedzselest hogyan kepzeli el az oracle? Mert erre en mai napig nem birtam rajonni. Probalok az Grid Controllal bohockodni, de sajnos alapveto feature-ok hianyoznak belole, mig a redhatnal a satellite server minden igenyt kielegit.

Engem inkabb az aggaszt az OELlel kapcsolatban hogy security patch = redhat + 6 het...

Erről a +6 hétről nincs valami linked? Épp most dolgozom egy ilyen javaslaton és ha ez valóban így van akkor inkább RH-t javasolnék mert szerintem ez egy nagyon fontos szempont.