Aufwandsabschaetzung User Homedirs zentral auf Server
Thomas Kaiser
aktuell beschäftigt mich grad die Anfrage eines Kunden, der aus gegebenem
Anlaß (ja, das häßliche Wort Datenverlust schwebt irgendwo im Raum) darüber
nachdenkt, für 30 User mit geschätztem Aufkommen von ca. 10 GByte pro Nase
die Homedirs auf einen Server legen möchte. Es sind ausschließlich
Mac-Clients, um die es geht. Diese sind auch schon alle auf einer Sun mit
EtherShare als Benutzer eingerichtet.
Mein Ziel bei der Realisierung wäre natürlich eine von der Administration
her streßfreie Lösung (die Admins vor Ort sollten sich nicht bis ins letzte
Detail mit dem Kram auskennen müssen) und -- wenn möglich -- ein Hauch von
"Single Sign Logon", also daß die Autentifizierung gegen eine zentrale
Instanz läuft.
Als Alternativen böten sich nach meinem aktuellen Kenntnisstand an:
1) Xserve + MacOS X Server unlimited. Fällt von der Investitionssumme bei
der spezifischen Ausbaustufe (500 Gbyte RAID netto, 2 CPUs, 4 Gbyte RAM,
Ersatzteilpackerl im Schrank) mit ca. 7.000,- Euronen aus.
- Mit wieviel Aufwand ist zu rechnen, den Server jetzt so aufzusetzen,
daß die Clients ihre Homedirs auf dem Server liegen haben (Hint:
Datenmigration und so Kram dürfte weniger das Problem sein. Rudimentäre
Skriptingkenntnisse sind vorhanden ;-)
- Wie könnte man das Ganze mit dem EtherShare Server verheiraten?
Hauptproblem: Im Moment (der angekündigte Authentifizierungsserver von
Helios ist ohne Releasetermin noch nicht direkter Gegenstand meiner
Überlegungen) unterstützt Helios nur NIS für zentrale
Authentifizierung. Kann MacOS X Server damit als Client oder als Server
umgehen?
2) NIS/Netatalk Gespann. Investitionskosten beschränken sich rein auf die
Hardware, da der ganze Rest OSS ist. Wenn man passend einkauft, bekommt
man ein zum Xserve 1:1 vergleichbares Gerät für ca. die Hälfte (ja, inkl.
3 Jahre vor Ort Garantie mit kurzen Reaktionszeiten!)
Daß NIS wegen der Integration mit EtherShare praktisch wäre, ist eh klar.
Daß insgesamt der Aufwand, den ganzen Kram einzurichten, _vermutlich_
höher ausfallen wird, ebenfalls.
Fallen irgendwem hier spezifische Stolpersteine ein, die es bei der
Konstellation geben könnte?
3) ?
Eine andere Alternative wäre, das Ganze die Sun mitmachen zu lassen, auf der
ja mit EtherShare und NIS eigentlich alles bereitstehen würde. Ich befürchte
aber an der Stelle etwaige Last- bzw. eher Durchsatzprobleme... Und ein
wirklicher Kostenvorteil will sich nicht auf den ersten Blick erschließen,
da die 500 GByte Plattenplatz ja auch irgendwoher kommen wollen und in Form
eines externen ATA-RAIDs nicht wesentlich günstiger ausfallen als eine
dedizierte Serverlösung für den Zweck...
Würde mich über ein paar Anmerkungen, konkrete Tipps, Zweifel oder allgemein
Ideen/Denkanstösse freuen.
Danke und Gruss,
Thomas
Markus Hippeli
> Als Alternativen böten sich nach meinem aktuellen Kenntnisstand an:
>
> 1) Xserve + MacOS X Server unlimited. Fällt von der Investitionssumme bei
> der spezifischen Ausbaustufe (500 Gbyte RAID netto, 2 CPUs, 4 Gbyte RAM,
> Ersatzteilpackerl im Schrank) mit ca. 7.000,- Euronen aus.
>
> - Mit wieviel Aufwand ist zu rechnen, den Server jetzt so aufzusetzen,
> daß die Clients ihre Homedirs auf dem Server liegen haben
Der Aufwand für die Einrichtung hält sich in Grenzen, via Open Directory
funktioniert das Single Sign Logon ganz brauchbar, Homedirectories auf
dem Server (oder einem anderen) sind damit kein Problem sondern eher
Standard. Allerdings gibt es - wie immer - ein paar Fußangeln zu
beachten:
- Der Server sollte direkt beim Installieren als Open Directory Master
eingerichtet werden, versucht man das nachträglich passieren häufig
eklige Dinge oder es funktioniert schlicht nicht (siehe Apple Server
Board) oder man ist als Administrator schlicht aus der Open Directory
ausgesperrt und kann sie nicht verwalten (auch sehr nett). Ein
funktionierender DNS ist Pflicht.
<http://discussions.info.apple.com/webx?1...@104.figAaNJEkLG.5@.599c058d>
- Kerberos reagiert bissig, wenn Die Systemzeit von Client und Server
abweicht, was ein erfolgreiches Einloggen verhindert, daher ist ein
Timeserver Pflicht. Der Realm muss per Hand eingerichtet werden auf den
Clients - Anleitungen dafür finden sich via Google.
<http://www.afp548.com/Articles/Panther/kerberos1.html>
<http://www.afp548.com/Articles/Panther/kerberos2.html>
<http://alcor.concordia.ca/~peter/MacPage.html>
- Die spezifischen Ideen von Apple was Gruppenverzeichnisse und
dergleichen angeht sollte man im Hinterkopf haben. Muss man nicht
verwenden, macht es aber unter Umständen einfacher - oder auch das
Gegenteil.
- Die Möglichkeit die Clients zu verwalten was das Unterschieben von
Shares beim Anmelden angeht oder Dockicons oder oder oder ist recht nett
und in meinen Augen ein Pluspunkt, wenn man sowas braucht.
- Es empfiehlt sich in jedem Fall die pdfs von Apple zum Thema Open
Directory zumindest zu überfliegen (und idealiter die restlichen pdf's
zum Server auch - reichlich Lesestoff) und das Geplante in einer
Testumgebung mal zurechtzubasteln und vor allem ein paar Tage komische
Sachen damit zu machen. Bis ins Letzte transparent und vertrauenswürdig
kommt mir das noch nicht vor, das mag aber auch an meiner noch
begrenzten Erfahrung mit OS X Server liegen.
- Die Administration über die Servertools ist begrenzt witzig, die
Möglichkeiten sind an verschiedenen Stellen limitiert und dann muss halt
doch wieder ssh herhalten. Auch was solche Dinge wie einrichten von
Shares etc. angeht ist IMHO die Klickorgie bei den Servertools deutlich
nerviger als vergleichbares via Shell bei der Konkurrenz. Dafür ist ein
einfacher Nameserver recht unkompliziert einzurichten, immerhin. ;-)
> - Wie könnte man das Ganze mit dem EtherShare Server verheiraten?
> Hauptproblem: Im Moment (der angekündigte Authentifizierungsserver von
> Helios ist ohne Releasetermin noch nicht direkter Gegenstand meiner
> Überlegungen) unterstützt Helios nur NIS für zentrale
> Authentifizierung. Kann MacOS X Server damit als Client oder als Server
> umgehen?
Ich würde vermuten, daß die Variante OS X Server mit Open Directory als
Auth-Server und die Sun als Client am ehesten funktionieren sollte.
Keine praktische Erfahrung bisher.
> Eine andere Alternative wäre, das Ganze die Sun mitmachen zu lassen, auf der
> ja mit EtherShare und NIS eigentlich alles bereitstehen würde. Ich befürchte
> aber an der Stelle etwaige Last- bzw. eher Durchsatzprobleme...
Bei 30x 10GB-Homes würde ich Dir da gefühlsmäßig zustimmen.
> wirklicher Kostenvorteil will sich nicht auf den ersten Blick erschließen,
> da die 500 GByte Plattenplatz ja auch irgendwoher kommen wollen und in Form
> eines externen ATA-RAIDs nicht wesentlich günstiger ausfallen als eine
> dedizierte Serverlösung für den Zweck...
Wie sieht es mit Backup aus?
> Würde mich über ein paar Anmerkungen, konkrete Tipps, Zweifel oder allgemein
> Ideen/Denkanstösse freuen.
Grundsätzlich tut der Panther Server recht schön, wenn er erst mal in
der gewünschten Konfiguration läuft. Der Aufwand zur Einrichtung ist
nicht zu vernachlässigen, sprich: wenn man nur mal eben ein paar Shares
und einen Printserver haben will ist man je nach Erfahrung mit einem
Linux und Netatalk/Samba/etc. schneller am Ziel. In dem Moment wo Single
Sign On ins Spiel kommt und heterogene Umgebungen wird es wieder
interessant, weil man den ganzen LDAP- und Kerberoskram quasi
automatisch mitgeliefert bekommt und das mehr oder weniger out of the
Box funktioniert wenn man nicht vorher in irgendeine Falle tappt.
Wirklich viel Erfahrung (insbsondere Langzeiterfahrung) mit dem
Panther-Server hab ich nicht, aber von der Tendenz her ist das Ding eher
für grössere Netze mit Replikation und Pipapo geeignet und weniger dazu,
mal eben einen Server aufzustellen für ein kleines Netz. Durch LDAP und
Kerberos hat man offene Standards und kann die Kiste mit allem möglichen
verheiraten. Performant ist das Teil hinreichend IMHO
Was die Administration angeht ist OS X Server sicherlich auf den ersten
Blick recht freundlich, sprich vergleichsweise Daukompatibel -
allerdings täuscht dieser Eindruck etwas - kein Vergleich mit AppleShare
IP oder so. OS X Server ist anders als OS X und wie oft in den letzten
Jahren hat Apple mal wieder einen Haufen OpenSource und anderen Kram
genommen, zu einem eigenen Destillat verwurstet und recht spezifische
Vorstellungen davon, wie das dann heisst und wie man damit umgehen soll
- da muss man sich doch erst mal reindenken. Ein wenig Einarbeitung
seitens des Admins ist also gefragt.
cu
Markus
Markus Hippeli
> Als Alternativen böten sich nach meinem aktuellen Kenntnisstand an:
>
> 1) Xserve + MacOS X Server unlimited. Fällt von der Investitionssumme bei
> der spezifischen Ausbaustufe (500 Gbyte RAID netto, 2 CPUs, 4 Gbyte RAM,
> Ersatzteilpackerl im Schrank) mit ca. 7.000,- Euronen aus.
>
> - Mit wieviel Aufwand ist zu rechnen, den Server jetzt so aufzusetzen,
> daß die Clients ihre Homedirs auf dem Server liegen haben
Der Aufwand für die Einrichtung hält sich in Grenzen, via Open Directory
<http://discussions.info.apple.com/webx?1...@104.figAaNJEkLG.5@.599c058d>
begrenzten Erfahrung mit OS X Server liegen. Ich habe allereings den
EIndruck, dass man sich recht einfach vergallopieren kann und dann mit
etwas Pech von vorne anfangen muss, weil der Weg zurück verbaut ist -
also hinreichend Zeit für Planung und Tests vorsehen.
- Die Administration über die Servertools ist begrenzt witzig, die
Möglichkeiten sind an verschiedenen Stellen limitiert und dann muss halt
doch wieder ssh herhalten. Auch was solche Dinge wie einrichten von
Shares etc. angeht ist IMHO die Klickorgie bei den Servertools deutlich
nerviger als vergleichbares via Shell bei der Konkurrenz. Dafür ist ein
einfacher Nameserver recht unkompliziert einzurichten, immerhin. ;-)
> - Wie könnte man das Ganze mit dem EtherShare Server verheiraten?
> Hauptproblem: Im Moment (der angekündigte Authentifizierungsserver von
> Helios ist ohne Releasetermin noch nicht direkter Gegenstand meiner
> Überlegungen) unterstützt Helios nur NIS für zentrale
> Authentifizierung. Kann MacOS X Server damit als Client oder als Server
> umgehen?
Ich würde vermuten, daß die Variante OS X Server mit Open Directory als
Auth-Server und die Sun als Client am ehesten funktionieren sollte.
Keine praktische Erfahrung bisher.
> Eine andere Alternative wäre, das Ganze die Sun mitmachen zu lassen, auf der
> ja mit EtherShare und NIS eigentlich alles bereitstehen würde. Ich befürchte
> aber an der Stelle etwaige Last- bzw. eher Durchsatzprobleme...
Bei 30x 10GB-Homes würde ich Dir da gefühlsmäßig zustimmen.
> wirklicher Kostenvorteil will sich nicht auf den ersten Blick erschließen,
> da die 500 GByte Plattenplatz ja auch irgendwoher kommen wollen und in Form
> eines externen ATA-RAIDs nicht wesentlich günstiger ausfallen als eine
> dedizierte Serverlösung für den Zweck...
Wie sieht es mit Backup aus?
> Würde mich über ein paar Anmerkungen, konkrete Tipps, Zweifel oder allgemein
> Ideen/Denkanstösse freuen.
Grundsätzlich tut der Panther Server recht schön, wenn er erst mal in
cu
Markus (superseedend)
Dominik Schlütter
Thomas Kaiser <Thomas...@phg-online.de> schrieb:
> - Mit wieviel Aufwand ist zu rechnen, den Server jetzt so aufzusetzen,
> daß die Clients ihre Homedirs auf dem Server liegen haben (Hint:
> Datenmigration und so Kram dürfte weniger das Problem sein. Rudimentäre
> Skriptingkenntnisse sind vorhanden ;-)
Das ist mit MacOS X Server eigentlich kein Problem, da Apple zwar
manchmal eigene Vorstellungen zum verwendeten LDAP-Schema hat, das aber
natürlich beim MacOS X Server alles schon fertig mitliefert (naja,
Zertifikate muss man sich noch selbst bauen %-).
> - Wie könnte man das Ganze mit dem EtherShare Server verheiraten?
> Hauptproblem: Im Moment (der angekündigte Authentifizierungsserver von
> Helios ist ohne Releasetermin noch nicht direkter Gegenstand meiner
> Überlegungen) unterstützt Helios nur NIS für zentrale
> Authentifizierung. Kann MacOS X Server damit als Client oder als Server
> umgehen?
Seit Panther wird auch NIS wieder "ab Werk" unterstützt. Prinzipiell
kann man natürlich Authentifizierung und Homeverzeichnisse/Mountpoints
trennen. Wenn man LDAP benutzt, kann man das auch alles am Server
konfigurieren und die Clients bekommen bei der Anmeldung einen Hinweis,
wo sie nach dem Home-Verzeichnis suchen sollen (bzw. mit welchen
Mappings sie die restlichen Daten vom LDAP-Server bekommen).
> 2) NIS/Netatalk Gespann. Investitionskosten beschränken sich rein auf die
> Hardware, da der ganze Rest OSS ist. Wenn man passend einkauft, bekommt
> man ein zum Xserve 1:1 vergleichbares Gerät für ca. die Hälfte (ja, inkl.
> 3 Jahre vor Ort Garantie mit kurzen Reaktionszeiten!)
Wenn du so eine Lösung aufsetzen willst, würde ich nach Möglichkeit LDAP
verwenden. Das macht nicht nur so nette Dinge wie Kerberos in der
Integration einfacher, zusätzlich gibt es dazu eine Menge Infos im Netz
- und vor allem kann man sich so einfach Apples Lösung nachbauen.
Es gibt im Netz ein paar Anlaufstellen für LDAP-Authetifizierung gegen
"nicht-Apple" Server, beispielsweise
<http://www.macosxlabs.org/documentation/auth_and_ds/auth_and_ds.html>,
eventuell ist auch Apples Dokumentation zu MacOS X Server noch
hilfreich.
> Daß NIS wegen der Integration mit EtherShare praktisch wäre, ist eh klar.
> Daß insgesamt der Aufwand, den ganzen Kram einzurichten, _vermutlich_
> höher ausfallen wird, ebenfalls.
Ich mag NIS nicht und kenne mich damit nicht sonderlich aus (aber das
sind bloss Vorurteile). Das Problem ist IMHO vor allem, dass Apple NIS
ebenfalls nicht für sonderlich relevant hält (unter Jaguar ging es
beispielsweise nicht, momentan unter Panther anscheinend wohl - wenn
auch mit Stolpersteinen z.B. beim "automounter").
<http://www.bresink.de/osx/nis-de.html> kennst du ja vermutlich schon.
> Eine andere Alternative wäre, das Ganze die Sun mitmachen zu lassen, auf der
> ja mit EtherShare und NIS eigentlich alles bereitstehen würde. Ich befürchte
> aber an der Stelle etwaige Last- bzw. eher Durchsatzprobleme...
Naja, bei Netzwerk-Homeverzeichnissen geht Apple IMHO recht
verschwenderisch mit der Netzwerkbandbreite um, vor allem sind die
Lastszenarien andere als beim typischen Umgang mit großen
Print-/Repro-/wasauchimmer-Dateien. Schliesslich wird jetzt jede
fitzelige Pref-Datei vom Server geöffnet ... .
Gruß,
Dominik.
Alexander Barton
> 1) Xserve + MacOS X Server unlimited. Fällt von der Investitionssumme bei
> der spezifischen Ausbaustufe (500 Gbyte RAID netto, 2 CPUs, 4 Gbyte RAM,
> Ersatzteilpackerl im Schrank) mit ca. 7.000,- Euronen aus.
>
> - Mit wieviel Aufwand ist zu rechnen, den Server jetzt so aufzusetzen,
> daß die Clients ihre Homedirs auf dem Server liegen haben (Hint:
> Datenmigration und so Kram dürfte weniger das Problem sein. Rudimentäre
> Skriptingkenntnisse sind vorhanden ;-)
Das Einrichten von Benutzern mit serverseitigen Benutzerordnern ist
unter Mac OS X Server kein problem, das lässt sich sehr einfach über den
"Arbeitsgruppenmanager" konfigurieren. Die Clients beziehen ihre
Weisheit dann über NetInfo. Clients in eine solche NetInfo-Domain
einzubinden ist ebenfalls in wenigen Minuten mit dem
"Verzeichnisdienste"-Dienstprogramm erledigt.
Ein solches Scenario (Mac OS X 10.2.6 Server, Panther-Clients) haben wir
hier bei einem Kunden laufen.
> - Wie könnte man das Ganze mit dem EtherShare Server verheiraten?
Bessere Frage, EtherShare kenne ich nicht wirklich.
> Hauptproblem: Im Moment (der angekündigte Authentifizierungsserver von
> Helios ist ohne Releasetermin noch nicht direkter Gegenstand meiner
> Überlegungen) unterstützt Helios nur NIS für zentrale
> Authentifizierung. Kann MacOS X Server damit als Client oder als Server
> umgehen?
Mac OS X unterstützt als Client NIS problemlos. Als Server wohl nicht.
Ich habe schon einige Zeit vor Netatalk als AFP-Server anstelle von NFS
zu testen. Bisher habe ich mich allerdings noch nicht getraut ;-)
Grüße
Alex
>
Thomas Kaiser
<news:1gd0b5o.51r90e1dumlxcN%markus...@gmx.de>:
> Wie sieht es mit Backup aus?
Da gibt es leichte Kapazitätsprobleme, so daß eine wöchentliche oder
monatliche Sicherung der Homes auf Tape via AIT-3 Jukebox angedacht ist.
Für den "Huch, wo ist die Datei denn nun hin? Habe ich sie etwa gelöscht"
Fall würde ich dann noch einen Mechanismus einbauen, der -- wenn MacOS X zum
Einsatz kommen sollte -- wohl auf ein komprimiertes Disk-Image hinausläuft,
daß den Leuten als "Gestern.dmg" in ihr Home gelegt wird. Wenn es eine
Netatalk-Lösung werden sollte, dann dito komprimiertes Image, das einfach
als separater Sharepoint je User eingehängt wird (genauso simpel zu
realisieren)
Das ist alles von dem Anspruch "tagesaktuelles Backup" etwas entfernt aber
per Definition haben wichtige Daten sowieso auf dem zentralen EtherShare-
Server zu liegen, so daß sich der Schaden also in Grenzen hält. Ich denke,
das entspringt eher der Philosophie des Kunden, den Leuten dort ein
angenehmes Arbeitsklime zu schaffen, indem sie eben auch selbständig und
ohne größere Einschränkungen aber eben doch mit ein bisserl Absicherung
"Eigene Dateien" ablegen können sollen.
Man könnte das wohl auch auf die herrische Tour regeln (Speicherverbot für
Privatdaten, IMAP und Mailquota würden wohl reichen) aber das halte ich
ebenfalls für keine gute Idee in Hinblick auf die Zufriedenheit der Leute.
An der Stelle erstmal Danke auch an die anderen, die bisher etwas zur
Entscheidungsfindung beigetragen haben. Die Links kannte ich partiell schon,
werde mir jetzt wohl mal etwas exakter NIS und Sharepoints per AFP 3.1
anschauen (d.h. wohl einfach mal einen Test machen -- das letzte mal vor ca.
15 Monaten, als wir das hier diskutiert hatten, war das Ganze relativ flott
erledigt... freilich ohne NIS).
Interessant fand ich die Aussagen zum Aufwand, das Ganze mit MacOS X Server
einzurichten. Wenn ich hier 2 Tage veranschlagen müsste (inkl. Verdauen der
Apple-Literatur) und parallel weitere interessante Features, die mit der
Lösung zur Verfügung stünden, sowieso nicht genutzt würden, dann scheidet
für mich diese Lösung unter wirtschaftlichen Gesichtspunkten auf den ersten
Blick schonmal aus.
Naja, wir werden sehen, wie aufwändig das mit NIS (Ein Muß in dem Szenarium
wegen EtherShare) wird. Ich werde hier berichten und freue mich einstweilen
über weitere Anregungen.
Danke und Gruss,
Thomas
Yann Borg
BCB68DCE.3C708%Thomas...@phg-online.de:
> aktuell beschäftigt mich grad die Anfrage eines Kunden, der aus gegebenem
> Anlaß (ja, das häßliche Wort Datenverlust schwebt irgendwo im Raum) darüber
> nachdenkt, für 30 User mit geschätztem Aufkommen von ca. 10 GByte pro Nase
> die Homedirs auf einen Server legen möchte.
Mich würde interessieren wie Weit eine solche Lösung eingesetzt werden
könnte. Wenn man schon die Homedirs zentral gesichert hat warum den nicht
weitere Verzeichnisse und Einstellungen mit nehmen? Ich denke z.B. an das
Applications Verzeichnis oder an angelegte Netzwerkdrucker.
Und wenn man schon so weit geht und 30 Macs mit MacOS X im Einsatz hat,
warum den nicht gleich an Netboot denken? Zuviel Traffic? Erzeugt einer mit
Netboot bereits gestarteter Rechner deutlich mehr Netzwerk-Traffic als ein
Rechner der nur sein Homedir vom Server holt?
Was würde passieren wenn auf den Clientrechner die Systemsoftware
aktualisiert wird? Werden eventuell auch bei einer Aktualisierung Dinge im
Homeverzeichnis aktualisiert? Dann hätte man plötzlich einen 10.3.3 Homedir
was auf einen 10.3.4 System läuft. Bedenken? Mir fällt spontan der Fall ein
(zugegeben, bei einer Grundlegende Aktualisierung der Systemsoftware, die
nun mal aber trotzdem in relativ kurze Intervalle, 18 Monate, stattfindet)
bei der Aktualisierung von 10.2.x auf 10.3.x wo es plötzlich nicht mehr
möglich war ein User "admin" anzulegen, weil es vermutlich in 10.3
reserviert ist.
Und zu guter Letzt: Wenn über Datenverlust, bzw. Datensicherheit gesprochen
wird, warum nicht auch parallel zu der zentralen Datensicherung die Homedirs
zusätzlich auf die Client-Rechner kopieren? Beim Ausschalten der
Clientrechner könnte ein Sync mit dem Userverzeichnis des zuletzt
eingelogtem Benutzer gestartet werden. Das hätte als netter Nebeneffekt,
dass ein Client auch ohne Netzwerkverbindung in bekannter Umgebung starten
könnte.
Meinungen?
Danke und Gruss,
Yann
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Mein Ziel bei der Realisierung wäre natürlich eine von der Administration
> her streßfreie Lösung (die Admins vor Ort sollten sich nicht bis ins letzte
> Detail mit dem Kram auskennen müssen) und -- wenn möglich -- ein Hauch von
> "Single Sign Logon", also daß die Autentifizierung gegen eine zentrale
> Instanz läuft.
Ich habe hier die Combo NIS/NFS mit Home auf dem FreeBSD-Server
am laufen. Folgendes gibt es dazu zu sagen:
Die Einbindung ist mit der Anleitung von Marcel Bresink ein
Klacks. Fuer die Erweiterung des YP-Makefiles um eine Automounter-Map
solte man wissen, was man tut - wirklich kompliziert ist es nicht.
In dieser Variante flitzen die Passwoerter zwar nicht im Klartext
durch die Gegend aber die Hashes aus der passwd Map werden ueber's
Netz geschickt und sind offen fuer Brute Force oder Dictionary Attacks.
Das Home per NFS funktioniert zunaechst mal einwandfrei. Alle Cocoa-
Applikationen, die ich in die Finger bekommen habe, legen ihre
Resource Forks brav in den bekannten "._" Dateien ab.
Manche Carbon-Anwendungen auch. Anderes, aelteres Zeug spinnt total,
wenn das Home nicht auf HFS+ liegt. Palm Desktop z.B.
Frage an die Source Code Leser ;-) Warum ist das so? Welches API
verwendet Software A, sodass der "._" Trick nicht transparent 2 Ebenen
unter der Applikation erledigt wird, im Gegensatz zu Software B, die
von NFS, SMBFS, ... nichts mitbekommt und einfach gluecklich ist?
Locking funktioniert mit FreeBSD 5.x. D.h. man kann auf FreeBSD den
rpc.lockd und rpc.statd anwerfen und der Panther-NFS-Client freut sich.
Allerdings semmelt mir der rpc.lockd ca. einmal pro Arbeitstag
mit einem Core Dump ab. Und dann _steht_ der Client-Mac unerklaerlich.
D.h. er reagiert schon noch irgendwie, nur eine Menge Anwendungen
"haengen". Ich habe daher Locking bei mir auf dem Client deaktiviert.
Ist der einzige Rechner, der per NFS auf mein Home zugreift ;-)
Performance: keine Probleme.
Im Gegensatz zu NFS funktioniert NIS allerdings sowas von tadellos,
dass man sogar aufpassen muss, keine Gruppe namens "admin" in der
NIS-Domain zu haben. Deren Mitglieder sind vollautomatisch Administrator
auf dem Mac. ;-)
Gruss,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe http://punkt.de
Thomas Kaiser
<news:4096...@news.punkt.de>:
> Die Einbindung ist mit der Anleitung von Marcel Bresink ein
> Klacks. Fuer die Erweiterung des YP-Makefiles um eine Automounter-Map
> solte man wissen, was man tut - wirklich kompliziert ist es nicht.
Gut zu hören. Für mich weiterhin interessant, wie die relevanten Anpassungen
aussehen, um das Ganze ohne NFS aber mit AFP zu machen :-)
> In dieser Variante flitzen die Passwoerter zwar nicht im Klartext
> durch die Gegend aber die Hashes aus der passwd Map werden ueber's
> Netz geschickt und sind offen fuer Brute Force oder Dictionary Attacks.
Tja, ist ja schon mal was. Ich war neulich in einem Laden, in dem Single
Sign Logon gefeiert wurde und unter anderem auch POP3 in der Standard-
Variante mit im Spiel war ;-)
> Das Home per NFS funktioniert zunaechst mal einwandfrei. Alle Cocoa-
> Applikationen, die ich in die Finger bekommen habe, legen ihre
> Resource Forks brav in den bekannten "._" Dateien ab.
Die sind halt insofern nur eine billige Notlösung, als sie gerade mal einen
Teil der "klassischen" Mac-Metadaten unterbringen können und dann halt noch
die Resourcefork.
> Manche Carbon-Anwendungen auch. Anderes, aelteres Zeug spinnt total,
> wenn das Home nicht auf HFS+ liegt. Palm Desktop z.B.
Word wahrscheinlich ebenso...
> Frage an die Source Code Leser ;-) Warum ist das so? Welches API
> verwendet Software A, sodass der "._" Trick nicht transparent 2 Ebenen
> unter der Applikation erledigt wird, im Gegensatz zu Software B, die
> von NFS, SMBFS, ... nichts mitbekommt und einfach gluecklich ist?
A benutzt bspw. einen FPExchangeFiles Call (dabei wird beim Sichern einer
Datei einfach eine neue neben die alte gelegt und anschließend per
FPExchange Call die IDs beider Dateien getauscht und schließlich die alte
weggeschmissen). Und wo kein Dateisystem, das mit IDs umgehen muß, da fliegt
eben erstmal alles auf die Schnauze, was auf IDs angewiesen ist (außer man
bastelt halt Datenbank-Lösungen, die oberhalb des Dateisystems operieren,
wie bspw. bei Helios oder Netatalk).
Kann man auch nachvollziehen, indem man einen Mac per AFP (an sich ID-fähig)
eine UFS-Partition freigeben läßt. Da funktioniert sowas genausowenig wie
per NFS...
Hatten wir aber erst neulich in einem Seitenarm dieses Thread, wenn ich mich
recht entsinne...
> Locking funktioniert mit FreeBSD 5.x. D.h. man kann auf FreeBSD den
> rpc.lockd und rpc.statd anwerfen und der Panther-NFS-Client freut sich.
> Allerdings semmelt mir der rpc.lockd ca. einmal pro Arbeitstag
> mit einem Core Dump ab. Und dann _steht_ der Client-Mac unerklaerlich.
> D.h. er reagiert schon noch irgendwie, nur eine Menge Anwendungen
> "haengen". Ich habe daher Locking bei mir auf dem Client deaktiviert.
> Ist der einzige Rechner, der per NFS auf mein Home zugreift ;-)
Hu? Seltsame Definition von "funktioniert" ;-)
Danke erstmal für die Infos...
Gruss,
Thomas
Dominik Schlütter
Thomas Kaiser <Thomas...@phg-online.de> schrieb:
> Tja, ist ja schon mal was. Ich war neulich in einem Laden, in dem Single
> Sign Logon gefeiert wurde und unter anderem auch POP3 in der Standard-
> Variante mit im Spiel war ;-)
Naja, man kann auch POP3 über Kerberos absichern (zu Kerberos generell
gibt es weitere Informationen beispielsweise unter
<http://www.busan.edu/~nic/networking/puis/ch19_06.htm>) - aber NIS hat
in diesem Zusammenhang diverse Probleme.
NIS+ <http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html> steht
etwas besser da, jenseits von SUN ist das aber kaum kaum verbreitet,
LDAP+Kerberos bietet da deutlich mehr Komfort und Unterstützung durch
das Betriebssystem (bzw. Apple in diesem Fall). Vielleicht hilft dir da
auch <http://www.padl.com/Products/NISLDAPGateway.html> weiter, das
erleichtert zumindest eine Migration in Richtung LDAP. Ansonsten beibt
IMHO die Aussage, dass man via LDAP bzw. SASL und Kerberos ducrchaus
eine "state of the art"-Sicherheit bekommen kann - wer experimentelle
Techniken ausprobieren will, der muss halt auch die Risiken entsprechend
evaluieren %-).
Gruß,
Dominik.
(... aus aktuellem Anlass "Grimbergen 'Optimo bruno'" empfehlend %-)
Stefan Wowereit
> 10.3.x wo es plötzlich nicht mehr
> möglich war ein User "admin" anzulegen, weil es vermutlich in 10.3
> reserviert ist.
Der erste Benutzer der angelegt wird darf admin heissen, spätere nicht
mehr (heute erst wieder gemacht).
--
Stefan Wowereit
http://www.wowereit.de
Markus Hippeli
> Mich würde interessieren wie Weit eine solche Lösung eingesetzt werden
> könnte. Wenn man schon die Homedirs zentral gesichert hat warum den nicht
> weitere Verzeichnisse und Einstellungen mit nehmen? Ich denke z.B. an das
> Applications Verzeichnis oder an angelegte Netzwerkdrucker.
Derlei Dinge gehen unter OS X Server - verwaltete Clients heisst das
Stichwort. Mehr als rumgepielt hab damit aber nicht bisher.
> Und zu guter Letzt: Wenn über Datenverlust, bzw. Datensicherheit gesprochen
> wird, warum nicht auch parallel zu der zentralen Datensicherung die Homedirs
> zusätzlich auf die Client-Rechner kopieren? Beim Ausschalten der
> Clientrechner könnte ein Sync mit dem Userverzeichnis des zuletzt
> eingelogtem Benutzer gestartet werden. Das hätte als netter Nebeneffekt,
> dass ein Client auch ohne Netzwerkverbindung in bekannter Umgebung starten
> könnte.
Das gibt es unter OS X Server unter dem Namen "ortsungebundene Clients",
ist ganz schnucklig für Powerbooks. Funktioniert so, daß das homdir auf
dem Server und lokal liegt und jeweils syncron gehalten wird. Sofern er
sich zuvor schon mal auf dieser Maschine am Netz angemeldet hatte kann
ein User auf einem Rechner, der im Arbeitsgruppen-Manager als
"ortsungebundener Client" definiert ist, sich auch dann anmelden, wenn
er nicht am Netz hängt und hat sein homedir lokal auf der Maschine. Beim
nächsten Amelden am Netzwerk werden dann die Daten mit dem homedir auf
dem Server gleichgeschaltet - soweit die Theorie. Nachteil: Die ganze
Geschichte funktioniert nicht mit file vault. Hat definitiv den Vorteil,
daß bei einem geklauten / kaputten Powerbook der Datenbestand zum
Zeitpunkt des letzten Netzzugriffs auf dem Server liegt und damit wohl
aktueller ist als das Backup, das bei mobilen Clienten bekanntlich oft
problematisch ist. In der Praxis hatte ich beim Rumspielen damit ein
paar Syncronisationsprobleme beim wechselweisen Anmelden an
verschiedenen Maschinen, denen ich aber noch nicht nachgegangen bin
bisher.
cu
Markus
Markus Hippeli
> Das ist genau der Muell, den Microsoft fuer eine Netzwerkumgebung
> haelt und der unter Windows schon nicht funktionert, weil mit
> serverbasierten Profilen der Anmeldevorgang eine Stunde dauert.
Nein, das ist was anderes. Unter OS X hat das Ganze den Zweck offline
arbeiten zu können unter Windows kann das anmelden mit dem lokalen
Profil anstelle des serverbasierten im schlimmsten Fall zu Ekligkeiten
führen und das lokale Profil ist nur ein echter Notnagel. Die Verwaltung
durch OS X Server finde ich da hübscher als in Windows - die
hinreichende Praxiserfahrung fehlt mir allerdings noch.
cu
Markus
Basar Alabay
> Das gibt es unter OS X Server unter dem Namen "ortsungebundene Clients",
> ist ganz schnucklig für Powerbooks.
Geht das auch mit OS X Nonserver?
Grüße
B. Alabay
.
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> > Frage an die Source Code Leser ;-) Warum ist das so? Welches API
> > verwendet Software A, sodass der "._" Trick nicht transparent 2 Ebenen
> > unter der Applikation erledigt wird, im Gegensatz zu Software B, die
> > von NFS, SMBFS, ... nichts mitbekommt und einfach gluecklich ist?
>
> A benutzt bspw. einen FPExchangeFiles Call (dabei wird beim Sichern einer
> Datei einfach eine neue neben die alte gelegt und anschließend per
> FPExchange Call die IDs beider Dateien getauscht und schließlich die alte
> weggeschmissen). Und wo kein Dateisystem, das mit IDs umgehen muß, da fliegt
> eben erstmal alles auf die Schnauze, was auf IDs angewiesen ist (außer man
> bastelt halt Datenbank-Lösungen, die oberhalb des Dateisystems operieren,
> wie bspw. bei Helios oder Netatalk).
Und genau das erwarte ich von Apple! Ein VFS-Layer, das die vollstaendige
Semantik bereitstellt. Helios und Netatalk beweisen schliesslich
tagtaeglich, dass es moeglich ist. Helios etwas besser, Netatalk
hinreichend gut.
Ich kenne die Problematik der Pesistent IDs aus der Netatalk-Diskussion
und weiss daher, dass es nicht trivial ist. Aber machbar ist es.
Ich war nach der Installation von X.1 schon fix und fertig, dass
die Classic-Umgebung Netzwerk-Volumes (SMB, NFS) nicht sieht.
Patrick M. Hausen
Markus Hippeli <markus...@gmx.de> wrote:
> Patrick M. Hausen <hau...@nospam.de> wrote:
>
> > Das ist genau der Muell, den Microsoft fuer eine Netzwerkumgebung
> > haelt und der unter Windows schon nicht funktionert, weil mit
> > serverbasierten Profilen der Anmeldevorgang eine Stunde dauert.
>
> Nein, das ist was anderes. Unter OS X hat das Ganze den Zweck offline
> arbeiten zu können
"Offline" und "Arbeiten" schliessen sich aus. Netz und Server sind
die Arbeitsumgebung, der Client sollte idealerweise in 5 Minuten
auszutauschen sein. Wenn ich sicher waere, dass Mac OS X koennte,
wuerde ich auch /Applications auf den Server schmeissen.
Gruss,
Patrick, zertifizierter Cisco und Sun Admin ;-)))
Thomas Kaiser
<news:4097...@news.punkt.de>:
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
[FPExchangeFiles Call]
>> dabei wird beim Sichern einer Datei einfach eine neue neben die alte gelegt
>> und anschließend per FPExchange Call die IDs beider Dateien getauscht und
>> schließlich die alte weggeschmissen). Und wo kein Dateisystem, das mit IDs
>> umgehen muß, da fliegt eben erstmal alles auf die Schnauze, was auf IDs
>> angewiesen ist (außer man bastelt halt Datenbank-Lösungen, die oberhalb des
>> Dateisystems operieren, wie bspw. bei Helios oder Netatalk).
>
> Und genau das erwarte ich von Apple! Ein VFS-Layer, das die vollstaendige
> Semantik bereitstellt.
Apple muß aber an der Stelle client-seitig ansetzen...
> Helios und Netatalk beweisen schliesslich tagtaeglich, dass es moeglich ist.
Die setzen wiederum serverseitig an.
> Helios etwas besser, Netatalk hinreichend gut.
He! ;-)
Die Datenbank-Implementierung von Netatalk braucht sich aus Entwicklersicht
nicht mehr wirklich vor der von Helios zu verstecken. Aus Anwendersicht
sieht das aber nochmals ganz anders aus -- zugegeben ;-)
> Ich kenne die Problematik der Pesistent IDs aus der Netatalk-Diskussion
> und weiss daher, dass es nicht trivial ist. Aber machbar ist es.
Nur wie?
Wenn das Dateisystem selbst nicht mit IDs aufwarten kann, muß man sie
irgendwoher nehmen. Wenn es persistent und vollwertig sein soll, dann kann
man mit vertretbarem Aufwand nur mit Datenbank-gestützten Lösungen
*serverseitig* an den Start gehen.
Alternativen?
Netatalk hatte bspw. mal ein Muster implementiert, das die Inodes des
darunter liegenden Dateisystems für die Implementierung der IDs heranzog.
Das hatte in Grenzen katastrophale Folgen, da Inodes nach dem Löschen
normalerweise sofort wieder recycelt werden und das in Verbindung mit
client-seitigem Caching der IDs bspw. durch den Finder dazu führt, daß auf
einmal Objekte falsch referenziert werden (Ach, war das spaßig, wenn nach
dem Papierkorb Entlehren auf einmal ein falscher Ordner samt Inhalt
(rekursiv natürlich) verschwunden war -- diese Semantik hat Netatalk-
Anwender nachweislich GByte-weise Datenverluste eingebracht).
Auch kommerzielle Hersteller setzen auf diese "Lösung": Xinet bspw.
generiert die IDs auch aus den Inodes und ist mit MacOS X Clients (der
Finder von MacOS X hängt sich weit mehr an IDs auf als noch der von MacOS 9)
erstmal baden gegangen, da eben permanent ID-Konflikte auftraten. Der
daraufhin an Kunden ausgelieferte AFP-ID Fix ist dann schon als wirklich
drollig anzusehen. Deren AFP-Server benutzt weiterhin die Inodes des
Dateisystems, verschiebt aber jetzt, um dem Inode-/ID-Recycling vorzubeugen,
Dateien in einen separaten Bereich je Dateisystem und setzt sie auf 0 Byte
anstatt sie zu löschen (warum sie Ordner nicht ebenso behandeln, bei denen
die Konsequenzen von ID-Konflikten weitaus drastischer sein könnten,
entzieht sich meiner Kenntnis). Dieser Bereich wird dann regelmäßig
aufgeräumt (aber bspw. nicht nach einem Neustart der Serverprozesse --
häßlich, wenn man ein bisserl testet und einem der AFP-Server alle Inodes
eines Dateisystems auf einen Schlag aufgefressen hat und man -- dank gewohnt
nebulöser "Informationspolitik" seitens Xinet -- keinen Schimmer hat, wo die
Inodes nun hin sind und nur noch "newfs" als passendes Werkzeug das Mittel
der Wahl erscheint ;-)
Das mag zwar helfen, ID-Konflikten durch zu schnelles Recyclen zuvorzukommen
ist aber weiterhin keine Lösung für echte persistente IDs.
> Ich war nach der Installation von X.1 schon fix und fertig, dass
> die Classic-Umgebung Netzwerk-Volumes (SMB, NFS) nicht sieht.
Naja, 10.1 konnte man ja auch nicht als in irgendeiner Weise fertig
betrachten. Aber ich bin ebenso gespannt, ob Apple es schafft, das Ganze
sauber von der VFS-Seite her anzugehen. Irgendwie ist es ja schon alles
reichlich undurchsichtig, was Apple so macht. Dateisysteme ohne ID-Support
als vollwertig unterstützt promoten, andererseits den Finder wieder heikler
hinsichtlich ID-Unterstützung zu machen. Offiziell Resourceforks als nicht
mehr gern gesehen darstellen aber zwischen 10.2 und 10.3 manche Bereiche
wieder auf Resourceforks umstellen...
Gruss,
Thomas
Dominik Schlütter
Markus Hippeli <markus...@gmx.de> schrieb:
> Das gibt es unter OS X Server unter dem Namen "ortsungebundene Clients",
> ist ganz schnucklig für Powerbooks. Funktioniert so, daß das homdir auf
> dem Server und lokal liegt und jeweils syncron gehalten wird.
Hmm - als ich mir das beim letzten Mal angeschaut habe, wurde da nix an
Daten synchronisiert, man hat plötzlich mehrere Home-Verzeichnisse auf
unterschiedlichen Maschinen (mit vermutlich unterschiedlichem Inhalt).
Wenn man da was synchronisieren will, muss man das AFAIK immer noch "von
Hand" nachbauen. So sthet das auch in
<http://docs.info.apple.com/article.html?artnum=107812>.
Gruß,
Dominik.
Noses
> > Und genau das erwarte ich von Apple! Ein VFS-Layer, das die
> > vollstaendige Semantik bereitstellt.
>
> Apple muß aber an der Stelle client-seitig ansetzen...
Verzeih, aber Du redest hier mit einem BSD-Benutzer.
Ein VFS-Layer ist ein Dateisystem, das sich nicht unbedingt auf ein echtes
device setzen muss, sondern damit zurechtkommt, dass die Ebene unter ihm
bestimmte rudimentaere Dienste ("hol mir dies, schreib mir jenes") liefern
kann. Ob dieses Teil nun Client eines ganz anderen Dienstes ist (bei Linux
beliebt sind beispielsweise remote block devices, etwas, bei dem es mir echt
gruselt, wenn ich an all die Dinge denke, an die die Erfinder nicht gedacht
haben - auch wenn sie schnell sind) oder auf einen (meinetwegen weiter
abstrahierten) device layer aufsetzen, ist komplett egal. Insofern koennte
man damit HFS+ auf NFS stapeln, ohne die Pfannkuchen zu verwuseln.
> Die Datenbank-Implementierung von Netatalk braucht sich aus Entwicklersicht
> nicht mehr wirklich vor der von Helios zu verstecken. Aus Anwendersicht
> sieht das aber nochmals ganz anders aus -- zugegeben ;-)
Was ist jetzt mit einem netatalk-Vortrag? *DRAENGEL* *QUENGEL*
Mir fällt ja nur kein Thema ein, sonst wuerde ich ja auch...
> Netatalk hatte bspw. mal ein Muster implementiert, das die Inodes des
> darunter liegenden Dateisystems für die Implementierung der IDs heranzog.
> Das hatte in Grenzen katastrophale Folgen, da Inodes nach dem Löschen
> normalerweise sofort wieder recycelt werden und das in Verbindung mit
> client-seitigem Caching der IDs bspw. durch den Finder dazu führt, daß auf
> einmal Objekte falsch referenziert werden
Denkfehler. inodes sind nicht einmal garantiert einzigartig - da können auch
mehrere Directory-Eintraege hinzeigen. Aber man koennte natuerlich einen
Hash ueber den Pfad als zusaetzliche Kollisionsvermeidung nehmen.
> (der Finder von MacOS X hängt sich weit mehr an IDs auf als noch der von
> MacOS 9)
Es ist wohl eher eine Folge des volfs...
Noses.
Thomas Kaiser
> Verzeih, aber Du redest hier mit einem BSD-Benutzer.
Na, und? :-)
> Ein VFS-Layer ist ein Dateisystem, das sich nicht unbedingt auf ein echtes
> device setzen muss, sondern damit zurechtkommt, dass die Ebene unter ihm
> bestimmte rudimentaere Dienste ("hol mir dies, schreib mir jenes") liefern
> kann. Ob dieses Teil nun Client eines ganz anderen Dienstes ist [...] oder
> auf einen (meinetwegen weiter abstrahierten) device layer aufsetzen, ist
> komplett egal. Insofern koennte man damit HFS+ auf NFS stapeln, ohne die
> Pfannkuchen zu verwuseln.
Nun. Es ist ja nicht so, daß ich da nicht schon öfter mal drüber nachgedacht
hätte... Wie würdest Du das Problem der persistenten IDs auf einem Server
client-seitig angehen?
Also so daß die IDs wirklich konsistent auch über umount/mount Vorgänge
hinweg bleiben?
> Was ist jetzt mit einem netatalk-Vortrag? *DRAENGEL* *QUENGEL*
Ach, laß mal. Dazu müsste ich mich ja wirklich mit den Innereien
beschäftigen ;-P
> inodes sind nicht einmal garantiert einzigartig - da können auch mehrere
> Directory-Eintraege hinzeigen.
Hmm... kommt sowas in der Praxis auch vor?
>> (der Finder von MacOS X hängt sich weit mehr an IDs auf als noch der von
>> MacOS 9)
>
> Es ist wohl eher eine Folge des volfs...
-v bitte.
Gruss,
Thomas
Noses
> Na, und? :-)
Die nennen Dinge manchmal anders... Bei denen wedelt der Hund noch mit dem
Schwanz. 8-)
> Nun. Es ist ja nicht so, daß ich da nicht schon öfter mal drüber nachgedacht
> hätte... Wie würdest Du das Problem der persistenten IDs auf einem Server
> client-seitig angehen?
Was hat der Client damit zu tun? 8-) Du meinst "auf einem Client eines
ID-freien Dateisystems, der selber eine bereitstellen muß"? Ich habe gute
Neuigkeiten: Gar nicht Wenn Du unbedingt nach oben die Schnittstelle "HFS+"
haben willst, legst Du eben ein HFS+ VFS daruf und überläßt dem die Arbeit.
So ganz habe ich noch nicht kapiert, wie es das anstellt, aber so ganz ist
mir auch noch nicht klar, wie die ._-Dateien entstehen (und die sind ein
Teil des notwendigen Mechanismus, volfs ist ein anderer); das liegt auch
daran, daß ich mich für das Thema noch nie interessiert habe, ich halte
diese IDs für etwas, das zusammen mit resource forks und Type&Creator an die
Wand gestellt werden sollte.
> Also so daß die IDs wirklich konsistent auch über umount/mount Vorgänge
> hinweg bleiben?
Ich wollte sowieso bei Gelegenheit etwas mit Darwin spielen; mal sehen, was
passiert, wenn ich HFS+ auf ein UFS stapele.
> > Was ist jetzt mit einem netatalk-Vortrag? *DRAENGEL* *QUENGEL*
> Ach, laß mal. Dazu müsste ich mich ja wirklich mit den Innereien
> beschäftigen ;-P
Ja eben... 8-) Irgendwer muß das doch mal tun.
> > inodes sind nicht einmal garantiert einzigartig - da können auch mehrere
> > Directory-Eintraege hinzeigen.
>
> Hmm... kommt sowas in der Praxis auch vor?
Laufend - was glaubst Du, was hard links sind und wo "." und ".." in jedem
Verzeichnis herkommen?. Allerdings - was ist eine File-ID? Etwas, das am
Namen oder an der Datei hängt? (Du solltest auf einem *BSD "fsdb"
ausprobieren - aber bitte nur mit dem Switch "-r". Man kann dabei viel über
die Struktur eines UFS lernen...)
> >> (der Finder von MacOS X hängt sich weit mehr an IDs auf als noch der von
> >> MacOS 9)
> >
> > Es ist wohl eher eine Folge des volfs...
>
> -v bitte.
volfs. If my memory serves me right, there is a dangerous being, right at
the root of it all.
Die komplette Dokumentation zum Thema (und das ist wirklich alles) findest
Du in /usr/src/xnu-517.3.7/bsd/miscfs/volfs/volfs_vnops.c:
/*
* volfs acts as a bridge between the requirements of the MacOS API and the
* Unix API. MacOS applications describe files by a <Volume ID><Directory
* ID><File Name> triple. The Unix API describes files by pathname. Volfs
* is a virtual file system that sits over the HFS VFS interface and allows
* files to be described by a <Volume ID>/<Directory ID>/<File Name>
* pathname.
*
* The root of the volfs filesystem consists of directories named the volume
* ID's of all the currently mounted filesystems which support the VFS
* vget() routine. Each of those directories supports the lookup by file ID
* of all files and directories within the filesystem. When a file or
* directory is resolved its vnode from that filesystem rather than a volfs
* vnode is returned allowing immediate access to the target file or
* directory.
*
* Readdir on the root of the volfs filesystem returns the list of available
* file systems. Readdir on a filesystem node, however, returns only . and
* .. since it is not practical to list all of the file ID's in a timely
* fashion and furthermore VFS does not provide a mechanism for enumerating
* all of the file id's.
*
* Volume ID's are taken from the low 32 bits of the f_fsid field, formatted
* as a base 10 ASCII string with no leading zeros (volume ID 1 is
* represented as "1").
*
* File ID's are created in same manner, with their 32 bits formatted as a
* base 10 ASCII string with no leading zeros.
*
* Volfs does create a security hole since it is possible to bypass
* directory permissions higher in the namespace tree. This security hole
* is about the same as the one created by NFS which uses a similar
* mechanism.
*/
Kreative Nutzung von Deppen-Apostrophen... Und den letzten Absatz solltest
Du genießen - ich kenne da mindestens zwei interessante Wege, an gültige
"Mac OS 9"-file handles heranzukommen, deswegen bin ich auch der NSHO, daß
ein halbwegs sicheres System kein Classic-Environment enthalten darf. Ich
fürchte, Apple setzt da auf "security by obscurity".
Aber was rede ich schon wieder - es kann ja gar keine Schädlinge für Mac OS
X geben und wenn etwas passiert, war es der Depp an der Tastatur schuld,
richtig?
So always remember: There is a dangerous being, right at the root of it all.
Und jetzt werde ich mindestens eine Woche lang die Finger vom Iron Chef
lassen, ehrlich.
Noses.
Markus Hippeli
> Hmm - als ich mir das beim letzten Mal angeschaut habe, wurde da nix an
> Daten synchronisiert, man hat plötzlich mehrere Home-Verzeichnisse auf
> unterschiedlichen Maschinen (mit vermutlich unterschiedlichem Inhalt).
> Wenn man da was synchronisieren will, muss man das AFAIK immer noch "von
> Hand" nachbauen. So sthet das auch in
> <http://docs.info.apple.com/article.html?artnum=107812>.
Das ist in der Tat einen ziemlich eindeutige Ansage. Dann habe ich das
Benutzerverwaltungshandbuch missverstanden in dem in der deutschen
Fassung auf Seite 54 steht:
<schnipp>
Ein ortsungebundener (mobiler) Account ist ein Mac OS X Server
Benutzer-Account, der auf einen lokalen Computer kopiert wurde und
weiterhin mit dem Server-Account synchronisiert ist, sodass beide
Umgebungen einen Satz übereinstimmender Daten enthalten. Somit kann
sich der Benutzer auch dann bei einem Mobilcomputer mit dem Namen und
dem Kennwort für einen Netzwerk-Account anmelden, wenn der Computer
gerade nicht mit dem Netzwerk verbunden ist. Der Privatordner für den
ortsungebundenen Account ist auf dem Computer des Benutzers angelegt.
Der Privatordner für den Netzwerk-Account befindet sich jedoch auf dem
Server selber. Wenn der Computer mit dem Netzwerk verbunden ist, meldet
sich der Benutzer direkt über den Server-Account an. Der
ortsungebundene Account wird auf diese Weise umgangen, wobei dennoch
ein lokaler Privatordner verwendet wird. Der ortsungebundene Account
wird anschließend automatisch und gemeinsam mit allen zugehörigen,
verwalteten Einstellungen aktualisiert. Wenn der Computer vom Netzwerk
getrennt ist, bleiben alle zugewiesenen, verwalteten Einstellungen
weiterhin in Kraft.
<schnapp>
Ohne Kenntniss des obigen Links hört sich das für mich auch immer noch
fehlinterpretierbar an...
Zu finden unter (voorsicht Akaimai)
<http://a1440.g.akamai.net/5/1440/51/63b27e0bf8215c/1a1a1aaa2198c6279707
73d80669d84574a8d80d3ca11688f7268aef1e91f668de43b5e448b71a8ffc61cf43a418
81f05e8dfd61c73a/User_Management_Admin.pdf>
Erlärt auf jeden Fall das Syncronisierungsproblem, das ich erwähnte. ;-(
cu
Markus