Migración desde la Edición Comunitaria de ((OTRS)) a OTOBO

¡Bienvenido y muchas gracias por elegir OTOBO! OTRS, la Edición Comunitaria de ((OTRS)) y OTOBO son aplicaciones muy completas y flexibles. Por ello, cada migración a OTOBO requiere una preparación cuidadosa y posiblemente algo de trabajo posterior.

Tómese su tiempo para la migración y siga estas instrucciones paso a paso.

INFO

Tras la migración, los datos previamente disponibles en la Edición Comunitaria ((OTRS)) 6 estarán disponibles en OTOBO 10. No modificamos ningún dato de la instalación OTRS 6 durante el proceso de migración.

Visión general de la migración a OTOBO

Mediante la interfaz de migración de OTOBO, es posible utilizar las siguientes estrategias de migración:

1. La estrategia general de migración.

   Este es el método habitual para realizar una migración. Se admiten muchas combinaciones diferentes:

   • Cambio de servidor: Migrar y al mismo tiempo cambiar al nuevo servidor de aplicaciones.

   • Servidores de aplicaciones y web separados: Puede elegir si desea ejecutar los servidores de aplicaciones y base de datos en el mismo host o en hosts dedicados separados. Esta elección es independiente de la configuración anterior en OTRS / Edición Comunitaria ((OTRS)).

   • Diferentes bases de datos: Migrar desde cualquier base de datos compatible a otra base de datos compatible.

   • Diferentes sistemas operativos: Cambiar desde cualquier sistema operativo compatible a otro sistema operativo compatible.

   • Docker: Migrar a una instalación basada en Docker de OTOBO 10.

2. Una variante de la estrategia general en la que se optimiza la migración de la base de datos.

Utilice la migración similar a ETL si no se debe sobrecargar la base de datos de origen con cargas adicionales o si el acceso a la base de datos de origen es un cuello de botella. En la estrategia general, los datos se leen fila por fila primero desde la base de datos otrs y luego se insertan en la base de datos OTOBO. En esta variante, las tablas completas de la base de datos otrs se exportan primero, luego se transforman y finalmente se importan en la base de datos otobo.

3. Migración desde una instalación de ((OTRS)) Community Edition 6 basada en Oracle a una instalación de OTOBO también basada en Oracle.

Este es un caso especial que no es compatible con la estrategia general de migración. Esto significa que debe utilizarse una variante de la estrategia optimizada.

WARNING

Todas las estrategias funcionan tanto para instalaciones basadas en Docker como para instalaciones nativas. Sin embargo, para instalaciones basadas en Docker deben tenerse en cuenta ciertas particularidades. Estas particularidades se tratan en los pasos opcionales.

INFO

También es posible clonar la base de datos de la Edición Comunitaria ((OTRS)) al servidor de base de datos de OTOBO antes de la migración real. Esto puede acelerar la estrategia general de migración.

Requisitos para la migración

1. El requisito previo fundamental para una migración es que ya tenga funcionando una Edición Comunitaria ((OTRS)) o OTRS 6.0.* y desee transferir tanto la configuración como los datos a OTOBO.

   WARNING

   Considere cuidadosamente si realmente necesita los datos y la configuración. La experiencia muestra que en muchos casos, comenzar desde cero es la mejor opción. Esto se debe a que la instalación y configuración previamente utilizada a menudo era subóptima. También podría tener sentido transferir solo los datos de tickets y reconfigurar la configuración básica según las mejores prácticas de OTOBO.

2. ¡Necesita una instalación de OTOBO en funcionamiento para iniciar desde allí el proceso de migración!

3. Esta instalación de OTOBO debe incluir todos los paquetes OPM que estén instalados en su Edición Comunitaria ((OTRS)) y que desee seguir utilizando en OTOBO.

4. Si planea migrar a otro servidor, el servidor web de OTOBO debe poder acceder al lugar donde está instalada su Edición Comunitaria ((OTRS)) o OTRS 6.0._. En la mayoría de los casos, se trata del directorio _/opt/otrs* en el servidor donde se ejecuta la Edición Comunitaria ((OTRS)). El acceso de lectura puede realizarse mediante SSH o mediante montajes del sistema de archivos.

5. La base de datos de la Edición Comunitaria ((otrs)) debe ser accesible desde el servidor donde se ejecuta OTOBO. Debe permitirse el acceso de solo lectura desde hosts externos. Si el acceso no es posible o si desea optimizar la velocidad de la migración, entonces un volcado (dump) de la base de datos es suficiente.

INFO

Si no es posible el acceso SSH ni a la base de datos entre los servidores, migre primero la Edición Comunitaria ((OTRS)) a OTOBO en el mismo servidor y luego mueva la nueva instalación.

Instrucciones paso a paso

Paso 1: Instalación de OTOBO

Comience con la instalación de un nuevo sistema OTOBO. Su antigua instalación de OTRS / Edición Comunitaria ((OTRS)) se migrará a este nuevo sistema.

WARNING

Con Apache existen trampas al ejecutar dos aplicaciones independientes mod_perl en el mismo servidor web. Por ello, se recomienda ejecutar la Edición Comunitaria ((OTRS)) y OTOBO en servidores web separados. Alternativamente, debería eliminar la configuración de OTRS de Apache antes de instalar OTOBO. Utilice el comando a2query -s y verifique los directorios /etc/apache2/sites-available y /etc/apache2/sites-enabled para ver qué configuraciones están actualmente disponibles y habilitadas.

Una vez completada la instalación, inicie sesión como root@localhost. Vaya al área de administración de OTOBO Admin -> Paquetes e instale todos los paquetes OPM de OTOBO necesarios.

Los siguientes paquetes OPM y "Feature Addons" de la Edición Comunitaria ((OTRS)) NO deben y NO deben instalarse, ya que estas funcionalidades ya están incluidas en OTOBO por defecto:

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

Los siguientes paquetes de OTOBO-Pakete se han integrado en OTOBO 10+. Esto significa que no deben instalarse en el sistema destino si este es OTOBO 10+:

• ImportExport

Paso 2: Desactivar SecureMode

Después de instalar OTOBO, inicie sesión nuevamente en el área de administración de OTOBOAdmin -> Configuración del sistema y desactive la opción de configuración SecureMode.

INFO

No olvide implementar realmente el cambio de configuración.

Paso 3: Detener el Daemon de OTOBO

Esto es necesario si el Daemon de OTOBO está realmente en ejecución. Detener el daemon varía entre instalaciones basadas en Docker y no basadas en Docker.

En el caso sin Docker, ejecute los siguientes comandos como usuario otobo:

# si ha iniciado sesión como root
root> su - otobo

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

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

Si OTOBO se ejecuta en Docker, simplemente debe detener el servicio daemon:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 debería haber terminado con código 0

INFO

Se recomienda realizar en este punto una copia de seguridad (Backup) completa del sistema OTOBO. Si durante la migración algo sale mal, no tendrá que repetir todo el proceso de instalación, sino que podrá importar la copia de seguridad (Backup) para una nueva migración.

TIP

Le recomendamos leer el capítulo Copia de seguridad de OTOBO backup-restore.

Opcional: montar /opt/otrs

A menudo se desea que OTOBO se ejecute en un nuevo servidor donde inicialmente /opt/otrs no está disponible. En estos casos, el directorio /opt/otrs en el servidor de la Edición Comunitaria ((OTRS)) puede montarse en el sistema de archivos del servidor OTOBO. Si un montaje de red estándar no es posible, sshfs podría ser una opción.

Opcional: sshpass y rsync

Este paso solo es necesario si desea migrar la Edición Comunitaria ((OTRS)) desde otro servidor y /opt/otrs no se ha montado desde el servidor remoto al servidor OTOBO.

Las herramientas sshpass y rsync son necesarias para que migration.pl pueda copiar archivos mediante ssh. Para instalar sshpass, inicie sesión como usuario root en el servidor y ejecute uno de los siguientes comandos:

Instalar sshpass en Debian / Ubuntu Linux

sudo apt install sshpass

Instalar sshpass en RHEL/CentOS Linux

sudo yum install sshpass

Instalar sshpass en Fedora Linux

sudo dnf install sshpass

Instalar sshpass en OpenSUSE Linux

sudo zypper install sshpass

Lo mismo debe hacerse con rsync si aún no está disponible.

Paso 4: Preparación

INFO

Asegúrese de tener también una copia de seguridad (Backup) válida de su sistema OTRS / Edición Comunitaria ((OTRS)). Sí, no tocamos los datos de la Edición Comunitaria ((OTRS)) durante la migración, pero a veces un simple error puede causar problemas.

Ahora estamos listos para la migración. Primero debemos asegurarnos de que no se estén editando más tickets y de que ningún usuario pueda iniciar sesión en la Edición Comunitaria ((OTRS)):

Inicie sesión en el área de administración de la Edición Comunitaria ((OTRS)) Admin -> Mantenimiento del sistema y agregue una nueva franja de mantenimiento del sistema durante algunas horas. Luego elimine todas las sesiones de agentes y usuarios (Admin -> Sesiones) y cierre la sesión.

Detener todos los servicios relevantes y el daemon de OTRS

Asegúrese de que no haya servicios ni trabajos cron en ejecución.

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

Eliminar cachés y datos operativos

Los datos en caché y los datos operativos no necesitan migrarse. La cola de correo debería estar vacía en este momento.

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

Paso opcional para Docker

Existen algunas particularidades a tener en cuenta si su instalación de OTOBO se ejecuta bajo Docker. La más importante: los procesos que se ejecutan dentro de un contenedor Docker generalmente no pueden acceder a directorios fuera del contenedor. Sin embargo, existe una excepción: los directorios montados como volúmenes en el contenedor sí pueden accederse. Tenga en cuenta también que la base de datos MariaDB que se ejecuta en otobo_db_1 (otobo-db-1 en versiones más recientes de docker compose) no es directamente accesible desde fuera de la red del contenedor.

INFO

En los ejemplos de comandos, asumimos que el usuario docker_admin se utiliza para interactuar con Docker. El administrador de Docker puede ser el usuario root del host Docker o un usuario dedicado con los permisos necesarios.

Copiar /opt/otrs al volumen otobo_opt_otobo

::: note Nombres de contenedores En versiones antiguas de docker compose, los nombres de contenedores son otobo_web_1, otobo_db_1 y otobo_daemon_1. En versiones más recientes, los nombres son otobo-web-1, otobo-db-1 y otobo-daemon-1.

:::

En esta sección, asumimos que el directorio home de OTRS /opt/otrs está disponible en el host Docker.

Existen al menos dos opciones viables:

a. Copiar /opt/otrs al volumen existente otobo_opt_otobo

b. Montar /opt/otrs como volumen adicional

Nos centraremos aquí en la opción a..

Primero debemos descubrir dónde está disponible el volumen otobo_opt_otobo en el host Docker.

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

Para copiar de forma segura, usamos rsync. Dependiendo de su configuración de Docker, el comando rsync puede necesitar ejecutarse con 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  # solo para verificación
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  # solo para verificación

Este directorio copiado estará disponible dentro del contenedor como /opt/otobo/var/tmp/copied_otrs.

Paso 5: Migrar datos

:::note Comando Docker Compose En versiones antiguas de Docker Compose se usaba el comando docker-compose. En versiones más recientes se usa docker compose. :::

Utilice la herramienta web de migración en http://localhost/otobo/migration.pl. Tenga en cuenta que puede necesitar reemplazar "localhost" por el nombre de host de su OTOBO y posiblemente agregar un puerto no estándar. La aplicación lo guiará a través del proceso de migración.

WARNING

A veces se muestra una advertencia indicando que la desactivación de SecureMode no ha sido detectada. En ese caso, reinicie el servidor web. Esto obligará al servidor web a leer la configuración actual.

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

INFO

Si OTOBO se ejecuta en un contenedor Docker, mantenga los valores predeterminados localhost para el servidor OTRS y /opt/otobo/var/tmp/copied_otrs para el directorio home de OTRS. Este es el camino de los datos copiados en el paso opcional.

INFO

Los valores predeterminados para el usuario y contraseña de la base de datos OTRS se toman de Kernel/Config.pm en el directorio home de OTRS. Cambie la configuración sugerida si utiliza un usuario de base de datos dedicado para la migración. También cambie la configuración si trabaja con una base de datos copiada al contenedor Docker otobo_db_1.

INFO

En el caso de Docker, una base de datos que se ejecuta en el host Docker no es accesible desde 127.0.0.1 dentro del contenedor Docker. Esto significa que la configuración 127.0.0.1 no será válida para el campo de entrada Servidor OTRS. En ese caso, introduzca una de las direcciones IP alternativas informadas por el comando hostname --all-ip-addresses para Servidor OTRS.

INFO

Al migrar a un nuevo servidor de aplicaciones o a una instalación basada en Docker, a menudo la base de datos no puede ser accesible desde la instalación destino. Esto generalmente se debe a que el usuario de base de datos otobo solo puede conectarse desde el host donde se ejecuta la base de datos. Para permitir el acceso de todos modos, se recomienda crear un usuario de base de datos dedicado para la migración, por ejemplo: CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; y GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Este usuario puede eliminarse después de la migración: DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

La configuración específica del usuario en Kernel/Config.pm se transferirá desde la antigua instalación OTRS a la nueva instalación OTOBO. Si tiene configuraciones específicas del usuario, revise el archivo migrado /opt/otobo/Kernel/Config.pm. Es posible que desee ajustar rutas personalizadas o configuraciones LDAP. En el mejor de los casos, descubrirá que algunas configuraciones personalizadas ya no son necesarias.

Cuando la migración haya finalizado, tómese su tiempo para probar todo el sistema. Una vez que decida que la migración ha sido exitosa y que desea usar OTOBO a partir de ahora, inicie el daemon de OTOBO:

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

En el caso de Docker:

cd ~/otobo-docker
docker-compose start daemon

Paso 6: Limpieza

1. Desinstale sshpass si ya no lo necesita.

2. Elimine las bases de datos y usuarios de base de datos creados específicamente para la migración, si existen.

3. ¡Disfrute de OTOBO!

Problemas conocidos de migración

No es posible iniciar sesión tras la migración

Durante nuestras pruebas de migración, el navegador utilizado para la migración a veces tenía problemas. Tras reiniciar el navegador, este problema normalmente se resolvía. En Safari, a veces era necesario eliminar manualmente la sesión antigua de OTRS.

La página final de la migración tiene un diseño extraño

Esto puede ocurrir si la configuración ScriptAlias tiene un valor no estándar. La migración simplemente reemplaza otrs por otobo. Esto puede hacer que los archivos CSS y JavaScript en OTOBO ya no puedan cargarse. Si este es el caso, revise la configuración en Kernel/Config.pm y cámbiela a valores razonables.

La migración se detiene por errores de MySQL

En sistemas que han tenido problemas previos durante una actualización, el proceso de migración puede detenerse debido a errores de MySQL en las tablas ticket y ticket_history. Normalmente se trata de valores NULL en la tabla de origen que ya no son permitidos en la tabla de destino. Estos conflictos deben resolverse manualmente antes de poder continuar con la migración.

A partir de OTOBO 10.0.12, existe una comprobación en migration.pl que verifica valores NULL antes de la transferencia de datos. Tenga en cuenta que la solución aún debe realizarse manualmente.

Errores en el paso 5 al migrar a PostgreSQL

En estos casos, migration.pl muestra el mensaje poco útil "El sistema no pudo completar la transferencia de datos". El archivo de registro de Apache y el archivo de registro de OTOBO muestran un mensaje más claro: "Mensaje de error: ERROR: permission denied to set parameter "session_replication_role", SQL: 'set session_replication_role to replica;'". Para otorgar al usuario de base de datos otobo los privilegios de superusuario necesarios, ejecute el siguiente comando como administrador de PostgreSQL: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Luego intente ejecutar nuevamente http://localhost/otobo/migration.pl. Tras la migración, vuelva al estado normal ejecutando ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Aún no está claro si los privilegios extendidos deben otorgarse en cada configuración.

TIP

La discusión en Foro OTOBO

Problemas con la implementación de la configuración del sistema fusionada

La configuración del sistema se migra después de que las tablas de la base de datos hayan sido migradas. En este contexto, migración significa que los valores predeterminados de OTOBO se fusionan con la configuración del sistema del sistema OTRS de origen. En este paso pueden surgir inconsistencias. Un ejemplo práctico es la configuración Ticket::Frontend::AgentTicketQuickClose###State. Esta configuración es nueva en OTOBO 10 y el valor predeterminado es el estado closed successful. Pero esta configuración es inválida si el estado closed successful ha sido eliminado o renombrado en el sistema de origen. Esta inconsistencia se detecta como un error en el paso de migración Migrar configuraciones. La configuración del sistema fusionada se almacena realmente en la base de datos, pero se realizan comprobaciones de validez adicionales durante la implementación.

El problema debe resolverse manualmente mediante comandos de consola de OTOBO.

• Liste las inconsistencias con el comando bin/otobo.Console.pl Admin::Config::ListInvalid.

• Corrija los valores inválidos interactivamente con bin/otobo.Console.pl Admin::Config::FixInvalid.

• Implemente los cambios recopilados por migration.pl, incluyendo el SecureMode desactivado, con bin/otobo.Console.pl Maint::Config::Rebuild.

Después de estos pasos manuales, debería poder ejecutar migration.pl nuevamente. La migración continuará desde el paso donde ocurrió el error.

Tareas manuales finales

Reglas de política de contraseñas

Con OTOBO 10 entra en vigor una nueva política de contraseñas predeterminada para agentes y usuarios clientes cuando se utiliza la autenticación local. Las reglas de política de contraseñas pueden modificarse en la configuración del sistema (PreferencesGroups###Password y CustomerPersonalPreference###Password).

| Regla de política de contraseñas | Predeterminado |

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

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Sí |

| PasswordNeedDigit | Sí |

| PasswordHistory | 10 |

| PasswordTTL | 30 días |

| PasswordWarnBeforeExpiry | 5 días |

| PasswordChangeAfterFirstLogin | Sí |

Bajo Docker: migrar manualmente trabajos cron

En una instalación de OTOBO no basada en Docker, existe al menos un trabajo cron que verifica la salud del daemon. Bajo Docker este trabajo cron ya no existe. Además, ningún daemon cron se ejecuta dentro de los contenedores Docker. Esto significa que debe buscar una solución personalizada para sistemas OTRS con trabajos cron específicos del usuario (por ejemplo, copia de seguridad de la base de datos).

Migración de Oracle a Oracle

Para la migración a Oracle debe aplicarse la estrategia similar a ETL. Esto se debe a que Oracle no ofrece una forma sencilla de desactivar temporalmente la verificación de claves externas.

En el host OTOBO debe instalarse un cliente Oracle y el módulo Perl DBD::Oracle.

INFO

Al usar el cliente Oracle Instant, también se requiere el SDK opcional para la instalación de DBD::Oracle.

Existen muchas formas de clonar un esquema. En los comandos de ejemplo usamos expdp y impdp, que utilizan Data Pump en segundo plano.

INFO

Las cadenas de conexión mostradas en esta documentación se refieren al caso en que tanto la base de datos de origen como la de destino se ejecutan en un contenedor Docker. Vea también https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Limpieza de otobo

Detenga el servidor web para otobo, para que la conexión de base de datos para otobo se cierre.

DROP USER otobo CASCADE

2. Exportar todo el esquema 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. Importar el esquema OTRS y renombrarlo a '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. Ajustar el esquema otobo clonado

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # está bien que el comando solo conozca la base de datos otobo, solo la última línea es relevante
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

Para verificar, use select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Reinicie el servidor web para OTOBO

6. Continúe con el paso 5, es decir, ejecute migration.pl.

INFO

Si migra a una versión de OTOBO mayor o igual a 10.1, debe ejecutar el script /opt/otobo/scripts/DBUpdate-to-10.1.pl para crear las tablas nuevas stats_report y data_storage agregadas en la versión 10.1.

Opcional: Migración simplificada de la base de datos (solo para expertos y escenarios especiales)

En la estrategia general de migración, todos los datos en las tablas de la base de datos se copian fila por fila desde la base de datos OTRS a la base de datos OTOBO. Exportar los datos desde la base de datos OTRS e importarlos a la base de datos OTOBO puede ahorrar tiempo y en algunos casos ser más estable.

INFO

Esta variante funciona tanto para instalaciones basadas en Docker como para instalaciones nativas.

INFO

Estas instrucciones asumen que la Edición Comunitaria ((OTRS)) utiliza MySQL como backend.

Primero necesitamos un volcado (dump) de las tablas necesarias de la base de datos OTRS. Luego debemos realizar algunas transformaciones:

• Conversión del conjunto de caracteres a utf8mb4

• Renombrar algunas tablas

• Acortar algunas columnas de tablas

Después de la transformación, podemos sobrescribir las tablas en el esquema OTOBO con los datos transformados de OTRS. Efectivamente, no necesitamos un solo archivo de volcado, sino varios scripts SQL.

Si mysqldump está instalado y es posible la conexión a la base de datos OTRS, puede crear el volcado directamente en el host Docker. Este caso es compatible con el script bin/backup.pl.

WARNING

Esto requiere que una instalación de OTOBO esté disponible en el host 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

Alternativamente, la base de datos puede respaldarse en otro servidor y luego transferirse al host Docker. Una forma sencilla de hacerlo es copiar /opt/otobo al servidor donde se ejecuta OTRS y ejecutar el mismo comando que arriba.

El script bin/backup.pl genera cuatro scripts SQL en un directorio de volcado, por ejemplo, en 2021-04-13_12-13-04. Para ejecutar los scripts SQL, debemos ejecutar el comando mysql.

Instalación nativa:

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

Instalación basada en Docker:

Ejecute el comando mysql dentro del contenedor Docker db para importar los archivos de volcado de la base de datos. Tenga en cuenta que la contraseña para el usuario root de la base de datos ahora es la contraseña establecida en el archivo .env del host 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

Para una verificación rápida de si la importación funcionó, puede ejecutar los siguientes comandos.

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'

o al ejecutar bajo 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 datos ya está migrada. Esto significa que en el siguiente paso podemos omitir la migración de la base de datos. Asegúrese de marcar la casilla correspondiente.