NetScaler Nagios Plugin (check_netscaler)

Mein NetScaler Nagios Plugin (auf Perl Basis) steht nun auf GitHub zum Download zur Verfügung. Dokumentation und einige Beispiele für die Verwendung finden sich direkt auf der GitHub Seite.

https://github.com/slauger/check_netscaler

Das Plugin arbeitet komplett über die NITRO REST API des Citrix NetScalers. Keine SNMP Verbindung. Über die API kann nahezu jeder Status innerhalb des NetScalers abgefragt werden.

NetScaler::VPNvServer::State
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_vserver -I vpnvserver

NetScaler::LBvServer::State
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot-C check_vserver -I lbvserver

NetScaler::System::Memory
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_threshold_above -I system -F memusagepcnt -w 75 -c 80

NetScaler::System::CPU
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_threshold_above -I system -F cpuusagepcnt -w 75 -c 80

NetScaler::System::CPU::MGMT
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_threshold_above -I system -F mgmtcpuusagepcnt -w 75 -c 80

NetScaler::System::Disk0
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_threshold_above -I system -F disk0perusage -w 75 -c 80

NetScaler::System::Disk1
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_threshold_above -I system -F disk1perusage -w 75 -c 80

NetScaler::HA::Status
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_string_not -I hanode -F hacurstatus -w YES -c YES

NetScaler::HA::State
./check_netscaler.pl -H  192.168.100.100 -U nsroot -P nsroot -C check_string_not -I hanode -F hacurstate -w UP -c UP

Auf der Agenda stehen noch Support für Performance Daten (für das Graphing) und ein Patch für den SSL Support der Nitro.pm von Citrix.

NetScaler Gateway: Icons are not displayed

Mit dem NetScaler Gateway im SmartAccess/Portal Modus gibt ab Version 11 die Möglichkeit für jede Applikation ein Icon für den Link zur Applikation/Ressource zu hinterlegen. Hierzu kann man über Ressources -> Bookmarks in der NetScaler GUI für jede Applikation ein Logo hochladen.

NetScaler Links

Leider gibt es einen Bug im NetScaler, der trotz Ausnahme in den „Domains for Clientless Access“ dazu führt das für jedes Icon ein CVPN Rewrite der URL durchgeführt wird.

So wird aus der eigentlich richtigen URL für die Grafik, z.B.

http://gateway.domain.de/logon/icons/Applikation.png

über den Rewrite die folgende CVPN URL

http://gateway.domain.de/http/gateway.domain.de/logon/icons/Applikation.png

Grundsätzlich wäre das kein Problem, allerdings wird der Rewrite auf die eigene Adresse mit HTTP statt HTTPS durchgeführt. Gibt es keine Umleitung von Port 80 zu Port 443 scheitert der Browser Request zum Icon mit einem „Request Timeout“. Die Folge ist natürlich das keines der eingerichteten Icons angezeigt werden kann.

Für das NetScaler Gateway ist kein zusätzlicher Listener auf Port 80 der VIP nötig, auf dem das Gateway konfiguriert ist (auch wenn es die Usability meiner Meinung nach deutlich erhöht und somit bei jedem Setup Pflicht sein sollte). Um diesen Bug zu umgehen ist es jedoch notwendig eine saubere Umleitung, inkl. dem HTTP Path und Query auf SSL einzurichten.

Am einfachsten kann dies über einen „leeren“ Content Switch mit einer Responder Policy realisiert werden. Ein CS vServer ist immer „UP“ und benötigt keinen aktiven Service um Content auszuliefern.

add responder action act_responder_redirect_generic redirect "\"https://\" + HTTP.REQ.HOSTNAME + HTTP.REQ.URL.PATH_AND_QUERY" -responseStatusCode 302
add responder policy pol_responder_redirect_generic true act_responder_redirect_generic

add cs vserver vs_ssl_redirect HTTP 192.168.100.100 80 -cltTimeout 180
bind cs vserver vs_ssl_redirect -policyName pol_responder_redirect_generic -priority 100 -gotoPriorityExpression END -type REQUEST

Für die beste Darstellung im Standard X1 Theme empfiehlt sich im übrigen eine Auflösung der Logos von 70x70px.

Puppet Module mittels r10k über Puppetfile deployen

Hier ein kurzer Überblick über mein aktuelles Management meiner Puppet Module und Manifests mittels r10k. Das Tool r10k kümmert sich darum, das aus einem Git-Branch innerhalb eines Repositories mit Puppet Code ein nutzbares Puppet Environment wird. Das unten stehende Setup läuft nun bereits seit einigen Monaten so produktiv und ich bin wirklich sehr zufrieden mit r10k.

Meine eigentliche r10k Konfiguration ist sehr einfach gehalten. Ich lasse ausschließlich ein Verzeichnis /etc/puppet/environments deployen, in dem ich alle Dateien und Verzeichnise ablege. Zwecks Performance handelt es sich bei diesem Verzeichnis um ein tmpfs. Ein globales Manifest oder globale Module gibt es nicht. Hiera liegt ebenfalls im environment Verzeichnis.

# /etc/environment.conf
---
:cachedir: /var/cache/r10k
:sources:
   :environments:
     remote: ssh://root@localhost/opt/puppet/environments.git
     basedir: /etc/puppet/environments

Hier ein kurzer Ausschnitt über den Aufbau des Git-Repositories. Der Masterbranch wurde von „master“ umbenannt in „production“, um hier mit Puppet auf einen gemeinsamen Nenner zu kommen. Aktuell gibt es zwei Branches: production und testing.

658084 drwxr-xr-x 10 root root 4.0K May 10 22:30 .
702437 drwxr-xr-x  3 root root 4.0K Dec 18  2014 ..
715811 -rw-r--r--  1 root root  207 Apr 30 21:50 environment.conf
832255 drwxr-xr-x 28 root root 4.0K Apr 30 21:57 forge/
658085 drwxr-xr-x  8 root root 4.0K Jul 14 22:56 .git
133592 drwxr-xr-x  4 root root 4.0K May 10 22:28 hieradata/
659093 drwxr-xr-x  2 root root 4.0K Apr 28 21:28 manifests/
659095 drwxr-xr-x 24 root root 4.0K May 10 21:59 modules/
718207 -rw-r--r--  1 root root 2.0K May 10 22:30 Puppetfile
727181 drwxr-xr-x 26 root root 4.0K Apr 30 21:56 puppetlabs/
658124 -rw-r--r--  1 root root    2 Dec 18  2014 README
727182 drwxr-xr-x 10 root root 4.0K Apr 30 21:56 theforeman/
659308 drwxr-xr-x  2 root root 4.0K Dec 18  2014 tools/

Die Modulpfade werden mit einer environment.conf konfiguriert. Dies hat den schönen Vorteil, das man hier sauber zwischen Testing und Production trennen kann und je nach Branch zusäzliche Verzeichnise ohne viel Aufwand einbringen kann. Die Trennung nach Quelle der Module ist einfach Geschmackssache und hat keinen wirklichen technischen Vorteil.

# environment.conf
modulepath = puppetlabs:theforeman:forge:modules:/etc/puppet/modules:/usr/share/puppet/modules
manifest = manifests
#config_version = get_environment_commit.sh
#environment_timeout = 180

Die eigentliche Logik für alle „externen“ Module liegt in der Datei „Puppetfile“. Dieses File wird von r10k je nach Wunsch bei jedem Deployment evaluiert. Dort können Module aus Git und SVN-Repos oder aber Module aus der Puppet Forge (Forge API) eingebunden werden. Hier noch eine Doku von Puppetlabs zum Thema Puppetfile. Hier meine momentane Konfiguration, mit der ich sehr glücklich bin (aufklappen, um die komplette Config zu sehen).

#!/usr/bin/env ruby
#^syntax detection

# puppetlabs
moduledir 'puppetlabs'
mod 'puppetlabs/acl'
mod 'puppetlabs/apt'
mod 'puppetlabs/activemq'
mod 'puppetlabs/apache'
mod 'puppetlabs/concat'
mod 'puppetlabs/corosync'
mod 'puppetlabs/dism'
mod 'puppetlabs/firewall'
mod 'puppetlabs/inifile'
mod 'puppetlabs/java'
mod 'puppetlabs/java_ks'
mod 'puppetlabs/mssql'
mod 'puppetlabs/mysql'
mod 'puppetlabs/ntp'
mod 'puppetlabs/postgresql'
mod 'puppetlabs/powershell'
mod 'puppetlabs/puppetdb'
mod 'puppetlabs/rabbitmq'
mod 'puppetlabs/reboot'
mod 'puppetlabs/registry'
mod 'puppetlabs/stdlib'
mod 'puppetlabs/vcsrepo'
mod 'puppetlabs/win_desktop_shortcut'
mod 'puppetlabs/xinetd'
# conflicts with theforeman/git
#mod 'puppetlabs/git'

# theforeman
moduledir 'theforeman'
mod 'concat_native', :git => 'https://github.com/theforeman/puppet-concat_native.git'
mod 'dhcp', :git => 'https://github.com/theforeman/puppet-dhcp.git'
mod 'dns', :git => 'https://github.com/theforeman/puppet-dns.git'
mod 'foreman', :git => 'https://github.com/theforeman/puppet-foreman.git'
mod 'foreman_proxy', :git => 'https://github.com/theforeman/puppet-foreman_proxy.git'
mod 'git', :git => 'https://github.com/theforeman/puppet-git.git'
mod 'puppet', :git => 'https://github.com/theforeman/puppet-puppet.git'
mod 'tftp', :git => 'https://github.com/theforeman/puppet-tftp.git'

# forge
moduledir 'forge'
mod 'acme/sysstat'
mod 'adrien/alternatives'
mod 'akumria/nullmailer'
mod 'crayfishx/gemsource'
mod 'darin/zypprepo'
mod 'duritong/trocla'
mod 'elasticsearch/logstash'
mod 'garethr/erlang'
mod 'hunner/hiera'
mod 'ispavailability/file_concat'
mod 'jdowning/rbenv'
mod 'liamjbennett/win_facts'
mod 'nanliu/staging'
mod 'pdxcat/collectd'
mod 'richardc/datacat'
mod 'rismoney/chocolatey'
mod 'rtyler/jenkins'
mod 'saz/memcached'
mod 'saz/sudo'
#mod 'spotify/puppetexplorer'
mod 'stahnma/epel'
mod 'thias/mailman'
mod 'thias/postfix'
mod 'thomasvandoren/etckeeper'
#mod 'wcooley/nss_pam_ldapd'
mod 'yguenane/authconfig'
mod 'ghoneycutt/dnsclient'

Wer genau hinsieht bemerkt hier das ich alle Module des Foreman Projekts immer aus dem GitHub Masterbranch ziehe. GitHub würde ich generell als Anlaufstelle für Foreman weiterempfehlen. Das Projekt Foreman bringt seine Updates nur sehr unregelmäßig in die Forge ein, wodurch man dann auf wichtige Features wie Support für den Puppetserver sehr lange warten oder gar komplett verzichten müsste.

Bei obiger Konfiguration handelt es sich um das Testing Environment. Das schöne an r10k in Zusammenhang mit einem Puppetfile ist, das auch hier das branchen ohne Probleme funktioniert. Währand ich mich in meinem Test-Environment z.B. immer auf die aktuellsten Versionen oder den Masterbranch bei GitHub ausrollen kann, ist es mir auch möglich Module auf gewisse Versionsstände zu pinnen.

# Pinnen auf einen commit (auch möglich: tags oder branches)
mod 'apache',
  :git    => 'https://github.com/puppetlabs/puppetlabs-apache',
  :commit => 'a0224412893d39463a4fde82887312b279f83e1b'

# Das ganze mit Modulen aus der Puppet Forge
mod 'puppetlabs/apache', '0.10.0'

Dadurch können alle Updates von externen Modulen „sanft“ eingeführt werden und durch alle Environments getestet werden.

Der Worklow bei der Modulentwicklung gestaltet sich dann wie folgt.

# Änderungen am Git-Repo durchführen und commiten
root@foreman01.linux-dev.de:/opt/puppet/environments.git
-bash# git commit -a -m "Neues Feature"
[production 9a5a113] Neues Feature
 1 file changed, 3 insertions(+)

# Push zum Remote
root@foreman01.linux-dev.de:/opt/puppet/environments.git
-bash# git push
Counting objects: 11, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 535 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To git@intern01.linux-dev.de:/opt/git/environments.git
   36a61ec..9a5a113  production -> production

# Deployment aller Branches via r10k
root@foreman01.linux-dev.de:/opt/puppet/environments.git/modules
-bash# r10k deploy environment -v -p
[R10K::Action::Deploy::Environment - INFO] Deploying environment /etc/puppet/environments/testing
[R10K::Action::Deploy::Environment - INFO] Deploying environment /etc/puppet/environments/production

[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/puppetlabs/acl
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/puppetlabs/apt
...
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/theforeman/concat_native
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/theforeman/dhcp
...
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/forge/sysstat
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/forge/alternatives
...

Je nach Bedarf kann man r10 mit oder ohne den Parameter „-p“ ausführen. Mit „-p“ wird das Puppetfile evaluiert und die Module aus der Forge bzw. GitHub eingebunden. Lässt man den Parameter weg, werden ausschließlich die Environments ausgerollt. Empehlenswert ist evtl. auch einen Post-Commit Hook in der Repository für r10k einzurichten. Hat man mehrere Master im Einsatz können die Tools ansible oder mcollective hier unterstützen.

Citrix NetScaler 11: A+ Rating bei Qualys SSL Labs

Qualys SSL LabsNachfolgend ein kurzes Cheat-Sheet, um für Webseiten, die auf bzw. hinter einem Citrix NetScaler gehostet sind beim SSL Test von Qualys für seine Webseite ein A+ zu erhalten. Dank NetScaler Version 11 ist dies nun endlich auch für die virtuellen VPX Appliances möglich.

Zunächst benötigt man eine eigene Ciphergruppe, die den Secrurity Standard etwas höher setzt, als die von Haus aus mitgelieferten Gruppen. Für MPX und SDX Appliances kann für den zu konfigurierenden vServer folgende Cipher Group verwendet werden.

add ssl cipher cipher_secure_default
bind ssl cipher cipher_secure_default -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher cipher_secure_default -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher cipher_secure_default -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher cipher_secure_default -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher cipher_secure_default -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl cipher cipher_secure_default -cipherName TLS1-ECDHE-RSA-AES128-SHA
bind ssl cipher cipher_secure_default -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384
bind ssl cipher cipher_secure_default -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256
bind ssl cipher cipher_secure_default -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA
bind ssl cipher cipher_secure_default -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
bind ssl cipher cipher_secure_default -cipherName TLS1-AES-256-CBC-SHA
bind ssl cipher cipher_secure_default -cipherName TLS1-AES-128-CBC-SHA
bind ssl cipher cipher_secure_default -cipherName SSL3-DES-CBC3-SHA

Für die NetScaler VPX kann folgendes Set benutzt werden (hier werden aktuell nicht alle Ciphers unterstützt).

add ssl cipher cipher_secure_default_vpx
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-ECDHE-RSA-AES128-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-AES-256-CBC-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName TLS1-AES-128-CBC-SHA
bind ssl cipher cipher_secure_default_vpx -cipherName SSL3-DES-CBC3-SHA

Zusätzlich benötigt man noch eine Rewrite Policy, um den HTTP STS Header in die Server Response einzufügen. Diese Policy kann entweder global oder für jeden vServer gebunden werden.

add rewrite action act_rewrite_inject_http_sts_header insert_http_header Strict-Transport-Security "\"max-age=31536000\""
add rewrite policy pol_rewrite_inject_http_sts_header true act_rewrite_inject_http_sts_header

Final sollte SSLv3 global oder lokal mittels SSL Profile deaktiviert werden.

add ssl profile prof_ssl_default -sessReuse ENABLED -sessTimeout 120 -ssl3 DISABLED

ProGet als bessere Chocolatey Repository Verwaltung

So, eine kleine Forsetzung vom letzten Beitrag. Ich hatte gezeigt das Chocolatey auch CIFS-Shares bzw. UNC-Pfade und lokale Verzeichnise als Install Source supportet. Für eine sehr kleine lokale Repository reicht das auch aus. Leider muss man dann natürlich auf das nette Feature von pushen von Paketen verzichten. Außerdem bin ich als Linux Admin selbst kein wirklicher Freund von CIFS. Generell war ich mit der Lösung nicht voll zufrieden.

Mein primäres Ziel war eigentlich einen NuGet.Server aufzusetzen. Versucht habe ich es, aber nach einigen Studen Arbeit in Visual Studio for Web und der Anpassung IIS Konfiguration habe ich es nun aufgegeben. Viel mehr als die Startseite funktionierte nicht, beim Package Discovery blieb es bei einem HTTP Error 404.

Durch das Debugging bin ich aber über eine Google Group an eine deutlich schönere und auch einfachere Lösung gestoßen. ProGet ist ein Repository Server für NuGet und Chocolatey mit kommerziellen Hintergrund, den es aber auch freie Version gibt.

Die Installation ist Windowstypisch extrem einfach. Durchklicken und es funktioniert. ProGet benötigt einen SQL-Server (SQL Express) und einen Webserver (wahlweise einen eigenen eine vorhandene IIS Instanz). Das wars.

ProGet

ProGet hat viele nette Features. Pakete können über Web oder den NuGet Push hochgeladen werden. Das Caching sowie das Staging von Paketen in verschiedenen Environments ist möglich und die Webadministration kann sauber in eine LDAP Struktur integriert werden.

An dieser Stelle sei nochmal erwähnt: Microsofts One-Get setzt auf dem Chocolatey Paketmanagement auf. Mit dem offiziellen Release von PowerShell v5 (aktuell ist das Projekt noch im „Preview“ Status) können diese Repositorys auch nativ in Windows genutzt werden.

Ich halte Chocolatey und NuGet für eine zukunftsweisende Lösung von einfacher Softwareverteilung unter Windows. Gerade dann, wenn man das ganze als eine Art Framework nutzt und in Puppet etc. einbindet. Wir werden sehen wie es mit dem Chocolatey Projekt weiter geht. Aktuell läuft hier auf Kickstarter ein Crowdfunding, mit dem sich das Projekt dann sein Büro einrichten möchte und eine kommerzielle „Chocolatey Enterprise“ Lösung schaffen möchte. Dazu kommt natürlich Microsoft, die durch One-Get hier auch einiges voran bringen sollten.