Ubuntu 20.04 LTS (Focal Fossa) - NordVPN installieren unter Root


Guten Tag meine lieben Technik Fans,

heute schauen wir uns mal im schnell Durchlauf an wie wir die aktuelle NordVPN Software auf einen frisch installieren Ubuntu 20.04 Forcal Fossa VPS / PC / Rechner installieren können. Das ganze machen wir mit dem Benutzer Account "root". Also lasst uns loslegen.

NordVPN installieren unter Ubuntu 20.04


Einfach die Befehle kopieren und ausführen ;=)

Schritt 1: NordVPN .deb Package herunterladen (https://nordvpn.com/de/download/linux/)

# wget https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/nordvpn-release_1.0.0_all.deb


Schritt 2: Repository installieren

# sudo apt-get install /root/nordvpn-release_1.0.0_all.deb
Hinweiß! solltet Ihr hier eine Fehlermeldung in der Art erhalten: "Download is performed unsandboxed as root" dann fehlen dem User _apt die Rechte. Führt dann folgendes aus.

# sudo chown -Rv _apt:root /var/cache/apt/archives/partial/
# sudo chmod -Rv 700 /var/cache/apt/archives/partial/


Schritt 3: Aktualisiere deine Paketlisten

# sudo apt-get update && sudo apt-get upgrade

Schritt 4: NordVPN installieren

sudo apt-get install nordvpn

Fertig!

Das war es auch schon. Am Ende könnt ihr ja noch mal prüfen ob alles geklappt und und ob Ihr die passende Version installiert habt. Mit "nordvpn --version" zeigt Ihr euch die installierte Version an. Falls Ihr irgendwelche Fragen oder Anregungen habt dann einfach ab in die Kommentare.

PHP-FPM Einstellungen optimieren

Heute geht es darum den unter PHP Nutzern bekannten FastCGI Process Manager (FPM) richtig zu konfigurieren und zu optimieren. (https://php-fpm.org/)

Die meisten PHP Anwendungen verwenden Heutzutage den PHP-FPM um Ihre PHP Anwendungen auszuliefern. In Kombination mit NGINX als Webserver ist dies mit einer der effektivsten Methoden eine Webanwendung mit PHP im Produktiveinsatz laufen zu lassen.

Der Teufel steckt im Detail

Bei FPM reichen schon ein paar falsch gesetzte Werte und schon startet der FPM Prozess nicht mehr oder der Speicher des Servers läuft voll oder oder oder ... die Liste ist lang ;)

Häufige Fehler die auftreten können:
  • FPM Master Prozess startet nicht mehr
  • RAM des Servers läuft voll
  • "server reached max_children"

Prüfen ob PHP-FPM Prozess läuft

Das Beispiel zeigt die PHP-FPM Prozesse und für welche pool Konfiguration / User diese ist, in dem Falle zu sehen "web1" da unter ISPConfig der erste angelegt Host "web1" ist.
ps aux | grep fpm

PHP-FPM Konfiguration anpassen

In diesem Beispiel hier zeige ich euch wie Ihr die Konfiguration anpasst anhand einer ISPConfig Standard Installation mit einer angelegten Webseite. Dazu bearbeiten wir die Datei:

nano /etc/php/7.0/fpm/pool.d/web1.conf

Der Inhalt der Datei sieht dann so aus (kann je nach Installation abweichen):

[web1]

listen = /var/lib/php7.0-fpm/web1.sock
listen.owner = web1
listen.group = www-data
listen.mode = 0660

user = web1
group = www-data

pm = dynamic
pm.max_children = 50
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 1000

....
....

Ich werde jetzt die wichtigsten Einstellung im Detail erklären und euch gegebenenfalls Hinweise dazu geben. Aber fangen wir direkt an mit der wohl wichtigsten Einstellung "pm.max_children".

Wichtigste PHP-FPM Einstellungen einfach erklärt

  • pm (string)
    • es gibt 3 mögliche Einstellungen, dynamic ist meistens die beste Wahl
      • static - Anzahl der Kindprozesse ist fest (pm.max_children)
      • ondemand - Kindprozess wird erst erstellt wenn er benötigt wird (pm.start_servers)
      • dynamic - dynamische Einstellung der Kindprozesse (benötigt folgenden Einstellungen: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers)
  • pm.max_children (int)
    • Anzahl der Kindprozesse die erstellt werden wenn pm = static oder die maximale Anzahl der Kindprozesse wenn pm = dynamic. Einstellung ist notwendig!
  • pm.start_servers (int)
    • Anzahl an Kindprozessen, die beim Start erstellt werden. Wird nur verwendet, wenn pm auf dynamic gesetzt ist. Standardwert: min_spare_servers + (max_spare_servers - min_spare_servers) / 2.
  • pm.min_spare_servers (int)
    • gewünschte Mindestanzahl an Prozessen. Wird nur genutzt, wenn pm auf dynamic gesetzt ist. Zwingend notwendig!
  • pm.max_spare_servers (int)
    • gewünschte Maximalanzahl an Prozessen. Wird nur genutzt, wenn pm auf dynamic gesetzt ist. Zwingend notwendig!
  • pm.max_requests (int)
    • Anzahl der Requests bis der FPM Prozess neustartet, hilft Memory Leaks in einigen PHP Libs zu fixen
Noch viele weitere und detailliertere Beschreibungen könnt Ihr in der Dokumentation von PHP finden.

Optimalen Wert für "pm.max_children" bestimmen

Um den perfekten Wert für pm.max_children zu finden muss man zuerst herausfinden wieviel Speicher ein FPM Prozess mit der aktuellen Anwendung verbraucht. Dazu können wir auf 2 verschiedenen Befehle zurück greifen.

ps -ylC php-fpm7.0 --sort:rss

Das sollte dann in etwa so bei euch aussehen:
Für uns von Bedeutung ist die Spalte "RSS" diese gibt den Speicherverbrauch des Prozesses in Kilobyte an. Also wären 43868 rund ~ 43MB für diesen Prozess. Um das ganze etwas zu vereinfachen können wir aber einfach den Befehl ausführen und erhalten den Durchschnitt.

ps --no-headers -o "rss,cmd" -C php-fpm7.0 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"Mb") }'

// Output
34Mb

Mit diesem Verbrauchswert können wir nun den passenden Wert für pm.max_children berechnen. Dazu nehme ich einfach mal ein Beispiel (einen VPS der 2GB RAM hat).
  • VPS mit 2 GB RAM
    • wir ziehen 256 MB ab da noch andere Dienste auf dem VPS laufen
    • uns bleiben 1792 MB Ram
      • Formel: max_children = Free RAM VPS / RAM pro Prozess
      • max_children = 1792 / 34
      • = 52,7 = ~ 52
Der Ideale Wert für diesen VPS wäre also pm.max_children = 52. Natürlich sollte man diesen Wert nicht einfach Blind übernehmen! Ändert eure Einstellungen und dann testet wie sich euer Server verhält. Wenn Ihr eure Konfiguration angepasst habt, startet Ihr am besten euer FPM neu. Dies könnt Ihr mit folgendem Befehl machen:

sudo /etc/init.d/php7.0-fpm restart

Resümee

Ein optimal Konfigurierter PHP-FPM Service erspart euch auf eurem Produktivsystem eine Menge ärger. Denn niemand möchte einen überlaufenden Speicher oder eine langsame PHP Anwendung nur weil der FPM Dienst falsch konfiguriert ist. Nehmt euch die Zeit ermittelt die optimalen Werte und setzt diese dann um. Oft hilft es auch die Logs regelmäßig zu checken um sehen ob alles ohne Probleme funktioniert und ob nicht doch der Server bald an seine Grenzen kommt. 

Ich hoffe ich konnte dem ein oder anderem das Mysterium PHP-FPM näher bringen und wünsche euch viel Erfolg beim optimieren eurer Einstellungen.

Monero/AEON Mining mit XMR-STAK 2.0

Tutorial Monero Mining Ubuntu (XMR-STAK 2.0)

Neue Version XMR-STAK 2.0.0 ausprobiert!

Der Entwickler "fireice-uk" hat eine neue Version von seiner beliebten Mining Software XMR-STAK veröffentlicht. Grund für uns sich diese einmal etwas genauer anzuschauen.

Laut Changelog haben wir in dieser Version einige interessante Änderungen. Denn die Software vereint jetzt alle drei Versionen zu einer Software. Wir benötigen also nicht mehr extra den XMR-STAK-CPU, XMR-STAK-AMD oder XMR-STAK-NVIDA Miner sondern können bequem alles aus einer Hand installieren und konfigurieren. Außerdem unterstützt die Software jetzt die Kryptowährung AEON, welche wie Monero auf einen ähnlichen Hash Algorithmus zurück greift (CryptoNote Lite). Dieser ist für Smartphones optimiert. Wie ich finde auch eine interessante Kryptowährung. Wer mehr darüber wissen möchte kann gern mal auf der offiziellen Seite vorbeischauen.

Hier jetzt noch einmal der komplette Changelog der Vollständigkeit halber.

Features
  • 10% boost to CPUs without hardware AES
  • Supports all common backends (CPU/x86, AMD-GPU and NVIDIA-GPU)
  • Supports all common OS (Linux, Windows and MacOS)
  • Supports algorithm cryptonight for Monero (XMR) and cryptonight-light (AEON)
  • Guided start (no need to edit a config file for the first start)
  • Automatic configuration for each mining backend
  • Allows to tweak each core or gpu by hand
  • Supports backup pools
  • TLS support
  • HTML statistics
  • JSON API for monitoring
  • Support the new stratum statistics extension
  • Easy precompiled and portable Linux binary

Installation XMR-STAK 2.0 unter Ubuntu

Das neue XMR-STAK bietet jetzt auch eine bereits kompilierte Version welche man portable typisch nur noch herunterladen muss und ausführen kann. Dies spart das selbst kompilieren.

// wir legen uns einen Ordner an
mkdir xmr-stak-portable
// download
wget https://github.com/fireice-uk/xmr-stak/archive/v2.0.0.tar.gz
// entpacken das Archiv
tar xzf xmr-stak-portbin-linux.tar.gz
// starten
./xmr-stak.sh

XMR-STAK 2.0 Setup Assistent

Nach dem wir alles heruntergeladen haben und das Programm starten, müssen wir einige Fragen beantworten welche das Setup darstellen. Wie so etwas aussehen kann seht Ihr im folgenden Beispiel.

// starten
./xmr-stak.sh 
Please enter:
- Currency: 'monero' or 'aeon'
monero
- Pool address: e.g. pool.usxmrpool.com:3333
pool.supportxmr.com:3333
- Username (wallet address or pool login):
423gorEqp1GR1Rn431fwuQVmrSAw7v86z3CygoeLsbr6EvenAMeKus1CiZgXana9b1RjnAPbaxyBL4CP5QpdL8PK88KkdRi
- Password (mostly empty or x):
Worker-CPU-01
- Does this pool port support TLS/SSL? Use no if unknown. (y/N)
N
- Do you want to use nicehash on this pool? (y/n)
n
- Do you want to use multiple pools? (y/n)
n
Configuration stored in file 'config.txt'

Unsere Einstellungen kann man nachträglich jederzeit ändern. Das Programm erzeugt 2 Dateien welche im aktuellen Verzeichnis erstellt werden.


  • config.txt - Allgemeine Einstellungen
  • cpu.txt - Einstellungen fürs CPU Mining
Ich vermute mit einer entsprechenden Grafikkarte würde dann dort noch eine Konfiguration für die Grafikkarte zu finden sein. Nach der Konfiguration ist der Miner fertig und einsatzbereit.

Automatisches deployen / installieren auf Server / VPS

Die neue Version ermöglicht es uns außerdem die Installation auf einem Server / VPS in wenigen Sekunden vorzunehmen. Dafür benötigen wir nur eine einmalig auf unsere Zecke eingestellte config.txt die über eine Webadresse verfügbar ist (z.B. http://meine-domain.de/config.txt).

Auf unserem Server legen wir dann ein kleines Bash Script mit folgendem Inhalt an.

#!/bin/bash
curl -O `curl -s https://api.github.com/repos/fireice-uk/xmr-stak/releases/latest | grep -o 'browser_download_url.*xmr-stak-portbin-linux.tar.gz' | sed 's/.*"//'`
curl -O http://meine-domain.de/config.txt
tar xzf xmr-stak-portbin-linux.tar.gz
./xmr-stak.sh

Dieses Script führen wir dann aus und in wenigen Sekunden haben wir ein lauffähiges Mining Setup auf unserem Server. Einfacher geht es nicht oder?

Wer noch wissen möchte wie das ganze im Hintergrund ausführen kann ohne beim schließen des Terminals das Mining zu beenden sollte sich meinen anderen Artikel noch einmal ansehen.

Was sagt Ihr zu der neuen Version? Findet Ihr die Verbesserungen gut und sinnvoll? Schreibt mir gern eure Meinung dazu in die Kommentare. Falls Ihr Fehler gefunden habt meldet diese bitte auch in den Kommentaren.

Viel Spass beim Minig

Webserver NGINX Performance Tuning

Schnell? Schneller? NGINX? Performance!!!


Heute beschäftigen wir uns mit dem Thema NGINX und Performance Optimierung. Wir wissen alle das der NGINX der König unter den Webservern ist und deshalb schauen wir uns heute an, wie wir das letzte Fünkchen Geschwindigkeit aus dem Webserver herausholen. Zu dem Zeitpunkt wo ich diesen Beitrag schreibe gibt es den NGINX in der Stable Version 1.12.1 (Download).

Backup der NGINX Config

Als erstes ist es wichtig eure aktuelle funktionierende NGINX Konfiguration zu sichern (Kopie davon erstellen) damit wir nichts zu fürchten haben falls etwas nicht ganz so läuft wie von euch erhofft. Die Konfiguration findet Ihr z.B. bei Ubuntu unter /etc/nginx/nginx.conf

Performance? Optimieren!

Jetzt werde ich euch einzelne NGINX Core Module Direktiven vorstellen die euch helfen werden eure Webserver Performance zu steigern. Ich versuche dabei kurz und verständlich die Werte zu erklären. Alle folgenden Werte können in der nginx.conf bearbeitet oder hinzugefügt werden.

worker_processes auto;
Gibt an wie viele NGINX Worker Prozesse laufen. auto = automatische Erkennung. Generell gilt, man kann auch die Anzahl der verfügbaren CPU Cores angeben. (z.B. VPS mit 2 Kernen = auf 2 stellen).

worker_connections 1024;
Gibt an wie viele gleichzeitige Verbindungen pro Worker aufgebaut werden können. Die maximale Anzahl der Clients wird also wie folgt Berechnet. max Clients = worker_processes * worker_connections. Tip: hier ein wenig testen wie viel euer Server schafft.

use epoll;
Wichtig für Linux Server um viele Clients in einem Thread zu verarbeiten.

multi_accept on;
Dadurch werden so viele neue Verbindungen wie möglich akzeptiert von einem Worker Prozess.

sendfile on;
Kopiert Daten von einem FD (File Descriptor) zu einem innerhalb des Linux Kernels. Das ist schneller als read() + write()

tcp_nopush on;
Sendet den Request Header in einem Stück, dies ist besser als viele kleine.

tcp_nodelay on;
Aktiviert die TCP Option TCP_NODELAY. Daten werden nicht mehr im BUffer zwischen gespeichert, sondern gleich verschickt.

access_log off;
Um schwache Festplatten zu entlasten und den HDD I/O zu verbessern.

gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/json application/xml;
gzip_disable msie6;
Komprimiert die ausgegebenen Dateien, dies spart Traffic. Sollte nur bei ausreichend CPU Leistung aktiviert werden!

reset_timedout_connection on;
Erlaubt es dem Server die Verbindung zu nicht antwortenden Clients zu schließen. Das spart Arbeitsspeicher.

client_body_timeout 10;
Der Request Timeout. Standard ist bei 60. Falls keine Dateien auf eurer Seite hochgeladen werden sollte der Timeout reduziert werden z.B. auf 10 Sekunden

send_timeout 2;
Wenn der Client nicht mehr reagiert und nichts empfängt dann stoppe (Standard ist 60). Spart Arbeitsspeicher.

keepalive_timeout 30;
Schließt die Verbindung nach der angegebenen Zeit. Standard ist 75. Hier kann etwas experimentiert werden.

keepalive_requests 100;
Wie viele Keep Alive Requests gemacht werden können. Standard ist 100. Beachtet wie viele gleichzeitigen Besucher Ihr auf eurer Seite erwartet.

server_tokens off;
Erhöht die Sicherheit. Der Server schickt keine Version etc mehr heraus.

open_file_cache max=100000 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2;
open_file_cache_errors on;
Der Cache kann die Performance steigern, die optimalen Werte solltet Ihr durch testen herausbekommen. Eine detaillierte Erklärung dazu findet Ihr hier

Beispiel Konfiguration für einen 2 Kern VPS (/etc/nginx/nginx.conf)


user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
        worker_connections 1024;
        use epoll;
        multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 30; # default 75
        keepalive_requests 100;   # default 100
        reset_timedout_connection on;
        client_body_timeout 10; # default 60
        send_timeout 10; # default 60
        types_hash_max_size 2048;
        server_tokens off;
        
        # File Cache
        open_file_cache max=100000 inactive=20s; 
        open_file_cache_valid 30s; 
        open_file_cache_min_uses 2;
        open_file_cache_errors on;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log off;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        #gzip on;
        #gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Wichtig für Dateiuploads in Verbindung mit NGINX

Falls Ihr auf eurer Seite einen Upload von Dateien anbietet solltet Ihr in eurer vhost Config noch folgende NGINX Einstellungen setzen.

        client_max_body_size 1G;
        client_body_buffer_size 1024k;

In diesem Beispiel ist er möglich Dateien von einer größe von 1 GB auf den Server zu laden.

Konfiguration neu einlesen oder NGINX neustarten

Um die ganzen neuen Einstellungen zu testen könnt Ihr die Config neu einlesen lassen:

# /etc/init.d/nginx reload

Oder Ihr startet den Webserver einfach neu.

# /etc/init.d/nginx restart

Falls etwas falsch sein sollte würde an dieser Stelle eine entsprechende Meldung erscheinen. Abschließend hoffe ich das euch das ein oder andere Helfen konnte und Ihr eure Server Performance steigern konntet. Über Verbesserungsvorschläge und Tips würde ich mich sehr freuen. Schreibt es in die Kommentare ;)

Buchempfehlung über NGINX

Vor 2 Jahren habe ich mir das Buch "Nginx HTTP Server" bei Amazon bestellt. Damit habe ich begonnen mich in die Materie einzuarbeiten. Dort sind alle grundlegenden Elemente des Webservers sehr gut und ausführlich erklärt. Für komplette Neueinsteiger zu empfehlen.

Fortgeschrittene sollten sich das demnächst erhältliche Taschenbuch "Nginx: A Practical Guide to High Performance"  von Stephen Corona (Autor) mal genauer ansehen. Es wirkt auf den ersten Eindruck sehr interessant und vielleicht bekommt man von Ihm wertvolle Tips für eine optimale Konfiguration. Lasst es mich wissen falls jemand das Buch empfehlen kann.

Quellen:

Ubuntu 16.04 einrichten von SSL / HTTPS unter NGINX

Einleitung

Im Jahre 2017 sollte SSL Standard für jede Webseite sein. Warum das leider immer noch nicht so ist liegt vielleicht daran, dass viele Leute abgeschreckt sind von der Einrichtung oder nicht wissen wie es umgesetzt wird. In diesem kleinen Tutorial, möchte ich euch Heute zeigen, wie einfach es doch ist SSL unter Ubuntu mit einem NGINX Webserver einzurichten.

Voraussetzungen

Eine kleine Liste mit Dingen die ich für dieses Tutorial voraussetze.
  • Ubuntu Server
  • NGINX Server installiert
  • OpenSSL installiert
Außerdem solltet Ihr auf eurem Server die entsprechenden "root" oder "sudo" Rechte haben. Wenn ihr das alles habt können wir auch schon beginnen.

Schritt 1 - Zertifikat erzeugen

Als erstes brauchen wir einen Ort wo wir das Zertifikat ablegen und speichern wollen. Da es sich hier um ein Zertifikat für den NGINX handelt erzeugen wir einfach im NGINX Ordner einen weiteren Ordner "ssl".

  sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

Kurze Erklärung zu dem Befehl:
  • openssl: Standard Konsolen Programm um Zertifikate zu erstellen
  • req: sagt aus das wir eine X.509 Signierungsanfrage erstellen wollen. X.509 ist ein Standard für SSL und TSL
  • -x509: Die Option sagt aus das wir ein selbst signiertes Zertifikat erstellen wollen
  • -nodes: Teilt OpenSSL mit das wir keine Passwortabfrage bei dem Zertifikat benötigen. Wäre auch schlecht da NGINX dann bei Neustarts immer danach fragen würde
  • -days 365: Anzahl der Tage wie lange das Zert. gültig ist
  • -newkey rsa:2048: Sagt das wir einen neuen Schlüssel und Zertifikat mit einem 2048 Bit Schlüssel möchten
  • -keyout: Gibt OpenSSL einen Ort an wo der Schlüssel gespeichert werden soll
  • -out: Gibt OpenSSL einen Ort an wo das Zertifikat gespeichert werden soll
Anschließend wirst du nach einigen Angaben gefragt. Diese kannst du leer lassen oder ausfüllen.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Die von dir erstelleten Dateien werden in dem angegebenen Ordner abgespeichert.

Schritt 2 - NGINX Konfigurieren

Ein Vorteil von NGINX gegenüber dem Apache ist das man HTTPS/SSL in der selben Vhost Config aktivieren kann wo auch HTTP konfiguriert ist. Wir bearbeiten dazu unsere Standard Konfiguration unter.

nano /etc/nginx/sites-available/default

Wir fügen 4 Zeilen hinzu.

server {
        # ipv4 http
        listen 80 default_server;
        # ipv6 http
        listen [::]:80 default_server;
        # ADDED ipv4 https
        listen 443 ssl default_server;
        # ADDED ipv6 https
        listen [::]:443 ssl default_server;

        server_name default;

        root   /var/www/application/public;

        index index.html index.htm index.php index.cgi index.pl index.xhtml;

        # ADDED ssl settings
        ssl_certificate         /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key     /etc/nginx/ssl/nginx.key;

        # log
        error_log /var/www/application/log/error.log;
        access_log /var/www/application/log/access.log combined;

        # rewrite
        location / {
            try_files $uri $uri/ /index.php;
        }

        # php socket
        location ~ \.php$ {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/run/php/php7.1-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }

}

Die ersten beiden hinzugefügten Zeilen kümmern sich darum das der NGINX auf den richtigen Port lauscht und IPv4 und IPv6 anfragen annimmt.

Die anderen 2 kümmern sich darum das der NGINX den Schlüssel und das Zertifikat läd.

Danach starten wir neu uns schauen ob alles klappt.

sudo service nginx restart
ODER
sudo /etc/init.d/nginx restart

Nach erfolgreichem Neustart sollte unsere Seite unter http und https erreichbar sein.

HTTPS testen

Um unsere Konfiguration zu testen erstellen wir in unsrem Verzeichnis (/var/www/application/public) eine index.html zum testen. Unsere Seite dann unter beiden Adressen erreichbar sein

http://server_domain_or_IP
UND
https://server_domain_or_IP:443

Hinweiß: In den meisten Browsern muss man noch das Zertifikat akzeptieren damit die Seite dargestellt wird. Denn euer Lokales Zertifikat gilt in den Browsern als nicht sicher.

Abschluss

Abschließend ist zu sagen, dass der Aufwand SSL einzurichten doch relativ gering ist und für lokale Tests sehr zu empfehlen ist. Wenn eure Applikation lokal zu 100% läuft, solltet Ihr den Schritt nicht scheuen auch Live SSL mit einem richtigen Zertifikat zu verwenden. Richtige Zertifikate bekommt Ihr dank "Lets Encrypt" quasi für 0€.

Viel Spass beim testen. Bei Fragen benutzt bitte die Kommentare.

vServer Erstellen und Verwalten mit Proxmox

Du hast einen eigenen Root Server und möchtest diesen in mehrere vServer aufteilen? Und diese dann einfach Verwalten und Konfigurieren? Dann ist diese schöne Tutorial, welches ich auf Youtube gefunden habe genau das richtige für dich. Vielen Dank an BennetRichter98 für diesen ausführlichen Beitrag auf deutsch.