Migration WIN-3.0.10 auf RHEL7-5.0.15.01

[Wolfpack]

Hallo zusammen,

jetzt bin ich neu hier und hab gleich ein Mammut-Projekt vor...

Ein bisschen was zum Hintergrund:
Wir haben seit einigen Jahren OTRS auf Windows-Basis im Einsatz. Nachdem mit 3.0.10 der Windows-Support zu Ende war haben wir (leider) nicht reagiert und das System auf der 3.0.10 einfach weiterlaufen lassen. Nennt es Feigheit, sich mit Linux zu beschäftigen oder wie auch immer...
Inzwischen ist das System aber so betagt, dass ein Umstieg auf eine neue Umgebung (RHEL7/CentOS7) notwendig ist.
Der neue Server läuft, OTRS läuft, ich habe auf beiden Maschinen (alt und neu) direkten Zugriff auf die Datenbank (MySQL).

Jetzt kommt aber die Masterfrage:
Wie bringe ich den Inhalt (Tickets, Einstellungen, User, Anhänge, etc.) auf die neue Maschine UND auf die aktuelle Version?

Mein erster Blick und meine ersten Versuche haben mir gezeigt, dass sich die Datenbankstruktur wohl geändert hat.
Die nächste Frage wäre, die bekomme ich die Attachments aus den Tickets in das neue System (=> Link-Anpassung?).
Und vor allem: an welche Dinge hab ich noch gar nicht gedacht?

Gibt es hierfür Tools? Oder jemanden, der Erfahrung mit einer solchen Migration hat und empfehlbar + buchbar wäre?

Danke euch schon mal & frohe Weihnachten!!!

[wurzel]

Hi,

am Besten auf RHEL mal ein neues 3.0.x aufsetzen und den installer.pl laufen lassen.
Danach das /opt/otrs umbenennen nach otrs-3.0.x

Danach machst Du das ganze auch für 3.1.x
3.2.x
3.3.x
4.0.x
5.0.x

Wenn Du alle Versionen auf der Kiste lauffähig hattest kannst Du einfach
die DB dumpen und auf dem neuen System restoren
Deine Config Dateien mitnehmen und den klassischem Migrationspfad beginnend von Deinem 3.0.x Verzeichnis folgen.

viele Grüße
Flo

[reneeb]

Du musst nicht nur auf ein anderes Betriebssystem wechseln, sondern auch die ganzen Upgrade-Zwischenschritte machen: https://otrs.github.io/doc/manual/admin ... ading.html

Also Upgrade auf 3.1.x, 3.2.x, 3.3.x, 4.0.x, 5.0.x

Bei jedem dieser Zwischenschritte gibt es Hilfsskripte, die die notwendigen Änderungen an Datenbank und ggf. Konfig vornehmen.

Was Du beachten musst: Wenn ihr Addons installiert habt, müssen die auch angepasst werden.

Wenn ihr Hilfe braucht, könnt ihr z.B. bei i-cron ( http://i-cron.de/ ) nachfragen. Eine Liste mit noch mehr Dienstleistern gibt es auch unter viewtopic.php?f=104&t=8247&p=89605#p32500

[wurzel]

Hi,

hier hab' ich mein Verfahren nochmal gefunden
viewtopic.php?f=35&t=33569&p=136637&hil ... de#p136637

Viele Grüße
Flo

[Wolfpack]

Hallo ihr Beiden,

herzlichen Dank für eure schnellen und hilfreichen Antworten!
Habe gar nicht damit gerechnet, dass sich hier vor Weihnachten noch was tut und dann auch gleich noch so hilfreich!

Ich denke, damit kann ich was anfangen. Es sieht nur nach einer Menge Arbeit und Zeit aus.
Aber wer sich lange vor der (Upgrade-)Arbeit drückt, hat die Arbeit eben am Ende gebündelt...
Werde das wohl auf die Agenda für das neue Jahr schreiben.
Wenn ich es geschafft habe, werde ich berichten. Wenn ich verzweifelt habe, ebenfalls!

[Wolfpack]

Hallo zusammen,

jetzt möchte ich schon mal meine zwischenzeitlichen Fortschritte berichten, nur an einer Sache beisse ich mir noch die Zähne aus.

Folgenden Weg habe ich genommen:
- Update mit Windows Installer 3.010 auf 3.1.21
- Update mit Windows Installer 3.1.21 auf 3.2.17
- Update mit Windows Installer 3.2.17 auf 3.3.13
- Migration 3.3.13 Windows auf 3.3.13 Linux/CentOS7 (nicht unterstütztes CentOS6-RPM mit YUM auf CentOS7 installiert, manuelle Anpassung der Apache-Berechtigung)
dabei mitgenommen:
- Datenbank exportiert & wieder importiert
- Umstellung auf MySQL-InnoDB
- Kernel/Config.pm (manuelle Überführung in die neue config.pm)
- Kernel/Config/GenericAgent.pm
- Kernel/Config/Files/ZZZAuto.pm (Kopie, Anpassung der Pfade)
- var/log/TicketCounter.log
- var/Articles/*
danach:
- Update auf 4.0.20 (mit CentOS7 unterstütztem otrs-4.0.20-01.noarch.rpm über YUM) nach Anleitung https://otrs.github.io/doc/manual/admin ... ading.html)
- Update auf 5.0.15 (mit CentOS7 unterstütztem otrs-5.0.15-01.noarch.rpm über YUM) nach Anleitung https://otrs.github.io/doc/manual/admin ... ading.html)


...so weit, so gut. Ticketsystem läuft, es wird alles angezeigt.
Auch die Tickets werden aus dem Postfach abgeholt und eingepflegt und der ABSENDER bekommt seine Mail über die Erstellung.
Allerdings gehen keine Benachrichtigungen mehr an die Agenten raus. Weder über die Ticketerstellung, noch beim Verschieben in den Queues und wahrscheinlich auch nicht bei der Eskalation.
Ich habe schon an den verschiedensten Stellen gesucht:
- Agenten haben die Queues ausgewählt
- In den Ticket-Benachrichtigungen sieht auch alles gut aus, dort testweise neben den neuen Nachrichten auch noch testweise die überführten alten Nachrichten auf gültig gesetzt
- Im Core::Sendmail gestöbert

Die Fakten, die ich für mich festgehalten habe:
- In Version 4.0.20 funktionierte es noch, in Version 5.0.15 nicht mehr
- Die Mail an den Absender des Tickets geht raus, aber keine Nachrichten an die Agenten
- OTRS versucht auch nicht mit dem Mailserver zu kommunizieren

Könnte mir einer von euch auf die Sprünge helfen oder weitere Denk-/Suchansätze geben?

Danke euch!

[RStraub]

Gratuliere erstmal dazu

Zu Version 5 sind die Ticket Benachrichtigungen überarbeitet worden. Schau mal in Admin -> "Ticket-Benachrichtigungen". Dort sollten deine alten Notifications ausgegraut (= ungültig) und die neuen Standardwerte angezeigt werden. Sind dort bei euch gültige Benachrichtigungen zu sehen ?

[Wolfpack]

Dankeschön!

Ja, das hatte ich auch schon gefunden. Dort sind die "neuen" Benachrichtigungen alle aktiv und ich habe auch mal testweise die "alten" ausgegrauten wieder auf gültig gesetzt - leider ohne Ergebnis.

Vielleicht noch als Nachtrag: Ich habe zwar keine Ahnung, aber wenn ich eine Glaskugel fragen würde, könnte das mit den Jobs zusammenhängen. Seit dem Update auf 5.0 haut er mir alle 5 Minuten in var/mail/root solche Meldungen rein und ich bin mir nicht sicher woher:

Code: Select all

From root@  Thu Jan 12 17:15:01 2017
Return-Path: <root@>
X-Original-To: root@localhost
Delivered-To: root@localhost.
Received: by  (Postfix, from userid 0)
	id 7F2FA60C4E11; Thu, 12 Jan 2017 17:15:01 +0100 (CET)
From: "(Cron Daemon)" <root@>
To: root@localhost
Subject: Cron <root@> $HOME/bin/otrs.Scheduler.pl -w 1 >> /dev/null
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated
Precedence: bulk
X-Cron-Env: <XDG_SESSION_ID=33>
X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/0>
X-Cron-Env: <LANG=de_DE.UTF-8>
X-Cron-Env: <MAILTO=root@localhost>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20170112161501.7F2FA60C4E11@>
Date: Thu, 12 Jan 2017 17:15:01 +0100 (CET)

/bin/sh: /root/bin/otrs.Scheduler.pl: Datei oder Verzeichnis nicht gefunden

[RStraub]

Huhu.

Du scheinst noch einen Cronjob zu haben der die Scheduler.pl aufrufen möchte. Diese gibt es nicht mehr (und wurde durch andere Scheduler abgelöst).

Schau mal unter "crontab -e" oder ~otrs/var/cron nach, ob dort noch Einträge bzgl. des Scheduler sind.

[Wolfpack]

Hallo,

ich hab mal geschaut, im otrs/var/cron sind nur die aaa_base und der otrs_daemon drin.
Im otrs_daemon ist kein Verweis auf das aufgerufene Script zu finden.
Im regulären System-crontab (meintest du den mit "crontab -e"?) ist keinerlei Eintrag.

Irgendwie hab ich das Gefühl, ich habe immer noch zu viel Müll mit migriert und dass darin die Ursache liegt.
Vor allem die ZZZAuto.pm ist riesig im Gegensatz zur Default. Ich hab mal ein Sniplet angefügt unten.
Da stelle ich mir die Frage: Sollte ich die ZZZAuto einfach lassen und mit der Default wieder anfangen?
Zur Zeit setze ich mit meinen Tests immer wieder bei der Migration WIN-3.3.13 auf LINUX-3.3.13 als ersten Schritt an.

Eine Verhaltensfrage würde mir meine Gedanken auch erleichtern:
Würde OTRS 5 in der Default-Installation bei neuen Tickets eine Benachrichtigung an Agenten schicken?
Meine Frage zielt darauf hin ab, ob ich durch die Migration aktiv eine Funktion abgewürgt habe oder ob eine Funktion durch die Migration nicht aktiv angeschalten wurde.

Code: Select all

# OTRS config file (automatically generated)
# VERSION:1.1
package Kernel::Config::Files::ZZZAuto;
use strict;
use warnings;
use utf8;
sub Load {
    my ($File, $Self) = @_;
$Self->{'PostMaster::PreFilterModule::NewTicketReject::Body'} =  'Dear Customer,

Unfortunately we could not detect a valid ticket number
in your subject, so this email can\'t be processed.

Please create a new ticket via the customer panel.

Thanks for your help!

 Your Helpdesk Team
';
$Self->{'PostmasterFollowUpStateClosed'} =  'open';
$Self->{'PostmasterDefaultQueue'} =  'Administration';
$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'StateDefault'} =  'new';
$Self->{'Ticket::StateAfterPending'} =  {
  'new' => 'new'
};
$Self->{'Ticket::Frontend::AgentTicketForward'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::ComposeReplaceSenderAddress'} =  '1';
$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketBounce'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketPending'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Title'} =  '1';
$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Priority'} =  '1';
$Self->{'Ticket::Frontend::AgentTicketNote'}->{'InformAgent'} =  '1';
$Self->{'Ticket::Frontend::AgentTicketNote'}->{'State'} =  '1';
$Self->{'Ticket::Frontend::AgentTicketClose'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'StateDefault'} =  'new';
$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}->{'State'} =  'new';
$Self->{'Ticket::Frontend::OverviewSmall'}->{'ColumnHeader'} =  'TicketTitle';
$Self->{'Ticket::StorageModule'} =  'Kernel::System::Ticket::ArticleStorageFS';
$Self->{'Ticket::Service'} =  '1';
$Self->{'Frontend::Module'}->{'AdminGenericInterfaceMappingSimple'} =  {
  'Description' => 'Admin',
  'Group' => [
    'admin'
  ],
  'Loader' => {
    'CSS' => [
      'Core.Agent.Admin.GenericInterface.css'
    ],
    'JavaScript' => [
      'Core.Agent.Admin.GenericInterfaceMappingSimple.js'
    ]
  },
  'Title' => 'GenericInterface Webservice Mapping GUI'
};

[Wolfpack]

Hallo zusammen,

es ist vollbracht!

Der Server läuft endlich stabil auf 5.0.15. Der Wurm war irgendwo in der alten Config drin. Deshalb hab ich die Config komplett dort gelassen wo sie war und nur die Datenbank in die neue Installation mitgenommen.

Falls jemand mal in eine ähnliche Verlegenheit kommen sollte wie ich - hier die Anleitung, um eine 3.3.13er-Windows-Installation auf einen CentOS7-Server (VirtualBox) zu bekommen:

Code: Select all

# Installiere Repository
yum -y install epel-release
 
# Entferne Microcode-Update durch CentOS für Virtualbox
yum -y remove microcode_ctl
 
# Update alle Komponenten
yum -y update
 
# Installiere MariaDB
yum -y install mariadb-server mariadb
 
### Anpassung /etc/my.cnf
### max_allowed_packet = 20M
### query_cache_size = 32M
### innodb_log_file_size = 256M
 
# Starte MariaDB, konfigurieren und als Systemdienst hinzufügen
systemctl start mariadb
mysql_secure_installation
systemctl enable mariadb.service
 
# Installiere Apache, PHP & PHPmyAdmin
yum -y install httpd
yum -y install php
yum -y install phpmyadmin
systemctl enable httpd
 
# Manuelle Anpassung von
#
# etc/php.ini
# upload_max_filesize = 100M
# post_max_size = 100M
# date.timezone = Europe/Berlin
#
# etc/httpd/conf.d/phpmyadmin.conf
# <Directory /usr/share/phpMyAdmin/>
# Require all granted
# Allow from All
#
# etc/phpmyadmin/config.inc.php
# $cfg['Servers'][$i]['auth_type'] = 'http';
systemctl restart httpd.service
 
# Firewall Web-Services hinzufügen und SecurityPolicy ausschalten
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-service=smtp
firewall-cmd --reload\\
# Anpassung /etc/selinux/config
# SELINUX=disabled
# durch das Umbenennen auf dem Server bricht die SFTP-Verbindung zusammen => reboot => Upload => reboot
 
# WGET-Downloader installieren und OTRs holen
yum -y install wget\\
wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/6/otrs-3.3.13-02.noarch.rpm
yum -y install otrs-3.3.13-02.noarch.rpm
 
# Benötigte Perl-Module nachinstallieren und checken
yum -y install "perl(Crypt::SSLeay)" "perl(Encode::HanExtra)" "perl(GD::Text)" "perl(GD::Graph)" "perl(GD::Graph::lines)" "perl(GD::Text::Align)" "perl(JSON::XS)" "perl(Mail::IMAPClient)" "perl(Net::LDAP)" "perl(Net::SSL)" "perl(PDF::API2)" "perl(Text::CSV_XS)"
yum -y install "perl(Apache2::Reload)" "perl(Crypt::Eksblowfish::Bcrypt)" "perl(Encode::HanExtra)" "perl(JSON::XS)" "perl(Mail::IMAPClient)" "perl(ModPerl::Util)" "perl(Text::CSV_XS)" "perl(YAML::XS)"
/opt/otrs/bin/otrs.CheckModules.pl
 
# Einfügen der zzz_otrs.conf aus Version 5.0.15 in /etc/httpd/conf.d für korrekten Verzeichniszugriff
systemctl restart httpd.service
# Ausführen der Installer.pl und Basisinstallation mit Datenbankpasswort
# FQDN & Systemmail setzen

# Datenbank aus Windows als .SQL exportieren (MySQL Workbench)
# Datenbank über phpmyadmin über die otrs-Datenbank "drüberimportieren"
# Datenbanktabellen auf InnoDB umstellen mit phpmyadmin:
# Datenbankserver-SQL ausführen
SET @DATABASE_NAME = 'otrs';
SELECT  CONCAT('ALTER TABLE `', table_name, '` ENGINE=InnoDB;') AS sql_statements
FROM    information_schema.tables AS tb
WHERE   table_schema = @DATABASE_NAME
AND     `ENGINE` = 'MyISAM'
AND     `TABLE_TYPE` = 'BASE TABLE'
ORDER BY table_name DESC;
# Das Ergebnis erneut als SQL in der Datenbank 'otrs' durchlaufen lassen.
 
# Upgrade auf OTRS 4.0.20
systemctl stop crond
systemctl stop postfix
systemctl stop httpd
wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-4.0.20-01.noarch.rpm
yum -y install otrs-4.0.20-01.noarch.rpm
/opt/otrs/bin/otrs.CheckModules.pl
cd /opt/otrs/
bin/otrs.CheckDB.pl
cat scripts/DBUpdate-to-4.mysql.sql | mysql -p -f -u root otrs
su -c "scripts/DBUpdate-to-4.pl" -s /bin/bash otrs
su -c "bin/otrs.RebuildConfig.pl" -s /bin/bash otrs
su -c "bin/otrs.DeleteCache.pl" -s /bin/bash otrs
systemctl start crond
systemctl start postfix
systemctl start httpd
su -c "/opt/otrs/bin/Cron.sh start" -s /bin/bash otrs
reboot
 
# Upgrade auf OTRS 5.0.15
systemctl stop crond
systemctl stop postfix
systemctl stop httpd
wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-5.0.15-01.noarch.rpm
yum -y install otrs-5.0.15-01.noarch.rpm
/opt/otrs/bin/otrs.CheckModules.pl
cd /opt/otrs/
cat scripts/DBUpdate-to-5.mysql.sql | mysql -p -f -u root otrs
su -c "bin/otrs.Console.pl Maint::Database::Check" -s /bin/bash otrs
su -c "scripts/DBUpdate-to-5.pl" -s /bin/bash otrs
cd /opt/otrs/
su -c "bin/otrs.Console.pl Maint::Config::Rebuild" -s /bin/bash otrs
su -c "bin/otrs.Console.pl Maint::Cache::Delete" -s /bin/bash otrs
systemctl start crond
systemctl start postfix
systemctl start httpd
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
  
# var/article auf den Server kopieren und danach die Besitzerschaft an otrs übergeben
chown -R otrs:apache /opt/otrs/var/article
# Zugriffsrechte für article neu setzen
/opt/otrs/bin/otrs.SetPermissions.pl --otrs-user=otrs --web-user=apache --otrs-group=apache --web-group=apache /opt/otrs