csshX

CsshX ist ganz nett auch wenn es gegenüber cssh noch einige Nachteile hat. zum Beispiel wen man mal so 20-30 Sessions aufbauen will. Sonst ist es aber echt gut. Benutze es auch mit dem Mac OSX Terminal zusammen und nicht mit iTerm2. Es gibt zwar auch schon eine iTerm2 Version, die funktioniert aber nicht so gut wie der für Terminal.

Terminal

Der Terminal ist eigentlich auch ganz ok. Man muss sich nur das Homebrew-Theme ein wenig anpassen und die Bild-Rauf und Bild-Runter Tasten unbelegten und schon kann man damit arbeiten. Die Tasten legt man sich dann am besten so:

Anfang: \033[1~
Ende: \033[4~
Seite nach oben: \033[5~
Seite nach unten: \033[6~

TextWrangler

Hab einen neuen Simplen Texteditor mit Syntax Highlighting gesucht, da Smultron auf Lion nicht so gut funktioniert und ich mir nicht die 4er Version davon kaufen wollte. Wollte dann auch ein wenig was graphischeres als Vim und hab mich nun mit Textwrangler angefreundet. Ein dunkles Theme eingestellt, die Farben ein bisschen angepasst und schon geht’s. Und um dann dieses nervige Gutter zu entfernen einfach im Terminal folgendes eingeben: “defaults write com.barebones.textwrangler Editor:Gutter -bool false”. Danach ist es weg, sollte man es doch mal wieder haben wollen, nimmt man einfach den gleichen Befehl und gibt am ende “true” ein.

ExpanDrive

Mit Expandrive kann man sich SSH-Server als Laufwerke mount’n. Aber nicht nur SSH, auch FTP und sogar Amazon S3 lässt sich so leicht einbinden. Eine entsprechend schnelle Internet/Intranet-Verbindung vorrausgesetzt kann man dann schnell Zugriff auf die Dateisysteme seiner Server nehmen und muss nicht immer über den Terminal gehen. So kann man dann zB mit TextWrangler die Configs direkt auf dem Server bearbeiten.

CoRD

Wenn man mit Windows Servern abreiten muss, muss man ja meist auch das RDP-Protokoll nutzen. VNC wäre zu umständlich zu konfigurieren, also doch lieber das eingebaute von MS nutzen. Es gibt zwar auch einen Client von MS selbst, dieser bietet aber wenig Komfort. Mit CoRD sieht es da schon ganz anders aus. Hier lassen sich Favoriten speicher mit allen Einstellungen. Geht mit dem MS-Tool vllt auch, aber findet man die Einstellungen dort schwer und sind nicht so schön dargestellt. CoRD ist schlicht und doch umfangreich und komfortabel.

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":}


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.

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.

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.

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.

Über die Connectoren kann Verbindung zum Tomcat aufbauen. Über den HTTP-Connector kann man, wie der Name schon sagt HTTP-Verbindungen aufbauen. Also der Port über den alle Webseiten ausgeliefert werden. Bei Tomcat ist dies defaultmäßig immer “8080“. Im Gegensatz zu Port “80“, welcher z.B. bei Apache2 genommen wird. Dies ist so, da Tomcat selten direkt als Webserver auftritt. Meist sind ihm immer noch Webserver vorgeschalten. Zum Beispiel Nginx per Reverse Proxy oder Apache2. Dieser verbindet sich meist über mod_jk. Damit kämen wir dann zum AJP-Connector. Dieser wird also zur kommunikation zwischen dem Apache2 Modul mod_jk und Tomcat benutzt. Das Protokoll ist ein binäres, es wird also kein HTTP gesprochen. Von jedem Connector kann es immer mehrere geben, jeweils natürlich mit unterschiedlichen Ports.

Die „server.xml“ ist im XML Stil ausgebaut. Alles wird mit Tags definiert. Alles umschließt das „<server>“-Tag. Innerhalb davon sind dann immer einige Listener und Resourcen definiert. Im weiteren Verlauf kommt dann das „<service>“-Tag. Darin enthalten sind die Connectoren für HTTP und AJP. Weiterhin noch das „<engine>“-Tag. Damit kann man den Standardhost für den Tomcat angeben, welcher genommen werden soll, wenn kein anderer passt. Darin enthalten ist dann einmal das Realm-Tag und dann noch das besagte „<host>“-Tag. Dieses entspricht grob den Vhosts beim Apache2-Webserver. Damit kann man Hostnames auf Applikationen mappen. Die „appBase“ (DocumentRoot) festlegen und weitere Feature zur Behandlung von Sourcecode. Innerhalb hiervon kann man wiederum „<context>“-Tags festlegen, welche dann die Applikationen noch genauer beschreiben und auch Domain-Pfade kennen. Und letztendlich kann man jetzt wieder „<resource>“-Tags anlegen, um der Applikation z.B. feste Datenbankverbindungen mitzugeben.

Applikationen kann man hier definieren, muss man aber nicht. Eine wesentlich dynamischere Variante wäre hier, die “context.xml” zu benutzten. Denn bei Änderungen an der server.xml muss danach der Tomcat neu gestartet werden. Benutzt man die “context.xml” braucht es zum einspielen keinen Neustart.

Baumansicht der Verzeichnisstruktur eines Tomcat 5.5

|– bin
|– common
| |– classes
| |– endorsed
| |– i18n
| `– lib
|– conf
|– logs
|– server
| |– classes
| |– lib
| `– webapps
| |– host-manager
| `– manager
|– shared
| |– classes
| `– lib
|– temp
|– webapps
| `– AG_Public
`– work
`– Catalina

Das Lib-Verzeichnis

Unterhalt „common“ liegt das Verzeichnis für die ganzen Libaries die Tomcat-weit genutzt werden können. Auf diese Libs haben alle Applikationen zugriff.

Das Konfigurationsverzeichnis „conf“

Hier liegen alle Dateien die Konfiguration betreffend. Wichtig sind hier die „server.xml“ und die „web.xml“. Will man die einfache HTTP-Auth von Tomcat nutzen, ist dann noch die „tomcat-users.xml“. Es gibt weiterhin noch eine weitere wichtige Konfig die aber im „bin“-Verzeichnis liegt. Das ist die „catalina.sh“. Hier kann man noch Startoptionen für die Tomcat-JVM einstellen. Z.B. Heapsize oder GarbageCollector.

Das WebApp-Verzeichnis

Hie liegt die eigentlich Applikation. Entweder als Verzeichnis oder als WAR-Datei. Es kann auch beides nebeneinander liegen, aber auch nur eins von beiden vorhanden sein. dies obliegt den Einstellungen in der „server.xml“. Wenn beides vorhanden ist, ist es meist auch so, das wenn man das WAR löscht, auch das Verzeichnis vom Tomcat selbst entfernt wird.

Das „work“-Verzeichnis

Hier lagert der Tomcat die ganzen compilierten Klassen, Servlets und JSP. Dabei wird alles im Unterordner „Catalina“ gespeichert. Hier wiederum wird das ganze noch nach Hosts aufgeteilt. In der Regel sollte bei einer Applikation, dann auch nur ein Verzeichnis mit Namen „localhost“ da sein. Hat man in der „server.xml“ mehrere Hosts definiert, findet man die hier alle wieder. Wenn man die Vermutung hat, das der Tomcat die neuen Sourcen, welche man gerade eingespielt hat, noch nicht übernommen hat, dann sollte man den Tomcat einmal stoppen, das „work“-Verzeichnis leeren und ihn dann wieder starten. Dann ist er gezwungen alles noch mal neu zu compilieren.

Um das Cacheing beim Apache zu aktivieren, muss man zum einen das allgemeine Cacheing Modul „mod_cache“ laden und dann eins für die Cacheing Methode welche man verwenden möchte. Also entweder „mod_disk_cache“ oder „mod_mem_cache“, wobei es auch geht beide zu laden. Es kommt eben immer darauf an wie man Cachen möchte. Entweder nur im RAM, oder nur auf der Festplatte, oder ein gemisch aus beiden. Eingebunden werden die Module über das Kommando „LoadModule Modulname Modul“. Für Cacheing würde das so aussehen:

LoadModule cache_module modules/mod_cache.so
LoadModule disk_cache_module modules/mod_disk_cache.so
LoadModule mem_cache_module modules/mod_mem_cache.so

In dem Zusammenhang ist es auch immer gut noch die Module für HTTP-Header und Expire-Steuerung zu aktivieren. Da auf diese beim Cacheing zurückgeriffen wird. Also zusätzlich dann noch:

LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so

All dies wird in die httpd.conf (evtl. auch apache2.conf) eingefügt. Nach einem Neustart des Apache sind die Module dann auch verfügbar. Hier nun die Allgemeinen Optionen für „mod_cache“:

„CacheEnable disk /“ aktiviert das Caching. „disk“ besagt hierbei das „mod_disk_cache“ benutzt wird und nicht „mod_mem_cache“. Das Slash besagt, das alles ab dem Domain-Root gecached werden soll. Also alles z.B. ab http://www.domain.tld/ . Man könnte also auch sagen, wenn man nur Teilbereiche seiner Website cachen will, das nur http://www.domain.tdl/archive/ gecached werden soll. Dies würde man mit „CacheEnable disk /archive/“ erreichen. Will man mod_mem_cache ansprechen muss man die Option entsprehende umformulieren: „CacheEnable mem /sites“. So wird alles unterhalb von domain.tld/sites/ in durch den Mem- Cache abgedeckt.

„CacheDisable“ kann das Caching für angegebene Domain.Pfade deaktivieren. Bsp.: „CacheDisable /sites/intern“.

„CacheDefaultExpire“ legt die Zeit für ein Dokument ohne Gültigkeitsdauer fest, bevor es verfällt. Also wenn eine Dokumente keinen „Expires“-Header hat. Der Standard-Wert liegt bei einer Stunde. Die Zeit wird in Sekunden angegeben.

„CacheIgnoreCacheControl“, ist diese Option gesetzt ignoriert Apache den „CacheControl“-Header des angeforderten Objektes und legt es trotzdem in den Cache, auch wenn „CacheControl: no-cache“ gesetzt ist.

„CacheIgnoreNoLastMod“ wird gesetzt wenn man ein Dokument ohne „Last-Modified“-Header hat, dies aber trotzdem in den Cache legen möchte. Der „Last-Modified“-Wert wird dann auf die aktuelle Zeit + den Wert von „CacheDefaultExpire“ gesetzt.

„CacheLastModifiedFactor“ legt das Verfallsdatum anhand von LastModified-Headers fest, wenn kein Expires- Header gesetzt ist. Dazu wird die aktuelle Zeit genommen, dann nachgeschaut, wie lange das Dokument schon nicht verändert wurde und dies dann mit dem Faktor multipliziert. Daraus ergibt sich zum Bsp. Bei einer seit 20h nicht mehr veränderten Datei und einen Faktor von „0,1“ eine Verfallszeit von zwei Stunden.

„CacheMaxExpire“ definiert wie lange ein Dokument ohne Prüfung aus dem Cache ausgeliefert wird. Ist die Zeit abgelaufen, wird es aus dem Cache genommen, selbst wenn der „Expires“-Header etwas anderes besagt.

mod_disk_cache

Will man nun für einen bestimmten Vhost das Disk-Caching aktivieren (gesamte Domain), muss man in dessen <VirtualHost>-Tag folgendes einfügen:

CacheEnable        disk /
CacheRoot            /var/cache/apache2/VHOSTname
CacheSize             307200
CacheDirLevels   3
CacheDirLength 2
CacheMaxFileSize   2097152
CacheMinFileSize    1024

„CacheRoot“ gibt an, wo auf der Festplatte das Verzeichnis liegt, in welchem Apache seine Cache-Dateien ablegent. Dieses Verzeichnis muss schon existieren, der Webserver wird es nicht selbst anlegen. Deshalb sollte man darauf achten, das auch die richten Zugriffsrechte gesetzt sind. Dieses Kommando gilt nur für „mod_disk_cache“.

„CacheDirLevels“ legt die Tiefe fest, bis zu welcher Ordner für Cache-Dateien angelegt werden sollen.

„CacheDirLength“ legt die Länge der Ordnernamen fest, in welchen die Cache-Dateien gespeichert werden. Die beiden Direktiven dienen zur Verwaltung der Cache-Dateien. So wird die Ordner Hierarchie festgelegt. So kann man die Größe des Cache regulieren und durch schlanke Verzeichnisstrukturen die Zugriffszeiten steigern. Dabei ist noch zu beachten, das CacheDirLevels * CacheDirLength < 20 sein sollte. Sollte dies nicht beachtet werden kommt es zu Instabilitäten oder sogar abstürzen des Apache.

„CacheMaxFileSize“ legt die maximale Größe einer Datei fest, welche in den Cache aufgenommen werden soll. Überschreitet eine Datei diese Größe wird sie nicht gecached. Im Bsp. Wird die max. Größe auf 2 MiB festgelegt.

„CacheMaxFileSize“ legt entgegen zu CacheMaxFileSize die minimal Größe einer Datei fest, welche in den Cache aufgenommen werden soll. Unterschreiten Dateien diese Größe, werden sie ebenfalls nicht gecached. Im Bsp. Wird die min. Größe auf 100 KiB festgelegt

„CacheSize“ legt einfach die Maximale Größe des gesamten Cache fest, der auf der Festplatte gespeichert werden soll. Läuft der Cache über, wird er durch das löschen der ältesten Dateien wieder auf seine maximal erlaubte Größe verkleinert. „mod_disk_cache“ hat dazu eine eigene Garbage-Collection-Funktion. Dabei wird auf das externe, aber zu Apache gehörende Tool „htcacheclean“ zurückgegriffen. Dieses Tool kann man auch selbst anstoßen oder durch Cronjobs zyklisch laufen lassen.

mod_mem_cache

Im Gegensatz zu mod_disk_cache, speichert „mod_mem_cache“ wie der Name schon sagt, die zu cachenden Inhalte im RAM des Servers. Auch sind hier wieder Angaben pro Vhost möglich. Für „mod_mem_cache“ gibt es 6 Optionen, die im Folgenden erläutert werden.

„MCacheSzie“ legt die Maximale Größe des Cache im RAM fest. Man sollte sie nicht allzu groß wählen, außer man hat genügend Hauptspeicher. Standardmäßig steht dies Option auf 100 KiB.

„MCacheMaxObjectCount“ legt die maximale Anzahl der Objekte im Speicher fest. Wird die Grenze erreicht, werden Objekte anhand der Option „MCacheRemovalAlgorithm“ entfernt.

„MCacheMaxObjectSize“ legt wie der Name schon sagt, die max. Größe eines Objektes fest. Sie entspricht der Option „CacheMaxFileSize“.

„MCacheMinObjectSize“ ist das Gegenteil der vorherigen Option und legt die minimale Größe eines Dokuments fest, welches im Speicher abgelegt werden darf. Es ist das Äquivalent zu „CacheMinFileSize“

„MCacheMaxStreamingBuffer“ legt den max. Buffer für Streaming-Antworten fest. Bei Streaming-Objekten ist die Gesamtgröße vorher nicht bekannt. Daher kann die Prüfung von „MCacheMaxObjectSize“ nicht stattfinden. Daher wird soviel wie „MCacheMaxStreamingBuffer“ festlegt, gepuffert und daran dann entschieden ob das Objekt zu groß ist für den Cache oder nicht. Wird diese Option nicht gesetzt, wird der Wert von MCacheSzie“ genommen. Aber dann nur ungefähr 98% davon.

„McacheRemovalAlgorithm“ bestimmt nach welchen Verfahren die Objekte aus dem Speicher entfernt werden. Dabei gibt es zwei Optionen. Einmal LRU und zum anderen GDSF. LRU beduetet hierbei Last Recently Used. Wie der Name schon vermuten lässt, werden so dann die am längsten nicht benutzen Objekte aus dem Cache entfernt. Bei GDSF, was Greedy-Dual-Size-Frequency heißt, werden die Objekte priorisiert. Die Priorisierung wird daran festgelegt wie Aufwändig eine Neu-Anfrage wäre und wie groß das Objekt ist. Objekte mit niedriger Priorität werden dann aus dem Cache entfernt.

Hier nun also das Skript:

#!/bin/bash
NAME=$1
RAM=$2
HDD=$3

 

virt-install –connect qemu:///system -n $NAME -r $RAM -vcpus=1 \
-f /var/lib/libvirt/images/$NAME.img -s $HDD \
–network=bridge:vibr0  –vnc –accelerate -v \
-c /var/lib/libvirt/images/ISOs/Fedora-15-x86_64-DVD.iso \
–os-type=linux –noautoconsole

Damit das alles ein wenig leichter zu installieren ist, hab ich mich an dem veralteten INSTALL.debian Skript von Danbooru orientiert und hier und da was ergänz oder abgeändert.

#### http://tech.tomgoren.com/archives/245
#### http://animebsd.net/archives/2528
#### http://trac.donmai.us/browser/danbooru/trunk/INSTALL.debian

als Download: INSTALL.debian

Hier das install script:
#!/bin/bash

#### http://tech.tomgoren.com/archives/245
#### http://animebsd.net/archives/2528
#### http://trac.donmai.us/browser/danbooru/trunk/INSTALL.debian

#### root@danbooru:/var/www/danbooru# vim app/models/post_methods/file_methods.rb
#### sftp albert maskieren

echo
echo
echo
echo "I'm done!"
echo "You should probably set the password for the danbooru account (run passwd danbooru)."