Hier eine kleine Anleitung einen SFTP Server mit Proftpd einzurichten. Da es um die reine Funktionsweise geht, habe ich die Konfiguration und die Erklärung auf das nötigste gestrippt.

/etc/proftpd.conf

User nobody
Group nobody

LogFormat default “%h %l %u %t \”%r\” %s %b”
LogFormat auth “%v [%P] %h %t \”%r\” %s”

LoadModule mod_sftp.c

SFTPEngine on
SFTPLog /var/log/proftpd/sftp.log
TransferLog /var/log/proftpd/sftp-xferlog

Port 40448

SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key

SFTPAuthMethods publickey
SFTPAuthorizedUserKeys file:/etc/proftpd/keys/%u

DefaultRoot ~

Die Authentifizierung ist damit auf Publickey beschränkt. Proftpd akzeptiert RFC4716 Public Keys (ssh.com). Sollte das Key-Set im OpenSSH Format vorliegen, muss der Public Key konvertiert werden:

ssh-keygen -e -f /pfad/zum/pubkey.pub

Die Ausgabe aus obigem Kommando wird dann nach /etc/proftpd/keys/username gespeichtert. Username steht hier für den Benutzernamen mit dem man sich verbinden möchte (Siehe auch %u in SFTPAuthorizedUserKeys). Es ist auch darauf zu achten, dass der Benutzer im System angelegt ist. Es ist kein Problem dem Benutzer /bin/false o.ä. als Shell zuzuweisen.

Das war auch schon alles, natürlich sollten die Dateiberechtigungen der Pubkeys entsprechend sicher konfiguriert werden. In dieser Konfiguration ist der verbundene Benutzer in einem Jail gefangen, welches das Home-Verzeichnis des jeweiligen Benutzers abbildet.

Ich arbeite privat sehr viel mit Centos, und habe aus Performancegründen seit längerer Zeit einen privaten Centos-Mirror am laufen. Gerade für Netz-Installationen ist ein schneller Mirror eine prima Sache. Jedenfalls kam mir bald der Gedanke den Mirror bei Centos zu announcen.
Ab heute ist der Mirror öffentlich zugänglich, und bei Centos in der Public Mirror List geführt.

Der neue Mirror ist ab sofort bereit zur Verwendung: http://centos.mirror.linuxwerk.com/

Bei verschiedenen Tests mit Apache Reverse Proxies bin ich aus das Phänomen gestoßen, daß WordPress beim Aufruf des Blogs nach 127.0.0.1 redirected. Nach einer Recherche bin ich dem Problem auf die Schliche gekommen. Einige Forenschreiber empfehlen Variablen in WordPress umzuschreiben. Davon war ich nicht begeistert, ich wollte die WordPress-Applikation unberührt lassen.

Das Problem entsteht wie folgt. Meine Apache-Backend Installation mit WordPress lauscht auf Localhost, Port 45080. Im WordPress-Code wird häufig mit der Variable $_SERVER['HTTP_HOST'] gearbeitet. Diese Variable beinhaltet 127.0.0.1:45080. Und genau hier hin will WordPress Umleiten. In manchen Fällen wäre es vielleicht geschickter gewesen mit der Variable $_SERVER["HTTP_X_FORWARDED_HOST"] zu arbeiten. Ändern des Codes war jedoch keine Option, also habe ich eine Anpassung am Backend-Apache vorgenommen, um das Problem zu lösen.

Dieser RequestHeader Eintrag ersetzt vorherige Header mit dem neuen Namen. Das Modul mod_header muss natürlich geladen werden.

RequestHeader set Host blog.timharsdorf.de

Nach einem Reload funktioniert WordPress wieder ohne die lästigen Localhost-Redirects.

Vorab sollten folgende Dependency-Pakete installiert werden:

yum install gtk2-2.24.7-2.fc16.i686 libXt-1.1.1-1.fc16.i686 libXmu-1.1.0-2.fc15.i686 libXpm-3.5.8-3.fc15.i686 libXp-1.0.0-16.fc15.i686 nspluginwrapper alsa-lib-1.0.25-1.fc16.i686

Als nächstes soll der Citrix Receiver von www.citrix.com herunterladen und installiert werden.
Gegebenenfalls muss noch ein Zertifikat installiert werden, je nach Organisation. CA Zertifikate müssen in /opt/Citrix/ICAClient/keystore/cacerts/ abgelegt werden.

Nun kann man sich am Citrix XenApp einloggen und die angebotenen .ica Dateien mit /opt/Citrix/ICAClient/wfica öffnen.

Unter gewissen Umständen kann es möglich sein dass man in einem Yum Repository ein Paket in verschiedenen Versionen vorhalten möchte. Ein Beispiel dafür wäre z.B. die Instanzierung eines Services, den man in verschiedenen Versionen betreiben möchte.
Per Default zeigt yum immer nur die neueste Version der Pakete an. Um sich alle verfügbaren Versionen eines Paketes anzeigen zu lassen, wird die Option —showduplicates verwendet.

Normales Listing:

[ root@santiago:~ ] yum list lw-httpd
Available Packages
lw-httpd.x86_64 2.2.22-1.el6 Linuxwerk

Listing mit allen verfügbaren Versionen:

[ root@santiago:~ ] yum –showduplicates list lw-httpd
Available Packages
lw-httpd.x86_64 2.0.64-1.el6 Linuxwerk
lw-httpd.x86_64 2.2.22-1.el6 Linuxwerk

Im nächsten Schritt möchte man die verschiedenen Versionen auch per yum installieren. Out of the Box will yum nur ein Update auf die neueste Version unternehmen. Auch hier gibt es eine Lösung. In der Konfigurationsdatei /etc/yum.conf können Pakete definiert werden, für die keine Updates, sondern nur die eigentliche Installation angewandt wird.

installonlypkgs=lw-httpd

Nun kann man z.B. nach dem Schema name-ver-rel die jeweilig gewünschte Version installieren.

Diese Anleitung basiert auf einem Debian 6. Vorab lädt man den „Citrix Receiver“ von http://www.citrix.com herunter. Hier gibt es ein Debian Package, welchem noch folgende Abhängigkeiten fehlen:

libmotif4 (non-free)
libxp6

Nach Erfüllen der Abhängigkeiten kann das Citrix Paket (icaclient_12.0.0_i386.deb) installiert werden. Die ICA-Client Installation erfolgt nach /opt/Citrix/ICAClient.
Würde man nun einen Verbindungsversuch starten, könnte dies mit dem SSL Error 61 quittiert werden. Dies bedeutet dass das benötigte SSL-Zertifikat nicht installiert ist. Hier muss das Stammzertifikat des Zertifikatsherausgebers installiert werden.
Hier wird das DER encoded X.509 Zertifikat benötigt. Dieses Zertifikat kommt dann in das Verzeichnis /opt/Citrix/ICAClient/keystore/cacerts/ . Damit ist der Grundstein für die Verbindung gelegt.

Nun sollte die Verbindung via z.B. Firefox über die Citrix-Url funktionieren.

Ein paar Adressen für das Troubleshooting:
https://help.ubuntu.com/community/CitrixICAClientHowTo
http://support.citrix.com/article/CTX711855
http://forums.citrix.com/thread.jspa?threadID=249720

Auf einer frisch, mit Fedora 14 (x64) installierten Kiste wollte ich gerne ohne weitere Umschweife mit KVM virtualisieren. Nun, nach der Installation der entsprechenden Pakete, u.a. dem Virtual Machine Manager (virt-manager), meldete sich dieser beim Start mit folgendem Fehler:

Unable to open a connection to the libvirt management daemon.
Libvirt URI is:
qemu:///systemVerify that:
- The ‘libvirtd’ daemon has been started

Weitere Details:

authentication failed

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 983, in _try_open
None], flags)
File “/usr/lib64/python2.7/site-packages/libvirt.py”, line 107, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: authentication failed

Ein Lösungsansatz findet sich in der Libvirt-Dokumentation unter dem Abschnitt Access Control. Um es kurz zu halten, als nicht-root Benutzer fehlen die Rechte am Libvirt Management Daemon. Abhilfe schafft hier eine Konfiguration des UNIX socket PolicyKit auth. Um beispielsweise dem Benutzer “Hans” Zugriff auf den Virtual Machine Manager in Kombination mit dem Libvirt-Daemon zu geben, erstellt man eine neue Policy unter /etc/polkit-1/localauthority/50-local.d/. Ein solches Policy-File hat die Dateinamenserweiterung .pkla. Ein beispielhafter Eintrag könnte wie folgt aussehen:

[Libvirt Management Rechte für Hans]
Identity=unix-user:hans
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Als “Action” lassen sich zwei Berechtigungsstufen konfigurieren. org.libvirt.unix.manage gibt Vollzugriff, org.libvirt.unix.monitor gibt einen Lesezugriff auf den Virt-Manager.

An dieser Stelle ein Dankeschön an Richard Jones, welcher an dieser Stelle den Ansatz zur Problemlösung in der Fedora Development Liste gab.

Beruflich war ich in letzter Zeit mit dem Thema Testautomatisierung und Non-Functional Tests beschäftigt. Nun, in diesem Kontext habe ich meine Aufgaben in Java realisiert. Ich selbst, war von den beim Kunden eingesetzten Techniken und Mitteln stark begeistert und habe viel dazu gelernt. Als begeisterter Perl-Benutzer lag es für mich nahe eine Implementation von Selenium für Perl bereitzustellen, welche es ermöglicht Webapplikationen zu testen, welche auf dem Javascript-Framework Qooxdoo aufsetzen.

Dazu haben eigentlich nur noch die Perl-Bindings für die Qooxdoo Implementation für Selenium gefehlt. Mit diesen lassen sich klassische qxSelenium-Befehle wie qxClick, qxType etc. nun auch via Perl am RC-Server ausführen.

Viel Spass mit Selenium und Qooxdoo Webapplikationen

Download: QxSelenium.pm

Die aktuelle Version der qxSelenium Perl-Bindings sind im SVN-Repository des Qooxdoo-Projektes zu finden. An dieser Stelle möchte ich mich noch herzlich für die Zusammenarbeit mit D. Wagner und A. Ecker bedanken.

Inspiriert von einem Bericht über Slowloris im Linuxmagazin, zeige ich hier in einer Quick & Dirty Anleitung wie man mod_qos unter Apache einsetzt, um Slowloris-Angriffe abzuwehren.

Meine Anleitung basiert auf einem Debian 5 Minimalsystem unter einem selbskompiliertem Apache 2.2.16.

Zuerst wird das mod_qos Archiv von der Projektseite heruntergeladen und entpackt.

Mit folgender Eingabe wird mod_qos installiert.

apxs -i -c mod_qos-9.25/apache2/mod_qos.c

Der Apache braucht in der httpd.conf noch folgenden Eintrag um das Modul zu verwenden:

LoadModule qos_module modules/mod_qos.so

In der Apache-Konfiguration wird folgender Abschnitt hinzugefügt:

## QoS Settings
<IfModule mod_qos.c>
# handles connections from up to 100000 different IPs
QS_ClientEntries 100000
# will allow only 50 connections per IP
QS_SrvMaxConnPerIP 50
# maximum number of active TCP connections is limited to 256
MaxClients 256
# disables keep-alive when 70% of the TCP connections are occupied:
QS_SrvMaxConnClose 180
# minimum request/response speed (deny slow clients blocking the server, ie. slowloris keeping connections open without requesting anything):
QS_SrvMinDataRate 150 1200
# and limit request header and body (carefull, that limits uploads and post requests too):
# LimitRequestFields 30
# QS_LimitRequestBody 102400
</IfModule>

Nach einem Webserverneustart ist das Modul aktiv, und durch die Konfiguration, der Apache geschützt. Natürlich sollte sich jeder die Werte nach eigenem Bedarf anpassen.

Zum Schluss möchte ich noch erwähnen dass mod_qos nicht nur zur Abwehr von Slowloris entwickelt wurde, vielmehr lassen sich durch zahlreiche Optionen respektable “Quality-Of-Service” Werte erreichen.

Dieses Nagios-Plugin ermittelt die Anzahl offener MySQL-Verbindungen. In erster Linie dachte ich bei der Entwicklung des Plugins an die oft gesehene Fehlermeldung “Too many connections“. Von der Aufrufsyntax her ist dieses Plugin einfach gehalten, es werden nur der Warning- und der Criticalwert übergeben. Damit das Script funktioniert, müssen die Variablen für die MySQL-Zugangsdaten und den MySQL-Socket angepasst werden:

# Konfiguration / Zugangsdaten
my $username=”USERNAME”;
my $passwort=”PASSWORT”;
my $mysqlsock=”mysql_socket=/pfad/zu/mysql.sock”;

Um eine Validierung der Warning- und Critical Werte zu gewährleisten liest das Plugin den aktuell gesetzten max_connections Wert aus der MySQL-Konfiguration aus. Damit wird verhindert dass beim Aufruf mit einem Wert > max-connections für Warning oder Critical gearbeitet werden kann.

Letztendlich bezieht das Nagios-Plugin sein Ergebnis der offenen Verbindungen über den Query “show processlist“.

Ein Aufruf des Plugins wie z.B.:

./check_mysql_processlist -w 20 -c 30

egibt eine Ausgabe wie z.B.:

OK: 16 Verbindungen | verbindungen=16;20;30

Die Syntax des MySQL Processlist Nagios Plugins beschränkt sich auf zwei Optionen:

./check_mysql_processlist -w XX -c XX

Download: check_mysql_processlist.pl

Dieses Nagios Plugin benötigt die Module Getopt::Std und DBI.

Eine Visualisierung mit PNP4Nagios sieht dann so aus: