Inferno OS: Namespace,/net & /prog

10.09.2006 14:18

Ako som uz spomenul v minulom clanku:

"Namespace to su hierarchicky usporiadane
systemove zdroje ( reprezentovane pomocou suborov )"

Tento namespace, ktory je
privatny pre kazdy proces, je tvoreny prikazmi bind a mount.

Prikaz bind ma podobnu funkciu ako v Linuxe prikaz mount --bind tj. pripoji
jednu cast namespace do inej.Priklad:
Do /n/remote sme namountovali vzdialeny filesystem (root adresar Inferna) z
ktoreho chceme pouzit adresar /usr, teda domovske adresare uzivatelov na
svojom systeme.

; ls /usr
inferno
v92
; bind /n/remote/usr /usr
; ls /usr
user1
user2
user3
;

Takze teraz pre nase lokalne aplikacie sa bude /n/remote/usr tvarit ako lokalny /usr. Program bind ma mnohe parametre, za vsetky spomeniem parameter -a ktory appenduje jeden adresar na koniec toho druheho. Toto sposobuje ze na systemoch Plan9/Inferno nie je nutna systemova premenna $PATH.Vsetky binarky sa hladaju v adresari /bin (Plan9) alebo /dis (Inferno).Priklad:

; ls /dis
echo.dis
cat.dis
cd.dis
; ls /usr/v92/bin
prog1.dis
prog2.dis

Za normalnych okolnosti ak by sme chceli spustit prog1.dis alebo prog2.dis bud by sme ich spustili priamo v adresari, zadanim celej cesty alebo zapisom
adresara /usr/v92/bin do premennej $PATH. Pod Plan9/Inferno sa vsetky pripady riesia jednym prikazom:

; bind -a /usr/v92/bin /bin
; ls /bin
echo.dis
cat.dis
cd.dis
prog1.dis
prog2.dis

Bind je teda program urceny na pripajanie/prepajanie roznych casti namespace-u co vlastne sposobuje ze Plan9 filesystem (fossil,kfs) nepozna hard alebo soft linky. Netreba ich. Skratka si bindneme nejaky subor, adresar, cokolvek kam treba. Bind je taktiez schopne bindovat systemove zariadenia ako disky, mys a pod ktore su zase
reprezentovane ako subor tam kam treba.

Predstavovat prikaz mount je uplne zbytocne pretoze ma presne taku funkciu aku by ste cakali. Bude cosi kamsi mountovat/pripajat ale narozdiel od bind-u
dokaze mountovat aj vzdialene fileservre (skratka programy ktore maju na svojom stdin a stdout Styx protokol a su exportovane do siete cez program listen).Pripadne aj lokalne fileservre. Dame si nejaky ten priklad:

; mount tcp!registry!6667 /mnt/registry

Tento prikaz namountuje vzdialeny registry server do naseho lokalneho adresara
/mnt/registry.Ale co ak chceme u seba spustit registry server ?

; mount {ndb/registry} /mnt/registry

Program mount spusti program ndb/registry ktory ma na svojom stdin/out Styx
protokol a ten mountne do /mnt/registry, ktory mozme nasledne exportovat do
siete cez program listen a na inom pocitaci mountnut ako v prvom pripade.

/net
V tomto adresari sa nachadza filesystemova reprezentacia sietoveho stacku. Vyzera to nasledovne:

/net/arp
/net/cs
/net/dns
/net/ndb
/net/tcp
/net/udp

Vsetko to su adresare v ktorych sa nachadzaju subory ako clone a stats a potom podadresare s ciselnym oznacenim oznacujuce spojenie.V nativnom mode je takto dostupny aj ethernetovy interface.

; cd /net/tcp
; ls
0
1
2
clone
stats
; cd 0
; ls
ctl
data
listen
local
remote
status

Vyznam jednotlivych suborov:
ctl - ovladanie spojenia ( nejake specificke nastavenia protokolu )
data - toto je I/O pre data
listen - pouziva sa na pocuvanie na danom porte
local,remote - lokalna a vzdialena adresa v tvare protokol!adresa!port
status - stav spojenia, napr Established,Announced a pod.
Spojenia sa manazuju roznymi suborovymi operaciami nad subormi.

Inferno/Plan9 svojim skvelym dizajnom uplne potlacaju neduhy NATu ako je nemoznost dockat sa spojeni na stroj s privatnou adresou, pripadne ak vasa LAN nepouziva vobec TCP/IP (taky pripad snad uz ani neexistuje ale na ilustraciu posluzi dobre). Predstavme si ze mame klasicku LAN s privatnymi
adresami a jednu branu ktora ma verejnu IP a robi NAT. Chceme na jednom pocitaci v LAN rozbehat ftp server. Normalne by sa to riesilo pridanim pravidla do fw brany.
Ak by brana bola Plan9/Inferno a stroje na LAN tiez, dalo by sa to na tom stroji na LAN riesit takto:

; mount -c tcp!brana!styx /n/remote
; bind /n/remote/net /net
; ip/ftpd

A co sa to stalo ? Nuz namountovali sme sietovy stack brany, a nabindovali ho ako svoj /net adresar. Teraz VSETKY lokalne aplikacie budu vyuzivat /net na manazment spojeni, cim vlastne budu zapisovat do /net brany. Ak spustime nejaky server ten vykona potrebne zapisy do /net (teda do vzdialeneho /net brany) a bude cakat na prichodzie data zo suboru data. Moze sa stat ze budeme mat na LAN viac serverov ktore budu chciet komunikovat na rovnakom porte, nevadi nic sa nedeje skratka sa zmeni cislo portu servera a idesa.

Mat toto implementovane v nasich \"modernych\" OS neexistovali by problemy s NATom a frustrovany programatori p2p sieti ci gridov :).

Pod Plan9 existuje jedna velmi zaujimava utilita ktora sa vola sshnet.Ta sposobi to ze vyuzitim
forwardovacich schopnosti ssh protokolu dokaze vyuzit
sietovy stack (jedine TCP) vzdialeneho Unixoveho stroja
a prakticky docielit to iste ako bindnutie /net nejakeho vzdialeneho Plan9/Inferno stroja.Ja som tak
este svojho casu vyuzival hysterku, a pre cely Internet
som sa javil akokeby som siel z hysterky a to bez
ohladu na program aky som pouzil (telnet,ssh,web,ftp).
Skratka anonymne,plne transparentne bez ohladu na protokol proxy.

/prog
Adresar /prog ma presne tu istu funkciu ako adresar /proc pod akymkolvek Unixom. Obsahuje podadresare s cislom PIDu procesu.Kazdy adresar /prog/PID obsahuje tieto subory:

ctl dbgctl exception fd heap ns nsgrp pgrp stack status text wait

Subor ctl sluzi na ovladanie procesu, resp na posielanie signalov. Pod Plan9 je prikaz kill len 142 riadkovy skript ktory spravi v podstate len:

echo kill > /prog/PID/note

fd,heap,stack,text - odkazuju sa na dotycne miesta v pamati procesu alebo na otvorene file descriptory.

ns,nsgrp - v suborore ns sa nachadza sekvencia bind & mount prikazov ktore zostavili namespace procesu

Zaujimava vec nastane ak si mountneme vzdialeny /prog k sebe. Potom vsetky programy spojene s manazmentom procesov ( za predpokladu ze mame na to prava)
budu ovladat vzdialene procesy.

Priklad:
Na node x86.sk si namountujeme /prog stroja blackhole.sk (bezi na nom registry,signer a styx server ktory exportuje / ) a uvidime co to spravi...:

; ps
1 1 v92 0:00.0 release 73K Sh[$Sys]
3 2 v92 0:00.0 alt 17K Cs
5 4 v92 0:00.0 recv 44K DNS
6 4 v92 0:00.0 alt 44K DNS
10 1 v92 0:00.0 ready 73K Ps[$Sys]
; mount -A tcp!blackhole.sk!styx /n/remote
; bind /n/remote/prog /prog
; ps
1 1 v92 0:00.0 release 82K Bufio[$Sys]
19 18 v92 0:00.0 alt 17K Cs
21 20 v92 0:00.0 recv 44K DNS
22 20 v92 0:00.0 alt 44K DNS
27 1 v92 0:00.0 alt 9K Listen
29 1 v92 0:00.0 release 9K Listen[$Sys]
30 1 v92 0:00.0 release 73K Export[$Sys]
38 1 v92 0:00.0 recv 15K Registry
39 1 v92 0:00.0 release 46K Styx[$Sys]
40 1 v92 0:00.0 recv 15K Registry
48 47 v92 0:00.0 recv 25K Keyfs
49 47 v92 0:00.0 release 46K Styx[$Sys]
50 47 v92 0:00.0 recv 25K Keyfs
52 1 v92 0:00.0 alt 9K Listen
54 1 v92 0:00.0 release 9K Listen[$Sys]
56 1 v92 0:00.0 alt 9K Listen; echo kill > /prog/56/ctl

Tymto stylom si mozme robit s hocico s vlastnymi procesmi nech nam uz bezia kdekolvek. V nasom pripade som na konci killol nejaky listen proces. Samozrejme
je mozne takto pouzit aj debuger pripadne hocico ine.

Zial jedinym nedostatkom /prog adresara je ze nie je reprezentaciou procesov ale iba zobrazenim tabulky procesov v Styx (teda ako fileserver) forme. Nove
procesy sa budu tvorit vzdy na lokalnom pocitaci nie na vzdialenom. Idealne by bolo ak by existovalo nieco ako:

; bind /n/remote/prog /prog
; cp /dis/date.dis /prog/cmd_exec
Sun Sep 10 12:06:43 BST 2006

Co by bol vlastne ekvivalent:

; bind /n/remote/prog /prog
; date
Sun Sep 10 12:06:43 BST 2006

V skutocnosti pod Plan9/Inferno prebieha vzdialene
spustanie takto:

; cpu adresa_remote_stroja date
Sun Sep 10 12:06:43 BST 2006

Nabuduce sa pozrieme na to ake zariadenia sa nachadzaju v adresari /dev,ake rozne user-land fileservre mozme v Inferne najst a ake zaujimave veci sa s tym daju robit.

    • klobouk dolu je videt, ze se 15.09.2006 | 17:56
      damien   Návštevník

      klobouk dolu je videt, ze se vyznas
      ---------------------------------------
      nadani ucit se je dar;
      schopnost ucit se je dovednost;
      ochota ucit se je volba;

    • Pekne 18.09.2006 | 13:39
      CiV   Návštevník
      Hmm, zda se ze tento OS oplyva mnoha dobrymi napady.