[crythias]

I’m trying to locate where the hangup is with regard to the tickets.

I can see them under my OTRSv6 dashboard, but they’re blank under OTOBO.

I have these:

[Wed Feb 10 20:30:34.250263 2021] [mpm_prefork:notice] [pid 2406121] AH00169: caught SIGTERM, shutting down
[Wed Feb 10 20:30:35.073474 2021] [mpm_prefork:notice] [pid 2416610] AH00163: Apache/2.4.41 (Ubuntu) mod_perl/2.0.11 Perl/v5.30.0 configured — resuming normal operations
[Wed Feb 10 20:30:35.073582 2021] [core:notice] [pid 2416610] AH00094: Command line: ‚/usr/sbin/apache2‘
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.

 

But syslog and journalctl -r doesn’t show anything.

I can’t connect to the admin portal, but reverting to OTRS v6 I can.

When I try the admin portal in Otobo, I get kicked out and permission denied.

 

 

[crythias]

The database has tickets and articles…

 

[crythias]

never mind at the moment. didn’t run migration.pl before posting.

[crythias]

Migrate web service configuration.

Failed – see the log!

 

Where’s the log?

[crythias]

found some things in /var/log/apache2/error.log

ERROR: OTOBO-CGI-17 Perl: 5.30.0 OS: linux Time: Wed Feb 10 20:49:04 2021

Message: Setting Ticket::Type::Default Effective value is not correct: Entity value is invalid(Support)!

ERROR: OTOBO-CGI-17 Perl: 5.30.0 OS: linux Time: Wed Feb 10 20:50:15 2021

Message: Duplicate entry ‚1‘ for key ‚PRIMARY‘, SQL: ‚INSERT INTO gi_webservice_config (id, name, config, valid_id, create_by, create_time, change_by, change_time)
VALUES
(1, ‚Elasticsearch‘, ‚—
Debugger:

…

Message: Could not execute INSERT INTO gi_webservice_config (id, name, config, valid_id, create_by, create_time, change_by, change_time)
VALUES
(1, ‚Elasticsearch‘, ‚—

 

This I think

[Sven Oesterling]

Hi Crythias,

yes, this is the bug mentioned in my answer in the other topic. It will be resolved in OTOBO 10.0.8 which is planned to be released tomorrow. As you are almost done with the migration, though, you might want to download the current version of https://github.com/RotherOSS/otobo/blob/rel-10_0/Kernel/System/MigrateFromOTRS/OTOBOMigrateWebServiceConfiguration.pm (right click on raw and save it) and replace the file in your installation. It will work then.

The error above the webservices could lead to some trouble. Invalid sysconfig settings have to be resolved by hand (and it’s better done before migration). But I’m not 100% sure that it won’t work, just from the logs. As mentioned in the other post, you should be able to just restart the migration where you left, after replacing the file.

(If you run into errors regarding the Sysconfig, please try /opt/otrs/bin/otrs.Console.pl Admin::Config::ListInvalid on the source system. You can try fixing things on the otobo side, later, too – for me this worked in more than one cases, but I’m not sure about docker e.g.)

Sven

[Alvaro Cordero Retana]

Hello, I just finished doing a migration of a system with about 65000 tickets and I get the exact same issue. Everything seems to be there but not permissions are applied.

 

I migrated from latest OTRS 6 to OTOBO 10.1 latest. I fixed all invalid configs and stuff early during first migration attempt.

 

Should I migrate to OTOBO 10.0 and the to OTOBO 10.1? Is it ok to migrate directly to 10.1?

 

Regards

[Stefan Rother]

Hi,

I think you made a mistake doing the migration. Did you follow the exact migration instructions from https://doc.otobo.org/manual/installation/10.1/en/content/migration-from-otrs-6.html?

The migration to 10.1 is not yet so well tested, but should be just as possible.

It’s not easy to find the problem, but please check if the database table groups_table exists or if it is possibly corrupted.

Best wishes,

Stefan

Team OTOBO

[Alvaro Cordero Retana]

Hello,

In fact I did follow the instructions several times until I got a successfull migration message, but it had what I described.

 

Afterwards I decided to go back and install 10.0 first and did the migration to that version firs, it indeed went a little bit smooth, but at the end, even though I can see all the roles, the data, the menus, still don’t have the groups, so what you said makes sense, I will redo the process again hopefully this afternoon and find out where the error is.

I can look into the database and all is there, the groups, the roles, the queues, the role_groups table, but it just can’t be seen in the interface.

I’ll let you guys know if I identify where the issue is.

Regards

[Alvaro Cordero Retana]

Hello again,

In regards of what Stephan mentioned we reviewed the list of tables and found that in fact the groups_table existed and had all the new groups, but the ones coming from otrs where not inserted into this one, instead, the groups table from otrs was kept.

So we moved all the contents from groups into groups_table and it seems to be ok now.

Question? Should there be something into the migration script that merges those tables instead of keeping the old one?

[Autor]

Beiträge