Netatalk: Brief der »Entwicklergemeinde« & Verschluß

[Goetz Hoffart]

Hallo,

<http://www.netafp.com/open-letter-to-the-netatalk-community-501/>

Man beschwert sich, dass niemand mithilft und OEMs nicht teilhaben.
Darum wird ab der aktuellen Beta wohl erstmal verschlossen, ein
»Pricing«-Menüpunkt eingeführt.

TBD.

xp & fup

Grüße
Götz

[Nils Hott]

Post by Goetz Hoffart
Man beschwert sich, dass niemand mithilft und OEMs nicht teilhaben.
Darum wird ab der aktuellen Beta wohl erstmal verschlossen, ein
»Pricing«-Menüpunkt eingeführt.

Finde ich gut. Dadurch wird hoffentlich einigen Nutznießern klar, dass
solche Projekte auch einschlafen können, wenn sich niemand beteiligt.

Gruß, Nils

[Goetz Hoffart]

Dadurch wird hoffentlich einigen Nutznießern klar, dass solche Projekte
auch einschlafen können, wenn sich niemand beteiligt.

Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen? Sobald ein Binary rausgeht, muss der Source
mitkommen, und der darf beliebig veröffentlicht werden.

Bis Netatalk 1.5.x war es ja noch BSD-Code, da gehen solche Späße ja, da
völlig frei. Oder übersehe ich eine GPL-Regelung?

Grüße
Götz

[Nils Hott]

Post by Goetz Hoffart
Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen? Sobald ein Binary rausgeht, muss der Source
mitkommen, und der darf beliebig veröffentlicht werden.

Guter Punkt, ich hatte das noch als BSD im Hinterkopf gespeichert. Keine
Ahnung, wie das rechtlich aussieht, aber moralisch kann ich die Jungs
verstehen.

(Ich gehöre allerdings auch nicht zu den Entwicklern, die ihren Code
verschenken, sondern arbeite für Geld. Vielleicht ändert das die
Sichtweise.)

Grüße, Nils

[Hermann Schaefer]

Post by Goetz Hoffart
Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen? Sobald ein Binary rausgeht, muss der Source
mitkommen, und der darf beliebig veröffentlicht werden.

Wer das Urheberrecht hat, kann jederzeit aus einen Open ein Closed Source
Projekt machen, Neuerungen müßten dann geforkt werden. Wenn die Jungs keine
Binaries offen zugänglich machen (sf), dann friert netatalk wieder mal ein. Wäre
ja nicht das erste Mal..
Tja, was soll man da sagen? Hoffen, daß Apple ihren SMB-Client zügig ausbaut?
Oder NFS? AFP ist ohne Server von Apple sowieso eigentlich keine Option mehr -
und ohne netatalk kann man AFP bald ganz vergessen, dann iclouden die Macs halt
irgendwie durch die Landschaft..

traurig.

[Ingo Keck]

Post by Hermann Schaefer

Post by Goetz Hoffart
Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen? Sobald ein Binary rausgeht, muss der Source
mitkommen, und der darf beliebig veröffentlicht werden.

Wer das Urheberrecht hat, kann jederzeit aus einen Open ein Closed Source
Projekt machen, Neuerungen müßten dann geforkt werden.

Du musst aber das Urheberrecht an allen Bestandteilen haben, d.h. du
darfst keinen Code nehmen, der von anderen zu GPL-Zeiten zugetragen
wurde, ausser dieser Code fällt nicht unters Urheberrecht, da keine
ausreichende Schaffenshöhe.

Ingo.

[Hermann Schaefer]

Post by Ingo Keck
Du musst aber das Urheberrecht an allen Bestandteilen haben, d.h. du
darfst keinen Code nehmen, der von anderen zu GPL-Zeiten zugetragen
wurde, ausser dieser Code fällt nicht unters Urheberrecht, da keine
ausreichende Schaffenshöhe.

Die Anzahl an Entwicklern ist bei netatalk ziemlich überschaubar..

[Dirk Kring]

Post by Hermann Schaefer

Post by Goetz Hoffart
Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen? Sobald ein Binary rausgeht, muss der Source
mitkommen, und der darf beliebig veröffentlicht werden.

Tja, was soll man da sagen? Hoffen, daß Apple ihren SMB-Client zügig ausbaut?
Oder NFS? AFP ist ohne Server von Apple sowieso eigentlich keine Option mehr -

Wie sind eigentlich die Erfahrungen mit ExtremeZ-IP?

MacServerIP ist ja wohl tot und nur bis 10.5 zu gebrauchen.

[Alexander Barton]

Post by Dirk Kring

Post by Hermann Schaefer
Tja, was soll man da sagen? Hoffen, daß Apple ihren SMB-Client zügig ausbaut?
Oder NFS? AFP ist ohne Server von Apple sowieso eigentlich keine Option mehr -

Wie sind eigentlich die Erfahrungen mit ExtremeZ-IP?

Durchweg sehr gut.

Viele Grüße
Alex

[Hannes Gnad]

Hermann Schaefer <***@zeitkind.de> wrote:

Hallo.

Post by Hermann Schaefer
Tja, was soll man da sagen? Hoffen, daß Apple ihren SMB-Client zügig ausbaut?

Ansonsten gibt es ja DAVE und ADmitMac.

Post by Hermann Schaefer
Oder NFS? AFP ist ohne Server von Apple sowieso eigentlich keine Option mehr -

Mal schauen, was da noch kommen wird. Einerseits erlaubt Lion
wohl bald mehr Virtualisierung (Lion Server in der VM auf Hard-
ware nach Wunsch), andererseits wird gemunkelt, der nächste
Mac Pro könnte besser in ein 19" passen.

[Hermann Schaefer]

Post by Hannes Gnad
Einerseits erlaubt Lion
wohl bald mehr Virtualisierung (Lion Server in der VM auf Hard-
ware nach Wunsch)

Quelle??

Post by Hannes Gnad
andererseits wird gemunkelt, der nächste
Mac Pro könnte besser in ein 19" passen.

"Besser passen" ist ja wohl eher ein Witz. Allein die Desktop-GPU da drin ist
sowas von daneben, daß man lachen müßte - wäre es nicht so zum heulen. Entweder
ist in einem Server nicht nur ein Babberl drauf sondern auch entsprechende
Hardware verbaut, oder Apple sollte es einfach lassen. Mit dem Krempel machen
die sich doch gerade lächerlich. Erinnert an die WGS von vor 20 Jahren, aber
damals gab es auch andere Anforderungen.

[Nils Hott]

Erinnert an die WGS von vor 20 Jahren, aber damals gab es auch andere
Anforderungen.

Mitnichten, die Anforderungen an einen "typischen" Apple-Server sind
damals wie heute die gleichen: Muss das gleiche OS haben wie die Clients
und von den gleichen Leuten administriert werden können. Und schick
aussehen im Büro.

Gruß, Nils (der auch mal einen Xserve hatte)

[Hermann Schaefer]

Post by Nils Hott

Erinnert an die WGS von vor 20 Jahren, aber damals gab es auch andere
Anforderungen.

Mitnichten, die Anforderungen an einen "typischen" Apple-Server sind
damals wie heute die gleichen: Muss das gleiche OS haben wie die Clients
und von den gleichen Leuten administriert werden können. Und schick
aussehen im Büro.

Heute sind Server in Serverräumen untergebracht, allein das Gesurre der
RAID-Systeme ist sonst nicht zu ertragen. Und man denkt heute auch an so
Kleinigkeiten wie "Green IT". Eine Desktop GPU verbrät ja bald mehr Saft im
Leerlauf, als ein alter Server insgesamt.. usw. usf.

Ich rede hier auch nicht von dem Kleinstbetrieb, der schon einen Mac Mini
"Server" nicht mal ansatzweise auslastet. Jeder kleine Mittelständler hat heute
eine IT, deren Ausmaß früher dem einer Uni entsprach. Es gibt praktisch keine
Arbeitsplätze mehr ohne IT-Anbindung, auch Produktionsarbeitsplätze werden
zunehmend vernetzt.

[Goetz Hoffart]

Post by Hermann Schaefer
Heute sind Server in Serverräumen untergebracht, allein das Gesurre der
RAID-Systeme ist sonst nicht zu ertragen.

Kommt auf die Zielgruppe an. Es gibt viele Zielgruppen, denen ein
Zweiplatten-RAID1 an einem Mac mini (von der Leistung her) dicke reicht.
Für vier-fünf Texter braucht es nicht mehr.

Und auch früher gab es für solche Anforderungen eine Netware 3-Kiste in
der Ecke, oder später ein Windows NT.

IT wird nicht per se professioneller oder besser, nur weil die Technik
in einen gekühlten 19"-Schrank gesteckt wird.

Grüße
Götz

[Hermann Schaefer]

Post by Goetz Hoffart

Post by Hermann Schaefer
Heute sind Server in Serverräumen untergebracht, allein das Gesurre der
RAID-Systeme ist sonst nicht zu ertragen.

Kommt auf die Zielgruppe an. Es gibt viele Zielgruppen, denen ein
Zweiplatten-RAID1 an einem Mac mini (von der Leistung her) dicke reicht.
Für vier-fünf Texter braucht es nicht mehr.

Die brauchen aber auch keinen Xserve - und um dessen Absenz ging es ja. Sehr
wohl aber eben Firmen mit mehr Angestellten, und die hat Apple inzwischen wohl
vergessen. Und so sehr das einen "alten Macianer" dann auch ärgert, dann kommt
halt 'ne Windowskiste oder ein NetApp etc. in den Schrank. Und dann wird beim
nächsten Hardwareupgrade der Clients 3x überlegt, ob es wieder Apple wird. Soooo
schlecht ist Windows 7 auch nicht, und bei einigen täte es sicher auch ein Ubuntu.

[Daniel Krebs]

Post by Hermann Schaefer

Post by Goetz Hoffart

Post by Hermann Schaefer
Heute sind Server in Serverräumen untergebracht, allein das Gesurre der
RAID-Systeme ist sonst nicht zu ertragen.

Kommt auf die Zielgruppe an. Es gibt viele Zielgruppen, denen ein
Zweiplatten-RAID1 an einem Mac mini (von der Leistung her) dicke reicht.
Für vier-fünf Texter braucht es nicht mehr.

Die brauchen aber auch keinen Xserve - und um dessen Absenz ging es ja.
Sehr wohl aber eben Firmen mit mehr Angestellten, und die hat Apple
inzwischen wohl vergessen. Und so sehr das einen "alten Macianer" dann
auch ärgert, dann kommt halt 'ne Windowskiste oder ein NetApp etc. in den
Schrank. Und dann wird beim nächsten Hardwareupgrade der Clients 3x
überlegt, ob es wieder Apple wird. Soooo schlecht ist Windows 7 auch
nicht, und bei einigen täte es sicher auch ein Ubuntu.

Es geht ja nicht nur um Apples "Server".
Ich werde den Eindruck nicht los, dass Apple gar kein Interesse daran
hat, seine Produkte im professionellen Umfeld einsetzen zu lassen.
Einige Beispiele:
- Der Windows 7 Treiber für den NIC des vorletzten Mac Mini funktioniert
nicht. Kunde ist gezwungen, WLAN oder USB Adapter zu nutzen. Apple hilft
nicht. (Ob es beim aktuellen Mini wieder so ist, weiß ich noch nicht,
befürchte es aber.)
- Man kann kein Windows per PXE boot auf den vorletzten Minis ausrollen.
- Der Checkpoint IPsec Client für MacOS funktioniert nicht über UMTS.
- Der NX Client von NoMachine will noch immer Rosetta.
Wer verlängert die Liste?

Ja, nicht wundern, der Mini ist ein echter Stromspar- PC. Deshalb nehmen
wir ihn auch für Windows.
BTW: Wie gut funktioniert die DFS- Unterstützung bei Lion? Ich habe noch
keinen Löwen.
Daniel

[Dennis Grevenstein]

Post by Daniel Krebs
Ja, nicht wundern, der Mini ist ein echter Stromspar- PC. Deshalb nehmen
wir ihn auch für Windows.

Um also ein paar EURO Strom zu sparen, kauft Ihr ein Geraet,
dass vom Hersteller nicht mit vollstaendiger Windowsunterstuetzung
ausgeliefert wird? Gibt es da nichts von Dell, das billiger ist und
Windows gleich drauf hat?

Also es gibt ja schon Dinge, die mich an Apple oder der Mac-
Plattform stoeren, aber mangelnde Windowsunterstuetzung
gehoert wirklich nicht dazu.

gruss,
Dennis

[Daniel Krebs]

Post by Dennis Grevenstein

Post by Daniel Krebs
Ja, nicht wundern, der Mini ist ein echter Stromspar- PC. Deshalb nehmen
wir ihn auch für Windows.

Um also ein paar EURO Strom zu sparen, kauft Ihr ein Geraet,
dass vom Hersteller nicht mit vollstaendiger Windowsunterstuetzung
ausgeliefert wird? Gibt es da nichts von Dell, das billiger ist und
Windows gleich drauf hat?
Also es gibt ja schon Dinge, die mich an Apple oder der Mac-
Plattform stoeren, aber mangelnde Windowsunterstuetzung
gehoert wirklich nicht dazu.

Du hast ja nicht unrecht. Wir haben Kisten (eher Kästchen, auch von
Dell) durchgemessen, die nicht nur Atom oder ARM drin haben und uns für
den Mac Mini entschieden. Sowas machen wir nicht jedes Jahr.
Vor zwei Jahren hat halt der Mini von Apple gewonnen.
Dass dessen Nachfolgemodell keine anständige Windows- Treiber hatte,
konnten wir nicht ahnen.
Womöglich sollten wir in Zukunft sämtliche Apple- Produkte von diesen
Tests ausschließen...
Man weiß ja nie.
BTW paar Euro: Du bist vielleicht ein kleines Licht. Die Masse macht es.
Daniel

[Dennis Grevenstein]

Post by Daniel Krebs
BTW paar Euro: Du bist vielleicht ein kleines Licht. Die Masse macht es.

Wenn Du 10000 minis gekauft hast, um nachher festzustellen,
dass was nicht geht, dann wundere ich mich eher noch mehr
als wenn es nur zwei Stueck waren.

gruss,
Dennis

[Thomas Kaiser]

Post by Daniel Krebs
BTW paar Euro: Du bist vielleicht ein kleines Licht. Die Masse macht es.

Wenn Du 10000 minis gekauft hast, um nachher festzustellen, dass was
nicht geht, dann wundere ich mich eher noch mehr als wenn es nur zwei
Stueck waren.

Naja, "nachher" war wohl nach Shopping-Zeitpunkt? Wie soll man bei Kauf
feststellen, daß Apple funktionierende NIC-Treiber für Windows 7 später
Latte sein werden?

Wobei mich ja die finanziellen Konditionen durchaus interessieren
würden. Spiel grad ein "Wolf im Schafspelz"-Szenarium durch, d.h. in
ein 1HE-19-Zoll-Gehäuse 4 Mini Server und einen 5-Port-GBit-Switch zu
stopfen und damit Racks vollzuklatschen. Auf ein 42-HE-Rack kämen 4
Switches mit 10 GBit-Uplink und demnach noch 38 HE à 4 Minis, d.h. 608
i7-CPU-Cores à 2 Ghz, ca. 1,2 PByte RAM und ca. 38 PByte SSD-Storage je
Schrank. Lustig. Aber leider ist die Aufgabenstellung völlig gaga :-)

Gruss,

Thomas

[Daniel Krebs]

Dennis Grevenstein schrieb in

Post by Daniel Krebs
BTW paar Euro: Du bist vielleicht ein kleines Licht. Die Masse macht es.

Wenn Du 10000 minis gekauft hast, um nachher festzustellen, dass was
nicht geht, dann wundere ich mich eher noch mehr als wenn es nur zwei
Stueck waren.

Naja, "nachher" war wohl nach Shopping-Zeitpunkt?

Na sicher. Schrub ich ja.
Aber wie soll man das einem Dennis erklären?
Daniel

[Dirk Kring]

Post by Daniel Krebs
BTW: Wie gut funktioniert die DFS- Unterstützung bei Lion? Ich habe noch
keinen Löwen.

DFS scheint nun zu funktionieren, jedenfalls bei uns. Bis einschließlich
10.6 mußten wir statt DFS zu nutzen die Server direkt anwählen.
Habe allerdings noch keinen richtigen Test gemacht, war nur ein
Ereichbarkeits- und Lesetest.

Aber AFP geht nur noch mit ExptremeZ-IP, nicht mehr mit MacServerIP.

[Daniel Krebs]

Post by Dirk Kring

Post by Daniel Krebs
BTW: Wie gut funktioniert die DFS- Unterstützung bei Lion? Ich habe noch
keinen Löwen.

DFS scheint nun zu funktionieren, jedenfalls bei uns. Bis einschließlich
10.6 mußten wir statt DFS zu nutzen die Server direkt anwählen.
Habe allerdings noch keinen richtigen Test gemacht, war nur ein
Ereichbarkeits- und Lesetest.

Danke!
Das ist doch schonmal was. Viele werden Dave jetzt nicht mehr benötigen.
Daniel

[Thomas Kaiser]

Post by Dirk Kring
Aber AFP geht nur noch mit ExptremeZ-IP, nicht mehr mit MacServerIP.

Nö, man muß 10.7 halt nur wieder DHCAST128 als Authentifizierungs-
Methode beibringen, siehe bspw.:

http://www.hilfdirselbst.ch/foren/gforum.cgi?post=476417#476417

Gruss,

Thomas

[Goetz Hoffart]

Post by Daniel Krebs
Ja, nicht wundern, der Mini ist ein echter Stromspar- PC. Deshalb nehmen
wir ihn auch für Windows.

Braucht er dort wirklich genauso wenig wie unter MOSX? Würde mich jetzt
wundern. Die Akkulaufzeit unter Win7 ist auf meinem MBP deutlich kürzer
als unter MOSX.

Grüße
Götz

[Daniel K®ebs]

Post by Goetz Hoffart
Braucht er dort wirklich genauso wenig wie unter MOSX?

Unsere Leute haben unter W 7 gemessen. Es war wirklich wenig. Die Zahlen
habe ich aber nicht im Kopf.
Gruss,
Daniel

[Daniel Krebs]

Post by Nils Hott

Erinnert an die WGS von vor 20 Jahren, aber damals gab es auch andere
Anforderungen.

Mitnichten, die Anforderungen an einen "typischen" Apple-Server sind
damals wie heute die gleichen: Muss das gleiche OS haben wie die Clients
und von den gleichen Leuten administriert werden können. Und schick
aussehen im Büro.
Gruß, Nils (der auch mal einen Xserve hatte)

Ich hatte mal einen WGS 8150. Schick war der nicht.
Daniel

[Thomas Kaiser]

Post by Goetz Hoffart

Dadurch wird hoffentlich einigen Nutznießern klar, dass solche
Projekte auch einschlafen können, wenn sich niemand beteiligt.

Gegenfrage: wie geht es, dass sie GPL (!) Software jetzt vorläufig
»schließen« wollen?

It's not a fork, it's a spoon! ;-)

Im Ernst: Ich find's gut und richtig. Die Jungs von netafp.com haben de
facto die letzten Jahre alleinig die Hauptarbeit hinter Netatalk
geleistet. Und das *richtig*, d.h. nicht wie in früheren Zeiten, als
sich jeder Admin einer Mac-Herde noch in Netatalk zur persönlichen
Bespaßung Features hineingepatcht hat, die dann Netatalk instabil werden
ließen und die Specs verletzt haben (selbstverständlich wanderte all der
Quatsch per CVS in die allgemeine Version).

Als wir anno 2003/2004 noch in einem etwas größeren Kreis Netatalk 2.0
an den Start brachten, waren diese Auseinandersetzungen um Code-Qualität
und Spezifikationstreue, die man sich mit "Hinz und Kunz", die auch
gerne ihre Code-Brocken ins Repository werfen wollten, dermaßen mühsam
und zeitaufreibend, daß ich mir solche Zustände wirklich nicht mehr
zurücksehne.

Seit den netafp.com-Contributions bewegt sich Netatalk in genau die
richtige Richtung. Qualitäts-Code und die richtigen Features. Und das
soll auch so bleiben. Mal schauen, ob's die diversen Netatalk-"OEMs"
kapieren werden und die Entwicklung endlich auch mal angemessen
unterstützen... geht bei Samba ja auch, daß die Nutznießer der Software
kapieren, daß die Entwickler auch von irgendwas leben müssen.

Gruss,

Thomas

[Robert]

Prima, damit bleibt FreeNAS dann auch Lion kompatibel (war meine grösste
Sorge):

Update:

Update (July-23-2011):
Thanks to the new commitment of Data Robotics, Western Digital
Corporation and QNAP, there's hope! Also, we're reopening development,
pushing all sources to the official Netatalk git VCS at Sourceforge. We
expect Netatalk 2.2.0 sourcecode tarballs to be available at the
Sourceforge download site soon.



http://www.netafp.com/open-letter-to-the-netatalk-community-501/

[Thomas Kaiser]

Post by Robert
Prima, damit bleibt FreeNAS dann auch Lion kompatibel (war meine grösste

Dann solltest Du mal bei netafp.com anklopfen und fragen, wie Du das
Projekt unterstützen kannst. Aber vielleicht hast Du das ja schon getan?

Post by Robert
Thanks to the new commitment of Data Robotics, Western Digital
Corporation and QNAP, there's hope! Also, we're reopening development,
pushing all sources to the official Netatalk git VCS at Sourceforge. We
expect Netatalk 2.2.0 sourcecode tarballs to be available at the
Sourceforge download site soon.
http://www.netafp.com/open-letter-to-the-netatalk-community-501/

Yep, und jetzt wird's spannend, ob die NAS-Hersteller wirklich kapiert
haben, worum's geht oder einfach nur mal "aus der Not heraus" einen
Obulus entrichtet haben, der einmalig war.

Dito ob bspw. Synology, die vorher ein hoffnungslos veraltetes Netatalk
2.0.1 "pflegten" und in ihrer neuen Beta-Firmware ein buggy Netatalk
2.2-beta-4 einsetzen, dann überhaupt auf die finale 2.2.0 umsteigen
werden (in der noch massig Zeugs gefixt wurde, siehe [1]). Zahlen tun
sie jedenfalls mal nichts laut Auskunft der netafp.com-Jungs.

Das ist halt der Knackpunkt: Netatalk war ein Spiel- und Spaßprojekt
bzw. der Sandkasten von paar Admins, die programmieren konnten, vor
Version 2.0 -- zudem an einigen Stellen auf die Spezifikationen pfeifend
bzw. absichtlich verletzend. Mit 2.0 wurden dann erhebliche
Anstrengungen seitens ein paar Personen unternommen, das Ganze besser
aufzuziehen, die Specs einzuhalten, aktuelle nötige Features einzubauen
und mal eine Doku zusammenzunageln, die halbwegs vollständig war. Immer
noch weit von Perfektion entfernt.

Das war 2004... und danach passierte fast nix mehr, bis sich netafp.com
der Sache annahm. Ca. 95% der Contributions der letzten 2 Jahre kommen
aus der Ecke. Und ohne die wäre Netatalk das, was es zwischen 2005 und
2009 war: Ein totes Projekt, das zudem nicht mehr mit aktuellen MacOS X
Releases funktionieren würde.

Wenn die NAS-Hersteller diese Ausgangslage nicht raffen und verstehen,
daß ein kleiner Obulus ihrerseits nicht nur dafür sorgt, daß sie
kompetenten Netatalk-Support erhalten und damit auch Richtung Kunden
leisten können, sondern daß dieser Obulus letztlich dafür sorgt, daß
Netatal überhaupt weiterentwickelt wird... ja, dann wird das Projekt auf
kurz oder lang wieder einschlafen. Einfach weil man "OpenSource machen"
sich auch erst mal leisten können muß...

Gruss,

Thomas

[1] <http://Netatalk.Sourceforge.Net/2.2/ReleaseNotes2.2.0.html>

[Andreas Berger]

Post by Thomas Kaiser
Wenn die NAS-Hersteller diese Ausgangslage nicht raffen und verstehen,
daß ein kleiner Obulus ihrerseits nicht nur dafür sorgt, daß sie
kompetenten Netatalk-Support erhalten und damit auch Richtung Kunden
leisten können, sondern daß dieser Obulus letztlich dafür sorgt, daß
Netatal überhaupt weiterentwickelt wird... ja, dann wird das Projekt auf
kurz oder lang wieder einschlafen. Einfach weil man "OpenSource machen"
sich auch erst mal leisten können muß...

Das ist eine Scheiß-Situation, und noch schlimmer, das jetzt aus dem
Wintellager und vor allem aus Entscheiderkreisen, die nichts falsch
machen wollen, komplett auf Windows Server "geswitched" wird um ein
homogenes Umfeld zu haben.
Die machen halt nicht soviel "Ärger" wie Linuxkisten und die
Wintel-Clienten laufen sofort dran. Ein paar exotische Apples greifen
eben dann über SMB zu.

[Daniel Krebs]

Post by Andreas Berger

Post by Thomas Kaiser
Wenn die NAS-Hersteller diese Ausgangslage nicht raffen und verstehen,
daß ein kleiner Obulus ihrerseits nicht nur dafür sorgt, daß sie
kompetenten Netatalk-Support erhalten und damit auch Richtung Kunden
leisten können, sondern daß dieser Obulus letztlich dafür sorgt, daß
Netatal überhaupt weiterentwickelt wird... ja, dann wird das Projekt auf
kurz oder lang wieder einschlafen. Einfach weil man "OpenSource machen"
sich auch erst mal leisten können muß...

Das ist eine Scheiß-Situation, und noch schlimmer, das jetzt aus dem
Wintellager und vor allem aus Entscheiderkreisen, die nichts falsch
machen wollen, komplett auf Windows Server "geswitched" wird um ein
homogenes Umfeld zu haben.
Die machen halt nicht soviel "Ärger" wie Linuxkisten und die
Wintel-Clienten laufen sofort dran. Ein paar exotische Apples greifen
eben dann über SMB zu.

Und wie machen die TM?
Darum geht es doch.
Apple ist lieder kein Nieschenprodukt mehr.
Daniel

[Joern Bredereck]

Post by Daniel Krebs

Post by Andreas Berger
Das ist eine Scheiß-Situation, und noch schlimmer, das jetzt aus dem
Wintellager und vor allem aus Entscheiderkreisen, die nichts falsch
machen wollen, komplett auf Windows Server "geswitched" wird um ein
homogenes Umfeld zu haben.
Die machen halt nicht soviel "Ärger" wie Linuxkisten und die
Wintel-Clienten laufen sofort dran. Ein paar exotische Apples greifen
eben dann über SMB zu.

Und wie machen die TM?

für TM muss man nicht unbedingt AFP nehmen. Nach meiner Erfahrung klappt
es mit iSCSI sowieso problemloser und performanter. Außerdem ist man bei
iSCSI eben nicht von einer einzigen Implementierung (netatalk) abhängig.
iSCSI ist ein Industriestandard während AFP ein propritäres Protokoll
von Apple ist.

VG,

Jörn

[Patrick M. Hausen]

Hallo,

Post by Joern Bredereck
für TM muss man nicht unbedingt AFP nehmen. Nach meiner Erfahrung klappt
es mit iSCSI sowieso problemloser und performanter. Außerdem ist man bei
iSCSI eben nicht von einer einzigen Implementierung (netatalk) abhängig.
iSCSI ist ein Industriestandard während AFP ein propritäres Protokoll
von Apple ist.

Und mit iSCSI hat man zwar auf der Target-Seite reichlich Auswahl,
ist aber auf einen kostenlosen oder zumindest erschwinglichen
Initiator fÃ?r Mac OS X angewiesen. Pick your poison ;-)

Gruß,
Patrick

[Daniel K®ebs]

Post by Goetz Hoffart
Hallo,

Post by Joern Bredereck
für TM muss man nicht unbedingt AFP nehmen. Nach meiner Erfahrung klappt
es mit iSCSI sowieso problemloser und performanter. Außerdem ist man bei
iSCSI eben nicht von einer einzigen Implementierung (netatalk) abhängig.
iSCSI ist ein Industriestandard während AFP ein propritäres Protokoll
von Apple ist.

Und mit iSCSI hat man zwar auf der Target-Seite reichlich Auswahl,
ist aber auf einen kostenlosen oder zumindest erschwinglichen
Initiator fÃ?r Mac OS X angewiesen. Pick your poison ;-)

Im SOHO Bereich sollte iSCSI eh nicht oft anzutreffen sein, wohl aber
kleine NAS Geräte, die für TM genutzt werden sollen.
Daniel

[Andreas Berger]

Post by Daniel K®ebs

Post by Patrick M. Hausen
Und mit iSCSI hat man zwar auf der Target-Seite reichlich Auswahl,
ist aber auf einen kostenlosen oder zumindest erschwinglichen
Initiator fÃ?r Mac OS X angewiesen. Pick your poison ;-)

Was spricht gegen:
<http://www.snsftp.com/public/globalsan/>?

Post by Daniel K®ebs
Im SOHO Bereich sollte iSCSI eh nicht oft anzutreffen sein, wohl aber
kleine NAS Geräte, die für TM genutzt werden sollen.

Selbst kostenlose Software wie freeNAS oder der community-Ableger
<http://www.nexentastor.org/> bietet iSCSI

[Daniel Krebs]

Post by Andreas Berger

Post by Daniel K®ebs

Post by Patrick M. Hausen
Und mit iSCSI hat man zwar auf der Target-Seite reichlich Auswahl,
ist aber auf einen kostenlosen oder zumindest erschwinglichen
Initiator fÃ?r Mac OS X angewiesen. Pick your poison ;-)

<http://www.snsftp.com/public/globalsan/>?

Post by Daniel K®ebs
Im SOHO Bereich sollte iSCSI eh nicht oft anzutreffen sein, wohl aber
kleine NAS Geräte, die für TM genutzt werden sollen.

Selbst kostenlose Software wie freeNAS oder der community-Ableger
<http://www.nexentastor.org/> bietet iSCSI

Glaubst Du wirklich, ein normaler SoHo Kunde baut sich noch ein zweites
LAN auf, um iSCSI betreiben zu können?
Der Aufwand ist doch meist viel zu hoch.
Daniel

[Patrick M. Hausen]

Hallo,

Post by Daniel Krebs
Glaubst Du wirklich, ein normaler SoHo Kunde baut sich noch ein zweites
LAN auf, um iSCSI betreiben zu können?

Wozu braucht man ein separates LAN? Das braucht man in Firmen nur,
damit man Performance-Garantien abgeben kann, aber bei einer
Handvoll von Kisten im Hausnetz ...

1 Router, 16 Mbit DSL-Uplink
1 iSCSI-Target
1 Mac
1 Airport Express
1 iPad oder Macbook

Kannst Du mir verraten, wie es da bei einer nicht total willenlosen
Verkabelung irgendwo zum Engpass kommen soll?

Gruß,
Patrick

[Daniel K®ebs]

Post by Goetz Hoffart
Hallo,

Post by Daniel Krebs
Glaubst Du wirklich, ein normaler SoHo Kunde baut sich noch ein zweites
LAN auf, um iSCSI betreiben zu können?

Wozu braucht man ein separates LAN? Das braucht man in Firmen nur,
damit man Performance-Garantien abgeben kann, aber bei einer
Handvoll von Kisten im Hausnetz ...
1 Router, 16 Mbit DSL-Uplink
1 iSCSI-Target
1 Mac
1 Airport Express
1 iPad oder Macbook
Kannst Du mir verraten, wie es da bei einer nicht total willenlosen
Verkabelung irgendwo zum Engpass kommen soll?

Wurde doch hier schon oft genug diskutiert.
Ich zitiere mal aus:
<http://www.thomas-krenn.com/de/wiki/Leitfaden_Storage_Konnektivität_iSC
SI_SAS_FC>

"Bei der Einrichtung des Netzwerkes ist darauf zu achten, dass die Wahl
auf ein dediziertes Storage-Netzwerk fällt. Ein dediziertes Storage
Netzwerk sollte hinsichtlich Sicherheit, Performance und Administration
gewählt werden. Entscheidet man sich für ein gemischtes LAN, so ist das
Risiko einer Sabotage oder Hardwareausfalls größer, auch können ggf.
Probleme sehr schwierig analysiert und behoben werden. Durch eine
strikte Trennung von LAN und SAN eliminiert man potenzielle Störquellen,
die sich einerseits negativ auf den SAN-Betrieb als auch auf den
LAN-Betrieb auswirken können. "

Wenn es bei Dir zufällig problemlos im Mischbetrieb laufen sollte, hast
Du einfach nur Glück.
Daniel

[Joern Bredereck]

Post by Daniel K®ebs

Post by Patrick M. Hausen
1 Router, 16 Mbit DSL-Uplink
1 iSCSI-Target
1 Mac
1 Airport Express
1 iPad oder Macbook
Kannst Du mir verraten, wie es da bei einer nicht total willenlosen
Verkabelung irgendwo zum Engpass kommen soll?

Wurde doch hier schon oft genug diskutiert.

Anscheinend nicht oft genug, denn da scheint es noch Nachholbedarf zu geben.

Post by Daniel K®ebs
<http://www.thomas-krenn.com/de/wiki/Leitfaden_Storage_Konnektivität_iSC
SI_SAS_FC>
"Bei der Einrichtung des Netzwerkes ist darauf zu achten, dass die Wahl
auf ein dediziertes Storage-Netzwerk fällt. Ein dediziertes Storage
Netzwerk sollte hinsichtlich Sicherheit, Performance und Administration
gewählt werden. Entscheidet man sich für ein gemischtes LAN, so ist das
Risiko einer Sabotage oder Hardwareausfalls größer, auch können ggf.
Probleme sehr schwierig analysiert und behoben werden. Durch eine
strikte Trennung von LAN und SAN eliminiert man potenzielle Störquellen,
die sich einerseits negativ auf den SAN-Betrieb als auch auf den
LAN-Betrieb auswirken können. "

Dieser "Leitfaden" hat mit dem Anwendungsfall "Time-Machine-Backup"
nichts zu tun. Es geht nicht darum, ein Storage-Netzwerk aufzubauen, um
z.B. Festplatten-Stapel performant und hochverfügbar an Fileserver
anzubinden oder um VmWare-Images einzubinden, sondern es geht darum dass
eine Workstation per Timemachine alle paar Stunden ihr Datendelta
wegschreibt. In ersterem Fall will man natürlich ein separates Netz
haben, da es hier auf Latenz und Hochverfügbarkeit ankommt. Ich würde
sogar so weit gehen, dass man im Server-Bereich iSCSI grundsätzlich mit
Multipathing betreiben will (d.h. über zwei separate physikalische Links
im Failover-Modus, sodass die Verbindung bestehen bleibt, wenn eines der
beiden Storage-Netze ausfällt).

Für ein Time-Machine-Backup kann ich hingegen sehr gut damit leben, wenn
der iSCSI-Link mal ein paar Minuten weg ist, oder wenn die Perfomance
mal etwas einbricht, weil über das LAN gerade grössere Datenmengen
verschoben werden. Im Zweifelsfall dauert das Backup halt etwas länger
oder muss verschoben werden, bis das iSCSI-Target wieder zur Verfügung
steht.

Post by Daniel K®ebs
Wenn es bei Dir zufällig problemlos im Mischbetrieb laufen sollte, hast
Du einfach nur Glück.

Nein, das hat mit Glück nichts zu tun. iSCSI ist ein simples
TCP-basiertes Protokoll, dass über jede beliebige IP-Verbindung genutzt
werden kann. Je nach Anwendungsfall sogar über einen WAN-Verbindung ins
Internet. Das "i" in iSCSI steht überigens für "Internet".

VG,

Jörn

[Patrick M. Hausen]

Hi!

Post by Andreas Berger
<http://www.snsftp.com/public/globalsan/>?

Die Frage, ob es das in 5 Jahren noch gibt, und es
dann mit der dann aktuellen Mac-OS-X-Version noch funktioniert.

Gruß,
Patrick

[Andreas Berger]

Post by Patrick M. Hausen

Post by Andreas Berger
<http://www.snsftp.com/public/globalsan/>?

Die Frage, ob es das in 5 Jahren noch gibt, und es
dann mit der dann aktuellen Mac-OS-X-Version noch funktioniert.

Das ist für Privat doch eh Pille/Palle. Da dient das Backup eher zur
Versionierung als zum Crashrecovery neben einem initialen Abzug per CCC,
TM oder Festplattendienstprogramm auf eine USB/FW hd.

[Patrick M. Hausen]

Hallo,

Post by Andreas Berger

Post by Patrick M. Hausen

Post by Andreas Berger
<http://www.snsftp.com/public/globalsan/>?

Die Frage, ob es das in 5 Jahren noch gibt, und es
dann mit der dann aktuellen Mac-OS-X-Version noch funktioniert.

Das ist für Privat doch eh Pille/Palle. Da dient das Backup eher zur
Versionierung als zum Crashrecovery neben einem initialen Abzug per CCC,
TM oder Festplattendienstprogramm auf eine USB/FW hd.

Tut mir leid, aber das ist so pauschal Quatsch. Die 'zig
Gigabyte an Fotos und iTunes-Mediathek wwill ich wirklich nicht
verlieren.

Und mit Netatalk und ZFS auf dem FreeNAS bekomme ich das
Sparse-Image zur Not in 5 Jahren manuell auf eine USB/Thunderbolt-Platte
kopiert, die direkt am Mac angeschlossen, und die Daten da irgendwie
wieder raus ... sollte Apple AFP killen oder so modifizieren, dass
Netatalk nicht hinterher kommt, oder ...

Darum geht's mir. Ich will dauerhaft wieder an meine Daten kommen.
Deshalb: keine proprietäre Technik. Kein Hardware-RAID, nur Open Source
für alles, was lange aufbewahrt werden muss. Und ich rede hier vom
Rest meines Lebens ... 40-50 Jahre mit Glück. Klar, dass davon
maximal die nächsten 5 überschaubar sind. Aber bei dem zwar kostenlosen
aber nicht freien iSCSI-Initiator sind es eben nicht mal die.

Gruß,
Patrick

[Thomas Kaiser]

Post by Patrick M. Hausen

Post by Andreas Berger

Post by Andreas Berger
<http://www.snsftp.com/public/globalsan/>?

Die Frage, ob es das in 5 Jahren noch gibt, und es dann mit der
dann aktuellen Mac-OS-X-Version noch funktioniert.

Das ist für Privat doch eh Pille/Palle. Da dient das Backup eher zur
Versionierung als zum Crashrecovery neben einem initialen Abzug per
CCC, TM oder Festplattendienstprogramm auf eine USB/FW hd.

Tut mir leid, aber das ist so pauschal Quatsch. Die 'zig
Gigabyte an Fotos und iTunes-Mediathek wwill ich wirklich nicht
verlieren.

Und dann setzt Du auf TimeMachine, also einen Mechanismus, der
selbständig die ältesten Revisionen von Dokumenten entsorgt, wenn der
Platz zu knapp wird (auch klar, Daseinsberechtigung von TM lautet ja
Backup) und kein Archivierungssystem, was per Definition Sachen so lange
aufhebt wie Du willst?

Post by Patrick M. Hausen
Und mit Netatalk und ZFS auf dem FreeNAS bekomme ich das Sparse-Image

Das ist der nächste Punkt. Alle Versionen sind ja innerhalb des Sparse
Bundles. D.h. wenn das SparseBundle selbst malade wird, ist alles weg.
Für Backup verschmerzbar, für Archiv IMO untauglich. Vor allem braucht's
einen AFP-Server, der das AFP-Feature "Replay Cache" unterstützt (kam
erst mit AFP 3.3 [1], d.h. erst in Netatalk 2.2 enthalten), wenn das
Ganze wirklich robust sein soll. Daß Apple dieses Feature ab 10.7
obligatorisch macht und nicht mehr wie 10.6 oder Vorversionen "Vabanque-
Backup" unterstützt, halte ich für begrüßenswert. Eine Unterbrechung der
Netzwerk-Verbindung und das schöne SparseBundle ist im Eimer...

Gruss,

Thomas

[1] http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/AFPVersionDifferences/AFPVersionDifferences.html

[Patrick M. Hausen]

Hi!

Post by Thomas Kaiser
Und dann setzt Du auf TimeMachine, also einen Mechanismus, der
selbständig die ältesten Revisionen von Dokumenten entsorgt, wenn der
Platz zu knapp wird (auch klar, Daseinsberechtigung von TM lautet ja
Backup) und kein Archivierungssystem, was per Definition Sachen so lange
aufhebt wie Du willst?

Archiv habe ich separat, aber auch auf FreeNAS/ZFS und nicht auf
proprietärem Kram.

Was die Netatalk-Version angeht: FreeNAS 8.0.1 beta 4 ist endlich
benutzbar - kann zu den vorangegangenen Betas nichts sagen, aber
8.0 war für AFP unbrauchbar. Early adopters komplettes Redesign,
eben.

Und laut Roadmap soll statt Netatalk 2.1.5 in die 8.0.1 final
2.2.2 rein.

Sieht also ganz gut aus ...

Ich gebe zu: ich könnte nur für das Backup durchaus iSCSI nehmen.
Ich mag nur nichts mehr, aus dem ich die Daten nicht auch per
Hand rausgefrickelt kriege (solange das Archiv/Backup-File intakt
ist, klar).

Gruß,
Patrick

[Patrick M. Hausen]

Hallo,

Post by Patrick M. Hausen
Ich mag nur nichts mehr, aus dem ich die Daten nicht auch per
Hand rausgefrickelt kriege (solange das Archiv/Backup-File intakt
ist, klar).

Nachtrag: und das bedeutet für mich eben, ich habe nur noch die
nackten Platten (genügend davon intakt ;-), irgendein Mainboard, an
das ich sie anschließen kann, und das FreeBSD, Linux oder Solaris
bootet. Wenn ich damit meinen Krempel wieder bekomme, dann is' gut.
Die Anforderung erfüllt ZFS im Moment bei weitem am besten.

Gruß,
Patrick

[Joern Bredereck]

Post by Patrick M. Hausen
Ich gebe zu: ich könnte nur für das Backup durchaus iSCSI nehmen.
Ich mag nur nichts mehr, aus dem ich die Daten nicht auch per
Hand rausgefrickelt kriege (solange das Archiv/Backup-File intakt
ist, klar).

Ein per iSCSI formatiertest Volume kannst du auch jederzeit z.B. per USB
oder Firewire an deinen Mac anschliessend und mounten.

Ich habe hier eine externe USB-Platte mit meiner ITunes-Library, die ich
mir in meinem Heim-Netz per iSCSI an meinen Mac exportiere. Und wenn ich
mal länger unterwegs bin, nehme ich diese Platte einfach mit und stöpsel
sie per USB an mein MacBook Air.

VG,

Jörn

[Andreas Berger]

Post by Patrick M. Hausen
Was die Netatalk-Version angeht: FreeNAS 8.0.1 beta 4 ist endlich
benutzbar

[OFFTOPIC] Weisst Du, wie man die JRE auf das Teil bekommt? Die binaries
setzen alle auf freebsd7 auf.
<http://www.freebsdfoundation.org/downloads/java.shtml>

[Patrick M. Hausen]

Hi!

Post by Andreas Berger

Post by Patrick M. Hausen
Was die Netatalk-Version angeht: FreeNAS 8.0.1 beta 4 ist endlich
benutzbar

[OFFTOPIC] Weisst Du, wie man die JRE auf das Teil bekommt? Die binaries
setzen alle auf freebsd7 auf.
<http://www.freebsdfoundation.org/downloads/java.shtml>

Ja - und?

Du brauchst:

diablo-jdk-1.6.0.07.02_15
compat7x-amd64-7.3.703000.201008_1

und natürlich ein paar weitere Abhängigkeiten wie xproto-7.0.16
etc. pp.

Gestern erst auf einem 8-STABLE installiert.

Gruß,
Patrick

[Joern Bredereck]

Post by Patrick M. Hausen

Post by Patrick M. Hausen

Post by Andreas Berger
<http://www.snsftp.com/public/globalsan/>?

Die Frage, ob es das in 5 Jahren noch gibt, und es
dann mit der dann aktuellen Mac-OS-X-Version noch funktioniert.

Warum sollte es in 5 Jahren keinen iSCSI-Initiator mehr geben? iSCSI ist
ein offener Industriestandard, für den es wohl immer entsprechenden
Implementierungen auf allen gängigen Plattformen geben wird. AFP ist
hingegen ein proprietäres Filesharing-Protokoll von Apple, welches Apple
jederzeit einstellen könnte. Ich schätze die Gefahr, dass es in 5 Jahren
kein AFP mehr gibt jedenfalls als höher ein, als die Gefahr dass du in 5
Jahren keinen iSCSI-Initiator mehr findest.

Post by Patrick M. Hausen
Und mit Netatalk und ZFS auf dem FreeNAS bekomme ich das
Sparse-Image zur Not in 5 Jahren manuell auf eine USB/Thunderbolt-Platte
kopiert, die direkt am Mac angeschlossen, und die Daten da irgendwie
wieder raus ... sollte Apple AFP killen oder so modifizieren, dass
Netatalk nicht hinterher kommt, oder ...
Darum geht's mir. Ich will dauerhaft wieder an meine Daten kommen.
Deshalb: keine proprietäre Technik.

Wenn du keine proprietäre Technik willst, dann solltest du AFP nicht
verwenden, denn das ist proprietär. iSCSI ist hingegen ein offener
Industrie-Standard.

VG,

Jörn

[Alexander Barton]

Post by Joern Bredereck
Warum sollte es in 5 Jahren keinen iSCSI-Initiator mehr geben? iSCSI ist
ein offener Industriestandard, für den es wohl immer entsprechenden
Implementierungen auf allen gängigen Plattformen geben wird.

Diese Einschätzung kann ich nun gar nicht teilen.

Heute kenne ich 2 Implementierungen: Atto und GlobalSAN.
Funktionieren tut hiervon eine, Atto. GlobalSAN funktioniert in unseren
Tests seit 10.6.7 nicht mehr zuverlässig. Und bisher hat sich da nichts
weiter getan. Von 10.7 will ich gar nicht erst schreiben.

Post by Joern Bredereck
AFP ist
hingegen ein proprietäres Filesharing-Protokoll von Apple, welches Apple
jederzeit einstellen könnte. Ich schätze die Gefahr, dass es in 5 Jahren
kein AFP mehr gibt jedenfalls als höher ein, als die Gefahr dass du in 5
Jahren keinen iSCSI-Initiator mehr findest.

Wenn "morgen" Atto keine Lust mehr hat gibt es ... 0 brauchbare.

Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?

Und da schätze ich letzteres doch als deutlich geringer ein, Apple hat
wohl deutlich mehr Kunden, die AFP einsetzen, also Atto Kunden hat, die
ihren iSCSI-Initiator für Mac OS X nutzen ...

Viele Grüße
Alex

[Daniel Krebs]

Post by Alexander Barton

Post by Joern Bredereck
Warum sollte es in 5 Jahren keinen iSCSI-Initiator mehr geben? iSCSI ist
ein offener Industriestandard, für den es wohl immer entsprechenden
Implementierungen auf allen gängigen Plattformen geben wird.

Diese Einschätzung kann ich nun gar nicht teilen.
Heute kenne ich 2 Implementierungen: Atto und GlobalSAN.
Funktionieren tut hiervon eine, Atto. GlobalSAN funktioniert in unseren
Tests seit 10.6.7 nicht mehr zuverlässig. Und bisher hat sich da nichts
weiter getan. Von 10.7 will ich gar nicht erst schreiben.

Post by Joern Bredereck
AFP ist
hingegen ein proprietäres Filesharing-Protokoll von Apple, welches Apple
jederzeit einstellen könnte. Ich schätze die Gefahr, dass es in 5 Jahren
kein AFP mehr gibt jedenfalls als höher ein, als die Gefahr dass du in 5
Jahren keinen iSCSI-Initiator mehr findest.

Wenn "morgen" Atto keine Lust mehr hat gibt es ... 0 brauchbare.
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?
Und da schätze ich letzteres doch als deutlich geringer ein, Apple hat
wohl deutlich mehr Kunden, die AFP einsetzen, also Atto Kunden hat, die
ihren iSCSI-Initiator für Mac OS X nutzen ...

Ist das nicht eher eine Diskussion darüber, wer seine Kristallkugel
besser geputzt hat?
Daniel

[Andre Igler]

Post by Daniel Krebs

Post by Alexander Barton

Post by Joern Bredereck
Warum sollte es in 5 Jahren keinen iSCSI-Initiator mehr geben?
iSCSI ist ein offener Industriestandard, für den es wohl immer
entsprechenden Implementierungen auf allen gängigen Plattformen
geben wird.

Diese Einschätzung kann ich nun gar nicht teilen.
Heute kenne ich 2 Implementierungen: Atto und GlobalSAN.
Funktionieren tut hiervon eine, Atto. GlobalSAN funktioniert in
unseren Tests seit 10.6.7 nicht mehr zuverlässig. Und bisher hat
sich da nichts weiter getan. Von 10.7 will ich gar nicht erst
schreiben.

Post by Joern Bredereck
AFP ist hingegen ein proprietäres Filesharing-Protokoll von
Apple, welches Apple jederzeit einstellen könnte. Ich schätze die
Gefahr, dass es in 5 Jahren kein AFP mehr gibt jedenfalls als
höher ein, als die Gefahr dass du in 5 Jahren keinen
iSCSI-Initiator mehr findest.

Wenn "morgen" Atto keine Lust mehr hat gibt es ... 0 brauchbare.
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?
Und da schätze ich letzteres doch als deutlich geringer ein, Apple
hat wohl deutlich mehr Kunden, die AFP einsetzen, also Atto Kunden
hat, die ihren iSCSI-Initiator für Mac OS X nutzen ...

Ist das nicht eher eine Diskussion darüber, wer seine Kristallkugel
besser geputzt hat?

[full quote intentional]

Das sehe ich eher als eine Diskussion darüber an, wieviel Eier man in
welchen Korb legen soll/möchte/wird. Oder so.

addio

[Alexander Barton]

Post by Daniel Krebs

Post by Alexander Barton
Und da schätze ich letzteres doch als deutlich geringer ein, Apple hat
wohl deutlich mehr Kunden, die AFP einsetzen, also Atto Kunden hat, die
ihren iSCSI-Initiator für Mac OS X nutzen ...

Ist das nicht eher eine Diskussion darüber, wer seine Kristallkugel
besser geputzt hat?
Daniel

Schon :-)

Aber mich würde doch interessieren, mit welchen iSCSI Initiatoren Joern
unter Mac OS X gute Erfahrungen gemacht hat, wenn er sie so favorisiert.

Viele Grüße
Alex

[Joern Bredereck]

Post by Alexander Barton
Aber mich würde doch interessieren, mit welchen iSCSI Initiatoren Joern
unter Mac OS X gute Erfahrungen gemacht hat, wenn er sie so favorisiert.

Wie gesagt: GlobalSAN auf der Client-Seite funktioniert bei uns auf
diversen Maschinen vollkommen problemlos. Auf der Target-Seite kommt der
IETD unter Linux zum Einsatz. Vielleicht hat bei euren Tests ja auch der
Target die Probleme gemacht und nicht der Initiator? Was für Probleme
hattet ihr denn konkret?

VG,

Jörn

[Alexander Barton]

Post by Joern Bredereck

Post by Alexander Barton
Aber mich würde doch interessieren, mit welchen iSCSI Initiatoren Joern
unter Mac OS X gute Erfahrungen gemacht hat, wenn er sie so favorisiert.

Wie gesagt: GlobalSAN auf der Client-Seite funktioniert bei uns auf
diversen Maschinen vollkommen problemlos.

Welches Mac OS X?

Seit 10.6.7 funktioniert er bei uns reproduzierbar auf _keinem_ System

Post by Joern Bredereck
Auf der Target-Seite kommt der IETD unter Linux zum Einsatz. Vielleicht
hat bei euren Tests ja auch der Target die Probleme gemacht und nicht der
Initiator? Was für Probleme hattet ihr denn konkret?

10.6.*: mit einem ietd/Linux Target (und testweise istgt/FreeBSD): mind.
1x die Woche eine Kernel Panic oder ein Freeze mit der GlobalSan kext im
Backtrace. Oder einfach ein Disconnect des Targets. Oder ...

10.6.{7|8}: Deatch funktioniert nicht mehr, 100% CPU-Auslastung im
"kernel_task". 100% reproduzierbar durch a) Klicken auf "disconnect" im
Kontrollfeld oder b) stoppen des Targets. Einzig bekannt Abhilfe: Reboot.

Mit 10.7 können Volumes nicht mehr connectiert werden: das Kontrollfeld
zeigt zwar "connected" an, die Volumes werden von Mac OS X jedoch nicht
"gesehen".

Gut, dass der Initiator nicht mehr mit 10.7 (zuverlässig) tut, damit könnte
ich leben -- wer heute 10.7 auf Kundensystemem produktiv einsetzt, frisst
vermutlich auch kleine Kinder -- aber es funktioniert ja auch mit 10.6
schon nicht wirklich zuverlässig. Und es war auch eine Geburt, bis SNS
eine 64-bittige kext hatte, was für die Xserve und MacPro, die per Default
den 64-bit-Kernel booten, doch eine nette Sache war ...

Anders als du im anderen Posting von dir, kann ich übrigens auch keine
neuere Version als 4.1.0.279 bei SNS finden[1] -- von "innerhalb von 24
Stunden" kann also keine Rede sein. Diese Version wurde am 17. März
in den Foren angekündigt[2], seitdem tat sich nichts mehr.

Wir haben auch mal versucht, von SNS (kommerziellen) Support für das Ding
zu bekommen. Bei dem Versuch blieb es aber auch: "gibt es nicht".

Mag ja sein, dass es für deren SanMP und ausgesuchte Targets honreichend
funktioniert, als universeller iSCSI-Initator taugt es aber definitiv
nicht.

Viele Grüße
Alex

[1] http://www.snsforums.com/index.php?showtopic=26
[2] http://www.snsforums.com/index.php?showtopic=448

[Joern Bredereck]

Post by Alexander Barton

Post by Joern Bredereck
Wie gesagt: GlobalSAN auf der Client-Seite funktioniert bei uns auf
diversen Maschinen vollkommen problemlos.

Welches Mac OS X?

10.7

Post by Alexander Barton
Seit 10.6.7 funktioniert er bei uns reproduzierbar auf _keinem_ System

lief auch unter 10.6.7 bei mir noch ohne Probleme. Ich mache seit etwa
einem Jahr meine Timemachine-Backups nur noch über GlobalSAN; und das
mit allen MacOS-Versionen, die seither rauskamen.

Post by Alexander Barton
10.6.{7|8}: Deatch funktioniert nicht mehr, 100% CPU-Auslastung im
"kernel_task". 100% reproduzierbar durch a) Klicken auf "disconnect" im
Kontrollfeld oder b) stoppen des Targets. Einzig bekannt Abhilfe: Reboot.

Disconnect klappt bei mir. Den Target abwürgen führt erwartungsgemäss
natürlich zu problemen (Hängern). Meistens fängt er sich dann aber
wieder, wenn man den Target-Dienst wieder startet.

Was ab und zu etwas Probleme macht ist meine Itunes-Library, die ich
ebenfalls auf einer externen Festplatte liegen habe, die wiederum in
meinem LAN zu hause per iSCSI eingebunden wird. Probleme gibt es z.B.
dann, wenn ich das Macbook bei geöffnetem ITunes zuklappe. Nach dem
Aufwachen passiert es ab und zu, dass ITunes seine Library nicht mehr
findet, weil die iSCSI-Verbindung zu dem Zeitpunkt noch nicht wieder
steht. Ich muss dann Itunes "hart" schliessen. Anschliessend lässt es
sich aber wieder normal öffnen und findet natürlich seine Library auch
wieder. Inzwischen mache ich ITunes eben vorher zu, wenn ich das MacBook
"schlafen lege". Damit kann ich leben. Ist immernoch besser als immer
die externe Platte in den Garten mitnehmen zu müssen, wenn ich mit dem
MacBook mal raus gehe.

Post by Alexander Barton
Gut, dass der Initiator nicht mehr mit 10.7 (zuverlässig) tut, damit könnte
ich leben -- wer heute 10.7 auf Kundensystemem produktiv einsetzt, frisst
vermutlich auch kleine Kinder

10.7 läuft gut. Probleme machen lediglich Programme von
Drittherstellern, die es bis heute noch nicht geschafft haben, ihre
Software für 10.7 anzupassen. Solange man solch eine Software nicht
einsetzt ist man im grünen Bereich.

Post by Alexander Barton
Anders als du im anderen Posting von dir, kann ich übrigens auch keine
neuere Version als 4.1.0.279 bei SNS finden[1] -- von "innerhalb von 24
Stunden" kann also keine Rede sein. Diese Version wurde am 17. März
in den Foren angekündigt[2], seitdem tat sich nichts mehr.

Ja, das ist ne seltsame Sache: Ich hatte direkt nach dem Upgrade auf
10.7 (hatte es noch am selben Tag auf einem MacBook Pro installiert)
bemerkt, dass GlobalSan zunächst nicht mehr funktionierte. Ich hatte
daraufhin am selben Tag noch die damals aktuellste Version
heruntergeladen. Leider ohne Erfolg. Ich hatte diesbezüglich auch im
SNS-Forum und im UseNet nachgefragt.

Einen Tag später habe ich mein MacBook Air auf 10.7 geupgraded und auch
hier nochmal die aktuellste GlobalSAN-Version von deren Server
heruntergeladen. Und sieh da: Es lief auf Anhieb.

Anschließend habe ich mir auch auf dem MacBook Pro nochmal die neuste
Version vom SNS-Server gezogen und auch da funktionierte nach dem Reboot
wieder alles.

Anschliessend habe ich mal in meinen Download-Ordner auf dem MBP
geschaut: Der Dateiname der am Tag zuvor heruntergeladenen
Global-San-Version war ein anderer als der Name der Datei, die ich am
Tag danach geladen hatte. Auch die Dateigröße war eine andere. Ergo: Die
Jungs von SNS scheinen da irgendwas gefixt zu haben; auch wenn die
Versionsnummer sich offiziell nicht geändert hat.

In den darauffolgenden Tagen habe ich die neue Version dann auch bei
unseren anderen Macs in der Firma eingespielt und auch hier
funktioniert's auch nach Lion-Upgrade noch problemlos.

Langer Rede kurzer Sinn: Probier doch einfach nochmal die aktuellste
Version aus, die JETZT auf dem SNS-Server liegt.

Post by Alexander Barton
Mag ja sein, dass es für deren SanMP und ausgesuchte Targets honreichend
funktioniert, als universeller iSCSI-Initator taugt es aber definitiv
nicht.

YMMV. Bei uns taugts.

Joerns-MBA:Downloads jb$ uname -a
Darwin Joerns-MBA.local 11.0.0 Darwin Kernel Version 11.0.0: Sat Jun 18
12:56:35 PDT 2011; root:xnu-1699.22.73~1/RELEASE_X86_64 x86_64

Joerns-MBA:Downloads jb$ kextstat -l |grep -i sns
91 1 0xffffff7f80854000 0x22000 0x22000
com.sns.driver.SNSArchitectureModel (1.1) <90 50 48 7 5 4 3 1>
92 0 0xffffff7f817a7000 0x17000 0x17000
com.sns.driver.SnsiSCSI (4.1) <91 90 12 7 5 4 3 1>

Joerns-MBA:Downloads jb$ diskutil info disk1s2
Device Identifier: disk1s2
Device Node: /dev/disk1s2
Part of Whole: disk1
Device / Media Name: timemachine-mba

Volume Name: timemachine-mba
Escaped with Unicode: timemachine-mba

Mounted: Yes
Mount Point: /Volumes/timemachine-mba
Escaped with Unicode: /Volumes/timemachine-mba

File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
Journal: Journal size 16384 KB at offset 0x5d2000
Owners: Enabled

Partition Type: Apple_HFS
OS Can Be Installed: Yes
Media Type: Generic
Protocol: iSCSI
SMART Status: Not Supported
Volume UUID: 1BE5883B-4A99-3A8A-8730-684E3D4E5022

Total Size: 199.7 GB (199656026112 Bytes) (exactly
389953176 512-Byte-Blocks)
Volume Free Space: 128.4 GB (128386977792 Bytes) (exactly
250755816 512-Byte-Blocks)
Device Block Size: 512 Bytes

Read-Only Media: No
Read-Only Volume: No
Ejectable: Yes

Whole: No
Internal: No


Joerns-MBA:Downloads jb$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 112Gi 74Gi 38Gi 66% /
devfs 190Ki 190Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
/dev/disk1s2 186Gi 66Gi 120Gi 36% /Volumes/timemachine-mba



VG,

Jörn

[Andreas Berger]

Post by Alexander Barton
10.6.{7|8}: Deatch funktioniert nicht mehr, 100% CPU-Auslastung im
"kernel_task". 100% reproduzierbar durch a) Klicken auf "disconnect" im
Kontrollfeld oder b) stoppen des Targets. Einzig bekannt Abhilfe: Reboot.

Ja shit, den habe ich hier unter 10.7. Blöderweise lässt sich der
Rechner nicht mal mehr zu einem reboot überreden.

Post by Alexander Barton
Mit 10.7 können Volumes nicht mehr connectiert werden: das Kontrollfeld
zeigt zwar "connected" an, die Volumes werden von Mac OS X jedoch nicht
"gesehen".

Ja doch, das geht bei mir.

[Joern Bredereck]

Dieser beitrag ist möglicherweise unangemessen. Klicken sie auf, um es anzuzeigen.

[Thomas Kaiser]

Post by Joern Bredereck
Das selbe können meine Kollegen, die auf NAS+AFP gesetzt haben, leider
_nicht_ sagen. Hier gibt es immernoch viele NAS-Geräte, die bis heute
nicht mit dem AFP von 10.7 klarkommen.

Aha, "das AFP von 10.7", soso -- das Problem ist in erster Linie das,
daß die NAS-Heimer zu blöde/ignorant waren, die DHX2-Authentifizierung
einzuschalten (kam mit MacOS X 10.2, also vor ca. 10 Jahren, ist in
Netatalk ab Version 2.1 drin, muß vom NAS-Hersteller nur eingeschaltet
werden). Im Kontext TimeMachine noch wichtig: Ab AFP 3.3 gibt es das
Feature "Reply Cache", das konsistente Backups im Falle von Netzwerk-
Problemen sicherstellen soll (sowas gibt's -- nebenbei bemerkt -- bei
iSCSI nicht. Da ziehst Du mal kurz das Kabel und alles ist kaputt). 10.6
sichert törichterweise auch auf AFP-Server ohne Reply-Cache, 10.7 ist im
Sinne der User bzw. eines konsistenten Backups da strenger. Sehr zu
begrüssen.

Post by Joern Bredereck

Post by Alexander Barton
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?

AFP ist nunmal kein Standard.

Ah ja, klar. Was ist es denn dann? Ein Brotaufstrich?

Post by Joern Bredereck
Hier gibt es genau EINE brauchbare, reverse enginierte, und
plattformübergreifende Implementierung.

Was ist los? Von was faselst Du wieder? "Reverse Engineering" braucht's
bei AFP nur in Teilbereichen (konkret Spotlight), der Rest ist offen
spezifiziert:

http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/Introduction/Introduction.html#//apple_ref/doc/uid/TP40000854-CH1-SW1

Es gibt neben Netatalk an _aktiv_ entwickelten AFP-Servern bspw. noch
EtherShare (diverse Unices) oder ExtremeZ-IP (Windows) und eben Apples
eigenen AppleFileServer (OS X). Und in der Vergangenheit gab's noch 'ne
ganze Menge mehr, siehe bspw.

http://www.knubbelmac.de/themen/afp-server-vergleich.html

Gruss,

Thomas

[Joern Bredereck]

Post by Thomas Kaiser

Post by Joern Bredereck
Das selbe können meine Kollegen, die auf NAS+AFP gesetzt haben, leider
_nicht_ sagen. Hier gibt es immernoch viele NAS-Geräte, die bis heute
nicht mit dem AFP von 10.7 klarkommen.

Aha, "das AFP von 10.7", soso -- das Problem ist in erster Linie das,
daß die NAS-Heimer zu blöde/ignorant waren, die DHX2-Authentifizierung
einzuschalten (kam mit MacOS X 10.2, also vor ca. 10 Jahren, ist in
Netatalk ab Version 2.1 drin, muß vom NAS-Hersteller nur eingeschaltet
werden). Im Kontext TimeMachine noch wichtig: Ab AFP 3.3 gibt es das
Feature "Reply Cache", das konsistente Backups im Falle von Netzwerk-
Problemen sicherstellen soll

Welche NAS mit Ausnahme der TimeCapsule haben das zur Einführung von
10.7 unterstützt? Was bringt mir der Reply Cache, wenn's dafür so gut
wie keine fertigen Implementierungen gibt?

Post by Thomas Kaiser
(sowas gibt's -- nebenbei bemerkt -- bei
iSCSI nicht. Da ziehst Du mal kurz das Kabel und alles ist kaputt).

Netter Versuch, aber "Kabel ziehen" ist nun wirklich kein valides
Kriterium. Wenn ich während des TM-Backups auf meine USB-Festplatte das
USB-Kabel ziehe ist unter Umständen auch alles kaputt. Und wenn ich
während des TM-Backups per AFP auf eine Timecapsule den Strom-Stecker
der TimeCapsule ziehe, dann ebenso. -> Nullargument

Post by Thomas Kaiser

Post by Joern Bredereck

Post by Alexander Barton
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?

AFP ist nunmal kein Standard.

Ah ja, klar. Was ist es denn dann? Ein Brotaufstrich?

Es ist ein proprietäres Protokoll, dass unter der Kontrolle einer
einzigen Firma steht. Das willst du doch wohl nicht ernsthaft mit einem
freien Industrie-Standard wie (i)SCSI vergleichen, oder?

Post by Thomas Kaiser

Post by Joern Bredereck
Hier gibt es genau EINE brauchbare, reverse enginierte, und
plattformübergreifende Implementierung.

Was ist los? Von was faselst Du wieder? "Reverse Engineering" braucht's
bei AFP nur in Teilbereichen (konkret Spotlight), der Rest ist offen
http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/Introduction/Introduction.html#//apple_ref/doc/uid/TP40000854-CH1-SW1

Ok, mag sein dass ein Reverse Engineering nicht notwendig ist. Das macht
AFP aber noch lange nicht zu einem offenen Standard sondern höchtens zu
einem _dokumentierten_ proprietären Protokoll.

Post by Thomas Kaiser
Es gibt neben Netatalk an _aktiv_ entwickelten AFP-Servern bspw. noch
EtherShare (diverse Unices) oder ExtremeZ-IP (Windows) und eben Apples
eigenen AppleFileServer (OS X). Und in der Vergangenheit gab's noch 'ne
ganze Menge mehr, siehe bspw.

Bringen die von dir oben genannten Implementierungen überhaupt DHX2 und
Replay Cache mit, sodass sie für diese Diskussion überhaupt relevant
wären? Oder kürzer gefragt: Was außer der aktuellen Netatalk-Beta kann
ich denn überhaupt für TimeMachine benutzen?

VG,

Jörn

[Thomas Kaiser]

Post by Joern Bredereck

Post by Thomas Kaiser

Post by Joern Bredereck
Das selbe können meine Kollegen, die auf NAS+AFP gesetzt haben,
leider _nicht_ sagen. Hier gibt es immernoch viele NAS-Geräte, die
bis heute nicht mit dem AFP von 10.7 klarkommen.

Aha, "das AFP von 10.7", soso -- das Problem ist in erster Linie das,
daß die NAS-Heimer zu blöde/ignorant waren, die DHX2-
Authentifizierung einzuschalten (kam mit MacOS X 10.2, also vor ca.
10 Jahren, ist in Netatalk ab Version 2.1 drin, muß vom NAS-
Hersteller nur eingeschaltet werden). Im Kontext TimeMachine noch
wichtig: Ab AFP 3.3 gibt es das Feature "Reply Cache", das
konsistente Backups im Falle von Netzwerk- Problemen sicherstellen
soll

Welche NAS mit Ausnahme der TimeCapsule haben das zur Einführung von
10.7 unterstützt?

Du hast es nicht verstanden. Der Replay Cache kam mit AFP 3.3, welches
parallel zu MacOS X 10.6 kam. Der Zusammenhang mit 10.7 ist nur der, daß
10.7 nun zwingend _für Time Machine_ das AFP3.3-Feature Replay Cache
verlangt.

Post by Joern Bredereck
Was bringt mir der Reply Cache, wenn's dafür so gut wie keine fertigen
Implementierungen gibt?

Man wird sehen, ob das, was jetzt seitens der Netatalk-Jungs an
Diskussion entstanden ist, mittel- und langfristig dazu führt, daß die
diversen NAS-Hersteller Mac-User wirklich ernstnehmen. Die haben ja
jahrelang einfach nur uralte Netatalk-Versionen verbaut, bei Problemen
wüst irgendwas dahergepatcht und die eigentliche Netatalk-Entwicklung
ausbluten lassen. Aktuell scheint ein Umdenken eingetreten zu sein --
wie lange das anhält, wird man sehen. Laut den netafp.com-Jungs sind
neben Netgear aktuell noch Drobo, QNAP und Western Digital an Bord, d.h.
unterstützen die Netatalk-Entwicklung nun auch finanziell und verbauen
Netatalk 2.2.0 in ihren Kisten.

Netgear hat frische ReadyNAS-Firmwares im Juli rausgebracht, bei QNAP
dauert's noch Tage:

http://www.qnap.com/PressRelease_detail.asp?pr_id=251

Keine Ahnung, wie der Status bei WD und Drobo aussieht.

Post by Joern Bredereck

Post by Thomas Kaiser
(sowas gibt's -- nebenbei bemerkt -- bei iSCSI nicht. Da ziehst Du
mal kurz das Kabel und alles ist kaputt).

Netter Versuch, aber "Kabel ziehen" ist nun wirklich kein valides
Kriterium.

Für Dich nicht. Für Leute, die sich mit dem AFP-Feature "Reconnect"
beschäftigt haben und wissen, daß sie mittendrin mal schnell eben ihren
Rechner vom Netzwerk abstecken, von einem Raum in den nächsten tragen
können und dort wieder anstecken, ohne daß auch nur irgendwas passiert,
schon. Genau für solche kurzen temporären Ausfälle ist sowohl Reconnect
als auch nun der Replay Cache gedacht. Das nimmt denen effektiv den
Schrecken.

Post by Joern Bredereck

Post by Thomas Kaiser

Post by Joern Bredereck

Post by Alexander Barton
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?

AFP ist nunmal kein Standard.

Ah ja, klar. Was ist es denn dann? Ein Brotaufstrich?

Es ist ein proprietäres Protokoll, dass unter der Kontrolle einer
einzigen Firma steht. Das willst du doch wohl nicht ernsthaft mit einem
freien Industrie-Standard wie (i)SCSI vergleichen, oder?

AFP ist Standard, wenn's darum geht, daß Macs auf Netzwerk-Shares
zugreifen.

Post by Joern Bredereck

Post by Thomas Kaiser

Post by Joern Bredereck
Hier gibt es genau EINE brauchbare, reverse enginierte, und
plattformübergreifende Implementierung.

Was ist los? Von was faselst Du wieder? "Reverse Engineering"
braucht's bei AFP nur in Teilbereichen (konkret Spotlight), der Rest
http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/Introduction/Introduction.html#//apple_ref/doc/uid/TP40000854-CH1-SW1

Ok, mag sein dass ein Reverse Engineering nicht notwendig ist. Das
macht AFP aber noch lange nicht zu einem offenen Standard sondern
höchtens zu einem _dokumentierten_ proprietären Protokoll.

Das zufälligerweise dann zum Einsatz kommt, wenn man den proprietären
Backup-Mechanismus in den aktuellen Versionen des proprietären
Betriebsystems des gleichen Herstellers einsetzt. Wow.

Post by Joern Bredereck

Post by Thomas Kaiser
Es gibt neben Netatalk an _aktiv_ entwickelten AFP-Servern bspw. noch
EtherShare (diverse Unices) oder ExtremeZ-IP (Windows) und eben
Apples eigenen AppleFileServer (OS X). Und in der Vergangenheit gab's
noch 'ne ganze Menge mehr, siehe bspw.

Bringen die von dir oben genannten Implementierungen überhaupt DHX2 und
Replay Cache mit, sodass sie für diese Diskussion überhaupt relevant
wären? Oder kürzer gefragt: Was außer der aktuellen Netatalk-Beta kann
ich denn überhaupt für TimeMachine benutzen?

Meine Fresse, lies halt die Threads, in denen Du postest.

DHX2 ist erstmal schon wurscht, weil man's dem 10.7-Client auch wieder
angewöhnen kann, DHCAST128 zu nutzen, abermals siehe:

http://www.hilfdirselbst.ch/foren/gforum.cgi?post=476417#476417

Inzwischen hat sogar Apple selbst gemerkt, daß es keine so gute Idee
war, etwas auf die schwarze Liste zu setzen, wenn der Nachfolger der
Authentifizierungsmethode sich noch nicht wirklich etabliert hat.

http://support.apple.com/kb/HT4700?viewlocale=de_DE

Dann: Neben "der aktuellen Netatalk-Beta" kann selbstverständlich auch
die endgültige Version 2.2.0 AFP 3.3 und DHX2 (Release-Datum 9. 6.
2011). Dito ExtremeZ-IP ab Version 7.2, die -- welch Zufall -- am 21. 7.
2011 rauskam, also exakt zeitgleich mit MacOS X 10.7. Und Helios hat
noch bisserl gebraucht, die aktuelle EtherShare-Release UB2 hab ich erst
letzten Freitag in Händen halten können (die Betas und Preview-Versionen
von UB2 konnten das schon seit Ende letzten Jahres)

Und damit EOT meinerseits,

Thomas, tut sich den Zirkus wie vor einem Jahr sicherlich nicht nochmal
an...

[Joern Bredereck]

Post by Thomas Kaiser

Post by Joern Bredereck
Welche NAS mit Ausnahme der TimeCapsule haben das zur Einführung von
10.7 unterstützt?

Du hast es nicht verstanden. Der Replay Cache kam mit AFP 3.3, welches
parallel zu MacOS X 10.6 kam. Der Zusammenhang mit 10.7 ist nur der, daß
10.7 nun zwingend _für Time Machine_ das AFP3.3-Feature Replay Cache
verlangt.

Pack deine Mikro-Axt zum Haarspalten bitte wieder ein... das bringt uns
nicht wirklich weiter. Tatsache ist, dass Time-Machine-Backups auf einen
Großteil der verfügbaren NAS-Geräte seit 10.7 nicht mehr funktionieren.
Man muss schon viel Fantasie mitbringen, um darin erstmal einen Vorteil
zu sehen.

Ich jedenfalls sehe erstmal einen Nachteil darin, wenn Backups nicht
mehr laufen. Lieber riskiere ich, dass ein Backup mangels Replay Cache
mal kaputt geht, als dass ich GAR KEIN Backup mehr erstellen kann.

Post by Thomas Kaiser

Post by Joern Bredereck
Was bringt mir der Reply Cache, wenn's dafür so gut wie keine fertigen
Implementierungen gibt?

Man wird sehen, ob das, was jetzt seitens der Netatalk-Jungs an
Diskussion entstanden ist, mittel- und langfristig dazu führt, daß die
diversen NAS-Hersteller Mac-User wirklich ernstnehmen. Die haben ja
jahrelang einfach nur uralte Netatalk-Versionen verbaut, bei Problemen
wüst irgendwas dahergepatcht und die eigentliche Netatalk-Entwicklung
ausbluten lassen. Aktuell scheint ein Umdenken eingetreten zu sein --
wie lange das anhält, wird man sehen. Laut den netafp.com-Jungs sind
neben Netgear aktuell noch Drobo, QNAP und Western Digital an Bord, d.h.
unterstützen die Netatalk-Entwicklung nun auch finanziell und verbauen
Netatalk 2.2.0 in ihren Kisten.
Netgear hat frische ReadyNAS-Firmwares im Juli rausgebracht, bei QNAP
http://www.qnap.com/PressRelease_detail.asp?pr_id=251
Keine Ahnung, wie der Status bei WD und Drobo aussieht.

Ist ja schön, dass die Hersteller jetzt alle zum Handeln gezwungen
werden. Aber den Preis hierfür zahlen die Anwender, die jetzt temporär
erstmal keine Backups machen können, wenn Sie auf AFP setzen.

Als Workaround kann man nun seine Backup-Platten per FW oder USB oder
eben iSCSI anschliessen. Auch wenn man dann plötzlich keine Kabel mehr
rausziehen darf. :->

Post by Thomas Kaiser

Post by Joern Bredereck

Post by Thomas Kaiser
(sowas gibt's -- nebenbei bemerkt -- bei iSCSI nicht. Da ziehst Du
mal kurz das Kabel und alles ist kaputt).

Netter Versuch, aber "Kabel ziehen" ist nun wirklich kein valides
Kriterium.

Für Dich nicht. Für Leute, die sich mit dem AFP-Feature "Reconnect"
beschäftigt haben und wissen, daß sie mittendrin mal schnell eben ihren
Rechner vom Netzwerk abstecken, von einem Raum in den nächsten tragen
können und dort wieder anstecken, ohne daß auch nur irgendwas passiert,
schon. Genau für solche kurzen temporären Ausfälle ist sowohl Reconnect
als auch nun der Replay Cache gedacht. Das nimmt denen effektiv den
Schrecken.

Die Leute, die momentan nicht mehr sichern können, konnten auch bislang
kein Kabel ziehen, weil ihre olle Netatalk-Version das nicht unterstützt
hat. Frag mal diese Leute, ob sie lieber ihr Kabel ziehen wollen, oder
ob sie in der Lage sein wollen überhaupt wieder irgendwelche Daten zu
sichern.

Post by Thomas Kaiser

Post by Joern Bredereck

Post by Thomas Kaiser

Post by Joern Bredereck

Post by Alexander Barton
Wo ist da der Unterschied zu "Apple hat auf AFP keine Lust mehr"?

AFP ist nunmal kein Standard.

Ah ja, klar. Was ist es denn dann? Ein Brotaufstrich?

Es ist ein proprietäres Protokoll, dass unter der Kontrolle einer
einzigen Firma steht. Das willst du doch wohl nicht ernsthaft mit einem
freien Industrie-Standard wie (i)SCSI vergleichen, oder?

AFP ist Standard, wenn's darum geht, daß Macs auf Netzwerk-Shares
zugreifen.

;-) nice try... aber ich glaube jedem hier ist klar, wass der
Unterschied zwischen der proprietären Technik eines einzigen
Unternehmens auf der einen Seite und einem offenen Industrie-Stndard auf
der anderen Seite ist.

Außerdem fände ich mal interessant, ob AFP wirklich immernoch das
meistverwendete Protokoll in der Mac-Welt ist, oder ob nicht inzwischen
schon mehr SMB/CIFS als AFP eingesetzt wird. Zumindest die Macs, die ich
täglich so zu Gesicht bekomme (das sind zugegeben leider nicht sooo
viele, daher ist das bestimmt nicht repräsentativ) greifen meistens auf
irgendwelche Windows-Fileserver oder CIFS-NAS zu.

Post by Thomas Kaiser

Post by Joern Bredereck
Ok, mag sein dass ein Reverse Engineering nicht notwendig ist. Das
macht AFP aber noch lange nicht zu einem offenen Standard sondern
höchtens zu einem _dokumentierten_ proprietären Protokoll.

Das zufälligerweise dann zum Einsatz kommt, wenn man den proprietären
Backup-Mechanismus in den aktuellen Versionen des proprietären
Betriebsystems des gleichen Herstellers einsetzt. Wow.

...einsetzen KANN. Aber keinesfalls MUSS. Das ist der Punkt, den ich
hier machen wollte, und den du geflissentlich irgnorierst und weiterhin
suggerierst, man könne nur mit AFP TM-Backups machen.

VG,

Jörn

[Thomas Kaiser]

Post by Joern Bredereck

Post by Thomas Kaiser
Rechner vom Netzwerk abstecken, von einem Raum in den nächsten tragen
können und dort wieder anstecken, ohne daß auch nur irgendwas
passiert, schon. Genau für solche kurzen temporären Ausfälle ist
sowohl Reconnect als auch nun der Replay Cache gedacht. Das nimmt
denen effektiv den Schrecken.

Die Leute, die momentan nicht mehr sichern können, konnten auch
bislang kein Kabel ziehen, weil ihre olle Netatalk-Version das nicht
unterstützt hat.

Warum muß ich schon wieder an Dieter Nuhr denken?

AFP Reconnect ist ein AFP 3.x-Feature. AFP 3.1 unterstützt Netatalk seit
Version 2.0, d.h. 2004. Jedes NAS, das man die letzten Jahre kaufen
konnte und das man per AFP ansteuert, bietet dieses Feature. Der Replay
Cache ist eine evolutionäre Weiterentwicklung des Protokolls, das in
solchen Situationen nun zusätzlich für Datenkonsistenz sorgen soll.
Vulgo: Eine Verbesserung eines eh schon feinen Features.

Weit und breit nix davon zu sehen bei iSCSI. Korrigier mich bitte, wenn
ich falsch liegen sollte und iSCSI tatsächlich Protokollerweiterungen
spendiert bekommen haben sollte, um mit ungünstigen (W)LAN-Bedingungen
besser, d.h. im Netzwerkbereich v.a. *robuster* umzugehen. Danke.

Post by Joern Bredereck
Frag mal diese Leute, ob sie lieber ihr Kabel ziehen wollen, oder
ob sie in der Lage sein wollen überhaupt wieder irgendwelche Daten zu
sichern.

"Diese Leute" frag ich gar nix, weil ich sie ganz salopp gesagt für
fahrlässig halte. Wer auf eine neue Betriebsystemversion am Tag ihres
Erscheinens wechselt oder auch nur in den Wochen darauf _ohne_
ausreichend zu prüfen, wo überall noch Inkompatibilitäten lauern, der
will es nicht anders als daß irgendwas klemmt oder nicht funktioniert.
Daß man eben bei Frust und Ärger landet. Fahrlässig eben. Bzw. dämlich,
falls man dann auch noch das Jammern anfangen sollte.

Post by Joern Bredereck
Das ist der Punkt, den ich hier machen wollte, und den du
geflissentlich irgnorierst und weiterhin suggerierst, man könne nur
mit AFP TM-Backups machen.

Du, ganz im Ernst. Mir ist "Dein Punkt" sowas von wurscht, ich hab
bisher im Wesentlichen in dem Thread Falschbehauptungen Deinerseits
korrigiert. Mag sein, daß Du mit iSCSI in Deinem Klein-Klein-Szenario
bei Dir daheim und Deinen Kunden glücklich bist und Datenkorruption
bisher nicht auftrat oder nicht bemerkt wurde. Schön, freu Dich :-)

Mir geht's aber darum, zu prüfen, ob iSCSI für Client-Sicherung
vielleicht doch eine Alternative zu AFP ist. Sieht aber nicht danach
aus.

Dein iSCSI Initiator ist in der aktuellsten Version der da, oder?

http://www.snsforums.com/index.php?showtopic=448

Falls ja, dann ist die offizielle Snow-Leopard-kompatible Version, die
auch endlich 64-Bit-Fähigkeit mitbrachte, von GlobalSAN vor paar Monaten
erschienen (Snow Leopard wird demnächst 2 Jahre alt, ist also nur eine
kleine Verspätung von über eineinhalb Jahren). BTW: Deine "iSCSI-
Referenzimplementierung", also Dein Privat-Mac, mit was für CPU läuft
der denn? 64-Bit-fähig?

Wann kommt die Lion-kompatible Version? Jaja, klar. Bei Dir in Deinem
Setup ist alles kompatibel. Mußt Du bloß dem Rest der Welt noch sagen,
der am Jammern ist, siehe bspw.:

http://www.snsforums.com/index.php?showtopic=482 (da posten sogar
Vollidioten, die alle ihre Daten auf iSCSI-Shares ablegen, direkt
mit Erscheinen von 10.7 upgraden und auf nix mehr zugreifen können
-- sensationell! :-)

In dem Szenarium, das wir grad verifizieren, geht's darum, eine manuelle
bzw. proprietär dahergeskriptete Sicherung auf TM umzustellen. Bedeutet,
daß auf günstigen Network-Storage gesichert werden soll (in Form eines
QNAP). Mit iSCSI hätte ich schon mal das Komfort-Problem (nein, man kann
das iSCSI-Blockdevice nicht einfach lokal an einen Mac anschließen, um
im Desaster Recovery Fall davon zu booten -- es handelt sich nicht um
eine USB-Platte wie in Deinem Zuhause-Setup sondern um ein performantes
RAID), dito ein Platzproblem: iSCSI-LUNs bräuchten eine fixe Größe, bei
TM per AFP kann ich jede Share per volsizelimit [1] auf eine virtuelle
Größe festnageln, die dann je zu sicherndem Rechner als Obergrenze gilt.
Den physischen Platz teilen sich aber alle TM-Shares.

Von der Administration des Ganzen irgendwie auch Hölle, wenn man auf
iSCSI setzt. Dort beim Kunden ist alles (User, Rechner) im OpenDirectory
eines MacOS X Server. Dort, also _zentral_, kann man auch per MCX
("Managed Client for OS X") halbwegs bequem den Clients Backup-Shares
zuweisen. Aber halt nur in der Form Server://Share, d.h. nix mit pseudo-
lokalen Volumes wie per iSCSI.

AFP bringt dann _hoffentlich_ noch im Falle von temporären Netzwerk-
Outages mehr Robustheit mit. Und wenn das Setup jetzt sauber läuft, kann
man auch drüber nachdenken, anstelle des QNAP auch wieder auf den
Helios-Server zu sichern (oder dort auf der Solaris-Kiste noch ein
frisches Netatalk 2.2 parallel für den Zweck laufen zu lassen). Ein
ZFS-basiertes System kann man nämlich bspw. per

zfs set compression=gzip

dazu bringen, noch effizienter mit dem physischen Speicherplatz
umzugehen (geht auch nicht per iSCSI, denn da kommt das Dateisystem ja
erst diverse Layer weiter oben drauf. MacOS X ab 10.6 unterstützt zwar
per se auch Kompression auf Dateisystem-Ebene. Wird aber AFAIK von
TimeMachine nicht genutzt).

Gut' Nacht,

Thomas, resümiert, daß er Dir auf den Leim gegangen ist und mal wieder
ziemlich viel Zeit für die Evaluierung einer untauglichen Variante
verschwendet hat, weil sie wer unreflektiert über den Klee gelobt hat...

[1] http://netatalk.sourceforge.net/2.2/htmldocs/AppleVolumes.default.5.html

[Michael Grundmann]

Am 15.08.11 21:05, schrieb Joern Bredereck:


Hallo Jörn,

jetzt kennen wir uns schon so lange :) - aber ...

Post by Joern Bredereck
Welche NAS mit Ausnahme der TimeCapsule haben das zur Einführung von
10.7 unterstützt? Was bringt mir der Reply Cache, wenn's dafür so gut
wie keine fertigen Implementierungen gibt?

reicht es nicht, dass dadurch eine ordentliche Sicherung gewährleistet wird?

Post by Joern Bredereck
Netter Versuch, aber "Kabel ziehen" ist nun wirklich kein valides
Kriterium. Wenn ich während des TM-Backups auf meine USB-Festplatte das
USB-Kabel ziehe ist unter Umständen auch alles kaputt. Und wenn ich
während des TM-Backups per AFP auf eine Timecapsule den Strom-Stecker
der TimeCapsule ziehe, dann ebenso. -> Nullargument

Es ist ein Beispiel, welches doch nur veranschauliches soll, dass es
abrupte Störungen gibt. Nehmen wir doch vielleicht einen Stromausfall,
Überspannung, ... und und und
Bei mir hat letztens ein Techniker, der nur die Klima warten wollte, die
falsche Sicherung gezogen und somit den kompletten Serverraum stromlos
gestellt. Da gibt es zig Gründe.

Post by Joern Bredereck
Es ist ein proprietäres Protokoll, dass unter der Kontrolle einer
einzigen Firma steht. Das willst du doch wohl nicht ernsthaft mit einem
freien Industrie-Standard wie (i)SCSI vergleichen, oder?

Was ist denn mit smb/cifs - wer hats erfunden? Die könnten das doch auch
in die Tonne kloppen. Hier wird über ungelegte Eier geredet - wer kommt
denn nur auf die Idee zu sagen, dass Apple AFP einstampfen wird.
Was in den nächsten zwei Jahren nicht geplant ist, interessiert mich
heute null und nix - da habe ich später noch zeit.

Post by Joern Bredereck
Ok, mag sein dass ein Reverse Engineering nicht notwendig ist. Das macht
AFP aber noch lange nicht zu einem offenen Standard sondern höchtens zu
einem _dokumentierten_ proprietären Protokoll.

siehe einen Absatz oben

Post by Joern Bredereck
Bringen die von dir oben genannten Implementierungen überhaupt DHX2 und
Replay Cache mit, sodass sie für diese Diskussion überhaupt relevant
wären? Oder kürzer gefragt: Was außer der aktuellen Netatalk-Beta kann
ich denn überhaupt für TimeMachine benutzen?

Also über die Beta sind sie erstmal raus - Ethershare kann das auf jeden
Fall auch, ob und wie entzieht sich meiner Kenntnis, denn ich habe es
dafür noch nicht genutzt. Bleibt aber noch das gute _alte_ OS X :)
Apropos - der Rechner meiner Frau sichert mittlerweile auch auf
Netatalk. _Bisher_ ohne Probleme.

[Joern Bredereck]

Post by Michael Grundmann
jetzt kennen wir uns schon so lange :) - aber ...

;-)

Post by Michael Grundmann

Post by Joern Bredereck
Welche NAS mit Ausnahme der TimeCapsule haben das zur Einführung von
10.7 unterstützt? Was bringt mir der Reply Cache, wenn's dafür so gut
wie keine fertigen Implementierungen gibt?

reicht es nicht, dass dadurch eine ordentliche Sicherung gewährleistet wird?

Wir sind in der Diskussion ganz schön abgeschweift. Ursprünglich war
meine Aussage einfach nur, dass ich iSCSI als valide Alternative zu AFP
sehe. Und während teilweise Kollegen und Kunden mit ihren
TM-auf-NAS-Lösungen durch den Umstieg auf Lion auf die Nase gefallen
sind, sichern meine iSCSI-basierten TM-Backups munter weiter.

Post by Michael Grundmann

Post by Joern Bredereck
Es ist ein proprietäres Protokoll, dass unter der Kontrolle einer
einzigen Firma steht. Das willst du doch wohl nicht ernsthaft mit einem
freien Industrie-Standard wie (i)SCSI vergleichen, oder?

Was ist denn mit smb/cifs - wer hats erfunden? Die könnten das doch auch
in die Tonne kloppen. Hier wird über ungelegte Eier geredet - wer kommt
denn nur auf die Idee zu sagen, dass Apple AFP einstampfen wird.
Was in den nächsten zwei Jahren nicht geplant ist, interessiert mich
heute null und nix - da habe ich später noch zeit.

Das ist richtig. Aber darauf wollte ich nicht hinaus. Im aktuellen Fall
ging es darum, dass iSCSI eine valide Alternative darstellt, die eben
von Apples Entscheidungen zunächst mal vollkommen unabhängig ist.

ich seh das einfach ganz pragmatisch: Apple setzt plötzlich neu
AFP-Features voraus, die die meisten NAS nicht mibringen. Ergo: Wenn man
ein Backup-Konzept auf dieser Basis eingesetzt hat, ist man erstmal
angeschmiert und muss über's Apple's Stöckchen springen, damit's wieder
funktiniert (AFP auf NAS-Seite upgraden).

Nimmt man hingegen iSCSI als offene Alternative zu AFP ist man von
Apple's Entscheidungen weitestgehend unabhängig und muss über keine
Stöckchen springen. Die Unabhängigkeit sehe ich einfach als Vorteil. YMMV.

VG,

Jörn

[Andreas Berger]

Am 10.08.2011 10:20 schrieb Patrick M. Hausen:
[iSCSI]

Post by Patrick M. Hausen
Und mit Netatalk und ZFS auf dem FreeNAS bekomme ich das
Sparse-Image zur Not in 5 Jahren manuell auf eine USB/Thunderbolt-Platte
kopiert, die direkt am Mac angeschlossen, und die Daten da irgendwie
wieder raus ... sollte Apple AFP killen oder so modifizieren, dass
Netatalk nicht hinterher kommt, oder ...

Hm, da habe ich iSCSI falsch verstanden. In meiner Umgebung stellt das
NAS einfach nur ein tumbes device (file image) zur Verfügung, das ich
dann per Festplattentool formatiere, auf was auch immer.
Dazu brauchts kein Netatalk. Und, falls ich das richtig kapiert habe,
kann ich das iSCSI-device ganz normal auf eine normale Platte dd'en, die
ich dann mit was auch immer (USB/FW/Thunderbolt) an den Mac hänge.
An dem Punkt sind wir noch gar nicht beim filesystem und wie das evtl.
zu interpretieren wäre.

[Joern Bredereck]

Post by Andreas Berger
[iSCSI]

Post by Patrick M. Hausen
Und mit Netatalk und ZFS auf dem FreeNAS bekomme ich das
Sparse-Image zur Not in 5 Jahren manuell auf eine USB/Thunderbolt-Platte
kopiert, die direkt am Mac angeschlossen, und die Daten da irgendwie
wieder raus ... sollte Apple AFP killen oder so modifizieren, dass
Netatalk nicht hinterher kommt, oder ...

Hm, da habe ich iSCSI falsch verstanden.

Nein, hast du nicht.

Post by Andreas Berger
In meiner Umgebung stellt das
NAS einfach nur ein tumbes device (file image) zur Verfügung, das ich
dann per Festplattentool formatiere, auf was auch immer.
Dazu brauchts kein Netatalk. Und, falls ich das richtig kapiert habe,
kann ich das iSCSI-device ganz normal auf eine normale Platte dd'en, die
ich dann mit was auch immer (USB/FW/Thunderbolt) an den Mac hänge.
An dem Punkt sind wir noch gar nicht beim filesystem und wie das evtl.
zu interpretieren wäre.

vollkommen korrekt. iSCSI exportiert den Festplatten-Platz auf
Block-Ebene und nicht auf Filesystem-Ebene. Das nimmt eine ganze Menge
Komplexität raus und ist für Ziele, auf die sowieso immer nur ein
Rechner gleichzeitig zugreifen soll, ideal. Filesharing-Protokolle wie
AFP oder SMB/CIFS machen eigentlich erst dann Sinn, wenn mehrere Rechner
gleichzeitig auf Datei-Ebene auf irgendwelche Daten zugreifen sollen.
Für ein Time-Machine-Backup verkomplizieren die hierfür notwendige
Locking-Mechanismen und der Dateisystem-Overhead (ACLs, Datei-Attribute
etc...) das ganze nur unnötig.

[Robert Welz]

Wenn TimeMachine die Backups eh auf 'nem SparseImage sichert, warum
nicht NFS als Protokoll ? Wo ist da der Unterschied (für TimeMachine)?

Robert

[Thomas Kaiser]

Post by Robert Welz
Wenn TimeMachine die Backups eh auf 'nem SparseImage sichert, warum
nicht NFS als Protokoll ? Wo ist da der Unterschied (für TimeMachine)?

Hatten wir hier vor einem Jahr IIRC in epischer Breite, beteiligt war
einer der aktuellen Thread Mitspieler (Joern). Einfach bei
groups.google.com danach suchen. Und ebenfalls nach "AFP 3.3" und
"Reply Cache" googlen.

Oder gleich hier lesen:

http://www.netafp.com/tn002-time-machine-warning-79/

Der Artikel bezieht sich auf ältere Netatalk-Releases. Ein _aktuelles_,
d.h. Netatalk 2.2.0, hat den Reply Cache implementiert, das andere
Feature, "TM Lock Stealing", ist nur für Apples eigene AFP-Server-
Implementierung wichtig (weil Apple ja nach wie vor alle AFP-
Verbindungen mit einem einzigen Prozeß auf Serverseite abfeiert).

Gruss,

Thomas