samba in combinatie met nfs

[Zym0tiC]

Tot vandaag gebruikte ik samba voor het delen van shares op mijn server. Dit omdat al mijn clients (3 stuks op win2k/xp draaide)
Nu ik echter sinds een maand 99% van de tjd linux op mijn workstation gebruik leek mij nfs een goede optie. Vooral omdat ik hiermee oa dit probleem kan verhelpen: [rml][ samba] mounten met behoud van de originele rechten.[/rml]

Nu is het wel zo dat mijn laptop nog winxp is, dit ivm de opleiding. Nu wil ik dus samba wel nog gewoon draaien voor als ik met mijn laptop shares wil benaderen.
Nu is de vraag echter gaat dit goed samen? Zowel onder samba als onder nfs worden de zelfde shares gedeelt. Het is dus niet zo dat mijn workstation en de samba shares en de nfs shares heeft gemapt maar nfs=workstation en samba=laptop.

De kans dat dezelfde file door beide wordt geopend is relatief klein aangezien het een thuis netwerkje is. Maar ik zou toch graag willen weten hoe dit zich verhoud als het toch gebeurd.

Verder gaat nfs standaard via UDP. In de kernel kan ik echter ook kiezen voor TCP, wat normaal gesproken beter is, iig voor dit werk. Nu is de vraag alleen hoe goed de TCP support is voor nfs.

De server draait trouwens slackware 10.1 current, de workstation Ubuntu Hoary 5.04

[Zwerver]

Uhhh, sorry, maar 1 files 2x openen is natuurlijk nooit handig Verder denk ik dat je het gewoon maar eens moet proberen Ik kan je bijna op een blaadje geven dat je in de nfs config file overigens kan instellen hoe er met file-locks om gegaan moet worden, maar zelfs ik heb soms luie momenten

[irondog]

Om even in te gaan wat je in dit topic hebt aangehaald:
[rml][ samba] mounten met behoud van de originele rechten.[/rml]

Het is gezwets dat Samba niet meer is dan een fileserver voor windows clients. Ook voor unix kan het prima in alle mogelijke behoeften voorzien. De nodige user, group en world attributen kunnen vanuit het onderliggende filesystem op de server overdragen naar clients. Samba implementeert als netwerk filesystem gewoon de rechten en alle mogelijke nuttige syscalls die we gewend zijn in GNU/Linux.

Wil je hiervan gebruik maken, moet je een Samba share mounten als CIFS en dus niet met het alom bekende SMBFS.
Voorbeeld:

code:

mount -t cifs //localhost/test /mnt/test
ls /mnt/test
total 24
drwxr-xr-x   4 root  root     0 May 21 01:09 .
drwxr-xr-x  17 root  root  4096 May  6 01:05 ..
-rw-r--r--   1 root  root     0 May 18 22:12 .keep
drwxr-xr-x   2 root  root     0 May 21 01:09 vanroot
drwxr-xr-x  64 ik ik    0 May 21 01:10 vanmij

Voila, weer geruchten uit de wereld geholpen.

Locking
Windows en Unix verschillen verschrikkelijk veel op het gebied van file-locking. Een lock in Windows betekent grofweg dat een fopen() op een gelockte file mislukt voor het process dat een poging neemt een in gebruik zijnde file te openen.

In Unix kennen we ook locking. Echter, na het zetten van een lock (met fcntl() of met flock()) door een proces, moet een ander proces 'vragen' of er een lock is om vervolgens mogelijke restricties naar de gebruiker toe te passen. OpenOffice negeert bijvoorbeeld alle Posix locks tenzij een bepaalde omgevings variabele gezet is bij het laden.

Een posix lock op een file (flock en fcntl) zal door samba NIET gezet worden bij het openen. Samba registreert locks in haar eigen database. Als een file eenmaal geopend is, zal samba na een lock request van de client geen andere clients write toegang verschaffen. Dat neemt niet weg dat jij naar hartelust met OpenOffice in een document kan schrijven (stel: om samba heen) tewijl een samba hem voor een client in gebruik heeft. Zo werkt Unix.

Om samba wel posix locks te laten zetten in het onderliggende filesystem is aanpassing van de broncode vereist. Maar dan nog zal het je niet weerhouden om met vi en friends dingen scheeft te laten lopen. Posix locks gezet door andere programma's dan smbd zelf worden desalnietemin wel gewoon door Samba opgenomen.

De kans dat dezelfde file door beide wordt geopend is relatief klein aangezien het een thuis netwerkje is. Maar ik zou toch graag willen weten hoe dit zich verhoud als het toch gebeurd.

Wat je nu nog met NFS, samba en locking wil, moet je zelf even bekijken. Als je aleen MSword en Openoffice gebruikt als samba client is met locking te voorkomen dat dingen scheeflopen. Met andere programma's wordt dat moeilijker.

[Zym0tiC]

@ Zwerver: Dat van de 2 files openen begrijp ik. Maar ik ga ervan uit dat als je 2 zelfde files opent onder samba _of_ nfs een van deze dat wel in de onderliggende structuur afhandeld. Maar omdat je in mijn voorbeeld te maken had met 2 verschillende programma's wist ik dus niet hoe dit dan werd opgelost.

Ik moet zeggen dat dat stukje over locking van irondog erg duidelijk is . Verder wist ik dat niet van CIFS. Ik heb net ff snel geprobeerd, heb wat weinig tijd atm, maar volgens mij doet dit precies wat het moet doen.

Dan vraag ik me echter af.... waarom zie je dit niet vaker voorkomen? Tot nu toe heb ik 99 van de 100 keer alleen maar SMBFS gezien. Is het gewoon een kwestie van niet weten? Of zitten er nadelen aan?

[irondog]

CIFS is een stuk nieuwer en moderner dan SMBFS. Je moet er ook een redelijk recente kernel voor hebben wil je CIFS kunnen gebruiken. Verder kan documentatie achter lopen en zijn er heel wat mensen die maar wat in de ruimte kletsen omdat ze ook ooit eens een middagje met samba hebben zitten spelen
Niet alle ideeën waarvoor CIFS ontworpen is, zijn al doorgevoerd. Het is nog in ontwikkeling.

Mijn achtergrond met Samba en file-locking komt met wat hackwerk dat ik verricht heb. Ik heb ooit een patch geschreven voor samba3 clusters om locking over netwerk filesystems door te geven. Deze is trouwens niet officieel opgenomen. Als je interesse hebt om het te testen op NFS, moet je maar iets laten weten.

[Zym0tiC]

Ik heb net eens even met CIFS gespeeld en ik kwam op een paar probleempjes uit.

Ik heb trouwens gebruik gemaakt van dit artikel: http://www.linux-mag.com/content/view/1645/2188/

Daarin wordt het volgende verteld:

Permissions modes work as you'd expect. Existing modes are passed to the client, and users can change the modes of their files with chmod or similar tools. There is one caveat: the Samba create mode and directory mode parameters can block creation of certain modes. For instance, if you've set create mode = 0644, you won't be able to set group-or world-write access to the file, nor will you be able to set any execute permissions.

Dit is wel een vervelend probleem, ik zou graag willen dat een user de groep/world kan veranderen van een file waar hij rechten op heeft. Hier is zeker nog geen oplossing voor gevonden....

Verder heb ik op dit moment weinig aan te merken op CIFS, het is eigenlijk alles wat ik nodig had tot nu toe. Op het probleem hierboven na dan.

Binnenkort ga ik eens aan de slag met ACL. Ik las namelijk dat samba hier standaard ondersteuning voor had en wil wel eens kijken wat ik er mee opschiet als ik een winxp machine laat inloggen op mijn server.