Domain Name System (DNS)

TL;DR

Das „Domain Name System“ (kurz DNS) ist eine Art Telefonbuch für das Internet.

Prinzipiell basiert die Kommunikation zwischen 2 Computer auf IP-Adressen. Da diese aber (besonders IPv6) Adressen nicht leicht für uns Menschen merkbar sind können Domain-Namen mit diesen IP-Adressen verbunden werden.

Daher „übersetzt“ ein DNS-Server eine Anfrage wie z.b. „google.com“ in die IP-Adresse 172.217.18.67 (v4) bzw. 2a00:1450:400d:802::200e (v6)

Detaillierte Informationen

Die 8 Schritte eines DNS Lookups:

  1. Ein Benutzer gibt die Adresse „example.com“ in seinem Web Browser ein. Dadurch wird ein Query zum nächsten verfügbaren „DNS recursive resolver“ ausgelöst.
  2. Dieser „resolver“ fragt beim nächstgelegenen „DNS Root Server“ (.) an.
  3. Der „Root-Server“ gibt dann die Adresse des nächstgelegenen Top Level Domain (TLD) DNS Servers (wie z.B. „.at“ oder „.net“) zurück. Durch unsere Anfrage an „example.com“ erhalten wir die Adresse des nächstgelegenen „.com“ TLD DNS Servers.
  4. Der „resolver“ führt dann eine Anfrage an den .com TLD DNS Server durch.
  5. Der TLD DNS Server antwortet darauf mit der IP Adresse der angefragten Domain „example.com“.
  6. Zuletzt fragt der „resolver“ eine Anfrage zu dem vorhin erhaltenen Domain Nameserver.
  7. Die IP Adresse für „example.com“ wird nun vom Domain Nameserver zum „resolver“ zurück geschickt.
  8. Der „resolver“ schickt nun die aufgelöste IP Adresse zum Web Browser zurück.
Source: https://www.cloudflare.com/learning/dns/what-is-dns/

DNS-Records (Zone-Files)

DNS-Records sind Anweisungen für den DNS-Server wie dieser sich bei DNS-Requests für eine gewisse Domain verhalten soll.

Diese sind im Prinzip reine Text-Dateien geschrieben in einer speziellen DNS-Syntax.

Ebenso hat jeder DNS-Record eine „Time-to-live“ (TTL), welche anzeigt wie oft der DNS-Server die eingetragenen Daten neu ausliest.

Wichtigste DNS-Record-Typen

  • A bzw. AAAA
    • Beinhaltet die IP-Adresse (A = v4, AAAA = v6)
  • CNAME
    • „Canonical Name“ verweist eine Domain auf eine andere Domain (nicht IP-Adresse!)
  • MX
    • „Mail Exchange“ verweist auf den Mail-Server
  • TXT
    • Bietet dem Domain-Admin eine Möglichkeit Text-Einträge hinzuzufügen
    • Wird aber öfters auch für SPF Einträge oder Domain-Verifizierung genutzt
  • SOA
    • „Start of authority“ zeigt wichtige Admin-Informationen über den Domain-Inhaber an (z.b. eine E-Mail Adresse)
  • SRV
    • „Service“ verweist auf auf einen spezifischen Host und Port für einen gewissen Service wie z.b. VOIP
  • PTR
    • „Pointer“ ist genau das Gegenteil von einem „A“-Record und wird für den „Reverse-Lookup“ verwendet um die zugewiesene Domain aus einer IP-Adresse zu erhalten.

Es gibt noch weitere DNS-Record-Typen, die aber nur sehr selten gebraucht werden. Siehe HIER.

Sources:
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/dns/dns-records/

Was ist PHP?

PHP (Abkürzung für Hypertext Preprocessor) ist eine Open-Source Skriptsprache, welche hauptsächlich in der Web-Entwicklung zur Generierung von HTML-Code verwendet wird.

Beispiel:

<?php
   $variable = "Testvariable";
   echo "Folgende Variable wurde definiert: " . $variable;
?>

Generiert folgendes Ergebnis:

Folgende Variable wurde definiert: Testvariable

In diesem Beispiel wird eine Variable definiert und über den Befehl „echo“ an den Text „Folgende Variable wurde definiert:“ hinten hinzugefügt und ausgegeben.

Da PHP eine Skriptsprache ist wird bei jedem Aufruf der PHP Datei der Inhalt neu interpretiert. Im Gegensatz dazu wird am Beispiel von Java oder C erst der Source-Code durch einen „Compiler“ in Maschinen-Code umgewandelt bevor er ausgeführt werden kann.

Standardmäßig bietet PHP schon einige unterschiedlichste Funktionalitäten zur Verfügung – wie z.B.:

  • Datenbank-Zugriff (MySQL, PostgreSQL, SQLite etc.)
  • Dateisystem-Zugriff (Ordner und Dateien erstellen/bearbeiten/löschen etc.)
  • String-Abänderungen (Texte erstellen/bearbeiten/formatieren etc.)
  • XML-Verarbeitung (Datenstrukturen erstellen/bearbeiten/durchsuchen etc.)
  • u.v.m.

Dies sind nur ein paar Beispiele an Funktionalitäten die in der „Standard-PHP“ Installation integriert sind. Jedoch gibt es „PHP-Module“ um die Funktionalität von PHP noch zu erweitern.

Bekannte bzw. häufig verwendete Beispiel hierfür wären:

  • XDebug (Erweiterte Debug Funktionalität um Probleme im PHP-Code schneller zu finden)
  • OPCache (Speichert vorkompilierte Bytecodes aus PHP-Code im Arbeitsspeicher anstatt diesen bei jedem Aufruf neu zu generieren => Performance-Boost)
  • MBString (Ermöglicht das richtige Handhaben von „MultiByte Strings“ in PHP – z.B. von Emoji Icons)
  • GD (Bildbearbeitung – Bilder drehen/umwandeln etc.)
  • SOAP (Eine spezielle Variante von XML Datenstrukturen)
  • u.v.m.

Wie PHP implementiert bzw. aufgerufen wird kann in dem Beitrag „CLI vs WebServer Integration“ nachgelesen werden.

Da sich mit jeder PHP Version aktuelle Funktionen ändern, entfernt werden und neue hinzugefügt werden wurden die wichtigsten Änderungen von PHP 7.1, 7.2 und 7.3 HIER zusammengefasst.

Sources:
PHP: Was ist PHP – https://www.php.net/manual/de/intro-whatis.php

PHP-Versionen

Wie überall in der Software-Entwicklung gibt es auch hier Versionen, die mit der Zeit die „alten“ Funktionalitäten verbessern bzw. neue Funktionalität hinzufügen. Die folgende Liste zeigt einen kurzen Überblick über die wichtigsten Änderungen von PHP 7.1 bis 7.3.

PHP 5.6 und 7.0 wurden hier nicht mehr eingebunden, da diese laut php.net nicht mehr mit Security-Patches versorgt werden und damit auch nicht mehr aktiv verwendet werden sollten. (Stand April 2019)

PHP 7.4

Spread-Operator für Arrays

Bei Funktionsaufrufen war der Spread-Operator schon bekannt.

function my_function(...$args) { var_dump($args); }
my_function('test', true, 123);

// Resultat
array(3) {
  [0]=>
  string(4) "test"
  [1]=>
  bool(true)
  [2]=>
  int(123)
}

Dies ist nun auch für Array-Operationen möglich.

$bool_arr = [true, false];
$total_arr = ['text1', 123, ...$bool_arr , 456];
var_dump($total_arr );

// Resultat
array(5) {
  [0]=>
  string(5) "text1"
  [1]=>
  int(123)
  [2]=>
  bool(true)
  [3]=>
  bool(false)
  [4]=>
  int(456)
}

Diese Art von Array Zusammenführung soll ebenso performanter sein als die übliche array_merge() Funktion.

Arrow Funktionen

Ein typischer Fall für Arrow Funktionen wäre z.b. folgendes Beispiel

function cube($n){
	return ($n * $n * $n);
}
$a = [1, 2, 3, 4, 5];
$b = array_map('cube', $a);

Wird zu

$a = [1, 2, 3, 4, 5];
$b = array_map(fn($n) => $n * $n * $n, $a);

Null Coalescing Assignment Operator

Mit PHP 7.0 ist es ja schon möglich einen Fallback Wert zu setzen wenn eine gewissen Variable nicht gesetzt ist.

$this->request->data['comments']['user_id'] = $this->request->data['comments']['user_id'] ?? 'value';

Diese Schreibweise kann nun wie folgt vereinfacht werden

$this->request->data['comments']['user_id'] ??= 'value';

Typisierte Klassen-Argumente

Es ist nun möglich folgende Klassen-Definition

class User {
    /** @var int $id */
    private $id;
    /** @var string $name */
    private $name;
 
    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
}

wie folgt zu vereinfachen

class User {
    public int $id;
    public string $name;
}

Folgende Typen sind hier erlaubt:

  • bool
  • int
  • float
  • string
  • array
  • object
  • iterable
  • self
  • parent
  • Jegliche/s Klasse oder Interface
  • Nullable Typen (?type)

Jedoch dürfen keine void als auch callable Typen definiert werden!

Preloading

Ohne in komplizierte Details zu gehen bewirkt das OPCache preloading, dass Libraries in den OPCache vorgeladen und damit immer zur Verfügung stehen statt sie bei jedem PHP-Prozess neu zu laden. Dies bewirkt einen deutlichen Performance-Gewinn.

Diese Einstellung muss in der php.ini gesetzt werden.

PHP 7.3

Nachgestelltes Komma in Funktions-Parametern erlaubt

Ab PHP 7.3. ist es nun erlaubt beim letzten Parameter eines Funktionsaufrufs ein Komma hinten anzustellen.

my_function(
    $param1,
    $param2,
);

JSON_THROW_ON_ERROR

Aktuell gibt json_decode() null bei einem Fehler zurück.
null kann aber auch ein gültiges Ergebnis sein was zu Verwirrungen führen kann.

Nun gibt es folgende Funktionen:

  • json_last_error()
    • Gibt (sofern vorhanden) den letzten Fehler zurück, der beim letzten Kodieren/Dekodieren von JSON aufgetreten ist.
  • json_last_error_msg()
    • Gibt bei Erfolg die Fehlermeldung zurück, „No error“, wenn kein Fehler aufgetreten ist. Im Fehlerfall wird FALSE zurückgegeben.

Ein anonymer User hat bei der php.net Definition der json_last_error_msg() Funktion eine nette Helper-Funktion geschrieben, welche die Fehler-Ausgabe bei json_decode() vereinfacht:

<?php
    if (!function_exists('json_last_error_msg')) {
        function json_last_error_msg() {
            static $ERRORS = array(
                JSON_ERROR_NONE => 'No error',
                JSON_ERROR_DEPTH => 'Maximum stack depth exceeded',
                JSON_ERROR_STATE_MISMATCH => 'State mismatch (invalid or malformed JSON)',
                JSON_ERROR_CTRL_CHAR => 'Control character error, possibly incorrectly encoded',
                JSON_ERROR_SYNTAX => 'Syntax error',
                JSON_ERROR_UTF8 => 'Malformed UTF-8 characters, possibly incorrectly encoded'
            );

            $error = json_last_error();
            return isset($ERRORS[$error]) ? $ERRORS[$error] : 'Unknown error';
        }
    }
?>

Alternativ kann dies auch über einen try-catch Block gelöst werden:

try {
    json_decode("{", false, 512, JSON_THROW_ON_ERROR);
}
catch (\JsonException $exception) {
    echo $exception->getMessage(); // echoes "Syntax error"
}

is_countable Funktion

Aktuell ist es für z.b. foreach-Schleifen üblich die Variablen wie folgt zu überprüfen:

$array = [1,2,3,4,5,6,7,8];

if(is_array($array) && sizeof($array) > 0){
  foreach($array as $value){
    
  }
}

Dies kann nun wie folgt verkürzt werden:

$array = [1,2,3,4,5,6,7,8];

if(is_countable($array)){
  foreach($array as $value){
    
  }
}

array_key_first(), array_key_last()

Bis jetzt war es nicht „einfach“ möglich den ersten bzw. letzten „key“ eines Arrays zu erhalten. Mit den Funktionenarray_key_first()und array_key_last() ist dies nun einfach möglich.

PHP 7.2

Native Untersützung für das Bild-Format (BMP)

Bis jetzt musste man bei der Bild-Bearbeitung von BMP-Bildern über PHP externe Bibliotheken verwenden. Jedoch bietet seit PHP 7.2 die GD-Bibliothek die Unterstützung für dieses Bildformat mit an.

Typ „object“ bei Parameter- und Rückgabewerten einstellbar

Bis jetzt war es nicht bei Funktionen als Paramter- oder Rückgabewerte eine Variable vom Typ „object“ anzugeben. Seit PHP 7.2 ist dies nun aber möglich.

function test (object $a): object {

}

exif_read_data() erkennt mehr Daten aus Bildern

EXIF (Exchangeable Image File Format) ist ein Standard für das Abspeichern von Metadaten bei Bild-Dateien.

Bis jetzt waren diese automatisch ausgelesenen Daten aus PHP sehr beschränkt. Jedoch wurden mit PHP 7.2 diverse EXIF-Formate von bekannten Kamera-Herstellern hinzugefügt. Siehe HIER

Verschlüsselte ZIP-Archive nun möglich

Ab PHP 7.2 ist es nun möglich ZIP-Archive mit Passwörtern zu erstellen.

PHP 7.1

„Nullable types“

function test1(?array $a) {
 
}
 
function test2($a): ?array {
 
}

Die erste Funktion (test1) besagt, dass ein Parameter vom Typ „Array“ der Funktion übergeben werden kann, dieser jedoch auch „null“ sein kann (? vor dem array)

Die zweite Funktion (test2) besagt, dass der Rückgabewert der Funktion vom Typ „Array“ sein kann, jedoch aber auch „null“ erlaubt ist.

Ohne diese vorangestellten ? würde bei einem Aufruf der Funktion test1 mit dem Paramter „null“ bzw. bei der Funktion test2 mit dem Rückgabe-Wert „null“ ein „Fatal Error“ produziert werden.

Array und list haben gleiche Funktionalität

Alter Code:

$array = array(0 => 'a', 1 => 'b');
 
list($a, $b) = $array;
 
// $a ist = 'a'
// $b ist = 'b'

Neuer Code:

$array = array(0 => 'a', 1 => 'b', 2 => 'c');
 
[$a, $b] = $array;
 
// $a ist = 'a'
// $b ist = 'b'
 

list(1 => $b, 2 => $c) = $array;
// ist das gleiche wie
[1 => $b, 2 => $c] = $array;

Sichtbarkeiten von Konstanten in Klassen

Wie es schon bei Klassen-Variablen und Funktionen bekannt ist können nun „Sichtbarkeiten“ (bekannt aus der Objektorientierten Programmierung) auch auf Konstanten angewandt werden.

  • public Zugriff auf Variablen ist von überall möglich, d.h. auch von anderen Klassen bzw. Objekten
  • protected Zugriff auf Variablen ist nur in der eigenen Klasse UND von allen Klassen, die von der eigenen Klasse abgeleitet (=extended) wurden, möglich.
  • private Zugriff auf Variablen ist nur in der eigenen Klasse vorhanden.
class test {
    const PUBLIC1 = 'TEST';
 
    public const PUBLIC2 = 'TEST';
    protected const PROTECTED = 'TEST';
    private const PRIVATE = 'TEST';
}

try-catch mit mehreren Exception Angaben möglich

Es ist nun möglich in einem try-catch Block mehrere Exception-Typen mit einem | anzugeben.

try {
     throw new Exception('Fehler');
} catch (Exception | AndererExceptionTyp $catchedException) {
     var_dump($catchedException);
}

mcrypt Erweiterung veraltet => OpenSSL verwenden

Die Funktionen der „mcrypt“ Erweiterung (Funktionsnamen die mit „mcrypt_“ starten) werden nun als „deprecated“ markiert bzw. bei Verwendung in der error.log als „deprecated“ angezeigt.

Ersetzt wird die mcrypt Funktionlität mit den Funktionen aus der OpenSSL Erweiterung.

Sources

mod_php vs (Fast)CGI vs FPM

Es gibt mehrere Arten wie PHP Dateien vom Web Server verarbeitet werden können. Die folgenden Bereiche beschreiben die bekanntesten Implementierungen:

mod_php

„mod_php“ ist ein Module für den Web-Server „apache“.

Mit diesem Modul ist PHP sozusagen „integriertim Web-Server. Das bewirkt, dass es keinen extra PHP-Prozess zur Abwicklung des PHP-Codes gibt sondern alles vom Apache-Prozess verarbeitet wird.

Der große Vorteil bei der Verwendung von „mod_php“ ist Performance. Im Vergleich zu CGI bewirkt der Umstieg auf „mod_php“ einen durchschnittlichen Performance-Gewinn von 300-500%.

Grund dafür ist die Möglichkeit des Cachings von diversen PHP-Modulen bzw. Konfigurationen die sonst (bei CGI und FastCGI) bei jedem Aufruf einer Seite immer neu ausgelesen und abgearbeitet werden müssen.

Wie erkenne ich, ob mod_php verwendet wird?

Nachdem mod_php ein Web-Server Modul ist muss es in der Webserver-Config wie folgt geladen werden (hier am Beispiel von Apache2)

LoadModule php7_module modules/mod_php.so

Auf meinem Ubuntu Server war z.b. folgender Eintrag in der /etc/apache2/mods-available/php7.4.load vorhanden

LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

Dies führt dann typischerweise dazu, dass in der phpinfo() Ausgabe wie folgt darauf hingewiesen wird:

Server APIApache 2.0 Handler
Loaded Modulescore mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_deflate mod_dir mod_env mod_filter mod_mime prefork mod_negotiation mod_php7 mod_reqtimeout mod_setenvif mod_status

CGI

Die „Common Gateway Interface“ (kurz CGI) Implementation bedeutet, dass der Web-Server pro Anfrage eine neue PHP-Interpreter-Prozess startet. Dadurch müssen bei jeder Anfrage alle PHP-Module, die php.ini und die diversen anderen Konfigurationen neu geladen und durchgeführt werden, was sehr ineffizient ist.

Hauptvorteil von der CGI Implementation ist die komplette Isolierung zwischen ausgeführten Web-Server Code und PHP-Code.

FastCGI

FastCGI ist eine PHP-Implementation, die die Security-Vorteile von CGI implementiert aber trotzdem effizient in der Abarbeitung ist wie mod_php.

Hier wird nicht pro Request eine neue PHP-Interpreter-Instanz gestartet (was das primäre Problem war bei CGI), sondern es gibt schon „fertige“ PHP-Interpreter-Instanzen, denen nur die angefragte PHP-Datei übergeben wird.

Wie erkenne ich, ob FastCGI verwendet wird?

Serverseitig gibt es hier mehrere Möglichkeiten wie dies umgesetzt werden kann. Ein Beispiel wäre ein lokal verfügbares, ausführbares PHP Binary:

ScriptAlias /myPHP /home/devguide/php-install-directory
AddHandler cgi-php .php
Action cgi-php /myPHP/php-cgi

Hier ist also /home/devguide/php-install-directory/php-cgi ein spezielles PHP Binary für CGI Zwecke ist (sollte beim installieren von PHP automatisch mitkommen sollte oder als eigenes Package installiert werden kann).

In derphpinfo() Ausgabe sieht das ganze wie folgt aus:

Server APICGI/FastCGI

FPM

Der „PHP-FastCGI Process Manager“ (kurz PHP-FPM) ist eine alternative zur FastCGI Implementation von PHP in einem Webserver.

Hier besteht immer parallel zum Web-Server Prozess (zu mindest) ein PHP-FPM Prozess, an den PHP-Anfragen vom Web-Server weitergeleitet werden.

Für weitere Details zu FPM siehe HIER

Source: https://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/

Wie erkenne ich, ob FPM verwendet wird?

FPM verwendet einen eigenen Service mit dem die FPM-Pools verwaltet werden. D.h. wenn man die Services des Servers sehen kann (z.b. über top oder htop) wird man recht schnell herausfinden, ob PHP-FPM verfügbar ist bzw. verwendet wird.

In derphpinfo() Ausgabe sieht das ganze wie folgt aus:

Server APIFPM/FastCGI
php-fpmactive

PHP-FPM

Der „PHP-FastCGI Process Manager“ (kurz PHP-FPM) ist eine alternative zur FastCGI Implementation von PHP in einem Webserver.

Hier besteht immer parallel zum Web-Server Prozess (zu mindest) ein PHP-FPM Prozess, an den PHP-Anfragen vom Web-Server weitergeleitet werden.

FPM-Prozesse unterteilen sich in unterschiedliche „Pools“. In diesen Pools werden typischerweise mehrere Prozesse für eine gewissen Seite gestartet werden damit diese bei Anfragen über den Web-Server gleich zur Verfügung stehen.

Die Anzahl dieser Prozesse und diverse anderen Einstellungen für den Pool können in der FPM Konfiguration (wie weiter unten zu sehen) eingestellt werden.

Installation (Debian basierte Distros)

sudo apt install php7.2 php7.2-common php7.2-cli php7.2-fpm

FPM Konfiguration

Diese befinden sich unter „/etc/php/7.2/fpm/pool.d/“.
Hier wird pro Socket eine Datei erstellt.

[<pool-name>]
user = <username>
group = <groupname>
listen = /run/php/<socket-name>.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
chroot = <docroot-path>
php_admin_value[openssl.capath] = /etc/ssl/certs

Beim eingetragenen Pfad bei „listen“ wird nach neustarten des PHP-FPM-Prozesses ein Socket erstellt.

Über diesen kann dann der jeweilige Web-Server die Anfragen weiterleiten (siehe unten)

Web-Server Konfiguration (NGINX)

Der Web-Server muss dafür so konfiguriert werden, dass PHP-Files an den jeweiligen PHP-Prozess (typischerweise über einen Socket) weitergeleitet werden.

Am Beispiel vom NGINX-Web-Server: /etc/nginx/sites-available/<domain-name>.conf

server {
    listen 443 ssl http2; # managed by Certbot
    listen [::]:443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/<domain-name>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<domain-name>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    root <path-to-docroot>;
    server_name <domain-name>;

    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }	

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/run/php/<fpm-socket-name>.sock;
    }
	
    error_log <path-to-logs>/error.log warn;
    access_log <path-to-logs>/access.log apm;
}

server {
    if ($host = <domain-name>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
	
    listen 80;
    listen [::]:80;

    server_name <domain-name>;
    return 404; # managed by Certbot
}

Die folgende Zeile ist für die „Weiterleitung“ an den FPM-Prozess verantwortlich

fastcgi_pass unix:/run/php/<fpm-socket-name>.sock;

Der PHP-FPM Prozess muss bei jeder neu erstellten oder geändert Konfiguration neu gestartet werden um den Socket zu erstellen, zu dem sich dann der Webserver verbindet. In dem gleichen Zug kann der Webserver auch gleich neugestartet werden.

sudo systemctl restart php7.2-fpm.service nginx

CLI vs WebServer Integration

Wie in der PHP-FPM Beschreibung schon beschrieben können unterschiedliche Konfigurationen für unterschiedliche vHosts erstellt werden.

Das hat natürlich den Vorteil, dass unterschiedliche vHosts mit unterschiedlichen PHP Versionen ausgeführt werden können, was bei Legacy-Software öfters der Fall ist, da diese die neuesten PHP Standards nicht implementiert haben und zu mindest Warnings auftauchen.

Diese Konfiguration ändert aber nichts an der systemweiten installierten PHP Version.

Das bedeutet, dass die PHP Version aus einer PHP-Info Datei nicht unbedingt die gleiche sein muss wie die PHP Version, die aus dem folgenden Befehl über das Terminal erscheint.

php -v
PHP 7.2.19-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: May 31 2019 11:17:15) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.19-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.1, Copyright (c) 2002-2019, by Derick Rethans

Wie ändert man die Standard PHP Version in der CLI?

HINWEIS: Dies ist nur möglich, wenn root bzw. sudo Rechte am Server vorhanden sind!

Über folgenden Befehl findet man heraus, was der Pfad zu einem Befehl ist

which php

Dieser gibt bei meinem Server aktuell folgendes aus:

/usr/bin/php

Wenn man nun diese „Datei“ genauer betrachtet sieht man folgendes:

ls -al /usr/bin/php        
lrwxrwxrwx 1 root root 21 Jan  3  2018 /usr/bin/php -> /etc/alternatives/php

Das bedeutet, dass /usr/bin/php eigentlich nur auf /etc/alternatives/php zeigt, also eine Art Verknüpfung. Hier sieht man aber schon am Pfad, dass es etwas mit den „alternatives“ zu tun hat.

Wenn diese Datei genauer betrachtet wird sieht man folgendes:

ls -al /etc/alternatives/php        
lrwxrwxrwx 1 root root 15 May 31  2018 /etc/alternatives/php -> /usr/bin/php7.2

Dieser Link zeigt nun zum „wirklichen“ Binary, welches dann PHP in der Version ausführt.

ls -al /usr/bin/php7.2      
-rwxr-xr-x 1 root root 4899864 May 31 13:17 /usr/bin/php7.2

D.h. der Befehl „php“ liegt in „/usr/bin/php“, welcher dann weiter zu „/etc/alternatives/php“ und final zu „/usr/bin/php7.2“ linkt.

Um diese „Verlinkung“ nun anzupassen (um eine andere PHP Version in der CLI zu erhalten) kann folgender Befehl eingegeben werden:

sudo update-alternatives --set php /usr/bin/php7.3

Damit haben wir die Standard PHP Version in der CLI von 7.2 auf 7.3 geändert.

php -v
PHP 7.3.6-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: May 31 2019 11:06:48) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.6, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.6-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.1, Copyright (c) 2002-2019, by Derick Rethans

Was ist ein Webserver?

Ein Webserver liefert Daten über das HTTP-Protokoll an Web-Browser. Diese Daten sind typischerweise HTML, CSS, JavaScript und Bild-Dateien.

Je nach gewähltem Webserver können gewisse Scriptsprachen bzw. dynamische Daten mit interpretiert und ausgegeben werden wie z.B.

  • PHP
  • JS
  • ASP
  • JSP

Hier hängt es aber von dem gewählten Webserver ab wie/ob/welche Scriptsprache standardmäßig interpretiert wird.

Typische Webserver Implementierung

  • Apache
  • NGINX
  • Cloudflare
  • Microsoft ISS
  • Node.js
  • Tomcat (Java)
  • lighthttpd

Aktuelle Aufteilung (11. Mai 2019) der meist verwendeten Webserver Implementierungen

Source: https://de.wikipedia.org/wiki/Webserver

Apache

Der Apache HTTP Server ist ein freier Webserver der im Jahr 1995 veröffentlicht wurde und ist aktuell der am meisten verwendete Webserver (Stand Mai 2019 – siehe „Was ist ein Webserver„).

Das installieren vom Apache Webserver ist bei jedem Betriebssystem etwas anders. An den folgenden Beispielen wird immer von Debian/Ubuntu ausgegangen.

sudo apt-get install apache2

Danach sollte folgender Befehl die aktuell installierte Apache2 Version ausgeben:

apache2 -v

Wie sonst bei allen anderen Software-Packages üblich befinden sich die Config-Dateien in /etc/apache2.

In diesem befinden sich folgende Dateien und Ordner

  • apache2.conf
    • Enthält die allgemeinen Apache2-Einstellungen.
  • conf-available
    • Enthält alle Config-Dateien die potentiell in den Server geladen werden sollen.
  • conf-enabled
    • Enthält symbolische Links zu allen Config-Dateien, die wirklich aktiviert werden sollen.
  • envvars
    • Datei, in der Apache2-Umgebungsvariablen gesetzt werden.
  • mods-available
    • gleich wie conf-available nur für Apache2-Module
  • mods-enabled
    • gleich wie conf-enabled nur für Apache2-Module
  • ports.conf
    • enthält Einstellungen auf welche Ports der Webserver Standardmäßig hören soll
  • sites-available
    • gleich wie conf-available nur für vHost-Configs
  • sites-enabled
    • gleich wie conf-available nur für vHost-Configs
  • magic
    • Regeln, um anhand der führenden Bytes einer Datei dem MIME-Typ zu erkennen.

Standard Apache vHost Config

Ordner: /etc/apache2/sites-available/<Dateiname>

<VirtualHost *:80>
    ServerName www.domain.com
    ServerAlias domain.com
    DocumentRoot /var/www/html/docroot
</VirtualHost>

Erklärung

  • VirtualHost *:80
    • Höre auf den Port 80
  • ServerName www.domain.com
    • Wende die unten angeführten Einstellungen an wenn der Hostname „www.domain.com“ ist
  • ServerAlias domain.com
    • Wende die unten angeführten Einstellungen an auch wenn der Hostname „domain.com“ ist
  • DocumentRoot /var/www/html/docroot
    • Zeige den Inhalt vom Ordner „/var/www/html/docroot“ an

Aktivieren einer neu erstellten vHost Config

ln -s /etc/apache2/sites-available/<Dateiname> /etc/apache2/sites-enabled/<Dateiname>

Testen der neu erstellten Apache vHost Config

apache2ctl configtest

Neustarten des Apache Webserver

apache2ctl restart

PHP-Handler hinzufügen

Bei Ubuntu/Debian basierenden Systemen funktioniert dies relativ einfach über ein Package welches – wie jede andere Software – über apt-get installiert wird.

sudo apt-get install -y php7.2-curl php7.2-gd php7.2-json php7.2-mbstring php7.2-mcrypt libapache2-mod-php7.2

Das wichtige hier ist das Package „libapache2-mod-php7.2“ was die Verbindung zwischen dem systemweit installierten PHP und dem Apache Webserver herstellt. Siehe mod_php für weitere Details.

Anstatt php7.2 kann php7.3 oder jegliche zukünftige PHP-Version angegeben werden die verwendet werden sollte.

Bei anderen Betriebssystemen kann dieser Prozess etwas anders ablaufen – hier bitte einfach Dr. Google fragen^^

Wenn alles funktioniert hat und der Webserver über apachectl restart neu gestartet wurde kann die Datei /var/www/html/info.php erstellt werden und mit folgendem Inhalt befüllt werden:

<?php phpinfo();

Danach kann über den Browser die Datei wie folgt aufgerufen werden:

http://<Server-IP>/info.php

Dies sollte nun die PHP-Info Seite der aktiv verwendeten PHP-Version anzeigen.

NGINX

NGINX ist ein freier Webserver der im Jahr 1999 von Igor Sysoev entwickelt wurde und ist aktuell die Nummer 2 der meist verwendetesten Webserver (Stand Mai 2019 – siehe „Was ist ein Webserver„).

Warum wurde noch ein Webserver entwickelt wenn es eh schon Apache gab?

NGINX ist primär aus dem sogenannten „C10k Problem“ entstanden.

Beim „C10k Problem“ geht es um die Optimierung der Handhabung von Network-Sockets um eine große Anzahl an Clients zu verabeiten.

C => Connection | 10k => 10.000

Hier hat NGINX mit seiner Event getriebenen, asynchronen Architektur die Basis für weitere zukünftigen „High-Performance“ Server-Software gelegt und wurde zum schnellsten verfügbaren Webserver.

Installation und Konfiguration

Das installieren vom NGINX Webserver ist bei jedem Betriebssystem etwas anders. An den folgenden Beispielen wird immer von Debian/Ubuntu ausgegangen.

sudo apt-get install nginx

Danach sollte folgender Befehl die aktuell installierte NGINX Version ausgeben:

nginx -v

Wie sonst bei allen anderen Software-Packages üblich befinden sich die Config-Dateien in /etc/nginx.

In diesem befinden sich folgende Dateien und Ordner

  • conf.d/
    • Hier können Konfigruationsdateien abgelegt werden
  • fastcgi.conf & fastcgi_params
    • Setzt Standardparameter für FastCGI Aufrufe.
  • mime.types
    • Mapping für Dateiendungen zu MIME-Types
  • modules-available/
    • Enthält Konfigurationsdateien von verfügbaren NGINX-Modulen
  • modules-enabled/
    • Enthält Symlinks zu den Konfigurationsdateien (in modules-available), welche aktiviert werden sollen
  • nginx.conf
    • Basis NGINX-Config File, welche für alle vHosts geladen wird
    • In dieser werden alle aktivierten Module, Konfigurationen und vHosts geladen
  • proxy_params
    • Hier sind ein paar standard Proxy-Parameter vorhanden.
  • scgi_params
    • Setzt standard SCGI-Parameter vorhanden
  • sites-available/
    • Beinhaltet Konfigurationen für die jeweiligen vHosts
  • sites-enabled/
    • Beinhaltet Symlinks zu den vHosts-Konfigurationsdateien (in sites-available), welche aktiviert werden sollen
  • snippets/
    • Beinhaltet Snippets für den Aufruf von PHP Dateien über FastCGI und für die Implementierung von selbst erstellten HTTPS Zertifikaten

Unwichtigere Dateien

  • uwsgi_params
  • koi-utf
    • Mapping für „KOI8-R“ (Kyrillisch) zu „UTF-8“ Characters
  • koi-win
    • Mapping für „KOI8-R“ (Kyrillisch) zu „Windows-1251“ Characters
  • win-utf
    • Mapping für „Windows-1251“ zu „UTF-8“ Characters

Neuen vHost erstellen

In /etc/nginx/sites-available befindet sich eine Datei „default“.

Diese baut sich wie folgt auf (unwichtige Kommentare (#) wurden entfernt)

server {
	listen 80 default_server; # IPv4 listen on Port 80
	listen [::]:80 default_server; # IPv6 listen on Port 80

	root /var/www/html; # Absolute path to Document-Root

	# Set default files to show when accessing the website
	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;

	server_name mydomain.at; # the domain name

	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
	}

	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	#	include snippets/fastcgi-php.conf;
	#
	#	# With php-fpm (or other unix sockets):
	#	fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
	#	# With php-cgi (or other tcp sockets):
	#	fastcgi_pass 127.0.0.1:9000;
	#}

	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	#	deny all;
	#}
}

Wenn diese Konfiguration aktiviert werden soll muss ein „Symlink“ in den Ordner /etc/nginx/sites-enabled erstellt werden.

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Bzw. wenn eine schon aktivierte Config deaktiviert werden soll:

unlink /etc/nginx/sites-enabled/default

Bevor man aber nun den NGINX Service neu startet sollte man checken, ob die neue Configuration auch valide ist:

nginx -t

Nach einer Änderungen der Config im NGINX muss immer der Service neu gestartet bzw. neu geladen werden.

systemctl reload nginx

Source: https://www.nginx.com/resources/glossary/nginx/

Gratis HTTPS Zertifikate mit LetsEncrypt

HTTPS-Zertifikate sind notwendig um ein Schloss bzw. ein grünes Symbol links neben der URL im Browser zu erhalten.

Arten von Zertifikaten

  • Self-Signed Certificates
    • Jeder kann selbst Zertifikate erstellen und in seine Webseiten integrieren.
    • Jedoch werden diese NICHT automatisch von den aktuellen Browsern als „sicher“ anerkannt und erhalten deswegen KEIN grünes Schlosssymbol neben der URL.
    • Diese Zertifikate müssen pro Client erst als „sicher“ akzeptiert werden.
  • Wildcard Certificate
    • Wird oft für Subdomain Certificate verwendet damit nicht pro Subdomain ein extra Certificate erstellt und eingebunden ist.
    • Beispiel: *.pfiff.me
  • Domain Validation (DV)
    • Hier wird überprüft, ob der Antragssteller der Inhaber der spezifischen Domain ist. Es werden keine Informationen zur Unternehmensidentität überprüft und es werden keine anderen Informationen angezeigt.
    • Wildcard-Certificates sind möglich!
    • Dies ist das Standardverfahren für die Gratis LetsEncrypt Zertifikate.
  • Organization Validation (OV)
    • Gleich wie DV aber es wird auch eine Überprüfung des Organisations-Standorts und Namens durchgeführt. Diese Informationen sind dann auch im Zertifikat für den Endkunden ersichtlich. Dadurch wird für dem Endkunden besser dargestellt, wer hinter der Webseite steckt.
    • Wildcard-Certificates sind möglich!
  • Extended Validation (EV)
    • Gleich wie OV, nur wird detaillierter die Organisation überprüft.
    • Der Name der Organisation wurde früher neben dem grünen Schloss angezeigt. Jedoch wurde dieses Feature von den aktuellen Browser Herstellen wie Chrome, Firefox, Safari etc. inzwischen schon entfernt. Daher ist die Sinnhaftigkeit von einem EV-Certificate fragwürdig.
      Siehe https://www.troyhunt.com/extended-validation-certificates-are-dead/
    • Wildcard-Certificates sind NICHT möglich!

Was ist eine „Certificate Authority“ (CA)?

Eine „Certificate Authority“ (kurz CA) wird benötigt um erstellte Zertifikate mit gewissen vordefinierten Methoden zu überprüfen und bei erfolgreicher Prüfung diese signieren. Zusätzlich wird bei der Signierung ein Ablaufdatum gesetzt ab wann eine erneute Überprüfung durchgeführt werden muss.

„Früher“ gab es prinzipiell nur die Möglichkeit ein HTTPS-Zertifikate käuflich zu erhalten. Jedoch gibt es seit 2015 „LetsEncrypt“ bzw. die in Python geschriebene Software „Certbot“.

LetsEncrypt nimmt als Basis die „Domain-Vaildation“ (DV). Daher kann jeder, der Inhaber einer Domain ist und diese auf einen Server zeigen lässt, ein signiertes LetsEncrypt Zertifikat generieren lassen.

Was ist Certbot?

Certbot ist eine Software, die das automatische generieren und verwalten von HTTPS-Zertifikaten übernimmt.

Aktuell gibt es für die 2 am meisten verwendeten Webserver (Apache und NGINX) Plugins, die sogar das installieren der Zertifikate übernehmen.

Damit muss man nicht selbst in der jeweiligen Apache oder NGINX vHost Config die Zertifikat-Pfade händisch eingeben.

Am einfachsten folgt man den Anleitungen laut https://certbot.eff.org wie man Certbot für das aktuelle Betriebsystem und für den verwendeten Webserver installiert und verwendet.

Die Gültigkeit eines über Certbot bzw. LetsEncrypt generierten Zertifikats ist 90 Tage. Jedoch überprüft Certbot regelmäßig die Gültigkeit alles generierten Zertifikate und erneuert automatisch alle Zertifikate die nur mehr 1 Monat lang gültig sind.

Damit braucht man nur 1 mal ein Zertifikat für eine Webseite erstellen und installieren und es sollte in Zukunft keine Probleme geben mit dem Zertifikat.

Informationen von einem Zertifikat

Source: https://www.digitalocean.com/community/tutorials/a-comparison-of-let-s-encrypt-commercial-and-private-certificate-authorities-and-self-signed-ssl-certificates