Homelab--Bratonein-Kontrollzentrum--Tutorial/Kapitel 9/Premium Rohtext.md

## 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.