Kapitel 9/Premium Rohtext.md hinzugefügt
This commit is contained in:
830
Kapitel 9/Premium Rohtext.md
Normal file
830
Kapitel 9/Premium Rohtext.md
Normal file
@@ -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://<USER>@<SERVER-IP>/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 `<VirtualHost *:80>`-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
|
||||||
|
<VirtualHost *:80>
|
||||||
|
ServerName shop.deinedomain.tld
|
||||||
|
DocumentRoot /var/www/shop-prod
|
||||||
|
RewriteEngine On
|
||||||
|
RewriteCond %{HTTPS} off
|
||||||
|
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
|
||||||
|
</VirtualHost>
|
||||||
|
```
|
||||||
|
|
||||||
|
Für den Blog:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
nano /etc/apache2/sites-available/blog-prod.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
Beispielinhalt:
|
||||||
|
|
||||||
|
```apache
|
||||||
|
<VirtualHost *:80>
|
||||||
|
ServerName blog.deinedomain.tld
|
||||||
|
DocumentRoot /var/www/blog-prod
|
||||||
|
RewriteEngine On
|
||||||
|
RewriteCond %{HTTPS} off
|
||||||
|
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
|
||||||
|
</VirtualHost>
|
||||||
|
```
|
||||||
|
|
||||||
|
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 `<VirtualHost *:80>`-Blocks und füge den folgenden Abschnitt **direkt vor der schließenden Klammer** `</VirtualHost>` ein:
|
||||||
|
|
||||||
|
```apache
|
||||||
|
<Directory "/var/www/webproject-prod/wp-admin">
|
||||||
|
AuthType Basic
|
||||||
|
AuthName "Geschützter Bereich"
|
||||||
|
AuthUserFile /etc/apache2/.htpasswd
|
||||||
|
Require valid-user
|
||||||
|
</Directory>
|
||||||
|
```
|
||||||
|
|
||||||
|
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.
|
||||||
Reference in New Issue
Block a user