OS X migreren naar Samba, Apple wordt steeds lastiger op de bedrijfsvloer

  • May 2, 2018
  • 0

In een vorig artikel schreef ik hoe wij een FreeBSD fileserver voor zowel Windows als OS X draaien. Daarbij werd uitgegaan van Netatalk, om de Mac’s via het AFP-protocol te bedienen en Samba voor de Windows-omgeving te draaien, via het SMB-protocol. Dit werkte prima, aangezien er vanuit Windows eigenlijk nooit wijzigingen werden gedaan op de Prepress-shares. Maar tijden veranderen: nooit werd soms en soms werd vaak. Dat ging problemen opleveren.

Indexen

Het beroerde van AFP is dat er op de server een index wordt bijgehouden van alle bestanden en mappen. Wat de gebruiker ziet, is eigenlijk deze index. Het is dus heel belangrijk dat de index altijd synchroon is met de echte bestanden en mappen. Daarom werkt Netatalk elke wijziging direct bij in deze indexen.

Dat gaat mis op het moment dat er wijzigingen gedaan worden buiten Netatalk om, bijvoorbeeld via Samba. Dan kloppen de indexen namelijk niet meer. Het gevolg is dat er klachten komen dat bestanden niet zichtbaar zijn op de Mac’s, terwijl de collega’s op de acquisitie volhouden dat die toch echt op de server staan.

Daarom eist Netatalk exclusieve toegang tot de bestanden, die via Netatalk gedeeld worden. Die mogen niet via een ander protocol gedeeld worden, terwijl dat dus wel gebeurde. Zolang het echter bij leesacties blijft, gaat het goed, maar zodra er wijzigingen gedaan worden, gaat het mis.

Apple stapt over

Het is mogelijk om Samba met Netatalk te integreren om dit te voorkomen. Maar dat was niet wat ik wilde. Er leek zich namelijk een veel betere oplossing voor te doen. Geheel afstappen van AFP en alleen nog maar SMB gebruiken.

Apple begon zich te realiseren dat AFP niet meer voldeed. En daarom is er sinds OS X 10.9 Mavericks overgestapt naar SMB. De oplossing leek dus eenvoudig: stel alle Mac’s in op SMB en je bent klaar. Simpel, toch?

Traag

Helaas, we hebben hier te maken met Apple. Apple zou zichzelf niet zijn, als ze zomaar een open standaard gaan gebruiken, zonder daar hun eigen stempel op te drukken. En dat natuurlijk zonder enige openheid van zaken. Apple heeft namelijk extra metadata aan SMB toegevoegd, waar een normale SMB-server niets van snapt. Ook een Windows-server gaat niet goed werken. Het is wat we van Apple gewend zijn. Mac’s onderling werken perfect, maar oh wee als je een niet-Apple oplossing wilt gebruiken…

Na de overstap regende het klachten dat de shares ontzettend traag waren. Soms duurde het meer dan een minuut, voordat de bestanden en mappen tevoorschijn kwamen, na het openen van een share en onderliggende mappen. Het is onnodig te zeggen dat de frustraties hoog opliepen. Op zich is dit probleem bekend, want er zijn klachten genoeg over te vinden op internet. Het vinden van een oplossing bleek echter een stuk lastiger.

Ik ben te rade gegaan bij andere grafische bedrijven en leveranciers. Volgens experts moest ik een Windows-server gaan draaien met ExtremeZ-IP. Maar ExtemeZ-IP is feitelijk niets anders dan een commerciële versie van Netatalk. Die gebruikt AFP, waar we nou juist van af wilden! Bovendien moest ik dan alle voordelen van ZFS inleveren. Natuurlijk is er nu ReFS, maar laat dat zich eerst maar eens bewijzen.

Een andere non-oplossing was het inzetten van een Mac Mini. Daar zou dan de server-versie van OS X op geïnstalleerd kunnen worden, zodat het geschikt was als fileserver. Op de vraag hoe ze dachten vele terabytes op een Mac Mini kwijt te kunnen, bleef het stil. Externe schijven? Dat zag ik niet zitten. Om over de performance nog maar te zwijgen.

Als één eigenschap ons open source liefhebbers kenmerkt, dan is het wel dat we stronteigenwijs kunnen zijn. Ik ging het advies van de experts niet overnemen.

VFS

Na lang zoeken bleek er een andere oplossing te zijn. Het bleek namelijk dat de laatste versies van Samba met dit probleem om konden gaan.

Sinds versie 2.2 heeft Samba de mogelijkheid om alle filesystem operations via een Virtual File System layer (VFS) te laten lopen. Deze laag bestaat uit modules, die in de configuratie van Samba geladen kunnen worden. Deze modules kunnen bepaalde bewerkingen op de data doen, voordat deze daadwerkelijk wordt weggeschreven. Op die manier kan de functionaliteit van Samba eenvoudig uitgebreid worden.

Er is een VFS-module, die de communicatie met OS X weer rechttrekt. Dat is de vfs_fruit module. Maar om dit probleem op te lossen, moet wel minimaal Samba 4.2 gebruikt worden. Dat was gelukkig geen enkel probleem en na de upgrade van Samba 3.6 naar 4.4 kon ik de configuratie aanpassen. De instellingen van een share zien er dan als volgt uit.

 

*** 

[01 Lopende Orders]

comment = 01 Lopende Orders

path = /Opslag/01_Lopende_Orders

valid users = @prepress @pcgebruikers

writeable = yes

printable = no

browseable = yes

create mask = 0775

directory mask = 0775

 

vfs objects     = zfsacl catia fruit streams_xattr

nfs4:mode       = special

nfs4:acedup     = merge

nfs4:chown      = yes

fruit:resource = file

fruit:metadata = netatalk

fruit:locking = none

fruit:encoding = native

fruit:nfs_aces = no

*** 

In de Global settings is de ea-module nodig, om vfs_fruit goed te laten werken. Verder gebruikt Samba-4.4 als default het SMB3-protocol, waardoor oudere clients niet goed meer werken. Dat betreft Windows XP of lager, Maar ook mijn Mint 18-desktop had er last van. Dat laatste kon ik eenvoudig oplossen door gewoon op SSH over te schakelen. Een andere mogelijkheid is het afdwingen van SMB2 in smb4.conf. Ik heb dat zelf echter niet geprobeerd.

***

[global]

ea support = yes

max protocol = SMB2#optioneel

***

Met de optie vfs object worden de modules geladeN in de aangegeven volgorde. De module zfsacl zorgt voor de acl support onder ZFS. Catia zorg voor de juiste character encoding. Ook dat moest Apple natuurlijk op een andere manier doen. Fruit zorgt voor de juiste metadata afhandeling, die Apple zelf aan SMB heeft toegevoegd. En streams_xattr is nodig om on fruit correct te laten werken. Vanwege een bug is het noodzakelijk om zfsacl voor de fruit module te laden, mocht je die willen gebruiken. Daarna kunnen per module nog verschillende opties ingesteld worden.

Na deze wijzigingen waren de problemen opgelost. De Mac’s konden weer met normale snelheid verbinding maken met de server. Het was niet langer noodzakelijk om Netatalk naast Samba te draaien, waarmee die problemen ook opgelost waren.

Van alle geboden oplossingen bleek open source de beste, goedkoopste en simpelste keuze te zijn. Onze eigenwijsheid kan soms op hoon en onbegrip rekenen, maar uiteindelijk trekken we aan het langste eind.

Tenslotte

Ik begin mij steeds meer af te vragen of het nog verstandig is om als bedrijf Mac’s te willen gebruiken. Het argument dat grafische software op Mac’s beter en sneller draait, gaat al een aantal jaren niet meer op. Sinds Apple de overstap naar Intel heeft gemaakt, is de hardware vrijwel hetzelfde als wat er in een normale pc zit. Het enige verschil is dat een Mac veel duurder is.

Het argument dat men OS X gewend is, is ook niet erg sterk. In 2001 kon immers ook de overstap gemaakt worden van OS-classic naar OS X, dat er echt heel anders uitzag.

Wat me de meeste zorgen baart is dat Apple zich niets meer van de zakelijke en professionele gebruiker aan lijkt te trekken. Er wordt juist sterk ingezet op de thuisgebruikers en die groep probeert Apple zoveel mogelijk in een niche Apple-hoekje te drukken. Dat doen ze door alles heel bewust incompatible te maken met alles wat niet-Apple is. De zakelijke gebruiker wordt in die trend meegesleurd.

Een thuisgebruiker kan ervoor kiezen om volledig Apple te gaan, maar een bedrijf heeft die luxe niet. Zodra je Apple probeert te verenigen met iets wat niet-Apple is, dan loop je tegen problemen aan. Gegarandeerd! Wat mij betreft kunnen de Mac’s dus zo snel mogelijk de deur uit. Daarvoor moet ik echter eerst de strijd aangaan met hardcore fanboys, maar dat is een verhaal voor een andere keer.

Bronnen