Kapitel 09/Premium Rohtext.md aktualisiert
This commit is contained in:
862
Kapitel 09/Premium Rohtext.md
Normal file
862
Kapitel 09/Premium Rohtext.md
Normal file
@@ -0,0 +1,862 @@
|
||||
## 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. Statische Inhalte beschleunigen
|
||||
|
||||
Statische Inhalte wie Bilder, CSS- und JavaScript-Dateien ändern sich selten, werden aber bei jedem Seitenaufruf neu vom Server geladen.
|
||||
Damit diese Dateien schneller ausgeliefert werden und den Webspace-Container nicht unnötig belasten, richten wir ein **lokales Caching** ein.
|
||||
Für größere Projekte mit sehr vielen Medien empfehlen wir später den Einsatz eines eigenen **Asset-LXC** (siehe Kapitel 12).
|
||||
|
||||
### Schritt 1 – Cache-Module aktivieren
|
||||
Öffne die Konsole des Webspace-Containers und installiere die benötigten Apache-Module:
|
||||
|
||||
```bash
|
||||
apt update
|
||||
apt install -y libapache2-mod-cache libapache2-mod-cache-disk libapache2-mod-deflate
|
||||
a2enmod cache cache_disk deflate expires headers
|
||||
systemctl restart apache2
|
||||
```
|
||||
|
||||
👉 Screenshot geeignet: Konsole nach erfolgreicher Installation und Aktivierung der Module
|
||||
|
||||
Diese Module sorgen dafür, dass häufig verwendete Dateien zwischengespeichert und komprimiert übertragen werden.
|
||||
|
||||
### Schritt 2 – Cache-Regeln für statische Dateien einrichten
|
||||
Öffne die Konfigurationsdatei deiner Live-Seite, z. B.:
|
||||
|
||||
```bash
|
||||
nano /etc/apache2/sites-available/webproject-prod.conf
|
||||
```
|
||||
|
||||
Füge innerhalb des `<VirtualHost *:80>`-Blocks vor `</VirtualHost>` Folgendes hinzu:
|
||||
|
||||
```apache
|
||||
<IfModule mod_expires.c>
|
||||
ExpiresActive On
|
||||
ExpiresByType image/jpg "access plus 1 month"
|
||||
ExpiresByType image/jpeg "access plus 1 month"
|
||||
ExpiresByType image/png "access plus 1 month"
|
||||
ExpiresByType image/gif "access plus 1 month"
|
||||
ExpiresByType text/css "access plus 1 month"
|
||||
ExpiresByType application/javascript "access plus 1 month"
|
||||
</IfModule>
|
||||
|
||||
<IfModule mod_headers.c>
|
||||
Header set Cache-Control "public, max-age=2592000"
|
||||
</IfModule>
|
||||
```
|
||||
|
||||
👉 Screenshot geeignet: geöffnete Apache-Konfigurationsdatei mit eingefügten Cache-Regeln
|
||||
|
||||
Die Regeln teilen Browsern und Apache mit, dass Bilder und Skripte bis zu 30 Tage lang aus dem Cache geladen werden dürfen.
|
||||
|
||||
### Schritt 3 – Apache neu laden
|
||||
Übernimm die Änderungen mit:
|
||||
|
||||
```bash
|
||||
systemctl reload apache2
|
||||
```
|
||||
|
||||
👉 Screenshot geeignet: Konsole nach erfolgreichem Reload
|
||||
|
||||
### Schritt 4 – Funktion prüfen
|
||||
Öffne die Entwicklertools deines Browsers (F12 → Netzwerk-Tab) und lade die Seite neu.
|
||||
Bei den statischen Dateien sollte nun ein Cache-Header mit Ablaufdatum angezeigt werden.
|
||||
|
||||
👉 Screenshot geeignet: Browser-Netzwerkanzeige mit Cache-Headern für Bilder und CSS
|
||||
|
||||
[!TIP]
|
||||
Wenn du eine Datei ersetzt und die Änderung sofort sichtbar sein soll, leere den Browser-Cache mit **Strg + F5**.
|
||||
Falls nötig, kannst du auch den Apache-Cache im Container löschen:
|
||||
|
||||
```bash
|
||||
rm -rf /var/cache/apache2/*
|
||||
```
|
||||
|
||||
Für wachsende Projekte mit vielen Medieninhalten lohnt sich ein eigener **Asset-LXC**.
|
||||
Damit werden große Dateien separat ausgeliefert, die Performance steigt und der Webspace-Container wird entlastet.
|
||||
Die Einrichtung eines solchen Asset-Containers behandeln wir ausführlich in **Kapitel 12**.
|
||||
|
||||
## 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