OnPremise / Self Hosted

Questo documento descrive i requisiti tecnici per il funzionamento di Campus Events in un ambiente self-hosted (OnPremise).

Per un funzionamento stabile e ad alte prestazioni, il server deve soddisfare almeno i seguenti requisiti:

• Processore: architettura multi-core (multi-core).
• RAM: La quantità di RAM necessaria dipende dal traffico previsto. Come base, consigliamo almeno 4 GB di RAM libera per i servizi applicativi.
• Spazio di archiviazione: almeno 50 GB di spazio di archiviazione libero per il codice del programma, i dati dell'applicazione (upload, ecc.) e i backup locali.

• Responsabilità: la manutenzione continua del sistema operativo, compresa l'installazione degli aggiornamenti di sicurezza per il sistema e i servizi installati (PHP, Apache, database, ecc.), è responsabilità dell'amministratore del server da parte del cliente.
• Sincronizzazione dell'ora: il server deve essere sincronizzato tramite NTP. Il fuso orario del sistema deve essere impostato su Europa/Berlino.
• Locale: Il locale de_DE.UTF-8 deve essere installato e disponibile.

PHP e database

Il nostro software è in continuo sviluppo. La seguente tabella mostra le versioni necessarie per le rispettive release.

I seguenti moduli devono essere installati e attivati per PHP (sia FPM che CLI):

• bcmath, ctype, curl, gd, iconv, igbinary, imagick, intl, json, ldap, mbstring, mysql (pdo_mysql), opcache, readline, redis, soap, xml, xsl, zip
• Nota su imap: Il modulo imap è necessario fino a PHP 8.3, ma non è più richiesto a partire da PHP 8.4.

A differenza dei valori predefiniti, è necessario impostare le seguenti impostazioni:

• limite_memoria = 512 MB (o superiore)
• allow_url_fopen = true
• Il comando php -v sulla console deve restituire la stessa versione utilizzata dal server web. Se su un server sono presenti più versioni di PHP, la versione della CLI deve corrispondere all'ambiente di produzione.

Il nostro software è sviluppato e testato con una versione PHP specifica. Potrebbe essere necessario che la versione di PHP venga aggiornata dall'amministratore del server per poter andare in onda o per un aggiornamento. Questo verrà annunciato e coordinato da noi in tempo utile.

• Richiesto per Campus Events dalla versione 2.35 (alias 5.0).
• Accessibile tramite host/porta o socket Unix (ad esempio, /var/run/redis.sock).
• Non è richiesta la memorizzazione persistente dei dati.

Il software è ottimizzato e testato esclusivamente per il funzionamento con Apache.

• Moduli: mod_rewrite deve essere attivo.
• Configurazione: FollowSymLinks deve essere consentito (i link simbolici al di fuori della webroot devono essere accessibili).
• Registri: I log degli errori di Apache devono essere accessibili all'utente dell'applicazione (idealmente tramite un link simbolico nella home directory).

Per garantire un processo di distribuzione senza intoppi, è necessaria la seguente struttura (basata su Deployer):

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

• backup/
• releases/ (contiene le singole versioni del programma in sottocartelle)
• shared/ (contiene dati relativi a più release, come upload o configurazioni)
• current (link simbolico alla release attualmente attiva in releases/)

La radice del documento del server web deve puntare alla directory public/ della release corrente:
/var/www/html/campus-events/productive/current/public

Si consiglia di mantenere la separazione tra productive e staging nel percorso, anche se c'è un solo sistema.

• L'utente SSH per l'installazione richiede la piena autorizzazione di scrittura nella directory del progetto.
• Se questo utente non è identico all'utente del processo del server web (ad esempio www-data), sudo deve funzionare senza password per questo utente, al fine di regolare le autorizzazioni.

• In entrata: la porta 443 (HTTPS) e la porta 22 (SSH) devono essere accessibili da un elenco definito di indirizzi IP.
  • 109.90.104.82 (Ufficio Appello Cervello - per l'assistenza)
  • 167.235.150.166 e 2a01:4f8:c2c:a670::/64 (Deployment Server)
• In uscita: la connessione diretta sulla porta 443 al nostro sistema di tracciamento dei bug deve essere consentita (whitelisting).
  • 188.245.245.172 2a01:4f8:1c1b:a451::/64 (GlitchTip)
  • 78.47.122.223 2a01:4f8:c0c:e3fd::/64 (Sentry - Discontinuato in futuro)
• Non è supportata una connessione VPN; l'accesso SSH è esclusivamente diretto e utilizza una coppia di chiavi SSH.

Utilizzo di servizi esterni (ad es. fornitori di servizi di pagamento, accesso API)

Per connettersi a servizi esterni, il firewall deve essere configurato in modo tale che i sistemi possano essere raggiunti senza deviazioni.
In particolare, ciò significa che non abbiamo progettato le nostre connessioni per l'utilizzo tramite proxy o altre deviazioni.

• L'applicazione attualmente richiede due cron job che devono essere eseguiti ogni minuto.
• Idealmente, questi dovrebbero essere inseriti in /etc/crontab. Un commento in /etc/crontab è obbligatorio per le diverse posizioni.

• Il cliente è responsabile del backup dei dati (database e file).
• Raccomandazione: almeno un backup giornaliero con un periodo di conservazione di 7 giorni.
• Se necessario, il cliente deve essere in grado di ripristinare prontamente i dati.

Per l'invio di e-mail (ad es. conferme, notifiche di sistema) sono necessari i seguenti dati di accesso:

• Invio (SMTP): è obbligatoria una configurazione SMTP funzionante (host, porta, utente, password, crittografia).
• Ricezione/controllo (IMAP): Si consiglia vivamente di prevedere un accesso IMAP (può essere la stessa casella di posta elettronica dell'SMTP). Questo ci permette di controllare automaticamente l'invio della posta.

Non ci assumiamo alcuna responsabilità per:

• Impostazione e rinnovo dei certificati SSL.
• Configurazioni generali di Apache o PHP al di fuori di questa specifica.
• Problemi di autorizzazione a livello di file system o errori di rete.