Scenariu ilustrativ: Imaginați-vă o firmă de design fictivă cu 32 de persoane, Cedar Studio, care rulează ownCloud Classic 10 cu un director LDAP, zone de fișiere personale, partajări de grup, linkuri publice și o montare externă pentru stocarea proiectelor. Firma dorește să treacă la ownCloud Infinite Scale (oCIS) fără a presupune că instalarea unui nou server va transfera datele sau permisiunile sale. Acest exemplu este ipotetic; nu este un raport al unei migrări finalizate.
Calea acceptată documentată de ownCloud este o migrare ghidată folosind migrate-to-ocisaplicația de pe serverul Classic și occcomenzi. Este un transfer etapizat către o țintă oCIS separată, curată, nu o actualizare la fața locului a bazei de date sau a directorului de date Classic. Manualul de migrare precizează că sursa rămâne operațională pe parcursul majorității procesului, dar nu descrie sincronizarea continuă sau o trecere delta finală fără întreruperi. Planificați o migrare controlată și confirmați compatibilitatea sursă-versiunea și procedura finală de înghețare a scrierii cu asistența ownCloud înainte de utilizarea în producție.
Pașii de mai jos respectă ghidul oficial de migrare ownCloud Server 11.0 și documentația de autentificare și backup Infinite Scale 8.2 disponibilă pe 6 octombrie 2026. Sintaxa comenzilor, variabilele de mediu și aranjamentele de asistență se pot modifica; confirmați-le cu documentația pentru versiunile instalate.
Pentru Cedar Studio, prima sarcină este de a lista utilizatorii, grupurile, conturile activate și dezactivate, folderele partajate, partajările de linkuri, montările externe și orice utilizatori locali care nu există în LDAP. Înregistrați echipele care depind de fiecare element. Acest lucru evită tratarea unui transfer reușit al fișierelor personale ca dovadă că fiecare flux de lucru vechi a fost mutat.
Conform ghidului de migrare, migrarea poate transfera utilizatori și grupuri activate cu abonamente, fișierele directorului principal al fiecărui utilizator activat și partajările de utilizatori, grupuri și linkuri. Fișierele sunt plasate în spațiul personal al fiecărui utilizator din oCIS. Utilizatorii dezactivați și fișierele acestora sunt omiși. Procesul nu migrează parole sau montări externe. Octeții aflați în montările externe și partajările primite sunt excluși din transferul de fișiere personale și trebuie gestionați separat. Inventariați aceste locații și atribuiți un proprietar manual pentru migrare.
| Articol clasic | Comportament de migrație documentat | Plan pentru Cedar Studio |
|---|---|---|
| Utilizatori și grupuri activate | Transferat sau mapat, în funcție de backend-ul de identitate. | Confirmați că toate conturile și abonamentele așteptate sunt vizibile în oCIS. |
| Fișierele din directoarele principale ale utilizatorilor | Transferat în spațiul personal al fiecărui utilizator. | Comparați folderele și fișierele reprezentative după transfer. |
| Partajări de utilizatori, grupuri și linkuri | Înregistrările partajate sunt migrate, în funcție de utilizatori, grupuri sau politicile privind linkul și parola lipsă. | Retestați accesul cu conturile de proprietar și destinatar. |
| Parole și conturi dezactivate | Parolele nu sunt transferate; utilizatorii dezactivați sunt omiși. | Pregătiți integrarea contului și verificați ce conturi dezactivate ar trebui activate înainte de migrare. |
| Montări externe și date de partajare primite | Datele de montare externă sunt excluse din transferul de fișiere. | Recreați montările sau copiați datele sursă separat, apoi testați accesul. |
De asemenea, înregistrați dacă sunt utilizate linkuri publice fără parolă. În mod implicit, oCIS necesită o parolă pentru linkurile publice; astfel de linkuri clasice pot eșua să migreze decât dacă politica țintă este modificată. Nu slăbiți această politică doar pentru a păstra adresele URL vechi. Decideți dacă proprietarii linkurilor ar trebui să creeze în schimb linkuri noi protejate prin parolă. Parolele de pe linkurile protejate prin parolă migrate nu se vor potrivi cu vechile parole, așa că utilizatorii ar trebui să le reseteze după trecere.
Construiți și testați o instanță oCIS separată înainte de a transfera datele de producție. Ghidul de migrare necesită ca ambele sisteme să ruleze și să fie accesibile unul de la celălalt. De asemenea, avertizează că ținta trebuie să fie nouă și curată: utilizatorii sau datele preexistente pot intra în conflict cu conținutul importat. Faceți o copie de rezervă a instanței Classic curente și pregătiți un plan de revenire la versiunea inițială care să o mențină disponibilă până când utilizatorii acceptă noul serviciu.
Migrarea necesită o aplicație furnizată de ownCloud, instalată pe serverul Classic. Aceasta este furnizată ca parte a unei migrări ghidate; documentația îi îndrumă pe administratori să contacteze asistența ownCloud pentru a o obține. Aplicația include propriul fișier binar rclone. Nu înlocuiți procesul documentat al acestei aplicații cu un pachet Marketplace aleatoriu sau cu o sarcină de copiere a fișierelor fără legătură.
Pe partea oCIS, activați auth-appserviciul și setarea de autentificare a aplicației. Ghidul de migrare necesită, de asemenea, ca impersonarea să fie activă și ca un token de aplicație să fie creat pentru administratorul oCIS. Documentația Infinite Scale 8.2 auth-app precizează în mod explicit că impersonarea este destinată migrării și nu ar trebui să rămână activată într-o implementare de producție. Tratați-o ca pe o setare de migrare temporară: protejați token-ul, limitați cine îl poate accesa și dezactivați impersonarea doar pentru migrare după finalizarea lucrării. Într-o implementare distribuită, aplicați setările serviciului corect, așa cum specifică documentația.
Pentru ipoteticul Cedar Studio, ținta oCIS ar trebui testată cu același serviciu LDAP utilizat de serverul Classic. Păstrați acreditările în mecanismul secret al implementării, în loc să lipiți parolele de legare în istoricul shell-ului sau într-un registru de operare partajat. Ghidul oficial de migrare ownCloud listează cerințele țintei și indică suportul ownCloud pentru aplicația de migrare. Ghidul aplicației de autentificare oCIS 8.2 explică token-urile aplicației și uzurparea identității.
oCIS trebuie să poată rezolva utilizatorii și grupurile înainte ca fișierele și partajările acestora să fie migrate. Cedar Studio utilizează deja LDAP, așa că administratorul său ar conecta oCIS la același director, ar verifica dacă utilizatorii se pot conecta și ar verifica dacă identificatorii se potrivesc conturilor dorite. Ghidul ownCloud indică adrese de e-mail unice și valide pentru fiecare utilizator Classic activat. Pentru utilizatorii Classic cu suport LDAP, acesta indică și atributul nume de utilizator, de obicei uidsau samAccountName, și setările schemei oCIS LDAP corespunzătoare. Potriviți atributele cu directorul real; nu copiați orbește valori eșantion.
Dacă Classic folosește conturi locale, dar oCIS va folosi un director LDAP extern, creați sau migrați utilizatori și grupuri corespunzătoare în directorul respectiv înainte de transferul fișierelor. Numele utilizatorilor și grupurilor trebuie să corespundă. IDM-ul intern oCIS este un director încorporat limitat, destinat configurărilor mici sau testării; ownCloud recomandă un sistem LDAP real sau un sistem extern de gestionare a identităților pentru producție. Procedura oficială de migrare nu acceptă o populație mixtă de utilizatori Classic locali și susținuți de LDAP într-o singură ramură de migrare. Rezolvați acea arhitectură cu asistență, în loc să improvizați pe jumătate.
După ce aplicația de migrare a fost instalată și activată pe Classic, adaptați calea documentată și contul de serviciu la instalare. Ghidul folosește /var/www/owncloudca www-dataexemple:
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:verifyComanda de verificare verifică dacă utilizatorii activați au adrese de e-mail valide, neduplicate. Remediați problemele raportate înainte de a continua, în loc să omiteți verificarea. Dacă un utilizator dezactivat trebuie să se mute, verificați contul, activați-l în Classic înainte de verificare și includeți-l în planul de migrare. Cedar Studio ar trebui, de asemenea, să verifice conectarea LDAP la oCIS cu mai mulți utilizatori reprezentativi înainte de începerea transferului de date.
Urmați ramura din ghidul oficial care corespunde configurării identității dvs. Dacă utilizatorii Classic sunt locali și vor utiliza IDM-ul încorporat din oCIS, secvența ghidului include migrarea utilizatorilor, atribuirea unui rol oCIS și migrarea grupurilor. Un rol este atribuit utilizatorilor migrați; rolurile Classic nu sunt păstrate unu la unu, iar privilegiile de subadministrator Classic nu au un rol echivalent în oCIS. Verificați manual accesul de administrator. Dacă ambele sisteme utilizează același director LDAP, asigurați-vă că utilizatorii și grupurile sunt deja disponibile pentru oCIS și urmați ramura LDAP în loc să creați duplicate.
După ce utilizatorii, grupurile și rolurile sunt gata, comenzile documentate de fișiere și partajare utilizează numele de utilizator de administrator oCIS ca argument final. Parola de administrator clasică este solicitată interactiv:
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 adminExecutați transferul de fișiere înainte de transferul partajării, așa cum este descris în procedura de migrare. Utilizatorii care nu s-au autentificat niciodată și nu au fișiere sau utilizatori lipsă din oCIS sunt omiși de pasul de fișiere. Partajările care implică utilizatori sau grupuri lipsă pot fi raportate ca erori în timp ce migrarea continuă. Pentru Cedar Studio, aceasta înseamnă că echipa trebuie să inspecteze ieșirea comenzii și inventarul partajărilor; finalizarea fără o oprire fatală nu este același lucru cu dovada că fiecare partajare funcționează.
Ghidul de migrare precizează că etapele reușite nu pot fi repetate pur și simplu fără a elimina mai întâi datele țintă create. O --forceresetare a inițializării nu elimină fișierele deja migrate din oCIS. Nu utilizați semnalizatoarele de resetare ca strategie de reîncercare de rutină. Dacă o etapă eșuează, păstrați jurnalele, identificați ce a fost creat și consultați ghidul de migrare sau asistența înainte de a decide dacă să reparați ținta sau să reporniți de la una curată.
Pentru o migrare sigură, Cedar Studio ar programa o perioadă în care angajații ar înceta să modifice fișierele în Classic, ar executa migrarea aprobată, apoi ar direcționa clienții și utilizatorii către oCIS numai după trecerea verificărilor. Această înghețare a scrierii este o măsură de siguranță operațională, nu o afirmație că aplicația de migrare efectuează sincronizare live. Ghidul de migrare publicat nu documentează sincronizarea continuă sau o comandă finală de copiere delta. Dacă afacerea nu poate tolera o înghețare a scrierii, solicitați asistenței ownCloud un plan de tranziție specific versiunii înainte de a promite o migrare fără întreruperi.
Validați cu o listă de verificare în loc de o singură autentificare de administrator:
Păstrați versiunea Classic disponibilă într-o stare controlată, doar pentru citire sau altfel înghețată, până când proprietarul afacerii semnează și înregistrările necesare au fost verificate. Eliminați capacitatea temporară de impersonare și revocați token-ul aplicației de migrare atunci când nu mai este necesar. Apoi, realizați și testați o copie de rezervă oCIS utilizând procedura pentru aspectul său de stocare. Considerațiile oficiale privind backup-ul oCIS 8.2 spun că instanța trebuie închisă complet pentru procedura de backup documentată și explică faptul că metadatele și fișierele blob pot avea căi de stocare separate.
În exemplul Cedar Studio, succesul nu constă doar în încărcarea interfeței web oCIS. Înseamnă că angajații se pot autentifica cu sursa de identitate dorită, pot găsi conținutul directorului lor principal, pot deschide fișiere de echipă și pot utiliza partajări recreate sau migrate cu permisiunile așteptate. Resetarea parolelor, montările externe și modificările linkurilor publice sunt luate în considerare, în timp ce Classic rămâne disponibil până la acceptare. Dacă oricare dintre aceste verificări eșuează, întrerupeți trecerea, înregistrați utilizatorii și obiectele afectate și rezolvați lacuna înainte de a trata oCIS ca sistem de înregistrare.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
