Migração da ((OTRS)) Community Edition para OTOBO

Bem-vindo e obrigado por escolher o OTOBO! OTRS, ((OTRS)) Community Edition e OTOBO são muito abrangentes e flexíveis em seu uso. Portanto, cada migração para OTOBO requer preparação completa e, possivelmente, algum trabalho de ajuste.

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 ((OTRS)) Community Edition 6 estarão disponíveis no OTOBO 10. 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 usar 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:

   • Mudança de Servidor: Migre e mude para um novo servidor de aplicação ao mesmo tempo.

   • Servidores de Aplicação e Web Separados: Você tem a opção de executar servidores de aplicação e banco de dados no mesmo host ou em hosts dedicados cada um. Esta escolha é independente da configuração anterior no OTRS / ((OTRS)) Community Edition.

   • Bancos de Dados Diferentes: Migre de qualquer banco de dados suportado para outro banco de dados suportado.

   • Sistemas Operacionais Diferentes: Mude de qualquer sistema operacional suportado para outro sistema operacional suportado.

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

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

Use a migração semelhante a ETL se o banco de dados de origem não puder ser sobrecarregado com carga aumentada ou se o acesso ao banco de dados de origem for um gargalo. Na estratégia geral, os dados são lidos linha por linha da 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 para o banco de dados otobo.

3. Migração de uma instalação ((OTRS)) Community Edition 6 baseada em Oracle para uma instalação OTOBO baseada em Oracle.

Este é um caso especial que 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. Mas para instalações baseadas em Docker, algumas particularidades devem ser levadas em consideração. Essas particularidades são abordadas nas etapas opcionais.

INFO

Também é viável clonar o banco de dados ((OTRS)) Community Edition para o servidor de banco de dados OTOBO antes da migração real. Isso pode acelerar a estratégia geral de migração.

Requisitos de Migração

1. Um pré-requisito básico para uma migração é que você já tenha uma ((OTRS)) Community Edition ou OTRS 6.0.* em execução e queira transferir configuração e dados para o OTOBO.

   WARNING

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

2. Você precisa de 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 em sua ((OTRS)) Community Edition e que você também deseja usar no OTOBO.

4. Se você planeja migrar para um servidor diferente, o servidor web OTOBO deve ser capaz de acessar o local onde sua ((OTRS)) Community Edition ou OTRS 6.0.* está instalado. Na maioria dos casos, este é o diretório _/opt/otrs* no servidor onde a ((OTRS)) Community Edition está em execução. O acesso de leitura pode ser feito via SSH ou via montagens de sistema de arquivos.

5. O banco de dados ((otrs)) Community Edition 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, um dump do banco de dados será suficiente.

INFO

Caso o acesso SSH e ao banco de dados entre os servidores não seja possível, migre a ((OTRS)) Community Edition para o OTOBO no mesmo servidor e só então mova a nova instalação.

Guia Passo a Passo

Passo 1: Instalação OTOBO

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

WARNING

Sob o Apache, existem armadilhas ao executar duas aplicações mod_perl independentes no mesmo servidor web. Portanto, é recomendado executar ((OTRS)) Community Edition e 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 a conclusão da instalação, por favor, faça login como root@localhost. Navegue até a área Admin do OTOBO Admin -> Pacotes e instale todos os pacotes OPM necessários do OTOBO.

Os seguintes pacotes OPM e "Addons de Funcionalidades" da ((OTRS)) Community Edition NÃO PRECISAM 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 no 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 SecureMode

Após instalar o OTOBO, por favor, faça login novamente na área Admin do OTOBO Admin -> Configuração do Sistema e desative a opção de configuração SecureMode.

INFO

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

Passo 3: Parar o Daemon OTOBO

Isso é necessário se o daemon OTOBO estiver realmente em execução. Parar o daemon é diferente entre instalações baseadas em Docker e não baseadas em Docker.

No caso não-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 em Docker, você só precisa 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 terminado com o código 0

INFO

É recomendado fazer um backup de todo o sistema OTOBO neste ponto. 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 migração.

TIP

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

Opcional montar /opt/otrs

Muitas vezes, o OTOBO deve rodar em um novo servidor onde /opt/otrs inicialmente não está disponível. Nesses casos, o diretório /opt/otrs no servidor ((OTRS)) Community Edition 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

Esta etapa só é necessária se você quiser migrar ((OTRS)) Community Edition 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 migration.pl possa copiar arquivos via ssh. Para instalar sshpass, por favor, 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 ele ainda não estiver disponível.

Passo 4: Preparação

INFO

Certifique-se de ter também um backup válido do seu sistema OTRS / ((OTRS)) Community Edition. Sim, nós não tocamos nos dados da ((OTRS)) Community Edition durante a migração, mas às vezes apenas uma entrada incorreta é suficiente para causar problemas.

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

Por favor, faça login na área Admin da ((OTRS)) Community Edition Admin -> Manutenção do Sistema e adicione um novo slot de manutenção do sistema para algumas horas. Depois disso, exclua todas as sessões de agente e usuário (Admin -> Sessões) e saia.

Parar todos os serviços relevantes e o daemon OTRS

Por favor, certifique-se de que nenhum serviço ou job cron esteja em execução.

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

Excluir os caches e os dados operacionais

Os dados em cache e os dados operacionais não precisam ser migrados. A fila de e-mail já deve 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

Etapa Opcional para Docker

Existem algumas particularidades a serem observadas se sua instalação OTOBO estiver rodando sob Docker. O mais relevante: processos que rodam em um contêiner Docker geralmente não podem acessar diretórios fora do contêiner. No entanto, há uma exceção: diretórios que são 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 do Docker pode ser o usuário root do host Docker ou um usuário dedicado com as permissões necessárias.

Copiar /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 dos contêineres são otobo-web-1, otobo-db-1 e otobo-daemon-1.

:::

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

Existem pelo menos duas maneiras viáveis:

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

b. Montar /opt/otrs como um volume adicional

Vamos nos concentrar na opção a. aqui.

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 cópia segura, 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 foi usado. Em versões mais recentes, docker compose é usado. :::

Por favor, use a ferramenta de migração web em http://localhost/otobo/migration.pl. Observe que você pode precisar substituir "localhost" pelo seu nome de host OTOBO e possivelmente adicionar sua porta não padrão. A aplicação então o guiará pelo processo de migração.

WARNING

Às vezes, um aviso é exibido de que a desativação do SecureMode não foi detectada. Neste caso, por favor, reinicie o servidor web. Isso força o servidor web a ler 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 as configurações padrão localhost para o servidor OTRS e /opt/otobo/var/tmp/copied_otrs para o diretório home OTRS. Este é o caminho dos dados que foram copiados na etapa opcional.

INFO

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

INFO

No caso do Docker, um banco de dados rodando 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 OTRS-Server. Neste caso, insira um dos endereços IP alternativos relatados pelo comando hostname --all-ip-addresses para OTRS-Server.

INFO

Ao migrar para um novo servidor de aplicação ou para uma instalação baseada em Docker, o banco de dados muitas vezes não pode ser acessado pela instalação de destino. Isso geralmente ocorre porque o usuário do banco de dados otobo só pode se conectar a partir do host onde o banco de dados está rodando. Para permitir o acesso de qualquer maneira, é recomendado 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 instalação OTRS antiga para a nova instalação OTOBO. Se você tiver configurações específicas do usuário, deve dar 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, por favor, reserve um tempo e teste todo o sistema. Assim que você 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 do Docker:

cd ~/otobo-docker
docker-compose start daemon

Passo 6: Limpeza

1. Desinstale sshpass se você não precisar mais dele.

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

3. Aproveite o OTOBO!

Problemas de Migração Conhecidos

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 teve problemas. Após reiniciar o navegador, esse problema foi geralmente resolvido. Com o Safari, às vezes era necessário excluir manualmente a sessão OTRS antiga.

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 otrs por otobo. Isso pode levar ao fato de que os arquivos CSS e JavaScript no OTOBO não podem mais ser recuperados. Se este for o caso, por favor, verifique as configurações em Kernel/Config.pm e altere-as de volta para valores razoáveis.

Migração para devido a erros MySQL

Em sistemas que tiveram problemas com um upgrade no passado, o processo de migração pode parar devido a erros MySQL nas tabelas ticket e ticket_history. Geralmente, estes são valores NULL na tabela de origem que não são mais permitidos na tabela de destino. Esses conflitos devem ser resolvidos manualmente antes que você possa continuar a migração.

A partir do OTOBO 10.0.12, há 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.

Erro na Etapa 5 ao migrar para PostgreSQL

Nesses casos, a mensagem não muito útil "O sistema não conseguiu concluir a transferência de dados." é exibida por migration.pl. O arquivo de log do Apache e o arquivo de log do OTOBO mostram uma mensagem mais significativa: " Mensagem de erro: ERROR: permission denied to set parameter "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 http://localhost/otobo/migration.pl novamente. 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 em Fórum OTOBO

Problemas com o deploy 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. Inconsistências podem ocorrer nesta etapa. Um exemplo da vida real é 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 foi excluído ou renomeado no sistema de origem. Essa inconsistência é detectada como um erro na etapa de migração Migrate configuration settings. A configuração do sistema mesclada é de fato salva no banco de dados, mas verificações de validade adicionais são realizadas durante o deploy.

O problema deve ser corrigido manualmente usando comandos do console OTOBO.

• Lista 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.

• Faça o deploy das alterações coletadas de migration.pl, incluindo o SecureMode desativado, com bin/otobo.Console.pl Maint::Config::Rebuild.

Após essas etapas manuais, você deve ser capaz de executar migration.pl novamente. A migração continuará na etapa 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 para agentes e usuários clientes entra em vigor quando a autenticação local é usada. As regras de 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 |

Em Docker: Migrar Cron-Jobs Manualmente

Em uma instalação não Docker do OTOBO, existe pelo menos um job cron que verifica a saúde do daemon. Sob Docker, este job cron não existe mais. Além disso, nenhum daemon Cron está rodando em nenhum dos contêineres Docker. Isso significa que você precisa procurar uma solução individual para sistemas OTRS com jobs cron personalizados (por exemplo, backup do banco de dados).

Migração de Oracle para Oracle

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

No host OTOBO, um cliente Oracle e o módulo Perl DBD::Oracle devem ser 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 usam o Data Pump nos bastidores.

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 DB 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 clonado otobo

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # 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 verificar, use `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Reinicie o servidor web para OTOBO

6. Continue com a Etapa 5, ou seja, execute migration.pl.

INFO

Ao migrar para uma versão OTOBO igual ou superior a 10.1, o script /opt/otobo/scripts/DBUpdate-to-10.1.pl deve ser executado para criar as novas tabelas stats_report e data_storage adicionadas na versão 10.1.

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 para o banco de dados OTOBO pode economizar tempo e é mais estável em alguns casos.

INFO

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

INFO

Estas instruções assumem que ((OTRS)) Community Edition usa MySQL como backend.

Primeiro de tudo, precisamos de um dump das tabelas de banco de dados OTRS necessárias. Então, precisamos fazer algumas transformações:

• Conversão do conjunto de caracteres para utf8mb4

• Renomear algumas tabelas

• Truncar algumas colunas de tabela

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 requer 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 copiado para o host Docker a partir de outro servidor. 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, em 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 db do Docker para importar os arquivos de dump do banco de dados. Observe que a senha para o 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 podemos pular a migração do banco de dados na próxima etapa. Preste atenção à caixa de seleção correspondente.