Migration de la version communautaire ((OTRS)) vers OTOBO

Bienvenue et merci d’avoir choisi OTOBO !
OTRS, la version communautaire ((OTRS)) et OTOBO sont des solutions très complètes et flexibles. Par conséquent, chaque migration vers OTOBO nécessite une préparation minutieuse et peut parfois exiger un travail complémentaire.

Veuillez prendre le temps nécessaire pour la migration et suivez attentivement les étapes décrites ci-dessous.

INFO

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

Aperçu de la migration OTOBO

L'interface de migration OTOBO permet d'utiliser les stratégies suivantes :

Stratégie générale de migration.
C’est la méthode standard pour effectuer une migration. Elle prend en charge de nombreuses combinaisons différentes :
- Changement de serveur : Migrer tout en passant à un nouveau serveur applicatif.
- Serveurs applicatif et web séparés : Vous pouvez choisir d’exécuter les serveurs applicatif et de base de données sur le même hôte ou sur des hôtes dédiés distincts. 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 supportée vers une autre base de données supportée.
- Différents systèmes d’exploitation : Passer d’un système d’exploitation supporté à un autre système d’exploitation supporté.
- Docker : Migrer vers une installation OTOBO 10 basée sur Docker.
Variante de la stratégie générale, optimisée pour la migration de la base de données.
Utilisez la migration de type ETL si la base de données source ne doit pas être surchargée ou si l’accès à celle-ci 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 otrs sont d’abord exportées, puis transformées, puis importées dans la base otobo.
Migration d’une installation ((OTRS)) Community Edition 6 basée sur Oracle vers une installation OTOBO également basée sur Oracle.
Il s’agit d’un cas particulier non pris en charge par la stratégie générale. Une variante de la stratégie optimisée doit donc être utilisée.

WARNING

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

INFO

Il est également possible de cloner la base de données de la version ((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 générale de migration.

Prérequis pour la migration

Le prérequis fondamental est d’avoir déjà une version ((OTRS)) Community Edition ou OTRS 6.0.* en fonctionnement, et de vouloir transférer à la fois la configuration et les données vers OTOBO.
WARNING
Réfléchissez bien à la nécessité réelle de conserver les données et la configuration. L’expérience montre que dans de nombreux cas, repartir de zéro est une meilleure option. En effet, l’installation et la configuration précédentes étaient souvent sous-optimales. Il pourrait aussi être judicieux de ne transférer que les données des tickets et de reconfigurer les paramètres de base selon les meilleures pratiques OTOBO.
Vous devez disposer d’une installation OTOBO opérationnelle pour lancer la migration depuis celle-ci !
Cette installation OTOBO doit contenir tous les paquets OPM installés dans votre ((OTRS)) Community Edition que vous souhaitez continuer à utiliser dans OTOBO.
Si vous prévoyez de migrer vers un autre serveur, le serveur web OTOBO doit pouvoir accéder à l’emplacement où ((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 hébergeant ((OTRS)) Community Edition. L’accès en lecture peut s’effectuer 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 installé. L’accès en lecture seule doit être autorisé pour les hôtes distants. Si l’accès n’est pas possible ou si vous souhaitez optimiser la vitesse de migration, un dump de la base de données suffit.

INFO

Si l’accès SSH et à la base de données entre les serveurs n’est pas possible, effectuez d’abord la migration de ((OTRS)) Community Edition vers OTOBO sur le même serveur, puis déplacez l’installation une fois terminée.

Guide étape par étape

Étape 1 : Installation d’OTOBO

Commencez 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. Il est donc recommandé d’exécuter ((OTRS)) Community Edition et OTOBO sur des serveurs web distincts. Sinon, retirez la configuration OTRS 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, connectez-vous en tant que root@localhost. Accédez à la section d’administration OTOBO Admin -> Paquets et installez tous les paquets OPM OTOBO nécessaires.

Les paquets OPM suivants et les « Feature Addons » de ((OTRS)) Community Edition NE DOIVENT PAS ET NE DOIVENT PAS ÊTRE installés, car leurs fonctionnalités sont déjà intégrées à 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 à OTOBO 10+. Cela signifie qu’ils ne doivent pas être installés sur le système cible si celui-ci est OTOBO 10+ :

ImportExport

Étape 2 : Désactiver le SecureMode

Après avoir installé OTOBO, reconnectez-vous dans la section d’administration OTOBO Admin -> Configuration système et désactivez l’option de configuration SecureMode.

INFO

N’oubliez pas d’appliquer effectivement les modifications apportées aux paramètres.

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

Cette étape est nécessaire si le démon OTOBO est en cours d’exécution. La procédure d’arrêt diffère selon que l’installation est basée ou non sur Docker.

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

bash

# 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 fonctionne sous Docker, arrêtez simplement le service daemon :

bash

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 doit s’arrêter avec le code 0

INFO

Il est recommandé de faire à ce stade une sauvegarde complète du système OTOBO (Backup). En cas de problème durant la migration, vous n’aurez pas à répéter tout le processus d’installation, mais pourrez simplement restaurer la sauvegarde pour une nouvelle tentative.

TIP

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

Optionnel : Monter /opt/otrs

Souvent, OTOBO doit fonctionner sur un nouveau serveur où /opt/otrs n’est pas disponible initialement. Dans ce 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 classique n’est pas possible, sshfs peut être une alternative.

Optionnel : Installer sshpass et rsync

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

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

Installer sshpass sous Debian / Ubuntu Linux

bash

sudo apt install sshpass

Installer sshpass sous RHEL/CentOS Linux

bash

sudo yum install sshpass

Installer sshpass sous Fedora Linux

bash

sudo dnf install sshpass

Installer sshpass sous OpenSUSE Linux

bash

sudo zypper install sshpass

Procédez de même pour rsync s’il n’est pas déjà disponible.

Étape 4 : Préparation

INFO

Assurez-vous d’avoir également une sauvegarde valide (Backup) de votre système OTRS / ((OTRS)) Community Edition. Oui, nous ne touchons pas aux données ((OTRS)) Community Edition pendant la migration, mais une simple erreur de configuration peut causer des problèmes.

Nous sommes maintenant prêts pour la migration. Tout d’abord, assurez-vous qu’aucun ticket n’est en cours de modification et qu’aucun utilisateur ne peut se connecter à ((OTRS)) Community Edition :

Connectez-vous à la section d’administration ((OTRS)) Community Edition Admin -> Maintenance système, ajoutez un créneau de maintenance système pour quelques heures, puis supprimez toutes les sessions agents et utilisateurs (Admin -> Sessions) et déconnectez-vous.

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

Assurez-vous qu’aucun service ou tâche cron n’est en cours d’exécution.

bash

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

Supprimer les caches et données d’exécution

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

bash

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

Certaines particularités doivent être prises en compte si votre installation OTOBO fonctionne sous Docker. La plus importante : les processus s’exécutant dans un conteneur Docker ne peuvent généralement pas accéder à des répertoires situés en dehors du conteneur. Une exception existe toutefois : les répertoires montés comme volumes dans le conteneur sont accessibles. Notez également que la base de données MariaDB, exécutée dans otobo_db_1 (ou otobo-db-1 dans les versions récentes de docker-compose), n’est pas directement accessible depuis l’extérieur du réseau des conteneurs.

INFO

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

Copier /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 récentes, ils sont otobo-web-1, otobo-db-1 et otobo-daemon-1.

:::

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

Il existe au moins deux méthodes pratiques :

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

b. Monter /opt/otrs comme volume supplémentaire

Nous nous concentrons ici sur l’option a.

Tout d’abord, déterminons où le volume otobo_opt_otobo est disponible sur l’hôte Docker.

bash

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 nécessiter sudo.

bash

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  # vérification uniquement
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  # vérification uniquement

Ce répertoire copié sera accessible dans le 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 récentes, c’est docker compose qui est utilisée. :::

Utilisez l’outil de migration web à l’adresse http://localhost/otobo/migration.pl. Remplacez éventuellement "localhost" par le nom d’hôte OTOBO et ajoutez un port non standard si nécessaire. L’application vous guidera ensuite à travers le processus de migration.

WARNING

Parfois, un avertissement indique que la désactivation du SecureMode n’a pas été détectée. Dans ce cas, redémarrez le serveur web pour forcer la relecture de la configuration.

bash

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

INFO

Si OTOBO fonctionne 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 home 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 OTRS sont extraites de Kernel/Config.pm dans le répertoire home OTRS. Modifiez les paramètres proposés si vous utilisez un utilisateur dédié pour la migration. Modifiez également les paramètres si vous travaillez avec une base copiée dans le conteneur Docker otobo_db_1.

INFO

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

INFO

Lors de la migration vers un nouveau serveur applicatif ou vers 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 otobo ne peut se connecter qu’à partir de l’hôte où la base est installée. Pour permettre l’accès, créez un utilisateur 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 utilisateur spécifiques dans Kernel/Config.pm sont transférés de l’ancienne installation OTRS vers la nouvelle installation OTOBO. Si vous avez des paramètres personnalisés, examinez attentivement le fichier migré /opt/otobo/Kernel/Config.pm. Vous devrez peut-être ajuster des chemins personnalisés ou des paramètres LDAP. Idéalement, 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 jugez la migration réussie et décidez d’utiliser OTOBO, redémarrez le démon OTOBO :

bash

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

Dans le cas Docker :

bash

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 utilisateurs créés spécifiquement pour la migration, s’ils existent.
Profitez bien d’OTOBO !

Problèmes connus de migration

Impossible de se connecter après la migration

Pendant nos tests, le navigateur utilisé pour la migration rencontrait parfois des problèmes. Ce problème était généralement résolu après un redémarrage du navigateur. Avec Safari, il était parfois nécessaire de supprimer manuellement l’ancienne session OTRS.

La page finale de migration a un affichage étrange

Cela peut arriver si le paramètre ScriptAlias a une valeur non standard. La migration remplace simplement otrs par otobo, ce qui peut empêcher le chargement des fichiers CSS et JavaScript dans OTOBO. Dans ce cas, vérifiez les paramètres dans Kernel/Config.pm et rétablissez des valeurs correctes.

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

Sur les systèmes ayant connu des problèmes lors d’une mise à niveau précédente, le processus de migration peut s’arrêter en raison d’erreurs MySQL dans les tables ticket et ticket_history. Généralement, 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 poursuivre.

À partir d’OTOBO 10.0.12, migration.pl inclut une vérification des valeurs NULL avant le transfert. La correction reste toutefois manuelle.

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

Dans ces cas, migration.pl affiche le message peu utile « Le système n’a pas pu terminer le transfert des données ». Les journaux Apache et OTOBO montrent un message plus clair : « Erreur : permission denied to set parameter "session_replication_role", SQL : 'set session_replication_role to replica;' ». Pour accorder les privilèges superutilisateur nécessaires à l’utilisateur otobo, exécutez en tant qu’administrateur PostgreSQL : ALTER USER [otobo](../index.md) WITH SUPERUSER;. Réessayez ensuite http://localhost/otobo/migration.pl. Après la migration, revenez à la normale avec ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Il n’est pas encore clair si ces privilèges étendus sont nécessaires dans tous les cas.

TIP

Discussion sur le Forum OTOBO

Problèmes lors du déploiement de la configuration système fusionnée

La configuration système est migrée après les tables de base de données. Ici, « migration » signifie que les paramètres par défaut d’OTOBO sont fusionnés avec la configuration du système OTRS source. Des incohérences peuvent survenir. Par exemple, le paramètre Ticket::Frontend::AgentTicketQuickClose###State est nouveau dans OTOBO 10, avec comme valeur par défaut le statut closed successful. Mais ce paramètre est invalide si ce statut a été supprimé ou renommé dans le système source. Cette incohérence est détectée comme une erreur à l’étape Migrer les paramètres de configuration. La configuration fusionnée est bien stockée dans la base, mais des vérifications supplémentaires sont effectuées lors du déploiement.

Le problème doit être corrigé manuellement via les commandes console OTOBO :

Lister les incohérences : bin/otobo.Console.pl Admin::Config::ListInvalid
Corriger les valeurs invalides : bin/otobo.Console.pl Admin::Config::FixInvalid
Déployer les modifications : bin/otobo.Console.pl Maint::Config::Rebuild

Après ces corrections, vous devriez pouvoir relancer migration.pl, qui reprendra à 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 s’applique aux agents et utilisateurs clients utilisant l’authentification locale. Les règles peuvent être modifiées dans la configuration système (PreferencesGroups###Password et CustomerPersonalPreference###Password).

Règle de politique de mot de passe	Valeur 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 OTOBO non Docker, au moins une tâche cron vérifie la santé du démon. Sous Docker, cette tâche n’existe plus, et aucun démon cron n’est actif dans les conteneurs. Vous devrez donc trouver une solution personnalisée pour les systèmes OTRS avec tâches cron spécifiques (ex. : sauvegarde de la base).

Migration Oracle vers Oracle

Pour migrer vers Oracle, la stratégie de type ETL doit être utilisée, car Oracle ne permet pas facilement de désactiver temporairement les contraintes de clés étrangères.

Un client Oracle et le module Perl DBD::Oracle doivent être installés sur l’hôte OTOBO.

INFO

Avec le client Oracle Instant, le SDK optionnel est nécessaire pour installer DBD::Oracle.

De nombreuses méthodes permettent de cloner un schéma. Ici, nous utilisons expdp et impdp, basés sur Data Pump.

INFO

Les chaînes de connexion montrées ici supposent que les bases source et cible sont dans des conteneurs Docker. Voir aussi : https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

Nettoyage d’otobo
Arrêtez le serveur web pour fermer la connexion DB d’otobo.
SQL
```
DROP USER otobo CASCADE
```

Exporter le schéma OTRS complet

bash

mkdir /tmp/otrs_dump_dir

SQL

CREATE DIRECTORY OTRS_DUMP_DIR AS '/tmp/otrs_dump_dir';
GRANT READ, WRITE ON DIRECTORY OTRS_DUMP_DIR TO sys;

bash

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 le renommer en 'otobo'

bash

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

SQL

SELECT owner, table_name FROM all_tables WHERE table_name LIKE 'ARTICLE_DATA_OT%_CHAT';
ALTER USER otobo IDENTIFIED BY XXXXXX;

Adapter le schéma otobo cloné

bash

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # OK même si la commande ne connaît que la base 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

Vérifiez 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 : exécutez migration.pl

INFO

Si vous migrez vers une version OTOBO ≥ 10.1, exécutez /opt/otobo/scripts/DBUpdate-to-10.1.pl pour créer les nouvelles tables stats_report et data_storage.

Optionnel : Migration simplifiée de la base de données (experts uniquement)

Dans la stratégie générale, les données sont copiées ligne par ligne. Exporter puis importer peut gagner du temps et être plus stable.

INFO

Cette variante fonctionne pour Docker et installations natives.

INFO

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

Créez un dump des tables OTRS nécessaires.
Transformez les données :
- Convertir l’encodage en utf8mb4
- Renommer certaines tables
- Raccourcir certaines colonnes
Remplacez les tables dans le schéma OTOBO par les données transformées.

Le script bin/backup.pl génère quatre scripts SQL dans un répertoire de dump (ex. : 2021-04-13_12-13-04). Exécutez-les avec mysql.

Installation native :

bash

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 Docker :

bash

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

Vérification rapide :

bash

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 est maintenant migrée. Vous pouvez donc ignorer l’étape de migration de la base lors de la prochaine étape.

Migration de la version communautaire ((OTRS)) vers OTOBO ​

Aperçu de la migration OTOBO ​

Prérequis pour la migration ​

Guide étape par étape ​

Étape 1 : Installation d’OTOBO ​

Étape 2 : Désactiver le SecureMode ​

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

Optionnel : Installer sshpass et rsync ​

Étape 4 : Préparation ​

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

Supprimer les caches et données d’exécution ​

Étape optionnelle pour Docker ​

Copier /opt/otrs dans le volume otobo_opt_otobo ​

Étape 5 : Migrer les données ​

Étape 6 : Nettoyage ​

Problèmes connus de migration ​

Impossible de se connecter après la migration ​

La page finale de migration a un affichage étrange ​

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

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

Problèmes lors du déploiement de la configuration système fusionnée ​

Tâches manuelles finales ​

Règles de politique de mot de passe ​

Sous Docker : Migration manuelle des tâches cron ​

Migration Oracle vers Oracle ​

Optionnel : Migration simplifiée de la base de données (experts uniquement) ​

Installation native : ​

Installation Docker : ​

Migration de la version communautaire ((OTRS)) vers OTOBO

Aperçu de la migration OTOBO

Prérequis pour la migration

Guide étape par étape

Étape 1 : Installation d’OTOBO

Étape 2 : Désactiver le SecureMode

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

Optionnel : Installer sshpass et rsync

Étape 4 : Préparation

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

Supprimer les caches et données d’exécution

Étape optionnelle pour Docker

Copier /opt/otrs dans le volume otobo_opt_otobo

Étape 5 : Migrer les données

Étape 6 : Nettoyage

Problèmes connus de migration

Impossible de se connecter après la migration

La page finale de migration a un affichage étrange

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

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

Problèmes lors du déploiement de la configuration système fusionnée

Tâches manuelles finales

Règles de politique de mot de passe

Sous Docker : Migration manuelle des tâches cron

Migration Oracle vers Oracle

Optionnel : Migration simplifiée de la base de données (experts uniquement)

Installation native :

Installation Docker :