Tlusté klienty ve školní učebně (diskuse)

[Michal]

Pri pouziti zivotne formy klientu by clanek vypadal mnohem interesantneji. Uz jenom ten nadpis "Tlusti klienti ve skolni ucebne" by vypadal naprosto uchvatne. Skoda no...

[ondrasheq]

...by vypadal uchvatne, za to ted vypada dost debilne - vypada to, jak ctvrty pad

[Leoš Literák]

Zato nadpis Tlusti hradi by se vyjímal

PS uznavám, že to bije do očí

[CET]

"Obecně platí, že každý linuxový systém musí mít adresář /var připojen i pro zápis a nemůže být sdílený. Toto pravidlo není nutné, ba ani vhodné aplikovat na celý /var, ale jen na některé podadresáře, např /var/log, /var/run atd. Nabízejí se 2 řešení. Jednak můžeme mít soubor obsahující filesystém a ten mít extra pro každou stanici a vždy si ho připojit, nebo použít ramdisk a vždy při startu systému v ramdisku vytvořit potřebnou adresářovou strukturu. Já jsem zvolil řešení s ramdiskem."

Nabizeji se celkem 3 reseni, dve jak pises a dalsi pomoci UnionFS, ktery je IMO nejlepsi. Take jsem zkousel delat v ramdisku adresare, do nich pak mountit prislusne adresare ze serveru pres NFS (protoze ne vsechny ruzne adresare je mozne jen tak potom smazat), ale nebylo to ono, protoze pri dalsim pridanim adresare jsem musel menit linuxrc v initrd (reseni se souborem to sice trosku zjednodusuje), navic soubor asi pres NFS nepripojis (ted nevim, nezkousel jsem -o bind na NFS) a pokud jsem mountil adresar do ramdisku a pak delal symlinky, tak to zase nedelalo dobre nekterym init skriptum, ktery chtely pracovat primo se souborem.

Ja osobne jsem to resil tim UnionFS, kde jsem zmenovy adresar (RW) vytvarel pro kazdou MAC adresu zvlast (samozrejme automaticky pri startu initrd na NFS readwrite oblast). Vyhoda je, ze nemusim nic menit v zakladni distribuci sdilene pres NFS, nechal jsem i originalni init skripty, pritom jsem ale pro kazdou stanici mohl mit uplne jine nastaveni (kazda stanice mela v UnionFS vlastni konfiguracni soubory pouze ty, ktere byly ruzne a pripadne mely pozapinane/povypinane jine sluzby). Vyhoda 100%=zadna ztrata dat, vlastni konfigurace stanice, originalni zpusob spousteni. Muzes mit i 3 stupnovy UnionFS=originalni distro (Readonly), tvoje konfigurace (readonly), uzivatelske zmeny v systemu (read-write). Pak si i uzivatel na stanici muze delat bordel, do puvodniho distra nezasahne (readonly NFS), a kdyz se ti ty uzivatelske zmeny nelibi, nebo to rozhodi startovani ty stanice, tak ten adresar proste smaznes. Popremyslej jeste o tom UnionFS, urcite by ti to hodne veci ulehcilo.

"V současné chvíli se distribuce ze serveru duplikuje na klienty, ale to v řadě případů nestačí. Museli bychom mít uživatele na serveru, což sice můžeme, ale lze použít i NIS+NFS popsané v odkazovaném seriálu."

No, pokud mas pres NFS pripojeny cely "/", tak nepotrebujes NIS, protoze mas pristupny i uzivatele (ja jsem mel teda na Gentoo distru sdilenej debian, tak /etc/passwd byl jiny). Ovsem pak se pres sit zrejme posila i /etc/shadow, coz neni tak super, a pokud na stanici muzou useri na roota, tak je to blby. Lepsi by bylo pouzit nejakej jinej system na auth, treba LDAP, ten se mi zda jako jednoduse nastavitelnej a dobre pracujici.

[Zdeněk Štěpánek]

Diky za napad, vypada to velmi zajimave, nicmene nevim jestli se dostanu k pokusovani s UnionFS.

Tu zminka o NISu jsi pochopil zrejme spatne. Jde o to ze moji klienti neberou uzivatele z terminaloveho serveru ale z jinyho serveru kde je /home sdileny pres NFS a uzivatele pres NIS. Klient se tak pta primo datoveho serveru bez spoluprace terminaloveho serveru. Pokud bych mel uzivatele i data na terminalovem serveru, neni NIS potreba.

S LDAPem jsem si hral, chtel jsem ho pro sambu, mel jsem ovsem pocit velmi maleho mozku a za par dni jsem to vzdal. Slozitejsi system jsem jeste nevidel.

Zdenek

[CET]

"Diky za napad, vypada to velmi zajimave, nicmene nevim jestli se dostanu k pokusovani s UnionFS."

UnionFS urcite zkus, neni na tom nic tezkyho a pritom to ma upravdu super vyhody (samozrejme take svoje nevyhody, jako napr. kdyz se v /tmp zacnou hromadit soubory nulove delky, ktere oznacuji smazany realny soubor a pak jejich pocet muzes prerust velkeho poctu a ls v /tmp je hodne pomale, aspon na ext3fs, takze to chce promazavat, nebo mozna spis na /tmp pouzvat ramdisk?). Jinak je ale unionfs dobrej i pres sit. UnionFS je pouzivanej na Knoppixu i ve Slaxu (ve Slaxu o neco elegantneji nez v Knoppixu), takze vyhodny urcite bude.

"Tu zminka o NISu jsi pochopil zrejme spatne."

Aha, tak to jo, to jsem nejak asi minul. To pak samozrejme NIS.

"S LDAPem jsem si hral, chtel jsem ho pro sambu, mel jsem ovsem pocit velmi maleho mozku a za par dni jsem to vzdal."

LDAP se sambou je trosku neco jineho, pletou se tam do toho jeste ptakoviny od M$:) SamAccount, ruzny ty jejich trapny ID:) ale i tak to neni slozite. LDAP pro linux autentizaci je uplne v pohode, proste nastavit nss-ldap a pam-ldap, pak zmena v /etc/nsswitch.conf, ve LDAP strome PosixUser a PosixGroup objekty a jede to. Jednoduse se daji v bashi udelat skriptiky na pridavani uzivatelu a skupin, mozna by to slo i primo pres useradd a groupadd, ale to jsem nezkousel (pam-ldap a nss-ldap mi do LDAPu leze jako anonymous [neni potreba davat heslo k read-write useru na FS linuxu] takze by ani nemohl tvorit uzivatele, ale asi to prubnu).

[Kyosuke]

A není lepší používat AuFS? Já myslel, že UnionFS je deprecated.

[franta]

Vam pres NFS exportovany unionfs funguje? Zkousel jsem to asi pred pul rokem a shodilo to server (bug v unionfs). Ted jsem to chtel vyzkouset pres funionfs, ale zatim jsem se k tomu nedostal.

Useradd a groupadd s LDAPem urcite nefunguje (aspon ne v sargi, pokud se to nezmenilo, coz nepredpokladam - PAM nema na tuhle administrativu snad ani rozhrani), akorat jedine co muze fungovat je passwd, pokud ale se prihlasuje do LDAPu jako admin (nastavuje se to nekde, uz si nevzpominam).

Ano, LDAP mi taky nakonec prijde jednoduchy, ale pridavani uzivatelu atd, to je opravdu hruza. Psal jsem to s python-ldap, doporucuju (format ldif je nechutnej; a bash obcas taky... ).

[xxx]

Jj souhlasim. Jakmile ma clovek jednou uzivatele v ldapu, je dobre velmi rychle zapomenout na vsechy ty groupadd atp. Ty totiz pracuji primo se soubory v /etc. Ja si nakonec zvykl na praci s webovym phpldapadminem. Dalsi moznosti je napsat si nejake vlastni skripty.

Co se tyce passwd. Tak to funguje. Pokud je ale potreba pomoci passwd menit hesla jinym uzivatelum, je nutne v nastaveni LDAP modulu pro PAM, rict, aby se root bindoval s jinou "identitou" a to s takovou, ktera ma pristup k posixPasswordu ostatnich useru. Normalne je user bindlej jako on sam, tudiz smi menit jen sam sebe.

Jinak LDAP je hezkej, ale obcas je to velkej boj s nastavenim. Hlavne s pravama

[Noname]

Slozitost OpenLDAPu souvisi s tim, ze schazi rozumna dokumentace a nastroje pro jednoduchou spravu. Nastesti se uz situace zacina menit. Napriklad v openSUSE 10.2 zprovoznite OpenLDAP pomoci nekolika kliknuti v YaSTu. Ale i tak to ma do idealniho stavu hodne daleko.

[CEST]

No, osobne mi taky jeden cas pripadal LDAP (ale obecne jako takovy) strasne slozity. Kdyz jsem to pochopil, myslenka je trivialni.

Dalsi vec je konfigurace prislusneho serveru, nikdo nikoho nenuti pouzivat OpenLDAP (ikdyz se mi zda hodne jednoduchy na jednoduche veci typu jeden server), muzete pouzit Sun DirServer nebo Fedora DirServer, ktery je samozrejme slozitejsi, nabizi vice funkci, ale take obsahuje Java administratorskou konzoli, takze relativne jednoduse clovek naklika. Samozrejme chapani zakladu replikace master-master je nutne, aby i to clovek dobre naklikal. Taky zalezi na zkusenostech, osobne bych rekl, ze jednoduchy LDAP server se da rychle rozbehnout na OpenLDAP jednoduchou upravou konfiguraku, misto instalace molocha SunDS/FedoraDS, konfigurace+nastaveni pres Java konzoli. Naopak replikace, SSL a nastaveni pristupovych prav se rychleji udela v SunDS/FedoraDS+java konzoli.

[Bazin]

Pěkný článek , ale chtěl jsem se optat jak se tam řeší svapování protože mě to doma nejde :( . Ten kus skriptíku , kterej obsahuje swap jsem moc nepochopil :)

[Zdeněk Štěpánek]

Viz skript "default".

Swapuju na lokalni disk. V tom skriptu je "fdisk -l" a nekolik grepu co vycucnou prvni swap oddil (s vice swapy to nepocita). Pokud tedy najde nejaky swap oddil tak ho aktivuje a hotovo. Pokud nenajde, tak neswapuje.

Swap pres sit jsem neresil, vsichni mi klienti maji disk nebo 512MB ramky.

Velmi jednoduse lze swapovat do souboru kterej bude sdilenej pres jiz pripojene NFS, nicmene swap pres NFS se moc nedoporucuje, pry je lepsi nbd, ale s tim neporadim.

Zdenek

[m$ lipo $m]

vybornej clanek jen tak dal

[Zdeněk Štěpánek]

Zapomel jsem jeste na jednu vec, Arch Linux pri vypinani schazuje sit, coz tedy v nasem pripade neni moc dobry napad. Vyresil jsem to quick&dirty, ve skriptu network jsem schazovani site pri shutdownu proste zakazal. Ono by asi slo ten skript zakazat cely, jelikoz sit nastavuje jadro samo podle parametru predanych pri startu. Jadro musi obsahovat AutoIPConfig a ROOT_NFS, kdyby si nekdo chtel vyrabet vlastni jadro.

Zdenek

[Bazin]

No s tím jádrem botuju krása . ale povolím moduly ale když daám modproe tak my to píše že QM_Modules not implemented a nevím proč :( .

[freshmouse]

Preferuji tenké klientky.

[emorjino]

jo, já taky :)

[xkucf03]

< žádný flame > jestli nepotřebujete mít data v bezpečí a tohle vám stačí, tak mne prosím nekamenujte za kritiku, nenutím vás číst dál < / žádný flame>

Když použijeme NFS pro připojení celého /home adresáře, má to jednu zásadní chybu: adresář se připojí ještě před tím, než se někdo k počítači vůbec přihlásí, navíc jsou připojeny (a potenciálně přístupné) adresáře všech uživatelů, ne jen toho jednoho, který s počítačem bude pracovat. To je IMHO architektonicky špatně a je to velká bezpečnostní mezera* Server neví, kdo u počítače (klienta) sedí, prostě jen slepě poskytuje data a věří klientskému počítači, že se o autorizaci postaral.

Za správné bych považoval to, že by se nepřipojoval celý /home, ale pouze adresář jednoho konkrétního uživatele, a to na základě jeho jména a hesla. Jenže když si domácí adresář bude připojovat sám uživatel, musí být přihlášený, jenže háček je v tom, že ve chvíli kdy je přihlášený, už musí být domácí adresář dostupný, tedy připojený.

Chtělo by to tedy, aby se po zadání jména a hesla v GDM/KDM připojil domácí adresář daného uživatele a potom mohlo naběhnout uživatelovo oblíbené KDE/Gnome.

Napadá mne použít SSHFS pro připojení ~/ Používám ho třeba pro on-line editaci www stránek a je to docela použitelné. Výkonnostně je to někde jinde než NFS nebo SAMBA, ale bezpečnostně taky Navíc "velká data" by si mohl uživatel zpracovávat na nějakém lokálním disku a až nakonec je nahrát do svého síťového domácího adresáře. Pro ty ostatní věci (nastavení programů, textové dokumenty...) by i tenhle FS měl stačit.

Takže pár otázek nakonec: Je SSHFS příliš pomalý nebo by šel použít? Víte o něčem lepším? Jak nacpat skript pro připojení disku mezi správce přihlášení a start KDE/Gnome (skript musí mít k dispozici heslo uživatele)? Neexistuje už nějaké hotové řešení tohohle všeho?

*) asi řeknete, že se mají počítače zabezpečit fyzicky, nebo že NFS serveru má být povolený přístup jen z některých IP adres. Ale to je podobně děravé řešení, jako když ve windows šlo shodit zaheslovaný spořič obrazovky vložením zvláštního CD.

[Zdeněk Štěpánek]

Do urcite miry mas pravdu, ale sdileni celeho /home je asi tak stejne nebezpecne jako kdyz si sednes k pocitaci kde maj ucty i jini uzivatele.

SSHFS bych dotoho opravdu netahal, pouzivam to v Konqueroru na pristup na jiny kompy, na to je to moc prima, ale na velky pouziti tezko...

Zdenek

[miso]

S nazorom sa stotoznujem. Nieco take sa da spravit s automount

[vencas]

Na to je http://pam-mount.sourceforge.net/

[petr_p]

Silna autorizace k jednotlivym domovskym adresarum existuje. Jedna se o NFS verze 4, ktera umi pres GSS Kerberos.

Nic o tom ale nevim, takze by me zajimalo, jestli se o to uz nekdo pokousel.

[Ondar]

Par poznamek: 1. Nac se trapit s necim, co uz davno funguje. Viz muj predchozi clanek http://www.abclinuxu.cz/clanky/navody/jak-nabootovat-linux-po-siti Pokud pouzivate RedHat, nemusite nic delat, vse uz je pripraveno (cela moje serverovna bezi bezdiskove - jedna radost) 2. Pripojit korenovy adresar s rw a no_squash mi pripada jako vysmech, to by me zajimalo, jak dlouho vam to bude fachcit. 3. Automounter je bomba 4. Ldap ja taky bomba 5. Kerberos + Ldap je uplne nejvetsi bomba, ale ten kdo to spolehlive rozbeha pomoci OSS nastroju s NFS v.4 a GSS, tak je u me frajer. Me se to jeste nepodarilo, takze jsem pouzil komercni produkt Centrify. 5 ze 4 psychologu doporucuje ladeni Kerberosu. 6. Na swap je mozno take pouzit NBD nebo GFS (v podstate to same) Ondar

[Zdeněk Štěpánek]

Mas tam neco co neco co neni bomba?