Raspberry Pi als Webserver mit nginx
Wir werden nginx als Webserver installieren, PHP, als Datenbank SQLite (MySQL vorbereiten), so daß du Webseiten laufen lassen kannst. Dann werden wir SSL Zertifikate erstellen und einbinden, so daß du den Zugriff auf deine Website mit https absichern kannst. Zuletzt das ganze über eine externe Domain (bspw. https://deinesubdomain.example.com) erreichbar machen.
Voraussetzungen
Dieses Tutorial setzt voraus, daß du dich schon ein wenig mit dem Raspberry Pi auskennst. Es wird aber nicht wirklich viel vorausgesetzt. Du mußt wissen, wie du dich mit dem Raspi verbindest. Du arbeitest entweder direkt darauf oder remote - bspw. per SSH von Linux oder Windows aus oder per RDP von Windows aus. Du solltest wissen, wie du das Terminal startest und wie du dort Befehle eintippst und ausführst. In diesem Tutorial werden wir - bis auf ein paar Tests am Ende - ausschließlich in der Shell arbeiten; dh. mit dem Terminal. Bist du neu beim Pi, hast du idealerweise das Einsteigertutorial Raspberry Pi installieren durchgearbeitet.
Verbinde dich mit deinem Raspi
Alternative a: SSH mit putty von Windows aus.
Starte putty. Gebe den Hostnamen deines Raspi ein. Kommst du vom Einsteigertutorial "Raspberry Pi installieren" ist das "RASPI03". Klicke Open.
Im Terminalfenster kommt als erstes die Anmeldung.
User: pi
Passwort: raspberry (bzw. dein eigenes Passwort, falls du es wie im oben erwähnten Einsteigertutorial beschrieben gleich geändert hast)
Alternative b: du arbeitest direkt auf dem Raspi.
Starte LXTerminal - bspw. über die Taskleiste. Keine Anmeldung. Du bist ja schon als User pi angemeldet.
Updates
Falls du von einem Vortutorial hierher gekommen bist, wirst du keine Updates ausführen müssen. Das hast du dort bereits gemacht. In so kurzer Zeit wird sich nichts geändert haben. Hattest du aber eine längere Pause oder beginnst du erst hier, dann könntest du den Raspberry Pi auf den aktuellen Stand bringen.
sudo apt-get update
sudo apt-get upgrade
Nginx installieren
Standard raspbian könnte apache2 vorinstalliert und konfiguriert haben. Wir könnten nginx einfach "dazu" installieren. Dabei würde der alles nötige erledigen, einrichten, verknüpfen, etc. Bin mir nicht sicher, woran es genau lag, aber immer wieder ist es mir passiert, daß dann anscheinend doch wieder irgendwie was vom apache "dazwischen kam". Kanns nicht genau sagen, aber ich hatte halt hinundwieder den Effekt "wieso macht er das jetzt nicht? die letzten 20 installs gings doch!?" Nun, seitdem mache ich immer folgendes:
sudo apt-get purge apache2
Das deinstalliert den Apache und entfernt alle seine configs.
nginx installieren:
sudo apt-get install nginx
ein paar grundlegende Befehle um den webserver zu starten, anzuhalten etc.
starten
sudo /etc/init.d/nginx start
anhalten/stoppen/ausschalten
sudo /etc/init.d/nginx stop
wenn er bereits läuft, neu starten, d.h. ein reboot des webservers
sudo /etc/init.d/nginx restart
restart hat eine kurze Unterbrechung, bei reload läuft nginx weiter, lädt nur seine Konfig neu
(genauer Unterschied zwischen restart und reload läßt sich im Netz finden/suchen)
sudo /etc/init.d/nginx reload
das ganze geht auch mit dem service befehl, ist äquivalent, es gibt da keinen unterschied zu oben:
sudo service nginx start
sudo service nginx stop
sudo service nginx restart
sudo service nginx reload
Module installieren (php, Datenbank, etc.)
Je nachdem, von welchem Vortutorial du kommst oder wohin du anschließend weiter gehst, wirst du unterschiedliche Module brauchen. PHP wirst du vrmtl. immer brauchen; als Datenbank mal SQLite, mal MySQL oder auch schon MariaDB. Du liest dir am besten die nachfolgende Absätze erstmal durch, bevor du weiter installierst und entscheidest dann, welcher bzw. welche der Installbefehle/-varianten auf deine Situation zutrifft.
PHP
sudo apt-get install php php-fpm php-pear php-common php-mcrypt php-cli php-gd
Installiert PHP in der aktuellen Version; gleich mitsamt ein paar grundlegenden PHP-Modulen und -Erweiterungen. Die aktuelle Version dadurch, da wir keine Versionsnummer mit angegeben haben.
Willst du eine bestimmte PHP-Version haben, so gibst du ein
sudo apt-get install php5 php5-fpm php5-pear php5-common php5-mcrypt php5-cli php5-gd
sudo apt-get install php5.6 php5.6-fpm php5.6-pear php5.6-common php5.6-mcrypt php5.6-cli php5.6-gd
sudo apt-get install php7.0 php7.0-fpm php7.0-pear php7.0-common php7.0-mcrypt php7.0-cli php7.0-gd
installierst du PHP7 mit Version 7.0.
Ich denke, du hast das Prinzip verstanden. Ich möchte hier nicht tiefer einsteigen; evtl. nur noch anmerken, daß das nicht mit jeder Version genau so buchstabengetreu funktionieren muß. Wenn du eine ganz bestimmte Version haben magst, mußt du evtl. bei dem einen oder anderen PHP-Modul leicht abwandeln. So kann es sein, daß bspw. ein "php5.6-modulname" nicht funktioniert und dafür das "übergeordnete" "php5-modulname" genommen werden muß. Oder es könnte sein, daß das allgemeine "php-modulname" nicht geht; also ganz ohne Versionsnummer, um das aktuellste zu erhalten. Und du stattdessen die Versionsnummer mit angeben mußt. Das nur so am Rande.
Auf eine Fehlermeldung möchte ich noch kurz eingehen. Bei anderen Fehlern wirst du dir anhand der Fehlermeldungen selbst weiterhelfen müssen. Möchtest du bspw. mit "sudo apt-get install sqlite php-sqlite" installieren, bekommst du Fehlermeldung
E: For package php-sqlite existiert kein Installationskandidat.
Es wäre schön php-sqlite zu nutzen, um auch das mit der aktuellsten passenden Version zu erhalten. Scheints aber nicht zu geben und du mußt es bestimmter angeben; mit "sudo apt-get install sqlite php5-sqlite" oder "sudo apt-get install sqlite php7-sqlite" usw. Du solltest natürlich vorher wissen, welche PHP-Version installiert ist.
Aktuelle PHP-Version herausfinden
Variante 1: Gib "ls /etc/php" in der Shell ein. Dort legt PHP bei der Installation für die jeweilige Version ein Verzeichnis an. Ist dort "7.0" als Unterverzeichnis vorhanden, hast du die PHP-Version 7.0.x installiert. Du kannst auch mehrere PHP-Versionen parallel nebeneinander installieren. Darauf gehen wir aber hier nicht weiter ein.
Variante 2: Wurde PHP fehlerfrei installiert, so kannst du dir in der Shell mit "php -v" die aktuelle Version anzeigen lassen.
Datenbank - MySQL
sudo apt-get install mysql-server php-mysql
Du wirst MySQL anschließend noch (grund-)einrichten müssen. Ich überspringe das hier. Du wirst bei mir (auch in absehbarer Zeit) vermutlich kein MySQL-Tutorial finden. Ich werde mich höchst wahrscheinlich gleich auf MariaDB konzentrieren und MySQL ganz überspringen. Im Netz wirst du sicher gute Anleitungen finden, falls du MySQL für dein Projekt brauchst.
Datenbank - SQLite
Der "allgemeine" Weg
sudo apt-get install sqlite php-sqlite
hat bei meinem letzten Testdurchlauf (Raspbian Stretch, Herbst 2017) nicht funktioniert. SQLite selber ging, doch für das PHP-Modul bzgl. SQLite mußte ich die PHP-Version mit angeben. Dh. mit "php -v" die PHP-Version herausfinden - siehe oben. Und dann je nach PHP-Version
sudo apt-get install sqlite php5-sqlite
oder
sudo apt-get install sqlite php7-sqlite
Weiter einrichten - wie bei MySQL - muß man SQLite nicht. Die Installation reicht. Danach läufts ohne weiter eingerichtet werden zu müssen.
Laut gedacht: eigentlich schade, daß SQLite nicht den "allgemeinen" Weg mit php-sqlite zur Verfügung stellt. Das php7-sqlite war bei meinem letzten Versuch auch nur ein wrapper, der dann php7.0-sqlite3 ausgeführt hat. Auch wird diskutiert, daß man php-sqlite3 nehmen sollte, um nicht die PHP-Version kennen zu müssen. Dann hat man SQLite3 - aber zum Zeitpunkt, wenn du das Tutorial durchgehst, könnte bereits SQLite4 oder SQLite5 aktuell sein. Nun, hier heißt es: Augen auf, Gehirn einschalten, dann das richtige installieren - und hoffen, daß auch SQLite irgendwann einen "länger haltbaren" Installweg findet.
Bezug zu anderen Tutorials
Am Anfang des Abschnitts "Module installieren" haben wir geschrieben, daß du erstmal lesen sollst; dann entscheiden, welche Befehle du brauchst, für das konkrete Tutorial von dem du kommst. Nachfolgend liste ich für die aktuell vorhandenen Tutorials die notwendigen Befehle auf. Ich werde versuchen, die Liste aktuell zu halten. Kann das aber nicht versprechen. So daß du auch im Tutorial von dem du kommst schauen mußt, ob da nicht evtl. aktuellere Install-Befehle stehen. Dh. du wirst hier und dort vergleichen und etwas mitdenken müssen.
Tutorial "CalDav mit Baikal"
Zuerst PHP installieren
sudo apt-get install php php-fpm php-pear php-common php-mcrypt php-cli php-gd
sudo apt-get install sqlite php7-sqlite
Dabei nicht vergessen, das php7-sqlite an deine PHP-Version anzupassen.
Nachdem die Module installiert wurden
Die "neuen" Module sind erst nach einem Neustart von nginx verfügbar.
sudo /etc/init.d/nginx restart
sudo /etc/init.d/php5-fpm restart
Obs wirklich notwendig ist, kann ich nicht sagen. Aber ich meine gelesen zu haben, daß auch das PHP-FPM einen restart haben möchte. Der genaue Befehl hängt hier von der PHP-Version ab. Mit "ls /etc/init.d" kannst du herausfinden, wie es heißen muß. Nachfolgend ein paar Beispiele, wie der Befehl dann am Ende aussehen könnte:
sudo /etc/init.d/php5-fpm restartsudo /etc/init.d/php7.0-fpm restart
Ganz am Ende nun nochmal ein Gesamt-Update. Sicher ist sicher. Und ein restart des nginx. Restart diesmal mit dem service-Befehl, damit du beide Varianten (service und init.d) in Aktion siehst.
sudo apt-get update
sudo apt-get upgrade
sudo service nginx restart
Nginx einrichten
Üblicherweise ist das web root Verzeichnis
/var/www
oder neuerdings
/var/www/html
nginx kocht da standardmäßig aber ein eigenes Süppchen. Früher war es anscheinend unter
/usr/share/nginx/www
Seit ich jedoch mit nginx unterm Raspi arbeite war es unter
/usr/share/nginx/html
Nun, egal wo es nginx aktuell als default auch hat. Wir werden es so einstellen, daß wir das allgemein übliche einstellen und nutzen. Wenn apache (oder ein anderer Webserver) nicht eingerichtet war, wird es das /var/www/html noch nicht geben. Wir erstellen es, falls erforderlich mit:
mkdir /var/www/html
Wenn es schon existierte, gibt's die Meldung, daß es schon existiert. So oder so, wir haben, was wir wollten.
Wenn das Verzeichnis bereits existierte, wird's wohl auch eine defaultmäßige index-Datei geben. Schau mal nach was da ist mit
ls
sudo rm -rf /var/www/html/{*,.*}
Die Fehlermeldungen bzgl. "." und ".." kannst du ignorieren.
Erstelle nun die index.php und füge Testcode ein, damit wir unsere Konfiguration später testen können. Hier im Tutorial nutzen wir den nano Editor. Kennst du dich mit Linux besser aus, kannst du gernen deinen üblichen Workflow beibehalten und deinen Lieblingseditor verwenden. Hinweis: falls die Datei nicht existiert, brauchts du sie nicht erst neu anlegen. nano öffnet sie, wenn sie bereits existiert oder erstellt sie, falls nicht, um sie sofort anschließend zu öffnen.
sudo nano /var/www/html/index.php
Fülle die index.php mit obigem Code. Das phpinfo() reicht uns völlig aus. Wir brauchen lediglich irgendeine Ausgabe, egal welche, um bei unseren "gehts?"-Tests etwas zu sehen.
Speichern und schließen.
Wenn du wie oben vorgeschlagen nano als Editor nutzt: a) Strg-x zum schließen wollen, dann b) mit j die Änderungen-speichern-Nachfrage bestätigen und c) zuletzt mit Enter (ohne den Dateinamen zu ändern) speichern lassen. Hinweis für nano-Neulinge: Wenn nano läuft, eine Datei offen ist, siehst du unten eine oder mehrere Zeilen mit dem Menü. Das "^"-Zeichen - der accent circonflexe - steht symbolisch für die Strg-Taste. Dh. du siehst ein "^X" → das steht für die Tastenkombination Strg-x.
Du bist nun wieder ganz normal in der Shell und kannst Befehle eingeben.
Mit den Vorbereitungen sind wir soweit durch. Laß uns nginx nun konfigurieren.
sudo nano /etc/nginx/sites-available/default
Unser frisch installiertes nginx bringt folgende Default-Konfig mit:
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# http://wiki.nginx.org/Pitfalls
# http://wiki.nginx.org/QuickStart
# http://wiki.nginx.org/Configuration
#
# Generally, you will want to move this file somewhere, and start with a clean
# file but keep this around for reference. Or just disable in sites-enabled.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_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 the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php5-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# # With php5-fpm:
# fastcgi_pass unix:/var/run/php5-fpm.sock;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
Wir passen zuerst das Document Root an unsere Gegebenheiten an. Oben schrieben wir, daß es /var/www/html sein soll. Suche nach der Zeile, die mit "root" beginnt.
Zum Zeitpunkt des Tutorialerstellens sieht es bei mir so aus:
root /var/www/html;
D.h. es ist schon richtig eingestellt. Wir müssen nichts weiter tun, lassen es einfach so. Wenn du einen anderen Pfad hast, dann ändere es ab, daß es so aussieht:
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
Dieses index.nginx-debian.html am Ende löschen. Am Anfang ein index.php einfügen. Es sieht dann so aus:
# Add index.php to the list if you are using PHP
index index.php index.html index.htm;
D.h. du startest mit index, dann ein Blank, danach die gewünschten Index-Varianten jeweils mit Blank getrennt und ganz am Ende das Semikolon.
nginx weiß nun, daß auch index.php als Index-Datei gültig ist. Doch wir müssen dem Webserver noch php beibringen. Suche den vorgefertigten php-Teil. Sieht bei mir aktuell so aus:
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php5-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# # With php5-fpm:
# fastcgi_pass unix:/var/run/php5-fpm.sock;
#}
Hinweis: Beachte die letzte Codezeile. Wir haben PHP-FPM. Das werden wir auch nutzen und einstellen. Hier war PHP5 aktuell. Spätere Testdurchläufe des Tutorials hatte ich, als PHP7 aktuell war. Da sah die Zeile leicht anders aus: "fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;".
Ändere den vorgefertigten PHP-Abschnitt so ab:
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
location ~ ^(.+\.php)(.*)$ {
try_files $fastcgi_script_name =404;
fastcgi_split_path_info ^(.+\.php)(.*)$;
# include snippets/fastcgi-php.conf;
#
# # With php5-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# # With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include /etc/nginx/fastcgi_params;
}
Beachte die Zeile mit dem php5-fpm.sock. Du entfernst nur das Kommentarzeichen. Den Inhalt der Zeile wirst du nicht verändern. Dann die darunterliegenden Zeilen hinzufügen. Du hast natürlich auch die Möglichkeit im Netz zu suchen, ob du auf die schnelle etwas zu php(hier deine Versionsnummer) und nginx findest.
Zuletzt aktivieren wir noch das "Verbot" von .htaccess Dateien. Die default Konfig von nginx hat da schon was vorbereitet - einkommentiert. Wir müssen es nur noch auskommentieren. Grob gesagt geht es darum: Wir haben uns entschieden den allgemein üblichen Webroot auch für unsere Installation einzurichten. Diesen nutzen auch andere Webserver. Der Apache bspw. Falls sich nun .htaccess Dateien von Apache an diesem Ort befinden sollten: die sind für den Apache, nicht für den nginx. Unsere Surfer werden nun aber nicht mehr vom Apache, sondern vom nginx bedient. nginx weiß nicht, daß .htaccess Dateien etwas besonderes sind und würde sie wie normale Dateien behandeln und einfach anzeigen, wenn sie jemand von außen (über Browser etc.) aufruft. Aber auch der nginx soll dem von extern kommenden Surfer keinen Zugriff auf solche Konfigurationsdateien geben. Suche nach:
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
Lösche die Kommentarzeichen bei den drei betreffenden Zeilen. Ergebnis:
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny all;
}
Zwischen diesem eben geänderten "deny"-Abschnitt und den darüberliegenden php-Abschnitt fügen wir noch folgendes ein.
charset utf-8;
Insgesamt sieht es am Ende so aus:
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# http://wiki.nginx.org/Pitfalls
# http://wiki.nginx.org/QuickStart
# http://wiki.nginx.org/Configuration
#
# Generally, you will want to move this file somewhere, and start with a clean
# file but keep this around for reference. Or just disable in sites-enabled.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.php index.html index.htm;
server_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 the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
location ~ ^(.+\.php)(.*)$ {
try_files $fastcgi_script_name =404;
fastcgi_split_path_info ^(.+\.php)(.*)$;
# include snippets/fastcgi-php.conf;
#
# # With php5-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# # With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include /etc/nginx/fastcgi_params;
}
charset utf-8;
# a) deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
# b) deny access to baikal's sources and config
#
location ~ /\.ht {
deny all;
}
}
# Virtual Host configuration for example.com#
# You can move that to a different file under sites-available/ and symlink that# to sites-enabled/ to enable it.##server {# listen 80;# listen [::]:80;## server_name example.com;## root /var/www/example.com;# index index.html;## location / {# try_files $uri $uri/ =404;# }#}
Speichern und schließen.
Hatten wir eben gerade bei der index.php; aber nochmal zur Erinnerung: Wenn du wie oben vorgeschlagen nano als Editor nutzt: a) Strg-x zum schließen wollen, dann b) mit j die Änderungen-speichern-Nachfrage bestätigen und c) zuletzt mit Enter (ohne den Dateinamen zu ändern) speichern lassen. Hinweis für nano-Neulinge: Wenn nano läuft, eine Datei offen ist, siehst du unten eine oder mehrere Zeilen mit dem Menü. Das "^"-Zeichen - der accent circonflexe - steht symbolisch für die Strg-Taste. Dh. du siehst ein "^X" → das steht für die Tastenkombination Strg-x.
Du bist nun wieder ganz normal in der Shell und kannst Befehle eingeben.
Damit die Änderungen in Kraft treten, starten wir nginx neu.
sudo service nginx restart
Startet nginx nicht neu durch und erhälst du eine Fehlermeldung - bspw. die oben gezeigte "Job for nginx.service failed because the control process exited with error code." -, so hast du dich entweder vertippt oder bzgl. PHP hat sich mittlerweile so viel verändert, daß meine Beschreibung oben nicht mehr paßt. Mit "sudo nginx -t" kannst du die Syntax prüfen lassen; sehen ob du Vertipper hast. "Beliebte" Vertipper sind: vergessen die schließende geschweifte Klammer auszukommentieren (beim php-Teil). Öffnende und schließende Klammern müssen korrespondieren. Ein Semikolon am Ende vergessen. Alles auf einmal aus dem Browser in den nano per copy & paste kopiert? Evtl. hast du dadurch irgendwo zu viele Blanks oder Blanks an der falschen Stelle oder Windows-Linux-Umsetzungsprobleme, wenn dein Arbeits-PC eine Windowskiste ist. Hat sich PHP so verändert, daß eine der Änderungen zu Fehlern führt: unmöglich hier Jahre in die Zukunft zu schauen und zukünftige Änderungen vorwegnehmen zu können. Wenn du Tippfehler gesucht hast und ausschließen kannst, so fange an einen Teil der Änderungen wieder einzukommentieren. Also ein "#" an den Zeilenanfang zu setzen, um die betreffende Zeile wieder zu deaktivieren. Speichern, schließen und wieder ein "sudo service nginx restart". Bis du den Fehler gefunden hast. Traust du dir zu, die Fehlerlogs lesen zu können, befolge aus der Fehlermeldung das mit dem "See systemctl status nginx.service usw.", um die Logs einzusehen.
Nachtrag: bei einem Testdurchlauf hatte ich den Fall, daß der Restart nicht wollte, weil Port 80 bereits belegt war. Mit "sudo netstat -nlp" sah ich, daß apache2 den Port belegt. Den haben wir doch gelöscht!? Nach einem "sudo apt-get purge apache2" gings dann. Keine Ahnung, ob ich das löschen vorher versehentlich übersprungen habe, oder ob apache2 aufgrund irgendwelcher Abhängigkeiten oben beim Punkt "Module installieren" wieder ins System gekommen ist.
Startet nginx normal durch: Wir sind soweit fertig; der Webserver ist fertig eingerichtet.
Wir testen das jetzt direkt mal, indem wir per Browser auf den nginx unseres Raspi zugreifen.
Wenn du vom Vortutorial "Raspberry Pi installieren" kommst, hast du dir bereits unter anderem die IP-Adresse notiert. Wenn nicht: du bist noch in der Shell, kannst dir also direkt mit ifconfig die Netzwerkeinstellungen anzeigen lassen. Tippe in der Shell ein:
ifconfig
Du erhältst Angaben in der Art:
eth0 ist das Lan (also per Kabel) und wlan0 die Wlan-Verbindung. Du wirst nur eine der beiden Angaben haben - je nachdem wie du den Pi verbunden hast. Die Bezeichner können sich in der Zwischenzeit geändert haben. Im Screenshot siehst du kein eth0 fürs Lan, sondern da ist es dieses enxb827ebf4cb53. Wenn du dich nicht bereits gut mit Linux auskennst bzw. regelmäßig mit ifconfig arbeitest, wirst du mitdenken müssen, um die richtige Zeile zu finden.
Wir notieren uns auch gleich die MAC-Adressen - das ist die Angabe "Hardware Adresse". Auch hier änhlich wie eben: mittlerweile kann sich der Bezeichner geändert haben. Es könnte auch "HWaddr" sein oder wie in unserem Screenshot die jeweilige "ether"-Zeile. Das ether unter wlan0 ist die MAC-Adresse des Wlan-Adapters; das ether im Abschnitt dieses langen en-irgendwas (enxb827ebf4cb53) die MAC-Adresse des Lanports (Kabel).
Du hast nun also drei Angaben in der Art
mac-lan: ab:12:cd:34:ef:56
mac-wlan: a1:b2:c3:d4:e5:f6
ip: 192.168.2.171
Wenn du noch auf dem Raspi selbst bist. D.h. dort im Desktop. Kannst du den Browser dort starten und nginx "lokal" ansprechen.
http://localhost/
Von deinem Arbeitsplatzrechner aus steuerst du die IP-Adresse an.
http://<ip-adresse>
Beispiel von oben: http://192.168.2.171
Hast du wie oben vorgeschlagen die index.php mit einem Inhalt mit etwas wie phpinfo() angelegt, so solltest du im Browser etwas in der folgenden Art angezeigt bekommen.
Screenshot oben: von einem anderen PC aus über die IP-Adresse; unten: direkt auf dem Pi mit localhost.
Hat das funktioniert, weißt du, daß a) nginx funktioniert, b) unsere Standardkonfig (webroot, etc.) funktioniert, c) php funktioniert und d) nginx php richtig "verarbeitet".
Hier ist dein erster Ausstiegspunkt. Nachfolgend richten wir SSL und danach den Zugriff für von außen übers Internet ein. Das kannst du gerne überspringen. Wenn du bspw. beim CalDAV-Tutorial nicht dein(e) Smartphone(s) anbinden willst, sondern nur Thunderbird und dich immer im lokalen Netz bei dir zu Hause bewegen wirst. Oder wenn du die Anleitung nun zum dritten mal from scratch durchmachts, aber das mit den Zertifikate-einbinden einfach nicht funktionieren mag. Wenn du aber deine "last version for going productive" angehst und vorallem, wenn du von außen zugreifen willst: nutze SSL.
SSL
Wir richten nun SSL ein, damit du deine Daten nicht unverschlüsselt übers Netz schickst. Nachfolgend erst die notwendigen Befehle. Es ist teilweise etwas mehr oder weniger Erklärung nötig. Die schließt sich direkt an. Ich wollte aber die Befehle nicht "auseinanderreißen", sondern kompakt an einer Stelle haben. Deshalb diese Reihenfolge.
sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -out sslcert.key 4096
sudo openssl req -new -sha256 -key sslcert.key -out sslcert.csr
sudo openssl x509 -req -sha256 -days 3650 -in sslcert.csr -signkey sslcert.key -out sslcert.crt
SSL ist ein eigenes großes Thema. Hier ist nicht der Platz, tief in dieses Thema einzusteigen. Hier nur kurz angerissen, was du zum "schnellen" Verständnis brauchst.
openssl ist das Programm/Script mit dem du die Schlüssel und Zertifikate erstellst und bearbeitest.
Beim dritten Befehl (genrsa) kannst du statt 4096 auch 2048 nehmen. Du findest im Netz reichlich Diskussionen darüber. Die einen argumentieren, daß ein Punkt der Sicherheit ist, dem Zertifikat keine unendliche Laufzeit zu geben. Deshalb braucht man keine 4k-Bit, da auch die 2k-Bit in absehbarer Zeit nicht zu knacken sind. Wenn das Zertifikat eine Laufzeit hat, wird es ungültig, bevor es knackbar wäre. 4k würden beim entschlüsseln/etc. nur unnötig mehr Leistung abverlangen, was sich bereits (hier kommen dann meist Beispiele) spürbar zeigen würde. Andere argumentieren (hier dann mit anderen Beispielen), daß die Performance der aktuellen Hardware reicht, um 4K zu entschlüsseln, ohne daß es einen für Endanwender spürbaren Unterscheid zu 2K macht - und Hardware eh immer leistungsfähiger wird. Wenns dich interessiert, lies dich ein und entscheide dann selbst, ob du mit 4096 oder 2048 Länge verschlüsselst.
Den Namen sslcert der generierten Dateien - sslcert.key, sslcert.csr, sslcert.crt - habe ich frei "erfunden". Dh. du kannst nehmen, was dir gefällt. Das kann baikal.crt sein oder caldav.crt oder kalenderserver.crt, deinfirmenname.crt, derdomainname.crt, derprojektname.crt, usw. usw. Du mußt nur später wissen, wie du die Dateien benannt hast und in diesem - und dem Tutorial von dem du hierher gekommen bist -, entspr. die Beispielnamen durch die Namen deiner Zertifikatsdateien ersetzen.
Den fünften und letzten Befehl (das mit dem openssl x509 usw.) ziehe ich kurz vor. Dort hast du einen Teil "-days 3650". Hier legst du fest, wie lange - in Tagen - das Zertifikat gültig sein soll. Geh ins Netz und lies dir dort die Pro und Kontra für ein lang oder kurz gültiges Zertifikat. Ich halte mich hier aus der Diskussion heraus.
Beim vierten Befehl (sudo openssl req -new ... usw) wirst du Eingaben tätigen müssen. Die meisten Eingaben sind beliebig. Lediglich das eintragen der "richtigen" Domain ist wichtig - sonst funktioniert es nicht bzw. nicht richtig oder fehlerfrei. Das Programm (Browser, etc.), das das Zertifikat prüft, wird es ablehnen, da der Ort, wofür es ausgestellt wurde, nicht stimmt. In manchen Fällen wird das Programm (bspw. Microsoft-Browser) den Zugriff ganz verweigern. In anderen Fällen (bspw. Firefox) wirst du Fehlermeldungen erhalten und Ausnahmen eintragen müssen. Wir wollten in SSL nicht tiefer einsteigen, aber hier sind vrmtl. doch ein paar mehr Infos erforderlich - und am anschaulichsten natürlich mit Screenshots.
Bei "common name" trägst du gleich den richtigen Wert ein. Das ist eine Domain (oder Subdomain), eine IP-Adresse oder der Hostname. Oben im Screenshot habe ich die Subdomain "dav.example.com" eingetragen. Das wäre eine Eingabe für unser CalDAV-Server Tutorial. Den wollen wir nicht direkt über unsere Domain ansprechen, sondern richten dafür beim Provider eine Subdomain ein, die wir dann zu uns nach Hause umleiten. Wenn wir das Glück einer festen IP daheim haben :-) Du kannst aber bspw. auch die eigentliche Domain "example.com" eintragen. Also ohne Subdomain. Beispiel wäre ein zu Hause gehostetes CMS. Die eigenen Wordpress-Seite möchte man meist nicht in der Subdomain, sondern auf "oberster" Ebene haben.
Die anderen Punkte sind eigentlich beliebig. Wenn du magst, trägst du was ein. Wenn nicht, dann nicht. Beachte lediglich, daß Defaultwerte eingetragen werden könnten, wenn du bei einer Eingabe nichts einträgst; dh. einfach nur Enter drückst. Siehe im Screenshot meine Angabe zu "State or Province Name". Da habe ich einen Punkt "." eingetragen. Sonst wäre der Default "Some-State" eingetragen worden. Die Defaults sind diese Angaben in den eckigen Klammern.
Beispiel mit fester IP. Alle anderen Angaben leer (beachte: Punkt wo nötig).
Und noch ein letztes Beispiel. Diesmal mit unserem Hostnamen "RASPI03" als common name. Da die anderen Felder beliebig sind, habe ich sie hier mal zweckentfremdet. In Tagen aufkommender IoT im Eigenheim, habe ich hier mal die "Position" des DLNA-Servers "hineincodiert". Die IP-Adresse wollte ich nicht eintragen. Der Raspi ersetzt die bisher dafür genutzte NAS. So kann ich beide nach Belieben tauschen, ohne die Zertifikate umhertauschen zu müssen. Du hast insoweit recht, daß ich dann so etwas wie DLNASERVER als Hostnamen hätte nehmen können. Aber um in den Tutorials kohärent zu bleiben, blieb ich beim in den Tutorials genutzten Hostnamen :-) Du siehst: wann du was als common name nimmst, hängt von deinem Anwendungsfall ab.
Falls du die "sudo openssl"-Befehle von oben noch nicht ausgeführt hast, tue das jetzt. Als common name nimmst du am besten:
a) Wenn du das Tutorial das erstmal durcharbeitest: die IP-Adresse. Wenn du auch gleich mit externer Domain arbeiten willst, wirst du zwar nachher das Zertifikat nochmal neu mit Domain erstellen müssen. Aber mit jetzt an dieser Stelle erstmal IP, bleibst du im didaktischen Fluß des Tutorials.
b) Wenn du das Turial wiederholst, oder sicher weißt, daß du keine Wiederholung brauchst oder Zertifikate dich vor keine Herausforderung stellen und du jetzt schon weißt, daß du eine externe Domain nutzen willst: stelle gleich die Domain ein. Dann sparst du dir, später ein neues Zertifikat mit Domain anstatt IP erstellen und neu einbinden zu müssen.
In einigen Quellen im Netz die OpenSSL betrachten, bin ich immer wieder darauf gestoßen, daß die nach dem Erstellen des Zertifikates chown und chmod ausführen. Zusammenfassend und auf unser Tutorial übersetzt ergeben sich mehrere Varianten.
Variante 1:
sudo chown -R www-data:www-data /etc/nginx/ssl
sudo chmod 600 /etc/nginx/ssl/sslcert.csr
sudo chmod 600 /etc/nginx/ssl/sslcert.key
Vaiante 2:
sudo chmod 600 /etc/nginx/ssl/*
Und Kombinationen aus Variante 1 und 2.
Dh. manche ändern den Besitzer mit chown auf den www-data und geben ausschließlich www-data Zugriff, dh. verweigern den Zugriff für alle anderen. Manche führen nur den chmod aus, lassen den chown weg - dh. ändern den Besitzer nicht, sondern kümmern sich nur um den Zugriffsschutz. Bei der Zugriffsverweigerung achten manche darauf, nicht die crt-Datei zu verweigern und andere gehen mit "*" in Rasenmähermanier unterschiedslos über alles hinweg.
So ganz erschließt es sich mir nicht. Wir kümmern uns um SSL, haben also ein Bewußtsein für Sicherheit. Da klingt das mit dem chmod (Zugriffsschutz) erstmal plausibel. Andererseits: die Dateien sind doch an einer Stelle, an die niemand von außen ran kommt. Das Webroot befindet sich doch an ganz anderer Stelle. Und: in den Fällen mit dem "*": da wird doch auch die crt-Datei mit Zugriffsschutz belegt. Aber die crt-Datei will ich doch weitergeben. Alle Geräte, von denen aus ich zugreifen will, müssen diese Datei doch einbinden. Wieso schütze ich eine Datei vor Zugriff, auf die ich öffentlichen Zugriff haben will? Das chown (Besitzwechsel) könnte ich noch einsehen, da evtl. der Webserver sonst nicht rankommt. Ich habs aber selbst nicht ausgeführt - also den Befehl mit dem chown nicht eingetippt - und es hat wunderbar funktioniert. Evtl. betrifft das aber auch garnicht den nginx, sondern ist eher ein Apache-Phänomen und ich habs im überfliegen nicht herausgelesen.
Nun, ich habe jedenfalls dieses ganze chown/chmod bei meinen Tests ausgelassen, hab diese Befehle nicht ausgeführt. Ich führe es hier aber auf, da ich meinerseits immer Verständnisfehler und ein "bist halt noch nicht ganz so toll drinne in der Materie" gelten lasse. Falls ich es nur noch nicht ganz durchschaut habe, so hast du trotzdem die nötigen Befehle gesehen und kannst anwenden, was du davon für richtig hältst.
Laß uns aber nun weiter gehen. Nächster Schritt: nginx-Konfiguration anpassen. Damit nginx die Zertifikate nutzt, ausliefert.
sudo nano /etc/nginx/sites-available/default
Suche den SSL-Teil:
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
Ändere das in:
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/ssl/sslcert.crt;
ssl_certificate_key /etc/nginx/ssl/sslcert.key;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
Was haben wir gemacht? SSL aktiviert, indem wir die einkommentierten ersten beiden Zeilen auskommentiert haben. Und wir haben unser (direkt davor) selbst erstelltes Zertifikat eingebunden mit den beiden ssl_certificate und ssl_certificate_key Zeilen.
Damit die Änderungen wirksam werden:
sudo service nginx restart
Die sslcert.crt müssen wir nun überall dort (als vertrauenswürdig) einbinden, von wo aus wir auf unseren Webserver - bzw. das dort laufende Projekt natürlich :-) - zugreifen wollen.
Beachte: es ist nur die crt-Datei. Nicht eine der anderen. Die sslcert.key bspw. gibst du unter keinen Umständen weiter. Du verteilst immer nur die crt-Datei. Und nur diese eine, keine anderen.
Lets go test :-)
Von deinem Arbeitsplatzrechner aus steuerst du die IP-Adresse an. Diesmal über SSL, dh. mit https.
https://<ip-adresse>
Mit unserem Tutorial-Beispiel: https://192.168.2.171
Beachte das "s" beim https.
Du wirst im Browser ersteinmal mit einer Fehlermeldung beglückt. Der Firefox meldet "Diese Verbindung ist nicht sicher". Beim Internet Explorer heißts "Es besteht ein Problem mit dem Sicherheitszertifikat der Website". Chrome, Safari und die anderen werden es ähnlich nennen.
Den Hintergrund werde ich nur kurz skizzieren. Wenn du mehr darüber wissen willst, findest du im Netz viele Infos dazu. Eine Certification Authority (auf deutsch: Zertifizierungsstelle) ist der/die/das, der das Zertifikat ausgestellt/erstellt hat. Es gibt große Organisationen (kommerzielle wie nicht kommerzielle, staatliche, etc.) bei denen man sagt: "Wenn das Zertifikat von denen kommt, vertrauen wir darauf, daß es seine Richtigkeit hat." Es gibt eine Liste und da sind alle "vertrauenswürdigen" eingetragen. Mozilla hat eine eigene Liste, die der Firefox nutzt. Microsoft hat eine eigene Liste, die in Windows und den Microsoft-Programmen genutzt werden (Internet-Explorer, vrmtl. auch irgendwas bei den Servern, evtl. auch der Exchange, usw.). Google, Apple, usw. usw. - informier dich selbst, wenns dir wichtig ist zu wissen. Nun, wir, dh. du und ich, sind aber lediglich jemand aus der anonymen Masse. Hinz und Kunz werden nicht autom. als vertrauenswürdig eingestuft.
Zurück zu unserem Tutorial.
Du wirst eine der beiden folgenden Fehlermeldungen erhalten - am Beispiel Firefox; die anderen Browser analog.
Klicke auf den Button "Erweitert", um die ganze Meldung zu sehen.
Wenn du beim Erstellen des Zertifikates (siehe weiter oben, da haben wir es erstellt) die IP-Adresse angegeben hast, erhälst du "<ip-adresse> verwendet ein ungültiges Sicherheitszertifikat. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde." Dh. wir sind Hinz und Kunz und keine "vertrauenswürdige" Zertifizierungsstelle.
Hast du gleich die Domain anstatt der IP eingetragen, gibts zusätzlich noch die Anmerkung "Das Zertifikat gilt nicht für den Namen <ip-adresse>." Das ist ok. Das Zertifikat haben wir im Namen unserer Domain erstellt, greifen aktuell aber über die lokale IP zu.
Klicke unten rechts auf "Ausnahme hinzufügen".
Entferne den Haken bei "Diese Ausnahme dauerhaft speichern". Es ist nur ein kleiner, kurzer, schneller Zwischentest. Wir werden im weiteren Verlauf des Tutorials das Zertifikat "richtig" einbinden. Wenn wir dann Testen, ob das Einbinden des Zertfikates geklappt hat, könnten wir nicht unterscheiden, obs wegen dem Zertifikat oder wegen der Ausnahmeregel ohne Fehlermeldung geht. Also: Ausnahmeregel _nicht_ dauerhaft speichern!
Noch ein Test. Auch das muß funktionieren:
http://<ip-adresse>
Im Tutorial-Beispiel: http://192.168.2.171
Beachte: jetzt http ohne das "s".
D.h. sowohl https als auch http müssen funktionieren.
Beim Internetexplorer wählst du "Laden dieser Website fortsetzen (nicht empfohlen)." Chrome, Safari und bei anderen Browsern wirds ähnlich sein.
Nächster Schritt, ist es, http zu "verbieten". Der Zugriff soll grundsätzlich nur verschlüsselt erfolgen können. Auch sollen wir nicht versehentlich einen unverschlüsselten Zugriff von einem Gerät oder Smartphone einstellen können. Unsere Lösung: alle http Zugriffe leiten wir automatisch auf https um.
Zwei Beispiele zur Veranschaulichung.
Nehmen wir an, du kommst vom CMS mit WordPress Tutorial. Dann hieße das: aus http://blog.example.com/<kategorie>/<beitrag>…usw
soll automatisch werden https://blog.example.com/<kategorie>/<beitrag>…usw
http://<irgendwas> soll gar nicht möglich sein.
Das hat auch den positiven "Nebeneffekt", daß wir auch das WordPress-Dashboard (die Admin-Oberfläche) immer nur über https erreichen und somit immer alles verschlüsselt ist.
Nehmen wir an, du kommst vom Raspberry Pi als CalDav-Server Tutorial. Dann hieße das: aus http://mysubdomain.example.com/cal.php/<user>/<calender>…usw
soll automatisch werden https://mysubdomain.example.com/cal.php/<user>/<calender>…usw
http://<irgendwas> soll gar nicht möglich sein.
Das hat auch den positiven "Nebeneffekt", daß wir auch den CalDav-Server-Admin immer nur über https erreichen und somit immer alles verschlüsselt ist.
Du hast es verstanden. Lass es uns nun einrichten. Im Terminal (dh. putty bzw. das Tool das du dafür nutzt) gebe ein:
sudo nano /etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/ssl/sslcert.crt;
ssl_certificate_key /etc/nginx/ssl/sslcert.key;
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name 192.168.2.171;
rewrite ^ https://$server_name$request_uri? permanent; # enforce https
}
server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
server_name 192.168.2.171;
ssl_certificate /etc/nginx/ssl/sslcert.crt;
ssl_certificate_key /etc/nginx/ssl/sslcert.key;
Beachte: Die IP-Adresse ersetzt du durch deine IP-Adresse. Es sind zwei Stellen.
nginx neu durchstarten, damit es wirksam wird.
sudo service nginx restart
Testen:
https://<ip-adresse>
Tutorial-Beispiel: https://192.168.2.171
→ muß funktionieren (abgesehen von der Meldung bezüglich dem Zertifikat, siehe oben; beachte auch wieder, daß du die Ausnahmeregel fürs Zertifikat zwar zuläßt, falls du entspr. Meldung bekommst, aber _nicht_ dauerhaft speicherst)
http://<ip-adresse>/index.php
Tutorial-Beispiel: http://192.168.2.171
also ohne das "s" bei http
→ muß automatisch umgeleitet haben auf: https://<ip-adresse>/index.php
also mit "s" bei http
(Beachte wieder: das mit dem Zertifikat zulassen, aber nicht dauerhaft speichern, falls entspr. Meldung kommt)
Einschub. Wenn du "kurzfristig" diese Autoumleitung auf https "ausschalten" willst. Bspw. wenn dein Browser oder dein Handy etc. nicht zugreifen kann und du testen willst, obs nicht evtl. nur daran liegt, daß du bei dem betreffenden Gerät das Zertifikat nicht oder nicht richtig eingebunden bekommen hast.
sudo nano /etc/nginx/sites-available/default
Bitte 4 Zeilen einkommentieren. Sieht wie nachfolgend aus. Vergleiche es mit direkt oberhalb im Text. Es ist bei 4 Zeilen das Kommentarzeichen # an den Anfang gesetzt.
server {
listen 80 default_server;
listen [::]:80 default_server;
# server_name 192.168.2.171;
# rewrite ^ https://$server_name$request_uri? permanent; # enforce https
#}
#server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
Jetzt kannst du wieder sowohl über http als auch über https zugreifen.
Mache die 4 Kommentarzeichen wieder weg, d.h. die 4 Zeilen wieder auskommentieren, und die "Autoumleitung" ist wieder aktiv.
Das kannst du nutzen, wenn du irgendwas "testen" mußt. Evtl. irgendwo einen Fehler hast und mutmaßt, es könnte an diesem ganzen Zertifikatekram liegen. Usw. Wozu du es halt brauchst. Vergiß am Ende der Tests aber nie, die Autoumleitung wieder zu aktiveren. Wir haben das ja nicht umsonst so eingestellt.
Ende Einschub.
Von außen per Domain zugreifen können
Du tust drei Dinge: nginx Konfig anpassen, bei deinem Provider die Domain auf deine IP umbiegen oder einen DynDNS-Dienst nutzen, deinen Router so konfigurieren, daß die Anfragen bei deinem Raspi ankommen. Die Punkte Provider und Router behandle ich hier nur kurz mit recht allgemeinen Sätzen. Das Thema ist mir hier zu groß; zu viele Provider, zu viele Router.
Zuerst passen wir die Konfig des nginx an.
sudo nano /etc/nginx/sites-available/default
Suche nach:
server_name 192.168.2.171;
Ersetze durch:
server_name mysubdomain.example.com;
Es sind zwei Stellen.
mysubdomain.example.com ist dabei deine Subdomain oder die betreffende DynDNS-Domain usw.
In deinem Router gibst du nun die Ports 80 und 443 frei und leitest sie auf die IP deines Raspi. In unserem Beispiel wäre es die: 192.168.2.171
PS.: Da du gerade im Router bist: Du könntest die Mac-Adresse des Raspi mit der gewünschten IP-Adresse einstellen. Was sinnvoll ist, hängt von deiner konkreten Situation ab. Ich wollts lediglich erwähnt haben; nur so als Idee.
Wenn du eine eigene Subdomain hast: Gehe nun zu deinem Provider, dort wo du deine Website und Domain hast. Erstelle dort eine Subdomain. Diese Subdomain stellst du so ein, daß sie nicht auf deinen Webspace zeigt, sondern auf eine externe IP. MX-Einträge (betrifft Emails etc.) biegst du nicht um. Nur die IP-Adresse (A-Record) der Subdomain. Wenn du deine (feste) externe IP nicht kennst, nutze einen dieser WieIstMeineIP-Dienste im Internet, um dir deine aktuelle externe IP anzeigen zu lassen.
Bei DynDNS: brauchst eigentlich nichts weiter tun. Wenn du beim DynDNS-Anbieter alles richtig eingerichtet hast, zeigt deine DynDNS-Adresse bereits zu dir nach Hause.
Testen:
https://mysubdomain.example.com
→ sollte die phpinfo-Seite anzeigen, wie bei den obigen Tests
http://mysubdomain.example.com
→ sollte auf die https umleiten
Zertifikate in Windows/Linux/Android/iOs/etc. einbinden
Das Einbinden des Zertifikates ist eine so allgemeine Kiste, daß ich es in einem eigenen Tutorial behandeln werde. Außerdem paßt es mir auch nicht wirklich in dieses Tutorial. Der Webserver ansich ist kein Ergebnis. Du wirst immer eine Anwendung haben, für die du den Webserver aufsetzt. Dh. hierher gelangst du immer von einem anderen Vortutorial aus. Weitere ellenlange Beschreibungen fürs Einbinden von SSL-Zertifikaten paßt mir hier nicht in den didaktischen Fluß. Das Webserver-Tutorial ist schon lang genug.
Das heißt: TODO: besagtes Tutorial erstellen und hier lediglich darauf verlinken.
Aufräumen, Abschlussarbeiten
Zuletzt "säubern" wir noch unser Rootverzeichnis.cd /var/www/html
sudo rm index.php
ls
→ sollte jetzt leer sein. Falls nicht: auch die anderen Dateien löschen. PS.: "Gesunden Menschenverstand" nicht ausschalten. Wenn - warum auch immer - sich in der Zwischenzeit seit Erstellen dieses Tutorials im "Standardverhalten" irgendwas dahingehend geändert hat, daß irgendeine Datei sich nun neu ebenfalls in /var/www/html befindet und warum auch immer nicht gelöscht werden darf, so wirst du das selbst erkennen müssen. Oder zumindest auf die Idee kommen "Im Tut steht zwar ich soll alles löschen. Da ist jetzt aber diese komische Datei. Vielleicht schaue ich doch lieber mal im Internet nach." Wenn es mittlerweile so etwas geben sollte: schreib mir eine kurze Mail, damit ich das Tutorial anpassen kann. Danke.
Unser Webserver ist nun komplett eingerichtet und alles ist eingestellt. Der Raspi läuft, nginx läuft, php ist verfügbar, SSL funktioniert und wir haben sichergestellt, daß alle Anfragen verschlüsselt werden, auch die unverschlüsselten autom. ins verschlüsselte umgeleitet werden. Jetzt kannst du dich dem Vortutorial, deiner eigentlichen Aufgabestellung widmen. Wenn dabei Fehler auftreten, dein CMS oder CalDav-Server oder was du auch vor hast, nicht läuft, sich nicht aufrufen läßt, etc., so wissen wir zumindest, daß es nicht an unserem Webserver liegen kann und auch nicht an den Zertifiakten und SSL. Mit unseren letzten Tests haben wir gesehen, daß das zumindest alles richtig eingestellt ist und läuft.
Mit der Installation und Konfiguration bist du fertig und kannst nun deinen Raspi in den Netzwerkschrank stellen oder an die Wand schrauben - verräumen, wegräumen.
