Migration de ((OTRS)) Community Edition vers OTOBO

Bienvenue et merci d’avoir choisi OTOBO ! OTRS, ((OTRS)) Community Edition et OTOBO sont très complets et flexibles dans leur utilisation. Par conséquent, toute migration vers OTOBO nécessite une préparation minutieuse et éventuellement un peu de travail supplémentaire.

Veuillez prendre le temps nécessaire pour la migration et suivre ces instructions étape par étape.

::: info

Après la migration, les données précédemment disponibles dans ((OTRS)) Community Edition 6 sont disponibles dans OTOBO 10. Nous ne modifions aucune donnée de l’installation OTRS 6 pendant la migration.

:::

Aperçu de la migration OTOBO

Avec l’interface de migration OTOBO, il est possible d’utiliser les stratégies de migration suivantes :

La stratégie de migration générale.

Il s’agit de la méthode habituelle pour effectuer une migration. De nombreuses combinaisons différentes sont prises en charge :
- Changement de serveur : Migrer tout en changeant de serveur d’application.
- Serveurs d’application et Web séparés : Vous avez le choix de faire fonctionner les serveurs d’application et de base de données sur le même hôte ou sur un hôte dédié chacun. Ce choix est indépendant de la configuration précédente dans OTRS / ((OTRS)) Community Edition.
- Différentes bases de données : Migrer d’une base de données prise en charge vers une autre base de données prise en charge.
- Différents systèmes d’exploitation : Passer de tout système d’exploitation pris en charge à un autre système d’exploitation pris en charge.
- Docker : Migrer vers une installation d’OTOBO 10 basée sur Docker.
Une variante de la stratégie générale où la migration de la base de données est optimisée.

Utilisez la migration de type ETL si la base de données source ne doit pas être surchargée par une charge accrue ou si l’accès à la base de données source est un goulot d’étranglement. Dans la stratégie générale, les données sont lues ligne par ligne à partir de la base de données otrs, puis insérées dans la base de données OTOBO. Dans cette variante, les tables complètes de la base de données otrs sont d’abord exportées, puis transformées, puis importées dans la base de données otobo.

Migration d’une installation ((OTRS)) Community Edition 6 basée sur Oracle vers une installation OTOBO basée sur Oracle.

Il s’agit d’un cas particulier qui n’est pas pris en charge par la stratégie de migration générale. Cela signifie qu’une variante de la stratégie optimisée doit être utilisée.

::: warning

Toutes les stratégies fonctionnent aussi bien pour les installations basées sur Docker que pour les installations natives. Cependant, pour les installations basées sur Docker, certaines particularités doivent être prises en compte. Ces particularités sont traitées dans les étapes optionnelles.

:::

::: info

Il est également possible de cloner la base de données ((OTRS)) Community Edition sur le serveur de base de données OTOBO avant la migration proprement dite. Cela peut accélérer la stratégie de migration générale.

:::

Exigences de migration

La condition de base pour une migration est que vous ayez déjà une ((OTRS)) Community Edition ou OTRS 6.0.* en cours d’exécution et que vous souhaitiez transférer à la fois la configuration et les données vers OTOBO.

::: warning

Veuillez réfléchir attentivement si vous avez vraiment besoin des données et de la configuration. L’expérience montre que, dans de nombreux cas, un nouveau départ est la meilleure option. Cela est dû au fait que l’installation et la configuration précédemment utilisées étaient souvent sous-optimales. Il pourrait également être judicieux de ne transférer que les données de tickets et de basculer la configuration de base vers les Best Practices d’OTOBO.

:::
Vous avez besoin d’une installation OTOBO en cours d’exécution pour démarrer la migration à partir de là !
Cette installation OTOBO doit contenir tous les paquets OPM qui sont installés dans votre ((OTRS)) Community Edition et que vous souhaitez également utiliser dans OTOBO.
Si vous prévoyez de migrer vers un autre serveur, le serveur Web OTOBO doit pouvoir accéder à l’emplacement où votre ((OTRS)) Community Edition ou OTRS 6.0.* est installé. Dans la plupart des cas, il s’agit du répertoire _/opt/otrs* sur le serveur où ((OTRS)) Community Edition est en cours d’exécution. L’accès en lecture peut se faire via SSH ou via des montages de système de fichiers.
La base de données ((otrs)) Community Edition doit être accessible depuis le serveur sur lequel OTOBO est en cours d’exécution. Un accès en lecture seule doit être accordé aux hôtes externes. Si l’accès n’est pas possible ou si la vitesse de la migration doit être optimisée, un dump de la base de données est suffisant.

::: info

Si l’accès SSH et l’accès à la base de données entre les serveurs ne sont pas possibles, veuillez migrer ((OTRS)) Community Edition vers OTOBO sur le même serveur, puis déplacer la nouvelle installation.

:::

Guide étape par étape

Étape 1 : Installation d’OTOBO

Veuillez commencer par l’installation d’un nouveau système OTOBO. Votre ancienne installation OTRS / ((OTRS)) Community Edition sera migrée vers ce nouveau système.

::: warning

Sous Apache, il existe des pièges lors de l’exécution de deux applications mod_perl indépendantes sur le même serveur Web. Par conséquent, il est recommandé d’exécuter ((OTRS)) Community Edition et OTOBO sur des serveurs Web séparés. Alternativement, la configuration OTRS doit être supprimée d’Apache avant l’installation d’OTOBO. Utilisez la commande a2query -s et vérifiez les répertoires /etc/apache2/sites-available et /etc/apache2/sites-enabled pour voir quelles configurations sont actuellement disponibles et activées.

:::

Une fois l’installation terminée, veuillez vous connecter en tant que root@localhost. Naviguez vers la zone d’administration OTOBO Admin -> Paquets et installez tous les paquets OPM OTOBO requis.

Les paquets OPM et “Feature Addons” de ((OTRS)) Community Edition suivants NE DOIVENT PAS et NE DEVRAIENT PAS être installés, car ces fonctionnalités sont déjà incluses dans le standard 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

Les paquets OTOBO suivants ont été intégrés dans OTOBO 10+. Cela signifie qu’ils ne doivent pas être installés sur le système cible si le système cible est OTOBO 10+. - ImportExport

Étape 2 : Désactiver le SecureMode

Après avoir installé OTOBO, veuillez vous reconnecter à la zone d’administration OTOBO Admin -> Configuration système et désactiver l’option de configuration SecureMode.

::: info

N’oubliez pas d’implémenter réellement le paramètre modifié.

:::

Étape 3 : Arrêter le démon OTOBO

Ceci est nécessaire si le démon OTOBO est effectivement en cours d’exécution. L’arrêt du démon diffère entre les installations basées sur Docker et celles qui ne le sont pas.

Dans le cas non-Docker, exécutez les commandes suivantes en tant qu’utilisateur otobo :

# si vous êtes connecté en tant que root

root> su - otobo

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

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

Si OTOBO s’exécute dans Docker, il vous suffit d’arrêter le service daemon :

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 devrait s'être arrêté avec le code 0

:::: info

Il est recommandé d’effectuer une sauvegarde de l’ensemble du système OTOBO à ce stade. Si quelque chose ne va pas pendant la migration, vous n’aurez pas à répéter tout le processus d’installation, mais pourrez plutôt importer la sauvegarde pour une nouvelle migration.

::: tip

Nous vous recommandons de lire le chapitre Sauvegarde OTOBO backup-restore.

:::

::: details Optionnel : monter /opt/otrs

Souvent, OTOBO doit fonctionner sur un nouveau serveur où /opt/otrs n’est pas disponible initialement. Dans ces cas, le répertoire /opt/otrs sur le serveur ((OTRS)) Community Edition peut être monté dans le système de fichiers du serveur OTOBO. Si un montage réseau régulier n’est pas possible, sshfs pourrait être une option.

Optionnel : sshpass et rsync

Cette étape n’est nécessaire que si vous souhaitez migrer ((OTRS)) Community Edition depuis un autre serveur et que /opt/otrs n’a pas été monté sur le serveur OTOBO depuis le serveur distant.

Les outils sshpass et rsync sont nécessaires pour que migration.pl puisse copier des fichiers via ssh. Pour installer sshpass, veuillez vous connecter en tant qu’utilisateur root sur le serveur et exécuter l’une des commandes suivantes :

::: details Installer sshpass sous Debian / Ubuntu Linux

sudo apt install sshpass

:::

::: details Installer sshpass sous RHEL/CentOS Linux

sudo yum install sshpass

:::

::: details Installer sshpass sous Fedora Linux

sudo dnf install sshpass

:::

::: details Installer sshpass sous OpenSUSE Linux

sudo zypper install sshpass

:::

La même chose doit être faite pour rsync s’il n’est pas encore disponible.

Étape 4 : Préparation

::: info

Assurez-vous d’avoir également une sauvegarde valide de votre système OTRS / ((OTRS)) Community Edition. Oui, nous ne touchons pas aux données ((OTRS)) Community Edition pendant la migration, mais parfois une mauvaise entrée suffit à causer des problèmes. :::

Nous sommes maintenant prêts pour la migration. Tout d’abord, nous devons nous assurer qu’aucun ticket n’est plus traité et qu’aucun utilisateur ne se connecte à ((OTRS)) Community Edition :

Veuillez vous connecter à la zone d’administration ((OTRS)) Community Edition Admin -> Maintenance système et ajoutez un nouveau créneau de maintenance système pour quelques heures. Supprimez ensuite toutes les sessions d’agents et d’utilisateurs (Admin -> Sessions) et déconnectez-vous.

Arrêter tous les services pertinents et le démon OTRS

Veuillez vous assurer qu’aucun service ou tâche Cron n’est en cours d’exécution.

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

Supprimer les caches et les données d’exploitation

Les données mises en cache et les données d’exploitation n’ont pas besoin d’être migrées. La file d’attente d’e-mails devrait déjà être vide à ce stade.

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

Étape optionnelle pour Docker

Il y a quelques particularités à prendre en compte si votre installation OTOBO s’exécute sous Docker. Le plus pertinent : les processus s’exécutant dans un conteneur Docker ne peuvent généralement pas accéder aux répertoires en dehors du conteneur. Il existe cependant une exception : les répertoires montés en tant que volumes dans le conteneur peuvent être consultés. Notez également que la base de données MariaDB, qui s’exécute dans otobo_db_1 (otobo-db-1 dans les versions plus récentes de docker compose), n’est pas directement accessible depuis l’extérieur du réseau du conteneur.

::: info

Dans les exemples de commandes, nous supposons que l’utilisateur docker_admin est utilisé pour l’interaction avec Docker. L’administrateur Docker peut être soit l’utilisateur root de l’hôte Docker, soit un utilisateur dédié avec les autorisations requises.

:::

Copiez /opt/otrs dans le volume otobo_opt_otobo

::: note Noms des conteneurs Dans les anciennes versions de docker compose, les noms des conteneurs sont otobo_web_1, otobo_db_1 et otobo_daemon_1. Dans les versions plus récentes, les noms des conteneurs sont otobo-web-1, otobo-db-1 et otobo-daemon-1.

:::

Dans cette section, nous supposons que le répertoire racine OTRS /opt/otrs est disponible sur l’hôte Docker.

Il existe au moins deux possibilités viables :

a. Copiez /opt/otrs dans le volume existant otobo_opt_otobo

b. Montez /opt/otrs en tant que volume supplémentaire

Concentrons-nous ici sur l’option a..

Tout d’abord, nous devons savoir où le volume otobo_opt_otobo est disponible sur l’hôte Docker.

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

Pour une copie sécurisée, nous utilisons rsync. Selon votre configuration Docker, la commande rsync peut devoir être exécutée avec 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  # juste pour vérification
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  # juste pour vérification

Ce répertoire copié sera disponible à l’intérieur du conteneur sous /opt/otobo/var/tmp/copied_otrs.

Étape 5 : Migrer les données

:::note Commande Docker Compose Dans les anciennes versions de Docker Compose, la commande docker-compose était utilisée. Dans les versions plus récentes, docker compose est utilisé. :::

Veuillez utiliser l’outil de migration Web à l’adresse http://localhost/otobo/migration.pl. Notez que vous devrez peut-être remplacer “localhost” par votre nom d’hôte OTOBO et éventuellement ajouter votre port non standard. L’application vous guidera ensuite tout au long du processus de migration.

::: warning

Parfois, un avertissement s’affiche indiquant que la désactivation du SecureMode n’a pas été détectée. Dans ce cas, veuillez redémarrer le serveur Web. Cela force le serveur Web à lire la configuration actuelle.

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

:::

::: info

Si OTOBO s’exécute dans un conteneur Docker, conservez les paramètres par défaut localhost pour le serveur OTRS et /opt/otobo/var/tmp/copied_otrs pour le répertoire racine OTRS. Il s’agit du chemin d’accès aux données copiées lors de l’étape optionnelle.

:::

::: info

Les valeurs par défaut pour l’utilisateur et le mot de passe de la base de données OTRS sont reprises de Kernel/Config.pm dans le répertoire racine OTRS. Modifiez les paramètres suggérés si vous utilisez un utilisateur de base de données dédié pour la migration. Modifiez également les paramètres si vous travaillez avec une base de données qui a été copiée dans le conteneur Docker otobo_db_1.

:::

::: info

Dans le cas de Docker, une base de données s’exécutant sur l’hôte Docker n’est pas accessible via 127.0.0.1 à l’intérieur du conteneur Docker. Cela signifie que le paramètre 127.0.0.1 ne sera pas valide pour le champ de saisie Serveur OTRS. Dans ce cas, entrez l’une des adresses IP alternatives signalées par la commande hostname --all-ip-addresses pour Serveur OTRS.

:::

::: info

Lors de la migration vers un nouveau serveur d’application ou vers une installation basée sur Docker, la base de données ne peut souvent pas être accessible depuis l’installation cible. Cela est généralement dû au fait que l’utilisateur de la base de données otobo ne peut se connecter qu’à partir de l’hôte sur lequel la base de données s’exécute. Pour permettre l’accès malgré tout, il est recommandé de créer un utilisateur de base de données dédié pour la migration, par ex. CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; et GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Cet utilisateur peut être supprimé après la migration : DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

:::

Les paramètres spécifiques à l’utilisateur dans Kernel/Config.pm sont transférés de l’ancienne installation OTRS vers la nouvelle installation OTOBO. Si vous avez des paramètres spécifiques à l’utilisateur, vous devriez jeter un œil au fichier migré /opt/otobo/Kernel/Config.pm. Vous voudrez peut-être ajuster les chemins personnalisés ou les paramètres LDAP. Dans le meilleur des cas, vous constaterez que certains paramètres personnalisés ne sont plus nécessaires.

Une fois la migration terminée, veuillez prendre le temps de tester l’ensemble du système. Une fois que vous avez décidé que la migration a réussi et que vous souhaitez utiliser OTOBO à partir de maintenant, démarrez le démon OTOBO :

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

Dans le cas de Docker :

cd ~/otobo-docker
docker-compose start daemon

Étape 6 : Nettoyage

Désinstallez sshpass si vous n’en avez plus besoin.
Supprimez les bases de données et les utilisateurs de base de données créés spécifiquement pour la migration, le cas échéant.
Amusez-vous bien avec OTOBO !

Problèmes de migration connus

Connexion impossible après la migration

Lors de nos tests de migration, le navigateur utilisé pour la migration a parfois rencontré des problèmes. Après le redémarrage du navigateur, ce problème était généralement résolu. Avec Safari, il était parfois nécessaire de supprimer manuellement l’ancienne session OTRS.

La page finale de la migration a une mise en page étrange

Cela peut arriver si le paramètre ScriptAlias a une valeur non standard. La migration remplace simplement otrs par otobo. Cela peut empêcher l’extraction des fichiers CSS et JavaScript dans OTOBO. Si tel est le cas, veuillez vérifier les paramètres dans Kernel/Config.pm et les rétablir à des valeurs raisonnables.

La migration s’arrête à cause d’erreurs MySQL

Sur les systèmes ayant rencontré des problèmes lors d’une mise à niveau par le passé, le processus de migration peut s’arrêter en raison d’erreurs MySQL dans les tables ticket et ticket_history. En règle générale, il s’agit de valeurs NULL dans la table source qui ne sont plus autorisées dans la table cible. Ces conflits doivent être résolus manuellement avant de pouvoir poursuivre la migration.

Depuis OTOBO 10.0.12, il existe une vérification dans migration.pl qui vérifie les valeurs NULL avant le transfert de données. Notez que la résolution doit toujours être effectuée manuellement.

Erreur à l’étape 5 lors de la migration vers PostgreSQL

Dans ces cas, le message peu utile “Le système n’a pas pu terminer le transfert de données.” est affiché par migration.pl. Le fichier journal Apache et le fichier journal OTOBO affichent un message plus explicite : “Message d’erreur : ERROR: permission denied to set parameter “session_replication_role”, SQL: ‘set session_replication_role to replica;’” Pour accorder à l’utilisateur de base de données otobo les privilèges de superutilisateur requis, exécutez la commande suivante en tant qu’administrateur PostgreSQL : ALTER USER [otobo](../index.md) WITH SUPERUSER;. Essayez ensuite d’exécuter à nouveau http://localhost/otobo/migration.pl. Après la migration, revenez à l’état normal en exécutant ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Il n’est pas encore clair si les privilèges étendus doivent être accordés dans chaque configuration.

::: tip

La discussion dans le forum OTOBO

:::

Problèmes avec le déploiement de la configuration système fusionnée

La configuration système est migrée après la migration des tables de base de données. Dans ce contexte, migration signifie que les paramètres par défaut d’OTOBO sont fusionnés avec la configuration système du système OTRS source. Des incohérences peuvent survenir à cette étape. Un exemple pratique est le paramètre Ticket::Frontend::AgentTicketQuickClose###State. Ce paramètre est nouveau dans OTOBO 10 et la valeur par défaut est l’état closed successful. Mais ce paramètre est invalide si l’état closed successful a été supprimé ou renommé dans le système source. Cette incohérence est détectée comme une erreur lors de l’étape de migration Migrate configuration settings. La configuration système fusionnée est effectivement enregistrée dans la base de données, mais des vérifications de validité supplémentaires sont effectuées lors du déploiement.

Le problème doit être résolu manuellement à l’aide des commandes de console OTOBO.

Listez les incohérences avec la commande bin/otobo.Console.pl Admin::Config::ListInvalid.
Corrigez les valeurs invalides de manière interactive avec bin/otobo.Console.pl Admin::Config::FixInvalid.
Déployez les modifications collectées par migration.pl, y compris le SecureMode désactivé, avec bin/otobo.Console.pl Maint::Config::Rebuild.

Après ces étapes manuelles, vous devriez être en mesure d’exécuter à nouveau migration.pl. La migration se poursuivra à partir de l’étape où l’erreur s’est produite.

Tâches manuelles finales

Règles de politique de mot de passe

Avec OTOBO 10, une nouvelle politique de mot de passe par défaut pour les agents et les utilisateurs clients entre en vigueur si l’authentification locale est utilisée. Les règles de politique de mot de passe peuvent être modifiées dans la configuration système (PreferencesGroups###Password et CustomerPersonalPreference###Password).

Règle de politique de mot de passe	Par défaut
`PasswordMinSize`	8
`PasswordMin2Lower2UpperCharacters`	Oui
`PasswordNeedDigit`	Oui
`PasswordHistory`	10
`PasswordTTL`	30 jours
`PasswordWarnBeforeExpiry`	5 jours
`PasswordChangeAfterFirstLogin`	Oui

Sous Docker : Migrer manuellement les tâches Cron

Dans une installation non basée sur Docker d’OTOBO, il existe au moins une tâche Cron qui vérifie la santé du démon. Sous Docker, cette tâche Cron n’existe plus. De plus, aucun démon Cron ne s’exécute dans l’un des conteneurs Docker. Cela signifie que vous devez rechercher une solution individuelle pour les systèmes OTRS avec des tâches Cron spécifiques à l’utilisateur (par exemple, sauvegarde de la base de données).

Migration d’Oracle vers Oracle

Pour la migration vers Oracle, la stratégie de type ETL doit être appliquée. Cela est dû au fait qu’Oracle n’offre pas de moyen simple de désactiver temporairement la vérification des clés étrangères.

Sur l’hôte OTOBO, un client Oracle ainsi que le module Perl DBD::Oracle doivent être installés.

::: info

Lors de l’utilisation du client instantané Oracle, le SDK optionnel est également requis pour l’installation de DBD::Oracle.

:::

Il existe de nombreuses façons de cloner un schéma. Dans les exemples de commandes, nous utilisons expdp et impdp, qui utilisent Data Pump sous le capot.

::: info

Les chaînes de connexion présentées dans cette documentation se réfèrent au cas où les bases de données source et cible s’exécutent dans un conteneur Docker. Voir aussi https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

:::

Nettoyage d’otobo

Arrêtez le serveur Web pour otobo afin que la connexion DB pour otobo soit fermée.

DROP USER otobo CASCADE

Export de l’ensemble du schéma 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

Importer le schéma OTRS et renommer le schéma en ‘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;

Ajuster le schéma cloné otobo

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # il est normal que la commande ne connaisse que la base de données otobo, seule la dernière ligne est pertinente
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

Pour le contrôle avec `select owner, table_name from all_tables where table_name like ‘ARTICLE_DATA_OT%_CHAT’;

Redémarrez le serveur Web pour OTOBO
Passez à l’étape 5, c’est-à-dire exécutez migration.pl.

::: info

Lors de la migration vers une version OTOBO supérieure ou égale à 10.1, le script /opt/otobo/scripts/DBUpdate-to-10.1.pl doit être exécuté pour créer les tables stats_report et data_storage nouvellement ajoutées dans la version 10.1.

:::

Optionnel : Migration simplifiée de la base de données (uniquement pour les experts et les scénarios spéciaux)

Dans la stratégie de migration générale, toutes les données des tables de base de données sont copiées ligne par ligne de la base de données OTRS vers la base de données OTOBO. L’exportation des données de la base de données OTRS et l’importation dans la base de données OTOBO peuvent faire gagner du temps et sont dans certains cas plus stables.

::: info

Cette variante fonctionne aussi bien pour les installations basées sur Docker que pour les installations natives.

:::

::: info

Ces instructions supposent que ((OTRS)) Community Edition utilise MySQL comme backend.

:::

Tout d’abord, nous avons besoin d’un dump des tables de base de données OTRS requises. Ensuite, nous devons effectuer quelques transformations :

Conversion du jeu de caractères en utf8mb4
Renommage de certaines tables
Raccourcissement de certaines colonnes de table

Après la transformation, nous pouvons écraser les tables du schéma OTOBO avec les données transformées provenant d’OTRS. En fait, nous n’avons pas besoin d’un seul fichier dump, mais de plusieurs scripts SQL.

Si mysqldump est installé et qu’une connexion à la base de données OTRS est possible, vous pouvez créer le dump de base de données directement sur l’hôte Docker. Ce cas est pris en charge par le script bin/backup.pl.

::: warning

Cela nécessite qu’une installation OTOBO soit disponible sur l’hôte 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

Alternativement, la base de données peut être sauvegardée sur un autre serveur, puis transférée sur l’hôte Docker. Un moyen simple de le faire consiste à copier /opt/otobo sur le serveur où OTRS s’exécute et à exécuter la même commande que ci-dessus.

:::

Le script bin/backup.pl génère quatre scripts SQL dans un répertoire de dump, par ex. dans 2021-04-13_12-13-04. Pour exécuter les scripts SQL, nous devons exécuter la commande mysql.

Installation native :

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

Installation basée sur Docker :

Exécutez la commande mysql à l’intérieur du conteneur Docker db pour importer les fichiers de dump de base de données. Notez que le mot de passe pour le root de la base de données est maintenant le mot de passe défini dans le fichier .env sur l’hôte 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

Pour une vérification rapide du fonctionnement de l’importation, vous pouvez exécuter les commandes suivantes.

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'

ou lors de l’exécution sous 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'

La base de données est maintenant migrée. Cela signifie que nous pouvons ignorer la migration de la base de données à l’étape suivante. Faites attention à la case à cocher correspondante.