Ready to go?

Webserver auf Ubuntu

24. Dezember 2020

Fast jeder Technik Blog hat so ein Tutorial: "How to setup a Webserver". Jedoch sind viele davon entweder unvollständig oder machen einige Dinge nciht so wie du es gerne hättest. Deshalb in diesem Tutorial meine Version und mein Vorgehen wenn ich dies mache. Vorneweg: Es gibt noch etwa 1000 andere Varianten wie man einen Webserver aufsetzten kann und garantiert auch bessere, aber dies ist der Weg wie ich des machen würde mit meinem aktuellen Wissensstand, der sich bekanntlich gerne ändert.

Zuerst jedoch noch kurz eine Erklärung zum Webserver, insbesondere auch im Zusammenhang mit dem Raspberry Pi:

Raspberry Pi als Webserver

Eines der bekanntesten und weitverbreitetsten Projekte für den Raspberry Pi  ist die Installation und Konfiguration von einem Webserver mit allem was dazu gehört. Es kommt zwar selten vor das man in der Praxis einen blanken Webserver laufend auf einem Pi antrifft, denn dafür ist der Pi doch ein wenig zu schwach, aber es ist bei so vielen Projekten ein Webserver irgendwie integriert. Sei es als WebGUI, als Dashboard oder sonst irgendwie. Es gibt viele Tutorials da draussen welche dir erklären wie du aus dem Raspberry Pi einen Webserver machst. Doch zuerst eine kleiner Exkurs zur Frage: Warum einen Webserver auf dem Raspberry Pi?

Aus meiner Sicht macht es überhaupt keinen Sinn einen Webserver auf dem Raspberry Pi laufen zu lassen für einen Blog oder sonst eine Homepage. Dafür ist der Raspberry Pi definitiv nicht geeignet und man ist mit einem Webhosting eines Providers viel besser bedient. Doch wo macht es dann Sinn? Nun gerade im Bezug auf IoT ist Node-RED ein bekanntes Tool um seine ganzen IoT Geräte zu managen und zu steuern. Dies basiert auf einem Webserver. Oder auch das typische Beispiel der eigenen Cloud auf dem Raspberry Pi. Dies basiert ebenfalls auf einem Webserver. Dies sind zwei Beispiele wo man schlecht ein Webhosting dafür mieten kann. Klar für die Cloud wäre es noch denkbar aber eine eigene Cloud hat man ja sehr wahrscheinlich wegen dem Security und Datenschutz Aspekt und dann macht es Sinn das man sie zuhause hostet oder auf einem eigenen gemieteten Server. In beiden Fällen ist aber das Knowhow nötig wie man dies richtig aufsetzt.

Doch aus was besteht ein Webserver?

LAMP-Stack

Bisher habe ich absichtlich immer das Wort Webserver gebraucht. Ein Webserver ist also ein Server der mit HTML, CSS, PHP, JavaScript etc zu tun hat. Doch was für Komponenten braucht es damit ein Webserver entsteht? Einmal LAMP bitte.

LAMP ist die Abkürzung für LinuxApacheMySQLPHP und beschreibt was es im klassischen Fall alles braucht für einen Webserver. Es ist dabei wohl die bekannteste, simpelste und performanteste Option einen Webserver zu installieren und betreiben. Es gibt natürlich auch anderes. Heutzutage sehr stark im Trend ist NodeJS, AngularJS etc. All dies ist JavaScript welches Serverseitig ausgeführt wird und unter anderem das aktualisieren von Inhalten auf einer Website ohne Neu laden ermöglicht. Doch der Grossteil der Websites ist und wird wohl auch noch ziemlich lange auf dem altbekannten LAMP Stack laufen. Es gibt aber nicht nur LAMP. Für Testing und Development Zwecke wird auch gerne WAMP oder MAMP verwendet, was Linux einfach durch Windows oder MacOS austauscht. Folgendermassen gibt es auch Applikationen wie MAMP oder XAMPP welche dir einen LAMP Stack zum Entwickeln auf dein Laptop bringen. Gehen wir die einzelnen Komponenten des LAMP-Stack doch einmal durch und schauen uns die Besonderheiten an.

Linux

Das wohl offensichtlichste: Linux. Ohne Linux geht gar nichts. Es ist nach wie vor so und wird hoffentlich irgendeinmal nur noch so sein, das für Server Linux das beste OS ist was du haben kannst. Es gibt auch fast keine Alternativen, ausser der IIS von Microsoft aber von dem halte ich persönlich nicht viel.

Ein LAMP Stack lässt sich auf fast jedem Betriebssystem installieren. Wir werden in diesem Projekt einen Cloud Server mit Ubuntu 20.04 verwenden, einfach weils einfacher und bequemer geht. Die Befehle sind dabei aber die gleichen wie auf Raspbian und etwa jeder anderen Linux Distro die Debian als Unterbau verwendet. Distros basierend auf CentOS / Redhat oder auch SLES brauchen hier und da andere Befehle oder werden sogar einige Pakete nicht in den default Repositorys enthalten haben.

Apache

Nein nicht der Kampfhelikopter, sondern der Webserver. Apache war mal der meistgenutzte Webserver und ist heute immer noch ein sehr beliebter Webserver. Er ist OpenSource und seit langer Zeit in der Version 2.x verfügbar in den meisten Default Repositorys. Mehr zum Thema "beliebtester und meistgenutzer Webserver" gibt es hier.

MySQL

MySQL ist ein relationales Datenbanksystem und ebenfalls OpenSource. Es ist aber seit geraumer Zeit in den Händen von Oracle und wird auch fast ausschliesslich von Ihnen entwickelt. Dies ist aber auch der Grund weshalb es seit der Übernahme von MySQL durch Oracle auch MariaDB gibt. Der oder die Gründer und Urzeitentwickler von MySQL waren wohl damit nicht besonders happy und haben einen Fork von MySQL gemacht: MariaDB. MariaDB ist oder besser gesagt war ein Fork von MySQL welcher zu 100% Community basiert ist. Seit den letzten paar Versionen hat MariaDB nicht mehr wirklich viel mit MySQL gemeinsam, weshalb es weniger ein Fork und mehr ein eigenes Datenbanksystem ist. Es hat viele Gemeinsamkeiten mit MySQL. Besonders was SQL an sich und die Syntax angeht ist es sehr ähnlich. Lange war ein Argument für MariaDB die einfache Übernahme von MySQL auf MariaDB. Obwohl dies heutzutage wohl immer noch einfacher sein dürfte als andere Migrationen ist es nicht mehr das was es ausmacht. MariaDB hat den Ruf extrem performant zu sein und viele Features sowie StorageEngines zu untersützten. Es hat einige Features welche man bei MySQL nur in der Enterprise Edition findet. MariaDB hingegen hat diese in der "Community Edition" integriert, was gleichzeitig auch die einzige Edition ist die es gibt.

Ob MySQL oder MariaDB, beides sind brauchbare Systeme für einen LAMP-Stack und es kommt schlussendlich auf die detaillierten Bedürfnisse an was man installiert. Es fängt beides mit M an also spielt es für unseren LAMP-Stack nicht wirklich eine Rolle.

PHP

PHP ist die interpretierte Sprache im Hintergrund welches es erlaubt Seiten dynamisch zu generieren und mit Informationen aus einer DB zu erweitern und personalisieren. Es kann ebenfalls durch HTML Formulare mit dem Benutzer interagieren und Daten in eine DB schreiben. Oft kommt es mit diversen Modulen die es um etliche Funktionen erweitern. Es gibt wie oben erwähnt auch andere Möglichkeiten und Programmiersprachen für Websites aber PHP ist der gute alte Klassiker. Wir werden später auch noch eine Web Applikation installieren welche PHP braucht.

Doch zuerst muss unser LAMP-Stack stehen. Es ist wie gesagt ein extrem beliebtes Projekt um seine eigene Website nicht nur selber erstellt aber auch selber gehostet zu haben. Deshalb geht der LAMP und der Raspi meist Hand in Hand. Aber es ist eben doch nur ein Raspi und kein Server im Internet. Eine frequentierte Website sollte so also nicht betrieben werden. Dafür gibt’s gute Hoster welche dir das nötige zur Verfügung stellen damit du dich nicht mal mehr um den Unterhalt und Betrieb des LAMP kümmern musst.

Doch da wir Technikbegeisterte sind werden wir uns nun einen eigenen LAMP-Stack ganz manuell deployen.

Installation

Fangen wir mit der manuellen Installation an in welcher wir jede Komponenten einzeln installieren werden.

Wie bereits erwähnt mache ich dies auf einem Cloud Server auf welchen die Domain "techpi.ch"  zeigt. Somit haben wir später gleich etwas womit wir arbeiten können.

Apache installieren

Das allererste was wir machen ist unsere Paketquellen aktualisieren und danach installieren wir den Apache.

Danach öffne ich noch die entsprechenden Port auf meiner Basic Firewall (ufw):

Wenn wir danach mal im Browser die IP / Domain unseres Servers aufrufen sehen wir das der Apache2 läuft und seine Default Website erreichbar ist.

Das wäre nun also erstaunlich einfach gegangen.

MySQL / MariaDB installieren

Als nächstes kommt MySQL oder eben MariaDB. Es spielt keine Rolle welches wir nehmen, denn bei beiden ist der Prozess genau der gleiche:

Ich nehme hier mal klassisch MySQL

Nachdem dies installiert ist, lassen wir noch ein Skript durchlaufen welches gewisse Default Security Einstellung nach Angaben vornimmt.

Die Fragen sind ziemlich einfach zu beantworten. Ich habe das Passwort Validation Plugin nicht aktiviert, da es für Testzwecke nicht nötig ist und bei Debugging mühsam sein könnte, aber das hindert einem ja nicht daran gute Passwörter zu nehmen 😉.

 

 

PHP installieren

Nun da dies erledigt wäre lass uns PHP installieren, zusammen mit den benötigten Modulen um mit dem Apache und MySQL zu kommunizieren: 

Soweit so gut, nun ist unser LAMP-Stack installiert und Einsatzbereit, aber wie meistens muss man Dinge nun auf seine Bedürfnisse hin konfigurieren. Dazu im folgenden ein Paar Dinge die es sich lohnt zu konfigurieren. 

LAMP Recommneded Configs

Apache Virtualhost

Bevor wir nun unserer Demowebsite installieren konfigurieren wir uns einen Apache Virtualhost. Dies ist quasi eine "Webseitenkonfiguration" die es einem erlaubt verschiedene Websites auf dem gleichen Webserver laufen zu lassen. Dies ist jedoch nur möglich wenn die Websites mittels Domainnamen aufgerufen werden oder man eine URL spezifiziert wie phpMyAdmin mit IP/phpMyAdmin. 

Wie bereits erwähnt habe ich eine Domain "techpi.ch" zeigend auf meinen Server.  Im folgenden werden wir nun für die Domain einen Virtualhost konfigurieren.

Nun gehe ich ins /var/www. Dort gibt’s bereits einen Ordner namens "html" dort drin ist die Default Website welche wir ganz am Anfang gesehen haben. Wir lassen dies und erstellen uns hier je einen Ordner für "techpi.ch". Danach vergebe ich noch direkt die richtigen Berechtigungen, damit ich in diesem Ordner arbeiten kann und alle anderen lesen dürfen (so auch der Apache User). 

Nun wechsle ich ins /etc/apache2/sites-available Verzeichnis. /etc/apache2 ist das Hauptkonfigurationsverzeichnis vom Apache. Alle Konfigurationen sind hier abgespeichert. So auch die Virtualhosts. 

Ich lege mir einen Virtualhosts an und kopiere für den Anfang den folgenden Text rein:

  • Mit "ServerName" definiere ich unter welcher Domain der Apache aufgerufen werde muss damit dieser Virtualhost sich angesprochen fühlt. Zusammen mit dem Port in der ersten Zeile. 

  • Mit "ServerAlias" definiere ich einen zweiten "ServerName" z.B für www.techpi.ch 

  • ServerAdmin ist die Mail Adresse. Falls keine Custom Error Pages konfiguriert sind, kann es bei einem Fehler sein das diese Adresse im Browser angezeigt wird, es sollte also nicht die private sein.  

  • "DocumentRoot" ist das Projektverzeichnis. Hier drin erwartet er ein index.html ein index.php.  

  • Die anderen beiden Settings beziehen sich auf die Logs, man könnte an dieser Stelle die Logs auch dezentral z.B ins /var/www/techpi.ch/error.log schreiben. Aber wir lassen es mal so 

Um diese Konfiguraiton nun in Kraft treten zu lassen arbeiten wir mit den Befehlen "a2ensite" und "a2dissite". Lass und also unsere Websites mal aktivieren:

Im gleichen Zug deaktivieren wir die Default Website. 

Bevor wir nun unsere neuen Websites aufrufen können müssen wir noch irgendetwas im entsprechenden Ordner ablegen, was dann auch angezeigt werden kann. Ich verwende dafür ein einfaches HTML welches ich mir mal erstellt habe für ähnliche Zwecke. 

Dieses Dokument platziere ich als "index.html" im /var/www/techpi.ch:

Und nun sind wir mutig und probieren mal was unter "http://techpi.ch" kommt:

Scheint zu funktionieren, zumindest unter HTTP und mit diesem statischen HTML.

Doch es gibt noch mehr Zeugs das wir konfigurieren können.

DirectoryIndex Reihenfolge wechseln

Beim Virtualhost aufsetzten haben wir ein "index.html" File ins /var/www/techpi.ch gelegt und der Apache hat entsprechend dieses HTML File genommen. Woher hat der gewusst das er dieses nehmen sollte? Nun das liegt am sogennanten DirectoryIndex welcher im File /etc/apache2/mods-enabled/dir.conf spezifiziert wird. Dort steht nämlich in welcher Reihenfolge welche Filenamen und Dateiendungen in den entsprechenden Projektordnern gesucht werden sollen. Man sieht hier auch gut das ein index.html vorrang hat vor einem index.php. 

Je nachdem ob einem dies passt oder nicht kann man hier nun die Reihenfolge verändert. Nicht vergessen danach den Aapche2 einmal rezuloaden damit er die Konfig auch schluckt. 

SSL Konfigurieren

Als nächstes kümmern wir uns mal um das Thema SSL. 

Dies machen wir via Let's Encrypt. Let's Encrypt ist eine CA welche es sich gewissermassen zum Ziel gemacht hat das ganze Internet HTTPS fähig zu machen. Dies tun sie indem man bei Ihnen ohne grosse Probleme und komplett kostenlos SSL Zertifikate bekommt. Bei einer anderen CAs kosten die sonst jeweils einiges und sind auch nicht ganz so einfach zu bekommen, respektive brauchen ein bisschen mehr Konfigurationsaufwand. Dafür garantieren sie dir meistens nicht nur HTTPS sondern auch die Identität deiner Website. Sprich sie prüfen ob du du bist. Das tut Let's Encrypt nur bedingt. Das Ding ist nämlich, das ein SSL Zertifikat nicht nur einen Publik Key beinhaltet damit Asymetrische Verschlüsselung funktioniert, sondern gleichzeitig auch noch ein Zertifikat ist welches besagt das der Besitzer eben der Besitzer ist. So kann sich niemand anders als du ausgeben. Jedoch überprüft Let's Encrypt dies nicht mit irgendwelchen Pässen oder sonstigen Hochoffiziellen Dokumenten sondern eben nur indem sie schauen ob die Domain welche du mit SSL sichern möchtest auch auf den Server zeigt auf dem du sie installieren willst. Dies übernimmt ein kleines Tool von ihnen genannt "Certbot". Es gibt verschiedene Wege wie der Certbot (via Let's Encrypt Server) überprüfen kann das die Domain für welche du ein SSL Zertifikat möchtest auf dein Server zeigt. Eine davon ist die Webroot Challenge. Doch zuerst nochmals kurz zurück zu SSL. Let's Encrypt Zertifikate sind für sehr viele Websites wahrscheinlich vollkommen ausreichend. Problematisch wird es bei Dinge wie Onlinebanking. Dort geht es natürlich nicht wenn das Online Banking Tool einer Bank mit einem Let's Encrypt Zertifikat daherkommt. Da muss dann schon eins von einer anderen CA her. Dies besagt dann auch das die CA das Zertifikat unter Prüfung ausgestellt hat, das auch wirklich die Bank dieses bekommen hat und auch wirklich sie es sind die das Zertifikat für ihre Domain angefragt haben. 

Nun noch zu dieser Webroot Challenge. Bei diesem Verfahren generiert der Certbot auf deinem Server ein random String aus Zahlen und Buchstaben. Den sogenannten Challenge-String. Dieser wird dann in einem File im Webverzeichnis deiner Domain abgespeichert. Danach versucht der Certbot mit Hilfe der Let's Encrypt Server dieses File aufzurufen indem er die Domain benutzt und dann halt /filename. Wenn er als Antwort das File zurückbekommt mit dem String, weiss er das die Domain auf den richtigen Server zeigt und stellt dir das Zertifikat aus. Es geht sogar noch weiter, der Certbot kann danach auch automatisch die Virtualhost Konfiguration für Nginx und Apache anpassen damit SSL funktioniert. Ebenfalls bietet der Certbot eine Funktion zum Erneuern der Zertifikate welche man z.B als Cronjob laufen lassen kann damit man sich nicht mehr um die Erneuerung der Zertifikate kümmern muss.

Lass uns diesen Certbot doch mal installieren und dann schauen wir uns an wie man ein Zertifikat bekommt. 

Danach starte ich den Certbot und gebe ihm mit das ich gerne mittels der Apache-Methode Zertifikate bekommen möchte. 

Und....:

Tata! So einfach geht SSL. Da hat Let's Encrypt vieles richtig gemacht um SSL so einfach wie möglich zu machen. 

Es geht sogar noch weiter. SSL Zertifikate sind ja Zertifikate und die haben wie alle Zertifikate ein Ablaufdatum. Im Falle von Let's Encrypt ist es so das diese nach 90 Tagen verfallen, dies hauptsächlich aus Security Gründen. Jedoch haben sie auch da eine Lösung parat wie man seine Zertifikate automatisch erneuern kann. Dies übernimmt der Certbot via Cronjob ebenfalls. Der Cronjob hingegen wird wie systemctl gemanaget. Lass und den doch mal anschauen: 

Der erste Befehl zeigt via systemctl was der Cronjob macht und ob er läuft. Der zweite ist quasi der Command welcher mittels Cronjob ausgeführt wird. Mit der Option -dry-run können wir sehen ob er alles richtig machen würde

PHPMyAdmin installieren

Um Datenbanken zu administrieren gibt es den mysql Dialog auf der Konsole. Dieser ist jedoch relativ advanced und erfordert einiges an Kenntnissen. Hier wäre ein WebGUI viel bequemer und einfacher. Zum Glück gibt’s das schon seit langem und nennt sich phpmyadmin. Es ist wichtig das wir SSL vor phpmyadmin eingerichtet haben, da phpmyadmin ohne HTTPS eine RIESIGE Sicherheitslücke darstellt. Da wir nun aber SSL Certs für zwei Virtualhosts haben können wir phpmyadmin auch darüber laufen lassen.

Um phpmyadmin zu installieren brauchts folgende Befehle:

Bevor wir den Befehl absetzten lass uns kurz über die PHP Module reden welche hier mitinstalliert werden. Phpmyadmin empfiehlt diese Module mitzuinstallieren aus folgenden Gründen: 

Macht Sinn? Performance und mehr Features sind immer gut.

Während der Installation von phpmyadmin müssen wir nun einige Konfigurationen direkt festlegen:

 

Alles ziemlich logisch oder?

Das letzte was wir nun noch wollen ist das PHP Modul mbstring zu aktivieren und den Apache2 zu reloaden. 

PHPMyAdmin MySQL User erstellen

Nun haben wir zwar phpmyadmin installiert und sogar ein Password für einen User namens "phpmyadmin" gesetzt, welcher für diverse Hintergrundtasks zuständig ist, aber wie loggen wir uns nun im GUI ein? 

Dies geschieht entweder durch den Root User, welcher aber momentan mittels auth_socket authentifiziert wird. Dies ist sicherer aber man kann nun nicht mittels Password einloggen. Also erstellen wir uns am besten einen Adminuser welcher genug Rechte hat um via phpmyadmin alles zu administrieren aber doch nicht root ist. 

In etwa so. Nun lass uns mal sehen ob wir uns in phpmyadmin einloggen können: 

Works!

Jedoch kann nun auch jeder andere der weiss das domain.tld/phpmyadmin der Link zum phpmyadmin ist dies erreichen und ein einfacher Passwortschutz ist nicht wirklich sicher, auch wenn das Passwort sicher ist. 

Was können wir dagegen machen? 

Der Apache hat eine Möglichkeit gewisse Web Ressourcen durch eine einfache Authentifizierung zu schützten. Wenn wir dies davorschalten und ein anderes Passwort wählen haben wir eine doppelte Authentifizierung und die Möglichkeit via Sicherheitslücken von phpmyadmin reinzukommen ausgeschlossen.

Damit das geht muss phpmyadmin aber zuerst .htaccess Dateien unterstüzten. Dies ist eine Zugriffsdatei welche soebengenanntes in die Tat umsetzt. Man kann damit aber auch von http auf https umleiten oder www.domain.tld auf domain.tld (ja dieses WWW in der URL ist doch lustig nicht 😉).

Damit dies passiert gehen wir in die Virtaulhost Config von phpmyadmin rein und fügen folgende Zeile hinzu: 

Ein Neustart später ist dies aktiv. Nun können wir eine .htaccess für phpmyadmin schreiben. 

Die Zeilen machen folgendes: 

AuthType Basic: Beschreibt das wir hier eine simple Authentifizierung via Passwortfile vor diese Web Applikation setzten

AuthName: Setzt eine Message welche im Browser zusammen mit der Loginmaske kommt wenn man versucht die Website zu öffnen

AuthUserFile: das besage Passwortfile 

Require valid-user: Ohne dies würde die Authentifizierung nichts bringen, es besagt das eben nur authentizifierte User die Applikation sehen dürfen.

Nun erstellen wir uns noch das Passwortfile: 

Natürlich können auch mehrere User hinzugefügt werden, dies geschieht folgendermassen: 

Wenn wir nun die Website aufrufen kommt zuerst mal folgendes:

Bevor wir dann auf die Loginmaske von phpmyadmin selber kommen.

Was wir als Sahenhäuptchen obendrauf noch machen können ist den "Default Pfad" wegzunehmen. Aktuell ist phpmyadmin unter domain.tld/phpmyadmin erreichbar. Dies ist aber garantiert auch der Pfad der von irgendwelchen Boswiligen Bots oder Hacker ausprobiert wird. Was wenn wir statt /phpmyadmin nun /gugussugus machen würden? 

Dies ist wie mit vielem in der IT so. Sicherheit fängt zuvorderst an indem man Standartwerte auf eigene Werte verändert. Seien es Pfäde, Ports oder Passwörter. 

Um dies zu machen gehen wir nochmals in die phpmyadmin virtualhost Config rein und ändere ganz zuoberst das Alias:

Wenn man das ganze auf einem Pi zuhause laufen hat könnte man hier sogar noch  einschränken aus welchen Netzten der Zugriff zugelassen ist: 

Das würde dann in dem resultieren: 

So oder so Apache reloaden nicht vergessen: 

Vorbereitungen PHP-Applikation

Nun sind wir aber etwa fertig mit dem LAMP konfigurieren und absichern. Jetzt wird es erst so richtig spannend, denn was haben wir noch nicht gebraucht? Richtig PHP. Also lass und mal eine PHP-Applikationen installieren. Diese kommt ins /var/www/techpi.ch Verzeichnis.

Als Beispiel nehme ich hierfür Concrete5, aber viele andere PHP Applikationen funktionieren in der Installation sehr ähnlich.

Fangen wir damit an das wir uns Concrete5 in den richtigen Ordner auf dem Server ziehen:

Auf dem Server unzipen wir die Dateien: 

Und nun müssen wir noch das Zip löschen sowie die Dateien aus dem Unterordner nach oben holen:

Und dann kümmern wir uns um die DB. Bei Concrete5 ist es so das wir eine DB sowie User erstellen müssen welchen Concrete5 benutzten darf. Also entweder via phpmyadmin diese einfach und praktisch erstellen oder auf die Hardcore Variante: 

Ich würde für ein nächstes mal vielleicht die DB nicht gleich nennen wie den User  und den User z.B "c5_user" benennen, macht vieles einfacher…

Installation C5

Nun installieren wir doch C5. Im Browser das C5 aufrufen und den Setup Guide durchgehen. Dieser ist relativ selbsterklärend. 

Wie man sieht habe ich noch einen Fehler drin. Dieser besagt mir das die Verzeichnisse /var/www/techpi.ch/application und /var/www/techpi.ch/packages für den Webuser nicht beschreibbar sind. Dies ist auch ganz normal, haben wir doch die Berechtigungen auf /var/www/techpi.ch zu 755 für uns gestellt. Entweder wir stellen sie auf 777 was ich nicht empfehlen würde oder wir geben den ganzen Configordner einfach dem sogenannten www-data User. Dies ist der Apache User für solche Verzeichnise. Dies bedeuet zwar das wir in diesem Ordner danach mit sudo arbeiten müssen sofern wir uns nicht in die Gruppe des www-data schleichen, aber das kann ich verkraften.

Also: 

Wenn wir auf dem C5 Installer nun "Run Test Again" drücken sollte alles grün sein. 

Nun geht es um die Settings. Der Sitename, Administrator Email / Password sind ja relativ selbsterklärend. Spannend wird es bei der Datenbank. Da wir einen LAMP Stack auf einem Server laufen haben können wir als Server "localhost" angeben und allenfalls den Port falls wir irgendwo den Standardport von "3306" geändert hätten 

So passt das. 

 

Unter den Advanced Options können wir noch Einstellungen für die Canonical URL sowie Zeit und Spracheinstellungen machen. Ich mache dies ganz gerne da so das /index.php in der URL verschwindet: 

Und dann starten wir die Installation. 

Bei mir hat er noch gemekert das https://techpi.ch mit einem / am Schluss angegeben werden soll.  

Wenn die Installation fertig ist wird dies entsprechend mitgeteilt. Mit "Edit your Site" kann die Seite nun angesehen und bearbeitet werden: 

Erfolg auf ganzer Linie! Auch das /index.php ist aus der URL verschwunden. 

Einen LAMP-Stack manuell aufsetzten braucht viel Know How und man muss sich ständig um irgendetwas kümmern. Es erlaubt einem aber auch sehr viel Flexibilität und man hat über alles die Kontrolle. Heutzutage ist es dies leider nicht immer wert, weshalb es die wesentlich bequemere Variante ist sich ein Webhoasting bei einem Provider zu holen. Dort kommt man zwar auch mit phpmyadmin, sftp und PHP in Kontakt aber man muss sich nicht mehr um den Betrieb des LAMP kümmern. Jedoch finde ich es sehr spannend und will mir dieses Know How unbedingt noch weiter ausbauen, man weiss ja nie wann man es braucht...

Hilfestellungen

Anmelden