Эти инструкции предназначены для тех, кто переходит с OTRS 3.3 к 4 или с 4 к более поздним patchlevel релизам 4 и применимы к обоим способам обновления из RPM и из исходных кодов (tarball).
Если вы работаете на ранних версиях OTRS, то должны следовать такому порядку обновления - сначала до 3.3 (1.1->1.2->1.3->2.0->2.1->2.2->2.3->2.4->3.0->3.1->3.2->3.3)! Вы должны выполнить полное обновление до каждой версии в промежутке, включая изменения структуры БД и perl-скриптов обновления.
Помните, что если вы делаете обновление с OTRS 2.2 или более ранней, вы должны выполнить дополнительный шаг.
Внутри одной версии, вы можете пропустить промежуточные релизы/patch level при обновлении. К примеру, вы можете провести обновление прямо с OTRS 4 patchlevel 2 до версии 4 patchlevel 6. Если вы желаете выполнить такое "patch level" обновление, Вы должны пропустить шаги 6, 11, 13 и 14.
Настоятельно рекомендуем выполнить сначала тестовое обновление в отдельной тестовой среде.
Убедитесь, что никакие сервисы или задания cron, которые обращаются к OTRS не выполняются. Это зависит от конфигурации вашей системы, далее приведен пример:
shell> /etc/init.d/cron stop
shell> /etc/init.d/postfix stop
shell> /etc/init.d/apache stop
Остановить OTRS cronjobs и Планировщик (в следующем порядке):
shell> cd /opt/otrs/
shell> bin/Cron.sh stop
shell> bin/otrs.Scheduler.pl -a stop
Kernel/Config.pm
Kernel/Config/GenericAgent.pm
Kernel/Config/Files/ZZZAuto.pm
var/*
а также базы данных
shell> cd /opt
shell> mv otrs otrs-old
shell> tar -xzf otrs-x.x.x.tar.gz
shell> mv otrs-x.x.x otrs
Kernel/Config.pm
Kernel/Config/GenericAgent.pm
Kernel/Config/Files/ZZZAuto.pm
Чтобы после обновления OTRS продолжил нумеровать заявки правильно,
восстановите TicketCounter.log в
/opt/otrs/var/log/. Это особенно важно, если вы
используете последовательную нумерацию заявок.
Если вы настроили хранение данных сообщений/заметок в OTRS в файловой
системе нужно восстановить article папку в
/opt/otrs/var/.
Выполните
shell> cd /opt/otrs/
shell> bin/otrs.SetPermissions.pl
с необходимыми для вашей системы правами. Например:
Web server работающий как пользователь OTRS:
shell> bin/otrs.SetPermissions.pl --web-group=otrs
Webserver с пользователем wwwrun (например в SUSE):
shell> bin/otrs.SetPermissions.pl --web-group=wwwrun
Webserver с пользователем apache (например, Red Hat, CentOS):
shell> bin/otrs.SetPermissions.pl --web-group=apache
Webserver с пользователем www-data (например, Debian, Ubuntu):
shell> bin/otrs.SetPermissions.pl --web-group=www-data
Проверьте наличие всех требуемых perl модулей и доустановите те, которые могли быть пропущены по разным причинам.
shell> /opt/otrs/bin/otrs.CheckModules.pl
Примечание: новые таблицы, созданные в процессе MySQL UPGRADING будут
созданы с методом доступа по умолчанию, установленном в вашем MySQL
сервере. В MySQL 5.5 применяется новый метод - InnoDB. Если
существующие таблицы, например, "users", имеют метод доступа, например,
MyISAM, может появиться сообщение об ошибке при создании
внешних ключей.
Имеется два варианта: вы можете изменить стандартный метод доступа MySQL
обратно в MyISAM, при этом новые таблицы будут иметь тот же
метод, что и старые, или перенастроить существующие таблицы на использование
InnoDB.
Любые проблемы, связанные с использованием метода доступа будут отражены в
отчете скрипта otrs.CheckDB.pl. Выполните его для
обнаружения возможных проблем.
shell> cd /opt/otrs/
shell> bin/otrs.CheckDB.pl
shell> cat scripts/DBUpdate-to-4.mysql.sql | mysql -p -f -u root otrs
Примечание: Темы OTRS 3.3 и OTRS 4 НЕ совместимы между собой, так что не используйте старые темы!
Темы расположены в /opt/otrs/Kernel/Output/HTML/*/*.tt.
Обращаем внимание, что OTRS 4 теперь использует новый механизм шаблонов основанный на Template::Toolkit. Все кастомизированные шаблоны должны быть преобразованы из DTL в новый формат. Читайте Руководство разработчика для детальных пояснений.
Выполните (как пользователь otrs, не как
root):
shell> bin/otrs.RebuildConfig.pl
shell> bin/otrs.DeleteCache.pl
в т.ч. (зависящие от использующихся услуг):
shell> /etc/init.d/apache start
shell> /etc/init.d/postfix start
shell> /etc/init.d/cron start
Теперь вы можете войти в систему.
Пакеты OTRS от 3.3 НЕ совместимы с OTRS 4, поэтому надо переустановить обновленные пакеты!
Следующие пакеты будут автоматически деинсталлированы после процесса обновления (если были установлены ранее):
OTRSGenericInterfaceREST
OTRSMyServices
OTRSStatsRestrictionByDateTimeDF
Поддержка
Если у вас имеются задания GenericAgent/Планировщика задач (или, даже
какие-то собственные разработки), которые автоматически устанавливают
значения динамических полей ProcessID или ActivityID, необходимо обновить
установку этих полей в новый формат long EntityIDs, которые генерируются
скриптом DBUpdate-to-4.pl.
В OTRS есть несколько стандартных заданий cron в файле
/opt/otrs/var/cron/*.dist. Для их применения скопируйте
их в файл, опустив в окончании его имени расширение ".dist". Выполните это,
чтобы быть уверенным в том, что вы используете последние версии заданий cron
и вновь включенные задания.
shell> cd /opt/otrs/var/cron
shell> for foo in *.dist; do cp $foo `basename $foo .dist`; done
Проверьте
скопированные файлы и сделайте нужные изменения, которые вы, возможно
делали. Для применения этих cronjobs в вашей системе можно использовать
скрипт Cron.sh. Убедитесь, что вы запускаете от имени
пользователя otrs!
shell> /opt/otrs/bin/Cron.sh start
Это также приводит к запуску Планировщика OTRS.
Если вы используете внешние БД клиентов и эти базы НЕ предоставляют
определенных для OTRS полей create_time, create_by, change_time и
change_by, установите значение ForeignDB => 1 для
$Self->{CustomerUser} и $Self->{CustomerCompany}
(см. Kernel/Config/Defaults.pm).
Выполните bin/otrs.RebuildTicketIndex.pl для обновления
индексов заявок. Это можно сделать в фоновом режиме для пересчета номеров
заявок для экранов обзора очередей. Теперь можно пользоваться системой.