Doména, mount.cifs a marné snahy rozjet to nějak lépe

21.3.2012 22:48 | Přečteno: 1364× | Debian | poslední úprava: 21.3.2012 22:51

Uf, to byl zase půlrok. Trochu se zabýváme s kamarádem správou jisté školní sítě a domény, kterou kromě Windows Serveru a stanic s Windows (rozličných odrůd) obývají i různé verze Ubuntu a Debianu. S Windows stanicemi obvykle nebývají žádné problémy, co se týče zapojení do domény a namapování síťových disků (až na pár vzácných výjimek). Ovšem Linux, no... :)

Neměň to, dokud někdo nechce víc

Na našem gymnáziu se momentálně vyučuje Java a k tomuto účelu jsme na jednotlivé počítače nainstalovali NetBeans. K připojení síťových disků ze serveru používáme fungující, ale neobvyklé (já bych možná řekl prasácké, vzhledem k okolnostem ) řešení spočívající v tom, že po přihlášení uživatele se na jeho ploše vytvoří dvě ikonky - Připojit disk G: a Připojit disk P: (což zajistí pythonovský skript zavolaný z /etc/gdm3/PostLogin) - a poklikáním se disky následně připojí pomocí gvfs a uživatel je může používat. Autorizace je zajištěna pomocí Kerberova tiketu, takže tento způsob je prakticky bezproblémový.

Ale - takto namapované disky se objeví všude, jen ne v NetBeans, a ne každý si pamatuje cestu ~/.gvfs, takže vznikla jistá potřeba něčeho trochu chytřejšího. Symlinky do ~ po připojení? Proboha, jen to ne! Složitost, která se navíc může kdykoliv rozbít. Ale jak to tedy provést?

mount.cifs vs. my - 5:0

Použití příkazu mount nám připadalo jako poměrně logická volba, navíc se uživateli vytvoří pěkná ikonka disku na ploše - za předpokladu, že to bude nějak fungovat. Ale ukázalo se, že ani s mountem se nedá jen tak počítat, pokud jde o naši síť a doménu. :)

Hned první pokus vyšel úplně naprázdno,

sudo mount -t cifs //server/pavel ~/G

když se mount ve své jasnozřivé moudrosti pokusil přeložit server na čísla a tečky. Výsledek si jistě domyslíte. Jenže ani po přímém zadání IP adresy jsme nedopadli o mnoho lépe.

$ sudo mount.cifs //192.168.1.2/pavel ~/G
Password:

Tak, připojení zdá se funguje, ale chce po nás heslo. Co je mountu do hesla? Má přece lístek od Kerbera! Zmetek jeden zatracenej. Tak ne, asi to nějak půjde:

$ sudo mount.cifs //192.168.1.2/pavel ~/G -o sec=krb5
mount error(95): Operation not supported

Nepůjde. Podle dmesg se musíme připojovat s podepsanými pakety. OK. (Jen tak mimochodem, mezi jednotlivými kroky vždy uplynula zhruba hodina, ale na tento jsem přišel trochu rychleji.)

$ sudo mount.cifs //192.168.1.2/pavel ~/G -o sec=krb5i
mount error(2): file not found

A co je zase tohle? Dmesg tentokrát zarytě mlčel a debugovat mount.cifs nijak nepomohlo, resp. nevylezlo nic použitelného. Považovali jsme to za bug v kernelu, dokud někoho nenapadlo dohrát balíček smbfs. Ten s sebou tehdá vzal i keyutils jakožto esenci zcela nezbytnou pro připojení s podepsanými pakety. Asi kvůli nějakému exotickému druhu šifrování. Dobře, to bychom měli. Co si na nás mount nachystá příště? (Nechtějte vědět. Strávili jsme nad tím měsíc. )

$ sudo mount.cifs //192.168.1.2/pavel ~/G -o sec=krb5i,user=pavel
mount error(127): Required key not available

Už tady jsem věděl, že jsem sakra blízko k řešení, ale kamarádovi tenkrát došlo lépe než mě, že ten příkaz přece pouštím pod rootem, který nemá propustku do Kerberova klubu uživatele pavel. Tedy že se za něj nesmí vydávat.

suid? Ale kdeže

Po prohledání internetu jsem přišel na jinou prasárničku. Nastavím příkazům mount.cifs, smbmount a smbumount suid bit, takže je bude i obyčejný uživatel spouštět jakoby pod rootem. Tím se to mělo vyřešit. A chvíli to fungovalo, než jsme přešli k jinému počítači a pokusili se zopakovat naše kroky... :-/ Další pátrání na internetu přineslo zjištění, že ani téhle fujovince nebyla souzena dlouhá existence a přestala fungovat i jiným. Nu což, čas se posunout jinam...

gvfs-mount and all his friends

Příkaz:

gvfs-mount //192.168.1.2/pavel

se zprvu tvářil, že vyřeší všechny naše problémy. Jenže:

• ono je to vlastně to samé jako naše původní řešení (viz úplně nahoře), jen se po připojení neotevře okno
• nefunguje to pod ssh, resp. je třeba použít dbus-launch
• nefunguje pod rootem - při přihlašování, kdy je to nejvíc potřeba - a to ani za použití podpůrných prostředků typu sudo

Čili z louže do bláta. Ne, tudy fakt ne. Ale naštěstí jsem si všiml jedné zajímavé věci... A tou byl PAM.

pam_mount

PAM v moderních linuxových distribucích totiž zajištuje vše, co se jen trochu dotýká přihlašování, a je navíc velmi přizpůsobitelný a rozšířitelný moduly, jako je třeba pam_mount (v Debianu balík libpam-mount). Tento malý pomocník umožňuje připojovat různé disky a je taktéž velice tvárný, co se týče nastavení, ale zároveň nevypadá ani příliš složitě. To se mi zalíbilo a rozhodl jsem se prozkoumat, co náš malý kouzelník dokáže. No, zjistil jsem, že mount.cifs stejně budu muset dřív nebo později rozjet. A tehdá mi to docvaklo, když jsem hledal a hledal. Nějak jsem nevěřil, že ten jeden jediný parametr může v něčem pomoct. Ale tak jsem to zkusil:

$ sudo mount.cifs //192.168.1.2/pavel ~/G -o sec=krb5i,uid=pavel
$

Nemohl jsem tomu uvěřit. Ono to vážně začalo fungovat. Přidání parametru UID zabralo. Všechny problémy jako by mávnutím proutku zmizely a já se radoval. Polohlasitě radoval, aby to pokud možno nikdo neslyšel. Upravil jsem konfiguráček v /etc/security/pam_mount.conf.xml, ten se po nějakém laborování taky rozjel. Aspoň na počítači s Debianem. :)

pam_mount a strniště bugů

No, ale zpět k těm bugům. Otestoval jsem konfiguraci na jednom počítači s Debianem a automaticky předpokládal, že to bude fungovat i na Ubuntích kompjútrech. Ojojoj, jak strašlivě jsem se zmýlil. Na pam_mount totiž ani nedošlo a žádný příkaz k přimountování se nespustil. Debug byl neobyčejně hluchý. Aby taky ne, netrvalo dlouho zjistit příčinu. pam_lsass z balíku likewise-open nějakým způsobem blokuje pam_mount, pokud je v /etc/pam.d/common-session napsaný před ním. Řešení? Bylo asi nejjednodušší z celé sestavy kroků, stačilo přehodit ty dva řádky.

session optional pam_mount.so
session sufficient pam_lsass.so

A ne, klid jsme stále neměli, narazili jsme totiž na bug s chownem, kterýžto se dá nejlépe vyřešit asi jen instalací verze 2.8.1 balíku libpam_mount. Úlevou je, že nemá nové závislosti oproti starší verzi. V dalších dnech zkusíme celý nový cirkus nahodit zkušebně na ostatních počítačích a nahradit jím starou pythonovskou parádičku. Držte nám palce.        

Komentáře

[Pindal]

Dost odstrašující čtení. Např. při tom posledním "bugu" si stačilo v manu pamu přečíst co znamená optional a sufficient. Brrr.

[PaulosV]

Člověk se stále učí (čímž neomlouvám některé prasečinky, které jsem konkrétně já natropil), třeba tohle jsem nevěděl a do manu PAMu jsem se až do teď ani nepodíval, takže díky. Ten článek byl spíš jen příběh nadějného nápadu, který skončil mnoha hodinami laborování a několika případy svěšené (skoro zavěšené) hlavy.

[trekker.dk]

Nastavím příkazům mount.cifs, smbmount a smbumount suid bit, takže je bude i obyčejný uživatel spouštět jakoby pod rootem.

Nevím, co tam máte za "Debiany", ale u mě má mount.cifs suid nastaveno už z distra a smbmount je symlink.