Überblick
  
System-Voraussetzungen
 - Betriebssysteme
 - Unterstützte Server
  
Installation und Entfernen
 - Installation
 - Upgrade auf eine neue Version
 - Entfernen von Sharity 3
  
Mit Sharity 3 arbeiten
 - Konfiguration
 - Ein- und Ausloggen
 - Authentifizieren mit Kerberos
 - Der Schlüsselbund
 - Ressourcen durchsuchen
 - /CIFS als magisches Verzeichnis
 - Einloggen und Schlüsselbund-Verwaltung aus der Kommandozeile
 - Mounten von Freitaben aus der Kommandozeile
 - Zugriff auf ACLs
 - Allgemeine Information
  
Dateien auf einem Windows-PC freigeben
 - Konfiguration des Netzwerks
 - Freigeben eines Verzeichnisses
 - Namens- und Browsing-Dienste
  
Tips und Tricks
 - Hilfe zu Konfigurations-Optionen
 - Permanente Mounts
 - Default Login für Domäne
 - Ein Default-Konto konfigurieren
  
Problembehebung
 - Erzeugen eines Debug-Logs
 - Wiederherstellen nach einem Absturz
 - Fehlersuche bei Kerberos und AD
  
Unix Home-Verzeichnisse auf SMB Freigaben
 - Überblick
 - Sharity und DirectControl
 - Integration von Sharity mit anderer Software
 - Einschränkungen
  
Release Notes
  
Software-Lizenz

Problembehebung

Erzeugen eines Debug-Logs

Wenn Sie einen Bug oder ein Problem an unseren Support melden, kann es sein, dass wir Sie um ein Debug-Log der Sitzung bitten. In diesem Fall tun Sie bitte folgendes:
  1. Definieren Sie einen klaren reproduzierbaren Startpunkt. Löschen Sie dazu jedenfalls die Datei "/tmp/sharity-debug.log", die von einem vorherigen Lauf übrig sein kann, oder benennen Sie sie um.
  2. Aktivieren Sie das Debug-Log. Geben Sie dazu (als root-User) den Befehl
    sharity debug file logLevelsDebug
    in der Kommandozeile ein. Wenn wir Sie um abweichende Einstellungen gebeten haben, verwenden Sie bitte diese.
  3. Bereiten Sie sich darauf vor, das Problem zu reproduzieren. Unternehmen Sie alle notwendigen Schritte bis kurz vor dem Punkt, an dem das Problem auftritt. Das kann z.B. das Mounten von Freigaben, Einloggen von Anwendern etc. sein.
  4. Notieren Sie die Grösse der Datei "/tmp/sharity-debug.log". Das gibt uns eine genauere Einschränkung, wo wir in der Log-Datei nach dem Problem suchen sollen.
  5. Reproduzieren Sie nun das Problem mit so wenig Schritten wie möglich. Notieren Sie dazu alle Ihre Eingaben und deren Ergebnisse (z.B. Fehlermeldungen) genau. Bitte seien Sie dabei so exakt wie möglich!
  6. Beenden Sie das Debug-Log mit dem Befehl (als root):
    sharity debug syslog
  7. Komprimieren Sie die Datei "/tmp/sharity-debug.log" und e-mailen sie an unseren Support.
Achtung: Das Debug-Log kann geheime Informationen und je nach Debug-Einstellungen sogar Passworte im Klartext enthalten. Bitte greifen Sie während des Loggings nicht auf Geheimnisse zu und ändern Sie nach dem Debug-Log Ihr Passwort. Wenn Sie auf diese Art Geheimnisse preisgeben, weisen wir jegliche Haftung von uns.

Wiederherstellen nach einem Absturz des Dämons

Sharity besteht aus zwei Teilen: Einer Benutzeroberfläche zur Interaktion mit dem Anwender und einem Dämon, der die eigentliche Arbeit im Hintergrund erledigt. Während ein Absturz der Benutzeroberfläche keine ernsten Konsequenzen hat, kann ein Absturz des Dämons gröbere Schwierigkeiten verursachen: Wenn der Dämon abstürzt oder versehentlich gekillt wird, hängen alle Sharity Mounts. Aber keine Panik: Eine Wiederherstellung ist normalerweise möglich. Wenn das für Sie eine Option ist, ist ein sofortiger Neustart des Computers meist die schnellste Lösung. Wenn aber ein Neustart aus welchen Gründen auch immer nicht möglich ist, versuchen Sie zunächst, mit dem umount (oder unmount) Befehl Ihres Systems alle Sharity Mounts loszuwerden. Verwenden Sie dazu die "-f" Option um den Unmount zu erzwingen, wenn diese Option existiert. Reicht das noch nicht aus, starten Sie Sharity jetzt. Beim Default-Installationspfad:
/usr/local/sharity3/sbin/sharity.init start
Probieren Sie jetzt nochmals alle Sharity mounts mit dem umount Befehl loszuwerden. Ist Ihnen das gelungen, stoppen Sie den Dämon mit dem Befehl "kill -9 daemon-pid". [Das sollten Sie niemals tun, ausser in diesem ganz speziellen Fall!] Danach starten Sie Sharity erneut.

Das Unmounten kann mit der Fehlermeldung "Device or resource busy" abbrechen. Das bedeutet, dass es noch einen Prozess gibt, der den Mount benutzt. Sie können erst dann unmounten, wenn Sie diesen Prozess beendet haben. Um herauszufinden, welcher Prozess das ist, benutzen Sie bitte den Befehl "lsof" oder "fuser". Der Quellcode zu "lsof" ist frei verfügbar.

Fehlersuche bei Kerberos und Active Directory

Kerberos und Active Directory Funktionen sind in einem separaten Programm implementiert, das für jeden Anwender individuell gestartet wird. Mit diesem Programm (sharity-userd) können Fehler gesucht werden, ohne dass dazu andere Teile von Sharity laufen müssen. Es braucht allerdings einige spezielle Umgebungsvariablen, damit es funktioniert. Um in eine Shell zu kommen, in der diese Variablen vordefiniert sind, führen Sie das folgende Kommando (als Anwender, ausser wenn Sie Logins für root debuggen wollen) durch:
/usr/local/sharity3/sbin/sharity.init testshell
Damit kommen Sie in eine "sh" Shell, von der aus Sie Ihre bevorzugte Shell starten können.

Bevor wir mit sharity-userd arbeiten, stellen Sie sicher, dass Sie ein gültiges Kerberos-Ticket haben. Geben Sie "klist" ein um alle Ihre Kerberos-Tickets anzuzeigen bzw. verwenden Sie falls notwendig "kinit" um sich einzuloggen. Unter der Annahme, dass Sie ein gültiges Ticket Granting Ticket haben, können Sie mit

sbin/sharity-userd getUserPrincipal
Ihr Kerberos Login ("Kerberos Principal") anzeigen. Um Login-Daten für einen bestimmten Server zu erhalten, führen Sie
sbin/sharity-userd getKrb5Auth <server-principal>
durch. "<server-principal>" ist dabei der Kerberos Principal Name des Servers. Dieser Name wird üblicherweise aus dem Computernamen des Rechners als "servername$@REALM" zusammengebaut. "REALM" ist normalerweise die in Grossbuchstaben geschriebene Domäne. Ein Beispiel:
bash$ sbin/sharity-userd getKrb5Auth 'pdc1$@TEST.HOME'
authenticator for pdc1$@TEST.HOME is:
odalloc/alloc: 0000: 6e 82 04 5a 30 82 04 56 a0 03 02 01 05 a1 03 02
odalloc/alloc: 0010: 01 0e a2 07 03 05 00 00 00 00 00 a3 82 03 99 61
[...]
odalloc/alloc: 0450: 36 84 00 8c 0c 7d f3 e9 58 7e 2b bd 98 e9
session key is:
odalloc/alloc: 0000: 09 35 a9 f4 4a 97 ed 60 42 11 ca d7 95 f7 e3 aa
Wenn bis hier her alles funktioniert hat, sollten Kerberos Logins mit Sharity funktionieren. Wenn nicht, stellen Sie bitte sicher, dass Sie den Default Credentials Cache für Kerberos verwenden (die Umgebungsvariable KRB5CCNAME darf nicht gesetzt sein). Da Sharity beim Hochfahren des Systems startet, kann es Ihre Umgebungsvariablen nicht erben.

Um den Zugriff auf Active Directory zu testen, probieren Sie

sbin/sharity-userd ldapQuery <domain> 1 objectClass=user
wobei Sie "<domain>" durch Ihre Active Directory Domäne ersetzen. Ein Beispiel: 
bash$ sbin/sharity-userd ldapQuery test.home 1 objectClass=user
userd/db0: trying ldap connect to pdc1.test.home port 3268
userd/db0: SASL Interaction: challenge=Authorization Name prompt=...
userd/db0: SASL Interaction: defaultRes=
entry 0 dn = CN=TsInternetUser,CN=Users,DC=sub1,DC=test,DC=home
    cn = TsInternetUser
    displayName = TsInternetUser
    instanceType = 0
    distinguishedName = CN=TsInternetUser,CN=Users,DC=sub1,DC=test,DC=home
    objectCategory = CN=Person,CN=Schema,CN=Configuration,DC=test,DC=home
    objectClass = top
         person
         organizationalPerson
         user
[...]

Wenn auch dieser Befehl funktioniert, sollten Sie Active Directory über Sharity durchsuchen können. Sollte eines der oben beschriebenen Kommandos fehlschlagen, sollte Ihnen die Fehlermeldung bei der Behebung des Problems helfen.

Copyright © 2004 - 2007 by OBJECTIVE DEVELOPMENT Software GmbHDruckversion