Re: Zentrale File-Ablage fuer Macs
Thomas Kaiser
> habe ein paar Fragen bzgl. zentraler File-Ablage fuer Macs.
>
> Ausgangssituation:
> ------------------
> - 3x PowerMacs 7.3 (G5,PPC) mit zuletzt OS X 10.4.11
> - zentral abgelegt werden sollen Excel-Dateien und
> Prüfprogramme (propritäre Binärdateien, welche im Finder einem
> bestimmten Programm auf den Macs zugeordnet sind)
> - auf die Excel-Dateien wird auch von der Windows-Seite aus zugegriffen
>
> - bisher gelöst: Services for Macintosh + Windows-Share auf W2k3-Server
> (SP2 + alle Patches), Zugriff von den Mac aus per afp
>
>
> neue Situation:
> ---------------
> - 1 neuer Intel-Mac (MacPro 4.1) mit OS X 10.6.2
> ==> hat kein afp
Quatsch. Der mag kein AppleTalk mehr haben was aber gleichfalls wurscht
ist, weil Du auch von 10.4.11 auf den Win2k3 Server per AFP over TCP
zugegriffen hast.
10.6 kann sich halt nicht mehr mit den ollen buggy Services for
Macintosh verbinden (AFP 2.2). Simple Abhilfe: Passenden AFP-Server für
Windows kaufen, bspw. ExtremeZ-IP oder MacServer IP. Siehe bspw.:
<http://www.knubbelmac.de/themen/afp-server-vergleich.html>
> - Update der G5-Macs auf 10.5.8
> ==> ein G5-Mac läßt sich nicht updaten
> ==> wird kommendes Jahr durch Intel-Mac abgelöst
>
>==> aktuell: 2xG5 (PPC) mit 10.5.85; Zugriff per afp
> 1xG5 (PPC) mit 10.4.11; Zugriff per afp
> 1xIntel Mac mit 10.6.2; Zugriff per smb
>
> Problem:
Genau: Problem deshalb, weil der Fehler gemacht wird, parallel per SMB
und AFP auf ein und die selbe Share zuzugreifen. Das geht *immer* in die
Hose, weil bei AFP Finder-Metadaten (wie FileType/Creator als auch
Resourcefork) völlig anders übertragen (und auf Windows-Servern auch
gespeichert) werden als via SMB. In letztem Fall sorgt das client-
seitige VFS-Modul dafür, daß diese Metadaten und eine evtl. vorhandene
Resourcefork in eine AppleDouble-kodierte Datei, deren Name mit "._"
beginnt, neben die eigentliche Datafork gelegt wird.
Daher: Nie SMB- und AFP-Zugriff auf ein und der selben Share mischen.
Das muß in die Hose gehen außer man nimmt client-seitig DAVE, das auch
per SMB die Dateien so auf dem Server speichern kann (in drei separaten
NTFS-Filestreams) wie sie per AFP gespeichert würden.
Zudem sind die SFM, die Ihr benutzt, einfach uralt und fehlerhaft.
Simpelste Abhilfe: Besseren AFP-Server verwenden.
> In Abhängigkeit davon, welcher Typ Mac die Prüfprogramme auf den Shares
> geschrieben hat bzw. von wo aus sie kopiert wurden, sind diese von den
> anderen Macs nicht mehr lesbar, d.h., sie werden nur noch als unix
> executeables erkannt. Die Excel-Dateien sind davon nicht betroffen.
>
> Eine Verlagerung der Shares auf ein SAN (NetApp Ontap 7.2.6) mit CIFS
> brachte keine Verbesserung der Situation, eher eine Verschlechterung
> durch noch mehr undefiniertes Verhalten. Das liegt aber auch daran, dass
> OS X(10.6.2/10.5.8) erst ab Ontap 7.3.2 sauber unterstützt wird, OS X
> 10.4.11 allerdings nur bis Ontap 7.3.1.1 :-(
Ja mei, SMB und MacOS X halt...
> Z.Z. liegen die Shares also wieder auf dem ursprünglichen
> Windows-Server, unterteilt in Bereiche, so dass sich die verschiedenen
> Macs nicht in die Quere kommen.
>
> Fragen:
>
> - Zentrale Ablage von Mac-Binärdateien:
> Wie löst man das sauber, ohne XSan/XServer kaufen zu müssen?
Wenn's nur um Macs geht, irgendeinen AFP 3.1-fähigen File-Server
einsetzen, fertig. Wenn's um gemischten Einsatz Mac/Windows und Zugriff
auf identische Sharepoints geht, dann die Macs per AFP zugreifen lassen
und drauf achten, daß der AFP-Server sauber mit dem auf dem Server
installierten SMB-Server für die Windows-Clients interagiert
(Encoding-Problematiken, Locking). Das schränkt die Möglichkeiten dann
ein auf:
* Unter Windows ExtremeZ-IP oder MacServer IP in aktuellen Versionen
einsetzen
* Unter Unix/Linux/MacOS X Helios EtherShare/PCShare
* Unter MacOS X (Server) die eingebauten File-Services (aber erst ab
10.4 -- davor klappt's noch nicht mit Byte-Range-Locking zwischen den
Plattformen)
> - Welche Erfahrungen bestehen mit der Ablage von Mac Binärdateien
> bzgl. SAN im allgemeinen und CIFS im besonderen?
Was jetzt? SAN oder CIFS (also NAS)?
Gruss,
Thomas
Goetz Hoffart
> Passenden AFP-Server für
> Windows kaufen, bspw. ExtremeZ-IP oder MacServer IP.
Kann man MacServer IP noch in der Liste drinlassen? Ich zitiere mal von
deren Homepage <http://www.cyansoftware.com/MacServerIP.htm>:
»• new: Full support for TIGER MacOSX 10.4«
Das gammelt doch bald ...
Grüße
Götz
--
http://www.knubbelmac.de/
Dominik Schlütter
> habe ein paar Fragen bzgl. zentraler File-Ablage fuer Macs.
Vermutlich sind deine Fragen nebenan in <de.comp.sys.mac.lokale-netze>
besser aufgehoben, ich setze mal ein x-post und f'up dahin.
> Ausgangssituation:
> ------------------
> - 3x PowerMacs 7.3 (G5,PPC) mit zuletzt OS X 10.4.11
> - zentral abgelegt werden sollen Excel-Dateien und
> Pr�fprogramme (proprit�re Bin�rdateien, welche im Finder einem
> bestimmten Programm auf den Macs zugeordnet sind)
> - auf die Excel-Dateien wird auch von der Windows-Seite aus zugegriffen
>
> - bisher gel�st: Services for Macintosh + Windows-Share auf W2k3-Server
> (SP2 + alle Patches), Zugriff von den Mac aus per afp
Hmm. Was du an Alternativen f�r den Windows-Server hast, wird z.B. unter
<http://www.knubbelmac.de/themen/afp-server-vergleich.html?platform=4&af
p_version=1&afp_features=1&uams=1&supported=1&sort=1&schritt=1>
aufgelistet. Mit SFM hat man bei aktuellen Macs halt diverse Probleme.
> neue Situation:
> ---------------
> - 1 neuer Intel-Mac (MacPro 4.1) mit OS X 10.6.2
> ==> hat kein afp
Der kann sehr wohl AFP. Allerdings kann es da eventuell mit den UAMs
Probleme geben, weil Microsoft IIRC keine der standardm��ig am Mac
vorhandenen nutzt.
> - Update der G5-Macs auf 10.5.8
> ==> ein G5-Mac l��t sich nicht updaten
> ==> wird kommendes Jahr durch Intel-Mac abgel�st
Das w�rde ich mal n�her untersuchen. Auf einem G5 darf das kein Problem
sein - wer wei�, was da noch im Argen liegt.
> ==> aktuell: 2xG5 (PPC) mit 10.5.85; Zugriff per afp
> 1xG5 (PPC) mit 10.4.11; Zugriff per afp
> 1xIntel Mac mit 10.6.2; Zugriff per smb
>
> Problem:
>
> In Abh�ngigkeit davon, welcher Typ Mac die Pr�fprogramme auf den Shares
> geschrieben hat bzw. von wo aus sie kopiert wurden, sind diese von den
> anderen Macs nicht mehr lesbar, d.h., sie werden nur noch als unix
> executeables erkannt. Die Excel-Dateien sind davon nicht betroffen.
>
> Eine Verlagerung der Shares auf ein SAN (NetApp Ontap 7.2.6) mit CIFS
> brachte keine Verbesserung der Situation, eher eine Verschlechterung
> durch noch mehr undefiniertes Verhalten. Das liegt aber auch daran, dass
> OS X(10.6.2/10.5.8) erst ab Ontap 7.3.2 sauber unterst�tzt wird, OS X
> 10.4.11 allerdings nur bis Ontap 7.3.1.1 :-(
>
> Z.Z. liegen die Shares also wieder auf dem urspr�nglichen
> Windows-Server, unterteilt in Bereiche, so dass sich die verschiedenen
> Macs nicht in die Quere kommen.
Du solltest dir IMHO mal alternative AFP-Serversoftware anschauen.
Vermutlich l�st du damit einen Gro�teil deiner Probleme.
> Fragen:
>
> - Zentrale Ablage von Mac-Bin�rdateien:
> Wie l�st man das sauber, ohne XSan/XServer kaufen zu m�ssen?
>
> - Welche Erfahrungen bestehen mit der Ablage von Mac Bin�rdateien
> bzgl. SAN im allgemeinen und CIFS im besonderen?
Ich habe mit CIFS am Mac keine guten Erfahrungen gemacht - es ist
relativ langsam und hat fr�her oder sp�ter zu Problemen gef�hrt. Das ist
jetzt allerdings schon etwas her und bezieht sich prim�r auf Mac OS X
10.4, keine Ahnung ob das mit aktuelleren Systemen besser geworden ist.
Im Mischbetrieb mit Windows st�ren gelegentlich auch die separaten
Metadatendateien, die der Mac so anlegt - aber das hat man mit anderen
Protkollen wie NFS ja auch.
Gru�,
Dominik.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Passenden AFP-Server für Windows kaufen, bspw. ExtremeZ-IP oder
>> MacServer IP.
>
> Kann man MacServer IP noch in der Liste drinlassen? Ich zitiere mal von
> deren Homepage <http://www.cyansoftware.com/MacServerIP.htm>:
>
> »• new: Full support for TIGER MacOSX 10.4«
>
> Das gammelt doch bald ...
Naja, da gammelt wohl eher nur die Webseite. Laut Dirk
<news:1jaeir1.1rk0ft2101mkcbN%dirk....@arcor.de>
sind aktuelle Versionen auch mit 10.6 kompatibel gemacht worden. Man muß
halt Preis und Features abwägen und dann gucken, ob man nicht doch
lieber zu ExtremeZ-IP greift (AFP 3.2 nebst weiteren Schmankerln)
Gruss,
Thomas
Dirk Kring
Die Cyanseite taugt nichts, aber
<http://www.impressed.de/t/produkt.taf?fn=detail&PR_ID=1032>
hat aktuelle Versionen und hier auch ein Eintrag, der sich auf 10.6
bezieht
<http://www.impressed.de/t/produkt.taf?fn=detail&PR_ID=1032&link=sdet&si
d=33715%2E000000>
--
Dirk Kring
Thomas Kaiser
> Im Mischbetrieb mit Windows stören gelegentlich auch die separaten
> Protkollen wie NFS ja auch.
Hä? Was meinst Du konkret? Die .DS_Store-Dateien oder mehr?
Gruss,
Thomas
Christian Winther
[...]
>> neue Situation:
>> ---------------
>> - 1 neuer Intel-Mac (MacPro 4.1) mit OS X 10.6.2
>> ==> hat kein afp
>
> Quatsch. Der mag kein AppleTalk mehr haben was aber gleichfalls wurscht
> ist, weil Du auch von 10.4.11 auf den Win2k3 Server per AFP over TCP
> zugegriffen hast.
War die Aussage des Technikers, der die Installation/Umstellung der Macs
gemacht hat.
> 10.6 kann sich halt nicht mehr mit den ollen buggy Services for
> Macintosh verbinden (AFP 2.2). Simple Abhilfe: Passenden AFP-Server für
> Windows kaufen, bspw. ExtremeZ-IP oder MacServer IP. Siehe bspw.:
>
> <http://www.knubbelmac.de/themen/afp-server-vergleich.html>
Ok. Schau ich mir an.
[...]
[Nie SMB und AFP-Zugriff auf gleichem Share mischen]
Das war mir in dieser Deutlichkeit nicht bekannt. Danke für die
fundierte Aufklärung! Findet man dazu auch etwas in den Tiefen der
Apple-Websites? Oder was sind die richtigen Suchworte für Tante Guh?
[...]
>> - Welche Erfahrungen bestehen mit der Ablage von Mac Binärdateien
>> bzgl. SAN im allgemeinen und CIFS im besonderen?
>
> Was jetzt? SAN oder CIFS (also NAS)?
Wir haben als SAN Netapp im Einsatz. Netapp bietet in der Klasse, die
wir haben, von Haus aus Fileservice (NFS, CIFS) an. Wir wickeln unseren
Fileservice, d.h., unsere Netzwerklaufwerke per Netapp CIFS ab. Das hat
den Vorteil eines zentralen Backups, Snapshots, dem Vorhalten mehrerer
Fileversionen (1Woche alt, 1Tag alt, 4h alt,...) etc. Dort hätte ich
halt auch gern die Daten der Macs liegen. Das Backup dieser CIFS erfolgt
per NDMP-Backup von einem Windows-Server aus. Die Frage ist halt, wenn
schon das Backup funktioniert, wie schaut's mit der Lesbarkeit des
Restores aus? Wenn ich Dich richtig verstanden habe, dann sollte das
funktionieren, wenn der Zugriff auf alle Daten nur noch per smb erfolgt
und afp ganz außen vor bleibt.
MfG CW
Dirk Kring
Preise laut Impressed
Artikelname Plattform VK exkl VK inkl
MacServerIP Server 9.0, 5 clients Win 495,00 589,05
MacServerIP Server 9.0, 10 clients Win 895,00 1065,05
ich kenne leider nicht die ExtremeZ-IP Preise.
--
Dirk Kring
Dominik Schlütter
> H�? Was meinst Du konkret? Die .DS_Store-Dateien oder mehr?
Die eigentlich auch, aber vor allem das, was vom Mac an "Ressourcen" in
den ._-Dateien landet.
Das ist ja kein Problem des Servers, sondern eines des Benutzers - denn
bislang war es immer so, dass fr�her oder sp�ter jemand den Datenzweig
von einzelnen Dateien verschiebt oder umbenennt und dann eine ._Leiche
�brig bleibt. Oder dass Leute zum Admin laufen und sagen, dass Datei xy
sich nicht �ffnen l�sst und sich dann herausstellt, dass sie den
Ressourcenzweig benutzen wollen. Und dergleichen mehr ... .
Gru�,
Dominik.
Christian Winther
[...]
>
> Hmm. Was du an Alternativen f�r den Windows-Server hast, wird z.B. unter
> <http://www.knubbelmac.de/themen/afp-server-vergleich.html?platform=4&af
> p_version=1&afp_features=1&uams=1&supported=1&sort=1&schritt=1>
> aufgelistet. Mit SFM hat man bei aktuellen Macs halt diverse Probleme.
Danke. Schau ich mir an.
>> neue Situation:
>> ---------------
>> - 1 neuer Intel-Mac (MacPro 4.1) mit OS X 10.6.2
>> ==> hat kein afp
>
> Der kann sehr wohl AFP. Allerdings kann es da eventuell mit den UAMs
> Probleme geben, weil Microsoft IIRC keine der standardm��ig am Mac
> vorhandenen nutzt.
War eine Aussage des Technikers, der den installiert hat.
>> - Update der G5-Macs auf 10.5.8
>> ==> ein G5-Mac l��t sich nicht updaten
>> ==> wird kommendes Jahr durch Intel-Mac abgel�st
>
> Das w�rde ich mal n�her untersuchen. Auf einem G5 darf das kein Problem
> sein - wer wei�, was da noch im Argen liegt.
Ja, aber erst nachdem er ersetzt wurde. Ich will doch auch mal einen Mac
zum spiel^W testen. ;-)
[alternative AFP Serversoftware beschaffen]
Mir w�re es am Liebsten, wenn ich die Daten der Macs auf die CIFS der
Netapp bekommen w�rde. OK, vorher muss ich das dortige OS updaten.
Die Frage ist halt, ob CIFS/smb-Zugriff mit den Bin�rdaten funktioniert,
und ob die u.U. aus dem NDMP-Backup restorten Bin�rdaten funktionieren.
Werde ich wohl testen m�ssen, wenn hier keine Erfahrung mit sowas hat.
MfG CW
Goetz Hoffart
> Mir w�re es am Liebsten, wenn ich die Daten der Macs auf die CIFS der
> Netapp bekommen w�rde.
BTDT. Ich habe damit nur m��ig gute Erfahrungen gemacht - CIFS ist halt
CIFS. Das f�ngt bei den Dateinamenskonventionen an und h�rt mit der
Langsamkeit auf.
Ansonsten kannst du dir ja lustige Spielchen ausdenken f�r das Ziel "ich
will die Daten auf der Netapp haben", wie etwa die Netapp per iSCSI
rausreichen, an einem XServe o.�. beziehen und das per AFP an die
Mac-Clients rausreichen.-)
Gr��e
G�tz
--
http://www.knubbelmac.de/
Dirk Kring
>
> [alternative AFP Serversoftware beschaffen]
>
> Mir w�re es am Liebsten, wenn ich die Daten der Macs auf die CIFS der
> Netapp bekommen w�rde.
Liegt da nicht ein Unix drunter oder habe ihr eine mit Windows?
--
Dirk Kring
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Man muß halt Preis und Features abwägen und dann gucken, ob man nicht
>> doch lieber zu ExtremeZ-IP greift (AFP 3.2 nebst weiteren
>> Schmankerln)
>>
> Preise laut Impressed
> Artikelname Plattform VK exkl VK inkl
> MacServerIP Server 9.0, 5 clients Win 495,00 589,05
> MacServerIP Server 9.0, 10 clients Win 895,00 1065,05
> ich kenne leider nicht die ExtremeZ-IP Preise.
Ich hab auch nur 2-3 Jahre alte:
* ExtremeZ-IP 5, 10 Users: $1,345
* ExtremeZ-IP 5, 100 Users: $3,195
Lauffähigkeit laut Group Logic auf "Server 2000, 2003, Storage Server,
XP Pro, XP Embedded, Windows Powered NAS".
Hier in D sollte man sich an Konzept-ix wenden:
<http://www.konzept-ix.com/grouplogic/extremez-ip.html>
Mein Spotlight hat da eben ein Angebot für die 25-User Version für
1.450,- EUR netto zutage gefördert. Keine Ahnung, selber fragen.
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser schrieb:
> [...]
>
> [Nie SMB und AFP-Zugriff auf gleichem Share mischen]
>
> Das war mir in dieser Deutlichkeit nicht bekannt. Danke für die
> fundierte Aufklärung! Findet man dazu auch etwas in den Tiefen der
> Apple-Websites? Oder was sind die richtigen Suchworte für Tante Guh?
Vermutlich findest Du was auf macwindows.com. Und hier im Archiv der
Gruppe einiges dazu. Bei Apple vielleicht auch (wobei ich meist bei
Suchen, discussions.apple.com von vorneherein ausschließe, weil da so
viel Quatsch im Brustton der Überzeugung gepostet wird, daß es viel zu
aufwändig ist, das alles manuell bzw. per Hirn auszufiltern)
> Wir haben als SAN Netapp im Einsatz. Netapp bietet in der Klasse, die
> wir haben, von Haus aus Fileservice (NFS, CIFS) an. Wir wickeln
> unseren Fileservice, d.h., unsere Netzwerklaufwerke per Netapp CIFS
> ab. Das hat den Vorteil eines zentralen Backups, Snapshots, dem
> Vorhalten mehrerer Fileversionen (1Woche alt, 1Tag alt, 4h alt,...)
> etc. Dort hätte ich halt auch gern die Daten der Macs liegen.
Verständlich. Ich war zweimal in Projekte involviert, bei denen NetApp-
Filer und Macs involviert waren. Ging in sinnvoll eh nur mittels DAVE
auf den Clients (weil dann Speicherung der Mac-Resourcen als ADS [1],
d.h. _nicht_ als Dateischwesterchen, das daneben liegt und gerne mal
verloren gehen kann). Aber das war dermaßen lahm, daß in beiden
Installationen NetApp als SAN genutzt werden mußte (also Einbindung als
lokales Dateisystem auf 'nem Windows-Server, Erwerb von ExtremeZ-IP und
dann Sharing des Dateisystems via AFP/SMB).
> Die Frage ist halt, wenn schon das Backup funktioniert, wie schaut's
> mit der Lesbarkeit des Restores aus? Wenn ich Dich richtig verstanden
> habe, dann sollte das funktionieren, wenn der Zugriff auf alle Daten
> nur noch per smb erfolgt und afp ganz außen vor bleibt.
Auch bei "nur SMB" muß man aufpassen, wie man's einsetzt. Apples
VFS-Modul erzeugt "._"-Dateien, DAVE bspw. schreibt ADS (wie auch die
SFM, ExtremeZ-IP oder MacServer IP). Diese beiden Varianten sind eben
zueinander inkompatibel und ein Mischbetrieb früher oder später tödlich.
Wenn man mal in der häßlichen Situation ist, hilft evtl. noch Marcel
Bresinks Fork Server Helper... Äh, nö:
<http://www.bresink.de/osx/ForkServerHelper-de.html>
Gruss,
Thomas, schon zweimal bei Kunden per Skripting Dateien, die per SMB und
AFP auf Windows-Server gelandet sind, konsolidiert habend -- macht nur
bedingt Spaß...
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> schrieb:
>
>> Hä? Was meinst Du konkret? Die .DS_Store-Dateien oder mehr?
>
> Die eigentlich auch, aber vor allem das, was vom Mac an "Ressourcen"
> in den ._-Dateien landet.
Die kommen ja nur auf den Server, wenn man zwischen Mac und Server SMB
nutzt... und das per Apples Bordmitteln und nicht bspw. DAVE.
Es ist also genaugenommen nicht das Problem mit dem Mischbetrieb mit
Windows sondern rein, daß man den Zugriff vom Mac mittels Apples
CIFS-VFS-Modul realisiert.
> Das ist ja kein Problem des Servers, sondern eines des Benutzers -
> denn bislang war es immer so, dass früher oder später jemand den
> Datenzweig von einzelnen Dateien verschiebt oder umbenennt und dann
> eine ._Leiche übrig bleibt.
Was dann dazu führt, daß der Datenzweig seiner Metadaten und ggf.
Resourcefork beraubt ist, und sich dann nicht mehr einfach so am Mac
öffnen läßt bzw. seines Inhalts beraubt ist (sehr beliebt: Alte
Type-1-Fonts, die alles an Daten in der Resource Fork tragen)
> Oder dass Leute zum Admin laufen und sagen, dass Datei xy
> sich nicht öffnen lässt und sich dann herausstellt, dass sie den
> Ressourcenzweig benutzen wollen. Und dergleichen mehr ... .
Genau. SMB am Mac besser vermeiden. Oder auf die eine oder andere Art
leiden...
Gruss,
Thomas, auch Installationen kennend, in denen "null Probleme mit SMB und
Macs bestehen" -- das ist aber immer nur die Meinung des Admins. Die
User sehen das immer ganz anders.
Christian Winther
> Christian Winther <cw20...@gmx.de> wrote:
>
>> Mir w�re es am Liebsten, wenn ich die Daten der Macs auf die CIFS der
>> Netapp bekommen w�rde.
>
> BTDT. Ich habe damit nur m��ig gute Erfahrungen gemacht - CIFS ist halt
> CIFS. Das f�ngt bei den Dateinamenskonventionen an und h�rt mit der
> Langsamkeit auf.
Geschwindigkeit ist tempor�r. Da wird 1,2,3,4 mal pro Schicht so ein
Pr�fprogramm gelesen und damit gearbeitet. �nderungen, welche
geschrieben werden, sind selten.
In Excel werden ab und an ein paar Pr�fwerte etc. eingetragen und
geschrieben.
> Ansonsten kannst du dir ja lustige Spielchen ausdenken f�r das Ziel "ich
> will die Daten auf der Netapp haben", wie etwa die Netapp per iSCSI
> rausreichen, an einem XServe o.�. beziehen und das per AFP an die
> Mac-Clients rausreichen.-)
Hab' ich ja jetzt schon. VMware-Volume an virtuellen W2k3, allerdings
mit dem veralteten SFM. H�tte halt gern die Vorteile der CIFS auf der
Netapp genutzt. OK. Ontap 7.3.2 ist ziemlich neu. Mal schauen, ob das
was bringt.
MfG CW
Goetz Hoffart
> Thomas, auch Installationen kennend, in denen "null Probleme mit SMB und
> Macs bestehen" -- das ist aber immer nur die Meinung des Admins. Die
> User sehen das immer ganz anders.
Full ACK. Das f�hrt in einer Firma dazu, dass die ~20 Leute alle nicht
mehr den gro�en dicken CIFS-Storage nutzen, sondern mit externen Platten
hin- und herlaufen und Peer-Freigaben mit AFP nutzen.
Und der Admin freute sich neulich, dass er mit 10 GB Quota auf dem
Server alle Leute abgefr�hst�ckt bekommt. Klar, die legen da auch nix
wichtiges hin.
Christian Winther
Die liegt ein Ontap drunter (was immer das ist). Scheint zumindest
unixoid zu sein und fa�t sich in der Shell so an.
MfG CW
Dominik Schlütter
> Die kommen ja nur auf den Server, wenn man zwischen Mac und Server SMB
> nutzt... und das per Apples Bordmitteln und nicht bspw. DAVE.
Ja. Deshalb auch mein Hinweis auf NFS, wo das genauso passiert.
> Es ist also genaugenommen nicht das Problem mit dem Mischbetrieb mit
> Windows sondern rein, da� man den Zugriff vom Mac mittels Apples
> CIFS-VFS-Modul realisiert.
Wenn nur Macs (mit der gleichen Software, also z.B. dem systemeigenen
Client) auf den SMB-Server zugreifen, dann hat man das Problem nicht -
die sehen die einzelnen Dateien ja nicht. Problematisch wird es immer
erst, wenn andere Systeme dazu kommen. Oder jemand, der am Server direkt
das Dateisystem befummelt.
> Was dann dazu f�hrt, da� der Datenzweig seiner Metadaten und ggf.
> Resourcefork beraubt ist, und sich dann nicht mehr einfach so am Mac
> �ffnen l��t bzw. seines Inhalts beraubt ist (sehr beliebt: Alte
> Type-1-Fonts, die alles an Daten in der Resource Fork tragen)
Das war hier eher selten ein Problem - bei den meisten Datenformaten,
die man zwischen Macs und Windows austauscht, kommt man notfalls mit der
Datafork aus. Aber nat�rlich kann man da auch noch auf die Nase fallen.
> Genau. SMB am Mac besser vermeiden. Oder auf die eine oder andere Art
> leiden...
Sag ich ja :-).
Gru�,
Dominik.
Thomas Kaiser
>>> der Netapp bekommen würde.
>>
>> BTDT. Ich habe damit nur mäßig gute Erfahrungen gemacht - CIFS ist
>> halt CIFS. Das fängt bei den Dateinamenskonventionen an und hört mit
>> der Langsamkeit auf.
>
> Geschwindigkeit ist temporär. Da wird 1,2,3,4 mal pro Schicht so ein
> Prüfprogramm gelesen und damit gearbeitet. Änderungen, welche
> geschrieben werden, sind selten.
>
> In Excel werden ab und an ein paar Prüfwerte etc. eingetragen und
> geschrieben.
Hmm... dann würde ich aber wirklich mal einen Blick auf DAVE riskieren.
<http://www.thursby.com/evaluations/dave.html>
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> schrieb:
>
>> Die kommen ja nur auf den Server, wenn man zwischen Mac und Server
>> SMB nutzt... und das per Apples Bordmitteln und nicht bspw. DAVE.
>
> Ja. Deshalb auch mein Hinweis auf NFS, wo das genauso passiert.
Bei NFS rennt man meistens auch noch in die Encoding-Falle (außer der
NFS-Server ist wieder ein Mac). Denn der NFS-Client von MacOS X schreibt
ja AFAIK nach wie vor Dateinamen in UTF-8 decomposed auf den Server.
Womit schon Umlaute zum Problem werden können.
>> Es ist also genaugenommen nicht das Problem mit dem Mischbetrieb mit
>> Windows sondern rein, daß man den Zugriff vom Mac mittels Apples
>> CIFS-VFS-Modul realisiert.
>
> Wenn nur Macs (mit der gleichen Software, also z.B. dem systemeigenen
> Client) auf den SMB-Server zugreifen, dann hat man das Problem nicht -
> die sehen die einzelnen Dateien ja nicht.
Aber wenn *nur* Macs auf einen Server zugreifen, dann gibt es doch
überhaupt keinen Grund für SMB? Dann nimmt man AFP und fertig? Ah, so...
doch, wenn man nur einen Windows-Server hat und der keinen aktuellen
AFP-Server, dann ist das _eventuell_ eine Option.
Gruss,
Thomas
Goetz Hoffart
> > wie etwa die Netapp per iSCSI
> > rausreichen, an einem XServe o.ä. beziehen und das per AFP an die
> > Mac-Clients rausreichen.-)
>
> Hab' ich ja jetzt schon. VMware-Volume an virtuellen W2k3, allerdings
> mit dem veralteten SFM.
Veraltet ist gut. Das ist bald 10 Jahre alt, der Code. Und schon damals
war er nicht gerade State-of-the-Art.
> Hätte halt gern die Vorteile der CIFS auf der Netapp genutzt.
Die Vorteile haben ja mit CIFS nichts zu tun.
• Zentrales Backup: gibt's mit jedem zentralen Server
• Snapshots: kann Windows bspw. auch
• Fileversionen: kann ich nix zu sagen, mache zuwenig Windows
Dominik Schlütter
> Aber wenn *nur* Macs auf einen Server zugreifen, dann gibt es doch
> �berhaupt keinen Grund f�r SMB? Dann nimmt man AFP und fertig?
Nun ja, *ich* w�rde das auch so sehen. Aber es gibt halt - �hm - in den
entlegenen Gebieten unseres Globus durchaus noch ein paar Netzwerke (und
SMB-Installationen), bei denen ich nicht gefragt wurde :-P.
SCNR,
Dominik.
Ralph Böhme
> Verständlich. Ich war zweimal in Projekte involviert, bei denen NetApp-
> Filer und Macs involviert waren. Ging in sinnvoll eh nur mittels DAVE
> auf den Clients (weil dann Speicherung der Mac-Resourcen als ADS [1],
> d.h. _nicht_ als Dateischwesterchen, das daneben liegt und gerne mal
> verloren gehen kann).
Btw: einer der DAVE Entwickler ist seit einer Weile Apple Entwickler. Und
bei passender Samba Version und Konfig nutzt nun auch das Apple smb vfs
NTFS streams.
> Thomas, schon zweimal bei Kunden per Skripting Dateien, die per SMB und
> AFP auf Windows-Server gelandet sind, konsolidiert habend -- macht nur
> bedingt Spaß...
Mit `dot_clean` vom Mac aus je nach Situation evtl. etwas spaßiger.
--
s/-nsp// for mail
Christian Winther
[...]
> Hmm... dann würde ich aber wirklich mal einen Blick auf DAVE riskieren.
>
> <http://www.thursby.com/evaluations/dave.html>
>
Bei Gelegenheit mal testen. Dort wird aber, da ADS, ADmitMac empfohlen.
MfG CW
Christian Winther
[...]
>> Hätte halt gern die Vorteile der CIFS auf der Netapp genutzt.
>
> Die Vorteile haben ja mit CIFS nichts zu tun.
>
> • Zentrales Backup: gibt's mit jedem zentralen Server
> • Snapshots: kann Windows bspw. auch
> • Fileversionen: kann ich nix zu sagen, mache zuwenig Windows
Dir Vorteile bietet die Netapp, welche die CIFS anbietet:
- HA (Metrocluster)
- Versionen einer Datei vorhaltbar (1 Woche alt, 1 Tag alt, 2h alt, ...)
etc.
MfG CW
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> schrieb:
>> Verständlich. Ich war zweimal in Projekte involviert, bei denen
>> NetApp- Filer und Macs involviert waren. Ging in sinnvoll eh nur
>> mittels DAVE auf den Clients (weil dann Speicherung der Mac-Resourcen
>> als ADS [1], d.h. _nicht_ als Dateischwesterchen, das daneben liegt
>> und gerne mal verloren gehen kann).
>
> Btw: einer der DAVE Entwickler ist seit einer Weile Apple Entwickler. Und
> bei passender Samba Version und Konfig nutzt nun auch das Apple smb vfs
> NTFS streams.
Moment. Bzw. wovon schreibst Du? Samba (also CIFS-Server) in MacOS X
und/oder die Client-Komponente?
Falls (auch) Letzteres: Versucht das VFS-Modul dann einfach mal, "auf
blöd" auf einen File-Stream per SMB zuzugreifen und wenn das klappt,
dann wird einfach von "._"-Dateischwesterchen auf Speicherung des Krams
in drei Filestreams umgeschalten? So, wie in
<http://www.netkill.com/html/mac_ntfs.htm#NTFS_fork>
beschrieben? Hast' Du irgendeinen Link, der auf die Thematik verweist?
Gruss,
Thomas
Christian Winther
[...]
>
> Verständlich. Ich war zweimal in Projekte involviert, bei denen NetApp-
> Filer und Macs involviert waren. Ging in sinnvoll eh nur mittels DAVE
> auf den Clients (weil dann Speicherung der Mac-Resourcen als ADS [1],
> d.h. _nicht_ als Dateischwesterchen, das daneben liegt und gerne mal
> verloren gehen kann). Aber das war dermaßen lahm, daß in beiden
> Installationen NetApp als SAN genutzt werden mußte (also Einbindung als
> lokales Dateisystem auf 'nem Windows-Server, Erwerb von ExtremeZ-IP und
> dann Sharing des Dateisystems via AFP/SMB).
[...]
OK. Schaue mit DAVE/ADmitMac bei Gelegenheit an.
>
> Wenn man mal in der häßlichen Situation ist, hilft evtl. noch Marcel
> Bresinks Fork Server Helper... Äh, nö:
>
> <http://www.bresink.de/osx/ForkServerHelper-de.html>
Abgekündigt.
[...]
MfG CW
Ralph Böhme
> Ralph Böhme schrieb in <news:hfle2u$gih$1...@news.albasani.net>
>> Thomas Kaiser <Thomas...@phg-online.de> schrieb:
>>> Verständlich. Ich war zweimal in Projekte involviert, bei denen
>>> NetApp- Filer und Macs involviert waren. Ging in sinnvoll eh nur
>>> mittels DAVE auf den Clients (weil dann Speicherung der Mac-Resourcen
>>> als ADS [1], d.h. _nicht_ als Dateischwesterchen, das daneben liegt
>>> und gerne mal verloren gehen kann).
>>
>> Btw: einer der DAVE Entwickler ist seit einer Weile Apple Entwickler. Und
>> bei passender Samba Version und Konfig nutzt nun auch das Apple smb vfs
>> NTFS streams.
> Moment. Bzw. wovon schreibst Du? Samba (also CIFS-Server) in MacOS X
> und/oder die Client-Komponente?
Beides.
> Falls (auch) Letzteres: Versucht das VFS-Modul dann einfach mal, "auf
> blöd" auf einen File-Stream per SMB zuzugreifen und wenn das klappt,
Nein, nicht auf blöd, sondern u.a. je nachdem was der CIFS Server an
Optionen signalisiert und je nachdem wie der Client mountet etc.
> dann wird einfach von "._"-Dateischwesterchen auf Speicherung des Krams
> in drei Filestreams umgeschalten? So, wie in
> <http://www.netkill.com/html/mac_ntfs.htm#NTFS_fork>
> beschrieben? Hast' Du irgendeinen Link, der auf die Thematik verweist?
man mount_smbfs
man nsmb.conf
Für Google: ".com.apple.ntfsstreams.on"
http://www.samba.org/samba/docs/man/manpages-3/vfs_streams_xattr.8.html
Afair Situation bei den OS X Clients:
- seit 10.5 Unterstützung für NTFS Streams vorhanden, default ist aber off.
- seit 10.6 afair ist der default: wenn der CIFS Server Unterstützung für
NTFS Streams signalisiert, werden sie auch genutzt.
Afair Situation serverseitig:
- OS X Server mit Apple-gepatchtem smbd: afair seit 10.6 keine Spezial-Patches
mehr um Split-Forks hintenrum wieder richtig zu speichern, sondern gleich
auf Protokollebene Nutzung von NTFS Streams.
- Samba kann seit 3.2 NTFS Streams auf Protokollebene und speichert die
entweder in EAs des Dateisystems oder in einer tdb (*uargh!*)
Achtung: "NTFS Streams" bezeichnet auch das entsprechende Feature auf CIFS
Protokollebene.
Gruß Ralph
--
s/-nsp// for mail
Thomas Kaiser
> Für Google: ".com.apple.ntfsstreams.on"
Nur kurz dazu: Gefunden habe ich was ohne "ntfs" im Namen:
<http://groups.google.com/group/macenterprise/browse_thread/thread/f3ec0d0983e7769b>
Sieht jetzt auch nicht danach aus, als ob man das nutzen wolle...
Die Möglichkeit, das je Share ein-/auszuschalten, ist ja nett. Löst aber
auch nicht die Probleme, die man mit unterschiedlichen Client-Versionen
bekommt. Irgendwie schon ulkig, was für alberne Umstände abseits AFP
nötig sind, um Sachen zu erledigen, die woanders seit Jahrzehnten sinnig
im Protokoll stecken :-)
Gruss,
Thomas, den Rest in Ruhe goutierend und dann drauf zurückkommend... grad
bissi hektisch alles...
Ralph Böhme
> Ralph Böhme schrieb in <news:hfljcq$p06$1...@news.albasani.net>
>> Für Google: ".com.apple.ntfsstreams.on"
> Nur kurz dazu: Gefunden habe ich was ohne "ntfs" im Namen:
> <http://groups.google.com/group/macenterprise/browse_thread/thread/f3ec0d0983e7769b>
Hm.. copy/paste verunglückt. ".com.apple.smb.streams.on" ist in der Tat richtig.
> Die Möglichkeit, das je Share ein-/auszuschalten, ist ja nett. Löst aber
> auch nicht die Probleme, die man mit unterschiedlichen Client-Versionen
> bekommt. Irgendwie schon ulkig, was für alberne Umstände abseits AFP
> nötig sind, um Sachen zu erledigen, die woanders seit Jahrzehnten sinnig
> im Protokoll stecken :-)
Ach was! Samba kann bald Kaffee kochen und anschließend für dich aufs
Klo gehen. Und wenn die Jungs keiner aufhält wird Samba 5 wahrscheinlich
auch die Energieprobleme der Menschheit lösen. Da kann AFP einpacken! ;)