Ich: “sie brauchen bestimmt Vertrags- oder Kundennr.?!”
Support: “die habe ich – leider komme ich gerade nicht an ihre Daten. Aber vieleicht kann ich ihnen auch so helfen”
Ich: “naja mein Rootserver ist nicht erreichbar..”
Support: “haben sie das Rescuesystemprobiert?”
Ich: “ja – netzwerkseitig sieht der letzte Hop aber sehr komisch aus – hohe Latenz, andere Hosts aus dem Subnetz werden über anderen Weg geroutet und funktionieren.”
Support: “doof! (wortwörtlich!). Ich würde gerne nachschauen, aber die Supportdatenbank ist gerade nicht erreichbar. Momentan geht hier gar nix!”
Ich: “haben sie mal den Support gefragt?!”
Support: “ich hoffe(!) irgendwann heute nacht geht es wieder. Leider kann ich momentan nicht helfen. Bitte rufen sie morgen früh wieder an.”

Gut das dieses Gespräch nur 0,99 EUR gekostet hat.

Kommunikationswege:

Technisch stellt der Agent an das Citrix Webinterface PNAgent Site erst eine GET Anfrage (kann weggelassen werden) und übermittelt danach per POST Username und Passwort. Daraufhin leitet das Webinterface die Usercredentials and den Citrix XML-Service weiter und erhält die Liste der Anwendungen, welche für den User konfiguriert sind als XML.

Simulieren des Logins

Um unsere Anfrage zu simulieren müssen wir den Verkehr mit einem Tool wie Wireshark mitschneiden. Um mitlesen zu können sollten wir gegen ein Webinterface arbeiten, welches per HTTP anzusprechen ist.

Im vorhinein wird ein User benötigt für welchen wenigstens eine veröffentlichte Anwendung definiert ist.

Da mehrere Logins mit dem gleichem Passwort immer das selbe verschlüsselte Passwort ergeben, ist davon auszugehen, dass ein XOR mit einem geheimen Wert gemacht wird.

Die POST Anfrage vom Client zu Server sieht ungefähr folgendermaßen aus:

erst nen bischen allgemeines Zeug:

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd">
<nfuseprotocol version="4.6">
<requestappdata>
<scope traverse="onelevel" type="PNFolder"/>
</requestappdata></nfuseprotocol>
<desireddetails>all</desireddetails>
<desireddetails>icon-info</desireddetails>
<servertype>x</servertype>
<servertype>win32</servertype><clienttype>ica30</clienttype>
<clienttype>content</clienttype>

nun die Usercredentials:

<credentials>
<username>MYUSERACCOUNTTOCHECK</username>
<password encoding="ctx1">THISISMYCRYPTEDPASSWORD</password>
<domain type="NT">MYDOMAIN</domain>
</credentials>

ein bischen unnützes Zeug:

<clientname>MYCLIENTNAME</clientname>
<clientaddress>111.222.333.444</clientaddress>

NagiosPlugin

Eins vorweg: ich weiss, dass es “smartere” Möglichkeiten gibt, aber es muss platz für Verbesserung geben. Ich denke ich werde das gesammte Plugin demnächst nochmal überarbeiten und schick machen.

Mit dem check_http Plugin – defaultplugin von Nagios – kann ein Post Anfrage simuliert und die Rückgabe geparsed werden. Wird dein definiertes Pattern gefunden liefert das Script “OK” und eine Antwortzeit. Diese Rückgabe parsen wir mit dem check_wiserver.sh Script.

check_wiserver.sh:

#!/bin/sh
a=`/usr/lib/nagios/plugins/check_http -I 111.112.113.114 -u http://mywebinterfaceserver/citrix/pnagent/enum.aspx -s MyMonitoringApp -P '< ?xml version="1.0" encoding="UTF-8"?>< !DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"><nfuseprotocol version="4.6"><requestappdata><scope traverse="onelevel" type="PNFolder"/><desireddetails>all</desireddetails><desireddetails>icon-info</desireddetails><servertype>x</servertype><servertype>win32</servertype><clienttype>ica30</clienttype><clienttype>content</clienttype><credentials><username>MYUSERACCOUNTTOCHECK</username><password encoding="ctx1">THISISMYCRYPTEDPASSWORD</password><domain type="NT">MYDOMAIN</domain></credentials><clientname>Nagisserver</clientname><clientaddress>115.116.117.118</clientaddress></requestappdata></nfuseprotocol>'`
 
zeic=`/bin/echo $a |/bin/grep OK`
if [[ "$zeic" = "" ]]; then
 
  echo $a
  exit 2
fi
echo $a
exit 0

In diesem Beispiel wird der Host 111.112.113.114 auf der URL http://mywebinterfaceserver/citrix/pnagent/enum.aspx mit den Usercredentials MYUSERACCOUNTTOCHECK mit dem verschlüsseltem Passwort “THISISMYCRYPTEDPASSWORD” abgefragt. In der Rückabe wird nach der veröffentlichten Anwendung “MyMonitoringApp” geparsed und “OK” zurückgegeben. Daraufhin liefert check_wiserver.sh 2 für Error oder 0 für OK an Nagios zurück.

Dieses Script muss nun lediglich noch als Command im Nagios definiert werden.

Zusammenfassung

was wird mit der Probe überwacht?
• Authentifizierungbackend (z.B.: Active Directory)
• XML Service liefert valide Antworten
• Web Interface Agent Site

was wird mit der Probe nicht überwacht?
• Citrix Datastore
• Citrix Licensing (hierzu kommt demnächst ein Blogpost)
• “richtiges Login” wie Citrix Active Application Monitoring oder Openview

was muss getan werden:
• Monitoringuser anlegen und Anwendung veröffentlichen
• Login mit expliziten Credentials tracen um verschlüsseltes Passwort zu erhalten
• in check_wiserver.sh hostname, sitename und usercredentials anpassen, ggf. Pfad zu check_http anpassen

Leider haben wir zum ersten “Schuss” nur 2 Billigmikros genommen. Trotzdem hoffe ich dass ihr es uns die schlechte Audioqulität verzeiht – das nächste mal wird’s besser – versprochen!

Mittlerweile sind einige Statements zu “alt”. Autotype funktioniert beispielsweise mit Linux.

Nachdem ich ca. 15 FLV Plugins für Wordpress durchprobiert habe, kann ich FLV-embed empfehlen. Alles andere is überladen, bietet kein fullscreenmodus oder ist fummelig in der Installation.

Beim Update meiner steinalten 2.2.3 Wordpress Version auf 2.6.0 funktionierten nach dem Update weder die Permanlinks (Links zu den Artikeln) noch wurde nur eine Kategorie angezeigt.

Das Kategorieproblem war schnell bei Google gefunden, aber ich hatte wenig Lust händisch in der Datenbank rum zufummeln und beim nächsten Update wieder auf Gesicht zu fallen.

Nächster Ansatz war ein schrittweiser Upgrade von 2.2.3 auf 2.3.3., 2.5.1 dann 2.6.0. Hier bestand bei 2.5.1 das Problem, dass ein Login auf der Adminoberfläche – Dashboard – nicht möglich war.
Gefixt hat nach etlichen probieren dann die 2.2.3 von allen Plugins zu befreien, schrittweise upzudaten und die Plugins wieder zu aktivieren.

Da das Permalink Problem nach dem Update von 2.5.1 auf 2.6.0 immernoch besteht werde ich die nächsten Tage weiter rumprobieren oder auf einen neue Version warten. Auf jeden Fall sollte im gleichen Zuge das Problem mit den Popup Bildern behoben werden. Das Problem ist den Entwicklern anscheinend bekannt und soll mit 2.6.1 behoben werden.

Es bleibt dabei: immer ein funktionierendes Backup griffbereit halten!

Beispiel:

send_sms.pl -r 0172222222 -f nagios -t "small sms" -k 132343554556465656BBEF3

das Script benötigt Perl LWP Modul.

Hier gibt es das Script zum Download

Das Script akzeptiert die Übergabeparameter -u für den Usernamen der zmcontrol ansprechen darf (default: zimbra) , sowie -b für den Pfad von zmcontrol (default: /opt/zimbra/bin/zmcontrol).

Da zmcontrol lediglich durch den Zimbrauser zu starten ist, müsst ihr eurem Nagiosuser erlauben das Kommando als Zimbrauser zu starten. Dies erledigt man durch das Anpassen der /etc/sudoers und das Anfügen der Zeile

%nagios ALL=(zimbra) NOPASSWD:/opt/zimbra/bin/zmcontrol

Danach bindet man das Script in seine Nagiosinstallation ein. Da ich den nrpe Deamon verwende wird die nrpe.cfg erweitert durch.

command[check_zmstatus]=/usr/local/nagios-plugins/libexec/check_zmstatus.pl -b $ARG1$

Hier gibt es das Script zum Download

Ein paar Bugs gibt es aber anscheinend. So funktioniert die HTTP Authentifizierung in 1.10 nicht.

Wer trotzdem nicht auf den Luxus einer Paketverwaltung verzichten möchte greift zum DAG.

Einfach /etc/yum.conf um das Repository (hier CentOS4):

[dag]
name=dag
baseurl=http://apt.sw.be/redhat/el4/en/$basearch/dag
gpgcheck=0

erweitern und updaten.

Link zu FAQ

The process of setting up an VMware ESX3 Host ist quite similar to RHEL3/Centos3. I’m using Altriris Deployment Server (or HP Rapid Deployment Pack) but IMHO you could easily customize it for any other deployment solution.

The main steps are:
1. create a bootable dos partition with all necessary files for booting up the linux installer with loadlin – or linld.
2. create bootentries depending on your physical hardware (Proliant, PowerEdge Server…)
3. create a custom kickstart (ks.cfg) file which uses hostname and ip you entered in you deployment server console.
4. create virtual switches, portgroups etc. depending on your enviroment.
5. install further Managmentsoftware (e.g.: Openmanage, Proliant Support Pack), Backup- or Monitoringagents

Step One:
Deploy an empty FAT32 partition to you deploment client. Mine is 100MB, but it can be much smaller – you can use rdeploy. Reboot your maschine.
The install01.bat file attached is copying the needed files from deplomentserver share.

copy %OSFilesPath%\dosutils\loadlin.exe c:\loadlin.exe
copy %OSFilesPath%\dosutils\linld.com c:\linld.com
copy %OSFilesPATH%\dosutils\autoboot\initrd.img c:\initrd.img
copy %OSFilesPATH%\dosutils\autoboot\vmlinuz c:\vmlinuz

echo dos2unix.exe ks.cfg > C:\autoexec.bat


Step 2:
Now you have to create a custom bootentry for your linux loader. The main problem is that the ks.cfg will be located on hardware and the devicenames differ from vendor to vendor (e.g. /dev/cciss/c0d0 for HP with SmartArray – /dev/sda for MegaRaid). Be aware that the 9th generation of PowerEdge Server (PE1950, PE2950…) will not work with loadlin. Nobody really knows why, but I found it here.

install02.bat does make the decision for you what server hardware you’ve got:

if "%#!computer@right(prod_name,4)%" =="2850" goto sda
if "%#!computer@right(prod_name,4)%" =="2950" goto sdalld
if "%#!computer@right(prod_name,2)%" =="G4" goto cciss

:Exit
exit

The strange looking “%#!computer@right(prod_name,4)%” is Altiris DS specific. It’s reading out the vendor description for the Server presented at PXE Boot. This will differ to other Deployment solutions.
Now reboot you maschine and make C:\ drive bootable (install03.bat) and copy further files.

f:\bootwiz\dos\sys.com f:\bootwiz\dos c:
f:
copy f:\bootwiz\dos\himem.sys c:\
copy f:\bootwiz\dos\smartdrv.exe c:\
echo device=c:\himem.sys>>c:\config.sys
echo @echo on>>c:\autoexec.bat

Step3a: create ks.cfg file

The ks.cfg file is the answer file for the ESX Installer. If you are not familar with the kickstart procedure you can fancy it as an unattended.txt or winnt.sif file for Windows Installations. The main difference is that you also define package source (in my case a webserver with the hole cd copied to “http://webserverurl/esx3″ and partition scheme. The important section begins at %post and process self written scripts after the installation. I’m using it for creating virtual networks, installing the altiris (adl)agent and some small jobs.

You can easily create a ks.cfg file with installing ESX Server one time manually. The specified options are written to /root/anaconda-ks.cfg. For further information about kickstartfile consult VI Installation guide.

Step3b: Token Replacement Process
The Replacement Process is also Altris DS specific und uses for creating a machine specific kickstart file. It is replacing placeholders with the values you entered in Deployment Server Console. Because there is no Token for VMKernel network ip, I’m using the os license entry for it. Do not remove any “rem”ed line. – the Token Replacement will not work.

rem bootwork unload

rem replacetokens .\deplmes\deploy\pre-os\esx3\ks.cfg .\deplmes\deploy\pre-os\esx3\%ID%.cfg
Firm Copy F:\deplmes\deploy\pre-os\esx3\%ID%.cfg C:\ks.cfg
Firm Copy F:\deplmes\centos\unixdo16\dos2unix.exe C:\dos2unix.exe


After the Token Replacement process you installation is ready to be booted to production. This will start the installer with the ks.cfg file. Good luck!

You will find more information about step 4 and step 5 in the next Blog-entry “fully hardware-independent unattended ESX3 Server installation – Part 2″. This will be published in the next days.

Attachments:
install01.bat
install02.bat
install03.bat
Kickstart file ks.cfg

http://support.citrix.com/article/CTX113293 (dt. PS) bzw. http://support.citrix.com/article/CTX113515 (engl. PS) ist das Problem als Verbindungsabrüche von “nicht Windows Clients” beschrieben.

der Hotfix hat nach kurzer Testphase funktioniert. Es waren Igel LX2110 Thinclient betroffen. Vom MacOS konnte ich das Problem nicht nachstellen!