/etc/init.d/mysql restart

vi /etc/mysql/my.cnf

skip-bdb

Noch mal mysql neu starten und siehe da… ich mag meinen Server wieder!

Wer sich schon mal gefragt hat, wofür w7x eigentlich steht, ist entweder auf meinen ersten Blog-Eintrag gestoßen, oder er hat im Internet recherchiert und hat dabei höchstwahrscheinlich den “Wendelstein 7X” entdeckt.

Für Physik-Interessierte (wie ich es auch bin) ist das Thema Kernfusion sicher sehr spannend und aktuell hat Spiegel Online einen netten Bericht dazu veröffentlicht:

Kernfusionsforschung in Greifswald: Die 100-Millionen-Grad-Maschine – SPIEGEL ONLINE – Nachrichten – Wissenschaft.

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.

Der Gag dabei ist, dass man zuerst den Button selbst aktivieren muss bevor er aktiv wird. Dann bekommt man einen Hinweis, dass seine Daten im Ausland gespeichert werden und erst dann kann man den Button selbst betätigen.

Der Hintergrund ist natürlich klar. Auf jeder beliebigen Webseite gibt es heute einen Facebook- oder Google+-Button. Und die Benutzer nutzen diese auch teils exzessiv ohne sich Gedanken darüber zu machen, was im Hintergrund eigentlich passiert. Kaum jemandem ist bewusst, dass bei einem harmlosen Klick auf einen Like-Button sofort bei Facebook gespeichert wird, dass der Benutzer diese Seite besucht und dass er auch am Kontext dieser Seite interessiert ist. Eigentlich sogar noch schlimmer… ist man permanent bei Facebook eingeloggt, reicht sogar schon der Besuch auf der Seite mit dem Button damit Facebook dies mitbekommt. So lassen sich natürlich wunderbar detaillierte Bewegungsprofile im Internet erzeugen. Daraus ergeben sich dann im nächsten Schritt automatisierte Zuordnung von Interessengebieten und schon bekommt man angepasste Werbung.

Wie man auf diesen Seiten sehen kann, gibt es auch schon ein Plugin für WordPress mit dem man dieses System einfach integrieren kann. Es funktioniert zwar noch nicht 100%ig, ist aber jetzt schon besser als alle anderen Varianten.

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.

StartSSL™ Certificates & Public Key Infrastructure -.

Ob für die Authentifizierung von E-Mails oder die verschlüsselte Übertragung von Website-Inhalten. Eine kostenlose Variante zu den sonst eher teuren SSL-Zertifikaten von Verisign & Co. ist denke ich immer gern gesehen.

Ich habe mich für einen DSA-Key entschieden. Diesen erstellt man folgendermaßen:

$ ssh-keygen -t dsa

Damit ich nicht doch wieder was eintippen muss wenn ich mich auf dem anderen Host einloggen will, lasse ich die Passphrase leer.

Daraufhin haben wir jetzt folgende Dateien:
~/.ssh/id_dsa
~/.ssh/id_dsa.pub

Die *.pub-Datei muss nun auf den Zielserver kopiert und dort der Datei ~/.ssh/authorized_keys angehängt werden:

$ ssh-copy-id -i ~/.ssh/id_dsa.pub user@host

Jetzt einmal kurz testen obs geklappt hat:

$ ssh user@host

Eigentlich sollte jetzt keine Passwortabfrage mehr kommen.

Wer sich das mal ansehen möchte, kann sich einen der folgenden Gutscheincodes schnappen und sich mal anmelden. Die Server sind monatlich kündbar. Somit hätte man keinen Verlust gemacht, wenn es einem doch nicht zusagen sollte.

225nc13099571740
225nc13099571741
225nc13099571742
225nc13099571743
225nc13099571744
225nc13099571745
225nc13099571746
225nc13099571747
225nc13099571748
225nc13099571749

Viel Spaß dabei!

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

newaliases

Der Befehl gibt keine Rückmeldung wenn alles gut gelaufen ist. Und die Meldung sollte alsbald auch aus den Logfiles verschwunden sein.