Posts by voja

    wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?

    in dem Fall würd einem das Monitoring System mitteilen,

    dass der Server xy nicht erreichbar ist, aber das würd man ohne Agent auch wissen ;)


    Failure by Design?:/

    Ohne Netzwerkverbindung wird aber kein Alarm die Maschine verlassen… Ich habe keinen Zugriff auf das Hostsystem um extern ne Box mit SMS Versand etc. anzuschließen. Sind ja auch Rootserver.


    Immerhin weiß man, dass etwas auf der Maschine nicht stimmt. Aus der Summe der Meldungen kann man dann schon anfangen den Fehler zu suchen. Sollte der Agent abrauchen kriege ich das gemeldet, sollte das Netz abrauchen dito. Und alle anderen Fehler meldet das Monitoring.

    wenn ma am zum monitorenden System was installieren muss,

    um es dann in ein Monitoring "einzuhängen" hat man bereits was falsch gemacht;

    Worin besteht da das Problem? Ein Agent kommt lokal an alle Infos, die über das Netzwerk nicht zugänglich wären. Bei Icinga gibt es einen Check der prüft ob alle Agents verbunden sind. Plus man kann getrenntes Monitoring aufsetzen, dass prüft ob das Monitoring ansich läuft.

    Heute ist gesetzlicher Feiertag in Baden-Württemberg. Daher dürfte es nur den Notfallsupport geben.


    Die IP-Adresse wird unter den Netzwerkeinstellungen im SCP (und nicht im CCP) zugewiesen.

    Ja: Magenta Zuhause Hybrid von der Telekom. Der Tarif ist aber veraltet. Wie die Technik dahinter funktioniert weiß ich nicht, aber es sieht wie eine Art VPN aus.

    Da braucht man aber einen Telekom Router für, oder? Das hätte ich gerne vermieden. Aktuell kriegt man das als Addon zum DSL.

    Hallo zusammen,

    hat jemand von euch aus DE einen Fallback auf LTE, falls der DSL-/Kabelanschluss ausfällt? Falls ja: welcher Tarif kommt zum Einsatz?

    Wenn das Hostsystem weg ist, brauchst du die Route nicht mehr löschen - weil dann ja auch keine Container mehr existieren, die diese Route nutzen könnten ;-)

    Per SSH kannst du auch die erlaubten Kommandos auf jene beiden beschränken. Pubkey dahinter und gut ist.

    Ich habe das jetzt so gelöst: der keepalived managed die Failover IPs nun auf dem VLAN Interface. Jedes Hostsystem hat für IPv4 die Route via VLAN Bridge gesetzt. Für IPv6 hängen die mit einer IP im Failover Netz. Damit gibt es nur statische Routen.

    Wenn das Hostsystem weg ist, brauchst du die Route nicht mehr löschen - weil dann ja auch keine Container mehr existieren, die diese Route nutzen könnten ;-)

    Per SSH kannst du auch die erlaubten Kommandos auf jene beiden beschränken. Pubkey dahinter und gut ist.

    War falsch ausgedrückt von mir. Das SSH Kommando kann warum auch immer fehlschlagen und dann kann dieses Problem nicht vom Monitoring festgelegt werden, wenn die Route nicht passt. Das ist mir zu wackelig.

    Hosts & Container - einfacher wäre aber über SSH ein ip r d und ip r a an den entsprechenden Host zu senden.

    SSH finde ich an der Stelle heikel. Einmal wegen der Sicherheit und einmal für den Fall, wenn das SSH Kommando fehlschlägt, weil ein Hostsystem weg ist.


    Ich werde mir nochmal durch den Kopf gehen lassen, ob ich das über das VLAN abgebildet bekomme.

    Du kannst ja in deinem Syncprogramm (Corosync / pacemaker) ein ip route delete feuern - oder OSPF verwenden.

    Ich habe keepalived direkt im Container laufen, die kommunizieren über ein VLAN.


    OSPF würde dann zwischen Host und Container laufen?

    Hat jemand schonmal eine Failover IP in einem Container verwendet? Ich habe gerade das Problem, dass die Hostsysteme die Route für die Failover IP zum nicht mehr aktiven Container „vergessen“ müssen, damit alle anderen Container auf die Failover IP zugreifen können.


    Spontan fällt mir da nur ein das mit BGP zu lösen, das klingt aber nach Overkill.

    Ich denke nicht, dass es problemlos geht, von Jessie direkt auf Buster upzudaten. Die Distributionen werden wenn überhaupt nur das Upgrade zur nächsten Major Version testen und unterstützen.


    Der Weg wäre also Jessie -> Stretch -> Buster. Bei Debian empfehle ich jeweils das Studium der Upgrade Anleitung. Ich habe die einmal nicht gelesen und bin prompt in ein dort behandeltes Problem gelaufen. Es lohnt sich also die zu lesen.


    Ich mache vorher immer ein komplettes Backup, aus dem ich im Zweifelsfall das alte System wiederherstellen kann. Ich musste schonmal ein Upgrade verwerfen und von vorne anfangen.

    Bzgl. Spritverbrauch kann ich bei unserem Auto keine Zahlen mehr nennen. Inzwischen haben wir unser Fahrverhalten komplett umgekrempelt und ich rechne nicht mehr nach. Wir sind von der Stadt aufs Land gezogen. Mit Corona Homeoffice war dann eh kaum Autofahren angesagt.


    Unser Auto soll auch mit E10 kompatibel sein. Habs aber noch nie probiert, weil man für E10 nicht wirklich weniger zahlt. Und da greift dann bei mir wieder, dass ich die Herstellung von dem Bioethanol nicht befürworte aus den oben genannten Gründen.

    • Bei E10 ist der Spritverbrauch höher.
    • Die Leitungen können durch E10 früher kaputt gehen.
    • Das tolle Ethanol kommt teilweise aus klimaschädlichem Anbau oder von ehemaligen landwirtschaftlichen Flächen für Nahrungsanbau.


    So zumindest meine Vorurteile. 😉