Migracja z ((OTRS)) Community Edition do OTOBO

Witamy i dziękujemy za wybór OTOBO! OTRS, ((OTRS)) Community Edition i OTOBO są bardzo wszechstronne i elastyczne w użyciu. Dlatego każda migracja do OTOBO wymaga starannego przygotowania i być może pewnych prac naprawczych.

Prosimy o poświęcenie czasu na migrację i postępowanie zgodnie z tymi instrukcjami krok po kroku.

INFO

Po migracji dane dostępne wcześniej w ((OTRS)) Community Edition 6 będą dostępne w OTOBO 10. Nie zmieniamy żadnych danych z instalacji OTRS 6 podczas migracji.

Przegląd migracji OTOBO

Dzięki interfejsowi migracyjnemu OTOBO możliwe jest zastosowanie następujących strategii migracji:

1. Ogólna strategia migracji.

   Jest to standardowa ścieżka migracji. Obsługiwanych jest wiele różnych kombinacji:

   • Zmiana serwera: Migracja i jednoczesna zmiana serwera aplikacji.

   • Oddzielne serwery aplikacji i sieci: Masz możliwość uruchomienia serwerów aplikacji i baz danych na tym samym hoście lub na dedykowanym hoście. Ten wybór jest niezależny od poprzedniej konfiguracji w OTRS / ((OTRS)) Community Edition.

   • Różne bazy danych: Migracja z dowolnej obsługiwanej bazy danych do innej obsługiwanej bazy danych.

   • Różne systemy operacyjne: Przejście z dowolnego obsługiwanego systemu operacyjnego na inny obsługiwany system operacyjny.

   • Docker: Migracja do instalacji OTOBO 10 opartej na Dockerze.

2. Wariant ogólnej strategii, w którym optymalizowana jest migracja bazy danych.

Użyj migracji typu ETL, jeśli baza danych źródłowa nie może być obciążona zwiększonym ruchem lub jeśli dostęp do bazy danych źródłowej jest wąskim gardłem. W ogólnej strategii dane są odczytywane wiersz po wierszu najpierw z bazy danych otrs, a następnie wstawiane do bazy danych OTOBO. W tym wariancie kompletne tabele bazy danych otrs są najpierw eksportowane, następnie transformowane i na końcu importowane do bazy danych otobo.

3. Migracja z instalacji ((OTRS)) Community Edition 6 opartej na Oracle do instalacji OTOBO opartej na Oracle.

Jest to przypadek specjalny, który nie jest obsługiwany przez ogólną strategię migracji. Oznacza to, że należy zastosować wariant zoptymalizowanej strategii.

WARNING

Wszystkie strategie działają zarówno dla instalacji opartych na Dockerze, jak i dla instalacji natywnych. Jednak w przypadku instalacji opartych na Dockerze należy wziąć pod uwagę pewne specyficzne cechy. Te cechy są omawiane w krokach opcjonalnych.

INFO

Możliwe jest również sklonowanie bazy danych ((OTRS)) Community Edition na serwer bazy danych OTOBO przed faktyczną migracją. Może to przyspieszyć ogólną strategię migracji.

Wymagania dotyczące migracji

1. Podstawowym wymogiem migracji jest posiadanie działającej instalacji ((OTRS)) Community Edition lub OTRS 6.0.* i chęć przeniesienia konfiguracji i danych do OTOBO.

   WARNING

   Proszę dokładnie rozważyć, czy dane i konfiguracja są naprawdę potrzebne. Doświadczenie pokazuje, że w wielu przypadkach ponowne rozpoczęcie pracy jest lepszą opcją. Dzieje się tak dlatego, że wcześniej używana instalacja i konfiguracja były często dalekie od optymalnych. Może być również sensowne przenieść tylko dane biletów i dostosować podstawową konfigurację do najlepszych praktyk OTOBO.

2. Aby rozpocząć migrację, potrzebujesz działającej instalacji OTOBO!

3. Ta instalacja OTOBO musi zawierać wszystkie pakiety OPM, które są zainstalowane w Twojej ((OTRS)) Community Edition i które chcesz również używać w OTOBO.

4. Jeśli planujesz migrację na inny serwer, serwer sieciowy OTOBO musi mieć dostęp do lokalizacji, w której zainstalowano Twoją ((OTRS)) Community Edition lub OTRS 6.0.*. W większości przypadków jest to katalog _/opt/otrs* na serwerze, na którym działa ((OTRS)) Community Edition. Dostęp do odczytu można uzyskać za pomocą SSH lub montowania systemu plików.

5. Baza danych ((otrs)) Community Edition musi być dostępna z serwera, na którym działa OTOBO. Dostęp tylko do odczytu musi być udzielony dla hostów zewnętrznych. Jeśli dostęp nie jest możliwy lub jeśli prędkość migracji ma zostać zoptymalizowana, wystarczy zrzut bazy danych.

INFO

Jeśli dostęp SSH i do bazy danych między serwerami nie jest możliwy, proszę migrować ((OTRS)) Community Edition do OTOBO na tym samym serwerze, a następnie przenieść nową instalację.

Instrukcja krok po kroku

Krok 1: Instalacja OTOBO

Proszę rozpocząć od instalacji nowego systemu OTOBO. Twoja stara instalacja OTRS / ((OTRS)) Community Edition zostanie do niej zmigrowana.

WARNING

W przypadku Apache istnieją pułapki podczas uruchamiania dwóch niezależnych aplikacji mod_perl na tym samym serwerze sieciowym. Dlatego zaleca się uruchamianie ((OTRS)) Community Edition i OTOBO na oddzielnych serwerach sieciowych. Alternatywnie, konfiguracja OTRS powinna zostać usunięta z Apache przed instalacją OTOBO. Użyj polecenia a2query -s i sprawdź katalogi /etc/apache2/sites-available i /etc/apache2/sites-enabled, aby zobaczyć, które konfiguracje są aktualnie dostępne i aktywne.

Po zakończeniu instalacji proszę zalogować się jako root@localhost. Przejdź do obszaru administracyjnego OTOBO Admin -> Pakiety i zainstaluj wszystkie wymagane pakiety OTOBO OPM.

Następujące pakiety OPM i "Dodatki funkcyjne" ((OTRS)) Community Edition NIE MUSZĄ i NIE POWINNY być instalowane, ponieważ te funkcje są już zawarte w standardzie OTOBO:

• OTRSHideShowDynamicField
• RotherOSSHideShowDynamicField
• TicketForms
• RotherOSS-LongEscalationPerformanceBoost
• Znuny4OTRS-AdvancedDynamicFields
• Znuny4OTRS-AutoSelect
• Znuny4OTRS-EscalationSuspend
• OTRSEscalationSuspend
• OTRSDynamicFieldDatabase
• OTRSDynamicFieldWebService
• OTRSBruteForceAttackProtection
• Znuny4OTRS-ExternalURLJump
• Znuny4OTRS-QuickClose
• Znuny4OTRS-AutoCheckbox
• OTRSSystemConfigurationHistory
• Znuny4OTRS-PasswordPolicy

Następujące pakiety OTOBO Pakiety zostały zintegrowane w OTOBO 10+. Oznacza to, że nie powinny być instalowane w systemie docelowym, jeśli system docelowy jest OTOBO 10+. - ImportExport

Krok 2: Wyłączenie SecureMode

Po zainstalowaniu OTOBO proszę ponownie zalogować się do obszaru administracyjnego OTOBO Admin -> Konfiguracja systemu i wyłączyć opcję konfiguracji SecureMode.

INFO

Nie zapomnij faktycznie zaimplementować zmienionego ustawienia.

Krok 3: Zatrzymanie demona OTOBO

Jest to konieczne, jeśli demon OTOBO faktycznie działa. Zatrzymanie demona różni się w zależności od instalacji opartych na Dockerze i tych nieopartych na Dockerze.

W przypadku nie-Dockerowym wykonaj następujące polecenia jako użytkownik otobo:

# jeśli jesteś zalogowany jako root

root> su - otobo

otobo> /opt/otobo/bin/Cron.sh stop

otobo> /opt/otobo/bin/otobo.Daemon.pl stop --force

Jeśli OTOBO działa w Dockerze, wystarczy zatrzymać usługę daemon:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 powinien zostać zakończony z kodem 0

INFO

Zaleca się wykonanie kopii zapasowej całego systemu OTOBO w tym momencie. Jeśli coś pójdzie nie tak podczas migracji, nie będziesz musiał powtarzać całego procesu instalacji, ale zamiast tego zaimportować kopie zapasowe do nowej migracji.

TIP

Zalecamy przeczytanie rozdziału Kopia zapasowa OTOBO backup-restore.

Opcjonalne montowanie /opt/otrs

Często OTOBO ma działać na nowym serwerze, gdzie /opt/otrs początkowo nie jest dostępny. W takich przypadkach katalog /opt/otrs z serwera ((OTRS)) Community Edition można zamontować w systemie plików serwera OTOBO. Jeśli zwykłe montowanie sieciowe nie jest możliwe, sshfs może być opcją.

Opcjonalnie: sshpass i rsync

Ten krok jest wymagany tylko wtedy, gdy chcesz migrować ((OTRS)) Community Edition z innego serwera i /opt/otrs nie został zamontowany na serwerze OTOBO z serwera zdalnego.

Narzędzia sshpass i rsync są potrzebne, aby migration.pl mógł kopiować pliki przez ssh. Aby zainstalować sshpass, zaloguj się jako użytkownik root na serwerze i wykonaj jedno z poniższych poleceń:

Instalacja sshpass w systemie Debian / Ubuntu Linux

sudo apt install sshpass

Instalacja sshpass w systemie RHEL/CentOS Linux

sudo yum install sshpass

Instalacja sshpass w systemie Fedora Linux

sudo dnf install sshpass

Instalacja sshpass w systemie OpenSUSE Linux

sudo zypper install sshpass

To samo należy zrobić dla rsync, jeśli nie jest jeszcze dostępny.

Krok 4: Przygotowanie

INFO

Upewnij się, że masz również ważną kopię zapasową swojego systemu OTRS / ((OTRS)) Community Edition. Tak, nie dotykamy danych ((OTRS)) Community Edition podczas migracji, ale czasami jeden zły wpis wystarczy, aby spowodować problemy.

Teraz jesteśmy gotowi do migracji. Najpierw musimy upewnić się, że żadne bilety nie są już przetwarzane i że żaden użytkownik nie loguje się do ((OTRS)) Community Edition:

Proszę zalogować się do obszaru administracyjnego ((OTRS)) Community Edition Admin -> Konserwacja systemu i dodać nowy slot konserwacji systemu na kilka godzin. Następnie usuń wszystkie sesje agentów i użytkowników (Admin -> Sesje) i wyloguj się.

Zatrzymanie wszystkich odpowiednich usług i demona OTRS

Proszę upewnić się, że żadne usługi ani zadania cron nie są uruchomione.

su - otrs
/opt/otrs/bin/Cron.sh stop
/opt/otrs/bin/otrs.Daemon.pl stop --force

Usunięcie danych tymczasowych i operacyjnych

Dane tymczasowe i operacyjne nie muszą być migrowane. Kolejka e-mail powinna być już pusta w tym momencie.

su - otrs
/opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
/opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
/opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup
/opt/otrs/bin/otrs.Console.pl Maint::WebUploadCache::Cleanup
/opt/otrs/bin/otrs.Console.pl Maint::Email::MailQueue --delete-all

Opcjonalny krok dla Dockera

Istnieją pewne specyficzne cechy, które należy wziąć pod uwagę, jeśli Twoja instalacja OTOBO działa pod kontrolą Dockera. Najważniejsze: procesy działające w kontenerze Docker generalnie nie mogą uzyskiwać dostępu do katalogów poza kontenerem. Istnieje jednak wyjątek: katalogi zamontowane jako wolumeny do kontenera mogą być dostępne. Należy również pamiętać, że baza danych MariaDB działająca w otobo_db_1 (otobo-db-1 w nowszych wersjach docker compose) nie jest bezpośrednio dostępna spoza sieci kontenera.

INFO

W przykładowych poleceniach zakładamy, że użytkownik docker_admin jest używany do interakcji z Dockerem. Administrator Dockera może być albo użytkownikiem root hosta Dockera, albo dedykowanym użytkownikiem z odpowiednimi uprawnieniami.

Kopiowanie /opt/otrs do wolumenu otobo_opt_otobo

::: note Nazwy kontenerów W starych wersjach docker compose nazwy kontenerów to otobo_web_1, otobo_db_1 i otobo_daemon_1. W nowszych wersjach nazwy kontenerów to otobo-web-1, otobo-db-1 i otobo-daemon-1.

:::

W tym rozdziale zakładamy, że katalog domowy OTRS /opt/otrs jest dostępny na hoście Docker.

Istnieją co najmniej dwa praktyczne sposoby:

a. Skopiuj /opt/otrs do istniejącego wolumenu otobo_opt_otobo

b. Zamontuj /opt/otrs jako dodatkowy wolumen

Skupmy się tutaj na opcji a.

Najpierw musimy dowiedzieć się, gdzie wolumen otobo_opt_otobo jest dostępny na hoście Docker.

 otobo_opt_otobo_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_opt_otobo)
echo $otobo_opt_otobo_mp

Dla bezpiecznego kopiowania używamy rsync. W zależności od konfiguracji Dockera, polecenie rsync może wymagać uruchomienia z sudo.

rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # tylko do sprawdzenia
sudo rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
sudo ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # tylko do sprawdzenia

Ten skopiowany katalog będzie dostępny wewnątrz kontenera jako /opt/otobo/var/tmp/copied_otrs.

Krok 5: Migracja danych

:::note Polecenie Docker Compose W starych wersjach Docker Compose używano polecenia docker-compose. W nowszych wersjach używa się docker compose. :::

Proszę użyć narzędzia do migracji przez sieć pod adresem http://localhost/otobo/migration.pl. Należy pamiętać, że być może trzeba będzie zastąpić "localhost" nazwą hosta OTOBO i ewentualnie dodać niestandardowy port. Aplikacja przeprowadzi Cię przez proces migracji.

WARNING

Czasami wyświetlane jest ostrzeżenie, że wyłączenie SecureMode nie zostało wykryte. W takim przypadku proszę zrestartować serwer sieciowy. Wymusi to na serwerze sieciowym odczytanie bieżącej konfiguracji.

service apache2 restart
cd /opt/otobo-docker
docker-compose restart web
docker-compose ps

INFO

Jeśli OTOBO działa w kontenerze Docker, zachowaj domyślne ustawienia localhost dla serwera OTRS i /opt/otobo/var/tmp/copied_otrs dla katalogu domowego OTRS. Jest to ścieżka danych skopiowanych w kroku opcjonalnym.

INFO

Domyślne wartości dla użytkownika i hasła bazy danych OTRS są pobierane z Kernel/Config.pm w katalogu domowym OTRS. Zmień sugerowane ustawienia, jeśli używasz dedykowanego użytkownika bazy danych do migracji. Zmień również ustawienia, jeśli pracujesz z bazą danych, która została skopiowana do kontenera Docker otobo_db_1.

INFO

W przypadku Dockera baza danych działająca na hoście Docker nie jest dostępna przez 127.0.0.1 wewnątrz kontenera Docker. Oznacza to, że ustawienie 127.0.0.1 nie będzie prawidłowe dla pola wejściowego OTRS-Server. W takim przypadku podaj jeden z alternatywnych adresów IP zgłoszonych przez polecenie hostname --all-ip-addresses dla OTRS-Server.

INFO

Podczas migracji na nowy serwer aplikacji lub do instalacji opartej na Dockerze, baza danych często nie jest dostępna z instalacji docelowej. Zwykle dzieje się tak dlatego, że użytkownik bazy danych otobo może połączyć się tylko z hosta, na którym działa baza danych. Aby umożliwić dostęp, zaleca się utworzenie dedykowanego użytkownika bazy danych do migracji, np. CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; i GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Ten użytkownik może zostać usunięty po migracji: DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

Ustawienia specyficzne dla użytkownika w Kernel/Config.pm są przenoszone ze starej instalacji OTRS do nowej instalacji OTOBO. Jeśli masz ustawienia specyficzne dla użytkownika, powinieneś przyjrzeć się zmigrowanemu plikowi /opt/otobo/Kernel/Config.pm. Możesz chcieć dostosować niestandardowe ścieżki lub ustawienia LDAP. W najlepszym przypadku stwierdzisz, że niektóre niestandardowe ustawienia nie są już potrzebne.

Po zakończeniu migracji proszę poświęcić czas na przetestowanie całego systemu. Gdy zdecydujesz, że migracja zakończyła się sukcesem i chcesz używać OTOBO od teraz, uruchom demon OTOBO:

su - otobo
/opt/otobo/bin/Cron.sh start
/opt/otobo/bin/otobo.Daemon.pl start

W przypadku Dockera:

cd ~/otobo-docker
docker-compose start daemon

Krok 6: Czyszczenie

1. Odinstaluj sshpass, jeśli nie jest już potrzebny.

2. Usuń bazy danych i użytkowników baz danych utworzonych specjalnie do migracji, jeśli istnieją.

3. Baw się dobrze z OTOBO!

Znane problemy z migracją

Brak możliwości zalogowania po migracji

Podczas naszych testów migracyjnych przeglądarka używana do migracji czasami sprawiała problemy. Po ponownym uruchomieniu przeglądarki problem ten zazwyczaj ustępował. W przypadku Safari czasami trzeba było ręcznie usunąć starą sesję OTRS.

Końcowa strona migracji ma dziwny układ

Może się tak zdarzyć, jeśli ustawienie ScriptAlias ma niestandardową wartość. Migracja po prostu zastępuje otrs przez otobo. Może to spowodować, że pliki CSS i JavaScript w OTOBO nie będą już pobierane. Jeśli tak się stanie, proszę sprawdzić ustawienia w Kernel/Config.pm i zmienić je z powrotem na rozsądne wartości.

Migracja zatrzymuje się z powodu błędów MySQL

W systemach, które miały problemy z aktualizacją w przeszłości, proces migracji może zatrzymać się z powodu błędów MySQL w tabelach ticket i ticket_history. Zazwyczaj są to wartości NULL w tabeli źródłowej, które nie są już dozwolone w tabeli docelowej. Te konflikty muszą zostać rozwiązane ręcznie przed kontynuowaniem migracji.

Od wersji OTOBO 10.0.12 istnieje kontrola w migration.pl, która sprawdza wartości NULL przed transferem danych. Należy pamiętać, że rozwiązanie nadal musi być wykonane ręcznie.

Błąd w kroku 5 podczas migracji do PostgreSQL

W tych przypadkach niepomocna wiadomość "System nie mógł zakończyć transferu danych." jest wyświetlana przez migration.pl. Plik dziennika Apache i plik dziennika OTOBO pokazują bardziej znaczącą wiadomość: " Komunikat o błędzie: ERROR: permission denied to set parameter "session_replication_role", SQL: 'set session_replication_role to replica;'" Aby nadać użytkownikowi bazy danych otobo wymagane uprawnienia superużytkownika, wykonaj następujące polecenie jako administrator PostgreSQL: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Następnie spróbuj ponownie wykonać http://localhost/otobo/migration.pl. Po migracji wróć do normalnego stanu, wykonując ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Nie jest jeszcze jasne, czy rozszerzone uprawnienia muszą być przyznawane w każdym środowisku.

TIP

Dyskusja na forum OTOBO Forum

Problemy z wdrażaniem połączonej konfiguracji systemu

Konfiguracja systemu jest migrowana po migracji tabel baz danych. W tym kontekście migracja oznacza, że domyślne ustawienia OTOBO są łączone z konfiguracją systemu źródłowego OTRS. W tym kroku mogą wystąpić niespójności. Przykład z praktyki to ustawienie Ticket::Frontend::AgentTicketQuickClose###State. To ustawienie jest nowe w OTOBO 10, a domyślną wartością jest stan closed successful. Ale to ustawienie jest nieprawidłowe, jeśli stan closed successful został usunięty lub zmieniony w systemie źródłowym. Ta niespójność jest wykrywana jako błąd w kroku migracji Migrate configuration settings. Połączona konfiguracja systemu jest faktycznie zapisywana w bazie danych, ale dodatkowe kontrole poprawności są wykonywane podczas wdrażania.

Problem musi zostać rozwiązany ręcznie za pomocą poleceń konsoli OTOBO.

• Wyświetla niespójności za pomocą polecenia bin/otobo.Console.pl Admin::Config::ListInvalid.

• Naprawia nieprawidłowe wartości interaktywnie za pomocą bin/otobo.Console.pl Admin::Config::FixInvalid.

• Wdraża zebrane zmiany z migration.pl, w tym wyłączony SecureMode, za pomocą bin/otobo.Console.pl Maint::Config::Rebuild.

Po wykonaniu tych ręcznych kroków powinieneś być w stanie ponownie uruchomić migration.pl. Migracja będzie kontynuowana od kroku, w którym wystąpił błąd.

Końcowe zadania ręczne

Reguły polityki haseł

Z OTOBO 10 wchodzi w życie nowa domyślna polityka haseł dla agentów i użytkowników klientów przy użyciu lokalnej uwierzytelniania. Reguły polityki haseł można zmienić w konfiguracji systemu (PreferencesGroups###Password i CustomerPersonalPreference###Password).

| Reguła polityki haseł | Domyślna |

|-------------------------------------------|--------------------|

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Tak |

| PasswordNeedDigit | Tak |

| PasswordHistory | 10 |

| PasswordTTL | 30 dni |

| PasswordWarnBeforeExpiry | 5 dni |

| PasswordChangeAfterFirstLogin | Tak |

W Dockerze: Ręczna migracja zadań Cron

W instalacji OTOBO nie opartej na Dockerze istnieje co najmniej jedno zadanie cron, które sprawdza stan demona. W Dockerze to zadanie cron już nie istnieje. Ponadto żaden demon cron nie działa w żadnym z kontenerów Docker. Oznacza to, że musisz szukać indywidualnego rozwiązania dla systemów OTRS z niestandardowymi zadaniami cron (np. kopia zapasowa bazy danych).

Migracja z Oracle do Oracle

W przypadku migracji do Oracle należy zastosować strategię podobną do ETL. Dzieje się tak dlatego, że Oracle nie oferuje prostego sposobu na tymczasowe wyłączenie sprawdzania kluczy obcych.

Na hoście OTOBO musi być zainstalowany klient Oracle oraz moduł Perla DBD::Oracle.

INFO

W przypadku korzystania z Oracle Instant Client, opcjonalny pakiet SDK jest również wymagany do instalacji DBD:: Oracle.

Istnieje wiele sposobów klonowania schematu. W przykładowych poleceniach używamy expdp i impdp, które wykorzystują Data Pump w tle.

INFO

Ciągi połączeń pokazane w tej dokumentacji odnoszą się do przypadku, gdy zarówno baza danych źródłowa, jak i docelowa działają w kontenerze Docker. Zobacz również https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Czyszczenie otobo

Zatrzymaj serwer sieciowy dla otobo, aby połączenie z bazą danych dla otobo zostało zamknięte.

DROP USER otobo CASCADE

2. Eksport całego schematu OTRS.

mkdir /tmp/otrs_dump_dir

CREATE DIRECTORY OTRS_DUMP_DIR AS '/tmp/otrs_dump_dir';

GRANT READ, WRITE ON DIRECTORY OTRS_DUMP_DIR TO sys;

expdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" schemas=otrs directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=expdpotrs.log

3. Importuj schemat OTRS i zmień nazwę schematu na 'otobo'.

impdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=impdpotobo.log remap_schema=otrs:otobo

select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';
    ALTER USER otobo IDENTIFIED BY XXXXXX;

4. Dostosowanie sklonowanego schematu otobo

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # jest w porządku, że polecenie wie tylko o bazie danych otobo, tylko ostatnia linia jest istotna

sqlplus otobo/otobo@//127.0.0.1/orclpdb1.localdomain < /home/bernhard/devel/OTOBO/otobo/2021-03-31_13-36-55/orclpdb1.localdomain_post.sql >sqlplus.out 2>&1

Aby sprawdzić, użyj `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Ponownie uruchom serwer sieciowy dla OTOBO

6. Kontynuuj od kroku 5, czyli uruchom migration.pl.

INFO

Podczas migracji do wersji OTOBO 10.1 lub nowszej, skrypt /opt/otobo/scripts/DBUpdate-to-10.1.pl musi zostać wykonany, aby utworzyć nowe tabele stats_report i data_storage dodane w wersji 10.1.

Opcjonalnie: Uproszczona migracja bazy danych (tylko dla ekspertów i specjalnych scenariuszy)

W ogólnej strategii migracji wszystkie dane w tabelach baz danych są kopiowane wiersz po wierszu z bazy danych OTRS do bazy danych OTOBO. Eksportowanie danych z bazy danych OTRS i importowanie ich do bazy danych OTOBO może zaoszczędzić czas i w niektórych przypadkach jest bardziej stabilne.

INFO

Ten wariant działa zarówno dla instalacji opartych na Dockerze, jak i dla instalacji natywnych.

INFO

Te instrukcje zakładają, że ((OTRS)) Community Edition używa MySQL jako backendu.

Przede wszystkim potrzebujemy zrzutu wymaganych tabel bazy danych OTRS. Następnie musimy przeprowadzić pewne transformacje:

• Konwersja zestawu znaków do utf8mb4

• Zmiana nazwy niektórych tabel

• Skracanie niektórych kolumn tabel

Po transformacji możemy nadpisać tabele w schemacie OTOBO przetworzonymi danymi z OTRS. W rzeczywistości nie potrzebujemy jednego pliku zrzutu, ale kilku skryptów SQL.

Jeśli mysqldump jest zainstalowany i możliwy jest dostęp do bazy danych OTRS, możesz utworzyć zrzut bazy danych bezpośrednio na hoście Docker. Ten przypadek jest obsługiwany przez skrypt bin/backup.pl.

WARNING

Wymaga to dostępności instalacji OTOBO na hoście Docker.

cd /opt/otobo
scripts/backup.pl -t migratefromotrs --db-name otrs --db-host=127.0.0.1 --db-user otrs --db-password "secret_otrs_password"

INFO

Alternatywnie, baza danych może zostać zrobiona kopia zapasowa na innym serwerze, a następnie przeniesiona na host Docker. Prosty sposób na zrobienie tego to skopiowanie /opt/otobo na serwer, na którym działa OTRS, i wykonanie tego samego polecenia, co powyżej.

Skrypt bin/backup.pl generuje cztery skrypty SQL w katalogu zrzutu, np. w 2021-04-13_12-13-04. Aby wykonać skrypty SQL, musimy wykonać polecenie mysql.

Instalacja natywna:

cd <dump_dir>
mysql -u root -p<root_secret> otobo < otrs_pre.sql
mysql -u root -p<root_secret> otobo < otrs_schema_for_otobo.sql
mysql -u root -p<root_secret> otobo < otrs_data.sql
mysql -u root -p<root_secret> otobo < otrs_post.sql

Instalacja oparta na Dockerze:

Wykonaj polecenie mysql wewnątrz kontenera db Dockera, aby zaimportować pliki zrzutu bazy danych. Należy pamiętać, że hasło dla roota bazy danych jest teraz hasłem ustawionym w pliku .env na hoście Docker.

cd /opt/otobo-docker
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_pre.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_schema_for_otobo.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_data.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_post.sql

Aby szybko sprawdzić, czy import się powiódł, możesz wykonać następujące polecenia.

mysql -u root -p<root_secret> -e 'SHOW DATABASES'
mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

lub podczas wykonywania w Dockerze

docker-compose exec -T db mysql -u root -p<root_secret> -e 'SHOW DATABASES'
docker-compose exec -T db mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
docker-compose exec -T db mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

Baza danych została teraz zmigrowana. Oznacza to, że w następnym kroku możemy pominąć migrację bazy danych. Zwróć uwagę na odpowiednie pole wyboru.