Upgradefehler 5.0.26 -> 6.0.7

Hilfe zu OTRS Problemen aller Art
Post Reply
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Einen schönen guten Tag euch allen,

aktuell versuche ich ein Klonsystem von 5.0.26 auf 6.0.7 upzugraden. Ich konnte schon diverse Fehler beheben, bzw. habe im Forum weitere Schritte gefunden. Leider habe ich aktuell eine Fehlermeldung, welche sich nicht mit bisher beschriebenen Ansätzen lösen lässt und hoffe ihr könnt mir hier helfen.
Fehlermeldung:

Code: Select all

root@otrs:/opt/otrs# su -c "/opt/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs

 Migration started ...

 Checking requirements ...

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Requirement check for: Check required database version ...
    Requirement check for: Check database charset ...
    Requirement check for: Check required Perl modules ...
    Requirement check for: Check if database has been backed up ...

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...
    Requirement check for: Migrating time zone configuration ...
    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Migrate ArticleType in ProcessManagement Data ...
    Requirement check for: Migrate ArticleType in PostMaster filters ...

 Executing tasks ...

    Step 1 of 38: Check framework version ...
    Step 2 of 38: Check required Perl version ...
    Step 3 of 38: Check required database version ...
    Step 4 of 38: Check database charset ...
    Step 5 of 38: Check required Perl modules ...
    Step 6 of 38: Check if database has been backed up ...
    Step 7 of 38: Upgrade database structure ...
    Step 8 of 38: Migrate configuration ...
    Step 9 of 38: Refresh configuration cache after migration of OTRS 5 settings...
    Step 10 of 38: Migrating ticket storage configuration ...
    Step 11 of 38: Migrating article search index configuration ...
    Step 12 of 38: Migrating ticket zoom customer information widget configuration ...
    Step 13 of 38: Drop deprecated table gi_object_lock_state ...
    Step 14 of 38: Migrate PossibleNextActions setting ...
    Step 15 of 38: Migrate ZoomExpand setting ...
    Step 16 of 38: Migrating time zone configuration ...
    Step 17 of 38: Create appointment calendar tables ...
    Step 18 of 38: Create ticket number counter tables ...
    Step 19 of 38: Update calendar appointment future tasks ...
    Step 20 of 38: Add basic appointment notification for reminders ...
    Step 21 of 38: Create Form Draft tables ...
    Step 22 of 38: Clean and drop group_user permission_value column ...
    Step 23 of 38: Migrate GenericAgent jobs configuration ...
    Step 24 of 38: Migrate TicketAppointment rules configuration ...
    Step 25 of 38: Migrate Merged Ticket history name values ...
    Step 26 of 38: Migrate ticket statistics ...
    Step 27 of 38: Migrate ticket notifications ...
    Step 28 of 38: Post changes on article related tables ...
[Thu May 17 13:20:12 2018] DBUpdate-to-6.pl: DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`otrs`.`#sql-47b8_b7`, CONSTRAINT `FK_article_data_mime_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)) at /opt/otrs/Kernel/System/DB.pm line 470.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.18.2 OS: linux Time: Thu May 17 13:20:12 2018

 Message: Cannot add or update a child row: a foreign key constraint fails (`otrs`.`#sql-47b8_b7`, CONSTRAINT `FK_article_data_mime_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)), SQL: 'EXECUTE FKStatement'

 Traceback (27276):
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 363
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_UpdateArticleDataMimeTable Line: 295
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 51
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /opt/otrs/scripts/DBUpdate-to-6.pl Line: 84


ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.18.2 OS: linux Time: Thu May 17 13:20:12 2018

 Message: Error during execution of 'EXECUTE FKStatement'!

 Traceback (27276):
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 366
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_UpdateArticleDataMimeTable Line: 295
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 51
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /opt/otrs/scripts/DBUpdate-to-6.pl Line: 84




 Not possible to complete migration, check previous messages for more information.
Ich habe auch diesen Ansatz bereits versucht, allerdings werden hier keinerlei Dateien mit einer solchen Endung gefunden.

Dieser Ansatz bringt mich ebenfalls zu keiner Lösung.

PS: Da im orginalen Migrationskript meine Ticketinhalte komplett entfernt werden, habe ich folgende Zeile aus der Datei /opt/otrs/scripts/DBUpdateTo6.pm entfernt:

Code: Select all

				{
            Message => 'Create entries in new article table',
            Module  => 'MigrateArticleData',
            },
Allerdings glaube ich nicht, dass dies den aktuellen Fehler verursacht.

Code: Select all

root@otrs:/opt/otrs# /opt/otrs/bin/otrs.CheckModules.pl
  o Apache::DBI......................ok (v1.12)
  o Apache2::Reload..................ok (v0.13)
  o Archive::Tar.....................ok (v1.90)
  o Archive::Zip.....................ok (v1.30)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
  o Crypt::SSLeay....................ok (v0.58)
  o Date::Format.....................ok (v2.24)
  o DateTime.........................ok (v1.06)
  o DBI..............................ok (v1.630)
  o DBD::mysql.......................ok (v4.025)
  o DBD::ODBC........................ok (v1.45)
  o DBD::Oracle......................Not installed! (optional - Required to connect to a Oracle database.)
  o DBD::Pg..........................ok (v2.19.3)
  o Digest::SHA......................ok (v5.84_01)
  o Encode::HanExtra.................ok (v0.23)
  o IO::Socket::SSL..................ok (v1.965)
  o JSON::XS.........................ok (v2.34)
  o List::Util::XS...................ok (v1.27)
  o LWP::UserAgent...................ok (v6.26)
  o Mail::IMAPClient.................ok (v3.35)
    o IO::Socket::SSL................ok (v1.965)
    o Authen::SASL...................ok (v2.15)
    o Authen::NTLM...................Not installed! Use: 'apt-get install -y libauthen-ntlm-perl' (optional - Required for NTLM authentication mechanism in IMAP connections.)
  o ModPerl::Util....................ok (v2.000008)
  o Net::DNS.........................ok (v0.68)
  o Net::LDAP........................ok (v0.58)
  o Template.........................ok (v2.24)
  o Template::Stash::XS..............ok (undef)
  o Text::CSV_XS.....................ok (v1.02)
  o Time::HiRes......................ok (v1.9725)
  o XML::LibXML......................ok (v2.0108)
  o XML::LibXSLT.....................ok (v1.84)
  o XML::Parser......................ok (v2.41)
  o YAML::XS.........................ok (v0.41)
Ubuntu 14.04.5 LTS

Über konstruktive Lösungsvorschläge würde ich mich sehr freuen.


Mit freundlichen Grüßen

Sascha Sebastian Wieth
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by wurzel »

Hi,

die Migration sollte schon laufen. Du könntest die Foreign Key checks abschalten - aber das ist auch doof.

Warum hast Du
PS: Da im orginalen Migrationskript meine Ticketinhalte komplett entfernt werden, habe ich folgende Zeile aus der Datei /opt/otrs/scripts/DBUpdateTo6.pm entfernt:
da was entfernt?

viele Grüße
Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Hallo wurzel,

dies musste ich entfernen, da hier ständig alle Kundenmails aus der Datenbank als verwaist markiert wurden und gelöscht werden MUSSTEN. Ein verneinen des Löschens hatte sofort zur Folge, dass die Migration fehlschlug.

Mit freundlichen Grüßen

Sascha Sebastian Wieth
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by wurzel »

Hi,

das versteh ich nicht. Sorry. Ich musste da noch nie was verneinen oder so :shock:

viele Grüße
Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Ich habe gerade diesen Punkt ebenfalls entfernt und die Migration war erfolgreich. Leider musste ich feststellen, dass trotz des Entfernens dieser Einträge die kompletten Einträge leer sind. Mache ich irgendetwas falsch? Die Migration auf Version 5 klappte tadellos. Bei Update 6 verschwinden sämtliche Ticketinhalte. Man sieht noch die Übersicht, aber das Ticket selbst ist dann komplett leer.
Image

Wie zu sehen, werden die Tickets in der Übersicht aber noch angezeigt:
Image

Wo könnte denn hier der Fehler liegen?

Mit freundlichen Grüßen

Sascha Sebastian Wieth
You do not have the required permissions to view the files attached to this post.
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

Das Migrationsscript muss ohne Änderungen! und ohne Fehler durchlaufen. Sonst kann es keine erfolgreiche Migration geben.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Aber ich werde in diesem Skript gefragt, ob ich sämtliche Einträge aus der Datenbank entfernen möchte, da diese Einträge verwaist wären. Woran kann sowas liegen?
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

zeig bitte mal die konkrete Fehlermeldung
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Code: Select all

root@otrs:/opt/otrs# su -c "/opt/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs

 Migration started ...

 Checking requirements ...

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Requirement check for: Check required database version ...
    Requirement check for: Check database charset ...
    Requirement check for: Check required Perl modules ...
    Requirement check for: Check if database has been backed up ...

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...
    Requirement check for: Migrating time zone configuration ...


        The currently configured time offset is 2 hours, these are the suggestions for a corresponding OTRS time zone:

        Africa/Blantyre
        Africa/Bujumbura
        Africa/Cairo
        Africa/Ceuta
        Africa/Gaborone
        Africa/Harare
        Africa/Johannesburg
        Africa/Kigali
        Africa/Lubumbashi
        Africa/Lusaka
        Africa/Maputo
        Africa/Maseru
        Africa/Mbabane
        Africa/Tripoli
        CET
        Europe/Amsterdam
        Europe/Andorra
        Europe/Belgrade
        Europe/Berlin
        Europe/Brussels
        Europe/Budapest
        Europe/Copenhagen
        Europe/Gibraltar
        Europe/Luxembourg
        Europe/Madrid
        Europe/Malta
        Europe/Monaco
        Europe/Oslo
        Europe/Paris
        Europe/Prague
        Europe/Rome
        Europe/Stockholm
        Europe/Tirane
        Europe/Vienna
        Europe/Warsaw
        Europe/Zurich
        MET


        It seems that Europe/Berlin should be the correct time zone to set for your OTRS.

        Enter the time zone to use for OTRSTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

        Enter the time zone to use for UserDefaultTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Create entries in new article table ...

        Found 4577 orphaned entries in article_flag table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o:
Wenn ich jetzt Y eingeben werden die Einträge komplett gelöscht, wenn ich N eingebe, wird die Migration direkt abgebrochen.

Vielleicht liegt der Fehler ja schon vorher. Hier mal mein Ablaufplan:

Code: Select all

service cron stop
service postfix stop
service nginx stop
service apache2 stop
su -c "/opt/otrs/bin/otrs.Daemon.pl stop" -s /bin/bash otrs
su -c "/opt/otrs/bin/Cron.sh stop" -s /bin/bash otrs
cd /opt
wget http://ftp.otrs.org/pub/otrs/otrs-6.0.7.tar.gz
mv -n otrs otrs-oldv5
tar -xzf otrs-6.0.7.tar.gz
mv otrs-6.0.7 otrs
cp /opt/otrs-oldv5/Kernel/Config.pm /opt/otrs/Kernel/
cd /opt/otrs/var/cron
cd /opt/otrs/
bin/otrs.SetPermissions.pl --web-group=www-data
apt install libdatetime-perl
sudo apt-get update
sudo apt-get dist-upgrade
/opt/otrs/bin/otrs.CheckModules.pl
su -c "/opt/otrs/bin/otrs.Console.pl Dev::Tools::Migrate::ConfigXMLStructure --source-directory Kernel/Config/Files/XML" -s /bin/bash otrs
su -c "/opt/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs
su -c "/opt/otrs/bin/otrs.Console.pl Admin::Package::Upgrade http://ftp.otrs.org/pub/otrs//packages/:FAQ-6.0.6.opm" otrs
su -c "/opt/otrs/bin/otrs.Console.pl Admin::Package::Upgrade http://ftp.otrs.org/pub/otrs//itsm/bundle6/:ITSM-6.0.7.opm" otrs
service apache2 start
service postfix start
service nginx start
service cron start
su -c "/opt/otrs/bin/otrs.Daemon.pl start" -s /bin/bash otrs
su -c "/opt/otrs/bin/Cron.sh start" -s /bin/bash otrs
Problem tritt auf bei Punkt su -c "/opt/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs .
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

es geht hier um die Article Flag table, wenn hier Einträge verweist sind, bedeutet das üblicherweise das z.B. Agenten aus der Datgelöschtenbank wurden.

Die Löschung dieser Records stellt aber kein Problem für den Inhalt dar.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Also hier mal die Meldung, was aktuell passiert, wenn ich alles unverändert ausführe:

Code: Select all

root@otrs:/opt/otrs# su -c "/opt/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs

 Migration started ...

 Checking requirements ...

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Requirement check for: Check required database version ...
    Requirement check for: Check database charset ...
    Requirement check for: Check required Perl modules ...
    Requirement check for: Check if database has been backed up ...

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...
    Requirement check for: Migrating time zone configuration ...


        The currently configured time offset is 2 hours, these are the suggestions for a corresponding OTRS time zone:

        Africa/Blantyre
        Africa/Bujumbura
        Africa/Cairo
        Africa/Ceuta
        Africa/Gaborone
        Africa/Harare
        Africa/Johannesburg
        Africa/Kigali
        Africa/Lubumbashi
        Africa/Lusaka
        Africa/Maputo
        Africa/Maseru
        Africa/Mbabane
        Africa/Tripoli
        CET
        Europe/Amsterdam
        Europe/Andorra
        Europe/Belgrade
        Europe/Berlin
        Europe/Brussels
        Europe/Budapest
        Europe/Copenhagen
        Europe/Gibraltar
        Europe/Luxembourg
        Europe/Madrid
        Europe/Malta
        Europe/Monaco
        Europe/Oslo
        Europe/Paris
        Europe/Prague
        Europe/Rome
        Europe/Stockholm
        Europe/Tirane
        Europe/Vienna
        Europe/Warsaw
        Europe/Zurich
        MET


        It seems that Europe/Berlin should be the correct time zone to set for your OTRS.

        Enter the time zone to use for OTRSTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

        Enter the time zone to use for UserDefaultTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Create entries in new article table ...

        Found 4577 orphaned entries in article_flag table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
        Fixing... Done.

        Found 1 orphaned entries in time_accounting table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
        Fixing... Done.

        Found 8 orphaned entries in article_plain table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
        Fixing... Done.

        Found 5 orphaned entries in ticket_history table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
        Fixing... Done.

        Found 3 orphaned entries in article table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
        Fixing... Done.

    Requirement check for: Migrate ArticleType in ProcessManagement Data ...
    Requirement check for: Migrate ArticleType in PostMaster filters ...

 Executing tasks ...

    Step 1 of 39: Check framework version ...
    Step 2 of 39: Check required Perl version ...
    Step 3 of 39: Check required database version ...
    Step 4 of 39: Check database charset ...
    Step 5 of 39: Check required Perl modules ...
    Step 6 of 39: Check if database has been backed up ...
    Step 7 of 39: Upgrade database structure ...
    Step 8 of 39: Migrate configuration ...
    Step 9 of 39: Refresh configuration cache after migration of OTRS 5 settings ...
    Step 10 of 39: Migrating ticket storage configuration ...
    Step 11 of 39: Migrating article search index configuration ...
    Step 12 of 39: Migrating ticket zoom customer information widget configuration ...
    Step 13 of 39: Drop deprecated table gi_object_lock_state ...
    Step 14 of 39: Migrate PossibleNextActions setting ...
    Step 15 of 39: Migrate ZoomExpand setting ...
    Step 16 of 39: Migrating time zone configuration ...
    Step 17 of 39: Create appointment calendar tables ...
    Step 18 of 39: Create ticket number counter tables ...
    Step 19 of 39: Update calendar appointment future tasks ...
    Step 20 of 39: Add basic appointment notification for reminders ...
    Step 21 of 39: Create Form Draft tables ...
    Step 22 of 39: Clean and drop group_user permission_value column ...
    Step 23 of 39: Migrate GenericAgent jobs configuration ...
    Step 24 of 39: Migrate TicketAppointment rules configuration ...
    Step 25 of 39: Migrate Merged Ticket history name values ...
    Step 26 of 39: Migrate ticket statistics ...
    Step 27 of 39: Migrate ticket notifications ...
    Step 28 of 39: Create entries in new article table ...
[Fri May 18 12:23:18 2018] DBUpdate-to-6.pl: DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`otrs`.`article`, CONSTRAINT `FK_article_create_by_id` FOREIGN KEY (`create_by`) REFERENCES `users` (`id`)) at /opt/otrs/Kernel/System/DB.pm line 470.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.18.2 OS: linux Time: Fri May 18 12:23:19 2018

 Message: Cannot add or update a child row: a foreign key constraint fails (`otrs`.`article`, CONSTRAINT `FK_article_create_by_id` FOREIGN KEY (`create_by`) REFERENCES `users` (`id`)), SQL: '
                INSERT INTO article (
                    id,ticket_id,article_sender_type_id,communication_channel_id,
                    is_visible_for_customer,create_by,create_time,change_by,change_time
                )VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ? ), ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) , ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) '

 Traceback (20437):
   Module: scripts::DBUpdateTo6::MigrateArticleData::_MigrateData Line: 302
   Module: scripts::DBUpdateTo6::MigrateArticleData::Run Line: 136
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /opt/otrs/scripts/DBUpdate-to-6.pl Line: 89

ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.18.2 OS: linux Time: Fri May 18 12:23:19 2018

 Message: An error occurs during article data migration!

 Traceback (20437):
   Module: scripts::DBUpdateTo6::MigrateArticleData::Run Line: 142
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /opt/otrs/scripts/DBUpdate-to-6.pl Line: 89


    An error occurs during article data migration!



 Not possible to complete migration, check previous messages for more information.
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

Anscheinend werden leider nicht alle Tabellen sauber auf orphaned records geprüft (kannst gerne einen Bug dafür aufmachen)

Ursache ist, das ein Benutzer (Agent) gelöscht wurde. Das hat die referentielle Intigrität der Datenbank zerstört. Das musst Du nun in irgendeiner Weise bereinigen.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Danke für die Rückmeldung, ich werde dies mit unserem DB Spezialisten mal eingehen bearbeiten. Wenn wir zu einer Lösung gekommen sind, melde ich mich nochmal.
Pasce1203
Znuny newbie
Posts: 6
Joined: 04 Jul 2018, 16:28
Znuny Version: 5.0.23
Real Name: Pascal

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Pasce1203 »

Hallo,

bin gerade beim selben Problem.
Hat hierfür vielleicht jemand eine Lösung?

Danke im Voraus
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Ich leider noch nicht. Bin aktuell weiterhin mit unserem DB Spezialisten dran herauszufinden, wie wir dies lösen können. Leider fehlt ein wenig die Zeit, da aktuell dringendere Aufgaben anstehen.
Sollte jemand einen Lösungsansatz parat haben, würde aber auch ich diesen sehr begrüßen.

Mit freundlichen Grüßen
Sascha Sebastian Wieth
einhirn
Znuny newbie
Posts: 4
Joined: 28 Oct 2013, 11:03
Znuny Version: 3.2.10

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by einhirn »

Hallo in die Runde!

Ich habe gerade beim ersten Anlauf auf einen Test des Upgrades von OTRS 5.0.6 auf 6.0.8 das gleiche beziehungsweise ein ähnliches Problem erlebt. Ich werde mir mal die DB-Abfragen anschauen, die im Updatescript drin sind - ich habe aber den Verdacht, dass es bei uns daran liegen könnte, dass wir die ArticleDB "FS" nutzen, unsere Artikel also als Datei im Dateisystem liegen, nicht in der Datenbank...

bye
Einhirn
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

wie gesagt muss in diesen Fällen die Datenbank ggf. händisch bereinigt werden. Insbesondere kann dies vorkommen wenn Benutzer gelöscht wurden
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
einhirn
Znuny newbie
Posts: 4
Joined: 28 Oct 2013, 11:03
Znuny Version: 3.2.10

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by einhirn »

Hallihallo,

ich habe die Ursache bei uns gefunden - wahrscheinlich haben wir irgendwann einmal Artikel aus dem Dateisystem gelöscht, nachdem sie aus der DB exportiert waren oder sowas. Jedenfalls habe ich die Queries, die man angezeigt bekommt wenn man "No" sagt, mal als Grundlage für "Select"s genommen und herausgefunden, dass die "Create_time"-Einträge in unserem jeweils mehr als 5 Jahre her sind. Und weiter als 5 Jahre zurück haben wir auch keine Artikel mehr im Dateisystem...

Daher habe ich jetzt Schritt für Schritt nachgeschaut und dann aufräumen lassen. Nur bei der "Article"-DB bin ich auf die Klappe gefallen:

Code: Select all

        Found 78354 orphaned entries in article table ...
        Do you want to automatically delete the entries from the database now? [Y]es/[N]o: y
[Wed Jul 11 12:38:28 2018] DBUpdate-to-6.pl: DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign key constraint fails (`otrs`.`ticket_history`, CONSTRAINT `FK_ticket_history_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)) at /opt/otrs-6.0.8/Kernel/System/DB.pm line 470, <> line 13.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-5323 Perl: 5.18.2 OS: linux Time: Wed Jul 11 12:38:28 2018

 Message: Cannot delete or update a parent row: a foreign key constraint fails (`otrs`.`ticket_history`, CONSTRAINT `FK_ticket_history_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)), SQL: '
                        DELETE
                        FROM article
                        WHERE article.ticket_id
                        NOT IN (SELECT ticket.id FROM ticket)
                    '

 Traceback (10560):
   Module: scripts::DBUpdateTo6::MigrateArticleData::CheckPreviousRequirement Line: 510
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 163
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: scripts/DBUpdate-to-6.pl Line: 89




 Not possible to complete migration, check previous messages for more information.
werde wohl vorübergehend die Constraints ausschalten müssen, um das durch zu bekommen...

bye
Einhirn
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

werde wohl vorübergehend die Constraints ausschalten müssen, um das durch zu bekommen...
Dies habe ich ebenfalls versucht und die Migration läuft dann auch durch, leider werden dann nur gar keine Daten migriert und man hat nichts damit gewonnen. =(

LG SSW
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Gibt es hier neue Erkenntnisse?

Für meinen Begriff ist das Migrationsscript für die Artikel-Daten nicht funktional. Wir versuchen von 5.0.26 nach 6.0.10 zu migrieren.

1. Das Modul UpgradeDatabaseStructure lädt in dieser Reihenfolge die Untermodule:

ArticleTableChangesPreRename.pm -> ArticleTableChangesRename.pm -> ArticleTableChangesPostRename.pm

Danach existieren (auf dem Papier) 2 Tabellen: eine neue Tabelle article und eine umbenannte Tabelle article -> 'article_data_mime'

Dummerweise ist aber der Vorgang in ArticleTableChangesPostRename nicht erfolgreich, die Tabelle 'article' hat falsche Spalten. Es fehlt mindestens die Spalte "communication_channel_id". Für mich sieht das so aus, als wären die TableAlter-Befehle alle fehlgeschlagen.

2. Das Modul MigrateArticleData.pm soll eigentlich Inhalte der Artikel aus article_data_mime nach article kopieren. Kann es aber eigentlich gar nicht schaffen, weil die Spalte "communication_channel_id" nicht exisitiert. Es gibt aber KEINE Fehlermeldungen für die vielen Inserts.

3. Am Ende bleibt eine unvollständige Tabelle article übrig. Diese hat zwar ohne Ende Inhalte, aber da die Spalte "communication_channel_id" fehlt, ist OTRS nicht in der Lage, Inhalte darzustellen. Aber woher kommen die Inhalte überhaupt?


Zusammengefasst:
Ich verstehe nicht, wieso die Tabelle article noch existiert und / oder warum sie die neuen Spalten nicht besitzt.
Ich verstehe nicht, wieso sie die neue Spalte "communication_channel_id" nicht besitzt.

Leider gibt es im Github seit Juli keine Änderungen in den Migrationsscripten...
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

Deine Datenbank scheint korrupt zu sein, diese Probleme musst Du manuell lösen. Dann läuft auch das Migrationsskript problemlos. Ich konnte schon diverse Systeme jeglichen Alters (bis hin zu einem System das seit der 1.0RC1 existiert) migrieren.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Bisher hatten wir noch nie Probleme, die OTRS-Migrationen auszuführen. Wir machen das mindestens seit OTRS 3.
Das ist das erste Mal, dass es nicht klappt.

Ja natürlich ist die Datenbank korrupt. Und zwar wird sie von den DB-Migrationsscripten kaputt gemacht.
OTRS 5 läuft ja schliesslich vorher tadellos...

Wie gesagt, ArticleTableChangesPostRename läuft nicht richtig, danach ist die Tabelle für "article" ohne Artikel-Inhalte.
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

OTRS 5 läuft auch mit einer kaputten Datenbank. Das Migrationsscript macht nichts kaputt, ich habe schon mehrere TB an Daten migriert.

Ich empfehle Euch daher dringend professionellen Support einzukaufen.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Hm. HM. Danke, ich schau mal, was das sein könnte.
Seppelchen
Znuny newbie
Posts: 14
Joined: 21 Mar 2018, 13:16
Znuny Version: 4.0.13
Real Name: Sascha Sebastian
Company: Clarity AG

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by Seppelchen »

Aktuell versuche ich, mit Hilfe unseres DB-Spezialisten, ein neues OTRS 6 aufzusetzen und die benötigten Daten manuell zu migrieren. Sollten daraus Schlüsse zu folgern oder dieses Vorhaben irgendwie von Erfolg gekrönt sein, werde ich euch natürlich informieren.

Mit freundlichen Grüßen
Sascha Sebastian Wieth
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

jojo wrote: 29 Aug 2018, 15:22 OTRS 5 läuft auch mit einer kaputten Datenbank. Das Migrationsscript macht nichts kaputt, ich habe schon mehrere TB an Daten migriert.

Ich empfehle Euch daher dringend professionellen Support einzukaufen.
Wir haben auch schon "TB an Daten migriert". Aber bei der Migration 5 -> 6 scheitert das nun beim letzten, entscheidenden Schritt: Übergang zur neuen Article-Tabelle.

Der "professionelle Support" von OTRS weigert sich, uns Support für die Community-Edition Version 6 zu verkaufen und ignoriert auch konkrete Bitten, den Fehler kostenplichtig zu beheben.

Stattdessen verkauft man uns Cloud-Lösungen. Sehr unlustig, wenn man selber Rechenzentrumsbetreiber ist. Noch unlustiger, wenn man Behördenkunden hat, denen DSGVO wichtig ist.

Ich habe jetzt von mehreren Seiten gehört, dass eine Migration von OTRS 5 -> OTRS 6 mit dem mitgelieferten Update-Script fehlschlägt. Und zwar mit exakt den Meldungen, Fehlern und Erkenntnissen, wie ich sie geschildert habe. Alle Artikel sind vorhanden, aber werden nicht migriert. Ergebnis ist ein unbrauchbarer Datenbestand.

Das ist extrem unbefriedigend.

Fazit:
- Wir werden OTRS 6 aufsetzen, einen Cut machen (also bei 0 anfangen) und das alte OTRS mit einem anderen Hostnamen als Archiv weiter betreiben.
- Wir werden dann *ein neues* Produkt suchen, da OTRS 6 ja bald gar nicht mehr unterstützt wird. Und ohne Sicherheitsupdates geht da gar nichts.
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

Hallo,

Sicherheitsupdates wird es auch für die ((OTRS Community Edition)) geben. Migrationen schlagen üblicherweise fehl weil die Datenbank nicht "sauber" ist und hier manuell eingegriffen werden muss. Dazu braucht man entsprechendes Fachwissen über den OTRS Core. Das Script läuft fehlerfrei durch, wenn die Datenbank keine Fehler wirft.

Support gibt es nur für OTRS Anwender (OTRS kann auch selbst gehostet werden, es gibt nicht nur managed Lösungen) und nicht für Anwender der (OTRS Community Edition)), das ist richtig.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by wurzel »

Hi,
millenseer wrote: 28 Nov 2018, 10:48
Ich habe jetzt von mehreren Seiten gehört, dass eine Migration von OTRS 5 -> OTRS 6 mit dem mitgelieferten Update-Script fehlschlägt. Und zwar mit exakt den Meldungen, Fehlern und Erkenntnissen, wie ich sie geschildert habe. Alle Artikel sind vorhanden, aber werden nicht migriert. Ergebnis ist ein unbrauchbarer Datenbestand.

Das ist extrem unbefriedigend.
Die OTRS6 Migration schlägt in der Regel nicht fehl. Ich habe sicher ein paar Dutzend ohne Probleme migriert. Auch von der 3er hoch.
millenseer wrote: Fazit:
- Wir werden OTRS 6 aufsetzen, einen Cut machen (also bei 0 anfangen) und das alte OTRS mit einem anderen Hostnamen als Archiv weiter betreiben.
- Wir werden dann *ein neues* Produkt suchen, da OTRS 6 ja bald gar nicht mehr unterstützt wird. Und ohne Sicherheitsupdates geht da gar nichts.
Zu eins: Kannste machen. Is halt dann kagge :D
Zu zwei: das ist quatsch. OTRS6 wird sehr wohl noch mit (Sicherheits-)Updates versorgt.

viele Grüße
Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
reneeb
Znuny guru
Posts: 5018
Joined: 13 Mar 2011, 09:54
Znuny Version: 6.0.x
Real Name: Renée Bäcker
Company: Perl-Services.de
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by reneeb »

Es gibt ja noch mehr Unternehmen, die Support gegen Bezahlung anbieten. Schau doch mal bei Znuny vorbei oder i-cron.

Sicherheitsupdates wird es auch für OTRS6 weiterhin geben.
Perl / Znuny development: http://perl-services.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Woher nehmt ihr die (gesicherte) Informationen, dass es zu OTRS 6 noch weiterhin Security-Updates geben wird?
Uns wurde von OTRS gegenteiliges berichtet.
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by wurzel »

Hi,

kannst Du bitte Deine Informationsquelle von Seiten OTRS nennen? Dann haken wir da mal nach.


https://otrs.com/de/kaufen/leistungspakete/

unterstützte Releases: letzten 2

Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by jojo »

millenseer wrote: 28 Nov 2018, 11:37 Woher nehmt ihr die (gesicherte) Informationen, dass es zu OTRS 6 noch weiterhin Security-Updates geben wird?
Uns wurde von OTRS gegenteiliges berichtet.
Siehe meine Signatur, ich arbeite für den Hersteller. Und ich habe auch das entsprechende Ticket gelesen, dort ist nichts gegenteiliges zu lesen.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Nur dass hier keine Missverständnisse auftreten: Ich spreche von der Community Version von OTRS; selbst gehostet.
reneeb
Znuny guru
Posts: 5018
Joined: 13 Mar 2011, 09:54
Znuny Version: 6.0.x
Real Name: Renée Bäcker
Company: Perl-Services.de
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by reneeb »

https://community.otrs.com/
Will bug fixes be available to ((OTRS)) Community Edition users?
Yes. We will provide bug fixes for the most recent version of the ((OTRS)) Community Edition until there is a new publicly-available major release.
Perl / Znuny development: http://perl-services.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
millenseer
Znuny newbie
Posts: 17
Joined: 24 Nov 2017, 14:45
Znuny Version: 5.0.20

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by millenseer »

Fein, das sind beruhigende Nachrichten.
Erklärt aber immer noch nicht, warum eine OTRS 5 Datenbank, mit der wir definitiv nichts angestellt haben, sich nicht nach OTRS 6 migrieren lässt. Und zwar nachvollziehbar auf verschiedenen Instanzen bei verschiedenen Systemen.
reneeb
Znuny guru
Posts: 5018
Joined: 13 Mar 2011, 09:54
Znuny Version: 6.0.x
Real Name: Renée Bäcker
Company: Perl-Services.de
Contact:

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by reneeb »

Habt ihr irgendwelche Erweiterungen installiert oder selbst Änderungen vorgenommen? Auf welchen Wegen wurden schon Tickets/Artikel gelöscht?
Perl / Znuny development: http://perl-services.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
tcpdumb
Znuny newbie
Posts: 2
Joined: 04 Dec 2018, 15:54
Znuny Version: 6.0.x
Real Name: Lukas Th. Hey
Company: AöR mit drei Buchstaben

Re: Upgradefehler 5.0.26 -> 6.0.7

Post by tcpdumb »

Nabend!

Nach dem heutigen...sehr sportlichen Tag zu diesem Problem, bei dem mir dieser Thread sehr geholfen hat, meine zwei Cent zum Thema Datenbankbereinigung:

Also, wenn man bei der OTRS-Datenbank auf Stand 5.0.x in Tabelle `users` guckt, wo in der Reihenfolge IDs fehlen, kriegt man auch raus, welche IDs von anderen Admins geloescht wurden, anstatt die Benutzer nur ungueltig zu schalten (best practice: ungueltig statt loeschen). In meinem heutigen Fall waren's 4,6,8,9,12,16 :wink: Mit der Angabe kann ich unmoeglich gegen die DSGVO oder das BDSG verstossen :D

Mit den IDs dann durch mehr oder weniger alle Tabellen pfluegen und nach create_by/change_by Spalten suchen. Damit hat man schonmal viel erschlagen. Bei den Tabellen article* und ticket* muss man dann noch nach Eintraegen suchen, wo ne user_id-Spalte existiert. Ich hab frecherweise alles der UID 1 zugeschanzt was create/change im Spaltennamen hatte oder wo ein Ticket herrenlos war und habe den Rest geloescht:

UPDATE article SET create_by=1 change_by=1 WHERE create_by=4 OR change_by=4;
[...]
DELETE FROM group_user WHERE user_id=4;
DELETE FROM personal_queues WHERE user_id=4;
DELETE FROM user_preferences WHERE user_id=4;
[...]

(Alle Statements beispielhaft ohne Gew(a)ehr und ohne Anrecht auf Vollstaendigkeit!)

Obacht: Bei einigen Tabellen heissts create_by / change_by, bei anderen Tabellen heissts created_by / changed_by. Man sollte die "Struktur" der OTRS-Datenbank etwas kennen, sonst zerschiesst man was oder verzweifelt an Statements, die in einen Fehler rauschen. Und wie immer gilt: Zwei Backups sind besser als ein Backup! Nach jedem Meilenstein (bingo?) mindestens eines, um im Falle des Falles continuity zu haben (jetzt aber: bingo!)

Jedenfalls: Nachdem ich die o.g. UIDs vermutlich sogar komplett aus allen Tabellen der Datenbank geworfen hatte, lief sogar das DBUpdate-to-6.pl Script durch :-)

Tipps:
  • Ich mache zu 99,99% cold-backups von /var/lib/mysql, damit ich problemlos und schnell zurueckrollen kann. Und das inklusive allen Triggern, Prozeduren usw. etc. pp..
  • /opt/otrs wird zu /opt/otrs-alt oder /opt/otrs-5.0.12 verschoben. otrs-6.0.14 zu otrs. Sinngemaess beim rollback dann erst otrs zu otrs-6.0.14, dann otrs-5.0.12 zu otrs
  • Es werden keine .tar.gz/.zip/.sonstwas geloescht, bevor man komplett fertig ist, falls man ein `diff` von den original Sourcen und den angepassten Dateien machen muss (Wer kein Linuxer ist, diff zeigt 'differences')
  • Das Support Assessment von OTRS, zeigt verwaiste Tickets an, wenn ich mich recht erinnere :-)
  • Ich hasse Umlaute :-P
Vielleicht ist das ja mal eine Hilfe fuer wen, der auch hinter anderen Admins aufraeumen muss.
Post Reply