How to run multiple (mod_perl supported) OTRS on a single host

Jens Bothe11. Aug 2010 | Administration


The practical examples presented in our technical blog ( and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.


Running multiple OTRS instances on 1 host is interesting and possible when using the so-called CGI mode. This means OTRS is compiled by the webserver each time you perform a task like sending an email, calling the Dashboard etc.

Apache’s mod_perl on the other hand makes sure the OTRS is compiled at Apache start-up and available at any time (See [perl] for more information). This improves speed by numbers and you don’t want to miss it.

The intersting point is now to have separate OTRS within Apache’s memory not accessing each others environment.


multiple Apache instances

The first idea was to “simply” run multiple Apache instances with their own configuration and environment.

See [multipleApache] for an example setup.

chrooted Apache environments

Chroots (or jails in *BSD) provide the option to further (in fact really) separate the different Apache processes from each other.

See [chroot] for more information and [chroot1] for an example setup.

mod_perl’s +Parent separation

mod_perl provides a switch which:

Create a new parent Perl interpreter for the given VirtualHost and give it its own interpreter pool (implies the Clone option).

Remember that +Parent gives you a completely new Perl interpreters pool, so all your modifications to @INC and preloading of the modules should be done again. Consider using PerlOptions +Clone if you want to inherit from the parent Perl interpreter.


The idea of chroot’ing the Apache is nice and interesting but here’s the big BUT:

Pros and Cons

  • If apache is ever compromised, the attacker will not have access to the entire file system.
  • Poorly written CGI scripts that may allow someone to access your server will not work.
  • There are extra libraries you’ll need to have in the chroot jail for Apache to work.
    If you use any Perl/CGI features with Apache, you will need to copy the needed binaries, Perl libraries and files to the appropriate spot within the chroot space.
    The same applies for SSL, PHP, LDAP, PostgresSQL and other third-party programs.


So we have to provide the complete Perl environment plus any possibly used binaries inside the chroot.
This can be done either by copying the directory structures or files or creating a symlink farm for update reasons.

I’m really not sure about the final effort and if it’s justified by the gained security level.

At the moment I will skip chroot/jail and multiple Apache processes for 3 reasons:

  • it seems that Apache and mod_perl provide a way to have separate run-time environments for web applications
  • both alternatives need a much higher effort by no clear advantage
  • mod_perl’s +Parent directive is independent of the used OS so the same mechanism can be used on Debian GNU/Linux, XYZ-BSD, Solaris, Windows Server 2008

Example on a Debian Lenny using name based virtual hosts

(1) configure your Apache and OS the way you want to use the <VirtualHost> setting later on

Make sure there is a default <VirtualHost> in /etc/apache2/sites-enabled/000-default

Add the virtual server names to /etc/hosts

(2) install your OTRS instances

(3) reflect your system settings in each OTRS’

  • scripts/apache2-httpd-new.include.conf
  • scripts/
  • Kernel/


Add a <VirtualHost> handler to the configuration
(make sure you add the necessary </VirtualHost> to the end of the file)
<VirtualHost *:80>
ServerName otrs-3
ServerAdmin webmaster@localhost

# agent, admin and customer frontend
ScriptAlias /otrs/ "/opt/otrs-3/bin/cgi-bin/"
Alias /otrs-web/ "/opt/otrs-3/var/httpd/htdocs/"
# if mod_perl is used
<IfModule mod_perl.c>
PerlOptions +Parent
# load all otrs modules
Perlrequire /opt/otrs-3/scripts/

<Directory "/opt/otrs-3/bin/cgi-bin/">
<Directory "/opt/otrs-3/var/httpd/htdocs/">



# set otrs lib path!
use lib "/opt/otrs-3/";
use lib "/opt/otrs-3/Kernel/cpan-lib";


$Self->{Home} = '/opt/otrs-3';
$Self->{'LogModule::LogFile'} = '/opt/otrs-3/var/log/otrs.log';
$Self->{'LogModule'} = 'Kernel::System::Log::File';

(4) link the OTRS configurations to Apache

ln -s /opt/otrs-3/scripts/apache2-httpd-new.include.conf /etc/apache2/sites-enabled/otrs-3

(5) restart Apache

(6) make sure your DNS is resolving otrs-3 correct

Further reading


Have fun,


Jens at 20.08.2015, 15:33

For services please contact or use the forums, mailinglists or facebook group. Please note that it is not suggested to run several OTRS instances on one host!

Simone Mura at 14.08.2015, 14:53

Hi i've problems with the schedule, don't work for the second installation, how can i do?

Jarvis at 09.07.2014, 18:35

Nice article. I was able to get OTRS 3.3.4 running...with 4 instances with Centos 6.4 using the mod_perl approach. Rather than installing 4 times, I think I installed once and copied the directories and created new databases. The big gotchas I ran into was setting up individuals ports for each instance in the *.conf file and making sure that the directory names for the config files..etc referenced the appropriate directory. Seems to work nicely. Thank you.

liuk001 at 08.10.2013, 09:07

@MvB: yes switching to apache2-mpm-worker solved for us. HTH Cheers, Luca

MvB at 02.10.2013, 07:50

We only got abovementioned JSON error after switching to OTRS 3.2.10. Still running a preforked apache. Would a switch to MPMP-Worker solve it?

Luca Maranzano at 14.05.2013, 11:28

We have solved switching from apache2-mpm-prefork to apache2-mpm-worker. This happened after upgrade to Ubuntu 10.04, since on Ubuntu 8.04 with prefork it was working fine. Still to understand the reason of the bug: apache? mod_perl? JSON ? It has been quite hard to figure it out. HTH Cheers, Lua

Luca Maranzano at 08.05.2013, 22:17

I'm facing the same issue, apparently after upgrading from Ubuntu 8.04 (where it was working fine!) to Ubuntu 10.04 ans 12.04. I've two OTRS instances, one with 3.1.8 and one with 3.2.6, if both are enabled the second one gets JSON errors, enabling 1 at a time all is working. Please advise if you find a solution, I also wrote to the perl mailing list. Getting crazy about this :-) Thanks, Luca

Diego at 08.04.2013, 03:06

I have the same problem. I have this issue since 3.0.7.

Chandan Haldar at 16.03.2013, 06:06

With multiple OTRS instances on the same Apache/Mod_perl server in the +Parent configuration you described, all AJAX calls start failing, for example, in the retrieval of field values in the new ticket form. Apache error log shows a JSON object encode failure in line 109 in Any idea what could be the fix?

Tweets that mention How to run multiple (mod_perl supported) OTRS on a single host - OTRS Community Blog -- at 11.08.2010, 11:36

[...] This post was mentioned on Twitter by Christopher T. Kuhn, Daniel Ciaglia. Daniel Ciaglia said: How to run multiple (mod_perl supported) OTRS on a single host - [...]

Your email address will not be published. Required fields are marked *