OpenSolaris - 2 (základy)

5. 2. 2009 | Jakub Jirků | Recenze | 6704×

Jak probíhá instalace, jak se vyznat v základních adresářích, čím se adresářová struktura liší od Linuxu, co jsou to contracty, kde najít běžné nástroje pro práci s procesy, a proč se mít na pozoru před killall.

Instalace

U instalace dlouho nepobudeme. Není ničím neobvyklá, na stránce www.opensolaris.com/get/ si stáhnete livecd, které je zároveň instalačním. Můžete zvolit multijazyčnou verzi, nebo verzi jen s pár "základnímí" jazyky. Nijak to neovlivňuje, co se systémem můžete dělat po instalaci, rozdíl je jen v tom, že CD se všemi jazyky je komprimované, a instalace tak zabere víc času.

Nabootované livecd vám nabídne GNOME s instalačním programem a nástrojem pro kontrolu fungování ovladačů na ploše. Druhý jmenovaný sice nabízí i možnost instalace ovladače jedním tlačítkem, ale pokud ovladač není součástí livecd, pravděpodobně neexistuje, takže se hodí jen pro kontrolu kompatibility hardwaru. K instalačnímu programu také není mnoho co dodat, jen se zeptá na časovou zonu, jazyk, uživatelské jméno a heslo, disk, který chcete použít (ZFS se moc nechce používat cache disku, když ho nemá celý, takže doporučeno je použít celý disk). Systém používá schopnost ZFS vytvářet virtuální svazky, takže zvlášť oddíl na swap nebo crashdumpy není potřeba. O tom později. Jestli jste si jisti, pak zbývá jen čekat.

Po instalaci vás přivítá GRUB, grafický boot a nakonec GDM.

...a kde je root?

Systém privilegií, autorizací, profilů, oprávnění, rolí a uživatelů v (Open)Solarisu je docela složitý a nechci se jím tu zabývat moc do hloubky. Oproti "velkému" Solarisu tady roota jako uživatele nenajdete, stala se z něj role. Pokud toužíte po možnosti v systému něco měnit, můžete použít sudo, které bylo do OpenSolarisu přeportováno "aby usnadnilo přechod uživatelům Linuxu a nemátla je komplexnost systému práv" nebo použít "oficiální způsob": utilitu pfexec.

Jak to funguje? Zjednodušeně řečeno, v systému existují nějaká privilegia. Vznikla tak, že kdykoli někdo viděl v systému konstrukci "pokud je uživatel root, povol, jinak odmítni přístup", přepsal ji na "pokud má proces nějaké privilegium, povol, jinak odmítni přístup". Existují například privilegia pro práci s icmp, změnu vlastnictví souborů, Dtrace, zjišťování informací o procesech a tak dále. I na fork a exec jsou potřeba privilegia, ač ta základní jsou zahrnuta do skupiny basic, kterou mají k dispozici všichni uživatelé. Privilegia lze samozřejmě i odebírat a některé (ne všechny) součásti systému toho využívají, některé démony nesmí mít potomky a někdy ani sáhnout na jakýkoli soubor.

Jaká privilegia má proces, zjistíme pomocí utility ppriv. Kdo co smí je (v tomhle případě) definováno v /etc/user_attr. Dozvíte se tam, že váš instalační uživatel má normálně práva "basic" a když požádá o privilegia svého profilu, dostane profil Primary administrator, který smí dělat cokoli, a krom toho bude také systém předstírat, že má UID 0. Popisy profilů, práva na spouštění procesů a další lze najít v /etc/security a práva uživatelů lze samozřejmě měnit i v GUI nástroji na správu uživatelů (poflakuje se v menu System -> Administraion -> Users and Groups).

O spuštění něčeho v profilu můžeme požádat pomocí pfexec. Rootshell nejsnáze získáme pomocí pfexec bash, toužíme-li po bashi. Existují i pfsh a pfcsh, což jsou ekvivalenty k pfexec sh a pfexec csh, ale tyhle shelly vám asi nebudou připadat příliš pohodlné. pfbash neexistuje z licenčních důvodů.

Na závěr doplním, že na rozdíl od sudo pfexec nemění proměnné prostředí, pracovní adresář ani nic podobného, jen nastaví UID a privilegia. Takže pokud budete často používat privilegovaný bash, může se vám stát že polovina souborů ve vašem home bude vlastněna rootem.

...co je to za adresáře?

Adresářová struktura OpenSolarisu se v detailech liší a abychom se vyhnuli typickému problému "kde je probohy xxx", trochu se na to podíváme. /bin, /root, /mnt, /etc, /sbin, /dev a /tmp asi nikoho nepřekvapí, fungují jako na většině linuxových distribucí (jen /tmp je ramdisk, pro použití, která vyžadují víc místa nebo mají přežít restart, je lepší /var/tmp). V /usr/bin se nachází jak obvyklé GNU nástroje, tak některé standardní nástroje ze Solarisu, které jinak převážně chybí. To spoustě lidí neudělalo radost (tedy, byl o tom flame v konferenci), ale vedení rozhodlo, že OpenSolaris se bude distribuovat s obojím, ale GNU nástroje budou přednastavené, a na návrh mít možnost vybrat si při instalaci nepřistoupilo, protože by to mátlo nové uživatele. Zpátky k adresářům, /usr/X (a taky /usr/X11 a /usr/X11R6) nabídne Xorg i s binárkami v /usr/X/bin. Rozhodně nemá smysl nechat se tím znepokojovat, balíčkovací systém klasické /usr/bin a /usr/sbin moc nepoužívá, takže adresáře jako /usr/php/5.2/bin nejsou ničím zvláštním. /var asi také moc nepřekvapí, jen /var/run je opět ramdisk a logy najdete krom /var/log i ve /var/adm.

Další adresáře už ale zvláštní budou. /devices je obdoba dnes již neexistujícího DevFS v Linuxu, tedy virtuální souborový systém se soubory reprezentujícími zařízení. /dev v OpenSolarisu je plný symlinků do /devices, ale systém se stará o to, aby se zařízení nepřekrývala. Tedy pokud přidám do počítače novou síťovou kartu, systém si zapamatuje její identifikační číslo a když ji potom vyměním za jinou, pojmenuje ji jinak, aby nedocházelo ke konfliktům. Resetovat tuhle paměť lze vytvořením souboru /reconfigure a rebootem systému.

O /home a /net se stará automounter, ale toho si v OpenSolarisu moc neužijete. Skutečné domovské adresáře uživatelů jsou v /export/home. Tohle rozdělení vzniklo proto, je možné mít domovské adresáře na serveru nasdílené pomocí NFS (proto /export) a připojené na pracovních stanicích a člověk může klidně měnit pracovní stanici a přitom mít svoje data k dispozici. Že tohle zůstalo zachováno Solarisu od Sunu, tvůrců NFS, asi nikoho nepřekvapí.

Adresář /system je další v kategorii virtuálních, obsahuje podadresáře object a contract. object nás moc zajímat nebude, obsahuje virtuálně moduly jádra, ale contract je zajímavější. Obsahuje seznam contractů, stejně jako /proc obsahuje seznam procesů. Co je contract? Contract je skupina procesů. Potomci procesu normálně patří do stejného contractu, ale lze vytvořit nový pomocí utility ctrun. U takového nového contractu jde nastavit, jak bude reagovat na ukončení vůdcovského procesu (skončí, ale potomci zůstanou, skončí, ale potomci jsou zabiti, jede dál, dokud neskončí všichni potomci), a nastavit, jestli má být contract po skončení restartován, případně kolikrát. Vytvořit službu, která se bude restartovat po pádu, pak nedá moc práce a OpenSolaris toho v rámci vlastních "initskriptů", tedy toho, co má místo initskriptů, hojně využívá.

Nástroje

Když jsem mluvil o adresářích, záměrně jsem minul /proc. Proč? Protože práce s procesy na (Open)Solarisu se od linuxové liší a zaslouží si vlastní odstavec, než někoho potká nepříjemné překvapení. (Open)Solarisový /proc obsahuje jen podadresáře pro každý proces, žádné /proc/partitions a podobné věci v něm nehledejte. Zjišťovat informace o procesech pomocí grepu a /proc není příliš pohodlné, takže jak na to jinak? Základní přehled vám může poskytnout top portovaný z Linuxu (htop se prý bohužel nechystá), ale podíváme se na nativnější nástroje.

První na řadě je nástroj prstat. Je podobný topu, ale umí toho víc, třeba zobrazit přehled pro jednotlivé uživatele (prstat -t), zóny (prstat -Z, o zónách ještě bude řeč v kapitole o virtualizaci) a různé kombinované přehledy. To LWPS, o kterém prstat mluví u každého procesu, je počet vláken (neboli odlehčených procesů). Krom prstatu je tu samořejmě i klasické ps.

Další dva nástroje jsou ptree a pgrep. ptree se podobá linuxovému pstree, ale je přizpůsobené Solarisu, takže s parametrem -c se s ním například dá prohlížet hierarchie contractů. pgrep funguje jako chytré ps | grep . Umí zjistit pidy podle jména procesu, ale i všechny procesy patřící nějakému uživateli nebo skupině, také nejnovější nebo nejstarší proces odpovídající podmínkám. Pid všech svých procesů tak zjistím pomocí

pgrep -u jakub

a svůj nejnovější proces (což nebude moc užitečné, protože to velmi pravděpodobně bude sám pgrep)

pgrep -u jakub -n

Rozšířením pgrep je pkill, který funguje stejně, jen procesům místo vypsání pošle signál. Dá se použít stejně jako killall na Linuxu, ale třeba i k zabíjení všech procesů některého uživatele. Ale (Open)Solaris už má killall, co ten dělá? Skutečně zabije všechny procesy, přesněji všechny procesy s otevřenými soubory. Používá se při vypínání systému, aby mohly být odpojeny souborové systémy. Zkráceně řečeno, nespouštějte ho.

Příště

Příště se připravte na sítě, balíčkovací systém a ZFS.

       

Komentáře

[Zdenek Kotala]

Co se tyce ZFS a zapisove cache disku, tak je skutecne lepsi dat ZFS cely disk, ale v pripade root partitiony to nejde, protoze PC BIOS by to nedokazal nabootovat. Takze se vytvori klasicka Solarisi partitiona v ni slice a v tom pak ZFS volume. Dokud nebudou umet biosy bootovat z disku s EFI, tak to jinak asi nepujde.

[CIJOML]

Opensolaris a uz i ofiko klasicky solaris 10 tusim 2008/11 umi nabootovat uz nativne ze ZFS - pouzivaji obezlicku podobne jako linux initrd

[Zdenek Kotala]

To ja vim, ale tady jde o to jak je vytvoren ZFS volume. Pokud udelam "zpool create ..." a dam mu cely disk, tak ZFS udela EFI label na tom disku, misto klasicke partitiony a pak ho dokaze vyuzit optimalne. Pokud se jedna o root filesystem, z ktereho se bootuje, tak kvuli BIOSu, ktery umi pracovat jen se starou partition table, se musi ten ZFS volume udelat v Solarisi slice. Takze pak ZFS nema cely disk, ale jen jeho cast. A pak se s takto vytvorenou casti zachazi jinak.

[Milan Jurik]

Kdyby jsi aspon vedel, o cem mluvis...

[CIJOML]

velmi dobre, dekuji za pochvalu ;)

[Petr Adámek]

To samozřejmě ano, ale Zdeněk poukazuje na něco jiného. U ZFS se doporučuje přidávat do poolu celý disk (to znamená, že na disku není ani partition table, ale celý disk od prvního do posledního sektoru využívá ZFS). Má to několik výhod (možnost bezpečné aktivace write cache disku, efektivnější plánování IO operací, apod.)

Pro root pool to ale není možné použít, protože klasický BIOS neumí z takového disku nabootovat. Proto se to řeší tak, že se na disku vytvoří klasická partition table s MBR, v ní Solaris partition, a teprve v ní se vytvoří slice pro ZFS. Až bude každý BIOS podporovat EFI, pak to nebude nutné a i u root poolu bude možné vynechat partition table a ZFS obsadí celý disk.

[CIJOML]

aha tady se mluvi o x86 :)) Ja mam totiz vsechno na Sparcu a tam problemy s EFI neresim.

[Milan Jurik]

Fakt? Jezus, co veta, to perla.

[Petr Adámek]

Že je řeč o x86 vyplývá minimálně z toho, že Zdeněk mluví o PC BIOSu, který na sparcu určitě není .

[Petr Adámek]

Jenom drobné upřesnění - obvyklé GNU nástroje se nenacházejí v /usr/bin, ale v /usr/gnu/bin. V /usr/bin jsou tradiční nástroje Solarisu (vycházející z původních System V R4 nástrojů). Rozdíl oproti Solarisu však spočívá v tom, že standardní PATH je přednastavená jako

/usr/gnu/bin:/usr/bin:/usr/X11/bin

takže pokud zavoláme nějaký příkaz, nejdříve se hledá mezi GNU nástroji. Pokud někdo preferuje tradiční nástroje ze Solarisu, prostě si upraví svoji PATH.

[Milan Jurik]

Drive GNU tooly (aspon ty podstatnejsi) se nachazely v /usr/sfw/bin nebo i v /usr/bin s prefixem g. Tohle se pred casem zavrhlo a vznikla tato politika :

1) co ma nekolizni nazev, jde do /usr/bin

2) GNU tooly s koliznim nazvem jdou do /usr/gnu/bin a pokud to ma smysl (treba u sedu), tak v /usr/bin je hardlink s prefixem

Viz PSARC 2007/047. Jinak, co se tyce cest, viz man standards. Btw. pro ty, kteri chteji pracovat napriklad se ZFS ACLky, GNU tooly jsou na nic a meli by si nastavit cestu nejlepe podle SUSv3.

[Käyttäjä 11133]

Zrovna včera cestou z práce jsem si říkal, že by nebylo špatné si ten Solaris nainstalovat a vyzkoušet ZFS Takže už to instaluju do VMWare serveru

[Milan Jurik]

Pro zavislaky na /home i pro lokalni uzivatele:

$ tail -1 /etc/auto_home

* localhost:/export/home/&

Netusim, proc v ramci boje za priblizeni Linuxovym distribucim tohle nebylo nastaveno. Jinak opet velice pekny clanek (heh, process kontrakty jsem nikdy dosud nepotkal, diky).

[frEon]

nevim jak ostatni nastroje, ale pgrep a pkill jsou i na linuxu

[VM]

Po většině uvedených featur v Linuxu nijak netoužím, ale ty možnosti nastavení práv by se mi líbily. Svého času existovalo v jádře něco zvaného capability, což snad mělo fungovat podobně. Netušíte někdo, jak to bylo, a co se s tím stalo?

[petr_p]

Pomalu se to dostává do použitelného stavu – konečně je možné mít připojené kvalifikace k souboru, a tak se již lze obejít bez SUID bitů. Na druhou stranu množina rolí je o proti Solarisu docela chudá. Budoucnost je ale nejistá, protože prakticky veškerou funkcionalitu lze nahradit SELinuxem.

[x]

Hmmmm,jenze SELinux architektura je implementovana do Solarisu,stejne jako do FreeBSD a Darwinu

 

http://www.nsa.gov/research/selinux/index.shtml

[Majkls]

No já bych se nerad hádal, ale jste si tím jistý? Já sem totiž v kernelu nikde neviděl hooky povyšující práva (selinux umí práva akorát ořezávat, nikoli je dávat. Tedy alespoň dle mého názoru). Čili na tuhle situaci budou lepší capabilities. Navíc je s nima lidštější manipulace

[petr_p]

Pravda, z praktického hlediska jsou kvalifikace snadněji uchopitelné. Ale ve výsledku je jedno, jestli /bin/ping startuje s rootovským EUID a SELinux mu dovolí jen raw sockety, nebo startuje s neprivilegovaným EUID a má v effective a permitted množinách CAP_NET_RAW.

[Michal]

Od jadra 2.6.25 jsou capabilities jiz pouzitelne, ale distribuce s nimi zatim moc nepocitaji (alespon v Debianu to neni jeste dotazene). Docela obsahla je manualova stranka capabilities(7).

Michal

[Karel Zak]

Fedora-10 (ale musite manualne, neni to default, je jen podpora v jadru):

# chmod u-s /bin/ping
# setcap cap_net_raw=ep /bin/ping

$ ls -la /bin/ping
-rwxr-xr-x 1 root root 41784 2008-09-26 08:02 /bin/ping

$ ping www.google.com
PING www.l.google.com (74.125.43.103) 56(84) bytes of data.
64 bytes from bw-in-f103.google.com (74.125.43.103): icmp_seq=1 ttl=242 time=77.1 ms

(ale pouzivate-li SELinux tak todle resit nemusite...)

[Michal]

Ale neprijemny je (teda alespon na Debianu), ze update balicku znamena ztratu nastaveni capabilities.

[Zdenek Kotala]

Jen pro upresneni cele se to jmenuje v (Open)Solarisu RBAC = Role Based Access Control. White paper zde: www.sun.com/software/whitepapers/wp-rbac/wp-rbac.pdf