Linux v uporabniškem načinu
Zadnjih nekaj let je postala priljubljena uporaba hkratnih operacijskih sistemov v enem računalniku.
Tako početje navadno ne prinaša prednosti v zmogljivosti, vsaj ne na arhitekturi računalnikov, ki danes predstavljajo večino. Pri tem načrtno porabljamo določen del računskih zmogljivosti za zagotavljanje drugih namenov, kot so npr. varnost sistema, izoliran zagon določenih strežniških programov ali za potrebe takih in drugačnih preizkusov. Tovrstna programska oprema pa je pospešila razvoj operacijskih sistemov in njihovih funkcij, saj razvijalcem za preizkušanje in razvoj ni več treba uporabljati ločene strojne opreme. Z nastankom močnejših osebnih računalnikov je več hkratnih operacijskih sistemov marsikateremu uporabniku postal že vsakdanje.
Programske rešitve virtualizacije
Preden se resno lotimo teme, moramo vsekakor omeniti, da so se koncepta več hkratnih operacijskih sistemov v enem računalniku lotili v IBM s strežniki, zdaj imenovanimi z/Series (ali bolj znanimi kot "veliki računalniki" - mainframe), že konec 60. let na takratnem računalniku S/360. Namen je ostal enak, vendar se virtualizacija na velikih sistemih in računalnikih v širši rabi (osebnih in računalnikih podobnih zmogljivosti) razlikuje predvsem zaradi manj primerne arhitekture in tej funkciji neprilagojene strojne opreme. Včasih se bližnjim neradi zaupamo, da našim "abakusom" še večopravilnost ne gre zmeraj najbolje od rok.
Pa si na kratko oglejmo, kaj imamo na razpolago, če bi si želeli več hkratnih operacijskih sistemov v osebnem računalniku. Nekoč je bil najboljša izbira kar klasični posnemovalnik (emulator), po možnosti za isto podlago. Še vedno ne smemo pozabiti, da ta uporaba tudi danes ni izključena, vendar je zaradi zmogljivostnih problemov manj primerna. Tu je v svetu GNU vsekakor omembe vreden posnemovalnik bochs in novejši projekt qemu, ki ima vgrajene že določene mehanizme, kot so t. i. virtualizatorji, posebej pri posnemanju gostiteljeve podlage. Med novejšimi izdelki-virtualizatorji najdemo komercialni VMWare in Microsoftov VirtualPC. Različice obeh izdelkov so namenjene rabi v strežnikih ali delovnih postajah. Na področju odprte kode najdemo nekaj zelo zanimivih projektov. Med bolj svežimi je vsekakor Xen, ki ponuja trenutno verjetno najhitrejšo in najboljšo izvedbo virtualizacije za podlago x86. Jedro operacijskega sistema mora biti za zagon na navideznem stroju Xen posebej prilagojene, kar je tudi ena izmed njegovih bistvenih slabosti. Na voljo je ustrezen popravek za jedro Linuxa 2.4, nastaja pa tudi za 2.6 in nekatere operacijske sisteme BSD. Kot posebnost velja omeniti, da je bilo za Xen prirejeno tudi jedro Windows XP.
Sun je s sistemom Solaris 10 predstavil tehnologijo zones, ki ponuja izoliran zagon strežniških programov v ločenih sistemih na enem gostiteljskem operacijskem sistemu. Uporabnikom GNU/Linux pa je že kar dolgo na voljo rešitev zagona operacijskega sistema kot programa v gostiteljskem sistemu. Rešitev se imenuje User Mode Linux (UMLi) ali Linux v uporabniškem načinu.
Shematski prikaz delovanja navideznega sistema v gostitelju.
UMLi seveda ne ponuja najhitrejšega načina zagona hkratnih operacijskih sistemov, je pa dovolj dober približek. Edina zahteva za tak način delovanja je prevod jedra z določenim popravkom in datotečni sistem v datoteki. UMLi nam bo koristil predvsem za zagon GNU/Linux-a, ne pa katerega drugega operacijskega sistema. Orodje oz. način zagona tega sistema je aktualno še iz časov jedra 2.2 in je nastalo predvsem iz potrebe po hitrejšem in učinkovitejšem preizkušanju svežih popravkov v jedru ter možnosti, da lahko za iskanje hroščev v jedru uporabimo priljubljen razhroščevalnik gdb ali ddd. Uporabimo pa ga lahko še na tisoče drugih načinov, ki so razlog za aktualnost virtualizacije. Jedra v uporabniškem načinu ni treba zagnati nadzorniku (superuser), temveč je zagon dovoljen tudi navadnim uporabnikom, kar je zanimivo predvsem s stališča varnosti. Nekateri ponudniki internetnih storitev dajejo v najem navidezne računalnike v načinu UMLi. Uporaba UMLi je zelo primerna tudi, če želimo izvedeti, kako naša poslovna aplikacija teče na novejšem jedru s posodobljeno programsko opremo. V ta namen ne potrebujemo novega strežnika, temveč vse skupaj preizkusimo na sistemu UMLi in po uspešnem preizkusu novosti namestimo v svoj sistem. Linux v uporabniškem načinu je, skratka, naše igrišče znotraj obstoječega sistema.
Namestitev
Namestitev ali, bolje rečeno, priprava je razdeljena na dva dela. Prvi del obsega prevajanje jedra za zagon v načinu UMLi. Drugi del je priprava datotečnega sistema v datoteki. UMLi ne uporablja klasičnih naprav za shranjevanje podatkov in uporablja datoteko s sliko datotečnega sistema. Sistem in nastavitvene datoteke morajo biti prilagojene delu z drugače imenovanimi napravami. V sistemu UMLi je mogoče uporabljati omrežje prek posnemanih zaporednih vrat ali navideznega omrežnega vmesnika ethernet. Pri zadnjem je poimenovanje naprav enako kot pri klasičnem sistemu GNU/Linux.
Izbor distribucije GNU/Linux je odvisen predvsem od tega, kaj želimo z njo narediti. Kot smo že ugotovili, so možnosti uporabe praktično neskončne, zato se bomo v članku ukvarjali predvsem s tem, kako hitro in učinkovito presneti klasično namestitev v datoteko in jo prilagoditi za zagon z jedrom v načinu UMLi. Tu še omenimo, da večina namestitvenih programov (ne vsi), ki pridejo z distribucijami, ne podpira namestitve v datoteke z datotečnim sistemom ali na nestandardne naprave, zato bomo namestitev naredili na del diska in jo potem prestavili.
Zahteve
Glede strojne opreme je priporočljivo imeti čim večji pomnilnik (seveda odvisno od uporabe) in čim boljši procesor - zaradi vzporednih procesov se bo najverjetneje bolje odrezal procesor z več (navideznimi) jedri, kot je npr. Pentium 4. Za resno uporabo v produkcijske namene je priporočljiva uporaba dvo- ali več procesorskega računalnika.
Zahteve za programsko opremo so bolj jasne in razvidno je, da je za UMLi potrebna namestitev ene izmed distribucij GNU/Linuxa, ki bo služila kot gostiteljski sistem. Izbira ni tako pomembna, kljub temu pa mora vsebovati vsa potrebna razvojna orodja za prevajanje jedra. Če ste jedro že prevajali, vam to opravilo ne bo tuje in verjetno veste, kaj potrebujete. Drugi pa preverite, ali imate nameščena naslednja orodja GNU: make, gcc (prevajalnik), razvojne knjižnice za glibc in paket binutils. Če bomo želeli uporabljati omrežje v navideznem sistemu, se moramo prepričati, da ima naš gostiteljski sistem v jedru vključen gonilnik za univerzalno napravo TUN/TAP, ki se na strani gostiteljskega sistema predstavlja kot omrežni vmesnik in omogoča neposredno komunikacijo, namenjeno uporabniškim programom.
Prav tako je nujno potrebno v jedru imeti vključen t. i. loopback device. Za ponazoritev prevajanja jedra v načinu UMLi bomo uporabili eno od različic jedra 2.6. Pri prevajanju jedra različice 2.4 moramo biti posebej pozorni, saj se postopek malenkost razlikuje.
Veselo na delo
Z bližnjega strežnika FTP si priskrbimo različico jedra 2.6 in odgovarjajoči popravek za jedro v načinu UMLi s spletne strani http://user-mode-linux.sourceforge.net/dl-sf.html, kjer poiščemo datoteko z imenom uml-patch-2.6.x.x.bz2. Med pisanjem tega članka je zadnja različica, namenjena jedru, različice 2.6.8.1.
Jedro razpakiramo v mapo na razdelku diska, ki naj ne bo enak tistemu, na katerem hranimo izvirne kode jedra za gostiteljski sistem. Predpostavimo, da je to mapa /usr/src/uml/. Ko je izvirna koda razpakirana, nanjo namestimo popravek.
# mkdir /usr/src/uml
# cd /usr/src/uml
# tar -xvjf /pot/do/datoteke/linux-2.6.8.1.tar.bz2
...
# cd linux-2.6.8.1
# bzcat /pot/do/datoteke/uml-patch-2.6.8.1-1.bz2 | patch -p1
...
Če je šlo vse brez napak, smo pripravljeni na prevajanje jedra. Postopek je enak, kot smo vajeni, razlika je le v tem, da ukazu make dodamo parameter ARCH=um
# make mrproper ARCH=um
Sledi konfiguracija jedra - tu izberemo svoj priljubljen način konfiguracije. Za naš zgled bomo uporabili konfiguracijo v terminalu s knjižnico ncurses (naslednji ukaz se ne bo izvedel, če nimate nameščene razvojne različice knjižnice ncurses):
# make menuconfig ARCH=um
Kot lahko opazimo v prilagoditvenem orodju, nastavitev skoraj ni treba spreminjati za osnovno testiranje. Opozorili bi morda le na izbiro "Kernel Hacking", kjer lahko izklopimo vse opcije, če se ne bomo ukvarjali z razvojem sistema. Te opcije nam bodo privarčevale malenkost prostora na disku - rezultat bo manjše jedro. Sledi prevajanje jedra - torej del, ki traja dalj časa in ni odvisen od nas, temveč od naše strojne opreme.
# make ARCH=um
...
Po koncu prevajanja bo v mapi zagonska datoteka "linux". Da, pravilno, to je jedro v načinu UMLi oziroma jedro kot uporabniški program. Za poizkus ga zaženimo, vendar ne bo delovalo, saj nima datotečnega sistema.
Če želimo prevesti module (verjetno jih nismo označili v konfiguraciji), moramo še zagnati:
# make modules ARCH=um
Za namestitev na alternativno lokacijo (v mapi /lib/modules/ nam ne bodo ravno koristili) moramo uporabiti še en parameter:
# make modules_install INSTALL_MOD_PATH=/pot/za/namestitev/modulov ARCH=um
Module lahko pozneje ročno prepišemo v datoteko z datotečnim sistemom.
Za normalen zagon sistema UMLi potrebujemo še paket uml_utilities, ki ga dobimo na istem naslovu kot popravke za jedro. Programe instaliramo kot paket ali ga sami prevedemo in namestimo v gostiteljski sistem - razpakiramo datoteko .tar.gz, spremenimo mapo v tools in zaženemo ukaz make, nato pa še make install (mesto namestitve teh programov spremenimo kar v datoteki Makefile).
Zdaj, ko imamo pripravljeno jedro kot uporabniški program in druge pomožne programe, lahko začnemo s pripravo sveže nameščene distribucije za zagon z jedrom. Za neučakane so na spletni strani projekta UMLi že pripravljene datoteke s prirejenimi distribucijami za zagon v tem načinu.
Pri namestitvi poljubne distribucije, njenih korenskih in drugih map ne razdelimo na več razdelkov, razen če imamo za to zelo dober razlog (in globoko poznavanje delovanja). Vsekakor pa ni treba delati razdelkov za navidezni pomnilnik (swap), saj je poraba pomnilnika vezana na gostiteljski operacijski sistem, ki pa ima najverjetneje dovolj navadnega in navideznega pomnilnika.
Namestitev nujno porabi veliko prostora. V razmislek - potrebujemo toliko, koliko bomo porabili za sistem s potrebnimi programi. Za podatke lahko uporabimo drug "razdelek" ali način dostopa. Prav tako programov za okolje X in samega strežnika X verjetno ne bomo potrebovali. Praktično je, da nameščeni sistem tudi zaženemo in poskrbimo za osnovne nastavitve.
Tako, zdaj lahko spet naložimo naš gostiteljski sistem. Na izbrani lokaciji (/uml), ki jo bomo imeli za sistem UMLi, naredimo datoteko z datotečnim sistemom, ki naj se imenuje root_fs. Predstavljajmo si jo kot en razdelek. Predpostavimo, da je njegova velikost okoli 2 GB. Naredimo prazno datoteko te velikosti:
# dd if=/dev/zero of=root_fs bs=512 count=2000000
2000000+0 records in
2000000+0 records out
in jo sformatiramo za datotečni sistem ext3:
# mkfs.ext3 root_fs
mke2fs 1.34 (25-Jul-2003)
addon.fs is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
...
Pripnemo jo na vnaprej pripravljeno mapo:
# mount -o loop root_fs /uml/sys
Zdaj še pripnemo razdelek, na katerem smo naredili svežo namestitev. Prepišemo celotno vsebino v mapo /uml/sys (vse, razen mape proc). Po končanem kopiranju lahko začnemo s spremembami v mapi /uml/sys. Splošna navodila za popravke je nemogoče napisati, zato je treba nekoliko eksperimentirati. Najpomembnejša je sprememba datoteke fstab v mapi etc. Iz nje odstranimo vse vrstice, ki se nanašajo na razdelek swap (če smo slučajno omogočili navidezni pomnilnik) in fizične naprave, kot sta pogon za plošče CD in diskete. Napravo, ki opisuje nosilec korenske mape (/), nadomestimo z napravo /dev/ubd/0, če uporabljamo devfs ali samo /dev/ubd0. Datoteka je potem videti približno tako:
/dev/ubd/0 / ext3 defaults 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
Ne pozabimo znotraj mape /uml/sys narediti še prazne podmape proc. Odpravimo se na lov še na druge nastavitve. Ker bomo pri zagonu sistema v načinu UMLi vzpostavili zaenkrat samo eno omrežno kartico, preglejmo, ali je tudi v sistemu nastavljena samo ena. Sistem UMLi je lahko v istem omrežju kot gostiteljski sistem, ki bo s pomočjo naprave tuntap omogočil povezavo z omrežjem. Naslov IP mora biti drugačen od tistega, ki ga napravi tuntap določimo pri zagonu jedra UMLi (sledi).
Pri zagonu ne smemo dovoliti zagona programov, ki imajo kaj neposredno opraviti s strojno opremo (clock, smartd, setserial in podobni). Preverimo tudi, da pri zagonu sistem ne bo prešel v grafični način (čeprav smo že zgoraj odsvetovali namestitev strežnika X). Pri virtualnih terminalih nastavimo prvi virtualni terminal na tty0, če še ni (datoteka inittab), saj je ta terminal viden pri zagonu jedra UMLi (popravimo tudi datoteko securetty, ki določa, od kod se lahko prijavi uporabnik root).
Ko smo uredili vse potrebno, odpnemo /uml/sys, se prestavimo v /uml in sem skopiramo jedro - datoteko linux ter jo zaženemo z dodatnimi argumenti:
# ./linux con=pty con0=fd:0,fd:1 eth0=tuntap,,,192.168.0.10
Prva argumenta preusmerita vse virtualne konzole k samemu sistemu UMLi, saj se sicer zaženejo v terminalskem programu xterm. Lahko jih poljubno preusmerimo na zaporedna vrata gostitelja, navadne terminale ali omrežna vrata ter jih uporabljamo s terminalskim programom, kot je minicom, programom screen oziroma programom telnet. Z argumentom eth0= pa določimo način posnemanja omrežnega vmesnika za ethernet. Možnosti je več in so različno podprte glede na različico jedra gostiteljskega in virtualnega sistema.
Zaslonska slika z domače strani projekta UML prikazuje dva sočasno izvajajoča se navidezna stroja. Štiri okna na levi so konzole Slackware, na desni pa so tri konzole SuSE in njegova sistemska prijava v četrti. V ozadju teče xnest, krajevni strežnik X navideznega stroja Slackware. Znotraj njega se izvaja xterm, priključen na navidezni stroj SuSE.
Če nam je uspelo zagnati sistem v načinu UMLi, lahko temu dodamo še nekaj prostora z argumentom ubd1=datoteka.fs. Datoteko datoteka.fs pred tem pripravimo na isti način, kot smo naredili datoteko root_fs. Tako bomo v sistemu UMLi lahko upravljali z novo pomnilniško napravo /dev/ubd/1.
Še en nasvet. Za lažji nadzor sistema UMLi je v paketu uml_tools program uml_mconsole. Zaženemo ga s parametrom, ki ga dobimo iz izhodnih sporočil jedra. Vrstica izgleda tako:
mconsole (version 2) initialized on /root/.uml/u4r8uF/mconsole
# uml_mconsole u4r8uF
(u4r8uF)
Za pomoč in ukaze v tem programu vnesemo kar "help". Tako dobimo dovolj informacij za uporabo programa.
Kot že zapisano, so možnosti uporabe UMLi številne tako za razvijalce programske opreme in sistema kot tudi za tiste, ki imajo več opravka s samim sistemom. Če želite o načinu UMLi izvedeti več, je na voljo veliko dokumentacije, ki je lahko razumljiva in morda se vam že svita, zakaj bi bil UMLi boljši za vas kot kakšne druge rešitve na področju virtualizacije.