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:

Um belegte Inodes zu überwachen, habe ich ein frisches Nagios-Plugin entwickelt. Der Nutzen zeigt sich darin zu jeder Zeit darüber informiert zu sein ob die Inodes knapp werden.

Dieses Nagios-Plugin habe ich mit dem CPAN Modul Getopt::Std geschrieben. Dieses muss installiert sein.

CentOS:

yum install perl-Getopt-ArgvFile

Unter Debian ist das Perl Modul bereits installiert. Natürlich kann man Getopt::Std auch via CPAN Shell installieren. Dieses Plugin gibt wie meine anderen Plugins auch Nagios Performancedaten aus. Unten, ein Screenshot wie die Visualisierung des Inode Nagios Plugins aussehen kann.

Auf der Kommandozeile ergibt ein Aufruf der Form:

./check_inode.pl -w 10 -c 15 -d /dev/hda3

etwa eine Ausgabe wie:

CRITICAL: 20% belegt | inodesbelegt=20;10;15

Zu beachten sei an dieser Stelle, dass die ausgegebenen Werte prozentuale Werte sind. Bei Bedarf könnte ich noch eine Version veröffentlichen welche die tatsächlich belegten/freien Inodes ausgibt.

Syntax:

./check_inode.pl -w XX -c XX -d /dev/XX

Download: check_inode.pl

Ausgabe von Performacedaten mit PNP4Nagios.

Update

Aufgrund des Bedarfs habe ich das Nagios-Inode-Plugin etwas angepasst. Nun liest das Plugin die tatsächlich belegten Inodes aus. Über die Warning- und Critical-Option werden die tatsächliche Anzahl an Inodes angegeben bei denen alarmiert werden soll. Dieses Plugin arbeitet nicht wie das weiter oben mit prozentualen Werten, sondern einzigst mit den belegten Inodes am jeweiligen Device.

Syntax:

./check_inode.pl -w XX -c XX -d /dev/XX

Download: check_total_inodes.pl

Dieses Plugin gibt ebenfalls Performancedaten aus.

Ein Update auf die neue WordPress Version 3.0.1 gestaltet sich recht einfach. Einige Schritte müssen beachtet werden, damit es nicht später zu einem allgemeinen Datenverlust kommt. Daher empfehle ich vorab erstmal eine Datensicherung des Documentroot (Webhostingverzeichnis) und der WordPress Datenbank vorzunehmen.

Nun können alle Dateien und Ordner im WordPressverzeichnis gelöscht werden, bis auf folgende Ausnahmen:

/wp-content/
wp-config.php

Nach dem Download der WordPressversion 3.0.1 werden alle Dateien bis auf die beiden Ausnahmen, der Ordner wp-content und die Konfigurationsdatei wp-config.php in das WordPressverzeichnis hochgeladen. Ist dieser Vorgang abgeschlossen, wird über die URL http://meinedomain.de/wordpress/wp-admin/upgrade.php (exemplarisch) das Update gestartet. Nach Abschluss des Upgrades gibt WordPress Meldung, und damit ist der Vorgang abgeschlossen.

Und immer daran denken: Erstmal ein Backup anfertigen

Seit kurzem überwache ich die Festplattentemperatur an meinem Hetzner EQ6 mit Nagios. Dies geschah eigentlich nur aus dem Grund weil mir die Festplattentemperatur mit ca. 55°C-58°C doch etwas hoch vorkam, vor allem im Dauerbetrieb. Die Platten haben zwar eine Betriebstemperatur die bis 60°C angegeben ist, etwas unwohl war mir dabei aber schon.
Nachdem die Temperatur dauerhaft über 58°C angestiegen ist habe ich den Support angeschrieben, welcher mir direkt einen zusätzlichen Lüfter in das Gehäuse baute. Mit dem Effekt bin ich zufrieden, die Temperatur beider Festplatten wurde um ca. 10°C gesenkt. Anbei habe ich die Graphen der Nagiosüberwachung angehängt, damit kann man sich mal ein Bild davon machen was ein Lüfter doch so ausmachen kann.

SDA

SDB