Menu:
:. HomePage
:. Linux
:. Solaris
:. Windows
:. Programování
:. Java + Tomcat
:. HW obecně
:. VoIP - Asterisk
:. Cisco - Mikrotik - Síť
:. O mě
:. Fotogalerie
Testovací:
:. ASP projekt
:. JSP projekt
Doporučuji:
Galerie fotek
Notebooky
Webdesign Praha
www.eprdel.cz
www.root.cz
Lumimont
A
3.135.184.166
LUFS - tak trochu jiný virtuální souborový systém (mount FTP)
Úvod, aneb trocha teorie nikoho nezabijeÚvodem si řekneme něco o principu fungování projektu LUFS. Již v citované Sklizni jsem nakousl problematiku implementace virtuálních souborových systémů (dále jen VFS). Představme si, že třeba chceme zpřístupnit obsah FTP serveru jako kdyby to byl lokální souborový systém. Základní přístupy k implementaci jsou dva: buďto využijeme mechanismů, který nabízí jádro operačního systému, a nebo přeneseme celou správu takového VFS do aplikačního prostoru. Obě tato řešení jsou technicky možná, ale obě mají svá pro i proti.
Využijeme-li možností jádra, největší a zásadní výhodou bude naprostá transparentnost pro všechny aplikace. Nebude záležet na tom, co je váš oblíbený správce souborů, komprimační program nebo třeba přehrávač multimédií - všechny budou schopné pracovat se soubory na vzdáleném FTP serveru, protože celý protokol obalí jádro svými vlastními systémovými voláními, která jsou na konkrétním typu souborového systému (dále jen FS) nezávislá. Tento obrovský klad je ale vykoupen téměř stejně důležitými zápory. Mezi ně patří zejména složitější programování v jádře oproti aplikačnímu prostoru a v neposlední řadě také nebezpečné proplétání aplikačních a systémových záležitostí. Osobně jsem zastáncem názoru, že třeba implementace věcí, jako je FTP protokol, do jádra prostě nepatří.
Druhým obecným přístupem k programování VFS je kompletní implementace v rámci aplikačních prostoru. Typickým příkladem může být například KIO v KDE, které umožňuje aplikacím pracovat s VFS pomocí URL, jak je známe z webu. V tomto systému je každý typ FS určen "protokolem", podle nějž se rozhodne, který "ovladač" se použije k zprostředkování přístupu k souboru. Jak vidno, toto řešení obchází nutnost implementovat aplikační protokoly do jádra, což je pozitivní, leč zase vyvstává jiný problém: bude to celé fungovat jenom pro aplikace, které s podobným systémem počítají. Budeme-li se držet příkladu s KDE, pouze aplikace používající pro práci se soubory rutiny z KDE knihoven budou ze systému KIO profitovat. To je ovšem poměrně zásadní omezení pro kohokoliv, kdo nepracuje v přísně homogenním prostředí, což upřímně řečeno není asi nikdo.
Po tomto obšírném úvodu se dostáváme konečně k principu, na němž je založen LUFS. Bystrý čtenář již jistě pochopil, že existuje přístup třetí, takzvaný hybridní, který se snaží spojit výhody a eliminovat nedostatky obojího. Jádro potřebujeme proto, aby VFS byl transparentně přístupný pro všechny aplikace bez rozdílu (dalším možným řešením by bylo podstrčení upravených IO funkcí pomocí speciální knihovny, ale tento přístup by neměl žádný vliv na staticky linkované aplikace), takže LUFS implementuje jaderný modul, nicméně jeho cílem je pouze zpřístupnit FS vytvořený v aplikačním prostoru zvláštním démonem. Obě komponenty spolu pak komunikují přes unixový socket. Tento přístup skutečně bere z jaderného i aplikačního řešení to nejlepší, ale ideální řešení pochopitelně neexistují, takže je třeba říci, že i on má své mínusy, a to zejména větší režii v komunikaci mezi modulem a démonem. Naštěstí bývá nejčastějším důvodem implementace VFS tohoto typu zpřístupnění vzdálených síťových služeb, kde limitujícím faktorem bude spíše rychlost sítě, takže to tolik nevadí.
Nyní se ale už pojďme podívat na instalaci a použití LUFSu.
Instalace
LUFS je šířen pouze v podobě zdrojových kódů, takže je třeba jej vždy zkompilovat, což je ostatně dané i potřebou přizpůsobení používanému jádru. Kompilace a instalace je prováděna pomocí klasické kombinace
make
make install
Jediným úskalím, s nímž jsem se při kompilaci na Red Hat Linuxu 7.2 setkal, byla nutnost mít nainstalované zdrojové kódy jádra, neboť hlavičkové soubory v /usr/include z balíčku kernel-headers obsahují makra znemožňující zkompilovat proti nim jaderný modul (přiznám se, že mi není známo, zda je to věc obecná nebo specifická pro Red Hat; v každém případě kompilace počítá s přítomností hlavičkových souborů v adresáři /lib/modules/`uname -r`/build/include).
Jistým záporem se mi jeví být absence informací o minimálních požadavcích na verze jádra a kompilátoru v dokumentaci. Takto vám nezbývá nic jiného, než prostě LUFS stáhnout a zkusit, jestli na vaší konfiguraci bude fungovat.
Moduly FS
Při popisu principu fungování LUFSu jsem nezmínil jednu zásadní věc: démon existuje jenom jeden, zatímco jednotlivé FS implementují speciální moduly (staticky linkované v době kompilace). To umožňuje poměrně snadno rozšiřovat nabídku podporovaných FS, a to i vývojářům třetích stran. Momentálně jsou součástí LUFSu moduly localfs (zpřístupnění lokálního souborového systému skrz LUFS - tento modul je zamýšlen jako vzorový pro vývojáře), ftpfs (zpřístupnění vzdáleného FTP serveru) a sshfs (zpřístupnění vzdáleného SSH serveru pomocí nadstavby sftp).
Použití
Použití LUFSu je nadmíru jednoduché - po instalaci se automaticky zavede jaderný modul a spustí démon (nestane-li se tak, můžete to udělat ručně, dokumentace na tento případ myslí) a pak už jen stačí obyčejným příkazem mount připojit požadovaný FS do vybraného adresáře. Například příkaz, který připojí do adresáře ./linux.cz FTP server ftp.linux.cz vypadá takto:
mount -t lufs none ./linux.cz -o \
nosuid,fs=ftpfs,host=ftp.linux.cz
Na příkazové řádce můžete pomocí další voleb ještě určit přihlašovací jméno a heslo, případně zapnout aktivní režim FTP.
O něco málo složitější je to v případě použití sshfs, neboť pro něj je nutné nakonfigurovat ssh připojení tak, aby používalo RSA autentizaci bez hesla. Součástí distribuce LUFSu je i skript lufs_sshconfig, který vám dokáže vše potřebné nastavit sám, takže pokud se na to necítíte nebo máte s RSA autentizací nějaké problémy, můžete jej zkusit. Vlastní připojení vzdáleného systému je pak jednoduché:
mount -t lufs none ./ssh_server -o \
nosuid,fs=sshfs,host=ssh.nekde.cz,username=uzivatel
Funkčnost a stabilita
Při relativně krátkodobém (a je třeba říci, že nepříliš sofistikovaném) testování jsem se párkrát dostal do situace, kdy se odezva programu pracujícího se vzdáleným FTP serverem (mc) radikálně zhoršila a pomohlo jenom opuštění připojeného FS. Domnívám se, že k tomu dojde v okamžiku, kdy FTP server ukončí spojení při nečinnosti a démon se s ním stále snaží komunikovat. Nějaké obnovení spojení se bohužel nekoná. Procházení některých adresářů v mc se mi zdálo celkové poněkud pomalé, ale nevím, zda to způsobuje nějaká chyba nebo prostě to, že si mc zjišťuje informace o adresářích a souborech. Dobré je, že se jaderný modul a potažmo běžící aplikace bez problémů vyrovnali se simulovanou havárií démona.
Závěr
LUFS je dle mého názoru opravdu velmi zajímavá implementace VFS, která stojí za pozornost. V současné době se zdá být až na některé mušky poměrně stabilní a pokud v budoucnu přibydou další plánované FS, jako například webdavfs, httpfs nebo freenetfs či nutellafs, bude to jistě velmi zajímavý nástroj pro různé úkoly.
Prebrano z ROOT.CZ: