Probleme bei Samba?/tbl-Datei gesperrt

glaser at ub.tum.de glaser at ub.tum.de
Mi Dez 19 10:33:01 CET 2001


Werte Allegrologen,

folgender Text ist etwas länglich und ziemlich technischer Natur. Trotzdem 
meine ich, ist er von allgemeinem Interesse, weshalb ich ihn in die Liste 
stelle. Also je nachdem löschen oder weiterlesen.

Seit längerer Zeit wird hier gegen die Sperrung der tbl-Datei gekämpft. 
Meine erste diesbezügliche Mail stammt vom 15.November und die 
Resonanz war mäßig (Dank an Herrn Thamm und an Herrn Eversberg!) Da 
im Ruhestand, habe ich mich auch nicht mehr soooo intensiv darum 
gekümmert, aber jetzt mache ich noch einmal einen letzten Versuch. Hier 
ist nämlich ein m.E. sinnloser Aktionismus ausgebrochen, und der kommt 
teuer, wenn die Fehlergrundlagen unbekannt sind (analog Politik).

Die Situtation: Server ist eine Sun mit Samba (2.2.10 glaube ich). Clients 
sind Windows9x, NT, (künftig W2000, XP).

Einschub ein:
1. Immer wieder gab es mal Anfragen in der Liste über die richtige 
Konfiguration der Clients (ansi-Treiber usw.) und es kamen auch die 
diversen Hinweise, z.B. daß ME immer die config.sys zurücksetzt. Da 
Onkel $ill sich vermutlich immer wieder mal was neues einfallen lassen 
wird: könnten diese Hinweise nicht mal zentral gesammelt werden?
2. Früher gab es mal eine Anleitung für die Netzinstallation unter Novell von 
Herrn Evers. Könnte da nicht eine Neuauflage erfolgen unter Einschluß von 
NT und Samba? Für letzteres stelle ich gerne meine Unterlagen zur 
Verfügung (enden allerdings 1999). Wie steht es übrigens mit der 
Datensicherheit unter NT? Unter Novell gab(gibt?) es das User-Recht 
modify und erase. Unter NT und Unix gibt es nur schreiben, lesen, 
ausführen. Kann unter NT nicht ein rachedurstiger Benutzer alle 
gemounteten Daten (z.B. ALD-Dateien) ohne weiteres löschen (falls sie 
nicht durch Tricks wenigstens unsichtbar gemacht werden)? (Unter Samba 
läßt sich das durch eine passende link-Struktur via Unix vermeiden)
Einschub aus

Weiter mit der Situation:
Sowohl Programme als auch Daten liegen auf dem Server. Beim Einloggen 
werden die Programme in den Speicher der Clients geladen und damit die 
Daten (auf dem Server) bearbeitet. Nun ist die Idee aufgetaucht, daß diese 
Konstruktion den Server zu stark belastet. Eine Entlastung wird durch 
Installation der Programme auf den Clients erwartet. Das ist m.E. nicht 
richtig - abgesehen davon, daß daraus zusätzliche finanzielle (Lizenz!) und 
EDV-administrative Aufwendungen (über 100 PCs!) entstehen.
Meine Einschätzung fußt auf der Tatsache, daß sich die Bearbeitung, d.h. 
tbl-Datei gesperrt, mit der ZEIT geändert hat. Man liest immer wieder in 
Computer-Zeitschriften, daß Onkel $ills System mit den Jahren langsamer 
wird, abstürzt, neu installiert werden sollte.

Typische Situation auf unseren Clients ist die folgende:
Beim Hochfahren zeigt sich das (selbstgestrickte) allegro-Menü. 
Bestenfalls (für Windows) bleibt es bei der Vorauswahl (d.h. es werden 
noch keine Laufwerke gemountet und auch die allegro-Programme noch 
nicht geladen). Aber es kommt auch vor, daß in allegro eingestiegen wird 
(dann werden bis zu 4 LW gemountet). Dann wird u.U. allegro geparkt und 
ein Browser gestartet, um das VLB anzusehen. Dann wird über 97501-
Emulation auf den Verbund zugegriffen. Und dann wird vielleicht noch das 
Mail-Programm gestartet und zusätzlich noch das eine oder andere 
Programm.
Bekanntlich ist Onkel $ills System nicht das stabilste. Was passiert mit 
allegro (besser: mit den Daten) bei einem Hänger, bei einem Blue-Screen, 
bei :Diese Anwendung wird durch .... geschlossen!? Das braucht überhaupt 
nicht von allegro auszugehen!

Was passiert beim Speichern von allegro? Ich reime mir das so zusammen 
(biite um Korrektur, Herr Eversberg):
Beim Start wird die ADX-Datei schon zum SCHREIBEN geöffnet. Das 
schließe ich daraus, daß bei jedem Aufruf (also auch nur lesen!) die ADX-
Datei (nur sie!) die aktuelle Zeitmarke bekommt, was m.E. unnötig wenn 
nicht ein Fehler ist. Da - soviel ich weiß - beim Lesen in die Datei selber 
nicht geschrieben, sondern sie nur zum Schreiben geöfnet wird, hätte ein 
Absturz hier keine Folgen.
Soll wirklich ein Satz geschrieben werden, ist der Vorgang wohl folgender:
Das Schreibfenster wird geöffnet und der Text erfaßt. Zum Abspeichern 
wird in der ADX-Datei (Register 1, //-Einträge) nachgeschaut: Gibt es eine 
Stelle in der ADL-Datei, wo der neue Satz hinpaßt? Egal ob was gefunden 
wird oder nicht, wird dann die TBL-Datei geöffnet und das Schreibbit 
gesetzt. Ggf.wird die zu überschreibende Stelle in der ADL-Datei 
herausgesucht oder gleich eine neue Satznummer/Offset  vergeben, in die 
ADL-Datei geschrieben, dann in der ADX-Datei ggf. der Register-1-Eintrag 
gelöscht und die fälligen anderen Registereinträge geschrieben, die STL-
Datei ergänzt, dann STL-, ALD- und ADX-Datei geschlossen, TBL-Datei 
ergänzt und Schreibbit von TBL zurückgesetzt und ebenfalls geschlossen. 
Und das war's dann.

Es passiert also eine ganze Menge sowohl was die Dateien betrifft als 
auch die Programm- und Datenkommunikation. Und was passiert jetzt, 
wenn Onkel $ill dazwischenfunkt?
Herr Eversberg sagte, daß presto im Sekundentakt die tbl-Datei überprüft. 
Was passiert, wenn das Schreibbit gesetzt ist und der PC den Geist 
aufgibt? Dann ist es wohl mit der Prüfung vorbei und die tbl-Datei bleibt 
gesperrt bis ein Aufschrei den Administrator zum entsprechenden Handeln 
veranlaßt. Analoges gilt für Störung in der Datenkommunikation also vulgo, 
wenn jemand in die Leitung spuckt Und in beiden Fällen wäre es auch völlig 
wurscht, ob die Progamme auf dem Client liegen (wie für die Zukunft 
vorgeschlagen) oder vom Server geholt werden.

Da wir hier eine ziemlich heterogene Client-Landschaft haben, sowohl was 
Windows als auch was das Gerätealter betrifft, scheint mir des Pudels 
Kern (d.h. tbl-Datei gesperrt) in o.g. Szenario zu liegen. 

Was tun? Darüber hat schon Lenin ein Buch geschrieben. Hier wäre es 
hilfreicher, wenn jemand ein Administrator-Werkzeug kennen würde, das 
die Prozesse aufzeichnet und mit welchen Dateien sie arbeiten. Da das 
eine ziemlich längliche Angelegenheit sein könnte, wäre eine 
Einschränkung auf bestimmte Dateien wünschenswert. Eine NT-
Anwendung würde mir hier nichts nützen. Unter Unix müßte es doch 
sowas geben. Erschwerend ist hier, daß zwar die interessierenden Dateien 
auf dem (Unix-)-Server liegen, die Prozeßkommunikation aber über Samba 
erfolgt. Die log-Dateien von smb und nmb geben in der Normalform nichts 
her. Frage an die Samba-Gurus: Gibt es eine (wenn auch nur temporär 
sinnvolle) Parameter-Einstellung, die am besten die Frage beantwortet: IP-
Adresse xyz hat an der tbl-Datei gedreht und schläft seit einer halben 
Stunde. Das Gerät ist reif für Schrottplatz! Bei über 100 Geräte wäre das 
das Optimum!

Alles klar?

mfg gl




Mehr Informationen über die Mailingliste Allegro