Manažer Greg DeKoenigsberg z Red Hat nesouhlasí. Rozdíl mezi RHEL a CentOS (free kopie RHEL odvozená ze zdrojových kódů RHEL) není žádný, poskytujeme zdrojové kódy.
To mi moze byt srdecne jedno, ked ma Oracle s CentOS na supporte odmietne (kedze uzivatel nepouziva jednu z certifikovanych distribucii).
A prosím, kde je problém? Můžete si zcela svobodně vybrat, jakou distribuci zvolíte. Buď si zvolíte CentOS, za kterou nezaplatíte ani korunu a svobodně se rozhodnete si kompletně dělat podporu sám (a Oracle vám dopředu říká, že vám nepomůže), nebo si koupíte Red Hat s podporou a můžete se s důvěrou obrátit na podporu Oracle.
CentOS prostě není pro Oracle zárukou, že se vždy bude chovat jako Red Hat - jste si jistý, jestli všechny balíčky byly zkompilovány stejně, jako u Red Hatu, že jsou ve všech verzích, atd.? Marná sláva, neexistuje na světě člověk, který by byl schopen rozumnět všem linuxovým distribucím a aby Oracle podporoval všechny distribuce, musel by mít armádu fundovaných lidí na hot-line - kolik by asi takový support stál?
Komerční firmy se prostě rozhodly, že bude podporovat pár komerčních distribucí přímo (a jednotliví distributoři jsou schopni technicky, obchodně i právně garantovat podobu distribuce). Že Oracle nepodporuje zrovna CentOS? Riziko soudního sporu, že "support Oracle blbě poradil, nám vznikla škoda x milionů dolarů a chceme ji nahradit" je ve Státech poměrně vysoké. A že by žalobce našel sponzora pro takový mediální spor, je myslím jasné (a je jedno, kdo by vyhrál - podívejte se na soudy SCO - IBM).
Až bude pro Oracle výhodné podporovat CentOS, nepochybně to udělá. Zatím si musí komunita u nepodporovaných distribucí poradit sama.
Mno, když jste zvolil příklad Oracle, dobrá, pojďme se ho na chvíli držet.
Od firmy Oracle neočekávám podporu své linuxové distribuce, ale očekávám od nich podporu jejich produktu - databáze. Může jim být zcela fuk, na čem Oracle provozuji. Jistě, každý soft vyžaduje nějaké prostředí. Např. Oracle bude vyžadovat ze systému pár knihoven a nějaká bloková zařízení (neznám Oracle). Dále už té firmě může být šumafuk co mám např. v /opt/kde nebo /usr/local, jakou mám distribuce a co na ní kromě DB ještě mám. Tenhle klikací přístup fakt nechápu - chápal bych to tak u her pro BFU, kde budou vyžadovat RedHat x.y.z s kernelem verze 2.6.18.19.redhat.patch.7-9-2.2006.version-4.17 a s ničím jiným to fungovat nebude. Ale u korporátní databáze ? Proboha proč ?
Pokud budu mít požadované knihovny, nechápu, proč musím mít RedHat. IMHO nejspíš proto, protože jsem též asi BFU a potřebuji klikací instalační program, o kterém nic nevím a který musím pustit pod rootem a pak se jen divit :-(
Moje zkušenost z praxe, případ, který zrovna řeším:
Pořídili jsme servery s Intel RAID SATA řadičem. Teď, před týdnem. Podpora samozřejmě jen pro RedHat a SuSE, jak jinak. Nabootoval jsem slackware 11 a OK, Megaraid se chytil a systém běžel. Pak jsem nabootoval x86_64 kernel. V okamžiku, kdy jsem sáhnul na disky, začal řadič pískat jako siréna, pole a všechny disky šly do offline. Strávil jsem den pokusy, abych zjistil, že firmware v řadiči je více než 3 roky starý a že je potřeba ho upgradnout. U právě koupeného řadiče. Prostě systém dodělej doma. Po upgrade firmware (utilita samozřejmě pro RedHat a SuSE, takže jsem musel nejprve analyzovat skript, co vlastně dělá, vytvořit mu podmínky pro funkci, které nejsou nidke uvedené - tedy kromě toho, že mám mít RedHat nebo SuSE) a upgradnout firmware. OK, 64bit kernel už na tom jel normálně. Tak a teď co dál - při poruše pole nechci rebootovat - proto jsme koupili hotswapové disky, že. Takže bych rád za provozu veděl, co se tam děje. Na to se dodává utilita zvaná WebConsole, což je web server, kde se dá s řadičem manipulovat - monitorovat ho, přidávat a ubírat disky atd. Web server je samozřejmě pro RedHat a SuSE. Instalační program je jen pro X-ka, takže namísto jednoduchého rozbalení z taru musím pustit javu a 5x odkliknout jako ve windows, že to opravdu chci nainstalovat. Instaluje se to do /opt/SVR, budiž. Části se instalují do /usr/bin, blbější místo už zvolit nemohli. Aby to bylo všechno snazší, je instalák Plug&Play a detekuje si, zda mám dotyčný řadič v počítači. Jak už to u PnP instaláků bývá, detekujeme, ale zdetekujeme prd. Takže se nenainstalovala jedna komponenta, protože PnP instalátor usoudil, že řadič v počítači není. Jak tu komponentu dostat ze změti binárek právě řeším. Doufám, že nebudu muset někam nainstalovat RedHat nebo SuSE, abych tu komponentu získal.
A teď moje varianta:
Tar archiv, požadavky:
vytvořit zařízení /dev /megadev0, c, 252, 0
JRE 1.3+
rozbalit archiv a je to.
Na uvedeném příkladu myslím dost jasně je demonstrováno, kam tato klikací politika vede. K bordelu stejnému jako ve windows - klikejte a když to nebude fungovat, vymýšlejte, jak přílišnou inteligenci naši PnP technologie očúráte. Fakticky budu trávit čas něčím jiným než tím, jak očúrat debilní přechytralý instalační program.
A poslední poznámka - Informix jsem rozchodil nakonec jen v chrootu. Protože varianta pro Linux neexistuje. Existuje totiž pro RedHat a SuSE. Divíte se, že když slyším o těchto 2 distribucích, že vidím rudě ?
Nedavno jsem instaloval server s intel raid radicem a potykal jsem se se stejnyma problemama. Nicmene na monitorovani tohoto radice (megaraid driver) existuje konzolovy program, ktery umi s radicem pracovat, tzn. menit vsechny parametry a cist z radice vse potrebne.