[Tárgytalan] IBM HS12 - Debian - SAS

 ( toshy | 2012. október 25., csütörtök - 10:33 )

Sziasztok.

Volna egy kis problémám, és mielőtt komolyabb erőfeszítéseket tennék valamelyik irányba, szeretnék itt is tájékozódni.
Érdeklődnék tapasztalatokról.
Adott egy IBM HS12 -es blade egy blade centerben.
Támogatott OP -között RH, SuSe. A helyzet az, hogy egyiket sem akarom, és nem az anyagiak miatt. Ne menjünk ebbe bele nem szeretnék flame-et indítani.
Egy bizonyos határokon(erőfeszítéseken) belül én erőltetnem rá a Debian-t.
A gond az, hogy a benne lévő SAS disk-eket nem látja :(
Gondoltam ki vadászom a hivatalos RH driver-rek közül a SAS meghajtók driver-ét, és megpróbálom hozzá kalapálni.
Van esetleg bárkinek bármilyen tapasztalata a fentiekkel kapcsolatban ?
Már arra is gondoltam, hogy nem teszek bele disk-et és SAN -ról bootoltatnám.

A segítségeket előre is köszönöm.

Update: Sajnos eldőlni látszik a probléma. Egyébként Wheezy -vel sem ment. De különböző jogi, és licence -lési okok miatt kénytelen leszek RH-t tenni rá.
Köszönöm az építő jellegű hozzászólásokat.
Meg a többieknek is. ;)

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ő.

Az a gond, hogy azok a driverek, megadott kernelhez készülnek. Így valószínű debian alatt nem fog menni. Viszont pl. CentOS alatt valószínűbb

Azonkívül nekünk van pár HS20, HS21 es blade azokon lévő vezérlőt még a debian 5.0 is felismerte.

Egyik helyen ahol blade + SAN van, se raktam debian-t mert a debian telepítőnek alapból nehéz volt megmondani hogy SAN-ra települjön, CentOS-nél out-of-the box működött.

Fedora 17, Thinkpad x61s

Nagyon csodalkoznek ha debian alatt nem mukodne.
Ugye wheezy-vel probalod? (firmware-es telepitovel?)

Pont ebben a setupban nincs bladeunk, de mas kiepitesben (FC storage) van es szinte csak debiannal hasznaljuk.

Sarge-al probáltam, nettes install.

a sarge kb 2005 ben jelent meg kb 3 évvel előbb mint a hs12
Szerintem felejtsd el, tegyél újabb debiant. Tuti látni fogja a vezérlőt, és ajánlatos a fent említett firmwarekkel bővített telepítőt használni.

Fedora 17, Thinkpad x61s

Mea culpa.
Nem vagyok annyira tisztában a kód nevekkel, DE szerintem a legújabbal próbáltam, ezzel:

http://cdimage.debian.org/debian-cd/6.0.6/i386/iso-cd/debian-6.0.6-i386-netinst.iso

Esetleg valamelyik nem hivatalos debian installerrel próbálkozni, hátha azok látják?

http://kmuto.jp/debian/d-i/

ez még squeeze (még ez a stable release), inkább a wheezy-vel próbáld!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

jogos. most töltöm le !

rendszergazdakent nem tudni, hogy abbol a disztrobol amit epp telepitesz mi a legujabb = uberfail

És mégis forog a föld :D

Amiből építek/építenék az a 6.0.6 -os.
Amit használhatok az a 6.x.
A testing -el kipróbálom, de nem használhatom.
Egyébként upgrade -elem a topik indításom, mert eldőlni látszik.
RH lesz.

mast nem is erdemes.

Hú, ha látnád a teljes képet...

Sarge?
Az egy őskövület már (2005-ben adták ki). Security fixeket se adnak már ki rá...

:DDD lol welcome to 2012

Majd 2021-ben HS21-el próbálkozik. (Ha még lesz.)

-

-

Mennyit adnál LS21 darabjáért? (4 ill. 8G RAM) ;)

Ez egyebkent hozzaallas kerdese. Ha egy szerver gyartoja csak X es Y disztrot tamogat, akkor azt kell ra tenni, es erdektelen a szemelyes preferencia, meg kb. minden mas is. Mert azzal lesz stabil, azzal van tesztelve, es valoszinu a support nagy ivben sz@rni fog a fejedre, ha hibat jelentenel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ez becsülendő hozzáállás, csak visszanyal, amikor az üzemeltetni kívánt - muszáj - app meg másik disztrót/verziót igényel :D

Vagy ha a support olyan, hogy akár ne is lenne. Persze a felelősség áttolását megoldja :D

Namost nagyon keves olyan app van, ami pont Debiant igenyelne maga ala. Ami enteprise app csak letezik, annak a 95,5%-at RPM alapu rendszerekre (ezen belul SUSE es RedHat) irjak, ajanljak es tamogatjak. Innentol maga a kerdes veszti ertelmet.

Egyebkent meg ertelmes helyen nem csak ugy vesznek egy szervert, mert milyen fasza dolog az, ha van egy IBM szerver az elocsarnokban, hanem megnezik, hogy az app mit igenyel, es ahhoz vesznek szervert.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem debiánnal jártam így. Pont RedHattal és IBM vas, amint az X verziójú kernel volt támogatva, ám az app leírásában az Y verziójú kernel volt feltüntetve mint támogatott, és az Y kisebb volt mint X.

Értelmes helyen igen :D Máshol meg úgy, ahogy lehet/sikerül.

"Máshol meg úgy, ahogy lehet/sikerül."

Pl. MOST van rá tőke, MOST tudod, hogy mit kell szolgáltatnod, de fogalmad sincs és nem is lehet, hogy akár holnap még mit (további keretnek akár csak a reménye nélkül is), de a tapasztalataid alapján az az egy biztos, hogy sok MÉG VALAMIT igen.

Pontosabban még egy biztos: a rendelkezésre álló specifikációk mennyiségétől és minőségétől függetlenül az örök hülye szerepe ki van osztva.

Mivel a topicindító a kollégám, kb. sejtem, hogy milyen alapon megy a gépbeszerzés (nem szabad normális felállást elképzelni), és azt is tudom, hogy az RH/SUSE miért mostoha: üzemeltetési szempontból maximálisan racionális okai vannak. Bizonyos egyéb kényszerítő körülmények miatt az RH a pofozógépbe beüléssel egyenértékű (az említett személyes szempontból csak időgépbe beüléssel).

Ezt kifejtenéd részletesebben is? Mármint hogy miért nem jó a RHEL (az árától függetlenül)?

A mindenkori RH szerver csomaghalmaza - egyébként érthető, de nem minden helyzetben racionális biztonsági okokból - jellemzően évekkel van lemaradva a világtól. Persze ez a lemaradás kevésbé igaz a fixekre (de ott is jelentkezik, ami kínos, ha globálcéges fixelési határidőket kell betartanod), mint a utilitykre. Utóbbi nyilván nem lehet prio1 egy üzemeltetésben, de nem is kellemes, amikor az üzemeltetés elsősorban automatizált akar lenni, és nem egyébként szofisztikált (vagy annak szánt) gui löködéséből és bámulásából áll.

Ezt megfejeli az, hogy ha az RH oldalán valami nem megy, akkor az a fizetős enterprise - a free stabil.

Szóval ahhoz képes, hogy hajdan CHIP CD-n lévő RH 4.* szoktatott át, és a mai napig jobban jönnek fejből az rpm paraméterei, mint a dpkg-i, szerveren utálom, mint kukoricagölödint.

Mondjuk az áhított Debian pont nem a frissességéről híres.
Leellenőriztem, hogy a squeeze ugyanannál a kernel verziónál tart, mint a RHEL6.3 (2.6.32). Tehát nagyságrendileg egy szinten vannak. RHEL alatt ugyanúgy meg lehet csinálni mindent gui nélkül is, lévén a default "Basic install" opció választása esetén nem is települ fel X server.
Ellenben ha vmi enterprise programot szeretnél rá feltelepíteni (pl. bármelyik Tivoli termék), akkor Debiannal nem sokra mész...

Es a Debian mogott a vilagon semmilyen tamogatas nincs - ehhez kepest az RH mogott sokkal tobb van. Azt meg mar ne is feszegessuk, hogy milyen minosegu munkat vegez a "community" es milyet a RedHat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

De nem szeretnék, van elég bajom anélkül is.

Ha egyszer átsétálsz a 7-esbe, szívesen elmondjuk, mikkel kell szembenézned, ha az RH-hez kötöd magad, _miközben_ feszt disztribverzió váltására nincs lehetőséged, _miközben_ a corporate előírásokat folyamatosan be akarod (mert fővesztés terhe mellett be kell) tartani.

Ha az utóbbit lehetőséged van lesajnálni, akkor persze nem csak RH, de bármi lehet szimpatikus.

Csak azt nem értem, hogy ebből a szempontból a Debian miért jobb választás.
RHEL esetében rendszeresen jönnek ki az alverziók, melyek úgy-ahogy tartalmaznak frissebb verziójú szoftvereket, míg Debian esetében "majd kiadjuk ha kész lesz" ígéretnél több nincs. Debiannak annyi előnye van, hogy hozzáférhető a mindenkori testing/sid ág is, onnan lehet szemezgetni csomagokat. De ennyi erővel a RHEL7 alpha-ból is ki lehet másolni rpm-eket...

Ha tudod ki vagyok (amiben nem vagyok biztos, lévén a 7esben van az asztalom), akkor küldhetsz mailben pár példát, ami megoldhatatlan volt RHEL alatt. Köszi!

Vagy akar kiteheti publikba is, megfeleloen anonimizalva. Masokat is erdekelhet.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nagyon anonimizálva megtehetem.
Ahogy említettem, háromszereplős a játék, az OS és egyebek, a globális céges előírások, amelyek annyit tesznek lehetővé, hogy adott határidőig tedd fel egy ismertté vált szekhól fixét, és mi.
Jellemző forgatókönyv: értesítés új apache sebezhetőségéről. Ellenőrzöd, tényleg létezik a bag. A megoldást jelentő .tar.gz már ott az apache.orgon, de sajnos a RH repóban még semmi. Túlmész a határidőn, jönnek kötelező magyarázkodó körök nemzetközi szinten:
- miért nincs még fenn?
- mert még nincs rpm.
- lehetne máshogy?
- lehetne, de nem a helyben forgatás volna a módja.
- akkor a másikon ez miért nem jön elő?
- mert az debian, és deb viszont van.
- és mikor lesz rpm?
- (...)

Aláírom és aláhúzom, hogy ahol a globális szereplő nem lép képbe, ott ez a probléma nem, vagy nem így jelentkezik, de ezt a topicot a mi saját nyűgünk ihlette.
Sőt azt is elhiszem, hogy az rpm repók jellemzően frissebbek, mint a deb repói, csak nem ez a tapasztalatunk, pedig kifejezetten örülnénk ellentétes tapasztalatoknak.

- o -

Azt egyébként soha semmilyen *xon nem tapasztaltuk, amit hajdan PPC-s SLES esetén (hálistennek már nincs meg, tán 8.2 volt), hogy bármilyen júzer crontab listájának szerkesztése után a crond az újraindításáig a régi listával dolgozzon.

Jellemzően a RH nagyon gyorsan reagál az ismerté vált security bugokra.
A gond inkább az lehet, hogy corporate szinten nem a legújabb apache verziót kellene elvárni, hanem azzal is meg kellene elégedni, amiben a disztribútor javítja az adott sebezhetőséget. RH nem ugrál verzióról verzióra, hanem backportolják a fixeket.

Egyébként ez nem gond AIX esetében? Az sokkal lassabban frissül, minden opensource komponense évekkel lemaradottabb a mainstream linux disztrókhoz képest, mégis üzemeltetni tudják/tudjátok a szervereket...

A szitu pontosan ugyanez, és pontosan ugyanígy el kell magyaráznunk, ha beköszönt a narancssárga/piros időszak, hogy az IBM még nem adott ki hivatalos fixet, hiába tud megoldásról a nessus.

Ha hátralépek kettőt, és kívülről nézem, én is csak röhögök rajta, de ez BAU.

Akkor most rakjunk rendet.

Eloszor is, ahogy elottem is mondtak, ez RedHat eseteben nem verziotol fugg, hanem security update-tol. Vagyis ha elolvasod a RedHat bejelenteseit is, es tenyleg nincs fixalva az a bug, akkor vagy erintett. Van olyan secu oldal, ami egy-egy CVE bejelenteshez linkeli az idokozben bejelentett es kijott fixeket, csak fejbol nem tudom, melyik az. Ilyenkor lehet azt mondani, hogy igen, de nekunk nem kell frissiteni, mert az oktober tizenhatodikai update-tel lejott ez a fix.

Aztan: Debian es RedHat kozott ugye nem a verzio a kulonbseg, hanem az, hogy ha RedHat cuccra 3rdparty cuccot raksz fel (pontosabban olyan cuccnak a 3rdparty verziojat, amit a rendszer maga is tartalmaz), akkor ugrik a support. Mert hogy ugyebar az allitassal ellentetben a legtobb esetben VAN rpm, vagy ha nincs, viszonylag konnyen legyarthato, csakhogy az mar 3rdparty-nak szamit, tehat nem lesz supportod ra.

Ez persze elohozza azt a kerdest, hogy ezt miert nem kommunikaljatok le a RedHattel. Ha van ervenyes supportotok, akkor ra lehet kerdezni, hogy vat iz de ETA for disz bug. Es akkor mondanak valamit, vagy nem, de ezzel megint elorebb lennetek, es el lehet mondani, hogy igen, nem jon valasz a tamogatastol. Es ez nem a felelosseg elkenese, hanem eszkalacio, hiszen ezert fizetitek a nyomorult supportot.

Ha nincs - vagy mar nincs - supportotok, akkor meg megint nem ertem a kerdest, mert akkor meg irrelevans, hogy raksz-e fel 3rdparty RPM-et. Es altalaban van olyan RPM, foleg azert, mert ha valami RedHat alatt bug, akkor az jo esellyel CentOS alatt is bug. Es azert van egy aktiv kozosseg a CentOS mogott.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

tudomásom szerint az RHEL visszaportolgatja a featureket/drivereket abba a 2.6.32-be, míg a debian csak sec fixeket tol bele.

Fedora 17, Thinkpad x61s