Admin am 25. Februar 2026 um 19:47 Uhr

2026-02-25T19:47:48Z

@@ Zeile 60: / Zeile 60: @@
 * [ ] '''OPcache Flush:''' Nach jedem Deployment `php_cache_clear()` oder Neustart der CGI-Instanz erzwingen (via bplaced Panel oder Wrapper-Touch).
 * [ ] '''Logs:''' Regelmäßige Rotation der `php_access_logfile` und Framework-Logs, da Quota-Überschreitungen zum Systemstopp führen.
 [[Kategorie:Hosting-Architektur]] [[Kategorie:PHP-Administration]]

Admin: Die Seite wurde neu angelegt: „TOC == Infrastruktur-Analyse: bplaced für Professional Hosting == === 1. Architektur & System-Design === bplaced nutzt eine '''verteilte Shared-Hosting-Architektur'''. Im Gegensatz zu monolithischen Systemen sind Web-Server (Apache), Datenbank-Server (MariaDB/PostgreSQL) und Storage-Server physisch getrennt. * '''Cluster-Logik:''' User werden auf spezifische Server-Cluster (z.B. server6, server12) verteilt. Dies ist bei der Konfiguration von Daten…“

2026-02-25T19:34:24Z

Die Seite wurde neu angelegt: „__TOC__ == Infrastruktur-Analyse: bplaced für Professional Hosting == === 1. Architektur & System-Design === bplaced nutzt eine '''verteilte Shared-Hosting-Architektur'''. Im Gegensatz zu monolithischen Systemen sind Web-Server (Apache), Datenbank-Server (MariaDB/PostgreSQL) und Storage-Server physisch getrennt. * '''Cluster-Logik:''' User werden auf spezifische Server-Cluster (z.B. server6, server12) verteilt. Dies ist bei der Konfiguration von Daten…“

Neue Seite

__TOC__

== Infrastruktur-Analyse: bplaced für Professional Hosting ==

=== 1. Architektur & System-Design ===
bplaced nutzt eine '''verteilte Shared-Hosting-Architektur'''. Im Gegensatz zu monolithischen Systemen sind Web-Server (Apache), Datenbank-Server (MariaDB/PostgreSQL) und Storage-Server physisch getrennt.

* '''Cluster-Logik:''' User werden auf spezifische Server-Cluster (z.B. server6, server12) verteilt. Dies ist bei der Konfiguration von Datenbank-Hosts (oft `localhost`, aber bei externen Zugriffen der Cluster-Name) zu beachten.
* '''Storage-Backend:''' Die Speicherung erfolgt oft über Netzwerk-Dateisysteme. Dies bedeutet eine leicht erhöhte Latenz bei Dateizugriffen (I/O), was Caching-Mechanismen (Redis/OPcache) für Frameworks wie Symfony oder Shopware essenziell macht.

=== 2. PHP-Runtime & Prozess-Management ===
Die PHP-Execution erfolgt primär über '''FastCGI'''. Dies ermöglicht eine saubere Trennung der User-Berechtigungen, bringt aber Besonderheiten im Prozess-Handling mit sich.

==== Memory & Execution Limits ====
In professionellen Umgebungen stoßen Symfony-Commands oft an die Standard-Limits.
* '''CLI-Override:''' Via Wrapper-Script können `memory_limit` und `max_execution_time` oft höher gesetzt werden als im Web-Kontext.
* '''Zustandslosigkeit:''' Da Prozesse nach Timeouts hart beendet werden, sollten Long-Running-Tasks (wie Mail-Abruf oder Massen-Indizierung) in kleine Batches unterteilt werden.

==== Erweiterte Modul-Verfügbarkeit ====
Viele für Enterprise-Systeme kritische Module sind vorhanden, müssen aber oft manuell adressiert werden:
* '''Mailparse & IMAP:''' Essenziell für Ticket-Systeme (UVdesk). Pfade liegen oft unter `/usr/share/php[Version]/ext/`.
* '''BCMath & Intl:''' Meist standardmäßig aktiv, für E-Commerce (Preiskalkulationen) unverzichtbar.

=== 3. Sicherheit & Zugriffskontrolle ===

==== Open_basedir & Symlink-Sicherheit ====
Das `open_basedir`-Konzept ist bei bplaced sehr strikt.
* '''Problem:''' Frameworks, die mit Symlinks arbeiten (z.B. `public/storage`), scheitern, wenn der Zielpfad nicht explizit in der `open_basedir`-Variable der PHP-Konfiguration enthalten ist.
* '''Fix:''' Der PHP-Wrapper muss dynamisch die Pfade des aktuellen Release-Ordners inkludieren (besonders bei Atomic Deployments).

==== SSL/TLS Handling ====
bplaced integriert Let's Encrypt. Profi-Tipp: Symfony-Apps hinter dem bplaced-Proxy benötigen oft die Konfiguration von `Trusted Proxies`, damit `isSecure()` und Redirects auf HTTPS korrekt funktionieren.

=== 4. Netzwerk-Restriktionen & Mail-Ökosystem ===

==== Socket-Verbindungen (Die "Free"-Barriere) ====
Einer der größten Fallstricke für Profi-Systeme:
* '''Outbound Traffic:''' Verbindungen zu externen APIs (Stripe, PayPal, Mailgun) oder Mail-Servern (IMAP/SMTP) sind in der Basis-Version oft limitiert oder gesperrt.
* '''Lösung:''' Upgrade auf bplaced Pro/Business schaltet Sockets frei. Ohne diese bleiben Mail-Abrufe (`uvdesk:refresh-mailbox`) trotz korrektem Code ergebnislos.

==== Mail-Reputation ====
Shared-Hosting-IPs stehen oft auf Blacklists.
* '''Strategie:''' Für geschäftskritische Mails (Bestellbestätigungen, Tickets) sollte niemals der lokale `sendmail`-Pfad, sondern ein dedizierter SMTP-Relay-Provider genutzt werden.

=== 5. DevOp-Workflow & Deployment ===

{| class="wikitable"
! Thema !! Empfehlung
|-
| '''Environment Variables''' || `.env` Dateien werden unterstützt, aber der PHP-Wrapper sollte sicherstellen, dass diese nicht via Browser (z.B. in falsch konfigurierten Sub-Verzeichnissen) auslesbar sind.
|-
| '''Git-Deploy''' || Da kein direktes `git push` auf das Web-Verzeichnis möglich ist, sollte ein Workflow über GitHub Actions oder GitLab CI (via FTP/SFTP oder SSH) implementiert werden.
|-
| '''Composer''' || Composer sollte lokal oder in einer CI/CD-Pipeline ausgeführt werden. Das Ausführen von `composer install` auf dem Server kann durch Memory-Limits scheitern.
|}

=== 6. Professionelle Checkliste für bplaced ===
* [ ] '''Absolute Pfade:''' Pfade wie `/users/NAME/www/support/bin/console` statt relativer Pfade verwenden.
* [ ] '''Temp-Ordner:''' `sys_temp_dir` auf `/users/_temp/NAME` biegen, um Schreibfehler in `/tmp` zu vermeiden.
* [ ] '''OPcache Flush:''' Nach jedem Deployment `php_cache_clear()` oder Neustart der CGI-Instanz erzwingen (via bplaced Panel oder Wrapper-Touch).
* [ ] '''Logs:''' Regelmäßige Rotation der `php_access_logfile` und Framework-Logs, da Quota-Überschreitungen zum Systemstopp führen.

[[Kategorie:Hosting-Architektur]] [[Kategorie:PHP-Administration]]

Intern:Hauptseite/Bplaced - Versionsgeschichte

Admin am 25. Februar 2026 um 19:47 Uhr