Keepcon.todo: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
* Umstellung auf "ifup" "ifdown" und "ifstatus" - nicht mehr cinternet, das dies nicht mehr Unterstützt wird.
* wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
* wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
* automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten
* automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten ISDN noch nicht getraut.)
  ISDN noch nicht getraut.)
* Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein. Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
* Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein.
* Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene) Interfaces in einer firewall angeben.
  Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over
* Ein unnötiges rumgepinge ist eigentlich nicht notwendig. Erkennt keepcon traffic (in beiden Richtungen auf der Leitung) diff innerhalb der letzten z.B. 6 min ist ein ping zwecks "simuliertem Traffic" nicht notwendig.
  Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
* critical "sites" sollten angebbar sein! Bei Fail -> providerwechsel, im neuen provider auch fail -> fallback auf den main-Provider -> PANIC
* Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall
  geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene)
  Interfaces in einer firewall angeben.
* Ein unnötiges rumgepinge ist eigentlich nicht notwendig. Erkennt keepcon traffic
  (in beiden Richtungen auf der Leitung) diff innerhalb der letzten z.B. 6 min
  ist ein ping zwecks "simuliertem Traffic" nicht notwendig.
* critical "sites" sollten angebbar sein! Bei Fail -> providerwechsel, im neuen
  provider auch fail -> fallback auf den main-Provider -> PANIC
* critical "ftp" sollten angebbar sein!
* critical "ftp" sollten angebbar sein!
* !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface.
* !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface. Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen sind.
  Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflo
* Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic innerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der Regel weniger schmerzlich als der im vollen Last-Betrieb.
  ssen sind.
* Freiwillige Trennung z.B. zwischen 2 und 3 Uhr (einmalig) bei ruhigem traffic! Dies könnte eine Zwandtrennung innerhalb der Geschäftszeiten verhindern!
* Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein
* Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt?
  freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic
* Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg" oder eine "Fehlermeldung" liefern.
  inerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der
* Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http: Es brauchen nicht unnötige Geheimnisse weitergegeben werden.
  Regel weniger schmerzlich als der im vollen Last-Betrieb.
* im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden können. Wie kann man jedoch elegant eine Interprozesskommunikation programmieren, die durch ein Script schon verwendbar ist?
  o Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt?
* "C" connect: Es sollte wirklich erst zurückführen, wenn auch die zugeteilte IP-Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
* Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen
* einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt.  
  sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg"
Ev. auch die Konfiguration über diesen Server ermöglichen.
  oder eine "Fehlermeldung" liefern.
* Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http:
  Es brauchen nicht unnötig Geheimnisse weitergegeben werden.
* im ip-down (z.B. ausgelöst durch eine Zwangstrennung) ein Signal an keepcon
  schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden
  können. Wie kann man jedoch elegant eine Interprozesskommunikation
  programmieren, die durch ein Script schon verwendbar ist?
* "C" connect: Es sollte wirklich erst zurückkehren, wenn auch die zugeteilte IP-
  Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
* einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev.
  auch die Konfiguration über diesen Server ermöglichen.

Aktuelle Version vom 8. November 2017, 10:28 Uhr

  • Umstellung auf "ifup" "ifdown" und "ifstatus" - nicht mehr cinternet, das dies nicht mehr Unterstützt wird.
  • wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
  • automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten ISDN noch nicht getraut.)
  • Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein. Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
  • Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene) Interfaces in einer firewall angeben.
  • Ein unnötiges rumgepinge ist eigentlich nicht notwendig. Erkennt keepcon traffic (in beiden Richtungen auf der Leitung) diff innerhalb der letzten z.B. 6 min ist ein ping zwecks "simuliertem Traffic" nicht notwendig.
  • critical "sites" sollten angebbar sein! Bei Fail -> providerwechsel, im neuen provider auch fail -> fallback auf den main-Provider -> PANIC
  • critical "ftp" sollten angebbar sein!
  • !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface. Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen sind.
  • Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic innerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der Regel weniger schmerzlich als der im vollen Last-Betrieb.
  • Freiwillige Trennung z.B. zwischen 2 und 3 Uhr (einmalig) bei ruhigem traffic! Dies könnte eine Zwandtrennung innerhalb der Geschäftszeiten verhindern!
  • Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt?
  • Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg" oder eine "Fehlermeldung" liefern.
  • Weak-Remote (hhtp-get dazu notwendig) ->wget. Nicht via ftp, sondern http: Es brauchen nicht unnötige Geheimnisse weitergegeben werden.
  • im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden können. Wie kann man jedoch elegant eine Interprozesskommunikation programmieren, die durch ein Script schon verwendbar ist?
  • "C" connect: Es sollte wirklich erst zurückführen, wenn auch die zugeteilte IP-Adresse stabil ermittelt ist (Bei ISDN habe ich schon 127.0.0.1 oder so gesehen).
  • einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt.

Ev. auch die Konfiguration über diesen Server ermöglichen.