Beiträge von [netcup] Felix P.

    Hmm, nett. In der aktuellen c't kompakt Linux, werden wir als Anbieter für Server auf Basis von Linux-VServer genannt. Wem es interessiert, der kann im nächsten Kiosk mal Seite 64 der besagten Zeitschrift aufschlagen.

    Deswegen wollte Heise wohl ein Testsystem haben :)

    Das liegt an der eingesetzten Virtualisierunglösung. Wir setzen auf Linux-VServer, da es mehr Performace aufgrund des geteilten Kernels bietet. Der Nachteil ist hier, dass keine kernelseitigen Konfigurationen aus dem vServer heraus möglich sind.

    Kurzes Update für treue Leser dieses (langen) Beitrages:

    Im Dezember wird es neue vServer-Angebote geben, mit einem neuen netten Feature. Man darf gespannt sein :)

    Die Beta-Phase des neuen vServercontrolpanel wird (hoffentlich) auch im Dezember starten. Bis Januar werden dann sowohl das alte als auch das neue Panel parallel arbeiten.

    Wir haben immer noch ähnliche Angriffsmuster wie zum Start dieses Beitrages. Die Betreiber dieser vServer mussten feststellen, dass TS3 dafür verantwortlich war. Welche Version diese genutzt haben, können wir nicht sagen. Die Angriffe sind aber deutlich zurück gegangen.

    Da Teamspeak immerhin die Software gewerblich vertreibt, lassen Sie sich doch von Teamspeak am besten die Zusicherung geben, dass keine Probleme mehr bestehen. Notfalls ist der Hersteller dann im Rahmen der Produkthaftung in Regress zu nehmen (weiteres hierzu kann ein zugelassener Rechtsanwalt sagen).

    TS3 verbieten wir nicht. Wir tragen hier allerdings nicht mehr aus Kulanz den entstandenen Schaden, wenn durch TS3 Angriffe gefahren werden. Dafür waren das in der Vergangenheit zu viele Angriffe. Es ist in der Tat fahrlässig, eine derartige Software einzusetzen. Wir können jedem nur raten von den Herstellern TS3s eine fehlerfreie Software zu verlangen.

    Wir tun alles uns mögliche um stabile Systeme bereit zu stellen. Stellen Sie sich einmal vor was es uns kostet, wenn die Systeme durchgehend instabil wären? Der Support-Aufwand würde explodieren und Support ist mit das teuerste, was wir anbieten. Daher ist der Kernel bevor er ausgerollt wurde, wirklich sehr lange getestet worden.

    Den aktuellen Bug, von dem leider ein paar Kunden bislang betroffen waren, konnten wir so eben (Sie sehen, wir arbeiten auch Nachts für Sie) reproduzieren. Er liegt an einer versteckten Inkompatibilität zwischen dem aktuellen Kernel und dem RAID-Controller, den wir auf manchen Nodes verwenden. Dadurch kommt es in seltenen Fällen zu dem Fehler, dass der RAID-Controller die Festplatten nur noch verzögert ansprechen kann.

    Auf allen betroffenen Nodes werden wir den Kernel zurück setzen, sollte der Fehler auftreten (was wie geschrieben unwahrscheinlich ist). Auf den Nodes die hiervon gar nicht betroffen sind, werden wir den Kernel weiter ausrollen.

    Sobald dann ein Patch für den Kernel besteht der den Fehler fixt, werden wir den Kernel auch auf den bislang von dem Fehler betroffenen Nodes ausrollen.

    Sie nutzen einen sehr günstigen vServer. Dieser ist so günstig, da er in großen Mengen von uns vertrieben wird.

    Wir sind bemüht Wartungsarbeiten Nachts durchzuführen, allerdings lassen sich nicht alle Wartungsarbeiten bei der Menge an vServern Nachts durchführen. Zu dem sind hier die Preise unserer Mitarbeiter deutlich teurer.

    Wenn Sie mit der von uns garantierten Verfügbarkeit nicht leben können, unterbreiten wir Ihnen gerne ein individuelles Angebot was genau auf Ihre Anforderungen zugeschnitten ist. Bitte wenden Sie sich hierzu an den Support.

    Vielen Dank!

    Manchmal kann auch der Chef mit einem Kaffee beim Mitarbeiter stehen. Momentan klaut er sich aber eher Süßigkeiten bei seinen Angestellten :)

    Jetzt stehe ich kurz davor einen Angestellten für heute Büro-Verbot zu erteilen. Er ist trotz Urlaub hier und wollte eigentlich, nur mal eben schnell, etwas ins SVN einchecken....

    shifty:

    Dann überschneiden sich bei Ihnen eventuell unglücklicher Weise zwei Probleme. Bitte wenden Sie sich direkt an den Support.

    Hat noch jemand anders Probleme mit seinem vServer seit dem Eingang des Newsletters? (wichtig, Sie müssen auch auf dem betroffenen Node liegen, sprich den Newsletter erhalten haben).

    Wir haben jetzt alle eMails zu ähnlichen Problemen wie die hier geschilderten (das Problem mit dem Passwort ausgenommen) ausgewertet. Leider sieht es in der Tat so aus, dass der neue Kernel auf einem Node nicht stabil läuft.

    Wir haben den Kernel, wie hier gewünscht, daher auf dem Node zurück gesetzt. Alle betroffenen Kunden haben soeben hierzu eine eMail erhalten.

    Wir bedauern diesen Vorfall sehr. Gerade um Probleme mit neuen Kernels auszuschließen, haben wir diesen über mehrere Monate in einer Testumgebung (an dieser sind auch Mitglieders des Forums beteiligt) getestet. Leider müssen auf dem betroffenem Node Umstände vorherrschen, die in der Testumgebung und auf allen anderen Nodes die mittlerweile mit dem neuen Kernel ausgestattet sind, nicht auftreten.

    Den Vorfall nehmen wir zum Anlass um zu prüfen was genau die Probleme verursacht hat. Anschließend werden wir den Kernel anpassen und neu kompilieren. Nach weiteren Tests in der Testumgebung werden wir ihn dann erneut ausrollen, sofern er in der Testumgebung problemlos arbeitet.

    Für die bereiteten Umstände bitten wir um Entschuldigung.