JonDa.Server: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Zeile 379: | Zeile 379: | ||
LOST.DAT (nur Zwischendatei) verschimmelte Restaten landen dort | LOST.DAT (nur Zwischendatei) verschimmelte Restaten landen dort | ||
STAY.DAT (nur Zwischendatei) GGG.DAT+STAY.DAT=AUFTRAG.DAT | STAY.DAT (nur Zwischendatei) GGG.DAT+STAY.DAT=AUFTRAG.DAT | ||
AUFTRAG+TS.BLA (cOrgaMon.App) Sicherheitskopie, die beim Neustart von cOrgaMon.App erstellt wird (doAbschluss) | |||
FOTO+TS.BLA (cOrgaMon.App) Sicherheitskopie, die beim Neustart von cOrgaMon.App erstellt wird (doAbschluss) | |||
=== ftp === | === ftp === |
Version vom 20. April 2023, 17:57 Uhr
- Der JonDaServer ist die "App"-Identität des cOrgaMon.exe
- Er betreibt einen XMLRPC Server im Namespace "jonda"
- Hier sieht man die beiden Server-Prozesse "App-Service" (im Vordergrund als win32 KOnsolenanwendung) und "Foto-Service" (im Hintergrund als Win32-GUI) bei der Arbeit.
- Die beiden Server-Programme für Win32-Systeme sind die Kommunikations-Partner für die Android Anwendung OrgaMon-App.
- Die Server arbeiten ohne Datenbank und Sychronisieren sich mit OrgaMon über einen gemeinsamen FTP-Ablage Bereich.
- Beiden Anwendungen werden heutzutage als Win32-Konsolenanwendungen unter wine auf Linux ausgeführt.
- Beide Server-Prozesse sind vollständig im Quelltext veröffentlicht im Rahmen des OrgaMon-Open-Source Projektes. Beide Dienste werden über cOrgaMon.exe geleistet, dieses Programm kann in der mit der Identität (Entwickler#OrgaMon-Server-Identitäten) "Foto" und der Idendität "App" gestartet werden.
Identitäten
AppServer
- Der AppServer dienstleistet die Funktionalität "jonda.proceed" hinter dem "senden" für die OrgaMon-App auf den Smartphones
- Der Server wird ohne GUI für Verwaltungs- und Rechercheaufgaben geliefert (Win32, cOrgaMon.exe)
- Im Regelbetrieb wird die Konsolenanwendung auch unter Wine eingesetzt
- Im OrgaMon lässt sich der Dienst unter "App" Verwalten
cOrgaMon.ini
; ; durch mehrere Sektionen (Name in der eckigen Klammer, im Moment System) ; kann zwischen mehreren Mandanten unterschieden werden. So ist es ; möglich mehrere Instanzen des Servers auf einer System zu betreiben. ; Und für jeden Id, für jede Sektion folgt dann andere Einstellungen. ; ; Bei Start wird dem OrgaMon-App-Server über den Kommandozeilenparameter ; --Id=Id dieser Sektionswert mitgegeben (default=System) ; [System] ; ; Optionales Feld, es muss einfach nur mit einem Wert belegt sein, ; ; wenn nicht wird der Wert "System" angenommen. Alle weiteren ; Optionen werden dann unter der Sektion [System] gesucht. ftpuser=System ; Für die Identität "App-Server" ; ; für das Script "up.php" des ./web Verzeichnisses des OrgaMon-App-Server ; ; Für die Identität "Web-Server" ; ; wird auch aus im 2. Rang aus dem Kommandozeilenparameter "-Port=" ermittelt host= port=3049 ; ; Für die Identität "App-Server". ; ; =JA ; Damit kann man ; die Datum/Uhrzeit Prüfung beim "senden" Versuch der Handys ; ausschalten ; NoTimeCheck=NEIN ; ; Für die Identität "App-Server" ; ; Für die Ausführung der XMLRPC-Funktion "senden" bei "einfacher Liste" ; Funktion @XMLRPCHost:XMLRPCPort:abu.Senden() ; XMLRPCHost=raib23 XMLRPCPort=3042 ; ; Für die Identitäten "App-Server" und "Foto-Server" ; BackUpPath=..\bak\ WebPath=..\web\ FTPPath=..\ftp\ LogPath=..\log\
- siehe auch Installation.Arbeitsplatz#OrgaMon.ini
Optionen
- Der JonDa-Server kann bestimmten Geräten bestimmte Programm-Optionen mitgeben. Dies wird mit
OPTIONEN=
in der Geräte-Einstellungsdatei gesteuert.
a
- KEINE_DOPPELEINGABE_ZAEHLERSTAND_ALT
b
- KEINE_DOPPELEINGABE_ZAEHLERNUMMER_NEU
c
- KEINE_DOPPELEINGABE_ZAEHLERSTAND_NEU
Einstellungen
- Pro Gerät kann eine .ini Datei angelegt werden, diese Datei steuert individuelle Einstellungen
- Dateiname ist
<3stellige GeräteNummer>.ini
#
# Ist das Datum/Uhr des Handys falsch einstellt unterbleibt die
# weitere Datenverarbeitung.
#
# JA | NEIN
#
ZEIT_PRÜFUNG=
#
#
#
#
OPTIONEN=
#
# für die Lager-Funktionen muss diese Option auf "JA" gesetzt werden
#
# JA | NEIN
#
EinfacheListe=
#
# Protokolle befinden sich im Verzeichnis ./dat/Protokolle
# Ist dieser Schalter gesetzt, so wird davon ausgegangen, dass es hier
# Unterverzeichnisse gibt. Der Namen der Unterverzeichnisse ist
# in dieser Einstellung angegeben. Default ist <Leer> also kein
# weiteres Unterverzeichnis.
#
# <Leer> | Unterverzeichnis\
#
ProtokollPfad=
ShopServer
Ein XMLRPC der vom Webshop in Anspruch genommen wird.
FotoServer
Installation
- Betrieb und Installation von cOrgaMon.exe auf Linux Linux.wine
- Trage die Ip Adresse des OrgaMon-App-Servers im DNS in firma.orgamon.net ein
- Lege ein 9 stelliges Passwort für "firma" fest, Symbolisch hier "***pwd***" genannt
- Erstelle einen nginx-Host "https://firma.orgamon.net", der auf ./tls zeigt
- Erlaube nur Zugriffe mit dem richtigen Passwort
if ($cookie_pwd != "**pwd**") { return 403; break; }
- Mache den vsftp FTPS fähig
- Lege einen Linux-Benutzer an, mit dem Namen "firma" und dem Passwort "***pwd***", der auf das Verzeichnis ./ftp zeigt
Sektions-Migration
- Den Id, sprich die Sektion der .ini, sprich den Mandanten oder den Namensraum unter dem der OrgaMon-App-Server läuft kann man ändern, dies muss aber an einigen Stellen gemacht werden:
- zunächst eine Diagnose: Stellen Sie zunächst fest unter welcher Id das System im Moment läuft
systemctl status | grep cOrgaMon
- es werden alle bisherigen --Id ausgegeben
- es wird nun beschrieben wie Sie "alte-Id" auf "neue-Id" ändern können
/etc/crontab editieren
10 02 * * * root systemctl stop cOrgaMonApp@alte-Id 10 02 * * * root systemctl stop cOrgaMonFoto@alte-Id 15 02 * * * root systemctl start cOrgaMonApp@alte-Id 15 02 * * * root systemctl start cOrgaMonFoto@alte-Id
- umstellen auf
10 02 * * * root systemctl stop cOrgaMonApp@neue-Id 10 02 * * * root systemctl stop cOrgaMonFoto@neue-Id 15 02 * * * root systemctl start cOrgaMonApp@neue-Id 15 02 * * * root systemctl start cOrgaMonFoto@neue-Id
OrgaMon.ini in "Documents" editieren
[alte-Id]
- umstellen auf
[neue-Id]
- Merken Sie sich das angegebene Verzeichnis im Wert DatabaseName=, dieses Verzeichnis ist für den nächsten Schritt nötig
cOrgaMon.ini im .\dat editieren
[alte-Id]
- umstellen auf
[neue-Id]
systemctl Befehle durchführen
systemctl stop cOrgaMonApp@alte-Id systemctl disable cOrgaMonApp@alte-Id systemctl stop cOrgaMonFoto@alte-Id systemctl disable cOrgaMonFoto@alte-Id
systemctl enable cOrgaMonApp@neue-Id systemctl enable cOrgaMonFoto@neue-Id systemctl start cOrgaMonApp@neue-Id systemctl start cOrgaMonFoto@neue-Id
Neustart unter Linux
- da wine einzelne Resourcen für alle cOrgaMon.exe Prozesse teilt, muss ein Neustart immer alle Instanzen und Identitäten betreffen
- zudem verwendet wine Optimierungen die eine verzögerte Freigabe dieser Resourcen bewirkt
- somit ist nach dem Beenden der Prozesse eine Wartezeit einzuplanen
- geschieht das nicht, kann das Ergebnis sein, dass z.B. Sockets oder Dateien noch nicht freigegeben sind
- Bei gleichzeitigem Start der Idendität "App" und "Foto" kann Streit um Resourcen entstehen, wodurch der Start dann misslingt
systemctl stop cOrgaMonApp@~FirmenKurzbegriff~ systemctl stop cOrgaMonFoto@~FirmenKurzbegriff~ sleep 100 systemctl start cOrgaMonFoto@~FirmenKurzbegriff~ sleep 100 systemctl start cOrgaMonApp@~FirmenKurzbegriff~
Kommunikation bei "senden"
- Schritte des Skripts
- up.php zieht eine neue Transaktions-Nummer und erstellt das gleichnamige Verzeichnis
- up.php hat Zeile für Zeile Auftragsergebnisse in die Datei [] geschrieben
- Final kontaktiert up.php den XML-RPC Server und führt die Funktion "proceed" aus
# # Initialisierungsphase # up.php?id=666;50000;1.011 // GeräteID;LetzteErfolgreicheTAN;Programmversionsnummer // Antwort: liefert im BODY eine neue TAN # # Datenübertragungsphase # up.php?tan=50999&data=RID1 // lädt Daten hoch up.php?tan=50999&data=RID2 // ... up.php?tan=50999&data=RID3 // ... # # up.php?proceed=50999 // fordert zum verarbeiten auf, liefert "OK" im BODY
Diagnose
# # Test der XMLRPC-Verfügbarkeit # liefert im BODY die BasePlug-Infos # http://<deinAppServer>/up.php?info=JA # # Ausgabe der aktuellen Logs für die Idendität "Foto" # journalctl -e -nall -t cOrgaMonFoto
Info zum Verzeichnisinhalt
OrgaMon
- TTTTT.DAT File of mderec, Archiv für die dem OrgaMon übertragenen TRN Eingabe-Daten
web
- Dieses Verzeichnis ist im Web Sichtbar, aber nur für http:// Anfragen, dies kann abgeschaltet werden, sobald alle OrgaMon-Apps >= 2.043 sind
- Verzeichnis .\web\
TTTTT.auftrag.utf-8.txt (vom Server) das neue Auftragsvolumen für die OrgaMon-App TTTTT.txt wird von XMLRPC.StartTAN erstellt wird vom Script up.php erweitert und enthält dann die Eingabeergebnisse der OrgaMon-App ("senden")
htm
Die ist das Hauptverzeichnis für das App-Server-Dashboard
- Info-Dokumente für den Admin, das sind statische html-Dateien, die durch den Server ab und zu neu erstellt werden
001.html ... nnn.html
ausstehende-details.html
ausstehende-fotos.html
geraete.html
-neu.html
senden.html
vertrag.html
- Viele dieser Dokumente waren ehemals in "web" gespeichert was ein Sicherheitsrisiko war
- Im nginx sollte ein Host eingerichtet werden, der nur noch aus dem internen Netz erreichbar ist
- Im index.php nach up.php suchen, einen Prefix einrichten, so dass up.php lokal lauffähig wird
tls
- "web" ist unverschlüsselt, bei "tls" verbinden sich die Clients per https://
- Clients ab 2.043 sprechen nur noch https://
- Zur Absicherung benötigt man Zertifikate, im Moment sind alle OrgaMon-Apps einem Subdomain von *.orgamon.net zugeordnet
- Mit einem Script kann man (z.B. in /etc/nginx/orgamon.net) sich die jeweiligen Zertifikat-Dateien holen
#!/bin/bash # # update.sh # scp orgamon.net:/etc/letsencrypt/live/orgamon.net/privkey.pem . scp orgamon.net:/etc/letsencrypt/live/orgamon.net/fullchain.pem . scp orgamon.net:/etc/letsencrypt/live/orgamon.net/cert.pem .
dat
./dat/Daten
# # binlager-Tabellen (OrgaMon internes DB-Format aus binlager.pas) # AUFTRAG+TS.BLA alle bekannten Aufträge (plus TimeStamp) auf allen Geräten FOTO+TS.BLA Foto (plus TimeStamp). binäre Tabelle aller bekannten Meldungen an den OrgaMon wobei F?= beteiligt war. # # Im Rahmen des Start-Ups von cOrgaMon.exe werden die Tabellen AUFTRAG+TS.BLA und FOTO+TS.BLA # von "alten" Datensätzen befreit, Datensätze, die 32 Tage und älter sind, werden in der Tabelle # gelöscht. Die Tabellen werden neu aufgebaut. # # Bei jedem Einfügen in die Tabelle wird das Datum aufgezeichnet # GGG.DAT File of mderec AUFTRAG.GGG.DAT File of mderec abgezogen.GGG.DAT TgpIntegerList (File of RID) abgearbeitet.DAT TgpIntegerList (File of RID) unberuecksichtigt.txt Textdatei, Liste mit TANS die OrgaMon-Desktop noch nicht abgeholt hat?!
./dat/db
- Bei jedem Neustart des App-Servers werden Kopieen aus ./dat/Daten gezogen, damit sich Foto-Dienste und "proceed" nicht in die Quere kommen
AUFTRAG+TS.BLA (eine Kopie aus ./dat/Daten) binäre Tabelle aller bekannten Aufträge (plus TimeStamp) auf allen Geräten _AUFTRAG+TS.BLA zweite, meist ältere Variante dieser Tabelle die manuell zur Seite gestellt wird wenn sehr alte Transaktionen wiederholt werden sollen, bei denen die Gefahr besteht, dass AUFTRAG-RIDs in AUFTRAG+TS.BLA nicht mehr vorhanden sind.
Eingabe.GGG.txt GGG ist die Gerätenummer eine csv mit folgender Kopfzeile (diese Kopfzeile wird nicht in der .csv gespeichert!) DATUM;UHRZEIT;RID;REGLER_NUMMER_NEU;ZAEHLER_NUMMER_NEU
./dat/TTTTT
- Transaktionsverzeichnise, durchnummeriert von 10000 bis 99999
- jedes "senden" verbraucht eine Transaktions-Nummer und erzeugt ein Unterverzeichnis mit dieser Nummer
TTTTT
ist die Transaktionsnummer- Verzeichnis .\dat\TTTTT\
GGG.DAT (vom FTP) Netto-Auftragsvolumen für dieses Gerät, wird frisch vom ftp-Bereich geholt. GGG.ZIP (vom Gerät) komplett Daten vom Gerät kommend TTTTT.DAT (zum OrgaMon) Meldenswerte Volumen für OrgaMon (Bericht Datei) TTTTT.TXT (vom Gerät) Eingaben den Monteures AUFTRAG.DAT (zum Gerät) das neue, vom Server zusammengestellte Volumen auftrag.txt (zum Gerät) das neue, vom Server zusammengestellte Volumen in Textform JONDA.DAT (vom Gerät) vom Monteur getätigte Eingaben. GERAET.DAT (vom Gerät) Geräteeinstellungen LOST.DAT (nur Zwischendatei) verschimmelte Restaten landen dort STAY.DAT (nur Zwischendatei) GGG.DAT+STAY.DAT=AUFTRAG.DAT AUFTRAG+TS.BLA (cOrgaMon.App) Sicherheitskopie, die beim Neustart von cOrgaMon.App erstellt wird (doAbschluss) FOTO+TS.BLA (cOrgaMon.App) Sicherheitskopie, die beim Neustart von cOrgaMon.App erstellt wird (doAbschluss)
ftp
- Verzeichnis .\ftp\, das zentrale Up- Downloadverzeichnis des Servers
# Erzeugt durch cOrgaMon.App # # dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon gelöscht) # TTTTT.DAT Meldungen der OrgaMon-App an OrgaMon (binär) TTTTT.utf-8.txt Meldungen der OrgaMon-App an OrgaMon (als Text) # # statisch (Informativ, stellt 1:1 die aktuellen Daten des Gerätes GGG dar) # AUFTRAG.GGG.DAT # Erzeugt durch OrgaMon # # dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon-App-Server gelöscht) # baustelle.csv # # # statisch (Dateien werden durch den OrgaMon bereitgestellt/aktualisiert und bleiben bestehen) # GGG.DAT File of MDEREC abgearbeitet.dat (TGpIntegerList) abgezogen.GGG.dat (TgpIntegerList) # Erzeugt (Upload) durch die OrgaMon-App # # dynamisch (Foto-Dateien werden nach dem Verarbeiten durch den OrgaMon-Foto-Server gelöscht) # GGG-RRRRRR-PP.jpg
Verarbeitungsschritte
start
- erstelle das TTTTT Verzeichnis
- prüfe die IMEI und Datum / Uhrzeit des Handy
- erstelle .\web\TTTTT.txt mit allen Infos wer "senden" will als Key=Value, in der Folge wird up.php diese Datei iterativ immer um eine Zeile erweitern, bis das Handy ein "proceed" auslöst
proceed
- Begrifflichkeiten
- Abgearbeitete, sind Auftrags-RIDS die aus OrgaMon Sicht fertig sind und nicht mehr aufs Handy sollen
- Abgezogene, die Auftrags-RIDs die nicht mehr auf dem Handy erscheinen dürfen
- Schritte der Proceed-Funktion
- Geräte Speziefische Optionen laden
- Transaktion Initialisieren (InitTRN)
- lade "abgearbeitet.dat"
- lade "unberuecksichtigt.txt"
- lade "abgezogen.GGG.dat"
- lade "GGG.dat"
- .\web\TTTTT.txt verarbeiten
- die Datei um Zeilen erweitern die nicht aus "senden" stammen, sondern dem schnelleren "melden"
- dabei allerlei Tatsachen beachten: Restanten, Stay-Liste, Abgearbeitet, Abgezogene usw.
- mit "WriteOrgaMon" den OrgaMon über Ergebnisse informieren
- TTTTT.DAT und TTTTT.utf8 wird erstellt
- Zug um Zug das neue Auftragsvolumen erstellen
- AUFTRAG.DAT und auftrag.txt erstellen
Datenabruf
- Der Client lädt die Datei TTTTT.auftrag.utf-8.txt vom .\web\ Verzeichnis
todo
- von dem binären Format des MDEREC komplett verabschieden (immer mit csv arbeiten)