Hi,
In my company we are considering the possibility of separating certain departments OTRS instance we had set for their sensitive information. We evaluated various options and has put on the table to implement on the same virtual machine but in a second OTRS.
I searched and could do it and I found this topic about multiple instances of OTRS in only apache.
viewtopic.php?f=62&t=16750&p=65030&hili ... trs#p65024
jojo says it's not recommended to use this method, but does not specify the causes. What could be the implications?
Regards.
Implications of having multiple instances OTRS in Apache?
Moderator: crythias
-
crythias
- Moderator
- Posts: 10170
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: Implications of having multiple instances OTRS in Apache
If you're separating based upon agent, say .. HR/Termination/Management, just do that within OTRS as a new queue. Create a new email address that drops into that queue and only the agent members of that queue's group will see and respond to the tickets.
If you've given everyone in your company the same CustomerID, you'll need to determine how to deal with "Company Tickets" as this Company Internal, yet sensitive information will be seen (by default) by the people with the same CustomerID who have access to Company Tickets (This is mitigated by CustomerGroupMembership).
"What could be the implications?"
It's a pain in the butt to administer correctly, and spinning up a VM for this purpose is just easier.
"But will it break anything?"
No, but, especially with mod_perl, it may not work as you've intended performance-wise. Also, with the separate vm, you have a general, "Take it and go" environment that is, indeed, completely separate from the master database.
If you've given everyone in your company the same CustomerID, you'll need to determine how to deal with "Company Tickets" as this Company Internal, yet sensitive information will be seen (by default) by the people with the same CustomerID who have access to Company Tickets (This is mitigated by CustomerGroupMembership).
"What could be the implications?"
It's a pain in the butt to administer correctly, and spinning up a VM for this purpose is just easier.
"But will it break anything?"
No, but, especially with mod_perl, it may not work as you've intended performance-wise. Also, with the separate vm, you have a general, "Take it and go" environment that is, indeed, completely separate from the master database.
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
-
miguelmz
- Znuny wizard
- Posts: 370
- Joined: 17 Nov 2011, 17:46
- Znuny Version: 6.0.10
- Real Name: Miguel
- Company: SIA
- Location: Madrid, Spain.
Re: Implications of having multiple instances OTRS in Apache
Thanks for responding so soon.
Due to sensitive information of this group and service requirements, I can not separate them by queues and permissions.
The performance issue had already assumed, but I worry more errors of compilations with 2 otrs running perl. In mod_perl configuration documentation, I saw a reference to a problem:
http://perl.apache.org/docs/2.0/user/config/config.html
A common problem with mod_perl 1.0 was the shared namespace between all code within the process. Consider two developers using the same server and each wants to run a different version of a module with the same name
Due to sensitive information of this group and service requirements, I can not separate them by queues and permissions.
yes, I think the same, but this is not possible in this case"But will it break anything?"
No, but, especially with mod_perl, it may not work as you've intended performance-wise. Also, with the separate vm, you have a general, "Take it and go" environment that is, indeed, completely separate from the master database.
The performance issue had already assumed, but I worry more errors of compilations with 2 otrs running perl. In mod_perl configuration documentation, I saw a reference to a problem:
http://perl.apache.org/docs/2.0/user/config/config.html
A common problem with mod_perl 1.0 was the shared namespace between all code within the process. Consider two developers using the same server and each wants to run a different version of a module with the same name