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

21. 4. 2005 | Zdeněk Štěpánek | Bezpečnost | 23870×

Typická situace. Hromada windowsových počítačů, které se přihlašují do domény na Sambě v Linuxu. Přeneseno do řeči unixáků, win stanice je jakoby tlustý klient a domácí adresář si tahá ze serveru. Nyní si popíšeme, jak to samé rozjet na linuxové stanici, a nakonec to doplníme o LTSP server.

Ze serveru potřebujeme na stanici dostat dvě věci: uživatelův domácí adresář (/home) a seznam uživatelů s hesly. K prvnímu nám poslouží NFS (Network File System) a k druhému NIS (Network Information Service). Dříve se používalo označení YP (Yellow Pages) a dodnes je to patrné z názvu programů. Pro tento účel by šly použít i modernější technologie jako je LDAP, PAM atd. My se ale budeme zabývat NISem.

NFS

Co je NFS, snad není potřeba sáhodlouze popisovat, takže jen ve zkratce. Je to unixový síťový filesystém, která podporuje uživatelská práva ve formátu UGO (User Group Other), tedy to, co známe z Linuxu. Na rozdíl od většiny ostatních protokolů (FTP, SMB, ...) je to bezestavový protokol. Neexistuje nic jako navázané spojení, přihlašování se apod. Klient pouze pošle na server požadavek, např. "vylistuj ./", a server mu odpoví. Pokud je klient nečinný, vůbec nevadí, pokud server odpojíme nebo restartujeme, klient si toho prakticky ani nevšimne. Běda však, pokud pracujeme na stanici s /home přes NFS a server se odpojí - systém doslova zamrzne pod rukama. Po nahození serveru se vše rozjede bez problémů.

NIS

NIS je klient/server systém pro zpřístupnění dat ze serveru na klienty. Alespoň taková je obecná definice. Postupně se ale vyprofiloval do systému, který zpřístupňuje data související s přihlašováním, hesly apod. Konkrétně jsou to tyto soubory (přesněji mapy):

ls /var/yp/domena.tld/

group.bygid
group.byname
hosts.byaddr
hosts.byname
mail.aliases
netid.byname
passwd.byname
passwd.byuid
protocols.byname
protocols.bynumber
rpc.byname
rpc.bynumber
services.byname
services.byservicename

Jak je vidět, řada souborů se exportuje vícekrát; rozdíl je v interním řazení položek.

Cílem NIS serveru je exportovat uživatelská jména a hesla ze serveru na stanice tak, aby se na stanici mohl přihlásit uživatel, který tam nemá lokální účet - obdoba přihlašování do domény u Windows.

Nastavení NFS na serveru:

NFS vyžaduje podporu v jádře. Distribuční jádra ji snad mají všechny a pokud ne, tak ji stačí dokompilovat. Jsou tam volby "NIS server" a "NIS klient" a vedle toho ještě zapnutí podpory NFS v3. Verze 3 je zastaralá už teď, takže určitě zapnout. V posledních jádrech nebo v -mm, -ac apod. by už snad měl být NFS v4. Dále je potřeba několik balíčků do systému. V textu budu popisovat situaci, kde klient je slackware-current a server je Red Hat 9.0. Je potřeba nainstalovat služby "portmap" a "nfs".

Nastavení, které se bude exportovat (neboli sdílet) je v /etc/exports:

cat /etc/exports

/home 192.168.5.143/255.255.255.255(rw,no_root_squash,sync)

Syntaxe je následující:

• /home
  Adresář, který se bude exportovat.
• 192.168.5.143/255.255.255.255
  Kdo bude mít přístup.
• rw
  read/write
• no_root_squash
  roota nebude přemapovávat na bezpečné UID/GID.
• sync
  Bude pracovat synchronně.

NFS nemá žádné vlastní bezpečnostní mechanismy (vyjma squashování UID/GID), jako je jméno a heslo. Adresář může připojit každý, kdo se nachází v rozsahu povolených IP adres. Pokud to chcete povolit pro celou síť, asi použijete 192.0.0.0/255.0.0.0.

Squashování UID/GID znamená, že pokud se na adresář snaží přistoupit user s UID 100, tak na NFS serveru bude mít UID 65435. UID se překlopí ke konci rozsahu. Stejně to funguje i pro GID. Lze nastavit i konkrétní UID číslo, na které se budou všichni klienti přemapovávat. Tento bezpečnostní mechanismus lze využít při vytváření public adresáře, ale pro nás je to nepoužitelné. NFS rozlišuje mezi squashováním obyčejných uživatelů (all_squash) a roota (no_root_squash). Squashování pro uživatele je ve výchozím nastavení vypnuté a pro roota zapnuté. Já osobně jsem squashování pro roota vypnul, abych se jako lokální root na stanici dostal do všech složek na serveru, nicméně to není nezbytně nutné a samozřejmě to představuje jisté bezpečnostní riziko. Pokud by se k adresáři připojil někdo, kdo má na své stanici roota, získá tak rootovský přístup ke všem home adresářům.

Nyní můžeme NFS server pokusně spustit:

service portmap start
Starting portmapper:        [  OK  ]

service nfs start
Starting NFS services:      [  OK  ]
Starting NFS quotas:        [  OK  ]
Starting NFS daemon:        [  OK  ]
Starting NFS mountd:        [  OK  ]

Pokud vše dobře dopadne, nastavte automatické spouštění služeb portmap a nfs při bootu.

Nastavení NFS u klienta

Potřebujeme balíčky "nfs-utils" a "portmap".

Připojování NFS adresáře se nastavuje klasicky v /etc/fstab:

192.168.1.2:/home /home nfs defaults 0 0

Syntaxe je následující:

• 192.168.1.2
  IP serveru.
• /home
  Adresář, který připojujeme.
• /home
  Kam ho připojíme na stanici.
• nfs
  Typ filesystému.
• defaults
  Parametry pro mount a NFS klienta.
• 0 0
  Klasické major a minor.

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".

Zkusíme připojit /home na stanici. Na pokus se hodí buď testovací stroj, kde není žádný uživatel mimo roota, nebo připojovat do jiného adresáře, např /serverhome. Měly by být vidět všechny adresáře uvnitř i se správnými UID a GID; prozatím ale pouze jako čísla, protože na stanici nejsou uživatelé s těmito UID a GID.

/etc/rc.d/rc.portmap start
Starting RPC portmapper:  /sbin/rpc.portmap

/etc/rc.d/rc.nfsd start
Starting NFS services:
  /usr/sbin/exportfs -r
  /usr/sbin/rpc.nfsd 8
  /usr/sbin/rpc.mountd
  /usr/sbin/rpc.lockd
  /usr/sbin/rpc.statd

mount /home

Pokud vše dobře dopadne, nastavte automatické spouštění služeb portmap a nfs při bootu. Adresář /home se bude připojovat sám.

Více o NFS lze najít v Linux NFS-HOWTO.

Příště

V druhém díle bude práce dokončena nastavením NIS na serveru a u klienta a instalací LSTP.

       

Komentáře

[......]

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.