Seite wählen

NETWAYS Blog

Perl-Plugins standardisieren

Im Icinga- bzw. Nagios-Umfeld wird für Plugins gerne Perl eingesetzt. Das Monitoring Plugins Projekt stellt mit dem Monitoring Perl-Modul eine standardisierte Schnittstelle zur Verfügung mit der sich schnell und einfach eigene Plugins programmieren lassen, die den Richtlinien für Plugins entsprechen.
Auszüge aus einem Plugin zum Abfragen des Status eines Apache-Webservers soll den generellen Aufbau verdeutlichen. Das komplette Skript ist auf Github veröffentlicht.

$plugin = Monitoring::Plugin->new;

Zuerst instantiert man neues Objekt und bereitet mit der Methode Getopt->new die Verarbeitung von Optionen vor.

$options = Monitoring::Plugin::Getopt->new(
  usage   => 'Usage: %s [OPTIONS]',
  version => $VERSION,
  url     => 'https://github.com/lbetz/nagios-plugins',
  blurb   => 'Check apache server status',
);

Optionen mit beschreibenden Text für den Aufruf des Plugins werden dem Objekt mit der Methode arg hinzugefügt. Mit spec wird die Variable festgelegt in der, der Wert der Option abgelegt wird. Die Variable lautet hier hostname. Nach der Pipe folgt die Option für das Plugin, hier ein H. Die Zuweisung des Buchstabens s bedeutet, dass hier ein String übergeben wird.

$options->arg(
  spec     => 'hostname|H=s',
  help     => 'hostname or ip address to check',
  required => 1,
);

Weitere Typen sind i für einen Integer oder das als Suffix angehängte + für einen Schalter. Mit -s wird also gesteuert, dass die Anfrage via HTTPS zu erfolgen hat. getopts erledigt dann die Übernahme der Optionen in Variablen.

$options->arg(
  spec     => 'port|p=i',
  help     => 'port, default 80 (http) or 443 (https)',
  required => 0,
);
$options->arg(
  spec     => 'ssl|s+',
  help     => 'use https instead of http',
  required => 0,
);
$options->getopts();

Ausgehend davon, dass auch die üblichen Optionen für Schwellwerte implementiert sind, kann ein Threshold-Objekt erzeugt werden. Dieses wird später für die Status-Ermittlung herangezogen.

$threshold = Monitoring::Plugin::Threshold->set_thresholds(
  warning  => $warning,
  critical => $critical,
);

Die aus den Optionen ermittelten Variablen lassen sich nun für den HTTP-Request benutzen.

$request = HTTP::Request->new(GET => 'http://'.$options->hostname.'/server-status/?auto');

Nachfolgend ist der HTTP-Response auszuwerten. Hier ist in $OpenSlots die Anzahl der noch zur freien Verfügung stehen Slots abgelegt.

$plugin->add_perfdata(
  label => 'OpenSlots',
  value => $OpenSlots,
  uom   => q{},
  threshold => $threshold,
);

Performance-Daten lassen sich mit der Methode add_perfdata dem Pluginoutput hinzufügen, hier OpenSlots=n. Abschließend wird in Abhängigkeit der Schwellwerte der Return Code berechnet und das Plugin mittels exit beendet.

$plugin->nagios_exit($threshold->get_status($OpenSlots), 'some plugin output');
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Weekly Snap: Git & Apache, OSMC & PuppetConf 2013

weekly snap12 – 16 August shared tips for Git, Apache and performance graphing as well as a special on PuppetConf 2013 in San Francisco.
Eva started the week by counting 71 days to the OSMC with Eric Lippmann’s presentation on ‘Performance Graphing with inGraph’.
Meanwhile, Bernd got ready for PuppetConf 2013 and shared a code for 20% discount on tickets as Dirk showed how to bypass Apache authentication requirements.
Finally, Marius played with the Git filter-branch and Achim answered the question: “How do I delete old Git branches?

Apache und kein User

Lennarts und meine Blogposts zum Thema Apache-Authentifizierungen haben sich bisher eigentlich immer damit befasst wie man möglichst viele Benutzer aus einem zentralen Verzeichnisdienst durch den Webserver authentifiziert. Was aber tun wenn für bestimmte automatisierte Zugriffe keine Authentifizierung erwünscht ist? Komplett auf die Authentifizierung verzichten möchte man meist nicht, also muss eine Ausnahme her. Aber wie?
In Apache 2.2 heißt die Direktive dafür „Satisfy any“. Mit dieser lässt sich festlegen dass entweder eine Allow-Regel oder die Benutzer-Authentifzierung erfüllt werden muss. Als Konfigurationsabschnitt sieht dies dann beispielsweise so aus:

Order allow,deny
Allow from 192.168.0.23
Allow from 192.168.0.42
Include auth.inc
Satisfy any

Mit Apache 2.4 ändert dies sich zu:

<RequireAny>
Require host 192.168.0.23
Require host 192.168.0.42
Require valid-user
</RequireAny>

Damit könnte nun von die zwei Systemen ohne Authentfizierung anmelden. Handelt es sich dabei um Proxies können dies sogar noch wesentlich mehr sein. Was nun wenn aber eine Authentifizierung nötig ist um die gewünschten Rechte zu erlangen, wenn ohne Authentifizierung durch Apache der interne Authentifizierungsdialog erscheint? Muss sich nun doch überall immer und überall wer anmelden?
Auch hierfür gibt es eine Lösung, indem durch entsprechende Rewrite-Regeln automatisch ein Benutzer angemeldet wird. Einmal als Beispiel anhand von Nagvis und unseren zwei Systemen von oben:

RewriteEngine On
RewriteBase /nagvis
RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.23 [OR]
RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.42
RewriteRule ^(.*)$ - [E=REMOTE_USER:nagvisuser]

Diese Konfigurationszeilen in Kombination mit dem ersten Beispiel sorgen dafür, dass für die zwei Systeme die Benutzer-Authentfizierung entfällt und ihr Webseiten-Aufruf um die Umgebungsvariable REMOTE_USER mit dem Wert nagvisuser ergänzt wird. Somit wäre der Benutzer nagvisuser automatisch angemeldet.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Weekly Snap: MCollective, CCache & Apache Tips

weekly snap15 – 19 July offered tips for Puppet users, developers and sys admins alike, as well as news from the event circuit.
Starting with events, Eva counted 99 days to the OSMC 2013 with Rihards Olups’ presentation on Zabbix 2.0 while Lennart reported from DevOps Days Down Under in Australia.
Thomas then recommended Puppet users to try the MCollective orchestration framework as Gunnar upped the speed on his builds with ccache.
Lastly, Dirk offered a handy tip for large environments by showing how to integrate multiple LDAP servers in Apache authentication.

Apache und viele, viele User

Kollege Lennart hat zwar schon dankenswerterweise einiges zu Apache, Openldap und Active Directory geschrieben trotzdem ist dieses Thema noch nicht völlig erschöpft. Ich möchte diesmal die Anleitung liefern wie man mehrere verschiedene LDAP-Server bei der Apache-Authentifizierung nutzt. Auch nutzbar ist diese Lösung um mehrere Einstiegspunkte in den gleichen Verzeichnisbaum zu bekommen.
Die einen fragen sich nun wo soll da bitte die Schwierigkeit sein, die anderen wozu sollte man so etwas brauchen. Die Schwierigkeit hierbei stellt der LDAP-Provider dar, der nur eine LdapAuthURL akzeptiert. Der Grund dafür mehrere zu brauchen können mehrere Verzeichnisdienste für verschiedene Anwendergruppen sein oder auch ein Struktur im Active Directory, bei der sonst neue Gruppen gebildet und gepflegt werden müssten oder ein Verschieben der Benutzer innerhalb des Baums aus organisatorischen oder gar technischen Gründen nicht möglich ist.
Die Lösung hierfür heißt mod_authn_alias (oder ab 2.4 mod_authn_core). Mit diesem Modul lässt sich ein Alias für einen Authentfizierungs-Provider erstellen, so dass es möglich wird diesen mehrfach zu verwenden. Die Konfiguration könnte dann folgendermaßen aussiehen:

<AuthnProviderAlias ldap admins>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=admins,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias>
<AuthnProviderAlias ldap entwickler>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=entwickler,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias> 

Diese Konfiguration muss einmalig und vor der Verwendung eingebunden werden. Daher bietet sich ein Dateiname wie 00provider.conf an mit dem die Konfiguration im Apache-Konfigurationsverzeichnis abgelegt wird.
Für die Verwendung bietet es sich dann eine Datei auth.inc anzulegen, die dann in den einzelnen Konfigurationsdateien für die Webanwendungen mit include eingebunden werden kann. Diese sieht dann beispielsweise so aus:

AuthName "Icinga Access"
AuthType Basic
AuthBasicProvider admins entwickler
Require valid-user

Wer zusätzlich noch einen Fallback für einen anderen Provider benötigt kann diesen einfach hinzufügen und je nach Apache-Version einen Blick auf AuthzLDAPAuthoritative (2.2) oder RequireAny (2.4) werfen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.