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 viene costantemente aggiornato. La tabella seguente riporta le versioni richieste 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.

• Obbligatorio per Campus Events a partire dalla versione 5.0 e per Campus Mails a partire dalla versione 4.0.
• Sono supportati i tipi di connessione Redis supportati da Symfony.
• In particolare, è possibile connettersi al server Redis tramite:
  • TCP/IP (host e porta)
  • Unix Domain Socket
  • Autenticazione tramite utente/password (ACL) o password
  • Connessioni crittografate con TLS
  • Redis Sentinel
  • Redis Cluster
• La configurazione concreta avviene tramite un DSN Redis secondo la documentazione di Symfony.
• Per il funzionamento del nostro software non è necessario un salvataggio persistente dei dati Redis.
• L'istanza Redis può essere utilizzata insieme ad altre applicazioni.

Ulteriori informazioni sulla sintassi DSN supportata: https://symfony.com/doc/current/components/cache/adapters/redis_adapter.html#configure-the-connection

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.

Questo contenuto è accessibile solo dopo aver effettuato il accesso .

• 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.