Jön a vállalati-szintű Ubuntu a héten

Ubuntu

A népszerű Ubuntu Linux disztribúció fejlesztői azt tervezik, hogy ezen a héten széles körben elérhetővé teszik a szoftver legújabb, mérföldkőnek számító verzióját. Az Ubuntu Linux 6.06 (kódnevén Dapper Drake) a publikus ütemterv szerint 2006. június 1-jén, azaz holnapután lesz elérhető. A kiadást a projekt tovább fogja hivatalosan támogatni, mint a korábbi verziókat, és úgy hirdetik, hogy alkalmas lesz vállalati felhasználásra is.

Az Dapper Drake desktop verziója hivatalosan három évig, míg a szerverekre szánt kiadása öt évig fogja a fejlesztők támogatását élvezni. Összehasonlításképpen, a jelenlegi stabil 5.10-es verzió, a Breezy Badger 18 hónapos támogatással rendelkezik.

Bővebben itt.

( lacika v | 2006. 05. 30., k – 09:34 )

Honnan is lehet ltölteni a szerverekre szánt verziót? Nekem most kicsit zavaros mert az ubuntu.com -on nem igen fedeztem ezt fel. Valaki útba igazítana? Köszönöm!

AFAIK: A szerverekre szánt verzió ugyanaz lesz (telepítő CD is), mint a desktop-ra, ugyanabból a repo-ból fog dolgozni, csak a szerver specifikus csomagok sokkal tovább (+2 év) lesz támogatottak.

"Custom or Server Installation

Type "server" at the initial CD-ROM boot prompt. This will install only the base packages, after which you can install only what you need, using 'aptitude' or 'apt-get'."

--
trey @ gépház

Haggyad. Fogalma sincs arról, hogy ettől lesz vállalati szintű. Hogy egy szupport cég áll mögötte. És nem attól, hogy milyen a telepítő média. Akinek szüksége van rá, majd jön a Canonical embere, aztán telepíti a rendszert (a pénzt meg ki lehet érte csengetni).

--
trey @ gépház

Komolyan arra a csodás vállalati szintű AIX-re vered, amihez kimentem OracleAS-t telepíteni, és két napon keresztül szívlapáttal hordták rá a patch-eket, mert annyira ratyi volt?

AIX. Mert megérdemled.

Vagy miben is jobb a RHEL, mint amilyen az Ubuntu Server tud lenni? Konkrétumot légyszi. Mert szeretem én a RHEL-t, de hogy hányféleképp tud magába dőlni, és hogy mennyire megaröhely, amit support címén nyújtanak, arról azért könyvet lehetne írni. Annyival jobb a Win-nél, hogy saját magam is ki tudom javítani, ha vmi szar benne.

latod megint csak az orto buzisagod teszed nyilvanvalova
1. az os josagat mennyire mondja meg az mennyi pecs van hozza?
ennyi erovel a linux a legszarabb os
2. ha fogalmad sincsen arrol h miert jo a rhel akkor minek fikazod?

http://www.redhat.com/rhel/migrate/whichlinux/

olvasgassal kicsit

http://litch.eu/blog

kerlek a tragarsagot mellozd a kesobbiekben. csak a hozzaszolas elso mondataval van bajom, a tobbi normal vita.

amugy abban egyetertunk, hogy a rhel tenyleg jo, es jopar ev elonye is van az enterprise piacon. az ubuntu meg majd kiderul, hogy mennyire kepes betorni a piacra, meg csak most probalgatja a szarnyait. fikazni megsem kellene izombol :)

A stílusod téged minősít, nem engem.
Miheztartás végett:
Tudom, miért jó a RHEL, különben nem üzemeltetnék 60 szervert vele. De ettől még ugyanúgy vannak olyan problémái, amiken röhögnöm kell, ha arra gondolok, hogy vállalati környezetben ilyennek nem szabadna történnie.

Nem az minősíti az AIX-ot, hogy mennyi patch van hozzá, hanem az, hogy ha gyakorlatilag bármire is használni akarod, akkor egyből két napig csak túr6od hozzá a javításokat...

Ez kb annyira enterspájz megoldás, mint mikor pár éve egy alkalmazás bug miatt egy SUN-os alkalmazásszerveren Java verziót kellett cserélni, emiatt Solarist kellett patch-elni, emiatt pedig szét kellett bontani a clustert. Na szerintem ez nem éppen vállalati megoldás. És az AIX-en sincsenek sokkal jobb tapasztalataim. Mondjuk a Sun egész sokat fejlődött az utóbbi időben.

Ezeknél akkor már sokkal jobb az RHEL, bizonyos dolgokra legalábbis.

Olvasgatással meg nem sokat érsz, kellene némi tapasztalat is talán.

Ezt senki nem mondta. Ellenben vannak olyan cégek, akik építenek RHEL-re, SLES-re és ha Shuttleworth tartja amit ígért, akkor elképzelhető, hogy Ubuntu-ra is. Az adatbázis szerverek közül az IBM-es DB2 már certifikálva van Ubuntu-ra, a MySQL nemrég jelentett be hozzá támogatást, és várhatóan csak nőni fog azon cégek száma, akik folytatni fogják ezt a sort.

--
trey @ gépház

Gratulálok ahhoz, hogy te kinézet alapján mondod meg valakiről, hogy az milyen szakember.

"(egyébként nem, messze nem csak ettől lesz vállalati szintű)"

Valóban nem csak ettől, lejjebb említettem további dolgokat is. De kíváncsian várom tőleg is, hogy még mitől.

--
trey @ gépház

>> Gratulálok ahhoz, hogy te kinézet alapján mondod meg valakiről, hogy az milyen szakember.
továbbklikkeltem és elolvastam, hogy a pingvinbabákkal ölelkező enterprise-grade fószer 1985 óta linuxmájer, úgyhogy most már biztonságban érzem a magyar vállalatok jövőjét, kthx

>> De kíváncsian várom tőleg is, hogy még mitől.
pl attól hogy tudjuk mire használni a Vállalatba'
(nem, a háttérképállítgatás, az mp3 taggelés meg a brózolgatás az nem felhasználás)

"úgyhogy most már biztonságban érzem a magyar vállalatok jövőjét, kthx"

Ühüm, amíg nem ismered a képességeit valakinek, addig azt hiszem nagy baromság arról neked véleményt formálni.

"pl attól hogy tudjuk mire használni a Vállalatba'
(nem, a háttérképállítgatás, az mp3 taggelés meg a brózolgatás az nem felhasználás)"

Tehát egy Linux szerver snq- szerint csak erre képes?

--
trey @ gépház

elnézést, nem tudtam, hogy éppen Vállalati Szintű Linux Kiszolgálókról beszéltünk, azt hittem a szokásos "éppen kijött egy új alpha gimpből vagy xfce-ből, úgyhogy most aztán gyalulja le mindenki a céges dekstopját, de durván, mert a csoportos produktivitás új értelmet kapott + van zöldmezős háttérkép"

Miért ez most milyen oldal?

http://people.freebsd.org/~phk/

vagy ez:

http://www.zipworld.com.au/~akpm/

vagy ez:

http://www.porcupine.org/wietse/

vagy ez:

http://www.cs.vu.nl/~ast/

(legjobb)

Amikor először néztem, azt hittem valami lúzeré. Aztán kiderült, hogy a faszi nem nagy webdesigner, de attól még elismert kernelfejlesztő. De mutathatnék még számos szánalmasan kinéző embert és honlapot, aki a maga területén nagy koponya. Én nem ítélnék sem a külső, sem a ruházat, sem a honlap alapján meg senkit.

--
trey @ gépház

Dehogy néztem végig. Gondolom snq- szándékosan kiválasztotta a legrosszabb honlappal rendelkező Ubuntu támogatót. Ebből marhán nem lehet következtetni arra, hogy milyen támogatás várható a Canoncal-tól. Pláne, hogy ma bejelentették, hogy a Sun-nal is összeálltak. Majd mindjárt lesz is róla hír :-)

--
trey @ gépház

Miert, nalad mi a vallalati szintu megoldas? Az hogy a szerver-installerert 20x annyi penzt kernek, majd kijon 3 dilettans tokig oltony-nyakkendo-laptopba oltozve, szopik ket hetet 15 rugos oraberert, megvetetik a nyolcszor akkora hardvert a szar ala aranyarban, majd support gyanant kozlik hogy "hat ezt sajnos nem lehet".

(Megtortent eset, nagy cegnel, NW5 -> Win2003 migracio. Nehany szolgaltatas azota is a Netwaren megy. Sz'al helybol lehetne vitatkozni hogy miaz hogy "vallalati szint", ugye. Ugy is mondhatnam, "az ellen nem ved".)

AFAIK, par regebbi de kritikus ugyviteli szoftvert (Win32 nativak), aminek a keszitoje forraskoddal egyutt eltunt a kodben. Valami miatt a Netware-s meghajtorol hajlando futni, mig ha Win2003-s halozati meghajtorol kene futnia, akkor kulonbozo helyeken mindenfele jogosultsagokra hivatkozva (vagy csak ugy random) elhal. Megvolt a konkret hiba is, hogy mi okozza, ami ismert gond Win2003 eseten, de a reszletekre mar nem emlekszem, 1-2 eve volt.

hehe, vállalati szintű Oracle (megtörtént eset). Nyakkendős "szakértő" 2 nap alatt nem volt képes felinstallni a SUN vasakra a 8i-t, man oldalakat olvasgatta a weben, az órabért képzelhetitek. Amikor jeleztük, hogy ez nem megy, ne erőltessünk és küldjenek valaki mást, küldtek is: egy szintén nyakkendős minőségbiztosítót (az előző szakember mellé), aki egy napi monitorozás után biztosított minket arról, hogy a kollégája megfelelő minőséggel dolgozik. Mi úgy láttuk, inkább vergődik, mint malac a jégen. Megköszöntük a közreműködést, majd felinstalláltuk magunk. Csak elég gáz volt a hat hete tartó napi 16 órás munka mellé még benyomni ezt a taskot is. Persze ha rajtunk múlt volna, nem Oracle lett volna, az biztos...

Nalunk a proengineer installja volt ilyen... jott egy ficko, hozta a linuxos telepito cd-t es rogton mondta hogy kell majd egy kis segitseg mert linuxra meg nem telepitette... kiderult meg eleteben nem latott linuxot, vegul vegignezte ahogy en felraktam. szoval erdekesen ertelmezik a support fogalmat, legalabbis Mo-n...

A'rpi

Errol az jutott eszembe amikor Solaris-ra Oracle-t telepitve az /etc/system beli shm beallitasokat nem tudtam fejbol, ezert "kipuskaztam" egy masik geprol, ott egy rakas mindenfele kombinacioban szereplo 99%-ban kikommentezett ertekek voltak ilyen megjegyzesekkel hogy "ezzel nem ment", "XYZ ezt ajanlotta", "Dr W. ezt ajanlotta", stb ;-)

En nem ott melozok. Nem hulyultem meg. :) En nem engednek be ilyen alakokat oda ahol en vagyok a rendszergazda. Ahol en dolgoztam, ott RHEL-eket szortunk ki, mert nem mukodott, es ment a helyere Debian, mert azt lenyegesen kevesebb szopassal birtuk atalakitani ugy, ahogy nekunk kellett. (Redhat support meg ROFLMAO.) Aztan ex-melohelyet megvette egy Windoz-fan ceg es kituztek a Windows migraciot mint celt. Azota is kuzdenek, hogy a dual 3Ghz-s + 4GB RAM Xeonra fel birjak rakni ugy az Exchanget, hogy kivaltsa a Cele 600-n futo altalam epitett mailrendszert, ami mai napig megy. En meg elmentem Java programozonak inkabb (bleargh). Shit happens. :P

van kulon server cd es valoban kozos poolbol dolgozik, csak a kernel kulonbozik (forras kozos, mas opciokkal fordul, pl. preempt nelkul).
hasznalhato termeszetesen a dapper desktop cd is a telepitesre, de azokra a cd-kre mas csomagokat valogattak ossze es akkor a kerneltis erdemes kicserelni a mindenkori linux-image-server vagy linux-image-server-bigiron metacsomag altal nyujtottra, kinek melyik fekszik. a kulon image elerheto a http://releases.ubuntu.com/dapper/ alatt az ubuntu-server image-ek kozott. gondolom a vegleges is ide kerul ha elkeszul

konkretan milyen bugokat tapasztalsz a release elott allo ubuntuban levo kernellel pl.? az altalam reportoltakat javitottak, sot a nagy reszet mar amikor belefutottam, megtalaltam pending statusban a bugtracking rendszerukben, es valoban nem telt bele 3 nap es uploadoltak a javitasokat. nem, nem azt mondom, hogy ez aztan tuti bugmentes, de ki merem jelenteni, hogy egesz szeles korben tesztelt es az en fogalmaim szerint jonak mondhato a minosege.

Ez engem is érdekelne. Konkrétan _normális_ crashdump-ra gondolok, ami ráadásul _támogatott_ a nagyobb disztribúciók által. Ha van ilyen, akkor elnézést a hozzászólásért.

Ave, Saabi.
ps: konkrét tapasztalat, a crashdump-tól függetlenül: SAN-os környezetben a linux-os gépek induláskor mindenképpen kidobtak egy SCSI reset-et a SAN-ra. Mindig. Ez kissé megzavarta a SAN-on lévő tape-re dolgozó egyéb masinákat. Szar ügy ugye a menet közben visszacsévélődő szalag. Megoldás tudtommal még nincs.

nezd itt a cegnel en pont a linux integracion dolgozom hogy ebbol az iszonyat fosbol egy normalis mukodo operacios rendszert faragjunk
elmondhatom hogy iszonyat negativ tapasztalatok vannak minden teren, megmagyarazhatatlan hibak sorozata, es sajnos a vevoknek ezt adjuk. a linux telleg alkalmatlan vallalati hasznalatra, van aki ezt kepes felfogni es van aki nem.

http://litch.eu/blog

Én meg tudok neked mutatni olyan Bp.-i kórházat, ahonnan kivágták a Solaris+Oracle kombót (ez elég vállalati?), mert állandó teljesítmény-problémák voltak vele, helyette RHEL+Oracle párost tettek, azon fut az egész kórház, azóta nincs problémájuk. Ennek idén lesz 4. éve.

Naugye. Akkor most kinek van igaza. Senkinek. Az is lehet, hogy te (ti) vagytok a bénák (én is tudok tahó lenni, de ettől még nem lesz igazam)?

--
trey @ gépház

Sajnos kishazánkban a kórházak számítástechnikáját inkább kisvállalati környezetnek tudom elképzelni, bár konkrétan még egy kórházban sem láttam milyen gépeket használnak.
A korábban említett SAN-os probléma amúgy RHEL-nél jött elő, de tartok tőle disztribúció független.
Szerintem nem attól lesz egy rendszer vállalati környezetben jól használható mert x évet megy meghibásodás nélkül - az x mértéke szerencse kérdése - hanem attól hogy meghibásodás esetén mennyire gyorsan lehet működő állapotba hozni. Ezért hoztam fel a crashdump kérdését, ami elég lényeges egy elhasalt gép javításánál.
Másik lényeges kérdés, hogy milyen módon lehet HA környezetet kialakítani. Mondjuk ebben nincs a Linux rossz helyzetben.

Ave, Saabi.

"Sajnos kishazánkban a kórházak számítástechnikáját inkább kisvállalati környezetnek tudom elképzelni, bár konkrétan még egy kórházban sem láttam milyen gépeket használnak."

Nem hiszem, hogy arról beszélgettünk volna, hogy kis- vagy nagyvállalat, hanem arról, hogy vállalat.

"A korábban említett SAN-os probléma amúgy RHEL-nél jött elő, de tartok tőle disztribúció független."

Nemtom, én csináltam már HP EVA storage-ot Red Hat-tal és Oracle-lel, failoverrel, köszöni működik. Biztos vannak hibái a Linuxnak is, de melyik OS-nek nincsenek?

"hanem attól hogy meghibásodás esetén mennyire gyorsan lehet működő állapotba hozni."

A Linuxnak megvan az a nagy előnye, hogy ha problémád van, akkor akár közvetlenül a fejlesztőkkel is levelezhetsz a probléma megoldásával kapcsolatban (ez egyébként igaz a többi nyílt forrású OS-re is, nem csak a Linuxra). Nem ritka, hogy egyes bugokat ilyen módon és meglepően gyorsan (igen, nekem is volt már rá példa, hogy így segítettek) oldanak meg. Az is lehet, hogy nem csak a kérdéses cég szakemberei, hanem valaki más is foglalkozik vele tök függetlenül. Elképzelhető, hogy működő patchet kapsz pár órán belül. Újrapörgeted a kernelt, és elképzelhető, hogy működik. Ezt egy kereskedelmi OS-nél nem tudom elképzelni. Ott majd jön a javítás a következő service pack-kel (vagy patch cluster-rel, cégtől függően), de az is lehet, hogy csak hónapok múlva. Persze ha nagy pénzed van, akkor jöhet guru neked repülővel, elemezhet crash dumpot, és pörgethet neked kernelt a commercial OS-en is, csak győzd fizetni a milliókat.

Vannak mindegyiknek előnyei is éppugy mint hátrányai.

Azt azért ne kelljen megkérdeznem, hogy egy kereskedelmi termék (és most nem csak OS-ről beszélek) is csak akkor vállalati, ha

- megveszed a pénzes szupportot (mondjuk a 4-6 órásat)
- ha Phone Home és egyéb rendszert futtatsz (pl. WEBES, ISEM, ISEE) a rendszereden
- és sok sok money-t aprítasz bele

Példa miatt nézzük egy nagy cég szupportját, hogy az miből áll:

Megkülönböztetünk többfajta támogatást:

- alapvető (foundation service solutions)
- proaktív
- reaktív

Az alapvetőt felejtsük el, nincs benne semmi, csak a kiszállítás, tervezés, install, meg egy marék jótanács.

A proaktív az megkapod még a szoftver frissítéseket meg a dokumentáció
frissítéseket.

Ez eddig nagy 0.

Az igazi szupport a súlyos pénzekért csak itt indul, a reaktívnál, amiben már van 7x24 órás rendelkezésre-állás és folyamatos problémamegoldás, "betelefonálás" és hibaelhárítás, stb.

Ha van még több lóvéd, akkor van még critical service solution, amiben
6 órás "hívástól a javításig" megoldás, kijelölt kapcsolattartó és az összes korábban felsorolt szolgáltatás van. Csak győzd megfizetni. Nem kell hangsúlyoznom, hogy ezeket kik tudják és akarják kiperkálni. Ha nagyon összeszerem magam, akkor se sokan.

Szóval ezek a céges szupportok is csak bizonyos esetben _és_ bizonyos _nagy_ lóvék befizetése után állnak rendelkezésedre. Alapesetben nem nagyon kapsz többet, amint amit egy Ubuntu nyújt, azaz telepítő média, security figyelmeztetők, hosszú támogatási időszak (5 év), és a patchek rendelkezésre bocsátása. Az összes többi szolgáltatás pénzért jön. Nem kevés pénzért.

--
trey @ gépház

Igazad van. Lehet az a probléma velem, hogy mindig is nagyvállalati szemszögből néztem ezeket a dolgokat, ahol a support-ot megvenni többé-kevésbé magától értetődő dolog.

Hogy az EVA-val nem problémád, az abból adódik, hogy a disk-eket nem zavarja olyan módon a SCSI reset mint a szalagegységeket. Azokat is csak annyira, hogy jó eséllyel visszatekernek. Ami ugye disk-en értelmezhetetlen.

Lehet, hogy opensource OS-nél levelezhetsz az ALKOTÓVAL is, de ez sehol nem garantálja, hogy Ő időben és jól válaszol. Ráadásul feltételezed, hogy a vállalatoknál olyan az üzemeltető gárda, hogy képes egy OS írójával levelezni és az iránymutatásuk alapján megoldani a saját problémáját. Ez lenne az ideális, de sajnos nincs így. Ha viszont van support szerződésed - és az ésszel lett megkötve - akkor a támogató cég akár anyagilag is érdekelt lehet a probléma mihamarabbi megoldásában. Mondjuk amúgy is, hiszen kinek hiányzik hogy rossz híre kerekedjék?

Szóval vállalati szinten alkalmas-e a Linux server operációs rendszernek? Kis költségvetésű vállalatok esetén mindenképp, de akkor el kell fogadniuk a korlátait. Nagyvállalati környezetben is el tudok képzelni olyan szerepkört ahol egy Linux server dolgozik, de a magas rendelkezésre állást igénylő, "mission critical" alkalmazásaimat azért inkább kereskedelmi UNIX-ra tenném.
Nem kérdéses melyikre. ;-D

Ave, Saabi.

"Lehet, hogy opensource OS-nél levelezhetsz az ALKOTÓVAL is, de ez sehol nem garantálja, hogy Ő időben és jól válaszol. Ráadásul feltételezed, hogy a vállalatoknál olyan az üzemeltető gárda, hogy képes egy OS írójával levelezni és az iránymutatásuk alapján megoldani a saját problémáját."

Nem, nem, nem. Félreérted. Vállalati _és_ nyílt forrásúról beszélek. Pl. Linux vagy Solaris. Ha gondod van, akkor a céges támogatás vonalon is elindulhatsz (amiért fizetsz, és megvannak az előnyei annak ami a kereskedelmi és zárt forrású OS-eknek), de ezzel egy időben írhatsz problémáddal a támogatási listákra (vagy ilyen a Red Hat-nek, ahol egy rakás kernelfejlesztő figyel s válaszol), az LKML-re vagy egyéb más helyekre is. Mindig van, aki érdekődést mutat a problémákra. Nekem a múltkor egy géphez driver kellett, írtam a listára, elküldtem a pci azonosítót, másnap reggelre jött a pár soros patch, és lám működött.

Szerintem ebben nagyobb a lehetőség.

"Ráadásul feltételezed, hogy a vállalatoknál olyan az üzemeltető gárda, hogy képes egy OS írójával levelezni és az iránymutatásuk alapján megoldani a saját problémáját."

Ennyi azért elvárható egy felelős rendszergazdától. Mármint minimális problémamegoldó képesség. :-)

"Ha viszont van support szerződésed - és az ésszel lett megkötve - akkor a támogató cég akár anyagilag is érdekelt lehet a probléma mihamarabbi megoldásában."

Ez fennáll itt is lehetőségként. Ha veszel egy dobozos Windows 2003 Server-t, ahhoz milyen komoly support jár? Semmi. Pénzért jár. Ez így van a SUSE és a RHEL esetében is.

"Szóval vállalati szinten alkalmas-e a Linux server operációs rendszernek? Kis költségvetésű vállalatok esetén mindenképp, de akkor el kell fogadniuk a korlátait."

Erről kérdezzük meg a Red Hat-et vagy a Novell-t. Mindegyik sikeres évet tudhat maga mögött.

"Nagyvállalati környezetben is el tudok képzelni olyan szerepkört ahol egy Linux server dolgozik, de a magas rendelkezésre állást igénylő, "mission critical" alkalmazásaimat azért inkább kereskedelmi UNIX-ra tenném."

Rengeteg más helye lehet egy Linux szervernek a vállalatban. MAIL, infrastruktúra szerver (DHCP, DNS, stb.), Proxy, tűzfal. stb. Az a baj, hogy a vállalati felhasználásról mindenkinek az SAP meg ilyesmi jut eszébe. Pedig mennyi minden van még azon kívül....

Senki sem vitatja, hogy a UNIX-nak is megvan a piaca. A fent említett EVA-t éppen egy Red Hat ES, két HP Integrity (HP-UX) és 10-15 darab Windows szerver használja. Ugye, hogy mennyi mindennek lehet helye egy
cégnél? :-)

--
trey @ gépház

1. Nekunk erdekes modon pont ellentetes tapasztalatink vannak :) Szoval van akinek szerencseje van van akinek peche (vagy nem ert hozza elegge azert sziv).
2. vannak pl olyan megoldasok amitol az ember elhanyja magat, es azt allitja o 5 perc alatt ir jobbat. Ja lehet. Csak azt nem tamogatja XYZ ceg. A vallalati szintu az az, hogy van ra support attol lehet barmilyen jo vagy szar is a cucc, nem ettol fugg, azt kene vegre felfogni.

Szoval ez ilyen jatek ...

ilyet nem tudok, pedig tenyleg jopofa dolog. persze semmit sem er korrekt support nelkul. anno 2-3 naponta random befagyo aix 4.3.x-en rendszeresen gyartottunk es tape-re mentettunk le crashdumpot, amit az ibm ha akart volna, ki is elemzett volna. a tisztelt support mernok kijott es mindig elvitte a kazit, aztan semmi reakcio. egy ido utan annyit nyogott ki, hogy restartoljuk cronbol, hiszen az osanban is volt ilyen hiba es ott ez bevalt. nekunk meg a fejunket akartak leszedni, hogy nem megy a masina, no comment. alap h70, scsi-n a system, ssa-ben nehany disk raid5-ben, plusz egy 3570 csatolva hozza, semmi kulonleges a configban. masik esetben (teljesitmeny szempontbol) hulladek ppc-re linuxot huztunk. termeszetesen itt is adodott gubanc, tobbszor kernel panicba futottunk. reportoltam, morton tolta vissza az arcomba a patchet masnap, mindenki happy volt. de ezt nem tudom elmagyarazni a donteshozoknak, akik a supporttal a covering your ass jatekot folytatjak, es valahol az o dontesuk is ertheto. talan a legjobb kombinacio az open source, de uzleti alapon is tamogatott szoftver, es itt sem mindegy a tulajdonosi kor fele, hogy a red hattel vagy a pistike ubuntu bt-vel szerzodunk most meg. remeljuk a canonical tenyleg tud minosegi supportot adni az egyebkent remek rendszerehez.

"ps: konkrét tapasztalat, a crashdump-tól függetlenül: SAN-os környezetben a linux-os gépek induláskor mindenképpen kidobtak egy SCSI reset-et a SAN-ra. Mindig. Ez kissé megzavarta a SAN-on lévő tape-re dolgozó egyéb masinákat. Szar ügy ugye a menet közben visszacsévélődő szalag. Megoldás tudtommal még nincs."

Bocs, de Windows környezetben az NT backupnak számtalan hibája van, ismert / ismeretlen. Ettől függetlenül botorság lenne részemről kijelenteni, hogy a Windows 2000 Advanced Server nem vállalati szintű operációs rendszer. Ilyen példákat bármely operációs rendszerre lehetne hozni attól félek.

--
trey @ gépház

Nem, ekkora hibát még a Windows Server-ek sem vétenek. Nem arról van szó, hogy egy Linux serveren futó backup software elrontja a mentést, hanem arról, hogy egy bootoló linux server kernelében lévő FC driver küld SCSI reset-et a SAN-on lévő eszközöknek. És ezzel azoknak a gépeknek rontja el a mentését, amik amúgy köszönik szépen jól elvannak és éppen a dolgukat végeznék.

Ave, Saabi.

Jaja, milyen kártya, milyen linux, milyen driver, milyen san?
Mert sokszor az ilyen "apróságokat" pl egy kártya- vagy san-szállító által adott driver szokott megoldani. Ahogy pl a HP szerverekhez is használhatod az alap tg3 hálókari drivert is, meg a HP által adottakat is. Régen ez megoldás volt nekünk például egy érdekes bonding problémára. De san gondot is oldott már meg EMC-től kapott driver... :)

Levlisták. Nem emléxem, kb 3 hete olvasgattam bele mélyebben a témába, mikor megvilágosodtam, hogy "Hé, hova tűnt a cpqfc driver???".
Aztán kicsit körbeszaglásztam, megkérdeztem MKP-t, hogy áll a tachyonnal, közben akadtam bele a target mode-os anyázásokba...
Szóval nem tudok pontos linket, de ha ragaszkodsz hozzá, kikeresem a MARC-ból.

Csakhogy a SCSI resetet nem a HBA-k kapják meg, hanem a magnó. Ha pedig elrejtem a magnót a Linux-ok elől, akkor a Linuxokat nem lehet menteni.
Amúgy szerintem a magnó nem SAN-ra való és a mentéseket inkább gigabit ethernet-en érdemes csinálni egy vagy több mentő-server-rel, valódi lokális eszközökkel, ahol a server és a magnó közötti kommunikációt kizárólag egy kisbalta akadályozhatja.
De ettől függetlenül nem illik SCSI resettel bombázni egy SAN-t induláskor.

Ave, Saabi.

Hát csak régen volt lehetőség egy érdekes témán filozofálgatni, meg amúgy is elég hideg van ma, kinek van ilyenkor kedve kimenni a szabadba? Inkább habzó szájjal bizonygatjuk a magunk igazát, pedig tudat alatt sejtjük, hogy a másik csak azért sem fog nekünk engedni :-)