Sonstiges

Backup

Ein Backup erfolgt durch die zentrale Technik.

Änderung am 27.8.19:

Die Gastansicht auf Tickets wurde komplett abgeschafft. Dies wurde auf dem T-Treffen am 22.8.19 beschlossen.

Upgrade von 4.2.10 auf 4.4.1

Das Upgrade wurde wie in der RT Dokumentation beschrieben durchgeführt und die Dateien in local/html angepasst. Es traten keine Probleme auf. Die Dateien für SelfService wurden in local/html auf dem 4.2.10 Stand belassen, da sie unverändert funktionierten.

Vorher wurde Debian per Upgrade auf die aktuelle Debian Version 8 gebracht. Danach musste /opt/rt4/bin/check-fetchmail und die Apache Konfiguration (2.2 auf 2.4) angepasst werden.

Actung: Nach dem RT Update hatten die zusätzlich in /opt/rt4/etc befindlichen Dateien für procmail und fetchmail den falschen Owner, sie müssen fetchmail gehören!

Upgrade von 4.0.19 auf 4.2.10

Das Upgrade wurde wie in der RT Dokumentation beschrieben durchgeführt und die Dateien in local/html angepasst. Es traten keine Probleme auf.

Upgrade von 4.0.10 auf 4.0.19

Das Upgrade war eine Neuinstallation auf Debian, die gesamte Dokumentation bezieht sich auf die Version 4.0.19, daher wird hier nichts beschrieben.

Upgrade von 3.8.8 auf 4.0.10

Da mit diesem Upgrade ein großer Sprung gemacht wurde und auch das verwendete Webdesign Theme von dem bisher genutzten 3.5-Standard auf das mit 4.0 kommende aileron gewechselt wurde, wurde eine Neuinstallation in /services/rt4 vorgenommen, die zunächst mit einer kopierten Datenbank angepasst und getestet wurde, bevor die endgültige Umstellung erfolgte.

Im ausgepackten Verzeichnis rt-4.0.10 wurde zunächst configure aufgerufen:

export PATH=/services/perl/bin:/opt/csw/gnu:$PATH
./configure --prefix=/services/rt4 --with-web-user=apache --with-web-group=apache --with-rt-group=rt

Danach die Perl Abhängigkeiten überprüfen und ggf. nachinstallieren:

make testdeps
make fixdeps

Dann RT4 installieren lassen:

make install

Da kein Upgrade gemacht wurde, müssen nun die zusätzlichen Dateien aus bin und etc für das rt-mailgate kopiert werden. Die Datei etc/RT_SiteConfig.pm muss gemäß Dokumentation angepasst werden.

Danach die Datenbank updaten und weitere Upgrade Kommandos ausführen:

make upgrade-database
/services/perl/bin/perl etc/upgrade/vulnerable-passwords
/services/perl/bin/perl -I /services/rt4/local/lib -I /services/rt4/lib etc/upgrade/shrink_transactions_table.pl

Die Konfiguration für Apache2 musste komplett überarbeitet werden.

In diesem Fall waren die Änderungen so umfangreich, dass alle lokalen Anpassungen Schritt für Schritt anhand des diff's nachvollzogen und getestet werden mussten.

Upgrade von 3.6.4 auf 3.8.8

Im ausgepackten Verzeichnis rt-3.8.8 wurde zunächst configure aufgerufen:

export PATH=/services/perl/bin:/opt/csw/gnu:$PATH:/usr/sfw/bin
./configure --prefix=/services/rt3 --with-web-user=apache --with-web-group=apache --with-rt-group=rt

Danach wie bei der Installation beschrieben, die Perl Abhängigkeiten überprüfen und ggf. nachinstallieren.

Vor dem eigentlichen Upgrade werden die html Dateien verglichen, z.B. mit folgendem Kommando alle veränderten Dateien finden:

for i in `find html -type d`; do diff --brief $i /usr/local/rt3/share/$i; done | grep -v "ommon subdir" | cut -d' ' -f2

Danach das Kommando:

make upgrade

ausführen. Falls erforderlich wie in der Ausgabe des obigen Kommandos beschrieben die Datenbank upgraden. In diesem Fall auf 3.8.8:

perl etc/upgrade/upgrade-mysql-schema.pl rt3 rt_user service-rt3 >queries.sql
mysql -u rt_user -p rt3 < queries.sql

Dann in das Installationsverzeichnis /services/rt3 wechseln. Im Verzeichnis etc befindet sich die Datei RT_SiteConfig.pm unverändert, dort müssen die Änderungen aus RT_Config.pm hinzugefügt werden.

Falls sich html Dateien geändert haben, die von uns in local/html ebenfalls geändert wurden, müssen diese Änderungen in den local/html Dateien nachvollzogen werden. In diesem Fall waren die Änderungen so umfangreich, dass alle lokalen Anpassungen Schritt für Schritt anhand des diff's nachvollzogen werden mussten. Dazu wurde das Upgrade zunächst in /services/rt388 durchgeführt und parallel zum laufenden RT 3.6.4 mit einer geklonten Datenbank getestet, bevor das eigentliche Upgrade durchgeführt wurde.

Autor: Mattias Werner

AG BKB

Zuletzt geändert am: 27. August 2019