Der richtige Weg ist aber natürlich ein Anderer.
Die eigene Homepage
Was NGINX wissen muss
Bevor es an die Gestaltung einer Homepage geht, muss NGINX erst mal erklärt werden,
worauf er hören soll, wo er die auszuliefernden Daten findet und was er damit anfangen soll.
Die Konfiguration erfolgt im Grundsatz in der Datei
/etc/nginx/nginx.conf
, die aber unverändert bleiben sollte, solange kein trifftiger Grund dafür besteht.
Wichtig darin ist die Zeile:
http {
[...]
include /etc/nginx/sites-enabled/*;
[...]
}
In diesem Verzeichnis sollten wiederum nur Verweise auf die config-Daten liegen.
Für die eigentlichen Dateien wurde bei der Installation von NGINX das Verzeichnis
/etc/nginx/sites-available/
angelegt.
Hier kann man sich mit Konfigurationen austoben, Backups anlegen, etc.
Verknüpft nach /etc/nginx/sites-enabled/ werden nur die jeweils aktuellen Versionen.
Für alle Dateien in diesen Verzeichnissen sollte nur der User
root Schreibrechte besitzen.
NGINX läuft mit den Rechten des Users www-data, der die Dateien lesen,
aber keinesfalls ändern darf.
Konfiguriert werden sogenannte virtuelle Server, z.B.
server {
listen 80;
server_name raspi 192.168.0.105;
root /var/www/myhomepage;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Datei anlegen und Server-Konfiguration eintragen
sudo nano /etc/nginx/sites-available/homepage
Symbolischen Link zum neuen Server anlegen
sudo ln -s /etc/nginx/sites-available/homepage /etc/nginx/sites-enabled/homepage
NGINX-Konfiguration neu einlesen
Bei der Installation von nginx wurde bereits der virtuelle Server
default eingerichtet.
Dorthin werden alle Verbindungsversuche mit unbekanntem URL umgeleitet,
die den Server aus aus irgendeinem Grund erreicht haben.
Dieser Eintrag sollte bestehen bleiben.
Inhalt der Website
Per Konfiguration erwartet NGINX die Daten der Homepage in der Datei
/var/www/homepage/index.html.
Diese Datei muss natürlich angelegt und gefüllt werden.
Beispielgrundgerüste in html5 sind im Internet zuhauf zu finden. Bspw. kann
diese Datei
kopiert und als index.html auf dem PC gespeichert werden.
Auf dem Pi das Webroot-Verzeichnis anlegen und dem User pi zuordnen.
sudo mkdir /var/www/myhome
sudo chown -R pi:pi /var/www/myhome
Damit ist sichergestellt, dass
pi
Daten hochladen darf, aber
www-data
keine Dateien manipulieren kann.
Erst wenn Daten über den Server geschrieben werden sollen, müssen die Rechte von Dateien oder
Verzeichnissen angepasst werden.
Hochladen der Beispielwebseite vom PC:
rsync -a ./index.html pi@raspi:/var/www/myhome
... und im Browser testen
http://raspi
http://192.168.0.105
Die Seiten von
Selfhtml
sind eine gute Ausgangsbasis für eigene Experimente.
Der Weg nach Draußen
Wer kennt das nicht.
Man sitzt wochenlang in aufopferungsvoller Arbeit vor dem Rechner, hat endlich seine Webseite
zum Laufen bekommen, aber die Anerkennung im lokalen Netzwerk bleibt versagt.
Was liegt also näher, als seine Erfahrungen mit Leuten zu teilen, die die Mühe zu schätzen wissen.
Ein Server im privaten Umfeld wird i.A. hinter einem Router betrieben, der über eine DSL-Leitung
zum Internetprovider verbunden ist.
Um den externen Zugriff auf die bereitgestellten Dienste des Raspberry zu ermöglichen,
sind in dieser Konfiguration einige Hürden zu überwinden.
- die Paketzustellung durch den Router
- die Adresse im Internet (IP - Adresse)
- der Name im Internet (Domain-Name)
- Sicherheitsbedenken über Board werfen
1. Der Router
Der Router regelt die Kommunikation zwischen den Rechnern des lokalen und des öffentlichen Netzwerkes.
Per default sollten nur Datenpakete aus dem Internet nach Innen passieren dürfen, die erwartet werden
und eindeutig zuordenbar sind. Diese Bedingung ist erfüllt, wenn eine Verbindung von Innen (Client)
initiiert und von Außen (Server) beantwortet wird.
Verbindungsversuche zu einem Server im LAN wird der Router blockieren, zumal er ohnehin nicht wüsste,
an welchen der Rechner er die Anfrage weiterleiten soll.
Um Verbindungsanfragen aus dem Internet zu ermöglichen, muss im Router das Port-Forwarding eingerichtet werden.
Anfragen aus dem öffentlichen Netz wird der Router dann an einen bestimmten Rechner im LAN auf dem zugewiesenen
Port weiterleiten.
Für den Betrieb eines Webservers müssen i.d.R. der Port 80 (http) und der Port 443 (https) freigegeben werden.
Zwingend erforderlich ist dafür der administrative Zugriff auf den Router.
An dieser Stelle sollte man sich bewusst sein, dass damit ein wichtiger Sicherheitsmechanismus für das
lokale Netzwerk aufgegeben wird.
Im Internet ist zuhauf Gelichter auf der Suche nach angreifbaren Diensten unterwegs.
Sollte es bspw. jemandem gelingen, den Server als Verteiler für illegale Inhalte zu kapern,
könnte dies für den Betreiber strafrechtliche Konsequenzen nach sich ziehen.
Daher muss man sich erst mit dem Thema Serversicherheit beschäftigen, bevor man Löcher in seinen Router bohrt.
Die Funktion, die der Router beim Weiterleiten der Datenpakete in beiden Richtungen ausführt, wird als NAT
(Network Adress Translation)
bezeichnet.
Er manipuliert dabei die Adressfelder und ersetzt die öffentliche mit der privaten Adresse und umgekehrt.
Solange Zugriff auf die Routereinstellungen besteht und Port Forwarding möglich ist, stellt dies kein Problem dar.
Allerdings gibt es Provider, die ihrerseits ein NAT vorschalten und die öffentlichen Adressen in ihren
privaten Adressbereich übersetzen.
Ein Beispiel hierfür ist das Mobilfunknetz von Vodafone.
Andere Provider dürften Ähnliches praktizieren.
Der Betrieb eines Servers hinter einem solchen Anschluss ist nicht möglich.
Einfach testen lässt sich dies, indem die vom Provider zugewiesene
IP-Adresse
ermittelt und mit der im Router angezeigten öffentlichen Adresse verglichen wird.
Bei unterschiedlichen Werten hat man verloren.
Die Einrichtung des Port-Forwarding unterscheidet sich je nach Routermodell. Bei der Fritz!Box bspw:
→ Internet → Freigaben → Portfreigaben → Neue Portfreigabe
Freizugeben sind die Ports 80 und 443.
Bei Bedarf kann auch Port 22 für die Security Shell über das Internet geöffnet werden.
Es ist allerdings erstaunlich, wie viele Angriffe auf diesen Port durch o.g. Gelichter täglich gefahren werden,
um Zugriff auf den Server zu erlangen.
Einen Überblick dazu verschafft das Logfile
/var/log/auth.log.
Um dem Gesindel die Arbeit etwas zu erschweren, lässt sich der ssh-Dienst auf einen
anderen Port
umlegen.
Wenn die Portfreigaben funktionieren, sollte der Server jetzt via
http://öffentliche IP-Adresse
2. Die IP-Adresse
Die Erreichbarkeit von Rechnern im Netzwerk wird über IP-Adressen geregelt.
Der Service-Provider weist dem eigenen Router bei der Verbindungsaufnahme eine willkürliche Adresse aus
seinem IP-Pool zu.
DSL-Verbindungen werden zu allem Überfluss durch den Provider hin und wieder getrennt und neu verbunden.
Damit wird jedes mal eine neue IP-Adresse zugewiesen.
Vodafone trennt Verbindungen alle ein bis zehn Tage.
Die Häufigkeit scheint im Zusammenhang mit der übertragenen Datenmenge zu stehen.
Damit ist die Erreichbarkeit eines Servers über die IP-Adresse unpraktikabel.
Glücklicherweise werden Dienste im Internet i.A. ohnehin über einen Domainnamen angesprochen.
Die Zuordnung der variierenden IP-Adresse zu einer Domain übernehmen sogenannte DynDNS-Services.
Diese Dienste sind teilweise frei verfügbar, dann aber mehr oder weniger nervig oder aber kostenpflichtig.
Gut dran sind Betreiber einer Fritzbox.
Die Firma AVM stellt jedem Nutzer eines solchen Gerätes eine Subdomain wie
koezxnfnu5abcxyz.myfritz.net
kostenlos zur Verfügung und ordnet diesem Namen über den hauseigenen DynDNS die wechselnde IP-Adresse der Fritzbox zu.
Gedacht ist das Ganze natürlich nicht für Server-Experimente, sondern zur Erreichbarkeit des Routers für
Serviceeinstellungen über das Internet.
Eine Möglichkeit, auf die man aus Sicherheitsgründen tunlichst verzichten sollte.
Einfach ein MyFRITZ!-Konto einrichten – fertig.
Bis zur Einrichtung und Zuordnung im DNS kann einige Zeit vergehen.
Der Erfolg kann geprüft werden mit:
ping koezxnfnu5abcxyz.myfritz.net
Sobald diese Subdomain zur eigenen IP-Adresse aufgelöst wird, ist der Punkt geschafft.
Der Default-Server sollte jetzt erreichbar sein:
http://koezxnfnu5abcxyz.myfritz.net
An dieser Stelle könnte ein virtueller Server unter nginx mit dieser Subdomain
(server_name) eingerichtet werden und die Homepage wäre unter dieser Adresse erreichbar.
Für den privaten, internen Betrieb sicher völlig ausreichend, sodass man sich Punkt 3 sparen könnte.
An dieser Stelle sollte noch erwähnt werden, dass sich die Darstellung auf die Protokollversion IPv4 bezieht.
Unter IPv6 werden die Karten neu gemischt.
3. Der Name
Aber wer möchte schon jemandem zumuten, eine Adresse wie
http://koezxnfnu5abcxyz.myfritz.net
einzutippen.
Eine vernünftige Domain also muss her.
Nach Anschaffungs- und Stromkosten gehen die Experimente hier zum ersten mal wieder ins Geld.
Domain-Hoster gibt es auf dem Markt wie Sand am Meer.
Bei der Auswahl ist ein Blick in die Vertragsbedingungen geboten.
Wie lange binde ich mich? Wieviel kostet die Dienstleistung nach der Billigphase?
Technisch entscheidend ist die Möglichkeit, dass dieser Domain ein weiterer Domainname (der der FritzBox)
zugeordnet werden kann.
Im DNS ist dies über den
CNAME Resource Record
möglich.
Der Hoster muss einen entsprechenden Eintrag über seine Konfigurationseinstellungen zulassen.
Aufgrund anderer Verträge ist meine Wahl auf 1&1 gefallen.
Der eigentlichen Domain lässt sich zwar kein CNAME RR zuordnen.
Es ist aber möglich, beliebig viele Subdomains anzulegen, wie bspw.
www.mydomain.de.
Dieser Subdomain wird der CNAME RR
http://koezxnfnu5abcxyz.myfritz.net
der Fritzbox zugewiesen.
Die Domain
mydomain.de
selbst kann über die DNS-Konfiguration bei 1&1 auf die Subdomain umgeleitet werden,
sodass über diesen Umweg auch bei Eingabe von
der Pi-Server erreicht wird.
Allerdings ist auch hier Geduld angesagt.
Also keine Sorge, wenn das nicht sofort funktioniert.
verrät, wann der Name zur IP-Adresse zugeordnet wurde. Zum Test muss die Subdomain verwendet werden,
da die Namensauflösung von
mydomain.de
weiterhin zur IP-Adresse des Hosters erfolgt.
Um die richtige Seite im Webserver zu erreichen, muss unter nginx noch der virtuelle Server für
die neue Subdomain eingerichtet werden:
server {
listen 80;
server_name www.mydomain.de;
[...]
}
Geschafft !!! Nun sollte unser Server aus dem Internet erreichbar sein.
Mit der eigenen Domain ist man nun allerdings auffind- und identifizierbar. Seriöse Hoster leiten persönliche
Daten wie Name, Adresse, email und Telefonnummer an die Registrierungsstelle weiter, wo sie veröffentlicht werden.
Mit der Anonymität ist es an dieser Stelle vorbei.
Wer dies nicht möchte, kann bei der kryptischen Fritzbox-Subdomain bleiben.
Mit der Registrierung einer Domain ist auch eine Flut von Spammails diverser Webdesigner verbunden,
die Ihre Dienstleistungen anbieten.
3a. Vorsicht Falle
Wie so oft bei Onlineverträgen ist die Bestellung einer Domain schnell erledigt und die Gebühren werden pünktlich abgebucht. Geht es allerdings ans kündigen, gilt es Fußangeln zu überwinden.
Hier ein Beispiel zur Abwicklung einer .de-Domain bei Strato:
Mit Registrierung einer .de-Domain bei dem Provider werden gleichzeitig zwei Verträge geschlossen, einer mit dem Provider über Serviceleistungen und einer mit DENIC für die Verwaltung der Domain.
Kündigt man die Domain beim Provider, scheint die Welt in Ordnung. Es trifft eine email mit der Bestätigung der Löschung und dem Termin des Vertragsendes ein. Beachtung sollte der letzten Satz der email finden (Zitat aus der Strato-email):
Wenn Sie eine .de, .at oder .uk Domain besitzen, geben wir die Domain in
diesem Fall an die zuständige Registrierungsstelle zurück. Gegebenfalls
setzt sich diese später mit Ihnen in Verbindung, um das weitere Vorgehen
bzgl. der Domain zu klären.
Na gut, könnte man meinen, sollen sie sich doch bei mir melden, gekündigt ist gekündigt.
Aber das ist ein Irrtum !
Mit der Kündigung bei Strato ist es nicht getan. Der Vertrag mit DENIC besteht weiterhin.
Zwei Monate nach Vertragsende trifft per Briefpost von DENIC ein Schreiben ein,
dass ich (als Domaininhaber) mich nun entscheiden solle, wie mit der Domain zu verfahren sei.
Ohne weiteren Löschauftrag oder Providerwechsel wird die Verwaltung nach vier weiteren Wochen
gebührenpflichtig durch DENIC übernommen (58€ für das erste Jahr).
Vertraglich ist das bestimmt korrekt.
Irgendwo im Kleingedruckten wird's schon so stehen.
Nochmal online bei DENIC gekündigt und dann ist (hoffentlich) alles gut.
Falls jemand allerdings auf die Idee gekommen sein sollte, seine Adressdaten (illegalerweise)
gegenüber DENIC zu verfälschen, um nicht mit jeder WhoIs-Abfrage auf dem Präsentierteller zu stehen
oder einfach nur umgezogen ist, den wird diese Post nicht erreichen.
Und da anscheinend keine Infos per email vorausgehen, könnte die Frist verstreichen und sich daraus
eine Zahlungspflicht ergeben.
Also, Augen auf und/oder das Kleingedruckte lesen !
4. Sicherheitsbedenken über Board werfen ?
Natürlich nicht, sondern nachdenken! Wer einen Root-Server im Internet betreibt, macht sich angreifbar.
Fehlerhafte Software, ein schlecht gewartetes System oder falsche Konfiguration können es Eindringlingen
ermöglichen, den Raspberry zu kapern. Auch wenn das Teil wie ein Spielzeug aussieht,
unterscheidet es sich doch in Funktion und Leistungsfähigkeit kaum von den V-Servern namhafter Provider.
Pflicht für den Admin ist mindestens:
- Konfiguration prüfen
- System regelmäßig aktualisieren
- Logfiles prüfen
- auf ungewöhnliche Aktivitäten reagieren
Ansonsten bedarf es noch einer gehörigen Portion Vertrauen in die Fähigkeiten der Programmierer.
In Opensource-Software ist kaum mit Hintertüren zu rechnen, aber Schwachstellen können das Gesamtsystem gefährden.
Betrachtungen zum Thema Serversicherheit sind etliche im Netz zu finden.
Besonderes Augenmerk ist auf die Konfiguration von nginx zu legen.
Auch hier sind im Netz sehr viele Informationen zu bekommen, leider aber auch falsche.
Die Einstellungen müssen zum eigenen Dienst passen, sodass es mit der Übernahme einer Standard-Config nicht getan ist.
Ob man sich den Risken aussetzen möchte, muss jeder für sich entscheiden.
Aber was soll's.
Jeder weiß, dass das Leben gefährlich ist und man steht trotzdem frühmorgens auf.
