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

Autor: Eric Lippmann

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.

How css-tricks improved my work life

My relationship with CSS is some kind of a love-hate one and I think that is a sentiment a lot of web-devs share with me.
My biggest issue with it is, that it is really counterintuitive and most of the time it feels a bit like solving puzzles to make things align the way you want it to.

and oftentimes it feels a lot like

Properties that mean the same thing being worded inconsistently – I’m looking at you…

vertical-align: middle;
text-align: center;

And there is also some questionable naming with ‘grey’ (#808080) being darker than ‘darkgrey’ (#a9a9a9)…

In general there are too many quirks you need to just know. Unless you work with it every day, you need to google every second line in order to write your stylesheets.
There you can find all sorts of guidelines, help, blogposts with a nice mix of bad-practices and outdated information.

What helped me a lot is the website css-tricks.

(more…)

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer (von eigentlich jedem nur "Feu" genannt) verbrachte ihre Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt sie nun im Rahmen ihrer Ausbildung zum Fachinformatiker die Development Abteilung bei Netways und widmet sich dort dem Web Development. Ihre Freizeit verbringt sie hauptsächlich in den virtuellen Welten von 'Dota 2' und diversen anderen Games, an der Kletterwand in der Boulderhalle oder damit ihren Freunden und Kollegen auf die Nerven zu gehen.

Linux Netzwerkschnittstellen mit check_nwc_health überwachen

Quelle: 9gag.com

Olá!

Heute möchte ich euch zeigen wie ihr lokale Netzwerk Schnittstellen unter Linux ganz einfach mit dem Plugin check_nwc_health überwachen könnt. Für die Demonstration verwende ich eine VirtualBox Maschine mit CentOS Linux 7.5.1804 (Core) und Icinga 2.9.1.

Anmerkung: Zusätzliche Icinga 2 Plugins werden im besten Fall unter /usr/lib64/nagios/plugins/contrib installiert. Hierfür muss die Konstante PluginContribDir (/etc/icinga2/constants.conf) angepasst werden da diese per se auf /usr/lib64/nagios/plugins zeigt.

 

[root@centos7 ~]# mkdir -pv /var/lib64/nagios/plugins/contrib
[root@centos7 ~]# vi /etc/icinga2/constants.conf
- const PluginContribDir = "/usr/lib64/nagios/plugins"
+ const PluginContribDir = "/usr/lib64/nagios/plugins/contrib"

Dann kann es auch schon los gehen! Zunächst müssen fehlende Pakete installieren sowie das Plugin heruntergeladen und kompilieren werden:

[root@centos7 ~]# yum install -y perl-Net-SNMP perl-Data-Dumper perl-Module-Load
[root@centos7 ~]# cd /tmp
[root@centos7 tmp]# wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# tar -xvzf check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# cd check_nwc_health-7.2
[root@centos7 check_nwc_health-7.2]# ./configure \
  --libexecdir=/usr/lib64/nagios/plugins/contrib \ 
  --with-statesfiles-dir=/var/cache/icinga2 \ 
  --with-nagios-user=icinga \
  --with-nagios-group=icinga
[root@centos7 check_nwc_health-7.2]# make
[root@centos7 check_nwc_health-7.2]# make install

Nun sollte man das Plugin im Verzeichnis /usr/lib64/nagios/plugins/contrib vorfinden. Im Endeffekt waren das jetzt auch schon alle Schritte. Nun können wir folgende Befehle einfach ausführen:

[root@centos7 check_nwc_health-7.2]# cd /usr/lib64/nagios/plugins/contrib
[root@centos7 contrib]# sudo -u icinga ./check_nwc_health --hostname localhost --servertype linuxlocal --mode interface-health

Ausgabe

Schnittstelle eth0

OK - eth0 is up/up, interface eth0 usage is in:0.00% (0.06bit/s) out:0.00% (0.00bit/s), interface eth0 errors in:0.00/s out:0.00/s , interface eth0 discards in:0.00/s out:0.00/s , interface eth0 broadcast in:0.00% out:0.00%

Schnittstelle eth1

eth1 is up/up, interface eth1 usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface eth1 errors in:0.00/s out:0.00/s , interface eth1 discards in:0.00/s out:0.00/s , interface eth1 broadcast in:0.00% out:0.00%

Schnittstelle lo

lo is up/up, interface lo usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface lo errors in:0.00/s out:0.00/s , interface lo discards in:0.00/s out:0.00/s , interface lo broadcast in:0.00% out:0.00%

Performancedaten

'eth0_usage_in'=0%;80;90;0;100 'eth0_usage_out'=0%;80;90;0;100 'eth0_traffic_in'=0.06;0;0;0;0 'eth0_traffic_out'=0.00;0;0;0;0 'eth0_errors_in'=0;1;10;; 'eth0_errors_out'=0;1;10;; 'eth0_discards_in'=0;1;10;; 'eth0_discards_out'=0;1;10;; 'eth0_broadcast_in'=0%;10;20;0;100 'eth0_broadcast_out'=0%;10;20;0;100 'eth1_usage_in'=0%;80;90;0;100 'eth1_usage_out'=0%;80;90;0;100 'eth1_traffic_in'=0.00;0;0;0;0 'eth1_traffic_out'=0.00;0;0;0;0 'eth1_errors_in'=0;1;10;; 'eth1_errors_out'=0;1;10;; 'eth1_discards_in'=0;1;10;; 'eth1_discards_out'=0;1;10;; 'eth1_broadcast_in'=0%;10;20;0;100 'eth1_broadcast_out'=0%;10;20;0;100 'lo_usage_in'=0%;80;90;0;100 'lo_usage_out'=0%;80;90;0;100 'lo_traffic_in'=0.00;0;0;0;0 'lo_traffic_out'=0.00;0;0;0;0 'lo_errors_in'=0;1;10;; 'lo_errors_out'=0;1;10;; 'lo_discards_in'=0;1;10;; 'lo_discards_out'=0;1;10;; 'lo_broadcast_in'=0%;10;20;0;100 'lo_broadcast_out'=0%;10;20;0;100

Icinga Web 2

check_nwc_health hält noch viele andere Möglichkeiten bereit die vom Umfang her, aber den Rahmen dieses Blogposts sprengen würden. Daher würde ich euch gerne auf die Dokumentation verweisen. In diesen Sinne verabschiede ich mich auch schon wieder und wünsche euch viel Spaß beim implementieren und basteln 🙂

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

The Icinga Config Compiler: An Overview

The Icinga configuration format was designed to be easy to use for novice users while at the same time providing more advanced features to expert users. At first glance it might look like a simple key-value configuration format:

object Host "example.icinga.com" {
	import "generic-host"

	address = "203.0.113.17"
	address6 = "2001:db8::17"
}

However, it features quite a bit of functionality that elevates it to the level of scripting languages: variables, functions, control flow (if, for, while) and a whole lot more.

Icinga’s scripting language is used in several places:

  • configuration files
  • API filter expressions
  • auto-generated files used for keeping track of modified attributes

In this post I’d like to show how some of the config machinery works internally.

The vast majority of the config compiler is contained in the lib/config directory. It weighs in at about 4.5% of the entire code base (3059 out of 68851 lines of code as of July 2018). The compiler is made up of three major parts:

Lexer

The lexer (lib/config/config_lexer.ll, based on flex) takes the configuration source code in text form and breaks it up into tokens. In doing so the lexer recognizes all the basic building blocks that make up the language:

  • keywords (e.g. “object”, “for”, “break”) and operators (e.g. >, ==, in)
  • identifiers
  • literals (numbers, strings, booleans)
  • comments

However, it has no understanding of how these tokens fit together syntactically. For that it forwards them to the parser. All in all the lexer is actually quite boring.

Parser/AST

The parser (lib/config/config_parser.yy, based on GNU Bison) takes the tokens from the lexer and tries to figure out whether they represent a valid program. In order to do so it has production rules which define the language’s syntax. As an example here’s one of those rules for “for” loops:

| T_FOR '(' identifier T_FOLLOWS identifier T_IN rterm ')'
{
        BeginFlowControlBlock(context, FlowControlContinue | FlowControlBreak, true);
}
rterm_scope_require_side_effect
{
        EndFlowControlBlock(context);

        $$ = new ForExpression(*$3, *$5, std::unique_ptr($7), std::unique_ptr($10), @$);
        delete $3;
        delete $5;
}

Here’s a list of some of the terms used in the production rule example:

Symbol Description
T_FOR Literal text “for”.
identifier A valid identifier
T_FOLLOWS Literal text “=>”.
T_IN Literal text “in”.
BeginFlowControlBlock, EndFlowControlBlock These functions enable the use of certain flow control statements which would otherwise not be allowed in code blocks. In this case the “continue” and “break” keywords can be used in the loop’s body.
rterm_scope_require_side_effect A code block for which Icinga can’t prove that the last statement doesn’t modify the program state.

An example for a side-effect-free code block would be { 3 } because Icinga can prove that executing its last statement has no effect.

After matching the lexer tokens against its production rules the parser continues by constructing an abstract syntax tree (AST). The AST is an executable representation of the script’s code. Each node in the tree corresponds to an operation which Icinga can perform (e.g. “multiply two numbers”, “create an object”, “retrieve a variable’s value”). Here’s an example of an AST for the expression “2 + 3 * 5”:

Note how the parser supports operator precedence by placing the AddExpression AST node on top of the MultiplyExpression node.

Icinga’s AST supports a total of 52 different AST node types. Here are some of the more interesting ones:

Node Type Description
ArrayExpression An array definition, e.g. [ varName, "3", true ]. Its interior values are also AST nodes.
BreakpointExpression Spawns the script debugger console if Icinga is started with the -X command-line option.
ImportExpression Corresponds to the import keyword which can be used to import another object or template.
LogicalOrExpression Implements the || operator. This is one of the AST node types which don’t necessarily evaluate all of its interior AST nodes, e.g. for true || func() the function call never happens.
SetExpression This is essentially the = operator in its various forms, e.g. host_name = "localhost"

On their own the AST nodes just describe the semantical structure of the script. They don’t actually do anything in terms of performing any real actions.

VM

Icinga contains a virtual machine (in the language sense) for executing AST expressions (mostly lib/config/expression.cpp and lib/config/vmops.hpp). Given a reference to an AST node – such as root node from the example in the previous section – it attempts to evaluate that node. What that means exactly depends on the kind of AST node:

The LiteralExpression class represents bare values (e.g. strings, numbers and boolean literals). Evaluating a LiteralExpression AST node merely yields the value that is stored inside of that node, i.e. no calculation of any kind takes place. On the other hand, the AddExpression and MultiplyExpression AST nodes each have references to two other AST nodes. These are the operands which are used when asking an AddExpression or MultiplyExpression AST node for “their” value.

Some AST nodes require additional context in order to run. For example a script function needs a way to access its arguments. The VM provides these – and a way to store local variables for the duration of the script’s execution – through an instance of the StackFrame (lib/base/scriptframe.hpp) class.

Future Considerations

All in all the Icinga scripting language is actually fairly simple – at least when compared to other more sophisticated scripting engines like V8. In particular Icinga does not implement any kind of optimization.

A first step would be to get rid of the AST and implement a bytecode interpreter. This would most likely result in a significant performance boost – because it allows us to use the CPU cache much more effectively than with thousands, if not hundreds of thousands AST nodes scattered around the address space. It would also decrease memory usage both directly and indirectly by avoiding memory fragmentation.

However, for now the config compiler seems to be doing its job just fine and is probably one of the most solid parts of the Icinga codebase.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

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

Autor: Nicole Lang

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 Bücher und zockt auch mal gerne.

Continuous Integration with Golang and GitLab

Today you not only develop code and collaborate with other developers in your Git branches and forks. In addition continuous integration helps with “instant” compile and runtime tests. Which Git commit caused a failure, are there any performance changes with the recent code history?

Today I want to dive into our latest insights into Golang and building our code inside GitLab on each push and merge request. Golang extensively supports unit tests and also their analysis with coverage tests. This ensures that code isolated in test interfaces runs rock-solid and you can focus on the more important tasks and features.

In order to abstract the Go build and install calls, we add a Makefile for convenience. This also allows developers to manually use it, if they want.

$ vim Makefile

.PHONY: all test coverage

all: get build install

get:
        go get ./...

build:
        go build ./...

install:
        go install ./...

test:
        go test ./... -v -coverprofile .coverage.txt
        go tool cover -func .coverage.txt

coverage: test
        go tool cover -html=.coverage.txt

The “coverage” target runs the tests and stores the coverage results in “.coverage.txt”. This is then converted into HTML and can be opened with a browser for example.

Inside GitLab we need a CI runner configured for our project and job pipeline. This is already available in the NWS app. If you want to learn more about GitLab CI/CD, containers, jobs and pipelines, I’ll invite you to join me for the official GitLab training sessions 🙂

The CI configuration file is stored in “.gitlab-ci.yml” inside the Git repository and uses the Golang image for Debian Stretch in this example.

$ vim .gitlab-ci.yml

image: golang:1.10-stretch

stages:
  - build

before_script:
  - apt-get update && apt-get install -y make curl
  - curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
  - mkdir -p /go/src/git.icinga.com/icingadb
  - ln -s /builds/icingadb/icingadb /go/src/git.icinga.com/icingadb/icingadb
  - cd /go/src/git.icinga.com/icingadb/icingadb
  - dep init && dep ensure

build:
  stage: build
  script:
    - make test

The “before_script” tasks can be moved into your own Docker image which can be made available in the GitLab container registry too. At some later point when dependencies are fixed, we’ll remove the “dep init” step and just use the locked versions from inside our Git repository.

The test coverage should also be highlighted in the job output. This can be extracted with a regular expression using the shell output from the tests. Nagivate into “Settings > CI/CD > General pipeline settings > Test coverage parsing” and add the following regex:

^total:\t+\(statements\)\t+(\d+\.\d+)%

Each pushed branch and merge request will then automatically be built and also shows the test coverage. There’s room for improvement here, the next months will ensure to add more unit and runtime tests ?

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg mit #atasteofaustria 🙂