Umstellung ArticleStorageDB auf ArticleStorageFS

Dennis · Post by **Dennis** » 11 Apr 2007, 14:32

Da unsere Datenbank durch die Einstellung "ArticleStorageDB" über die Jahre ziemlich dick geworden ist, wollte ich nachträglich den Modus umstellen, so dass alle Artikeldaten und Anhänge nicht in der Datenbank, sondern direkt im Filesystem abgelegt werden. Das Umstellen an sich ist auch überhaupt kein Problem (solange man ein Standard-OTRS einsetzt, sollten Berechtigungsprobleme auftreten unten weiterlesen), dazu muss man einfach in der Sysconfig im Bereich Core::Ticket den Punkt Ticket::StorageModule auf "ArticleStorageFS" umstellen und abspeichern.
Die Anhänge werden von nun an im Filesystem nach Datum sortiert abgelegt. Begonnen wird in $OTRSHOME/var/article.

Damit hat man also geschafft, dass alle zukünftigen Anhänge nicht mehr in die Datenbank wandern. Was ist aber mit denen die schon in der Datenbank sind? Bei mir zum Beispiel waren von 16 GB ganze 12 GB Anhänge die ausgelagert werden konnten.
Um diese Daten aus der Datenbank zu bekommen hat Stefan Bedorf ein Perlscript geschrieben welches sich einfach über den GenericAgent einbinden läßt. Dieser Generic Agent zieht alle Daten aus der Datenbank und löscht sie dort. Um das zu erreichen geht man folgendermaßen vor:

1. Angehängte MoveArticleParts.pm nach $OTRSHOME/Kernel/System/GenericAgent kopieren

2. Eintrag in $OTRSHOME/Kernel/Config/GenericAgent.pm vornehmen:

Code: Select all

            # --
            # move articles from db to fs
            # --
            'move articles from db to fs' => {
            TicketNumber => '*',

            New => {
                    Module => 'Kernel::System::GenericAgent::MoveArticleParts',
                }
            },

3. Den GenericAgent manuell aufrufen:

Code: Select all

$OTRSHOME/bin/GenericAgent.pl

Falls man mehr als 3000 Tickets im System hat sollte man noch eine Ticketanzahl mitgeben, da der GenericAgent von Haus aus nur 3000 Tickets abarbeitet. Also:

Code: Select all

$OTRSHOME/bin/GenericAgent.pl -l 100000

Danach sollt der GenericAgent sauber durchlaufen und alle Attachments aus der Datenbank holen. Wenn das erledigt ist (kann schon eine Weile dauern bei entsprechender Ticketanzahl) sollte man noch die Tabellen optimieren:

4.

Code: Select all

mysql -p otrs

5.

Code: Select all

optimize table article_attachment;

6.

Code: Select all

optimize table article_plain;

Damit ist das ganze erledigt und man sollte jetzt eine Attachmentfreie Datenbank haben

SetPermission Probleme bei ArticleStorageFS
Da auf meinem System ein extra Benutzer angelegt ist (support) der die Mails fürs OTRS empfängt und dann per Procmail und Postmaster.pl die Daten weiterreicht ins System hatte ich ein kleines Berechtigungsproblem. Ich mußte als Hauptgruppe für den Benutzer(support) die Webservergruppe(www) setzen, andernfalls durfte der User nicht in $OTRSHOME/var/article schreiben.

DonEstefan · Post by **DonEstefan** » 23 Apr 2007, 12:59

Erstmal Danke für die Anleitung. SUPER ARBEIT!

Ich habe aber noch 3 Ergänzungen

Das Script hat einen kleinen Bug.
Bei einigen Sonderzeichen in Dateinamen von E-Mail Anhängen schlägt der Export fehl, z.B.

"user's guide.pdf" oder
"file:///C|/DOKUME%7E1/USER/LOKALE%7E1/TEMP/logfile.tmp" (Zugegebenermaßen ein ziemlich dämlich Dateiname)

Bei ersterem liegt es wahrscheinlich am Escapen von Sonderzeichen unter Perl. MySQL brachte jedenfalls ne entsprechende Fehlermeldung.
Bei dem anderen Beispiel könnte es sogar an Beschränkungen des Filesystems liegt, daß der Export fehlschlägt. Hier brachte das GenericAgent Script eine Fehlermeldung.
Jedenfalls sollte man das Ganze im Hinterkopf haben.

Der Bug hat aber keinen allzu negativen Einfluß. Die "bösen" Dateien bleiben eben in der DB (so intelligent ist das Script) und alle anderen Dateien werden erfolgreich Exportiert. Über Die Weboberfläche sind sie beide Verfügbar.
Kritisch wird es aber, wenn zu einem Ticket (oder einer Mail?!?) mehrere Anhänge existieren. Wird nun ein Anhang exportiert und der andere nicht (wegen dem Bug), so taucht ersterer nicht mehr in der Webansicht auf.
Das läßt sich aber anhand des Logfiles (siehe nächsten Punkt meiner Vorschläge) mit etwas Mühe nachvollziehen. Das beheben kostet etwas mehr Energie. Es gibt nach wohl 4 verschiedene Möglichkeiten das ganze zu lösen...
1. Das Ganze Szenario auf einem Testsystem simulieren.
  Aufschreiben welche Tickets von dem Bug betroffen sind.
  ALLE Anhänge zu den Tickets aus der originalen Datenbank kopieren.
  Die Kopierten Einträge in die Testdatenbank wieder einfügen.
  Ggf. noch die Dopplungen aus dem Dateisystem löschen.
  Resultat -> alle Anhänge von Tickets in denen Probleme Auftraten bleiben in der DB und die Welt dreht sich weiter
2. Man kann die Dateinamen in der Datenbank (Tabelle "article_attachments" Spalte "filename") auf vernünftige Namen ändern, und dann den Agenten nochmal anzustoßen bis alle Anhänge aus der DB draußen sind. Allerdings sind alle E-Mails nochmal separat als "Plaintext incl. Anhängen" gespeichert und die entsprechenden Anzeigen würden sich dann unterscheiden. Je nachdem wie OTRS auf die Daten zugreift (so tief steck ich dann doch nicht in der Materie) riskiert man damit auch noch die Konsistenz seiner Datenbank - also ohne Garantie
  Resultat -> alle Anhänge von Tickets in denen Probleme Auftraten kommen ins Filesystem und die Welt dreht sich (mit schlechtem Gewissen) weiter
3. Wem das alles zuviel wird, der kann über den GenericAgent in der Weboberfläche Tickets (incl. Anhänge) auch ganz für immer und auf nimmerwiedersehen löschen
4. Man betet zu einer höheren Entität der Wahl, das die Nutzer weniger Fantasievolle Namen gewählt haben und der Bug für einen nicht relevant ist. Oder einfach niemand den merkt, daß nicht alles 100% lief.
Ich kann nur anraten für Schritt 3 der Anleitung die Ausgabe des Scriptes in eine Datei umzuleiten
Code: Select all
```
bin/GenericAgent.pl -l 100000 >> output.txt
```
So bekommt man ausschließlich eventuelle Fehlermeldungen von MySQL auf den Bildschirm, da diese nicht in die Datei umgeleitet werden. Anschließend kann man output.txt in aller Ruhe nach Fehlermeldungen vom GerericAgent durchsuchen.
TIP dazu:
In den "print" Anweisungen im Script, welche für Fehlermeldungen zuständig sind, ein Schlagwort wie "ERROR" hinzufügen. Danach läßt es sich dann leichter suchen.
Die option "-l 100000" bei mehr als 3000 Tickets hat bei mir nicht funktionert. Ich habe daher der Gererich Agent mehrfach hintereinander gestartet bis alles exportiert war.

Getestet mit OTRS 2.1.7 auf CentOS 5 Linux

PS: Das Forum hat übrigens auch einen Bug wenn man Listen in Listen erstellt

buster · Post by **buster** » 27 Jun 2007, 10:05

Zunächst mal vielen Dank für die Anleitung!

Allerdings habe ich noch ein Problem mit dem genannten Script entdeckt:
Auf unserem Test-System (Win2003 Server) habe ich alles genau nach Anleitung ausgeführt und die Attachments und Plain-Files wurden auch alle im Article-Verzeichnis angelegt. Nur: Die Files sind fehlerhaft und können nicht geöffnet werden !!!
Dies gilt für alle Filetypen, egal ob gif, jpg, doc, ect. einzig die Plainfiles können problemlos geöffnet werden.

Hängt dies eventuell damit zusammen, dass unsere MySQL-DB ursprünglich eine 1.3er Version war, die ich nun auf die 2.1.17 upgedatet habe? Allerdings sollten die UpdateScripts eventuelle Änderungen ja beinhalten, oder ?

Da ich mich in Perl nicht besonders gut auskenne, bin Ich für jede Hilfe Dankbar

Andre Bauer · Post by **Andre Bauer** » 27 Jun 2007, 10:16

Benutzt Ihr UTF-8?

Wenn ja, gibts dort derzeit leider einige Bugs, die die Dateianhänge zerstören können...

Dennis · Post by **Dennis** » 27 Jun 2007, 15:14

Ich habe es nie unter Windows getestet, deshalb keine Ahnung, sorry

buster · Post by **buster** » 27 Jun 2007, 16:04

Wenn ich den Inhalt eines Word-Files mit einem Texteditor anschaue, beginnt das File mit folgender Sequenz:
application/msword; name="System.doc"

Ich denke das hier auch der Fehler liegt! Denn sobald ich den Inhalt des Feldes Content aus article_attachments im MySQL QueryBrowser anschaue so fehlt dort diese Sequenz. Wird der Content aus dem QueryBrowser heraus gespeichert, so kann das File geöffnet werden und der Inhalt wird korrekt angezeigt.

Da ich mich unter Perl aber nicht auskenne, kann ich den Code des Skripts leider nicht selbst so ändern, dass der Content-Type und der Filename nicht mehr in das File hineingeschrieben werden

Falls jemand von Euch über diese Fähigkeiten verfügt (wovon ich überzeugt bin), so würde ich mich über ein wenig Hilfe freuen

Andre Bauer · Post by **Andre Bauer** » 27 Jun 2007, 17:13

Das ist kein Fehler. Die Files werden erst beim Download aus dem OTRS über den Browser in die Originalform (ohne die erste Zeile) gebracht.

buster · Post by **buster** » 27 Jun 2007, 19:16

OK, ich habe nun mal ein Attachment aus der DB im Produktiv via QueryBrowser gespeichert und anschliessend das selbe Attachment auch aus der Test-DB via QueryBrowser. Ergebnis: Beide Files sind identisch !!!

Daher muss das Attachment in seinem Inhalt beim Schreiben in das FileSystem offenbar von dem Script oder von OTRS verändert werden, da die Files nach schreiben ins FS differenzen aufweisen!!!

UTF-8 wird aktuell von uns nicht eingesetzt, die Tabelle und die komplette DB stehen auf latin1 als Zeichensatz

Ich weiss einfach nicht mehr weiter.....

Andre Bauer · Post by **Andre Bauer** » 28 Jun 2007, 11:47

Kann ich hier nicht nachvollziehen. DieDownloads sind OK, außer wenn der UTF8 Bug zuschlägt...

buster · Post by **buster** » 02 Jul 2007, 14:50

Woran kann ich erkennen, ob unser Problem nicht doch irgendwo mit dem UTF8-Bug zusammenhängt?

Wie gesagt die DB steht auf latin1 und hat mit UTF8 eigendlich nichts am Hut....

Andre Bauer · Post by **Andre Bauer** » 02 Jul 2007, 16:06

Kommt ja auch noch darauf an, was du in der Sysconfig für ein Charset eingestellt hast...

buster · Post by **buster** » 02 Jul 2007, 17:12

In der SysConfig ist iso-8859-1 eingetragen...

Andre Bauer · Post by **Andre Bauer** » 02 Jul 2007, 18:07

Eventuell könnte iso-8859-15 richtig sein. Hängt ja auch noch von deiner Apache Konfiguration ab.

buster · Post by **buster** » 14 Aug 2007, 10:59

Ich habe nun auf der Version 2.2 versucht, dass ganze nochmal zum laufen zu bringen.

Ergebnis: Can't run GenericAgent Job 'move articles from db to fs' because no search attributes are used!.

Was mache ich falsch?

Andre Bauer · Post by **Andre Bauer** » 14 Aug 2007, 13:33

Siehe release notes OTRS 2.2.2.

- (2007/07/23) Because of safety reason, generic agent jobs will not longer run
without min. one search attribute (admin interface and cmd). So if you want to
match all ticket, you need to add an * in the ticket number.

Eventuell muss hier also noch was angepasst werden....

buster · Post by **buster** » 15 Aug 2007, 13:30

monotek wrote: ... Eventuell muss hier also noch was angepasst werden....

Was und wo?

Besten Dank

goahead · Post by **goahead** » 04 Nov 2007, 01:32

gibt es schon eine Anpassung für Version 2.2 ?

Andre Bauer · Post by **Andre Bauer** » 23 Nov 2007, 14:53

Ungetestete Anpassung des Scripts:

Code: Select all

        # --
        # move articles from db to fs
        # --
        'move articles from db to fs' => {
        TicketNumber => '*',

        New => {
                Module => 'Kernel::System::GenericAgent::MoveArticleParts',
            }
        },

Eventuell muss der "*" auch ein "%" sein.

huestjan · Post by **huestjan** » 26 Nov 2007, 12:48

Unter SLES10 und OTRS 2.2.2 getestet und es hat ohne Fehler funktioniert.
Der * als Suchstring ist richtig!

Code: Select all

TicketNumber => '*',

Andre Bauer · Post by **Andre Bauer** » 26 Nov 2007, 13:06

Danke fürs Feedback.

Hab mir mal erlaubt das Howto entsprechend anzupassen...

GeorgK · Post by **GeorgK** » 04 Jan 2008, 00:21

Hallo,

aus verschiedenen technischen und organisatorischen Gründen habe ich das umgekehrte Problem: Vor 2 1/2 Jahren haben wir auf ArticleStorageFS umgestellt und ich muß diese Tickets wieder zurück in die DB holen. Gibt es hierzu auch einen passenden GenericAgent?
Leider fehlt mir die Zeit und ich habe auch zu wenig wenig Kenntnis über die Datenstrukturen um mir da selbst auf die Rasche etwas zu bauen.

Danke im voraus!

McClane · Post by **McClane** » 11 Feb 2008, 20:51

Hi,

ich stehe nun auch vor dem Problem mit UFT8 und Umstellug auf ArticleStorageFS. Sämtliche Anhänge sind defekt nach dem das Script durchgelaufen ist.
Gibt es da einen Workaround? Es würde mir ja schon reichen wenn die alten Anhänge in der DB verbleiben, aber die lassen sich dann auch nicht mehr öffnen nach der Umstellung.

Andre Bauer · Post by **Andre Bauer** » 12 Feb 2008, 11:40

Das eine (UTF8) hat ja erstmal nichts mit dem anderen (ArticleStorage) zu tun.

Hast Du versucht beides gleichzeitig zu ändern?

McClane · Post by **McClane** » 12 Feb 2008, 11:47

Was meinst du mit beides gleichtzeitig?
Ich hab bisher nur versucht die Anhänge mit dem Script zu exportieren. Dabei wurde aus einer 500kb BMP Datei eine 1,7MB Müll Datei. Gleiches bei PDFs und anderen Anhängen.
Ich hab dann mein Backup wieder eingespielt und umgestellt auf StorageFS und dabei bemerkt das dann zwar neue Anhänge korrekt abgelegt werden im Dateisystem aber die alten Anhänge in der DB nicht aufrufbar sind. Es kommt ein Downloaddialog mit der index.pl und der Größe 0.
Im Moment sehe ich nur die Möglichkeit die alten DB Anhänge zu löschen und dann auf StorageFS umzustellen.

Andre Bauer · Post by **Andre Bauer** » 12 Feb 2008, 11:53

Ich hatte das jetzt so verstanden, dass Du außerdem auch deinen Zeichenstaz geändert hast.

McClane · Post by **McClane** » 12 Feb 2008, 12:25

Nene, bin doch nicht Wahnsinnig. Aber der Apache, MySQL und OTRS sind auf UTF8 geeicht. Bisher auch keine Probleme bei Empfang und Versand von Emails, Darstellung um Browser oder beim Ausdruck als PDF. Nur irgendwas hakt beim Export der Anhänge.

ane · Post by **ane** » 13 Feb 2008, 13:40

Ich hab mich mit dem Problem schon ein Paar Monate befasst, Wenn ich die Anhänge aus der Datenbank holle, sind dise kaputt. Ich hab eine Lösung gefunden, die einen Mischbetrieb erlaubt.
In der Datei ArticleStorageFS in der Unterfunktion folgendes ändern:

if (!%Data) {

durch

else{

ersetzen. Das Problem ist, da der Hash %Data schon existiert, wird in der Datenbank nicht gesucht. Durch Die Umstellung kann man nach Lust und Laune in der SysConfig auf DB oder FS umstellen.

mfg,
Alex

PS: Ich hoffe das eich die Lösung auch Hilft

McClane · Post by **McClane** » 13 Feb 2008, 13:54

Hi Alex,

vielen Dank, das funktioniert. Ist natürlich ein böser Bug. Im Bugzilla ist der noch nicht vermerkt, ich werde mal einen Report dafür erstellen.

Andre Bauer · Post by **Andre Bauer** » 13 Feb 2008, 13:55

Bitte auch gleich den Link dazu hier posten...

McClane · Post by **McClane** » 13 Feb 2008, 14:40

Hier der Link zum Bug http://bugs.otrs.org/show_bug.cgi?id=2684

Andre Bauer · Post by **Andre Bauer** » 02 Oct 2008, 14:35

Das ganze wird übrigens in OTRS 2.4.0 out of the box möglich sein

- (2008/10/02) Added script to move stored attachments from one backend to
other backend, e. g. DB -> FS (bin/otrs.ArticleStorageSwitch.pl).

risker · Post by **risker** » 28 Jan 2011, 13:11

Funktioniert das auch zuverlässig?

Znuny Open Source Ticketsystem