Migración de ((OTRS)) Community Edition a OTOBO

¡Bienvenido y gracias por elegir OTOBO! OTRS, ((OTRS)) Community Edition y OTOBO son muy completos y flexibles en su aplicación. Por lo tanto, cualquier migración a OTOBO requiere una preparación exhaustiva y, posiblemente, algo de trabajo posterior.

Por favor, tómese su tiempo para la migración y siga estas instrucciones paso a paso.

::: info

Después de la migración, los datos previamente disponibles en ((OTRS)) Community Edition 6 estarán disponibles en OTOBO 10. No modificamos ningún dato de la instalación de OTRS 6 durante la migración.

:::

Resumen de la migración de OTOBO

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

La estrategia de migración general.

Esta es la forma habitual de realizar una migración. Se admiten muchas combinaciones diferentes:
- Cambio de servidor: Migrar y cambiar a un nuevo servidor de aplicaciones al mismo tiempo.
- Servidores de aplicaciones y web separados: Usted tiene la opción de elegir si desea ejecutar los servidores de aplicaciones y de base de datos en el mismo host o en un host dedicado para cada uno. Esta elección es independiente de la configuración anterior en OTRS / ((OTRS)) Community Edition.
- Diferentes bases de datos: Migrar de cualquier base de datos compatible a otra base de datos compatible.
- Diferentes sistemas operativos: Cambiar de cualquier sistema operativo compatible a otro sistema operativo compatible.
- Docker: Migrar a una instalación de OTOBO 10 basada en Docker.
Una variante de la estrategia general en la que se optimiza la migración de la base de datos.

Utilice la migración tipo ETL si la base de datos de origen no debe verse afectada por una carga mayor 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 de la base de datos otrs y luego se insertan en la base de datos de OTOBO. En esta variante, las tablas completas de la base de datos otrs se exportan primero, luego se transforman y finalmente se importan a la base de datos otobo.

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

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

::: warning

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

:::

::: info

También es factible clonar la base de datos de ((OTRS)) Community Edition en el servidor de base de datos de OTOBO antes de la migración real. Esto puede acelerar la estrategia de migración general.

:::

Requisitos de migración

El requisito básico para una migración es que ya tenga una ((OTRS)) Community Edition o OTRS 6.0.* en ejecución y desee transferir tanto la configuración como los datos a OTOBO.

::: warning

Por favor, considere cuidadosamente si realmente necesita los datos y la configuración. La experiencia demuestra que, en muchos casos, empezar de cero es la mejor opción. Esto se debe a que la instalación y la configuración utilizadas anteriormente a menudo eran subóptimas. También podría ser útil transferir solo los datos de los tickets y cambiar la configuración básica a las mejores prácticas de OTOBO.

:::
¡Necesita una instalación de OTOBO en ejecución para iniciar la migración desde allí!
Esta instalación de OTOBO debe contener todos los paquetes OPM que están instalados en su ((OTRS)) Community Edition y que también desea utilizar en OTOBO.
Si planea migrar a otro servidor, el servidor web de OTOBO debe poder acceder a la ubicación donde está instalada su ((OTRS)) Community Edition o OTRS 6.0.. En la mayoría de los casos, se trata del directorio _/opt/otrs en el servidor donde se ejecuta ((OTRS)) Community Edition. El acceso de lectura puede realizarse a través de SSH o mediante montajes del sistema de archivos.
La base de datos de ((otrs)) Community Edition debe ser accesible desde el servidor donde se ejecuta OTOBO. Se debe conceder acceso de solo lectura para hosts externos. Si el acceso no es posible o si se desea optimizar la velocidad de la migración, un volcado (dump) de la base de datos es suficiente.

::: info

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

:::

Guía paso a paso

Paso 1: Instalación de OTOBO

Por favor, comience con la instalación de un nuevo sistema OTOBO. Su antigua instalación de OTRS / ((OTRS)) Community Edition se migrará a este nuevo sistema.

::: warning

En Apache, existen dificultades al ejecutar dos aplicaciones mod_perl independientes en el mismo servidor web. Por lo tanto, se recomienda ejecutar ((OTRS)) Community Edition y OTOBO en servidores web separados. Alternativamente, la configuración de OTRS debe eliminarse 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 activadas.

:::

Una vez finalizada la instalación, inicie sesión como root@localhost. Navegue 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 ((OTRS)) Community Edition NO deben instalarse, ya que estas funciones ya están incluidas en el estándar de 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

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

Paso 2: Desactivar SecureMode

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

::: info

No olvide implementar realmente la configuración modificada.

:::

Paso 3: Detener el demonio de OTOBO

Esto es necesario si el demonio de OTOBO está realmente en ejecución. Detener el demonio es diferente entre las instalaciones basadas en Docker y las que no lo son.

En el caso de no 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, solo necesita 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 el código 0

:::: info

Se recomienda realizar un backup de todo el sistema OTOBO en este punto. Si algo sale mal durante la migración, no tendrá que repetir todo el proceso de instalación, sino que podrá importar el backup para una nueva migración.

::: tip

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

:::

::: details Opcional: montar /opt/otrs

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

Opcional: sshpass y rsync

Este paso solo es necesario si desea migrar ((OTRS)) Community Edition desde otro servidor y /opt/otrs no se ha montado desde el servidor remoto en el servidor OTOBO.

Se necesitan las herramientas sshpass y rsync 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:

::: details Instalar sshpass en Debian / Ubuntu Linux

sudo apt install sshpass

:::

::: details Instalar sshpass en RHEL/CentOS Linux

sudo yum install sshpass

:::

::: details Instalar sshpass en Fedora Linux

sudo dnf install sshpass

:::

::: details Instalar sshpass en OpenSUSE Linux

sudo zypper install sshpass

:::

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

Paso 4: Preparación

::: info

Asegúrese de tener también un backup válido de su sistema OTRS / ((OTRS)) Community Edition. Sí, no tocamos ningún dato de ((OTRS)) Community Edition durante la migración, pero a veces una entrada incorrecta es suficiente para causar problemas. :::

Ahora estamos listos para la migración. Primero, debemos asegurarnos de que no se procesen más tickets y que ningún usuario inicie sesión en ((OTRS)) Community Edition:

Por favor, inicie sesión en el área de administración de ((OTRS)) Community Edition Admin -> Mantenimiento del sistema y agregue una nueva ranura de mantenimiento del sistema durante algunas horas. Después, elimine todas las sesiones de agentes y usuarios (Admin -> Sesiones) y cierre la sesión.

Detener todos los servicios relevantes y el demonio de OTRS

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

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

Eliminar la caché y los datos operativos

Los datos en caché y los datos operativos no necesitan ser migrados. La cola de correo electrónico ya 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

Hay algunas particularidades a tener en cuenta si su instalación de OTOBO se ejecuta bajo Docker. Lo más relevante: los procesos que se ejecutan en un contenedor Docker generalmente no pueden acceder a directorios fuera del contenedor. Sin embargo, hay una excepción: los directorios que se montan como volúmenes en el contenedor pueden ser accedidos. 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 accesible directamente desde fuera de la red del contenedor.

::: info

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

:::

Copie /opt/otrs en el volumen otobo_opt_otobo

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

:::

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

Hay al menos dos formas viables:

a. Copie /opt/otrs en el volumen existente otobo_opt_otobo

b. Monte /opt/otrs como un volumen adicional

Centrémonos aquí en la opción a..

Primero, debemos averiguar 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 una copia segura, utilizamos rsync. Dependiendo de su configuración de Docker, es posible que el comando rsync deba 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 verificar
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 verificar

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 utilizaba el comando docker-compose. En versiones más recientes se utiliza docker compose. :::

Por favor, utilice la herramienta de migración web en http://localhost/otobo/migration.pl. Tenga en cuenta que es posible que deba reemplazar “localhost” por su nombre de host de OTOBO y posiblemente agregar su puerto no estándar. La aplicación le guiará a través del proceso de migración.

::: warning

A veces aparece una advertencia de que no se detectó la desactivación del SecureMode. En este caso, reinicie el servidor web. Esto obliga 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 la configuración predeterminada localhost para el servidor OTRS y /opt/otobo/var/tmp/copied_otrs para el directorio de inicio de OTRS. Esta es la ruta de los datos que se copiaron en el paso opcional.

:::

::: info

Los valores predeterminados para el usuario y la contraseña de la base de datos OTRS se toman de Kernel/Config.pm en el directorio de inicio de OTRS. Cambie la configuración propuesta si utiliza un usuario de base de datos dedicado para la migración. Cambie también la configuración si trabaja con una base de datos que se copió en el 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 a través de 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 OTRS-Server. En este caso, introduzca una de las direcciones IP alternativas reportadas por el comando hostname --all-ip-addresses para OTRS-Server.

:::

::: info

Al migrar a un nuevo servidor de aplicaciones o a una instalación basada en Docker, a menudo no se puede acceder a la base de datos desde la instalación de destino. Esto se debe normalmente a que el usuario de la 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, p. ej. 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 transfiere de la antigua instalación de OTRS a la nueva instalación de OTOBO. Si tiene configuraciones específicas del usuario, debería echar un vistazo al archivo migrado /opt/otobo/Kernel/Config.pm. Es posible que desee ajustar rutas personalizadas o configuraciones LDAP. En el mejor de los casos, notará que algunas configuraciones personalizadas ya no son necesarias.

Cuando la migración haya finalizado, tómese su tiempo y pruebe todo el sistema. Una vez que haya decidido que la migración fue exitosa y desea utilizar OTOBO a partir de ahora, inicie el demonio 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

Desinstale sshpass si ya no lo necesita.
Elimine las bases de datos y los usuarios de base de datos creados específicamente para la migración, si existen.
¡Disfrute de OTOBO!

Problemas de migración conocidos

No es posible iniciar sesión después de la migración

Durante nuestras pruebas de migración, el navegador utilizado para la migración a veces tuvo problemas. Después de reiniciar el navegador, este problema generalmente se resolvió. En Safari, a veces fue necesario eliminar manualmente la antigua sesión de OTRS.

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

Esto puede suceder 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 se puedan recuperar. Si este es el caso, verifique la configuración en Kernel/Config.pm y cámbiela de nuevo a valores razonables.

La migración se detiene debido a errores de MySQL

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

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

Error 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 significativo: “Mensaje de error: ERROR: permission denied to set parameter “session_replication_role”, SQL: ‘set session_replication_role to replica;’” Para otorgar al usuario de la 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 http://localhost/otobo/migration.pl nuevamente. Después de 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 el foro de OTOBO

:::

Problemas con el despliegue de la configuración del sistema fusionada

La configuración del sistema se migra después de que se migran las tablas de la base de datos. En este contexto, migración significa que la configuración predeterminada de OTOBO se fusiona con la configuración del sistema del sistema OTRS de origen. En este paso pueden ocurrir 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 no es válida si el estado closed successful se eliminó o cambió de nombre en el sistema de origen. Esta inconsistencia se detecta como un error en el paso de migración Migrate configuration settings. La configuración del sistema fusionada se guarda realmente en la base de datos, pero se realizan comprobaciones de validez adicionales durante el despliegue.

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

Enumere las inconsistencias con el comando bin/otobo.Console.pl Admin::Config::ListInvalid.
Corrija los valores no válidos de forma interactiva con bin/otobo.Console.pl Admin::Config::FixInvalid.
Despliegue los cambios recopilados de migration.pl, incluido 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 en el que ocurrió el error.

Tareas manuales finales

Reglas de políticas 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íticas de contraseñas se pueden cambiar 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 que no está basada en Docker, hay al menos un trabajo cron que verifica la salud del demonio. Bajo Docker, este trabajo cron ya no existe. Además, no se ejecuta ningún demonio cron en ninguno de los contenedores Docker. Esto significa que debe buscar una solución individual para los sistemas OTRS con trabajos cron específicos del usuario (p. ej., backup de la base de datos).

Migración de Oracle a Oracle

Para la migración a Oracle, se debe aplicar la estrategia tipo ETL. Esto se debe a que Oracle no ofrece una forma sencilla de desactivar temporalmente la comprobación de claves foráneas.

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

::: info

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

:::

Hay muchas formas de clonar un esquema. En los comandos de ejemplo, utilizamos expdp e impdp, que utilizan Data Pump bajo el capó.

::: 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. Véase también https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

:::

Limpieza de otobo

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

DROP USER otobo CASCADE

Exportación de 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

Importar el esquema OTRS y renombrar el esquema 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;

Ajustar el esquema clonado otobo

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # está bien que el comando solo sepa sobre 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 controlar con `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

Reinicie el servidor web para OTOBO
Continúe con el paso 5, es decir, ejecute migration.pl.

::: info

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

:::

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

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

::: info

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

:::

::: info

Estas instrucciones asumen que ((OTRS)) Community Edition utiliza MySQL como backend.

:::

En primer lugar, necesitamos un volcado de las tablas de la base de datos OTRS necesarias. Luego debemos realizar algunas transformaciones:

Conversión del conjunto de caracteres a utf8mb4
Cambio de nombre de algunas tablas
Recorte de algunas columnas de tabla

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 una conexión a la base de datos OTRS, puede crear el volcado de la base de datos 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 se puede respaldar 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, p. ej. 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 root de la base de datos es ahora la contraseña que se estableció en el archivo .env en el 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 ahora está migrada. Esto significa que en el siguiente paso podemos omitir la migración de la base de datos. Preste atención a la casilla de verificación correspondiente.