Migração da Edição Comunitária ((OTRS)) para OTOBO

Bem-vindo e obrigado por escolher OTOBO! OTRS, Edição Comunitária ((OTRS)) e OTOBO são muito abrangentes e flexíveis em seu uso. Portanto, cada migração para OTOBO exige uma preparação cuidadosa e, possivelmente, algum trabalho adicional.

Por favor, reserve um tempo para a migração e siga estas instruções passo a passo.

INFO

Após a migração, os dados anteriormente disponíveis na Edição Comunitária ((OTRS)) 6 estarão disponíveis no OTOBO 10. Nós não alteramos nenhum dado da instalação OTRS 6 durante a migração.

Visão Geral da Migração OTOBO

Com a interface de migração do OTOBO, é possível utilizar as seguintes estratégias de migração:

1. A estratégia geral de migração.

   Este é o caminho regular para realizar uma migração. Muitas combinações diferentes são suportadas:

   • Troca de servidor: Migrar e ao mesmo tempo mudar para um novo servidor de aplicação.

   • Servidores de aplicação e web separados: Você pode escolher se deseja executar os servidores de aplicação e banco de dados no mesmo host ou em hosts dedicados separados. Essa escolha é independente da configuração anterior no OTRS / Edição Comunitária ((OTRS)).

   • Diferentes bancos de dados: Migrar de qualquer banco de dados suportado para outro banco de dados suportado.

   • Diferentes sistemas operacionais: Migrar de qualquer sistema operacional suportado para outro sistema operacional suportado.

   • Docker: Migrar para uma instalação baseada em Docker do OTOBO 10.

2. Uma variante da estratégia geral, na qual a migração do banco de dados é otimizada.

Use a migração semelhante a ETL quando o banco de dados de origem não pode ser sobrecarregado com carga adicional ou quando o acesso ao banco de dados de origem é um gargalo. Na estratégia geral, os dados são lidos linha por linha primeiro do banco de dados otrs e depois inseridos no banco de dados OTOBO. Nesta variante, as tabelas completas do banco de dados otrs são primeiro exportadas, depois transformadas e depois importadas no banco de dados otobo.

3. Migração de uma instalação da Edição Comunitária ((OTRS)) 6 baseada em Oracle para uma instalação do OTOBO baseada em Oracle.

Este é um caso especial não suportado pela estratégia geral de migração. Isso significa que uma variante da estratégia otimizada deve ser usada.

WARNING

Todas as estratégias funcionam tanto para instalações baseadas em Docker quanto para instalações nativas. Porém, para instalações baseadas em Docker, algumas particularidades devem ser consideradas. Essas particularidades são tratadas nos passos opcionais.

INFO

Também é possível clonar o banco de dados da Edição Comunitária ((OTRS)) para o servidor de banco de dados do OTOBO antes da migração real. Isso pode acelerar a estratégia geral de migração.

Requisitos para Migração

1. O pré-requisito básico para uma migração é que você já tenha uma Edição Comunitária ((OTRS)) ou OTRS 6.0.* em execução e deseje transferir tanto a configuração quanto os dados para o OTOBO.

   WARNING

   Por favor, considere cuidadosamente se você realmente precisa dos dados e da configuração. A experiência mostra que, em muitos casos, começar do zero é a melhor opção. Isso ocorre porque a instalação e configuração anteriormente usada muitas vezes era subótima. Também pode fazer sentido transferir apenas os dados dos tickets e reconfigurar a configuração básica de acordo com as melhores práticas do OTOBO.

2. Você precisa ter uma instalação OTOBO em execução para iniciar a migração a partir dela!

3. Esta instalação OTOBO deve conter todos os pacotes OPM que estão instalados na sua Edição Comunitária ((OTRS)) e que você deseja usar também no OTOBO.

4. Se você planeja migrar para outro servidor, o servidor web OTOBO deve ter acesso ao local onde sua Edição Comunitária ((OTRS)) ou OTRS 6.0._ está instalada. Na maioria dos casos, trata-se do diretório _/opt/otrs* no servidor onde a Edição Comunitária ((OTRS)) está em execução. O acesso de leitura pode ser feito via SSH ou montagens de sistema de arquivos.

5. O banco de dados da Edição Comunitária ((otrs)) deve ser acessível a partir do servidor onde o OTOBO está em execução. O acesso somente leitura deve ser concedido para hosts externos. Se o acesso não for possível ou se a velocidade da migração precisar ser otimizada, então um dump do banco de dados é suficiente.

INFO

Se o acesso SSH e ao banco de dados entre os servidores não for possível, migre a Edição Comunitária ((OTRS)) para o OTOBO no mesmo servidor e mova a nova instalação posteriormente.

Instruções Passo a Passo

Passo 1: Instalação do OTOBO

Por favor, comece com a instalação de um novo sistema OTOBO. Sua instalação antiga OTRS / Edição Comunitária ((OTRS)) será migrada para este novo sistema.

WARNING

No Apache, existem armadilhas ao executar duas aplicações mod_perl independentes no mesmo servidor web. Portanto, recomenda-se executar a Edição Comunitária ((OTRS)) e o OTOBO em servidores web separados. Alternativamente, a configuração do OTRS deve ser removida do Apache antes de instalar o OTOBO. Use o comando a2query -s e verifique os diretórios /etc/apache2/sites-available e /etc/apache2/sites-enabled para ver quais configurações estão atualmente disponíveis e ativadas.

Após concluir a instalação, faça login como root@localhost. Navegue até a área de administração do OTOBO Admin -> Pacotes e instale todos os pacotes OPM OTOBO necessários.

Os seguintes pacotes OPM e "Feature Addons" da Edição Comunitária ((OTRS)) NÃO devem e não devem ser instalados, pois essas funcionalidades já estão incluídas no padrão 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

Os seguintes pacotes OTOBO foram integrados ao OTOBO 10+. Isso significa que eles não devem ser instalados no sistema de destino se o sistema de destino for OTOBO 10+:

• ImportExport

Passo 2: Desativar o SecureMode

Após instalar o OTOBO, faça login novamente na área de administração do OTOBOAdmin -> Systemkonfiguration e desative a opção de configuração SecureMode.

INFO

Não se esqueça de realmente implementar a configuração alterada.

Passo 3: Parar o Daemon OTOBO

Isso é necessário se o Daemon OTOBO estiver realmente em execução. A forma de parar o daemon difere entre instalações baseadas em Docker e não baseadas em Docker.

No caso sem Docker, execute os seguintes comandos como usuário otobo:

# se você estiver logado como root

root> su - otobo

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

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

Se o OTOBO estiver rodando no Docker, basta parar o serviço daemon:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 deve ter encerrado com código 0

INFO

Recomenda-se fazer um backup completo do sistema OTOBO neste momento. Se algo der errado durante a migração, você não precisará repetir todo o processo de instalação, mas poderá importar o backup para uma nova tentativa de migração.

TIP

Recomendamos que você leia o capítulo Backup OTOBO backup-restore.

Opcional: Montar /opt/otrs

Muitas vezes, o OTOBO será executado em um novo servidor onde inicialmente /opt/otrs não está disponível. Nestes casos, o diretório /opt/otrs no servidor da Edição Comunitária ((OTRS)) pode ser montado no sistema de arquivos do servidor OTOBO. Se uma montagem de rede regular não for possível, sshfs pode ser uma opção.

Opcional: sshpass e rsync

Este passo é necessário apenas se você deseja migrar a Edição Comunitária ((OTRS)) de outro servidor e /opt/otrs não foi montado no servidor OTOBO a partir do servidor remoto.

As ferramentas sshpass e rsync são necessárias para que o migration.pl possa copiar arquivos via ssh. Para instalar sshpass, faça login como usuário root no servidor e execute um dos seguintes comandos:

Instalar sshpass no Debian / Ubuntu Linux

sudo apt install sshpass

Instalar sshpass no RHEL/CentOS Linux

sudo yum install sshpass

Instalar sshpass no Fedora Linux

sudo dnf install sshpass

Instalar sshpass no OpenSUSE Linux

sudo zypper install sshpass

O mesmo deve ser feito para rsync se ainda não estiver disponível.

Passo 4: Preparação

INFO

Certifique-se de que você também tenha um backup válido do seu sistema OTRS / Edição Comunitária ((OTRS)). Sim, nós não alteramos os dados da Edição Comunitária ((OTRS)) durante a migração, mas às vezes um erro simples pode causar problemas.

Agora estamos prontos para a migração. Primeiro, precisamos garantir que nenhum ticket esteja sendo editado e que nenhum usuário esteja logado na Edição Comunitária ((OTRS)):

Faça login na área de administração da Edição Comunitária ((OTRS)) Admin -> Systemwartung e adicione um novo intervalo de manutenção do sistema por algumas horas. Em seguida, exclua todas as sessões de agentes e usuários (Admin -> Sitzungen) e saia.

Parar todos os serviços relevantes e o daemon OTRS

Certifique-se de que nenhum serviço ou tarefa cron esteja em execução.

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

Limpar caches e dados operacionais

Os dados em cache e os dados operacionais não precisam ser migrados. A fila de e-mails já deveria estar vazia neste 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

Passo Opcional para Docker

Existem algumas particularidades a considerar se sua instalação OTOBO estiver rodando em Docker. A mais importante: processos em execução dentro de um contêiner Docker geralmente não podem acessar diretórios fora do contêiner. No entanto, existe uma exceção: diretórios montados como volumes no contêiner podem ser acessados. Observe também que o banco de dados MariaDB, que roda em otobo_db_1 (otobo-db-1 em versões mais recentes do docker compose), não é diretamente acessível de fora da rede do contêiner.

INFO

Nos comandos de exemplo, assumimos que o usuário docker_admin é usado para interagir com o Docker. O administrador Docker pode ser o usuário root do host Docker ou um usuário dedicado com as permissões necessárias.

Copie /opt/otrs para o volume otobo_opt_otobo

::: note Nomes dos contêineres Em versões antigas do docker compose, os nomes dos contêineres são otobo_web_1, otobo_db_1 e otobo_daemon_1. Em versões mais recentes, os nomes são otobo-web-1, otobo-db-1 e otobo-daemon-1.

:::

Nesta seção, assumimos que o diretório home do OTRS /opt/otrs está disponível no host Docker.

Existem pelo menos duas opções viáveis:

a. Copie /opt/otrs para o volume existente otobo_opt_otobo

b. Monte /opt/otrs como volume adicional

Focaremos aqui na opção a..

Primeiro, precisamos descobrir onde o volume otobo_opt_otobo está disponível no host Docker.

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

Para copiar com segurança, usamos rsync. Dependendo da sua configuração Docker, o comando rsync pode precisar ser executado com 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  # apenas para verificação
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  # apenas para verificação

Este diretório copiado estará disponível dentro do contêiner como /opt/otobo/var/tmp/copied_otrs.

Passo 5: Migrar dados

:::note Comando Docker Compose Em versões antigas do Docker Compose, o comando docker-compose era usado. Em versões mais recentes, usa-se docker compose. :::

Use a ferramenta web de migração em http://localhost/otobo/migration.pl. Observe que você pode precisar substituir "localhost" pelo nome do host OTOBO e talvez adicionar uma porta não padrão. O aplicativo irá guiá-lo pelo processo de migração.

WARNING

Às vezes, um aviso é exibido indicando que a desativação do SecureMode não foi detectada. Nesse caso, reinicie o servidor web. Isso força o servidor web a recarregar a configuração atual.

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

INFO

Se o OTOBO estiver rodando em um contêiner Docker, mantenha os valores padrão localhost para o servidor OTRS e /opt/otobo/var/tmp/copied_otrs para o diretório home do OTRS. Este é o caminho dos dados copiados no passo opcional.

INFO

Os valores padrão para usuário e senha do banco de dados OTRS são obtidos de Kernel/Config.pm no diretório home do OTRS. Altere as configurações sugeridas se estiver usando um usuário de banco de dados dedicado para a migração. Altere também as configurações se estiver trabalhando com um banco de dados copiado para o contêiner Docker otobo_db_1.

INFO

No caso Docker, um banco de dados que roda no host Docker não é acessível via 127.0.0.1 dentro do contêiner Docker. Isso significa que a configuração 127.0.0.1 não será válida para o campo de entrada Servidor OTRS. Nesse caso, insira um dos endereços IP alternativos relatados pelo comando hostname --all-ip-addresses para Servidor OTRS.

INFO

Ao migrar para um novo servidor de aplicação ou para uma instalação baseada em Docker, o banco de dados geralmente não pode ser acessado a partir da instalação de destino. Isso geralmente ocorre porque o usuário do banco de dados otobo só pode se conectar do host onde o banco de dados está rodando. Para permitir o acesso, recomenda-se criar um usuário de banco de dados dedicado para a migração, por exemplo, CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; e GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Este usuário pode ser excluído após a migração: DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

Configurações específicas do usuário em Kernel/Config.pm são transferidas da antiga instalação OTRS para a nova instalação OTOBO. Se você tiver configurações específicas do usuário, dê uma olhada no arquivo migrado /opt/otobo/Kernel/Config.pm. Você pode querer ajustar caminhos personalizados ou configurações LDAP. Na melhor das hipóteses, você descobrirá que algumas configurações personalizadas não são mais necessárias.

Quando a migração estiver concluída, reserve um tempo para testar todo o sistema. Assim que decidir que a migração foi bem-sucedida e que deseja usar o OTOBO a partir de agora, inicie o daemon OTOBO:

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

No caso Docker:

cd ~/otobo-docker
docker-compose start daemon

Passo 6: Limpeza

1. Desinstale sshpass se não for mais necessário.

2. Exclua os bancos de dados e usuários do banco de dados criados especificamente para a migração, se existirem.

3. Divirta-se com o OTOBO!

Problemas Conhecidos de Migração

Não é possível fazer login após a migração

Durante nossos testes de migração, o navegador usado para a migração às vezes apresentava problemas. Após reiniciar o navegador, o problema geralmente era resolvido. No Safari, às vezes era necessário excluir manualmente a sessão antiga do OTRS.

A página final da migração tem um layout estranho

Isso pode acontecer se a configuração ScriptAlias tiver um valor não padrão. A migração simplesmente substitui ots por otobo. Isso pode fazer com que os arquivos CSS e JavaScript no OTOBO não possam mais ser recuperados. Se este for o caso, verifique as configurações em Kernel/Config.pm e altere-as de volta para valores razoáveis.

A migração para com erros do MySQL

Em sistemas que tiveram problemas com atualizações no passado, o processo de migração pode parar devido a erros do MySQL nas tabelas ticket e ticket_history. Geralmente, trata-se de valores NULL na tabela de origem que não são mais permitidos na tabela de destino. Esses conflitos devem ser resolvidos manualmente antes de continuar a migração.

A partir do OTOBO 10.0.12, existe uma verificação em migration.pl que verifica valores NULL antes da transferência de dados. Observe que a solução ainda precisa ser feita manualmente.

Erros na Etapa 5 ao migrar para PostgreSQL

Nesses casos, a mensagem pouco útil "O sistema não conseguiu concluir a transferência de dados." é exibida pelo migration.pl. O arquivo de log do Apache e o arquivo de log do OTOBO mostram uma mensagem mais informativa: " Mensagem de erro: ERRO: permissão negada para definir o parâmetro 'session_replication_role', SQL: 'set session_replication_role to replica;'". Para conceder ao usuário do banco de dados otobo os privilégios de superusuário necessários, execute o seguinte comando como administrador PostgreSQL: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Em seguida, tente executar novamente http://localhost/otobo/migration.pl. Após a migração, retorne ao estado normal executando ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Ainda não está claro se os privilégios estendidos precisam ser concedidos em todas as configurações.

TIP

A discussão no Fórum OTOBO

Problemas com a implantação da configuração do sistema mesclada

A configuração do sistema é migrada após as tabelas do banco de dados serem migradas. Neste contexto, migração significa que as configurações padrão do OTOBO são mescladas com a configuração do sistema do sistema OTRS de origem. Neste passo, podem ocorrer inconsistências. Um exemplo prático é a configuração Ticket::Frontend::AgentTicketQuickClose###State. Esta configuração é nova no OTOBO 10 e o valor padrão é o status closed successful. Mas esta configuração é inválida se o status closed successful tiver sido excluído ou renomeado no sistema de origem. Essa inconsistência é detectada como um erro na etapa de migração Migrar configurações. A configuração do sistema mesclada é realmente armazenada no banco de dados, mas verificações de validade adicionais são realizadas durante a implantação.

O problema deve ser corrigido manualmente com comandos da linha de comando do OTOBO.

• Liste as inconsistências com o comando bin/otobo.Console.pl Admin::Config::ListInvalid.

• Corrija os valores inválidos interativamente com bin/otobo.Console.pl Admin::Config::FixInvalid.

• Implante as alterações coletadas do migration.pl, incluindo o SecureMode desativado, com bin/otobo.Console.pl Maint::Config::Rebuild.

Após essas etapas manuais, você deverá ser capaz de executar migration.pl novamente. A migração continuará no passo onde o erro ocorreu.

Tarefas Manuais Finais

Regras de Política de Senha

Com o OTOBO 10, uma nova política de senha padrão entra em vigor para agentes e usuários clientes quando a autenticação local é usada. As regras da política de senha podem ser alteradas na configuração do sistema (PreferencesGroups###Password e CustomerPersonalPreference###Password).

| Regra de política de senha | Padrão |

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

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Sim |

| PasswordNeedDigit | Sim |

| PasswordHistory | 10 |

| PasswordTTL | 30 dias |

| PasswordWarnBeforeExpiry | 5 dias |

| PasswordChangeAfterFirstLogin | Sim |

Sob Docker: Migrar manualmente tarefas cron

Em uma instalação OTOBO não baseada em Docker, existe pelo menos uma tarefa cron que verifica a saúde do daemon. Sob Docker, essa tarefa cron não existe mais. Além disso, nenhum daemon cron roda em nenhum dos contêineres Docker. Isso significa que você precisará encontrar uma solução personalizada para sistemas OTRS com tarefas cron específicas do usuário (por exemplo, backup do banco de dados).

Migração de Oracle para Oracle

Para a migração para Oracle, a estratégia semelhante a ETL deve ser aplicada. Isso ocorre porque o Oracle não oferece uma maneira simples de desativar temporariamente a verificação de chaves estrangeiras.

No host OTOBO, um cliente Oracle e o módulo Perl DBD::Oracle devem estar instalados.

INFO

Ao usar o Oracle Instant Client, o SDK opcional também é necessário para a instalação do DBD::Oracle.

Existem muitas maneiras de clonar um esquema. Nos comandos de exemplo, usamos expdp e impdp, que utilizam o Data Pump internamente.

INFO

As strings de conexão mostradas nesta documentação referem-se ao caso em que tanto o banco de dados de origem quanto o de destino estão rodando em um contêiner Docker. Veja também https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Limpeza do otobo

Pare o servidor web para otobo, para que a conexão com o banco de dados para otobo seja fechada.

DROP USER otobo CASCADE

2. Exportar todo o 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 o esquema OTRS e renomear o esquema para '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 o esquema otobo clonado

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # está tudo bem se o comando souber apenas do banco de dados otobo, apenas a última linha é 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 verificação com `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Reinicie o servidor web para OTOBO

6. Prossiga para o passo 5, ou seja, execute migration.pl.

INFO

Se estiver migrando para uma versão OTOBO maior ou igual a 10.1, o script /opt/otobo/scripts/DBUpdate-to-10.1.pl deve ser executado para criar as tabelas recém-adicionadas na versão 10.1 stats_report e data_storage.

Opcional: Migração simplificada do banco de dados (apenas para especialistas e cenários especiais)

Na estratégia geral de migração, todos os dados nas tabelas do banco de dados são copiados linha por linha do banco de dados OTRS para o banco de dados OTOBO. Exportar os dados do banco de dados OTRS e importá-los no banco de dados OTOBO pode economizar tempo e, em alguns casos, ser mais estável.

INFO

Esta variante funciona tanto para instalações baseadas em Docker quanto para instalações nativas.

INFO

Estas instruções assumem que a Edição Comunitária ((OTRS)) usa MySQL como backend.

Primeiro, precisamos de um dump das tabelas do banco de dados OTRS necessárias. Em seguida, precisamos realizar algumas transformações:

• Conversão do conjunto de caracteres para utf8mb4

• Renomeação de algumas tabelas

• Encurtamento de algumas colunas de tabelas

Após a transformação, podemos sobrescrever as tabelas no esquema OTOBO com os dados transformados do OTRS. Efetivamente, não precisamos de um único arquivo de dump, mas de vários scripts SQL.

Se mysqldump estiver instalado e uma conexão com o banco de dados OTRS for possível, você pode criar o dump do banco de dados diretamente no host Docker. Este caso é suportado pelo script bin/backup.pl.

WARNING

Isso exige que uma instalação OTOBO esteja disponível no 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, o banco de dados pode ser salvo em outro servidor e depois transferido para o host Docker. Uma maneira simples de fazer isso é copiar /opt/otobo para o servidor onde o OTRS está rodando e executar o mesmo comando acima.

O script bin/backup.pl gera quatro scripts SQL em um diretório de dump, por exemplo, 2021-04-13_12-13-04. Para executar os scripts SQL, precisamos executar o comando mysql.

Instalação 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

Instalação baseada em Docker:

Execute o comando mysql dentro do contêiner Docker db para importar os arquivos de dump do banco de dados. Observe que a senha do root do banco de dados agora é a senha definida no arquivo .env no 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 uma verificação rápida se a importação funcionou, você pode executar os seguintes 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'

ou ao executar sob 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'

O banco de dados agora está migrado. Isso significa que no próximo passo podemos pular a migração do banco de dados. Observe a caixa de seleção correspondente.