OnPremise / Self Hosted

Dieses Dokument beschreibt die technischen Voraussetzungen für den Betrieb von Campus Mails in einer Self-Hosted-Umgebung (OnPremise).

Hardware-Anforderungen

Für einen stabilen und performanten Betrieb sollte der Server mindestens folgende Anforderungen erfüllen:

  • Prozessor: Mehrkern-Architektur (Multi-Core).
  • Arbeitsspeicher (RAM): Die Menge des benötigten Arbeitsspeichers ist vom zu erwartenden Traffic abhängig. Als Basis empfehlen wir mindestens 4 GB freien RAM für die Applikationsdienste.
  • Speicherplatz: Mindestens 50 GB freier Speicherplatz für den Programmcode, die Anwendungsdaten (Uploads etc.) sowie lokale Backups.

Betriebssystem & Systemwartung

  • Verantwortung: Die laufende Wartung des Betriebssystems, inklusive der Installation von Sicherheitsupdates für das System und die installierten Dienste (PHP, Apache, Datenbank etc.), liegt in der Verantwortung des Server-Administrators auf Kundenseite.
  • Zeitsynchronisation: Der Server sollte über NTP synchronisiert sein. Die Systemzeitzone sollte auf Europe/Berlin eingestellt sein.
  • Locales: Die Locale de_DE.UTF-8 muss installiert und verfügbar sein.

Softwarevoraussetzungen

PHP & Datenbank

Unsere Software wird kontinuierlich weiterentwickelt. Die folgende Tabelle zeigt die benötigten Versionen für die jeweiligen Releases.

Campus Mails

VersionPHP VersionPHP-Module (Auszug)DatenbankRedisHinweise
4.0 - 4.18.2ctype, gd, iconv, intl, imap, json, ldap, redisMariaDB 10.11 (MySQL 8.0)Erforderlich 
4.28.3ctype, gd, iconv, intl, imap, json, ldap, redisMariaDB 10.11 (MySQL 8.0)Erforderlich 
4.38.4ctype, gd, iconv, intl, json, ldap, redisMariaDB 10.11 (MySQL 8.0)Erforderlich 

MariaDB versus MySQL: Compatibility

Kunden sichtbare Systemanforderungen

  • Campus Mails: noch nicht spezifiziert

Erforderliche PHP-Module

Die folgenden Module müssen für PHP (sowohl FPM als auch CLI) installiert und aktiviert sein:

  • bcmath, ctype, curl, gd, iconv, igbinary, imagick, intl, json, ldap, mbstring, mysql (pdo_mysql), opcache, readline, redis, soap, xml, xsl, zip
  • Hinweis zu imap: Das imap-Modul wird bis PHP 8.3 benötigt, entfällt jedoch ab PHP 8.4.

PHP-Konfiguration

Abweichend von Standardwerten müssen folgende Einstellungen gesetzt sein:

  • memory_limit = 512MB (oder höher)
  • allow_url_fopen = true
  • Der Befehl php -v auf der Konsole muss dieselbe Version zurückgeben, die auch vom Webserver verwendet wird. Bei mehreren PHP-Versionen auf einem Server muss die CLI-Version der Produktivumgebung entsprechen.

PHP-Versions-Wechsel

Unsere Software ist jeweils gegen eine bestimmte PHP-Version entwickelt und getestet. Es kann erforderlich sein, dass die PHP-Version zum Livegang oder für ein Update durch den Server-Administrator angehoben werden muss. Dies wird von uns rechtzeitig angekündigt und koordiniert.

Redis

  • Erforderlich für Campus Events ab v5.0 und Campus Mails ab v4.0.
  • Erreichbar über Host/Port oder Unix-Socket (z. B. /var/run/redis.sock).
  • Eine persistente Speicherung der Daten ist nicht erforderlich.

Webserver (Apache)

Die Software ist ausschließlich für den Betrieb mit Apache optimiert und getestet.

  • Module: mod_rewrite muss aktiv sein.
  • Konfiguration: FollowSymLinks muss erlaubt sein (Symlinks außerhalb der Webroot müssen erreichbar sein).
  • Logs: Die Apache-Error-Logs müssen für den Applikations-User auffindbar sein (idealerweise per Symlink im Home-Verzeichnis).

E-Mail Versand

Für den Versand von E-Mails (z. B. Bestätigungen, Systembenachrichtigungen) werden folgende Zugangsdaten benötigt:

  • Versand (SMTP): Eine funktionierende SMTP-Konfiguration (Host, Port, User, Passwort, Verschlüsselung) ist zwingend erforderlich.
  • Empfang/Prüfung (IMAP): Wir empfehlen dringend die zusätzliche Bereitstellung eines IMAP-Zugangs (kann dasselbe Postfach wie für SMTP sein). Dies ermöglicht uns eine automatisierte Überprüfung des Mailversands.

Infrastruktur & Sicherheit

Dateistruktur & Bereitstellung

Um einen reibungslosen Deployment-Prozess zu gewährleisten, wird folgende Struktur (basierend auf Deployer) vorausgesetzt:

/var/www/html/campus-events/produktiv/

  • backups/
  • releases/ (enthält die einzelnen Programmversionen in Unterordnern)
  • shared/ (enthält release-übergreifende Daten wie Uploads oder Konfigurationen)
  • current (Symlink auf das aktuell aktive Release in releases/)

Der Document Root des Webservers muss auf das public/-Verzeichnis des aktuellen Releases zeigen:
/var/www/html/campus-events/produktiv/current/public

Wir empfehlen, auch bei nur einem System die Trennung in produktiv und staging im Pfad beizubehalten.

User & Berechtigungen

  • Der SSH-User für das Deployment benötigt volle Schreibrechte im Projektverzeichnis.
  • Falls dieser User nicht identisch mit dem User des Webserver-Prozesses (z. B. www-data) ist, muss sudo für diesen User passwortlos funktionieren, um Berechtigungen anzupassen.

Firewall-Freigaben

  • Eingehend: Port 443 (HTTPS) und Port 22 (SSH) müssen von einer definierten Liste unserer IP-Adressen erreichbar sein.
    • 109.90.104.82 (Brain Appeal Office - für Support)
    • 167.235.150.166 und 2a01:4f8:c2c:a670::/64 (Deployment Server)
  • Ausgehend: Direkte Verbindung auf Port 443 zu unserem Bugtracking-System sollte erlaubt sein (Whitelisting).
    • 188.245.245.172 2a01:4f8:1c1b:a451::/64 (GlitchTip)
    • 78.47.122.223 2a01:4f8:c0c:e3fd::/64 (Sentry - Entfällt zukünftig)
  • Eine VPN-Verbindung wird nicht unterstützt; der SSH-Zugriff erfolgt ausschließlich direkt und mittels SSH-Schlüsselpaar.

Cronjobs

  • Die Applikation benötigt zur Zeit zwei Cronjobs, die minütlich ausgeführt werden müssen.
  • Diese sollten idealerweise in /etc/crontab eingetragen werden. Bei abweichenden Orten ist ein Kommentar in /etc/crontab zwingend erforderlich.

Backups & Restore

  • Die Verantwortung für die Datensicherung (Datenbank und Dateien) liegt beim Kunden.
  • Empfehlung: Mindestens tägliche Sicherung mit einer Aufbewahrungsfrist von 7 Tagen.
  • Die Wiederherstellung (Restore) muss im Bedarfsfall zeitnah durch den Kunden durchgeführt werden können.

Monitoring & Support

Bugtracking (Glitchtip / Sentry)

Zur schnellen Reaktion im Fehlerfall empfehlen wir dringend die Anbindung an unser Bugtracking-Tool.

  • Erfassung technischer Kontextdaten zur Fehleranalyse.
  • Vollständig von uns auf Servern in Deutschland gehostet (DSGVO-konform).
  • Automatische Löschung der Daten nach spätestens 90 Tagen.

PHP-MyAdmin

Zur Fehleranalyse und Unterstützung bei Supportanfragen empfehlen wir die Bereitstellung eines PhpMyAdmin-Zugangs.

Abgrenzungen

Wir übernehmen keine Verantwortung für:

  • Einrichtung und Verlängerung von SSL-Zertifikaten.
  • Allgemeine Apache- oder PHP-Konfigurationen außerhalb dieser Spezifikation.
  • Berechtigungsprobleme auf Dateisystemebene oder Netzwerkstörungen.