Beiträge von [netcup] Alex W.

    Code
    my_ip=$(ifconfig eth0 | head -n2 | tail -n1 | cut -d: -f2 | cut -d" " -f1)
    my_ip_o1=$(echo ${my_ip} | cut -d"." -f1)
    my_ip_o2=$(echo ${my_ip} | cut -d"." -f2)
    my_ip_o3=$(echo ${my_ip} | cut -d"." -f3)
    my_ip_o4=$(echo ${my_ip} | cut -d"." -f4)
    Bash
    #!/bin/bash
    my_ip=$(ifconfig eth0 | head -n2 | tail -n1 | cut -d: -f2 | cut -d" " -f1)
    check_ip="88.12.45.32"
    if [ $check_ip -eq $my_ip ]; then
        echo "Gleiche Adresse."
    else
        echo "Nicht gleiche Adresse."
    fi

    Ein grep auf "inet Adresse" würde ich meiden da dies bei anderen gesetzten locales nicht mehr funktionieren wird ;)

    Wir haben es nun nach weiteren Überlegungen wie folgt ausgelegt.

    Die Security Mirror haben wir nun zumindest in der sources.list bei Debian belassen da dies explizit offizielle Mirror und direkte Anlaufstellen sind, auch wenn unserer Mirror exakt abgeglichen werden. Unsere Mirror wurden hier gestern auch nochmal entsprechend optimiert und erweitert.

    Für Wheezy sind die Mirror ebenfalls bereits ausgelegt.

    Von Fragen zu einem Wheezy Image bitten wir noch abzusehen ;) Dies wird natürlich kommen, wenn es soweit ist.

    Bitte enschuldigen Sie die etwas späte Antwort auf das Thema. Zunächst mal liegt es natürlich auch in unserem Interesse das die Security Mirror mit verwendet werden. Es gab lediglich ein Image wo diese nicht von Haus aus enthalten waren, wir haben noch einmal alle Images ausgiebig geprüft. In dem Image Debian Squeeze minimal 64bit sind die Security Mirror nun auch enthalten bzw. die Mirror List vervollständigt.

    Dies ist auf bestehende vServer natürlich nicht anwendbar, hier muss, wie generell bei einem vServer, der Administrator des Systems tätig werden.

    Wir empfehlen dabei mindestens folgende sources.list

    Unter Netcup VServer Control Panel – netcup Wiki (Informationen) wird jedoch darauf hingewiesen das dies eine Status-Anzeige, keine Fehlermeldung ist. Die "rote Box" besagt viel mehr das es sich um kritische Informationen handelt, dies werden wir im Wiki noch ausbessern / besser erwähnen.

    Wenn einer der Gameserver nicht stabil funktioniert und dort ggf. auch Plugins / Erweiterungen verwendet werden, kann dies schon eine Ursache sein. Auch ist es durchaus normal das ein vServer mit einem Webserver und 2 Gameservern beim Start viel RAM verbrauchen kann.

    Beispiel: In einem kürzlichen Test mit einem anderen Gameserver (ich nenn den Namen jetzt bewusst nicht), verbraucht dieser im laufenden Betrieb ca. 400-600MB RAM. Beim Start, wo viel Informationen initialisiert werden wie dies bei Gameservern durch die Bank weg geschieht, verbraucht der Prozess beinahe das 10fache an Arbeitsspeicher.

    Das ist keine Fehlermeldung. Ihr vServer verbraucht offenbar beim Start kurrzeitig einmal alle verfügbaren garantierten Ressourcen wozu es zu besagter Meldung im VCP kommt. Wenn Sie beim Systemstart z.B. einen Webserver, Datenbankserver und mehrere Gameserver starten lassen, ist dies nicht verwunderlich.

    Hierzu einfach bitte an den Support wenden welche Domain Sie wo haben möchten.

    Beachten Sie jedoch, das Inklusivdomains vertraglich immer an den entsprechenden Tarif gebunden bleiben, unabhängig davon, ob die Domain in einem anderen Tarif angelegt wird um diese dort nutzen zu können.

    Ggf. im Confixx unter httpd_Spezial die Error Logs aktivieren und die Seite erneut aufrufen damit der Fehler in die Error Log (für Sie einsehbar per FTP unter /log/) geschrieben wird.

    Bei einer weissen Seite und dem Vorgang eines WBB Updates, kann man davon ausgehen das es am PHP Memory Limit liegt. Dies ist bei WoltLab allerdings bekannt, verwunderlich wieso man Sie nicht darauf hingewiesen hat. Das WBB hat bei einem größeren Update wie z.B. lite2 -> WBB3 einen massiven Verbrauch bezüglich des Memory Limit, teilweise ist es notwendig 128MB zu aktivieren damit ein Update erfolgreich verlaufen kann.

    Bei einem Upgrade wird alles übernommen, auch bestehende Domains natürlich. Inwiefern ein Upgrade auf dem bestehenden Server möglich ist, oder ob wir einen neuen Account auf einem anderen Server bereit stellen müssen, wird dabei jedesmal individuell geprüft durch den Support.

    Daher bitte am besten beim Support anfragen damit wir Ihnen die Details entsprechend Ihrem Account mitteilen können.

    Bei de Transfers geht es immer sehr schnell, insofern, das gilt aber überall, der AuthCode gültig ist und kein, wenn möglich (je nach TLD), Transfer-Lock gesetzt ist.
    Die ICANN behält sich eine Bearbeitungszeit von bis zu 7 Tage vor für einen Transfer, auch nach erfolgreichem Transfer-OK, darauf haben wir leider keinen Einfluss. Es gibt vereinzelte Domainendungen wo es sogar 12-14 Tage sind.

    Länger als 3 Tage dauert ein Transfer, in der Regel (das heisst nicht generell), jedoch nicht. Ggf. einfach mal den Support anstubsen was der Status des Transfers ist ;) Wir schauen dann gerne nach.

    Oftmals hakt es an der FOA Mail / Bestätigung, siehe dazu auch Domaintransfer – netcup Wiki

    Da hies es aber immer wir seien zu dämlich ;)

    So haben wir dies weder gesagt, geschrieben noch mit unseren Aussagen gemeint. Es ist nun mal unbestritten oftmals so, das man vielleicht was vergessen hat in seiner Konfiguration oder sich andere Fehler wie z.B. sehr oft Kompatiblitätsprobleme einschleichen. Da wir tagtäglich Anfragen dieser Art (nicht unbedingt exakt solche) bearbeiten, haben wir natürlich ein gewisses Gefühl für gewisse Fehler. Wir müssen hierbei auch um Verständnis bitten das wir nicht jeden Fehler so explizit tiefgründig prüfen können wie mancher sich dies ggf. wünscht. Desto detaillierter Fehler gemeldet werden, z.B. mit Vorgehensweise, Log-Auszügen, exakten Fehlermeldungen etc. desto eher ist es für uns möglich genauere Rückschlüsse zu ziehen, Probleme zu analysieren und ggf. zu reproduzieren.

    Naja, es ist ein seltenes Problem, wenn man hier wieder liest "ispCP ist auf den vServern der VP Reihe entsprechend der Anleitung im Wiki lauffähig",

    Das Problem trat, soweit uns bekannt ist, bisher genau 3x auf. Einmal bei internen Tests (einer von hunderten in Sachen ispCP) wo wir uns dies selbst nicht erklären konnten und wo auch der Hersteller von ispCP keinen Rat mehr wusste, trotz eingehender Prüfung, und 2x bei Kunden. Einmal ebenfalls auf unerklärliche Weise und nun bei dem Kunden kraZey. In allen 3 Fällen konnte trotz weitreichender Versuche und Tests das Problem nicht lokalisiert werden. Die Anleitung im Wiki ist richtig und funktioniert auch, dies ist unumstritten. Wenn jedoch ein sehr spezielles Problem besteht, helfen natürlich keine normalen Anleitungen. Auf diese jedoch zu verweisen, sollte man uns auch nicht vorwerfen denke ich.

    Allgemein ist dieses "Phänomen" wohl noch ungeklärt,

    So sieht es wohl leider aus, da ja selbst der Hersteller keinerlei Ansatz hatte woher dies kommen kann.

    Ich hätte auch gerne mal gewusst wie es denn aussehen würde wenn Netcup dieses Problem dann selbst feststellt wenn der Nutzer dieses Angebot wahr genommen hätte,

    Wenn jemand ein solches Angebot annimmt, wir das Problem dann tatsächlich auf gleiche Art nachvollziehen können, wird dem Kunden natürlich kein Vorgang berechnet, bzw. falls bereits eine Abrechnung statt fand, die Kosten des Angebots erstattet (hier sind remote Hands Services für die Installation gemeint, nicht die Grundkosten des vServers).


    Sollte sich jemand persönlich angegriffen gefühlt haben so möchte ich mich an dieser Stelle, ggf. auch für Kollegen, natürlich entschuldigen. Dies war und ist natürlich keineswegs unsere Absicht. Auch habe ich das erneute Thema zum Anlass genommen ispCP nochmal weitreichender zu testen und "kaputt zu machen was geht" um diesen Fehler irgendwie reproduzieren zu können, leider hat es bisher jedoch in allen weiteren Tests funktioniert. Wir werden dies aber natürlich auch weiterhin beobachten und auch ggf. Rücksprachen mit dem Hersteller der Software halten. Uns liegt nichts ferner als Probleme "immer nur" auf Kunden abzuwälzen. Wenn dies so vernommen worden sein sollte, so möchte ich mich auch hierfür aufrichtig entschuldigen.