Meine ersten eigenen Projekte

Das letzte Mal das ich einen Blogpost geschrieben habe ist jetzt schon ein Weilchen her und das Thema hat sich wenig mit meiner Arbeit beschäftigt – Teamwochenende.

Doch in den letzten Wochen habe ich meine ersten eigenständigen Projekte bekommen. Zunächst hat mir Markus die Aufgabe gegeben eine Backup-Lösung für unsere Notebooks zu finden. Vorgabe hierzu war es, sowohl Disaster Recovery und normale Datensicherung zu bewerkstelligen. Dies habe ich mittels Relax and Recover und DejaDub gelöst.

Natürlich hatte die Aufgabe ihre Tücke, wenn man noch keine Erfahrung mit dem Thema hat, aber zum Einstieg war das genau richtig. Vor Allem hat mir die Aufgabe die Möglichkeit gegeben nicht nur Erfahrung sondern auch Selbstvertrauen zu sammeln.

Danach bekam ich das Stichwort “Puppetized Graphing” zugeworfen, dahinter verbirgt sich dass ich Grafana und Graphite via Puppet installieren sollte. Ziel war es auch das Graphite und Grafana miteinander kommunizieren und alles was dazu gehört, sprich Datenbank und ähnliches. Ich durfte bei Netways auch schon einige Schulungen absolvieren und habe über entsprechende Grundlagenkenntnisse von Puppet verfügt, genauso wie Graphite und Grafana, und hatte auch Unterlagen, sowie Referenzen, aber einige Fallstricke kamen bei dem Thema trotz alledem auf mich zu.

In dem Zeitraum habe ich dutzende Versuche gestartet und bin oft hingefallen und hab Dinge gelernt, die ich ursprünglich gar nicht mit dem Thema in Verbindung gebracht hätte. Zu keinem Zeitpunkt hab ich mich allein gefühlt in meiner Aufgabe, denn auch wenn mal ein Kollege grinsend an der gigantischen Fehlerausgabe vorbei lief, wurde oft genug gefragt ob man mir den helfen könnte und auch umgekehrt, hat mich keiner abgewunken, wenn ich mal Hilfe brauchte.

 

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI

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

Nachdem letzte Woche der Nginx verwendet wurde, wenden wir uns im nun vorerst letzten Teil der Konfiguration des Apaches als Webserver zur Auslieferung von Icinga Web 2 zu.
Der Apache kommt unter Debian als abhängig zu installierendes Paket von icingaweb2 mit und wird ensprechend konfiguriert. Damit dies unsere Anforderung an den Apache nicht wieder überschreibt, sorgen wir dafür, dass das Paket icingaweb2 vor der Klasse apache installiert wird. Hierfür müssen wir das Managment des Pakets durch die Klasse icingaweb2 unterbinden.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse apache aus dessen Modul.

 
  
if $web_server == 'nginx' {
     [...]
  } else {
    #
    # Apache
    #
    $manage_package = false
    Package['icingaweb2']
      -> Class['apache']
    package { 'icingaweb2':
      ensure => installed,
    }
    class { '::apache':
      default_mods => false,
      default_vhost =>false,
      mpm_module => 'worker',
    }
    apache::listen { '80': }
    $web_conf_user = $::apache::user
    include ::apache::mod::alias
    include ::apache::mod::status
    include ::apache::mod::dir
    include ::apache::mod::env
    include ::apache::mod::rewrite
    include ::apache::mod::proxy
    include ::apache::mod::proxy_fcgi
    apache::custom_config { 'icingaweb2':
      ensure       => present,
      source        => 'puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf',
      verify_config => false,
      priority      => false,
    }
  }
  [...]

Der Apache wird von uns komplett mit allen Modulen für Icinga Web 2 verwaltet, da sich die Defaults für RedHat und Debian zu sehr unterscheiden. Auch hier, wie bei Nginx, entfernen wird alle Konfiguration sonstiger auszuliefernder Webseiten und benutzen die vom Icinga-Web-2-Modul zur Verfügung gestellt Beispielkonfiguration.

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 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 12: Profile Part IV

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

Heute geht es mit der Konfiguration von Icinga Web 2 weiter, nach dem im letzte Teil als Voraussetzung PHP konfiguriert wurde. Als Backend zur Speicherung von Authentifizierungs- und Benutzerdaten, kommt eine eigene MySQL Datenbank auf dem gleichen lokalen System zum Einsatz. Der Datenbank- und der Benutzername, sowie dass Passwort soll mittels Parameter festgelegt werden könnten, das gleiche gilt für den zum Senden von Kommandos an Icinga benötigten API-Benutzer und man soll sich als Webserver zwischen einem Apache bzw. einem Nginx entscheiden können. Die Konfiguration letztgenannter, wird im nächsten Teil der kommenden Woche behandelt.

class profile::icinga2::server(
  String                    $web_db_pass,
  String                    $web_api_pass,
  ...
  String                    $web_db_user  = 'icingaweb2',
  String                    $web_db_name  = 'icingaweb2',
  String                    $web_api_user = 'icingaweb2',
  Enum['apache', 'nginx']   $web_server   = 'apache',
) {
  ...
  mysql::db { $web_db_name:
    host     => $web_db_host,
    user     => $web_db_user,
    password => $web_db_pass,
    grant    => ['ALL'],
    before   => Class['icingaweb2'],
  }
  if $web_server == 'nginx' {
    $manage_package = true
#    $web_conf_user =
  } else {
    $manage_package = false
#    $web_conf_user =
    package { 'icingaweb2':
      ensure => installed,
    }
  }
  class { 'icingaweb2':
    db_username    => $web_db_user,
    db_password    => $web_db_pass,
    import_schema  => true,
    config_backend => 'db',
    conf_user      => $web_conf_user,
    manage_package => $manage_package,
  }
  ::icinga2::object::apiuser { $web_api_user:
    ensure      => present,
    password    => $web_api_pass,
    permissions => [ 'status/query', 'actions/*', 'objects/modify/*', 'objects/query/*' ],
    target      => '/etc/icinga2/conf.d/api-users.conf',
  }
  class { '::icingaweb2::module::monitoring':
    ido_db_host       => '127.0.0.1',
    ido_db_name       => $ido_db_name,
    ido_db_username   => $ido_db_user,
    ido_db_password   => $ido_db_pass,
    commandtransports => {
      'icinga2' => {
        transport => 'api',
        username  => $web_api_user,
        password  => $web_api_pass,
      }
    }
  }
}
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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II

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

In Weiterführung vom letzten Post dieser Serie, beschäftigen wir uns zuerst damit dem Icinga-Server eine CA hinzuzufügen. Dies erledigt die Deklaration der Klasse icinga2::pki::ca. Sie erzeugt auch noch gleich ein Zertifikat für den eigenen Server.
Das ist auch der Grund, warum im Folgenden der Parameter pki des Features API mit none belegt werden muss, da genau dies verhindert, dass nochmals versucht wird ein Zertifikat zu generieren. Dieser Wert für pki ist also nur sinnvoll für Hosts mit einer Icinga-2-CA.

class profile::icinga2::server {
  ...
  #
  # CA / API
  #
  include ::icinga2::pki::ca
  class { '::icinga2::feature::api':
    pki             => 'none',
    accept_commands => true,
  }

Als nächstes widmen wir uns dem Feature IDO, welches die IDO-DB befüllt, hier eine MySQL-Datenbank, die ebenfalls per Puppet verwaltet werden soll und sich auch dem gleichen Server befindet. Hierfür ist zusätzlich das MySQL-Puppetmodule erforderlich. Das Datenbank-Schema kann vom Icinga2-Modul automatisch angelegt werden. Hierfür ist dann zu den üblichen Berechtigungen auch CREATE für den Benutzer, den auch Icinga für den Zugriff verwendet, erforderlich, da auch dieser zum initalen Erzeugen der Tabellen vom Icinga2-Modul verwendet wird.
In Bezug auf die Reihenfolge der Abarbeitung unserer Ressourcen, muss nur dafür Sorge getragen werden, dass die Datenbank für die IDO vor dem IDO-Feature dran kommt.
Für den zu verwenden Benutzernamen, das zugehörige Passwort und den eigentlichen Datenbanknamen fügen wir der Profilklasse Parameter hinzu. Im Gegensatz zum Datenbank- und Benutzernamen, die beide als Default icinga2 gesetzt bekommen, ist das Passwort als Parameter vom Endbenutzer immer selbst anzugeben.

class profile::icinga2::server(
  String   $ido_db_pass,
  String   $ido_db_name  = 'icinga2',
  String   $ido_db_user  = 'icinga2',
) {
  case $::osfamily {
    'redhat': {
      ...
      package { [ 'nagios-plugins-all', 'icinga2', 'icinga2-ido-mysql' ]:
        ensure => installed,
        before => User['icinga'],
      }
      ...
    }
    ...
  }
  #
  # Icinga 2
  #
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
  #
  # IDO database
  #
  include ::mysql::server
  mysql::db { $ido_db_name:
    user     => $ido_db_user,
    password => $ido_db_pass,
    host     => '127.0.0.1',
    grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
    before   => Class['icinga2::feature::idomysql']
  }
  class{ '::icinga2::feature::idomysql':
    user          => $ido_db_user,
    password      => $ido_db_pass,
    database      => $ido_db_name,
    import_schema => true,
  }

Auf RedHat-Systemen musste, wie in vorherigen Teil zu sehen war, da Paketmanagement aus dem eigentlichen Icinga-Modul herausgezogen werden, um den Benutzer icinga zwischen Paketinstallation und Icinga-Klasse verwalten zu können. Das bezieht sich nun ebenfalls auf das Paket icinga2-ido-mysql, das für das IDO-Feature erforderlich ist. Debianbasierte Systeme sind hiervon nicht betroffen.

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.