NFS+NIS+LTSP - přihlašování na server (diskuse)

[......]

někde jsem ovšem četl, nebylo-li to možná tu, že NFS je pěkně nenažraný systém co se vytížení sítě týče. Zajímalo by mě jak to teda je. Není tu o tom ani zmínka.

[Josef Kufner]

Z vlastni zkusenosti muzu potvrdit, ze je daleko uspornejsi nez ftp a znatelne uspornejsi nez samba. Porovnavam maximalni dosazenou prenosovou rychlost: na NFS kolem 11-13MB/s, na sambe 6-8, na ftp kolem 5MB/s.

[......]

takže začne-li mi jeden klient pracovat s NFS jak urvaný tak se dá říct že 100mbit síť bude zahlcená.

[petr_p]

Klasicke NFS nad UDP ma vlastni implementaci congestion window, takze by k zahlceni dojit nemelo. Nicmene dnes je linuxovy TCP stack natolik efektivni, ze muzete pouzit NFS nad TCP a zatizeni CPU se nijak nebude nijak odlisovat (dokonce se vedou famy, ze je i mene narocne).

[Chulda]

Uspornejsi? Jak to myslite? Mam tu NFS i FTP s max cca 10MBps na tom samem stroji (ne soucasne, samozrejme). Narocnost lze IMHO jednoduse odvodit z protokolu (co zabiraj hlavicky, co data a jak casto apod) ale v tom se nevyznam.

[Pinky]

Skutečně se ale nenažreným může stát(stalo se), v tom smyslu že ftp i sambu při přenosu zatlačí do kouta( nedostanou přenosové pásmo) ale záleží to na více parametrech a nelze to říci obecně.

[David Jaša]

V nejbližší době budu NIS a NFS taky zavádět.

[Zdeněk Štěpánek]

Zdravim

Ono je to tim ze NFS defaultne jede pres UDP, coz ma za nasledek dve veci: velkou prenosovou rychlost a tim i vetsi zatizeni site. Jde zapnout i TCP rezim, i kdyz nevim jaky to ma vliv na rychlost.

I kdyz nekdo na NFS nadava kde muze, vpodstate neexistuje rozumna nahrada, jsou tu jen overkill projekty typu CODA, ktere ne vzdy uspokojive funguji. A pouziti nbd (network block device) se mi nezda jako vhodny a vyzkouseny napad.

Zdenek

[بطرس]

1) trochu nechapu, jak muze pouziti UDP znamenat vetsi zatizeni site. V pripade TCP to prece padne na rezii protokolu, ne?

2) jak je to s bezpecnosti NFS a hlavne NIS?

[Beda]

rika se tomu UDP storm.

a vypada to krom jineho tak, ze pokud mate povoleny tcp window scaling, tak se resiznou vsechny spojeni az na minimalni velikost prenosoveho okna. coz u linek treba do australie kde je rtt okolo 200ms kdyz se opravdu zadari a kdyz se nezadari a je po ceste treba chybova linka muze znamenat prenosovy rychlosti vyrazne pod 1kb/s i na 100MBit/s lince.

[kukacz]

Jeste je tady OpenAFS, ktery je v produkcnim nasazeni (jako pokracovatel AFS) pouzivan jiz temer 20 let. System ma svoje mouchy, vyplyvajici prevazne z jeho dlouhe historie a i jeho soucasni vyvojari uznavaji, ze nektere casti by dnes bylo treba kompletne "prepsat".

Presto jej ale pouziva napr. velka cast z nejvetsich svetovych univerzit (MIT, Univ. of Michigan ad., v Cesku napr. ZCU Plzen) i komercni organizace s pobockami po cele zemekouli. Duvodem je urcite jeho ohromna distribuovanost a skalovatelnost, podpora vetsiny operacnich systemu (unixovych, Mac i Windows) a treba i pritomnost sofistikovaneho zalohovaciho systemu.

Pro jeho nasazeni v nekterych sitich muze byt argumentem i to, ze probiha velmi aktivni vyvoj jeho Windows klienta.

[zzz]

Jste si jist, ze NFS defaultne jede pres UDP?

Ja se vzdy domnival, ze ve verzi 3 se defaultne pouziva TCP. Jednak nfs(5) explicitne zminuje "tcp - Mount the NFS filesystem using the TCP pro­tocol instead of the UDP protocol.This is the default, but in case it fails (many NFS servers only support UDP) it will fallback and try UDP." a navic kdyz pouziji "tcpdump -i eth1 udp" pro vypsani UDP paketu, tak se nevypisuje nic, zatimco "tcpdump -i eth1 tcp" vypisuje cilou NFS aktivitu.

Myslim, ze clanek by mel zminit, ze NIS je v soucasne dobe zoufale zastarala jmenna sluzba, ktera se pouziva hlavne z duvodu zpetne kombatibility a kvuli tomu, ze prechod na LDAP neni u rady siti zcela trivialni a levna zalezitost.

Bezpecnost NFS je v soucasne dobe zoufala. V praxi pouzitelne reseni se ale mozna najde pres bezpecnostni mechanismy IPv6.

My tu NFS i NIS pouzivame, ale v budoucnu bych radsi presel na LDAP a podstatne bezpecnejsi verzi NFS nebo nejakou variantu AFS.

[Zdeněk Štěpánek]

Zdravim

Nebudu ze sebe delat experta co ma NFS v malicku, ale obecne se rika ze protokoly co pouzivaj UDP maji vetsi propustnost na ukor ostatnich, protoze obchazeji obecne TCP flow control a tak vlastne tyto mechanismy nemaji nastroje jak UDP omezit.

Bezpecnost NFS i NISu je bidna.

O bezpecnosti NFS jsem napsal par slov v clanku a jeste dodam ze neni po ceste nijak chraneny, teoreticky by to melo jit poslat skrz SSH (SSL) tunel, ale nezkousel jsem to.

U NISu to bude asi jeste horsi, howto o nejake autentizaci uplne mlci, zrejme bude potreba pouzit autentizaci v RPC vrstve (jestli tam nejaka je) nebo vyuzit hosts.deny apod. Je potreba si uvedomit ze je to znacne stary protokol ktery vznikl na solarisu, mozna jeste driv.

Mimochodem, hned prvni veta z howto ohledne stinovych hesel:

Shadow passwords over NIS are always a bad idea.

Dale se tam pise ze se NISem ztrati vyhoda stinovych hesel a ze praci s nima zvlada jen Linux a jen s glibc 2.x a novejsim. Libc 5 to neumi. Vzdyt rikam, ze je to stare.

Zdenek

[jazz]

NFS: Tunelovani pres SSH asi nebude nejlepsim resenim, protoze by se pro kompletni funkcnost musela tunelovat i spousta jinych sluzeb (portmap, nlockmgr, mountd, status a treba i rquotad). Dalsi problem je v tom, ze tyto sluzby pouzivani porty dynamicky (vymezeny range - o hlaseni pro clienta se stara portmap), takze pri sestavovani tunelu bysme museli pro ssh vytvorit tento seznam a cisla portu by samozrejme nesmela kolidovat s obsazenymi porty na localhostu (a mame tu problem minimalne s portmapem, ktery je vzdy na 111). A jako "snad posledni" omezeni je tunelovani pouze TCP, protoze s UDP ma ssh problemy a myslim, že mozna ani nechodi. Takze tato moznost je podle me nerealna.

NIS: Jen tak mimochodem, pokud budeme NIS pouzivat i pro Solaris (8,+?), tak pozor, protoze ten neumi, krom "stinovych hesel", hesla v MD5 tvaru ($1$...), ale pouze CRYPT. Pristup k NIS se da nastavit v souborech ypserv.securenets a ypserv.conf, kde je i moznost nastaveni cteni NIS map z pouze privilegovanych portu klienta (takze root a jeho daemoni :).

To, ze jsem paranoidni jeste neznamena, ze po mne nikdo nejde.

[Jiří (BoodOk) Kadeřávek]

Je tunelovani a tunelovani. Mate-li na mysli sshtun, mate pravdu, pokud pouzijete vtun, openvpn apod. - tzn. VPN, tak nic dalsiho neresite. Ve skutecnosti je NFS systemem pro duveryhodne site, tzn. intranety, pripadne VPN. A z tohoto pohledu je dobre, ze se nesnazi resit neco, co se da vyresit jinak. To stejne plati samozrejme i pro NIS.

[jazz]

Tak i tunelovani NFS pres SSH je mozne (pred tim jsem se malicko sek - logicka dedukce a lehka znalost RPC, ale napravuji): Tunneling NFS through SSH

O VPN jsem se zatim nemel cas zajimat, a proto me ani tato moznost nenapadla, ale mate pravdu.

[Marek Rychlý]

Jake vyhody prinese popisovane reseni oproti pouziti LDAP+PAM nebo navic s autentizaci pres Kerberos?

Myslim, ze LDAP je bezpecnejsi a lze ho vyuzit pro sdileni uzivatele ve vice prostredich. NIS je mozna lepsi na sdileni jinych udaju, nez jsou zrovna uzivatele.

[zzz]

NIS je zastarala jmenna sluzba a pokud mate moznost pouzit LDAP, tak na ni s klidem zapomente - zadne vyhody by Vam neprinesla. Bezpecnostni nedostatky NIS se Sun pokusil odstranit v NIS+. Na rozdil od NIS ale nedal k dispozici zdrojove kody a o rozsireni se pokousel licencovanim. Jine velke unixove firmy (IBM, HP, ...) ale zajem o NIS+ neprojevily, a tak je tato sluzba v podstate mrtrva, i kdyz nektere firmy ji mozna jeste pouzivaji.

V soucasne dobe se v podnikove sfere prosazuje LDAP. Potiz je ale v tom, ze blbovzdorne klikaci nastroje pro spravu jsou pomerne drahe. Free nastroje existuji, ale pred nejakou dobou bylo jejich pouziti problematicke v heterogennich sitich, ktere konfigurovali i administratori MS-Windows zvykli vyhradne na GUI.

Napriklad ja jsem zvazoval prechod na LDAP pod Linuxem asi pred rokem, ale kvuli administratorum MS-Windows jsem to vzdal. Ted pokukuji po ZENworks od Novellu, ale zatim me odrazuje cena.

[yeckel]

Chapu dobre, ze pokud nekdo dostane na klientske stanici roota, tak se muze vesele dostat do domacich adresaru VSECH uzivatelu? Pekne nebezpecne :( Server jeste schovam za dvere, ale pracovni stanice? Nebo kdyz si nekdo nekdo vytahne kablik a pichne si ho do booka, tak jsem asi taky propadajici, ne? Je tohle nejak reseno ve v4? Jestli jsou me domenky spravne, tak nechapu jak to muze normalni spravce nasadit. :o

[Zdeněk Štěpánek]

Zdravim

No od toho tam je to squashovani roota. Pokud ho explicitne vypnes tak mas ve vsem pravdu, ale na to jsme v clanku upozornoval. Jenze defaultne je to zapnute a tudiz pokud mas u sebe lokalniho roota a chces s tim na NFS server tak tam jdes jako uzivatel nobody nebo anonymous.

citace z man exports:

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called "root squashing") is the default, and can be turned off with no_root_squash.

Jinak v manu jsem jeste nasel neco o auth_nlm, asi by se to tim dalo taky nejak zabezpecit.

Zdenek

[zzz]

Popsany problem se squashovanim roota nesouvisi. Zna-li nekdo heslo roota na klientske stanici, pak se pres "su - uzivatel" muze prepnout na daneho uzivatele (toto je zvlast snadne, pouziva-li se zaroven NIS). NFS server ho od praveho uzivatele "uzivatel" nerozezna a umozni mu plny pristup do home adresare uzivatele "uzivatel". Nejedna se o bezpecnostni chybu, ale o dostatecne znamou vlastnost NFS. Problem je, IMHO, odstranen v Secure NFS, ale to neni v Linuxu implementovano a v praxi se pouziva minimalne.

[Drak]

I kdyz se root nesquashuje, tak kdyz nekdo prijde s notasem, pichne do site a udela si uzivatele s libovolym UID, dostane se k jakymkoliv datum uzivatele se stejnym UID na serveru, takze ani tak bezpecnost nic moc.

Ty cisla ve fstabu nejsou zadna klasicka major/minor, ale prvni cislo (paty sloupec) je pro dump, a urcuje, ma li se filesystem zalohovat (viz dump(8), fstab(5)), a druhe cislo (sesty sloupec) udava poradi, v jakem se ma provadet fsck filesystemu pri bootu (viz fstab(5)). Kdyz to zminujete v clanku, proctete si predtim aspon manual, kdyz nevite co ta cisla znamenaji.

S parametry mountu si chce trochu pohrat, hlavne s velikosti cache (rsize=8192,wsize=8192) nastavuje read/write buffer na 8K, ale optimalni parametry fakt nevim, tohle je z manualu... hard - v pripade ze NFS server chcipne, proces se zavesi a bude cekat v uninterruptable sleepu na jeho probuzeni. intr - v soucinnosti s hard povoli prerusit hangnuty proces cekajici na I/O soft - kdyz se server nedostupny, proces nakonec vytimeoutuje... Teoreticky... viz mount(8)

Jinak tohle tema me zajima, tak jen tak dal, jen trosku pecliveji prosim.

[hajma]

S parametry mountu si chce trochu pohrat, hlavne s velikosti cache (rsize=8192,wsize=8192) nastavuje read/write buffer na 8K, ale optimalni parametry fakt nevim, tohle je z manualu...

Já mám u tlustýho klienta rsize i wsize nastavený na 1024, při 8k i 4k se to kousalo. Je to voodoo...

[jazz]

Problem s bezpecnosti lze vyresit s pouzitim kombinace PAM+LDAP+Kerberos (misto NIS) a NFSv4 opet s podporou Kerberos (jadra 2.6.x, Solaris 8+). Stanice jsou pote "identifikovany" pres KRB na zaklade ticket-granting ticketu u Master Key Distribution Center (M/KDC). Pokud se tedy pokusi pripojit nejake PC, ktere neni vedeno v M/KDC (neni vytvorena prislusna identita - principal), nebudou poskytnuty ani sluzby LDAP, NFS. Pokud ale nekdo ziska lokalniho roota, muze samozrejme za pouziti napr. "su - uzivatel" zkompromitovat uzivatelova data. Vse je tedy v rukou administratora ;)

BTW, co se tyka NFS over TCP, nekdy je nutno pri "vytuhnuti" NFS serveru, a opetovnem zprovozneni, rucne odmountovat a primountovat NFS svazek (umount -fl ...). Pri pouziti autofs staci pouze umount.

[vs]

Jestli to není jen teoretické řešení, napíšete o tom článek? Zkoušel jsem LDAP a fungoval (i když nějak podivně, myslíš že SSL nešlo), s Kerberem jsem to rozchodil jen pokusně a po několika týdnech. Jak se můžou windows (v heterogenní síti) logovat přes Kerberos nevím, podle dokumentace to asi nejde (aspoň ne stylem windows -> samba -> kerberos, win98 rozhodně ketrberos nativně neuměj, NT taky ne). Zkrátka je to sice možná bezpečné, ale nakonfigurovat se to nedá buď vůbec nebo dá hodně špatně. Jestli je NFSv4 tak složité na konfiguraci a integraci s Kerberem jako AFS, tak do toho rozhodně nejdu.

[jazz]

Pokud Vas zajima implementace KRB(v5) ve Windows + spoluprace s Unixem, doporucuji precist clanek Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability. Podpora KRB ve Windows je od verze W2K+ (pro spolupraci s dalsim systemem je potreba SDK). Jako filesystem bych ale NFS ve Win nepouzival, jelikoz to nativne nelze (pouze mozna s Windows Services for UNIX). Misto toho radeji Sambu, ktera s LDAP nema problemy a umi i KRB.

Na clanek bych asi nemel nervy (nebo spis na komentare ) a hlavne cas (musel bych si vse peclive odzkouset).

[Michal Kubeček]

Problém vidím v tom, že Samba je proti NFS zoufale neefektivní.

[Michal Kubeček]

Když padne root, padne všechno (tedy aspoň v klasickém bezpečnostním modelu, nemáme-li SELinux/LIDS/…). NFS primárně předpokládá, že jednotlivé stanice jsou pod společnou správou a mají společnou databázi uživatelů. Padne-li tedy root na jedné, padl na všech. To, že pak lze zneužít konkrétně NFS, je v takové situaci už jen zanedbatelný detail.

[Myspulin]

Root do spolecne databaze uzivatelu nebyva zarazovan. Kazda klientska stanice miva vlastni heslo roota, ktere se bere z /etc/shadow. Kdyz padne root na jednom klientovi, pozici roota na ostatnich to neovlivni.

[Zdeněk Štěpánek]

Zdravim

Skutecne je to tak, pouzivam tento system presne tak jak je psano v clanku a rootovsky heslo na klientovi mam stale puvodni. Nicmene porad plati ze i jako lokalni root ziskam pristup do vsech exportovanych slozek, i kdyz maj prava 700.

Zdenek

[Michal Kubeček]

Jen částečně. Jak už tu několikrát zaznělo, pořád zbývá možnost vydávat se za kteréhokoli jiného uživatele (na kterékoli stanici). Tedy i za normální uživatelský účet toho, kdo systém spravuje. A tím se otevírá prostor ke zjištění hesla roota.

[tk]

konecne zas, po delsi dobe, jeden konstruktivni clanek, diky.

[unchallenger]

Co je NFS, snad není potřeba

požadavek, např. "vylistuj ./", a server mu odpoví

mechanismy (vyjma squashování UID/GID), jako je jméno a heslo

snaží přistoupit user s UID 100, tak na NFS serveru

[Robert Krátký]

OK (chci říct... Budiž).

[javes]

Zdravím,

potřeboval bych síťově nasdílet /home.

Problém je v tom, že by to mělo jet (klient) jak pod Linuxem, tak pod Windowsem. Mělo by to podporovat práva. Identifikaci jménem/heslem (nebo třeba kerberem). Plus by byl šifrovaný kananál pro data. A aby to nebylo vázáno na adresy (chtěl bych se připojovat z domu, ze školy, z kavárny, prostě odkudkoli).

Díval jsem se na OpenAFS, ale bohužel mám jádro 2.6, což jaksi nezkousl.

Díval jsem se ještě na Intermeezo, ale ten se mi nějak nezamlouval (nebo jsem ho špatně pochopil :().

Díky za jakoukoli radu.

[Zdeněk Burda]

Co třeba OpenVPN tunel a pak si ty data nasdílet čímkoliv, třeba sambou?

[javes]

Taky možnost.

Teď by mně jen zajímalo, jak je to s podporou Linux[samba]Linux.

Servřík je totiž na Linuxu (překvapivě ;)), a já mam stanici na Linuxu ;). Jsem k serveru připojenej 100Mbit (UTP). Jak je to s rychlostí, a stabilitou SAMBY?

A jak je to se sambou s právy? Podporuje standardní UNIXovská práva?

Díky moc.

[MartinT]

Jde mi o nasledujici situaci, hlavni server s NFS a export /home, vice stanic v rezimu "tlusty klient" s ruznymi Linux distribucemi (mdk10.0, Aurox10.0, FC3 ...) a obcasnou potrebou se prihlasit jako jeden user z ruznych pocitacu (nemyslim soucasne, ale treba chvilku tady, pote jinde ...). Zajima me dopad na konfiguracni soubory jednotlivych programu, predevsim desktop systemu (KDE, GNOME ...).

Z nevedomosti/hlouposti jsem to jednou udelal. Defaultne pracuji na mdk10.0 s KDE a prihlasil jsem se v Aurox10.0 s KDE (rozdil verzi KDE minimalni, nejaka treti cislice) a litoval jsem. Po navratu k mdk10.0 stroji docela rozhozene KDE a totalne pokazena cestina (asi problem kodovani iso/UTF). Neprisel jsem na nic chytrejsiho nez usera smazat a znovu vytvorit.

Zajimaly by mne vase zkusenosti, pripadne jak takovou potrebu resite vy? Me napadlo jen:
a) pohrat si shell init skripty na serveru a pro novy stroj presouvat/prejmenovavat konfiguracni soubory a adresare -- desna pakarna, casem se na neco stejne zapomene
b) exportovat jen /home/user/Data, tam taky ukladat vse co se tyce dokumentu/prace a konfiguracni soubory mit na vsech strojich nativni a delat maximalne symlibky z $HOME na $HOME/Data/Prace etc.

[Ondrej Zajicek]

Zkusenosti s tim mam velice spatne - pokud jsou tam ruzne verze klientskych programum, tak casto jim vadi, ze maji konfiguracni soubory jine (novejsi) verze.

[Beda]

pr. mozilla (browser, 1.0, 1.6.x, 1.7.x), firefox 1.x a na problem je zadelano. jedina rozumna moznost je pred kazdou zmenou verze mazat profil.

Dalsi zajimavy artefakty delaji aplikace co si neinicializuji data pred pouzitim a spolehaji na nejakou vlastnost pridruzene knihovny. Treba pri tunelovani X aplikace. spoustena aplikace na woodym(backportovy firefox) zobrazovana na Xkach na nejakym starickym mandraku. segfaultne to protoze nektery graficky prvky se nevykresli jak maji. proste neco je jak kdyby neinicializovany a ve woodym se to vykresli barvou pozadi kdezto mandrake proste nicim a firefox to pak neustoji.

[O. Rusek]

U klienta si lze pohrát s celou řadou parametrů. Vedle standardního "defaults" mohou mít zásadní vliv na rychlost spojení, nicméně nelze dát žádný obecný návod - musíte prohledat diskuze a zkoušet. How-to doporučuje parametry "hard,intr".

No, já tu ve škole mám fileserver, který exportuje /home pro LSTP klienty (přes LTSP server) via NFS a ještě je nabízí win klientům via smb. K těm parametrům u klienta - doporučuji radši 'soft' než 'hard'. Konkrétně LTSP server ma v /etc/fstab toto:
edunix:/home /home nfs rw,bg,intr,soft,wsize=8192,rsize=8192
Vše jede na 100 mbps - propustnost ok.

[siboch]

Dobrý den,

zajímalo by mne, zda lze njk. způsobem specifikovat rozsah IP adres, abych nemusel vypisovat (a v budoucnu třeba přepisovat) všechny adresy. Např: /home/somebody 192.168.1.2-192.168.1.20/255.255.255.255 (rw,all_squash,anonuid=502,anongid=100,sync)

Pátral jsem po téhle možnosti, ale nikde jsem nenašel jak na to. Uvedený zápis nefunguje.