NoCode, Security by Design

NoPicture

Bei Netways sind wir immer am Puls der Zeit und probieren für euch den neuesten heißen Sch**ß aus. Heute möchte ich euch deswegen NoCode vorstellen. Wenn man NoCode noch nicht kennt; es kann als logische Fortsetzung aller aktuellen Cloud Technologien und Everything as Code Initiativen gesehen werden. So konnte sich NoCode innerhalb kurzer Zeit einen zentralen Platz auf der CloudNative Landscape sichern
Am Anfang steht die Lochkarte. Auf dieser sind Programme binär abgespeichert und werden von damaligen Großrechnern ausgeführt. Leider enthält der Code dieser Anwendungen einige wenige Bugs, was allgemein Verunsericherung führte. Lochkarten werden nach kurzer Zeit wieder abgeschafft.

Weiter geht es mit solide programmierten Unix und Windows Serveranwendungen, die innerhalb von vielen Unternehmen hervorragende Dienste leisteten. Da mit zunehmender Vernetzung die Probleme dieser Lösungen offensichtlicher wurden und man nicht schnell genug hinterher kam einen Fehler immer wieder durch zwei neue zu ersetzen, schaffte man vielerorts diese Insellösungen wieder ab und setzte auf Standards. Das Glück für die schon beinahe von Arbeitslosigkeit bedrohten Admins, es gibt derlei sehr viele.
Mittlerweile haben wir Virtualisierung und können mit P(roblem)aaS, I(nsecure)aaS und S(anduhr)aaS fast alle Kundenwünsche im keim … erfüllen. Ab diesem Zeitpunkt, wo man dank DevOps und dezentralen verbindungslosen Orchestrierungstools seine Bugfixes auf tausende Container gleichzeitig deployen kann, wird es Zeit sich von diesen noch beinah beherrschbaren Problem Factories zu verabschieden.
Jetzt können papierlos, hardwareless, connectionless und configurationless einpacken. Wir machen serverless und führen Funktionen ‘direkt in der Cloud’ aus.
Da wir alles vom Strom, über das Netzwerk bis zum Server abschaffen, fehlt nur noch der Code.
Genau hier springt NoCode ein. Mit wenigen Zeilen NoCode kann man sich fast alle Anwendungsfälle moderner Applikationen vorstellen. Das beste an NoCode, es enthält niemals Bugs und kann für die verschiedensten Einsatzzwecke genutzt werden. Als erste Enterprise Monitoring Lösung hat auch icinga2 die NoCode notation eingeführt. Jedes in NoCode geschriebene config file wird klaglos von der Syntax Prüfung akzeptiert. Ein Kollege arbeitet gerade daran ein neues Backend Feature in NoCode zu implementieren. Ich habe noch keine Details gesehen, aber es rennt wie Sau.

Schaut euch unbedingt das NoCode github Repo von Kelsey Hightower, dem verantwortlichen google Hacker, an. Hier könnt ihr das Projekt auschecken und mit docker testen.

Wer jetzt heiß ist und mal eine Anwendung im live Betrieb sehen möchte. Die vom führenden Crypto Anbieter ROT26 angeboteny Crpyto API ist gerüchteweise in NoCode implementiert. Probiert es direkt aus

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Open Source Camp: Hurry up to get on stage!

You know how to automate things with Ansible? You enjoy sharing your knowledge with your fellows? Then hurry up to get on stage and become a speaker at OSCAMP!

Call for papers runs until February 2019! Submit your paper here.

Open Source Camp is a series of events giving Open Source projects a platform to present themselves to the community. Its third edition on Ansible takes place right after OSDC‘s lecture program on May 16 in Berlin.

 

#OSCAMP | May 16, 2019 | Berlin

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

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.

Landscape – On-Premise

Bei Netways muss jeder Azubi jede Abteilung durchlaufen. Grund hierfür ist die Arbeit der anderen Mitarbeiter besser zu verstehen und zu respektieren. Derzeit bin ich bei Managed Services, genauer noch im Customer Hosting. Im Zuge dessen sollte ich mich mit alternativen Verwaltungstools auseinandersetzen im speziellen mit Landscape.

Was ist Landscape?

Landscape ist ein Management-Tool von Canonical. Des Weiteren bietet Landscape einige kleinere Kapazitäten hinsichtlich Monitoring, darunter Netzwerk- und Speicherauslastung, aber auch verbleibende Speicherkapazität, Netzwerkbelastung oder derzeitiger SWAP-Verbrauch.

Der Kern der Anwendung ist jedoch die einfache Ausführung von Updates/Upgrades, sowie Scripts auf Systemen, sowie die Möglichkeit diese zu limitieren und individuell anzuwenden. Eine Reihe an weiteren Features werden von Canonical für Landscape beworben, die ihr hier finden könnt.

Was kostet Landscape?

Landscape’s Kosten variieren stark anhand der Umgebung, die man damit verwalten möchte. Jedoch gibt es die Möglichkeit Landscape in einer kleineren Umgebung – bis zu 10 Vms und 50 Container – umsonst zuverwenden, dies nennt sich Landscape On-premises.

Wie installiere ich Landscape On-premises?

Die entsprechende Software Repository hinzufügen:

sudo add-apt-repository ppa:landscape/18.03

sudo apt-get update

Und daraufhin installieren:

sudo aptitude install landscape-server

sudo aptitude install landscape-server-quickstart

Die Quickstart-Variante installiert App-Server, Datenbank etc. alles auf das gleiche System.

Sollte das nicht gewünscht sein, gibt es ebenfalls eine ausführliche Dokumentation zur manuellen Installation hier.

Falls es zu Fehlern aufgrund von Package-Dependencys kommen sollte, dann kann dieses einfach mit aptitude anstelle von apt-get gelöst werden.

Jetzt können bereits Clients hinzugefügt werden. Eine ausführliche Anleitung dafür ist zwar auch im Webinterface unter <IP_of_APP-Server>/account/standalone/how-to-register zu finden. Dort wird auch automatisch ein Befehl generiert, der die entsprechenden Parameter setzt die zum hinzufügen relevant sind.

 

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

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.