Page MenuHomePhabricator

Upgrade OTRS to 3.2.14 version
Closed, ResolvedPublic


We're currently sitting at version 3.2.9. Version 3.3.3 is the latest available and there have been *several security releases* since we last upgraded.

I'm told that RT #6674 ( is related to this as well.

Version: wmf-deployment
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:51 AM
bzimport added a project: Znuny.
bzimport set Reference to bz60271.

Copying Chris to evaluate out how urgent the security fixes are.

(In reply to comment #2)

How are the links you provided related to security? Why did you include a broken link?

(In reply to comment #3)

(In reply to comment #2)

How are the links you provided related to security? Why did you include a
broken link?

Ask OTRS? The message we all see when we log in is the following:

Product News
OTRS 3.3.3 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.3.2 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.3.1 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.2.12 is available! Please update now. (Release Note - Level: Security)
OTRS 3.2.11 is available! Please update now. (Release Note - Level: Security)
OTRS 3.2.10 is available! Please update now. (Release Note - Level: Security)

The links I provided are the links they provided within those above words.

I should note, that this is probably a 2 part bug

The 3.2.X patches should ideally be applied sooner, and hopefully should be trivial to do.

Upgrade to 3.3 is likely to be quite a bit more involved work to do so

I see that otrs is calling 3.2.8-13 "security" releases (, but nothing in the release notes looks like a serious security issue. It doesn't look like any cve's have been issued since 3.2.9.

If anyone can find the details, I'm happy to add an opinion.

I'm changing the bug topic to 3.2.x--IMO we should keep the minor/security releases separate from the major version upgrade. The upgrade and tracking of latest 3.2.x is a no-brainer, somthing I've been intending to do but haven't had time due to fundraising obligations. The main hitch at this point is making sure that the version patches don't conflict with our own patches.

And this was released yesterday,

So we need to update to 3.2.14. I can't tell how critical the vulnerable features are, so I'm not sure how urgent the upgrade is. But seems like something we should try to do soon.

me wrote:

Znuny ( can assist. We have two options.

  1. Just update fixed files, see also!/advisory/ZSA-2014-01!/advisory/ZSA-2014-02
  1. Upgrade to latest OTRS 3.2 release

Who is the technical contact?


me wrote:

Sorry, this are the correct urls (in english):!/advisory/ZSA-2014-01!/advisory/ZSA-2014-02

I can work on this. Let's go for the latest 3.2 release. I will review the release/upgrade information today.

I applied the fixed files per Martin's suggested workaround, so we should be in reasonably good shape security wise.

I still intend to upgrade us to 3.2.14 which is the latest 3.2.x release once I'm more confident on the order of operations for the upgrade.

I set up a test db+webserver instance on db78 and went through the reinstall process with 3.2.14. The OTRS packages needed reinstall as expected, and everything appeared to go smoothly.

When we do the upgrade on the live system we should run a database dump and web tree backup before making changes. I think we can use one of the slave db's to do this in parallel--so we shouldn't need a very long outage, under an hour.

So as far as I'm concerned we can schedule a maintenance window and go ahead with the upgrade.

Just let us know so we can notify our users ASAP when this outage will occur.
Thanks, Jeff.

The upgrade to 3.2.14 is scheduled for Wednesday Feb 12th, at 5AM UTC according to the deployment schedule.

Upgrade process notes:

disable iodine https/smtpd monitoring
disable db48 mysql monitoring

root@iodine:/usr/local/src# wget
root@iodine:/opt# tar xjf /usr/local/src/otrs-3.2.14.tar.bz2
study otrs-3.2.14/ and sanity check these upgrade instructions

root@iodine:~# /etc/init.d/puppet stop
root@iodine:~# /etc/init.d/apache2 stop
root@iodine:~# /etc/init.d/exim4 stop
root@iodine:~# rm /etc/cron.d/puppet /etc/cron.d/otrs

root@iodine:/opt# tar czf backup/otrs-3.2.9-20140206.tgz otrs-3.2.9
stop slave on db48, start dumping the otrs db there

root@iodine:/opt# rm otrs && ln -s otrs-3.2.14 otrs
root@iodine:/opt# cp otrs-3.2.9/Kernel/ otrs/Kernel/
root@iodine:/opt# ./otrs/bin/ --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /opt/otrs

root@iodine:/opt# ./otrs/bin/
follow database upgrade instructions in

on db1048.eqiad.wmnet, otrs database
ALTER TABLE dynamic_field ENGINE=InnoDB;
ALTER TABLE dynamic_field_value ENGINE=InnoDB;
ALTER TABLE gi_debugger_entry ENGINE=InnoDB;
ALTER TABLE gi_debugger_entry_content ENGINE=InnoDB;
ALTER TABLE gi_object_lock_state ENGINE=InnoDB;
ALTER TABLE gi_webservice_config ENGINE=InnoDB;
ALTER TABLE gi_webservice_config_history ENGINE=InnoDB;
ALTER TABLE notification_event ENGINE=InnoDB;
ALTER TABLE notification_event_item ENGINE=InnoDB;
ALTER TABLE pm_activity ENGINE=InnoDB;
ALTER TABLE pm_activity_dialog ENGINE=InnoDB;
ALTER TABLE pm_entity_sync ENGINE=InnoDB;
ALTER TABLE pm_transition ENGINE=InnoDB;
ALTER TABLE pm_transition_action ENGINE=InnoDB;
ALTER TABLE scheduler_task_list ENGINE=InnoDB;
ALTER TABLE smime_signer_cert_relations ENGINE=InnoDB;
ALTER TABLE ticket_flag ENGINE=InnoDB;
ALTER TABLE virtual_fs_db ENGINE=InnoDB;
ALTER TABLE virtual_fs_preferences ENGINE=InnoDB;
*NOTE* complains because the default storage engine for db1048 is myisam
jgreen declares this acceptable and moves on

root@iodine:/opt# /etc/init.d/apache2 start
ADMIN -> System Administration -> Package Manager

Reinstall will be under the ACTION column for each package

root@iodine:/opt# cp otrs-3.2.9/Kernel/Config/Files/ZZZA* otrs/Kernel/Config/Files/
root@iodine:/opt# ./otrs/bin/ --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /opt/otrs
root@iodine:/opt# /etc/init.d/apache2 restart

test functionality

root@iodine:~# /etc/init.d/exim4 start
root@iodine:~# puppetd -tv
send a mail to e.g. info-en and check that it shows up in OTRS


reenable iodine https/smtpd monitoring

restart slave on db48
reenable db48 mysql monitoring