VM shutdown
im Wirt dann das img-File der VM Sicherheitskopieren und dann ein neues RAW-File anlegen. Dieses so dimensionieren, wie viel zusätzlichen Platz man haben möchte:

cp nameVM.img nameVM.img.bck
qemu-img create -f raw temp.img 10G
mv nameVM.img
cat nameVM.img.save temp.img > nameVM.img


VM starten
Dann die VM wieder starten, normal sollte das problemlos gehen und das installierte Linux sollte ohne Probleme starten. Für das System hat sich an sich ja nicht viel geändert. Im laufenden System dann mit fdisk eine neue Partition anlegen. Für fdisk sollte der neue Speicher schon sichtbar sein. Es sollte also erkannt werden, das noch unpartitionierter Platz auf der Festplatte vorhanden ist. Abschließend noch mal neu starten.

Volume vergrössern
Nach dem reboot sollte dann das zusätzlich SDA-Device zur Verfügung stehen. Dieses können wir nun dazu nutzen, das Volume von LVM zu erweitern.

Ein zusätzliches Physical Volume anlegen:

ll /dev/sda*
pvcreate /dev/sdaX
pvdisplay


Das neue PV der Volume Group hinzufügen:

vgextend vg_name /dev/sdaX
vgdisplay


Das Logische Volume auf die volle Größe der VG erweitern:

lvextend /dev/mapper/vg_name-lv_root /dev/sdaX
lvdisplay


Zum Schluss dann noch das Dateisystem von Linux auf die Größe des LV anpassen:

resize2fs /dev/mapper/vg_name-lv_root


Abschließend noch mal nachsehen, ob der Platz nun wirklich zur Verfügung steht und fertig!
df -lh

Die zweite Sache, die auch eher zufällig rausgefunden habe ist, das man eine iPhone Headset auch als Headset am Mac nehmen kann. Einfach einstecken und Mac OS Lion erkennt es als externes Mikrofon und Kopfhörer. Jetzt kann man es in allen anderen Programmen genutzt werden. Skype zum Beispiel funktioniert super damit.

Was ich jetzt beinahe vergessen hätte: WoW läuft bei mir von einer externen Festplatte. Das Laden dauert auch nicht viel länger als sonst. Ab und an gibt es allerdings mal ein paar kleine Aussetzer. Das liegt wohl daran, das die Festplatte schon sehr schnell in den Standby-Modus fährt. Beim nächsten Zugriff dauert es dann wieder einige Sekunden bis sie anspringt. Lässt sich aber ganz gut damit Leben und spielen.

Der ein oder andere wird sich jetzt fragen was iTunes Match ist? Es ist Apples lösung iTunes von der heimischen Festplatte in die Cloud zu transferieren. Wenn man dies so kommentarlos hört, wird man sich denken :”Der Upload wird aber lange dauern…”. Dafür hat sich Apple aber etwas einfallen lassen. Und zwar geht es erst daher und jagt die ganze Mediathek durch Genius und eine Songanalyse. Analysiert also einmal alle Songs, schickt dies dann ins Netz zu Apple und vergleicht das Ergebnis mit dem iTunes Store. Alle Lieder die so gefunden werden, werden in deinen iTunes Match Account vermerkt, brauchen also nicht mehr hochgeladen werden. Den Rest, den iTunes nicht erkennt, lädt es dann noch zusätzlich hoch. Das gute dabei ist, er vergleicht nicht mit dem lokalen iTunes Store sondern mit dem globalen Store. Die Anzahl der  Tracks ist auf 25.000 begrenzt. Die die er im Store findet, zählen nicht dazu. Im Moment erzielt iTunes eine Trefferrate von gut 75-85%. Hört man jedenfalls von den Menschen auf Twitter und Co.. Bei mir waren es 72% meiner Tracks, die er erkannte. Eine gute Rate wie ich finde, da ich doch sehr viel exotische Musik habe.

Soweit so gut. Das einzige daran was oft ein wenig schief geht ist, das er nicht alle Tracks eines Albums erkennt. Jetzt könnte man sich denken “was soll’s, die Musik hast du doch so oder so”. Ja schon, aber einer der vielen Vorteile von iTunes Match ist, das die Songs die im Store gefunden werden einem als 256Kbit/s AACs bereitgestellt werden. Was klanglich doch bei vielen Songs einen sehr grossen Unterschied macht. Sehr deutlich hab ich es bei einem Album von X Japan gemerkt. Das wollt ich immer mal wieder neu rippen (bin aber nie dazu gekommen), weil beim erstmal ist da wohl was schiefgegangen. Der Rip war sehr leise und dumpf. Nach dem Import in iTunes Match klang das auf einmal sehr viel lauter und deutlicher.

Und nein, durch iTunes Match werden die Songs auf der Festplatte nicht automatisch ausgetauscht. Aber man kann es machen und sollte es auch bei vielen tun. So werden auch zum Beispiel alte Dateien aus der Zeit wo iTunes noch DRM hatte bereinigt. Also man kann nun jegliche seiner Dateien aus der Cloud neu runterladen, immer und immer wieder. Jeden Kauf den man mal getätigt hatte und auch jede Datei die Hochgeladen wurde. Auch können neu gekaufte Tracks gleich auf alle Geräte verteilt werden. Dies muss aber auf den einzelnen Geräten erst explizit aktiviert werden. Auch sollte man in diesem Fall gleich darauf achten, das bei iOS Geräten deaktiviert ist, das diese auch über 3G versuchen Content zu laden.

Aber man kann nicht nur runterladen und so mit seine Mediathek verlegen, man kann auch wunderbar Streamen. Man kann bei iTunes Match bis zu 10 Geräte hinzufügen die Streamen und Runterladen dürfen. So kann ich nun im Büro, bei Freunden oder bei meinen Eltern zuhause immer auf meine gesamte Mediathek zugreifen und all meine musik hören. Cover und Metadaten wie zB der Playcount werden immer mitgesynct. Man kann nicht nur über iTunes auf iTunes Match zugreifen, sondern auch über iOS. Allerdings wird dort nicht gestreamt sondern immer heruntergeladen. Macht auch Sinn, da UMTS erstens nicht flächendeckend ist und zweitens es keine wirklichen Flatrates gibt.

So kann man nun auch über sein iPhone auf sämtliche Songs zugreifen. Schwierig ist allerdings die Verwaltung. Da die übliche Songverwaltung nach dem aktivieren von iTunes Match aus dem Sync-Menü von iTunes rausfällt. Will man nun mal viele Songs löschen oder viele neu aufs Gerät bringen wird es anstrengend. Neue Songs Aufs iOS-Device zu bringen ist noch relative gut gelöst. Man kann Tracks einzeln laden oder albumweise oder auch ganze Playlists. Kompliziert wird es, wenn man sie dann wieder runter haben will. Man kann wieder nur einzeln oder albumweise löschen, was nun passiert wenn man eine Playlist löscht, habe ich noch nicht rausgefunden (mich noch nicht getraut auszuprobieren). Hier könnte man bei der Verwaltung noch ausbauen und sich verbessern. Es ist benutzbar, aber verbesserungswürdig.

Also was haben wir alles: Mediathek@Cloud , Neu laden jeglicher Songs, Streaming, iOS Support und das alles für 25€ im Jahr. Ja es kostet Geld, aber wenn man sich das mal ein wenig überlegt, ist das nicht viel. Also für die Leistung hätten andere bestimmt schon das Doppelte verlangt, im Monat! Wenn man allein nur mal überlegt was das an Speicher und Bandbreite bedeutet. Naja Speicher sparen sie ja schon dadurch, das sie mit den iTunes Store matchen und so nicht jeden song 5 Bazillionen mal speichern müssen. Aber Bandbreite kostet es sie enorm. Vor allen zur Anfangszeit, da viele wohl ihre gesamte Mediathek noch mal neu herunterladen werden.

Man definiert sich im seinem Modul, hier “nginx”, eine neue Klasse. In dieser legt man nun ein Define an. Also quasi eine abstrakte Kasse oder Funktion. Diese belegt man schon mit allen Werten vor, die später jede einzelne vHost-Datei haben soll. Ich benutze hier $title als Übergabe-Variable. siteName ist der vHostname innerhalb des Templates.


class nginx::wordpress{
define site {
$siteName = $title

file { "/etc/nginx/sites/$title.conf":
ensure => present,
owner => "root",
group => "root",
mode => 0644,
content => template("nginx/wordpress.erb"),
}
}


Nun noch ein Template erstellen. In diesem wird der eigentliche vHost definiert. Mit Extras wie Umleitung auf WWW und Sprechenden-URLs. siteName wird hier jeweils durch den von $title übergebenen Wert ersetzt.


server {
listen 80;

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/sites/<%= siteName %>$fastcgi_script_name;
include fastcgi_params;
}
}


Und jetzt kann man z.B. in einer Konfigurationsklasse von Nginx einfach das Define aufrufen, ihm einen Hostnamen übergeben und da durch erhält man einen vHost. Hier muss dann vorab nur noch die oben erstellte klasse inkludiert werden.


nginx::wordpress::site {"zero0ne.de":}


26.05.2011 – Cut My Skin
25.06.2011 – Maximum the Hormone
04.07.2011 – X Japan
29.08.2011 – The Offspring

To do:

07.10.2011 – Abwärts
04.11.2011 – ASP
18.11.2011 – Hammerfall
04.12.2011 – Rammstein

Die Ausführung des Befehls kann je nach Größe der Datenbank von einigen Sekunden bei zu mehreren Minuten Dauern. Bei sehr großen Datenbanken auch Stunden. Ist der Vorgang jedoch abgeschlossen, findet man im aktuellen Verzeichnis den Dump. Diesen kann man nun auf den Server kopieren, wo die Datenbank läuft, in welche man den Export importieren möchte. Dies kann man per SCP oder per SFTP machen, wie einem beliebt.

Hat man nun also die Datei kopiert, wechselt man auf die Konsole des Zielservers. Dort geht man dann in das Verzeichnis, in welchem die Datei liegt. Hier nun folgendes Kommando absetzen:

Hiermit wird die Datenbank aus der Datei in den MySQL-Server importiert. Zu beachten sei, das Datenbanken gleichen Namens so überschrieben werden. Ist dies erfolgreich abgeschlossen kann man die SQL-Datei löschen.

Einfache Replikation: Master – Slave

Für eine asynchrone Replikation werden mindestens 2 MySQL-Server benötigt, von denen einer als Master und mindestens einer als Slave agiert. Bei dieser Art von Replikation schreibt der Master die Updates (alle Statements, die Datensätze verändern) in eine Binärlog-Datei. Diese dient als Datenspeicher, von welchem aus die Informationen über Datenänderungen an die Slave-Server gesendet werden.

Sobald sich ein Slave mit dem Master verbindet, übermittelt dieser die Position der letzten, erfolgreich empfangenen Änderungen, und empfängt daraufhin vom Master alle Updates seit der übermittelten Position. Nachdem der Slave die Änderungen übernommen hat, schaltet er so zu sagen in den Leerlauf und wartet auf die Übermittlung weiterer Änderungen vom Master.

Konfiguration eines Master

Für den später einzurichtenden Slave muss man auf dem Master einen Account anlegen. Dies erledigt man mit einen GRANT-Befehl, welcher allgemein dazu da ist Benutzer anzulegen. „GRANT SUPER,REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO ReplikationsUser@slavehost IDENTIFIED BY ‘PWD’ ; Flush Privileges;“. Wobei hier dann „@slavehost“ die IP oder der Hostname des Slave ist. Man sollte dann noch in der „my.cnf“ nachsehen ob eine „server-id“ vergeben ist. Ohne diese geht es nicht. Jeder Server, der an einer Replikation beteiligt ist, braucht eine eindeutige „server-id“. Dabei sind nur Zahlen erlaubt. Man sollte dann auch noch einen Verbindungstest durchführen, indem man sich vom Slave aus auf den Master verbindet. „mysql -h masterhost -u ReplikationsUser -p“. Sollte diese Verbindung nicht aufgebaut werden können, sollte man beim Master kontrollieren ob in der Konfig evtl. „bind-address = 127.0.0.1“ steht oder ob das Passwort richtig gesetzt ist. Im folgenden Schritt erstellt man dann eine Kopie aller zu replizierenden Daten. Im Regelfall ist das meist alles. Dafür sperrt man den kompletten Server mit einer Schreib-Sperre.

„FLUSH TABLES WITH READLOCK ;“. Die Konsole in der man dies Kommando eingegeben hat muss für die Dauer der folgenden Vorgänge geöffnet bleiben, da sonst der Readlock erlischt. Um dem Slave die genaue Position und den Namen der Binärlogdatei mitzuteilen, führt man noch folgendes Kommando aus: „SHOW MASTER STATUS;“. Die Ausgabe sollte dabei dieser ähneln:

[ Mit den letzten beiden Feldern kann man in der „my.cnf“ explizit festlegen, welche einzelnen Datenbanken repliziert werden sollen und welche nicht. Dieses sollte man aber im Regelfall nie auf dem Master festlegen. Sondern eher auf dem Slave filtern. Dort kann man auch wieder in der „my.cnf“ festlegen was alles repliziert werden soll und was nicht. ]

Man notiert sich nun den Namen des „binlog“ und die Position, danach kann man mit dem Kopieren der Daten beginnen. Hat man nur MyISAM-Datenbanken macht man dies am besten auf Dateiebene. „tar -cvz -f /backup/mysql/snapshot_DATUM.tar.gz /var/lib/mysql“. Um die DB nicht all zu lange zu sperren kann man auch erst nur die Daten kopieren und dann später komprimieren. Ist man dann fertig, kann man sich aus der MySQL-Konsole ausloggen und somit die Sperre wieder aufheben.

Konfiguration eines Slave

Die MySQL-Version auf dem Slave sollte mindestens der des Masters entsprechen. Sie darf neuer sein, aber nicht älter. Auf dem Slave stoppt man dann erstmal den laufenden MySQL-Server und editiert die „my.cnf“. Dort setzt man auch wieder die Variablen für die Server-ID. Zu beachten ist hier nur, dass die Server-ID sich von der des Masters und aller bestehenden Slaves unterscheiden muss. Will man, das dieser Slave noch Master für weitere untergeordnete Slaves ist, muss man auch darauf achten das hier das binlog aktiviert ist. Hat man dann die Daten, welche man auf dem Master kopiert hat übertragen, kopiert man diese auf dem Slave nach „/var/lib/mysql“. Zu beachten sei, das man sich nicht die Datenbank „mysql“ überschreibt. Diese sollte man auch in der „my.cnf“ von der Replikation ausnehmen. Dies macht man mit den Optionen:

replicate-ignore-db= mysql
replicate-wild-ignore-table = mysql.%

Hat man dann die Daten kopiert, kontrolliert man noch mal, ob alle Dateien unterhalb von „/var/lib/mysql“ auch dem Benutzer und der Gruppe „mysql“ gehören. Jetzt kann man den MySQL-Server wieder starten. Um nun die Replikation zu aktiveren müssen wir dem Slave noch mitteilen, wer der Master ist und an welcher Stelle im binlog er anfangen soll zu lesen. Dies macht man mit dem „CHANGE MASTER“ Kommando:

Wurde das Statement erfolgreich ausgeführt, wurden alle Änderungen übernommen und der Slave ist soweit bereit die Replikation zu starten. Gestartet wird dann einfach mit „SLAVE START;“ (gestoppt mit „SLAVE STOP;“). Nach dem Start sollte man mit „SHOW SLAVE STATUS;“ den Status der Replikation überprüfen. Steht „Slave_IO_Running“ auf „Yes“ läuft die Replikation. Dann ist immer noch der Wert „Seconds_Behind_Master“ interessant. Er gibt an, wie viel der Slave dem Master hinterher hängt. Am Anfang steht hier eine mehr oder weniger große Zahl, in endlicher Zeit sollte hier dann aber nur noch „0“ stehen. Steht dort „NULL“ gibt es ein Problem mit der Replikation, dann ist aber auch „Slave_IO_Running“ meisten auf „No“. Unter „Last_Error“ kann man dann noch nachlesen, wieso es zu einer Unterbrechung kam.

Reparieren der Replikation

Sollte die Replikation einmal unterbrochen werden, sollte man mit „slave stop“ erst mal den Replikations Prozess beenden. Mit „slave show status\G“ kann man sich dann den Status ausgeben lassen. Hierbei sollte man jetzt auf die Zeile „Last_Error:“ achten. Die dort ausgegebene Fehlermeldung sollte man nun genauer untersuchen und versuchen festzustellen warum es zu diesen Fehler kam. Hat man diesen dann beseitigt kann man mit „SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;“ MySQL anweisen, dieses Query zu überspringen. Anschließend kann man mit „slave start“ die Replikation wieder starten. Wenn alles gut läuft und dies der einzigste Fehler war, müsste diese nun auch wieder laufen.

Master – Master

Bei einer Master-Master-Replikation, gibt es, wie der Name schon sagt, 2 Master. Beide sind sich gegenseitig aber noch Slave. Sodas Änderungen auf einen Master direkt auch auf dem 2. Verfügbar sind und umgekehrt. Bei Master Slave kommen Update immer nur von einer Seite, vom Master. Hier kann jeder der beiden Änderungen machen. Dies führt natürlich auch zu Probleme. Was ist, wenn beide den gleichen Datensatz Ändern wollen? Deswegen muss man hier sehr auf die Daten-Integrität achten und am besten immer nur einen der Beiden Master schreiben lassen.

Aufbau einer Master-Master-Replikation

Es muss hier auch wieder auf beiden Server von den Gleichen Daten ausgegangen werden. Auf beiden das „binlog“ aktiviert sein. Dann kann man auf beiden jeweils einen Slave-Prozess einrichten, welcher den anderen Als Master nimmt.

Der Aufbau von MySQL ist recht Simple. Die einzige Konfigurationsdatei liegt in „/etc/mysql/“ und heißt „my.cnf“. Hier lassen sich nun die verschiedenen Laufzeitoptionen von MySQL einstellen. Zum Beispiel auf welchen Port und welchen Interface es laufen soll. Aber auch wieviel Puffer und Speicher MySQL verwenden soll. Die eigentlichen Daten von MySQL werden dann in „/var/lib/mysql“ gespeichert. Das Rechte-Management von MySQL wird über eine MySQL-Datenbank mit dem Namen „mysql“ gesteuert.

„my.cnf“

Die „my.cnf“ ist in mehrere Teil gegliedert. Jeder Teilbereich wird durch den Namen eckige Klammer abgegrenzt. Der wirklich wichtige Bereich ist „[mysqld]“. Dort stehen die Optionen welche für den MySQL-Prozess wichtig sind. Hier man eine gute Grundkonfiguration:

Server Basics

Am Anfang sollte man immer Grundlegende Dinge festlegen. Wie z.B. den Buntzer, unter welchen MySQL laufen soll. Soll es an eine IP gebunden werden? Welcher Port verwendet werden soll. Wichtig für die Replikation ist dann auch immer eine eindeutige „server-id“. Oft ist es auch sinnvoll „Selects“ eine höhere Priorität zu geben. „skip-locking“ sollte auf jeden Fall aktiviert sein, da sonst die Performance massiv einbrechen kann. Ohne diese Option werden recht rechenintensive Methoden verwendet, Tabellen von der Festplatte zu lesen.

Server Verzeichnisse und Logdateien

Im weiteren Verlauf der Konfig werde meist noch mehrere Verzeichnisse und Log-Dateien definiert. Diese sind selbsterklärend. Einzig auf das „bin-log“ sollte man genau achten, da darüber die Replikation abläuft. „datadir“ ist, wo die Tabellen auf der Festplatte abgelegt werden.

Puffer und Caches

MySQL hat verschiedene Cache-Funktionen und Puffer. Manche sind nur auf Verbindungsebene aktive, wieder andere serverweit. Aber es geht auch, das man auf seiner Verbindung den Cache/Puffer neu definiert und so den Serverweiten überschreibt, für seine Verbindung. Cache und Puffer kann man nie pauschal festlegen. Sie müssen auf die jeweiligen Anwendungen angepasst werden, welche mit der Datenbank arbeiten sollen.

Bei „max_connections“ handelt es sich um die Anzahl der offenen Verbindungen, oder eingeloggten Benutzer wenn man so will.

„open_files_limit“ gibt an, wieviele Dateien der MySQL-Prozess gleichzeitig öffnen darf.

„long_query_time“ wird in Sekunden angegeben. Es definiert ab welcher laufzeit ein Query als „slow query“ eingestuft wird.

„thread_cache_size“ gibt die Anzahl der Threads an, welche zurückgehalten werden.

„query_cache_szie“ legt die Größe des Speichers für SELECT-Querys fest.

„query_cache_limit“ besagt, das Querys, welche größer als das Limit sind, nicht gecached werden sollen.

„table_cache“ gibt die Anzahl an Tabellen vor, welche im Speicher gehalten werden sollen.

„max_heap_table_size“ gibt an, wie groß eine Tabellen sein darf, welche temporär im RAM erzeugt wird.

„tmp_table_size“ legt die gesamt Größe des Tabellen-Cache fest.

„read_buffer_size“ ist für das sequenzielle auslesen von Tabellen zuständig. Werte größer als 512 KB bringen kaum mehr Performance.

„key_buffer_size“ legt die Größe des Speichers für die MyISAM Key-Files der Tabellen fest. Man sollte möglichst versuchen viel davon im Speicher zu haben.

„read_rnd_buffer_size“ ist für nicht-sequenzielle und parallele Zugriffe auf Tabellen zuständig.

„join_buffer_size“, wie der Name schon da, um bei „joins“ zwischen zu speichern.

„sort_buffer_size“, beim Sortieren ist dieser Puffer wichtig.

Blogparade: Wie 1.0 bist du?

CDs oder mp3-Player?

Festnetz oder Mobiltelefonie?

Handy oder Smartphone?

Notebook oder Tablet-PC?

Buch oder E-Book-Reader?

Buch oder Hörbuch?

Brettspiel oder Spiel-Konsole?

Tagebuch oder Weblog?

Bargeld oder EC-Karte?

Poesiealbum oder Social Network?

Kabel-/Satelliten-TV oder IpTV?

Videothek oder Online-Videothek?

Ladengeschäft oder Online-Shop?

Brief oder E-Mail?

Urlaubspostkarte oder MMS?

Straßenkarte oder Navigationsgerät?

Duden oder Online-Duden?

Pizza-Zettel mit Anruf oder Online-Pizza-Bestellung?

Briefmarke oder Online-Frankierung? (achtung Werbung: ePostbrief XD )

Papierrechnung oder Online-Rechnung?

Und zuletzt: mehr offline oder mehr online?

Und nun zum spannenden Ergebnis: Mit 19 Punkten in Sachen 2.0 und 2 in 1.0 …

1. Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden. Eine Bestätigungsmeldung ist erforderlich.

2. Mailserver hat die Anforderung erfolgreich ohne Fehler ausgeführt.

3. Mailserver hat die Anforderung verstanden, benötigt aber zur Verarbeitung weitere Informationen.

4. Mailserver hat einen temporären Fehler festgestellt. Wenn die Anforderung ohne jegliche Änderung wiederholt wird, kann die Verarbeitung möglicherweise abgeschlossen werden. Versuchen Sie es erneut, vielleicht funktioniert’s!

5. Mailserver hat einen fatalen Fehler festgestellt. Ihre Anforderung kann nicht verarbeitet werden.

Die zweite Zahl geht ins Detail. Es gibt sechs mögliche Werte:

0. Syntax Fehler

1. Antwortinformation

2. Diese Zahl bezieht sich auf den Status der Verbindung

3. Wird nicht benutzt

4. Wird nicht benutzt

5. Diese Zahl bezieht sich auf den Status des Mailservers

Die dritte Zahl geht noch stärker ins Detail als die zweite. Sie zeigt in feineren Stufen den Status des Mailtransfers. Die Kombination dieser drei Zahlen ergibt die detaillierte Liste der ESMTP Server Antwortcodes, wie sie im RFC 821 und später festgelegt wurden.

Gängige Fehlercodes bei Mailservern

]]> http://www.zero0ne.de/2011/07/spamassassin/feed/ 0 http://www.zero0ne.de/2011/07/calmav/ http://www.zero0ne.de/2011/07/calmav/#comments Mon, 25 Jul 2011 12:38:32 +0000 zer(o_0)ne http://www.zero0ne.de/?p=3190 ClamAV

ClamAV ist ein freier OpenSource Virenscanner. Er ist der de-facto Standard in Linux-Mailsystemen. Er wird auch über AMaViS angesteuert. Sollte ClamAV etwas verdächtiges finden, reportet er dies an AMaViS zurück, welches dann die Mail aus dem Verkehr zieht. ClamAV verfügt über einen automatischen Update-Mechanismus, sodass er selbst dafür sorgt, das seine Bibliotheken immer aktuell sind. Um ClamAV über AMaViS zu aktivieren, muss man in der AmaViS Konfiguration „15-content_filter_mode“ die beiden „@bypass“-Regeln aktivieren. Danach kann ClamAV über AmaViS angesprochen werden.

Ein weiteres Support-Programm außerhalb von Postfix ist AMaViS. Im eigentlichen steht AMaViS für A Mail Virus Scanner. Doch kann es mehr als nur Mails auf Viren zu prüfen. Mittlerweile ist es auch ein Spam und Maleware-Scanner. Dazu behilft sich AMaViS selbst wieder mit 2 weiteren Programmen. Dies ist einmal ClamAV, der OpenSource-Virenscanner und als zweites wird Spamassassin zum scannen nach Spam verwendet.

AMaViS fungiert dabei selbst als Mini-Mailserver. Dieser läuft dann nur auf Localhost auf Port 10024. Postfix macht auch noch einen Port auf, und zwar Port 10025 nimm man dort üblicher Weise. Die beiden schicken sich dann die Mails über diese beiden Ports hin und her. Das funktioniert dann so: Postfix nimmt eine Mail an, führt seine bisherigen Checks durch, Greylistet evtl., besteht diese Mail die Test, wird sie an AMaViS weitergereicht, aber noch nicht endgültig angenommen. Dieser übergibt sie dann direkt an ClamAV, wo sie nach Viren durch-scannt wird. Werden Viren gefunden, wird Postfix angewiesen die Mail abzuweisen. Werden keine Viren gefunden wird dann auf Spam geprüft. Hierbei werden verschiedene Techniken benutzt, einmal wird der Text gegen eine Datenbank mit oft vorkommenden Spammeldungen geprüft, andererseits wird auch auf das vorkommen von Links und die Formatierung der Links geachtet. Das Ganze läuft in einen Scorering zusammen, was in den Header geschrieben wird. Liegt der Score zwischen 0 und 5.00 wird die Mail meist als kein Spam klassifiziert oder höchstens als verdächtig im Betreff getagt. Liegt er drüber, wird er meist entweder ins Quarantäne-Postfach umgelenkt oder besser gleich Postfix angewiesen die Mail abzulehnen. Wenn die Mail hier ohne Weiteres durchkommt, wird sie wieder an Postfix übergeben und weiterverarbeitet. AMaViS und Spamassassin kennen natürlich auch wieder White- und Blacklists. Um gewisse Domains von vorhnherein zu erlauben oder zu verbieten. Auch kann man in der AmaViS-Konfiguration in „/etc/amavis/local.cf“ und den danebenliegen Konfigurationsdateien das Verhalten noch anpassen. Eben solche Dinge wie, ob Mails abgelehnt oder in Quarantäne verschoben werden.

AMaViS kann in der Konfiguration von Postfix auf zwei Arten aktiviert werden. Entweder über „content_filter“ oder über „smtpd-proxy“. Logisch gesehen machen die beiden Direktiven das selbe, nur technisch gesehen gibt es einige Unterschiede. Wir werden zu Anfang noch „content_filter“ verwenden. Dies ist die bekannte und getestet Lösung. Es ist jedoch geplant auf „smptd_proxy“ umzusteigen. Diese bietet technische gesehen einige Vorteile in der Abarbeitung der Mails.

AMaViS wird nun also per content_filter eingebunden. Dies ist ein eigener Parameter und steht außerhalb der bis jetzt verwendeten smtpd_recipient_restrictions. In einer eigene Zeile wird einfach „content_filter = amavis:[127.0.0.1]:10024 “ in der main.cf eingefügt. Nun muss aber noch zusätzlich in der master.cf ein weiterer Eintrag ganz am ende der Datei hinzugefügt werden, da es sonst nicht funktioniert. Denn man muss Postfix noch sagen, das es zu Port 10024, den AMaViS aufmacht, den korrespondierenden Port 10025 aufmachen soll.

Courier stellt im Mailserver-Konstrukt den Zugang für den Benutzer zu seinen Mails dar. Courier ist dabei auch wieder ein Multi-Server, da er 4 Services auf einmal stellt. Courier ist eine IMAP, IMAP-S, POP3 und POP3S Server. Wobei das S immer für Secure stehen soll, hießt eine SSL-verschlüsselte Verbindung genutzt wird. Was Courier an Standard Einstellungen mitbringt kann man eigentlich so weiter nutzen. Das einzige wobei man etwas nachjustieren muss ist der Wert für „MAXDAEMONS“ und „MAXPERIP“. Dies legt einerseits fest, wie viele Threads für den entsprechenden Server erstellt werden und andererseits wie oft man sich von der gleichen IP aus einloggen darf. Courier benutzt für die verschiedenen Protokolle die Standardports. D.h. für IMAP 143, für IMAPS 993, für POP3 110 und für POP3S 995. Diese lassen sich in den Konfigs von Courier aber auch ganz leicht anpassen.

Courier und SSL

Was man weiterhin beachten sollte ist, das Courier IMAP und POP3 eigene SSL Zertifikate verwenden. Mann kann diese aber einfach gegen seine eintauschen. Muss dann aber auch wieder darauf achten das diese im PEM-Format vorliegen und auch das CA-Bundle eingebunden wird. Tut man dies nicht, werden die Benutzer beim abholen der Mails über gesicherte Verbindungen darauf hingewiesen, das man ein selbst unterschriebenes Zertifikat benutzt. Dies wird allgemein als unsicher erachtet, was aber nicht immer der Fall sein muss. Die Zertifikate liegen standardmäßig im selben Verzeichnis wie die Konfigurationsdateien. Man kann diese aber auch woanders ablegen, muss dann aber in der „IMAP-SSL“-Konfig den Pfad zu diesen korrigieren. Das CA-Bundle bindet man mit der Option „TLS_TRUSTCERTS“ ein. Gleiches gilt natürlich auch für POP3-SSL.

Hauptseite:

www.zero0ne.de

Profil:

www.RobertWaffen.de

What if radioactive mutant vampire zombie robots from outerspace attack?!

www.rmvzrfo.de

Twitter-Archive

twitter.zero0ne.de

Stuff-Archive

stuff.zero0ne.de

Keine Hektik mehr beim Ticketkauf. Keine unfreundliche/langsamen Mitarbeiter am Schalter (obwohl diese auch ihre Vorzüge haben. z.b. Angebote raussuchen). Kein Stress mit dem Kartenautomaten der das Geld/die Karte nicht annehmen will. Kein Stress mehr mit dem Drucker, welcher das online-ticket nicht ausdrucken mag!

Alles “on the go” mit dem iPhone! (od. Ähnlichem Smartphone)

Einziges Problem jetzt: der Akku geht vor der Kontrolle in die Brüche! In der Sache sind analoge Tickets auf toten Bäumen echt vorteilhaft!

Lustig: wie verdutzt so mancher Schaffner ist. Er ist es gewohnt irgendwo mit seiner Kontrollzange reinzuknipsen… Doch nun geht das nicht mehr. Man sollte ihn auch daran hindern es zu versuchen ;-)

]]> http://www.zero0ne.de/2011/07/deutsche-bahn-21th-century/feed/ 0 http://www.zero0ne.de/2011/07/x-japan-04-07-2011-berlin/ http://www.zero0ne.de/2011/07/x-japan-04-07-2011-berlin/#comments Wed, 06 Jul 2011 22:16:00 +0000 zer(o_0)ne http://www.zero0ne.de/?p=2431 Nach Jahren des Wartens war es dann letzten Montag (04.07.2011) soweit: X Japan traten in Deutschland auf! Vor Jahren hatte ich mir immer schon vorgestellt wie toll es sein musste diese einmal live zu sehen. Doch hatten sie sich zu dieser Zeit schon getrennt gehabt. 1998, ein Jahr bevor ich auf sie aufmerksam wurde, hatten diese sich aufgelöst. Und als wäre das schon nicht schlimm genug gewesen verstarb hide (einer der beiden Gitarristen) auf sehr unglückliche und tragische Weise. Er ist unersetzbar und wird von der Band selbst bis heute als Mitglied aufgeführt und auf jeder Tour während der Eröffnung mit genannt. Als dann 2007 die Wiedervereinigung bekannt wurde war meine Freude kaum zu bremsen. Es würde neue Lieder geben und auch sehr bestimmt eine neue Tour. Diese lies leider auf sich warten. Erst wurde wieder nur der asiatische Raum betourt und letztes Jahr dann die Staaten. Kurz nach Karneval surfte ich zufällig auf einen Ticket-Portal, dort viel mir an diesem Morgen ein rotes X umschlungen von einem Drachen ins Auge. Ich konnte es kaum fassen. Dachte mir, das kann doch nicht war sein. Doch das war es! X Japan hatten sich für Deutschland angekündigt. Darauf mussten meine Kollegen an diesem Tag ein wenig leiden. Eine meiner besten Freundinnen warf es aber total aus dem Alltag. Nicht aus Freude, sondern weil an diesem angekündigten Montag schon ihr Auslandsurlaub begonnen hätte. Mit ein wenig Recherche (Züge/Flieger usw.) und Unterstützung eines Freundes haben wir sie aber dann doch noch zum Konzert mitbekommen. Ihren Urlaub leicht verschoben, ihr leben wieder aufgehellt.

Das ist nun wieder eine ganze Weile her. Letzten Montag war es dann wie gesagt so weit. Am Freitag davor reisten wir nach Paderborn, um noch einen weiteren Freund einzusammeln. Samstag sahen wir dann schon mal zur Einstimmung verschiedene Tour-Videos aus vergangenen Tagen. Die „Blue Blood“-Tour, die „Dahlia“-Tour, den „hide memorial summit“ und abschließend die „Last Live“-Aufzeichnung. Sonntag ging’s dann mit X Japan in den Ohren auf nach Berlin. Dort angekommen sammelten wir noch einen weiteren Freund ein. Somit waren wir nun zu viert und komplett. Also auf ins Hostel… Nach der Zugfahrt waren wir echt kaputt und deshalb gab’s nur noch was zu essen und ein wenig Musik und Kartenspielen. Man will sich ja nicht schon vor dem Konzert zu sehr verausgaben. Die Nacht war dann doch eher unruhig. Ob nun wegen der Aufregung oder wegen des Lärmes auf der Straße. Oder auch des Gewitters…

Montag, einer der wenigen Momente im Leben wo man sich auf einen Montag freut.! Leider sehr verregnet. Aber es sollte ja ein Hallen-Konzert werden. Davor waren wir noch mal im nahe gelegenen “Neo Tokyo”, wo wir auch schon die ersten anderen Fans trafen. Abends dann mit der U-Bahn auf zur Columbia Halle! Dort warteten auch schon sehr viele auf Einlass. Es kamen immer noch mehr, amn konnte aber auch sehen, das einige schon länger hier campiert hatten. Der Einlass war dann pünktlich um 19:00 Uhr. Schnell und ohne Probleme waren auch schon die ersten drin. Gegen 19:25 waren dann auch schon alle in der Halle.Das ging ich echt flott! Hier begann dann erst mal der Sturm auf den T-Shirt-Stand. Dieser hielt der Masse an Fans aber sehr gut stand, hatte genug für alle.
Dann, kurz nach 20:00 Uhr, ging es los. Die Band wurde mit einem neuen Intro angekündigt und kam nach und nach auf die Bühne. Laut umjubelt ging es auch gleich mit dem neuen Song “Jade” los. Darauf folgten Klassiker wie “Rusty Nail”, “Silent Jealousy” oder “Kurenai” (in der englischen wie in der japanischen Version). Zwischen durch wurde immer wieder unterbrochen um das ein oder andere Solo zu spielen. Yoshiki und Sugizo hatten so die Bühne jeweils oder zusammen für sich allein. Sugizo ist der Band als „Aushilfe“ für hide beigetreten. Hide werde nicht ausgetauscht oder ersetzt, Sugizo vertrete ihn nur. Was weiterhin aber in der Setlist nicht fehlen durfte war “X” mit der Aufforderung an das Publikum immer wieder “X” zu schreien… “We are…?!?” – “X!!!” … „You are….?!?“ – „_X!!!“. Dies ist eigentlich immer Toshi’s Part, aber Yoshiki schnappte sich auch immer wieder das Micro und schrie so laut er konnte “We are?!?!”. Auch sehr Genial war “Endless Rain”, wo das Publikum fehlerfrei und lautstark mitsang. X Japan überlies dann auch lange das Singen allein dem Publikum und zog den Song so in die länge. Was aber echt super war! Abgeschlossen wurde das Konzert mit “Art of Life”. Yoshiki bedankte sich im Namen von X Japan bei allen Fans, sprach über hide, dessen Tod und die Trennung der Band. Er meinte der wahre Grund für die Wiedervereinigung waren einzig allein die Fans. Der Satz des Abends war aber als, Yoshiki sagte das sie zum ersten mal Currywurst gegessen hatten und es super gewesen sei : “X Japan will Return for Curry Wurst!!!!!” Dann wurde die Band frenetisch verabschiedet, diese macht auch noch von der Bühne aus Bilder von sich und dem Publikum, verbeugte sich und räumte die Bühne.

Alles in allem war es wirklich ein super Konzert! Man kann es aber nicht mit den Mega-Shows aus Japan vergleichen. Dort sind sie gewohnt nicht vor weniger als 10.000 Menschen aufzutreten. In Japan schaffen sie es auch ein 140.000 Personen Stadion zu füllen – an drei Tagen am Stück! Hier in Berlin waren es gerade einmal 3.600! Und dabei wurde auch hier schon in eine größere Location umgesiedelt. Man kann also sagen das dies eher eine Club Tour für X Japan war ;) .

Einzig negativ aufgefallen war, das ab ungefähr der Mitte des Konzerts der Sound sehr blechern und verzerrt wurde. Auch war Toshis Stimme viel schlechter zu hören und man hatte das Gefühl Sugizo’s Gitarre überstimmte alles. Irgendwer hatte sich da wohl an den Reglern vertan.

Es war aber trotzdem echt super X Japan nach so langer Zeit endlich einmal live sehen zu können. Es wurde eine super Show abgeliefert und auch sehr gut mit dem Publikum interagiert. Ich freue mich darauf, sie hoffentlich bald noch einmal sehen zu können!

Hier die komplette Setlist (von X-Plosion-Online.com )

01) Intro
02) Jade
03) Rusty Nail
04) Silent Jealousy
05) Drain
06) SUGIZO Violin Solo
07) Kurenai (english & japanese Version)
08) Born To Be Free
09) YOSHIKI drums & piano solo
10) I.V.
11) X
— Break
12) Forever Love (Short Version)
13) Endless Rain
14) Art of Life (started from piano solo)

Hier dann noch zwei Videos vom Konzert:

Ausschnitt – Rusty Nail

Abschied von X Japan

Sehe mir schon den ganzen Abend verschiedenen Live Aufzeichnungen an um mich ein wenig einzustimmen. ( Meine Lieblingslieder –  das komplette Blue Blood Album )

Hier mal ein Aufzeichnung von “X” aus Yokohama:

master.cf

In der „master.cf“ kann man eigentlich das meiste so lassen wie es ist. Selten besteht bedarf hier etwas zu ändern. Definiert sind hier alle Subprozesse von Postfix und deren Optionen. Z.B. kann man hier einen weiteren SMTP-Port definieren um die Übergabe an Amavis zu regeln. Auch kann man hier schon Checks durchführen, bevor die Mail überhaupt richtig angenommen wurde. Dies sollte man in der Regel aber der „main.cf“ überlassen.

main.cf

Die „main.cf“ definiert wirklich alles weitere, was über die Helfershelfer und die Ports hinausgeht. Unter anderen z.B. Wie sich der Server nennt, auf welche Domains er achten soll, welche Annahmechecks durchgeführt werden, verschiedene Limits und wo die Mailboxen liegen. Mit zusätzlichen Modulen kann man die Mailboxen auch über MySQL definieren. dazu bedarf es dann noch einiger Helfer-Konfigurationen. Diese sind aber selbsterklärend, da in ihnen nur eine MySQL-Verbindung und ein SELECT steht. Neben den ganzen Laufzeit- und Domaineinstellungen sind hier aber die Annahmechecks am wichtigsten. Es gibt verschiedene Level von „restrictions“ in denen man filtern kann. Am meisten Sinn macht aber eigentlich nur „smtpd_recipient_restrictions“.

Hier ein Beispiel wie die „restriction“ aussehen könnte:

smtpd_recipient_restrictions =
# Keine unsauberen Mails annehmen
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
# eigene saeuberung der adresse
check_recipient_mx_access cidr:/etc/postfix/mx_access,
check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
check_helo_access hash:/etc/postfix/helo_blacklist,
# Eiegne Nutzer erlauben
permit_sasl_authenticated,
permit_mynetworks,
# SPAMSCHUTZ RBLs
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.njabl.org,
# relay-empfaenger
reject_unverified_recipient,
# backup MX
permit_mx_backup,
reject_unauth_destination,
permit

Von oben nach unten erklärt:

Am Anfang wir geprüft ob der Absender eine Voll qualifizierte Domain-Adresse hat. Anschließend wird geprüft ob die Domain bekannt (erreichbar) ist. Mit MX-Access wird geprüft ob der Absender aus einen Gültigen IP-Netz kommt. Hierauf wird dann geprüft, ob die Mail vom Aufbau her stimmt, also z.B. ob genau ein „@“ darin enthalten ist. Mit der Regel „check_helo_access“ wird überprüft ob jemand versucht mit der IP des Servers aber einer anderen, nicht bekannte Domain, Mail einzuliefern. Anschließend erlaubt man das per SASL authentifizierte Benutzer Kontakt zum Server aufnehmen dürfen. Weiterhin werden auch die eigenen IPs erlaubt, sodass man sich nicht selbst aussperrt. Danach wird mit „reject_rbl_*“ verschiedenen „DNS Black Lists“ abgefragt, ob der einliefernde Mailserver nicht schon für Spam bekannt ist. Anschließend werden Mails abgewiesen, welche einen unbekannten Empfänger haben. Letztendlich wird noch erlaubt das ein Backup-MX erlaubt. Es wird dann noch verboten, das an Adressen versendet wird, welche nicht erlaubt sind oder nicht existieren. Abschließen wird noch alles erlaubt was bis jetzt nicht verboten ist.

RBL im Detail

Auszug aus der Wikipedia (http://de.wikipedia.org/wiki/Realtime_Blackhole_List, 13.10.2009):

Als Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) werden in Echtzeit (realtime) abfragbare Schwarze Listen bezeichnet, die verwendet werden, um E-Mail zweifelhafter Herkunft als Spam zu klassifizieren. In den meisten RBLs werden IP-Adressen von Rechnern gelistet, von denen in der Vergangenheit Spam versendet wurde – einige Listen enthalten auch Quellen von Computerviren und anderer Malware. Heute handelt es sich bei diesen Rechnern meist um trojanisierte PCs oder seltener offene Mail-Relays, die von Spammern missbraucht wurden. Diese Listen können Mailserver oder Spam-Erkennungssoftware (z. B. Spamassassin) beim Eingang einer Mail nahezu in Echtzeit über das DNS-Protokoll auswerten und bei positivem Ergebnis die Annahme der Mail verweigern, die Annahme der Mail verzögern (Teergrube, Greylisting) oder die Mail so markieren, dass sie ohne großen Aufwand vom Empfänger gefiltert werden kann.

Es werden die Listen von Spamhaus.org, NiXSpam (Liste der iX), SpamCop.net und NJABL.org empfohlen. Diese haben sich in der Vergangenheit als sehr zuverlässig erwiesen und einen geringen Anteil an False-Positives.

postconf

Will man sich die Konfig welche gerade geladen ist noch einmal ansehen, kann man dazu das Kommando „postconf“ nehmen. Mit „postconf -d“ kann man sich alle Defaulteinstellungen anzeigen lassen. Dies gibt sehr viel Output, da wirklich fast jede Variable ausgegeben wird. Übersichtlicher wird das ganze wenn man „postconf -n“, welche Variablen anzeigt, welche nicht defaultmäßig belegt sind. Also verändert wurden. Neben dem Anzeigen der Konfigs, kann man mit postconf auch Variablen setzen. Dazu gibt man „postconf -e ‘PARAMETER=WERT’ “.

postqueue

Mit dem Kommando „postqueue“ kann man sich die Warteschlange des Servers ansehen. Hier liegen Mails die noch nicht versendet wurden, oder zurück kamen und auf einen erneuten Zustellversuch warten. Dabei kann man sich die Queue ansehen und auch einen erneuten Zustellversuchen veranlassen. Anzeigen kann man sich die Queue mit „postqueue -p“. Dabei wird dann angezeigt, welche ID die Mail hat. Dies ist wichtig wenn man in Logdateien danach sucht. Weiterhin wird auch angezeigt, welche Größe die Mail hat, wann sie ursprünglich eintraf und von wem an wen sie gesendet wurde. Hängt man den noch ein „-v“ an, bekommt man noch einige Debug-Meldungen ausgegeben. Gibt man mehr V’s an, werden noch mehr Ausgaben produziert. Mit „postconf -f“ veranlasst man Postfix dazu, alle Mails in der Queue noch mal versuchen zu versenden. Mit „postqueue -i ID“ veranlasst man Postfix genau die Mail mit der übergebenen ID nochmals zuzustellen. Weiterhin kann man dann auch noch mit „postqueue -s Domain“ den erneuten Versandt aller Mails dieser Domain zu veranlassen. Was postqueue nicht kann, ist das löschen einer Mail aus der Queue.

postsuper

Da postqueue keine Mails löschen kann, nimmt man „postsuper“. Dieses ist zur Queue-Steuerung da. Man kann Queue-Mails löschen, in eine Queue stecken oder sie auch wieder herausholen. Will man also eine Mail aus der Queue entfernen gibt man „postsuper -d ID“ an. Will man die gesamte Queue löschen nimmt man „postsuper -d ALL“. Wobei darauf zu achten ist, das das „ALL“ auch wirklich groß geschrieben wird, da es sonst nicht klappt. Hinter dem ALL kann man auch noch eine Queue angeben. Muss man aber nicht. Man kann auch eine Mail auf „on Hold“ setzten. das heißt sie temporär stoppen. Das tut man indem man „postsuper -h ID“ eingibt. Auch hier trifft wieder das mit ALL und der optionalen Queue Angabe zu. Um die Mail wieder weiterzubearbeiten holt man sie mit „postsuper -H ID“ wieder ins aktive System.

Das Postfix-Log

Postfix schreibt im normal Fall unter „/var/log/“ seine Log-Dateien. Hierbei schreibt es immer 4 Logs parallel. Einmal all-umfassend „mail.log“. Hier steht alles drin was Postfix und seine Helfershelfer so von sich geben. Dann gibt es noch die drei Dateien „mail.info“ , „mail.warn“ und „mail.err“. Hier stehen dann entsprechend der Namen jeweils nur die Logs vom Level Info, Warning und Error drin. Die Logs werden dabei immer ungefähr 10-14 Tage in 8 Versionen vorgehalten.

pflogsum

„pflogsum“ erstellt aus dem Logfile von Postfix eine Zusammenfassung. Wie viele Mails prozesst wurden, wie viele abgelehnt und geblockt. Welche SMTP-Fehler auftraten. Top-Senden und Top-Empfänger. Wie die Verteilung der Mails über den Tag hinweg waren und noch andere statistische Werte. Damit kann man den Mailserver ein wenig im blick behalten und frühzeitig Fehler erkennen. Ein aufruf von „pflogsum“ für normaler Weise zur Ausgabe in der CLI. Man kann das Ganze aber auch in eine Mail umleiten und dann per Cronjob einmal am Tag versenden lassen.

pflogsumm --rej_add_from --problems_first --smtpd_stats -h 15 -u 15 --no_reject_detail --no_smtpd_warnings -d today /var/log/mail.log | mail -s "Mailserver Report - `date`" monitoring@domain.de

Service-Liste:

• Postfix SMTP-Server
• AmaVis
  • Spamassasin
    • pyszor
    • dcc
    • bayes
  • ClamAV

• Courier
  • IMAP-Server
  • POP3-Server

Schematischer Aufbau:

Annahme Von E-Mails

Kommen E-Mails vom Internet aus am Mail-Server an, werden diese zunächst angenommen und dann geprüft. Zu erst wird der Aufbau der E-Mail geprüft. Ist dieser nicht FQDN-Konform wird die E-Mail abgewiesen, da FQDN-Unkonforme (FQDN = Full Qualified Domain Name = Standardmäßiger Domainname) E-Mails nicht im Internet vorkommen, außer sie werden von Spammern verwendet. Danach wird geprüft ob der einliefernde Mailserver per Reserve DNS und EHLO-Check legitim ist. Darauf wird dann noch geprüft ob der Empfänger FQDN-konform ist. Ist dies der Fall wird die IP des einliefernden Servers gegen verschiedene Spam-Listen getestet. Sollte dies positiv sein, wird die E-Mail abgewiesen. Ist das Ergebnis negativ wird die E-Mail an AMaViS übergeben. Dieser durch-scannt mit Hilfe von Spamassassin die E-Mail nach Spam-Merkmalen. Auch wird durch AMaViS die E-Mail auf Viren geprüft. Dies geschieht mit Hilfe von ClamAV. Wenn die E-Mail dann letztendlich auch diese Prüfungen bestanden hat, wird sie auf die Festplatte ins MailDir des betreffenden Empfängers gespeichert. Dort liegt sie dann als simple Textdatei vor.

Nun kann sie durch ein Mailprogramm abgerufen werden. Dies geschieht indem das Mailprogramm zu Courier eine Verbindung aufbaut und nach neuen Mails fragt. Courier biete dazu die Protokolle POP3 und IMAP an. Darüber werden dann die als Textdateien gespeicherten E-Mail aus dem Maildir ausgelesen und an das Mailprogramm gesendet.

Versenden von E-Mails

Vor dem Versenden durch den SMTP-Server wird die E-Mail wieder auf Viren und Spam geprüft. Ein Greylisting findet in diese Richtung nicht statt. Die Anti-Spam-Listen werden in diese Richtung auch nicht abgefragt. Im Anschluss wird die Mail wieder darauf geprüft ob Sender- und Empfänger-Adresse FQDN-konform sind. Auch wird noch geprüft ob der empfangende Mailserver legitim ist. Passiert die Mail die Tests wird sie vom SMTP versendet.

Früher oder später bekommt mich Steve immer rum seinen Shice zu kaufen XD

Mit Nginx kann man das in folgender Weise realisieren:

Immer WWW:

if ($host != ‘www.domain.de’ ) {
rewrite ^/(.*)$ http://www.domain.de/$1 permanent;
}

Ohne WWW:

if ($host != ‘domain.de’ ) {
rewrite ^/(.*)$ http://domain.de/$1 permanent;
}

Falls man aber noch mehrere Subdomains unterhalb seiner Domain fährt, sollte man dies etwas anders gestalten:

if ($host = ‘www.domain.de’ ) {
rewrite ^/(.*)$ http://domain.de/$1 permanent;
}

Summa Summarum kann man sagen, eine gut überarbeitet Version des ersten iPad, welche eigentlich den Namen iPad2 nicht verdient hätte. Für mich ist es eher ein iPad 1.5.