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