Web server, PHP, database e SFTP possono essere configurati separatamente. Il problema operativo nasce quando devono rappresentare lo stesso ambiente, evolvere insieme e conservare una relazione comprensibile con l'utente e con il controllo centrale.
Fliclic Server organizza questi componenti intorno all'identità del servizio. Le funzioni seguenti sono gruppi di responsabilità del motore, non strumenti amministrativi indipendenti da presentare tutti allo stesso livello.
La creazione prepara l'identità tecnica dell'ambiente e le risorse necessarie: utente e gruppo dedicati, albero del sito, directory per contenuto, log, temporanei e backup, quota, pool PHP-FPM, configurazione web, HTTPS nei flussi supportati ed eventuale database iniziale.
Il workflow decide poi se l'ambiente è concluso oppure deve proseguire con l'installazione WordPress o con la duplicazione. Questa catena evita di considerare pronto uno spazio che ha terminato soltanto la prima fase.
Il ciclo di vita comprende inoltre:
Questi flussi hanno errori e rollback differenti. L'eliminazione, in particolare, è multi-componente e non possiede una transazione globale capace di ricreare ogni risorsa dopo un errore tardivo.
Ogni ambiente usa un'identità Linux dedicata e un gruppo proprio. La radice del servizio, la directory pubblica, i log, i temporanei e i backup hanno proprietari e permessi differenti in base alla loro funzione.
Il contenuto pubblico deve essere leggibile dal web server e modificabile dall'utente dell'ambiente senza diventare attraversabile dagli altri tenant. I file sensibili riconosciuti dalla policy ricevono permessi più restrittivi. Log e temporanei hanno regole separate; la radice backup resta sotto controllo amministrativo.
Un helper sicuro normalizza proprietari e permessi lavorando sugli oggetti già aperti e rifiutando anomalie come hard link, mount inattesi, tipi speciali o cambiamenti concorrenti. Non modifica contenuti né attributi di quota: sicurezza dei metadata e Project Quota restano controlli distinti.
Fliclic include un flusso di installazione WordPress eseguito, dove possibile, con l'identità dell'ambiente. Scaricamento, configurazione e installazione sono seguiti dalla normalizzazione dei metadata secondo la policy prevista.
La duplicazione di un WordPress richiede una fase applicativa: la copia deve usare il database di destinazione e riferirsi al nuovo dominio. Il workflow dedicato aggiorna configurazione, URL e riferimenti pertinenti.
Questa logica non viene riutilizzata nel ripristino. Un restore deve preservare la fotografia senza interpretare il CMS; usare lo stesso strumento per entrambi i casi introdurrebbe modifiche non richieste nei dati storici.
La destinazione viene provisionata prima della copia, con una propria identità, quota, pool, socket e configurazione. I database destinazione seguono il loro workflow; quando sono pronti, i contenuti pubblici vengono sincronizzati e normalizzati. WordPress passa poi alla riconfigurazione dedicata.
Questo modello rende la copia indipendente dalla sorgente. Non trasferisce automaticamente ogni direttiva manuale del pool sorgente, ACL o attributo esteso e non applica alla destinazione la quota del progetto originario.
La duplicazione non dispone oggi di staging e rollback generale. Un errore può lasciare una destinazione parziale; lo stato esplicito permette di distinguerla da una copia riuscita.
Il sottosistema backup gestisce creazione HOT o STOP, pubblicazione degli artefatti, conservazione della fotografia, eliminazione secondo stato e scadenza e restore completo. Lock interni dedicati evitano collisioni tra istanze dei checker di cancellazione e ripristino.
Il backup disponibile rimane separato dal suo stato operativo. Durante il restore non viene consumato: dopo un successo torna disponibile, mentre un errore conserva la diagnosi. Le richieste e gli stati del servizio, del backup e dei database sono namespace distinti, progettati per non sovrapporre significati.
