OTRS umzug - Darstellungsprobleme HTML wird nicht korrekt dargestellt

[MAKUT]

Guten Morgen,

ich habe das große 'Vergnügen' eine uralte OTRS Version (3.0.16 - nicht meine Entscheidung also bitte nicht darüber diskutieren ) von einem Physikalischen auf einen Virutellen Server um zu ziehen.

Hier die Infos:
Beide Server laufen mit Win Server 2008 R2(siehe oben).
Die Tickets und Anhänge sind im filesystem gespeichert.

Ich hatte schon einmal das Vergnügen eines OTRS Umzuges und folgende Vorgehensweise hat sich als erfolgreich erwiesen:

Export der DB und des Filesystems
Kopieren des Unterordners OTRS ( OTRS/OTRS/xxx um die ganzen config Dateien und Tickets (var/article/xxx) mit zu bekommen.
Frische Installation auf dem neuen Server
Import der DB und einfügen der Tickets und Config Dateien

Mit den Pfaden sollte es keine Probleme geben da diese Identisch sind.
Auf beiden Servern ist die Installation über den selben Programmpfad erreichbar.

Das Ergebnis ist dieses mal nur leider etwas ernüchternd.
Nach dem ersten Durchlauf sind zwar alle Tickets,Queues,Agenten und Jobs übernommen worden und laufen, aber dafür funktioniert die Ticketdarstellung nicht ganz.

Alle Tickets werden im rohen Textformat dargestellt. Tags sind im Text verstreut, Links zu den Elementen finden sich am Ende des Tickets

Vielleicht habt ihr ja eine Idee. Die Einstellungen in der Sysconfig sind soweit ich das beurteilen kann alle korrekt übernommen worden. und somit identisch.


Danke im voraus

Gruß

[MAKUT]

Hier ist ein Beispielticket. Eine Mail von EBay. Alle auf Personen- oder Firmen bezogene Daten habe ich entfernt.

Code: Select all

      td.product-details-block{word-break:break-all}.threeColumns{width:140px
!important}.threeColumnsTd{padding:10px 20px
!important}.fourColumns{width:158px !important}.fourColumnsPad{padding: 0 18px
0 0 !important}.fourColumnsTd{padding:10px 0px
!important}.twoColumnSixty{width:360px !important}table{mso-table-lspace:0pt;
mso-table-rspace:0pt;}  

Neue Nachricht: Ich habe jetzt noch 2 Artikel geka...

[1]  

  Neue Nachricht von: [2]XYZ [3](24)  

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

[4]Antworten  

[5]Angebot aufrufen  

 Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.


[6]Prdukt XYZ
[7]  



[8]Angebot aufrufen  

  Machen Sie sich ein Bild vom Käufer [9]


[10]    

Nur Käufe bei eBay sind über die eBay-Käuferschutzprogramme abgesichert. Beim
Handelspartner nachzufragen, ob eine Transaktion außerhalb von eBay
abgeschlossen werden kann, ist nicht erlaubt.

E-Mail-Referenznummer:
[#XYZ]

Nachrichten an dieses Postfach werden nicht gelesen. Bitte antworten Sie
nicht auf diese Nachricht. Wenn Sie eine Frage haben, gehen Sie zu [11]Hilfe &
Kontakt.



Diese E-Mail haben Sie von der eBay Europe S.à r.l. erhalten, die den
eBay-Service über ihre Tochtergesellschaften bereitstellt. Wenn sich Ihr
Wohnsitz außerhalb der Europäischen Union befindet, lesen Sie die
Informationen zu Ihrem Vertragspartner bitte in den Allgemeinen
Geschäftsbedingungen nach.  

©2016 eBay Inc., eBay Europe S.à r.l. 22–24 Boulevard Royal, 2449, Luxemburg

  

[1] http:/ /rover.ebay.com/rover/0/e11050.m1831.l3127/7?euid=7b39acbc4c074afda53[..]
[2] http:/ /rover.ebay.com/rover/0/e11050.m44.l1181/7?euid=7b39acbc4c074afda53a2[..]
[3] http:/ /rover.ebay.com/rover/0/e11050.m44.l1183/7?euid=7b39acbc4c074afda53a2[..]
[4] http:/ /rover.ebay.com/rover/0/e11050.m44.l1139/7?euid=7b39acbc4c074afda53a2[..]
[5] http:/ /rover.ebay.com/rover/0/e11050.m44.l1123/7?euid=7b39acbc4c074afda53a2[..]
[6] http:/ /rover.ebay.com/rover/0/e11050.m43.l1123/7?euid=7b39acbc4c074afda53a2[..]
[7] http:/ /rover.ebay.com/rover/0/e11050.m43.l1123/7?euid=7b39acbc4c074afda53a2[..]
[8] http:/ /rover.ebay.com/rover/0/e11050.m43.l1465/7?euid=7b39acbc4c074afda53a2[..]
[9] http:/ /rover.ebay.com/rover/0/e11050.m3965.l1181/7?euid=7b39acbc4c074afda53[..]
[10] http:/ /rover.ebay.com/rover/0/e11050.m3944.l7013/7?euid=7b39acbc4c074afda53[..]
[11] http:/ /rover.ebay.com/rover/0/e11050.m1852.l6369/7?euid=7b39acbc4c074afda53[..]
[12] http:/ /rover.ebay.com/rover/0/e11050.m1852.l3167/7?euid=7b39acbc4c074afda53[..]
[13] http:/ /rover.ebay.com/rover/0/e11050.m1852.l3168/7?euid=7b39acbc4c074afda53[..]
[14] http:/ /rover.ebay.com/rover/0/e11050.m1852.l3165/7?euid=7b39acbc4c074afda53[..]

Hoffe mir kann jemand helfen das problem zu beheben.

Gruß
Alex

[RStraub]

Hast du mal den Umzug mittels des backup / restore script versucht?
Bist du sicher dass dieselbe Framework-Version genutzt wird?
SInd alle benötigten Module installiert?

[MAKUT]

Hallo,

Bist du sicher dass dieselbe Framework-Version genutzt wird?

Ja. Die neue Installation ist eine exakte Kopie der originalen Installation.

Sind alle benötigten Module installiert?

Laut Admin Support Overview sind alle Module vorhanden und in Ordnung

Hast du mal den Umzug mittels des backup / restore script versucht?

Die Installation läuft unter Windows und das Backup Script in der portable shell ausgeführt gibt mir folglich einen Fehler aus.
Meine Recherchen (vor dem ersten Umzug den ich durch gezogen habe) haben aber ergeben das das Script nur ein backup des filesystems macht und dieses auch mit jedem anderen Tool genauso gut funktioniert. Selbst mit einfachem c & p

Den msqldump nutze ich selbstverständlich um die DB zu übertragen und das klappt auch wie geschnitten Brot.
Beide DB,s sind nach dem Ex-/Import identisch.

[MAKUT]

Ich habe diese Frage nun im englischen Forenteil erneut gestellt und hoffe dort auf eine Antwort.

Sollte ich eine Lösung erhalten füge ich dieser hier ein und markiere den Beitrag als erledigt.



Gruß

Alex

[wurzel]

Hi,

also hier weiter

Wie im engl. Teil beschrieben würde ich garnicht auf Windows weitermachen.

Mein Tipp:
Setz' Dir ein neues Linux auf.

Installiere ein OTRS Version 5 und schaue, dass es fehlerfrei läuft.
Das ist dann unter /opt/otrs

Wenn das läuft, benenne den Ordner um nach /opt/otrs5
droppe die Datenbank.

Als nächstes installierst Du ein OTRS 4 (auch nach /opt/otrs) und schaust auch, dass das fehlerfrei läuft.
Wenn das läuft, benenne den Ordner um nach /opt/otrs4
droppe die Datenbank.

Verfahre analog mit Version 3.3, 3.2, 3.1. und 3.0.

Am Ende hast Du ein laufendes OTRS 3.0.x richtig? Und Du hast
/opt/otrs5
/opt/otrs4
/opt/otrs3.3
/opt/otrs3.2
/opt/otrs3.1
/opt/otrs (<<--- das ist die 3.0.x)
droppe nun die Datenbank.

Jetzt dumpst Du auf Deiner Windows Kiste die Datenbank und spielst Sie auf dem Linux mysql ein.
Dann holst Du Dir die Config Dateien (ZZZAuto.pm) und Deine Artikel
Einmal Caches löschen, RebuildConfig.pl

starte den Webserver neu, das OTRS 3.0 sollte nun Deine aktuellen Daten (fehlerfrei) haben.

Danach migrierst Du einfach wie gewohnt durch
Notiere Dir alle Fehler, behebe sie. Für das produktive Upgrade ist es dann wichtig. Das geht dann in einem Rutsch durch

... und apache 2.2. oder 2.4. ist egal. Beides läuft.

Am Einfachsten wäre wohl mit 'ner 2.2.x auf dem Linux. Wenn dann die 5er läuft kannst Du immer nochmal auf 'ne 2.4.x wechseln.

viele Grüße
Flo

[MAKUT]

Heidewitzka!!

Das klingt zu einfach um wahr zu sein!

Ich werde mich direkt Montag daran machen das Pferd von hinten auf zu zäumen

Bin gespannt wie weit ich komme mit meinen kaum vorhandenen Linux Kenntnissen. Aber ich bin ja noch Lernfähig
Sollten Probleme auftreten eröffne ich einfach einen neuen post.


Vielen dank! Und ein schönes Wochenende Florian



Gruß

Alex

[wurzel]

Hi,

prinzipiell ist es einfach. Erfahrungsgemäß brauchst Du aber ein paar Versuche bis alles reibungslos läuft.
Angefangen von Kodierungsfehler, faslchen Einträgen in der DB, eigener Code, ...


Viel Erfolg

Flo

[MAKUT]

Hi Flo,

ich erwähnte ja schon meine geringen Linux Kenntnisse... Dazu eine letzte Frage zum allgemeinen Ablauf.

ich habe jetzt das OTRS5 laufen und möchte es durch das 4er ersetzen.

Die Installation übers Terminal wirft mir immer Fehler aus wenn ich eine der niedrigeren Versionen nachinstallieren will, trotz '--replacefiles' .
Meldung ist immer das installierte 5er Paket ist aktueller.

Daher meine Idee den entsprechenden ordner Manuell zu ersetzen.

Die .rpm Pakete enthalten immer 2 Verzeichnisse. Etc und opt.
Genügt es den /opt teil zu kopieren um die 5er ( in 'otrs5' umbenannt) zu ersetzen oder sind die Dateien im etc auch zu ersetzen?


Danke für den Support und beste Grüße,

Alex

[wurzel]

Hi,

am Besten verwendest Du nicht das rpm sonder das tar.gz

bennene das Verzeichnis einfach um von /opt/otrs nach /opt/otrs5
und entpacke das 4er tar.gz nach /opt/otrs

Das mit dem 5er rpm würde ich am Ende (wenn alles läuft) einfach nochmal draufspielen.
Das kannst Du jetzt aber erstmal so lassen. Das ist garnicht schlecht, wenn das 5er rpm drauf ist.

Du kannst trotzdem jetzt mit den tar.gz files weitermachen.

viele Grüße
Flo

[MAKUT]

Hi,

Oh das ging ja fix . Also einfach /opt ersetzen. Danke dir!

..nur um den Wissensdurst zu stillen.... der Unterschied zwischen diesen beiden Typen ist

.rpm: Eine art vorgefertigtes Installationspacket das alle notwendigen schritte zur Verwendung selbst erledigt und dem System diese auch mitteilt.

.tar.gz: Ein einfaches Archiv das die rohen Anwendungsdaten enthält und keinerlei weitere Einträge im System erstellt oder anderen Anpassungen automatisch vornimmt.


Kann man das so sagen?

Und zu den Versionen:

otrs-4.0.0.rc1.tar.gz
oder
otrs-4.0.1.tar.gz ?

diese rc1 versionen gibt es ja von jeder Variante (3.3, 3.2 etc.)



Gruß

Alex

[wurzel]

Hi,

vergleiche das rpm mit einer .exe Datei unter Windows.
das rpm prüft Abhängikeiten, setzt Benutzerrechte, erstellt User, macht Basis Konfiguration mit apache.

das tar.gz. ist nur ein gepacktes Dateiarchiv. Da musst Du den Rest (was das rpm zum Großteil macht) manuell machen.


Was die Versionen betrifft... nimm immer das letzte Patch Release
http://ftp.otrs.org/pub/otrs/

Stand heute ist das
otrs-5.0.13.tar.gz
otrs-4.0.18.tar.gz
otrs-3.3.15.tar.gz
und so weiter


die rc Versionen sind ReleaseCandidate (teils aus Beta Phasen) bitte nicht verwenden.

Flo

[MAKUT]

Halli Hallo, ich schon wieder


Kurzes Update: Der Downgrade von 5.0.18 auf 3.0.22 hat wunderbar funktioniert. Hier und da waren geringe Anpassungen nötig aber im Großen und Ganzen war das ganze ein Spaziergang.

Nun bin ich dabei die db und die Artikel zu importieren.

bei einem Test der 3.0.22 er verison ist mir jedoch etwas aufgefallen das mich leicht stutzig macht.

Wenn ich mit dem SQL Benchmark tool die DB Zugriffszeiten prüfe bekomme ich für Insert und Update enorm hohe werte angezeigt.

Für select und delete jedoch nicht. Egal mit welchem multiplier ich das ganze teste.

Insert Time: 10000 26 s Should not take more than 5's on an average system.
Update Time: 10000 33 s Should not take more than 9's on an average system.
Select Time: 10000 3 s Looks fine!
Delete Time: 10000 2 s Looks fine!
Multiplier: * 1 s

DIe hardware schließe ich mal als Ursache aus.
Fixer RAID 10, 2 Kerne und 6GB RAM sind derzeit zugewiesen
Gibt es da spezielle Einstellungen um das ganze zu optimieren oder wird sich das legen sobald ich mit dem Upgrade wieder über 4.0 bin?
Davor war noch alles iO mit den Zugriffszeiten.

Des weiteren noch eine kurze frage zu den benötigten Config Dateien beim Umzug.

aktueller Wissenstand:

Benötigt werden neben den Artikeln nur 2 weitere Dateien. Config.pm (Kernel) und die ZZZAuto (Kernel/Config/files)

------

Brauche ich neben den Artikeln ausschließlich die Config.pm (Kernel) und die ZZZAuto (Kernel/Config/files) ?
Ich habe in diversen Quellen gelesen das die Ticketcounter.log Datei mit übertragen werden muss da es sonst zu Indexproblemen kommen kann.


Danke für den Support.


mit besten Grüßen

Alex

[wurzel]

Hi,

Halli Hallo, ich schon wieder
Kurzes Update: Der Downgrade von 5.0.18 auf 3.0.22 hat wunderbar funktioniert. Hier und da waren geringe Anpassungen nötig aber im Großen und Ganzen war das ganze ein Spaziergang.

schön zu hören

Wenn ich mit dem SQL Benchmark tool die DB Zugriffszeiten prüfe bekomme ich für Insert und Update enorm hohe werte angezeigt.

ich würde den Benchmark nicht trauen. Früher hatte ich da ähnliche Zeiten obwohl das OTRS immer superschnell war.

Ich mag aber auch faslch liegen.

Des weiteren noch eine kurze frage zu den benötigten Config Dateien beim Umzug.

aktueller Wissenstand:

Benötigt werden neben den Artikeln nur 2 weitere Dateien. Config.pm (Kernel) und die ZZZAuto (Kernel/Config/files)

Prinzipiell reichen die Beiden. Wenn Du strikt nach der Migrationsanleitung (bzw. nach allen Anleitungen) durchgehst, wirst Du noch 'ne GenericAgent.pm finden.

Je nachdem, was Du da drin hast (gilt auch für die Config.pm) musst Du die mit migrieren.

Du musst (wenn Du ACLs in der Config.pm hast) diese auch manuell anpassen. Die Anleitungen beschreiben das aber genau wann und wo

viele Grüße
Flo

[MAKUT]

Hello again,

Nun habe ich eine funktionierende OTRS Version 3.0.22 mit unseren Ticketdaten und Configdateien auf CentOS laufen aber der Ursprungsfehler wegen dem ich den thread eröfffnet habe ist wieder da.


Tickets sind voller styletags und alle Links sind am ende gesammelt. :/

So will ich die migration natürlich nicht starten.


Woran kann das bloß liegen...hab schon sehr viel gesucht aber ich komme nicht dahinter.


Vielleicht hast du ja jetzt eine idee...ist ja immerhin nicht mehr auf Windows

Schönes Wochenende!

Gruß
Alex

[wurzel]

Hi

dann ist ne codierung wohl falsch. prüfe mal ob alles utf8 ist. Vermutlich ist bei dir was auf ISO gestellt oder so. DB oder Dateien.

Dann musst Du das konvertieren.

Flo

[wurzel]

Hi,

Wartmal... du hast nur fehlende Formate? Die Umlaute sind OK? Dann stimmt die codierung.


Dann kann Dein OTRS das article Verzeichnis nicht finden oder Du hast fehlende Dateinerechtigungen.

Was sagen die Logs?

wenn du ein neues Ticket anlegst, stimmen dann die Formate und Links?

Flo

[MAKUT]

Guten Morgen,

ich habe mir mal ein langes Wochenende gegönnt. Nun wieder frisch ans Werk.

Logs.... gute Frage.

Das einzige was in Richtung der Berechtigungen geht ist dieser Eintrag:

][Error][Kernel::System::Main::FileWrite][444] Can't write '/opt/otrs/var/httpd/htdocs/skins/Agent/default/css-cache//CommonCSS_7a141409083744751f2a68b03d06d7b0.css': Permission denied

Weist ja zumindest auf ein solches Problem hin, wenn auch in einem ganz anderen Bereich.

Ich habe mich nach deinem Tipp mal bezgl. dieser Thematik durchs admin book gewühlt aber nichts dazu gefunden.
Wie muss ich denn die Berechtigungen korrekt setzen damit OTRS alle nötigen Rechte hat?

Die SetPermissions.pl habe ich natürlich drüber rödeln lassen und ich war der Ansicht das damit die Berechtigungen korrekt gesetzt werden.

Das Verzeichnis /otrs/var/* (artikelverzeichnis) sollte dabei ja auch mit abgefrühstückt werden.


Danke für den ausdauernden Support Flo!


Gruß

Alex

[MAKUT]

.

[RStraub]

Oha ich erinnere mich dunkel dass ich die Probleme auch mal hatte. Wir haben damals die Ordner-Cache Tiefe angepasst... Unabhängig davon, geh mal in den Eltern-Ordner, also:
opt/otrs/var/httpd/htdocs/skins/Agent/default/
oder
opt/otrs/var/httpd/htdocs/skins/Agent/default/css-cache/

und prüf mit "ls -l" die Ordnerrechte.
Im Zweifel als root user die Rechte umsetzen. Auf Ubuntu wäre das z.B. (falls du im richtigen Verzeichnis bist):
chown -R otrs:www-data *

[MAKUT]

Hi RStraub,


Verzeichnis: opt/otrs/var/httpd/htdocs/skins/Agent/default/

Output:

[root@OTRS default]# ls -l
insgesamt 12
drwxrwxr-x 3 otrs apache 4096 25. Okt 12:18 css
drwxrwxr-x 2 otrs apache 4096 2. Nov 11:56 css-cache
drwxrwxr-x 4 otrs apache 4096 14. Jun 2013 img


Die skin problematik ist jedoch erstmal zu vernachlässigen.
Habe die erforderlichen ordner stumpf kopiert.


Output beim articles überordner /opt/otrs/var :

drwxrwsr-x 3 otrs apache 56 28. Okt 10:12 article

und vom ordner article:

drwxrwsr-x 13 otrs apache 105 2. Nov 08:18 2016

[RStraub]

Und dasselbe im ordner css-cache?

[MAKUT]

[root@OTRS css-cache]# ls -l
insgesamt 396
-rw-rw-r-- 1 otrs apache 79371 28. Okt 16:33 CommonCSS_9b3b26eb5b968ce2d29ee317d93417fc.css
-rw-rw-r-- 1 otrs apache 78895 25. Okt 12:18 CommonCSS_a2ed3b4b933451fbfcbd9602ab4cc5f9.css
-rw-rw-r-- 1 otrs apache 79371 2. Nov 09:03 CommonCSS_c2bbcb950c77c8636a92c786ce461aa6.css
-rw-rw-r-- 1 otrs apache 78895 25. Okt 12:18 CommonCSS_ce8784f140d1879fb06dcffb55fa3a8a.css
-rw-rw-r-- 1 otrs apache 5387 2. Nov 09:03 CommonCSS_IE7_0798721707b5113846a77358120ba5d7.css
-rw-rw-r-- 1 otrs apache 5387 28. Okt 16:33 CommonCSS_IE7_752e65b9686488bdd311e33270214a0a.css
-rw-rw-r-- 1 otrs apache 5387 25. Okt 12:18 CommonCSS_IE7_943623b8f47327ce9044617d4563a284.css
-rw-rw-r-- 1 otrs apache 5387 25. Okt 12:18 CommonCSS_IE7_e689827343a7b7d35010e5db7edd64e8.css
-rw-rw-r-- 1 otrs apache 208 2. Nov 09:03 CommonCSS_IE8_4e433cf5efd8472ddb6d3fb72a9fa986.css
-rw-rw-r-- 1 otrs apache 208 25. Okt 12:18 CommonCSS_IE8_508d7e06c8872386c9244aabe2561c49.css
-rw-rw-r-- 1 otrs apache 208 28. Okt 16:33 CommonCSS_IE8_7a4dfbb2d50f4b2e9f8a246edeb19264.css
-rw-rw-r-- 1 otrs apache 208 25. Okt 12:18 CommonCSS_IE8_f6cd2aeb97e3f6610a3b32fbc8b6ea34.css
-rw-rw-r-- 1 otrs apache 316 25. Okt 12:18 ModuleCSS_16cf7ad093b50c17d7a7740c620efbf8.css
-rw-rw-r-- 1 otrs apache 3492 2. Nov 08:25 ModuleCSS_1c61e646e4e0c1df37f89e6ea42f601b.css
-rw-rw-r-- 1 otrs apache 579 2. Nov 11:56 ModuleCSS_568cddb9950e392a66fa954118f7e52e.css
-rw-rw-r-- 1 otrs apache 316 25. Okt 12:18 ModuleCSS_7e7932d79e192315fc921384e1dbdc6c.css
-rw-rw-r-- 1 otrs apache 579 28. Okt 16:34 ModuleCSS_88fb528fcc506dddcae67be75fae7d17.css
-rw-rw-r-- 1 otrs apache 1438 28. Okt 16:37 ModuleCSS_a039c3277accf474a4e7ec0512d0c673.css
-rw-rw-r-- 1 otrs apache 230 28. Okt 16:37 ModuleCSS_IE7_cb6eb103ad348fa1e723bdf342143afb.css

[RStraub]

Sieht korrekt aus. Lese+Schreibrechte für die Gruppe und die korrekte Gruppe :/

[MAKUT]

Guten Morgen,

ja, aber wie gesagt. Den Skin schnell neu zu erstellen und ein zu richten ist ein leichtes und in Minuten erledigt.

Die Darstellung der Tickets ist mir grad ein größerer Dorn im Auge.
Vorher möchte ich nicht mit dem Testupgraden beginnen.

Trotzdem danke für die Hilfe RStraub. Sehr nettes Forum hier.



Gruß

Alex

[MAKUT]

Kurzes Update:

Es lag tatsächlich an den Berechtigungen.

Die Überordner hatten alle die richtigen Rechte aber einige Unterordner nicht.
Nachdem ich diese manuell korrigiert habe funktioniert die Ticketdarstellung einwandfrei.

Nun geht's ans Upgraden.


Gruß

Alex

[RStraub]

Yey! Viel Erfolg

[wurzel]

Hi,

yeeah auch von mir viel Erfolg

Flo

[MAKUT]

Hach soviel anteilnahme.... gibtn Eis wenn ich fertig bin


kurz zwischenfrage: Nach dem Upgrade auf 3.1 (hat wunderbar funktioniert) Mault das Support Assessment nun rum:

Check if the database uses utf8 as charset.
Character_set_database setting found, but it's set to latin1 (needs to be utf8).


Failed Check the utf8 table charset collation.
Your charset collation is set to Invalid charset collation for: dynamic_field[latin1_swedish_ci], dynamic_field_value[latin1_swedish_ci],
gi_debugger_entry[latin1_swedish_ci], gi_debugger_entry_content[latin1_swedish_ci], gi_object_lock_state[latin1_swedish_ci], gi_web


Wie bekomme ich die DB entsprechend umgemodelt?

Und vor allem...wieso verstellt sich das während des Upgrades von alleine (vorher war ja auch utf8) und, kann ich das beim nächsten upgradeschritt verhindern?

Als möglichen Lösungsansatz habe ich nur eine Option gefunden:
sqldump der otrsDB default charset auf utf8 stellen und dann reimport.

passt das so?


beste grüße und schon mal ein schönes Wochenende!

Alex

[wurzel]

Hi,

"von alleine" stellt sich das nicht um.

Du musst die DB nach utf8 konvertieren. Dump -> Convert -> Restore
Es gibt meines Wissens auch Tools die das können. Wichtig ist, dass Du definitv beim Konvertieren keine Fehler machst.

auf portal.otrs.com gibt es dazu (nach Registrierung) einen FAQ Eintrag dazu.


und Dein mysql muss auch die Storage Engine InnoDB unterstützen (ist ein anderes Thema, musst Du nur aufpassen später)

und auch utf8 als default charset haben
(create database otrs character set utf8)


Dein sqldump muss eigentlich auch utf8 exportieren wenn die DB utf8 ist.
Und Dein Terminal sollte auch utf8 sein

viele Grüße
Flo

[MAKUT]

Hallo,

scheinbar ja schon.
Vorher war definitiv utf8 Standard. Nun ist es latin1. Und ich habe beim Upgrade ja nichtmal die DB neu importiert sondern nur das OTRS verzeichnis ersetzt und dann die scripte laufen lassen.

wird denn der Dump beim import automatisch umgewandelt wenn die zuvor erstellte, leere, DB 'otrs' mit latin1 als standard erstellt wurde statt utf8 ?
(notiz an mich selbst: SQL Kenntnisse auffrischen!)
MariaDB hat InnoDB als default engine gesetzt das habe ich bereits geprüft als ich das erste mal über diese Empfehlung stolperte.

Code: Select all

MariaDB [(none)]> show engines;
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                                    | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES          | YES  | YES        |

Gut dann werde ich wohl nicht drum herum kommen...

erneut dump erstellen -> convertieren auf utf8 -> leere db 'otrs' erstellen , default charset utf8 -> import

ich werde mir die erwähnte FAQ mal ansehen. Danke für den Tip.

Weiter gehts.

[wurzel]

Hi,

das hört sich seltsam an, es sollte eigentlich immer utf8 bleiben.


Viel Erfolg weiterhin

Flo

[MAKUT]

Fürs Gesamtbild hier die Lösung des Problems:

Es waren komischerweise alle beim Upgrade neu angelegten Tabellen in latin1.
Die alten waren wie gehabt utf8.

Um das ganze zu beheben habe ich folgende Schritte unternommen:

DB Dump
Dump komplett in utf konvertiert mit:

Code: Select all

iconv -f iso-8859-1 -t utf8 backup.sql > backuputf8.sql

reimport der DB


Dann im mysql mit folgendem Befehl:

Code: Select all

use otrs;
show table status;

die zu konvertierenden Tabellen heraus gesucht und mit:

Code: Select all

alter table <TABELLENNAME> convert to character set utf8 collate utf8_general_ci;

Die Codierung umgestellt.

[MAKUT]

Dabei ist mir übrigens aufgefallen, das die meisten Tabellen noch mit der MyISAM Engine laufen, die neuen hingegen schon mit InnoDB.

Wird der Rest automatisch mit einem späteren Upgrade umgestellt oder muss das so oder so manuell gemacht werden?

ich muss gestehen das mir nicht ganz klar ist was das für Auswirkungen auf die Funktion des ganzen hat. Aber das ist ja auch erst mal zweitrangig.


Gruß

Alex

[wurzel]

Hi,

in einer Version ist so n innodb switch tool dabei im opt/otrs/bin/ ordner


steht in der jeweiligen doku auch

Flo

[MAKUT]

Halli Hallo

Am WE hatte ich mal wieder etwas zeit weiter zu machen.

DIe 4er Version läuft einwandfrei zeigt aber ein paar Errors an die ich nicht wirklich nachvollziehen kann.
Bevor ich auf 5 Hoch ziehe frag ich lieber nochmal.

Code: Select all

Scheduler could not delete PID file:'/opt/otrs/var/run/scheduler.pid'! Datei oder Verzeichnis nicht gefunden

diese Datei existiert am angegebenen Ort. mal wieder ein rechteProblem?

Die Setpermissions.pl

gibt mir seit V4 auch nurnoch

Code: Select all

[root@OTRS otrs]# bin/otrs.SetPermissions.pl --web-group=apache
Setting permissions on /opt/otrs

statt wie zuvor

Code: Select all

bin/otrs.SetPermissions.pl - set OTRS file permissions
Copyright (C) 2001-2013 xxx, http://otrs.com/
Setting permissions on /opt/otrs
Setting permissions on /opt/otrs/var
Setting permissions on /opt/otrs/bin/*
Setting permissions on /opt/otrs/scripts/
Setting permissions on /opt/otrs/Kernel/Config.pm
[root@OTRS otrs]# bin/otrs.CheckModules.pl

Ist das so gewollt oder Hab ichs kaputt gemacht?
Hier die ausgabe wenn icxh die Berechtigungen abfrage:

Code: Select all

[root@OTRS ~]# cd /opt/otrs/var
[root@OTRS var]# ls -l
insgesamt 36
drwxrwsr-x 3 otrs apache    17 14. Nov 14:01 article
drwxrwsr-x 2 otrs apache  4096 14. Nov 14:05 cron
drwxrwsr-x 2 otrs apache  4096 19. Feb 2013  fonts
drwxrwsr-x 3 otrs apache    19 19. Feb 2013  httpd
drwxrwsr-x 2 otrs apache    91 14. Nov 14:10 log
-rw-rw---- 1 otrs apache 23707 19. Feb 2013  logo-otrs.png
drwxr-s--- 2 otrs apache    26 14. Nov 14:10 run
drwxrwsr-x 2 otrs apache     6 21. Nov 2014  sessions
drwxrwsr-x 2 otrs apache     6 21. Nov 2014  spool
drwxrwsr-x 2 otrs apache  4096 19. Feb 2013  stats
drwxrwsr-x 3 otrs apache    30 14. Nov 14:07 tmp

Code: Select all

[root@OTRS var]# cd run
[root@OTRS run]# ls -l
insgesamt 4
-rw-rw---- 1 otrs apache 4 14. Nov 14:10 scheduler.pid

---------------------------

Außerdem noch diesen hier:

Code: Select all

Module Kernel/Modules/AdminSupport.pm not in @INC (/usr/sbin/../../Custom /usr/sbin/../../Kernel/cpan-lib /usr/sbin/../.. /usr/Custom /usr/Kernel/cpan-lib /usr /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)

Ich habe garkein Support modul installiert und es scheint für 4 Ja auch keins mehr zu geben.
Sind das nur überreste der alten Version oder wie darf ich das verstehen?

---------------------
und diese hier.

Code: Select all

No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar.pm!
No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar/File.pm!
No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar/Constant.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/mysql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/postgresql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/mssql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/oracle.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver/Apache.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver/IIS.pm!
No such file: /opt/otrs/Kernel/System/Support/OTRS.pm!
No such file: /opt/otrs/Kernel/System/Support/OS.pm!
No such file: /opt/otrs/Kernel/System/Support/Database.pm!
No such file: /opt/otrs/Kernel/System/Support.pm!
No such file: /opt/otrs/Kernel/Output/HTML/Standard/AdminSupportLicenseText.dtl!
No such file: /opt/otrs/Kernel/Output/HTML/Standard/AdminSupport.dtl!
No such file: /opt/otrs/Kernel/Modules/AdminSupport.pm!
No such file: /opt/otrs/Kernel/Language/es_MX_Support.pm!
No such file: /opt/otrs/Kernel/Language/de_Support.pm!
No such file: /opt/otrs/Kernel/Config/Files/Support.xml!

Fehler beim Upgrade gab es eigentlich keine die ich für nennenswert halte.....

Danke fürs sichten und beraten.


Mit besten grüßen!

Alex

[MAKUT]

Achso und noch aus neugier folgendes:

Code: Select all

 	DATENBANKEINTRÄGE
 
 Dynamische Felder 	46 	
Werte in Dynamischen Feldern 	1433919 	
Ungültige dynamische Felder 	36 	
Werte in ungültigen dynamischen Feldern 	1433919

Bekomme ich diese ungütigenWerte/Felder irgendwie raus aus der DB oder habe ich das so zu akzeptieren?

[jojo]

Einfach die deaktivierten Dynamischen Felder löschen, dann sind die Daten auch weg

[MAKUT]

HI Jojo...

beim Geschriebenen Wort bin ich etwas vorsichter wenns um ironie geht... Wie genau meinst du das nun? ^^

P.s.: sollte das ernst gemeint gewesen sein...ich hab wenig Ahnung was mysql angeht. ich wüsste gerade aus dem Stegreif nicht wie ich nur eben jene Felder selektieren könnte.

[jojo]

das geht im Adminfrontend der dynamischen Felder. Dort kannst Du deaktivierte dynamische Felder auch löschen

[MAKUT]

Ahhh so wird nen schuh draus.

Danke für den Hinweis!


Gruß

Alex

[wurzel]

Hi,

Am WE hatte ich mal wieder etwas zeit weiter zu machen.

dann schaumermal

DIe 4er Version läuft einwandfrei zeigt aber ein paar Errors an die ich nicht wirklich nachvollziehen kann.
Bevor ich auf 5 Hoch ziehe frag ich lieber nochmal.

sehr gut.

Code: Select all

Scheduler could not delete PID file:'/opt/otrs/var/run/scheduler.pid'! Datei oder Verzeichnis nicht gefunden

diese Datei existiert am angegebenen Ort. mal wieder ein rechteProblem?

das ist eine process ID Datei. Wenn es die nicht gibt, läuft der Scheduler nicht. Die wird angelegt wenn der Scheduler startet. --> kannste erstmal ignorieren

Die Setpermissions.pl

gibt mir seit V4 auch nurnoch

Code: Select all

[root@OTRS otrs]# bin/otrs.SetPermissions.pl --web-group=apache
Setting permissions on /opt/otrs

statt wie zuvor

Code: Select all

bin/otrs.SetPermissions.pl - set OTRS file permissions
Copyright (C) 2001-2013 xxx, http://otrs.com/
Setting permissions on /opt/otrs
Setting permissions on /opt/otrs/var
Setting permissions on /opt/otrs/bin/*
Setting permissions on /opt/otrs/scripts/
Setting permissions on /opt/otrs/Kernel/Config.pm
[root@OTRS otrs]# bin/otrs.CheckModules.pl

Ist das so gewollt oder Hab ichs kaputt gemacht?

Lese die Doku und freue Dich dass es so gewollt ist.

Code: Select all

Module Kernel/Modules/AdminSupport.pm not in @INC (/usr/sbin/../../Custom /usr/sbin/../../Kernel/cpan-lib /usr/sbin/../.. /usr/Custom /usr/Kernel/cpan-lib /usr /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)

Ich habe garkein Support modul installiert und es scheint für 4 Ja auch keins mehr zu geben.
Sind das nur überreste der alten Version oder wie darf ich das verstehen?

korrekt. Gibt's nicht mehr. Die Meldung ist bisschen irreführend. --> kannste ignorieren

Code: Select all

No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar.pm!
No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar/File.pm!
No such file: /opt/otrs/Kernel/cpan-lib/Archive/Tar/Constant.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/mysql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/postgresql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/mssql.pm!
No such file: /opt/otrs/Kernel/System/Support/Database/oracle.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver/Apache.pm!
No such file: /opt/otrs/Kernel/System/Support/Webserver/IIS.pm!
No such file: /opt/otrs/Kernel/System/Support/OTRS.pm!
No such file: /opt/otrs/Kernel/System/Support/OS.pm!
No such file: /opt/otrs/Kernel/System/Support/Database.pm!
No such file: /opt/otrs/Kernel/System/Support.pm!
No such file: /opt/otrs/Kernel/Output/HTML/Standard/AdminSupportLicenseText.dtl!
No such file: /opt/otrs/Kernel/Output/HTML/Standard/AdminSupport.dtl!
No such file: /opt/otrs/Kernel/Modules/AdminSupport.pm!
No such file: /opt/otrs/Kernel/Language/es_MX_Support.pm!
No such file: /opt/otrs/Kernel/Language/de_Support.pm!
No such file: /opt/otrs/Kernel/Config/Files/Support.xml!

gehört auch auch alles zu dem Support Paket. --> ignorieren

Jetzt weitermachen

Weiterhin viel Erfolg.

Flo

[MAKUT]

Tag zusammen!

So nun bin ich auf V5 und es sieht alles gut aus.

2 Dinge fallen mir noch auf.

1.

Code: Select all

Alle Details zu dieser Zahlung finden Sie in Ihrer PayPal-Kontoübersicht.

Komischerweise werden Umlaute wieder falsch dargestellt.

DIe Tabellen bin ich aber schon durch gegangen und alle stehen auf utf8_general_ci.
Ist zwar hinnehmbar, da sich das ganze nur auf alte Tickets bezieht und neu erstellte Tickets die Umlaute alle korrekt darstellen, schön ist es aber nicht.


und als 2.

Im Errorlog

Code: Select all

No existing template directory found ('/opt/otrs/Kernel/Output/HTML/Templates/Akut')!.

Das ist ein altes Template aus 3.0.

Ich habe mir bereits nen Wolf gesucht aber ich komme nicht dahinter wo dieses Template sich noch verewigt hat.
Es bleibt ja eigentlich nurnoch die DB.
Die Config dateien die ich immer mit rüber nehme habe ich bereits durchforstet aber dort ist nichts mehr zu finden.


mit besten grüßen

Alex

[RStraub]

Das er noch nach einem alten Template sucht, vermute ich in den ~otrs/Kernel/Config/Files/ZZZ*Dateien...
such doch einfach mal vom Stammverzeichnis ~otrs aus:

Code: Select all

grep -R 'Akut' *

[MAKUT]

Hi RStraub

wenig brauchbares.

ZZZAuto nur im Titel (Firmenname)
dann die ganzen log einträge mit eben jenem Fehler und einige Binärdateien im Cache. Aber den Cache habe ich ja nach jedem Updateschritt gelöscht. Ich kann mir nicht vorstellen das da der Fehler liegt.

Vielleicht im Apache Verzeichnis?


Gruß

Alex

[RStraub]

Seltsam. Ich bekomm immer nach einem Upgrade den Fehler dass der Ordner ~otrs/Kernel/Output/HTML/Templates/Custom oder so ähnlich fehlt.

Meine Lösung ist dann, diesen einfach leer anzulegen. Probier mal ob das schon reicht:

Code: Select all

mkdir /opt/otrs/Kernel/Output/HTML/Templates/Akut

[wurzel]

Hi,

leg mal /opt/otrs/Kernel/Output/HTML/Templates/Akut an
(korrekte Rechte)

und der Fehler sollte nicht mehr im Log sein. Ich hab auch so ein System (ursprünglich 'ne <2.4.x) und ich find nicht, wo das verewigt ist. Ein Anlegen des Ordners sollte helfen.

zum Umlaute (utf8) weiß ich jetz auch grad nix

viele Grüße
Flo

[wurzel]

Hi,

ich hatte manchmal die Erfahrung gemacht, wenn ich mit einem ISO Terminal (putty auf ISO) einen dump gemacht habe (und evtl. mit sed umgebaut hatte) dass das auch nicht 100%ig ging.

Kannst Du mal Dein Terminal prüfen?
Kannst Du mal den Dump prüfen mit

Code: Select all

root@server:/opt# file -i otrs-4.0.x.sql 

die Ausgabe sollte sein

Code: Select all

otrs-4.0.x.sql: text/plain; charset=utf-8

viele Grüße
Flo

[MAKUT]

Guten Morgen!


Kitty läuft mit utf-8


Die Ausgabe deines Befehls passt.

Code: Select all

[root@OTRS ]# file -i otrs-database.sql

otrs-database.sql: text/plain; charset=utf-8

Oha, ich glaub ich weiß wo ich den Fehler produziert habe.

Als es darum ging die Tabellen auf utf8 zu konvertieren habe ich wohl..entgegen jeder best practice...an einer schraube zuviel gedreht anstatt eins nach dem anderen zu ändern.

und zwar habe ich in der Config.pl folgendes eingetragen:

Code: Select all

$Self->{'DefaultCharset'} = iso-8859-15';

Wenn ich nun auf die ZZZAuto Datei zugreifen und diese Bearbeiten will wird mir eine Warnung angezeigt das dort ungültige Zeichen existieren und das ich die Datei eventuell durch bearbeiten unbrauchbar mache.

Da ich ja gern vor Wände laufe um zu sehen das sie da sind hab ich die Datei erst mal kräftig bearbeitet und die kritischen Stellen dem neuen Zeichensatz angepasst.
Wenn ich die Datei dann aber Speichere und die Dienste neu starte gibts nen Error "Misconfiguration" und so weiter....

Ich gehe mal davon aus das das mein Fehler war. utf-8 <> iso-8859-15. Wie ich das nun wieder ausbügeln kann weiß ich jedoch gerade nicht.


Gruß

Alex

[jojo]

OTRS unterstützt ausschließlich utf8