[todo] [Software 0000058]: Domain-Robot Multi-Host-fähig machen

[todo-notifyer at hostsharing.net]

Das folgende Problem wurde geschlossen. 
====================================================================== 
https://todo.hostsharing.net/view.php?id=58 
====================================================================== 
Berichtet von:              mi
Zugewiesen an:              mi
====================================================================== 
Projekt:                    Software
Problem ID:                 58
Kategorie:                  Domain-Skripte
Reproduzierbarkeit:         N/A
Auswirkung:                 Feature-Wunsch
Priorität:                  hoch
Status:                     geschlossen
Lösung:                     erledigt
Erledigt in Version:        
====================================================================== 
Erstellt am:                13.12.2002 18:11 (CET)
Letzte Aktualisierung:      19.08.2006 11:29 (CEST)
====================================================================== 
Zusammenfassung:            Domain-Robot Multi-Host-fähig machen
Beschreibung: 
Der Domain-Robot muss Multi-Host-fähig werden.

Idee dazu: zentrale Original Config für /etc/doms/ und etc/pacs/, auf den
Hosts nur noch als Kopie. Skript wird auf Satelliten-Host gestartet, die
Robot-Meldungen (von InetWire) an den richtigen Host (der die Domain hat)
weitergeleitet.
====================================================================== 

---------------------------------------------------------------------- 
 sm - 13.12.02 20:47  
---------------------------------------------------------------------- 
Ich sehe Multi-Host noch allgemeiner:

Ich würde gerne eine Art Workflow-System aufbauen. Ein Vorgang kann auf
jedem beliebigen Host angestoßen werden.  Dabei kann ein Vorgang aus
mehreren Arbeitsschritten bestehen, die auch auf unterschiedlichen
Rechnern
laufen können.  Die Vorgangsdaten werden mit jedem Arbeitsschritt zur
nächsten Bearbeitungsstation (evtl. lokal) weitergeleitet.

Wesentliches 'Problem' ist der Transportmechanismus.  Bislang halte ich
SAFT für den besten Kandidaten:

http://www.belwue.de/projekte/saft/

Wesentliche Vorteile:
* Asynchrone Auslieferung durch Daemon möglich, d.h. temporäre
  Netzwerkprobleme führen nicht zum Ausfall, sondern nur zur
  Verzögerung (analog Mailauslieferung).
* Empfänger kann beim Eintreffen neuer Nachrichten skriptgesteuert
  darauf reagieren (analog procmail bei Mails).
* Verschlüsselung und Authentifizierung des Absenders über PGP
  integriert. 

---------------------------------------------------------------------- 
 mi - 14.12.02 08:26  
---------------------------------------------------------------------- 
Insbesondere in Fehlersituationen (DNS3 down oder so), wäre ein solches
Workflow-System sehr vorteilhaft. Daher schwebt mir auch schon lange vor,
es so umzubauene.

Aber ich würde das nicht im RAhmen dieses Multi-Host-Umbaus machen, weil
das nicht nur zu lange dauern würde, sondern vor allem wir noch zu viele
Schritte haben, die manuell eingerichtet werden müssen (nicht bei
Einfachst-Paketen, aber bei bestimmten Zusatz-Features). D.h. wir wirden
das Projekt mal eben um den Faktor 100 verkomplizieren.

Daher plädire ich dafür, das in einn separaten Issue ("But") zu packen. 

---------------------------------------------------------------------- 
 mi - 19.08.06 11:29  
---------------------------------------------------------------------- 
der Domain Robot ist schon seit Jahren Multi-Host-fähig 

Problem-Historie 
Änderungsdatum  Benutzername   Feld                     Änderung             
====================================================================== 
19.08.06 11:29  mi             Status                   zugewiesen => erledigt
19.08.06 11:29  mi             Lösung                   offen => erledigt   
19.08.06 11:29  mi             Problemnotiz hinzugefügt: 0001593                
   
19.08.06 11:29  mi             Status                   erledigt => geschlossen
======================================================================