Zur Dokumentation falls jemand noch eine Uralt Version im Einsatz hat und diese pflegen will.
Wir können nur dringend raten auf die aktuellen Versionen zu wechseln
Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. Druckvorgang starten.
Zur Dokumentation falls jemand noch eine Uralt Version im Einsatz hat und diese pflegen will.
Wir können nur dringend raten auf die aktuellen Versionen zu wechseln
Beschreibung der Installation deines Kieselstein ERP Servers bis Mai 2025
Wird die Serverinstallation von uns durchgeführt, so benötigen wir, neben den ganzen Zugangsdaten,
Wir freuen uns über jedeN der uns beim Testen der aktuellen Software hilft. Insofern stehen unter dem Link die latest Release und ein aktueller Build zur Verfügung.
D.h. über den Link kommst du zum Repository des Kernsystems von Kieselstein ERP. 
Nun kannst du durch Klick auf Latest Release
die letzte gültige Version herunterladen.
Alternativ bekommst du den aktuellen Stand durch Klick auf
, welche den neuesten von der Technik / Softwareentwicklung zur Verfügung dargestellten Stand darstellt.
Um die Latest Release zu verwenden, klicke auf den Button und dann auf

Um die neueste Version herunterzuladen, Klicke auf Pipeline passed (du solltest nur Build mit einem Status von Passed verwenden).
Nun wird die Build Pipeline angezeigt. Klicke hier im rechten Bereich auf Artefakte herunterladen und wähle build-distpack:archive
Entzippe aus dieser Datei das dist Verzeichnis nach ?:\kieselstein\dist
Lege parallel dazu ein Verzeichnis data (?:\kieselstein\data) an
Für die Installation benötigst du auch
wir verwenden gerne auch noch:
Es werden aktuell ausschließlich PostgresQL Version 14 und 15 unterstützt. MS-SQL wird nicht unterstützt. Für eine eventuelle Konvertierung deiner MS-SQL Datenbank wende dich bitte an die Kieselstein ERP eG. Neuere PostgresQL Versionen können funktionieren, sind aber aktuell von uns nicht freigegeben.
Bei der Installation darauf achten, dass nur PostgresSQL Server und die Command Line Tools installiert werden.

Bei der Installation muss auch das default Passwort für den User Postgres angegeben werden (postgres). Beachte in diesem Zusammenhang auch die Themen der Datenzugriffssicherheit. Aktuell kann das Datenbankpasswort durch die Environmentvariable MAIN_DB_PASS übersteuert werden.
Bitte prüfe, dass auch der Port auf 5432 vorgeschlagen wird.
Beachte, dass die Installation in Windowssystemen idealerweise auf einem eigenen Laufwerk erfolgt. Also z.B. nicht auf C: sondern, vom Betriebssystem unabhängig auf z.B. D:
Bitte verwende aktuell nur IP V4, sowohl für den Zugriff auf den Datenbank-Server als auch für die Kommunikation von den Clients mit deinem Kieselstein ERP Server.
Die abschließende Meldung nach dem Rechner-Neustart kann ignoriert werden.
Es gibt noch weitere optionale Environment-Variablen welche in der README.md Datei bei den Start-Scripten (im KIESELSTEIN_DIST/bin/) beschrieben sind.
ACHTUNG:
Wenn du bestehende Daten übernimmst, schau im Kieselstein ERP Wiki nach wie es nun weiter geht. Ansonsten:
Wir haben für Testzwecke eine sehr kleine und einfache Musterdatenbank eingerichtet. Diese findest du hier. Bitte beachte:

D.h. anstatt des fillDb.bat führst du das fillDb_Demodaten.bat aus.
Eine weitere Variante sind Demodaten in deDE und ohne Fibu. Diese findest du hier. Bitte beachte:
D.h. anstatt des fillDb.bat führst du das fillDb_Demodaten_DE_OF.bat aus.
Diese Daten müssen auf die aktuelle Datenbankversion gehoben werden.
D.h. bevor du mit der Installation fortfährst, muss je nach Betriebssystem das Datenbankupdate ausgeführt werden.
Ab der Version 1.x.x steht anstatt obiger FillDb eine leere Datenbank zur Verfügung.
D.h. der Installationsprozess ändert sich insofern, das du nach dem CreateDb das Liquibase aus dem Liquibaseverzeichnis (?:\kieselstein\dist\bootstrap\liquibase) mit run-liquibase.bat update eine leere aber funktionsfähige Datenbank erzeugst. In dieser sind auch alle Änderungen passend zur installierten Version enthalten.
Für Linux Anwender, ebenfalls in das liquibase Verzeichnis wechseln (/opt/kieselstein/dist/bootstrap/liquibase) und mit ./liquibase.sh update die leere Datenbank erzeugen.
ACHTUNG: Liquibase ab Version 4.29 verlangt Java 11
Prüfen, dass auch installiert durch Command Shell, Java -version

Aus ?:\Kieselstein\dist\clients\kieselstein-ui-swing-0.0.11.tar.gz mehrfach in die Ordner (zip) reinwechseln bis zum kieselstein-ui-swing-0.0.11. Hier die beiden Verzeichnisse bin und lib z.B. nach ?:\Kieselstein\dist\client kopieren. Nun das ?:\Kieselstein\dist\client\bin\kieselstein-ui-swing.bat editieren und den localhost auf die IP-Adresse des Servers austauschen. Wenn in anderen Sprache gestartet werden sollte, auch noch das -Dloc=de_AT auf z.B. -Dloc=de_DE oder -Dloc=de_CH oder -Dloc=en_US oder -Dloc=it_IT oder pl_PL oder sl_SL austauschen. (Weitere Sprachen, bitte melden)
Das Kieselstein-Desktop-Icon findest du hier
Weiteres zu Sprachen am Client siehe
so läuft der Zugriff grundsätzlich. Nun den Client beenden und dann den Server (mit Strg+C) stoppen und mit der Einrichtung des Serverdienstes fortsetzen.Fehlermeldung beim Einrichten des Dienstes
Kommt beim Einrichten des Dienstes die Meldung
so bedeutet dies “nur”, dass bisher kein Kieselstein ERP Dienst eingerichtet ist (und nicht upgedated werden konnte).
Du findest trotzdem nun die neu eingerichteten
in den Windows-Diensten.
Eine lose Sammlung von Tipps, KnowHow und ähnlichem für den/die Consultant im Rahmen der Installation.
ACHTE immer auf die Sicherheit Durch das Öffnen von Ports, gibt es natürlich auch mehr Möglichkeiten das System anzugreifen. Also denke auch an die Verwendung von VPN Tunnel usw..
Dass Betriebssystem, Virenscanner und Firewall immer aktuell sind, ergibt sich schon aus der DSGVO.
Die Themen rund um die Sicherheit, Passwörter abweichend vom default usw. sind im Web ausreichend abgehandelt. Kieselstein ERP eG Mitglieder schauen im Wiki unter dem Suchwort Sicherheit nach.
| Port | Zweck |
|---|---|
| 8080 | für den Zugriff auf den Kieselstein ERP Applikationsserver |
| 8280 | für den Zugriff auf die RestAPI Ab Version 1.x.x greift die RestAPI auf 8080 zu |
| 5432 | für den Zugriff auf die Postgres-Datenbank |
| 22 | für Linux, SSH Kommunikation |
Das sind die Standard Ports. Diese können, z.B. für weitere parallele Installationen am gleichen Rechner auch abweichen.
Siehe dazu: …/kieselstein/dist/bin/launch-kieselstein-main-server.bat bzw. .sh
Hier sollte zusätzlich der gewünschte Netzwerkkreis eingetragen werden, mit dem auch ein Zugriff erlaubt ist. Beispiel:
was bedeutet, dass aus dem Subnetz xx alle IP-Geräte die ein Passwort wissen auf die Datenbank zugreifen können.
Die pg_hba.conf findest du, je nach Betriebssystem unter:
| Betriebssystem | Pfad | Bemerkung |
|---|---|---|
| Windows(R) | c:\Programm Files\PostgreSQL\VV\data\ | |
| Debian | /etc/postgresql/14/main | Achtung: Wenn englisch installiert, muss der datestyle auf ‘ios, dmy’ gestellt werden. |
| Ubuntu | /etc/postgresql/14/main | ev. muss zusätzlich in der postgresql.conf listen_addresses=’*’ gestellt werden |
| iOS | .. |
systemctl start/stop wildfly.service systemctl start/stop tomcat.service
| Betriebssystem | Pfad |
|---|---|
| Debian | /etc/systemd/system/, |
ACHTUNG: Wenn auf dem Kieselstein ERP Server die IP Adresse verändert wurde, so muss danach unbedingt der Kieselstein ERP Server neu gestartet werden.
Vom Client aus auf http://Kieselstein-ERP-SERVER-IP-Adresse:8080 gehen.

Auf der Willkommensseite findest du links unten den Link zu download clients.
hier werden alle Dateien angezeigt die im Server unter c:\Kieselstein\dist\clients zur Verfügung stehen. D.h. üblicherweise werden hier die angepassten ?:\Kieselstein\dist\client Verzeichnisse als Client.zip einkopiert und somit dem Anwender zur Verfügung gestellt.
Bewährt hat sich auch, dass hier ein aktuelles Java für den Client hinterlegt wird.
https://www.azul.com/downloads/?version=java-11-lts&os=windows&architecture=x86-64-bit&package=jdk-fx#zulu
Tools (VDA-Scann-App, Terminal, Android-Mobile-App, evtl. Java) können im {KIESELSTEIN_DATA}/tools Ordner abegelegt werden und über http://Kieselstein-ERP-SERVER-IP-Adresse:8080/tools heruntergeladen werden.
Der Basis-Link für das erprobte Zulu Java findest du unter https://www.azul.com/downloads/?package=jdk#zulu
Hier dann für den Server nur Java 8 mit jdk-FX verwenden.

Für Windows-User empfiehlt sich die .msi herunterzuladen.
Bitte achte massivst darauf, dass auch in virtuellen Betriebsumgebungen ausreichen Ram zur Verfügung steht. Es kommt leider immer wieder vor, dass manche IT-Betreuer glauben, der VM ausreichend Platz gegeben zu haben, es kommt dieses RAM aber bei der VM nicht an. Hier empfiehlt sich, eine fixe Speicher Zuweisung zu verwenden.
Wo sehe ich, ob ich mein Kieselstein ERP aktualisieren sollte.
Aktuelle Version -> siehe Client, Fenstertitel
bzw. siehe ?:\kieselstein\dist\version.txt
Was ist in der aktuell verfügbaren Version enthalten bzw. welche Erweiterungen sind für die nächste Zeit geplant. Siehe
Herunterladen der aktuellen Version
Aktuelle Version: Siehe Titelzeile, hier steht z.B.: 0.0.xx.0 
Die aktuell verfügbare Version siehe
Hier findest du unter Versionshinweise welche Änderungen in der jeweiligen Version enthalten sind.
Von hier kannst du auch die aktuelle Terminalversion herunterladen
Aktuelle Version: Siehe Konfiguration
und dann ganz unten Version.
Weitere Vorgehensweise wie unter Terminal beschrieben.
Wie für die Installation deines Kieselstein ERP Servers vorgehen.
Diese Beschreibung teilt sich, unabhängig von den Betriebssystemen in zwei Bereiche:
Sie gilt ab der Kieselstein ERP Version 1.0.6, welche auch am Server Java 11 voraussetzt.
Beachte das unter Vorbereitung geschriebene
Unabhängig vom Betriebssystem ist die Vorgehensweise im Wesentlichen immer die gleiche. Die wesentlichsten Unterschiede zwischen den Betriebssystemen ist das Thema:
In der nachfolgenden Beschreibung wird von Windows als Server Betriebssystem ausgegangen. Wir wissen, dass Linux Admins, immer auch ein umfassendes Wissen in der Windows Administration haben und dies entsprechend übersetzen können.
Für Windows die Empfehlung alles auf ein eigenes Laufwerk zu installieren z.B. D:
Installation Java, inkl. permanentem Setzen des Java_Home
Installation PostgresQL, alles default, PW: postgres
Installation PGadmin
Installation Liquibase
Unter Linux die Schriften installieren
Installation Kieselstein ERP
unter Windows hinzufügen des Pfades auf die PostgresQL Runtimes z.B. ?:\Program Files\PostgreSQL\15\bin
Einrichten der Environment Variablen wie unter ?:\kieselstein\dist\bin\readme.md beschrieben Unter Linux darauf achten, dies OHNE EXPORT zu machen und danach den Server neu starten
erstellen der Datenbanken
liquibase.sh update / run-liquibase.bat update
ausführen.
erstellen des Clients
erster Server Start
Als Dienst / Service einrichten
Gratulation, dein Kieselstein ERP läuft
Hinweis:
Gegebenenfalls an die Freigabe des Ports 8080 für den Zugriff innerhalb deines Netzwerkes denken.
Grundsätzlich sind die Kieselstein ERP Updates so gestaltet, dass diese, egal welche Version deine Ausgangsdatenbank hat, jederzeit aktualisiert werden können. Die Unterschiede liegen in der Ausgangsbasis für den Beginn der Liquibase Installation und gegebenenfalls in der Verlagerung der anwenderspezifischen Reports.
Es wird immer auf die aktuelle Version upgedated. Also diejenige die du aus dem Gitlab heruntergeladen hast. Ein Downgrade ist nicht vorgesehen.
Denke daran, dass du ein vollständiges und überprüftes Backup deiner Daten und Reports gemacht hast, bevor du mit dem Update beginnst.
Bewährt hat sich hier, das nächtliche Backup zu nutzen. D.h. es wird, kurz vor dem Beginn des automatischen Backups, der bestehende Kieselstein ERP Server gestoppt. Somit können keine Veränderungen an den Daten (von den “normalen” Anwendern) durchgeführt werden und du kannst das Backup, das mit Vacuum schon auch mal einige Stunden dauern kann, als Sicherheit für dein Update nutzen.
Diese Beschreibung geht davon aus, dass du auf 1.0.6 oder höher aktualisierst. D.h. es müssen folgende Dinge eingerichtet und funktionsfähig sein:
./liquibase.sh changelog-sync --label-filter="0.0.12"
ausführen.
liquibase.sh update / run-liquibase.bat update
ausführen
du findest nun in einem Web-Browser unter http://IP_deines_Kieselstein_Servers:8080 die Startseite deines Kieselstein ERP Servers.
Hier auf download clients klicken.
In diesem Verzeichnis findest du alles, was du auf deinem Kieselstein ERP Server unter Clients (?:\kieselstein\dist\clients) zur Verfügung gestellt hast.
D.h. du kannst hier z.B. das passende APK für die mobile App zur Verfügung stellen, oder auch das Installationsprogramm für deine Terminals.
Wie für die Wiederherstellung deines Kieselstein ERP Servers vorgehen.
Solltest du wirklich den dramatischen Fall haben, dass dein Kieselstein ERP Server unkontrolliert abgekracht ist, nimm dir vor irgend welchen weiteren Maßnahmen die Zeit dieses kurze Kapitel durchzulesen.
In aller Ruhe.
Und wirf auch den Chef raus. Wenn er / sie will, dass es rasch geht, brauchst du vor allem Zeit, um die Schritte durchführen zu können. Das hat sich in allen Situationen bewährt.
D.h. diese Beschreibung kannst du auch dafür verwenden, ein Testsystem deines Kieselsteins aufzusetzen. Und ja, du / dein IT-Betreuer solltest das üben. Denn im Falle des Desasters und wir wünschen uns alle, dass das nie eintritt, solltest du das schon öfter geübt haben.
Um dein Kieselstein ERP System wieder herstellen zu können, benötigst du in jedem Falle
WICHTIG:
Kümmere dich, mindestens einmal monatlich darum, dass dieses Backup auch in dein externes Sicherungsmedium wandert UND vollständig ist. Idealerweise machst du z.B. quartalsweise, jedenfalls aber jahresweise einen Restoretest.
Siehe dazu auch Sicherung
liquibase.sh update / run-liquibase.bat update
Wichtig:
Dass der Datenbankserver die gleiche Major Version wie die gesicherte Datei hat oder etwas neuer ist, sollte selbstverständlich sein.
Hinweis:
Du siehst in einem guten Editor in den ersten Zeilen deiner Datensicherung im Klartext die Datenbankversion von der aus diese Datenbank gesichert wurde.
Wie lange wird so ein Restore dauern?
Du hast NUR die Daten zur Verfügung, die in deinem Backup enthalten sind. Wenn also dein Backup von gestern Abend ist und heute Abend, eine Sekunde bevor das Backup gültig abgespeichert werden konnte, kaputt ist, so hast du einen ganzen Tag verloren.
Kannst du dir das leisten, oder muss öfter gesichert werden. Das kann bis zum gespiegelten Datenbankserver gehen. Siehe Sicherung
Beim Restore der Datenbanken dürfen grundsätzlich keine Fehler auftreten.
Auch hier keine Regel ohne Ausnahme.
Folgende Fehler sind normal und kommen daher, je nach Situation vor:

Ein gerne gemachter Fehler ist, dass eine komplette Neuinstallation gemacht wird und dann die Backupdatei in die bestehende KIESELSTEIN restored wird. Dies ist falsch. Es muss immer von einer neu angelegten Datenbank direkt in diese leere Datenbank restored werden.
Den Kieselstein ERP Server auf einem frischen Debian installieren.
Was mir alles so bei der Installation unter Debian unterkommt.
Es ist dies ein Debian 11 mit Desktop Gnome (Std)
Boot-Auswahl:
Dauer ca. 30 Minuten
OpenSSH Server installieren
apt update
apt upgrade
apt install openssh-server
Root Login per SSH ausschalten
nano /etc/ssh/sshd_config
und folgende Zeile ändern
PermitRootLogin yes
und speichern.
systemctl restart ssh
Ein praktisches Werkzeug ist auch der Midnight Commander.
apt install mc
Natürlich kann man die Dateien mit dem Nano bearbeiten. Praktischer ist jedoch der gedit.
Da üblicherweise kein root installiert wird, man aber die Rechte braucht, einfach mit su root und dem eigenen PW anmelden.
ip address
www.azul.com, klick auf Downloads
runterscrollen und Java8 LTS, Debian, x86 64.bit, JDK FX auswählen = 8u372b07
.deb herunterladen
Terminal öffen,
su - root
auf das home des herunterladenden Users wechseln und ins Downloads, z.B. /home/keg/Downloads
apt install ./zulu8.70.0.23-ca-fx-jdk8.0.372-linux_amd64.deb
danach mit java -version überprüfen
sudo -u postgres psql
ALTER USER postgres WITH PASSWORD ‘postgres’; ACHTUNG: Beachte die GoDB
\q (um den psql Editor wieder zu verlassen)
Pfad: /etc/postgresql/14/main
Einstellen postgresql.conf
Gegebenenfalls auch den Zugriff von außen einrichten. D.h.:
Datenbankserver neu starten systemctl restart postgresql
Für die Datenbankmigrationen, muss das Tool liquibase installiert werden.
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
Im Debian 11 ist das eigentliche Java unter /usr/lib/jvm/zulu-fx-8-amd64/jre/bin/java
Wir setzen die Enviroment Variable unter /etc/environment
Anmerkung: Das wirkt nur für den Service nach einem Neustart des gesamten Systems.
Um den Server manuell starten zu können, empfiehlt sich die Einrichtung des unten beschriebenen Start.sh
Als su - root auf /opt wechseln und
chmod 777 kieselstein -R
ACHTUNG: Sicherheit!!
Die Datei von Gitlab herunterladen, mit dem Archivemanager öffnen und in das dist die Dateien aus dem Archivemanager reinkopieren.
In das Verzeichnis /opt/kieselstein/dist/bootstrap/database wechseln
als root nach /opt/kieselstein/dist/bootstrap/service/linux
./install-kieselstein-services.sh
ausführen. Damit wird auch systemctl start kieselstein-main-server.service gestartet.
bewährt hat sich das Laufen des Servers in folgender Reihenfolge zu prüfen:
Kommt beim Drucken die Meldung
Schriftart ’null’ am Server nicht verfügbar, so müssen die in den Reports verwendeten Schriften noch installiert werden.
Üblicherweise wird von Kieselstein ERP die Schriftart Arial verwendet. D.h. diese nachinstallieren. Dazu:
Anmerkungen worauf bei der Installation mit Hyper V zu achten ist:
Anmerkung: Wenn das Ding nicht von dem ISO Image Boote will, die Netzwerkkarte auf nicht verbunden stellen
Wenn man nun versehentlich die Ansicht der VM auf 25% stellt, kann man nicht mehr zurück, weil das Menü nicht breit genug ist.
Der Trick, der hilft ist,
Bildschirmauflösung unter Hyper V ändern, ergänzen des Booteintrages
Den Kieselstein ERP Server auf einem frischen Debian installieren.
Dauer ca. 30 Minuten
OpenSSH Server installieren
apt update
apt upgrade
apt install openssh-server
apt-get install wget sudo curl gnupg2
sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
apt-get install postgresql-15
Mit vi oder anderen Texteditor öffnen.
vi /etc/postgresql/15/main/postgresql.conf
Hier müssen das Datums-Format und die Zeitzone umgestellt werden.
datestyle = 'iso, dmy'
timezone = 'Europe/Vienna'
# Auf die Timezone achten. Diese muss auf ‘Europe/Vienna’ (bzw. Berlin gerne auch Zuerich) stehen
Sollte ein Zugriff von einem anderen System auf die Datenbank notwendig sein, muss hier auch der listen_addresses Wert
gesetzt werden (auf * für alle, bzw. die IP-Adressen, welche unbedingt Zugriff auf die Datenbank brauchen).
Gegebenenfalls auch den Zugriff von außen einrichten. D.h.:
systemctl is-enabled postgresql
systemctl status postgresql
Datenbank öffnen
sudo -u postgres psql
Passwort für den Datenbankbenutzer setzen:
ALTER USER postgres WITH PASSWORD '<Sicheres Passwort>';
exit
Hinweis: Es sollte ein sicheres Passwort verwendet werden, welches über einen Passwort-Generator erstellt wurde (Achtung das Passwort wird hier in folgenden Schritten noch benötigt!).
wget https://cdn.azul.com/zulu/bin/zulu11.74.15-ca-fx-jdk11.0.24-linux_amd64.deb
Alternativ kann der Download auch über die Azul-Seite erfolgen.
Siehe hierfür auch Java-Version.
Den folgenden Befehl im Download-Verzeichnis der Java-Version ausführen.
apt install ./zulu11.74.15-ca-fx-jdk11.0.24-linux_amd64.deb
Installation überprüfen:
java -version
Für die Datenbankmigrationen, muss das Tool liquibase installiert werden.
ACHTUNG: Du musst dafür root-Rechte haben z.B. su - root (und dann dein eigenes PW eingeben)
wget -O- https://repo.liquibase.com/liquibase.asc | gpg --dearmor > liquibase-keyring.gpg && \
cat liquibase-keyring.gpg | 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' | tee /etc/apt/sources.list.d/liquibase.list
apt-get update
apt-get install liquibase
Auch hier kannst du prüfen, ob die Installation gegangen ist.
liquibase --version
Hinweis:
Sollte die Installation des Liquibase nicht möglich sein, muss das gpg aktualisiert werden. Vermutlich ist das ein Signal für eine veraltete Installation, daher das gesamte Betriebssystem aktualisieren.
Damit die Reports funktionieren, muss die Schriftart Arial installiert werden. Dies kann unter Linux so durchgeführt werden.
wget http://ftp.de.debian.org/debian/pool/contrib/m/msttcorefonts/ttf-mscorefonts-installer_3.8_all.deb
apt install ./ttf-mscorefonts-installer_3.8_all.deb
Mit vi oder nano oder anderem Texteditor öffnen.
vi /etc/environment
Wichtig! Die Umgebungsvariablen müssen OHNE export hinzugefügt werden.
Optional kann auch die KIESELSTEIN_WILDFLY_CONFIG Umgebungsvariable gesetzt werden.
Wichtig ist dabei das die Variable keine anderen Variablen beinhalten darf.
Bsp: KIESELSTEIN_WILDFLY_CONFIG=/opt/kieselstein/data/wildfly
Es müssen dann noch einmalig folgende files vom wildfly ordner in den KIESELSTEIN_WILDFLY_CONFIG kopiert werden.
/opt/kieselstein/dist/wildfly-26.1.2.Final/standalone/configuration/
Danach noch einen Applikations-User mit /opt/kieselstein/dist/wildfly-26.1.2.Final/bin/add-user.sh hinzufügen.
source /etc/environment
oder Server Neustarten
reboot
Verzeichnisse anlegen:
mkdir /opt/kieselstein
mkdir /opt/kieselstein/dist
mkdir /opt/kieselstein/data
Dist-Paket über die bestehende Installation entpacken (In der Windows Eingabeaufforderung cmd.exe) Beispiel:
# Beispiel für Download des Dist-Pakets.
wget https://gitlab.com/kieselstein-erp/sources/kieselstein/-/jobs/7650408929/artifacts/raw/kieselstein-distpack/build/distributions/kieselstein-distpack-1.0.0-rc.1.tar.gz
# Beispiel für das Entpacken des Dist-Packets.
tar -xvf ./kieselstein-distpack-1.0.0-rc.1.tar.gz -C /opt/kieselstein
cd /opt/kieselstein/dist/bootstrap/liquibase/
./createdb.sh
Hier muss dann 4x das Passwort für den Postgres-Benutzer eingegeben werden.
Danach auch die default Datenbank auf den aktuellen Stand deines Kieselstein Servers heben.
./liquibase.sh update
cd /opt/kieselstein/dist/bootstrap/service/linux
./install-kieselstein-services.sh
ausführen. Damit wird auch systemctl start kieselstein-main-server.service gestartet.
ACHTUNG: Es muss dafür das environment gesetzt worden sein
Wird für BasicAuth bei EDIFACT und CLEVERCURE benötigt.
KIESELSTEIN_DATA/wildfly Ordner erstellen und die folgenden Dateien aus KIESELSTEIN_DIST/wildfly-26.1.2.Final/standalone/configuration hineinkopieren.
Sollte für die REST-Schnittstelle ein eigener Port notwendig sein. Damit der Zugriff zum Beispiel über das Internet zur Verfügung gestellt werden kann oder bestehende Zeiterfassung-Terminals oder andere Anwendungen bereits den Port: 8280 verwenden kann ein Nginx-Webserver als Proxy hierfür installiert werden.
# Nginx-Webserver installieren:
apt install nginx
# Konfiguration für Kieselstein verlinken:
ln -s /opt/kieselstein/dist/bootstrap/nginx/kieselstein.conf /etc/nginx/sites-enabled/kieselstein-main.cfg
# Testen, ob die Konfiguration gültig ist:
nginx -t
# Nginx-Webserver Dienst neustarten
systemctl restart nginx
Für das Freischalten im Internet sollte auf jeden Fall ein SSL-Zertifikat noch hinterlegt werden (siehe hier auch Configuring HTTPS servers bzw. Nginx-Webserver)
Zum Überpüfen, ob der Nginx funktioniert und mit dem Kieselstein kommuniziert, kann die Url: http://(Name oder IP-Adresse des Servers):8280/kieselstein-rest/services/rest/api/v1/system/ping aufgerufen werden.
bewährt hat sich das Laufen des Servers in folgender Reihenfolge zu prüfen:
Wenn eine bestehende Kieselstein Installation mit der Version 0.2.x vorhanden ist, können folgende Schritte für das Update auf Version 1.x.x durchgeführt werden.
Falls möglich, snapshot vom Server machen.
Dienste beenden
systemctl stop kieselstein-main-server.service
# REST Service kann gelöscht werden da dieser jetzt im Wildfly integriert ist.
systemctl stop kieselstein-rest-server.service
systemctl disable kieselstein-rest-server.service
rm /etc/systemd/system/kieselstein-rest-server.service
Das aktuell installierte Kieselstein in ein eigenes Verzeichnis mit der aktuellen Versionsnummer im Namen wegsichern. Beispiel:
cp -r /opt/kieselstein/ /opt/kieselstein-0.2.10
apt remove <Pfald zum alten Java-Deb-Paket.>
Mit vi oder Nano oder einem anderen Texteditor öffnen.
vi /etc/environment
Nur den Wert für JAVA_HOME anpassen, alles andere kann so bleiben wie es ist.
Neue Umgebungsvariable laden
source /etc/environment
Damit die Anwender-Reports nach dem Update wieder zur Verfügung stehen, muss der Reports-Ordner in ein neues Verzeichnis kopiert werden.
mkdir /opt/kieselstein/dist/wildfly-26.1.2.Final/
mkdir /opt/kieselstein/dist/wildfly-26.1.2.Final/kieselstein/
cp -r /opt/kieselstein/dist/wildfly-12.0.0.Final/server/helium/report/ /opt/kieselstein/dist/wildfly-26.1.2.Final/kieselstein/reports/
WICHTIG: Dies muss vor dem Entpacken des neuen Dist-Packets erfolgen, damit neuere Versionen der Standard-Reports richtig nachgezogen werden.
Folgende Ordner können nun komplett gelöscht werden:
rm -rf /opt/kieselstein/dist/apache-tomcat-*
rm -rf /opt/kieselstein/dist/bin
rm -rf /opt/kieselstein/dist/bootstrap
rm -rf /opt/kieselstein/dist/service
rm -rf /opt/kieselstein/dist/wildfly-12.0.0.Final
Dist-Paket über die bestehende Installation entpacken (In der Windows Eingabeaufforderung cmd.exe) Beispiel:
# Beispiel für Download des Dist-Pakets.
wget https://gitlab.com/kieselstein-erp/sources/kieselstein/-/jobs/7650408929/artifacts/raw/kieselstein-distpack/build/distributions/kieselstein-distpack-1.0.0-rc.1.tar.gz
# Beispiel für das Entpacken des Dist-Packets.
tar -xvf ./kieselstein-distpack-1.0.0-rc.1.tar.gz -C /opt/kieselstein
cd /opt/kieselstein/dist/bootstrap/liquibase/
./liquibase.sh update
Dann muss dem Liquibase noch mitgeteilt werden, dass es bereit die Grund-Datenstruktur gibt, somit muss vor dem Befehl
./liquibase.sh updatenoch folgender Befehl aufgerufen werden:./liquibase.sh changelog-sync --label-filter="0.0.12"
cd /opt/kieselstein/dist/bootstrap/service/linux
./install-kieselstein-services.sh
Die Kieselstein-REST Schnittstelle wurde mit dem Update in den Wildfly integriert und ist somit auch über den Port: 8080 erreichbar.
Sollte es notwendig sein, dass diese wie bisher über den Port 8280 erreichbar ist, kann hier ein Nginx-Webserver als Proxy vorgeschaltet werden (Siehe NGINX Webserver)
Siehe Läuft der Server
Wenn eine bestehende Dokumentendatenbank existiert, müssen hier folgende Parameter Werte (Achtung diese Werte sind 2x in der XML-Datei vorhanden) angepasst werden:
/opt/kieselstein/data/jackrabbit/workspaces/default/workspace.xml
Und folgende Parameter können gelöscht werden:
<?xml version="1.0" encoding="UTF-8"?>
<Workspace name="default">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://${org.kieselstein.db-doc.host}:${org.kieselstein.db-doc.port}/${org.kieselstein.db-doc.name}"/>
<param name="schema" value="postgresql"/>
<param name="user" value="postgres"/>
<param name="password" value="postgres"/>
<param name="schemaObjectPrefix" value="ws_"/>
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://${org.kieselstein.db-doc.host}:${org.kieselstein.db-doc.port}/${org.kieselstein.db-doc.name}"/>
<param name="user" value="postgres"/>
<param name="password" value="postgres"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
</SearchIndex>
</Workspace>
<?xml version="1.0" encoding="UTF-8"?><Workspace name="default">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="java:/JRDS"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="ws_"/>
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="java:/JRDS"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
</SearchIndex>
</Workspace>
Man kann das jackrabbit config file mit der DOC_CONFIG Umgebungsvariable ändern.
Umgebungsvariable auf den folgenden Wert setzen, um die Datei-basierte Dokumenten Datenbank zu verwenden.
DOC_CONFIG=/opt/kieselstein/conf/jackrabbit-datastore-fs.xml
Die dokumente werden standardmäsßig in folgenden Ordner gespeichert. Kann mit der DOC_REPO Umgebungsvariable geändert werden.
DOC_REPO=/opt/kieselstein/data/jackrabbit
<?xml version="1.0" encoding="UTF-8"?>
<Repository>
<Security appName="Jackrabbit">
<AccessManager class="org.apache.jackrabbit.core.security.simple.SimpleAccessManager"/>
<LoginModule class="org.apache.jackrabbit.core.security.simple.SimpleLoginModule">
<param name="anonymousId" value="anonymous"/>
</LoginModule>
</Security>
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/>
<DataStore class="org.apache.jackrabbit.core.data.FileDataStore">
<param name="path" value="${rep.home}/datastore"/>
<param name="minRecordLength" value="100"/>
</DataStore>
</Repository>
Empfehlung:
Insbesondere für die Tests in der ersten Zeit, sollte für ein eventuelles Fallback auf den Clients sowohl die Version für den Java 8 Server als auch für den Java 11 Server parallel vorgehalten werden. Damit man, im schlimmsten Falle, schnell auf die Vorgängerversion zurückwechseln kann.
update lp_primarykey set i_index = (select max(i_id)+1 from fb_sepakontoauszug) where c_name like '%sepa%';
Siehe dazu auch [#307}(https://gitlab.com/kieselstein-erp/sources/kieselstein/-/issues/307).
Hier kommen die eventuellen Besonderheiten zu einer Ubuntu Installation rein. Aktuell bitte wie unter Debian beschrieben vorgehen.
www.azul.com/downloads/ … damit die Werbung nicht kommt
wenn apt nicht gegangen, weil z.B. zu wenig Rechte dann apt reinstall usw.
apt install postgresql holt die aktuellste Postgresversion derzeit 16 ACHTUNG: Installiert OHNE Passwort. daher su postgres psql damit bist du im Scripteditor commander nun
Ubuntu Version lsb_release -a
su postgres -> der Sudo geht irgendwie nicht Mit sudo su kannst du auch root-Rechte bekommen.
Anmerkung: Wenn das Kopieren per Fernwartung nicht geht, dann über den Firefox auf die docs.kieselstein-erp.org gehen und von dort die Kommandos herauskopieren. Im Ubuntu dann mit rechter Maustaste in den Eingabefeldern einfügen.
Je nach Maschine für das filldb sich etwas gedulden. Das kann dauern.
export KIESELSTEIN_JAVA_OPT_XMX=5G export KIESELSTEIN_JAVA_OPT_XMS=512m
reboot … = shutdown -r now
Hier findest du ergänzende Punkte zur Installation unter Windows. Die Standard-Installation ist im Hauptkapitel beschrieben.
Nach der Installation und dem erfolgreichen Test daran denken, dass in der Regel, zumindest für den Port 8080.


8280 wenn auch die Rest-API verwendet werden sollte (Ab der Version 1.x.x nicht mehr erforderlich)
5432 wenn auch von innerhalb des Netzwerkes auf den PostgresQL zugegriffen werden sollte.
ACHTUNG: Sicherheit!!
Im Deploymentsverzeichnis (?:\Kieselstein\dist\wildfly-12.0.0.Final\standalone\deployments) steht kieselstein-0.0.11.ear.failed.
Ev. auch nur jackrabbit-jca-1.5.7.rar.failed.
So kann man in den beiden Dateien nachsehen.
Effizienter ist vermutlich in der ?:\Kieselstein\dist\wildfly-12.0.0.Final\standalone\log\server.log nachzusehen.
Dafür zuerst das log Verzeichnis löschen um nur die aktuellsten Einträge zu bekommen und dann den Server erneut starten, bis wiederum im Deploymentsverzeichnis das failed kommt.
Nun sucht man in der server.log am besten von oben nach dem ersten Eintrag mit Error. Meist findet man einen Eintrag wie z.B.:
2023-09-22 17:15:23,014 ERROR [org.apache.jackrabbit.core.fs.db.DatabaseFileSystem] (MSC service thread 1-3) failed to initialize file system: org.postgresql.util.PSQLException: FATAL: Passwort-Authentifizierung f�r Benutzer �postgres� fehlgeschlagen
Dies bedeutet, dass der Applikationsserver sich nicht an der Datenbank anmelden konnte. Versuche nun dich mittels PGAdmin auf der Datenbank mit postgres, postgres anzumelden. Ist dies nicht möglich, stimmt das Passwort der Datenbank nicht. Eventuell wurde bei der Installation des Postgresservers ein falsches oder kein Passwort vergeben. D.h. es muss das Passwort geändert werden. Wenn du das andere(falsche) Passwort kennst, melde dich mit diesem an und ändere das Passwort. Wenn du dieses nicht kennst, muss zuerst der Zugang zum PostgresQL-Server, auf dem Rechner, auf dem dieser läuft, so freigeschaltet werden, dass du dich auch ohne Passwort anmelden kannst. Dafür muss die pg_hba.conf angepasst werden. Diese findest du unter “?:\Program Files\PostgreSQL\14\data". Ergänze diese nun abhängig von deiner IP-Konfiguration um
Nun muss der postgresql Dienst neu gestartet werden.
Wechsle nun als Administrator nach ?:\Program Files\PostgreSQL\14\bin
und rufe psql.exe -U postgres auf
Nun mit
\password postgres
das Passwort auf postgres setzen und dann mit
\q
Das Programm wieder verlassen.
Nun musst du dich auch im PGAdmin mit dem Passwort anmelden können.
Bitte beachte, dass ab PostgresQL 15 der PGAdmin 7 zum Einsatz kommen sollte.
Info:
Bei der Modifikation der pg_hba.conf auf IP V4 bzw. IP V6 achten! Kommt
psql: Fehler: Verbindung zum Server auf »localhost« (::1)
So fehlt der passende Eintrag in der pg_hba.conf
Info:
Nach diesen Änderungen empfiehlt sich auch die Verzeichnisse log, tmp, data aus dem standalone (?:\kieselstein\dist\wildfly-12.0.0.Final\standalone) zu löschen, damit die ganzen falschen Einträge weg sind.
Den Kieselstein ERP Server auf einem frischen Windows installieren.
Es werden aktuell ausschließlich PostgresQL Version 14 und 15 unterstützt. MS-SQL wird nicht unterstützt. Für eine eventuelle Konvertierung deiner MS-SQL Datenbank wende dich bitte an die Kieselstein ERP eG. Neuere PostgresQL Versionen können funktionieren, sind aber aktuell von uns nicht freigegeben.
Bei der Installation darauf achten, dass nur PostgresSQL Server und die Command Line Tools installiert werden.

Bei der Installation muss auch das Passwort für den User Postgres angegeben werden.
Hinweis: Es sollte ein sicheres Passwort verwendet werden, welches über einen Passwort-Generator erstellt wurde (Achtung das Passwort wird hier in folgenden Schritten noch benötigt!).

Java -version

Optional kann auch die KIESELSTEIN_WILDFLY_CONFIG Umgebungsvariable gesetzt werden.
Wichtig ist dabei das die Variable keine anderen Variablen beinhalten darf.
Bsp: KIESELSTEIN_WILDFLY_CONFIG=?:\kieselstein\data\wildfly
Es müssen dann noch einmalig folgende files vom wildfly ordner in den KIESELSTEIN_WILDFLY_CONFIG kopiert werden.
?:\kieselstein\dist\wildfly-26.1.2.Final\standalone\configuration
Danach noch einen Applikations-User mit \opt\kieselstein\dist\wildfly-26.1.2.Final\bin\add-user.bat hinzufügen.
Es gibt noch weitere optionale Environment-Variablen welche in der README.md Datei bei den Start-Scripten (im KIESELSTEIN_DIST/bin/) beschrieben sind.

Achtung: Damit die Umgebungsvariablen für den Kieselstein-Dienst funktionieren, müssen diese als Systemvariablen hinterlegt werden.
Für die Datenbankmigrationen muss das Tool liquibase installiert werden.
Aktuelle Liquibase Version vom git Repository runterladen:
https://github.com/liquibase/liquibase/releases
Hier bis 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.
Dist-Paket über die bestehende Installation entpacken (In der Windows Eingabeaufforderung cmd.exe) Beispiel:
tar -xvf <pfad-zum-dist-packet>.gz -C ?:\kieselstein\
Die installierte ?:\kieselstein\dist\bootstrap\liquibase\createdb.bat ausführen. Hier muss dann 4x das Passwort für den Postgres-Benutzer eingegeben werden.
In der Command Shell in das Verzeichnis navigieren und mit liquibase den update Befehl durchführen:
cd ?:\kieselstein\dist\bootstrap\liquibase
run-liquibase.bat update
Mit Administrationsrechten das Install-Script ?:\kieselstein\dist\bootstrap\service\windows\install-kieselstein-services.bat ausführen.
Sollte für die REST-Schnittstelle ein eigener Port notwendig sein. Damit der Zugriff zum Beispiel über das Internet zur Verfügung gestellt werden kann oder bestehende Zeiterfassung-Terminals oder andere Anwendungen bereits den Port: 8280 verwenden, kann ein Nginx-Webserver als Proxy hierfür installiert werden.
Mit Administrationsrechten das Install-Script ?:\kieselstein\dist\bootstrap\service\windows\install-kieselstein-nginx-service.bat ausführen.
Für das Freischalten im Internet sollte auf jeden Fall ein SSL-Zertifikat noch hinterlegt werden (siehe hier auch Configuring HTTPS servers bzw. Nginx-Webserver)
Zum Überprüfen, ob der Nginx funktioniert und mit dem Kieselstein kommuniziert, kann die Url: http://(Name oder IP-Adresse des Servers):8280/kieselstein-rest/services/rest/api/v1/system/ping aufgerufen werden.
bewährt hat sich, das Laufen des Servers in folgender Reihenfolge zu prüfen:
Wenn du Daten von anderen Installationen übernimmst, muss beim ersten Start deines Servers der Index der Dokumentendatenbank neu aufgebaut werden. Dies wird grundsätzlich vom Server unterstützt. Es kann aber unter Umständen so lange dauern, dass der Server von sich aus abbricht.
D.h. gegebenenfalls den Server mehrfach starten und oder zusätzlich das Timeout temporär höher drehen. D.h. im launch-kieselstein-main-server(.bat)
MAIN_SERVER_OPTS="${MAIN_SERVER_OPTS} -Djboss.as.management.blocking.timeout=3600"
set MAIN_SERVER_OPTS=%MAIN_SERVER_OPTS% -Djboss.as.management.blocking.timeout=3600
hinzufügen. Erhöht das Timeout auf eine Stunde.
Manchmal hat man in Windowsumgebungen das Problem, dass über die Dienste-Konsole der Kieselstein Service nicht endgültig gestoppt werden kann.
Mit den nötigen Administrator Rechten kann mit
net stop "Kieselstein Main Server"
Der Dienst gestoppt werden.
Wenn eine bestehende Kieselstein Installation mit der Version 0.2.x vorhanden ist, können folgende Schritte für das Update auf Version 1.x.x durchgeführt werden.
Dienste beenden

?:\kieselstein\dist\bootstrap\service\windows\delete-kieselstein-services.batDas aktuell installierte Kieselstein in ein eigenes Verzeichnis mit der aktuellen Versionsnummer im Namen wegsichern.
Beispiel: C:\kieselstein nach C:\kieselstein-0.2.10 kopieren.
Azul Java 11 mit FX installieren Siehe hierfür auch Java-Version.
darauf achten, dass Java Home gesetzt wird

Prüfen, dass Java auch installiert wurde durch Command Shell,
Java -version

Über “Programme hinzufügen oder entfernen” nach JDK Suchen und die Java 8 Version deinstallieren.

Achtung: Diesen Schritt nur durchführen, wenn auf dem Server sicher keine andere Anwendung mehr das Java 8 JDK benötigt!
Auf jeden Fall ist sicherzustellen, dass die JAVA_HOME Variable auf das Neue JDK 11 gesetzt wurde:

Dafür das Skript ?:\kieselstein\dist\bootstrap\service\windows\delete-kieselstein-services.bat mit Administrator Rechten ausführen.
Damit die Anwender-Reports nach dem Update wieder zur Verfügung stehen, muss der Reports-Ordner in ein neues Verzeichnis kopiert werden.
Hier muss der bestehende ?:\kieselstein\dist\wildfly-12.0.0.Final\server\helium\report nach ?:\kieselstein\dist\wildfly-26.1.2.Final\kieselstein\reports kopiert werden.
WICHTIG: Dies muss vor dem Entpacken des neuen Dist-Packets erfolgen, damit neuere Versionen der Standard-Reports richtig nachgezogen werden.
ACHTUNG: Die Definitionen für dein JasperStudio entsprechend übertragen und auch die Einstellungen im Jasper Studio entsprechend anpassen.
Dies idealerweise, bevor du die nachfolgenden Verzeichnisse löschst.
Im Verzeichnis bin solltest du auch die aktuelle kieselstein-ejb-1.0.3.jar anstatt der bisherigen ejb.jar verwenden.
Folgende Ordner können nun komplett gelöscht werden:
Dist-Paket über die bestehende Installation entpacken (In der Windows Eingabeaufforderung cmd.exe) Beispiel
tar -xvf <pfad-zum-dist-packet>.gz -C ?:\kieselstein\
In der Command Shell in das Verzeichnis navigieren und mit liquibase den update Befehl durchführen:
cd C:\kieselstein\dist\bootstrap\liquibase
run-liquibase.bat update
Dann muss dem Liquibase noch mitgeteilt werden, dass es bereit die Grund-Datenstruktur gibt, somit muss vor dem Befehl
run-liquibase.bat updatenoch folgender Befehl aufgerufen werden:run-liquibase.bat changelog-sync --label-filter="0.0.12"
Mit Administrationsrechten das Install-Script ?:\kieselstein\dist\bootstrap\service\windows\install-kieselstein-services.bat ausführen.
Die Kieselstein-REST Schnittstelle wurde mit dem Update in den Wildfly integriert und ist somit auch über den Port: 8080 erreichbar.
Sollte es notwendig sein, dass diese wie bisher über den Port 8280 erreichbar ist, kann hier ein Nginx-Webserver als Proxy vorgeschaltet werden (Siehe NGINX Webserver)
Siehe Läuft der Server
Es hat sich bewährt nach einem Update, insbesondere nach dem Wechsel der Java Version, den Server manuell zu starten. D.h. mit administrativen Rechten das
?:\kieselstein\dist\bin\launch-kieselstein-main-server.bat
auszuführen.
Beobachte hier die Ausgabe der Console. Erscheint hier:
2024-09-19 10:58:50,075 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 82) MSC000001: Failed to start service jboss.ra.deployer."jackrabbit-jca-2.22.0.rar": org.jboss.msc.service.StartException in service jboss.ra.deployer."jackrabbit-jca-2.22.0.rar": WFLYJCA0046: Failed to start RA deployment [jackrabbit-jca-2.22.0.rar]
at org.jboss.as.connector.services.resourceadapters.deployment.
...
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: jackrabbit-jca-2.22.0.rar
...
Caused by: java.lang.UnsupportedClassVersionError: Failed to link org/apache/jackrabbit/jca/JCAResourceAdapter (Module "deployment.jackrabbit-jca-2.22.0.rar" from Service Module Loader): org/apache/jackrabbit/jca/JCAResourceAdapter has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
this version of the Java Runtime only recognizes class file versions up to 52.0
so bedeutet dies, dass du vermutlich noch Java 8 auf deinem Server verwendest.
Gegebenenfalls willst du auf deinem Server, warum auch immer, auch noch Java 8 verwenden und hast daher beide Java Versionen installiert.
In diesem Falle muss das JAVA_HOME im Start-Batch
(?:\kieselstein\dist\bin\launch-kieselstein-main-server.bat) gesetzt werden.
Z.B. schreibst du in Zeile 3 set JAVA_HOME=c:\Program Files\Zulu\zulu-11, also den Pfad auf dein Java 11 rein.
Wenn eine bestehende Dokumentendatenbank existiert, müssen hier folgende Parameter Werte (Achtung diese Werte sind 2x in der XML-Datei vorhanden) angepasst werden:
?:\kieselstein\data\jackrabbit\workspaces\default\workspace.xml
Und folgende Parameter können gelöscht werden:
<?xml version="1.0" encoding="UTF-8"?>
<Workspace name="default">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://${org.kieselstein.db-doc.host}:${org.kieselstein.db-doc.port}/${org.kieselstein.db-doc.name}"/>
<param name="schema" value="postgresql"/>
<param name="user" value="postgres"/>
<param name="password" value="postgres"/>
<param name="schemaObjectPrefix" value="ws_"/>
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://${org.kieselstein.db-doc.host}:${org.kieselstein.db-doc.port}/${org.kieselstein.db-doc.name}"/>
<param name="user" value="postgres"/>
<param name="password" value="postgres"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
</SearchIndex>
</Workspace>
<?xml version="1.0" encoding="UTF-8"?><Workspace name="default">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="java:/JRDS"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="ws_"/>
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.PostgreSQLPersistenceManager">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="java:/JRDS"/>
<param name="schema" value="postgresql"/>
<param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index"/>
</SearchIndex>
</Workspace>
Empfehlung:
Insbesondere für die Tests in der ersten Zeit, sollte für ein eventuelles Fallback auf den Clients sowohl die Version für den Java 8 Server als auch für den Java 11 Server parallel vorgehalten werden. Damit man, im schlimmsten Falle, schnell auf die Vorgängerversion zurückwechseln kann.
Hier findest du nur in textlicher Form zusammengestellt, wie eine erste Installation unter MacOS erfolgen könnte.
Wir freuen uns, wenn ein entsprechender Profi, diese Beschreibung ergänzt.
Diese Installation baut auf der Kieselstein ERP Version 1.0.1 auf.
Wir haben auch einige Hintes für die Anwender anderer Betriebssysteme mit dazugegeben.
Wenn man im Finder verschiedene Devices usw. nicht findet, dann am Desktop auf Gehe Zu (Computer) und dann dieses Device links reinziehen. Ab dem Zeitpunkt ist es da.
Ab OS X Version 8? steht der Launcher zum Starten der Dienste zur Verfügung launchctl start/stop (dienst) mit list sieht man alle Dienste und die die eine PID haben laufen
find / -name xxx*.* findet alle Dateien ab Root
Rechtsklick mit der Maus bringt Einsetzen (aus der Zwischenablage)
mit pwd bekommt man den aktuellen Pfad im Terminal, auf dem man steht
idealerweise die Downloads über den Finder aus dem Download Verzeichnis starten
Den Root User gibt es nicht wirklich, aber
sudo -s eigenes Password -> damit ich ausreichend Rechte habe
??? open /Library/PostgreSQL/Version/uninstall-postgresql.app/Contents/MacOS/installbuilder.sh Sollte die Deinstallation nicht gehen, das Verzeichnis entfernen. Ev. dazu über Dienstprogramme, Aktivitäten den laufenden Prozess killen.
Nach der Installation von PostgreSQL 15 findest du diesen direkt im Finder
Je nach MAC Version und Postgresversion musst du die pg_hba.conf und die postgresql.conf anpassen. Siehe
von GitLab anscheinend nur mit Safari
Java11 auf die richtige Architektur achten (X64 oder ARM) JDK FX !!
Java deinstallieren (laut Oracle)
sudo rm -fr /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
sudo rm -fr /Library/PreferencePanes/JavaControlPanel.prefPane
sudo rm -fr ~/Library/Application\ Support/Oracle/Java
Versuchen Sie nicht, Java zu deinstallieren, indem Sie die Java-Tools aus /usr/bin entfernen. Dieses Verzeichnis ist Teil der Systemsoftware. Änderungen werden von Apple zurückgesetzt, wenn Sie das nächste Mal ein BS-Update durchführen.
rm -r Path
Nun die Environmentvariablen anlegen / ergänzen
Laut einigen Beschreibungen sind diese für alle User auf /etc/bashrc … das File gegebenenfalls mit Nano anlegen export PATH=$PATH:/Library/PostgreSQL/15/bin export KIESELSTEIN_DATA=/opt/kieselstein/data/ export KIESELSTEIN_DIST=/opt/kieselstein/dist/ Terminal neu starten ev. mit printenv die ganzen environment variablen prüfen
ABER Es müssen diese auf meinen Mac in die bash-profile. Also:
herunterladen und installieren. Landet auf /usr/local/opt/liquibase
Es dürfen keine Fehler kommen und es müssen 18 oder mehr updates ausgeführt angezeigt werden
Im Finder aus /opt/kieselstein/dist/clients, das Kieselstein-client…tar mit Rechtsklick und Archivierungsprogramm öffnen. Damit bekommst du das in das clients mit den Unterverzeichnissen bin und lib
Wenn mehrfach verteilt werden sollte, die kieselstein-client.sh die IP Adresse anpassen
auf /opt/kieselstein/dist/bin wechseln
und launch-kieselstein-main-server.sh
mit gehe zu auf deployment wechseln und prüfen ob startet
Um das aus dem Finder zu starten, musste du die Sicherheitseinstellungen erweitern D.h. Öffnen einer App durch Aussetzen der Sicherheitseinstellungen
zu klären sind noch folgende Dinge
Für die Beschreibung des Server-Updates deiner Kieselstein ERP Installation siehe die betriebssystemspezifischen Updates in den Unterkapiteln
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-Infrastruktur 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?
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.
Dafür gibt es mehrere Dinge zu beachten.
Wenn deine Installation zu deiner / eurer Zufriedenheit läuft, keine gesetzlichen Änderungen anstehen usw. besteht kein Grund ein Update durchzuführen. Bedenke dabei, dass sich die IT-Welt immer schneller weiterentwickelt. So kann es durchaus sein, dass ein Betriebssystemupdate auch ein Update deines Kieselstein ERP erzwingt. Plane solche Dinge langfristig.
Macht aber deine Installation Problem, so stelle bitte sicher, dass du die aktuelle Kieselstein ERP Version im Einsatz hast. Technische Änderungen werden nur aufbauend auf der aktuellen Version durchgeführt. Sollten mit der aktuellen Version Probleme / Wünsche gegeben sein, so beachte dazu auch das unter Supportanfrage geschriebene.
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 gecrashtes 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.
Seid euch des Wertes eurer Daten und Systeme bewusst. Durch die Update Manie wird nur eine Geringschätzung den eigenen Systemen gegenüber zum Ausdruck gebracht.
Vor jedem Update Prozess muss sowohl von der Datenbank als auch von den File-Systemen ein Backup gemacht werden.
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 Anmeldeversuch 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:

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.
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 Benutzers 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 Anmeldung angezeigt.
systemctl stop kieselstein-main-server.servicesystemctl stop kieselstein-rest-server.servicerm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.earrm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.warrm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.rarrm /opt/kieselstein/dist/wildfly-*.Final/standalone/deployments/*.deployedrm /opt/kieselstein/dist/apache-tomcat-*/webapps/*.war
tar -xvf <pfad-zum-dist-packet>.gz -C /opt/kieselsteinchown -R kieselstein:kieselstein /opt/kieselsteincat /opt/kieselstein/dist/bin/launch-kieselstein-rest-server.shcat /opt/kieselstein/dist/bin/launch-kieselstein-main-server.shMuss die initiale Migration gemacht werden.
Das gilt auch für den Start mit den Demodaten.
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
cd /opt/kieselstein/dist/bootstrap/liquibase./liquibase.sh changelog-sync --label-filter="0.0.12"liquibase.command.url=jdbc:postgresql://localhost:5432/KIESELSTEIN
liquibase.command.username=postgres
liquibase.command.password=postgres
cd /opt/kieselstein/dist/bootstrap/liquibase
./liquibase.sh update

systemctl start kieselstein-main-server.service
systemctl start kieselstein-rest-server.service
Siehe hierfür bitte Installation Clients.
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
Schritt für Schritt Anleitung

tar -xvf <pfad-zum-dist-packet>.gz -C ?:\kieselstein\
cat ?:\kieselstein\dist\bin\launch-kieselstein-rest-server.shcat ?:\kieselstein\dist\bin\launch-kieselstein-main-server.shMuss die initiale Migration gemacht werden.
Das gilt auch für den Start mit den Demodaten.
Für die Datenbankmigrationen, muss das Tool liquibase installiert werden.
Aktuelle Liquibase Version vom git Repository runterladen:
https://github.com/liquibase/liquibase/releases
Hier bis 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.
cd ?:\kieselstein\dist\bootstrap\liquibaseliquibase changelog-sync --label-filter="0.0.12"
liquibase.command.url=jdbc:postgresql://localhost:5432/KIESELSTEIN
liquibase.command.username=postgres
liquibase.command.password=postgres
In der Windows Eingabeaufforderung cmd.exe
cd ?:\kieselstein\dist\bootstrap\liquibase
liquibase update

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.

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.

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”.Funktioniert dies, würde ich mit der oben beschriebenen Prüfung fortfahren.

Siehe hierfür bitte Installation Clients.
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
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.
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.

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
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’;
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
Wenn auf deinem Kieselstein bereits die Liquibase Version installiert ist, also ab 0.1.0 so hat sich folgende Vorgehensweise bewährt:
Die Anforderungen an den Kieselstein ERP Server sind von verschiedenen Eckpunkten abhängig. Im wesentlichen sind dies Benutzeranzahl und Betriebssystem.
Die Verwendung eines 64Bit Betriebssystems ist heutzutage selbstverständlich.
Bei Verwendung von Windows gehen wir davon aus, dass dieses, auch für den Testbetrieb, ordnungsgemäß lizenziert ist.
| Eigenschaft | Betriebssystem | Datenbank | Kieselstein appServer |
je Power User | je std. User |
|---|---|---|---|---|---|
| Kerne | 1 | 1 | 1 | 0,5 | 0,1 |
| Ram [GB] | 4 | 2 | 2 | 0,1 | 0,01 |
| Platte [GB] | 100 | 70 | 70 |
Ganz wesentlich in die Geschwindigkeit des Gesamtsystems geht die Zugriffsgeschwindigkeit der / auf die Festplatten ein. Wir raten, auch wenn es teuer ist, zu SSD Platten. Sollte dies nicht möglich sein, zu Raid10.
ACHTUNG: Bei Virtualisierung kommt es immer wieder vor, dass die Platten zwar sehr schnell sind, aber da alle virtuellen Maschinen auf die gleiche Hardware zugreifen, ist im Endeffekt der Festplattencontroller der Flaschenhals. Hier ist zusätzlich zu bedenken, dass die Zugriffe oft mit kleinen Datenmengen erfolgen. D.h. die in der IT üblichen Geschwindigkeitsmessungen haben keine Aussagekraft (die Optimierungsalgorithmen der VM’s greifen leider nicht).
Die Größe der Platten hängt auch an der Verwendung der Dokumentenablage. Kann also, bei intensiver Nutzung, was im Sinne des Systems ist, auch deutlich darüber hinaus anwachsen.
In dieser Betrachtung ist der, für das unumgängliche zumindest tägliche Backup benötigte Platz, nicht berücksichtigt. Auch dies hängt von der Datenmenge der Installation ab. So beginnen Neuinstallationen bei einigen wenigen GB und wachsen danach schon mal auf 150 GB oder mehr an.
Eine wesentliche Frage in diesem Zusammenhang ist das Thema des Backups bzw., wie alt dürfen die Daten bei einem eventuellen Ausfall sein. Das geht bis hin zu gespiegelten Datenbankservern.
Diese Dinge klären wir am besten in einem persönlichen Gespräch.
ACHTUNG: Es muss am Server IMMER der doppelte Speicherplatz wie dein Datenbankbackup belegt frei sein.
Auch das hängt vom Einsatzbereich ab.
Für eine anfänglich kleine Installation mit 2 Usern reicht auch mal ein Windows11 (Windows 10 wird nicht mehr lange zur Verfügung stehen). Für den Einsatz in einem Unternehmen mit 5 Usern oder mehr, raten wir zum Einsatz eines Server Betriebssystems. Da der ganze grafische Overhead auf dem Server nicht benötigt wird, gerne auch Linux, Debian.
In jedem Falle aber bitte ausschließlich 64 Bit-Systeme.
Es werden die Version 14 oder 15 der PostgreSQL Datenbank unterstützt. Siehe Downloads unter: https://www.enterprisedb.com/downloads/postgres-postgresql-downloads
Für die Datenbankmigrationen wird das Liquibase Tool benötigt. Die aktuelle Liquibase Version kann vom git Repository heruntergeladen: https://github.com/liquibase/liquibase/releases werden. Hier bis zu den Assets runterscrollen und dann den passenden (Bsp.: Windows-)Installer auswählen. Z.B.: liquibase-windows-x64-installer-x.x.x.exe
ACHTUNG Java Version 11 ist erst ab der Kieselstein-Version 1.0.0 und höher unterstützt; vorher bitte Java-Version 8 verwenden!
Es wird für den Server die Azul-Java Version 11 benötigt.
Siehe dazu www.azul.com, klick auf Downloads
runterscrollen und Java11 LTS, (das jeweilige Betriebssystem auswählen), x86 64.bit, JDK FX auswählen.

Wenn die REST-Schnittstelle oder andere Dienste über das Internet zur Verfügung stehen sollen, dann sollte dies über einen Nginx-Webserver werden. Es wird für die Installation eine Default-Konfiguration (unter Kieselstein/dist/bootstrap/) mit ausgeliefert, wo der Port 8280 ohne SSL vorkonfiguriert ist (wie es bei früheren Versionen mit dem Tomcat durchgeführt wurde).
Unter nginxtutorials.com ist auch beschrieben wie mit Nginx ein Lets Encrypt-SSL-Zertifikat erstellt werden kann.
Alternativ kann natürlich auch ein “Selbstsigniertes Zertifikat” für SSL mit Nginx verwendet werden.
Es gibt inzwischen noch eine Anzahl von Funktionen / Zugriffen auf den Server, die für jeden Zugriff mehr oder weniger Serverlast ziehen. Auch diese sind in den obigen Überlegungen zu berücksichtigen.
Hier reichen heutzutage (2023) übliche Standard PC’s, mit mindestens 64 Bit Betriebssystemen und 8 GB Ram (wenn nur der Kieselstein-ERP Client läuft). Empfohlen 16 GB Ram, gerne mehr.
Auch hier raten wir zur Verwendung von SSD Platten, da auch diese massiv in das Geschwindigkeitsverhalten eingehen.
Da wir in der Praxis immer erleben, dass die Datensicherung zwar angeblich gemacht wird, aber dann doch nicht funktioniert, hier einige Gedanken dazu.
Wie hoffentlich allgemein bekannt ist, ist gerade die IT nicht vor Fehlern gefeit. D.h. deine Daten und diese sind heutzutage das Herzstück deines Unternehmens, müssen in jedem Falle “jederzeit” zur Verfügung stehen.
Solltest du anderer Meinung sein, schalte PC und Handy aus, was geht dann für dich noch?
Siehe dazu auch eRechnung bzw. generelle Aufbewahrungspflicht
Die Datensicherung muss mechanisch vom Rest der IT getrennt sein.
D.h. die Bänder, Kassetten dürfen nach der durchgeführten Datensicherung auch elektrisch nicht mehr mit dem Rest der IT verbunden sein. So werfen RDX Laufwerke bzw. Streamer am Ende des positiv abgeschlossenen Sicherungsvorganges die Kassette aus.
Üblicherweise ist das so organisiert, dass eine Bürokraft sich um die tägliche Sicherung kümmert und wenn das Medium nicht ausgeworfen wurde, die Verpflichtung hat die zuständige Stelle zu informieren.
Dass zumindest die Monatssicherung außer Haus gebracht wird, ist selbstverständlich. Wenn du Tagessicherungen machst, was für eine Produktionsunternehmen eher die Regel ist, so gilt dies für die Wochensicherungen. Das Außer-Haus-Bringen kann ein Bank-Safe sein, oder deine weit genug entfernte Privat-Wohnung. Der Gedanke hier ist immer, wenn jemand / etwas, beide Daten(stämme) zugleich stiehlt, angreift, also z.B. den Server klaut und deine Kassetten aus dem Privathaus, so hast du sowieso ein anderes Problem.
Um diese Frage zu beantworten, muss man sich überlegen, wie oft ich eigentlich sichern muss.
Der Schlüssel dafür ist für mich:
D.h. wenn ich die Daten wiederherstellen kann und ich diese innerhalb einer Wochenendaktion nacherfassen kann, so ist der Zeitraum, für den ich das mache, jener für den ich meine Sicherung machen muss. Ich würde jedoch immer für jede Woche eine Sicherung machen (man vergisst zu viel). Die Frage ist eher, ob eine Tagessicherung ausreicht, oder ob es stündliche Sicherungen von Teilen sein müssen, oder ob es gespiegelte Server braucht, welche in der Regel nur eine Datenbanktransaktion hinten sind.
Man sollte das auch nicht übertreiben. Wenn ich in fünf Jahren, die Zeitdaten eines Tages von meinen 150 Mitarbeiter:innen nicht exakt habe, wird mich das nicht umbringen.
Ja das stimmt. So kostet aktuell eine 1 TB RDX Kassette ca. 180,- €. Davon brauche ich, bei wöchentlicher Sicherung und Monatsbackup 4 + 12 Stk -> 2.880,- €.
Setzt man nun für die Nacherfassung einen Stundensatz von 80,- € (Inkl. aller Nebenkosten) an, so sind das 36 Std, also 4 Menschtage!
Dazu kommt: Ein IT-Systemausfall ist komplett versicherbar, die Datenwiederherstellung aus einem guten Backup ist darin enthalten, aber das Herzaubern von Daten ist nicht versicherbar.
Heutzutage ist alles in der IT gespeichert. Also z.B. auch die Telefonnummern in der Telefonanlage, welche ja auch ein IT System ist. Fällt nun die IT aus, woher weißt du die Telefonnummern der Kunden, die du anrufen solltest?
Es gibt schon sehr lange Statistiken, die besagen eine dreitägige Nicht-Verfügbarkeit des IT-Systems haben einen Großteil der Unternehmen nicht überstanden.
Zu obigem Thema kommt auch dazu, wie lange brauche ich, um überhaupt die Daten wiederherstellen zu können. Es ist ja wunderbar, wenn alles, in der Regel in Images gesichert ist. Braucht man nun eine einzelne Datei daraus, so muss man, je nach Backupsystem, das gesamte Image zurücksichern (wo findet man schnell mal 500 GB freien Platz) um dann die eine Datei mit 2 GB daraus extrahieren zu können. Oder eben auch, das Image ist gesichert, muss aber über die Internetleitung übertragen werden. Diese ist im Moment aber gut ausgelastet bzw. die Übertragung von großen Datenmengen ist noch immer problematisch, muss über eine geeignete Software gemacht werden.
Bedenke dies alles mit, auch wie kommt man zu den verschiedensten Passwörtern usw. Wer hat die Daten, wo sind sie? Der/diejenige ist gerade in Urlaub, im Krankenhaus. Woher weiß ich überhaupt von wann (Zeitpunkt) das Backup ist, das ich einspielen möchte.
Wir raten, mach dir einen definitiven Plan, wie im Falle des Falles vorzugehen ist. Das beginnt bei der Beschaffung eines neuen Servers (im nächsten Computershop) und endet bei den Zeiten, die für die verschiedensten Restores benötigt werden. Schreib diese Tabelle mal zusammen und lass diesen schlimmen Fall dann am 24.12. um 16:30 auftreten. Wie sieht der Zeitablauf aus. Wenn du dann auch noch einen Datenverlust hast, denk an die dann sehr kurzen Fristen der DSGVO. Ich wünsche uns allen, dass wir das nie brauchen.
Diese Frage kommt immer bei entsprechend großen Datenmengen, also wenn die Nacht für die Sicherung zu kurz wird.
Unsere Erfahrung. Nur Veränderungssicherungen sind extrem gefährlich. Denn im Falle der Rücksicherung braucht nur ein Medium in der Kette defekt zu sein und das Restore ist nicht mehr möglich. Daher muss in den Sicherungskonzepten immer ein aktuelles und vollständiges Backup auf dem Sicherungsmedium gespeichert sein.
Bitte achte bei der Erzeugung der Backupdateien darauf, dass das Ende des Backups rechtzeitig vor dem Weiterkopieren auf das Sicherungsmedium abgeschlossen ist. Du solltest das monatlich überprüfen.
Bitte nimm dir die Zeit, auch den Restore der Daten regelmäßig zu prüfen. Regelmäßig bedeutet in diesem Falle, zumindest jedes halbe Jahr, besser öfter. D.h. wirklich in das Testsystem die Backupdaten reinspielen. Es müssen die Daten des letzten Tages, also des Tages der Datensicherung im Zugriff stehen.
Es kommt leider zu oft vor, dass nur Filezuwachs und Datum geprüft werden, aber in der langen Kette irgendetwas nicht stimmt und du im Falle des Falles, dann doch keine Daten hast.
ACHTUNG: Im Falle eines Verschlüsselungstrojaners ist die Gefahr, dass durch einen Fehler / Irrtum in der Konfiguration, der Trojaner auch dein Backup verschlüsselt, extrem hoch. Nur sehr sehr versierte IT-Betreuer sind in der Lage dies richtig aufzusetzen.
Daher unser Rat, immer mechanisch getrennt aufbewahren. Und auch außer Haus. Denkt an Hochwasser, Blitzschlag, generelle Überspannung, Feuer, Diebstahl.
Ich habe persönlich noch keinen IT-Betreuer kennengelernt, der das wirklich beherrscht. Daher rate ich lieber ein paar Euro mehr für die Sicherheit auszugeben.
Für umfassende Desaster Recovery Szenarien, wendet euch gerne an uns.
Zum Thema Angriffe siehe auch: Real-Time DDoS Attack Map | NETSCOUT Omnis Threat Horizon, https://horizon.netscout.com/
EIn leider sehr trauriges Beispiel was passieren kann, wenn man sich nicht wirklich um die Datensicherung kümmert.

Gerne auch der [Link dazu](
) der im April 2025 noch funktioniert.
Die paar tausend CHF für die Sicherungsmedien hätte die Bächerli AG gerettet, so ist ein erfolgreiches Unternehmen, schlichtweg vernichtet worden.
Also denke auch daran, ob der von dir beauftragte Dienstleister für das zu tragende Risiko überhaupt versichert ist.
Auch diese Frage kommt immer wieder.
Der Grundgedanke: Lieber ein geplanter Stillstand als ein unkontrollierter Ausfall.
D.h. es geht darum, dein ERP System (und auch deine restliche Serverlandschaft) immer zur Verfügung zu haben. Dies kann man großteils durch vorbeugende Wartung erreichen.
So sagt uns die Statistik, dass Serverplatten alle vier Jahre ausgetauscht werden müssen.
Server Hardware gehört alle sieben Jahre ausgetauscht.
Auch wenn das die Metallverarbeiter manchmal schreckt, deren teure Maschinen auch mal 30 Jahre halten, hier handelt es sich um hochkomplexe elektronische Geräte, die 24/7 im Einsatz sind und von denen wir erwarten, dass sie immer funktionieren.
Und was dazu kommt, wenn dein Server ausfällt: es steht nicht nur eine Maschine, sondern die ganze Firma. D.h. du hast nicht nur den Produktionsausfall eines Mitarbeiters, sondern deines gesamten Teams. Du kannst keinen Kunden anrufen, weißt nicht was zu liefern / fertigen ist, usw.
Daher: Ja das kostet Geld; ein ungeplanter Stillstand kostet dramatisch mehr und ist immer mit Datenverlust verbunden.
Ausgehend von dem Gedanken, dass du deine Daten in eine Neuinstallation deines Kieselstein ERP übertragen willst / musst und mit diesem Datenbestand weiterarbeiten willst, müssen folgende Datenbanken / Dateien gesichert werden.
Nachfolgend eine lose Aufstellung der Aufgaben deines IT-Betreuers für den Betrieb deines Kieselstein ERP-Systems, welche nicht vollständig ist.
Es sollte dies dazu dienen, den Umfang einer verantwortungsvollen IT-Betreuung zu skizzieren. Ergänzungen dazu sind willkommen.
Bitte beachte auch, dass dein Kieselstein ERP zwar die IT massiv nutzt. Die Betreuung deiner IT ist aber in keinster Weise die Aufgabe der Genossenschaft bzw. der Techniker:innen der Consultants, auch wenn das andere Firmen anders handhaben mögen. Siehe dazu auch Update
Welche Aufgaben sollte die IT-Betreuung nun übernehmen:
Anmerkung:
Wenn du diese Betreuung selbst übernimmst, gehen wir davon aus, dass eine entsprechende Qualifikation gegeben ist. Du also auch die Verantwortung dafür übernimmst / übernehmen kannst.
Von der Verfügbarkeit des Backups (zu jeder Zeit) bis zu Updates usw..
Für die Einrichtung der Zugangsdaten des (externen) Betreuers siehe
Dein Kieselstein ERP hat grundsätzlich zwei Datenbanken.
Da diese Frage immer wieder kommt, also kann ein Super Spezialist die Daten der Dokumente verändern? Hierzu muss man folgendes wissen:
Ob man dies nun, mit einer entsprechend kriminellen Energie auch richtig stellen könnte, ist mir nicht bekannt. Hier kommt mit dazu, dass die Person die dieses macht, physikalisch auf deinen Kieselstein ERP Server Zugriff haben muss (root). Wenn das alles gelingt, hast du ein anderes Problem.
Daher betrachten wir diese Daten als unveränderbar.
Beschreibung der Installation deines Kieselstein ERP Clients bis Mai 2025
Voraussetzung: Du hast auf den jeweiligen Rechnern ausreichende Installationsrechte und bist mit den Arbeiten mit Programm-Files und allem, was so dazu gehört, vertraut. Für Unterstützung wende dich als Mitglied der Kieselstein-ERP eG gerne an eine:n der Consulter:innen.
Ab der Version 0.0.0.8 deines Kieselstein ERP können die erforderlichen Installationsdateien über einen Weblink geladen werden. Gehe dazu in einem Browser auf http://IPADRESSE_KIESELSTEIN_ERP:8080.

für Clients ab der Versionsverwaltung (>0.0.14) siehe
Klicke nun auf download clients 
Hier findest du nun die vom Installationsverantwortlichen zusammengestellten Dateien zum Download zur Auswahl.

Es sind dies alle Dateien die in deinem Kieselstein-ERP im Verzeichnis
?:\kieselstein\dist\clients abgelegt sind.
Es ist Aufgabe des/der installierenden hier alle richtigen Dateien zusammenzustellen. Das bedeutet aktuell auch, dass nach jedem Update die Dateien anzupassen sind.
Das Kieselstein-Desktop-Icon findest du hier.
In der Client.zip sind die beiden Verzeichnisse für die Installation enthalten. Lade diese herunter und kopiere diese z.B. auf c:\kieselstein\client.

Im bin Verzeichnis findest du drei Dateien:

In Windowssystemen richte dir eine Desktop-Verknüpfung auf die kieselstein-ui-swing.bat ein. Dieser gibst du das Icon Kieselstein.ico.
In Linux bzw. MAC-OS verwendest du die kieselstein-ui-swing.
Nun benötigst du noch das passende Java (wenn nicht schon installiert), welches ebenfalls im Browser als Download zur Verfügung steht (zulu ….).
Üblicherweise kann ein / alle eventuell vorhandenes(n) Java entfernt werden. -> EMPFOHLEN
Installiere nun das Azul Java mit den default Einstellungen. Einzig bei der Frage nach dem Java Home wähle
immer Verfügbar. Details siehe
Nun kannst du deinen Kieselstein ERP Client starten.
Benutzername und Passwort erhältst du von deinem/r Kieselstein ERP in Haus Verantwortlichen.
Hinweis:
Sollte nach eine Neuinstallation von Java, das Java trotzdem nicht zur Verfügung stehen (prüfen z.B. aufmachen des CMD (Command-Shell) und Java -version), so hilft unter Umständen, gerade bei komplexen Berechtigungen, ein Neustart des Rechners.
Hinweis:
Es hat sich bewährt, auf den Rechnern der Poweruser auch einen Teamviewer (https://www.teamviewer.com/de/download/windows/) installiert zu haben. Wir gehen davon aus, dass jeder ERP Anwender den Teamviewer starten kann und darf.
Von Kieselstein ERP verwendete Ports siehe bitte Server
Wir setzen zurzeit folgende Versionen voraus:
Gerade im Clientbereich kann es vorkommen, dass andere Versionen eingesetzt werden. Bitte beachte, dass wir für das richtige Verhalten der Software ausschließlich die unten von uns zur Verfügung gestellte OpenJDK8 verwendet werden sollte. Bitte beachte bei der Verwendung von original Oracle Java 8/11 Versionen, dass diese lizenzkostenpflichtig sind.
Der Basis-Link für das erprobte Zulu Java findest du unter https://www.azul.com/downloads/?package=jdk#zulu Hier dann Java 11 mit jdk-FX auswählen.
Den Download einer freien OpenJDK Version mit Java 11 für deinen Client finden man unter:
https://www.azul.com/downloads/?version=java-11-lts&os=windows&package=jdk-fx

Achte bei der Installation des Javas darauf, dass:

Alternativ kann seit der Kieselstein Version 1.0.0 der Client auch mit einer OpenJDK Version 11 starten. Hinweis: bei einem Mac mit Apple Silicon Prozess wird die Java-Zulu FX Version vorausgesetzt.
Wenn unter Windows der Client nur kurz durchläuft und sich dann wieder automatisch beendet, so ist der Pfad in dem deine eigentlichen Clientdateien stecken zu lange. Mache diese kürzer.
Wir raten dies unter ?:\Kieselstein\Client einzurichten
Es werden viele Fehler in der Client-Console angezeigt.
Die Barcode sind zerstückelt.
Beim Drucken von Artikeletiketten erscheint das Vorschau-Fenster nicht. Fährt man mit der Maus über den Client erscheinen teilweise die “Bilder” des Druck-Vorschau-Fensters.

Bitte prüfe, ob das aktuelle Java installiert ist.
Es muss 
angezeigt werden. Wird ein älteres Java angezeigt, kann es zu den beschriebenen Effekten kommen. Wichtig eben auch, nur Java mit der FX Erweiterung.
Sollte die Anzeige trotzdem so “spinnen”, dann ist dies ein Problem der Grafikkarte bzw. des Treibers.
Das kann auch auftreten, wenn der Rechner ohne Bildschirm installiert ist und man nur per Fernwartung (Teamviewer, Remote Desktop, …) zugreift.
Startet man unter Windows den Batch zum ersten Mal, kommt

So auf Weitere Informationen klicken und dann
Auf den Trotzdem ausführen Button klicken.
Dies bleibt bis zum nächsten Update / Erneuerung des Batchs erhalten.
Hat man, wie oben beschrieben den Client.bat (eigentlich die ?:\kieselstein\dist\client\bin\kieselstein-ui-swing.bat ) als Verknüpfung auf den Desktop gelegt, so wünscht man sich oft, diese auch in den Start bzw. die Taskleiste zu bringen.
Der Trick dafür geht wie folgt:


Weitere Optionen anzeigen und kann damit dann An Start anheften bzw. an Taskleiste anheften auswählen.Da Windows 7 schon seit etlichen Jahren nicht mehr supported wird und alleine schon aus diesem Titel dies eine grobe Verletzung der DSGVO darstellt, wird Windows 7 nicht unterstützt. Bitte verwende aktuelle Betriebssysteme, gegebenenfalls auch in einer VM (Virtual Machine) z.B. mit Virtual Box.
Neben der reinen Netzwerk-Zugriffs-Geschwindigkeit (siehe Hauptmenüleiste, Hilfe, Info) ist unter Umständen auch der Back-Call des Servers an den Client für die Geschwindigkeit, meist auch für die Langsamkeit verantwortlich.
D.h. es müssen sowohl der Server vom Client aus als auch der Client vom Server aus, mit ihren Netzwerk-Namen als auch mit den IP Adressen problemlos und schnell erreicht werden können. Ist dem nicht so, dauert das Blättern zwischen den Modulreitern entsprechend lange.
Gerade in Linux-Systemen oder bei VPN Verbindungen werden hier gerne Konfigurationsfehler gemacht.
In anderen Worten, es muss der DNS Name immer auf einen internen DNS Server zeigen, dann ist zumindest von dieser Seite her die Geschwindigkeit entsprechend optimiert.
Für Windows-User siehe Eigenschaften der Netzwerkverbindung

Nachfolgend eine kleine Beschreibung der Besonderheiten beim Update der Clients, von aus älteren Versionen.
Manchmal will man die Installation vorab testen.
Hier ist wichtig zu wissen, dass die neueren Clients, z.B. 0.1.1, bereits beim Starten, bevor noch irgendeine Oberfläche angezeigt wird, den Server um die Versionsnummer (der Datenbank und des Servers) abfragen.
Das bedeutet, wenn du mit einem neuen Client gegen einen alten Server testest, wird dies nicht funktionieren. Der optische Eindruck ist, dass der Client nicht startet. Startest du den Client aus der Commandshell, ohne javaw.exe so siehst du
Got Exception No such EJB method org.jboss.ejb.client.EJBMethodLocator@bc7b26d3 found on lpserver/ejb/SystemFacBean java.lang.IllegalArgumentException: No such EJB method org.jboss.ejb.client.EJBMethodLocator@bc7b26d3 found on lpserver/ejb/SystemFacBean
Das bedeutet, der Client konnte zwar eine Verbindung zum Server herstellen, aber die Abfrage nach der Versionsnummer ist bereits fehlgeschlagen.
Hier hilft nur den Server auch zu aktualisieren.
Üblicherweise wird beim Start des Clients auch die Sprache vorgeschlagen, die für den Anwender die richtige ist. Diese Definition findest du unter
?:\Kieselstein\client\bin\kieselstein-ui-swing.bat
Hier steht (ca. in Zeile 37)
´´´
set DEFAULT_JVM_OPTS="-XX:PermSize=64m" “-XX:MaxPermSize=256m” “-Djava.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory” “-Djava.naming.provider.url=remote+http://192.168.100.14:8080” “-Dloc=sl_ " “-Dsun.java2d.dpiaware=false”
´´´
mit dem Parameter -Dloc= kann gesteuert werden, welche Sprache vorgeschlagen wird. Bitte beachte: sollte die hier eingetragene Sprache in deinem Kieselstein ERP nicht aktiviert sein, so wird die nächstliegende Sprache verwendet.
Für die aktuell unterstützten Sprachen müssen folgende Einträge gemacht werden. Welche Einträge in aktiviert sind, findest du in der lp_locale.
| locale | Sprache |
|---|---|
| deAT | Deutsch mit österreichischer Sprachausprägung |
| deCH | Deutsch mit schweizer Sprachausprägung |
| deDE | Deutsch mit deutscher Sprachausprägung |
| enGB | Britisches Englisch (nicht vollständig übersetzt) |
| enUS | Amerikanisches Englisch |
| itIT | Italienisch |
| plPL | Polnisch |
| sl | Slowenisch. Bitte beachte, dass die Definition des Locales mit sl_< >< > mit zwei nachfolgenden Spaces erfolgen muss. Ist eigentlich Englisch, aber um die Zahlen wie in Europa üblich darzustellen als Slowenisch definiert |
Weitere Details siehe
Den Kieselstein ERP Client auf einem frischen Debian installieren
pgadmin installieren –» siehe Clientbeschreibung siehe https://www.itzgeek.com/how-tos/linux/debian/how-to-install-pgadmin-on-debian-11-debian-10.html sudo apt update sudo apt install -y apt-transport-https ca-certificates software-properties-common curl
curl -fsSL https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo gpg –dearmor -o /usr/share/keyrings/pgadmin-keyring.gpg
echo “deb [signed-by=/usr/share/keyrings/pgadmin-keyring.gpg] https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bullseye pgadmin4 main” | sudo tee /etc/apt/sources.list.d/pgadmin4.list
sudo apt update sudo apt install -y pgadmin4-desktop Das Programm einfach unter Aktivitäten, Anwendungen (die Punkte unten) und pgadmin4 eingeben (rechtsklick, zu Favoriten)
Wenn man auch die WebObefläche nutzen will (was ich persönlich nicht mag) sudo apt install -y pgadmin4-web (ist das wirklich erforderlich?)
sudo /usr/pgadmin4/bin/setup-web.sh
pgadmin EMail Adresse postgres@wa-consulting.at pw: postgres
Frage nach Installation des Webservers mit y beantworten und dann restart Apache Webserver und dann http://127.0.0.1/pgadmin4
Siehe bitte allgemeine Client Beschreibung
Den Midnight Commander verwenden:
sudo apt install mc
Um das passende Java11 FX zu bekommen sind folgende Schritte erforderlich:
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0xB1998361219BD9C9
apt-add-repository 'deb http://repos.azulsystems.com/ubuntu stable main'
apt update
apt install zulu-11
Danach das Java Home manuell hinzufügen:
nano /etc/environment
JAVA_HOME="/usr/lib/jvm/zulu-11-amd64"
source /etc/environment
echo $JAVA_HOME
Anzeige:
/usr/lib/jvm/zulu-11-amd64
mit dpkg installieren, einmal apt install -f, dann nochmal installieren!
apt --fix-broken install
Gegebenenfalls den Rechner mal neu starten
Für eine allgemeine Anwendung kannst du den Kieselstein ERP CLient unter /opt/kieselstein installieren (und hier auch zentral alle weiteren Dinge sammeln).
Bei einem lauffähigen Kieselstein ERP System findest du unter http://KIESELSTEIN_ERP_SERVER_ADRESSE:8080 alle nötigen Dateien (Für KIESELSTEIN_ERP_SERVER_ADRESSE in der Regel die IP-Adresse deines KLieselstein ERP Servers angeben )
Das geht am besten mit “desktop” Files. Ein Muster findest du auch auf deinem Server unter /opt/kieselstein/dist/clients/ entweder im tar/gz oder direkt dann im bin Verzeichnis.
[Desktop Entry]
Name=Kieselstein Client
Comment=Kieselstein ERP Client
Exec=/opt/kieselstein/client/bin/kieselstein-client
Icon=/opt/kieselstein/client/bin/kieselstein-icon-square-96x96px.png
Terminal=false
Type=Application
Categories=Office
Als Icon kannst du aus dem Gitlab gerne die Kieselstein ERP Icons verwenden, bzw. das im Client.zip mit enthaltene Icon.
Für eine allgemeine Anwendung kannst du den Kieselstein ERP CLient unter /opt/kieselstein installieren (und hier auch zentral alle weiteren Dinge sammeln).
Also:
cp /opt/kieselstein/client/bin/kieselstein.desktop /home/Benutzername/Schreibtisch/kieselstein.desktop
Siehe bitte allgemeine Client Beschreibung
Übernommen aus obigem Artikel.
Nach jedem Neustart schlägt Windows vor, das Einrichten des Geräts zu beenden. Um dies unter Windows 10 abzuschalten, gehe bitte folgendermaßen vor:
Du kannst den Client deines Kieselstein ERP auch unter macOS betreiben.
Wichtig ist von Anfang an zu unterscheiden, mit welchem Prozessor dein MAC ausgestattet ist. Entweder X64 oder Arm. Diese Information findest du unter Apfel, über diesen MAC
und dann
Der Apple M1 ist das erste Arm-basierte System-on-a-Chip (SoC) von Apple für seine Mac-Computer. Wikipedia
Das benötigte Java findest du unter https://www.azul.com/downloads/?version=java-11-lts&os=macos&package=jdk-fx#zulu
Hier:
Nun das entsprechende Paket auswählen,

in der Regel .dmg.
In die Downloads gehen und
mit einem Doppelklick das JDK11 von Azul installieren.

Du kannst nun prüfen, ob die soeben installierte Javaversion auch richtig installiert wurde. Dazu ein Terminal öffnen und Java -Version eingeben.

Starte nun den Safari / deinen Browser gehe dazu auf http://IPADRESSE_KIESELSTEIN_ERP:8080.
gehen. Hier wird von der Kieselsteininstallation
bereitgestellt.
Die Client.zip rechts anklicken und herunterladen.
Als Ort den Schreibtisch auswählen.
Mit einem Doppelklick entzippen.
Ausführenberechtigung setzen:
Mit dem Terminal (Programme, Dienstprogramme, Terminal)
in das Verzeichnis wechseln.

mit
chmod +x ./kieselstein-ui-swing
die Ausführenberechtigung für das Shellscript setzen.
Nun im Finder in das Verzeichnis (Schreibtisch, Kieselstein, bin) wechseln und

rechte Maustaste, Öffnen mit, Andere

Hier bei “Aktivieren” “Alle Programme” auswählen und das “Immer öffnen mit” anhaken.
Nun das Terminal auswählen.

Die nun folgende Sicherheitsmeldung mit “Öffnen” bestätigen.

Berechtigungsanpassungen für den Datenzugriff auf MacOS wurden im FAQ-Bereich der Doku genauer beschrieben.