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

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.

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.

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.

# 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:

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.

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

SDA

SDB

Eine Beispielausgabe für die CPU-Auslastung kann wie folgt aussehen:

OK: 0.1% (2 CPU)

Dazu sollte man wissen dass die prozentuale Angabe herunterskaliert ist. Bei einem Wert von 160% bei 2 vCPU’s gibt das Plugin 80% aus.

Bei der Ram Prüfung wird die prozentuale Auslastung/Belegung ausgegeben und in Klammern der Max-Mem-Wert.

OK: 16.7% (2048 MB)

Syntax:

./check_xvmstat.pl <vm> <cpu|mem> <warn> <crit>

Download: check_xvmstat.pl

Im PNP4Nagios sieht meine Visualisierung der Messdaten dann ungefähr so aus: