LEMP Stack – der perfekte Webserver

Update: 30.03.2018

Hinweis: Neben den Anleitungen im Rahmen dieser Serie habe ich mittlerweile fertige Shell Scripte erstellt, die quasi voll automatisch die Installation eines Servers für euch übernehmen. Ihr findet das Ganze auf github.de, wobei ihr entweder den ganzen Server per Script aufsetzen und konfigurieren lassen könnt, oder eben jeden einzelnen Schritt, wie  z.B. das Absichern des Servers, oder das Installieren eines LEMP Stacks, mit Hilfe der jeweiligen Scripte erledigen könnt. Die Scripte entsprechen quasi 1:1 zu den Tutorials.

Inhalte

LEMP

Zugegeben, es ist schon wieder ein bissen mehr Zeit verstrichen, seit ich den letzten Teil zum perfekten Server veröffentlicht habe, aber wie heißt es so schön, besser spät als nie! Im Grund genommen ist dies hier ja auch nur eine Art Nachschlagewerk, gefüllt mit meinen persönlichen Empfehlungen.

Ich hatte letztes Jahr eigentlich schon mal einen relativ ausführlichen Artikel zum Thema LEMP verfasst, mich nach anfänglichem Überlegen dann aber doch dazu entschieden einen neuen Artikel zu verfassen – wobei ich hier ein bisschen weiter ins Detail gehen werde, bzw. wir einen Teil selbst compilieren werden. Wer nur eine schnelle und simple Anleitung sucht, der kann sich ja noch mal das alte Tutorial angucken.

Als Grundlage für unseren LEMP Server bzw. unser LEMP Stack dienen Debian, NGiNX, PHP und MariaDB.

Ich hatte zwischenzeitlich mal Testszenarien mit HHVM statt php, bzw. HHVM und php als Fallback laufen, bzw. MySQL oder MungoDB statt MariaDB im Einsatz. Mit allen Kombinationen war ich eher weniger zufrieden, weswegen ich mich eben für oben genannte Komponenten entschieden habe.

So dann wollen wir mal, immer schön der Reihe nach.

System vorbereiten

Auch wenn wir unser System gerade erst aufgesetzt haben, kann es nicht schaden es zu Beginn zu updaten – gerade wenn man eine CD als Installationsmedium verwendet, oder fertige Images vom Hoster.

Standardmäßig kommt Debian mit dem Texteditor Nano daher, da ich aber kein großer Fan von Nano bin und quasi mit Vim aufgewachsen bin, installieren wir an dieser Stelle schnell noch Vim. Theoretisch sollte den meisten Usern eigentlich auch vim reichen, die vim-nox Version kommt mit zusätzlichem Support von tcl, ruby, Lua und perl daher – je nachdem, was man noch so vorhat.

nginxInstallation Nginx

Für die Installation von nginx gibt es zwei Möglichkeiten. Die Erste ist sicherlich die bequemere, aber in meinen Augen nicht gleich bessere Variante. Außerdem ist die zweite Möglichkeit die einzige, um zusätzlich Module zu installieren. Wobei nginx hier mittlerweile auch immer offener für das nachträglich integrieren von Modulen wird, wie z.B. das GeoIP Modul.

Installation via APT

Die Installation via APT ist sicherlich eine feine Sache, nur leider installieren wir damit nicht wirklich die neuste Version, sondern die letzte ’stable‘, d.h stabil laufende Version. Mittlerweile ist man hierbei immerhin schon bei der Version 1.12.2 angekommen. Wer auf Nummer Sicher gehen will, der kann hier beruhigt die stable Version installieren – profitiert aber damit leider nicht von aktuellen Neuerungen der ‚mainline‘ Version.

Installation via Source

Da wir in unserem Fall die mainline Version von nginx installieren wollen, müssen wir ein wenig mehr Hand anlegen. Belohnt werden wir dafür aber mit den neusten Funktionen und Features. Die mainline Version wird eigentlich in der Regel ziemlich oft upgedatet und weiterentwickelt. Aktuelle Version wäre hier die 1.13.10.

Zunächst benötigen wir die passenden Werkzeuge, um nginx selbst aus den source files zu kompilieren, d.h. auf unserem System nach unseren Wünschen zusammen zu bauen.

Ähnlich wie bei der Installation via APT müssen wir das passende Repository hinzufügen und die Daten herunterladen.

Anschließend laden wir die passenden Files herunterladen und wechseln in den Ordner.

Jetzt sind wir eigentlich schon fast am Ende des Datensammelns angelangt.

Ich für meinen Teil installiere aber gerne immer noch das Cache Purge Modul von FRiCKLE. Das ist zwar schon ein wenig älter, erfüllt aber dennoch bestens seinen Zweck, speziell im Zusammenspiel mit WordPress und dem Nginx Helper Plugin. Besonders praktisch, wenn ihr öfters Artikel auf WordPress und Co veröffentlicht, oder bearbeitet. Dank nginx eigenem Cache spart man sich eigentlich sämtliche Cache Plugins, die die WordPressinstallation eh nur noch langsamer werden lassen. Mittlerweile gibt es aber auch mit dem Nginx Cache Plugin die Möglichkeit nginx hauseigenen cache ohne zusätzliches Modul zu ‚purgen‘.

Beide Plugins erfüllen ihren Zweck, von daher werde ich im nächsten Schritt auch auf beide Möglichkeiten nginx zu compilieren eingehen, mit und ohne zusätzliches Modul.

Option 1: Zusätzliche Module hinzufügen

Wie im letzten Schritt bereits beschrieben, werden wir ein zusätzliches Modul, das Cache Purge Modul, herunterladen und vor der eigentlichen Installation in unser selbst compiliertes Installationspaket einfügen. Dafür erstellen wir zunächst einen neuen Modul Ordner, laden das passende Modul herunter, entpacken es und benennen den Ordner anschließend um, da wir am Ende sonst einen ziemlich langen, unschönen Namen haben – haha. Die heruntergeladenen Zip files werden anschließend nicht mehr benötigt und gelöscht.

Wenn ihr zusätzlich andere Module, wie z.B. das PageSpeed Modul von google – welches ich nach längerem Test für nutzlos befunden habe – installieren wollt, dann könnt ihr genau so vorgehen und die passenden Files in den Modul Ordner kopieren.

Nun müsst ihr nur noch die nginx Installation anpassen, da nginx ja nicht riechen kann, dass ihr noch zusätzliche Module installieren wollt. Ebenfalls ändere ich die Rechte Debian-typisch auf www-data. Da ich relativ faul bin und die config files nicht einzeln von Hand öffnen möchte, machen wir das ganze per sed (stream editor). Achtet hierbei bitten genau auf eure eigenen Pfadangabe, bzw., da wir sed zum editieren benutzen, auch darauf, im letzten Befehl mit Hilfe von „\“ jedes „/“ auszukommentieren, aber nur innerhalb der „“!

Für den Fall, dass ihr keine Lust habt, das ganze mit sed zu editieren, könnt ihr die /nginx-1.13.10/debian/rules auch von Hand editieren, per sftp Client, oder mit Hilfe von nano, vim, etc. Das Ganze sollte dann so aussehen, wobei ihr den letzten Eintrag auch ignorieren könnt, wenn ihr nicht gerade später die debug Version installieren wollt.

Option 2: Ohne zusätzliche Module

Ohne zusätzliche Module spart ihr euch quasi den ersten Schritt aus dem vorherigen Teil, bzw. den letzten Schritt am Ende. Alles was ihr benötigt ist folgender Befehl:

Oder eben die von Hand editierte rules

Installationspaket erstellen

Soooo, fast geschafft, jetzt basteln wir uns aus den source files und unseren optionalen Modulen eine passende Installationsdatei.

Das kann jetzt einen Moment dauern. Wir erhalten in der Regel nicht nur ein File, sondern eine ganze Hand voll Files. Diese könnt ihr nun nach Belieben installieren. Eine Auflistung erhalte ihr mit „ls

In unserem Fall wären das z.B. für die reine nginx Installation inkl. unserer selbst eingebauten Module.

Das hätten wir geschafft. nginx sollte nun eigentlich erfolgreich auf eurem Server laufen.

Einige Module lassen sich Gott sei dank mittlerweile bequem nachträglich per APT installieren, wie z.B. das GeoIP Modul

Zu guter Letzt schließen wir noch unsere mühevoll von Hand installiere nginx Version von automatischen Updates via APT und Co aus. Es kann sonst nämlich passieren, dass euch APT sonst einfach die stable Version drüber bügelt und all eure Module flöten gehen – selbst schon passiert, also Vorsicht!

Konfiguration Nginx

Kommen wir nun zur Konfiguration von nginx. Hier kommt es sicherlich auf persönliche Vorlieben an, was die Ordnerstruktur etc. angeht, also seht das Ganz nicht so eng, sondern nutzt es evtl. als Leitfaden.

Zunächst erstelle ich mir einen Ordner wo ich später sämtliche Files für den Webserver ablege, und setzte die passenden Berechtigungen.

Als nächstes erstelle ich mir gerne vier Ordner. Einen für alle gängigen config files, einen für alle vhost Konfigurationen, einen für die aktivierten vhosts und einen für alle Cache files.

In den cfg Ordner kommen alle meine configs, ganz gleich, ob ich sie verwende, oder nicht. Diese importiere ich dann quasi bei Bedarf in der Hauptkonfiguration.

Im Ordner sites-available landen alle vhost files und im Ordner sites-enabled lediglich symlinks, d.h. Verlinkungen. Somit kann es mir nicht passieren, dass ich aus Versehen irgendwelche Files lösche, bzw, habe ich so die Möglichkeit schnell Änderungen vorzunehmen, oder bei Bedarf bestimmte configs zu aktivieren bzw. deaktivieren, ohne dabei immer wieder die Hauptkonfiguration anzupassen.

Die Hauptkonfiguration – nginx.conf ist somit immer schön schlank und übersichtlich.

Das Ganze sieht dann in etwa so aus:

Und hier mal ein paar Configs aus dem cfg Ordner, damit ihr ein Gefühl für die Struktur bekommt.

 gzip.cfg

Natürlich sind das alles nur Beispiele. Jedem steht natürlich frei, seinen Webserver einzurichten, wie er mag. Auf der Seite des Herstellers findet man z.B. auch einige gut erklärte Beispiele. Bzw. eine Sammlung verschiedener meiner configs findet ihr auch hier.

Zu guter Letzt starten wir nginx neu, damit alle Änderungen übernommen werden. Keine Sorge, wenn ihr hier irgendwas falsch gemacht habt, startet nginx gar nicht erst, wirklich was kaputt machen könnt ihr also nicht. Bzw. am Besten testet ihr die Config vorher einmal kurz mit nginx -t.

Vhost einrichten

Richtig, wie ihr sicherlich bemerkt habt, gibt es bis hierhin noch keine wirkliche Erklärung zum Thema vhost, bzw. der Konfiguration einzelner Websites. Das möchte ich an dieser Stelle auch so belassen. An anderer Stelle, zum Thema WordPress Installation, oder Nextcloud findet ihr dann auch einen vollständigen vhost.

Der Übersicht halber hier nur kurz das Standard Beispiel vom Hersteller.

Eine Datei mit dem Inhalt speichert ihr nun im Ordner sites-available ab und erstellt einen symlink zum Ordner sites-enabled. Danach müsst ihr nginx wieder neustarte.

php7Installation PHP 7.2

Hier können wir wieder bequem auf APT zurückgreifen! Installiert wird aber nicht direkt php 7.2, sondern php7.2-fpm – PHP FastCGI Process Manager, php läuft also als eigener Prozess.

Da wir die neuste Version installieren wollen, müssen wir noch das passende Repository hinzufügen. Aktueller wäre natürlich, wenn wir das Ganze, ähnlich wie nginx aus dem source selbst kompilieren, aber da hier keine besonders großen Versionssprünge zu erwarten sind, überlassen wir diese Arbeit wem anders.

Jetzt können wir bequem mit Hilfe von APT PHP-FPM und alles, was wir später sonst noch so gebrauchen können, installieren.

Nur was die Konfiguration, falls gewünscht, angeht ist mal wieder Handarbeit gefragt. In diesem Beispiel erhöhe ich die Maximalgröße von Uplaods bzw. deaktiviere das Ausführen von externen php Scripten.

Seht ihr, das ging doch schon mal wesentlich fixer. Damit ist php 7 auch schon einsatzbereit!

mariadbInstallation MariaDB

MariaDB lässt sich Gott sei Dank auch relativ einfach und unkompliziert via APT installieren, wobei wir hier auch zuerst das passende Repo hinzufügen müssen.

Die Konfiguration ist, wie bei php, ebenfalls ziemlich schnell erledigt. Hierbei unterbinde ich ebenfalls, wie bei php, Zugriffe von Außerhalb.

Damit wäre MariaDB eigentlich schon einsatzbereit. Ich empfehle dennoch kurz zur Absicherung den letzten Schritt:

So geschafft, das wars dann auch schon. Euer LEMP Webserver sollte nun ohne Probleme laufen!

phpmyadminphpMyAdmin

Die Installation von PHPmyAdminist zwar nicht zwingend notwendig, für mich gehört es aber zu den nützlichsten webbased Tools überhaupt! Mit Hilfe von PHPmyAdmin könnt ihr ganz bequem via Browser auf euren SQL Server zugreifen. Hierbei gilt, ähnlich wie bei nginx. Die Version direkt vom Anbieter ist aktueller, als via APT.

Was machen wir genau? Wir clonen die neuste Version direkt von Github, erstellen einen sicheren Schlüssel, der später vom Webinterface benötigt wird und installieren alles mit Hilfe von Composer. Da ich nicht davon ausgehe, dass Composer bis jetzt auf dem System läuft, laden wir dieses Tool vorab herunter.

Zu guter Letzt erstellen wir uns eben noch schnell ein Update Script, um auch diese Version immer up-to-date zu halten. Wer nicht unbedingt wöchentlich updaten möchte, kann das Ganze auch im cron.monthly statt cron.weekly Ordner ablegen.

Viel Spaß mit eurem neuen Webserver!

Bei Fragen stehe ich natürlich nach wie vor gerne zur Verfügung.

Kommentieren Sie den Artikel

Please enter your comment!
Please enter your name here