HELIOS Base UB64 Benutzerhandbuch (Version 4.0.0)  
 

13 Desktopserver

13.1 Allgemeine Bemerkungen

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“).

13.1.1 Die SQL-Desktopdatenbank

Die SQL-Desktopdatenbank hat die folgenden Funktionen:

Journaldatei

Eine Unterbrechung der Stromversorgung oder unerwartete Neustarts machen keinen Neuaufbau des Desktops beim Booten erforderlich. Sämtliche Volumes sind in wenigen Sekunden verfügbar.

Identische Byte-Reihenfolge

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.

Unbegrenzt viele Dateien pro Volume

Die SQL-Desktopdatenbank hat keinerlei Einschränkungen hinsichtlich der Dateigröße.

Automatisches „Flushen“/Schließen

Nach 60 Sekunden Leerlauf (keine Dateiänderung, nur Lesezugriff) wird die Desktopdatenbank „geflusht“, d. h. die Daten werden auf die Festplatte geschrieben.

Online-Datensicherung des Desktops/​Snapshots und „Flushen“ des Desktops

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.

Rückwärtskompatibilität

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.

13.1.2 Wozu dient die Desktopdatenbank?

13.2 Desktopserver (Programm)

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

„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.

Icons sowie Programmdaten für Mac-OS-8/9

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.

IDs für Dateien und Ordner

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.

Desktop neu aufbauen

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).

hsymInstruction

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.

Wichtig:

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!

Automatischer Aufbau des Desktops

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“.

Auswirkungen von Timeouts

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.

„Read only“-Volumes

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.

13.2.1 Online-Datensicherungen von einem Live-Volume

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

Hinweis:

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.

13.2.2 Neuaufbau der Desktopdatenbank

Hinweis:

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.

Wichtig:

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.

a)

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)

b)

Desktop neu indizieren (fehlende bzw. falsche Dateiindizes werden repariert):

# rebuild /volpath
c)

Dateisystem mit der Desktopdatenbank vergleichen:

# rebuild -s /volpath

Keine Ausgabe deutet darauf hin, dass der Index auf einem aktuellen Stand ist.

Wichtig:

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“)!

13.2.3 Desktopdatenbank transferieren

Mit der Präferenz desktoplocation lässt sich der Desktop eines HELIOS Volumes an einem Ort außerhalb des HELIOS Volumes sichern.

Vorteile:

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.

Hinweis:

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.

13.2.4 SQL-Desktopdatenbank

Der SQL-Desktop nutzt das unterliegende SQLite-Datenbankformat. Mit dem Kommandozeilen-Tool „sqlite“ (siehe Abschnitt 8.9 „sqlite“) kann die SQL-Desktopdatenbank verwaltet werden.

Wichtig:

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

Hinweis:

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.

13.2.5 Hinweis zur Präferenz „UseSQL“

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.

13.3 Koordination von „afpsrv/pcshare“ mit „desksrv“

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.


HELIOS Website © 2015 HELIOS Software GmbH  
HELIOS Handbücher 6. Februar 2019