Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten.
Druckvorgang starten.
Zur Standardansicht zurückkehren.
Update
Muss ich regelmäßig updaten und wenn ja, was?
Für die Beschreibung des Server-Updates deiner Kieselstein ERP Installation siehe die betriebssystemspezifischen Updates in den Unterkapiteln
Allgemeine Punkte zum Thema Updaten / Aktualisieren
Da wir in der Praxis durchaus auch erleben, dass einfach ohne jegliche Notwendigkeit Updates eingespielt werden, hier unsere Gedanken und Informationen dazu.
Wir gehen hier davon aus, dass dein Kieselstein ERP-Server in einem sicheren Netzwerk betrieben wird.
Die nachfolgenden Infos sind für Server die vorne an der Front (= WorldWideWeb) stehen, wie z.B. WebServer, nicht zutreffend.
-
Wozu muss aktualisiert werden? Gibt es einen wichtigen Grund?
Nur dann sollte ein Update eingespielt werden.
Es gilt der alte Grundsatz, never touch a running system!
Wir können dies nur bestätigen.
-
Die Kieselstein ERP eG mit Ihren Consultants sind KEINE IT-Betreuer.
Bitte suche dir einen sehr guten IT-Betreuer. Der auch etwas von IT-Infrastuktur versteht und auch weiß, warum man mechanisch getrennte Backups braucht.
-
Welchen Wert hat dein ERP System für dein Unternehmen?
Welche Dinge werden passieren, wenn dein ERP nicht verfügbar ist?
- ich weiß nicht was ich heute produzieren sollte
- ich weiß nicht welche Waren ich einkaufen sollte
- ich kann keinen Kunden anrufen und ihm erklären, dass er seine Lieferung später bekommt
- ich habe keine Zeiterfassung meiner Mitarbeiter:innen und auch nicht meiner Maschinen
- das kann man noch lange fortsetzen
Wenn nun durch die, bei manchen Menschen ausgeprägte Update-Manie, täglich / wöchentlich neue Versionen in das Live-System eingespielt werden, das oft noch ohne ein qualifiziertes Backup / Fallback zu haben, dein ERP System, warum auch immer, nicht mehr funktioniert, so können wir von der Kieselstein ERP eG dazu nur sagen, Pech gehabt. Hoffentlich etwas dazu gelernt.
Unsere Techniker:innen sind Programmierer oder Consultants, aber keine IT-Leute die sich mit Servern und PC’s mehr als notwendig herum ärgern.
Richtige Update-Vorgehensweise
- Ist das Update wirklich notwendig
- erstelle ein vollwertiges Backup. Du musst im Falle des Falles auf diesen Stand zurückstellen können.
Manche unserer Mitglieder machen das in dem Sinne, dass die VM (virtuelle Maschine) des Echtsystems gesichert und kopiert wird. Beachte dazu das Thema vollwertige Sicherung einer VM mit der PostgresQL!
Nun können am Echtsystem die Updates durchgeführt werden. Sollten sich Probleme herausstellen, kann man auf die qualifizierte und vollwertige Sicherung zurückgreifen.
Oder es werden auf der kopierten VM die notwendigen Tests durchgeführt und erst danach die Updates am Echtsystem ausgerollt.
- Selbstverständlich ist dein IT-Betreuer greifbar und deine Tests der neuen Version werden zu normalen Bürozeiten durchgeführt und sind nicht zeitkritisch. D.h. ob eine Fehlerbehebung einige Tage dauert ist nicht relevant.
Was mache ich, wenn mein System gecrasht ist
In solchen Fällen, welche in der Regel, bei gut gepflegter Hardware, sehr sehr selten auftreten, helfen wir nach besten Kräften. Wir wollen grundsätzlich dass die Systeme laufen. So ist es uns kürzlich gelungen, ein gechrastes Windowssystem mit guten vorhandenen Backupdaten innerhalb von wenigen Stunden, nachdem der neue Server wieder zur Verfügung gestanden ist, zum Laufen zu bringen.
Dein Kieselstein ERP läuft immer auf einem Server, auch wenn der Rechner mit vielleicht etwas geringerer Leistung ausgelegt ist.
Server sind immer mit gespiegelten Platten oder Raid-Platten ausgestattet. Es läuft eine Festplattenüberwachung und die Meldungen des Überwachungssystems werden erst genommen und umgehend, raschest möglich, durch deinen IT-Betreuer beseitigt.
Dass ein qualifiziertes und verifiziertes Backup zur Verfügung steht, ist selbstverständlich.
Zusammenfassend:
Seid euch selber des Wertes eurer Daten und Systeme bewusst. Durch die Update Manie wird nur eine Geringschätzung den eigenen Systemen gegenüber zum Ausdruck gebracht.
Update Prozess für dein Kieselstein ERP:
Vor jedem Update Prozess muss sowohl von der Datenbank als auch von den File-Systemen ein Backup gemacht werden.
Update Schritte je Betriebssystem:
Debian Update
Windows Update
Clients
Nach dem Update des Servers müssen auch die Clients wieder aktualisiert werden.
Siehe hierfür bitte Installation Clients.
Sollte die Version des Kieselstein-Clients nicht mit der Version des Servers oder der Datenbank übereinstimmen kommt eine entsprechende Fehlermeldung und kann die Anmeldung nicht durchgeführt werden.
Fehlermeldungen mit Client-Version 0.0.13 oder kleiner:
Dies wird nach dem anmelde Versuch bei Versionen, welche vor der Versionierung erstellt wurden angezeigt.
Hier muss das Client-Programm aktualisiert werden.
Ab Kieselstein Version 0.0.13 werden die jeweiligen Versionen angezeigt und die Anmeldung verhindert:
Troubleshooting
Wenn die Datenbankversion nicht mit der Wildfly Installation übereinstimmt,
kommt beim Starten des Clients folgende Fehlermeldung:
bzw. bei einem Umstieg von einer Version vor 0.0.13:
Am Server wird hier auch ein Fehler geloggt (kieselstein-dist/wildfly-12.0.0.Final/standalone/log/server.log)
2024-02-28 09:10:26,607 ERROR [com.lp.server.system.ejbfac.SystemFacBean] (EJB default - 8) Database version may not match server version (0.0.14)! Make sure the database was updated.: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not extract ResultSet
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1619)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1106)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1033)
at org.jboss.as.jpa.container.AbstractEntityManager.find(AbstractEntityManager.java:213)
Hier muss der Dienst wieder gestoppt werden und das Liquibase update durchgeführt werden.
Releasehinweise
TODO Is a comming feature!
In Zukunft kann es sein, dass nach einem Versionsupdate manuelle Datenbereinigungen durchgeführt werden müssen.
Sollte eine solche Datenbereinigung notwendig sein, wird nach der Anmeldung eines Benutzer eine Liste (wenn mehrere) der noch nicht durchgeführten Aktionen angezeigt.
Die Punkte in der Releasehinweise-Tabelle können nur von dem Kieselstein Admin-Benutzer als erledigt markiert werden.
Solange noch nicht erledigte Releasehinweise vorhanden sind, werden diese jedem Benutzer bei der Anmeldunge angezeigt.
1 - Update Kieselstein ERP Server unter Debian
Update Kieselstein ERP Server unter Debian
Applicationsserver Updaten
- Dist-Pack auf den Server kopieren
- Dienste beenden
systemctl stop kieselstein-main-server.service
systemctl stop kieselstein-rest-server.service
- Alte Programmdateien löschen:
rm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.ear
rm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.war
rm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.rar
rm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.deployed
rm /opt/kieselstein/dist/apache-tomcat-*/webapps/*.war
- und auch alle Verzeichnisse mit kieselstein-rest##. löschen
- Dist-Packet über die bestehende Installation entpacken
tar -xvf <pfad-zum-dist-packet>.gz -C /opt/kieselstein
- Client-Scripte anpassen
- Es muss geprüft werden, ob es manuelle Änderungen im Client-Paket für die Startskripte gab und diese eventuell bei den neuen Startscripten nachziehen (Hostname und Splashscreen zum Beispiel).
- Alte Client-Scripte löschen oder klar markieren als OLD (Siehe im Verzeichnis /opt/kieselstein/dist/clients/)
- Berechtigungen wieder für den Kieselstein Ordner setzen
chown -R kieselstein:kieselstein /opt/kieselstein
- Wenn im dist-Verzeichnis mehrere Tomcat oder Wildfly Versionen enthalten sind prüfen welche verwendet wird und die alten löschen
- Prüfen welche Tomcat-Version verwendet wird:
cat /opt/kieselstein/dist/bin/launch-kieselstein-rest-server.sh
- Suche nach Zeile: export CATALINA_HOME="${KIESELSTEIN_DIST}/apache-tomcat-x.x.x", diese Tomcat Version wird verwendet die andere(n) müssen gelöscht werden.
- Prüfen welche Wildfly-Version verwendet wird:
cat /opt/kieselstein/dist/bin/launch-kieselstein-main-server.sh
- Suche nach Zeile: wildfly_bin_dir=${KIESELSTEIN_DIST}/wildfly-x.x.x.Final/bin, diese Wildfly Version wird verwendet die andere(n) müssen gelöscht werden.
- Achtung Aktuell sind im Wildfly noch die Report-Dateien enthalten so wie eventuelle Anwender-Reports.
- Es müssen, wenn sich die Wildfly Version ändert, vor dem Löschen des alten Wildfly Ordners alle Anwender-Reports in den neuen Wildfly kopiert werden.
- /opt/kieselstein/dist/wildfly-.Final/server/helium/report//anwender
Datenbankmigrationen durchführen
Hinweis: Wenn Kieselstein Version kleiner als 0.0.13 ist:
Muss die initiale Migration gemacht werden.
Das gilt auch für den Start mit den Demodaten.
Installation Liquibase
Für die Datenbankmigrationen, muss das Tool liquibase installiert werden (mit root Rechten).
wget -O- https://repo.liquibase.com/liquibase.asc | gpg --dearmor > liquibase-keyring.gpg && \
cat liquibase-keyring.gpg | sudo tee /usr/share/keyrings/liquibase-keyring.gpg > /dev/null && \
echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/liquibase-keyring.gpg] https://repo.liquibase.com stable main' | sudo tee /etc/apt/sources.list.d/liquibase.list
apt-get update
apt-get install liquibase
Initial-Migrationen setzen
- In das Liquibase Verzeichnis gehen
cd /opt/kieselstein/dist/bootstrap/liquibase
- Bestehende Datenstrukturen als bereits migriert markieren
./liquibase.sh changelog-sync --label-filter="0.0.12"
ACHTUNG Wenn die Datenbank von der Default-Installation abweicht müssen in der /opt/kieselstein/dist/bootstrap/liquibase/liquibase.properties Datei die Verbindungseinstellungen angepasst werden:
liquibase.command.url=jdbc:postgresql://localhost:5432/KIESELSTEIN
liquibase.command.username=postgres
liquibase.command.password=postgres
Datenbank Updaten
cd /opt/kieselstein/dist/bootstrap/liquibase
./liquibase.sh update
Hinweis
Sollten hier lange Listen von kryptischen Befehlen kommen, funktioniert das Datenbankupdate nicht.
Dienste wieder aktivieren
systemctl start kieselstein-main-server.service
systemctl start kieselstein-rest-server.service
Aktualisieren der Clients
Siehe hierfür bitte Installation Clients.
Verlagerung der Anwenderreports
Bis inkl. der Version 0.2.14 wurden die Anwender-Reports innerhalb des Reportverzeichnisses unter anwender abgelegt.(?:\kieselstein\dist\wildfly-12.0.0.Final\server\helium\report..)
Ab der Version 1.0.3 (die dazwischen solltest du nicht verwenden) gibt es die Trennung in Dist und Data. Details siehe bitte
2 - Update Kieselstein ERP Server unter Windows Server
Update Kieselstein ERP Server unter Windows Server
Schritt für Schritt Anleitung
Applikationsserver Updaten
- Dist-Pack auf den Server kopieren
- Dienste beenden
- Beide Kieselstein Dienste (Kieselstein Main Server & Kieselstein REST Server) beenden
- Alte Programmdateien löschen:
- Im Verzeichnis ?:\kieselstein\dist\wildfly-12.0.0.Final\standalone\deployments
- Alle Dateien mit den Dateiendungen ear, rar und war löschen
- und auch die deployed löschen
- Im Verzeichnis ?:\kieselstein\dist\apache-tomcat-8.5.93\webapps
- Alle Dateien mit den Dateiendung war löschen
- Alle Verzeichnisse mit kieselstein-rest##. löschen
- im Verzeichnis ?:\kieselstein\dist\clients alle gz Dateien löschen
- Dist-Packet über die bestehende Installation entpacken (In der Windows Eingabeaufforderung cmd.exe)
tar -xvf <pfad-zum-dist-packet>.gz -C ?:\kieselstein\
- Client-Scripte anpassen
- Es muss geprüft werden, ob es manuelle Änderungen im Client-Paket für die Startskripte gab und diese eventuell bei den neuen Startscripten nachzeihen (Hostname und Splashscreen zum Beispiel).
- Alte Client-Scripte löschen oder klar markieren als OLD (Siehe im Verzeichnis ?:\kieselstein\dist\clients)
- TODO Scripte Pfade müssen noch angepasst werden.
- Wenn im dist-Verzeichnis mehrere Tomcat oder Wildfly Versionen enthalten sind prüfen welche verwendet wird und die alten löschen
- Prüfen welche Tomcat-Version verwendet wird:
cat ?:\kieselstein\dist\bin\launch-kieselstein-rest-server.sh
- Suche nach Zeile: export CATALINA_HOME="${KIESELSTEIN_DIST}/apache-tomcat-x.x.x", diese Tomcat Version wird verwendet die andere(n) müssen gelöscht werden.
- Prüfen welche Wildfly-Version verwendet wird:
cat ?:\kieselstein\dist\bin\launch-kieselstein-main-server.sh
- Suche nach Zeile: wildfly_bin_dir=${KIESELSTEIN_DIST}/wildfly-x.x.x.Final/bin, diese Wildfly Version wird verwendet die andere(n) müssen gelöscht werden.
- Achtung Aktuell sind im Wildfly noch die Report-Dateien enthalten so wie eventuelle Anwender-Reports.
- Es müssen wenn sich die Wildfly Version ändert vor dem Löschen des alten Wildfly Ordners alle Anwender-Reports in den neuen Wildfly kopiert werden.
- ?:\kieselstein\dist\wildfly-*.Final\server\helium\report*\anwender
Datenbankmigrationen durchführen
Hinweis: Wenn Kieselstein Version kleiner als 0.0.13 ist:
Muss die initiale Migration gemacht werden.
Das gilt auch für den Start mit den Demodaten.
Installation Liquibase
Für die Datenbankmigrationen, muss das Tool liquibase installiert werden.
Akutelle Liquibase Version vom git Repository runterladen:
https://github.com/liquibase/liquibase/releases
Hier biss zu den Assets runterscrollen und dann den passenden (Windows-)Installer auswählen. Z.B.: liquibase-windows-x64-installer-x.x.x.exe
Den Installer am Server ausführen und durchklicken.
Bitte darauf achten, dass Add Liquibase to PATH angehakt bleibt.
Achtung nach der Installation von Liquibase müssen für die weiteren Arbeiten neue Eingabeaufforderungen (cmd) gestartet werden! Ein Neustart des Servers ist nicht erforderlich.
ACHTUNG
Das Liquibase ergänzt die Pfad-Angabe nur Benutzer spezifisch.
Das bedeutet, wenn du danach das Update unter einem anderen Benutzer machst, hast du keinen Zugriff. Unsere Empfehlung. Verschiebe die Pfad-Ergänzung von den Benutzervariablen in die Systemvariablen.
Initial-Migrationen setzen
- In der Windows Eingabeaufforderung cmd.exe
- In das Verzeichnis wechseln
cd ?:\kieselstein\dist\bootstrap\liquibase
- Bestehende Datenstrukturen als bereits migriert markieren
liquibase changelog-sync --label-filter="0.0.12"
ACHTUNG Wenn die Datenbank von der Default-Installation abweicht müssen in der ?:\kieselstein\dist\bootstrap\liquibase\liquibase.properties Datei die Verbindungseinstellungen angepasst werden:
liquibase.command.url=jdbc:postgresql://localhost:5432/KIESELSTEIN
liquibase.command.username=postgres
liquibase.command.password=postgres
Datenbank Updaten
In der Windows Eingabeaufforderung cmd.exe
cd ?:\kieselstein\dist\bootstrap\liquibase
liquibase update
Hinweis
Sollten hier lange Listen von kryptischen Befehlen kommen, funktioniert das Datenbankupdate nicht.
Prüfen ob das Update funktioniert hat
In der Praxis hat sich bewährt, dass man, vor dem Start der Dienste, zumindest den Main-Prozess als “Programm” startet.
Idealerweise wechselst du dazu in das Verzeichnis ?:\kieselstein\dist\bin und startest launch-kieselstein-main-server.bat.
Dieser muss problemlos durchlaufen.
Sollte hier eine Meldung ähnlich nachfolgender kommen:
"(" kann syntaktisch an dieser Stelle nicht verarbeitet werden
so fehlt in deinen Pfaden der Zugriff auf die postgresQL Runtime Programme.
Trage diese in den Pfaddefinitionen ein.
- Problemlos durchlaufen bedeutet, dass der Startschirm angezeigt werden muss. Dieser sieht unter Windows wie folgt aus:
Wenn der Start durchgelaufen ist, was je nach Performance der Maschine auch mal ein paar Minuten dauern kann, so kommt danach die Anzeige des sogenannten Shoptimers
Damit siehst du, dass dein Server läuft. Nun kannst du diesen mit Strg+C stoppen und den Dienst wieder aktivieren.
Nachtragen PostgresQL Runtime Pfad
- Rechtsklick auf das Windows Start-Symbol
- System
- suche nun erweiterte Systemeinstellungen. Je nach Windows-Version ist dies optisch an einem anderen Platz, aber immer unter System Info zu finden
- Umgebungsvariablen anklicken
- Suche nun im unteren Bereich (Systemvariablen) die Variable Path
und klicke auf bearbeiten
-
Hier muss nun, abhängig von der verwendeten pgAdmin Version der Pfad auf die pgAdmin runtime eingetragen sein. Bei pgAdmin 4 V7 ist dies “c:\Program Files\pgAdmin 4\v7\runtime”. Bei pgAdmin 4 V8 ist dies “c:\Program Files\pgAdmin 4\runtime”.
- Wenn alles eingetragen ist, beende zumindest den Umgebungsvariablen und den Systemeigenschaften Dialog.
- starte ein neues CMD-Fenster und gib psql (+ Enter) ein. Es muss die Abfrage des psql nach dem Benutzerpasswort kommen. Kommt eine Meldung mit *Der Befehl “psql” ist entweder falsch ….. *so ist deine Pfad-Definition falsch, womit auch der Serverstart nicht funktionieren wird.
Funktioniert dies, würde ich mit der oben beschriebenen Prüfung fortfahren.
Dienste wieder aktivieren
- Beide Kieselstein Dienste (Kieselstein Main Server & Kieselstein REST Server) starten
Aktualisieren der Clients
Siehe hierfür bitte Installation Clients.
Verlagerung der Anwenderreports
Bis inkl. der Version 0.2.14 wurden die Anwender-Reports innerhalb des Reportverzeichnisses unter anwender abgelegt.(?:\kieselstein\dist\wildfly-12.0.0.Final\server\helium\report..)
Ab der Version 1.0.3 (die dazwischen solltest du nicht verwenden) gibt es die Trennung in Dist und Data. Details siehe bitte
Probleme / Lösungen
Nachfolgend eine Sammlung von bisher bekannten Problemen und deren Lösungen beim Updateprozess. Vom Grundgedanken her gelten diese Dinge für beide Betriebssysteme, auch wenn die Aufrufe und die erforderlichen Betriebssystemspezifischen Rechte durchaus unterschiedlich sein können.
Liquibase meldet Checksum Konflikt
Während des Liquibase Updates kommen Fehlermeldungen. Wie z.B.:
Starte Liquibase am 08:47:40 (Version 4.28.0 #2272, kompiliert am 2024-05-16 19:00+0000)
Liquibase Version: 4.28.0
Liquibase Open Source 4.28.0 by Liquibase
ERROR: Exception Details
ERROR: Exception Primary Class: ValidationFailedException
ERROR: Exception Primary Reason: Validierung war nicht erfolgreich:
Bei 1 ChangeSets stimmt die Prüfsumme nicht mehr mit der Historientabelle überein.
changelogs/0.1.1/punkt_ist_dezimaltrenner_parameter.xml::add-parameter::KSE was:
> 9:2e4dc472a79dcf110b919b796195b677 but is now: 9:ff143e7c43a38123ddfb731c38d613c9
Siehe dazu
bzw.
Clear Checksums
run-liquibase.bat clear-checksums (für Linux ./liquibase.sh clear-checksums)
Um eventuell falsche Checksums zu löschen und damit weiter zu kommen.
Aufruf von ?:\kieselstein\dist\bootstrap\liquibase\ aus
Siehe zusätzlich auch –help
Die Checksum in der Tabelle manuell richtig stellen
Ich habe dafür folgendes Script verwendet. Dieses ist sicherlich nicht vollständig und muss gegebenenfalls auf die aktuelle Situation angepasst werden. Die Vorgehensweise sollte damit aber klar sein.
ACHTUNG:
Ob diese Vorgehensweise die Konsistenz deiner Daten bzw. die Konsistenz deiner Datenbank zerstört, kann hier nicht geklärt werden. Achte auf die Inhalte der Liquibase Änderungsscripte. Es gilt dies auch für das Clear Checksums
– korrigieren der checksum der zwischenversion der 0.1.1
update databasechangelog set md5sum = ‘9:ff143e7c43a38123ddfb731c38d613c9’ where
md5sum=‘9:2e4dc472a79dcf110b919b796195b677’;
update databasechangelog set md5sum = ‘9:ff143e7c43a38123ddfb731c38d613c9’ where
md5sum=‘9:67af6ebc94a79ccc6073d7044b4fe2dc’;
Spalte ist bereits vorhanden
Es kommt beim Update eine Meldung dass die Spalte xy bereits in der Datenbank eingetragen ist.
Wenn man sich sicher ist, dass in der Tabellen Spalte KEINE Einträge sind, kann man diese einfach löschen und danach das Update erneut ausführen.
Ist dem nicht so, so kann man das betreffende XML entsprechend auskommentieren. Die Update-XMLs, welche Versionsweise organisiert sind, findest du unter
?:\kieselstein\dist\bootstrap\liquibase\changelogs\Versionsnummern
Hier das betreffende XML heraussuchen und z.B. die Extension mit .nix ergänzen. Danach das Update erneut ausführen.
Passend zu obiger Fehlermeldung:
?:\kieselstein\dist\bootstrap\liquibase\changelogs\0.0.14\los_material_vollstaendig_parameter.xml
Kurzfassung des Updatevorgangs
Wenn auf deinem Kieselstein bereits die Liquibase Version installiert ist, also ab 0.1.0 so hat sich folgende Vorgehensweise bewährt:
- herunterladen des aktuellen Releases
- stoppen der Dienste kieselstein-rest-server, kieselstein-main-server
- kopieren des ..\kieselstein\dist Verzeichnises auf die bisherige Versionsnummer (siehe d:\kieselstein\dist\VERSION.txt)
- Ausführen des loeschen.bat
- kopieren des im kieselstein-distpack-0.2.4.tar.gz enthaltenen dist auf das (bereinigte) dist Verzeichnis. Überschreiben aller vorhandenen Dateien.
ACHTUNG: Es werden damit (Stand Juni 2024) alle ev. speziell angepassten fremdsprachigen Reports durch den Standard überschrieben. Änderung ist geplant.
- Update der Datenbank durch inital.bat
- Anpassen der Clientdateien
- üblicherweise gibt es im d:\kieselstein\dist\ ein client.zip mit den aktuellen Daten für die Clients.
- das lib löschen
- aus ?:\kieselstein\dist\clients\kieselstein-ui-swing-0.2.4.tar.gz das lib in obiges client.zip einkopieren
- im bin das kieselstein-ui-swing.bat die Zeile mit
set CLASSPATH=%APP_HOME%\lib\kieselstein-ui-swing-0.2.4.jar; …….. in dein speziell auf deine Installation angepasstes kieselstein-ui-swing.bat übernehmen.
- Dienste starten und gegebenenfalls unter d:\kieselstein\dist\wildfly-12.0.0.Final\standalone\deployments prüfen, dass der Wildfly tatsächlich startet.
Gegebenenfalls auch den Start des RestAPI Servers (Tomcat) durch Aufruf der RestAPI Dokumentation prüfen.
- Nun den Client am Server starten -> sollte gehen
- Infos an die Anwender, dass neuer Client zu installieren ist.