Przykładowy scenariusz: Wyobraź sobie fikcyjną, 32-osobową firmę projektową Cedar Studio, która korzysta z ownCloud Classic 10 z katalogiem LDAP, obszarami plików osobistych, udziałami grupowymi, linkami publicznymi i zewnętrznym punktem montowania pamięci masowej projektów. Firma chce przejść na ownCloud Infinite Scale (oCIS), nie zakładając, że instalacja nowego serwera spowoduje przeniesienie danych lub uprawnień. Ten przykład jest hipotetyczny i nie jest raportem z zakończonej migracji.
Obsługiwana ścieżka udokumentowana przez ownCloud to migracja z przewodnikiem, wykorzystująca migrate-to-ocisaplikację na serwerze Classic i occpolecenia. Jest to etapowe przeniesienie do oddzielnego, czystego celu oCIS, a nie aktualizacja bazy danych Classic lub katalogu danych w miejscu instalacji. W podręczniku migracji podano, że źródło pozostaje sprawne przez większość procesu, ale nie opisano ciągłej synchronizacji ani końcowego przejścia delta bez przestojów. Zaplanuj kontrolowane przełączenie i potwierdź zgodność wersji źródłowej oraz ostateczną procedurę zamrożenia zapisu z obsługą ownCloud przed uruchomieniem produkcyjnym.
Poniższe kroki są zgodne z oficjalnym przewodnikiem migracji ownCloud Server 11.0 oraz dokumentacją uwierzytelniania i tworzenia kopii zapasowych Infinite Scale 8.2, dostępnymi od 6 października 2026 r. Składnia poleceń, zmienne środowiskowe i ustalenia dotyczące pomocy technicznej mogą ulec zmianie; należy je sprawdzić w dokumentacji zainstalowanych wersji.
W przypadku Cedar Studio pierwszym zadaniem jest utworzenie listy użytkowników, grup, włączonych i wyłączonych kont, folderów współdzielonych, udostępnionych linków, zewnętrznych punktów montowania oraz wszystkich użytkowników lokalnych, którzy nie są dostępni w LDAP. Rejestrowanie zespołów zależnych od każdego elementu. Pozwala to uniknąć traktowania pomyślnego transferu plików osobistych jako dowodu na to, że wszystkie dotychczasowe przepływy pracy zostały przeniesione.
Zgodnie z przewodnikiem migracji, migracja może przenieść aktywnych użytkowników i grupy z członkostwem, pliki w katalogu domowym każdego aktywnego użytkownika oraz udziały użytkowników, grup i linków. Pliki są umieszczane w osobistej przestrzeni każdego użytkownika w systemie oCIS. Wyłączeni użytkownicy i ich pliki są pomijane. Proces nie obejmuje migracji haseł ani zewnętrznych montowań. Bajty znajdujące się w zewnętrznych montowaniach i otrzymanych udziałach są wyłączone z transferu plików osobistych i muszą być obsługiwane osobno. Zinwentaryzuj te lokalizacje i ręcznie przypisz właściciela migracji.
| Klasyczny przedmiot | Udokumentowane zachowanie migracyjne | Plan dla Cedar Studio |
|---|---|---|
| Włączeni użytkownicy i grupy | Przeniesione lub zmapowane, w zależności od zaplecza tożsamości. | Sprawdź, czy wszystkie oczekiwane konta i członkostwa są widoczne w oCIS. |
| Pliki w katalogach domowych użytkowników | Przeniesione do osobistej przestrzeni każdego użytkownika. | Porównaj reprezentatywne foldery i pliki po przeniesieniu. |
| Udostępnianie użytkowników, grup i łączy | Rekordy udziałów są migrowane w przypadku brakujących użytkowników, grup lub zasad dotyczących łączy i haseł. | Ponownie przetestuj dostęp na kontach właściciela i odbiorcy. |
| Hasła i wyłączone konta | Hasła nie są przenoszone; wyłączeni użytkownicy są pomijani. | Przygotuj wdrożenie konta i sprawdź, które wyłączone konta powinny zostać włączone przed migracją. |
| Zewnętrzne mocowania i otrzymane dane współdzielone | Dane montowania zewnętrznego są wyłączone z transferu pliku. | Utwórz ponownie punkty mocowania lub skopiuj dane źródłowe osobno, a następnie przetestuj dostęp. |
Należy również odnotować, czy używane są publiczne linki bez hasła. Domyślnie oCIS wymaga hasła do linków publicznych; takie klasyczne linki mogą nie zostać przeniesione, chyba że zmieniona zostanie polityka docelowa. Nie należy osłabiać tej polityki tylko po to, aby zachować stare adresy URL. Należy zdecydować, czy właściciele linków powinni zamiast tego tworzyć nowe linki chronione hasłem. Hasła w przeniesionych linkach chronionych hasłem nie będą zgodne ze starymi hasłami, dlatego użytkownicy powinni je zresetować po przełączeniu.
Zbuduj i przetestuj osobną instancję oCIS przed przeniesieniem danych produkcyjnych. Przewodnik migracji wymaga, aby oba systemy działały i były ze sobą połączone. Ostrzega również, że cel powinien być nowy i czysty: istniejący użytkownicy lub dane mogą kolidować z importowaną zawartością. Utwórz kopię zapasową bieżącej instancji Classic i przygotuj plan przywracania, który zapewni jej dostępność do czasu zaakceptowania nowej usługi przez użytkowników.
Migracja wymaga zainstalowania aplikacji dostarczonej przez ownCloud na serwerze Classic. Jest ona dostarczana w ramach prowadzonej migracji; dokumentacja zaleca administratorom kontakt z pomocą techniczną ownCloud w celu jej uzyskania. Aplikacja zawiera własny plik binarny rclone. Nie należy zastępować udokumentowanego procesu tej aplikacji losowym pakietem z Marketplace ani niepowiązanym zadaniem kopiowania plików.
Po stronie oCIS włącz auth-appusługę i ustawienie uwierzytelniania aplikacji. Przewodnik migracji wymaga również, aby personifikacja była aktywna i aby administrator oCIS utworzył token aplikacji. Dokumentacja Infinite Scale 8.2 auth-app wyraźnie stwierdza, że personifikacja jest przeznaczona na potrzeby migracji i nie powinna być włączona we wdrożeniu produkcyjnym. Potraktuj to jako tymczasowe ustawienie migracji: chroń token, ogranicz dostęp do niego i wyłącz personifikację tylko dla migracji po zakończeniu prac. W przypadku wdrożenia rozproszonego zastosuj ustawienia do odpowiedniej usługi zgodnie z dokumentacją.
W przypadku hipotetycznego środowiska Cedar Studio, cel oCIS powinien zostać przetestowany z tą samą usługą LDAP, z której korzysta serwer Classic. Zachowaj poświadczenia w tajnym mechanizmie wdrożenia, zamiast wklejać hasła bind do historii powłoki lub współdzielonego podręcznika. Oficjalny przewodnik migracji ownCloud zawiera listę wymagań docelowych i wskazuje na obsługę ownCloud dla aplikacji do migracji. Przewodnik oCIS 8.2 auth-app wyjaśnia tokeny aplikacji i podszywanie się pod inne osoby.
oCIS musi być w stanie rozpoznać użytkowników i grupy przed migracją ich plików i udziałów. Cedar Studio korzysta już z protokołu LDAP, więc jego administrator powinien połączyć oCIS z tym samym katalogiem, sprawdzić, czy użytkownicy mogą się zalogować i czy identyfikatory są przypisane do odpowiednich kont. Przewodnik ownCloud podaje unikalne, prawidłowe adresy e-mail dla każdego włączonego użytkownika Classic. W przypadku użytkowników Classic obsługiwanych przez LDAP, zwraca również uwagę na atrybut username, zazwyczaj uidlub samAccountName, oraz odpowiadające mu ustawienia schematu LDAP oCIS. Dopasuj atrybuty do rzeczywistego katalogu; nie kopiuj wartości przykładowych bezmyślnie.
Jeśli Classic korzysta z kont lokalnych, ale oCIS będzie korzystać z zewnętrznego katalogu LDAP, przed transferem plików należy utworzyć lub przenieść do niego odpowiednich użytkowników i grupy. Nazwy użytkowników i grup muszą być zgodne. Wewnętrzny oCIS IDM to ograniczony, osadzony katalog przeznaczony do małych instalacji lub testów; ownCloud zaleca korzystanie z prawdziwego LDAP lub zewnętrznego systemu zarządzania tożsamościami do celów produkcyjnych. Oficjalna procedura migracji nie obsługuje mieszanej populacji lokalnych i obsługiwanych przez LDAP użytkowników Classic w jednej gałęzi migracji. Należy rozwiązać ten problem z pomocą techniczną, zamiast improwizować w połowie.
Po zainstalowaniu i włączeniu aplikacji do migracji w wersji Classic dostosuj udokumentowaną ścieżkę i konto usługi do swojej instalacji. W przewodniku wykorzystano /var/www/owncloudi www-datajako przykłady:
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:verifyPolecenie weryfikacji sprawdza, czy włączeni użytkownicy mają prawidłowe, niepowielone adresy e-mail. Rozwiąż zgłoszone problemy przed kontynuacją, zamiast pomijać weryfikację. Jeśli wyłączony użytkownik musi zostać przeniesiony, sprawdź konto, włącz je w wersji Classic przed weryfikacją i uwzględnij w planie migracji. Cedar Studio powinno również zweryfikować logowanie LDAP do oCIS u kilku reprezentatywnych użytkowników przed rozpoczęciem transferu danych.
Postępuj zgodnie z gałęzią w oficjalnym przewodniku, która odpowiada Twojej konfiguracji tożsamości. Jeśli użytkownicy Classic są lokalni i będą korzystać z wbudowanego systemu IDM w oCIS, kolejność działań w przewodniku obejmuje migrację użytkowników, przypisanie roli oCIS oraz migrację grup. Migrowanym użytkownikom przypisana jest jedna rola; role Classic nie są zachowywane jeden do jednego, a uprawnienia subadministratora Classic nie mają równoważnej roli w oCIS. Sprawdź ręcznie uprawnienia administratora. Jeśli oba systemy korzystają z tego samego katalogu LDAP, upewnij się, że użytkownicy i grupy są już dostępne dla oCIS i postępuj zgodnie z gałęzią LDAP, zamiast tworzyć duplikaty.
Gdy użytkownicy, grupy i role są gotowe, udokumentowane polecenia plików i udostępniania używają nazwy użytkownika administratora oCIS jako argumentu końcowego. Hasło administratora Classic jest wymagane interaktywnie:
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 adminUruchom transfer plików przed transferem udziałów, zgodnie z opisem procedury migracji. Użytkownicy, którzy nigdy się nie logowali i nie mają żadnych plików lub których brakuje w oCIS, są pomijani w kroku dotyczącym plików. Udziały z brakującymi użytkownikami lub grupami mogą być zgłaszane jako błędy podczas trwania migracji. W przypadku Cedar Studio oznacza to, że zespół musi sprawdzić dane wyjściowe polecenia i inwentaryzację udziałów; ukończenie bez krytycznego zatrzymania nie jest równoznaczne z dowodem na to, że każdy udział działa.
W przewodniku migracji podano, że pomyślnie ukończonych etapów nie można po prostu powtórzyć bez uprzedniego usunięcia utworzonych danych docelowych. --forceReset inicjalizacji nie usuwa już zmigrowanych plików z oCIS. Nie należy używać flag resetowania jako rutynowej strategii ponawiania prób. Jeśli etap się nie powiedzie, należy zachować logi, zidentyfikować utworzony element i skonsultować się z przewodnikiem migracji lub pomocą techniczną, zanim zdecyduje się, czy naprawić cel, czy uruchomić ponownie na czystym systemie.
Aby zapewnić bezpieczne przejście, Cedar Studio zaplanowało okres, w którym pracownicy przestaliby zmieniać pliki w Classic, uruchomili zatwierdzoną migrację, a następnie przekierowali klientów i użytkowników do oCIS dopiero po pomyślnym zakończeniu kontroli. To zamrożenie zapisu jest zabezpieczeniem operacyjnym, a nie zapewnieniem, że aplikacja do migracji wykonuje synchronizację na żywo. Opublikowany przewodnik po migracji nie dokumentuje ciągłej synchronizacji ani końcowego polecenia delta-copy. Jeśli firma nie toleruje zamrożenia zapisu, należy zwrócić się do wsparcia ownCloud o plan przejścia dla konkretnej wersji, zanim obieca się przejście bez przestoju.
Przeprowadź walidację za pomocą listy kontrolnej zamiast pojedynczego logowania administratora:
Pozostaw wersję Classic dostępną w kontrolowanym trybie tylko do odczytu lub w stanie zamrożonym do momentu zatwierdzenia przez właściciela firmy i sprawdzenia wymaganych rekordów. Usuń tymczasową możliwość personifikacji i unieważnij token aplikacji migracji, gdy nie będzie już potrzebny. Następnie wykonaj i przetestuj kopię zapasową oCIS, korzystając z procedury odpowiedniej dla jej układu pamięci masowej. Oficjalne zasady tworzenia kopii zapasowych w oCIS 8.2 mówią, że instancja musi być całkowicie wyłączona w celu wykonania udokumentowanej procedury tworzenia kopii zapasowej i wyjaśniają, że metadane i pliki bloby mogą mieć oddzielne ścieżki pamięci masowej.
W przykładzie Cedar Studio sukces nie polega jedynie na załadowaniu interfejsu sieciowego oCIS. Oznacza to, że pracownicy mogą uwierzytelniać się przy użyciu docelowego źródła tożsamości, znajdować zawartość swojego katalogu domowego, otwierać pliki zespołu i korzystać z ponownie utworzonych lub zmigrowanych zasobów z oczekiwanymi uprawnieniami. Resetowanie haseł, montowanie zewnętrzne i zmiany łączy publicznych są uwzględniane, a tryb Classic pozostaje dostępny do momentu akceptacji. Jeśli którykolwiek z tych testów zakończy się niepowodzeniem, należy wstrzymać przełączenie, zarejestrować użytkowników i obiekty, których to dotyczy, i rozwiązać problem, zanim oCIS zostanie uznany za system rekordów.
Ustaw maksymalną datę wygaśnięcia łączy publicznych na serwerze ownCloud, sprawdź, których udostępnień ona dotyczy i zweryfikuj zasady, nie pomijając starszych łączy.
Skonfiguruj automatyczną synchronizację Zimbra GAL, ustaw interwał sondowania, wymuś synchronizację testową, zweryfikuj znaczniki czasu i rozwiąż problemy ze starymi wewnętrznymi lub zewnętrznymi kontaktami LDAP.
Skonfiguruj logowanie oparte na protokole LDAP dla ownCloud Infinite Scale, mapuj użytkowników i grupy, wybierz wbudowany lub zewnętrzny OIDC, chroń dane uwierzytelniające i bezpiecznie weryfikuj uwierzytelnianie.
Zaplanuj migrację z ownCloud Classic 10 do Infinite Scale z obsługiwaną aplikacją migrate-to-ocis. Dowiedz się, co podlega transferowi, a co nie, jakie są wymagania wstępne LDAP, polecenia i kontrole przełączenia.
Dowiedz się, gdzie Zimbra ładuje niestandardowe reguły SpamAssassin, jak pisać i weryfikować reguły .cf, ponownie uruchamiać Amavis, testować nagłówki wiadomości i bezpiecznie przywracać poprzednią wersję.
Twórz kopie zapasowe i przywracaj pojedyncze skrzynki pocztowe Zimbra CE za pomocą zmmailbox. Wyeksportuj archiwum ZIP z metadanymi, zweryfikuj je i przetestuj odzyskiwanie bezpiecznie na koncie testowym.
Dowiedz się, jak ustawić limit przestrzeni osobistej dla użytkownika ownCloud Infinite Scale, odróżnić go od limitów przestrzeni projektu i limitów globalnych oraz przypisać wartości domyślne nowym użytkownikom według roli.
Diagnozuj przekroczenia limitu czasu rejestracji SIP w urządzeniu BigBlueButton FreeSWITCH, sprawdzając stan usługi, odbiorniki SIP i ESL, adresy NAT, reguły zapory sieciowej i dzienniki.
Napraw błędy odrzucenia połączenia z aplikacją mobilną ownCloud, sprawdzając adres URL serwera, port HTTPS, serwer WWW, zaporę sieciową, serwer proxy, protokół TLS i zaufane domeny.
Porównaj sposoby kontrolowania nowych kont Matrix w Synapse, od wyłączania rejestracji publicznej po wydawanie tokenów o ograniczonym zastosowaniu, z przykładami konfiguracji i sprawdzeniami.
