Dieses Kapitel beschreibt die Funktion und die Konfiguration des
Desktopservers. Dieser speichert Icons sowie Programmdaten für den
gesamten HELIOS Server. Außerdem verwaltet er die Datei- und Verzeichnis-IDs
für alle Netzwerk-Volumes. Der Desktopserver ist für den Anwender in der
Regel unsichtbar und besitzt auch kein zugeordnetes Client-Programm.
Eine Ausnahme stellt die Option Schreibtisch aufbauen
in
HELIOS Admin bzw. das Tool „rebuild“ dar (siehe Abschnitt 8.12 „rebuild“).
Die SQL-Desktopdatenbank hat die folgenden Funktionen:
Eine Unterbrechung der Stromversorgung oder unerwartete Neustarts machen keinen Neuaufbau des Desktops beim Booten erforderlich. Sämtliche Volumes sind in wenigen Sekunden verfügbar.
Die Desktopdatenbank ist mit verschiedenen Host-Byte-Reihenfolgen kompatibel, z. B. mit Solaris SPARC- und Linux-Systemen. Auch von Systemen mit einer anderen Host-Byte-Reihenfolge ist der Zugriff problemlos und ohne die Desktopdatenbank neu aufbauen zu müssen. Deshalb kann von einem Linux-System ein Volume von einem Solaris SPARC-Server per NFS gemountet und die HELIOS „dt“-Tools ohne Probleme mit der Byte-Reihenfolge verwendet werden.
Die SQL-Desktopdatenbank hat keinerlei Einschränkungen hinsichtlich der Dateigröße.
Nach 60 Sekunden Leerlauf (keine Dateiänderung, nur Lesezugriff) wird die Desktopdatenbank „geflusht“, d. h. die Daten werden auf die Festplatte geschrieben.
Die aktuelle Desktopdatenbank kann gesichert und in
ein Verzeichnis zur Datensicherung kopiert werden (siehe Kapitel
13.2.1 „Online-Datensicherungen von einem
Live-Volume“). Die Desktopdatenbank wird mit dem
Befehl srvutil reconf desksrv
auf die Festplatte
geschrieben („geflusht“). Eine Snapshot-Kopie des Dateisystems ist ebenfalls
möglich (abhängig vom Betriebs- und Dateisystem). So lässt sich auf dem Live-Volume
mit Lese- und Schreibberechtigung weiterarbeiten, während die Snapshots als
Volume mit nur-Leseberechtigung genutzt werden können.
Das SQL-Desktopdatenbankformat ist der Standard für alle Volumes mit Lese-/Schreibberechtigung. Dateisysteme mit einem alten Desktopformat, die nur Leseberechtigung bieten, z. B. CD-ROMs, werden erkannt und mit dem alten Format verwendet.
Eindeutige IDs für Dateien/Ordner
Dateien und Ordnern werden beim Anlegen eindeutige IDs zugewiesen. Diese ändern sich nicht mehr, auch wenn die Datei umbenannt oder an einen anderen Ort auf demselben Volume verschoben wird
Beim Umbenennen einer Datei bzw. eines Ordners bleiben Verweise (Aliase, Datei-IDs, OPI-Verweise usw.) erhalten, da die Identifikation über eine eindeutige ID erfolgt
„Aliase“ für den Mac lassen sich immer auf die verknüpfte Datei bzw. den verknüpften Ordner auflösen
Kompatibilität mit Mac und Windows
Die Desktopdatenbank ist sowohl mit dem AFP- als auch mit dem SMB-Protokoll sowie HFS-/NTFS-Dateisystemen kompatibel
Schnelle Dateisuche
Die Suche nach einer Datei oder einem Ordner dauert statt Stunden nur noch Sekunden (Dateien und Ordner müssen vorher nicht abgefragt werden werden)
Der Desktopserver besteht aus dem Programm „desksrv“. Er wird während der Installation im Verzeichnis HELIOSDIR/sbin” angelegt. HELIOS Base ist so konfiguriert, dass „desksrv“ beim Hochfahren des Servers automatisch gestartet wird.
„desksrv“ verwaltet je HELIOS Volume eine Datenbank, die Icons sowie Programmdaten für den gesamten HELIOS Server enthält sowie Informationen über Datei- und Verzeichnis-IDs für Netzwerkvolumes. Die Daten werden in der Datei „.Desktop“, das im Root-Verzeichnis eines jeden Volumes liegt, gespeichert. Der Dateiname „.Desktop“ wird von allen HELIOS Servern geschützt und ist normalerweise für Mac-, Windows- oder Web-Anwender unsichtbar.
Die Programmdaten in jeder „.Desktop“-Datei enthalten die Informationen, die erforderlich sind, um den jeweiligen Dokumenten die Mac-Anwendungen zuzuordnen, die sie angelegt haben. Der Mac-Finder nutzt diese Information, um die passende Anwendung zu starten, wenn der Benutzer ein bestimmtes Dokument per Doppelklick öffnen möchte. Wird ein Programm auf ein HELIOS Volume kopiert, legt „desksrv“ einen neuen Eintrag in der jeweiligen Desktopdatenbank an.
Die in jeder Desktopdatei („.Desktop“) gespeicherten Symboldaten enthalten Icons sämtlicher Programme auf dem Volume. Diese sind nach Type und Creator sortiert.
Wenn der Finder oder eine Anwendung eine Datei öffnen möchte, steht eine Systemoption zur Verfügung, mit der sich diese Datei nicht nur über ihren Namen sondern stattdessen auch über ihre Referenznummer öffnen lässt. Diese Referenz wird auch „Datei-ID“ genannt. Der Verzeichnispfad kann ebenfalls über die „Ordner-ID“ angegeben werden. Durch die Verwendung von Datei- bzw. Ordner-IDs, lassen sich Dateien auch dann noch finden, wenn ein Benutzer sie umbenannt oder verschoben hat. Dadurch erhält der Anwender eine größere Flexibilität.
Dieses Prinzip findet in der Mac-Funktionalität „Alias“ Anwendung.
Jede Desktopdatei enthält Datei- und Ordner-IDs für sämtliche Dateien und Verzeichnisse im Volume. Die Datei-ID wird zusätzlich im Ressourcezweig einer jeden Datei gespeichert, ebenso wie die Ordner-ID im Ressourcezweig eines jeden Verzeichnisses abgelegt ist. Für den Benutzer sind diese IDs in der Regel unsichtbar.
Um den Desktop eines HELIOS Volumes neu aufzubauen, müssen Sie sicherstellen,
dass das Volume nicht gemountet ist (z. B. durch Verwendung der Option
Aktive Benutzer
, die im Abschnitt 7.5.10 „Online“
beschrieben wird).
Starten Sie HELIOS Admin von einem der verbundenen Client-Computer,
markieren Sie ein Volume in der Volumeliste und wählen Sie
Schreibtisch aufbauen
aus dem Menü Volume
(siehe
Kapitel 7.6 „Menü „Volume““).
Da der Desktopdatenbank durch einen Neuaufbau immer auch neue Dateien hinzugefügt werden, um Dateisuchen über die Desktopdatenbank des Volumes durchführen zu können, muss jede Datei bzw. jeder Ordner einen Ressourcezweig haben.
Während des Neuaufbaus werden für sämtliche Ordner im HELIOS Volume fehlende Ressourceverzeichnisse und -dateien angelegt; bereits vorhandene IDs werden geprüft und fehlende neu erstellt. Gleichermaßen werden fehlende Datei-IDs erstellt und vorhandene IDs geprüft.
Standardmäßig verwendet das Programm „rebuild“ beim Aktualisieren der Desktopdatenbank zwei Durchläufe. Das hat den Vorteil, dass auf Volumes mit doppelten Datei- bzw. Ordner-IDs (was gewöhnlich auf durch UNIX-Befehle manipulierte Dateien und Ordner zurückzuführen ist), eben jene Dateien und Ordner eine neue ID erhalten, nachdem der gesamte Desktop überprüft wurde, während alle anderen Objekte ihre Original-ID behalten. Datei- und Ordner-IDs werden sowohl in der Datei „.Desktop“ als auch im Ressourcezweig der Datei bzw. des Ordners gespeichert; treten bei der Überprüfung Ungereimtheiten auf, werden die IDs aus dem Ressourcezweig zugrunde gelegt.
Während des Neuaufbaus kann auf ein HELIOS Volume geschrieben werden. Solange die Desktopdatenbank noch nicht vollständig ist, können Änderungen an Dateien und Ordnern zur Zuweisung von unterschiedlichen Datei- bzw. Ordner-IDs für Objekte führen, die im Zuge des Aufbaus noch nicht bearbeitet wurden.
Um Inkonsistenzen zwischen den Informationen in der Desktopdatenbank eines HELIOS Volumes und den Dateien und Ordnern auf diesem Volume zu vermeiden, wird der Neuaufbau beim Auftreten eines Timeouts sofort beendet. Die Desktopinformationen für dieses Volume bleiben solange unvollständig, bis ein Aufbau erfolgreich beendet wird.
Für von UNIX-Programmen erstellte Dateien sind Ressourceverzeichnisse überflüssig. Sie haben zwar auf UNIX-Programme beim Zugriff auf die Originaldateien keinen Einfluss, beanspruchen aber einen Teil des Festplattenspeichers. Dementsprechend könnte es besser sein, wenn Sie Ihre Verzeichnisse und Volumes in getrennten Dateisystemen für reine UNIX-Dateien und für Mac-, Windows- und Web-Dateien organisieren.
Wir raten Ihnen dringend, das Programm „rebuild“ (siehe Kapitel
8.12 „rebuild“) oder die Option Schreibtisch aufbauen
in HELIOS Admin zum Aufbau Ihrer Desktopdatenbank zu verwenden. Löschen Sie
niemals die Desktopdatenbank unter UNIX!
Jedesmal wenn Sie ein HELIOS Volume über den Dialog Mit Server
verbinden
am Server anmelden, prüft der Desktopserver die logische Beschaffenheit
der Desktopdatei. Falls der Serverprozess dabei ungültige Informationen
entdeckt, wird er einen erneuten Aufbau des Desktops auslösen. Dieser
Vorgang läuft automatisch und im Hintergrund ab. Die gleiche Überprüfung
findet auch beim ersten Start der HELIOS Dienste statt – je nach Status der
Volume-Präferenzen AFPPublish
und SMBPublish
in der
Datei „Preferences“.
Falls bei der Kommunikation zwischen „afpsrv“- bzw. „pcshare“-Prozessen
und „desksrv“ Timeouts aufgetreten sind, erhält das Volume nur eine
Leseberechtigung und erscheint ausgegraut in der Liste der Volumes
Mit Server verbinden
. Ordner können noch geöffnet und Dateien
gelesen werden, jedoch können Sie nicht mehr angelegt, umbenannt,
verschoben oder gelöscht werden.
Timeouts werden üblicherweise von hohen Server- oder I/O-Lasten, langsamen I/O-Geräten oder Netzwerk- sowie Kommunikationsproblemen verursacht. In den Systemmeldungen finden Sie vielleicht einen Hinweis auf die genaue Ursache. Je nach Schwere des Problems kann es erforderlich sein, die HELIOS Dienste auf dem Server mit Hilfe der Skripte „stop-helios now“ gefolgt von „start-helios“ neu zu starten. Vergewissern Sie sich aber, dass das Problem behoben ist bevor Sie die HELIOS Dienste erneut starten.
Bei CD-ROMs, die in HELIOS Admin mit der Berechtigung „Nur Lesen“ als Volume gemountet worden sind, prüft der Desktopserver zuerst, ob eine gültige Desktopdatei im Root-Verzeichnis des Volumes existiert. Dies ist beispielsweise bei MO-Laufwerken der Fall, die zuvor mit EtherShare mit Lese- und Schreibzugriff gemountet wurden und so eine Desktopdatei besitzen.
Kann auf dem Volume keine gültige Desktopdatei gefunden werden (was bei CD-ROMs die Regel sein wird), legt der Desktopserver eine temporäre Desktopdatei mit einem eindeutigen Dateinamen (beginnend mit „desksrv…“) im Verzeichnis „/tmp“ auf dem Host an. Da die Dateien auf der CD-ROM demzufolge wohl auch keinen Ressourcezweig haben, verwendet der Finder die Informationen aus der Mapping-Tabelle für Dateiendungen oder nutzt eines der 20 generischen EtherShare-Icons.
Regelmäßige Datensicherungen von Volumes mit sensiblen Daten sind ein „Muss“. Dabei wird die Desktopdatenbank ebenfalls gesichert. Allerdings kann es zu Problemen kommen, wenn die Desktopdatenbank im Moment der Sicherung, aufgrund von Dateiänderungen durch den HELIOS Fileserver, in Benutzung ist. So können bei der Wiederherstellung der Daten auf dem Volume Unstimmigkeiten in der Datenbank auftreten, die zu fehlerhaftem Verhalten oder Fehlermeldungen führen. Um dies zu verhindern könnte man das Volume während der Datensicherung deaktivieren.
Eine bessere Methode ist es, den Desktop für einen kurzen Moment „einzufrieren“,
sodass Snapshots vom Volume angefertigt werden können. Der Desktopserver
unterstützt das „Flushen“ der Daten auf die Festplatte, gefolgt von einem
Einfrieren der Datenbank für den Zeitraum von 10 Sekunden (dieser Wert lässt sich
mit dem Befehl
srvmsg -c -n desksrv freeze [duration]
ändern), wodurch
Snapshots vereinfacht werden. Mit der Serverpräferenz FreezeDefault
können Sie die Zeitspanne des Einfrierens angeben und mit FreezeMax
den maximale möglichen Wert festlegen.
Mit dem Skript „backup-desktop.pl“ lässt sich online eine Kopie der
„.Desktop“-Datei anlegen (Aufruf auf der Kommandozeile: perl
backup-desktop.pl
).
Das Skript finden Sie unter:
www.helios.de/web/EN/support/desktop_backup.html
Setzen Sie den Wert für FreezeMax nicht unnötig hoch, da dies ansonsten zu einem clientseitigen Timeout-Fehler führen, wenn Clients versuchen, sich mit dem Server neu zu verbinden.
Obwohl ein Neuaufbau der Desktopdatenbank nach der Migration auf UB64 nicht zwingend erforderlich ist, raten wir dennoch dazu, da wir einen neuen Datenbank-Index hinzugefügt haben, der den Zugriff erheblich beschleunigt.
Änderungen an Dateien in HELIOS Volumes, die nicht mit EtherShare, PCShare, WebShare oder den HELIOS „dt“-Tools vorgenommen wurden, machen einen Neuaufbau des Desktops erforderlich, damit die Konsistenz des Volume-Index gewahrt bleibt. Der Workflow sollte auf alle Dateioperationen, welche die HELIOS Prozesse umgehen, überprüft werden. Dazu zählen auch Host-Skripte, die nicht die „dt“-Tools verwenden, FTP-Uploads, unsauber wiederhergestellte Volumedaten aus einem Systembackup (siehe Abschnitt 8.11.3 „„dt“ zur Datensicherung und -wiederherstellung nutzen“) sowie andere Dateiänderungen, die nicht mit HELIOS kompatibel sind. Denken Sie bitte daran, dass für EtherShare- und PCShare-Clients eine aktuelle Desktopdatenbank erforderlich ist, da diese über eindeutige IDs auf Dateien auf dem Volume zugreifen. Falsche oder fehlende IDs führen zu erheblichen Problemen.
Falls eine UNIX-Fehlermeldung wie:
missing DB shutdown:[/apple1/software] at Thu Nov 24 18:22:48 2009, recommend rebuild to re-create desktop file
protokolliert wird, raten wir Ihnen zu einem Neuaufbau des Desktops bei nächster Gelegenheit.
Beachten Sie bitte, dass die Transaktionsdatenbank nach einem Abbruch wie z. B. einem Stromausfall nicht neu aufgebaut werden muss.
Die Verwendung von Dateiservern, die nicht mit HELIOS kompatibel sind (z. B. Samba), auf einem HELIOS Live-Volume führt zu Problemen wie „springenden“ Finder-Listeneinträgen, seltsamen „File not found…“-Meldungen usw.
Desktop neu anlegen:
# rebuild -f /volpath (wie in HELIOS Admin)
(Kein Datenverlust, da die IDs aller Dateien im entsprechenden Ressourcezweig, der indiziert wird, abgelegt sind)
Desktop neu indizieren (fehlende bzw. falsche Dateiindizes werden repariert):
# rebuild /volpath
Dateisystem mit der Desktopdatenbank vergleichen:
# rebuild -s /volpath
Keine Ausgabe deutet darauf hin, dass der Index auf einem aktuellen Stand ist.
Wir raten Ihnen dringend, vor dem Neuaufbau der Desktopdatei zu überprüfen, dass auf der Festplatte genügend freier Speicherplatz vorhanden ist (siehe Kapitel 8.12 „rebuild“)!
Mit der Präferenz desktoplocation lässt sich der Desktop eines HELIOS Volumes an einem Ort außerhalb des HELIOS Volumes sichern.
Vorteile:
Keine Probleme, wenn der Speicherplatz auf dem Volume knapp wird
Geschwindigkeitszuwachs durch Verwendung des Desktops auf einer ungenutzten Festplatte
Wenn diese Präferenz gesetzt ist, werden Volumes nicht automatisch neu aufgebaut, sondern behalten ihre bestehende Desktopdatenbank solange bis ein Neuaufbau explizit angeregt wird.
Nur der Aufbau in HELIOS Admin oder die Verwendung des Befehls rebuild -f
legt die Datei „.Desktop“ am neuen Ort an. Die alte Desktopdatei „.Desktop“
wird in einen Symlink auf den neuen Speicherort umgewandelt.
Der Symlink kann auch abgeändert werden, sodass er auf einen benutzerdefinierten,
bereits bestehenden Speicherort verweist.
Wird das Volume auch mit „dt“-Tools per NFS verwendet, vergewissern Sie sich, dass beide Dateien, Volumedaten und „.Desktop“ unter dem angegebenen Pfad über NFS erreichbar sind. Sonst kann es passieren, dass ein separater Volume-Desktop verwendet wird, der nur auf dem zweiten System, auf dem „dt“ für den Zugriff auf die Volumedaten über NFS genutzt wird, aktuell ist.
Beispiel mit relativem Pfad (der bestehende Volumepfad ist „/data/helios“):
# prefvalue -k Programs/desksrv/desktoplocation -t str "var/desktops"
Beim nächsten Aufruf von „rebuild -f“ wird die Desktopdatei „.Desktop“ in „HELIOSDIR/var/desktops/data/helios/.Desktop“ angelegt.
Beispiel mit absolutem Pfad (der bestehende Volumepfad ist „/data/helios“):
# prefvalue -k Programs/desksrv/desktoplocation -t str "/desktops"
Beim nächsten Aufruf von „rebuild -f“ wird die Desktopdatei „.Desktop“ in „/desktops/data/helios/.Desktop“ angelegt.
Nachdem die Präferenz gesetzt wurde, muss „desksrv“ neu gestartet werden (siehe Abschnitt 14.1 „srvutil“).
Existiert das Ziel für den Symlink nicht, wird die Fehlermeldung
OpenDesk <volume path>: Miscellaneous error
ausgegeben.
Der SQL-Desktop nutzt das unterliegende SQLite-Datenbankformat. Mit dem Kommandozeilen-Tool „sqlite“ (siehe Abschnitt 8.9 „sqlite“) kann die SQL-Desktopdatenbank verwaltet werden.
Die „SQLite“-Distribution von OS X, oder auch jede andere „SQLite“-Distribution, ist nicht mit der SQL-Desktopversion von HELIOS kompatibel, weshalb „sqlite“-Tools oder Libraries, die nicht von HELIOS stammen, nicht einwandfrei funktionieren oder zu „Locking“-Problemen führen, welche die Datenbank beschädigen. Dagegen ist die Verwendung des Befehls „sqlite“ aus der HELIOS Installation sicher.
Die Dokumentation zu SQLite finden Sie hier:
www.sqlite.org/docs.html
Eine Modifikation der SQL-Desktopdatenbank sollte nur von erfahrenen Entwicklern vorgenommen werden, die sich gut mit SQL und Datei- bzw. Ordner-IDs bei HELIOS Produkten auskennen. Das Sperren der Datenbank für einen längeren Zeitraum (mehr als ein paar Sekunden) kann zu Netzwerk-Timeouts der verbundenen Mac- oder Windows-Clients führen. Wenn Clients versuchen, Volumeinformationen zu ändern und die Desktopdatenbank des Volumes gesperrt ist, wird eine Fehlermeldung ähnlich der folgenden ausgegeben: „Warning, desktop DB busy by another process“.
Der HELIOS Dienst „desksrv“ notiert sich Änderungen für eine Transaktion
und „flusht“ diese alle 60 Sekunden (Vorgabewert; siehe Präferenz
SQLFlushDelay in Abschnitt 19.6 „Desktop server preference keys“), um sicher
zu stellen, dass die SQL-Desktopdatei auf dem neuesten Stand ist. Mit dem
Befehl srvutil reconf desksrv
bewirken Sie, dass alle Volumes „geflusht“
werden.
Das alte Desktopformat wird nur noch unterstützt, um den Zugriff auf die alten schreibgeschützten Volumes zu gewährleisten. Daher empfehlen wir Ihnen, diese Präferenz nicht zu setzen oder zu ändern. Vorgabe (Präferenz nicht gesetzt) ist das SQL-Datenbankformat. Für Dateisysteme mit der Berechtigung „Nur Lesen“ erkennt und nutzt der Desktopserver automatisch das alte Format.
Die Dienste „afpsrv“ oder „pcshare“ versuchen sich mit „desksrv“ zu verbinden, um Informationen von der Desktopdatenbank der Volumes zu bekommen bzw. abzuspeichern.
Haben sie nach 60 Sekunden noch keine Antwort von „desksrv“ bekommen, deutet dies auf ein ernsthaftes Problem mit dem unterliegenden Betriebssystem des Server, dem UNIX-Dateisystem, den RAID/HSM-Treibern oder einem Hardwareproblem mit dem Massenspeicher hin.
Um Inkonsistenzen zwischen den Informationen in der Desktopdatenbank eines HELIOS Volumes und den Dateien und Ordnern auf diesem Volume zu vermeiden, erhält das Volume (alle gemounteten Volumes) von „afpsrv“ sowie „pcshare“ nur eine Leseberechtigung. Ordner können noch geöffnet und Dateien gelesen werden, jedoch können Sie nicht mehr angelegt, umbenannt, verschoben oder gelöscht werden.
Abgesehen von den üblichen Meldungen, die in den Systemfehlermeldungen des Hosts protokolliert werden, gibt der Server eine Fehlermeldung an den Client aus, falls die Kommunikation mit „desksrv“ fehlschlägt und informiert die Benutzer darüber, dass das Volume auf die Berechtigung „nur Lesen“ gesetzt wurde. Diese Meldung lautet:
Volname: localhost: RPC: Timed out; Only readonly access possible
Unter bestimmten Bedingungen wird eine weitere Fehlermeldung ausgegeben und das Volume automatisch vom Finder ausgeworfen.
Obwohl diese Meldung nur von einem „afpsrv“ oder „pcshare“-Clientprozess ausgegeben wird, ist es wahrscheinlich, dass alle anderen „afpsrv“-Prozesse dasselbe Problem haben und der Serveradministrator deshalb sofort informiert werden sollte.
Da Programme üblicherweise mit temporären Dateien und Ordnern arbeiten,
ist es nicht immer möglich einzelne Dateien zu speichern. Tritt dieses
Problem nur temporär auf, erhalten die HELIOS Volumes durch Auswerfen und
anschließendem Neuverbinden die Berechtigung „Lesen & Schreiben“. War das Problem
nicht temporär und ist noch nicht behoben, werden im Mac-Dialog Mit
Server verbinden
überhaupt keine Volumes angezeigt. Nicht einmal „root“
ist dann in der Lage eines dieser Volumes zu mounten.
Je nach Schwere des Problems kann es erforderlich sein, die HELIOS Dienste auf dem Server mit Hilfe der Skripte „stop-helios now“ gefolgt von „start-helios“ zu stoppen und erneut zu starten.
Vergewissern Sie sich, dass die Ursache des Problems behoben worden ist bevor Sie die HELIOS Dienste erneut starten.