CareTaker

CareTaker

• Ab März 2019: Aufgrund der Datenschutzgrundverordnung wurde die Cartaker-Domain abgeschaltet. Jeglicher Caretaker-Programmcode wurde aus dem OrgaMon mit der Rev. 8.401 oder besser entfernt.

• CareTaker war ein System das Funktionen des OrgaMon überprüft, und auf Störugen aufmerksam machen kann bevor Kunden diese bemerken. Dazu sendete der OrgaMon verschlüsselt aufgelaufenen Fehlermeldungen an caretaker.orgamon.net.

Dort war auch die zentrale Stelle an die Fehlerzustände gemeldet wurden. Insbesondere kritische Module (eCommerce) meldeten Exceptions an den Caretaker.

• Ab sofort ist jeder selbst für die einwandfreie Funktion aller Teilsysteme verantwortlich

Ein Server im InterNet nimmt Log-Events von verteilten Anwendungen entgegen. Der Dienst wird auch selbst aktiv indem er Trouble Tickets vergibt, und einer Problemsache mit Fristen nachgeht. Durch eine Watchdog on demand Funktion müssen "open" - Logs rechtzeitig durch "close" - Logs abgemeldet werden, ansonsten entsteht ein Trouble Ticket. Durch eine Auto Watchdog Funktion wird ständige Kontrolle diverse Systeme vorgenommen. Projekt-Admins können TCareTaker Events mit eMail-Notifikations verknüpfen. Des weiteren können html-Templates entsprechend dem Zustand von Systemen (ONLINE,OFFLINE) ins Web gestellt werden.

• Verschlüsselte Übertragung der Log-Anfragen

der Log-String wird in 3 Stufen umgesetzt

Stufe 1: die Webanfrage wird BlowFish verschlüsselt, der Key ist OrgaMon bekannt<bt> Stufe 2: base64 Kodierung des "rauschen" Stufe 3: RFC 1738 konformes umkodierung Stufe 4: Es wird nun über Web übertragen Stufe 5: der Log-Event wird auf dem Server in einer firebird Datenbank abgelegt (im Moment noch Standard Log-Files!)

Begriffe

WatchDog

Zeitgesteuertes System, das aktiv nach vorgebbaren Zeitabschnitten aktiv wird. Durch WatchDogs lassen sich "Zusage" oder "Wiedervorlage" Fristen überprüfen und deren Einhaltung testen. Implemetierung via cron-jobs, als "brwoser" wird lynx verwendet. lynx -dump -mime_header ...

Zusage

Bei einem "Watchdog on demand" Antrag eines Client gibt er eine Zeitangabe mit "Zusage" die Festlegt, wie lange der WatchDog ruhig bleiben soll. Erfolgt in diesem Zeitraum keine Abmeldung des Watchdogs schlägt dieser Alarm. (für Tagesabschluss, Tagwache) Beispiel: Nach Tagesabschluss start muss innerhalb 6 Stunden der Tagesabschluss Ende kommen.

Wiedervorlage

Trouble Ticket Vorgänge müssen von Menschen als erledigt gebucht werden, ansonsten erzeugt ein Trouble Ticket Vorgang nach dem Wiedervorlage-Zeitraum wiederum ein kritsches Event.

SysLog

Durch den SysLog Dienst lassen sich kritische Zustände loggen. (für fehler beim Tagesabschluss)

Trouble Ticket

positive int64 Ganzzahl.

• Als kritisch eingestufte Log - Events haben die Erzeugung eines Trouble-Tickets zur Folge. Zusammen mit dem Ticket entwirft TCareTaker einen Fahrplan zur Behebung der Störung.
• "Watch on demand" Antragsteller erhalten auch ein Trouble-Ticket, das erst nach Ablauf der

Wartestellungsfrist in einen Fahrplan umgestellt wird.

Brisanz-Klassen

Sind Gruppen von eMail-Adresse. Der Brisanz-Admin kann Einträge in diese eMail Listen machen.

Abmelden

Durch Abmelden einer Störung wird diese behoben und die Benachrichtigungs-Logik kann deaktviert werden. (Einfach Eingabe des Trouble-Tickets in einem admin bereich).

Funktionssicherstellung

Mit der Funktionssicherstellung kann der OrgaMon bestimmte Testszenarien abarbeiten. Das daraus resultierende Ergebnis wird mit einem Soll-Ergebnis verglichen. Ergebnis und Soll-Ergebnis muss dabei in Dateiform abgelegt werden. Bei Unterschieden ist der Test gescheitert.

Der Sinn liegt darin Regressionen zu vermeiden. Nach Änderungen in einem bestimmten Kontext muss bewiesenm werden, dass "alte" Funktionalität erhalten bleibt. Gibt es hier Abweischungen, so dann man entweder den Bug fixen oder das neuere Test-Ergebnis als "auch richtig" oder "nunmehr richtig" speichern.

Im Moment gibt es verschiedene Bereiche in denen Selbst-Tests definiert werden können.

*.*
Testname.Testdomäne

*.html-add
#
# führt also alle Tests in der Testdomäne "html-add" aus
#

Foto-Server

• Um die Umbenennung eines einzelnen RIDs zu testen muss man folgendes tun

1. baustelle.csv erstellen und nach ./ftp
2. Fotobenennung-BAUST.csv und FotoParameter-BAUST.ini nach ./ftp
3. das Auftragvolmen des Monteurs GGG.DAT erstellen und nach ./db/daten/ kopieren
4. das Einstiegsverzeichnis für die Internet-Ablagen setzen in ./dat/db/Ablagen.csv
5. die hereinkommende Foto-Datei nach ./ftp kopieren
6. Foto->Mandant wählen->Init(das Impilziert auch "sync")->Work jpg

Ticket Arten

1. BestellungNunVollstaendigLieferbar
2. BestellungNunTeilweiseLieferbar
3. BestellungMerkmalTeilweiseLieferbarVerloren
4. WareEingetroffen
5. LagerPlatzZugeteilt
6. LagerPlatzFreigabe
7. BelegScan
8. Miniscore
9. WareRausgegangen
10. WareBestellt
11. ZahlungPerLastschrift
12. ForderungsAusgleich
13. KatalogVersendung

Host Dienste

Putty Login

#
# Das ssh-Login-Passwort
#
Password=

#
# (optional) Login als "anderer" Benutzer
# default=root
#
Login=  

# 
# (optional) Beim Login einen anderen Host oder einen anderen Port benutzen
#            Der Default Port ist 22
#            ssh-host=[host][":" Port]
#            default=~Host~
#
# Beispiele
#
# // anderer Host 
# ssh-host=host.dyndns.org
#
# // anderer Port
# ssh-host=:234
# 
# // anderer Host UND Port
# ssh-host=buddy.dyndns.org:23
#
ssh-host=

System aufwecken

MAC=

VNC Fernsteuerung

 # default, es wird der in der Datenbank-Tabelle angegebene Host benutzt
 vnc-host=

 # es wird VNC Port (5900+)3 angesteuert
 vnc-host=:3
 
 # ein anderer Host (Alias) wird benutzt
 vnc-host=paris
 
 # anderer Host + anderer Port
 vnc-host=paris:16

 # Pflichtfeld, vnc-Passwort
 vnc=

Firebird Server Version abfragen

# host (optional)
# 
# Name des Datenbank-Servers
#
host=

#
# Passwort des Datenbank-Users "SYSDBA"
#
SYSDBA=<SYSDBA-Passwort>