Home na NFS4 + Kerberos

31.3.2015 14:06 | Přečteno: 2262× | Linux | | poslední úprava: 31.3.2015 21:42

Už týden nebo dva doma provozuji HOME adresáře přes NFSv4 s autentizací přes Kerberos (integrovaný přes PAM).

Stroje, který si /home takto připojují, bootují ze sítě přes read-only nfsroot. Výhoda je taková, že udržuji jen jediný systém pro všechna PC, všichni uživatelé mají všude stejná data a stejná hesla a o storage se starám jen na serveru.

Rozchodit si takto NFSv4 + Kerberos není moc těžké. Návodů se najde hodně. Nejhorší je ale to, když něco záhadně nefunguje. I já jsem došel to takto podivného stavu a nakonec jsem to vyřešil rekonfigurací od nuly.

Zkušenosti (respektive problémy)

Výkon

Pokud máte gigabitovou síť, pak výkon při čtení a zápisu činí teoreticky až 120 MB/s. Tomuto se dá dopomoci nastevním vyššího rsize/wsize při mountu. Čtení velkých souborů je obecně bezproblémové; kámenem úrazu je ale vysoká latence Ethernetu v kombinaci s ne zcela moudře napsanými aplikacemi.

Asi nejproblémovější je v tomto ohledu KDE. Kdykoliv se má někde objevit ikonka aplikace nebo typu souboru, pak sekvenčně prohledává až snad stovky adresářů. Já to vidím například při vstupu do adresáře, kde je nějaký soubor RTF, pro který ikonku nemám (takže to hledání opravdu trvá). Aplikace se až na 6 sekund zasekne a Wireshark ukazuje šílené množství volání NFS. Tento problém je sice už dávno nahlášený, ale v KDE se na výkonnostní problémy kašle i v mnohem jednodušších případech. (V KDE4 je například bug/prasárna, která způsobuje zátěž CPU na uzamčené obrazovce - výrazně by pomohlo na jeden jediný řádek připsat nulu, ale asi dostávají všimné z ČEZu, že ani to nejsou ochotní udělat.)

Považuji to ale snesitelné, protože ve většině situací to funguje dobře. Jiná prostředí (zkoušel jsem Xfce, LXQt) fungují o něco lépe.

Expirace ticketů

Při ověření vůči Kerberosu získává uživatel ticket, který se pak používá při přístupu k souborům. Tento ticket ale po čase expiruje.

Nejsem si jist, jestli se ticket obnovuje automaticky - tak dlouho nenechávám počítač zapnutý. Problém je ale při suspendu: při probuzení počítače následující den je ticket už beznadějně expirovaný.

Pokud nemám zapnutou lock screen, pak je nutné ticket obnovit ručně spuštěním kinit v terminálu a zadáním hesla. V případě lock screen se ticket obnoví zadáním hesla sám. V obou případech ale nastane určité období, kdy volání NFS nefungují. Některé aplikace se s tím nedokáží vypořádat (Firefox, Thunderbird, Skype, ...).

fatal: failed to stat '.': Key has expired

Aktuálně mám sice /home připojený jako soft (chyby NFS se tedy dostávají k aplikacím a jádro se nesnaží operaci opakovat), ale i ve variantě hard se po odemčení obrazovky objevovaly drobné problémy. Přepínači klávesnice KDE například zmizí vlajky (místo nich se objevuje jen en nebo cz) a k přepínání navzdory nastavení začne docházet globálně (namísto na úrovni aplikace).

UPDATE: Dá se částečně řešit instalací app-crypt/kstart (Gentoo) a vytvořením /etc/profile.d/krenew.sh například s tímto obsahem:

krenew -K 10 -b -p ~/.krenewprocess.txt

což zajistí obnovu ticketu každých 10 minut.

Jádro odpojuje /proc

Tohle podle všeho souvisí spíš s nfsrootem, ale nejsem sám, komu začalo linuxové jádro (3.18 a vyšší) za běhu odpojovat /proc. Někdy se to stane náhodně po čase, i když se nic neděje, jsou ale spolehlivé způsoby, jak to vyvolat (spustit Steam). Přidal jsem na vhodná místa do jádra warningy, když se něco pokusí /proc odpojit, ale spíš to vypadá, že něco někde poškodí výčet mountů a procfs tak zmizí. Vyloženě skvělé.

       

Komentáře

[luky]

Zajimave, ze listuje adresare porad vzdalene. U RO mountu to preci muze vsem klientum dat READ delegat a oni pak pozadavky mohou odbavit z cache.

[Luboš Doležel (Doli)]

Dobrý tip. Pro nfsroot stále používám NFSv3, tahle delegace je ale až u NFSv4, jestli googlím správně.

[luky]

jj, az od NFSv4. Na obou by ale melo jit nastavit, jak dlouho to muze pouzivat starou odpoved.

[snajpa]

NFSv3 bude vzdycky delat minimalne getattr call i pro vsechno, co ma v cachi. Stejne jako NFSv4 klient bez delegace.

[luky]

acregmin=n The minimum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. If this option is not specified, the NFS client uses a 3-second minimum.

[snajpa]

Tedy, 3s jsou default? Ze jsem nikdy nevidel NFS na linuxu se tak chovat. Divne. Ale NFS do detailu.

[snajpa]

..*neznam kod.. NFS do detailu

[Luboš Doležel (Doli)]

Hmm, ty jo, nfsroot přes NFSv4 je mission impossible. Možná tak s initrd. Jakmile ale začnu nutit vers=4 nebo rootfstype=nfs4, tak to skončí po chvíli kernel panicem, kterému nepředchází vůbec žádná síťová aktivita.

[pavlix]

Možná tak s initrd.

To bych viděl jako ideální postup a vykopat z jádra všechny ty jinak typicky userspacové sračky jako je DHCP. Obecně, nejenom pro NFSv4.

[Kvakor]

Mně se taky zdá NFS jako rootfs, navíc v read-only režimu, jako zbytečně drsná složitost, kdybych si dělal osobní bezdiskový stroj, tak bych pro rootfs použi spíš něco na způsob squashfs přes nbd (plus overlayfs s tmpfs), protože všechny moderní CPU jsou schopné dekomprimovat data rychleji, než se čtou přes gigabitovou síť. Jediná nevýhoda (mimo nutnosti používat initramdisk/initramfs) je vt tom, že zkomprimovaný souborový systém se musí při updatech znovu (re)generovat, i když i to by šlo nejspíš nějak pořešit, protože mksquashfs umí přidávat data inktrementálně.

No a pokud se někomu nechce komprimovat, tak se může klidně vyexportovat jako síťové blokové zařízení normální disk, jediný problém je problematičnost při mountování takového obrazu read-only, protože i v tomto režimo do něj některé souborové systémy zapisují (minimálně Ext3/4, ale nejspíš i další používající žurnál). Minimálně ndb sice má možnost copy-on-write, ale má výrazné negativní následky na výkonnost.

[Luboš Doležel (Doli)]

Jediná nevýhoda (mimo nutnosti používat initramdisk/initramfs) je vt tom, že zkomprimovaný souborový systém se musí při updatech znovu (re)generovat, i když i to by šlo nejspíš nějak pořešit, protože mksquashfs umí přidávat data inktrementálně.

Přesně tohle uvádí jako workaround problémů s KDE a přesně kvůli nutnosti přegenerování jsem to zatím nechal takhle.

No a pokud se někomu nechce komprimovat, tak se může klidně vyexportovat jako síťové blokové zařízení normální disk, jediný problém je problematičnost při mountování takového obrazu read-only, protože i v tomto režimo do něj některé souborové systémy zapisují (minimálně Ext3/4, ale nejspíš i další používající žurnál).

Kvůli herním Windows bootovaným ze sítě tu mám v provozu iSCSI target, takže to spíš zkusím přes něj. Udělal jsem si lokálně rychlý pokus s immutable souborem (chattr +i) a mount -o loop,ro a ext4 s tím nemělo problém. Stejně ale asi pro tento účel zvolím ext2.

[Luboš Doležel (Doli)]

Tak iSCSI taky stojí za prd. Windows s mým linuxovým targetem fungují v pohodě, ale jakmile je initiatorem Linux a dělám zápisy, tak na klientovi začnou po chvíli zápisy selhávat. Na serveru je v dmesg chyba:

[1044588.807658] fd_do_rw() write returned -22

Google nachází jedinou relevantní věc, kde to byla chyba na storage. Jenže já do toho souboru můžu na serveru zapisovat naprosto bez problémů. Filesystém ani úložiště problémy nemá.

Takže prostě target v Linuxu v reakci na určité požadavky vytvoří nevalidní požadavek pro zápis do souboru (-22 je EINVAL).

[trekker.dk]

Zkoušel jsi místo souboru jako backing store toho targetu použít blokové zařízení (LVM třeba)? Tipuju, že to bude častější způsob využití toho targetu a tím by to mohlo být líp otestovaný.

Btw. jak moc práce je rozběhat Windows přes iSCSI? Úplně bezdiskový stroj neplánuju, ale mít Windows nad md raidem s SSD cache zní docela zajímavě...

[Luboš Doležel (Doli)]

Tipuju, že to bude častější způsob využití toho targetu a tím by to mohlo být líp otestovaný.

Souhlasím, ale to už nechci Na používání souborů se mi líbí, že mohou být řídké ("thin provisioning").

Btw. jak moc práce je rozběhat Windows přes iSCSI? Úplně bezdiskový stroj neplánuju, ale mít Windows nad md raidem s SSD cache zní docela zajímavě...

Práce to tolik není (pokud člověk instaluje Windows z DVD a vyhne se potížím při instalaci ze sítě). Má to ale nevýhody:

1. Pokud v cílovém stroji změníš síťovku (změníš nutný ovladač), tak ty Windows už nikdy nenabootují. Chci o tom napsat článek, tak to tu teď nebudu rozvádět, ale běžný smrtelník už ty Windows dohromady nedá.
2. Po Ethernetu jsem nikdy nedosáhl rychlosti vyšší než ~33 MB/s, a to ani ve vyloženě syntetických testech bez ohledu na rychlost úložiště. Windows jsou dostatečně rychlé, ale cítíš, že ten disk je nějaký pomalý. Dnes už nebudu doma, abych na Linuxu zkusil, jestli je na vině MS initiator nebo Linux target. (Přes NFS jsem ale dosahoval snad i 100 MB/s.)

[trekker.dk]

Souhlasím, ale to už nechci

Proč to?

Na používání souborů se mi líbí, že mohou být řídké ("thin provisioning").

Koukni na dm-thin. Trochu jsem ho testoval v Debian Jessie a v pohodě, dokonce to podporuje i discard, takže se uvolňuje místo uvolněné filesystémem. Akorát je citelné zpomalení, když jsou metadata zapsaná na rotačním disku a musí se s nimi manipulovat při de/alokaci bloků, ale to bude u děravého souboru stejné.

Práce to tolik není (pokud člověk instaluje Windows z DVD a vyhne se potížím při instalaci ze sítě)

Hm, tuhle možnost jsem v instalátoru neviděl - hádám, že ji schová, když vidí disky.

[Luboš Doležel (Doli)]

Hm, tuhle možnost jsem v instalátoru neviděl - hádám, že ji schová, když vidí disky.

Instalátor ti iSCSI přímo nenabídne. Musíš použít iPXE pro namapování iSCSI disku (sanhook), pak přejít na boot z CD a instalátor pak ten iSCSI disk vidí jako běžný fyzický. Něco v něm pak ale pozná, že to není skutečný disk a zařídí, že Windows o iSCSI vědí.

[Luboš Doležel (Doli)]

Doplnění: iSCSI mi mezi dvěma linuxovými stroji jede 106 MB/s. Za prd tedy stojí initiator ve Windows, který zvládá max 33 MB/s.

[Heron]

Mě to na Widlích saturovalo gigabit. Velmi záleží na targetu. Na ten co je v CentOS 5 to jelo rychle, na ten co byl v té době v Debianu, mi to jelo strašně pomalu (pomaleji než 33MB/s). (Co přesně to bylo za targety fakt nevím.)

Linux initiator vs Linux target jsem nezkoušel, tam mám NFS (v3). Je možné, že Debianní target s linuxovým inicitátorem nemá problém.

[trekker.dk]

Nejsou náhodou v kernelu targety dva? To by to mohlo vysvětlovat.

[Luboš Doležel (Doli)]

Já vím jen o tom jednom, co se ovládá přes targetcli.

Po přechodu na backend iblock v thin logical volume (LVM) ty Windows dávají až 99 MB/s (Linux teď až 112 MB/s). Takže jen to fileio je takové problémové.

[trekker.dk]

Hm, tak to vypadá, že do mainline se dostal jenom jeden.

[luky]

No a pokud se někomu nechce komprimovat, tak se může klidně vyexportovat jako síťové blokové zařízení normální disk, jediný problém je problematičnost při mountování takového obrazu read-only, protože i v tomto režimo do něj některé souborové systémy zapisují (minimálně Ext3/4, ale nejspíš i další používající žurnál).

Kvůli herním Windows bootovaným ze sítě tu mám v provozu iSCSI target, takže to spíš zkusím přes něj. Udělal jsem si lokálně rychlý pokus s immutable souborem (chattr +i) a mount -o loop,ro a ext4 s tím nemělo problém. Stejně ale asi pro tento účel zvolím ext2.

I ext2 se vetsinou vyplati pripojovat jako ext4, protoze ext4 ovladac je vykonnejsi. Format disku to nijak neovlivni.

[pavlix]

Squashfs má dost pomalý start a zabírá dost RAM. To se zápisem na read only mount máš odkud?

[Kvakor]

Pomalosti startu jsem si nikdy nevšiml (a to ani na relativně pomalých ARMech), a i když je pravda, že squashfs zabírá více místa než jiné "běžné" souborové systémy (protože drží v paměti navíc buffery pro dekomprimovaná data), při překladu jádra to jde poněkud upravit přes rozšířené volby (za cenu zpomalení).

A ten problém s nutností zápisu i na read-only média mám z vlastní zkušenosti, po té, co se read-only exportovaný souborový systém s Ext3 odmít připojit a bylo nutné ho buď připojit jako Ext2, nebo povolit zápis (resp. copy-on-write). Podle dokumentace to jde nejspíš obejít externím žurnálem, ale nezkoušel jsem to.

[pavlix]

Pomalosti startu jsem si nikdy nevšiml (a to ani na relativně pomalých ARMech), a i když je pravda, že squashfs zabírá více místa než jiné "běžné" souborové systémy (protože drží v paměti navíc buffery pro dekomprimovaná data), při překladu jádra to jde poněkud upravit přes rozšířené volby (za cenu zpomalení).

To se ovšem bavíš o době, kdy už je celý image stažený, jenže já řádově déle čekám právě na to stahování. Doma nejčastěji bootuju ze sítě SquashFS z LiveCD, kdykoli se něco pokazí nebo potřebuju udělat novou (třeba i testovací) instalaci. V případe Gentoo mám ten image na lokálním serveru. V případě Fedory chápu, že stažení z internetu může trvat o něco déle, ale to je jiný příběh.

A ten problém s nutností zápisu

Na to jsem se neptal. Ptal jsem se na tvrzení, že read-only mount zapisuje, to bych osobně považoval za průser, oproti kterému je odmítnutí připojení nepodstatná prkotina.

[Pavel Píša]

S initrd, RO NFSrootem a AUFS overlayem, aby si každý počítač mohl dořešit nastavení v etc nám laboratoře běží již přes 10 let. Dokumentace od Aleše Kapicy na stránkách naší katedry:

https://support.dce.felk.cvut.cz/mediawiki/index.php/P%C5%99ehled_v%C3%BDvoje_infrastruktury_pro_diskless_Debian_na_kated%C5%99e_DCE

Stránky v kategorii diskless pak obsahují množství informací o naší konfiguraci i obecných návodů. Dále existuje moje starší prezentace na toto téma připravená pro InstallFest

http://cmp.felk.cvut.cz/~pisa/linux/diskless/diskless_dce_slides.pdf

Bohužel se teď situace trochu zkomplikovala. Dlouho jsme se těšili, že out-of-source AUFS nahradíme Overlayem a budeme mít Vanilla jádra. Dokonce před několika lety jsme to úspěšně s overlayem odzkoušeli, ale verze, co se do mainline dostala nedovolí v žádné vrstvě systém souborů, který potřebuje revalidate. Přitom ze standardního jádra Debianu AUFS již odstranili. Takže nezbývá než patchovat AUFS nebo zkusit adrenalin se zrušením testu v Overlay. Pokud nedojde ke změně RO lower filesystému, tak to pak chodí. Patch:

https://github.com/ppisa/linux-rpi/commit/d350d419ebd5b942a199cdf34991aeee379ba1e7

Při testu se změnou v RO mnoutovaném nfs filesystému na straně serveru pak Overlay začne nadávat do syslogu. Jádro se zdálo, že ale nespadne. V každém případě by bylo moc milé, kdyby se i na toto použití myslelo a jednou se to dostalo do mainline.

[trekker.dk]

Tento problém je sice už dávno nahlášený, ale v KDE se na výkonnostní problémy kašle i v mnohem jednodušších případech.

To si člověk nevybere. Já jsem teď zkoušel rozběhat Bluetooth v Xfce4 - všechno ok, spárováno s telefonem, blueman nabízí browse device, přes gvfs vidím v prohlížeči souborů adresářovou strukturu, dám zkopírovat obrázek z telefonu do počítače a chyba: another operation is in progress. Tak jsem hledal, chyba (v gvfs) nahlášená asi rok v Ubuntu, půl roku v Debianu.

Za poslední dobu mám tak nějak pocit, že když jde o počítače, tak se problémy řeší, když je průser. Dokud není průser, tak není co řešit.

[David Watzke]

To spíš záleží na vývojářích daného projektu. Když se jim chyba neprojevuje a mají hodně jiných věcí, tak to neřeší. Občas do toho holt člověk musí hrábnout sám.

[Luboš Doležel (Doli)]

Já mám někdy bohužel pocit, že kdybych neuměl programovat, tak se ty počítače nedají používat. Pořád si něco musím opravovat nebo dodělávat :-/

[mimi.vx]

kdyby jsi neumel programovat tak si toho ze je neco spatne ani nevsimnes

[Dr. Eddy]

Taky bych doma neco takoveho chtel, ale vidim problem v prenositelnych zarizenich - /home nemusi byt vzdy dostupny. Nebylo by lepsi mit lokalni kopii, ktera by se vzdy obcas sesynchronizovala se serverem? Stacilo by zjistit, ktera verze je novejsi a tou nahradit tu starsi. A dokonce by v klientovi ani nemusel byt pevny disk, stacila by flashka a nad tim nejaky overlay v pameti...

[Luboš Doležel (Doli)]

Nevím, jak vypadá tvůj home, ale ten můj by se synchronizoval hooodně dlouho. Proto, když potřebuju sáhnout na nějaké dokumenty zvenčí, tak použiju buď sshfs nebo NFSv4 (sec=krb5p).

[Dr. Eddy]

Nechapu. Rikas, ze mas obsahly home, a proto pouzijes ciste sitove reseni, ktere je navic treba vubec nedostupne, kdyz nejsi pripojeny k netu. Zatimco to moje reseni by po siti tahalo jen zmeny (ktere jsou prinejhorsim stejne velke jako cela data) a jen obcas, protoze by porad existovala lokalni kopie.

[Luboš Doležel (Doli)]

ktere je navic treba vubec nedostupne, kdyz nejsi pripojeny k netu

To se neděje.

Zatimco to moje reseni by po siti tahalo jen zmeny (ktere jsou prinejhorsim stejne velke jako cela data) a jen obcas, protoze by porad existovala lokalni kopie.

Jenže už ten rsync by trval zoufale dlouho.

[sigma]

V tomhle se musí uznat výhoda Microsoft řešení, kde mají CSC - Client Side Caching - pro síťové složky už velmi dlouho. Od Windows 7 to funguje i dost spolehlivě a záhadně se to nerozbíjí. Lidi s notebooky o tom v podstatě nemusí přemýšlet, a vybrané složky mají dostupné offline, a při návratu do LAN se synchronizují. Je k tomu i celkem použitelná integrace s GUI.

Existuje něco podobně funkčního pro Linux?

[Max]

To se ale hodí jen pro dokumenty, které se nemusí mezi uživateli sdílet. Pokud je potřebuji sdílet, tak jsou mi offline složky na nic.
Zdar Max

[Václav Vanc]

Já jsem taky zkoušel bootovat z NFS, ale ty KDEčka pak byly opravdu pomalé. iSCSI takový problém nemá a skoro ani nepoznám, že to bootuje přes síť (jen spouštění programů trvá o něco déle, protože mam jen 100 MBit síť, na gigabitu bych asi rozdíl nepoznal:) )

[SAM:]

Jak to vypadá u těch diskless strojů s kerberos tickety pro NFS ? Musí být na straně klienta v keytabu uložen nějaký ticket pro NFS službu? Musí být na straně kerberos serveru klientský principal, aby to chodilo ?

Dík.

[Luboš Doležel (Doli)]

Musí být na straně klienta v keytabu uložen nějaký ticket pro NFS službu?

Ano.

Musí být na straně kerberos serveru klientský principal, aby to chodilo ?

NFS server musí v keytabu zase mít vlastní "serverový" principal. Klientské principaly ale v keytabu na serveru být nemusí.

[SAM:]

A jak to řešíš u těch disklessů? V našem prostředí máme jeden diskless Debian, který bootuje na velkém množství stanic, které mají nfsroot jen jeden a na každé stanici je přes RW nfsroot aufs overlay s lokálním tmpfs. Takže změny se nepropagují na nfsserver.

Nemám tuto chvíli řešení, jak pro každého nfs klienta zvládnout jeho nfs ticket. Nemáš nějaký tip ?

Dík.

[Luboš Doležel (Doli)]

Prostě jsem nacpal jeden principal pojmenovaný "nfs/nfsroot.doména" do keytabu v tom nfsrootovém systému. A ono to chodí.

V /etc/krb5.conf v [libdefaults] mám ještě ignore_acceptor_hostname = true.