Hallo zusammen,
aktuell verwenden wir OTRS5s in Verbindung mit KIX4OTRS. Da dieses vermutlich nicht mehr auf OTRS6 angepasst wird, denken wir nun darüber nach wie wir weiter verfahren wollen. Die Optionen sind ein Betrieb auf dem letzten Patchlevel von OTRS und KIX4OTRS oder ein Umzug auf OTRS6 ohne Kix.
Gerade zu zweiterer Variante wollte ich mich mal erkundigen, ob das jemand mit der aktuellen Betaversion schon probiert hat? Läuft der Umzug einer KIX4OTRS DB auf OTRS6 sauber durch? Sind neben dem offensichtlichen Wegfallen einiger Funktionalitäten sonstige Einschränkungen/Probleme/etc. zu erwarten?
Viele Grüße
RoH1
Umstieg auf OTRS6
Umstieg auf OTRS6
OTRS: 6.0.4
Ubuntu Server 14.04 LTS
Ubuntu Server 14.04 LTS
Re: Umstieg auf OTRS6
Hallo,
Du müsstest vorher alle KIX Module sauber entfernen. Und dann einfach mal probieren....
Ein festhalten an der OTRS5 wird nicht ewig möglich sein, da es irgendwann keine Bugfixes und Security Updates mehr gibt
Du müsstest vorher alle KIX Module sauber entfernen. Und dann einfach mal probieren....
Ein festhalten an der OTRS5 wird nicht ewig möglich sein, da es irgendwann keine Bugfixes und Security Updates mehr gibt
"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
"Testing": ((OTRS Community Edition)) and git Master
Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
-
- Znuny wizard
- Posts: 315
- Joined: 09 Jan 2007, 15:24
- Znuny Version: OTRS 5.0.x
- Real Name: Torsten
- Company: c.a.p.e. IT GmbH
- Location: Chemnitz
- Contact:
Re: Umstieg auf OTRS6
Hallo,RoH1 wrote:Hallo zusammen,
aktuell verwenden wir OTRS5s in Verbindung mit KIX4OTRS. Da dieses vermutlich nicht mehr auf OTRS6 angepasst wird, denken wir nun darüber nach wie wir weiter verfahren wollen. Die Optionen sind ein Betrieb auf dem letzten Patchlevel von OTRS und KIX4OTRS oder ein Umzug auf OTRS6 ohne Kix.
Gerade zu zweiterer Variante wollte ich mich mal erkundigen, ob das jemand mit der aktuellen Betaversion schon probiert hat? Läuft der Umzug einer KIX4OTRS DB auf OTRS6 sauber durch? Sind neben dem offensichtlichen Wegfallen einiger Funktionalitäten sonstige Einschränkungen/Probleme/etc. zu erwarten?
Viele Grüße
RoH1
aus meiner Sicht gibt es zweieinhalb Möglichkeiten:
(1) Wie Jens schon schrie, kannst du alle Nicht-OTRS-AG-Pakete deinstallieren und ein ganz "normales" Upgrade auf OTRS6 durchführen. So manche Funktion wird (je nach Nutzung bei Euch) entfallen, aber dafür die OTRS6-Neuerungen dazu kommen.
(2a) Du kannst auf KIX16 oder eher KIX17 wechseln.
(2b) Alternativ auf OTRS5+KIX4OTRS bleiben bis KIX2018 kommt und dann (via KIX2017) auf KIX2018 gehen. KIX2018 wird ein signifikanter Sprung - sowohl technisch als auch aus Nutzersicht (GUI). Solange sollte auch OTRS5 noch supported werden.
vG, T.
--
KIX 17.x (fork of OTRS)
Professional KIX-, or OTRS-integration, development and consulting by c.a.p.e. IT - http://www.cape-it.de
For questions and hints regarding KIX(4OTRS) please go to https://forum.kixdesk.com/
Bei Fragen und Hinweisen zu KIX(4OTRS) bitte an https://forum.kixdesk.com/ wenden.
KIX 17.x (fork of OTRS)
Professional KIX-, or OTRS-integration, development and consulting by c.a.p.e. IT - http://www.cape-it.de
For questions and hints regarding KIX(4OTRS) please go to https://forum.kixdesk.com/
Bei Fragen und Hinweisen zu KIX(4OTRS) bitte an https://forum.kixdesk.com/ wenden.
-
- Znuny advanced
- Posts: 108
- Joined: 29 Feb 2008, 16:30
- Znuny Version: 3.x 4.x 5.x 6.x
- Real Name: Oliver Oltmanns
- Company: i-cron
- Location: Köln
- Contact:
Re: Umstieg auf OTRS6
Leider wird das KIX4OTRS nicht sauber deinstalliert.
Nach entfernen des KIX4OTRS Modules bleiben weiterhin Fragmente bestehen, die Fehler im Log hervorrufen.
Diese Fehler treten nur bei Aufruf von TIckets "vor" der Entfernung des Modules auf, da diese mit "link_relation" zu link_object" und link_type versehen wurden, die es nicht mehr gibt.
Diese Einträge würde ich vor einem Major Upgrade auf OTRS 6 entfernen.
ACHTUNG!: Bevor wir unwiderrufliche Manipulationen an der Datenbank vornehmen, sollten wir IMMER ein Backup anfertigen und vorab die Operationen auf einem Test-System ausgiebig auf Funkion überprüfen!
Zunächst würde ich die Datenbank Zombies kix_* entfernen, wie sie noch nach der Datenbank nach der Deinstallation des KIX4OTRS Modules verblieben sind.
Unter der Tabelle link_objects stehen weiterhin Einträge, auf die Tickets mit Ihren gespeicherten Eigenschaften in der Tabelle link_relations verweisen.
Nach dem wir die Datenbank von den nicht mehr vorhandenen link_object und link_type Einträge bereinigt haben, müssen die Verweise nun in der link_relation (Link Beziehung) bereinigt werden. Ansonsten wird jedesmal, wenn ein Ticket im OTRS Frontend aufgerufen wird, welches link_relation Kriterien zugewiesen bekommen hat (type_id) einen Fehler im Log produzieren, da es diesen Verweis nicht finden kann.
Wie solche:
Auf der Datenbank können wir mit dem SQL Befehl die link_type Referenzierungen, die wir nicht mehr benötigen ebenfalls entfernen z.B.:
DELETE FROM link_relation WHERE link_relation.type_id = '3';
Weitere ID´s können so ebenfalls entfernt werden.
Gruß
oliver
Nach entfernen des KIX4OTRS Modules bleiben weiterhin Fragmente bestehen, die Fehler im Log hervorrufen.
Diese Fehler treten nur bei Aufruf von TIckets "vor" der Entfernung des Modules auf, da diese mit "link_relation" zu link_object" und link_type versehen wurden, die es nicht mehr gibt.
Diese Einträge würde ich vor einem Major Upgrade auf OTRS 6 entfernen.
ACHTUNG!: Bevor wir unwiderrufliche Manipulationen an der Datenbank vornehmen, sollten wir IMMER ein Backup anfertigen und vorab die Operationen auf einem Test-System ausgiebig auf Funkion überprüfen!
Zunächst würde ich die Datenbank Zombies kix_* entfernen, wie sie noch nach der Datenbank nach der Deinstallation des KIX4OTRS Modules verblieben sind.
Unter der Tabelle link_objects stehen weiterhin Einträge, auf die Tickets mit Ihren gespeicherten Eigenschaften in der Tabelle link_relations verweisen.
Nach dem wir die Datenbank von den nicht mehr vorhandenen link_object und link_type Einträge bereinigt haben, müssen die Verweise nun in der link_relation (Link Beziehung) bereinigt werden. Ansonsten wird jedesmal, wenn ein Ticket im OTRS Frontend aufgerufen wird, welches link_relation Kriterien zugewiesen bekommen hat (type_id) einen Fehler im Log produzieren, da es diesen Verweis nicht finden kann.
Wie solche:
Code: Select all
ERROR: OTRS-CGI-42 Perl: 5.16.3 OS: linux Time: Sat Feb 18 20:58:44 2017
Message: Linktype 'Agent' does not exist!
RemoteAddress: xxxx
RequestURI: /otrs/index.pl?Action=AgentTicketZoom;TicketID=2419
Traceback (11116):
Module: Kernel::System::LinkObject::TypeGet Line: 1807
Module: Kernel::System::LinkObject::LinkList Line: 1068
Module: Kernel::System::LinkObject::LinkListWithData Line: 1201
Module: Kernel::Modules::AgentTicketZoom::MaskAgentZoom Line: 1833
Module: Kernel::Modules::AgentTicketZoom::Run Line: 643
Module: Kernel::System::Web::InterfaceAgent::Run Line: 1054
Module: ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler Line: 40
Module: (eval) (v1.99) Line: 207
Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
Module: ModPerl::Registry::handler (v1.99) Line: 32
[Sat Feb 18 20:58:44 2017] -e: Use of uninitialized value $TypeData{"Name"} in hash element at /opt/otrs//Kernel/System/LinkObject.pm line 1072.
[Sat Feb 18 20:58:44 2017] -e: Use of uninitialized value $TypeData{"Name"} in hash element at /opt/otrs//Kernel/System/LinkObject.pm line 1075.
ERROR: OTRS-CGI-42 Perl: 5.16.3 OS: linux Time: Sat Feb 18 20:58:44 2017
Message: Linktype 'Customer' does not exist!
RemoteAddress: xxxx
RequestURI: /otrs/index.pl?Action=AgentTicketZoom;TicketID=2419
Traceback (11116):
Module: Kernel::System::LinkObject::TypeGet Line: 1807
Module: Kernel::System::LinkObject::LinkList Line: 1068
Module: Kernel::System::LinkObject::LinkListWithData Line: 1201
Module: Kernel::Modules::AgentTicketZoom::MaskAgentZoom Line: 1833
Module: Kernel::Modules::AgentTicketZoom::Run Line: 643
Module: Kernel::System::Web::InterfaceAgent::Run Line: 1054
Module: ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler Line: 40
Module: (eval) (v1.99) Line: 207
Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
Module: ModPerl::Registry::handler (v1.99) Line: 32
[Sat Feb 18 20:58:44 2017] -e: Use of uninitialized value $TypeData{"Name"} in hash element at /opt/otrs//Kernel/System/LinkObject.pm line 1072.
[Sat Feb 18 20:58:44 2017] -e: Use of uninitialized value $TypeData{"Name"} in hash element at /opt/otrs//Kernel/System/LinkObject.pm line 1075.
ERROR: OTRS-CGI-42 Perl: 5.16.3 OS: linux Time: Sat Feb 18 20:58:44 2017
Message: Module Kernel/System/LinkObject/Person.pm not in @INC (/opt/otrs/Custom /opt/otrs/Kernel/cpan-lib /opt/otrs/ /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . /etc/httpd)
RemoteAddress: xxx
RequestURI: /otrs/index.pl?Action=AgentTicketZoom;TicketID=2419
Traceback (11116):
Module: Kernel::System::LinkObject::LinkListWithData Line: 1212
Module: Kernel::Modules::AgentTicketZoom::MaskAgentZoom Line: 1833
Module: Kernel::Modules::AgentTicketZoom::Run Line: 643
Module: Kernel::System::Web::InterfaceAgent::Run Line: 1054
Module: ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler Line: 40
Module: (eval) (v1.99) Line: 207
Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
Module: ModPerl::Registry::handler (v1.99) Line: 32
DELETE FROM link_relation WHERE link_relation.type_id = '3';
Weitere ID´s können so ebenfalls entfernt werden.
Gruß
oliver
i-cron OTRS IT-Service Management
https://i-cron.de
https://i-cron.de