Come migrare da ownCloud 10 Classic a ownCloud Infinite Scale

Scenario illustrativo: Immaginiamo uno studio di design fittizio di 32 persone, Cedar Studio, che utilizza ownCloud Classic 10 con una directory LDAP, aree file personali, condivisioni di gruppo, link pubblici e un mount di archiviazione di progetto esterno. Lo studio desidera migrare a ownCloud Infinite Scale (oCIS) senza dare per scontato che l'installazione di un nuovo server trasferisca automaticamente i dati o le autorizzazioni. Questo esempio è ipotetico e non rappresenta la descrizione di una migrazione completata.

Il percorso supportato e documentato da ownCloud è una migrazione guidata che utilizza l' migrate-to-ocisapp sul server Classic e occi relativi comandi. Si tratta di un trasferimento graduale verso una destinazione oCIS separata e pulita, non di un aggiornamento in loco del database o della directory dati di Classic. Il manuale di migrazione afferma che la sorgente rimane operativa per la maggior parte del processo, ma non descrive la sincronizzazione continua o una fase di migrazione delta finale senza tempi di inattività. Pianifica un passaggio controllato e conferma la compatibilità della versione della sorgente e la procedura finale di blocco delle scritture con il supporto di ownCloud prima dell'utilizzo in produzione.

I passaggi seguenti seguono la guida ufficiale alla migrazione di ownCloud Server 11.0 e la documentazione di autenticazione e backup di Infinite Scale 8.2, disponibile al 6 ottobre 2026. La sintassi dei comandi, le variabili d'ambiente e le modalità di supporto possono subire modifiche; si consiglia di verificarle nella documentazione relativa alle versioni installate.

Passaggio 1: inventariare l'istanza Classic e definire cosa significa "migrato".

Per Cedar Studio, il primo compito è elencare utenti, gruppi, account abilitati e disabilitati, cartelle condivise, collegamenti condivisi, punti di montaggio esterni e tutti gli utenti locali non presenti in LDAP. È importante registrare quali team dipendono da ciascun elemento. Questo evita di considerare un trasferimento riuscito di file personali come prova che ogni vecchio flusso di lavoro sia stato migrato.

Secondo la guida alla migrazione, è possibile trasferire utenti e gruppi abilitati con le relative appartenenze, i file della directory home di ciascun utente abilitato e le condivisioni di utenti, gruppi e collegamenti. I file vengono posizionati nello spazio personale di ciascun utente in oCIS. Gli utenti disabilitati e i relativi file vengono ignorati. Il processo non migra password o mount esterni. I byte residenti nei mount esterni e nelle condivisioni ricevute sono esclusi dal trasferimento dei file personali e devono essere gestiti separatamente. È necessario inventariare tali posizioni e assegnare manualmente un responsabile della migrazione.

È inoltre necessario verificare se vengono utilizzati link pubblici senza password. Per impostazione predefinita, oCIS richiede una password per i link pubblici; tali link Classic potrebbero non essere migrati correttamente a meno che non venga modificata la policy di destinazione. Non indebolire tale policy solo per preservare i vecchi URL. Valutare se i proprietari dei link debbano invece creare nuovi link protetti da password. Le password dei link protetti da password migrati non corrisponderanno alle vecchie password, pertanto gli utenti dovranno reimpostarle dopo il passaggio alla nuova versione.

Passaggio 2: Preparare una destinazione oCIS pulita e la connessione di migrazione

Prima di trasferire i dati di produzione, create e testate un'istanza oCIS separata. La guida alla migrazione richiede che entrambi i sistemi siano in esecuzione e raggiungibili l'uno dall'altro. Avverte inoltre che il sistema di destinazione deve essere nuovo e pulito: utenti o dati preesistenti potrebbero entrare in conflitto con i contenuti importati. Eseguite un backup dell'istanza Classic corrente e preparate un piano di ripristino che la mantenga disponibile fino a quando gli utenti non accetteranno il nuovo servizio.

La migrazione richiede l'installazione di un'app fornita da ownCloud sul server Classic. L'app viene fornita nell'ambito di una migrazione guidata; la documentazione indica agli amministratori di contattare l'assistenza di ownCloud per ottenerla. L'app include il proprio binario rclone. Non sostituire il processo documentato con un pacchetto casuale del Marketplace o con un'attività di copia file non correlata.

Lato oCIS, abilita il auth-appservizio e l'impostazione di autenticazione dell'applicazione. La guida alla migrazione richiede inoltre che l'impersonificazione sia attiva e che venga creato un token dell'applicazione per l'amministratore oCIS. La documentazione di auth-app di Infinite Scale 8.2 afferma esplicitamente che l'impersonificazione è destinata alla migrazione e non deve rimanere abilitata in un ambiente di produzione. Considerala come un'impostazione temporanea per la migrazione: proteggi il token, limita chi può accedervi e disattiva l'impersonificazione (solo per la migrazione) al termine del lavoro. In un ambiente distribuito, applica le impostazioni al servizio corretto come specificato nella documentazione.

Per l'ipotetico Cedar Studio, il target oCIS dovrebbe essere testato con lo stesso servizio LDAP utilizzato dal server Classic. Conserva le credenziali nel meccanismo di segretezza del deployment anziché incollare le password di bind nella cronologia della shell o in un runbook condiviso. La guida ufficiale alla migrazione di ownCloud elenca i requisiti del target e indica il supporto di ownCloud per l'app di migrazione. La guida all'app di autenticazione oCIS 8.2 spiega i token dell'app e l'impersonificazione.

Passaggio 3: rendere coerente la mappatura delle identità, quindi eseguire i controlli di prontezza

oCIS deve essere in grado di risolvere utenti e gruppi prima che i relativi file e condivisioni vengano migrati. Cedar Studio utilizza già LDAP, quindi il suo amministratore collegherà oCIS alla stessa directory, verificherà che gli utenti possano accedere e controllerà che gli identificativi corrispondano agli account previsti. La guida di ownCloud indica indirizzi email univoci e validi per ogni utente Classic abilitato. Per gli utenti Classic basati su LDAP, indica anche l'attributo username, solitamente uido samAccountName, e le corrispondenti impostazioni dello schema LDAP di oCIS. Assicuratevi che gli attributi corrispondano alla directory effettiva; non copiate ciecamente i valori di esempio.

Se Classic utilizza account locali ma oCIS utilizzerà una directory LDAP esterna, è necessario creare o migrare utenti e gruppi corrispondenti in tale directory prima del trasferimento dei file. I nomi di utenti e gruppi devono corrispondere. Il sistema IDM interno di oCIS è una directory integrata limitata, pensata per configurazioni di piccole dimensioni o per scopi di test; ownCloud raccomanda un vero sistema LDAP o un sistema di gestione delle identità esterno per gli ambienti di produzione. La procedura di migrazione ufficiale non supporta una popolazione mista di utenti Classic locali e con supporto LDAP in un unico ramo di migrazione. È preferibile risolvere tale architettura con il supporto tecnico piuttosto che improvvisare a metà percorso.

Una volta installata e abilitata l'app di migrazione su Classic, adatta il percorso e l'account di servizio documentati alla tua installazione. La guida utilizza /var/www/owncloude www-datacome esempi:

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

Il comando di verifica controlla che gli utenti abilitati abbiano indirizzi email validi e non duplicati. Risolvete i problemi segnalati prima di procedere, anziché saltare la verifica. Se un utente disabilitato deve essere spostato, esaminate l'account, abilitatelo su Classic prima della verifica e includetelo nel piano di migrazione. Cedar Studio dovrebbe inoltre verificare l'accesso LDAP a oCIS con diversi utenti rappresentativi prima dell'inizio del trasferimento dei dati.

Passaggio 4: Completa il ramo utenti e gruppi, quindi migra file e condivisioni

Segui il ramo della guida ufficiale corrispondente alla tua configurazione di identità. Se gli utenti Classic sono locali e utilizzeranno l'IDM integrato di oCIS, la sequenza della guida prevede la migrazione degli utenti, l'assegnazione di un ruolo oCIS e la migrazione dei gruppi. Agli utenti migrati viene assegnato un ruolo; i ruoli Classic non vengono mantenuti uno a uno e i privilegi di subamministratore Classic non hanno un ruolo equivalente in oCIS. Verifica manualmente l'accesso amministrativo. Se entrambi i sistemi utilizzano la stessa directory LDAP, assicurati che utenti e gruppi siano già disponibili per oCIS e segui il ramo LDAP anziché creare duplicati.

Una volta configurati utenti, gruppi e ruoli, i comandi di condivisione e di gestione file documentati utilizzano il nome utente dell'amministratore oCIS come ultimo argomento. La password dell'amministratore Classic viene richiesta in modalità interattiva:

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

Eseguire il trasferimento dei file prima del trasferimento delle condivisioni, come descritto nella procedura di migrazione. Gli utenti che non hanno mai effettuato l'accesso e non dispongono di file, o gli utenti mancanti in oCIS, vengono ignorati durante la fase di trasferimento dei file. Le condivisioni che coinvolgono utenti o gruppi mancanti possono essere segnalate come errori durante la migrazione. Per Cedar Studio, ciò significa che il team deve esaminare l'output del comando e l'inventario delle condivisioni; il completamento senza un arresto anomalo non equivale alla prova che tutte le condivisioni funzionino correttamente.

La guida alla migrazione afferma che le fasi riuscite non possono essere semplicemente ripetute senza prima rimuovere i dati di destinazione creati. Un --forceripristino dell'inizializzazione non rimuove i file già migrati da oCIS. Non utilizzare i flag di ripristino come strategia di ripetizione di routine. Se una fase fallisce, conservare i log, identificare cosa è stato creato e consultare la guida alla migrazione o l'assistenza prima di decidere se riparare la destinazione o riavviare su una destinazione pulita.

Passaggio 5: Effettuare il passaggio con una finestra di convalida e ripristino pianificata.

Per una transizione sicura, Cedar Studio pianificherebbe un periodo in cui i dipendenti smettono di modificare i file in Classic, eseguirebbe la migrazione approvata e indirizzerebbe clienti e utenti a oCIS solo dopo che i controlli sono stati superati. Questo blocco delle scritture è una misura di sicurezza operativa, non una garanzia che l'applicazione di migrazione esegua una sincronizzazione in tempo reale. La guida alla migrazione pubblicata non documenta la sincronizzazione continua né un comando di copia delta finale. Se l'azienda non può tollerare un blocco delle scritture, si prega di richiedere al supporto di ownCloud un piano di transizione specifico per la versione prima di promettere una migrazione senza tempi di inattività.

Eseguite la convalida tramite una checklist anziché con un singolo accesso amministratore:

• Verificare che gli utenti, i gruppi e le appartenenze ai gruppi abilitati, come previsto, siano presenti in oCIS; confermare le assegnazioni dei ruoli, in particolare per gli ex amministratori.
• Consenti agli utenti di aprire file rappresentativi migrati da diversi Spazi personali, inclusi file di grandi dimensioni e documenti modificati di recente.
• Verifica le condivisioni interne tra utenti e le condivisioni di gruppo sia con l'account proprietario che con un account destinatario.
• Aprire i link pubblici in una sessione di navigazione privata; reimpostare le password sui link protetti migrati e ricreare i link che non hanno superato i controlli delle policy.
• Ricrea i punti di montaggio esterni e migra o ricollega separatamente i dati a cui puntavano, quindi verifica che gli utenti abbiano l'accesso previsto.
• Prima di annunciare il nuovo indirizzo, verifica i client desktop e mobile, l'accesso, la sincronizzazione e il canale di supporto per il ripristino della password.

Mantenere Classic disponibile in uno stato controllato di sola lettura o comunque bloccato fino a quando il responsabile aziendale non approva e i record richiesti non sono stati verificati. Rimuovere la funzionalità di impersonificazione temporanea e revocare il token dell'app di migrazione quando non è più necessario. Quindi, eseguire e testare un backup di oCIS utilizzando la procedura per la sua configurazione di archiviazione. Le considerazioni ufficiali sul backup di oCIS 8.2 affermano che l'istanza deve essere completamente arrestata per la procedura di backup documentata e spiegano che i metadati e i blob di file possono avere percorsi di archiviazione separati.

Come si presenta una migrazione di successo

Nell'esempio di Cedar Studio, il successo non si limita al semplice caricamento dell'interfaccia web di oCIS. Significa che i dipendenti possono autenticarsi con l'origine di identità prevista, trovare il contenuto della propria directory home, aprire i file di gruppo e utilizzare le condivisioni ricreate o migrate con le autorizzazioni previste. Vengono presi in considerazione i reset delle password, i mount esterni e le modifiche ai link pubblici, mentre Classic rimane disponibile fino all'accettazione. Se uno qualsiasi di questi controlli fallisce, è necessario sospendere il passaggio, registrare gli utenti e gli oggetti interessati e risolvere il problema prima di considerare oCIS come sistema di riferimento.