Solaris 10 Szakmai NapNa, ma voltam a Solaris 10 szakmai napon, gondoltam megosztom veletek a tapasztalataimat.
A rendezvényt a Corinthia Aquincum Hotelben tartották. 9:30-kor kezdődött a bevezető, a Solaris 10-et mutatták be nagy vonalakban. Csak ez a rész volt marketing-szagú, a többi tényleg szakmai, igényes ismertető volt. Itt megtudtuk, hogy a Solaris 10 a Sun legnagyobb projektje, a régi Solaris verziókban hemzsegtek a hibák, ezért a Sun úgy döntött, hogy nem adhat ilyen megbízhatatlan szoftvereket a felhasználók kezébe, ezért erősen elkezdték tesztelni az oprendszert. A Sun alkalmazottai még laptopjaikon és otthoni gépeiken is tesztelték, így végül a Solaris 10-be annyi újdonság került, hogy ez lett a Sun legátfogóbb és legnagyobb projektje, több mint 700 alprojekt épül köré.
Ezt követte a ZFS fájlrendszer bemutatása. A neve, azaz Zetabyre Filesystem onnan származik, hogy a maxinmális kapacitása nem tudom hány millió zetabyte, ami elképzelhetetlenül sok. (Ami engem illet már azt sem tudom, hogy a zeta előtét mit jelent pontosan, leragadtam a petánál meg az exánál.)
Más fájlrendszereknél a kötetkezelő és a fájlrendszer közt van egy interfész, de a ZFS-nél a kötetkezelés a fájlrendszer szerves részét képezi, így nagyobb rugalmasságot enged meg.
A fájlrendszer kiküszöböli a Big Endian - Little Endian közti kompatibilitási hibákat is, egy Sparcban használt ZFS kötet gond nélkül áthelyezhető x86 alá, és fordítva.
ZFS alatt általában nem felülírás történik adatok írásakor, hanem egy új blokk allokálása. Az ún. öngyógyítás is új allokálással történik. Ha egy mirrored volumeban egy adat sérült az egyik lemezen, az a checksum összegekből kiderül és a fájlrendszer egy új blokkot allokál a ludas lemezen és oda kerül a helyreállított adat, de eközben az alkalamazási réteg mit sem tud az eglészről.
A fájlrendszer a metaadatokat teljesen külön kezeli, egy ún. überblokkban. A metaadatok lementésével könnyen készíthetőek snapshotok a fájlrendszerről, és egy esetleges véletlen törlés után a snapshotból a hiba könnyen korrigálható.
Ezután következett a Solaris Containers, vagy ahogyan magyarul fordítják, a zónák bemutatása. Ez a módszer az adminisztráció megosztására használható, és leginkább a BSD jailre hasonlít.
Különbséget leginkább a nagyobb rugalmasságot biztiosító konfigurációban látok, illetve abban, hogy a globális zóna, tehát az önállóan futó operációs rendszer könyvtárstruktúrájának egy-egy része read-only módban delegálható a jailbe, így a legfontosabb binárisokon lehetővé válik egy központi adminisztráció, a globális zóna root-ja patchelheti a szoftvereket, és így azok a többi zónában is frissülnek.
A zónák után a Solaris 10 biztonsági szolgáltatásait ismerhettük meg. Először az RBAC-ról (Role Based Access Control) volt szó egy példán keresztül. Az RBAC ha jól emlékszem 49 szerepet definiál, ezeket oszthatjuk ki felhasználóknak, illetve processzeknek. Egy apache-os példával szemléltették. Létezik egy olyan privilege, amivel az adott process <1024 portokon listenelhet, ezt kell használni az apache-nál. Kiemelték még a file_dac_write privilege-t, amely lehetővé teszi, hogy bármely fájlt írjunk még akkor is, ha a standars rwx jogok nem engednék. Ez alól kivételt képeznek a root által ownolt fájlok.
Szó volt még a BART szolgáltatásról. Sorry, arra nem emlékszem, hogy a rövidítés mit takar. A lényege, hogy a rendszeren történt változásokat összevethetjük egy általunk lementett és persze read-only médián páncélszekrényben tárolt adatbázissal, és így megtudhatjuk, hogy mi változott a rendszeren. Így fedezhetők fel betörések, vagy egyéb rendellenességek. Persze a BART-ot is meg lehet crackelni, ez szóba is került, tehát mint ahogyan semmi, ez sem nyújthat teljes biztonságot. A binárisainkat a Sun által karbantartott fingerprint adatbázissal is összevethetjük, ez tartalmazza a Sun által kiadott összes fájlt, ami a Solaris rendszereken megtalálható.
Természetesen a kompatibilitás miatt a jó öreg root felhasználó is megmaradt, aki minden privilege-el rendelkezik.
Ezután következett a legvelősebb témakör a Dtrace. Ez egy olyan nyomkövető program, amely debuggolásra, és egyéb kutakodásra használható a futó programok között. Példán láthattuk, hogyan nézzük meg a Dtrace C-awk-Perl keverék nyelvével, hogy mely processek használják éppen a write rendszerhívást. Itt ráakadtunk a gnome-cd -re, amit furcsálltunk, hiszen ez egy CD-lejátszó. Szintén Dtrace-el a write nulladik paraméterét (arg0) lekérve megkaptuk a file descriptort, ami egy socket volt, és rájöttünk, hogy tán megnéztük azt is, hogy egy ilyen thread mennyi ideig fut, azaz mennyi időt tölt a gnome-cd ezen, számunkra felesleges, cselekedettel. Trükközgettünk még mással is, a Dtrace-t háttérben futtatva átírtuk az uname parancs kimenetét, így SunOS 5.10 helyett 5.11-et mutatott, ami jelen pillanatban lehetetlenség, és a GENERIC kernelnév helyett Erix-et. :) Talán ez volt a legérdekesebb az egészben.
Végül a Service Management Facilityt ismertük meg, amely az rc scriptek leváltására született, és rendelkezik extra funkciókkal, pl. újraindítják az adott processt ha az leáll, vagy jelzik, ha éppen nem megfelelően fut. Itt egyszerűen egy paranccsal beállíthatjuk valamire, hogy induljon-e vagy ne. A futási szintek analógiájára itt is létrehozhatunk set-eket. A zónák külön rendelkezhetnek a saját kis SMF-jükkel. És persze a kompatibilitás miatt az rc scriptek is használhatóak.
Ezután aki kitöltötte a kérdőívet, az kapott egy Solaris 10-es pólót és két Solaris 10 DVD-t, egyiken a Sparc, másikon az x86 rendszer található meg, aztán a Sun mindenkit meghívott egy nagyon fincsi ebédre. :)
