[Tárgytalan] IBM HS12 - Debian - SAS

Debian GNU/Linux

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. ;)

  • 4199 megtekintés

( _ventura_ v | 2012. 10. 25., cs – 10:39 )

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

( cstamas | 2012. 10. 25., cs – 11:23 )

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.

( STP | 2012. 10. 25., cs – 18:44 )

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

( hrgy84 | 2012. 10. 26., p – 00:22 )

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

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

"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).

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

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!

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

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