MyTISM - Ein Datenbank- und Anwendungs-Framework

Im folgenden Text wird auf die einzelnen Schritte der Installation des PostgreSQL-Datenbank-Servers und des Java-Developer-Kits unter Windows eingegangen.

1.1.1. PostgreSQL

	Achtung
	Die Installation sollte als angemeldeter Administrator durchgeführt werden, da Installationsprobleme mit Benutzer-Konten berichtet wurden, die der Administrator-Gruppe "nur zugeordnet" waren.

Am Anfang steht der Download des Installations-Archivs. Dieses kann von

http://www.postgresql.org/ftp/win32

bezogen werden (sollte der Link irgendwann nicht mehr stimmen, gehe man direkt auf

http://www.postgresql.org

und klicke sich bis zum Windows-Download durch). Hier wählt man das ZIP-Archiv postgresql-8.0.3.zip zum Download aus.

Das heruntergeladene Archiv muss entpackt werden. U.a. liegen dann zwei Dateien auf der Festplatte die mit postgres beginnt und die Endung .msi hat - hiervon ruft man die kleinere Datei auf zum Starten der PostgreSQL-Installation.

Die Installationsabfolge ist weitestgehend unspektakulär, so dass nur auf einige "Spezialitäten" eingegangen wird.

Zu Beginn wählt man lediglich die Installationssprache aus, mit der man durch den weiteren Installationsverlauf geleitet wird.

Im Dialog "Installations-Optionen" stellt man ein, dass alle Sprachen installiert werden sollen und setzt das Installationsverzeichnis auf c:\db

Installationsoptionen-Dialog der PostgreSQL-Installation

Im Dialog "Dienste-Konfiguration" ändert man den Namen des Dienstes auf postgres und vergibt KEIN Passwort. Den folgenden Dialog, in dem man gefragt wird ob das fehlende Benutzerkonto angelegt werden soll, bstätigt mal - das anschliessend angezeigte Passwort kann man sich notieren, muss man aber nicht.

Im Dialog "Datenbank-Cluster initialisieren" würde man theoretisch das Encoding auf UTF-8 umstellen. Da es damit aber unter Windows noch ein paar Problemchen gibt, lässt man das einfach auf SQL-ASCII stehen.

	Achtung
	Wenn man auf der Kommandozeile per createdb eine neue Datenbank anlegt muss man jetzt aber daran denken das Encoding auf UTF-8 zu stellen. creatdb -U postgres -E UTF-8 DBNAME

Im gleichen Dialog setzt man das Passwort auf postgres

Alle weiteren Dialoge kann man einfach bestätigen.

Nachdem die Installation abgeschlossen ist, muss noch eine Einstellung in der Datei c:\db\data\pg_hba.conf vorgenommen werden: am Ende der Datei in der nicht auskommentierten Zeile den Text md5 durch trust ersetzen. An dieser Stelle wird auch ersichtlich warum man während der Installation ein doch vermeintlich schwaches Passwort wählen konnte - es werden nämlich eh nur Verbindungen direkt von der lokalen Maschine (127.0.0.1) akzeptiert und durch die Angabe von trust erspart man sich die Passwort-Abfrage.

Folgende Tuning-Massnahmen an der Datei c:\db\data\postgresql.conf sind nicht zwingend nötig, bringen aber doch einiges an Performance-Gewinn:

fsync = true
wal_buffers = 2000
commit_delay = 10000
commit_siblings = 500

Damit diese und obige Änderung wirksam werden, muss der PostgreSQL-Server "durchgestartet" werden.

net stop postgres
net start postgres

Hierfür werden natürlich die Sourcen benötigt, die man mittels des Programms SmartCVS aus dem CVS-Repository abrufen kann. Der Download des Programms ist auf http://www.smartcvs.com kostenfrei möglich.

Access Method: sserver
Server Name: cvs.mytism.de
Repository Path: cvs

Repository: {das eben definierte Repository}
Module(s): nrx
Local Directory: {das Verzeichnis, in das ausgecheckt werden soll; ein Verzeichnis nrx wird dort automatisch angelegt}
Checkout options: Default (keep sticky)
Project Name: nrx
Text File Encoding: Cp1252
Text File Encoding in Repository: ASCII

Zum Kompilieren wechselt man unterhalb des nrx-Verzeichnisses in das entsprechende Projekt-Verzeichnis und startet die Kompilierung mit folgendem Befehl:

j -ant

Das Ergebnis der Kompilierung liegt im Build-Verzeichnis (wo dieses zu finden ist, steht im Build-File des jeweiligen Projektes in der Variablen build.dir).

Sofern nicht bereits geschehen muss in PostgreSQL natürlich noch eine Datenbank angelegt werden. Dies macht man mithilfe des zentralen mytism-Scripts im Build-Verzeichnis.

./mytism init_db

Sofern alles klappt ist unter Linux mit dem Aufruf von

./mytism start

aus dem Build-Verzeichnis heraus alles erledigt.

chmod 755 DATEINAME

FIXME

	Achtung
	Die BTs müssen in jedem Fall vollständig bleiben und dürfen auf keinen Fall geflusht werden, wenn man eine Instanz umzieht. Grund ist, dass der SyncChecker sonst nicht prüfen kann, welche Transaktionen evtl. lokal noch aufgrund von Timing-Problemen beim Syncen (lang dauernde Speichervorgänge auf dem Server, von dem gesynct wird, die später vom SyncChecker nachgezogen werden) fehlen.

FIXME

Achtung

Beim Neu-Aufsetzen von Knoten aus einem aktuellen Backup, das bereits alle alten Daten des erneut aufgesetzten Servers enthält, muss nichts besonderes beachtet werden. Hierbei geht man am besten so vor, dass man die syncende Instanz alle lokalen Änderungen zunächst auf den autoritativen Server syncen lässt. Danach fährt man den neu aufzusetzenden Server herunter und zieht erst dann ein frisches Backup vom autoritativen Server, mit dem man dann den syncenden Server neu aufsetzt wie oben beschrieben. Im Gegensatz dazu muss beim Neu-Aufsetzen von Knoten aus einem alten Backup, das nicht alle alten Daten des erneut aufgesetzten Servers enthält, eine neue Node-Nummer vergeben werden. Hintergrund: Wenn die BN gleich bleibt, so werden beim Sync alle Transaktionen übersprungen, die von diesem Knoten stammten (da diese ja "eigentlich" auf dem Knoten vorhanden sein müssten, dieser war ja der Ursprung der Transaktionen / Daten). Am einfachsten kann man eine neue Node-Nummer setzen, indem man die Nodenummer in der mytism.ini einfach leer lässt. Es wird dann bei der ersten Verbindung mit dem autoritativen Server automatisch eine Nummer vergeben und in die mytism.ini eingetragen.

Der Client lässt sich per Kommandozeile aus dem Build-Verzeichnis starten

java -jar deploy/XXX-Client.jar localhost

oder per JavaWebStart

/usr/lib/java/jre/javaws/javaws "http://localhost:8080/deploy/"
// statt localhost kann auch eine IP-Adresse angegeben werden

Das Logfile bzw. Meldungen des Client werden beim Start von der Kommandozeile in der jeweiligen Shell ausgegeben, in der der Client gestartet wurde. Ausserdem wird im Temp-Verzeichnis (unter Linux /tmp/) eine Log-Datei namens "client-log.txt" angelegt.

	Anmerkung
	Unter Windows-Systemen wird die heruntergeladene Anwendung (Datei mit der Endung ".jnlp") im Profil gespeichtert, was bei Systemen, deren Profil auf einem zentralen Server liegt den An- bzw. Abmelde-Prozess verlangsamen kann. Im JavaWebStart lässt sich der Speicherort der heruntergeladenen Anwendung festlegen. Hier wählt man dann einen geeigneteren Speicherort aus.

Das Vorhandensein dieser Datein signalisiert dem Server, dass bestimmte (normalerweise eher recht lange dauernde) Überprüfungen bereits durchgeführt wurden.

Um eine der Überprüfungen (nochmal) ablaufen zu lassen, z.B. nach dem Einspielen einer Datenbank-Sicherungskopie, einfach die entsprechende(n) Datei(en) löschen; nach dem Neustart des Servers wird die entsprechende Überprüfung dann durchgeführt.

FIXME (Erklärung)

FIXME - Was darf wann und zu welchem Zweck gelöscht werden?

FIXME Einleitende Erklärung zu BN, BU, BS, Skript-Service, Import-Service

method verifyOnServer(nodeNumber=Long, user=Benutzer, tx=Transaction)
  if cancelRecalc() then
     return
  super.verifyOnServer( nodeNumber, user, tx )
  if \ getWartendNN() & getBelegNr() == null then
     -- eindeutige BelegNr ziehen und zuweisen
     setBelegNr( BU.nextValueAsString( getClass().getName()'.BelegNr', nodeNumber, user, tx, getBOLoader() ) )
          

Rechteverwaltung bedeutet, dass man bestimmten Personen das Lesen, Ändern, Neuanlegen oder Löschen von bestimmten Objekten oder Daten (in MyTISM also BOs bzw. deren Attribute) erlauben oder verweigern will. Hierbei sollte man sich folgende Fragen stellen:

Beispiel:

Im Folgenden soll kurz erklärt werden, wie man diese Rechteverwaltung in MyTISM realisieren kann.

Ein Benutzer steht für eine einzelne reale oder virtuelle Person (oder genauer eigentlich: Für ein Benutzerkonto; auch wenn es nicht vorkommen sollte kann ein Benutzer(konto) im Prinzip von mehreren Personen gemeinsam - wenn auch nicht unbedingt gleichzeitig - benutzt werden). Die definierten Benutzer bestimmen, wer überhaupt auf ein MyTISM-System zugreifen darf.

Der Benutzer "Admin", der alles sehen kann und alles darf, wird für jedes MyTISM-System automatisch angelegt. Weitere Benutzer können dann je nach Bedarf hinzugefügt werden, haben allerdings dann noch keinerlei Rechte. Ein Hinweis direkt hierzu: Allein um sich überhaupt anmelden zu können, müssen Benutzer schon gewisse Leserechte bekommen! Diese hier im Einzelnen aufzuführen wäre zu aufwändig - einfacher ist es eine "MT_ALL"-BO-Maske zu erstellen.

Das Benutzer-Formular in Solstice

Für dieses Tutorial nehmen wir mal an, dass folgende Benutzer definiert sind:

Mehrere Benutzer kann man in einer Gruppe zusammenfassen. Da Rechte in MyTISM nur an Gruppen und nicht an einzelnen Benutzern hängen können, muss jeder Benutzer mindestens einer Gruppe angehören.

Eine Gruppe "Admins" wird automatisch gebaut und enthält (am Anfang nur) den Benutzer "Admin".

Das Gruppe-Formular in Solstice, hier die Liste der für die Gruppe eingetragenen Benutzer

In diesem Tutorial benutzen wir folgende Gruppen:

Um Rechte für bestimmte BOs festzulegen, muss man die entsprechenden BOs natürlich irgendwie auswählen. Dies geschieht mit Hilfe der sog. BOMasken; damit definiert man eine Menge von BOs, für welche man dann einer oder mehreren Gruppen bestimmte Rechte erlauben oder verweigern will.

Nehmen wir an, wir haben BOs vom Typ "Kunde" in unserer Datenbank:

Dann können wir wie folgt eine BOMaske bauen, die alle vorhandenen Kunden-BOs auswählt:

Das BOMaske-Formular in Solstice

Unter "Name" tragen wir einen passenden Namen für die BOMaske ein. Der Name kann frei gewählt werden, sollte aber irgendwie sinnvoll sein :-) In unserem Beispiel hätten wir genauso gut z.B. auch "Alle Kunden" nehmen können. (FIXME es gibt eine Namenskonvention?)

Unter Beschreibung sollte man einen kurzen Text eintragen, der in ein paar Worten "menschenlesbar" erklärt, welche BOs mit dieser Maske ausgewählt werden.

Der wichtigste Punkt ist "Entitaet": Hier bestimmt man, BOs welchen Typs diese BOMaske auswählt. Da wir in unserem Beispiel alle Kunden (also BOs vom Typ "Kunde") wollen, tragen wir hier den BO-Typ "Kunde" ein.

Wenn Sie unter Attribut auch einen Wert angeben, so bezieht sich die Maske nur auf dieses Attribut der BOs, d.h. sie können hiermit Rechte für einzelne Eigenschaften von BOs vergeben.

return bo.Id.longValue() > 1000

return bo.IstSchoenNN

Wir haben jetzt Gruppen, denen wir Rechte geben können und haben eine Möglichkeit, Mengen von BOs definieren, für welche diese Rechte gelten sollen. Was fehlt ist natürlich noch die Definition dieser Rechte.

In den RechteZuweisungen werden alle Komponenten zusammengeführt. Hier gibt man an, wer (Gruppen) mit was (BOMaske) wie arbeiten darf.

Das RechteZuweisungs-Formular in Solstice

Wir wollen in unserem Beispiel allen Benutzern etwas erlauben, also tragen wir unter "Gruppe" die bereits definierte Gruppe "Benutzer" ein.

"Position" wird z.Zt. noch nicht benutzt und bleibt leer.

Wir wollen Rechte für alle Kunden-BOs setzen, also tragen wir unter "Maske" unsere eben definierte BOMaske "Kunden" ein, die ja alle vorhandenen Kunden-BOs auswählt.

Jetzt können wir auch bestimmen, was die "Benutzer" mit allen "Kunden" machen dürfen. Da Änderungen an den Kundendaten Chefsache sind, erlauben wir nur das "Lesen".

Zu guter Letzt sollte man auch hier wieder einen kurzen "menschenlesbaren" Kommentar eintragen, der aussagt, was diese RechteZuweisung genau bewirkt. Dieser im Feld "Bemerkung" hinterlegte Kommentar wird auch in der Meldung angezeigt, die dem Anwender angezeigt wird, wenn er für die jeweilige Aktion keine Rechte besitzt.

Nachdem wir diese RechteZuweisung abgespeichert haben, dürfen fortan alle Benutzer die Kundendaten einsehen!

Soweit, so gut, aber irgend jemand muss ja auch die Kundendaten auf dem aktuellen Stand halten. Da das Sache der Chefs ist, benötigen diese natürlich auch entsprechende Rechte d.h. wir bauen noch eine weitere RechteZuweisung:

Chefs dürfen alles!

Unter "Gruppe" wählen wir logischerweise "Chefs".

Da wir auch hier wieder etwas für alle Kunden-BOs definieren wollen, tragen wir unter "Maske" wieder unsere eben definierte BOMaske "Kunden" ein.

An Rechten vergeben wir jetzt aber wesentlich mehr, nämlich alles was möglich ist:

Mit Hilfe der Ablehnen-Rechte, die immer Priorität gegenüber allen anderen Rechten für das selbe BO haben, ist natürlich eine "Alles zulassen und Ausnahmen definieren" Strategie bis zu einem gewissen Punkt tolerabel, speziell in kleinen Installationen. Hier bietet sich z.B. an die Quertabellen über die Vererbung dem gemeinen Benutzer zum Editieren zu sperren indem man eine Gruppe "KeineQuertabellenÄndern" oder ähnliches zu erstellen und über die Rechtezuweisung ein (Ablehnen Erstellen Löschen Schreiben) zuzuweisen. Einziges Manko ist dabei die Menge der zu erstellenden Gruppen und die Menge der Ausschlüsse für einen normalen Benutzer - man merke sich: Wenn ein Ablehnen-Recht einmal definiert wurde für irgendeine Gruppe dieses Benutzers, wird es zur Anwendung kommen. Eine Aufhebung eines solchen Rechts ist (bislang) nicht vorgesehen.

In etwas größeren Umgebungen mit etwas mehr Schema und entsprechender Evolution wird dieses Verfahren müßig, weil bei Updates sofort die entsprechenden "Schotten" definiert und gebaut werden müssen, um editierfreudige Benutzer davon abzuhalten, Unheil anzurichten (meist machen diese Benutzer das ja nicht absichtlich...). Im folgenden möchte ich aufzeigen, wie man eine Rechtestruktur rein auf "Grant"-Basis erstellt, die als Grundlage für eigene Verfahren dienen kann, eine komplexe Rechtestruktur für ein großes Projekt zu erstellen.

return (user.Id.equals(bo.Id));

for(gr:user.GruppenIterator){
  if(gr.Id==bo.Id) return true;
}
return false;

for(gr:user.GruppenIterator){
  for(usr:gr.BenutzerIterator){
    if(usr.Id==bo.Id) return true;
  }
}
return false;

return bo.Elter!=null;

Situation: Der Integrity-Check beim Serverstart meldet doppelte IDs bzw. es ist anderweitig aufgefallen, dass in der Datenbank gleiche IDs für verschiedene Objekte mehrfach vergeben wurden (kann z.B. passieren, wenn ein Backup einer Datenbank eingespielt wurde, aber vergessen wurde, vor dem darauffolgenden Serverstart die Dateien .init-keygen und .checked-firstnodestart zu löschen).

Fehlerbehebung (bei synchonisierendem System; wenn nur ein einzelner Server zu fixen ist können die "Synchronisierender Server"-Schritte weggelassen werden; alle Kommandos müssen im jeweiligen Projektverzeichnis stehend ausgeführt werden; ggf. heißt das Kommando statt "./mytism" auch PROJEKTNAME, also z.B. "./oashi"):

Beide Server sollten danach ohne Fehlermeldungen starten; auf der Status-Webseite kontrollieren, ob auf dem authoritativen Server der Sync-Account des synchronisierenden Servers angemeldet ist; im logs/daily.log des synchronisierenden Servers kontrollieren, ob die Synchronisation läuft (Nach Meldungen wie "INFO 10:15:59.355 [shi->oashi.oashi.com] SyncService logSyncLocalToRemote(637)- >>>> BT[12345678] from 11-12-12 10:15:57 SrvCrea 11-12-12 10:15:57" bzw. "... logSyncRemoteToLocal(...) ..." Ausschau halten; ggf. selbst mal eine Änderung an einem Objekt auf einem der Server machen).