Icinga 2 – Monitoring automatisiert mit Puppet Teil 13: Profile Part V

This entry is part 13 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Im heutigen Teil dieser Reihe, fügen wir den ausstehenden Code zur Konfiguration von Nginx als Webserver für Icinga Web 2 hinzu. Neben den benötigten Nginx-Ressources, vor allem der Umleitung auf den PHP-FPM, ist darauf zu achten, dass Nginx vor der Klasse icingaweb2 und damit vor dem Paket icingaweb2 abzuarbeiten ist. Wird dies nich beachtet installiert das icingaweb2-Paket automatisch den Apache als Abhängigkeit und man hätte zwei Webserver bei sich auf dem Icinga-2-Server.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse nginx aus dessen Modul.

  [...]
 if $web_server == 'nginx' {
    #
    # Nginx
    #
    $manage_package = true
    Class['nginx']
      -> Class['icingaweb2']
    class { '::nginx':
      manage_repo  => false,
      server_purge => true,
      confd_purge  => true,
    }
    $web_conf_user = $::nginx::daemon_user
    nginx::resource::server { 'icingaweb2':
      server_name          => [ 'localhost' ],
      ssl                  => false,
      index_files          => [],
      use_default_location => false,
    }
    nginx::resource::location { 'icingaweb2':
      location       => '~ ^/icingaweb2(.+)?',
      location_alias => '/usr/share/icingaweb2/public',
      try_files      => ['$1', '$uri', '$uri/', '/icingaweb2/index.php$is_args$args'],
      index_files    => ['index.php'],
      server         => 'icingaweb2',
      ssl            => false,
    }
    nginx::resource::location { 'icingaweb2_index':
      location       => '~ ^/icingaweb2/index\.php(.*)$',
      server         => 'icingaweb2',
      ssl            => false,
      index_files    => [],
      fastcgi        => '127.0.0.1:9000',
      fastcgi_index  => 'index.php',
      fastcgi_param  => {
        'SCRIPT_FILENAME'         => '/usr/share/icingaweb2/public/index.php',
        'ICINGAWEB_CONFIGDIR' => '/etc/icingaweb2',
        'REMOTE_USER'         => '$remote_user',
      },
    }
  } else {
  [...]

Beim Nginx selbst werden alle von der Standard-Installation kommenden virtuellen Hosts (server_purge => true) und sonstigen Konfigurationsdateien entfernt. Der Artikel der kommenden Woche schließt diesen Abschnitt über eine komplexere Konfiguration vorerst ab. Dort wird dann der noch fehlende Code präsentiert, der einen Apache-Webserver zum Ausliefern von Icinga Web 2 verwendet.

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 11: Profile Part III

This entry is part 11 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Die heutige Fortsetzung dieser Serie befasst sich mit dem Management einer PHP-Umgebung für daen Betrieb eines Icinga Web 2 auf dem Icinga-Server. Icinga Web 2 benötigt in aktuellen Versionen mindestens ein PHP in der Version 5.6, kommen dann noch Module hinzu, wird damit einhergehend ein PHP 7 oder neuer vorausgesetzt.
Server mit Debian Stretch bekommen ein aktuelles PHP aus ihren eigenen Repositories, bei RedHat 7 muss auf das SCL (Softwarer Collection Linux) Repository zurückgegriffen werden.

class profile::icinga2::server(
  ...
) {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      require ::profile::repo::scl
      $manage_package = false
      $manage_repo    = false
      $php_globals    = {
        php_version => 'rh-php71',
        rhscl_mode  => 'rhscl',
      }
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysqlnd => {}, pgsql => {}, },
      ...
    }
    'debian': {
      $manage_package = true
      $manage_repo    = true
      $php_globals    = {}
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysql => {}, pgsql => {}, },
      ...
    }
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  }
  ...

PHP selbst lässt sich mit dem Puppet-Module puppet/php des Projektes Vox Pubuli konfigurieren. Hierbei werden über die Klasse php::globals Einstellungen getätigt, welches PHP, aus welchen Quellen benutzt werden soll. Im Anschluss wir über die Hauptklasse php das Management auf das Betreiben eines FPM (FastCGI Process Manager) eingeschränkt. Dieser lauscht standardmäßig auf TCP-Port 9000 ausschließlich auf localhost.
Neben einem erhöhen des Speicherlimits und dem Setzen der Zeitzone, werden auch die von Icinga Web vorausgesetzten PHP-Extensions aktiviert.

...
#
# PHP
#
class { '::php::globals':
  * => $php_globals,
}
class { '::php':
  ensure        => installed,
  manage_repos  => false,
  apache_config => false,
  fpm           => true,
  extensions    => $php_extensions,
  settings      => {
    'PHP/memory_limit'   => '128M',
    'Date/date.timezone' => 'Europe/Berlin',
  },
  dev           => false,
  composer      => false,
  pear          => false,
  phpunit       => false,
  require       => Class['::php::globals'],
}

Bei der Klasse profile::repo::scl beschränken wir uns im folgenden Beispiel auf CentOS basierte Systeme, wie es auf RHEL einzubinden ist muss aus der Installations-Dokumentation abgeleitet werden.

class profile::repo::scl {
  case $::operatingsystem {
    'centos': {
      package { 'centos-release-scl':
        ensure => installed,
      }
    } # CentOS
    default: {
      fail("'Your plattform ${::operatingsystem} is not supported.'")
    }
  } # case
}
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.

Tracing PHP memory usage with Xdebug


In addition to Xdebug’s great profiling and debugging features it also supports tracing memory usage. This helps to find functions which consume a lot of memory or to identify memory leaks. The following options enable tracing right away:

xdebug.auto_trace=1
xdebug.trace_format=1

Traces are written to /tmp by default. You may change this via the xdebug.trace_output_dir setting. With xdebug.trace_format=1 you tell Xdebug to write traces in an easy-to-parse tab separated format. The logged information includes the start and end times of function calls as well as the amount of used memory when entering and leaving the function. The last two numbers help to figure out which functions increase the memory usage a lot. Luckily you don’t have to interpret the traces yourself but use a script for that.
The script parses the trace files and aggregates the numbers by function name. It accepts a few different keys to sort the output: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure the number of elements to show:

php tracefile-analyser.php trace.662975268.xt memory-own 10
Showing the 10 most costly calls sorted by 'memory-own'.
                                                          Inclusive        Own
function                                          #calls  time     memory  time     memory
------------------------------------------------------------------------------------------
Icinga\Application\ClassLoader->loadClass             90  0.9151  2638176  0.0814  1262312
Zend_Loader::loadFile                                 17  0.1496  1183528  0.0345   882928
PDOStatement->execute                                 22  0.0102   395368  0.0102   395368
require                                               85  0.6066  1548112  0.0157   338512
require_once                                          22  0.0506   566296  0.0107   149128
Icinga\Application\ClassLoader->requireZendAutoloader  1  0.0045   154360  0.0023   120136
Composer\Autoload\includeFile                          8  0.0148    86544  0.0028    59448
Zend_Db_Select->_join                                 41  0.2599    59368  0.0627    57072
explode                                              135  0.0341    55672  0.0341    55672
Icinga\Application\Benchmark::measure                 94  0.2099    47448  0.0737    47352
Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Canonical schließt Lücken in Ubuntu 18.04 LTS

Common Vulnerabilities and Exposures (CVE) ist ein Industriestandard, dessen Ziel die Einführung einer einheitlichen Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen ist. Mehrfachbenennung gleicher Gefahren durch verschiedene Unternehmen und Institutionen werden um eine laufende Nummer ergänzt, um eine eindeutige Identifizierung der Schwachstelle zu gewährleisten. Dadurch ist ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich.

Canonical hat ein neues Kernel-Update für Ubuntu 18.04 LTS veröffentlicht, indem Lücken, die im VirtIO-Subsystem und dem ACPI Kernel stecken, gepatcht werden. Eine Lücke in der Speicherinitialisierung (CVE-2018-1118) im VirtIO-Subsystem des Kernels, die nicht immer funktionierte, wurde entfernt. Hier konnte ein Angreifer über einen lokalen Zugriff vertrauliche Informationen erhalten. Die zweite Lücke betrifft das ACPI (Advanced Configuration and Power Interface) des Kernels wodurch auch ein lokaler Angriff Erfolg hätte.
Außerdem gab es mehrere Schwachstellen in der PHP-Komponente FPM und EXIF bei denen Angreifer auch lokal mit speziell präpariertem PHP-Skripten die Vorbereitung von verschiedenen DoS-Angriffen ausführen konnten. Später dann auch aus der Ferne steuerbar. Die Schwachstellen CVE-2018-14851 und CVE-2018-14883 lassen den Angreifer beliebigen Programmcode ausführen. CVE-2015-9253 lassen sich aus der Ferne für DoS-Angriffe auf geteilte PHP-Server ausführen.
Die Updates stehen seit längerem für Ubuntu 18.04 LTS, 16.04 LTS und 14.04 LTS bereit.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Event-driven, async I/O with PHP

Ever wondered whether it is possible to write asynchronous code in PHP? Good news, it is! One of the most promising libraries is ReactPHP. It provides the powerful concept of event-driven, non-blocking I/O in PHP. Its core is an event loop, on top of which it provides utilities like stream abstraction and async network clients and servers. The library is written in pure PHP and its architecture is well-suited for high performance network servers and clients. The documentation and examples of ReactPHP’s components are quite detailed so it should be no problem to get started. The following example is a simple asynchronous web server written in ReactPHP which responds with “Hello World” for every request.

$loop = React\EventLoop\Factory::create();
$server = new React\Http\Server(function (Psr\Http\Message\ServerRequestInterface $request) {
    return new React\Http\Response(
        200,
        array('Content-Type' => 'text/plain'),
        "Hello World!\n"
    );
});
$socket = new React\Socket\Server(8080, $loop);
$server->listen($socket);
echo "Server running at http://127.0.0.1:8080\n";
$loop->run();
Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Außerhalb von NETWAYS: Projektwoche in der Berufsschule

Heute möchte ich einen Blick außerhalb der betrieblichen Ausbildung werfen und ein wenig über die Projektwoche in der Berufsschule berichten. Alle Auszubildenden, die die Berufsschule B3 in Fürth im Zweig Fachinformatik Systemintegration oder Anwendungsentwicklung besuchen, führen dort am Ende des 2. Ausbildungsjahres eine Projektwoche durch.
Innerhalb dieser Projektwoche arbeiten die Schüler einer Klasse in Gruppen von 12 – 15 Mitgliedern zusammen. Dabei wird vor allem darauf geachtet, dass die Stärken der Schüler gleichmäßig auf die Gruppen verteilt werden.
Das Projekt selbst bestand aus der Simulation eines Kundenauftrages an eine Firma, die sowohl die Umsetzung von IT-Infrastrukturen als auch Software-Entwicklung bietet. Die Belegschaft der Firma wurde dann wie folgt auf die Mitschüler aufgeteilt:

  • Abteilung Management: 3 Schüler
  • Abteilung Infrastruktur: 3 Schüler
  • Abteilung Entwicklung: 6 Schüler

Die Gewichtung ergab sich aus der Analyse des Lastenheftes, das vom Lehrerkollegium zuvor ausgearbeitet und ausgehändigt wurde. Darin ging es darum, dass für den Kunden eine Infrastruktur und Software aufgebaut werden soll, mit der der Kunde sämtliches IT-Inventar in seinen Räumlichkeiten verwalten kann. Der Kunde selbst wurde dabei durch unsere Schule und einen Teil des Lehrerkollegiums dargestellt. Folgende Punkte waren dabei besonders von Bedeutung:

  • Netzwerk mit VLANs (Trennung von Schul- und Administrationsnetzwerk) mit Access Points für WLAN
  • Web- und Datenbankserver, auf denen die Inventarisierungssoftware laufen soll
  • Mit der Software müssen folgende Aktionen machbar sein:
    • Auflisten von Inventar
    • Ändern, Löschen und Hinzufügen von Inventar
    • Zuordnung von Inventar zu Räumen und Klassenzimmern
    • Login mit User/Passwort und Vergabe von Rechten (Admin oder User)
  • Einrichten von Clients für die Nutzung des Webfrontends der Software
    • Aufrufbar über Browser
    • Ergonomie muss beachtet werden
  • Erstellung eines Pflichtenheftes, einer Kundendokumentation und eines Wartungsvertrages
    • Pflichtenheft und Wartungsvertrag muss von den Lehrkräften abgenommen werden
    • Kundendokumentation soll als Benutzerhandbuch fungieren
  • Abschließende Projekt-Präsentation vor Publikum mit abschließender Fragerunde
  • Zeitlicher Rahmen: Montag bis Donnerstag, Umsetzung des Projektes mit freier Zeiteinteilung, Freitag morgen Präsentation

Nachdem wir den Montagvormittag damit verbrachten, die Aufgabenstellung durchzuplanen, setzten wir im Laufe der Woche die folgenden Schritte um:

  • Erstellung Pflichtenheft
  • Aufbau Netzwerk
  • Aufbau LAMP-Stack auf Server
  • Aufbau der MySQL-Datenbank
  • Erstellung der Core Software aus php und javascript
  • Erstellung des Webfrontends mit html und php
  • Erstellung Wartungsvertrag
  • Erstellung und Planung Projekt-Präsentation
  • Ausführliches Testen der einzelnen Komponenten
  • Fehlersuche, Debugging und Korrekturen
  • Erstellung Kundendokumentation, direkt aufrufbar über die Hilfe-Funktion in der Software

Mit dem Ergebnis aus dieser Woche konnten wir dann auch unsere Lehrer überzeugen, die unsere Gruppe durchweg positiv bewerteten und sehen konnten, dass wir als Klasse viel Wissen aus den letzten beiden Schuljahren mitgenommen haben.
Als Fazit kann ich persönlich sagen, dass es auf jeden Fall eine tolle und konstruktive Erfahrung ist, einmal komplett eigenverantwortlich und mit eigener Zeiteinteilung eine solche Aufgabe zu bewältigen. Außerdem bringt dies die Schüler auch zwischenmenschlich und bzgl. der eigenen Persönlichkeit weiter, denn jeder lernt nicht nur die eigenen Stärken und die der Mitschüler kennen und schätzen, sondern muss auch mit Schwächen und Fehlschlägen zurechtkommen bzw. anderen aus diesen heraushelfen. Es ist eben doch ganz gut, wenn man ab und zu mal die eigene Komfortzone verlässt!
Wer sich nun angesprochen fühlt, auch mal in die IT-Welt zu schnuppern oder mit dem Gedanken spielt, eine Ausbildung im Bereich Informatik zu machen, dann schreibt uns doch einfach unter jobs@netways.de. Mehr Infos findet Ihr auch auf unserer Webseite oder in unserer Stellenausschreibung zum Azubi Fachinformatik. Mehr Informationen zum Thema Ausbildung Fachinformatiker findet Ihr auch auf der Webseite der IHK.
 
Bildquellen: 
https://www.unixmen.com/how-to-install-lamp-stack-ubuntu-17-04/
http://www.b3-fuerth.de/ 

Nicole Lang
Nicole Lang
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...