OnPremise / Autoalojado

Este documento describe los requisitos técnicos para el funcionamiento de Campus Events en un entorno autoalojado (OnPremise).

Para un funcionamiento estable y de alto rendimiento, el servidor debe cumplir al menos los siguientes requisitos:

• Procesador: Arquitectura multinúcleo (multi-core).
• RAM: La cantidad de RAM necesaria depende del tráfico esperado. Como base, recomendamos al menos 4 GB de RAM libre para los servicios de la aplicación.
• Espacio de almacenamiento: Al menos 50 GB de espacio de almacenamiento libre para el código del programa, los datos de la aplicación (cargas, etc.) y las copias de seguridad locales.

• Responsabilidad: El mantenimiento continuo del sistema operativo, incluida la instalación de actualizaciones de seguridad para el sistema y los servicios instalados (PHP, Apache, base de datos, etc.), es responsabilidad del administrador del servidor por parte del cliente.
• Sincronización horaria: El servidor debe sincronizarse mediante NTP. La zona horaria del sistema debe establecerse en Europa/Berlín.
• Configuración regional: La configuración regional de_DE.UTF-8 debe estar instalada y disponible.

PHP y bases de datos

Nuestro software está en continuo desarrollo. La siguiente tabla muestra las versiones requeridas para los respectivos lanzamientos.

Los siguientes módulos deben estar instalados y activados para PHP (tanto FPM como CLI):

• bcmath, ctype, curl, gd, iconv, igbinary, imagick, intl, json, ldap, mbstring, mysql (pdo_mysql), opcache, readline, redis, soap, xml, xsl, zip
• Nota sobre imap: El módulo imap es necesario hasta PHP 8.3, pero ya no es necesario a partir de PHP 8.4.

Desviándose de los valores por defecto, deben establecerse los siguientes ajustes:

• memory_limit = 512MB (o superior)
• allow_url_fopen = true
• El comando php -v en la consola debe devolver la misma versión que utiliza el servidor web. Si hay varias versiones de PHP en un servidor, la versión de la CLI debe corresponder al entorno de producción.

Nuestro software está desarrollado y probado con una versión específica de PHP. Puede que sea necesario que el administrador del servidor actualice la versión de PHP para ponerlo en marcha o para una actualización. Esto será anunciado y coordinado por nosotros con suficiente antelación.

• Necesario para Campus Events a partir de la versión 2.35 (alias 5.0)
• Accesible a través de host/puerto o socket Unix (por ejemplo, /var/run/redis.sock).
• No es necesario el almacenamiento permanente de los datos.

El software está optimizado y probado exclusivamente para funcionar con Apache.

• Módulos: mod_rewrite debe estar activo.
• Configuración: FollowSymLinks debe estar permitido (los enlaces simbólicos fuera de la raíz web deben ser accesibles).
• Registros: Los registros de errores de Apache deben ser accesibles para el usuario de la aplicación (idealmente a través de un enlace simbólico en el directorio home).

Para garantizar un proceso de despliegue sin problemas, se requiere la siguiente estructura (basada en Deployer):

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

• copias de seguridad/
• releases/ (contiene las versiones individuales del programa en subcarpetas)
• shared/ (contiene datos de versiones cruzadas, como cargas o configuraciones)
• current (enlace simbólico a la versión actualmente activa en releases/)

La raíz de documentos del servidor web debe apuntar al directorio public/ de la versión actual:
/var/www/html/campus-events/productive/current/public

Recomendamos mantener la separación en productivo y staging en la ruta, incluso si sólo hay un sistema.

• El usuario SSH para el despliegue requiere autorización de escritura completa en el directorio del proyecto.
• Si este usuario no es idéntico al usuario del proceso del servidor web (por ejemplo, www-data), sudo debe funcionar sin contraseña para este usuario con el fin de ajustar las autorizaciones.

• Entrante: El puerto 443 (HTTPS) y el puerto 22 (SSH) deben ser accesibles desde una lista definida de nuestras direcciones IP.
  • 109.90.104.82 (Oficina de Apelación Cerebral - para soporte)
  • 167.235.150.166 y 2a01:4f8:c2c:a670::/64 (Servidor de despliegue)
• Saliente: Debe permitirse la conexión directa en el puerto 443 a nuestro sistema de seguimiento de errores (lista blanca).
  • 188.245.245.172 2a01:4f8:1c1b:a451::/64 (GlitchTip)
  • 78.47.122.223 2a01:4f8:c0c:e3fd::/64 (Sentry - Descontinuado en el futuro)
• No se admite una conexión VPN; el acceso SSH es exclusivamente directo y mediante un par de claves SSH.

Uso de servicios externos (por ejemplo, proveedores de servicios de pago, acceso API)

Para conectar servicios externos, el cortafuegos debe estar configurado de forma que se pueda acceder a los sistemas sin desvíos.
En concreto, esto significa que no hemos diseñado nuestras conexiones para su uso a través de proxies u otros desvíos.

• La aplicación requiere actualmente dos cron jobs que deben ejecutarse cada minuto.
• Lo ideal es introducirlas en /etc/crontab. Un comentario en /etc/crontab es obligatorio para diferentes ubicaciones.

• El cliente es responsable de la copia de seguridad de los datos (base de datos y archivos).
• Recomendación: al menos una copia de seguridad diaria con un periodo de conservación de 7 días.
• En caso necesario, el cliente debe poder restaurar los datos rápidamente.

Para enviar correos electrónicos (por ejemplo, confirmaciones, notificaciones del sistema) se necesitan los siguientes datos de acceso:

• Envío (SMTP): Es obligatoria una configuración SMTP en funcionamiento (host, puerto, usuario, contraseña, cifrado).
• Recepción/comprobación (IMAP): Recomendamos encarecidamente la provisión adicional de acceso IMAP (puede ser el mismo buzón que para SMTP). Esto nos permite comprobar automáticamente el envío de correo.

No asumimos ninguna responsabilidad por:

• Configuración y renovación de certificados SSL.
• Configuraciones generales de Apache o PHP fuera de esta especificación.
• Problemas de autorización a nivel de sistema de archivos o fallos de red.