description: > Migración sin problemas de OTRS Community Edition a OTOBO. Migre datos de forma segura y eficiente y aproveche las ventajas de OTOBO 11.

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 uso. Por lo tanto, cada 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 disponibles anteriormente 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:

1. 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: Tiene la opción de ejecutar los servidores de aplicaciones y bases de datos en el mismo host o en hosts dedicados cada uno. Esta elección es independiente de la configuración previa 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.

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

Utilice la migración similar a ETL si la base de datos de origen no debe verse afectada por una carga elevada 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 OTOBO. En esta variante, todas las tablas 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 de 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 está soportado por 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. Pero 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 al 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

1. El requisito previo para una migración es que ya tenga una ((OTRS)) Community Edition u OTRS 6.0.* en funcionamiento 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 un nuevo comienzo es la mejor opción. Esto se debe a que la instalación y configuración utilizadas anteriormente a menudo eran subóptimas. También podría tener sentido transferir solo los datos de tickets y cambiar la configuración básica a las mejores prácticas de OTOBO.

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

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

4. 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 u OTRS 6.0._. En la mayoría de los casos, este es el directorio _/opt/otrs* en el servidor donde se ejecuta ((OTRS)) Community Edition. El acceso de lectura se puede realizar a través de SSH o a través de montajes del sistema de archivos.

5. 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, entonces un volcado de la base de datos es suficiente.

INFO

Si el acceso SSH y a la base de datos no es posible entre los servidores, 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

Con 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 revise 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. Navegue al área de administración de OTOBO Admin -> Paquetes e instale todos los paquetes OTOBO OPM requeridos.

Los siguientes paquetes OPM y "Feature Addons" de ((OTRS)) Community Edition NO NECESITAN y NO DEBEN instalarse, ya que estas funcionalidades 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 Admin -> System Configuration y desactive la opción de configuración SecureMode.

INFO

No olvide implementar el ajuste modificado.

Paso 3: Detener el Daemon de OTOBO

Esto es necesario si el daemon de OTOBO se está ejecutando. Detener el daemon varía entre las instalaciones basadas en Docker y las no basadas en Docker.

En el caso 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 una copia de seguridad 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 la copia de seguridad para una nueva migración.

TIP

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

Montar opcionalmente /opt/otrs

A menudo, OTOBO se ejecutará en un servidor nuevo donde /opt/otrs no está disponible inicialmente. En estos casos, el directorio /opt/otrs del servidor ((OTRS)) Community Edition se puede montar 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 en el servidor OTOBO desde el servidor remoto.

Las herramientas sshpass y rsync se necesitan para que migration.pl pueda copiar archivos a través de 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 para rsync si aún no está disponible.

Paso 4: Preparación

INFO

Asegúrese de tener también una copia de seguridad válida de su sistema OTRS / ((OTRS)) Community Edition. Sí, no tocamos los datos 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 estén procesando más tickets y que ningún usuario esté iniciando sesión en ((OTRS)) Community Edition:

Por favor, inicie sesión en el área de administración de ((OTRS)) Community Edition Admin -> System Maintenance y agregue una nueva ranura de mantenimiento del sistema para unas horas. Luego, elimine todas las sesiones de agente y usuario (Admin -> Sessions) y cierre la sesión.

Detener todos los servicios relevantes y el daemon de OTRS

Por favor, asegúrese de que no se estén ejecutando servicios ni trabajos cron.

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

Eliminar las cachés y los datos operativos

Los datos cacheados y los datos operativos no necesitan ser migrados. La cola de correo 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 en 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 están montados como volúmenes en el contenedor se pueden acceder. 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 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 contenedor 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. Copiar /opt/otrs al volumen existente otobo_opt_otobo

b. Montar /opt/otrs como un volumen adicional

Nos centraremos aquí en la opción a.

Primero, necesitamos 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, 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 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" con su nombre de host OTOBO y posiblemente agregar su puerto no predeterminado. La aplicación lo guiará a través del proceso de migración.

WARNING

A veces se muestra una advertencia de que la desactivación de SecureMode no se ha detectado. En este 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 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 de OTRS se toman de Kernel/Config.pm en el directorio de inicio de OTRS. Cambie la configuración sugerida si utiliza un usuario de base de datos dedicado para la migración. Cambie también la configuración si está trabajando 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, ingrese una de las direcciones IP alternativas informadas 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 suele deberse 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, 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 se puede eliminar 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á 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, descubrirá 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 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 los usuarios de bases de datos creados específicamente para la migración, si los hay.

3. ¡Disfrute de OTOBO!

Problemas de Migración Conocidos

No se puede 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 sesión antigua 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, revise 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 tuvieron problemas con 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. Generalmente, estos son 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.

A partir de OTOBO 10.0.12, hay una verificación en migration.pl que comprueba 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, el mensaje poco útil "El sistema no pudo completar la transferencia de datos." es mostrado por migration.pl. 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.

Todavía no está claro si los privilegios extendidos deben otorgarse en cada configuración.

TIP

La discusión en Foro 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 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 no es válida si el estado closed successful fue eliminado o renombrado 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 almacena realmente en la base de datos, pero se realizan validaciones adicionales durante el despliegue.

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

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

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

• Despliega los cambios recopilados de migration.pl, incluida la desactivación de SecureMode, 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á con 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 de clientes cuando se utiliza la autenticación local. Las reglas de política 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í |

En Docker: Migrar manualmente trabajos Cron

En una instalación de OTOBO no basada en Docker, hay al menos un trabajo cron que verifica la salud del daemon. En Docker, este trabajo cron ya no existe. Además, ningún daemon Cron se ejecuta en ninguno de los contenedores Docker. Esto significa que deberá buscar una solución individual para los sistemas OTRS con trabajos cron personalizados (por ejemplo, copia de seguridad de la base de datos).

Migración de Oracle a Oracle

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

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

INFO

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

Hay muchas maneras de clonar un esquema. En los comandos de ejemplo, usamos expdp y impdp, que utilizan Data Pump internamente.

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

1. Limpieza de otobo

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

DROP USER otobo CASCADE

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

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

4. Ajuste del esquema clonado otobo

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 con `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 se migra a una versión de OTOBO igual o superior a 10.1, se debe ejecutar el script /opt/otobo/scripts/DBUpdate-to-10.1.pl para crear las nuevas tablas stats_report y data_storage añadidas en la versión 10.1.

Opcional: Migración Simplificada de 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

• Renombrar algunas tablas

• Acortar algunas columnas de tabla

Después de la transformación, podemos sobrescribir las tablas en el esquema de 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 conectarse a la base de datos OTRS, puede crear el volcado de la base de datos directamente en el host Docker. Este caso está soportado por 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, 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 root de la base de datos es ahora la contraseña establecida 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 podemos omitir la migración de la base de datos en el siguiente paso. Preste atención a la casilla de verificación correspondiente.