Beiträge von White

    Also bei mir gibt es Neuigkeiten, der Support hat mittlerweile meinem vServer eine andere MAC Adresse gegeben --> ohne Änderung.

    Auch wurde der Gast nochmals auf einen anderen Host verschoben --> ohne Änderung.

    Heute Abend bekommt die Kiste eine andere IP Adresse weil der Support unter der IP Adresse selbst Tests machen will und dafür mein Produktivsystem nicht immer wieder stören will. Ich hoffe mal dass der Fehler sich dann für mich gelöst hat, bin aber natürlich weiterhin sehr interessiert daran die Fehlerursache zu erfahren.

    Ja.

    Okay richte ich ein. Mir fehlt aktuell für gw02 eine Ip Adresse wenn ich von turn.mennoniten-dresden.de gw02.netcup.net anpinge bekomme als IP Adresse die

    37.120.191.254 zurück aber keine ICMP Responses.


    Edit: also habe es eingerichtet läuft hier: https://smokeping.crazyideas.de noch ohne gw02 aber auch hier sieht man sehr schön dass alle Hosts ohne Probleme erreichbar sind. Nur der eine Server macht Probleme. Ich kann auch noch auf dem Problemhost das ganze einrichten.

    Ich schicke jetzt den Support mal den Link zu dem Thread hier.

    Ich habe jetzt mal die Nameserver geändert, mal sehen was es bringt. Das der Server aber 1.1.1.1 nicht erreichen kann (per ping -O 1.1.1.1 geprüft) spricht ja dagegen dass es allein daran liegt. Stabile Namensauflösung ist ja trotzdem nicht verkehrt ;)


    Ja sry dass ich auf die Hostnames pinge hätte ich erwähnen sollen. Dem Support ist es aber bekannt, die haben zuerst Konsolenausgaben geschickt bekommen inklusive Befehl und später auch das Script was per Ping prüft ob der Host da ist und das ganze in eine Datei loggt.

    Hier die mtr logs.

    Dabei war Server A im Rescue System.

    Server B zu A (A im REscue System): https://pastebin.com/P0RVsa33


    und hier Server A zu Server B (A läuft im Rescue System): https://pastebin.com/J8fNKhXk


    Das die eingetragenen Nameserver Probleme machen könnte ja doch maximal bei den Pings von A zu B sein (ich pinge ja hostnames, keine Ip-Adressen) aber wenn B zu A pingt sollte es ja egal sein ob A eine funktionierende Namensauflösung hat oder?

    https://pastebin.com/P0RVsa33

    Hallo in die Runde,


    ich bin mit mehreren Servern Kunde bei Netcup und auch ein Verein den ich betreue hat einen Teil seiner Server bei Netcup und genau bei einem Server habe ich nun seit mehreren Wochen das Problem dass der Server immer wieder nicht erreichbar ist. Das äußert sich dann darin das die Anwender keine E-Mails versenden können (Thunderbird meldet dass es den SMTP Server nicht erreichen kann) sowie der Nextcloud Client offline ist. Am Anfang habe ich natürlich gedacht "okay temporäre Routingprobleme an meinem DSL Anschluss". Aber nach und nach habe ich immer wieder Meldungen von Anwendern bekommen dass sie ebenfalls keinen Zugriff haben. Also habe ich ich mich an den Support gewendet und mein Problem geschildert. Ich wurde gebeten das ganze im Recovery-System mithilfe von Pings nachzuweisen. Daraufhin habe ich den Server (ich nennen ihn ab jetzt A) ins Recovery gebootet und ihn von extern (Server B, ebenfalls bei Netcup gehört dem selben Kundenaccount) angepingt und das Logfile davon gesichert. Auch habe ich von A aus verschiedene andere Ziele angepingt z.b. 8.8.8.8 und 1.1.1.1. Dabei ist mir aufgefallen dass der der Server A teilweise 1.1.1.1 nicht anpingen kann aber in der Zeit ohne Probleme 8.8.8.8 erreicht. Die Infos und entsprechenden Logs habe ich dem Support zur Verfügung gestellt.


    Einen Tag später habe ich dann die Antwort vom Support bekommen dass sie den Server selber ins Recovery booten müssen um den Fehler nachvollziehen zu können. Dem habe ich zugestimmt mit der Ansage dass der Server bitte nicht tagsüber ins Recovery gehen soll sondern Abends. Nun gut "Abends" wurde vom Support als 17:00 Uhr gedeutet und die Kiste war mal 5-10 Minuten im Recovery.

    Ich habe daraufhin die Antwort bekommen "Problem tritt im Recovery nicht auf, liegt also am Kundensystem". Das ich vorher Logfiles angefertig habe die das genaue Gegenteil beweisen war egal. Daraufhin habe ich dem Support nochmals geschrieben und erklärt dass der Fehler ja auch nicht "ständig" auftritt. Es kann auch mal 1-3 Stunden dauern bis der Server dann für ein zwei Minuten seinen Schluckauf hat.


    Ich wurde gebeten das ganze nochmals gebeten das ganze per Pings im Rescue-System zu dokumentieren --> habe ich getan und zwar über eine ganze Nacht. Server A hat B angepingt sowie diverse andere Server. Und hat in der Nacht zu mehreren Servern wiederholt Verbindungsprobleme. Server B hat ebenfalls die selben Server wie A angepingt und konnte die anderen Server die ganze Zeit ohne Probleme erreichen nur A war immer wieder nicht erreichbar.


    Dieses Log habe ich dann wieder an den Support geschickt mit der bitte um weitere Prüfung. Daraufhin habe ich nur die Antwort zurück bekommen dass sie mit den Pings ja nichts anfangen können ich müsse schon "mtr" nutzen. Da frage ich mich: Wieso wird nicht direkt genau mitgeteilt welche Art von Log gebraucht wird.


    Aber gut ich habe meinen Ärger über die schlechte Kommunikation runter geschluckt und habe den Server wieder eine Nacht im Recovery verbringen lassen mit den jeweiligen gegenseitigen Pings mit mtr.

    Auch das Log habe ich zur Verfügung gestellt nur um dann die Meldung zu bekommen dass sie das System ins Recovery schalten müssen um den Fehler zu untersuchen, (zu dem Zeitpunkt ist ja nun eindeutig klar dass es nicht an meiner Installation liegt, da der Fehler nun mehrfach im Recovery auf Logfile protokolliert wurde.)

    Deswegen habe ich mir auch erlaubt in der Antwort an den Support zu fragen ob es nicht auch im normalen System geht und meine Handynummer hinterlassen um das ganze kurz telefonisch klären zu können, leider rief niemand an. Stattdessen habe ich die Antwort bekommen wenn sie das System nicht ins Recovery booten können dann können sie mir nicht helfen. Zähneknirschend habe ich also zugestimmt dass der Server zu normaler Tageszeit ins Recovery gebootet werden darf. Daraufhin ist mehrere Tage nichts passiert und nach meinem heutigen Anruf meldete sich der Techniker per Mail dass sie keine Störungen feststellen können (und der Server wurde nicht ins Recovery gebootet). Ich sehe aber weiterhin die Aussetzer (mittlerweile läuft auf B ein dauerhaftes mtr in Richtung A und ich bekomme auch immer wieder Nachts eine E-Mail das das Backup nicht erstellt werden konnte weil Server C nicht erreicht werden kann. ("remote: ssh: Could not resolve hostname Server_C.tld: Temporary failure in name resolution").

    Auf den Backupserver backupen jede Nacht noch mehrere weitere Server ohne Probleme.



    Ich habe hier nun mehrere Fragen an euch:
    - Gibt es jemanden der die selben Verbindungsprobleme hatte und der weiß wie es gelöst wurde?

    - Gibt es eine Möglichkeit mit dem Support auf direkteren Weg zu kommunizieren? Ich schließe nicht aus dass hier einfach nur ein Kommunikationsfehler vorliegt den man durch ein kurzes Telefonat ausräumen kann.


    Ich bin auf eure Meinungen und Erfahrungen gespannt.


    netcup versteht mich nicht falsch, ich bin seit vielen Jahren treuer Kunde von euch und habe auch mehreren Leuten empfohlen bei euch Produkte zu holen, gefühlt hat aber der Support über die Jahre sich massiv verschlechtert.


    Grüße White

    Hallo zusammen,


    ein Server der im Zeitfenster von 15 bis 17 Uhr ist war nach knapp 20 Minuten wieder oben, bekommt nun aber keine IP-Adresse.

    Support sagt das Problem ist bekannt.


    Ein anderer Server sollte heute in der Zeit 10:20 - 12:20 rebootet werden zeigt mir bis jetzt aber eine Uptime von 16 Stunden an. Kann es sein dass der Server eher als in der Mail angegeben war neu gestartet wurde? Ich habe zumindest den Reboot nicht ausgelöst.

    Zitat von Xot;21018

    Von der GUI her sieht mir das nach einem JAVA-Programm aus. Da alle Java-Programme in einer gesonderten virtuellen Maschine laufen, sollte sie eigentlich keinen wirklichen Schaden anrichten können.


    Falsch. Ein lokales Javaprogramm hat die selben Rechte wie jedes andere Programm was der Nutzer ausführt. Das was du meinst sind Java-Applets. Die haben standardmäßig nur stark eingeschränkte Rechte. Wenn man jedoch das Zertifikat eines signierten Applets abnickt hat das dann die selben Rechte wie ein lokal laufendes Programm