Einträge für Xela

Redmine kann Tickets automatisch durch eingehende Mails anlegen und auch Projekten zuordnen.
Grundlage dieser Anleitung:

• Redmine - das Ubuntu Lucid Paket (0.9.3)
• Postfix als MTA - läuft auf dem selben Server, die in Redmine verwendete Maildomain ist virtuell

In diesem Fall wird Postfix angewiesen, Mails an Redmine via pipe zuzustellen. Das klappt verzögerungsfrei und performant, ist aber leider auch mit etwas Konfigurationsaufwand verbunden.
Im Beispiel-Redmine dürfen ausschließlich existierende User mit ausreichender Berechtigung Tickets anlegen, keines der Projekte ist öffentlich.

Mithilfe folgender Codewurst kann der Memoryverbrauch nach Prozessnamen addiert aufgelistet werden:

Kleine Variante - wenn wir die Hauptverbraucher ohnehin schon kennen, konzentrieren wir uns auf die:

Konkretes Beispiel: es soll auf die Schnelle ein Stapel wav Dateien mit ffmpeg in mp3 konvertiert werden, die Dateinamen haben aber leider ein Leerzeichen (Track 1.wav usw.).
Die Lösung: die Umgebungsvariable IFS (Internal Field Separator) umschreiben.
Hinweis: der Ordner "mp3" muss natürlich vorher von Hand angelegt werden.

Folgendes scheitert am Leerzeichen:

Wenn ich vorher aber die IFS Variable auf Zeilenumbruch setze, klappt es:

Danach sollte IFS wieder auf den ursprünglichen Wert, also Leerzeichen, gesetzt werden:

Ein überaus interessanter Thread in der Postgrey Mailingliste: Hostname-based Selective Greylisting
Im Grunde genommen ist es genau das, was ich mir schon länger wünsche:
Nur dynamisch oder sonstwie verdächtig aussehende Clients landen im Greylisting, die Mails echter MXe (die sowieso weitere Zustellversuche machen würden) werden gleich weiter verarbeitet.

Da das Ganze mit regex funktioniert, ist es auch leicht anpassbar.
Der Aufwand zum Umstellen von globalem Greylisting zu selektivem ist angenehm gering: zwei Konfigurationsdateien werden angepasst.

Keine Frage, ab ist ein tolles Tool.
Noch toller ist aber siege.
Warum? Ganz einfach: da man eine Liste ganz unterschiedlicher Links mitgeben kann, fällt das Ergebnis realistischer aus.
Ein Seitenaufruf normaler Besucher besteht ja immer aus einem Sammelsurium von unterschiedlichen Requests bestehend aus HTML-  und PHP-Inhalt, Stylesheets, Bildern, Javascript Files usw.

ab Beispiel:
siege Bespiel:
Die Datei links.txt enthält eine möglichst realitätsnahe Sammlung von urls eines Hosts. Die werden dann in beliebiger Reihenfolge aufgerufen.

Was auch noch schön ist an siege: die Verbosity.
Jeder einzelne Request wird mit Antwortcode, Dauer und Größe aufgelistet. So sieht man z.B. schön, wann es etwas länger gedauert hat, weil ein weiterer Apache Kindprozess gestartet werden musste.

Für beides gibt es Ubuntu Standardpakete:
ab wird mit Apache mitgeliefert (apache2-utils), siege kommt aus dem gleichnamigen Paket.

Wie in einem vorhergehenden Beitrag angekündigt, soll fail2ban mod_evasive ergänzen.
Statt nur Apache "403 Forbidden" Fehler ausliefern zu lassen, soll die IP komplett mit iptables geblockt werden.

Dazu brauchen wir:

1. einen fail2ban Filter
2. ein fail2ban jail

 

Das Problem: Apache auf einem mit wenig Ressourcen ausgestatteten Server (eine VM, Ubuntu lucid) erreicht neuerdings öfter mal das MaxClients Limit.
Nachdem ich die Apache Logfiles durchstöbert habe, stelle ich fest, dass von nur wenigen IP's massiv Anfragen kommen. Der vorgebliche Useragent IE6 ist es mit Sicherheit nicht - so schnell kann sich kein Mensch durchklicken.
Eher ist es ein schleißig programmierter Testbot oder ein Scriptkiddie hat was gebastelt.

In jedem Fall muss gedrosselt werden. Es darf nicht sein, dass eine einzelne IP via Script das normale Ausliefern von Content an echte menschliche Besucher ausbremst.