Migrazione dalla ((OTRS)) Community Edition a OTOBO

Benvenuti e grazie per aver scelto OTOBO! OTRS, ((OTRS)) Community Edition e OTOBO sono molto completi e flessibili nell'uso. Pertanto, ogni migrazione a OTOBO richiede un'attenta preparazione e potrebbe richiedere anche un po' di lavoro aggiuntivo.

Vi preghiamo di prendervi del tempo per la migrazione e di seguire queste istruzioni passo dopo passo.

INFO

Dopo la migrazione, i dati precedentemente disponibili in ((OTRS)) Community Edition 6 saranno disponibili in OTOBO 10. Non modifichiamo alcun dato dell'installazione OTRS 6 durante la migrazione.

Panoramica della migrazione OTOBO

Tramite l'interfaccia di migrazione di OTOBO è possibile utilizzare le seguenti strategie di migrazione:

1. La strategia di migrazione generale.

   Questo è il modo standard per eseguire una migrazione. Sono supportate molte combinazioni diverse:

   • Cambio di server: Migrare e contemporaneamente passare a un nuovo server applicativo.

   • Server applicativo e server web separati: Potete scegliere se eseguire il server applicativo e il server del database sullo stesso host oppure su host dedicati separati. Questa scelta è indipendente dall'installazione precedente in OTRS / ((OTRS)) Community Edition.

   • Database diversi: Passare da un qualsiasi database supportato a un altro database supportato.

   • Sistemi operativi diversi: Passare da un qualsiasi sistema operativo supportato a un altro sistema operativo supportato.

   • Docker: Migrare a un'installazione basata su Docker di OTOBO 10.

2. Una variante della strategia generale in cui la migrazione del database è ottimizzata.

Utilizzate la migrazione simile a ETL quando il database di origine non deve essere sottoposto a carico aggiuntivo oppure quando l'accesso al database di origine rappresenta un collo di bottiglia. Nella strategia generale, i dati vengono letti riga per riga dal database otrs e poi inseriti nel database OTOBO. In questa variante, le tabelle complete del database otrs vengono prima esportate, poi trasformate e infine importate nel database otobo.

3. Migrazione da un'installazione ((OTRS)) Community Edition 6 basata su Oracle a un'installazione OTOBO basata su Oracle.

Questo è un caso speciale non supportato dalla strategia generale di migrazione. Ciò significa che deve essere utilizzata una variante della strategia ottimizzata.

WARNING

Tutte le strategie funzionano sia per installazioni basate su Docker che per installazioni native. Tuttavia, per le installazioni basate su Docker devono essere considerate alcune particolarità. Queste particolarità vengono trattate nei passaggi opzionali.

INFO

È anche possibile clonare il database della ((OTRS)) Community Edition sul server del database OTOBO prima della migrazione effettiva. Questo può accelerare la strategia generale di migrazione.

Requisiti per la migrazione

1. Il prerequisito fondamentale per una migrazione è che abbiate già in esecuzione una ((OTRS)) Community Edition o OTRS 6.0.* e vogliate trasferire sia la configurazione che i dati a OTOBO.

   WARNING

   Vi preghiamo di riflettere attentamente se avete effettivamente bisogno dei dati e della configurazione. L'esperienza mostra che in molti casi è preferibile ricominciare da zero. Ciò accade perché l'installazione e la configurazione precedentemente utilizzate erano spesso subottimali. Potrebbe essere sensato trasferire solo i dati dei ticket e reimpostare la configurazione di base secondo le best practice di OTOBO.

2. È necessario disporre di un'installazione OTOBO attiva per avviare da lì la migrazione!

3. Questa installazione OTOBO deve includere tutti i pacchetti OPM installati nella vostra ((OTRS)) Community Edition e che volete utilizzare anche in OTOBO.

4. Se prevedete di migrare su un altro server, il server web OTOBO deve poter accedere alla posizione in cui è installata la vostra ((OTRS)) Community Edition o OTRS 6.0.*. Nella maggior parte dei casi si tratta della directory _/opt/otrs* sul server su cui è in esecuzione ((OTRS)) Community Edition. L'accesso in lettura può avvenire tramite SSH o tramite mount del filesystem.

5. Il database della ((OTRS)) Community Edition deve essere accessibile dal server su cui è in esecuzione OTOBO. L'accesso in sola lettura deve essere consentito per host esterni. Se l'accesso non è possibile o se si desidera ottimizzare la velocità della migrazione, allora è sufficiente un dump del database.

INFO

Se l'accesso SSH e al database tra i server non è possibile, migrate prima ((OTRS)) Community Edition a OTOBO sullo stesso server, quindi spostate la nuova installazione.

Istruzioni passo dopo passo

Passo 1: Installazione OTOBO

Iniziate con l'installazione di un nuovo sistema OTOBO. L'installazione precedente di OTRS / ((OTRS)) Community Edition verrà migrata su questo nuovo sistema.

WARNING

Con Apache esistono trappole nell'esecuzione di due applicazioni mod_perl indipendenti sullo stesso server web. Pertanto, si consiglia di eseguire ((OTRS)) Community Edition e OTOBO su server web separati. In alternativa, la configurazione OTRS deve essere rimossa da Apache prima di installare OTOBO. Utilizzate il comando a2query -s e verificate le directory /etc/apache2/sites-available e /etc/apache2/sites-enabled per vedere quali configurazioni sono attualmente disponibili e abilitate.

Al termine dell'installazione, effettuate l'accesso come root@localhost. Andate nell'area amministrativa di OTOBO Amministrazione -> Pacchetti e installate tutti i pacchetti OPM OTOBO necessari.

I seguenti pacchetti OPM e "Feature Addons" della ((OTRS)) Community Edition NON devono e NON dovrebbero essere installati, poiché queste funzionalità sono già incluse di default in 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

I seguenti pacchetti OTOBO sono stati integrati in OTOBO 10+. Ciò significa che non dovrebbero essere installati nel sistema di destinazione se quest'ultimo è OTOBO 10+:

• ImportExport

Passo 2: Disattivare SecureMode

Dopo aver installato OTOBO, effettuate nuovamente l'accesso nell'area amministrativa OTOBO Amministrazione -> Configurazione di sistema e disattivate l'opzione di configurazione SecureMode.

INFO

Non dimenticate di implementare effettivamente l'impostazione modificata.

Passo 3: Arrestare il demone OTOBO

Questo è necessario se il demone OTOBO è effettivamente in esecuzione. L'arresto del demone differisce tra installazioni basate su Docker e non basate su Docker.

Nel caso senza Docker, eseguite i seguenti comandi come utente otobo:

# se siete loggati come root
root> su - otobo

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

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

Se OTOBO è in esecuzione su Docker, è sufficiente arrestare il servizio daemon:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 dovrebbe terminare con codice 0

INFO

Si raccomanda di eseguire in questo momento un backup dell'intero sistema OTOBO. Se durante la migrazione dovesse andare storto qualcosa, non dovrete ripetere l'intero processo di installazione, ma potrete invece importare il backup per una nuova migrazione.

TIP

Vi consigliamo di leggere il capitolo Backup OTOBO backup-restore.

Opzionale: montare /opt/otrs

Spesso si desidera che OTOBO venga eseguito su un nuovo server dove inizialmente /opt/otrs non è disponibile. In questi casi, la directory /opt/otrs sul server ((OTRS)) Community Edition può essere montata nel filesystem del server OTOBO. Se un mount di rete standard non è possibile, sshfs potrebbe essere un'opzione.

Opzionale: sshpass e rsync

Questo passaggio è necessario solo se si desidera migrare ((OTRS)) Community Edition da un altro server e /opt/otrs non è stato montato dal server remoto sul server OTOBO.

Gli strumenti sshpass e rsync sono necessari affinché migration.pl possa copiare file tramite ssh. Per installare sshpass, effettuate l'accesso come utente root sul server ed eseguite uno dei seguenti comandi:

Installare sshpass su Debian / Ubuntu Linux

sudo apt install sshpass

Installare sshpass su RHEL/CentOS Linux

sudo yum install sshpass

Installare sshpass su Fedora Linux

sudo dnf install sshpass

Installare sshpass su OpenSUSE Linux

sudo zypper install sshpass

Lo stesso deve essere fatto per rsync se non è ancora disponibile.

Passo 4: Preparazione

INFO

Assicuratevi di avere anche un backup valido del vostro sistema OTRS / ((OTRS)) Community Edition. Sì, durante la migrazione non tocchiamo i dati della ((OTRS)) Community Edition, ma a volte basta un errore di battitura per causare problemi.

Ora siamo pronti per la migrazione. Prima di tutto dobbiamo assicurarci che nessun ticket venga più modificato e che nessun utente possa accedere a ((OTRS)) Community Edition:

Effettuate l'accesso nell'area amministrativa ((OTRS)) Community Edition Amministrazione -> Manutenzione sistema e aggiungete una nuova finestra di manutenzione per alcune ore. Successivamente eliminate tutte le sessioni degli agenti e degli utenti (Amministrazione -> Sessioni) e disconnettetevi.

Arrestare tutti i servizi rilevanti e il demone OTRS

Assicuratevi che nessun servizio o job cron sia in esecuzione.

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

Eliminare cache e dati operativi

I dati in cache e i dati operativi non devono essere migrati. A questo punto la coda delle email dovrebbe essere già vuota.

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

Passaggio opzionale per Docker

Ci sono alcune particolarità da considerare se la vostra installazione OTOBO è in esecuzione su Docker. La più importante: i processi in esecuzione in un container Docker non possono accedere a directory al di fuori del container. Tuttavia, esiste un'eccezione: le directory montate come volumi nel container possono essere accessibili. Notate anche che il database MariaDB in esecuzione in otobo_db_1 (otobo-db-1 nelle versioni più recenti di docker compose) non è direttamente accessibile dall'esterno della rete container.

INFO

Negli esempi di comandi, assumiamo che l'utente docker_admin venga utilizzato per interagire con Docker. L'amministratore Docker può essere l'utente root dell'host Docker o un utente dedicato con i permessi necessari.

Copiare /opt/otrs nel volume otobo_opt_otobo

::: note Nomi dei container Nelle vecchie versioni di docker compose i nomi dei container sono otobo_web_1, otobo_db_1 e otobo_daemon_1. Nelle versioni più recenti i nomi sono otobo-web-1, otobo-db-1 e otobo-daemon-1.

:::

In questa sezione assumiamo che la directory home OTRS /opt/otrs sia disponibile sull'host Docker.

Esistono almeno due opzioni praticabili:

a. Copiare /opt/otrs nel volume esistente otobo_opt_otobo

b. Montare /opt/otrs come volume aggiuntivo

Concentriamoci qui sull'opzione a..

Prima dobbiamo scoprire dove il volume otobo_opt_otobo è disponibile sull'host Docker.

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

Per una copia sicura utilizziamo rsync. A seconda della configurazione Docker, il comando rsync potrebbe dover essere eseguito 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 per verifica
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 per verifica

Questa directory copiata sarà disponibile all'interno del container come /opt/otobo/var/tmp/copied_otrs.

Passo 5: Migrare i dati

:::note Comando Docker Compose Nelle vecchie versioni di Docker Compose veniva usato il comando docker-compose. Nelle versioni più recenti si usa docker compose. :::

Utilizzate lo strumento web di migrazione all'indirizzo http://localhost/otobo/migration.pl. Notate che potreste dover sostituire "localhost" con il nome host OTOBO e aggiungere una porta non standard. L'applicazione vi guiderà attraverso il processo di migrazione.

WARNING

A volte viene visualizzato un avviso che la disattivazione di SecureMode non è stata riconosciuta. In questo caso, riavviate il server web. Questo costringerà il server web a ricaricare la configurazione corrente.

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

INFO

Se OTOBO è in esecuzione in un container Docker, mantenete le impostazioni predefinite localhost per il server OTRS e /opt/otobo/var/tmp/copied_otrs per la directory home OTRS. Questo è il percorso dei dati copiati nel passaggio opzionale.

INFO

I valori predefiniti per l'utente e la password del database OTRS vengono presi da Kernel/Config.pm nella directory home OTRS. Modificate le impostazioni proposte se utilizzate un utente database dedicato per la migrazione. Modificate anche le impostazioni se lavorate con un database copiato nel container Docker _otobo_db_1.

INFO

Nel caso Docker, un database in esecuzione sull'host Docker non è raggiungibile tramite 127.0.0.1 all'interno del container Docker. Ciò significa che l'impostazione 127.0.0.1 non sarà valida per il campo di input Server OTRS. In questo caso, inserite uno degli indirizzi IP alternativi riportati dal comando hostname --all-ip-addresses per Server OTRS.

INFO

Durante la migrazione verso un nuovo server applicativo o verso un'installazione basata su Docker, spesso il database non è accessibile dall'installazione di destinazione. Ciò è solitamente dovuto al fatto che l'utente database otobo può connettersi solo dall'host su cui è in esecuzione il database. Per consentire comunque l'accesso, si consiglia di creare un utente database dedicato per la migrazione, ad esempio CREATE [USER](../agents/agents.md) 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; e GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Questo utente può essere eliminato dopo la migrazione: DROP [USER](../agents/agents.md) 'otrs_migration'@'%'.

Le impostazioni specifiche dell'utente in Kernel/Config.pm vengono trasferite dall'installazione OTRS precedente alla nuova installazione OTOBO. Se avete impostazioni personalizzate, date un'occhiata al file migrato /opt/otobo/Kernel/Config.pm. Potreste voler adattare percorsi personalizzati o impostazioni LDAP. Nel migliore dei casi, scoprirete che alcune impostazioni personalizzate non sono più necessarie.

Una volta completata la migrazione, prendetevi del tempo per testare l'intero sistema. Quando avrete deciso che la migrazione è riuscita e volete iniziare a utilizzare OTOBO, avviate il demone OTOBO:

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

Nel caso Docker:

cd ~/otobo-docker
docker-compose start daemon

Passo 6: Pulizia

1. Disinstallate sshpass se non ne avete più bisogno.

2. Eliminate i database e gli utenti database creati appositamente per la migrazione, se presenti.

3. Buon divertimento con OTOBO!

Problemi noti durante la migrazione

Impossibilità di accedere dopo la migrazione

Durante i nostri test di migrazione, a volte il browser utilizzato per la migrazione ha avuto problemi. Di solito il problema veniva risolto riavviando il browser. Con Safari a volte era necessario eliminare manualmente la vecchia sessione OTRS.

L'ultima pagina della migrazione ha un layout strano

Questo può accadere se l'impostazione ScriptAlias ha un valore non standard. La migrazione sostituisce semplicemente otrs con otobo. Questo può impedire il caricamento dei file CSS e JavaScript in OTOBO. In tal caso, controllate le impostazioni in Kernel/Config.pm e ripristinatele a valori ragionevoli.

La migrazione si interrompe a causa di errori MySQL

Su sistemi che in passato hanno avuto problemi durante un aggiornamento, il processo di migrazione può interrompersi a causa di errori MySQL nelle tabelle ticket e ticket_history. Di solito si tratta di valori NULL nella tabella di origine che non sono più consentiti nella tabella di destinazione. Questi conflitti devono essere risolti manualmente prima di poter proseguire con la migrazione.

A partire da OTOBO 10.0.12, esiste un controllo in migration.pl che verifica la presenza di valori NULL prima del trasferimento dei dati. Notate che la soluzione deve comunque essere eseguita manualmente.

Errori al passo 5 durante la migrazione a PostgreSQL

In questi casi, migration.pl mostra il messaggio poco utile "Il sistema non è riuscito a completare il trasferimento dei dati.". Il file di log di Apache e il file di log OTOBO mostrano un messaggio più chiaro: "Messaggio di errore: ERRORE: permesso negato per impostare il parametro "session_replication_role", SQL: 'set session_replication_role to replica;'". Per concedere all'utente database otobo i privilegi di superutente necessari, eseguite il seguente comando come amministratore PostgreSQL: ALTER USER [otobo](../index.md) WITH SUPERUSER;. Poi provate di nuovo ad eseguire http://localhost/otobo/migration.pl. Dopo la migrazione, tornate alla normalità eseguendo ALTER USER [otobo](../index.md) WITH NOSUPERUSER.

Non è ancora chiaro se i privilegi estesi debbano essere concessi in ogni configurazione.

TIP

La discussione nel Forum OTOBO

Problemi con il deployment della configurazione di sistema unita

La configurazione di sistema viene migrata dopo che le tabelle del database sono state migrate. In questo contesto, migrazione significa che le impostazioni predefinite di OTOBO vengono unite con la configurazione di sistema del sistema OTRS di origine. In questo passaggio possono verificarsi incoerenze. Un esempio pratico è l'impostazione Ticket::Frontend::AgentTicketQuickClose###State. Questa impostazione è nuova in OTOBO 10 e il valore predefinito è lo stato closed successful. Ma questa impostazione è invalida se lo stato closed successful è stato eliminato o rinominato nel sistema di origine. Questa incoerenza viene rilevata come errore nel passaggio di migrazione Migrate configuration settings. La configurazione di sistema unita viene effettivamente salvata nel database, ma ulteriori controlli di validità vengono eseguiti durante il deployment.

Il problema deve essere risolto manualmente tramite comandi della console OTOBO.

• Elencate le incoerenze con il comando bin/otobo.Console.pl Admin::Config::ListInvalid.

• Correggete i valori non validi in modo interattivo con bin/otobo.Console.pl Admin::Config::FixInvalid.

• Deployate le modifiche raccolte da migration.pl, inclusa la disattivazione di SecureMode, con bin/otobo.Console.pl Maint::Config::Rebuild.

Dopo questi passaggi manuali, dovreste essere in grado di eseguire nuovamente migration.pl. La migrazione continuerà dal passaggio in cui si è verificato l'errore.

Compiti manuali finali

Regole della politica delle password

Con OTOBO 10 entra in vigore una nuova politica delle password predefinita per gli agenti e gli utenti clienti quando viene utilizzata l'autenticazione locale. Le regole della politica delle password possono essere modificate nella configurazione di sistema (PreferencesGroups###Password e CustomerPersonalPreference###Password).

| Regola della politica delle password | Predefinito |

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

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Sì |

| PasswordNeedDigit | Sì |

| PasswordHistory | 10 |

| PasswordTTL | 30 giorni |

| PasswordWarnBeforeExpiry | 5 giorni |

| PasswordChangeAfterFirstLogin | Sì |

Sotto Docker: Migrazione manuale dei job cron

In un'installazione OTOBO non basata su Docker esiste almeno un job cron che verifica lo stato del demone. Sotto Docker questo job cron non esiste più. Inoltre, nessun demone cron è in esecuzione in uno dei container Docker. Ciò significa che dovrete cercare una soluzione personalizzata per i sistemi OTRS con job cron specifici dell'utente (ad esempio backup del database).

Migrazione da Oracle a Oracle

Per la migrazione a Oracle deve essere applicata la strategia simile a ETL. Ciò è dovuto al fatto che Oracle non offre un modo semplice per disabilitare temporaneamente i controlli di chiave esterna.

Sull'host OTOBO devono essere installati un client Oracle e il modulo Perl DBD::Oracle.

INFO

Quando si utilizza il client Oracle Instant, è necessario anche l'SDK opzionale per l'installazione di DBD::Oracle.

Esistono molte modalità per clonare uno schema. Nei comandi di esempio utilizziamo expdp e impdp, che sfruttano Data Pump.

INFO

Le stringhe di connessione mostrate in questa documentazione si riferiscono al caso in cui sia il database di origine che quello di destinazione siano in esecuzione in un container Docker. Vedere anche https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Pulizia di otobo

Arrestate il server web per otobo in modo che la connessione al database per otobo venga chiusa.

DROP USER otobo CASCADE

2. Esportazione dell'intero schema 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. Importare lo schema OTRS e rinominarlo in '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. Adattare lo schema otobo clonato

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # è normale che il comando conosca solo il database otobo, solo l'ultima riga è rilevante
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
Verifica con `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Riavviare il server web per OTOBO

6. Proseguire con il passo 5, cioè eseguire migration.pl.

INFO

Se si migra a una versione OTOBO maggiore o uguale a 10.1, è necessario eseguire lo script /opt/otobo/scripts/DBUpdate-to-10.1.pl per creare le nuove tabelle stats_report e data_storage aggiunte nella versione 10.1.

Opzionale: Migrazione semplificata del database (solo per esperti e scenari specifici)

Nella strategia generale di migrazione, tutti i dati nelle tabelle del database vengono copiati riga per riga dal database OTRS al database OTOBO. L'esportazione dei dati dal database OTRS e l'importazione nel database OTOBO può risparmiare tempo ed essere in alcuni casi più stabile.

INFO

Questa variante funziona sia per installazioni basate su Docker che per installazioni native.

INFO

Queste istruzioni presuppongono che ((OTRS)) Community Edition utilizzi MySQL come backend.

Prima di tutto abbiamo bisogno di un dump delle tabelle del database OTRS necessarie. Poi dobbiamo eseguire alcune trasformazioni:

• Conversione del set di caratteri in utf8mb4

• Rinominazione di alcune tabelle

• Accorciamento di alcune colonne delle tabelle

Dopo la trasformazione, possiamo sovrascrivere le tabelle nello schema OTOBO con i dati trasformati da OTRS. In pratica, non abbiamo bisogno di un singolo file dump, ma di diversi script SQL.

Se mysqldump è installato ed è possibile connettersi al database OTRS, potete creare il dump del database direttamente sull'host Docker. Questo caso è supportato dallo script bin/backup.pl.

WARNING

Questo richiede che un'installazione OTOBO sia disponibile sull'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

In alternativa, il database può essere salvato su un altro server e successivamente trasferito sull'host Docker. Un modo semplice per farlo è copiare /opt/otobo sul server su cui è in esecuzione OTRS ed eseguire lo stesso comando di cui sopra.

Lo script bin/backup.pl genera quattro script SQL in una directory dump, ad esempio in 2021-04-13_12-13-04. Per eseguire gli script SQL, dobbiamo eseguire il comando mysql.

Installazione 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

Installazione basata su Docker:

Eseguite il comando mysql all'interno del container Docker db per importare i file dump del database. Notate che la password per il database root ora è la password impostata nel file .env sull'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

Per un controllo rapido del corretto funzionamento dell'importazione, potete eseguire i seguenti comandi.

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'

oppure in esecuzione su 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'

Il database è ora migrato. Ciò significa che nel passaggio successivo possiamo saltare la migrazione del database. Prestare attenzione alla casella di controllo corrispondente.