Beiträge von vmk

    Den SSH-Dienst im Rettungssystem stoppen, dann nach /vserver chroot und dann deinen originalen SSH-Dienst starten. Falls dein Debian/Ubuntu rumzickt, dann einfach mal per Hand den Dienst ohne das Runlevel-Skript starten und gucken was passiert.

    Zitat von ubuntu;30553

    Hab schon gedacht Portforwarding mit iptables zu machen, aber dann muss ich jeden einzelnen Port freigeben (und den auch noch finden) :eek:


    Wieviele Ports hat denn so ein Drucker? In der Regel genau 1 Port der regelmäßig benutzt wird (80 oder 631).

    Zitat von 20365;34678

    Eine kurze Erklärung anhand meines vServer Neptun: Ich habe insgesamt 2048 MB Speicher zur Verfügung, von denen mir 1024 als RAM und 1024 als Swap angezeigt werden.


    Wenn ich nun mehr als die 1024 MB die als RAM angezeigt werden verbrauche wird meine VM intern als "Zuviel RAM-Verbrauch" markiert. Sollte die Node auf der mein vServer liegt nun plötzlich zu wenig freien Speicher haben[...]


    Wenn ich mich nicht ganz falsche erinnere, so habe ich hier bei netcup 1GB RAM (in Riegelform) und 1GB RAM (in SSDform) welcher mir jeweils exklusiv zusteht. Annahme: Ich verbrauche 1800MB. Wieso sollte der oomkiller plötzlich aktiv werden? Das Limit ist doch hart bei 2048MB.

    Zitat von Homwer;34602

    Einfach den Orderner /var/lib/mysql ersetzen klappt leider nicht.


    Aus Erfahrung: Funktioniert, aber nur bei gleicher/ähnlicher mySQL-Version sowie einige kritische Konfigurationsparameter müssen genauso wie bei der Backupversion sein.

    Zitat von Gigadoc 2;33671

    was eigentlich passiert wenn der VServer zu viel RAM braucht.


    Nichts oder es läuft der OOM Killer los. Experten lassen sich natürlich bevorzugt den ssh-Daemon killen ;)


    Zitat von Gigadoc 2;33671

    Wenn jetzt ein "Nachbar"-Node aber ebenfalls mal was von dem shared memory abhaben will, was passiert dann mit meinem VServer?


    Du teilst dir mit deinen Nachbarn keinen Speicher. Ihr liegt höchstens auf dem gleichem Speicherriegel. Hierzu kann aber nur netcup selbst eine verbindliche Aussage treffen. Es gibt genug Billighoster, die vServer überbuchen.


    Zitat von Gigadoc 2;33671

    Werden da einfach random Prozesse gekillt, oder bekommt der Kernel irgendwie gesagt dass er jetzt weniger RAM zur Verfügung hat?


    Die Anwendung bekommt keinen neuen Speicher mehr zugewiesen. Stell dir das so vor, als würdest du versuchen eine nicht erreichbare Webseite zu erreichen. Hierbei stürzt weder dein Browser, noch dein Netzwerk, etc ab.


    Zitat von killerbees19;33673

    Meine Vermutung geht eher in diese Richtung: Sobald ein Programm (= irgendeines) weitere Speicherbereiche anfordert, wird die Anforderung vom Kernel zurückgewiesen => Programm stürzt ab


    Wieso sollte ein Programm einfach so abstürzen? Das ist Quatsch, siehe z.B. http://lwn.net/Articles/318294/


    Zitat von Gigadoc 2;33678

    Der Swap sollte nur im Notfall bereitstehen, damit nicht wichtige Prozesse ganz gekillt werden.


    Genau dafür ist swap auch gedacht wenn man ein System richtig plant. Siehe dazu den Parameter swappiness. Der Kernel entscheidet wenig genutzte Speicherbereiche im Gegenzug für mehr Cache für aktive Programme auszubalancieren (vereinfacht gesagt). Mehr dazu unter http://kerneltrap.org/node/3000

    MX-Eintrag passt, postfix ist auch erreichbar aber mittendrin stockt es.


    Und dann passiert nichts mehr. Was steht dazu in den Logfiles?

    1) Was hälst du von Sicherheitsupdates? Dein Dovecot ist von 2008, dein Postfix von 2007. Beide Programme hatten mehrere schlimme Sicherheitslücken (jeweils: "beliebigen Code mit den Rechten des Servers auszufuehren").


    2) Leider verschweigst du dein Domänennamen. Der MX-Record ist richtig gesetzt und du hast >48h gewartet danach?


    3) Für das Versenden/Empfangen von Mails ist bei dir Postfix zuständig. Davon sehe ich aber nur eine einzige Meldung, nämlich das dieser mal gestartet wurde. Idee: Firewall? Klappt den ein 'telnet irgendwas 25' bzw. ein 'telnet localhost 25'? Was sagt 'netstat -lnp|grep 25'?


    4) Welche Version von SysCP benutzt du? Hast du hier vielleicht auch eine knapp 5 Jahre alte Version im Einsatz?

    Lawliet, die Sicherheitslücken sind ca 1 Jahr alt. Aktuell ist ispCP Omega 1.1.0. Im Ticket wird die Lücke so beschrieben:

    Zitat

    A customer must not be able to connect to a database of another customer

    d.h. es sind nichtmal alle Anwender der Software betroffen (bzw. wer kein Webhosting-Anbieter ist, den dürfte die Lücke nicht weiter stören).