Shery és RePa

Már nem az első Intel SR2400-asra teszek mostanában Solarist, és míg kezdetben az upgrade 6 gond nélkül kezelte a vasat, addig az utóbbi két gépen a 7-es megtréfált.

Első ránézésre minden oké, az ember lelkesen telepít, csak úgy hasít a gép, jönnek le a csomagok jó gyorsan, minden szép és jó. De aztán felkerül mondjuk a webszerver, és ekkor kiderül, hogy kifele irányba csúfondárosan lassú a hálózat.
Az első ilyen esetben persze egyből arra gyanakodtam, hogy valami gond van az alaplapi hálókártyával, tettünk bele másikat - szintén Intel, szinte ugyanaz a chipset -, és a probléma megoldódott.

Azonban ma újra belefutottam a problémába, és ekkor felmerült bennem a gyanú, hogy nem lehet minden gép hálókártyája rossz. Rákerestem, és másnak is volt hasonló problémája.

A Sun oldalán megnéztem, azóta van újabb kernel patch, gondoltam felteszem, a bűnös e1000g driver is frissült, nade a sunsolve ma sztrájkolt, vagy nemtudom, de még a szerződéssel rendelkező volt Siemenses kollégák se tudták letölteni, ami nekem kellett. Viszont eszembe jutott, hogy a solarisos srácok büszkék arra, hogy a kernel driver API-ja atomstabil - ellentétben a Linuxéval -, ezért gondoltam egyet, és az egyik jól működő update 6-os Solarisról fogtam a drivert, szépen felülmásoltam az új/beteg kernel modult a régivel, bootadm update-archive, reboot, és lőn csoda, a gép nemhogy bebootol, de tökéletesen működik. Öröm.

A másik nagy öröm pedig az, hogy Émike már nyugodtan eszi a jutifalatot a vállamon, és nem akarja bementeni valami biztos helyre

Muninhoz nem találtam olyan scriptet, amivel a Solaris memória foglaltságát lehetne ábrázolni, úgyhogy Brendan munkájából kiindulva alkottam egyet. Használd egészséggel.

Gondoltunk egyet Balázzsal, hogy megnézzük hogy megy a Solaris live upgrade funkciója, méghozzá úgy, hogy egy softraid/UFS alapú rendszeren csinálunk egy ZFS alapú új boot környezetet (Sol10 update 6 végre bootol ZFS-ről is, és sparcon olyat még én sem láttam). Próbáltunk előre guglizni, hogy vajh mekkora sikerre számíthatunk, de ilyet nem nagyon találtunk csak UFS-UFS és ZFS-ZFS verziót.

A művelet annyi volt, hogy csináltunk egy új ZFS dataset-et, meg csak nem is külön vinyóra, aztán jöhetett a live upgrade környezet létrehozása:

# zpool create rpool mirror c3t0d0s6 c3t1d0s6
# lucreate -p rpool -n alma
... másol, másol, másol ...
# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
d10                        yes      yes    yes       no     -
alma                       yes      no     no        yes    -
#

Átmásolta az egész mindenséget (/root, /var) az új helyre, ez eltartott egy ideig, de végül minden hibaüzenet nélkül végzett. Upgrade-elni nem upgradeltünk semmit, mert alapból zsír friss volt a gép, amin játszadozhatunk, úgyhogy jöhetett a lényeg, a boot környezet aktiválása, és a reboot:

# luactivate alma
... elmondja mit kell tenni, ha mégsem bootol be ...
# init 6

És láss csodát, gond nélkül felbootolt sparc rendszeren a ZFS root-tal rendelkező Solarisunk.

Csak próbaképp létrehoztunk még egy új környezetet, ez viszont nem tökölt már a file másolgatással, ZFS snapshottal készült, és cirka 12 másodperc alatt a rendelkezésünkre is állt. Ez igen.

A műveletet tegnap befejeztük, éljen az open source, és az OpenSolaris fejlesztők, akik nélkül nem jöhetett volna létre pl. a gani driver, ami pöccre begyújtotta a Linksys chipes Realteknek keresztelt kártyát.
Következik a zónák - és bennük a szolgáltatások - felépítése, kíváncsi vagyok, hogy a Solaris hogy muzsikál x86 hardveren.

Csykin beszerzett egy relative erős (bár desktop jellegű) gépet, amin fel akarjuk építeni a rendszerünket, mindent szépen külön zónában.

Az install igazából totálisan painless volt, OK, OK, OK, 'ZFS legyen a root?', hogyne, OK, kész. SATA vezérlőn látszik a vinyo, megvan mind a négy processzormag, az összes memória, szuper, látszik azért, hogy az OpenSolarisból szívárognak vissza a dolgok. Nade a halókártya.

Az alaplapon csücsült egy RTL-8168 jelzésű eszköz, amihez érkezik is a Solarisszal rge néven driver. Rábeszéltük, hogy betöltse, ifconfig rge0 plumb, örül. De nem sokáig, mert hiába kap IP címet az interface, kb. semmi reakció, illetve még rosszabb, ~száz elküldöttből egy beérkező csomag. Google segít, ezzel az alaplappal ez bizony Linux alatt is megesik.
Sebaj, szekrényben ott figyel egy RTL-8169 jelzésű PCI-os hálókártya. Beszerel, bekapcsol, de a driver nem töltődik be. A prtconf megmondja az eszkoz PCI azonosítóját, és bizony az nem a klasszikus 8169-hez tartozó, hanem egy másik. Linksys oldalán van hozzá driver, tökjó, nade az 32 bites... Czo holnap még próbálkozik egy open source driverrel, de a vére folyna ki az összes hálókartya gyártónak, aki különböző eszközöket ugyanúgy nevez el.

Nem haszontalan a Solaris 10 azon tulajdonsága, hogy észreveszi előre, ha meg fog halni a gép. (Bár lehet, hogy csak megfelelő hardver esetén képes erre.)

Az alábbi üzenetet egyik webszerverünk produkálja:

SUNW-MSG-ID: PCIEX-8000-5Y, TYPE: Fault, VER: 1, SEVERITY: Critical
EVENT-TIME: Wed Oct  1 16:09:44 CEST 2008
PLATFORM: SUNW,Sun-Fire-480R, CSN: -, HOSTNAME: ssrv35sd
SOURCE: eft, REV: 1.16
EVENT-ID: 6e1de556-842e-e410-8b42-ba2dfbc7f99c
DESC: The transmitting device sent an invalid request.
  Refer to http://sun.com/msg/PCIEX-8000-5Y for more information.
AUTO-RESPONSE: One or more device instances may be disabled

IMPACT: Loss of services provided by the device instances associated with this fault

REC-ACTION: Ensure that the latest drivers and patches are installed. Otherwise schedule a repair procedure to replace the affected device(s).  Use fmdump -v -u  to identify the devices or contact Sun for support.

Kifejtve:

Oct 01 17:55:43.0157 6e1de556-842e-e410-8b42-ba2dfbc7f99c PCIEX-8000-5Y
   50%  fault.io.pci.device-invreq

        Problem in: hc://:product-id=SUNW,Sun-Fire-480R:server-id=ssrv35sd/motherboard=0/hostbridge=1/pcibus=0/pcidev=1/pcifn=0
           Affects: dev:////pci@9,600000/network@1
               FRU: hc:///component=MB
          Location: MB

   50%  fault.io.pci.device-invreq

        Problem in: hc://:product-id=SUNW,Sun-Fire-480R:server-id=ssrv35sd/motherboard=0/hostbridge=1/pcibus=0/pcidev=2/pcifn=0
           Affects: dev:////pci@9,600000/SUNW,qlc@2
               FRU: hc:///component=MB
          Location: MB

Egyelőre a beteg hálózati interfacet kikapcsoltuk, meglátjuk segít-e. Full hardver teszt persze semmi hibát nem mutat. Eszünkbe jutott az is, hogy kicseréljük az egész gépet, csak a winyók maradnak, de ha mégis valami szoftveres hiba, akkor ezt is hiába. Ötletek?

Egyébként sem unatkozok, erre jön egy levél, hogy:

***** Nagios *****

Notification Type: PROBLEM

Service: load
Host: ssrv21sd: ray server
Address: 163.242.213.78
State: WARNING

Date/Time: Fri Sept 5 10:23:42 CEST 2008

Additional Info:

WARNING - load average: 17.42, 19.68, 14.32

Mivel a gépben kettő darab processzor van, ezért a 20 körüli load az nem olyan jó. (Most hogy a helyzet normalizálódott, már csak 0.25...) Ember belép, megnézi prstat/top, semmi. Első gondolat, hogy itt bizony valami lelkesen forkol (azaz szaporítja magát). Ezt nem olyan egyszerű elkapni, de szerencsére Solaris alatt ott van nekünk a dtrace:

# dtrace -n 'syscall::fork*:entry{printf("%s %d",execname,pid);}'

És a nem túl meglepő eredmény:

CPU ID FUNCTION:NAME
0 3655 fork1:entry bash 28845
0 3655 fork1:entry bash 28848
0 3655 fork1:entry bash 28851
0 3655 fork1:entry bash 28854
0 3655 fork1:entry bash 28855
0 3655 fork1:entry bash 28859
0 3655 fork1:entry bash 28860
2 3655 fork1:entry bash 28846
2 3655 fork1:entry bash 28849
2 3655 fork1:entry bash 28850
2 3655 fork1:entry bash 28847
2 3655 fork1:entry bash 28853
2 3655 fork1:entry bash 28852
2 3655 fork1:entry bash 28856
2 3655 fork1:entry bash 28857
2 3655 fork1:entry bash 28858
...

Egy-két ps kimenet összehasonlítása után meg is lett a tettes, aki "csak játszott kicsit a .bash_profile-jával". (Sajnos a játékot magát nem tudtam megtekinteni, mert mire oda jutottam már letörölte a disznó dolgokat. Azért a bátrak beírhatják a .bash_profile-juk végére, hogy bash& ) Ezután szerencsére a .bash_profile átnevezése egy idő után megállította a folyamatot, de ha valaki direkt csinálta volna, akkor a destrukív dtrace trükközésen kívül nekem csak a reboot jut eszembe, mint megoldás.

Esetleges jobb megoldásokat kommentbe várom.

[Update] Csak nem sikerült neki mégegyszer ugyanazt, de. Öröm és boldogság.

Ahogy mar a multban nehanyszor, Gabor mai postjara reagalnek, illetve egeszitenem ki.

A screen bizony tenyleg vegtelenul hasznos program, megelegedessel hasznalom mar evek ota, igen hasznos tud lenni, mikor megszakad a kapcsolat a felhasznalo es a lelkesen hasznalt tavoli szerver kozott. (autodetach on) Es szerintem meg az alapertelmezett ^A escape karakterkombinacioval sincs semmi baj, mert - bar en is zsh-t hasznalok, nalam a $EDITOR erteke vim, ezert nekem a ^[I megy a sor elejere. Egyebkent Emacs baratoknak sem kell felni, a ^A a kombinacio elore viszi a kurzort a sor elejere.

Amit viszont en most kiemelnek az a multiuser mod. Bemutatora, tanfolyamra egyszeruen tokeletes. Lassuk hogy megy ez:
Ahhoz, hogy a multiuser mod hasznalhato legyen, a screen-t setuid root joggal kell ellatni. Ezzel azert csak ovatosan, mert komoly bizotnsagi reseket teremthetunk igy.

# chmod u+s `which screen`

Ezutan peldaul ha azt szeretnenk, hogy az oktato felhasznalo tevekenyseget figyelemmel kiserhesse a tanulo felhasznalonk, akkor azt az alabbi modon erhetnenk el:

oktato@host$ screen -S tanfolyam
[elindul a screen]
^A :multiuser on
^A :addacl tanulo
^A :aclchg tanulo -w "#"

A tanulo pedig igy kapcsolodhat a mar futo sessionhoz:

tanulo@host$ screen -x oktato/tanfolyam
[elindul a screen, latszik mit csinal az oktato]

Egyszeruen szuper! Aki tobbre kivancsi, annak ajanlom a man screen parancsot.

Nemreg eszembe jutott - es masok is kerdezgettek -, hogy meg kene merni milyen gyors a zfs.

Hat tul nagy gyakorlatom nincs a temaban, de azert lassuk, hatha le lehet vonni valami kovetkeztetest. tovább...

A zfs az egy disznojo filerendszer, es nagyon sajnalom, hogy liszensz pocskoles miatt kb. sosem lesz linuxra. Meg jo hogy mar a Solaris is ingyenes, sot van belole nyilt forrasu valtozat is.

Mar egy ideje erett a dolog, hogy upgradeljuk a home szerverunket mind tarhely, mind korszeruseg tekinteteben, aztan arra gondoltam, hogy ha mar csinalunk vele valamit, akkor lepjunk nagyot, es legyen rajta zfs.

Na lassuk hogyan is nez ki a dolog, most hogy mar mukodik: tovább...

Tehat a Sun ugy dontott, hogy beszall a adatbazis bizniszbe is, most kb. a csapbol is ez folyik a neten, meg az index is megirta.

De szerintem - es masok szerint is - ennek a lepesnek melyebb strategiai celja is van. (Na persze egy sajat adatbaziskezelo - ami egyebkent a a legelterjedtebbek koze tartozik a vilagon -, sose jon rosszul a haznal, meg hat a supportert is lehet szep penzt kerni.)

Megpedig: kis- es kozepvallalatok koreben meltan nepszeru opensource LAMP modellnek tud lassan a Sun jol mukodo es rendesen tamogatott alternativat nyujtani. Ez lenne a SAMJ , azaz az (Open)Solaris+Apache+MySQL+Java alapu platform. (Igazan szep akkor lenne, ha az Apache helyett valami sajat, jol mukodo opensource webszerverrel is kijonnenek.)
Vegulis minden reszegyseg opensource, ingyen lehet hasznalni, es (majdnem) minden komponponenshez a Sun tud adni olyan supportot, amit senki mas.

A Solaris azert tobb ponton tud olyat mutatni a Linuxnak, hogy az elszegyelli magat, azzal nem is lenne gond. A Javaval viszont bonyolultabb a helyzet. Eloszoris aki eddig phpban "programozott" - tisztelet a kivetelnek - az nem fog megtanulni csakugy hipphopp Javaban (persze a Sun jo penzert mindenkit megtanit ), ott azert mar tenyleg programozni kell, a php-nal jol bevallt ganyolas nem sok eredmenyt hozhat. Es mondjuk nekem szemely szerint is vannak fenntartasaim a Java webes felhasznalast tekintve, plane epp a LAMP-os celkozosseg koreben, na de majd meglatjuk, mit hoz a jovo.

Eszunkbe jutott, hogy mi lenne, ha csinalnank a workstationokre uj Sol10-es flar image-et, mert a regi mar elegge regi. Arra gondoltam, hogy ha mar ugyis benne vagyok, akkor forgatok egy e17-et is bele, hadd oruljon az a 2-3 fejleszto, aki rajtam kivul hasznalna (em mar jo masfel eve azt hasznalok itt is)

Igaz, hogy a regit relative keves hackolassal sikerult leforditani, es az enlightenmentes fiuk elvileg az elejetol kezdve ugyelnek a platformfuggetlensegre (johat, azert X kell hozza), de hat ismerem en a programozokat, ugyhogy aggodtam egy kicsit, hogy nagy faba vagom a fejszemet. Hat felesleges volt. tovább...

Szal, ahogy regebben irtam, csinaltam specko M2Crypto csomagot Solarishoz, mert abban trukkos az openssl. Ma upgradeltem, mert kiderult, hogy annyira trukkos az a szemet, hogy annak ellenere, hogy nincs benne 256 bites AES, azert lejelenti, hogy van:

.( horakgy@sun130sd pts/32 ~ )----
'(14:20:28)% openssl ciphers "ALL"
ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:...

Es bizony mikor ennek az M2Crypto (vagy barmimas) megorul, es lelkesen elkezdi hasznalni, akkor elszall.
Ha kell olyan, ami ennek nem dol be, akkor szedd le innen.

A Solaris 10-ben frissul a python, illetve belekerul a 2.4.4-es verzio is. Ugyhogy az az otletem tamadt, hogy forditsam le ehhez az M2Crypto-t, ami amugy egy openssl wrapper pythonhoz, es igen hasznos tud lenni. Hat nekialltam.

Mar regebben is olvastam valamivel kapcsolatban, hogy pl. az openssl-t, meg hasonlo kriptografiaval kapcsolatos cuccokat nemigen szabad ellenseges (marmint az USA-nak ellenseges) orszagokba exportalni. Dehat azzal is tisztaban voltam, hogy Solarist adnak el Irannak is, abban meg benne van. Viszont ma kiderult hol a csel: a Solarisban levo openssl bizony csak a 128 bites AES-t tamogatja, a 192 es a 256 bitest nem (es meg ki tudja mit sporoltak ki belole). Igy viszont az M2Crypto nemigazan megy vele. Persze tehetnenk fel akarhonnan a netrol leszedett openssl-t, es fordithatnank azzal is, de szamomra ez nem volt megoldas, ezert picit megpiszkaltam a forrast, es minden AES fuggvenyt a 128 bites valtozatokra mappeltem at.

Egyelore ugy fest mukodik, ha valakinek szuksege van ilyen csomagra (mert nekem pl. volt, de nem talaltam sehol), akkor az szedheti is iziben.

Enter baratom olyan problemaba utkozott a minap, hogy a tar letrehozta siman a 2 giganal nagyobb filet, aztan a gzip ezt lelkesen ossze is tomoritette, de utana egyik se akarta kibontani a sajat termeket. (Elvileg a legujabb verziokban ez a problema mar ki van kuszobolve, de mindenkepp kellemetlen.)

A problema oda nyulik vissza, hogy 32 bites rendszereken a maximalis elojeles egesz szam (intetger) az 2147483647 - azaz 2 giga. A filerendszerek is e kore a varazs szam kore epultek, ezert regebbi rendszereken a maximalis file merete is ekkora volt - igy nem volt gond, ha a programok nem kezeltek az ennel nagyobb fileokat.

Sot, igazabol ha nekem valaki 10 eve azt mondjak, hogy ma lazan szukseg lesz majd ~4 gigabyteos fileok kezelgetesere (lasd. dvd image), akkor en azt kirohogtem volna. Ezert kicsit meresz lenne ma azt kijelenteni, hogy pl. az XFS, ami 64 bites, az najd eleg lesz nekunk orokre, "64 bit-nel nem kell nekunk tobb, mikor lesz nekunk 8 exabyteos (9223372036854775808 byte) fileunk". (Egyebkent szerintem sokara...)

Igy gondoltak ezt a sracok a Sun-nal is, amikor megcsinaltak a ZFS-t, ami mar 128 bites. A maximalis filemeret itt 16 exabyte (igen, "csak" ketszer annyi), de az ut mar meg van jelolve

Palyafutasom soran azert talalkoztam egy-ket biztonsagi ressel, de ez a mai magasan viszi a primet. Addot ugye a Solaris 10, ami ugyebar the most secure OS on the planet. Fogja az emberke magat, beirja, hogy:

# telnet -l "-froot" <solaris10eshost>

Es lon, maris bent van a vilag legbiztonsagosabb oprendszereben, rootkent, mindenfele jelszo nelkul. Erre mondjak, hogy odabasz. Ertem en, hogy akinel futa a telnet, az haljon meg amugy is, de ez akkor is fajo.

Egyebkent, ha mar Solaris, akkor mig a

# ifconfig -a

parancs informaciokat kozol a gepben levo halozati interface-ekrol, addig a

# ifconfig -a <ipcim>

nem az adott ipcimu geprol kozol informaciokat (ahogy egy kollegam gondolta), de bekonfiguralja az osszes interface-t az adott ipcimre. Igen, a loopback-et is. Funny

Jelentem, az enlightenment feljesztoi (DR17) verzioja oly konnyeden fordul Solaris 10-en, hogy csak na. Es mivel rdesktop is van, mostantol a windowsom fut ablakban, es a Rayt hasznalom elsodlegesen. Kircsi.