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, chaque migration vers OTOBO nécessite une préparation minutieuse et potentiellement 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 seront 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 :

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

   C'est la manière normale de procéder à une migration. De nombreuses combinaisons différentes sont prises en charge :

   • Changement de serveur : Migrer et changer de serveur d'application en même temps.

   • 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 des hôtes dédiés chacun. Ce choix est indépendant de la configuration précédente dans OTRS / ((OTRS)) Community Edition.

   • Bases de données différentes : Migrer d'une base de données prise en charge à une autre base de données prise en charge.

   • Systèmes d'exploitation différents : Passer d'un système d'exploitation pris en charge à un autre système d'exploitation pris en charge.

   • Docker : Migrer vers une installation OTOBO 10 basée sur Docker.

2. 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 soumise à une charge accrue ou si l'accès à la base de données source constitue un goulot d'étranglement. Dans la stratégie générale, les données sont lues ligne par ligne depuis 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 et enfin importées dans la base de données otobo.

3. 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. Mais 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 réelle. Cela peut accélérer la stratégie de migration générale.

Exigences de migration

1. La condition préalable à 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 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 une meilleure option. En effet, l'installation et la configuration utilisées précédemment étaient souvent plutôt sous-optimales. Il peut également être judicieux de ne transférer que les données des tickets et de faire passer la configuration de base aux meilleures pratiques d'OTOBO.

2. Vous avez besoin d'une installation OTOBO en cours d'exécution pour démarrer la migration à partir de là !

3. 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.

4. 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èmes de fichiers.

5. La base de données ((otrs)) Community Edition doit être accessible depuis le serveur sur lequel OTOBO est en cours d'exécution. L'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 migration doit être optimisée, une sauvegarde de la base de données est suffisante.

INFO

Si l'accès SSH et à la base de données n'est pas possible entre les serveurs, veuillez migrer ((OTRS)) Community Edition vers OTOBO sur le même serveur, puis déplacez la nouvelle installation.

Instructions étape par étape

Étape 1 : Installation d'OTOBO

Veuillez commencer par installer 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 d'installer 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 section Admin d'OTOBO Admin -> Paquets et installez tous les paquets OTOBO OPM requis.

Les paquets OPM et les "Feature Addons" ((OTRS)) Community Edition suivants NE DOIVENT PAS et NE DEVRAIENT PAS être installés, car ces fonctionnalités sont déjà incluses dans la norme 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 SecureMode

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

INFO

N'oubliez pas de réellement implémenter 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 terminé avec le code 0

INFO

Il est recommandé de faire une sauvegarde de l'ensemble du système OTOBO à ce stade. Si quelque chose se passe mal 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.

Monter /opt/otrs en option

Souvent, OTOBO est destiné à fonctionner sur un nouveau serveur où /opt/otrs n'est initialement pas disponible. Dans ces cas, le répertoire /opt/otrs du 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 :

Installer sshpass sous Debian / Ubuntu Linux

sudo apt install sshpass

Installer sshpass sous RHEL/CentOS Linux

sudo yum install sshpass

Installer sshpass sous Fedora Linux

sudo dnf install sshpass

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 seule entrée incorrecte 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 en cours de traitement et qu'aucun utilisateur ne se connecte à ((OTRS)) Community Edition :

Veuillez vous connecter à la section Admin d'((OTRS)) Community Edition Admin -> Maintenance système et ajouter un nouveau créneau de maintenance système pour quelques heures. Ensuite, supprimez 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 ne s'exécute.

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

Supprimer les caches et les données opérationnelles

Les données mises en cache et les données opérationnelles n'ont pas besoin d'être migrées. La file d'attente des 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 sont accessibles. Notez également que la base de données MariaDB s'exécutant 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 Docker.

INFO

Dans les exemples de commandes, nous supposons que l'utilisateur docker_admin est utilisé pour interagir avec Docker. L'administrateur Docker peut être l'utilisateur root de l'hôte Docker ou un utilisateur dédié avec les autorisations nécessaires.

Copier /opt/otrs dans le volume otobo_opt_otobo

::: note Noms de 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 d'accueil OTRS /opt/otrs est disponible sur l'hôte Docker.

Il existe au moins deux options viables :

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

b. Monter /opt/otrs comme 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 de SecureMode n'a pas été détectée. Dans ce cas, veuillez redémarrer le serveur web. Cela forcera 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 valeurs par défaut localhost pour le serveur OTRS et /opt/otobo/var/tmp/copied_otrs pour le répertoire d'accueil OTRS. C'est le chemin des données copiées à 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 d'accueil 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 copiée dans le conteneur Docker otobo_db_1.

INFO

Dans le cas de Docker, une base de données fonctionnant 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 OTRS-Server. Dans ce cas, entrez l'une des adresses IP alternatives rapportées par la commande hostname --all-ip-addresses pour OTRS-Server.

INFO

Lors de la migration vers un nouveau serveur d'application ou une installation basée sur Docker, la base de données n'est souvent pas accessible depuis l'installation cible. Cela est généralement dû au fait que l'utilisateur de base de données otobo ne peut se connecter qu'à partir de l'hôte où la base de données s'exécute. Pour permettre l'accès, il est recommandé de créer un utilisateur de base de données dédié pour la migration, par exemple 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 à 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 pourriez vouloir ajuster les chemins personnalisés ou les paramètres LDAP. Au mieux, vous constaterez que certains paramètres personnalisés ne sont plus nécessaires.

Une fois la migration terminée, prenez le temps de tester l'ensemble du système. Dès que vous aurez 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

1. Désinstallez sshpass si vous n'en avez plus besoin.

2. 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.

3. Profitez d'OTOBO !

Problèmes de migration connus

Impossible de se connecter 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 a généralement été résolu. Avec Safari, il était parfois nécessaire de supprimer manuellement l'ancienne session OTRS.

La dernière page 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 entraîner l'impossibilité de récupérer les fichiers CSS et JavaScript dans OTOBO. Si tel est le cas, veuillez vérifier les paramètres dans Kernel/Config.pm et les modifier pour revenir à des valeurs raisonnables.

La migration s'arrête en raison d'erreurs MySQL

Sur les systèmes qui ont eu des problèmes de mise à niveau dans le passé, le processus de migration peut s'arrêter en raison d'erreurs MySQL dans les tables ticket et ticket_history. Il s'agit généralement 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.

À partir de OTOBO 10.0.12, il existe une vérification dans migration.pl qui recherche les valeurs NULL avant le transfert des données. Notez que la 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 des données." est affiché par migration.pl. Le fichier journal Apache et le fichier journal OTOBO affichent un message plus significatif : " 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 à nouveau d'exécuter 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 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, la 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 concret est le paramètre Ticket::Frontend::AgentTicketQuickClose###State. Ce paramètre est nouveau dans OTOBO 10 et la valeur par défaut est le statut closed successful. Mais ce paramètre est invalide si le statut closed successful a été supprimé ou renommé dans le système source. Cette incohérence est détectée comme une erreur à 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.

• Liste les incohérences avec la commande bin/otobo.Console.pl Admin::Config::ListInvalid.

• Corrigez les valeurs invalides interactivement 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 à 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 lors de l'utilisation de l'authentification locale. Les règles de politique de mot de passe peuvent être modifiées dans la configuration du 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 : Migration manuelle des tâches Cron

Dans une installation non 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 aucun des conteneurs Docker. Cela signifie que vous devrez rechercher une solution personnalisée pour les systèmes OTRS avec des tâches Cron personnalisées (par exemple, la 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. En effet, 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 d'Oracle Instant Client, 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 en arrière-plan.

INFO

Les chaînes de connexion montrées dans cette documentation se réfèrent au cas où la base de données source et la base de données cible s'exécutent toutes deux dans un conteneur Docker. Voir également https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Nettoyage d'otobo

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

DROP USER otobo CASCADE

2. Exportation 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

3. Importation du schéma OTRS et renommage du 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;

4. Ajustement du 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 vérification, utilisez `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Redémarrez le serveur web pour OTOBO.

6. Continuez à l'étape 5, c'est-à-dire exécutez migration.pl.

INFO

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

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

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 leur importation dans la base de données OTOBO peut faire gagner du temps et est plus stable dans certains cas.

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'une sauvegarde des tables de base de données OTRS nécessaires. Ensuite, nous devons effectuer quelques transformations :

• Conversion du jeu de caractères en utf8mb4

• Renommage de certaines tables

• Troncation de certaines colonnes de table

Après la transformation, nous pouvons écraser les tables du schéma OTOBO avec les données transformées d'OTRS. En fait, nous n'avons pas besoin d'un seul fichier de sauvegarde, 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 la sauvegarde de la 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. Une façon simple de le faire est de copier /opt/otobo sur le serveur où OTRS est en cours d'exécution et d'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 sauvegarde, par exemple 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 sauvegarde de la base de données. Notez que le mot de passe pour la base de données root 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 succès 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.