Gerade habe ich bei meinem Server in der GRUB-Konfiguration einen Hinweis auf eine QUEMO-VHD gefunden. 1und1 scheint also quemu zum Testen der Systemabbilder ihrer rootserver zu verwenden?! Warum nicht, nur hätte man den sinnfreien resume-eintrag aus der GRUB-Konfiguration entfernen sollen.
kernel /boot/vmlinuz-2.6.34.7-0.7-default root=/dev/md1 resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00002-part1
Naja, immerhin besser als Virtual PC 
Tag Archives: linux
Vierual Server – kein Speicher trotz massig vRAM
Also wenn man vorher bie mit vServern dieser Art zu tun hatte ist es schon eine ganz schön dicke Überraschung. “Cannot allocate memory” trotz 3 GB freiem Speicher. Bei einem Webserver bedeutet dieses Verhalten kurz gesagt Schicht im Schacht. Aber woher kommt dieses Verhalten? Nun, nach einiger Recherche bin ich auf ein Limit “kmemsize” des Virtuozzo Containers gestoßen. Dieses Limit begrenzt den nicht auslagerbaren Kernelspeicher pro Container. Dumm nur, jeder Prozess benötigt einige KB bis mehrere MB Kernelspeicher die beim “forken” allokiert werden.
Bei 1und1 ist dieses Limit 40MB. Betreibt man hier einen Apache2 Webserver mit Prefork MPM benötigt jeder Prozess ca. 800K Kernelspeicher. Dazu noch ca. 500K für MySQL, 2M für alle Postfix-Prozesse und ca. 8MB für die restlichen Dienste eines SuSE 11.3 Systems.
Es bleiben also für Apache Prozesse ca. 30MB, was ca. 40 Prozessen entspricht. Hat man mehrere Webseiten, ein Statistiksystem und mehrere kleinere vHosts eingerichtet, kann dieses Limit sehr schnell erreicht sein. Ein kleines Beispiel:
Eine Website enthält 50 Fotos, 2 Scripte, 4 CSS-Dateien und 4 andere Elemente. Ein Browser lädt Elemente so wie sie im DOM-Baum (HTML-Position) vorkommen, versucht allerdings externe Elemente wie Fotos etc. möglichst paralell zu laden. Das würde auf der oben besagten Website erst 7 nacheinander folgende GET Anfragen und dann 50 fast parallele Anfragen verursachen und somit auch 50 Child-Prozesse.
Also, wer einen vServer bestellt sollte dieses ärgerliche und nicht im Prospekt erwähnte Limit unbedingt beobachten. Ich werde nun wohl wieder vom vServer weggehen müssen, da diese 40MB vorn und hinten nicht ausreichen.
Serverumzug!!!
So, nachdem es nun am vergangenem Wochenende zum Totalausfall meiner Webseiten kahm, und mein Provider nichts besseres zu tun hatte, als ohne vorherige Ankündigung meine Accounts auf einen anderen Server zu verlagern, habe ich mich dann doch dazu überwunden einen vServer zu mieten. Die Performance ist einfach nur gigantisch. Bei All-inkl.com dauerte ein Aufruf meines Statistik-Systems “Piwik” immer mehrere Minuten, der vServer verarbeitet die gleiche Seite in wenigen Sekunden. Ähnliche Unterschiede auch bei meinem (diesem) Blog. Statt sekundenlanger Ladezeiten quasi null Verzögerung. In den kommenden Tagen wird es noch das ein oder andere Problem geben, ich hoffe aber bis ende Januar alles auf dem vServer umgezogen zu haben.
Wo ich nun Hoste? DNS wie immer bei Inter Networx und den vServer bei 1und1. Zugegeben, hier ist auch nicht alles ohne Fehler, so kann das SuSE 11.3 Template komischerweise keinen Hostnamen ändern, CentOS mit Plesk komischerweise schon. Die Installation eines aaa_base Updates verabschiedet den vServer ins nichts und diverse Scripte in /etc/init.d/rc[xx] sind definitiv NICHT LSB-Konform was zu diversen Fehlermeldungen führt. Mehr dazu wenn ich den Server besser kennengelernt habe.
Gigabyte GA-D525TUD – DualCore Atom Mini-ITX Mainboard
Seit einiger Zeit suche ich nach einem möglichst günstigem, stromsparendem, Linux-tauglichen und mit 4 SATA-Ports ausgestatteten Mainboard für meinen Heimserver. Nach einigem hin und her habe ich mich für das Gigabyte GA-D525TUD entschieden.
Zur Ausstattung:
Die ersten beiden SATA-II Anschlüsse werden über den Standard 82801GR/GH (ICH7 Family) SATA AHCI Controller bereitgestellt. Der onboard “Realtek RTL8111/8168B” Gigabit Ethernet Chip ist intern genau wie der von Gigabyte “Gigabyte SATA-II Controller” getaufte “JMicron 20360/20363 Serial ATA Controller” über PCI Express angebungen. Leider wird der am 82801G (ICH7 Family) High Definition Audio Controller angebundene Realtek ALC887 noch nicht von ALSA unterstützt. Alsactl meldet “Unknown hardware: “HDA-Intel” “Realtek ALC887″ “HDA:10ec0887,1458a002,00100302″ “0×1458″ “0xa002″. Anwender, die dieses Board als Multimedia-System einsetzten wollen, sollten dies beachten. Leider kann im BIOS nicht sehr viel Speicher für den “Intel Pineview” Grafikchip” zugewiesen werden, was wieder gegen Multimedia-Einsatz spricht. Für Erweiterungskarten steht ein normaler PCI-Slot zur Verfügung.
Hardware-Monitoring
Das Board verfügt noch über einen it8720-isa-0290 Hardware-Monitoring Chip und den üblichen coretemp-Sensor bei Intel-Prozessoren. Beide werden vom LM-Sensors-Projekt unterstützt und auch richtig erkannt. Es können die üblichen Spannungen, Coretemp und Lüfterdrehzahl problemlos abgefragt und überwacht werden.
Leistung
Die beiden Kerne und die HT Unterstützung machen sich unter Linux bemerkbar. Im Vergleich zu meinem EPIA C7 1Ghz System ist der Atom um das 5-10 Fache schneller. Leider fehlt ihm eine Hardware-AES Engine zur Festplattenverschlüsselung, was den kleinen Prozessor beim Verschlüsseln von Software-Raids an seine Grenzen bringt. In den beiden DDR3 Speicherbänken können maximal 4GB PC3-800 Speicher installiert werden. Für einen Heimserver mehr als ausreichend.
Fazit
Das Mainboard ist in Preis/Leistung fast nicht mehr zu überbieten. Das fast perfekte Mainboard für einen Heimserver. In Verbindung mit einem IDE-Flash Modul für das Betriebssystem stehen 4 SATA-Ports zur Verfügung. Zusammen mit dem Chenbro ES34069 ergibt das einen sehr stromsparenden Heimserver.
Greylisting am Mailserver – Ehr nervig als nützlich
Greylisting – eine Methode zur absichtlichen E Mail-Empfangsverzögerung zur Spambekämpfung funktioniert so: Auf dem Mailserver, genauer dem SMTP-Server läuft ein Prozess der den ersten Versuch eines anderen Mailservers oder Spammers eine Nachricht zuzustellen mit einem temporären Fehler abweist. In der Fehlermeldung steht dann meistens “Message Rejected – Greylisting for xx Minutes”. Die meisten modernen Mailserver sind so konfiguriert, dass beim auftreten einer 4xx Meldung nach X Minuten die Nachricht erneut gesendet wird. Je nach Konfiguration des Mailservers kann dies aber auch mal mehrere Stunden dauern.
Die meisten Greylisting-Dienste warten allerdings nicht ewig auf die erneute Zustellung einer Nachricht. Verwirft der Greylisting-Dienst nun die Nachricht aus der Datenbank bevor der Mailserver des Absenders einen erneuten Versuch startet, wird die Nachricht niemals ankommen. Das kann relativ schnell passieren, wenn es beim Absender tatsächlich Probleme gab die Nachricht zuzustellen. Dann verdoppelt sich nämlich das resend Intervall nach jedem Fehlversuch.
Nimmt man nun als Beispiel Postfix, versucht der Mailserver des Absenders nach einem Fehlversuch nach 5 Minuten die Nachricht erneut zu zusenden. Scheitert das erneut, verdoppelt sich die Wartezeit bis zum nächstem Versuch. Nehmen wir an, der Server des Empfängers hat eine Greylist-Time von 5 Minuten. Der Server des Absenders addiert zum Nachrichtenzeitstempel bei ersten Versuch die konfigurierte minimal_backoff_time. Sind das ebenfalls 5 Minuten, versucht es das System nach Eingangszeit+5Minuten erneut. Das sind allerdings niemals 5 Minuten ab Greylist-Startzeit, da die Nachricht je nach Last einige Sekunden auf dem Mailserver des Absenders verbleibt. Also scheitert auch der zweite Versuch in 50% der Fälle, da sich die Zähler um einige Sekunden unterscheiden.
Für einen dritten Versuch wartet der Mailserver des Absenders nun die doppelte Zeit, also 10 Minuten. Die minimale Verzögerung neuer Nachrichten sind bei Postgrey in der Standardkonfiguration also 15 Minuten. Einige ganz schlaue Admins setzen allerdings ihre Greylist-Time auf 30 Minuten. Der Server des Absenders wartet für den 3. Versuch 20 Minuten. 5 + 10 + 20 = 35Minuten. Wenn es ungünstig läuft und die Nachricht vorher mehr als 5 Minuten in der Warteschlange lag, braucht der Server einen weiteren Versuch. 5 + 10 + 20 + 30 = 1h. Nun habe ich es erlebt, dass einige Server die Nachricht maximal 1 Stunde in der Greylist-Datenbank halten. Wie soll hier im ungünstigstem Fall jemals eine Nachricht ankommen?
Dazu kommt, die Spammer haben inzwischen dazu gelernt. Da in der Fehlermeldung meistens “Greylisted for xx Minutes” erscheint, werten die Spam-Scripte einfach diese Zeit aus und versuchen es anschließend erneut.
Die oben beschriebenen Szenarios sind real und kommen in der Praxis tatsächlich so vor. Selten, aber es passiert. Dazu kommt auch noch, einige Admins die scheinbar die RFC nicht gelesen haben, verwerfen alle Mails die vom Zielserver mit einer temporären Fehlermeldung abgewiesen werden. Manchmal liegt das auch an schlecht umgesetzten SMTP-Diensten die alle nicht zustellbaren Nachrichten gleich behandeln. Solche Systeme werden nicht in der Lage sein, an Server mit Greylist-Daemon Nachrichten zu senden. Ein Beispiel ist mail.ru.
Auch ist die absichtliche Verzögerung nicht in der RFC vorgesehen. Es gibt bessere und Sinnvollere Möglichkeiten Mailserver zu schützen. Greylisting war eine Zeit lang als Notlösung gut, inzwischen aber unbrauchbar und sollte abgeschaltet werden.
