Mountain Prophet

Über 30 unterschiedliche static IP Adressen von augenscheinlich dedizierten Servern bei Hetzner hab ich grad an der Firewall ausgesperrt wegen permanenten Spammings. In nur 24 Stunden 30+ IPs und über 200 Spams. Wenn ich nicht zu faul wäre, würde ich die grad alle Mal an abuse@ melden, aber da fehlt mir bei dem Pisswetter grad die Motivation. Ist aber schon komisch, warum so viele Hetzner IPs da auftauchen.. Dabei hatte ich von Hetzner immer ne gute Meinung, muss ich die nun revidieren?

Tags: Hosting, Rootserver, Spam

Unsere bei 1&1 angemieteten dedicated Root Webserver werden auch nicht jünger, die zu migrierende Kiste pfiff wenn man es genau nimmt, auf dem letzten Loch. Es war also dringend an der Zeit, den alten Server gegen neue Hardware auszutauschen. Im heutigen Blog Post möchte ich kurz das Vorgehen und die Fallstricke dazu schildern.

weiter »

Tags: 1und1, Plesk, Rootserver

Der Grund, warum ich hier schon lange nicht mehr über Plesk auf den 1&1 Kisten meiner Kunden gemeckert habe, liegt nicht etwa daran, dass Plesk seit neuestem brav und zuverlässig seinen Dienst tun würde, nein, ich hatte nur die letzte Zeit kaum Zeit, mich damit zu beschäftigen oder hier zu posten. Die neueste Episode in der Unendlichen Geschichte mit Plesk Nerverreien ist wieder ein prima Schenkelklopfer.. Diesmal geht’s darum, dass plötzlich keine eMails mehr rein oder raus gehen. Rien ne va plus.

Kurz eingeloggt und nach etwas rumstochern fällt mir auf, dass das Spool Verzeichnis von QMail genagelt voll ist, mit teils steinalten Mails, die da eigentlich nix mehr zu suchen hatten. Die Plesk Kisten sind jetzt über 2 Jahre immer wieder per AutoUpdate in Plesk von damals 7.x auf heute 9.x aktualisiert worden, sonst wurde nix getan. Die Partitionsgrößen für /handlers/spool und die diversen Queues sind zu klein geraten für meinen Geschmack und dem Aufkommen. Als weiteren Teil des Problemes könnte man sich Fragen, warum die Kiste so mit Spam zugeballert wird. Als nächste Frage kämen dann gleich: warum löscht Plesk die Spool nicht mehr selber?

Interims Fixe: z.b. Server neu starten, /handlers/spool/ ist dort tempfs.  Oder alle 14 Tage per Cronjob Qmail dazu zu bringen, den alten Mist wegzuwerfen. Dann dringend bei Gelegenheit: die verwendeten tempfs  Paritionen bissl vergrößern und dann aber auch mal alles neu aufsetzen – am besten neu aufsetzen ohne Plesk. Aber das soll jemand anders machen, ich hab grad kein Nerv für sowas.

Was lernt man draus? Rootserver administrieren sich nicht selber und Plesk alleine ersetzt keinen Admin. Nur will das halt keiner hören.

Tags: 1und1, Email, Plesk, Rootserver

Seit ein paar Plesk Releases schon hat Plesk die nervige Angewohnheit entwickelt, den FQDN Domänenname zu vergessen, welcher beim eMailversand an den empfangenden Server als HELO Namen geschickt wird. GMX (und andere Provider akzeptieren) aber nur dann ankommende Mails, wenn der HELO Name eine funktionsfähige Domäne beinhaltet. Dieser Helo Name kann in /var/qmail/control/me in ner Shell Sitzung korrigiert werden, wird aber beim nächsten Reboot bzw. spätestens jedoch beim nächsten Update wieder überschrieben. Anstatt irgendwas sollte mein-server.de in dieser Datei stehen (wobei mein-server.de natürlich korrekt auflösen sollte).

Tags: 1und1, Email, Plesk, Rootserver, Vserver

Heute hat sich mal wieder einer unserer Plesk Server krank gemeldet. Beim Einrichten einer neuen Domäne kam die Fehlermeldung:

Failed domain creation: Domaindaten konnten nicht aktualisiert werden : Fehlerhafte DNS Zone-Parameter.

Wer nun, wie ich, vermutet, das es an den DNS Template, den Zone Files, SOA oder sonstwas DNS bezogenes liegt, der irrt genauso wie ich…

Das Problem kommt von einem fehlerhaften Domain Template (das Ding, was beim Einrichten einer neuen Domäne ausgewählt werden kann, damit man nicht alle Hosting Einstellungen von Hand setzen muss). Da muss man man erst mal drauf kommen, denn Google fand zwar haufenweise “Failed domain creation” Fehler, aber keinen “Fehlerhafte DNS Zone Parameter”.

2,5 Stunden Fehlersuche für so nen Scheiss.. Manchmal frage ich mir, ob diese Zeitverschwendung für die Fehlersuche nicht die Zeitersparnis, die man mit Plesk zweifelsohne hat, nicht unterm Strich ad absurdum führt.

Tags: 1und1, Plesk, Rootserver, Supportfälle, Vserver

Mittwoch, 3.09.2008 – 08:00 Uhr: Was gibt es schöneres am Morgen als einen Serverausfall? Ich schlapp grad mehr oder weniger motiviert an den Schreibtisch und muss feststellen, dass einer unserer Dedicated Server bei 1&1 nicht mehr reagiert – die anderen funktionieren problemlos. Kollege klingelt bei der Hotline durch, ja, ist was kaputt, Reparaturzeit noch nicht bekannt. Bingo.

Nachtrag: seit 11:40 ist der Server wieder erreichbar.

Tags: 1und1, Eigene Homepage, Rootserver

1&1 Rootserver werden mit Plesk 8.x ausgeliefert. In Plesk enthalten ist Spam Assassin, dies wiederum enthält einen ganzen Sack voll Filter (Inhaltsfilter, ReqEx basiert, zu finden in /usr/share/spamassassin/*.cf) sowie einen Bayes Filter. Verzeichnisnamen beispielhaft für unseren Server mit Suse 9.3, dürfte bei neueren Suse Versionen aber nicht viel anders sein. In diesem Blog Post gibt es ein paar Ansätze, um die Filterleistung zu optimieren. weiter »

Tags: 1und1, Email, Plesk, Rootserver, Spam, Spamassassin

Vor ein paar Tagen musste einer unserer Root-Server L aus dem Hause 1und1 neu initialisert werden. Die Initialisierung (also das neu Formatieren und Aufspielen eines Suse 9.3 und PLESK 8 Images) dauert sonst im Schnitt 2 Stunden. Nach ca. 4 Stunden begannen wir damit, den 1+1 Support an der Hotline zu nerven und wurden ab dann im halbstunden Rhythmus weiter vertröstet. Nach ca. 8 Stunden dachten wir uns: “Hey, weisst was, der Server muss morgen stehen, das kann noch Ewig so weiter gehen, holen wir einfach nen neuen, dann kann der hier Initialiseren bis die Kühe von der Weide traben“.
Gesagt getan und vom 1und1 Vertrieb einen niegelnagelneuen Root Server L64 in Rekordzeit hingestellt bekommen, nichtmal 20 Minuten hat es von telefonischer Auftragserteilung bis Übergabe des Servers gedauert. Prima. Exakt 21 Minuten nach Auftragserteilung für den 1&1 Root Server L64 war der für mehr als 9 Stunden versumpfte alte Rootserver L wieder betriebsbereit. Dumme Zufälle gibts? Knapp 70 Euro “umsonst” ausgegeben.

Heute morgen verabschiedet sich ohne ersichtlichen Grund auf eben diesem Root-Server L eine der 2 zugewiesenen IP Adressen und damit der Secondary DNS Server des Servers. Keine Ahnung wieso und warum. Lokal war alles OK, von aussen gepingt kam man nie auf der Kiste an. Der Hotliner wusste es auch nicht, hat hier mal die Nase reinget eckt, dort mal ins Plesk geschaut und ein “Netzwerk Ticket” aufgemacht. Was immer damit nun genau gemeint ist. Man würde sich bei uns melden. Nachdem Stunden später immer noch nix kam und meine eigenen Reparaturversuche erfolglos blieben, kam uns die glorreiche Idee: “hey weisst was, dann kaufen wir eben ne neue IP und konfigurieren dass schnell um”. Gesagt getan.  Im 1und1 Controlcenter schnell ne weitere IP bestellt, in Plesk Eingerichtet und siehe da.. Schwups im selben Moment, wo ich die neue IP Adresse im Plesk einrichte, geht die alte wieder. Ja glaub ichs noch.. schon wieder  Geld zum Fenster rausgeworfen.

Was lernt man da nun draus? Ich bin zu ungeduldig, oder: jedesmal, wenn was kaputt geht, muss ich Geld zum Fenster raus werfen, dann gehts wieder. Ich habe mir nun also den Entschluss gefasst, wenn das nächste Mal was nicht mehr funktioniert, was eigentlich funktionieren muß, dann spül ich 10 Euro das Klo hinunter, dann müsste lt. dieser erdrückenden Beweiskette wieder alles funktionieren.

Ich werde berichten…

Tags: 1und1, Rootserver

1&1 aktuelle Rootserver, zumindest die Suse Kisten sind mit QMail ausgestattet. Was mir als alter SendMail Fan doch gelegentliches Kopfzerbrechen bereitet, denn zumindest in meiner Online Bibliothek findet sich nur sehr wenig Literatur zum Thema QMail. Was mich in letzter Zeit mehrfach die Wand hochgehen liess, ist die Tatsache, dass diese 1+1 Kisten mit Plesk 8 zumindest in Sachen E-mail Statistik immer noch schmerzlich wenig zu bieten haben. Seit der Plesk 7.5.x Version kam zwar eine in Plesk integrierte Ansicht der Lokalen und Remote eMail Queue hinzu, aber die hilft einem auch nur, wenn die Mails noch nicht zugestellt wurden und man zufällig dann reinguggt.

Nun ist Spam in der letzten Zeit wirklich zum Problem geworden, selbst unsere weniger stark ausgelasteten Server schaufeln gut und gerne 100.000 Nachrichten am Tag in der Gegend herum. Überwiegend Spam, der trotz aktivierten MAPS Blacklisten, Sender Policy Framework, etc. auf der Kiste aufschlägt. Andere Spam Angriffspunkte, die derzeit extrem populär bei der Spambranche sind, sind ungeschütze Kontaktformulare oder allgemein alle Scripts, die irgendwie Mails versenden können. Auch immer wieder gerne gesehen sind Kunden mit verseuchten PCs, die schnell mal ein paar tausend Mails auf den Server blasen.

Um der ganzen Sache etwas besser Herr zu werden und den eMail Traffic etwas besser überwachen zu können, bin ich schliesslich auf das kostenlose ISOQLOG gestossen, was die QMAIL Protokolle des Server analysiert und entsprechende eMail Tagesstatistiken erstellet: Wer hat wann wieviel EMails empfangen, versendet, wieviel Datentransfervolumen hat er verursacht.

Die Installation war leider mal wieder Linux typisch ätzend. Bequeme RPM Installdateien von ISOQLOG sind leider seit zig Versionen veraltet, so dass einem mal wieder nur die Installation per Make bleibt. Die war dann allerdings wenig problematisch, die aktuelle Plesk 8 Suse 9.3 Installation bei 1und1 erfüllte alle Installationsvoraussetzungen ohne nachinstallieren irgendwelche abhängigen Packages. Leider ebenfalls wieder Linux typisch ist die Dokumentation von ISOQLOG so gut wie nicht existent und im Großen und Ganzen eher nutzlos. Bei der Installation sehr nützlich hatte sich die Seite Qmailrocks.org erwiesen.

Für die Installation auf Suse9.3 mit Plesk 8 mussten ein paar Änderungen in der Config Datei gemacht werden, hier die Abweichungen zur Config aus dem Tutorial von Qmailrocks.org:

logtype = “qmail-syslog”
logstore = “/usr/local/psa/var/log/maillog”
outputdir = “/srv/www/vhosts/ihr-server.de/httpdocs/isoqlog”

Der Cronjob zur automatischen Aktualisierung kann bequem über das Plesk Interface eingerichtet werden. Sinnvoll ist es auch, das outputdir zusätzlich noch mit einem .htaccess Verzeichnisschutz zu sichern, das geht auch einfach über die Plesk Oberfläche.

Teilweise kommt es durch die Logrotation zu etwas merkwürdigen Ergebnissen, die sich dann im Laufe des Tages nach der Rotation dann wieder korrigieren. So ganz optimal ist es also noch nicht. Auch gibt ISOQLOG keine Auskünfte über die große Masse an von relaylock abgewiesener Mails, was den erhofften Nutzen von ISOQLOG dann doch wieder etwas reduziert hab, aber hilfreich ist es allemal.

Tags: 1und1, Email, Plesk, Rootserver, Spam