Erfahrungsbericht Serverdiscounter.com

tl;dr: Ich würde nicht empfehlen, irgendeine Dienstleistung dieses Anbieters in Anspruch zu nehmen. Innerhalb von vier Monaten habe ich nahezu nur schlechte Erfahrungen gesammelt, welche ich hier detailliert darlegen möchte.

Zu Beginn

Ich brauchte für einen 1HE-Server ein günstiges Housing, weswegen ich ein passendes Paket bei Serverdiscounter buchte. Die Buchung war unkompliziert und der Support nahm zeitnah Kontakt mit mir auf, um meine Fragen zu klären.

Entgegen der Information auf der Webseite sowie der Antwort vom Support werden Rackmuttern zum Einbau in das Rack im Rechenzentrum benötigt. Die Aussage auf der Webseite und vom Support war, dass nur der Server, Montageschienen und Stromkabel gebraucht werden. Die Muttern konnten zum Glück vor Ort für kleines Geld erworben werden.
Als es dann an das Einbauen im Rack ging bemerkte ich, dass die mir zugewiesene Höheneinheit voll gestellt war mit Kabeln und kleineren Geräten, welche von mir vor dem Einbau erst noch weggeräumt werden mussten.

Das Kabelmanagement im Rack selbst ist seines Namens nicht würdig – Überall hängen kreuz und quer Kabel herum, welche nicht gesichert sind. Dies kenne ich aus professionellen Umgebungen so überhaupt nicht.

Der Hauptakt

Das Netzwerk war nach dem Einbau eine komplette Woche sporadisch nicht erreichbar. Nach ein paar Tagen war die Downtime so groß, dass die 99,8% Verfügbarkeit gemittelt für ein Jahr schon nicht mehr eingehalten werden konnte.

Der Support reagierte mit verschiedenen Aktionen, wobei ein eigenes VLAN für meinen Server am Ende Abhilfe schaffte. An dieser Stelle hatte ich vermehrt den Eindruck, dass der Support blind Lösungswege versuchte, bis das Problem verschwand. Immerhin wurde mir aber geholfen!
Eine der genannten Aktionen war der angebliche Tausch meines Netzwerkkabels, welches aber bei einem späteren Besuch meinerseits immer noch eingesteckt war. Was da genau getauscht wurde, ist mir schleierhaft.

Bei dem Tausch des Netzwerkkabels wurde durch den Anbieter ohne vorherige Ankündigung (!) mein Server vom Strom getrennt und anschließend wieder eingeschaltet, wodurch sich eine Downtime von mehr als einer Stunde ergab.

Auf Nachfrage beim Support kam heraus, dass planmäßige Wartungsarbeiten an der Stromversorgung durchgeführt wurden und mein Server keinen A/B-Strom-Feed unterstützt, weswegen er hart abgeschaltet wurde. (Warum wurde so etwas nicht im Vorhinein durch den Anbieter angekündigt?)

Nach drei bis vier Monaten begann die Netzwerkverbindung wieder Abbrüche zu erleiden. Auf Facebook und auf der Support-Seite wurde ein Switch des Anbieters als defekt beschrieben, der Support versicherte mir jedoch, dass ich nicht davon betroffen bin.
Weiterhin versicherte mit der Support mehrfach, dass sich um das Problem gekümmert werde, was nicht geschah.
An dieser Stelle möchte ich nur anmerken, dass in der AGB beschrieben steht, dass allen (!) Kunden nach spätestens 24h Abhilfe bei Problemen geschaffen wird. In meinem Fall war das Problem auch nach einer ganzen Woche noch nicht gelöst, die Meldungen auf der Support-Seite und auf Facebook wurden allerdings entfernt.
Nach einer Woche ohne Störungsbehebung sah ich mich gezwungen zu kündigen und zu einem anderen Housing umzuziehen.

Die Kündigungsmail ging an einem Freitag-Abend per Mail und per Ticket an den Support raus. Als bis Montag immer noch keine Antwort kam, fragte ich erneut nach.
Als Antwort kam nur eine Nachricht, dass ich das Housing bitte im Kundencenter kündigen solle. (In der Zwischenzeit habe ich allerdings schon mal eine Rechnung für den kommenden Monat per Mail erhalten, obwohl ich das Lastschriftmandat zur Kontobelastung eindeutig widerrufen habe.)
Ich kündigte im Kundencenter und verlange einen Termin zum Ausbau meiner Hardware. Auf viermalige (!) Nachfrage habe ich endlich auch einen Termin im Rechenzentrum bekommen, um meine Hardware wieder abzuholen.

In der gesamten Zeit, in der ich Kunde beim Anbieter waren, wurden immer wieder Fragen und Teile von Nachrichten ignoriert und ich musste sehr häufig nachfragen, bis ich auf konkrete Fragen auch Antworten bekam. Ich hatte das Gefühl, dass ich dem Support nahezu jede Antwort “aus der Nase ziehen” musste.
(Oft wurde davon gesprochen, dass “Kollegen” sich um unsere Probleme kümmern – Ich halte das schlichtweg für gelogen, da jeglicher Kontakt immer nur mit Herrn Zaiser geschehen ist. Man merkt an der Auslastung des Supports relativ deutlich, dass das Unternehmen aus einer einzigen Person besteht.)
Während meines Netzwerk-Probleme war auch die Support-Seite des Anbieters gar nicht oder nur sehr schwer zu erreichen. Auch die Firewall des Anbieters leidet (bis heute) unter starkem Paketverlust. Selbst der Mailserver, an den die Kündigung gesendet wurde, litt unter massivem Paketverlust (>50%).
Mehrere Tage lang war der Zustand der Anbieter-Webseite so, dass weder die Unterseite der AGB, noch die Unterseite der Datenschutzerklärung erreichbar war, da eine ständige Weiterleitung auf die selbe Seite passiert (was in einer Endlosschleife resultierte). Dies rundet das unseriöse Erscheinungsbild des Anbieters ab.

Nachgang

Nachdem ich eigentlich dachte, dass mit der Kündigung alles erledigt ist, erhielt ich im Nachgang eine Rechnung über 7TB (!) Traffic, welchen ich angeblich im letzten Monat meines Housings verursacht hätte.
Laut meinem Monitoring habe ich nicht einmal 100GB Traffic im letzten Monat verbraucht, also schrieb ich eine EMail an den Support. Dieser antwortete mir recht zeitnah mit einem Screenshot des Trafficverbrauchs aus seiner Sicht und einer Erklärung, wie sich die Kosten zusammensetzen. Auf weitere Nachfrage, ob hier eine Verwechslung vorliegen könnte (inklusive Screenshot aus meinem Monitoring), erhielt ich wieder mal einige Tage lang keine Antwort.
Laut meinem besten Wissen und Gewissen habe ich den in Rechnung gestellten Traffic nicht verbraucht und dass auf eine deutliche Nachfrage nicht reagiert wird, finde ich sehr schade.
Nach etwa einer Woche meldete sich der Support auf erneute Nachfrage hin, dass das wohl Traffic gewesen ist, der durch den Router gefiltert wurde. Am Switch-Port selbst wären weniger als 100GB verbraucht worden, weswegen die Rechnung glücklicher Weise storniert wurde. Hätte ich hier nicht mehrfach nachgefragt, wäre das Geld von meinem Konto eingezogen worden. (Obwohl die Einzugsermächtigung schriftlich widerrufen wurde.)
Des Weiteren wurde meine Kündigung im Nachgang vom System des Anbieters storniert. Auf Nachfrage wurde mir dann mitgeteilt, dass es sich hierbei um einen Fehler handelt.

Aus allen oben genannten Gründen rate ich dringend davon ab, jedwede Dienstleistung bei diesem Anbieter zu buchen. Ich wurde (leider) durchweg enttäuscht.

Read More

CalDav Invitations trotz Baikal

Im Internet sind immer wieder Beschwerden darüber zu finden, dass mit einer Baikal-Instanz als Kalender-Server keine Einladungen an Personen geschickt werden kann, was Google-Mail, Outlook und Konsorten allerdings von Haus aus mitbringen. Auch der kostenlose Mail-Client Thunderbird kann, zusammen mit dem kostenfreien Lightning-Kalender-Plugin, solche Mails verschicken, aber eben nur so lange, bis Termine zu einem mit Baikal sychronisierten Kalender hinzugefügt werden sollen.

Studiert man die Bugtracker des Baikal-Repositories genauer, so schlagen immer wieder Nutzer einen Trick vor, der allerdings in der aktuell von Baikal verwendeten Version von Sabre/dav (das Backend hinter Baikal) überhaupt nicht mehr funktioniert:

$caldavPlugin = new \Sabre\CalDAV\Plugin();
$caldavPlugin->setIMipHandler(
new \Sabre\CalDAV\Schedule\IMip('no-reply@example.org')
);
$server->addPlugin($caldavPlugin);

Diese Erweiterung funktioniert in den aktuelleren Versionen nicht mehr!

Um nun doch erfolgreich Mails mit Einladungen senden zu können, bedarf es eines Tricks, damit Baikal den verwendeten Clients nicht mehr vorgaukelt, Einladungen verschicken zu können. Genau das ist nämlich das Problem: Die Clients (in meinem Fall Thunderbird) denken, die Einladung wird von Baikal versendet, was aber gar nicht passiert. Um die Mails lokal von der verwendeten Software senden zu lassen reicht es aus, das Scheduling-Paket von Baikal zu deaktivieren.

Dazu einfach in der Datei Server.php unter <baikal-root>/Core/Frameworks/Baikal/Core/ die Zeile 171 auszukommentieren:

# $this->server->addPlugin(new \Sabre\CalDAV\Schedule\Plugin());

Nach dieser kleinen Änderung werden die Mails zur Einladung einfach lokal durch die verwendeten Clients abgesendet und verarbeitet. Klar sollte an dieser Stelle allerdings sein, dass das Ganze nicht so komfortable wie eine durch den Server verwaltete Variante ist, da so die Antworten auch durch eben jene Clients verarbeitet werden müssen.

Interessant an der ganzen Geschichte ist allerdings, dass laut diesem Kommentar das ganze Scheduling-Plugin erst für Baikal 2 geplant war.

Read More

Postfix reject/Relay access denied

Postfix NOQUEUE: reject: RCPT 450 4.1.1 Recipient address rejected unverified address Connection refused

oder auch:

The mail system <mail>: host mail.xyz.de[xxx.xxx.xxx.xxx] said: 554 5.7.1 <mail>: Relay access denied (in reply to RCPT TO command)

Beim Aufsetzen eines Mail-Servers mit Postfix bekam ich es immer wieder mit dem Problem zu tun, dass Postfix Mails “rejectet“, die eigentlich völlig korrekt zugestellt werden sollten. Ausgangslage war ein System auf einem vServer, das zwei Domains mit einem Mail-Service ausstatten sollte. In meinem Fall war die Haupt-Domain eine xyz.org und die Zweit-Domain xyz.de. Alle Postfächer der org-Domain sollten auf der de-Domain als Aliase vorhanden sein und einfach nur die Mails an die Haupt-Domain weiterleiten. Merkwürdigerweise bekam ich immer den o.g. Fehler, wenn ich versuchte eine Mail mit der de-Domain zu verarbeiten.

Die Lösung zu dem Problem fand ich nach einschlägiger Recherche auf der Seite von  Usman Majid, der unter https://usman.dk/ einen IT-Blog betreibt:
Fügt man in die Config von Postfix eine neue Domain hinzu und konfiguriert diese, so muss der Cache danach geleert werden. Hier reicht ein einfaches Neustarten des Dienstes nicht aus! Standardmäßig passiert das alle 12h, möchte man es von Hand starten reichen folgende Befehle:

/etc/init.d/postfix stop # stoppt den postfix-dienst
 rm -fr /var/lib/postfix/verify_cache.db # loescht die cache-Datei
 /etc/init.d/postfix start # startet den postfix-dienst wieder
Read More

Multitrack-Export in Cubase

Um in Cubase mehrere Spuren auf einmal zu Exportieren reicht es aus, im Export-Fenster links den Mehrspurexport und die zu exportierenden Spuren auszuwählen. More…

Read More

Bundle-Image Speicher freigeben

Ein Sparsebundle kann im Festplatten-Dienstprogramm eines Macs erstellt werden, um beispielsweise viele Dateien zu bündeln oder mit AES128/256 zu verschlüsseln. Die Größe dieses Images wächst mit, wenn Dateien darin abgelegt werden. Das Problem bei einem solchen Image ist allerdings, dass dessen Größe nicht wieder abnimmt, wenn Dateien daraus gelöscht werden. More…

Read More

Rastern kurzzeitig ausschalten

Um die “Einrast-Funktion” der Timeline in Cubase kurzzeitig auszuschalten, reicht es aus, während dem verschieben einzelner Clips mit der Maus, die Befehls-Taste zu drücken: More…

Read More

Cubase 64 Bit auf dem Mac

Steinbergs Cubase wird auf dem Mac OS X Betriebssystem standardmäßig nur in 32 Bit ausgeführt. Um es in vollem Umfang und auch mit allen 64 Bit Plug-Ins benutzen zu können, ist es erforderlich, Cubase in 64 Bit auszuführen. More…

Read More