Ein Tipp eines Kollegen hat mich auf folgenden Post gebracht:

Folgender Code muss also einfach im Header der Datei untergebracht werden:

### BEGIN INIT INFO
# Provides: SCRIPTNAME
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO

nun nur noch SCRIPTNAME mit dem tatsächlichen Dateinamen ersetzen. Bei mir sieht der Header im Beispiel von SVN also so aus:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO#
# svnserve - brings up the svn server so anonymous users
# can access svn
#

Danach ein lustiges

dpkg-reconfigure sysv-rc

Und schon hat man das neue Bootsystem aktiviert.

Wie immer – großes Problem, einfache Lösung:

Courier selbst will dem Mailclient ja ein bisschen Arbeit abnehmen und scheint die Inhalte der Mailbox vorab zu sortieren. Zur Geburt jeder Inbox ist das ja kein Problem, da es nicht viel zu sortieren gibt. Je mehr Mails allerdings gespeichert werden umso mehr muss der liebe Courier auch arbeiten.

Die Abhilfe:

Bearbeitet folgende Datei (Dateipfad aus Debian Lenny):

/etc/courier/imapd

Darin solltet ihr folgende Zeile finden:

IMAP_DISABLETHREADSORT=0

Nun ändert ihr den Wert dieser Variable von 0 auf 1 und startet den Courier neu mit

/etc/init.d/courier-imap restart

Ab sofort ist die einzige Instanz die sortiert das liebe Squirrelmail. Ob dies Auswirkung auf einen Mailclient ala Outlook & Co. hat, konnte ich bislang noch nicht feststellen. Wenn ihr was feststellt, freue ich mich über einen Kommentar diesbezüglich.

Nachdem ich einen neuen VServer mit ISPConfig3 aufgesetzt habe, habe ich mir zum ersten Mal genauer das fail2ban Logfile angesehen. fail2ban ist ein Tool das die Frequenz von Zugriffen auf den Server registriert und automatisch über die systemeigene Firewall mit iptables einzelne IP-Adressen sperrt wenn diese zu häufig zugreifen wollen. An sich eine schöne Erleichterung für den Sysadmin.

Nun aber zur Fehlermeldung:

ERROR iptables -n -L INPUT | grep -q fail2ban-ssh returned 100

Heißt so viel wie “iptables funktioniert nicht”. Ein einfacher Test gibt Aufschluss über den Hintergrund. Einfach in der Kommandozeile mal folgendes eingeben:

modprobe ip_tables

Wenn dann sowas hier kommt

FATAL: Could not load /lib/modules/2.6.36.4-vs2.3.0.36.39-netcup/modules.dep: No such file or directory

bedeutet das, dass iptables nicht geladen wurde und somit auch nicht zur Verfügung steht.

Wie man in der Fehlermeldung sieht, steht besagter Server bei Netcup. Hier soll es angeblich eine Möglichkeit geben dennoch auf iptables zuzugreifen. Ich werde das mal recherchieren und bei Erfolg hier nachtragen. Ansonsten scheint es aber üblich zu sein, dass man keinen Zugriff auf iptables auf einem VServer bekommt.

Weitere Quellen sagen jedoch ohnehin aus, dass fail2ban nicht unbedingt das beste Stück Software ist und gerne auch die Serversicherheit ein wenig runter schraubt. Ich kann das nicht bestätigen und lasse diese Aussage somit einfach mal im Raum stehen, würde mich aber über fachliche Kommentare dazu sehr freuen.

Meine Lösung:
Bisher hab ich noch keine. Ich werde mir mal ein hübsches Script überlegen, was die Zugriffe überwacht und mich dann entsprechend per Mail informiert oder sowas in der Richtung. Auch hier bin ich für jegliche Lösungsvorschläge dankbar.

[EDIT]
In den FAQ von Netcup steht, dass man den Support kontaktieren soll wenn man iptables freigeschaltet haben möchte. Dies habe ich eben getan und warte nun gespannt auf Antwort. Wär natürlich ne feine Sache wenn das klappen würde.

[EDIT 2]
Da hatte ich wohl was falsch verstanden. iptables steht prinzipiell nicht zur Verfügung. Netcup arbeitet aber bereits an einer eigenen API für das vservercontrollpanel. Dadurch wird es möglich sein, fail2ban direkt auf diese API zugreifen zu lassen.
Ein Kollege von mir hat sich jedoch die Arbeit gemacht und für die Übergangszeit ein Script geschrieben mit dem das jetzt schon ohne API funktioniert. Das Script gibts hier:
http://blog.n-durch-x.de/2011/07/fail2ban-auf-netcup-vservern/
Funktioniert bislang tadellos auf meinem Server. Somit klappts dann auch mit fail2ban

Einmal bitte die /etc/apache2/httpd.conf editieren und folgende Zeilen einfügen:

Apache neu starten mit /etc/init.d/apache2 restart und schon sind wir sicher.

Zum Prüfen obs geklappt hat, gibt es diverse Shell-Scripts. Wer eines davon braucht – bitte einfach anmelden und nen Kommentar hinterlassen, dann schick ich das gerne zu.

Die Kontrolle durch mein mir vorliegendes Script war erfolgreich.

Vor der Umstellung:

Testing SSL2…
DES-CBC3-MD5 – 168 bits
RC2-CBC-MD5 – 128 bits
RC4-MD5 – 128 bits
DES-CBC-MD5 – 56 bits
EXP-RC2-CBC-MD5 – 40 bits
EXP-RC4-MD5 – 40 bits
Testing TLS1…
DHE-RSA-AES256-SHA – 256 bits
AES256-SHA – 256 bits
EDH-RSA-DES-CBC3-SHA – 168 bits
DES-CBC3-SHA – 168 bits
DHE-RSA-AES128-SHA – 128 bits
AES128-SHA – 128 bits
RC4-SHA – 128 bits
RC4-MD5 – 128 bits
EDH-RSA-DES-CBC-SHA – 56 bits
DES-CBC-SHA – 56 bits
EXP-EDH-RSA-DES-CBC-SHA – 40 bits
EXP-DES-CBC-SHA – 40 bits
EXP-RC2-CBC-MD5 – 40 bits
EXP-RC4-MD5 – 40 bits

Nach der Umstellung:

Testing SSL2…
Testing TLS1…
DHE-RSA-AES256-SHA – 256 bits
AES256-SHA – 256 bits
EDH-RSA-DES-CBC3-SHA – 168 bits
DES-CBC3-SHA – 168 bits
DHE-RSA-AES128-SHA – 128 bits
AES128-SHA – 128 bits

Alles also im grünen Bereich.

Einfaches Problem -> einfache Lösung.

Einmal bitte per root auf das System den folgenden Befehl ausführen:

dpkg-reconfigure locales

In einigen Tutorials wurde mir gesagt ich solle “de_DE.ISO-8859-1″ als Default einstellen. Ich selbst habe aber UTF-8 lieber, deswegen hab ich auch “de_DE.UTF-8″ eingestellt. Ich denke aber, dass nur wichtig ist, dass das entsprechende Locale installiert wurde.

Ich habe bei mir jetzt jedenfalls folgende Locales installiert weil ich sie für notwendig halte:

- de_DE ISO-8859-1
- de_DE.UTF-8 UTF-8
- de_DE@euro ISO-8859-15
- en_US.UTF-8 UTF-8

Nachdem das Script durch ist, einfach SquirrelMail im Browser neu laden und schon ist Alles wunderbar in Deutsch.

EDIT:
Neuerdings muss man anscheinen auch den Apachen neu laden bevor die Änderungen übernommen werden. Also einmal /etc/init.d/apache2 restart und endlich Squirrelmail in Deutsch benutzen.

Dabei wurde mir folgende Fehlermeldung um die Ohren gehauen:

Err http://ftp.de.debian.org etch/main Packages

Ein kurzer Blick in die sources.list zeigte mir auch sofort wo der Fehler war:

Das sind die alten Quellenangaben für die etch-Packages.

Daraus macht man einfach folgendes:

Und schon klappts auch wieder mit den Packages!

Vielleicht hilft das ja dem einen oder anderen bei der Fehlersuche. Bei Google und Co wurde ich nämlich nicht wirklich fündig.

Man editiere die Datei /etc/mail/submit.cf und modifiziere eine bereits existierende Zeile. Im Original sieht diese so aus:

# “Smart” relay host (may be null)
DS

Hinter das “DS” schreibt man nun die IP-Adresse des Relay-Host. Das Ergebnis sieht dann so aus wenn der Relay-Host beispielsweise die IP-Adresse 192.168.2.1 hat:

# “Smart” relay host (may be null)
DS 192.168.2.1

Danach ein schickes /etc/init.d/sendmail restart und schon trudeln die ersten Mails ins Postfach! Es kann so einfach sein…

Ich arbeite übrigens mit Debian etch auf aktuellstem stable release.

Das zu lösende Problem ist einfach zu erklären. Ich habe eine Kombination aus postfix, courier, amavis, spamassassin und maildrop auf einem Debian 5.0 System. Meine Mails werden im Header durch amavis und spamassassin schon korrekt als Spam markiert. Nun möchte ich aber noch, dass diese markierten Mails automatisch in einen Spamordner verschoben werden. Falls dieser Spamordner noch nicht existiert, soll er außerdem automatisch angelegt werden.

Folgendes führt zum Ziel.

Man editiere die Datei /etc/maildroprc