OnPremise / Self Hosted

This document describes the technical requirements for the operation of Campus Events in a self-hosted environment (OnPremise).

For stable and high-performance operation, the server should fulfil at least the following requirements:

• Processor: Multi-core architecture (multi-core).
• RAM: The amount of RAM required depends on the expected traffic. As a basis, we recommend at least 4 GB of free RAM for the application services.
• Storage space: At least 50 GB free storage space for the programme code, application data (uploads etc.) and local backups.

• Responsibility: The ongoing maintenance of the operating system, including the installation of security updates for the system and the installed services (PHP, Apache, database, etc.), is the responsibility of the server administrator on the customer side.
• Time synchronisation: The server should be synchronised via NTP. The system time zone should be set to Europe/Berlin.
• Locales: The locale de_DE.UTF-8 must be installed and available.

PHP & Database

Our software is continuously being developed. The following table shows the required versions for the respective releases.

The following modules must be installed and activated for PHP (both FPM and CLI):

• bcmath, ctype, curl, gd, iconv, igbinary, imagick, intl, json, ldap, mbstring, mysql (pdo_mysql), opcache, readline, redis, soap, xml, xsl, zip
• Note on imap: The imap module is required up to PHP 8.3, but is no longer required from PHP 8.4.

Deviating from the default values, the following settings must be set:

• memory_limit = 512MB (or higher)
• allow_url_fopen = true
• The php -v command on the console must return the same version that is used by the web server. If there are several PHP versions on a server, the CLI version must correspond to the production environment.

Our software is developed and tested against a specific PHP version. It may be necessary for the PHP version to be upgraded by the server administrator in order to go live or for an update. This will be announced and coordinated by us in good time.

• Required for Campus Events from version 2.35 (alias 5.0)
• Accessible via host/port or Unix socket (e.g. /var/run/redis.sock).
• Persistent storage of the data is not required.

The software is optimised and tested exclusively for operation with Apache.

• Modules: mod_rewrite must be active.
• Configuration: FollowSymLinks must be allowed (symlinks outside the webroot must be accessible).
• Logs: The Apache error logs must be accessible to the application user (ideally via symlink in the home directory).

To ensure a smooth deployment process, the following structure (based on Deployer) is required:

/var/www/html/campus-events/productive/

• backups/
• releases/ (contains the individual programme versions in subfolders)
• shared/ (contains cross-release data such as uploads or configurations)
• current (symlink to the currently active release in releases/)

The document root of the web server must point to the public/ directory of the current release:
/var/www/html/campus-events/productive/current/public

We recommend retaining the separation into productive and staging in the path, even if there is only one system.

• The SSH user for the deployment requires full write authorisation in the project directory.
• If this user is not identical to the user of the web server process (e.g. www-data), sudo must function without a password for this user in order to adjust authorisations.

• Incoming: Port 443 (HTTPS) and port 22 (SSH) must be accessible from a defined list of our IP addresses.
  • 109.90.104.82 (Brain Appeal Office - for support)
  • 167.235.150.166 and 2a01:4f8:c2c:a670::/64 (Deployment Server)
• Outgoing: Direct connection on port 443 to our bug tracking system should be allowed (whitelisting).
  • 188.245.245.172 2a01:4f8:1c1b:a451::/64 (GlitchTip)
  • 78.47.122.223 2a01:4f8:c0c:e3fd::/64 (Sentry - Discontinued in future)
• A VPN connection is not supported; SSH access is exclusively direct and using an SSH key pair.

Use of external services (e.g. payment service providers, API access)

To connect external services, the firewall must be configured in such a way that the systems can be reached without detours.
Specifically, this means that we have not designed our connections for use via proxies or other detours.

• The application currently requires two cron jobs that must be executed every minute.
• Ideally, these should be entered in /etc/crontab. A comment in /etc/crontab is mandatory for different locations.

• The customer is responsible for the data backup (database and files).
• Recommendation: At least daily backup with a retention period of 7 days.
• If necessary, the customer must be able to restore the data promptly.

The following access data is required to send e-mails (e.g. confirmations, system notifications):

• Sending (SMTP): A functioning SMTP configuration (host, port, user, password, encryption) is mandatory.
• Receiving/checking (IMAP): We strongly recommend the additional provision of IMAP access (can be the same mailbox as for SMTP). This enables us to automatically check the mail dispatch.

We assume no responsibility for:

• Setup and renewal of SSL certificates.
• General Apache or PHP configurations outside of this specification.
• Authorisation problems at file system level or network faults.