Migratie van ((OTRS)) Community Edition naar OTOBO

Welkom en dank dat u heeft gekozen voor OTOBO!
OTRS, ((OTRS)) Community Edition en OTOBO zijn in hun gebruik zeer uitgebreid en flexibel. Daarom vereist elke migratie naar OTOBO een grondige voorbereiding en mogelijk ook enige nabewerking.

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

INFO

Na de migratie zijn de eerder beschikbare gegevens in ((OTRS)) Community Edition 6 beschikbaar in OTOBO 10.
We wijzigen geen gegevens van de OTRS 6-installatie tijdens de migratie.

Overzicht van OTOBO-migratie

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: Migreren en tegelijkertijd overschakelen naar een nieuwe toepassingsserver.

   • Afzonderlijke toepassings- en webservers: U kunt kiezen of u de toepassings- en databaseserver op dezelfde host of op elk een aparte host wilt uitvoeren. Deze keuze is onafhankelijk van de vorige instelling in OTRS / ((OTRS)) Community Edition.

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

   • Verschillende besturingssystemen: Wisselen van elk ondersteund besturingssysteem naar een ander ondersteund besturingssysteem.

   • Docker: Migreren naar een op Docker gebaseerde installatie van OTOBO 10.

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

Gebruik de ETL-achtige migratie als de brondatabase niet mag worden belast met extra belasting of als toegang tot de brondatabase een knelpunt is. Bij de algemene strategie worden de gegevens rij per rij eerst uit de otrs-database gelezen en vervolgens in de OTOBO-database ingevoegd. Bij deze variant worden de volledige otrs-databasetabellen eerst geëxporteerd, daarna getransformeerd en vervolgens 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. Voor Docker-gebaseerde installaties moeten echter 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 vóór de eigenlijke migratie naar de OTOBO-databaseserver te klonen. Dit kan de algemene migratiestrategie versnellen.

Migratievereisten

1. Een basisvereiste voor een migratie is dat u al een ((OTRS)) Community Edition of OTRS 6.0.* draait en zowel configuratie als gegevens naar OTOBO wilt overbrengen.

   WARNING

   Overweeg zorgvuldig of u de gegevens en configuratie echt nodig hebt. De ervaring leert dat in veel gevallen een nieuwe start de betere optie is. Dit komt doordat de eerder gebruikte installatie en configuratie vaak suboptimaal waren. Het kan ook zinvol zijn om alleen de ticketgegevens over te nemen en de basisconfiguratie aan te passen volgens OTOBO-best practices.

2. U hebt een actieve OTOBO-installatie nodig om vanaf daar de migratie te starten!

3. Deze OTOBO-installatie moet alle OPM-pakketten bevatten die in uw ((OTRS)) Community Edition zijn geïnstalleerd 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 waar ((OTRS)) Community Edition draait. De leestoegang kan via SSH of via filesystem-mounts worden verstrekt.

5. De ((otrs)) Community Edition-database moet toegankelijk zijn vanaf de server waarop OTOBO draait. Alleen-lezen toegang moet worden toegestaan voor externe hosts. Als toegang niet mogelijk is of als de snelheid van de migratie moet worden geoptimaliseerd, 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 daarna pas de nieuwe installatie.

Stap-voor-stap instructie

Stap 1: OTOBO installatie

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

WARNING

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

Nadat de installatie is voltooid, meldt u zich aan als root@localhost. Ga naar het OTOBO-beheerdersgedeelte Beheer -> Pakketten en installeer alle vereiste OTOBO OPM-pakketten.

De volgende OPM-pakketten en ((OTRS)) Community Edition "Feature Addons" moeten NIET en mogen NIET worden geïnstalleerd, omdat deze functionaliteiten al standaard in OTOBO 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 op het doelsysteem moeten worden geïnstalleerd als het doelsysteem OTOBO 10+ is:

• ImportExport

Stap 2: SecureMode uitschakelen

Nadat u OTOBO hebt geïnstalleerd, meldt u zich opnieuw aan in het OTOBO-beheerdersgedeelte Beheer -> Systeemconfiguratie en schakel de configuratieoptie SecureMode uit.

INFO

Vergeet niet de gewijzigde instelling daadwerkelijk toe te passen.

Stap 3: OTOBO Daemon stoppen

Dit is nodig als de OTOBO Daemon daadwerkelijk actief is. Het stoppen van de daemon verschilt tussen Docker-gebaseerde en niet-Docker-gebaseerde installaties.

In het geval zonder Docker voert u de volgende opdrachten uit als gebruiker otobo:

# als u bent aangemeld 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 moeten stoppen met code 0

INFO

Op dit moment wordt aanbevolen om een back-up van het volledige OTOBO-systeem te maken. Als er tijdens de migratie iets misgaat, hoeft u het installatieproces niet opnieuw te doorlopen, maar kunt u in plaats daarvan de back-up gebruiken 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 dergelijke gevallen kan de map /opt/otrs op de ((OTRS)) Community Edition-server worden gekoppeld aan het bestandssysteem van de OTOBO-server. 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 vanaf een andere server wilt migreren en /opt/otrs niet is gekoppeld vanaf de externe server op de OTOBO-server.

De hulpmiddelen sshpass en rsync zijn nodig zodat migration.pl bestanden via ssh kan kopiëren. Om sshpass te installeren, meldt u zich aan als gebruiker root op de server en voert u een van de volgende opdrachten uit:

sshpass installeren onder Debian / Ubuntu Linux

sudo apt install sshpass

sshpass installeren onder RHEL/CentOS Linux

sudo yum install sshpass

sshpass installeren onder Fedora Linux

sudo dnf install sshpass

sshpass installeren onder OpenSUSE Linux

sudo zypper install sshpass

Hetzelfde moet worden gedaan voor rsync als deze nog niet beschikbaar is.

Stap 4: Voorbereiding

INFO

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

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

Log in op het ((OTRS)) Community Edition-beheerdersgedeelte Beheer -> Systeemonderhoud en voeg een nieuwe systeemonderhoudsslot toe voor enkele uren. Verwijder daarna alle agent- en gebruikerssessies (Beheer -> Sessies) en log uit.

Stop alle relevante diensten en de OTRS-Daemon

Zorg ervoor dat er geen diensten of Cron-jobs actief zijn.

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

Verwijder tijdelijke opslag en operationele gegevens

De gecachte gegevens en 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 te overwegen als uw OTOBO-installatie onder Docker draait. Het belangrijkste: processen die in een Docker-container draaien, kunnen in het algemeen geen mappen buiten de container bereiken. Er is echter een uitzondering: mappen die als volumes in de container zijn gekoppeld, 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 van buiten het container-netwerk.

INFO

In de voorbeeldopdrachten gaan we ervan uit dat de gebruiker docker_admin wordt gebruikt voor interactie met Docker. De Docker-beheerder kan ofwel de root-gebruiker van de Docker-host zijn of een speciale gebruiker met de vereiste rechten.

Kopieer /opt/otrs naar het volume otobo_opt_otobo

::: note Containernamen In oudere docker-compose-versies zijn de containernamen otobo_web_1, otobo_db_1 en otobo_daemon_1.
In nieuwere versies zijn de containernamen otobo-web-1, otobo-db-1 en otobo-daemon-1.

:::

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

Er zijn minstens twee haalbare mogelijkheden:

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

b. Koppel /opt/otrs als extra volume

We concentreren ons hier op optie a.

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

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 rsync-commando 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 voor 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 voor controle

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

Stap 5: Gegevens migreren

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

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

WARNING

Soms wordt een waarschuwing weergegeven dat het uitschakelen van SecureMode niet is herkend. Herstart in dat geval de webserver. Dit dwingt de webserver om de huidige configuratie opnieuw 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, behoudt u de standaardinstellingen localhost voor de OTRS-server en /opt/otobo/var/tmp/copied_otrs voor de OTRS-homemap. 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-homemap. Wijzig de voorgestelde instellingen als u een speciale databasegebruiker voor de migratie gebruikt. Wijzig ook de instellingen als u werkt met een database die is gekopieerd naar de otobo_db_1 Docker-container.

INFO

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

INFO

Bij migratie naar een nieuwe toepassingsserver of naar een op Docker gebaseerde installatie is de database vaak niet toegankelijk vanaf de doelinstallatie. Dit komt meestal doordat de otobo-databasegebruiker alleen kan verbinden vanaf de host waarop de database draait. Om toegang toch mogelijk te maken, wordt aanbevolen om een speciale 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 naar de nieuwe OTOBO-installatie overgenomen. Als u gebruikersspecifieke instellingen heeft, bekijk dan de gemigreerde bestand /opt/otobo/Kernel/Config.pm. Mogelijk wilt u aangepaste paden of LDAP-instellingen aanpassen. In het beste geval ontdekt u dat sommige aangepaste instellingen niet langer nodig zijn.

Wanneer de migratie is voltooid, neem dan de tijd om het hele systeem te testen. Zodra u besluit dat de migratie succesvol is en u voortaan OTOBO 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: Opruimen

1. Verwijder sshpass als u het niet langer nodig hebt.

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

3. Veel plezier met OTOBO!

Bekende migratieproblemen

Aanmelden na de migratie niet mogelijk

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

De laatste pagina van de migratie heeft een vreemd ontwerp

Dit kan gebeuren als de instelling ScriptAlias een niet-standaardwaarde heeft. De migratie vervangt eenvoudigweg otrs door otobo. Dit kan ertoe leiden dat de CSS- en JavaScript-bestanden in OTOBO niet meer kunnen worden opgehaald. In dat geval controleert u de instellingen in Kernel/Config.pm en wijzigt u deze terug naar redelijke waarden.

Migratie stopt vanwege MySQL-fouten

Op systemen die in het verleden problemen hadden bij een upgrade, kan het migratieproces stoppen vanwege MySQL-fouten in de tabellen ticket en ticket_history. Meestal gaat het om NULL-waarden in de brontabel die in de doeltabel niet langer 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 op NULL-waarden controleert vóór de gegevensoverdracht. 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 de weinig nuttige melding "Het systeem kon de gegevensoverdracht niet voltooien." weergegeven door migration.pl. Het Apache-logbestand en het OTOBO-logbestand tonen een informatievere melding: "Foutmelding: ERROR: toestemming geweigerd om parameter 'session_replication_role' in te stellen, SQL: 'set session_replication_role to replica;'". Voer als PostgreSQL-beheerder het volgende commando uit om de databasegebruiker otobo de benodigde superuser-rechten te geven: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Probeer daarna opnieuw om http://localhost/otobo/migration.pl uit te voeren. Na de migratie keert u terug naar de normale toestand door ALTER USER [otobo](../index.md) WITH NOSUPERUSER uit te voeren.

Het is nog niet duidelijk of de uitgebreide rechten in elke installatie moeten worden verleend.

TIP

De discussie in OTOBO Forum

Problemen met het implementeren van de samengevoegde systeemconfiguratie

De systeemconfiguratie wordt gemigreerd nadat de databasetabellen zijn gemigreerd. In dit verband betekent migratie dat de standaardinstellingen van OTOBO worden samengevoegd met de systeemconfiguratie van het bron-OTRS-systeem. 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 herkend als een fout in de migratiestap Migrate configuration settings. De samengevoegde systeemconfiguratie wordt daadwerkelijk in de database opgeslagen, maar extra validaties worden uitgevoerd tijdens de implementatie.

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

• Gebruik het commando bin/otobo.Console.pl Admin::Config::ListInvalid om de inconsistenties weer te geven.

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

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

Na deze handmatige stappen zou u in staat moeten zijn om migration.pl opnieuw uit te voeren. De migratie wordt voortgezet vanaf het punt waar de fout optrad.

Afsluitende handmatige taken

Wachtwoordbeleidregels

Met OTOBO 10 treedt een nieuw standaardwachtwoordbeleid in werking voor agent- en klantgebruikers als lokale authenticatie wordt gebruikt. De wachtwoordbeleidregels kunnen worden gewijzigd in de systeemconfiguratie (PreferencesGroups###Password en CustomerPersonalPreference###Password).

| Wachtwoordbeleidregel | 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 status 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 eigen oplossing moet zoeken voor OTRS-systemen met gebruikersspecifieke Cron-jobs (bijvoorbeeld back-up van de database).

Migratie van Oracle naar Oracle

Voor de migratie naar Oracle moet de ETL-achtige strategie worden toegepast. Dit komt doordat Oracle geen eenvoudige manier biedt om de controle van refererende 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 voorbeeldopdrachten gebruiken we expdp en impdp, die gebruikmaken van Data Pump.

INFO

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

1. Opruimen van otobo

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

DROP USER otobo CASCADE

2. Exporteer het volledige 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. Importeer het OTRS-schema en hernoem het schema 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. Pas het gekloonde schema otobo aan

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # het is in orde dat het commando alleen van de otobo-database weet, 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
Controleer 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

Als u migreert 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 in versie 10.1 toegevoegde tabellen stats_report en data_storage aan te maken.

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

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

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 vereiste OTRS-databasetabellen. Vervolgens moeten we enkele transformaties uitvoeren:

• Conversie van het tekenset naar utf8mb4

• Hernoemen van enkele tabellen

• Inkorten 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 dumpbestand nodig, maar meerdere SQL-scripts.

Als mysqldump is geïnstalleerd en een verbinding met de OTRS-database mogelijk is, kunt u de databasedump rechtstreeks 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 overgedragen. Een eenvoudige manier om dit te doen, is /opt/otobo naar de server kopiëren waar OTRS draait en hetzelfde commando als hierboven uitvoeren.

Het script bin/backup.pl genereert vier SQL-scripts in een dumpmap, 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 mysql-commando uit binnen de Docker-container db om de databasedumpbestanden 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 opdrachten 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.