JonDa.Server: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
 
(133 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{|
 
|[[Datei:Virtualbox-Karlsruhe.png]]
* Der JonDaServer ist die "App"-Identität des cOrgaMon.exe
|Die beiden Server-Programme für Win32-Systeme sind die Kommunikations-Partner für die OrgaMon-App. Die Server arbeiten ohne Datenbank und Sychronisieren sich mit OrgaMon über einen gemeinsamen FTP-Ablage Bereich.
* Er betreibt einen XMLRPC Server im Namespace "jonda"
  |}
 
[[Datei:Virtualbox-Karlsruhe.png]]
 
* 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 <b>System</b>)
; 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=<i>Id</i> dieser Sektionswert mitgegeben (default=System)
;
[<i>System</i>]
;
; 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".
;
; <b>=JA</b>
; 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 ===


== AppServer ==
* Der JonDa-Server kann bestimmten Geräten bestimmte Programm-Optionen mitgeben. Dies wird mit <code>OPTIONEN=</code> in der Geräte-Einstellungsdatei gesteuert.


==== a ====


Der AppServer Dienstleistet die Funktionalität hinter dem "senden" für die OrgaMon-App auf den Smartphones. Der Server wird mit GUI für Verwaltungs- und Rechercheaufgaben geliefert (Win32, JonDaServer.exe). Im Regelbetrieb wird die Konsolenanwendung cJonDaServer.exe verwendet, die auch unter Wine einsetzbar ist. JonDaServer arbeitet mit dem Script up.php zusammen.
* KEINE_DOPPELEINGABE_ZAEHLERSTAND_ALT


== ShopServer ==
==== b ====


Ein XMLRPC Dienst der vom Webshop ins Anspruch genommen wird.
* KEINE_DOPPELEINGABE_ZAEHLERNUMMER_NEU


== FotoServer ==
==== c ====  


Dienstleistet
* KEINE_DOPPELEINGABE_ZAEHLERSTAND_NEU


* das Zuordnen der Fotos in die jeweiligen Ablagen
=== Einstellungen ===
* Umbenennen der Fotos nach bestimmen Namensmodellen
* Aufräumen in den Internet-Ablage incl. Wegsichern der Daten


=== Unter Wine ===
* Pro Gerät kann eine .ini Datei angelegt werden, diese Datei steuert individuelle Einstellungen


* Dateiname ist <code><b><3stellige GeräteNummer>.ini</b></code>


#!/bin/bash
  #
  #
  # JonDaServer - wine - Startup Script
  # Ist das Datum/Uhr des Handys falsch einstellt unterbleibt die
# weitere Datenverarbeitung.
#
# <b>JA</b> | NEIN
#
ZEIT_PRÜFUNG=
#
#
#
#
OPTIONEN=
#
# für die Lager-Funktionen muss diese Option auf "JA" gesetzt werden
#
# JA | <code><b>NEIN</b></code>
  #
  #
  sleep 25
  EinfacheListe=
   
   
  export LANG=de_DE.UTF-8
  #
mount //~NAS-Host~/web$ /root/.wine/drive_w --verbose -o guest
# Protokolle befinden sich im Verzeichnis ./dat/Protokolle
  wine "C:\\Program Files\\JonDaServer\\cJonDaServer.exe"
# 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.
#
# <b><Leer></b> | Unterverzeichnis\
#
ProtokollPfad=
 
=== ShopServer ===
 
Ein XMLRPC der vom Webshop in Anspruch genommen wird.
 
=== FotoServer ===
 
[[cOrgaMon.Foto]]
 
== 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


* Offenes Problem: Nutzt wine ein lokales SMB-Share so werden die ("DOS"-) Dateien mit den falschen Rechten angelegt.
[neue-Id]


=== Funktionstest ===
* Merken Sie sich das angegebene Verzeichnis im Wert DatabaseName=, dieses Verzeichnis ist für den nächsten Schritt nötig


* Testcase "http://www.orgamon.com/up.php?info=YP86QPYFK"
=== cOrgaMon.ini im .\dat editieren ===


=== Konfiguration ===
[alte-Id]


<b>Port des XML-RPC Services</b>
* umstellen auf


  Default ist 3049
[neue-Id]


<b>XML-RPC Funktionen</b>
=== systemctl Befehle durchführen ===


  <b>jonda.BasePlug () : array of string;</b> { Infos }
systemctl stop cOrgaMonApp@alte-Id
 
systemctl disable cOrgaMonApp@alte-Id
  // liefert diverse Informations-String:
systemctl stop cOrgaMonFoto@alte-Id
  // 1) Datenbankname (im Moment nicht verfügbar, jonda benötigt im Moment keine Datenbank)
systemctl disable cOrgaMonFoto@alte-Id
  // 2) Jonda - Server Versions-Nummer
 
  // 4) Indy Versions-Nummer
  //


  <b>jonda.StartTAN (GeraetID : string) : string;</b> { TAN }
systemctl enable cOrgaMonApp@neue-Id
 
  systemctl enable cOrgaMonFoto@neue-Id
  // erwartet eine 3 stellige Geräte Identifiktationsnummer wie z.B. 422
  systemctl start cOrgaMonApp@neue-Id
  // Die Funktion holt die passenden Gerätedaten von einem FTP Server
  systemctl start cOrgaMonFoto@neue-Id
  // Ist das Gerät bekannt, so wird eine neue TAN Nummer gezogen, es wird
  // ein entsprechendes Verzeichnis geöffnet, und Upload Daten können
  // gezogen werden.
  // Format: GeraetID;_TAN;VERSION;OPTIONEN;UHR;
  // GeraetID  : z.B. 003
  // _TAN      : bisherige TAN
  // VERSION    : Programmversion z.B. 1.114
  //  OPTIONEN  : 85
  //  UHR        : Datum + Uhr im Format: "26.09.2005 - 07:21:05"


== Neustart unter Linux ==


  <b>jonda.ProceedTAN (TAN : string) : integer;</b> { 0=OK,Ansonsten Fehlercodes }
* 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
  // verarbeitet alle Eingangsdaten und stellt die Ergebnisdateien
* somit ist nach dem Beenden der Prozesse eine Wartezeit einzuplanen
  // im entsprechenden TAN Verzeichnis zur Verfügung.
* 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


<b>von JonDa erwartet php Funktionen:</b>
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
  up.php?id=666;50000;1.011    // GeräteID;LetzteErfolgreicheTAN;Programmversionsnummer
                               // Antwort: liefert im BODY eine neue TAN
                               // Antwort: liefert im BODY eine neue TAN
  up.php?tan=50999&data=part1   // lädt Daten hoch
  up.php?tan=50999&data=part2   // ...
#
  up.php?tan=50999&data=part3   // ...
# 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
  up.php?proceed=50999          // fordert zum verarbeiten auf, liefert "OK" im BODY
up.php?info                  // liefert im BODY die BasePlug-Infos,
                                  zum Test der XMLRPC-Verfügbarkeit


<b>Ablagebereich für das php Script:</b>
=== Diagnose ===


  ./JonDaServer/<TAN>/.


<br>
#
# 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
** <code>001.html ... nnn.html</code>
** <code>ausstehende-details.html</code>
** <code>ausstehende-fotos.html</code>
** <code>geraete.html</code>
** <code>-neu.html</code>
** <code>senden.html</code>
** <code>vertrag.html</code>
* 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


2) Verzeichnis-Replikation via FTP<br>
#!/bin/bash
<br>
ACTARIS erhält über ein html-Dokument auf www.mysewa24.com die aktuelle IP des
#
Linux Workgroup Servers(2) von "Andreas Filsinger, Softwareentwicklung". Mit
# update.sh
Hilfe der IP-Adresse und einer Benutzername/pwd Kombination kann sich ACTARIS(3)
#
via passiven ftp-client auf den ftp-Server-Dienst auf dem ISDN-Server verbinden.
Nun müssen 2 lokale ACTARIS-Verzeichnisse (wiederum IN/OUT) synchronisiert werden.
scp orgamon.net:/etc/letsencrypt/live/orgamon.net/privkey.pem .
Dazu können Standard-Verzeichnis Replikations-Dienste verwendet werden. Man sollte
  scp orgamon.net:/etc/letsencrypt/live/orgamon.net/fullchain.pem .
vorsehen, dass das OrgaMon-Team diesen Replikations-Prozess selbst anstossen kann.
scp orgamon.net:/etc/letsencrypt/live/orgamon.net/cert.pem .
Ansonsten läuft dieser etwa alle 30 Minuten automatisiert.
<br>
3) Kopplung von OrgaMon an IN / OUT<br>
<br>
OrgaMon(4) liesst und beschreibt im Rahmen des Tagesabschlusses oder auf manuelle
Anforderung die beiden Verzeichnisse und bereitet alle Dateien auf. IN und OUT
müssen für alle OrgaMon-Arbeitsplätze sichtbare Verzeichnisse sein.
<br>
4) Ausfall-Konzept
<br>
  Situation: Totalausfall des "filsinger-Servers"
<br>
JonDa-Server wird auf CD-R als installierbares Tool für win32 geliefert. Der Rechner
auf dem installiert wird muss auch eine OrgaMon-Client Installation besitzen. Bei
der SEWA wird ein Handy mit V24-Schnitstelle an diesen Arbeitsplatz gekoppelt.
Den Monteuren wird mitgeteilt, dass der "ALTERNATIV-SERVER" angewählt werden muss
(Das ist ein Menü-Punkt in der JonDa-Software). Der Anruf des Monteur-Handys
landet auf dem Handy bei der SEWA.
<br>
5) Sicherheits-Schlagworte
<br>
* Der Linux-Server besitzt eine Firewall
* Das Filsinger Netzwerk besitzt eine DMZ dem der ISDN-Server zugeordnet ist
* JonDa-Server und OrgaMon benutzen starke Verschlüssellung für alle Dateien in In/Out
  dadurch ist ein abhören im Internet wenig sinnvoll
* Die Anwahlnummern bleiben geheim
* Die Anwahl der MDEs ist durch täglich wechselnde pwds gesichert
* JonDa-Server hat kein bekanntes Sicherheitsloch seit ca. 1991
<br>
wichtige Infos zur Installation unter Windows 2000
<br>
* Die FRITZ! PCI Card Treiber MÜSSEN auf den neuesten Stand gebracht werden. Sonst
gibt es Übertragungsfehler.
* Der CAPI-Port Treiber muss auf custom-Config unter der Verwendung des ersten
nicht physikalischen Ports installiert werden sonst gehts nicht!
<br>
JonDaServer.ini
<br>
  Im [Default]-Bereich werden alle Einstellungen gespeichert, falls der Rechnername
  nicht gefunden wird.


  [Default]
  ComPort=3
  InitString=ATS50=966208;S49=966208;S31=2;S51=0;S35=9600


  Ansonsten muss der Rechnername als Sektionsname in eckige Klammern gesetzt werden.
=== dat ===


  [fred]
==== ./dat/Daten ====
  ComPort=3
 
  InitString=ATS50=966208;S49=966208;S31=2;S51=0
* intern auch "AuftragPath" genannt
  ftppwd=?????
 
  ftpuser=?????
#
<br>
# Haupt- binlager - Tabellen (OrgaMon internes DB-Format aus binlager.pas)
Konzepte und Tatsachen
#
<br>
AUFTRAG+TS.BLA  alle bekannten Aufträge (plus TimeStamp) auf allen Geräten
* heute abgearbeitete Termin bleiben auf dem Gerät
* Man kann mit der Geräte-Nummer "000" anrufen lassen. Dabei wird der
FOTO+TS.BLA      Foto (plus TimeStamp). binäre Tabelle aller bekannten Meldungen an den
aktuellen Bestand des Gerätes gelöscht. Es wird eine leere Auftragsdatei
                  OrgaMon wobei F?= beteiligt war.  
übertragen. Die "alten" Daten, die sich auf dem Gerät befanden sind
zwar auf dem JonDaServer gesichert, werden aber nicht an OrgaMon über-
#
tragen.
# Im Rahmen des Start-Ups von cOrgaMon.exe werden die Tabellen AUFTRAG+TS.BLA und FOTO+TS.BLA
* Man kann Auftragsoptionen in den Server eintragen. Beim nächsten Anruf wird
# von "alten" Datensätzen befreit, Datensätze, die 32 Tage und älter sind, werden in der Tabelle
dann bei passender Gerätenummer diese Option ausgeführt!   
# gelöscht. Die Tabellen werden neu aufgebaut.
<br>
#
Ideen
# Bei jedem Einfügen in die Tabelle wird das Datum aufgezeichnet
<br>
#
ACTIDX.DAT könnte man zumindest auf "1" setzen. Noch besser: erster nach den
Restaten, noch besser
GGG.DAT                file of mderec
<br>
AUFTRAG.GGG.DAT        file of mderec
Lizenz<br>
abgezogen.GGG.DAT      TgpIntegerList (File of RID)
<br>
abgearbeitet.DAT       TgpIntegerList (File of RID)
MPL 1.1 für alle mitgelieferten Sourcen.
unberuecksichtigt.txt  Textdatei, Liste mit TANS die OrgaMon-Desktop noch nicht abgeholt hat?!
Es werden jedoch nicht freie Komponenten verwendet, diese sind nicht Teil der
 
Distribution, können jedoch durch freeware-tools ersetzt werden.
==== ./dat/db ====
tserial4, http://www.rjc.org.uk/sharewar.htm
 
capi2han, http://www.isdn-tools.de
* intern auch "DataPath" genannt
<br>
 
#
# Bei jedem Neustart des App-Servers wird eine Kopie aus ./dat/Daten erstellt
# gezogen, damit sich Foto-Dienste und "proceed" nicht in die Quere kommen
# Diese Datei wird nur durch cOrgaMon.Foto verwendet
#
AUFTRAG+TS.BLA
#
# Wenn sehr alte Bilder ankommen kann auch eine sehr alte AUFTRAG+TS.BLA
# aus einer Sicherung manuell geholt werden, in der Hoffnung dass diese Datei noch
# die alten RIDs gespeichert hat. Dazu das "_" dem Dateinamen voranstellen.
# Diese Datei ist optional.
# Diese Datei wird nur durch cOrgaMon.Foto verwendet
#
_AUFTRAG+TS.BLA
 
#
# GGG ist die Gerätenummer
# eine csv mit folgender Kopfzeile (diese Kopfzeile wird nicht in der .csv gespeichert!)
  # <b>DATUM;UHRZEIT;RID;REGLER_NUMMER_NEU;ZAEHLER_NUMMER_NEU</b>
#
Eingabe.GGG.txt
 
==== ./dat/TTTTT ====
 
* Transaktionsverzeichnise, durchnummeriert von 10000 bis 99999
* jedes "senden" verbraucht eine Transaktions-Nummer und erzeugt ein Unterverzeichnis mit dieser Nummer
* <code>TTTTT</code> ist die Transaktionsnummer
* Verzeichnis .\dat\TTTTT\


== Verzeichnisinhalt einer Transaktion ==
<br>


  GGG.DAT    (vom FTP) Netto-Auftragsvolumen für dieses Gerät, wird frisch vom ftp-Bereich geholt.
  GGG.DAT    (vom FTP) Netto-Auftragsvolumen für dieses Gerät, wird frisch vom ftp-Bereich geholt.
Zeile 196: Zeile 393:
  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 ===
* Verzeichnis .\ftp\, das zentrale Up- Downloadverzeichnis des Servers
# <b><u>Erzeugt durch cOrgaMon.App</u></b>
#
# dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon gelöscht)
#
<i>TTTTT</i>.DAT          Meldungen der OrgaMon-App an OrgaMon (binär)
<i>TTTTT</i>.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.<i>GGG</i>.DAT <i>file of MDEREC</i>*
# <b><u>Erzeugt durch OrgaMon</u></b>
#
# 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)
#
<i>GGG</i>.DAT File of MDEREC
abgearbeitet.dat (TGpIntegerList)
abgezogen.<i>GGG</i>.dat  (TgpIntegerList)
# <b><u>Erzeugt (Upload) durch die OrgaMon-App</u></b>
#
# dynamisch (Foto-Dateien werden nach dem Verarbeiten durch den OrgaMon-Foto-Server  gelöscht)
#
<i>GGG</i>-<i>RRRRRR</i>-<i>PP</i>.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


== JonDaServer (Ausblick) ==
=== Datenabruf ===


der JonDaServer könnte auch in PHP / Python oder in Java (Java-Server Pages Tomcat) implementiert werden. Wichtig ist auch wieder dass durch eine kleine GUI Diagnose-Fragen an das System gestellt werden können. Ev. wird dazu weiter Delphi verwendet. <br>
* Der Client lädt die Datei TTTTT.auftrag.utf-8.txt vom .\web\ Verzeichnis
Einzelprobleme sind hier:


# FTP-Komponente für UP- und DOWN- Load
=== todo ===
# Ev. von dem binären Format des MDEREC verabschieden, sondern immer mit csv arbeiten


Hier eine GUI für Python http://www.tkzinc.org
* von dem binären Format des MDEREC komplett verabschieden  (immer mit csv arbeiten)

Aktuelle Version vom 24. April 2023, 16:19 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\

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

cOrgaMon.Foto

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
  1. up.php zieht eine neue Transaktions-Nummer und erstellt das gleichnamige Verzeichnis
  2. up.php hat Zeile für Zeile Auftragsergebnisse in die Datei [] geschrieben
  3. 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

  • intern auch "AuftragPath" genannt
#
# Haupt- 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

  • intern auch "DataPath" genannt
# 
# Bei jedem Neustart des App-Servers wird eine Kopie aus ./dat/Daten erstellt
# gezogen, damit sich Foto-Dienste und "proceed" nicht in die Quere kommen 
# Diese Datei wird nur durch cOrgaMon.Foto verwendet
#
AUFTRAG+TS.BLA 

#
# Wenn sehr alte Bilder ankommen kann auch eine sehr alte AUFTRAG+TS.BLA
# aus einer Sicherung manuell geholt werden, in der Hoffnung dass diese Datei noch
# die alten RIDs gespeichert hat. Dazu das "_" dem Dateinamen voranstellen.
# Diese Datei ist optional.
# Diese Datei wird nur durch cOrgaMon.Foto verwendet
#
_AUFTRAG+TS.BLA
 
#
# 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
#
Eingabe.GGG.txt

./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 file of MDEREC*

# 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

  1. erstelle das TTTTT Verzeichnis
  2. prüfe die IMEI und Datum / Uhrzeit des Handy
  3. 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
  1. Geräte Speziefische Optionen laden
  2. Transaktion Initialisieren (InitTRN)
    1. lade "abgearbeitet.dat"
    2. lade "unberuecksichtigt.txt"
    3. lade "abgezogen.GGG.dat"
    4. lade "GGG.dat"
  3. .\web\TTTTT.txt verarbeiten
    1. die Datei um Zeilen erweitern die nicht aus "senden" stammen, sondern dem schnelleren "melden"
    2. dabei allerlei Tatsachen beachten: Restanten, Stay-Liste, Abgearbeitet, Abgezogene usw.
  4. mit "WriteOrgaMon" den OrgaMon über Ergebnisse informieren
    1. TTTTT.DAT und TTTTT.utf8 wird erstellt
  5. Zug um Zug das neue Auftragsvolumen erstellen
    1. 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)
Abgerufen von „https://wiki.orgamon.org/index.php?title=JonDa.Server&oldid=32022“