Seite wählen

NETWAYS Blog

Je suis #nginx! | Я/Мы #nginx!

Der Autor mit einem russischen Plakat: „Je suis Nginx“

Stellt Dir vor, Du hast um 2004 herum als Programmierer für ein Unternehmen gearbeitet. Nach und nach hast Du Dir eine Nebentätigkeit aufgebaut, die Du schließlich hauptberuflich als Unternehmer betreibst. Und jetzt kommt aus heiterem Himmel Dein ehemaliger Arbeitgeber und fordert nichts geringeres, als ihm Dein schönes neues Unternehmen zu überlassen.

Ich weiß, das klingt unvorstellbar – zumindest für ein Land wie Deutschland. Aber genau das ist dem Nginx-Gründer Igor Sysoev so passiert.

Ich selbst weiß noch genau wie mein Ausbilder mir den Übernahmevertrag erläutert hat. Beim Punkt, dass ich dem Betrieb automatisch die Rechte am von mir geschriebenen Code übergebe, wurde ich hellhörig. Ich fragte nach, ob dass denn nur für den auf der Arbeit geschriebenen Code gelte und wo das im Vertrag stehe. Darauf antwortete der Ausbilder, dass es nirgendwo explizit stehen müsste, da es sich aus dem Kontext ergebe.

Zahlen, Daten, Fakten

Igor Sysoev war seit Ende 2000 Chef-Admin der russischen Suchmaschine Rambler. Nebenbei entwickelte er 2004 die Webserver-Software Nginx. 2011 gründete er Nginx Inc. als kommerziellen Verwerter der Software.

Rambler ist gegen diese Tätigkeit nie vorgegangen… bis vor Kurzem, als die Strafverfolger vor Nginx‘ Tür standen. Diese nahmen Sysoev vorübergehend fest und werfen ihm als ehemaligen Rambler-Mitarbeiter Urheberrechtsverletzung gegenüber dem Arbeitgeber vor. Und als ob das nicht schon genug wäre: Die Beschuldigungen fußen wohl auf einem Gesetz aus 2006 – sprich, zwei Jahre nach der „Tat“.

Und jetzt?

Gerüchten zufolge hat der russische Geheimdienst FSB es auf den Löwenanteil des russischen Internets abgesehen – dieser läuft auf Nginx. Wenn das stimmt, haben die ihre Rechnung ohne Nginx Inc. gemacht. Diese speichert nämlich Ihren Code im Ausland – und hat jetzt zusätzliche Sicherheits-Maßnahmen ergriffen. Außerdem installieren nicht alle Nutzer Nginx from-Source – viele bedienen sich der Paket-Quellen des Betriebssystems. Deren Maintainer werden jetzt noch ein bisschen genauer hinschauen. Die Docker-Images fußen zwar auf einem GitHub-Repository der Organisation NGINX, Inc., aber alle Mitglieder geben (Stand 16.12.19) einen ausländischen Wohnort an.

Ich selbst habe privat nach Kenntnis der Meldung zwei neue Nginx-Instanzen in Betrieb genommen und kann angesichts meiner Erkenntnisse aus dem letzten Absatz allen Sysadmins Entwarnung geben – und ein Lob zugunsten von Nginx Inc. aussprechen.

Fazit

Dieser Fall zeigt, wie wichtig Open Source und freie Software heutzutage sind. Gerade in Zeiten politischer Unsicherheit ist allen Beteiligten Transparenz wichtiger denn je. Gerade deshalb liegt uns Open Source so am Herzen. Das heißt aber nicht, dass wir ITler uns erdreisten sollten, jetzt die Füße hochzulegen. Im Gegenteil:

Der Autor auf Twitter: „Je suis #Nginx!“

Quellen

Alexander Klimov
Alexander Klimov
Senior Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 12: Profile Part IV

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.
[ruby]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,
}
}
}
}[/ruby]

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.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.
Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.
Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.
Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

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: Introducing CouchDB & Nginx, Offering Dev Job & NETWAYS Training

11 – 15 July introduced CouchDB, new ways of using Nginx, a part-time job opening and our training course schedule for September.
Christoph put a spin on the popular Nginx for use as a load-balanced image converter. As the first step, he showed how Nginx can distribute incoming queries to other web servers. He defined an upstream server and vhost to check for the requested image on all servers and to generate it in a shared directory when it is not found. In the second step, he used vhost’s image filter and security check for image optimisation. SSL and other image formats can be easily integrated, making this a handy tool but most of all scalable, stable and (with a bit of additional effort) also redundant.
Following on Gunnar introduced CouchDB. The Erlang, doc based DBMS has been packaged for most Linux distributions, and thanks to its HTTP based REST interface, can be accessed by most HTTP clients. With a simple UI for admin and database editing, it differs from relational DBMS in that no database schemas in the form of tables need to be defined upon DB setup. Instead, JSON formatted documents can be directly stored in the DB. Documents are accessed via _id, and views can be defined to enable access via other fields. In using an internal binary tree CouchDB can offer performance comparable with indexes in relational DBMS. Information on replication, document validation and more can be found on the Apache project page and in the online book “CouchDB: The Definitive Guide”.
Marius continued to fortify the development team, announcing a position for a student with Python and UML modelling experience. Uni students available to work 80 hours a month, and are interested in working on open source projects with a focus on Python, object modelling in UML based on EMF, document oriented databases, XML and JSON interfaces are welcome to apply at jobs@netways.de or find more info in our jobs area.
Ending the week, Rebecca gave a rundown of upcoming NETWAYS training courses in Icinga (19 – 23 Sep), Nagios (19 – 22 Sep), Puppet (13 – 15 Sep) and SLA Reporting with Jasper (28 – 29 Sep). Thanks to our innumerable consulting projects, we have much practical experience in dealing with highly varied environments and installations to share through our courses. These are designed for intensive learning with small groups, and many opportunities to share ideas and experience between attendees. For more, see our training area.

Nginx als lastverteilter Bild Konverter

Der bekannte Webserver nginx, auf dem ca. 6% aller Webseiten des Internets laufen und der auch noch Reverse Proxy- und pop3/imap Proxyserver sein kann,  hat noch eine andere, oft wenig beachtete Möglichkeit. Mit Hilfe seines Image Filters ist es möglich, ihn als lastverteilten Lieferanten für Bilder zu benutzen, die er on-the-fly in andere Größen skalieren kann.

1. Lastverteilung

Nginx kann von Haus aus Anfragen an andere Webserver verteilen. Hierzu definiert man zuerst einen Upstream Server.

upstream cache_group {
server :8888 weight=100;
server 127.0.0.1:8888 weight=1;
}

Im vhost der die ersten Anfragen annimmt, definiert man dass der Webserver zuerst schaut, ob er das optimierte Bild schon hat, bzw. wenn das Original gefordert wird dieses sofort ausliefert.

server {
       listen   80;
       server_name mein_Server;
       location = /favicon.ico {
               #empty_gif;
               return 204;
       }
       location / {
               root                    /var/www/images;
               rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$1/$2.$3 break;
               rewrite "^\/(.*)\.(jpg|png)" /$1.$2 break;
               error_page              404 = @cache;
       }
       location @cache {
               internal;
               proxy_pass              http://cache_group;
               proxy_store             on;
               proxy_store_access      user:rw  group:rw  all:r;
               proxy_temp_path         /var/www/temp;
               root                    /var/www/images;
       }
}

Falls der Server das Bild nicht findet schaut er, statt die error_page 404 auszugeben, in der cache_group nach. Hier greift die bei Upstream eingerichtete Gewichtung der Server. Nginx wird 100mal so oft auf dem zweiten Image Server suchen wie auf sich selbst. Wenn das Bild auch auf dem anderen Server nicht gefunden wird, wird es dort generiert. Das sorgt natürlich dafür, dass der erste Server entlastet wird. Das Verzeichnis /var/www sollte ein gemeinsames Share sein, damit das generierte Bild auch beiden Servern zur Verfügung steht.
Die im vhost eingestellten rewrite Regeln sind nötig, um unterscheiden zu können, welche Größe des Bildes angefordert wird, bzw. ob einfach das Original benutzt wird. Ruft der Client http://mein_Server/300/testbild.jpg ab bekommt er das Bild aus /var/www/images/300/testbild.jpg. Bei http://mein_Server/testbild.jpg greift die untere rewrite Regel und er kommt auf /var/www/images/testbild.jpg

2. Bildoptimierung

Der vhost für den Cache sieht folgendermaßen aus:

server {
        listen 8888;
        server_name mein_Server;
        location / {
                root                    /var/www/images/;
                error_page              404 = @local_image;
        }
        location @local_image {
                internal;
                proxy_pass              http://local_group_image;
                proxy_store             on;
                proxy_store_access      user:rw  group:rw  all:r;
                proxy_temp_path         /var/www/temp;
                root                    /var/www/images;
        }

Von hier aus springt er, falls das Bild dort nicht finden kann in den Image teil.
Hierfür muss man zunächst noch einen Upstream angeben:

upstream local_group_image {
        server 127.0.0.1:7777;
}

Und anschließend den vhost inklusive Imagefilter und Sicherheitscheck (es sollen nur die Größen erstellt werden, die wir vorher angeben) erstellen. Der Sicherheitscheck funktioniert durch den Regex in der Location Direktive.

server {
        listen 7777;
        server_name mein_Server;
        location ~ "\/(50|100|150|200|250|300|350)\/.*\.(png|jpg)$" {
                root    /var/www/images/;
                rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$2.$3 break;
                image_filter resize $1 $1;
                image_filter_buffer 6M;
                image_filter_jpeg_quality 95;
        }
}

Jetzt sollte alles so funktionieren, wie wir uns das vorstellen. Das Konstrukt ist natürlich noch um weitere Server erweiterbar. Auch zusätzliche Aufgaben, wie z.B. SSL oder andere Bild Formate sind schnell integriert. Wen man so weit ist, wie hier beschrieben, hat man eine skalierbare, stabile und leicht gewichtige Lösung die mit ein wenig Mehrarbeit auch Ausfallsicher ist.

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.