Remote procedure call je systém pro vzdálené volání procedur, kterou vyvinula v roce 1985 společnost Sun Microsystems. Aplikace jako NFS (network file system) a NIS (network information system) jsou založeny právě na bázi RPC. RPC server poskytuje množinu procedur, které mohou klienti vzdáleně volat. Server provede zavolanou proceduru a klient obdrží patřičný výsledek. Množina procedur, které RPC server poskytuje, se nazývá program a je identifikován číslem programu.
RPC server musí nějakým způsobem informovat své okolí o tom, které služby a jakým způsobem poskytuje. Tuto činnost provádí tzv. portmapper, což je jakýsi správce RPC. Portmapper je démon, který běží na portu TCP/IP 111 a je typicky umístěn v /sbin/portmap. Seznam služeb a jejich číselných označení je umístěn v souboru /etc/rpc, který je s případnou nově nabízenou službou nutno ručně editovat. Otázkou zůstává, jak jsou RPC službám přidělovány porty. Tato situace je řešena při každém startu portmapperu a porty jsou službám, které běží pod jeho správou, přiděleny víceméně náhodně podle toho, které porty jsou v daný okamžik dostupné. Může se tedy lehce stát, že jednou bude mít služba port 256 a po rebootu stroje např. 815. Klienti tyto informace samozřejmě potřebují zjistit, takže před vlastním použitím služby zašlou dotaz na portmapper s požadavkem na informace o dané službě.
$cat /etc/rpc # RPC program number data base # $Revision: 1.5 $ (from 88/08/01 4.0 RPCSRC) # portmapper 100000 portmap sunrpc rstatd 100001 rstat rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd etherstatd 100010 etherstat rquotad 100011 rquotaprog quota rquotaPříkazem rpcinfo -p ověříme funkčnost portmapperu a zároveň zjistíme, které služby běží pod jeho správou a další informace.
[/home/xkumpost]/usr/sbin/rpcinfo -p
program verz proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32769 status
100011 1 udp 908 rquotad
100011 2 udp 908 rquotad
100011 1 tcp 911 rquotad
100011 2 tcp 911 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100005 1 udp 923 mountd
100005 1 tcp 926 mountd
100005 2 udp 923 mountd
100005 2 tcp 926 mountd
100005 3 udp 923 mountd
100005 3 tcp 926 mountd
Co se týče čísel programů v /etc/rpc tak přirozeným požadavkem je, aby byla identifikace procedur jednoznačná. Je nutné předejít situacím, kdy by dva různé programy, využívající RPC, používaly tutéž identifikaci svých procedur. K tomu je ovšem nutná existence jediného centrálního subjektu, který bude přidělování těchto identifikátorů vhodně koordinovat. Této činnost vykonává právě společnost Sun Microsystems.
Aby firma Sun Microsystems nemusela přidělovat jednoznačný identifikátor pro každou jednotlivou vzdálenou proceduru (což by bylo organizačně neúnosné), rozhodla se pro použití takových identifikátorů, které se skládají ze tří složek:
Společnosti Sun, jako globálnímu koordinátorovi, stačí pečovat pouze o jednoznačnost první složky. Kdokoli, kdo se rozhodne implementovat pomocí mechanismu RPC nějakou novou službu, si od firmy Sun může vyžádat jednoznačné číslo programu. Jednotlivým procedurám, které pak pro zajištění své služby vytvoří, již přiděluje druhou složku (číslo procedury) sám. Konečně třetí složka vychází vstříc postupnému vývoji jednotlivých služeb, který dává postupně vznikat novým a novým verzím. Díky této složce identifikátoru vzdálené procedury je pak možné průběžně implementovat nejnovější verze, ale současně s tím zabezpečit i zpětnou kompatibilitu a podporovat i verze předchozí.
V zájmu snazší implementace zavedla firma Sun konvenci, že všechny vzdálené procedury mají právě jeden vstupní parametr, a právě jeden výstupní parametr (resp. vrací jediný výstup). Pokud by bylo zapotřebí předat více parametrů, tyto se vhodně "zabalí" (přesněji: vytvoří se z nich vhodná datová struktura), a jako jediný vstupní parametr bude vzdálené proceduře předán ukazatel na tuto datovou strukturu, která samozřejmě musí být v rámci vzdáleného volání přenesena na server. K jejímu správnému využití je dále nutné, aby obě strany (tj. klient i server) byly předem dohodnuty na formátu této datové struktury a významu jejích jednotlivých částí. K tomu slouží XDR (eXternal Data Representation)
Je nutné zajistit aby obě strany správně interpretovaly každou
jednotlivou část vstupních a výstupních dat vzdálených procedur. Budou-li například
srozuměny s tím, že obsah dvou bytů má představovat celé číslo bez znaménka, mohou
jej stále ještě interpretovat různě - jedna strana může považovat za vyšší ten z obou
bytů, který druhá strana naopak považuje za nižší.
Konkrétní realizací této volby je pak standard XDR (eXternal Data Representation), který je
všeobecně uznáván jako standard v rámci rodiny protokolů TCP/IP, a je kodifikován formou
dokumentu RFC 1832.
Standard XDR tedy definuje jednotný způsob reprezentace přenášených dat, nezávislý na
konkrétní architektuře jejich odesilatele i příjemce. Kromě toho je součástí XDR také jazyk
pro nezávislý popis těchto dat. Po stránce implementační souvisí s tímto standardem také
konkrétní konverzní rutiny, které mají nejčastěji formu knihovních rutin, a jsou obvykle
označovány jak XDR filtry.
NFS (network file system) byl vytvořen s cílem umožnit připojování vzdálených disků nebo diskových oblastí jiných počítačů prostřednictvím počítačové sítě a protokolu TCP/IP.
Na začátek povídání o NFS jeden motivační příklad. Za předpokladu, že nám vše funguje a vše je správně nakonfigurované, můžeme velmi snadno přistupovat k vzdáleným diskům nebo adresářům. Ukážeme si, jak např. zpřístupnit adresář /exports/home/xkumpost na serveru mujserver.
$ mount -t nfs mujserver:/exports/home/xkumpost /home/xkumpostPo provedení tohoto příkazu dojde k připojení vzdáleného adresáře, který se od tohoto okamžiku bude jevit jako lokální. Nyní si pojďme ukázat jak tohoto pěkného stavu docílit.
Začneme tou snadnější částí a to je konfigurace klienta pro práci s NFS. Předně je nutné mít v jádře zapnutou podporu pro NFS, což lze zjistit ze souboru /proc/filesystems.
[/home/xkumpost]cat /proc/filesystems ... nodev nfs nodev nfs4 nodev nfsd ...
Poté je již, pomocí výše zmíněného příkazu a znalosti názvů poskytovaných vzdálených adresářů, možné připojovat svazky. Komu se to nechce dělat ručně při každém startu systému, může tato připojení nadefinovat v souboru /etc/fstab nebo použít mechanizmy, které budou popsány dále. Poté bude docházet k automatickému připojování. Je možné využít nejrůznějších voleb programu mount. Zmínil bych snad jen jednu celkem užitečnou a to je volba bg, která má za následek přenesení procesu připojení na pozadí, pokud toto nebude na první pokus úspěšné. Tato volba má své využití v případě, kdy je připojení součástí spouštěcího procesu. Proces spuštění tak v případě neúspěšného připojení není ohrožen.
Prověření funkčnosti těchto démonů (zda běží) lze provést příkazem rpcinfo -p. Dále bychom asi chtěli serveru říci, jaké adresáře, jakým strojům a s jakým oprávněním chceme poskytovat. Toto nastavení se provádí v souboru /etc/exports a zápis jednotlivých adresářů je poměrně přímočarý.
directory machine1(option11,option12,...) machine2(option21,option22,...) ...Položka directory specifikuje adresář na disku, který má být sdílen (nabízí se otázka, zda se tento adresář musí fyzicky nacházet na disku nebo zda to může být adresář, který je připojen pomocí NFS ;-) Bez výraznějšího googlení si myslím, že proč ne.) Položka machine pak určuje, které IP adresy mají oprávnění si tento adresář přimountovat. Místo IP adresy nebo názvu stroje lze také použít identifikaci sítě s příslušnou maskou nebo např. *.lab.fi.muni.cz. Dostáváme se k závorkám, kde specifikujeme konkrétní oprávnění pro danou IP nebo síť. Volby mohou být následující:
Pokud jsme v situaci, kdy chceme nové nastavení v /etc/exports aplikovat, ale chceme se vyhnout restartu NFS serveru, tak lze použít příkaz exportfs -a, který způsobí okamžité sdílení všech položek v /etc/exports. Další volby exportfs lze najít v manuálové stránce. Na závěr bych ještě uvedl příkaz showmount, který zobrazí, kteří klienti jsou aktuálně připojeni k serveru.
V závěrečné části tohoto referátu se budeme zabývat nástroji pro automatické připojování svazků. Ukážeme si použití Automountu a Amd.
Automount je proces běžící na pozadí, který zajišťuje automatické připojování a odpojování svazků podle toho, jak je uživatel využívá. Použití tohoto mechanizmu vyžaduje podporu v jádře, konkrétně se jedná o autofs. Přítomnost této podpory lze zjistit z /proc/filesystems Konfigurace se provádí v souborech /etc/auto.*, kde hlavní z nich je /etc/auto.master. V tomto souboru je každý přípojný bod spojen s tzv. mapou. Mapa překládá název adresáře, který uživatel otevírá - říká se mu klíč - na příkazový řádek, který může příkaz mount využít k provedení vlastního připojení. Mapa může být textový soubor, spustitelný program nebo třeba databáze LDAP.
Hlavní soubor obsahuje seznam adresářů, k nimž by měl být připojen souborový systém typu autofs, a spojuje s každým adresářem mapu. Zárověn zde je možné definovat přídavné parametry, které použije příkaz mount.
Mapové soubory automaticky připojují několik souborových systému pod jeden společný adresář. Cesta k tomuto adresáři se definuje v hlavnim souboru, nikoliv ve vlastní mapě. No, dobrý příklad řekne víc, než hromada teorie ;-)
[/home/xkumpost]cat /etc/auto.master /mnt /etc/auto.mnt -t 3 /misc /etc/auto.tmpnymfe -t 3 /packages /etc/auto.packages -t 10800 /net/anxur /etc/auto.anxur -t 60 /home /etc/auto.home -t 1800 /net/afs /etc/auto.afs -t 60 /net/afs_software /etc/auto.software -t 60 /net/news /etc/auto.news -t 60 /net/atlas/home /etc/auto.atlas -t 1800 /net/aisa /etc/auto.aisa -t 300 /net/anxur1 /etc/auto.anxur1 -t 300
Co by nemuselo být na první pohled zcela jasné je poslední parametr -t číslo. Tento parametr říká, po jaké době (ve vteřinách) má být svazek odpojen, jestliže všechny procesy tento připojený svazek opustí.
[/home/xkumpost]cat /etc/auto.afs afs -ro,soft,intr,nfsvers=2 afs.fi.muni.cz:/afs software -ro,soft,intr,nfsvers=2 afs.fi.muni.cz:/afs/ics.muni.cz/software
Zde vidíme, že do adresáře /net/afs/ budou připojeny dva adresáře afs a software. Následují paramery pro mount a potom umístění zdroje na NFS serveru.
[/home/xkumpost]cat /etc/auto.home * -rw,soft,intr home.fi.muni.cz:/export/home/&
Tento poslední příklad ilustruje situaci, kdy máme hodně sdílených adresářů, ale málo síly je všechny vypsat do mapového souboru :-) * a & zde mají speciální význam. * znamená "cokoliv", a znak & se vždy nahradí tím řetězcem, kterým začíná řádek, na němž se vyskytuje. Jinými slovy, když provedu cd /home/xkumpost, tak se řádek v mapovém souboru vyhodnotí jako:
xkumpost -rw,soft,intr home.fi.muni.cz:/export/home/xkumpostcož nepochybně ušetří spoutu práce a starostí...
Amd je jiný nástroj pro automatické připojování sdílených svazků, je součástí balíku am-utils a je dostupný na adrese http://www.am-utils.org/.
Konfigurace této věci se provádí v souboru /etc/amd.conf. Příklad:
$cat /etc/amd.conf [ global ] auto_dir = /amd restart_mounts = yes cache_duration = 5 dismount_interval = 5 log_file = syslog log_options = all map_type = file [ /home ] map_name = /etc/amd.home [ /packages ] map_name = /etc/amd.packages [ /net/aisa ] map_name = /etc/amd.aisa [ /mnt ] map_name = /etc/amd.mnt
Filozofie je podobná jako u automountu. Pojďme dál...
$cat /etc/amd.home
* type:=nfs;rhost:=atlas;rfs:=/export/home/${key};opts:=rw,grpid,resvport,vers=2,proto=udp,nosuid,nodev,utimeout=900
Trochu jinak se to zapisuje, ale myšlenka zůstává stejná. No, máme to za sebou, úplně na závěr ještě připojím několik užitečných odkazů.
Autofs Automounter HOWTO