Migracja z edycji community ((OTRS)) do OTOBO

Witamy i dziękujemy za wybór OTOBO!
OTRS, edycja community ((OTRS)) oraz OTOBO są bardzo elastyczne i wszechstronne w użytkowaniu. Dlatego każda migracja do OTOBO wymaga dokładnego przygotowania i może wymagać dodatkowej pracy.

Prosimy poświęcić czas na proces migracji i postępować zgodnie z poniższymi instrukcjami krok po kroku.

INFO

Po migracji dane wcześniej dostępne w edycji community ((OTRS)) 6 będą dostępne w OTOBO 10.
Nie modyfikujemy żadnych danych z instalacji OTRS 6 podczas procesu migracji.

Przegląd migracji OTOBO

Za pomocą interfejsu migracyjnego OTOBO możliwe jest zastosowanie następujących strategii migracji:

1. Ogólna strategia migracji.

   To standardowy sposób przeprowadzania migracji. Obsługiwane są różne kombinacje:

   • Zmiana serwera: Migracja z jednoczesnym przejściem na nowy serwer aplikacji.

   • Oddzielne serwery aplikacji i bazy danych: Możliwość uruchamiania serwera aplikacji i bazy danych na tym samym hoście lub na osobnych, dedykowanych hostach. Ta decyzja nie zależy od poprzedniej konfiguracji w OTRS / edycji community ((OTRS)).

   • 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 podobnej do ETL, jeśli źródłowa baza danych nie może być obciążona dodatkowym ruchem lub jeśli dostęp do źródłowej bazy danych stanowi wąskie gardło. W ogólnej strategii dane są odczytywane wiersz po wierszu z bazy danych otrs, a następnie wstawiane do bazy danych OTOBO. W tej wersji całe tabele bazy danych otrs są najpierw eksportowane, następnie przekształcane, a potem importowane do bazy danych otobo.

3. Migracja z opartej na Oracle edycji community ((OTRS)) 6 instalacji do instalacji OTOBO opartej na Oracle.

   Jest to przypadek szczególny, który nie jest obsługiwany przez ogólną strategię migracji. Oznacza to, że należy użyć wariantu optymalizowanej strategii.

WARNING

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

INFO

Możliwe jest również sklonowanie bazy danych edycji community ((OTRS)) na serwer bazy danych OTOBO przed właściwą migracją. Może to przyspieszyć ogólną strategię migracji.

Wymagania dotyczące migracji

1. Podstawowym warunkiem migracji jest posiadanie działającej edycji community ((OTRS)) lub OTRS 6.0.*, z którego chcesz przenieść zarówno konfigurację, jak i dane do OTOBO.

   WARNING

   Dokładnie przemyśl, czy rzeczywiście potrzebujesz danych i konfiguracji. Doświadczenie pokazuje, że w wielu przypadkach lepszym rozwiązaniem jest rozpoczęcie od nowa. Wynika to z faktu, że poprzednia instalacja i konfiguracja często były suboptymalne. Może również mieć sens przeniesienie tylko danych zgłoszeń i dostosowanie podstawowej konfiguracji do najlepszych praktyk OTOBO.

2. Potrzebujesz działającej instalacji OTOBO, aby z niej rozpocząć migrację!

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

4. Jeśli planujesz migrację na inny serwer, serwer WWW OTOBO musi mieć dostęp do lokalizacji, w której zainstalowana jest Twoja edycja community ((OTRS)) lub OTRS 6.0._. W większości przypadków chodzi o katalog _/opt/otrs* na serwerze, na którym działa edycja community ((OTRS)). Dostęp do odczytu może odbywać się przez SSH lub przez montowanie systemu plików.

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

INFO

Jeśli dostęp przez SSH i bazę danych między serwerami nie jest możliwy, przeprowadź migrację edycji community ((OTRS)) do OTOBO na tym samym serwerze, a dopiero potem przenieś nową instalację.

Instrukcja krok po kroku

Krok 1: Instalacja OTOBO

Zacznij od instalacji nowego systemu OTOBO. Twoja stara instalacja OTRS / edycji community ((OTRS)) zostanie przeniesiona do tego nowego systemu.

WARNING

W Apache występują pułapki związane z uruchamianiem dwóch niezależnych aplikacji mod_perl na tym samym serwerze WWW. Dlatego zaleca się uruchamianie edycji community ((OTRS)) i OTOBO na oddzielnych serwerach WWW. Alternatywnie należy usunąć konfigurację OTRS z Apache przed instalacją OTOBO. Użyj polecenia a2query -s i sprawdź katalogi /etc/apache2/sites-available oraz /etc/apache2/sites-enabled, aby zobaczyć, które konfiguracje są obecnie dostępne i włączone.

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

Następujące pakiety OPM i dodatki funkcjonalne edycji community ((OTRS)) 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-Pakiet zostały zintegrowane w OTOBO 10+. Oznacza to, że nie powinny być one instalowane w systemie docelowym, jeśli system docelowy to OTOBO 10+:

• ImportExport

Krok 2: Wyłączenie SecureMode

Po zainstalowaniu OTOBO ponownie zaloguj się w obszarze administracyjnym OTOBO Admin -> Konfiguracja systemu i wyłącz opcję konfiguracyjną SecureMode.

INFO

Nie zapomnij faktycznie wdrożyć zmienionej 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 opartej na Dockerze i nieopartej na Dockerze.

W przypadku instalacji nieopartej na Dockerze 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 zakończyć działanie z kodem 0

INFO

Zaleca się wykonanie kopii zapasowej całego systemu OTOBO w tym momencie. Jeśli podczas migracji coś pójdzie nie tak, nie musisz powtarzać całego procesu instalacji, ale możesz zaimportować kopię zapasową do nowej migracji.

TIP

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

Opcjonalnie zamontuj /opt/otrs

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

Opcjonalnie: sshpass i rsync

Ten krok jest potrzebny tylko wtedy, gdy chcesz przeprowadzić migrację edycji community ((OTRS)) z innego serwera, a katalog /opt/otrs z serwera zdalnego nie został zamontowany na serwerze OTOBO.

Narzędzia sshpass i rsync są potrzebne, aby migration.pl mogło kopiować pliki przez ssh. Aby zainstalować sshpass, zaloguj się jako użytkownik root na serwerze i wykonaj jedno z następujących poleceń:

Zainstaluj sshpass w Debianie / Ubuntu Linux

sudo apt install sshpass

Zainstaluj sshpass w RHEL/CentOS Linux

sudo yum install sshpass

Zainstaluj sshpass w Fedora Linux

sudo dnf install sshpass

Zainstaluj sshpass w OpenSUSE Linux

sudo zypper install sshpass

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

Krok 4: Przygotowanie

INFO

Upewnij się, że masz również ważną kopię zapasową swojego systemu OTRS / edycji community ((OTRS)). Tak, nie dotykamy danych edycji community ((OTRS)) podczas migracji, ale czasem wystarczy jeden błędny wpis, aby spowodować problemy.

Teraz jesteśmy gotowi do migracji. Najpierw musimy upewnić się, że żadne zgłoszenia nie są już edytowane i żaden użytkownik nie loguje się do edycji community ((OTRS)):

Zaloguj się do obszaru administracyjnego edycji community ((OTRS)) Admin -> Konserwacja systemu i dodaj nowy przedział 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

Upewnij 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 pamięci podręcznej i danych operacyjnych

Dane z pamięci podręcznej i dane 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 Docker

Istnieją pewne szczegóły, które należy wziąć pod uwagę, jeśli Twoja instalacja OTOBO działa w Dockerze. Najważniejszy: procesy działające w kontenerze Docker nie mogą zazwyczaj uzyskać dostępu do katalogów poza kontenerem. Istnieje jednak wyjątek: katalogi zamontowane jako woluminy do kontenera są 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 z zewnątrz sieci kontenera.

INFO

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

Skopiuj /opt/otrs do woluminu 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 tej sekcji zakładamy, że katalog domowy OTRS /opt/otrs jest dostępny na hoście Docker.

Istnieją co najmniej dwie praktyczne możliwości:

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

b. Zamontuj /opt/otrs jako dodatkowy wolumin

Skupimy się tutaj na opcji a..

Najpierw musimy ustalić, gdzie wolumin 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

Do bezpiecznego kopiowania używamy rsync. W zależności od konfiguracji Docker 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 weryfikacji
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 weryfikacji

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

Krok 5: Migrowanie danych

:::note Polecenie Docker Compose W starych wersjach Docker Compose używano polecenia docker-compose.
W nowszych wersjach używane jest docker compose. :::

Użyj narzędzia migracyjnego webowego pod adresem http://localhost/otobo/migration.pl. Pamiętaj, że być może musisz zastąpić "localhost" nazwą hosta OTOBO i dodać niestandardowy port. Aplikacja poprowadzi Cię przez proces migracji.

WARNING

Czasami pojawia się ostrzeżenie, że wyłączenie SecureMode nie zostało wykryte. W takim przypadku uruchom ponownie serwer WWW. To zmusi serwer WWW do ponownego załadowania 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 ustawienia domyślne 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 użytkownika i hasła bazy danych OTRS są pobierane z pliku Kernel/Config.pm w katalogu domowym OTRS. Zmień proponowane ustawienia, jeśli używasz dedykowanego użytkownika bazy danych do migracji. Zmień również ustawienia, jeśli pracujesz z bazą danych skopiowaną do kontenera Docker otobo_db_1.

INFO

W przypadku Docker baza danych działająca na hoście Docker nie jest dostępna z kontenera Docker przez 127.0.0.1. Oznacza to, że ustawienie 127.0.0.1 nie będzie ważne dla pola wejściowego Serwer OTRS. W takim przypadku wprowadź jedną z alternatywnych adresów IP zwróconych przez polecenie hostname --all-ip-addresses dla Serwer OTRS.

INFO

Podczas migracji do nowego serwera aplikacji lub do instalacji opartej na Docker instalacja często nie może uzyskać dostępu do bazy danych. Zazwyczaj jest to spowodowane tym, że użytkownik bazy danych otobo może łą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 użytkownika w pliku Kernel/Config.pm są przenoszone ze starej instalacji OTRS do nowej instalacji OTOBO. Jeśli masz ustawienia użytkownika, warto rzucić okiem na zmigrowany plik /opt/otobo/Kernel/Config.pm. Być może zechcesz dostosować niestandardowe ścieżki lub ustawienia LDAP. W najlepszym przypadku okaże się, że niektóre niestandardowe ustawienia nie są już potrzebne.

Po zakończeniu migracji poświęć czas i przetestuj cały system. Gdy zdecydujesz, że migracja zakończyła się sukcesem i chcesz od teraz używać OTOBO, uruchom demona OTOBO:

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

W przypadku Docker:

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 bazy danych utworzone specjalnie do migracji, jeśli istnieją.

3. Miłej pracy z OTOBO!

Znane problemy z migracją

Nie można się zalogować po migracji

Podczas naszych testów migracyjnych przeglądarka używana do migracji czasem miała problemy. Po ponownym uruchomieniu przeglądarki problem był zwykle rozwiązany. W przypadku Safari czasem trzeba było ręcznie usunąć starą sesję OTRS.

Ostateczna strona migracji ma dziwny układ

Może się to 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 mogą być już pobierane. W takim przypadku sprawdź ustawienia w pliku Kernel/Config.pm i przywróć je do rozsądnych wartości.

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

Na systemach, które miały wcześniej problemy z aktualizacją, proces migracji może zatrzymać się z powodu błędów MySQL w tabelach ticket i ticket_history. Zazwyczaj chodzi o 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 kontynuacją migracji.

Od OTOBO 10.0.12 istnieje sprawdzenie w migration.pl, które weryfikuje wartości NULL przed transferem danych. Pamiętaj, że rozwiązanie nadal musi być wykonane ręcznie.

Błędy w kroku 5 podczas migracji do PostgreSQL

W takich przypadkach migration.pl wyświetla mało pomocną wiadomość „System nie mógł ukończyć transferu danych.”. Plik dziennika Apache i plik dziennika OTOBO pokazują bardziej wyraźną wiadomość: „Błąd: permission denied to set parameter "session_replication_role", SQL: 'set session_replication_role to replica;'". Aby przyznać 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 uruchomić http://localhost/otobo/migration.pl. Po migracji przywróć normalny stan, wykonując ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

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

TIP

Dyskusja na Forum OTOBO

Problemy z wdrażaniem scalonej konfiguracji systemu

Konfiguracja systemu jest migrowana po przeprowadzeniu migracji tabel bazy danych. W tym kontekście migracja oznacza scalenie ustawień domyślnych OTOBO 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 wartość domyślna to status closed successful. Jednak to ustawienie jest nieprawidłowe, jeśli status closed successful został usunięty lub zmieniony w systemie źródłowym. Ta niespójność jest wykrywana jako błąd w kroku migracji Migrowanie ustawień konfiguracyjnych. Scalona konfiguracja systemu jest faktycznie przechowywana w bazie danych, ale dodatkowe sprawdzanie poprawności odbywa się podczas wdrażania.

Problem należy ręcznie rozwiązać za pomocą poleceń konsoli OTOBO.

• Wyświetl niespójności poleceniem bin/otobo.Console.pl Admin::Config::ListInvalid.

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

• Wdróż zgromadzone zmiany z migration.pl, w tym wyłączone SecureMode, za pomocą bin/otobo.Console.pl Maint::Config::Rebuild.

Po tych ręcznych krokach 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 zasad haseł

Z OTOBO 10 wchodzi w życie nowa domyślna zasada haseł dla agentów i użytkowników klientów, jeśli używana jest lokalna autoryzacja. Reguły zasad haseł można zmienić w konfiguracji systemu (PreferencesGroups###Password i CustomerPersonalPreference###Password).

| Reguła zasad haseł | Domyślnie |

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

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Tak |

| PasswordNeedDigit | Tak |

| PasswordHistory | 10 |

| PasswordTTL | 30 dni |

| PasswordWarnBeforeExpiry | 5 dni |

| PasswordChangeAfterFirstLogin | Tak |

W Docker: ręczna migracja zadań cron

W nieopartej na Dockerze instalacji OTOBO istnieje co najmniej jedno zadanie cron, które sprawdza kondycję 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 znaleźć indywidualne rozwiązanie dla systemów OTRS z niestandardowymi zadaniami cron (np. kopia zapasowa bazy danych).

Migracja z Oracle do Oracle

Do migracji do Oracle należy zastosować strategię podobną do ETL. Dzieje się tak, ponieważ Oracle nie oferuje prostego sposobu tymczasowego wyłączenia sprawdzania kluczy obcych.

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

INFO

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

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

INFO

Ciągi połączeniowe pokazane w tej dokumentacji dotyczą 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. Wyczyszczenie otobo

Zatrzymaj serwer WWW dla otobo, aby zamknąć połączenie z bazą danych dla otobo.

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. Zaimportuj 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 ostatni wiersz jest istotny

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

Do kontroli użyj `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Uruchom ponownie serwer WWW dla OTOBO

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

INFO

Jeśli migrujesz do wersji OTOBO większej lub równej 10.1, należy uruchomić skrypt /opt/otobo/scripts/DBUpdate-to-10.1.pl, 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 bazy danych są kopiowane wiersz po wierszu z bazy danych OTRS do bazy danych OTOBO. Eksport danych z bazy danych OTRS i import do bazy danych OTOBO może zaoszczędzić czas i w niektórych przypadkach być bardziej stabilny.

INFO

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

INFO

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

Po pierwsze potrzebujemy zrzutu wymaganych tabel bazy danych OTRS. Następnie musimy wykonać kilka przekształceń:

• Konwersja zestawu znaków na utf8mb4

• Zmiana nazw niektórych tabel

• Skrócenie niektórych kolumn tabeli

Po przekształceniu możemy nadpisać tabele w schemacie OTOBO przekształconymi danymi z OTRS. Efektywnie potrzebujemy nie pojedynczego pliku zrzutu, ale kilku skryptów SQL.

Jeśli mysqldump jest zainstalowany i możliwe jest połączenie z bazą 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, aby instalacja OTOBO była dostępna 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 można utworzyć kopię zapasową bazy danych na innym serwerze, a następnie przesłać ją na hosta Docker. Prostym sposobem na zrobienie tego jest 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 uruchomić 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 Docker db, aby zaimportować pliki zrzutu bazy danych. Pamiętaj, że hasło dla użytkownika root bazy danych to teraz hasło ustawione 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

Dla szybkiej weryfikacji, czy import się powiódł, możesz uruchomić 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 działania 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.