From aadff8accef805797214f8531575dfa68ddafa50 Mon Sep 17 00:00:00 2001 From: Thomas Dannenberg Date: Mon, 6 Oct 2025 20:05:03 +0000 Subject: [PATCH] =?UTF-8?q?Kapitel=209/Premium=20Rohtext.md=20hinzugef?= =?UTF-8?q?=C3=BCgt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Kapitel 9/Premium Rohtext.md | 830 +++++++++++++++++++++++++++++++++++ 1 file changed, 830 insertions(+) create mode 100644 Kapitel 9/Premium Rohtext.md diff --git a/Kapitel 9/Premium Rohtext.md b/Kapitel 9/Premium Rohtext.md new file mode 100644 index 0000000..c0e3be7 --- /dev/null +++ b/Kapitel 9/Premium Rohtext.md @@ -0,0 +1,830 @@ +## Premium – Professionelle Erweiterungen für den Webspace + +Im Free-Kapitel hast du den Webspace so eingerichtet, dass er sofort für einfache Webseiten einsatzbereit ist. +Der Premium-Teil erweitert diese Grundlage gezielt um Funktionen, die für ein professionelles Arbeiten unverzichtbar sind: automatisierte Deployments, klare Trennung von Test- und Live-Umgebungen, optimierte Sicherheit und mehr Komfort bei Wartung und Updates. + +Diese Erweiterungen helfen dir, den Webspace zuverlässig zu betreiben, selbst wenn mehrere Personen an Projekten arbeiten oder wenn du komplexere Anwendungen wie Shops oder Portfolios betreiben möchtest. + +In diesem Kapitel behandeln wir: + +1. **Auto-Deployment via Git** – Änderungen werden per `git push` direkt auf den Webspace übertragen. +2. **Staging / Production-Trennung** – eine Test- und eine Live-Umgebung mit getrennten Domains/Subdomains. +3. **HTTPS-Redirect-Regeln** – alle Aufrufe werden automatisch auf verschlüsseltes HTTPS umgeleitet. +4. **Multi-Site-Hosting** – mehrere Webseiten oder Projekte sauber nebeneinander auf demselben Container betreiben. +5. **CDN-Integration** – statische Inhalte wie Bilder und Skripte schneller ausliefern. +6. **Sicherheitsmaßnahmen** – Härtung des Webservers und Schutz sensibler Bereiche. +7. **Vorbereitung einer CMS-Installation** am Beispiel WordPress – als universelle Basis für Blogs, Shops und Portfolios. +8. **Automatische System-Updates** – Debian, Apache und PHP halten sich selbst aktuell. + +[!NOTE] +Alle Schritte in diesem Premium-Kapitel bauen auf der bestehenden Free-Installation auf. +Es ist keine Neuinstallation nötig. +Wir fügen zusätzliche Konfigurationen und Werkzeuge hinzu, um den Webspace produktionsreif und zukunftssicher zu machen. + +--- + +## 1. Auto-Deployment via Git + +Mit einem Git-basierten Deployment kannst du deine Webseiten und Projekte lokal entwickeln und anschließend per `git push` direkt auf den Webspace übertragen. +Das erspart manuelles Hochladen per SFTP und verhindert Fehler durch vergessene Dateien. +Außerdem lassen sich mit diesem Workflow Versionen sauber nachvollziehen und bei Bedarf zurückrollen. + +### Warum Git-Deployment? +- **Schneller und sicherer Upload:** Änderungen werden gezielt übertragen, nicht die ganze Seite. +- **Versionskontrolle:** Jeder Stand ist dokumentiert und kann jederzeit wiederhergestellt werden. +- **Automatisierung:** Bei jedem Push wird der Code automatisch an den richtigen Ort kopiert. +- **Teamfähig:** Mehrere Personen können gleichzeitig am Projekt arbeiten. + +[!TIP] +Auch Einsteiger profitieren davon, weil sich der Deploy-Prozess auf ein einziges `git push` reduziert. + +### Schritt 1 – Git auf dem Webspace-Container installieren +Öffne die Konsole des Webspace-Containers in Proxmox oder verbinde dich per SSH. + +```bash +apt update && apt install -y git +``` + +👉 Screenshot geeignet: Konsole nach erfolgreicher Installation von Git + +### Schritt 2 – Verzeichnisstruktur für Deployments anlegen +Wir richten ein zentrales Verzeichnis für das Git-Repository und ein Zielverzeichnis für die Live-Webseite ein. + +```bash +mkdir -p /var/repo/webproject.git +mkdir -p /var/www/webproject +chown -R www-data:www-data /var/www/webproject +``` + +👉 Screenshot geeignet: Verzeichnisstruktur mit `ls -l /var/repo` und `/var/www` + +### Schritt 3 – Bare-Repository initialisieren +Ein „Bare-Repository“ ist ein Git-Repo ohne Arbeitskopie und dient als reines Ziel für Push-Vorgänge. + +```bash +git init --bare /var/repo/webproject.git +``` + +👉 Screenshot geeignet: Ausgabe von `git init --bare` + +### Schritt 4 – Automatisches Kopieren nach Push +Wir legen ein Hook-Skript an, das nach jedem Push die Inhalte in das Webverzeichnis kopiert. + +```bash +nano /var/repo/webproject.git/hooks/post-receive +``` + +Füge folgenden Inhalt ein: + +```bash +#!/bin/bash +GIT_WORK_TREE=/var/www/webproject git checkout -f +chown -R www-data:www-data /var/www/webproject +``` + +Datei speichern und ausführbar machen: + +```bash +chmod +x /var/repo/webproject.git/hooks/post-receive +``` + +### Schritt 5 – Lokales Projekt mit dem Repo verbinden +Auf deinem lokalen Rechner (z. B. Laptop oder PC, auf dem die Webseite entwickelt wird) führst du im Projektordner aus: + +```bash +git init +git remote add webspace ssh://@/var/repo/webproject.git +git add . +git commit -m "Erster Commit" +git push webspace master +``` + +Nach dem Push werden die Dateien automatisch in das Webverzeichnis kopiert und sind sofort online. + +[!TIP] +Nutze einen separaten Benutzer mit SSH-Zugriff ausschließlich für Deployments. +Dieser benötigt Schreibrechte auf `/var/repo`, nicht auf das ganze System. + +👉 Screenshot geeignet: Git-Push vom lokalen Rechner mit erfolgreicher Übertragung + +[!WARNING] +Stelle sicher, dass keine vertraulichen Dateien wie `.env` oder API-Schlüssel ins Repository gelangen. +Nutze `.gitignore`, um solche Dateien auszuschließen. + +Damit ist das Grundgerüst für automatisches Deployment per Git eingerichtet. +Im nächsten Schritt kümmern wir uns um die **Trennung von Staging- und Production-Umgebung**. + +## 2. Staging / Production-Trennung + +In professionellen Projekten ist es wichtig, neue Funktionen oder Updates zuerst in einer **Staging-Umgebung** zu testen, bevor sie für Besucher auf der **Production-Umgebung** sichtbar werden. +So vermeidest du Ausfälle oder fehlerhafte Seiten im Live-Betrieb. + +### Ziel der Trennung +- **Sichere Tests:** Änderungen lassen sich gefahrlos ausprobieren. +- **Keine Unterbrechung im Live-Betrieb:** Besucher sehen nur stabile, geprüfte Versionen. +- **Einfache Freigabe:** Nach erfolgreichem Test wird dieselbe Version auf Production übertragen. + +### Schritt 1 – Verzeichnisstruktur anlegen +Wir legen getrennte Verzeichnisse für Staging und Production an. + +```bash +mkdir -p /var/www/webproject-staging +mkdir -p /var/www/webproject-prod +chown -R www-data:www-data /var/www/webproject-* +``` + +👉 Screenshot geeignet: Anzeige der neuen Verzeichnisse mit `ls -l /var/www` + +### Schritt 2 – Subdomains für Staging und Production einrichten +Öffne den **Nginx Proxy Manager** und lege zwei Proxy-Hosts an: + +1. **Staging:** `staging.deinedomain.tld` → Ziel: `/var/www/webproject-staging` +2. **Production:** `www.deinedomain.tld` → Ziel: `/var/www/webproject-prod` + +Aktiviere für beide Einträge SSL und **Force SSL**. + +👉 Screenshot geeignet: NPM – Proxy-Host-Übersicht mit zwei Einträgen für Staging und Production + +### Schritt 3 – Git-Hooks für beide Umgebungen +Wir passen das Deployment so an, dass Pushes standardmäßig in Staging landen und nur freigegebene Versionen in Production kopiert werden. + +Erstelle zwei Bare-Repositories: + +```bash +mkdir -p /var/repo/webproject-staging.git +mkdir -p /var/repo/webproject-prod.git +git init --bare /var/repo/webproject-staging.git +git init --bare /var/repo/webproject-prod.git +``` + +👉 Screenshot geeignet: Ausgabe von `git init --bare` für beide Repos + +Für Staging-Repo das Hook-Skript: + +```bash +nano /var/repo/webproject-staging.git/hooks/post-receive +``` + +Inhalt: + +```bash +#!/bin/bash +GIT_WORK_TREE=/var/www/webproject-staging git checkout -f +chown -R www-data:www-data /var/www/webproject-staging +``` + +Für Production-Repo das Hook-Skript: + +```bash +nano /var/repo/webproject-prod.git/hooks/post-receive +``` + +Inhalt: + +```bash +#!/bin/bash +GIT_WORK_TREE=/var/www/webproject-prod git checkout -f +chown -R www-data:www-data /var/www/webproject-prod +``` + +Beide Skripte ausführbar machen: + +```bash +chmod +x /var/repo/webproject-*/hooks/post-receive +``` + +### Schritt 4 – Arbeitsweise im Team +- Standard-Pushes gehen an das **Staging-Repository**: + `git push staging master` +- Nach erfolgreichen Tests in Staging wird derselbe Code an das **Production-Repository** gepusht: + `git push production master` + +So bleibt Production immer stabil, und du hast gleichzeitig eine sichere Testumgebung. + +[!TIP] +Für die Arbeit im Team empfiehlt sich ein zentrales Remote-Repository (z. B. Gitea oder GitHub), von dem aus alle Entwickler arbeiten und von dem aus die Deployments an Staging und Production erfolgen. + +[!IMPORTANT] +Halte Staging und Production technisch identisch (gleiche PHP-Version, gleiche Module, gleiche Verzeichnisstruktur), damit Tests zuverlässig sind. + +### Schritt 1 – Weiterleitung in Apache aktivieren +Wir verwenden für jedes Projekt **eigene Apache-Konfigurationsdateien** – sowohl für Staging als auch für Production. +Die Konfigurationsdateien müssen **genau so benannt werden wie die zugehörigen Projektordner**, damit jederzeit klar ist, welche Datei zu welcher Seite gehört. +Beispiel: Für den Ordner `/var/www/webproject-prod` lautet die Konfigurationsdatei `webproject-prod.conf`. + +Öffne die Konfigurationsdatei für die Production-Seite: + +```bash +nano /etc/apache2/sites-available/webproject-prod.conf +``` + +Füge in den ``-Block folgende Zeilen ein: + +```apache +RewriteEngine On +RewriteCond %{HTTPS} off +RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] +``` + +Speichern und schließen. + +Aktiviere anschließend das Rewrite-Modul und die neue Konfiguration: + +```bash +a2enmod rewrite +a2ensite webproject-prod.conf +systemctl reload apache2 +``` + +👉 Screenshot geeignet: Apache-Konfigurationsdatei mit eingetragener Rewrite-Regel + +Wiederhole denselben Vorgang für Staging: + +```bash +nano /etc/apache2/sites-available/webproject-staging.conf +``` + +Die Rewrite-Regel ist identisch. Danach ebenfalls aktivieren: + +```bash +a2ensite webproject-staging.conf +systemctl reload apache2 +``` + +## 4. Multi-Site-Hosting + +Mit Multi-Site-Hosting kannst du auf demselben Webspace-Container mehrere voneinander unabhängige Webseiten betreiben. +Jede Seite erhält ihren eigenen Projektordner, ihre eigene Apache-Konfigurationsdatei und eine eigene Subdomain. +So lassen sich z. B. ein Portfolio, ein Shop und eine Event-Seite getrennt verwalten, ohne zusätzliche Container zu erstellen. + +### Schritt 1 – Verzeichnisstruktur für neue Projekte anlegen +Lege für jede neue Seite einen eigenen Ordner unter `/var/www/` an. +Der Ordnername muss exakt dem Projektnamen entsprechen, um die Zuordnung zu erleichtern. + +Beispiel für zwei weitere Projekte: + +```bash +mkdir -p /var/www/shop-prod +mkdir -p /var/www/blog-prod +chown -R www-data:www-data /var/www/shop-prod /var/www/blog-prod +``` + +👉 Screenshot geeignet: Anzeige der neuen Projektordner mit `ls -l /var/www` + +### Schritt 2 – Apache-Konfiguration für jedes Projekt +Erstelle für jedes Projekt eine eigene Konfigurationsdatei im Verzeichnis `/etc/apache2/sites-available/`. +Die Dateinamen müssen identisch zu den Projektordnern sein. + +Für den Shop: + +```bash +nano /etc/apache2/sites-available/shop-prod.conf +``` + +Beispielinhalt: + +```apache + + ServerName shop.deinedomain.tld + DocumentRoot /var/www/shop-prod + RewriteEngine On + RewriteCond %{HTTPS} off + RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] + +``` + +Für den Blog: + +```bash +nano /etc/apache2/sites-available/blog-prod.conf +``` + +Beispielinhalt: + +```apache + + ServerName blog.deinedomain.tld + DocumentRoot /var/www/blog-prod + RewriteEngine On + RewriteCond %{HTTPS} off + RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] + +``` + +Speichern und schließen. +Anschließend beide Seiten aktivieren und Apache neu laden: + +```bash +a2ensite shop-prod.conf +a2ensite blog-prod.conf +systemctl reload apache2 +``` + +👉 Screenshot geeignet: Aktivierte Sites mit `apache2ctl -S` + +### Schritt 3 – Subdomains im Nginx Proxy Manager anlegen +Öffne den Nginx Proxy Manager und lege für jede neue Seite einen eigenen Proxy-Host an: + +- `shop.deinedomain.tld` → IP des Webspace-Containers → Port 80 +- `blog.deinedomain.tld` → IP des Webspace-Containers → Port 80 + +Für alle Einträge **Force SSL** aktivieren und Zertifikate anfordern. + +👉 Screenshot geeignet: NPM-Übersicht mit mehreren Subdomains für Shop und Blog + +[!IMPORTANT] +Jede neue Seite benötigt einen eigenen Projektordner, eine eigene `.conf`-Datei und eine eigene Subdomain. +Diese klare Trennung verhindert Konflikte und erleichtert Wartung und Sicherheit. + +## 5. CDN-Integration + +Ein **Content Delivery Network (CDN)** beschleunigt die Auslieferung von statischen Dateien wie Bildern, CSS- und JavaScript-Dateien. +Gerade bei internationalen Besuchern oder grafiklastigen Projekten verbessert ein CDN die Ladezeiten erheblich und entlastet den eigenen Webspace-Container. + +### Ziel der Integration +- **Schnellere Ladezeiten:** Dateien werden über weltweit verteilte Server ausgeliefert. +- **Weniger Serverlast:** Der Webspace muss weniger Daten direkt bereitstellen. +- **Bessere Nutzererfahrung:** Besucher erleben kürzere Ladezeiten und stabilere Performance. + +### Schritt 1 – Geeigneten CDN-Anbieter wählen +Für die meisten Projekte reicht ein kostenloser Dienst wie **Cloudflare CDN**, der statische Inhalte zwischenspeichert und gleichzeitig DDoS-Schutz bietet. +Wer nur Bilder und Videos optimieren möchte, kann auch **Bunny CDN** oder ähnliche Dienste nutzen. + +[!TIP] +Cloudflare ist für die meisten Einsteiger ideal, da es leicht einzurichten ist und viele Basisfunktionen kostenfrei bereitstellt. + +### Schritt 2 – DNS auf das CDN umstellen +Melde dich beim gewählten CDN-Anbieter an und folge dem dortigen Einrichtungsassistenten. +In der Regel ersetzt der Anbieter die Nameserver deiner Domain durch eigene (z. B. bei Cloudflare). +Nach der Umstellung laufen alle Anfragen automatisch über das CDN. + +👉 Screenshot geeignet: Cloudflare-Dashboard mit aktivierten CDN- und SSL-Optionen + +### Schritt 3 – HTTPS und Weiterleitungen prüfen +Da alle Aufrufe künftig über das CDN gehen, prüfe anschließend die HTTPS-Einstellungen: + +- Im CDN-Dashboard **„Always Use HTTPS“** aktivieren +- Sicherstellen, dass im Nginx Proxy Manager weiterhin **Force SSL** aktiv ist +- Testen, ob die Seiten weiterhin automatisch auf `https://` umleiten und ein gültiges Zertifikat anzeigen + +### Schritt 4 – Caching und Performance optimieren +Passe im CDN die Caching-Regeln für statische Dateien an, z. B.: + +- HTML-Dateien: kurze Cache-Dauer (z. B. 10 Minuten) +- Bilder, CSS, JS: lange Cache-Dauer (z. B. 1 Monat) + +Damit werden Änderungen an der Seite zeitnah sichtbar, während selten geänderte Dateien länger im Cache bleiben. + +👉 Screenshot geeignet: CDN-Einstellungen für Cache-Dauer + +[!IMPORTANT] +Nach jeder Layout- oder Inhaltsänderung ggf. den CDN-Cache leeren („Purge Cache“), damit Besucher sofort die aktuelle Version der Webseite sehen. + +## 6. Sicherheitsmaßnahmen + +Sicherheit ist ein zentraler Faktor für jeden öffentlich zugänglichen Webspace. +Gerade wenn du CMS, Shops oder Logins anbietest, müssen die Grundfunktionen des Servers gut abgesichert sein. +Wir ergänzen deshalb einige wichtige Maßnahmen direkt auf System- und Webserver-Ebene. + +### Ziel der Maßnahmen +- **Schutz sensibler Bereiche:** Admin-Logins, Konfigurationsdateien und Datenverzeichnisse vor unbefugtem Zugriff schützen +- **Reduzierung der Angriffsfläche:** Nur benötigte Dienste offenhalten und unnötige Funktionen deaktivieren +- **Bessere Serverhärtung:** Typische Schwachstellen von Apache und PHP absichern + +### Schritt 1 – Zugriff auf den Admin-Bereich absichern + +Viele Angriffe auf Webseiten zielen direkt auf den Admin-Login. +Wir legen daher eine zusätzliche Passwort-Abfrage **vor** den eigentlichen Login – so können Unbefugte die Login-Seite gar nicht erst sehen. + +#### 1) Zusatzmodul für Passwortschutz installieren +Öffne die Konsole des Webspace-Containers: + +```bash +apt install -y apache2-utils +``` + +Dieses kleine Zusatzpaket bringt das Werkzeug `htpasswd` mit, das wir für die Passwortdatei brauchen. + +👉 Screenshot geeignet: Konsole nach erfolgreicher Installation von `apache2-utils` + +#### 2) Passwortdatei anlegen +Lege eine zentrale Passwortdatei für den Schutz an. +Wir speichern sie unter `/etc/apache2/.htpasswd`: + +```bash +htpasswd -c /etc/apache2/.htpasswd adminuser +``` + +Du wirst aufgefordert, ein Passwort einzugeben. +Verwende ein **langes, starkes Passwort** und notiere es in **Vaultwarden** (Kapitel 5). +Dieser Benutzername und dieses Passwort werden künftig beim Aufruf des Admin-Bereichs abgefragt. + +👉 Screenshot geeignet: Konsole während der Passwort-Eingabe + +#### 3) Apache-Konfiguration anpassen +Öffne die Konfigurationsdatei deiner Produktiv-Seite. +Dateiname und Ordner müssen übereinstimmen: + +```bash +nano /etc/apache2/sites-available/webproject-prod.conf +``` + +Scrolle zum Ende des ``-Blocks und füge den folgenden Abschnitt **direkt vor der schließenden Klammer** `` ein: + +```apache + + AuthType Basic + AuthName "Geschützter Bereich" + AuthUserFile /etc/apache2/.htpasswd + Require valid-user + +``` + +Speichern und schließen. + +👉 Screenshot geeignet: Apache-Konfigurationsausschnitt mit hinzugefügtem Passwort-Block + +#### 4) Apache neu laden +Die Änderung aktivieren wir mit: + +```bash +systemctl reload apache2 +``` + +#### 5) Testen +Rufe jetzt im Browser die Admin-Seite auf, zum Beispiel +`https://www.deinedomain.tld/wp-admin` + +Es sollte **vor dem eigentlichen CMS-Login** ein kleines Fenster erscheinen, das Benutzername und Passwort verlangt. +Erst danach erscheint die übliche Login-Maske von WordPress oder deinem CMS. + +👉 Screenshot geeignet: Browser-Fenster mit vorgeschalteter Passwort-Abfrage + +[!TIP] +Nutze für diesen Zugang ein starkes Passwort (mindestens 16 Zeichen) und speichere es sicher in Vaultwarden. +Gib es nur den Personen weiter, die auch wirklich Zugang zum Admin-Bereich brauchen. + +### Schritt 2 – Verzeichnislisting deaktivieren + +Standardmäßig zeigt Apache den Inhalt eines Ordners an, wenn dort keine `index.html` oder `index.php` liegt. +Das ist nicht nur unschön, sondern kann auch sensible Dateien sichtbar machen. +Wir schalten diese Funktion vollständig ab. + +#### 1) Apache-Hauptkonfiguration öffnen +Öffne die Konfigurationsdatei: + +```bash +nano /etc/apache2/apache2.conf +``` + +#### 2) „Indexes“ entfernen +Suche nach Einträgen wie: + +```apache +Options Indexes FollowSymLinks +``` + +Entferne **`Indexes`**, sodass nur noch steht: + +```apache +Options FollowSymLinks +``` + +Speichern und die Datei schließen. + +👉 Screenshot geeignet: geänderte Options-Zeile ohne „Indexes“ + +#### 3) Apache neu laden +Übernimm die Änderung: + +```bash +systemctl reload apache2 +``` + +#### 4) Testen +Rufe im Browser ein Verzeichnis auf, in dem keine Startseite liegt, z. B.: +`https://www.deinedomain.tld/testordner` + +Es darf jetzt keine Dateiliste erscheinen. +Stattdessen sollte ein Fehler 403 („Forbidden“) angezeigt werden. + +👉 Screenshot geeignet: Browser mit 403-Meldung statt Verzeichnislisting + +### Schritt 3 – PHP-Konfiguration härten + +Einige Standard-Einstellungen von PHP sind für die Produktion nicht optimal. +Wir passen sie an, um unnötige Informationen zu verbergen und sichere Limits zu setzen. + +#### 1) PHP-Konfigurationsdatei öffnen +Die Version kann leicht abweichen (z. B. 8.2 oder 8.3). +Finde die passende Datei und öffne sie: + +```bash +nano /etc/php/8.2/apache2/php.ini +``` + +#### 2) Folgende Werte ändern oder hinzufügen +Suche die betreffenden Zeilen und stelle sicher, dass sie wie folgt gesetzt sind: + +``` +expose_php = Off +display_errors = Off +file_uploads = On +upload_max_filesize = 64M +post_max_size = 64M +memory_limit = 256M +``` + +- `expose_php = Off` verhindert, dass der Server seine PHP-Version preisgibt. +- `display_errors = Off` blendet interne Fehlerausgaben im Browser aus. +- Die Upload- und Speicherlimits sind praxisgerechte Startwerte für Medieninhalte. + +Speichern und schließen. + +👉 Screenshot geeignet: bearbeitete php.ini mit den geänderten Zeilen + +#### 3) Apache neu starten +Damit die Änderungen aktiv werden: + +```bash +systemctl restart apache2 +``` + +### Schritt 4 – Firewall aktivieren + +Wir schützen den Webspace-Container zusätzlich mit einer einfachen Firewall, die nur die notwendigen Ports offenlässt. + +#### 1) UFW installieren +Öffne die Konsole des Webspace-Containers: + +```bash +apt install -y ufw +``` + +#### 2) Standardregeln setzen +Blockiere eingehenden Verkehr und erlaube nur das Nötigste: + +```bash +ufw default deny incoming +ufw default allow outgoing +ufw allow 22 +ufw allow 80 +ufw allow 443 +``` + +👉 Screenshot geeignet: Konsole mit den gesetzten UFW-Regeln + +#### 3) Firewall aktivieren +Schalte UFW ein: + +```bash +ufw enable +ufw status +``` + +👉 Screenshot geeignet: Konsolenanzeige der aktiven Firewall mit erlaubten Ports + +[!TIP] +Port 22 (SSH) nur geöffnet lassen, wenn du ihn für Wartung oder Deployment brauchst. +Falls nicht benötigt, nach der Einrichtung wieder sperren oder auf einen anderen Port legen. + +## 7. CMS-Installation vorbereiten (Beispiel: WordPress) + +Viele Content-Creator möchten auf ihrem Webspace nicht nur statische Seiten, sondern auch Blogs, Shops oder ein Portfolio betreiben. +Dafür ist **WordPress** besonders geeignet: Es ist kostenlos, einfach zu bedienen, lässt sich flexibel erweitern und hat eine riesige Auswahl an Themes und Plugins. +Damit kannst du deinen Webspace ohne Programmierkenntnisse zu einer vollwertigen Website, einem Shop oder einer Community-Plattform ausbauen. + +In diesem Abschnitt bereiten wir die Installation von WordPress vor und führen dich bis zu dem Punkt, an dem der grafische Einrichtungs-Assistent im Browser startet. + +## Schritt 1 – Benötigte Software installieren + +WordPress benötigt eine **Datenbank** und ein paar zusätzliche PHP-Module, die in der Free-Installation noch nicht enthalten sind. +Öffne die **Konsole des Webspace-Containers** (z. B. in Proxmox oder per SSH) und gib ein: + +```bash +apt update +apt install -y php-mysql mariadb-server unzip +``` + +- `php-mysql` stellt die Verbindung zwischen PHP und der Datenbank her +- `mariadb-server` ist die eigentliche MySQL-kompatible Datenbank +- `unzip` wird gebraucht, um das WordPress-Archiv zu entpacken + +👉 Screenshot geeignet: Konsole nach der erfolgreichen Installation dieser Pakete + +[!TIP] +Die Installation dauert in der Regel nur wenige Sekunden. +Sollte eine Fehlermeldung erscheinen, überprüfe die Internetverbindung des Containers. + +## Schritt 2 – Datenbank für WordPress anlegen + +Jede WordPress-Installation benötigt eine eigene Datenbank. +Wir legen diese über die Kommandozeile an – du musst nur die Befehle kopieren und ausführen. + +1) Öffne den Datenbank-Client von MariaDB: + +```bash +mysql -u root +``` + +2) Gib im Eingabeprompt nacheinander folgende Befehle ein (ersetze die Platzhalter durch eigene Werte): + +```sql +CREATE DATABASE wordpress_db; +CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'EinSicheresPasswort123!'; +GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost'; +FLUSH PRIVILEGES; +EXIT; +``` + +- `wordpress_db` ist der Name der neuen Datenbank +- `wp_user` ist der Benutzername für WordPress +- `EinSicheresPasswort123!` bitte durch ein eigenes, starkes Passwort ersetzen und in **Vaultwarden** speichern + +👉 Screenshot geeignet: Konsole mit angelegter Datenbank und Benutzerrechten + +[!IMPORTANT] +Wähle ein langes, starkes Passwort mit Groß-/Kleinbuchstaben, Zahlen und Sonderzeichen. + +## Schritt 3 – WordPress herunterladen und entpacken + +Lade nun WordPress in den Ordner der Live-Seite (Production) und entpacke es: + +```bash +cd /var/www/webproject-prod +wget https://wordpress.org/latest.zip +unzip latest.zip +mv wordpress/* . +rm -rf wordpress latest.zip +chown -R www-data:www-data /var/www/webproject-prod +``` + +Erklärung der Befehle: +- `wget` lädt die aktuelle WordPress-Version herunter +- `unzip` entpackt die ZIP-Datei +- `mv wordpress/* .` verschiebt die Dateien in den Projektordner +- `rm -rf …` entfernt die leeren Ordner und die ZIP-Datei +- `chown …` sorgt dafür, dass der Webserver Zugriff auf alle Dateien hat + +👉 Screenshot geeignet: Konsole nach dem Entpacken und Verschieben der Dateien + +## Schritt 4 – Grafischen Installations-Assistenten starten + +1) Öffne deinen Browser und rufe die Domain auf, z. B.: +``` +https://www.deinedomain.tld +``` + +2) Du wirst automatisch zum **Setup-Assistenten von WordPress** weitergeleitet. +Trage hier die zuvor angelegten Datenbank-Daten ein: + +- Datenbank-Name: `wordpress_db` +- Benutzer: `wp_user` +- Passwort: dein sicheres Passwort aus Vaultwarden +- Datenbank-Host: `localhost` +- Tabellen-Präfix: Standardwert `wp_` kann so bleiben + +3) Danach vergibst du einen **Seitentitel**, einen **Admin-Benutzer** und ein starkes **Admin-Passwort** für den Login ins WordPress-Dashboard. + +👉 Screenshot geeignet: Setup-Seite von WordPress mit Formular für die Datenbank-Einstellungen + +[!TIP] +Speichere das Admin-Passwort ebenfalls sicher in Vaultwarden. + +4) Schließe die Einrichtung ab. +Anschließend kannst du dich sofort mit den neuen Admin-Zugangsdaten im WordPress-Dashboard anmelden. + +👉 Screenshot geeignet: WordPress-Dashboard nach erfolgreicher Installation + +Nach diesen Schritten ist WordPress einsatzbereit. +Du kannst Themes installieren, Plugins hinzufügen oder den Shop-Bereich mit WooCommerce aktivieren. +In diesem Premium-Kapitel beschränken wir uns auf die Grundinstallation. +Design-Anpassungen und Plugins werden in einem eigenen Kapitel behandelt. + +## 8. Automatische System-Updates einrichten + +Ein Webspace ist nur so sicher wie seine Software. +Damit Sicherheitslücken in Apache, PHP oder Debian nicht lange offenbleiben, lassen wir den Container selbständig täglich nach Updates suchen und diese automatisch installieren. +So musst du nicht ständig selbst daran denken und bist dennoch immer auf dem neuesten Stand. + +### Schritt 1 – Zusatzpaket installieren +Öffne die Konsole des Webspace-Containers in Proxmox oder per SSH. +Dort installierst du das Update-Werkzeug mit: + +```bash +apt update +apt install -y unattended-upgrades +``` + +👉 Screenshot geeignet: Konsole nach erfolgreicher Installation von `unattended-upgrades` + +Dieses kleine Programm sorgt später dafür, dass der Container automatisch Sicherheits-Updates bezieht. + +### Schritt 2 – Automatische Updates aktivieren +Starte nun die Einrichtung: + +```bash +dpkg-reconfigure --priority=low unattended-upgrades +``` + +Der Assistent fragt, ob Sicherheits-Updates künftig automatisch installiert werden sollen. +Wähle **„Yes“** und bestätige. +Damit sind die täglichen Updates eingeschaltet. + +👉 Screenshot geeignet: Bildschirmfoto des Dialogfensters mit aktivierter Option „automatische Updates“ + +### Schritt 3 – Funktion testen +Wir prüfen einmal, ob alles korrekt funktioniert: + +```bash +unattended-upgrade --dry-run --debug +``` + +Die Ausgabe zeigt an, welche Pakete bei einem echten Lauf aktualisiert würden. +Wenn hier keine Fehlermeldung auftaucht, ist das System bereit. + +👉 Screenshot geeignet: Konsole mit erfolgreicher Testausgabe + +[!TIP] +Die automatischen Updates laufen künftig einmal täglich im Hintergrund. +Kontrolliere den Container trotzdem etwa einmal im Monat manuell mit: + +```bash +apt update && apt upgrade +``` + +So stellst du sicher, dass auch größere Versionssprünge (z. B. neue PHP-Versionen) rechtzeitig bemerkt werden und du gegebenenfalls Anpassungen in den Webseiten vornehmen kannst. + +## Zusammenfassung + +In diesem Kapitel hast du deinen Webspace von einem einfachen LXC-Container zu einer **vollwertigen und professionellen Hosting-Umgebung** ausgebaut. +Die Anleitung richtet sich an Content-Creator und Einsteiger, die ohne teure externe Hoster eigene Webseiten betreiben wollen – egal ob Blog, Shop oder Portfolio. + +### Dein Weg durch das Kapitel + +Wir haben zuerst die **Basisfunktionen für fortgeschrittene Projekte** eingerichtet: + +- **Auto-Deployment via Git**: Für statische Projekte oder selbst geschriebene Websites kannst du alle Änderungen direkt aus deinem Git-Repository übernehmen, ohne Dateien manuell hochzuladen. + [!IMPORTANT] + Dieser Workflow eignet sich **nicht für CMS wie WordPress**, da dort Inhalte und Uploads dynamisch in der Datenbank gespeichert werden. + Für WordPress bleibst du beim klassischen Upload oder bei den eingebauten Update-Funktionen des CMS. + +- Mit der **Staging- und Produktionsumgebung** kannst du neue Designs, Funktionen oder Code zuerst auf einer Test-Seite prüfen und erst dann auf die Live-Seite übernehmen. + Das schützt deine Besucher vor fehlerhaften Updates und erleichtert die Wartung größerer Projekte. + +- Dank der erzwungenen **HTTPS-Weiterleitungen** läuft jede Verbindung verschlüsselt und wird automatisch auf die sichere Adresse umgeleitet. + +Danach haben wir den Webspace so vorbereitet, dass er nicht auf ein einzelnes Projekt beschränkt ist: + +- Über das **Multi-Site-Hosting** kannst du mehrere Domains und Webseiten parallel auf demselben Container betreiben. + Das spart Ressourcen und ermöglicht es dir, z. B. Blog, Shop und Portfolio getrennt, aber auf derselben Infrastruktur zu verwalten. + +- Mit der **CDN-Integration** (z. B. Cloudflare) werden statische Dateien wie Bilder, CSS und JavaScript-Dateien von einem weltweiten Servernetz ausgeliefert. + Besucher erhalten die Inhalte schneller, und dein Container wird entlastet. + +Wir haben außerdem die **Sicherheitsmaßnahmen** verbessert: + +- Die **Admin-Bereiche** deiner Webseiten sind durch eine vorgeschaltete Passwortabfrage geschützt. + So können Angreifer die Login-Maske nicht mehr direkt aufrufen. + +- Das **Verzeichnislisting** wurde abgeschaltet, damit niemand die Dateistruktur deiner Website auslesen kann. + +- Die **PHP-Konfiguration** ist gehärtet und zeigt weder interne Fehlermeldungen noch die PHP-Version an. + +- Die **Firewall (UFW)** lässt nur die Ports 80 (HTTP), 443 (HTTPS) und optional 22 (SSH) offen und blockiert alles andere. + +Als Beispiel-CMS haben wir **WordPress** installiert: + +- Du hast gelernt, die nötige Software nachzuinstallieren, eine eigene Datenbank einzurichten und den grafischen Setup-Assistenten im Browser auszuführen. + Damit hast du eine komfortable Grundlage für Blogs, Shops oder Portfolios. + +Zum Schluss haben wir den laufenden Betrieb abgesichert: + +- Mit den **automatischen System-Updates** für Debian, Apache und PHP werden Sicherheitslücken zeitnah geschlossen, ohne dass du manuell eingreifen musst. + +### Was du jetzt erreicht hast + +Dein Webspace ist nun **stabil, sicher und vielseitig nutzbar**: + +- Du kannst mehrere Projekte und Domains auf demselben Container betreiben. +- Webseiten laufen verschlüsselt über HTTPS und werden durch ein CDN schneller geladen. +- Sicherheitsmaßnahmen und automatische Updates reduzieren Risiken und Wartungsaufwand. +- Für dynamische CMS-Seiten wie WordPress nutzt du den eingebauten Update-Mechanismus des CMS. +- Für statische Projekte steht dir ein professioneller Git-Workflow zur Verfügung. + +[!TIP] +Lege regelmäßige **Backups** an (siehe Kapitel 8 – Archiv), besonders wenn du mit CMS arbeitest. +Nur ein funktionierendes Backup schützt dich zuverlässig vor Datenverlust bei Plugin-Fehlern oder Experimenten. + +[!IMPORTANT] +Teste größere Änderungen stets zuerst in der **Staging-Umgebung**. +So verhinderst du, dass ein fehlerhaftes Update deine Live-Seite lahmlegt. + +### Ausblick + +In späteren Kapiteln beschäftigen wir uns mit: +- der **Gestaltung und Themes** für WordPress und andere CMS, +- der Installation wichtiger **Plugins** (z. B. SEO, Performance, E-Commerce, Sicherheit), +- sowie weiteren Automatisierungen, die dir Arbeit abnehmen und deine Online-Präsenz noch professioneller machen. + +Mit diesem Kapitel hast du die Grundlage geschaffen, um **selbstbestimmt und unabhängig** Webseiten zu betreiben – egal ob klassisch per Git bereitgestellt oder dynamisch mit einem CMS wie WordPress. \ No newline at end of file