Migratie van ((OTRS)) Community Edition naar OTOBO

Welkom en bedankt voor uw keuze voor OTOBO! OTRS, ((OTRS)) Community Edition en OTOBO zijn zeer uitgebreid en flexibel in gebruik. Daarom vereist elke migratie naar OTOBO een grondige voorbereiding en mogelijk ook wat nabewerking.

Neem de tijd voor de migratie en volg deze instructies stap voor stap.

INFO

Na de migratie zijn de gegevens die voorheen beschikbaar waren in ((OTRS)) Community Edition 6 beschikbaar in OTOBO 10. We wijzigen geen gegevens van de OTRS 6 installatie tijdens de migratie.

OTOBO Migratie Overzicht

Met de OTOBO migratie-interface is het mogelijk om de volgende migratiestrategieën te gebruiken:

1. De algemene migratiestrategie.

   Dit is de reguliere manier om een migratie uit te voeren. Veel verschillende combinaties worden ondersteund:

   • Serverwissel: Migreer en wissel tegelijkertijd naar een nieuwe applicatieserver.

   • Gescheiden applicatie- en webservers: U heeft de keuze om applicatie- en databaseservers op dezelfde host te draaien of op elk een aparte host. Deze keuze is onafhankelijk van de vorige opzet in OTRS / ((OTRS)) Community Edition.

   • Verschillende databases: Migreer van een willekeurige ondersteunde database naar een andere ondersteunde database.

   • Verschillende besturingssystemen: Wissel van een willekeurig ondersteund besturingssysteem naar een ander ondersteund besturingssysteem.

   • Docker: Migreer naar een Docker-gebaseerde installatie van OTOBO 10.

2. Een variant van de algemene strategie waarbij de databasemigratie wordt geoptimaliseerd.

Gebruik de ETL-achtige migratie als de brondatabase niet mag worden belast door verhoogde belasting of als de toegang tot de brondatabase een knelpunt is. In de algemene strategie worden de gegevens regel voor regel eerst uit de otrs-database gelezen en vervolgens in de OTOBO-database ingevoegd. In deze variant worden de volledige otrs-databasetabellen eerst geëxporteerd, vervolgens getransformeerd en daarna in de otobo-database geïmporteerd.

3. Migratie van een op Oracle gebaseerde ((OTRS)) Community Edition 6 installatie naar een op Oracle gebaseerde OTOBO installatie.

Dit is een speciaal geval dat niet wordt ondersteund door de algemene migratiestrategie. Dit betekent dat een variant van de geoptimaliseerde strategie moet worden gebruikt.

WARNING

Alle strategieën werken zowel voor Docker-gebaseerde als voor native installaties. Maar voor Docker-gebaseerde installaties moeten enkele bijzonderheden in acht worden genomen. Deze bijzonderheden worden behandeld in de optionele stappen.

INFO

Het is ook mogelijk om de ((OTRS)) Community Edition-database te klonen naar de OTOBO-databaseserver vóór de eigenlijke migratie. Dit kan de algemene migratiestrategie versnellen.

Migratievereisten

1. Basisvereiste voor een migratie is dat u reeds een ((OTRS)) Community Edition of OTRS 6.0.* draait en zowel configuratie als gegevens wilt overzetten naar OTOBO.

   WARNING

   Overweeg zorgvuldig of u de gegevens en configuratie echt nodig heeft. De ervaring leert dat in veel gevallen een nieuwe start de betere optie is. Dit komt omdat de eerder gebruikte installatie en configuratie vaak eerder suboptimaal was. Het kan ook zinvol zijn om alleen de ticketgegevens over te zetten en de basisconfiguratie om te zetten naar OTOBO best practices.

2. U heeft een draaiende OTOBO installatie nodig om van daaruit de migratie te starten!

3. Deze OTOBO installatie moet alle OPM-pakketten bevatten die in uw ((OTRS)) Community Edition geïnstalleerd zijn en die u ook in OTOBO wilt gebruiken.

4. Als u van plan bent naar een andere server te migreren, moet de OTOBO-webserver toegang hebben tot de locatie waar uw ((OTRS)) Community Edition of OTRS 6.0._ is geïnstalleerd. In de meeste gevallen is dit de map _/opt/otrs* op de server waarop ((OTRS)) Community Edition draait. Toegang tot lezen kan via SSH of via bestandssysteem-mounts.

5. De ((otrs)) Community Edition-database moet toegankelijk zijn vanaf de server waarop OTOBO draait. Readonly-toegang moet worden verleend voor externe hosts. Als toegang niet mogelijk is of als de snelheid van de migratie geoptimaliseerd moet worden, dan is een dump van de database voldoende.

INFO

Als SSH- en database-toegang tussen de servers niet mogelijk is, migreer dan ((OTRS)) Community Edition naar OTOBO op dezelfde server en verplaats dan pas de nieuwe installatie.

Stap voor stap handleiding

Stap 1: OTOBO Installatie

Begin alstublieft met de installatie van een nieuw OTOBO-systeem. Uw oude OTRS / ((OTRS)) Community Edition-installatie wordt naar dit nieuwe systeem gemigreerd.

WARNING

Onder Apache zijn er valkuilen bij het draaien van twee onafhankelijke mod_perl-applicaties op dezelfde webserver. Daarom wordt aanbevolen om ((OTRS)) Community Edition en OTOBO op gescheiden webservers te draaien. Als alternatief moet de OTRS-configuratie uit Apache worden verwijderd voordat OTOBO wordt geïnstalleerd. Gebruik de opdracht a2query -s en controleer de mappen /etc/apache2/sites-available en /etc/apache2/sites-enabled om te zien welke configuraties momenteel beschikbaar en geactiveerd zijn.

Na voltooiing van de installatie logt u alstublieft in als root@localhost. Navigeer naar het OTOBO Admin-gebied Admin -> Pakketten en installeer alle benodigde OTOBO OPM-pakketten.

De volgende OPM-pakketten en ((OTRS)) Community Edition "Feature Addons" hoeven NIET en mogen NIET worden geïnstalleerd, aangezien deze functies al in de OTOBO-standaard zijn opgenomen:

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

De volgende OTOBO-pakketten zijn geïntegreerd in OTOBO 10+. Dit betekent dat ze niet in het doelsysteem geïnstalleerd moeten worden als het doelsysteem OTOBO 10+ is. - ImportExport

Stap 2: SecureMode deactiveren

Nadat u OTOBO hebt geïnstalleerd, logt u alstublieft opnieuw in het OTOBO Admin-gebied in Admin -> Systeemconfiguratie en deactiveert u de configuratieoptie SecureMode.

INFO

Vergeet niet om de gewijzigde instelling daadwerkelijk te implementeren.

Stap 3: OTOBO Daemon stoppen

Dit is noodzakelijk als de OTOBO daemon daadwerkelijk draait. Het stoppen van de daemon verschilt tussen Docker-gebaseerde en niet-Docker-gebaseerde installaties.

In het niet-Docker-geval voert u de volgende commando's uit als gebruiker otobo:

# als u bent ingelogd als root

root> su - otobo

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

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

Als OTOBO in Docker draait, hoeft u alleen de service daemon te stoppen:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 zou met de code 0 moeten zijn beëindigd

INFO

Het wordt aanbevolen om op dit punt een back-up te maken van het gehele OTOBO-systeem. Als er iets misgaat tijdens de migratie, hoeft u niet het gehele installatieproces te herhalen, maar kunt u in plaats daarvan de back-up importeren voor een nieuwe migratie.

TIP

Wij raden u aan het hoofdstuk OTOBO Back-up backup-restore te lezen.

Optioneel /opt/otrs mounten

Vaak moet OTOBO op een nieuwe server draaien waar /opt/otrs aanvankelijk niet beschikbaar is. In deze gevallen kan de map /opt/otrs op de ((OTRS)) Community Edition-server in het bestandssysteem van de OTOBO-server worden gemount. Als een reguliere netwerk-mount niet mogelijk is, kan sshfs een optie zijn.

Optioneel: sshpass en rsync

Deze stap is alleen nodig als u ((OTRS)) Community Edition van een andere server wilt migreren en /opt/otrs niet vanaf de remote server op de OTOBO-server is gemount.

De tools sshpass en rsync zijn nodig zodat migration.pl bestanden via ssh kan kopiëren. Om sshpass te installeren, logt u alstublieft in als gebruiker root op de server en voert u een van de volgende commando's uit:

sshpass installeren op Debian / Ubuntu Linux

sudo apt install sshpass

sshpass installeren op RHEL/CentOS Linux

sudo yum install sshpass

sshpass installeren op Fedora Linux

sudo dnf install sshpass

sshpass installeren op OpenSUSE Linux

sudo zypper install sshpass

Hetzelfde moet gebeuren voor rsync als het nog niet beschikbaar is.

Stap 4: Voorbereiding

INFO

Zorg ervoor dat u ook een geldige back-up van uw OTRS / ((OTRS)) Community Edition-systeem heeft. Ja, we raken tijdens de migratie geen ((OTRS)) Community Edition-gegevens aan, maar soms is een verkeerde vermelding al voldoende om problemen te veroorzaken.

Nu zijn we klaar voor de migratie. Eerst moeten we ervoor zorgen dat er geen tickets meer worden verwerkt en dat er geen gebruikers inloggen op ((OTRS)) Community Edition:

Log alstublieft in op het ((OTRS)) Community Edition Admin-gebied Admin -> Systeemonderhoud en voeg een nieuwe systeemonderhoudsslot toe voor een paar uur. Verwijder daarna alle agent- en gebruikerssessies (Admin -> Sessies) en log uit.

Alle relevante services en de OTRS-daemon stoppen

Zorg er alstublieft voor dat er geen services of cron-jobs draaien.

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

De caches en operationele gegevens verwijderen

De gecachte gegevens en de operationele gegevens hoeven niet te worden gemigreerd. De e-mailwachtrij zou op dit moment al leeg moeten zijn.

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

Optionele stap voor Docker

Er zijn enkele bijzonderheden waarmee rekening moet worden gehouden als uw OTOBO-installatie onder Docker draait. Het meest relevante: processen die in een Docker-container draaien, kunnen over het algemeen geen mappen buiten de container benaderen. Er is echter een uitzondering: mappen die als volumes in de container zijn gemount, kunnen worden benaderd. Houd er ook rekening mee dat de MariaDB-database die in otobo_db_1 (otobo-db-1 in nieuwere docker compose versies) draait, niet direct toegankelijk is vanaf buiten het container-netwerk.

INFO

In de voorbeelden commando's gaan we ervan uit dat de gebruiker docker_admin wordt gebruikt voor interactie met Docker. De Docker-administrator kan de root-gebruiker van de Docker-host zijn of een toegewijde gebruiker met de vereiste permissies.

Kopieer /opt/otrs naar het volume otobo_opt_otobo

::: note Container Namen In oude docker compose versies zijn de container namen otobo_web_1, otobo_db_1 en otobo_daemon_1. In nieuwere versies zijn de container namen otobo-web-1, otobo-db-1 en otobo-daemon-1.

:::

In dit gedeelte gaan we ervan uit dat de OTRS-home-map /opt/otrs beschikbaar is op de Docker-host.

Er zijn minstens twee praktische opties:

a. Kopieer /opt/otrs naar het bestaande volume otobo_opt_otobo

b. Mount /opt/otrs als een extra volume

Laten we ons hier concentreren op optie a..

Eerst moeten we achterhalen waar het volume otobo_opt_otobo beschikbaar is op de Docker-host.

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

Voor veilig kopiëren gebruiken we rsync. Afhankelijk van uw Docker-configuratie moet het commando rsync mogelijk met sudo worden uitgevoerd.

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  # alleen ter controle
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  # alleen ter controle

Deze gekopieerde map zal binnen de container beschikbaar zijn als /opt/otobo/var/tmp/copied_otrs.

Stap 5: Gegevens migreren

:::note Docker Compose Command In oude Docker Compose versies werd het commando docker-compose gebruikt. In nieuwere versies wordt docker compose gebruikt. :::

Gebruik alstublieft de webmigratietool op http://localhost/otobo/migration.pl. Houd er rekening mee dat u mogelijk "localhost" moet vervangen door uw OTOBO-hostnaam en mogelijk uw niet-standaard poort moet toevoegen. De applicatie leidt u vervolgens door het migratieproces.

WARNING

Soms wordt een waarschuwing weergegeven dat het deactiveren van SecureMode niet is gedetecteerd. Start in dat geval de webserver opnieuw op. Dit dwingt de webserver om de huidige configuratie in te lezen.

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

INFO

Als OTOBO in een Docker-container draait, behoud dan de standaardwaarden localhost voor de OTRS-server en /opt/otobo/var/tmp/copied_otrs voor de OTRS-home-map. Dit is het pad van de gegevens die in de optionele stap zijn gekopieerd.

INFO

De standaardwaarden voor OTRS-databasegebruiker en -wachtwoord worden overgenomen uit Kernel/Config.pm in de OTRS-home-map. Wijzig de voorgestelde instellingen als u een toegewijde databasegebruiker voor de migratie gebruikt. Wijzig ook de instellingen als u werkt met een database die in de otobo_db_1 Docker-container is gekopieerd.

INFO

In het Docker-geval is een database die op de Docker-host draait niet toegankelijk via 127.0.0.1 binnen de Docker-container. Dit betekent dat de instelling 127.0.0.1 niet geldig zal zijn voor het invoerveld OTRS-Server. Voer in dat geval een van de alternatieve IP-adressen in die door het commando hostname --all-ip-addresses voor OTRS-Server worden gerapporteerd.

INFO

Bij migratie naar een nieuwe applicatieserver of naar een Docker-gebaseerde installatie kan de database vaak niet worden benaderd vanuit de doelinstallatie. Dit komt meestal doordat de otobo databasegebruiker alleen kan verbinden vanaf de host waarop de database draait. Om toch toegang mogelijk te maken, wordt aanbevolen om een toegewijde databasegebruiker voor de migratie aan te maken, bijvoorbeeld CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; en GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Deze gebruiker kan na de migratie weer worden verwijderd: DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

Gebruikersspecifieke instellingen in Kernel/Config.pm worden van de oude OTRS-installatie overgezet naar de nieuwe OTOBO-installatie. Als u gebruikersspecifieke instellingen heeft, moet u een kijkje nemen in het gemigreerde bestand /opt/otobo/Kernel/Config.pm. Mogelijk wilt u aangepaste paden of LDAP-instellingen aanpassen. In het beste geval stelt u vast dat sommige aangepaste instellingen niet meer nodig zijn.

Als de migratie is voltooid, neemt u de tijd om het gehele systeem te testen. Zodra u heeft besloten dat de migratie succesvol was en u OTOBO vanaf nu wilt gebruiken, start u de OTOBO-daemon:

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

In het Docker-geval:

cd ~/otobo-docker
docker-compose start daemon

Stap 6: Opschonen

1. Deïnstalleer sshpass als u het niet meer nodig heeft.

2. Verwijder de databases en databasegebruikers die speciaal voor de migratie zijn aangemaakt, indien aanwezig.

3. Veel plezier met OTOBO!

Bekende Migratieproblemen

Inloggen na migratie niet mogelijk

Tijdens onze migratietests had de browser die voor de migratie werd gebruikt soms problemen. Na het herstarten van de browser werd dit probleem meestal opgelost. Bij Safari was het soms nodig om de oude OTRS-sessie handmatig te verwijderen.

Laatste pagina van de migratie heeft een vreemde layout

Dit kan gebeuren als de ScriptAlias-instelling een niet-standaardwaarde heeft. De migratie vervangt simpelweg otrs door otobo. Dit kan ertoe leiden dat de CSS- en JavaScript-bestanden in OTOBO niet meer kunnen worden opgehaald worden. Als dit het geval is, controleer dan de instellingen in Kernel/Config.pm en wijzig deze terug naar redelijke waarden.

Migratie stopt vanwege MySQL-fouten

Op systemen die in het verleden problemen hadden met een upgrade, kan het migratieproces stoppen vanwege MySQL-fouten in de tabellen ticket en ticket_history. Meestal zijn dit NULL-waarden in de brontabel die in de doeltabel niet meer zijn toegestaan. Deze conflicten moeten handmatig worden opgelost voordat u de migratie kunt voortzetten.

Vanaf OTOBO 10.0.12 is er een controle in migration.pl die controleert op NULL-waarden vóór de dataoverdracht. Houd er rekening mee dat de oplossing nog steeds handmatig moet worden uitgevoerd.

Fout in stap 5 bij migratie naar PostgreSQL

In deze gevallen wordt het niet erg behulpzame bericht "Het systeem kon de dataoverdracht niet voltooien." weergegeven door migration.pl. Het Apache-logbestand en het OTOBO-logbestand tonen een meerzeggende bericht: " Foutmelding: ERROR: permission denied to set parameter "session_replication_role", SQL: 'set session_replication_role to replica;'" Om de databasegebruiker otobo de benodigde superuser-privileges te verlenen, voert u het volgende commando uit als PostgreSQL-admin: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Probeer vervolgens opnieuw http://localhost/otobo/migration.pl uit te voeren. Na de migratie, keer terug naar de normale staat door ALTER USER [otobo](../index.md) WITH NOSUPERUSER uit te voeren.

Het is nog niet duidelijk of de uitgebreide privileges in elke setup moeten worden verleend.

TIP

De discussie in OTOBO Forum

Problemen met de implementatie van de samengevoegde systeemconfiguratie

De systeemconfiguratie wordt gemigreerd nadat de databasetabellen zijn gemigreerd. In deze context betekent migratie dat de standaardinstellingen van OTOBO worden samengevoegd met de systeemconfiguratie van het bronsysteem OTRS. In deze stap kunnen inconsistenties optreden. Een praktijkvoorbeeld is de instelling Ticket::Frontend::AgentTicketQuickClose###State. Deze instelling is nieuw in OTOBO 10 en de standaardwaarde is de status closed successful. Maar deze instelling is ongeldig als de status closed successful in het bronsysteem is verwijderd of hernoemd. Deze inconsistentie wordt gedetecteerd als een fout in de migratiestap Migrate configuration settings. De samengevoegde systeemconfiguratie wordt daadwerkelijk opgeslagen in de database, maar extra validatiecontroles worden uitgevoerd tijdens de implementatie.

Het probleem moet handmatig worden opgelost met behulp van OTOBO-consolecommando's.

• Geeft de inconsistenties weer met het commando bin/otobo.Console.pl Admin::Config::ListInvalid.

• Los de ongeldige waarden interactief op met bin/otobo.Console.pl Admin::Config::FixInvalid.

• Implementeer de verzamelde wijzigingen van migration.pl, inclusief de gedeactiveerde SecureMode, met bin/otobo.Console.pl Maint::Config::Rebuild.

Na deze handmatige stappen zou u migration.pl opnieuw moeten kunnen uitvoeren. De migratie gaat verder met de stap waar de fout optrad.

Afsluitende Handmatige Taken

Wachtwoordbeleidsregels

Met OTOBO 10 treedt een nieuw standaard wachtwoordbeleid in werking voor agenten- en klantgebruikers wanneer lokale authenticatie wordt gebruikt. De wachtwoordbeleidsregels kunnen worden gewijzigd in de systeemconfiguratie (PreferencesGroups###Password en CustomerPersonalPreference###Password).

| Wachtwoordbeleidsregel | Standaard |

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

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Ja |

| PasswordNeedDigit | Ja |

| PasswordHistory | 10 |

| PasswordTTL | 30 dagen |

| PasswordWarnBeforeExpiry | 5 dagen |

| PasswordChangeAfterFirstLogin | Ja |

Onder Docker: Handmatig migreren van Cron-jobs

In een niet-Docker-gebaseerde installatie van OTOBO is er minstens één cron-job die de gezondheid van de daemon controleert. Onder Docker bestaat deze cron-job niet meer. Bovendien draait er geen Cron-daemon in een van de Docker-containers. Dit betekent dat u een individuele oplossing moet zoeken voor OTRS-systemen met aangepaste cron-jobs (bijvoorbeeld back-up van de database).

Migratie van Oracle naar Oracle

Voor migratie naar Oracle moet de ETL-achtige strategie worden toegepast. Dit komt omdat Oracle geen eenvoudige manier biedt om de controle van vreemde sleutels tijdelijk uit te schakelen.

Op de OTOBO-host moet een Oracle-client en de Perl-module DBD::Oracle zijn geïnstalleerd.

INFO

Bij gebruik van de Oracle Instant Client is ook de optionele SDK vereist voor de installatie van DBD:: Oracle.

Er zijn veel manieren om een schema te klonen. In de voorbeeldcommando's gebruiken we expdp en impdp, die Data Pump onder de motorkap gebruiken.

INFO

De verbindingsstrings die in deze documentatie worden getoond, verwijzen naar het geval waarin zowel de bron- als de doeldatabase in een Docker-container draaien. Zie ook https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Opschonen van otobo

Stop de webserver voor otobo, zodat de DB-verbinding voor otobo wordt gesloten.

DROP USER otobo CASCADE

2. Exporteren van het gehele OTRS-schema.

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. Importeren van het OTRS-schema en het schema hernoemen naar '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. Aanpassen van het gekloonde schema otobo

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # het is oké als het commando alleen de otobo database kent, alleen de laatste regel is relevant

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

Voor controle met `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Start de webserver voor OTOBO opnieuw.

6. Ga verder met stap 5, dat wil zeggen, voer migration.pl uit.

INFO

Bij migratie naar een OTOBO-versie groter dan of gelijk aan 10.1 moet het script /opt/otobo/scripts/DBUpdate-to-10.1.pl worden uitgevoerd om de nieuw toegevoegde tabellen stats_report en data_storage in versie 10.1 te maken.

Optioneel: Vereenvoudigde databasemigratie (alleen voor experts en speciale scenario's)

In de algemene migratiestrategie worden alle gegevens in de databasetabellen regel voor regel gekopieerd van de OTRS-database naar de OTOBO-database. Het exporteren van de gegevens uit de OTRS-database en het importeren in de OTOBO-database kan tijd besparen en is in sommige gevallen stabieler.

INFO

Deze variant werkt zowel voor Docker-gebaseerde als voor native installaties.

INFO

Deze instructies gaan ervan uit dat ((OTRS)) Community Edition MySQL als backend gebruikt.

Allereerst hebben we een dump nodig van de benodigde OTRS-databasetabellen. Vervolgens moeten we enkele transformaties uitvoeren:

• Conversie van de tekenset naar utf8mb4

• Hernoemen van enkele tabellen

• Afkorten van enkele tabelkolommen

Na de transformatie kunnen we de tabellen in het OTOBO-schema overschrijven met de getransformeerde gegevens uit OTRS. Effectief hebben we niet één dump-bestand nodig, maar meerdere SQL-scripts.

Als mysqldump is geïnstalleerd en een verbinding met de OTRS-database mogelijk is, kunt u de database dump direct op de Docker-host maken. Dit geval wordt ondersteund door het script bin/backup.pl.

WARNING

Dit vereist dat een OTOBO-installatie beschikbaar is op de Docker-host.

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

Als alternatief kan de database op een andere server worden geback-upt en vervolgens naar de Docker-host worden overgebracht. Een eenvoudige manier om dit te doen is door /opt/otobo naar de server te kopiëren waar OTRS draait en hetzelfde commando als hierboven uit te voeren.

Het script bin/backup.pl genereert vier SQL-scripts in een dump-map, bijvoorbeeld in 2021-04-13_12-13-04. Om de SQL-scripts uit te voeren, moeten we het commando mysql uitvoeren.

Native Installatie:

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

Docker-gebaseerde Installatie:

Voer het commando mysql uit binnen de Docker-container db om de database dump-bestanden te importeren. Houd er rekening mee dat het wachtwoord voor de database-root nu het wachtwoord is dat is ingesteld in het bestand .env op de Docker-host.

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

Voor een snelle controle of de import is gelukt, kunt u de volgende commando's uitvoeren.

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'

of bij uitvoering onder Docker

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'

De database is nu gemigreerd. Dit betekent dat we in de volgende stap de databasemigratie kunnen overslaan. Let op het bijbehorende selectievakje.